Claude Codeで資料・提案書を作る｜中身と体裁を分けて、配布の直前に変換する手順

Claude Codeによる提案書・スライド制作の解説は、検索すれば数多く見つかります。しかし社内業務へ取り入れると、担当者は似た壁にぶつかりがちです。最初の1枚は数分で完成しても、差し戻しが3回続くころには全面的な作り直しになるという問題です。

これは生成能力の不足が主因ではありません。内容づくりと見た目の整形を、同じ工程で済ませていることに原因があります。数字の訂正や章の入れ替えを求められるたび、文章と配置が結び付いた成果物全体を再生成するため、修正対象ではなかった部分まで崩れてしまいます。

そこで本記事では、伝える内容を構造のあるテキストで管理し、相手へ渡す直前だけ資料形式に仕上げる運用を紹介します。契約書案を文字情報として管理しておき、提出時にだけ書式を整える方法と同じ発想です。変換時に気づかないまま起こる不具合、目視確認を必須工程にする意味、提案書で根拠なく補完されやすい情報、別案件の素材を混入させない保管方法まで順に説明します。

仕様を調べるにあたり、Claude Code公式のセキュリティドキュメントとスキルのドキュメントに加え、Anthropic公開のAgent Skills のリポジトリにある資料形式関連の説明を参照しました。内容を確認した日は2026年9月1日です。製品の仕様や各スキルは変更されることがあるため、実際に導入する際は公式情報で最新状況をご確認ください。事例は当社または支援先で得た経験をもとにしていますが、顧客・取引先の名称や金額は記載していません。

上位記事を実際に読んで見つけた空白

執筆に先立ち、「Claude Code 資料作成」と「Claude Code パワポ」で検索上位に表示された記事を開き、内容を確認しました。目的は、既存の記事が取り上げていない領域を明らかにすることです。

最初に読んだのは、個人発信者が公開した約8,000字の記事です。論旨がはっきりしており、一読する価値があります。中心となる考えは、スライドという形式自体がAIの力を狭めている、というものです。既存の変換用ライブラリやツールにある制約を示し、Webページとして資料を実装して独自のデザイン体系を構築する案を提示しています。そもそもの形式を問い直す視点は、ほかの記事では見られませんでした。ただし対象は制作方法までであり、完成後の扱いまでは含まれません。修正依頼、機密情報、版の履歴、共同編集については論じられていません。

次に確認したのは、メディア企業が掲載した約8,000〜9,000字の実装解説です。変換ライブラリの使い方から、テンプレート設計、差し込み変数の紐付け、表データを使った一括出力、フォント・画像の留意点、導入後の評価指標まで、実行手順が丁寧に整えられています。日本語で読める記事の中でも、これほど実装が具体的なものは少数です。反面、生成後の検査方法、不具合の直し方、提出直前の確認事項、成果物の版管理は扱われていません。

それ以降に読んだ記事は、連携の設定方法や複数ツールの比較が主題でした。いずれも制作ツールの選択に焦点があり、社内承認を経て資料が外部へ渡るまでの流れは対象外でした。

4本を横断して確認すると、なお説明されていないテーマは次の3点に集約できます。

• 完成した時点で説明が終わっています。現場で多くの時間を奪うのは初稿ではなく、その後に繰り返される修正です。しかし検索上位の記事は、どれも最初の生成方法に記述の大部分を使っています
• どのように壊れるかが示されていません。資料への変換に失敗しても、処理がエラーで停止するとは限りません。ファイルは開くのに表示だけが崩れる場合がありますが、この現象を説明した記事は確認できませんでした
• 提案書ならではのリスクが抜けています。金額・期間・体制・実績は、もっともらしい文章として補完されやすく、読み直しても誤りに気づきにくい項目です。資料制作であると同時に、これは情報の線引きをどう設計するかという問題です

以降は、この3点に重点を置きます。初稿を生み出す具体的な操作は、すでに上位記事で詳しく説明されています。本記事が主に扱うのは、2回目以降の作業と、社外へ渡す直前の管理です。

時間を食っているのは「作る」ではなく「直す」

はじめに、実際の業務時間が何へ費やされているかを見てみましょう。当社と支援先で提案書制作の工程を記録した結果、初稿の準備時間を、2回目から後の修正時間の合計が上回るケースが一般的でした。修正依頼が一度で完了することは少ないためです。

提案書へ戻ってくる代表的な指摘は、次のように分類できます。

