Claude Code（Opus 4.8）の自走サイクルを、実プロダクトで回してみた
AI に「Issue を直してリリースまで」を任せる実験を、OSS プロダクト Agent Deck で試しました。実装と検証を別のエージェントに分け、人間がゲートを持つ「監査できる自走」をどう組んだか。そして実際に回した 1 周を、誇張せずに書きます。
🤖 3行でわかるポイント
- 1Claude Code（Opus 4.8）の自走ループを実プロダクト Agent Deck に通し、Issue を 1 件直して v0.3.4 を自動でリリースした
- 2実装役（Maker）と検証役（Checker）を別エージェントに分離。Checker は LLM の感想ではなく node --test の exit code など"実行できる合否"だけで判定する
- 3すべての PR は公開、backlog の承認とリリースの引き金は人間の手。"AI が勝手に出荷"ではなく"監査できる自走"を目指す
ループの構成要素
実際に起きたこと
- ✓Issue #9（同分発火のブランチ名衝突）を決定論的に修正
- ✓Maker → Checker の独立検証（6 ゲート・すべて exit code で判定）
- ✓CI 全 green（test×3 + smoke×3 + CodeQL×4）→ v0.3.4 を公開
- ✓全 PR 公開・人間レビュー・監査ログに「1 サイクル 1 行」
v0.3.4 リリースノート
2026年6月14日
AI コーディングエージェントに、「Issue を見つけて、直して、リリースする」までを任せたら、どこまで安全に回せるのか。それを実プロダクトで確かめた実験の記録です。
舞台は、私たちが OSS で公開している Agent Deck 。複数の AI CLI エージェントを並列で操るデスクトップアプリです。今回はその開発側を、Claude Code（Opus 4.8）の自走ループに通しました。
先に正直に言っておきます。これは「AI が勝手にプロダクトを育てる」話ではありません。 人間がゲートを握ったまま、Issue を 1 件、誰でも検証できる形で消化した——起きたのはそれだけです。でも、その「だけ」を地に足のついた形で回せるかどうかが、実は一番難しい。
🧭なぜ、実プロダクトで試したのか
この自走ループ自体は、いきなり生まれたものではありません。まず私たちは社内の開発ハーネス willink-claude-kit で「人間レビュー付きの自走サイクル」を先に実証してきました。
ただ、ハーネス（道具）自身を直すのと、実ユーザーがいるプロダクトを直すのとでは、緊張感がまるで違います。壊せば使っている人に届いてしまう。だからこそ、2 つ目の実証台として、 公開リポジトリで誰でも検証できる Agent Deck を選びました。「動いた」も「危なかった」も、全部 GitHub 上に残る形で。
⚙️仕組み — 実装役と検証役を分ける
このループの肝は、作る人と確かめる人を別にすることです。 自分の書いたコードを自分でレビューすると、どうしても甘くなる。人間でもそうですし、LLM ならなおさらです。 そこで、実装する Maker と検証する Checker を独立したエージェントに分けました。
ゲート（着手前）
人間が「やっていい」と印（loop:approved ラベル）を付けた Issue だけが対象。 同時に走る作業が増えすぎないよう未マージの PR 本数で頭打ちにし、 連続で失敗していたら止まります。backlog が空ならそもそも起動しません。
preflight（自己点検）
作業ディレクトリが git worktree で隔離されているか、ブランチ名がloop/issue-N か、安全フックが応答するか。前提が崩れていたら、コードに触れる前に中断します。
Maker（実装）
worktree の中で Issue を 1 件だけ実装。コミットは変更したファイルをパス指定で束ねて行い、 ほかの作業が紛れ込むのを防ぎます。バージョンを上げたり、勝手にタグを打ったりはしません。
Checker（独立検証）
別エージェントが、Maker のテストをそのまま信用せずに検証。 判定の根拠は node --test の終了コード、変更ファイルの範囲、機密スキャンなど、機械が白黒つけられるものだけ。「良さそう」では通しません。
通れば Draft PR を起こし、1 サイクルを監査ログに 1 行残します （Issue・試行回数・preflight 結果・Checker のゲート・機密スキャン結果まで）。 あとから「いつ・何を・どう確かめて通したのか」を全部たどれるようにするためです。
🔁実際に回した 1 周（Issue #9）
今回直したのは、地味だけれど実害のあるバグでした。Agent Deck のスケジュール起動機能で、同じ分に発火する 2 つの予約（同じリポ・同じプリセット・ブランチ接頭辞なし）が、 まったく同じ名前のブランチを作ってしまう。結果、2 本目の git worktree addが失敗して、その予約は起動しない——という Issue #9 です。
Maker の直し方
ブランチ名は「分」までしか一意でなかったのが原因。そこで予約ごとの ID から決定論的な短いトークン（依存ゼロの FNV-1a ハッシュ）を足しました。乱数ではないので、 同じ予約は何度でも同じ名前——再現性を保ったまま衝突だけを消します。
Checker の確かめ方
Checker は自前のスニペットで独立に再現。別々の予約 A・B が本当に違うブランチになること、同じ予約なら同じになること（決定論）、既存の呼び出しは1 文字も変わらないこと（後方互換）を、すべて exit code で確認しました。
ユニットテストは node --test で 168 件すべて green。 PR を出すと CI が ubuntu / macOS / windows の 3 OS でテストとスモーク（実際にアプリを起動する検査）を回し、 CodeQL も含めて全チェック green。 そこで squash マージし、バージョンを上げてタグを打つと、Release ワークフローが 3 OS のインストーラを作って、v0.3.4 として公開されました。
🛡️安全装置と、正直な限界
ここが一番大事なところなので、はっきり書きます。これは「全自動」ではありません。
人間が握っているもの
どの Issue に着手していいかを決めるのは人間。リリースの引き金（タグ push）も人間の手です。 ループは PR を用意するところまで。最後にスイッチを入れるのは、いつも人。
止まる仕掛け
同じ Issue で3 回失敗したら自動で停止。 機密スキャンに引っかかれば即中断。さらに、惰性で回し続けないための見直し期日を設けています（コストの問題ではなく、統制のチェックポイントとして）。
誇張はしたくありません。起きたのは——人間がゲートを持った自走ループが、Issue を 1 件、監査できる形で消化し、リリースまで運んだ。それが全部です。 派手ではない。でも、「AI に任せて大丈夫か」を確かめるなら、派手さよりたどれることの方が、ずっと大事だと思っています。
🔄この実験を、道具に戻す
Agent Deck で効いたパターン——「実体ごとに決定論的な識別子を足す」「worktree のゲートを対象リポジトリで切り替えられるようにする」——は、 社内ハーネスの willink-claude-kit に汎用化して戻す前提で進めています。
1 つのプロダクトで証明する → 道具に落とす → 横に展開する。私たちが OSS でやりたいのは、まさにこの循環です。今回の自走サイクルも、その一歩。
📝v0.3.4 の内容
🐛Fixes
fix(schedule)修正は PR #11 で公開しています。Maker → Checker のやり取りも PR の説明に残してあるので、よければ覗いてみてください。
Agent Deck を試す
複数の AI CLI エージェントを並列で操るデスクトップアプリです。最新リリースをダウンロードして、ぜひ触ってみてください。
Agent Deck を見る（GitHub / ダウンロード）