Codex HOMEを分ける設定術 — 用途別に安全に使うための考え方

Codexをしばらく使っていると、「この作業とあの作業、同じ履歴や設定に混ぜていいのか？」という場面が出てきます。記事執筆、画像生成、動画制作、コード修正、検証用の実験。どれも同じAIエージェント作業ではありますが、必要なルール、使うスキル、生成されるファイル、残したい履歴はかなり違います。

そこで実務上便利なのが、CodexのHOMEを用途別に分ける運用です。ここでいうHOMEは、Codexが設定・履歴・スキル・生成物などを置く作業用の内部ディレクトリを指します。たとえばこのサイト制作環境では、記事作成用の O:\AI_\CodexHomes\web-article、素材制作向けのHOME、動画制作向けのHOMEを分ける、といった考え方です。

この記事では、Codex HOMEを分けると何が変わるのか、どういう時に分けるべきか、逆に分けないほうがいい場面はどこかを整理します。さらに、Claude Codeにも似た目的の仕組みとして CLAUDE.md、.claude/settings.json、~/.claude、プロジェクト設定、ローカル設定、メモリ機能があるので、両者の考え方の違いもまとめます。

Codex HOMEとは何か

Codex HOMEは、単なるプロジェクトフォルダとは違います。プロジェクトフォルダは、実際に編集するリポジトリや作業ディレクトリです。一方、Codex HOMEは、Codex側の状態を置く場所です。現在のHOMEを覗くと、AGENTS.md、config.toml、history.jsonl、sessions、skills、generated_images、logs_*.sqlite などが並びます。

つまりHOMEを分けるとは、同じリポジトリを別の人格で開くというよりも、Codexが使う机・引き出し・作業ログを用途別に分けることに近いです。記事を書く机、画像を作る机、動画を作る机、検証実験の机を分ける。そうすると、それぞれの机に置かれるスキル、作業履歴、生成画像、ルール、ログが混ざりにくくなります。

分けると何が変わるのか

HOMEを分けた時に変わるものは、主に5つです。まず履歴です。Codexは作業の文脈やログをHOME配下に蓄積します。記事執筆の会話、画像生成の試行錯誤、コード修正のログが同じ場所に残ると、後から探す時に負荷が上がります。用途別HOMEにすると、「この記事系の履歴はここ」「素材系の履歴はここ」と追いやすくなります。

次に設定です。AGENTS.md や config.toml のようなルールは、作業内容によってかなり変わります。記事作成では「公式情報を確認する」「日本語で返す」「HTML確認時はフルパスを出す」「画像生成はGPTImage2のみ」といったルールが重要です。コード修正中心のHOMEでは、テスト実行、ブランチ運用、レビュー姿勢などが重要になります。画像制作HOMEでは、保存先、参照画像、生成モデル、プロンプト記録のルールが中心になります。

三つ目はスキルです。Codexのスキルは、特定の作業に必要な手順や参照資料をまとめる仕組みです。記事用HOMEには記事執筆スキルや画像生成スキルを置き、動画用HOMEには台本、音声、Remotion、字幕、サムネ制作のスキルを置く。こうすると、不要なスキルが候補に出にくくなり、誤適用のリスクを下げられます。

四つ目は生成物です。ImageGenで作った画像はHOME配下の generated_images に保存されます。記事用のインフォグラフィックと、ゲーム素材と、動画サムネが同じ場所に溜まると、後でどれが本番採用品なのか分かりにくくなります。HOMEを分けると、生成物の由来が自然に分かれます。

五つ目は権限と安全です。あるHOMEではネットワーク確認やデプロイが必要でも、別のHOMEでは画像生成だけでよいかもしれません。用途ごとに許可するコマンド、触ってよいフォルダ、禁止するツールを変えれば、事故の範囲を小さくできます。

分かれるもの	実務上の意味	混ざると起きる問題
履歴	会話・操作ログを用途別に追える	過去の指示や判断根拠を探しにくい
設定	HOMEごとにルールや既定値を変えられる	記事用ルールが開発作業に混ざる
スキル	用途別に必要なスキルだけを置ける	関係ないスキルを誤って使う
生成物	画像やログの由来が分かりやすい	採用画像と没画像が混在する
権限	許可範囲を用途ごとに絞れる	不要な操作権限を持ったまま作業する