• 「3ページ目にある数値を最新情報へ更新して」——修正対象は内容です
• 「導入効果を説明する章を、体制の説明より先に置いて」——章立ての順序を変える依頼です
• 「この表を1枚の中に収めてほしい」——見た目に関する調整です
• 「先方の表現に揃え、”支援”ではなく”伴走”へ統一して」——使用語句を整える作業です
• 「A社用の資料をもとに、B社向けの版も用意して」——複製後に対象情報を差し替える依頼です

見た目まで一緒に生成していると、これら5種類の指摘はすべて、資料ファイル全体の再作成につながります。たった1つの数値修正でも、全ページが新たに出力されるのです。しかも新しい版が、以前と同じ配置になる保証はありません。1枚だった表が2枚へ分割されたり、見出しの折り返し位置や文字サイズが変わったりと、求められていない差分まで入り込みます。

そのため修正のたびに、担当者は資料全体を再点検しなければなりません。生成速度が向上しても、仕事全体が短縮されないのはこのためです。当社の支援現場で「AIを使っても資料制作が速くなった感じがしない」と評価された案件は、ほとんどが同じ工程設計になっていました。

必要な方針は明確です。指摘の種類に応じて、修正する場所をあらかじめ分けます。内容への指摘は内容ファイルで、表示への指摘は変換設定で直します。この分離ができていれば、数値だけを変更してもレイアウトには影響しません。

中身と体裁を分けるという作り方

制作フローを、内容と体裁の2工程に切り分けます。

前の工程で扱うのは伝える内容です。何を盛り込み、どの順で並べ、どう表現するかをテキストだけで組み立てます。タイトル、本文、発表者用メモ、図へ配置する要素も、すべて文字として保存します。この時点では書体・配置・配色を指定しません。

後の工程では見た目を整えます。確定したテキストを、受け渡しに適した形式へ変えます。社内だけの共有ならテキストのまま、提出が必要なら資料形式に仕上げるという判断です。形式変換を実施するのは、配布の直前に限ります。

工程を分離すると、現場では4つの利点が得られます。

• 文章を直しても配置規則が変わりません。テキストだけを更新し、変換側の設定を維持していれば、前回と同じルールで体裁が適用されます
• 変更箇所を行ごとに把握できます。テキスト同士なら1行単位で比較できるため、更新点を自動的に特定できます。資料ファイルだけでは、人が目視で探す必要があります
• 用語を漏れなく統一しやすくなります。テキスト上なら「支援」を「伴走」へ確実に揃えられますが、資料内では図形の文字や発表者ノートが修正対象から漏れがちです
• 別の提出先に合わせた展開が容易です。内容ファイルを複製し、固有名詞や条件に当たる部分だけを更新すれば新しい版になります

もともと当社では、契約書のたたき台に同じ設計を採用していました。契約書案もテキストとして保ち、相手へ渡す段階でのみ書式を付けます。なぜなら、変更した日時・担当者・場所を追跡するには、行単位で比較可能な形式が必要だからです。この事情は資料でも同様です。

中身をどの形で持つか

文字で管理するといっても、連続した文章だけでは変換処理が構造を判断できません。そこで、次に示す3条件を備えた形式にします。

第1の条件は、1枚分を1つのブロックとして区切ることです。各スライドの開始と終了を機械が判定できるようにします。見出し記号を境界に用いる方法が簡単です。境目を曖昧にすると、変換するたびにページの分割位置が揺れます。

第2の条件は、情報の用途をラベルで示すことです。見出し、本文、リスト、発表者メモ、出典を別々の行に置きます。役割が分かれば、見出しは大きく、出典は小さく表示する、といった変換規則を固定できます。印がなければ毎回用途を推測することになり、出力が安定しません。

第3の条件は、未確定部分を単なる空白にしないことです。詳しくは後述しますが、金額や期間を空欄にすると、変換後には未入力の事実自体が見えなくなります。たとえば[要確認：委託料]のように、確認が必要だと一目で分かる記号を置きます。

この3条件を前提にすると、依頼文は以下のように組み立てられます。当社の実用例から、社名などを除いて紹介します。

• 「この会議記録をもとに提案書の内容をテキストでまとめ、装飾やレイアウトは加えないでください」
• 「スライド1枚分を1ブロックとし、各ブロックの冒頭には見出しを配置してください」
• 「各ブロックは見出し、本文、箇条書き、話者メモの4行で構成してください。情報が存在しない役割は、空行を残さず該当行そのものを省いてください」
• 「会議記録にない数値、期間、体制を推測して記載せず、末尾の『要確認』欄へまとめてください」
• 「専門用語を初めて使う箇所には、1行の説明を添えてください」

