- URL: 【AIハーネス設計から“ループ”設計へ】AIが書いたコードを、AIに検証させる。Gota氏が語る、レビューを自動化するループ設計
- 登壇者: Gota (cc-sdd 作者)
- 開催日: 2026-07-29 (アーカイブ視聴)
- 動画: https://www.youtube.com/watch?v=1TOuEUQq-7A
いつ読むか？
- AI エージェントの実装は速くなったのに、レビュー負荷だけが増えていると感じたとき
- 検証をどの単位で作り、どう管理すればよいか迷ったとき
- 人の介入を減らして回り続ける開発ループを設計しようとしているとき
- 自分の AI エージェント運用の勘所を、他人の体系に照らして点検したいとき
何のセミナーか
cc-sdd 作者の Gota 氏が、自律開発の仕組みを作り込んだ末に「8 時間で 5 万行が動く」最悪の成功体験に至り、一度すべてを解体した経験から、AI が書いたコードを AI に検証させるループ設計を語る回。
自分にとっての価値は、新しい知識を得たことよりも、普段 AI エージェントを使いながら断片的に考えていたことが、名前と順序を持った体系として並べ直されたことにあった。以下、感銘を受けた 5 か所を時刻順に辿る。
24:29 4 つのエージェントの役割
Planning / Execution / Verification / Adaptation の 4 段に分け、各段は最低限の目的で完結させる。共有する真実はコードに置き、別文脈に出すのは判定だけ。人の関与も段ごとに違い、Planning は人が決める、Execution には人は入らない、Verification は証拠だけ見る、Adaptation は緩めるときだけ。
知識と経験が整理された感覚を受けた図。 役割ごとの箇条書きの一つ一つが、普段 AI エージェントを使っているときに考えていることと概ね一致していた。自分がその場その場で判断していたことに、置き場所が与えられた。
Verification の 4 項目で、抽象的だった勘所がつかめた。 「ハーネスエンジニアリング」という言葉を聞くようになってから重要性は感じていたが、具体的に何をすればよいかが掴めずにいた。
- 受入基準ごとに 1 つ
- 実行ログ / 画面の記録
- checks はできる限り決定論のスクリプトで
- 判定は、書いた本人以外
「受入基準ごとに 1 つ」は、検証をどの単位で作って管理していけばよいかの答えになる。「実行ログ / 画面の記録」は、人が成果物そのものをレビューするのではなく、検証結果を確認して生成結果の妥当性を判断できるようにするために要るものだと理解した。
30:04 レビュー負荷を減らすための検証の設計順序
- レビューする場所を減らす — 外部境界・依存の方向・コアの大きさを、構造で決めておく
- 壊れにくい形に縛る — 検証環境を先に。ログとエラーを外から観測できる形にする
- 残りを、証拠で読む — コードではなく、意図と受入基準の証拠を読む
そして「順番を飛ばして 3 だけやると、証拠を大量に読む仕事が増えるだけで、負荷は減らない」。
1 は、レビュー対象の切り分け基準として読めた。 AI の生成結果が予測可能な部分 (間違いなくこうにしかなり得ないと自信が持てるところ) は、決定論的なツールでチェックするか、レビューしないか、AI にレビューさせればよい。逆に、生成結果に幅が出そうな部分や、その結果が重要な意味を持つ部分 (ドメイン固有の意味を持つ、アーキテクチャー的な選択肢が考えられる、など) を人によるレビューの対象とする。
2 と 3 は、人が判断できる情報を判断しやすい形で AI に提出させる話。 人がレビューをせず、AI による決定論的なチェックや検証結果を確認するだけで済ませるには、そもそも観測できる形にしておく必要がある。この順序を守らないと 3 が破綻する、という警告が具体的で腑に落ちた。
38:11 判定を独立させ証拠を出させる
実装エージェントから検証エージェントへ渡すのは、外から観測できる証拠だけ。差分・実行ログ・画面の記録・テスト結果に、どの受入基準にどの証拠が対応するかを添える。実装側の要約や理由づけ、こちらの仮説は渡さない。検証エージェントは別文脈で受入基準ごとに合否を出し、「判定 + 検証の証拠」が残る。信じてよいかは、一度わざと壊して確かめる。
1 つ 1 つの受入基準ごとに評価をしたうえで合否を出す。受入基準ごとに証拠を出させる。証拠を見やすくまとめさせる。 人ができるだけコードを見ずに、証拠を見て生成結果の妥当性を判断できるようにする、という 24:29 と 30:04 の話が、ここでエージェント間のデータの受け渡しとして具体化された。
43:21 ループは下から積み上がる
- Loop 1 エージェントループ — モデルが、終わるまでツールを呼び続ける
- Loop 2 検証ループ — 出力を採点し、落ちたら直してやり直す
ここまでがハーネス設計 (1 つのタスクを、回しきれる環境を作る)。
- Loop 3 イベント駆動ループ — 人が開かなくても、仕事のほうが始まる
- Loop 4 登り続けるループ — 本番の記録から、ハーネス自体を書き換える
ここからがループ設計 (時間方向へ広げる。継続・停止・人への通知)。そして「検証ループが固まらないまま上へ進むと、人の介入だらけになる」。
ループの整理方法がわかりやすかった。 自分は「ループエンジニアリング」を Loop 3 のことだと理解していたが、その上下にあるループとの関係の中に位置づけ直すことができた。Loop 2 が固まっていないのに Loop 3 に進むと人の介入だらけになる、というのは 30:04 の「順番を飛ばすと負荷は減らない」と同じ構造の警告になっている。
Loop 4 を自動化すると、AI エージェントが自律的に成長していくことになりそう。
44:59 Agent が開発フロー全体を行えるよう人間をループの外側におく
相談・失敗障害・アイデアを入口 1 つの「発見」に集め、発見 → 実行 → 検証 → 継続と流す。発見でコンテキストを集めきり、issue は複数生まれて並行に流れる。実行は境界内で実装し自己検証まで。検証は別文脈で判定し証拠を残す。継続は issue ごとにマージして次へ。
検証の出口は 5 つ。
| 結果 | 行き先 |
|---|---|
| 合格 | 継続へ |
| 不合格 | 実行へ戻す |
| 証拠不足 | 取り直す |
| 判断が要る | 人へ返す |
| ブロック | 環境不備。人へ返す |
人間を開発フローの外に置き、AI エージェントだけで回すための区切り方として参考になった。 この単位でタスクとエージェントを分割してループとして構成すれば、ループエンジニアリングを実現できそうな感触があった。人間は「発見」と「検証」のところに介入させる。
体系化されたこと
5 枚のスライドは、人が読むものをコードから証拠に置き換え、そのために構造を先に縛るという一本の線でつながっている。
- 30:04 が方法論の順序 (場所を減らす → 形に縛る → 証拠で読む)
- 24:29 と 38:11 がその実装 (役割の分離と、証拠の受け渡し)
- 43:21 と 44:59 が、それを回し続けるための器 (ループの階層と、人の介入点)
このセミナーで得たものは、新しい知識よりも、抽象的なままだった勘所に具体的な形が与えられたこと、そして断片的に持っていた知識と経験が並べ直されたことだった。
Next Step
次に考えているのは「ループエンジニアリング」の実践。
これまでは、どうやったらうまくいきそうか、知識・経験・方法論のうち何が不足しているのかが、いまいち明確にわかっていなかった。このセミナーに参加したことで必要な知識と勘所が揃った感覚があり、全体像とロードマップが描けそうな感触がある。