ハクソク

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

クロードコードの優れた理由とは何か

275日前原文(minusx.ai)

概要

  • Claude Code は、シンプルかつ直感的なAIエージェント体験を提供
  • 複雑な仕組みを避け、単一ループと明快なツール設計 を重視
  • claude.mdなどのコンテキストファイル でユーザー設定や好みを反映
  • LLM検索中心の設計 でRAGに依存せず、モデル本来の力を最大活用
  • ツールやプロンプト設計の工夫 が、他のエージェントとの差別化要因

Claude Codeが「使っていて気持ちいい」理由

  • Claude Code は、ターゲット編集や使い捨てツールの操作が快適なエージェント体験を実現
  • 適度な自律性 を持ちつつ、ユーザーの制御感を損なわない設計
  • Claude 4モデル （特にinterleaved thinking）が主要な処理を担当
  • CursorやGitHub Copilot Agents と比較しても、使い勝手が圧倒的に優れている
  • MinusX の開発現場でも即採用されるほどの実用性

Claude Codeの設計思想と学び

  • LLMの得意・不得意を理解した設計 で、弱点をプロンプトやツールで補完
  • コントロールループは非常にシンプル で、デバッグも容易
  • 複雑なマルチエージェントやRAG検索は極力排除 し、保守性と拡張性を両立
  • 全てを1ファイルにまとめ、不要なボイラープレートを排除

Claude Codeの設計を自作エージェントに活かすポイント（TL;DR）

  • 設計はとにかくシンプルに保つことが最重要
  • メインループは1つ、分岐は最大1つ、メッセージ履歴も1つだけ
  • 小型モデル（例：claude-3-5-haiku）を多用 し、コスト最適化
  • ユーザーコンテキストはclaude.md等のファイルで厳密に管理
  • プロンプトはXMLタグ・Markdown・豊富な事例で構成
  • LLM検索を中心に据え、RAGベース検索は極力使わない
  • ツールは低・中・高レベルをバランス良く用意
  • エージェント自身がToDoリストを管理し、タスクの見失いを防止
  • トーンやスタイルなどの美学も明示的に設計

コントロールループ設計

  • メインループは1本化 し、デバッグ性を最優先
  • 階層的なタスクはサブエージェント（分岐最大1つ）で処理
  • メッセージ履歴はフラットなリストで管理
  • サブエージェントは自己増殖不可とし、制御性を担保
  • 複雑なマルチエージェント設計は不要

小型モデルの活用

  • 重要なLLM呼び出しの半数以上がclaude-3-5-haiku
  • 大容量ファイルの読取や要約も小型モデルで十分
  • コスト削減効果が大きく、常用推奨

プロンプト設計

claude.mdパターンによるユーザーコンテキスト管理

  • claude.md/cursor rules/agent.md などのコンテキストファイルでユーザー設定を厳密管理
  • コードベースから推測できない好みやルールも明文化
  • リクエストごとにclaude.mdの内容を毎回送信

XMLタグ・Markdown・事例の多用

  • <system-reminder> タグでLLMへのリマインドを明示
  • <good-example> / <bad-example> でベストプラクティスを具体的に提示
  • Markdown見出しでプロンプト内セクションを明確化
    • 例：トーン・スタイル、プロアクティブ性、コーディング規約、タスク管理、ツール利用方針

ツール設計

LLM検索中心主義（RAG排除）

  • RAGではなく、LLMによるコマンド検索（例：ripgrep, jq, find）を重視
  • LLMがコードを深く理解し、柔軟な正規表現やコマンド生成が可能
  • RAG導入による複雑化・隠れた失敗モードを回避
  • RL（強化学習）による最適化も視野に入る設計

ツールのレベル分けと選定

  • 低レベル：Bash, Read, Write
  • 中レベル：Edit, Grep, Glob
  • 高レベル：WebFetch, mcp__ide__getDiagnostics
  • 頻繁利用・高精度が求められるものは専用ツール化
  • ツール選択基準や利用例をプロンプトで明示

ToDoリスト管理

  • エージェント自身がToDoリストを頻繁に参照・更新
  • 長期タスクや文脈の劣化（コンテキストロット）を防止
  • 柔軟なタスク追加・修正が可能な設計

ステアラビリティ（制御性）

  • トーンやスタイル、プロアクティブ性をプロンプト内で明示
  • 「PLEASE THIS IS IMPORTANT」などの強調も未だ有効
  • アルゴリズムやヒューリスティック、事例を活用し、望ましい動作へ誘導