とりわけ末尾の2項目が重要です。推量による補完を禁止しなければ、空いている情報は埋められます。モデルの性能よりも、依頼条件の設定に関わる問題です。具体的な依頼の組み方は、業務で効く頼み方でも解説しています。

体裁を当てる3つの経路と選び方

内容への合意が得られたら、受け渡し用の姿へ整えます。選択肢は3経路あり、判断軸は受け手が必要とする形式です。制作側の都合だけで決めると、後工程で手戻りが発生します。

第1の経路は、変換せずテキストを共有する方法です。社内での意見合わせ、上司への相談、チームへの情報共有であれば、多くの場合これで用が足ります。変換しない以上、表示崩れも起こりません。当社でも、社内資料のかなりの割合はテキスト段階で完了します。資料らしい外観が本当に必要かを先に検討すれば、工程を丸ごと省けることがあります。

第2の経路は、ゼロから資料を構築する方法です。指定テンプレートがなく、見た目を自由に決められる場合に向きます。テキストを資料形式に変換する処理を書かせて実行します。設計の自由は大きいものの、社内標準のデザインへ毎回揃える用途には不向きです。ロゴ、ブランドカラー、余白などを都度指定しなければなりません。

第3の経路は、用意済みの型へ内容を差し込む方法です。会社指定のテンプレートがあるなら、この方式を選びます。型そのものは変更せず、文字を置く領域を決めて流し込みます。どの版でも同じ外観を保てることが最大の強みです。提案書のように、統一された体裁が信頼感へ影響する文書に適しています。

要約すれば、社内だけなら第1、受け手指定の型があれば第3、どちらにも該当しなければ第2です。判断に迷う場合は第1から開始し、必要が生じた時だけ次へ進めるのが安全です。当社では第1で内容の承認を得た後、第3で仕上げる順番を標準にしています。見た目を整えた後で内容の議論を始めると、同じ作業を繰り返すことになるためです。

公式の作り方と上位記事が食い違う点

調査の過程では、説明の前提が一致していない箇所も見つかりました。実際に導入する読者にとって、この違いは特に役立つ情報でしょう。

Anthropicは、特定作業の進め方をClaudeへ与える「スキル」として、各種文書形式を扱うものを公開しています。2026年9月1日の確認時点では、公開リポジトリに文書、表計算、スライド、PDF用のスキルがあります。ただしApache 2.0で提供されるオープンソースではなく、閲覧可能な形での公開（source-available）だと明記されています。業務利用を始める前に、情報システム部門へ利用条件を確認してください。

スライド用スキルには、実装時に守るべき点が具体的に記されています。中でも注目したのは、次の内容でした。

• Webページ用の記述をスライドへ変換する手法は、推奨しない経路とされています。資料を作る場合は、生成ライブラリを直接利用する方法、または既存ファイルの内部を編集する方法が示されています
• 一般的な変換ライブラリについても、制約が具体名とともに記載されています。スライドを複製できない点や、テンプレートに含まれる一部画像形式を読み取れない点などが例示されています
• 生成後に人の目で確かめる作業が、必須手順に含まれています。資料をPDF化し、各ページを画像に変えて確認する流れです。ファイル内部の検査だけでは、文字のはみ出しを判定できないためです

この説明は検索上位記事の前提と異なります。最初の記事はWebページとして実装することを解決案とし、次の記事は変換ライブラリの利用を軸にしています。一方、公式スキルでは前者の変換ルートを勧めず、後者が用いるライブラリにも制約があると説明しています。

ここは区別して読む必要があります。最初の記事が提案しているのはWebページの状態で提供する方法であり、Webページをスライドに変換する方法ではありません。そのため、公式側が非推奨としている工程と完全に同じではありません。ここで伝えたいのは方法の優劣ではなく、同じ資料制作の記事でも、採用する前提や到達点が違うということです。記事の手順をそのまま採用すれば、書き手の前提まで自社の工程へ持ち込むことになります。

実務では、もう一点にも注意が必要です。Claude Codeへ初期状態で同梱されているスキルの一覧には、これら文書形式用のスキルがありません。2026年9月1日の公式情報でバンドル対象として紹介されているのは、診断、コードレビュー、一括処理、デバッグ、反復実行、API資料の参照などです。Claude Code上で文書用スキルを利用するには、自ら所定の保存場所へ追加しなければなりません。最初からパワーポイントを作れるものとして導入申請すると、必要作業の見積もりにずれが生じます。

