AIエージェント向け画像検索インフラ：市場が実際に提供しているもの

今年出荷されたどのエージェントフレームワークも、文章を書き、計画を立て、ツールを呼び、プルリクエストを開くことができる。ところが写真を1枚頼んだ途端、すべては肩をすくめるだけの結果に落ち込む——記憶から捏造されたストックURL、壊れたホットリンク、あるいは本物を探すより自分で作った方が楽だったから生成された画像。モデルは弱点ではない。弱点はその下にある画像レイヤーであり、それは非常に具体的かつ測定可能な形で欠落している。

これはマニフェストではなく、市場調査である。以下のすべては2026年8月18日に測定または一次情報源から読み取ったものだ——公式MCPレジストリの全数調査、4つの大手無料写真APIの公開規約、今月エージェント用コネクタを出荷した2社の有料大手企業のアクセス条件、そしてAPIキー不要で1分もあれば再現できる小さなベンチマーク。

読み進める前に境界を1つ示しておく。これがあなたの疑問でないなら、ここで読むのをやめてもよい。本記事のテーマはアクセス層——検索、到達可能性、規約、割り当て——である。公開パイプラインの話ではない。下書きを、挿絵付きでクレジット表記もされた、マークアップ済みのページに変える方法——ルーティングプロンプト、ビジュアルブリーフ、組み立て、ImageObjectマークアップ——が必要であれば、それは AI生成記事に挿絵を入れるパイプラインで別途まとめている。

呼び出し元が機械であるとき何が変わるか

人間が写真を検索するときは、2〜3語を打ち込み、グリッドをざっと眺め、良い写真を見れば分かる。これまで作られてきたストック検索エンジンはすべて、そのループを前提にしている。エージェントはその3つの前提を一度に壊す。

1. キーワードではなく文章を書く。 住宅ローンの書類についてのセクションを書き終えたばかりのモデルは、mortgageとは出力しない。「銀行の担当者が条件を説明する中、キッチンテーブルで住宅ローンの書類にサインする女性」と出力する。これは言語モデルの自然な出力であり、まさにトークンマッチング型のインデックスが処理できないものだ。
2. グリッドを眺めることができない。 ツールが返すものが、そのままエージェントが知るすべてだ。レスポンスが説明も寸法もクレジットもないURLのリストであれば、エージェントは1枚ずつ取得して確認するしかない——もっと頻繁には、推測に頼るしかない。
3. 手を持たない。 スクリーンショットを審査キューにアップロードすることも、規約に同意することも、キーをローテーションすることも、本番承認を3営業日待つこともできない。APIのオンボーディングにある人間向けのステップはすべて、エージェントが立ち止まる壁になる。

つまり「AIエージェント向けの画像検索インフラ」はマーケティング用語ではない。それはチェックリストだ——自然言語による検索、推論できるほど豊富な機械可読の結果、そしてプログラムが自力で完了できる認証・割り当てモデル。

検証:キーワードインデックスに文章をぶつける

問題を確認する最も安上がりな方法は、エージェント自身の言葉をキーワードエンジンに送ることだ。以下のテストではOpenverseを使う。これはWordPress.orgが運営するオープンライセンスのメディア検索で、APIが公開されておりキー不要、誰でも1分足らずで再現できるからだ。モデルが自分の書いた下書きに挿絵を入れるときに書くような依頼文を4つ用意した。

import json, urllib.request, urllib.parse

BRIEFS = [
  "a woman signing a mortgage document at a kitchen table while a bank"
  " adviser explains the terms, warm morning light",
  "An elderly couple enjoying a peaceful retirement together",
  "a child discovering snow for the first time in a suburban garden",
  "a delivery cyclist waiting at a red light in heavy rain",
]

def count(q):
    u = "https://api.openverse.org/v1/images/?" + urllib.parse.urlencode({"q": q})
    r = urllib.request.Request(u, headers={"User-Agent": "benchmark/1.0"})
    return json.load(urllib.request.urlopen(r))["result_count"]

for b in BRIEFS:
    print(count(b), "|", b[:48])
# 0 | a woman signing a mortgage document at a kitchen
# 0 | An elderly couple enjoying a peaceful retirement
# 0 | a child discovering snow for the first time in a
# 0 | a delivery cyclist waiting at a red light in hea

依頼文4件、結果セット4件がすべて空。今度は各依頼文を、人間なら打ち込んだであろう2つのキーワード——signing document、elderly couple、child snow、cyclist rain——に削ってみると、いずれも写真1ページ分がまるごと返ってくる(APIは240件と報告するが、これは匿名呼び出しに対する件数の上限だ)。カタログには写真がある。それを解析できないのは文章の方だ。

表を横にスワイプするとすべての列が見られます →

