「Vibe Coding」の先へ：アーキテクトが設計する『ループエンジニアリング』と自律開発インフラの構築

はじめに

2023年から2025年にかけて、生成AIを活用したコーディングは爆発的に普及しました。しかし、人間が手動でAIに指示を出し、出力されたコードをコピペして確認する「ターン制」のスタイル（いわゆるVibe Coding）は、個人の局所的な生産性を上げたものの、組織スケールにおける持続可能性（Scalability）や一貫性（Consistency）という観点では限界を迎えています。

AIの自律性が急速に高まった現在、エンジニアリングのパラダイムはシフトしています。これからの技術指導者に求められるのは、AIに個別のプロンプトを入力することではありません。「AIが自律的に動き、検証し、修正を繰り返す『システム（ループ）』そのものを設計・構築すること」です。

元GoogleのAddy Osmani氏は、自身のブログ記事『Loop Engineering』の中で、Peter Steinberger氏の*「もはやコーディングエージェントにプロンプトを打つべきではない。エージェントにプロンプトを打つ『ループ』を設計すべきだ」という言葉や、Anthropic社のClaude Code責任者であるBoris Cherny氏の「私はもうClaudeにプロンプトを打たない。ループを走らせている。私の仕事はループを書くことだ」*という言葉を引き、このパラダイムシフトの本質を突いています。

本記事では、この「Loop Engineering（ループエンジニアリング）」の概念をもとに、個別最適から全体最適へと向かう次世代の開発インフラを、アーキテクチャの視点から紐解きます。

1. なぜ今「ループ」の設計が必要なのか：個別最適から全体最適へ

メンバー個々人が異なるAIツールを使い、独自のプロンプトを試行錯誤している状態は、一過性の効率化にはなっても組織の資産にはなりません。目指すべきは、チーム全体で共有・再利用が可能な「自律開発パイプライン」への昇華です。

ここで重要なのは、「ハーネス（Harness）」と「ループ（Loop）」の構造的違いを理解することです。

• ハーネス（環境の整備）： 単一のAIエージェントを安全に動かすための実行環境やコンテキストの準備。
• ループ（上位システムの設計）： 複数のエージェントをスケジュール実行やイベントトリガーと協調させ、レビュー、テスト、デプロイまでを自律的に循環させるシステム全体。

Osmani氏が指摘するように、ループエンジニアリングはハーネスの「ワンフロア上」に位置する概念です。タイマーやフックによって駆動し、サブエージェント（小さなヘルパー）を生成しながら自律的にインフラへフィードバックを与える上位システムをオーケストレーションすることこそが、アーキテクトが主導すべき領域です。

かつてはこうしたループを構築するために大量のBashスクリプトを泥臭くメンテナンスする必要がありましたが、現在ではCodexアプリやClaude Codeといったプロダクトの内部に、これらのプリミティブな機能が標準実装され始めています。私たちは個別のツール論に終始するのではなく、ツールが変わっても機能する「ループの共通形状」を設計しなければなりません。

2. ループアーキテクチャを構成する6つのビルディングブロック

Osmani氏は、現在の先進的なAI開発ツールに共通して組み込まれつつある、ループを構成するコア要素（5つのコンポーネントと1つの記憶領域）を挙げています。これらをクラウド・インフラアーキテクチャの観点から解釈・分解します。

[イベントトリガー (Automations)]
        │
        ▼
[環境隔離 (Worktrees)] ── (Skills: コンテキスト注入)
        │
        ▼
[実行 (Plugins/Connectors)] <──> [相互牽制 (Sub-agents)]
        │
        ▼
[状態管理 (State & Memory)]

① Automations（自動トリガーと自律起動）

AIの起動を人間の手動操作から解放します。CIのテストエラー、GitHub Issuesの発行、あるいは定期的なcronジョブなどをイベントソースとし、バックグラウンドでループを自動キックするイベント駆動型アーキテクチャを構築します。例えば、CIエラーの要約やバグハンティングを定期実行させ、結果をトリアージ用のインボックスに集約する設計が可能です。

また、多くのツールで導入されている /goal コマンドのように、「すべてのテストが通過し、リントがクリーンになるまで周回を続ける」といった、検証可能な停止条件を満たすまで自律駆動する仕組みがこれに該当します。

② Worktrees（環境隔離と並行処理）

複数のAIエージェントが同時に、かつ自律的に動くため、作業環境の競合（コンフリクト）を完全に防ぐ必要があります。git worktree などを活用し、エージェントごとにクリーンで隔離されたサンドボックス環境をオンデマンドでプロビジョニングし、並行処理させてもファイルが衝突しないインフラ設計が不可欠です。

③ Skills（暗黙知のメタデータ化）

プロジェクト固有のアーキテクチャ規約、ビルド手順、過去の教訓といった「チームの暗黙知」を SKILL.md などの形式でコード化（宣言的メタデータ化）します。エージェントが起動するたびにこれをコンテキストとして自動注入することで、「毎回同じ前提条件をプロンプトで説明する」という無駄を省き、プロジェクトのインテント（意図）を累積的に学習させます。

④ Plugins / Connectors（外部エコシステムとの連携）

