第2章：論理的思考の基本構造

この章で作れる成果物

この章を読み終えると、次の成果物を作れる状態を目指します。

論理構造メモ: task brief から、前提、論点、根拠、推論、反論、結論を分けたメモ。
反論・要確認リスト: AI出力や自分の提案に対して、反対意見、代替説明、未確認事項を整理したリスト。
判断可能な結論文: 読み手が採否を判断できるように、条件、根拠、次アクションを含めた結論文。

第1章では、AIを使う前に目的、読み手、意思決定点、情報分類を定義しました。第2章では、その task brief を論理構造へ分解し、AI出力をそのまま採用せず、人間が説明できる形に整えます。

本章とAI活用の標準業務フロー

本章は、AI活用の標準業務フロー（1枚）のうち、主に次の工程に対応します。

1. タスク定義: 何を判断するための論点かを明確にする。
3. 文脈設計: 前提、利用できる根拠、未確認事項をAIへ渡す形に整理する。
4. 出力仕様: AIに、結論だけでなく根拠、反論、要確認事項を分けて出させる。
7. 評価: 論理の飛躍、根拠不足、代替説明の見落としを確認する。
9. 編集・承認: 人間が最終結論を修正し、採用条件と承認理由を残す。

2.1 この章で扱う業務課題

AIは、もっともらしい結論や整った文章を短時間で作れます。しかし、文章が自然でも、次の問題が残ることがあります。

前提と結論の間に飛躍がある。
根拠と推測が混ざっている。
何を判断したいのか、論点が曖昧なままになっている。
反論や代替説明を確認せず、都合のよい結論へ進んでいる。
採用できる条件、保留すべき条件、追加確認が必要な点が分からない。

本章では、論理的思考を「きれいに説明する技術」ではなく、AI出力を判断可能な業務成果物へ変換するための構造化技術として扱います。

2.1.1 論証を読むための最小単位

6つの論理部品へ進む前に、論証を読むための最小単位を確認します。ここでいう論証は、理由を示して、ある判断を受け入れられるか検討するまとまりです。

主張: 正しい、または採用すべきだと読み手へ提示する文。業務では、提案、判断、予測も主張になり得ます。
前提: 推論を始めるために置く条件。確認済み事実だけでなく仮置きの条件も含み得るため、確認状態を分けます。
根拠: 前提や主張を支える確認可能な材料。事実、記録、資料などについて、出所と確認状態を示します。
推論: 前提や根拠から主張へ進む理由づけ。どの条件を使い、なぜその主張を支えられるかを説明します。
反例: 主張が想定する範囲に含まれるのに、その主張が成立しない具体例。単なる反対意見ではなく、一般化や条件設定を見直す材料です。

実務では、対象範囲、前提条件、測定方法が同じかを確認するまでは反例候補として扱い、それらが同じだと確認できた段階で反例と判定します。

関係を最小化すると、次の形になります。

前提 + 根拠 --（推論）--> 主張
                    ↑
              反例候補で検査

根拠は、事実、記録、資料など、前提や主張を支える確認可能な材料です。推論は、その材料から主張へ進める理由です。資料を1件示しただけでは推論を説明したことにならず、推論を書いただけでは根拠を確認したことになりません。

短い例で分けます。

【主張】今夜の本番rolloutを開始できる。
【前提】通常のrollout手順を適用し、変更禁止時間帯ではない。
【根拠】必須テストの成功記録と、指定承認者の承認記録がある。
【推論】現行のrollout手順が要求する条件を満たしているため、開始できる。
【反例候補】変更禁止時間帯ではなくても、障害対応に伴う緊急凍結指示が出ていれば開始できない。

反例候補が見つかった場合は、主張を直ちに全否定するのではなく、適用範囲や不足条件を見直します。この例では、緊急凍結指示が通常手順にも適用されるかを確認し、適用されるなら「緊急凍結指示が出ていない」を前提へ追加すべきだと分かります。

2.1.2 必要条件と十分条件を区別する

必要条件: その条件が欠けると、主張を成立させられない条件です。満たしていても、それだけで主張が成立するとは限りません。
十分条件: その条件を満たせば、定めた範囲では主張を成立させられる条件です。主張を成立させる方法が、それだけとは限りません。

次の架空の運用ルールを使って判定します。

通常の本番rolloutを開始できるのは、次の3条件をすべて満たす場合に限る。

必須テストが成功している。
指定承認者が承認している。
変更禁止時間帯ではない。

3条件をすべて満たせば、この通常手順では本番rolloutを開始できる。

「必須テストが成功している」は、開始の必要条件ですが、単独では十分ではありません。
3条件をすべて満たすことは、この通常手順の範囲では、開始の十分条件です。
「テストが成功した。したがって開始できる」は、承認と時間帯を省略しているため成立しません。
「3条件を確認した。したがって通常手順では開始できる」は、適用範囲を限定しているため成立します。

