ループエンジニアリングとは——AIが自分で改善を回す仕組み

ループエンジニアリングとは、AIに単発の作業を頼むのではなく、「作る→測る→直す」という改善サイクル（ループ）ごと設計して任せる手法です。指示の言葉を磨くのではなく、AIが自分で成果を測って直し続ける仕組みそのものを設計します。

この記事は、この新しい言葉の意味を知りたい経営者・AI実践中級者に向けて、定義、プロンプト・コンテキスト・ハーネスエンジニアリングとの違い、そして実際に動いている改善ループの実物と作り方5ステップをまとめます。実は、いま読んでいただいているこのブログ自体が、ループエンジニアリングで動いている実例なんですよね。

ループエンジニアリングとは何か——AIが自分で改善を回す仕組み

これまでのAI活用は、人がプロンプト（AIへの指示文）を書き、AIが1回の成果物を返す一問一答が基本でした。ループエンジニアリングが設計するのは、その外側です。何をきっかけに動き、何を作り、何の数字で成果を測り、その数字を見て次に何を直すのか——このサイクル全体をあらかじめ設計し、AIに繰り返させます。

任せる単位が「作業」から「改善サイクル」に変わる

たとえば「記事を1本書いて」は、ただの作業依頼です。これに対して「毎日決まった時刻に記事を作り、公開後の検索データを毎週測り、伸びない記事の改善案を出し、次に書くテーマを補充し続けて」まで任せるのがループエンジニアリングです。人間の仕事は、指示を打つことから、回り続ける仕組みの設計と要所での承認に変わります。

大事なのは、ループは単なる定期実行ではないという点です。毎日同じ処理を繰り返すだけなら従来の自動化と変わりません。実測データを読んで、AIが毎回違う判断を下すからこそ「改善」のループになります。

なぜ今この言葉が出てきたのか

この言葉は2026年6月ごろ、海外の著名開発者Peter Steinberger氏の投稿をきっかけの一つとして、「プロンプトエンジニアリングの次はループエンジニアリングだ」という文脈で一気に広まりました（出典は記事末尾）。背景にあるのは、AIエージェント——指示を待たず、道具を使いながら自走するAI——の実用化です。1回の応答の質は、もうモデルの性能だけで十分に高くなりました。モデルの性能が上がるほど、差がつくのは1回の指示のうまさではなく、改善サイクルの設計になります。

ただし、正式な定義が固まった言葉ではまだありません。この記事の定義も、実際にループを運用している実務者としての僕の整理だと思って読んでください。

プロンプト・コンテキスト・ハーネスエンジニアリングと何が違うのか？

AIの世界は「◯◯エンジニアリング」という言葉だらけで混乱しますよね。この4つは対立する概念ではなく、設計する対象が違うだけです。1行ずつ言い換えると、次のようになります。

• プロンプトエンジニアリング——AIへの1回の指示文を磨く技術。設計対象は「何を言うか」

• コンテキストエンジニアリング——AIに渡す資料や背景情報を整える技術。設計対象は「何を見せるか」

• ハーネスエンジニアリング——AIが安全に働ける作業場（道具・検証・権限の枠組み）を組む技術。設計対象は「どこで働かせるか」

• ループエンジニアリング——作る→測る→直すのサイクル全体を設計する技術。設計対象は「どう回し続けるか」

僕の整理では、この4つは積み木の関係です。良い指示文（プロンプト）と良い資料（コンテキスト）を、安全な作業場（ハーネス）の中で、改善サイクル（ループ）として回し続ける。つまりループエンジニアリングは、他の3つを部品として含む、いちばん外側の設計です。どの言葉が正しいかを議論するより、自分がいまどの層を設計しているのかを意識するほうがずっと実用的です。

内側ループと外側ループ——2つの改善サイクル

ループには時間軸の違う2種類がある——この枠組みは、YouTubeのClaudeCodeチャンネルの動画から借りたものです（出典は記事末尾）。自分の運用に当てはめてみて、この2分類は実務の解像度を大きく上げてくれました。

内側ループ——1つの成果物を合格まで磨く（分単位）

内側ループは「作る→機械が合否判定→不合格なら直す」を、合格が出るまで繰り返すサイクルです。ポイントは、合否を人間の目視ではなく機械的な基準（文字数・必須要素・リンク切れなど）で判定すること。基準が機械化されているから、人間が寝ていても品質が守られます。僕のブログでは全記事が公開前にこの機械ゲートを通過していて、チェック項目の実物は次の記事で公開しています。

関連記事AI記事作成の品質管理——公開前に自動で守る機械ゲートの作り方AIに記事を書かせたいが品質が心配で任せきれない。その答えは人力チェックの強化ではなく、公開前に自動で合否を判定する機械ゲートです。僕のブログ全記事が通っている検査項目の実物と作り方5ステップを公開します。→

外側ループ——公開後の実測で次の一手を決める（週〜月単位）

外側ループは、公開のあとに始まります。検索でどれだけ表示されたか・クリックされたかの実測を取り、「順位が惜しい記事はリライト」「表示は多いのにクリックされない記事はタイトル改善」「拾えていない検索語は新規記事」と、次の一手をデータで決めるサイクルです。検索結果への反映には数週間かかるため、内側ループが分単位で回るのに対し、外側ループは週から月の単位で回ります。

