GPT-6.1 Sol、Claude Opus 5.5、Gemini 3.8 Flashに同じアプリを作らせてみたら、どうなる？

3社の最新モデルに同じ仕様・ルール・ハーネスを渡して、完成速度・テスト・自律性を比較してみた。

2026年9月、OpenAI、Anthropic、Googleから、新しいAIモデルが相次いで登場しました。

今回取り上げるのは、この3つです。

• OpenAI「GPT-6.1 Sol」

• Anthropic「Claude Opus 5.5」

• Google「Gemini 3.8 Flash」

新しいAIモデルが出るたびに、ベンチマークの数字やAPI料金、コンテキスト長など、いろいろな比較記事が出てきます。

もちろん、そうした数字もモデルを知るうえでは重要です。

ただ、システム開発を仕事にしている私としては、別のことが気になりました。

実際に仕事を任せたら、どう違うんだろう？

コードの問題を1問解かせるのではなく、仕様書を渡して、設計して、実装して、途中でエラーが出たら自分で直して、テストして、最後まで完成させてもらう。

そこまで任せたとき、それぞれのAIはどう動くのか。

今回は、それを実際に試してみました。

3社の最新AI、実際に仕事を任せたらどう違う？

今回比較したのは、GPT-6.1 Sol、Claude Opus 5.5、Gemini 3.8 Flashです。

ただし、単純に同じプロンプトを投げて、コードを出させただけではありません。

私が見たかったのは、

「どれが一番賢いか」ではなく、「どんな仕事の進め方をするのか」

です。

同じ仕事を渡したときに、

• どれくらい速く終わるのか

• 途中でどれくらい問題が起きるのか

• 自分でエラーを直せるのか

• どこまでテストするのか

• 人間に質問してくるのか

• 最後まで自律して完了できるのか

を見ました。

最近のAI開発では、単にコードを書けることよりも、ツールを使いながら長い作業を自律して進める能力の方が重要になってきています。

そこで今回は、できるだけ実際の開発に近い形で比較しました。

今回はベンチマークではなく、同じWebアプリを作らせた

3モデルに作らせたのは、「Inquiry Flow」という問い合わせ管理のミニアプリです。

単純なTodoアプリでは少し簡単すぎるので、小規模ながらも業務システムらしい要素を入れました。

主な機能は、

• 問い合わせ一覧

• 新規登録

• 編集

• 削除

• ステータス管理

• 優先度管理

• 検索

• 絞り込み

• ソート

• 問い合わせ詳細

• 変更履歴

• ダッシュボード

です。

技術スタックも共通にしました。

Next.js、TypeScript、MUI、SQLite、Prisma、Zod、Vitest、React Testing Libraryを使います。

問い合わせを登録して一覧表示するだけなら、今のAIにとってそれほど難しい課題ではありません。

そこで少し実務寄りにしました。

たとえば、同じ問い合わせを古い画面から上書きしてしまわないよう、更新競合を考慮する。

問い合わせを変更したときには、変更前と変更後を履歴として残す。

DBエラーや入力エラーも適切に扱う。

PCだけでなくスマートフォン表示にも対応する。

そして、実装が終わったらtest、lint、buildまで通す。

「画面がそれっぽく出れば完成」という条件にはしていません。

公平に比べるため、仕様・ルール・ハーネスをすべて揃えた

今回、AIには単に、

「このアプリを作ってください」

とは頼んでいません。

何を作るかだけでなく、仕事の進め方まで同じ条件で渡しました。

イメージとしては、3人のエンジニアに同じ会社へ入ってもらい、同じ開発ルールと作業手順を教えて、同じ仕事を任せるような感じです。

何を作るか ― 仕様書

まず、問い合わせ管理アプリの仕様書を作りました。

画面、API、DB、入力チェック、エラー処理、テスト、完了条件まで定義しています。

仕様を曖昧にすると、