変換の段階で静かに壊れる場所

資料変換の失敗は、常に分かりやすい停止として現れるわけではありません。出力は完了してファイルも開けるのに、表示や内容だけに問題が残ることがあります。公式スキルの注意事項と、当社が経験した事象を合わせて説明します。

第1の不具合は、色コードの形式が原因でファイル自体が破損することです。公式スキルでは、色指定を6桁の16進数だけで記述するよう求めています。冒頭に記号を付ける形式や、透明度を加えた8桁形式は破損を招くと明記されています。しかも生成処理の時点では、破損がエラーとして通知されません。完成後に開こうとして初めて発覚します。社内資料に載ったブランドカラー表記をそのまま渡すと、この問題に該当する可能性があります。

第2の不具合は、設定する順序によって全ページが既定サイズになることです。公式スキルは、ページを追加する前に用紙比率を指定するよう案内しています。先に追加されたページへ後から比率を指定しても反映されないためです。その結果、意図と違う比率の資料が完成します。単独ページの確認では見逃しやすく、投影時に発覚することがあります。

第3の不具合は、共通の設定データを再利用したときに後続ページが壊れる現象です。影や配置などをまとめた設定を複数ページで共有すると、処理途中の変更が別ページにも及ぶと公式スキルに記載されています。共通化による効率化を狙うほど遭遇しやすい問題です。人の感覚では同一設定の再利用が合理的に見えるため、避けるよう明示しなければ共通化されやすくなります。

第4の不具合は、文字が枠外へ出ても自動検査では判定できないことです。実務上もっともよく起きます。文章量が枠を超えても、文字は外へはみ出した状態で出力されます。データとしては正常なので、形式検証を通過してしまいます。日本語では文字ごとに横幅が異なり、英語のサンプルで収まった領域でも日本語にすると溢れる場合があります。当社では、長い会社名や役職名を入れた版で繰り返し発生しました。

第5の不具合は、削除したページに紐づく素材が内部へ残ることです。既存資料の内部を編集する方法では、ページを取り除いても、そこで使われていた画像やレイアウト定義が消えない場合があります。公式スキルは、削除後に必ず不要データを掃除する処理を行うよう求めています。この後処理を省くと、ファイルが開かなくなったり、不要に容量が増えたりします。

以上5つの問題には、処理中にエラーで知らせてくれないという共通点があります。法人導入でよくある失敗でも触れたとおり、仕事への影響が大きいのは明確に停止する障害より、誤りを抱えたまま進む障害です。資料変換にも同じ危険があります。

目で見る検査を工程に組み込む

前章で挙げた第4の問題は、機械だけでは見つけられません。したがって、人が見て確かめる作業を、正式な工程に含める必要があります。担当者の注意に委ねるのではなく、実施手順として固定します。

公式スキルが示す確認方法は、そのまま現場でも利用できます。出力した資料をPDFへ変え、ページ単位の画像を作って一覧表示する方法です。アプリ上で1ページずつめくる確認より効率的で、見落としも抑えやすくなります。

当社では、この手順へさらに2つの決めごとを加えました。

追加した第1の決めごとは、確認対象を4項目に限定することです。毎回、全ページの全文を最初から読み返す運用は長続きしません。継続できることを優先して、以下だけを確認対象にしました。

• 数値情報——金額、期間、件数、割合を確認します。1文字の違いだけで意味が変化する要素です
• 名称情報——提出先の会社・部署・担当者、自社の正式名称を見ます。以前の相手向けに使った名称が残っていないかを点検します
• 言い切っている箇所——「できます」「保証します」「必ず」などです。内容作成時に残した断定は、装飾後には見落としやすくなります
• 表示の欠けや重なり——枠を越えた文字、図形に重なる文字、途中で切れた文章がないかを見ます

追加した第2の決めごとは、制作者以外が確認を担当することです。書いた本人は内容を知っているため、文章を無意識に補って読んでしまいます。注意深さとは別の問題です。当社では、社外提出する提案書について、作成者とは異なる人が4項目を点検します。所要時間は5分程度で、全ページの精読よりも短く済みます。

確認対象を4つへ限定する運用は、当社が自社の自動化を続ける中で定着させました。あらゆる箇所を確認する決まりは守られにくく、実行されない検査は、存在しないのと同じだからです。

差し戻しはどこへ戻すのかを決める

