Claude Codeチームの事例から考える、AI時代のon distributionな技術選定
皆さんはClaude Codeが、「エンジニアが仕事中に聴いている音楽をターミナルに表示する」 という、社内ツールから始まったことをご存知でしょうか？
プロトタイプの一つとして作られたこの音楽ツールが、ファイルシステムアクセスとbash機能を与えられて進化し、最終的にClaude Codeとなったそうです。
このエピソードは、Gergely Orosz氏による「How Claude Code is built」にて言及されました。
- Anthropic社では、Claude Codeの導入により、エンジニアの数を倍増させながら一人当たりの生産性（PR数）が67%向上
- Claude Code自身のコードの約90%は、Claude Code自身によって書かれている
- アーキテクチャは意図的にシンプルにされている
- より高性能なAIモデルがリリースされるたびに、不要になった古いコードは積極的に削除される
- ある機能（TODOリスト）の開発では、わずか2日間で20種類以上のプロトタイプが作成されたことも
- アーキテクチャは意図的にシンプルにされていて、モデルの強みを最大限に活かす思想
気になったことは沢山ありますが、そのうちの一つは技術選定についての言及です。
「モデルの強みを最大限に活かす（play to the strengths of the model）」 という思想に基づき、TypeScriptやReactといったAIが得意な 「on distribution」 な技術を意図的に選ぶ、というものでした。
今回は、on distributionな技術選定という、視点や事例について考えてみます。
結論から言うと、AIネイティブ or AIフレンドリーな技術選定は大事、という当たり前に聞こえる話を長めに書いています。
「on distribution」という考え方
「on distribution」の定義は、厳密には「学習に使ったデータと統計的に同じ性質を持つデータのこと」を指すようです。
今回のClaude Codeチームのインタビューにおいては、モデルが既に得意・よく知っている領域を指して語られています。逆に、モデルが苦手な領域のことは「off distribution」と呼んでいます。
本記事では、機械学習の厳密な定義とは別に、インタビュー記事の趣旨にも近い「モデルが学習データで十分に見てきた、得意な領域」をon distributionとして扱います。
In-Distribution (On-Distribution): AIモデルが学習に使ったデータと統計的に同じ性質を持つデータのことです。例えば、様々な種類の猫の画像で学習したAIにとって、新しい猫の画像は「In-Distribution」データです。AIは、このようなデータに対しては高い性能を発揮することが期待されます。
Out-of-Distribution (off distribution): AIモデルが学習データには含まれていなかった、全く性質の異なるデータのことです。猫の画像で学習したAIにとって、犬や車の画像は「Out-of-Distribution」データです。
Claude Codeから学ぶ「on distribution」
Claude Codeチームは、開発の初期段階でこの「on distribution」であることを意図的に重視していました。
オフディストリビューションスタックでも、モデルは学習できます。ただし、モデルに手順を教え、実際に作業させる必要があります。私たちが求めていたのは、教える必要のない技術スタック、つまりClaude Codeが自ら構築できるスタックです。そして、それはうまく機能しています。Claude Codeの約90%はClaude Codeで書かれています。
引用: How Claude Code is built
この思想のもと、彼らが選んだ技術スタックが下記です。
- TypeScript / React
- Ink (ReactベースのCLI用UIライブラリ)
- Bun (ビルドツール)
- Yoga（レイアウトエンジン）
構成自体はシンプル（CLIですし）で、特段の驚きはないスタックです。
とはいえ、TypeScriptとReactは、現代のLLMが学習した膨大なコードデータセットの中で、大きな割合を占める技術ではあるでしょう。
そして、これらはClaudeモデルにとってon distributionであるから選択したと述べられています。
Claude CodeはCLIツールという特性上、選択肢が限られていた面もあります。
Webアプリケーション開発においては、技術スタックだけでなく、開発ツールや実装パターンも含め、「AIが得意な土俵を意図的に選ぶ」という思想をより広く適用できるでしょう。
TypeScript/Reactという選択自体は目新しくなく、実感が湧きづらいですが、AIが得意な土俵を意図的に選んだという判断基準自体はこれからの技術選定における観点を示していると感じます。
言語による学習データの偏り
そもそもの話で言うと、学習データに対する言語やフレームワークの偏りは一定は存在することが予想されます。
コード関連タスクに特化したStarCoderは、80以上のプログラミング言語のコードなどを学習していますが、内訳を見てみると、86言語、783GBのコードの多くはJava,JavaScript,Pythonといった一部のWebアプリ系のメジャー技術で占められています。
詳しく見ると、Java (11%) が最大で、続いてMarkdown (10%)、JavaScript・Python・PHP (各8%)、C (7%)、C#・C++ (各6%)、Issues (7%)、Commits (4%)となっており、残りの78言語が25%を占めています。
「on distribution」を構成するものは何か
AIによるコード生成の恩恵は、「どのプログラミング言語を使うか」だけでなく、「どのような性質のタスクを任せるか」にも依存することは明らかです。
実際に、Cisco社が2024年6月に発表した「Transforming Software Development」では、大規模な独自コードベースを持つ実際のプロジェクトで、タスクごとの生産性向上を測定しています。
- Web開発やクラウドネイティブな環境で頻繁に利用されるJava、Go、Pythonといった言語で大きな効果を発揮します。
- 一方で、システムプログラミングで中心的な役割を担うC言語やC++では、AIの恩恵が少なく、有用なコードの生成に失敗するケースさえ報告されています。
https://arxiv.org/pdf/2406.17910から言語ごとの効率性の図
この差は、単純にデータの少なさとは言い切れません。要因は言語仕様の複雑さや多様な使われ方（低レベルのシステムプログラミング、組み込み、ゲーム開発など）が、Web開発に比べて生成が難しいという可能性もあります。
また、言語を問わず、定型的で反復的な性質を持つタスク（ボイラープレートコードの生成、シンプルなUIコンポーネントの実装、ドキュメント作成など) に効果を発揮する傾向にあります。
前述のCisco社の調査では、具体的な時間削減率として以下のタスクが挙げられています。
| タスク内容 | 時間削減率 | 詳細 |
|---|---|---|
| コードの文書化（コメント、Doxygen生成） | 最大50% | 最も顕著な時間削減が見られた領域 |
| コード自動補完 | 最大50% | 従来のIDE機能を大幅に上回る改善が見られた。 |
| 反復的コーディング（ボイラープレートなど） | 30〜40% | 定型的なコード生成において高い効果。 |
| 単体テスト生成 | 30〜40% | シンプルなケースで有効。テストカバレッジ向上に貢献。 |
| デバッグ（コンパイラエラー、リンターエラー） | 30〜40% | 特に問題が明確に記述されている場合に効果。 |
https://arxiv.org/pdf/2406.17910からタスクタイプごとの効率性の図
単なる言語の人気度だけでなく、タスクの性質そのものも深く関わっていることを示唆しています。つまり、ドキュメント作成や定型コードの生成といった、あらゆるプロジェクトで普遍的に見られる作業は、それ自体がAIにとっての「on distribution」な領域です。
一方で、企業独自の複雑で大規模なコードベースを扱う際にパフォーマンスが低下する傾向がはっきりと見られます。
この現象は、企業がAIコーディングアシスタントを導入する際に直面する典型的な「off distribution」の壁と言えます。
- 社内独自のAPI
- 企業固有の設計パターン
- ドメインに特化したビジネスロジック
結局のところ、単に言語の人気だけでなく、タスクの性質やコードベースの文脈に依存することを示しています。
off distributionとの向き合い方
とはいえ、MCPやllms.txt（LLMが参照すべきファイルやディレクトリを指定するファイル）などの登場もあり、AIがプロジェクト固有の文脈（off-distributionな情報）を収集する術は増え、そもそもモデル自体の性能も上がっています。
最近はConvexやTurso、Neonなどを利用することもありますが、新興のPFであり、おそらくon distributionと呼べるほど学習自体はされていないことが予想されます。
しかし、Claude Codeとの相性も抜群で、困ることは特にありません。
型安全なAPIや明確なドキュメントを提供しており、結果としてAIが理解しやすい、AIフレンドリーな構造になっているからだと考えています。もちろん、モデル自体のパワーや性能向上も含まれます。
コンテキストブリッジとも呼べる仕組みが整っていくことも影響して、将来的にはoff distributionな技術スタックを選択する際のハンディキャップは小さくなるかもしれません。
単に「古いか新しいか」ではなく、「AIが理解しやすい構造か」の見極めが本質です。
「AIフレンドリー」とだけ言っても、それは何も説明していないも同然です。「AIが理解しやすい構造か」への解像度や実践知、AIモデル自体の性能向上も鑑みて、どこが肝要であるかの見極めの力が求められています。
フライホイール効果は働くか
on distributionな技術の優位性と採用が増すとするならば、一種のフライホイール効果を生み出す可能性にも思いを馳せたくなります。
- 人気の技術スタック（例: React, TS）が、AIの主要な学習データとなる
- その結果、そのスタックがAIにとって「on distribution」となり、AIツールはそのスタックで高い性能を発揮する
- 開発者はAIの恩恵を最大限受けるために、その技術スタックを積極的に採用する
- 結果として、そのスタックで書かれたコードがさらに増え、次世代のAIにとっての学習データがよりリッチになる (1. に戻る)
このサイクルが回り始めると、メジャーな技術スタックはAIの進化と共にさらに強力になり、マイナーな技術との生産性ギャップはますます開いていくかもしれません。
IEEE Spectrumの2025年プログラミング言語ランキングの調査によれば、Stack Exchangeでの質問数も減少しており、週あたりの質問数は、2024年の水準と比較して22%にまで減少したそうです。
ClaudeやChatGPTとの対話で疑問を解決するようになったことを示しており、AIツールの普及により、プログラミングコミュニティの活動も大きく変化している様子が伺えます。
しかし、登場したばかりでコードのサンプルが少ない技術では、AIは質の高いコードを生成できず、既存の主要技術の人気が固定化される可能性もないとは言い切れません。
「AIレバレッジ」という軸
AIが開発プロセスの至る所に浸透してきている今、何を考えるにしても、AIレバレッジ（AI Affinity）、AIの能力をどれだけ引き出せるか？ という観点が頭にちらつきます。
AIは不慣れな技術に対しても、自信満々にコードを生成しようとします。
AIにとってon distributionな技術を選ぶことも、AIの能力にレバレッジをかける、AIの能力を出来るだけ引き出すための一つの方針です。
v0.appのように、出力するコードの技術スタックをあえて絞り込み、AI生成コードの品質と一貫性を担保する。これもAIの能力を引き出すための戦略と言えます。
Rethinking Technology Stack Selection with AI Coding Proficiencyのように（これは執筆中にたまたま見つけただけ）、LLMが得意な技術を見極めるノウハウ・ナレッジの探索は今後も進むはずです。
まとめ
技術選定も人間だけの都合で決めるものではなく、AIの得意・不得意を考慮に入れるべき時代に突入していますが、on distributionな技術選定は、AIとの協働を前提とした選択の一つです。
もちろん、AIモデルのパワーと進化をシンプルに信じるアプローチもあります。
（割と私はこちらのスタンスも強い、故に余計な凝ったアプローチを可能なら避けたい）
これは、AIにとって「on distribution」だろうか？ という問いを今後はもっと意識してみようと思いました。
もう一つ、個人的に 「on distributionってどう測る/判断するのか？」 に関心があります。
直感やセンス頼みでやってる自覚はあるので、もう少し実験的にやれないかを考えたい所存です。
今やっていることとしては、同じタスク・同じ指示で異なる技術を試したり、性能の低いモデル（Haikuやgpt-oss 20bなど）でも精度のばらつきが少ないかをチェックしたりしています。
今回は以上です！
Discussion