第4章：問題解決の論理プロセス

この章で作れる成果物

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

問題設定メモ: 現象、問題、意思決定点、制約、読み手、承認者を分けたメモ。
仮説検証シート: 仮説、根拠候補、反証条件、追加確認、次アクションを残すシート。
AI出力採否判断メモ: AIが出した提案や分析を、評価軸、受け入れ基準、リスク、承認条件に照らして採用・条件付き採用・差し戻し・保留に分けるメモ。

本章は、問題解決フレームワークを網羅する章ではありません。AIが作ったもっともらしい解決策をそのまま採用せず、問題設定、仮説、意思決定、評価軸を使って、業務で採用できる出力へ変換するための章です。

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

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

1. タスク定義: 解くべき問題、意思決定点、読み手、期限、制約を定義する。
3. 文脈設計: AIに渡す問題文、仮説、前提、判断背景を整理する。
4. 出力仕様: 評価軸、受け入れ基準、根拠欄、要確認欄を出力形式へ組み込む。
7. 評価: AI出力を受け入れ基準、根拠、リスク、反証条件で評価する。
9. 編集・承認: 採用可否、保留条件、承認者、人間が補う判断を明確にする。
10. ログ化・再利用: 問題設定、仮説、採否理由を再利用できる形で残す。

第5章で扱う指示設計は、この章で作る問題設定メモと評価軸があって初めて安定します。問題が曖昧なままプロンプトを磨いても、出力品質は業務判断に耐えにくくなります。

4.1 この章で扱う業務課題

AIは、課題を渡すと短時間で原因候補、施策案、比較表、報告文を作れます。一方で、次のような失敗が起きやすくなります。

現象を問題として扱い、何を意思決定するかが曖昧なまま解決策を作る。
仮説と事実を分けず、AIが挙げた原因候補を根拠のある結論として扱う。
評価軸を後付けし、都合のよい案だけが高く見える比較表を作る。
数値スコアはあるが、必須条件、リスク、承認条件がないため採否判断に使えない。
いつ、誰が、どの前提で採用したかを残さず、後から説明できない。

本章では、「AIに答えを出させる」前に、人間が問題設定と採否基準を決める手順を扱います。AIは観点出し、反論候補、比較表の初稿作成には使えますが、問題の定義、リスク許容度、承認可否は人間が判断します。

4.2 問題設定：現象、問題、意思決定点を分ける

4.2.1 現象と問題を混同しない

問題設定では、まず次の4つを分けます。

区分	意味	例
現象	観察された出来事や数値	「問い合わせ対応が滞っている」
影響	読み手や業務に生じる不利益	「回答遅延により商談化の機会を逃す」
問題	解決対象として定義したギャップ	「優先度の高い問い合わせを当日中に処理できない」
意思決定点	読み手が決めること	「一次分類をAI支援に切り替えるか」

AIに「問い合わせ対応を改善して」と依頼すると、ツール導入、FAQ整備、人員増、チャットボットなどの案が返るかもしれません。しかし、問題が「優先度判定の遅れ」なのか、「回答品質のばらつき」なのか、「担当者の負荷集中」なのかで、採用すべき案は変わります。

4.2.2 問題設定メモ

AIへ依頼する前に、次のメモを作ります。

【問題設定メモ】
目的:
読み手 / 承認者:
現象:
影響:
解くべき問題:
今回の意思決定点:
対象範囲:
対象外:
制約（期限、予算、体制、ポリシー）:
利用できる根拠:
未確認事項:
採否判断に使う評価軸:

このメモは長く書く必要はありません。重要なのは、AIに渡す前に「何を解くのか」と「何を決めるのか」を人間が宣言することです。

4.2.3 改善前から改善後へ

改善前の依頼は、次のようになりがちです。

営業資料が弱いので、改善案を出してください。

この依頼では、読み手、判断点、弱い理由、評価軸が分かりません。改善後は、次のように問題設定を含めます。

【目的】来月の既存顧客向け提案で、導入後支援の価値を説明する1枚サマリーを改善する。
【読み手】顧客の部門長。判断点は、追加支援プランの検討に進むかどうか。
【現象】現行資料は機能説明が中心で、導入後の運用負荷軽減が伝わりにくい。
【問題】読み手が「支援を追加する理由」と「追加しない場合のリスク」を判断できない。
【制約】未公開顧客名、個別契約条件、個人情報は使わない。
【評価軸】判断可能性、根拠の明確さ、反論への備え、機密配慮、1枚で読める構成。
【依頼】上記を前提に、改善観点と1枚サマリーの構成案を作ってください。事実、仮説、要確認を分けてください。

改善後の依頼では、AI出力を採用する基準が先に見えています。これにより、出力を受け取った後の評価が属人的になりにくくなります。

4.3 仮説：検証できる形で置く

4.3.1 仮説は結論ではない

仮説は、現時点での最も有力な説明や打ち手の候補です。結論ではないため、採用するには検証や反証条件が必要です。

良い仮説は、次の形で表現できます。

もし【原因または条件】が主要因であれば、【施策】によって【観測可能な変化】が起きるはずである。

