FDX株式会社
Tech Note

ループエンジニアリング入門｜自律エージェントを​動かし続ける​ハーネス設計の​体系

ループエンジニアリングとは、自律 AI エージェントを観測→判断→行動の反復で安全に走らせるための設計思想。本記事は 3 層構造、停止条件 4 パターン、検証ハーネスの階層設計（Hook / pre-commit / CI / 人間）、運用 Tips、避けるべきアンチパターンを 2026 年時点の Anthropic / Karpathy / Stripe 知見をもとに整理する。

·FDX株式会社 編集部·監修: 佐藤 拓哉（生成AI協会 理事）
ループエンジニアリングの 3 層構造図。観測層（state / memory / tool result）、判断層（model + reasoning）、行動層（tool call / side effect）を環状に配置し、4 つの停止条件を周囲に配置。

要点（100字）：ループエンジニアリングとは、​AI エージェントを​観測→判断→行動の​反復で​安全に​動かし続ける​設計思想。​停止条件・検証ハーネス・予算管理の​ 3 軸で​設計し、​フィードバックを​最速層に​寄せれば、​自律エージェントは​業務で​運用可能な​信頼性に​達する。

この​​記事の​​対象読者

ループエンジニアリングとは​​（要点3行）

  1. ループエンジニアリング = 観測 → 判断 → 行動の反復を安全に動かし続けるハーネスを設計する技術。​エージェント本体​（モデル + プロンプト）の​外側に、​停止条件 / 検証 / 予算管理を​組み込む。
  2. 2026 年に自律エージェントの業務運用が一気に広がった背景は 3 つ。​Claude Opus 4.7 など​長尺タスクに​耐える​モデルの​登場、​Anthropic の​ harness 記事に​よる​設計指針の​公式化、​Karpathy 流の​ autoresearch 思想の​エンタープライズへの​浸透。
  3. 設計の中核は「フィードバックを最速層に寄せる」。​決定論的な​ツール​（リンター / テスト / 型チェック）で​モデルを​矯正すれば、​プロンプトを​増や​さずに​品質が​出る。

なぜ2026年に​​自律エージェントの​​運用が​​広がったか

3 つの​要因が​重なった​結果、​2026 年は​自律エージェントを​業務運用する​企業が​一気に​増えた。

要因1：長尺タスクに​​耐える​​モデルの​​登場

Claude Opus 4.7 や​ OpenAI o-series、​Gemini 3 Pro など、​内部での​自己検証を​持つモデルが​本格運用フェーズに​入った。​失敗時の​リトライを​少なく​抑えても、​数ループ以内で​タスクを​完結できる​確率が​大幅に​向上している。

要因2：Anthropic の​​ harness 設計記事

Anthropic Engineering Blog の​ "Designing Harness for Long-Running Agents" が​公開され、​ハーネスを​「文書ではなく​テストで​強制する」と​いう​設計指針が​公式化された。​これに​より​エンタープライズが​品質保証の​社内基準と​して​採用しや​すくなった。

要因3：Karpathy 流 "autoresearch" 思想の​​浸透

Andrej Karpathy が​提唱した​「Modify → Verify → Keep / Discard → Repeat」の​自律研究ループが、​コーディング以外の​ドメイン​（マーケティング / カスタマーサポート / 法務リサーチ）にも​適用可能である​ことが​示された。​これに​より​業務ループの​設計手法が​広がった。

ループの​​3層構造

ループの 3 層構造

エージェントループは​観測・判断・​行動の​ 3 層から​成る。​1 周回る​たびに​この​ 3 層を​順に​めぐり、​行動層の​結果が​次の​観測層へ​戻ってくる。​どの​層が​弱くても​ループ全体の​信頼性が​崩れる​ため、​層ごとに​何を​設計すべきかを​押さえておく。

観測層​（Observation Layer）

観測層の​設計は​ コンテキストウィンドウの管理 と​等価。​すべての​履歴を​詰め込むと​判断層が​ブレる​ため、​要約・選別・圧縮が​必要​（参考：LLM トークン節約 5 パターン）。

判断層​（Decision Layer）

判断層の​品質は​ 観測層のシグナル / ノイズ比 で​決まる。​プロンプトを​増やすよりも、​観測層の​シグナルを​濃縮する方が​効果的。

