訪問看護の現場で新人OTに同行指導をするとき、私が最初に決めるのは「どこまで本人に任せ、どこで私を呼ばせるか」だ。優秀さに賭けるのではなく、報告のタイミング、判断を仰ぐ基準、何をもって訪問完了とするかを先に決めておく。そうすれば、本人が多少つまずいても全体は崩れない。人に仕事を任せたことのある人なら、誰でもやっていることだ。
ここ数日、AI開発の世界で「ループエンジニアリング」という言葉が一気に広まった。読んでいて私が抱いたのは、新しさへの驚きではなく、奇妙な既視感だった。つまり、いま語られているループエンジニアリングは、私には「新発明」というより、別の分野で組織論と同じ構造が立ち上がっている現象に見える。
ループエンジニアリングとは何か
きっかけは、AnthropicでClaude Codeを率いるBoris Chernyの一言だった。「私はもうClaudeにプロンプトを書かない。私の仕事はループを書くことだ」。ほぼ同時期に、OpenClaw創業者で現在OpenAIに所属するPeter Steinbergerも、エージェントに直接プロンプトを書くのではなくエージェントを動かすループを設計せよ、と投稿し、数百万回読まれた。これを「ループエンジニアリング」として整理し広めたのが、GoogleのAddy Osmaniだ。一連の流れは開発者コミュニティで瞬く間に拡散し、激しい議論を呼んだ。
従来のプロンプトエンジニアリングが「一回で良い指示を作り、一回の応答をもらう」ことに重心を置くのに対し、ループエンジニアリングは「AIエージェントを反復して動かし、エージェント自身の判断でツールを使わせ、ゴール達成まで自走させる仕組みを設計する」ことに重心を置く。
重要なのは、これが単なる定期実行スクリプトではない点だ。毎回まっさらな状態で呼び出すのではなく、エージェントが文脈・権限・接続を保持し、前回の操作を踏まえて次の一手を進める。そして設計の核心は、何をもって成功とするか、どこで止めるか、いつ人間に判断を戻すかをあらかじめ決めておくことにある。
ここまで読んで、経営理論を学んでいる人は気づくはずだ。これは、組織を設計するときの話とほとんど同じ構造をしている。
組織論から見ると、既視感しかない
ループエンジニアリングが「新しい」とされる要素を組織論の語彙に翻訳すると、下図のようにほぼ一対一で対応する。
成功条件と停止条件を先に決めるのは、組織論でいう例外管理(management by exception)そのものだ。正常な範囲はそのまま進め、例外が起きたときだけ上に上げる。出力を別の仕組みで検証する発想は、内部統制でいう職務分掌（実行する主体と評価する主体を分け、相互に牽制させる）と重なり、一人の優秀さに依存せず構造でミスを捕まえる。必要なら人間に戻すのは権限委譲とエスカレーション基準の設計であり、どの線を越えたら上位者の判断を仰ぐかという線引きが、委譲という行為の本体だ。永続セッションで文脈を保持する要件は、まず組織記憶の問題だ。さらに、その経験を属人化させず形式知として記録し次の実行へ接続する過程は、野中郁次郎のSECIモデルが扱う知識変換とも重なる。組織記憶が「保持」を、SECIが「変換」を担うと整理すればよい。ループを標準化して回す思想は、ミンツバーグの調整メカニズムのうち作業プロセスの標準化（手順そのものを設計して品質を担保する）にあたる。
極めつけは、ループ設計者たちが繰り返す「賢さで解決しようとせず、構造で解決する」という原則だ。これはハーバート・サイモンの限定合理性を出発点とする組織観と完全に一致する。人間の認知には限界がある。だからこそ個人の賢さを当てにせず、限界を補う仕組みとして組織が存在する──サイモンが半世紀以上前に示した洞察だ。
つまりループエンジニアリングが語ることの大半は、組織論がとうの昔に体系化してきた知見の再発見である。
では、なぜエンジニアは今これを「発見」したのか
意地悪く終われば、ただの揚げ足取りだ。本当に面白いのは、「なぜソフトウェア工学は今になってこの知見を必要とし始めたのか」という問いのほうだ。
答えは、制御の対象が変わったからだと私は考えている。
これまでソフトウェア工学が相手にしてきたのは、決定論的なプログラムだった。同じ入力には必ず同じ出力を返し、間違えず、忘れず、暴走しない。こういう対象に、組織論的な発想は要らなかった。仕様を正しく書けば、その通りに動く。プロンプトエンジニアリングは、この「正しく書けば正しく動く」世界観の延長線上にあった。
ところがAIエージェントは違う。間違える。忘れる。文脈次第で振る舞いが変わり、放っておけば想定外の方向へ進む。これは決定論的な機械の性質ではなく、むしろ人間の性質に近い。
ここで初めて、サイモンの限定合理性が工学の問題になった。相手が確率的に間違える主体になった瞬間、「正しい仕様を書く」だけでは制御できなくなり、「間違える主体をどう前提に組み込み、どう手綱を握るか」という問いが立ち上がる。そしてこの問いへの知見は、工学ではなくマネジメントの側に蓄積されていた。そうした主体を協調させて成果を出させることは、組織が何千年も向き合ってきた課題そのものだからだ。
だからループエンジニアリングは、新発見というより、ソフトウェア工学がマネジメント論を輸入し始めた瞬間として捉えるほうが正確だと思う。もちろん工学側にも、制御理論・分散システム・ワークフロー設計・テスト自動化といった蓄積はある。だが、確率的に間違える主体を前提に「任せ方」そのものを設計する局面では、組織論の語彙が驚くほど効いてくる。エンジニアが試行錯誤の末に再発見している原則の多くは、経営学の教科書をめくれば最初から書いてある。
ただし、人材の組織論をそのまま当てはめてはいけない
ここまで「AIエージェントは人材に似ている」と書いてきたが、安易に同一視すると足をすくわれる。両者には決定的な差分がある（下図）。
AIエージェントには動機づけが要らない。人材マネジメントの中核はやる気を引き出し離職を防ぐことにあるが、エージェントにモチベーションも不満もなく、ハーズバーグもマズローも出番がない。疲労もしないから、労働時間や負荷という制約条件が外れ、むしろ設計の自由度が上がる。ただし疲労しない代わりに、トークンコストや文脈劣化、誤作動の蓄積が新たな管理対象になる。一方で忘却がデフォルトであり、人間は黙っていても経験を覚えているが、エージェントは文脈を保持する仕組みを作らない限り毎回まっさらに戻る。組織記憶が「自然に溜まる」のではなく「設計しないと存在しない」のだ。さらに追加コストがきわめて小さく、複数のエージェントに同じ仕事をさせて結果を突き合わせるような、人間の組織ではありえない冗長設計が合理的な選択肢になる。
これらの差分を無視して「AIも人と同じ」と語るのは雑だ。正しくは、組織論は強力な出発点になるが、終着点ではない。人間向けに最適化された前提の一部は外し、AI特有の性質に合わせて作り直す必要がある。
AIにループを任せる前に、最低限決めるべき5つの問い
最後に実務へ落とす。新人に仕事を任せるときの三つ（報告のタイミング・判断基準・完了の定義）をAIエージェント向けに広げると、最低限の問いは次の5つだ。これだけ決めておけば、暴走と空回りの大半は防げる。
- 何をもって成功とするか（成功条件の定義）
- どこで止めるか（停止条件。無限ループとコスト爆発の歯止め）
- 何を検証させるか（出力をチェックする独立した仕組み。「ノーと言える何か」をループに入れる）
- どの条件で人間に戻すか（エスカレーション基準）
- 前回の学習をどこに残すか（組織記憶の置き場）
この5問は、そのまま例外管理・職務分掌・権限委譲・組織記憶の設計に対応している。つまりループ設計とは、この記事で見てきた組織論の論点を、自分の手元のAIに対して一つずつ具体的に答えていく作業にほかならない。
経営理論を学ぶ価値は、AI時代にむしろ上がる
私はこの数週間、自分のブログ記事を書くために、複数のAIモデルを組み合わせた制作ループを動かしている。一つのモデルに原稿を書かせ、別のモデルに採点させ、その指摘で改訂し、また採点に戻す。成功条件は点数、停止条件は目標点への到達、迷う論点は私に戻す──設計したあとで気づいたのだが、これはまさにループエンジニアリングの実践だった。そしてすんなり組めたのは、エンジニアリングのスキルがあったからではなく、例外管理や権限委譲という組織論の語彙をたまたま先に持っていたからだ。
ここに、AI時代の地味だが重要な示唆がある。AIエージェントを「制御する側」に回ろうとするとき効いてくるのは、最新のツール知識だけではない。間違える主体をどう協調させるかという、組織論が積み上げてきた知見だ。エンジニア出身者が試行錯誤で再発見している原則を、経営理論を学んだ人間は最初から手元に持っている。
「AIに仕事を奪われる」とよく言われる。だが少なくともこの局面では逆のことが起きている。AIエージェントが普及するほど、それを束ねて成果を出させる組織設計の力が問われる。経営理論は、その設計図を書くための言語だ。半世紀前の教科書が、いま最前線の問題に効く──そういう逆転が、静かに起きている。
なお本記事は「AI×経営理論」シリーズの一本だ。プロダクトのライフサイクルを扱った「プロダクトライフサイクル×AI」、内製と外注の境界を論じた「取引費用×AI」もある。経営理論をAI時代の道具として読み直すことに関心があれば、あわせて読んでほしい。
よくある質問
Q. ループエンジニアリングとは何ですか？ A. AIエージェントを一度きりのプロンプトで動かすのではなく、反復して自走させる仕組みを設計する考え方です。成功条件・停止条件・検証・人間に戻す基準などをあらかじめ決め、エージェントが文脈を保持しながらゴールまで進むよう設計します。
Q. プロンプトエンジニアリングとどう違いますか？ A. プロンプトエンジニアリングは一回の良い指示と一回の応答に重心を置きます。ループエンジニアリングは、エージェントを反復して動かす制御の仕組み全体を設計する点が異なります。
Q. ループエンジニアリングは誰が提唱したのですか？ A. AnthropicのBoris ChernyとOpenAIのPeter Steinbergerがほぼ同時期に同趣旨を発言し、GoogleのAddy Osmaniが「ループエンジニアリング」として整理・拡散しました（2026年6月）。
Q. 経営理論を知らないエンジニアでもループ設計はできますか？ A. できます。ただしループ設計の要点（停止条件・検証・人間への引き継ぎ・記憶の保持）は、組織論でいう例外管理・職務分掌・権限委譲・組織記憶に対応します。経営理論を知っていると、これらを最初から見通せます。
Q. AIエージェントにループを任せる前に何を決めればいいですか？ A. 最低限5つです。何を成功とするか、どこで止めるか、何を検証させるか、どの条件で人間に戻すか、前回の学習をどこに残すか。これらは組織論の論点と一致します。
参考
- Addy Osmani「Loop Engineering」 https://addyosmani.com/blog/loop-engineering/
- Peter Steinberger（@steipete）2026年6月8日のX投稿
- Boris Cherny（Anthropic, Claude Code）の講演・投稿での発言
- MindStudio / Lushbinary によるループエンジニアリング解説
コメント