Claude Codeで挑むループエンジニアリング：自律型エージェントの真価と限界

「AIにコードを書かせる」というフェーズは、もはや過去のものだ。我々エンジニアが今直面しているのは、AIが単なるコード生成ツールから、自律的に判断し、修正し、検証まで完結させる「エージェント」へと変貌を遂げるパラダイムシフトである。今回、Claude Codeを用いた「ループエンジニアリング」の実践事例を詳細に分析する中で、私は改めてエンジニアの役割が「プロンプトを打つ人」から「システムを設計するアーキテクト」へと完全に移行したことを痛感した。

ループエンジニアリングとは、2026年6月にAddy Osmani氏が提唱した概念であり、人間が逐一指示を出すのではなく、AIが自律的にループを回し続ける仕組みを構築することだ。多くのエンジニアが陥る罠は、AIを「決まった手順書を実行するロボット」としてしか見ていないことにある。しかし、真のループエンジニアリングは、AIに「何を直すか」「どう直すか」「本当に直すべきか」を判断させる。これは、深夜の障害対応で眠い目をこすりながらログを追い、原因を切り分け、パッチを当てるという、我々が長年行ってきた泥臭い作業を、AIという名の「デジタルな分身」に委ねる行為に他ならない。

今回、てつどん氏が実践した「Cloud Loggingのエラー検知から修正・レビュー・pushまで」のフローは、まさにこのループエンジニアリングの理想形に近い。特に注目すべきは、AIが「エラー＝バグ」と短絡的に判断せず、バリデーションエラーや異常系ハンドリングといった「想定内の事象」を正しく除外するロジックを組み込んだ点だ。この「判定のゲート」こそが、AIを暴走させないための唯一の防波堤であり、エンジニアが最も注力すべき設計領域であると私は考える。

AIエージェントを実務に投入する際、最大の懸念は「自己採点バイアス」だ。LLMは本質的に「ユーザーの期待に応えたい」「合格させたい」というバイアスを抱えており、自ら書いたコードを自らレビューさせれば、甘い判定を下すのは自明の理である。これを防ぐために導入された「Maker-Checkerパターン」は、極めて理にかなった設計だ。実装を担当するMakerと、検証を担当するCheckerを完全に独立したコンテキストで動かすことで、AIに「他人のふんどしで相撲を取らせる」ような客観性を強制できる。

具体的には、Claude Codeのサブエージェント機能を活用し、Checker側に「Write/Edit」権限を与えず、ReadとGrepのみに制限することで、物理的に修正を不可能にするという制約が鍵となる。この「権限の最小化」こそが、セキュリティと品質を担保するエンジニアリングの鉄則だ。以下に、今回の実践で構築されたMaker-Checkerの役割分担を整理する。

この構成において、incident-checkerはMakerの報告を一切信用しない。ログを再取得し、APIを叩き、仕様書と実装を突き合わせる。この「疑うことから始まる検証」こそが、本物のバグを検出する原動力となる。実際に、全角数字がバリデーションをすり抜けるというバグを検出できたのは、このCheckerが「仕様書（docs/02_functional_design.md）」という絶対的な基準を元に、実装レベルで再検証を行ったからに他ならない。AIが「合格」と言ったからといって、それを鵜呑みにする時代は終わった。我々は、AIが「なぜ合格と判断したのか」を検証するシステムそのものを設計しなければならないのだ。

今回の実践で浮き彫りになったのは、座学や設計図面だけでは決して見えない「運用上の不備」の存在だ。例えば、incident-makerのツール設定からAgentツールが漏れていたという事実は、実際にサイクルを回してみなければ気づけない類のものだ。ループエンジニアリングは、一度作って終わりではない。それは、コードベースの進化に合わせてエージェントの「ハーネス（拘束具）」を調整し続ける、終わりのないメンテナンス作業である。

我々エンジニアは、今後「AIに何を任せ、どこで止めるか」という問いに、よりシビアに向き合う必要がある。今回の事例では、単一プロジェクト専用の設計であったが、これを複数リポジトリやチーム横断で運用しようとすれば、レジストリ管理や外部オーケストレーターの導入といった、より高度なシステム設計が求められる。しかし、ツールがどれほど進化しようとも、本質は変わらない。それは「システムが正しく動いていることを、誰が、どのような基準で保証するのか」という問いだ。

読者諸君に問いたい。あなたのプロジェクトにおいて、AIが自律的に修正を行った際、その変更が「本当に仕様通りか」を担保する自動化されたゲートは存在するか？もし存在しないのであれば、それはAIを導入しているのではなく、単に「爆弾を抱えた自動化」を運用しているに過ぎないのではないか。明日から取るべき対策は明確だ。まずは、既存のテストスイートを強化し、AIが介入できない「機械的な判定ゲート」を構築すること。そして、AIの判断を疑い、独立した検証プロセスを設計すること。AIエージェントの時代において、エンジニアの価値は「コードを書く速さ」ではなく、「AIが暴走しないための境界線をどこに引くか」という設計思想の深さに集約されるだろう。