ループエンジニアリングを、
開発ではなく「会社」に適用する

2026年、AIの使いこなし方の重心が動きました。「どうプロンプトを書くか」から、「AIが自分で動き続ける仕組み＝ループをどう設計するか」へ。ループエンジニアリングと呼ばれるこの考え方を、いま第一線のエンジニアが口を揃えて言い始めています。ただ、出回っている解説はほとんどが開発ワークフローの話に留まっています。私たちJumpStackは、AIエージェントのチームと人間の代表1名で運営しています。開発だけでなく、会社の運営そのものがループです。本記事では4段階のモデルを整理したうえで、それを会社の規模で回すと何が必要になるのかを書きます。連載「全員AIの会社の内側」の第2回です。

AIとの付き合い方は、4段階で外へ広がってきた

安野貴博氏が動画で整理している4段階が分かりやすいので、それを借りて全体像を示します。

段階	設計するもの	具体例
1. プロンプトエンジニアリング	AIへの頼み方	役割を与える、聞き方を工夫する
2. コンテキストエンジニアリング	判断に必要な情報の渡し方	仕様書・規約・関連ファイル・過去の経緯を毎回入れる
3. ハーネスエンジニアリング	AIが安全に作業できる足場	テスト、書き方の検査、権限の制限、ログ、人間へのエスカレーション
4. ループエンジニアリング	指示を出すこと自体の自動化	定期起動、サブエージェントの分業、人間はループの外へ

段が上がるごとに、人間の仕事は「中身を書くこと」から「外枠を設計すること」へ移ります。そして4段目で、人間はループの中から外へ出ます。ヒューマン・イン・ザ・ループから、ヒューマン・オン・ザ・ループへ。inとonが一文字違うだけですが、意味はまったく違います。作業の流れの中にいて一つひとつ検品するのか、外から監督していて逸れたときだけ声をかけるのか。

出典: 安野貴博「【ループエンジニアリングとは？】AIにプロンプトはもう要らない」／@IT「ループエンジニアリングとは？」（2026年6月23日）

いちばん見落とされるのは、3段目のハーネス

ループという言葉は魅力的なので、そこだけを取り出したくなります。しかし強調されているのは、ハーネスができていないままループを回すと暴走するという点です。ループエンジニアリングは、ハーネスエンジニアリングができていることを前提にしています。

ハーネスとは、AIが安全に、検証されながら作業できる足場のことです。振る舞いのルールを書いたファイル、テスト、書き方を検査する仕組み、ログと履歴、そして判断に迷ったときに人間へ判断を仰ぐ経路。重要なのは、これらが「お願い」ではなく環境側の強制力だという点です。「テストを通してくださいね」はプロンプト。「テストが通らなければ次の工程へ進めない」がハーネス。この違いが決定的です。AIは時に暴走してデータを消そうとしますが、消せない環境に置いてあれば消せません。

ここで白状すると、前回の記事で私たちが書いた4つの工夫——生成物を人が手で触らない、差分検出を毎回回す、運用知識をファイルに置く、人間が確認する対象を絞る——は、名前を付けるならハーネスそのものでした。理解負債への対処として書いたものが、そのままループを回すための前提条件になっていた。順番として、これは偶然ではないのだと思います。

私たちのループは、開発の外にもある

具体例を出します。いまお読みいただいているこのコラムの、公開作業そのものです。

公開の指示を受けると処理が起動し、下書きのうち次に出すべき記事を特定し、公開日を各所に反映し、記事一覧・サイトマップ・RSS・トップページの新着欄を再生成し、検証を通し、人間に報告する。ここまでで一巡です。

ハーネスに当たるのは検証の部分です。記事のメタ情報が規約に違反していればビルドはエラーで停止し、一本でも違反があれば何も書き込まれません。生成物が手で触られていないかは差分検出で分かります。2つのフォルダの内容が一致しているかはハッシュで照合し、公開記事から下書き記事へのリンクが混ざっていないかも機械的に確かめます。どれか一つでも落ちれば、その先へは進みません。