例として、問い合わせ対応の問題では次のように置けます。

もし優先度判定の遅れが回答遅延の主要因であれば、一次分類ルールを整備し、AIに分類初稿を作らせることで、緊急度の高い問い合わせの初動時間が短くなるはずである。

ここで重要なのは、「AIを導入すれば改善する」という結論にしないことです。何が主要因で、何を変え、どの変化を観測するのかを分けます。

4.3.2 仮説検証シート

仮説を採用候補にする前に、次のシートへ落とします。

【仮説検証シート】
問題:
仮説:
根拠候補:
反証される条件:
確認するデータ / 資料:
AIに依頼する作業:
人間が確認する作業:
小さく試す方法:
採用条件:
保留 / 中止条件:
次アクション:

AIには、仮説の代替案、反論、追加確認、検証計画の初稿を作らせると有効です。一方で、根拠の採用可否、データの解釈、顧客や従業員への影響は人間が確認します。

4.3.3 AIに依頼しやすい仮説検証タスク

AIに依頼しやすいのは、次のようなタスクです。

問題設定メモから、原因仮説を複数案に分ける。
各仮説について、必要な根拠、反証条件、確認方法を列挙する。
仮説ごとに、低リスクで試せる検証方法を提案する。
仮説が外れた場合の代替説明を挙げる。
結論文を、採用条件と保留条件が分かる表現へ書き換える。

ただし、AIが出した仮説は、事実ではありません。第3章の evidence matrix と fact-check log を使い、根拠候補と確認状況を残します。

4.4 評価軸：採否判断に使える基準へ落とす

4.4.1 評価軸と受け入れ基準を分ける

評価軸は、比較するときの観点です。受け入れ基準は、採用するための最低条件です。この2つを混同すると、総合点は高いが必須条件を満たさない案を採用してしまいます。

種類	役割	例
評価軸	複数案を比較する観点	判断可能性、実現可能性、効果、リスク、再利用性
受け入れ基準	採用するための最低条件	機密情報を含まない、根拠欄がある、承認者が明記されている
差し戻し条件	修正しない限り採用できない条件	未確認の数値を断定している、対象外の顧客情報を含む
保留条件	追加確認が必要な条件	根拠資料が古い、法務確認が未完了、現場負荷が未評価

AI出力を評価するときは、まず受け入れ基準を満たすかを確認し、その後に評価軸で比較します。

4.4.2 評価rubricの例

次は、提案書の1枚サマリー案を評価するためのrubric例です。数値はサンプルであり、実務では目的、読み手、リスクに合わせて調整します。

評価軸	3: 採用水準	2: 条件付き	1: 差し戻し
判断可能性	読み手が次の判断を選べる	判断点はあるが選択肢が弱い	何を決めるか不明
根拠	主張ごとに根拠候補と確認状況がある	一部の根拠が未確認	根拠なしの断定が多い
反論対応	想定反論と回答方針がある	主要反論のみある	反論を扱っていない
リスク	採用リスクと保留条件が明記されている	リスクが抽象的	リスク記載がない
機密配慮	機密・個人情報を含まず、範囲が明確	一部確認が必要	利用不可情報を含む
再利用性	テンプレート化できる構造	一部修正で再利用可能	文脈依存で再利用困難

点数は意思決定の補助です。機密配慮や法務確認などの必須条件を満たさない場合、総合点が高くても採用しません。

4.4.3 評価マトリックスを採否に接続する

比較表は、単に点数を並べるのではなく、採否判断に接続します。

【評価マトリックス】
候補案:
必須条件の確認:
評価軸と重み:
スコア:
根拠:
主なリスク:
反証 / 保留条件:
推奨採否:
承認者に確認する点:

AIに比較表を作らせる場合は、必ず「根拠欄」「未確認欄」「採用条件」「保留条件」を入れます。表の見栄えよりも、読み手が次の判断をできることを優先します。

4.5 AI出力の採否判断

4.5.1 採否は4分類で扱う

AI出力は、採用か不採用かの二択だけで扱う必要はありません。次の4分類にすると、実務上の次アクションが明確になります。

区分	意味	次アクション
採用	受け入れ基準を満たし、人間の確認も完了	最終成果物へ反映し、承認ログを残す
条件付き採用	大筋は使えるが、根拠確認や表現修正が必要	条件を満たしてから反映する
差し戻し	目的、根拠、構成、機密配慮に大きな不足がある	問題設定や指示を修正し、再生成または人手で修正する
保留	判断材料が足りない、または承認待ち	追加確認、関係者確認、リスクレビューを行う

この分類は、AI出力だけでなく、人間が作った初稿のレビューにも使えます。

4.5.2 AI出力採否判断メモ

採否判断は、短いメモで残します。

【AI出力採否判断メモ】
対象成果物:
依頼したタスク:
採否区分（採用 / 条件付き採用 / 差し戻し / 保留）:
判断理由:
満たした受け入れ基準:
満たしていない受け入れ基準:
根拠確認の状況:
主なリスク:
人間が修正する点:
承認者 / 確認日:
再利用時の注意:

