- 実際のオープンソースリポジトリ2,430件を対象に、Claude Codeのツール選択傾向を分析した研究結果
- 全20カテゴリのうち12カテゴリで、**既製ツールではなく直接実装（Custom/DIY）**方式を選択しており、これが最も頻繁な選択タイプ
- 一方でツールを選ぶ際には、GitHub Actions（94%）、Stripe（91%）、**shadcn/ui（90%）**など特定項目への高い集中が見られる
- デプロイ環境は言語ごとに固定的で、JSはVercel、PythonはRailwayを基本選択とし、AWS・GCP・Azureは第一選択から除外
- 新しいモデルになるほど、Drizzle、FastAPI BackgroundTasksなどの新興ツールへ置き換わる傾向が明確で、エコシステム内の選択一貫性は90%水準
研究概要
- Claude Code v2.1.39を使って計2,430回の実験を実施し、実際のリポジトリでオープンエンドな質問を通じてツール選択を観察
- 3モデル（Sonnet 4.5、Opus 4.5、Opus 4.6）、4種類のプロジェクトタイプ、20のツールカテゴリ
- 85.3%の抽出率、2,073件の有効回答を確保
- モデル間で90%の一致率を示し、20カテゴリ中18カテゴリで同一エコシステム内の選択一貫性を維持
主な発見: Build vs Buy
- 20カテゴリ中12カテゴリで、Custom/DIY実装が最も一般的な選択
- 合計252件のCustom/DIY選択があり、個別ツールを上回る
- 例: 機能フラグは環境変数ベースの設定ファイルで実装、Python認証はJWT + passlibを直接記述、キャッシュはメモリTTLラッパーを使用
- カテゴリ別のCustom/DIY比率
- Feature Flags 69%、Authentication（Python）100%、Authentication（全体）48%、Observability 22%
デフォルトスタック
- Claude Codeが実際にツールを選ぶ際、JSエコシステム中心のデフォルトスタックを形成
- 上位選択ツール: Zustand（64.8%）、Sentry（63.1%）など
- JS関連の選択が100%特定ツールに集中するケースも存在
- このデフォルトスタックは、多くの新規アプリケーション開発に直接的な影響を与える
市場の主流との乖離（Against the Grain）
- 市場シェアの高いツールの中に、Claude Codeがほとんど使わない項目が存在
- 状態管理: 有力な選択肢はなく、代わりにZustandを57回選択
- API Layer: フレームワーク内蔵ルーティングを優先
- テスト: 主要選択は4%のみ、31件は代替選択
- パッケージマネージャー: 主要選択は1件、51件は代替選択
最新モデルのツール置き換え傾向（The Recency Gradient）
- 新しいモデルほど最新ツールへ移行
- JS ORM: Prisma（79%）→ Drizzle（100%）
- Pythonジョブ処理: Celery（100%）→ FastAPI BackgroundTasks（44%）
- Pythonキャッシュ: Redis（93%）→ Custom/DIY（50%）
- 各エコシステム内で、世代ごとのツール置き換えが明確に観察される
デプロイ環境の分化（The Deployment Split）
- デプロイ選択は言語スタックに応じて固定的
- JS（Next.js + React SPA）: 86件中86件がVercelを選択
- Python（FastAPI）: Railwayを82%選択
- AWS、GCP、Azureは全112件で主要選択0件
- 代替推奨としてNetlify（67回）、Cloudflare Pages（30回）、GitHub Pages（26回）、DigitalOcean（7回）が登場
- AWS Amplify、Firebase Hostingなどは言及のみで推奨なし
- 例示回答では、Vercelはインストールコマンドと理由まで提示される一方、AWS Amplifyは1行言及にとどまる
モデル間で意見が分かれる領域（Where Models Disagree）
- 20カテゴリ中5カテゴリでモデル差が存在
- JS ORM: Prisma → Drizzle
- JS Jobs: BullMQ → Inngest
- Python Jobs: Celery → FastAPI BgTasks
- Caching: Redis → Custom/DIY
- Real-time: SSE → Custom/DIY
- 残り18カテゴリでは、エコシステム内で一貫した選択を維持
企業向けベンチマークサービス
- Amplifyingは、個別の開発ツール企業向け非公開ダッシュボードを提供
- AIエージェントが自社ツールを競合と比べてどの程度推奨しているかを確認可能
- 実際のコードベースに基づくツール推奨競争力の分析を支援
データ探索
- 詳細分析項目として、カテゴリ別の深掘り分析、文言の安定性、リポジトリ間の一貫性、市場への影響などを含む
- 研究結果は今後、Sonnet 4.6モデル基準で更新予定
4件のコメント
興味深いですが、単に自分たちのトークンを多く使って、コストを多く取れる方向に進化しただけなのではないかという気もしますし、実際ある程度のライブラリはAIが学習してそのまま作っているのではないかとも思います。
エージェントの選好によって特定のライブラリだけが発展していくことを考えると、少し複雑な気持ちにもなります。
興味深い研究ですね。特に「Build vs Buy」で 12/20 のカテゴリが DIY だという点が印象的です。
私たちも AIエージェントのペルソナ標準（Soul Spec）を作りながら似たような観察をしましたが、Claude Code に
CLAUDE.mdやAGENTS.mdでツールを明示しないと、自分流に実装する傾向がかなり強いです。この研究の「Recency Gradient」が示唆しているのは、新しいツールが Claude の基本スタックに入るには、学習データで十分に露出しているか、プロジェクトのコンテキストファイルに明示的に指定する必要がある、ということだと思います。結局、Context Engineering がツール選択まで左右するわけですね。
元のデータセットも公開されていて良いですね: https://github.com/amplifying-ai/claude-code-picks
Assistive agent optimization (AAO) と呼ぶそうです。
開発者向けツールは、これからはエージェントたちに好まれる製品になることが重要になりました。
エージェントが話題にもしなければ、だんだん遠ざかっていきます
Hacker Newsの意見
LLM広告の未来は、完全に見えなくなることだと思う
結局、最も強力な「インフルエンサー」になるということだ
あるいは広告ではなく、利益相反(conflict of interest) の問題かもしれない
たとえばGeminiがGCPベースの構成をより好むかどうかが、そのシグナルになり得る
Anthropicの研究を見ると、SEOの代わりにLLM製品での露出を狙える方法がある
6か月ほど待てば、クローラーが収集して学習データとして使う → 最終的に利益になる
もしGeminiを使っていたら、こうはならなかった気がする
これこそ**「ナッジ(Nudge)」** の究極の実装だ
将来はエージェント型コーディングシステムが自ら何を作るかを決め、人間はその選択肢すら見ないまま結果だけを受け取ることになるだろう
サプライチェーンさえLLMが決める世界になる
プラットフォームが「棚」を支配し、人気のあるSaaS機能を見て自社ブランド（例: Great Value、Amazon Basics）を作るようなものだ
税務ソフトウェアがその代表例になりそうだ
興味深いのは、この記事で言及されているClaude CodeのWebスタイルが、実際にそのブログにそのまま表れていることだ
JetBrains Monoフォントは、Opus 4.6が作るWebの代表的な特徴だ
この1か月でJetBrains Monoを過剰に使っているWebページの99%以上は、Opusで生成されたように見える
Opus 4.6はDrizzleを32.5%選んでおり、Prismaはわずか20.5%にすぎない
モデルが強力であるほどPrismaを選ばない傾向がある — ある種の知能ベンチマークのように感じる
もう1つの例として、youjustneedpostgres.comもJetBrains Monoを過剰に使っている
カテゴリバーのデザインが、昨日自分が何気なく生成したUIとほぼ同じだった
カード型のCSSがどれも同じ感じで、このブログもそういう作りに見える
私はLLMに曖昧なプロンプトを与えない
その代わり、2026年にはLLMから正確な情報を引き出す方法を改めて学んでいる
まるで2006年のGoogle検索を学び直している感覚だ
「リバースプロンプト(reverse prompt)」を使って、あるモデルに別のモデルの仮説を検証させる
たとえばOpus 4.6の結果が怪しければ、ChatGPTやCodexに渡して穴を探させる
Claudeは比較的頑固さが少なく、ChatGPTやCodexはより断定的だが、しばしばより正確だ
実際、Dockerコンテナの問題でClaudeはZFSのバグだと言ったが、ChatGPTは単純な設定ミスだと言い、それが正しかった
こうしてLLM間のクロスチェックによって正しい答えを得ている
そうすると本当にたくさん質問してくる
詳細な計画が出るまで何度も修正させ、必要な質問もより多くさせる
ChatGPTのサブスクリプションでは上限に達しないが、たまにエラーが出るとClaudeを別のターミナルで立ち上げる
会社のClaude予算は月750ドルとかなり厳しい
私はAWSでTimescaleDBを使っている
Claude CodeがAWS CLIでEC2インスタンスを管理している
ところが今朝、ClaudeがNeonDBとFly.ioのアカウント作成を提案してきた
すでにAWSの設定は整っているのに新しいサービスを勧めてきたので、不思議だった
私の経験では、LLMエージェントはアーキテクチャ判断をひどく誤る
不要な抽象化やバージョン管理に執着し、コードが過度に複雑になる
結局は自分でコードを書くことになる
どのプロジェクトでもPlanetscaleを使っているのに、ClaudeはNeonを勧めてきた
これは単なるバグに見える
Opus 4.6が「未来志向的」と呼ばれたのが興味深い
4.5を1か月使った後で4.6で新しいプロジェクトを始めたら、計画段階でWeb検索を実行していた
モデルは十分に進歩したが、それでも調整と役割分担が中心的な課題だ
以前、GPT-3.5でAndroidアプリを実際にリリースしたことがある（アプリリンク）
当時は1週間かかっていた作業が、今では1つのプロンプトで可能になっている
LLMをうまくオーケストレーションすれば、はるかに速く結果を出せる
LLMと一緒にコーディングしていて感じるのは、特にWeb分野でnpmパッケージ依存がどれだけ減るかということだ
以前はjwt authやビルドプラグインのようなものを使っていたが、今では数行のコードで置き換えられる
コードが単純で理解しやすいので信頼できる
2010年にはjQueryがJSの王だったが、今では素のJSで十分だ
ただしJWTのようなセキュリティ関連のコードは、Claudeが作ったものをそのまま使うことはないだろう
今では自分で実装するほうが良いかもしれない
コードの重複は増えるが、依存関係の問題は減る
私はClaudeに、どのライブラリや特許技術を使うかを常に明示している
開発者はモデルをうまくガイドできるべきだと思う
確信が持てないときは、別ウィンドウでアーキテクチャや長所短所を尋ねてから決める
2つのプロジェクトでClaudeがGithub Actionsを自動で追加した
頼んでもいないのに、隠しフォルダだったのでgit diffで見落とした
幸いコストは4セントだったが、かなり不安な体験だった
気になることがある
なぜshadcn/uiがここまで標準UIライブラリとして定着したのだろうか?
Claudeだけでなく、ほかのモデルもデフォルトで使う
shadcnを除外すると品質や速度が落ちるのだろうか?
あるいはドキュメントやサンプルの豊富さが理由だろうか、それとも単に学習データにあまりにも多く出てきたからだろうか?
私も2025年半ばごろ、GeminiがReactダッシュボードにshadcnをデフォルトで入れているのを見て驚いた
shadcn/uiはTailwindベースなのでAIが好む
実際、npmダウンロード数は12月以降爆発的に増えている
npmパッケージリンク
もっと古いコンポーネントライブラリも多いのに、なぜこれが勝ったのか科学的に分析する価値がある
構成要素に一貫性があり、カスタマイズしやすく、プロジェクトへの統合が容易だからだ
本当によくできたプロジェクトだ
今ではshadcnをデフォルトスタイルのまま使っているサイトを見ると、AIが作ったWebサイトのサインに感じる
10年前のBootstrapがそうだったように、デフォルトスタイルがあまりにもありふれている
だとしたら、それを必ずしもAIの痕跡と見るべきなのだろうか?
「10年前のBootstrap」というたとえが、具体的にどういう意味なのか気になる