ループエンジニアリングとは？AIエージェントに指示を出す仕組みを設計する

毎朝、非定型の面談メモを一つずつ読み返し、連絡が途絶えている顧客へ送るフォローの文面を考える作業に追われていませんか。毎日人間が手作業でAIに指示を打ち込む運用では手間がかかり、かといって顧客管理システムの単純な期限通知だけでは、商談の複雑な背景までは読み解けません。

そこで役立つのが、いつどのような条件でAIを実行し、停止し、人に処理を引き継ぐかという一連の仕組みを設計する「ループエンジニアリング」という考え方です。人が毎回指示を出すのではなく、あらかじめAIが自律的に動いて判断するルールを定めます。

本記事では独自の架空の営業フォロー業務を例に、この仕組みを設計する方法を解説します。AIの役割を非定型の面談メモからの「連絡理由と質問案」の作成に絞り、最終的に人間が元記録を確認して顧客への連絡を決めるまでの、発火から検証、停止に至る手順を見ていきましょう。

ループエンジニアリングとは何か
営業のフォロー業務を六段階のループにする
前回の記録と現在の商談情報を照合する
最初の設計表に何を書くか
AIの提案を元記録で確かめる
件数、時間、費用、人の承認で止める
報告だけで試し、権限を段階的に広げる
ハーネスとグラフとの違い
よくある質問
調査手法について

ループエンジニアリングとは何か

散らばった個別の指示と一つの発火条件を左右で分け、毎回の手入力から条件設定への移行を示す。

AIエージェントへの指示（プロンプト）を人間がその都度打ち込むのではなく、いつ、どのような条件でAIを実行し、停止し、人に処理を引き継ぐかという一連の仕組み（ループ）を設計する考え方を「ループエンジニアリング」と呼びます。

業務へのAI導入を考える際、「人が逐次指示を出す方法」「単純な定期通知」「結果に応じて次の行動を変えるループ」の3つを明確に区別することが重要です。

1つ目の「人が逐次指示を出す方法」は、人間が毎日AIの画面を開き、「この顧客の過去のメモを読んで、次のアクションを提案して」と手作業で打ち込む運用です。最初は便利でも、対象件数が増えると個人の業務を大きく圧迫します。

2つ目の「単純な定期通知」は、CRM（顧客管理システム）などの既存機能を使って「最終接触から14日が経過した顧客をリストアップする」といった機械的なリマインダーのことです。このような定型的な期限通知だけであれば、通常のシステムのアラートやタスク生成ルールで十分であり、高度なAIを使う必要はありません。

3つ目の「結果に応じて次の行動を変えるループ」こそが、ループエンジニアリングが目指す形です。単なる条件による通知にとどまらず、複雑で非定型な商談メモなどをAIが読み解き、その内容を踏まえて「なぜ今連絡するのか」「どのような質問案が適切か」を判断し、次の行動を自律的に提案する仕組みを指します。

架空の営業チームが毎朝行う「商談フォロー候補選び」を独自の設計例として、具体的なイメージを見てみましょう。

まず、「毎朝9時」といったスケジュールを発火（トリガー＝処理を始めるきっかけ）と定義します。ここで無条件にAIを動かすのではなく、まずは定型的なプログラムが「前回から一定期間経過した商談」という作業の有無を発見し、真に必要な場合のみAIエージェントに処理を委譲します。

次にAIエージェントは過去の面談メモを読み込み、顧客への連絡理由と質問案を作成します。しかし、AIの作った文章をそのまま顧客へ自動送信するわけではありません。意図しない動作を防ぐために、処理の回数上限といった機械的な停止条件や、最終的な人への引き継ぎをあらかじめ設計しておきます。

最後に、営業担当者がAIの提案内容と原記録である商談画面を照らし合わせて確認し、連絡の採否や実際の送信を決定します。このように、人とAIの役割分担や、AIの出力を人が評価・検証する手順を明確に定めることが、安全にループを運用する第一歩となります。