いつ分けるべきか

HOMEを分けるべきかどうかは、気分ではなく「混ぜると危険か」「混ぜると探しにくいか」「混ぜると判断がブレるか」で考えるのが現実的です。たとえば、Web記事執筆と本番デプロイをするHOMEには、公開導線、サイトマップ、OGP、画像保存先、引用ルール、著作権ルールが必要です。一方で、画像素材の大量生成HOMEには、参照画像、プロンプト、生成フォルダ、採用・没の管理が重要です。

この2つを同じHOMEで扱うこともできます。しかし、画像生成の試行錯誤で履歴が膨らみ、記事公開時に必要な判断ログが埋もれるなら、分けたほうがよいです。逆に、まだ小さな個人プロジェクトで、記事も画像も同じ流れで作るだけなら、最初から分けすぎる必要はありません。

分けるべきケース

まず、成果物の種類が違うなら分ける価値があります。記事HTML、画像素材、動画素材、コード修正、研究メモは、管理したい単位が違います。次に、禁止事項が違う場合です。たとえば記事HOMEでは「画像生成はGPTImage2のみ」と強く縛りたいが、別の検証HOMEでは複数モデルを比較したい、といったケースです。この場合、HOMEを分けないと、禁止事項が混ざって判断ミスが起きやすくなります。

また、クライアント別・案件別に守秘範囲が違う場合も分けるべきです。A社の資料、B社の資料、個人制作の資料を同じHOMEに置くと、履歴やメモの混線がリスクになります。プロジェクトフォルダを分けるだけで足りることもありますが、Codex側の履歴やスキルまで分けたいならHOME分離が効きます。

分けなくてよいケース

一方、HOMEを増やすと管理するものも増えます。設定の更新、スキルの同期、認証状態、生成物の置き場所、どのHOMEで何をしたかの記録が必要になります。小さなプロジェクトで、同じルール・同じ権限・同じスキルで十分なら、分けるよりも AGENTS.md やプロジェクト単位のルールを整えるほうが楽です。

Codexの公式機能とHOME分離の関係

OpenAIのCodexドキュメントでは、設定の基本として config.toml、コマンドラインオプション、プロジェクト内の設定、AGENTS.md などが説明されています。特に AGENTS.md は、リポジトリや作業ツリーに置いてエージェントへの指示を管理するためのファイルです。

ここで重要なのは、HOME分離は「公式の設定ファイルを置き換える魔法」ではないという点です。HOMEを分けても、プロジェクト側の AGENTS.md やリポジトリ内のルールは引き続き効きます。HOME分離は、もっと上位の運用です。Codexの内部状態やHOME側の設定を用途別に分け、その上で各プロジェクトの AGENTS.md を読む、という二段構えになります。

たとえば、このWeb記事用HOMEでは O:\AI_\CodexHomes\web-article\AGENTS.md に「記事作成用の履歴・設定・出力を分ける」と書き、実際のサイトリポジトリ側にも AGENTS.md を置いて「このフォルダでは日本語で返す」「画像生成はGPTImage2のみ」「HTML確認時はフルパスを共有する」といったルールを置いています。HOMEのルールとリポジトリのルールは役割が違います。

Claude Codeにも似た考え方がある

Claude Code側にも、作業文脈を分けるための仕組みがあります。ただし、Codex HOME分離とまったく同じではありません。Claude Codeは、ユーザー設定、プロジェクト設定、ローカル設定、メモリファイルを組み合わせて、どの範囲にどのルールを適用するかを分ける設計です。

代表的なのが CLAUDE.md です。これはプロジェクトのコンテキストや作業ルールをClaude Codeに伝えるためのメモリファイルです。プロジェクトの構成、よく使うコマンド、テスト方法、コーディング規約、注意点などを書いておくと、Claude Codeはそのプロジェクトでの作業時に参照できます。

また、Claude Codeには ~/.claude/settings.json、プロジェクト配下の .claude/settings.json、ローカル専用の .claude/settings.local.json など、スコープごとの設定があります。共有したいプロジェクト設定はリポジトリに置き、個人だけの設定やローカル権限はローカルファイルに置く、という使い分けです。

