コンテンツにスキップ
Picaro.AI Picaro.AI Prompt Library

レポートを作成する

このページでは、月次・週次のレポートを AI が一気に組み立てて、HTML のスライド資料として出力できます。データの下調べ → データが揃っているかの事前チェック → データ収集 → スライド構成 → HTML 化までを 1 つの指示でまとめて実行することも、ステップごとに確認しながら進めることもできます。

このページの基本情報

Section titled “このページの基本情報”
項目内容
このページでできること対象期間・比較期間を指定して、KPI とスライドをまとめた HTML レポートを生成する。あわせて、レポート設定の保存・再利用や、使えるデータソースの下調べもできる
対象レポート（HTML スライド資料）。中身はスポンサープロダクト広告（SP）を中心とした KPI・貢献度分析
必要なデータ・接続接続済みアカウントの広告実績・検索データ（追加設定は不要）。できあがった HTML を Slack などで配る場合は共有先の準備
実行範囲大半はレポート作成のみ（HTML などの生成）で、広告設定は変更しません。 ただしプロンプト 3 の「レポート設定の保存・削除」は設定の**記録（永続化）**にあたり、削除は元に戻せません。各プロンプトの「設定変更」で個別に示します

こんな時に使います

Section titled “こんな時に使います”
  • 対象期間と比較期間を指定して、月次・週次のレポートを 1 つの指示でまとめて作りたい
  • ステップごとに中身を確認しながら、データが揃っているかを先に確かめつつレポートを組み立てたい
  • 毎月同じ形のレポートを作れるよう、スライド構成やしきい値を設定として保存しておきたい
  • 新しいレポート設定を作るときに、使えるデータソースの候補を調べたい
  • 前月比の月次比較や、年初来（YTD）サマリー、過去 3 ヶ月のトレンドを表で見たい

実行前に確認すること

Section titled “実行前に確認すること”
  • 接続先のアカウント … 複数アカウントを扱う場合は、対象アカウントが合っているか先に確認します。
  • 対象期間と比較期間 … 多くのプロンプトで指定します。指定しなければ直近の確定済みの期間・その前の同じ長さの期間が使われます。当日・前日のデータは未確定のことがあるため、確定済みの直近期間が安全です。
  • 保存済みのレポート設定（任意） … 毎月同じ形にしたい場合は、先に プロンプト 3 で設定を保存しておくと、以降の生成で呼び出せます。

プロンプト早見表

Section titled “プロンプト早見表”
やりたいこと分かること・作られるもの設定変更プロンプト
レポート設定を保存して毎月再利用する一覧・確認・保存・削除の結果設定を保存・削除（記録）プロンプト 3
レポートに使えるデータソースを下調べする候補データソースの一覧（上位 5 件まで）変更なし（下調べのみ）プロンプト 4
前月比の月次比較レポートを作る主要 KPI の当月・前月・差分の比較表変更なし（レポート生成のみ）プロンプト 5
年初来（YTD）サマリーを作る月別の KPI 推移と年間累計の表変更なし（レポート生成のみ）プロンプト 6
過去 3 ヶ月の広告売上・注文トレンドを確認する週ごとの売上・注文推移と要因仮説変更なし（レポート生成のみ）プロンプト 7

プロンプト 1: レポート設定を保存して毎月再利用する

Section titled “プロンプト 1: レポート設定を保存して毎月再利用する”

レポートの設定に名前を付けて保存し、毎月の生成時に同じ設定を呼び出せるようにします。設定の一覧・確認・保存・削除をこのプロンプトでまとめて扱います。

こんな時に使う — 毎月同じ形のレポートを作れるよう、スライド構成やしきい値を設定として固定したいとき。

実行前に必要な情報 — 設定名（例: monthly-standard / agency-client-a）、画面に出す表示名、設定の中身（スライド構成・しきい値・伏せ字にする項目など）。

レポート設定を管理して:
- 一覧を見せて
- {{設定名（例: monthly-standard）}} の内容を見せて
- {{設定名（例: monthly-standard）}}（表示名: {{表示名（例: 月次標準）}}）として、
  スライド構成・しきい値・伏せ字の設定をまとめて保存して
- {{設定名（例: monthly-standard）}} を削除して


保存した設定は、その後のデータ収集・スライド構成・
レポート生成で再利用される。

変更できる条件 — 設定名／表示名／設定の中身（スライド構成・しきい値・伏せ字にする項目など）／実行する操作（一覧・確認・保存・削除）。

