OpenAI、Codex Security研究プレビューを公開 文脈理解型application securityレビューを狙う

Original: Codex Security—our application security agent—is now in research preview. https://openai.com/index/codex-security-now-in-research-preview/ View original →

Read in other languages: 한국어English
LLM Mar 19, 2026 By Insights AI 1 min read Source

XでOpenAIが発表したこと

2026年3月6日、OpenAIはCodex Securityがresearch previewに入ったと発表した。投稿自体は短いが、リンク先の公式ページでの位置づけは明確だ。repositoryの文脈を理解し、可能性の高い脆弱性を検証し、一般的なAIセキュリティツールやstatic analysisより少ないnoiseでpatchまで提案するapplication security agentという説明である。

公式ページが補った内容

OpenAIによると、Codex Securityは以前はAardvarkとして運用され、昨年に少数顧客向けprivate betaとして始まった。初期の内部運用では実際のSSRFや重大なcross-tenant authentication vulnerabilityなどを見つけ、セキュリティチームが数時間以内に修正したという。ベータ期間中には精度面も大きく改善したと説明している。

  • あるrepositoryではscan noiseが初期導入時比で84%減少したとされる。
  • severityの過大報告率は90%以上下がったという。
  • false positive rateもrepository全体で50%以上低下したと説明されている。
  • 直近30日間でbeta cohortの120万件超のcommitを走査し、792件のcritical10,561件のhigh-severity findingを特定したという。

OpenAIはworkflowを3段階で説明する。まずsystem向けのeditable threat modelを作り、次に文脈やsandbox環境で問題を検証し、最後にsystemの振る舞いと整合するpatchを提案する。さらに、このpreviewはChatGPT Pro、Enterprise、Business、Edu向けにCodex webで展開され、最初の1か月は無料利用になるとしている。

なぜ重要か

重要なのは、AI security reviewをgenericなSAST風のnoiseから、文脈理解型のapplication security triageへ移そうとしている点だ。agentic developmentツールがコード生成を加速するほど、security teamはfindingが正確で実行可能でなければ新しいボトルネックになりやすい。OpenAIはCodex Securityを、その経済性を変える道具として打ち出している。

validationとpatchingの主張が実際のrepositoryでも再現されるなら、セキュリティレビューは単なるキュー処理ではなく、より狙いを定めた調査に近づく可能性がある。もちろん多様なコードベースでこの精度を維持できるかは今後の検証次第だが、方向性は明確だ。application securityは事後スキャンではなく、agent workflowの中核要素になりつつある。

出典: OpenAI X投稿 · OpenAI Codex Security公式ページ

Share: Long

Related Articles

LLM sources.twitter 2d ago 1 min read

OpenAIDevsは2026年3月16日、Codexでsubagentsが利用可能になったと発表した。main contextを軽く保ちながらspecialized agentへ仕事を並列分散し、各threadを個別にsteerできるようにする更新で、公式ドキュメントにはPR reviewやCSV batch fan-outの運用例もすでに載っている。

LLM 1d ago 1 min read

OpenAIは、Codex Security を事前生成された SAST レポートの triage 製品としてではなく、repository の実際の挙動と trust boundary を理解したうえで仮説を検証する agent として設計したと説明した。重要な脆弱性は source-to-sink の追跡だけでは捉え切れず、security invariant が本当に成立しているかを確かめる必要があるという立場だ。

Comments (0)

No comments yet. Be the first to comment!

Leave a Comment

© 2026 Insights. All rights reserved.