第3章：情報の整理と分析
この章で作れる成果物
この章を読み終えると、次の成果物を作れる状態を目指します。
- 情報分類メモ: AI出力や収集資料を、事実、解釈、仮説、推定、推奨、要確認に分けたメモ。
- evidence matrix: 主張ごとに根拠、出所、確認日、信頼度、利用可否を整理した表。
- fact-check log: AI出力を業務成果物に使う前に、確認した一次情報、修正内容、未確認事項を残すログ。
第2章では、task brief を前提、論点、根拠、推論、反論、結論へ分解しました。第3章では、その「根拠」をさらに分類し、AI出力に含まれる事実らしい文を業務で使える証拠へ変換します。
本章とAI活用の標準業務フロー
本章は、AI活用の標準業務フロー（1枚） のうち、主に次の工程に対応します。
- 2. 情報分類: AIに渡してよい情報、根拠として使える情報、要確認情報を分ける。
- 3. 文脈設計: 出所、確認日、利用範囲、未確認事項をAIへ渡す。
- 7. 評価: AI出力の事実、解釈、仮説、推定、推奨を分けて点検する。
- 8. ファクトチェック: 一次情報、社内正本資料、承認済み資料で確認する。
- 10. ログ化・再利用: 確認済み根拠と未確認事項を再利用できる形で残す。
3.1 この章で扱う業務課題
AIを使うと、調査メモ、比較表、提案文、報告書の初稿を素早く作れます。一方で、出力には次のような混在が起きます。
- 確認済み事実と、AIの一般的な補完が混ざる。
- 解釈や仮説が、事実のように書かれる。
- 推定値や見込みが、確定値のように見える。
- 推奨案に必要な根拠、リスク、前提条件が抜ける。
- 出所、確認日、利用してよい範囲が残らない。
本章では、情報整理を「分類して見やすくする作業」ではなく、AI出力を検証可能な根拠へ戻す作業として扱います。
3.2 重要概念：5つの情報ラベル
AI時代の情報整理では、文を次の5種類に分けます。必要に応じて、未確認のものには 要確認 を付けます。
| ラベル | 意味 | 業務での扱い |
|---|---|---|
| 事実 | 確認可能な出来事、数値、記録 | 出所と確認日を残せば根拠候補になる |
| 解釈 | 事実に意味づけした説明 | 別解や前提条件を併記する |
| 仮説 | まだ検証していない説明案 | 検証方法と反証条件を置く |
| 推定 | 限られた材料から見込む値や状態 | 推定方法、幅、不確実性を示す |
| 推奨 | 取るべき行動の提案 | 判断理由、採用条件、リスクを添える |
3.2.1 事実
事実は、記録、資料、観察、測定により確認できる情報です。ただし、事実として扱うには出所と確認日が必要です。
事実: 5月10日の定例会議で、提案書の提出期限を5月24日に変更した。
出所: 会議録 v1.2
確認日: 2026-05-24
AIが「〜とされています」と書いた文は、それだけでは事実ではありません。一次情報や社内正本資料で確認できた段階で、事実として扱います。
3.2.2 解釈
解釈は、事実に意味を付ける説明です。解釈には観点や前提が入るため、別の解釈が成立する可能性があります。
事実: 問い合わせ件数が前月より増えた。
解釈: 新機能への関心が高まっている可能性がある。
別解: 画面変更により利用者が迷っている可能性もある。
3.2.3 仮説
仮説は、検証前の説明案です。仮説は悪いものではありませんが、事実と混ぜて書くと読み手が誤解します。
仮説: 導入後支援を強調すると、価格差への懸念を一部緩和できる。
検証方法: 過去提案の質疑、顧客ヒアリング、営業責任者レビューで確認する。
反証条件: 顧客が初期費用のみを判断基準にしている場合は成立しにくい。
3.2.4 推定
推定は、限られた材料から見込む値や状態です。推定には幅と不確実性があります。
推定: 提案前の追加確認には半日から1日程度かかる可能性がある。
根拠候補: 過去の同種提案で必要だった確認項目。
要確認: 今回の関係部門レビュー範囲。
推定を使う場合は、前提、方法、幅、未確認事項を明記します。
3.2.5 推奨
推奨は、取るべき行動の提案です。推奨は、事実、解釈、仮説、推定を踏まえた結論であり、根拠そのものではありません。
推奨: 次回提案では、導入後支援を主軸にし、価格差への補足資料を添える。
採用条件: 自社の支援範囲を営業責任者が確認する。
保留条件: 顧客が初期費用のみを判断基準にしている場合。
3.3 source hierarchy と evidence matrix
根拠には強弱があります。AI出力を確認するときは、次のような source hierarchy を使います。
- 一次情報: 公式発表、契約書、社内正本資料、会議録、実測ログ、原資料。
- 承認済み二次資料: 社内で承認された要約、正式な分析レポート、監査済み資料。
- 参考情報: 報道、業界解説、ブログ、SNS、第三者まとめ。
- AI出力: 根拠候補や論点候補。単独では根拠にしない。
3.3.1 evidence matrix の基本形
| 主張 | ラベル | 根拠/出所 | 確認日 | 信頼度 | 利用可否/要確認 |
| --- | --- | --- | --- | --- | --- |
| 導入後支援を重視する顧客がいる | 要確認（事実候補） | 共有許可済み営業メモ要約 | 2026-05-24 | 中 | 原メモの共有範囲を確認 |
| 価格差は主な失注理由である | 仮説 | 営業担当者の口頭コメント | 未確認 | 低 | 失注記録で確認 |
| 導入後支援を主軸にする | 推奨 | 上記根拠を踏まえた提案 | 2026-05-24 | 中 | 条件付き利用。支援範囲の承認が必要 |
この表では、主張をそのまま採用せず、ラベルと利用可否を分けています。特に、AI出力が作った主張は、最初は「要確認（事実候補）」または「仮説」として扱います。
3.3.2 evidence matrix をAIに作らせる指示例
次のAI出力を、事実、解釈、仮説、推定、推奨、要確認に分類してください。
各行に、根拠として使うために必要な出所、確認日、信頼度、追加確認事項を付けてください。
AI出力だけを根拠として扱わないでください。
未確認の主張は「要確認」と明記してください。
3.4 よくある失敗
失敗1：事実らしい文をそのまま採用する
AIが断定調で書いた文でも、出所がなければ根拠ではありません。まずは「要確認（事実候補）」として扱い、一次情報で確認します。
失敗2：解釈を事実として報告する
「問い合わせが増えた」は要確認（事実候補）です。「顧客の関心が高まっている」は解釈です。この2つを混ぜると、施策判断を誤る可能性があります。
失敗3：仮説を検証計画なしで使う
仮説は、検証方法と反証条件を置いて初めて使えます。「おそらく」「可能性がある」で終わる文は、次に何を確認するかまで書きます。
失敗4：推定値の幅を消す
推定は、幅や不確実性を持ちます。単一の数値や単一の見込みだけを書くと、読み手が確定情報として受け取る可能性があります。
失敗5：推奨だけを先に共有する
推奨だけを共有すると、承認者は根拠とリスクを追えません。推奨には、採用条件、保留条件、未確認事項を添えます。
3.5 改善前 → 改善後
改善前：AI出力をそのまま使う
競合A社は低価格を強く打ち出しており、市場では価格重視の傾向が強まっています。当社は導入後支援に強みがあるため、価格ではなく支援品質を訴求するのが最適です。
この文章には、次の問題があります。
- 競合A社の低価格訴求を確認した出所がない。
- 「市場では価格重視の傾向が強まっている」が事実か解釈か分からない。
- 「当社は導入後支援に強みがある」の根拠がない。
- 「最適です」という推奨に、採用条件と反論がない。
改善後：情報ラベルと evidence matrix に分ける
【分類】
- 競合A社は低価格を訴求している: 要確認（事実候補）。競合A社の公開資料で確認する。
- 市場では価格重視の傾向が強まっている: 仮説。市場調査または失注記録で確認する。
- 当社は導入後支援に強みがある: 要確認（事実候補）。自社の正式資料と提供条件で確認する。
- 支援品質を訴求するのが最適: 推奨。顧客の意思決定基準によって成立条件が変わる。
【evidence matrix】
| 主張 | ラベル | 根拠/出所 | 確認日 | 信頼度 | 利用可否/要確認 |
| --- | --- | --- | --- | --- | --- |
| 競合A社は低価格を訴求している | 要確認（事実候補） | 競合A社公開資料 | 要確認 | 未定 | 公開資料URLと確認日を記録 |
| 価格重視の傾向が強まっている | 仮説 | AI出力のみ | 未確認 | 低 | 市場調査または失注記録で確認 |
| 当社は導入後支援に強みがある | 要確認（事実候補） | 自社正式資料 | 要確認 | 未定 | 提供可能範囲を営業責任者が確認 |
| 支援品質を主軸にする | 推奨 | 上記確認後に判断 | 未確認 | 低 | 条件付き利用。顧客の重視条件を確認 |
改善後は、AI出力を否定しているのではありません。採用できる文、確認が必要な文、推奨として扱う文を分けています。
3.6 実務テンプレート：fact-check log
【対象成果物】
【確認日 / 確認者】
【確認対象の主張】
【分類】
- 事実:
- 解釈:
- 仮説:
- 推定:
- 推奨:
- 要確認:
【根拠】
| 主張 | 出所 | 確認日 | 利用可否 | 備考 |
| --- | --- | --- | --- | --- |
【修正内容】
- 断定を弱めた箇所:
- 出所を追記した箇所:
- 推奨から要確認へ移した箇所:
【残課題】
- 追加確認する一次情報:
- 承認者に確認する点:
- 再利用時の注意:
3.7 人間が最終判断すべき点
AIに分類や evidence matrix 作成を依頼しても、次は人間が判断します。
- どの資料を根拠として採用してよいか。
- 社内限定、機密、個人情報、契約情報を成果物に含めてよいか。
- 解釈や仮説をどの程度の確度で共有してよいか。
- 推定の幅や不確実性を読み手にどう伝えるか。
- 推奨を採用する条件、保留する条件、承認者を明示したか。
- 監査や再利用に耐えるログが残っているか。
章末演習
演習3-1：情報ラベルを付ける
次の文を、事実、解釈、仮説、推定、推奨、要確認に分類してください。
1. 5月10日の会議録には、提案書の提出期限が5月24日と記載されている。
2. 問い合わせ件数が増えたのは、新機能への関心が高まったためだと思われる。
3. 競合A社は低価格を訴求している可能性がある。
4. 追加確認には半日から1日程度かかる見込みである。
5. 次回提案では、導入後支援を主軸にすべきである。
6. 競合A社の最新公開資料は未確認である。
演習3-2：evidence matrix を作る
次のAI出力案から、主張を3つ以上抜き出し、ラベル、根拠/出所、確認日、信頼度、利用可否/要確認を整理してください。
競合A社は低価格を強く訴求しており、顧客は価格を重視しています。一方、当社は導入後支援に強みがあるため、支援品質を主軸に提案するのが有効です。
演習3-3：ファクトチェック計画を作る
「当社は導入後支援に強みがある」という主張を、社外提案書で使う前に確認すべき一次情報、社内承認者、修正文例を挙げてください。
演習3-4：推奨文を安全に書き換える
次の推奨文を、根拠、採用条件、保留条件、要確認事項が分かる形に修正してください。
市場では価格重視が進んでいるため、次回提案では値引きを前面に出すべきです。
理解度チェック
□ 事実、解釈、仮説、推定、推奨を分けて説明できる □ AI出力を根拠候補として扱い、一次情報で確認できる □ evidence matrix に出所、確認日、信頼度、利用可否を残せる □ 推定には幅と不確実性を添えられる □ 推奨には採用条件、保留条件、要確認事項を添えられる
章末の要点
- AI出力には、事実、解釈、仮説、推定、推奨が混ざります。
- AI出力は根拠そのものではなく、根拠候補や論点候補です。
- evidence matrix を使うと、主張ごとに出所、確認日、信頼度、利用可否を残せます。
- fact-check log を残すと、承認、監査、再利用がしやすくなります。
- 人間は、根拠の採用可否、情報分類、承認条件を最終判断します。
次章への橋渡し
第3章では、AI出力と収集資料を分類し、根拠確認と evidence matrix へ接続しました。次の第4章では、問題設定、仮説、意思決定、評価軸を使い、AI出力の採否判断へ進みます。
- 前章: 第2章：論理的思考の基本構造
- 次章: 第4章：問題解決の論理プロセス
- リライト方針: 2026年版リライト契約と分割計画