AIエージェントの運用・保守とは？本番導入後に育てる改善サイクル

AIエージェントは、本番に入れた日がゴールではなく、育て始める日です。導入直後のエージェントは、自社の業務ルールも、社内システムの癖も、現場の言い回しも知らないまま動いています。

運用・保守の中身は、モデルを入れ替えることではありません。ルールファイル、プロンプト、ツール接続、評価ケースといった周辺の仕組み（ハーネス）を、本番で出た失敗をもとに少しずつ直していく作業です。この改善サイクルの回し方、見るべき指標、モデル廃止や障害への備え、社内と外部の役割分担を、2026年10月時点の情報でまとめます。

この記事でわかること

導入直後のAIエージェントに「育てる工程」が要る理由
保守の対象になるハーネスの4要素と、それぞれの直し方
本番の失敗を評価ケースに変えて回す改善サイクルの手順
監視する指標、モデル廃止への備え、障害時の動き方
社内で持つものと外部のFDEに任せるものの分け方

導入直後のAIエージェントは現場に最適化されていない

導入直後のエージェントは、汎用的な能力はあっても、自社の現場向けには調整されていません。だから本番稼働の後に「育てる」工程が必要で、運用・保守はこの工程そのものを指します。

動き出した時点がスタートライン

PoC（試作）では、用意した数十件の問い合わせや資料でうまく動いたように見えます。本番に入ると、想定していない言い回し、古い社内規程、例外的な手続きが次々に来ます。ここで出る失敗は、導入前には再現できません。

評価の仕組みがない状態でリリースすると、問題が本番で見つかってから直す反応型の修正サイクルに陥ります。事前の自動評価が最初の防衛線で、本番の監視は配備後に起きるドリフト（性能のじわじわした低下）や想定外の失敗を拾う役割です。この整理はAnthropicの評価ガイドにあります。

エージェント型AIプロジェクトの4割超が2027年末までに中止される、というGartnerの予測があります。理由として挙がっているのはコスト増、価値の不明確さ、リスク管理の不足です。実測値ではなく予測ですが、「作って終わり」の運用では価値が出ないという方向は、現場の感覚とも合います。

運用保守は直すより育てる仕事

システムの保守は、壊れたものを元に戻す仕事でした。エージェントの保守は少し違います。壊れていなくても、現場の使われ方に合わせて振る舞いを良くし続ける仕事が半分を占めます。

1週間で見える変化は小さくても、失敗を1件ずつ直し、同じ失敗が二度と起きない状態を積み上げれば、時間がたつほど差が開きます。直さなければ、同じ間違いは何度でも起きます。

LLMOpsとの関係

LLMOpsは、プロンプト管理、ハルシネーション（もっともらしい誤り）の監視、コスト管理、評価基盤といった、LLMアプリの運用基盤全体を指す言葉です。エージェントではツール利用や複数エージェントの連携まで含めて、AgentOpsと呼ぶこともあります。

この記事での整理は次のとおりです。LLMOpsは運用基盤全体、ハーネスはエージェントの周辺環境の設計。改善サイクルがこの2つをつなぎます。用語の定義は解説ごとに揺れているため、言葉の違いより、何を直すかを先に決めるほうが実務では役に立ちます。

改善の対象はモデルではなくハーネス

保守で直す対象は、モデルではなくハーネスです。ハーネスとは、ルールファイル、プロンプト、ツール接続、評価の4つで、エージェントを現場で正しく動かすための周辺の仕組みを指します。

保守の対象になるハーネスの4要素

ハーネスエンジニアリングは、コーディングエージェントの文脈で広まった考え方です。AIの失敗を環境設計の不足のサインとして扱い、失敗ごとに再発防止策を足していきます。NTTデータの解説は、知識・実行・制約・検証・運用の5要素に分けています。

業務エージェントの運用では、これを日々の点検項目に落とすと扱いやすくなります。

保守対象	中身	点検のきっかけ
ルールファイル	業務ルール、禁止事項、判断基準をまとめた文書	同じ種類の誤りが2回出た
プロンプト	役割、出力形式、例示	回答の形式や口調が現場とずれた
ツール接続	社内システムやデータへの接続口と、その説明	ツールの選び間違い、呼び出し失敗
評価	テストケースと採点の基準	失敗が評価で検出できなかった

4つのうち、最も後回しにされやすいのが評価です。評価が薄いと、他の3つを直しても良くなったかどうかを判定できません。

ルールファイルとプロンプトは足すより削る

失敗が出るたびに指示を足していくと、ルールファイルは際限なく膨らみます。システムプロンプトの目安は、期待する振る舞いを十分に規定する最小限の情報です。最小限から始め、テストで見つかった失敗パターンに応じて指示や例を足す、というやり方がAnthropicのコンテキスト設計の記事に示されています。例は、多様で代表的なものを厳選します。

