トップ / 記事一覧 / AIを使った資料作成のコツ——「丸投げ」をやめて4つの順番で作る

SHARE

AIを使った資料作成のコツ——「丸投げ」をやめて4つの順番で作る

AIを使った資料作成のコツ——「丸投げ」をやめて4つの順番で作る

パンハウスインサイト編集部
2026.07.14

「AIに資料作って」がうまくいかない理由

生成AIを使い始めた人が、資料作成でだいたい一度は通る道があります。

「AIに提案資料を作ってと頼んだのに、それっぽいだけで、そのままは使えない」

見出しは並んでいる。文章も一見きれい。でも読み返すと中身が薄く、デザインもどこかチグハグで、直そうとすると全体が崩れる——。そして結局、自分で一から作り直すことになります。

原因は、AIの性能ではありません。頼む順番です。

考えてみると、私たち自身も資料を作るとき、いきなりスライドの1枚目から作り始めたりはしません。まず「何のために・誰に・何を伝える資料か」を頭の中で整理し、次に話の流れを決め、それから見た目を整える。この順番を、無意識にたどっています。

AIに資料を「丸投げ」するというのは、この順番をすべて飛ばして、いきなり「完成品」を要求している状態です。順番を飛ばせば、人間がやっても良い資料はできません。AIも同じです。

この記事では、実際に社内で作った提案資料(ある経営層向けのセミナーを提案する、全14枚のスライド資料)を題材に、AIで資料を作るときの4つの順番を紹介します。使ったのはターミナル(黒い画面に文字で指示するタイプのツール)上で動くAIエージェント「Claude Code」ですが、考え方はChatGPTなど他のツールでもそのまま使えます。

その1:まず「背景」を言語化させる

この資料づくりの出発点は、上司から社内チャットで届いた、たった一言の依頼でした。

「経営層向けの勉強会の提案資料を作ってほしい。ターゲットは経営者が集まる団体・会」

ここで最初にやったのは、資料を「作る」ことではありません。この依頼の背景を、AIと一緒に文章に起こすことです。具体的には、次の3つをはっきりさせました。

  • 狙い — この資料は「送って終わり」ではなく、送った相手に勉強会を「主催してもらう」ためのもの。つまりゴールは”開催の決断”を後押しすること
  • 読み手 — 実際に読むのは、主催を検討する団体の事務局や経営者。だから資料には「参加する価値」ではなく「主催するメリット」が必要になる
  • 前提 — 講師は誰で、何を語れるのか。過去にどんな実績があるのか

この整理を先にやると、後の全工程が一本の軸で通ります。逆にここを飛ばすと、「なんとなく良さそうなAI活用資料」はできても、「主催を決断させる資料」にはならない。出発点が一言だからこそ、その一言に隠れている狙い・読み手・前提を、最初に言葉にしておくことが効きます。

もう一つの前提——「自社の情報」はAIに作らせない

前提のなかでも特に注意したいのが、講師の実績・過去の導入社数・提供できるプログラムの型といった「自社の情報」です。ここをAIに推測させると、事実と異なる数字や、それらしい記述が混じることがあります。資料の信頼を一発で崩す原因が、たいていここに潜んでいます。

そこで今回は、これらの事実をAIに考えさせず、あらかじめ用意した自社の正確な情報として渡しました。この「AIに自社のことを正しく教えておく資料」は、一般にナレッジファイル(知識ファイル)と呼ばれます。今回はClaude Codeの「スキル」という仕組みでまとめて渡しましたが、これはツール固有の話ではありません。ChatGPTでも他のツールでも、“自社の前提をまとめたテキストを用意して渡す”という考え方はまったく同じです。

AIの仕事は「事実を作ること」ではなく、「渡された事実を、読み手に刺さる形に組み立てること」。この切り分けが、その1の肝です。ナレッジファイルの作り方そのものは、別記事で詳しく解説しています:AIに「自社のこと」を覚えさせる——システムプロンプトとナレッジファイルの仕組みと使い方

実際は「1つの完璧なプロンプト」ではなかった

正直に打ち明けると、この背景整理は、用意周到な1つのプロンプトで一気に渡したわけではありません。実際は、こんな短いやり取りの積み重ねでした。

  • まず、依頼の元になったチャットのスレッドをAIに読ませる——「この資料作成の背景を確認して」。依頼の一次情報は、たいてい会話ログの中に埋もれているからです。今回はClaude Codeと社内のチャットツール(Slack)を連携させているので、スレッドのリンクを渡すだけでAIが中身を直接読みに行けます。わざわざコピペで貼り付ける必要すらありません
  • そこに口頭で条件を足す——「読み手は”経営者が集まる団体・会”」「狙いは、送った相手にこの勉強会を”主催してもらう”こと」。補足する内容が多いときは、キーボードで打たずに音声入力で流し込むことも多いです。話しかけるように条件を足していけるので、身構えずに前提を渡せます
  • 自社の実績・講師・提供メニューは、用意してある自社の情報(ナレッジファイル)を参照させる——ここをAIの記憶や推測に任せると、導入社数や実績を”それっぽい数字”で埋めてしまうことがあります。正確な事実をまとめたファイルを渡しておけば、AIはその範囲でだけ書くようになり、資料に嘘が混じりにくくなります

