# 02. 市場仮説と案件の棚卸し（Day 1）

2026-10-05 · 社内検討用（社外秘）

最初に攻めるのは **金融の「PoC は終わったが本番に出せない」顧客** です。過去2年の案件のうち、少なくとも6件で「エージェントを基幹につなぐときに詰まる箇所」が、すでに別の形で現れていました。本書はその根拠と、M0 の診断で検証する仮説をまとめたものです。

## 1. 過去案件の棚卸し（顧客名は伏せる）

過去案件の課題を「エージェントを接続したら何が問題になるか」の観点で読み直しました。顧客名は業種と規模に置き換えています。

| # | 業種・案件の型 | 当時の課題 | エージェント接続で再発する論点 | 関係する統制 |
| --- | --- | --- | --- | --- |
| A | 金融（大手）・勘定系周辺の統合基盤（Camel、MQ、CORBA、HULFT） | 外部系との電文連携、例外設計、Outbox、流量制御 | 更新系の二重実行と補償、基幹側の流量保護 | 5, 4 |
| B | 金融（ネット銀行）・Kafka による分散トランザクション | Saga、分散トレーシング、監視 | 処理の途中失敗の巻き戻し、全体の追跡 | 5, 6 |
| C | 金融（銀行）・API 基盤（RHBK、blue/green、GitOps） | クライアント登録の統制、製品ごとの流量上限 | エージェント用クライアントの権限設計、ポリシーのコード管理 | 1, 2, 4 |
| D | 通信・ESB 移行（Fuse から Camel） | ログ、スレッド、JMX 監視、性能 | 移行と同時に AI から使える形にする需要 | 6, オプション |
| E | 公共・統合基盤（Camel、流量制御） | スロットリング、XML 変換、Q&A 対応 | 調達要件としての統制、監査対応 | 4, 7 |
| F | 製造・エッジと工場データ（MQTT、Kafka、Debezium） | OT と IT の境界、データ連携 | 現場データへのエージェントのアクセス範囲 | 2, 3 |
| G | 製造（重工）・OpenShift の PoC | 基盤標準化、工数見積り | エージェント基盤を共通基盤に載せる要件 | 6 |

棚卸しから分かったことは3つです。

1. **統制5（更新系の整合性）は、金融の統合案件ではすでに日常の論点です。** エージェントは「新しい呼び出し元」にすぎず、Outbox や Saga の設計資産がそのまま効きます。
2. **統制6（可観測性）は、どの案件でも後回しにされがちでした。** エージェントでは推論・ツール・基幹をまたぐため、後付けではさらに難しくなります。
3. **統制1・2は API 基盤の延長で設計できます。** ただし「人の権限をエージェントに一部だけ委任する」という観点は、これまでの API 基盤にはありませんでした。

## 2. 顧客課題の仮説

| ID | 仮説 | 確かめ方（M0 のヒアリング） | 反証されたら |
| --- | --- | --- | --- |
| H1 | 本番化を止めているのは技術ではなく、リスク管理・監査部門の承認である | 「本番化の判断を誰がし、何を見て止めたか」を聞く | 技術課題（性能、精度）中心の提案に切り替える |
| H2 | 更新系（書き込み）を任せる段階で止まる顧客が多い | 接続済みの業務を「参照のみ」と「更新あり」に分けて数える | 参照系の可観測性と評価を入口にする |
| H3 | 部署ごとにエージェントが作られ、全社の統制がない | エージェントとツールの一覧、および所管部署を聞く | 単一業務の PoC（M1）を入口にする |
| H4 | LLM の利用料と原因の追跡ができず、運用部門が引き取らない | 障害時に原因を特定した事例と、その所要時間を聞く | 可観測性を前面に出すのをやめ、監査を前面にする |
| H5 | 基幹の移行（Fuse の EOL など）と同時に AI 対応したい | 移行計画の有無と時期を聞く | Agent-Ready モダナイゼーションのオプションを外す |

## 3. 市場の動き（提案の背景として使う範囲）

- **エージェントの標準化：** MCP（Model Context Protocol）が、エージェントと業務ツールをつなぐ事実上の共通仕様になりつつあります。仕様の改訂は続いているため、メニューは仕様ではなく統制で定義します。
- **ゲートウェイの役割の拡大：** API ゲートウェイが、LLM 推論の経路と MCP の経路にも統制をかける方向に広がっています。Connectivity Link（Kuadrant）では、Gateway API の上で認証・認可・回数制限を経路ごとに付けられます。
- **可観測性の標準化：** OpenTelemetry に生成 AI 向けの属性（gen_ai.*）が定義されつつあり、推論とツール実行を同じトレースに載せられるようになりました。
- **規制とガイドライン：** 国内では AI事業者ガイドライン、金融では FISC 安全対策基準が参照されます。海外拠点がある顧客には EU AI Act が関係します。いずれも「説明責任と記録」を求めており、統制6・7の需要につながります。

注：数値の市場規模や他社の売上などは、出典を確認できたものだけを提案書に載せます。本書には載せていません。

## 4. 競合の見取り図

| 競合のタイプ | 典型的な提案 | 顧客が困ること | 私たちの勝ち筋 |
| --- | --- | --- | --- |
| AI 専業ベンダー | エージェントの開発、RAG、プロンプト | 基幹への更新系接続と運用は範囲外 | 後工程として協業し、本番化を引き受ける |
| 大手 SIer | 業務アプリ開発の延長でのエージェント構築 | 統制の型がなく、案件ごとにばらつく | 型（7統制）と参照実装を渡し、構築は分担する |
| ハイパースケーラー | マネージドのエージェント基盤 | オンプレミスの基幹、データの所在、マルチクラウド | ハイブリッド前提で、クラウドに依存しない統制 |
| オブザーバビリティ製品ベンダー | LLM のトレースと評価のツール | 基幹側のトランザクションとつながらない | OpenTelemetry で全層を一本にする設計 |

## 5. 次に確かめること

- [ ] H1〜H5 を、既存顧客3社への非公式ヒアリングで確かめる（質問は `assessment-kit/questionnaire.md` の抜粋を使う）
- [ ] 社内で、同じ領域の既存メニューや進行中の案件がないか確認する（G1）
- [ ] 競合の具体的な提供メニューは、公開情報を出典付きで追記する