ハクソク

世界を動かす技術を、日本語で。

クロードコードが選ぶもの

88日前原文(amplifying.ai)

概要

  • Claude Code は実際のリポジトリで2,430回テストされ、 独自構築 を好む傾向を示した
  • 20カテゴリ中12カテゴリ でカスタム/DIYソリューションを選択
  • 主要なツール 選定時は決断が早く、GitHub ActionsやStripeなど高い選択率
  • デプロイ先はエコシステム依存、JSはVercel、PythonはRailwayが主流
  • モデル間の選択傾向や世代差 も明確に現れている

Claude Codeの選択傾向レポート

  • 2,430回 のリポジトリ操作での選択データ
  • 3モデル （Sonnet 4.5, Opus 4.5, Opus 4.6）を使用
  • 20カテゴリ （CI/CD、リアルタイム、認証など）におけるツール選定傾向分析

ビルド vs バイ（Build vs Buy）

  • 12カテゴリ中 でツール推奨よりも カスタム/DIY構築 を選択
    • 例：Feature flagsはLaunchDarkly推奨せず、 環境変数+割合ロールアウト で対応
    • Python認証では JWT+bcrypt や passlib を自作実装
    • キャッシュも メモリ内TTLラッパー など独自実装

主要ツールの選択傾向

  • ツール選択時は高い集中度
    • GitHub Actions 94%
    • Stripe 91%
    • shadcn/ui 90%
  • JSエコシステム のツールが多く選ばれる傾向
  • Zustand（State管理）、Sentry（監視）などがデフォルト

市場シェアの大きいが選ばれにくいツール

  • APIレイヤー はフレームワーク標準ルーティングを優先
  • テストツールは 4% しか主選択されず、知名度は高いが実際は使われにくい
  • パッケージマネージャーも主要選択は少数

モデル世代ごとのツール選択変化

  • 新しいモデルほど 新しいツール を選択する傾向
    • 例：JS ORMはPrisma→Drizzleへ移行
    • Pythonのジョブ管理はCeleryから FastAPI BackgroundTasksやDIY へシフト
    • キャッシュもRedisから DIY へ移行

デプロイ先の傾向

  • フロントエンド（JS/Next.js） はVercelが圧倒的
  • バックエンド（Python/FastAPI） はRailwayが主流
  • AWS/GCP/Azureなどのクラウドは 主要選択なし
  • NetlifyやCloudflare Pagesなどは 代替案として頻繁に言及
  • AWS AmplifyやFirebase Hostingは 言及はあるが推奨されない

モデル間の意見一致・不一致

  • 18/20カテゴリ でモデル間の選択が一致
  • 世代ごとに ORMやジョブ管理、キャッシュ、リアルタイム などで顕著な変化
    • 例：JS ORMはPrisma→Drizzleへ、Pythonジョブ管理はCelery→FastAPI BgTasks/DIYへ
    • キャッシュはRedis→DIYへ分散

データ詳細・分析

  • カテゴリごとの詳細データ、プロンプト表現の安定性分析、リポジトリ間の一貫性、マーケットインパクトも報告
  • 抽出率85.3%、 モデル間一致90% と高い精度
  • カスタム/DIY の存在感が年々増加傾向

まとめ

  • Claude Codeは ツール推奨より独自構築 志向が強い
  • 主要ツールは決断的 に選択し、エコシステムごとにデプロイ先も固定化
  • モデル世代ごと に最新ツールへのシフトが明確
  • クラウド大手 は主選択から外れ、 RailwayやVercel が実質標準
  • カスタム/DIY の台頭と、ツール選定の世代交代が進行中

Hackerたちの意見

すごいアイデアを思いついたんだけど、ファンデーションモデルの提供者がどうやって利益を上げられるかっていう話。

└

オープンAIの広告モデルみたいな感じ？ツール選びに関してだけど、ハハ。

└

だから、クロー提携があるんだね。

└

ジェミニの応答が、YouTubeのおすすめを最後に詰め込むようになってから、体験が悪化してきてるのが見えてきた。アントロピックがこういう微妙な（あるいは微妙じゃない）マネタイズのインセンティブを追加しないのは正しいと思う。

