2026 年 5 月 20 日、InfoQ が Designing a Multi-Agent System for Engineering Support at Scale: a Case Study from Grab を公開しました。Grab のセントラルデータチームは、データウェアハウス基盤に対する 問い合わせ / 障害調査 / 軽微修正を自動化するためにマルチエージェントシステムを構築し、「調査ワークフロー」と「修正ワークフロー」をオーケストレータで分業することで、運用負荷の大幅削減 + 開発者体験向上を達成しました。
受託で中堅企業の 社内エンジニアリングサポート / ヘルプデスク を設計する立場では、これは 「単一の汎用 AI チャットでは到達できなかった領域に、マルチエージェント分業で踏み込める」ことを示します。これまで Spotify パターン 社内開発エージェント基盤 で扱った コーディング自動化 に対し、Grab パターンは 問い合わせ対応 / オペレーション 領域です。本記事では弊社が提供する 「マルチエージェント社内サポート」 受託パッケージを整理します。
なぜ「単一エージェント」では社内サポートが破綻するか
| 観点 | 単一汎用エージェント | マルチエージェント分業（Grab 方式） |
|---|---|---|
| 業務知識の深さ | 浅い / 横断 | 専門エージェントが深く担当 |
| コンテキストサイズ | 全社全業務を抱え込む | エージェント別に最小化 |
| 権限管理 | フラット | エージェント別に細分化 |
| 回答品質 | 7 割 | 9 割 |
| 誤回答の検知 | 困難 | オーケストレータで多段検証 |
| 拡張性 | プロンプト肥大化 | エージェント追加で水平拡張 |
| 責任所在 | 不明瞭 | エージェント別に明示 |
つまり 単一エージェントは「総合受付」程度には機能するが、実務での意思決定を任せられないことが分かっています。Grab パターンは 「調査」「修正」「オーケストレータ」という最小 3 エージェント構成で、これを克服する設計を示しています。
Grab パターンが変える 3 つの構造
構造 1: 「Slack で人間が一次対応」から「エージェントが一次対応」へ
中堅企業の社内サポートは Slack / Teams で SRE / データチームが一次対応するパターンが定番ですが、業務時間の 30〜40% が問い合わせ対応で消費されています。Grab パターンでは エージェントが一次対応 → 人間はエスカレーション分のみという構造変化を起こします。
構造 2: 「単一プロンプトで全部やる」から「エージェント分業」へ
Grab の 調査エージェントは read-only で問題の原因を特定し、修正エージェントは限定的な書き込み権限で軽微な修正を実行します。これは 権限分離 + 責任分離を実装層で実現する正攻法で、VSCode Agent Window マルチエージェント受託 と思想は近いものの 業務オペレーション側 に降ろした事例です。
構造 3: 「ナレッジベースを人間が更新」から「会話ログから自動学習」へ
Grab パターンでは 問い合わせ会話ログを ナレッジベース更新の起点としています。これは Notion Developer Platform 内部 SaaS 連携受託 で扱った内部知識基盤と組み合わせると、月次更新サイクルとして運用できます。
受託で提供する「マルチエージェント社内サポート」5 フェーズ
フェーズ 1: 現状診断（2 週間）
- 既存社内ヘルプデスクの 問い合わせ分類（問い合わせ ログ / Slack / Jira）
- 対応工数の 月次集計
- 頻出 20 問の洗い出し（パレートの法則 80/20）
- 既存ナレッジベース（Notion / Confluence / Esa）の棚卸し
- セキュリティ / 権限境界の確認
フェーズ 2: エージェント設計（2〜3 週間）
- エージェント分業設計（最小 3 構成）
- 調査エージェント（read-only）
- 修正エージェント（限定書き込み）
- オーケストレータ（ルーティング + 検証）
- 権限スコープ設計（顧客 IAM / OAuth）
- ナレッジ取り込みパイプライン
- ヒューマンインザループ点設計
- 評価指標（一次解決率 / 誤回答率 / 平均回答時間）
フェーズ 3: PoC 構築（3〜5 週間）
- Slack / Teams 連携
- 頻出 20 問への対応カバレッジ確認
- 評価データセット作成（過去 6 ヶ月の問い合わせから）
- A/B テスト（人間オペ vs エージェント）
- 安全弁（人間承認必須アクションのリスト）
フェーズ 4: 本番展開 + ガバナンス（2〜3 週間）
- 段階展開（部署別 → 全社）
- 監査ログ（全会話 + アクション履歴）
- インシデント対応ランブック
- 月次会話分析ダッシュボード
- ナレッジベース自動更新ループ
フェーズ 5: 月次運用レビュー（継続）
- 一次解決率 / 誤回答率モニタリング
- 新カテゴリ問い合わせのキャッチアップ
- エージェント追加判断（4 つ目以降）
- 権限スコープの見直し
- ナレッジベース鮮度監査
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| オーケストレーション | Anthropic Routines / OpenAI Agents SDK | LangGraph / Mastra |
| LLM | Claude / GPT-5.5 / Gemini 3.5 | Llama 4 自前 |
| ナレッジベース接続 | MCP Server（Notion / Confluence / GitHub） | 自前 RAG |
| Slack / Teams 連携 | Slack Bolt / Bot Framework | 自前 Webhook |
| 権限管理 | OAuth + IAM Role | HashiCorp Vault |
| 会話ログ | BigQuery / Snowflake | PostgreSQL |
| 評価 | LangSmith / Phoenix | 自前評価フレームワーク |
| アラート | PagerDuty / Slack | Opsgenie |
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| エンジニア 30 名以上 | 5 名以下の小規模 |
| 社内 SRE / データチームが問い合わせ対応で疲弊 | 問い合わせ自体が少ない |
| ナレッジベースが分散している | 単一ツールで完結 |
| 月次の問い合わせ 200 件以上 | 月 20 件以下 |
| ガバナンス要件あり（監査 / 権限） | 規制対象外 |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 一次解決率 SLA | 目標 60% 以上 | カテゴリ別の調整 |
| 誤回答率上限 | 5% 以下 | 重大誤回答の定義 |
| 権限スコープ | エージェント別の最小権限 | 顧客 IAM との整合 |
| 会話ログ保管 | 期間 + 暗号化 | プライバシー法整合 |
| ヒューマン承認必須アクション | 明示リスト | 業務影響度 |
| 退会時引き渡し | エージェント定義 + ナレッジベース | 自社運用継続性 |
価格モデル — マルチエージェント社内サポートパッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 | 90 万円〜（3 週間） | 問い合わせログ分析 + 設計提案 | レポート + 改善ロードマップ |
| Lite | 320 万円〜（一括） | 3 エージェント / 単一部署 | PoC + 本番展開（1 部署） |
| Standard | 720 万円〜（一括） | 5 エージェント / 全社 | + ガバナンス層 + 監査 |
| Enterprise | 1,500 万円〜（一括） | 10 エージェント / 全社 | + 24h 運用 + 専任担当 |
| 継続運用 | 60 万円〜 / 月 | 全プラン共通 | 月次レビュー + エージェント追加 |
顧客側 ROI 試算（エンジニア 80 名 / 月 300 件問い合わせ想定）
| 項目 | 既存ヘルプデスク（現状） | マルチエージェント導入後 | 差分 |
|---|---|---|---|
| 一次解決率 | 0%（全件人間対応） | 60% | +60% |
| 1 件あたり対応時間 | 45 分 | 8 分 | -37 分 |
| 月次対応工数 | 225h | 90h | -135h |
| SRE / データ専任工数の年間損失 | 2,700h | 1,080h | -1,620h |
| 開発者の待ち時間（年） | 4,500h | 1,500h | -3,000h |
| 年間効果 | — | — | 約 3,800 万円相当 + DX 加速 |
時給 8,000 円換算で 年間 3,696 万円超の工数削減効果。Standard プラン（初期 720 万円 + 年額 720 万円）でも 6 ヶ月以内で回収可能です。
ハマりやすい 5 つの落とし穴
落とし穴 1: 全エージェントに「書き込み権限」を付与する
調査エージェントに 書き込み権限を持たせると、LLM の暴走で本番データを壊す事故が起きます。read-only / write 限定 / orchestrator の 3 層分離が原則です。
落とし穴 2: ナレッジベース更新を「手動」にする
会話ログから 自動更新ループを組まないと、ナレッジは半年で陳腐化します。月次の自動更新提案 + 人間承認フローを最初から組み込むべきです。
落とし穴 3: Slack に直接出力して終わり
Slack に答えだけ返すと オーディット不能になります。会話ログを BigQuery / Snowflake に蓄積 + ダッシュボード化を必須化します。
落とし穴 4: 「単一巨大エージェント」に統合する誘惑
「分業より統合の方がシンプル」と判断すると、プロンプト肥大化 + コンテキスト圧迫 + 責任所在不明で破綻します。Grab パターンの 3 分業を守るべきです。
落とし穴 5: 人間の最終承認点を曖昧にする
「人間承認必須なアクション」を明示しないと、エージェントが 本来人間判断であるべきアクションを独断実行します。最初から 承認必須アクションリスト を契約に明記します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜2 | 問い合わせログ分析 + 頻出 20 問抽出 |
| Week 3〜5 | エージェント設計 + 権限スコープ確定 |
| Week 6〜9 | PoC 構築 + Slack 連携 + 評価データセット |
| Week 10〜11 | A/B テスト + 段階本番展開 |
| Week 12 | ガバナンス層構築 + 監査ダッシュボード |
| Week 13 | 月次運用レビュー会議立ち上げ |
まとめ — 社内サポートを「分業マルチエージェント」で組み直す
Grab のマルチエージェント支援システムは、「単一汎用 AI チャット」では到達できなかった社内エンジニアリングサポートの正解を示しました。受託で中堅企業を支える立場では、棚卸し + 分業設計 + PoC + 本番展開 + 月次運用レビューを一体で設計する 「マルチエージェント社内サポート」 が新しい標準サービスになります。
弊社では 診断 / Lite / Standard / Enterprise の 4 段階で本パッケージを提供しています。「SRE / データチームが問い合わせ対応で疲弊」「ナレッジベースが陳腐化している」「社内ヘルプデスクをエージェントで置き換えたい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
