AIに読ませる資料の作り方。論文データで常識を見直す

社内の規程集をAIに読ませて質問したら、的外れな答えが返ってきた。製品マニュアルを丸ごと渡したのに、書いてあるはずのことを「分かりません」と言われた。せっかく整備した資料なのに、AIがうまく使ってくれない。

この経験をした方に、まずお伝えしたいことがあります。原因の多くは、AIの賢さではなく資料の側にあります。より正確に言うと、「人間が読みやすい資料」と「AIが使いやすい資料」は設計が違うのに、人間向けの資料をそのまま渡していることが原因です。

2026年8月、この問題を実データで裏付ける研究が続けて公開されました。この記事では、その研究の数字と、私たちKOIYALが自社のAI運用で実践している方法を突き合わせて、AIに読ませる資料の5原則にまとめます。研究はソフトウェア開発のAIエージェントを対象にしたものなので、一般業務への当てはめは私たちの解釈も含みますが、どこまでがデータでどこからが解釈かを分けて書きます。

# 研究1: AIは、立派なマニュアルをほとんど読んでいない

1本目の研究(arXiv:2608.20195・査読前のプレプリントです)は、AIコーディングエージェントの557の作業セッション、94,813の行動記録と、エージェントが作成した33,097件の変更提案を分析し、AIが「何を読み、何を書いているか」を調べました。

最も衝撃的な数字は時間配分です。エージェントが文書に使った時間のうち、60.5%は「エージェント向けの成果物」、つまり指示ファイル(CLAUDE.mdやAGENTS.mdのような、AIへの申し送り)や作業メモに向けられていました。一方、人間が丁寧に作る**従来型の技術文書は10.6%、APIリファレンスにいたっては1.3%**でした。

さらに、AIが文書を読むのは70.2%が自発的なタイミングで、エラーで困ってから読む「失敗駆動」は7.5%にすぎません。人間のように「詰まったらマニュアルを引く」働き方ではなく、自分のタイミングで手元の指示と申し送りを読みにいく働き方です。

この研究が「人間向け文書の常識への反証」と呼ぶ通り、含意ははっきりしています。AIのために立派な網羅マニュアルを作り込むより、簡潔な指示ファイルと作業の申し送りを整える方が、実際に読まれるということです。

# 研究2: 知らないことをAIは「間違えて埋める」

2本目の研究(arXiv:2608.16630・同じくプレプリント)は、逆方向からこの問題を照らします。7つのAIモデル×5つの実行環境で、作業に必要な事実(仕様やルール)を意図的に隠したり与えたりする実験をしました。

この研究は、作業に必要な事実が「渡した資料」にも「AIがもともと知っている知識」にも無い状態を「一貫性負債」と名付けています。結果は明快でした。AIが知らない新しい仕様について、資料でも事実を渡さなければ、どのモデルもタスクを完了できませんでした。そして必要な事実をプロンプトに入れると、成功率は回復しました。

重要なのは失敗の形です。事実が足りないときAIは「分かりません」と止まるのではなく、それらしく間違った作業をする傾向が観察されました。社内ルールを知らないAIは、世間一般のルールで埋めて、自信ありげに間違えるのです。また、同じ課題を達成できる構成同士でも、資料の渡し方次第で処理量(トークン消費)が10倍以上違うことも示されました。渡し方は、精度だけでなくコストにも効きます。

2本を合わせると、AI向け資料の設計問題はこう整理できます。読まれる場所(指示ファイル・申し送り)に、AIが知らない自社の事実を、確実に届ける。これが本質で、以下の5原則はすべてこのための方法です。

# 原則1: 要約して渡さない。生のまま渡す

社内資料をAIに渡すとき、多くの人が親切心で「要点をA4一枚にまとめて」から渡します。私たちはこれをやめました。要約は人間の圧縮であり、圧縮の過程でAIの材料が捨てられるからです。

考えてみると構図は単純です。アウトプットを整えること、つまり長い材料を短くまとめることは、AIが得意中の得意です。逆に、すでに要約されたものを元の情報量に戻すことは、AIには原理的にできません。足りない部分はAIの推測で埋まりますが、研究2で見た通り、その推測は「それらしい間違い」になります。要約して渡した資料への回答が薄いのは、当然の帰結です。

