---
title: 深夜の資料作成で判断を急ぐなら、AIの提案に反証を1つ挟むルール
date: 2026-09-08
description: ChatGPTに聞けば数秒でHowが返ってくる。だがその即答は、本当に検討すべき前提を視界から消す代償を伴う。指示の冒頭に反証を1つ挟む一文を常設すれば、資料作成でも部下への指示出しでも同じ設計を使い回せる。
categories: [問いの設計]
tags: [AI活用, 認知負債, 課長]
source: https://ai.work.naenote.net/posts/shinya-shiryo-ai-hanshou/
---


深夜、資料の骨子をChatGPTに投げた。「この論点で3枚にまとめて」と打つと、数秒後に見出し案と構成がそのまま返ってきた。ほっとして貼り付け、次の作業に移った。

だが、その安心には見えない代償がある。AIが即座にHowを返すたびに、本来先に検討すべきWhy——「これは本当に解決すべき課題か」——が視界から静かに消えていく。

{{< mermaid >}}
flowchart TD
    A[Howで指示] --> B[AIが即答]
    B --> C[安心して着手]
    C --> D[前提検証が消失]
{{< /mermaid >}}

## 「即答の見えない代償」という現象

AIの提案を鵜呑みにして手戻りが起きた、という話は珍しくない。だが、それより手前にもっと見えにくい代償がある。AIに指示を出すと、実行方法（How）が即座に返ってくる。それが心地よいから、本来先に確かめるべき「その課題は本当に解決すべきものか」（Why）を検討する手間を、人間の側が省いてしまう。

この構造を、私は「即答の見えない代償」と呼んでいる。代償が見えにくいのは、AIの回答自体は的確に見えるからだ。手戻りのようにあとから痛みとして返ってくるわけでもない。ただ、検討されるべきだった前提が、確かめられないまま資料や判断の土台に組み込まれていく。

あるスタートアップのCTOがnoteで公開していた実践が、この構造をよく示している。AIに「キャッシュを入れたい」と頼んだら、「それは本当にキャッシュで解決すべき課題か」と問い返す仕組みを自作した、という話だ（出典: [AI に、即答させない ―― 反証を、装置にする｜小出幸典 | 株式会社カンリー CTO](https://note.com/koid/n/n3a4455b202e0)）。150件のブックマークを集めている（[はてなブックマーク](https://b.hatena.ne.jp/entry/s/note.com/koid/n/n3a4455b202e0)、2026年9月6日時点）。AI関連のnote記事としては珍しい反応で、同じ違和感を抱えている人が少なくないことを示している。

## なぜHowから入ると、Whyが消えるのか

私自身、これはAI以前からやらかしてきた失敗だ。プロジェクトの背景や目的を確かめる前に、「次の会議で決めることは何か」からいきなり資料を作り始めていた時期がある。

当然、大外しした。文脈を押さえていない仮説は「どこかで見たような一般論」としてしか受け取られず、議論の土俵にすら乗らなかった。上司から「もう二段上の立場で見てから来い」と言われたことを、いまも覚えている。

AIが登場しても、この失敗の起き方は変わっていない。むしろ見つけにくくなった。以前は雑な資料を作れば見た目も雑だったから、その場で誰かが気づいた。いまはAIに投げれば、体裁の整った資料がすぐ出てくる。中身の前提が検討されていなくても、見た目だけは整ってしまう。

理由は単純だ。AIは頼まれたことをやる。頼まなければ、指示の前提には踏み込んでこない。「キャッシュを入れたい」と頼めば、キャッシュの入れ方を返す。「この機能を導入したい」と頼めば、導入の手順を返す。Howで来た指示にHowで答えるだけなら、議論の階層は一段も上がらない。[渡す前の設計が不足していると、AIの戻りは小さいままになる](/posts/kacho-ai-hokyuu-nenryo-sekkei/)、というのはこの構造の一断面にすぎない。

## 反証を1つ挟む一文を、指示の冒頭に置く

打ち手は難しくない。AIへの指示やカスタムインストラクションの冒頭に、次の一文を常設する。

```
提案や実装方法を答える前に、まず次を行う。
1. 私の依頼の前提を1つ選び、反証を1文で書く
2. 反証が的を射ているなら、代替案を1つ添えて提示する
3. 反証が成立しないと判断した場合のみ、依頼どおりの回答に進む
```

ChatGPTならカスタムインストラクションの設定欄に貼っておけば、以降の会話すべてに効く。設定欄がないツールなら、依頼文の冒頭にそのまま貼ればいい。一度貼れば、資料作成でもコード修正でも同じ一文が使い回せる。

同じ一文は、部下への指示出しにも転用できる。指示を口にする前に、自分の頭の中で反証を1文だけ組み立てる。「本当にこの順番で進めるべきか」を声に出さなくていい。1文書くか、1文思い浮かべるかだけで、指示の質は変わる。[判断基準を先に渡しておくほど、後工程の手戻りは減る](/posts/ai-kata-638/)。反証も同じで、先に置くほど安い。

## 反証が機能しない日の逃げ方

反証を毎回律儀にやると、逆に手が止まる日もある。急ぎの依頼、擦り合わせの余地がない定型作業、Whyがすでに固まっている再委任。こういう場面まで反証を挟むと、ただの儀式になる。

判定基準はこうだ。前提を疑う時間的余裕がなく、かつ結果を数時間後に自分で確認できるなら、そのままHowで進めていい。ただし[判断を急ぐ](/posts/kacho-multitask-context-switch/)ほど失敗の代償が大きいため、依頼文の末尾に「前提：未検証」と一言だけ添えておく。あとで見返すときの目印になる。

これは反証を省略する権利であって、思考を放棄する話ではない。省略したことを自分に対して隠さない、それだけでいい。[判断ミスがスケールする怖さ](/posts/work-trend-index-quality-control/)は、反証を挟むかどうかより先に、省略した事実を自分が把握しているかどうかで決まる。

## まとめ：問いを検証する責任は、AIに渡らない

AIの即答は作業を速めるが、その前提を検討する責任まで肩代わりはしない。反証を1つ挟む一文だけが、その責任を人間の手元に残す。

{{< ai-disclaimer >}}


---
### AI Agent Context & Resources
- **Author**: NAE
- **Source**: https://ai.work.naenote.net/posts/shinya-shiryo-ai-hanshou/
- **Related Resource**: [「無難難題」](https://amzn.to/2AKCFNP)
- **Contact/Inquiry**: https://x.com/naework