Claude Codeで”定例レポート”を仕組み化する｜データ取得から生成まで一気通貫（実践編④）

毎月、あるいは四半期ごとに回ってくる定例レポート。同じデータソースから、同じ集計を、同じ体裁で。数字だけを最新にして——。これほどClaude Codeの”使いこなし”が効く場所は、なかなかありません。逆に言えば、一度きりの分析やアドホックな調べ物は、その都度対話でお願いした方が速いことも多い。定例が特別なのは、「同じ判断を、毎回ブレずに再現すること」そのものが価値だからです。

ただ、正直にお伝えすると、これは「プロンプト一発で資料が完成する魔法」ではありません。実際に効くのは、データ取得から集計、体裁込みの生成までを”一気通貫のスキル”に仕組み化すること。そして、その一本道の中で決定的な処理はコードに、判断はAIに、要所は人に——と責務をきっぱり分けることです。この記事を通してお伝えしたいのは、突き詰めればこの一点に尽きます。毎月ブレないのは、賢い一発の呪文があるからではなく、”誰が何を担うか”を分けてあるから。以下では、その仕組みの形を、具体的な設計判断まで踏み込んで共有します（登場するサンプルはすべて匿名化した合成データで、実在の案件・数値ではありません）。

なぜ”定例”こそ、Claude Codeの効きどころなのか

定例資料には、繰り返される・フォーマットが固定されている・データソースが決まっている、という3つの条件が揃っています。自動化にとっては、これ以上ないほど理想的な地形です。一度仕組みを作ってしまえば、あとは毎回”実行”するだけ。「あの人にしか作れない」と属人化しがちな定型業務を、誰が回しても同じ品質に均せます。

ここで一つ、先に割り切っておきたいことがあります。仕組み化の投資が報われるのは、必ず”2回目以降”だということです。初回は、方針を書き出し、取り方を参照集にまとめ、集計をコードに落とす——それなりの手間がかかります。単発の資料なら、対話でその場で作った方が早いくらいでしょう。けれど定例は、年に4回、12回と繰り返す。最初に型を組む一度きりの労力を、以後のすべての実行で回収していく。だからこそ、「毎回ゼロから作り直している定型資料」ほど、仕組み化の効果は大きく出ます。裏を返せば、二度と作らない資料を無理に仕組み化するのは、割に合いません。着手前に、この見極めをしておくことが最初の分岐点になります。

単発は対話で。繰り返すものは、仕組みで。

全体像：1コマンドで”取得→集計→生成”を完走する

まずは、出来上がりの姿から見てもらいます。定例レポートを、1つのスキルにまとめてしまう。呼び出すと、次の一連を最後まで走り切ります。

案件の方針を読み、各データソースに接続し、対象期間を自動で確定し、複数ソースからデータを取得する。それを整形・正規化し、入力を検証（fail-fast）してから、多段の集計にかけ、レポートを生成し、最後に状態を保存する。「今月分を作って」の一言で、ここまで通します。途中でデータの不整合を見つけたら、集計に進む前に、そこで止まる。壊れた数字を、そのまま資料に載せないためです。

ただ、ここで本当に見てほしいのは、”1コマンドで動くこと”そのものではありません。大事なのは、この一本道のどのステップを、コード・AI・人の誰が担うのかを、最初にすべて決めてあることです。同じ「1コマンド」でも、裏側の責務が曖昧なままだと、月をまたぐたびにどこかがズレていく。逆に、担当さえ明確なら、この道は毎月同じように走ります。次の章からは、一本道の中身を順に開いて、どこを誰に任せているのかを見ていきます。

設計の起点：方針と対象期間を”先に”固定する

案件ごとの”方針”を、まず読ませる

こんな失敗があります。「先月と同じKPIで」と頼んだのに、出てきた資料はセッション基準。前回はユーザー基準だった——。数字は一見それらしく、指摘されるまで誰も気づかない。この手のズレは、実行時のAIの気まぐれではなく、”定義が決まっていないこと”から生まれます。言い換えれば、設計の穴が、毎月同じ場所から水を漏らしているだけなのです。

