AgentOps とは、AI エージェントを安定稼働させるための「組織設計＋運用基盤」のフレームワークである。

DevOps が「コードを安全にリリースする運用」、MLOps が「モデルを安定運用する仕組み」だったのに対し、AgentOps は「自律実行する複数エージェントを、品質・コスト・コンプライアンスの 3 軸で持続的に運用する組織と仕組み」を扱う。LLM の登場で立ち上がった LLMOps の延長で済むように見えるが、エージェントが「ツールを自律的に呼ぶ」前提が加わった瞬間に、運用の設計対象は推論パイプラインから「業務プロセスそのもの」へと移る。

本ガイドは中堅企業の DX / 情シス責任者を対象に、AgentOps の構成要素・既存運用との統合・導入ステップを整理する。読み終えたとき、自社で「誰が・何を・どの SLI/SLO で見るか」の役割表を引け、パイロット段階のエージェントを本番展開に乗せるための優先順位が判断できる状態を目指す。

AgentOps は、複数の AI エージェントを「組織の正規運用ワークロード」として管理する考え方とその基盤を指す。単なるツール導入ではなく、所有権・観測指標・人間介入の設計を組み合わせた組織側の整備が中心となる。

このセクションでは、既存の Ops 系（DevOps / MLOps / LLMOps）との違いと、エージェント運用が新しい課題を生む理由を整理する。「これまでの運用に何を足せばよいか」が明確になることが、導入計画を立てる出発点になる。

従来の Ops 系と AgentOps の関心領域を並べて整理する。

AgentOps が新しいのは「LLM が自律的にツールを呼ぶ」前提が加わる点だ。LLMOps までは「テキスト生成の品質と速度」が主な関心事だったが、エージェントは社内 DB に書き込んだり、外部 API に送金したり、ファイルを削除したりする。副作用の伴う行動が日常的に発生するため、デプロイ後の運用が単なるレイテンシ監視では足りない。

移行のトリガーとして観察されるのは、(1) エージェントが外部 API に副作用のあるアクションを発行し始めた時点、(2) 複数エージェントが同一データに同時アクセスする構成になった時点、(3) ユーザー入力以外の「データソース由来のプロンプト」が入り込んだ時点の 3 つだ。これらが揃った段階で、LLMOps の延長線では運用が破綻し始める。

エージェントが「自律的に判断する」性質は、運用上 3 つの新しい課題を持ち込む。

• 非決定性の常態化: 同じ入力でもツール呼び出しの順序や選択が変わり、再現性が下がる。バグの再現が困難になり、原因切り分けに「同一入力で N 回再実行する」アプローチが必要になる
• コスト変動の予測困難: 1 タスクあたりのトークン消費が「何ステップ思考するか」で大きく変動する。同じ機能でもユーザー入力次第でコストが数倍に振れるため、「平均値」だけ見る予算管理は破綻しやすい
• 責任境界の曖昧化: エージェントが下した判断が誤っていた場合、誰が責任を持つか（提供チーム / 利用部署 / 管理部門）が定義されていないと、対応が止まる。事故報告のフローも「どのチームが起票するか」から議論が始まることになる

これらは個別のツールでは解けず、組織側のルールと役割で吸収する必要がある。AgentOps が「組織設計」を含むのはこのためだ。3 課題のいずれかが現場で顕在化したら、ツール選定より先にエスカレーションパスとオーナー定義を整える方が結果として早い。

エージェントを 1 体・1 用途で動かしているうちは小さな運用で済むが、数が増えた瞬間に運用負荷が指数的に膨らむ。「Pilot は成功したが拡張で詰まる」という現場の声が、AgentOps への関心を押し上げている。

ここでは「拡張で詰まる」現象の中身を分解し、なぜそれが従来の運用設計では吸収できないのかを整理する。

単体のエージェントでは追跡可能だった「思考→ツール呼び出し→結果」のループは、複数エージェントが協調すると、

• どのエージェントが、どの順序で、どのツールを呼んだか
• 途中で失敗したとき、どこから再実行すれば安全か
• 同時実行で発生するコンフリクト（同じレコードを 2 体が更新するなど）
• エージェント間の引き継ぎでコンテキストが欠落していないか