ここまで説明した設計を採用すると、修正依頼への対応先を規則的に選べます。指摘された内容を判別し、該当する工程へ戻せばよいからです。

内容ファイル側で直す指摘——数値の更新、章の並べ替え、言葉の統一、表現の調整、項目の追加・削除が該当します。修正後は再び変換処理を実行し、体裁設定には手を加えません。

変換設定側で直す指摘——書体、配色、余白、ロゴ配置、1ページ内の行数などです。設定だけを変更し、内容ファイルはそのまま保ちます。

どちらへも直ちに戻せない指摘——「もっと理解しやすく」「魅力が伝わるように」といった抽象的な要望です。この言葉をそのまま再生成の指示にしてはいけません。内容と見た目が同時に変化し、それまでの承認事項まで失われるためです。依頼者へ、どのページの何が伝わりにくかったのかを確認し、内容に対する具体的な修正へ置き換えてから作業します。

当社は、この3分類を提案書制作の標準手順へ組み込んでいます。導入前は「分かりやすくして」という言葉が加工されないまま渡り、翌日には元資料と大きく違う案が出てくることが何度もありました。分類の目的は、迷わず処理するための負担軽減であり、慎重さを示すことではありません。

提案書で黙って埋まる6か所

ここからは提案書特有のリスクを考えます。提案書は契約へ進む前に提示する文書です。そこに記した事項が、後日「説明を受けた内容」として扱われる可能性があります。

契約書案の作成で当社が整理した、根拠なく補完されやすい箇所は、提案書にもほぼ共通します。会議メモから提案書を作るよう頼むと、記録に存在しない情報まで、違和感のない文として追加されることがあります。自然な文章なので再読時にも見抜きにくいのが問題です。実際に補われた内容を挙げます。

• 期間・工数——未決定にもかかわらず「3か月」「週1回」といった条件が記載されます。会話中の「おおむね四半期くらい」という発言が、確定条件のように変わる例です
• 業務の対象範囲——「含まれる作業」として、話題にしていない項目が追加されます。一般的な提案書にありがちな要素を補う形で起こります
• 実施体制——担当人数、各人の役割、稼働率などです。場合によっては組織図まで生成されます
• 費用に関する条件——金額だけでなく、支払時期、追加料金、値引き条件まで補完の対象になります
• 期待できる成果——「〜%減少」「〜時間の短縮」などです。特に危険で、裏付けのない数値が確かな情報のように記載されます
• 過去実績・事例——同じ業種での導入経験があるような表現です。存在しない事例が加えられる場合があります

防ぐには、後工程で削除するのではなく、生成時点で記載を禁止します。先述した、会議記録にない数値・期間・体制を追加しないという条件を、内容作成の依頼へ含めてください。自然な文章として紛れ込むため、完成後に探して消す方法では漏れが避けられません。

さらに、決まっていない項目を末尾へまとめて表示させます。当社では内容ファイルの最後に、次の3区分を必ず設けています。

• 合意済みの内容——先方との会議で決まった事項です。根拠として、合意した打ち合わせの日も付記します
• 提案案として置いた前提——記録上は未確定でも、案を成立させるため仮定した内容です。仮置きであることを明らかにします
• 判断が必要な事項——提出前に結論が要る情報です。判断する担当者も併記します

3区分に整理すると、別の用途にも使えます。その一覧が、そのまま上司へ判断を仰ぐ文章になるのです。決定済み、仮置き、要決定が明確に分かれているためです。当社では提案書レビューを依頼する際、この一覧を貼り付けるだけで相談内容が伝わるようになりました。

資料に載る数字は集計させない

提案資料や報告書へ掲載する数値について、当社は一貫した原則を設けています。AIには数値集計そのものを担当させません。

依頼する範囲は、数える処理を作るところまでです。実データの計算はプログラムが行い、AIには算出結果を説明する文章だけを作らせます。役割を分離するのには3つの理由があります。

• 同じ結果を再現できないからです。同一内容で再度依頼しても、同じ値になる保証がありません。決算や請求の証拠となる数字では許容できない問題です
• 誤りの場所を追跡できないからです。プログラムによる処理なら、対象行と計算方法をたどれます。AIが集計した結果だけでは、どの過程で誤ったかを特定できません
• 誤った値でも文章になじむからです。桁数が違っていても、文中に置かれると自然に読めてしまいます。前章で説明した自動補完と同じ危険です