営業のフォロー業務を六段階のループにする

AIエージェントを自律的に動かしつつ適切に制御するためには、ループの一巡をどう組み立てるかが重要です。本記事独自の架空の設計例として、営業チームの「未対応商談のフォロー」を六つの段階に分けて見てみましょう。全体の流れは、発火、候補発見と選定、AI実行、根拠検証、状態更新、そして停止または引き継ぎの六段階です。

発火（処理の開始） まずは処理を始めるきっかけである「発火」を決めます。例えば、「毎朝9時」といった定刻のスケジュールや、顧客管理データの更新などをトリガーとします。このとき、定期実行の重複を防ぎ、状態を固定する設計を行っておくことが基本です。
候補発見と選定 発火後、すぐにAIを動かすわけではありません。まずは定型的なプログラムで「最終接触から14日が経過した未対応商談」が存在するかを確認します。単純な条件による絞り込みの通知だけであれば既存システムのタスク機能やリマインダーで十分です。対象となる商談が一つもなければ、AIを呼び出すことなくここで処理を終了させます。
AI実行 フォローすべき商談候補が見つかった場合のみ、実際の調査や作成作業をAIエージェントへ委譲します。AIは対象となった商談の非定型な面談メモや過去の履歴を読み込みます。その内容を分析して、「なぜ今この顧客に連絡するのか」という連絡理由と、次に尋ねるべき質問案を作成します。
根拠検証 AIが作成した連絡理由や質問案が妥当かを確かめます。AIの出力結果に対し、別の検証用の仕組みを用いて、必要な情報が指定の形式で揃っているか、商談IDと根拠への参照が揃うかを機械的に確認し、内容の妥当性は担当者が元記録で判断します。人とAIの役割を明確にし、検証の仕組みを設計することで、提案の質を保ちます。
状態更新 処理がどこまで進んだか、どの商談に対してどんな質問案を作ったかという結果を記録し、次回以降の実行へ渡す情報として保存します。これにより、翌日以降の処理で「すでに質問案を作成済みの商談」を二重に処理してしまうことを防ぎ、次回のループの分岐へとつなげます。
停止または引き継ぎ 処理の暴走を防ぐため、あらかじめ定めた処理件数や費用の上限に達したら、機械的な停止や人への引き継ぎを行います。最終的にAIは作成した連絡理由と質問案を報告として提出します。営業担当者は、提出された報告と元の商談画面を確認し、実際の連絡の採否や顧客へのメール送信を最終判断します。

このように六段階の工程を一巡させることで、AIは単なるテキスト生成にとどまらず、営業のフォロー業務を自律的に支援する仕組みとなります。

前回の記録と現在の商談情報を照合する

AIエージェントの反復処理において、変わらないルールである固定する設計と、実行のたびに書き換わる更新する状態を分けて管理することが基本です。前回のループで更新された状態の記録は、次回の処理を始めるための重要な手掛かりとなります。しかし、処理を再開する際に「前回の記録をどこまで信じてよいのか」という疑問が生じます。

営業チームのフォロー業務で考えてみましょう。AIエージェントは前回の実行時に、対象となる商談ID、その時点での更新時刻、AIによる前回の判定結果（連絡理由や質問案など）、そしてそれに対する営業担当者の採否を記録し、次回以降に引き継ぐ状態として保存したとします。

ここで注意すべきは、記録された状態と現在の現実が乖離しているリスクです。状態を管理するファイルには「未対応の商談」として記録されていても、次の処理が始まるまでの間に、営業担当者が顧客に直接電話をかけ、実際の商談画面（CRMなどの顧客管理システム）を手動で更新しているかもしれません。

このような古い状態の情報をそのまま信じて、新たな作業の発見とAIへの委譲を再実行してしまうことは、意図しない変更や無駄な処理を引き起こす原因となります。状況がすでに変わっている顧客に対し、AIが過去の情報をもとに的外れな質問案を作成してしまうといった失敗につながるからです。

