本記事は連載 「AI駆動開発 実践シリーズ」 の第4回です。
#1「バイブコーディングとAI駆動開発は何が違うのか」では個人開発でSpec駆動へ移った話、#2「組織でAI駆動開発を回すための方法論」ではチームへ広げる方法、#3「セッション×サブエージェントで作るAIプロジェクト体制」ではAIへの仕事の分け方を書きました。今回は、分けた仕事を人の逐次指示なしで回す方法を紹介します。
はじめに — 「AIに頼む」から「AIが自分で仕事を進める」へ
朝、AIへ「昨日の日記を書いて」と頼むことはありません。
私の環境では、毎朝決まった時刻になると、App Store Connect（ASC）の情報、各アプリのGitコミット、マージ済みPRなどを収集します。その事実から制作日記とアプリ別履歴を作り、DL数と国別データをホームページへ反映します。
私のホームページ
ASC実績から自動生成されたホームページ表示。数値はキャプチャ時点のもので、日次処理によって更新されます。
同じループで、前日の制作活動も自然言語の日記にまとめます。たとえば、実際に生成された2026年7月18日の記録には、次のように残っています。
2026-07-18 制作記録（一部）
Maker's Noteでは、ウィジェットごとのテーマ色選択を追加し、PR #44「Add per-widget theme color selection for v3.4.2」に結び付いた。記録上は、v3.4.2向けの変更としてマージまで確認できるため、次はこのテーマ色機能のリリース後状態を確認する。nichfulホームページでは、ブランド検索安定化の計画をアーカイブし、Nichfulのブランドエンティティ統一とApp Store Connectダウンロード指標の更新を行ったほか、アプリ紹介ページ・記事・英語ページなどの公開ファイルとサイト構成文書を更新した。
問題集アプリでも、最初に要件を渡した後は、企画・設計、テンプレート複製、実装、問題制作、多言語化、テストへ進む手順を整えています。
このように、AIを一度使うのではなく、AIが次の仕事を判断し、検証しながら進み続けられる仕組みを設計するのが、私の考えるループエンジニアリングです。
人が工程ごとにプロンプトを入力する代わりに、AIを動かす仕事の循環そのものを設計する。
ループエンジニアリングは、2026年6月に広がり始めた新しい呼び方です。まだ唯一の定義が確立した段階ではありません。しかし、AI駆動で業務をしていると多くの人が辿り着きます。「もっと指示を少なくしたい」「もっと自動化したい」と思うからです。
本記事では、私が実際に構築している自動化を基に説明します（Stop Hand-Holding Your Coding Agent）。
1. ループエンジニアリングとは
ループエンジニアリングとは、人の指示、時刻、イベントなどを起点に、AIが目標へ向かって工程を進め、検証結果に応じて続行、再実行、停止、人への差し戻しを判断できる仕事の循環を設計することです。
重要なのは、Triggerが定期実行だけではないことです。
- 人が「このアプリを作って」と指示する
- 毎朝7時15分になる
- PRがマージされる
- 新しいデータが保存される
- テストや監視が異常を検出する
どれもループの開始条件になります。
ループには、少なくとも次の要素が必要です。
| 要素 | 決めること |
|---|---|
| Trigger | 人の指示、時刻、イベントなど、いつ始めるか |
| Goal | 何を達成するか |
| Spec / Context | 何を正本として参照するか |
| Action | AIが何を作成・変更するか |
| Verification | 何をもって正しいと判定するか |
| Retry / Escalation | 修正して再実行するか、人へ戻すか |
| Stop condition | いつ完了・中止するか |
| Memory | 結果、失敗、判断をどこへ残すか |
近年のloop specificationに関する研究でも、Trigger、Goal、Verification、Stop、Memoryなどを、繰り返し使える境界付きの成果物として設計する考え方が示されています（Stop Hand-Holding Your Coding Agent）。
つまり、ループエンジニアリングは「AIが勝手に何でもする」方法ではありません。人が先に設計した境界の中で、AIが自走できるようにする方法です。
2. バイブコーディングとの共通点は「一度の指示で一気に作る」こと
バイブコーディングとループエンジニアリングは別物です。ただし、利用者から見ると大きな共通点があります。
最初に指示をすると、AIが製造やテストまで一気に進めてくれる。
たとえば「この要件でアプリを作って」と指示したとします。バイブコーディングでも、AIは不足する前提を補いながら画面とコードを作り、テストや修正まで進められます。
ループエンジニアリングも、最初の指示から完成まで進めます。
違いは、一気に作るかどうかではなく、その途中で本来の開発工程をどう扱うかです。
3. ウォーターフォールモデルで比べる
バイブコーディングは、要望から完成物までの距離を短くします。基本設計や詳細設計を独立した成果物として残さず、AIが内部で補正しながら実装へ進む場合があります。これが速さの源泉です。
一方、私が実践するループエンジニアリングは、次の工程を明示的に通ります。
- 要件定義
- 基本設計
- 詳細設計
- 製造
- 単体テスト
- 結合テスト
各工程には成果物と完了条件があります。要件定義が品質ゲートを通過したら基本設計へ進み、基本設計が通過したら詳細設計へ進みます。失敗した場合は、その工程を修正するか、人へ判断を戻します。
なお、ループエンジニアリングが必ずウォーターフォールモデルを採用するわけではありません。本記事では、私がSpec駆動開発で使用してきた工程を、そのまま自動実行する実践例として説明しています。
工程を飛ばして速くするのではなく、工程間の待ち時間をなくして速くする。
これにより、Spec駆動の品質管理を維持したまま、バイブコーディングのように一度の指示で開発を進められます。
4. 3つの違いを整理する
| 観点 | バイブコーディング | Spec駆動開発 | ループエンジニアリング |
|---|---|---|---|
| 起点 | 人の要望・対話 | 人が作成・承認したSpec | 人の指示、時刻、イベント、データ更新 |
| 一度の指示後 | AIが実装・テストまで進める | Specに沿って工程を進める | AIが複数工程を連続実行する |
| 工程 | 簡略化し、AIが不足を補正する | 工程、成果物、完了条件を定義する | Spec駆動の工程を仕組みとして実行する |
| 工程間の移行 | AIの判断や人との対話 | 人が確認・指示することが多い | 品質ゲートのPASS／FAILで制御する |
| 中間成果物 | 省略されることがある | 設計書、コード、テスト結果を残す | 各工程の成果物と判定結果を残す |
| 速度 | 速い | 人の受け渡しで待ち時間が生まれる | 工程間の受け渡しを自動化する |
| 品質 | AIの自己補正と人の確認に依存しやすい | Specとの整合を確認する | Spec、テスト、validator、人のゲートを組み込む |
Spec駆動開発は、ループエンジニアリングによって不要になるわけではありません。Specは、AIが各工程で読む正本であり、品質ゲートの判定基準です。
私にとってループエンジニアリングは、Spec駆動開発の品質を、バイブコーディングに近い速度で回すための進化形です。
5. 従来のバッチ処理へLLMを組み込む
仕組みは、一般的なシステム開発のバッチ処理に似ています。
従来のバッチ
Trigger → データ取得 → 固定ロジック → 検証 → 保存
LLMを含むループ
Trigger → 状態取得 → AIが判断・生成 → 検証 → 修正／停止 → 記録
Triggerは、時刻だけではありません。人がボタンを押す、コマンドを実行する、自然言語で要件を渡す、といった操作でも構いません。
従来のバッチ処理との大きな違いは、途中にLLMの判断や文章・コードの生成が入ることです。LLMの出力には揺れがあるため、「AIが終わったと言った」ことを成功条件にはできません。
- ビルドが成功したか
- テストがGreenか
- JSON Schemaを満たすか
- 件数と識別子が正本と一致するか
- 変更してよいファイルだけが変更されたか
このような機械的な証拠で判定します。
AIの「完了しました」という主張と、実際に工程を通過できる証拠を分ける考え方は、近年のevidence-gated lifecycleの研究でも扱われています（Proof-or-Stop）。
6. 実例①：問題集アプリを全自動で開発する
問題集アプリでは、共通テンプレートから新しいアプリを作る手順を整備しています。
企画・設計
↓ Gate
テンプレート複製・固有値置換
↓ Gate
アプリ固有実装
↓ Gate
問題制作・多言語化
↓ Gate
問題バンドル生成・検証
↓ Gate
ビルド・テスト
↓ Gate
リリース準備
2026年7月に制作したCCDV-Fでは、テンプレート複製、固有実装、318問・5言語の問題制作、検証までをこの流れで進めました。
問題は25個のバッチへ分けています。制作途中のデータを製品へ直接入れず、次の経路を通します。
制作正本
↓ assemble
検証用バンドル
↓ validate
内容・構造の確認
↓ approve
承認済み成果物
↓ promote
製品バンドル
生成、検証、昇格を分けたのは、AIが一気に作った成果物を、そのまま製品へ入れないためです。
まだ「厳密な全自動」ではない
ここは正直に書かなければなりません。
AIだけで大量の問題と翻訳を生成し、validatorやテストを通すところまでは進められます。しかし現時点では、内容品質、翻訳の意味、実機での見え方、Apple側の操作、公開判断には人の確認が残っています。
機械検証を通過しても、内容が利用者にとって良いとは限りません。構造として正しい文章が、学習問題として適切とは限らないからです。
全自動化で最も難しいのは、作らせることではありません。「正しく終わった」と判定することです。
7. 実例②：PR・ASC・日記・ホームページを1本のループにする
もう1つは、毎朝の事業運営ループです。
毎朝7:15
↓
ASCから最新の分析データを取得
↓
全期間の実績を集計
↓
公開用データを生成・検証
↓
ホームページの実績を更新・公開
↓
ASCの公開履歴と各種Reportを生成
↓
Gitコミット・マージ済みPR・更新ファイルを収集
↓
日次の制作記録とアプリ別履歴を生成
OpenAIのCodex Automationsも、スケジュールやTriggerで反復作業を実行し、結果をレビューへ戻す用途を案内しています（Automations）。私の環境では、その仕組みとローカルの集計・検証処理を組み合わせています。
冒頭に載せたホームページ表示と日記は、このループから生まれた実際の出力です。
ホームページへ公開するのは、検証済みの実績データだけです。次の場合は処理を止めます。
- ASCから最新データを取得できない
- ダウンロード総数や国数が正本と一致しない
- 変換できない国コードがある
- ホームページに無関係な未コミット変更がある
-
main以外のブランチである - 公開処理が失敗した
成功した場合だけ生成物をコミットし、ホームページへ反映します。失敗した日は、前回の正常な公開状態を維持します。
このループでは、LLMだけが主役ではありません。既存の集計処理、Git、検証、公開処理の間をAIがつなぐことで、事業運営の一連の流れになっています。
8. ループを作るのは、会社を作るのと似ている
起業直後は、経営者が営業、制作、経理、顧客対応をすべて自分で行います。
仕事を繰り返すうちに、手順と判断基準が見えてきます。そこで初めて、部下へ任せられる仕事が増えます。Agentへの委譲も同じです。
| 段階 | 状態 |
|---|---|
| 0 | 人がすべて作業する |
| 1 | 繰り返し部分をスクリプト化する |
| 2 | Agentへ狭い作業を任せ、人が確認する |
| 3 | テストとvalidatorを加え、失敗時だけ人へ戻す |
| 4 | 複数工程をつなぎ、状態と履歴を残す |
| 5 | 人の指示または自動Triggerから、記録・反映まで一気に回す |
最初から「全部やって」と任せても、安定したループにはなりません。
人が一度も正しく実行できない仕事は、手順も完了条件も定義できません。まず自分で仕事を理解し、失敗しても影響が小さく、正誤を判定しやすい範囲から任せます。
9. 精度を上げるのは、モデルより「蓄積した仕組み」
問題集アプリを作るたびに、トラブルシューティングとナレッジを残しています。
- コピー元アプリの識別子が残った
- 問題文と解説の対応がずれた
- 大量翻訳に別言語が混ざった
- 並列処理で同じファイルが競合した
- 正しい生成物でも、製品へ反映する順序を誤った
これらを、その場で修正して終わりにはしません。
トラブル発生
↓
原因を特定
↓
手順・テスト・validator・禁止事項へ反映
↓
次のアプリ／次の実行で自動確認
「AIが日に日に賢くなる」というより、AIが読むルールと、AIの仕事を判定する仕組みが日に日に強くなるという表現が正確です。モデル自体が私の失敗から自動学習しているわけではありません。
ループの精度は、高性能なモデルへ変更した時だけ上がるのではありません。失敗を再発防止へ変換するたびに上がります。
10. 注意点 — 自動化できることと、任せてよいことは違う
誤りも高速化する
検証が弱いループは、誤ったコードや文章を人間より速く大量生産します。生成量ではなく、品質ゲートを通過した状態を進捗として扱います。
LLMだけに採点させない
AIによるレビューは有効ですが、AIが作り、同じ前提でAIが採点すると、共通の盲点が残ります。ビルド、テスト、Schema、件数、差分など、機械的な検証を優先します。
停止条件を置く
再試行回数、時間、トークン、費用の上限を決めます。同じ失敗が続く、権限が必要、正本が見つからない場合は、人へ戻します。
権限を絞る
削除、課金、公開、App Store提出、CloudKit Production反映などは、人の承認を残します。技術的に自動化できても、外部へ影響する判断まで任せる必要はありません。
状態を会話だけに残さない
Spec、Git、ログ、進捗、テスト結果へ状態を保存します。会話が終わっても、次のAgentが同じ場所から再開できることが重要です。
11. 最初のループは、小さく作る
導入時は、次の順番で十分です。
- 毎日・毎週繰り返している仕事を1つ選ぶ。
- 人が行っている手順を書き出す。
- 入力、正本、出力、完了条件を決める。
- 正誤を機械的に判定できる検証を1つ置く。
- 失敗時は自動修正せず、最初は人へ戻す。
- 安定してから再試行、記録、スケジュール実行を追加する。
最初の題材には、次のような仕事が向いています。
- 前日のコミットとPRから日報の下書きを作る
- 定期的にリンク切れや依存関係を確認する
- テスト失敗を分類し、修正候補を作る
- 定型データを集計し、検証済みのレポートを作る
いきなりアプリ全体を作る必要はありません。小さなループを安定させ、その出力を次のループの入力へつなぎます。
まとめ
- ループエンジニアリングは、AIへ毎回指示する代わりに、AIを動かす循環を設計する。
- Triggerには、時刻やイベントだけでなく、人が最初に出す指示も含まれる。
- バイブコーディングと同じく、一度の指示で製造・テストまで一気に進められる。
- バイブコーディングとは異なり、決められた工程、品質ゲート、停止条件に従って動く。
- Spec駆動開発を置き換えるのではなく、Specを実行可能なループへ発展させる。
- 工程を省略せず、工程間の待ち時間を自動化することで、Spec駆動の品質とバイブコーディングの速度を両立する。
- 失敗を手順、テスト、ナレッジへ戻すほど、次のループが強くなる。
AIへ仕事を頼むのではなく、AIが仕事を続けられる会社を設計する。それが、私の考えるループエンジニアリングです。
次回予告（#5）：「AIの外部脳で事業を運営する」。ループが生んだ事実、判断、失敗、改善を、次の仕事へ使える形で残す情報設計を書きます。更新に気づけるよう、フォロー・ストックしておいてもらえると嬉しいです。