企業のインフラを自律的に操作するAIエージェントが、既存の障害分類では捕捉できない新種の本番障害を静かに生み出しています。VentureBeatの報道によると、PwC調査で79%の組織がすでにAIエージェントを本番環境で稼働させており、96%が拡大を計画しています。一方でGartnerは、リスク管理の不備により2027年末までにエージェントプロジェクトの40%が中止されると予測しています。

問題の核心は、人間のエンジニアがカオス実験を実施する際に行う「今この瞬間にシステムが追加ストレスを吸収できるか」という判断を、自律型エージェントが完全にスキップしている点にあります。たとえば、レイテンシ上昇を検知したエージェントがサービスを再起動した結果、ピーク時のトラフィック処理中だった他の3サービスへ障害が連鎖する事例が報告されています。エージェントは自身の行動のブラストラジアス（影響範囲）を把握する設計になっていません。

この課題に対し、CiscoやSplunkでインフラ自動化に携わってきた筆者は「レジリエンス予算」モデルを提唱しています。これはシステムの吸収容量を静的な閾値ではなく、SLOバーンレート、P99レイテンシの傾向、依存関係の飽和状態、アプリケーション行動シグナルの4種類のライブデータから連続的に再計算する消費可能なリソースとして扱う手法です。カオス実験もエージェント行動も同一の台帳で消費を管理し、複数チームや複数エージェントの行動が重複した際の想定外のブラストラジアスを防ぎます。

LLMを活用したカオス仮説の生成も試みられていますが、依存関係グラフの鮮度という根本的な限界があります。スタンフォード大学のTrustworthy AI Research Labの研究では、モデルレベルのガードレールだけでは安全性の確保が不十分であることが示されました。特にシグナルが曖昧な場合、保留中のデプロイやオンコール体制といった監視システムの外にある情報が判断に不可欠であり、人間への即時エスカレーションが構造的に必要です。

実務としてまず取り組むべきは、インフラに触れるすべての自律エージェントを監査し、その行動範囲をライブSLOバーンレートと照合することです。レジリエンス予算が定義した下限を下回る場合にはエージェントの行動を待機またはエスカレーションに切り替える明示的なルールの設定が求められます。多くの組織では、リスク管理の台帳から完全に外れたエージェントがすでに複数稼働しているとみられ、本番障害が先に発見する前に対処することが急務です。

Google Cloudの開発者がAPIキーを悪用され、数千ドルから1万ドル超の高額請求を受ける被害が相次いでいます。面接準備プラットフォームPrentusのCEOは約30分で1万138ドルを請求され、シドニーの開発者は約1万7000豪ドルの被害に遭いました。いずれもGoogle Maps向けに公開していたAPIキーが、Googleの仕様変更によりGeminiモデルへのアクセスにも使える状態になっていたことが原因です。

セキュリティ企業Aikidoの調査では、被害に気づいてAPIキーを即座に削除しても、Googleのインフラ全体に無効化が行き渡るまで最大23分間かかることが判明しました。その間、攻撃者は90%以上の成功率でリクエストを送り続け、ファイルやGeminiの会話データを窃取できる状態にあります。一方、Googleの新しいサービスアカウント認証情報は約5秒で無効化されるため、技術的には解決可能な問題だと研究者は指摘しています。

こうした状況のなか、Google CloudのCOOであるフランシス・デ・スーザ氏は、企業がAI導入を進めるにあたりセキュリティを最初から組み込むプラットフォームアプローチの重要性を訴えました。同氏は、従業員が組織の管理外で消費者向けAIツールを使う「シャドーAI」のリスクを警告し、セキュリティ・ガバナンス・監査可能性を最初から求めるべきだと主張しています。

デ・スーザ氏はまた、脅威の状況が根本的に変化していると強調しました。初期侵入から次の攻撃段階への移行時間は平均8時間から22秒にまで短縮されており、攻撃対象もネットワーク境界を大きく超えてモデルやデータパイプライン、エージェント、プロンプトにまで広がっています。同氏は機械の速度に機械の速度で対抗する「AIネイティブな完全エージェント型防御」の導入を提唱しました。

