AIで週次レポートを自動作成する方法｜集計から文章化まで

週次レポートをAIで自動化するときは、最初から「毎週いい感じにまとめて送って」と任せない方が安全です。先に、同じ期間・同じ定義でKPIを集計する工程と、差分を文章へ変える工程を分けます。そのうえで、欠損や異常値があれば配信を止めるGateを入れます。

週次は変化が早いぶん、未確定値や一時的なノイズも入りやすいレポートです。この記事では、架空のWebマーケ週報を例に、データ取得、KPI集計、前週差分、AI要約、人の確認、定期実行までを一つの流れにします。読後には、自社の週次レポートを半自動化するためのInput / OutputとQA条件を作れる状態を目指します。

自動化する前に「週次レポートの契約」を固定する

最初に決めるのはツールではなく、毎週変わってはいけない条件です。週の開始・終了、timezone、データ確定時刻、KPIの定義、対象filter、配信先、Ownerを1枚にまとめます。

たとえば「月曜0:00〜日曜23:59、JST、翌月曜9:00時点で取得、社内traffic除外、問い合わせは完了画面到達で計上」のようにします。ここが曖昧だと、AIが毎週同じ文章を作れても、比較する数字自体がそろいません。

最低限のReport Contractは、report_id、period_start、period_end、timezone、data_cutoff、metric_definition_version、filters、owner、destinationです。KPI定義を途中で変えた場合はversionを残し、前週との単純比較を止める判断ができるようにします。

Pipelineは「取得→検算→要約→配信」に分ける

おすすめの流れは、Data取得 → KPI集計 → 前週差分 → Data Quality確認 → AI要約 → 人のReview → 配信です。

ここで重要なのは、AI要約を最後の方に置くことです。取得直後の生データをそのままAIへ渡して集計・解釈・文章化を一度にさせると、どこで数字がずれたのか追いにくくなります。まず計算済みのChange Tableを作り、その表が正しいことを確認してから文章化します。

架空例：Change Tableを先に作る

説明用の架空データです。今週と前週を同じ定義で集計したとします。

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

KPI	今週	前週	差分	増減率 / pt	状態
Organic Sessions	2,400	2,100	+300	+14.3%	CONFIRMED
問い合わせ	48	50	-2	-4.0%	CONFIRMED
CVR	2.0%	2.38%	-0.38pt	—	CONFIRMED
売上	1,180,000円	1,050,000円	+130,000円	+12.4%	PROVISIONAL

この表なら、「流入は増えたが問い合わせは減り、CVRが低下した」という変化はFactとして確認できます。一方、「流入の質が悪化した」はまだ仮説です。売上がPROVISIONALなら、AIの要約内でも確定値と同じ強さで扱いません。

差分の計算ルールを固定する

件数や金額は差額と増減率、率そのものはpercentage point差を使うと混乱しにくくなります。たとえばCVRが2.38%から2.0%へ下がった場合、単純差は-0.38ptです。何を%で、何をptで出すかをReport Contractへ入れておきます。

前週が0の場合、増減率は通常の割り算では扱えません。0除算を0%として埋めるのではなく、N/AやNEWとして扱います。母数が極端に小さい指標も同様で、率の変化だけを強調しないようにします。

文章化の前にData Quality Gateを通す

週次はスピードが重要ですが、異常値をそのまま配信する方がコストが高くなります。次の条件に該当したらAI要約を保留するGateを作ります。

1. 必須KPIが欠損している。

2. 前週まで存在した値が突然0になった。

3. tracking変更や障害が発生している。

4. 期間が7日そろっていない。

5. timezoneやfilterが前週と違う。

6. 前週値と元Dashboard値が一致しない。

7. 未確定値が意思決定に使われる可能性がある。

Gateは「異常値を削除する仕組み」ではありません。異常が本当の変化なのか、計測事故なのかを分けるための停止条件です。異常を検知したらstatusをHOLDにし、配信ではなく確認Queueへ回します。

AIにはFact・Hypothesis・Unknown・Actionを分けて出させる

Change Tableが確定した後で、AIへ文章化を依頼します。

依頼例：

以下は検算済みの週次KPI表です。週次レポートを作成してください。

出力：

1. 今週のFact：重要な変化を3件以内

2. 前週との差

3. Hypothesis：原因候補。Factと混ぜない

4. Unknown：追加で必要なデータ

