同じ仕様書をGeminiとClaude Codeに投げたら、埋まらない差が出た話
前回、Gemini 3.6 Flashを触った1日目の感触を「速度は明らかに向上、質は指摘すれば直せるが自分からは拾わない」とまとめました。あれから少し経って、実務でも同じ仕様書をGemini 3.6 FlashとClaude Codeの両方に投げる機会がありました。GAS（Google Apps Script）の設計を頼んだのですが、そこで見えた差は、前回のちょっとしたコーディング課題よりもずっとはっきりしたものでした。
仕様の中身そのものは業務に関わるので書けませんが、そこで起きたことは書けます。抽象化して2つのエピソードとして残しておきます。
先に断っておくと、今回は完全に同じ条件での比較ではありません。Geminiはチャットのみで、コード実行やAPIアクセスといったツールは使えない状態でした。Claude Codeはエージェント環境なので、コードを書いて実際に実行することができます。なので、これは「モデル単体の賢さ比較」というより、「今回それぞれに与えた環境・道具込みでの、実務での振る舞いの違い」として読んでください。むしろ、この道具立ての違いも含めて「実際どちらに仕事を任せたいか」という話だと思っています。
仕様書の「行間」を読めたかどうか
渡した仕様書には、2つの要素が入っていました。1つは「参考にしてほしい」と添えた既存のコード。もう1つは、設計思想として明記していた「修正・検証は非エンジニアが進められるようにする」という条件です。
Geminiは、参考コードをほぼそのままアレンジしただけの実装を返してきました。渡した材料はきちんと使っている。でも、もう1つの条件——非エンジニアが修正・検証できること——は汲み取られていませんでした。
Claude Codeは逆でした。参考コードはあくまで参考として扱いつつ、「非エンジニアが修正・検証できるように」という設計思想の方を汲み取り、修正や検証の作業がスプレッドシート上で完結するように設計してきました。
渡した情報は同じです。でも、「渡された材料をアレンジする」のか「渡された材料の背後にある要求を満たす」のかで、成果物の質がはっきり分かれました。
404エラーへの反応で、もっとはっきりした差が出た
もう1つのエピソードの方が、正直インパクトが大きかったです。
仕様書には、当時の過去モデルであるGemini 2.5 Flashを呼び出す前提が書かれていました。ところが実装を進めると、両方とも同じところでつまずきました。仕様書通りにGemini 2.5 Flashを呼び出すコードを書いたところ、404エラーが返ってきたのです。
後から分かったことですが、これには裏がありました。Gemini 2.5 Flashの公式な廃止予定日は2026年10月16日です。ところがGoogleの開発者フォーラムによると、2026年7月上旬から、2.5系のモデル（2.5 Flash・2.5 Pro等）が新規プロジェクトに対してだけ404を返すようになっていました。Google公式スタッフがフォーラムで、2.5系モデルへのアクセスは過去に利用実績があるユーザーに限定している、という趣旨の説明をしています。廃止ではなく容量維持のための措置で、新規プロジェクトには3.1 Flash-Liteや3.5 Flashなど新しいモデルを使うよう案内されていました。つまり、正式な廃止予定日より3ヶ月以上前から、新規ユーザーだけ静かに締め出されていた格好です。
もちろん、実装していたその瞬間には、そんな事情は分かりません。ここからの反応が、両者でまったく違いました。
Geminiは、「2.5 Flashはもう存在しない、最新は2.0 Flashだ」と言ってきました。実はこれ、事実として逆です。2.0 Flashは2.5 Flashより前のモデルで、「最新」どころか一世代以上前のものです。おかしいと思って「本当に2.5 Flashは無いんですか？」と問い直しても、返ってくるのは「はい」の一点張り。何度聞いても訂正されず、最終的に私から「最新は3.6 Flashだよね？」と答えを教えてから、ようやく認めました。
Claude Codeは、モデル名を知識から言い切るということをしませんでした。代わりに、APIキーを渡して、そのキーで実際にどのモデルが呼び出せるかをコードで確認しにいきました。しかも、その確認・呼び出しの仕組みをApp Scriptの中に隠すのではなく、スプレッドシート上で完結するように組んでくれました（ここは1つ目のエピソードで書いた「非エンジニアが検証できるように」という設計思想とも繋がっています）。そのうえでチャットの方で、「新規に作ったAPIキーだと、古いモデルへのアクセスが制限されているのかもしれない」という趣旨の見立ても添えてきました。この時点では裏を取れていない推測でしたが、後から調べ直すと、この見立ては実際に当たっていたことになります。「動くコードを出す」だけでなく「なぜ最初の404が起きたのか」まで考えようとする姿勢自体は、はっきり伝わってきました。
前回の記事で書いた「指摘すれば直せるが、自分からは拾わない」というのは、まだ可愛いものでした。今回は、間違った情報に固執し、指摘されても認めず、答えを教えてようやく訂正するという、一段階踏み込んだ姿を見ることになりました。
それでも、Geminiが悪いだけとは思わない
ここまで読むとGeminiをこき下ろしているように見えるかもしれませんが、そういう結論にはしたくありません。
単発で「このコードを書いて」と頼むだけなら、Geminiでも十分こなせると思います。実際、前回の記事で見た速度の良さは本物です。
ただ、今回のように仕様の背後にある意図を汲み取る必要がある場面や、想定外のエラーに向き合う場面では、話が変わってきます。少なくとも今回見た2つの場面では、「渡された材料をアレンジする」方は得意でも、「材料の奥にある要求」までは見に行きませんでした。しかも、分からないことを分からないと言わずに、誤った情報のまま押し通そうともしました。これが毎回起きることなのかは、まだ2例だけでは分かりません。
それでも、この2例だけでも、継続的に設計し、運用していく相手として見ると、正直ちょっと怖いと感じるには十分でした。今後は、単発のコーディングはGeminiに任せることがあっても、仕様の解釈や設計判断が絡む場面では、引き続きClaude Codeを軸にしていこうと思います。
Gemini 2.5系モデルの新規プロジェクトに対する404の件は、Google AI Developer Forumのスレッド（“Gemini 2.5 Flash and Gemini 2.5 Flash-Lite returning 404”、“Gemini 2.5 Pro returns ‘no longer available to new users’“）でのユーザー報告と、Google公式スタッフによる返信を参照している。