プロンプトを打ち続けるのはもうやめよう。AIの仕事を評価し、次へ進める「ループエンジニアリング」

ループエンジニアリングとは、目標、状態、証拠、評価、停止条件をつなぎ、AIの次の行動を決めながら、一回の完了か次回へ引き継げる状態まで進める設計です。

AIエンジニアリングシリーズ

この言葉はまだ新しく、指す範囲も完全には固まっていません。

この記事では、単なる定期実行ではなく、観測した結果によって次の行動を変えられる仕組みをループとして扱います。

次のどれかに心当たりがあれば、ループを検討する段階です。

• AIエージェントに作業を任せても、次の指示を出すまで止まってしまう。
• エラーが起きるたびに、人が画面を確認して修正を指示している。
• 調査、データ収集、テストなどの長い作業中、パソコンの前から離れられない。
• AIが作った成果物を検証できず、失敗した状態のまま次へ進んでしまう。
• 前回の状態から再開できず、毎回同じ説明と調査を繰り返している。
• AIをどこで止め、どの判断を人間へ戻すか決められていない。

この記事を読むと、リトライ、固定ワークフロー、スケジュール実行、ループを区別し、状態と停止条件を持つ小さな反復を設計できるようになります。

人間がプロンプトを打ち続けている仕事

Claude CodeやCodexへ仕事を任せていると、AIより先に自分が止まっていることに気づきます。

AIが一つの作業を終えたあと、僕が画面を見て、次のプロンプトを送るまで何も進まないからです。

「これを直しておいて」

「直したらテストしておいて」

「またエラーが出たので、原因を調べて」

このやり取りでは、問題を見つけ、結果を確かめ、次の行動を決めているのは人間です。

AIは作業を速くしていても、仕事を前へ進める制御は人間の頭の中に残っています。

つまり、人間自身がループです。

ループエンジニアリングで置き換えるのは、人間の責任ではありません。

置き換えるのは、証拠を見れば機械的に決められる「次は何をするか」という逐次指示です。

人間は内側で毎回プロンプトを打つ役割から離れ、外側で目標、制約、停止条件、最終判断を持ちます。

ループエンジニアリングが設計する範囲

ループが設計するのは、一回の実行が終わったあとの制御です。

出てきた証拠を評価し、続行、方針変更、停止、人間への引き渡しのどれを選ぶか決めます。

4つのAIエンジニアリングの違いを、本サイトでは次のように整理しています。

これは初級から上級へ進む序列ではありません。

指示を仕様にし、必要な情報を渡し、安全に実行できる環境を作り、その実行を検証しながら反復させる関係です。

例えば、テストを実行して合否を返す仕組みはハーネスが担当します。

不合格という証拠を受け、修正を続けるか、別の方針へ変えるか、予算超過で止めるかを決めるのがループです。

リトライ、固定ワークフロー、自動起動との違い

同じ処理を何度も動かしていても、それだけではループとは限りません。

違いは、前回の結果が次の行動を変えるかどうかです。

スケジュールは、ループを始める方法の一つです。

時刻ではなく、前のターンが終わった直後や、CI失敗などのイベントを起点にしても構いません。

Claude Codeの/goalは、各ターンのあとに完了条件を評価し、未達なら次のターンを始めます。

Codexの/goalも、検証可能な停止条件へ向けて複数ターンの作業を継続する機能です。

どちらも、決まった時刻まで待つことをループの条件にはしていません。

一方、同じプロンプトを毎朝9時に実行するだけなら、それは自動起動された固定ワークフローです。

前回の失敗や発見を読み、調査対象や次の処理を変えて初めて、評価を持つ定期ループになります。

目標から次の行動を決める構造

ループを作るとき、最初に自動化ツールを選ぶ必要はありません。

先に、何を見て次の行動を決めるのかを明文化します。

目標
  ↓
現在状態 → 次の行動 → 証拠 → 評価
              ↑                ↓
           再計画 ← 状態更新
                              ↓
                       停止 / 人間へ戻す

重要なのは、会話の長さではなく状態の質です。

前回までの会話をすべて渡すより、現在地、試したこと、証拠、次の候補を短く残した方が、次の周回を始めやすくなります。

状態をどのファイルへ保存し、誰に書き込みを許可するかはハーネスの設計です。

その状態をいつ更新し、どの判定を受けて次へ進むかはループの設計です。

作る役と確かめる役を分ける

AIエージェントへ仕事を任せて難しいのは、案を作らせることより「これは不合格です」と言える状態を作ることです。

作業したエージェントは、なぜその案を選んだかという過程も知っています。

そのため、自分の成果を評価させると、結果より意図を好意的に読んでしまうことがあります。

