「Thin Harness, Fat Skills」とは？Claude Codeの生産性が変わる設計パターン
「Thin Harness, Fat Skills」とは何か
Claude Codeの「Skills」を使いこなしている人は多い。しかし、CLAUDE.mdにあれもこれもと書き込んで、気づけばハーネス（設定ファイル群）が膨れ上がっている人も少なくないはずだ。
2026年4月、YCombinator代表のGarry TanがXで共有した投稿が大きな反響を呼んだ。元GoogleのSteve Yeggeが提唱した「Thin Harness, Fat Skills」というAIエージェント設計パターンだ。Yeggeの主張によれば、AIコーディングエージェントを使いこなすエンジニアは「従来のIDE利用者の10倍〜100倍の生産性を発揮する」という。
この数字は誇張に聞こえるかもしれない。しかし私自身、Claude Codeで40以上のスキルを運用し、コーディングだけでなく記事執筆・提案書作成・調査・ファイル整理まで業務のほぼ全範囲をカバーしてきた経験から言えば、方向性として正しいと感じている。
「Thin Harness, Fat Skills」を一言でまとめると、ハーネス（CLAUDE.md・settings.json等の設定層）は最小限に抑え、知識と手順はすべてSkillsに集約する設計パターンだ。なぜこのパターンが有効なのか、実務で得た知見を交えて解説する。
なぜ「Thin Harness」が重要なのか
CLAUDE.mdを書きすぎると逆効果になる
CLAUDE.mdはClaude Codeのプロジェクト設定ファイルだ。プロジェクトのルール、技術スタック、ディレクトリ構成などを記述することで、AIがプロジェクトの文脈を理解した上で作業できるようになる。
しかし、ある研究ではCLAUDE.mdへの記載量が一定以上増えると、コンテキスト量の増加により逆にAIの作業精度が下がることが指摘されている。私自身もCLAUDE.mdに情報を追加するほど、AIが指示を見落とすケースが増えた経験がある。
2026年3〜4月には、Claude Codeの「思考予算（thinking budget）」のデフォルトがmediumに変更されたことで品質低下が広く報告された。GitHub issue #42796では6,852セッション・17,871思考ブロックの分析から、思考の深さが低下するとAIは「調査優先」から「編集優先」にシフトし、ファイルを読まずに編集に飛びつく傾向が出ることが裏付けられている。
コンテキストが多い環境でこの問題が顕在化するのは当然だ。ハーネスが厚ければ厚いほど、AIの認知負荷は上がり、本来やるべきタスクへの集中力が下がる。
Thinハーネスの実践｜200行以下が目安
私のCLAUDE.mdの運用方針は「あまり書き込みすぎない」だ。具体的には以下を心がけている。
- プロジェクトの概要とディレクトリ構成は書く（AIがファイルを探す起点になるため）
- 技術スタックと禁止事項は書く（致命的なミスを防ぐため）
- 詳細なルールはCLAUDE.md本体ではなく別ファイル（.claude/rules/）に分離する
- コードで表現できるルールはCLAUDE.mdに書かず、Hooksで強制する
CLAUDE.mdはあくまで「目次」であり「辞書」ではない。詳細は必要なときだけ参照すればよい。この「必要なときだけ読み込む」仕組みこそが、Thinハーネスの本質だ。
なぜ「Fat Skills」が重要なのか
Skillsは「再利用可能な専門知識」
Claude Code Skillsは、特定のタスクに対する詳細な手順・ルール・テンプレートをまとめたファイルだ。スキルが呼び出されたときだけコンテキストに読み込まれるため、普段はAIの認知負荷を増やさず、必要な場面でだけ専門知識を発揮する。
私が運用している40以上のスキルには、以下のようなものがある。
- SEO記事→MicroCMS投稿: キーワード選定→記事執筆→サムネイル生成→挿絵生成→CMS投稿→既存記事CSV更新まで一気通貫で実行
- PDF提案書生成: クライアント向けの提案書をHTML→Puppeteer→PDF変換で自動生成
- GSCレポート: Google Search Consoleのデータを取得→分析→対策提案まで自動化
- ポートフォリオ画像生成: 制作実績のモックアップHTMLをスクリーンショットで自動生成
これらのスキルは、それぞれが独立した「専門家」のように機能する。SEO記事スキルはSEOの専門知識を持ち、PDF生成スキルはレイアウトの専門知識を持つ。ハーネス（CLAUDE.md）にこれらすべてを書き込んだら、何千行にもなるだろう。
GitHubスキルの収集→改良が加速する
スキルの活用法として特に有効なのが、GitHubで公開されている人気スキルを収集し、中身を読んで理解した上で、自分のワークフローに合うよう改良して使う方法だ。
ゼロから全てを自作する必要はない。他のエンジニアが試行錯誤して完成させたスキルを土台にして、自分の業務フローに最適化する。このアプローチなら、スキルの数を短期間で増やせる。
スキルの「太さ」には限度がある
ただし「Fat Skills」とはいえ、1つのスキルに全てを詰め込むのは逆効果だ。私の経験では、1スキルあたり300〜500行が実用的な上限だ。それを超えると、スキル内の情報量が多すぎてAIが指示を見落とすようになる。
対策として、共通のロジック（画像生成手順、MicroCMS投稿手順など）は共通コンポーネントとして切り出し、各スキルから参照する構造にしている。これはソフトウェア開発の「DRY原則」と同じ考え方だ。
実務で得た3つの設計原則
原則1: ハーネスは「制限」のために使う
私がハーネスエンジニアリングで最も重要だと考えているのは、「制限することで本質的な価値を高めること」だ。
レースカーに例えると分かりやすい。どれだけ強大なエンジンを積んでいても、それだけではレースに勝てない。車体（躯体）を設計し、エンジンを適切に制御する必要がある。エンジンのパワーは制限されるが、結果としてゴールへ近づき、全体としての性能は向上する。
Claude Codeも同じだ。AIの能力を無制限に使わせるのではなく、3つのレイヤーで制御する。
- ガイドライン層（CLAUDE.md・ルールファイル）: 方向性を示す
- ルール層（Skills・コマンド）: 具体的な手順を規定する
- 監視層（Hooks）: 第三者的な品質管理を強制する
このうちハーネス（ガイドライン層）は「方向性」だけを担当する。具体的な手順はスキル、品質管理はHooksに任せる。だからThinでいい。
原則2: AIが間違えやすいポイントはHooksで自動検出する
AIが間違えやすい部分には共通点がある。記事執筆時の言い回しや構成パターン、セキュリティ的な制御、Webサイト制作時のSEOやインデックス設定の漏れなど、パターン化できるミスだ。
これらのミスをCLAUDE.mdに「注意事項」として列挙するのは、Fatハーネスの典型的な失敗パターンだ。書いても見落とされる。代わりにHooksで事後チェックを強制する方が確実だ。
私の運用では、記事や提案書など公開物を生成するとき、Hooksが自動的に発火し、事前に定義したチェックリスト（表記ルール・クライアント特定防止・数字の正確性等）と照合する。基準を満たさない箇所があれば修正指示が出る。人間が毎回目視確認する手間を省きつつ、品質を担保できる。
原則3: コンテキスト管理は「プロジェクト×Markdown」に統一する
Claude Codeの知識管理は試行錯誤の歴史だ。私自身、以下の遍歴を経て現在の形に落ち着いた。
- メモリファイルのみ: セッション間でほぼコンテキストが引き継がれない
- スキル内保持: スキルが細分化されすぎて管理が煩雑に
- 外部ツール連携（Notion・Obsidian）: 各ツールのフォーマットに合わせる必要があり、自由度が低い
- プロジェクト単位GitHub管理＋Markdownデータフォルダ: ここでようやく問題が解消
現在はプロジェクトのdata/フォルダにMarkdownで知見を蓄積し、GitHubプライベートリポジトリで管理する形に統一している。Thin Harnessの文脈で言えば、知見はハーネスではなく「データ」として分離し、スキルが必要なときだけ参照する設計だ。
「Thin Harness, Fat Skills」を実現するための具体的な手順
Step 1: CLAUDE.mdを棚卸しする
まず現在のCLAUDE.mdを見直す。以下に該当する記述は別ファイルに移動する。
- 特定タスクの手順（デプロイ手順、テスト手順等）→ スキル化
- 詳細なルール（コーディング規約、記事執筆ルール等）→ .claude/rules/ に分離
- チェックリスト（レビュー基準、品質基準等）→ Hooks化
CLAUDE.mdに残すのは、プロジェクト概要・ディレクトリ構成・技術スタック・禁止事項だけだ。
Step 2: 繰り返しタスクをスキル化する
週に2回以上実行するタスクはスキル化の候補だ。以下の観点で優先度をつける。
- 手順が固定的: 毎回同じ手順を踏むタスク（記事投稿、レポート生成等）
- 品質基準がある: 「こうあるべき」が明確なタスク（コードレビュー、提案書作成等）
- 複数ステップ: 3ステップ以上のタスク（データ収集→分析→レポート等）
Step 3: 共通ロジックをコンポーネント化する
複数のスキルで同じ処理（画像アップロード、CMS投稿等）が必要な場合、共通コンポーネントとして切り出す。各スキルからは参照するだけでよくなり、修正も1箇所で済む。
Step 4: Hooksで品質ゲートを設置する
AIが公開物（記事・メール・提案書）を生成するワークフローには、必ずHooksで品質チェックを入れる。チェック項目はCLAUDE.mdではなく、専用のチェックリストファイルに定義する。
Step 5: 定期的にスキルを見直す
月に1回、スキルの棚卸しを行う。使っていないスキルは削除し、よく使うスキルは改良する。スキルの数が増えすぎると管理コストが上がるため、統合できるスキルは統合する。
失敗パターン: Fatハーネスの末路
「Thin Harness, Fat Skills」の逆、つまりFatハーネスでThinスキルの構成を最初に試す人は多い。CLAUDE.mdにプロジェクトの全ルールを書き込み、スキルはほとんど使わない。
この構成の問題点は3つある。
- AIの精度低下: コンテキスト量が多すぎて、重要な指示を見落とす
- 保守コストの増大: ルールを変更するたびにCLAUDE.md全体を読み返す必要がある
- 再利用性ゼロ: 別プロジェクトに知識を持ち出せない
スキル化していれば、SEO記事の書き方は別プロジェクトでも同じスキルを使い回せる。しかしCLAUDE.mdに直書きしていると、プロジェクトに紐づいてしまい移植が困難になる。
まとめ
Steve Yeggeが提唱し、Garry Tanが共有した「Thin Harness, Fat Skills」は、Claude Codeの設計パターンとして理にかなっている。
- Thin Harness: CLAUDE.mdは目次にとどめ、詳細はルールファイルに分離する。品質管理はHooksで強制する
- Fat Skills: 繰り返しタスクはすべてスキル化し、必要なときだけコンテキストに読み込む。共通ロジックはコンポーネント化する
- 3つの制御レイヤー: ガイドライン（方向性）→ Skills（手順）→ Hooks（品質管理）の分離が生産性を最大化する
AIの能力を最大限に引き出すのは、情報を大量に与えることではない。必要な情報を、必要なタイミングで、必要な粒度で提供することだ。それが「Thin Harness, Fat Skills」の本質であり、AIエージェント時代の設計思想だ。
Skills設計の基本的な作り方については、こちらの記事で詳しく解説している。
また、CLAUDE.mdの書き方と「書きすぎない」運用のコツはこちら。
Hooksを使った品質チェック自動化の具体的な手順はこちらで解説している。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。