# Agent Safe-Connect オファリング定義書（初稿）

2026-10-05 · KEIJI JIN

## 0. 本書の位置づけ

本書は、AIエージェントを企業の基幹システムへ安全に接続・運用するためのコンサルティングメニュー「Agent Safe-Connect」（仮称）の定義書です。現在は初稿（v0.1）で、社内検討用です。顧客への配布はしません。

| 項目 | 内容 |
| --- | --- |
| 版 | v0.1（初稿） |
| 対象読者 | 社内のコンサルタント、営業、プリセールス、デリバリー責任者 |
| 使い方 | 提案書、見積り、SOW 雛形、アセスメントキットの「正本」とする |
| 次の版で確定させること | 工数単価、社内既存メニューとの整理、パイロット顧客（第8章） |

## 1. ビジョンと提供価値

**ビジョン：** AIエージェントを本番の企業システムに安全につなげられるアーキテクトとして、顧客のエージェントをPoCから本番へ送り出す。

### 顧客の課題

> 「エージェントのPoCはうまくいった。しかし基幹系につなぐ段階で、セキュリティや監査、**可観測性**、障害時の責任の問題に阻まれ、本番に出せない」

本番を阻む壁は、次の4つに分けられます。

| 壁 | 現場で出る言葉 | 本質 |
| --- | --- | --- |
| セキュリティ | 「エージェントにどこまで権限を渡してよいか分からない」 | 身元、権限委任、最小権限が未設計 |
| 監査 | 「誰の指示で何が実行されたか、後から証明できない」 | 証跡が残らない、改ざんを防げない |
| 可観測性 | 「遅い・間違う・高いと言われても、どこで何が起きているか見えない」 | 推論から基幹までの一貫したトレース、品質とコストの指標、SLO がない |
| 障害時の責任 | 「エージェントが誤って更新したら、誰がどう戻すのか」 | 冪等性、補償、人間の承認、責任分界が未定義 |

可観測性は他の3つの土台でもあります。見えないものは統制できず、監査でも説明できず、障害時に原因も切り分けられません。

### 提供価値

既存の基幹統合を「エージェントが安全に使える業務ツール」に変えます。そのうえで、認可、可観測性、監査、失敗時の回復までを備えて本番に載せます。

- **顧客が得るもの：** 監査やリスク管理部門を通せる設計と証跡、運用部門が引き取れる監視と手順、次の業務へ横展開できる共通基盤。
- **測る指標（例）：** PoCから本番までの期間、本番に接続した業務ツール数、インシデントの原因特定までの時間、エージェント1件あたりの実行コスト。

## 2. 対象顧客と購買のきっかけ

最初のターゲットは金融です。更新系の統制と監査証跡への要求が最も厳しく、ここで通る設計は他の業種にも展開できます。

| 優先 | 業種 | 主な規制・論点 | 典型的なユースケース |
| --- | --- | --- | --- |
| 1 | 金融（銀行、証券、保険） | FISC 安全対策基準、監査証跡、個人情報 | 顧客対応、審査の下準備、店舗・コールセンターの照会と予約 |
| 2 | 製造 | OT と IT の境界、設計情報の扱い | 生産・品質データの照会、保全の手配 |
| 3 | 公共・通信 | 調達要件、大規模な既存統合 | 内部申請の処理、問い合わせ対応 |

どの業種でも、AI事業者ガイドラインを参照します。海外拠点がある顧客には EU AI Act も加えます。

### 購買のきっかけ（この発言が出たら提案する）

- 「PoC は終わったが、セキュリティ審査（またはリスク委員会）を通らない」
- 「部署ごとにエージェントを作り始め、全社での統制が効かない」
- 「LLM の利用料が予測できない。どの業務で使われているかも分からない」
- 「基幹の移行（Fuse の EOL 対応など）をするなら、AI から使える形にしたい」

### 想定ペルソナ

| ペルソナ | 関心事 | 刺さる成果物 |
| --- | --- | --- |
| CIO、DX 推進責任者（発注者） | PoC を投資対効果に変える | 本番化ロードマップ、横展開の計画 |
| リスク管理、内部監査（関門） | 説明責任と証跡 | 統制の対応表、監査ログの仕様 |
| アーキテクト、基盤チーム（一緒に作る人） | 既存統合との整合 | 参照アーキテクチャ、ポリシーのテンプレート |
| 運用・SRE（引き取る人） | 障害時に追えること | ダッシュボード、SLO、障害対応手順 |

