目次
背景
- 複雑なタスクをAIエージェントにやらせていると、1つのAgentのコンテキストだけでは終わらないことがある
- そのときは、新しいAgent（Sub Agent）を立てて作業を引き継ぐことになる
- しかし、Sub Agentはそれまでの経緯を理解していない。普通に「続きをやって」と伝えても、前提を誤解したまま進めてしまうことがある
- そこで、業務改善やシステム導入のコンサルティングでよく使われるAsIs/ToBe/GAP分析のフレームワークを、Agent間の引き継ぎに応用してみた
- 結果として、Sub Agentが段階的に正しく理解してくれるようになったので、そのやり方を整理する
AsIs/ToBe/GAP分析とは
- もともとは、業務プロセスやシステムの改善で使われる3段階の分析手法
- それぞれの段階には、着眼点・やること・手法・ゴールがある
| 段階 | 着眼点 | やること | 手法 | ゴール |
|---|---|---|---|---|
| AsIs（現状） | 今実際に何が起きているかを、判断を交えずに捉える | 現行のワークフロー・手作業・引き継ぎ・ボトルネック・レガシーなツール・痛点を文書化する | 現場へのインタビュー、観察、既存ドキュメントのレビュー、プロセスマッピング | 症状ではなく根本原因を診断するための、業務の正直なベースラインを作る |
| ToBe（あるべき姿） | 将来どうあるべきかを描く | プロセスの再設計・最適化、重複の削減、新しい技術や自動化の統合 | 創造的なワークショップ、戦略的なブレインストーミング、プロセス・アプリケーション・インフラの各層をまたいだ再設計 | 事業の成長目標に沿った、実用的で無駄のないモデルを作る |
| GAP（差分） | AsIsとToBeの差分 | 現在の能力と目標要件を比較し、何が足りないかを洗い出す | AsIsとToBeの突き合わせ、優先順位づけ | ビジネスインパクト・技術的な複雑さ・運用リスクで優先順位づけされた、段階的な移行ロードマップを作る |
- 現状とあるべき姿を分けて定義したうえで、その差分として課題を定義するため、「何が問題なのか」を曖昧にしないという効果がある
Agentの引き継ぎへの応用
- このフレームワークを、Main Agent（これまでの経緯を把握している、元のAgent）からSub Agent（新しく立てる、引き継ぎ先のAgent）への引き継ぎに当てはめた
- ポイントは、Sub Agentに分析結果をMarkdownのレポートとしてまとめさせ、各段階でMain Agentに「理解が正しいか」を確認してもらうこと
- 上の表の「手法」列も、Agentの文脈に置き換えられる
- AsIsの「インタビュー・観察・ドキュメントレビュー」は、Sub Agentにとっての「これまでの会話ログ・コードベース・コミット履歴を読むこと」に対応する
- ToBeの「ワークショップ・ブレインストーミング」は、Sub Agentが要件や過去のやり取りから目指す姿を自分なりに言語化する作業に対応する
- GAPの「AsIsとToBeの突き合わせ」は、そのまま両方のMarkdownを比較して課題を洗い出す作業になる
AsIsのまとめ
- Sub Agentに、これまでの経緯（現状）を1つのMarkdownレポートにまとめてもらう
- それをMain Agentに渡し、理解が正しいかを確認してもらう
- Main AgentがApprovedを出すまで、ずれている点を指摘してSub Agentに修正させる。承認が出るまでは次のステップに進まない
ToBeのまとめ
- 次に、Sub AgentにToBe（あるべき姿、目指す姿）の分析をしてもらい、同様にMarkdownにまとめる
- これもMain Agentに見せて、Approvedが出るまで修正を繰り返す
GAPの抽出
AsIsとToBeの差分（GAP）をSub Agentに抽出させ、課題としてMarkdownにまとめてもらう
これが、実際に解決すべき課題のリストになる
最後にもう一度Main AgentにApprovedをもらい、これを土台にして実際の作業を進めてもらう
各ステップで「とりあえず進める」ことはせず、Main AgentがApprovedを出すまでは次に進まないのがポイント。ここを曖昧にすると、結局どこかの段階で誤解が残ったまま作業に入ってしまう
flowchart TD
Start[Sub Agent起動] --> AsIs[Sub Agent: AsIs.md作成]
AsIs --> AsIsCheck{Main Agent承認?}
AsIsCheck -->|No: 修正| AsIs
AsIsCheck -->|Yes| ToBe[Sub Agent: ToBe.md作成]
ToBe --> ToBeCheck{Main Agent承認?}
ToBeCheck -->|No: 修正| ToBe
ToBeCheck -->|Yes| Gap[Sub Agent: GAP.md作成]
Gap --> GapCheck{Main Agent承認?}
GapCheck -->|No: 修正| Gap
GapCheck -->|Yes| Work[Sub Agent: 作業に着手]やってみてどうだったか
- このプロセスを挟むと、Sub Agentが前提を誤解したまま作業を進めてしまうケースが減った
- 一度に全部説明するのではなく、AsIs→ToBe→GAPと段階を分けて確認することで、どこで理解がずれているのかが分かりやすくなる
- 各ステップをMarkdownという共有しやすい形に落とすことで、Agent同士だけでなく、人間が途中のレポートを読んでチェックすることも簡単になる
- 特に効果を感じたのは、Sub Agentが受け取った情報を自分の言葉でAsIsとして再構成する過程そのものが、理解確認のテストになっていたこと
- 単に「わかりました」と返すのではなく、文書として現状を再現させることで、理解していないところが自然と浮き上がってくる
なぜこれがうまくいくのか
- Main Agentが都度チェックすることで、Sub Agentの誤解を早い段階で検出できる
- これは、人間のチームでタスクを引き継ぐときに、相手の理解を確認してから進めるのと同じ考え方
- AsIs/ToBe/GAPという3段階に分けることで、確認すべきポイントが「現状の理解」「目指す姿の理解」「課題の理解」と明確に切り分けられる
- 1段階ずつ確認するため、どこで理解がずれたのかを特定しやすく、誤解を引き継いだまま先に進んでしまうリスクを抑えられる
まとめ
- 複雑なタスクをAgent間で引き継ぐとき、AsIs/ToBe/GAP分析のフレームワークを使うと、Sub Agentの理解を段階的に確認できる
- Sub AgentにAsIs・ToBe・GAPそれぞれをMarkdownレポートとしてまとめさせ、各段階でMain Agentに確認してもらう、という流れ
- 理解を一度にまとめて確認するのではなく、現状・あるべき姿・課題という3段階に分けて確認することで、誤解を早期に検出できる
- Agent同士の引き継ぎだけでなく、人間とAgentの間の認識合わせにも応用できそうな考え方