観点	Codex HOME分離	Claude Codeの類似機能
基本発想	用途別に内部状態の置き場所を分ける	ユーザー・プロジェクト・ローカルのスコープで設定を分ける
ルール文書	HOME側やリポジトリ側の AGENTS.md	CLAUDE.md、インポート、メモリ
設定ファイル	config.toml など	settings.json、settings.local.json
履歴・生成物	HOMEを分けると自然に分かれる	主にプロジェクト・ユーザー設定とメモリで文脈を制御
向いている分け方	用途別、案件別、制作工程別	ユーザー共通、チーム共有、ローカル個人設定

どう設計すると破綻しにくいか

HOMEを分ける時は、最初に名前を決めるよりも、分けたい責務を決めるほうが大事です。「記事を書くHOME」「画像だけ作るHOME」「動画だけ作るHOME」「検証だけするHOME」のように、成果物と禁止事項がすぐ分かる単位にします。抽象的な名前にすると、結局どのHOMEで作業するべきか迷います。

次に、HOMEごとに AGENTS.md を短く書きます。最初から長大なルールを書く必要はありません。むしろ、最初は「このHOMEの目的」「保存先」「禁止事項」「確認時の出力ルール」くらいで十分です。運用して問題が出たら追記します。ルールは、実際に事故りそうになった箇所から育てるほうが定着します。

三つ目に、生成物の出口を決めます。ImageGenの出力はHOME配下に残りますが、記事で使う画像は必ず website/assets/images/article/{slug}/ にコピーする、動画で使う素材は tools/video-projects/ に置く、というように、本番で参照する場所を明確にします。HOME配下の生成物は作業ログであり、本番参照先ではない、と決めておくと迷いません。

おすすめのHOME分け例

実際の分け方はチームや制作内容によりますが、個人制作から小規模チームなら、まずは3つで十分です。記事・サイト更新用、素材制作用、実験用です。記事・サイト更新用は、HTML、SEO、引用、公開導線、本番pushなどを扱います。素材制作用は、画像生成、参照画像、サムネ、インフォグラフィック、採用画像の記録を扱います。実験用は、まだ本番ルールに入れたくない検証を隔離します。

O:\AI_\CodexHomes\
  web-article\
    AGENTS.md
    skills\
    generated_images\
  asset-production\
    AGENTS.md
    skills\
    generated_images\
  experiment\
    AGENTS.md
    skills\
    generated_images\

一方で、リポジトリ側にはプロジェクト固有の AGENTS.md を置きます。HOMEは「Codex側の机」、リポジトリの AGENTS.md は「その現場の作業ルール」です。両方を分けて考えると、運用がかなり安定します。

実例：記事HOMEと素材HOMEは何が違うか

記事HOMEと素材HOMEは、同じサイト制作に関わっていても、守るべきことが違います。記事HOMEでは、文章の根拠、日付、引用、公開導線、サイトマップ、OGP、内部リンク、レビュー用HTMLのフルパス共有が重要です。特に技術記事では、現在情報を公式ドキュメントで確認するかどうかが品質に直結します。

素材HOMEでは、文章よりも参照画像、生成プロンプト、モデル制約、採用ファイル、没案の管理が重要です。キャラクター入り画像なら、どの参照画像を使ったかを残す必要があります。記事HOMEで画像生成まで全部やってもよいのですが、画像生成の試行錯誤が多い案件では、履歴が画像生成ログだらけになります。後から「この文章判断はどこで決めたのか」を探す時に邪魔になります。

HOME	主な目的	強めに書くべきルール
web-article	記事執筆、HTML化、公開導線、SEO	公式情報確認、引用制限、HTMLフルパス共有、公開前チェック
asset-production	サムネ、挿絵、インフォグラフィック、素材管理	使用モデル、参照画像、保存先、プロンプト記録、禁止ツール
video-production	台本、音声、字幕、映像素材、レンダリング	尺、解像度、音声命名、動画プロジェクト構成、納品先
experiment	検証、比較、壊してよい試作	本番ファイルを触らない、結果を明示、採用前に別HOMEへ移す