Model Context Protocol（MCP）などを活用し、エージェントがローカルのファイル操作に閉じないよう設計します。Slackへの通知、LinearやJiraのチケット更新、ステージング環境へのデプロイなど、外部APIやクラウドサービスと双方向に安全に連携できるコネクタレイヤーを整備することで、AIが「修正案を示す」だけでなく「実際にPRを開き、チケットを更新する」までの自律性を獲得します。

⑤ Sub-agents（相互牽制による品質保証）

システム設計における「職能分離（Separation of Duties）」をAIワークフローにも適用します。コードを書くモデルは、自分の書いたコードの検証に対して甘くなりがちです。そのため、コードを生成する「実装エージェント」と、それを静的解析や仕様の観点から厳しくチェックする「検証・レビューエージェント」を分離し、相互牽制（マルチエージェント・コラボレーション）を行わせることで品質を担保します。

⑥ State & Memory（状態管理）

自律型ループは長時間の非同期処理になりがちです。エージェントはセッションをまたぐとコンテキストを忘却してしまうため、進捗や試行錯誤の履歴をリポジトリ上のMarkdownファイル（AGENTS.mdなど）や外部システムに「ディスク永続化」する状態管理レイヤーが必要です。「エージェントは忘れるが、リポジトリは忘れない」構造にすることで、途中でエラーになってもチェックポイントから再開可能にします。同時に、実行予算やトークン消費量を追跡・監査するためのメトリクス収集もここに組み込みます。

3. アーキテクチャの要：ガバナンスとリスク管理

どれだけ優れたループを設計しても、制御不能になればただの「コスト垂れ流しマシン」と化します。Osmani氏も「トークンコストには絶対的な注意が必要である」と警告している通り、実務に導入する上で最も重要なのが以下のガバナンス設計です。

• 暴走の防止（ハードリミットの設定）：
  最大実行回数（Max Iterations）の制限、1ループあたりの最大消費トークン数、および月次の予算上限（Billing Alarmと連動した強制停止）をインフラレベルで埋め込みます。無限ループによるクラウド破産を防ぐセーフティネットは必須です。
• 安全な終了条件（Stop Conditions）と人間へのハンドオフ：
  「すべてのテストが100%通過した」といった厳密な終了条件を定義します。一方で、数回連続で同じエラーを解決困難な場合などは、それ以上のトークン消費を止め、そこまでの実行ログとコンテキストを添えて人間に「エレガントにハンドオフ（通知）」する境界線を設計します。
• 最小特権原則（Least Privilege）：
  エージェントに付与するIAMロールやGitHub Tokenなどの認証情報は、必要最小限の権限（リポジトリの特定ブランチへのプッシュ権限、特定のサンドボックス内での実行権限など）に絞り込み、セキュアなシークレット管理を行います。

4. 組織とエンジニア体験（DevEx）の再定義

ループエンジニアリングが浸透した組織では、エンジニアの役割と評価軸がドラスティックに変化します。

「仕様通りに素早くコードを書く」という職能の多くは、24時間365日稼働するループシステムへと代替されていきます。これからのエンジニアに求められるのは、「ビジネスドメインを深く理解し、ループシステムが正しく動いているかを検証・評価する能力」、そして「ループそのものを改善するメタエンジニアリング能力」です。

これはエンジニアの価値を奪うものではなく、DevEx（開発者体験）を最高峰へと引き上げるトリガーになります。

「技術的負債の自動返済ループ」や「依存パッケージの自動アップデートループ」をバックグラウンドで常時稼働させる。

人間が泥臭い運用のメンテナスから解放され、本質的なアーキテクチャ設計や、コアとなるビジネス価値の創造に集中できる環境こそが、ループエンジニアリングの真のゴールです。

しかし、Osmani氏が強く主張するように、ここには「認知の降伏（Cognitive Surrender）」という罠が潜んでいます。ループが自動でコードを量産するスピードに、人間の理解が追いつかなくなる「理解の負債（Comprehension Debt）」が発生するリスクです。

二人のエンジニアが全く同じループを構築したとしても、片方は「自分が深く理解している領域の作業を加速させるため」に使い、もう片方は「理解することを避けるため」に使うならば、結果は真逆になります。ループはどちらの意図で動かされているかを区別しません。だからこそ、私たちは「ただ実行ボタンを押すだけの人」になるのではなく、コードの最終的な挙動に責任を持つ「エンジニア」であり続ける意志が必要です。

5. まとめ：どこから始めるべきか

ループエンジニアリングは一過性のトレンドではなく、今後のソフトウェアエンジニアリングにおける標準的なインフラプラクティス（Engineering Infrastructure）になる可能性を秘めています。

とはいえ、最初から完璧なマルチエージェント自律システムを組む必要はありません。まずは「CIで特定のエラー（例：静的解析エラー）が発生したら、それをトリガーに修正PRを自動作成する単一のループ」といった、小さく具体的なスコープから始めるべきです。

AIという不確実性の高いコンポーネントを、決定論的なソフトウェア開発のインフラの中にどう安全に組み込むか。泥臭いシステム設計と「人間による継続的な検証・監視」の目を持ちながら、自社の開発基盤を「自律型」へとモダンにアップデートしていきましょう。

参考文献・引用元

• Addy Osmani, "Loop Engineering" (2026)
  URL: https://addyosmani.com/blog/loop-engineering/