Claude Codeでパワポ・Excel・Wordを一括生成する共通入力と検証

営業提案書はパワポ、月次レポートはExcel、契約書の下書きはWord。業務ドキュメントの生成を自動化しようとすると、ファイル形式ごとにスクリプトが分かれ、管理が属人化しやすくなります。テンプレートの置き場所もバラバラ、実行手順も担当者の頭の中だけ、という状態は多くの現場で見られます。

結論として、パワポ・Excel・Wordを1つの仕組みから作るには、3形式が同じ値を読む「共通入力」を1つ決め、形式ごとの出力の後に「検証」の工程を必ず入れます。共通入力には、項目名、単位、対象期間、元データの出典と取得日時を持たせます。検証では、出力した数値が共通入力と一致するか、テンプレートの差し込み記号が残っていないか、ファイルが開けるかを確かめます。Claude Codeには、この3つの工程（取得・加工・出力）と検証をまとめたスクリプトを作らせ、形式ごとの細かい実装はパワポ・Excel・Wordの各記事の手順に分けます。

この設計が向いている場面

• パワポ・Excel・Wordを定期的に、それぞれ別のスクリプトで生成している
• テンプレートやスクリプトの管理が特定の担当者に依存している
• 月次や週次で同じデータソースから複数形式のドキュメントを出力している
• 生成物のバージョン管理や差分追跡ができていない

共通するのは「形式ごとにバラバラだった生成フローを1本にまとめたい」という課題です。

ドキュメント生成パイプラインの全体像

業務ドキュメントの自動生成を安定させるには、ファイル形式ごとにスクリプトを書くのではなく、パイプライン全体を3つのレイヤーに分けて設計します。データ取得、加工、出力の3層です。この分離により、データソースが変わっても出力層は触らず、出力形式が増えても上流はそのまま使えます。

Claude Code が最も力を発揮するのは、このパイプライン全体のスクリプトを一括で生成・修正できる点です。「CRMからデータを取得して、月次サマリーに加工し、パワポとExcelの両方で出力するスクリプトを作ってください」という指示で、3レイヤーを通したコードが生成されます。

データ取得→加工→出力の3レイヤー設計

各レイヤーの具体的な設計を見ていきます。ディレクトリ構成は次の形が実務で安定します。

doc-pipeline/
        ├── src/
        │   ├── fetch/              # レイヤー1：データ取得
        │   │   ├── crm_client.py
        │   │   ├── sheets_client.py
        │   │   └── csv_loader.py
        │   ├── transform/          # レイヤー2：加工
        │   │   ├── monthly_summary.py
        │   │   ├── customer_profile.py
        │   │   └── common_filters.py
        │   └── render/             # レイヤー3：出力
        │       ├── pptx_renderer.py
        │       ├── xlsx_renderer.py
        │       └── docx_renderer.py
        ├── templates/
        │   ├── report_master.pptx
        │   ├── monthly_report.xlsx
        │   └── contract_draft.docx
        ├── output/
        ├── main.py                 # 統合エントリポイント
        ├── config.yaml             # 設定ファイル
        └── requirements.txt
        

レイヤー1：データ取得では、外部ソースとの接続を1か所にまとめます。CRM API、Google スプレッドシート、ローカル CSV など、データの入り口が変わっても他のレイヤーに影響しません。Claude Code に「SalesforceのAPIから商談データを取得するfetchモジュールを作ってください」と伝えれば、認証処理からデータ取得、JSON変換までを生成してくれます。

レイヤー2：加工では、取得したデータを出力に必要な形に変換します。月次の売上集計、顧客ごとのフィルタリング、テキストの整形などをここで行います。このレイヤーの出力は Python の辞書やデータフレームなど、ファイル形式に依存しない中間データです。

レイヤー3：出力では、中間データをファイルに変換します。python-pptx、openpyxl、python-docx の各ライブラリがここで使われます。テンプレートの読み込みとプレースホルダーの差し替えだけを担当するため、ロジックが薄く保守しやすい構成になります。

共通入力を1つに決める

3形式で数値がずれる原因の多くは、形式ごとに別々に集計していることです。加工レイヤーの出力を「共通入力」として1つのファイル（例：JSON）に書き出し、出力レイヤーはそれだけを読むようにします。

Claude Codeには「加工の結果を共通入力のJSONに書き出し、pptx・xlsx・docxの各出力はこのJSONだけを読むようにしてください」と指示すると、形式ごとの集計の重複を防げます。

パワポ・Excel・Wordを1スクリプトで回す実装例

3レイヤーを統合するエントリポイント main.py の設計です。Claude Code に対して次のように指示すると、統合スクリプトが生成されます。

# Claude Codeへの指示例
        「main.py を作ってください。
        config.yaml から出力対象（pptx, xlsx, docx）を読み、
        fetch → transform → render の順に実行するパイプラインです。
        出力対象は config で選択でき、全形式を一括でも個別でも実行できるようにしてください。
        エラー時は該当形式だけスキップして、他の形式は生成を続行してください。」
        

config.yaml で出力対象を制御する設計にすると、「今月はExcelだけ出したい」「全形式まとめて生成したい」の両方に対応できます。

# config.yaml の例
        data_source:
          type: csv
          path: data/sales_2026q1.csv

        outputs:
          pptx:
            enabled: true
            template: templates/report_master.pptx
            output_path: output/monthly_report.pptx
          xlsx:
            enabled: true
            template: templates/monthly_report.xlsx
            output_path: output/monthly_data.xlsx
          docx:
            enabled: false
            template: templates/contract_draft.docx
            output_path: output/contract.docx
        