Pexafyの列は、同じ4つの文をそのままホスト型MCPサーバーのsearch_photosに送った結果で、レイテンシはサーバー自身が報告した値だ。これはクエリの形を比較しているのであって、カタログの質を比較しているのではない——そしてカタログはまったく問題ではない。Openverse自身の統計エンドポイントは、テスト当日で52ソースにまたがる9億1,500万枚の画像を報告しており、それが作られた目的、つまり人間によるキーワード検索においては優れている。壊れている箇所はどこにもない。ただ、文章で考える呼び出し元向けには一切設計されていなかっただけだ。タグマッチングが説明された場面でなぜ破綻するのか、そしてセマンティック検索が代わりに何をするのかは、読者側の視点から キーワードではなく文章で検索するで論じている。ここで新しいのはその測定であり、呼び出し元が人間ではなくプログラムである場合に何を意味するかということだ。

「穏やかな退職後の生活を共に楽しむ高齢の夫婦」・135 msで16件・そのうち3枚

1位Pexels Pixabay Unsplash

2026年8月18日時点の市場

検索性は半分でしかない。もう半分は到達可能性だ——エージェントはそもそもカタログにたどり着けるのか、どんな条件で。Model Context Protocolがアシスタントを外部システムに接続する手段になって以来——現行仕様(2026年7月28日付)はプロトコルをステートレスなリクエスト/レスポンス方式のコアに移行させ、サーバーが通常のロードバランサーの背後に置けるようにした1——この市場を調べる誠実な方法は、発表内容ではなく実際に公開されているものを見ることだ。

有料大手は今月やってきた

Getty Imagesは2026年8月12日、つまり本記事の6日前にMCPサーバーを公開し、クリエイティブ・報道・アーカイブ検索とダウンロードをAIワークフローに開放した。2 これはエンタープライズチームやプラットフォーム構築者を対象としており、自社のアクセスページには参入価格が明確に示されている——Premium Accessのような有効なGetty Images契約に加え、Web Service利用規約への同意が必要だ。無料枠はない。ShutterstockのコンテンツもMCPサーバー経由で到達可能だ——検索、コレクション、ライセンスをカバーする24種類のツールがあり、ダウンロードは有効なサブスクリプションを持つアカウントの背後に置かれている。3

どちらの動きも合理的であり、どちらも特定の買い手向けだ。Gettyは2025年に9億8,130万ドルの収益を計上しており4、ストックフォト市場全体は2026年時点でおよそ54億ドル規模と見積もられている5。契約を要求するコネクタは、その市場を開放するのではなく収益を守るためのものだ。あなたが銀行や放送局であれば、これはまさに望むものだろう。あなたが個人プロジェクトを組み立てる開発者——あるいは立ち止まって人間に何かへの署名を頼むことのできないエージェント——であれば、それは閉じた扉だ。

無料ライブラリは1つも出荷していない

Unsplash、Pexels、Pixabayは、ほとんどの開発者が最初に手を伸ばす3つのカタログだが、いずれも公式のMCPサーバーを公開していない。代わりに存在するのは、コミュニティ製ラッパーの棚だ。私たちは公式MCPレジストリを全数クロールし——22,607サーバー、公開バージョン数75,487——名前や説明が写真やストック画像検索に関するものをすべて保持した。パターンは一様だ。

表を横にスワイプするとすべての列が見られます →

import json, urllib.request, urllib.parse

def crawl(term):                      # レジストリは `nextCursor` でページ送りする
    out, cursor = {}, None
    while True:
        p = {"limit": "100", "search": term} | ({"cursor": cursor} if cursor else {})
        d = json.load(urllib.request.urlopen(
            "https://registry.modelcontextprotocol.io/v0/servers?" + urllib.parse.urlencode(p)))
        for e in d["servers"]: out[e["server"]["name"]] = e["server"]
        cursor = (d.get("metadata") or {}).get("nextCursor")
        if not cursor or not d["servers"]: return out

servers = {}
for t in ["photo", "image", "stock", "picture", "unsplash",
          "pexels", "pixabay", "getty", "shutterstock", "openverse"]:
    servers |= crawl(t)

# 137個の重複なしサーバー · リモートかローカルかは server["remotes"] を見る
# 必須のサードパーティキーは packages[].environmentVariables にある

これらのラッパーはいずれも同じ3つのキーワードAPIの薄いクライアントに過ぎず、つまり上記のベンチマークがすべてに当てはまる。変わったのはトランスポートであって、検索の中身は変わっていない。ラッパーはタグインデックスに文章を理解させることはできない。

機械を止めるのは割り当てではなく条項だ

