top of page
Tazuna

Codex 導入・安全設定・使い方ガイド

執筆者の写真: 雄二 橋本
雄二 橋本
11 時間前
読了時間: 7分

OpenAI のコーディングエージェント「Codex」を、安全にチームで使い始めるための研修資料の内容を、記事として読みやすくまとめました。「入れる」「安全に設定する」「日々使う」の3段階で説明します。

※2026年11月時点の情報（Codex CLI v0.149 以降の仕様）です。Codex は更新が速いため、導入時には公式ドキュメントで最新仕様も確認してください。



Codex とは

OpenAI のコーディングエージェントです。コードを読み、編集し、コマンドを実行して作業を進めます。使い方（入口）は4つあり、中身は同じエージェントです。

  • CLI：ターミナルで動く本体。オープンソースで公開

  • IDE 拡張：VS Code・Cursor・JetBrains のサイドバーで使う

  • デスクトップ：2026年7月から ChatGPT デスクトップアプリの「Codex」モードに統合

  • クラウド：chatgpt.com/codex でクラウド上のタスクとして実行

この記事は主に CLI を例に説明します。設定ファイル ~/.codex/config.toml は CLI と IDE 拡張で共通です。

1. 導入

準備するもの

  • アカウント：ChatGPT アカウント（Plus・Pro・Business・Edu・Enterprise などのプランに Codex が含まれる）、または OpenAI の API キー

  • 対応 OS：macOS・Linux・Windows（Windows 11 推奨。Windows 10 は最新状態でベストエフォート）

  • 必要なツール：ターミナル、Git（AI の変更を確認・取り消すために必須）、npm で入れる場合は Node.js

  • 練習環境：Git 管理された練習用リポジトリ（最初から本番のコードで試さない）

Git は必須と考えてください。AI が加えた変更を差分で確認し、問題があればすぐ元に戻せることが、安全に使うための土台になります。

CLI をインストールする

# macOS / Linux
curl -fsSL https://chatgpt.com/codex/install.sh | sh

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

# npm
npm install -g @openai/codex

# Homebrew
brew install --cask codex

# 確認
codex --version

入手元は公式だけに。chatgpt.com のスクリプトか、npm の @openai/codex を使います（似た名前の偽パッケージに注意）。更新は新しい版なら codex update、または入れた方法で再実行します。どれか1つの方法で入れれば十分です。

IDE 拡張・デスクトップアプリ・Windows

IDE 拡張：

  • VS Code の拡張機能「Codex – OpenAI’s coding agent」を入れる

  • 発行元 ID が openai.chatgpt か確認（似た偽拡張に注意）

  • Cursor・Windsurf・JetBrains にも対応

デスクトップ：

  • 2026年7月9日から ChatGPT デスクトップアプリに統合

  • アプリ内の「Codex」モードで使う（Mac / Windows）

  • 旧 Codex アプリは更新するとそのまま移行

Windows：

  • 既定は PowerShell ＋ネイティブのサンドボックス

  • Linux のツールが必要なら WSL2 を使う

  • WSL1 は v0.115 以降は非対応

初回サインイン：プロジェクトで codex を起動

  • ChatGPT でサインイン（推奨）：ふだんの対話的な作業向け。プランの利用枠を使う

  • デバイスコード：ブラウザのない環境（SSH 先のサーバーなど）向け。プランの利用枠を使う

  • API キー：自動化・CI 向け。API の従量課金

API キーを使うときの注意：キーは標準入力で渡し、チャットに貼らない・リポジトリにコミットしないこと。

printenv OPENAI_API_KEY | codex login --with-api-key

サインインは codex login でもやり直せます。

2. 安全な設定

安全は「2つのダイヤル」で決まる

  • サンドボックス（sandbox_mode）：技術的に「何ができるか」。書き込める場所とネットワーク接続を OS のしくみで制限する

  • 承認ポリシー（approval_policy）：「いつ人に確認するか」。サンドボックスの外に出る操作の前に、ユーザーの承認を求める

片方だけを緩めても危険になるので、必ずセットで考えてください。

選べるモードと、推奨の組み合わせ

サンドボックス（sandbox_mode）：

  • read-only：読むだけ。調査・レビュー向け

  • workspace-write【推奨】：作業フォルダ内の編集・テストが可能。ネットは既定でオフ

  • danger-full-access：制限なし。コンテナ・VM の中だけで使う

承認ポリシー（approval_policy）：

  • on-request【推奨】：権限の外に出る操作の前に確認する

  • never：確認しない。隔離された自動実行の環境専用

  • granular：操作の種類ごとに細かく指定（上級者向け）

注意：untrusted は廃止されました。v0.149.0（2026年8月20日）で削除され、設定に残っていると起動時にエラーになります。on-request に置き換えてください。

おすすめの基本設定

# ~/.codex/config.toml
sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

