ループエンジニアリングをやってみてわかったこと

生成AIを「質問して答えをもらう」道具として使う段階から、「AI社員」として業務そのものを任せる段階へ——わたしたちFROM CENTERでは、AIによる業務代行（AI-BPO）の取り組みを進めています。

実際に運用まで進めてみて分かったのは、成否を分けるのはプロンプトの書き方でも、読ませる資料の量でもなく、「実行→検証→改善のサイクルをどう回すか」だということでした。

この記事では、この設計をループエンジニアリングと呼び、わたしたちが社内で実験してみた構成と、やってみて分かったコツ、実際にハマった失敗を紹介します。

1. ループエンジニアリングとは？

プロンプトエンジニアリングが「1回の応答の質」、コンテキストエンジニアリングが「読ませる知識の構造」を扱うとすれば、ループエンジニアリングはエージェントの周りの循環そのものを設計する考え方です。

人の新入社員に例えると分かりやすいかもしれません。良い指示の出し方（プロンプト）や、マニュアルの整備（コンテキスト）はもちろん大事です。ただ、新入社員が本当に戦力になるのは、「日々の業務 → 報告 → フィードバック → マニュアル改訂」という運用のサイクルが回り始めてからです。AI社員も同じでした。

出発点は「AIの出力は、毎回は完璧にならない」という前提です。だからこそ、間違える前提で「どこで検証するか」「失敗や気づきをどう次に活かすか」「人間をループのどこに置くか」を、あらかじめ仕組みとして作り込みます。

今回は、ループを4種類に分けて設計しました。

① 実行ループ業務そのもの（前提チェック→実行→自己検証→報告）実行ごと

② 改善ループ実行中の「気づき」→ 人間の承認 → ルール正本の更新都度

③ 配布ループ更新したルールを全実行環境へ配るリリースごと

④ データ駆動ループ実行結果の計測 → 不足の発見 → 補充 → 翌サイクルで再計測月次など

いちばんのポイントは、フィードバックが正本（ルールの大元）に反映される経路に、必ず人間を挟んでいることです。AIが自分でルールを書き換える「全自動の自己改善」は、あえて作っていません（理由は後述します）。

2. 実際にやってみた構成

題材にした業務

社内で実際に運用している3つの業務を、AIエージェント（Claude Code）に任せました。守秘とサービス規約の観点から、具体的なサービス名や案件の詳細は伏せています。

業務A：外部サービス上の定型オペレーション対象データの抽出 → 基準との照合 → 個別処理。

業務C：Webサイトコメントのモデレーション保留コメントを ✅承認／❌スパム／⚠️グレー保留 の3分類で処理平日朝

全体像：正本はGitHubにひとつだけ

ルール（業務手順や判定基準）はGitHubのプライベートリポジトリに置き、これを唯一の「正本」としています。各実行端末へはClaude Codeのプラグイン（marketplace）として配布します。実行データやログは正本と混ぜず、リポジトリの外のストレージに分離しています。

ルールは「継承」で持つ

ループを回せば回すほど、ルールは増えていきます。放っておくと確実に破綻するので、ルールは共通 → サービス → サービス×案件の3層で継承させ、最下層は自己完結にしました。こうしておくと、改善ループで「どこを直すか」が一意に決まるため、あとで迷子になりません。

rules/
├─ common/                  ① 全業務共通の原則
└─ <サービス>/
   ├─ _common.md            ② そのサービスの操作・UI
   ├─ policy.md             ② そのサービスの利用規約・ポリシー（遵守必須）
   └─ <案件>/                ③ サービス×案件（判定基準・文面方針は自己完結）

① 実行ループ：1回の実行の中にも検証を入れる

「実行して終わり」にはせず、毎回の実行そのものを小さなループにしています。

• 前提チェック：ログイン状態や実行上限をまず確認。満たしていなければ実行せず、中止して報告
• 確定前の自己検証：内容・宛先・件数をスクリーンショットやDOMで確認してから確定
• 異常時は即中止：UIが想定と違う、データが食い違う——そんなときは推測で進めず、Slackへエスカレーション
• 重複防止：処理済みのものはスキップ

② 改善ループ：AIは提案、人間が反映

実行用アカウントに渡しているのは、リポジトリのRead権限だけです。実行中に「このルールは直したほうがよさそうだ」と気づくと、AIは正本を触らずに、Slackの業務チャネルへ「対象ファイル・変更案（before→after）・理由・緊急度」を添えて提案してきます。人間がレビューして正本に反映すれば、その学びは以後のすべての実行に効きます。ここが回り始めると、運用は目に見えて楽になっていきました。

③ 配布ループ：release と apply

• release：ルール編集 → バージョンを上げる → JSON検証 → commit/push → GitHubと一致しているか確認
• apply：各端末で git pull → プラグイン更新

地味な工程ですが、この手順自体もスキル化（手順のコード化）してあり、配布ミスがだいぶ減りました。

④ データ駆動ループ：不足が「見える」と勝手に回り出す

これはチャットbotの品質評価で実感しました。月次評価で「未回答」を必ずリストアップする設計にしたところ、未回答リストがそのまま「次に追加すべき模範解答のリスト」になったのです。評価 → 不足発見 → 人間が模範解答を追加 → 翌月の評価で改善を確認、というループが、特別な号令をかけなくても自然に回り始めました。

