CodexのAccess Tokenを使う方法｜CI・定期実行で安全に動かす手順

本記事を読めば、CodexのAccess Tokenの用途と管理方法がわかり、CIや定期実行で非対話のCodex利用を安全に始められるようになります。

AIzen株式会社は、AIエージェントを業務システム開発や社内運用へ組み込む際、認証情報の管理と監査設計を重視しています。

本記事では、Codex Access TokenをAPIキーと混同せず、Business・Enterprise環境で安全に扱う考え方を整理します。

CodexのAccess Tokenとは

CodexのAccess Tokenは、信頼できる自動化環境からCodex localを非対話で動かすための認証情報です。OpenAI公式ドキュメントでは、スクリプト、スケジュールジョブ、CI runnerなどが、ブラウザサインインなしで繰り返しCodexを実行する用途に使うものとして説明されています。

通常のAPIキーとは目的が異なり、ChatGPTワークスペースのIDに紐づくCodex実行用の認証情報として扱う点が重要です。

ChatGPTワークスペースIDでの実行

Access Tokenを使ったCodex実行は、トークンを作成したChatGPTユーザーとワークスペースに紐づきます。つまり、ワークスペースの管理下にあるIDでCodex localを動かす設計です。

情シス・DX担当の視点では、この点が大きな意味を持ちます。個人のPCで都度ログインして使うだけならブラウザサインインで足りますが、CIや定期実行に組み込むなら、誰の権限で実行され、どのワークスペースに記録されるのかを管理する必要があります。Access Tokenは、その管理点を作るための仕組みです。

CI・定期実行での利用範囲

Access Tokenが向くのは、繰り返し実行される非対話のCodexタスクです。たとえば、毎朝のリポジトリ診断、定期的なドキュメント差分チェック、CI上でのリスク要約、内部ツールのコード品質確認などが該当します。公式ドキュメントでも、codex exec を信頼できる自動化から実行する用途が挙げられています。

一方で、Access Tokenはどこでも使ってよいものではありません。公開CI、forkされたPull Request、共有端末、不特定多数が触れるrunnerでは、トークンがログや環境変数から露出する可能性があります。Access Tokenは、信頼できるrunnerと秘密管理がある環境だけで使うという前提を置くべきです。

ブラウザサインインとの違い

ブラウザサインインは、人が手元でCodexを使うための認証です。CIやcronでは人が毎回ログインできないため、Access Tokenを使って環境変数 CODEX_ACCESS_TOKEN などからCodexを起動します。

ただし、便利になるほど管理責任も増えます。Access Tokenは自動実行されるため、失効、ローテーション、保管場所、実行ログの確認まで決めておきます。

Access Tokenを発行する方法

Access Tokenは、ChatGPTの管理コンソール側で作成・管理します。公式ドキュメントでは、Codex access tokensはChatGPT BusinessおよびEnterpriseワークスペースでサポートされているとされています。提供条件や画面名称は変わる可能性があるため、実際の運用前には管理コンソールと公式ドキュメントで最新状態を確認してください。

Business・Enterpriseでの対応

Codex Access Tokenは、個人利用のAPIキーとは異なり、Business・Enterpriseのワークスペース管理と結びつく機能です。利用には、ワークスペース側でCodex LocalやAccess Tokenの利用許可が有効になっている必要があります。管理者が全員に開放するのか、特定ロールやグループだけに許可するのかを決めます。

情シス部門としては、まず対象ワークスペース、対象ユーザー、対象リポジトリ、対象runnerを整理します。全社へ一斉に開放するより、PoC用の開発チームやサービスオーナーに限定し、運用ログとセキュリティレビューを見ながら広げるほうが安全です。

管理コンソールでの作成

Access Tokenは、管理コンソールのAccess tokensページで名前と有効期限を指定して作成します。公式ドキュメントでは、release-ci や nightly-docs-check のように用途がわかる名前を付ける例が示されています。作成後に表示されるトークンは再表示できないため、その場でシークレット管理へ保存します。

作成時には、トークン名、作成者、利用するworkflowまたはrunner、保存先、有効期限、ローテーション予定日、失効時の連絡先を台帳化します。トークン名は人名ではなく、業務・環境・用途で付けるのが管理しやすいです。

