AI LAB

Insights and Innovations

Sus8システム
2026/10/27
AIエージェントの自律性を高める「ガードレール設計」――Dellが示すセキュリティと事業継続の接点
自律性を止めるのではなく、安全に広げる設計
AIエージェントに業務を任せるとき、企業が直面するのは「使うか、使わないか」という二者択一ではありません。発注、顧客対応、システム運用などの一部を自動化しながら、どこまで単独で判断させ、どの場面で人の承認を求めるかを決める必要があります。権限を絞りすぎれば導入効果が薄れ、広げすぎれば誤操作や情報漏えいの影響が大きくなりかねません。

Dell Technologiesの社長兼最高セキュリティ責任者を務めるジョン・シモーネ氏は、AIエージェントの設計段階こそ、セキュリティとレジリエンスを組み込む好機だと説明しています。これから長期間使われる可能性のある仕組みである以上、運用開始後に制限を継ぎ足すより、設計時に権限や停止条件を定めるほうが整合性を保ちやすいという考え方です。

ここでいうガードレールは、AIの利用を一律に抑えるための障壁ではありません。失敗できない処理を特定し、アクセス可能な情報、実行できる操作、承認が必要な条件を明示する仕組みです。越えてはいけない境界が機械的に判定できれば、その内側ではエージェントに広い裁量を与えられます。シモーネ氏は、こうした統制を先に整えた企業ほど、状況を把握しながら自信を持ってリスクを取れるとみています。

SiliconANGLE Mediaの配信スタジオ「theCUBE」で行われた対談では、企業側が慎重になりすぎている可能性も指摘されました。求められるのは無制限な自動化ではなく、失敗の影響を限定できる範囲から自律性を広げる判断です。ガードレールをブレーキとしてだけ捉えず、業務を安全に前進させるための条件として扱うことが、議論の中心にあります。
災害復旧からサイバーレジリエンスへの重心移動
企業の事業継続対策は、かつて自然災害や停電によるデータセンター停止を想定した災害復旧が中心でした。バックアップを取得し、別拠点でシステムを再開する仕組みを準備しておけば、設備障害からの復旧経路を描けます。シモーネ氏によると、現在はデジタル基盤全体へ広がるサイバー攻撃を、より現実的なシナリオとして捉える必要があります。

AIエージェントの導入は、この事業継続の設計に新たな依存関係を加えます。人が手作業で行っていた判断や処理をソフトウェアへ移せば、エージェントの停止がそのまま業務停止につながるからです。エージェント本体が稼働していても、判断材料となるデータへアクセスできなければ仕事は進みません。モデル、データ、認証基盤、外部サービスのどこかが使えなくなるだけでも、処理全体が止まる可能性があります。

このため、復旧対象をサーバーやファイルだけに限定するのは十分ではありません。どのエージェントがどの業務を担い、どのデータとシステムに依存しているかを把握したうえで、停止時の代替手段まで考える必要があります。人が処理を引き継げるのか、限定機能で運転を続けられるのか、安全に停止して復旧を待つべきなのかによって、準備すべき内容は変わるでしょう。

サイバーレジリエンスは、攻撃をすべて防ぐという発想だけではなく、侵害や障害が起きても影響を封じ込め、信頼できる状態へ戻す能力を含みます。AIエージェントを業務基盤として扱うなら、可用性だけでなく、復旧したデータや判断履歴が正しいことも確認しなければなりません。導入部門とセキュリティ部門が別々に設計するのではなく、業務継続の観点から依存関係を共有する必要が生じています。
25社の調査に見る「境界付き自律」の現在地
theCUBE Researchのクリスタ・ケース氏が主導した調査では、企業のテクノロジーおよびセキュリティ責任者25人のうち、19人が自律型エージェントを本番環境で運用していました。ただし、高リスクの操作を人の承認なしで実行させている回答者はいませんでした。導入そのものは進んでいても、重大な結果を招く判断については人が最終責任を持つ段階にあることが分かります。

この結果は、あらゆる処理へ同じ承認フローを適用すべきだという意味ではありません。情報の検索や下書き作成と、送金、契約変更、顧客データの削除では、失敗した場合の影響が異なります。行動をリスク別に分類し、低リスクの範囲では自動実行を認め、影響の大きな操作では追加確認を求めるほうが、業務効率と統制を両立しやすくなります。

注目したいのは、人の承認だけに依存する組織より、範囲を限定した自律性を認める組織のほうが、復旧準備の面で良好な傾向を示した点です。これは自動化そのものが安全性を生むという因果関係を証明するものではありません。ただし、自律運用へ進むために権限、監視、停止、復旧を具体化した組織では、障害対応も併せて整備されやすいと考えられます。

人による承認にも限界があります。処理件数が増えれば、承認者が内容を十分に確認せず通過させる「形だけの統制」になる恐れがあるためです。承認を残すなら、金額、対象データ、操作の不可逆性など、確認すべき理由が明確な場面に絞る必要があります。境界の内側は自動化し、境界を越えるときだけ人へ引き渡す設計が、実務的な落としどころになるでしょう。
Dellが重視するID管理・ログ・追跡可能性
Dellは社内で利用する各AIエージェントに対し、厳格なID管理とアクセス制御を適用していると説明しています。エージェントを単なるソフトウェア機能ではなく、企業システムへアクセスする主体として扱う考え方です。誰の指示で動き、どの情報を参照でき、どの操作まで許可されるのかを識別できなければ、問題発生時に影響範囲を確定できません。

