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）側のログと紐付けて管理することが推奨されます。

監査ログ5要素：具体的に何を・どこに・どう記録するか

前述の「残すべき5要素」は、何を記録すべきかの羅列にとどまります。実務でよくある失敗は、ログが存在してもバラバラなツールに散在していて、インシデント発生時に追跡できない状態です。下表では、各ログ要素について「記録すべき具体的な内容」「現場で使われる保存先・ツール」「そのログを省略した場合に起きるリスク」を整理しました。エージェント設計の初期に、このログ設計をアーキテクチャに組み込むことで、後からの追加コストを大幅に削減できます。

実装上のコツは、「すべてのログを単一の相関ID（trace_id）でひも付ける」ことです。ユーザーの1リクエストに対してInput→Retrieval→Thinking→Tool Call→Outputの全ログが同じtrace_idを持っていれば、インシデント発生時にその1件のエージェント行動を1本の時系列として追跡できます。ツールごとにバラバラなキーで管理すると、ログが存在しても「点」にしかならず、監査目的では使い物になりません。

Claude Code エージェントの SLA 設計：会計・経理領域での Human-in-the-Loop 実装例

AI coworkerの概念設計として「Human-in-the-Loop」の重要性が語られますが、会計・経理の自動化で具体的にどう実装するかを整理します。Claude Codeを使ったエージェントを例に、失敗時のエスカレーションフローと監査ログの残し方を示します。

会計自動化エージェントの「失敗時」シナリオ定義

エージェントが「失敗した」と判断する基準を事前に明文化することが、SLA設計の出発点です。会計・経理用途では以下のシナリオが代表的です。

Claude Code エージェントでの介入ポイント実装パターン

Claude Code（またはClaudeを使ったエージェント）に会計自動化タスクを委任する場合、介入ポイントを明示的にコードで定義します。以下は疑似コードによる構造例です。

# エージェントへの指示（CLAUDE.md または システムプロンプト内）

## 会計自動化タスクのルール

以下の場合は処理を中断して、必ず人間の確認を求めること：

1. 科目の確信度が低い場合（どの勘定科目か判断できない場合）
   → 「[要確認] 仕訳ID: XXX 勘定科目候補: A（60%）/ B（30%）」形式で報告

2. 金額が前月比200%を超える場合
   → 「[異常値アラート] 前月比: +230% 金額: ¥450,000」形式で報告

3. 複数の事業所・顧問先が混在する可能性がある場合
   → 全処理を停止し、どのデータが混在しているかを報告

上記に該当しない場合のみ、自動でfreeeへの仕訳登録を実行すること。

この指示をCLAUDE.mdに記述しておくことで、Claude Codeは条件に当たる仕訳を自動で保留し、人間にレビューを求めます。

監査ログとして残すべき5要素の実装

AIが自動処理した仕訳は、後で「なぜこの科目にしたか」を説明できるように記録します。最低限、以下を構造化ログとして保存します。

• タイムスタンプ：ISO 8601形式（例: 2026-06-14T09:32:11+09:00）
• 入力データ：AIに渡した請求書・取引情報のハッシュ値（PII保護のためデータそのものではなくハッシュ）
• AI判断内容：提案した勘定科目・摘要・金額と、使用したモデル（例: claude-sonnet-4-6）
• 介入状況：自動実行か、人間が確認/修正したか
• 最終実行結果：freee/MFへのAPI書き込み結果（成功/失敗・エラーコード）

これらのログはAurantのRuleHubで一元管理できます。RuleHubのMCP連携を使うと、Claude CodeからfreeeへのAPI操作ログが自動的に蓄積され、事後の監査やクライアント報告に使えます。

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ガバナンスの最適解を模索してみてください。