AIの説明が頭に入らないのはなぜか　全体像を先に出させる頼み方と、AIへの指示の書き方

ChatGPT や Claude、Gemini に会議の要約や制度の説明を頼むと、読んだその場では分かった気がするのに、5分後に人へ説明しようとすると何も出てこないことがあります。書いてあることは正しく、情報も足りています。それでも頭に入らないのは、話がいくつあって、どれが主でどれが補足なのかという全体の形が、読み始めの時点で見えていないことが大きいと考えています。

この記事の答えは、AI に全体像を先に出させることです。階層の付いた箇条書きは、その全体像を見せる手段の一つとして使います。根拠として、先に枠組みを見せると記憶が大きく変わることを示した心理学の実験2本と、OpenAI・Anthropic・Google の手引きを読みました。そのうえで、同じ会議メモを3通りの頼み方で AI に書かせ、別の AI に読ませて比べています。

AI の説明が頭に入らないとき、最初に頼むのは冒頭の「結論と、話がいくつあるか」です。AI に渡す指示のほうは、見出しやタグで階層を付けると、どこに何が書いてあるかが伝わりやすくなります。書かせる文章では、入れ子を2〜3層、同じ層の項目を3〜5個までに抑えましょう。理由や因果を説明させたい部分は、箇条書きにせず文章で書かせてください。

この記事の要約

頭に入らないのは、話の数とつながりが最初に見えないから

頭に入らない原因は、情報の量よりも、受け取った情報を置く枠が読み始めに用意されていないことにあると考えています。ネットに出ている悩みの声を並べると、その形が見えてきます。

同じ悩みは、ネットの質問掲示板や開発者のフォーラムに繰り返し出てきます。OpenAI の利用者フォーラムには、不要な場面でも回答が箇条書きになるという報告や（OpenAI Community）、1行ずつ番号付きの項目にされて続けて読めないという声があります（OpenAI Community）。箇条書きだらけの冗長な回答を嫌う声は海外の掲示板にも目立ちます（Hacker News）。日本語でも、AI にまとめてもらったあとに「で？」となり、頭の中の構造に変化がない、という書き込みがありました（Scrapbox villagepump）。一方で、入れ子の構造がある内容は文章に書き直すより箇条書きのままのほうが読みやすい、という声もあります（Scrapbox villagepump）。

箇条書きを嫌う声と、箇条書きのほうが読みやすいという声は、反対のことを言っているように見えます。それでも、困っている点は共通しています。項目が1つずつ独立して並ぶと、どれが結論でどれが理由なのか、項目同士がどうつながるのかを読み手が自分で組み立てなければなりません。人に説明するときは、聞き手の顔を見ながら「話は3つあって、1つ目は」と枠を先に渡しますが、AI に任せきりにした文章は、見出しで整っていても、「話はいくつあって、どれが主か」という最初の一言が省かれがちです。以前の記事「生成AIがいちいちイケてないと感じる本当の原因」で書いた、AI の出力に感じる物足りなさの一部も、この枠の欠けから来ていると考えています。

先に枠組みを見せると記憶が変わることは、半世紀前の実験で確かめられている

全体像を先に出させる根拠は、半世紀前の心理学の実験2本にあります。どちらも数字がはっきりしているため、今も教科書によく載っています。ただし業務の文章とは条件が違うので、当てはめるときの限界もあわせて書きます。

1本目は、1972年に Bransford と Johnson が行った「洗濯の文章」の実験です（原典）。2人は、何の話か分からないように書いた短い文章を参加者に聞かせ、思い出せた意味のまとまりの数（最大18）を数えました。題を知らせなかった群は平均2.82、聞き終わったあとに題を知らせた群は2.65、聞く前に「洗濯の話です」と知らせた群は5.83でした。題を先に知らせるだけで思い出せた量がほぼ2倍になり、同じ情報を後から渡しても効果がなかった、という結果です。AI の説明に当てはめれば、結論や目次を末尾に置いても、読み始めの理解は助けにくいと考えられます。