実務の条件は、規程改定、例外申請、対象環境によって変わります。「十分条件」を唯一の「必要条件」へ読み替えず、どのルールと範囲で判定したかを残します。

2.1.3 相関と因果を区別する

相関: 2つの事象が同じ時期に変化するなど、連動して観察される関係です。
因果: 一方の変化が、一定の作用経路を通じて他方の変化を生じさせた関係です。

たとえば、「ナレッジ共有会の開始後に問い合わせ件数が減った」という観察だけでは、共有会が減少の原因だとは確定できません。同じ時期の製品変更、繁閑、利用者数、集計基準の変更など、別の説明があり得ます。

「同じ時期に起きた。したがって共有会が減少させた」は、相関から因果へ飛躍しています。
「同じ時期に起きた。因果を主張する前に、時間順序、作用経路、代替説明、比較材料を確認する」は、観察と未確認事項を分けています。

比較対象や時系列、施策が働く仕組み、他の変化を確認するまでは、「同時に観察された」「寄与した可能性がある」のように、確認できた範囲で記述します。

2.2 重要概念：6つの論理部品

本書では、業務で使う論理構造を次の6つに分けます。

この6部品は、前節の主張・前提・推論・反例を置き換える基礎論理の代替ではありません。論証を、根拠確認、反論、承認条件を含む判断可能な実務成果物へ適用するテンプレートです。

前提: すでに分かっていること、置いている条件、利用範囲。
論点: 今回判断したい問い。論点が複数ある場合は分ける。
根拠: 事実、資料、観察、確認済みデータ。出所と確認日を残す。
推論: 根拠から結論へ進む理由づけ。因果、比較、分類、優先順位などを使う。
反論: 成立しない可能性、別解、リスク、読み手から出そうな質問。
結論: 採用案、保留案、次アクション。条件と未確認事項を含める。

従来の「前提 → 推論 → 結論」だけでは、AI協働の実務には不足します。AI出力には、根拠らしく見える文、仮説、推奨、断定が混在しやすいため、論点と反論を明示して、どこを確認すべきかを見えるようにします。

2.2.1 前提

前提は、考える前に固定する条件です。前提が曖昧だと、AIは一般論で補完し、読み手の判断に必要な条件を外すことがあります。

前提には、次のような情報を含めます。

読み手と意思決定点。
対象範囲と対象外。
利用してよい情報と使ってはいけない情報。
時点、地域、部門、顧客セグメントなどの適用範囲。
まだ仮置きしている条件。

2.2.2 論点

論点は、「何を答えるべきか」を一文で表した問いです。論点が曖昧なままAIへ依頼すると、要約、調査、提案、説得が混ざります。

良い論点は、次の形に近づきます。

誰が、何を判断するために、どの選択肢または条件を比較するのか。

例:

営業責任者が次回提案方針を決めるために、競合A社との差別化論点を3つに絞れるか。

2.2.3 根拠

根拠は、結論を支える確認済み材料です。AIが生成した文章そのものは、根拠ではありません。AIが引用した資料、社内で確認済みの事実、公開情報、観察記録など、確認可能な材料を根拠として扱います。

根拠を書くときは、次を残します。

出所。
確認日。
事実か、要約か、推定か。
利用上の制限。
反証になり得る材料。

2.2.4 推論

推論は、根拠から結論へ進む橋渡しです。AIが作った文章で見落としやすいのは、この橋渡しの妥当性です。

推論では、次を確認します。

根拠からその結論が自然に導けるか。
因果関係と相関関係を混同していないか。
少数の事例から一般化していないか。
他の説明可能性を排除しすぎていないか。
結論に必要な条件を省略していないか。

2.2.5 反論

反論は、提案を弱くする要素ではありません。読み手が判断するために必要な安全装置です。

反論には、次を含めます。

成立しない条件。
別の原因や別案。
読み手が質問しそうな点。
リスクと副作用。
追加確認が必要な一次情報。

2.2.6 結論

結論は、単なる「おすすめ」ではありません。業務では、結論に次の情報を含めます。

採用案または保留案。
判断理由。
採用条件。
未確認事項。
次アクションと担当者。
承認者または確認者。

2.3 task brief を論理構造へ分解する

第1章で作った task brief は、論理構造の材料です。ここでは、競合調査から提案方針を決める場面を例にします。固有名詞や条件は架空です。

【目的】法人向けサービスAの次回提案方針を決める。
【読み手】営業責任者と提案チーム。
【意思決定点】次回提案で強調する差別化論点を3つに絞る。
【利用してよい情報】公開Webサイト、公開資料、共有許可済み営業メモの要約。
【出力仕様】競合別の訴求軸、当社との差分、反論、要確認事項。

