# 動画台本（Day 2）

# Day 2：「安全につなぐ」を7つの統制に分ける（約3分）

**ねらい：** 7つの統制と M0〜M3 のメニュー体系、成熟度モデルが「同じ物差し」でつながっていることを伝える。
**映すもの：** `docs/01_offering_definition.md`（参照アーキテクチャ図）、`assessment-kit/maturity-model.yaml`、`docs/03_offering_scope_and_effort.md`。

| 時間 | 画面 | ナレーション | テロップ |
| --- | --- | --- | --- |
| 0:00 | タイトル画面 | 今日の結論です。「安全につなぐ」は、そのままでは提案にも見積りにもなりません。7つの統制に分けると、設計・診断・運用を同じ物差しで語れるようになります。 | Day 2：7つの統制 |
| 0:15 | 定義書の統制表 | 1 Identity、エージェントの身元と、利用者からの権限委任。2 Authorization、ツール単位の最小権限。3 Guardrails、入力と出力の検査。4 Blast Radius、回数や金額の上限と人間の承認。5 Transactional Safety、書き込みの冪等性と補償。6 Observability、全層を一本のトレースで追う。7 Audit、誰の指示で何をしたかの証明です。 | 7つの統制 |
| 0:55 | 参照アーキテクチャ図 | 図にするとこうなります。すべての呼び出しはゲートウェイを通ります。左の Identity と右の可観測性、下の監査は、全層を横断します。可観測性を独立した統制にしたのは、ほかの統制の土台だからです。見えないものは、統制も説明もできません。 | 可観測性は土台 |
| 1:19 | 成熟度モデル（L1〜L5）の表 | 統制ごとに5段階の成熟度を決めました。L3 が本番の最低ラインです。金銭や個人情報が絡む業務では、可観測性と監査を L4 にします。採点は「最も低い質問のレベル」で決めます。弱い環が全体を決めるからです。 | L3＝本番の最低ライン |
| 1:39 | メニュー表 M0〜M3 | メニューは4段階です。入口は M0 の診断、2〜3週間。次に M1 で1業務の PoC、M2 で全社基盤、M3 で継続支援。どの段階も、7つの統制で成果物を書きます。 | 入口は M0 |
| 1:56 | `03` の M0 WBS 表 | 工数も作業単位に分けました。M0 は標準18人日。ヒアリングは4部門、各90分。増える要因と減る要因も書いておくと、見積りの説明が楽になります。 | M0 は標準18人日 |
| 2:10 | 締め | 明日は、この7つが全部「動くところ」を見せるデモの台本を書きます。 | 次回：デモの台本 |


---

# 参考資料：01_offering_definition.md

# 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 に更新する（工数単価、パイロット顧客を反映）


---

# 参考資料：03_offering_scope_and_effort.md

# 03. スコープと工数モデル（Day 2）

2026-10-05 · 社内検討用

M0 は標準18人日（15〜20人日）、M1 は標準約90人日で見積ります。本書はその内訳（WBS）と、見積りを増減させる要因、成果物の定義です。単価は未決のため、金額は「人日 × 単価」で計算する形にしています（単価は v0.2 で確定）。

## 1. M0 エージェント接続レディネス診断（2〜3週間）

| # | 作業 | 内容 | 成果物 | 人日（標準） |
| --- | --- | --- | --- | --- |
| 0-1 | キックオフ | 対象業務、関係部門、既存 PoC の確認。ヒアリング日程の確定 | キックオフ資料、ヒアリング計画 | 1.5 |
| 0-2 | 事前資料の読み込み | 構成図、セキュリティ規程、PoC の設計書 | 論点メモ | 2 |
| 0-3 | ヒアリング（4部門×90分） | 業務、基盤、リスク管理・監査、運用 | ヒアリング記録 | 3 |
| 0-4 | 接続候補の棚卸しとリスク分類 | 参照のみ／更新あり／金銭・個人情報、の3区分 | 接続候補一覧 | 2 |
| 0-5 | 7統制の成熟度評価 | 質問票の採点、証跡の確認 | 採点表（`assessment-kit/`） | 2.5 |
| 0-6 | ギャップ分析とロードマップ | 本番の最低ライン（L3）との差、施策の優先順位 | ロードマップ案 | 3 |
| 0-7 | 報告書の作成とレビュー | 社内レビュー（品質ゲート）を含む | 診断レポート | 3 |
| 0-8 | 報告会 | 経営層・関係部門向け。M1 の対象業務の合意 | 報告会資料 | 1 |
| | **合計** | | | **18** |