このように、 Claude Code は「シンプルな設計」「強力なコンテキスト管理」「LLM本来の力の最大活用」「ツール設計の工夫」によって、他のエージェントと一線を画しています。自作エージェントにもこれらの原則を取り入れることで、 使っていて楽しい・気持ちいいLLMエージェント体験 が実現可能です。

Hackerたちの意見

GoogleのGemini（Pro？）とClaudeをコードに関して比べると、みんなはどう思ってる？Googleの製品は結構好きなんだけど、いつも何かを閉じちゃうし、企業のコントロール（Chromeや不正行為）や検閲に関してはちょっと手荒いよね。

└

Geminiは理由もなくコードを書いてくれないことが多かったし、仮想的な解決策についてだけ話してた。ツールの問題っぽいけど。

└

Ampの人たちによると、ClaudeのSonnet/Opusはツールの使い方が得意なんだって。

└

ウェブUI（チャット）について？実はGemini 2.5 Proがすごく好きなんだ。コマンドラインツール（ClaudeコードとGeminiコード）については？全然比較にならないよ。Geminiのコードは役に立たなかったし、Claudeのコードはほとんど遅いだけだった。

└

考えるのは結構得意だけど、コーディングはイマイチだね。コードを書くと、よくぐるぐる回って入力を無視しちゃう。役に立つのは、大きなコードベースを読み込んで必要な情報を抽出する時かな。特定のことを相談するためにClaudeからGeminiを使ったりもしてる。Opusもそんな感じだけど、もうちょっとコーディングが得意かな。Sonnetは、私の経験ではコーディングが得意なんだけどね。

└

Gemini Proがコーディングで必ずしも劣っているとは思わないけど、私の経験ではClaudeは「ターミナル」タスク（つまり、ターミナルでCLIを通じてモデルを操作すること）でかなり優れてる。ほとんどのCLIはClaudeを使ってるし、詳しくはhttps://www.tbench.ai/leaderboardを見てみて。

└

Geminiは、複数の関数呼び出しを追跡する必要がある難しい問題をデバッグするのに役立つと思う。Claudeはもっと予測可能で、指示に従うのが得意だと思う。管理しているtodoリストは、この点でとても役立つみたい。

└

システムコマンドでモデルを制御できたら、すごくいいと思う。でも、結局うまくいかなかった。モデルが冗長すぎて、助けになりすぎるんだよね。

└

最近のテストで、全体像を分析するのが結構賢いなって思ったよ（つまり、「テストが失敗してるのはあれのせいじゃなくて、全体の前提が変わったからだ。だからこのテストを最初から書き直そう」って感じ）。でも、何回か「ファイルを編集できない、詰まった、全然違う方法でやってみる」っていう風に行き詰まったこともあった。今のところ一番の違いはコミュニケーションスタイルかな。ちょっと…皮肉っぽい？「ああ、テストが失敗してるね、やっぱり」みたいなコメントがあるんだ。なんで初めて見るプロジェクトの失敗するテストを予想できるんだろう？ :D

└

ジェミニは、自分のリポジトリ全体のマージファイルを入れて、いろいろ話し合うのにめっちゃ便利だよ。コードベース全体を理解するレベルがすごすぎて、素晴らしいアーキテクチャの計画支援もできる。クロードは全然そこまでできないね。俺の戦略は、ジェミニを使ってプロジェクトの濃い要約を作って、高レベルのアクションプランを立てること。その後、それをgpt5に持って行って、プランを改善してもらい、実行するための詳細なワークフローXMLドキュメントに変換してもらう。それをクロードに渡すんだ。これでクロードの計画外のもたつきをほぼ回避できる。

└

昔はすごく好きだったけど、最近はなんかバカになった気がする。俺の気のせいかな？他にもそう感じてる人いる？

基本モデルが現実のコーディングタスクには向いてるだけだと思う。一般的なベンチマークのコーディングタスクとは違ってね。GitHub Copilotを使うと、自分のシステムレベルのプロンプトがあって、モデルを切り替えられるんだけど、ClaudeはOpenAIやGoogleのモデルよりも圧倒的にパフォーマンスが良くて、他は実質的に役に立たないよ。

└

Anthropicは強化学習の際にモデルやプロンプトを最適化する機会があるから、記事のアドバイス「Claudeコードでうまくいくものに近づく」は有効だし、他のモデルに同じ技術を適用するよりもAnthropicモデルにもっと適用できると思う。サブスクリプションプランがあるから、Anthropicはユーザー体験を良くするだけじゃなくて、効率的にループを回すことにも強いインセンティブがあるんだよね。

└

Claude Codeの称賛を全部読んで、1ヶ月試してみたけど、すごくがっかりした。俺にはCursorのサイドバーと同じくらいの効果しかなくて、UXも悪い。もしかして俺が何か間違ってるのかな？コーディング中にバカなミスをたくさんするんだよね、2つの異なるコードベースで。

