最初の1時間で、依頼から差分の受け入れまでを一周する

道具が入ったので、今回は1時間で一周します。フォルダを開き、規約の下書きを作り、依頼を1つ出し、返ってきた差分を読み、受け入れる。ここまでが Codex を使う作業の最小の形で、あとの14回はこの形の各部分を深くしていくだけです。

先に断っておくと、この回でやることは地味です。派手な成果物は出てきません。ただ、ここで身につく「差分を読んでから受け入れる」という順番が、あとの回の全部の土台になります。

作業するフォルダの中で起動する

Codex は、開いたフォルダを作業の範囲として扱います。デスクトップアプリならフォルダを選ぶ画面が出ますし、コマンドライン版なら、そのフォルダへ移動してから codex と打ちます。

cd C:\work\my-project
codex

別の場所から起動先を指定することもできます。コマンドライン版には -C, --cd <DIR> という指定があり、起動時の作業フォルダを渡せます。

ここで大事なのは、選んだフォルダの外は既定では触れないということです。第5回で詳しく扱いますが、書き込みが許されるのは作業フォルダとその下だけで、外にあるファイルを書き換えるには別の許可が要ります。だから最初にどのフォルダを開くかが、そのまま安全の境界になります。

もうひとつ、起動先は Git の管理下にあるフォルダを選んでください。非対話で動かす codex exec には、Gitリポジトリの外で動かすことを許す --skip-git-repo-check という指定があります。わざわざ「確認を飛ばす」指定が用意されているということは、既定では確認しているということです。Git があれば、気に入らない変更をまとめて捨てられます。Git がなければ、上書きされたファイルは戻りません。Git そのものは第7回で扱いますが、この時点では git init と git commit を1回ずつ通しておけば足ります。

最初の依頼の前に、/init を通す

フォルダを開いたら、依頼より先に /init を実行します。

これは、そのリポジトリを読んで AGENTS.md の下書きを作らせるコマンドです。AGENTS.md は、Codex が作業を始める前に読む規約のファイルで、使っている言語、動かし方、検査の通し方などを書いておきます。/init は、その下書きをリポジトリの中身から推測して書き出します。

出てきたものをそのまま使う必要はありません。むしろ最初は、書かれた内容が事実と合っているかを読む時間だと思ってください。テストの走らせ方が違っていたり、使っていないフレームワークが書かれていたりします。そこを直す作業が、そのまま「このリポジトリで何が守られるべきか」を自分で言葉にする作業になります。

AGENTS.md の中身をどう設計するかは第9回でまとめて扱います。ここでは、下書きを作って、明らかな間違いだけ直して、コミットしておけば十分です。

最初の依頼は、確かめられる大きさにする

さて、最初の依頼です。

選び方の条件はひとつだけで、出てきた結果の正しさを自分で判定できることです。文言の修正、関数1つの切り出し、テスト1件の追加。このあたりが適します。

逆に、最初にやらないほうがよいのは「このアプリにログイン機能をつけて」のような依頼です。出てくる量が多く、正しいかどうかを読み切れません。読み切れないものを受け入れると、次に何か壊れたときに、どこから壊れたのかが分からなくなります。

依頼の文は、対象と、望む結果と、確かめ方の3つが入っていれば十分です。

src/lib/date.ts の formatDate を、和暦にも対応させてください。
既存の呼び出し側は変えず、第2引数で切り替える形にしてください。
テストは tests/unit/date.test.ts に追加し、npm test が通ることを確認してください。

「確かめ方」を書いておくと、Codex は自分で検査コマンドを走らせて、通るところまで持っていきます。この一文があるかないかで、返ってくるものの完成度は変わります。依頼の書き方そのものは第6回で扱います。

返ってきた差分の読み方

依頼を出すと、Codex はファイルを読み、編集し、必要ならコマンドを実行します。その過程は画面に流れますが、最後に見るべきは差分です。

差分は、行の頭に印がついた形で出ます。消える行と、増える行が並んでいます。読む順番を決めておくと速くなります。

1. 触ったファイルの一覧を先に見る。依頼で想定していなかったファイルが入っていないか
2. 消えている行を見る。消してよいものだったか
3. 増えている行を見る。書き方が周りと揃っているか
4. 検査の結果を見る。テストや型検査が通っているか

順番がこうなっているのは、1つ目で気づけることが一番大きいからです。「文言を直して」と頼んだのに設定ファイルが書き換わっていたら、その時点で受け入れずに理由を聞いたほうが速い。中身の1行1行を読むのは、範囲が想定どおりだと分かってからで間に合います。

承認を出す場面と、止める場面

作業の途中で、Codex は人に確認を求めることがあります。ファイルの書き込み、コマンドの実行、作業フォルダの外への操作などです。どこで止まるかは承認の方針で決まり、既定の設定では、必要な場面で聞いてくる形になっています。

聞かれたときに考えることは2つです。

ひとつは、その操作が依頼の範囲に入っているかどうか。文言を直す依頼で npm install を走らせたいと言ってきたら、なぜそれが要るのかを先に聞きます。理由が返ってこないなら止めます。

もうひとつは、その操作が戻せるかどうか。ファイルの書き換えは Git があれば戻せます。外部への送信や、データベースへの書き込みや、デプロイは戻せません。戻せない操作は、依頼した覚えがなければ止める。この一線だけ決めておけば、最初のうちは困りません。

承認の方針とサンドボックスの組み合わせは第5回でまとめて扱います。ここでは既定のまま進めてください。

セッションを畳んで、また開く

1時間の作業は途中で切れます。会議が入り、パソコンを閉じ、翌日また開く。

Codex のセッションは記録されているので、続きから再開できます。コマンドライン版では次の形です。

codex resume --last

引数なしの codex resume は、過去のセッションを一覧から選ぶ画面を出します。--all をつけると、別のフォルダで動かしたセッションも含めて表示されます。

別の道筋を試したいときは codex fork です。ここまでの文脈を引き継いだまま枝分かれさせるので、「さっきの続きで別の直し方を試す」ができます。元のセッションは残ります。

会話が長くなってきたときは /compact で要約に畳めます。長い会話をそのまま持ち続けると、古いやり取りに引きずられて的外れな提案が増えます。話題が変わったら畳む、を癖にしておくと結果が安定します。

1時間でできた状態

ここまでで、手元には次のものが残っているはずです。

• 規約の下書きが入った AGENTS.md が1つ
• 依頼から生まれた差分が1つ、内容を読んだうえでコミットされた状態
• 「範囲が想定どおりか」を先に見る読み方

最初の1件は誰でも丁寧に読みます。問題は10件目で、そのころには差分をざっと流して受け入れたくなります。先に見る場所を決めておくのは、そのときのための仕掛けです。

次の回

基本の一周ができました。第4回では、同じ依頼でも結果が変わる要因のうち、一番効くところを扱います。どのモデルで動かし、どれだけ考えさせるか、という設定です。

参照した公式情報

• OpenAI「Codex CLI」「Configuration」「AGENTS.md」（developers.openai.com/codex、2026年9月時点）
• コマンドライン版の引数と補助コマンドは codex-cli 0.154.0 を執筆環境へ導入して取得