移行手順：既存HOMEを分ける時の進め方

すでに一つのHOMEで何でもやっている場合、いきなり全部を分割すると混乱します。おすすめは、新しいHOMEを一つだけ作り、最も混ざると困る用途から移すことです。たとえば画像生成が多すぎて履歴が汚れているなら、まず素材HOMEを作ります。公開作業と実験が混ざって怖いなら、まず実験HOMEを作ります。

新しいHOMEを作ったら、最初に書くのは AGENTS.md です。ここには、そのHOMEの目的、触ってよいフォルダ、出力物の置き場所、禁止事項、ユーザーへの報告ルールを書きます。最初から完璧なルールを作ろうとすると止まるので、最低限で始めます。

# Codex Home: Asset Production

- Use this CODEX_HOME for article thumbnails, infographics, and reusable visual assets.
- Keep generated images, prompts, and selection notes separate from article-writing history.
- Use only the approved image generation path for production assets.
- Copy accepted assets into the project repository before referencing them from HTML.
- Record source prompt, generated path, destination path, and usage purpose.

次に、必要なスキルだけを入れます。記事HOMEに動画スキルを大量に置く必要はありません。素材HOMEにデプロイスキルを置く必要もありません。スキルは便利ですが、増えすぎると「どれを使うべきか」の判断が難しくなります。HOME分離の価値は、不要な選択肢を減らせるところにもあります。

最後に、移行前後の成果物を混ぜないようにします。古いHOMEにある画像を新しいHOMEへ移す必要は必ずしもありません。むしろ、採用品だけをプロジェクトの正式なアセットフォルダへコピーし、HOME配下の生成物は作業ログとして残すほうが整理しやすいです。

よくあるアンチパターン

一つ目の失敗は、HOMEを「プロジェクトごと」だけで切ることです。プロジェクト単位で分けるのは自然ですが、同じプロジェクト内に記事、画像、動画、実験が混在するなら、プロジェクト単位だけでは足りないことがあります。逆に、同じ画像生成ワークフローを複数プロジェクトで使うなら、素材制作HOMEを横断的に持つほうが楽なこともあります。

二つ目は、HOMEを増やしたのにルールを書かないことです。空のHOMEを増やしても、エージェントは何を優先すべきか分かりません。HOMEを分けるなら、そのHOMEで「やること」と「やらないこと」を短く書く必要があります。

三つ目は、HOMEをセキュリティ境界だと思い込むことです。HOMEを分けても、同じOSユーザーで動いているなら、読めるファイル範囲や認証情報の扱いは別問題です。秘密情報を扱うなら、リポジトリ、環境変数、認証ファイル、外部サービスの権限、Gitのignore設定まで見る必要があります。

四つ目は、公開作業と実験作業を同じ権限で走らせることです。実験HOMEでは壊してよいファイルだけを扱い、本番HOMEでは公開導線やpush権限を扱う。権限の重さが違う作業は、HOME分離の効果が出やすい代表例です。

Claude Codeではどう考えるべきか

Claude Codeでは、まず CLAUDE.md を整えるのが基本です。プロジェクトのビルド方法、テスト方法、禁止事項、ディレクトリ構成、よくある作業手順を書く。これはCodexでいうリポジトリ側 AGENTS.md に近い役割です。

次に、チームで共有する設定は .claude/settings.json、個人のローカル設定は .claude/settings.local.json やユーザー設定に置く、という分け方をします。つまりClaude Codeは、HOMEを用途別に丸ごと切るというより、同じプロジェクトの中で「共有する設定」「個人だけの設定」「ユーザー全体の設定」を分けるのが得意です。

さらに、Claude Codeのメモリ機能は、作業中に重要な情報を CLAUDE.md に追加していく運用と相性があります。プロジェクトで繰り返し使う知識はメモリへ、ローカルの権限や個人設定はローカル設定へ、チーム共通の制約は共有設定へ、という分担です。

CodexとClaude Codeを併用する場合

