Codex Securityは、GitHubで管理されているコードを読み、サービスごとに注意すべき場所を整理したうえで、実際の攻撃につながる可能性がある弱点を探すOpenAIの機能です。見つけた候補については、外部から切り離された環境で再現を試し、問題が確認できた場合には修正案まで作成します。ただし、AIが勝手にコードを書き換えるわけではなく、最終的な確認と反映は人が行います。
現在はChatGPT Enterprise、Edu、Business、Proの利用者向けにリサーチプレビューとして提供されています。警告を増やすのではなく、対応すべき問題を見分けやすくし、日々の開発作業の中で安全対策を進めるための仕組みであるため、本プロジェクトの詳細を考察します。
コードの背景を読みながら弱点を探すCodex Security
Codex Securityは、プログラムの中にある安全上の弱点を見つけ、問題が本当に起こるのかを確かめ、修正案を作るための機能です。このような安全上の弱点は「脆弱性」と呼ばれます。脆弱性を放置すると、外部から情報を見られたり、本来は使えない機能を操作されたりするおそれがあります。
Codex Securityの特徴は、危険な書き方を機械的に探すだけではなく、コード全体のつながりやサービスの使われ方まで確認する点にあります。OpenAIは、従来のスキャナーよりもセキュリティ研究者に近い形で働くように設計されていると説明しています。コードを読み、必要に応じてテストを行い、攻撃者がどこから入り、どのような流れで重要な情報や機能へ近づくのかを調べます。
現在のCodex Securityは、GitHub上でコードを保管・管理する場所である「リポジトリ」と直接つないで利用します。対象となるコードだけでなく、過去にどのような変更が行われたかも確認するため、現在の状態だけを見た場合には気づきにくい問題を見つけられる可能性があります。
ただし、Codex Securityがコードを自動で書き換えることはありません。問題が確認された場合には修正案が示されますが、その内容を採用するかどうかは開発者が確認して決めます。AIにすべてを任せるサービスではなく、人が安全性を判断するために必要な調査や確認を助ける仕組みとして位置づけられています。
Codex Securityが問題を見つけて修正案を作る流れ
Codex Securityは、疑わしい場所を見つけただけで作業を終えるわけではありません。対象となるコードを調べ、問題が実際に起こるかを確かめ、原因に合った修正案を作ります。ここでは、その流れを三つの段階に分けて紹介します。
サービスごとに注意すべき場所を整理する
Codex SecurityをGitHubリポジトリにつなぐと、新しい変更から順にコードを確認し、対象となるサービスの特徴を整理します。その際に作られるのが「脅威モデル」です。脅威モデルとは、どこから攻撃を受ける可能性があるのか、どの情報を守る必要があるのか、どの処理で大きな問題が起こりやすいのかをまとめたものです。
たとえば、利用者が文字やファイルを入力する場所、ログイン状態を確認する処理、個人情報を保存する場所などが調査の対象になります。外部から入った情報が複数の処理を通り、重要なデータや機能まで届く可能性がないかを確認します。
作成された脅威モデルは、開発チームが内容を確認して編集できます。実際の公開方法や利用環境と違う部分があれば、前提を直すことも可能です。これにより、Codex Securityがサービスをどのように理解しているかを人が確認しながら、現実の運用に近い条件で調査を進められます。
外部から切り離された環境で問題を確かめる
コードの中に気になる場所が見つかっても、それだけで実際の危険があるとは限りません。書き方だけを見ると危険に見えても、サービスの構成や利用条件によっては問題が起こらない場合もあります。そのため、Codex Securityは見つけた候補をすぐに警告として出すのではなく、外部から切り離された環境で再現を試みます。
この確認では、どのような操作を行ったのか、コードがどのように動いたのか、問題を再現できたのかといった内容が記録されます。攻撃に利用できる可能性についても確認し、実際に動くことが示された問題を優先して提示します。
確認の結果や実行内容が残ることで、開発者は「危険かもしれない」という短い警告だけではなく、問題が起こる条件や流れを見ながら判断できます。この仕組みは、対応する必要がない警告を減らし、本当に確認すべき問題へ時間を使いやすくするためのものです。
原因に合わせた修正案を作って再確認する
問題が実際に起こることを確認すると、Codex Securityは原因となった部分に対応する修正案を作成します。必要以上に広い範囲を書き換えるのではなく、問題の原因へ対応する小さな変更を提案することが基本です。変更する場所を絞ることで、修正によって別の動きまで変わってしまう可能性を抑えやすくなります。
作成された修正案は、GitHubのプルリクエストとして扱えます。プルリクエストとは、コードの変更内容をチームで確認し、問題がなければ取り込むための仕組みです。開発者は普段の確認手順に沿って修正内容を読み、必要に応じてテストやCodex Code Reviewを行ったうえで、反映するかどうかを決めます。
修正が取り込まれた後には、同じ問題が解消されているかをCodex Securityで再び確かめることも可能です。問題の発見だけで終わらず、修正後の確認までを一つの流れとして進められる点が大きな特徴です。
Codex Securityを無理なく導入するための進め方
Codex Securityを導入する際は、機能を有効にするだけではなく、どのリポジトリを調べるのか、誰が結果を確認するのか、誰が設定を変更できるのかを決める必要があります。ここでは、導入時に押さえておきたい三つのポイントを紹介します。
最初に調べるリポジトリを選ぶ
Codex Securityを使い始めるには、専用の画面から調査したいGitHubリポジトリをつなぎ、スキャンを有効にします。初回のスキャンでは、現在のコードだけではなく、過去の変更履歴も確認します。そのため、コードの量や変更回数が多いプロジェクトでは、最初の結果が出るまでに時間がかかる場合があります。
初回のスキャンが終わった後は、新しく追加されたコードを中心に確認するため、通常は最初よりも早く処理されます。ただし、導入直後から多くのリポジトリを対象にすると、確認する結果も一度に増えてしまいます。
OpenAIは、まず少数のリポジトリから始める方法を勧めています。GitHub Cloudを普段使っていない組織では、重要度が低いリポジトリや、本番サービスでは使っていないリポジトリから試す方法もあります。小さく始めることで、結果の見方や担当者への共有方法を確認しながら、自社に合った運用を作りやすくなります。
利用する人と管理する人を分ける
EnterpriseとEduのワークスペースでは、Codex Securityを利用できる人を、役割やグループごとに設定できます。このように、役割に応じて使える機能を分ける仕組みを「RBAC」と呼びます。難しく聞こえますが、簡単にいえば、仕事の担当に合わせて利用できる範囲を決める方法です。
Codex Securityを利用するには、ワークスペースでCodex CloudとCodex Securityの両方を有効にする必要があります。また、スキャン対象の追加や設定変更まで行う人には、通常の利用権限とは別に管理権限を設定します。
検出結果を見る人と、設定を変更できる人を分けることで、意図しない変更を防ぎやすくなると考えられます。社内で使っているグループ管理と連携して、特定の部署や担当チームだけに利用を認めることも可能です。導入前には、誰がどこまで操作できるのかを一覧にし、必要以上に広い権限が付いていないかを確認することが大切です。
少人数の確認チームから始める
Codex Securityの導入直後は、検出された問題を誰が確認するのか、開発担当者へどのように伝えるのか、どの問題を先に直すのかといった流れが決まっていない場合があります。最初から多くの部署やリポジトリへ広げると、確認方法がそろわず、結果を十分に活用できなくなる可能性があります。
OpenAIは、少数のリポジトリと専任の確認チームから始めることを勧めています。対象を絞ることで、一つの問題が見つかってから修正されるまでの流れを確認し、社内の役割分担や連絡方法を整えやすくなります。
提案された修正案については、Codex Securityが作ったものだからといって、そのまま取り込むのではなく、普段と同じように人が内容を確認します。必要に応じて動作テストやCodex Code Reviewも行い、別の不具合が起こらないかを確かめます。AI専用の特別な流れを作るよりも、普段の開発手順へ組み込む方が、無理なく続けやすい運用になると考えられます。
検出結果を修正の優先順位につなげる仕組み
Codex Securityが示す結果には、問題が見つかった場所だけではなく、攻撃者が操作できる情報がどこから入り、どの処理を通って重要なデータや機能へ届く可能性があるのかもまとめられます。この一連の流れは「攻撃経路」と呼ばれます。
たとえば、利用者が入力した文字が正しく確認されないまま処理され、管理者向けの機能や個人情報へ影響する可能性がある場合には、入口から問題が起こる場所までの流れが示されます。開発者はコードの一部分だけではなく、問題がサービス全体へどのようにつながるのかを確認できます。
また、問題が起こる可能性と、起きた場合の影響の大きさも評価されます。どのような前提で判断されたのかも確認できるため、表示された数字だけを見るのではなく、自社の使い方に合った評価かを考えられます。
さらに、問題を再現した際の結果や実行内容、確認に使われた記録も残ります。セキュリティ担当者と開発者が同じ情報を見ながら、すぐに直すべき問題なのか、条件を確認してから対応する問題なのかを話し合いやすくなります。
Codex Securityの役割は、できるだけ多くの警告を出すことではありません。問題の起こり方や影響を分かりやすくし、限られた時間の中で、どの問題から対応するべきかを決めやすくすることにあります。
今後の展望
Codex Securityは、コードの問題を見つけるだけではなく、設計の見直しや社内教育、オープンソースとの協力にも役立つ可能性があります。ここからは、現在公開されている機能や取り組みをもとに、今後考えられる三つの活用方法を紹介します。
脅威モデルを設計時の確認にも活用する
現在のCodex Securityは、コードや変更履歴を確認し、攻撃の入口、守るべき情報、注意が必要な処理などを脅威モデルとしてまとめます。この脅威モデルは表示するだけでなく、開発チームが内容を編集できます。実際のサービスの使い方と違う部分があれば、人が前提を直せる仕組みです。
今後は、この脅威モデルを問題が起きた後に見る資料としてだけではなく、新しい機能を作る前の確認にも活用できると考えられます。たとえば、決済機能を追加する場合には、カード情報や購入履歴をどこで扱うのかを整理し、外部から入力された情報が重要な処理へ届く可能性を事前に確認できます。
ログイン方法を変える場合には、誰がどこまで操作できるのかを見直し、新しい仕組みが別の機能へ思わぬ影響を与えないかを考える材料にもなります。開発後に問題を探すだけではなく、設計の段階から危険が生まれにくい形を考える使い方です。
また、脅威モデルを定期的に更新すれば、サービスの変化を記録する「安全面の地図」としても使える可能性があります。新しく参加した開発者も、その地図を見ることで、どの情報を特に守る必要があるのか、どの機能を変更すると影響が広がりやすいのかを理解しやすくなります。
検出結果を社内の学びとして残す
Codex Securityでは、問題が見つかった場所だけではなく、どのような流れで問題が起こるのか、どのような条件で再現できたのか、どの部分を直せばよいのかが示されます。こうした情報は、その場の修正だけに使うのではなく、社内で同じ問題を繰り返さないための学びとして残せる可能性があります。
たとえば、利用者が入力した情報の確認不足が何度も見つかった場合には、入力内容を確認する共通の決まりを作れます。ログインや権限に関する問題が続く場合には、設計時に確認する項目を追加したり、コードレビューで見るポイントをまとめたりできます。
検出結果をそのまま保存するだけではなく、「何が原因だったのか」「なぜ見落としたのか」「今後はどこを確認するのか」を短く整理すれば、新しい開発者向けの研修にも活用できます。実際に自社のコードで起きた問題をもとに学ぶため、一般的な説明だけを読むよりも、仕事とのつながりを理解しやすくなるでしょう。
さらに、修正案を採用しなかった場合にも、その理由を残すことが大切です。サービスの使い方を考えると危険が小さいと判断したのか、別の方法で対応したのかを記録しておけば、後から同じ問題が出たときに判断の背景を確認できます。
このような記録が増えると、セキュリティ担当者だけが持っていた知識を、開発チーム全体で共有しやすくなります。Codex Securityは自動で最終判断を行うものではありませんが、問題を話し合うための材料をそろえる役割を担えます。検出と修正を繰り返す中で得た情報を社内のルールや教育へつなげることができれば、問題が起きてから直すだけでなく、同じ問題を作りにくい開発体制へ近づくと考えられます。これは、現在の検証記録や修正案をもとにした今後の運用についての考察です。
オープンソースの安全性向上に役立てる
オープンソースとは、プログラムの中身が公開され、多くの開発者や企業が利用・改善しているソフトウェアです。現在のサービスや製品は、数多くのオープンソースを組み合わせて作られています。そのため、広く使われている一つのソフトウェアに問題が見つかると、多くの製品や利用者へ影響が広がる可能性があります。
OpenAIは、依存度の高いオープンソースのリポジトリをCodex Securityで調査し、影響の大きい問題を管理者へ共有する取り組みを行っています。2026年3月6日の公式発表では、OpenSSH、GnuTLS、GOGS、PHP、Chromiumなどのプロジェクトへ問題を報告したことが紹介されました。また、vLLMなどのプロジェクトが、普段の開発作業の中でCodex Securityを活用した事例も示されています。
現在の「Codex for Open Source」では、選ばれたオープンソースの管理者に対し、Codexを含むChatGPT Proを6か月間提供しています。条件を満たすリポジトリについては、Codex Securityを利用できる可能性もあります。コードの確認や日々の管理作業に使えるAPIクレジットも提供対象に含まれています。
今後は、企業が自社で作ったコードだけを守るのではなく、自社サービスで使っている重要なオープンソースの安全性向上へ協力する動きが広がると考えられます。問題を見つけた企業が、再現方法や影響の範囲、修正案を開発元へ伝えれば、修正までの負担を減らせる可能性があります。
ただし、まだ修正されていない問題を広く公開すると、悪用される危険があります。問題を見つけた場合には、開発元へ先に連絡し、修正や公開の時期を相談する必要があります。Codex Securityによって質の高い情報を用意し、人が責任を持って共有する流れを作ることが重要です。