といったマルチエージェント特有の運用問題が現れる。Mastra や LangGraph のようなフレームワークが「エージェントの状態をワークフローとして記述する」方向に進んでいるのも、追跡可能性を取り戻すための動きだ。「何が起きたか分からない」状態を防ぐには、各エージェントの入出力と判断根拠をすべて構造化ログに残し、ワークフロー単位でリプレイ可能な状態を維持しておく必要がある。

ラオス語 AI エージェント実装ガイド で扱った MCP ベースの自律実行も、本番化の段階で同じ運用問題に直面する。実装パターンが整っていても、運用基盤が追いついていないと「動くが止められない」状況に陥る。

エージェント運用で必須になる 3 つの機能を整理する。

この 3 つは独立に実装できるが、お互いを参照する設計にすると運用負荷が下がる。例えば監査ログから HITL 必要判定を行う、コスト超過時に HITL を強制する、HITL 承認ログを監査ログに統合する、といった連携だ。

特にコスト管理は、Pilot 段階で見ていた小規模な数字が、本番展開で大幅に膨らむことが珍しくない。原因は (a) 利用ユーザー数が増える、(b) 1 タスクあたりの推論ステップ数が増える、(c) ロングコンテキスト RAG でプロンプトが肥大化する、の 3 系統に集約される。ツールの導入よりも先に、コスト計測の単位とアラート閾値を決めておく必要がある。閾値を超えたとき自動でエージェント停止するか、HITL 承認に切り替えるか、運用方針を事前に合意しておくと現場の判断が早くなる。

AgentOps は (1) エージェントレジストリ、(2) 観測（SLI/SLO・コスト）、(3) HITL とエスカレーション、(4) 評価ループ、(5) ガバナンスポリシーの 5 要素で構成される。本セクションでは特に重要な前 3 つを掘り下げる。

評価ループは「エージェントの品質を継続的に測り直す仕組み」、ガバナンスポリシーは「どのデータをどのエージェントが扱ってよいか」の規程を指す。これらは前 3 要素が整った後に着手するのが効率的で、最初から 5 要素同時を目指すと足元が固まらないままパイロットが終わる。

エージェントが 5 体を超えたあたりから、「どこにどのエージェントがいて、誰が責任者なのか」が曖昧になる。レジストリは以下の最小情報を持つ。

• エージェント ID と用途（顧客対応 / 経理処理 / 営業支援 …）
• 所有者（業務部門オーナー）と技術担当（開発者）
• 利用する MCP / ツール一覧
• アクセス可能なデータカテゴリと PII 区分
• バージョンと変更履歴
• 廃止予定日（あれば）

社内 wiki や Notion でも構わないが、**「変更があれば必ずここを更新する」**という運用ルールが回らないと、棚卸し時に存在しないエージェントが見つかる事態が起きる。レジストリは「正しい状態を保つ」ための運用負荷も無視できないので、デプロイパイプラインから自動で更新が入る仕組み（CI で更新されたら PR 経由で反映）を最初から組み込むと、形骸化を防ぎやすい。

AgentOps の SLI（Service Level Indicator）は、Web サービスのレイテンシ・エラー率とは違う観点が必要になる。最低限見るべき 4 指標を挙げる。

• タスク成功率: HITL 介入なしでタスクを完遂できた割合
• 平均ツール呼び出し回数: 1 タスクあたり何回ツールを叩いているか（増加は思考の迷走シグナル）
• トークンコスト / タスク: 入力 + 出力 + キャッシュ消費の合計
• エスカレーション率: HITL に上がってきた割合

SLO（目標値）は最初から厳しく設定せず、Pilot 期間で実測してから決める。例えば「タスク成功率 90% 以上」を最初から掲げると、運用側が成果を取り繕う方向に動きがちで、本来見るべき改善点が見えなくなる。Pilot で 70% 程度の成功率なら、SLO は 75% から始めて段階的に引き上げるほうが、組織として現実的な改善サイクルを回せる。

アンチパターンとして避けたいのは「エラー率だけを SLI にする」設計だ。エージェントは失敗しなくても「無駄な思考ループでコストだけ消費する」「正しく動作したが結果がユーザー期待と違う」といった失敗のしかたが多く、エラー率では拾えない。タスク成功率と平均ツール呼び出し回数を組み合わせると、品質劣化の予兆を早く掴めるようになる。

