Codex service accounts 設計ガイド - 個人アカウントでCIを回さない

CodexをCI runnerや定期ジョブに入れるとき、最初に決めるべきなのはpromptではありません。誰の権限でCodexが動くのかです。個人アカウントのログイン状態をそのまま使うと、退職、異動、権限変更、plugin追加、token漏えいの影響範囲を後から説明できません。

この記事では、OpenAI Docsで説明されている Codex service accounts を、CI / scheduled job / shared integration 用の非人間IDとしてどう設計するかを扱います。CI内で codex exec をどう走らせるかは Codex CI / non-interactive 設計ガイド、定期実行の仕事選定は Codex Automations 実践ガイド、plugin許可の全体像は Codex plugin governance 設計ガイド、secretの扱いは AIエージェント秘密情報設計ガイド に分けます。

今回は、Codexの性能や自動修正の話ではありません。個人ではなくworkflowにIDを持たせ、最小権限、期限、監査、失効をそろえる話です。

先に結論: service account は「便利なtoken」ではなく実行主体

私なら、Codex service accountは次の単位で切ります。

workflow	service account	付ける権限	避けること
PR要約	svc-codex-pr-summary	GitHub read、Codex local access	branch push
CI失敗調査	svc-codex-ci-digest	CI log read、repo read	deploy secretの同居
release note作成	svc-codex-release-notes	tag / merged PR read	release publish
dependency更新案	svc-codex-dep-proposal	package metadata read、draft PR	main直push

service accountを「人の代わりにログインする裏口」と考えると危険です。正しくは、特定workflowのための実行主体です。人の権限を借りるのではなく、workflowが必要とする権限だけを明示して持たせます。

個人アカウント、Admin key、API Platform service accountと混ぜない

OpenAIのdocsでは、Codex service accountはChatGPT workspace上の非人間IDとして説明されています。個人access tokenは作成者本人を表し、API Platformのproject service accountやAPI keyは別のproject accessとbillingで動きます。さらにAdmin keyはChatGPT workspaceの管理API用で、Codex automationの実行tokenとは役割が違います。

ここを混ぜると、incident時に止めるものを間違えます。

credential	主語	使う場面	事故時の論点
個人ログイン / personal token	workspace member	手元の対話作業	退職・権限変更に引きずられる
Codex service-account token	workflow identity	CI runner、scheduled job	workflow単位で失効できる
Workspace Admin key	workspace admin operation	service account管理、監査API	model実行用ではない
API Platform service account	API project workload	model API / platform project	ChatGPT workspace権限とは別

実務では「とりあえず動くtoken」が後で負債になります。Codexを自動化するなら、実行token、管理key、model API keyを同じsecret store名で並べない方がよいです。

既存記事との役割分担

このサイトには、すでにCodex automationやCI安全運用の記事があります。今回の記事は、それらを横断するidentity設計だけに絞ります。

既存記事	扱うこと	本記事で扱うこと
Codex CI / non-interactive	codex exec、sandbox、output schema	CIに渡す実行主体
Codex Automations	反復タスク、worktree、inbox review	定期ジョブ用の非人間ID
Codex plugin governance	plugin / app / action controls	service accountに付けるplugin境界
AIエージェント secret handling	secretを読ませない、失効する	Codex tokenの発行・保存・rotate
AIエージェント監査ログ	tool実行や承認の証跡	runをservice accountへ帰属させる

つまり、この記事は「Codexをどう使うか」ではなく、「Codexを誰として使わせるか」を扱います。

service accountを作る前にworkflow packetを作る

service accountは、作成画面から先に作るより、workflow定義から始めた方が安定します。名前、権限、plugin、token期限を後から考えると、だいたい広くなります。

私なら最初にこのpacketを書きます。

codex_service_account:
  name: "svc-codex-ci-digest"
  owner_group: "platform-engineering"
  purpose: "CI failure logsを読み、失敗原因と次の人間確認事項をPRへ要約する"
  allowed_inputs:
    - "GitHub PR metadata"
    - "CI check summary"
    - "failure logs from current workflow run"
  denied_inputs:
    - "deployment credentials"
    - "production database secrets"
    - "unrelated repository content"
  plugins:
    github:
      actions:
        read:
          - "pull request"
          - "checks"
          - "workflow logs"
        write:
          - "none in phase 1"
  codex:
    mode: "codex exec"
    sandbox: "read-only"
    approval_policy: "never"
    output: "json summary"
  token:
    ttl_days: 30
    storage: "CI runner secret store"
    rotation_owner: "platform-engineering"

