非エンジニアのAI業務自動化（AIエンジニアリング4段）/止める所は、人が先に決める

AI活用のホゲホゲエンジニアリングについての第2弾です。
前回はコンテキストエンジニアリングについて書きました。

今回は、ハーネスエンジニアリングに関してです。

みなさん、AIに任せたら、頼んでいないところまで進んでいたコトってありますよね？

おいおい、誰がそこまでやれって言うた？やりすぎやし間違っとるし・・・

的なｗ

前回は、AIに何を読ませるかを決める話（コンテキスト）を書きました。ただ、読ませる範囲を決めても、AIの動きは止めていません。今回は、動く側を「適切に」止める関所（ハーネス）の話です。

ちなみに、ハーネスってのはもともとは「 馬を操るためのハミや手綱、馬車を引かせるための装具などの馬具全般を指す」そうです。

それが安全ベルトとかそういう意味で使われるようになった模様。

AIでいうと、安全ロックみたいなもんでしょうか。
セキュリティでいうとガードレールに当たるものに近いってイメージしてもらってもいいと思います（ちょっと拡大解釈ですが）

---

今回の最も重要なポイントを結論から申し上げます。

それは、

AIが先へ進む前に必ず止まる関所を作らせ、試験で動きを確かめると、入口の中では任せても勝手に進まなくなる
ということです。

勘違いしてはいけないのは、ハーネスつくったからって、全部安全ってわけじゃないです。入口の外は、まだ塞げていませんから。

この回の4点	内容
困っていたこと	承認も検査もレビューの合格も、次へ進む前に仕組みが読んでいなかった
人間が決めたこと	関門が読むもの、関門を置く場所、入口の外は塞がないこと
AI部下がやったこと	3つの止めを入れる、試験を書いて回す、届かない原因を調べる
結果	入口の中の止めは動いた。完了の報告と入口の外が残った

前回のおさらい

この連載では、AIの仕組みを4つの段（コンテキスト → ハーネス → ループ → グラフ）で見直しています。4段は標準ではなく、私が自分の仕組みを測るために決めた物差しです。今回は2つ目のハーネスを取り上げます。

ハーネスは、AIモデルの周りに道具・検証・記憶・ガードレール（越えてはいけない線）・観測を作る仕事です。式は「Agent = Model + Harness」で、Faros AIのブログにあります

成熟度は、ONESのブログの4つのレベルを使い、Lv0からLv3と書きます

これも1社の物差しで、標準ではありません。

困っていたこと

私は、依頼ごとにAIの担当を立て、担当が作業を小分けして子のAIに渡しています。依頼はAIが計画書（フローと呼んでいます）に書き直し、私が承認すると動き出します。

診断させると、最大の弱みは、承認したか、検査に通ったか、レビューに合格したかを、次へ進む前に仕組みが読んでいないことでした。

関門を3つに分けて作らせた

診断のあとの改善案には番号が付いていたので、私は番号を挙げて頼みました。出した指示は、次の一文です。

案１〜３を１つの依頼で振って

AIはこれを3つの箱に分けました。

箱	入れる止め	止まるとき
1	検査を、実行の登録の前提にする	検査でエラーが出たとき。警告では止めない
2	承認の関門	計画書の状態が「承認済み」でないとき
3	レビューの回数の上限	レビューが5回を超える、または0回のとき

3つは同じファイルを書くので、1本道です。各箱は子のAIが書き、箱が終わるたびに、既にある試験を全部回しました。試験は三百件台まで増えましたが、毎回全部通りました。

書く前の試験でずれを見つけた話は、以前AIで作った読書カードの仕組みで、ここに書きました

取り込みの前にも、止めがあります。書いたファイルが決めた範囲の中か、対の試験が通るか、レビュー2人が合格か。この3つを読んで、外れれば止まります。

pushを止める関所は、以前Orcaを使った自動化で作りました。ここに書きました

図：計画書から取り込みまでの流れと、塞いでいない道

決めたのは人

実装の前に、AIは私が決めることを4つ聞いて止まりました。止めに関わる3つを表にします。残る1つは作業の管理の話なので省きます。

