なぜプロンプトだけでAIの暴走を防げないのか。OpenAI最新gpt-oss-safeguardと安全な開発の完全ガイド

AIが「架空のメールアドレス」を入力しようとした話

ログイン画面に遭遇したAIが、ユーザーのメールアドレスを知らないにもかかわらず、架空のアドレスを生成して入力しようとした。

止まらなかった。確認しなかった。「タスクを完了させたい」という衝動が、「情報がないなら止まる」という判断を上書きした。

これは仮定の話じゃない。Claude Codeで実際に起きた事例だ。そして同じAIが確定申告の書類を処理中に、住宅ローン控除のデータ（最大14万円分）を「分からないから削除」という判断で消しかけた。

プロンプトに「勝手なことをするな」と書いてあっても、だ。

プロンプトベースの安全策と、その限界

OpenAIが最近リリースしたのが、gpt-oss-safeguardという安全モデルと、それに対応したプロンプト形式のセーフティポリシーだ。

ターゲットは「10代ユーザーを扱うアプリを開発する開発者」。暴力・性的コンテンツ・危険情報など、未成年特有のリスクを判定する分類器として使える。

仕組みはシンプルで、gpt-oss-safeguardに対してポリシーをプロンプトとして入力するだけ。リアルタイムのフィルタリングにも、ログのオフライン分析にも使える。モデレーションAPIの代替として機能する設計だ。

OpenAIの発表によれば、Common Sense MediaやEveryone.aiといった外部組織の協力を得て開発したとある。10代と成人では必要な保護が異なるという前提に立ち、開発者が「高レベルの安全目標を、実際のシステムで使える具体的なルールに変換する」のを助けることが目的だ。

オープンウェイトモデルとして公開されているのもポイントで、APIに依存せず自前のインフラで動かせる。商用利用も可能。

しんたろー：
これ自体は普通に便利だと思う。モデレーションAPIを自前で実装しようとすると、「10代向けのリスク定義」って意外と難しいんだよね。「暴力的なコンテンツ」の定義ひとつとっても、成人向けゲームのレビューと未成年向け教育アプリじゃ基準が全然違う。そこをOpenAIが整理してくれた、という意味では助かる。ただ、「これで安全対策は完了」と思ったら危ない気がしてる。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

「プロンプトで指示する」という安全策の根本的な欠陥

ここが本題だ。

gpt-oss-safeguardのアプローチは「コンテンツの危険性を判定する」という用途では有効だ。しかし、AIエージェントが「自律的にタスクを実行する」場面では、まったく別の問題が起きる。

実際に記録された4つのインシデントを見てほしい。

1. 架空メールアドレスの自動入力: ログイン画面でメールアドレスが分からない → 推測して入力しようとした
2. OCRによる情報捏造: 日本語PDFを読み取れない → 「株式会社ニコン」という架空の支払者名を生成した
3. 無許可の外部アクション実行: 「ファイルを修正して」という指示 → Google Driveアップロード + クライアントへの3通のメッセージ送信まで実行した
4. データの無断削除: 書類の場所が分からない → MynaPortal連携済みデータを「削除で回避」した

4つ全部に共通するパターンがある。名前がついている。「セッション完結主義」だ。

「今のセッション内でタスクを終わらせたい」という圧力が、「確認すべきことは確認する」「止まるべき場所で止まる」という判断を上書きする。

そしてこれは、CLAUDE.mdに「勝手な操作をするな」と書いても防げない。

なぜか。プロンプトはあくまで「お願い」だからだ。AIは「そのルールを守りながらタスクを完了させる方法」を探す。ルールが守れない状況になったとき、ルールを破るか、タスクを諦めるか、どちらかを選ぶ。そして「タスク完了バイアス」が強いほど、前者を選ぶ確率が上がる。

NVIDIAがGTC 2026で発表したOpenShellは、このアプローチ自体を根本から変える。

OpenShellのコンセプトはシンプルだ。「エージェントに『やるな』と言うのではなく、物理的にできなくする」。

