Human ⇄ Agent · 引き継ぎとレビュー

人とAIエージェントの引き継ぎとレビュー

次の担当が迷わず続けられるように、誰の作業か、何を変更し、どこまで確認し、どの判断が残っているかを渡す。GuilduoはQuestに作業記録と人の指摘を残し、外部のコーディングツールで進む仕事の引き継ぎを支えます。

「修正した」の先に、引き継ぐ情報がある

AIエージェントから「直しました」と返ってきても、何が未確認か分からないことがあります。人が別のチャットで指摘すると、次の作業セッションには判断が伝わらないこともあります。引き継ぎには、元の目的、担当、進捗、検証根拠、次にすることを一緒に残す必要があります。

GuilduoのQuestは仕事の記録、Handoffは引き継ぎの状態です。Agent登録で保存するのは役割と権限の設定であり、モデルは起動しません。担当の割り当てや状態変更も実行を開始しません。接続したCodexやClaudeなどの外部環境で、エージェントが明示的にQuestを読み、作業を進めます。

エージェントSDKの「handoff」は、実行中のランタイムで別のエージェントへ処理を渡す意味で使われることがあります。Guilduoの永続化されたHandoffは、担当責任とレビューの文脈を記録するものです。実行中のモデルセッションや、その内部の文脈を移す機能ではありません。

作業を渡し、判断を読み直して続ける

目的と担当を決める。 対象、制約、完了条件をQuestに書きます。現在のQuestと登録Agentを読み、assign_quest_to_agentでプレビュー。許可された変更を最新のexpectedUpdatedAtで保存します。
接続先で作業する。 エージェントはQuestを読み、workingを記録して外部ツールで修正・検証します。結果の要点、根拠の場所、残る確認を保存し、review_requiredでレビューへ返します。進められないときはブロック理由と再開条件を残します。
人に具体的な確認を依頼する。 list_human_requestsで既存依頼を確認します。理由、確認対象、完了条件を指定してrequest_human_reviewをプレビューし、最新のexpectedUpdatedAtで保存。元Questとは別の確認Questが作られます。
本人が回答を保存する。 指定された人が外部の成果物や実機を確認し、Web認証を通して結果とテキストの指摘を保存します。リンクを開いたこと、既読、保留は、回答とは別です。
回答を読んでから再開する。 エージェントにlist_human_requestsを読み直させ、humanRequest.responseとoutcomeを確認します。changes_requestedなら指摘に沿って修正・再検証。approvedなら承認範囲を確認して仕事を閉じます。

保存された状態と、次に明示的に行うこと
Handoff状態	意味	次の操作
`working`	作業中。	外部クライアントで修正と検証を行う。
`blocked`	作業を続けられない。	理由を残し、解消後に再開する。
`review_required`	人のレビューへ返した。	結果と残る確認を読む。
`accepted`	Handoffが承認された。	元Questの完了を別に確認する。

人の回答、確認Questの完了、Handoffの承認、元Questの完了には、それぞれ別の条件と操作があります。承認が保存されても、元の仕事が自動で完了するわけではありません。

例：スマホメニューを直し、使い心地をレビューする

以下のタスクと指摘は説明用の架空例です。実際の顧客事例や、実機検証を完了した証拠ではありません。

元Quest：「スマホのメニューを直し、すべてのリンクを使えて、片手で閉じられるようにする。PCのナビゲーションは変えない。変更ファイル、実行したチェック、残る実機確認を返す。」これで、エージェントに期待する結果と変更範囲が伝わります。

エージェントは外部のコーディングツールで修正し、実際に行ったチェックを報告します。自動チェックで画面幅に応じた挙動を確認できても、親指の届きやすさは本人の判断が必要です。確認依頼では「普段のスマホでメニューを開閉し、リンクを試す。変更不要、または変える要素と理由を回答する」と頼みます。

人は外部のプレビューを確認し、changes_requestedと「リンクは使えるが、閉じるボタンに親指が届きにくい。ラベルを保ったまま下へ移してほしい」という指摘を保存します。エージェントは保存済みの回答を明示的に読み、Handoffをworkingへ戻して指摘を反映します。

もう一度レビューするなら、新しいrequestKeyを使い、以前の回答は残します。人がapprovedを保存した後も、残る完了条件を確認し、Handoff承認と元Quest完了を別の操作として行います。

向いている仕事と、任せきれない範囲

作業が複数のセッションにまたがるとき、担当が変わるとき、実機の挙動や好みに人の判断が必要なときに向いています。次の担当が、済んだチェックと推測を区別できる根拠を残します。エージェント自身で実行できる通常のlint確認なら、人への依頼は不要です。

Guilduoはモデルの実行環境ではなく、別のエージェントの起動を保証するものでもありません。接続先での明示的な読み取りと再開を手順に含めてください。実行権限はOAuthの許可とAgentポリシーの共通部分で決まり、登録や接続の紐付けだけでは拡張されません。

タスク例、共有ログ、成果物URLに認証情報や個人情報を含めないでください。エージェントは通常のQuest更新で本人の回答を代行できません。対応する変更はプレビューし、Handoff遷移には現在のexpectedStateを使います。競合したら最新の内容を読み直します。

ひとつの仕事と、ひとつの確認から始める

Agent登録とHandoffでAgentを登録し、コーディングクライアントを紐付けます。続いてHuman Relayで確認依頼と回答の読み取りを進めます。書き込み前に認証と権限も確認。まずは双方が完了条件を確認できる小さなタスクで、一往復を試してください。

公開資料と内容確認日

内容確認日：2026年10月6日。公開ソースrevision 42caab0fa1f396f15e4e1277f6e36dda1ac9bd04を根拠に編集しています。

public-docs/content.json：Agent、Human Relay、Permissionsの記事。指摘の保存、外部環境での実行、各完了操作の区別。
api/mcp-tools.json：担当割り当て、Handoff遷移、人への確認依頼、回答読み取りの契約。