shokai subagent 相談手順書
概要
相談先Agent（subagent）にセカンドオピニオンを求め、その結果を要約してユーザーに報告する。 ユーザーはsubagentの生出力を直接見る必要はない。相談元Agentがsubagentの回答を咀嚼し、自分の見解と照らし合わせて報告する。
登場人物
本手順には3者が登場する:
- ユーザー: 相談を依頼する人間
- 相談元Agent: この手順を実行しているAgent自身。ユーザーからの要請を受けて相談先Agentと相談し、結果をユーザーに報告する
- 相談先Agent（subagent）: Agentツールで起動されるsubagent。セカンドオピニオンを提供する
ユーザーへの報告時、見出しに自分のAgent名を使うこと（例: 「Claude Codeの見解」「Clineの見解」等）。
1. 相談の深さの確認
ユーザーが相談の深さを明示していない場合（「全力で」「深く」「よく」「軽く」等の指定がない場合）、 AskUserQuestionツールで以下の3択を提示する:
| 選択肢 | 往復回数 | 相談元Agentの仮見解 | 漏れ抜けの追求度 |
|---|---|---|---|
| よく相談する（推奨） | 必要に応じて2往復 | 相談元Agentが判断 | 漏れ抜けを確認して報告 |
| 全力で深く相談する | 2往復を原則実施（明らかに不要な場合のみスキップ） | 必ず含め、subagentに反論を促す | 積極的に反論・補完・追加追求 |
| 軽く相談する | 1往復のみ | 相談元Agentが判断 | subagentの指摘を整理して報告 |
ユーザーが明示的に深さを指定している場合はこの確認を省略し、指定に従う。
2. プロンプトの設計
subagentに渡すプロンプトを相談元Agentが設計する。以下の指針に従う:
プロンプト設計の指針
- 会話のコンテキストから「今何について相談すべきか」を判断する
- ユーザーが明示的にテーマを指定している場合はそれに従う
- 指定がない場合は、直前の議論や作業内容から適切なテーマを選ぶ
コンテキスト別のプロンプト例
未commitの変更をレビューしたいとき
「このリポジトリの未commitの変更をレビューしてください。コードの品質、設計の妥当性、潜在的なバグ、改善点を指摘してください。」
設計について相談したいとき
「以下の設計について意見をください。[設計の要約]。代替案やトレードオフがあれば提案してください。」
実装方針を相談したいとき
「[タスクの要約]を実装したい。このリポジトリのコードベースを踏まえて、最適な実装方針を提案してください。」
プロンプトの構成
- プロジェクトの背景（簡潔に）
- 相談したい具体的な内容
- 相談元Agentの現時点での仮見解（状況に応じて含める。「全力」モードでは必ず含める）
- 指定観点以外も幅広く探索するよう依頼（常に含める）
- 動作中のmodel IDの申告依頼（常に含める）
相談元Agentの仮見解を含める場合のテンプレート
なお相談元Agent（[自分のAgent名]）は現時点で以下のように考えている:
- [仮見解]
この見解の漏れ・誤りも含めて、幅広くレビューしてほしい。
指定した観点以外にも気になる点があれば積極的に報告してほしい。
幅広い探索の依頼（常にプロンプトに含める）
指定された観点はあくまで出発点であり、制約ではない。 リポジトリを自分で探索して気になる点があれば積極的に報告してほしい、という旨を必ずプロンプトに含める。
model IDの申告依頼（常にプロンプトに含める）
回答の末尾に model: <ID> の形式で動作中のmodel IDを1行記載するよう依頼する。
3. subagentの実行
Agentツールで以下の形式でsubagentを起動する:
prompt: セクション2で設計したプロンプトdescription: 相談内容を3-5語で要約したもの
追加往復の判断
「全力」モードでは、1往復目の結果を受け取った後、2往復目を原則実施する。明らかに追加の深掘りが不要な場合（1往復目で十分網羅的な回答が得られた場合）のみスキップする。
「よく」モードでは、1往復目の結果を受け取った後、以下のいずれかに該当する場合は2往復目を実施する:
- さらに深掘りすべき重要なポイントがsubagentの指摘に含まれている
- subagentの指摘に相談元Agentが反論・補完したいことがある
- 十分に探索されていない領域があると相談元Agentが判断できる
2往復目を判断する前に、1往復目の出力に実行失敗の兆候がないか確認する。失敗を検知した場合は、まず相談元Agentが正しい情報を取得・補正してから2往復目の要否を判断する（詳細はセクション4「subagentの実行失敗を検知した場合」を参照）。
2往復目のプロンプト構成:
注意: Agentツールは単発実行のため、2往復目のsubagentは1往復目の記憶を持っていない。最初から文脈を全て含める必要がある。
- 元の相談内容の再提示（背景/目的/制約/評価観点を落とさず構造化して含める）
- 1往復目のsubagentの回答サマリー
- 相談元Agentの反論・補完・追加質問
- さらに掘り下げてほしい観点
往復は原則2回まで。3回以上はユーザーに確認してから実施する。
4. 結果の要約と報告
subagentの出力を読み取り、以下の構成でユーザーに報告する:
報告の構成
subagentへの相談内容
subagentの実行環境を subagent (claude-fable-5-1) の形式で1行記載し、続けてsubagentに送ったプロンプトの概要を1-2文で説明する。
subagentの回答サマリー
subagentの主な指摘・提案を箇条書きで要約する。
[自分のAgent名]の見解
- subagentの指摘のうち、同意するもの
- subagentの指摘のうち、異なる意見を持つもの（理由付き）
- subagentが見落としていると考えるポイント
- 2往復目を実施した場合は、その理由と2往復目で何が明らかになったか
見解の姿勢:
- subagentの指摘を安易に受け入れない。相談元Agentとして検証を試みてから報告する
- subagentが探索しなかった可能性がある領域を意識的に探す
- subagentと相談元Agentの見解が食い違う場合は、その食い違いを価値ある情報として積極的に伝える
次のアクション提案
ユーザーと相談すべき事項や、推奨する次のステップを示す。
報告のスタイル
- 簡潔にまとめる。冗長な引用は避ける
- subagentと相談元Agentの見解が異なる場合は、両方の理由を説明してユーザーが判断できるようにする
- ユーザーが次に何をすべきか明確にする
subagentの実行失敗を検知した場合
subagentの出力を読む際、実行失敗の兆候がないか注意深く確認する。 兆候の例: エラーメッセージ、「取得できなかった」「失敗した」「permission denied」「not found」など。
失敗を検知した場合は、以下の手順に従う:
- まず、相談元Agentが正しい情報を自分で取得する。subagentが失敗したコマンド（例:
gh pr view）をBashツールで実行し、結果を確認する - 次に、取得した情報でsubagentの分析を補正する。情報不足で的外れになった指摘を特定し、正しい文脈で再評価する
- 最後に、報告の見解セクションで情報不足を明示する。欠落情報と、その影響を受けた指摘を具体的に説明する
5. 改善提案
subagentが何らかの失敗をしたパターンを認識したら、次回以降の改善策をユーザーに進言する。