行動層​（Action Layer）

行動層は 副作用の伴うすべての操作 を​含む。​特に​ DB / メール / 決済など​取り消しが​効かない​操作は、​行動層内に​ "ガード" を​組み込むのが​定石。

停止条件の​​4パターン

ループは​「いつ​止めるか」を​設計しないと、​暴走や​コスト超過、​無限ループに​陥る。​止めどころは​大きく​ 4 タイプに​分けられ、​実運用では​これらを​単独ではなく​組み合わせて​仕掛けておくのが​普通だ。​望ましい​止まり方​（成功）から、​避けたい​止まり方​（予算超過・連続失敗）、​外から​止める​経路​（割込み）まで​一通り用意する。

パターン1：成功条件達成

最も​望ましい​停止理由。​成功条件は​数値 / boolean で​機械​判定可能に​する。

パターン2：予算超過​（token / time / cost）

エンタープライズ運用では​必須。​予算なしの​ループは、​エッジケースで​指数的コスト爆発を​起こす。

パターン3：検証 fail の​​連続発生

「無限リトライは​ LLM の​品質を​落とす」と​いうのは​多くの​企業の​経験則。​2〜3 回 fail で​人間に​エスカレーション。

パターン4：外部​​割込み

人間オペレーターが​介入する​経路を​必ず残す。​完全自律は​障害時の​リカバリを​困難に​する。

検証ハーネスの​​階層設計

検証フィードバック階層

ループの​品質は​ 検証ハーネスの応答速度 で​決まる。​原則は​「フィードバックを​最速層に​寄せる」。

Tier 1：Hook​（ms）

ミリ秒で​判定できる​検証は​ Hook で​完結させる。​これだけで​「明らかに​違反」の​ミスを​ 80% 削れる。

Tier 2：pre-commit / pre-action​（秒）

秒オーダーで​完了する​検証。​エージェントが​コミット / アクション実行する​前に​走らせる。

Tier 3：CI​（分）

分オーダーで​完了。​プルリクエスト相当の​タイミングで​走らせる。​エージェントは​ CI 結果を​待ってから​次の​判断に​進む。

Tier 4：人間レビュー​（時間 / 日）

人間でしか​判定できない​論点に​集約する。​ここを​増やすと​運用負荷が​上がる​ため、​Tier 1〜3 で​吸収できる​部分は​徹底的に​自動化する。

原則：Hook(ms) > pre-commit(s) > CI(min) > 人間(h) の​順で、​より​速い層に​検証を​寄せる。​これに​より​人間の​負荷を​最小化しつつ品質を​上げる。

運用Tipsと​​アンチパターン

Tip 1：ハーネス棚卸し​（四半期）

各ルール / Hook / 制約に​ついて​「モデル改善で​不要に​なっていないか」を​四半期ごとに​問う。​不要な​ガードレールは​除去する。

過剰な​制約は​パフォーマンスを​下げる。​モデルが​自力で​回避できるようになった​ミスへの​ Hook は​除去すべき。

Tip 2：部​​分成功を​​受容する

「100% 完成」を​目指すと、​修正ループ 3 回で​トークンを​浪費して​結果​ゼロに​なる。80% 完成で人間に渡す方が、100% 目指してトークン浪費するより合理的（Stripe / Anthropic の​経験則）。

部​分成功を​許容する​設計に​すると、​エージェントの​稼働率が​大幅に​上がる。

Tip 3：説明文書より​​テスト / 型定義で​​情報を​​表現する

CLAUDE.md / AGENTS.md などの​説明文書は​モデルが​読み飛ばすことがある。​テスト / 型定義は​モデルが​読まなくても​ CI で​違反を​検出できる。

エージェント由来の​ミスは​テストまたは​リンタールールで​再発防止する。​複利効果が​大きい。

アンチパターン1：プロンプトに​​保険文言を​​増やす

「ダブルチェックしろ」​「再確認しろ」系の​保険文言は、​モデルの​内部​検証と​重複し過剰ループを​誘発する。​新規ルール / プロンプトには​入れない。

アンチパターン2：無限リトライで​​根本原因を​​潰さない

