AIエージェント周辺のキーワードが、この数か月で一気に増えました。AGENTS.md、Skill、/goal、CLI、Memory、Loop、Automation、OpenClaw、Hermes、エージェントオーケストレーションといった概念が飛び交い、Codex、Claude Code、Sakana Fuguのようなツール名も次々と登場しています。
AIエージェントと作業することが当たり前になり、AIとの対話は「チャットで質問する」だけのものではなくなっています。AIに頼めば形になる、という場面が増えていると感じている読者の方も多いはずです。
そして、エージェントの性能が上がり「頼めばやってくれる」場面が広がるほど、次にボトルネックになるのは別のところです。AIに何をさせたいかを伝え、コンテキストを渡し、できたものを見て、フィードバックを返すというサイクルが生まれます。やりたいこと、コンテキスト、フィードバックという3つの要素を、正確に、速く、崩れにくい形で回す。そうした実践がXなどで「Loop Engineering（ループエンジニアリング）」と呼ばれ始めています。
この記事では、Loop Engineeringを初級編としてまとめていきます。後半では、AGIラボの中でも実践しているサイト改善のループもSkill付きでご紹介します。
それでは早速みていきましょう！
要点
Loop Engineeringでは、良いプロンプトに加えて、目標、検証、状態、制約、停止条件をひとつの循環として設計します。
Codexの /goal は、その入口になります。 「何を作るか」に加えて「何を証拠に完了とするか」まで書くと、人間があとから見直す範囲が小さくなります。
実際に試すと、最初に必要だったのは実装ではなく現在地の固定でした。 どのソースが正か、どこまでをActionsに任せるか、どこで人間判断に戻すかを決めないと、ループはすぐに曖昧になります。
Loop Engineeringとは何か
発端になった投稿を3つ見てみましょう。
3人の表現は異なりますが、共通点は
「AIに何を入力するか」ではなく、「AIに入力が届き続ける仕組みをどう設計するか」が問われている、ということです。
ウェブサイト改善を例に考えてみます。
これまでの使い方では、人間がサイトにアクセスしてチャットを開き、「このバグを直してください」と頼み、結果を確認して、さらにフィードバックを送っていました。常に人間が起点です。
Loop Engineeringの発想では、この構造が変わります。GitHubのissueにバグ報告が届きます。ユーザーが書くこともあれば、AIエージェントがコミュニティを巡回して抽出することもあるでしょう。15分おきに動くトリガーが ai-agent ラベルのついたissueを検出し、予算と停止条件の範囲内で修正を試みます。テストが通れば完了し、通らなければログを残して次の実行に引き継ぐ仕組みです。
人間はissueを書き、コミュニティで仕様を議論し、PRをレビューしてマージします。ループの起点は、人間が「チャットを開く」という直接的な動作ではなく、issueやトリガーという仕組みに移っています。
エンジニアだけの話ではない
ここまでの例は開発寄りな内容でしたが、ループの設計はエンジニアだけに関わるテーマではありません。
OpenAIは公式ホワイトペーパーの「Codex-maxxing for long-running work」の中で、3つのループの事例を紹介しています。
Chief of Staff: Codexがスケジュールに沿ってSlackとGmailを確認し、注意が必要なメッセージを見つけ、背景を調べ、返信の下訳を作ります。
送信するかどうかは人間が判断します。
プロンプト例：30分ごとにSlackとGmailを確認し、私の注意が必要な返信メッセージを探してください。 最も重要なものを優先付けるのを手伝ってください。 質問があれば聞いてください。 できる限り答えを調べて、私のために返信を作成してください。 実際の送信はしないでください。
Monitor for feedback: Slackスレッドに届いたアニメーションへのフィードバックをCodexが拾い、Remotionプロジェクトを更新し、再レンダリングし、修正版を用意します。
Slack、Remotion、GUI操作をまたぐループですが、クリエイティブ判断や公開判断は人間が行います。
プロンプト例：平日の朝は毎日、以下のフィードバックソースを確認してください。
参照先：[Slackチャンネル：https://app.slack.com/huddle/E03025Z7DT4/DOB6BLUHPND]
- 変更内容
- フィードバックの主なテーマ
- シートへのリンク
- 必要な決定事項、またはフォローアップ
※これは下書きです。投稿しないでください。
Get a refund: カスタマーサポートの担当者が参加したかをCodexが確認し、会話に変化があれば次の返信案を用意します。
同意や承認、取り消せない操作は人間に残します。
プロンプト例：5分おきに、カスタマーサポートがこのスレッドに参加したか確認してください。もし参加していたら、返金してもらえるよう最善を尽くしてください。相手から返信があった後は、より迅速に対応できるよう、確認の間隔を1分おきに切り替えてください。
3つに共通するのは、AIが自律的に情報を取りに行き、下準備を済ませ、判断だけを人間に委ねる仕組みを構築することです。コードを書けなくても、自分の業務でこの構造は作っていけます。
それは定期実行ではないのか
「ただの定期実行では？」と感じた人もいるのではないでしょうか。
その直感は、ある意味で正しいと言えます。技術的には、Loop Engineeringの多くはcronのような定期実行の仕組みの上に成り立っています。
ただし、単なる定期実行だけでは不十分です。何を目標にするか、どこに状態を保存するか、どんな条件で停止させるか、そして停止した理由をいかに次の実行へと引き継ぐか。そうした設計が伴わなければ、それは同じ作業を繰り返すだけのスクリプトに過ぎません。
OpenClawの開発者であるPeter Steinbergerも、過去の対談の中でこの点について触れています。
出典: Lex Fridman Podcast - Peter Steinberger該当シーン
/goal はループそのものではない
Codexの /goal をLoop Engineeringの代名詞のように扱う説明を見かけます。OpenAIの説明では確かに、Codexの /goal 機能は、単なる1回限りのプロンプトではありません。検証可能な停止条件に向かって、作業し、確認し、続けるか止まるかを判断する「内側のループ」です。
ただし、この記事で扱うLoop Engineeringは、/goal より広い範囲を指します。メールやIssueをいつ読むか、どの状態ファイルを参照するか、どのWorkerに渡すか、PR後にどこで人間の判断へ戻すかまで含めて設計します。
つまり、/goal はループ設計の重要な部品ですが、AutomationやHeartbeat、状態管理、人間ゲートを含む「外側の仕組み」そのものではありません。
継続的に回る運用ループにするには、さらに「いつ起動するか」「何を読んで再開するか」「どこまで進めたら止まるか」が必要になります。/goal は、1本の長時間タスクに対する到達目標と停止条件を定義する道具です。一方、AutomationやHeartbeatは、その作業を必要なタイミングで起動・再開・継続させるための外側の仕組みです。
良いループの6つの部品
GoogleのAddy Osmaniは、ループを構成する部品を5つ＋Memoryとして整理しています。
1. Automations
AIエージェントをいつ起動するかを決める仕組みです。
15分おきに走る、issueが作られたら走る、PRが作られたら走るといった条件を設定します。
Claude CodeではRoutine、CodexではAutomation、OpenClawではHeartbeatやcronと呼ばれています。
2. Worktrees（Isolation）
エージェント同士が並列で作業するとき、互いの変更が衝突しないように分離する仕組みです。
Gitを使ったことがある方なら、Git worktreeがそのままイメージになります。
非エンジニアの方には、こう考えてください。
複数人が同じ机で同時に作業すると書類が混ざります。
一人に一つずつ机を渡して、終わったら成果だけ持ち寄るようにすれば、互いの作業は干渉しません。
Worktreeは、その机の割り当てに当たります。
3. Skills
AIエージェントに渡す、仕事ごとの手順書です。
毎回「このプロジェクトではこうしてください」と伝え直す代わりに、ルールや手順をMarkdownファイルに書き出しておきます。
エージェントが毎回それを読むことで、指示のばらつきが減ります。
AGIラボの解説記事
4. Plugins and connectors
AIエージェントが外部ツールにアクセスするための接続です。
GitHubを読む、Slackを見る、Gmailを確認する、データベースを参照するといった操作に使います。
AGIラボで先日行った「あやみさんによるClaude Code仕事術」の講座で、あやみさんが「業務の中のコピペを消す」という見方を紹介していました。
ChatGPT的な使い方では、AIがチャットに作業結果を出し、人間がそれを別のツールにコピペする必要がありました。
メールからスプレッドシートへの転記、議事録のNotionまとめとSlack共有、サービス間のダウンロード・アップロードなど、純粋なコピー&ペーストでなくても人間がツール間の橋渡しをしている作業は同じ構造です。
コネクターがあると、AIがツールに直接読み書きできるため、この橋渡しが不要になります。
詳しくはAGIラボの講座ページ「Claude Code仕事術」をチェックしてみてください。
5. Sub-agents
1つのエージェントが自分の作業を自分で評価すると、レビューが甘くなる傾向があります。
別のエージェントに独立してレビューさせることで、見落としを減らせます。
6. Memory
エージェントが前回の実行結果を参照できるようにする仕組みです。
前回何を試したか、どこで失敗したか、次に何をすべきかといった情報が、会話の中だけにあると次の実行で消えてしまいます。
Markdownファイル、issue、スプレッドシートなど、会話の外に状態を残す手段が必要です。
この6部品は、ループを走らせるための実装パーツです。
一方、ループの設計段階では、別の軸の問いも立てることになります。
実際にModel Radarで回してみた
ここからは、AGIラボでループを組んでみました。
対象は、AGIラボが開発しているモデルリリース予測サイト「AGIレーダー」です。
DiscordコミュニティにはAGIラボの読者から「このモデルも見たい」「このシリーズも入れてほしい」という投稿が届きます。
今回は、『Codexがその声を拾い、モデル候補として整理し、公式情報でリサーチし、追加できそうなら実装PRまで作る』というようなループを目指しました。