ルールファイルの長さについては、サーバーワークスの解説が60行以内を目安にしています。この数字は絶対ではありません。ただ、数百行になった文書を毎回読み込ませて精度が上がる保証はなく、ルールファイルは網羅マニュアルではなく目次として扱い、詳細は参照先の文書に分ける形が扱いやすくなります。

足す前に、既存ルールと矛盾していないか、古くなっていないかを確認してください。保守の半分は削除です。

ツール接続は迷わせないことが目標

ツールの数が増えると、エージェントはどれを使うべきか迷います。人間のエンジニアが迷うなら、エージェントも迷います。ツールは自己完結していて、役割が重複せず、返り値が短いのが望ましい形です。

社内システムとの接続口を整える場合は、Claude Code MCP連携の考え方が参考になります。接続を増やすときは、既存の接続と役割がかぶらないかを先に見てください。

本番の失敗を評価ケースにする改善サイクル

改善サイクルの核は、本番で起きた失敗を、次からは必ず検出できる評価ケースに変えることです。失敗は一度直して終わりにせず、テストとして残します。

6ステップの手順

本番の問い合わせ対応を例にします。

失敗を拾います。利用者のフィードバック、担当者による差し戻し、エスカレーション（人への引き継ぎ）の記録から、うまくいかなかった会話を集めます
記録を読みます。結果だけでなく、エージェントが何を考え、どのツールを呼び、どこで道を外れたかをトレース（実行の記録）で追います
原因を4要素のどれかに割り当てます。ルールの欠落か、プロンプトの曖昧さか、ツールの選び間違いか、評価の穴かを分けます
直します。1回の変更で直す箇所は1つに絞ります。複数を同時に変えると、効いたものが分からなくなります
失敗を評価ケースに追加し、既存の全ケースを再実行します。直したのに別のケースが壊れていないかを確認します
変更内容と評価結果を記録して反映します。反映後は監視で様子を見ます

失敗を評価タスクに変換する、という考え方はAnthropicの評価ガイドでも推奨されています。手作業で行っているチェックや、実際に起きた失敗が、評価の素材になります。

評価で見落としやすい4つの落とし穴

評価の仕組みを作ると、数字が出るぶん安心してしまいます。見落としやすい点は次の4つです。

一貫性。顧客向けの対応のように毎回成功してほしい場面では、1回成功すれば良いという指標では足りません。1回の成功率が75%なら、3回連続で成功する確率は約42%（0.75の3乗）に下がります。k回すべて成功する割合を見る指標（pass^k）が、このときの物差しです
採点の誤り。採点ロジックが、正しい答えを不合格にしていることがあります。トランスクリプト（会話と実行の全記録）と採点結果を、人間が実際に読んで確認します
飽和。合格率が100%に張り付くと、それ以上の改善を測れません。難しいケースを足し続ける必要があります
片側だけのテスト。「実行すべき場合」と「実行すべきでない場合」の両方をテストします。例えば、返金処理は依頼されたときに実行し、問い合わせだけのときは実行してはいけません

最初は20〜50件の簡単なケースから

評価ケースの整備は、最初から大規模にしなくて済みます。目安は20〜50件の簡単なタスクで、実際の失敗が出るたびに増やします。決定的に判定できる採点（出力が特定の形式か、特定のツールを呼んだか）を優先し、LLMに採点させる場合は人間の判定と突き合わせて較正（キャリブレーション）します。

ケースの所有者を決めることも欠かせません。誰も持たない評価は、業務の変化に追随できず陳腐化しがちです。

改善サイクルの立ち上げ、評価ケースの設計、ルールファイルの整理は、社内だけで進めにくい工程です。当協会は、導入後の調整・最適化を担うFDE支援を行っています。評価の整備からの相談も、お問い合わせフォームから受け付けています。

監視と評価指標は何を見るか

監視では、本番の動きを定期的にサンプリングして採点し、基準を下回ったら通知します。見る指標は、品質、安全性、タスクの完了、コスト、速度の5系統に整理できます。

見るべき指標の種類

公式ドキュメントで確認できる指標を、運用の観点で整理すると次の表になります。

系統	見る指標	悪化したときに疑う場所
品質	回答の関連性、根拠に基づいているか（groundedness）	ナレッジ参照、プロンプト
安全性	禁止事項やポリシーの違反	ルールファイル、ガードレール
タスク完了	依頼を最後まで終えた割合、ツール呼び出しの正確さ	ツール接続、ルール
コスト	トークン消費量	ループの設計、ツールの返り値
速度・安定性	レイテンシ（応答時間）、エラー率	接続先システム、モデル側