無料ライブラリの割り当てと規約は、共通の単位で並べて 無料ストック写真API比較で比較している——承認待ちキュー、必須のダウンロード呼び出し、24時間のキャッシュ義務、クレジット表記のルール。あの記事はそれらを、プロバイダーを選ぶ開発者の視点で読んでいる。今度はそれらに従わねばならないプログラムの視点で読み返すと、量とは無関係な1行が際立つ。

同じ読み方はオンボーディングにも当てはまる。誰かがアプリのスクリーンショットを審査して初めて本番運用に移行できるデモ枠は、エージェントが折り返せるレート制限ではなく、そもそも実行できないステップだ。Pixabayはその意図を明示している——このAPIは正当な人間による利用のためのものであり、大量の自動ダウンロードは禁止されている。これは何一つ不合理ではない。写真家は作品を無償で提供し、誰かが帯域幅の代金を払っている。ただそれは、呼び出し元に画面と手があることを前提としたAPIを表しているに過ぎない。

4つの要件、それを満たすのは誰か

両半分を合わせると、エージェントが実際に使える画像レイヤーの仕様は短くて検証可能なものになる。これは意図的に、プロバイダー比較ではない——カタログの規模、価格、ライセンス条件は 比較記事で整理している。以下の4つはあくまで、プログラムがそもそも写真にたどり着けるかどうかだけを問うものだ。

1. セマンティック検索——完全な文章がランク付けされたページを返す、空集合ではなく。
2. 無料ライセンス、複数ソース——1枚ごとにライセンス費用が発生せず、単一ライブラリの好みが公開する全ページを規定しない。
3. 独自のサインインを備えたホスト型サーバー——リモート、OAuth、インストールするローカルプロセスもなく、設定ファイルに貼り付けるサードパーティのAPIキーもない。
4. 機械が自力で完了できる無料枠——スクリーンショット審査なし、契約なし、月間割り当てとワーカーが自分でペース配分できる分単位のレート制限。

表を横にスワイプするとすべての列が見られます →

私たちはPexafyを作っている側なので、その最後の行はしかるべき懐疑心をもって読んでほしい——そしてそれを検証してほしい。レジストリの全数調査は1つのスクリプトで再現でき、GettyとShutterstockのアクセス条件は各社のページに載っており、3つの写真APIの制限も各社のドキュメントに載っている。すべて下部にリンクしてある。主張は狭く、反証可能だ——2026年8月18日時点で、この4つすべてを満たす2つ目のサービスを私たちは見つけられなかった。もし知っていれば、この表に追加する。要件を書き出しておく意義は、私たちの製品を含め、誰でもどんな製品に対してもそれを検証できることにある。

優れた画像サーバーがMCP上で行うこと

コネクタは、新しい皮を被せただけのRESTエンドポイントではない。このレイヤーの2つの使い道は別の記事でまとめており、ここでは繰り返さない——下書きに挿絵を入れることは パイプライン記事で、長期シリーズの見た目の一貫性を保つことは ボリュームに関する記事で扱っている。インフラに属するのは、その両方が依存し、かつどちらも後から追加できないもの——サーバー側で一度だけ下される、以後接続するすべてのエージェントに適用される3つの決定だ。

1. エージェントが推論できるオブジェクトを返す。 ツールが返すものが、そのままモデルが知るすべてだ——グリッドを眺めることはできない。以下の2つの形の違いが、写真について推論するアシスタントと、リンクを右から左に流すだけのアシスタントとの違いになる。

# 典型的なキーワードラッパー:エージェントは取得して見るか、推測するしかない
[{ "url": "https://…/photo-8795398.jpeg" }, { "url": "https://…/366611.jpg" }]

# 実際に返される1件の結果——ここでは省略しているが、何も付け足していない
{
  "rank": 1,                       // 人間が使うハンドル:「#1に似たものを」
  "photo_id": "019e14d9-e821-…",   // get_similar_photos が受け取る値
  "width": 6424, "height": 4283, "orientation": "landscape",
  "color_hex": "#918872", "blur_hash": "LPI#Px?aDikCGwW?M{kD-VR*s.fl",
  "source": "Pexels", "license_type": "free",
  "alt_description": "Older couple sits together on wooden bench in a park",
  "attribution": { "plain": "Photo by Anastasia Shuraeva on Pexels", "html": "…" },
  "urls": { "thumb": "…", "small": "…", "regular": "…", "large": "…" }
}

2つ目の形であれば、エージェントは「#3は縦長なので、あなたのヒーロー枠を壊します」と言え、重複する写真家を除外し、クレジット行を出力し、テンプレートにレイアウトシフトを起こさないwidth/heightの組を渡せる——画像を1枚も取得することなくだ。1つ目の形では、そのどの判断も推測か往復通信を必要とする。