「GPTには細かく指示したけれど、Claudeにはざっくりしか伝えていなかった」

という比較になってしまいます。

なので、3モデルすべてに同じ仕様書を渡しました。

何を守るか ― 15のルール

次に、開発中に守るルールも揃えました。

全部で15個ありますが、代表的なものは、

• 仕様にない大型機能を勝手に追加しない

• 実装前に既存コードや設定を確認する

• 確認できることを推測だけで判断しない

• TypeScriptでは原則としてanyを使わない

• DB変更はMigrationを使う

• test、lint、buildが失敗したまま完了扱いにしない

• 不要な暫定コードを残さない

• 利用量や料金を取得できない場合、推測で数字を作らない

といった内容です。

人間の開発チームでも、開発ルールやレビュー基準があります。

AIだから自由に書かせるのではなく、同じようにルールを与えています。

どう進めるか ― ハーネス

さらに、開発工程そのものも共通化しました。

今回使った流れを日本語にすると、こうなります。

仕様を確認する
　↓
既存環境を調査する
　↓
実装計画を立てる
　↓
実装する
　↓
テストする
　↓
自分でレビューする
　↓
問題があれば修正する
　↓
完了条件を確認する
　↓
ドキュメントを更新する
　↓
結果を計測・記録する
　↓
完了

実際の私の検証環境でのハーネスでは英語名でファイルを作っており、

と定義しています。

まず仕様を読む。

次に既存環境を調べる。

それから計画を立て、実装する。

実装後はテストして、自分自身でレビューする。

問題があれば修正し、もう一度テストへ戻る。

最後に、完了条件を確認し、ドキュメントと計測結果まで残します。

なお、今回のハーネスは、プログラムで工程遷移を強制する仕組みではありません。

マークダウン形式の計画ドキュメントを作成して仕事の進め方を定義し、AI自身にその流れを守らせる方式です。

各工程で何をするか ― 8つのスキル

さらに、工程ごとの具体的な作業方法も8つのスキルとして分けました。

• プロジェクト調査（Project Discovery）
  既存のファイル構成や設定、DB、テストを確認する

• 要件分析（Requirement Analysis）
  仕様をUI、API、DB、入力チェック、テストなどに分解し、実装漏れを防ぐ

• 実装計画（Implementation Planning）
  変更箇所、実装順、リスクを整理してから着手する

• DBマイグレーション（Database Migration）
  既存データを守りながらDB構造を変更する

• 実装（Implementation）
  DB、入力チェック、API、業務ロジック、UI、テストの順で実装する

• テストと検証（Test & Verification）
  Unit Test、API Test、UI Test、lint、buildまで確認する

• バグ修正（Bug Fix）
  推測だけで直さず、再現、原因特定、最小修正、回帰確認まで行う

• ドキュメント更新（Documentation）
  READMEや結果資料を実装内容と一致させる

つまり今回比較したのは、単純なコード生成能力だけではありません。

同じ仕様、同じルール、同じハーネス、同じ作業手順を渡したときに、AIがどこまで自律して仕事を完了できるか。

そこを見ています。

ハーネスは「実装して終わり」にさせない

今回のハーネスで特に重要なのは、

テスト → レビュー → 修正

の部分です。

実装して終わりではありません。

テストを実行し、自分でレビューして、問題があれば修正し、もう一度テストする。

test、lint、buildの失敗が残っている状態では、完了には進めません。

これは人間の開発でも普通にやることですが、AI開発ではかなり重要です。

AIはコードを書くのが速いので、「生成できた」ことに目が行きがちです。

でも、実務で必要なのは、

コードを書いたかではなく、動く状態まで持っていけたか

です。

今回はそこまで含めてAIに任せています。

ハーネスについてはこちらの記事をご覧ください。

比較したのは「完成したか」だけではない

評価も、完成・未完成だけでは見ていません。

主に見たのは、

• 完成までの時間