この task brief を、次のように分解します。

【前提】
- 読み手は営業責任者と提案チーム。
- 提案方針を決めるための材料であり、公開前の顧客名や契約条件は使わない。
- 公開情報と共有許可済みメモだけを使う。

【論点】
- 次回提案で強調すべき差別化論点は何か。
- その論点は、読み手が提案方針を決める材料として十分か。

【根拠】
- 競合の公開Webページで確認できる訴求軸。
- 自社資料で確認済みの機能・運用体制・サポート条件。
- 営業メモに含まれる、共有許可済みの顧客課題要約。

【推論】
- 競合が価格訴求を強めている場合、同じ軸で競争すると利益率や提供範囲に影響する可能性がある。
- 自社の運用支援や導入後支援が確認済みの強みなら、価格以外の比較軸を提案に入れる余地がある。

【反論】
- 顧客が短期費用を最優先している場合、運用支援の価値が伝わりにくい。
- 競合の最新情報が公開資料だけでは不足している可能性がある。
- 自社の支援体制を過大に表現すると、契約後の期待値ずれにつながる。

【結論】
- 差別化論点の候補は、導入後支援、運用定着、既存業務との接続性の3つとする。
- ただし、提案前に競合の最新公開資料と自社支援体制の提供条件を再確認する。

2.4 よくある失敗

失敗1：結論を急ぐ

「何をすべきか」を先に書くと、文章は力強く見えます。しかし、前提、根拠、反論が弱いままでは、読み手は採用可否を判断できません。

失敗2：AI出力を根拠として扱う

AIが自然な文章で説明していても、それだけでは根拠になりません。AI出力は、根拠候補を整理するための初稿です。根拠として採用するには、出所、確認日、適用範囲を確認します。

失敗3：論点が複数混ざる

「売上を上げたい」「競合に勝ちたい」「新施策を出したい」は、似ていても別の論点です。論点が混ざると、根拠も結論も散らばります。

失敗4：反論を省く

反論を省くと、提案が通りやすく見えることがあります。しかし、承認者や関係部門は、リスク、例外、代替案を確認します。先に反論を整理すると、議論の手戻りを減らせます。

失敗5：相関を因果として扱う

同時に起きたことを、原因と結果として断定しないようにします。売上、満足度、問い合わせ数、施策実施時期などは、第三の要因が影響している可能性があります。

2.5 改善前 → 改善後

改善前：もっともらしいが判断しにくい文章

競合A社は低価格を強く打ち出しています。当社も価格面で対抗しないと、今後の提案で不利になる可能性があります。そのため、次回提案では値引きを中心に訴求すべきです。

この文章には、次の問題があります。

誰が何を判断するための文章か分からない。
競合A社の低価格訴求を確認した根拠が書かれていない。
「価格で対抗すべき」という推論の条件が示されていない。
値引き以外の選択肢が検討されていない。
値引きによるリスクや承認条件がない。

改善後：論理構造を分ける

【論点】
次回提案で、価格訴求を主軸にすべきか、導入後支援を主軸にすべきか。

【前提】
- 読み手は営業責任者。
- 提案対象は法人向けサービスAの既存見込み顧客。
- 顧客名、契約条件、未公開売上情報はAIに入力しない。

【根拠】
- 競合A社の公開Webページでは、初期費用の低さを訴求している。
- 自社の公開資料では、導入後支援と運用定着支援を説明している。
- 営業メモの共有許可済み要約では、顧客は導入後の運用負荷を懸念している。

【推論】
- 顧客が初期費用だけを重視するなら価格訴求が有効な可能性がある。
- ただし、顧客が運用負荷を懸念しているなら、導入後支援を主軸にした方が判断材料になりやすい。

【反論・要確認】
- 顧客の予算上限が厳しい場合、導入後支援の価値だけでは不十分な可能性がある。
- 自社の支援体制で約束できる範囲を営業責任者が確認する必要がある。
- 競合A社の最新条件は公開情報だけでは不足する可能性がある。

【結論】
次回提案では、値引きを主軸にせず、導入後支援と運用定着を中心論点にする。ただし、価格差が意思決定に与える影響を補足資料で扱い、営業責任者が支援範囲を確認してから社外共有する。

改善後は、結論だけでなく、採用条件と要確認事項が見えます。これにより、AI出力を業務判断へ使う前に、人間が確認すべき点を特定できます。

2.6 実務テンプレート：論理構造メモ

次のテンプレートを使うと、AIへ依頼する前にも、AI出力を評価するときにも、論理構造を確認できます。

【タスク名】

【読み手 / 承認者】

【意思決定点】

【前提】
- 確定していること:
- 仮置きしていること:
- 対象外:
- 利用してよい情報:
- 利用してはいけない情報:

