ループエンジニアリング: プロンプトエンジニアリングをいつの間にか置き換えたスキル

では、ループエンジニアリングとは正確には何か

設計対象そのものから始めよう。AIエージェントを本質まで削ぎ落とすと、「ツールを備えたwhileループの中のLLM」だ。入力を受け取り、モデルが何をすべきか考え、ツールを呼び出し、結果を確認し、タスクが完了するか制限に達するまでこれを繰り返す。このサイクルこそがAIエージェントループであり、エージェントをチャットボットと分ける唯一の特徴だ。チャットボットは一回のやり取りで答えるが、エージェントは多くのステップにわたって持続し、適応する。

ループエンジニアリングとは、そのループを信頼できるものにする技術だ。Simon Willisonがこの実践に名前を付けた際の言葉を借りよう。

「私が好んで使うLLMエージェントの定義は、目標を達成するためにツールをループで実行するものだ。それをうまく使いこなす技術とは、彼らが使うツールとループを注意深く設計することにある。」 - Simon Willison, Designing agentic loops (2025年9月)

これがどこに位置づけられるかを最もはっきり見る方法は、この技術がどのように層を重ねて発展してきたかを見ることだ。まずプロンプトエンジニアリングが登場した。一つの良い指示を書くことだ。次にコンテキストエンジニアリング。プロンプトだけでなく、モデルが各ターンで目にするトークン集合全体をキュレーションすることだ。ループエンジニアリングはその両方の上に位置し、モデルを取り巻くランタイムシステムを設計する。

Anthropicは中間層を「プロンプトエンジニアリングの自然な発展形」と位置づけており、同じ論理はもう一段上まで通用する。

「ループの中で動くエージェントは、次の推論ターンに関連するかもしれないデータをどんどん生み出していき、その情報は周期的に整理されなければならない。」 - Anthropic, Effective context engineering for AI agents

つまりこの関係は競合ではなく、入れ子構造だ。プロンプトエンジニアリングは単一の呼び出しを最適化する。コンテキストエンジニアリングは各ターンでモデルが目にする状態を最適化する。ループエンジニアリングは、エージェントがそもそも良い状態に到達できるかどうかを決める仕組みそのものを最適化する。プロンプトエンジニアリングの解説記事を読んだことがある人なら、これがその一段上の階層にあたる。

なぜプロンプトではなくループがレバーになったのか

2023年から2024年の大部分において、最も賢いやり方はモデルへの話しかけ方を学ぶことだった。それは、モデルが一発で答えていたからこそ機能した。モデルがループの中で動き、ツールを呼び出し、多くのステップにわたって行動するようになった瞬間、プロンプトはボトルネックであることをやめた。今日エージェントを最も壊しやすいのは、言葉遣いの悪い指示ではなく、オフスイッチのない、メモリ戦略のない、あるいは自分の作業を確認する手段のないループだ。

Dockerの創業者であるSolomon Hykesは、この危険性を、今や業界全体が引用する一文で言い表した。

