AI業界ではいつの頃からか、「XXエンジニアリング」という表現を頻繁に目にするようになりました。昨年まではXXに「プロンプト」や「コンテキスト」が入り、今年は「ハーネス」と「ループ」、最近では「グラフ」も登場しています。今回は、少し流行が過ぎた感もある（？）「ループエンジニアリング」についての私の考えと経験、そしてAX共有会を通じてCorcaが組織内でどのようにループを回しているのかをご紹介します。結論から言えば、「エージェントのためのループ設計」と「組織の週次イベント設計」を効果的にする方法は、驚くほど似ていると考えています。
ループは単なる流行ではなく「本物」だ
開発者の方なら「ループ」と聞いて、forやwhileのような反復処理を思い浮かべるでしょう。最近では、ヒューマン・イン・ザ・ループ、ヒューマン・オン・ザ・ループ、そしてループエンジニアリングのように、より広い文脈で使われ始めています。
この広い意味でのループを本格的に広めた一人が、Claude Codeを率いるBoris Chernyです。2026年6月17日、Metaの@Scaleカンファレンスで行われた聴衆との質疑応答でも、最初の質問はループに関するものでした。
「ループは次のハイプサイクルにすぎないのでしょうか。それとも本物なのでしょうか？」
Chernyの答えは明快でした。
「ループは本物です。2年前まで、私たちはソースコードを手で直接書いていました。その後、エージェントにコードを書かせるようになりました。今は、エージェントが別のエージェントにプロンプトを送り、そのエージェントがコードを書く段階へ移りつつあります。ソースコードからエージェントへの移行が大きかったのと同じく、ループもそれに劣らず重要で大きな飛躍です。」
それを裏付けるように、主要なコーディングエージェントには現在goal機能が組み込まれ、誰でも簡単にループを回せます。一度プロンプトを実行して終わるのではなく「目標」を有効にする機能です。エージェントは完了条件が満たされるまで、次の行動を自ら設計して繰り返します。
Corcaでも数か月前からgoalを非常に積極的に使っています。あるリポジトリでは大胆な目標を設定し、数十時間自律実行するエージェントを時々ステアリングします。別のリポジトリではフィードバック周期の短い仕事を任せます。どちらも今では当たり前になり、コーディングの姿がまた大きく変わりました。
しかし、ループは万能ではない
ループが大きな飛躍だというChernyの意見には強く共感しますが、もちろん万能ではありません。終わらない無限ループは、コーディングで最も避けたい問題の一つです。私もgoalを使い始めた頃、Codexに「開いているIssueをすべて閉じよ」という粗い目標を与え、30時間もトークンを消費し続けたため強制終了したことがあります。反対に、長く動くと思って寝たのに、朝には「承認が必要だが3回応答がなかったため中断しました」で終わっていて、落胆したことも何度もあります。
こうした失望を避け、ループをより効果的に設計・実行したいという欲求から、「ループ」に「エンジニアリング」が付いたのかもしれません。私なりに整理した効果的なループエンジニアリングの必要条件は次のとおりです。
- エージェントが自らループを「閉じる」ための検証ツールと権限を適切に与える（リンター、ベンチマーク、ブラウザ検証ハーネス、独立エージェントによる必須レビュー、特定URLへの外部書き込み許可など）。
- 実装の完了を機械的に判定できるようにする（実行時間、全テスト合格、カバレッジ目標など）。
- 実装と検証をできるだけ低コストかつ短時間で行えるようにする（設計は賢く遅いモデル、実装は安く速いモデルで並列化、可能ならエージェントではなく決定論的コードを使う、停止条件と予算条件を定めるなど）。
- 検証に失敗したら、現象ではなく本質を直して自己改善する（単純な再試行ではなく構造的パターンを改善し、記憶ではなくAGENTS.mdや文書にルールとして残し、検証器自体のロジックと範囲も改善対象にするなど）。
- エージェントの進行と成果を、人が観察・介入・レビューしやすくする（意思決定と結果をファイルに残す、判断が必要なら止まって質問する、HTMLやMermaidで状態を可視化するなど）。
この一覧は自分の経験だけでまとめたものでしたが、調べるとAnthropicのループ入門ガイドやGoogleのAddy Osmaniも似た点を挙げています。Anthropicは、エージェントに結果を見て測定し操作できるツールを与えること、定量的な検証ほど自己検証しやすいこと、テスト合格数やスコア閾値のような決定論的基準が有効だと述べます。OsmaniはLoop Engineeringで、ループを自動化・ワークツリー・スキル・コネクター・サブエージェントの5要素に分け、その土台に会話の外に残る「外部メモリ」を第6の要素として置いています。
Corcaでも、こうした条件を整えてより良いループを回すノウハウを共有することが増えています。「ループを設計する」「ループを閉じる」という表現も頻繁に使うようになりました。コードのループ概念をエージェントのレベルへ引き上げて話すことが、ごく自然になったのです。
ところが、この5項目を書いてみると、どこか見覚えがありました。Corcaはさらに高い組織レベルでも、すでに似たループを回していました。毎週木曜の朝に行うAX共有会がその仕組みです。
組織にもループがあった：AX共有会の昨日と今日
AX共有会の前身は、昨年11月に始まった「エージェンティックエンジニアリング週次振り返り」です。Moonlightチームと、AIを使って製品の技術的負債を返す実践方法を共有しました。しかし製品チームには目前の機能修正やリリースがより重要なため、私を含むAXを本業とする数人が主導する印象が強くありました。コード品質を高める環境と小さな実践は少しずつ生まれましたが、変化はそれほど速くありませんでした。（この経験をもとに、Claude Code Meetupで「レガシーコードベースでエージェントと人の双方が成果を出せる環境づくり」という発表もしました。）
それでも全社的な雰囲気が整い、今年2〜3月に「エージェンティックエンジニアリング共有会」を経て「AX共有会」へ改称すると、雪だるまが転がり始めました。特定の誰かや一つのチームだけの場ではなくなり、全社員が毎週木曜の朝に集まり、3人ずつ最近のAI実験と試行錯誤を共有しました。新しく作った社内ツールを披露する人、最近読んだ本やカンファレンスの要約、話題のスキルやツールの使用記を紹介する人もいました。いつしか、Corca全体にAXを広げ、新入社員のオンボーディングも助ける大切なイベントになりました。
AX共有会で組織のループを回す
AX共有会は今ではCorcaに定着していますが、ここまでには多くの紆余曲折がありました。特に「週次イベントを形式的な時間ではなく、個人と組織の双方にとって本当に意味のある時間にするには？」を考え続けました。初期には議論と実験を重ね、より有益な形式へ進化させました。
そうして安定した2026年8月時点の形式は次のとおりです。所要時間はちょうど1時間です。
- 前回の振り返りで書いた「次の1週間で試すこと」を本当に実践したか、どう実践したか、その他話したいことを自由に共有します。
- 今週の共有者3人が自分の話をし、「これを一つ実験・実践してみてください！」を残します。
- 各自が今日の感想を振り返り、「次の1週間で試すこと」を書きます。
表面的には2番が中心に見えますが、実は2番は呼び水で、それを囲む1番と3番が重要でした。そうすることで、誰かが主導する「セミナー」ではなく、全員で行う「共有会」となり、個人と組織が継続的に成長できるからです。そこで、3つのタイミングに使う文化的な仕掛けが徐々に発展しました。
- 共有会の終了時：振り返りの「試すこと」が小さく明確でなければ、やんわり突っ込まれます。（「Aさん、本当にできますか？」「Bさん、試すことがありませんよ」「Cさん、完了したとどう判断しますか？」）
- 共有会の間：Corcaのエージェント同僚Cealが振り返りをもとにリマインドします。翌日には各自の予定をまとめたスレッドを開き、:done:の反応もコメントもない人へ最大2回DMし、「こんなに小さくてもいいので試してみてください」と声をかけます。Cealが故障してメッセージを送れないと、メンバーは冗談で「Cealに催促されなかったからできなかった」と言います。
- 共有会の開始時：一人ずつ率直に尋ねます。「やりましたか？何をしましたか？なぜできませんでしたか？何週間もできていませんね。今週はどうしますか？」かなりの圧力なので、木曜の朝に慌てて少しでも試す人もいます。申し訳なく思いつつ、私は前向きな副作用だと考えています。「木曜日は何かを試す日」という小さな共通習慣が生まれたとも言えます。
この形式と仕掛けは、先ほどの「効果的なループエンジニアリングの必要条件」とよく似ています。
| 効果的なループの必要条件 | エージェントループでは | AX共有会では |
|---|---|---|
| ① ループを閉じる検証ツールと権限 | リンター、テスト、ベンチマーク、ブラウザハーネス、独立エージェントのレビュー | 木曜朝に一人ずつ「やりましたか？」と尋ね、反応のない人へCealがDMする |
| ② 機械的な完了判定 | 全テスト合格、カバレッジN%以上 | 共有会の開始と終了における前向きかつ組織的な圧力 |
| ③ 少ないコストと時間 | 設計は遅いモデル、実装は速いモデルで並列化、停止条件と予算 | 1時間固定、共有者は3人、既存のSlack上で運用し、Cealと同僚が「小さくても試す」よう行動単位を縮める |
| ④ 失敗時に本質を直す | 再試行ではなくパターンを直し、AGENTS.mdと文書にルールを反映 | 同じ人が続けてできない時、さらに催促せず、突っ込み・Ceal・開始時の質問など形式と仕掛けを直して翌週へ反映 |
| ⑤ 観察・介入・レビュー可能性 | 意思決定と結果をファイルに残し、状態を可視化 | 振り返りと実践をNotionとSlackスレッドという皆がよく見る場所に集約 |
表を埋めながら、私自身が新たに気づいたのは①と④でした。自分の振り返りを自分で採点せず、木曜朝に同僚が尋ねる構造は、実装エージェントとレビューエージェントの分離に似ています。また、誰かが何週間も実践できない時、その人をさらに急かすのではなく「形式が何を見落としたか」を考えて仕掛けを直すことは、個別の失敗を取り繕わずルールへ反映することに近いのです。Cealのリマインドや開始時の質問も、こうして一つずつ生まれました。
こじつけに見えるかもしれませんが、この類似は偶然ではないと思います。どちらも「自律的に動く主体へ、明確な完了基準とフィードバックを与える問題」だからです。主体が人でもエージェントでも、基準とフィードバックがなければ終わらないループに陥るか、曖昧に終わります。ループを回すエージェントと人の双方に、適切な支援が必要です。
おわりに
ループの本質は、長時間回すことではありません。人の明確な意図をエージェントが優れた形で代行し、より短い時間で望む品質の仕事を完了することが重要です。そのためには、実行主体（人とエージェントの能力）と環境（ループエンジニアリングの方法論）の双方が継続的に発展する必要があります。
同じく、組織の週次会議、1on1、AX共有会のような反復イベントの本質は形式の維持ではなく、そのイベントが目指す目的を確実に果たすことです。目的達成に必要な時間とエネルギーは徐々に減るべきで、そのためには主体と環境が共に発展しなければなりません。現在のAX共有会も2026年8月のある日のスナップショットにすぎません。これからも面白い実験と挑戦を続けます。
皆さんの組織の反復イベントには「閉じる条件」がありますか？エージェント向けのループエンジニアリング思想のうち、自分や組織にはまだ適用できていないものがないか、振り返ってみてはいかがでしょうか。