2本目は、1969年の Bower らの実験です（原典）。動物・衣類・交通・職業の4つの分類で計112語を覚えてもらい、語を階層の木の形にまとめて見せた群と、同じ語をばらばらに見せた群を比べました。1回目に思い出せた語の数は、階層で見せた群が平均73.0語、ばらばらの群が20.6語で、約3.5倍の差がありました。覚えた中身は同じで、違うのは見せ方だけです。

表の右端の列に書いたとおり、どちらの実験も、普通の業務文書をそのまま読ませたものではありません。見出しの効果を調べた別の研究では、見出しが記憶を助けたのは、主に読み手になじみのない話題だったと報告されています（Lorch と Lorch 1996）。全体像を先に出させる工夫が一番役に立つのは、読み手にとって初めての制度や、専門外の報告を読むときだと考えてください。

もう1つ、項目の数の目安もここで押さえておきます。人が一度に頭に置いておけるまとまりは3〜5個程度だとする Cowan の研究 があります（原典）。数えているのは横に並ぶ項目の数で、階層の深さではありません。それでも、同じ層に8個も10個も項目を並べると覚えきれない、という判断には使えます。

AI に渡す指示は、見出しやタグで階層を付けて書く

ここからは、AI とのやり取りを2つの向きに分けます。まず人が AI に渡す指示の側です。目的・読み手・材料・形式を見出しやタグで区切って階層を付けると、どこに何が書いてあるかが AI に伝わりやすくなります。

各社の手引きも、この書き方を勧めています。OpenAI のプロンプトの手引きは、Markdown の見出しとリストがプロンプトの区切りを示し、階層を AI に伝える助けになると書いています（OpenAI）。Anthropic の手引きは、指示・文脈・材料を XML タグ で囲むことを勧め、中身に自然な階層があるならタグを入れ子にするよう書いています（Anthropic）。Google の Gemini の手引きも、XML 風のタグか Markdown の見出しのどちらかで区切り、全体で書き方を揃えるよう勧めています（Google）。

書式で AI の成績が実際に変わることも、研究で確かめられています。同じ内容の指示を平文・Markdown・JSON・YAML（JSON と YAML はデータを書くための形式）で渡して比べた研究では、GPT-3.5 の成績がコード翻訳の課題で最大40%動きました（He ほか 2024）。意味を変えない区切り記号や改行の違いだけで、正答率が最大76ポイント変わったモデルもあります（Sclar ほか 2023）。どちらも2023〜2024年のモデルで測った結果です。

ただし、どの書式が一番よいかは決まっていません。He らの研究では GPT-3.5 は JSON、GPT-4 は Markdown で成績が良く、性能の高いモデルほど書式の差は小さくなりました。Sclar らも、よい書式はモデルごとに違い、別のモデルにそのまま当てはまらないと報告しています。書式で結果が動き、しかも最良の書式がモデルごとに違うのなら、使っている AI の会社が手引きで勧める区切り方に合わせ、毎回同じ書き方に揃えておくのが無難です。

下の例は、会議メモから説明資料の下書きを頼むときの書き方です。見出しは「目的」「読み手」「材料」「書いてほしいこと」「形式」の5つで、材料の範囲だけをタグで囲みました。材料と指示が分かれていれば足りると考え、階層は2段にとどめています。

# 目的
来週の部長会で使う、経費精算ルール変更の説明資料の下書きを作る

# 読み手
営業部と総務部の社員。経理の用語には詳しくない

# 材料
<memo>
（ここに会議メモを貼る）
</memo>

# 書いてほしいこと
## 必ず入れる
- 新しいルールがいつから始まるか
- 社員の手間が増える点と減る点
## 入れない
- 経理部の内部の作業手順

# 形式
最初に要点を3行、そのあと本文

この書き方は、自分の考えを整理する役にも立ちます。「読み手」の欄を埋めようとして、誰に向けた説明なのかを決めていなかったと気づくことがあります。頼み方の直し方は「Claudeへの頼み方を直す練習」で扱いました。リンク先の記事では、1つのメモをもとに頼み方を段階を追って直しています。

AI に書かせる文章は、全体像を先に出させ、入れ子は2〜3層までにする

