ハーネスとは何か

AI を賢くする話ではなく、 AI の外側にある
作業範囲・実行・観測・停止・引き渡しを設計する話。

6/19　札幌すごいAI会でのLT資料／FUJI

Transcript

1. ハーネスエンジニアリング AI を賢くする話ではなく、 AI の外側にある 作業範囲・実行・観測・停止・引き渡しを設計する話。 Review Gate Harness を例に、AIエージェントを安全に回すための実装を話します。 5–7 min LT 1
3. ハーネスエンジニアリングの要素 作るべきものは、AI本体の外側にある 4
4. 具体例: Review Gate Harness AIの「できました」を、そのまま完了にしない 5
5. なぜ必要か AI は速い。でも、そのまま仕事にはできない AI が「できました」と言う 停止・観測・介入を 先に設計する 人間の確認が 追いつかない 変更量が増える AI は一気に直せる。だから見落としも一気に増える。 自己レビューになりがち 同じ文脈の「レビューして」だけでは、別視点になりにくい。 境界変更が危ない 設定・ CI ・認証・ Hook ・ DB などは小さな変更でも影響が大きい。 最低限の門番が必要 人間レビューの前に、機械的に止める場所を置く。 速度が上がるほど、 「どこで止めるか」 「何を記録するか」 「いつ人間に返すか」が重要になる。 3
7. 運用で効いた、壊せない契約 CodexHook の stdout 契約 診断ログは stderr/tmp へ分離 作業範囲の契約 REVIEW_GATE_HOME= ハーネス本体 REVIEW_GATE_TARGET_ROOT = レビュー対象Git logs / reports はハーネス側へ集約 ALLOW は {"continue": true} BLOCK は {"decision":"block","reason":"..."} Fail-open / Fail-closed を機能ごとに決める stdout / stderr 分離 レビュー以前に仕組みを壊さない WSL/Linux 起動へ寄せる adapter と core の分離 終了境界を決める 連続 BLOCK は人間確認へエスカレーション Windows native + Git Bash の不安定さを避ける Claude / Codex の違いは外側へ閉じ込める 7
8. 人間への引き渡し • • • • ADVERSARIAL 変更 static_only レビュー 大きい diff / BLOCK履歴あり NIM / ローカルLLM修正フロー Gate 結果 human_review_required=true になる例 Human Review Packet 最終diff / 変更ファイル一覧 Gate結果 / BLOCK履歴 人間の確認ポイント Dashboard ALLOW / BLOCK human_review_required JSONL logs / BLOCK 理由 再実行 / エスカレーション 完了・ハンドオフ 目的は、人間を消すことではなく、 AI が進めた作業を 人間が判断できる状態に戻すこと。 8
10. まとめ ハーネスエンジニアリングは、 AI と仕事をするための実務設計 任せる範囲を制御する 作業範囲・ Git 境界・変更可能ファイルを明示する 危ない時は止める 出力を観測する 差分・ログ・レビュー結果として残す 人間に返す 自動化しきれないものは判断材料つきで引き渡す 完了直前にGateを置き、fail-closed に倒す AI の内側は触れない。だから、外側を設計する。 10