私がClaude Codeの全機能をどう使っているか徹底解説！
引用元：https://news.ycombinator.com/item?id=45786738
記事にはAGENTS.mdと同期してるってあるけど、Anthropicがおすすめしてるのは、CLAUDE.mdに「@AGENTS.md」って一行だけ書いて、実際のコンテンツは別のファイルに置く方法らしいよ。詳しい情報はこのURLを見てみてね！
https://docs.claude.com/en/docs/claude-code/claude-code-on-t…
これは彼らがちゃんと合わせるべき点の一つだね。慣例に従ってCLAUDE.mdをAGENTS.mdにリネームすべきだと思うよ。
公平に言うとさ、AnthropicやClaudeはAGENTS.mdが流行る前からCLAUDE.mdを使い始めたんじゃないかな。
そこまで先を読めなかったことを批判するなら、それでもかなり公平な意見だと言えるんじゃないかな。
僕は強く反対だな。エージェントごとに違うプロンプトファイルを読ませられないのはめちゃくちゃ迷惑だよ。Cursorは今、AGENTS.mdを自動でロードしちゃうんだけど、それを無効にする方法がなくて最悪なんだ。
うちはAGENTS.mdをCLAUDE.mdにシンボリックリンクしてるんだけど、それで問題なく動いてるみたいだよ。
それが正しいやり方だね。
うん、それがたぶんもっときれいなやり方だよね。
symlinkを使うとClaude Codeがよく混乱するんだよね。CLAUDE.mdがAGENTS.mdへのシンボリックリンクだって理解させるのに、何回もやり取りが必要になるんだ。
推奨アプローチはClaude Code固有の情報を分けられる利点があるけど、AnthropicはAGENTS.mdフォーマットを採用すべきだと思う。別ファイルだとCLAUDE.mdに記憶が書かれて、定期的に整理が必要になるのも面倒だよ。
Gitリポジトリでのsymlinkの挙動、特に違うOS間での動きがよく分かってないんだ。大丈夫なのかな？
Anthropicは「CLAUDE.mdに@AGENTS.mdを入れろ」って言ってるし、自分で試したら、手動でコピーしたみたいにシステムプロンプトに内容が全部入ったから、この方法で満足してるよ。Anthropicが直接AGENTS.mdをサポートするまではね。
Gitでは、他のチェックアウトでも同じsymlinkが作られるだけだよ（Linux/macOSの場合ね。Windowsはローカル設定の変更が必要だと思うけど）。
保証されたポータブルな唯一の方法は、同じリポジトリ内の別のファイルへの相対パスのsymlinkにすることだね。つまり、CLAUDE.mdはAGENTS.mdを指すようにするべきで、絶対パスはダメだよ。
Windowsだと、ローカルのGit設定次第なんだ。特にDockerコンテナを使ってWindowsで開発をすると、symlinkの挙動がまた違ってくるから、あまり良くないと思ってるよ。
僕はAGENTS.mdをCLAUDE.mdにsymlinkしてるけど、自分のリポジトリではうまく動いてるよ。でも、OSをまたいでの動作は保証できないな。
新しくクローンした時に、ファイルを変更したらもう一方が更新されるか確認してほしい。
Gitはデフォルトで、新しくクローンする時symlinkをただのファイルコピーとして扱うと思ってたんだ。つまり、Gitがsymlinkを認識してないのかも。
Gitはsymlinkをしっかりサポートしてるよ。ただ、システム設定によっては、Windowsで実際のsymlinkが作成されないこともあるけどね。
僕の経験だと、Claudeも他のエージェントも、セッションごとに明示的に指示しない限り、AGENTS.md（やCLAUDE.mdなど）を実際には読んでくれないよ。
Claude CodeのHTTPトラフィックを調べて確認したよ！CLAUDE.mdファイルの内容（そして@で参照されたAGENTS.mdも）は、追加のファイル読み込み操作なしで、システムプロンプトに自動的に含まれてるんだ。
うわー！これって正直がっかりだよ。Claudeが僕のAGENTS.mdの指示をしょっちゅう無視するの考えるとね。
@参照の要件、気づいてた？AGENTS.mdはデフォルトでは含まれないけど、CLAUDE.mdは含まれるべきだよ。
MCPに関するこの見解、めちゃくちゃ好きだな！https://blog.sshh.io/i/177742847/mcp-model-context-protocol
APIが肥大化するより、MCPはシンプルで安全なゲートウェイとして、強力な高レベルツールを提供すべきってさ。MCPの役割は、エージェントのために現実を抽象化するんじゃなく、認証、ネットワーキング、セキュリティの境界を管理して、あとは邪魔しないことだって。
ありがとう！MCPが出たばかりの頃は、この使い方を想像できなかったな。でも、Claudeはだんだん「ツール」じゃなくてデータに対するスクリプト処理を求めてるみたい。僕／MCPの仕事は、そのデータをClaudeに渡すことになったよ。
MCPじゃなくて軽いCLIsを使ってみた？CLIsの方がClaudeにとって簡単だって分かったんだ。特にClaudeと一緒にCLIsを作って、計画中にユーザーが困惑しないようにガイダンスを追加するように指示すると良いよ。僕らの認証、ログ解析、インフラ状態とか全部CLIで使えるし、Claudeにそれを指定するとかなりいい感じ。
うん、それが可能で、もし自分で作れるなら、それが正しい解決策だね。今、僕のほとんどの統合はMCPじゃなくて、そういう純粋なCLIsなんだ。CLIsを使えば何でもできるけど、MCPは共通インターフェースとして人々やプラットフォームが採用したいと思う標準としてまだ存在するよ。
MCPって、ほとんどのケースでまだスコープが足りないよね。例えば、企業のGoogle Drive全体に接続できるMCPなんて実用的じゃない。無理だよ。特定のホワイトリストに制限できないのはなんで？
＞ 特定のホワイトリストに制限できないのはなんで？
それはできるよ。でも、Rootsを実装したMCPクライアントとサーバーを使う必要があるんだ。
同感だよ。僕の唯一のMCPはコードインタプリタなんだ。最近、MCPの「プロキシ」を作って、コードインタプリタ内からエージェントがMCPを呼び出せるようにする実験も始めたよ [1]。でも、基本的にはまだMCPはあまり使ってないな。エージェントが自分で問題を解決するのがすごく得意だからね。MCPはツール部分よりも認証部分に重点を置いてほしいな。資格情報でAPIにアクセスできるようにするだけで、エージェントは自分で問題を解決するのに十分な力を得るよ。
[1]: https://x.com/mitsuhiko/status/1984756813850374578?s=46
MCPは、もしエンドユーザーが直接接続するクライアント向けサービスじゃなくて、重要な内部ツールAPIゲートウェイ（ステートレスHTTP）として使うなら、こんな感じで機能するよ。基本的にはOpenAPIなんだけど、LLM推論向けにもう少し調整されてるって感じだね。
正直、LLMツールはどれも結構良い感じだよね。でもさ、みんな出力スタイルとかUIにこだわりすぎじゃない？例えば、「絶対その通り！」みたいなゴマすり表現は別にバグじゃないんだよ。むしろ、君がAIに依存しすぎてるサインって感じ。俺の目標は「撃って忘れる」こと。つまり、仕事を任せて、文脈を設定したら、あとはAIにやらせるだけ。ツールの評価は最終的なPRの出来で判断するんだ。
でも、俺が毎日LLMツールを使ってて思うのは、ある程度の規模や複雑さのアプリケーションだと、このやり方は通用しないってこと。すぐに大量のコード、コメント、Markdownファイル、そして問題解決になるかわからない余計なテキストに圧倒されちゃうよ。そうなると、大量の怪しいコードのPRレビューが重荷になって、もしそれをマージしすぎたら、すぐにコードベースが肥大化して、どんなに巧みなプロンプトを使っても整理できなくなる。だから、アイデア出しや、すごくターゲットを絞ったプロンプトに使うのが一番。任せっぱなしはマジでクレイジーだよ。
完全に同意だね。上で言ってた戦略は、小さいホビー用のコードベースでしか通用しないよ。
Claude Codeの設定を改善するのに、Claude Code自体を使うのを忘れてない？plan modeに切り替えて、このプロンプトを試してみてよ：「https://blog.sshh.io/p/how-i-use-every-claude-code-feature のドキュメントを読んで、私のClaude Codeのセットアップをどう改善すればいいか教えて」
もっとコメントを表示（1）
「Claude Codeは単なるインタラクティブなCLIじゃない。全く新しいエージェントを構築するための強力なSDKなんだ——…」ってさ。エムダッシュと「XじゃなくてY」構文が同じ文にあるなんて、AIが書いた記事を読むのはもううんざり。読者に対して失礼だよ。
俺もAIが生成したものを読むと本能的に嫌悪感があったんだけど、最近はもっと穏やかな意見になってきて、内容そのもので判断しようとしてるんだ。例えば、この記事では全然気にならないよ。すごく役立つ参考資料だし、著者がちゃんと読んで、整理して、編集してるのが明らかだからね。これはAIの良い使い方だと思う。ただ、AIの出力をコピペしてブログ記事として出すだけのやつらは、かなり非難されるべきだね。
書くことって思考のためのツールだと思うんだ。思考をアウトソースしちゃうと、言いたかったことが薄まっちゃう気がする。もしそこまでがっつり編集されてたら、そんなAIっぽい兆候は残らないはずだよね。俺はコードにはAIを使うけど、人間が読む文章には絶対使わないよ。
ハルシネーションの心配はないの？
心配するよ、もちろん。でも、この記事は「著者がちゃんと読んで、整理して、編集してる」って部分が対策になってると思う。あと、人間が書いたものにも間違いはたくさんあるから、俺は何でも懐疑的に読むようにしてるんだ。
もし著者がドラフトを書いて、それを徹底的に読み直したら、AIが引き起こしたハルシネーションじゃなくて、人間が引き起こしたハルシネーションだけになるはずだよ。
インターネットは死んだ。インターネットよ永遠なれ。
「永遠の9月 2」が、今回はもっと「永遠」になってるって話だね。
今や「永遠の9月 3」って感じだね。iPhoneが登場した時に「永遠の9月 2」が来たんだ。
「AIが書いた記事を読むのはもううんざりだ」って意見に対して、「別に強制されてるわけじゃないでしょ？」って反論してるね。「読者に失礼だ」って意見には、「全然失礼なんて感じなかったよ。むしろ尊重されてる気分で全部読んじゃった」って返してる。
「強制された」なんてことは何も書かれてなかったよ。記事は全部読んだし。ただ、AIによって（一部？）書かれたとは明かされてなかったね。僕が引用したあの文章は、かなり後の方に出てきたんだ。
「AIによって書かれたとは明かされなかった」って言うけど、それがどうしたって言うの？AIが書いた文章が嫌いで、かなり読み進めてから腹が立ったんだとしたら、怒る相手は著者？それとも自分自身？もしこれAIなしで書かれてて、ただ君がAIライティングの検出が苦手だったって分かったら、もっとハッピーになるの？
「/clear と /catchup（シンプルな再起動）：僕のデフォルトの再起動方法。状態を /clear してから、Claudeにgitブランチの変更された全ファイルを読ませるカスタムの /catchup コマンドを実行してるんだ。」僕も似たような回避策をしてるよ。Anthropicはそのうち /compact コマンドがこの機能をするようにするんじゃないかな。
/compact の遅延がひどくて使えないって感じだよ。僕がコンテキストが0%になるまで待っちゃうせいかもしれないけどね。面白い豆知識なんだけど、実はコンテキストの大部分がコンパクト化のために予約されてるんだ。「残りコンテキスト0%」って表示されても、実際はコンパクト化用に約30%が残ってるんだよ。なのに、なぜか半分くらいの確率で、コンテキストがなくなったりAPI制限に引っかかったりしてコンパクト化が失敗するんだよね。
不思議なんだけど、そういう時ってClaudeを閉じて claude –continue を実行すると、compactするためのスペースができるんだ。意味不明だけどね。でもcompact後の状態がどうなるか分からないから、どのソースファイルを読めばいいかとか全部含めて、完全で徹底したレポートを書くようClaudeに頼む方が良いよ。手間はかかるけど、変な方向に行っちゃうよりはマシだね。
古い経験則だと、コンパクト化する時点で、もう手遅れってことらしいよ。
3000語が「長すぎて全部読むより参照として使う」って言われるのはちょっと悲しいけど、いくつか面白い点もあったよ。プレースホルダーじゃなくて具体的な例が入った、もっと長いバージョンも見てみたいね。
もしClaude CodeとかCodex CLIみたいなCLIベースのエージェントを使ってないなら、使うべきだって。CLIベースのエージェントってCursorアプリより良いの？どうして？CursorはCmd-Lでコードの一部を選択して“ここをこう直して”って簡単にできるから好きなんだけど。CLIエージェントは試したことないけど、コードをCLIで送るのって面倒くさそう。“login.tsの148-160行目を直して、ここがこう壊れてるよ___”ってね。
うん、最初はCursorから始めて、ハイブリッドになって、先月くらいから完全に移行したよ。きびきびしたミニマルなUXもそうだけど、純粋に効果がずっと良いみたい。ClaudeはCCで最高の仕事をするし、Codexも同じだと思うよ。
Cursor Composerは、こういう連携機能を持ってて、他のモデルよりも平均的にIDEリソースを上手く使ってるみたいだよ。
どうやらCursor 2.0のこと、まだ知らないみたいだね。
https://cursor.com/blog/2-0
より良いかって？それは難しいね。違うか？うん。評価する価値はあるか？絶対に。30分使ってみれば、ここに返信するよりも良い答えが見つかるはずだよ。すぐに自分で答えが出ると思う。15年くらい真剣にコーディングしてるけど、Claude Codeほど私のコーディング方法を変えたツールはないね。これには“AI”じゃないツールやサービスも含まれるよ。宣伝してるみたいに聞こえるかもしれないけど、私は関係者じゃないんだ。これが物作りへの情熱を再燃させてくれた大きな要因なんだ。
Claudeは、VSCodeで選択されたコードの行をちゃんと検出できるんだよ。
Gemini CLIやCodexもそうだよ。私はCLIをVSCで実行してて、VSCはファイルブラウザとしてだけ使ってるよ。
どれもオプションでIDE連携ができるんだ。例えば、ClaudeはアクティブなVSCodeタブやハイライトされた行を知ってるんだよ。
CursorからClaudeに乗り換えたら、24時間で戻れないって気づいたよ。CursorのVS Code UIは余計な機能が多すぎるしバグだらけ。出力も全然良くなかった。Claude CLIとVS Codeの組み合わせが最高すぎて、もう他のを試す気にならないな。Cursorはおもちゃみたいだったけど、Claude CLIは毎日価値を提供してくれる最高の製品だよ。
VS Codeにはもうエージェントが内蔵されてるけど、そのUIって使ってみた？
その部分はCursorとだいたい同じだね。それよりも、僕が最後に確認した時点ではCCの方がCursorより良いエージェントだよ。VS CodeでCCを動かすための公式Anthropic拡張もあるんだ。VS Codeのdiffビューを使えるのが一番の利点なんだけど、残念ながらこの拡張はターミナル版CCの最新機能をすべてサポートしてないから、結局ターミナルを使ってるよ。
うん、複数のファイルを選んでフォーカスできるよ。あと、PATHにあるものなら何でも実行できるんだ。例えば、ghとかを使うのもかなり得意だね。
Cursorで同じモデルを使うよりも、CodexやGPT5、Claude Code CLIを直接使う方が良い結果が出るよ。両方比較したんだ。Cursorは独自のaugmentationを適用してて、出力サイズを減らしてるみたい。たぶんトークンを節約するためだろうね。
もっとコメントを表示（2）
ClaudeはCursorよりコーディングが上手いんだよね。正直、インターフェースはあんまり重要じゃないよ。僕はcmd-Lも好きだけど、Claudeの方がただコードを書くのが得意なんだ…。あと、AnthropicがSkillsみたいなクールなものを作るのに集中してるのは良いんだけど、Cursorの連中がCursor 2.0で何をやってるのかはよく分からないな 🤷
CursorでもClaude SonnetやClaude OpusのLLMを使えるから、出力に関してはかなり似たものになると予想するよ。エージェントの部分は、両方とも常に改善され続けてるんだ。
Claude Code CLIには、使ってるモデルだけじゃなくて、プロンプト、ツール、ヒューリスティクスの中に何か特別なものがあるんだ。ANTROPHIC_URLを別のモデルに向けてみたらそれが明らかになったよ。結果はほぼ同じだったからね。Kilo CodeやCoPilot、JetBrain’s agentなんかもSonnet 4に直接当ててみたけど、それと比べるとClaudeの出力は全然良くなかったな。Claudeには不満もあるけど、それでもすごく感動してるよ。
Claude Codeは、Anthropicモデルを使ってるCursorと比べてもはるかに効率的だよ。プランニングとツール利用の能力が段違いに優れてるんだ。
VS CodeでClaudeとCodex使ってんだけど、マジでめっちゃ使えるよ。テキスト選んでCmd-Lで「ここ壊れてるから直して」って言うだけでちゃんと動くんだ。このやり方、最高！
マジかよ、プログラミングってこの2年で激変したよな。今はツール相手に心理戦仕掛けて、なんとか動かそうとしてる感じ。そのうちLLMが「メンタルブレイク中だから会社休む」とか言って、俺らも病欠する日も来そうだわ。
プロンプトの一部を大文字にすると、もっと良い結果が出るって聞いて、もう無理ってなったわ。こんなのにいちいち付き合ってらんないよ。
こういうツールは面白いけどさ、業界全体でまた「顧客」以外のことに夢中になってない？Paul Grahamの「Top idea in your mind」ってエッセイみたいにさ。
そうそう、LLMコーディングツールは開発スピードとコストばっか見てるけど、顧客が求めてるのは機能とバグのなさだろ？安く早く作っても、顧客のニーズに合わないバグだらけの商品じゃ誰も得しない。AI全般も同じで、CEOは人減らしにAIを使いたがるけど、顧客を満足させるレベルにはまだ遠い。AIチャットボットとか、顧客をイラつかせるだけだよ。
「顧客」って具体的に何のこと？だって俺はこれらのツールを、顧客をもっとよく理解するために使ってるんだけど。
結論から言うと、スキルって適切な抽象化で、MCPみたいなAPIモデルより堅牢で柔軟なスクリプトベースのエージェントモデルのことだね。MCPもAPIだけど、そのAPIがスキルを実行できるんだ。つまり、MCPとスキルは対立じゃなくて、「柔軟なスキル」と「パラメータベースのAPI」っていう広い概念だよ。パラメータAPIも書き方次第で柔軟になるけど、LLMをガイドするSKILL.mdがないのがスキルとの違いだね。あと、Macユーザーなら俺が作ったOpenSkillsでスキルをローカル実行できるよ。https://github.com/BandarLabs/open-skills
Claude Codeの進化、マジで半端ないよな！毎週新しいことを覚えなきゃいけないくらい、どんどん良くなってるんだぜ。
CPUとmemoryの使用量見たら、別に大したことないだろ。M4 Macの64GB RAMでも動きが遅くならないで機能が増えたら、それはもう魔法レベルだよ。
俺のM1 MacBook Proは、iTerm2でClaude Codeのセッションを10個以上開いても全然問題なく動いてるよ。ひょっとしてメモリリークしてるターミナル使ってんの？
iTerm2を使ってるんだけど、メモリリークとかCPUの問題がGitHubのissueでめちゃくちゃ報告されてるよ。
俺も16GB RAMのホームサーバー（150ドルくらい）でClaude Codeを問題なく動かしてるよ。
10個も並行してエージェントをどうやって管理してるの？？
俺はWindows Terminalを使ってるよ。タブの名前を変えてるんだ。
今のプロジェクトだと、トップレベルのチャットが1つ、4つのコンポーネントのサブディレクトリにそれぞれ1つずつチャットがあるよ。
さらにQA機能用のターミナルも別で開いてるから合計10タブだね。
docker psみたいな簡単なコマンドをサッと実行する用にもう1つ使ってるよ。
モデルはqwenを使ってる。
CCがめちゃくちゃ速くなったとはいえ、それを管理するのはかなりの認知負荷だよね。
アウトプットはちゃんとレビューしてるの？
アウトプットはユーザーがレビューしてるよ。
ごめん、10個全部を同時にアクティブには使ってないよ。
メモリには置いておいて、作業を再開する時のために開いたままにしてるんだ。
同時にアクティブで使うのは2、3個だけだよ。
え、Claude Codeってほとんどシステムリソース使わないんだけど。
本当にClaude Codeなの？Tahoe向けにアップデートされてないElectronアプリとかじゃない？
Claudeはローカルマシンでほとんど何も動かさないよ。
MacBook Airとか、しょぼい2vCPU 4GBのVPSでも全然問題なく動いてる。
CCはシステムリソースをほとんど使わないよ。
