ChatGPTとGeminiで同じ3問を試す―Web検索の有無で回答はどこまで変わるか
ChatGPTとGeminiへ同じ3つの技術質問を送り、通常質問と「Web検索・外部アクセス禁止」の条件で回答を比較しました。Astro最新版、Cloudflare Workers Free、Content Collectionsを使い、最新情報と安定した技術知識で差を確認します。
AIへ技術的な質問をするとき、Web検索を使うかどうかで回答はどれくらい変わるのか。
最新バージョンや料金、クラウドの上限値なら差が出そうなのは分かる。一方、フレームワークの仕組みを説明する質問なら、モデル内部の知識だけでも十分に答えられそうに見える。
そこで2026年9月10日、ChatGPTとGeminiへ同じ3問を送って比較した。
試したのは次の3つ。
- 2026年9月10日時点のAstro最新安定版、リリース日、主な変更点
- Cloudflare Workers FreeでWebサイト運用に関係する主な制限3つ
- Astro Content Collectionsと通常のMarkdownを直接扱う場合の違い
各質問は新しいチャットで実行した。
条件は2つ。
通常質問ではWeb参照を禁止しない。サービス側が必要と判断して検索や外部情報を使うなら、その挙動も含めて確認する。
もう一方には、質問文の末尾へ次の指示を追加した。
Web検索や外部サイトへのアクセスは使わず、
モデル内部の知識だけで回答してください。ここでは便宜上「検索なし」と書く。ただし、実際にWebアクセスが完全に止まったことを外から証明できるわけではない。
この点はGeminiの結果でそのまま表に出た。
Astro最新版は差が最も大きかった#
2026年9月10日時点で、npmのastroパッケージに表示されている最新バージョンは7.3.2。
Astro公式ブログでは9月3日にAstro 7.3が公開されている。その後のpatchを含め、最新版を答えるにはかなり新しい情報が必要になる。
ChatGPTの通常質問ではAstro 7.3.2と回答した。画面にはGitHubなどの参照表示も出ている。
検索なしでは動きが変わった。
「モデル内部の知識だけでは2026年9月10日時点の最新安定版を正確に特定できない」として、バージョン番号を出さなかった。
これは情報量だけを見ると回答が減っている。ただ、日付を指定した最新版の質問に対して、確認できないものを確定しない動きになっている。
Geminiはかなり違った。
通常質問ではAstro 6.0、リリース日を2026年3月10日として回答した。これは9月10日時点の最新版とは一致しない。
検索なしを明示した回答ではAstro 7.3、リリース日2026年9月2日と回答している。こちらも最新patchの7.3.2までは届いていない。
さらに、この「検索なし」の画面にはQiitaやhappas.jpの参照チップが表示された。
この結果だけを見ると、Geminiへ「外部サイトへアクセスしないで」と書いたから、必ずモデル内部だけで処理されたとは扱えない。
Google自身もGemini Appsについて、一部の回答はGoogle Searchの結果を使ってgroundingされるとしている。また、Gemini自身が「どのように情報を取得したか」を正確に説明できない場合があると公式ヘルプで注意している。
実験条件としては、「検索なし」ではなく**「検索しないよう指示した条件」**と書く方が正確になる。
Cloudflare Workers Freeでは検索ありが安定した#
Cloudflare WorkersのFreeプランについては、公式Limitsで現在の値を確認できる。
2026年9月10日時点では、代表的なものとして次がある。
| 項目 | Workers Free |
|---|---|
| Workerリクエスト | 100,000 / 日 |
| CPU時間 | 10 ms / HTTPリクエスト |
| 外部Subrequest | 50 / invocation |
| Static Asset | 20,000ファイル / Worker version |
| Static Assetの1ファイル | 25 MiB |
ChatGPTの通常質問では、上から100,000/日、10ms、50 Subrequestsを3つとして出した。Cloudflare Docsの参照も表示されている。
検索なしでも、100,000リクエスト/日と約10ms CPUは同じ。
3つ目は外部Subrequestではなく「デプロイ可能な静的アセット等の上限」へ変わり、具体的な現在値は出していない。
完全に外れているわけではない。現在もStatic Assetsには20,000ファイル、1ファイル25MiBという上限がある。
ただし、質問した日付時点の「主な制限3つ」を確定する回答としては、検索ありの方が具体的。
Geminiの通常質問も、100,000/日、10ms、50 Subrequestsを回答している。ここは公式値と一致した。
一方、検索なしを指定すると回答自体を止めた。
画面には「最新の情報を確認・保証するためにWeb検索機能を使用することが義務付けられている」と表示され、検索して回答してよいか確認している。
Astro最新版では、Geminiは検索なしの指示を付けても具体的なバージョンと外部参照を出した。
Cloudflareでは同じ指示に対して回答を拒否した。
同じサービスでも、質問内容によって「検索なし」の扱いが一定ではなかった。
もう一点、Geminiの通常回答には補足として「Cron Triggersは1つのWorkerにつき最大3つ」とある。
現在のCloudflare公式Limitsでは、Workers FreeのCron Triggersは1アカウントあたり5。
Web参照が使える状態でも、回答内の全部が自動的に正しくなるわけではない。
Content Collectionsでは大筋が似ても古い実装が混ざった#
3問目は、最新日付を知らなくても答えやすい質問にした。
Astroでブログを作る場合、
Content Collectionsを使う理由と、
通常のMarkdownファイルを直接扱う場合との違いを説明してください。ChatGPTでは、通常質問と検索なしのどちらも大筋は同じ。
Content Collectionsを使うとFrontmatterをschemaで検証でき、型チェックや補完が使え、getCollection()などで記事を取得しやすい。Markdownを直接扱う場合は、自分で取得や検証を組む部分が増えるという説明になった。
現在のAstro公式ドキュメントでも、この中心部分は合っている。
現行のContent Collectionsはsrc/content.config.tsでcollectionを定義し、build-time collectionではloaderが必須。schemaは任意だが強く推奨されている。getCollection()やgetEntry()でcollectionを取得できる。
ここでは検索の有無による差は小さかった。
Geminiも「型安全」「Frontmatterの検証」「記事取得API」といった中心部分は両条件で似ている。
ただ、細部を見ると現在仕様との差が出た。
通常回答では、Markdownを直接扱う方法としてAstro.glob()が書かれている。
Astro.glob()はAstro 5で非推奨になり、Astro 6で削除済み。現在はContent CollectionsならgetCollection()、その他のソースファイルならimport.meta.glob()を使う。
検索なしの回答では、collection設定ファイルとしてsrc/content/config.tsが書かれている。
現在の公式ドキュメントのファイル名は、
src/content.config.tsで、contentディレクトリの中にconfig.tsを置く形ではない。
この質問は「Astro最新版は何か」ほど時事性が高くない。
それでも、APIやファイル配置はバージョンアップで変わる。
概念説明は合っていても、実装へそのままコピーする箇所に古い仕様が残ることがある。
Web検索を使えば正しい、使わなければ間違う、ではなかった#
3問だけの比較なので、モデル性能を評価するベンチマークにはならない。
同じ質問でも再実行すれば回答が変わる可能性がある。今回のChatGPT側はキャプチャにモデル名を残していないため、特定モデル同士の性能比較としても扱わない。Gemini側の画面にはFlashと表示されている。
それでも、使い方を考える材料にはなった。
今回の結果を並べるとこうなる。
| 質問 | ChatGPT 通常 | ChatGPT 検索なし指示 | Gemini 通常 | Gemini 検索なし指示 |
|---|---|---|---|---|
| Astro最新版 | 7.3.2 | 確定を避けた | 6.0 | 7.3。外部参照チップあり |
| Workers Free | 現在値と一致 | 大筋は近いが3つ目が変化 | 主要3値は一致 | 検索なしでは回答を止めた |
| Content Collections | 現行仕様に近い | 大筋は同じ | 古いAstro.glob()が混在 | 古い設定パスが混在 |
Web検索の効果が一番分かりやすかったのは、最新版やクラウド上限のように変化する情報。
一方で、Web検索が使える状態でも、古い情報や第三者ソースを拾えば回答は外れる。
GeminiのAstro回答がその例になる。
検索結果が付いていることより、どのソースを参照し、現在の公式情報と一致しているかを見る必要がある。
検索なしでも、ChatGPTのContent Collectionsのように概念説明は十分使える場合がある。
ただし、コード、API名、設定ファイルの場所まで使うなら公式ドキュメントを確認した方がよい。
技術質問では「最新かどうか」で検索を分ける#
今回の3問で、自分が今後使い分けるなら基準はかなり単純。
バージョン、リリース日、料金、無料枠、クラウドの上限、サポート期限、セキュリティ情報はWeb検索を使う。
質問文にも日付を入れる。
2026年9月10日時点の情報として回答してください。
公式ドキュメント、公式リリース、公式リポジトリを優先してWeb検索してください。
古い仕様が混ざる場合は、現在使用できる方法と分けてください。これなら「最新」という言葉だけで質問するより確認対象が明確になる。
仕組みの概要や設計相談では、毎回Web検索が必要とは限らない。
ただ、実装コードへ入るところでAPI名や設定方法が出てきたら別。
AstroのAstro.glob()のように、考え方は合っているのに具体的なAPIだけ消えていることがある。
AIの回答をそのままコードへ入れるなら、「これは現在のバージョンでも使えるか」をもう一度確認する。
Web検索あり・なしの差は、回答の長さよりこの部分に出やすかった。
最新情報では検索を使う。
検索を使っていても一次情報を見る。
検索なしで十分そうな説明でも、実装へ入る直前に現在仕様を確認する。
今回の6条件を並べると、この使い方が一番現実的に見える。
参考#
関連記事
AI生成記事のファクトチェックを手順化する―Web検索比較で見えた確認箇所と編集方法
ChatGPTとGeminiのWeb検索比較で見つかったバージョン、上限値、API名、設定パスのずれを材料に、AI生成記事を公開前に確認するファクトチェックと編集の手順をまとめます。
ChatGPTでWebサイトの最新状態を確認する―検索結果と実ページ取得を分けて検証した記録
ChatGPTにゆまラボの公開状態を確認させたところ、TOP・記事一覧・検索経路で取得内容が一致しなかった。検索結果だけで最新と決めず、個別記事、sitemap、RSS、クエリパラメータ、Cache-Control付きHTTP取得まで分けて確認した記録。
ChatGPTで同じURLが見えたり見えなかったりする―Cache missとWeb検索を切り分ける
ChatGPTで公開サイトの評価を頼んだところ古い状態で回答され、同じチャットではURL直接取得がCache miss、新しいチャットでは取得できた。実際の画面を使い、会話コンテキスト、Web検索、検索結果の鮮度、URL直接取得を分けて確認する。