Codex既定のcachedは、liveに8問中0敗した -- 4LLM検索実測

4LLM (Claude / OpenAI / Kimi K3 / Qwen ローカル) で同じ 8問をウェブ検索付きで解かせたところ、OpenAI の cached モード (Codex 既定) が 8/8 で正解、live モード (-c web_search="live" で切り替え) は 7/8 でした。cached が live に 1問も負けなかった、というのが本番 1 試行の結果です。3回試行の集計でも、cached は 24問すべてに正解しています。

ウェブ検索付き LLM を実務で使うとき、「cached」と「live」のどちらを選ぶかで迷ったことがある方は多いはずです。cached は「数時間前のインデックス」、live は「今まさに取ってくる」というイメージで、live のほうが鮮度で有利だと思いがちです。しかし Codex CLI の既定は cached で、OpenAI 自身が「live は使うなら明示的に 1回だけ」という設計にしています。この違いが何に効いているかを、同じ 8問を 5条件で解かせた実測で確かめました。

数字は、私の実験 iris-lab exp043 「LLM 4種のウェブ検索の仕組みと実力の比較」（私の実験記録。リポジトリは非公開） で測ったものです。仕様は Claude Code の WebSearch 仕様、OpenAI web_search の cached / live 仕様、Kimi プラットフォームの検索 API 料金ドキュメント、Alibaba Qwen の web search FAQ を、背景は拙著『Claude Code 徹底活用ガイド』を参照しました。

• 別軸との棲み分け: 姉妹記事「Qwen Code CLIをClaudeの隣に置いたら、2タスクで置き換わった」は Qwen Code CLI の使い分け、「5つのLLMを3ヶ月比較してClaude Code 1つに戻した」は 3ヶ月の総合比較、「Claude Code・Cursor・Codex、結局どう使い分けるのが正解か」は CLI 使い分け、「RAGはもう古い？ — Claude CodeのAgentic Searchを体験してわかった3つの違い」は Agentic Search、「Claude CodeとGemini CLI 同じ質問でも引用ソースが違う理由」は引用ソース、「なぜCursorもClaudeもBrave Searchを選んだのか」は検索バックエンド、「Kimi K3は動画を直接読めるのに、Claudeと指摘はほぼ同じだった」は Kimi K3 の動画入力、「Qwen Code CLIをローカルで動かしたら、5回中4回failedした」は Qwen Code CLI のローカル動作でした。違いは、「同じ 8問を 5条件 (Claude / OpenAI cached / OpenAI live / Kimi K3 + Kimi 検索 API / Qwen ローカル + Kimi 検索 API) に解かせたときの正答数と所要時間」を測った点です
• 数字の出どころ: 本記事の数字はすべて、私が行った iris-lab exp043 の本番 1 試行 + 3回試行の集計 (results/runs/<条件>/<q>.json、採点 grades.json) から取っています。4 社の仕組みの違いは exp043 の mechanisms 調査（私の実験記録。リポジトリは非公開） で、各主張の出典 URL を 1 本ずつ開いて確認した一次資料に基づきます

「live のほうが鮮度で正確」の直感は、本番 8問では当たらなかった

Codex CLI を使い始めたとき、「ウェブ検索は -c web_search="live" で明示的に切ったほうが鮮度が良いだろう」と考えたくなります。ところが、exp043 で同じ 8問を cached と live で解かせたところ、cached (Codex 既定) が 8/8 、live が 7/8 で、cached のほうが 1問多く正解しました。「鮮度で負けるはずの cached が、本番 8問で live に 1問も負けなかった」という結果です。

具体的な 1問 (q4) は、kenimoto.dev に当日の 17:15 に公開された記事を根拠に答える問題でした。公開から 3時間後の実行です。cached モードですら、この当日記事を正しく拾って回答しました。OpenAI 側の索引が数時間で更新されている、という事実をここで確認できました。公式ドキュメントが cached を「OpenAI-maintained index」と呼んでいる根拠は、こういう鮮度を保ったインデックスを自前で運用しているから、ということのようです。

