Codexのセキュリティは本当に安全?【結論:安全だが注意点もあり】

こんにちは。AI・ノーコード開発を手がける成長支援カンパニーWalkersです。

弊社では多くの企業様からAI開発に関するご相談をいただいていますが、その中でも「Codexのセキュリティは本当に安全なのか」という質問は特に多く寄せられます。

Codexは自分のパソコンの中でファイルを読み書きし、コマンドまで実行できるツールです。そう聞くと、任せて大丈夫なのか心配になりますよね。

実は、Codexのセキュリティは決して弱くありません。むしろ適切に設定すれば、強固なセキュリティ体制を実現できます。

そこで今回は、Codexのセキュリティについて以下の内容を解説していきます。

この記事の内容
  • Codexのセキュリティが安全な5つの理由
  • 代表的なCodexのセキュリティ設定
  • セキュリティが安全でも情報漏洩が起きる理由
  • セキュリティを万全にするための解決策

Walkersでは「AIを用いたシステム開発のノウハウがない」「最大限に効率よく開発を進めたい」企業さまに、事業を成功に導くAI開発×補助金支援を行っています。⇒サービス概要はこちら

執筆者:山口 鳳汰
 

執筆者:山口 鳳汰
累計100万PV以上のAI・ノーコード開発メディアの編集長。
アプリ開発の電子書籍を3冊出版し、1冊はAmazonベストセラーを獲得。

その他、受託開発や教育など多数のノーコード事業に参画している。

運営会社:株式会社Walkers

運営会社:株式会社Walkers
AI・ノーコード開発を手がける成長支援カンパニー。
300件以上の開発/制作実績、200件以上の企業様を支援。
マーケティングやUI/UXと掛け合わせたサービス開発を得意としている。

執筆者:山口 鳳汰

執筆者:山口 鳳汰
累計100万PV以上のAI・ノーコード開発メディアの編集長。
アプリ開発の電子書籍を3冊出版し、1冊はAmazonベストセラーを獲得。

運営会社:株式会社Walkers

運営会社:株式会社Walkers
AI・ノーコード開発を手がける成長支援カンパニー。
これまでに300件以上の開発/制作実績、200件以上の企業様を支援。

クリックできる目次

Codexのセキュリティは安全なのか?

Codexのセキュリティは安全なのかの解説画像

初めにも言いましたが、Codexのセキュリティは決して弱くありません。

CodexはOpenAIが提供する開発支援ツールで、企業での利用を前提に設計されています。実際に公式ドキュメントでは、セキュリティの仕組みだけで独立した解説ページが用意されています。

さらに重要なのは、Codexが「危険なことをできないように作られている」という点です。

  • 作業できる範囲がサンドボックスで区切られている
  • インターネット接続は最初から遮断されている
  • 区切りを越える操作には人の承認が要る
  • 業務データは既定でモデルの学習に使われない

※サンドボックスとは「ツールが触れるファイルや通信の範囲をあらかじめ区切っておく、隔離された実行環境」を指す。

このように、従来の「AIに任せると何をされるか分からない」というイメージとは異なり、リスクを前提に設計されたツールであることが分かります。

そのため、手作業で環境を組んで開発するよりも、Codexのような仕組みを活用した方が、かえって安全性が高くなるケースも十分にあります。

Codexのセキュリティが安全と言える5つの理由とは?

Codexのセキュリティが安全と言える5つの理由の解説画像

ここからは、Codexのセキュリティが安全と言える理由を、公式ドキュメントの記載にもとづいて5つ紹介します。

【理由①】国際的なセキュリティ認証を取得した基盤の上で提供されている

国際的なセキュリティ認証を取得した基盤の上で提供されているの解説画像

Codexは、OpenAIが提供しているサービスです。

OpenAIは、SOC 2 Type 2やISO/IEC 27001といった、国際的に認められたセキュリティ認証を取得しています。公式のトラストポータルでは、独立した第三者の監査法人による評価を受けていることが明記されています。

公開されている対応状況は以下のとおりです。

  • SOC 2 Type 2・SOC 3
  • ISO/IEC 27001:2022(情報セキュリティ)
  • ISO/IEC 27017:2015・27018:2019(クラウドと個人データ)
  • ISO/IEC 27701:2019(プライバシー)・42001:2023(AIマネジメント)
  • GDPR・CSA STAR・PCI DSS v4.0.1

