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

ループエンジニアリングとは、人間がAIへ送り続けていた「次のプロンプト」を、目標、現在の状態、検証結果から仕組みが決め、完了、停止、人間への引き渡しまで反復できるようにする設計です。

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

ループエンジニアリングはまだ新しい言葉で、指す範囲も完全には固まっていません。Addy Osmaniは、人間がエージェントへ次のプロンプトを送り続ける代わりに、その役割を担う仕組みを設計する考え方として説明しています。

本記事では、この考え方を実務へ落とし込みます。AIを何度も動かすことではなく、前回の結果を確かめ、続行、方針変更、停止、人間への引き渡しを選べる仕組みをループとして扱います。

まず、自分がAIの出力と次の指示をつないでいないか確認してください。次のどれかに心当たりがあれば、その仕事はループとして設計し直せる可能性があります。

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

この記事を読むと、リトライ、固定ワークフロー、スケジュール実行、ループの違いを整理し、証拠から次の行動を変えられる小さな反復を設計できるようになります。

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

Claude CodeやCodexへ仕事を任せていると、AIが止まっているのではなく、自分が次の指示を出すまで仕事全体が止まっていることに気づきます。AIが一つの作業を終えるたびに、僕が画面を開き、結果を読み、次のプロンプトを送っていたからです。

「これを直しておいて」

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

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

このやり取りでAIが担当しているのは、指示された一回の作業です。問題を見つけ、結果を確かめ、次に何を試すかを決めているのは、まだ人間です。AIが処理を速くしても、この制御が人間の頭の中に残っていれば仕事は自走せず、人間自身がループのままです。

ループエンジニアリングが置き換えるのは、人間の責任や最終判断ではありません。テスト結果やログを見れば決められる「次は何をするか」という逐次指示です。人間は外側で目標、制約、停止条件を決め、責任を伴う例外判断や本番反映を引き受けます。

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

ループエンジニアリングが設計するのは、一回の実行の前後をつなぐ制御です。次の仕事を選び、実行結果を証拠で確かめ、その結果から続行、方針変更、停止、人間への引き渡しを決めます。

この制御が、ほかの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」と表現しています。エージェントが内側で調査、実行、検証を進めても、結果を採用する責任まで自動化されたわけではありません。停止条件は自動判断の限界を明示し、人間が責任を持てる範囲に作業を保ちます。

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

ループには、一つの完了状態へ収束するものと、各回を閉じながら運用を続けるものがあります。両者を同じ停止条件で設計すると、目的達成ループは終わらず、定期業務ループは一回の成功だけで運用全体が完了したように見えてしまいます。

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

僕は、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回で止まる小さなループを作ります。そこで残った証拠を読み、結果によって次の行動が本当に変わったか、停止条件が機能したかを確認します。

この二つを確認できてから、実行時間と対象範囲を広げます。最初に確かめるのは、AIが何回動いたかではなく、証拠によって次の行動が変わり、決めた条件で止まれたかです。

情報元

• 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、状態遷移と停止条件のテンプレートを追加しました。