ハーネスエンジニアリングを個人規模で考えてみた
こんにちは！つつです！
「ハーネスエンジニアリング」という言葉を最初に見かけたとき、大規模なシステムを持つ組織向けの話だと読み流していました。でも "Thin" と "Self-healing" という二語に引っかかってもう一度読み直したら、自分が最近組んでいたブログ自動化パイプラインの設計そのものの話だと気づいて、少し焦りました。
ハーネスエンジニアリングとは何か
まず言葉の定義を整理します。
ハーネスエンジニアリングとは、AI エージェントが自律的に動けるよう「環境側」を設計することを指します。「ハーネス」は馬具から来ており、馬（AI モデル）の力を安全に引き出すための装具に例えています。プロンプトだけでなく、ツールの定義・指示ファイル・テスト・ビルド検証など、エージェントの行動を制御・補佐する仕組みの総称です。
提唱者によって定義の範囲は少し異なりますが、「モデルに直接頼むだけでなく、モデルが動く環境を整える」という発想は共通しています。CLAUDE.md に指示を書いている人は、すでにハーネスエンジニアリングの一端を実践していることになります。
Thin Harness, Fat Skills という考え方
ここしばらく話題になっているのが、"Thin Harness, Fat Skills" というフレームワークです（Y Combinator CEO の Garry Tan が提唱したとされています）。
要旨を言葉で整理するとこうなります。
- Thin（薄いハーネス）: ハーネスのコアロジックはできる限り小さく保つ。エージェントの動き方を事前にすべて固定しようとしない
- Fat Skills（厚いスキル）: 役割ごとの手順・判断基準・参考情報はスキルファイル（Markdown 等）として外側に配置する
- Fat Code（厚いコード）: 決済・削除など「絶対に間違えられない操作」は決定論的なコードで実装して逃げない
上の図が示すように、ハーネスは「誰に何を任せるか」だけを薄く持ち、知識はスキルファイルへ、確実性が要る処理は決定論的コードへと分離する構造です。
逆の "Fat Harness" は、例外処理やバリデーションをすべてハーネス側に書き込んだ設計です。書けば書くほど「ここを変えるとあそこが壊れる」が積み重なります。
Self-healing という概念
もうひとつのキーワードが Self-healing（自己修復）です。
**Self-healing とは「エージェントが実行時のエラーや不足に遭遇したとき、ハーネス自体を書き足す能力」**です。事前にすべてを予測して詰め込むのではなく、実際に失敗した場所からハーネスを育てていく発想です。
これが成立しやすくなった背景として、技術的な変化が 3 つあります。
モデルの信頼性向上
ツールスキーマへの準拠精度が上がった。以前は「指定した形式で返ってこない」ケースが多く、ハーネス側で補正ロジックが必要だったが、近年のモデルではかなり改善されている。
コンテキストウィンドウの拡大
100 万トークン規模になり、事前のチャンク分割が不要になりつつある。長いスキルファイルやコードベースをまるごと渡せるようになったことで、エージェントが文脈を持ったまま判断できる範囲が広がった。
自己修正能力の向上
エージェント自身がエラー処理を生成できるケースが増えた。失敗を検知して「じゃあこう直す」を自律的に回せるようになりつつある。
ただし、注意点も明記されています。timakin 氏は「予測しない設計が万能ではない」と書いており、決済・削除など取り返しのつかない操作には明示的な承認フローを残すべきだと指摘しています。Self-healing を過信して、壊れてはいけない処理まで「何とかしてくれるでしょ」にしてしまうのは危険です。
自分のパイプラインで当てはめてみると
このブログの自動化パイプラインはいくつかのサブエージェントで構成されていて、ニュース収集・記事企画・執筆・デザイン・レビューと順番に処理を回しています。エージェントを増やしていくうちに、気づかないままハーネス側が厚くなっていた、という問題が積み重なっていました。
たとえば、各エージェントへの指示ファイルに例外ケースをどんどん追記し、エラー時の継続ルールもすべて中央のオーケストレータに集中させていきました。これは「失敗パターンを積み重ねてルールを育てる」実践ではあるのですが、Thin という方向性からは明確に遠ざかっていました。
Thin に近い設計: エージェントはスキルファイルを読んで自分で判断する。オーケストレータは「誰に何を任せるか」だけを持つ。例外は各エージェントが自己解決する。
今の設計（Fat 寄り）: オーケストレータに「A が失敗したら B に継続、ただし C の場合は止まる」のようなロジックが集中している。スキルとハーネスの境界が曖昧。
Self-healing に完全に任せると、おかしな状態のまま処理が進んでも検知が遅れます。観察性（何がどう動いているかを人間が把握できること）を保つためには、ある程度の厚さは必要という判断です。
"Ratchet Principle" という補助線
timakin 氏の記事で紹介されている概念で、「Ratchet Principle（ラチェット原則）」というものがあります。ラチェットとは一方向にしか回らない歯車で、「実際に失敗した場所からのみハーネスを厚くする」という原則です。
予測で先に詰め込まない。実際に転んだ場所に柵を立てる。
これは Thin を維持しながら Self-healing 的に育てていくバランス感覚として、個人開発の規模感にもしっくり来る考え方でした。「全部を守ろうとして最初から厚くする」のではなく、「実際に壊れた実績がある場所だけを固める」という割り切りです。
CLAUDE.md にルールを書き足す判断も、「1 回それで失敗した」という実績を前提にする。逆に、失敗していないケースへの事前対応は後回しにする。この粒度でルールファイルを育てると、ファイルが肥大化せず、かつ「なぜこのルールがあるか」の文脈も残りやすいです。
個人開発者が意識しておくこと
Thin Harness と Self-healing の話を受けて、個人開発で小さなパイプラインを組む際に意識したいポイントをまとめます。
ハーネスの厚さを定期的に確認する。 エージェントを増やしたタイミングで、オーケストレータ側に例外ロジックが積み上がっていないか見直すと、設計の歪みを早めに拾えます。
スキルと制御を別レイヤーにする。 「何を知っているか（スキル）」と「どの順番で呼び出すか（ハーネス）」を意識的に分けておけば、片方を変えてももう片方への影響を抑えやすい。
Self-healing の範囲を最初に決めておく。 やり直しが利くタスクと、絶対に止まってほしいタスクを事前に分けておくと、後から「任せすぎた」と悔やむ場面が確実に減ります。
最初に「焦りました」と書いたのは、パイプラインを育ててきた実感と照らして、Thin という発想の方向性が自分の設計とずれていたからです。全部を今すぐ Thin にする気はないし、観察性を捨てる気もない。ただ Ratchet Principle の「転んだ場所にだけ柵を立てる」は、そのままルールファイルの育て方に使える指針だと思っています。エージェントが増えるほど、この問いは避けて通れなくなります。
参考リンク