※SOC 2 Type 2とは「セキュリティや機密保持に関する社内の仕組みが、一定期間にわたって実際に機能していたかどうかを、第三者が検証した報告書」を指す。

これらは単なる技術的な対策の話ではなく、社内の運用体制まで含めて外部の目が入っていることを示しています。

加えてOpenAIは、Bugcrowdを通じたバグバウンティを運営しており、外部の研究者から脆弱性の報告を受け付ける窓口を常設しています。

【理由②】既定でネットワークを遮断したサンドボックスの中で動く

既定でネットワークを遮断したサンドボックスの中で動くの解説画像

Codexの安全性を支えている中心が、このサンドボックスです。

公式ドキュメントには「標準のサンドボックスは、設定で有効にしない限りネットワークアクセスをオフのままにする」と明記されています。つまり、何も設定していない状態では、Codexが実行するコマンドは外部と通信できません。

ここで遮断されるのは、あくまでCodexが動かすコマンドの通信です。Codex自体は、指示や対象のコードをOpenAIのサーバーに送って処理する仕組みなので、「手元から何も出ていかない」という意味ではない点は押さえておいてください。

書き込みできる範囲も、作業中のフォルダと一時ディレクトリに限られています。

この制限は、OSの機能を使って強制されます。

  • macOSではSeatbelt(sandbox-exec)を使う
  • Linuxではbwrapとseccompを使う
  • WindowsではWindows専用のサンドボックスを使う(WSL2で動かす場合はLinuxと同じ仕組み)

重要なのは、この制限がCodexの自主的な遠慮ではなく、OS側で強制されている点です。AIが指示を取り違えたとしても、境界の外には手が届きません。

さらに、書き込み可能な範囲の中でも .git や .codex といった設定用のフォルダは読み取り専用で保護されており、この保護は配下のファイルすべてに及びます。

【理由③】サンドボックスを越える操作には承認が必要になる

サンドボックスを越える操作には承認が必要になるの解説画像

サンドボックスが「できる範囲」を決める仕組みだとすれば、承認ポリシーは「いつ人に確認するか」を決める仕組みです。

公式ドキュメントでは、この2つが組み合わさって機能すると説明されています。

標準の設定では、作業フォルダの中の読み書きやコマンド実行は自動で進みます。一方で、次のような操作は人の承認を求めます。

  • 作業フォルダの外にあるファイルを書き換えるとき
  • ネットワークを使うコマンドを実行するとき
  • 副作用があると宣言された外部ツールを呼び出すとき

特に、破壊的な操作だと宣言されている外部ツールの呼び出しは、原則として承認が必要になる設計です。

起動時の初期値も安全側に寄せられています。Gitで管理されたフォルダなら標準設定、管理されていないフォルダなら読み取り専用が推奨されます。

【理由④】業務データは既定でモデルの学習に使われない

業務データは既定でモデルの学習に使われないの解説画像

自社のコードが学習に使われて、他社の回答に出てしまうのではないか。これは相談の場でも必ず出る不安です。

公式ドキュメントには、ビジネス・Enterprise・Eduのワークスペースのデータは通信中も保存時も暗号化され、既定ではモデルの学習に使われないと明記されています。

APIについても同様です。2023年3月1日以降、APIに送られたデータは、利用者が自ら共有を選ばない限り学習には使われないと公開されています。

削除したチャットは、公開された例外を除いて原則30日以内に完全削除がスケジュールされます。

より厳しい要件がある企業向けには、追加の仕組みも用意されています。

  • ログを残さないゼロデータ保持(APIに対する設定。事前承認制)
  • 自社で管理する鍵を使った暗号化(対象のEnterprise・Eduワークスペース向け)
  • ワークスペース単位の保存期間設定

ゼロデータ保持はAPI側の仕組みで、ChatGPTのワークスペースの保存期間を決めるものではない点だけ注意が必要です。
いずれも審査や追加条件を伴いますが、要件の厳しい業界でも交渉の余地があるということです。

【理由⑤】クラウド実行は隔離コンテナで動きシークレットは実行前に取り除かれる

クラウド実行は隔離コンテナで動きシークレットは実行前に取り除かれるの解説画像

Codexには、自分のパソコンではなくクラウド側で作業を任せる使い方もあります。

