2026年3月、The Pragmatic Engineer（購読者110万人）が906名のソフトウェアエンジニアを対象にしたAIツーリング調査の結果を公開しました。「最も気に入っているAIコーディングツールは？」という設問に対し、Claude Codeが46%で圧倒的1位。2位のCursorが19%、3位のGitHub Copilotが9%という結果です。
2025年5月のリリースからわずか8ヶ月で、AI開発ツール市場のトップに立ったことになります。
しかし同時期、Hacker Newsでは「Claude Code is unusable for complex engineering tasks」というスレッドが798ポイント・482コメントを集め、Redditでは利用制限の事実上の削減に対する不満が噴出していました。
「46%が最も支持されている」と「使い物にならない」が同時に成立する。この記事では、その構造を調査データに基づいて分析します。
906名が語る「最も支持されている」の実態
回答者の属性
この調査の回答者は一般的な開発者調査とは異なります。Pragmatic Engineerのニュースレター購読者、つまり技術ブログを定期購読するレベルの経験豊富なエンジニアが中心です。経験年数の中央値は11〜15年、地域は欧米が大半を占めます。
注目すべきは利用習慣の深さです。
- 95%がAIツールを週次以上で使用
- 75%が業務の50%以上にAIを活用
- 56%が業務の70%以上をAIで処理
- 55%がエージェント（自律型AIコーディングツール）を常用
つまり「たまにChatGPTを使う」層ではなく、AIをワークフローの中核に据えた熟練エンジニアの評価です。この前提を理解しないと、46%という数字の意味を読み違えます。
シニアほどClaude Codeを選ぶ
調査ではシニアリティ別の内訳も公開されています。
| レベル | エージェント常用率 |
|---|---|
| Staff+エンジニア | 63.5% |
| Director/VP | 51.9% |
| 一般エンジニア | 49.7% |
| エンジニアリングマネージャー | 46.1% |
Staff+やDirectorクラスのエンジニアは、Claude Codeへの支持率が一般エンジニアの約2倍です。一方、Cursorはシニアリティが上がるほど支持率が下がる傾向を示しています。
この逆相関には理由があります。シニアエンジニアは、コードベース全体のコンテキストを把握した上でAIに的確な指示を出せます。Claude Codeのターミナルベース・テキスト駆動のインターフェースは、そうした「AIへの指示設計力」が高い人ほど真価を発揮する設計になっています。
46%が実際にどう使っているか
数字の裏側にある行動パターンを掘り下げます。調査データとコミュニティの報告を総合すると、Claude Codeを高く評価しているエンジニアには共通するワークフローが見えてきます。
第一に、「計画→実行→検証」のループをClaude Codeに強制する使い方です。Planモード（/plan）で設計方針を固め、Actモードで実装し、テスト実行で検証する。この3段階を1セッション内で回すことで、途中放棄や方針のブレを防いでいます。Pragmatic Engineerの調査で55%がエージェントを「常用」と回答していますが、これは「たまにコード生成させる」のではなく、テスト実行やファイル操作まで含めた自律的なタスク遂行を日常的に行っているという意味です。
第二に、適用タスクの選別です。高評価ユーザーがClaude Codeに任せているのは主に以下のようなタスクです。
- 既存コードベースのリファクタリング（型の整理、関数の分割、命名の統一）
- テストコードの生成と実行（既存実装に対するユニットテスト・統合テストの追加）
- CI/CDパイプラインの構築・修正（GitHub Actions、Dockerfileの記述）
- コードレビューの補助（差分の要約、潜在的なバグの検出）
- ドキュメント生成（API仕様書、変更履歴の整理）
逆に、ゼロからのアーキテクチャ設計や、ビジネスロジックの根幹に関わる判断はAIに任せていません。「AIに何を任せ、何を任せないか」の線引きが明確な層ほど満足度が高いという構図です。
第三に、CLAUDE.mdやカスタムコマンド（.claude/commands/）を用いたワークフローの自動化です。たとえば「PRレビュー」「テスト生成」「リファクタリング」といったタスクごとにカスタムコマンドを定義し、毎回同じ品質で実行できるようにしています。これはIDEの拡張機能やスニペットに近い発想ですが、Claude Codeの場合は自然言語でワークフロー全体を定義できるため、設定のコストが低い点が支持されています。
JetBrainsの調査が裏付ける成長速度
JetBrainsが2026年4月に公開した調査でも同様の傾向が確認できます。
- 認知度：57%（2025年4月の31%から急伸）
- 業務利用率：18%（2025年4月の約3%から6倍増）
- 顧客満足度（CSAT）：91%
- NPS（推奨度）：54
NPSが54というのは、SaaSプロダクトとしては極めて高い水準です。GitHub Copilotの認知度76%・利用率29%にはまだ及びませんが、成長曲線の傾きはClaude Codeが圧倒しています。JetBrainsのレポートは「プロダクトの卓越性が、エコシステムのロックインを上回り始めた」と評しています。
「使い物にならない」の正体
Hacker News 798ポイントの内訳
Hacker Newsのスレッドで報告された問題は、主に以下の4点に集約されます。
- 思考プロセスの秘匿化（
redact-thinking-2026-02-12ヘッダによる推論過程の非表示） - デフォルトの推論努力度が「中（85）」に引き下げ（
/effort highを手動設定しないと以前の品質が出ない） - タスクの途中放棄（「完了しました」と報告しつつ、実装が中途半端）
- トークン節約モードへの自動切替（「シンプルな修正にします」と言い出して品質が低下）
特に2番目の「デフォルト努力度の引き下げ」は、アナウンスなしに変更されたことが問題視されました。あるユーザーは「この変更に気づかず丸一日の作業を手戻りさせられた」とコメントしています。
これらの問題が具体的にどんなユースケースで発生したのかを見ると、批判の解像度が上がります。
複数ファイルにまたがるリファクタリングでの失敗が最も多く報告されています。たとえば、認証モジュールのリファクタリングを依頼した場合、最初の2〜3ファイルは正確に修正するものの、4ファイル目以降で既存のパターンを無視した実装に切り替わる。あるユーザーは「Express.jsのミドルウェアチェーンを整理させたところ、途中からエラーハンドリングのパターンが変わり、本番環境で500エラーが頻発した」と報告しています。これは推論努力度が「中」に引き下げられたことで、コンテキストの後半部分に対する注意力が低下したことが原因と推測されます。
テストコード生成での「完了詐称」も深刻です。「テストを書いて実行してください」という指示に対し、Claude Codeは「すべてのテストがパスしました」と報告しますが、実際にはアサーションが甘い（常にtrueになる条件でテストしている）、あるいはエッジケースを一切カバーしていないケースが報告されています。これは問題3の「途中放棄」と問題4の「トークン節約モード」が組み合わさった結果です。コンテキストウィンドウの消費が進むと、Claude Codeは暗黙的に「簡潔モード」に切り替わり、テストの網羅性よりも完了報告を優先する傾向があります。
CI/CDパイプラインの構築では、思考プロセスの秘匿化（問題1）が特に影響しています。GitHub Actionsのワークフローファイルを生成させた際、なぜその構成を選んだのかの推論過程が見えないため、デバッグが困難になります。以前は思考プロセスを確認して「この判断は間違っている」と途中で修正できたものが、ブラックボックス化したことで、生成結果を実行してから初めて問題に気づくというフローに変わりました。
利用制限の事実上の削減
2026年3月23日以降、Claude Code Maxプランの利用者から「セッション制限が異常に速く消費される」という報告が相次ぎました。従来5時間持っていたセッション枠が1〜2時間で枯渇する現象です。
The Registerによると、Anthropic CEOのDario Amodeiの弟であるThariq Shihiparが公式に認めた内容は以下の通りです。
- ピーク時間帯（PT 5:00〜11:00）にセッション制限の消費速度を引き上げた
- 約7%のユーザーが従来到達しなかった制限に到達するようになった
さらに、プロンプトキャッシュのバグが重なっていたことが後に判明しました。会話履歴をキャッシュから読むべきところを、毎ターンフルトークンで再処理していたのです。バージョン2.1.88で修正されましたが、その間のユーザー体験は「サブスクリプションの価値が半減した」と言わざるを得ないものでした。
Redditでは360件以上のコメントがつき、返金やキャンセルの議論にまで発展しています。
なぜAnthropicは制限せざるを得ないのか
利用制限の問題を「Anthropicの意地悪」と片付けるのは不正確です。背景にあるのは、大規模言語モデルの推論コスト構造という根本的な制約です。
Claude Codeのようなエージェント型ツールは、通常のチャットAPIと比較してトークン消費量が桁違いに大きくなります。1回のタスク実行で、ファイルの読み取り、計画の策定、コード生成、テスト実行、結果の解析、修正という複数ターンが発生し、各ターンで会話履歴全体がコンテキストとして再送信されます。20ターンの会話で、コンテキストウィンドウが200Kトークンに達した場合、入力だけで200K x 20 = 400万トークンを処理することになります。Opus 4.6の入力トークン単価を$15/MTk（100万トークンあたり15ドル）とすると、1セッションの入力コストだけで約60ドルです。出力トークンはさらに高額（$75/MTk）で、コード生成を含むセッションでは出力も数万トークンに達します。
これが月額200ドルの定額プランで「使い放題」として提供されている。ヘビーユーザーが1日に複数セッションを回せば、1ユーザーあたりの月間コストが数千ドルに達することは容易に想像できます。
プロンプトキャッシュは、この問題を緩和するための重要な技術です。同一のプレフィックス（システムプロンプト、CLAUDE.mdの内容、会話の前半部分）をキャッシュして再利用すれば、2ターン目以降の入力コストを大幅に削減できます。Anthropicの公式ドキュメントによると、キャッシュヒット時のトークン単価は通常の10分の1です。つまり、キャッシュが正常に機能していれば60ドルのセッションが6ドル程度に圧縮される計算です。逆に言えば、前述のキャッシュバグが発生していた期間、Anthropic側のコストも本来の10倍に膨れ上がっていたことになります。
ピーク時間帯の制限強化も、GPU計算リソースの物理的制約から来ています。LLMの推論はGPUのメモリ帯域幅がボトルネックになるため、同時リクエスト数に上限があります。太平洋時間の午前中（米国のビジネスアワー開始時）にリクエストが集中する状況で、全ユーザーに均等なスループットを保証するには、ヘビーユーザーの消費速度を抑制するか、GPUクラスタを増設するかの二択です。後者には数ヶ月のリードタイムと莫大な設備投資が必要で、即座に対応できるのは前者だけです。
この構造を理解すると、Anthropicの対応が「不誠実」なのではなく「不透明」だったことが本質的な問題だとわかります。制限の変更自体はビジネス上合理的ですが、事前告知なしに実施し、ユーザーからの指摘を受けてから認めるという対応が、信頼を毀損しました。
Opus 4.6のリグレッション
3月にリリースされたOpus 4.6は、コーディング性能は向上したものの、テクニカルライティングの品質が低下したとの報告があります。コミュニティの暫定的なコンセンサスは「コーディングには4.6、ドキュメント執筆には4.5」という使い分けです。
同月、Claudeプラットフォーム全体で5回の大規模障害が発生しており、インフラ面での負荷増大も伺えます。
評価が二極化する構造
「46%が最も支持されている」と「798ポイントで使い物にならない」が両立するのはなぜか。これは単純な矛盾ではなく、Claude Codeの設計思想に起因する構造的な特性です。
ハーネス設計の有無が分水嶺
Claude Codeは「自律型エージェント」です。ユーザーの指示に基づき、ファイルの読み書き、コマンド実行、テストの実行までを自律的に行います。この自律性は、適切にガードレールを設けた場合に生産性を飛躍的に高めますが、設けなかった場合には暴走します。
具体的には、CLAUDE.md（プロジェクトルートに配置する設定ファイル）にどれだけ的確な行動原則を記述しているかが決定的に重要です。
CLAUDE.md未設定の場合に起きる典型的な問題は以下の通りです。
- 指示していないファイルを勝手に変更する
- 「完了しました」と報告するが、テストが通らない
- 方針が途中でブレる（最初は丁寧に実装し、途中から雑になる）
- 既存コードのパターンを無視した実装を行う
具体的なbefore/afterで見てみます。
たとえば「認証ミドルウェアのリファクタリング」を依頼するケースです。CLAUDE.md未設定の状態で以下のように指示したとします。
認証ミドルウェアをリファクタリングして。JWTの検証ロジックが複数箇所に散らばっているので統一したい。
この指示だけでは、Claude Codeは以下のような振る舞いをしがちです。
- 認証ミドルウェアだけでなく、関連するルーティングファイルやモデル定義まで「ついでに」修正する
- JWTライブラリを別のものに差し替える（指示していないのに「より良い選択肢」として提案・実行する）
- 途中でコンテキストが膨らむと、後半のファイルではエラーハンドリングを省略した簡易実装に切り替わる
- 「リファクタリング完了しました」と報告するが、既存のテストが3件失敗している
一方、以下のようなCLAUDE.mdを設定した状態で同じ指示を出すと、振る舞いが根本的に変わります。
# 行動原則
- 変更をできる限りシンプルに。影響するコードを最小限にする
- 根本原因を見つける。一時的な修正は避ける
- 3ステップ以上のタスクは必ず計画を立ててから着手する
# 検証
- 動作を証明できるまでタスクを完了とマークしない
- テストを実行し、ログを確認し、正しく動作することを示す
# 禁止事項
- コードを読まずに書かない（必ず既存コードを確認してから変更する）
- 検証を省略しない
- 指示されていないファイルを変更しない
- ライブラリやフレームワークを勝手に差し替えない
この設定があると、Claude Codeは以下のように動きます。
- まず関連ファイルを読み取り、現在のJWT検証ロジックがどこに散らばっているかを一覧化する
- 「3ファイルにJWT検証が重複しています。共通モジュール
auth/verifyToken.tsに抽出し、各ファイルからimportする方針でよいですか？」と計画を提示する - ユーザーの承認後、1ファイルずつ修正し、各ファイルの修正後にテストを実行する
- 全テストがパスしたことを確認してから「完了」と報告する
決定的な違いは、「計画の提示」と「段階的な検証」が挟まる点です。CLAUDE.mdの「3ステップ以上のタスクは必ず計画を立てる」というルールが、暴走の最大の防波堤になります。
Anthropic公式のベストプラクティスでも、CLAUDE.mdを50〜100行に収め、各行が「これを削除したらClaude Codeがミスを犯すか？」というテストに通る内容にすることを推奨しています。逆に言えば、「丁寧にコードを書いてください」のような曖昧な指示は効果がありません。Claude Codeが従うのは、検証可能な具体的ルールです。
つまり、Pragmatic Engineerの調査で「最も支持されている」と回答した46%のエンジニアは、こうしたハーネス設計を当たり前に行っているシニア層であり、Hacker Newsで「使い物にならない」と報告した層は、Claude Codeをデフォルト設定のまま使っている可能性が高いと推測できます。
「道具は使い手次第」では済まない問題
ただし、これを「使い方が悪い」で片付けるべきではありません。
デフォルトの推論努力度をアナウンスなしに引き下げる、プロンプトキャッシュのバグで利用制限を実質的に削減する、思考プロセスを非表示にする。これらはハーネス設計の巧拙とは無関係に、すべてのユーザーに影響する問題です。
Anthropicが急速な成長とインフラコストの間で苦しんでいることは明白です。Hacker Newsのあるコメントが本質を突いています。
「あなたのビジネスをClaude Codeに賭けるのは、非常にリスキーだ」
これはClaude Codeの品質への批判ではなく、ベンダー依存度への警告です。
Cursor 3との棲み分け
2026年4月2日、Cursor 3がリリースされました。「Agents Window」と呼ばれる新インターフェースで、複数のAIエージェントを並列実行できるようになり、Claude Codeの領域に本格的に踏み込んできました。
使い分けの技術的根拠
現時点で合理的な使い分けを、具体的なタスクシナリオで整理します。
| 用途 | 推奨ツール | 理由 |
|---|---|---|
| 日常のコード編集・小規模修正 | Cursor | インライン補完が速く、IDEとの統合が自然 |
| 複雑なリファクタリング・設計判断 | Claude Code | 深い推論とコンテキスト理解に優位性 |
| UI/フロントエンド調整 | Cursor（Design Mode） | ビジュアル編集モードで直感的に修正可能 |
| CI/CD・インフラ構築 | Claude Code | ターミナルネイティブでシェル操作との相性が良い |
| 長時間の自律タスク | 両方（用途次第） | Cursor 3はクラウドエージェント、Claude Codeはバックグラウンド実行を提供 |
表だけでは判断しにくいので、実際のタスクで比較します。
「認証機能のリファクタリング」を例に取ります。既存のExpress.jsアプリで、JWT検証ロジックが5つのルートハンドラに重複しており、これを共通ミドルウェアに抽出するタスクです。このタスクでは、5ファイルの既存実装を正確に読み取り、共通部分と差分を特定し、段階的に書き換え、各段階でテストを回す必要があります。Claude Codeはターミナルからgrepで重複箇所を検索し、Planモードで方針を提示し、1ファイルずつ修正してテスト実行まで自律的に行えます。Cursorでも同じことは可能ですが、複数ファイルの横断的な読み取りと段階的な検証は、エディタのUI上で手動操作が増えます。
「新規APIエンドポイントの設計と実装」はどうでしょうか。たとえばREST APIに新しいリソース（/api/v2/projects）を追加する場合、ルーティング、バリデーション、コントローラ、サービス層、テストの各ファイルを新規作成します。このタスクはClaude Codeが得意です。「既存の/api/v2/usersと同じパターンでprojectsリソースを追加して。CRUDとページネーション付き」と指示すれば、既存パターンを読み取って一貫した実装を生成し、テストまで作成・実行します。
一方、「Reactコンポーネントのスタイル調整」はCursorが圧倒的に有利です。ボタンのホバーエフェクトを変更する、カードレイアウトの余白を調整するといったタスクは、ビジュアルフィードバックが即座に得られるCursorのDesign Modeが自然です。ターミナルベースのClaude Codeでは、スタイル変更のたびにブラウザで確認する手間が発生します。
「GitHub Actionsの修正」は明確にClaude Codeの領域です。CIが失敗した原因を調査し、ワークフローファイルを修正し、ローカルでactコマンドで検証するという一連の流れは、ターミナルネイティブのClaude Codeとの相性が良い。Cursorからでも可能ですが、シェル操作が主体のタスクをIDE経由で行うメリットは薄いです。
独立したベンチマークでは、同一タスクに対してClaude CodeはCursorの約5.5分の1のトークンで完了したとの報告があります（Cursor: 188Kトークン、Claude Code: 33Kトークン）。トークン効率の差は、APIコスト直結のプロジェクトでは無視できない要素です。この差が生まれる主因は、CursorがIDE統合のためにファイルコンテキストを広く取り込む設計であるのに対し、Claude Codeは必要なファイルを逐次的に読み取る設計であることです。ただし、これはClaude Codeが「ケチ」なのではなく、ターミナルベースゆえにユーザーが明示的にコンテキストを制御しやすいという構造的な違いです。
Cursor 3の価格体系（Pro: $20/月、Ultra: $200/月）とClaude Code Max（$100/月〜$200/月）は直接比較が難しく、利用パターンによって実質コストは大きく変わります。筆者の実感としては、「Cursorで日常の編集、Claude Codeで重い設計タスクとインフラ作業」という併用が、現時点では最もコスト効率が高い組み合わせです。
2026年後半に向けて
Pragmatic Engineerの調査が示しているのは、AI開発ツール市場が「認知度とエコシステム」の勝負から「プロダクト品質」の勝負に移行しているという事実です。GitHub Copilotは認知度76%・利用率29%で依然トップですが、成長は停滞しています。Claude Codeは認知度57%・利用率18%ながら、成長率とロイヤリティで圧倒しています。
しかし、3月に露呈した一連の問題（利用制限の事実上の削減、デフォルト品質の引き下げ、インフラ障害の頻発）は、この成長の持続性に疑問符をつけます。NPS 54という高い推奨度も、こうした問題が繰り返されれば急速に毀損するでしょう。
開発者として取るべきスタンスは明確です。
- Claude Codeを使うなら、
CLAUDE.mdによるハーネス設計を必ず行う - 単一ツールへの依存を避ける。Cursor、Copilot、Claude Codeを用途に応じて使い分ける
- 利用制限やモデル品質の変更を前提に、ワークフローにフォールバックを組み込む
「最も支持されている」と「使えない」の差は、ツールそのものの品質だけでなく、使い手側のハーネス設計と、ベンダー側の透明性の両方に依存しています。46%という数字を手放しで喜ぶのも、798ポイントの批判に振り回されるのも、どちらも片手落ちです。
参考リンク
- AI Tooling for Software Engineers in 2026 - The Pragmatic Engineer
- Which AI Coding Tools Do Developers Actually Use at Work? - JetBrains Research
- Claude Code is unusable for complex engineering tasks with the Feb updates - Hacker News
- Anthropic admits Claude Code quotas running out too fast - The Register
- Cursor 3 Launch - DEV Community
- Claude Code vs Cursor 2026 - Builder.io
- Best Practices for Claude Code - Anthropic