実務では、会議の録音の文字起こし、判断の経緯が残ったメールのやり取り、過去の見積もりの実物。こうした一次資料をそのまま渡します。整形はAIの仕事、材料の確保が人間の仕事です。

私たちの自社運用では、これを徹底しています。代表が考えを共有するとき、きれいな企画書に整え直さず、本人の言い回しと考えた順番を残したまま社内のネタ帳に貯めています。理由は明快で、言い回しや思考の癖にこそ情報が入っているからです。「要約すると同じ」に見える2つの表現でも、どちらの言葉を選んだかに判断基準がにじみます。AIにその人らしい仕事をさせたいなら、その人らしさが残った生の材料を食べさせるしかありません。

もうひとつ実務のコツを足すと、記録を残す習慣そのものが資料整備になります。会議は録音して文字起こしする、判断はチャットに書いて流さず残す。AI時代の文書整備は「立派な資料を書く」ことではなく「生の記録をとにかく残す」ことから始まります。録音や文字起こしのツールを全社員が使える状態にするのは、その第一歩として費用対効果が高い投資です。

# 原則2: ゴールは例示で絞って見せる

原則1と対になる原則です。材料は生のまま広く渡す一方で、求めるアウトプットの形は、完成見本で狭く示します。

私たちの運用では、AIに新しい種類の成果物を作らせるとき、まず80点の見本を数パターン用意して「これがゴール」と示します。品質の言葉での説明(「分かりやすく」「プロらしく」)は、AIの解釈がぶれます。見本はぶれません。

具体例で言うと、議事録をAIに任せるなら、過去の会議から「よく書けていた議事録」を2〜3本選んで渡し、「この形で」と言うだけです。見本が2〜3本あると、AIは共通点(決定事項が先・担当と期限つき・発言録は要点だけ、など)を読み取って再現します。100点の理想形を言葉で定義する作業は要りません。80点の実物が数本あれば、品質はそこで固定されます。

ここで多くの人が抱く疑問は「見本もなしに、ゼロから良いものを作らせられないのか」でしょう。作らせられますが、出てくるのは「世間一般の議事録」です。見本を渡さなければ、AIが頼れるのは学習済みの世間一般の型だけになります。見本を渡さないという選択は、自社の型を捨てて世間の平均を選ぶという意味になります。

まとめると、入力は生のまま・広く、出力は見本で・狭く。この非対称が、AIに仕事を任せる設計の背骨です。

# 原則3: 「いつもの指示」と「今回の材料」を分ける

研究1で見た通り、AIは指示ファイルを一番読みます。だからといって、そこに何でも書くと逆効果になります。指示ファイルは毎回読み込まれるため、太るほど本当に重要な指示が薄まるからです(この問題は別の記事で詳しく書きました)。

使い分けの基準は単純です。毎回守るべき原則だけを指示ファイルに、今回の作業の材料は都度渡す。社内でいえば、就業規則の全文を毎回読ませるのではなく、「当社の文書はこの形式・この用語で」という原則だけを常設にし、個別の規程は質問に応じて渡す構造です。

# 原則4: 構造は機械が辿れる形にする

人間は資料を「見た目」で辿ります。太字、色、レイアウト。AIは「構造」で辿ります。見出しの階層、ファイル名、リンク。

具体的には3つです。

①見出しに内容を書く。「第3章」「その他」ではなく「経費精算の締め日と例外」。AIは見出しを手がかりに読む場所を決めるので、見出しが中身を語らない資料は、全文を読まないと使えない資料になります。

②ファイル名で中身が分かるようにする。「資料_最終版(2).docx」は、人間にもAIにも何のファイルか分かりません。「2026-08_経費精算規程.docx」のように、日付と内容をファイル名に入れます。地味ですが、AIに複数の資料を渡す運用では効果が大きい習慣です。

③関連する資料同士をリンクでつなぐ。規程から申請フォームへ、議事録から決定の背景資料へ。リンクがあれば、AIは必要に応じて参照先をたどれます。

この3つだけで、AIの参照精度は目に見えて変わります。しかも、どれもAI専用の作業ではなく、人間にとっても探しやすい資料になる改善です。

