setup codexの初期設定｜Windows・macOS・Linuxの選び方

setup codexで最初に決めること

setup codexという検索語は、単にコマンドを一つ実行する方法だけを指しません。Codexをターミナルで使うのか、デスクトップ画面から使うのか、エディタの中で使うのかによって、導入するものも確認する場所も変わります。先に入口を決めず、複数の配布方法を重ねると、どの実行ファイルが呼ばれているのか、どの設定が効いているのかが分かりにくくなります。最初の目的を「自分のプロジェクトを読み、説明を返してもらう」といった小さな単位にしておくと、導入の成否を落ち着いて判定できます。

OpenAIのCodex CLI公式ガイドは、インストール、ログイン、プロジェクトでの最初の作業を分けて案内しています。この順番は、初めての人にも既に別のAIコーディングエージェントを使っている人にも有効です。ソフトを入れた直後に大きな変更を頼むのではなく、版、ログイン状態、対象フォルダ、読み取り結果を順に確認すると、失敗した場所を特定しやすくなります。

使う場所を選ぶ

Codex CLIは、ローカルのリポジトリを見ながらファイルの調査や編集を進めたい人に向きます。コマンドを入力する場所と作業フォルダがはっきりしているため、どのプロジェクトを見ているかを確認しやすいのが特徴です。デスクトップアプリは複数の作業を画面で管理したい場合に便利ですが、CLIの導入とは別に考えます。VS CodeやCursorのようなエディタでは、編集画面から相談したい人に向きます。迷ったら、まずCLIで起動と読み取りを確認し、必要性が見えた段階で別の入口を追加してください。

配布方法を選ぶ

公式のスタンドアロン配布版は、Node.jsやnpmの状態に左右されたくない人に向いています。一方、既存の開発ツールをnpmでそろえている人は、npm install -g @openai/codexで管理する方が現在の版を把握しやすい場合があります。macOSではHomebrewを使う選択肢もあります。大切なのは、最初に選んだ方法と更新方法をメモすることです。同じ端末で別の方法を何度も試すと、古い実行ファイルが先に呼ばれることがあるためです。

更新前提で考える

Codex CLIは機能の追加と修正が続くため、setup codexは一度終えたら完了という作業ではありません。ただし、毎回最新版へ急いで切り替える必要もありません。安定版を使う人は、公式リリース一覧で現在の版と変更内容を確認し、試験版を試す人は普段の作業と分けて扱います。更新の前後でcodex --versionと小さな確認作業を同じ条件で実施すれば、問題が導入方法にあるのか、版の変更にあるのかを判断できます。

2026年8月にsetup codexを見直す理由

この記事を今読む理由は、Codexを取り巻く入口が増え、CLIとアプリの更新が別々に進んでいるからです。公式のCodex CLIリリース一覧では、2026年8月5日に0.147.0-alpha.6.5が試験版として掲載されています。8月4日にも同じ0.147系の複数の試験版が公開されており、数字だけを見ると安定版のように感じても、実際には性格が違います。導入時点で「安定版を使う」「変更を試す」と決めておくことが、予期しない差分を減らします。

また、OpenAIの公式リリースノートには、2026年7月20日のCodex関連更新として、iOSでのMermaid表示、入力フォーム、未送信プロンプトの復元、作業一覧の改善などが記載されています。7月16日のデスクトップアプリ更新では、ChatGPTとCodexを選ぶ画面や履歴の扱いも整理されました。これらはCLIの導入コマンドを直接変える情報ではありませんが、同じ名前のCodexでも入口ごとに確認すべき場所が違うことを示しています。

CLIの版は安定版と試験版を分ける

リリース一覧で最初に見るのは、バージョン番号の大きさではなく、安定版かプレリリースかという表示です。試験版は新しい修正を先に確認できる反面、普段の開発で使う前に起動、読み取り、編集、テストの順で確かめる必要があります。仕事の中心となる端末では安定版を残し、別のフォルダや別端末で試験版を確認する方が、原因の切り分けをしやすくなります。公式ページの公開日も一緒に記録しておくと、後から状況を再現できます。

画面側の更新とCLIは切り分ける

デスクトップアプリやモバイルアプリの更新を見て、CLIにも同じ機能が直ちに加わったと考えるのは危険です。反対に、CLIの版が上がっても、デスクトップ画面の表示が同じ日に変わるとは限りません。setup codexでは、使っている入口、版、設定の場所を一組として確認します。画面の改善を使いたいならアプリのリリースノートを、端末のコマンドや実行結果を確認したいならCLIのリリース一覧を読み分けてください。

