# 動画台本（Day 9）

# Day 9：6つの立場で自分の提案を叩く（約2分）

**ねらい：** 提案を外に出す前に、異なる立場から指摘を集めて直すプロセスを見せる。正式な承認とは別物であることを明確にする。
**映すもの：** `docs/06_internal_review.md`。

| 時間 | 画面 | ナレーション | テロップ |
| --- | --- | --- | --- |
| 0:00 | タイトル画面 | 今日の結論です。作った本人が一番気づけないのは、自分の提案の穴です。営業、デリバリー、製品、法務、技術、そして顧客の立場で、模擬審議をしました。 | Day 9：社内レビュー |
| 0:14 | 冒頭の注意書き | 最初にお断りしておきます。これは AI に6つの立場を演じさせた模擬審議で、実際の部門の承認ではありません。正式な承認は、このあと社内ゲートで取ります。 | 模擬審議 ≠ 承認 |
| 0:29 | 指摘一覧の表 | 指摘は15件。そのうち9件はその場で直し、6件は未決として残しました。直したものの例は、M1 の完了条件に「評価で安全性の違反0件」を加えたことです。 | 15件中9件を対応 |
| 0:44 | 指摘12・15の行 | 未決のものも正直に残しています。たとえば、デモ用の改ざん API が本番のイメージに入ったままになること。トレースに口座 ID と利用者名がそのまま入っていること。どちらも M1 までに対応します。 | 未決も隠さない |
| 1:04 | 資料ごとの確認結果の表 | 資料ごとに、顧客名が出ていないか、断定的な表現がないかを確認しました。たとえば「FISC に準拠」とは書かず、「参照する」と書いています。 | 断定しない |
| 1:18 | 社内ゲート G1〜G3 の質問 | 社内ゲートには、具体的な質問を持ち込みます。既存メニューとの重なり、製品のサポート範囲、商標。質問を先に書いておくと、レビューする側も答えやすくなります。 | 質問を書いて持ち込む |
| 1:33 | 締め | 最終日の明日は、最初の顧客にどう持ち込むかと、3年後の姿を描きます。 | 次回：打診と3年後 |


---

# 参考資料：06_internal_review.md

# 06. 社内レビュー（Day 9）

2026-10-05 · 社内検討用

**このレビューは、Claude が6つの立場を想定して行った模擬審議の記録です。実在の部門や担当者の承認ではありません。** 正式な承認は、第3章の社内ゲート G1〜G3 で、実際の担当者から得てください。

模擬審議の結論は **「条件付きで、M0 の非公式打診は開始してよい」** です。対外配布の前には、G1〜G3 の通過が必要です。指摘15件のうち9件は対応済み（一部対応1件を含む）、6件は未決として残しました。

## 1. 審議の観点と指摘