提案書では、この原則が成果予測に直接関係します。たとえば「導入後は月40時間を削減できる見込みです」と記すなら、40という値の算出根拠を説明できなければなりません。当社が自社の短縮時間を提案資料に使う際は、必ず測定方法も一緒に示します。詳しい考え方は、費用対効果を社内で説明するで取り上げています。

また、第三者の記事から数値を転記しないというルールも守っています。公開記事に記載された製品価格が、提供企業の公式ページと一致しない事例を実際に確認したためです。転記した担当者は正しい情報だと思って扱います。提案書へ使う数字は一次情報で直接確認し、その確認日も記録してください。

案件をまたいで材料を混ぜない

提案書制作で最も重大な事故の一つは、他の顧客に関する情報が入り込むことです。単なる謝罪では収拾できない問題になり得ます。

情報混入の原因は明確です。以前の提案書を参照資料として渡す際、閲覧範囲を限定しなければ、見えるファイルすべてが素材候補になります。A社向け資料と同じ構成を求めても、同一フォルダにB社資料があれば、そちらの情報も使われる可能性があります。

防止策は注意事項ではなく、ファイルの配置で実現します。Claude Codeの公式説明では、開始フォルダと配下のフォルダだけに書き込め、明示的に許可しない限り親ディレクトリのファイルは変更できないとされています。読み取りも境界外では承認が必要になる設計です。この仕組みを、案件資料の隔離に利用します。

• 顧客案件ごとに専用フォルダを用意し、その場所から起動します。A社資料ならA社フォルダで開始する、という操作まで手順として定めます
• 全案件で使うテンプレートは、案件用フォルダへ複製して配置します。共有の親フォルダを参照可能にすると、せっかくの境界が機能しません
• 以前の案件を参考にする場合、対象の1件だけを作業フォルダ内へ複製します。過去案件一式のフォルダを参照対象にはしません

この3ルールは、注意力に頼る対策を物理的な配置へ変換したものです。忙しい状況では「混ぜないよう注意する」という決まりは破られます。使ってよい資料しかフォルダ内に存在しなければ、担当者が都度意識する必要はありません。この方法は、顧問先別に資料を管理する専門職でも、受託案件単位で情報を分ける事業でも活用できます。

同時に、提案書へ使用可能な素材の範囲も先に定めます。相手から提供されたファイルには、こちらが保管を約束していない情報まで含まれていることがあります。受領時に扱える情報を分ける方法は、入れてよい情報・いけない情報の線引きで詳しく説明しています。

テキストで持つと版管理が成立する

提案書は修正のたびに版が増えていきます。初稿、修正版、社内確認済み、先方コメント反映済み、最終稿という具合です。多くの組織で「最終版_修正_v3_確定.pptx」のようなファイル名が生まれています。

内容をテキストで保存すれば、この混乱を仕組みから解消できます。行ごとの差分を自動で比較できるため、前後の版で更新された箇所が明確になります。ファイル名だけに履歴を背負わせる必要はありません。

現場では、次の3情報を記録できるようになります。

• 変更した時期——更新したタイミングが履歴として保存されます
• 変更を行った担当者——複数人が同じ提案書を編集する場合に役立ちます
• 手を加えた場所——更新行が特定されます。文章全体を置き換えると、この記録は残りません

提案書では、特に3つ目の情報が重要です。提出先から以前の条件との違いを尋ねられた際、変更行をすぐ示せるかどうかで説明の明瞭さが変わります。資料ファイルだけで管理していれば、2ファイルを人が並べて読み比べる作業が必要です。

この点でも、提出直前まで体裁を付けない順番が効果を発揮します。レイアウト済みのファイル同士は、文章を行単位では比較できません。履歴の対象は内容テキストとし、配布用資料は特定の版から生成した出力物として位置付けます。元へ戻せる管理環境の整備は、非エンジニア向けの入門より先の内容になるため、必要に応じて別途準備してください。

配布の直前で必ず止める

資料は一度外部へ渡ると、完全には回収できません。送信元で消しても、受領者側には複製が残ります。提案書は相手企業内で共有され、発表資料は参加者の端末に保存されることがあります。

このため、外部配布の直前には必ず人が判断する地点を設けます。当社では以下の4点を決まりにしています。

• 初期状態では外へ出ない設定にします。完成しただけでは配布されず、操作を忘れた場合も事故ではなく遅延にとどまります
• 配布手段を1経路だけにします。経路が複数あると、確認前の版が別ルートから送られる恐れがあります
• 配布を承認した担当者を履歴へ残します。責任の追及ではなく、後日判断の経緯を確認できるようにするためです
• 確認対象は既述の4項目に限定します。数値、固有名詞、断定表現、表示のはみ出しを見ます