この時点でwrite権限が必要に見えるなら、workflowを2つに分けます。読むservice accountと書くservice accountを分けるだけで、事故時の止血がかなり楽になります。

tokenは長寿命にしない

Codex service accountでは、accountの詳細からaccess tokenを作成し、Codex scopeと期限を指定します。tokenの全体値は作成時に一度だけ表示されます。つまり、発行直後の扱いを誤ると、後から復元ではなく再発行になります。

私ならtoken運用をこうします。

項目	初期値
名前	ci-digest-2026-09 のように用途と発行月を入れる
TTL	30日から始める
保存先	GitHub Actions secret、runner secret、またはsecret manager
ログ	token値は出さず、token id / service account idだけ残す
rotation	新tokenでworkflowを通し、旧tokenをrevokeする

OpenAI docsのAdmin API例でも、finite lifetimeは1年未満かつworkspace policyに従う前提です。最初から1年近いtokenを配るより、30日で運用負荷を測り、必要なら90日に伸ばす方が説明しやすいです。

pluginは作成者から継承されない前提で見る

service accountは、作成者のpluginやconnected appをそのまま継承しません。account自身にpluginを設定します。これは面倒ではなく、良い制約です。

たとえばGitHub pluginを付けるなら、次を分けて見ます。

plugin_assignment:
  service_account: "svc-codex-pr-summary"
  plugin: "GitHub"
  service_authorization: "org-approved GitHub app installation"
  app_actions:
    read:
      - "repo metadata"
      - "pull request diff"
      - "review comments"
      - "check status"
    draft:
      - "summary text"
    write:
      - "none"
  escalation:
    write_pr_comment: "separate human-approved workflow"

「GitHub pluginを許可した」だけでは粒度が荒いです。plugin availability、app action、接続先サービスの権限、Codex runtime permissionを別々に見ます。この分離は Codex plugin governance 設計ガイド と同じ考え方です。

CIでは保存ログインより環境変数を優先する

OpenAI docsでは、service-account access tokenを CODEX_ACCESS_TOKEN として渡せば、browser sign-inなしで codex exec を実行できます。信頼済み端末では標準入力から codex login --with-access-token で保存できますが、共有runnerや一時runnerでは保存しない方がよいです。

CIではこの形に寄せます。

export CODEX_ACCESS_TOKEN="$CODEX_SERVICE_ACCOUNT_TOKEN"

codex exec \
  --json \
  --sandbox read-only \
  -c approval_policy=never \
  "Summarize the current CI failure. Return JSON with cause, evidence, and next_human_action."

重要なのは、tokenを渡したから広い仕事を任せてよいわけではないことです。CODEX_ACCESS_TOKEN は実行主体を固定するだけです。sandbox、approval policy、対象repo、plugin action、出力形式は別に狭めます。

groupとroleは人間と同じ棚卸し対象にする

service accountは、人間のworkspace memberと同じようにroleやgroupを持てます。ただし、人間と同じgroupへ雑に入れると、automation用には不要な権限まで拾います。

私なら、service account用groupを分けます。

group	入れるaccount	権限
codex-ci-readers	CI要約、PR調査	repo read、Codex local access
codex-release-drafters	release note作成	merged PR read、tag read
codex-plugin-pilots	plugin検証	限定pluginのみ
codex-write-approved	人間承認済みwrite workflow	PR commentやbranch作成など最小限

特に避けたいのは、Engineering や All members にservice accountを入れてしまうことです。人間向けの便利権限は、automationにとって過大権限になりやすいです。

監査では「誰が作ったか」と「何が走ったか」を分ける

service accountのrunはservice accountに帰属します。一方で、tokenを作った人、account設定を変えた人、pluginを追加した人は別に追う必要があります。

監査ログでは最低限これを残します。

