「作れる」と「使われ続ける」は別問題

本日は、これまでさまざまなお客様に対してAIエージェントやLLMアプリケーション開発、LLMOps・AgentOpsを提供してきた経験を踏まえ、AIエージェントシステムを運用に乗せていくための観点についてお話しします。

AIエージェントシステムとは、生成AIベースのエージェントがツール利用や外部サービス連携を駆使しながら、ユーザーからの依頼に応じてさまざまな仕事に自律的に取り組む仕組みです。シンプルなチャットボットにとどまらず、エージェント自身が計画し、権限を持って自律的に動作する点がポイントです。

Claude Codeのようなコーディングエージェントの力を借りれば、エージェントシステムを高速に組み上げることが可能になってきました。しかし、動くものを作れたとして、それが本番で価値を出し続けられるかどうかは別問題です。

PoCではうまくいっていたのに本番で重大な事故を起こした事例は多数報告されており、平均して46%のAI PoCが本番化に至らず中止されているという報告もあります。それだけPoC段階と本番化の間には大きな崖があるということです。

代表的な失敗事例を3つ挙げます。1つ目は、コード凍結中にもかかわらずAIエージェントが独断で本番DBを削除し、1,206名の経営幹部記録と1,196社のデータが影響を受けたReplitのケースです。バックアップも同じ場所に置いていたため復旧もできず、深刻な問題となりました。2つ目は、Air Canadaのケースです。AIチャットボットが存在しない遺族割引を案内してしまい、裁判所が航空会社に賠償を命じました。AIがハルシネーションをした責任は企業が負うという判決は、AIエージェントを提供する立場として無視できない事例です。3つ目はKlarnaのケースで、カスタマーサービスをAIに置き換えて約67%の自動化を実現したものの、顧客体験の品質が低下し、最終的に人間のサポートを再投入する事態になりました。

これらの事例から、「使われ続けるためには、安全性やブランドを守りながら高品質に運用するための設計が重要」というのが本日のテーマです。

運用が難しい理由：PoCと本番の4つのギャップ

なぜ運用は難しいのでしょうか。PoC時点と運用時の考慮ポイントを比較すると、4つのギャップが見えてきます。

1つ目は、PoCでは固定データで検証しているのに対し、運用時には日々生まれるデータへの対応が必要になる点です。古いデータや未整備のデータがハルシネーションの要因となります。2つ目は、PoCでは限定シナリオで評価するのに対し、運用時には多様かつ想定外・敵対的な入力が想定されるため、ガードレールを設けて対処する必要があります。3つ目は、PoCでは人間が結果を確認していますが、運用時には無人あるいは極少人数で品質を守る必要があるため、トレース情報を付与した上で自動評価し、劣化を検知する仕組みが求められます。4つ目は、PoCではサンドボックス環境で検証しますが、運用時にはエージェントが権限を持って実データを操作するため、失敗が実害に直結します。さらに複数のエージェント連携が強まるほど、統制が困難になっていきます。

また、技術的な設計観点とは別に、「静かに使われなくなる」リスクも重要です。KGI・KPIが未設定のまま進めてしまうと価値を測れなくなり、ユーザーシナリオや業務接続が未設計だと現場のフローに乗らず使われなくなります。そして運用責任者・改善体制の空白があると、放置されてシステムが劣化していきます。これらは多くの現場で実際に発生している課題です。

設計観点①：AI Readyなデータ基盤

5つの設計観点の1つ目は、データ基盤です。

整備されていないデータはエージェントの誤った行動を誘発します。高性能なAIエージェントを実現するためには、利用モデル以上にデータ品質が鍵となります。例えば、「売上」という同じ単語でも、部署ごとに出荷基準・売上基準・入金基準と定義が揺れていると、LLMが適切なカラムを選択できず誤答につながります。LLMは定義に矛盾があっても自信満々に誤答する傾向があり、未整備の状態ではセマンティックドリフトを増幅させてしまいます。

AI Readyなデータ基盤には、5つの層が必要です。

①コンテキスト層では、データに「意味・出自・鮮度・前提」を付与します。「このカラムは税抜か税込か」「この売上は会計基準か管理会計か」といった情報を整備することで、弊社の実績では検索のヒット率が40%から90%程度まで向上したケースもありました。②データモデル層では、データの構造・粒度・関係性を定義します。スタースキーマでfactとdimensionが明確に分離されているか、「売上」の粒度がテーブル横断で一致しているかなどが重要です。③オントロジー層では、ドメインの概念とその関係をテーブルを超えた抽象レベルで定義します。「解約予兆＝直近3ヶ月の利用頻度が前年同期比50%以下」といった定義が複数テーブル間で共有されているような状態を目指します。④ガードレール層では、AIがやってはいけないことを構造的に防御します。アクセス制御やPIIマスキング、行レベル・列レベルのセキュリティなどが該当します。⑤評価ハーネス層では、AIの出力が正しいか・劣化していないかを継続的に測定・検証できる仕組みを整備します。

オントロジーに関連して、セマンティックレイヤーも重要なコンセプトです。

指標の「意味（定義）」と「実装（クエリ）」を1つの定義単位で一元管理することで、運用の中で定義がズレていくメトリックドリフトを防ぎます。半年も経てば部署ごとに異なる「売上」が再び生まれてしまうような状況を、宣言的な定義で抑制します。