実例公開：このブログ自体がループエンジニアリングで動いている

概念の説明はここまでにして、実物を見せます。このAIVESTブログは、僕が設計した3つの自動ジョブで「作る→測る→直す→補充する」が回っています。

毎週この順番で回っている3つの自動ジョブ

• 記事の自動生成（毎日9時12分と15時7分）——企画在庫（バックログ）からテーマを選び、執筆し、機械ゲートを通し、下書き投稿まで無人で進む

• 実測の自動取得（毎週月曜9時0分）——Google Search Console（検索での表示回数・順位が見える無料ツール）とGA4（アクセス解析ツール）から直近1週間の数字を取り、計測ログに1行追記する

• 週次の診断ラン（毎週月曜9時42分）——たまった実測を読んで、リライト候補・タイトル改善候補を提案し、まだ拾えていない検索語を新規テーマとしてバックログに補充する

起動はMacに標準搭載されている予約実行の仕組み（launchd）です。月曜の朝は、9時に計測が走り、42分後にその数字を読んで診断が走る、という順番で設計してあります。そして診断ランのスクリプト冒頭には、僕はこういう運用原則を書き込んであります。

公開物の変更はしない（リライト・タイトル変更の実行は人間の承認後。提案までが仕事）

実測ログの実物——ゼロでも計器は動いている

正直に書くと、このサイトは公開から日が浅く、検索の実測はまだほぼゼロです。計測ログkpi.jsonl（1週間ごとに1行たまる記録ファイル）に自動追記された実物の1行が、これです（一部項目を省略）。

{"date":"2026-07-20","week_start":"2026-07-12","week_end":"2026-07-18","published_total":6,"gsc_impressions_7d":0,"gsc_clicks_7d":0,"note":"auto(pull_metrics)"}

表示回数ゼロ。それでも、実測がゼロのうちから毎週自動で記録が残り始めた時点で、外側ループは動き始めています。改善サイクルは数字が貯まってから作るものではなく、数字が貯まる前に計器ごと設計しておくものだからです。ちなみに、記事の材料になる毎朝の自動リサーチも同じ思想の別ループで回しています。作り方はこちらの記事にまとめました。

関連記事Claude Codeに毎朝のリサーチを任せる仕組みの作り方毎朝9時にClaude Codeが追跡リストを巡回し、「今日の動き」を1枚に合成して通知する——2026年6月から無人で回り続けている僕の実運用をもとに、リサーチ自動化を組む5ステップと続けるための設計を解説します。→

自分の業務で改善ループを作る5ステップ

僕が新しいループを組むときに使っている手順です。Claude Codeのような対話型のAIエージェントに「この手順で仕組みを作って」と日本語で渡せば、スクリプト作成や予約実行の設定はAI側が進めてくれます。

実行は自動、責任は人間——ループを暴走させない安全弁

ループエンジニアリングには、実害のある失敗例がすでに共有されています。コード修正のループが本来の趣旨からズレた修正を大量生産してしまい、成果物がほぼすべて却下された、という報告です（出典は記事末尾）。AIに改善サイクルを任せることは、放置することではありません。実行は自動、責任は人間。この原則を、精神論ではなく仕組みとして先に埋め込みます。

僕のブログの外側ループも、診断ランは「提案を書くまで」で止まり、リライトの実行は僕の承認後です。提案が的外れなら却下すればいいだけなので、暴走のしようがない構造になっています。

ループエンジニアリングに関するよくある質問

まとめ——「AIを使う人」から「改善ループを設計する人」へ

• ループエンジニアリングとは、「作る→測る→直す」の改善サイクルごとAIに任せる設計手法。定期実行との違いは、実測を読んでAIが毎回違う判断をすること

• プロンプト・コンテキスト・ハーネスの各エンジニアリングとは設計する層が違い、ループはそれらを部品として含むいちばん外側の設計

• 始め方は「週1回以上繰り返す」「機械が合否を判定できる」業務を1つ選び、計測の自動化から。人間承認・機械ゲート・上限という安全弁は最初に入れる

AIモデルそのものの性能差は、どんどん縮んでいきます。これから差がつくのは、どんな改善ループを設計して回し続けているかです。「AIを使う人」から「改善ループを設計する人」へ——この記事が、最初のループの設計図になればうれしいです。

出典

本記事のうち「内側ループ／外側ループ」という枠組みは1本目の動画から、言葉が広まった経緯と失敗例は2本目・3本目の投稿から借りました。一方、AIVESTブログの3つの自動ジョブ・計測ログの実物・週次診断ランの運用原則・作り方5ステップは、僕自身の実運用にもとづく一次情報です。4用語の比較整理には僕の解釈を含みます。

• ClaudeCodeチャンネル「AI社員を雇うは論外、ClaudeCodeが勝手にSEOメディアを運用する時代がやってきました」——内側ループ／外側ループの概念枠組み

• Peter Steinberger氏の投稿——ループエンジニアリングが話題になる発端とされるポスト

• オカムラ氏のX記事「Loop Engineeringについて」——定義の整理・実践事例・暴走の失敗例