表の右端が、そのまま次のアクションです。指標が悪化したら、ハーネスのどこを開くかが決まっているのが良い運用です。

コストは見落とされがちです。エージェントは推論を繰り返すので、設計次第でトークン消費が急に増えます。品質だけでなく、1件あたりの消費も定点観測に含めてください。

閾値は自社で決める

合格率や応答時間の標準的な閾値は、公的には確認できていません。業務ごとに許容できる失敗の重さが違うので、当然とも言えます。社内の問い合わせ回答と、顧客への請求処理では、求める水準がまったく違います。

実務の進め方は、導入後の最初の数週間のデータを基準線にすることです。そこから、重大な失敗はゼロを目標に、軽微なものは許容率を決めます。平均点だけで判定せず、重大失敗の有無は別に見てください。

クラウド各社の継続評価機能

本番トレースをサンプリングして継続的に採点し、アラートを出し、失敗を分類して改善し、再評価する。この流れは、各社の公式機能でほぼ同じ形をしています。

AWS。Amazon Bedrock AgentCore Evaluationsは2026年3月に一般提供となり、本番トレースの継続採点と、CI/CDでの回帰テストに対応します。組み込みの評価器は13種で、東京リージョンを含みます
Microsoft。Foundryの可観測性では、本番のサンプリング評価、定期的なデータセット評価、定期的なレッドチーミング（意図的な攻撃テスト）、アラートを組み合わせます
Google Cloud。Gemini Enterprise Agent Platformの最適化に、オフライン評価、継続評価、失敗クラスタの分析、品質アラートが並びます
OpenAI。エージェント評価のガイドでは、トレースの採点でツール選択や安全ポリシー違反を評価できます

各機能の提供状況、料金、名称は変わります。採用前に、公式ページで最新の状態を確認してください。

モデルの廃止・更新と障害にどう動くか

モデルの廃止は事前に通知されるので、運用カレンダーに組み込めます。障害は予告なしに来るので、止める人と戻し方を先に決めておきます。

モデル廃止を運用カレンダーに入れる

Anthropicのモデル廃止ポリシーでは、モデルはActive、Legacy、Deprecated、Retiredの段階を進みます。公開モデルの廃止は、最低60日前に通知されます。移行先のモデルでアプリを事前にテストすることも推奨されています。挙動や性能が変わりうるからです。

運用側でやることは3つです。

利用しているモデルのIDを、エージェントごとに台帳へ記録しておきます。管理画面のUsageで、APIキー別・モデル別の利用状況を出力すれば、旧モデルの利用箇所を洗い出せます
廃止の通知が来たら、評価ケース一式を移行先のモデルで走らせます。壊れたケースがハーネスの直しどころです
通知を受け取る担当者を決めます。通知先が退職者や異動者の宛先のままで届かない、という事態を避けるためです

AmazonのBedrockやGoogleのVertex AI経由で使っている場合は、それぞれ独自の廃止スケジュールがあります。個別のモデルの廃止日は、必ず公式ページで確認してください。

設定ごとのロールバック

障害時に、アプリケーションのコードだけを前のバージョンに戻しても直らないことがあります。エージェントの振る舞いは、コードの外にある設定の組み合わせで決まるからです。

プロンプト、モデルの指定と設定値、ツール定義、ガードレール（出力の制約）、参照しているナレッジ。この5つを、1つの「構成」としてバージョン管理し、まとめて前の正常な状態へ戻せるようにします。これは本記事での整理で、公的な標準手順があるわけではありません。ただ、変更が1つの記録に残っていないと、戻す先が分からなくなります。

バージョン管理するのは、構成と評価ケースの対です。どの構成が、どの版の評価ケースで合格したかが残っていれば、正常な状態を客観的に選べます。

障害時の対応の流れ

公式の決定版の手順は確認できていません。ここに示すのは、AWSのアラーム、Microsoftの品質しきい値アラート、失敗を評価ケースにするという考え方を組み合わせた、本記事の提案です。

検知します。品質や安全性の指標がしきい値を下回ったら通知します
影響を止めます。自動処理を止め、人への引き継ぎに切り替えます。誰が止める判断をするかは、事前に決めておきます
切り分けます。直近の構成変更、モデル側の更新、接続先システムの変化のどれかを、ログとトレースで確認します
戻します。構成を直前の正常版へ戻し、評価ケースで確認してから再開します
失敗を評価ケースに追加します。原因をハーネスのどこかに直し、同じ障害を二度と見逃さないようにします

特に2番目が肝心です。AIが誤った処理を続けている間は、原因究明より先に止めます。

運用体制は社内で持つものと外部に任せるものを分ける

運用体制は、評価ケースの所有を社内、ハーネスの設計と評価基盤の立ち上げを外部のFDEが担当する、という分け方が基本です。社内に残す役割と外に出す役割を、先に切り分けます。

