Claude Code を導入したばかりの頃は「賢い補完エンジン」として扱いがちです。しかし、半年ほど運用を続けているうちに、私の中での位置づけは大きく変わりました。Claude Code は便利な道具ではなく、開発プロセスそのものを駆動する『基盤』として設計したほうがよい、という結論に至っています。
ここで言う運用設計とは、単に CLAUDE.md を書く・スラッシュコマンドを増やすといった個別テクニックの集合ではありません。プロジェクトの記憶（CLAUDE.md）、外部システムとの接続（MCP）、ワークフロー自動化（skills）、品質保証（hooks）、作業の並列化（サブエージェント）の5つを軸として一貫した考え方で組み上げると、Claude Code の振る舞いが驚くほど安定します。
ここでは私自身が4つのサイト（Dolice Labs）の運用で実際に効いた構成を、なるべく汎化した形でまとめます。コード断片もすべて実プロジェクトで動いている実例ベースです。
軸1: プロジェクトの記憶を CLAUDE.md に集約する
Claude Code の最大の特徴は『プロジェクトを横断する記憶』を CLAUDE.md という1ファイルに集約できる点です。リポジトリ直下に置けば、新しいセッションでも自動的に読み込まれます。
最初は「READMEと何が違うのか」と思っていたのですが、READMEが『人間に読ませるもの』であるのに対して、CLAUDE.md は『AIに読み込ませる前提の、もう少しドライな指示書』として機能します。私が最近採用しているテンプレートは次のようなものです。
# プロジェクト名 — CLAUDE.md
## プロジェクト概要
（1〜2段落で、何のリポジトリか・誰が読者か）
## 最重要ルール
1. 必ず日英セットで作る
2. push前に件数一致を確認
3. /tmp/ で作業し本リポは触らない
## 自律実行ポリシー
- ユーザー確認は行わず最善判断で進める
- エラー時は自動リカバリを試みる
## トラブルシューティング表
| 問題 | 対処 |
|---|---|
| git push 失敗 | git pull --rebase 後に再push |ポイントは『最重要ルール』『自律実行ポリシー』『トラブルシューティング表』の3つを必ず入れること。最重要ルールは Claude Code が忘れがちな制約を3〜5項目に絞って明記し、自律実行ポリシーは「どこまで自分で判断してよいか」の境界を決めます。トラブルシューティング表は、過去にハマった失敗とその対処を表形式で残しておくと、似た問題で再度時間を溶かすことがなくなります。
CLAUDE.md は肥大化しやすいので、プロジェクト固有の運用ガイドは別ファイルに切り出して _documents/ 等に置き、CLAUDE.md からは『どこを参照すべきか』だけ指示するのがおすすめです。
軸2: MCP で外部システムとの接続を『当たり前』にする
MCP（Model Context Protocol）は、Claude Code に外部ツールを接続するための共通プロトコルです。GitHub、Slack、データベース、社内APIなど、Claude Code が直接触れるべきリソースは MCP サーバとして登録しておくと、毎回手作業でコピペする必要がなくなります。
私が必ず最初に入れるのは、自分の運用するシステムに直接触れる MCP です。たとえば Cloudflare Workers にデプロイしているサイトであれば、Cloudflare の MCP を入れて、Worker のログ確認やKV操作を Claude Code から直接できるようにしておきます。
設定ファイル（.claude/settings.json 等）には、MCP サーバの宣言だけでなく、各 MCP の用途を必ずコメントで残します。
{
"mcpServers": {
"cloudflare": {
"command": "npx",
"args": ["@cloudflare/mcp-server-cloudflare"],
"comment": "Worker ログ確認・KV操作・デプロイ状況確認に使用"
}
}
}comment フィールドは公式仕様には存在しませんが、Claude Code は JSON コメントを読むので、用途のメモを残しておくと数か月後の自分が助かります。
軸3: skills で『繰り返す手順』を完全に固定化する
スラッシュコマンドや skills（.claude/skills/）は、頻出する手順を固定化するのに使います。私の場合、ブログ記事の執筆ワークフローを _skills/{site}/SKILL.md として完全にステップ化しています。
skills の良いところは、Claude Code 自身が「いま skills を呼ぶべきか」を文脈から判断してくれる点です。description を書くときは、トリガーになりそうな表現をなるべく具体的に列挙します。
---
name: site-content-update
description: "site.net の記事を生成・push する。トリガー: 記事を書いて, 投稿して, blog を更新, 記事生成"
---
# 記事更新スキル
## Step 0: リポジトリ準備
... 実行コマンド ...
## Step 1〜8
... 各ステップ ...description には『何をするスキルか』ではなく『どういう発話で発火させたいか』を書くのが結果的に効きます。「記事を書いて」「投稿して」のような自然な発話を含めると、ユーザーが特殊な呼び出しを覚えなくても自然に発火します。
軸4: hooks で品質保証を仕組みに落とす
hooks は Claude Code が特定のタイミング（ファイル編集前後、コマンド実行前後など）でカスタムスクリプトを走らせる仕組みです。私はこれを『品質保証の最後の砦』として使っています。
たとえば私が運営しているブログサイトでは、MDX を書いたあとに必ず以下を走らせています。
- フロントマターの YAML が壊れていないか検証
- 日英の記事数が一致しているか確認
- 内部リンクが実在する記事を指しているかチェック
これを hooks に登録しておけば、Claude Code が記事を書き終えた瞬間に自動で走り、問題があればその場で修正に入ります。「品質チェックを忘れる」というヒューマンエラーが構造的に起きなくなるのが大きな価値です。
#!/bin/bash
# .claude/hooks/post-edit-mdx.sh
FILE="$1"
[[ "$FILE" == *.mdx ]] || exit 0
# フロントマター検証
node scripts/validate-frontmatter.mjs "$FILE" || exit 1
# 日英件数チェック
JA=$(find content/articles/ja -name "*.mdx" | wc -l)
EN=$(find content/articles/en -name "*.mdx" | wc -l)
[ "$JA" -eq "$EN" ] || echo "⚠️ JA=$JA EN=$EN — 不一致"hooks は速く・冪等に・失敗時に明確なメッセージを返すこと。この3つを守ると Claude Code が hook の出力を読んで自分で修正に入ります。
軸5: サブエージェントで作業を並列化する
長時間タスクは1つのセッションで抱え込むよりも、サブエージェントに分割したほうが速く・安全に終わります。サブエージェントとは、メインの Claude Code セッションから別プロセスの Claude Code を呼び出して特定のタスクだけを任せる仕組みです。
私が普段やっている分割パターンは次の3つです。
第一に、調査と実装を分ける。「このリポジトリのどこにキャッシュ層があるか調べる」のような調査タスクは、メインのコンテキストを汚さずにサブエージェントへ。返ってくる結果（ファイルパスと該当箇所のサマリ）だけを使って実装に入ります。
第二に、複数サイトへの同時反映を並列化します。私のように4サイトを同時に更新するケースでは、サイトごとにサブエージェントを起動して独立したワーキングディレクトリで作業させると、待ち時間がほぼ4分の1になります。
第三に、検証専用エージェントを用意します。実装が終わったあとに「品質チェック専用」のサブエージェントを呼び、独立した目線で diff をレビューさせます。実装したエージェント自身が自分の成果物をレビューするより、別エージェントのほうが見落としが少ない印象です。
5つの軸はそれぞれ補強し合う
ここまで紹介した5つは独立した機能ではなく、互いに補強し合います。CLAUDE.md で指針を示し、MCP で外部接続を確立し、skills で繰り返し手順を固定し、hooks で品質を担保し、サブエージェントで並列化します。この一連の設計が回り始めると、Claude Code は『便利な道具』ではなく『開発の中心』として機能し始めます。
正直に言うと、ここまで作り込まなくても日常的な開発は十分回ります。ただ、繰り返し作業や複数プロジェクトの並行運用が増えてくると、運用設計をしていない場合との差は加速度的に開いていきます。
次の一歩としておすすめなのは、CLAUDE.md の『最重要ルール』『自律実行ポリシー』『トラブルシューティング表』の3つを今日中に書き出してみることです。何度も同じことを Claude Code に伝えていた自分に気付くはずで、そこが運用設計の出発点になります。