ほら、私たちは過去18カ月をかけて本番環境のAIシステムを構築してきました。そして夜眠れなくさせるのが何かをお伝えします — モデルが質問に答えられるかどうかではありません。それは今や「テーブルステークス」に過ぎません。私たちを悩ませるのは、誰かが設定ファイルのタイプミスをしたために、午前2時にエージェントが自動的に六桁のベンダー契約を承認するという心のイメージです。
私たちは「ChatGPTラッパー」の時代を超えた（神に感謝）、しかし業界は依然として自律エージェントをAPIアクセスを持つただのチャットボットだと見なしています。彼らは違います。人間の確認なしにAIシステムに行動を取る能力を与えると、基本的な閾値を越えます。もう有用なアシスタントを作っているわけではなく、従業員に近い何かを作っているのです。そして、それはこれらのシステムを設計する方法を根本的に変えます。
誰も語らない自律性の問題
驚くべきことに、私たちは*自信があるように*聞こえるモデルを作るのが非常に得意になっています。しかし自信と信頼性は同じものではなく、その間のギャップが、実運用のシステムが失敗する場所です。
私たちはこのことを苦い経験として、役員チーム全体のカレンダーのスケジュールを管理させるAIエージェントを使うパイロットプログラムの中で学びました。簡単そうに見えますよね？エージェントは空き状況を確認し、招待を送信し、衝突を処理できました。ところが、ある月曜日の朝、それがSlackメッセージの「この場合はこれを推し進めよう」という表現を実際の指示として解釈したため、取締役会の会議を再スケジュールしてしまいました。モデルの解釈は間違っていませんでした—それはもっともらしく思えました。しかし、自律性を扱うとき、それが十分に正当な理由にはなりません。
その出来事は、私たちにとって非常に重要な教訓を教えてくれました: 機能するエージェントを作ることがほとんどの時間可能になることではなく、むしろ壊れずに動作させるための回路遮断器を備えたエージェントを作ることです。
自律システムにおける信頼性の本質
層状の信頼性アーキテクチャ
従来のソフトウェア工学で信頼性について語るとき、私たちは数十年分のパターンを持っています。冗長性、リトライ、冪等性、優雅な低下。しかしAIエージェントは私たちの多くの仮定を崩します。
従来のソフトウェアは予測可能な方法で失敗します。ユニットテストを実行できます。実行経路をたどることもできます。AIエージェントは、判断を下す確率的なシステムを扱っています。バグは単なる論理エラーではありません。むしろモデルがもっともらしく聞こえるが完全に作られたAPIエンドポイントを幻覚してしまうか、文脈を解釈する際に人間の意図を完全にはずして技術的には解釈できても人間の意図を完全に見逃すといったことです。
それではここで信頼性はどんな形になるのでしょうか？私たちの経験では、それは層状のアプローチです。
レイヤー1: モデル選択とプロンプト設計
これは基礎的なものですが不十分です。はい、手に入る最良のモデルを使いましょう。はい、例と制約を含む、慎重にプロンプトを作成しましょう。しかし、優れたプロンプトだけで十分だと自分を欺いてはいけません。私は多くのチームが「GPT-4と非常に良いシステムプロンプト」を搭載しただけで企業対応だと呼んでしまうのを見てきました。
レイヤー2: 決定論的ガードレール
不可逆なことを行う前に、厳格な検証を通過させてください。アクセスすべきでないリソースへアクセスしようとしていませんか？そのアクションは許容パラメータ内ですか？私たちは昔ながらの検証ロジック—正規表現、スキーマ検証、許可リスト—の話をしています。華やかではないですが、効果的です。
私たちがうまくいったパターンの1つ: 正式なアクションスキーマを維持すること。エージェントがとれるすべてのアクションには定義済みの構造、必須フィールド、検証ルールがあります。エージェントはこのスキーマ内でアクションを提案し、実行前に検証します。検証に失敗した場合、単にブロックするだけでなく、検証エラーをエージェントに返し、何が間違っていたのかの文脈を付けて再試行させます。
レイヤー3: 自信と不確実性の定量化
ここが興味深い点です。私たちは自分が知らないことを知っているエージェントが必要です。行動を起こす前に自分の自信について明示的に推論できるエージェントを実験しています。確率スコアだけでなく、実際に表現された不確実性: 「このメールをプロジェクトの遅延依頼として解釈していますが、文言はあいまいで、…とも意味する可能性があります」
これで全てのミスを防げるわけではありませんが、人間の監視を挿入できる自然な区切り点を作ります。高自信度のアクションは自動的に通過します。中程度の自信度のアクションは審査のためにフラグが立てられます。低自信度のアクションは説明付きでブロックされます。
レイヤー4: 可観測性と監査可能性
アクション検証パイプライン
デバッグできなければ、信頼できません。エージェントが下すすべての決定は、記録可能で、追跡可能で、説明可能である必要があります。単に「どのアクションを取ったのか」だけでなく「何を考え、どんなデータを検討し、推論の連鎖はどうだったのか」を説明できることです。
私たちは、プロンプト、応答、コンテキストウィンドウ、さらにはモデルの温度設定まで、完全な大規模言語モデル（LLM）の相互作用を捕捉するカスタムロギングシステムを構築しました。それは非常に冗長ですが、何かがうまくいかなかったときには、正確に何が起こったのかを再構築する必要があります。さらに、これはファインチューニングと改善のデータセットにもなります。
ガードレール: ノーと言う技術
ガードレールについて話そう。これはエンジニアリングの規律が本当に重要になる場面です。多くのチームはガードレールを後付けとして扱います—「必要なら安全チェックを追加します」—それは逆効果です。ガードレールは出発点であるべきです。
私たちはガードレールを三つのカテゴリーで考えています。
許可境界
エージェントが実際に物理的に何をすることが許されているのか？これはあなたの被害規模（爆発半径）を制御するものです。エージェントが最悪の行動を幻覚してしまうとしても、最大でどれだけの被害を引き起こせるでしょうか？
私たちは「段階的自律性」という原則を用います。新しいエージェントは読み取り専用アクセスから始まります。信頼性が証明されるにつれて、低リスクの書き込みへと昇格します（カレンダーイベントの作成、内部メッセージの送信）。高リスクのアクション（金融取引、外部通信、データ削除）は、明示的な人間の承認が必要か、単にオフリミットです。
うまく機能している技術の1つ: アクションコスト予算。各エージェントには日次の「予算」がリスクやコストの単位で設定されています。データベースレコードを読むには1単位、メールを送るには10単位、ベンダーへの支払いを開始するには1,000単位。予算を使い果たすまでエージェントは自律的に動作できます。使い果たしたら人間の介入が必要です。これにより、潜在的に問題のある振る舞いを自然に抑制します。
Graduated Autonomy and Action Cost Budget
意味的境界
エージェントが「取り組み対象内」か「取り組み対象外」かをどう理解すべきか？これは概念的で、単なる技術的な問題ではありません。
明確なドメイン定義が大いに役立つことを私は見つけました。私たちのカスタマーサポートエージェントには明確な任務があります：製品に関する質問に対応、返品を処理、苦情をエスカレーション。そのドメインの外にあるもの — 投資助言を求める人、第三者製品の技術サポート、個人的な頼み — には丁寧な断りとエスカレーションを行います。
境界をプロンプトの注入やジャイルブレイキングの試みに対して堅牢にすることが課題です。ユーザーはエージェントに範囲外のリクエストの対応を促そうとします。他のシステム部位が意図せずエージェントの境界を覆す指示を渡してしまうことがあります。ここでは複数の防御層が必要です。
運用上の境界
エージェントはどれだけのことをできるのか、どれくらい速く動けるのか。これがレート制限とリソース管理です。
私たちはすべてに厳格な制限を導入しました：1分あたりのAPI呼び出し回数、1回の対話あたりの最大トークン数、1日の最大コスト、人間へのエスカレーション前の最大リトライ回数。これらは人工的な制約のように見えるかもしれませんが、暴走を防ぐために不可欠です。
私たちは かつてスケジューリングの衝突を解決しようとしてループにはまるエージェントを見たことがあります。エージェントは何度も時間を提案し、却下され、再試行を繰り返しました。レート制限がなかった場合、1時間で300件のカレンダー招待を送信していたでしょう。適切な運用境界があれば、試行回数5回目の時点で閾値に達し、人間へエスカレーションしていただろう。
エージェントには独自のテスト手法が必要
従来のソフトウェアテストは自律エージェントには通用しません。LLMでは、すべてがエッジケースであるため、すべての境界条件を網羅するテストケースを書くだけでは足りません。
私たちにとって効果があったのは次の点です：
シミュレーション環境
本番環境を模したサンドボックスを、偽データとモックサービスを使って構築します。エージェントを思い切り動かしてみてください。何が壊れるかを確認します。私たちはこれを継続的に行います — コード変更のたびに、本番環境に触れる前に100のシミュレートされたシナリオを通過させます。
ポイントはシナリオを現実的に作ることです。ハッピーパスだけをテストしてはいけません。怒っている顧客、曖昧なリクエスト、矛盾する情報、システム障害をシミュレートします。敵対的な例も含めます。もしエージェントが物事がうまくいかないテスト環境を扱えないなら、本番環境を扱えるはずがありません。
レッドチーミング
創造的な人々にエージェントを壊してみるよう挑戦してもらいます。セキュリティ研究者だけでなく、ビジネスロジックを理解するドメインの専門家にも参加してもらいます。私たちの最も良い改善のいくつかは、営業チームのメンバーがエージェントを「だまそうとして」本来すべきでないことをさせようとしたときに生まれました。
シャドーモード
公開する前に、エージェントを人間と並行してシャドーモードで実行します。エージェントが意思決定をしますが、実際のアクションは人間が実行します。エージェントの選択と人間の選択の両方を記録し、その差分を分析します。
これは苦痛で遅いですが、価値はあります。テストでは決して捕捉できない、微妙なミスアラインメントが数多く見つかるでしょう。たとえば、エージェントが技術的には正しい答えを出していても、表現が会社のトーンガイドラインに反している場合があります。法的には正しくても倫理的に問題のある決定を下すこともあるでしょう。シャドーモードは、現実の問題になる前にこれらの問題を浮き彫りにします。
人間をループに組み込むパターン
3つの人間をループに組み込むパターン
自動化が進んでも人間は不可欠です。問題は、ループのどこに位置づくかです。
私たちはますます、「人間をループに組み込む」という概念が、実際にはいくつかの異なるパターンから成ると確信しています：
ループ上の人間: エージェントは自律的に動作しますが、人間がダッシュボードを監視し介入することができます。これは、よく理解され低リスクの運用における安定状態です。
人間をループに組み込む: エージェントがアクションを提案し、人間がそれを承認します。これは、エージェントが自らを証明していく間の“補助輪”モードであり、高リスク運用の恒久モードです。
ループ内で人間と協働する: エージェントと人間がリアルタイムに協働し、それぞれ自分の得意とする部分を担当します。エージェントが地味な作業を担い、人間が判断を下します。
コツは、これらの移行を滑らかにすることです。自動モードから監視モードに移動するとき、エージェントがまったく別のシステムのように感じてはいけません。インターフェース、ロギング、エスカレーション経路はすべて一貫しているべきです。
故障モードと回復
正直に言いましょう。エージェントは失敗します。その問題は、優雅に失敗するのか、それとも壊滅的に失敗するのか、という点です。
私たちは 失敗を3つのカテゴリーに分類します：
回復可能なエラー: エージェントは何かを試みますが、それが機能せず、エージェントはうまくいかなかったことに気づき、別のことを試します。これは問題ありません。これは複雑なシステムが動作する方法です。エージェントが事態を悪化させていなければ、指数バックオフで再試行させてください。
検出可能なエラー: エージェントが何か間違ったことをしますが、モニタリングシステムが重大な被害が起こる前にそれを検知します。ここでガードレールと可観測性が役に立ちます。エージェントはロールバックされ、人間が調査し、問題を修正します。
検知されないエラー: エージェントが何か間違ったことをしますが、かなり後になって誰も気づきません。これらは最も恐ろしいものです。数週間にわたり顧客リクエストを誤解しているかもしれません。微妙に不正確なデータ入力を繰り返しているかもしれません。これらは蓄積して体系的な問題へとつながります。
検知されないエラーに対する対策は、定期的な監査です。私たちはエージェントの行動をランダムにサンプリングし、人間がそれをレビューします。合格/不合格だけでなく、詳細な分析を行います。エージェントの挙動にドリフトは見られますか？間違いにはパターンがありますか？懸念すべき傾向を形成していますか？
コストと性能のトレードオフ
十分には語られていないことの1つは、信頼性にはコストがかかるということです。
すべてのガードレールは遅延を生み出します。すべての検証ステップは計算リソースを消費します。信頼性を確認するための複数のモデル呼び出しはAPIコストを増大させます。包括的なロギングは大容量のデータを生成します。
どこへ投資するかは戦略的であるべきです。すべてのエージェントが同じレベルの信頼性を必要とするわけではありません。マーケティング用のコピー生成器は、金融取引処理より緩くても構いません。スケジューリングアシスタントは、コードデプロイメントシステムより再試行を緩く許容できます。
私たちはリスクに基づくアプローチを採用しています。高リスクのエージェントにはすべての保護機能、複数の検証層、広範なモニタリングを適用します。低リスクのエージェントには軽量な保護を適用します。このトレードオフを明示し、各エージェントがなぜそのガードレールを持つのかを文書化することが鍵です。
組織的な課題
私たちは 最も難しい部分は技術的なものではなく、組織的なものであることに触れないのは過ちだと感じています。
エージェントがミスをした場合、所有者は誰ですか？それを作ったエンジニアリングチームですか？それを展開したビジネス部門ですか？監督するはずだった人ですか？
エージェントのロジックが技術的には正しいが文脈的には不適切なエッジケースをどう扱いますか？エージェントが規則に従う一方で、書かれていない規範に違反している場合、誰の責任ですか？
エージェントが暴走した場合のインシデント対応プロセスは？従来のランブックは人間のオペレーターのミスを前提としています。自律システム向けにこれらをどう適用しますか？
これらの質問には普遍的な答えはありませんが、展開前に対処する必要があります。明確な所有権、文書化されたエスカレーション経路、明確に定義された成功指標は、技術的なアーキテクチャと同じくらい重要です。
ここからの展望
業界はまだこの課題の解決を試みています。信頼性の高い自律エージェントを作るための確立されたプレイブックはまだありません。私たちは皆、実運用の中で学んでおり、それは刺激的でもあり、同時に恐れおののく側面もあります。
確かなことは、成功するチームはAIの問題だけでなくエンジニアリングの分野としてこれを扱うチームだということです。従来のソフトウェアエンジニアリングの厳密さ—テスト、モニタリング、インシデント対応—と、確率的システムに特有の新しい手法を組み合わせる必要があります。
あなたは用心深くあるべきですが、麻痺してはいけません。はい、自律エージェントは壮大な方法で失敗することがあります。しかし、適切なガードレールがあれば、膨大な作業量を超人的な一貫性で処理できます。リスクを尊重しつつ可能性を受け入れることが鍵です。
ここでひとつお伝えします。新しい自律機能を展開するたびに、プレモート演習を実施します。私たちはそれが今から6か月後だと想定し、そのエージェントが重大なインシデントを引き起こしたとします。何が起きたのでしょうか。どの警告サインを見逃したのでしょうか。どのガードレールが機能しなかったのでしょうか？
この演習は、数え切れないほど私たちを救ってきました。発生する前に失敗モードを熟考させ、必要になる前に防御を築き、前提を疑うことを促します。
結局のところ、エンタープライズ級の自律AIエージェントを作ることは、完璧に動作するシステムを作ることではありません。安全に失敗し、優雅に回復し、継続的に学習するシステムを作ることです。
そして、それこそが実際に重要なエンジニアリングの形です。
Madhvesh Kumar は主任エンジニアです。Deepika Singh は上級ソフトウェアエンジニアです。
表現されている見解は、自律エージェントの構築と展開に関する実務経験に基づくものであり、時には深夜3時のインシデント対応があなたのキャリア選択を問うこともあります。
