Claude Code自律化とZ3形式手法で作る2026年AI開発ループ

• 事実と背景：mizchi氏が2026年時点での自律型AIプログラミング手法とCI評価指標の最新知見を公開。
• 技術的変革：単一指示からClaude Codeの/goalやRalph Loopによる自律ループと形式手法（Z3/TLA+）連携へ刷新。
• 現場への影響：プロンプト指定よりもRSSやMutation Testなど厳格な評価数値のCI組み込みと人間側の評価設計が必須に。

深夜3時、障害アラートで起こされスパゲッティコードのデッドロックを追う——そんな不条理な泥臭い現場から、我々エンジニアはついに解放されようとしている。しかし、単に「Claudeにコードを書かせる」というレベルで止まっているチームは、AIプログラミングの本質を見誤っていると言わざるを得ない。現在我々が立ち向かうべきは、プロンプトの工夫などではなく、「人間が評価指標（メトリクス）を設計し、AIエージェントに自律的な改善ループ（Loop）を回させるシステムアーキテクチャの構築」である。

最も原始的な自律ループは、while : ; do claude -p "Git 履歴を見て次にやることを探して"; done といういわゆるRalph Loopに始まる。これをさらに実用化したものが、claude session hook を用いてセッション終了時に「/goal Issues を全部潰して」と自動リトライを発生させるアプローチだ。エージェントは指定されたゴールを達成するまで、人間の介在なしに自律的に思考と試行錯誤を繰り返す。ここで致命的となるのが、AIの「完了判断」をどこに委ねるかという問題だ。

AIに曖昧な指示を与えて放置すると、自己満足の無限ループに陥るか、リファクタリングと称して不要な破壊を引き起こす。これを防ぐためには、主観的な良し悪しではなく、CI（継続的インテグレーション）上で計測できる厳格かつ決定的な評価指標を与える必要がある。例えば、実行環境に左右されやすい実行時間ではなく、メモリ使用率のRSS（Resident Set Size）やFuelのような決定的指標を優先採用することだ。具体的には、hyperfineやperf、valgrindを用いた低レイヤーでのリソース計測、cccc（https://github.com/moznion/cccc）による循環複雑度の定量的削減、mizchi/similarity（https://github.com/mizchi/similarity）によるコード重複率のチェック、そしてMutation Test（ミューテーションテスト）のKill率やVRT（Visual Regression Test）の一致率といった数値である。

これらの数値をCIに組み込み、「数値が向上しない限りPRを承認しない」というゲームルールをセットすることで、AIは探索的改善を開始する。SRE視点でのテレメトリ計装、N+1クエリの探索と修正、ローカルDocker環境でのペネトレーションテストによるセキュリティ監査など、多角的な視点から生成された課題はUmbrella Issueとしてまとめられ、/goal コマンドをトリガーに順番に自動消化されていく。人間がやるべき仕事は、テストが長くなりすぎないように優先順位を打ち出し、AIが評価指標を正しく追えているかログを観察することなのだ。

どれほどAIが優れたコードを生成し、CIのユニットテストをグリーンに保ったとしても、「そもそも作成した仕様自体が間違っている」という根本的欠陥を防ぐことはできない。特にマイクロサービス間の分散トランザクションや、マルチスレッド環境における複雑なキャッシュ制御のコードは、経験上、人間のレビューでもAIの単体テストでもほぼ確実にエッジケースの漏れが発生する。ここに我々が形式手法（Formal Methods）を導入すべき絶対的な理由がある。

自然言語による曖昧な要件定義をAIに与えるのではなく、強い型システムや述語論理を用いた形式仕様言語へと落とし込む。複雑な状態遷移や並行処理の検証にはTLA+やQuintを使用させ、述語論理で表現できるデータ構造の制約や整合性チェックにはZ3ソルバーを活用する。さらに、アルゴリズムの正当性証明にはLeanを、複雑なロールベースアクセス制御（RBAC）などのユーザー権限周りのモデル化にはAlloyを指定する。「今あるコードを形式化できる部分を形式化し、それをテストオラクル（正解判定器）として実装が従っているか確認せよ」と指示を送るのだ。

