Codexにセキュリティ調査を任せる前に決めること

3行まとめ

Scope

対象。

Permission

権限。

Finding

証跡。

Patch

最小修正。

Review

承認。

securityでは、発見より根拠と安全な修正経路が重要です。

• Codexにsecurity scanやPR差分reviewを任せる時は、authorized repository、read-only調査、証跡、severity、人間reviewを先に決めます。
• deep scan、PR diff review、vulnerability backlog remediation、dependency incident triageを同じ依頼に混ぜないようにします。
• 修正へ進む時は、最小差分、regression evidence、code ownerとsecurity ownerのreviewをセットにします。

この記事では、OpenAI公式のCodex use cases、Codex app Features、Worktrees、Permissions、AGENTS.md docsを確認し、2026年6月1日時点の情報として整理しています。Codex app、security系use case、Worktrees、権限設定は更新され得るため、導入前に最新docsと自社のsecurity policyを確認してください。

この記事でわかること

Task

scanかreviewか。

Repo

許可対象。

Evidence

根拠。

Owner

確認者。

authorized repositoryだけを対象にし、read-only調査から始めます。

• Codexへ任せるsecurity taskの分け方
• authorized repositoryと権限の固定方法
• findingに必要な証跡の型
• 修正へ進む条件と最小差分の考え方
• PR reviewと人間承認を入れる理由
• 初週に試す低riskな導入例

OpenAIのCodex use casesでは、authorized repositoryを深く検索してplausible vulnerabilitiesを探すdeep security scan、PRやlocal diffのsecurity regression review、vulnerability backlogのminimal fixes、public package advisoryからrepo-audit planを作る用途が紹介されています。

ただし、security領域では「AIが見つけた」だけでは足りません。根拠、到達経路、影響範囲、不確実性、修正案、regression evidence、人間reviewが必要です。Codexはsecurity作業を補助できますが、最終判断や承認を置き換えるものではありません。

Codexの権限や外部接続の整理は、公開済み記事のCodex設定を増やす前に決めることでも扱っています。この記事ではsecurity taskへ絞ります。

前提知識

項目	内容	見方
Use cases		security用途。
Features		app機能。
Worktrees		作業場所。
Permissions		権限。
AGENTS.md		作業契約。

security taskは、作業場所と権限を特に慎重に確認します。

OpenAI公式のCodex use casesでは、Run a deep security scan、Scan code changes for security、Remediate a vulnerability backlog、Audit dependency incidentsといったsecurity系の用途が示されています。どれも、authorized repositoryやreviewed findings、regression evidenceのような前提を置いています。

Codex app Featuresでは、Codex appがproject、thread、worktree、skillsなどを扱う開発作業の入口として説明されています。Worktrees docsでは、Git repositoryで独立した作業場所を作り、background作業やHandoffへ使えることが説明されています。

Permissions docsでは、filesystemやnetworkの境界をprofileとして決める考え方が説明されています。security調査では、読むだけか、変更してよいか、外部情報を参照してよいかを特に慎重に分けます。

公式情報で確認する範囲

確認先	見ること
Codex use cases	security scan、PR diff review、backlog remediation
Codex app Features	project、thread、worktree
Worktrees	独立作業、Handoff
Permissions	read/write/networkの境界
AGENTS.md	repo固有の作業契約

注意点

この記事は、Codexに未承認targetを攻撃させる話ではありません。対象は、自社が調査権限を持つrepositoryやPR、local diff、依存関係情報に限定します。

また、security findingは誤検知もあります。Codexの指摘を脆弱性確定として扱わず、再現性、影響範囲、悪用可能性、修正の副作用を人間が確認します。

まずsecurity taskを分ける

項目	内容	見方
Deep scan		広い調査。
PR diff		差分review。
Backlog		既知finding。
Incident		依存incident。

scan、review、remediationを同じ依頼にしないようにします。

Codexへ渡すsecurity taskは、目的ごとに分けます。

task	目的	成果物
deep scan	repository全体から怪しい箇所を探す	finding候補
PR diff review	変更差分のsecurity regressionを見る	PR commentやfindings
vulnerability backlog	既知findingを直す	最小修正PR
dependency incident	advisoryから影響を調べる	audit plan