2. 結果に番号を振り、人が指し示せるようにする。 結果は#1, #2, #3…とランク付けされて返る。これは会話の中で誰もが写真を指す方法——「#3みたいなのをもっと」——であり、識別子を手でコピーする必要はない。MCP Appsに対応したクライアントではサムネイルがインラインで表示され、1枚を開くとツール結果にすでに含まれていたメタデータが、追加の呼び出しなしで表示される。

3. 読み取り専用を貫き、それを明示する。 ツールは3つ、書き込みスコープなし、アカウント変更なし。そのうち1つには、キーワードマッチングに対応するものがどこにも存在しない——search_photos_by_imageは参照画像(クライアントの既存のヒーロー画像、チャットに貼り付けられたスクリーンショット)を受け取り、それに任意の文章を加えて条件を変更できる(「これと似た感じで、ただし夜に」)。タグマッチング型のAPIには、そのようなリクエストを入力できるフィールドすら存在しない。そして何も変更できないエージェントは、最悪の結果がサポートチケットではなく空の結果セットで済むエージェントだ。

2つの入口、どちらを選ぶべきか

入口はちょうど2つあり、その選択は能力の話ではなく、誰がループの中にいるかの話だ——ツールもカタログも両方で同一だ。

人が関わる場合はコネクタ。 URLは1つ、https://mcp.pexafy.com/mcpで、アシスタントのコネクタ設定に一度追加すればよい。サインインはブラウザウィンドウで行われ、クライアントは自身の資格情報を受け取るので、設定ファイルに貼り付けるキーも、後でローテーションするキーもない。OAuthを実装していないクライアントは、Pexafy APIキーをベアラートークンとして同じエンドポイントに送る——これによって、誰も「Allow」をクリックできないビルドサーバー上のcronジョブからでもコネクタが使えるようになる。Claude、ChatGPT、そしてフリート用の設定ファイルへの具体的な組み込み手順は パイプライン記事に載っており、変わっていない。

誰も関わらない場合はHTTP API。 800のトピッククラスタ分のプールを埋めるバッチジョブは、チャットクライアントのふりをすべきではない——同じアカウント、同じキー、プレーンなHTTP、1回の呼び出しで100件の結果。それに伴うペース配分のルール——レート制限ヘッダー、分単位の429はリトライする価値があり月間割り当ての429はそうではない理由、大量処理時にワーカーがどれだけのコストになるか——は 大規模な挿絵付けに関する記事にまとめてあり、そこでそのワーカーの全体像を書き出している。

ここで押さえておくべき点はもっと狭く、それこそが市場調査の要になる。どちらの入口も、書かれたその日にプログラムから到達可能であり、キューも契約も必要ない。

これでは解決しないこと

誠実なリストを挙げておく。それぞれ、誰かにロールバックの代償を払わせてきたものだからだ。

• ライセンスは依然として写真を支配する。 Pexafy APIの利用規約はクレジット表記を必須としておらず、すべての結果にはそのままレンダリング可能なクレジット文字列が付いてくる——だが、元のライブラリが付したライセンスは、その写真の利用に対して適用される。クレジットを自動的にレンダリングすること。後から監査するより安上がりだ。
• 無料ライセンスのカタログは報道アーカイブではない。 ニュースもスポーツも、著名なブランドや公人をオンデマンドで用意することもできない。特定のイベントや人物の写真がページに必要なら、それはライセンス済みの大手向けであり、彼らのコネクタは今や存在する。
• これは検索であり、検索でしかない。 図表、グラフ、スクリーンショットはコードから生成されるものであって検索されるものではない。ページ間の重複排除はエンドポイントのパラメータではなく、あなたのデータベースの1カラムの仕事だ。そして写真を付けたからといって薄いページの順位が上がるわけではない——Googleのスパムポリシーは、ページに挿絵があってもなくても、大量生成コンテンツの悪用を同じように扱う。6 この3つはパイプラインの問題であり、パイプラインの答えを持つ問題であって、 パイプライン記事と ボリュームに関する記事で扱っている。

どこから始めるか

1. ベンチマークを自分で再現する。 20行、キー不要。今使っている画像APIが何であれ、自分のエージェントが書いた依頼文をそのまま3つ送り、空の結果セットの数を数えてみる。
2. コネクタを1つ接続する、今使っているアシスタントに。そして今週実際に必要な写真を、文章で頼んでみる。それが評価のすべてだ。
3. 依頼文をエージェント側に移す——1スロットにつき1つの場面、下書きから書き起こす、タイトルからは決して書かない。
4. photo_id列を追加する、大量に公開する前に。
5. 無料枠で運用する——月5,000回の検索、1分あたり20回まで、ビルドの窓が——請求書ではなく——上位プランへ押し上げるまで。

参考文献と注釈