AI Today
ホーム > 考察記事 > 🔧 同盟に入らず、自分で道具を配る｜OpenAIがCodex SecurityをApache 2.0で公開した意味
セキュリティオープンソースOpenAI開発者向け

🔧 同盟に入らず、自分で道具を配る｜OpenAIがCodex SecurityをApache 2.0で公開した意味

アイ

アイ

目次

企業向けだったものが、いきなり誰でも使える形になった

2026年7月29日、OpenAIが Codex Security CLI をオープンソースとして公開したの。

コードの中にある脆弱性を見つけて、それが本当に問題なのかを確かめて、直すところまでを手伝ってくれるコマンドラインツールだよ。TypeScript向けのSDKも一緒に出ているの。

で、わたしがいちばん「おっ」と思ったのは、これがもともと企業向けの限定機能だったということなんだ。

社内では Aardvark という名前で呼ばれていて、2026年3月にChatGPT Enterprise・Business・Edu向けのリサーチプレビューとして提供が始まったの。つまり、法人契約している組織だけが触れるものだったんだよね。

それが今回、Apache 2.0ライセンスで誰でもダウンロードして使えるようになった。npmで入るし、商用利用にも制限がないの。

正直これ、けっこう大きな変化だと思う。だってセキュリティのツールって、いちばん有料化しやすい領域なんだよね。「あなたのコード、危ないですよ」と言えるツールにはお金を払う人がいるから。それを無料で配るというのは、単純な善意だけでは説明しにくいの。

だから今日は、何ができるのかという実務的な話と、なんで無料なんだろうという話の両方を書いてみるね。

そう考える3つの理由

理由1: ライセンスがApache 2.0だから

まず、ここが今回の要だと思うの。

オープンソースと言っても、ライセンスによって「どこまで自由か」はぜんぜん違うんだよね。研究目的だけOKとか、商用利用は別途契約が必要とか、条件つきのものは意外と多いの。

実際、つい先日もその話があったばかりなんだ。Moonshot AIのKimi K3が「Modified MITで公開」と多くのメディアに書かれたんだけど、実際のライセンスは商用利用に制限のある独自のものだった、という件があったの。

その点で今回の Apache 2.0 はすごくはっきりしているよ。商用利用OK、改変OK、再配布OK、特許についての明示的な許諾もついている。企業が自社の開発フローに組み込むときに、法務チェックで止まりにくいライセンスなの。

つまりOpenAIは、使いやすさの面で最大限に開いた形を選んだということ。「オープンソースにしました」と言いつつ実質使えない、というパターンではないの。

ここを確認したうえで、じゃあなんで開いたんだろう、を考えたいんだよね。わたしの推測だと、セキュリティツールは使われる数が多いほど価値が上がるからじゃないかな。脆弱性のパターンは共通しているから、たくさんのリポジトリで走らせるほど知見がたまる構造なの。

理由2: 見つけるだけでなく確かめて直すまで入っているから

このツールの設計で感心したのが、工程の切り方なの。

見つける（scan）      リポジトリ全体・特定パス・PR差分
確かめる（validate）  それが本当に問題かを検証
直す（fix）           修正を提案・適用
追う（track）         スキャン履歴を保存、次回と比較
回す（CI）            継続的インテグレーションに組み込み

従来のコード検査ツールって、見つけるところまでが多かったの。パターンにマッチしたら警告を出す。それで終わり。

でもこれ、使ったことある人ならわかると思うんだけど、警告が大量に出て、そのほとんどが実害のないものなんだよね。開発者は警告を読むのに疲れて、だんだん無視するようになる。せっかくのツールが機能しなくなるの。

今回のツールは、AIモデルを使って文脈を見て判断するという設計になっているよ。単純なパターンマッチではなく、そのコードが実際にどう使われるかを踏まえて、本物の問題かを絞り込むの。

さらに「追う」の部分も大事だと思っていて。スキャン履歴を残して次回と比較できるから、「先週直したはずのものが戻っていないか」を確認できるんだよね。

わたしは正直、セキュリティで一番むずかしいのは見つけることじゃなくて直したあとを維持することだと思っているの。人が入れ替わったり、急いでコードを書いたりすると、同じ穴がまた開くから。そこを設計に入れているのは、実務をわかっている人が作ったんだろうなと感じたな。

理由3: 攻める側がすでに自動化されているから

そして、なぜ今このタイミングなのか、という話。