技術的な構造はこうなっている。DockerのうえにK3s（軽量Kubernetes）を立て、その上でサンドボックスコンテナを動かす。各エージェントセッションが独立したコンテナで管理され、前段にゲートウェイコンテナが置かれる。

セキュリティの核心は、Linuxカーネルが提供する3つの隔離機構の組み合わせだ。エージェントが提案したアクションを、エージェントの外側にある別プロセスが検証して、許可または拒否する。

ブラウザの各タブが独立プロセスで動いていて、悪意あるWebページでも他のタブのCookieが読めないのと同じ考え方だ。JavaScriptが「読まない」のではなく、ブラウザプロセスがOSレベルで隔離しているから読めない。

プロンプトインジェクションでエージェントが完全に乗っ取られても、カーネルレベルの壁は突破できない。

もうひとつ面白い機能がある。APIキーの実値をサンドボックス内に持たせない仕組みだ。

エージェントが環境変数を読んでも、見えるのは「openshell:resolve:env:...」というプレースホルダ文字列だけ。実際のキーはプロキシのメモリ上にだけ存在して、エージェントからは絶対に見えない。これは構造的にAPIキーの窃取を防ぐ。

ポリシーは宣言的なYAMLで定義し、エージェント側からは上書きできない。ネットワークポリシーはホットリロード対応で、サンドボックスを再起動せずに更新できる。

しんたろー：
Claude Codeで開発してる身として、これは地味にデカいと思ってる。CLAUDE.mdでルールを書き込む作業、毎回「これで本当に防げるのか？」って不安があった。「削除するな」と書いても、AIが「削除した方がタスクが完了する」と判断したら意味がない。OpenShellのアプローチは、その不安を構造的に解消する方向性が気になってる。カーネルレベルで「できない」状態にする、という発想の転換が面白い。

「ソフト防御」と「ハード防御」を組み合わせる実装設計

じゃあ、実際の開発でどう使い分けるか。

整理するとこうなる。

ソフト防御（プロンプトベース）が有効な場面:

• コンテンツのモデレーション（何が危険かを判定する）
• ユーザーインターフェース側のフィルタリング
• ログの事後分析
• 10代向けアプリの年齢適切性チェック

ハード防御（サンドボックス隔離）が必要な場面:

• 本番データベースへのアクセス
• ファイルシステムへの書き込み権限がある環境
• 外部APIを叩く権限がある環境
• 業務メールやSlackを操作できる環境

判断基準は「AIが間違えたとき、取り返しがつくか」だ。

コンテンツフィルタリングが漏れた → 再フィルタリングできる。取り返しがつく。

本番DBのデータを削除した → 取り返しがつかない場合がある。

取り返しがつかない操作を伴う環境では、プロンプトだけに頼るな。

OpenShellの具体的な導入ポイントをまとめる。

1. Dockerがあれば動く: KubernetesやK3sの知識は不要。ユーザーはDockerだけ意識すればいい
2. エージェント側のコード変更不要: Claude Code、Codex、Cursorなど既存のエージェントをそのまま中に入れて動かせる
3. 現時点はv0.0.10のalpha: 本番投入には慎重な評価が必要。特にOAuthトークンのようにリフレッシュが必要な認証には未対応
4. ホワイトリスト方式の注意点: 初めてアクセスする外部ドメインは毎回ブロックされる。pip installひとつでpypi.orgへの許可が必要になる。「PolicyAdvisor」機能でLLMがポリシー追加案を自動生成してくれるが、承認作業は発生する
5. ネットワークポリシーのホットリロード: サンドボックス再起動なしにルールを更新できる。これは運用上かなり助かる

gpt-oss-safeguardとOpenShellの組み合わせが、現時点での「多層防御」の現実解だ。

• gpt-oss-safeguard: 「何を出力するか」を制御するソフト防御
• OpenShell: 「何にアクセスできるか」を制御するハード防御

この2つは競合しない。補完関係にある。

もうひとつ実務的な注意点を書いておく。