停止条件の​パターン3で​触れた​とおり、​同じ​エラーへの​リトライは​数回で​打ち切り、​人間に​エスカレーションするのが​定石だ。​リトライを​際限なく​回すと、​LLM の​出力品質が​落ちるうえ、​本来直すべき根本原因が​回数の​陰に​隠れてしまう。

アンチパターン3：検証なき委譲

サブエージェントに​任せた​結果を​検証せずに​採用する。​サブエージェントの​「やった​つもり」を​信じると、​後段で​巻き戻し作業が​発生する。

委譲したら​必ず​実行結果​（テスト / ログ / 画面）で​動作を​検証する。

実装フレームワークとの​​対応

機能LangGraphClaude Agent SDKClaude Code
観測層State Objectsession messagesconversation history
判断層Node + Conditional Edgemain loopmodel + thinking
行動層Tool Nodetool callsbash / file ops
停止条件Conditional Edgeterminationexit / stop signal
Hook 連携カスタム実装hooks APIsettings.json hooks

LangGraph は​ループ構造を​ State Machine で​明示できるが​学習コストが​高い。​Claude Agent SDK は​中規模、​Claude Code は​手軽だが​自由度が​低い。​詳細は​「LangGraph 実装入門」「マルチエージェント実装ガイド」を参照。

FAQ

Q1. マルチエージェントとの​​違いは？

ループエンジニアリングは​「単一エージェント / 単一ループの​安全運用」を​扱う​設計思想。​マルチエージェントは​「複数エージェント間の​協調 / 分業」を​扱う。

両者は​補完関係で、​マルチエージェントの​各サブエージェントも​それぞれループエンジニアリングの​対象。​詳細は​「マルチエージェント実装ガイド」を参照。

Q2. LangGraph / Claude Agent SDK の​​どちらで​​実装する？

業務要件次第。

Q3. 停止条件は​​誰が​​決める？

業務要件 + 経営判断。​技術側だけで​決めない​こと。

Q4. 人間介入は​​どこに​​挟む？

3 タイプ：

  1. Approval Gate：副作用の​大きい操作​（DB 削除 / 大口決済 / 顧客通知）の​前に​承認を​求める
  2. Fallback Gate：エラー / 信頼度低下時に​人間に​判断を​委ねる
  3. Audit Gate：完了後に​サンプリングで​人間が​レビュー

完全自律より、​適切に​人間介入を​挟む方が​運用品質は​高い。

Q5. 失敗時の​​ロールバック​設計は？

3 階層：

  1. State Snapshot：各ノード / ステップ実行前に​ state を​保存。​失敗時に​巻き戻し可能
  2. Side Effect Compensation：副作用が​発生した​場合、​補償トランザクション​（メール取り消し通知 / DB 巻き戻し）を​実装
  3. Manual Recovery：完全自動ロールバックが​難しい​場合、​人間オペレーターに​「何が​起きたか」​「どこから​再開するか」を​提示

FDXの​​エージェント実装・運用支援

FDX 株式会社は、Forward Deployed Engineer（FDE）+ AX Factory に​よる​エージェント実装・運用伴走を​提供する。

エージェントは​「作って​終わり」ではなく、​運用しながら​改善する​ソフトウェア。​内製運用の​引き受け手を​最初から​決めて​おくべき​（参考：AI 内製化の​進め方）。

FDX に​ AI エージェント実装の​相談を​する​ →

関連記事

出典・参考文献

関連記事

Implementation

DS+FDE ハイブリッドチーム設計｜日本企業のための AI 実装組織論

Strategy

DS vs FDE — 役割・責任・成果定義の8軸比較と、組み合わせて使うべき理由

Strategy

Deployment Strategist（DS）とは？Palantir発、AI時代のもう一つの実装パートナー

Next Steps

次に読むべき

ノウハウ記事

他のノウハウ記事を読む

FDE / AX 実装に関する他のインサイト記事。

読む

事例

実装事例集

記事で議論したパターンが動いている実例。

読む

ホワイトペーパー

AX 診断と研修設計

読んだ後の「次に何をするか」のたたき台。

読む

FDX流の​FDEモデルを​相談する

戦略立案・実装・現場定着・運用移管まで一気通貫で支援します。

無料相談を申し込む実装事例を見る