返ってくる内容 — 一覧・確認・保存・削除のいずれを実行したかの結果。保存した設定は、その後のデータ収集・スライド構成・レポート生成で再利用されます。

設定変更 — レポート設定をアカウントに保存・削除します（記録）。 保存は設定の永続化にあたり、同じ名前への上書きは事前に確認します。削除は元に戻せないため、最終確認を求めます。広告設定は変更しません。

次にすること — 保存した設定は、このページのレポート生成プロンプト（プロンプト 3・プロンプト 4）から呼び出せます。

プロンプト 2: レポートに使えるデータソースを下調べする

Section titled “プロンプト 2: レポートに使えるデータソースを下調べする”

新しいレポート設定を作るときや既存の設定を広げるときに、Picaro で取得できるデータソースの候補を上位 5 件まで返します。

こんな時に使う — 新しいレポート設定に、どんなデータソースを組み込めるかの候補を調べたいとき。

実行前に必要な情報 — 探したいデータの種類（例: 在庫,利益。カンマ区切り）。

レポートを新しく作りたいが、どのデータを使えばいいか分からないときに使います。


テーマ {{探したいデータ（例: ACoS, 検索語句, SQP, 在庫）}}（カンマ区切りで複数可）に
関連する Picaro のデータソース候補を、テーマごとに上位5件まで提示してください。


探索は次の手順で行ってください。
1. get_openapi_spec の read_data_paths（read データ面の path 一覧）を取得し、
   path・summary・required フィールドをテーマ語で絞り込んで候補を選ぶ。
   ここが候補名の唯一の出所です。
2. discover_report_sources は候補名を返さず件数と信頼度のみを返すため、
   候補の列挙には使わず、機能スラッグ（product-detail, search-term-compare, label 等）を
   指定したときの裏付け（found / confidence）としてのみ併用してください。
   指標名（ACoS 等）を渡すと実在しても not_found になるため、判定に使わないこと。
3. get_data_ingestion_status で対象データの取込状況を確認する。
   rollup_status は1本でも no_data があると no_data に倒れるため、
   必ず reports[].statuses の明細で判断してください。
4. SQP 系が候補に入る場合は list_sqp_date_ranges で実在する期間候補を取得してください。


各候補について、次を明記してください。
- 取得できる粒度（アカウント／ポートフォリオ／キャンペーン／ASIN／検索語句 等）。
  required フィールドの type や集約軸から判断し、推測で書かないこと。
- 取得できる期間の制約（利用可能な最新日・欠落期間・2期間指定が必須か・
  指定できる frequency）。実際に取得できた範囲だけを書き、未確認の期間を断定しないこと。
- 候補データの簡単な説明（何の意思決定に使うか）


最後に「次工程で指定するパラメータ」を必ず付けてください。
データソース名を次のプロンプトへ渡す引数は存在しないため、選んだ候補を
period / frequency / KPIタブ / 集約レベル の具体値に翻訳して示すこと。


候補の中から使うデータソースを選んだら、次のいずれかに進んでください。
- 検索語句や施策の貢献度を先に確認したい場合は、貢献度データの事前チェックを行ってから本番の分析に進んでください
- レポートの構成から組み立てたい場合は「確認しながら段階的にレポートを作る」を使ってください

変更できる条件 — 探したいデータの種類／候補の件数（既定は 5 件まで）。

返ってくる内容 — 候補データソースの一覧（どこで一致したか・関連度の高さ付き）と、レポート設定に組み込むときの記述例。

設定変更 — 変更なし（下調べのみ）。候補を返すだけで、設定は保存しません。

次にすること — 組み込みたいデータソースが決まったら、プロンプト 3 でレポート設定に加えて保存します。

プロンプト 3: 前月比の月次比較レポートを作る

Section titled “プロンプト 3: 前月比の月次比較レポートを作る”

当月と前月の SP 広告パフォーマンスを比較し、可視化テーブルを生成します。

こんな時に使う — 月初の経営レビュー向けに、主要 KPI の前月比をひと目でわかる表にしたいとき。

実行前に必要な情報 — 当月（例: 2026-04、指定しなければ直近の確定済みの月）、前月（例: 2026-03、指定しなければその前月）。

{{当月（例: 2026-04）}}と{{前月（例: 2026-03）}}のSP広告パフォーマンス（売上/広告費/ACoS/ROAS/注文）を比較し、差分（絶対値と%）を含む可視化テーブルを作成して（{{前月}}は{{当月}}の前月として自動算出してよい）。
目的: 月次の変化を把握し、翌月の運用方針判断に使う。


