そのまま使えるAI向けプロンプト
先に、今回の進め方を自社環境へ応用するためのプロンプトを掲載します。角括弧の部分を自社情報へ置き換え、CodexまたはClaude Codeへ渡してください。
これは、同じシステムが一度で完成する魔法の指示ではありません。AIに既存環境を調査させ、必要な権限と設計を整理し、読み取り専用の確認から段階的に実装するための初期ブリーフです。
使う前に、次の3点だけ確認してください。
- 角括弧の項目を自社環境の情報へ置き換える
- 最初の返答では、現状確認、不足情報、推奨構成、段階別TODOを出してもらう
- 権限変更、Secret更新、デプロイなどの本番変更前で必ず止めてもらう
あなたは、Instagram Graph API、Meta Business Portfolio、Google Cloud、BigQuery、運用ダッシュボード構築に詳しいデータエンジニア兼SNS運用責任者です。
自社または管理権限のあるInstagramアカウントの運用データをAPIで取得し、履歴保存、集計、ダッシュボード表示まで行いたいです。単発のAPI確認で終わらせず、日次運用できるところまで段階的に進めてください。
前提情報:
- 対象Instagramアカウント: [アカウントURL。パスワードは書かない]
- アカウント種別: [個人 / Creator / Business / 不明]
- Facebookページ接続: [あり / なし / 不明]
- Business Portfolio: [あり / なし / 不明]
- Metaアプリ: [あり / なし / 不明]
- 会社ID: [company_id]
- クライアントID: [client_id]
- プラットフォームアカウントID: [platform_account_id]
- 使用クラウド: [Google Cloud / その他]
- 既存リポジトリ: [パスまたはURL]
- 既存ダッシュボード: [あり / なし。構成やURL]
- 希望更新頻度: [例: 毎日]
- 主に改善したいこと: [認知 / 反応 / フォロワー / 投稿量 / EC送客]
進め方:
1. 最初に既存環境を読み取り専用で調査し、現在のアカウント接続、コード、クラウド、データ構造、ダッシュボード構成を整理する。
2. Instagram API、対象アカウント種別、Facebookページ接続、必要Permissions、App Review・Advanced Accessの要否は、作業時点のMeta公式ドキュメントで確認し、参照URLと確認日を示す。
3. InstagramへのログインとMeta for Developersへのログインを分けて説明する。Developer登録は実在担当者、アプリ所有は会社のBusiness Portfolio、本番API実行はシステムユーザーを基本案として検討する。
4. 取得したいKPIから必要最小限の読み取り権限を逆算する。投稿、コメント、DM、広告管理など、目的に不要な権限は追加しない。
5. API Explorerは指標と権限の初期確認だけに使い、本番トークンには使わない。アクセストークン、APIキー、パスワード、個人情報をチャット、Git、ログ、BigQuery、dashboard JSONへ出さない。
6. 実アカウントで、プロフィール、アカウントInsights、Media、Storiesの取得可否を小さくプローブする。指標が返らない場合は、ゼロ、欠損、投稿形式上の非対応、権限不足、metric名違いを区別する。
7. 既存リポジトリへ変更する場合は、remoteのデフォルトブランチから専用ブランチを作る。ユーザーの未コミット変更を壊さない。
8. 次のデータ構造を基本案として、既存基盤に合わせた実装計画を作る。
- GCS raw: 実行日時別の取得JSON
- BigQuery raw account snapshots: 1アカウント × 取得日
- BigQuery raw account daily: 1アカウント × 指標日
- BigQuery raw media snapshots: 1投稿 × 取得日
- BigQuery mart: 日次最新版、投稿最新版、ダッシュボードサマリー
- GCS dashboard JSON: client-firstの表示専用データ
- Cloud Run Job + Cloud Scheduler: 日次取得
- Secret Manager: 本番トークン
9. すべてのデータにcompany_id、client_id、platform_account_idを持たせる。投稿データにはmedia_id、投稿形式、公開日時、caption、permalink、thumbnail、reach、views、反応、available_metrics、unavailable_metricsを持たせる。
10. Instagram運用KPIを、投稿量、認知、反応、継続接点、EC送客に分ける。Instagram内の数値だけで売上やROASを断定せず、必要ならUTM、GA4、注文データの接続を別フェーズとして提案する。
11. ダッシュボードには以下を実装候補として整理する。
- Feed、Carousel、Reel、Storiesの投稿目標と実績
- 全投稿合計と投稿タイプ別の投稿数推移
- follower、reach、viewsの期間推移
- 合計、投稿タイプ別、1投稿平均を選べる系列
- サムネイルから投稿URLへ移動できる投稿カード
- 各指標で並べ替えられる投稿一覧
- 任意期間指定。初期値は今月
12. グラフは未来日をゼロとして描かず、実績値は今日で止める。補間曲線や過剰な点マーカーで、元データにない変化を作らない。初期表示は合計など必要最小限の系列にする。
13. 実装後は、schema、集計、dashboard JSON、HTML、外部リンク、自動テストを確認する。デスクトップとモバイルをブラウザで確認し、コードレビューと修正を指摘がなくなるまで繰り返す。
14. 本番書き込み、権限変更、Secret更新、Cloud Run / Scheduler作成、デプロイ、PRマージなど外部状態を変える操作は、影響と確認方法を説明してから実行する。ログイン、2段階認証、本人確認、App Review申請、トークンの入力は私に引き継ぐ。
15. 完了時は、取得できる指標、取得できない指標、権限、データフロー、テーブル構造、秘密情報の保管場所、テスト結果、残課題、運用手順をMarkdownでまとめる。
制約:
- 対象アカウントとクラウドは、私が所有または正当に管理を委任されている範囲だけを扱う
- パスワード、アクセストークン、APIキー、認証コードの貼り付けを求めない
- 公式仕様と実アカウントの結果を分け、推測を事実として書かない
- 取得できないたびに権限を広げず、metric名、APIバージョン、投稿形式、アセット接続を先に確認する
- 個人ユーザートークンやExplorerトークンを本番ジョブへ使わない
- 既存のクライアント／プラットフォーム構造がある場合は、別システムを増やす前に統合案を優先する
- 将来日、欠損、非対応、実績ゼロを同じ0として扱わない
- 公開記事や成果物には、メールアドレス、内部ID、非公開URL、トークン、顧客固有の実績値を残さない
まずは実装やブラウザ操作を始める前に、
1. 現状確認のチェックリスト
2. 不足している前提情報
3. 推奨アーキテクチャ
4. 必要権限の暫定案
5. フェーズ別TODO
6. 人間の操作が必要になる箇所
を提示してください。その後、読み取り専用の確認から進めてください。
プロンプトへパスワード、アクセストークン、APIキー、認証コードを貼り付けないでください。AIが参照できるのは、リポジトリ内のコード、権限が許可されたクラウド情報、公式ドキュメントなどに限定します。
AIを活用すると、どこまで作れるのか
今回、Codexを使って既存コードとGoogle Cloud環境を調査し、API取得処理、BigQueryのテーブルと集計、ダッシュボード用JSON、画面、テスト、コードレビューまで進めました。
完成した画面では、対象期間、累計投稿数、フォロワー、リーチ、Views、今月の投稿計画をまとめて確認できます。
投稿別画面では、サムネイル付きカードでクリエイティブを確認しながら、reach、Views、反応、保存、シェア、反応率を比較できます。表は各指標で並べ替えられるため、次に再現したい投稿を探しやすくなります。
外部の公開Professionalアカウントを対象に、普段より伸びた参考動画を探す方法は、次の記事で解説しています。
AIに任せた作業と、人間が担当した作業は次のように分かれました。
| 工程 | AIに任せやすいこと | 人間が行うこと |
|---|---|---|
| 現状把握 | リポジトリ、データ構造、クラウド構成の整理 | 対象範囲と目的の決定 |
| API確認 | 公式仕様の論点整理、試験クエリ、エラーの切り分け | Metaへのログイン、本人確認、2段階認証 |
| 権限設計 | KPIから必要な読み取り権限を逆算 | Business Portfolio上の承認 |
| 実装 | 収集、保存、集計、JSON、画面、テスト | 秘密情報の入力、本番変更の承認 |
| KPI設計 | 指標候補と画面案の作成 | 次の施策が変わる指標か判断 |
| 品質確認 | 自動テスト、デスクトップ・モバイル確認、コードレビュー | 最終的な公開・運用判断 |
AIで大部分を進められても、責任まで自動化できるわけではありません。特に認証、秘密情報、本番反映、KPIの意味付けは、人間が確認する前提にします。
Instagram APIダッシュボードの作り方：全体の7ステップ
実装全体は、次の7段階に分けると進めやすくなります。
- 対象Instagramアカウント、Facebookページ、Business Portfolio、Metaアプリの接続状況を確認する
- 改善したいKPIを決め、必要最小限の読み取り権限を整理する
- Graph API Explorerなどで、プロフィール、アカウントInsights、投稿Insightsを小さく取得する
- 本番用のシステムユーザーを準備し、トークンをSecret Managerへ保存する
- Cloud Run Jobで日次収集し、GCS rawとBigQuery rawへ履歴を残す
- BigQueryの集計層とdashboard JSONを作り、既存ダッシュボードへ表示する
- schema、集計、リンク、自動テスト、デスクトップ・モバイル画面を確認してから本番反映する
最初から全工程を一度にAIへ実行させるのではなく、各段階で確認結果と次の変更内容を出してもらいます。とくにステップ4以降は外部状態が変わるため、人間の承認を挟みます。
最初に整理するMetaの所有・権限
Instagram Graph API連携で最初に詰まりやすいのは、APIコードではなく、Meta上の所有関係です。
Instagramへのログインと、Meta for Developersでアプリを管理する主体は別です。InstagramのIDとパスワードがあっても、それだけで会社のMetaアプリを管理できるわけではありません。
運用では、役割を次のように分けると整理しやすくなります。
| 役割 | 主体 | 理由 |
|---|---|---|
| Developer登録・本人確認 | 実在する担当者のFacebookアカウント | Meta管理画面へのアクセスに必要 |
| Metaアプリの所有 | 会社のBusiness Portfolio | 本番資産を個人所有にしない |
| 運用連絡先 | 業務用共有メール | 担当変更後も通知を受け取る |
| 本番API実行 | システムユーザー | 個人トークンへの依存を減らす |
CodexやClaude Codeには、現状のアセット接続を調べ、足りない設定をチェックリスト化してもらえます。一方、本人確認、Business Portfolioへの参加、FacebookページやInstagramアカウントの承認は、実在する担当者が操作します。
必要な権限は、取得したいKPIから逆算する
今回のFacebook Login方式の実装で使った読み取り権限は、次の4つです。
- instagram_basic
- instagram_manage_insights
- pages_show_list
- pages_read_engagement
投稿作成、コメント管理、DM、広告管理など、運用レポートの取得に不要な権限は追加しませんでした。権限が足りないエラーが出るたびに範囲を広げるのではなく、metric名、APIバージョン、投稿形式、Facebookページとの接続を先に確認します。
実アカウントで小さく確認したところ、interactionsではエラーになり、total_interactionsが正しいmetric名でした。またFeed投稿ではrepliesやnavigationが返らないことがありました。
ここで重要なのは、値が返らなかった状態をすべてゼロにしないことです。実績が0なのか、その投稿形式では非対応なのか、権限不足なのか、metric名が違うのかを分け、available_metricsとunavailable_metricsを保存します。
APIや権限の仕様は更新される可能性があります。この記事では2026年7月21日にMeta公式Instagram API collectionとMeta公式Long-Lived Access Tokenガイドを再確認しました。Instagram APIには接続方式の違いがあり、必要な権限や要件も用途によって異なるため、実装時にも作業時点の公式情報を確認し、参照URLと確認日を残してください。
本番認証はExplorerではなくシステムユーザーを使う
Graph API Explorerは、指標名や権限を小さく試す用途には便利です。しかし、Explorerで生成した一時トークンを日次ジョブへ入れる設計には向きません。
本番では、会社のBusiness Portfolio配下にシステムユーザーを作り、必要な読み取り権限だけを付与します。トークンはSecret Managerへ保存し、実行時にCloud Run Jobへ渡します。
秘密情報は、次の場所へ残さないようにします。
- Codex / Claude Codeとの会話
- Gitリポジトリ
- Cloud Runのログ
- BigQueryのテーブル
- 公開用dashboard JSON
- 公開記事やスクリーンショット
AIにはSecret Managerを参照するコードを実装させられますが、トークンの発行と入力は人間が行います。
Instagram APIからダッシュボードまでの構成
Instagram専用の別システムを新設するのではなく、既存のクライアント別データ基盤へInstagramを追加しました。
APIレスポンスは、画面表示用JSONへ変換する前にrawとして保存します。APIの一時障害、指標追加、集計ルール変更があっても、取得時点のデータから確認・再集計しやすくするためです。
現在の実装では、dashboard JSONは日次同期Jobが当日のAPI取得結果とBigQuery rawに保存済みの投稿・フォロワー履歴を組み合わせて生成します。BigQuery martは分析と整合性確認のための集計層であり、現時点ではdashboard JSONの直接の生成元ではありません。
基本となるデータの粒度は次の通りです。
| 保存先 | 粒度・役割 |
|---|---|
| GCS raw | 実行日時ごとのAPIレスポンス保管 |
| BigQuery account snapshots | 1アカウント × 取得日 |
| BigQuery account daily | 1アカウント × 指標日 |
| BigQuery media snapshots | 1投稿 × 取得日 |
| BigQuery mart | アカウント日次、投稿最新版、表示用サマリー |
| GCS dashboard JSON | クライアント別画面が読む軽量データ |
すべてのデータに会社、クライアント、プラットフォームアカウントを識別するキーを持たせます。投稿データにはmedia_id、投稿形式、公開日時、caption、permalink、thumbnail、reach、views、反応、取得可能・非対応指標を持たせます。
既存基盤がある場合は、AIへ新規構築を依頼する前に、その構造へ統合する案を出させるのがおすすめです。認証、監視、クライアント管理、画面導線を二重化せずに済みます。
ダッシュボードは「取れる数値」ではなく「次の判断」から作る
Instagram Insightsで取得できる指標をすべて表示しても、運用改善にはつながりません。今回は、投稿量、認知、反応、継続接点、EC送客に分けました。
| 見るもの | 主な指標 | 次に決めること |
|---|---|---|
| 投稿量 | 投稿タイプ別の目標・実績 | 次の7日間に何を何本出すか |
| 認知 | reach、Views | どの形式・テーマを増やすか |
| 反応 | 反応率、保存、シェア | どのフックや内容を再現するか |
| 継続接点 | フォロワー純増 | 継続して見たい内容になっているか |
| EC送客 | link taps、UTM、GA4 | EC導線をどう改善するか |
投稿数では、Feed、Carousel、Reel、Storiesの月間目標と実績を分け、次の7日間に必要な本数を表示します。成果では、全投稿合計だけでなく投稿タイプ別や1投稿平均へ切り替えられるようにします。
投稿カードと投稿一覧も役割を分けました。カードはサムネイルから内容を思い出すため、一覧は数値を並べ替えて比較するために使います。
AIはUIを実装できますが、「この数値を見た結果、次の投稿が変わるか」という判断は人間が行います。説明パネルや似た期間指定が重複している場合は、画面上の目的に合わせて削ることも必要です。
グラフでは未来日・欠損・実績ゼロを分ける
未来日の実績を0として描くと、まだ起きていない期間に成果が落ちたように見えます。そのため、実績線は今日で止め、未来日は未確定として扱います。
同様に、次の状態を同じ0へ変換しないことが重要です。
- 実際に実績が0だった
- APIが値を返さなかった
- 投稿形式上、その指標が提供されない
- 権限またはmetric名に問題がある
- まだ取得対象日になっていない
グラフの曲線補間も外しました。元データの点と点の間に滑らかな変化があったように見せないためです。複数系列をすべて初期表示するのではなく、最初は合計など必要最小限に絞ります。
AIの実装後は、モバイル表示までレビューする
実装後は、schema、集計、dashboard JSON、HTML、外部リンク、自動テストを確認します。さらに、デスクトップとモバイルの実画面をブラウザで確認します。
今回、Codexによる1回目のレビューでは、狭い画面でアカウント情報とInstagramリンクの案内が重なる可能性が見つかりました。モバイルでは縦に積むよう修正し、再テストしました。2回目のレビューで追加指摘がないことを確認してから、本番反映、PR作成、マージ、作業ブランチ削除まで進めています。
AI活用では、コードを生成させるだけでなく、実装後に別の視点でレビューさせることが重要です。完了条件に、テスト、画面確認、修正、再確認、作業ブランチの後片付けまで含めます。
Instagramの数値だけでは売上やROASを断定できない
Instagram Graph APIで取得できるオーガニック指標は、運用改善に使える先行指標です。しかし、その情報だけでは、どの投稿が購入につながったか、Instagram経由の売上、CVR、ROASを直接判断できません。
売上との接続には、別途次の流れが必要です。
Instagram内でリーチや反応が伸びた投稿と、EC売上へ貢献した投稿は一致しないことがあります。AIへ分析を依頼するときも、Instagram内の先行指標と売上帰属を分けて扱います。
よくある質問
CodexやClaude Codeだけで完成まで自動化できますか？
調査、設計案、コード実装、テスト、レビューの多くは進められます。ただし、Metaへのログイン、本人確認、2段階認証、Business Portfolio上の承認、トークン生成、秘密情報の入力、本番変更の最終判断は人間が行う必要があります。
個人のInstagramアカウントでも使えますか？
取得したい機能によって対象となるアカウント種別や接続条件が異なります。対象アカウントがBusinessまたはCreatorか、Facebookページと正しく接続されているかを先に確認し、作業時点のMeta公式ドキュメントで要件を確かめてください。
Graph API Explorerのトークンを日次処理に使えますか？
初期確認には使えますが、本番の日次処理には推奨しません。会社のBusiness Portfolio配下にシステムユーザーを作り、最小権限のトークンをSecret Managerなどの秘密情報管理へ保存する構成が扱いやすくなります。
BigQueryは必須ですか？
小規模な確認だけなら必須ではありません。ただし、取得履歴を残し、過去値を再集計し、複数アカウントやECデータと接続する場合は、BigQueryのような分析用データベースがあると運用しやすくなります。
Instagram投稿からECの売上まで見られますか？
Instagram Graph APIだけでは直接の購入帰属はできません。UTM付きリンク、GA4、ECの注文データを接続し、期間やキャンペーン単位で集計する別フェーズが必要です。
まとめ
Codex / Claude CodeのようなAIコーディングエージェントを活用すると、Instagram Graph APIの調査、GCS・BigQueryへの保存、Cloud Run Jobによる日次取得、ダッシュボードUI、テスト、レビューまでを対話しながら進められます。
実際の構築ではCodexを使い、既存のD2C基盤へInstagramデータを統合しました。重要だったのは、AIへ一発完成を求めず、読み取り専用の現状確認、必要権限の整理、小さなAPIプローブ、段階的な実装、画面レビューの順で進めたことです。
AIに任せる範囲を広げても、Metaの認証、秘密情報、本番反映、KPIの意味付けは人間が担います。この役割分担ができれば、手作業で作っていたInstagram運用レポートを、日次で更新される改善基盤へ変えることができます。