2026/07/08

人工知能エージェント自律走行のループエンジニアリングとは

記事イメージ
※画像はイメージです。本文と直接の関係はありません

人工知能エージェント自律走行のループエンジニアリングとは

Loop エンジニアリングは、(1)指示文作成の自動化 と(2)ループ全体の設計・監視 の二本柱から成り立ちます。この二本柱を実現するために、本来は 自動化・作業ツリー・スキル・プラグイン・コネクタ・サブエージェント・状態・記憶 の 8 つの要素が必要です。ただし、プラグインとコネクタは機能上ひとつにまとめ、状態と記憶も同一の永続化機構として扱うことで、実質 6 要素(自動化、作業ツリー、スキル、プラグイン・コネクタ、サブエージェント、状態・記憶)として整理できます。以後はこの 6 要素 という表現で統一します。エンジニアは個別の指示文を書く手間を省き、システム全体の構造と安全性の確保に注力できます。


Loop エンジニアリングの概要

従来はエージェントを呼び出すたびに指示文を作成していましたが、Loop エンジニアリングでは「エージェントを自律的に呼び出し続けるシステム(ループ)自体」を設計します。人間の役割は「エージェントに指示を出す人」から「エージェントに指示を出す仕組みを作る人」へと変わります。

この概念は 2026 年 6 月 に Addy Osmani 氏が「Loop エンジニアリング」として体系化したことがきっかけです。同時期に Peter Steinberger 氏は「エージェントに指示を書くのではなく、エージェントに指示を出すループを設計すべきだ」とツイートし、Anthropic の Boris Cherny 氏も「指示を書かずに、ループで Claude に指示させている」と語っています。

注記
本稿で紹介する個人プロジェクト(2022 年 2 月構築)は、Loop エンジニアリングの概念が正式に提示される以前に実装された先行事例です。概念化後に同様の手法が体系化されたことから、概念の有用性が実証された形となります。

従来の人工知能開発ステージとの位置付け

  • 第1世代:指示文設計 – 1 回の指示文(プロンプト)をどう作るか。
  • 第2世代:文脈設計 – モデルに渡す情報(文脈)をどう設計するか。
  • 第3世代:足場設計 – ツールや実行環境(足場)をどう整えるか。
    • 足場(Scaffolding) とは、実行環境や外部ツールとの接続基盤を指します。
  • 第4世代:ループエンジニアリング – 足場上に 自律的な継続性(Persistence) を組み込み、繰り返し実行されるループを設計する。

第3世代は「足場を整える」段階であり、そこに自律的な継続性を加えることで第4世代が完成します。

Loop を構成する要素と 1 周のステップ

Loop エンジニアリングで設計すべき 6 要素(自動化、作業ツリー、スキル、プラグイン・コネクタ、サブエージェント、状態・記憶)を、実行フローの 5 ステップ に対応させて整理します。

  1. 発見(Discovery)

    • 活用要素:状態・記憶、スキル
    • 内容:Issue・PR・メール・Slack メッセージなどから次にすべきタスクを自動抽出する。
  2. 引き渡し(Handoff)

    • 活用要素:作業ツリー、プラグイン・コネクタ
    • 内容:各エージェントが独立したブランチや作業ディレクトリでタスクを実行する。
  3. 検証(Verification)

    • 活用要素:サブエージェント、作成者と検証者のパターン
    • 内容:作成役と検証役のサブエージェントでテスト・Lint・コードレビューを行い、合格かどうかを判定する。
  4. 永続化(Persistence)

    • 活用要素:状態・記憶
    • 内容:実行結果やログを Markdown 形式(例:STATE.md)で保存し、次回のループで再利用できるようにする。STATE.md は「エージェントが次に何をすべきか」を示すコンテキストのバトンとして機能します。

    STATE.md のサンプル

    # Loop 状態ファイル
    
    ## 現在のタスク
    - ID: 1234
    - タイトル: バグ修正 #42
    - 担当エージェント: code-fixer
    - ステータス: 実行中
    
    ## 前回の結果
    - テスト結果: 失敗 (3/10)
    - エラーログ: `error.log` 参照
    
    ## 次のアクション
    - 再実行トリガ: スキル `retry-fix` (5 分後)
    - 必要リソース: 200 トークン上限
    
  5. スケジューリング(Scheduling)

    • 活用要素:スキル(再実行トリガ)
    • 内容:定期実行(cron)やイベント駆動でループを再起動する。

このサイクルは、目的が達成されるか、もしくは人間への引き継ぎが必要になるまで自律的に繰り返されます。


実装例とツールチェーン

個人プロジェクトでの実装例(2022 年 2 月)

1 つのスケジュールジョブと Markdown 形式の状態ファイルだけで以下の流れを自動化しました。

  • Issue のトリアージ → 計画作成 → 実装 → レビュー → テスト → CI 待ち → 自動マージ → デプロイチェック
  • 状態ファイルはプレーンな Markdown で「何がリリースされ、何が失敗し、何が未対応か」を記録し、前回の続きから再開できるようにした。