この場合、処理はOpenAIが管理する隔離されたコンテナの中で動きます。公式ドキュメントでは、利用者のパソコンや無関係なデータにはアクセスできないと説明されています。

注目したいのは、クラウド実行が2段階に分かれている点です。

  • 準備の段階だけネットワークにつながり、必要な部品を取得する
  • AIが実際に作業する段階は、既定でオフラインになる

そして、環境に設定したシークレットは準備段階でしか使えず、AIが作業を始める前に取り除かれます。

※シークレットとは「外部サービスにつなぐための鍵やパスワードなど、外に出てはいけない設定値」を指す。

仮にAIが誤って設定値を出力しようとしても、その時点で手元に鍵が残っていない構造になっているということです。


ここまでを整理すると、Codexでは

  • 第三者監査を受けた基盤
  • 範囲を区切るサンドボックス
  • 境界を越えるときの承認
  • 学習利用と保存期間のコントロール

といった形で、複数の観点からセキュリティが設計されています。

\特典:最適な開発方法をご提案/

Codexで設定できる主なセキュリティ機能とは?

Codexで設定できる主なセキュリティ機能の解説画像

Codexは、利用者側でも安全性の水準を調整できます。代表的な設定は次の5つです。

① サンドボックスモード(動ける範囲の制御)

Codexが技術的に何をできるかを決める設定で、3段階から選べます。

  • read-only:読むだけ。調査や設計の相談に向く
  • workspace-write:作業フォルダの中だけ書き換えられる標準設定
  • danger-full-access:制限を外す設定。通常は使わない

まずはread-onlyで動かし、必要になってから権限を広げるのが安全な進め方です。

② 承認ポリシー(確認を求めるタイミングの制御)

どの操作で手を止めて人に聞くかを決める設定です。標準は、必要なときだけ確認を求める方式になっています。

確認をまったく求めない設定も選べますが、その場合もサンドボックスの制限は残ります。自動化の度合いと安全性を、2つの設定の組み合わせで調整する形です。

なお、以前あった厳格な承認設定のひとつは廃止されており、古い設定が残っていると起動できない場合があります。

③ ネットワークの許可ドメイン制御(通信先の制限)

通信を許可する場合でも、つなぎ先を絞り込めます。

設定は許可リスト方式で、明示的に許可した宛先以外には出ていきません。禁止の指定は許可より優先され、社内ネットワークのような内部の宛先も既定でブロックされます。

注意したいのは、ドメインのルールを書いただけでは制限が効かない点です。通信を絞り込む機能そのものを有効にして、はじめてルールが適用されます。

④ 自動承認レビュー(危険な操作の自動判定)

承認が必要な操作を、人に聞く前に別のAIが点検する仕組みです。

点検の観点は公式に示されており、データの持ち出し、認証情報の探索、セキュリティ設定を恒久的に弱める行為、破壊的な操作が対象です。

重大なリスクがあると判定された操作は拒否されます。点検そのものが失敗した場合も実行されない設計で、迷ったら止める側に倒れるのが特徴です。

⑤ Web検索モード(外部情報の取り込み方の制御)

Codexは既定で、OpenAI側が用意した検索インデックスの結果を使います。ライブのページをその場で読みに行く動作は、明示的に指定したときだけ有効になります。

検索機能自体を無効にすることもできます。

外部のページをそのまま読ませるほど、後述する悪意ある指示文の紛れ込みに触れる機会が増えるため、業務で使うなら既定のまま運用するのが無難です。


単に「安全に作られている」だけでなく、利用者自身がリスクの大きさを選べる仕組みが用意されている点が、Codexの大きな特徴です。

セキュリティが強くても情報漏洩が起きるのはなぜか?

セキュリティが強くても情報漏洩が起きるのはなぜかの解説画像

ここまでの解説の通り、Codexは高いセキュリティ水準で設計されています。

しかし、それでも情報漏洩のリスクが完全になくなるわけではありません。

どれだけツール側の仕組みが強固でも、最終的なリスクは設定と使い方によって変わるためです。

実際、公式ドキュメントでも以下のように明記されています。

Use caution when enabling network access or web search in Codex. Prompt injection can cause the agent to fetch and follow untrusted instructions.