Anthropicの長時間アプリ開発に関する実験でも、生成したエージェントとは別に評価役を置くことが、自己評価の甘さを抑える手段として紹介されています。

評価役には、成果物を読むだけでなく、可能な範囲で行動させます。

フロントエンドならブラウザを開いて操作し、スクリーンショットとDOMを確認します。

データ処理なら入力件数、出力件数、除外理由、重複数を照合します。

コードならテスト、型検査、lint、実際の差分を確認します。

「よさそうです」という感想ではなく、「何を実行し、どの結果を見たか」という証拠を返させます。

ただし、評価役を別にすれば正しくなるわけではありません。

評価役も同じように見落とし、誤った基準へ最適化し、生成物へ甘い判定を出すことがあります。

まず機械的に確認できる条件を使い、そのあとでLLMによる判断を使い、影響の大きな決定は人間へ戻すのが基本形です。

生成役は候補を増やし、評価役は通してよい候補を狭めます。

両方がそろって初めて、反復が品質の改善へ向かいます。

評価後に同じ手順を繰り返さない

失敗した処理を、そのままもう一度動かすだけならリトライです。

ループでは、失敗を分類し、次の行動を変えます。

例えば、データを抽出できなかったときに、すべてを「0件」とまとめてはいけません。

元データが存在しないのか、取得に失敗したのか、パーサーが未対応なのか、人間の判断が必要なのかで、次の行動は変わります。

分類がなければ、エージェントは同じ修正を繰り返すか、危険な推測で空欄を埋めます。

分類があれば、未対応の構造だけを一つ直し、再検証し、改善しなければ別の方針へ移れます。

ループを回すことより、同じ失敗を二度目にどう扱うかを決める方が重要です。

停止条件、予算、人間へのエスカレーション

自動実行を始める前に、成功以外の止まり方も決めます。

終わり方が成功しかないループは、成功できない状況で走り続けるからです。

停止条件は、少なくとも次の5種類を用意します。

1. 完了条件を満たしたので止める。
2. 試行回数、時間、費用の上限へ達したので止める。
3. 同じ失敗が続き、進展がないので止める。
4. 権限を超える操作、個人情報、外部送信など、安全上の停止条件に当てはまったので止める。
5. 複数の妥当な選択肢があり、責任ある判断が必要なので人間へ戻す。

状態遷移と停止条件の最小テンプレート

最初のループは、次の項目を埋めるだけでも設計できます。

Goal:
  達成したい状態:
  変更してはいけないもの:

State:
  現在地を読む場所:
  各周回で書き戻す項目:

Evidence:
  実行する検証:
  保存するログや差分:

Decision:
  合格なら:
  不合格なら:
  判断不能なら:

Budget:
  最大試行回数:
  最大実行時間:
  最大費用:

Stop:
  完了条件:
  進展なしの条件:
  安全停止の条件:

Escalation:
  人間へ渡す条件:
  人間へ見せる証拠:

人間が外側にいるとは、結果だけを最後に眺めることではありません。

何を証拠として残すかを決め、証拠を説明できる状態にし、成果を本番へ入れる最終判断を引き受けることです。

Addy Osmaniは、人間が担うこの役割を「outer loop」として説明しています。

エージェントが内側で調査、実行、検証を進めても、その結果を採用する責任まで自動化されたわけではありません。

停止条件はAIを縛るためだけでなく、人間が責任を持てる範囲に作業を保つためにあります。

目的達成ループと定期業務ループ

ループには、終わりのあるものと、運用を続けるものがあります。

この二つを同じ停止条件で設計すると、片方は終わらず、もう片方は早く止まりすぎます。

未抽出データを減らす目的達成ループ

僕は、HTML構造がばらばらな大量のページを、正規化してDBへ格納する仕事でループを使いました。

ここでの目標は、RAWデータがあるのに正規化テーブルへ入っていない、対応可能な未抽出を0件にすることです。

一回の周回では、次の処理だけを行います。

1. RAWデータと正規化テーブルを照合する。
2. 未抽出の理由を分類する。
3. 対応可能な構造パターンを一つ選ぶ。
4. パーサーを修正し、fixtureと実DBで検証する。
5. 未抽出件数と失敗分類を更新する。
6. 0件なら停止し、残っていれば次の構造を選ぶ。

契約、パーサー、監査SQL、テスト、保存先は、一回の実行を支えるハーネスです。

監査結果から次の構造を選び、改善しなければ方針を変え、0件で止める制御がループです。

この例には毎朝のスケジュールがありません。

それでも、証拠を評価して次の行動を変え、完了条件へ収束しているため、目的達成型のループとして扱えます。