ツール側もこの方向に動いています。たとえばWordは、文書内の特定の見出しやブックマークへのリンクを簡単に作る機能の提供を始めています(2026年8月時点ではテスト提供の段階です)。文書を「参照可能な構造」にする流れは、AI活用を前提にした文書作成の標準になっていくと私たちは見ています。

# 原則5: 鮮度を仕組みで守る

研究2で見たのは「事実が無いとき」の挙動でしたが、実務ではもうひとつの形があります。古い事実が渡っているときです。AIは渡された資料を信じて使うので、組織変更前の承認フローや改定前の価格表も、自信を持って答えに使います。古い資料の誤りは「根拠がある」という顔をしている分、無い場合より見つけにくいのです。

対策は資料に確認日を書くこと、そして定期的な棚卸しをカレンダーに入れることです。私たちは自社の公開文書・社内文書に確認日を入れ、鮮度切れを機械的に検出する仕組みを回しています。具体的には、週に1回スクリプトが公開している記事・制作物のドラフト群を走査して、確認日から90日を超えた規約・仕様の記述や、「◯年◯月まで」のような期限つきの記述で期限が過ぎたものを一覧にします。人が「そういえばあの資料、古くないか」と思い出すのを待たず、機械が候補を挙げて、人は直すかどうかだけ判断する分担です。

外部サービスの仕様を書いた資料は特に要注意です。私たちは過去に、自社ブログの解説記事群を別のAIにレビューさせたところ、外部ツールの仕様に関する事実誤りが26件見つかった経験があります。26件はすべて、新しく書いた部分ではなく、過去に書いた既存の記述から出ていました。人の注意力ではなく仕組みで守るのがポイントです。

# よくある質問

「検索連携(RAG)のツールを入れれば解決するのでは」 道具は助けになりますが、土台は同じです。検索連携の仕組みは、資料を小さな断片に分けて、質問に関係しそうな断片を探して渡します。このとき、見出しが内容を語らない資料、要約済みで情報の落ちた資料、古いままの資料は、断片になっても弱いままです。ツール導入の前に原則1〜5を通しておくと、同じツールでも結果が変わります。

「全部の資料を書き直すのは無理がある」 書き直しません。優先順位は「AIに任せたい業務で実際に参照される資料」だけです。そして新しく作る資料からこの原則で書く。既存資料は、その業務で使うときに直す。全社文書刷新プロジェクトにした瞬間に頓挫するのは、AI以前の文書整備と同じです。

「機密資料を渡してよいのか」 渡し方の設計が先です。何をAIに渡してよいか(顧客名は伏せる・パスワードや鍵は絶対に渡さない・契約上の秘密保持対象は範囲を確認する)を先に決めるのは、資料の書き方以前の運用ルールです。この記事の原則は「渡すと決めた資料を、効くように渡す」ための話で、渡す範囲の判断は別途必要です。

# 明日からの3ステップ

自社で始めるなら、この順番をおすすめします。ポイントは、文書の整備を目的にせず、1つの業務の精度を上げる手段として始めることです。

1. AIに任せたい業務を1つ選ぶ(議事録、問い合わせ回答、見積もりの下書きなど)
2. その業務でAIに渡している資料を全部並べる。要約版を渡していたら原文に差し替える(原則1)
3. 完成見本を2〜3個用意して、指示は「原則だけ」に書き直す(原則2・3)

構造化(原則4)と鮮度管理(原則5)は、この1業務がうまく回ってから広げれば十分です。全社の文書整備から始めると、効果が出る前に力尽きます。

# まとめ

• AIは網羅的なマニュアルをほとんど読まず(時間の10.6%)、指示ファイルと申し送りを読む(60.5%)。読まれる場所に書く
• 必要な事実が渡されていないとき、AIは止まらずに「それらしく間違える」。自社固有の事実こそ確実に渡す
• 入力は生のまま広く、出力は見本で狭く。要約して渡すのをやめる
• 見出し・ファイル名・リンクの構造と、確認日つきの鮮度管理を仕組みにする

社内資料をAIに読ませる仕組みを作りたい企業の方へ。KOIYALでは、AIに読ませる前提での文書設計(何を指示ファイルに、何を都度渡すか)、既存資料の棚卸しと構造化の伴走、現場向けの「AIに伝わる書き方」研修を提供しています。資料はあるのにAIがうまく答えない、という状態は設計で直せます。お問い合わせからご相談ください。