このメモを残すと、後から「なぜそのAI出力を使ったのか」「どの前提なら再利用できるのか」を説明しやすくなります。

4.5.3 差し戻し指示の作り方

差し戻しでは、AIに「もっと良くして」と依頼しません。何を満たしていないのかを、評価軸と受け入れ基準に沿って伝えます。

次の理由で差し戻します。

1. 判断可能性: 読み手が選ぶべき選択肢が明確ではありません。
2. 根拠: 「運用負荷が大きい」という主張に根拠候補がありません。
3. リスク: 追加支援を導入しない場合のリスクが抽象的です。
4. 機密配慮: 顧客名は匿名化してください。

上記を踏まえ、1枚サマリー案を次の構成で修正してください。
- 判断点
- 根拠候補
- 推奨案
- 採用条件
- 保留条件
- 要確認事項

差し戻し指示には、改善対象、理由、再出力形式を含めます。これにより、再生成を重ねても論点が拡散しにくくなります。

4.6 よくある失敗

4.6.1 現象をそのまま解く

「売上が下がった」「会議が長い」「問い合わせが増えた」は現象です。問題設定では、影響、対象範囲、意思決定点を明確にします。AIに渡す前に、何を決めるための分析かを定義します。

4.6.2 AIの原因候補を根拠として扱う

AIが挙げた原因候補は、仮説または要確認です。根拠にするには、社内データ、顧客の発言、契約、ログ、公開資料などで確認します。根拠が弱い場合は、結論ではなく「確認すべき仮説」として扱います。

4.6.3 評価軸が多すぎる

評価軸を増やしすぎると、重要な判断がぼやけます。実務では、3〜6個程度に絞り、必須条件と加点要素を分けると扱いやすくなります。数値はサンプルであり、組織や成果物のリスクに応じて調整します。

4.6.4 スコアだけで決める

評価マトリックスの総合点は、説明の補助です。機密情報、法務・知財、顧客影響、重大な安全リスクなどの必須条件を満たさない場合は、総合点が高くても採用しません。

4.6.5 採否理由を残さない

AI出力を一度使うと、同じ表現やテンプレートが再利用されやすくなります。採用時の前提、対象範囲、確認日、再利用時の注意を残さないと、別文脈で誤用される可能性があります。

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

AIに問題整理、仮説候補、評価表、差し戻し文を作らせても、次は人間が判断します。

解くべき問題と、今回の意思決定点は妥当か。
仮説の根拠候補を、根拠として採用してよいか。
反証条件や保留条件を十分に扱っているか。
評価軸は読み手の判断に合っているか。
必須条件、機密配慮、法務・知財・社内ポリシーを満たしているか。
採用、条件付き採用、差し戻し、保留のどれにするか。
判断理由、承認者、確認日、再利用条件をログに残したか。

章末演習

演習4-1：問題設定メモを作る

次の依頼を、問題設定メモに書き換えてください。

社内研修の参加率が低いので、AIを使って改善案を出してください。

少なくとも、目的、読み手、現象、影響、解くべき問題、意思決定点、対象範囲、制約、評価軸を含めてください。

演習4-2：仮説検証シートを作る

演習4-1の問題について、原因仮説を1つ置き、仮説検証シートを作ってください。反証される条件、確認するデータ、AIに依頼する作業、人間が確認する作業を含めてください。

演習4-3：AI出力の評価rubricを作る

AIに「社内研修の参加率改善案」を作らせる前提で、評価軸と受け入れ基準を作ってください。必須条件と加点評価を分けてください。

演習4-4：採否判断を行う

次のAI出力案を、採用、条件付き採用、差し戻し、保留のいずれかに分類し、理由と次アクションを書いてください。

研修参加率を上げるには、全社員に参加を義務化し、未参加者を部門長へ通知するのが最も効果的です。あわせて、参加者にはポイントを付与し、ランキングを公開するとよいでしょう。

演習4-5：decision memo にまとめる

演習4-4の判断を、AI出力採否判断メモとしてまとめてください。根拠確認の状況、主なリスク、人間が修正する点、承認者に確認する点を含めてください。

理解度チェック

□ 現象、影響、問題、意思決定点を分けて説明できる □ 仮説を、検証可能な形で置ける □ 評価軸と受け入れ基準を分けて設計できる □ AI出力を採用、条件付き採用、差し戻し、保留に分類できる □ 採否理由、承認者、確認日、再利用条件をログに残せる

章末の要点

問題設定では、現象、影響、問題、意思決定点を分けます。
仮説は結論ではなく、検証と反証の対象です。
評価軸は比較の観点、受け入れ基準は採用の最低条件です。
AI出力の採否は、採用、条件付き採用、差し戻し、保留で扱うと次アクションが明確になります。
人間は、問題の妥当性、根拠の採用可否、リスク、承認条件を最終判断します。

次章への橋渡し

第4章では、問題設定、仮説、評価軸、採否判断を使い、AI出力を業務で採用できるか確認する方法を扱いました。次の第5章では、この判断基準を前提に、目的、文脈、制約、例示、出力形式を含む指示設計へ進みます。