3. うまく回すコツ

やってみて「これは効く」と感じた設計のコツです。

1. 正本はひとつ。AIには書き換えさせない。
改善ループは全自動で閉じたくなりますが、あえて閉じていません。AIの「気づき」には誤検知も混ざるため、無審査でルールが書き換わっていくと、業務全体が静かに壊れていきます。人間の承認を挟むと改善のスピードは少し落ちますが、そのかわり「悪化しない」ことが保証されます。このトレードオフは十分に割に合うと感じています。

2. 取り返しのつかない操作にはゲートを置く。
確定前の自己検証、宛先の固定（ページの内容から動的に宛先を決めない）、迷ったら保留、確定操作の前には人の承認。ループは回り続けるものなので、1回の事故が周期の数だけ複製されます。ゲートはループとセットで設計するのが鉄則です。

3. 「不足が見える化される」仕掛けを入れる。
④のループが回ったのは、未回答リストという「不足の見える化」があったからでした。改善は気合だけでは続きません。「次に何を直すべきか」が毎サイクル自動的に出てくる仕組みにしておくのがおすすめです。

4. 配布までがループ。
ルールを直しても、実行環境に届かなければ何も起きていないのと同じです。「versionを上げないと配布されない」という制約を逆手に取り、リリース手順に必ずversion更新を組み込みました。

5. ルールはパス非依存・自己完結で書く。
絶対パスやバージョン番号入りのパスを埋め込むと、端末が変わった瞬間・更新した瞬間にループが止まります。プラグインのルート変数で参照し、どの端末でも同じルールが動くようにしておきます。

6. 初回は必ず dry run。
新しい業務・新しい対象を追加するときは、外向きの確定操作なしで、判定とログだけを検証してから本番スケジュールに載せます。当たり前のようですが、急いでいるとつい飛ばしたくなる工程です。

4. ハマったポイント（失敗談）

ここからは、わたしたちが実際に踏んだ失敗です。同じところでつまずく方が減れば幸いです。

失敗1：実行環境の選択ミスで「動くのに動かない」。
ブラウザ操作が必要な業務を、クラウド実行や素のCLI、OSのタスクスケジューラ＋CLIで動かそうとして、見事に空振りしました。エージェント自体は正常でも、ブラウザに手が届かない環境では業務が成立しません。結局、デスクトップアプリ内のエージェント＋ローカルスケジューラの組み合わせに固定して解決しました。ループエンジニアリングというと設計の話に聞こえますが、実行環境の制約確認が先——これを痛感しました。

失敗2：version上げ忘れで、直したはずのルールが配布されない。
ルールを直してpushしたのに、versionを上げ忘れて各端末が「もう最新」と判断してしまい、更新されないという事故です。③のループが静かに切れるため、なかなか気づけません。リリース手順ごとスキル化して再発防止しました。

失敗3：バージョン番号入りの固定パスで、更新後に停止。
スケジュールタスクに …/plugin/2.4.0/… のようなパスを書いてしまい、更新でそのフォルダが消えた瞬間に読み込みが失敗しました。スキル名で起動するか、実行時に解決される変数を使うのが正解です。

失敗4：サービス側の検索フィルタを過信。
検索・絞り込みフィルタの条件と、実際にヒットするデータの中身がズレていて、本来対象外のものが混ざっていました。「入力条件＝実態」とは限りません。以来、個別の内容で実態を確認するルールを実行ループ側に追加しています。こうした現場の気づきが②の改善ループで正本に還流していくのは、ループエンジニアリングのいちばんの効能だと感じています。

失敗5：「共通のはず」と上位層に置いたルールで対象外が混入。
「この案件の判定基準はどのサービスでも共通のはず」と上位層に置いたところ、サービスごとに対象セグメントが違い、あるサービスでは対象外の層まで含みかけました。判定基準・対象はサービス×案件の最下層に自己完結させ、各ルールの冒頭に「対象はこれ。これ以外は処理しない」と明示する形に修正しました。

失敗6：後始末までループに入れていなかった。
無人実行がブラウザのタブを開きっぱなしにしていく問題です。「開いたら記録 → 終了直前に記録と突合して閉じる → 報告に後始末欄を必ず書く（記載がなければ実施忘れ扱い）」という手順まで実行ループに組み込んで解決しました。報告フォーマットに欄を作っておくと、抜けが構造的に検出できる——これは他の業務でも使える小技だと思います。

5. まとめ

ループエンジニアリングを実験してみて分かったのは、これは突き詰めると「人間をどこに置くかの設計」だということです。

• 毎回の実行に、自己検証と中止条件を入れる（① 実行ループ）
• AIの気づきは、人間の承認を経て正本に還流させる（② 改善ループ）
• 直したルールは、版管理で確実に全環境へ配る（③ 配布ループ）
• 「不足」が毎サイクル見える化される仕掛けで、改善を駆動する（④ データ駆動ループ）

AIは1回ごとの賢さで勝負させるより、回るたびに仕組みが良くなる構造に置いたほうが、はるかに戦力になります。プロンプトの次はコンテキスト、コンテキストの次はループ。エージェント運用に取り組む方の参考になればうれしいです。