# 重い作業でも使用量が増えないClaude Codeの運用設計。スキル・フック・オーケストレーション・記憶の4層

- URL: https://www.highdef.jp/news/98js_z98de/
- 分類: HIGHDEF NOTE
- 著者: 佐藤 宏（株式会社ハイデフ 代表取締役）
- 公開日: 2026.07.02
- 更新日: 2026.07.02
- 発行: 株式会社ハイデフ（新潟県上越市） https://www.highdef.jp/

---

結論から言うと、AIの成果は「どのツールを使うか」ではなく「どう組むか」で決まります。私は2名の会社で、Claude Code を業務の中枢に据えています。経理も、議事録も、メール返信も、このブログ記事の制作も、広告の出稿も、ここを通る。そして相当な負荷の作業を回しても、使用量（クレジット）はそれほど伸びません。理由は根性でも我慢でもなく、**運用を設計してあるから**です。

この記事は、2026年7月時点でハイデフが実際に使っている構成をそのまま開示します。スキル15個、コマンド6個、サブエージェント9体、ルール4本、外部連携（MCP）11本、自動フック4系統。地方の2名の会社でも、ここまで組めます。

## 差がつくのは「使い方」ではなく「運用設計」だ

生成AIを開いてプロンプトを打つ。ここまでは誰でもできます。差がつくのはその先、**同じ品質を再現する仕組みを持っているか**です。プロンプトの一発芸は、打った本人の調子とその日の気分に成果が左右される。仕組みは、そうならない。

私がこの1年で洗練させてきたのは、プロンプトの上手さではありません。Claude Code を「毎回ゼロから指示する相棒」から「会社のルールと過去の学びを積んだ実務OS」に変える、その設計です。具体的には次の4層で組んでいます。