決めること	決めたこと	理由
関門が読むもの	計画書の状態の値	承認の事実を読む案は、手順が増える
作業場所づくりにも置くか	置く	置かないと、承認前に作業場所ができる
入口の外を塞ぐか	塞がず、残る道として書く	塞ぐと今の流れが詰まる

答えは3つとも、同じ一文でした。

おすすめどおりでOK

AIは選択肢にそれぞれおすすめを付けて聞くので、答えは短くて済みます。AIの出したおすすめを自分で確かめて、そのまま選んだということです。状態の値は、私の承認のあとにAIが書きます。うっかりは止まりますが、人の印ではありません。

承認をAIの判定に任せた試みは、以前AIで作った仕組みで、ここに書きました

動いて見えたのに、届いていない

関門とは別に、動いているように見えて動いていないことがありました。

レビューのAI2人は、独立にレビューしたあと、対話してから判定します。ある回で、判定は一致していたのに、片方が「相手から届かなかったので返事なし」と書いていました。

AIに調べさせると、送るときに宛名を付けていないことが原因に見えました。手順書を直し、本物のAIを2人立てて試すと、片方の返事は届き、もう片方は届きませんでした。見立ては半分で、受け取る側が「読んだ印」を付けず、同じ束を読み続けていたのです。もう一度直して確かめました。

止めた結果を残す

ハーネスの観測にあたるのが、結果の記録です。検査・レビュー・書いた範囲・試験の結果を、1行ずつ残します。前回は半分でしたが、今回はできていると判定されました。ただ、記録は書くだけで、集計して次を決める道具がありません。ここは次のループの話につながります。

4段でいうと、ハーネスはLv2の一部

2026年10月19日の診断は、次の指示で頼みました。

いまこのOrcaで実装している、「すべての指示に対して設計を行ってOrchestrateでレビューして合格になってから出力する」という仕組みが、◯◯エンジニアリングのどのレベルにあるのかを診断してください。一部なのか全部なのかも含めて丁寧に分析をお願いします。

◯◯は、私の文のままです。物差しの名前は決めずに頼み、AIが出した選択肢から、私がハーネスを選びました。一部か全部かも聞いたので、答えが「Lv2の一部」という形で返ってきました。

判定は「できている」「半分」「できていない」で付け、1つでも半分があれば、そのレベルは半分です。結果は診断してみたもので、客観的な評価ではありません。

ハーネスは、Lv1（Basic Tools）が全部できていて、Lv2（Verification）とLv3（Full Substrate）が一部です。Lv2の要件は9つあり、診断のときは2つができていて、7つが半分でした。前回（2026年10月19日）は、できているが0、半分が7、できていないが2でした。今回の件数の動きは、Lv2の要件の中の話です。

要件	今	前回
決まった検査が実行の前に動く	できている	半分
回数の上限が全部コード	できている	半分
合否をコードが読む	半分	できていない
試験が決まって回る	半分	できていない
承認の関門	半分	半分
ほか4つ（範囲の制限など）	半分	半分

検査と回数の上限は、半分からできているに上がりました。できていなかった2つは、取り込みの前の止めが読むようになり、半分になりました。Lv2が一部のままなのは、残りの7つが半分だからです。

まだ空いているところ

診断で見つかった空きです。

空き	中身
完了の報告が合否を読まない	レビューの判定は読むが、子の完了の報告は読まない
入口の外が塞がっていない	直接の実行が残っている
承認が人の印ではない	状態の値はAIが書く
試験の対象が狭い	診断のときは、取り込みで回る試験は、試験のファイルのおよそ2割

任せたところ、決めたところ

AIに任せたこと	私が決めたこと
3つの止めを書く、試験を書いて回す	関門が読むもの、置く場所、入口の外は塞がないこと
届かない原因を調べる	本物のAIを立てて試すこと
診断して判定を付ける	結果の受け止め方

次回

止めるだけでは、作ったものの中身までは分かりません。次回は、作る人と確かめる人を分けて、直す輪を回す話（ループ）です。

参考