(Codexでネットワークアクセスやウェブ検索を有効にする際は注意してください。プロンプトインジェクションによって、エージェントが信頼できない指示を取得し、それに従ってしまう可能性があります。)

出典:Codex公式の承認・セキュリティ解説ページ

※プロンプトインジェクションとは「AIが読み込む文章の中に悪意ある指示文を紛れ込ませ、本来の指示とは違う動きをさせる手口」を指す。

同じページでは、検索結果についても信頼できないものとして扱うべきだと補足されています。安全に倒した既定値であっても、外部から取り込む情報は疑ってかかる前提です。

危険な挙動を検知してタスクを止める監視機能も用意されていますが、公式はこの監視がサンドボックスや権限設定、結果の確認の代わりにはならないと明言しています。

つまり、「ツールが安全かどうか」だけでなく、「どう使うか」が重要ということです。

注意すべきポイントは何か?

Codexで注意すべきポイントの解説画像

Codexを安全に利用するためには、特に以下の点に注意が必要です。

① 提案された操作を確認せずに承認してしまう

提案された操作を確認せずに承認してしまうの解説画像

Codexは、サンドボックスの外に出る操作の前に確認を求める設計になっています。

しかし、その内容を十分に読まずに承認してしまうと、せっかくの境界が意味を持たなくなります。

承認画面は作業を止める面倒な確認ではなく、最後の防波堤です。特に次の3点は必ず読んでから判断してください。

  • 触ろうとしているのが作業フォルダの外かどうか
  • 外部への通信が発生しないか
  • 元に戻せない操作が含まれていないか

② 制限を外した状態のまま使い続ける

制限を外した状態のまま使い続けるの解説画像

Codexには、サンドボックスも承認もすべて無効にして動かす設定があります。

この設定は公式ドキュメント上でも推奨されない選択肢として扱われています。

作業が止まるのが煩わしいという理由で一度使うと、そのまま常用してしまいがちです。使う場面は、捨ててよい検証用の環境に限るべきです。

自動化を進めたいだけであれば、制限を外さずに承認だけを減らす設定を選べます。

③ 信頼できない外部の情報をそのまま処理させる

信頼できない外部の情報をそのまま処理させるの解説画像

前の章で触れたプロンプトインジェクションは、AI開発で最も現実的なリスクです。

攻撃は、AIが読み込む場所であればどこにでも仕込めます。

  • 外部から取得したWebページをそのまま読ませる
  • 出所の分からないライブラリやテンプレートを読み込ませる
  • 第三者が書き込める場所のテキストを処理させる

対策の基本は、外部から来た内容は指示ではなくデータとして扱うことです。

そのうえで、外部情報を読ませるときだけ権限を絞る運用にしておくと、仮に紛れ込みがあっても実害につながりにくくなります。

④ ネットワークを開けたまま運用する

ネットワークを開けたまま運用するの解説画像

パッケージのインストールなどで通信を許可する場面はあります。

問題は、作業が終わった後も開けたままにしてしまうことです。通信が開いている状態は、情報が外に出る経路が開いている状態でもあります。

通信を許可する場合は、つなぎ先を必要な宛先だけに絞り込んでください。

なお公式ドキュメントでは、宛先の判定について技術的な限界があることも率直に説明されています。攻撃者が用意した名前解決まで想定するなら、ツールの設定だけに頼らず、ネットワーク側でも出口を制御するのが確実です。


Codexは、

  • サンドボックス
  • 承認ポリシー
  • データポリシー

といった観点から、非常に安全性の高いツールです。

しかし、

セキュリティは「ツールだけで完結するものではない」
最終的には「ユーザーの使い方」が重要になる

という点は、必ず押さえておく必要があります。

【解決策】Codexでの開発を外注する場合は信頼性の高い会社を選ぶ

Codexでの開発を外注する場合は信頼性の高い会社を選ぶの解説画像

ここまで見てきた通り、Codex自体は高いセキュリティを備えたツールです。

しかし実際の開発においては、「誰がどのように使うか」によって、安全性や品質は大きく変わります。

特に外注する場合は、開発会社の選び方が、そのままセキュリティや開発品質に直結すると言っても過言ではありません。

  1. 信頼できる実績があるか
  2. ブログやSNS、YouTubeで有益な発信がされているか
  3. 問い合わせた際の対応が丁寧か
  4. サポート体制は十分か
  5. 自社の事業・課題を踏まえて提案してくれるか

