AI のコード生成はなぜまだ不安定なのか？Loop Engineering が次の解法になるかもしれない

OpenClaw の作者をきっかけに広がった「Loop Engineering」の議論は、表面的には AI Coding の新しいやり方を語っているように見えます。しかし実際には、Kubernetes コミュニティが十数年前にすでに歩いた道を再発見しているようにも見えます。継続的なフィードバック制御ループによって、システムを期待状態へ近づけ続ける、という考え方です。

この 2 年間の AI コーディングツールの流れを並べると、移行の道筋はかなりはっきりしています。Prompt Engineering から Context Engineering へ、そして Loop Engineering へ。最初は、より良い prompt をどう書くかが注目されました。その後、Agent の性能を本当に左右するのは文脈、ツール、記憶、環境だと分かってきました。そしてさらに先では、問題はこう変わります。文脈が十分でも、Agent はまだ不安定です。ではどうするのか。

答えは、モデルに一度で「正しく考えさせる」ことではありません。観察、行動、検証、修正のループに入れ、少しずつ収束させることです。

これはまさに Kubernetes の基本的な世界観です。

1 回の呼び出しから継続的なループへ

現実のソフトウェア開発は、単発の推論ではありません。たいてい次のように進みます。

1. コードを読む。
2. 目標を理解する。
3. 実装を変更する。
4. コンパイルまたはテストを実行する。
5. ズレを見つける。
6. さらに修正する。
7. Review する。
8. もう一度直す。
9. 許容できる状態に達するまで続ける。

これは「prompt -> answer」ではありません。「goal -> loop -> evaluation -> feedback」です。Loop Engineering の価値はここにあります。AI Coding を自動コード生成としてではなく、目標へ自動的に近づくプロセスとして捉えるのです。

初期の実践の中には、すでにこの方向にかなり近いものがあります。たとえば、ループで Claude Code を繰り返し起動し、リポジトリ、計画ファイル、Git の状態から現状を読み直させ、小さなタスクを進める方法です。ここで重要な経験則があります。Agent は忘れますが、リポジトリは忘れません。会話履歴は信頼できず、ディスクに残った状態こそが次のループで依存できる事実です。

Kubernetes はすでにこのパターンを証明している

多くの人は Kubernetes をコンテナオーケストレーション基盤として理解しています。しかしより深い貢献は、制御理論をソフトウェア工学へ持ち込んだことです。

Kubernetes controller が行うことは、次の 4 ステップにまとめられます。

1
2
3
4
5

Desired State
  -> Observe
  -> Compare
  -> Act
  -> Repeat

これは Reconciliation Loop です。Controller は実際の状態が期待状態と一致しているかを繰り返し確認します。一致していなければ調整を続けます。

たとえば、次のように宣言します。

1

replicas: 3

ここで Kubernetes に「1 個目の Pod を起動し、次に 2 個目、次に 3 個目」と命令しているわけではありません。宣言しているのは期待状態だけです。現在いくつのレプリカがあるのか、どの Pod が死んだのか、補充が必要かどうかは、controller がループの中で処理します。

AI Coding も似た構造を形成しつつあります。Agent に対して、どのファイルを開き、どの関数を変更し、どのテストを追加するかを逐一命令するのではありません。代わりに目標を宣言します。この並行処理の問題を修正し、テストが通ることを確認せよ。Agent はリポジトリを観察し、コードを変更し、検証を実行し、フィードバックを読み、次のラウンドへ進みます。

Prompt は Spec になりつつあります。

Loop Engineering の構成要素

使える Loop Engineering システムには、通常いくつかの種類の要素が含まれます。

• 自動トリガー: timer、cron、webhook、GitHub Actions によって、人間のボタン操作に依存しないループを作る。
• 分離されたワークスペース: Git worktree などを使い、複数の Agent が互いに干渉せず並行作業できるようにする。
• プロジェクト知識: SKILL.md、AGENTS.md、仕様書、タスクファイルによって、経験を再利用可能な文脈として固定する。
• ツール接続: MCP、プラグイン、CI/CD、Issue システム、データベースを通じて、Agent が実環境を観察できるようにする。
• サブ Agent: maker、checker、reviewer を分け、モデルが自分で自分を採点する状況を避ける。
• 外部状態: Markdown、Issue、Git commit、タスクボードで進捗を記録し、ループを停止、再起動、継続できるようにする。

これらを合わせると、AI 時代の control plane のように見えます。モデルは実行器にすぎません。システムの能力を本当に決めるのは、ループの組み立て方、状態の保存方法、フィードバックが次のラウンドへ入る方法です。

類似点よりも差異のほうが重要

Loop Engineering と Kubernetes controller は構造的に似ていますが、同じものではありません。最も重要な違いは、Kubernetes が相対的に決定的なシステムを制御するのに対し、LLM のループは確率的なシステムを制御することです。

Kubernetes が Pod を作成するとき、その結果は通常、予測可能で、観測可能で、再試行可能です。一方、LLM に同じ「決済システムの並行処理問題を修正して」という指示を与えても、今日と明日で違う修正をするかもしれません。Claude と GPT がまったく別の解を出すこともあります。

そこからいくつかの難題が生まれます。