└

基本モデルだけじゃないよ。VS Codeでclineとopusを使ってみて。それからClaude Codeを使うと、違いが分かると思う。違いを定量化するのは難しいけど、CCの方がもっと作業が進むのは確か。

うわ、これはClaude Codeを使ってる時にちょっと辛いタイミングだな。Security OnionのElasticの問題をデバッグしてもらおうとしてるんだけど、数分後には意味不明なJSの山を吐き出して、「エラー: kill EPERM at process.kill (node:internal/process/per_thread:226:13)」って言ってる。多分、実行するスクリプトの一つがNode.jsのプロセスを殺しちゃって、それがClaudeも巻き込んでるんじゃないかな。もしくは、問題が解決できなくて自殺しちゃったのかも。とにかく、もうちょっと頑張って生き残って手伝ってほしいな（笑）。

└

別のLLMに飛ぶと、何が起こったのかがわかるよ。*これは公式なアドバイスじゃないけどね :)

└

どのLLMとエラスティックサーチを使っても、いい結果がゼロだった。出てくるものは全部ハルシネーションで、インターネット上には完全で文脈に合った例があまりないから。

└

現在のインストールをアップグレードするか、消して再インストールしてみるといいよ。どこかにキャッシュされたファイルが悪い状態になっているかもしれない。最近似たようなことがあったとき、これで解決したから。

└

sudoを使ってルート権限でプロセスを実行するときにこの問題が起きて、タイムアウトするんだよね。

└

クロードとローカルスタックのエッジな部分はあまり仲良くないね。Rustには結構いい感じで驚いたよ。LLMが「最も知られている」言語やプラットフォーム、アーキテクチャが、すぐに好まれるものになるんじゃないかな。LLMの使用による技術の均質化みたいな感じ。だって、例えばNode.jsで10倍成功するなら、エリクサーやGoを使う理由がないよね。特にテックショップじゃないなら、その選択肢でジュニアコーダーを中堅やシニアのように使えるし。

残念ながら、Claude Codeはオープンソースじゃないけど、どう動いているのかを理解するためのツールはいくつかあるよ。本当に興味があるなら、Claude Traceをチェックすることを強くおすすめするよ：https://github.com/badlogic/lemmy/tree/main/apps/claude-trac... これを使うと、セッションで使われたすべてのツールやプロンプトが表示される、JSONファイルときれいにフォーマットされたHTMLファイルが出力されるから。

└

https://github.com/anthropics/claude-code システムプロンプトも見れるよ。基本モデルがタスクを細かいステップに分けて、忍耐強くそれを進めるように訓練されてるんだ。失敗ケースにもある程度の耐性があるしね。

└

OSSの代替を探してるなら、OpenHands CLIをチェックしてみてね： https://github.com/All-Hands-AI/OpenHands?tab=readme-ov-file

「これは重要だ」っていうのは、まだ最先端なんだよ。似たような問題を抱えてたけど、「言うべきでないことを言わず、言うべきことに焦点を当てる」ってアドバイスを見てからは変わった。つまり、'thing'に手を伸ばすときには、文脈の中で代替案があることを確認するってこと。それ以来、そんな問題は起きてないよ。

└

つまり、こんなアドバイスが本当に効果的なら、なぜAnthropicはLLMにそれを言わせないんだろうね？

自分のスタートアップのMVPを全部Claude Codeで作っちゃって、今はお金を払ってくれるお客さんもいるんだ。ちょっと存在的な不安があって、SEVインシデントが起きてカードの家が崩れるんじゃないかって心配してるけど、それまではずっとClaudeを使ってセキュリティの脆弱性を直したり、テスト駆動開発を実践したり、長期的なプロダクトロードマップに沿ってソフトウェアアーキテクチャを計画したりしてる。こういう話がもっと一般的になればいいなと思ってる。

└

「テスト駆動開発を実践し、長期的なプロダクトロードマップに沿ったソフトウェアアーキテクチャを計画する」って、具体的にどうやってCCが助けてくれたのか教えてくれる？

└

こういう話がもっと一般的になればいいなと思ってる。なんで？？？？？？？ 開発者が自分の「仕事」を見失うほどに、そんなことを望むの？なんで君みたいな人がみんなを泥沼に沈めようとしてるの？クリーンコードの10分の1の行数で君の泥の山を置き換えられると思うし、実際それほど大変じゃないと思うよ。怠けてるから？

└

まあ、遠慮せずに、CCがどうやって助けてくれたか教えてよ。

└