つまり、立派なプロンプトを一発で書く必要はありません。大事なのは”文章の巧さ”ではなく、渡す情報の順番と種類です。①依頼の一次情報、②口頭で足りない条件、③自社の情報(ナレッジファイル)——この3つが揃えば、AIは背景を正しく掴めます。逆に、この3つのどれかを省いて「いい感じの提案資料作って」と打つと、AIは足りない部分を”それっぽく”埋めてしまう。それが、冒頭の「使えない資料」の正体です。

コツ:いきなり「作って」と言わず、「この依頼の狙いと読み手を整理して」から始める。そして、実績や社数といった「自社の情報」は、AIに推測させず正確な情報を渡す。AIは、前提を渡さないと、足りない部分を自分で推測して埋めてしまいます。前提を口頭の一言のままにせず、文章にして共有するのが第一歩です。

その2:デザインの前に「中身」を文章で確定する

背景が固まっても、まだスライドは作りません。次にやるのは、スライド1枚ずつの中身を、ただの文章として書き切ることです。具体的には、AIに「構成.md」という1つのマークダウンファイルを作らせます(マークダウンは、装飾を使わずテキストだけで見出しや箇条書きを書く形式のこと。詳しくは別記事をご覧ください)。

今回でいえば、「表紙にはこの一言」「2枚目はご提案の全体像で、誰に・何を・どんな形で、の3点」「3枚目はなぜ今なのか」……というふうに、14枚分の”設計図”をテキストで先に作りました。色もフォントも図もない、文章だけの状態です。

なぜデザインより先に中身なのか。文章の段階なら、修正が一瞬で終わるからです。

  • 「この3枚目は要らない、削って」→ 一行消すだけ
  • 「7枚目と8枚目を入れ替えて」→ 段落を並べ替えるだけ
  • 「主催のメリットが弱い、もう1つ足して」→ 箇条書きを1行足すだけ

もしこれを、デザイン済みのスライドでやろうとしたら、レイアウトの作り直しが毎回発生します。実際、今回も設計図を見ながら「全体像のあとに目次を入れよう」「このパートは経営者向けに表現を変えよう」といった調整を何度も重ねましたが、文章だったからこそ、そのやり取りは驚くほど速く進みました。

実際に打っていた指示

その2で最初にやったのは、たった一言でした。

まず、この提案資料を1枚ずつ設計します。各スライドについて「見出し」「そのページで伝えたいこと」「載せる要素(箇条書き・表など)」を書き出し、全体を1つのマークダウンファイル(構成.md)にまとめてください。最初に、全体で何枚・どんな順番にするかの案から見せてください。

これで文章の骨格(=14枚の設計図)が出てきます。あとは、その文章を見ながら短い指示で直していくだけ。実際に打っていたのは、こんな一言たちでした。

  • 「この6枚目のプログラム例は、社内の研修設計のルールを参考にして」
  • 「“あくまで一例で、事前の打ち合わせで決めます” と、表の上に一文足して」
  • 「この25分パートは詰め込みすぎ。“網羅”より、経営判断につながる論点に絞って」
  • 「この行は削除して」「目次も作っておいて」

どれも一言です。文章の段階だから、直しがこの短さで済む。もしスライドを作り込んだ後で同じことをやっていたら、一つひとつがレイアウトの作り直しになっていたはずです。ここでいくら直しても痛くない、という状態を作っておくのがその2の狙いです。

コツ:スライドは「文章が確定してから」作る。中身とデザインを同時にAIに任せると、直すたびに両方が崩れやすくなります。まず文章で骨格を合意し、それを”確定稿”として扱うと、後戻りが激減します。

なお、この段階で実際に作る「構成ファイル」のサンプルを公開しています(スライドを作る前の”文章だけ”の設計図。固有名は伏せた汎用版です):構成ファイルのサンプルを見る

その3:デザインは「型」を1つ渡す

中身が固まったら、いよいよ見た目です。ここでよくある失敗が、「かっこいいデザインにして」とだけ伝えて、ゼロから作らせてしまうこと。これをやると、毎回テイストが変わり、社内の資料がバラバラになります。

今回とった方法はシンプルです。すでにある完成物を1つ、見本として渡す