アクセス権は、業務上必要な範囲へ限定することが基本になります。顧客対応を支援するエージェントに、会計システムの変更権限まで与える理由はありません。また、情報の閲覧権限と更新権限を分ければ、同じエージェントでも操作に応じてリスクを調整できます。Dellが採用する具体的な権限設定や判定基準は明らかにされていませんが、エージェントごとにIDと権限を管理する方針は、既存のゼロトラストや最小権限の考え方とも整合します。

広範なログ取得と、判断・行動の追跡可能性も重視されています。最終的な操作結果だけでなく、どの入力やデータを基に処理が行われ、どのエージェントが何を実行したのかをたどれれば、誤動作の検証やインシデント調査に役立ちます。ログ自体が改ざんされたり、機密情報を過剰に記録したりする可能性もあるため、保存先へのアクセス制御や保管方針も必要になるでしょう。

明示的なルールで動作を制限する「決定論的なガードレール」は、生成AIの確率的な出力を補う役割を持ちます。たとえば、許可されていないシステムへの接続を拒否する処理や、所定の条件を満たさない操作を承認待ちにする仕組みです。AIに規則の解釈まで任せるのではなく、失敗できない境界を通常のソフトウェア制御で固定することで、エージェントの裁量と企業側の統制を分離できます。
インシデント演習が追いついていない現実
調査対象25人のうち、AIエージェントに関するインシデントシナリオをテストしていたのは4人だけでした。本番環境で自律型エージェントを運用しているとの回答が19人だったことを踏まえると、導入と演習の間には隔たりがあります。制御策を文書で定めていても、実際の障害や侵害時に機能するかどうかは、試してみなければ分かりません。

演習では、エージェントが利用できない場合だけでなく、判断に使うデータの信頼性が損なわれた場合も想定する必要があります。処理を停止する条件、権限を無効化する担当者、人間へ業務を戻す手順、復旧後に再開を許可する基準などを確認すれば、曖昧な責任分担を洗い出せます。複数のエージェントが連携する環境では、一つの停止や誤判断がどこまで波及するかも検証対象になるでしょう。

シモーネ氏は、攻撃者がAIを以前から利用している一方、まだ全面的な規模では展開していないとの見方を示しました。その状況は数年先ではなく、今後数四半期のうちに変化すると予想しています。これは同氏の見通しであり、発生時期が確定しているわけではありませんが、防御側が演習を後回しにできる時間は限られているという警告として受け取れます。

Dellはサイバーレジリエンス関連の取り組みを拡大し、OpenAI Group PBCが呼びかけるサイバー防御の共同活動にも参加しています。ただし、個々の企業が最初に確認すべきなのは、外部の脅威動向だけではありません。自社のエージェントが停止したときに何が止まり、誰が気づき、どの状態まで戻せば安全なのかを答えられるかどうかです。小規模な机上演習でも、設計書だけでは見つからない運用上の穴を把握する機会になります。
日本企業が着手すべきリスク区分と段階的な権限移譲
日本企業がAIエージェントを導入する際は、製品選定より先に「任せる業務」と「失敗した場合の影響」を対応付けることが出発点になります。情報収集、提案、外部への送信、データ変更、金銭や契約に関わる処理では、求められる統制が異なります。部門ごとに用途を列挙し、機密性、不可逆性、顧客への影響、法令や社内規程との関係からリスクを区分すれば、承認条件を説明しやすくなります。

初期段階では、エージェントに提案だけを作らせ、人が実行する方法が考えられます。判断精度や例外の傾向を把握できた業務は、金額や対象件数などの範囲を限定して自動実行へ移せます。権限を広げる際には、操作ログが取得できること、緊急停止が機能すること、異常を検知する担当者が決まっていることを確認すべきでしょう。実績のない段階で全権限を渡す必要はありません。

経営層への説明では、AIの精度だけを示しても十分な判断材料になりません。どの業務がエージェントへ依存しているか、停止時に許容できる時間はどの程度か、代替手段を使えるか、重大な操作を誰が承認するかといった事業上の問いへ置き換える必要があります。セキュリティ部門には利用を止める役割だけでなく、どの条件なら自動化を進められるかを示す役割も求められます。

運用開始後は、権限を固定したままにせず、業務変更やインシデントの結果に応じて見直します。使われなくなった権限を削除し、新しい外部サービスとの接続を審査し、ログから想定外の行動を確認する仕組みが必要です。人の承認が頻発しているなら、境界設定が厳しすぎるのか、エージェントに任せる業務自体が適切でないのかを検討できます。

着手時の具体的な一歩は、本番稼働中または導入予定のエージェントを一つ選び、「停止したら困る業務」「アクセス可能なデータ」「単独実行できる操作」「人へ戻す条件」を一枚に整理することです。その内容を業務、IT、セキュリティの担当者で確認すれば、不足しているガードレールと復旧手順が見えやすくなります。自律性を広げる判断は、その境界を実際に説明し、検証できる状態から始まります。
参考情報
Dell sees AI agent guardrails as a path to greater autonomy

この対談映像はDell Technologiesがスポンサーを務めています。SiliconANGLEは、Dellを含むスポンサーがtheCUBEおよびSiliconANGLEのコンテンツに対する編集権を持たないと開示しています。
AI LAB 一覧へ戻る