LinkedInのCISOであるリア・キスナー氏も、AIセキュリティを持続可能な形で理解するには数年かかるとの見方を示しています。プラットフォーム提供者自身が処方する対策と、自社の適応速度との間にギャップがある現状を認識することが、企業にとって重要な出発点となりそうです。

Amazonが2025年に買収したAIウェアラブル「Bee」の実機レビューをTechCrunchが公開しました。Beeは手首に装着する小型デバイスで、日常の会話を録音・文字起こし・要約する機能を持ち、カレンダーと連携してリマインダーを送ることもできます。業務用途では有望な一方、個人利用ではプライバシー面の懸念が指摘されています。

業務シーンでの評価は比較的良好です。記者がビジネス通話中にBeeを起動したところ、会話の要約が話題ごとに整理され、後から確認する際に便利だったといいます。会議が多い人が終日録音し、後で要約を見返すという使い方が想定されます。ただし文字起こしの精度には課題があり、話者の名前は手動入力が必要で、一部の会話が省略されるケースも確認されました。

個人利用については慎重な見方が示されています。Beeが十分に機能するには、位置情報・写真・連絡先・カレンダー・通知など広範なスマートフォン権限が必要です。健康データの共有も可能で、収集されたデータはクラウドに保存されます。プライバシーを重視するユーザーにとって、生活のあらゆる場面を記録されることへの抵抗感は大きいでしょう。

セキュリティ面では、Beeは保存時・転送時の暗号化や第三者監査を実施していると説明しています。しかしAmazon自体が過去にデータセキュリティの問題を経験しており、クラウド保存というアーキテクチャへの不安は残ります。YouTuberへのデモでは完全ローカル処理の試作版が紹介されましたが、Amazonから製品化の具体的な計画は発表されていません。

総じてBeeは、業務補助ツールとしては一定の実用性を備えつつあるものの、OtterやGranolaといった既存の文字起こしサービスとの明確な差別化が課題です。個人利用向けの製品として広く受け入れられるには、データ保存方式の見直しや権限要求の最小化など、プライバシー対策の強化が求められます。

サンフランシスコのテンダーロイン地区に拠点を置く非営利団体Project Open Handが、食品ロボティクス企業Chef Roboticsの盛り付けロボットを導入しました。Project Open Handは1985年にHIV危機への対応として設立され、心臓病や糖尿病など個別の医療ニーズに合わせた食事を無償で提供しています。コロナ禍以降、企業ボランティアが大幅に減少し、食事の組み立て作業の担い手確保が課題となっていました。

Chef Roboticsのロボットは調理や下ごしらえではなく、盛り付け作業に特化したAIロボットです。約70種類の食材に対応するアタッチメントを備え、ポテトサラダやコーンなどをトレーの所定位置に分配します。CEOのRajat Bhageria氏は「食品は粘りがあり、柔らかく、濡れている。最良のシミュレーションでも完全には再現できない」と食品特有の難しさを語ります。

現場では2台のロボットアームがコンベアライン上で1日数時間稼働しています。人手だけで時間あたり約500食だった生産能力に、ロボットが約200食を上乗せしました。ボランティアはより付加価値の高い野菜のカットや調理といった作業に回ることができます。盛り付けの正確さはまだ完璧ではなく、こぼれた食材を拭き取る人間の補助は必要ですが、「人間より汚いわけではない」と現場スタッフは評価しています。

この提携はBay Area Rapid Transit車内での両組織の従業員同士の偶然の会話がきっかけでした。Project Open HandのCEO Paul Hepfer氏はサブスクリプション方式でロボットをレンタルし、「非営利は欠乏のマインドセットで運営しがちだが、それでは革新や品質向上を見逃す」と語ります。テック企業やAI企業が集まるサンフランシスコにおいて、非営利団体が先端技術を活用する姿勢を示すことで、新たなボランティアや支援を呼び込む狙いもあります。