## 3. 7つの統制と参照アーキテクチャ

「安全につなぐ」を、次の7つの統制に分けます。提案、設計、アセスメント、成熟度モデルはすべてこの7項目で揃えます。可観測性（統制6）は独立した統制とし、監査（統制7）の土台にもします。

| # | 統制 | 守ること | 主な技術（例） | 本番の合格基準 |
| --- | --- | --- | --- | --- |
| 1 | Identity | エージェントの身元を定め、利用者からの権限委任を扱う | RHBK、トークン交換 | どの呼び出しでも、誰の権限で動いたか特定できる |
| 2 | Authorization | ツール単位で最小権限にし、参照と更新を分ける | Connectivity Link の AuthPolicy | 許可されていないツールの呼び出しをゲートウェイで拒否できる |
| 3 | Guardrails | 入力と出力を検査する（PII、プロンプトインジェクション） | TrustyAI Guardrails など | 検査を迂回する経路がない |
| 4 | Blast Radius | レート制限、トークン上限、更新系の人間承認で被害範囲を限定する | RateLimitPolicy、承認フロー | 暴走時の最大影響を事前に数値で示せる |
| 5 | Transactional Safety | 書き込みの冪等性、補償、Outbox、Saga を設計する | Camel、Kafka | 障害注入テストで補償が動く |
| 6 | Observability | 推論、ゲートウェイ、ツール、統合、基幹を一本のトレースで追い、品質・コスト・遅延を計測する | OpenTelemetry、Langfuse、Prometheus、Grafana | 障害の原因層をトレースから特定できる。SLO が定義されている |
| 7 | Audit & Traceability | 誰の指示で、どのエージェントが、何をしたかを証明する | 監査ログ、改ざんを防ぐ保管 | 監査部門が自ら検索・検証できる |

![参照アーキテクチャ · 5層と横断する3つの統制](images/reference-architecture.png)

利用者の指示は、エージェントからゲートウェイを通って、ツール、統合層、基幹へ流れます。各層は同じトレース ID でテレメトリを可観測性基盤へ送り（破線）、そこから監査証跡を作ります。

## 4. メニュー体系

メニューは M0（診断）から M3（継続支援）までの4段階です。入口は M0 に絞り、その成果物から次の段階へつなげます。工数は初稿時点の目安で、単価と見積りの根拠は v0.2 で確定します。

| メニュー | 期間・工数の目安 | 対象範囲 | 主な成果物 | 次へのつなぎ |
| --- | --- | --- | --- | --- |
| M0 エージェント接続レディネス診断 | 2〜3週間、15〜20人日 | 接続候補の業務とシステム、既存の認証・統合・監視基盤 | 診断レポート（7統制の成熟度）、接続候補の優先順位、ロードマップ | M1 の対象業務を合意 |
| M1 参照アーキテクチャと PoC | 6〜8週間 | 1業務、参照系と更新系をそれぞれ1つ以上 | 動く PoC、アーキテクチャ定義書、監視ダッシュボード、評価結果 | 本番化の判断材料 |
| M2 Agent Gateway 基盤の構築 | 3〜6か月 | 全社共通のゲートウェイ、ツールカタログ、可観測性基盤 | 本番基盤、運用設計、SLO、ポリシーテンプレート | 横展開、M3 |
| M3 AgentOps 継続支援 | 月額・四半期単位 | 本番稼働中のエージェント | 月次の品質・コスト・インシデントレポート、モデル切替時の回帰評価 | 対象業務の追加 |

### M0 診断の進め方

1. キックオフ：対象業務、関係部門（業務、基盤、リスク管理、運用）、既存の PoC を確認する。
2. ヒアリングと資料調査：7統制ごとの質問票で現状を把握する。
3. 接続候補のリスク分類：参照のみ、更新あり、金銭や個人情報が絡む、の3区分に分ける。
4. 成熟度の評価とギャップ分析：第5章のモデルで現状と本番に必要な水準を比べる。
5. 報告：優先順位とロードマップを示し、M1 の対象業務を合意する。