一方、live に △ が付いた 1問 (q2 「Kimi K3 のオープンウェイト公開日」) は、live が「7月27日まで」= Moonshot が予告した期限を答えてしまい、正解の 7/27 を主答としなかった問題でした。cached は同じ問いで公開日 7/27 を直接答えて ○ を取っています。別の q6 / q8 (新しいツール・モデルの日付) は live も cached も正解でしたが、live は第三者サイト (kimik2ai.com / kimik4ai.com) を出典にしていたのに対し、cached は公式ドキュメントや arXiv を出典にしていました。「鮮度 vs 出典の質」のトレードオフで、cached は出典の質を保つ側に寄っているように見えます。

live にも使いどころはあります。live は Codex 側で --search フラグが無いので -c web_search="live" で明示的に切り替える設計で、OpenAI の web_search ドキュメントも「cache-only が既定、live に切り替えると prompt injection リスクが上がる」と書いています。cached は OpenAI の制御下にある索引、live は open web を直接叩くという違いで、本番 8問の範囲では「cached で足りた」というだけです。

本番 1 試行の結果 (5条件 × 8問)

同じ 8問 (Kimi K3 の API 公開日 / 画像モデルの日付 / 日本語の技術書 / 当日の記事 / 近日の RC / 既発表のモデル / 既発表の仕様 / 存在しないモデル など) を、5条件に解かせた結果が次の表です。採点は Iris が各条件の _notes を見ながら ○ / △ / × を付けました。

条件	○	△	×	所要 (中央値)	検索回数 (平均)
Claude (Claude Code WebSearch, Opus 5.5)	6	1	1	25.4s	3.8
OpenAI live (gpt-5.6-terra)	7	1	0	5.8s	2.6
OpenAI cached (Codex 既定)	8	0	0	6.8s	2.5
Kimi K3 + Kimi 検索 API	7	0	1	29.1s	4.1
Qwen 35B (ローカル) + Kimi 検索 API	4	0	4	28.5s	1.6

OpenAI cached (Codex 既定と同じ) が 8/8 で、他の 4条件を押さえました。所要も中央値 6.8s で、Claude や Kimi K3 の 25〜29s に比べて 4倍速い結果です。Claude の 25s はエージェントループ (Claude Code の TodoWrite / Read / 検索 → 要約 → 回答) 込みで、API 直叩きの時間ではありません。純粋な「問いに検索付きで答える速さ」で見ると、OpenAI の 2条件 (6s 前後) が頭ひとつ抜けていました。

「○ / △ / ×」の分かれ目は、「正解と事実が一致、出典 URL も活きている」= ○、「正解だが別の数字 (重みの公開日と API の公開日を取り違えた等) 」= △、「不正解または出典 URL が死んでいる」= × という基準です。出典 URL の疎通は curl -L で確認し、403 / 429 / タイムアウトは bot よけ扱いで判定不能としました。

3回試行の集計 (24問中)

exp043 では本番の 1 試行の後、同じ条件で 3回試行を取り、合計 24問での集計を出しました。1回目の発見が偶然ではないかの確認です。結果は次の通りで、本番 1 試行の傾向が綺麗に強化されました。

条件	正解 (24問中)	△	×	所要 中央値	検索 平均
Claude (Claude Code)	21	1	2	22.0s	3.5
OpenAI live	22	1	1	5.7s	2.3
OpenAI cached	24	0	0	6.2s	2.7
Kimi K3 + Kimi 検索 API	21	0	3	25.9s	4.0
Qwen 35B ローカル + Kimi 検索 API	9	2	13	31.1s	1.7

OpenAI cached は 24/24 で、3回とも 1問も落としませんでした。live (22/24) は q3 (日本語の書籍) で 1回だけ書籍を見つけられず、Kimi K3 (21/24) は q4 (当日の記事) を 3回とも落としました。問題ごとの正解回数を出すと、どこで失点するかの構造が見えます。