【データ取得】
・SP実績は analyze_ad_type_performance を campaign_types=["SP"] で、{{当月}}と{{前月}}のそれぞれについて period_start / period_end を暦月の初日・末日で明示して2回呼ぶ。1回の呼び出しに両月をまとめない。
・レスポンスの period が要求した月と一致しているか毎回確認し、実際に返ってきた期間を表の脚注に書く。一致しなければ数値を出さず不一致を報告する。
・/bigquery/advertising-performance を期間指定の比較に使わない。このエンドポイントは from_date / to_date を無警告で無視し、HTTP 200 のまま別の暦月ペアを返す。「当月 vs 前月」は形が正しく見えるため誤りに気づけない。
・5指標はすべて同一レスポンス（analyze_ad_type_performance の metrics[]）から取り、出所を混在させない。get_dashboard は ROAS を返さず、SP単独でもなく、総売上は税抜・オーガニック込みの別集計なので同じ表に並べない。
・source_row_count と fetch_truncations を確認し、打ち切りがあれば「合計は過小」と明記する。


【完全月の原則】
・{{当月}}が進行中の月なら、部分月と完全月を比較しない（必ず「悪化」と出る）。get_data_ingestion_status で確定済みの最終日を確認したうえで、
　(a) 直近の完全月とその前月に置き換えて比較する、または
　(b) 部分月であることを明示し、日次平均（期間合計 ÷ 日数）で比較する。
　日次平均を使う場合は分子・分母・日数を必ず表に書く。未確定の日を日数に含めない（含めるかどうかで符号が反転しうる）。
・rollup_status を確定判定に使わない（未出稿の広告種別1件で日全体が no_data に落ちる）。個別レポートの status を見る。
・完全月同士でも日数が違う場合（28/29/30/31日）は、実数の差分に加えて日次平均の差分も併記する。


【注文数の健全性チェック】
・各月について 売上 ÷ 注文 = 平均注文単価 を計算し、直近数ヶ月と桁が揃っているか確認する。桁が外れている月は注文が取り込み不足の可能性が高いので、注文の前月比を数値として出さず「注文データ不整合のため比較不可」と明記する。推定値で埋めない。


【差分の表記】
・金額・件数: 絶対値＝実数差、%＝相対変化（(当月−前月)÷前月）。
・ACoS・ROAS などの比率指標: 絶対値＝パーセントポイント差(%p)、%＝相対変化。片方だけ書かない。
・MCPが返す delta / changeRate をそのまま転記しない。ツールごとに絶対差・相対差・bps と単位が異なり、同じ変化が別の数値になる。表の値は metrics[] の実測値から自分で計算し、計算式（分子・分母・日数）を脚注に書く。


【可視化】
・MCPはチャート画像を返さない。build_report_slide_spec はチャート種別と系列名の仕様(spec)までで描画しない。比較表はMarkdownテーブルで出力する。
・PPTX成果物が要る場合のみ run_report_command mode=pptx を使うが、これはアカウント全体のレポートでありSP単独の比較表ではない。混同しない。


次の5点構成で出力してください。
1. What happened — 主要指標の実績と前月比（絶対値・%）
2. Why — 悪化した指標があれば要因（検索語句/入札/CPC/CVR/予算/掲載枠）を「原因診断」で確認し1〜2点添える
3. So what — 事業への意味（機会損失・改善余地）。外挿した推計は「MCPの返り値ではない」と明記する
4. What was done — 期間中に実施した施策があれば明記。取得できない場合は「施策記録は取得不能」と書く（「実施した施策なし」と断定しない）
5. What should we do next — 翌月に「継続」「見直し」が必要な領域を1〜2件挙げ、見直しは入札変更の提案・承認フローへ回す


【出典の明記】
・表の脚注に、使用ツール名・campaign_types・実際に返ってきた period・source_row_count・fetch_truncations を書く。
・売上は税込・SP帰属7日クリック窓であることを明記する。


【Guardrail】
・翌月同様のレポートを作成し、指摘した領域が改善したか確認する。

変更できる条件 — 当月／前月。

返ってくる内容 — 主要 KPI（売上・広告費・ACoS・ROAS・注文）を当月・前月・差分（絶対値と %）で並べた比較表。