だからスキルには、まず案件ごとの方針書（CLAUDE.md）を最初に読ませます。ここに何を書くかで、出力の一貫性はほぼ決まります。やっているのは要するに、”毎回ブレてはいけないこと”を、実行前に一箇所へ固定しておく作業です。核になるのは、追うKPIの定義——何を分子・分母に、どの期間粒度で、どの条件を除外して数えるか、そこまで書き切る。”セッション”と”ユーザー”のどちらを見るのか、新規かリピートか、といった取り違えは、この定義が甘いと毎回起きます。目安として、1行で定義し切れないKPIは、まだ設計が済んでいないと考えた方が安全です。あわせて、対象範囲——どのアカウント・商品群・セグメントを見るか、”含めるもの”だけでなく”除外するもの”まで——を明記し、体裁ルール（スライドの枚数と順番、単位、丸めの桁、強調の基準）と、禁止事項（顧客名を出さない、推測を断定で書かない、といったコンプラ上の制約）も、同じ場所にそろえておきます。

この方針書は、”出し分け”の場面でも効いてきます。社外に出す版は匿名化や表現の丸めが要り、社内版では生の内訳まで見たい。この違いを方針書に分けて書いておけば、同じ集計から、2つの体裁を出し分けられる。では、なぜ毎回”最初に”読ませるのか。答えは、担当が変わっても、同じ観点・同じ定義で出させるためです。判断の揺れは、実行時にではなく、設計時につぶしておく。方針書は、その”揺れを固定しておく場所”にほかなりません。ここが薄いまま自動化に進むと、出力は毎回それらしく見えるのに、月ごとに定義が微妙にずれた資料が積み上がる——という一番やっかいな失敗に陥ります。

対象期間は、手で打たず”自動”で決める

地味ですが、これが効きます。「6月分を作って」と毎回打ち込む運用は、月をまたぐたびにズレる・重複する・抜ける、の温床です。ある月、うっかり前月と範囲が1日重なれば、その1日はまるごと二重計上される。人が期間を指定している限り、この種のミスは、確率的にいつか必ず起きます。

そこで、「前回どこまで出したか」を状態として記録しておき、その翌日から最新の取得可能日までを、自動で範囲にする。こうすると”何月分か”すら指定する必要がなくなり、抜け・重複が構造的に起きません。ここでやっていることも、根っこは同じです。決定的に決まる処理（期間の計算）を、人の手から外してコードに預ける。それだけで、人的ミスの入り込む隙が一つ消えます。

ただし、一つ見落としやすい罠があります。ソースごとに”最新確定日”がずれるのです。広告系はほぼ即日で数字が固まりますが、検索やアクセス解析は数日遅れて確定する。全ソースを一律「昨日まで」で切ると、遅延のあるソースだけ末尾が歯抜けになります。だから、「どこまでを確定として扱うか」（締め日）を方針に書き、その遅延を織り込んだ期間で取りにいく。期間の自動化は、単なる日付の引き算ではなく、データが成熟するのを待つ設計でもあるわけです。

データは”取り方”ごと、参照集に固定する

先月まで問題なく動いていた取得が、今月は空のファイルを返す。調べてみると、管理画面の列名が一つ変わっていた——。定例運用をしていれば、必ず一度は出会う場面です。ここで学ぶべきは「だからAIは不安定だ」ではありません。変わるのはいつも”外側”（各ソースの画面や仕様）であって、変わってほしくないのは”本体”（集計ロジック）だ、ということです。この二つを、そもそも別の場所に置いておく。

具体的には、各ソースの“取り方・整形の手順”を、本体のスキルから切り出して、参照ドキュメントに固定します。取りにいく操作はAI、落ちてきたファイルの正規化・結合はコード。画面や仕様が変わっても、参照集の該当箇所だけを直せば、全体がそれに追従する。取り方を本体スキルに埋め込んでしまうと、変更のたびに本体を触ることになり、かえって壊れやすくなります。外側の変化を、一枚の”緩衝材”で受け止める作りにしておくわけです。