### M1 PoC で必ず入れるもの

- 既存の API または Camel ルートを MCP ツールとして公開し、参照系と更新系を分ける。
- ゲートウェイで認証・認可、レート制限、トークン上限をかける。
- 推論から基幹までを一本のトレースで追えるようにし、品質とコストのダッシュボードを作る。
- 障害を意図的に注入し、補償が動くことと、原因をトレースから特定できることを実証する。
- 評価セット（攻撃ケースを含む）を作り、安全性の違反が0件であることを確かめる。モデルやプロンプトを替えたら必ず流す。

### オプション

| オプション | 内容 | 組み合わせるメニュー |
| --- | --- | --- |
| Agent-Ready モダナイゼーション | Fuse→Camel 4 移行に、MCP 公開と可観測性の組み込みをセットにする。EOL 対応を AI 対応への投資として位置づけ直せる | M1、M2 |
| エージェントのサプライチェーン診断 | MCP サーバーやモデルの SBOM・AI-BOM、署名、来歴を診断する。OSSサプライチェーン簡易診断と束ねて提供する | M0、M2 |

## 5. 成熟度モデル

本番で更新系のツールを開放する目安は、**7統制すべてが L3 以上**です。金銭や個人情報が絡む業務では、可観測性と監査を L4 とします。M0 ではこの表で現状を採点し、ギャップをロードマップに落とします。

各段階の意味は、L1 場当たり、L2 個別対応、L3 標準化、L4 計測と自動化、L5 継続的な改善、です。

| 統制 | L1 | L2 | L3（本番の最低ライン） | L4 | L5 |
| --- | --- | --- | --- | --- | --- |
| 1 Identity | 共通の API キー | エージェントごとの資格情報 | 利用者からの権限委任（OBO）が通る | 短命トークン、自動ローテーション | 異常な身元利用の自動検知 |
| 2 Authorization | 全ツールを開放 | アプリ内で個別に制限 | ツール単位のポリシーをゲートウェイで一元管理 | ポリシーを GitOps で管理し、変更もレビュー | 利用実績から権限を縮小 |
| 3 Guardrails | なし | プロンプトで指示 | 入力と出力を検査（PII、インジェクション） | 検査結果を計測し、しきい値を調整 | レッドチームを定期実施 |
| 4 Blast Radius | 制限なし | 手動で停止できる | レート制限、トークン上限、更新系の人間承認 | リスクに応じた承認の自動振り分け | 異常時の自動遮断 |
| 5 Transactional Safety | 更新は一発勝負 | リトライのみ | 冪等キー、Outbox、補償処理を設計 | 障害注入テストで補償を定期検証 | 業務単位での整合性を自動監査 |
| 6 Observability | アプリのログのみ | LLM の入出力を個別に記録 | 推論・ゲートウェイ・統合・基幹を一本のトレースで追える | 品質・コスト・遅延の SLO とアラート | 評価と障害分析が改善に自動で戻る |
| 7 Audit & Traceability | 証跡なし | ログを手作業で突合 | 「誰の指示で、どのエージェントが、何をしたか」を記録 | 改ざんを防ぐ保管と監査レポートの自動生成 | 監査部門が自ら検索・検証できる |

## 6. 提供体制、前提条件、除外事項

標準の体制は、リードアーキテクトを軸にした2〜4名です。M0 はリードアーキテクト1名でも実施できます。

| 役割 | 担当 | M0 | M1 | M2 | M3 |
| --- | --- | --- | --- | --- | --- |
| リードアーキテクト | 7統制の設計、顧客との合意形成 | ● | ● | ● | ○ |
| 統合エンジニア | MCP 化、Camel/Kafka、補償処理 | — | ● | ● | — |
| 基盤・可観測性エンジニア | OpenShift、ゲートウェイ、OpenTelemetry、監視 | ○ | ● | ● | ● |
| AI エンジニア | 推論基盤、評価、ガードレール | ○ | ● | ● | ● |

●：常駐、○：スポット。

### 前提条件

- 顧客側に、業務オーナーとリスク管理（または監査）部門の窓口がいる。
- 接続対象の基幹に、API または統合層（Camel、ESB、MQ など）から到達できる。
- M1 以降は、検証用の OpenShift 環境と推論の手段（自社 GPU または承認済みの外部 LLM）を用意できる。
- 本番データを使う場合は、顧客の社内規程に沿ってマスキングするか、利用の承認を得ている。

