AIのフィードバックループとは｜自動反復を任せる前に決める設計の要点

生成AIに反復作業を任せる「ループ自動化」は、目標を一度渡せば実行と確認と修正を自動で繰り返してくれる使い方だ。

ただし回し方を設計せず目標だけを投げると、それらしい修正を延々と続けてコストだけがかさむ。

このページは、ループ作業を扱った記事を設計とツールと実務の三つに整理し、任せる前に決めておくべき点をまとめた入口である。

AIのフィードバックループとは（用語の整理）

本記事では「ループ作業」「自動反復」「フィードバックループ」「エージェントループ」を同じ対象を指す語として扱う。呼び名は複数あるが、論点は共通している。

AIのフィードバックループは、次の5つの要素に分解できる。

入力：何をしてほしいかを渡す
実行：AIが作業する
出力の評価：できあがったものを何らかの基準で判定する
評価結果を次の入力へ戻す：足りない点を次の周回の材料にする
終了判定：どこで止めるかを決める

この記事が繰り返し述べる「終了条件と合格条件を先に決める」という主張は、5要素のうち(3)の評価と(5)の終了判定を、回し始める前に人が定義しておくことに当たる。AIに任せるのは(1)から(4)の反復であって、何をもって合格とするかの定義まで任せるわけではない。

終了判定をどう書くかは、ループ自動化で回す前に決める合格条件と停止条件で、編集部が毎日回しているSEOの定期ループの値を使って示している。

フィードバックループは3種類ある

フィードバックループと呼ばれるものには、少なくとも3つの型がある。

自己修正ループ：AIが自分の出力を評価して直す。Claude Codeの作者が語ったという「loopを書く開発」が想定しているのは主にこの型だ。
人間レビューのループ：人の指摘を次の入力に戻す。評価する主体が人になる。
学習のループ：評価結果をモデルそのものの改善に戻す。本記事の範囲外とする。

本記事が扱うのは前の2つである。学習のループは運用の話ではなくモデル開発の話になるため、ここでは触れない。範囲を区切ることは説明の手抜きではなく、読者が判断を誤らないための前提だ。

止め方も型ごとに違う。自己修正ループは反復の上限で止める。人間レビューのループは差し戻しの回数で止める。学習のループでは、止めるというより評価データの品質が結果を決める。

フィードバックループが壊れる典型パターン

評価基準がAIの主観になっている：「前より良くなったと思う」で合格にしてしまう。テスト通過やビルド成功のように、機械で判定できる基準を混ぜる。
評価する側と実行する側が同じモデル：同じ誤りを見落とし続ける。別のモデルか外部のテストを評価に入れる。複数AIを協調させるときのコストも併せて見ておきたい。
終了条件がなく、修正コストだけ積み上がる：回るほど費用が増える。Claude Codeのコスト構造を踏まえて上限を決める。

回す前に決めておく項目そのものは、後半の「まず何から決めるか」にまとめてある。

ループ作業とは何を指すか

ループ作業とは、AIに目標を与えて「実行して、確認して、修正する」を自動で繰り返させる使い方を指す。

人がプロンプトを打ち直さなくても、合格するまでAIが自分で反復する点に価値がある。

一方で、いつ止めるかと、1周ごとに何を達成できたら次へ進むかを決めないまま回すと、修正だけが続いてコストが膨らむ。

収録した記事はテーマがばらけているが、共通する論点はひとつに収束する。任せる前に終了条件と合格条件を決めたかどうかで、成否が分かれるという点だ。

設計と考え方

ループをどう組み立てるかは、回す前に人が何を決めるかに尽きる。

CodexとClaude Codeでループ自動化を回す前の設計

回す前に決めるのは、1周の合格条件、反復と費用の上限、止まる条件、人へ戻す条件の4つだ。編集部がこのサイトのSEOを回している定期ループで、それぞれにどんな値を置いているかと、2026年10月に実際に止まった3件の例をまとめた。定期起動、雛形の再利用、その場で手順を組むDynamic Workflows、並列のレビュー、エージェント同士のやり取りなど、ループの組み方ごとに先に決める条件も表にしてある。

合格条件は、AIの自己評価ではなく、HTTPのステータスやURL検査の結果のように機械で判定できる値にする
上限は費用のためだけでなく、どの変更が効いたかを見分けられる大きさに周回を区切るために置く

→ CodexとClaude Codeのループ自動化｜/goal前に決める合格条件と停止条件

ツールと仕組み