**増える要因：** 関係部門が5つ以上（+1〜2人日）、接続候補が20件以上（+2人日）、英語での報告（+1人日）。
**減る要因：** 対象業務が1つに決まっている（−2人日）、既存の PoC 設計書が揃っている（−1人日）。

## 2. M1 参照アーキテクチャと PoC（6〜8週間）

| フェーズ | 週 | 主な作業 | 体制 | 人日（標準） |
| --- | --- | --- | --- | --- |
| 設計 | 1〜2 | 対象業務のツール設計（参照／更新の分離）、7統制の設計、評価セットの設計 | リード、統合 | 16 |
| 構築① ツール層 | 2〜4 | 既存 API・Camel ルートの MCP 化、冪等キー、Outbox | 統合、基盤 | 22 |
| 構築② 統制層 | 3〜5 | ゲートウェイの認証・認可・回数制限、権限委任、ガードレール | 基盤、AI | 20 |
| 構築③ 可観測性と監査 | 4〜6 | 全層のトレース、ダッシュボード、監査証跡、障害注入 | 基盤、AI | 18 |
| 評価と報告 | 6〜8 | 評価セットの実行、障害注入テスト、本番化判断の材料 | 全員 | 14 |
| | | | **合計** | **90** |

**M1 の完了条件（本番化の判断材料として渡すもの）**

- 9つのデモ場面（`docs/04_demo_scenario.md`）に相当する確認が、顧客の業務で通っている
- 評価セットで、安全性の違反が0件である
- 障害の原因層を、トレースから10分以内に特定できることを、運用部門が自分で確かめている
- 監査部門が、監査証跡の検索と改ざん検知を自分で行える

## 3. M2 Agent Gateway 基盤の構築（3〜6か月）

| フェーズ | 期間 | 内容 |
| --- | --- | --- |
| 基盤設計 | 1か月 | 全社共通ゲートウェイ、ツールカタログ、エージェント用クライアントの発行手順、可観測性基盤（Tempo / Prometheus / Grafana） |
| 構築 | 1〜3か月 | 本番環境の構築、ポリシーの GitOps 化、監査証跡の永続化 |
| 移行・横展開 | 1〜2か月 | M1 の業務を本番へ移行。2業務目の接続を顧客と一緒に実施（自走の練習） |

工数は、接続する業務の数と環境の数で大きく変わるため、M1 の結果をもとに個別に見積ります。目安は、リード1名と基盤・統合のエンジニア2名で3〜6か月です。

## 4. M3 AgentOps 継続支援（月額）

| 項目 | 頻度 | 月あたり工数の目安 |
| --- | --- | --- |
| 評価セットの実行と更新 | 月次、およびモデル・プロンプトの変更時 | 2人日 |
| 品質・コスト・インシデントのレビュー | 月次 | 1.5人日 |
| ポリシー（権限、上限、ガードレール）の見直し | 四半期 | 1人日（月平均） |
| 問い合わせ対応 | 随時 | 1人日 |
| **合計** | | **5.5人日／月** |

## 5. 見積りの計算式

```
見積額 = Σ（作業の人日 × 増減係数）× 単価 + 旅費・環境費（実費）
```

単価、M0 を固定価格にするか、パートナーとの分担比率は未決です（定義書の第8章）。見積りの雛形は `presentations/proposal/m0_estimate.xlsx` にあります。