# Day 1：PoC の次で止まる理由を、過去案件から読み解く（約2分）

**ねらい：** 新メニューの出発点が「流行の技術」ではなく「過去案件で繰り返し見た詰まり方」であることを伝える。
**映すもの：** `docs/02_market_hypothesis.md`、`docs/01_offering_definition.md` の顧客課題。

| 時間 | 画面 | ナレーション | テロップ |
| --- | --- | --- | --- |
| 0:00 | タイトル画面 | 今日の結論から言います。AI エージェントの本番化を止めているのは、多くの場合モデルの性能ではありません。セキュリティ、監査、可観測性、そして障害時の責任です。この10日間で、それを解決するコンサルティングメニューを作ります。 | Day 1：PoC の次で止まる理由 |
| 0:22 | 定義書の「顧客の課題」の引用 | よく聞くのがこの言葉です。「PoC はうまくいった。でも基幹系につなぐ段階で、本番に出せない」。止める理由を分解すると、4つの壁になります。 | 4つの壁：セキュリティ／監査／可観測性／障害時の責任 |
| 0:36 | `02` の棚卸し表をスクロール | まず、自分の過去2年の案件を読み直しました。顧客名は伏せて、業種と案件の型だけにしています。見たのは「この案件にエージェントがつながったら、何が問題になるか」です。 | 過去案件7件を読み直す |
| 0:53 | 表の「統制5」「統制6」の列を強調 | 分かったことは3つです。1つ目、金融の統合案件では、更新の二重実行や補償はすでに日常の論点でした。エージェントは新しい呼び出し元にすぎません。2つ目、可観測性はどの案件でも後回しでした。3つ目、権限の設計は API 基盤の延長でできますが、「人の権限を一部だけエージェントに渡す」という観点は新しいものです。 | 既存の統合資産が、そのまま効く |
| 1:23 | 仮説 H1〜H5 の表 | ここから仮説を5つ立てました。たとえば H1、「本番化を止めているのは技術ではなく、リスク管理と監査の承認だ」。それぞれに、確かめ方と、外れたときにどう方針を変えるかを書いています。 | 仮説には「外れたら」を書く |
| 1:42 | 競合の見取り図の表 | 競合はタイプで整理しました。AI 専業、SIer、ハイパースケーラー、可観測性の製品ベンダー。どこも強みがありますが、「エージェントが基幹に書き込んだ後」まで面倒を見るところは少ない。ここが勝ち筋です。 | 勝ち筋：書き込んだ後まで守る |
| 2:02 | 締め（顔出し任意） | 明日は、この「安全につなぐ」を、設計にも診断にも使える7つの統制に分けます。 | 次回：7つの統制 |