発行権限と利用許可の確認

Access Tokenを発行できる人は、ワークスペース設定で制御されます。公式ドキュメントでは、Codex Local controlsでメンバーの利用可否やAccess Token作成可否を設定できると説明されています。必要な人だけが発行できる状態にし、発行した人が保存場所と利用範囲を説明できるようにします。

利用許可の確認では、Codexを実行する環境がトークンを読み取れるか、不要な人が読めないかの両方を確認します。GitHub ActionsならRepository SecretsやEnvironment Secrets、クラウドならSecret Manager、オンプレなら社内の秘密管理基盤を使います。ローカルの .env に置く場合も、git管理外であることを必ず確認します。

APIキーとの違い

Codex Access TokenとOpenAI Platform APIキーは、どちらも認証情報ですが、用途が異なります。公式ドキュメントでも、Platform APIキーで十分な自動化であればAPIキーを使い、ChatGPTワークスペースアクセスやCodex権限、企業向け統制が必要な場合にAccess Tokenを使うと整理されています。

APIキーで十分なケース

OpenAI APIを直接呼び出すアプリケーション、Responses APIを使った社内ツール、モデル推論だけを行うバックエンド処理では、通常はPlatform APIキーで十分です。APIキーはAPI組織やプロジェクト単位の管理に向いており、アプリケーションからモデルを呼び出す目的に合っています。

たとえば、問い合わせ分類、議事録要約、チャットボット、社内検索の回答生成などは、Codex localを動かす必要がなければAPIキーで設計します。ここでAccess Tokenを使うと、目的と認証情報がずれて管理が複雑になります。

ワークスペース管理が必要なケース

Access Tokenが必要になるのは、Codex localを非対話で実行し、ChatGPTワークスペースの権限や管理下で扱いたい場合です。CI runnerで codex exec を動かす、定期ジョブでコード診断を行う、ワークスペースのCodex利用権限に紐づけたい、といったケースです。

Platform APIキーはAPIからモデルを呼び出す用途、Access TokenはCodex localを非対話で動かす用途に向きます。どちらが上位という話ではなく、実行したい処理に合わせて認証方式を選ぶことが重要です。

監査とガバナンスの違い

APIキーはAPI利用の管理に向いていますが、Codex localの非対話実行をChatGPTワークスペースの文脈で管理したい場合はAccess Tokenが適します。Access Tokenは、作成者やワークスペースに紐づくため、誰の自動化として動いたのかを整理しやすくなります。

ただし、監査しやすいからといって、共有トークンを全社で使い回してよいわけではありません。共有IDのように使うと、どのチームのどの処理が実行したのか追いづらくなります。ワークフロー単位、サービスオーナー単位で発行し、不要になったら失効する運用が必要です。

トークン管理の注意点

Access Tokenの管理で最も避けたいのは、漏えい、共有、放置です。トークンを知っている人は、作成者のワークスペースIDとしてCodex実行を開始できる可能性があります。したがって、通常のパスワードやAPIキーと同等以上に慎重に扱います。

Secret Managerでの保管

Access Tokenは、GitHub ActionsならSecrets、AWSならSecrets Manager、GCPならSecret Manager、AzureならKey Vaultなどに保管します。ローカルの環境変数で使う場合も、シェル履歴やログに残らないように注意します。公式ドキュメントでも、トークンをSecret Managerに保存し、ログに出さず、定期的にローテーションすることが推奨されています。

GitHub Actionsで使う場合は、CODEX_ACCESS_TOKEN として環境変数に渡す設計が考えられます。ただし、pull_requestイベントやfork PRではSecretsの扱いに注意が必要です。外部コントリビューターのコードがトークンを読める構成にしないよう、対象イベントと権限を限定します。

ローテーションと権限確認

Access Tokenには有効期限を設定できます。公式ドキュメントでは、7日、30日、60日、90日など有限の期限を選ぶことが例示され、期限なしにする場合も定期ローテーションが必要とされています。最短のカスタム期限や失効済みトークンの扱いは変更される可能性があるため、最新の公式画面で確認してください。