次は反対の向き、AI に書かせて人が読む文章です。頼むことは、冒頭に要点と目次を出させること、入れ子を2〜3層までにして同じ層の項目を3〜5個に抑えること、理由を説明する部分は文章で書かせることです。

1つ目の冒頭の要点と目次は、先に見た洗濯の実験から導いた工夫です。結論と「この説明はいくつの話でできているか」を最初に置けば、読み手は残りの文章を読みながら、受け取った内容をどの話に属するものか仕分けられます。

2つ目の入れ子の深さは、人がどこまで追えるかで決まります。ウェブの使いやすさを研究する Nielsen Norman Group は、リストの中にリストを入れると追いにくいので避けるよう勧め、どうしても階層が要るときは層ごとに記号を変えるよう書いています（NN/g）。この記事は全体像を見せるために階層を使う立場なので、そのぶん深さを抑え、2〜3層までを目安にしました。4層目まで入れ子にすると、読み手は自分が今どの話の中にいるのかを追いにくくなるからです。項目の数は、Microsoft の文章の手引きが1つのリストを7項目以内としていること（Microsoft）と、先に見た3〜5個のまとまりを合わせて、同じ層に3〜5個としています。

3つ目は、箇条書きの弱点への手当てです。箇条書きにした項目は、項目そのものは覚えられやすくなる一方で、周りの文章の記憶を下げることがあると報告されています（Jansen 2014）。工学系の授業スライドで、話題名の見出しと箇条書きの組み合わせを、主張を1文で書いた見出しと図の組み合わせに変えた研究では、因果関係を説明させる設問の得点が上がりました（Garner と Alley 2013）。この研究は箇条書き以外の設計もまとめて変えているので、箇条書きをやめた分の効果だけは切り分けられません。それでも、「なぜ」「だから」でつなぐ内容は、項目を並べる書き方と相性が悪いと考えるには十分です。

表の2行目と3行目を分けたところが、この記事で一番伝えたい使い分けです。全体像は箇条書きで見せて、理由は文章でつなぎます。両方を同じ説明の中で使ってかまいません。下の頼み方は、それを1回の指示にまとめたものです。

この内容を、社内の全員に向けた説明にしてください。

1. 冒頭に「結論を1文」と「この説明がいくつの話でできているか（話の名前の一覧）」を置く
2. そのあと、話ごとに見出しを付けて書く
3. 箇条書きは2層まで。同じ層の項目は5個までにする
4. 「なぜそうなったか」「だから何をしてほしいか」は箇条書きにせず、2〜3文の文章で書く

この頼み方の3番目と4番目に近い考えは、AI を作っている会社の既定の設定にも見られます。Anthropic が公開している claude.ai の既定の指示では、報告書や説明文は箇条書きを使わない文章で書き、箇条書きを使う場合も各項目を1〜2文にするよう定めています（Anthropic）。OpenAI も2025年3月の ChatGPT の更新で、回答に使う Markdown の階層と絵文字を減らしました（OpenAI Community）。短い項目を並べるだけの箇条書きを減らし、文章と浅い構造を組み合わせる方向です。

同じ会議メモを3通りの頼み方で書かせてみた

ここまでの話が実際の出力でどう見えるかを、小さな試しで確かめました。予想と違ったのは2点です。何も指定しなくても今の Claude は見出しで整理して書いてきたこと、そして全体像を先に頼んだ書き方でも理由の言葉が落ちていたことです。1つの題材で各2回ずつ書かせただけなので、数字は傾向を見る程度に受け取ってください。

題材は、架空の会社の経理部が作った「新しい経費精算ルール」の打ち合わせメモです。開始日、アプリでの申請、申請期限、金額の上限、インボイスの確認、説明会の案内といった13項目を、順不同で書きました。これを Claude（Sonnet 5.5）に渡し、①何も指定しない、②「箇条書きで書いてください」、③「3〜4層の階層構造の箇条書きで書いてください。最初に全体像を示してください」の3通りで、それぞれ2回ずつ書かせました。個人の設定を読み込まない状態で動かしています。