【ポイント①】信頼できる実績があるか

信頼できる実績がないと技術力が低い可能性が高いの解説画像

まず最も重要なのが、実績の有無とその中身です。

Codexは、AIを活用して高速に開発を進められる一方で、単にツールを使うだけでは成果にはつながりません。

重要なのは、

  • どの工程でCodexを活用しているのか
  • どのサンドボックス設定で運用しているのか
  • AIが生成したコードをどのように検証しているのか

といった「使い方の設計」です。

そのため開発会社に依頼する際は、「Codexを使っています」という表面的な説明ではなく、具体的な活用プロセスや成果事例まで確認することが重要です。

特に、自社の目的に近い領域(MVP開発、業務効率化、社内ツールなど)での実績がある会社であれば、認識のズレが起きにくく、プロジェクトもスムーズに進めやすくなります。

【ポイント②】ブログやSNS、YouTubeで有益な発信がされているか

有益な発信がされていると問題が生じる可能性が低いの解説画像

CodexのようなAI開発領域は、変化のスピードが非常に速い分野です。

セキュリティに関わる既定値や設定項目も更新されていくため、最新の仕様を追えているかどうかが品質の差になります。

そのため、開発会社が

  • ブログ
  • 技術記事
  • SNS
  • YouTube

などで継続的に発信しているかは、情報の鮮度を保てている会社かどうかの判断材料になります。

【ポイント③】問い合わせた際の対応が丁寧か

問い合わせた際の対応が丁寧だと依頼後も丁寧な可能性が高いの解説画像

問い合わせ段階の対応は、そのままプロジェクト中のやり取りの質に表れます。

特にセキュリティの話題では、分からないことを分からないと言えるかどうかが重要です。

「AIを使っているので安全です」とだけ答える会社より、前提条件や制約まで説明してくれる会社の方が、後々のトラブルは起きにくくなります。

【ポイント④】サポート体制は十分か

サポート体制が良いとトラブル発生時も適切に対応可能の解説画像

セキュリティ上の問題は、リリース後に見つかることも珍しくありません。

そのため、納品して終わりではなく、問題が起きたときに誰がどこまで対応するのかを事前に決めておく必要があります。

契約前に、対応範囲・連絡経路・想定される対応時間を確認しておくと安心です。

【ポイント⑤】自社特有の課題を踏まえて提案してくれるか

自社特有の課題を踏まえて提案してくれるとアプリの完成度が高くなるの解説画像

Codexは強力なツールですが、「作れるから作る」という判断に陥ると失敗しやすいのも事実です。

そのため重要なのは、

  • どこにCodexを使うべきか
  • あえて使わない方がいい部分はどこか
  • 事業として意味があるか

といった視点で提案してくれるかどうかです。

単なる開発ではなく、

  • 壁打ち
  • 仮説検証
  • PoC設計

まで伴走してくれる会社であれば、スピードと事業価値の両立がしやすくなります。


本記事では、Codexのセキュリティについて、安全と言える理由と、あわせて押さえておきたい注意点を解説しました。

Codexは、サンドボックスによる範囲の制限、承認ポリシー、データの学習利用に関する方針など、複数の観点から安全性が考慮されたツールです。
一方で、どれだけセキュリティ機能が整っていても、設定ミスや運用方法によっては情報漏洩などのリスクが発生する可能性があります。

だからこそ、「Codexは安全か危険か」を二択で考えるのではなく、どのような仕組みで安全性が担保されているのか、そして安全に使うために何を意識すべきかを理解した上で活用することが重要です。

この記事が、Codexの導入や活用を検討する際の参考になれば幸いです。

Walkersでは成果が実証されたノウハウをもとに、事業を成功に導くためのAI開発×補助金支援を行っています。新規事業・システム開発でお悩みがある方はお気軽にご相談下さい。

AI開発×補助金支援サービスの概要はこちら>>

Walkersに無料で相談する>>

無料セルフチェック

費用も、AI活用の効果も。まず無料でチェック

開発の概算費用と、業務のAI効率化診断。条件を選ぶだけで、その場で結果を確認できます。会社への問い合わせは不要です。

無料でチェックを始める →
  • URLをコピーしました!
クリックできる目次