Claude Codeを業務自動化に使い始めると、最初は動くのに、徐々に設定・権限・プロンプトが絡み合って壊れていく──そういう経験をした人は少なくないと思います。
笹団子さん(@sasadango28)がZennで公開した「Claude Codeハーネスエンジニアリング」は、この問題に5層設計で答えた実装事例です。 個人の情報管理リポジトリで実践した構成を、再利用可能なテンプレートとして整理して公開しています(Zenn、2026年4月15日)。
僕が注目したのは「スコープ外の行動を明示的に禁止する」という設計思想です。 AIに「これをやれ」だけを書くと、意図しない範囲を勝手に変えて事故になります。 「やらないこと」を先に書く発想は、チームで使うときに特に効いてきます。
Claude Code運用で起きやすい問題
Claude Codeを複数業務や複数メンバーで運用し始めると、こういった問題が出てきます。
- プロンプト・権限・フック・ツールが一箇所に混在して読めなくなる
- 別メンバーが引き継いだとき「なぜこう動くのか」が分からない
- 権限設定が緩すぎて意図しないファイル変更・コマンド実行が起きる
- LLMにCSV処理やRSS取得まで任せてトークンを無駄遣いしている
- チームが増えるほど、設定変更の影響範囲が読めなくなる
「動いているうちはOK」で運用していると、ある日突然壊れて原因が追えない、という状況になります。
5層ハーネス設計の構成
笹団子さんが提案する設計は、5つのレイヤーで責務を分離するものです(Zenn、2026年4月15日)。
| レイヤー | ファイル | 役割 |
|---|---|---|
| Layer 1 | CLAUDE.md |
プロジェクト全体のルール・目的定義 |
| Layer 2 | .claude/rules/*.md |
ドメイン特化のルール(分割管理) |
| Layer 3 | .claude/skills/*/SKILL.md |
再利用可能なワークフロー |
| Layer 4 | .claude/agents/*.md |
専門特化したサブエージェント |
| Layer 5 | .claude/settings.json |
ツール権限・セキュリティ制御 |
設計の核となる3つの原則が紹介されています。
「やらないこと」を明記する ファイル整理の自動化禁止など、スコープ外の行動を明示的に制限します。 「やること」を書くだけでは、Claude Codeが意図しない範囲に踏み込んで事故になることがあるためです。
決定的処理をスクリプト化する RSSパース・CSV処理など、毎回同じ結果になる処理はPythonスクリプトで実装します。 LLMに任せるのは「判断」と「生成」のみ。 データ処理をLLM側に任せると、トークン消費とレスポンス時間が無駄に膨らみます。
責務を分離する CLAUDE.mdが肥大化するとコンテキストを圧迫します。 初期段階からドメインルールを .claude/rules/ に分割しておくことで、追加・削除の影響範囲を限定できます。
トークン1/6削減の内訳
具体的な改善例として、/tech-daily2 というスキルの実装が紹介されています。
初期版ではRSS取得をLLMが担当していたため、処理時間が長くトークン消費が大きい状態でした。 改善版ではRSS取得をPythonスクリプト側に移し、LLMはコンテンツ要約のみに集中する構成に変更しています。
結果として「トークン消費が1/6、処理時間が1/3に削減」されました(Zenn 笹団子、2026年4月15日)。
この改善は「LLMに全部任せる」から「LLMが得意なことだけ任せる」への切り替えです。 APIコストに直結するトークン消費の削減は、Claude Codeを継続運用するうえで実用上の意味が大きいです。
なお、引き継ぎ時間の短縮については、公開情報の範囲では具体的な数値の記載はありません。 5層で責務を分離することで「どのファイルを変えれば何が変わるか」が明確になる点は、設計上の意図として明記されています。
中小企業・中小開発チームで再現するなら
ここからが本題です。開発メンバーが5〜10名の中小チームで取り入れるなら、どう削るか。
構成
| 項目 | 笹団子さんの実装 | 中小開発チーム(5〜10名) |
|---|---|---|
| 対象 | 個人の情報管理リポジトリ | 複数メンバーで使うClaude Code運用環境 |
| ツール | Claude Code + Python(uv run) | 同左(Claude Code Max Plan、月3,000円/人〜、2026年4月時点。要最新価格確認) |
| 月額費用 | 数千円〜 | 推定 月1.5〜3万円(5名分、2026年4月時点) |
| 初期費用 | ほぼゼロ(セルフ設計) | 推定 20〜50万円(ハーネス設計+チーム教育+テンプレ整備) |
| 体制 | 個人1名 | リード1名+チームメンバー |
| 期間 | 継続的に改善 | 基本設計1〜2週間、チーム適用1ヶ月 |
評価軸スコア
| 評価軸 | スコア |
|---|---|
| ROI(投資対効果) | ★★★★☆ |
| 再現性(中小企業) | ★★★☆☆ |
| 難易度(低いほど簡単) | ★★★☆☆ |
(難易度=数字小さいほど簡単)
スコア根拠は以下です。
- ROIが高いのは、トークン消費削減がAPIコスト削減に直結し、引き継ぎコストの低減も見込めるため
- 再現性は中程度。5層の設計思想は汎用的だが、初期設計段階でチームの合意が必要
- 難易度は中程度。ファイル構造の理解とPython環境の整備が最初のハードルになる
前提条件・必要データ
- Claude Codeを少なくとも1業務で日常的に使っている、または使い始めている
- Pythonの基礎的な書き方が分かるメンバーが1名以上いる
- チームで設定ルールを共有できるGitリポジトリ環境がある
- 月間でClaude Code APIコストが5,000円以上発生している(削減効果が出やすい目安)
失敗条件・適用しないケース
- Claude Codeを月に数回しか使わない(設計コストが回収できない)
- 「全部CLAUDE.mdに書けばいい」と思って5層に分けない(後で読めなくなる)
- Pythonスクリプト化を怠って全処理をLLMに任せる(トークン消費が削れない)
- ルールを書いても定期的に見直さない(設定とコードがズレて事故の元になる)
- チームメンバーが設定ファイルを直接変えて競合する(変更フローを事前に決めないと混乱する)
「Claude Codeを入れれば自動で安全になる」わけではありません。
ハーネス設計の初期構築→チーム合意→Python化→定期見直し、の4ステップで初めて、複数人・複数業務で安定して動く体制が作れます。
「Claude Code使えてるけどなんかカオスになってきた」という段階のチームには、この設計パターンが判断の指針になります。
出典・参考
市野
愛知県岡崎市でAI活用支援を手がける一人社長。 中小企業の現場でAIを実装してきた経験から、他社事例を「うちで再現するには」の視点で読み解いて発信中。
