マルチエージェント開発の発注に向けて社内検討が進み、いよいよ「要件定義をどう書くか」「どのベンダーに任せるか」という実務の段階に入った。そんなときにこの記事にたどり着いた方も多いのではないでしょうか。
一般的なシステム開発の要件定義なら経験がある。けれど、マルチエージェントシステムは複数のAIが自律的に判断しながら連携するため、「何をもって正しい動作とするか」を定義することすら一筋縄ではいきません。社内にAIアーキテクチャの専任者がいなければ、要件をどこまで詰めればいいのか、どんなベンダーが適任なのか、判断材料を持ちにくいのが実情です。
発注で失敗する企業の多くは、この難しさゆえに要件定義をベンダーに丸投げしてしまい、出来上がったものが期待とずれて作り直しになります。マルチエージェントは自律性が高い分、発注側が主導権を持って要件を握れているかどうかが、そのまま成否を分けます。
本記事では、マルチエージェント開発の発注を進める企業の担当者に向けて、ベンダーに渡せる要件定義の論点、適任ベンダーの見極め方、作り直しを避ける段階的な発注プロセスを、発注実務の目線で解説します。なお、マルチエージェントの定義や単体AIエージェントとの費用・設計の違い、導入が有効なユースケースといった前提知識はマルチエージェントとは？単体AIとの費用・設計の違いで詳しく扱っているため、本記事は「発注を進めると決めた後の実務」に絞って解説します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
マルチエージェントの発注で要件定義が成否を分ける理由
要件定義の具体論に入る前に、なぜマルチエージェントの発注では要件定義がとりわけ重要になるのかを押さえておきます。ここを理解しておくと、後述する論点リストの一つひとつが「なぜ必要なのか」が腑に落ちるはずです。
自律性が高いほど「正しい動作」の定義が難しくなる
通常の業務システムは、入力に対して決められた処理を返します。仕様どおりに動くかどうかは比較的明確に判定できます。
一方マルチエージェントシステムは、複数のAIエージェントがそれぞれ自律的に判断し、状況に応じて動きを変えます。同じ入力でも出力が揺らぐことがあり、「100%正解」を前提にできません。つまり、何をもって「正しく動いた」とみなすのかを発注側が定義できていないと、ベンダーは何を目指して作ればいいのか分からず、検収の段階で「これは期待と違う」という食い違いが噴出します。
AIエージェント導入プロジェクトのうち、成果を出せずに終わるケースが少なくないという指摘もあり、その原因の多くは技術力ではなく「課題と求める成果のミスマッチ」にあります（AQUA「AIエージェント導入で失敗する5つの原因」）。このミスマッチを防ぐ最大の手段が、発注側が主導する要件定義です。
丸投げが作り直しを生む構造
「AIのことは専門のベンダーが分かっているはず」と要件定義を任せきりにすると、ベンダーは自社が作りやすい前提で設計を進めます。その結果、現場の業務実態とずれた仕様で開発が進み、納品後に「思っていたものと違う」となって作り直しが発生します。
マルチエージェントは構成が複雑な分、作り直しのコストも大きくなります。だからこそ、発注側が業務の実態と求める成果を要件として言語化し、主導権を持ってベンダーと握ることが、結果的に最も費用対効果の高い進め方になります。次の章から、その要件定義で具体的に何を詰めるべきかを見ていきます。
失敗しない要件定義の5つの論点【マルチエージェント特有】
通常のシステム開発と同様に、機能要件・非機能要件・業務フローの整理は当然必要です。そのうえで、マルチエージェントでは次の5つの論点を追加で詰める必要があります。一般的な要件定義に「上乗せ」して考えるのがポイントです。
1. エージェント分割の粒度と責務
どの業務を、いくつのエージェントに分けるか。各エージェントが何を担当し、何を担当しないかを明確にします。
分け方が曖昧だと、責任範囲が重複して同じ処理を複数のエージェントが行ったり、逆に誰も担当しない抜け漏れが生じたりします。「この業務はこのエージェント、例外時はこのエージェント」というように、業務フローと対応づけて責務を書き出すのが要件定義の出発点です。
2. エージェント間連携と例外・フォールバックの設計
エージェント同士がどう情報を受け渡すか、そしてあるエージェントが失敗したり判断に迷ったりしたときにどう振る舞うか（人間に引き継ぐ／別のエージェントが代替する／処理を止める等）を定義します。
マルチエージェントは正常系だけでなく異常系の設計が品質を左右します。例外時の挙動を決めておかないと、本番であるエージェントの失敗が次々と連鎖し、想定外の動作につながります。「うまくいかなかったときにどうなってほしいか」を業務目線で言語化しておくことが重要です。
3. 成功の評価指標
何をもって「正しい出力」とするかを定義します。前述のとおりAIエージェントは確率的に動作するため、許容できる精度・誤りの基準・人間が確認すべき範囲を、発注前に握っておく必要があります。
たとえば「問い合わせ分類の正答率は何%以上を目標とするか」「判断に迷うケースは人間に回す割合をどの程度許容するか」といった指標です。この評価指標が曖昧なまま開発を始めると、検収時に合否を判断できず、ずるずると追加開発が続く事態に陥ります。
4. ガードレール・ガバナンス・セキュリティ
エージェントがアクセスできる情報・実行できる操作の範囲を制限し、機密情報の漏洩や権限の過剰付与を防ぐ仕組みを定義します。
複数のエージェントが情報をやり取りするマルチエージェントは、構造上セキュリティリスクが高まりやすい点に注意が必要です。実際、調査では多くの組織がAIエージェント関連のセキュリティインシデントを経験しており、プロンプトインジェクションや意図しないデータ漏洩が主な要因として挙げられています（JBpress「AIエージェント同士の連携『マルチエージェント』に深刻な欠陥」）。どのエージェントにどこまでの権限を与えるかは、要件定義の段階で線引きしておくべき項目です。
5. 既存システム・データとの連携範囲
どの社内システムやデータベースと連携するか、その範囲と権限を明確にします。
連携範囲は開発費用とセキュリティ設計の両方に直結します。連携先が増えるほど開発工数も漏洩リスクも上がるため、「本当に連携が必要な範囲はどこまでか」を要件定義の早い段階で絞り込むことが、費用とリスクの両面で効いてきます。
発注前にベンダーと握っておく問いのチェックリスト
上記5つの論点を、発注前にベンダーへ渡す・社内で握っておくべき「問い」の形に落とし込みます。次のリストは、そのまま稟議資料やベンダーへの相談メモとして使えます。
- この業務は、なぜ単体エージェントでなくマルチエージェント構成が必要なのか説明できているか
- エージェントをいくつに分け、それぞれの責務は何か
- エージェントが失敗・判断不能になったとき、どう振る舞うか（人間への引き継ぎを含む）
- 「正しい動作」をどの指標で測り、どの程度の精度を許容するか
- 各エージェントがアクセスできる情報・操作の範囲をどう制限するか
- どの既存システム・データと連携し、その権限はどう管理するか
- 初期費用とランニングコスト（LLM利用料を含む）はそれぞれいくらか
- PoCから始めて段階的に拡張する進め方になっているか
これらの問いに発注側が答えを持ち、ベンダーと認識をすり合わせられていれば、丸投げによる作り直しリスクは大きく下がります。なお、1つ目の「なぜマルチエージェントが必要か」を社内でまだ整理しきれていない場合は、先にマルチエージェントとは？単体AIとの費用・設計の違いで単体構成との比較や有効なユースケースを確認しておくと、要件定義の前提が固まります。
マルチエージェント開発に強いベンダーの見極め方
要件定義の論点が整理できたら、次は「どこに頼むか」です。マルチエージェント開発は新しい領域のため、一般的なWeb・業務システム開発とは求められる専門性が異なります。次の観点でベンダーを見極めてください。
見極めの5つの観点
- オーケストレーション設計の実績: 複数エージェントの連携・分担を設計した経験があるか。実装したシステムの構成や、どんな課題をどう解決したかを具体的に語れるか
- LLM運用の知見: トークンコストの制御やモデル更新など、本番運用まで見据えた経験があるか。開発して終わりではなく、運用フェーズの設計を提案できるか
- 評価・ガードレール設計の実績: AIの出力品質をどう評価し、リスクをどう抑えるかの方法論を持っているか。前章の評価指標やガードレールの論点に具体的に応えられるか
- PoCから本番への伴走体制: 小さく試して段階的に広げる進め方を提案してくれるか。最初から大規模な一括開発を勧めてこないか
- 既存システム連携の経験: 自社の業務システムやデータ基盤との連携を任せられる実績があるか
「大規模提案」をしてくるベンダーには注意
特に注意したいのが、ヒアリングもそこそこに「最初から大規模なマルチエージェント構成」を提案してくるベンダーです。
マルチエージェント設計の研究では、多くのケースは単体やシンプルな構成で足りるにもかかわらず、複雑な構成を選んでコストを膨張させてしまう失敗が繰り返し指摘されています。発注側の課題をよく聞いたうえで「その業務なら、まずこの範囲をシンプルな構成で試しましょう」と身の丈に合った提案をしてくれるベンダーの方が、信頼に値します。提案規模の大きさではなく、課題理解の深さで見極めることが重要です。
相見積もりは判断軸を点数化する
複数ベンダーを比較する際は、上記の見極め観点を項目ごとに点数化すると、社内での合意形成がしやすくなります。「実績」「提案の具体性」「運用設計」「費用の妥当性」「伴走体制」といった軸で各社を採点し、価格だけでない多面的な比較を行うことで、稟議でも説明しやすい選定になります。なお、提示された見積金額が妥当かどうかを見極める一般的な観点はシステム開発費用の妥当性の判断方法も参考になります。
PoCから始める段階的な発注プロセス
最後に、要件定義とベンダー選定をどう発注プロセスに組み込むかを整理します。マルチエージェント開発は一括で発注せず、段階を分けて進めるのが安全です。作り直しのリスクを最小化し、投資を効果に応じて広げていくための進め方です。
- 課題の切り分け: 自社の課題を整理し、本当にマルチエージェント構成が必要かを確認する（迷う場合はマルチエージェントとは？単体AIとの費用・設計の違いの判断材料を活用）
- 要件定義の論点整理: 本記事の5論点とチェックリストをもとに、ベンダーに渡す論点リストを作る
- PoC（小さく試す）: 最も効果が見込める一業務に絞り、シンプルな構成で試験開発・効果検証する。ここで得た知見を本格開発の要件に反映できる
- 相見積もりと判断: PoCの結果をもとに複数ベンダーから見積もりを取り、実績・提案の具体性・費用を点数化して比較する
- 段階的な本格開発: 効果が確認できた範囲から、エージェントや連携を順次拡張する
この進め方の利点は2つあります。ひとつは、初期投資を抑えながら自社にとっての効果を実データで確認できること。もうひとつは、PoCで得た知見を要件定義に反映できるため、本格開発での作り直しリスクを下げられることです。
契約形態についても触れておくと、要件が固まりにくいPoC段階は準委任契約（成果ではなく稼働に対して対価を払う形）、要件が確定した本格開発は請負契約（成果物に対して対価を払う形）が選ばれることが多い、という考え方を覚えておくと、ベンダーとの契約交渉でも役立ちます。
まとめ：要件定義の主導権を発注側が握る
マルチエージェント開発の発注で作り直しを避ける鍵は、要件定義の主導権を発注側が握ることにあります。本記事で解説した実務の流れを振り返ります。
- 要件定義が成否を分ける: 自律性が高く「正しい動作」を定義しにくいマルチエージェントは、丸投げが作り直しを生む。発注側が業務実態と求める成果を言語化することが出発点
- 要件定義の5論点: 一般的な要件定義に、エージェント分割の粒度・連携と例外設計・評価指標・ガードレール・既存連携の5つを上乗せして詰める
- 問いのチェックリスト: 5論点を「問い」に落とし込み、稟議資料やベンダー相談メモとして使う
- ベンダー選定: オーケストレーション設計やLLM運用の実績を見極め、大規模提案より課題理解の深さを重視する。相見積もりは判断軸を点数化する
- 段階的な発注: 一括発注せず、PoCから始めて効果が確認できた範囲を段階的に拡張する
次のアクションとして、まずは本記事の5論点とチェックリストをもとに、自社の業務に当てはめた要件定義の論点リストを作ってみてください。その論点リストを持ってベンダーに相談し、PoCから段階的に発注する。この順序で進めれば、ベンダーへの丸投げによる作り直しを避け、自社に本当に必要なマルチエージェントシステムへ着実に近づけるはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- マルチエージェント開発のPoCにかかる費用と期間の目安はどのくらいですか？
PoCの規模や対象業務によって幅がありますが、一業務に絞ったシンプルな構成であれば数十万〜数百万円・1〜3か月程度で実施するケースが多いです。本格開発への移行判断材料を得ることを目的として、最小の対象範囲から始めることをお勧めします。
- 社内にAI専任者がいない場合、要件定義はどこから手をつければよいですか？
まず「この業務でどんな失敗が許されないか」「正しい動作をどの指標で測るか」を業務目線で言語化することが出発点です。AIの技術知識は不要で、業務フローと求める成果を自社側で整理することが発注者として果たすべき役割です。
- ベンダーへの相見積もりで価格以外に何を比較すればよいですか？
オーケストレーション設計の実績・LLM運用の知見・評価指標やガードレール設計の方法論・PoCから始める段階的な提案かどうか・本番運用まで見据えた伴走体制の5軸を点数化して比較するのが有効です。価格だけでなく課題理解の深さを最重視してください。
- 要件定義はどこまで自社で書いてからベンダーに渡すべきですか？
エージェントの分割粒度・成功の評価指標・既存システムとの連携範囲の3点は、発注前に自社側で方針を定めておくと認識のずれを防げます。技術的な実装方法はベンダーに委ねてよいですが、「何を達成したいか」と「何を許容できないか」は発注側が主導して握ることが重要です。