### 除外事項

- モデルの事前学習と大規模なファインチューニング（別メニュー）。
- エージェントの業務ロジック（プロンプトや画面）の本開発。接続と統制を示すための最小限に限る。
- 法律上の判断（適法性の最終判断は顧客の法務部門が行う）。
- 基幹側の改修（必要な場合は Agent-Ready モダナイゼーションで別途見積る）。

## 7. 差別化と競合との位置づけ

差別化の核は2つです。統制5の **エージェントが基幹に書き込んだあとの整合性** と、統制6の **推論から基幹までを一本で追える可観測性** です。どちらも、金融のミッションクリティカルな統合（Outbox、Saga、MQ、Kafka）と OpenShift 基盤の実績がないと設計できません。

| 競合のタイプ | 強み | 手薄なところ | 本メニューの立ち位置 |
| --- | --- | --- | --- |
| AI 専業ベンダー | モデル、プロンプト、RAG | 基幹統合、更新系の整合性、運用 | 作ったエージェントを本番につなぐ後工程として協業する |
| 大手 SIer | 業務知識、大規模な体制 | エージェント特有の統制の型、OSS の最新動向 | 設計の型と参照実装を提供し、構築はパートナーと分担する |
| ハイパースケーラー | マネージドなエージェント基盤 | オンプレミスの基幹、マルチクラウド、データの所在 | ハイブリッド前提で、特定クラウドに依存しない統制を提供する |
| オブザーバビリティ製品ベンダー | LLM のトレースと評価 | 基幹側のトランザクションとの紐付け | OpenTelemetry で結び、製品は顧客の選択に合わせる |

### 再利用できる社内資産

- 金融の統合パターン（Outbox、サーキットブレーカー、例外設計、MQ 連携）。顧客名を伏せてパターン化したものに限る。
- Kafka と Saga による分散トランザクション、分散トレーシングと監視の構成。
- API 基盤の構成（RHBK、blue/green、GitOps）。
- Connectivity Link と Service Mesh のトレーニング教材。
- Fuse→Camel 移行の課題一覧と支援の実績。

## 8. リスク、社内ゲート、未決事項

外部へ出す前に、次の3つのゲートを通します。通すまでは、本書と提案書は社内検討用に留めます。

| ゲート | 確認すること | 確認先 |
| --- | --- | --- |
| G1 社内整合 | 既存のコンサルティングメニューと重複しないか。メニュー名と位置づけ | コンサルティング部門の責任者 |
| G2 製品との整合 | 参照アーキテクチャが、製品のロードマップとサポート範囲に沿うか | AI 製品、Connectivity Link の製品チーム |
| G3 守秘と表現 | 過去案件の知見が顧客を特定できない形になっているか。外部向けの表現 | 法務、マーケティング |

### リスクと対策

| リスク | 影響 | 対策 |
| --- | --- | --- |
| MCP や Gateway API などの仕様が変化する | 参照実装がすぐ古くなる | メニューは7統制の原則で定義し、実装は差し替えられる前提にする |
| 可観測性のデータに個人情報が含まれる | 監視基盤自体が情報漏えいの経路になる | トレースの保存前にマスキングし、保管期間とアクセス権を定める |
| PoC が本番化につながらない | M1 で止まる | M0 で本番化の判断基準を先に合意する |
| 提供できる人材が少ない | 受注しても回せない | 教材とテンプレートを先に整備し、パートナーを育成する |

### 未決事項

- 正式なメニュー名（「Agent Safe-Connect」は仮称）。
- 工数単価と、M0 を固定価格にするかどうか。
- パイロット顧客（金融の既存顧客から2〜3社を候補にする）。

### 次のアクション

- [ ] デモのシナリオを確定する（残高照会と振込予約、障害注入とトレースでの原因特定を含む）
- [ ] M0 のアセスメントキット（質問票、採点表、レポート雛形）を作る
- [ ] 提案書と、1枚ものの資料を作る
- [ ] G1〜G3 の確認を依頼する
- [ ] 本書を v0.2 に更新する（工数単価、パイロット顧客を反映）