HITL の設計は「全リクエストに人間を挟む」と「エージェント任せ」の中間に着地点を見つける作業だ。3 系統のパターンを使い分ける。

• 常時 HITL 必須: 送金・契約・法的判断・社外公表（誤判定の影響が不可逆な領域）
• しきい値ベース HITL: 信頼度スコア < N、金額 > N 円、ファイル削除件数 > N 件
• サンプリング HITL: 自動承認しつつ、ランダムで一定割合を人間レビュー（品質の継続監視）

3 つを同じエージェントに併用するのが現実的だ。例えば「経費精算エージェント」なら、10 万円超の処理は常時 HITL、1 万円以下は自動、その中間はランダムで 5% を人間レビュー、という設計になる。

エスカレーション先は 「専任のレビュアーチーム」「業務部門オーナー」「セキュリティチーム」 の 3 系統を持っておくと、領域ごとに適切な人にルーティングできる。レビュアーの応答時間 SLA も決めておくと、HITL 待機が業務全体のボトルネックにならず、エージェント側のタイムアウト設計も組みやすくなる。

AgentOps を「専用ツールを買えば実装できる」と捉える誤解が最も多い。実際には組織側の役割と意思決定の整備が大半を占め、ツールはそれを支える一要素にすぎない。

ここでは特に多い 2 つの誤解を取り上げ、なぜそれが組織の動きを止めるのかを具体的に整理する。

AgentOps の SaaS が立て続けに登場した結果、「観測ツールを入れれば AgentOps が出来上がる」という認識が広がっている。観測ツールは確かに有用だが、それだけでは:

• どの SLI を「許容できないレベル」と判断するか
• HITL に上がった案件を誰が捌くか
• コスト超過アラートが出たとき、誰が予算上限を引き上げるか
• インシデント発生時に誰がエージェントを停止する権限を持つか

といった人間の判断が必要な部分を解決できない。ダッシュボードに赤いアラートが並ぶだけで動かない、というのは観測ツール先行の典型的な失敗だ。ツール導入と並行して、エスカレーションパスと意思決定権限の表を整備するのが先決だ。最低限「誰が・何を見て・どの閾値で・誰に連絡するか」を 1 ページにまとめ、関係部署で合意してから観測ツールを発注するのが、結果として最短のルートになる。

「AI エージェントを 50 体配備しました」というアナウンスが社内外で出ることがあるが、台数は価値の代理指標としてあまり機能しない。10 体で十分な場合もあれば、3 体しか使われないケースも珍しくない。配備された 50 体のうち、月間アクティブが 10 体未満というのも観察される現象だ。

価値の代理指標として有効なのは:

• 業務時間の実測削減（部署単位）
• HITL 件数の推移（減少は習熟、増加は新しいユースケース開拓）
• ユーザー満足度（NPS や継続利用率）
• ROI（削減時間 × 人件費 − 運用コスト）

エージェント数は予算配分・人員計画では意味があるが、**KPI として直接使うと「数を増やすこと自体が目的化する」**罠に陥る。社内提案資料では使い分けたい。経営層への報告では「業務時間削減」を中心に据え、エージェント数は内訳の参考値として扱う構成が、目的の取り違えを防ぎやすい。

AgentOps の導入は「既存 SRE / DevOps チームに 1 名アサイン → 段階的に役割を切り出す」のが現実的だ。専任部隊を新設するアプローチは、人材調達と既存チームとの摩擦で多くの場合失敗する。

ここでは中堅企業（情シス 5〜30 名規模）を想定して、現実的な導入ステップを 2 つの観点から整理する。

既存の SRE / DevOps チームには、観測基盤・インシデント対応プロセス・オンコールローテーションがすでにある。これを AI エージェントにも展開するのが最短経路だ。具体的には:

1. SRE / DevOps チーム内で「AI ワークロード担当」を 1 名アサインし、エージェント運用の責任範囲を明文化する
2. 既存 SIEM / 観測ツールに MCP / エージェントログを取り込む（JSON Lines 形式が扱いやすい）
3. 既存のインシデント対応 Runbook に「AI 異常」を 1 章追加し、停止・再起動・ロールバック手順を明示
4. 既存のオンコールに含める（ただし最初の数か月は AI 担当のみ呼び出し、知見が貯まってから他メンバーに展開）
5. 半年に一度、AI ワークロードの占有率と障害件数を SRE 全体ミーティングで共有