そのため、反復処理の入口で誤った状態を読み込まないためには、前回の状態の記録と現在の現物を必ず照合する設計が必要です。保存された商談の更新時刻と、実際の商談画面における最新の更新時刻を比較し、最新の事実を確認します。

また、AIからの提案を受けて、人は原記録と商談画面を確認し、連絡の採否と顧客への送信を決めます。そのため、営業担当者による採否の判断結果が現在の商談情報に反映されているかどうかも、重要な照合の対象となります。

すでに担当者が対応を済ませた対象や、状況が変化した商談を再処理の候補から除外して初めて、AIエージェントは正しく次の行動を選ぶことができます。

つまり、次回の実行において信じるべきは「記録そのもの」ではなく、「現物との照合を通過した記録」です。状態の記録はあくまで前回終了時点のスナップショットであるという前提に立ち、再開時には必ず実際の環境と突き合わせてから処理を進める工程を組み込んでください。

最初の設計表に何を書くか

AIエージェントに自律的な業務を任せる際、発火から停止条件、状態、検証、人への引き継ぎまでの一連のサイクルを設計する「ループエンジニアリング」の考え方が役立ちます。この全体像を把握するため、あらかじめ各工程のルールを一つの設計メモに整理しておくことが重要です。

営業チームの定期フォロー業務を設計する際、設計メモの各項目にどのような値を入れるべきかを解説します。

開始条件と候補条件 定期的に処理を始めるきっかけ（発火）と、対象の絞り込み条件です。例えば「毎朝9時に実行する（開始条件）」とし、「最終接触から14日以上経過し、かつ失注していない商談（候補条件）」を対象として探し出します。
読み取る情報とAIへ任せる判断 ただ期限を通知するだけの単純なリマインダーであれば通常の顧客管理システムのタスク機能で十分です。AIを活用する利点は、非定型の面談メモやメールの履歴（読み取る情報）を深く読み解けることにあります。過去のやり取りを踏まえ、「なぜ今連絡すべきかという理由」と「顧客へ投げかける質問案」を考えさせる（AIへ任せる判断）といった業務を任せます。
残す成果物と根拠の確認 AIが作成した質問案は、システム上のコメントや下書きとして記録させます（残す成果物）。しかし、AIの提案が過去の経緯を誤認している可能性もあるため、商談IDと根拠への参照が揃うかを機械的に確認し、面談メモとの意味の一致は担当者が確認します（根拠の確認）。
次回に残す状態 処理対象となった商談IDやAIの提案内容、後述する人の採否結果などを記録し、次回の実行へ引き継ぐ情報として保存します。これにより、AIが同じ商談に重複して提案してしまうのを防ぎます。
止める条件と人の承認 想定外のエラーや不要なコストを防ぐため、AIを停止させる上限を設けます。例えば「一度の実行につき提案は10件までとする」「システム処理時間が10分を超えたら止める（止める条件）」といった制限です（件数や時間はあくまで架空の例示です）。そして最終段階として、人間が原記録と実際の商談画面を確認し、提案された連絡の採否と顧客への送信を決定します（人の承認）。これこそが、人とAIの役割分担を明確にする設計の要となります。

このように、作業の発見からAIへの委譲、検証、状態保存までの実務パターンを設計メモに書き出すことで、各工程の目的が明確になり、実務へ安全にAIエージェントを導入する第一歩を踏み出せます。

AIの提案を元記録で確かめる

AIエージェントが作業を終えた後、その結果を次のアクションへ進める前には、内容が本当に妥当であるという証拠を確認しなければなりません。AIからの「提案が完了しました」という報告を鵜呑みにせず、出典不足や事実の取り違えを未然に止める仕組みが必要です。

