はじめに
「なぜClaude CodeはターミナルCLIなのか？」「なぜUIやガイドレールを極力排除しているのか？」「なぜCLAUDE.mdに書くことが重要なのか？」
これらの疑問に答えるのが、Claude Code創設者Boris Chernyの設計思想だ。ツールの「なぜ」を知ることで、使い方の質が変わる。
開発の原点：「UIを作る手間を省きたかっただけ」
Boris Chernyが2024年9月にAnthropicに入社した時、担当はチャットボット開発だった。Claude APIを学ぶために個人的に始めたターミナルチャットアプリが、全ての始まりだ。
ターミナルを選んだ理由：「UIを作る必要がなかったから」——これだけだ。深い設計思想ではなく、最初は純粋に「早く動かしたい」という理由だった。
最初の重要なツールとしてbash toolを実装した時のエピソードがある。tool useの実験中に「今聴いている音楽は？」と聞いたところ、ClaudeがAppleScriptを自作してMusicアプリから曲名を取得してきた。
「これが私が初めてAGI感を覚えた瞬間だ」——Boris Cherny
ファイルシステムとbashへのアクセスを与えた瞬間、Claudeが明示的なプログラミングなしに自律的に問題を解くようになった。
2ヶ月で社内を席巻
チームへ共有した2日後から同僚が実務で使い始め、2024年11月にdogfooding-ready versionをリリースすると、初日にエンジニアの20%が使用を開始し、5日後には50%が使用中になった。CEO Dario Amodeiが社内の利用急増グラフを見て「エンジニアに強制しているのか？」と聞くほど、自然に広まった。
開発者：Boris Chernyという人物
Boris ChernyはUC San Diegで経済学を専攻し、スタートアップでの独学でプログラミングを習得した。CS専攻ではなく、現場と独学でMetaのPrincipal Engineerになった人物だ。O'ReillyからTypeScriptの書籍も出版している。
STATION Fでのインタビュー（2026年3月）で彼はこう語っている。
"I have not written a single line of code since November [2024]."（2024年11月以降、コードを一行も書いていない）
Claude Codeを毎日使うことで、自分でコードを書く必要がなくなった。ツールの創設者自身が最もツールに依存しているという逆説が、その実力を物語っている。
なぜこの設計になったのか：「product overhang」という洞察
Cursor・Windsurfが台頭していた2024年末、Borisはある感覚を持っていた。「product overhang」——モデルはできるのに、製品がその能力を活かせていない状態だ。
「モデルはすでにはるかに多くのことができるのに、既存のツールはそれを活かしていない。モデルが実際に開発者の作業内容を見られる製品が必要だ」
当時のコーディングAIはモデルの能力を「scaffolding」で制限していた。Claude Codeは逆を行った——制限を取り除くことで、モデルが本来の能力を発揮できるようにした。
アーキテクチャ思想：「最小限のビジネスロジック」
Claude Codeが一貫して守っているのは、ビジネスロジックを最小化すること、UIやツールがモデルの能力を制限しないこと、常に最もシンプルな選択肢を選ぶことだ。
Borisはこう語っている。
"Every time there's a new model release, we delete a bunch of code. For example, with the 4.0 models, we deleted around half the system prompt because we no longer needed it."
モデルの能力が上がるたびに、人間が書いたコードやプロンプトが不要になる。これが「モデルを箱に閉じ込めない」設計思想の実践だ。
他のコーディングツールが採用しているDockerコンテナやクラウド環境での実行を、Claude Codeはあえて採用しなかった。理由はシンプルさだ。bashコマンドはローカルで実行、ファイルシステムも直接アクセス。余分な抽象化レイヤーを排除することで、モデルが「生」の環境と直接やり取りできる。
製品開発5つの原則
Borisが折に触れて語る、AI時代のツール開発の原則がある。
原則1：モデルを箱に閉じ込めない
過剰なオーケストレーションより、ゴールとツールを渡してモデルに任せる。
原則2：Bitter Lesson
Rich Suttonの「The Bitter Lesson」——より汎用的なモデルが特化モデルを常に上回る。Claude Codeがシンプルなシェル構造を維持し続ける理由でもある。
原則3：6ヶ月後のモデルを見据えて作る
現在のモデルに合わせてプロダクトを作ると、モデルの進化とともにすぐに陳腐化する。「今のClaudeには難しいから諦める」ではなく「半年後のClaudeならできる」を前提に設計する。
原則4：少人数・リソース不足気味に保つ
チームがリソース不足の状態にあることで、AIを活用せざるを得ない状況が生まれる。豊富なリソースは人手への依存を生む。
原則5：トークンを惜しまず使わせる
コストを気にしてトークンを節約させると、AIの能力を制限する。モデルが最大の能力を発揮できるよう、十分なコンテキストを与える。
設計思想を知った後、使い方がこう変わった
Borisの哲学を知った後、私のClaude Codeへの向き合い方は実際にいくつか変わった。
変化①：CLAUDE.mdを「削れるか」で見るようになる
「詳細設定を書き込もう」から「Borisなら2行でどう表現するか」に発想が変わる。念のためで詰め込んだ設定を削ると、かえってClaude Codeの出力が整合的になることに気づく。
変化②：「今できないから諦める」がなくなる
原則3「6ヶ月後のモデルを見据えて作る」を知ると、現在のモデルに合わせてプロンプトを細かくチューニングする無駄に気づく。「Claudeに任せたら何かやってくれるはず」という信頼ベースの使い方に切り替わる。
変化③：コードを削ることに抵抗がなくなる
新モデルリリースのたびにコードを削除するという実践を知ると、自分のCLAUDE.mdやSkillsも同じ視点で定期的に見直せるようになる。
「唯一の正解はない」という設計思想
Borisは繰り返しこう語っている。
"Remember: there is no one right way to use Claude Code — everyone's setup is different. You should experiment to see what works for you!"
これは単なる謙遜ではない。設計思想として意図的に「唯一の正解を押し付けない」ようにツールが作られている。Boris本人の個人CLAUDE.mdはたった2行だというが、Claude Code開発チーム内でも使い方が異なる。
「ターミナルは出発点のつもりだったのに、終着点になっている」——UIを作る手間を省くために選んだターミナルが、そのまま本番プロダクトになった。シンプルであることが、長く使われる理由になる。これがClaude Code設計の根底にある哲学だ。
まとめ：設計思想を知って使い方を変える
- CLAUDE.mdを最小限に: Boris本人が2行で運用していることを思い出す
- モデルに任せる: 過剰なオーケストレーションより、ゴールを渡してモデルに任せる
- 6ヶ月後を見据える: 「今できないこと」ではなく「もうすぐできること」を試す
- 新モデルが出たら削除する: CLAUDE.mdやSkillsで不要になったものを整理する
コメント