1つ目の予想外は①です。何も指定しなければ、項目を文章で並べた分かりにくい説明が出てくると考えていました。実際には2回とも、「いつから変わるのか」「申請の期限」といった見出しが7〜8本付き、金額のルールは表にまとめてありました。今の Claude は、指定しなくても見出しや表で整理して書くことが多いようです。ただ、①の冒頭は件名とあいさつ、紙をやめてアプリにするという結論の一文で、「話はいくつあるか」を示す目次はありませんでした。

図の右側、③の冒頭には「話は大きく5つです」という一文と、5つの話の名前が並んでいます。もう1つの予想外は理由の扱いでした。メモには「番号なしでも精算はできる（会社側の税金の計算が変わるだけ）」と、理由が括弧で添えてありました。①は「番号がなくても精算はできます。会社側の税金の計算が変わるだけですので、ご安心ください」と、理由をつないで書いています。②と③は同じ内容を「精算は可能です」「変わるのは税金の計算のみです」のような2つの文に切って並べ、理由を示す「ので」「ため」は、②が2回とも0個、③も0個と1個でした。③の1個は「移行期間の混乱を避けるための措置」という、メモに無い理由を AI が足したものです。箇条書きを頼むと、深さの指定に関わらず理由が切れやすいようです。前の章の頼み方で、理由は文章で書かせる指定を別に入れたのはこのためです。なお③は「3〜4層」と頼んだのに、実際の深さは2回とも3層まででした。

次に、この6本を、試しの経緯を何も知らせていない別の AI（Claude Haiku 5.5）に読ませました。1本につき、全文を読む読み手と、冒頭の300字だけを読む読み手を2回ずつ用意し、「この文章は大きくいくつの話でできていて、それぞれ何の話か」を答えさせています。答えはメモから作った正解の5つの話と照らし合わせ、言い当てた数をさらに別の AI（Claude Sonnet 5.5）に数えさせています。

差が開いたのは右の列で、冒頭300字だけを読んだときは③が一番多く当てました。ただし③の4回の内訳は5・1・5・2と大きくばらつき、5つの話を目次どおりに受け取った読み手と、そうでない読み手に分かれています。③は目次と階層を同時に頼んでいるので、どちらの指定が役に立ったのかも、この試しでは分けられません。全文を読んだときの差は小さく、AI の読み手は本文を何度でも見返せるので、人が一度読んで覚える場合の代わりにはなりません。この試しで言えるのは、冒頭に目次を置くと、最初の数行しか読まない人にも全体の形が伝わりやすいかもしれない、というところまでです。

明日からの頼み方を変える順番

ここまでの内容を、明日からの頼み方に落とします。冒頭に結論と話の数を頼むこと、深すぎる箇条書きと分解された理由を頼み直すこと、指示をひな形にすることの順に手を付けます。どれも、今使っている AI の画面でそのまま試せます。

最初に、AI に説明や要約を頼むときは、末尾に「冒頭に結論を1文と、話がいくつあるかを書いてください」と一言足します。効果はすぐ分かります。読み始めの数行で、全体の形が手に入るからです。洗濯の実験が示したとおり、同じ情報でも後から知らされた題は役に立たないので、目次は必ず冒頭に置かせます。

次に、出てきた文章の箇条書きが深すぎたり長すぎたりしたら、「箇条書きは2層まで、同じ層は5個まで」と頼み直します。理由や判断の経緯が箇条書きに分解されていたら、「この部分は2〜3文の文章で書き直してください」と指定します。稟議や報告のように読み手が理由を問う文書では、この直しを省かないでください。資料を通す側の工夫は「PowerPoint × 生成AIで稟議が通る資料を作る方法」でも扱いました。

最後に、AI に渡す指示のほうも、目的・読み手・材料・形式の見出しで区切って書く習慣をつけます。毎回書くのが手間なら、上の例をひな形として保存しておき、材料と読み手だけを差し替えます。資料作りの時間をどこで短くするかは「資料作成を60分から10分に短縮する現場の実装手順」に、Claude の基本的な使い方から順に学びたい場合は「Claudeを学ぶ8ステップ」にまとめています。

AI に任せた説明が頭に入らないとき、AI の性能を疑う前に、全体像を冒頭に置かせたかどうかを確かめてください。それで足りなければ、入れ子の深さと、理由が箇条書きに分解されていないかを見直します。