AI coworker／自律エージェントの SLA 設計｜失敗時の人の介入・責任分界・監査ログの残し方

生成AIの進展により、単なるチャットボットを超えた「AI Coworker（AI同僚）」や「自律エージェント」が実務に投入され始めています。しかし、従来のようなシステム稼働率（99.9%など）を中心としたSLA（サービス品質保証）だけでは、AIエージェントの運用は成立しません。

AIは確率的に動作するため、100%の正確性を保証することは不可能です。ここで重要になるのが、「AIが失敗することを前提としたSLA設計」と、「失敗時の人の介入フロー（Human-in-the-Loop）」、そして「誰が責任を取るのかという責任分界」の明確化です。

本記事では、自律エージェントをビジネスに実装するIT実務担当者やDX責任者が直面する、これらガバナンス設計の具体的指針を解説します。

1. AI CoworkerにおけるSLAの再定義

従来のSaaSやシステムのSLAは、「動いているか（可用性）」と「処理速度（応答性能）」が主眼でした。しかし、AIエージェントにおいては、これらに加えて「出力の妥当性」と「自律性の限界」を定義する必要があります。

可用性とスループット

OpenAIのAPIやAnthropicのClaudeなど、基盤となるLLMのアップタイムに依存します。自律エージェントの場合、内部で複数のエージェントが連携するため、単一のAPIダウンが業務全体の停止に直結します。

公式のステータス確認例：OpenAI Status / Anthropic Status

出力品質（ハルシネーション許容率）

AIが「もっともらしい嘘」をつく確率をゼロにすることは現状不可能です。そのため、SLAには「RAG（検索拡張生成）による根拠提示率」や「ハルシネーション発生時の検知率」を盛り込みます。例えば、「外部公開する回答については、必ず根拠となる社内ドキュメントのURLを付与し、人間が最終確認を行う」といった運用ルールの合意が、実質的なSLAとして機能します。

自律継続限界（Autonomy Limit）

エージェントがタスクを解決できない場合、無限に思考を繰り返してトークンを消費し続けるリスクがあります。「最大3回のリトライで解決しない場合は人間にエスカレーションする」といった、AIが「降参」する基準を設けることが、運用コストの爆発を防ぐ鍵となります。

2. 責任分界と人の介入（Human-in-the-Loop）の設計

AIエージェントが「勝手にメールを送信した」「勝手に在庫を発注した」という事態が起きた際、誰がその責任を負うべきでしょうか。これは単なる倫理の問題ではなく、法務・コンプライアンス上の実務課題です。

責任分界モデル（Shared Responsibility Model）

クラウドコンピューティングと同様、AIエージェント運用においても以下のような責任分界を明確にします。

• プラットフォーム層（OpenAI等）：基盤モデルの安全性、インフラの稼働。
• アプリケーション層（開発者）：プロンプトの堅牢性、ツール呼び出しの正確性、認可制御。
• ビジネス運用層（利用者）：入力データの妥当性、AI出力の最終承認、業務への適用判断。

介入ポイントの設計

業務の重要度に応じて、介入のタイミングを使い分けます。
例えば、経理業務の自動化において、AIが仕訳を行う際のフローを考えてみましょう。

「楽楽精算」からデータを出力し、「freee会計」へ連携するプロセスをAIが担う場合、単純な転記は自動化できても、勘定科目の判断ミスは税務リスクに直結します。
このようなケースでは、「楽楽精算×freee会計のCSV手作業を滅ぼす」アーキテクチャで解説しているような、バリデーションロジックと人間による最終承認ステップを必ず組み込むべきです。

3. 監査ログとトレーサビリティの確保

AIエージェントが「なぜその判断をしたのか」を後から検証できない状態（ブラックボックス化）は、企業にとって最大のガバナンスリスクです。事後検証を可能にするため、以下のデータを構造化して保存する必要があります。

残すべき監査ログの5要素

1. Input（プロンプト）：ユーザーからの指示と、システムプロンプトのバージョン。
2. Retrieval Context：RAGで取得されたナレッジの断片（どのドキュメントを参照したか）。
3. Thinking Process（CoT）：AIが内部で展開した思考のステップ。
4. Tool Call（Action）：外部APIの実行コードとその引数。
5. Output（結果）：最終的な回答と、それに対する人間の評価（フィードバック）。

特に、権限管理の観点からは、AIがどのSaaSに対してどのような操作を行ったかを記録することが不可欠です。例えば、社内システムのID管理を自動化する場合、「SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ」アーキテクチャのような自動化フローにおいて、AIエージェントが操作を行う際は、その操作ログをEntra IDやOktaなどのIDP（Identity Provider）側のログと紐付けて管理することが推奨されます。

4. 自律エージェントプラットフォームの比較

現在、自律エージェントを構築するためのフレームワークやプラットフォームが乱立しています。実務で選定する際の基準を整理しました。

企業が導入する場合、単に「動く」ことよりも、「途中で停止して人間が介在できるステートフルな設計ができるか」を重視すべきです。その点では、LangGraphのような状態管理に厳格なツールが、SLA遵守の観点からは優位性があります。

5. 設定・運用のステップバイステップ

AIエージェントを実務に投入する際、以下の手順で設計を進めます。

ステップ1：業務の構造化と「AIの自由度」の決定

すべての工程をAIに任せるのではなく、決定的な処理（プログラムで書ける部分）と、非決定的な処理（AIが判断する部分）を分離します。
例えば、顧客データの名寄せ作業を行う場合、「ITP対策・LINEログインを用いたセキュアな名寄せ」の知見を活用し、確定的なID連携をベースにしつつ、表記揺れの修正のみをAIに担当させるといった「責務の分離」を行います。

ステップ2：ガードレール（例外処理）の実装

AIが想定外の出力をした際の「ガードレール」を多重に設定します。

• 出力バリデーション：JSON形式の強制、必須項目の有無チェック。
• セマンティック・ガードレール：不適切な用語、競合他社情報の排除。
• タイムアウト設定：1つのタスクに30秒以上かかった場合は強制停止。

ステップ3：運用監視とドリフト検知

LLMのモデルアップデートや、入力データの変化によって、徐々に精度が低下する「ドリフト」が発生します。
週に一度、ログからランダムにサンプリングし、人間が「期待通りの動作であったか」をスコアリングする体制を構築します。これが将来的なAI再学習やプロンプト改善の貴重なデータとなります。

よくあるエラーと対処法

エラー1：APIレートリミットによる停止

対処：指数バックオフによるリトライ処理の実装、またはティアの高いAPIプランへの移行。

エラー2：ツール呼び出し引数の型不正

対処：Pydantic等を用いた型定義の厳格化と、LLMへのFunction Calling用ドキュメントの再整備。

エラー3：無限ループ（Halting Problem）

対処：最大再帰回数（Max Iterations）の設定と、各ループでの「進行状況」の自己評価プロンプトの挿入。

まとめ：AI Coworkerは「契約」で育てる

AI Coworkerの導入は、一度設定して終わりではありません。SLAを定め、責任の所在を明確にし、ログを通じて対話を続けることで、初めて「信頼できる同僚」へと成長します。
IT実務担当者の役割は、AIを作るだけでなく、AIが「安全に失敗できる環境」を整えることに他なりません。

まずは小規模な内部業務から、本記事で紹介したSLA設計と責任分界モデルを適用し、実務におけるAIガバナンスの最適解を模索してみてください。