公式ページを基準にする

検索結果や古い記事には、当時の導入コマンドや対応OSが残っています。OpenAIのCodex公式ページとGitHubのopenai/codexリポジトリを起点にし、現在の案内へ移動するのが安全です。配布方法、ログイン方法、対応する端末、設定ファイルの名称は更新される可能性があるため、記事に書かれた手順をそのまま信じるのではなく、最後に公式ページで照合します。

Windows・macOS・Linuxでの導入手順

OSによって端末の入口と表示が異なるため、同じコマンドをすべての環境へ貼り付ける必要はありません。WindowsではPowerShellを使う公式案内、macOSやLinuxではシェルから使う公式インストーラー、共通管理を重視する場合はnpmというように、使いやすさと保守しやすさのバランスで選びます。ここでは大きな設定変更を避け、インストール後に実行ファイルが一つに決まっていることを確認する流れにします。

Step 1: OSと端末を確かめる

まず、Codexを使う端末のOS、CPUの種類、普段使っているシェルを確認します。WindowsならPowerShell、macOSならターミナル、Linuxなら普段のシェルで作業します。複数の端末を使う場合は、端末ごとに同じ導入方法を選ぶ必要はありませんが、どの方法で入れたかを記録してください。特にWindowsでは、PowerShellで入れたものと別のターミナルから呼ぶものが一致するかを後で確かめます。

Step 2: 公式の導入方法を実行する

Windowsの公式案内を使う場合は、PowerShellで次の形を実行します。表示される確認内容を読んでから進め、見慣れないエラーが出たときは、同じコマンドを何度も繰り返さず、公式ガイドと端末の状態を確認します。

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

macOSやLinuxでは、Codex CLI公式ガイドに掲載されているインストーラーを確認し、案内された方法で導入します。npmを選ぶ場合は次のコマンドを使えます。

npm install -g @openai/codex

macOSでHomebrewを普段から使っている場合は、公式リポジトリの案内にあるbrew install --cask codexも候補です。複数の方法を同時に実行するのではなく、自分が後から更新しやすい一つを選ぶのがポイントです。

Step 3: 版と実行場所を確認する

導入が終わったら、プロジェクトの変更をまだ頼まず、まず版を表示します。

codex --version

Windowsでも、Codexを起動する同じPowerShellで実行してください。版が表示されない場合は、インストールが失敗したとは限りません。端末が実行ファイルを見つけられていない可能性があるため、ターミナルを開き直し、where.exe codexで参照先を確認します。macOSやLinuxではwhich codexを使えます。複数の場所が返った場合は、古い版が先に呼ばれていないかを確認し、どの配布方法を残すか決めます。

Step 4: プロジェクトから小さく起動する

次に、対象プロジェクトのフォルダへ移動してcodexを起動します。最初の確認は、ファイルの変更を頼む内容ではなく、「このプロジェクトの構成と、最初に読むべきファイルを説明して」といった読み取り中心の依頼にします。Codexが見ているフォルダ、返答の根拠、読み取れなかった場所を確認し、期待と違えばプロジェクトの場所を直します。この段階で無理にモデルや許可設定を変えないことが、初期設定の問題を増やさないコツです。

初回ログインと作業場所を整える

インストール後に大切なのは、ログインできたかだけではありません。どのアカウントで使っているか、どのプロジェクトを対象にしているか、Codexが何を読める状態かを同時に確認します。公式CLIガイドでも、プロジェクトのディレクトリでcodexを起動し、初回にChatGPTでのサインインなど利用可能な方法を選ぶ流れが示されています。ログイン画面の文言や選択肢は更新されることがあるため、端末に表示される案内を優先してください。

Step 1: 利用するアカウントを決める

個人用と業務用など複数のアカウントを使い分けている場合、初回起動の前にどちらで作業するか決めます。別のアカウントでログインしたまま進めると、利用できるモデルや使用量の表示が期待と合わないことがあります。必要なら、現在のログイン先を画面で確認し、普段のプロジェクトを扱うアカウントを選びます。アカウントを切り替えた後は、同じ小さな読み取り依頼をもう一度実施し、結果の違いを環境の差として記録しておくと安心です。

Step 2: 対象フォルダを先に開く

