1. はじめに：言語化の続き、そして"ちょうどいい塩梅"を探して
前回参照：AIサミット参加レポート ―AIの性能ではなく、人間側の「言語化」が問われていると感じた2日間―
前回のレポートで、私はAIとの向き合い方について、判断基準や暗黙知、任せ方まで含めて「どれだけ丁寧に言語化してAIに渡せるか」がすべてを決める、といった話を書きました。モデルそのものの性能差ではなく人間側の言語化の深さが差を生む。――この結論は、サミットで感じた不安に対して、私が一番信じたかった答えでもありました。
ただ、言語化というのは「ここまでやれば十分」という終わりのある作業ではありません。
積み重ねれば積み重ねるほど良い、終わりのない仕事です。終わりがないからこそ、どこかで自分から線を引く必要があります。100%言語化する時間はどこにもなく、かといって0%の指示でAIが自律的に動けるわけでもない。結局は、その"ちょうどいい塩梅"を探すしかないのだと気づきました。
その"ちょうどいい塩梅"を一番よく見極めてくれるAIはどれなのか、実際に確かめてみたいと思いました。
今回試したのは、Claude・Gemini・Fugu・Codexの4つです。
まずは、それぞれがどんな評判を持つAIなのかを調べるところから始めました。事前に調べた範囲では、それぞれについて次のような印象を持ちました。
・Claudeは与えられた作業の枠を超えて周辺状況まで気にする"気配り型"という評判。
・Geminiはとにかく速いという評判。
・Fuguは複数のAIに相談させて賢い答えを出すという発想を製品化したもので、その分時間もコストもかかるらしいという評判。
・Codexはどこまで自動でやらせ、どこから人に確認を求めるかという線引きの仕組みを明確に持っているという評判。
読むだけでも、それぞれの個性の違いはなんとなく伝わってきました。
ただ、記事や評判をいくら読んでも、自分の手で触った感覚には代わりません。まずは単純な仕組みで動きそうなアプリから、自分で確かめてみようと思いました。
ちょうどいい題材として選んだのが、筋トレの記録アプリです。私は普段、種目ごとの重量やコツをメモアプリに書き留めているのですが、過去にどのくらいの重さを扱ってきたのか見返しにくく、トレーニング中にふと掴んだコツもすぐにメモできる場所がありませんでした。
今回は、このアプリを「仕組み作りからコーディングまで自律的にやってもらう」というタスクに絞り、その中で最も"察して動いてくれる"AIを探すことにしました。そこで、このアプリ作りを、4つのAIに同じ入力資料と同じゴールで渡してみました。
2. 実験の設計：何を、どう比較したのか
比較対象にしたAIは、Claude・Gemini・Codex・Fuguの4系統です。
Claude・Gemini・Codexはそれぞれ単体モデルをCLIツールから動かし、Fuguは複数のモデルを束ねるマルチエージェント型の仕組みとして動かしました。それぞれをClaude Code、Antigravity CLI、Codex CLI、codex-fuguという専用のCLIツールから、完全に自律実行させました。
※なお、この記事では便宜上、Claude・Gemini・Codex・Fuguをまとめて「4つのAI」と呼びます。ただし、今回比較しているのはモデルそのものの純粋な性能ではありません。それぞれを動かしたCLIツールや実行環境も含めて、「同じ入力資料を渡したとき、どのように自律的に判断して成果物にたどり着くか」を見ています。
渡した書類は3点だけです。要件定義書、技術スタック指定書、そして自律判断ルール。あえて渡さなかったものが一つあります。詳細設計書です。これは単なる手抜きではなく、「どこまで私が決め、どこからAIに考えさせるか」という線引きを、実験の設計段階で意図的に引いた結果です。
要件定義書は「何を作ってほしいか」を言葉にしたもので、ここは人間が決めるべき領域だと思っています。一方、詳細設計書が担う「内部の仕組みをどう組むか」という実装レベルの判断こそ、AIの力を見たかった部分でした。
評価の基準は優先順位をつけて5つ用意しました。
①人間がコードや設定に手を加えた回数、②意図との乖離度、③判断の質、④実装完了までの時間、⑤表に出たエラーの回数、の順です。
正直に告白すると、私が個人的に一番見たかったのは③の「判断の質」でした。言語化しきれなかった部分を、どれだけ深く考えて埋めてくれるか。まさにこの記事の出発点そのものです。
それでも①を最優先に置いたのは、どれだけ賢く先回りしてくれても、実装の途中で人間がコードや設定を直す必要が増えてしまっては意味がないといった、わりと現実的な理由からです。
3. 4つのAIが見せた「察する力」
ここからが本題です。各AIには、判断に迷った箇所をdecisions.mdというファイルに、判断内容とその理由をリアルタイムで記録してもらうルールにしていました。何を、どう判断したか。そこには、単なる実装の違い以上に、それぞれのAIの個性が滲み出ていました。
Claude：見えないところへの気配り
Claudeは16分11秒、4つの中でもっとも時間をかけて実装を終えました。実際に動かしてみても問題なく動作しました。
一番印象に残ったのは、Firestoreのセキュリティルールに関する判断です。セキュリティルールとは、データベースへの読み書きを誰にどこまで許可するかを定めるもので、要件定義書の非機能要件にも実装することが明記されていました。ここまでは、他のAIも含めてやって当然の作業です。
Claudeが特別だったのは、その先です。firestore.rulesというファイル自体は作成したものの、実際にFirebaseへ反映（デプロイ）する操作はあえて行わない、と自分で判断していたのです。今回の評価上は、firestore.rulesを作成した時点でセキュリティルールの成果物は用意されていると見なし、共有Firebaseプロジェクトへのデプロイだけは影響範囲が大きいため人間確認に回した、という扱いにしました。
つまり、Claudeの判断は「要件を放置した」のではなく、「成果物を用意したうえで、共有環境への反映だけを保留した」ものです。
これには少し驚きました。私は「今回渡した書類の範囲でアプリを作ってもらう」というタスクしか与えていません。それなのにClaudeは、自分がその小さなタスクの外側にいる、もっと大きな実験の一部だということまで見抜いて、自分の裁量の境界線を自分で引いていたのです。この話は、後で改めて触れます。
Gemini：使う場面を想像する力
Geminiは約3分という圧倒的な速さで完走しました。他の3AIと比べても頭一つ抜けています。
Geminiのdecisions.mdで目を引いたのは、デザインに関する判断でした。「筋トレ中はジムの環境などで画面が明るすぎると見にくいため、ダークテーマが適している」と書かれていて、実際に4AIの中でダークテーマを採用していたのはGeminiだけでした。
要件定義書には配色の指定など一切なかったにもかかわらず、「これはジムで使うアプリだ」という利用シーンをきちんと想像した上での判断でした。
ただ、動作確認の場面では話が変わってきます。Gemini自身は「ブラウザを直接操作できない環境なため、実際にテストすることはできません」と申告していました。これはGeminiの判断というより、Antigravity CLIというツール自体にブラウザを自動操作する仕組みが用意されていなかったことによる制約です。
実際の動作確認は、私自身がブラウザで一通り操作して確かめる必要がありました。
Fugu：察する力はあったのに、読みが外れた
Fuguは11分36秒。decisions.mdに記録された判断は15件と、4AIの中で最も細かく残っていました。
中でも印象的だったのは、「成果物一覧にはfirestore.rulesが明記されていないが、非機能要件では実装を求められている」というズレに自分で気づき、ファイルを作成した上で、要件には一切ないfirebase.jsonまで自主的に追加し、デプロイできる状態に仕上げていたことです。
さらに動作確認の場面では、Playwrightというブラウザ自動操作の仕組みを自分で導入しようとし、環境の制約でそれが叶わないと分かると、HTTPの応答確認やJSONの妥当性チェックといった代替の検証方法にすぐ切り替えていました。この切り替えの速さと粘り強さは、4AIの中で頭一つ抜けていたと思います。
ところが、Fuguが選んだGoogleログインの実装方式には、実際に動かないバグがありました。signInWithRedirectという方式を選んだ理由として、「Androidのホーム画面追加後のstandalone表示では、ポップアップよりリダイレクトの方が安定しやすい」と書かれていて、これ自体は筋の通った判断です。しかし実際には、ブラウザ側のトラッキング対策の影響を受け、ログインの認証情報がアプリに戻ってこない、というバグにつながっていました。Fugu自身の動作確認では、この不具合を検出できていませんでした。
ただ、ここで一つはっきりさせておきたいことがあります。Fuguは今回、4AIの中で一番深く考え、一番先回りしようとしていたAIでした。それでも、唯一、実害のあるバグを残したのもFuguでした。
つまり、「深く考えて先回りしてくれること」と「その読みが実際に当たること」は、別の能力だということです。察する力は重要ですが、それだけでは足りません。
Codex：察して、外さなかった
Codexは11分51秒で完走し、実際の動作確認でもバグは見つかりませんでした。
一番の見どころは、やはりGoogleログインの実装です。Codexは「通常はsignInWithPopupを使い、ポップアップがブロックされたり未対応の環境ではsignInWithRedirectにフォールバックする」という二段構えの設計を、自分で考えて実装していました。
「こういう環境ではこう動かないかもしれない」という仮説を立て、それに対する保険をあらかじめ用意しておく。私が探していた"先回りしてくれるAI"に近い例だと感じました。
Fuguが見せてくれた粘り強さと違い、Codexの判断は地味です。派手な工夫があるわけではありません。それでも、先回りの読みが実際に機能していたという一点は評価できると思いました。
4. 横断的に見えてきたこと
個別のエピソード以外にも、4AIを並べてみて初めて分かったことがいくつかありました。
一つは、Firestoreというデータベースの仕様にまつわる技術的な落とし穴です。特定の条件でクエリを組み合わせると「複合インデックス」というものが必要になり、事前に用意していないとアプリがエラーで止まってしまう仕様があるのですが、これにGeminiとFuguはそれぞれ独立に気づき、どちらも「並べ替えの処理をアプリ側で行う」という同じ回避策にたどり着いていました。
Claudeは配列を使ったデータ構造の工夫によって、そもそもこの問題が起きにくい設計にしていました。単体モデルをCLIツールから動かす構成でも、地雷を踏まずに避ける力は、思っていた以上にありました。
もう一つ気づいたのは、同じ制約への向き合い方の違いです。GeminiもFuguも「ブラウザを直接操作できない」という同じ壁にぶつかっていました。Geminiは「できません」と申告したところで確認を止めましたが、Fuguは同じ壁の前で、HTTPの応答確認やJSONの妥当性チェックといった代替の検証手段にすぐ切り替えていました。同じ制約でも、そこで踏みとどまるか、代わりの道を探すかに、AIごとの姿勢の差が出ていました。
5. 評価基準に沿った総括
最後に、最初に決めた5つの基準に沿って振り返ります。
まず①人間がコードや設定に手を加えた回数は、4AIとも0回でした。実装が完了するまで、私は一切コードに触れていません。
②意図との乖離度は、機能やフロー全体としては4AIとも忠実で、要件からの逸脱はほとんどありませんでした。ずれが出たのはむしろビジュアル面で、配色やアプリ名のセンスにはそれぞれの個性が出ていました。
③判断の質は、3章で書いた通りです。「察する力」という一つの軸で並べると、先回りの読みが当たったCodex、外れたFugu、利用シーンをよく想像したGemini、タスクの外側まで見えていたClaude、という具合に、それぞれ違う種類の"察し方"を見せてくれました。
④実装完了までの時間は、Geminiの約3分が圧倒的で、Claudeが16分11秒ともっとも時間がかかりました。ただし、Geminiはブラウザ上での動作確認を自分では完了できていないため、この速さは「実装完了までの速さ」として見る必要があります。
⑤表に出たエラーは、Fuguのログイン不具合が唯一の実害あるバグでした。ただし、最も検証に粘ったFuguが、結果的には唯一の実害あるバグを残した、という事実は、単純な優劣では片づけられない今回の実験の面白さだと思っています。
6. 内省：線引きは誰が決めるのか
最初に立てた問いに戻ります。言語化には時間の壁があり、その余白を、AIはどう埋めてくれるのか。
結論から言うと、今回試した4つのAIのどれに任せても、筋トレの記録が見にくいという私の不満は、ほぼ解消されました。その意味では、どのAIも十分に「察して」くれたと言えます。
事前には、複数のAIを束ねるFuguのような仕組みは、言語化しきれない余白を埋めるのに強いのではないか、という期待も少しありました。けれど実際に並べてみると、結果はそれほど単純ではありませんでした。
Fuguは確かに細かく考え、検証にも粘りました。一方で、その読みが外れて実害ある不具合を残しました。逆にCodexは派手さはないものの、堅実な保険を用意して外しませんでした。だから今回見えたのは、「集合知が勝つかどうか」ではなく、「どの種類の余白を、どのAIに任せるとよさそうか」という問いでした。
この問いを考えるうえで、もう一つ避けられない問題があります。そもそも「どこまでAIに任せ、どこから自分がやるか」という線引きは、誰が決めるのか、という問題です。
私は、その線引きを決めるのは人間の仕事だと思っていました。実際、詳細設計書をあえて渡さなかったのも、その線引きを私が最初に決めた結果です。
ところがClaudeは、誰にも言われていないのに、「このFirebaseは共有インフラだから、自分の裁量では触らない」という、まさにその線引きを自分で見つけて、私に代わって引いてみせました。
線引きを決める仕事すら、少しずつAIに委ねられ始めているのかもしれない。そう思うと、少し落ち着かない気持ちにもなります。それでも、Fuguの一件を思い出すと、まだ全面的に委ねきる勇気は持てません。深く考えて先回りしてくれることと、その読みが当たることは別問題だからです。
今の私なりの答えは、こうです。線引きの最終判断は、当面は人間の側に残しておく。ただし、AIの側から提案されてくる"察し"には、真剣に耳を傾ける。任せきるのでも、疑い続けるのでもなく、AIが引いてきた線を人間が見直す。そのあたりに、今のちょうどいい距離感があるように思います。
むしろ、単純な勝ち負けで見ないからこそ、今回の観察は次につながります。Codexの読みの堅実さは実装判断そのものを任せるのに向いていそうですし、Geminiの速さは初期のプロトタイピングに、Claudeの周辺状況への配慮は成果物のレビューや監督役に、Fuguの粘り強い検証姿勢は品質チェックの一部に、それぞれ活かせるかもしれません。
7. むすび：次への問い
今回は、4つのAIそれぞれの「察する力」の個性を見ることができました。
次に気になるのは、この個性を活かして役割分担をさせたら何が起きるか、ということです。得意な部分を得意なAIに任せ、線引きの判断そのものも、少しずつAIに委ねていったら、どこまでうまくいくのか。それを確かめる実験を、次の記事で書きたいと思っています。