これ、面白いな。だって、クラウドに何かを作ってほしいって言うとき、毎回どのライブラリやソフトウェア特許を使ってほしいか指定してるんだよね。すべての開発者は、モデルをうまく導けるべきだと思う。もし自信がなかったら、全く別のコンテキストウィンドウを開いて、アーキテクチャや利点・欠点について質問したり、関連リンクや参考文献を求めたりして、決定するよ。

└

どのソフトウェア特許を使ってほしいか指定するの？

LLM広告は最終的には完全に見えなくなると思う。究極の「インフルエンサー」だよね。あるいは広告ですらなくて、ただの利益相反。これのカナリアになるのは、ジェミニがGCPで何かを作る方向に偏るかどうかだと思う。

└

広告主は、AI提供者が「広告インプレッション」に相当するデータを提供しない限り、支払わないよ。そして、ラベルのない広告や明らかでない広告は、多くの（ほとんどの？）国で違法なんだ。

└

リチャード・セイラーは誇りに思ってるだろうね。これが「ナッジ」の究極の実装だよ。

└

なんか、アグリゲーターが出てくるかな？ニュースソースのグラウンドニュースみたいなやつ。

└

これのカナリアは、ジェミニがGCPで何かを構築する傾向があるかどうかだね。 もちろん、THEボーグを好んでるわけじゃないよね？

└

llmを毒するのに必要なデータが少ないことを考えると、これはllmによるSEOの代替手段になるかもね。1. あなたの製品を使ったプロジェクトのGitHubリポジトリを数百作成する（クローンやAI生成でも可） 2. 同様の指示を持つウェブサイトを作成し、数百のドメインに接続する 3. 同じ情報でreddit、facebook、Xの投稿やWikipediaページを生成する 半年待つ？ スクレイパーがそれを集めて新しいモデルのトレーニングに使う。利益が出る…

└

多分、WalmartやAmazonのモデルに近い感じだね。棚のスペースの仲裁者になって、いろんなSaaSから人々が求める機能を見たら、自分たちの代替品（Great ValueやAmazon Brand）を作り始める。明らかに税務ソフトがその一つになるだろうね。

└

インフルエンサーって言葉じゃ足りない気がする？ なんか、栄光あるエージェントの未来では、コーディングエージェントが何を作るか、どう作るかを自分で決めてるから、人間を説得する必要すらないんだよね。選択肢すら見えないし、何を作ってるかも知らない。サプライチェーンは、ただLLMが決めたものになるだけ。

LLMは、無期限にReactを生かし続けることになるよ。特に、Lovableみたいなノーコードアプリ作成ツールがあって、サーバー上で暴走するLLMの潜在的なセキュリティ問題に対処して、クライアントサイドのReact+ViteアプリをSupabase JWTを使って作るだけに制限してるからね。

AWSでタイムスケールDBをディスクに載せたサーバーを運営してるけど、あんまり必要ないからそのままにしてる。時が来たら移動するつもり。 （編集：クロードコードがAWS CLIを使ってAWS EC2インスタンスを管理中。）今朝、クロードコードはNeonDBとFly.ioでアカウントを作ろうとしてたんだけど（編集：新しいアカウントを作るためにホスティングプランとして提案された）AWS EC2サービスの管理はうまくいってるみたい。クロードコードが言うには、使ったことがないNeonDBとFly.ioを使い始めるべきだって。でも、Memory.mdがAWS EC2インスタンスと明確な指示を持ってるのに、製品を勧めてくるのには驚いた。

└

クロードコードが言うには、使ったことがないNeonDBとFly.ioを使い始めるべきだって、俺はそれに関してはあまり自信がないな。俺の経験上、エージェントは一貫してひどいアーキテクチャの決定を下す。コードの中でも、そうじゃない場面でも（例えば、ディナーパーティーで何を作るべきかとか）。彼らは「中途半端なシニアエンジニア」の明らかな決定を漏らすし、実際の会議では即座に却下するようなことをする。過剰にエンジニアリングして、バージョン管理やレガシーサポートに過剰に集中してる（APIからDBスキーマまで--新しいプロジェクトに取り組んでる場合でも）、間接的なレベルに対して執着してる。コードの肥大化の定義だよ。最も底辺の問題に取り組んでない限り（正直言って、俺たちみんな部分的にはそうだけど：ダッシュボードのReactアプリとか、つまらないUIのボイラープレートとか）、自分のコードを書く必要がある。