• 実行器が不確定: 同じ入力が同じ出力を保証しない。
• 収束を証明できない: ループが何度も変更を繰り返したり、その場で回り続けたり、すでに直したものを壊したりする可能性がある。
• 完了判定が信頼できない: モデルが「完了」と言っても、本当に完了したとは限らない。
• 目標が曖昧: 「決済システムを最適化する」とは、性能、安定性、セキュリティ、保守性のどれを指すのか。
• 検証コストが高い: テストが通っても、性能劣化、セキュリティホール、アーキテクチャ上の負債がないとは限らない。

そのため AI Coding は Kubernetes Operator より難しいのです。reconcile だけでなく、より強い goal definition と evaluation system が必要です。

Maker-Checker は Admission Controller に似ている

なぜ最近の Agent システムは maker と checker を分けるのでしょうか。理由は単純です。実行器を完全には信用できないからです。

コードを書く Agent は自己確認してしまうことがあります。「修正済み」と言ってもテストを十分に走らせていないかもしれません。「より簡潔な方案」と言いながら、新しいリスクを入れているかもしれません。だから別の独立した役割が必要になります。テストを実行し、diff を確認し、セキュリティスキャンを行い、ログを読み、本当に目標を満たしているかを判断する役割です。

これは Kubernetes の Admission Controller や Validating Webhook に近い工学的直感です。実行アクションをそのままシステムへ入れず、まずポリシー、検証、制約を通すべきだという考え方です。

将来の Agent システムは、おそらくより多層化します。

1
2
3
4
5

Maker
  -> Checker
  -> Reviewer
  -> Policy Engine
  -> Human

これはワークフローを無意味に複雑にしているのではありません。確率的な実行器の外側に制御システムを補っているのです。

本当の上限は Goal と Evaluation にある

Loop Engineering の核心は、単にループを設計することではありません。より深く見ると、本当に解こうとしているのは Goal と Evaluation です。

Kubernetes が安定して動くのは、Desired State が形式化されているからです。replicas: 3 の完了条件は非常に明確です。実際のレプリカ数が 3 であること。そこには美的判断も「だいたい完了」もありません。

AI Coding の最大の問題は、まさにここにあります。多くの目標は曖昧です。

• 「このシステムを最適化して。」
• 「ユーザーモジュールをリファクタリングして。」
• 「本番の安定性問題を修正して。」
• 「このコードを保守しやすくして。」

これらの目標を、観測可能で、検証可能で、停止可能な条件に分解しなければ、ループは収束しにくくなります。Agent はいつ続けるべきか、いつ止めるべきかを判断できません。

より合理的な書き方は、次のようなものに近づくはずです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

goal:
  description: "決済システムの並行処理問題を修正する"
  metrics:
    correctness:
      unit_test_pass_rate: "100%"
      integration_test_pass_rate: "100%"
    performance:
      latency_p99: "< 100ms"
      throughput: ">= 1000 tps"
    safety:
      critical_vulnerability: 0
      data_race: 0

evaluation:
  layers:
    - unit_test
    - integration_test
    - e2e_test
    - benchmark
    - static_analysis
    - security_scan
  judge:
    model: "independent-checker"
    threshold: "all_layers_pass"

loop:
  max_iterations: 20
  strategy: "exponential_backoff"

ここまで来ると、書いているものは prompt ではなく、Agent CRD に近くなります。本当に重要なフィールドも、Claude を選ぶか GPT を選ぶかではなく、goal.metrics と evaluation.layers です。

ソフトウェアエンジニアは制御システムエンジニアに近づく

この変化は、必ずしも AI がエンジニアを直接置き換えるという意味ではありません。より起こりやすいのは、エンジニアの仕事の重心が移ることです。

過去、エンジニアの主な仕事はコードを書くことでした。未来には、目標、検証、状態、フィードバックを設計する時間が増えるでしょう。

• 曖昧なビジネス意図を収束可能な目標へ翻訳する。
• 多層の Evaluation Pipeline を設計する。
• Agent の記憶を会話からリポジトリ、タスクボード、永続化された状態へ移す。
• maker、checker、reviewer の境界を設計する。
• 停止条件と失敗時の再試行戦略を定義する。
• 何を人間が最終確認すべきかを判断する。

Prompt Engineer は次第に退場するかもしれません。prompt が無用になるからではなく、promptを書くこと自体がシステム化されるからです。より希少になる能力は、Goal Engineering と Evaluation Engineering でしょう。

結論

Loop Engineering は、何もないところから突然現れた新概念ではありません。制御理論、状態機械、フィードバックシステム、Kubernetes controller、Operator Pattern が、AI Coding の時代に復活したものに近いです。

この変化は 4 つの層に分けて理解できます。

1. 構造の類似: Loop は Operator に似ている。
2. 実装の類似: Agent は Controller に似ている。
3. 本質の類似: Goal は Spec に似ており、Evaluation は Status に似ている。
4. 最も重要な層: AI Coding はコードを書く自動化ではなく、目標へ近づく自動化である。

目標へ自動的に近づくすべてのシステムは、最終的に制御理論へ戻ります。目標は明確か、状態は観測可能か、フィードバックは正確か。

だから、これから 10 年の AI Native ソフトウェア工学で最も研究すべき問いは、「どのモデルがより強いか」ではないかもしれません。むしろ、ソフトウェアが自分自身を変更し始めたとき、それを制約し、検証し、修正し、最終的に信頼してよいかを決める制御ループを、私たちはどう設計すべきか、という問いです。