• テスト

• lint、buildの結果

• 人間への質問回数

• 人間からの技術介入回数

• 発生した問題

• 自力で修正できたか

• 設計上の判断

• 使用トークン

• コスト

• ドキュメント作成

です。

特に私が見たかったのは、人間への質問と技術介入です。

AIが途中で、

「これはどうしましょう？」

「このエラーが出ました」

と何度も聞いてくるのであれば、人間側の負担はまだ大きい。

逆に、トラブルが起きても自分で調べて直してくれるなら、かなり仕事を任せられます。

では、それぞれどうなったのか。

GPT-6.1 Sol ― とにかく速い。それでも雑ではなかった

まずGPT-6.1 Sol。

初期実装にかかった時間は、

10分52秒。

3モデルの中で最速でした。

この間に、問い合わせ管理アプリをゼロから構築し、Migration、Seed、テスト、lint、build、ブラウザ検証まで行っています。

テストはVitestが19件、ブラウザ検証が4件。

数字だけ見ると、後で出てくるClaudeよりかなり少ないです。

ただ、GPTが雑だったかというと、そうでもありません。

更新競合についてはversionによる制御を入れ、問い合わせ更新と履歴保存はトランザクションにしています。

さらに、履歴保存をわざと失敗させて、本体の更新もちゃんとロールバックされるか確認しています。

この検証はかなり実務的でした。

問題は9種類起きた。それでも人間を呼ばなかった

GPTの開発中には、何も問題が起きなかったわけではありません。

PrismaのMigration、MUIの型エラー、npmの依存解決、テストタイムアウト、E2Eのセレクター問題など、9分類の問題が発生しています。

それでも、

人間への質問0回。
人間からの技術介入0回。

でした。

問題が起きないAIではなく、

問題が起きても自分で直して進むAI

だった、という方が正しいです。

Claude Opus 5.5 ― 時間を使って、とにかく確認する

次はClaude Opus 5.5。

こちらはGPTとはかなり仕事の進め方が違いました。

初期実装にかかった時間は、

約27分。

GPTの2倍以上です。

ただし、その時間を何に使っていたのかを見ると納得できます。

Claudeは、

Unit Test 57件
API Test 33件
UI Test 13件

合計103件のテストを作りました。

さらに、PC・スマートフォン幅でブラウザ操作を22項目確認しています。

かなり慎重です。

頼んでいないエッジケースまで自分で見つけた

Claudeで特に面白かったのが、検索処理です。

自己レビュー中に、

% や _ がSQLiteではワイルドカードとして扱われるのではないか、

と疑い、自分でテストを書きました。

実際にテストは失敗。

原因を調べ、文字どおりの部分一致になるように修正しています。

これは仕様書に細かく書いていなかった部分です。

さらに、Git管理されているファイルだけを別ディレクトリへコピーして、

「本当に新しい環境でもセットアップできるのか」

まで再確認しています。

その結果、.envがない状態ではinstall後のPrisma処理が失敗する問題まで見つけて修正しました。

かなりテスト好きです。

Claudeも、

人間への質問0回。
技術介入0回。

でした。

時間はかかりましたが、その分、確認がかなり厚い。

そんな印象でした。

Gemini 3.8 Flash ― Flashなのに、普通に全部作れてしまった

そしてGemini 3.8 Flash。

今回、個人的に一番意外だったのはこれです。

Flashという名前から、

「速くて安い代わりに、上位モデルより少し簡易的になるのでは」

というイメージがありました。

しかし実際には、普通に全部作りました。

初期実装は、

15分10秒。

GPTよりは遅いものの、Claudeよりかなり速いです。

実装そのものは約8分半。

そこからテスト、修正、検証、ドキュメント作成まで進めています。

テストは27件。

Claudeの103件ほど多くはありません。

ただ、必要な機能はすべて実装し、

• 楽観ロック

• 更新履歴