これはソフトウェアの開発ではありません。編集と公開という、どちらかといえば事務作業に近い仕事です。それでもループとハーネスの発想はそのまま効きます。

ループは、速さの違う入れ子になっている

動画で紹介されているAI研究者アンドリュー・ング氏の整理が有用なので借ります。ループは一つではなく、速さの違う3つが入れ子になっているという見方です。

• 最も速いループ（数分単位）——実装して、テストして、直す。ここに人間はいません。
• 中間のループ（数十分〜数時間）——出てきたものを人間が見て、方向を修正する。ここが監督の場所です。
• 外側のループ（数時間〜数週間）——実際に使ってもらい、反応を見て、そもそも何を作るべきかという認識自体を更新する。

私たちに当てはめると、記事の生成と検証が内側、代表の確認が中間、公開後の検索順位やお客さまからの反応が外側です。ループエンジニアリングとは、この3つのどこに人間を置くかを決める作業だと言えます。全部をAIに任せきるのでも、全部を人間がやるのでもない。線を引くことがすべてです。

なぜ、人間はループに残るのか

動画でもっとも示唆的だったのは、ング氏によるこの説明でした。人間がループに残る理由は、人間に「センス」という替えのきかない資源があるからではない。人間はただ、ユーザーのことや、その製品が使われる状況について、AIが知らないことを知っている。その情報量の差を埋めているだけである、と。

突き放したようでいて、実務的にはとても有益な見方です。センスの話であれば、いつまでも属人的なまま終わります。情報の差の話であれば、渡せる情報は渡してしまえばいい。私たちが手順書や規約をファイルに書き出しているのは、まさにこの差を機械的に埋める作業です。

同時に、この見方は逆向きの結論も導きます。渡せない情報がある限り、そこには人間が要る。では受託開発において、AIが知らない情報がもっとも濃く存在する場所はどこか。お客さまの現場です。何が本当の困りごとで、誰が反対していて、どの制約が動かせないのか。仕様書には書かれず、そもそも書けもしない情報です。私たちが現場にAIチームを配置するという形にこだわっているのは、ここに理由があります。ループの外に出た人間が立つべき場所は、自社の中ではなく現場のほうだと考えています。

開発以外の仕事にも染み出す

動画ではソフトウェア以外の例も挙げられています。日程調整をAIに任せる場合、勤務時間や育児による制約をルールとして持たせ、違反を検出できる仕組みがあれば、任せられる範囲は広がる。会議の文字起こしからタスクを抽出し、関係者の予定を調整して招待を送るところまでを一巡にする。書類の作成と規則チェックを回す。

ここから引ける実務的な線引きは、おそらくこうです。その仕事に「テスト」を書けるか。何をもって正しいとするかを機械が判定できるなら、その仕事はループに乗ります。判定できないなら、そこは人間が残る場所です。ひとり情シスのように少人数で広い範囲を見る立場ほど、この線引きの効きは大きくなります。

発注する側から見ると、質問が一つ増える

外部に開発を頼む立場でこの話を使うなら、聞くべきことは一つです。「AIを使っていますか」ではなく、「どんなハーネスを持っていますか」。

テストは自動で走るのか。何が失敗したら先へ進めない設計になっているのか。人間の確認はどこに置いているのか。この3つに具体的に答えられる相手は、速いだけでなく、後から直せる成果物を作ります。答えが「気をつけています」であれば、それはハーネスではなく心がけです。開発会社の選び方に、2026年はこの一項目が加わりました。

まとめ——回す前に、足場を作る

ループエンジニアリングはまだ黎明期の考え方です。呼び名も整理の仕方も、これから変わっていくでしょう。それでも、重心が「うまく指示する」から「うまく回る仕組みを作る」へ移ったことは、もう動かないと思います。

そして回す前に、足場が要る。私たちが人間1名で事業を運営できているのは、AIが賢いからというより、止まるべきときに止まる仕組みを先に作ったからです。速さは、その副産物として付いてきました。順番を逆にすると、速く壊れます。