![ハイデフのClaude Code 4層構成図。ルール・スキル・オーケストレーション・記憶の4層](https://images.microcms-assets.io/assets/8779779a1bf246e39228c779f654eea6/e347bf65b77d4d139b9f6afa0e41156d/fig_01.png)

ハイデフのClaude Code運用は4層で組んでいる

## 4層で組む——ルール・スキル・オーケストレーション・記憶

4層それぞれに役割があります。単発の便利ツールではなく、積み上がる資産にするための構造です。

| 層          | 役割                   | 実例                         | 件数   |
| ---------- | -------------------- | -------------------------- | ---- |
| ルール        | 会社の判断基準を常に読ませる。品質ゲート | 文体・ブランドボイス・リサーチ品質・戦略品質     | 4本   |
| スキル／コマンド   | 頻出の作業手順を型にして呼び出す     | 市場調査・競合分析・議事録・記事制作・広告出稿    | 15＋6 |
| オーケストレーション | 難易度で仕事を振り分け、並列で回す    | 調査・分析・戦略・執筆の専門エージェント       | 9体   |
| 記憶         | 過去の学びと失敗を蓄積し再利用する    | lessons（学びログ）・memory（自己記憶） | 26件＋ |

ポイントは、この4層が最初から在ったわけではないということです。訂正されるたび、手戻りが起きるたびに1枚ずつ足してきた。**使い込むほど積み上がる設計にしてある**から、時間が経つほど楽になります。

## 設計思想は「最悪を織り込む」こと

ここで、根っこにある考え方を一つ明かします。私の運用設計は、一貫して**ネガティブな出発点から始まっています**。AIは間違える。私は忘れる。事故は起きる。まず、そう置く。そのうえで、間違いと事故を機械的に止める仕組みを先に組んでおく。すると逆に、安心して速く動けるようになります。

「うまくいく前提」で組んだ仕組みは、想定外が起きた瞬間に止まります。「事故る前提」で組んだ仕組みは、止まらない。データベースへの直接書き込みを禁止するフックも、散らかりを自動で片付けるフックも、失敗を学びログに残す仕組みも、根っこは全部同じです。**性悪説で仕組みを組み、性善説で動く。**悲観を設計の中に閉じ込めてしまうから、日々の行動は楽観でいられる。

これは精神論ではありません。気合いで注意深くあろうとするのではなく、注意深さそのものを機械に肩代わりさせる。だから、疲れていても品質が落ちない。ネガティブを出発点に置くことは、後ろ向きではなく、**前に進み続けるための土台**なんです。

## 手戻りを消す仕掛け——品質ゲートと自動フック

結論から言うと、人間が毎回やっていた「確認」と「後片付け」を機械に落とすと、作業は静かに速くなります。ハイデフでは2つの仕掛けで、雑務をAIとの対話から外しています。

1つ目が**ルール＝品質ゲート**です。各ルールには「どのフォルダを触るときに効くか」を指定してあり、記事フォルダを触ればコンテンツ制作ルールが、リサーチ成果物を触れば品質基準が、自動で適用される。文体がブレたドラフト、ソースの無い数字は、その場で差し戻される仕組みです。

2つ目が**フック**。ユーザーの許可を待たずに走る自動処理で、いま4系統動いています。

- **停止時の自動検証**：作業が一区切りするたび、直近で触ったコードを構文チェックし、データベースの整合性まで確認して報告する
- **DBガード**：会社の正本データベースへの直接書き込みを機械的に禁止する（事故防止）
- **散らかり自動掃除**：フォルダのルート直下に紛れた一時ファイルを、自動で退避する
- **「おはよう」で朝の情報チェック起動**：短く「おはよう」と打つだけで、カレンダー・メール・タスクの確認が自動で走る

どれも、以前は私が手でやっていたか、やり忘れて事故になっていた作業です。それを機械に任せた。**雑務は対話から外す。人間は判断だけに集中する。**これが手戻りを消す一番効く方法でした。

## 難しい仕事だけ、賢いモデルを使う

ここがコスト効率の肝です。すべての作業に最上位のモデルを使うのは、軽トラで買い物に行くのにダンプカーを出すようなもの。私はタスクの複雑度でモデルを使い分けています。

![オーケストレーションとモデル使い分けの図。メインClaudeがサブエージェントに委譲し、複雑度でモデルを振り分ける](https://images.microcms-assets.io/assets/8779779a1bf246e39228c779f654eea6/1e272cc59d5b4cc79130c1d5bb89b896/fig_02.png)

難易度で担当とモデルを振り分け、メインの負荷を守る

- **単純な監査・整合性チェック**：最軽量のモデル（Haiku）に任せる
- **調査・分析・執筆**：中位のモデル（Sonnet）で回す
- **大規模リサーチ・戦略導出・難解なデバッグ**：ここだけ最上位モデルを起動する

もう一つ効くのが**サブエージェントへの委譲**です。大量のファイルを読む調査は、専門の子エージェントに丸ごと押し込む。メインの私（オーケストレーター）は、その結論だけを受け取る。**重い読み取りでメインの作業領域を汚さない**——これが効率と品質の両方を守ります。1つのエージェントには1つのタスクしか渡さない、というルールも徹底しています。

## なぜ重い作業でも、使用量が跳ねないのか

結論から言うと、使用量はタスクの量ではなく、**どれだけ無駄なトークンを捨てられるか**で決まります。作業を増やしても、無駄を捨て続ければ消費は比例して増えない。ハイデフが使用量を抑えている仕掛けは、次の6つです。

| 仕掛け         | 何を捨てているか                                            |
| ----------- | --------------------------------------------------- |
| コンテキスト衛生    | 使用率をバーで常時可視化し、節目で会話を圧縮・無関係な作業の前にはリセット。膨らんだ文脈を運び続けない |
| サブエージェント隔離  | 重い調査の中身は子に閉じ込め、メインは結論だけ受け取る。探索の残骸を本体に持ち込まない         |
| モデルの使い分け    | 軽い仕事に高いモデルを使わない                                     |
| 自動フック       | 検証・掃除・DBガードを機械に任せ、AIとの対話ターンを消費しない                   |
| 型化（スキル・ルール） | 毎回ゼロから手順や前提を説明しない                                   |
| 記憶（学び・自己記憶） | 同じ調査・同じ失敗を二度繰り返さない                                  |

言い換えると、私がやっているのは「たくさん使う工夫」ではなく「**無駄を出さない工夫**」です。膨らんだ会話を延々と引きずれば、1回のやり取りが重くなる。だから節目で捨てる。可視化バーが黄色になれば圧縮を検討し、赤になれば必ず圧縮する。無関係なタスクに移るときは会話ごとリセットする。この衛生習慣だけで、重い1日を回しても使用量は驚くほど伸びません。

実際の数字を出します。この記事そのものを作ったセッション——リサーチ用のサブエージェント起動、図解3枚のブラウザレンダリング、CMSへの入稿と検証まで含めて、実作業およそ2時間——の消費が、**定額プランの週あたりの枠の6%**でした。従量課金に換算しても$12.83。かなり重い部類の作業をひと回しして、この程度です。

理由の一つはキャッシュです。このセッションで読み込んだ入力のうち、**約1,160万トークンはキャッシュからの再利用**でした。会社のルールやファイルという同じ前提を毎回フルで課金し直すのではなく、使い回している。だから作業を積み重ねても、入力コストは素直には膨らみません。

そしてもう一つ。**使用量はブラックボックスではありません。**Claude Codeは内訳を見せてくれます。今日のセッションなら「消費の61%はサブエージェントの多用」「53%は15万トークンを超える長い文脈」と、どこが効いているかが数字で分かる。分かれば、削れる。使用量は勘で怯えるものではなく、**計器を見て調整する変数**です。ここでも思想は同じで、無駄が出る前提で計器を組んでおくから、安心してアクセルを踏めます。

「AIは使うと高い」のではありません。**無駄に使うと高い。**設計すれば、使った量ではなく、無駄の量で決まります。

## 失敗を資産に変える——自己改善ループ

この構成が効く最大の理由は、**間違えるたびに賢くなる**ことです。私が訂正すると、Claude はその原因を「学びログ」に記録し、再発を防ぐルールを自分で書きます。いま26件たまっています。実例を挙げます。

- あるツールがデバッグ設定時に環境変数を平文で出力し、機密が漏れかけた → 起動手順のルール化
- 画像のメタデータ除去ツールが、AI生成の来歴情報を見落としていた → 専用スキルを改修
- メールは作成しても送信前に必ず人が確認する → 例外なしのルールに

1回目の失敗は事故です。2回目の同じ失敗は設計ミスです。**失敗を個人の反省で終わらせず、仕組みに変換する。**これができると、同じ担当者が2人目、3人目に増えても品質が落ちません。属人化の逆を、AI運用で実装しているわけです。

## 地方の中小企業こそ、この設計が効く

正直に言うと、この運用に高度なプログラミングは要りません。要るのは「自社の判断基準を言語化する力」と「失敗を仕組みに変える規律」です。どちらも経営者の仕事の中身そのものではないでしょうか。

地方の中小企業は、意思決定者と現場の距離が近い。全社一斉ではなく、1つの業務から局地戦で始められる。大企業のような合意形成のコストがない分、**設計して回し始めるまでが速い**。ここは地方の弱みではなく、明確な強みです。2名の会社がここまで組めているのが、その証拠です。

## FAQ

**Q. エンジニアでないと使えないのでは？**\
いいえ。私は経営者で、コードを書くのが本業ではありません。それでも経理・議事録・メール・記事制作・広告出稿まで回しています。必要なのはプログラミング能力より、自社のルールを言葉にする力です。

**Q. 重い作業を回すと料金が跳ね上がりませんか？**\
使用量はタスクの量ではなく設計で決まります。膨らんだ文脈を捨てる、軽い仕事に高いモデルを使わない、雑務は自動化する。この3つだけで、作業量のわりに消費は伸びにくくなります。

**Q. 何から始めればいいですか？**\
まず「会社のルールを書いた1枚」と「よく使う作業を型にした1つのコマンド」から。最初から15個のスキルは要りません。型化を1つ作り、訂正のたびに1枚足す。それだけで積み上がります。

**Q. 地方の小さな会社でも意味がありますか？**\
むしろ有利です。意思決定が速く、1部署から局地戦で始められる。全社導入で失敗する大企業より、成果を数字で証明してから横展開する道を取りやすい。

## まとめ

AIの成果は、ツールの性能ではなく運用設計で決まります。ルール・スキル・オーケストレーション・記憶の4層で組み、雑務は機械に落とし、難しい仕事だけ賢いモデルに任せ、無駄なトークンを捨て続ける。そして失敗を仕組みに変える。根っこにあるのは、**悲観を設計に閉じ込め、行動は楽観でいく**という一貫した思想です。**使い込むほど賢く、安くなる設計**は、地方の2名の会社でも作れます。

▶︎ [自社サイトをAstro＋microCMSで作り直した全記録。ノーコードの負債からGEO最適化まで](https://www.highdef.jp/news/qx38zjv3dct/)

▶︎ [生成AI、もう"使う側"と"使われる側"に分かれてる件](https://www.highdef.jp/news/l6l7kxo1/)