Codexをプロジェクトの外で起動してから、後でフォルダを指定するより、最初に対象フォルダへ移動して起動する方が確認しやすくなります。現在地はWindowsならGet-Location、macOSやLinuxならpwdで表示できます。フォルダ名だけで判断せず、リポジトリのルート、設定ファイル、テストの位置を確認し、別のコピーを開いていないことを確かめます。複数フォルダを扱うときも、最初は一つに絞ると返答の根拠を追いやすくなります。

Step 3: 最初の依頼を読み取りにする

初回に「全部直して」と頼むのは避け、構成説明、入口ファイル、テストの実行方法の確認から始めます。Codexが提案した内容をそのまま採用するのではなく、どのファイルを読んだか、未確認の点は何か、次に人が見るべき場所はどこかを尋ねます。AIコーディングエージェントの便利さは、変更量を増やすことではなく、調査を短くして判断材料を揃えることにあります。最初の読み取り結果が明確なら、次の編集依頼も安全に小さくできます。

Step 4: 変更前の状態を残す

編集を頼む前に、現在の差分がないかを確認します。Gitを使うプロジェクトならgit statusで作業前の状態を見て、未整理の変更がある場合は、Codexに触れてよい範囲をはっきり伝えます。公式ガイドが勧めるように、作業の前後で戻せる確認点を作ると、初回設定のテスト中に意図しない変更が混ざっても追跡できます。ここで重要なのは、変更を急ぐことではなく、変更前後を比較できる状態です。

config.tomlで設定を足す順番

Codexには、ユーザー単位の設定とプロジェクト単位の設定があります。設定リファレンスによると、ユーザー設定は~/.codex/config.toml、プロジェクト側の設定は.codex/config.tomlに置けます。最初から多くの項目を書き込むと、どの設定が結果へ影響したか分からなくなるため、初期設定では必要最小限から始めます。端末全体に効かせたい項目と、特定のプロジェクトだけに効かせたい項目を分けることが、後からの見直しを楽にします。

モデルは作業の難しさで選ぶ

モデル名は、古い記事の記憶だけで固定しないでください。Codexの画面や/modelコマンドから、現在利用できる選択肢と推論の重さを確認します。短い説明や小さな文言変更では速さを優先し、複雑な設計や原因調査では、より深い推論を選ぶという考え方が使えます。設定リファレンスにはmodel_reasoning_effortの選択肢が掲載されていますが、利用できる値はモデルによって異なるため、端末で選択できる範囲を基準にします。

許可範囲は狭く始める

ファイルの変更、コマンドの実行、ネットワーク接続などを伴う作業は、最初から広い範囲を許可する必要はありません。Codexの起動後に表示される権限や確認の画面を読み、読み取りだけで済む調査と、書き込みを伴う変更を分けます。プロジェクトの外にあるファイル、利用者のデータ、公開前の情報は対象から外し、必要になったときだけ範囲を見直します。公式の権限と安全性の案内も、環境や作業のリスクに応じて確認方法を選ぶ考え方を示しています。

設定ファイルはコメントで意図を残す

設定を追加するなら、なぜその項目を入れたのかを近くに短く残します。たとえば、作業を速くするためなのか、特定のモデルを試すためなのか、プロジェクトの読み取り範囲をそろえるためなのかを書いておくと、後から設定を外す判断がしやすくなります。チームで共有する設定と、個人の端末だけで使う設定を混ぜないことも大切です。設定を変えた後は、版表示と小さな読み取りを再実施し、変更の効果を一つずつ確認します。

setup codexでつまずくときの切り分け

インストールできない、起動しない、ログインが終わらない、プロジェクトを読めないという問題は、同じ「Codexが使えない」でも原因が異なります。エラーメッセージだけを見て再インストールを繰り返すより、OS、導入方法、版、実行場所、対象フォルダ、ログイン状態の順に一つずつ分けます。公式リリース一覧にある新しい試験版を導入した直後なら、まず安定版との違いを疑い、直前の状態で同じ確認を行います。小さな観測点を作るだけで、やり直しの回数を減らせます。

コマンドが見つからない場合

codex --versionで「見つからない」と表示される場合は、導入が未完了か、実行ファイルの場所が端末の検索対象に入っていない可能性があります。ターミナルを開き直し、Windowsではwhere.exe codex、macOSやLinuxではwhich codexを実行します。何も返らなければ公式ガイドの導入を確認し、複数の場所が返れば古い版との重複を整理します。npmを使った場合は、グローバルなインストール先と現在のNode.js環境が一致しているかも確かめます。

