.claude/ 配下には、CLAUDE.md、CLAUDE.local.md、Skills、subagents、rules などの役割分担された設定があるCLAUDE.md は長く書くより、ミスを防ぐための短いルール集にするのがコツCLAUDE.local.md は、自分専用の改善メモとして使うと日々の作業がかなり楽になる/goal など、あまり使われていない機能にもかなり実用的なものがある元記事は、Claude Codeを“ちょっと便利なAI補助”で終わらせず、毎日使う前提の開発ツールとしてどう育てるかをかなり深く掘り下げた記事です。
タイトルどおり、焦点は「プロンプトの先」にあります。
個人的に面白いのは、この記事がClaude Codeを会話相手というより、仕事を任せるエンジニアとして扱っている点です。ここが肝だと思います。
AIに逐一付き合うのではなく、良い制約・良いルール・良い確認手順を与えて、自走させる。そうすると、使い心地が別物になる、という話です。
記事の出発点はかなり明快です。
Claude Codeを、ただのチャット補助ではなく、自律的に動くエージェントとして扱え、ということです。
そのために重要なのが、Claude自身が結果を検証できるようにすること。
これはつまり、「書いて終わり」ではなく、タイプチェック、テスト、lint などで自分の作業を確かめさせるということです。
著者は、Claudeに自己検証のループを持たせるだけで、品質が2〜3倍よくなるとBoris Chernyが言っている、と紹介しています。
数字はあくまで元記事での引用ですが、感覚としてはすごくわかります。AIは“それっぽい答え”を出すのは得意でも、間違いを自分で踏み直す仕組みがないと平気で雑になります。ここは人間側が設計してあげる必要がある、というわけです。
記事では、日々の使い方として次のような流れが勧められています。
これは地味ですが、かなり重要です。
特に複数ファイルにまたがる変更では、いきなり実装に入るより、先に全体像を掴ませた方が事故が少ない、というのはかなり納得感があります。
Shift+Tab を2回押すと、読み取り専用の探索モードに入るこれはAIに「まず調べて」と言う感覚に近いです。
勢いでコードを書かせるより、設計文書を作るつもりで計画を出させるほうが、結果的に早いことが多いと思います。
@src/auth/login.pycat error.log | claudeこのあたりは実務っぽくて好きです。AIは人間以上に、具体的な文脈に強く反応します。雑な説明より、正確な入力のほうが圧倒的に効く、ということですね。
これもかなり本質的です。
AIに「ここどう思う？」と小刻みに聞くより、最初にちゃんとブリーフを渡して、まとめて動かすほうがいい、という話です。
ここはかなり賢い発想だと思います。
ミスは忘れると同じ形で再発しますが、ルールに変えれば再発率を下げられる。しかもClaudeは、自分の失敗をルールに要約するのがかなり得意だとされています。
これはまさに“AIに学習させる”というより、AIを使いながら育てる発想です。
.claude/ ディレクトリは「設定の箱」ではなく、レイヤー構造元記事で特に良かったのが、.claude/ を単なる設定置き場ではなく、役割ごとに分かれたシステムとして説明している点です。
ざっくり言うと、次の2つのスコープがあります。
.claude/ に置く設定。チーム共有向け。Gitに入るものもある。~/.claude/ に置く設定。自分の全プロジェクトに効く。この記事の言い方を借りるなら、
project files は「このプロジェクトのルール」、
global files は「自分の仕事の癖」
を表します。
この切り分けはかなり大事です。
何でも CLAUDE.md に詰め込むと、だんだん読まれなくなります。人間の運用でも同じですが、長すぎるルールはルールとして機能しにくいんですよね。
元記事では、以下のような構成が紹介されています。
CLAUDE.md
CLAUDE.local.md
settings.json
settings.local.json
.mcp.json
skills/<name>/SKILL.md
commands/*.md
agents/*.md
rules/*.md
要するに、全部を一箇所に書かないで、用途ごとに分けろということです。
これは地味ですが、運用が長くなるほど効いてきます。設定ファイルは“見やすさ”ではなく、更新しやすさが命なので。
CLAUDE.md は「短く、厳しく、失敗から育てる」元記事では、CLAUDE.md の書き方について、Claude CodeチームのBoris Chernyの流儀がかなり強調されています。
ポイントは2つです。
長い CLAUDE.md は重要なルールを埋もれさせます。
1行ずつ見て、「これを消したらClaudeがミスするか？」を自問する。ミスしないなら消す。
この姿勢はかなり気持ちいいです。ルールは多いほどよさそうに見えますが、実際には少数精鋭のほうが守られやすいことが多いです。
Claudeがミスをしたら、その場で
Update CLAUDE.md so you do not repeat this.
と伝える。
すると、Claudeがその失敗を一般化して、次回以降のためのルールにしてくれる。
これ、かなり実戦的です。
人間が毎回「このエラーは要するにこういうことだった」とメモするのは面倒ですが、AIにその整理までやらせる。これはうまい。
元記事では、Anthropic内部の実際の CLAUDE.md も紹介されています。中身は驚くほど短いです。
例えば、
bun を必ず使うなど、Claudeが推測しやすい場所を明示的に潰す内容だけが書かれています。
スタイルの好みや雑談的な説明はありません。かなりストイックです。
個人的には、これが一番参考になると思いました。
「AIに世界観を語る」のではなく、間違えやすいところだけを短く固定する。これが本当に強いです。
記事では、PRレビューのコメントから CLAUDE.md を育てるやり方を “Compounding Engineering” と呼んでいます。
つまり、レビューで出た指摘をそのまま一回限りの修正で終わらせず、次回から自動で防ぐルールに変換するわけです。
これは人間の開発でもかなり理想的です。
同じ指摘を何度も食らうのは消耗戦なので、AIに対しても人間に対しても、学習が積み上がる仕組みを作るのが大事だと感じます。
CLAUDE.local.md は“自分専用の改善ノート”CLAUDE.local.md は、個人専用で、Gitに入れないファイルです。
著者は、PRレビューでよく来るコメントを見たら、その場でここに書き込む使い方をしています。
たとえば、
console.log ではなく project logger を使うこういう“自分が何度も忘れること”を、毎回 Claude に覚えさせる。
これ、かなり実用的です。人間は忘れるので、忘れる前提で仕組みに埋め込むのが正解なんですよね。
さらに大事なのは、プロジェクト固有のフィードバックと自分の癖の修正を分けておくこと。
混ぜると、あとで削りにくくなるからです。ここは小さいけど、長く使うなら効く工夫だと思います。
記事の中盤でかなり重要なのが Skills です。
Skills は、Claude Codeを汎用AIから、特定作業に強いAIへ変える仕組みです。
簡単にいうと、~/.claude/skills/<name>/SKILL.md または .claude/skills/<name>/SKILL.md に置く、再利用可能な知識パッケージです。
フォルダ名が slash command になります。
例えば summarize-changes という Skill を作ると、/summarize-changes で呼べるようになります。
元記事の例では、
git diff HEAD を見せるというかなり実用的な Skill が示されています。
記事では、Skills の利点として次が挙げられています。
これはすごく良い設計です。
全部を最初から読ませると重いですが、必要なときだけ展開するなら、軽さと専門性を両立できる。UIの設計みたいで好きです。
Supporting files を持てる
tool access を調整できる
モデル呼び出しを抑制できる
つまり、Skills は「賢いマクロ」みたいなものではなく、小さな専門家に近いです。
この発想はかなり筋がいいと思います。AIに全部を覚えさせるのではなく、仕事単位で知識を切り出すわけです。
新しい仕事は commands ではなく、skills に寄せるべきとされています。
理由は、単純な呼び出しだけでなく、サポートファイルや制御を含めた“まとまり”として扱えるからです。
実務では、例えば以下のようなSkillが役立ちそうです。
こういうのは、毎回人間が言うよりSkill化したほうが絶対に楽です。
地味ですが、こういう仕組み化が一番効くんですよね。
記事では subagents も紹介されています。
これは、ひとつのClaudeに全部やらせるのではなく、役割ごとに分けたエージェントを作る考え方です。
たとえば /pr-review のような subagent を作って、
といった用途に特化させる。
これも発想としてはかなり自然です。
人間のチームでも、設計レビューが得意な人、テストを見るのが得意な人、リファクタリングを見るのが得意な人がいます。AIも同じで、役割を固定した方がブレにくいのだと思います。
元記事では、人気のある subagents や、真似すべき例も紹介されています。
実際、何でも1つの大きな指示にまとめるより、専門特化した小さな人格に分けたほうが、結果が安定しやすいのではないかと思います。
記事は Claude Code 本体だけでなく、周辺機能にも触れています。
Claude Code の機能を拡張する仕組みとして、plugins と marketplace がある。
ここは、必要な人にはかなり便利そうです。
ただ、元記事の主眼はここよりも、日々のワークフローをどう固めるかにあります。
記事では、あまり注目されないコマンドとして /goal が取り上げられています。
これは “Ralph Loop” を内蔵したようなものだと説明されていますが、要するに、目標を保ちながら反復するための仕組みです。
こういうコマンドは、知っているだけで使い勝手が変わるタイプです。
AI作業はすぐ横道に逸れるので、目標を固定する補助輪はけっこう大事だと思います。
MCP は、Claude Codeを外部ツールやデータソースに接続する仕組みです。
要するに、Claude単体で閉じるのではなく、Notion、Obsidian、GitHub、ローカルの各種情報源とつなげるための橋です。
記事では、Obsidian を使った実際のワークフローも紹介されています。
ここは、AIを“文章を作るだけのもの”から、“自分の知識ベースを操作するもの”に変える発想として面白いです。
個人的には、MCP はClaude Codeの価値をかなり押し上げる要素だと思います。
AIが強いのは生成だけでなく、既存情報を読んで、次の行動につなげるところなので、外部接続はかなり本質的です。
この記事の後半には、Anthropicチームが実際にどうやって使っているか、という視点があります。
これが単なる理論で終わっていないのが良いです。
読み取れるのは、次のような方針です。
CLAUDE.local.md に逃がす要するに、Claude Codeを“万能のAI”として扱うのではなく、再現性のある開発システムとして扱っているんですね。
これはかなり大事な視点だと思います。
AIは賢いですが、賢さだけでは運用は安定しません。運用の型が必要です。
率直にいうと、この記事は「Claude Codeの機能紹介」というより、AI時代の開発の作法を説明している記事でした。
ここがすごく良いです。
特に刺さったのは、次の3点です。
AIに説明しすぎない
AIに学ばせる
CLAUDE.md に反映するAIを役割分担させる
この3つが揃うと、Claude Codeはかなり“育てがいのある道具”になるはずです。
逆に、ただ会話しているだけだと、どこまで行っても「ちょっと便利な補助」に留まる。そこが分かれ目なのだと思います。
Claude Codeを使いこなすコツは、プロンプトをうまく書くことよりも、Claudeが自分でうまく働ける環境を作ることにあります。
CLAUDE.md で最低限のルールを固定するCLAUDE.local.md で自分の癖やレビュー指摘を吸収するこの思想は、かなり実用的で、しかも気持ちいいです。
AIを“その場しのぎの魔法”ではなく、積み上がる開発基盤として扱う。
元記事は、そのためのかなり良い手引きになっています。