Windows では %USERPROFILE%\.codex\config.toml。この3行を書いておけば、毎回同じ安全な状態で起動します。ネット接続は必要な作業のときだけ有効にします。

  • 調査・レビューだけのとき：codex --sandbox read-only --ask-for-approval on-request

  • 作業中に切り替える：/permissions

  • 今の設定を確かめる：/status

避けるべき設定

  • --yolo ／ --dangerously-bypass-approvals-and-sandbox：サンドボックスも承認もなくなる。通常の開発では使わない

  • sandbox_mode = "danger-full-access"：使うなら、使い捨てのコンテナ・VM の中だけ

  • approval_policy = "never"：影響範囲を外側で縛れる CI などに限定する

  • network_access = true（常時オン）：必要な作業のときだけ一時的に有効にする

ネット上の記事には手間を省くために --yolo を勧めるものがありますが、OpenAI も推奨していません。

見落としやすい3つの落とし穴

  • 落とし穴1「信頼」は権限ではない：プロジェクトを信頼すると、その中の .codex/config.toml が適用される。信頼する前に、danger-full-access や never など制限を緩める設定がないか中身を確認する

  • 落とし穴2 フォルダの外も読める場合がある：workspace-write は外への書き込みは防ぐが、読み取りまでは絞り切れない。~/.ssh・~/.aws・.env など認証情報を扱う開発はコンテナや VM で隔離する

  • 落とし穴3 自動レビューも間違える：承認の判定を AI に任せる設定（approvals_reviewer = "auto_review"）は便利だが、判断を誤ることがある。重要なファイルや認証情報がある環境では人が承認する

チームで使うときのルール

  • 管理者が上限を固定する：組織の管理設定（requirements.toml）で、承認ポリシー・サンドボックス・使える MCP サーバーを制限できる

  • ルールは AGENTS.md に書く：テストの実行方法、触ってはいけないフォルダ、ブランチの決まりを共有ファイルにまとめる

  • 差分は必ず人が読む：/diff で変更を確認してから人がコミットする。main ブランチへ直接反映させない

  • 秘密情報を置かない：.env や鍵ファイルは作業フォルダに置かない。置く場合も .gitignore で除外し、内容を AI に渡さない

3. 使い方

基本の流れ

  • 1. 起動：プロジェクトのフォルダで codex を実行

  • 2. 依頼：やりたいことを具体的に日本語で伝える

  • 3. 計画：/plan で手順を先に出させて確認

  • 4. 確認：提案された差分を読んで承認・却下

  • 5. 検証：テストを通し、自分でコミット

依頼の例：「tests/ で失敗しているテストの原因を調べて説明して。修正は src/auth/ の中だけにして、変更前に計画を見せて」。対象・範囲・確認のタイミングをはっきり書くほど、安全で的確になります。

よく使うスラッシュコマンド

  • /init：AGENTS.md の雛形を作る

  • /plan：実行前に計画だけを出す

  • /permissions：サンドボックスと承認を切り替え

  • /model：モデルと推論の深さを選ぶ

  • /status：今の設定と使用量を表示

  • /diff：変更内容（未追跡ファイル含む）を表示

  • /review：作業中の変更のレビューを依頼

  • /compact：会話を要約して文脈を節約

  • /resume：保存した会話を再開する

入力欄で / を押すと一覧が出ます。先頭に ! を付けるとシェルコマンドを直接実行できます（例：!npm test）。まず覚えるのは /plan、/diff、/permissions の3つです。

AGENTS.md でルールを伝える

  • リポジトリに置く「AI 向けの作業手順書」。他の AI ツールとも共通の形式

  • /init で雛形を自動作成できる

  • 読む順：~/.codex/AGENTS.md（個人共通）→ リポジトリ直下 → 作業中のフォルダ。近い場所の指示が優先

  • 短く具体的に。長すぎると読み込み上限（既定 32KiB）を超える

# AGENTS.md
## コマンド
- テスト: npm test
- Lint: npm run lint
## ルール
- 変更後は必ずテストを実行する
- config/production/ は編集しない
- パッケージ追加は事前に相談する

安全面では「編集してはいけないパス」と「事前に相談すべき操作」を書いておくのが効果的です。

自動化：codex exec

# 1回だけ実行して終了する
codex exec "README の手順が最新か確認して"

# 前回の会話を再開する
codex resume

自動化のルール：

  • 定型作業や CI に使う、対話なしのモード

  • CI では API キーをシークレット機能で渡し、ログに出さない

  • 承認なしで動かすのは、使い捨てのコンテナやランナーの中だけ

  • 結果は PR として出させ、人がレビューしてマージする

まとめ：導入前チェックリスト

  • 公式の入手元（chatgpt.com・@openai/codex・openai.chatgpt）から入れた

  • ChatGPT でサインイン。API キーはコミットしていない

  • sandbox_mode は workspace-write

  • approval_policy は on-request（untrusted は削除）

  • ネット接続は既定のオフのまま

  • --yolo や danger-full-access を常用していない

  • AGENTS.md にテスト手順と禁止事項を書いた

  • 差分を確認してから、人がコミットする

参考資料（2026年11月時点）

コメント

bottom of page