5. Action：誰が何を確認するか

ルール：

• 入力にない原因を断定しない

• PROVISIONALは未確定と明記

• 変化が小さいKPIは本文で無理に説明しない

• 率は母数とセットで扱う

• 週の期間とdata cutoffを冒頭に書く

こうすると、AIの役割は原因を決めることではなく、検算済みの差分を読みやすい形へ整理することになります。

完成例：短い週報でも判断材料を残す

先ほどの架空データなら、本文は次のようにできます。

「今週はOrganic Sessionsが2,400で前週比+14.3%でした。一方、問い合わせは48件で-4.0%、CVRは2.0%で-0.38ptです。流入増が問い合わせ増につながっていないことは確認できますが、流入品質の変化は未確認です。Landing Page別CVRと主要Queryの流入構成を確認します。売上1,180,000円は集計途中のため参考値として扱います。」

この文章なら、Factと仮説が混ざらず、次に見る場所まで分かります。週報は長い説明より、変化→未確認→Actionの流れが重要です。

ActionはOwnerと期限を持たせる

「CVRを改善する」では週報のActionになりません。たとえば「Web担当が月曜15時までにLanding Page別CVRを前週比較」「マーケ担当が火曜午前までにOrganic Query構成を確認」のように、Owner、期限、完了条件を置きます。

原因が分からない段階では、施策実行より調査Actionにします。確認前に「LPを変更する」「広告を止める」と決めると、週次のノイズへ反応しすぎる可能性があります。

定期実行は最初から完全自動にしない

初期は、集計と文章生成まで自動化しても、配信前のApprovalを残します。3〜4回程度の運用で、期間ずれ、欠損、誤った強調、同じ異常の繰り返しなどがないかを確認します。

安定したら、Data Quality Gateを通過した週だけ自動配信し、HOLD時は担当者へ確認依頼を送る設計にできます。自動化の成熟度は、Manual Review → Assisted Publish → Conditional Auto Publishのように段階を分けると管理しやすくなります。

再実行できるように入力と出力を記録する

自動化すると、あとから「なぜこの文章になったのか」を追えることが重要になります。少なくとも対象期間、入力したKPI表、生成時刻、使用したPrompt version、出力、Review結果、最終配信版を紐づけます。

数値が後から訂正された場合は、同じreport_idでrevisionを残します。前の週報を上書きして消すより、「どのデータで何を配信したか」が分かる方が、誤配信の原因調査や再発防止に使えます。完全な監査基盤まで作らなくても、Spreadsheetなどでrun logを持つだけで運用しやすくなります。

週次と月次は同じ内容にしない

週次では早く気づくこと、月次では締め後に大きな傾向を判断することが中心です。週次に前週差、異常、直近Actionを置き、月次では目標差や構造的な傾向を扱います。

同じKPIを使っても、週次で小さな上下を毎回原因説明する必要はありません。週次は「変化を検知するレーダー」として使い、継続している傾向は月次で判断する、と役割を分けます。

自動化前の最終チェック

定期実行をONにする前に、次を確認します。

• 同じ期間とtimezoneで再現できる

• KPI計算式が固定されている

• 元Dashboardとspot check済み

• 欠損・0・異常値でHOLDできる

• FactとHypothesisが別section

• 未確定値にflagが付く

• ActionにOwnerがある

• 配信先を誤らない

• 手動で再実行できる

• 配信後に元データへ戻れる

このチェックを通せないうちは、生成品質より運用設計を直した方が安全です。特に最初の数回は、短縮できた作業時間より「同じ条件で再現できたか」を優先すると、その後の自動化が安定します。判断基準も毎週同じにします。

AIものさしの判断

週次レポートの自動化は、文章生成の自動化ではありません。中心は「同じデータ → 同じ計算 → 同じQuality Gate → 変化だけ文章化」という再現可能なPipelineです。

まず1本の週報を手動で作り、Report ContractとChange Tableを固定してください。次にAI要約を追加し、3〜4回は人が検算する。問題がなければ定期実行へ進み、異常時だけHOLDする。ここまで作れば、週報作成の手間を減らしながら、数字の誤りをそのまま自動配信するリスクも抑えられます。

定期実行へ移した後も、月に一度はKPI定義、配信先、HOLD条件、前週比較の計算が変わっていないかを見直します。自動化は一度作って終わりではなく、比較条件を維持できていることまで含めて運用します。