複数のAIコーディングツール、数百のセッション：率直な比較

AIコーディングアシスタント市場は細分化し、率直な比較が難しくなっています。宣伝資料はどれも楽観的で、ベンチマークは各ツールの強みに有利な設計です。比較記事の多くは、重要な傾向が見えてくる数か月の実務経験ではなく、各製品を数時間試した人が書いています。私たちは、練習用ではなく本番のコードベースで、Claude Code、Cursor、Gemini CLI、OpenCode、Qwen Codeを使い、数百回のセッションを重ねました。その結果、より実態に即した姿が見えてきました。これらの観察は、2025年11月までに私たちが使用したツールのバージョンに基づいています。機能、制限、料金は急速に変わるため、個々の記述を判断の根拠にする前に、各提供元の最新ドキュメントを確認してください。

主な発見は、どれか1つがあらゆる場面で優れているということではありません。各ツールは異なる目的に向けて最適化されており、その違いは継続的に使って初めて分かります。何のために作られたツールかを理解すると、強みも失敗の傾向も説明できます。

Claude Code：ターミナル中心の実務向けツール

Claude Codeは独自の位置にあります。既存のエディターにチャットを追加する拡張機能ではなく、高度なエージェント機能を持つCLIツールです。この設計の影響は、使い続けるほど明確になります。

強みは、複数工程のタスクを自律的に進める能力です。範囲が明確な仕様を渡すと、関連ファイルを読み、既存のパターンを理解し、実装を書き、テストを実行して失敗を修正します。開発者が各工程を指示する必要はありません。コンテキストウィンドウの管理は、試したツールの中で最も優れています。大規模なコードベースを適切に扱い、他のツールでは難しい長時間のセッションでも、一貫した状態を維持します。

ただし、この自律性には両面があります。構造化された実装作業で力を発揮する能力が、仕様の曖昧なタスクでは過剰な対応につながることもあります。大きなコードベースに曖昧な指示を与えると、望まない判断を下す可能性があります。継続して使って分かったのは、Claude Codeでは仕様を厳密に定めることが効果的だという点です。出力品質はプロンプトの品質に直接左右されます。仕様、受け入れ基準、明示的な制約を整えて計画する開発者は、会話だけで進める開発者より大幅に良い結果を得られます。

ターミナルを中心とする設計では、IDE連携は二次的な位置付けです。インライン提案、リアルタイムのTab補完、エディター内のチャットパネルを求める開発者には、Cursorほど自然な作業感は得られません。Claude Codeは、行単位ではなくタスク単位で考える開発者に向けて最適化されています。

Cursor：IDE内のAI支援の基準

Cursorは、インラインのAI支援で引き続き基準となるツールです。Tab補完は、時折役立つ提案をするという程度ではありません。編集中のファイルの書き方や規約に合う複数行の補完を、入力のリズムが変わるほどの精度で予測します。長く使うと、この補完がない環境は後退したように感じます。

Composerとエージェントモードも大きく成熟しました。文脈が明確な単一ファイルや少数ファイルの変更では、範囲を適切に限定した、整った編集を行います。採用前に変更内容を正確に確認できるインライン差分レビューは、今回比較したツールの中で最も使いやすいものです。

弱点は、規模が大きく、複数箇所にまたがる変更で表れます。コンテキストの取得は良好ですが、突出してはいません。実装しようとするパターンが別の場所にすでに存在することを見落としたり、読み込まなかったファイルの既存規約と衝突する方法を提案したりすることがあります。小規模から中規模のタスクでは対処できますが、多数のファイルに及ぶアーキテクチャ変更では、事前分析がより徹底したClaude Codeより多くの誘導が必要です。

料金体系も論点です。Cursorの料金プランはチームでの利用に手間を生み、一部モデルのリクエスト上限は都合の悪いタイミングで作業を中断させます。個人開発者には小さな不便でも、チームでは調整の負担が積み重なります。

Gemini CLI：Googleのインフラ戦略

Gemini CLIはGoogleのインフラを背景に登場し、コンテキストウィンドウも大きいため、コードベースの規模で困ることはめったにありません。1つのプロンプトで推論できるコード量という純粋な容量では、多くの代替ツールを上回ります。非常に大きなモノレポを扱う開発者にとって、この点は重要です。