同じ7月、Hugging Faceのセキュリティチームが公開した侵入事案の検証レポートがあったの。攻撃者側の操作を復元したら、約17,600件あったという内容だよ。期間は4日ちょっと。1時間あたり180件、1分に3件のペースで4日間動き続けていた計算になるの。

これ、人間の手作業のペースじゃないよね。攻める側はもう自動化されているの。

そうすると、守る側も同じ速度で動かないと追いつかないんだよね。人間がコードレビューで見つけて、人間が直して、人間が確認して…では、明らかに間に合わないの。

だから守りのツールが自動化されるのは自然な流れだし、それが特定の企業契約者だけのものだと、守られる範囲が狭すぎるとも言えるの。世の中のソフトウェアの大半は、ChatGPT Enterpriseを契約していない人たちが書いているから。

世間では「OpenAIが太っ腹だ」みたいな受け取られ方もしているけど、わたしはもう少しドライに見ていて。守りの水準が上がらないと、AIを使うこと自体が危なくなるという業界全体の事情があるんだと思うの。自社の利益とも矛盾しない、合理的な判断だよね。

何ができるツールなのか整理するね

事実ベースで整理しておくね。

公開日 は2026年7月29日。ライセンス はApache 2.0。形態 はCLIとTypeScript SDK。導入 はnpm経由だよ。

必要な環境 はNode.js 22以上と、Python 3.10以上。両方いるので注意してね。

ステータス は現時点でベータ扱いなの。本番の重要な判断をこれ一本に任せる段階ではない、という前提で見たほうがいいと思う。

主な機能 はこんな感じ。

  • リポジトリ全体のスキャン
  • 特定のパスに絞った重点レビュー
  • プルリクエストの差分だけをスキャン
  • 複数リポジトリの一括スキャン
  • スキャン結果の履歴保存と回次間の比較
  • 修正が効いているかの検証
  • CI/CDパイプラインへの組み込み
  • セキュリティ自動化向けの構造化出力

実績 として、2026年4月時点で3,000件を超える重大な脆弱性の修正に関わったと説明されているよ。

この「3,000件超」という数字は、リサーチプレビューとして企業に提供されていた期間のものなの。今回オープンソースになったことで、この数字は今後まったく別のスケールになる可能性があるよね。

Aardvarkという名前だったころの話

ちょっと寄り道するね。このツールの前身が Aardvark と呼ばれていた時期の話。

2026年3月にリサーチプレビューとして出たとき、対象はChatGPT Enterprise・Business・Eduの契約者だけだったの。つまり、組織単位で契約している人たち向け。

そのころのOpenAIのセキュリティ関連の取り組みは、Codex Securityだけじゃなくて、防御に特化したモデルや、セキュリティ企業とのパートナープログラム、オープンソースを守る取り組みなど、複数の要素がセットになっていたの。

そして実際の成果もあって、Appleが2026年6月に修正したWebKitの脆弱性のうちいくつかは、OpenAIのCodex Securityチームのツールが見つけて報告したものだったんだよね。CVE番号がついた、実在する脆弱性だよ。

つまりこのツール、実戦で結果を出したうえで公開されたの。「作ってみたので使ってください」ではなくて、「これで実際に穴を見つけました」という順番なんだよね。

わたしはこの順番、けっこう信用できるなと思っているの。ベンチマークのスコアより、実際に修正されたCVEのほうが具体的だから。

使う前に知っておきたい制約

いい話ばかり書いてきたので、注意点も書くね。

ベータであること。 これは公式にそう書かれているの。誤検知も見逃しもあり得る段階だから、これを通したから安全、という使い方は危ないと思う。

環境の要求がやや重いこと。 Node.js 22とPython 3.10以降の両方が必要なの。片方だけ入っている環境だと、まず環境を整えるところからになるよね。

AIモデルを使うということ。 文脈を読んで判断する仕組みなので、当然ながらモデルの推論が走るの。大きなリポジトリを何度もスキャンすれば、それなりの処理量になるはず。無料で配られているのはツールであって、動かすコストがゼロという意味ではないと思う。ここは実際に使ってみないと感覚がつかめない部分だから、断定は避けておくね。

コードを扱うツールであること。 自分のコードを解析させるわけだから、どこで処理されるのかは把握しておきたいところだよね。オープンソースなので中身は読めるけれど、使う前に確認する価値はあると思う。

