ハーネス設計入門 〜プロンプト、コンテキストの次〜

AirCle＠AIコミュニティ開催の「ハーネス設計入門」で登壇した際に使用したスライド資料です。

Transcript

1. H AR N ESS ENG IN EERIN G ・ SEMINA R AIエージェント時代の ハーネス設計入門 第1部 系譜 ── 定義の揺れと収束 ／ 第2部 実践 ── 馬具・柵・ループで自走させる 今日のゴール ── 自分で直して完走するエージェントの設計を、持ち帰る 木下 雄一朗（Kinopee）｜ 株式会社キー・プランニング 代表取締役
2. A B OU T M E ／ 自 己 紹 介 AI×開発の現場に、書く側・使う側の両方から 氏名 木下 雄一朗（Kinopee） 所属 株式会社キー・プランニング 代表取締役 書籍 「AIを開発チームに採用する技術」（9月1日発売） 「AIエディタCursor完全ガイド」ほか多数 連載 Software Design 「プログラミング×AIの最前線」 アンバサダー Devin Ambassador Cursor Ambassador Regional Leader (East Asia) X https://x.com/kinopee_ai 02 / 35
3. P AR T 1 · HI S TO R Y & S C H OO L S 第1部 ハーネスエンジニアリングの系譜 — 5つの流派 ── 定義の揺れを現場感覚で読み解く — 収束・制度化・実証 ── 2026年、言葉はどこへ落ち着いたか 03 / 35
4. O V E R V IE W ハーネスエンジニアリングとは エージェントが失敗するたびに、同じ失敗が二度と起きないよう「環境側」を工学する営み AGENT = MODEL + HARNESS モデルは考える。指示ファイル・ツール・検証・ガードレール・ループ ── それ以外のすべてがハーネス。 PROMPT ENG. 2022– → CONTEXT ENG. 2024– → HARNESS ENG. 2026– 2026.02.05 Mitchell Hashimotoが命名 ──「失敗したら、二度と起きないよう環境を工学せよ」 2026.02.11 OpenAIが実践を公表 ── 3人で百万行・95%AI生成の "Harness engineering" 以降 各社・論者が追随 ── ただし定義の重心はバラバラ (→ 本資料で5つの流派に整理) モデルの賢さではなく、モデルの「外側」を工学する ── それがハーネスエンジニアリング 04 / 35
5. 5つの流派 同じ「ハーネス」を語っていても、論者が原器にしている実装で重心が違う 1 2 3 4 5 Chase派 Hashimoto派 Fowler派 Chawla派 Codex派 広義・分類論 運用哲学 制御理論 同心円モデル スケール駆動 代表者 代表者 代表者 代表者 代表者 Harrison Chase (LangChain) Mitchell Hashimoto Birgitta Böckeler (Thoughtworks) Avi Chawla (教育系) Ryan Lopopolo (OpenAI Codex) 中核主 張 中核主 張 中核主 張 中核主 張 中核主 張 モデル以外の すべてがハーネス 失敗したら環境を 再設計せよ コンテキスト設計の 特殊形として定義 LLMのOS層 三重の入れ子 スケールで壊れる 問題の答え 05 / 35
6. 1 C ON C E P T D I A G R AM Chase派 広義ハーネス / 分類論 H A R N E S S ツール オーケストレーション メモリ コンテキストビルダー ガードレール サブエージェント リトライ / 状態管理 MODEL (LLM) ── 唯一の「ハーネスでない」要素 「If you're not the model, you're the harness.」── モデル以外のすべてをハーネスとして囲い込む 06 / 35
7. 2 C ON C E P T D I A G R AM Hashimoto派 運用哲学 / 失敗駆動 1 実行 エージェントが タスクを試みる → 2 失敗 同じパターンで 繰り返し失敗 → 3 追記 → AGENTS.mdに 失敗防止ルールを 1行追加 4 再発不能 同じ失敗が 物理的に 起こせなくなる ↻ 新しいタスクで再開 ── 失敗知識が AGENTS.md に累積していく 失敗のたびに環境が強くなる ── ハーネスは「設計物」ではなく「育てていくもの」 07 / 35
8. 3 C ON C E P T D I A G R AM Fowler派 狭義ハーネス / 制御理論 自己修正フィードバック REQUEST ユーザー要求 → GUIDES ルール・制約 feedforward ── 事前制御 → AGENT LLM + ツール → SENSORS テスト・lint → OUTPUT 成果物 feedback ── 事後検証 guides (事前制御) × sensors (事後検証) の両輪でエージェントを信頼できる存在にする 08 / 35
9. 4 C ON C E P T D I A G R AM Chawla派 同心円モデル / OS比喩 コンピュータ LLMエージェント OS ⇔ ハーネス デバイスドライバ ⇔ ツール ディスク ⇔ 外部DB / メモリ RAM ⇔ コンテキスト CPU ⇔ LLM 「LLMはOSを持たない裸のCPUに過ぎない。ハーネスがOSの役割を担う」 09 / 35
10. 5 C ON C E P T D I A G R AM Codex派 スケール駆動 / プロダクション答え 3 engineers → 1M lines / 95% AI-generated (OpenAI Codex) HARNESS ENG. 2026– 自律・並列・本番 CONTEXT ENG. 2024– RAG / マルチターン PROMPT ENG. 2022– → → 単発プロンプト 「Agents aren't hard; the Harness is hard.」── スケール特有の故障モードを解くのがハーネス 10 / 35
11. 対立の構造 包含関係が逆転する ── 流派間のいちばん劇的な噛み合わなさ Chase派 / Chawla派 ハーネス ⊃ コンテキスト Fowler派 コンテキスト ⊃ ハーネス ハーネス (外層) コンテキスト設計 (外層) コンテキスト ハーネス (特殊形) プロンプト 総合フレーム設計の視点 ⇄ guides + sensors 制御理論 (feedforward / feedback) の視点 ── 2026年前半はこの対立が主戦場だった。以降、語彙は急速に収束していく (次頁) 11 / 35
12. A F T E R M AT H ・ C ON V E R G E N C E その後 ── 語彙の収束と制度化 2026年3月以降、定義の揺れは実装と標準化によって畳まれていった 03.10 LangChain「The Anatomy of an Agent Harness」── 構成要素の共通理解が形成される 04.19 Addy Osmani「Harness Engineering」──「ハーネスはモデル同士より互いに似てきている」 06.02 Build 2026でMicrosoft Agent Frameworkの「Agent Harness」が安定版に (のちGA) 06.23 Pydantic v2.0.0 ── ハーネス概念を中心に据えた破壊的リニューアル 2026 Linux FoundationがAgentic AI Foundationを設立 ── MCP・AGENTS.md・Gooseの寄贈が土台 2026 「Agent Plugins」1.0 ── Skills・MCPを可搬パッケージ化する中立標準 (Cursor・OpenAI・MS他) 08.13 DeepSeekがハーネスを公開 ── 2日で約9.5万GitHubスター 語彙は約5か月で収束 ──「5流派の対立」は2026年前半の過渡的現象だった 12 / 35
13. S T A N D A R D IZ AT I ON ・ 2 0 2 6 . 0 8 . 0 6 Agent Plugins 1.0 ── ハーネス部品の可搬標準 Skills・MCPサーバーを1つのフォルダ形式に ── 対応クライアントが同じ構造で発見・読込できる なぜ必要になったか 現状の課題 B E F O R E ── リ ポジ トリ が汚 れ てい く ▪ ルールファイルすら統一できず ── CLAUDE.md / AGENTS.md / .cursorrules / copilot-instructions.md が併存 (symlinkでしのぐ現場も) ▪ SkillsやMCP設定は .claude/ .cursor/ .codex/ .github/ とツー ル別の隠しフォルダへ ── Nツール分のドットフォルダと重複 管理 ↓ ▪ 署名・審査・権限・シークレットは仕様外 (future work) ── 信頼境界は依然として利用側の仕事 ▪ 可搬なのはSkillsとMCPのみ ── hooks・コマンド・rules 等は拡張名前空間行きで、使い込むほどクライアント固有 に戻る ▪ 対応は増分的 ──「どこでも動く」は保証されず、クライ アント別の対応表の確認が前提 ▪ Skills・MCPの出自であるAnthropicは、TSC・初期対応ク ライアントの一覧に不在 A F T ER plugin.json ＋ skills/ ＋ mcp.json の1形式に集約。配布・権限 ・UXは各クライアント側に残す「最小の床」 Vercel発案、AWS・Cursor・GitHub・MS・OpenAI共同策定 箱は共通化された。審査・権限・配布は各自の仕事 ── 標準は「床」であって「守り」ではない 13 / 35
14. EVID EN C E ・ N EXT Q U ESTION 実証と、次の論点 ハーネスの効果は数字で語れるようになった ── そして新しい反論も現れた TE R M IN AL B E NC H 2. 0 B EN C H M A R K V A R I A N C E Q U A L I T Y P O S T M O R T EM 30位 → トップ5 ±5pt 以上 3件 / 3件 モデル据え置き、ハーネスの変更のみで順 位を更新 (LangChain) ハーネス設定だけでスコアが変動 (Anthropic 2026 Agentic Coding Trends Report) Claude Code品質低下の原因は、すべてハー ネス層の変更だった (2026.04) 反論 も登場 「ハーネスは隠れた技術的負債。その大半は、次世代モデルに溶けて消える」 ── Han Lee 定義論争は終わった ── 次の問いは「どこまで作り込み、どこからモデルに任せるか」 14 / 35
15. PART 2 · PRACTI CE 第2部 ハーネス設計の実践 — ハーネスエンジニアリング ── AI エージェントを自走させる設計技法 — ハーネス・ガードレール・フィードバックループの全体像と、設計の勘所
16. A GE ND A 第2部の流れとゴール ゴール エージェントが自分で失敗に気づき、自分で直して完走する ── その仕組みの設計を、持ち帰れるよう になる。 1 2 3 ハーネスを作る ガードレールを張る ループを閉じる 「どう走ってほしいか」をエージェン トに伝える層。AGENTS.md・Skills・ サブエージェントで構成する。 逸脱を機械が見つける層。lint・型チェ ック・テストを導入し、「1コマンドの 門」に束ねる。 失敗をそのまま渡して、通るまで直さ せる ── エージェント自走の完成形。 進め方 概念 → 道具 → 設計の順に進みます。質問は随時どうぞ。 ハーネス設計入門 16 / 35
17. PR EMI SE ・ PR OB A B I LIST IC 前提 ── 生成AIは、確率で動く 同じ指示でも、出力は毎回同じとは限りません。これが動作原理です（図中の数字は説明用のイメージ）。 ① 1トークンごとに、確率で選ぶ ② 小さな揺らぎ × 数千トークン 「テストを ___ 」の次に来る語の分布： 動くコード A 書く 54% 実行する 28% スキップする 11% （その他） 7% ── 低確率の「悪い一手」も、ゼロではない 従来のプログラム：同じ入力 → 同じ出力（決定的） 同じ指示 動くコード B（別解） 逸脱（危険な一手） ── どの経路になるかは、実行のたびに変わる 生成AI：同じ入力 → 分布からのサンプル（確率的） 揺らぎは仕様 ── だから「指示して祈る」ではなく、環境と検証で受け止める（次頁） ハーネス設計入門 17 / 35
18. FOU N DA TIO N ハーネスとガードレール ── 役割の違う2つの仕組み AIコーディングの土台。普段使っている個々の機能は、すべてこの2つのどちらかに属します。 H AR N ES S GU A RD RA IL S ハーネス ＝ 馬具 ガードレール ＝ 道を外れないための 柵 走り出す前に「どう走ってほしいか」を伝える、事前設 計の層。 走った後に「逸脱していないか」を機械で自動検証する 、事後検証の層。 • ルール（カスタムインストラクション / AGENTS.md） • プラン（着手前の計画合意） • Skills（再利用可能な手順書） • サブエージェント（役割分担と委任） • 静的解析（lint・フォーマット・型チェック） • ビルド • テスト（ユニット / 結合 / E2E） ハーネスは主観、ガードレールは客観。 機械的な判定が強いほど、エージェントにハンドルを預けられる。 ハーネス設計入門 18 / 35
19. H AR N ES S I N DE TA IL ハーネス ── 走り出す前に伝える、事前設計の層 役割 走り出す前に「どう走ってほしいか」を伝える。プロジェクトの前提・規 約・手順・禁止事項を、エージェントが参照できる形で明文化しておく。 性質 内容は人間の判断で決める「主観」の層。書いた分だけ効くが、書きすぎ ればコンテキストを圧迫する。取捨選択そのものが設計。 馬具 (bridle & reins) ── 手綱で進路を伝える ハーネス設計入門 「ハーネスエンジニアリング」の定義にはまだ諸説ある。ただ日本の現 場は、名前がつく前から同じことをやっていた ── 定義より、事前に 伝える設計そのものが本体。 19 / 35
20. GU A RD RA IL S IN D ETA IL ガードレール ── 走った後に検証する、事後検証の層 役割 走った後に「道から外れていないか」を機械で自動検証する。人間の目視 ではなく、lint・型・ビルド・テストが Yes / No を返す。 性質 誰が実行しても同じ結果を返す「客観」の層。判定が機械的であるほど、 エージェントは自分で失敗に気づき、自分で直せる。 防護柵 (guardrails) ── 道の両脇で逸脱を止める ハーネスは主観、ガードレールは客観。機械的な判定が強いほど、エージェント にハンドルを預けられる ── 自律性を上げる鍵はここ。 ハーネス設計入門 20 / 35
21. FE E DB AC K LOO P フィードバック・ループ ── 馬具と柵だけでは、たどり着けない 1 走らせる エージェントに タスクをやらせる 2 逸脱を観察 期待からのズレを 機械が検知する 3 軌道を戻す ↻ 通るまで繰り返す 失敗を受けて 修正・再実行 具体的には テストが落ちたら lint が出たら 型が通らなければ → 直させる → 修正させる → やり直させる ── 判定結果をそのまま次の指示として返し、完了条件「門がすべて緑」まで回す。これがループの正体 言葉の定義に拘るよりも、馬具も柵もループも、今使える手段を全部使って結果を出しに行く。 ハーネス設計入門 21 / 35
22. H AR N ES S TO OLB OX ハーネスの道具箱 ── 適用範囲で使い分ける 同じ「事前に伝える」でも、効く範囲と深さが違う4つの道具。左から右へ、適用範囲が狭く・深くなります。 ルール 適用: 常時 プラン 適用: タスク単位 Skills 適用: 必要なとき サブエージェント 適用: 役割単位 AGENTS.md / Cursor Rules。 毎回のセッションに自動で入 る、プロジェクトの憲法。薄 く・広く効く。 着手前に計画を出させ、人間 が合意してから実行する。 Day1 で使った Plan モードが これ。 特定作業の手順書。必要な場 面でだけ読み込まれるため、 常時のコンテキストを圧迫し ない。 専用のプロンプトを与えられ た専門家。調査・実装・レビ ューなど役割ごとに委任し、 独立した文脈で動く。 規約・コマンド・禁止事項 認識合わせと手戻り防止 定型作業の再現性 並列化と文脈の分離 第一歩はルール（AGENTS.md）。 常時効く土台をまず固め、Skills・サブエージェントはその上に積む。 ハーネス設計入門 22 / 35
23. W RI TIN G RU LE S 1/2 AGENTS.md / Rules ── 何を書き、何を書かないか ルールはコンテキストの一部として毎回読み込まれます。1行ごとに「家賃」がかかる ── 取捨選択が設計です。 ◎ 書くこと ✕ 書かないこと • プロジェクト概要（1段落で） • 一般常識・言語の一般的な作法 何のための何か。目的がわかると判断が揃う モデルはすでに知っている。書くだけ無駄 • コマンド（ビルド・テスト・lint） • コードを読めばわかること エージェントが自分で検証できるようになる 実装と二重管理になり、すぐ嘘をつき始める • プロジェクト固有の規約・構成 • 長大な設計書の貼り付け 命名・ディレクトリ・エラー処理の流儀 常時読むには重い。Skills や参照リンクへ • してはいけないこと • 守れているか検証できない精神論 触ってはいけないファイル、変更禁止のAPI 「きれいに書く」ではなく機械判定に落とす 目安 まずは50行程度に収める。足りない分は、運用の中で「逸脱が出たら1行足す」方式で育てる。 ハーネス設計入門 23 / 35
24. W RI TIN G RU LE S 2/2 効くルールの4原則 書き方ひとつで、同じ内容でも効き方が変わります。「良いタスク指示」と原理は同じです。 1 簡潔に、構造的に 2 検証可能な表現にする 3 実例を1つ添える 4 失敗から育てる 見出しと箇条書きで短く。長文の物語はコンテキストを圧迫し、肝心の行が 埋もれる。 「きれいに」ではなく「関数は50行以内」「命名は camelCase」。機械判定 に落とせる表現ほど強い。 規約は「良い例」を1つ見せるのが最速。src/ の模範ファイルを指し示すだ けでも効く。 最初から完璧を狙わない。逸脱が起きるたびに1行追記 ── 運用こそがハー ネスエンジニアリング。 コツ 下書きはAIに作らせてよい。「このリポジトリを分析して AGENTS.md の草案を書いて」→ 人間が削って締める、が最速。 ハーネス設計入門 24 / 35
25. S KI LLS Skills ── 必要なときだけ読む手順書 ルールに全部書くとコンテキストが溢れる。定型作業は Skill に切り出し、必要な場面でだけ読ませます。 棲み分けの考え方 SKILL.md の基本形 ルール # エンドポイント追加 ## 使いどころ REST APIに新しいルートを足すとき ## 手順 1. routes/ にルート定義を追加 2. handlers/ に処理を実装 3. バリデーションを schemas/ に定義 4. テストを __tests__/ に追加 5. docs/api.md を更新 ## 模範例 routes/health.ts を参照 常時読み込み 薄く広く ── 全タスク共通の前提 Skills 必要なとき読む 深く狭く ── 特定作業の完全な手順 サブエージェント 別の文脈で並列 調査・実装・レビューを役割分担 判断基準：毎回必要なら「ルール」、特定作業でだけ必要なら 「Skill」。迷ったら Skill に逃がす。 /create-skill から対話的に生成 ── 出来上がりがこの形になっていれば OK ハーネス設計入門 25 / 35
26. S UB A GE NTS サブエージェント ── 2つの呼び出し方 親の文脈を汚さず、役割を分けて委任する仕組み。「その場で作る」と「定義して呼ぶ」の2系統を使い分けます。 A ── オンデマンド生成 B ── 事前定義して呼び出す 親エージェントが、必要になった瞬間に子を起こして仕 事を振る。使い捨ての委任。 役割・観点・出力形式をファイルに定義しておき、名前 で呼ぶ。育てて共有する委任。 向く場面 向く場面 大量の調査・比較の並列化 ／ コンテキストを大きく消費す る探索 ／ 結果の要約だけ持ち帰りたいとき 毎回同じ観点で行う作業 ── レビュー専門・セキュリティ 監査・テスト専門など。チームで観点を共有したいとき 「3つのライブラリを、それぞれ別のサブエージェントで並列 に調査して要点だけ報告して」 レビュー専門エージェント：「差分を 規約・セキュリティ・ テスト網羅 の3観点で指摘」 並列の効能と代償 非同期で並行に走らせれば、待ち時間は大きく短縮できる ── 反面、同時に走る数だけ時間当たりのトークン 消費は増える。数と深さは費用対効果で。 共通する本質は「文脈の分離」。 そして子には子のハーネスが効く ── 定義ファイルは、サブエージェントの AGENTS.md。 ハーネス設計入門 26 / 35
27. E X AMP LE S そのまま使える実例 ── Skill とサブエージェント 自分の現場に近いものを選んで写経からで構いません。名前と観点を自分のプロジェクトに合わせて調整してください。 Skill の実例（手順書） サブエージェントの実例（事前定義） リリースノート作成 code-reviewer git log を分類して CHANGELOG.md に追記。前提のコミット粒度 ・メッセージ規約も AGENTS.md へ コミット前に差分を「規約・セキュリティ・テスト網羅」の3観点 でレビューさせる 画面（エンドポイント）追加 refactorer ルーティング→実装→バリデーション→テスト→docs の5点セット （例：ユーザー一覧 API の追加） 重複・肥大化した関数・命名のゆらぎを検出し、振る舞いを変えな い改善案を出す専門役 バグ調査 test-designer 再現手順の確定 → ログ収集 → 原因仮説 → 最小修正 → 再発防止テ ストの調査手順書 仕様や差分から、境界値・異常系のテストケース一覧を設計させて から実装に渡す 動かし方 「作って終わり」にしない。実タスクで繰り返し呼び出し、効かなかった指示を1行ずつ直す ── ハーネスは運用で育 つ。 ハーネス設計入門 27 / 35
28. GU A RD RA IL S TOOLB OX ガードレールの階層 ── 右へ行くほど判定が強い どれも「機械が Yes / No を返す」仕組み。検証する対象が、表記 → 整合性 → 振る舞い へと深くなります。 フォーマッタ リンター 型チェック ビルド テスト 表記の統一 作法の検査 整合性の検証 成立の確認 振る舞いの保証 Prettier / gofmt など。議 論の余地なく自動修正 ESLint / Clippy など。バ グの芽と規約違反を静的 に検出 tsc / mypy など。データ の流れの矛盾を実行前に 検出 そもそも成果物として成 り立つかの最低ライン 仕様どおり動くか。逸脱 検知の最後の砦 機械的な判定の強さ・検証の深さ 配線に注意 エディタの赤線は言語サーバ／拡張機能の仕事で、エージェントには見えない。柵として機能するのは、エージェント自身が実行し て出力を読めるコマンド（npm run lint 等）── 配線は別物。 原則 ガードレールが強いほど、エージェントは自分の失敗に自分で気づける ── つまり任せられる範囲が広がる。 ハーネス設計入門 28 / 35
29. ON E GA TE 「1コマンドの門」を作る ── check に束ねる バラバラに走らせるのではなく、1コマンドですべての柵を通す。人間もAIも、同じ門をくぐらせます。 package.json（例） "scripts": { "format": "prettier --check .", "lint": "eslint src/", "types": "test": 1 「私の環境では動く」を排除。判定基準が一本化される 2 "tsc --noEmit", "vitest run", "check": "npm run format && npm run lint && npm run types && npm run test" 人もAIも同じ門をくぐる AGENTS.md に登録して完了基準に 「check が通ること」＝タスク完了の定義。曖昧さが消え る 3 CI にも同じ門を置く } 手元をすり抜けても push 後に必ず捕まる ── 二重の柵 段階導入のすすめ 既存プロジェクトでは、いきなり全ルールを厳格化しない。フォーマッタ → lint（警告から）→ 型 → テスト の順に、通せる柵から立てていく。 ハーネス設計入門 29 / 35
30. TW O KI ND S OF GU AR DR A ILS 柵は2種類ある ── 成果物への柵と、行動への柵 ここまでの柵はすべて「書いたもの」を検証する柵。もう1種類、「これからやること」を止める柵があります。 成果物への柵 行動への柵 書いたものを、事後に検証する 危険な実行を、事前にブロックする • lint・型チェック・ビルド・テスト 判定の対象はコード。npm run check に束ねた • 問うこと：「正しく作れたか」 失敗はループの入力になる（フィードバックループ） 主戦場はこちら ── 最初に作り込む対象 • Hooks・許可リスト・サンドボックス /create-hook で作成 ── beforeShellExecution で rm や外部送信 を止める等 • 問うこと：「実行してよいか」 判定の対象は行為 ── 起きる前に止めるしかない事故用 → 次ページで詳説 共通の原理 どちらも「人間の注意力ではなく、機械が止める」。テストが落ちたコードをマージできないのと、危険なコマンド を実行できないのは、同じ柵の2つの顔。 ハーネス設計入門 30 / 35
31. SEC U R ITY ハーネスとセキュリティ ── 委ねるほど、柵は防具になる 自律性を上げるほど、エージェントは「攻撃されうる実行主体」になります。代表的なリスクは4つ。 1 間接プロンプトインジェクション 2 秘密情報の漏洩 Web・Issue・READMEなど、エージェントが読む外部コンテンツ に悪意ある指示が紛れ込む。モデルは「読んだ指示」と「あなた の指示」を区別できない。 .env・認証情報・顧客データがコンテキストや外部送信に載る。 「読ませない」(deny設定・アクセス制限) を、規約より先に構造 で。 3 4 破壊的操作 rm・force push・本番環境への直接操作。許可リスト＋確認ゲー ト＋サンドボックスで、物理的に実行不能にしておく。 サプライチェーン エージェントが提案する依存パッケージの実在・正当性は保証さ れない (幻覚パッケージ・typosquatting)。導入は人間の門を通す 。 危険が最大化する条件 秘密データへのアクセス × 不審コンテンツの読み取り × 外部への送信 ── この3つを同時に 許さない (通称 lethal trifecta)。どれか1つを構造で断てば、致命傷にはならない。 守りも構造で ── 行動への柵 × 隔離（クラウドエージェント）× 信頼境界（審査済みSkill・Pluginのみ許可） ハーネス設計入門 31 / 35
32. H ID D E N T E C H NI C A L DE B T ハーネスは、隠れた技術的負債 「作り込むほど良い」への反論 ── 2026年後半の新しい論点。作り込んだハーネスにも、寿命があります。 「良いチームほど、多くのハーネスを作り込んでいる。苦いのは、そのほぼすべてが次世代モデルに溶け ていくことだ」 ── Han Lee (2026) モデルのリリースごとに、誰かが誇っていた回避策の山が引退していく 現行モデル世代 回避策 作り込み ハーネス (中核) MODEL 次世代モデル モデル更新 → 回避策 作り込み ハーネス (中核) 溶けて消える (モデルに吸収) ← 残る MODEL (賢く・大きく) 作り込みすら、いずれ溶ける ── ある時点の形に固執せず、薄く・軽く保ち、定期的に棚卸す。 ハーネス設計入門 32 / 35
33. O RD E R OF W O RK ハーネスエンジニアリング ── やるべき順序 何から手をつけるか。逆順にやると、効かないルールと使われない道具が積み上がります。 1 2 3 4 5 6 素の状態を観察する ハーネスなしで一度走らせ、逸脱を記録する。書くべきルールの種は、ここにある。 ルールを書く（AGENTS.md） まず50行程度から。全行が実際の失敗・規約に対応 ── AIに草案を書かせ、人間が削る。 柵を立て、「1コマンドの門」に束ねる lint・型・テストを check に。人もAIも同じ門をくぐる。行動への柵もここで。 ループを閉じる 失敗の出力を次の入力に、完了条件「門がすべて緑」まで回す。手動 → フック → テスト と自動化。 道具を増やす ── 繰り返しが見えてから 繰り返す手順はSkillsへ、繰り返す観点はサブエージェントへ昇格。ルールが先、道具は後。 運用で育てる ── 足すだけでなく、棚卸す 逸脱が出たら1行追記。数か月に一度は全削除し、要るものだけ戻す棚卸しを (Git管理で安全に試せる)。 順序が大事 ── 観察より先にルールを書かない。ルールより先に道具を増やさない。 ハーネス設計入門 33 / 35
34. C ON CLU S ION まとめ ── ハーネスエンジニアリング 3原則 1. 進路はハーネスで示す 2. 逸脱はガードレールで検知 3. ループを閉じて自走させる 規約・コマンド・禁止事項を明文化し 、逸脱が出るたびに1行育てる。書いて 終わりではなく、運用が本体。 lint・型・テストを「1コマンドの門」 に束ね、人もAIも同じ門をくぐる。判 定は主観でなく機械に。 失敗の出力をそのまま次の入力に。手 動 → フック → テストと自動化を進め るほど、任せられる範囲が広がる。 言葉の定義は、重要ではない。大切なのは、期待した結果を得ること。 ハーネス設計入門 34 / 35
35. Q& A ご清聴ありがとうございました お気軽にご質問ください。 X 書籍・連載 コミュニティ @kinopee_ai （https://x.com/kinopee_ai） 「AIを開発チームに採用する技術」9月1日発売 → Software Design「プログラミング×AIの最前線」 AIAU（AIエージェントユーザー会） 木下 雄一朗（Kinopee）｜ 株式会社キー・プランニング 35 / 35