エージェント型AIが認可境界を越えてサイバーリスクを拡大
企業が自律システムに機密性の高いツールやデータへの幅広いアクセスを急ぐなか、Google Newsはエージェント型AIに関する厳しい警告を取り上げた。
Security Boulevardの見出しは、エージェント型AIをサイバーリスクの新たな最前線として位置づけている。根底にある懸念は、チャットボットのハルシネーションが再び問題になるというだけではない。エージェントは、不完全な出力をメール、ソフトウェア、クラウドサービス、業務記録にまたがる現実の行動へと変え得る。
これは、エンタープライズの導入担当者が向き合う論点を変える。争点はもはや、生産性と不完全な回答の比較ではない。確率的に動作するソフトウェアに認証情報、メモリ、実行権限を与えたときに生じる、有用な自律性とセキュリティリスクの均衡である。
NISTは現在、AIエージェントを、現実の環境に影響を与える計画立案と自律的行動を実行できるシステムと説明している。同機関のセキュリティに関する取り組みは、確立済みの統制と、自ら運用手順を選択できるソフトウェアとの間に広がる隔たりを示している。
そのため、セキュリティチームには難しい課題が課される。製品の魅力である自律性を損なわずに、エージェントを制約しなければならない。このトレードオフが、エージェント型AIが一般的なエンタープライズ基盤となるのか、それとも限定的なパイロット導入にとどまるのかを左右する。
Google Newsの警告が実際に変えること
重要な変化は、AIが誤り得ることではなく、その誤りが認可境界を越えられるようになったことにある。
従来のチャットボットは、人が評価するための文章を生成する。エージェントは目標を解釈し、計画を組み立て、ツールを呼び出し、結果を確認し、継続的な人の指示なしに処理を進められる。エージェントはワークフローの内部で能動的な参加者となる。
エージェントが受信トレイの閲覧、文書の取得、コードの変更、顧客記録の照会、外部メッセージの送信を行える場合、この違いは重要になる。不正確な回答は不便にすぎない。しかし、未承認のデータベース更新や認証情報の露出は、セキュリティインシデントになり得る。
NISTのエージェントに関する照会は、危険の大きく3つの源泉を示している。エージェントは敵対的なデータに遭遇し、汚染されたモデルに依存し、攻撃者による直接的な操作がなくても有害な行動を追求する可能性がある。
第1のカテゴリーには、間接的なプロンプトインジェクションが含まれる。攻撃者は、Webページ、メール、文書、サポートチケットなど、エージェントが後で読むコンテンツの中に指示を埋め込む。エージェントは、その信頼できないコンテンツをコマンドと誤認する可能性がある。
第2のカテゴリーは、侵害されたコンポーネントに関するものだ。エージェントはモデル、コネクター、ライブラリ、外部サービス、取得した情報に依存する。この連鎖のどこかに弱点があれば、エージェントの判断に影響を及ぼしたり、攻撃者のアクセスを拡大したりする可能性がある。
第3のカテゴリーはさらに難しい。指示に重要な制約が欠けているため、モデルが与えられた目標を安全でない方法で追求する場合がある。セキュリティ研究者はこれをしばしば仕様ゲームと呼ぶ。つまり、システムが文字どおりの目標を満たしながら、本来の目的には反する状態である。
こうしたリスクは、エージェント型AI以前にも、より限定的な形で存在していた。フィッシングメールは人を操作し、アプリケーションはサプライチェーン攻撃を受け、自動化スクリプトは高額なエラーを引き起こしてきた。エージェントは、言語を解釈し、動的に行動を選択するシステムの中で、こうした既知のリスクを組み合わせる。
この組み合わせにより、Google Newsの最新報道は新たな製品カテゴリーへの警告以上の意味を持つ。AI安全性と運用上のサイバーセキュリティの境界が消え始めたことを示している。
システムがモデルの予測どおりに正確に動作していても、企業のセキュリティポリシーに違反することはあり得る。失敗は、権限、ツール設計、コンテキスト、承認プロセス、あるいはタスクの定義に潜んでいる場合がある。
組織は、モデルがベンチマークに正しく回答したかどうかを確認するだけでは、この問題を解決できない。エージェント全体が何を見て、判断し、記憶し、変更できるのかを検証する必要がある。
セキュリティチームは未完成の統制モデルを承認するよう求められている
最高情報セキュリティ責任者は、導入需要が共通のエージェントセキュリティ標準を上回る速度で進むため、直ちに対応を迫られている。
事業部門は、エージェントを反復作業の圧縮手段と見ている。開発者は、リポジトリを調査し、テストを実行し、コード変更を準備できるシステムを求めている。営業・サポートチームは、コンテキストを収集し、顧客システムを更新できるエージェントを望んでいる。
統合を追加するたびに、有用性は高まる。同時に、信頼関係も1つ増える。広範に接続されたエージェントは、従来は人間の判断によって分離されていたシステム間の橋渡し役になり得る。
最初に圧力を受けるのはアイデンティティチームだ。従来のアクセス管理は、人または決定論的なアプリケーションが既知のリソースを要求することを前提としている。エージェントは実行中にリソースを選択し、計画を変更し、複数のサービスを順番に呼び出すことができる。
人間の認証情報を借用すると、説明責任はさらに悪化する。ログには従業員のIDが記録されても、実際には自律プロセスがその行動を選択した可能性がある。調査担当者は、人間の意図とエージェントの挙動を区別することに苦労する。
各エージェントに独立したアイデンティティを与えることは有効だが、アイデンティティだけで認可の問題は解決しない。組織は依然として、そのアイデンティティが利用できるツール、アクセス可能な記録、承認が必要となる場面を決めなければならない。
メモリも別の統制上の問題を生む。エージェントメモリは、複数のステップやセッションにわたり将来の判断に影響を与える、保存されたコンテキストである。悪意のある、あるいは不正確なコンテンツがそのメモリに入り込めば、元の対話が終わった後も影響が残る可能性がある。
通常のアプリケーションデータベースにも不正なデータは保存され得る。エージェントメモリには、モデルが保存されたテキストを証拠、背景情報、または指示として解釈する可能性があるという意味的な側面が加わる。この曖昧さは、検証とインシデント再構築を複雑にする。
組織は、エージェントの運用予算も保護する必要がある。攻撃者は長時間のループ、繰り返しのツール呼び出し、高額なモデルリクエストを引き起こす可能性がある。OWASPはこのリソース枯渇パターンを「denial of wallet」と表現している。
その結果、調達チームは統制モデルが固まる前に製品選定を迫られている。ベンダーは暗号化、監査ログ、エンタープライズ認証を説明するかもしれないが、エージェントが実質的に持つ権限は不明確なままの場合がある。
本質的な問いは運用上のものだ。エージェントは読み取りだけでなく書き込みもできるのか。未承認の宛先を呼び出せるのか。認可は1回の行動で失効するのか。取得したコンテンツが、エージェントによるツール選択を変えられるのか。
NISTが2026年5月に公表したセキュリティ対応分析では、エージェントが新たな脅威をもたらすという広範な合意が確認された。回答者は、既存のサイバーセキュリティ慣行も依然として有効だが、適応が必要だと述べている。
これは重要な留保である。エージェント型AIは、既存のセキュリティ対策を時代遅れにするわけではない。最小権限や職務分離を含む既知の原則を、どこで適用すべきかを変えるのである。
そのためセキュリティチームは、相反する2つの要求に圧迫されている。事業責任者は、自律性が効率を生むため、より広い自律性を求める。リスク責任者は、権限が潜在的な損害を決めるため、より狭い権限を必要とする。
どちらの側も、ポリシー文言だけでこの対立を解決することはできない。答えは、アーキテクチャ、ランタイム制御、承認フロー、そして各行動後に保持される証跡に現れなければならない。
有用な自律性と安全な権限は相反する方向に働く
エージェント型AIは、侵害されたエージェントを危険にするその権限を与えられるほど、高度な能力を持つようになる。
顧客サポートの問題解決を任されたエージェントを考えてみよう。顧客のメッセージを読み、アカウント履歴を確認し、社内ガイダンスを参照し、サブスクリプション設定を変更し、返信を送る必要があるかもしれない。
読み取り専用のエージェントでは、このワークフローを完了できない。完全な権限を持つエージェントであれば完了できるが、アカウント情報を露出させたり、誤った変更を適用したりすることもある。製品の有用性とリスクは、ともに高まる。
同じ緊張関係はソフトウェア開発にも現れる。テキストを提案するだけのコーディングエージェントは、高度なアシスタントに近い振る舞いをする。ファイルを編集し、コマンドを実行し、依存関係をインストールし、プルリクエストを作成するエージェントは、ソフトウェアサプライチェーンに影響を与え得る。
こうした環境では、間接的なプロンプトインジェクションが特に深刻になる。悪意のある指示は、issue、依存関係の説明、Webページ、ソースファイル、取得した文書に隠される可能性がある。エージェントは正当なタスクを進める過程で、それに遭遇するかもしれない。
入力フィルタリングは既知の攻撃パターンを除去できるが、自然言語には同等の表現があまりにも多く、単純なブラックリストでは対応できない。より安全なアプローチは、取得したコンテンツをデータとして扱い、認可をモデルの裁量の外に置くことだ。
OWASPのエージェントセキュリティガイダンスは、最小限のツールアクセス、ツールごとの権限スコープ、機密性の高い操作に対する明示的な認可を推奨している。また、信頼レベルに応じてツールを分離することも助言している。
これらの推奨事項は、成熟したアプリケーションセキュリティの原則を反映している。違いは、その適用方法にある。同じ操作と認可判断の両方が操作されたコンテキストの影響を受ける可能性があるため、モデル自身に自らの行動が認可されているかを決定させてはならない。
その判断は決定論的なポリシー層が行わなければならない。決定論的とは、検証済みの同じ入力から、常に同じ認可結果を出すルールを意味する。モデルは行動を提案できるが、モデルの外部にあるコードが承認または拒否しなければならない。
承認は正確なパラメータにも紐づける必要がある。あるメッセージを承認したからといって、後にエージェントが別のメッセージを送ることまで認可してはならない。1つのファイルへの承認が、ディレクトリ全体を暗黙に対象とするべきでもない。
ここで、多くの魅力的なデモは誤解を招くものになる。デモでは途切れない完了が評価される。安全な導入では、誤りが不可逆的、公開的、金銭的、あるいは調査困難なものになる地点で摩擦が必要となる。
人によるレビューも、自動的に十分とは言えない。特にインターフェースが重要なパラメータを隠している場合、レビュー担当者は頻繁な要求を承認することに慣らされる可能性がある。曖昧な確認ボタンは、監督を儀式へと変えてしまう。
より優れた設計では、行動を影響度で分類する。低リスクの取得は、厳格な境界の内側で自動的に進められる。より高リスクな書き込みには強力な検証を求め、財務、管理、または外部に可視化される行動には独立した承認を与える。
ツールの説明も攻撃対象領域の一部となる。エージェントは、開発者や外部サーバーが提供する自然言語の説明をもとに、部分的にツールを選択する。誤解を招く説明は、モデルを安全でない、あるいは偽装された機能へ誘導する可能性がある。
モデルとツールを接続するプロトコルは、利用可能な統合の数を増やす。相互運用性を向上させ得る一方で、新たなエンドポイントごとにアイデンティティ、来歴、認可、出力検証の問題が加わる。
エージェントは、自身がどのサービスに到達したかを把握しなければならない。セキュリティ層は、そのサービスを独立して検証しなければならない。説得力のある説明から正当性を推論するようモデルを信頼することは、フィッシングが人に有効である理由と同じ過ちを繰り返すことになる。
これが、Security Boulevardの警告の根底にある中心的なトレードオフである。企業は、完全な自律性を維持しながら、すべての高影響な判断を無害な提案へと縮小することはできない。導入を始める前に、どこで自律性を終わらせるかを決めなければならない。
その境界は、モデルの確信度ではなく、潜在的な損害を反映すべきです。流暢な説明が、行為を安全にするわけではありません。確信度スコアも、認可、検証、監査可能なポリシー判断に代わるものではありません。
プロンプトインジェクションは、エージェント型AIの攻撃対象領域の一部にすぎない
悪意あるプロンプトだけに焦点を当てると問題を過小評価することになります。エージェントはツール、メモリ、アイデンティティ、外部データを一つの実行時システムに統合するためです。
プロンプトインジェクションは依然として喫緊の脅威です。直接的なインジェクションはユーザーの要求を通じて到達します。間接的なインジェクションは、その要求を完了する過程でエージェントが取得する資料を通じて到達します。
この攻撃は、根本的な曖昧さを悪用できます。モデルは、システムルール、ユーザー指示、ツールの結果、取得した文書、過去のコンテキストをすべて言語として受け取ります。そのため、どのテキストに権限があるとみなすべきかを推論しなければなりません。
開発者は指示とデータの境界を強化できますが、その境界が数学的な隔離を生み出すわけではありません。エージェントは依然として、文書内にあるもっともらしい指示を自身の目標に関連するものとして扱う可能性があります。
ツールの悪用は、別の障害経路を生み出します。モデルが正当なツールを不正な目的で選択したり、安全でないパラメーターを渡したり、結果を誤解した後に操作を繰り返したりする可能性があります。
その後、権限昇格によって影響が拡大することがあります。広範な認証情報を持つエージェントは、当初のタスクに不要なデータや機能へ到達できるかもしれません。攻撃者はもはや、接続されたすべてのシステムを個別に侵害する必要がありません。
データ流出も別個のリスクです。機密コンテキストは、APIリクエスト、生成されたメッセージ、ログエントリ、デバッグトレース、ツールパラメーターを通じて外部へ流出する可能性があります。最終回答のフィルターでは、中間アクション中に発生する漏えいを見逃します。
メモリ汚染は、攻撃を時間軸にまたがって拡張します。あるタスク中に保存された悪意あるコンテンツが、後のタスクに影響を及ぼす可能性があり、別のユーザーに対するタスクであることもあり得ます。したがって、永続メモリには検証、隔離、有効期限、監査の統制が必要です。
マルチエージェントシステムでは、伝播リスクも加わります。侵害された一つのエージェントが、異なる権限を持つ別のエージェントへ指示や汚染されたコンテキストを送る可能性があります。後者のエージェントは、意図せず権限の橋渡し役になり得ます。
サプライチェーンへの露出も拡大します。企業のエージェントは、モデルプロバイダー、オーケストレーションフレームワーク、プラグイン、プロトコルサーバー、データソース、従来型ソフトウェアパッケージに依存する可能性があります。各コンポーネントには、独自の更新経路と侵害経路があります。
連鎖的な障害により、こうした弱点を個別に評価することは難しくなります。汚染された文書が計画エージェントの方向を変え、過剰な権限を持つツールを呼び出し、そのツールが別のエージェント向けに汚染されたメモリを書き込むことがあります。
単一のモデル出力だけでは、インシデント全体を捉えられません。調査担当者には、元の要求、取得した入力、モデルの判断、ツール呼び出し、ポリシーチェック、承認、結果、その後のメモリ書き込みを示すトレースが必要です。
この要件はプライバシー上のトレードオフを生みます。詳細なトレースはセキュリティチームによる行動の再構築に役立ちますが、ログには認証情報、個人情報、機密の事業データが含まれることがあります。可観測性には、最小化とマスキングも組み込まなければなりません。
パーソナルナレッジベースは、コンテキストシステムの機微性を示しています。保存された資料は関連性を高められますが、それでも各コンテキストを誰が受け取るべきかは、権限とデータ境界によって決まります。
企業はエージェントメモリにも同様の規律を求める必要があります。取得は、要求するアイデンティティ、現在の目的、承認済みのデータスコープを尊重すべきです。広範なコンテキストが回答品質を高めるという理由だけで、エージェントが利用可能なすべての文書を受け取るべきではありません。
最も安全なアーキテクチャは、信頼できないコンテンツが最終的にはモデルへ到達すると想定します。そのうえで、操作されたモデルが実行できることを制限します。この原則は、防御の焦点を完璧な検知から、影響の封じ込めへと移します。
サンドボックス化は、コードやツールを隔離された環境に置くことで役立ちます。エグレス制御は、その環境が接続できる外部宛先を制限します。短命な認証情報は、悪用に利用できる時間を短縮します。
組織は、計画と実行も分離すべきです。モデルは提案された手順を作成し、ポリシーエンジンは実行段階で各センシティブな操作を評価できます。先行する承認が、後の変更まで自動的にカバーすべきではありません。
最後に、実行時の制限では、再帰、再試行、時間、トークン、支出に上限を設けるべきです。これらの統制は、攻撃だけでなく偶発的なループにも対応します。エージェントがリソースを消費したり、損害を与える操作を繰り返したりするのに、悪意は必要ありません。
この結果として得られるアーキテクチャは、研究室でのデモほど滑らかではありません。しかし、重要な能力のすべてに、モデルがプロンプトに従うことに依存しない境界が設けられるため、より防御しやすくなります。
セキュリティフレームワークは役立つが、コンプライアンスは安全性の証明ではない
既存のフレームワークは不可欠な原則を提供しますが、あらゆるモデル、ツール、変化するコンテキストにおける安全な振る舞いを、チェックリストだけで保証することはできません。
懐疑的な見方は、測定から始まります。エージェントの振る舞いは、モデル、システム指示、利用可能なツール、取得コンテンツ、メモリ、周辺のアプリケーションロジックに依存します。一つのコンポーネントを変えるだけで、システムの障害モードは変化し得ます。
したがって、ローンチ前に実施したセキュリティ評価の有効期間は短いものです。モデルプロバイダーの更新によって、ツール選択が変わる可能性があります。新しいコネクターによって、当初の評価では想定されなかったデータ経路が生まれることもあります。
プロンプトの改訂も重要です。小さな指示変更がタスク完了率を改善する一方で、拒否行動を弱める可能性があります。新しいメモリソースは、エージェントの中核コードを変更せずに悪意あるコンテンツを持ち込む可能性があります。
これは、テストが無意味であることを意味しません。テストは、システムのライフサイクルを通じて実施されなければならないということです。OWASPは、プロンプト、ツール、メモリ、取得、ポリシー、モデルプロバイダーに重要な変更が加わった後、改めて敵対的検証を行うことを推奨しています。
テストでは具体的な悪用事例を再現すべきです。エージェントが不正なツールを拒否するか、承認の回避を防ぐか、メモリを隔離するか、データ漏えいを阻止するか、無制限のループを停止するかを問う必要があります。
そのうえで、リリースゲートは、センシティブな権限が対応する証拠なしに変更された場合のデプロイを防ぐことができます。過去の失敗は、従来のソフトウェアの不具合と同様に、回帰テストにすべきです。
課題は網羅性です。自然言語入力には膨大な変動があり、エージェントは未知のアクションシーケンスを組み立てられます。固定されたテストセットに合格したことは、既知のケースに対応できたことを示すにすぎず、別の場所でシステムが失敗しないことを意味しません。
レッドチームは創造的な攻撃を探索できますが、時間とアクセスの制約下でも活動しています。評価環境には、最大のリスクを生む本番データ、コネクター、権限が含まれていない場合があります。
ベンダーの主張にも同じ注意が必要です。ある企業は、自社のエージェントがログ記録、承認、暗号化をサポートすると正確に述べることができますが、重要な実装詳細を顧客側に委ねている場合があります。
セキュリティは、これらの統制がどのように組み合わさるかに左右されます。承認機能が不完全なパラメーターしか表示しないなら、その価値は限定的です。取得コンテンツや中間的なツール呼び出しを省く監査ログも、有用性が低下します。
コンプライアンス認証は、プロセス上の規律とベースライン統制を確立できます。しかし、確率的なエージェントが将来のすべてのコンテキストを安全に解釈することを証明することはできません。購入者は、認証を完全な答えではなく、一つの判断材料として扱うべきです。
NISTの調査結果は、この抑制的な見方を支持しています。回答者は、基礎的なサイバーセキュリティの実践が依然として適用されるという点で広く一致しましたが、実装ガイダンス、情報共有、標準の必要性も指摘しました。
AI Agent Initiativeは、相互運用性とアイデンティティと並べてセキュリティを位置付けています。この組み合わせは重要です。エージェントが組織と技術の境界を越えて動作する機会が増えているためです。
共有標準は、エージェントのアイデンティティと相互作用の検証を容易にできます。同時に接続性も高めるため、脆弱な認可がもたらす結果を拡大します。強制可能な信頼境界を伴わない相互運用性は、リスクをより速く広げかねません。
正しい結論は、エージェントが制御不能だということでも、既存の統制が問題を解決済みだということでもありません。セキュリティチームには実行可能な設計原則がありますが、本番デプロイメントから得られる証拠は依然として製品固有です。
購入者は、具体的なワークフローに結び付いた脅威モデルを要求すべきです。ベンダーには、信頼境界、認証情報のスコープ、保持されるメモリ、外部宛先、独立した承認を必要とするアクションを特定するよう求めるべきです。
また、モデル更新後に何が起きるかも尋ねるべきです。成熟した回答には、回帰テスト、段階的デプロイ、監視、ロールバック、変更された振る舞いの記録が含まれます。
未解決の問題は説明責任です。エージェントがユーザーの広範な目標に従いながら有害な手段を選択した場合、責任はユーザー、導入者、モデルプロバイダー、アプリケーションベンダー、ツール運営者にまたがります。
契約とポリシーは、その責任の一部を割り当てるでしょう。技術ログは、インシデント後にそれらの割り当てを証拠で裏付けられるかどうかを決定します。
その証拠が当たり前になるまでは、安全な自律性に関する広範な主張には精査が必要です。セキュリティは、エージェントが何を約束するかよりも、周辺システムがエージェントに何をさせないかに左右されます。
次の試金石は、統制が実際の業務で機能し続けるかどうかだ
エージェントセキュリティが運用段階に入っているかを示すシグナルは三つあります。制限された権限、再現可能なテスト、そして実用的なインシデント証拠です。
第一のシグナルは、狭くスコープされた短命の認証情報を持つ、エージェント固有のアイデンティティの採用です。これにより、企業が自律的なアクションを人間のセッションから分離できるという主張が強まります。
永続的な共有認証情報は、反対の方向を示します。これらは帰属の特定を難しくし、一つの侵害されたエージェントが従業員またはサービスアカウントの完全な権限を継承することを可能にします。
ベンダーが製品ドキュメントで権限をどのように説明しているかに注目してください。「ワークスペースへのアクセス」では広すぎます。購入者には、読み取り、提案、変更、公開、削除を区別する、リソースレベルおよびアクションレベルの統制が必要です。
第二のシグナルは、重要なエージェント変更のたびに敵対的テストが実行されているという証拠です。一度きりの評価では、新しいモデル、ツール、プロンプト、メモリソース、外部統合をカバーできません。
有用な証拠には、バージョン管理されたテストケース、想定される拒否、リリースゲート、公開された是正措置が含まれます。ベンダーは、どの変更が再テストの契機となるか、また変更された振る舞いについて顧客に通知するかどうかを説明すべきです。
ここでは、失敗に関する透明性も重要です。プロバイダーが意味のあるインシデント分析を公開し、その失敗を回帰スイートに追加するなら、管理された自律性への信頼は強まります。繰り返される非公開の変更は、その信頼を弱めます。
第三のシグナルは、組織がより多くの機密データを露出させることなく、エージェントのアクションを再構築できるかどうかです。インシデント対応者には、要求からツール実行、最終結果までの一貫した連鎖が必要です。
その連鎖には、実行したアイデンティティ、認可判断、正確なパラメーター、承認記録、宛先、返却データ、メモリへの影響を含めるべきです。ログには、モデルとポリシーのバージョンも保存すべきです。
セキュリティチームは、インシデントが発生する前に再構築をテストすべきです。統制された演習により、欠落したイベント、一貫しないタイムスタンプ、過剰なデータ保持、人に誤って帰属されたままのアクションを明らかにできます。
これらのシグナルは、また一つの印象的なエージェントデモよりも重要です。システムが敵対的なコンテンツや不完全な指示に遭遇したとき、自律性が強制可能な制限の中で動作できるかを測るものだからです。
Google Newsの見出しは、サイバーリスクにおける実際の変化を捉えています。しかし、未来は決まっていません。エージェント型AIが危険になるのは、独立した統制より速く権限が拡大するときです。
開発者は、すべての機密性の高いツール呼び出しを明示し、ポリシーに照らして検証することで対応できる。エンタープライズの購入担当者は、一般的な保証を受け入れるのではなく、実際のワークフローに結び付いた根拠を求めることができる。
ナレッジワーカーも、自身のIDのもとでエージェントがどのような操作を実行できるのかを理解すべきだ。ワークフローを委任する前に、エージェントが何を読み取り、変更し、記憶し、送信できるのかを確認する必要がある。
決定的な問いは実務的なものだ。エージェントの有益な計画が未承認の操作へと変わる、まさにその瞬間に、組織はそのエージェントを停止できるだろうか。答えが明確でないなら、権限は狭く保ち、人による承認を維持し、自律性の拡大はすべてセキュリティ上の変更として扱うべきである。