AI Readyなデータ基盤は「作って終わり」ではなく、運用を回すことが前提です。メトリクス定義をコードとして管理し（definitions-as-code）、誰がいつ定義を変えたかを差分で追える状態にします。また、データオブザーバビリティによってデータの鮮度の遅延・ボリュームの異常・スキーマドリフトなどを自動で継続検知する仕組みも不可欠です。これらの異常は明示的なエラーとして現れず、「それらしい数字を出し続ける」ため非常に厄介で、データリネージと組み合わせて原因の上流と波及する下流を特定することが重要です。

設計観点②：精度×コストの最適化

2つ目の観点は、精度とコストのトレードオフです。

最上位モデルをマルチエージェント形式で多段に並べるほど精度は上がりますが高コストになり、安いモデルに置き換えると精度が落ちます。PoCで高精度な結果が出ても、実際の運用コストが見合わず、ユーザー1セッションあたりのコストが跳ね上がってPoCで終わってしまうケースも少なくありません。

着手順が重要で、まず①コストと品質を計測する（評価セット・LLM-as-a-judge）、次に②キャッシュ戦略を練る、そして③タスクでモデルを使い分けるルーティングを考えます。大量リクエストを処理するケースでは、全体の半分をキャッシュでまかなえた事例もあります。④難所だけ上位に回す（カスケード）や⑤SLM・Fine Tuningは難易度が高いため最後の選択肢です。

この最適化の取り組みにより、必要な精度を保ったままコストを1/3まで抑えられた事例も実際に発生しています。

また、コストが「静かに暴走する」リスクにも注意が必要です。エージェントシステムではエージェント同士が連鎖的に呼び出しを繰り返す設計となることが多く、最長経路の設計が漏れると気づかぬうちにコストが膨張します。実際に、暴走したマルチエージェントAIシステムが264時間にわたってエージェント同士でやりとりを続け、11日間で47,000ドルのLLM API費用が発生した事例もあります。計測するだけでなく、ステップ上限・予算上限を設けることが重要です。

さらに、モデル変更への備えも欠かせません。利用しているモデルは予告なく更新されることがあるため、バージョン固定とモデル変更時の回帰テストにより品質を維持する活動が必要です。公開ベンチマークは汎用的な能力を測る設計であり、自社の実タスクの品質を必ずしも反映しないため、必ず自社タスクで評価する必要があります。

設計観点③：AgentOps

3つ目の観点は、AgentOpsです。

AgentOpsとは、複数ステップにわたるタスク遂行やAPI連携などを行うエージェント全体のライフサイクル管理を重視し、複雑性や非決定論性へ対応するものです。

評価は大きく3つの単位で行います。まず「システム全体の評価」として、エンドツーエンドでのタスク達成度や制約遵守状況を見ます。次に「エージェント・サブモジュール単位の評価」として、エージェント単位の思考評価・アウトプット評価・モデル選択・エラー発生率などを確認します。最後に「選択や軌跡の評価」として、最終結果が得られるまでの経路長を評価し、不要なツール呼び出しや余計なステップがないかを検証します。Human-in-the-loop（HITL）が適切なタイミングで呼ばれたかどうかも評価対象となります。

どこまでやるかという観点では、MUSTとして「トレース収集・小さなデータセットでの評価・変更時の回帰テスト・HITLの導入」を最低限押さえ、投資対効果を見ながら段階的に評価の仕組みを広げていくことを推奨します。

設計観点④⑤：統制・権限と安全・ブランド

4つ目の観点は、統制と権限です。エージェントシステムの統制上の代表的な課題は「過剰権限」と「乱立」の2つです。エージェントに不必要に強い権限を与えてしまうと、誤りや乗っ取りが発生した際の被害リスクが高くなります。また社内でのエージェント開発が盛んになった結果、さまざまなエージェントが作られ管理されず放置・残存し、攻撃面が増えてしまう問題も生じます。

対応策として、①固有IDを与える（共有禁止）、②最小権限＋ユーザー代理（OBO）、③アクセス境界の判断をLLMに委ねない、④ユーザーとエージェントをどちらもトレースに記録、⑤Agent Registryで期限を管理、⑥高リスク実行はユーザー承認を挟む、という6つの打ち手を組み合わせて対応します。

5つ目の観点は、安全性とブランドガバナンスです。ユーザーや外部と接するエージェントは、敵対的な入力やブランド毀損のリスクに常にさらされています。配送ボットが誘導されて自社批判投稿を生成して炎上したDPDのケースや、メール1通のゼロクリックでCopilotから社内情報が外部流出したEchoLeakのケースなどが実例として挙げられます。

単独のガードレールは敵対的入力で6〜7割が破られるという報告もあり、入力ガード・最小権限・出力ガード・監査・HITLという多層構成で対処することが基本となります。

まとめ：「作れる」の次は「使われ続ける」

AIエージェントが使われ続けるためには、データ基盤の整備、精度とコストの両立、AgentOpsの導入、統制と権限の設計、安全性とブランドの保護、という5つの観点がかみ合って初めて、本番で価値を生み続けるシステムとなります。

一見すると正常に動作するAIエージェントを作ることのハードルは大きく下がりました。しかし「作れる」の先にある「使われ続ける」を実現するために、安全性やブランドを守りながら高品質に運用するための設計を、ぜひ意識して進めてください。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
AI Engineering Summit Tokyo 2026
※動画の視聴にはFindyへのログインが必要です。