既存repo / AIとのやり取りから、おれのハーネスエンジニアリングの現状と課題を見てもらった

Gunma.web #60のテーマLTスライドです。

Transcript

1. A B+ B C+ C C D 既存repo / AIとのやり取りから、 おれのハーネスエンジニアリングの 現状と課題を見てもらった 3ヶ月分の AI とのやり取りと git 全履歴を渡したら、 忖度なしの通知表が返ってきた。 2026/07/18 Gunma.web #60 @TsukasaGR
2. 自 己 紹 介 名前 関口 司 各種アカウント @TsukasaGR 出身 / 在住 群馬県富岡市 / 埼玉県春日部市 仕事 都内の SI 企業で Talevis（タレビス）という自社サービスを開発してます（次ページ） よく触っているもの codex / Cursor / Claude Code / Gamma / TypeScript / React / Next.js / NestJS / Prisma / GraphQL / AWS CDK
3. 宣 伝 Talevis（タレビス） アサイン管理を軸に、スキルや予実まで受託のミドルオフィス領域を最適化する SaaS を作っています。
4. は じ め に 自分がどの程度できているのか、分からなかった テーマは「ハーネスエンジニアリング」 。ふりかえってみると、それらしいことはやっている気がする。ただ、世間一般と比べてどの程度なのかは答えられませ んでした。 そこで、3ヶ月分の活動状況と git 履歴をまるごと AI に渡して、 「ハーネスエンジニアリング活用の通知表」を作ってもらいました。今日はその通知表を見せな がら話します。ひとつでも持ち帰れるものがあれば嬉しいです。
5. A G E N D A 今日話すこと 前提 — 採点の枠組み（7 工程 × 3 層）と、通知表の作り方 ▸ 通知表 — 7 工程の成績。良かった点と悪かった点 ▸ 深掘り — 最重要課題を「現状 → 問題 → 課題 → 施策」の順で ▸ 持ち帰り — 自分のハーネスに聞く 2 つの質問 ▸
6. 前 提 1 / 3 ハーネスエンジニアリング = モデルの「外側」の設計 乱暴にまとめると、答えるべき問いはこうなる。 「あなたの AI は、何を読み、何を許され、何を証拠に、いつ止まるのか?」 OpenAI — モデル単体ではなく、モデルが働く環境・repo の読みやすさ・ツール・フィードバックループを設計対象にする ▸ Anthropic — いちばん単純な構成から始めよ。ループを使うなら成功基準・正解データ・人間のチェックポイント・回数上限を持て ▸
7. 前 提 2 / 3 この LT での工程分け 統一された業界標準は無いため、OpenAI・Anthropic・Addy Osmani の資料をもとに 7 工程 × 3 層へ整理して採点した。 7 つの工程 3 つの層 HOST （実行環境） 能力のおおもと — モデル / ツール / skill ↓ REPO （リポジトリ） 方針・文脈・証拠 — ルール / チェック ↓ TASK （個々のタスク） 今回だけの約束 — ゴール / 止めどき / 予算 Purpose （目的）— 何ができたら完了か ▸ Context （文脈）— 何を読ませるか ▸ Memory （記憶）— 学びをどこに残すか ▸ Capability （能力）— 何を使えるか ▸ Control （制御）— 何を許可・禁止するか ▸ Evidence （証拠）— 何をもって「動いた」と言うか ▸ Loop （反復）— いつ繰り返し、いつ止まるか ▸
8. 前 提 3 / 3 通知表の作り方 — AI に 3ヶ月分の活動を採点させる 対象は業務で使っているリポジトリ（AGENTS / rules / skills） 、~/.codex 、~/.claude 、それと git 全履歴 ▸ 直近 3ヶ月の Codex 417 threads と Claude 119 sessions を分類 ▸ 使える skill を数えると、repo に 7 個 + ホスト側に 45 個 = 52 個あった ▸ 採点結果には「事実か推測か」と「対応済み / 一部だけ / 未整備」のラベルを付けさせた ▸
9. 通 知 表 1 / 3 通知表サマリー 採点は主観。前ページの 3 段階ラベルに沿って付けた。 Context （文脈） A rules に目次・タスク別の参照先・優先順位まである。CLAUDE.md は AGENTS.md を取り込む形で情報源を一本化 Memory （記憶） B+ 繰り返し出る指摘を共有ルールに書き足して残す仕組みがある。ホスト側のメモは古いまま放置ぎみ Capability （能力） B skill 52 個・ブラウザ検証・並列実行と充実。ただし同じ目的の skill が 7 組も重複 Evidence （証拠） C+ 変更範囲ごとの機械的チェックはある。 「確認済み」の中身を示す決まった成果物が無い Purpose （目的） C 完了条件・やらないことの定義が依頼文まかせ。タスクごとに固定する型が無い Control （制御） C 危険な操作の確認、追加作業は頼まれたときだけ、は徹底できている。コスト・回数・時間の上限が無い Loop （反復） D 止めどきが「指摘ゼロまで」しかなく、回数・予算の上限がない ← 最重要課題
10. 通 知 表 2 / 3 — 良 か っ た 点 Context（文脈）と Memory（記憶）は褒められた Context（文脈）: A Memory（記憶）: B+ rules/README が目次・タスク別の参照先・ルール同士の優先順位を定義している ▸ CLAUDE.md は @AGENTS.md を取り込むだけ。Codex と Claude が同じルールを読む ▸ 設計・命名・DB などドメイン別に「正本」を決めてある ▸ レビューで繰り返し出る指摘は、その場で直して終わりにせず共有ルールに書き足して残す ▸ 過去の設計判断は decision log に記録してある ▸ AI との会話で得た学びが、会話と一緒に消えない ▸
11. 通 知 表 3 / 3 — 悪 か っ た 点 低かった 3 工程は、同じ穴から漏れている Evidence （証拠） C+ 「確認済み」と言うときの中身の見せ方が決まっていない Control （制御） C やってよい事は決めたが、どこまでやるか（コスト・回数）が無い Loop （反復） D 「指摘が出なくなるまで」以外の止まる条件がない HOST（実行環境）は整えた。REPO（リポジトリ）も整えた。それでも TASK（個々のタスク）層には「今回の約束」を書く場所がない。この穴の代償をいちばん払っているのが レビューのループなので、ここからはその話をする。
12. 深 掘 り 1 / 5 — 現 状 直近、ひとつの計画に手動レビュー 24 ラウンド 24 1 つの計画に費やした手動レビュー回数 2026-07-10〜14 42.8% Codex の通常タスクでタイトルに「レビュー」 115 / 269 threads 70.1% レビュー・点検役のサブエージェント 101 / 144 今の運用では自動でレビューを繰り返す仕組みは使わない。Codex と Claude の双方から指摘が出なくなるまで、人間が手動でレビューを回す（指摘の自動修正なし・ 追加は頼んだときだけ） ▸ 2026-07-10〜14、ひとつのリファクタ計画に手動 24 ラウンドを実施した ▸ 回数が伸びる構造: 指摘された行だけ直す点修正 → 同じ根本原因を持つ同型の箇所が次のラウンドで見つかる → 「もう一回」 ▸
13. 深 掘 り 2 / 5 — 現 状 （ 経 緯 ） 実は 3ヶ月前、自動収束ハーネスを作っていた 2026-04-07 自動収束ハーネスを自作。実装 → レビュー → 判定 → 修正 → 再レビューを自動で回す。回数上限も人間へのエスカレーションも付けた 118 files +7,640 −1,927 04-25〜05-19 ハーネス自体の成績を測定。正解ケースを用意して検出率・的中率を評価した 2026-05-19 まるごと廃止。自動収束が終わった後にレビューさせてもまだ指摘が出るうえ、トークン消費量が半端じゃなく、コスパが合わないと判断した 81 files +147 −10,279 以来、 「レビューは（ちょっとした skill だけ残して）手動でやる」方針で回してきた。それが前ページの 24 ラウンドにつながる。
14. 深 掘 り 3 / 5 — 問 題 手動 24 ラウンドは、全然笑えなかった 自動でも手動でも、欠けているものは同じ。 「指摘ゼロ」という合格条件だけがあって、 「何ラウンドまで」 「いくらまで」という約束がどこにも書かれていない。書けるようになるま でに、足りないものが 4 つある。 手動の止めどきは「Codex と Claude の双方から指摘が出なくなるまで」 。終わりはあるが何ラウンドで着くかは分からず、そこまで人間がループを回し続ける ▸ 昔の自動に戻れば、トークン消費量の割にリターンが低い問題が再発する ▸ 24 ラウンドを経て、トークン消費量を見ながらレビューと修正が自動で収束していく仕組みはやはり欲しい ▸
15. 深 掘 り 4 / 5 — 課 題 課題: 「今回の約束」を書くために足りない 4 つ 課題 01 タスクの発注書（Task Contract）が無い 約束を書く場所そのもの。ゴール（Goal） ・通過条件（PASS） ・停止条件（STOP） ・予算（BUDGET） ・権限（AUTHORITY）をタスク開始時に 1 枚で固定する型がまだ無い 課題 02 証拠の目録（Evidence Manifest）が無い 約束を守れたと示す証拠の一覧。旧ハーネスには有ったのに、廃止のとき一緒に捨てた。無いままだと「確認済み」を信じきれず、追加レビューに手が伸びる 課題 03 レビューのリターンを測っていない 停止条件や予算は、ラウンドごとの新規指摘数が分からないと決めようがない。24 ラウンドのうち何回が有効だったのか、今は答えられない 課題 04 ホスト側が散らかっている 約束どおりに動く足元が崩れている。同じ目的の skill が 7 組重複し、承認ルールは 104 件。どの手順で動くかがブレる 前半 3 つは TASK（個々のタスク）層の欠落で、通知表の Loop（反復）D の正体。最後の 1 つは HOST（実行環境）の足元の話。
16. 深 掘 り 5 / 5 — 施 策 （ 方 向 性 ） やること 4 つ（課題と同じ順で） PLAN 01 タスクの発注書（Task Contract）の型を作る 「今回の約束」を書く場所を作る。ゴール（Goal）/ 通過条件（PASS）/ 停止条件（STOP）/ 予算（BUDGET）/ 権限（AUTHORITY）を開始時に 1 枚で固定し、Codex も Claude も読む共有の場所 （AGENTS / rules）に置く PLAN 02 証拠の目録（Evidence Manifest）を軽く復活させる 実行したチェックと結果、未確認の項目、残るリスクをタスク終了時に小さくまとめる。旧ハーネスの良かった部分だけ蘇生する。1 万行は要らない、1 枚でいい PLAN 03 レビューのリターンを数え、自動化に戻る判断材料にする ラウンドごとの新規の指摘数と「同じ根本原因の別の場所」の数を記録する。 「トークン消費量の割にリターンが低い」を勘ではなくデータで判断できれば、止めどき付きの自動ループを安心して再導入できる PLAN 04 ホスト側の定期大掃除 重複 skill の統廃合、古いメモの反映か削除、承認ルール 104 件の棚卸し。モデルが強くなるたびに「この仕組み、まだ要る?」と問い直す
17. ま と め REPO（リポジトリ）層は A。TASK（個々のタスク）層は D。 24 ラウンド回ったレビューループの正体は、 「今回の約束」を書く場所の不在。 だから次の仕事は、タスクごとの発注書づくり。 最後に、おれと同じ穴にはまっていないかだけ確認してみてください。 持ち帰り Q1 そのループは、何を見て止まりますか? 回数や予算の上限がないループは、いつか 24 ラウンド回ります 持ち帰り Q2 そのハーネスは、まだ役に立っていますか? モデルが強くなると捨てどきも来ます。おれは 1 万行捨てました
18. A P P E N D I X — 参 考 資 料 References OpenAI — Harness Engineering openai.com/index/harness-engineering/ Anthropic — Building Effective Agents（ループには成功基準・チェックポイント・回数上限を） anthropic.com/engineering/building-effective-agents Anthropic — Harness design for long-running applications（ハーネス無し $9 で壊れる vs ハーネス有り $200 で高品質、次世代モデルでは一部を簡素化、の比較例） anthropic.com/engineering/harness-design-long-running-apps Addy Osmani — Agent Harness Engineering / Loop Engineering addyosmani.com/blog/agent-harness-engineering/ · addyosmani.com/blog/loop-engineering/ データ: 2026-07-16 時点。Codex 417 threads（2026-04-16〜07-16）/ Claude history 119 sessions / git 全履歴。 件数は傾向を示す目安で、トークン・費用・品質を直接は表さない。7 工程 × 3 層の分類はこの LT 用の整理。