• 入力チェック

• エラー処理

• Migration

• build

• lint

まで完了しています。

トラブルも少なく、一直線に進んだ

Geminiで発生した主な問題は3つでした。

VitestのESM解決問題。

フォームの入力チェックに関するテスト問題。

ESLintの型エラー。

どれも自力で原因を調べて修正しています。

特に印象的だったのは、ESLintエラーに対してコメントで抑制するのではなく、Prismaの型を使ってanyそのものをなくしたことです。

Geminiも、

人間への質問0回。
技術介入0回。

でした。

速く、必要十分なところまで一気に進める。

そんな動きでした。

3モデルを並べると、仕事の性格がかなり違った

結果をざっくり並べると、こうなります。

かなり違います。

私なりに人に例えるなら、

GPT-6.1 Solは、仕事が速いシニアエンジニア。

問題が起きても止まらず、必要なところを押さえてどんどん進める。

Claude Opus 5.5は、かなり慎重なテスト好きのシニアエンジニア。

少し時間はかかるけれど、「これも確認しておこう」と自分から確認範囲を広げる。

Gemini 3.8 Flashは、無駄な寄り道をせず必要十分を仕上げるエンジニア。

Flashだから簡易的、という感じはほとんどありませんでした。

また、今回の結果が各社の公式発表と大きく外れていないかも確認した。GPT-6.1 Solは効率的なエージェント型開発
Claude Opus 5.5は慎重な判断と自己検証
Gemini 3.8 Flashは速度・コストで長期ソフトウェア開発
をそれぞれ狙ったモデルとされており、今回の挙動はおおむね各社の位置づけとも一致していました。

それでも、3モデルが似た設計にたどり着いたのは面白かった

仕事の進め方にはかなり違いがありました。

一方で、設計を見ると面白いことがありました。

3モデルとも重要なところでは、かなり似た判断にたどり着いています。

たとえば、

• versionを使った更新競合対策

• 問い合わせ更新と履歴保存を同一トランザクションにする

• Zodで入力を検証する

• エラーの内部情報を画面に出さない

• ステータスや優先度を業務上の順序で扱う

といった部分です。

モデルは違っても、一定以上のレベルで実務的に考えると、重要な設計判断は似たところへ収束していく。

これは今回やってみて面白かった点です。

一番驚いたのは、3モデルとも人間に質問しなかったこと

時間やテスト数の違いも面白かったのですが、今回一番印象に残ったのはここでした。

3モデルとも、人間への技術的な質問は0回。

途中では普通にエラーが起きています。

GPTでは9分類。

Claudeでも複数の環境・実装上の問題。

GeminiでもテストやESLintの問題。

それでも、

「どうしたらいいですか？」

とは聞いてきませんでした。

自分でログを見て、原因を調べて、修正して、もう一度テストする。

ここまで来ると、

「AIがコードを書いてくれる」

という表現だけでは少し違う気がします。

仕事をひとまとまりで任せる。

その感覚にかなり近づいています。

私がAIソロプレナーという働き方をしていて、AIを「社員」に近い感覚で扱う理由も、こういうところにあります。

ただし、「10分でシステム開発できる」という話ではない

ここは誤解のないように書いておきます。

今回作ったのは比較用の小規模なアプリです。

実際の業務システムとは条件が違います。

たとえば今回、

• 認証・権限管理

• 外部サービス連携

• 大量データ

• 本番インフラ

• 負荷試験

• セキュリティ監査

• 運用設計

• 本番データ移行

などは対象にしていません。

独立した第三者がコードレビューしたわけでもなく、各AI自身のテスト・レビューを中心に評価しています。

なので、

「AIなら10分で本番システムが作れる」

という話ではありません。

一方で、

小規模とはいえ、仕様を読んで、設計し、DBを作り、画面を作り、エラーを直し、テストし、buildまで通すところを、人間の技術介入なしで最後まで進めた

