ループ・エンジニアリングとは。1人でチーム級の量を支える完了の定義と停止条件

コラム一覧へ戻る

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

これまでのAIの使い方は、1回ずつ指示を出して、返ってきた出力を人が受け取る形が中心でした。ここを変えるのが、達成したい状態（goal）、正しさの確かめ方（verification）、どうなったら止めるか（stop condition）を先に決めて、あとは「実行して、結果を確かめて、ずれていれば直す」というくり返しをAI自身に任せる使い方です。この「推論と行動を交互にくり返す」形は、2022年の研究「ReAct」がAIエージェントの基本形として示したもので、開発者はこうしたループを設計する作業を「ループ・エンジニアリング（loop engineering）」と呼びます¹。

Anthropicは、Claude Codeのドキュメントで、確かめる手段をAIに渡すと何が変わるかを説明しています。チェックがなければ「作業が終わったように見える」ことだけが手がかりになり、人自身が検証ループになって、ミスは人が気づくまで止まりません。合否を返すものを与えれば、ループはひとりでに閉じ、AIが作業し、チェックを走らせ、結果を読み、通るまでくり返す、と書いています²。ここで人は、1つずつ手を動かす役から、確かめ方を決めて結果の証拠を見る役へ移ります。1人でチーム級の量が語られるのは、この設計を先に置いているからで、速く打てるからではありません。

量が増えるのは、能力ではなく滞りを見落とさない設計があるから

1人で多くの作業を並行させても回るのは、全部を見張っているからではありません。常に見張らなくても滞りに気づける設計を、先に置いているからです。ループ・エンジニアリングの3点は、業務の言葉に置き換えられます。

• 完了の定義（goal）。何をもって終わりとするか。曖昧だと、出力が合っているかを毎回人が最初から読み直すことになり、量が増えるほど確認で詰まります。
• 人が確認する場所（verification）。どの段階で、どう正しさを確かめるか。決めていないと、全部を確認するか、逆に何も見ずに通すかの両極に振れます。
• 停止条件（stop condition）。どうなったら止めて人へ戻すか。決めていないと、依頼がずれたまま進み、後から巻き戻す範囲が大きくなります。

この3つがあると、人は作業の全部を追わなくても、止まった依頼と進んでいる依頼を見分けられます。見分けられるから、次の作業に手を回せます。量は、頑張って増えるのではなく、滞りを見落とさない状態を保てるから増えます。

先に決めた設計は、他人にも渡せる

ここで出る反論があります。「結局その人が優秀なだけで、うちでは再現できない」というものです。これは、量を勘で回している場合には当たります。頭の中だけで完了と止めどきを判断しているなら、本人が休むと止まり、他の人は同じ結果を出せません。これは担当者が1人に張り付く属人化そのものです。

一方で、完了の定義と停止条件を文章にして外に出していれば、同じ設計を別の人が使えます。Anthropicのドキュメントも、作業した本人ではなく別の担当に差分だけを見せて確かめさせるやり方や、「確かめられないなら出荷しない」という原則を挙げています³。確かめ方が文章と手順になっているほど、作業した本人以外でも同じ判断ができます。1人でチーム級の量を出すために書いた設計は、そのまま複数人で回すための設計になります。だから量が個人に閉じません。AIに任せる範囲を広げる作業は、属人化を進める作業に見えて、実際は逆へ向かわせられます。判断の基準を人の頭から出して、他人が読める形にする作業だからです。

PATHWORKでの扱い方

この3つは、AIを動かすツールを選ぶより前に、運用の側で決められます。PATHWORKでは、依頼ごとに状態・責任・期限を1つの画面で扱います。完了の定義は依頼の完了状態として明示し、人が確認する場所は次に動く人と承認の段階として置き、停止条件と確認の記録は同じ依頼の中に残します。

こうすると、AIに任せた作業も人が進める作業も、同じ場所で滞りを把握できます。誰が次に動くかと、どこまで進んだかが1画面に並ぶので、量を増やしても、宙に浮いた依頼を後から探し直さずにすみます。

ただし、すべての作業に当てはまるわけではありません。完了を言葉にできない探索的な作業や、判断の基準がまだ固まっていない依頼では、完了の定義も停止条件も書ききれません。そこは無理に任せず、人が判断を担います。設計できる作業から順に外へ出す、という進め方になります。

任せる量を増やす前に確認したい項目

• その依頼の「完了」を1文で書けるか。
• 人が確認する段階は、どこに置くか。
• どうなったら止めて人へ戻すか（停止条件）。
• 完了の定義と確認の記録を、他人が読める場所に残しているか。

まとめ

ループ・エンジニアリングは、達成状態と確かめ方と止める条件を先に決めて、くり返しをAIに任せる設計です。1人でチーム級の量が出るのは能力の差ではなく、この完了の定義・確認する場所・停止条件を先に置いて、滞りを見落とさない状態を作っているからです。しかもその設計は文章にして外に出せば、本人以外にも渡せます。当てはまらないのは、完了を言葉にできない探索的な作業や、判断基準が固まっていない依頼で、そこは人が担います。まず手元の1つの依頼で、完了を1文にし、確認の段階と停止条件を書いてみる。別の人がそれを読んで同じ結果を出せるかどうかが、量を個人に閉じ込めずに増やせるかの分かれ目になります。

参考

本文中の番号をクリックすると、その数字の根拠にした原文にジャンプします。原文は改変せず、そのまま載せています。

1. Shunyu Yao ほか「ReAct: Synergizing Reasoning and Acting in Language Models」arXiv:2210.03629（2022）

   we explore the use of LLMs to generate both reasoning traces and task-specific actions in an interleaved manner, allowing for greater synergy between the two

   論文アブストラクト（本文の「推論と行動を交互にくり返す」の根拠） 本文の該当箇所へ戻る
2. Best practices for Claude Code（Claude Code Docs／Anthropic）

   Claude stops when the work looks done. Without a check it can run, "looks done" is the only signal available, and you become the verification loop: every mistake waits for you to notice it. Give Claude something that produces a pass or fail, and the loop closes on its own. Claude does the work, runs the check, reads the result, and iterates until the check passes.

   Give Claude a way to verify its work の節（本文の「人自身が検証ループになって」「ループはひとりでに閉じ」の根拠） 本文の該当箇所へ戻る
3. Best practices for Claude Code（Claude Code Docs／Anthropic）

   A reviewer running in a fresh subagent context sees only the diff and the criteria you give it, not the reasoning that produced the change, so it evaluates the result on its own terms. ... Always provide verification (tests, scripts, screenshots). If you can't verify it, don't ship it.

   Add an adversarial review step / Avoid common failure patterns の節（本文の「別の担当に差分だけを見せて確かめさせる」「確かめられないなら出荷しない」の根拠） 本文の該当箇所へ戻る