株式会社 Polyscape 代表取締役の島田です。
これまで複数のAI駆動開発案件に取り組む中で、単に素のCodexやClaude Codeに開発させた成果物と、適切なループやハーネスが備わったコーディングエージェントに書かせた成果物では、品質に大きな差があるということが見えてきました。
それを集約してたどり着いた概念が、「強いAI駆動開発は、『ループの強さ』から生まれる」という考え方です。
今回は、Anthropicが紹介している「ループエンジニアリング」を手掛かりに、ヒューマン・イン・ザ・ループからヒューマン・オン・ザ・ループへの移行、そしてPolyscapeが考えるAI駆動開発のレビューサイクルと発展段階について解説します。
PolyscapeのAI駆動開発サービスについては、こちらのサービスページでも紹介しています。
ループエンジニアリングとは？
2026年6月30のANTHROPICの発信［1］から、「ループエンジニアリング」という言葉が話題になっています。ループエンジニアリングとは、AIに一度だけ指示して答えを得るのではなく、目的を達成するまで「状況把握→実行→検証→修正」といった「ループ」を設計するという考え方です。AIがどの条件で動き始め、何を基準に結果を確かめ、どの条件で作業を終えるかまでを、ひとつの仕組みとして定義します。
AnthropicのClaude Codeチームは、ループを「停止条件が満たされるまで、エージェントが作業のサイクルを繰り返すこと」と定義しています。同チームは、何をきっかけに始まり、何をもって終わり、どのような仕事に向くかによって、主に4つのループを整理しています。［1］
- ターンベースのループ：ユーザーのプロンプトで始まり、AIが完了したと判断するか、追加情報が必要になった時点で止まります。短い作業や、その場で人と相談しながら進める仕事に向きます。
- ゴールベースのループ：達成条件と最大試行回数を先に定義し、条件を満たすまで実行と評価を繰り返します。「テストがすべて通る」「Lighthouseスコアが90以上になる」といった、機械的に判定しやすいゴールと相性が良い形式です。
- 時間ベースのループ：一定間隔で同じ仕事を実行します。CIの失敗確認、レビューコメントへの対応、定期的な情報整理など、入力だけが変化する継続業務に向きます。
- プロアクティブなループ：イベントやスケジュールを起点に、人がリアルタイムで指示しなくても動きます。新しい不具合報告の検知、一次切り分け、修正、レビュー、通知といった一連の流れを組み合わせられます。
重要なのは、複雑なループを作ること自体が目的ではないという点です。短い仕事はターンベースで十分です。一方、品質条件が明確な仕事はゴールベースにし、定期業務は時間ベースにし、入力イベントに反応し続ける仕事はプロアクティブにする。このように、仕事の性質に応じて「開始条件・反復の中身・停止条件」を設計することが、ループエンジニアリングのポイントです。
プロンプトから、反復可能なシステムの設計へ
プロンプトエンジニアリングは、一回の指示を明確にし、望ましい出力を得るための技術です。それに対してループエンジニアリングは、一回で正解を出すことを前提にしません。
何を見て状況を理解するのか。どのツールで行動するのか。何をもって正しいと判定するのか。失敗時にどの情報を引き継いでやり直すのか。どの条件で人へ戻すのか。こうした反復全体を設計します。
つまり、AI活用の焦点が「良い指示を書く」ことから、「AIが自分で確かめ、改善できる環境を作る」ことへ広がってきています。
Verify（検証）がループの中心になる
Anthropicは、エージェントの基本的なフィードバックループを「コンテキストを集める→行動する→作業を検証する→繰り返す」と説明しています。また、自分の出力を確認して改善できるエージェントは、誤りが積み重なる前に検知し、軌道から外れたときに自己修正できるため、より信頼性が高いとしています。［2］
ループの中で特に重要なのが、Verify、つまり検証です。
「なんとなく良さそう」とAI自身に判断させるだけでは、終了条件が曖昧です。テストの合否、ビルドの終了コード、lintの結果、期待値との差分、ブラウザ操作後の画面、パフォーマンススコアなど、AIが読み取れる具体的な信号を用意すると、失敗の理由を取り込みながら自律的に修正できます。
Anthropicのループ解説でも、チェックが定量的であるほど自己検証しやすいと説明されています。［1］ Claude Codeのベストプラクティスでは、AIが実行できる確認手段がなければ、人間自身が「検証ループ」になり、誤りは人が気づくまで待つことになる、とかなり明確に指摘されています。［3］
速いAIを導入するだけでは、人の確認待ちを高速で積み上げるだけになりかねません。AIが速さを品質へ変換するには、AI自身が失敗を観測できる仕組みが必要です。
ループエンジニアリングとハーネスエンジニアリングの関係
モデルの外側で、コンテキスト、ツール、権限、状態、再試行、停止条件、ログや監視をまとめて制御する実行基盤は、一般に「ハーネス」と呼ばれます。ループを実際に動かすのも、このハーネスです。
そのため、ループの設計はハーネスエンジニアリングの一部だと言えます。ただし、両者は完全な同義語ではありません。ハーネスエンジニアリングがAIを安全かつ継続的に働かせる外部環境全体を扱うのに対し、ループエンジニアリングは、その中でも「何を反復し、どう検証し、いつ終えるか」に焦点を当てた、より狭い概念として捉えると分かりやすいでしょう。
長時間の開発では、コンテキストウィンドウをまたいで作業を続ける必要があります。Anthropicも、長時間稼働するコーディングエージェントについて、進捗やテスト状態を次のセッションへ引き継ぐための明確な成果物が必要だと報告しています。［4］ ループを長く、強くするほど、状態管理まで含めたハーネスの設計が効いてきます。
ヒューマン・イン・ザ・ループから、ヒューマン・オン・ザ・ループへ
ループ設計を考えるとき、人間をどこへ配置するかは重要な論点です。
ヒューマン・イン・ザ・ループ（HITL）では、人がAIの処理フローの中に入り、確認や承認をしないと次へ進めません。たとえば、AIがコードを書くたびに人がレビューし、承認後にテストへ進み、再び人が確認してからマージする形です。
HITLは、判断責任が大きい工程や、失敗時の影響が読みにくい初期段階で有効です。一方で、AIが数分で実装できても、人のレビューが数時間後であれば、開発全体の速度は人の待ち時間に支配されます。AIの実行速度が上がるほど、人がボトルネックになる可能性があります。
ヒューマン・オン・ザ・ループ（HOTL）では、AIが定義された範囲内で実行・検証・修正を自律的に繰り返し、人はループの外側から状態を監視します。通常の各周回には入りませんが、異常、判断の曖昧さ、高リスクな操作、予算や試行回数の上限に達した場合には介入できます。
HOTLは「人をなくす」考え方ではありません。人の役割を、すべての処理を逐次承認することから、目的・制約・検証基準を設計し、例外を監督することへ移す考え方です。
AI駆動開発で時間を大きく短縮するには、テスト、修正、再テスト、定型レビューまでをAIの閉じたループに入れ、人は節目と例外に集中する「ヒューマン・オン・ザ・ループ（HOTL）」のループを設計することが重要です。
AI駆動開発におけるループエンジニアリング
AI駆動開発には、ミクロな実装から、プロダクト全体の価値確認まで、粒度の異なる複数のサイクルがあります。
CodexやClaude Codeなどのコーディングエージェントも、依頼すればテストやレビューを実行できます。しかし、組織固有の仕様、セキュリティ基準、UX基準まで含む多層のレビューサイクルが、自動的に完成するわけではありません。
そこで有効なのが、検証手順をスキルとして定義することです。「実装後にユニットテストを走らせる」「UI変更時はブラウザで操作する」「セキュリティチェックリストを確認する」「失敗したら修正して最初から再検証する」といった手順を再利用可能な形で持たせることで、レビューを偶発的な行動ではなく、開発ループの一部にできます。
基本サイクル：コードと同時に、周辺成果物も更新する
基本サイクルは、AIがコードを書くことに付随するタスクを、実装と同時に進めるループです。例えば、以下のようなアクションが組み込まれます。
SPECDOCをコードと同期する
SPEC駆動開発では、コードの縮図となるSPECDOCを用意します。一般的な仕様書との違いは、完成前に一度だけ作る文書ではなく、コードと密に連携し、コードが変わるたびに更新される「生きた仕様」であることです。理想的には、コードとSPECDOCが常に同期します。
人間だけでこの同期を維持するのは、開発規模が上がるほど現実的ではなくなります。しかし、変更のたびに「実装→テスト→SPECDOC更新→差分確認」を実行するループを組み込めば、AIが毎度行ってくれるため、更新漏れを減らすことができます。
「AIにとってはコードを読めば分かるので、あえて文書化する必要がないのではないか」と思うかもしれません。しかし、現在のLLMにはコンテキスト上限があります。毎回コードベース全体を読み込ませると、時間とトークンも増える上、アテンションの希薄化（コンテキストが長すぎて重要な情報の重要性が希薄化すること）が起こります。SPECDOCは、コードが圧縮された上方となるので、構造、責務、主要な判断、制約を圧縮して伝える索引になります。
ユニットテストを実装と同時に作る
コードだけでなく、その動きを担保するユニットテストの作成・更新も基本ループに含めます。
構造変更で既存のテストが動かなくなった、関数の入出力が変わった、想定していた例外処理が抜けた。こうした問題を実装直後に検知できれば、E2Eテストまで進んでから原因を探すより早く修正できます。
ユニットテストは品質保証であると同時に、AIが読み取れる明確なフィードバックです。「何が失敗したか」が具体的に返るため、AIは修正と再実行を自律的に繰り返せます。
コードレビューサイクル：組織の基準をチェックリストにする
コードレビューでは、一般的な効率性、冗長性、可読性、設計の妥当性に加え、プロジェクト固有の観点を確認します。
たとえば、認証・認可、入力値検証、秘密情報の扱い、依存ライブラリ、ログへの個人情報出力など、セキュリティのチェックリストをあらかじめ用意します。AIレビューをその基準に沿って繰り返すことで、「レビュアーがたまたま気づいた」状態から、「毎回同じ基準で検査される」状態へ変えられます。
また、実装を担当したエージェントとは別のエージェントにレビューさせることも有効です。Anthropicも、コードを書くループにはコードを確認するループが必要であり、新しいコンテキストを持つ別エージェントの利用を勧めています。［1］
振る舞いのレビューサイクル：AIがE2Eテストを実行する
コードとして正しく見えても、ソフトウェア全体が正しく動くとは限りません。各ユニットの相互作用、データの状態、画面遷移、外部サービスとの接続によって、実際の利用時だけ現れる不具合があります。
そのため、アプリケーションを起動し、ブラウザや端末を操作し、期待する振る舞いを確認するE2Eテストが必要です。AIにこの役割を持たせる場合は、「画面を開く→入力する→ボタンを押す→表示とデータを確認する→コンソールエラーを見る→失敗したら修正して最初から再実行する」という一連の流れをループとして定義します。
Anthropicも、UIなど視覚的なタスクでは、スクリーンショットやレンダリング結果をAIへ戻して比較・改善する「視覚フィードバック」を、検証手段の一つとして紹介しています。［2］
UXのレビューサイクル：正しく動くことと、使えることを分ける
不具合がなく、仕様書どおりに動くソフトウェアでも、使い手にとって分かりやすく、便利で、満足できるとは限りません。
そこで、ユーザーの視点（正確にはスキル）を持つAIがE2E操作を行い、不具合ではなく使い勝手をレビューするプロセスを入れれば、UX改善をAIが主体となって行うことができます。初めて触る人が次の操作を理解できるか。入力に迷わないか。空の状態やエラー時に立て直せるか。目的の仕事を少ない手順で終えられるか。こうした観点をユーザーストーリーやUX基準として定義し、問題があれば仕様や画面へ戻します。
AIによる開発は「コードを書くところ」から広がりつつあります。今後は、実装、コードレビュー、E2E、UXレビューを別々のエージェントやスキルが担い、互いの結果を受け渡す形が、AI駆動開発の一般的な構成になっていくと考えています。Polyscapeでも、この領域を継続的に研究しています。
AI駆動開発のレベルは「ループの強度」で上がる
私たちは、AI駆動開発のレベルは、ハーネスが定義するループの強度とともに上がると考えています。
ここでいうループの強度とは、単に反復回数が多いことではありません。ユニットテスト、コードレビュー、セキュリティ、E2E、仕様・UXレビューといった確認層の厚み、合否基準の明確さ、失敗を観測できる範囲、そして例外時に安全に止まれることの総体です。
段階1：エンジニア駆動
エンジニアが指示者とレビュアーになり、AIをコード生成や効率化に使う段階です。実行主体はエンジニアとAIで、人が逐一指示します。現在、広く使われているAIコーディングの基本形です。人は承認者というよりはあくまで指示者として動き、実働をAIが行うという意味で、「ヒューマン・ディレクテッド」なコンセプトといえます。
段階2：非エンジニア駆動
PMやビジネスサイドを含む人が自然言語で指示し、AIが主な実行を担う段階です。E2Eテストまでを安定して回すループがあれば、コードの細部を読めない人でも、要件と振る舞いを中心に開発を進めやすくなります。この段階においてもエンジニアが指示者となることはありますが、コードレベルでの指示ではなく、主に自然言語によって指示を行います。
さらに仕様・UXレビューまでループに含めれば、対象プロダクトの専門家ではない人でも、一定水準の使いやすさを備えたプロトタイプや業務システムへ近づけられます。もちろん、高リスク領域や専門判断が必要な領域では、その専門家を適切な節目に置く必要があります。
段階3：自律AI駆動
AIが指示、実行、レビューを担い、人はループの外から監視する段階です。今まではAIはコードを書く実行者でしたが、指示者側に回るという意味で、それまでの段階とは本質が変わります。
現在のAI駆動開発は、多くの場合「人間が指示者で、AIが実行者」という形です。しかし、強いループがあれば、AIが開発バックログや本番ログを読んだり、「請求書の管理が大変なのでなんとかしてください」といったざっくりとした目的から必要な作業を分解し、仕様定義、実装・検証・修正を進めることも視野に入ります。
この段階に入れば、ログを見てバグが発生してれば勝手に修正してリリースされる、ユーザーから問い合わせでバグが報告されたら勝手に修正される、AIが使い勝手の悪い点を見つけて勝手に修正される、と人間が介入しなくてもソフトウェア開発が勝手に進んでいきます。
2026年段階でこういった開発体制を実現している例はまだ少ないですが、Polyscapeでもそういった部分の研究をおこなっており、近い未来に実現されると考えています。
結びに：AIの性能を、仕組みの強さへ変える
AI駆動開発の品質は、使うモデルの性能だけでは決まりません。AIが実装した結果を自分で確かめ、失敗から戻り、次の層のレビューへ進み、適切な条件で終了できるか。そのループを支えるハーネスが、開発速度と安定性を左右します。
Polyscapeでは、SPECDOCの同期、ユニットテスト、コードレビュー、セキュリティチェック、E2E、仕様・UXレビューといった複数のループを、開発プロセスへ組み込む研究と実践を進めています。こうしたハーネスをあらかじめ用意することで、人の確認待ちや後工程での大きな手戻りを減らし、より少ないコストで安定性の高いソフトウェア開発を目指せます。
AI駆動開発の進め方や、自社の開発体制の変革など、AI駆動開発においてお悩みでしたら、AI駆動開発サービスの詳細をご覧ください。
ここまで読んでいただき、ありがとうございました。
Polyscape SF ジャーナル 