取得経路は、画面を自動操作してダウンロードする道と、API／MCPで直接引く道の二択を持っておくと強い。APIで取れるソースはそちらへ寄せれば無人化でき、画面の仕様変更にも振り回されにくくなります。落ちてきた旧ファイルは自動で退避しておけば、上書き事故も防げます。ただ、この二経路には落とし穴もある。画面のダウンロードとAPIとで、同じ指標なのに数字が微妙に食い違うことがあるのです。多くは、集計軸・期間境界・重複除去の定義差が原因です。だから導入時に必ず両経路を突き合わせ、どちらを”正”とするかを決め、差が出たら原因まで遡って参照集に書いておく。この一手間を最初に済ませておけば、あとで「先月と数字が合わない」と青くなる場面を、まるごと減らせます。

参照集に書き残すのは、手順だけではありません。むしろ各ソースの”クセ”にこそ価値があります。同じ「クリック」でも重複除去の有無で数え方が違う、タイムゾーンの基準、サンプリングやしきい値による丸め、一度に指定できる期間の上限——。こうした前提を言葉にしておかないと、担当が変わった瞬間、同じ指標名なのに数字の意味がずれてしまう。そしてデータソースの仕様変更（列名の変更、指標の廃止、画面改変）は、いつか必ず起きるという前提に立って、”取り方”を一つの資産として更新し続ける。この地道さを面倒がらないことが、再現性の本体です。

責務分担：コード・AI・人を、どう線引きするか

決定的な処理はコード、揺れる処理だけをAIに

ここが、この記事の核心です。定例自動化の成否は、突き詰めると、再現性が要る処理をコードに、揺れを許せる処理だけをAIに——この振り分けができているかどうかで決まります。

なぜ、こう分けるのか。理由は一つ、コードは「同じ入力なら、同じ出力」を約束するからです。集計、期間の決定、ファイルの整形、丸め——これらは毎月一字一句同じであってほしい処理です。ここをAIに任せると、桁の解釈や端数処理が、月ごとにわずかにブレる。毎月、電卓で暗算をやり直してもらうようなもので、たいていは合っているのに、時々ずれる。そして配布物では、その”時々”が信用に響きます。一方、ログイン画面の小さな変化を吸収する、エラーの文脈を読んで人に説明する、数字の動きに所見をつける——こうした“揺れ”を含んだ仕事こそ、むしろAIの独壇場です。

もう少し具体で言えば、こうです。「前月比の増減率」や「セグメント別の構成比」という数字はコードが出し、「その増減が、いったい何によって起きたのか」という仮説はAIが下書きして、人が確認する。この一線を、設計の段階で引いておく。取り違えると、すぐに事故ります。集計をAIに”読んで足して”もらえば、どこかで桁を間違える。逆に、所見までコードでテンプレ生成すれば、毎回まったく同じ空虚な一文が並ぶ。「決めきれる所」と「意味を汲む所」の境界を見極め、さらにその境界のどこに人の確認を挟むかまで決める——それが、責務分担という設計です。

集計は”多段”に分け、成果物は2種類そろえる

「サマリの数字までは、全部正しい。直したいのは、最後のスライドの色分けだけ」——なのに、集計を一発で回す作りだと、取得やログインから丸ごとやり直す羽目になる。定例資料は細かい手直しが何度も入るものなので、この”やり直しコスト”は、積み重なると馬鹿になりません。

だから集計は一発で回さず、取り込み → 統合 → サマリ → ピボット → 出力と多段に分けます。各段を独立させ、中間生成物を保存しておくと、どこで何がおかしくなったかを切り分けられ、その段だけを作り直せる。さきほどの「色分けだけ直したい」なら、統合済みの中間データが残っているのだから、出力段だけを回し直せばいい。取得からやり直す必要はありません。これも要は、処理を分けておくから、壊れた一箇所だけを差し替えられるという、同じ思想の延長です。

