経営企画のAI活用｜散らばった数字を毎月1枚のレポートに畳むClaude Codeの手順
経営企画の業務を見渡すと、月次報告を仕上げるために費やす時間の配分は、決して合理的とはいえません。
本来なら数値の意味を読み解くことに力を注ぎたいのに、実際にはデータを探し出し、同じ形式へ整える作業が大半を占めます。広告画面の実績を転記し、営業台帳を月単位でまとめ、経理部門の確定を待ちながら、先月の資料と体裁をそろえる。準備だけで何日も過ぎ、変化の背景を考えて文章にできるのは締切直前、という職場は珍しくありません。
こうした苦労からAI導入が検討されます。しかし、検索結果で目につくのは分析基盤や可視化製品を比較する情報が中心です。そこへ進む以前に必要な、別々の場所にある表をつないで一つの報告書へ整える方法は、あまり解説されていません。
そこで本記事では、その前処理に焦点を絞ります。先に結論を示すと、守るべき原則はAIを数値集計の担当にしないことです。計算はプログラムで確定させ、AIには結果を説明する文章だけを任せます。この境界が、経営資料の信頼性を左右します。当社で日次または週次に稼働している3種類の仕組みを例に、設計の考え方から実装の流れまで紹介します。
製品に関する記述はClaude Code公式のセキュリティ資料を参照し、2026年8月27日時点で確認できた情報に基づいています。今後仕様が変わる可能性があるため、最新の内容については必ず公式情報をご確認ください。掲載した事例は当社または支援先での実務をもとにしていますが、取引先名・金額・件数の一部は非公開としています。なお、他社媒体が示す削減率や効果の数値は根拠として採用していません。
本記事から得られる知識
経営企画のAI活用が「ツール比較」になりやすい理由
経営企画とAIを扱う記事が、分析基盤や可視化サービスの比較に集中しがちなのには、いくつかの背景があります。
まず、現場の悩みが「見える化」という表現にまとめられやすいためです。状況が見えないのであれば、可視化する製品を導入しようと考えるのは、ごく自然な流れでしょう。
次に、比較対象となる製品がはっきりしているためです。料金表や機能の違いを並べられるので、記事として整理しやすくなります。
さらに、規模の大きな企業の導入例は紹介しやすいという事情もあります。専門部署と整備済みのデータ基盤を前提にした取り組みは、成果を分かりやすく見せられます。
一方、当社へ相談が寄せられる規模の組織では、出発地点がまったく異なります。基盤の整備以前に、必要な数値が5か所、6か所へ分散しているケースが普通です。広告サービス、営業台帳、会計ソフト、アクセス解析、さらに担当者の端末内に保存されたExcelまで確認しなければなりません。この段階で可視化製品を入れても、接続できるデータが整っていないため、最後は人が手作業で入力する運用に戻ります。
したがって、多くの企業が先に着手すべきなのは、可視化よりも手前の作業です。点在する表を横断し、毎月変わらない様式の一枚へまとめるという地道な仕組みを作る必要があります。そして、この準備工程こそAIの支援と相性がよい領域です。
検索上位の記事を読んで見つけた空白
本稿を書く前に、「経営企画 AI 活用 レポート 集計 データ 分析」という語句で検索し、上位に表示された記事を確認しました。
経営分析サービス会社の記事は、おおむね15,000〜16,000字でした。AIで実現できること、普及の背景、利用可能な製品、コピーして試せるプロンプト、導入手順、活用事例までを順に扱っており、十分な情報量があります。とりわけ、具体的なプロンプトは実務でも参考になる内容でした。
可視化製品の提供会社による記事は約4,500字で、AIデータ分析の代表的な使い方、経営面の利点、製品同士の組み合わせが主題でした。また、マーケティング支援会社の記事は11,000〜13,000字にわたり、市場分析、シナリオ設計、数値計画という3段階から、中期経営計画へAIを取り入れる方法を説明しています。大手金融グループの事例も取り上げた、内容の整った記事でした。
これら3本を通読したところ、共通して具体的な説明が不足していたのは、以下の4項目です。
- AIに数値を直接計算させず、プログラムで集計を確定し、AIには解説だけを担当させる役割設計
- 異なる表やサービスから得たデータを、一つの資料へ統合する作業手順（個々の製品の担当範囲は示されても、まとめ方までは説明されていません）
- 算出結果の誤りを発見するための確認方法（人が確認するという方針だけでなく、実際にどこを照合するかという方法）
- 定期配信が通知なく停止した場合に、それを検知できる設計
最初の記事では、出力内容を検証して意思決定へつなげる工程が示され、人による確認が必須だと説明されていました。その方針自体に異論はありません。ただし、数百行に及ぶ計算結果を目視で点検するという運用は、日常業務の中では続きません。現実に実行できない点検を定めても、確認済みとはいえないからです。ここからは、この問題を実務で解決する方法を掘り下げます。
毎月1枚が作れない、3つの本当の理由
月次レポートの負担が大きいのは、作業する人の能力や速さが原因ではありません。構造的な理由は、次の3種類に整理できます。
第1の理由は、必要な材料が各所に分散していることです。保存先によって取得方法が異なり、画面を見ながら転記する数値もあれば、ファイルとして出力するもの、別部署へ依頼して届くまで待つものもあります。この待機が後工程を圧迫し、期限間際に作業が集中します。
第2の理由は、入力される形式が月ごとに少しずつ変わることです。前月にはなかった列が追加される、組織名が更新される、商品区分が一つにまとめられる、といった変更が起こります。先月のファイルを複製して上書きする方式では、小さな差異が発見されないまま積み上がっていきます。
第3の理由は、担当者が計算結果を手作業で数え直していることです。この負担は表面に出にくいものです。集計済みの表が存在していても、不安なので人がもう一度数えたり、前月から大きく変わった箇所だけ電卓で確かめたりします。こうした確認方法は文書化されないことが多く、担当変更と同時に失われます。
AIは、この3要因のうち材料の収集と形式の統一には大きく貢献します。しかし、数を確定する仕事まで委ねるべきではありません。その理由を次章から説明します。
最重要の原則：数字はAIに集計させない
当社が報告業務を自動化するときの基本方針は、短い言葉で表せます。
プログラムが計算し、AIはその結果を文章にする。
役割をもう少し具体的に分解すると、次のようになります。
- AIには、集計処理そのものではなく「集計できる仕組みの作成」を依頼します。対象となる表や列、抽出条件、合算方法を指定し、それを実行する処理を書かせます
- 数値の算出は、完成したプログラムに担当させます。入力が同一であれば、実行する日時にかかわらず結果も同一になります
- 計算後にAIを使う場面は、確定値の動きを言葉で説明するときです。前月からの増減や、他と違う傾向を示す項目などを文章へ整理させます
このように工程を切り分ければ、報告書における数値と記述の責任範囲を明確にできます。計算が違えばプログラム側を修正し、解釈の表現が不適切なら文章だけを直せます。問題が起きた場所を特定しやすい設計です。
反対に、元の表をAIへ渡して一括で集計を頼むと、計算と説明が一つの生成工程に混ざります。その場合に生じる実務上の危険を、続いて見ていきましょう。
なぜ集計させてはいけないのか
直接集計を避ける理由は3点あり、いずれも経営資料では無視できない問題です。
第1に、同じ結果を再現できる保証がないことです。同一の表と質問を与えても、生成のたびに回答が一致するとは限りません。仮に合計の桁が一つずれていても、前後の説明が自然なら読む側が見落とす可能性があります。
第2に、誤りが生じた箇所を追跡しにくいことです。プログラムなら抽出条件や途中結果を順番に調べ、原因の範囲を狭められます。一方、文章の一部として提示された数値からは、計算の過程が見えません。その値へ至った理由を後からたどれないのです。
第3に、誤った値であっても違和感のない見た目になることです。ここが特に危険です。生成された数字は単位や桁、文脈に合わせてもっともらしく配置されます。見た目の不自然さを手がかりに誤りを発見するのは困難です。
この性質を持つ数字を経営会議へ提出することには、大きなリスクがあります。決裁や社外説明の根拠となった後で誤りが判明すれば、どの資料まで戻って修正すべきかという問題へ発展します。
そのため当社では、報告作業を自動化する際に、計算と文章生成を必ず別工程にします。集計専用のスクリプトを用意し、そのスクリプトが出力したファイルのみをAIへ入力します。元となった明細をAIに読ませることはありません。説明文を作る目的には、確定後の結果だけで足りるためです。
生成結果を業務で信用する範囲については、AIの出力をどこまで信じるか｜業務で使う前の検算手順と、別AIに見せる二重チェックの型で、検証の考え方をより詳しく説明しています。
1枚に畳むまでの5工程
ここからは、完成までの作業を5つの工程に分けて具体化します。
工程1では、材料を収集します。必要な数字がどこに保存されているかを一覧にし、保存先ごとに取得手段を決めます。この段階では、アクセス権限を読み取り専用に限定することが重要です。当社が解析サービスや検索管理画面から情報を取得するときも、閲覧だけが可能な鍵を発行します。書き込みが許可されていなければ、自動処理の不具合によって原本を変更する事故を防げます。
工程2では、データの形を統一します。各所から集めた表は、列の名称、日付表記、数値の単位がそろっていません。この差を吸収し、共通形式へ変換します。この処理を作る仕事はAIの得意分野です。たとえば、二つの表を月と部署で対応付ける処理を作るよう依頼すれば、変換のためのコードを用意できます。毎月起きる様式変更も、この変換段階で調整します。
工程3は、確定値を算出する段階です。一つ前の工程で用意した処理を動かし、プログラムに計算させます。人が手で数えることも、AIが回答として数えることもありません。
工程4では、数字の意味を文章へまとめます。AIへ渡すのは集計後のファイルに限り、変化を説明する文を作らせます。指示には、提示された数値を変更しないこと、そして根拠のない因果関係を断言しないことの2点を含めます。「広告施策が成功した」と結論付けるのではなく、「対象期間はこの経路の流入が増加した」と事実を記述させます。原因を判断する役割は人に残します。
工程5は、完成した資料を届けることです。所定の場所へ決めた時刻にレポートを出す処理は、自動化に適しています。ただし、配信が止まった事実を検知できる仕掛けも同時に用意してください。具体策は後半の章で説明します。
実装例1：週次の検索流入レポート
最初に紹介するのは、当社へ毎週月曜日の朝に届く検索流入の報告です。以下の流れで動いています。
データの取得と計算を担うのはPythonで作成したスクリプトです。検索管理コンソールとサイト解析サービスの双方へ読み取り専用の鍵で接続し、データを直接取得します。先週と先々週を対象に、表示回数、クリック、掲載順位、流入量がどう変化したかを計算します。
算出された内容は、そのままチャットへ投稿されます。データ取得から投稿までの間にAIによる処理は入りません。掲載される数字はすべてプログラムが確定しています。
この構成を選んだのは、前章までに説明した信頼性を確保するためです。週ごとの結果は次の行動を決める材料なので、実行のたびに値が変わっては役に立ちません。AIを利用するのは、確定済みの結果を材料に次の施策を検討するときだけです。
一方、この仕組みを構築する段階ではAIを活用しました。認証方法の設定、二つのサービスからの情報取得、週同士の比較計算、チャットへ出す形式など、スクリプトを書く支援を受けています。検証を終えた処理を定期実行へ登録しました。つまり、AIは仕組みを組み立て、日々の処理はプログラムが繰り返すという役割分担です。
実装例2：営業の月別ダッシュボード
次の例は、営業部門の商談台帳を月単位で集計するダッシュボードです。スプレッドシートに記録された情報を読み込み、一つのページで状況を確認できるようにしています。
この仕組みを運用した経験から、特に重要だった学びは2点あります。
1点目は、後から分析軸を増やせる構造にすることです。当初は月ごとの件数だけを表示していました。しかし、利用が始まると、担当者、流入経路、商談確度など、別の視点でも確認したいという要望が生まれます。当社のダッシュボードも、表示の切り替えや条件による絞り込みを備える形へ発展しました。初期段階ですべてを盛り込まず、まず一つの指標を見せ、実際に求められた視点を順次加える方が、完成までの時間を短縮できます。
2点目は、いつ更新するのかを事前に定めることです。この画面は、1日のうち決められた複数の時刻に再生成されます。数値の基準時点が不明な画面は、会議の資料として利用できません。最終更新日時は、利用者が見つけられる場所へ必ず表示しましょう。
この事例でも、集計には入力に対して結果が一定となる処理を使い、AIは画面を構築する支援に回しています。台帳データを扱う際に確認すべき事項は、ExcelとGoogleスプレッドシートをClaude Codeで扱う｜できること・できないことの線引きで詳しく紹介しています。
実装例3：日次の経営レポート
3例目は、当日の商談記録を集約し、夕方になるとチャットへ届く経営向けの日次報告です。閲覧者を経営層に限定するため、投稿先には参加者を制限した社内チャンネルを指定しています。
この仕組みを作る過程で遭遇した、2種類の落とし穴も共有します。同様の自動化を行う場合には、どちらも起こり得る問題です。
一つは、投稿を行う仕組み自体がチャンネルへ参加していなければ、メッセージを出せないことです。非公開チャンネルを送信先に設定した際、投稿側がそのチャンネルのメンバーではなかったため、処理がエラーになりました。必要な権限と設定がそろっているように見えても、参加状態が原因で失敗します。
もう一つは、エラー通知を本来の投稿先とは別にする必要があることです。先ほどの失敗時、異常を知らせるメッセージまで同じチャンネルへ送る設定なら、その通知も表示されません。送信先に問題があるとき、同じ送信先だけへ異常を知らせても発見できないためです。現在は、失敗を報告するチャンネルを分けて運用しています。
この2点は、自動レポートに共通する典型的な問題です。届いて当然と思われている資料が実は止まっており、その状態が数週間見過ごされる場合もあります。検算と停止検知を扱う次の2章で、対処法を説明します。
数字が合っているか確かめる5つの検算
人による確認を無理なく続けるには、点検対象を限定しなければなりません。当社では、次の5項目を検算に使っています。
第1は、行数の照合です。原本の総行数、条件を適用した後の行数、最終的に集計対象となった行数を資料の端へ記載します。金額や数量の合計を見る前に、まず対象件数を確かめます。
第2は、総計同士の突き合わせです。区分ごとに算出した値を足した結果と、全データから直接求めた総計が一致するか確認します。差があれば、いずれかのデータが分類されずに漏れている可能性があります。
第3は、対象期間の境界確認です。月をまたいでデータを扱うと、切り替わる日付が重複したり、反対に除外されたりしやすくなります。前月最終日と当月初日の扱いを意識して点検します。
第4は、前月との比較で見つかる極端な変化です。前月値から大幅に動いた項目をプログラムで抽出し、理由を確認します。本当の事業変化である場合だけでなく、抽出や計算の条件が変わったために生じるケースも少なくありません。
第5は、報告値から原本へ戻る照合です。レポート内の値を一つ選択し、元の表までさかのぼって人が数えます。全項目を再計算するのは現実的ではありませんが、一つであれば実行できます。その値が一致すれば、集計処理の基本構造が正しく動いていると判断する材料になります。
5項目すべてを確認しても、必要なのは数分程度です。報告書を最初から最後まで眺めるより、確認点を限定した方が誤りを見つけやすくなります。
静かに止まる5つの原因
定期配信で警戒すべきなのは、目立つエラー表示よりも、処理も通知も何も現れない状態です。当社で実際に経験した停止原因を5つ紹介します。
第1は、手動実行と自動実行の環境差です。担当者が操作すれば動くのに、予約した時刻には失敗することがあります。当社の例では、自動実行時に必要なプログラムの保存場所を認識できないことが原因でした。手作業で使える経路が、予約処理でも同じように使えるとは限りません。
第2は、設定ファイルを参照する場所の食い違いです。接続設定を読むフォルダについて、作成者の想定と実際の処理が一致せず、必要な情報を取得できないまま終了したことがあります。特に発見しにくいのは、エラーではなく、配信対象が存在しないものとして正常終了してしまうケースです。
第3は、実行用端末がスリープしていることです。自分のパソコンで予約処理を動かす方式では、予定時刻に端末の電源が切れていれば実行されません。
第4は、接続する外部サービス側の上限です。サービスの仕様により、処理できる時間や一度に取得可能な件数が制限される場合があります。上限へ達して途中までしか取得できていないのに、その部分的なデータが正常な結果として返されることもあります。
第5は、送信を担う仕組みが投稿先へ参加していないことです。これは第9章で紹介した事例に当たります。
5つに共通する厄介さは、異常が起きても分かりやすい失敗として見えないことです。そこで、自動処理には以下の3要素を必ず含めます。
- 処理履歴を保存します。動作した時刻、扱った件数、最後に到達した工程を後から確認できるようにします
- 異常時は別経路で知らせます。通常の投稿先が使えなくても、担当者が気づける場所へ通知を出します
- 正常終了も簡潔に通知します。成功連絡は不要に見えますが、普段届く合図があるからこそ、その合図が途絶えた異常を発見できます
これら3要素を実装する手順は、Claude Codeの定期実行・自動化｜作り方と「静かに止まっても気づく」仕組みで、さらに具体的に解説しています。
材料の取りこぼしは「該当なし」の顔をする
集計を始める前の収集段階にも、注意すべき問題があります。一部の材料が欠けているにもかかわらず、すべて取得できたように見えてしまう状態です。
当社では以前、約600件の記録を複数の場所から探し、一枚の集計表へまとめたことがあります。初回の結果を確認すると、想定より明らかに件数が少なくなっていました。調査したところ、検索で取得できる件数に上限があり、それを超えた記録が通知なく除外されていたのです。処理はエラーにならず、取得できた範囲だけを全件であるかのように返していました。
対処方法は難しくありません。対象期間を短く分割して取得します。1か月を一度に検索せず、半月ごとに結果を取り出してから合算します。さらに、分割した各結果の件数を足し、事前の想定と一致しているかを確かめます。
この事例を踏まえ、当社の収集処理には次の確認を組み込んでいます。
- 毎回の取得件数を履歴として残します（前回より不自然に減った場合は、取得漏れの可能性を調べます）
- 検索対象の期間を分割し、それぞれの結果を最後に合算します
- 発見できなかった対象も明示させます（対象期間と区分を示して0件だったと記録します。取得失敗と本当の0件を同じ扱いにしません）
複数の保管場所をまたいで資料を探す手順については、Claude Codeでまず効くのは「作る」より「探す」｜社内の資料・過去のやりとりを横断で見つけるで詳しく取り上げています。
AIに任せてよい部分・任せてはいけない部分
ここまでの内容を、担当させる作業と人が担う作業に分けて整理します。AIへ任せられるのは、以下の領域です。
- 集計を実行する処理の作成（AIは処理を書き、完成後の実行はプログラムが担当します）
- 異なる様式を共通形式へ変える仕組みの用意（表そのものではなく、変換処理を作らせます）
- 確定した値の動きを説明文へ整理する作業（入力された数値を変更しないよう条件を付けます）
- 報告書全体の読みやすさを整える作業（章立て、情報の順序、重要点の整理を支援させます）
- 前年同月の資料と比較し、表現方法の違いを洗い出す作業
反対に、次の仕事はAIへ委ねず、人または検証可能な仕組みに残します。
- 数値そのもののカウントや合算（第4章と第5章で述べたとおり、プログラムで確定します）
- 変化が起きた原因の決め付け（たとえば、売上減少を値上げだけの影響と断定させません。AIは相関関係と因果関係を適切に区別できないことがあります）
- 根拠なく将来値を生成する作業（予測が必要なら、前提条件を示したモデルを使用します）
- 最終的な経営上の意思決定（判断材料の準備に活用しても、決定する責任は人が持ちます）
- 数値を含む情報の社外提供（取締役会向け資料や対外説明は、人による確認を終えてから扱います）
境界を決める基準は一つに集約できます。作業結果を後日検証できるかどうかです。確認手段を用意できる作業は委ねられますが、正否を追えない仕事は人の管理下に置く必要があります。
よくいただく質問
可視化製品と比べて、どちらから導入すべきでしょうか。
必要なデータがまだ一か所へまとまっていないなら、先に本記事の方法へ着手します。可視化製品の役目は整った材料を表示することであり、分散した材料を整備することではありません。複数の情報源から一枚へ集約する処理を先に作ると、その後の製品導入も進めやすくなります。
スプレッドシートの関数だけでも対応できませんか。
すべてのデータが一つの場所に集約済みなら、関数で十分に対応できます。本稿が想定するのは、保存先がいくつもあり、入力形式も月によって変化する環境です。外部サービスから情報を取得し、形式を変換する工程までは、表の関数だけで埋めにくい部分です。
業務上の数値をAIへ入力することが心配です。
入力内容は必要最小限へ限定できます。個別の取引内容や個人を識別できる情報は除外し、計算を終えた数値だけを渡す構成にしてください。情報範囲を決める方法は、Claude Codeで情報漏洩を防ぐ｜入れてよい情報・いけない情報の線引きで解説しています。
担当者が一人の場合、仕組みがその人に依存しないでしょうか。
何も対策しなければ属人化します。そこで、担当者の記憶ではなくファイルとして処理を残し、フォルダ内の構成も一覧化してください。最後の正常実行日、停止方法、管理責任者という3情報まで記録されていれば、後任へ引き継ぎやすくなります。
導入による成果は、社内へどのように示せばよいですか。
作業時間の削減量だけを起点にすると、前提の違いから議論が平行線になりがちです。代わりに、従来は不可能だった頻度で報告を出せるようになったかを基準にすることを勧めます。月1回だった報告が週1回になった変化なら、成果として共有しやすいでしょう。評価方法の詳細は、Claude Codeの費用対効果を社内で説明する｜時間削減の測り方にまとめています。
まとめ
- 多くの企業では、可視化製品より先にデータを整える必要があります。分散した表を横断し、月ごとに変わらない一枚へまとめる工程から始めます
- 最優先で守るのは、AIに数値集計を直接させない原則です。計算結果はプログラムで確定し、AIには文章での説明を担当させます
- 直接集計を避ける根拠は3点あります。再現性を保証できないこと、誤りの発生箇所を追えないこと、間違った値でも自然に見えることです
- 完成までの作業を5段階へ区切ります。収集、形式統一、計算、文章化、配布の順で進め、AIは主に形式統一と文章化を支援します
- データ取得には閲覧専用の権限を使います。自動処理が誤って原本を書き換える危険を取り除けます
- 検算対象は5項目に限定します。対象件数、総計、日付境界、前月からの異常な変化、原本との照合を見れば、全文の目視より効率よく誤りを探せます
- 自動配信は目立たない形で停止することがあります。実行環境の差、設定の参照場所、端末の休止、外部サービスの上限、投稿先への未参加はいずれも発見が遅れやすい原因です
- 異常時だけでなく、正常終了時にも合図を出します。日頃の成功通知が途絶えることで、停止を早期に認識できます
- 取得漏れは本当の0件と区別しにくい問題です。期間を分けて取得し、件数を履歴へ残し、見つからなかった対象も明記します
- AIへ任せる可否は、後から正しさを調べられるかで判断します。数値の確定と原因の最終判断は、検証できる仕組みと人の責任として残します
経営企画におけるAI利用で最初に目指すべきなのは、分析を高度に見せることではありません。毎月決まった日に、同一形式の数値が、根拠を確かめられる状態で届く仕組みを整えることです。この土台ができて初めて、担当者は数字を作る作業から離れ、その数字が示す変化を考える仕事へ時間を移せます。取り組む順序を逆にしないことが重要です。
経営企画や管理部門の担当者が、自社における数字の流れに合わせてAI活用を学べるよう、職種単位のカリキュラムを提供しています。社内だけで導入手順を設計することに難しさを感じる場合は、職種ごとのAI実践研修もご確認ください。
当社は、技術職ではない方がClaude Codeを安全に業務へ取り入れられるよう、研修および導入初期の支援を行っています。情報源の棚卸しから、集計と文章作成の分離、5項目の検算、配信停止を見逃さない運用設計まで、各社の報告業務に沿った形で組み立てます。最初のご相談に費用はかかりません。