出力の後に検証の工程を入れる

生成が成功しても、中身が正しいとは限りません。出力の後に検証スクリプトを走らせ、合格したファイルだけを共有先に置きます。

検証結果は、生成日時・共通入力のハッシュ・設定の内容と一緒にJSONで残します。後述の「バージョン管理と差分追跡」で紹介するメタデータ出力と同じファイルにまとめると、どの入力から何が作られ、検証に通ったかを1か所で追えます。

形式ごとの詳しい手順は専門記事へ

定期実行の設計（cron・GitHub Actions）

パイプラインが動くようになったら、次は定期実行の仕組みを入れます。月次レポートや週次報告のように定期的に生成するドキュメントは、手動実行のままだと結局誰かが忘れます。

GitHub Actions で週次実行する場合の設定例です。Claude Code に「このパイプラインを毎週月曜9時に実行する GitHub Actions の workflow ファイルを作ってください」と指示すれば、YAML ファイルが生成されます。

# .github/workflows/doc-pipeline.yml の構成イメージ
        name: Weekly Document Generation
        on:
          schedule:
            - cron: '0 0 * * 1'  # 毎週月曜 UTC 0:00（JST 9:00）
          workflow_dispatch:       # 手動実行も可能

        jobs:
          generate:
            runs-on: ubuntu-latest
            steps:
              - uses: actions/checkout@v4
              - uses: actions/setup-python@v5
                with:
                  python-version: '3.11'
              - run: pip install -r requirements.txt
              - run: python main.py
              - uses: actions/upload-artifact@v4
                with:
                  name: generated-docs
                  path: output/
        

アクションのバージョンは例です。使う時点の最新版を各リポジトリで確認してください。

定期実行で重要なのは、失敗時の通知です。Slack や Teams への通知ステップを追加しておくと、生成が失敗したまま放置される事態を防げます。

バージョン管理と差分追跡

生成されたドキュメントをどう管理するかは、パイプラインの設計と同じくらい重要です。バイナリファイル（.pptx、.xlsx、.docx）は Git の差分表示が効かないため、工夫が必要です。

• Git で管理する場合：output ディレクトリを Git 管理に含め、生成のたびにコミットする。ファイルサイズが大きい場合は Git LFS を使う。差分は見えないが、いつ・誰が・どの設定で生成したかの履歴は残る。
• クラウドストレージで管理する場合：Google Drive や SharePoint にアップロードするステップをパイプラインに追加する。バージョン履歴はストレージ側の機能で管理できる。
• ハイブリッド方式：コードとテンプレートは Git、生成物はクラウドストレージ。実務ではこの形が最も多い。

Claude Code に「生成後に output フォルダの内容を Google Drive の指定フォルダにアップロードするスクリプトを追加してください」と指示すれば、Google Drive API を使ったアップロード処理も生成できます。

差分追跡をより正確に行いたい場合は、生成時のメタデータ（使用したデータソースのハッシュ、config の内容、生成日時）を JSON で出力しておく方法が有効です。バイナリファイルの中身は比較できなくても、入力が変わったかどうかはメタデータで判断できます。

本記事は2026年10月26日時点の公開情報に基づきます。コード例とディレクトリ構成は設計の考え方を示すもので、環境ごとの動作確認が必要です。GitHub Actionsのスケジュール実行の仕様はGitHub Docs: Events that trigger workflowsで確認できます。

よくある質問

全形式を同時に生成する必要がある？

ありません。config.yaml の enabled フラグで形式ごとにオン・オフを切り替えられる設計にしておけば、必要な形式だけを生成できます。全形式を同時に生成するのは月次の締めなど特定のタイミングだけで、普段は必要な形式だけ回すのが実務的です。

生成したファイルの数値が正しいかはどう確かめる？

出力ファイルから主要な数値を読み戻し、共通入力のJSONと比べる検証スクリプトを出力の後に走らせます。一致しない形式は共有を止め、差分をログに残します。テンプレートを変えたときと定期実行の初回は、人がファイルを開いて見た目も確認します。

エラー時のリカバリは？

パイプラインは形式ごとに独立して実行する設計にしておくと、1つの形式でエラーが出ても他の形式は生成が続行されます。エラーが出た形式だけを再実行するオプション（例：python main.py --only pptx）を用意しておくと、リカバリが速くなります。データ取得の段階でエラーが出た場合は全形式に影響するため、取得データをローカルにキャッシュする設計も検討に値します。

非エンジニアでも運用できる？

パイプラインの初期構築にはエンジニアが必要ですが、運用フェーズでは非エンジニアでも回せる設計が目標です。具体的には、データの更新は CSV やスプレッドシートで行い、テンプレートの修正は PowerPoint・Excel・Word の GUI で行い、実行はボタン1つ（GitHub Actions の手動トリガーなど）にする。この3点が実現できていれば、日常の運用にコード変更は不要です。

PDF出力も同じパイプラインで回せる？

回せます。出力レイヤーに PDF 用の renderer を追加すれば、同じ中間データから PDF も生成できます。Python では ReportLab や WeasyPrint などのライブラリが使えます。PDF レポートの具体的な実装は Claude CodeでPDFレポートを自動化する方法 で詳しく解説しています。