設定変更 — 変更なし（レポート生成のみ）。広告設定は変更しません。

次にすること — 年間の推移とあわせて見る場合は プロンプト 4 を使います。

プロンプト 4: 年初来（YTD）サマリーを作る

Section titled “プロンプト 4: 年初来（YTD）サマリーを作る”

年初から現在までの SP 広告メトリクスをサマリー表示します。

こんな時に使う — 四半期・年次のレビュー向けに、年初来の KPI 推移と年間累計をまとめたいとき。

実行前に必要な情報 — 対象年（例: 2026、指定しなければ当年）。

{{対象年（例: 2026）}}年初来のSP（スポンサードプロダクト）広告実績を、次の5段構成でまとめてください。


取得手順（この順で必ず実行する）
1. まず当年の「直近の確定済み月」を確定する。データ取込状況を月次で確認し、当月は月の途中のため累計に含めない。確定済み月までを「年初来」と定義し、レポート冒頭に対象期間・月数・網羅率を明記する
   🔴 rollup_status を確定判定に使わない。 未出稿の広告種別が1件あるだけで、他のレポートがすべて completed でも月全体が fully_missed / no_data に落ちる（実測で、completed 13/16 なのに rollup_status=fully_missed の月があった）。必ずレポート別の status を見て、自分の分析に必要なレポート（SP なら Sponsored Products / Sponsored Product Campaign / Targeting SP）が completed かで判定する
   🔴 月次で見ると、日次とはレポートの集合が違う（月次にのみ Subscribe & Save と SQP が現れ、Suggested Bid は現れない）。また月次には completed / in_progress / no_data / fully_missed に加えて out_of_range という値が出る。これは「取込失敗」でなく「そのレポートの保持期間外」であるので、月を丸ごと除外する理由にしない
2. SP実績は必ず「1か月ずつ個別に」取得する。年初来を1回の期間指定でまとめて取得しない
3. 検算する。月別値の合計と、同じ期間を1回で指定した値を突き合わせ、差があれば両方の数値と差分（金額・%）をレポートに明記する。一致した場合も「検算済み」と明記する
   🔴 実測でこの2つは一致しない。 3か月分で検証したところ、1回指定の方が広告費で約5%・インプレッションで約7%低く出た（年単位では千万円オーダーの差になる）。
   累計値には月別値の合計を採用し、1回指定の値は検算用の参考値として併記する。どちらを採用したかをレポートに明記する。差の原因は特定できていないので、推測の説明を付けない
4. 広告タイプはSPのみに限定する。アカウント全体やDSP・SB・SDを含む値をSPの値として扱わない
5. 指標の出所を1つに固定し、出所名をレポートに明記する。同じACoSでも取得元により数値が変わるため、途中で出所を変えない
6. 打ち切りの確認を月ごとに行う。打ち切り情報が空でなければ「その月の合計は過小」と明記する。
   🔴 キャンペーン件数（campaign_count / source_row_count）は期間を変えても同じ値を返す（実測で単月・3か月のすべてで同一値）。これを「その月の稼動キャンペーン数」として読まない。月別の稼動件数が必要なら別のツールで取る


出力
1. What happened — 月別の広告費/広告売上/ACoS/ROAS/クリック/CPCの推移と、確定済み月までの累計を表で示す。取得できなかった月・部分月は累計に混ぜず、表外に区別して明記する。月によって日数が違う（28/29/30/31）ので、推移を読むときは日次平均も併記する
2. Why — 累計値の変動要因を ACoS = CPC ÷ RPC（クリック単価 ÷ クリックあたり広告売上）に分解し、CPC要因かRPC（CVR・単価）要因かを数値で示したうえで、検索語句/入札/CPC/CVR/予算のいずれかに分類して説明する（「原因診断」を使ってもよい）
3. So what — {{年間KPI目標（例: ACoS 15%以下）}}との対比を示す。この目標値は利用者の入力値として扱う（年間目標はMCPから取得できないため）。
   🔴 MCPに月次KPI目標が保存されている場合は、保存されているのがどの指標かを列挙してから併記する。実測では ACOS上限は未設定で、保存されていたのは TACOS上限 と CPA上限 だけだった（しかも対象年の１か月分のみ）。TACoS の値を ACoS 目標として提示しない（分母が違う別指標）。KPI目標が何か月分存在し、うち対象期間に重なるのが何か月分か（目標の網羅率）を明記する。乖離があれば事業への影響を1行で述べる
