ハーネスとループ — AIに任せる範囲の設計
2026年に広まった「ハーネスエンジニアリング」「ループエンジニアリング」という言葉を、 自分の個人事業のタスク管理に持ち込むために噛み砕いた整理です。教科書的な定義の要約ではなく、 実際に運用してみて効いた順に並べ直した、自分用の解釈メモになります。
1行でいうと
AIが働く環境そのものを設計する。何を使えるか、何を見られるか、何ができないか。予防にあたる。
作らせて、採点して、不合格なら直させて、合格したら止める。検査にあたる。
両方が要ります。禁止できることはハーネスで潰し、やってみないと良し悪しが分からないことはループで捕まえる、という役割分担です。
どちらの問題かを見分ける
何か事故が起きたとき、どちらで直すかはこの2択で決められます。これが実務上いちばん使う判断です。
前者は「できないようにする」。後者は「採点役を置く」。混ぜて考えると、本来は環境で潰せる問題に対して延々と注意書きを増やすことになります。
ハーネス：ルールを構造に変える5段階
ハーネスは「良いルールを作ること」だと思われがちですが、要点はルールを覚えている必要がない状態に変換することです。同じ要求を、強さ違いで5通り実装してみます。
例題は「プログラムAを直してほしい。ただし関連するプログラムBには触らないでほしい」。
その場では効く。次のセッションには残らない。
毎回自動で読まれるので、言い忘れは無くなる。ただし「読んで、理解して、守る気になる」という3つの前提が要る。会話が長くなると他の指示に埋もれる。
段1までは「守るかどうかの判断」が残る。段2からは判断が発生しない
AIが書き込もうとしても、道具の側が拒否する。破ろうとしても破れない。
作業用の場所にAだけを置く。Bの存在を知らないので、触りようがない。
事前に防ぐのではなく、出口で必ず捕まえる。禁止しきれない場合の受け皿になる。
この「同じ要求を、より上の段に載せ替える」作業がハーネスエンジニアリングです。 ルールを増やすことではありません。
なぜ段1と段2のあいだが断層なのか
交通ルールで考えると分かりやすいと思っています。
| やり方 | 破られ方 | |
|---|---|---|
| 法律 | 「速度超過は禁止」と定める | 守るかどうかは運転者の判断に委ねられる |
| 設備 | 速度リミッターを付ける | 守る／守らないという選択が発生しない |
段1までが法律で、段2以降が設備です。そして、この差は自分の運用でも実測として出ました。
「作業前に一次情報と突き合わせて確認する」というルールは、常設ファイルに書いてありました（段1）。それでも、すでに完了していたタスクが約6週間にわたって「期限超過」と表示され続けていました。 法律は破られます。
一方、「未保存の変更が残っているとセッションを終了できない」という仕組みは、フックとして実装してあります（段4）。こちらは一度も破られていません。 破りようがないからです。
どこまで上げるかの判断
全部を段3にすると、作るのも使うのも重くなります。判断基準はシンプルです。
| 破られたときの被害 | 頻度 | どこまで上げるか |
|---|---|---|
| やり直せる | たまに | 段1で十分（書いておく） |
| やり直せる | 繰り返し起きている | 段2〜4へ上げる |
| 取り返しがつかない | 頻度を問わず | 最初から段2以上 |
判断材料は「もし破られたら、自分は何分で復旧できるか」です。復旧できないもの（本番データの破壊、公開してはいけない情報の流出）は、注意ではなく構造で止めます。
そして、一度破られたものは「頻度の証拠が出た」ということなので、その時点で上の段に上げる。 自分の場合、成果物が消える事故を起こしてから終了時のフックを入れました。順番としてはいつも後追いです。
ループ：主役は自律ではなく、採点役と停止条件
ループのほうは、誤解しやすい言葉だと感じています。「AIが自律的に自己修復する仕組み」と読みたくなりますが、力点はむしろ逆です。自律的に走らせること自体は難しくなく、難しいのは「いつ合格とするか」と「いつ人に上げるか」のほうでした。
設計する中身は3つです。
何をもって合格とするか。テストやスクリプトのような機械的な判定でも、別のAIによる判定でもよい。
いつ終わるか。止まらない自己修復は、生命ではなく無限ループで、費用だけが増える。
どこから先は自動で確定させず、人の判断に回すか。ここが曖昧だと安心して任せられない。
もう一つ、実際にやってみて効いたのは採点役を作り手と別に置くことでした。同じAIに自分の成果物を採点させると、自分の仕事を甘く通してしまう傾向があります。文章の下書きを作る工程では、作成役と確認役に別々のモデルを割り当て、確認役には安いモデルを使っています。
PMの言葉に置き換えると、ループエンジニアリングはPDCAの「C（検査）」を誰がどうやるかを設計し、合格の基準と止めどきまで先に決めておくことだと理解しています。
自分の環境では、こう対応している
| 区分 | 実装しているもの | 段／役割 |
|---|---|---|
| ハーネス | 常設の運用ルールファイル（毎セッション自動で読み込む） | 段1 |
| ハーネス | 起動時に情報源を自動同期するフック | 環境の初期化 |
| ハーネス | 未保存の変更が残るとターンを終了できないフック | 段4 |
| ハーネス | 創作プロジェクトの設定資料のうち一部を読み込ませない仕組み | 段3 |
| ハーネス | 定型手順を実行可能なコマンドとして用意（12本） | 道具立て |
| ハーネス | 提案はAI・承認は人・着手は検証ゲート通過後、という権限分離 | 権限設計 |
| ループ | 文章生成の3段階レビュー | 採点役 |
| ループ | 下書き生成の作成役／確認役のモデル分離 | 採点役の独立 |
| ループ | 設定資料の矛盾スキャン（自動修正はせず、根拠付きで3択を人に返す） | 人に上げる線 |
並べてみて分かったのは、これらを設計思想から作ったわけではないということでした。事故が起きるたびに一つずつ足していった結果が、後から名前のついた枠組みにおおむね一致していた、というのが実際の順序です。
まだ埋まっていないところ
文章の生産工程と創作の設定管理には採点役を置いていますが、タスク管理そのものの状態には検査役がいません。 「完了」と書かれた項目が本当に完了しているかを、機械的に確かめる仕組みがない状態です。冒頭で触れた「6週間気づかなかった」件も、この穴から出てきました。記法と実態の食い違いを検出するスクリプトを置くのが次の一手だと考えています。
結局どう使い分けているか
運用してみての実感は、順番があるということです。
まず取り返しのつかないことだけをハーネスで塞ぐ。次に、良し悪しが事前に決められない仕事にだけループを置く。この2つを済ませてから、残りは文書のルールで足りる、という順です。逆にやると、注意書きばかり増えて何も守られない状態になります。実際、最初はそうなっていました。
AIに任せる範囲を広げるために必要なのは、AIを信頼することではなく、信頼しなくても成立する範囲を先に作ることだと考えています。