ループが失敗するパターン

ループの失敗は、止まらないことだけではありません。

間違った評価で早く止まることや、同じ失敗を高速で増やすことも失敗です。

ループは間違いを消す仕組みではありません。

間違いを観測できる形にし、次の周回で扱える状態へ変える仕組みです。

前回の状態を引き継ぐ市場ウォッチ

僕は、マーケティングの変化を確認するため、競合コンテンツとユーザー課題の市場ウォッチを定期実行しています。

毎朝の時刻指定は、この仕事を始めるきっかけにすぎません。

運用をループにするには、前回までの状態を読み、今回の証拠を評価し、次回へ何を残すか決める必要があります。

一回の処理は次の流れです。

1. 設定された対象ソースから、新しく公開された情報を取得する。
2. 公開日時と既知IDを照合し、対象外と重複を除く。
3. 採用した情報をMarkdownレポートへまとめる。
4. 取得済みID、失敗したソース、要確認項目をSQLiteへ保存する。
5. 前回との差分と未解決項目を、次回が読む状態へ残す。
6. 権限エラーや判断が必要な追加対象は、自動で決めず人間へ戻す。

毎日同じ検索をして同じ形式へ保存するだけなら、これは定期ワークフローです。

失敗したソースを次回の再取得対象にし、未解決項目を引き継ぎ、前回との差分から確認の優先順位を変えると、継続するループになります。

目的達成ループは一つの終了へ近づきます。

市場ウォッチのような定期業務ループは、各回を正常に閉じながら、次の回へ状態を渡します。

そのため、「永久に成功する」という完了条件ではなく、各回の取得完了、保存完了、失敗の記録、予算内という運用条件で閉じます。

よくある質問

ループエンジニアリングは単なる自動化と何が違いますか

自動化は、人が決めた処理を自動で実行する広い概念です。

ループは、実行結果を評価し、その証拠によって次の行動を変える制御を持ちます。

スケジュール実行がなければループではありませんか

スケジュールは必須ではありません。

前のターンの完了、テスト失敗、外部イベント、人の開始操作などを起点にできます。

重要なのは、評価から次の行動と停止を決めることです。

AIに自分の出力を評価させてもよいですか

補助的には使えますが、作業した同じコンテキストの自己評価だけで完了を決めるのは避けます。

可能なら評価役を分け、テスト、ログ、件数、実操作などの独立した証拠を使います。

無限ループを防ぐ停止条件はどう決めますか

成功条件だけでなく、最大試行回数、最大時間、最大費用、無進展、安全停止、人間判断の条件を決めます。

上限へ達したときは、失敗理由と最後の証拠を残して止めます。

状態はチャット履歴へ残せば十分ですか

一つの短いセッションだけなら履歴で足りる場合もあります。

再開、定期実行、別エージェントへの引き継ぎがあるなら、完了、未完了、証拠、次の候補をファイル、DB、チケットなどへ残します。

人間はループのどこへ入るべきですか

人間は、目標と制約の設定、評価基準の確認、例外判断、本番へ入れる最終判断を持ちます。

AIが内側の反復を担当しても、人間は外側で証拠を読み、止める権限と結果への責任を持ちます。

最初のループは停止条件から書く

最初から複数のエージェントや複雑な自動化を用意する必要はありません。

まず一つの業務を選び、状態遷移と停止条件の最小テンプレートへ、目標、証拠、次の判断、予算、引き渡し条件を書いてください。

目的が伝わらないなら、先に曖昧な依頼を作業仕様へ変えるプロンプトエンジニアリングを見直します。

判断材料が足りないなら、AIへ渡す情報を選び、圧縮するコンテキストエンジニアリングが先です。

一回の実行が危険で、結果を信用できないなら、ツール、権限、検証を作業環境へ組み込むハーネスエンジニアリングから整えます。

自社の業務をどこまで自動化し、どこで人間へ戻すか整理したい場合は、お問い合わせからご相談ください。

僕なら、最初は最大3回で止まる小さなループを作ります。

そこで残った証拠を読み、判断基準が機能したことを確認してから、実行時間と対象範囲を広げます。

情報元

• Loop Engineering | Addy Osmani
• Own the Outer Loop | Addy Osmani
• Building Effective AI Agents | Anthropic
• Harness design for long-running application development | Anthropic
• Keep Claude working toward a goal | Claude Code Docs
• Follow a goal | OpenAI

更新履歴

この記事は2026年7月18日に、スケジュールをループの必須条件としない定義へ改稿しました。

リトライとの違い、再計画、予算、人間へのエスカレーション、FAQ、状態遷移と停止条件のテンプレートを追加しました。