2026/04/13Claude Code

Skills活用AI活用

「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で2025年10月から40以上のスキルを運用し、コーディングだけでなく記事執筆・提案書作成・調査・ファイル整理まで業務のほぼ全範囲をカバーしてきた経験から言えば、方向性として正しいと感じている。

「Thin Harness, Fat Skills」を一言でまとめると、ハーネス（CLAUDE.md・settings.json等の設定層）は最小限に抑え、知識と手順はすべてSkillsに集約する設計パターンだ。なぜこのパターンが有効なのか、実務で得た知見を交えて解説する。

「Agent = Model + Harness」——業界全体が向かう潜在的な合意

「Thin Harness, Fat Skills」はYegge単独の主張ではない。2026年2月にOpenAIが公式ブログで「ハーネスエンジニアリング」を使い始めて以降、Anthropic、LangChain、Martin Fowlerなど業界の主要プレイヤーがそれぞれの解釈を発表しており、モデルの能力が十分に高くなった今、ボトルネックはモデルの外側にあるという認識が共有されつつある。

LangChainは「Agent = Model + Harness（エージェント = モデル + ハーネス）」と定義した。つまりハーネスとはモデル以外のすべて——プロンプト、ツール設定、実行ロジック、品質チェックの仕組みを指す。この言い方がしっくりくるのは、「Thin Harness」が「モデルに何も建り物をするな」という意味ではなく、「ハーネスという層をデータ・スキル・フックスに分解し、本体は薄く保つ」という設計思想だからだ。

OpenAI——「人間が舵を取り、エージェントが実行する」

OpenAIのエンジニアRyan Lopopoloは、5ヶ月間エンジニアが手動でコードを1行も書かず、Codexエージェントだけで約100万行のアプリを構築した事例を公式ブログで発表した。核心は「Humans steer. Agents execute.（人間が舵を取り、エージェントが実行する）」という原則。エンジニアの役割は「コードを書くこと」から「エージェントが成果を出せる環境を設計すること」に変わったと述べている。

Anthropic——Generator-Evaluatorで「自己評価の罠」を切り離す

Claude Codeの開発元であるAnthropicは、ハーネス設計に関する記事でGenerator-Evaluator構造を提唱している。作業するエージェントと評価するエージェントを分離する考え方だ。背景には「エージェントは自分の仕事を評価すると、常にポジティブに偏る」という発見がある。人間でも自分の仕事を客観的に評価するのは難しいが、AIも同じだ。だからこそ、作業と評価を分離する設計が重要になる。

Anthropicはまた、「Context anxiety（コンテキスト不安）」という概念も指摘している。コンテキストウィンドウの上限が近づくと、AIが作業を早期に切り上げてしまう傾向があるという問題だ。

LangChain——ハーネスだけで性能+13.7%の実証

LangChainはベンチマークによる定量的な実証を行った。同じモデル（GPT-5.2 Codex）を使い、ハーネスの設計だけを変更した結果、タスク達成率が52.8%から66.5%に向上（+13.7ポイント）した。モデルを変えずに性能が13.7%上がる——これはハーネスエンジニアリングの価値を数字で証明した重要なデータだ。

Martin Fowler——ガイドとセンサーの2軸

ソフトウェア設計の権威であるMartin Fowlerのサイトでは、Birgitta Bockeler氏がハーネスを2軸で整理している。

ガイド（フィードフォワード制御）: エージェントが動く前に、正しい方向へ誘導する仕組み（CLAUDE.md、ルールファイル、Skills）
センサー（フィードバック制御）: エージェントが動いた後に、結果を検知して修正する仕組み（Hooks、品質ゲート）

「良いハーネスは人間の入力を完全に排除するのではなく、人間の判断が最も重要な場所に集中させるべきだ」という指摘は、実務で非常に共感できる視点だ。Thin Harnessはこの「ガイド」側をどこまで軽しく保つかの問題であり、重い制御は「センサー」（Hooks）で補う。

なぜ「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の認知負荷は上がり、本来やるべきタスクへの集中力が下がる。

思考予算問題に対する具体的な対策（3ポイント）

私自身はthinking budget問題に対して、以下の3点をsettingsとCLAUDE.mdに仕込んだ。

settings.jsonに "effortLevel": "high" を追加——デフォルトの思考予算を引き上げる。設定後、「また間違えてる」という場面はなくなった
showThinkingSummaries: true で思考過程を可視化——AIが何を考えているかを確認し、思考が浅い場合に気づける
CLAUDE.mdに「読んでいないコードは変更するな」を明示——調査を飛ばして編集に入る挙動を防止するルール

この経験は、ハーネスなしに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）: 第三者的な品質管理を強制する

Fowlerの2軸で言えば、ガイドライン層とルール層が「ガイド（フィードフォワード）」、監視層が「センサー（フィードバック）」に対応する。このうちハーネス（ガイドライン層）は「方向性」だけを担当する。具体的な手順はスキル、品質管理はHooksに任せる。だからThinでいい。

原劇2: AIが間違えやすいポイントはHooksで自動検出する

AIが間違えやすい部分には共通点がある。記事執筆時の言い回しや構成パターン、セキュリティ的な制御、Webサイト制作時のSEOやインデックス設定の漏れなど、パターン化できるミスだ。

これらのミスをCLAUDE.mdに「注意事項」として列挙するのは、Fatハーネスの典型的な失敗パターンだ。書いても見落とされる。代わりにHooksで事後チェックを強制する方が確実だ。

これはAnthropicが提唱するGenerator-Evaluator構造をHooksという機能で実装することにあたる。作業するAIと、それを監視するAIを分離することで、自己評価バイアスの問題を解消できる。

私の運用では、記事や提案書など公開物を生成するとき、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の設計パターンとして理にかなっている。そしてその資源、OpenAI・Anthropic・LangChain・Martin Fowlerという業界の主要プレイヤーがそれぞれの形で同じ設計思想に向かっている。

Thin Harness: CLAUDE.mdは目次にとどめ、詳細はルールファイルに分離する。品質管理はHooksで強制する
Fat Skills: 繰り返しタスクはすべてスキル化し、必要なときだけコンテキストに読み込む。共通ロジックはコンポーネント化する
3つの制御レイヤー: ガイドライン（方向性）→ Skills（手順）→ Hooks（品質管理）の分離が生産性を最大化する
LangChainのベンチマークが示す通り、同じモデルでもハーネス設計だけで+13.7ポイントの性能差が出る

AIの能力を最大限に引き出すのは、情報を大量に与えることではない。必要な情報を、必要なタイミングで、必要な粒度で提供することだ。それが「Thin Harness, Fat Skills」の本質であり、AIエージェント時代の設計思想だ。

Skills設計の基本的な作り方については、こちらの記事で詳しく解説している。