自律的なエージェントであっても、作業を行ったAI自身に結果を評価させるのではなく、作業を行う役割と、結果を検証する役割を明確に分けて設計します。

営業チームの定期フォロー業務で考えてみましょう。AIは過去の非定型な面談メモを読み解き、「顧客へ連絡する理由」と「質問案」を提案します。このとき、AIが作成した提案文だけを受け取る仕組みにしてはいけません。必ず、提案の根拠となった面談メモの原文や、現在の顧客管理システム上の商談画面といった客観的なデータ（元記録）をセットで提示させ、両者を突き合わせる工程を設けます。

人間である営業担当者は、AIがもっともらしく書いた提案文だけを読むのではなく、その提案が元の面談メモの内容や文脈と一致しているか、事実関係に誤りがないかを確かめます。人は原記録と実際の商談画面を確認したうえで、初めて連絡の採否を判断し、顧客への送信を決めることになります。このように作業と検証を分けることで、人とAIの役割分担を明確にし、安全性を高めることができます。

ここで特に注意すべき失敗例として、「Verifier Theater（検証の劇場）」と呼ばれる状態があります。これは、検証する側が実際の面談メモや商談履歴といった客観的な証拠を確認せず、作業をしたAIが生成した「過去の課題に基づき、適切に質問案を作成しました」という承認用の文章だけを見て、形式的に通過させてしまう状態を指します。

このような実態のない検証を許容してしまうと、AIが過去の経緯を誤認しているにもかかわらず顧客へ的外れな連絡をしてしまう危険性が高まります。事実に基づいていない提案がそのまま顧客へ届くことは、営業活動において大きなマイナスです。

こうした事態を防ぐため、ループエンジニアリングを設計する際は、作業と検証の工程を独立させて評価します。元の記録という具体的な証拠が揃っていない場合や、事実との差分が確認できない場合は、次の処理へ進めないようなルールを設けることが、確実な業務運用への鍵となります。

件数、時間、費用、人の承認で止める

前段で述べたように、客観的な証拠に基づく検証は重要ですが、もし検証で不合格となった場合にAIエージェントへやり直しを任せきりにすると、新たな問題が生じます。AIの自律的な処理を無制限の再実行へ変えないためには、「処理をいつ止めるか」という条件をあらかじめ厳格に設計しておく必要があります。

単純な期限通知であれば通常のCRMタスク機能やルールなどで十分ですが、AIが非定型の面談メモを読み解いて連絡理由を考えるような処理では、予期せぬ暴走を止める仕組みが重要になります。ループエンジニアリングにおける停止条件は、主に「成功」「候補なし」「上限」「根拠不足」「承認待ち」といった状態に分類して設計し、いずれかに該当した時点でエージェントの処理を機械的に停止させます。

特に「上限」による停止は、システムリソースの枯渇を防ぐための命綱です。具体的には、同じ失敗に対する無限のやり直しを避けるための最大反復回数（件数）、処理が長引きすぎた場合の強制終了（時間）、そして想定外のAPI呼び出しによるトークン浪費を防ぐための予算上限（費用）をあらかじめ定めます。

営業チームの定期フォロー業務における停止分岐を見てみましょう。まず、処理のきっかけとなる発火段階で、フォローすべき対象が存在しなければ、「候補なし」としてAIを呼ばずに直ちに処理を終了します。

次に、AIが面談メモから顧客へ連絡する理由と質問案を提案しようとした際、メモの記述が乏しく判断できない場合があります。このときは無理に文章を生成させず、「根拠不足」として処理を停止し、そのまま人間の担当者へ引き継ぎます。また、AIが条件を満たそうと文章の再生成を繰り返しても、あらかじめ定めた設定回数や上限時間に達した場合は、それ以上の再試行を行わずに停止させます。

