AI Image Trend Labとは何か——0件と通信失敗から、AI画像トレンド収集を「研究」に変えるまで
AI Image Trend Labとは何か
AI Image Trend Labは、X上のAI画像投稿を継続的に観測し、画像の特徴、投稿文、エンゲージメントを分析して、次に試す制作仮説へ変換するオープンリサーチプロジェクトです。
AI Continuity LabのResearch Project #002として、2026年8月に開始しました。
出発点にあったのは、次の問いです。
AIを使って、Xで反応を集めているAI画像の傾向を継続的に観測できないか。
AI画像の世界では、「この構図が伸びている」「今はこのテーマが強い」といった話が日々流れます。しかし、それが一部の目立つ投稿から受けた印象なのか、一定の条件で繰り返し観測できる傾向なのかは、簡単には区別できません。
そこで、公開投稿のサンプルを一定の条件で収集し、構図、被写体、衣装、背景、光、カメラ位置などを記録する仕組みを作り始めました。
目的は、人気投稿をそのまま複製することではありません。
どのような視覚要素や投稿設計が反応につながっている可能性があるのかを観測し、制作仮説として整理し、次の検証へ渡すことです。プロジェクトの短い言葉では、これを「市場を観測し、創作を進化させる」と表しています。
なぜ「AI Image Trend Lab」と名付けたのか
この名称は、研究対象と進め方を4つの言葉で表したものです。
AI
対象は、AIによって生成・制作された画像と、その周辺で起きている創作活動です。また、収集や整理、分析にもAIを利用します。
ただし、AIが出した答えをそのまま事実として採用するわけではありません。AIによる判定や画像解釈には推定が含まれるため、観測できた事実とAIの推定を分けて記録します。
Image
対象を広いSNSトレンド全般ではなく、「画像投稿」に絞っています。
投稿文やエンゲージメントだけでなく、人物数、構図、画角、カメラ位置、衣装、背景、光、表情といった視覚的な特徴を扱うためです。
Trend
ここでいうTrendは、単発の人気投稿やランキングそのものではありません。
限られた観測サンプルの中で、どの特徴が繰り返し現れるのか、取得する時期や経路を変えても同じ傾向が残るのかを検証する対象です。「流行を断定する」のではなく、「流行の兆候を観測する」という位置づけです。
Lab
MediaやRankingではなくLabとしたのは、完成した答えを配信する場所ではなく、仮説を立て、条件を固定し、結果を記録する実験室として運営するためです。
うまく取得できた結果だけでなく、0件、通信失敗、仕様差異、仮説を支持しなかった結果も残します。外れや失敗を消さず、次の実験設計へ引き継ぐことが、Labという名前の中心にあります。
そして、母体であるAI Continuity Labの「継続」という考え方も引き継いでいます。一度のバズ分析で終わらせず、観測、仮説、検証、判断を連続させるための研究プロジェクトです。
この研究が目指すもの
AI Image Trend Labが目指しているのは、「今週はこの画像がバズった」という事例紹介だけではありません。検索条件、取得経路、失敗、費用、重複、再現性まで記録し、次の観測に引き継げる研究資産へ変えることです。
しかし、APIをつなげればすぐにデータが集まるほど単純ではありませんでした。
- 検索は正常に動いたのに、取得結果は0件
- 通信がタイムアウトし、データ自体を取得できない
- 実行は成功したが、事前に定めた記録仕様と一致しない
- 追加投稿は取得できたが、費用は基準経路より高い
- 別期間でも同じ傾向が見えたが、長期的な再現性はまだ分からない
この記事では、EXP-0005からEXP-0008までの実験結果と、EXP-0009の事前登録までを時系列で振り返ります。
成功した部分だけではなく、成立しなかった比較、通信失敗、実行前に止まったケース、部分的にしか検証できなかった条件もそのまま扱います。
なお、本記事で扱うのは限定された条件で取得した検索サンプルです。X全体を網羅した分析ではありません。また、公開成果物にはAPIキー、非公開のcreator list、第三者の投稿本文・投稿URL・画像URLを含めていません。
3つの収集経路
データ収集では、主に次の3経路を試しました。
| 経路 | 役割 |
|---|---|
explicit_ai_keyword | AIに関する明示的なキーワードを含む投稿を探す |
known_ai_creator | あらかじめ固定した既知のAIクリエイター群から探す |
visual_context_candidate | テキストだけでは拾いにくい視覚的な文脈から候補を探す |
3経路は、同じ投稿を別の方法で探すだけの単純な代替関係ではありません。
事前のPoCでは、3経路を統合すると単純合計29件、重複除去後27件になりました。known経路が取得した9件は、すべて他経路と重複しませんでした。一方、APIによる27件と手動収集による25件を比較すると、共通は5件、unionは47件、Jaccard similarityは10.64%でした。
この低い一致率を、すぐに「APIの品質が悪い」とは判断しませんでした。検索タイミングや検索戦略が異なるためです。むしろ、APIと手動が異なる観測集合を補完している可能性がありました。
そこで、複数日で条件をそろえ、API収集に対して手動作業がどれだけ追加価値を生むかを測る計画を立てました。それがEXP-0005です。
EXP-0005：比較実験が成立しなかった日
EXP-0005の当初案は、3日間にわたってAPI収集と手動収集を繰り返すものでした。
ただし、いきなり3日分を実行するのではなく、まずDay 1だけを縮小版として承認しました。API側は3経路それぞれ最大10件。手動収集は合計最大60分とし、API結果を事前に見ずに独立して収集する設計です。
Day 1の対象期間は、2026年8月4日0時から8月5日0時までの24時間でした。
結果は次のとおりです。
| 経路 | 結果 |
|---|---|
| explicit | X SearchとSchema検証まで正常終了したが0件 |
| known | 正式実行と同一条件retryの両方で通信失敗 |
| visual | 正式実行と同一条件retryの両方で通信失敗 |
ここで重要なのは、「0件」と「通信失敗」を分けることです。
explicit経路は、API実行とX Searchが成立したうえで、条件に合う投稿が0件でした。記録上はvalid_empty_resultです。これは有効な観測結果です。
一方、known経路とvisual経路は、検索結果が0件だったのではありません。通信が完了せず、結果を評価できませんでした。正式実行に加えて、それぞれ同一設定で1回retryしましたが、どちらも失敗しました。
正式実験外の診断では、known経路でtimeoutを90秒に延ばしても、read timeoutが確認されました。その後、エラーの種類、理由、試行回数、timeout秒数を記録できるよう診断情報を改善しました。
手動収集を実施しなかった理由
EXP-0005の本来の目的は、API収集に対して最大60分の手動作業がどれだけ追加価値を生むかを測ることでした。
しかし、API側で正常に終わったのは3経路中1経路だけで、その結果も0件です。この状態で手動収集を行っても、「APIと手動の比較」として結果を解釈できません。
そこで、手動収集とAPI対手動比較は実施しないと判断しました。Day 2とDay 3も承認せず、開始していません。
EXP-0005はcompleted_partialで終了しました。
- API報告実費：0.0113556 USD
- fallback込みの管理上累積費用：0.5496084 USD
- formal failure：4回
- formal retry：2回
- contaminated：false
「データが足りないまま比較結果を作る」のではなく、比較目的そのものを評価不能と記録した形です。
EXP-0005から得た次の問い
known経路とvisual経路は、事前のPoCではデータ取得に成功していました。それでもEXP-0005では通信に失敗しました。
この段階では、「経路に価値がない」とも「一時的な通信問題だった」とも断定できません。
そこでEXP-0005をそのまま繰り返すのではなく、問題を分けました。次に確認すべきなのは、known経路が固定条件で運用上正常に完了できるかどうかです。
EXP-0006：known経路は技術的に動くのか
EXP-0006では、API対手動比較も他経路との比較も行いませんでした。
目的は一つです。
固定したcreator listとAPI条件のもとで、known経路が正常に完了できるか。
対象期間は、2026年8月3日0時から8月6日0時までの72時間です。取得上限は5件、timeoutは180秒、retryは0回に固定しました。
結果、known経路は5件を取得しました。
| 指標 | 結果 |
|---|---|
| 取得件数 | 5件 |
| X Search | 7回 |
| total tokens | 31,981 |
| API報告費用 | 0.1125492 USD |
| Schema検証 | 成功 |
| formal retry | 0回 |
通信エラーはなく、費用上限0.34 USDにも収まりました。この結果から、known経路の技術成立性は運用上確認できたと判断しました。
ただし、形式的には完全検証済みとしていません。
動作成功と完全検証は同じではない
事前に定めた成功条件と実行記録の間に、2つの差異がありました。
- 事前基準ではstageを
valid_resultまたはvalid_empty_resultとしていたが、実行recordにはcompletedと保存された - recordに
elapsed_secondsがなく、180秒以内の完了をrecord単独では確認できなかった
取得結果、Schema、検索実行、費用については確認できています。しかし、事前条件のすべてを記録だけで形式検証できたわけではありません。
そのため、EXP-0006の結果は次のように分けました。
- 技術成立性：
confirmed_operationally - 形式的な受け入れ：
partially_verified - データ汚染：なし
この区別により、「実際には動いた」という観測と、「定義した成功条件を完全に証明できた」という評価を混同せずに済みました。
次は、known経路が動くかどうかではなく、explicit経路にない投稿を追加できるかを測ります。
EXP-0007：known経路に追加価値はあるのか
EXP-0007では、explicitとknownを同じ72時間、同じ取得上限、同じモデル設定で実行しました。
対象期間は2026年8月4日0時から8月7日0時まで。各経路のlimitは5件です。経路固有の差分は、検索promptとknown creator listだけに限定しました。
研究上の問いは明確です。
known経路は、explicit経路では取得できない投稿を1件以上追加できるか。
結果は次のとおりでした。
| 指標 | explicit | known |
|---|---|---|
| 取得件数 | 3件 | 5件 |
| 独自件数 | 3件 | 5件 |
| X Search | 1回 | 7回 |
| 実行時間 | 24秒 | 37秒 |
| API報告費用 | 0.0234012 USD | 0.0912572 USD |
| 独自投稿1件あたり費用 | 0.0078004 USD | 0.01825144 USD |
両経路の重複は0件、unionは8件、Jaccard similarityは0でした。known経路は、explicit経路では取得されなかった投稿を5件追加しました。
事前に定めたknown_unique_count >= 1を満たしたため、この72時間窓ではknown経路の増分価値をobservedとしました。
追加価値はあったが、すぐには採用しなかった
known経路は5件すべてが独自投稿でした。一方で、独自投稿1件あたりの費用はexplicitより高くなりました。
さらに、この結果は一つの72時間窓、各5件という小さな条件での観測です。長期的な再現性、投稿品質、毎週運用した場合の費用対効果、creator listの網羅性までは分かりません。
そのため、運用への常設採用はdeferred_pending_replication、つまり別期間での再現確認まで保留としました。
実行前に一度止まった記録も残した
known経路の正式実行前、新しいシェルでAPIキーが設定されておらず、処理が一度停止しました。
ただし、APIリクエストは送信されておらず、費用も発生していません。formal retryも消費せず、条件変更もありません。環境変数を再設定したあと、承認済みの条件で正式実行しました。
これは実験結果の失敗ではありませんが、再現可能な運用を考えるうえでは重要な出来事です。そのため、pre-request blockとして記録しました。
EXP-0008：別の72時間窓でも追加価値は見えるか
EXP-0008では、EXP-0007で観測したknown経路の追加価値が、重複しない別の72時間窓でも観測されるかを1回だけ確認しました。
観測期間は2026年8月1日0時から8月4日0時までです。EXP-0007の観測窓は8月4日0時から8月7日0時までなので、境界時刻は共有しますが、半開区間としてデータは重複しません。
実験番号ではEXP-0008が後ですが、使用した観測期間はEXP-0007より前です。そのため、ここで確認したのは「後の期間での再現」ではなく、「重複しない別期間での再現」です。
limit、モデル、推論設定、tool choice、timeout、retry方針、経路順序、creator listはEXP-0007と同じ条件に固定しました。
結果は次のとおりです。
| 指標 | explicit | known |
|---|---|---|
| 取得件数 | 5件 | 5件 |
| 独自件数 | 5件 | 5件 |
| 実行時間 | 69.441198秒 | 60.580319秒 |
| API報告費用 | 0.0991748 USD | 0.1038292 USD |
| 独自投稿1件あたり費用 | 0.01983496 USD | 0.02076584 USD |
重複は0件、unionは10件、known incremental rateは0.5でした。
主要判定条件known_unique_count >= 1に対し、known独自件数は5件です。したがって、EXP-0007で観測されたknown経路の増分価値は、独立した別の72時間窓でもobservedと判定しました。
dry-runで見つかったcreator list読み込み問題
EXP-0008でも、正式実行前に一度blockが発生しました。
creator listを実行環境へ渡す手順が、ファイル内のコメント行を受け付けなかったためです。これはdry-runの検証段階で止まり、APIリクエストは送られていません。formal executionもretryも消費していません。
読み込み手順を監査したうえで、prompt、creator list、limit、期間、判定条件を変えずに正式実行しました。最終結果はcontaminated: falseです。
実行前の検査で止められたこと自体が、preflightを設けた意味でもあります。
なぜ「再現した」と言いながら恒久採用しなかったのか
EXP-0007とEXP-0008では、互いに重複しない2つの72時間窓で、known経路がexplicit経路に含まれない投稿を取得しました。
これは重要な観測です。しかし、ここから「known経路はいつでも有効」「今後は必ず常設すべき」と結論づけることはできません。
実験結果と判断を分けると、次のようになります。
| 区分 | 2026年8月8日時点の内容 |
|---|---|
| 観測事実 | 2つの非重複72時間窓でknown独自投稿を取得した |
| 実験上の判定 | incremental value replication=observed |
| 運用上の解釈 | known route=operational_candidate |
| 未確認 | long-term reproducibility |
| 採用判断 | permanent baseline adoption=deferred |
| visual route | hold |
operational_candidateは、「通常運用へ組み込む価値がある候補」という意味です。恒久的なベースラインとして採用したという意味ではありません。
また、visual routeをholdとしたのも、経路そのものが無価値だと証明されたからではありません。EXP-0006以降ではknown経路の技術成立性と増分価値を分離して検証するため、visualを実験対象から外しました。検証していないことを、不要と断定しないための保留です。
EXP-0009：時間を隔てても繰り返し観測できるか
次に設計したのが、EXP-0009 Known Route Short-Horizon Temporal Replicationです。
EXP-0009では、さらに時間を分離した2つの固定checkpointで、known経路の増分価値がshort horizonで繰り返し現れるかを検証します。
固定した観測期間
| checkpoint | 対象期間 |
|---|---|
| EXP-0009-W1 | 2026年8月12日0時〜8月15日0時（JST） |
| EXP-0009-W2 | 2026年8月19日0時〜8月22日0時（JST） |
どちらも72時間です。W1終了からW2開始まで4日間を空け、2つの期間は重複しません。
各checkpointでは、次の条件を固定しました。
- 実行順序：explicit、post-run gate、known、ローカル比較
- 各経路のlimit：5件
- model：
grok-4.5 - reasoning effort：
low - tool choice：
required - timeout：180秒
- formal retry：0回
- 同一性判定：
post_id - visual route：無効
- manual collection：無効
- prompt調整：禁止
- creator list変更：禁止
W1の結果が良くても悪くても、その結果を見てW2の条件を変更しません。
結果を見る前に判定方法を固定する
EXP-0009では、結果が出たあとに都合よく成功条件を変えないよう、次の判定ロジックを事前登録しました。
| 比較可能なcheckpointの結果 | 最終分類 |
|---|---|
| 条件を満たすcheckpointが2/2 | supported |
| 条件を満たすcheckpointが1/2 | partially_supported |
| 条件を満たすcheckpointが0/2 | not_supported |
| 条件違反、technical failure、比較不能 | inconclusive |
技術失敗を「独自投稿0件」とみなして、not_supportedへ変換しない点も重要です。
検索を正常に完了した結果が0件だった場合と、通信や条件違反によって比較できなかった場合は、意味が異なります。これはEXP-0005で得た教訓を、そのまま判定ルールに反映したものです。
予算上限は1経路0.34 USD、1 checkpoint 0.68 USD、実験全体1.36 USDです。最大formal executionは4回、retryは0回に固定しています。
現在はまだ結果がない
2026年8月8日時点で承認されているのは、EXP-0009の設計と事前登録だけです。
- API calls：0
- formal execution：0回
- dry-run：未実施
- W1／W2：実行未承認
したがって、EXP-0009の結果や、known経路の時間的再現性については、現時点では何も断定できません。
仮に2/2で支持されても、確認できるのは指定したshort horizonと各limit 5の条件に限られます。長期的再現性の証明や、恒久ベースラインへの自動採用にはつなげない設計です。
5つの実験から得た教訓
EXP-0005からEXP-0009の事前登録までを通じて、データ収集の仕組みそのものについて5つの教訓が得られました。
1．0件と技術失敗を分ける
検索が正常終了した0件は、有効な観測結果です。通信失敗やツール未使用による0件相当の状態とは分けなければなりません。
この区別がなければ、「対象投稿が存在しなかった」のか、「探す処理が成立しなかった」のか判断できません。
2．一度に複数の問題を検証しない
EXP-0005では、API対手動比較の前提となるAPIデータが不足しました。
そのまま同じ実験を繰り返すのではなく、EXP-0006でknown経路の技術成立性だけを切り出し、EXP-0007で増分価値を比較しました。目的を分けることで、どの結果が何を示すのか明確になりました。
3．実行成功、仮説支持、運用採用を分ける
APIが動いたことは、経路に追加価値があることを意味しません。追加価値が一度観測されたことも、長期的に再現することを意味しません。
AI Image Trend Labでは、少なくとも次の段階を分けています。
- 技術的に実行できる
- 比較可能なデータがそろう
- 仮説を支持する結果が観測される
- 別期間でも再現する
- 運用候補になる
- 恒久的なベースラインとして採用する
EXP-0008で到達したのは5番目の「運用候補」です。6番目には進んでいません。
4．APIを呼ぶ前に止まった記録も残す
APIキー未設定やcreator listの読み込み不備は、正式なAPI失敗ではありません。しかし、実運用では再発し得る問題です。
リクエスト送信前の停止をpre-request blockとして残し、formal executionやretryと分けることで、実験結果を汚染せずに運用上の弱点を改善できます。
5．結果の適用範囲を広げすぎない
2つの72時間窓で同じ傾向が見えても、長期的な再現性は証明できません。各limit 5という小さな条件であり、creator listや時期にも依存します。
「観測できたこと」と「まだ言えないこと」を並べて残すことが、次の実験を設計する土台になります。
AI画像の流行を、再利用できる研究資産へ
AI Image Trend Labの独自性は、AI画像を収集・分析することだけではありません。
取得経路ごとの役割、検索に成功した0件、通信失敗、費用、重複、実行前block、仕様差異、Human Research Directorによる判断までを一つの研究履歴として残している点にあります。
EXP-0005では、本来の比較目的を評価できませんでした。しかし、その失敗を「うまくいかなかった」で終わらせず、known経路の技術成立性という小さな問いへ分解しました。
EXP-0006で技術的に動くことを確認し、EXP-0007で増分価値を観測し、EXP-0008で別期間の再現を確認しました。それでも恒久採用はせず、EXP-0009で時間をさらに分離した検証を事前登録しています。
研究として大切なのは、成功した結果を大きく見せることではありません。
何を固定し、何が起き、どこまで確認でき、何がまだ分からないのか。その境界を次の実験へ引き継ぐことです。
AI Image Trend Labは今後も、X全体を完全に説明したと主張するのではなく、限定された観測を積み重ねます。そして、AI画像の流行を一度きりの感想ではなく、再検証できる知識へ変えていきます。
研究記録について
本記事は、AI Image Trend Labのmainコミット42c9956に含まれるEXP-0005〜EXP-0009の計画、実行記録、結果、状態、意思決定記録を基準に作成しました。
第三者の投稿本文・投稿URL・画像URL、APIキー、非公開creator listの実値、raw API responseは掲載していません。費用は各実験記録に保存されたAPI報告値を使用し、API報告値が存在しない管理上の見積とは区別しています。