ほとんどのコーディング作業は、今でもグループチャットの一文から始まります。「CSVエクスポートで最後の行が落ちてる」「デモの前にSSOを追加できる?」「本番のチェックアウトでまた500が出てる」。誰かが親指を立ててリアクションし、コーディングエージェントがそれに向けられ、3日後には、それがリリースされたのか、誰がレビューしたのか、どのコミットが直したのか、誰も答えられなくなっています。メッセージは上へ流れていき、作業は伝説になります。
このギャップは規律の問題ではなく、構造の問題です。チャットメッセージにはオーナーも、ステータスも、受け入れテストも、それを解決するdiffへのリンクもありません。そのメッセージにコーディングエージェントを向ければ、追跡できない作業が生まれます。エージェントを2つ以上動かすようになると、事態はさらに悪化します。どのエージェントが触ったのかも、もはや言えなくなるからです。
この記事では、チャットメッセージを追跡可能なコードタスクに変える方法を順を追って説明します。素朴な自作セットアップで得られるもの、どこでスケールしなくなるのか、共有タスクレイヤーが何を追加するのかを見ていきます。Sharklyは、追跡可能なバージョンのためのワークスペースです。コーディングエージェントの上位に位置し、ゴール、実行、ブロッカー、diff、そして人間によるレビューを1つの記録にまとめてくれます。コーディングエージェントはすでに手元にあるはずです。やるべきことは、その作業をチームが追える形にすることです。
チャットは、なぜコードタスクが死に絶える場所なのか
グループチャットは会話のスピードを最適化します。これはコードタスクが必要とするものとは正反対です。本物のタスクには、明示されたゴール、オーナー、受け入れ基準、問い合わせ可能なステータス、そしてそれを完了させた変更へのリンクが伴います。チャットメッセージにはそのどれもありません。あるのはタイムスタンプとリアクションだけです。
失敗のパターンは明確です。リクエストが届き、スレッド内で非公式に合意され、スレッドは動き続けます。2日後、誰かが「エクスポートのバグ、直したっけ?」と尋ね、その答えを見つけるにはSlack検索と、当て推量と、同じフレーズが9回も現れるチャンネルを延々スクロールする作業が必要になります。仮にそのメッセージを見つけたとしても、修正がマージされたかどうかは分かりません。会話とコードは、互いの名前をいつまでも知らないままの、別々のシステムに住んでいるのです。
そのメッセージに自律型コーディングエージェントを向けると、トレースはさらに短くなります。エージェントはSlackの一文を読み、誰かのラップトップ上のターミナルで動き、ファイルを編集し、リクエストを飲み込んだのと同じ速いスレッドに報告を返します。その結果、誰も保存していない実行ログ、誰もリンクしていない変更、誰も記録していない決定が残ります。
DIYパイプラインと、それがスケールしなくなる地点
始めるのにプロダクトは必要ありません。実用的なDIYパイプラインとしては、チャットメッセージをコピーし、プロンプトとしてコーディングエージェントに貼り付け、メインのチェックアウトと衝突しないよう独立したGit worktreeで作業させ、Closes #123の行で追跡Issueにリンクするプルリクエストを開く、というものです。これは本物の追跡可能性であり、一度に1つのリクエストを扱う個人開発者にとっては、多くの場合それで十分です。
ここで正直な判断基準を示します。もしあなたが1人で、1つのエージェントを動かし、次のタスクの前に1つのタスクを終わらせているなら、コピペしてworktreeに渡すこのループは機能しますし、そこにツールを追加する必要はありません。共有システムのオーバーヘッドは、得られる見返り以上のコストになるでしょう。
このセットアップがスケールしなくなるのは、次の2つが同時に真になった瞬間です。つまり、2つのエージェントが動いている、2人で作業を振り分けている、あるいは2つのリポジトリが関わっている。そのとき、手動パイプラインには穴が開きます。
| 壊れるところ | DIYループでカバーできない理由 |
|---|---|
| 「エクスポートのバグはどのエージェントが持ってる?」 | アサインは頭の中にあり、記録には残っていない |
| 「これは終わったの、まだ動いてるの?」 | ステータスは閉じたターミナルの中にあり、問い合わせられるフィールドではない |
| 「認証の変更は誰が承認した?」 | 承認は親指のリアクションで、もう流れてしまった |
| 「あのSlackの依頼のdiffはどこ?」 | PRはIssueにリンクしているが、Issueは依頼にリンクしていない |
| 「エージェントは実際に何を変更した?」 | 実行ログは終了したセッションの中にあった |
それぞれの穴は、タスクが再び追跡不能になる場所です。より多くのIssue、命名規則、そして規律によって、手作業でふさぐこともできます。それは機能しなくなるときまで機能し、そして静かに失敗します。これがプロセスにとって最悪の失敗の仕方です。
タスクが共有されたとき、「追跡可能」とは何を意味するのか
追跡可能とは雰囲気のことではありません。ある作業に関するあらゆる問いに対して、1か所に存在し、それが始まったときにオンラインだった人たちが去っても残る答えがあるということです。追跡可能なタスクは、依頼からリリースまで、コンテキスト、アサイン、進捗、ブロッカー、結果、そして人間によるレビューを見える状態に保ちます。
SharklyはこれをTaskとしてモデル化します。これはシステムにおける作業の主要な単位です。Taskはチャットメッセージでも、ターミナルセッションでもありません。それは、あなたがそれに基づいて行動することを決めたときにチャットメッセージが姿を変える、共有された記録です。ゴールは説明欄に書きます。Agentまたは人がAssigneeになります。Agentの実行、そのブロッカー、その結果、そしてフォローアップの議論はすべて、プライベートなターミナルに消えるのではなく、Taskのタイムラインに戻ってきます。変更が着地するとき、プルリクエストはIDでリンクされるので、依頼とdiffはようやく互いの名前を知ることになります。
1つの境界線が重要です。読者が誤解する可能性があるからです。SharklyはClaude Code、Codex、あるいはあなたの他のコーディングエージェントの代替ではありません。それらのツールは実行を担います。Sharklyはその周りに共有タスク、コンテキスト、レビューのレイヤーを追加します。コードを書くのは依然としてAgentです。Sharklyはその作業をアサイン可能で追跡可能にします。
Sharklyでチャットメッセージを追跡可能なタスクに変える
ワークフローは頭の中に留めておけるほど短いものです。実際のメッセージ、たとえばCSVエクスポートのバグから始めて、それをチャンネルの外へ移しましょう。
- メッセージをTaskとして取り込む。そのリクエストをゴールとしてTaskを作成します。チャットがSlackにあるなら、コーディングエージェント用のSlackボットが、スレッドを離れることなくメンションをTaskに変えます。
- Agentが実行できる形に整える。1行のバグ報告は実行可能な仕様ではありません。再現手順、期待される挙動、受け入れテストを加えます。AIエージェントのタスク管理と同じ規律です。Agentが完了できるTaskには、Agentが行動できる説明が必要です。
- アサインしてAgentを走らせる。AgentがTaskを引き受け、並行作業が衝突しないよう独立したworktreeで作業し、その進捗をTaskにストリーミングで返します。あなたはターミナルではなく、記録を見ているのです。
- レビューして受け入れる。Agentは変更サマリー、テスト結果、既知の限界を添付します。人が受け入れるか、変更を要求するか、マージの判断を下します。
最後のステップは、はっきり述べておく価値のある契約です。Agentは調査し、実行し、テストし、報告します。人は方向性を定め、権限を与え、結果を受け入れます。自動化は、チームの判断が必要とされる場所で止まります。追跡可能なタスクはそのハンドオフを可能にします。変更をレビューする人間が、依頼からdiffまでの道のり全体を見られるからです。作業が完了したら、記憶から再構築することなく、エージェントが完了した作業を追跡できます。これは、正式なチケットではなくチャットの切れ端から始まる、要件からコードへのワークフロー全体と同じ背骨です。
これをIssueとworktreeで手作業で作ることもできますし、Sharklyを使ってワークフローを管理し、量が増えてもトレースが保たれるようにすることもできます。
今日から実行できるチェックリスト
これを現在のセットアップに対して実行してみてください。チェックの付いていない各項目は、チャットから生まれたタスクが追跡不能になりうる場所です。
- [ ] 対応したすべてのチャットリクエストが、リアクション絵文字ではなくオーナーを持つTaskになる。
- [ ] 各Taskに、Agentが実行できる説明(再現、期待される挙動、受け入れテスト)がある。
- [ ] 実行中の各Agentが独立したworktreeで作業し、2つのタスクが同じファイルに触れることがない。
- [ ] Agentの実行ログ、ブロッカー、結果が、閉じてしまうターミナルではなくTaskに戻ってくる。
- [ ] プルリクエストがTaskにIDでリンクされ、依頼とdiffがワンクリックの距離にある。
- [ ] 人が結果を受け入れるか拒否し、その決定がTaskに記録される。
- [ ] 「これは終わったのか、誰がやったのか、diffはどこか?」をチャットを検索せずに答えられる。
一度に1つのリクエストを扱うなら、手動ループはこれらのほとんどを自然に満たします。チーム全体で複数のエージェントを動かすなら、Sharklyがそれらのタスクと結果を管理する1つの場所を提供します。Sharklyをダウンロードして、チャンネル全体をそれに委ねる前に、実際のチャットリクエストを1つTaskに移してみてください。
FAQ
チャットから生まれたタスクを追跡可能にするのにSharklyは必要ですか?いいえ。1人の開発者が1つのエージェントを動かすなら、worktreeとIssueにリンクするプルリクエストで本物の追跡可能性が得られます。AIエージェントの受信箱パターンがその価値を発揮するのは、複数のエージェントや人がいて、手動のリンクが綻び始めてからです。
チャットメッセージがコーディングエージェントにとって実行しにくいのはなぜですか?通常、再現手順、期待される結果、受け入れテストが欠けているからです。「エクスポートが壊れてる」を「CSVエクスポートで最後の行が落ちる。期待はN行、実際はN-1行。件数が一致すれば修正済み」に変えましょう。これでAgentが完了判定できる対象ができます。
通常のチケットシステムとはどう違うのですか?チケットは人間が行う作業を追跡します。追跡可能なコードタスクはさらに、Agentの実行ログ、その独立した実行、リンクされたdiffも保持するので、記録が決定と変更の両方をカバーします。人がどこでループに入り続けるかについては、human-in-the-loopコーディングエージェントをご覧ください。
Sharklyは私のSlackチャンネルを直接読めますか?Sharkly AgentをSlackに接続すれば、メンションがTaskになります。会話はSlackに残り、追跡可能な作業記録はSharklyに存在します。
