AIで定例レポートを作る方法｜データ収集から文章化まで

週次・月次レポートをAIで自動化するときは、毎回AIに数字を読ませるだけでなく、「同じ情報源から同じ指標を集め、差分を計算し、その結果だけ文章化する」構造にすると安定します。

AIが得意なのは説明文のdraftや要点整理であり、集計ロジック自体はできるだけ固定します。

先に結論：定例レポートは「計算」と「解釈」を分離する

データ取得

→ KPI計算

→ 前回との差分

→ AIで解釈候補

→ 人が確認

→ 配信

週次・月次で共通する土台はこの流れです。短期変化を見る週次と、中期傾向を見る月次では役割を分け、この記事では定例レポート全体の設計を扱います。

入力と判断材料をそろえる

レポートのKPIを固定する

売上、CV、問い合わせ件数、進捗率など、毎回見る指標を決めます。

KPI定義が変わると前週比較が成立しないため、算出式と対象期間も固定します。

Data Sourceを決める

Google Sheets、CSV、GA4 export、CRMなど、どの情報源を正本にするか決めます。

複数情報源を統合する場合は、同じmetric名でも定義が違わないか確認します。

集計を先に行う

前週比、目標差、上位項目、異常値などは、できるだけformulaやcodeで計算してからAIへ渡します。

AIへraw データ全体から数字を推測させない設計にします。

AIで整理する

AIには「解釈候補」を作らせる

ChatGPTのファイル uploadsではspreadsheet分析、synthesis、要約などができます。

ただし「売上減の原因」のような因果はデータだけで確定できないことがあります。事実と仮説を分けます。

出力Formatを固定する

サマリー、KPI、変化、要因候補、次アクションのようにsectionを固定します。

同じ構造にすることで、前回との差を読みやすくします。

Scheduleで定例化する

n8nのSchedule Triggerなどを使えば、週次・月次でワークフローを開始し、データ取得→集計→AI draft→保存へつなげられます。

運用へつなぐ

数字と文章を別々に検証する

KPI数値は情報源と照合し、文章は「数字から言える範囲」を超えていないか確認します。

最終配信は段階的に自動化する

最初はdraft生成まで、次に社内共有、最後に自動配信と段階を分けます。

誤った数字が自動送信されるriskを下げます。

レポート設計を作業単位に分ける

表は横にスクロールできます

段階	入力	固定する処理	AIへ渡すもの	人が確認すること
1. 取得	指標名、対象期間、取得元	同じ時刻・同じ条件で取得	取得結果と取得日時	欠損、更新遅延
2. 集計	元データ	KPI定義に従い計算	計算済み値のみ	元表との一致
3. 比較	今週、前週、目標	差分と比率を計算	差分、分母、比較期間	期間ずれ、母数の変化
4. 説明案	確認済み数値とメモ	事実と仮説を別欄で出力	根拠を結び付けた入力	因果の言い過ぎ
5. 配信	承認済み原稿	draft保存から開始	文章案	宛先、機密、最終数値

最初に決めるのは「何を毎回知らせるか」です。KPI名だけでなく、計算式、対象期間、除外条件、単位、更新時刻を定義書にまとめます。例えば「問い合わせ数」は、重複送信やテスト送信を含めるかで値が変わります。定義を変えた場合は変更日を明記し、旧定義の値と単純比較しません。

指標の差分を再現できる形にする

AIへ渡す前のデータは、1行1指標・1期間の形にそろえると点検しやすくなります。最低限、次の列を持たせます。

表は横にスクロールできます

period_start	period_end	metric_key	value	unit	source	extracted_at	definition_version
例: 2026-10-01	2026-10-07	qualified_leads	42	件	CRM集計	取得時刻	v1

上の数値は形式を示す架空例で、実績ではありません。前週比を作るときは、期間の長さ、曜日構成、タイムゾーンが一致しているかを確認します。値が0のときは「0件」と「未取得」を区別し、空欄をゼロとして扱わないようにします。割合を出す場合は分子と分母も保存し、分母が小さい指標を大きな変化と断定しないようにします。

AIに渡す入力例は、次のように「事実」「比較」「背景メモ」を分離します。

対象期間: 2026-10-01〜2026-10-07（Asia/Tokyo）

指標: qualified_leads