ループを実際に動かすためのツールを扱う記事を集めた。ループの途中に処理を差し込む方法としては、Codexのタスクループに介入するHooksも参考になる。

ゴールを渡すとCodexがチームを組むスキル

ClaudeのDynamic WorkflowsをCodexへ移したオープンソースのスキルで、ゴールを渡すとサブのAIが作業の分解と役割分担を試みる。

複数のサブAIを並列で動かすと、編集の競合や重複作業や判断の衝突が起きる。投稿はその失敗時の対処や承認の手順までは示していない。

任せるゴールの大きさを先に制限し、出力された計画を人が検査できる構造にすることが実務の前提になる。

採用の基準は「無料か」ではなく、計画を人が検査して介入できるかどうか
自律化を進める前に、任せるゴールの粒度を明示的に区切る

→ codex-dynamic-workflows｜ゴールを渡すとCodexが自分でチームを組む無料スキル

実務インパクト

「タスクの100%はAIがやっている」をどう読むか

Andrew Ngの「自分のタスクの100%はもうAIエージェントがやっている」という発言の波紋を扱う記事だ。

「100%」は発言者個人の文脈の数値であり、自社の業務にそのまま移せる目標値ではない。

むしろ、エージェント導入が実験の段階を終えつつあるサインとして読むほうが実務に近い。

「やっている」業務でも、プロンプト設計や権限付与や結果の検査が自動化されているとは限らない
立てるべき問いは「どの業務単位なら自社で再現できるか」であり、検証できる粒度に分解することが先

→ Andrew Ng「自分のタスクの100%はもうAIエージェントがやっている」発言の波紋

まず何から決めるか

収録した記事に共通する出発点は、AIに任せる前に人が決めておく事柄を仕様として書き出すことだ。

終了条件：最大の反復回数と、何が起きたら強制的に止めるか
合格条件：1周ごとに何を満たせば次へ進むか。テスト通過やビルド成功など客観的に判定できるもの
権限の範囲：AIにどのファイルや操作まで触らせるか
戻す条件：失敗が続いたとき、どの時点で人へ引き戻すか
ゴールの粒度：一度に任せる目標をどこまで小さく区切るか

これらを決めずに目標だけを渡すと、どのツールを使っても同じ事故に行き着く。修正だけが続き、コストが膨らむ。

逆に言えば、ここを書き出してあれば、ループ自動化は反復作業を任せられる実用的な手段になる。

「Loop Engineering」という呼び方（2026-06-28 追記）

この考え方は、X上で「Loop Engineering」と名づけて語られ始めている。 @masahirochaen は、AIエージェント時代の本質が「良いプロンプトを書く力」から「AIが自走する仕組みを設計する力」へ移りつつある、という記事を紹介している。呼び名は新しいが、指している中身は本ページの主張と同じだ。人が毎回プロンプトを打つのではなく、終了条件と合格条件を先に決めて反復を任せる設計に重心を移す、という話である。

名前が付くと話題は広がりやすいが、設計の中身が変わるわけではない。自走の仕組みを名乗る前に、止める条件と戻す条件を書き出してあるか、という点はそのまま残る。

よくある質問

Q. AIのフィードバックループとは何ですか。 A. 実行 → 出力の評価 → 評価結果を次の入力へ戻す、を終了条件に達するまで繰り返す使い方です。人がプロンプトを打ち直さなくても、AI側で反復する点が特徴です。

Q. プロンプトを何度も打ち直すのと何が違いますか。 A. 評価と終了判定を仕組みに埋め込むかどうかが違います。人が毎回判断する場合、評価の基準が暗黙のままになりやすくなります。

Q. ループはいつ止めればいいですか。 A. 反復の上限と、客観的な合格条件（テスト通過やビルド成功など）を先に決めて、どちらかに当たったら止めます。決めないまま回すと修正だけが続きます。

Q. AIが自分で自分を評価すると正しく直りますか。 A. 同じモデルが実行と評価を兼ねると、同じ誤りを見落としやすくなります。外部のテストなど、機械的に判定できる指標を評価に混ぜてください。

Q. フィードバックループとエージェントループは別物ですか。 A. 本記事では同じ対象を指す語として扱います。呼び名は複数ありますが、評価と終了判定を設計するという論点は共通です。

このページについて

収録した記事の多くはX上の投稿を起点にした解説であり、投稿に含まれる数値や効果の表現は未検証のものを含む。ループ自動化の設計の記事は、編集部の運用で確かめた値と事例で書き直した（2026-10-23）。

各記事ではその前提を明示したうえで、実務で再現できる論点に絞って整理している。