信頼性こそがエージェントAIの真の試練

過去2年間、業界は一つの質問を投げかけてきました：AIエージェントは実務をこなすだけの能力があるか？質問はもうやめても構いません。彼らにできることは分かっていますが、エージェントが高額なミスを犯しそうになる瞬間を特定し、そしてそれが起こる前に止められるかどうかに、レーザーのように焦点を当てる必要があります。

本番環境での最悪の失敗は、通常、単純なモデルエラーのようには見えません。エージェントはすべてのAPI呼び出しを正常に完了させても、古いコンテキストで作業したり、失敗しているツールを再試行したり、ルールに違反する行動へ向かうことがあります。信頼性こそが、エージェントAIプログラムがパイロット段階を抜けられるかどうかを左右します。

「2025年のAIの現状：エージェント、イノベーション、変革」という報告書によると、McKinsey 調査、組織の62％がAIエージェントを試験的に導入していますが、これらの機能のいずれでもスケールさせていないのは約10％に過ぎません。エージェントが機能することを同僚に示すのは簡単です。しかし、実データと接続されたシステム上で安全に運用するのは容易ではありません。

エージェントAIがリスクを増幅させる理由

エージェントは確率的推論、ツール利用、そしてある程度の自律性を組み合わせます。これにより有用性が高まりますが、同時に従来のアプリケーションよりも速くエラーが蓄積するリスクを企業にもたらします。

コンテキスト

エージェントは提供されたコンテキストからしか作業できません。したがって、そのコンテキストが不完全、古い、または誤っている場合、初期の誤った解釈がすべての後続ステップに引き継がれます。欠陥のあるチャットボットの返信は不快ですが、アクセス権限を変更したりインフラに触れたりする誤った解釈はインシデントとなります。何か問題が発生した際に、エージェントが適切な証拠を使用し、ポリシーに従い、許容できる影響範囲内に留まっていたかを把握することが重要です。

ナレッジベース

エージェントはナレッジベース、チケットシステム、決済プラットフォームにも接続しますが、接続が増えるほど攻撃面が広がります。エージェントは誤ったツールを呼び出したり、正しいツールを誤った順序で呼び出したり、取得したコンテンツに隠された指示に従って行動したりすることがあります。これらは既知の失敗モードであり、エージェントがツールとコンテキストを連鎖させる過程で生じる妄想（confabulation）やセキュリティ脆弱性を含みます。

緑色のダッシュボードは誤解を招くことがあります。インフラは正常に見えても、エージェントが同じツールを静かに何度も問い合わせている場合があります。これは通常の障害ではなく、ドリフトの早期兆候です。

非決定性

非決定性はインシデント対応をさらに困難にします。従来のサービス障害は通常、リクエストIDと既知のソフトウェアバージョンで再現できますが、エージェントの実行はモデルのバージョン、取得した文書、得られたツールの出力、そして一連の中間決定に依存します。エージェントが受け取った情報や試みた内容の記録がなければ、根本原因分析やガバナンスは格段に難しくなります。

コストとレイテンシ

コストとレイテンシは別の視点から同じことを語ります。トークン使用量やリトライが急増すると、ユーザーが最終的に回答を得たとしても、計画の不備やループを示すシグナルとなります。推論コストが急激に下落した過去数年間で、推論コストが下がり、安価な推論により非効率な動作を無視しやすくなりますが、その動作が何千ものワークフローで繰り返されるまでです。コスト、レイテンシ、リトライを信頼性のシグナルとして扱い、単なる財務指標とみなさないでください。

分散型AIでも集中型の可視性が必要

明確なガードレールがなければ分散化は失敗します。ワークフローとエスカレーションの所有権は現場チームに委ねつつ、アイデンティティ、アクセス、インシデント対応は企業レベルで管理すべきです。財務チームは、一般的なベンチマークでは判断できない、正当な請求書例外と不適切な支払い決定の違いを見分けることができます。同じ調査で、McKinsey は、実際のAI効果を報告している組織は、既存のシステムにAIを付け足すよりも、ワークフローを再設計した可能性が約3倍高いことを明らかにしました。

とはいえ、トレードオフは実在します。インシデントがシステムを跨ぐと所有権がすぐに曖昧になります。解決策は、すべてのエージェント、そのツール、データアクセス、インシデント履歴を共有する運用ビューです。

分散型アーキテクチャは、何かが故障したときに全体像を把握しにくくします。多くのチームはトークン使用量やコストは確認できますが、エージェントが意図した結果を安全に達成したかどうかは確認できません。ワークフロー全体にまたがるレコードが異なる場所に存在すると、チームは原因ではなく症状を追いかけることになりがちです。

モデルの識別子やツール呼び出しといった標準化されたテレメトリ信号は役立ちます。ワークフローにおける通常のステップ数などの行動ベースラインも、停止したシステムから有用な持続性を特定するために必要です。評価はリリース前の一度きりのゲートではなく、継続的なループです。

本番環境で実際に見える信頼できるAI

信頼できるAIとは、ミスを回避することではなく、ミスを管理することです。チームは行動の可視性が必要で、パフォーマンスがドリフトした際のアラートや、問題が発生したときの対処計画が求められます。最も重要なのは、すべてのエージェントにアクセスと自律的な行動に関する明確なガードレールを設定することです。また、人間による承認も必要です。 

まずは取り消し可能な低リスクのアクションから始めます。プロダクションの変更や金融取引など、重要なものは実際のコントロールの背後に置きます。重要なワークフローは、事後に再構築できるようにすべきです。その際、エージェントが取得したコンテキスト、呼び出したツール、取得した承認、そして結果が実際に正しかったかどうかも含めます。

従来のサービスレベル目標は、エージェントの品質と安全性もカバーするように拡張する必要があります。具体的には、検証済みタスク成功率、ポリシー遵守率、人間エスカレーション率、タスクあたりのコスト、そして望ましくない結果が発生する頻度が含まれます。しきい値はユースケースごとに変えるべきです。内部のナレッジアシスタントは、規制データに触れるエージェントとは異なるエラープロファイルを許容できます。

最も有用な信頼性システムは、失敗の前兆となる条件を見つけ出すことを学習します。たとえば、リトライ回数の異常な急増や、過去に人間の介入が必要だった経路などです。低リスクのワークフローは自動修正をトリガーでき、リスクが高いものは一時停止し、権限を持つ人物に判断を委ねるべきです。目的は、単に自律的な行動を行うことではありません。証拠が裏付ける場合に、より速く、より安全な行動を実現することが目的です。

AI SRE がループを閉じる

ここで AI SRE が活躍します。AI SRE エージェントはインシデントのタイムラインを組み立て、現在の挙動を過去のインシデントと比較し、推奨アクションを作成します。一方で、組織は可逆的なタスクに対しては制御された修復を、重要なものに対しては人間の承認を維持します。

AI の導入は急速に進んでいますが、導入と運用成熟度は同じではありません。エージェント型AIを大規模に展開できる企業は、必ずしも最も高性能なモデルを単独で走らせている企業とは限りません。むしろ、エージェントの全社的な挙動を把握し、ドリフトの早期兆候を捕らえ、小さなエラーが顧客、セキュリティ、コンプライアンスの問題に発展する前に介入できる企業が成功します。 

これが AI SRE の果たす役割です：分散したイノベーションと集中した可視性を結びつけ、エージェント型AIを企業が信頼できるシステムへと変換します。