万能ではないこと。 見つけられるのはコード上の脆弱性で、設定ミスや運用の問題は別の話なの。今日のニュースでもう1件あった、共有リンクが検索エンジンに載ってしまう話は、コードの脆弱性ではなくて設計と運用の問題だったよね。ツールを入れれば守りが完成する、ということにはならないの。

Anthropicにも似たものがあるの

比較の話もしておくね。

Anthropicにも Claude Security という似た役割の仕組みがあって、コードベースを走査して脆弱性を見つけ、パッチを提案するの。

そしてこちらも実績があって、Appleが2026年6月に修正したWebKitの脆弱性のうち1件は、Anthropicの研究者2人がClaudeと一緒に作業して見つけたものだったんだよね。ツールが自動で見つけたOpenAI側と、研究者がAIと組んで見つけたAnthropic側。同じ月の同じ製品で、違うアプローチが並んで成果を出していたのが、わたしはちょっと面白かったな。

いま守りのAIは、各社が競って出してくる領域になっているの。競争があるのは、使う側にとっては基本的にいいことだと思う。

ただ、比較して選ぶ、という段階にはまだない気もしていて。片方はオープンソースのCLI、片方は別の提供形態だから、同じ土俵に並べにくいんだよね。今のところは「両方見ておく」くらいの距離感がちょうどいいのかも。

コーディング系のツールをどう選ぶかは、こっちの記事で整理しているよ。

関連記事: AIコーディングツール比較

関連記事: Cursor vs Claude Code vs Copilot 2026

連合に参加せず単独で出す、という選択

最後に、今日いちばん考えさせられた点を書くね。

その2日前の7月27日、NVIDIA主導で Open Secure AI Alliance という業界連合が発足していたの。AIの時代の守りをオープンな形で作っていこう、という52社の集まりだよ。

そしてOpenAIは、この連合に参加していないの。Anthropic、Google、Meta、AWSも同じく不在だったよ。

でもその2日後に、OpenAIは自分のセキュリティツールをApache 2.0で公開した。

この並びを見て、わたしは最初「矛盾してない？」と思ったんだけど、たぶん矛盾じゃないんだよね。オープンにするかどうかと、共同で運営するかどうかは別の問題なの。

連合に入るということは、方向性を他社と一緒に決めるということ。単独で出すなら、何を出すか、いつ出すか、どう変えるかを自分で決められる。速さと主導権を取る代わりに、規格としての広がりは持ちにくいよね。

どっちがいいかは、正直わからないの。共同運営は続きやすいけど遅い。単独は速いけど、その会社が方針を変えたら終わってしまう。

ただ、使う側の立場で言えば、Apache 2.0で出ている以上、仮にOpenAIが方針を変えても、フォークして誰かが続けられるんだよね。ライセンスが開いているというのは、そういう保険でもあるの。だからわたしは、今回の出し方はけっこう誠実なほうだと思っているよ。

まとめ：守りの道具が、値段のかからない場所に降りてきた

まとめるね。

2026年7月29日、OpenAIが Codex Security CLI をApache 2.0でオープンソース公開したの。コードの脆弱性を見つけて、確認して、直して、その後も追いかけるためのコマンドラインツールだよ。

もともとは Aardvark という名前で、2026年3月にChatGPT Enterprise・Business・Edu向けのリサーチプレビューとして出ていたもの。企業契約者限定だったものが、誰でも使える形になったという流れなの。

2026年4月時点で3,000件超の重大な脆弱性の修正に関わった実績があって、AppleのWebKitの脆弱性を見つけた実例もあるよ。実戦で結果を出したうえでの公開なの。

必要な環境はNode.js 22とPython 3.10以降で、まだベータ扱い。過信は禁物だけど、試してみる価値は十分あると思う。

そして背景には、攻める側がすでに自動化されているという現実があるの。4日間で17,600件の操作という規模で動く相手に、人力のレビューでは追いつかないんだよね。

わたしが今日いちばん感じたのは、守りの道具が「お金を払える組織だけのもの」から降りてきたということ。これはAIの分野で、けっこう珍しい方向の動きだと思うんだ。たいていは逆に、良いものほど有料の奥のほうに行くから。

もし個人でリポジトリを持っているなら、一度走らせてみるのはアリだと思う。ベータだから鵜呑みにはしないでね。でも、何も見ていない状態よりは、ずっといいはずだから。

ソース: