【実機検証】NVIDIA OpenShell × Slack｜AIエージェントの外部通信を承認制に

投稿日： 2026.10.13
更新日： 2026.10.13

#Salesforce #Slack #NVIDIA OpenShell

AIエージェントの活用が広がるなか、課題になるのが「外部への通信」の管理です。NVIDIAは2026/9/28、AIエージェントの外部通信を「AIの外側」で止める実行環境OpenShellの安定版を発表しました。あわせて、許可の判断をSlackのボタンで行える連携も公開されています。
本記事では、Mac上でOpenShellを動かし、止められた通信がSlackに承認依頼として届き、Slack上のボタン操作で許可・却下できるところまで実際に確かめました。最新版0.1.2で試した結果と、つまずいたポイントもあわせて紹介します。
この記事で分かること

• AIエージェントの外部通信を、AIの外側にある仕組みで止める方法
• 止められた通信をSlackで承認・却下する流れ(実機の画面付き)
• 最新版0.1.2で試した結果と、導入時の注意点

こんな困りごと、ありませんか

AIエージェントに仕事を任せるほど、「どこに、何を送っているか分からない」不安が大きくなります。

 
よくある悩みは、次の3つです。

• 全部禁止すると、仕事にならない。調べものやデータ取得には、外部への接続が欠かせません。
• 全部許可すると、怖い。情報の持ち出しや、意図しない書き込みを防げません。
• 許可の判断が、エンジニアにしかできない。設定ファイルやコマンドでしか変えられないと、現場のリーダーが判断に加われません。

この記事では、こうした悩みに対して「外部への通信は最初はすべて止め、必要になったらSlackで人が判断して許可する」という形を、実際に動かして確かめました。

OpenShellとは:AIエージェント用の「安全な実行環境」。2026/9/28に安定版0.1.0とSlack連携が発表

OpenShell自体は2026年3月に、NVIDIAがAIエージェント向けのオープンソース実行環境として公開しています。2026/9/28には、より広い「NVIDIA Open Agent Safety Platform」の発表に合わせて、OpenShell 0.1.0が安定版として位置づけられ、Salesforce / Slackとの連携も発表されました。OpenShellはApache License 2.0で公開されています。
OpenShellは、AIエージェントを「サンドボックス」と呼ばれる箱の中で動かし、触ってよいファイル、通信してよい相手、使ってよい道具や認証情報を、あらかじめ決めたルール(ポリシー)で制限します。制限はAIモデルやエージェントの外側でかかります。OpenShellのサンドボックス内で動かせるエージェントであれば、CodexやClaude Codeなど、モデルやエージェントの提供元が異なっても同じポリシーで制御できます。
OpenShellはSlack専用の仕組みではありません。NVIDIAの開発者ブログでは、半導体設計のCadence、ロボティクスのGecko Robotics、そしてSlackなどが採用例として挙げられています。許可の変更も、OpenShell単体でコマンドから行えます。
そのうえで、SalesforceとNVIDIAは、許可の判断をSlackで行える連携も公開しました。エージェントが追加の権限を求めたときに、Slackで承認・却下できるというものです。この記事では、このSlack連携を試しています。

何が新しいのか

新しいのは、AIへの「お願い」ではなく、AIの外側にある仕組みで通信を止め、その判断をSlackで人が行える点です。

固定ルール／プロンプト中心	今回試したOpenShell × Slack
AIへの指示だけでは、実行環境側の強制力はない	AIの外側で通信を止め、未許可の通信は通さない
宛先だけの単純な制御では、操作内容までは分けにくい	対応プロトコルでは、プログラム・宛先・読み取り／書き込みを分けて制御
固定ルールの変更は、運用担当者の作業が必要	Slack承認後、ネットワークポリシーにホットリロード
承認の経緯は、別の仕組みで残す必要がある	承認者・日時(却下時は理由も)がSlackのカードに残る
設定ツールを扱える人が判断窓口になりやすい	Slack上で許可された管理者が判断できる

 
OpenShellはNVIDIAのオープンソース実行環境で、Slack側のつなぎ役「Slack Admin Bridge」はSlackが公開しているサンプル実装です。OpenShell自体にライセンス利用料はなく、サンプルコードもMITライセンスで公開されています。ただし、Slackの契約プラン、Docker Desktopの利用条件、実行基盤やAIモデルの利用料は別途確認が必要です。

全体像

OpenShellとSlack Admin Bridgeの構成

サンドボックスの中のプログラムが外部に出るときは、必ず関所(プロキシ)を通ります。関所はゲートウェイのポリシーで通すか止めるかを判定し、拒否した通信はゲートウェイに報告されます。
今回使用したサンプル構成では、ブリッジが3秒間隔(サンプルの既定値)でゲートウェイの新しい提案を確認し、Slackにカードを投稿します。Slackで承認されると、ブリッジがゲートウェイ経由でポリシーに反映し、関所の判定がその場で変わります。

実際に試してみた

Macの上にOpenShellの「サンドボックス」(AIやプログラムを閉じ込めて動かす箱)を作り、そこから外部へ通信させて、Slackで承認・却下するところまで試しました。コマンドの詳細は省略します。公式ドキュメントとリポジトリのREADMEは、参考リンクをご覧ください。
なお、Slackでの承認までの一連の流れは、OpenShell 0.0.113で確認しています。最新版の0.1.2でもサンドボックスは動かせましたが、Slackとのブリッジのサンプルが0.1.2で動かなかったためです(詳しくは「7-2. つまずいたポイント」を参照)。
検証環境(2026年10月上旬)

項目	バージョン
Mac / macOS	Mac(Apple Silicon)/ macOS 26.6.2
Docker Desktop	4.93.0(Docker 29.8.1)。0.1.2の確認では「Enable host networking」をオン
OpenShell	0.0.113(Slackの承認を確認)/ 0.1.2(サンドボックスとポリシーの確認)
Node.js	24.1.0
Slack Admin Bridge	GitHubのmain(2026年10月上旬時点)

 

まず、外への通信はすべて止まる

サンドボックスの中から、何も設定せずにGitHubへアクセスすると、関所に止められました(関所がHTTPステータスコード403を返しました)。ここから、必要なものだけを許可していきます。
許可の決め方は、思っていたより細かく分けられます。

試したこと	結果	分かったこと
何も許可せずにアクセス	止められた	最初はすべて拒否
宛先(GitHub)だけを許可	止められた	「どのプログラムに」許可するかの指定も必要
宛先とプログラムを指定し、読み取りだけを許可	読み取りは成功	宛先とプログラムの組み合わせで許可が決まる
同じ条件で書き込みをしようとした	止められた	読み取りはOK、書き込みはNGと分けられる

 

Slackアプリを用意する

Slack側には、承認依頼を届けるアプリを1つ追加します。ボットとして求める権限は「メッセージを投稿する」(chat:write)だけで、チャンネルの過去のメッセージを読むことはできません。このほか、Socket Mode用のアプリレベルトークン(connections:write)を発行し、ボットを承認用チャンネルに手動で招待しておきます。

止められた通信が、Slackに承認依頼として届く

サンドボックスから、まだ許可していないサイト(example.org)にアクセスすると、数秒で承認用チャンネルにカードが届きました。拒否された1回の通信から、OpenShellが「この通信を許可してはどうか」という提案を自動で作り、それがSlackに投稿される仕組みです。

サンプルのままだとカードは英語ですが、どのサンドボックスから、どのプログラムが、どこへの通信を求めているかが一目で分かります。各項目の意味は次のとおりです。
※Slackの承認カードには通信先や対象プログラム、提案理由などが表示されますが、今回の画面では送信データの本文そのものは表示されません。承認者はカードに表示された範囲の情報をもとに判断します。

カードの表示	意味
Egress approval	外部通信の承認依頼
Sandbox / Workspace	どのサンドボックスからの依頼か
Proposer	提案した主体。agent-authored は、拒否の記録からOpenShellが自動で作った提案(AIエージェント自身が申請したという意味ではない)。65% confidence は提案の確信度/td>
Denials seen	拒否が記録された回数(1 hit(s) は1回)
Requested egress	許可を求めている通信先
Binaries	許可の対象になるプログラム
Rationale	提案の理由
Validation	OpenShellのポリシー検証結果。no new findings は「ポリシー検証で新たな指摘なし」という意味

 

「承認」を押すと、その場で使えるようになる

「Approve(承認)」を押すと、確認画面が出ます。ここでもう一度「Approve」を押すと、動いているサンドボックスにそのまま反映されます。再起動は不要でした。