【論点】
- 主論点:
- 副論点:

【根拠】
- 根拠1（出所 / 確認日 / 種別）:
- 根拠2（出所 / 確認日 / 種別）:
- 根拠不足の箇所:

【推論】
- 根拠から結論へ進む理由:
- 因果ではなく相関に留まる箇所:
- 条件付きで成立する箇所:

【反論・代替説明】
- 反論:
- 代替案:
- リスク:
- 追加確認が必要な一次情報:

【結論】
- 採用案:
- 保留条件:
- 次アクション:
- 担当者 / 確認者:

AIへ依頼するときの出力指定例

次の task brief を、前提、論点、根拠、推論、反論、結論に分解してください。
根拠が不足している箇所は「要確認」と明記してください。
推論では、因果関係と相関関係を混同していないかも確認してください。
結論には、採用条件、保留条件、次アクションを含めてください。

2.7 人間が最終判断すべき点

AIに論理構造の分解を依頼しても、次は人間が判断します。

その前提を業務上採用してよいか。
根拠として使う資料の正確性、利用許諾、更新日を確認したか。
反論や代替説明を十分に検討したか。
読み手が判断できる粒度まで結論を具体化したか。
リスクを受け入れる承認者が明確か。
社外共有、稟議、顧客提案に使える表現か。

章末演習

演習2-1：task brief の論理構造化

次の task brief を、前提、論点、根拠、推論、反論、結論に分解してください。

【目的】顧客向け提案書の方向性を決める。
【読み手】営業責任者。
【意思決定点】低価格訴求と導入後支援訴求のどちらを主軸にするか。
【利用してよい情報】公開Webページ、公開資料、共有許可済み営業メモの要約。
【制約】顧客名、契約条件、未公開売上情報は入力しない。

演習2-2：AI出力の論理飛躍を見つける

次のAI出力案にある論理の飛躍、根拠不足、要確認事項を指摘してください。

競合A社は低価格を訴求しています。したがって、当社も価格を下げれば提案に勝てます。次回提案では値引きを最優先にすべきです。

演習2-3：反論・要確認リストを作る

「導入後支援を主軸に提案する」という結論に対して、反論、代替説明、リスク、追加確認が必要な一次情報をそれぞれ2つ以上挙げてください。

演習2-4：判断可能な結論文に直す

次の結論文を、採用条件、保留条件、次アクションが分かる形に修正してください。

次回提案では、当社の強みを前面に出すべきです。

演習2-5：条件不足・因果混同・反例候補を判定する

次の3つの記述を読み、後の問いに答えてください。

A. 必須テストは成功した。したがって、本番rolloutを開始できる。
B. ナレッジ共有会の開始後に問い合わせ件数が減った。したがって、共有会が減少させた。
C. 「すべてのpilot teamで手戻りが減る」という主張に対し、同じ対象条件の1 teamでは手戻りが増えた。

Aの主張、前提、根拠、推論を分け、不足している条件を挙げてください。
Aの「必須テスト成功」は必要条件、十分条件のどちらとして扱うべきか説明してください。
Bで確認できるのは相関と因果のどちらか、因果を検討するために何を追加確認するか説明してください。
Cが反例候補になる理由と、元の主張をどのように修正すべきか説明してください。

理解度チェック

□ 主張、前提、根拠、推論、反例を区別できる □ 必要条件と十分条件を、適用範囲を含めて判定できる □ 相関だけが確認できる記述から因果を断定しない □ 前提、論点、根拠、推論、反論、結論を分けて説明できる □ AI出力を根拠として扱わず、根拠候補として確認できる □ 因果関係と相関関係を混同していないか確認できる □ 反論、代替説明、リスク、要確認事項を結論に添えられる □ 読み手が判断できる結論文へ編集できる

章末の要点

論証の最小単位では、前提、根拠、推論、主張を分け、反例候補で適用範囲を検査します。
必要条件は欠けると成立せず、十分条件は定めた範囲で満たせば成立します。両者を同一視しません。
同時に観察された事象は相関であり、因果を主張するには作用経路、代替説明、比較材料を追加確認します。
AI時代の論理的思考では、前提、論点、根拠、推論、反論、結論を分けて扱います。
AI出力は初稿であり、根拠そのものではありません。
反論や要確認事項を入れることで、提案は弱くなるのではなく、判断可能になります。
結論には、採用条件、保留条件、次アクションを含めます。
人間は、根拠の採用可否、リスク、承認条件を最終判断します。

次章への橋渡し

第2章では、task brief を論理構造へ分解し、判断可能な結論へ整える方法を扱いました。次の第3章では、事実、解釈、仮説、推定、推奨を分け、根拠確認と evidence matrix へ接続します。