TL;DR

Claude Codeを3ヶ月ほぼ毎日使い込む中で、コードを書かせる時よりも「事故らせない・ブレさせない」ための運用ルールの方が効いた、という話です。
CLAUDE.mdの階層化、間違いのルール化(メモリ活用)、モデルの使い分け、Skill化、危険操作へのガード、ファイル読み込みの節約、レビューの分離。7つのルールを実例つきで紹介します。
インフラエンジニアとして普段やっている「運用設計」の考え方が、そのままClaude Codeにも効きます。

1. 前提: 筆者の使い方

普段はインフラエンジニアとして、サーバやクラウドの設計・構築に携わっています。Claude Codeは3ヶ月ほど、ほぼ毎日使っています。

用途はコード開発だけではありません。むしろ多いのは、ドキュメント作成、個人プロジェクトのデータ管理、定型業務の自動化です。「AIコーディングツール」という枠で見られがちですが、実際にはファイルを読み書きしてタスクをこなす汎用アシスタントとして使っています。

そういう使い方をしていると、コードの品質よりも先に気になってくるのが「毎回同じ間違いをしないか」「大事なファイルを勝手に壊さないか」という運用面です。この記事では、3ヶ月使い込む中で固まってきた運用ルールを7つに整理して紹介します。

2. CLAUDE.mdを最初に書く(階層化する)

Claude Codeは、プロジェクトルートに CLAUDE.md というファイルを置いておくと、セッションの最初に自動で読み込んでくれます。ここに書いた内容が、そのプロジェクトでの振る舞いの前提になります。

最初にやるべきことは、このファイルを書くことです。それも、1枚に全部詰め込むのではなく、階層化するのがポイントです。

project/
├── CLAUDE.md          # ルート: 全体方針・出力ルール・呼称など
├── docs/
│   └── CLAUDE.md      # docs配下固有のルール
└── data/
    └── CLAUDE.md       # data配下固有のルール

ルートには、プロジェクト全体に関わること(自分がどんな役割で何を目的にしているか、応答は敬語かどうか、ファイルの出力先)を書きます。サブフォルダには、そのフォルダに固有のルール(命名規則、参照すべき関連ファイル)を書きます。なお、サブフォルダのCLAUDE.mdは起動時に全部読まれるわけではなく、そのフォルダ配下のファイルを扱う時に読み込まれます。だからこそ、フォルダ固有の話はサブ側に分離しておくとコンテキストの無駄がありません。

# CLAUDE.md (ルート例)

## 基本方針
- 会話は簡潔に。結論から書く
- ファイル生成時は `outputs/{プロジェクト名}/` 配下に置く

## 出力ルール
- 日本語ファイル名は避ける
- 完了時は変更点を1-2行で要約する

これを書いておくと、「毎回同じ説明をし直す」というコストが消えます。呼称や口調まで書いておくと、セッションを跨いでも同じトーンで応答してくれるので、地味に快適です。

3. 間違いを指摘したら「ルール化」させる(メモリ活用)

Claude Codeには、セッションを跨いで情報を持ち越せるメモリの仕組みがあります。これを「間違いの再発防止」に使うと効果が大きいです。

やり方はシンプルです。ミスを指摘したら、そのまま流さずに「次から気をつけて」ではなく「このルールをメモリに残して」と明示的に頼みます。

自分の場合、文書作成時の表記ゆれ(同じ言葉なのに毎回違う書き方をする)や、決まったフォーマットからのズレを何度か指摘していました。ある時点で「このパターンは毎回指摘しているので、ルールとして残してほしい」と伝えたところ、以降はその種のミスがほぼ出なくなりました。

保存先の使い分けも意識しておくと迷いません。

「何度も指摘している注意事項」→ メモリに残してもらう。「これを覚えて」「ルールとして残して」と頼むだけです(保存されるファイルの形式はバージョンによって変わり得るので、操作ベースで覚えるのがおすすめです)
「プロジェクトの恒久ルール」(出力先、命名規則、口調) → 自分でCLAUDE.mdに書く。こちらは自分の手で管理する領域です

一度で完璧なルールにはなりません。何度か指摘してメモリを更新していく前提で使うのが現実的です。ただ、「口頭で毎回言い直す」から「一度書けば以降適用される」に変わるだけで、体感の手間はかなり減ります。

4. モデルの使い分け

Claude Codeは、複数のモデルを切り替えて使えます。自分は、定型作業(決まった手順の実行、フォーマット変換)は軽量・高速なモデルに、重い判断や設計の検討は上位モデルに振り分けています。切り替えはセッション中に /model コマンド一発です。

/model sonnet   # 軽量・高速なモデルへ
/model opus     # 重い判断向けの上位モデルへ

起動時に claude --model sonnet のように指定することもできます。

ここで注意しているのが、上位モデルほど「考える時間」が長くなる特性です。難しい依頼を投げると、応答が数分単位で返ってこないことがあります。この現象自体は不具合ではなく、モデルがじっくり考えている状態なのですが、初見だと「固まったのでは」と不安になります。