しかし、多くのコーディングセッションでは、コンテキストウィンドウの大きさが制約ではありません。より重要なのは、得た文脈をどう使うかです。この点で、私たちのセッションではGemini CLIの動作に一貫性がありませんでした。実行するより先に、何をするかを長々と説明するなど、応答が冗長になりがちです。コードは概ね正しいものの、実際のコードベースの実用的な規約より、教科書的なパターンを優先する場合もあります。

Googleのエコシステムとの連携は、予想どおり優れています。Cloud Run、BigQuery、Firebaseなど、Google Cloudをすでに活用するチームには、他のツールにない組み込みの知識が役立ちます。IAM設定を理解し、適切なクライアントライブラリを提案し、大幅な修正なしで動くデプロイ設定を生成します。Googleのエコシステムの外では、この優位性はなくなります。

MCPサーバーへの対応も注目点です。Gemini CLIはModel Context Protocolのエコシステムに力を入れており、外部データソースやツールにつなぐことで、単なるコード生成を超えた用途に使えます。MCPを前提とする基盤を構築するチームには、ツール利用を後付けで扱う製品より自然に適合します。

OpenCode：柔軟な設定という価値

OpenCodeは、特定のモデルに依存しない、柔軟なターミナルツールとして位置付けられています。自分のAPIキーを使い、好みのモデルを設定して、ローカルまたはリモートの推論を利用できます。技術構成全体を管理したい開発者にとって、この価値は実際にあります。

実務での評価は一様ではありません。上級ユーザーに魅力的な設定の自由度は、設定作業や例外対応の多さにもつながります。他のツールが広範なユーザーテストで磨いたワークフローほど、仕上がっていない部分もあります。ツールは動作し、モデル非依存のアーキテクチャも技術的に妥当ですが、既定の動作が明確なツールより積極的な管理が必要です。

OpenCodeが力を発揮するのは、オフラインや隔離された環境、そしてデータの保存・処理地域に関する要件で外部APIにコードを送れない組織です。Ollamaなどの推論サーバーを通じてローカルモデルを使える機能は、こうした用途で有用です。それ以外では、標準の操作体験により多くの開発工数を投じたツールと比べ、設定の自由度による利点より運用の手間が大きくなるのが一般的です。

Qwen Code：オープンソースの候補

Qwen Codeは、Gemini CLIをベースに改変されたオープンソースのターミナルエージェントで、Qwenのオープンソースモデル群と緊密に統合されており、性能と費用の関係で異なる位置にあります。セルフホスト可能なモデルを利用できるため、大量処理では商用APIにはない費用面の利点があります。ドキュメント、テスト、定型コードなどを大量に生成するチームでは、費用の構造が大きく異なります。

性能には明確な限界があります。複雑なアーキテクチャの推論、見つけにくいバグの検出、複数ファイルのリファクタリングでは、Qwen Codeは商用ツールに及びません。モデルの世代ごとに差は縮まっていますが、誤った変更の損失が大きい本番の作業では、品質差は依然としてツール選択に影響します。

Qwen Codeが価値を示した実用的な用途は、影響の小さい大量生成、特に多言語環境です。中国語の能力が高いため、英語と中国語のコードベースやドキュメントを扱うチームには重要です。

実際に重要なパターン

数百回のセッションを通じて最も明確になったのは、最良のツールは何かではなく、各ツールが成功する条件です。どのツールも、見慣れないコードベースで曖昧な指示を受けると、予測できる形で失敗します。一方、明確なタスク、関連する文脈、動作の仕組みを理解して適切に誘導できる操作者がいれば、どのツールも良い結果を出します。

AIコーディングツールを最も有効に使う開発者は、最良のツールを見つけた人ではありません。ツールの性質に合わせて作業する習慣を身に付けた人です。仕様の品質に時間をかけ、制約を明示し、出力を注意深くレビューし、AIを技術判断の自律的な代替ではなく、能力は高いものの文脈に限界がある協働相手として扱います。

ツールは重要です。それ以上に、使う側の規律が重要です。

AIエージェントによる開発：本番で実際に機能するもの — エージェントのワークフローにおける、ベンチマーク結果と運用の信頼性の差。
AIコーディングアシスタントによる仕様駆動開発 — 複雑なタスクで、構造化した仕様が会話形式のプロンプトより一貫して良い結果を生む理由。
コード生成のためのセルフホスト型LLM：実用面からの評価 — ローカル推論が経済的に合理的な条件と、そのために妥協する点。