多くのマルチエージェントワークフローにおいて、破綻が生じるのは難易度の高い作業の最中ではありません。エージェントはコードを書き、テストを実行し、プルリクエストを作成するところまでは問題なくこなします。失敗するのは「継ぎ目（シーム）」、つまりあるエージェントから別の誰か（あるいは別のエージェント）へ作業を引き渡すべき瞬間です。バックエンドエージェントがエンドポイントの実装を終えても、フロントエンドエージェントにはその準備が整ったことが伝わりません。リファクタリングのコミットがワークツリーに反映され、テストがパス（グリーン）したまま放置される――誰も確認を依頼されていないからです。破綻したのはタスクそのものではなく、「ハンドオフ（引き継ぎ）」だったのです。
AIエージェントのハンドオフとは、作業成果物とそのコンテキスト（背景情報）を、ある作業者から次の作業者へ引き渡すことを指します。これは「エージェント間」、あるいは「エージェントから人間へ」行われます。単一のターミナルで1つのコーディングエージェントだけを動かしている場合、ハンドオフは存在しないため意識されることはありません。しかし、エージェントを2つ動かしたり、1つのエージェントと1人のレビュアーを組み合わせたりした瞬間から、完了した各工程を次の作業者が確実に見つけられる場所に届けなければならなくなります。この「引き渡し場所（着地点）」をどう設計するかが、成否のすべてを握っています。
本記事では、実践で機能するハンドオフのパターンを解説します。具体例として、コーディングエージェントの上位レイヤーとして機能し、リクエストからリリースに至るコンテキスト、進捗、ブロッカー、成果、そして人間によるレビューを一貫して可視化し続けるワークフローツールSharklyを取り上げます。コーディングエージェント自体はすでに手元にあるはずです。この記事が解決するのは、それらのエージェントの「隙間」で生じる問題です。
要約
ハンドオフとは、作業とそのコンテキストが次の作業者へと移るプロセスのことです。「エージェント間ハンドオフ」では完了したサブタスクを次のエージェントに渡し、「エージェントから人間へのハンドオフ」では自律的な作業をレビューゲートで一時停止させます。この両方をステータスによって明確に管理しましょう。エージェントはタスクを「レビュー準備完了（Ready for review）」へ移動し、人間はそれを「完了（Done）」へ移動します。ハンドオフをターミナル内のメッセージではなく、共有タスク上のステータス変更として扱うことで、作業が人知れず放置される事態を防ぐことができます。
エージェントハンドオフとは何か
ハンドオフは3つの要素で構成されており、そのいずれか1つでも欠けると作業が見失われてしまいます。その3つとは、「成果物（差分、PR、マイグレーションなど）」、「コンテキスト（何を求められ、何が変更され、何がまだ未確定なのか）」、そして「受取人（次のステップを担当する特定のエージェントまたは人間）」です。
ターミナルベースのワークフローでは成果物こそ引き継がれるものの、残りの2つが失われてしまいます。コミットは残っていても、その判断理由は単一のエージェントだけが見ていたスクロールバックバッファの中に消え、「次は誰の番か」はたまたま画面を確認した人任せになります。エージェントのオーケストレーションにおいて、本質的に重要なのがエージェントを起動すること自体ではなく、エージェントが生み出した成果物をいかにルーティングするかである理由はここにあります。
クリーンなハンドオフとは、変更内容、対応したこと・しなかったことの要約、そして受取人に順番が回ってきたことを示す明確なシグナルの3つを同時に引き渡すことです。Sharklyで言えば、実行内容、ブロッカー、成果、フォローアップの議論がすべてタスクのタイムラインに集約されるため、次の作業者は3つの情報を個別に掘り起こすことなく、1つの記録を確認するだけで全体像を把握できます。
2つのハンドオフパターン
この2つのパターンは外見上よく似ていますが、デフォルトの挙動は正反対です。「エージェント間ハンドオフ」は自動的に流れるべきであり、次のエージェントが準備完了となったサブタスクを引き受けて作業を続行します。一方、「エージェントから人間へのハンドオフ」はデフォルトで停止すべきです。人間による意思決定が必要となるため、エージェントは自身の担当範囲を完了した時点で待機します。
| エージェント間 | エージェントから人間 | |
|---|---|---|
| トリガー | サブタスクが準備完了（Ready）になる | 作業がレビューゲートに到達する |
| デフォルトの挙動 | 自動的に続行 | 停止して待機 |
| 引き渡す内容 | 成果物 + コンテキスト + 受入条件 | 差分 + 変更の要約 + 既知の制約事項 |
| 欠落時のリスク | 作業の重複や競合 | 未レビューのコードが無検証でマージされる |
判断を誤らないための指針は明確です。次のステップが明確に定義され、受入条件がすでに文書化されている場合（「テストスイートの実行」「マイグレーションの生成」「OpenAPI仕様の更新」など）は、エージェント間のハンドオフを自動化します。一方、エージェント自身には判断の責任が負えない場合（mainブランチへのマージ、公開API契約の変更、認証や決済処理の変更、成果物の完了承認など）は、強制的にエージェントから人間へのハンドオフを行います。
よくある過ちは、すべてのハンドオフを一律に扱ってしまうことです。すべてを自動化すれば未検証の作業がマージされてしまいますし、すべてに承認ゲートを設ければ、単に手間が増えただけの遅い手動パイプラインを再現することになります。これは、些細なステップごとに毎回止めるのではなく、致命的なミスの手前で確実にエージェントを止めるために承認ゲートをどこに配置すべきかを把握することと直結しています。
ステータスによってハンドオフを「期待」ではなく「ゲート」にする
運用モデルの本質は、4つの動詞とそれぞれの主体の関係に集約されます。誰が「割り当て」、誰が「実行し」、誰が「レビューし」、誰が「承認する」のか。エージェントは調査、実行、テスト、報告を担当します。人間は方向性の指示、権限の付与、そして成果物の承認を担当します。チームとしての判断が必要な境界で、自動化は停止します。
この取り決めを単なる理念で終わらせず、機械的な仕組みとして定着させるのが「ステータス」です。すべてのタスクは同じレーンに沿って進みます。
- Todo（未着手）：割り当て済みで、未着手の状態。人間またはリーダーエージェントがここにタスクを配置します。
- In progress（進行中）：エージェントがタスクを引き受け、隔離されたワークツリー内で作業を進めている状態。
- Ready for review（レビュー準備完了）：エージェントの担当境界。型チェック、テスト、ビルドを実行し、変更の要約と既知の制約事項を添付した上で作業を停止した状態。
- Done（完了）：人間の担当境界。成果物を承認し、マージおよびリリースの意思決定を行った状態。
システム全体を明快に保つ鉄則は、「エージェントはタスクをReady for reviewに動かし、人間がDoneに動かす」ということです。エージェントが自らの作業を勝手にDoneにすることはなく、人間もテストが通過したタスクが本当に安全かどうかを推測する必要がありません。ステータス変更そのものがハンドオフなのです。10個のエージェントが同時に稼働していても、10個のターミナルを逐一監視する必要はありません。ボードを見るだけで、自分自身の確認待ちのもの、別のエージェントの処理待ちのもの、そして現在実行中のものを正確に把握できます。この可視性こそが、エージェントが完了した作業を確実に追跡できている状態と、後からコミットログを見て経緯を読み解けるよう祈るだけの状態との決定的な違いです。
実践例：チケットからPRマージまでの流れ
実際の開発現場を想定したタスク「SH-312：公開APIへのレート制限の追加」を例に考えてみましょう。コードそのものではなく、ハンドオフの流れに着目してください。
まず人間が自然言語で要件を記述し、タスクを割り当てます。リーダーエージェントがコードベースや過去のタスク履歴を調査し、スコープと受入条件（APIキーごとの制限、Retry-Afterヘッダーを伴う429応答、アクセス頻度の高い上位3つのエンドポイントの対応など）を策定した上で、SH-312を実行可能な3つのサブタスクに分割します。これが最初の「エージェント間ハンドオフ」です。目標がインプットされ、準備完了状態のサブタスクがアウトプットされます。
分割されたサブタスクは自動的に進行します。バックエンドエージェントがレート制限ロジックを引き受け、テストエージェントがテストカバレッジの作成を引き受けます。それぞれが隔離されたワークツリーで動作するため、同じファイルで競合することはなく、各成果物は個別のプライベートセッションではなくSH-312へと集約されます。バックエンドエージェントは処理を完了しても人間に連絡することはせず、自身のサブタスクを準備完了（Ready）とマークします。すると、テストエージェントがスタブではなく実際の実装コードを受け取ってテストを進めます。
ここでハンドオフの種別が切り替わります。レート制限機能が実装され、型チェックがパスし、テストが成功してビルドが通ると、作業は「エージェントから人間へのゲート」に到達します。エージェントはSH-312を「Ready for review」に移動し、差分、変更内容の要約、そして「Redisベースのカウンターは単一リージョンを前提としているため、マルチリージョン対応は追加対応が必要」という既知の制約事項を1点添付します。人間はこれらすべての情報を1か所で確認し、429ステータスの挙動を検証した上でタスクを「Done」へ移動し、それによってマージがトリガーされます。チケットからPRのマージに至るまで、すべての継ぎ目で「誰が何をしたか」が記録されています。これは、要件からコードへのプロセスをエンドツーエンドで追跡可能にするアプローチそのものです。
ハンドオフが破綻する原因とその防止策
ハンドオフが失敗するパターンには予測可能な3つの原因がありますが、いずれに対しても「注意を怠らない」といった精神論ではなく、構造的な解決策が存在します。
コンテキストの消失：エージェントはその選択をした理由を把握していても、レビュアーには伝わりません。解決策：後付けではなく、「Ready for review」への移動プロセスの一環として、変更の要約と既知の制約事項をハンドオフ情報に含めるようにします。担当の曖昧化：2つのエージェントが同じ作業を取り合ったり、逆にどちらも着手しなかったりします。解決策：すべてのタスクとサブタスクに担当者（Assignee）を設定し、「次は誰の番か」を雰囲気ではなくフィールドとして明確に管理します。レビューの不実施：止めるよう指示されていなかったため、自律的に進められた作業が無検証でマージされてしまいます。解決策：エージェント単独では遷移できないステータスを設けます。
これらはすべて、ワークツリー、命名規則、そして徹底した規律によって手動で構築することも可能です。しかし、エージェント、タスク、リポジトリの数が増加すると、真っ先に崩壊するのはその規律です。すでに複数のエージェントを運用しているなら、Sharklyを使えばタスクと成果物を一元管理できます。共有タスク、タスクごとの担当者設定、隔離されたワークツリー、そして「エージェントはReady for reviewまで進め、人間がDoneを判断する」ステータスレーンが用意されています。現在利用しているコーディングエージェントはそのままに、ハンドオフを可視化するレイヤーを追加しましょう。エージェント間の継ぎ目の調整コストが作業そのもののコストを上回り始めたら、ぜひSharklyをダウンロードしてみてください。
FAQ（よくある質問）
AIエージェントのハンドオフとは何ですか？ タスクを、そのコンテキストおよび「次は別の作業者の番である」というシグナルとともに、ある作業者から次の作業者へ引き渡すことです。形態としては「エージェント間」（完了したサブタスクが次のエージェントに渡る）と「エージェントから人間」（自律作業がレビューゲートで一時停止する）の2種類があります。
エージェント間ハンドオフとエージェントから人間へのハンドオフの違いは何ですか？ エージェント間ハンドオフは、次のステップの受入条件がすでに定義されている場合、自動的に継続されるべきです。一方、エージェントから人間へのハンドオフは、マージの可否、公開API契約の変更、成果物の承認など、人間による判断が不可欠であるため、一時停止して待機する必要があります。
エージェント自身が自分の作業を完了（Done）にしてもよいですか？ いいえ、避けるべきです。エージェントにはテストの実行と要約の添付を行わせた上で、タスクを「Ready for review」へ移動させるにとどめ、「Done」への移動およびマージの決定権は人間に委ねるようにします。この2つの境界を分離することが、未レビューのコードがリリースされるのを防ぐ鍵となります。詳細はHuman-in-the-Loop コーディングエージェントを参照してください。
ステータスによって作業の取りこぼしをどのように防げるのですか？ ハンドオフをターミナル内のメッセージではなく共有タスク上のステータス変更として行えば、次の作業者は何が自分の対応待ちなのかを正確に把握できます。適切なタイミングで誰かがターミナルのスクロール履歴を見ているかどうかに頼る必要がなくなります。エージェントInboxを使えば、対応が必要なアイテムを自動で可視化できます。
これには専用のツールが必要ですか、それとも手動で運用できますか？ ワークツリーと共有ボードを使えば手動でも運用可能です。しかし、複数のリポジトリにまたがって複数のエージェントを連携させるようになり、手動での追跡がボトルネックになってくると、専用の管理レイヤーを導入する価値が十分に高まります。判断の基準として、「アシスタント」と「チームメイト」のメンタルモデルの比較も参考にしてください。