当然だけど、Claude Codeに毎月お金を自分の銀行口座に振り込むように頼んだら、ちゃんとやってくれてるよ。

└

それまではずっとClaudeを使ってセキュリティの脆弱性を直したりしてる。最初にそれを作ったのは彼なのに？

これをシェアしてくれてありがとう。今、マルチエージェントシステムに向けて急いでいる時期に、LLMファーストの組織がどうアプローチしているかを見るのは助かるね。ここにあるデザイン面は、俺が日々試していることだから、他の人が使っているのを見るのもいいね。いくつかのポイントを挙げると、(1) 長いプロンプトはいいよ - プロンプトでツールが何か、ユーザーをどう助けるかを説明するのを忘れないでね。(2) ツールの呼び出しは基本的すぎる; もっとコンテキストが必要だよ（いつ使うか、使わないかなど）(3) メッセージをシステムのメモリの状態として使うのはOK; fancyな方法（データフレームを持続させたり、ステップ間で変数を解析したり）を考えたこともあるけど、コンテキストウィンドウが大きくなるにつれて、メッセージで大丈夫そうだね。

└

（ここでのブログ記事の著者）うん、基本からたくさんのパフォーマンスを引き出せるし、99%のユースケースに対して複雑な設定は必要ないよ。ループはシンプルに保って、ツールを明確にしておくこと（機能が重複しても大丈夫）。明確さとシンプルさ >>> その他すべて。

└

長いプロンプトは、モデルがそれに最適化されてる場合にだけ良いってことを言いたい。Claude Codeの基盤モデルを入れ替えてみたけど、ほとんどのローカルモデルは、長いコンテキストやツール使用に対応してるって言われてるのに、指示が長くなると全然ダメ。ツール使用に関しては、小さなChatBotタイプのデモではうまくいくけど、Claudeのコードレベルのプロンプトが長くなると、ツールの存在を忘れたり、使うのを忘れたり、間違ったフォーマットで返したりする。OpenAIのモデルやGoogleのGeminiはなんとか動くけど、Anthropicのモデルには及ばないし、動作も遅く感じる。

重要なポイントは、やっぱりシンプルに保つことだね。もしこれが本当なら、ちょっと膨れ上がったアプローチに見えるけど、正直、ここでの著者のようにクロードを完全に使いこなせるとは言えないな...「普通の」プロンプトからたくさんの成果が得られると思うんだ。必要なことを一つずつ聞く感じで。記事で話されているような複雑さが、どうやって一つずつのプロンプトに付加されるのか、まだイメージできてない。クロードが一つずつのシンプルなプロンプトと比べてどう機能するのかもよくわからない。プロンプトを生成して、付録セクション（「メインクロードコードシステムプロンプト」と「すべてのクロードコードツール」）をループで確認する方が効率的じゃない？それとも、LLMはなんか神秘的にそれをやってるのかな（ただうまくいく）？だから、「[新しい言語]でのwhileループの同等物を教えて」っていうのがプロンプトの全てで...必要なら付録セクションをループすることができるよね？それ以外だと、トークンの使いすぎになって、リクエストが複雑すぎて無視されるかもしれないよね。ここでの制御フローはちょっとわからないな。LLMがプロンプトに付録セクションを正しく使ってない印象がある（時々無視できるんじゃないの？）。プロンプトからそれを分けて、付録セクションをループで確認した方が、もっと正確なレスポンスが得られると思うんだけど、どうかな？プログラム全体をコーディングするのを、個々の部分をプロンプトするようにイメージしてるんだ。そうするのに複雑な.mdファイルは必要ないし、「[新しい言語]でのwhileループの同等物を教えて」って聞くだけでいい。俺のプロンプトは用途のためにもっとシンプルかもしれないけど、他の人がどうやって複雑なプログラムを作っているのか、まだ見たことがないな。みんなはどうやってプロンプトをつなげて、全体のプログラムを作っているんだろう？（これが一つの質問かな）もっとクリアなイメージを得るために、誰かがものを作るプロンプトごとの内訳を見つける必要があるかも。

└

あなたが見る方法や使い方は、俺と同じだね。他の返信も聞いてみたいな。

ElixirとPhoenixでClaude Codeを使ってる。ほとんどは素晴らしいけど、プロジェクトに少し入ると、関係ない何かを壊しちゃうみたい。

└

まだ試してないなら、usage_rulesミックスパッケージを試してみるべき。俺は主にAshを使ってるけど、usage rulesのサポートがすごく良くて、効果の違いは歴然としてる。TidewaveもMCPとしてすごくいいよ。エージェントがhexdocsやスキーマに直接クエリできるからね。 https://hexdocs.pm/usage_rules/readme.html