最終的に、AIが面談メモに基づいた適切な連絡理由と質問案を生成できた場合でも、そのまま自動で顧客へ連絡してはいけません。処理自体は「成功」したとみなしつつ、状態としては「承認待ち」でループを止めます。人間である営業担当者は、AIの提案内容だけでなく原記録と商談画面を確認したうえで、連絡の採否を判断し、顧客への送信を決定します。

このように、件数・時間・費用の上限と、状況に応じた停止分岐を設けることで、業務への安全な組み込みが可能になります。AIを動かし続けることよりも、適切なタイミングで確実に止めて担当者へ渡す設計が不可欠です。

報告だけで試し、権限を段階的に広げる

ここまでに、処理の開始から停止条件の設計、そして人への引き継ぎといった一連の仕組みを見てきました。では、実際に業務のなかで最初の運用をどのように始めればよいのでしょうか。設計を実際の試験へと移す際、いきなりAIエージェントへシステム更新などの変更操作まで任せるのは、予期せぬトラブルを招く原因となります。

安全に導入を進めるためには、まずはエージェントの権限を絞り、「読み取りと報告のみ」を行う運用から始めます。作業対象の発見や検証、状態保持といった一連の仕組みにおいて、初週は報告だけにとどめる方法がコード作業の公開例で示されています。

営業チームの定期フォロー業務で考えてみましょう。最初の期間（たとえば一週間）は、AIエージェントに顧客への連絡文を作成させたり送信させたりするのではなく、「非定型の面談メモを読み解き、フォローすべき顧客の候補一覧と、その連絡理由の案だけを営業責任者へ渡す」という段階にとどめます。なお、ここで挙げる日数などの数値はあくまで例示であり、一般的な推奨値ではありません。

候補一覧の報告を受け取った人間の担当者は、その結果と実際の商談画面や面談の原記録を照らし合わせます。そこで、AIが不要な連絡を提案していないか、あるいは重要なフォロー対象を見落としていないかといった誤提案と漏れを一つずつ観察します。この初期段階において大切なのは、完全な自動化を急ぐことではありません。人とAIの役割分担を明確にし、評価や検証の設計が意図通りに機能しているかを見極めることです。もしAIが的外れな候補ばかりを挙げていれば、この時点で指示や検証の設計を見直すことができます。

報告結果に問題がなく、証拠の提示や停止条件の仕組みが安定して機能していることが確認できたら、そこから後になって初めて、次工程へと権限を広げていきます。先ほどの架空の例であれば、担当者が抽出精度の傾向を把握した後にのみ、連絡理由に基づく顧客への具体的な「質問案」の作成までをエージェントに許すかどうかの判断を下します。権限を広げたとしても、最終的には人が原記録と商談画面を確認して、連絡の採否と顧客への送信を決めるルールは維持します。

このように、ループエンジニアリングは初めからすべてをAIに任せるものではありません。最初は読み取りと報告から始め、誤提案と漏れを観察して実績を積んだうえで、段階的に権限を広げていくことが、安全で実用的な運用を始めるための重要な考え方となります。

ハーネスとグラフとの違い

実行環境、一件の反復、複数作業の依存関係を三領域で示し、三つの設計対象を区別する。

これまでに見てきたように、AIエージェントを実務に組み込むには、安全に発火させ、条件に従って確実に停止させる仕組みが欠かせません。では、この「ループ」の設計は、他の技術とどのように役割を分担しているのでしょうか。

その違いを理解するために、営業チームの定期フォロー業務を使い、「ハーネス」「ループ」「グラフ」の三つの境界を整理します。AI導入ではすべてを一つに詰め込むのではなく、一回の実行環境、時間をまたぐ反復、複数作業の依存を区別することが重要です。

まず、一つ前の段階である「ハーネス」は、AIエージェントが直面する一回のタスクを実行可能な状態に整えます。単純な期限通知なら通常のCRMタスクやルールで十分ですが、AIが非定型の面談メモを読んで連絡理由や質問案を提案するには、必要なデータへの安全なアクセス経路が必要です。商談記録への閲覧権限を与えたり、AIが情報を引き出すための特定の道具を用意したりして、一回の実行環境を整えるのがハーネスです。