今週: 42件 / 前週: 38件 / 差: +4件（+10.5%）

取得元: CRM集計表 / 取得時刻: 2026-10-08 09:00

背景メモ: 今週から一部フォームの項目を変更

指示: 数値を再計算せず、事実と要因仮説を分けて文章案を作る。

この例から言える事実は「対象指標が4件増えた」です。フォーム変更が増加の原因だとは、比較だけでは断定できません。追加分析や担当者確認がない限り「背景として関連する可能性」と表現します。

文章化の出力契約とプロンプト

毎回自由形式で書かせず、出力項目を固定します。例えば要約、確認できた変化、原因候補、未確認事項、次の確認作業を分けます。

あなたは定例レポートの編集補助です。集計値の再計算はしません。

入力内の数値と期間をそのまま使い、次の項目に分けてください。

summary: 2文以内

facts: 入力値で直接確認できる変化

hypotheses: 背景メモに基づく仮説。根拠のない因果は追加しない

unknowns: 判断に必要だが入力にない情報

next_checks: 担当者が確認できる作業

入力にない数値・原因は「不明」としてください。

JSON等の機械処理が必要なら、必須キー、型、空欄の扱いを別途検証します。人が読む運用なら見出しを固定するだけでも、事実と仮説の混線に気付きやすくなります。ChatGPTのWriting Blocksは画面上の文章編集UIであり、定刻起動やデータ取得を実行するワークフロー機能として扱わないでください。自動化を組む場合はSchedule Trigger等、実際の実行基盤と接続先を別に用意します。

失敗時の分岐を先に決める

表は横にスクロールできます

症状	自動処理を止める条件	次の作業
取得元が応答しない	必須指標が欠落	前回値で埋めず、取得失敗を通知
指標定義が変わった	definition_versionが不一致	旧期間との比較を止める
数値が不自然	しきい値超過、単位違い	元データと計算式を再確認
生成文に未入力の数値がある	出力値と入力値が一致しない	配信せず、原稿を差し戻す
予定時刻に動かない	workflow未公開、時刻設定不一致	公開状態とtimezoneを確認

定期実行では、実行時刻のタイムゾーンを明示します。n8n Schedule Triggerはworkflowまたはinstanceのtimezone設定に依存し、scheduleを使うworkflowは保存・公開が必要です。月末や祝日を含む場合は、次回実行時刻を確認してから配信へ進みます。

小さく試し、承認境界を残す

初回からメールや社外チャネルへ自動送信せず、テストデータで生成したdraftを担当者が読む運用にします。正常系、データ欠損、ゼロ件、取得失敗、定義変更、生成文の数値不一致を試し、各ケースで「継続するか」「誰へ通知するか」「前回値を使わないか」を明記します。

合格の目安は、同じ入力から同じ集計値が得られ、入力にない数値が本文に現れず、未確認の原因が仮説として示され、担当者が送信前に出典へ戻れることです。数字の検算は元データとの照合で、文章の自然さとは別に確認します。

定例化前チェックリスト

• KPIの計算式・単位・期間・除外条件が定義されている

• 取得元と正本が決まり、取得時刻を残す

• 欠損値と0を区別している

• 比較期間・timezone・分母がそろっている

• AI出力で事実・仮説・不明・次の確認を分けている

• 異常値や取得失敗時に配信を止める条件がある

• テスト用宛先またはdraft保存で確認している

• 人の承認前に外部配信されない

配信前の確認項目

ChatGPT Free tierではファイルやデータ分析等を利用できる一方、機能ごとの利用上限が別に設定されることがあります。定例処理にChatGPT画面を使う場合は、毎週の実行回数や入力形式が現在の制限内に収まるかを試し、安定した自動実行が必要ならAPIやworkflowの契約・費用・認証を別途確認します。画面上の文章編集機能を、スケジュール起動や外部データ取得の機能として扱わないでください。

AIものさしの判断

定例レポート自動化では、AIに集計も文章化も全部任せるより、「計算は固定、説明はAI」という役割分担が扱いやすいです。

情報源→aggregate→compare→AI narrative→fact check→publishという順にすると、定例業務を再現しやすくなります。

AIものさしでは、毎週文章が生成されたことではなく、同じ定義のKPIが正しく集計され、変化と仮説が区別されたレポートになった状態をこのワークフローの完了条件にします。