“1つのエージェントに全部やらせる“のをやめた理由 - Copilotエージェント設計の実践 -

2026年7月10日にエンジニアカフェ福岡で開催された、「AI駆動開発勉強会 福岡出張版+ EnjoyAIDeveloping　〜AIエージェント Hands-on with Oikonさん〜」でのLT資料です。

https://enjoy-dev-ai.connpass.com/event/397844/

AIエージェントは1つのエージェントで何でもやらせず、オーケストレータパターンにするとコンテキスト汚染が減って精度が上がる、内容に応じて小さなモデルを使うことで利用料を最適化できるといったことをお話ししました。

Transcript

1. “1つのエージェントに全部やらせる“のをやめた理由 - Copilotエージェント設計の実践 - 2026/07/10 AI駆動開発勉強会 福岡出張版+ EnjoyAIDeveloping 株式会社オルターブース クラウドソリューション部 木村健一郎 Copyright © Alterbooth Inc. All Rights Reserved. 1
2. 自己紹介 株式会社オルターブース クラウドソリューション部 副部長 木村 健一郎(Kenichiro KIMURA) 大学院在籍中に未踏ソフトウェア創造事業に 採択され、その成果を元に設立したスタート アップに20年在籍。 2014年頃からクラウドの世界に触れる中で サーバレスとIoTに魅せられ、JAWS-UG福岡 やSORACOM UG九州のコアメンバーとして コミュニティ活動を行っている。 2020年にオルターブースにジョイン。テッ クリードとしてお客様の支援やプロダクトの 開発に従事している。 家に帰ると8歳の娘と戯れる日々。 AWS Samurai2019受賞 AWS APJ Community Award 2023受賞 SORACOM MVC2020/2023受賞 Copyright © Alterbooth Inc. All Rights Reserved. 2
3. 出発点：全部入りの巨大カスタムプロンプト 1年前にスタートしたプロジェクトを、初手からAI駆動で進めることを決意。 レビューで疲弊してる自分にすぐに気がついた • コードレビューの観点をすべて1つのカスタムプロンプトに記述 • 「これ1本」でレビューを完結させるシンプルな構成 • 一次レビューをまかせることで負荷が激減 • チームメンバーはカスタムプロンプトのレビューとGitHub CodeReviewを通した後で私にレビューを依頼する • 私の視点のレビューはほぼ終わってるので、レビュー負荷が激減 Copyright © Alterbooth Inc. All Rights Reserved. 3
4. プロジェクトを進める中で課題が顕在化 • 動作速度 ― プロンプトが巨大で、完了までに時間がかかる • 精度 ― 観点を詰め込みすぎて指示が薄まり、見落としが発生 • アーキテクチャ、コードクオリティ、エラーハンドリング、パフォーマンス、セキュリティ、テストの6観点をプ ロンプトに入れた • 観点の間で衝突したときの不整合 • トークン使用量 ― 直近は特にコスト面の問題が深刻になってきた Copyright © Alterbooth Inc. All Rights Reserved. 4
5. 解決策：エージェントとサブエージェントへ分離 • 巨大プロンプトを分割し、役割ごとに再構成 • 観点を分けたサブエージェントが、それぞれの観点でレビューを担当 • 各観点に集中させることでレビュー精度が向上し、成果が上がった Copyright © Alterbooth Inc. All Rights Reserved. 5
6. 全体構成：レビューオーケストレータが観点ごとのサ ブエージェントを呼ぶ オーケストレータ（全体を統合） 観点別サブエージェント セキュリティは中価格モデル 観点別サブエージェント コーディングスタイルは低価格モデル 観点別サブエージェント アーキテクチャは中価格モデル 軽量モデルのサブタスク：コード内容の取得などを分離 → 出力を抑えてトークンコストを最適化 Copyright © Alterbooth Inc. All Rights Reserved. 6
7. コスト最適化①：中価格モデルのサブエージェントへ の処理委譲 • コード内容の取得/要約などのタスクを、中価格モデルのサブタスクへ委譲して全体のトークン使用量（＝価格）を抑 制 • ポイント1：自身より高額なモデルをサブエージェントとして呼べない＝オーケストレータは高価格モデルになる • ポイント2：モデルの価格は入力より出力が約10倍高い • 重量モデルであるオーケストレータの作業量と出力トークン数を減らす Copyright © Alterbooth Inc. All Rights Reserved. 7 オーケストレータがコンテキストを取得する場合：高コスト オーケストレータ 高価格モデルが自分でgit diff実行 大量のコンテキスト サブエージェント 高価格モデルが大量の入出力を処理 → コスト大 コンテキスト取得をサブタスクに委譲：低コスト オーケストレータ 高価格モデルは指示だけを出す 入出力が多い取得処理は低価格モデルが担当 → コスト小 サブエージェント 低価格モデルがgit diff実行 プロン プト のみ
8. コスト最適化②：低価格モデルへのタスク分割 • さらにコンテキスト取得処理を低価格モデルへ分離し、要約したコンテキストをサブエージェントに渡す • コンテキストが大きい場合は ② ＜ ① になる可能性がある • 例)巨大なdiffを含むコードレビュー Copyright © Alterbooth Inc. All Rights Reserved. 8 分割しない場合：コンテキスト量が多いと高コスト オーケストレータ 高価格モデルが自分でgit diff実行 サブエージェント 低価格モデルがgit diff実行 中価格モデルが大量の入出力を処理 → コスト大 サブタスク分割：コンテキストを圧縮できれば低コスト オーケストレータ 高価格モデルが要約したコンテキストを出す コンテキスト取得・要約専用 サブエージェント（低価格モデル） 重い取得処理は低価格モデルが担当 → コスト小 サブエージェント ② 要約した コンテキスト プロン プト のみ ①
9. コスト最適化③：nested subagent • コンテキスト取得専用サブエージェントを、サブエージェントから呼ぶ • Nested subagent(サブエージェントからサブエージェントを呼ぶ) • コンテキスト量に依存せず、全体のトークン使用量（＝価格）を抑制 • ポイント：nested subagentはデフォルトではオフ • VSCodeの設定でchat.subagents.allowInvocationsFromSubagents をtrueにする Copyright © Alterbooth Inc. All Rights Reserved. 9 Nested subagent未使用：コンテキストが小さいと高コスト コンテキストが大きいと、要約のメリットがあまり出ない→ コスト大 Nested subagentを使用：コンテキスト量に依らず低コスト オーケストレータ 高価格モデルは指示だけを出す コンテキスト取得専用 サブエージェント（低価格モデル） 高価格モデルが要約を取り扱わない → 要約の量に依らずコスト小 サブエージェント プロン プト のみ オーケストレータ 高価格モデルが要約したコンテキストを出す コンテキスト取得・要約専用 サブエージェント（低価格モデル） サブエージェント 要約した コンテキスト
10. エージェントデバッグログで見てみた Copyright © Alterbooth Inc. All Rights Reserved. 10 サブエージェントに分岐している サブエージェントから サブエージェントが呼ばれてる
11. まとめ • 「全部入り」1エージェントは速度・精度・コストで限界。観点ごとに分離して精度と成果が 向上 • 低価格モデルの使い分けでトークンコストを最適化（出力は入力の約10倍） • Nested subagentを活用。多段化はセッション長時間化に注意（VSCodeは停止しがち、 Copilot CLIも選択肢） • 差分が大きいなら最適化②が有効 • まだ実験中なので、ぜひ知見を教えてください Copyright © Alterbooth Inc. All Rights Reserved. 12