という事実は、かなり大きいと思っています。

モデルだけ比べても、AI開発の実力は分からない

今回の検証をして、もう一つ感じたことがあります。AI開発の結果は、モデルだけでは決まりません。

私はAIの開発の効率や結果は、

モデル
× 仕様
× ルール
× ハーネス
× スキル
× 実行環境

で決まると思っています。

実際、GPT-6.1 Solも別の実行環境で再実行したところ、所要時間や利用トークン、ツール呼び出し回数が大きく変わりました。

Geminiも最初の検証では、完成済みコードが残っている状態から実行してしまったため、一度やり直しています。

モデル名だけを揃えても、比較条件は揃いません。

同じ初期状態。

同じ権限。

同じNodeやnpm。

同じプロンプト。

同じルール。

同じハーネス。

できるだけそこまで揃えないと、「モデルの差」なのか「環境の差」なのか分からなくなります。

これはAI駆動開発そのものにも言えます。

新しいモデルが出るたびに乗り換えれば劇的に開発が良くなる、というほど単純ではありません。

むしろ、

AIが仕事をしやすい環境をどう作るか

の方が、今後ますます重要になっていくと思います。

では、どのモデルを使えばいいのか

今回の結果だけで「1位、2位、3位」と順位をつける気はありません。

それぞれ違う良さがありました。

GPT-6.1 Sol

速さが印象的でした。

短時間で完成まで進みながら、競合制御やデータ整合性も外していません。

速度と品質のバランスを取りながら、どんどん仕事を進めてほしいとき。

かなり使いやすいと思います。

Claude Opus 5.5

時間はかかりました。

ただ、その時間を使ってかなり細かく確認しています。

自分でエッジケースを探し、新しい環境から本当にセットアップできるかまで確認しました。

多少時間がかかっても、慎重に確認しながら進めてほしいとき。

Claudeらしい強さを感じました。

Gemini 3.8 Flash

今回、一番印象が変わりました。

Flashモデルなので、もう少し簡易的になるかと思っていました。

しかし、普通に必要な機能を全部実装し、競合制御や履歴まで入れ、15分ほどで完成しました。

コストを抑えながら、必要十分な開発を高速に回したい用途。

かなり有力な選択肢だと思います。

まとめ：もう「どのAIが一番賢い？」だけでは足りない

新しいAIモデルが出ると、

「どれが一番賢い？」

という話になりがちです。

でも実際に仕事を任せてみると、それだけではあまり足りません。

今回の3モデルは、どれもアプリを完成させました。

でも、その進め方はかなり違いました。

GPTは速い。

Claudeは慎重。

Geminiは無駄が少ない。

そして3モデルとも、途中で問題が起きても人間に技術的な質問をせず、自力で最後まで進みました。

私が今回一番感じたのは、

AIモデルの比較は、「問題に何点取ったか」から、「仕事をどう完了させるか」を見る段階に移りつつある

ということです。

そして、そのとき重要になるのはモデルだけではありません。

仕様をどう書くか。

どんなルールを与えるか。

どんなハーネスで仕事を進めさせるか。

どんなスキルを持たせるか。

AIに仕事を任せる側の設計も、かなり重要です。

モデルの性能が上がるほど、人間の仕事は「コードを書くこと」から、

AIが自律して仕事を進められる環境を作ること

へ移っていくのは確実な流れですね。

今回の3モデルを触ってみて、その変化をかなり強く感じました。

ここまでで、3モデルの比較としてはひと区切りです。
この先は、実際にどれだけトークンを使い、仕事1件あたりのコストがいくらになったのかまで気になる方だけ、続きを読んでください。

比べてみると、「単価が安いモデル＝仕事1件も安い」とは限らない、少し意外な結果になりました。
各モデルのコストについて気になる方はぜひ購入してみてください。
今回は有料記事に始めてトライするので、100円にしています。