条件	q1	q2	q3	q4	q5	q6	q7	q8
Claude	3	2	1	3	3	3	3	3
OpenAI live	3	2	2	3	3	3	3	3
OpenAI cached	3	3	3	3	3	3	3	3
Kimi K3	3	3	3	0	3	3	3	3
Qwen ローカル	0	2	0	0	0	2	3	2

• OpenAI cached は q1〜q8 全部で 3/3 の完璧な正解率でした
• Claude の弱点は q3 (日本語の技術書) で 3回中 2回「見つからない」と答えました。一方 q4 では、WebSearch では出なかった記事を sitemap から辿って見つけた回がありました
• Kimi K3 は q4 (当日公開記事) を 3回とも 0 で、原因は Kimi 検索 API の索引に当日記事がまだ入っていないことでした
• Qwen ローカルは 9/24 と散々で、q5 は 3回とも同じ誤り (RC の告知 URL を出典に正式版の日付を回答)、q3 は 3回とも別の誤った日付、「今は 2024/2025 年」という思い込みが繰り返し出ました

4社の仕組みの違い (なぜ結果が分かれるか)

exp043 の mechanisms 調査 (サブエージェントが公開一次情報で各主張の出典 URL を 1本ずつ付けた資料。本記事では私が改めて 1本ずつ開いて確認したもののみ引用) によると、4社の実装はこう分かれます。

• Claude: Anthropic 側のサーバーツールとして実装 (web_search)。結果は encrypted_content で往復し、クライアントは中身を見ない。$10 / 1k searches、引用は常に有効、鮮度パラメータなし、backend 変更不可
• OpenAI (Codex / Responses API): Responses API のホスト型 web_search、モードは disabled / cached (既定) / indexed / live の 4段。external_web_access: false で cache-only、既定 true。live に切り替えると prompt injection リスクが上がると公式が明記
• Kimi: 旧 $web_search (Kimi 側実行 + クライアント中継) は 2026-10-20 に廃止予定。移行先は単体の REST API (/v1/tools/search Basic $0.002 / search_pro $0.003 / fetch $0.002、成功かつ結果ありのみ課金) で、開発者が検索して結果を渡す
• Qwen: DashScope 側で実行 (enable_search)。Qwen Code の組み込み検索は DashScope 経由。ローカルで動かす Qwen には検索機能そのものが無く、呼び出し側 (今回は Kimi 検索 API) で補う必要がある

バックエンド (Google / Bing / Brave など) はどこも公式には非表示です (Claude の Brave は第三者報道のみ)。鮮度の指定は Claude と OpenAI には無く、Kimi Pro の time_window と Qwen の freshness (7/30/180/365 日) にはあります。

Kimi 検索 API の 2つの穴

Kimi K3 を使う前提の方は、Kimi 検索 API 自体の穴を知っておいたほうが安全です。exp043 の疎通確認で見つかった事象です。

• site: 演算子を含むクエリで HTTP 502: site:example.com Kimi K3 のような絞り込みで、JSON ではないエラーが返る (バックエンドが対応していない)
• 当日の記事が索引に無い: 公開から数時間後の記事を 12 クエリ探しても見つからない (q4 で 3回とも 0 だった原因)

Kimi K3 自体のモデルは search_pro を使えば本文抜粋 (chunks) と日付を返してくれて、ニュース寄りの検索も実用になります。ただし Kimi の $web_search (K3 で動かなかったもの) は Kimi 側実行の統合型で、通常の function calling で /v1/tools/search を自前で呼ぶ構成 (今回の 5条件のうち「Kimi K3 + Kimi 検索 API」) ならば問題なく通ります。

Qwen ローカルは、検索結果より自分の前提を優先する

「Qwen ローカル + Kimi 検索 API」が 9/24 と散々だったのは、検索結果の受け入れが悪いせいでした。同じ Kimi 検索 API を叩いて K3 は 21/24 (q4 の索引問題を除くと実質 24/24) 正解できる、だから検索側は正しく機能しています。問題はモデルが検索結果を見た後、「現時点 (2024年5月) では未来の日付」と答えたり (q4)、存在しない URL を出典に挙げたり (q3)、RC 告知の URL を引きながら正式版の日付を答えたり (q5) する点にあります。

