AIの出力を信じていい条件──検証の型（事実／推測／未確認）

AIを仕事で使っていて一番困るのは、「間違うこと」そのものではありません。
困るのは、それっぽい顔をした誤りが混ざり、意思決定や合意形成に混乱が起きることです。

だから検証は、気合や注意力ではなく、型でやります。

結論：AIの出力は“全部仮置き”。確度ラベルで扱う

AIの回答を読んだ瞬間に、頭の中で3つに分けます。

• 事実（Fact）：一次情報や根拠に当てれば確認できる

• 推測（Assumption）：妥当そうだが裏取りが必要（前提が置かれている）

• 未確認（Unknown）：根拠が薄い／具体が不足／AIが作っていそう

このラベル付けだけで、プロジェクト現場の事故（誤った合意、間違った計画、誤報告）がかなり減ります。

まず知っておくこと：AIは“検索結果”ではなく“回答っぽい文章”が返る

インターネット黎明期、Googleで出てきた情報をそのまま信じず、複数ソースを突き合わせたり、一次情報に当たりに行ったりしました。
AIも本質は同じです。ただし違いは、リンクではなく文章で返ってくる点。だからこそ「正しそう」に見える。検証が不要になったわけではありません。

検証の型：5ステップ（プロジェクト現場で回る形）

Step1：主張を“短文”に分解する

文章のまま読むと流れに飲まれます。主張を箇条書きにします。
（例：WBS提案、工数見積、リスク列挙、要件の解釈、優先順位…）

Step2：各主張にラベル（Fact／Assumption／Unknown）を付ける

• 数字、日付、契約条件、規程、固有名詞 → 原則Unknown寄り

• 「一般に〜」系の整理 → Assumptionになりやすい

• 自社・顧客の事情 → AIは基本Unknown（あなたの情報で埋める）

Step3：Factは一次情報で当てる（出典なしFactはFact扱いしない）

• 契約、RFP、決裁資料、議事録の決定事項、設計書、運用規程、実測ログ

• 「AIがそう言った」は根拠になりません

Step4：Assumptionは“反証条件”を書く

「何が起きたらこの前提が崩れるか」を明文化します。
（例：前提＝データ移行は既存IFで可能 → 反証＝データ定義が不一致／品質不足）

Step5：Unknownは“質問”に変えて回収する

Unknownを放置したまま計画や合意に入ると、後工程で爆発します。
関係者に聞く・資料に当たる・ログを見る、の順で潰します。

プロジェクトで特に危ない“検証必須”領域

• 見積・工数：根拠（前提条件、範囲、非機能、体制）なし見積は全てUnknown

• WBS：タスクの網羅性より「成果物と受入条件」が曖昧だと崩れる

• 要件解釈：「ユーザーが言ったこと」と「システム要件」を混ぜると事故る

• リスク：列挙より“検知指標”と“対応責任者”がないと機能しない

コピペ用：AIに自己点検させる（確度ラベル付け）

直前の回答を、次の形式で点検してください。
1) 主張の箇条書き（短文）
2) 各主張のラベル：Fact / Assumption / Unknown
3) Factを確認するための一次情報候補（社内文書・ログ等）
4) Assumptionの反証条件（何が起きたら崩れるか）
5) Unknownを埋める質問（抽象化したまま）

コピペ用：WBS叩き台の“検証付き”生成

目的：システム導入のWBS叩き台を作る（成果物ベース）
前提：固有名詞・金額・契約条件は使わない
出力：工程→タスク→成果物→受入条件（Draft）
最後に、未確認(Unknown)になりやすい前提と確認質問を20個出すこと

まとめ：信じていい条件＝「確度が見える」状態

AIの出力は、正しい／間違い以前に、確度が混ざっているのが問題です。
Fact／Assumption／Unknownに分け、Factは一次情報へ、Assumptionは反証条件、Unknownは質問化。この型で回せば、AIは“危ない箱”ではなく“使える道具”になります。

次はこの検証の型を前提に、議事録・報告・WBS・要件定義など、現場でそのまま使えるテンプレに展開していきます。

※本記事は一般的な情報提供です。最終判断は所属組織の規程・契約条件・セキュリティ方針を優先してください。

新シリーズ：仕事で使えるAI活用の型

次に読む：

はじめての方へ