何回同じ注意をしても直らなかった。1本のHookを書いたら二度と繰り返さなくなった——これがClaude Codeを「使うツール」から「育てるチームメンバー」へ変える、Level設計の核心だ。フリーランスの業務を自律化するための5段階を整理する。
Level 1〜5とは何か
Claude Codeの習熟度を5段階で整理すると、こうなる。
| Level | 状態 | 人間の作業 |
|---|---|---|
| Lv.1 | Raw Prompting。指示を毎回手打ち | 全指示の手入力 |
| Lv.2 | CLAUDE.md追加。プロジェクトルールを永続化 | 指示＋ルール説明＋レビュー |
| Lv.3 | Skills追加。繰り返し手順をオンデマンドで注入 | 指示＋レビュー＋手動テスト |
| Lv.4 | Hooks追加。ライフサイクルに品質ゲートを組み込む | 指示＋動作確認 |
| Lv.5 | Agents（オーケストレーション）。複数エージェントが並行稼働 | 指示と確認のみ |
Level 1はプロンプトを毎回書き直す状態で、何も積み上がらない。Level 5は複数のエージェントが自律的に協調し、人間は意図を伝えるだけでよい状態だ。ただし最初からLevel 5を目指す必要はない。各段階に「移行サイン」があり、そのサインを見落とさなければ無理に急がなくていい。
Level 2：CLAUDE.mdで「文脈の永続化」を作る
「このプロジェクトはTypeScriptで書いて」「コメントは日本語で」——同じことを2回言い直したらCLAUDE.mdに書くタイミングだ。
CLAUDE.mdの正しい書き方
Anthropicは「短く・人間が読みやすく保つ」ことを推奨しており、コミュニティでは150行程度が実用的な目安とされている。LLMには冒頭の命令が優先され後半が無視されやすくなる傾向があるため、指示が長くなるほど後半の遵守率が落ちる。
「お願い」形式
- できるだけテストを書いてください
- APIキーはハードコードしないようにしてください
解釈の余地を与えてしまうため、状況によってスキップされる。
コマンドと構造で指示
- 新機能追加時は必ず
npm testを実行してから完了を報告すること - APIキーをコードに直接記述しない（環境変数
.envを使用） rm -rfの実行前には必ず確認を取ること
禁止リストに「なぜ禁止か」の説明は不要だ。AIは命令より理由を優先して解釈するリスクがある。「状況によっては例外もあるかもしれない」という解釈の余地を与えてはいけない。端的に「禁止」と書く。
Level 3：Skillsでトークンを節約する
「ブログ記事を書く時は、まずキーワード調査をして、構成案を出して、本文を書いて……」——そのフローを毎回伝えているなら、Skillに切り出す時期だ。
Skillsの仕組み
配置場所は .claude/skills/<スキル名>/SKILL.md。呼ばれた時だけ読み込まれ、使わない時のトークン消費はゼロだ。CLAUDE.mdに全手順を詰め込まなくていい。
Skillsの具体的な書き方
SkillファイルにはYAMLフロントマターで name・description を設定する。
create-blog.md：記事執筆の全フローfix-issue.md：バグ修正の手順と報告フォーマットrelease.md：リリース手順
指示は /create-blog の一言で済む。CLAUDE.mdをスリムに保てるのは、詳細手順をSkillsに切り出しているからだ。
Level 4：Hooksで「お願い」から「強制」へ
プロンプトでの注意が効かない理由は単純で、LLMは確率的に動くからだ。指示を「解釈」する余地がある以上、必ずブレが生まれる。「できるだけ」「原則として」という言葉は存在しないのと同じだ。
ある実践者の言葉
「プロンプトでの注意を何回繰り返しても直らなかった。Hookを1本書いたら二度と繰り返さなくなった」——これがHooksの本質だ。
主要なHookイベント
PreToolUse
ツール実行前に介入できる。exit 2 を返すと強制停止。rm -rf や DROP TABLE などの危険コマンドのブロックに使う。
PostToolUse
ファイル保存のたびにPrettierを自動実行したり、テストを走らせたりできる。保存→整形→テストが自動で回る状態になる。
Stop
セッション終了時に全テストと品質チェックを実行する。「完了報告したけどテストを通し忘れた」が物理的に不可能になる。
多層防御の設計思想
CLAUDE.mdでの指示とHookを組み合わせることで初めて確実な制御になる。「お願いではなくインフラで保証する」が基本思想だ。
Level 5：Agentsで「並行処理」を自動化する
単一エージェントの限界は「一度に一つしかできない」ことだ。コードレビューをしながらセキュリティチェックをしながらSEO最適化を確認する——これを直列でやれば3倍の時間がかかる。
並行レビューエージェントの実例
security-agent
依存関係の脆弱性・APIキー漏洩・SQLインジェクションリスクを確認
performance-agent
N+1クエリ・不要なレンダリング・バンドルサイズを確認
seo-agent
メタタグ・OGP・構造化データを確認。全員の確認が取れたらマージを提案
海外での実証データ
国内ではGMOペパボのエンジニアが「タスクファイル作成→コマンド実行→AI自律開発→自動検証→完成」まで全自動化するGo製ツール「Sleepship」を個人開発し、公開している。オーケストレーション設計はこうした実践事例から学べる部分が多い。
暴走させないための3つの制約設計
Level 5に近づくほど、制約設計が重要になる。自律度が高いほど、一度の失敗の影響が大きくなるからだ。
1. brain-project分離は初日に決める
設計判断を記録するbrainリポジトリと、実装コードを置くprojectリポジトリを分ける。AIは迷ったとき必ずbrainを参照してから動くよう設計する。後から整理しようとするとAIが文脈を混乱させる。
2. 権限は段階的に付与する
基本モードは default → acceptEdits → plan の3段階。日常開発は acceptEdits で十分。auto は有料プラン限定で追加され、bypassPermissions（全権限スキップ）はVMや隔離環境のみで使う。
3. WHY/FIX/REF形式のエラーメッセージ
Hookのブロックメッセージに「なぜ止まったか」「どう直せばいいか」「根拠はどこにあるか」の3点を伝えることで、AIが次のアクションを正しく判断できる。自律回復率が上がる。
よくある質問
A: 「同じ訂正を2回した」タイミングで更新するのが基本です。定期的なメンテナンスより、失敗から学んで追記する運用のほうが実態に即した内容になります。
A: 必ずしも必要ではありません。一人であってもレビュー・テスト・納品確認を並行処理したい場面ではAgentsが有効です。まずLevel 3〜4で十分な自動化を実現してから検討してください。
A: Skills（Level 3）が先です。繰り返し手順をSkillに切り出してCLAUDE.mdをスリムに保つことで、Hook（Level 4）の制御対象が明確になります。逆順だと制御が複雑になりやすいです。
A: 基本的な考え方（文脈の永続化・手順の切り出し・強制ゲートの設置）はCursorやGitHub Copilot Workspaceなど他のAIコーディングツールにも応用できます。ただしHooks相当の機能はツールによって実装方法が異なります。
まとめ：「使う」から「育てる」への転換
CLAUDE.mdでコンテキストを永続化し、Skillsで手順を切り出し、Hooksでお願いを強制に変え、Agentsで並行処理を実現する——この順番に意味がある。焦ってLevel 5を目指す必要はない。「同じことを2回説明した」「Hookがあれば防げた」——そのサインが見えた時に、一段ずつ上がればいい。
AIスキルを活かせる案件はPRO WORKSで
Claude CodeなどのAIツールを実務で使いこなせるフリーランスへの需要は急速に高まっています。PRO WORKSではAI活用スキルを求める案件も豊富です。
PRO WORKSで案件を探す