形式手法の真骨頂は、モデル検査（Model Checking）によって反例（Counterexample）が検出された瞬間にある。モデルチェッカーが仕様の不備やレースコンディションを示す反例を吐き出した場合、その反例データを即座に具体的なテストコード（E2Eやユニットテスト）へ自動変換させる。これにより、人間が頭を抱えて再現手順を模索していた深夜の障害対応のようなバグが、実装前に完全に自動炙り出し可能となる。mizchi/skills/tree/main/formal-methods-reconciler のような仕様適合スキルを連携させることで、形式言語の厳密性とLLMの柔軟なコード生成能力が融合し、バグの入り込む隙を構造的に排除した開発ラインが完成するのだ。

AIプログラミングの世界において、昨日までの「常識」は今日の「ゴミ」となる。かつて効果的とされた「あなたは優秀なプログラマです」という役割付与や、「問題に取り組む前に、ゆっくり深呼吸してください」といった思考を促すプロンプト（数学性能が7ポイント改善したとされるテクニックなど）は、最新モデルの内部アーキテクチャ更新によって既に陳腐化している。我々エンジニアに求められるのは、古いノウハウを即座に捨て去る「アンラーニング」の姿勢だ。

リポジトリ内のAgents.mdやグローバルプロンプトに、モデルが既に世界知識として知っている一般的な知識や冗長なプロンプトを書き込むのは有害ですらある。記述すべきは、プロジェクト固有の意思決定における判断基準や強い制約のみだ。例えば「Node.jsは24+を採用する」「既存設計は尊重しつつ新規モジュールにはnpmではなくpnpmを使う」「Rustはstable 1.99を使う」「gh stackによるスタックPR運用を行う」といった、複数の選択肢が存在する場面でのローカルルールに限定すべきである。モデルの学習データは常に数ヶ月から半年程度古いため、最新のライブラリ仕様や特定のSkill（スキル）定義は、モデル自体の進化によって急速に不要化するリスクを考慮しなければならない。

また、コンテキストウィンドウの管理においても戦略的なアプローチが不可欠だ。コンテキスト圧縮コマンドである/compactは強力だが、適切な判断基準（テストや評価指標）が提示されていない状態で圧縮を実行すると、重要なコンテキストが欠落し誤った方向へ倒れる危険を孕んでいる。既存の巨大なリポジトリに適用する際は、まずmizchi/explainer（https://github.com/mizchi/explainer）やdreambigou/eli5（https://github.com/dreambigou/eli5）といった解説スキルを用い、アーキテクチャの概要や関数シグネチャ、E2EテストケースをAI自身に図解・言語化させ、GitHub CLIのgh --attachフラグ（https://gihyo.jp/article/2026/09/github-cli-attach-flag）でPRに添付させるといった、人間の直感的理解とAIのコンテキスト共有を同期させるワークフローが極めて有効である。

コード生成からテスト作成、形式検証までが自動化された先にある最終的なボトルネックは、人間によるプルリクエスト（PR）のコードレビューとマージ作業である。OpenAIの内部開発運用に見られるように、AIによるPRトリアージの自動化はすでに現実のものとなりつつある。リスクの低い単純なリファクタリングやVRTの軽微な修正はAIが自律的にマージし、データベースのスキーマ変更やTerraformによるインフラ定義の変更といった「高リスクな変更」のみを人間にエスカレーションする仕組みだ。

ここで我々開発者は、自らの存在価値についての根本的な問いを突きつけられることになる。作業の大部分をAIが消化し、危険な変更の最終判断とレビューだけが人間に回ってくる開発プロセスにおいて、我々は単なる「リスクの責任を取るための承認ボタン押し係」に成り下がっていないだろうか？ コードを書く時間が激減した現場で、エンジニアの本質的な価値とは一体何処に存在するのか。

その処方箋は明快だ。人間の主たる役割は「コードを書くこと」から「ドメイン知識を評価指標へ昇華させること」へと完全にシフトした。どの数値を優先し、どのトレードオフを受け入れるのか。ビジネス要求やユーザー体験を、RSSやMutation Kill率、形式仕様といった「AIが最適化可能な客観的数値」に変換するアーキテクトとしての思考力こそが、これからのシニアエンジニアに求められる唯一無二のスキルである。明日からの開発現場で、あなたはAIにどんな無茶振りを投げかけ、どのような評価指標を設計して自律ループを回し始めるだろうか？