【初心者版手順付き】codeXでトレンド投稿の収集分析自動化を作ってみた
最近、codeXの基本的な使い方を少しずつ触り始めて、なんとなくですが「どういう順番で頼めばいいのか」は見えてきました。
もちろん、まだコードを書けるわけではありません。
エラーが出たら普通に止まるし、ターミナルやAPIまわりの言葉も、毎回調べながら進めています。
ただ、最初の頃よりは少しだけ考え方が変わりました。
前は、codeXに対していきなり
「これを自動化して」
「こういうツールを作って」
「いい感じに実装して」
みたいに頼めば進むと思っていました。
でも実際に触ってみると、たぶんそれだとかなり危ないです。
何を集めたいのか。
どこから情報を取るのか。
どの項目を記録するのか。
どうやってスプレッドシートに残すのか。
何を見たら「伸びている投稿」と判断するのか。
このあたりを自分が整理できていないと、codeXに頼んでも、途中で方向がズレる可能性が高いと感じました。
今回やりたいのは、Xのトレンドやバズっている投稿を収集して、あとから分析できる形にする仕組みです。
なぜこれをやりたいかというと、X運用を感覚だけで続けるのは限界があるからです。
「なんとなくこの投稿が伸びそう」
「この言い回しは最近よく見る」
「こういう画像がバズっている気がする」
こういう感覚は大事だと思います。
ただ、それだけだと再現性がありません。
実際に伸びている投稿を集めて、
投稿文、テーマ、言い回し、画像の有無、投稿時間、反応数、アカウントの特徴などを見ていけば、少しずつ「伸びやすい型」が見えてくるかもしれません。
もちろん、Xの投稿を集める方法には注意が必要です。
APIを使うのか、手動でURLを集めるのか、公開情報の範囲でどう扱うのか。
ここを雑に進めると、あとから使えない仕組みになる可能性があります。
なので今回は、いきなり実装に入るのではなく、まずは
「何を作りたいのか」
「どんなデータが必要なのか」
「codeXにどの順番で頼めばよさそうか」
「初心者がどこで詰まりそうか」
を整理してから進めます。
完成形としては、Xで見つけたトレンド投稿や参考投稿をスプレッドシートに蓄積し、あとから分析できる状態を目指します。
たとえば、こんな情報を残せると便利そうです。
投稿日
投稿URL
アカウント名
投稿文
いいね数
リポスト数
返信数
表示回数
投稿ジャンル
使われている言い回し
画像や動画の有無
なぜ伸びたのかのメモ
自分の投稿に活かせそうなポイント
まだ最初から完璧なものを作るつもりはありません。
まずは、集める → 整理する → 見返せる状態にするところまでを目標にします。
そのうえで、慣れてきたら
バズ投稿の共通点を分類する
投稿文の型を抽出する
自分の投稿案に落とし込む
反応が出た投稿と比較する
ダッシュボード化する
という流れに広げていければよさそうです。
この記事では、その第一歩として、
Xのトレンド収集分析をcodeXで実装する前に、初心者なりに整理したことを書いていきます。
まだ「完全に作れました」という記事ではありません。
むしろ、作る前に考えておかないと詰まりそうなことを先に洗い出す記事です。
自分と同じように、
「X運用を感覚だけで終わらせたくない」
「バズっている投稿を分析して、自分の投稿に活かしたい」
「codeXで何か実務っぽい仕組みを作ってみたい」
「でも、いきなり実装と言われると何から始めればいいかわからない」
という人には、たぶん近い内容になると思います。
まず最初にやったのは、ローカル環境に作業用フォルダを作ることです。
今回は、Windowsのローカル上に以下のようなフォルダを作りました。
C:\Users\user\X-trend正直、最初は
「フォルダを作るだけなら、わざわざ記事に書くほどでもないのでは？」
と思いました。
でも、codeXを使って作業してみると、ここは意外と大事でした。
理由は、作業場所が決まっていないと、ファイルがどこに作られたのかわからなくなるからです。
codeXに何かを作ってもらうときは、
どのフォルダで作業するのか
どこにファイルを保存するのか
どのファイルを編集するのか
を明確にしておかないと、あとから自分が迷います。
特に初心者の場合、コードの中身以前に、
**「今どこで何をしているのか」**がわからなくなるのが一番危ないです。
なので、最初に作業フォルダを作っておくのは、地味ですがかなり重要だと感じました。
① ローカルに作業フォルダを作る
まず最初に、ローカル環境に作業用フォルダを作ります。
今回は、Windows上に以下のフォルダを作りました。
C:\Users\user\X-trend最初は「フォルダを作るだけ」と思っていました。
でも、codeXで作業していると、保存場所を決めておくことはかなり大事です。
理由は、ファイルが増えてきたときに、
どこに何があるのかわからなくなるからです。
初心者の場合、コードの中身よりも先に、
「今どこのフォルダで作業しているのか」
がわからなくなりやすいです。
なので、最初に作業場所を固定します。
今回であれば、フォルダ名はシンプルにしました。
X-trend変にかっこいい名前をつけるより、
あとから見ても何をするフォルダかわかる名前の方が安全です。
② 先に完成仕様を決める
ここが今回、一番大事だと思ったところです。
最初はAGENTS.mdを作る前に、ざっくり「Xのトレンド投稿を集めたい」とだけ考えていました。
でも、それだと広すぎます。
codeXにとっても、自分にとっても、判断基準が曖昧になります。
なので、最初に完成仕様を決めます。
今回作りたいものは、単にXの投稿を集めるツールではありません。
目的は、
バズっている投稿の共通点を集めて、GPTに渡し、自分の投稿作成に活かすこと
です。
つまり、最終的に欲しいのは「投稿データ」だけではなく、
バズる投稿を作るための判断材料です。
また、後で詳しく書くのですが、X APIは使わずにYahoo!リアルタイム検索経由でXのトレンドを収集していきます。
今回の完成仕様
今回の仕様は、以下のように整理しました。
| 項目 | 内容 |
| ------ | ------------------------------------- |
| 目的 | Xで反応が大きい投稿・トレンドを収集し、投稿作成に活かす |
| 取得元 | X APIではなく、Yahoo!リアルタイム検索を使う方向 |
| 対象期間 | 直近1週間の投稿 |
| 対象ジャンル | AIに絞らず、スポーツ、健康、おもしろ系、美容、食べ物など幅広く見る |
| 抽出条件 | インプレッション数10万以上、かつ、いいね数1000以上 |
| 保存先 | Googleスプレッドシート |
| シート構成 | 週ごとのシート＋全体蓄積シート |
| 表示言語 | シート名・見出しは日本語 |
| 目的 | GPTが読み込んだときに、トレンド傾向と投稿作成のヒントがわかる状態にする |ここで重要なのは、
「数値条件」と「使い道」を先に決めることです。
ただ大量に投稿を集めても、あとから見返せなければ意味がありません。
逆に、最初から
インプレッション数 > 100000
いいね数 > 1000
直近1週間
ジャンル問わず
GPTが理解しやすい形で保存と決めておけば、codeXに作ってもらう内容もかなり明確になります。
スプレッドシートに入れたい情報
次に、スプレッドシートにどんな情報を入れるかを決めます。
ここを後回しにすると、かなり手戻りになります。
今回入れたい項目は、以下です。
| 見出し | 内容 |
| ----------- | ----------------------- |
| 取得日 | データを取得した日 |
| 対象週 | どの週のデータか |
| ジャンル | スポーツ、健康、美容、食べ物、おもしろ系など |
| 検索キーワード | Yahoo!リアルタイム検索で使ったキーワード |
| 投稿者名 | 投稿したアカウント名 |
| 投稿URL | 投稿のURL |
| 投稿文 | 実際の投稿本文 |
| 投稿日時 | 投稿された日時 |
| インプレッション数 | 表示回数 |
| いいね数 | いいね数 |
| リポスト数 | リポスト数 |
| コメント数 | コメント数 |
| 判定 | 条件を満たしたか |
| 投稿の構成 | 冒頭、本文、オチ、CTAなどの構造 |
| 反応された理由 | なぜ伸びたと考えられるか |
| 見た人の感情 | 驚き、共感、笑い、不安、納得など |
| 使われている型 | まとめ型、対比型、あるある型、権威型など |
| 自分の投稿に使える要素 | 自社投稿へ応用できそうなポイント |
| GPTに渡す要約 | GPTが読みやすいように整理した文章 |
ここまで決めておくと、単なるデータ収集ではなくなります。
投稿作成に使うための分析データになります。
シート構成も最初に決める
スプレッドシートのシート名も、最初に日本語で決めておきます。
英語のままだと、UIとしてわかりづらくなります。
特に、あとから自分が見る場合や、社内で共有する可能性がある場合は、日本語の方が扱いやすいです。
今回のシート構成は、以下のようにします。
| シート名 | 役割 |
| -------------- | ------------------- |
| 使い方 | このスプレッドシートの見方を書く |
| 今週の収集結果 | 直近1週間で条件を満たした投稿を入れる |
| 週別_2026年05月第2週 | 週ごとの保存用シート |
| 全体蓄積 | すべての週のデータを残す |
| ジャンル別まとめ | ジャンルごとの傾向を見る |
| キーワード別まとめ | どのキーワードが伸びているかを見る |
| GPT入力用 | GPTに渡しやすい文章形式に整えた内容 |
| 実行ログ | いつ取得したか、エラーがあったかを残す |
最初からシート構成を決めておけば、
あとで「このデータはどこに入れるのか」で迷いにくくなります。（実際後で迷いました…）
③ AGENTS.mdを作る
完成仕様を決めたら、次にAGENTS.mdを作ります。
AGENTS.mdは、ざっくり言うと、
codeXにこのプロジェクトの前提や作業ルールを伝えるためのファイルです。
ここで、さっき決めた仕様をcodeXに渡します。
指示文は、以下のようにしました。
このプロジェクトでは、Xで反応が大きいトレンド投稿を収集し、Googleスプレッドシートのレポートとダッシュボードを作ります。
目的は、バズっている投稿の共通点を分析し、GPTに渡せる形で整理して、自分のX投稿作成に活かすことです。
取得元は、X APIではなくYahoo!リアルタイム検索を使う方向で検討します。
抽出条件は、直近1週間の投稿のうち、インプレッション数が100000以上、かつ、いいね数が1000以上の投稿です。
対象ジャンルはAIに限定せず、スポーツ、健康、おもしろ系、美容、食べ物など幅広く収集します。
スプレッドシートのシート名と見出しは、日本語でわかりやすくしてください。
週ごとのシートと、全体蓄積シートを作成してください。
GPTが読み込んだときに、トレンドの傾向、投稿の構成、見た人の感情、バズった理由、自分の投稿に応用できる要素がわかる構成にしてください。
APIキー、サービスアカウントJSON、.env.localなどの重要情報は、コードに直接書かず、secretsフォルダまたは環境変数で管理してください。
今後の作業ルールも含めて、AGENTS.mdのたたき台を作ってください。
C:\Users\user\X-trend のフォルダに保存してください。最初に書いた指示より、かなり長くなりました。
でも、このくらい書いた方がいいと思いました。
理由は、目的や条件が曖昧なままだと、後でコードもスプレッドシートも直すことになるからです。
特に今回のように、
GPTに渡す前提のデータを作る場合、ただ数値を保存するだけでは足りません。
投稿の構成や、見た人の感情、反応された理由まで残す必要があります。
④ 作業プランを出してもらう
AGENTS.mdを作ったら、いきなり実装させるのではなく、先に作業プランを出してもらいます。
ここで確認したいのは、以下です。
どんな手順で進めるか
どんなファイルを作るか
どのAPIを使うか
Yahoo!リアルタイム検索からどう取得するか
Googleスプレッドシートにどう保存するか
認証情報をどう扱うか
毎日8時にどう実行するか
どこまでを自動化し、どこを人間が確認するか
codeXには、以下のように伝えます。
AGENTS.mdの内容を前提に、実装前の作業プランを作成してください。
以下を必ず整理してください。
1. どんな手順で進めるか
2. どんなファイルを作るか
3. Yahoo!リアルタイム検索からどのように情報を取得するか
4. Google Sheets APIとGoogle Drive APIをどのように使うか
5. スプレッドシートのシート構成と日本語見出し
6. インプレッション数100000以上、かつ、いいね数1000以上で絞り込む方法
7. 直近1週間の投稿だけを対象にする方法
8. GPTが理解しやすい要約列をどう作るか
9. APIキーやサービスアカウントJSONを安全に管理する方法
10. 毎日8時に自動実行する方法
11. 人間が確認すべきポイント
まだ実装は始めず、まず計画だけを出してください。ここで大事なのは、
「まだ実装しないでください」と伝えることです。
初心者の場合、いきなりファイルを大量に作られると、追えなくなります。
まずは計画を出してもらい、自分が理解できるか確認します。
⑤ 取得方法を決める：X APIではなくYahoo!リアルタイム検索
当初はX APIを使う予定でした。
ただ、調べていくと、X APIは料金や利用条件の面でハードルがありました。
今回の目的は、X APIを使いこなすことではありません。
やりたいのは、
反応されている投稿の傾向を見て、自分の投稿改善に使うこと
です。
そのため、最初の検証段階では、X APIを使わず、Yahoo!リアルタイム検索を使う方向に変更します。
codeXには、以下のように伝えます。
X APIを使わずに、Yahoo!リアルタイム検索で数多くのX反応確認をしたい仕様にしてください。
ただし、利用規約やアクセス頻度に注意し、過剰なアクセスをしない設計にしてください。
取得できない情報がある場合は、無理に推測せず、取得不可として記録してください。ここは注意が必要です。
Yahoo!リアルタイム検索を使う方法は、X APIとは違います。
そのため、以下のリスクがあります。
リスク内容表示変更に弱いページ構造が変わると取得できなくなる可能性がある取得情報に制限があるインプレッション数など、表示されない情報は取得できない利用規約確認が必要自動取得してよい範囲の確認が必要アクセス頻度に注意短時間に大量アクセスしない設計が必要推測禁止見えない数値を勝手に補完しない
ここで無理に自動化しすぎると危ないです。
なので、取得できないものは取得できないと記録する。
この方針にしておいた方が安全です。
⑥ Googleスプレッドシート側の準備をする
次に、抽出したデータを保存するためのスプレッドシートを作ります。
ここでは、Google Cloud Consoleで準備が必要です。
流れは以下です。
1. Google Cloud Consoleでプロジェクトを作成、または選択
2. Google Sheets APIを有効化
3. Google Drive APIを有効化
4. サービスアカウントを作成
5. サービスアカウントキーをJSON形式で作成
6. JSONファイルを安全な場所に保存
7. スプレッドシートまたはDriveフォルダをサービスアカウントに共有今回、Google Sheets APIを有効にする画面は、以下のようなURLから開きました。
https://console.cloud.google.com/apis/library/sheets.googleapis.com?project=x-trend-496306Google Sheets APIは、スプレッドシートに読み書きするために必要です。
Google Drive APIは、Drive上のファイルやフォルダを扱う場合に必要になります。
最初は、
「スプレッドシートに保存するだけなのに、なぜGoogle Cloud Consoleが必要なのか」
と思いました。
でも、整理するとやっていることはこうです。
codeXからGoogleスプレッドシートを編集するための許可を作っている。
人間がスプレッドシートを編集するときは、自分のGoogleアカウントでログインします。
でも、プログラムから自動で書き込む場合は、人間が毎回ログインするわけではありません。
その代わりに、サービスアカウントという仕組みを使います。
⑦ 認証情報と環境変数を安全に保存する
サービスアカウントを作成したら、キーを作成します。
手順は以下です。
IAMと管理
↓
サービスアカウント
↓
新規サービスアカウントを作成
↓
作成したサービスアカウントを選択
↓
キー
↓
新しいキーを追加
↓
JSON形式でダウンロードダウンロードしたJSONファイルには、Google APIにアクセスするための重要な情報が入っています。
なので、コードに直接書いてはいけません。
今回は、以下の場所に保存する想定にします。
C:\Users\user\X-trend\secrets\google-service-account.jsonそして、.env.local に必要な情報を書きます。
例としては、以下です。
GOOGLE_APPLICATION_CREDENTIALS=C:\Users\user\X-trend\secrets\google-service-account.json
SPREADSHEET_ID=xxxxxxxxxxxxxxxxxxxxさらに、.gitignore に以下を追加します。
secrets/
.env.localこれはかなり大事です。
APIキーやJSONファイルをGit管理に入れると、外部に漏れる危険があります。
初心者の場合、エラーよりもこの事故の方が怖いです。
codeXにも、以下のように明確に伝えます。
APIキー、サービスアカウントJSON、.env.localはコードに直接書かないでください。
secretsフォルダと.env.localはGit管理に入れないように、.gitignoreに追加してください。⑧ スプレッドシートをサービスアカウントに共有する
JSONファイルを保存しただけでは、まだスプレッドシートには書き込めません。
次に、スプレッドシートをサービスアカウントに共有します。
JSONファイルの中に、以下の項目があります。
client_emailこのメールアドレスをコピーして、保存先にするGoogleスプレッドシートに共有します。
権限は「編集者」にします。
流れは以下です。
1. JSONファイル内の client_email を確認する
2. Googleスプレッドシートを開く
3. 共有ボタンを押す
4. client_email のメールアドレスを追加する
5. 編集者として共有するこの共有を忘れると、codeX側のコードが正しくても、スプレッドシートに書き込めません。
初心者だと、こういうときに
「コードが間違っているのか、権限がないのか」
がわかりづらいです。
なので、ここは必ず作業メモに残した方がいいです。
⑨ 抽出・保存・判定ルールを実装する
ここまで準備して、ようやく実装に入ります。
ただし、ここでも一気に全部作るのではなく、段階を分けます。
最初に作るべき流れは、以下です。
1. Yahoo!リアルタイム検索から検索結果を取得する
2. 投稿情報を抽出する
3. 数値情報を取得する
4. 直近1週間の投稿に絞る
5. インプレッション数100000以上、かつ、いいね数1000以上に絞る
6. 投稿文の構成を分析する
7. 見た人の感情や反応理由を整理する
8. Googleスプレッドシートに保存する
9. 全体蓄積シートにも追記する
10. GPT入力用シートに要約するここで気をつけるべきなのは、
見えない数値を推測しないことです。
たとえば、Yahoo!リアルタイム検索上でインプレッション数が見えない場合、
その投稿を無理に条件判定してはいけません。
その場合は、以下のように記録する方が安全です。
インプレッション数：取得不可
判定：対象外または要確認「たぶん伸びている」では、分析データとして弱くなります。
今回作りたいのは、なんとなくの感覚ではなく、
あとから見返して判断できるデータです。
なので、取得できた情報と取得できなかった情報は分けておきます。
⑩ 毎日8時に自動実行する
ある程度動くようになったら、毎日8時に自動でチェックされるようにします。
Windowsであれば、タスクスケジューラを使う形が考えられます。
ただし、ここもいきなり完全自動化しすぎない方がいいです。
理由は、取得結果やAIの判定が毎回正しいとは限らないからです。
特に、投稿の構成や「見た人がどう思ったか」の分析は、AIの推論が入ります。
そのため、最初は以下の運用にします。
毎日8時に自動収集
↓
スプレッドシートに保存
↓
実行ログを残す
↓
人間が結果を確認
↓
明らかにおかしい分析や分類を修正完全に任せるのではなく、
収集は自動、判断は人間が確認
という形です。
codeXには、以下のように伝えます。
毎日8時に自動実行できるようにしてください。
ただし、AIによる分類や推論は必ず正しいとは限らないため、実行ログと要確認フラグを残してください。
取得できない情報、判定が不確かな情報、数値条件を満たしているか判断できない投稿は、要確認としてスプレッドシートに記録してください。これで、あとから見たときに、
どこまでが確定データで、どこからがAIの推論なのかを分けられます。
初心者向けに一言でいうと
今回やっていることを初心者向けに一言でいうと、
Xで伸びている投稿をただ集めるのではなく、GPTが使いやすい分析データとして保存する仕組みを作っている
ということです。
ただ投稿を集めるだけなら、手作業でもできます。
でも、それだと数が増えたときに見返せません。
今回の目的は、投稿を集めること自体ではありません。
目的は、集めた投稿から、
どんなテーマが伸びているのか
どんな言い回しが使われているのか
どんな構成が反応されやすいのか
見た人はなぜ反応したのか
自分の投稿にどう応用できるのか
を考えられる状態にすることです。
そのためには、最初に仕様を決める必要がありました。
特に大事なのは、以下です。
何を集めるか
どの条件で残すか
どこに保存するか
どんな見出しで整理するか
GPTにどう渡すか
どこまで自動化するか
どこを人間が確認するかここを後回しにすると、あとから修正が増えます。
逆に、最初にここまで決めておけば、codeXに依頼する内容もかなり具体的になります。
今回の反省
今回の反省は、
「最後に調整するつもりだった条件ほど、本当は最初に決めるべきだった」
ということです。
特に、インプレッション数やいいね数の下限、シート構成、GPTに渡す形式は、後から足すとコード全体に影響します。
なので、最初の段階で決めた方がいいです。
次から使える判断基準
codeXでこういう分析ツールを作るときは、最初に以下を確認するとよさそうです。
□ 作業フォルダは決まっているか
□ 完成形のスプレッドシートを先に想像できているか
□ 取得したい数値は明確か
□ 抽出条件は明確か
□ 対象期間は決まっているか
□ 対象ジャンルは決まっているか
□ シート名・見出しは日本語で整理されているか
□ GPTに渡すための要約列があるか
□ APIキーや認証情報をコードに直接書かない設計になっているか
□ 自動実行後に人間が確認する場所があるか
□ 取得不可・要確認のデータを分けて保存できるかこのチェックをせずに進めると、
あとから「この列も必要だった」「この条件で絞りたかった」となりやすいです。
自動化で時間を減らしたいのに、仕様変更で時間を使っていたら本末転倒です。
次に試すこと
ここまでで、ようやく実装の前提が整理できました。
次に試すことは、以下です。
1. Yahoo!リアルタイム検索から実際に情報を取得できるか確認する
2. 取得できる数値と取得できない数値を分ける
3. 直近1週間の投稿だけに絞れるか確認する
4. インプレッション数100000以上、いいね数1000以上で抽出できるか確認する
5. Googleスプレッドシートに日本語見出しで保存する
6. GPT入力用シートに要約形式で出力する
7. 毎日8時に実行できるようにする
8. 実行結果を人間が確認し、分類や推論のズレを修正するまだ完成ではありません。
むしろここからが実装です。
ただ、最初に仕様を整理したことで、
何を作ればいいのかはかなり見えやすくなりました。
今後はこの流れに沿って、
まずは小さく動くものを作り、取得結果を見ながら改善していきます。
次のステップでは初心者がつまづきやすい「レート制限」について書いています。
これを学習しておくだけで、使い方が劇的に変わります。
