検索APIが、写真も連れてくる。
OpenAIのWeb Search APIが、テキストに加えて画像も検索できるようになった。RAGやエージェントが、記事の要約だけでなく商品写真や図版まで、同じ1回の呼び出しで直接引用できる時代が始まる。
テキストだけだった検索に
画像が加わった
これまでResponses APIのweb_searchツールは、テキストのスニペットとURLしか返さなかった。図版や写真を使いたい場面では、別途スクレイピングやライセンス済み画像APIを組み合わせる必要があった。OpenAIは公式ドキュメント「Web search | OpenAI API」で、リクエストのsearch_content_typesに"image"を指定すると画像結果も取得できるようになったことを明らかにした。開発者向け公式アカウント「OpenAI Developers」もX上の告知で「アプリがWeb上の画像を検索できるようになった。商品・場所・ビジュアル参照・出典リンクを提示するアプリが作れる」と説明している。
具体的には、リクエストでsearch_content_types: ["image","text"]を指定し、image_settingsでmax_results（取得件数）とcaption（画像への短い説明を付けるか）を制御する。画像結果はアシスタントの本文メッセージには混ざらず、web_search_call.results[]という別チャネルでレスポンスに含まれるため、アプリ側はURLとメタデータをそのままパースして表示・引用に使える。
| 従来のWeb Search API | 今回の変更 |
|---|---|
| テキストのスニペットとURLのみ返却 | 画像URL・キャプションも同時取得 |
| 画像の取得は別途スクレイピングが必要 | web_search_call.results[] にそのまま格納 |
| RAGに画像を混ぜるには追加実装が必要 | 1回のツール呼び出しで完結 |
何が変わったのか
設定項目で見る
もう、写真だけ別のツールに探しに行かなくていい。
検索と引用が、同じ1回の呼び出しで完結する。
リクエストから画像URLまでの流れ
同じ1回の呼び出しで、テキストと画像を別チャネルに分けて取り出す設計。
content_typesを指定
リクエスト時にsearch_content_types: ["image","text"]を指定するだけで、追加のクロール処理を組まずに画像検索が有効になる。
画像はresultsに分離
画像結果はアシスタントのテキスト出力には混ざらず、web_search_call.results[]という別チャネルで返る。URLと画像キャプションを含む。
アプリ側でそのまま利用
URLとcaptionをそのまま自社のUIやRAGパイプラインへ渡せる。従来のように画像を別途クロールして本文と紐付ける処理が丸ごと不要になる。
職種別に見る、効くポイント
「エンジニア・マーケター・デザイナー」——同じ機能でも、職種によって効き方は異なる。
エンジニア
RAGパイプラインに画像検索を足すたび組んでいた専用スクレイパーが不要になる。web_search_call.results[]をそのままベクトルDBやUIカードに渡せる分、実装工数と保守対象が減る。
マーケター
競合の商品写真やキャンペインビジュアルを、テキスト調査と同じプロンプト・同じ呼び出しで一度に集められる。市場調査資料の下準備を短縮できる。
デザイナー
ムードボードやビジュアルリファレンスの収集を、チャット越しの指示だけで済ませられる。ただし著作権・利用許諾の確認は従来どおり別途必要になる。
手放しでは喜べない理由
一方で、テキスト用途が中心の開発者にとって、今回の変更はほぼ無風だ。ドキュメント上でも画像検索の対象範囲・著作権処理・レート制限までは詳しく触れられておらず、商用のRAGアプリに組み込む前には自前で検証する必要がある。加えて、Google GeminiのSearch Groundingは以前からマルチモーダル入力への対応を進めてきた経緯があり、今回の追加は「後追いで足並みを揃えた一手」という側面も否めない。
実務での推奨アクションは3つ。(1) まずimage_settings.max_resultsを小さく設定し、返ってくる画像URLのドメイン分布や出典表記を目視で確認する。(2) caption: trueにしてキャプション精度を検証してから本番のRAGパイプラインへ接続する。(3) 既存のスクレイピング処理はすぐには捨てず、画像APIのレート制限や結果欠落時のフォールバックとして当面併用する。「画像もヒットするようになった」という一報だけで飛びつくと、著作権や品質の検証が抜け落ちやすい。