TL;DR
- ループエンジニアリングが流行っているのは知っていたが、現実の開発ではプロダクトの設計思想と現実の課題感に基づく意思決定が必要になり、イレギュラーをきっかけに本来の方針から大きく逸れるリスクがあるため、実用は難しいと思っていた。
- Web applicationとして開発しているKIBAKOの公開デモを、AI agentのBrowser（ブラウザ操作機能）で改善しているとき、「初見のつもりで愚直に使う → 最初につまずいた問題を一つ直す → 最初からやり直す」という指示を思いついた。
- 実際の画面が観測対象になり、「最初の一つ」がスコープを制限し、同じ入口からの再実行が検証になる。この種類のタスクなら、小さなループから始められるかもしれない。
- ChatGPT DesktopのScheduledを組み合わせ、アプリに表示されたweekly usage limitのリセット直前まで、安全に限定したこのループを回す運用も実際に試した。
流行りだが、現実には難しいと思っていた
最近、AI coding agentの文脈で「ループエンジニアリング」という言葉を目にするようになりました。
ざっくり言えば、人間が毎回次のプロンプトを書くのではなく、AI agentが目標に向かって実行、観測、修正、検証を繰り返せる仕組みを設計する考え方です。IBMの解説では、Goal、Action、Observation、Adjustmentという流れで説明されています。
一方で、この言葉自体はまだかなり新しいものです。2026年8月に公開されたLoop Engineeringに関するレビュー論文でも、2026年6月ごろから実務家の間で使われ始め、強い期待と懐疑の両方を伴って急速に広まった概念として整理されています。
流行っていること自体は理解していましたし、考え方にも興味がありました。ただ、率直な感想はこうでした。
ループエンジニアリングは流行っている。でも、現実のソフトウェア開発で安全に使うのは難しいだろうな。
そう考えていた最大の理由は、現実の開発には、プロダクトの設計思想と現実の課題感に基づく意思決定が欠かせないからです。
コードを書いてテストを通すだけなら、成功条件を機械的に置きやすいです。しかし実際には、アーキテクチャ、データモデル、移行方法、インフラ構成、セキュリティ、コスト、段階的リリース、rollbackなど、複数の正解から一つを選ぶ判断が何度も発生します。
さらに怖かったのは、イレギュラーへの対応です。想定外のエラーや依存関係、既存仕様との衝突が一つ起きたとき、AI agentがその場では合理的に見える回避策を選び、元のプロダクト方針や設計判断から大きく逸れてしまう可能性があります。
テストが通っていても、意思決定として正しいとは限りません。一周ごとの小さな逸脱が、ループによって何度も増幅されることもあり得ます。
- UXの「分かりやすくなった」を何で判定するのか
- AI agentが細かな見た目の修正を無限に始めないか
- イレギュラーに対する局所的な判断が、本来の設計方針から逸れないか
- プロダクトの設計思想や現実の課題感に関わる判断を、どこで人間へ戻すのか
- 何を完了条件にし、何周まで許容するのか
- 長く回した結果、時間やtokenだけを消費しないか
ループさせること自体は簡単でも、価値のある方向へ安全に回すための条件を決めるのは難しい。流行っているからそのまま採用できるものではない、と感じていました。
KIBAKOのデモを改善しているときに思いついた
私はWeb applicationとして、オンラインでボードゲームを試作・テストプレイできるKIBAKOを開発しています。
その中に、ログインせずに操作を試せる公開デモがあります。制作ルームから始まり、ダイスを振る、出目に合うトークンを動かす、カードの表裏を編集する、プレイルームを作る、カードを手札へ移す、手札の所有者を設定する、という一連の流れを体験できるデモです。
デモ内の変更は正式なプロジェクトに保存されず、ページを更新または移動すると消えます。つまり、何度も最初の状態へ戻して試せます。
このデモを、AI agentのBrowser useを使ってバージョンアップしようとしていたとき、次の指示を思いつきました。
実際に一度、事前知識のない初見ユーザーになったつもりで、
愚直にこの機能を使ってみて、
最初につまずく問題点を一つ洗い出して。
->
修正して。
---
このループを回す。
ここでのポイントは、事前知識のない初見ユーザーの視点に立つことです。
開発者やAI agentが、仕様、コード、画面構成について既に知っている情報をいったん封印するための指示です。「このボタンを押すはず」「この用語の意味はコードを見れば分かる」と補完せず、初めて来た人のように、画面に表示されている情報だけを頼りに愚直に進めます。
この視点は、人間である開発者自身が持とうとしても、そのプロダクトに関わった時間が長いほど難しくなります。自分にとって当たり前になった導線や言葉を、知らなかった状態には戻れません。だからこそ、AI agentに事前知識を使わないよう明示し、初見ユーザーとして操作させるこの指示自体にも価値があると感じました。
この指示を実際に試してみて、「ループエンジニアリングは難しそう」で止まっていた考えが少し変わりました。
あれ、この種類のタスクなら、ループエンジニアリングを有効活用できるかもしれない。
なぜ、このタスクはループにできそうなのか
Browser useが「観測」を作ってくれる
UX改善をコードだけで完結させようとすると、AI agentは実装上の推測に寄りやすくなります。
しかしBrowser useを使えば、実際の入口から画面を開き、表示された文言や操作可能な要素を確認し、ボタンを押し、結果を観測できます。KIBAKOのデモなら、ダイス、トークン、カード、プレイルーム、手札という実際の操作を通して、ユーザーが価値へ到達する経路を辿れます。
「コード上は正しい」ではなく、「実際の画面で次へ進めたか」をフィードバックにできる点が、このループの土台になります。
「最初の一つ」が変更範囲を狭くする
AI agentへ「UXを改善して」と頼むだけでは、対象が広すぎます。文言、色、レイアウト、機能追加など、どこまでも変更できてしまいます。
そこで、直す対象を「最初につまずいた一つ」に限定します。
- 数秒考えないと次の操作が分からなかった
- 操作できる場所を見つけられなかった
- 押した結果が成功なのか分からなかった
- エラーや無効状態の理由が表示されなかった
- 画面外の知識やヘルプがないと進めなかった
最初に発生したものを一つだけ扱い、それより先の問題はいったん修正しません。これにより、AI agentが際限なく「もっと良いUI」を作り始めるのを防ぎやすくなります。
同じ入口からの再実行が検証になる
修正後に変更したコンポーネントだけを見ても、ユーザー体験が改善したとは言えません。
状態をリセットし、同じURLから同じ目的で操作をやり直します。前回の停止地点を越えられたら、その修正には少なくとも観測可能な効果があります。越えられなければ、修正は未完了です。
さらに、前回の問題を越えた先で新しく最初につまずいた地点が、次の改善対象になります。人間がバックログの順番を毎回決めなくても、実際のユーザーフローが次のタスクを見つけてくれます。
リセットしやすいデモは、安全な実験場になる
本番データの更新、課金、外部への送信、他ユーザーへの影響があるフローを、自律的なBrowser useにそのまま渡すのは危険です。
その点、今回のKIBAKOデモは、操作結果が一時的でリロードによって初期状態へ戻せます。現実のUIを使いながらも、反復による副作用を抑えやすい環境です。
ループに向いたタスクを探すとき、「何を改善したいか」だけでなく「安全に何度でもやり直せる場所があるか」も重要だと気づきました。
この小さなループを分解してみる
今回の指示を、ループの構成要素に当てはめると次のようになります。
| 要素 | 今回のタスク |
|---|---|
| Goal | 初めて来た人がKIBAKOのデモを迷わず進められる状態に近づける |
| Action | Browser useでデモを入口から操作する |
| Observation | 最初に迷った、止まった、または結果を判断できなかった地点を記録する |
| Adjustment | 原因を調べ、その一点をコードで修正する |
| Verification | テストを実行し、同じ状態・同じ入口からブラウザ操作をやり直す |
| State | 修正結果はコードとテストに残し、次の問題は同じ操作から再発見する |
| Stop | 目的の操作を完了する、上限回数に達する、または人間の判断が必要になる |
Stateの重要性が低いのではなく、履歴への依存が低い
今回のタスクでもStateは必要です。修正結果はコードとテストに残り、未commitの差分も次のrunへ渡すStateになります。
一方で、過去の会話や判断履歴への依存は低いと感じました。デモは毎回初期化でき、前回までの経緯を詳しく覚えていなくても、同じ入口から操作し直せば次の問題を発見できます。必要なStateの多くがコード、テスト、実際のUIに外部化されており、agentはrunの開始時に環境から再構築できます。
このように、一周が短く、結果を観測でき、安全に初期化でき、Stateを環境から再構築しやすいタスクなら、少なくとも現在の最前線のモデルで実用ラインに載せやすいのではないか。これが今回の体験から得たもう一つの仮説です。
AI agent自体も、一つのturnの中でモデル推論とtool callを繰り返します。OpenAIもCodexの中核をagent loopとして説明しています。
ただし、ここで考えたいループは、その内側の動作だけではありません。「次にどの仕事を選ぶか」「何を証拠に直すか」「どの条件で止めるか」まで、開発ワークフローとして外側に設計することです。
Scheduledを外側のtriggerにしてみた
この小さなループには、ChatGPT DesktopのScheduledも組み合わせました。OpenAIの公式ドキュメントでは、ローカルプロジェクトや分離したGit worktreeを対象に定期実行できます。
私はアプリに表示されたweekly usage limitのリセット時刻を確認し、今週使い切れずに終わりそうな分で、リセット直前までこの改善ループを回してみました。KIBAKOデモのように状態を戻せる対象に絞り、一回のrunで直すのは一つ、testとBrowser useによる再確認を必須にし、最後は人間がreviewします。
credit消費自体を目的にすると、本来の意思決定から逸れる危険があります。先に安全なtaskを決め、Scheduledを外側のtriggerと時間上限にする。この形なら、最初の短いpromptよりも、かなりループエンジニアリングらしくなりました。
IBMの定義に照らすと、まだ完成したループエンジニアリングではない
IBMの定義では、ループエンジニアリングは、AI agentが最小限の人間の介入でユーザー定義の目標を達成できるようにする仕組みです。agent自身が行動、観測、意思決定、調整を繰り返すことに加え、目標には明確で検証可能な停止条件を置くことが重視されています。
この定義に照らすと、今回の仕組みはまだ完成形とは言えません。最初に試したのは、一つの指示から始まる小さなループで、その後にScheduledによるtriggerと時間上限を加えました。Goal、Action、Observation、Adjustmentはありましたが、明確だった停止条件はweekly limitのリセット前という時間上限です。「初見ユーザーが迷わず完了できる」といったプロダクト上の目標達成を自動で判定して終了するところまでは作っていません。独立したreviewer、すべてのrunをまたぐ厳密なstate管理、失敗時のescalationも未整備でした。
また、今回は一回ごとのループでAI agentにcommitさせず、変更は人間がreviewできる状態で残しました。自動commit自体がIBMの定義条件というわけではありませんが、私がそこまでagentを信頼していなかったためです。デモが確実に良くなった感触はある一方で、まだ直したい箇所も残っていました。完成の判断やcommitの区切りまで自律的に任せる段階ではありませんでした。
そのため、「これでループエンジニアリングを実現した」と大きく言うつもりはありません。
それでも、次の三つが一つのタスクに入ったことには意味があります。
- AI agent自身がBrowser useで次の問題を発見する
- 発見した問題を一つだけ修正する
- 同じ操作を再実行して、修正と次の問題を確認する
完全自律の大きな仕組みを最初から作ろうとすると難しく感じます。先に、観測可能で、修正範囲が狭く、再実行できるタスクを見つける。そこへScheduled、state、上限、review、escalationを一つずつ足すほうが、私には具体的に感じられました。
AI agentへの指示をもう少し実用的にする
最初の短い指示は、発想を試すには十分でした。継続的に回すなら、次のように境界を追加すると扱いやすくなります。
目的:
初めてKIBAKOのデモを訪れたユーザーが、画面内の案内だけを使って
指定されたデモ手順を完了できる状態へ近づける。
各ループ:
1. 状態をリセットし、デモの公開入口からBrowser useで操作する。
2. コードや内部仕様で画面の意味を補完せず、最初に迷った地点で止まる。
3. 観測事実、期待、実際の結果、証拠を記録する。
4. 最初の問題だけを対象に、コードから根本原因を調べる。
5. 最小の安全な修正を行い、関連するテストを実行する。
6. 同じ状態、同じ入口、同じ目的でブラウザ操作をやり直す。
7. 前回の問題を越えたら、次の最初の問題を新しい対象にする。
制約:
- 一周で修正する問題は一つだけにする。
- テストを削除・弱体化して通さない。
- エラーを握りつぶすfallbackを最終修正にしない。
- 課金、外部送信、権限変更などの副作用がある操作は自動実行しない。
- プロダクト方針の判断が必要なら、人間へ確認する。
停止条件:
- 指定したデモ手順を入口から完了できた。
- 最大周回数または予算に達した。
- 人間の判断なしでは安全に修正できない。
ポイントは、「初見のつもりで使って」のような姿勢だけで終わらせず、観測時に使ってよい情報、修正範囲、証拠、再現条件、停止条件まで書くことです。
すべてをAI agentへ任せるわけではない
Browser useをするAI agentは、本物の初心者ユーザーではありません。DOMの構造やaccessibility情報から、人間より簡単に操作対象を見つけることもあります。反対に、見た目の違和感、文脈、感情的な不安を十分に捉えられないこともあります。
そのため、このループだけでユーザー調査を置き換えることはできません。
- PCだけでなく、必要なviewportや入力方法でも確認する
- 自動テストやtype checkを別に実行する
- 大きなUX判断は人間がreviewする
- 実際のユーザーの行動や声とも照らし合わせる
- agentが見つけられなかった問題も扱える入口を残す
このループは、すべてのUX問題を自動で解くものではなく、開発者の知識によって見落としやすい「入口から最初の摩擦」を継続的に拾うための補助線です。
似たタスクは、ほかにもあるかもしれない
今回の経験から、ループエンジニアリングに向くかどうかは開発規模ではなく、結果を観測でき、安全に状態を戻せて、明確な停止条件を置けるかで決まるのではないかと思うようになりました。
たとえば、次のようなタスクも候補になりそうです。
- 新規ユーザーが最初の成果物を作れるまで、最初の摩擦を一つずつ直す
- ドキュメントの手順をBrowser useで実行し、最初に再現できない箇所を直す
- エラー画面から復旧を試し、最初に説明不足な状態を直す
- モバイルviewportで主要フローを進み、最初に操作不能な地点を直す
- 公開デモやsandboxを最初から使い、最初に壊れた操作を直す
共通するのは、実際に操作できる対象、観測可能な結果、小さく切れる最初の問題、再実行できる初期状態、明確な停止条件があることです。
まとめ
私は、流行りのループエンジニアリングに対して、「考え方は面白い。しかし現実の開発では、プロダクトの設計思想と現実の課題感に基づく意思決定が必要になり、イレギュラーをきっかけに本来の方針から逸れるリスクも大きいので、安全に持ち込むのは難しいだろう」と考えていました。
ところが、KIBAKOのデモをBrowser useで改善しようとして、考え方が少し変わりました。
事前知識のない初見ユーザーになったつもりで愚直に使う。最初につまずいた一つを直す。状態を戻し、最初からもう一度使う。
これなら、実際の画面を観測に使いながら、変更範囲と次の仕事を自然に絞れます。さらにScheduledを外側のtriggerとして使えば、weekly limitのリセット前に余りそうな利用枠を、この安全に限定した改善へ回すこともできました。
IBMの定義に照らせば、これはまだ完成したループエンジニアリングではありません。それでも、自分の開発にループを持ち込む最初の一歩にはなりそうです。
「ループエンジニアリングなんて……」と思っている方は、ぜひ自分の開発の中に、こういうタイプのタスクがないか探してみてください。