Agent = Model + Harness
AI エージェントを実際に運用すると、モデルを賢いものに替えても期待ほど安定しない、という壁にぶつかります。同じモデルでも、設定の仕方しだいで「指示を守る確率」が大きく変わるからです。この差を生んでいるのがハーネスです。
中核の等式
このガイドが下敷きにしている考え方を 1 行で書くと、こうなります。
Agent = Model + Harness
エージェント（実際に仕事をこなす存在）は、モデル単体ではなく、モデルとハーネスの組み合わせで決まる、という意味です。ここでいうハーネスとは、モデルの周りを固める仕掛けの総称で、具体的には次のようなものを指します。
- rules — 守ってほしい規範（命名規約、検証の手順、禁止事項）
- skills —
/debugのような、手順がパッケージ化されたコマンド - agents — レビューやリファクタを担当する専門の subagent
- hooks — 特定のタイミングで自動実行されるスクリプト
- MCP — 外部ドキュメントや構造化推論を呼び出すツール群
- memory — セッションをまたいで学びを残す仕組み
- verification loop — 出力を検証してから完了とみなすループ（
/debugの Verify で実際にテストを走らせ、出力を「直った」証跡とする）
これらは「Claude Code が機構を提供し（📦）、中身を使い手が書く（🔧）」という分担で成り立っています（区分の詳細は凡例）。
モデルは「エンジン」、ハーネスは「車体」に当たります。どれだけ高出力のエンジンでも、ハンドル・ブレーキ・センサーがなければ公道はまともに走れません。エージェントの信頼性は、エンジンの馬力よりも、この車体の設計品質に強く依存します。
LLM は本質的に「直前のトークンの続きを確率的に予測するモデル」です。賢くはなっても、指示を 100% 守るわけではありません。「テストを実行してから完了と言う」「秘密情報をハードコードしない」といった約束も、確率的にすり抜けます。ハーネスは、この「確率的なすり抜け」を構造的に塞ぐための仕掛けです。
ハーネスがある場合・ない場合
同じ依頼を、ハーネスの有無で比べてみます。
依頼: 「この関数のバグを直して」
→ それらしい修正を出す
→ テストは実行しないことがある
→ 「直りました」と言うが、実は別の箇所が壊れている
→ 秘密鍵をうっかりコードに直書きしても気づかない
依頼: 「この関数のバグを直して」
→ /debug skill が起動し、仮説を立てて検証する手順に乗る
→ 常時ロード済みの rule（検証ファースト原則）が効いていて、テスト実行が促される
→ .env への書き込みは hook が事前にブロックする
→ 応答の最後に Stop hook が出力を点検し、平文での質問などをその場で言い直させる
（上記 2 つは思考実験としての例示で、筆者環境での実測ログではありません）
違いは「モデルが賢いかどうか」ではありません。良い振る舞いを期待するか、構造で強制するかの違いです。ハーネスエンジニアリングとは、後者を設計する営みを指します。
このガイドで「動き」を見る理由
ハーネスの各要素は、設定ファイルを眺めているだけでは関係が見えてきません。rules/ のファイル、hooks/ のスクリプト、MCP のツールが、それぞれ独立して置かれているからです。
ところが、1 つのコマンドを実行すると、これらが順番に発火して 1 つの流れを作ります。次章からは /debug を題材に、その発火の連鎖を時系列で追います。その前に、まず「どんな要素を、どう分類して捉えると見通しが良いか」を次の章で押さえます。
要点は次のとおりです。
- エージェントの信頼性は、モデルよりハーネスの設計で決まる（
Agent = Model + Harness） - LLM は確率的にしか指示を守らず、ハーネスがそれを構造で補う
- 個々の設定は静的だが、コマンド実行時に連鎖して 1 つのワークフローになる
次は Guides と Sensors の十字分類 で、ハーネスの要素を整理する枠組みを学びます。