もう一度同じサイトにアクセスすると、今度は成功しました(結果は200)。カードは「Approved(承認済み)」に変わり、承認した人、日時、反映後のポリシーの番号(v5)が残ります。

理由を付けて「却下」する

許可が広すぎると感じた提案は、理由を付けて却下できます。理由の入力は必須に設定されていて、カードにそのまま記録されます。却下しても、サンドボックスの通信は止められたままです。下の画面は、GitHubへの提案を「読み取り専用の許可が既にあるため、より広い許可は不要」という理由で却下しているところです。

なお、Slackのメッセージは編集や削除ができるため、正式な監査の記録としては、OpenShell側の監査ログもあわせて残しておくと安心です。

カードを日本語にした

日本語のチームで使うなら、カードも日本語のほうが判断しやすくなります。サンプルはソースコードが公開されているので、画面に表示される文言だけを日本語に書き換えました。日時も日本時間で表示するようにしています。これは公式の機能ではなく、今回独自に行ったカスタマイズです。
日本語化した後に、example.comを却下し、example.netを承認したときの画面です。

なお、「提案の理由」と「自動検証」の中身はOpenShell側が生成するため、今回の表示文言だけの日本語化では英語のままです。また、「no new findings」は安全性全般を保証する意味ではなく、OpenShellのポリシー検証で新たな指摘が見つからなかったことを示します。
カードの「エージェントによる提案」は agent-authored を訳したもので、拒否の記録からOpenShellが自動で作った提案を指します。また、却下済みのカード(example.com)の理由欄は、動作確認のために「却下」とだけ入力したものです。実際の運用では、後から判断の根拠が分かるように、理由を具体的に書くことをおすすめします。

誰が使い、どんなときに便利か

OpenShellで制御するAIエージェントは、どこで動くのか

OpenShellが対象にするのは、会社や自分たちが管理するPC・サーバー上で動かすAIエージェントです。ChatGPTやClaude.aiそのものを囲う仕組みではありません。今回の検証のように、AIエージェントをOpenShellのサンドボックス内で動かし、その外への通信にルールをかけます。

立場	すること	OpenShellの操作
AIに仕事を頼む人	SlackなどからAIに仕事を頼み、結果を受け取る	基本的に不要
許可を判断する人	例外の通信だけ、Slackのカードで承認・却下する	基本的に不要
最初に準備する人	OpenShell、最初のルール、Slack連携を設定する	必要

 
※AIに仕事を頼む部分(Slackからエージェントへの依頼と結果の受け取り)は、Slack Admin Bridgeの機能ではなく、別の仕組みで用意する想定です。今回の検証で試したのは、通信の承認・却下の部分だけです。

イメージは、「ここまでは自由、ここから先は人に確認」という境界をAIの外側に作ることです。あらかじめ許可した通信はそのまま通し、ルールにない通信だけを止めて、人に判断を求めます。

AIに仕事を頼む人／許可を判断する人／最初に準備する人(依頼の経路は概念図)
最初に準備する人がOpenShellとルール、Slack連携を設定しておけば、普段使う人はOpenShellを操作する必要はありません。許可を判断する人は、基本的にSlack上でやり取りできます。仕事を頼む窓口は、別の仕組みで用意します(今回は未検証)。

どんなときに便利なのか

外部サイトやサービスを使う仕事をAIに任せたい一方で、外への通信を無条件には許可したくない場面に向いています。普段必要な通信は事前に許可してそのまま進め、想定外の通信だけをSlackで確認する運用にできます。

用途	AIに頼むこと	OpenShellでの境界
競合サイト調査	「競合3社の料金ページをまとめて」	許可済みのサイトはそのまま調査。初めての接続先だけ止めてSlackで判断する
問い合わせ要約	「問い合わせ内容を要約して」	要約は進めつつ、外部の翻訳サイトなどへ送ろうとした場合だけ止めて判断する
SNS調査	「SNSでの反応を調べて」	閲覧は許可、投稿は不許可のように分け、必要な例外だけSlackで承認する
共通	—	許可済みはそのまま、ルール外の例外だけをSlackで承認・却下する

 
この運用のポイントは、毎回承認を求めるのではなく、許可済みの仕事は止めず、例外だけを人に回せることです。なお、Slackの承認カードで確認できる主な材料は「どこへ」「どのプログラムが」「どの操作を許可するか」です。今回のカードには、実際に送信しようとしているデータ本文そのものは表示されません。承認者は、カードに表示された範囲の情報をもとに判断します。