AIの生成物だから毎回全文を読む、というルールは継続が困難です。1回目は精読しても、5回目には一部を飛ばし、10回目には開くことすら省かれがちです。4項目だけに限定したのは、範囲を絞らなければ実行されなくなるためです。

当社ではこの設計を、ブログや自社サイトの更新作業で先に運用していました。公開直前に人が確認し、対象は4項目だけに限定します。権限設計でも、社外公開に当たる操作は自動的に通過しない設定です。運用上の規則とシステム設定を併用するのは、どちらか一方だけでは漏れを防ぎ切れないからです。

任せてはいけない5種類

最後に、資料制作でAIへ委ねない判断を整理します。能力的に処理できないからではなく、出力後に正否を確かめられないから除外するものです。

• 成果を保証する表現——「〜%減らせます」「〜を実現できます」などです。根拠を説明できない数値は、生成後に削るのではなく最初から書かせません
• 価格・条件の決定——見積金額の根拠、値引き判断、支払条件が該当します。案の段階で金額を補わせると、その値が標準条件のように受け取られます
• 別企業や他顧客の話——「他社の例では」「同業のA社では」といった記述です。架空の事例が事実らしく入る恐れがあり、守秘義務の面でも問題があります
• 法律・制度への断定的な説明——助成金の対象可否、契約の効力、業法上の判断などです。当社が助成金の記事を作る際は、公式一次情報で確認できた内容だけを「最大」の表記と期限を添えて記載し、最新情報は公式で確かめる注意書きも残します。提案資料でも同様です
• 受け手の判断を決め付ける言葉——「導入すべきです」「今期内に決裁する必要があります」などです。提案書が提供するのは判断材料であり、相手の結論ではありません

5項目を判別する基準は共通しています。誤りがあった場合、第三者が後から根拠を確認できるかを問いかけてください。文章の読みやすさや構成は、実物を読めば評価できます。しかし成果の確約や法律解釈は、文章を読むだけで妥当性を判断できません。成果物だけでは確かめられない判断は、担当させないのが原則です。

資料作成に関するよくある質問

Q. 結局、スライドは何で作るのが正解ですか？

正解は、受け手が求める形式によって変わります。社内共有だけならテキストで十分な場合が多く、資料への変換自体を省けます。相手指定のテンプレートがあるときは、そのファイルへ内容を差し込む方法が安定します。形式指定がなく自由に設計できるなら、生成ライブラリで新しく組み立てる方法が候補です。制作側の手軽さだけで決めると、後から体裁指定を受けた際に全面修正になります。なおAnthropic公開のスライド用スキルでは、Webページの記述をスライド形式へ変える経路は推奨されていません（2026年9月1日時点）。

Q. 会社のテンプレートを使いたいのですが、うまく反映されません

既存テンプレートを見本として提示するだけではなく、元ファイル内の内容を直接入れ替える方式にすると結果が安定します。見本から似た資料を作らせると別ファイルとして再現されるため、細かな余白やロゴ位置にずれが出ます。内部を差し替えれば、テンプレートの定義を維持できます。ただしページを取り除いた後は、不要データの清掃が欠かせません。未使用の画像やレイアウト定義が残り、ファイルを開けなくする場合があります。

Q. 文字がはみ出していないか、自動で確認できませんか？

2026年9月1日に調べた範囲では、自動判定が難しい領域です。文字が枠外へ出ていてもファイル構造は正常なため、一般的な形式検証では検知されません。公式スキルでは、PDFへ変換したうえで各ページを画像化し、一覧で目視する方法が案内されています。1枚ずつ開く方法より短時間で確認でき、抜けも少なくなります。日本語は同じ文字数でも表示幅が一定ではなく、英語版で収まった枠から溢れることがあります。長い社名や役職名を入れる版は特に注意してください。

Q. 打ち合わせ記録から提案書を作らせたら、話していない内容が入っていました

よく起きる問題であり、推測による補完を禁止すると明記しなければ、不足情報は埋められます。代表例は期間、業務範囲、体制、費用条件、成果予測、実績の6項目です。完成後に削除するのではなく、生成条件として最初から書かせないことが対策になります。もっともらしい文章に整えられるため、読み直しだけでは発見しにくいからです。未確定情報は末尾へまとめ、「確定している事項／この案での判断／要判断」の3区分に分けると、その一覧を上司への相談にも利用できます。

Q. 過去の提案書を参考にさせたら、別の顧客の情報が混ざりました