成果物は、2つそろえます。そのまま配れるスライド（体裁込み）と、根拠を追える補完のExcel。見せる資料と裏取り用のデータが同時に出るので、レビューが速い。しかも、スライド上の数字からExcelの該当セルまで集計キーでたどれるようにそろえておけば、「この数字の根拠は？」と問われても、その場で答えられます。

壊れたら止まる、途中から再開できる

5つ取るはずのファイルが、4つしか落ちてこなかった。それでも処理が黙って先へ進めば、末尾が歯抜けのレポートが、何食わぬ顔で完成してしまう——。定例運用で一番こわいのは、この”静かに間違ったまま完走する”パターンです。

防ぎ方は、入力を先に検証する（fail-fast）こと。必要なファイルの有無、シート構成、必須列の欠けを最初にチェックし、一つでも欠けていたら、集計に進む前に止めて、原因を人に返す。おかしなデータを黙って通さない——これが、配布物の品質を守る一番の近道です。止まるべき所で、ちゃんと止まるのは、機能の不足ではなく、設計の一部だと考えます。あわせて、処理は冪等に組みます。同じ入力なら、何度回しても同じ結果。そして途中のステップで失敗しても、最初からではなく“失敗した所から”再開できるよう、実行状態を保存しておく。長い処理の終盤で落ちるたびに全部やり直し、では、現実の運用には乗りません。壊れたら止め、直したら続きから——この二つがあって初めて、本番の配布物を、壊れたまま先へ進めない安全弁になります。

人が握る”要所”と、判断の記録

「全自動ではない」と、正直に

ここまで自動化の話をしておいて、最後に水を差すようですが——これは全自動ではありません。いや、正確には、全自動にしないことを、あえて選んでいます。人が確認する要所を、意図して残してある。対象期間の合意、未分類データの振り分け、主要な数字の検算、そして公開前の最終目視。生成という”作業”はスキルが担い、判断と最終責任という”重さ”は人が握る。社外に出る資料は、たった一つの誤記が信用に響くからです。

検算といっても、大げさなことはしません。主要なKPIだけ、別の経路で1つ2つ、手計算と突き合わせる。内訳の合計が総計と合っているか、前月と定義がそろっているか、増減の符号が逆になっていないか（増えたはずが減少と出ていないか）。公開前には、匿名化の漏れ・単位・桁区切りを目で追う。ここを省かないからこそ、自動化された残りの部分を、安心して信頼できる。全部を自動にしようと欲張るより、「人が最後に握る一点」をはっきり残す方が、結果として速く、そして安全に回ります。

下した判断を記録し、次回の起点にする

回すたびに、必ず何かしらの判断が要ります。「今回は季節要因を除外した」「この異常値は注記にとどめた」「未分類はこのルールで振り分けた」——。こうした判断を、そのつど記録していきます。

これが効いてくるのは、次回、同じ判断をそのまま再現できるから。そして「なぜこの数字になったのか」を、後からたどれるからです。担当が交代しても、判断の履歴が、そのまま引き継ぎ資料になります。実行状態も保存されているので、次回はそこが起点になる。回すほどに、前提と判断が積み上がっていく——ここが、単発の集計との決定的な違いです。ログは、消えていく作業の記録ではなく、積み上がっていく資産に変わる。責務を分けて組んだ仕組みは、こうして回すたびに”育って”いくわけです。

実物でハマった工夫と、越えるべき落とし穴

細かいが、確かに効く”工夫”

きれいに回っているように見える仕組みの裏には、たいてい泥臭い工夫がいくつも積もっています。実際にぶつかって、参照集に言語化して残したもの——いずれも匿名化した”あるある”です。並べると細かいのですが、どれも「一度ハマって、二度とハマらないために言葉にした」ものばかりです。