今回も、あらかじめ用意してあるデザインシステムのHTMLの型を渡して、「このデザインに合わせて」と伝えました。すると、色の組み合わせ(濃紺×オレンジ)、フォント、ロゴの位置、ページ番号の付け方まで、新しい14枚が一気に同じテイストで揃いました。ゼロから「良いデザイン」を探させるより、決まった型を1つ渡すほうが、速く、ブレません。

「型」は、デザインシステムとして持っておく

この「見本にする型」は、毎回その場で用意しているわけではありません。パンハウスでは、Claude Codeの「Claude Design」という機能にあるデザインシステム(DesignSystem)を使って、あらかじめHTML形式の型を作ってあります。色・フォント・余白・ロゴの扱いといったルールを1つのデザインシステムとしてまとめておき、資料を作るたびに、それを土台として使っています。だからこそ、誰がいつ作っても、同じテイストの資料に仕上がります。(Claude Designの具体的な使い方は、別記事で改めて扱います)

コツ:「良いデザインを考えて」ではなく「この見本に合わせて」と指示する。会社としてテイストを揃えたいなら、“見本にする1枚”を決めておくと、以降の資料づくりが標準化されます。

その4:最後は「画面で見ながら」直す

ここまでで、送れる形の資料がひとまず出来上がります。でも、最後の仕上げは人間の仕事です。

AIは資料を「作る」ことはできますが、出来上がったものの良し悪しを最終判断するのは、まだ人間のほうが得意です。そこで、完成したスライドを1枚ずつ画像にして目で確認し、気になった点を直す——という地道なループを回します。今回、実際に出たのはこんな修正でした。

  • ロゴが背景に沈んで見えない → 明るいページは濃紺のロゴ、暗いページは白いロゴ、と使い分ける
  • 表現が言い過ぎ(「特に好評」「総本山」など断定的な言葉)→ 事実ベースの落ち着いた表現にトーンダウン
  • 箇条書きの体裁が崩れている → レイアウトを微調整

どれも、文章を読んでいるだけでは気づきにくく、画面で見て初めて分かる類のものです。逆に言えば、ここさえ人間が丁寧に見れば、AIが作った資料も”そのまま送れる品質”まで持っていけます。

コツ:完成イメージを画面で確認してから世に出す。AIの出力を鵜呑みにせず、「見た目」と「言葉の強さ」だけは必ず人の目を通す。この最後のひと手間が、資料の信頼感を決めます。

そして、この4ステップで仕上げた「完成版スライド」のサンプルもどうぞ。その2で見た構成ファイルが、最終的にどんな資料になるのか、見比べてみてください(PDF・全14枚。同じく固有名は伏せています):完成版スライドのサンプルを見る

まとめ:丸投げより「4つの順番」

AIで資料を作るコツは、突き詰めると「丸投げしない」ことに尽きます。そして、丸投げしないための具体的な手順が、この4つの順番でした。

  1. 背景を言語化させる — 狙い・読み手・前提を先に文章にする
  2. 中身を文章で確定する — デザインの前に、1枚ずつの設計図を書き切る
  3. デザインは型を1つ渡す — ゼロから作らせず、見本に合わせて揃える
  4. 画面で見ながら直す — 見た目と言葉の強さは、最後に人が確認する

この順番で作ると、良いことが3つあります。担当者が変わっても品質が落ちにくい(型と手順が残るから)、作る数が増えても回せる(毎回ゼロから悩まないから)、そして修正が速い(後戻りが少ないから)。今回も、チャットの一言から、そのまま送れる14枚の提案資料まで、この順番でたどり着きました。この進め方で実際に商談フォローの資料を30分で仕上げた実例は、商談後30分でここまでできたで紹介しています。

AIに「良い資料を作らせる」秘訣は、実はプロンプトの上手さではありません。人間が資料を作るときの当たり前の順番を、AIとの間でも丁寧に踏むこと。それだけです。

なお、この考え方をさらに一歩進めて、「AIが自分で起動して、営業準備を毎朝終わらせる」ところまで自動化した事例も別記事で紹介しています。あわせてどうぞ:誰も起こさなくても動く——Claude Codeが毎朝6時に営業準備を終わらせる仕組み

資料作成を含む「日々の業務」をAIで軽くしませんか?

何をどこまでAIに任せられるのか、自社の業務に当てはめて一緒に整理します。型として残せば、担当者が変わっても・数が増えても回る——そんな仕組み化までご一緒します。「まず何から手をつければいいか分からない」という方もお気軽にご相談ください。

お役立ち資料 AI導入を前に進める
推進担当者の教科書
導入前に整理しておきたい考え方、ルール設計、ツール選定、社内定着の進め方をまとめた資料です。 無料でダウンロードする

この記事を書いた人