4. What was done — 期間中に実施した施策を列挙する。変更履歴の取得可能範囲（遡れる日数）を先に明記し、対象期間が範囲外、または取得0件だった場合は「実施した施策なし」とは書かず、「MCPからは取得できなかった（取得可能範囲: ○○）」と明記する。
   変更履歴ツールは上限を超えた開始日を渡すと自動で上限まで切り上げ、調整後の開始日を注記で返すので、その注記に書かれた日付をそのまま引用すればよい。年初来をカバーできないことを冒頭で宣言し、施策欄は「直近○日分のみ確認可能」と範囲を限定して書く
5. What should we do next — 乖離が大きい月があれば「要因調査が必要」と明記し、優先度順に次のアクションを示す


実行条件
- 期間は{{対象年（例: 2026）}}の1月から直近の確定済み月まで。月次データは全月を取得し、欠けている月があれば明記する
- 未確定日は0埋めの行が返ることがあるため、実績0と未取込を区別できない旨を明記する
- 確定済み月であっても、再取込（re-crawl / backfill）で値が書き換わりうる。過去の数値を不変のものとして提示しない（四半期ごとの更新で前回と値が違っても、それだけで不具合と断定しない）
- 前年同期比を出す場合は、比較する2期間の月数・日数を揃える。揃えられない場合は比較しない
- 四半期ごとに同レポートを更新し、目標乖離の推移を追う

変更できる条件 — 対象年／年間KPI目標（例: ACoS 15%以下、任意。指定すると乖離を対比できます）。

返ってくる内容 — 月別の KPI（売上・広告費・ACoS・ROAS）推移と、年間累計の表。

設定変更 — 変更なし（レポート生成のみ）。広告設定は変更しません。

次にすること — 前月単位の比較は プロンプト 5、直近の週次トレンドは プロンプト 7 を使います。

プロンプト 5: 過去 3 ヶ月の広告売上と注文トレンドを確認する

Section titled “プロンプト 5: 過去 3 ヶ月の広告売上と注文トレンドを確認する”

過去 3 ヶ月の Amazon 広告経由売上と注文数のトレンドを表示します。

こんな時に使う — 直近の広告売上・注文数の増減傾向と、その要因の見当をつけたいとき。

実行前に必要な情報 — なし（そのまま使えます）。

過去3ヶ月のAmazon広告経由の売上と注文数を週次トレンドで表示してください。
増減が大きい週については、要因の仮説を検索語句/入札/CPC/CVR/予算/掲載枠のいずれかに分類して添えてください。
目的: トレンド変化の背景を理解し、次の施策判断に使うため。


データ取得（この手順で取ること）
- 週次系列は call_picaro_api の POST /bigquery/advertising-chart（frequency: "weekly"）から取得する。
  body に amazon_account_id / frequency / from_date / to_date を渡す。
  get_dashboard は frequency=weekly を指定しても週次系列を返さず期間合計1点だけなので、トレンド用途に使わない。
  analyze_ad_type_performance を長期間の1回指定で使わない（窓が長いほど無警告で過少集計する）。
  /bigquery/advertising-performance は期間指定を無警告で捨てるので使わない。
- 期間は「日曜始まり・土曜終わり」の週境界に揃える。{{分析基準日}}以前で最後に終了した土曜日を終端、
  その13週前の日曜日を始端とする。週境界に揃えないと端の部分週が丸ごと無警告で落ちる。
- 取得後に必ず検算する: 「返却された週数 × 7」が要求日数と一致するか。一致しなければ端の週が落ちているので、
  週境界に揃え直して取り直す。
- 応答の tooltip を網羅性の根拠にしない。tooltip は欠落を示さないだけでなく、
  chart_data に存在しない週まで終端として表示する。常に chart_data の行数を数えて判定する。
- 「広告経由の注文数」は purchases を使う。同じ応答の order_count は総注文数（広告以外を含む）なので混同しない。
- 最終週に未確定日を含めない。get_data_ingestion_status で取込状況を確認する。
  ただし rollup_status は未出稿の広告タイプ1件で日全体が no_data になるため、確定判定に使わない。
  reports[] をレポート単位で見て判定する。


応答フィールドの対応（推測で埋めないこと）
- そのまま使える: ad_sales（広告売上）/ purchases（広告経由注文数）/ ad_spend（広告費）/ acos / cvr /
  ad_clicks（クリック）/ impressions（表示回数）/ rpc（＝ ad_sales ÷ ad_clicks）