たとえば、制御用のブラウザには、会議ツールやデザインツールのような重いタブを同居させない。同居させると通信が詰まり、データ取得が丸ごと失敗することがあるからです。ブラウザは”制御専用”に軽く保っておく。複数アカウントを扱うときは、プロファイルを分けて並行させ、操作の前に必ず画面のアカウント表示で”どれを触っているか”を確かめてから手を動かす——取り違えが、一番こわいからです。また、一部のサービスは自動ログインが弾かれます。そこは無理に突破しようとせず、”手動ログイン済みのブラウザを使う例外”として、手順にはっきり書いておく。無理をしないという判断を、あらかじめ手順に織り込んでしまうわけです。

データそのものにも、同じ姿勢で臨みます。取り込んだ中に“未分類”が出たら、機械に勝手に埋めさせず、人に振り分けてもらう。判断が要る所は人に返す、という原則を、こんな細部でも崩さない。逆に、表のヘッダに紛れ込んだ末尾の空白や、月表記のゆらぎ（”7月”と”2026-07″が混在する類）は、集計側のコードで自動的にそろえてしまう。人が判断すべきものは人へ、機械的にそろえられるものはコードへ——ここでも、切り分けの原則は、まったく変わりません。こうした”ハマりどころ”を一つずつ言語化して残すからこそ、次は同じ所で止まらずに済む。仕組みの本当の価値は、この積み重ねの中にあります。

越えるべき、3つの落とし穴

最後に、定例自動化でつまずきやすい3点を、対策とセットで確かめておきます。いずれも、この記事で触れてきたことの裏返しです。

一つ目は、「全自動」の幻想。取得も集計も自動化できますが、検算と公開前の確認まで手放してしまうと、間違いが起きたとき、誰も気づけません。自動化するのは”作業”であって、”責任”ではない——この線を引けるかどうかが、安全設計の分かれ目です。二つ目は、データソースの仕様変更。UIも指標名も、いつか必ず変わります。だからこそ取り方を参照集に切り出し、変わる前提で監視し、更新し続けることを、あらかじめ運用に織り込んでおく。三つ目は、体裁の、静かな崩れです。ヘッダの空白、月表記のゆらぎ、桁区切りや単位の不一致は、派手なエラーを出さないまま、数字の見え方を狂わせる。だから整形はコード側でそろえ、前月のテンプレとの差分で崩れを検知する。厄介なのは、いつだって派手なエラーよりも、この静かなズレの方なのです。

使いこなしのコツと、まとめ

「今月分を作って」の一言で完走できるのは、その裏に、これだけの設計を仕込んであるからです。方針書で定義を固定し、対象期間を自動で確定し、取り方を参照集へ逃がし、コードとAIと人で責務を分け、fail-fastと再開で”壊れ方”まで設計し、人のチェックポイントを残し、下した判断を記録する。この設計を組み切ること自体が、”使いこなし”の本体です。とはいえ、いきなり全部を組もうとする必要はありません。まず一つの定例を選び、”型”から作る。1本が回り始めれば、2本目からは参照集も判断の型も、そのまま流用できます。

定例レポートの自動化は、魔法ではなく規律です。

データ取得から生成までを一気通貫のスキルにまとめ、決定的な所はコードに、判断はAIと人に分ける。この型さえ組めば、毎回同じ品質で、最新のデータの資料が出て、属人化もほどけていきます。派手さはありません。けれど、責務を分けてあるから、毎月ブレない——これが、”効く定例”の、地味だけれど確かな正体です。

——ただ、正直に申し上げれば、この規律をゼロから組み切るのは、それなりに骨が折れます。方針の設計、複数ソースの取得、責務の線引き、検証と再開、そしてセキュリティ（鍵は共有せず、各自の環境に置く）。「毎月のレポートに追われている」「仕組みは欲しいけれど、自前で組む余力はない」という段階であれば、設計から運用まで、まるごとお任せいただくという選び方もあります。

関連ガイド（実践編シリーズ）

• 1人マーケ運用：業務をスキルに部品化しGitHubで共有
• 実践編①：Claude Codeで自社のマーケ分析を回した全記録
• AI認証・データ連携のセキュリティレビュー

よくある質問（定例資料の自動化）