参考にした手順と、つまずいたポイント

参考にした手順と、変えた点

基本はNVIDIAとSlackの公式ドキュメントを参照しています。サンドボックスのローカルDocker構成だけは、Slackのサンプルリポジトリにある未マージのPR #14も参考にしました。PR #14は2026/10/1時点でOpenのため、正式ドキュメントではありません。

作業	参考にした手順	今回変えた点
OpenShellの導入	NVIDIA OpenShellのインストールガイド(最新版を入れる手順)	筆者環境の初回検証では0.1.2でサンドボックスを起動できなかったため、PR #14の構成を参考に、動作確認できた0.0.113で実施。再検証では0.1.2でもサンドボックスは動いたが、Slackのブリッジが動かなかったため、Slackの承認は0.0.113で確認した
Docker Desktopの設定(0.1.2のみ)	Sandbox Runtimes(NVIDIA公式ドキュメント)のDockerドライバの項。ホストネットワークの有効化と、grpc_endpoint の設定	0.1.2の再検証で追加。初回の検証では、この設定に気づいていなかった
ポリシーの試し方	NVIDIA開発者ブログの「読み取りは許可、書き込みは拒否」のデモ	0.0.113で動く方法(差分だけを足すコマンド)に置き換え
サンドボックスの作り方	Slackサンプルリポジトリの未マージPR #14にあるLocal Docker quickstart	同じ構成を参考にして検証。PR #14は2026/10/1時点でOpen
Slackアプリの作成	Slack開発者ドキュメント「OpenShell Slack Admin Bridge」	リポジトリのmanifestを貼り付けて作成(ドキュメントの作成ボタンからなら修正は不要)
ブリッジの設定と起動	同上、およびリポジトリのREADME	監査ログの送信は省略し、承認・却下だけを試した
カードの日本語化	公式の手順はなし	表示文言だけを独自に書き換え

 
Slackアプリは、公式ドキュメントにある「Create Slack app」ボタンから作るのがいちばん簡単です。今回はリポジトリの manifest.json を貼り付ける方法を取ったため、説明用のメモ欄を消す一手間が必要でした。

つまずいたポイント

いちばん大きな壁は、最新版0.1.2を動かすことでした。初回の検証では、筆者のMac環境でサンドボックスを起動できませんでしたが、再検証で、公式ドキュメントにあるDocker Desktopの設定に気づいていなかったことが分かり、設定を入れると0.1.2でもサンドボックスは起動しました。一方、Slackとつなぐブリッジのサンプルは、検証時点では0.1.2で動かず、Slackの承認は0.0.113で確認しています。公式のサポートマトリクスではApple SiliconのmacOS + Docker Desktopはサポート対象なので、「Macでは0.1.2が動かない」と一般化できる結果ではありません。試す方は、バージョン、実行方式、検証日を必ず確認してください。