- 導出が必要: CPC は返らない。ad_spend ÷ ad_clicks で導出し、導出値である旨を注記する。
- 使わない: 応答の aov フィールド。この値は ad_sales÷purchases とも total_sales÷order_count とも一致せず、
  定義が開示されていない。平均注文単価は必ず ad_sales ÷ purchases を自分で計算する。


出力
1. 週次テーブル — 週（日曜起点）／広告売上／前週比／広告経由注文数／前週比／広告費／ACoS／CPC（導出）／CVR／
   平均注文単価（広告売上÷広告経由注文数・自分で計算）／クリック／表示回数
2. 健全性チェック — 週ごとの平均注文単価を必ず算出する。他週から大きく外れる週があれば
   「注文数の欠損疑い」として明示し、その週の増減率を結論の根拠に使わない
3. 要因仮説 — 広告売上または注文数が前週比±15%以上動いた週について、要因を
   検索語句／入札／CPC／CVR／予算／掲載枠 のいずれかに分類する
   - 入札・CPC・CVR は上記と同一の週次ソース（CPC・CVR・クリック・表示回数・広告費）から判定できるので、
     数値を添えて断定してよい
   - 検索語句・予算・掲載枠は別ソース・別集計窓になり週次と同一基準に揃わない（掲載枠は別テーブル系統で
     集計窓が異なる／検索語句は取得が截断される／予算消化率は2日以上の窓で単位が壊れる）。
     参照した場合は「別窓の補助仮説」と明記し、断定しない


最後に次の3点を出力してください。
1. 推奨アクション — 直近で悪化傾向がある要因について、対象・理由・優先度（Impact順）・期待効果・確信度・リスクを明記した改善アクション案を1〜2件
2. 実行方法 — 要因が入札/CPCなら「原因診断」または該当する入札調整プロンプトへ、検索語句なら除外キーワード系プロンプトへ接続する。
   ACoSは取得元によって値が乖離するので、閾値で絞る場合は出所を1つに固定し、どのツールの値かを明記する
3. 測定 — {{効果測定を行う日（例: 施策実施の4週間後）}}に、本プロンプトと同じ週境界・同じ取得元で同トレンドを再取得し、
   施策実施週の前後で ACoS / CPC / CVR / 平均注文単価 を比較する。
   施策が実際に実施されたかは Picaro 側の変更履歴では追跡できない（変更履歴ツールは全条件0件）ため、
   実施日は依頼者の記録から確定させる。
   効果測定の窓は帰属窓（広告タイプごとに7日/14日と混在）より長く取る。実施直後の週は帰属未完了で過小に見える


実行条件
- 週次データは全期間を取得し、「返却週数×7」と要求日数の突合結果を必ず本文に書く。
  落ちた週があれば、落ちた日数と、その週に含まれる広告売上が全体の何%にあたるかを併せて明記する
- 比率を出すときは分子・分母・日数を必ず明示する
- 広告売上は税込、広告費は税区分未確定、総売上は税抜であり、これらを跨いだ比を「税基準の揃った値」として提示しない
- 確定済みの過去期間も再クロールで値が動きうるため、数値を不変として提示しない
- 部分データのときは増減の断定的な結論を出さない
- 読み取りのみ。書き込み系操作は実行しない

変更できる条件 — 分析基準日（任意。週境界の起点にする日）／効果測定を行う日（例: 施策実施の4週間後、任意）。

返ってくる内容 — 週ごとの売上と注文数の推移表と、増減傾向の要因の仮説（検索語句 / 入札 / CPC / CVR / 予算 / 掲載枠）。

設定変更 — 変更なし（レポート生成のみ）。広告設定は変更しません。

次にすること — 年単位の推移は プロンプト 6、施策との関連を見たい場合は 施策と外部イベントを記録して効果を検証する を使います。

レポート生成パイプライン

Section titled “レポート生成パイプライン”
[レポート設定の保存（任意、プロンプト 3）]
   ↓
データソースの下調べ（任意、プロンプト 4）
   ↓
事前チェック（プロンプト 2 の Step 1）
   ↓
データ収集
   ↓
スライド構成の組み立て
   ↓
HTML 化 → Slack 共有

プロンプト 1（1 つの指示でまとめて生成）は、上記の 事前チェック → データ収集 → スライド構成 → HTML 化 をまとめて実行する近道です。

関連カテゴリ

Section titled “関連カテゴリ”