プロジェクト概要
BtoB SaaS を提供する従業員 120 名規模の企業から、複数部署にまたがる「契約更新オペレーション」を AI エージェントで自動化したいという相談を受けました。営業・カスタマーサクセス・経理の 3 部署が、メール・社内 Wiki・契約管理 SaaS・スプレッドシートをまたいで手作業で進めていた一連の業務を、複数の AI エージェント に役割分担させて自動化するプロジェクトです。
この記事では、単一エージェントでは回らなかった理由から、マルチエージェント構成の設計、エージェント間のオーケストレーション、品質を担保する評価ハーネス、そして導入後の実数値と運用引き継ぎまでを、AI 駆動開発の実証事例として公開します。マルチエージェントの導入を検討している方が、設計と運用の勘所を具体的にイメージできることを狙っています。
課題 — 単一エージェントでは回らなかった複合業務
クライアントの契約更新フローは、ひとことで言えば「部署と情報源をまたぐ長い手続き」でした。契約満了の 60 日前から、おおまかに次のような工程が走ります。
- 契約管理 SaaS から満了が近い契約を抽出し、利用状況データと突き合わせる
- 過去のやり取りや解約リスクの兆候を CRM とサポート履歴から拾う
- 更新案 (継続・プラン変更・値上げ) を作り、社内 Wiki の価格ポリシーと整合を取る
- 顧客向けの更新案内メールを下書きし、担当者がレビューする
- 経理に売上見込みを連携し、見積書発行の準備をする
最初の検討段階では「ChatGPT や Claude に一発で全部やらせればよいのでは」という期待が社内にありました。しかし試作してみると、単一のエージェントに長大なプロンプトと多数のツールを持たせる構成は、次の 3 つの理由で破綻しました。
- ツールと判断の責務が混ざりすぎて、エラーの切り分けができませんでした。データ抽出のミスなのか、価格ポリシーの解釈ミスなのか、文面生成の問題なのかが切り分けられず、改善のループが回りませんでした。
- 1 回の実行で扱うコンテキストが膨らみすぎて、後半の工程ほど指示の遵守率が落ちました。価格ポリシーのような重要な制約を、長い処理の途中で取りこぼすケースが頻発しました。
- ヒューマンレビューを差し込みたい工程 (メール文面の最終確認など) と、人手を介さず自動で進めてよい工程が混在しているのに、単一エージェントだと「途中で止めて人に渡し、また再開する」設計がきれいに書けませんでした。
複合業務をひとつのエージェントに押し込むと、プロンプトエンジニアリングの沼にはまり、品質も運用性も上がらない。ここがプロジェクト初期の最大の学びでした。AI エージェントを業務に組み込む際の典型的な失敗パターンであり、対処の方向性は AI エージェント設計のパターン でも体系的に整理しています。
解決の全体像 — 役割分担したマルチエージェント構成
そこで、業務工程を 責務単位のエージェントに分割 し、それぞれが得意な仕事だけを担当する構成に切り替えました。人間の組織が役割分担で動くのと同じ発想です。最終的に落ち着いた構成は次の 5 つのエージェントと 1 つのオーケストレーターです。
flowchart TD
O["オーケストレーター<br/>(ワークフロー制御)"]
C["収集エージェント<br/>契約・利用状況データ抽出"]
R["リスク分析エージェント<br/>解約兆候・更新方針判定"]
P["プラン提案エージェント<br/>価格ポリシー整合チェック"]
D["文面ドラフトエージェント<br/>顧客向けメール生成"]
F["連携エージェント<br/>経理・見積準備"]
H["担当者レビュー"]
O --> C --> R --> P
P --> D --> H
H -- 承認 --> F
H -- 差し戻し --> Dそれぞれのエージェントには、担当する工程に必要なツールとナレッジだけを与えました。収集エージェントは契約管理 SaaS とデータウェアハウスへの読み取りツールだけ、プラン提案エージェントは社内 Wiki の価格ポリシーを参照する RAG だけ、というように 権限と知識を最小化 しています。これによって、各エージェントのプロンプトが短く保たれ、指示の遵守率が上がり、どの工程で問題が起きたかも切り分けやすくなりました。
実装は Claude (Sonnet 4.6) を各エージェントの推論エンジンに、エージェント定義とフロー記述に LangGraph、長時間ワークフローの状態管理に Temporal を使いました。開発そのものは Claude Code を中心に進め、エージェント定義・テスト・評価コードを並行して書き起こしています。Claude Code を用いた AI 駆動開発の進め方は AI エージェント開発サービス でも紹介しています。
エージェント間のオーケストレーションと受け渡し設計
マルチエージェントで最も設計が効くのは、エージェント同士をどうつなぐか です。ここを雑に作ると、エージェントが互いの出力を誤解したり、無限ループに陥ったりします。今回は次の 3 点を設計の柱にしました。
1. 受け渡しは「自然文」ではなく構造化スキーマで
エージェント間でデータを渡すとき、自然文の長い説明を投げ合うのではなく、工程ごとに JSON スキーマを定義し、各エージェントは スキーマに沿った構造化出力を返す 形にしました。たとえばリスク分析エージェントは、解約リスクスコア・根拠・推奨方針を決まったフィールドで返します。受け取る側はそれを機械的に解釈できるため、解釈ブレが激減しました。スキーマに合わない出力はオーケストレーターが弾いて再実行させるため、後続工程に壊れたデータが流れません。
2. 制御はオーケストレーターに集約し、エージェントは判断に専念
「次にどのエージェントを呼ぶか」「リトライするか」「人間に渡すか」といったフロー制御は、すべてオーケストレーター層 (LangGraph + Temporal) に持たせました。各エージェントはあくまで自分の担当範囲の判断に専念し、フロー全体の状態は持ちません。こうすると、エージェント単体の差し替えや A/B 比較が容易になり、業務ルール変更時の修正範囲も小さく保てます。集約か分散かというオーケストレーションの方針は業務の性質で変わるため、設計時の判断材料は AI エージェント設計のパターン に詳しくまとめています。
3. 長時間・中断ありの業務は Temporal で耐久ワークフロー化
契約更新は数分で終わらず、担当者レビュー待ちで数日中断することも珍しくありません。これをメモリ上のループで持つと、プロセス再起動で状態が飛びます。Temporal でワークフローを耐久化し、どの工程まで進んだか・どのレビュー待ちか を永続化することで、途中再開や障害復旧に耐える設計にしました。担当者が承認した瞬間に経理連携エージェントが起動する、といった「人間とエージェントの非同期な協調」もここで実現しています。
品質担保 — 評価ハーネスと人間協調の組み込み
業務自動化で怖いのは「動いてはいるが、静かに間違えている」状態です。とくに金額や契約条件を扱う工程では、誤りがそのまま顧客への誤案内や売上の取りこぼしにつながります。そこで、開発初期から評価ハーネスを並走させました。
各エージェントの出力に対して、ゴールデンデータ (人間が正解を確認した過去案件のサンプル) を用意し、回帰テストとして CI に組み込みました。評価のルーブリックは工程ごとに分け、おおむね次の軸で採点します。
- 抽出系エージェントは データの正確性と網羅性 (必要な契約・利用状況を漏れなく拾えているか)
- リスク分析・プラン提案エージェントは 判断の妥当性とポリシー遵守 (価格ポリシーや割引上限に違反していないか)
- 文面ドラフトエージェントは 事実整合とトーン (誤った金額や条件を書いていないか、ブランドの口調に沿っているか)
プロンプトやモデルを変更するたびにこのハーネスを回し、品質スコアが下がっていないかを確認してからリリースします。LLM を業務に使う際の評価ハーネスの組み方は奥が深く、考え方は LLM 評価ハーネスと LLMOps で掘り下げています。
同時に重要だったのが 人間協調 (human-in-the-loop) の設計 です。すべてを自動化するのではなく、「顧客に出るメール文面の最終承認」と「価格ポリシーから外れる例外的なプラン提案」の 2 点は、必ず担当者のレビューを通す設計にしました。エージェントは自信度が低い判断や例外パターンを検知すると、処理を止めて人間にエスカレーションします。完全自動化を狙わず「迷ったら人に渡す」を明示的に組み込むことで、誤案内のリスクを抑えつつ、定型部分の工数を大きく削れました。
導入の成果 — 処理時間・精度・工数の実数値
8 週間の開発後、まず一部の契約セグメントで本番運用を開始し、段階的に対象を広げました。導入前後で計測した主な指標は次のとおりです。数値はクライアント許諾の範囲で、相対値・レンジに丸めて記載しています。
| 指標 | 導入前 | 導入後 (運用 3 ヶ月) |
|---|---|---|
| 契約更新 1 件あたりの担当者作業時間 | 約 90 分 | 約 25 分 |
| 1 案件の準備リードタイム | 平均 3 営業日 | 平均 0.5 営業日 |
| 更新案内の準備工数 (月間合計) | 100 (基準) | 約 35 |
| プラン提案の価格ポリシー違反 | 月に数件発生 | ほぼゼロ |
| 担当者レビューでの差し戻し率 | — | 約 12% |
担当者 1 人あたりの作業時間は おおよそ 3 分の 1 以下 になり、契約更新の準備リードタイムも数営業日から半日程度まで縮みました。とくに効果が大きかったのは、価格ポリシー違反の提案がほぼゼロになった点です。これまでは人手の確認に頼っていたポリシー整合を、プラン提案エージェントの構造化チェックと評価ハーネスで機械的に担保できるようになったためです。
ここで強調したいのは、差し戻し率を あえてゼロにしていない ことです。約 12% の差し戻しは「人間が最終判断すべき例外を、エージェントが正しく人に渡している」状態であり、無理に自動化率を上げて誤案内を出すより健全だと判断しています。自動化率そのものではなく、誤りを出さずに工数を減らせているかを評価軸に置きました。
運用設計と内製化に向けた引き継ぎ
開発して終わりではなく、クライアントが自社で運用・改善し続けられる状態に引き継ぐところまでをスコープに含めました。AI エージェントは導入後の運用設計を怠ると、数ヶ月でナレッジが古くなり品質が落ちます。今回は次の運用基盤を整備しました。
まず、エージェントの実行ログと評価スコアを Slack と社内ダッシュボードに流し、週次で差し戻しケースと低スコア出力をレビューする運用 を定例化しました。外れたケースはゴールデンデータに追加され、回帰テストが少しずつ厚くなっていきます。価格ポリシーや商品マスタが変わったときは、該当エージェントが参照するナレッジを更新し、評価ハーネスを回して影響を確認してからリリースする、という更新手順も手順書に落としました。
内製化に向けては、クライアントのエンジニアと一緒に Claude Code を使った開発フローを共有し、エージェント定義の追加・修正・テストを自走できる体制づくりまで伴走しました。同種のオペレーション自動化を別領域に展開した事例は 顧客対応オペレーションの AI エージェント自動化 でも公開しています。あわせて読むと、業務分析からマルチエージェント化までの判断基準がより具体的に掴めるはずです。
マルチエージェントは「賢い AI を 1 つ置けば終わり」ではなく、責務分割・受け渡し設計・評価・運用までを一貫して設計してはじめて業務で使える資産になります。逆に言えば、ここを丁寧に作れば、モデルが新しくなっても評価ハーネスとオーケストレーション設計はそのまま活きる、長期的に価値の高い投資になります。
同様の業務自動化を相談する
複数部署や複数システムをまたぐ複合業務は、単一エージェントよりもマルチエージェント構成のほうが堅牢に自動化できるケースが多くあります。FIXIT は AI 駆動開発のクリエイティブスタジオとして、業務分析からマルチエージェント設計・評価ハーネス・運用引き継ぎまで一貫して伴走します。自社の業務フローを自動化できるか相談したい方は、AI エージェント開発の無料相談・見積もり からお気軽にお問い合わせください。
よくある質問
Q. 単一エージェントとマルチエージェント、どちらで作るべきですか？
A. 工程がひとつのまとまった判断で完結し、扱う情報源も限られているなら単一エージェントで十分です。一方、複数部署・複数システムをまたぎ、工程ごとに必要な権限や知識が異なる複合業務は、責務単位に分割したマルチエージェント構成のほうが品質も運用性も上がります。今回のように途中で人間のレビューを挟む業務も、マルチエージェント + オーケストレーターの構成が向いています。
Q. マルチエージェント開発の費用と期間の目安は？
A. 本案件相当 (5 エージェント + オーケストレーション + 評価ハーネス + 運用引き継ぎ) で 8 週間規模でした。費用は業務の複雑さや連携する外部システムの数で変動するため、まずは対象業務の整理から無料相談で承っています。スモールスタートで 1〜2 工程だけ自動化し、効果を見て広げる進め方も可能です。
Q. 自動化したあと、自社で運用・改善できますか？
A. できます。今回は評価ハーネスと週次レビューの運用、ナレッジ更新の手順書を整備し、クライアントのエンジニアが Claude Code を使ってエージェントを自走で改善できる体制まで引き継ぎました。内製化を前提とした設計と伴走を最初からスコープに含めることをおすすめしています。