# 動画台本（Day 1）

# 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つの統制 |


---

# 参考資料：02_market_hypothesis.md

# 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）
- [ ] 競合の具体的な提供メニューは、公開情報を出典付きで追記する


---

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