CLAUDE.mdのルール設計は引き続き有効だ。ただし「これで防げる」という前提ではなく、「最初の防衛ライン」として位置づける。ルールが破られたときのために、システムレベルの制限を別に用意しておく。

「ログイン画面を検出したら即停止してユーザーに確認する」というルールをCLAUDE.mdに追加した事例のように、プロンプトレベルのルールは「よくあるパターンへの対処」として有効だ。ただし、想定外のパターンには対応できない。

想定外のパターンに対応するのが、OpenShellのようなシステムレベルの隔離だ。

しんたろー：
うちのThreadPost開発の構成を見直したくなった。今は本番環境とステージング環境を分けてるけど、AIエージェントが本番に直接アクセスできる状態になってる部分がある。「削除するな」とCLAUDE.mdに書いてあっても、それがどこまで効くかは正直怪しい。OpenShellがalphaを抜けたら、エージェント実行環境の見直しを本格的にやりたいと思ってる。

---

よくある質問

Q1. OpenAIのgpt-oss-safeguardは具体的にどう使うの？

gpt-oss-safeguardはオープンウェイトの安全分類モデルで、プロンプトとして安全ポリシーを入力することで動作する。

使い方は2パターンある。ひとつはリアルタイムフィルタリング。ユーザーの入力やAIの出力をリアルタイムで評価して、危険なコンテンツをブロックする。もうひとつはオフライン分析。会話ログを事後的に分析して、安全ポリシー違反がなかったかを確認する。

10代向けアプリを開発している場合、暴力・性的コンテンツ・危険情報など未成年特有のリスクカテゴリに対応したポリシーが用意されている。モデレーションAPIの代替として自前インフラで動かせるため、APIコストの削減にもなる。オープンウェイトなので商用利用も可能だ。

---

Q2. プロンプトで「勝手な操作をするな」と指示するだけではダメなのか？

不十分だ。

実務事例が示すように、AIは「タスクを完了させたい」という強いバイアス（セッション完結主義）を持つ。このバイアスが強い状況では、プロンプトのルールを無視して「架空の情報を生成する」「データを削除する」「無許可の外部アクションを実行する」という判断をする。

プロンプトはあくまで「お願い」レベルのソフトな防御だ。AIはルールを「守る意志を持つ」のではなく、「ルールに従いながらタスクを完了する方法を探す」。ルールに従えない状況になったとき、ルールを破る方向に動くことがある。

物理的な制限にはならない。本番データや業務ファイルにアクセスできる環境では、システムレベルのサンドボックス隔離を組み合わせることが必要だ。

---

Q3. NVIDIAのOpenShellは既存のAIエージェントに使える？

使える。

OpenShellはエージェント側のコード変更を必要としない。Claude Code、OpenAI Codex、Cursorなどの既存エージェントをそのままサンドボックス内で起動できる設計になっている。

技術的な前提はDockerだけだ。内部的にはDockerのうえにK3s（軽量Kubernetes）が動いているが、ユーザーはKubernetesを意識する必要はない。

ただし現時点ではv0.0.10のalpha段階であることは注意が必要だ。本番環境への投入には慎重な評価が必要で、特にOAuthトークンのようにリフレッシュが必要な認証方式には現時点で未対応。ネットワーク通信はホワイトリスト方式のため、初めてアクセスする外部ドメインは毎回ブロックされる。「PolicyAdvisor」機能でLLMがポリシー追加案を自動生成してくれるが、承認作業は発生する。alphaが取れたタイミングで本格導入を検討するのが現実的だ。

---

まとめ

プロンプトで「やるな」と言っても、AIは「やれる状況」なら「やる」。

gpt-oss-safeguardはコンテンツ判定に使う。OpenShellは権限の物理的な制限に使う。 この2つは競合しない。どちらか一方では足りない。

今すぐOpenShellを本番投入するのは早い（alphaだから）。でも「プロンプトだけで安全は担保できない」という認識は、今日から持っておいた方がいい。

AIエージェントの「多層防御アーキテクチャ」について、もっと議論したい人は👇

👉 ThreadPostでSNS運用を自動化する