ローテーションは、単に新しいトークンへ置き換えるだけでは不十分です。古いトークンを失効し、CIが新トークンで正常実行できることを確認し、台帳の日付を更新します。退職者や異動者が作成したトークンは、所有者を見直すか、新しいワークフローオーナーで作り直します。

ログ出力と共有禁止ルール

トークン漏えいは、設定ファイルだけでなくログからも起こります。デバッグ時に環境変数を出力する、CIの失敗ログにヘッダーが出る、シェルの履歴にexportコマンドが残る、といったケースです。Codex実行前後のログ設計では、トークン値を出さないこと、マスクが効いていること、失敗時にも秘密情報が残らないことを確認します。

また、Slackやチャットでトークンを共有する運用は禁止すべきです。必要な人にはシークレット管理の権限を付与し、トークン値そのものを直接渡さない形にします。Access Tokenは便利な自動化キーではなく、ワークスペースIDを代理する重要な認証情報として扱う必要があります。

安全な非対話運用の設計

Access Tokenを安全に使うには、トークン単体ではなく、実行環境、権限、監査、失効対応をまとめて設計します。特にCIや定期実行は人の目が届きにくいため、実行範囲を小さくし、異常時に止められる仕組みを作ることが重要です。

実行環境ごとの権限分離

開発、検証、本番に関係するリポジトリやrunnerは、Access Tokenを分けて管理します。開発用の定期チェックと本番リリース前のレビューを同じトークンで動かすと、権限の意味が曖昧になります。可能であれば、リポジトリ、環境、用途ごとにSecretを分け、必要なworkflowだけが参照できるようにします。

また、self-hosted runnerを使う場合は、管理者、作業ディレクトリ、ログ保存、ジョブ後のクリーンアップを確認します。

失効時の対応フロー

トークンが期限切れ、失効、漏えい疑いになった場合の対応フローを決めておきます。失効時には、どのworkflowが止まるのか、誰が新しいトークンを発行するのか、どのSecretsを更新するのかを事前に整理します。漏えい疑いの場合は、対象トークンを即時失効し、利用ログ、CIログ、リポジトリアクセスを確認します。

失効手順が決まっていないと、期限切れのたびに属人的な対応になります。台帳と運用手順を作り、少なくとも四半期ごとにトークン一覧を確認するだけでも、放置リスクを下げられます。

安全なAI運用支援の活用範囲

Access Tokenは、AIエージェントを継続的な開発・運用フローに入れるための入口です。ただし、トークンを発行すれば安全なAI運用が完成するわけではありません。対象リポジトリ、実行プロンプト、承認ポリシー、ログ、秘密情報の扱いを合わせて設計する必要があります。

AIzen株式会社では、CodexやClaude Codeを使った開発自動化だけでなく、認証情報管理、CI/CD組み込み、監査ログ、社内運用ルールの整備まで支援しています。Access Tokenを使うかAPIキーで十分か迷う場合も、業務フローとセキュリティ要件から整理できます。

弊社エンジニアからのコメント：

非対話実行の初期設計では、トークン発行より先に「どのrunnerで、どのリポジトリに、どの権限で実行するか」を1枚にまとめるのが効果的です。

以前、先にSecretだけ作ったケースでは、後からfork PRでの扱いや失効時の連絡先が曖昧になりました。Access Tokenは作成画面より、運用台帳とローテーション手順が品質を左右します。

まとめ

Codex Access Tokenは、CIや定期実行でCodex localを安全に非対話実行するための認証情報です。要点は次の3つです。

• Platform APIキーとAccess Tokenは用途が異なり、Codex localのワークスペース管理が必要な場合にAccess Tokenを選ぶ
• トークンはSecret Managerで保管し、有効期限、所有者、保存先、ローテーション予定を台帳化する
• 公開CIやfork PRなど信頼できないrunnerでは使わず、環境ごとに権限を分離する

AIzen株式会社では、Codexの非対話運用、GitHub Actionsや社内CIへの組み込み、トークン管理とAIガバナンス設計を支援しています。Access Tokenを使った自動化を始めたい場合は、認証方式の選定から運用ルール作成まで無料でご相談ください。