CodexとClaude Codeを併用する場合は、どちらを「作業の主担当」にするかを決めたほうが安定します。たとえば、Claude Codeで記事HTMLの骨組みやサイト構造を触り、Codexの画像生成HOMEでサムネやインフォグラフィックを作り、最後に記事HOMEで公開導線を確認する、という分担です。

この時に危ないのは、片方のツールで決めたルールを、もう片方に伝え忘れることです。たとえば「画像生成はGPTImage2だけ」というルールをClaude Code側の CLAUDE.md には書いたが、Codex HOME側の AGENTS.md には書いていない。あるいは、Codex側で決めた公開手順をClaude Code側が知らない。こういうズレがあると、ツールを切り替えた瞬間に事故ります。

対策は、共通ルールをリポジトリ内に置くことです。HOME側には「このHOMEの用途」、リポジトリ側には「このプロジェクトで必ず守るルール」を置く。Claude Codeの CLAUDE.md とCodexの AGENTS.md で完全に同じ文章を二重管理する必要はありませんが、禁止事項や公開手順のような事故につながるルールは、両方から読める場所に置いたほうが安全です。

判断基準を一文で言うなら

HOMEを分けるか迷ったら、「その作業の履歴・生成物・権限が、別の作業に混ざった時に困るか」と考えます。困るなら分けます。困らないなら、まだ分けなくてよいです。

この基準はClaude Codeにもそのまま使えます。チーム全員に効かせたいなら共有設定や CLAUDE.md、自分だけに効かせたいならユーザー設定やローカル設定、プロジェクトに残すべき知識ならメモリ。どこに置くかは、「誰に効かせたいか」「どの範囲に残したいか」で決めます。

最後に、HOME分離は一度決めたら終わりではありません。月に一度くらい、使っていないHOME、古いスキル、未採用の生成物、今は不要になった許可ルールを見直すと運用が軽くなります。特に画像生成や動画制作のHOMEはファイルが増えやすいので、「本番採用済み」「保留」「破棄予定」を分けておくと後で迷いません。分離は整理のための手段なので、増やしたHOMEが逆に迷いを生んでいるなら、統合する判断も正解です。運用は、分ける勇気と戻す判断の両方で安定します。

運用で一番大事なこと

Codex HOME分離も、Claude Codeのスコープ設定も、目的は同じです。AIエージェントに渡す文脈と権限を、必要な範囲に絞ることです。文脈が多すぎると、エージェントは過去の別用途のルールを引きずることがあります。権限が広すぎると、必要ない作業までできてしまいます。生成物が混ざると、採用品と没案の区別が曖昧になります。

だから、分けるべきものは分ける。ただし、分けすぎない。これが実務上の落としどころです。HOMEを増やすほど、設定の重複、スキルの更新漏れ、どのHOMEで作業したかの迷いも増えます。最初は少数のHOMEで始め、明確な痛みが出たところだけ増やすのが堅実です。

まとめ

Codex HOMEを分けると、履歴、設定、スキル、生成物、権限の混線を減らせます。特に、記事制作、素材生成、動画制作、検証作業のように成果物と禁止事項が違う場合は有効です。一方で、同じプロジェクトで同じ目的の作業をしているだけなら、HOMEを増やすより、リポジトリの AGENTS.md を整えるほうが軽く済みます。

Claude Codeにも、同じ目的のために CLAUDE.md、.claude/settings.json、.claude/settings.local.json、ユーザー設定、メモリ機能があります。CodexはHOMEを分ける発想、Claude Codeはスコープを重ねる発想。どちらも「文脈と権限を混ぜない」ための道具です。

参照した公式資料

• OpenAI Codex docs: Configuration basics — Codexの設定ファイルや設定値の考え方を確認。
• OpenAI Codex docs: AGENTS.md — Codexにプロジェクト固有の指示を伝えるファイルとして確認。
• Anthropic docs: Claude Code settings — Claude Codeのユーザー設定・プロジェクト設定・ローカル設定の整理に参照。
• Anthropic docs: Claude Code memory — CLAUDE.md とメモリ運用の説明に参照。

この記事では、Codex HOME分離を「実務上の運用パターン」として説明しています。公式の設定機構そのものは、OpenAI Codex docsの config.toml や AGENTS.md の説明を基準にしてください。