対して本記事で扱ってきた「ループ」は、時間をまたぐ次回の実行と停止条件を決めることに特化しています。一回の処理後、進捗を永続状態として保存し、処理量の上限に達した時点で機械的に停止させるのはループの役割です。また、翌日の定刻（あくまで例示のスケジュールです）に再判定を行って処理を再開するかを判断し、最終的に人の担当者へ引き継ぐといった一巡を制御します。営業の例であれば、人が原記録と商談画面を確認して連絡の採否と顧客への送信を決めるために、AIから人へ適切にバトンを渡す仕組みがこれに当たります。

さらに運用が発展し、「承認後に連絡文を送信し、顧客から前向きな返信があったら、それに依存して法務部門での契約書確認と、技術部門での導入調査を同時に開始する」といった複数タスクの連携が必要になった場合はどうでしょうか。このような複雑な処理順序や複数部門をまたぐ依存関係の管理は、一連のループの役割を超えます。複数作業の依存を扱う場合は、「グラフ」と呼ばれる別の設計領域となります。

今回の設計対象であるループエンジニアリングがどこまでを担うのかを明確にすることで、安全で管理しやすい運用を構築できます。一回の環境整備（ハーネス）、時間をまたいだ反復と引き継ぎ（ループ）、複数作業の依存管理（グラフ）へと役割を分割する視点を持って設計を進めてください。

よくある質問

Q1. ループエンジニアリングとはどのような考え方ですか？

いつ、どのような条件でAIを実行し、停止し、人に処理を引き継ぐかという一連の仕組みを設計する考え方です。本記事独自の架空の営業フォロー例では、毎朝の候補発見からAIの処理、人への引き継ぎまでを一つのループとして設計しています。原典は主にAIコーディングの文脈です。営業への適用は本記事の設計例として、対象情報と承認の条件を個別に決めます。

Q2. 通常のCRMによる通知機能と、AIを使ったループの違いは何ですか？

最終接触から一定期間が過ぎたことを知らせる単純な期限通知だけであれば、既存のCRM機能で十分です。一方、AIの役割は、非定型の面談メモを深く読み解き、顧客への連絡理由や質問案を自律的に作成することにあります。記事独自の架空の営業例のように、単なる機械的なリマインダーではなく、文脈を踏まえた非定型な処理をAIへ委譲する点が異なります。

Q3. ループの設計を始める際、最初に取り組むべきことは何ですか？

処理を開始する発火条件、AIに読み取らせる情報と任せる判断、次回に残す状態、そして人へ引き継ぐ停止条件などを設計メモに書き出すことから始めます。架空の営業フォロー業務の例でも、月曜朝の発火から提案件数の上限といった一連のサイクルを設計することが第一歩となります。各工程の目的とルールを設計メモに整理することで、安全に実務へ導入できます。

Q4. 前回の処理で残した記録と、現在の商談状況が違っていた場合はどう対応しますか？

常に実際の商談画面などの現物を優先し、再開時に前回の記録と必ず照合する必要があります。次の処理が始まるまでの間に、人間の担当者が手動で直接状況を更新している可能性があるためです。架空の営業フォロー例において、古い記録だけを信じて作業の発見とAIへの委譲を再実行してしまうと、的外れな質問案を作成してしまう原因となります。

Q5. AIが作成した質問案を、そのまま顧客へ自動送信してもよいですか？

いいえ、自動送信せず必ず人間が最終確認する手順を設計してください。架空の営業フォロー例でも、AIの役割は連絡理由と質問案の作成までにとどめ、実際の顧客への連絡は人間が原記録と商談画面を確認したうえで決定します。検証と作業を切り離し、人とAIの役割分担を明確にする設計が、安全な業務運用の要となります。