フォルダの配置によって、参照可能な資料を限定してください。公式ドキュメントでは、Claude Codeは開始フォルダとその配下を基本作業範囲とし、外側へアクセスする場合は承認を求める設計と説明されています。案件単位のフォルダを作り、その中から開始すれば、別会社のファイルは通常の素材範囲に入りません。以前の案件を参照する必要がある場合も、選んだ1件だけを現在の案件フォルダへ複製します。過去案件全体をまとめて見せる運用は避けましょう。

Q. 「もっと分かりやすくして」という差し戻しには、どう対応すればよいですか？

抽象的な依頼文のまま再生成へ渡してはいけません。内容とレイアウトが同時に変更され、それまでに確定した部分まで失われます。依頼者へ、伝わらなかったページと箇所を確認し、内容側の具体的な変更へ翻訳してから反映します。一見すると確認の手間が増えますが、資料全体を何度も作り直すより、最終的な往復時間は短くなります。修正を「内容で対応／体裁で対応／具体化後に対応」の3種類へ分ける規則を、手順書へ入れておくと安定します。

Q. 資料に載せる削減時間や効果の数字は、どう出せばよいですか？

AIへ数値の集計を依頼しないでください。数える処理の作成までを任せ、データの計算はプログラムで実行します。同じ指示から同じ数値を再現できるとは限らないこと、誤りが生じた工程を追えないこと、そして間違った結果でも自然な文章として読めることが、分業すべき3つの理由です。提案書には、測定手順まで説明できる数値だけを掲載します。第三者の記事からの転記も避けてください。公開記事の料金と、提供元の公式ページにある料金が異なっていた実例もあります。

Q. Claude Code には最初からスライドを作る機能が入っていますか？

2026年9月1日に確認した公式一覧では、Claude Codeへ標準搭載されるスキルに文書形式用のものは含まれていません。初期状態の対象として紹介されているのは、診断、コードレビュー、一括処理、デバッグ、反復実行、API資料の参照などです。Anthropicの公開リポジトリには、文書・表計算・スライド・PDF用のスキルがありますが、Apache 2.0のオープンソースではなく、参照可能な公開形態（source-available）だとされています。業務で利用する前に、情報システム部門と条件を確認してください。導入計画には、追加作業に要する手数も含める必要があります。

まとめ

本記事の結論を、最後にまとめます。

• 初稿の生成より、2回目以降の修正へ多くの時間が使われます。内容と体裁を同時に作る方式では、数値1つを変える場合にも全ページが再生成されます
• 伝える内容はテキストで管理し、外部へ渡す直前だけ見た目を整えます。文章の変更でレイアウトが揺れにくくなり、行単位で差分を確認できます
• 仕上げ方は3経路から、受け手の必要形式に合わせて選択します。社内共有だけならテキストの状態で完了でき、変換工程を省略できます
• 公式スキルでは、Webページ用記述からスライドへの変換を推奨しないと説明されています（2026年9月1日時点）。解説記事ごとに前提が異なるため、手順を採用する前に条件を確かめてください
• 変換に失敗しても、処理が停止するとは限りません。色指定による破損、比率設定の順番、設定データの再利用、文字のはみ出し、ページ削除後の残存物は、エラーなく表面化する場合があります
• 枠外へ出た文字は自動判定しにくいため、目視チェックを正式な工程にします。数値、固有名詞、断定表現、表示崩れの4項目だけを確認対象にします
• 修正依頼は、内容へ戻すもの、体裁へ戻すもの、具体化してから戻すものへ分類します。抽象的な「分かりやすくして」をそのまま渡すと、それまでの合意も変わります
• 提案書では、期間、業務範囲、体制、費用条件、成果予測、実績の6項目が補完されやすくなります。後から探して削除するのではなく、生成条件で記載を禁じます
• 数値計算は任せないことが原則です。集計処理だけを作らせ、実行はプログラム、算出値の説明文はAIという役割に分けます
• 作業開始地点を案件別フォルダに分けます。注意力で防ぐのではなく、他案件の素材が視野に入らない配置を作ります

資料制作は、Claude Codeを業務へ導入する際に試しやすい用途です。しかし、初稿を作れた段階で終わる運用では、工数は十分に減りません。修正内容ごとの戻り先を決め、点検箇所を限定し、外部配布の直前に人の判断を置いて初めて、継続的な短縮につながります。まずは社内共有用の資料を1件選び、装飾せずテキストで作るところから始めてください。