2026.07.03

ループエンジニアリングってなんだ?

AI h-sugiyama

ループエンジニアリングとは

https://addyosmani.com/blog/loop-engineering

上記記事によると

エージェントハーネスエンジニアリング
これは単一のエージェントが内部で動作する環境とソフトウェアを構築するシステムであるファクトリーモデルを作成するもの
ループエンジニアリングはハーネスの一階層上に存在する
今までは人間がプロンプトを入力しAIが出力し人間が確認しまたプロンプトを打つという流れの「ターン制」が主流
しかし現在では「人間に変わってエージェントを駆動する自動化されたループを設計(システム)をすること」になっている
AnthropicのClaudeCode責任者も「Claudeに直接プロンプトを打っていない、Caludeを動かすループを走らせており私の仕事はループを描くことだ」と述べている

詰まるところAIを自動化し、駆動させるためのインフラを整えるイメージでしょうか

ループの要素 5個+1個

ループには5つの要素とそれらを記憶しておくメモリが必要

自動化

スケジュールに基づいて自動的に起動し、検出とトリアージを行う自動化システム
具体的には
定期的に（スケジュールやフック、GitHub Actionsなどで）起動し、CIエラーの要約やバグハンティング、Issueのトリアージを自律的に行う。条件が達成されるまで回り続ける

ワークツリー

ワークツリーを使用することで、2人のエージェントが並行して作業しても互いに干渉し合うことがなくなる
具体的には
複数のAIエージェントが並行して動く際、同じファイルを同時に書き換えて衝突（コンフリクト）しないよう、git worktree等を用いて環境を完全に隔離する

スキル

エージェントが推測するにとどまるようなプロジェクトに関する知識を書き留めるスキル。
具体的には
エージェントが毎回プロジェクトの前提やルールを忘れないよう、SKILL.mdなどのファイルにビルド手順や「この設計は過去の障害から禁止」といった文脈（コンテキスト）をアセット化しておく

ツールを接続

エージェントを既存のツールに接続するためのプラグインとコネクタ
具体的には
MCP（Model Context Protocol）などを利用し、AIがファイルシステムだけでなく、GitHub、Linear（タスク管理）、Slack等と連携できるようにする。「修正コードを書き、PRを出し、Linearのチケットを更新してSlackに通知する」までを繋ぐ

アイデアを出し、検証する

サブエージェントなので、1人がアイデアを持ち、別のサブエージェントがそれを検証する
具体的には
コードを書くAI（Maker）自身にテストや検証をさせると、自分の間違いに気づきにくい（自分に甘くなる）。そのため、「実装するエージェント」と「検証・レビューするエージェント（Verifier）」を明確に分ける

メモリ

マークダウンファイルやリニアボードなど、単一の会話とは別に存在し、完了した内容と次に行うべき内容を保持するもの
具体的には
AIモデルはセッションごとにコンテキストを忘れてしまうため、何が完了し、何が次に必要なのかをAGENTS.mdやLinearのボードなど「ディスク上（外部）」に状態として保存しておく。

ループが回る具体的なワークフローの例

著者が実際に活用している具体的なループの形は以下のようなもの

毎朝、Automationがリポジトリで起動する
トリアージのSkillを使い、前日のCI失敗やIssueを読み込んでタスク化する
修正すべきタスクごとに、隔離されたWorktreeを開く
1つ目のSub-agentがコードを修正（実装）する
2つ目のSub-agentがプロジェクトの共通ルール（Skills）やテストと照らし合わせてレビューする
パスすればConnector経由で自動でPRを作成し、タスク管理ツールを更新する

ループエンジニアリングにおける「人間の役割」と新たな課題

AIが自律的にループしてコードを書きまくる時代になっても、エンジニア（人間）が不要になるわけではなく、むしろエンジニアの真価が問われるようになります。著者は以下の3つのリスク（負債）を警告している

検証責任（Verification）は人間に残る
理解の腐敗（Comprehension Debt / 理解債）
認知の放棄（Cognitive Surrender）

本質：楽になるのではない、注力する点が変わっただけ

著者のAddy Osmani氏がこの記事で最も伝えたかった本質は、「自動化ループにすべてを丸投げして楽をすることではない」ということ
また必ずしもループエンジニアリングが絶対的であるとは述べていない
提示された言葉の中に、私たちがこれからAIと向き合う上での重要な指針がすべて詰まっている。またループは、使い方によって異なる結果をもたらす可能性がある

2人が全く同じループを作成しても、結果は正反対になることがあります。一方は、深く理解している作業をより速く進めるためにループを使用し、もう一方は、作業内容を全く理解しないためにループを使用します。

自動化されたループは強力だが、人間がコードをレビューしなくなったり、修正をループだけに頼り切ったりすれば、製品の品質は間違いなく低下し、悪循環に陥ってしまう
時にはエージェントに直接プロンプトで指示を出す方が効果的な場面もあり、「適切なバランスを見つけること」が不可欠
ループ設計がプロンプトエンジニアリングよりも難しいのは、まさにこの点にある。チェルニー(※原著等で言及されているエンジニア）の主張は、作業が楽になったということではなく、注力するポイントが変わったということ

プロンプトのテクニックを磨く時代から、システム（ループ）を設計する時代へ。私たちの仕事の「注力する場所」が変わっただけで、エンジニアとしての思考や責任の重さは変わらない、むしろ難易度は上がっていると言える