つまずき	起きたこと	どう解決したか
最新版(0.1.2)でサンドボックスが起動しない	の中から、Mac側のゲートウェイに連絡できなかった(ControlSupervisorStartFailed)。Docker Desktopのホストネットワークがオフで、ゲートウェイ設定にも連絡先がなかったことが原因とみられる。初回の検証では、ほかに2通りの方法も試したが、別のエラーで失敗した	ホストネットワークをオンにし、ゲートウェイ設定に grpc_endpoint を追加すると、このエラーは解消した。どちらも公式ドキュメントのDockerドライバの項に書かれている設定
起動しても「設定が不正」で止まる	PR #14の手順が固定しているイメージに入っていた古いポリシーが、0.1.xの検証で拒否された(ConfigurationInvalid)	ポリシーのファイルを指定して、サンドボックスを作り直した
Slackのブリッジが動かない(0.1.2)	ブリッジが0.0.x時代の項目(all_workspaces)で問い合わせ、0.1.2のゲートウェイが workspace_scope is required と返した。ブリッジのソース(GitHubのmain、2026年10月上旬時点)でも、この変更への対応は見当たらない	未マージのPR #14の手順が固定している0.0.113で、Slackの承認を確認した
入れ替え後に起動しない	0.1.2が作ったデータが残っていて、古い0.0.113が読めなかった	そのデータ(~/.local/state/openshell/gateway/openshell.db)を別の場所に退避
準備ソフトのエラー	Docker Desktopのインストールが権限不足で失敗。Macの開発ツールも古かった	Macの設定でターミナルに権限を与え、開発ツールを更新
Slackアプリが作れない	リポジトリのmanifestに、Slackが受け付けない説明用のメモ欄があった	メモ欄(先頭の _metadata)を消して貼り直す
動いているサンドボックスにポリシーが反映されない(0.0.113)	ポリシー全体を置き換える policy set が、動いているサンドボックスにうまく反映されない場合があった	差分だけを足す policy update を使った。例:policy update demo –add-endpoint api.github.com:443:read-only:rest:enforce –binary /usr/bin/curl –wait(GitHubの読み取りだけをcurlに許可)
sandbox connect で画面が表示されない	sandbox connect では、画面が表示されないことがあった	代わりに sandbox exec でコマンドを実行した
日本語化が反映されない	古いブリッジが動いたままで、英語のカードを投稿していた	古い方を止めてから起動し直す

 
OpenShell 0.1.xでは安定版のリリース方針が導入され、公式にはmacOS + Docker Desktopもサポート対象です。一方、0.0.xから0.1.0ではサンドボックスやポリシー、APIに互換性のない変更も入っています。今回も、Slackのブリッジのサンプルは、筆者が確認できた範囲では、2026/10/2時点で0.1.2に対応していませんでした。OpenShell本体とサンプルの対応バージョンをそろえて確認する必要があります。

まとめ

OpenShellとSlackを組み合わせると、AIエージェントの外部通信を「最初はすべて止め、必要になったらSlackで人が判断して許可する」運用にできました。

• 止めるのはAI自身ではなく、AIの外側にある関所なので、AIの判断に左右されません。
• 許可は「どのプログラムが」「どこへ」「読み取りか書き込みか」まで分けられます。
• 承認はSlackのボタン操作で、動いたまま反映され、判断の記録もSlackに残ります。

一方で、OpenShellは更新が速く、0.1.0でAPIが大きく変わっています。最新版0.1.2でも、設定を整えればサンドボックスの起動と通信の制限は確認できましたが、Slackとつなぐブリッジのサンプルは、検証時点では0.1.2で動かず、Slackの承認は0.0.113で確認しました。公式にはApple SiliconのmacOS + Docker Desktopはサポート対象なので、今回の結果は環境・バージョン・サンプルの組み合わせによるものとして捉える必要があります。業務で使う前には、手元の構成とバージョンで確かめることをおすすめします。

参考リンク

• NVIDIA Launches Open Agent Safety Platform(NVIDIAのプレスリリース、2026/9/28)
• Add Runtime Controls to AI Agents with NVIDIA OpenShell(NVIDIA開発者ブログ)
• NVIDIA OpenShell インストールガイド
• OpenShell Slack Admin Bridge(Slack開発者ドキュメント)
• openshell-slack-admin-bridge(GitHub)
• Local Docker quickstart(GitHub PR #14、2026/10/1時点でOpen)
• Extending admin control to the runtime layer with NVIDIA OpenShell and Slack(Salesforceブログ)
• Run Autonomous, Self-Evolving Agents More Safely with NVIDIA OpenShell(NVIDIA開発者ブログ、2026/3/16)
• NVIDIA OpenShell Support Matrix(Apple Silicon macOS + Docker Desktopのサポート状況)
• Upgrade to NVIDIA OpenShell 0.1.0(0.0.xから0.1.0の互換性に関する公式ガイド)
• NVIDIA OpenShell Sandbox Runtimes(Dockerドライバのホストネットワークと grpc_endpoint の設定)

＜Salesforce＞
弊社ではSalesforceをはじめとするさまざまな無料オンラインセミナーを実施しています！
＞＞セミナー一覧はこちら

また、弊社ではSalesforceの導入支援のサポートも行っています。ぜひお気軽にお問い合わせください。
＞＞Salesforceについての詳細はこちら
＞＞Salesforceの導入支援実績はこちらからご覧いただけます！

医療業界に特化した営業支援、顧客管理(SFA/CRM)のコンサルティングも提供しております。こちらもぜひお気軽にお問い合わせください。
＞＞顧客管理(SFA/CRM)のコンサルティングの詳細はこちら