企業での活用例

  • Slack 監視 → Notion タスク登録

    • トリガー:Slack メッセージ(5 分ごと)
    • 処理:メッセージを解析し、Notion のタスクデータベースに自動登録
  • Notion タスク自動実行

    • トリガー:タスク状態(10 分ごと)
    • 処理:Claude Code がコード生成・テストを実行
  • PR ベビーシッター

    • トリガー:PR 更新(リアルタイム)
    • 処理:CI が通るまで自動で修正案を生成し、テスト合格後にマージ
  • 不要ブランチ自動削除

    • トリガー:リポジトリ監視(定期)
    • 処理:不要ブランチを自動で削除(例:129 件)

すべて「自動化 → 作業ツリー → サブエージェント → 状態・記憶」の流れに従っています。

コマンドラインツール群(cobusgreyling 氏が管理)

  • loop‑init テンプレート(スキル・状態・予算)を一式生成する。
  • loop‑audit ループの準備度をスコア化して評価する。
  • loop‑cost 実行前にトークン消費量を見積もる。
  • loop‑sync 定義と実装のずれを検出する。
  • loop‑context 予算枠(コンテキスト)を監視し、超過時にサーキットブレーカーで停止させる。

これらは Claude Code、OpenAI Codex、Cursor など主要なコード生成エージェントに対応しています。


設計上の重要ポイントとリスク

重要ポイント(推奨事項)

  • 停止条件の明確化

    • 完了判定(例:テスト全通過)
    • リソース上限(イテレーション回数、トークン予算、実行時間)
    • エラー連続回数(同一失敗が 3 回続いたら人間にエスカレーション)
  • トークンコストの管理

    • 自律ループは標準的なチャットに比べて 4 倍以上、マルチエージェント構成では 15 倍以上のトークンが消費されることが報告されています(例:Claude Code が 1,000 トークンで単一タスクを実行した場合、Loop 版は約 4,200 トークン、3 エージェント構成では約 15,000 トークン)。
    • loop‑cost で事前に見積もり、上限を設定すると安全です。
  • 作成者と検証者のパターンの採用

    • 生成モデルは自分の出力を甘く評価しがちです。別モデルまたは別インスタンスで検証させることで品質を確保します。
  • 状態管理(Memory)

    • エージェントはセッション間で記憶しないため、永続化しないと「前回の続き」が失われます。
    • 状態ファイルが肥大化するとコンテキストが腐敗する恐れがあるため、定期的に圧縮や古いログのアーカイブを行います。
  • 段階的自律レベルの導入

    • L1(レポートのみ) エージェントは結果を人間に提示し、承認待ち。
    • L2(支援付き修正) 自動修正案を提示し、人間の承認でマージ。
    • L3(完全無人) 全工程(トリアージ→デプロイ)を自走し、失敗時は自動エスカレーション。
    • 各レベルへの移行は「成功率 ≥ 95 %」かつ「トークン予算使用率 ≤ 80 %」などの指標で判断します。

想定されるリスクと対策

  • コスト増大 トークン消費が増えるため、予算管理を徹底する。
  • 品質低下 検証エージェントが不十分な場合は、テストカバレッジやレビュー基準を強化する。
  • 状態ファイルの肥大化 定期的にログをローテーションし、必要な情報だけを保持する。
  • 停止条件の曖昧さ 部分的成功や品質基準の緩みが生じた場合のハンドオフ基準を事前に定義しておく。

エンジニアの役割変化

  • 従来 指示文を書いてエージェントを呼び出す → 手作業でコードレビュー → 単発タスクを実装。
  • 新しい役割 ループの設計・停止条件・ガードレールの定義 → 作成者と検証者の構築と評価基準の策定 → 複数タスクを横断する自律フローのオーケストレーション。

実務では「どこで人が介入し、どこでシステムが自走するか」を明確に描くことが最も重要です。


まとめ

  • Loop エンジニアリングは 指示文作成の自動化ループ全体の設計・監視 を同時に実現する手法です。
  • 6 要素(自動化、作業ツリー、スキル、プラグイン・コネクタ、サブエージェント、状態・記憶)を組み合わせ、作成者と検証者のパターンが品質確保の鍵となります。
  • 個人プロジェクトの Markdown 状態管理から、企業レベルの Slack 監視・PR 自動修正まで、幅広い活用例が報告されています。
  • 設計時は 停止条件、トークンコスト、状態管理 をしっかり定義し、段階的に自律度を上げることが成功のポイントです。
  • エンジニアは「コードを書く」から「ループを設計・監視する」へと役割がシフトし、一部のケースでは 10 倍以上の効率向上が報告されています(詳細は別レポート参照)。

まずは小規模な「毎朝の Issue トリアージ」ループから試してみましょう。自律的にタスクが回る感覚を体感すれば、Loop エンジニアリングの価値を実感できるはずです。