| # | 立場 | 指摘 | 対応 | 状態 |
| --- | --- | --- | --- | --- |
| 1 | 営業 | 入口が M0 の1つに絞られていて売りやすい。ただし単価が未定で、見積りを出せない | 見積り雛形（`presentations/proposal/m0_estimate.xlsx`）を作り、単価だけ入れれば計算できるようにした | 一部対応（単価は未決） |
| 2 | 営業 | 顧客の「この発言が出たら」を営業が覚えやすい形にしてほしい | 勉強会資料と1枚ものに、購買のきっかけ4つを載せた | 対応済み |
| 3 | デリバリー | M1 の90人日は、6〜8週間・2〜4名と整合するか | 3.5名×7週×5日＝約120人日が上限で、90人日はその範囲内。設計・構築・評価の内訳を `03` に記載 | 対応済み |
| 4 | デリバリー | M1 の完了条件に「評価」が入っていない | 定義書の「M1 で必ず入れるもの」に評価セット（攻撃ケース、違反0件）を追加 | 対応済み |
| 5 | デリバリー | 提供できる人材が少ない（統合と AI の両方が分かる人） | 勉強会資料と、動くデモ・評価セットを教材として先に整える。パートナー育成は Year 2 | 未決（体制） |
| 6 | 製品 | Connectivity Link の TokenRateLimitPolicy は新しい API。製品バージョンでのサポートを確認したか | マニフェストと runbook に「要確認（G2）」と明記。クラスタへの適用は未実施 | 未決（G2） |
| 7 | 製品 | 参照アーキテクチャが、製品のロードマップ（AI ゲートウェイ、MCP 関連機能）と食い違わないか | 実装は差し替え可能とし、メニューは7統制の原則で定義している。製品チームに確認する | 未決（G2） |
| 8 | 法務・守秘 | 過去案件の知見が、顧客を特定できる形で外部資料に出ていないか | 提案書・1枚ものに顧客名や固有の構成がないことを確認。棚卸し（`02`）は業種のみに置き換え済み | 対応済み（`07` は社外秘） |
| 9 | 法務・守秘 | 「FISC 安全対策基準に準拠」のような断定は避けるべき | 資料では「参照する」「論点」と表現しており、準拠を保証する表現はない | 対応済み |
| 10 | 法務・守秘 | メニュー名「Agent Safe-Connect」の商標・社名との衝突を確認したか | 仮称のまま。正式名は G1・G3 で決める | 未決（G1・G3） |
| 11 | 技術 | デモのパスワード・グラントを本番の設計と誤解されないか | デモシナリオ、runbook、デモのコードのコメントに「デモ専用。本番は認可コード + PKCE とトークン交換」と明記 | 対応済み |
| 12 | 技術 | デモの改ざん用 API（`/api/demo/*`）が、本番イメージに入ったままになる | demo-admin ロールで保護し「本番に含めない」とコメント済み。ビルド時に無効化する設定は未実装 | 未決（M1 までに対応） |
| 13 | 技術 | ガードレールが正規表現だけでは、本番の顧客に説明しにくい | 「アプリ側は内側の防御。本番はゲートウェイ側に専用の検出器」と資料に明記。評価セットに攻撃ケースを入れて測る運用にした | 対応済み |
| 14 | 顧客（リスク管理）視点 | 「暴走時の最大影響」を数値で示せるか | デモでは上限100万円、自動承認10万円、更新10回／分と設定値で示せる。M0 の質問 BR-4 で顧客ごとに試算する | 対応済み |
| 15 | 顧客（運用）視点 | 可観測性の基盤自体が個人情報の漏えい経路にならないか | 質問 OB-5 と定義書のリスク表に追加済み。ただしデモのトレースには口座 ID（`tool.target`、利用者名 `enduser.id`）がそのまま入っている。顧客の個人情報の定義に合わせ、M1 で仮名化かマスキングをする | 未決（トレースの仮名化とマスキング検査は未実装） |

## 2. 資料ごとの確認結果

| 資料 | 確認したこと | 結果 |
| --- | --- | --- |
| 提案書（12枚） | 顧客名の有無、断定表現、数値の出典（デモの実測のみ） | 問題なし。表紙のノートに「社外配布前に G1〜G3」と記載 |
| 1枚もの | 同上 | 問題なし |
| 勉強会資料（8枚） | 社内向け。パイロット候補の社名は載せていない | 問題なし |
| 定義書・`02`〜`05` | 社内検討用の表示 | 問題なし |
| `07` パイロット打診の準備 | 実在の顧客名を含む | **社外秘**。共有範囲をアカウントチームに限る |

## 3. 社内ゲートに出す質問（実際の担当者向け）

### G1 社内整合（コンサルティング部門の責任者）

- [ ] 既存のコンサルティングメニュー（AI、API 管理、アプリケーション・モダナイゼーション）と重なる範囲はどこか
- [ ] M0 を固定価格にしてよいか。単価の目安はいくらか
- [ ] 正式なメニュー名と、社内のどのカタログに載せるか

### G2 製品との整合（AI 製品、Connectivity Link の製品チーム）

- [ ] TokenRateLimitPolicy を含む Connectivity Link の API を、導入先の製品バージョンでサポートしているか
- [ ] MCP の経路に統制をかける製品機能（MCP ゲートウェイ等）の予定と、本メニューの参照アーキテクチャの関係
- [ ] OpenShift AI（vLLM、llm-d、Llama Stack）との組み合わせで推奨する構成

### G3 守秘と表現（法務、マーケティング）

- [ ] 過去案件のパターン（業種のみ表記）を提案に使ってよい範囲
- [ ] 規制・ガイドライン（FISC、AI事業者ガイドライン、EU AI Act）への言及の仕方
- [ ] 仮称の商標確認

## 4. 次の版（v0.2）で直すこと

- [ ] 単価と M0 の価格形態を、G1 の結果で確定する
- [ ] デモ用 API をビルド時に無効化する設定を入れる（指摘12）
- [ ] トレースのマスキング漏れを検査する仕組みを、M1 の標準作業に入れる（指摘15）
- [ ] G2 の回答をもとに、参照アーキテクチャ図とマニフェストを更新する