AIエージェントにファイルの編集やメールの送信を任せる会社が増えてきました。
任せる範囲が広がるほど、「エージェントが想定外の動きをしたら、どこで止まるのか」という問いが避けられなくなります。
NVIDIAが2026年9月28日に発表した「Open Agent Safety Platform」は、この問いに対する1つの答えです。
エージェントの中身を賢くして事故を防ぐ発想とは別に、エージェントの外側に「ここから先は通さない」という境界を置く仕組みです。
この記事では、公式発表と製品ページ、ソフトウェアの公開資料をもとに、部品の役割、ポリシーで決められること、対応する環境を整理します。
後半では、NVIDIAの機材を持っていない会社でも今日から始められる「エージェントの権限の棚卸し」を、表にまとめました。
Open Agent Safety Platformとは
Open Agent Safety Platformは、AIエージェントを試験の段階から本番の運用まで見張り、決められた範囲から出さないためのソフトウェアと設計図の組み合わせです。
NVIDIAは製品ページで、このプラットフォームを「AIエージェントの周りに境界を強制する、公開されていて自由に作り変えられる道具」と説明しています（英語の原文を訳したもの。以下の引用も同じ）。
ここで言う境界は、エージェントが読めるファイル、つなげる宛先、使える認証情報の範囲を指します。
発表の日付と位置づけ
発表はNVIDIAの投資家向けページに掲載されたプレスリリースで、日付は2026年9月28日です。
プレスリリースは、ソフトウェア、ハードウェア、計算基盤、ロボットまでを対象にした「エージェントの統治」の基盤として位置づけています。
創業者でCEOのジェンスン・フアン氏は、発表の中で次のように述べています。
「AIが社会にもたらす並外れた可能性は、AIの安全の問題を解いてはじめて実現する」
同じコメントの中で、フアン氏は「安全と防御には、全体を通した設計が要る」とも話しています。
ソフトからハードまでを1つの設計として守る、という立場がこのプラットフォームの出発点です。
2つの部品 OpenShellとSentry
プラットフォームは、オープンソースのソフトウェア「OpenShell」と、設計図として公開された「NVIDIA Sentry」の2つでできています。
OpenShellはエージェントを動かす土台で、エージェントが何を見て、何をして、どこにつながるかをポリシーで縛ります。
Sentryは、エージェントが動いているコンピューターとは別の処理装置から、エージェントの動きを見張る役です。
2つは役割が違うため、OpenShellだけを使うこともできます。
| 部品 | 何をするか | どこで動くか | いま使えるか |
|---|---|---|---|
| OpenShell | エージェントを隔離した箱の中で動かし、ファイル・通信・認証情報をポリシーで制限する | 手元のパソコン、社内サーバー、クラウド、Kubernetes。NVIDIAのVera CPUに最適化 | 公開済み。GitHubで入手でき、ライセンスはApache 2.0 |
| NVIDIA Sentry | エージェントとは別の装置から動きを監視し、範囲の外に出たら隔離する | BlueField-4 DPUを積んだシステム | 設計図（リファレンス設計）として公開。提供時期の記載なし |
| Vera CPU | エージェントの計画、道具の実行、隔離した箱の処理を受け持つ | NVIDIAのデータセンター向け機材 | NVIDIAの機材として提供 |
| BlueField-4 DPU | Sentryの監視と、通信経路上でのポリシーの適用を受け持つ | サーバーに載せる専用の処理装置 | NVIDIAの機材として提供 |
なぜ「エージェントの外側」に安全装置を置くのか
プレスリリースは発表の背景を「最近のセキュリティ事故によって、公開されていて自社に合わせて作り変えられる道具を組織に持たせる必要がはっきりした」と説明しています。
プレスリリースによると、これらの事故には共通の型がありました。
エージェントが、与えられた仕事を終わらせるために、アプリケーションの層に置かれた制御をすり抜けたのです。
モデルの安全策が届かない場面
エージェントに「この操作はしないでください」と指示しても、その指示を読むのはエージェント自身です。
指示を誤解したり、外から紛れ込んだ文章に指示を書き換えられたりすれば、エージェントは自分で決まりを破れてしまいます。
NVIDIAの製品ページのよくある質問は、この違いを次の1文で整理しています。
「プロンプト、モデルの安全策、エージェントの枠組みは、エージェントが何をしようとするかに影響する。実行時の制御は、何をしてよいかを強制する」
前の3つは傾向を変えるだけで、最後の線を引くのは実行時の制御だ、という整理です。
実行時の制御が決めること
プレスリリースは、企業に必要なものを「モデルとエージェントの枠組みの外にある、強制力のある境界」と表現しています。
外側の境界は、エージェントがどれだけ賢くても、どれだけ誤解しても、同じ判定を返します。
だからこそ、エージェントの判断に頼らずに済むのが外側に置く利点です。
| 対策の種類 | 何に効くか | 破られたときに起きること | 次にすること |
|---|---|---|---|
| プロンプトでの指示 | エージェントが選ぶ行動の傾向 | 指示の誤解や書き換えで、禁止した操作が実行される | 指示は残しつつ、守らせたい決まりを外側の制御にも書く |
| モデルの安全策 | 危険な依頼への応じ方 | 業務として自然に見える操作は止まらない | 業務の操作ごとに、許す範囲を別に決める |
| エージェントの枠組みの設定 | 使える道具の一覧 | 道具の中でできることが広すぎると、範囲を越える | 道具ごとに読み取りと書き込みを分ける |
| 実行時の制御 | ファイル・通信・認証情報への実際の到達 | ホスト自体が乗っ取られると効かない場合がある | 重要な環境では、ホストと別の装置からの監視を足す |
| 独立した監視（Sentry） | ホストが侵害されたあとの動き | 専用の機材が無い環境では使えない | 導入の要否を、扱うデータの重さで決める |
OpenShellの仕組み
OpenShellのGitHubの説明は、目的をこう書いています。
「OpenShellは、エージェントにその能力を与えつつ、データや秘密の情報、ネットワークへの無制限の到達は与えない」
ここで言う能力は、ファイルの読み書き、パッケージの導入、外部の窓口の呼び出し、認証情報の利用を指します。
そのために、各エージェントが触れてよいものを利用者がポリシーに書き、OpenShellがそれを強制します。
サンドボックスとカーネルでの制限
エージェントは、1体ずつ隔離された箱（サンドボックス）の中で動きます。
箱の中から読めるファイルや使えるシステムの呼び出しは、OSの中核であるカーネルの機能で制限されます。
ネットワークの接続は、箱から出る前にすべてポリシーの判定を通ります。
エージェントが自分の設定を書き換えても、カーネルと通信の出口で止まる作りです。
本物の認証情報をエージェントに見せない
説明書きには「エージェントが本物の認証情報を目にすることはない」とあります。
OpenShellは、許可された宛先へ向かう通信にだけ、あとから認証情報を付け足します。
そのため、エージェントが鍵を外部に書き出そうとしても、手元に本物が無いので漏れようがありません。
ポリシーの変更を形式検証で確かめる
エージェントの仕事が進むと、新しい宛先への接続が必要になることがあります。
OpenShellは、ポリシーを変える前に、その変更で新しく何が許されるかを数学的な手法（形式検証）で調べます。
認証情報を持って新しい宛先につなぐ変更や、新しい操作の呼び出しを許す変更は、人の確認を待つ扱いになります。
製品ページのよくある質問によると、許可と拒否の判定はすべて記録に残り、記録は1か所に集めて監査できます。
ポリシーファイルで決められること
OpenShellの公式ドキュメント（2026年10月時点の最新版はv0.1.5）によると、ポリシーはYAMLという書式の設定ファイルです。
ファイルには「version: 1」を書き、そのほかに最大5つの項目を置きます。
| 項目 | 決めること | 誰が強制するか | 効き始める時点 |
|---|---|---|---|
| filesystem_policy | 読めるだけの場所と、読み書きできる場所 | カーネルのLandlock | サンドボックスの起動時 |
| landlock | ファイルの制限をかけられなかったときに、起動を続けるかどうか | サンドボックスの実行環境 | サンドボックスの起動時 |
| process | 箱の中の処理をどの利用者とグループで動かすか | DockerやPodman | サンドボックスの作成時 |
| network_policies | プログラムごとにつないでよい宛先と、送ってよい要求 | サンドボックスの通信の中継役 | 動いている間ずっと |
| network_middlewares | 許可された通信の追加の検査、書き換え、遮断 | サンドボックスの通信の中継役 | 動いている間ずっと |
既定は「全部拒否」
ドキュメントは「OpenShellは、ポリシーが許していないものをすべて拒否する」と書いています。
外への接続も同じで、network_policiesのどれかの規則が許さない限り、箱から外へは1件もつながりません。
規則は宛先とプログラムの組で書き、たとえば「この外部の窓口は読むだけ、書き込みは不可」という細かさまで指定できます。
起動時に固まる設定と動きながら変えられる設定
ファイル、Landlock、処理の利用者の3つは、サンドボックスが起動した時点で固まります。
通信の規則と追加の検査は、動いている間に変えられます。
この分け方は、運用で困らないための工夫です。
ファイルの範囲は最初に狭く決めて動かさず、通信は仕事に合わせて人の確認を挟みながら広げる、という使い方になります。
ポリシーの出どころには優先順位があり、管理者が全サンドボックスに当てる全体のポリシーが最も強く効きます。
NVIDIA Sentryの役割
OpenShellは強力ですが、エージェントと同じコンピューターの上で動きます。
そのコンピューター自体が乗っ取られた場合に備えるのが、Sentryです。
ホストから独立した見張り役
Sentryは、BlueField-4というサーバーに載せる専用の処理装置（DPU）の上で動きます。
製品ページは、Sentryが見張る場所を「ハードウェアで切り離され、ホストに依存しない安全な区画」と説明しています。
エージェントやホストが出す記録に頼らずに異常を見つけるので、ホスト側の記録が改ざんされても判断がぶれません。
ミリ秒単位の隔離
プレスリリースは「AIエージェントがソフトウェアの境界の外へ出ようとすると、Sentryがミリ秒のうちに隔離して止める」と書いています。
1ミリ秒は1,000分の1秒です。
OpenShellとSentryの関係を図にすると、次のようになります。
図の金色の箱が、エージェントの外側に置かれた境界です。
下の黒い箱は、その境界ごと見張る2段目の守りにあたります。
対応する環境とエージェント
GitHubの説明によると、OpenShellを動かすには次の環境が必要です。
| 手元の環境 | いま使えるか | 次にすること |
|---|---|---|
| Linux | 対応 | DockerかPodman、またはホストの仮想化を用意する |
| Apple SiliconのmacOS | 対応 | Dockerなどの実行環境を入れてから導入する |
| WindowsのWSL 2 | 試験的な対応 | 本番の前に、手元で動作を確かめる |
| Kubernetes | 対応（Helmで導入） | ネットワークの制御（NetworkPolicy）を強制できる構成か確かめる |
| BlueField-4を積んだサーバー | Sentryまで使える | 扱うデータの重さに見合うか、費用対効果を社内で検討する |
BlueField-4が無くても使える
製品ページのよくある質問は、「OpenShellにBlueField-4は必要か」という問いに「いいえ」と答えています。
OpenShellは、手元のパソコン、社内サーバー、クラウド、Kubernetesのどれでも、BlueField-4なしで動きます。
BlueField-4がある環境では、そこにSentryが加わり、ホストが侵害されても止まらない監視が足される、という説明です。
プレスリリースは、OpenShellがArmやIntelといった他社の計算基盤にも広げられると書いています。
対応するエージェント
製品ページによると、OpenShellはClaude Code、Codex、OpenCode、GitHub Copilot CLI、OpenClawといったエージェントに対応しています。
自社で作ったエージェントや、独自の箱の中身（イメージ）を持ち込むこともできます。
公開されたモデルにも、公開されていないモデルにも、同じ実行時のポリシーをかけられるのが特徴です。
普段使っているエージェントを替えずに、外側の境界だけを足せるので、試すときの手間が小さく済みます。
試すときの手順
導入の手順は、GitHubの説明に沿うと4段階です。
| 段階 | やること | 確かめること |
|---|---|---|
| 1. 準備 | DockerかPodmanを入れる | 使っているOSが対応表に入っているか |
| 2. 導入 | 公式の導入スクリプトを実行し、コマンドと手元の中継役（ゲートウェイ）を入れる | スクリプトの入手元がNVIDIAの公式リポジトリか |
| 3. 最初の箱 | 名前を付けてサンドボックスを作る | 既定の箱は最小限のUbuntuで、エージェントは入っていないこと |
| 4. エージェントを動かす | 公式の手引き（最初のエージェントを動かす手順）に沿って動かす | 新しい接続を求められたときに、人が承認する流れになっているか |
| 5. ポリシーを書く | 公式の手引き（最初の通信ポリシーを書く手順）で通信の規則を書く | 許可していない宛先が拒否され、記録に残るか |
導入と最初のサンドボックス
公式の手順では、導入スクリプトを実行したあと、「openshell sandbox create –name demo」で最初の箱を作ります。
導入スクリプトは、コマンドと手元の中継役（ゲートウェイ）をまとめて入れます。
最初の箱にはエージェントが入っていないので、手引きに沿って無料のモデルでOpenCodeを動かし、承認の流れを体験するのが近道です。
エージェント用のスキル
GitHubには、コーディング用のエージェントにOpenShellの扱い方を教えるスキルも公開されています。
スキルを入れると、エージェントがOpenShellのコマンドを操作したり、サンドボックスのポリシーを書いたり、中継役の不具合を調べたりできるようになります。
ポリシーをエージェントに下書きさせる場合も、最終的に承認するのは人です。
匿名の利用統計を止める
OpenShellは、動作の種類と回数に限った匿名の利用統計を集めます。
説明によると、サンドボックスの名前、ホスト名、ファイルの場所、プロンプト、認証情報、モデル名、利用者の内容は集めません。
社内の決まりで外部送信を止めたい場合は、中継役で「OPENSHELL_TELEMETRY_ENABLED=false」を設定すれば止められます。
参加企業と業界の動き
プレスリリースによると、プラットフォームの技術に取り組む組織は100を超えます。
名前が挙がっているのは、Anthropic、Microsoft、SAP、Salesforce、Hugging Faceなど、AIとソフトウェアの主要な企業です。
金融、エネルギー、ロボット、クラウドの各分野からも参加があり、対象が業務システム全体に広がっていることが分かります。
エージェントを提供する側のコメント
Anthropicの最高商務責任者ポール・スミス氏は、発表に寄せて「Claude Managed Agentsは、それぞれのエージェントが何をしているかを企業がはっきり見られるようにする。NVIDIAのプラットフォームは、そこに統治の層をもう1枚足す」と述べています。
エージェントを作る側と外側で守る側が、役割を分けて重ねる構図です。
Open Secure AI Alliance
プレスリリースは、NVIDIAが120を超える組織とともに「Open Secure AI Alliance」を始めたと書いています。
この団体の運営は、Linuxなどのオープンソースを支える非営利団体のLinux Foundationが担います。
フアン氏のコメントにある「評価の方法をそろえ、国際的な協力を育てる」という狙いは、この団体の活動を指しています。
10月21日に出た設計図
NVIDIAは2026年10月21日、ドイツのGTC Berlinにあわせて「NVIDIA OpenShell Reference Architecture」を発表しました。
製品ページは、これをOpenShell、Vera CPU、Vera Rubinのシステム、BlueField-4上のSentryを組み合わせた、全体の設計図として紹介しています。
データセンター、社内の基盤、端末に近い現場まで、同じ考え方で安全なエージェントを動かすための参考図です。
自社のエージェントに当てはめる権限の棚卸し
Open Agent Safety Platformの考え方は、NVIDIAの機材を持っていない会社にもそのまま使えます。
中心にあるのは、情報セキュリティで昔から言われてきた「最小権限」の考え方です。
最小権限の原則
アメリカ国立標準技術研究所（NIST）の用語集は、最小権限を次のように定義しています。
「システムは、利用者（または利用者の代わりに動く処理）の権限を、与えられた仕事を果たすのに必要な最小限に制限すべきだ、という安全の原則」
出典はNISTの文書SP 800-12の改訂1版です。
「利用者の代わりに動く処理」は、まさにAIエージェントのことです。
OWASPの「過剰な権限」
Webの安全を扱う国際的な団体OWASPは、生成AIの危険をまとめた2025年版の一覧で「行き過ぎた主体性」を6番目に挙げています。
原因は「過剰な機能」「過剰な権限」「過剰な自律」の3つです。
道具が多すぎる、権限が広すぎる、人の確認なしに動ける範囲が大きすぎる、という状態を指します。
対策として、OWASPは「人が介在する仕組みを使い、影響の大きい操作は実行の前に人の承認を必須にする」と書いています。
| 自社のエージェントの使い方 | いま起きがちなこと | 次にすること |
|---|---|---|
| 文章の下書きや調べものだけ | メールやファイルの書き込み権限まで付いたままになっている | 読むだけの権限に切り替え、書き込みを外す |
| 社内のファイルを整理させている | 全社の共有フォルダに到達できる | 作業用のフォルダ1つに範囲を絞る |
| メールや予約を代わりに送らせている | 送信が人の確認なしで終わる | 送信の直前に人が承認する手順を入れる |
| 外部のサービスとつないでいる | どの宛先につながるかを誰も把握していない | つなぐ先を一覧にし、許す宛先だけを残す |
| 開発でコードを書かせている | 本番の鍵が作業環境に置いてある | 本番の鍵を作業環境から外し、別の経路で渡す |
| 複数のエージェントを並べて使っている | どれが何をしたか記録が残っていない | 許可と拒否の記録を1か所に集める |
棚卸しは3つの問いで足りる
難しく考える必要はありません。
エージェントごとに「何を読めるか」「何を書き換えられるか」「どこに送れるか」を書き出すだけで、絞るべき場所が見えてきます。
書き出した結果、読めれば足りる仕事に書き込みの権限が付いていたら、そこが最初に直す場所です。
Claude Codeで今日からできる絞り方
エージェントの代表例として、Claude Codeでの絞り方を見ておきます。
Anthropicの公式ドキュメントによると、手動モードのClaude Codeは読み取りだけの権限で始まります。
ドキュメントには「Claude Codeは読み取りだけの権限で始まる」と書かれています。
ファイルの編集やコマンドの実行が必要になると、そのたびに利用者へ確認を求めます。
手動モードと自動モード
対話型の端末やVS Codeでは、自動モードが最初の権限モードになっています。
自動モードでは、別の判定用のモデルが利用者の代わりに操作を確かめ、危険と判断したものを止めます。
自動モードでも、利用者や組織が書いた「確認する」「拒否する」の規則はそのまま効きます。
組織の管理者は、自動モードそのものを止めることもできます。
拒否ルールとサンドボックス
Claude Codeの設定には、特定の操作を禁じる拒否の規則（permissions.deny）を書けます。
ドキュメントは、拒否の規則が「書かれたとおりのコマンド」に一致したときに効くと注意しています。
コマンドの書き方に左右されない通信の制限が必要なら、サンドボックスの機能でファイルと通信を隔離します。
この考え方は、OpenShellの「外側の境界」と同じ向きです。
| Claude Codeの機能 | 何を絞れるか | 次にすること |
|---|---|---|
| 手動モード | 編集や実行の前に毎回確認が入る | 大事な作業の場所では手動モードで始める |
| 自動モード | 判定用のモデルが危険な操作を止める | 拒否したい操作は別に規則として書いておく |
| 拒否の規則 | 決めたコマンドや道具を使わせない | 外部への送信や削除のコマンドから書く |
| サンドボックス | コマンドのファイルと通信を隔離する | /sandboxで作業してよい範囲を決める |
| /permissions | いまの権限の設定を一覧で確かめる | 月に1回、許可の一覧を見直す |
エージェントに作業の前提を伝える説明書については、AGENTS.mdの書き方と読まれる条件の記事で詳しく扱っています。
説明書で「やってほしいこと」を伝え、権限の設定で「やってはいけないこと」を止める、という2段で考えると整理しやすくなります。
導入を急がなくてよい会社、急いだほうがよい会社
Open Agent Safety Platformは、データセンター規模でエージェントを動かす企業を主な対象にした仕組みです。
すべての会社が、いますぐOpenShellやSentryを入れる必要はありません。
| 会社の状況 | いま起きていること | 次にすること |
|---|---|---|
| チャットで質問するだけ | エージェントに操作を任せていない | 導入は不要。任せ始める前に権限の決まりを作る |
| 1人か2人がClaude Codeなどを使う | 手元のパソコンで作業させている | ツール側の権限設定とサンドボックスで十分。OpenShellは試す程度 |
| 社内の業務をエージェントに任せ始めた | 共有フォルダやメールに到達できる | 権限の棚卸しを先に行い、OpenShellの試用を検討する |
| 顧客の個人情報や決済に触れる | 事故が起きたときの影響が大きい | 外側の境界を必須にし、記録を監査できる形にする |
| 多数のエージェントを自社の基盤で動かす | 人の目で動きを追い切れない | OpenShellの本格導入とSentryの要否を検討する |
小さな会社にとって大事なのは、道具を入れることより、エージェントに渡している権限を言葉にできる状態にすることです。
注意点と分かっていないこと
発表から1か月ほどの時点で、公式資料からは読み取れないこともあります。
Sentryの提供時期
プレスリリースは、OpenShellを「すでに広く利用できる」と書いています。
一方で、Sentryは設計図（リファレンス設計）という扱いで、製品として手に入る時期は書かれていません。
Sentryを前提にした計画を立てる場合は、機材を扱う販売店に提供の時期を確かめてください。
「防げた」という主張の扱い
報道の中には、過去のエージェントの事故がこの仕組みで防げた可能性がある、というNVIDIA側の説明を伝えるものがあります。
これはNVIDIAの見解で、第三者が検証した結果ではありません。
導入を判断するときは、自社の環境で拒否と記録が期待どおりに動くかを、試験で確かめるのが確実です。
Vera CPUの性能の数字
製品ページには、Vera CPUが従来のCPUの基盤に比べてサンドボックスの処理を最大80%速くする、という記載があります。
これはNVIDIAが示した最大値で、どの条件で測ったかは製品ページからは分かりません。
手元の機材でOpenShellを使う場合は、この数字は当てはまらない前提で考えてください。
よくある質問
Open Agent Safety Platformは無料で使えますか
OpenShellはApache 2.0というライセンスのオープンソースで、GitHubから入手できます。
Sentryを使うには、BlueField-4を積んだシステムが必要です。
OpenShellはどのOSで動きますか
Linux、Apple SiliconのmacOS、WindowsのWSL 2（試験的）で動きます。
どの環境でも、DockerかPodman、またはホストの仮想化が必要です。
いま使っているClaude CodeやCodexはそのまま使えますか
製品ページによると、Claude Code、Codex、OpenCode、GitHub Copilot CLI、OpenClawに対応しています。
自社で作ったエージェントを持ち込むこともできます。
モデルの安全策があれば、外側の制御は要らないのではありませんか
NVIDIAは、モデルの安全策は「エージェントが何をしようとするか」に影響するもので、「何をしてよいか」を強制するのは実行時の制御だと説明しています。
両方を重ねるのが、公式の考え方です。
エージェントが新しい宛先につなぎたいときはどうなりますか
エージェントはポリシーの変更を求めることができます。
認証情報を持って新しい宛先につなぐような危険な変更は、形式検証で見つけられ、人の確認を待つ扱いになります。
まとめ
Open Agent Safety Platformは、AIエージェントの外側に強制力のある境界を置く、NVIDIAの仕組みです。
中身はオープンソースのOpenShellと、別の装置から見張るSentryの2つで、OpenShellはNVIDIAの機材が無くても使えます。
OpenShellはポリシーで許していないものをすべて拒否し、本物の認証情報をエージェントに見せません。
ポリシーの危険な変更は、形式検証で見つけて人の確認に回します。
この考え方の芯は、NISTが定義する最小権限と、OWASPが警告する過剰な権限の話につながっています。
まずは自社のエージェントが「何を読めて、何を書き換えられて、どこに送れるか」を書き出すところから始めてください。
今日できる点検
最後に、道具を入れる前でもできる点検を表にまとめます。
| 点検すること | 見る場所 | 引っかかったら |
|---|---|---|
| 使っているエージェントの一覧 | 社内で使っているAIツールと、つないでいるサービス | 担当者と用途を1行ずつ書き足す |
| 読むだけで足りる仕事に書き込み権限が無いか | 各ツールの接続設定と権限の画面 | 書き込みを外し、読み取りだけにする |
| 送信や削除に人の確認が入るか | メール送信、ファイル削除、外部への投稿の設定 | 実行前の承認を必須にする |
| つながる宛先を把握しているか | 連携しているサービスの一覧と、Claude Codeなどの許可の一覧 | 使っていない連携を外し、残す宛先を決める |
| 本番の鍵が作業環境に置かれていないか | 作業フォルダの設定ファイルと環境変数 | 鍵を外し、必要なときだけ別の経路で渡す |
| 何をしたかの記録が残るか | 各ツールの操作履歴と監査の記録 | 記録を残す設定に変え、月に1回見直す |