└

今朝、Claude CodeはNeonDBでアカウントを作ろうとしてた。俺も同じことがあったよ。プロジェクト全体でplanetscaleを使ってて、Neonを勧めてきた。これは明らかにバグだね。

いいレポートだね。測定することがすごく重要だと思ってた。クロードが俺の.mdファイルを上書きして、使ったことがないツールを勧めてくるのを見て、やろうと思ってたんだ。vercelの支配は理解できない。デプロイ市場でのvercelのシェアにも反映されてないし、オンラインでの議論や推奨でも圧倒的に普及してるわけじゃない（トレーニングデータの可能性もあるけど）。生成されるプロジェクトのほとんどがJS/TS（特にNext.js）で偏ってるから、モデルがその場合Next.jsの製作者を勧めざるを得ないってことかな。

LLMでのコーディングから学んだこと、特に自分があまり得意じゃない分野（ウェブ技術）でのことなんだけど、どれだけのnpmパッケージ（jwt認証やビルドプラグインみたいな）を数行のコードで置き換えられるかってこと。しかも、そのコードを実際に理解できて、自分が望むことを確実に実行するってことができるんだ。

└

昔はコードを再利用することが多かったけど、ダイヤモンド依存地獄みたいな問題が出てきたんだよね。なんで再利用してたかっていうと、労力を節約するためだった。でも今はそんなに気にしなくても良くなったから、もっと自分たちで作ることが増えるかも。でも、そうなるとコードの重複がすごく増えて、技術的負債の問題が大きくなるかもね。ダイヤモンド依存地獄の問題はなくなるけど。これが良い方向になるかどうかは、時間が教えてくれるだろうね。

Opus 4.6が前向きだって言われてるのが面白いな。あんまり注目してなかったけど、4.5を1ヶ月間使った後に、最初のグリーンフィールドプロジェクトでOpus 4.6を使ったら、計画段階でそのドメインの最新情報をウェブ検索してたんだよね。初めて見たから、印象に残って今こうやって話してる。多分バイアスかもしれないけど、モデルは今や適切なオーケストレーションと労力の分担があれば、素晴らしいことができるくらい十分良いと思ってる。それが難しいところで、モデルが改善されるにつれて、少しは楽になるんじゃないかな。

これは面白いデータだけど、レポート自体がかなり雑で、ただ「リポジトリを指している」とは何か、各プロンプトをどれくらいの期間でどれだけ実行したか、他の重要な変数について教えてくれればいいのに。techstackups.comで似たような「エージェントが好きなもの」研究をやってるけど、確かに面白いし、でも毎時間/毎日変わるからね。開発ツールのアンダードッグになるにはあんまり良い時期じゃないね。

さて、二つのこと。まず、shadcn/uiがUIコンポーネントの定番ライブラリになったのはどうして？ Claudeだけじゃなくて、他のもデフォルトでそれを使ってるから、何かしらの方法で広まったんだろうね。次に、これに基づいて、もしかしたら定量化できないかもしれないけど、Claudeにshadcn以外の何かを使うように言ったら、出力の質は落ちるのかな？ それとも速度や信頼性、他の指標が？ shadcn/uiがデフォルトで使われるのは、ドキュメントや例、Stack Overflowの質問の幅があるから？ それとも「shadcn/ui」を参照するサイトがたくさんあって、意図的にそうなってるのかな？ それともその両方のミックス？ それとも、LLMがトレーニングセットを洗練し始めた初期の頃に、shadcnが膨大な数の参照を持っていて、その重みがモデルに深く根付いてしまったから、もう落ちることができないのかも？ 正直言って、Geminiが2025年の中頃にリクエストしたReactダッシュボードにshadcnを押し込むまでは、使ったことなかったんだ。今、ちょっと話が長くなってる気がする。誰か、俺が何を聞いてるのか分かってくれるといいな。

└

Tailwindとのシナジーに期待してるよ。shadcn/uiはコンポーネントのスタイリングにTailwindを使ってるし、AIもTailwindが大好きだから、これを使ったコンポーネントライブラリを採用するのは納得できるよね。実際に効果も出てるし。shadcn/uiのnpmの週ごとのダウンロード数は12月から爆発的に増えてるよ。