deep scan

deep scanは、広い調査です。authorization、input validation、secret handling、SSRF、XSS、SQL injection、auth bypass、unsafe deserializationなど、観点を絞って調べます。

ただし、広いscanほど誤検知も増えます。Codexには、finding候補として返させ、すぐ修正へ進めないようにします。

PR diff review

PR diff reviewは、差分に絞ったsecurity reviewです。変更されたfile、data flow、permission change、external call、secret handling、logging、error handlingを見る用途に向いています。

既存記事のCodexレビューをGitHubに入れる前に決めることでは、GitHub review全体の運用を整理しています。security reviewでは、review観点と承認者をさらに明確にします。

vulnerability backlog

vulnerability backlogは、既にreviewされたfindingを修正する作業です。ここでは「見つける」より「最小差分で直し、regression evidenceを残す」ことが重要です。

backlog修正へ進む条件

条件	見ること
findingがreview済み	誤検知でない
影響範囲が分かる	どこを直すか明確
testがある	回帰確認できる
ownerがいる	承認者がいる
rollbackがある	失敗時に戻せる

対象repoと権限を固定する

Authorized

許可repo。

Read-only

読むだけ。

Scoped write

限定修正。

Network

必要先だけ。

未承認の外部対象や本番systemを勝手に調査対象にしません。

security taskでは、対象repoと権限を最初に固定します。

項目	書くこと
repo	調査許可があるrepository
branch	main、PR branch、release branch
scope	対象directoryやfile
permission	read-only、scoped write
network	advisory確認など必要なdomain
out of scope	本番system、外部target、secret

authorized repo

対象は、調査権限があるrepositoryに限定します。public repositoryでも、自分が攻撃的な検証をしてよいとは限りません。Codexには、code reading、static analysis、PR diff review、dependency metadata確認の範囲で依頼します。

外部systemへのアクセス、実payload送信、本番endpointへの試行、credentialの利用は、別の承認と手順が必要です。

read-onlyから始める

最初はread-onlyにします。finding候補を出し、根拠と不確実性を整理してから、修正taskを切ります。

Codexに「調査して必要なら直して」と頼むと、調査と修正の境界が曖昧になります。securityでは、調査、triage、修正、reviewを分けます。

networkとsecret

security調査では、networkとsecretの扱いを特に注意します。

対象	扱い
advisory page	必要なら参照
package registry	version確認に限定
production endpoint	原則触らない
credentials	渡さない
logs	tokenや個人情報を除く

findingの証跡を固定する

項目	内容	見方
Location		file/line。
Path		到達経路。
Impact		影響。
Evidence		根拠。
Uncertain		未確認。

AIの指摘は、根拠と不確実性を一緒に残します。

findingには、証跡が必要です。

項目	内容
location	file、function、line
data flow	inputからsinkまで
impact	何が起きる可能性
precondition	必要な条件
evidence	code、test、docs、advisory
uncertainty	未確認、仮説
suggested next	triage、test、fix、dismiss

根拠

根拠は、file/line、関数名、call path、package version、advisory URL、test resultなどで示します。単に「危険です」ではなく、「この入力がこのsinkに入り、ここでescapeされていない可能性がある」と書ける形にします。

severity

severityはAIだけで決めません。CVSS、Exploitability、影響範囲、認証要否、外部露出、データ種別、補償controlを見ます。

severity判断	見ること
exploitability	実行可能か
exposure	外部から届くか
impact	機密性、完全性、可用性
scope	影響するtenantやuser
control	既存の防御

修正へ進む条件を決める

1. 1Triage

   分類。

2. 2Confirm

   確認。

3. 3Patch

   最小修正。

4. 4Test

   回帰確認。

5. 5Review

   承認。

修正は最小差分とregression evidenceをセットにします。

security修正は、最小差分で進めます。大きなrefactorと混ぜると、reviewしにくくなります。

修正条件	内容
confirmed	findingが確認済み
minimal	変更範囲が小さい
testable	regression testがある
reviewed	ownerが見る
deployable	release手順がある

最小差分