audit_record:
  run_id: "codex-ci-digest-2026-09-01-001"
  service_account: "svc-codex-ci-digest"
  token_id: "tok_redacted_tracking_id"
  triggered_by: "github-actions"
  configured_by: "workspace-admin-group"
  plugin_set:
    - "GitHub read-only"
  inputs:
    - "pr:1234"
    - "check-run:5678"
  outputs:
    - "ci-digest-json"
  human_review:
    required: true
    location: "PR check summary"

「service accountがやった」で止めると、人間の管理責任が消えます。逆に「作成者がやった」とだけ見ると、CI runnerやscheduled jobの実行主体を見失います。両方を残します。

削除より先にdisableを使う場面

token漏えいなら即revokeです。workflow自体が不要ならaccountをdisableまたはdeleteします。OpenAI docsでは、disableやdeleteでactive tokenはrevokeされます。deleteは戻せないため、原因調査中はdisableから入る方がよい場面があります。

私ならincident時はこの順番にします。

1. token値が露出したなら、そのtokenをrevokeする
2. 露出範囲が不明ならaccountをdisableする
3. 直近run、plugin、group、token作成履歴を確認する
4. 新しいservice accountまたはtokenへ置き換えてworkflowを通す
5. 旧accountが不要ならdeleteする

この順番なら、止血、調査、復旧を分けられます。焦ってdeleteだけすると、どのworkflowが依存していたかの確認が難しくなります。

導入順序

最初から全automationをservice account化する必要はありません。まず、個人アカウント依存が一番説明しづらい場所から切ります。

1. read-onlyのCI digestをservice account化する
2. token TTLを30日にしてrotationを1回試す
3. GitHub read pluginだけを付け、write actionを入れない
4. run attributionとtoken管理者を監査ログで確認する
5. うまく回ったらscheduled jobへ広げる

この順番なら、失敗しても影響は小さいです。いきなりbranch pushやPR commentのwriteまで持たせると、identity設計の検証とworkflow設計の検証が混ざります。

よくある失敗

1. 個人tokenをCI secretに入れる

短期の検証では動きますが、退職、休職、権限変更、MFA更新で止まります。さらに、その人が持つpluginやworkspace roleの影響を受けます。CIは人ではなくworkflowとして認証させるべきです。

2. service accountにowner相当の権限を付ける

automationが止まらないように広い権限を付けるのは逆効果です。壊れたときに止める対象が大きくなります。まずread-only、次にdraft、最後に限定writeです。

3. plugin設定を人間の利用ルールと同じ表で見る

人間は画面を見て違和感に気づけます。scheduled jobは気づきません。service accountに付けるpluginは、unattended run前提で別審査にします。

4. token期限だけ決めてrotation手順を決めない

TTLを短くしても、期限切れでCIが落ちるだけなら現場は長寿命tokenへ戻します。新token発行、secret更新、dry run、旧token revokeまでをrunbookにします。

5. Admin keyでCodexを実行しようとする

Admin keyはworkspace管理APIのためのcredentialです。Codex automationを実行するtokenとは違います。管理と実行を同じcredentialにしないことが、後から説明できる権限設計の基本です。

実務チェックリスト

Codex service accountを作る前に、最低限これを確認します。

• workflow名、owner group、停止条件が決まっている
• 個人アカウントで動かす理由が残っていない
• service account用groupが人間用groupと分かれている
• pluginはaccount自身に設定し、必要なactionだけに絞っている
• token TTL、保存先、rotation担当が決まっている
• CI runnerに不要なdeploy secretやcloud admin credentialが同居していない
• CODEX_ACCESS_TOKEN は一時runnerでは保存ログインに使わない
• run attribution、token作成者、plugin変更者を追える
• revoke、disable、deleteの判断順がrunbookにある

参考にした一次情報

• OpenAI: Service accounts
• OpenAI: Non-interactive mode
• OpenAI Help Center: Managing Admin keys in Admin Console
• OpenAI Help Center: ChatGPT Enterprise & Edu release notes
• OpenAI: Plugin controls

まとめ

Codex service accountsは、CIを少し楽にするためのtoken発行機能ではありません。Codex automationを、個人アカウントではなくworkflow identityとして扱うための土台です。

まずはread-onlyのCI digestから始め、service account、plugin、group、token、監査ログを小さくそろえる。そこまで通ってからscheduled jobや限定writeへ広げる。この順番なら、Codexを自動化しても「誰の権限で、何を、いつ止められるのか」を失いにくくなります。