Claude Codeのハーネスを最初から全部組もうとして失敗した話

Last updated at 2026-06-13Posted at 2026-06-10

結論: 痛みが出てから1段ずつ足す

Claude Code の運用ハーネス（rules・skills・hooks・agent分担の総体）は、最初から全部組むと使う前に保守で疲れます。実際に早い段階で rules/ 分割や skill 量産に手を出して、使われない仕組みだけが増えました。

効いたのは、各段階に「次へ進む合図」を置き、痛みが出てから1段ずつ足すことでした。

以下、各ステップの要点と「早すぎると何が起きるか」を書きます。

最初は CLAUDE.md 1枚に方針と禁止事項を数行だけ書けば動きます。

# 方針
ユーザに同調せず、目的達成を優先する。

# 守ること
- コードを複数ファイル変更する規模なら、変更内容を説明してから許可を取る
- 公開・削除のような操作は勝手にやらない

ルールを足し続けて関係ない節を毎回読み飛ばすようになったら、本体を rules/ に分けて CLAUDE.md を目次にします。

@rules/git-ops.md
@rules/test-strategy.md
@rules/security-coding.md

ここで rules/ 分割から始めると、繰り返しの痛みが出ていない段階で構造を作ることになり、使われないまま保守対象だけが増えます。

同じ手順説明を3回したら、その1手順だけスキルに切り出します。全部をスキル化しない。

## 起動条件
- 「記事をレビュー」「公開前チェック」と言われたとき

## チェック項目
- フロントマター（title / topics / published）
- 文体NG語スキャン
- GitHub リンク・5行以上のコード・体験例
- 守秘義務（顧客名・本名）

早すぎると、使わないスキルが増えて、どれを呼ぶか自分で忘れます。1つ作って効果を感じてから次を足す方が続きました。

スキルで作業が速くなると、今度は取り消しにくい操作（公開・削除・push）を勝手に実行するリスクが出ます。その操作にだけ、明示確認のゲートを足します。

ゲート対象	通過条件
`published: true` への変更	セルフチェック済み・相互レビュー記録あり・ユーザーの公開明示あり

ゲートは全操作に付ける必要はありません。取り消しコストが高い操作に絞ります。

1台で実装もレビューもすると見落とします。自分で書いたものを自分で見て、公開後に抜けに気づいたら2台目（Codex）を入れるタイミングです。

役割	向いていた作業
Codex	実装・ファイル編集・初稿
ClaudeCode	方針整理・レビュー・別視点の確認

2台運用で複数セッションになると、「先週なぜそうしたか」が消えます。そこで設計判断は命題文ノートに、次セッションへの引き継ぎは handoff に残しています。

---
description: "判断の要旨を1文で"
alternatives: "検討した代替案"
rationale: "この選択をした理由"
status: active
type: decision
---

これも早すぎると、まだ誰も読み返さないノートの管理だけが増えます。判断を思い出せなくて困った経験が出てから足すくらいで間に合いました。

足すだけでなく捨てることも運用の一部です。私がやめたのは2つ。長いループ作業を会話の中で全部抱え込むこと（途中で文脈が膨らみ判断が雑になった）。もうひとつは、毎回アドバイザー（上位モデル）に相談すること（明らかな修正まで相談すると遅くなる）。

ルールを読んでも作業の質が変わらなくなったら、それは間引く合図です。

シリーズとして、組み上がった全体像は 5層の地図、変遷の物語は rulesとskillsに分けた話にまとめています。