「AI 専任部署」を新設しないのがポイント。社内 AI アシスタント導入 と同じ思想で、運用の連続性を保ちながら範囲を広げていく。専任部署化は組織が大きくなり、AI ワークロードが SRE 全体の 30% を超えてから検討するのが、人的リソースの観点で無理がない。

中堅企業で必要な役割は最小 3 つに絞れる。

3 役割を兼任で始めても良いが、「オーナーが運用も兼ねる」構成は避けたい。業務観点と技術運用観点が同一人物に集中すると、KPI とアラートのバランスが取れなくなる傾向がある。具体的には、業務側が成果を出したい一心で SLO の運用を緩めてしまう、コスト超過を「業務上必要」と判断して見過ごす、といった現象が起きやすい。役割を分けて相互チェックが働く構造にするのが、長期的に運用を安定させる。

AgentOps の導入で現場から最も多く聞かれる質問のうち、本ガイドで詳述しなかった重要トピックを 1 つ取り上げる。本番展開時の典型的破綻パターンに絞って解説する。

Q. パイロットでは順調だったエージェント運用が、本番展開で破綻するのはなぜですか？

破綻パターンは大きく 3 つに整理できる。

• コスト破綻: パイロットの利用量で計算したコストが、本番の負荷で大きく膨らむ。ユーザー数増加だけでなく、1 タスクあたりの思考ステップ数も増える傾向にある（複雑なケースをエージェントに任せるようになるため）。本番化前に想定ピーク時のコスト試算とアラート閾値を必ず作り、超過時の自動停止 or HITL 切り替えを設計しておく
• 監査破綻: パイロットでは取らなかった監査ログが、本番化時に「PDPA / 内部統制で必要」と判明する。後付けでログ整備すると過去データを失うため、監査要件は最初から想定して構造化ログの設計に組み込む。特に PII を含むやり取りはマスキングルールも事前に決めておく必要がある
• HITL 破綻: パイロットでは管理者が個別に承認していたものが、本番化で件数が膨らみレビュアーが追いつかない。HITL のしきい値・サンプリング率を本番想定で設計し直し、レビュアーの SLA と必要人数を見積もる。レビュアー不足が最も多い破綻原因なので、人員計画は早めに着手したい

パイロットから本番への移行は「同じものを大きくする」ではなく、「本番想定の負荷で再設計する」段階として扱うのが安全だ。Hybrid BPO のガイド で論じた人と AI の役割分担も、規模の変化で見直しが必要になる。具体的には、パイロット時は「AI が 8 割・人間が 2 割」だった分担が、本番化で「AI が 6 割・人間が 4 割」に動くことが多い。これは品質の問題ではなく、HITL を含む人間の介入領域が広がる現象として捉えるべきだ。

AgentOps は、AI エージェントを「ツール導入」ではなく「組織の正規運用ワークロード」として扱うための枠組みである。

導入の優先順位は次の 3 ステップ。

• Step 1: エージェントレジストリで現状の棚卸しと所有権の明文化
• Step 2: SLI / SLO・コスト指標を最低 4 つ定め、既存の SRE / DevOps チームに観測を統合
• Step 3: HITL のしきい値とエスカレーションパスを業務部門オーナーと合意する

専任部隊や専用ツールを揃えるより、役割と判断権限の整備が先になる。これは 社内 AI アシスタントの導入 でも、ラオス語エージェント実装 でも、本番運用を成立させるために共通して必要だった部分だ。AgentOps は技術論というより、AI 時代の運用ガバナンス論として捉えるほうが、現場での合意形成が進みやすい。

関連ガイドとして 社内 AI アシスタント ・ Hybrid BPO ガイド ・ MCP プロトコル入門 を併せて読むと、AgentOps と既存運用の接続点が立体的に見えてくる。次の一手としては「自社のエージェント 1 体を選び、本ガイドの 5 構成要素に沿って棚卸しシートを 1 枚作ってみる」のが、抽象論で止まらないための具体的な出発点になる。