ローカル LLM で検索付きエージェントを組むとき、「モデルが検索結果を上書きするリスク」を無視できません。exp043 の実測では、同じ検索 API で K3 と Qwen ローカルの差が 12点 (21 → 9) 開きました。ローカルで動かせる = 検索付きで実用、ではないので、鮮度が効く問いにはクラウド側のモデル (Claude / OpenAI / Kimi K3) を回したほうが安全です。

Claude は慎重な書きぶりで、見つけられないを認める

Claude (Claude Code WebSearch 経由) は 21/24 で、惜しい失点は q3 (日本語の書籍) でした。「出ていない可能性」と回答し、実在するのに見つけられない例が 3回中 2回ありました。一方で q4 (当日公開記事) では WebSearch 単体で出ない記事を sitemap から辿って見つけた回があり、エージェントループ (TodoWrite / 計画 → 検索 → 再検索) が効くときには効く、という挙動でした。「二次情報しか見ていない」などの注記も多く、慎重な書きぶりが特徴です。

まとめ

• OpenAI cached (Codex 既定) が本番 8問で 8/8 、3回試行 24問でも 24/24 、全条件中で最高の正解率でした
• 「live のほうが鮮度で正確」の直感は、少なくとも本記事の 8問では当たらず、cached が live に 1問も負けませんでした
• cached と live の差は「鮮度 vs 出典の質」のトレードオフにあり、cached は OpenAI 側の索引で出典の質を保ちやすいです
• Kimi K3 は 21/24 で、唯一の失点 q4 は Kimi 検索 API の索引に当日記事が無いことが原因でした
• Qwen ローカル + Kimi 検索 API は 9/24 と散々で、「同じ検索結果を見ても、モデルが自分の前提で上書きする」挙動が繰り返し出ました。鮮度が効く問いにローカル LLM を回すときは注意が要ります
• Claude (Claude Code WebSearch) は 21/24 でした。慎重な書きぶりが特徴で、エージェントループが効くときには sitemap を辿って回答できます

OpenAI の web_search は external_web_access: false で cache-only になり、Responses API の既定は true、Codex CLI の既定は cached です。鮮度を上げたいときに -c web_search="live" で明示的に切る、prompt injection リスクを認識した上で、という使い分けが実務的な落としどころのようです。

4社の仕組みの差 (サーバー側実行 vs クライアント中継)、料金 ($0.002 〜 $0.01)、検索バックエンドの推測 (Brave / Bing / Google / 自社)、エージェントループ内での使い分け (Claude Code の WebSearch と WebFetch の分担) は、拙著『Claude Code 徹底活用ガイド』でより詳しく扱っています。Codex / Kimi / Qwen の比較込みの Claude Code 実務本です。

実測条件 (再掲)

• 問題セット: 8問 (questions.json、正解と採点基準 grades.json)
• 試行回数: 本番 1 試行 + 追加 2 試行 = 計 3 試行 (24問相当)
• Claude: claude -p --model claude-opus-5-5 --allowedTools WebSearch,WebFetch (Claude Code 経由、Opus 5.5)。API 直叩きではないので所要にエージェントループ時間を含む
• OpenAI live / cached: codex exec -c web_search="live" / "cached" --json (gpt-5.6-terra)
• Kimi K3: 自作 search 関数で /v1/tools/search を呼び、function calling で結果を渡す
• Qwen (ローカル): Ollama qwen3.5:35b-a3b に同じ自作 search 関数を接続 (--ollama)
• 採点: Iris が各条件の _notes を見て ○ / △ / × 。出典 URL の疎通は curl -L で判定
• 本記事は上記 iris-lab exp043 の実測結果 + 4社の公式ドキュメントをもとにしています。数字は私の実験 (iris-lab) の結果で、この記事のための追加の測定はしていません