Speaker Deck（木下雄一朗（Kinopee）氏・株式会社キー・プランニング／全30枚）
2026年のAIエージェント開発のキーワードとなった「ハーネスエンジニアリング」を、系譜から実践まで一気通貫で解説する入門スライド。登壇者の木下雄一朗（Kinopee）氏は『AIを開発チームに採用する技術』『AIエディタCursor完全ガイド』の著者で、Software Design連載「プログラミング×AIの最前線」でも知られます。
時代の流れは プロンプトエンジニアリング（2022〜）→ コンテキストエンジニアリング（2024〜）→ ハーネスエンジニアリング（2026〜）。2026年2月5日にMitchell Hashimoto氏が命名（「失敗したら、二度と起きないよう環境を直す」）、同年2月11日にOpenAIが実践例を公開（3人で100万行、95%をAIが生成）し、各社・論者が追随しました。
同じ「ハーネス」でも、論者が手本にした実装によって意味の範囲が異なりました。
| 1. Chase派 | Harrison Chase（LangChain）／広義・分類論／「モデル以外のすべてがハーネス」 |
|---|---|
| 2. Hashimoto派 | Mitchell Hashimoto／運用哲学／「失敗したら環境を再設計せよ」 |
| 3. Fowler派 | Birgitta Böckeler（Thoughtworks）／制御理論／「コンテキスト設計の特殊形として定義」 |
| 4. Chawla派 | Avi Chawla（教育系）／同心円モデル／「LLMのOS層・三重の入れ子」 |
| 5. Codex派 | Ryan Lopopolo（OpenAI Codex）／スケール駆動／「スケールで壊れる問題の答え」 |
対立の構造は「どちらが外側か」。Chase派・Chawla派は ハーネス ⊃ コンテキスト（総合フレーム設計の視点）、Fowler派は コンテキスト ⊃ ハーネス（フィードフォワード／フィードバックの制御理論の視点）と、包含関係が逆になっていたことが2026年前半の議論の中心でした。
Skills・MCPサーバーを1つのフォルダ形式（plugin.json ＋ skills/ ＋ mcp.json）に統一。Vercel発案でAmazon・Cursor・GitHub・Microsoft・OpenAIが策定しGoogleも参加。ChatGPT・Codex・Cursor・GitHub Copilot・Kiro・VS Codeが対応し、一度作れば複数クライアントで使えるようになりました。
ただし互換性は一部で、Claude Codeは独自形式のまま未対応、Skills/MCPの片方だけ対応のクライアントもあり、hooks・コマンド・rulesは対象外。
ゴールは「エージェントが自分で失敗に気づき、自分で直して完走する」仕組みの設計。前提として、生成AIはトークンごとに確率で出力を選ぶため、同じ指示でも出力は毎回同じとは限りません。低確率の「悪い一手」もゼロではない — だから指示だけに頼らず、環境と検証で受け止める設計が必要です。
| ハーネス＝馬具 | 走り出す前に「どう走ってほしいか」を伝える事前設計の層。人間の判断で決める「主観」。ルール（AGENTS.md）・Skills・サブエージェント。自然言語で伝える「意図」なので効き目は絶対ではない |
|---|---|
| ガードレール＝柵 | 走った後に「逸脱していないか」を機械的に検証する事後検証の層。誰が実行しても同じ「客観」。lint・型チェック・ビルド・テスト・Hooks |
checkを自分で実行し、結果を読む人が用意するものは検証器＝門（checkの1コマンド）とゴール＝checkがすべて通ること。タスク固有の条件もテストにしてcheckに入れれば、「checkがすべて通る」だけで完了を判定できます。
| ルール | 適用：常時。AGENTS.mdは主要ツールが読む事実上の共通形式。毎回のセッションに自動で入り、薄く広く効く |
|---|---|
| Skills | 適用：必要なとき。特定作業の手順書。必要な場面でだけ読み込まれ、常時のコンテキストを圧迫しない |
| サブエージェント | 適用：役割単位。専用プロンプトを与えられた専門家。調査・実装・レビューなど役割ごとに委任し、独立した文脈で動く |
第一歩はルール（AGENTS.md）。常時効く土台を固めてから、Skills・サブエージェントをその上に積みます。
ルールは毎回コンテキストに読み込まれるので、1行ごとに「家賃」がかかります。
目安は「全行が実際の失敗や規約に対応していること」。逸脱が出たら1行足して育てる。なおClaude CodeはCLAUDE.mdがあればそちらを優先し、なければAGENTS.mdを読みます（v2.1.277以降）。
# エンドポイント追加 ## 使いどころ REST APIに新しいルートを足すとき ## 手順 1. routes/ にルート定義を追加 2. handlers/ に処理を実装 3. バリデーションを schemas/ に定義 4. テストを __tests__/ に追加 5. docs/api.md を更新 ## 模範例 routes/health.ts を参照
判断基準：毎回必要ならルールへ、特定作業でだけ必要ならSkillへ。迷ったらSkillに逃がす。/create-skillで対話的に生成可能。
共通するのは「文脈の分離」。子にも子のハーネスが効きます。並列化で待ち時間は大きく減らせるが、同時実行数だけトークン消費は増えるため、費用対効果で決める。
判定の強さは フォーマッタ（表記の統一）→ リンター（作法の検査）→ 型チェック（整合性の検証）→ ビルド（成立の確認）→ テスト（振る舞いの保証） の順に深くなります。この5つをcheckの1コマンドに束ね、人もAIも同じ門をくぐるのがポイント。
柵を自動で走らせる「レール」は3本：
| クライアント内（エージェントのHooks） | 編集・実行の瞬間。afterFileEditでlint、beforeShellExecutionでrmを止める。最速だが無効化可能 |
|---|---|
| リポジトリ（Git hooks） | コミット・push時。Husky・lefthookでcheckを実行。--no-verifyで抜けられる、強制力は中 |
| リモート（CI） | PR作成・更新時。同じcheckをパイプラインで実行し、ブランチ保護で失敗時マージ不可。抜けられない、強制力最大 |
原則：内側で速く気づき、外側で確実に止める。近い・速い・弱い ⟷ 遠い・遅い・強い。
| 1. 馬具：方向 | 走る前に「どう走るか」を与える（AGENTS.md・Skills） |
|---|---|
| 2. 柵：判定 | 道から外れていないか機械的に検証（lint・型・テスト・Hooks）。結果はエージェントが読んで直す |
| 3. 境界：可動域 | 触れる範囲を決める。外へ通じる道がない。隔離・遮断・最小権限（コンテナ／サンドボックス・通信遮断） |
自律性を上げるほど、エージェント自体が攻撃の入口になります。守るべきは4点：間接プロンプトインジェクション／機密・個人情報の漏洩／破壊的操作（rm・force push）／サプライチェーン（提案された依存パッケージは人が確認）。
危険が最大化する条件は Simon Willison のいう lethal trifecta：「機密データへのアクセス × 不審コンテンツの読み取り × 外部への送信」の3つを同時に許さないこと。守りも仕組みで作る：行動への柵 × 隔離（サンドボックス）× 信頼境界（審査済みSkill・Pluginのみ）。
コスト方程式は「ユーザー数 × セッション/ユーザー × ターン/セッション × リクエスト/ターン × トークン/リクエスト × 単価/トークン」の6項の掛け算。Uberは2026年2月→8月で利用者7倍・リクエスト9.4倍を達成しながら総コストは横ばい。中央の3項を減らすのがハーネスの仕事で、1000リクエストあたり−34%、1セッションあたり−52%。いちばん効いた手はサブエージェントを安いモデルにすること（方程式の右端「単価」）でした。
現行モデルの弱点を補う注意書きや細かい手順・独自リトライは、モデル更新で溶けて消えます。残る中核はテスト（check）・権限と境界・プロジェクト固有の規約。ある時点の形に固執せず、薄く軽く保ち、定期的に棚卸しする。