対策は単純で、重い依頼を1ターンに詰め込みすぎないことです。「分析して、設計して、実装して、テストもして」と一気に頼むと長考が膨らみやすいので、承認のポイントで区切って依頼を出すようにしています。この現象と対策については、他の方が詳しく分析した記事(参考: Claude Codeの固まる問題を分析した記事)もあるので、気になる方はそちらもどうぞ。

5. 定型ルーチンはSkillにする

同じ手順を毎回同じ品質で実行させたい作業は、.claude/skills/ 配下にSkillとして手順書(SKILL.md)を置いておくと安定します。

Skillは、手順・チェックリスト・合格基準を明文化したファイルです。これがあると、口頭で毎回指示を出さなくても、決まった手順を確実になぞってくれます。コマンド名はディレクトリ名がそのまま使われ(下の例なら /weekly-report で呼び出せます)、description に書いた内容は「この作業はこのSkillでやるべき」とClaudeが自動判断する手がかりにもなります。

.claude/skills/
└── weekly-report/
    └── SKILL.md

---
name: weekly-report
description: 週次データの棚卸しと記録更新
---

## 手順
1. 対象データを確認する
2. 前回記録との差分を確認する
3. 記録ファイルを更新する
4. 更新後、件数が一致するか検証する

## 合格基準
- 更新前後で件数の不整合がないこと

自分は個人プロジェクトのデータ管理まわりで、こうしたSkillをまず4本作りました。最初から完璧には書けなかったので、実際に動かして手順の抜け漏れに気づいては直す、というのを5周ほど繰り返して固めています。ポイントは「上位モデルに自分の判断基準を言語化させて、それを軽量モデルで運用する」という分業です。判断基準を書く作業は重いですが、書いてしまえば実行自体は軽量モデルで十分こなせます。

6. 危険な操作にはガードをかける

ファイルの削除や大量の変更など、後戻りしにくい操作には、必ずガードをかけるようにしています。基本の順序は「バックアップ→編集→検証」です。

CLAUDE.mdやSkillの手順書に「破壊的な操作の前には必ずバックアップを取り、検証してから実行する」「勝手に実行せず、承認を待つ」と明記しておくと、この順序が徹底されやすくなります。実際に、データを整理していた際、削除の前にバックアップとの件数照合を行い、欠落が0件であることを確認してから削除を実行した、ということがありました。この一手間があるかどうかで、事故った時の被害が全然変わります。

ただし、CLAUDE.mdはあくまで行動指針で、強制力はありません。「これだけは絶対に実行させたくない」という操作は、設定ファイル側でブロックできます。

// .claude/settings.json (特定コマンドを拒否する例)
{
  "permissions": {
    "deny": ["Bash(rm -rf:*)"]
  }
}

指針はCLAUDE.md、強制は設定、という2層で考えるのがおすすめです。

7. 大きいファイルを全文読みさせない

意外に効くのが、ファイルの読み方のルールです。大きいファイルを毎回全文読み込ませると、時間がかかるうえ、コンテキスト(AIが一度に扱える情報量)を圧迫します。会話の後半で応答が鈍くなる原因にもなります。

「大きいファイルはまず grep や部分読みで絞り込んでから、必要な範囲だけ読む」というルールをCLAUDE.mdに書いておくと、動作が軽くなります。ログやCSVのような行数の多いファイルを扱う時ほど効果が出ます。

## ファイル参照ルール (CLAUDE.md記載例)
- 大きいファイル(目安: 数百行以上)は全文Readしない
- まず grep で該当行を特定し、必要な範囲だけ部分読みする
- ログ・CSVは head/tail で先頭・末尾を確認してから読む範囲を決める

8. レビューは別のAIにやらせる(2エージェント運用)

生成物のレビューを、生成したのと同じAIにやらせると、同じ盲点をそのまま見逃しがちです。これは人間のセルフレビューが甘くなるのと同じ構造だと思っています。

自分は、重要な生成物については、作成したモデルとは別のモデル、あるいは別のAIサービスにレビューを頼むようにしています。視点が変わることで、片方が気づかなかった抜け漏れが出てくることが実際にありました。

レビューを頼む時は、観点と重要度の枠を先に渡すと指摘が実用的になります。

このドラフトをレビューしてください。
観点: 事実誤り / 論理の飛躍 / 冗長な箇所
指摘は Critical / Important / Nice-to-have に分けてください。

この運用で人間がやるべきことは、生成でもレビューでもなく、最終的にどちらの指摘を採用するかを判定することだと考えています。2つのAIの意見が割れた時にこそ、人間の判断が必要になります。

9. まとめ

7つのルールを振り返ると、内容自体は目新しいものではありません。標準化する、手順書を書く、権限とガードを設計する、バックアップを取る、レビューを分離する。これはすべて、インフラの運用設計で普段からやっていることです。

Claude Codeは「使う」ものというより「運用する」ものだと捉えると、コード開発以外の用途でも安定して力を発揮してくれます。これから使い始める方は、コードを書かせる前に、まずCLAUDE.mdを1枚書いてみることをおすすめします。

参考

Claude Code 公式ドキュメント (概要)
指示とメモリを保存する (CLAUDE.md)
Claude Code の設定 (settings.json)
スキル (Skills)
Claude Codeが固まる問題の分析記事 (Zenn) … 4章で触れた長考問題の詳細