役割分担の考え方

FDE（Forward Deployed Engineer）は、顧客の現場に入り込み、本番まで作り込むエンジニアです。助言や試作が中心のSEとは、現場に入る深さが違います。

以下は本記事の提案で、出典のある標準ではありません。

役割	担い手	理由
失敗の判定と評価ケースの所有	社内（業務の担当者）	何が正しい対応かは業務知識がないと決められない
評価基盤とハーネスの設計・立ち上げ	外部FDE	立ち上げの経験が少ない領域で、速く形にするため
日常の調整・最適化	社内と外部の共同	現場の知識と、ハーネスの技術の両方が要る
障害時の一次対応	社内（止める判断）と外部（原因調査）	業務を止める判断は社内でしかできない
モデル廃止の対応	外部FDEが主導、社内が確認	評価ケースの再実行は技術、合否の判断は業務

プロンプトの調整やデータの精度向上には、現場の知識が欠かせません。このため、すべてを外部に任せる体制は長続きしません。外部のFDEが現場にいる間に、社内の担当者が評価ケースの書き方とハーネスの直し方を身につける、という移行を最初から組み込んでください。

評価ケースを書ける人材を社内に持つには、AIを使った開発の基礎を学ぶ場が役立ちます。当協会のAI駆動開発研修は、そのための入口になります。

FDEに任せきりにしないほうがよい理由

FDEは、製品の未成熟さを埋める松葉杖として使われてしまう場合があります。Constellation Researchの記事は、この点を警告しています。人を現場に入れれば解決する、という期待は危ういということです。

2026年5月には、Anthropicが企業向けの導入支援を行う合弁の設立を発表し、OpenAIも同様の合弁を準備中だと報じられたとTechCrunchが伝えています。導入後に人が入って育てる形が、AIベンダー側からも重視され始めたことを示します。ただし、日本国内でのFDE提供の実態や価格帯は、公的な情報では確認できていません。外部に頼る場合も、契約の範囲と引き継ぎの内容は書面で確認してください。

当協会のFDE支援

当協会は、法人のAI導入を4段階で支援しています。AIリテラシー研修・教育、導入の伴走支援（3〜6か月の継続支援）、AI環境の構築・導入開発、そしてFDEによる継続的な最適化・保守です。

FDE支援は「育てる」段階として設計しており、最適化の対象はモデルではなくハーネスです。主な業務は、AIエージェントの調整・最適化、システム障害時の保守対応、運用の伴走と質問対応です。形態は、主に客先に常駐する形です。導入の進め方全体は、AI駆動開発導入をPoCから社内定着まで進める方法で整理しています。

よくある質問

AIエージェントの運用と保守は何が違いますか？

運用は日々の監視と調整、保守は障害対応やモデル廃止などへの対応です。ただしエージェントでは両者が地続きで、どちらも失敗を評価ケースに変えて、ハーネスを直す同じサイクルで回します。

LLMOpsと同じものですか？

近い関係ですが、範囲が違います。LLMOpsはプロンプト管理、監視、コスト、評価の基盤全体です。ハーネスはその上で動くエージェントの周辺環境を指し、改善サイクルで両者がつながります。

評価ケースは最初に何件用意すればよいですか？

20〜50件の簡単なケースから始めます。最初から網羅しようとせず、本番で失敗が出るたびに1件ずつ足すのが現実的です。

モデルの廃止通知が来たらどうしますか？

移行先のモデルで評価ケース一式を再実行し、壊れた箇所をハーネスで直します。Anthropicの公開モデルは最低60日前に通知されるので、その期間を検証に使います。

運用を全部外部に任せても大丈夫ですか？

勧めません。何が正しい対応かを決める評価ケースの所有は、業務知識のある社内に残すべきです。立ち上げと技術的な調整を外部に任せる形が現実的です。

まとめ

運用・保守の出発点は、評価ケースを20〜50件そろえることです。その次に、本番で出た失敗を1件ずつ追加し、原因をルールファイル、プロンプト、ツール接続、評価のどこに割り当てるかを記録してください。

並行して進めたいのは、利用中のモデルIDの台帳づくり、構成のバージョン管理、障害時に誰が止めるかの取り決めです。後回しにすると、廃止通知や障害の当日に慌てます。

体制は、評価ケースの所有を社内に置くところから決めてください。ハーネスの設計や立ち上げに経験者が必要なら、外部のFDEを使いながら社内の担当者に技術を移す前提で組みます。

AIエージェントを本番に出した後の改善サイクルの立ち上げや、導入後の保守体制づくりは、当協会のFDE支援で相談できます。評価ケースの整備、ハーネスの調整、障害時の対応体制まで含めて、まずはお問い合わせフォームからご相談ください。