最小差分とは、findingを閉じるために必要な変更だけを入れることです。周辺整理、style変更、大きな設計変更は別PRへ分けます。

Codexには、対象file、変更してよい範囲、追加すべきtest、触らない範囲を渡します。

regression evidence

regression evidenceは、修正が効いていることと、壊していないことの証跡です。unit test、integration test、static analysis、manual QA、dependency audit resultなどを使います。

修正後に残すもの

証跡	理由
finding ID	何を閉じたか
diff summary	何を変えたか
test result	回帰確認
residual risk	残る不確実性
reviewer	誰が見たか

PR reviewと人間承認を入れる

項目	内容	見方
Code owner		実装。
Security		risk。
QA		回帰。
Release		反映。

security changeは、Codexだけで完了判定しないようにします。

security changeは、Codexだけで完了判定しません。code owner、security owner、QA、release ownerのどこかで人間reviewを入れます。

reviewer	見ること
code owner	実装が妥当か
security owner	riskが下がったか
QA	regressionがないか
release owner	反映順とrollback

code owner

code ownerは、変更が既存設計に合っているかを見ます。security fixでも、設計を壊すと別のbugを生みます。

security owner

security ownerは、findingの真偽、severity、修正の十分性、残riskを見ます。特に外部公開や顧客影響がある場合、人間承認は省かないようにします。

導入初週の進め方

1. 1日目

   read-only scan。

2. 2日目

   PR diff review。

3. 3日目

   finding型。

4. 5日目

   小修正。

5. 7日目

   owner確認。

最初は検証しやすいPR差分と既知findingから始めます。

最初の1週間は、低riskなsecurity taskから始めます。

日	やること	見ること
1日目	read-onlyでPR diffを見る	finding型が使えるか
2日目	既知findingを1件triage	誤検知を分けられるか
3日目	証跡テンプレートを固定	reviewerが読めるか
5日目	小さな修正PRを作る	最小差分か
7日目	owner reviewを入れる	承認flowが回るか

初週の成功条件は、たくさん脆弱性を見つけることではありません。根拠付きのfindingを作り、安全な修正とreviewへつなげられることです。

小さく始める例

task	理由
PR diffのlogging review	範囲が狭い
dependency advisoryの影響確認	根拠が明確
secretらしき文字列の棚卸し	read-onlyで始められる
auth middlewareのdocs確認	実装とdocsを照合できる
既知findingのtest追加	修正前に証拠を作れる

FAQ

Pentest?

別扱い。

Auto fix?

最小差分。

Severity?

人間確認。

Prod?

承認必須。

迷ったら、許可対象と修正責任者へ戻ります。

Codexにpenetration testを任せてよいですか？

この記事の範囲では扱いません。未承認targetへの攻撃的検証は行いません。authorized repositoryのcode reading、PR diff review、dependency incident triageに限定します。

AIのfindingはそのまま脆弱性として扱えますか？

扱えません。根拠、到達条件、影響範囲、再現性、既存control、人間reviewを通して判断します。

すぐ修正まで任せてよいですか？

低riskでscopeが明確な既知findingなら可能な場合があります。ただし、調査、triage、修正、reviewは分けて記録します。

security fixのPRは普通のPRと何が違いますか？

finding ID、影響範囲、最小差分、regression evidence、残risk、security owner reviewを明確にします。

外部advisoryを見に行ってよいですか？

必要な場合は、許可されたdomainに限定して参照します。package registryや公式advisoryを確認し、取得した情報を根拠として残します。

次に読むなら

参照した主な情報源

• Codex use cases – OpenAI Developers
• Codex app features – OpenAI Developers
• Worktrees – Codex app – OpenAI Developers
• Permissions – Codex – OpenAI Developers
• Custom instructions with AGENTS.md – Codex – OpenAI Developers

更新履歴

1. 2026年6月1日

   OpenAI公式Codex docsを確認して初版を作成しました。

導入時には最新のCodex use casesとsecurity運用を確認してください。

• 2026年6月1日: OpenAI公式Codex use cases、Codex app docs、Worktrees、Permissions、AGENTS.mdを確認し、初版を作成しました。