DISCOVERY PHASE

本開発の前に、
投資判断できる状態を
固定する。

Discovery Phaseは、要件定義やPoCの言い換えではありません。 AI導入を「責任を持って使い続けられる判断インフラ」に変換するために、 判断範囲、精度指標、証跡、監査、責任分界、継続運用を先に確定します。 その結果として、本開発を段階投資に変換し、失敗コストを最小化します。

Outcome
投資判断支援資料として提出可能な形に固定
Governance
ISO/IEC 42001参照の監査と説明設計
Continuity
再学習、変更管理、移管可能性を前提にする
DELIVERABLES

机上の資料ではなく、
本開発の「止まらない前提」を固定する成果物

Discovery Phaseのゴールは、要件を綺麗に書くことではありません。 経営がGo/No-Goを判断でき、実装に入っても説明責任と継続運用が破綻しない状態に固定します。

Decision

判断範囲と介入点の確定

AIに任せる領域と、人が最終判断する領域を明確化。現場の介入ポイント、例外処理、停止条件まで含めて設計します。

  • AIが出すべき出力と、出してはいけない出力
  • Human-in-the-loopの介入条件と責任線
  • 運用停止とロールバックの条件
Quality

精度指標と受入基準の設計

「当たった/外れた」ではなく、業務に必要なSLOを指標に落とします。閾値、サンプリング、評価手順を固定します。

  • 評価指標と閾値(SLO)
  • データ分割と検証プロトコル
  • バイアスとドリフト検知の方針
Evidence

証跡と監査の要件定義

事故や苦情が起きたときに説明不能にならないために、ログ、根拠、再現性を「先に」仕様化します。

  • ログ項目と保存期間、閲覧権限
  • 説明可能性要件とレポート出力
  • 監査観点と証跡の紐付け
Risk

リスク整理と意思決定ログ

技術リスクだけでなく、運用、法務、信用の破壊リスクを洗い出し、軽減策と判断根拠を文書化します。

  • リスクレジスターと対策ロードマップ
  • 例外ケースと責任分界の整理
  • Go/No-Go判断に必要な論点
Continuity

継続運用と変更管理の設計

本番導入後の再学習、モデル更新、データ変更、障害対応を前提に、止めずに回す運用仕様を設計します。

  • 再学習の条件、頻度、承認フロー
  • ドリフト監視とアラート設計
  • 変更管理とリリース手順
Finance

段階投資レンジと実装計画

実装スコープを境界づけ、コストと期間をレンジで提示。ステークホルダー説明に耐える計画に落とします。

  • スコープ境界とMVP定義
  • 体制案、進行案、リスク織り込み
  • 銀行や監査側への説明材料
OUTPUT FORMAT
最終成果は、経営会議・投資家・金融機関・監査対応に提出できる構成でまとめます。 本開発に入る前に「判断と責任が一致している状態」を固定します。
GATED PROCESS

週次で進めるのではなく、
ゲートで止めて、判断する。

Discovery Phaseは「作業の進捗」ではなく「判断の確度」を積み上げます。 各ゲートで証跡と論点を固定し、次の投資に進むかを経営が決められる状態にします。

G1
Scope Lock
判断範囲と前提を固定
  • 目的と適用範囲、対象業務の確定
  • AIの出力、禁止出力、例外系の整理
  • Human-in-the-loopの介入条件と責任線
Gate Output
判断範囲定義と介入点一覧
G2
Data Fit
データ適合性を確定
  • 必要データと取得元、欠損、品質課題の整理
  • 学習と評価に使えるかの可否判定
  • データ提供者、権利、運用負荷の整理
Gate Output
データ適合性レポートと不足分
G3
Quality SLO
精度指標と受入基準を固定
  • 評価指標、閾値、検証プロトコルの確定
  • バイアス、ドリフト、例外ケースの扱い
  • 本番監視に接続できる形で定義
Gate Output
SLO定義と受入テスト仕様
G4
Evidence
証跡と監査要件を固定
  • ログ要件、保存、閲覧権限の確定
  • 説明可能性レポートの出力要件
  • 監査観点と証跡紐付け
Gate Output
証跡仕様と監査チェック項目
G5
Plan & Range
段階投資と実装計画を確定
  • MVP境界、スコープ、体制案の確定
  • 費用と期間のレンジ提示、リスク織り込み
  • Go/No-Goの最終判断材料を統合
Gate Output
投資判断支援資料と実装ロードマップ
FIT

こういう案件は、
Discovery Phaseを先にやるべき

実装の成否は、モデルではなく「判断と責任の設計」が先に固まっているかで決まります。 先にやるべき案件を、明確に切り分けます。

New Build

初回のAI導入

要件もデータも固まっていない状態で本開発に入ると、ほぼ確実に予算と責任が爆発します。

  • 判断範囲が曖昧で、現場が使い切れない
  • 精度の合格ラインが決まっていない
  • ログや説明が後付けになる
Rescue

途中で炎上したAI案件

原因は技術ではなく統治の欠損であることが多い。責任線と証跡を先に修復します。

  • 誰が最終判断者か不明
  • 評価方法がバラバラで合意できない
  • 運用停止の条件がない
Audit

監査や金融機関説明が必要

説明責任を求められる案件は、後から整えても間に合いません。最初から監査前提で固定します。

  • 監査観点と証跡が紐づいていない
  • 意思決定ログが残っていない
  • 再学習と変更管理が未設計
Continuity

止めずに使い続けたい

納品して終わりではなく、継続運用の責任まで設計対象に含める必要がある案件です。

  • 運用で劣化する前提がある
  • ドリフト監視と再学習が必要
  • 移管可能性やBCPが重要
PROCESS

6〜10週間で、
投資判断できる状態に固定する

週次で進めます。ただし目的は進捗ではなく、各週で「判断の根拠」が増えていくことです。 最終的に、経営がGo/No-Goを判断できる資料として提出可能な形にまとめます。

W1
Kickoff / Scope Lock
判断範囲、目的、制約を確定
  • 対象業務とユースケースの境界を定義
  • AIの出力と禁止出力、例外系の整理
  • 介入点と最終判断者の確定
Output 判断範囲定義、介入点一覧、前提条件
W2
Data Fit
データ適合性の可否判定
  • 必要データと取得元、欠損、品質課題の整理
  • 学習と評価に使えるかの可否判定
  • 権利、提供者、運用負荷の整理
Output データ適合性レポート、不足分、取得計画
W3
Quality SLO
精度指標と受入基準を固定
  • 評価指標、閾値、検証プロトコルの確定
  • 例外ケース、バイアス、ドリフト方針の整理
  • 本番監視へ接続できる形で定義
Output SLO定義、受入テスト仕様、評価手順
W4
Evidence / Audit
証跡と監査要件を固定
  • ログ項目、保存期間、閲覧権限の確定
  • 説明可能性レポートの出力要件
  • 監査観点と証跡の紐付け
Output 証跡仕様、監査チェック項目、説明設計
W5
Plan / Range
段階投資レンジと実装計画
  • MVP境界とスコープの確定
  • 体制案、期間、費用レンジの提示
  • リスク織り込みとGo/No-Go材料統合
Output 投資判断支援資料、実装ロードマップ
COMMERCIALS

価格は「作業量」ではなく、
リスクを潰す範囲で決まる

Discovery Phaseは見積作業ではありません。事故が起きた瞬間に「説明不能」にならないための設計です。 成果物は、投資判断支援資料として提出可能な形に固定します。

Discovery Phase
6〜10 weeks
Fee Range
要件とデータ状況で変動
含まれるもの
  • 判断範囲と介入点の確定
  • 精度指標(SLO)と受入基準設計
  • 証跡・監査・説明設計(ISO/IEC 42001参照)
  • リスクレジスターと意思決定ログ
  • 継続運用と変更管理の前提設計
  • 段階投資レンジと実装ロードマップ
別途になりやすいもの
  • データ購入費、アノテーション費
  • 現場実測や追加ヒアリングの増加分
  • 第三者監査や法務レビューの実費
  • モデル開発・実装(Phase2以降)
目的は「安く作る」ではなく、「事故と炎上でCEOの信用が死ぬ確率」を先に潰すことです。 そのため、ゲートを省略して短縮することはしません。
支払い
マイルストーン成果物確認後に分割
進め方
週次MTG + 中間レビュー + 最終プレゼン
成果
提出可能な投資判断支援資料に固定
FAQ

よくある質問

Discovery Phaseの位置づけと、導入判断の前提が揃うかどうかで誤解が起きやすいポイントだけに絞って回答します。

PoCや要件定義と何が違うのですか
PoCは技術的に動くかを確かめる行為です。要件定義は仕様を決める行為です。 Discovery Phaseはそれらを包含しつつ、AIを業務に組み込むために必要な 判断範囲、精度指標、証跡、監査、責任分界、継続運用を先に固定します。 結果として、経営がGo No-Goを判断できる状態になります。
要件が曖昧でも相談できますか
むしろ曖昧な状態で本開発に入る方が危険です。 Discovery Phaseは、曖昧さを「放置」するのではなく、曖昧さを 分解して、論点と未確定項目をログとして残し、固定できるところから固定します。
どの時点でやめる判断ができますか
各ゲートでGo No-Goが可能です。 代表的には、データ適合性が成立しない、品質SLOが事業として成立しない、 運用コストが過大になる、監査要件を満たせない、などが明確になった時点で止められます。 「止めるための判断材料」を先に作るのがDiscovery Phaseの本質です。
既存ベンダーの開発が進んでいる案件でもできますか
可能です。ただし前提として、責任線、評価方法、ログ、変更管理が曖昧なまま 進んでいる場合、どこかで説明不能になります。 Discovery Phaseはベンダー置換が目的ではなく、統治の欠損を埋めて 継続運用できる形に整えることが目的です。
最終成果物は何が出てきますか
投資判断支援資料として提出可能な形に固定します。 具体的には、判断範囲定義、精度指標SLOと受入基準、データ適合性レポート、 リスクレジスター、証跡と監査設計、継続運用と変更管理の設計、実装ロードマップと費用レンジです。
ISO/IEC 42001に準拠しているのですか
認証の代行ではありません。参照規格として、監査可能性と説明責任の設計論点を Discovery Phaseの成果物に落とします。 結果として、金融機関、投資家、監査法人に説明可能な構造になりやすくなります。
CLOSE

まずは30分で、
DPが必要か不要かを即決する

要件やデータが曖昧でも構いません。曖昧なまま本開発に入る方が危険です。 30分で論点を棚卸しし、判断範囲、精度、責任、証跡、運用のどこに穴があるかを特定します。 必要なら、最短距離のゲートと成果物スコープを提示します。

What you get
論点整理と、DP要否の即判断
If DP is needed
ゲート設計と成果物スコープ提示
If DP is not needed
すぐ実装に入るべき条件を提示