「AIエージェントとは、ループの中で自らの環境を破壊しているLLMのことだ。」 - Solomon Hykes, via Simon Willison (AI Engineer World's Fair、2025年6月)

これが再定義だ。設計の悪いループの中にあるより強力なモデルは、危険性が低くなるどころかより危険になる。なぜなら、それはより有能に悪いアイデアを実行してしまうからだ。実践者コミュニティはこれを素早く理解した。Hacker Newsでは、このテーマに関する最も評価の高い投稿の一つが、率直に「The canonical agent architecture: a while loop with tools」と題されており、LLMエージェントループの理不尽なまでの有効性について語るもう一つの人気スレッドも、周囲の足場さえ正しければシンプルなループがどれほど良いパフォーマンスを出すかに驚く人々で溢れている。

LangChainはこれをすっきりした等式にまとめた。エージェント = モデル + ハーネス。

「ハーネスエンジニアリングとは、モデルを仕事のエンジンに変えるために、モデルを取り巻くシステムを構築することだ。モデルは知性を含み、ハーネスはその知性を実用的なものにする。」 - LangChain, The anatomy of an agent harness

ループエンジニアリングと呼ぼうと、ハーネスエンジニアリングと呼ぼうと、あるいはエージェント型コーディングと呼ぼうと(呼び名はまだ定まっていない)、考え方は同じだ。あなたがモデルでないなら、あなたはループであり、いまやエンジニアリングはそのループの中に宿っている。

よく設計されたループの5つのレバー

この分野を定義している人々、Willison、Anthropic、LangChain、Thoughtworksを見渡すと、ループは毎回同じひとにぎりのレバーへと分解される。これらは実際に回す操作つまみだ。

1. ツール(エージェント・コンピュータ・インターフェース)。 エージェントが実際にできること。AnthropicはSWE-benchの作業においてプロンプトよりもツールの最適化に多くの時間を費やし、UIに相当するエージェント側の概念としてACI(エージェント・コンピュータ・インターフェース)という用語を作った。Willisonはコーディングエージェント向けにはシンプルなシェルコマンドを好む。なぜなら「コーディングエージェントはシェルコマンドを実行するのが本当に得意」だからだ。
2. 停止条件。 ループがいつ終了してよいか。成功時、最大反復回数の上限、予算の上限、あるいは進捗がないことを検知した時。終了ロジックのないループは、早々に勝利宣言をするか、決して止まらないかのどちらかだ。Anthropic:「制御を維持するために、(最大反復回数のような)停止条件を含めるのも一般的だ。」
3. コンテキスト管理。 ターンをまたいで何が生き残るか。ここでの技法は、圧縮(要約してウィンドウの上限近くでリスタートする)、ノート作成(エージェントが自身のコンテキスト外に保持するNOTES.md)、そしてそれぞれ数万トークンを消費するがコンパクトな1,000〜2,000トークンの要約を返すサブエージェントだ。これが重要な理由は、トークン数が増えるほど想起の精度が劣化するため、能動的にキュレーションする必要があるからだ(コンテキストウィンドウのサイズについての解説も参照)。
4. 検証。 ループが実際にそのタスクをやり遂げたことをどう証明するか。これは最も繰り返し語られるレバーだ。Willisonは、コーディングエージェントの価値は「良く、かつクリーンに通過するテストスイートによって大幅に増幅される」と言う。Anthropicの長時間稼働エージェント向けハーネスは、200を超えるエンドツーエンドの機能リストをJSONで持ち、それぞれ最初はpasses: falseとマークされていて、エージェントは証明なしに機能を完了扱いにできない。
5. ガードレール。 ループが害を及ぼすのを止めるもの。サンドボックス、厳密に権限を絞った認証情報、そして予算だ。Willisonは、暴走したループが実際のお金を使ってしまわないよう、Claude Codeに5ドルの予算を持つ専用のFly.io組織を与えた。

エージェントが誤動作するとき、修正はほぼ必ずこの5つのうちのどれかであり、プロンプトの言い換えではない。私がよく使う簡易診断はこうだ。

顧客サポートのためのループエンジニアリング

ここが、コーディング中心の報道の多くが見落としている部分だ。ループエンジニアという仕事の現実世界における最も分かりやすい姿は、コーディングCLIを作ることではなく、実際のサポートキューでAIエージェントを稼働させることだ。これは、こうしたエージェントを生業として作っている人間としての実感でもある。

サポートチケットはほぼ完璧なループだ。エージェントは受信したメッセージを知覚し、意図について推論し、必要なもの(注文履歴、ドキュメント、アカウント状態)を取得し、アクション(返金、リセット、チケット更新)を実行し、結果を検証し、そのうえで解決するか人間に引き継ぐ。Anthropicはサポートを「よりオープンエンドなエージェントにとって自然に適した領域」として特に挙げているが、それはこの仕事が会話と行動の両方を必要とし、その成功が「ユーザーが定義した解決によって明確に測定できる」からだ。

そして5つのレバーのすべてが、購入者が自覚している以上に気にかけているサポート上の判断に対応している。私たちはこの3年以上、実際のサポートキューにAIエージェントを導入し続けてきたが、導入がうまくいくかどうかを決めるのは、プロンプトの巧妙さでは決してない。ループだ。私が耳にした中で最も鋭いバージョンは、GorgiasとShopifyを使い、月に約7,000件のチケットを処理するDTCサプリメントブランドのCXリーダーが、あるコールで私たちに語ったこの言葉だ。

「AIは決して100%の質問に答えられるようにはならない……私が必要としているのは、自分が対応に自信を持てるチケットだけを扱い、それ以外のチケットにはすべて手を出さないAIだ。」

これは平易な言葉で表現された、ループエンジニアリング上の要件だ。「自信のあることだけを扱う」というのは、停止条件とガードレールが融合したものであり、それが彼らの購入決定を左右したただ一つの機能だった。何でも答えようとするボットはデモでは印象的に見えるが、本番環境では静かに信頼を損なっていく。これは、ほとんどのAIチャットボットの問題の背後にあるのと同じ失敗パターンだ。確信度ゲートがないため、答えるべきでないときに答えてしまう。またこれは、そうした判断を一切下せないルールベースのチャットボットと本物のエージェントとを分ける境界線でもある。

検証というレバーには、サポートの世界にも正確な対応物がある。コーディングではテストスイートで検証する。サポートでは、実際の顧客に触れる前に、エージェントを自社の過去のチケットに対してシミュレーションし、何を答えたであろうか、カバレッジが薄い箇所はどこか、何を間違えるかを観察することで検証する。これはサポートの世界における、Anthropicの「200の機能、すべてpasses: false」という規律の対応物であり、だからこそ私たちは、チームに本番で発見させるのではなく、eeselのヘルプデスクエージェントにシミュレーションを組み込んだ。

数字も、なぜエンジニアリングが重要かを裏付けている。2026年のベンチマークレポートで、Notchは従来型チャットボットの解決率を10〜25%、そして「CRM、請求、保険金請求システムに直接接続して実行する」エージェント型プラットフォームのエンドツーエンド解決率を70〜85%としている。この差はモデルの品質ではない。どの階層も同じフロンティアモデルを呼び出せる。差は、誰かがその周りのループを設計したかどうかにある。このレポートで最も鋭い一文は、ベンダーに投げかけるべき正直な質問は「解決率がいくつかではなく、何をもって解決とみなすか」だという購入時のヒントだ。

このループはコードではなく平易な言葉で調整することもでき、それこそがループエンジニアリングをエンジニアだけでなくサポートチームにとっても身近なものにする部分だ。

ループを自分で構築するか、すでに構築済みのものを使うか

サポート自動化をループエンジニアリングとして捉えると、自作か購入かという問いはより明確になる。生のClaudeやOpenAIのAPIの上に自分でループを構築することはできるし、実際多くの技術チームがそうしている。Claude Codeのベストプラクティスの記事群は、その技術を学ぶための本当に良い場所だ。しかし、ハーネスこそが難しい部分であり、それは維持し続けなければならない部分でもある。Anthropic自身の長時間稼働エージェントに関する取り組みには、200を超える機能の検証リスト、サブエージェントのオーケストレーション、圧縮ロジックが含まれていたが、それはコーディングエージェントを軌道に乗せておくためだけの話だ。本番のサポートループには、さらに確信度ルーティング、多言語対応、チケットタイプごとのルール、そしてクリーンな人間への引き継ぎが加わる。

暗号資産ハードウェア企業のあるエンジニアリングリードは、300件を超える記事からなるナレッジベースを持つ立場から、購入を選んだ後にその損得勘定をこうまとめた。

「自分たちでLLMアプリケーションを書いてみることもできたが、そこに時間を投資したくはなかった。メンテナンスしなくて済むものが欲しかった。」

Karel、GENERAL BYTES(eesel顧客)のエンジニアリングリード

それが本当のトレードオフだ。いまやループそのものが製品であり、問いは、自分がそれを設計し維持する側になりたいのか、それともサポート用にすでに設計済みのループを購入したいのか、ということだ。後者を検討しているなら、最良のAIヘルプデスクソフトウェアのまとめ、AIエージェントの事例集、そして最良のAIエージェントの選定は、誰がそのエンジニアリングをどれだけうまくやり遂げたかを知るための良い見取り図になる。

eeselを試す

eesel AIは、この記事全体の枠組みで言えば、サポート向けにすでに設計済みのループだ。あなたのヘルプデスク(Zendesk、Freshdesk、Gorgias、Help Scout、その他100以上)に接続すれば、初日からあなたの過去のチケットとドキュメントから学習する。5つのレバーはサポートのユースケース向けにあらかじめ組み込まれている。過去のチケットに対するシミュレーションが検証ステップであり、確信度ベースのルーティングが停止条件であり、範囲限定されたアクションとチケットタイプの除外がガードレールとなる。そのすべてがコードではなく平易な言葉で設定できる。

だからこそ、Gridwiseのようなチームは、最初の1か月でeeselがTier-1リクエストの73%を解決したのを目にした。ループは最初は監督下で稼働し、シミュレーションによって安全性が証明されるにつれて自律性を獲得していった。あなたは、設計済みのループと、それを信頼するための検証を、自分で構築し維持することなく手に入れられる。無料で始めて、一人の顧客の目に触れる前に、自社のチケット履歴に対してシミュレーションしてみることができる。