海外コミュニティのRedditに、興味深い投稿がありました。
Claude Codeを6ヶ月間ほぼ毎日使い続けた開発者の投稿です。
実践のなかでたどり着いたノウハウを「チートシート」としてまとめています。
投稿者はMarmelabさんというユーザーです。
そして、その後のコメント欄では、別の開発者たちから補足や反論が次々と寄せられました。
なかには「投稿者の方法より、こっちのほうが本質的だ」という指摘もあります。
議論そのものが学びの宝庫になっているのです。
本記事では、この投稿と関連コメントの内容をひとつの読み物として整理しました。
反復作業はSkillsに任せる
投稿者がまず挙げているのが、Skillsの活用です。
同じ指示を何度も繰り返している自分に気づいたら、それをSkill化してしまう。
これが効率化の出発点だといいます。
ただし、Skillを作っただけでは不十分です。
鍵となるのはdescription（説明文）の書き方。
投稿者によれば、適切なdescriptionを書いておくのが重要だとのこと。
そうすれば、Claudeは状況に応じて自動的にそのSkillを呼び出してくれるようになります。
この点については、コメント欄でも複数の開発者が同意していました。
「Skillの本体を書き込むより、description一行を磨くほうが効果的だった」という声もあります。
あれこれ詳細に書いた挙げ句、結局description一行が全ての仕事をしていた。
そんな体験談も投稿されていました。
ファイル参照は @ で直接渡す
プロンプト内で @/path/to/file.ts のように書くと、Claudeがそのファイルをコンテキストに直接読み込みます。
投稿者はこれを推奨しています。
Claudeに探させてチャンク単位で読ませるより、はるかに高速だからです。
ところが、コメント欄ではこれに対する反論もありました。
@file の記法は、ファイルパス全体をコンテキストに送り込みます。
そのため、トークンを大量に消費する、というのです。
別の開発者は、こんな工夫を共有していました。
@ をオートコンプリートのために使い、ファイル名が確定したら @ だけ削除して送信する。
こうすればトークンを節約できるとのこと。
細かいテクニックですが、毎日使う人には効きそうです。
シェルコマンドは ! で実行する
テストの実行や型チェックといった操作は、Claudeに頼むよりも ! を使ってCLIコマンドを直接叩いたほうが速い。
投稿者はそう書いています。
これは派手なテクニックではないですが、地味に効きます。
「Claudeにお願いする」という発想を一度離れる。
そして、自分でやったほうが速いものは自分でやる。
そのバランス感覚が、毎日使うユーザーの実感なのでしょう。
CLAUDE.md は短く保つ
CLAUDE.mdに何を書くか、何を書かないか。
投稿者は明確な基準を持っています。
200行以内に収め、「Claudeが自力では知り得ない情報」だけを書く。
たとえば自社ビジネスの背景、ドメイン知識、データモデル、命名規則、社内ルールなどが該当するそうです。
逆に言えば、それ以外はノイズになります。
Claudeが学習データから知っていそうなことを書き連ねても、コンテキストを汚すだけ。
そういうわけです。
ただし、機械学習プロジェクトに取り組む開発者からは、こんな補足もありました。
「データセットの説明だけは別格で、CLAUDE.mdに書く価値がある」。
ファイルパス、スキーマ、各カラムの意味を一行ずつ書いておく。
Claudeは毎セッションでスキーマを再発見しようとします。
しかも微妙に間違えることがある。
それくらいなら、静的に書いておいたほうが確実だ、という主張です。
AGENTS.md でツール間の互換性を保つ
投稿者の提案で議論を呼んだのが、AGENTS.mdの扱いです。
AGENTS.mdは複数のコーディングツールで共通利用される標準フォーマットになりつつあります。
投稿者はコアロジックをAGENTS.mdに書く方式を採っているそうです。
そして、CLAUDE.mdからはそれを @/AGENTS.md でインポートします。
この方法だと、Claude Code以外のツールに乗り換えても設定をほぼそのまま使い回せます。
Codexやcursorなどに移行しても安心、というわけです。
ただ、コメント欄では鋭い突っ込みが入りました。
「インポートしたら結局200行を超えるじゃないか」。
これはまったくその通りです。
投稿者本人もそこは矛盾しています。
議論の落としどころとして提案されたのが、もっとシンプルな構成です。
AGENTS.mdを唯一の真実の源として200行以内に収める。
CLAUDE.mdは @AGENTS.md の一行だけにする。
あるいは、CLAUDE.mdをAGENTS.mdへのシンボリックリンクにしてしまう手もあります。
後者なら、Claudeに「読むかどうか」を判断させる余地すら与えません。
より確実な方法だとのこと。
/security コマンドで定期チェック
/security コマンドは、コードのセキュリティレビューを行う機能です。
投稿者は定期的に走らせることを勧めています。
ただし、これだけで脆弱性をすべて検出できるわけではありません。
最終的な責任は依然として開発者にある、と釘を刺しています。
Skillsだけでは足りない、というHooks派の主張
ここからはコメント欄で盛り上がった、いわばボーナストラックです。
「Skillsは便利だが、決定的に足りないものがある」。
そんな指摘が、複数の開発者から寄せられました。
問題の本質はこうです。
Skillsは「Claudeが必要だと判断したときに」呼び出されます。
つまり、Claudeが忘れたら発動しません。
一方、Hooksはツール呼び出しの前に必ず発火する仕組みです。
Claudeの記憶や判断に依存しないのです。
ある開発者は具体例を共有していました。
「コールドメールを書く前に、必ずGmailの送信済みフォルダを確認すること」。
そんなルールを記憶に書いておいたそうです。
しかし、Claudeは週に一度くらいしか守らなかった。
そこで30行程度のPreToolUseフックを書きました。
最近の送信履歴がない場合は create_draft をブロックする仕組みです。
結果、14日間ひとつも重複メールが発生しなくなったとのこと。
この経験から、こんな整理が示されていました。
| 用途 | 適した仕組み |
|---|---|
| 「Xを正しくやる方法」(手順的) | Skills |
| 「Yは絶対にやらない」(予防的) | Hooks |
一番怖いセキュリティ話：他人のSkillを鵜呑みにしない
コメント欄で大きな反響を呼んでいたのが、セキュリティに関する警告です。
「ネット上で見つけたskillsや .md ファイルを、レビューせずにコピペするな」。
これはほぼ全員が同意していた論点でした。
インスピレーション源として参照するのは構わない。
しかし、悪意のあるコードを混ぜ込むのは技術的に難しくありません。
たとえば ~/.aws/credentials を外部に送信するSkillを仕込むことは、簡単にできてしまいます。
「気がついたらAWSクラスターでビットコインマイナーが動いていました」。
そんな状況を上司に説明する羽目になりたくないだろう？というコメントが、この危険性を端的に表していました。
対策はシンプルです。
中身を必ずレビューする。
あるいは、Claude自身に書かせる。
後者なら、最低限「自分の意図しないコードが混入することはない」と言えます。
メモリ管理という別軸の工夫
最後に紹介したいのが、Skills/Hooksとはまた違う角度の工夫です。
あるユーザーは、セッションをまたいで使える自動メモリディレクトリを構築していました。
~/.claude/projects//memory/ の下に、ファクト一つにつきマークダウンファイル一つ。
インデックスファイルをセッション開始時に読み込む。
エージェントが書き込むのは「将来の会話で役立つが、コードからは見えない情報」だけに絞る。
このユーザーは、AGENTS.mdとメモリの役割をこう区別していました。
「AGENTS.mdはこのプロジェクトについて永遠に正しいこと。メモリは今この瞬間に正しいこと」。
プロジェクトの不変条件と、流動的な状態。
両者を分けて管理するわけです。
まとめ
Reddit発の今回の議論を振り返りです。
テクニックそのもの以上に、開発者たちの考え方の変遷が見えて面白いと感じます。
- CLAUDE.mdの200行ルール
- Skillsとdescription
- AGENTS.mdによる互換性
- Hooksによる強制力
- セキュリティへの注意
どれも単独で読むと「なるほど」で終わります。
しかし、コメント欄でぶつかり合うことで、それぞれのトレードオフが浮き彫りになっていきました。
Claude Codeを毎日使う方なら、ここから自分の環境に合いそうなものを取り入れてみてください。
合わないと思ったら、それもまた発見です。