ログインや利用権限で止まる場合

ログイン後に利用できない場合は、アカウント、対象プラン、地域、端末側の日時、ネットワーク接続を確認します。ここで別の認証方法を無計画に追加するのではなく、表示された案内と公式のサポート情報を照合します。利用できるモデルや使用量が想定と違うときは、まず現在のアカウントを確認し、次にCodexの入口がCLIかアプリかを確認します。問題を報告するときは、個人情報を含めず、版、OS、再現した操作、表示されたエラーを整理します。

プロジェクトを読めない場合

Codexが別のフォルダを読んでいる、対象フォルダへの権限がない、プロジェクトの構成をまだ理解していないという可能性があります。起動前に現在地を表示し、プロジェクトのルートであることを確認します。次に、変更を頼まず、対象ディレクトリの構成と入口ファイルだけを説明するよう依頼します。回答が曖昧なら、対象を一つのサブディレクトリへ絞り、再度確認します。読み取りが安定してから編集へ進むことで、設定の問題と依頼の問題を分離できます。

動作の違いを記録する

同じ依頼を、導入直後と設定変更後に一度ずつ実施し、版、モデル、作業フォルダ、結果、未確認点を記録します。長い感想ではなく、再現できる事実を並べることが重要です。例えば「構成説明は返った」「テストの場所は見つけた」「編集はまだ許可していない」と書けば、次にどこを調べるかが明確になります。こうした小さな記録があれば、更新後に問題が出た場合も、導入方法を最初からやり直さずに差分を追えます。

setup codexを長く使うための確認項目

初期設定が終わった後は、毎回同じ重い確認をする必要はありません。利用する入口、導入方法、現在の版、設定ファイルの場所、最初の読み取り依頼を一枚のメモにまとめ、更新や端末変更のときだけ見直します。新しい機能を見つけた場合も、普段の作業にすぐ広げず、小さなプロジェクトで確認してから採用します。これにより、便利さを取り入れながら、どの変更が結果に影響したかを追いやすくなります。端末を変えるときも同じ確認項目を使えます。

更新前後に同じ確認をする

Codex CLIを更新したら、codex --version、作業フォルダの表示、読み取り依頼の三つを同じ順番で確認します。必要なら、軽い編集とテストの確認を加えますが、最初から大きな変更を頼む必要はありません。試験版へ移るときは、安定版での結果を残してから比較します。問題が出た場合に戻す判断をしやすくするには、導入日、更新前後の版、使った設定を短く記録しておくのが有効です。

入口を増やしすぎない

CLI、デスクトップアプリ、IDE拡張をすべて導入すると便利そうに見えますが、初心者のうちは設定やログイン先が分散しやすくなります。まず一つの入口で、読み取り、提案、編集、テスト確認までの流れを理解します。その後、別の入口に同じプロジェクトをつなぐ場合は、どの作業をどこで行うかを決めます。入口ごとに版や設定が異なることを前提にすれば、画面の違いを不具合と誤認しにくくなります。

公式情報の確認日を残す

Codexは更新が続くため、導入記事を保存するだけでは情報が古くなることがあります。公式CLIガイド、設定リファレンス、リリース一覧を確認した日と、使用した版をメモします。今回の基準日は2026年8月6日で、前日の公式リリース一覧には0.147.0-alpha.6.5が掲載されていました。次回更新時に同じページを見れば、前回との差分を確認できます。公式情報と自分の端末の表示が違う場合は、端末のOSと導入方法も一緒に見直してください。

まとめ：setup codexは小さく始めて確認する

setup codexで最初に必要なのは、設定を増やすことではなく、使う入口と導入方法を一つに決め、版、ログイン、作業フォルダ、読み取り結果を順に確認することです。Windows、macOS、Linuxで公式案内は異なりますが、作業を小さく始め、変更前の状態を残し、更新前後を比較する考え方は共通しています。

2026年8月はCodex CLI 0.147.0系の試験版が続けて公開され、アプリやモバイル側の更新も進んでいます。新しい版を試すときほど、安定版との違い、設定ファイルの場所、利用するアカウントを明確にしてください。公式のCodex CLIガイド、設定リファレンス、リリース一覧を確認しながら、自分の端末で再現できる最小の手順を作ることが、長く使える初期設定につながります。