Codex複数リポジトリ｜主・副フォルダーの使い分けと設定確認

ChatGPT 26.715でCodexのローカルプロジェクトが変わった

OpenAIは2026年7月23日、ChatGPTデスクトップアプリ26.715で、ローカルプロジェクトへ複数の関連フォルダーを追加できる機能を公開しました。追加したフォルダーの一つを主に指定し、残りを副として利用できます。発表内容はCodex公式更新履歴で確認できます。

従来の「一つのフォルダーを開いて作業する」という捉え方では、画面側、API、共通ライブラリが別リポジトリに分かれた案件を説明しにくい場面がありました。新機能では関連コードを同じプロジェクトに添付しながら、どこを基準に新しいチャットを始めるかを選べます。

複数フォルダーは単なる検索対象の追加ではない

すべての添付フォルダーは、Codexによるファイル検索、読み取り、編集に利用できます。一方、新しいチャットが始まる場所、Git操作の対象、AGENTS.md、skills、config.tomlの自動検出には主フォルダーが使われます。中心と参照先を明確に分ける設計です。

そのため、フォルダーを増やせば自動的に案件全体を理解する、と考えるのは正確ではありません。副フォルダーのコードは扱えても、そこに置かれたプロジェクト設定は自動検出されません。必要な指示や設定を最初に読ませたい場所を主に選ぶ必要があります。

利用範囲とアクセス範囲は別に確認する

公式のローカルプロジェクト利用手順では、複数フォルダーは関連する作業が別の場所にある場合に使い、無関係な作業は別プロジェクトへ分けるよう案内されています。リモートプロジェクトは現時点で一つのフォルダーに対応します。

また、プロジェクトへ添付したことだけで、あらゆるファイル操作が許可されるわけではありません。実際に読める場所、変更できる場所、ネットワークへ接続できる範囲は、その環境の安全設定によって決まります。追加後は小さな確認から始めるのが確実です。

複数フォルダーを追加して主フォルダーを選ぶ方法

公式手順では、対象プロジェクトのメニューからEdit projectを開き、Add folderで関連フォルダーを追加します。主にしたいフォルダーを選び、Make primaryを指定すると、既定の作業場所を変更できます。画面上の表記が異なる場合は、前述の公式手順を確認してください。

初回から多数のリポジトリを追加する必要はありません。まず今回の変更に直接関係する二つか三つに絞り、主フォルダーを一つ決めます。Codexが必要なファイルを見つけられるか確認した後で、必要性を説明できるフォルダーだけを追加すると対象範囲を保てます。

追加前に各フォルダーの役割を一文で書く

たとえば「アプリは画面変更と受け入れ確認の場所」「APIはデータ取得処理の変更先」「共通ライブラリは型定義の参照先」と整理します。一文で役割を書けないフォルダーは、今回のプロジェクトへ本当に添付する必要があるかを見直す候補です。

役割を決めたら、今回の依頼を完了と判断するコードがどこにあるかを確認します。画面の挙動が完了条件ならアプリ、応答形式やデータ処理が完了条件ならAPIを主にする、という決め方なら、作業中に中心がぶれにくくなります。

主を選んでから副を足す

最初に主を決め、足りない参照先を副として加える順序が分かりやすい方法です。先にすべての関連リポジトリを並べると、設定の起点と単なる参照先の区別が曖昧になります。主を決めた後なら、副を追加する理由も具体的に説明できます。

作業途中で中心が変わる場合は、主を切り替えて構いません。ただし、切り替え後は新しいチャットの開始位置と設定検出の基準も変わります。以前と同じ前提で続けず、後述する5項目をもう一度確かめてから変更を広げます。

主フォルダーと副フォルダーの役割

主と副は、編集できるかどうかだけで区別されるものではありません。どちらもファイルを検索、読み取り、編集できますが、作業の起点になる機能は主へ集まります。違いを先に把握すると、必要なコードが見つからない原因と、設定が使われない原因を分けて調べられます。

設定ファイルは主から自動検出される

Codexは主フォルダーを基準にAGENTS.md、skills、config.tomlを自動検出します。副フォルダーに同名ファイルがあっても、それを同じように自動検出するとは公式に示されていません。設定の探索順や優先順位を推測で補わないことが重要です。

副フォルダー固有の条件が作業に必要なら、依頼文で参照先を明示するか、その作業を行う間だけ適切なフォルダーを主に切り替えます。複数の指示を暗黙に混ぜるより、今回どの基準を使うかを一つ選ぶほうが、結果を再現しやすくなります。

Git関連の操作も主リポジトリが中心になる

公式手順では、Gitレビュー、プルリクエスト、worktreeに関する操作は主リポジトリを対象とします。worktreeでチャットを始めた場合も、ほかのフォルダーは添付されたままです。複数のコードを参照しつつ、履歴上の中心を一つに保てます。

副フォルダーも編集できるため、複数リポジトリに変更が分かれる可能性は残ります。変更前に対象ファイルを列挙し、変更後はリポジトリごとの差分と確認結果を分けて見ると、どこへ何が入ったかを見失いにくくなります。

複数リポジトリをまとめる3つの構成例

複数フォルダー対応が役立つのは、同じ成果物に関係するコードが別の場所に分かれている場面です。ここではアプリ、API、共通ライブラリを例に、主を変えた三つの構成を示します。いずれも、今回の完了条件が置かれている場所を主にする考え方で統一します。

アプリを主、APIと共通ライブラリを副にする

画面の表示や操作を変更し、その確認までを一つの依頼で進めるなら、アプリを主にします。APIは取得項目や応答形式を確認する副、共通ライブラリは型や共通処理を確認する副です。新しいチャットを画面側の指示から始められます。

たとえば新しい項目を画面へ表示する作業では、アプリのテストが最終的な合格条件になります。APIと型定義も同時に読めるため、存在しない項目を前提に画面だけを変更する失敗を減らせます。変更が不要な副は読み取りだけに限定します。

APIを主、アプリと仕様書を副にする

応答形式、入力検証、データ処理の変更が中心なら、APIを主にします。アプリは既存の利用箇所を調べる副、仕様書は期待する契約を確認する副です。API側の指示と確認方法を起点にしながら、利用側への影響を横断して調べられます。

この構成では、APIのテストを主な合格条件にし、アプリ側で影響を受ける箇所を検索します。仕様書が独立したフォルダーにある場合も添付できますが、無関係な資料群まで追加せず、今回参照する文書の範囲を先に決めておきます。

共通ライブラリの変更時だけ主を切り替える

型定義や共有部品そのものを変更する作業では、共通ライブラリを主へ切り替えます。アプリとAPIは利用箇所を確認する副です。ライブラリのテストと公開条件を中心に置き、利用側の互換性を同じプロジェクト内で調べられます。

変更が終わってアプリ側の調整へ移るなら、アプリを主に戻して確認します。主の切り替えは表示上の整理だけではなく、新しいチャットと設定検出の基準を変える操作です。切り替え後の前提を毎回確認することが欠かせません。

小さな案件で確認する5項目

導入確認では、複数フォルダーを追加できたことだけを合格にしません。検索、読み取り、編集、設定検出、主の切り替えという異なる働きを一つずつ確かめます。影響の小さい案件で結果を記録しておけば、本番規模へ広げたときの問題を切り分けやすくなります。

検索と読み取りを先に分けて試す

最初は副フォルダー内にある既知のファイル名を示さず、用途から検索できるかを確かめます。見つかったら、そのファイルと主フォルダー側の利用箇所を読み、関係を説明させます。検索できることと、内容を正しく結び付けられることを別々に見ます。

次に、対象ファイルを明示した確認も行います。用途から見つからない場合でも、場所を示せば読み取れるなら、添付範囲ではなく検索語やコード構造に原因があると考えられます。失敗の層を分けることで、不要なフォルダー追加を避けられます。

編集は破棄しやすい一箇所から始める

編集確認では、コメント、検証用の文言、専用の小さなテストなど、影響を限定できる対象を一つ選びます。変更前に触れるファイルを宣言し、変更後は主と副の差分をそれぞれ確認します。複数箇所を一度に変えないことがポイントです。

期待しない場所へ差分が出た場合は、その変更を広げず、なぜ対象に選ばれたかを確認します。副フォルダーが編集可能であることは便利ですが、関係するすべてを変える許可ではありません。依頼ごとに変更範囲を明示します。

主を切り替えた後の差を言葉にする

主を変更したら、新しいチャットの開始位置、設定検出、Git関連の対象をもう一度確かめます。副フォルダーの検索、読み取り、編集が引き続き可能かも確認します。どの働きが主に連動し、どれが添付状態に連動するかを説明できれば合格です。

結果が予想と違う場合は、対応OSや設定の優先順位を推測せず、公式手順と現在の画面を照合します。再現条件を残し、必要なら対象を一つのフォルダーへ戻します。小さな確認へ戻れる構成にしておくと安全です。

主フォルダーを選ぶ3つの判断基準

主フォルダー選びで迷ったら、完了条件、最初に読ませたい指示、変更後の確認回数という三つを見ます。単に規模が最大のリポジトリを主にする必要はありません。今回の依頼で最も多く判断する場所を中心にすると、作業の説明が短くなります。

完了条件を判定するコードがあるか

ユーザーが触る画面の完成が目的ならアプリ、APIの契約が目的ならAPI、共有部品の品質が目的なら共通ライブラリを主にします。どのテストや確認が通れば完了かを先に決めると、その合格条件に最も近い場所を選べます。

複数リポジトリに同じ重さの変更が必要でも、今回の成果を代表する一つは決められます。代表を主にし、ほかを副に置いたうえで、各リポジトリの変更と確認結果を分けて報告すると、中心と横断範囲を両立できます。

指示と設定を最初に読ませたいか

AGENTS.md、skills、config.tomlの自動検出は主を基準にします。製品固有の品質条件や確認方法が置かれている場所は、主の有力候補です。副側の設定も自動的に組み合わされると仮定せず、今回採用する基準を明示します。

作業の中心より設定の中心が重要な場合は、設定がある場所を主にし、実装対象を副に置く選択も考えられます。ただし、Git関連の対象も主へ寄るため、何を優先するかを決め、実際の変更先とのずれを確認しておきます。

変更後の確認を最も多く行うか

修正後にテスト、差分確認、関連箇所の再検索を最も多く行う場所は、主に向いています。作業のたびに副から主へ戻る説明が必要なら、中心の選び方が合っていない可能性があります。依頼の段階が変わったら主を見直します。

一方、主を頻繁に切り替えると、設定検出とGit関連の基準も動きます。一つの完了条件を終えるまでは主を固定し、次の段階へ移る区切りで変更するほうが比較しやすくなります。切り替え前後の確認結果も残してください。

複数フォルダー対応で避けたい3つの誤解

新機能を安全に使うには、「副は読むだけ」「副の設定も自動で使われる」「関連しそうなものは全部追加する」という三つの誤解を避けます。公式情報で確認できる範囲を押さえ、明示されていない優先順位や権限の継承を断定しないことが大切です。

副フォルダーは読み取り専用ではない

副フォルダーも検索と読み取りだけでなく、編集に利用できます。参照用として添付したい場合は、依頼文で「変更しない」と条件を付けます。機能上編集できることと、今回の作業で編集してよいことは別の判断です。

複数の副へ変更が及ぶ作業では、リポジトリごとに対象ファイルと確認方法を先に決めます。意図しない変更が混ざった場合に見つけられるよう、差分を別々に確認します。添付したという理由だけで変更範囲を広げないでください。

副フォルダーの設定は自動検出されない

副側のAGENTS.md、skills、config.tomlをCodexが自動で採用するとは、公式手順に書かれていません。必要な設定が副にある場合は、主を切り替えるか、読むべき場所を明示します。暗黙の優先順位を期待すると、確認しにくい差が生まれます。

設定が適用されたかは、ファイルが存在することではなく、実際の応答や変更方針が期待する条件に沿っているかで確かめます。重要な禁止事項やテスト条件は依頼にも明記し、自動検出だけに依存しない形にします。

無関係なリポジトリを同じプロジェクトへ集めない

複数フォルダーは、アプリと文書、ウェブサイトとバックエンドのような関連作業をまとめるための機能です。案件や目的が異なるコードまで一つへ集めると、検索結果と変更候補が増え、どこまでが今回の対象か分かりにくくなります。

関係の薄い作業や、チャットごとに一つの領域だけへアクセスさせたい場合は、公式案内どおり別プロジェクトに分けます。複数フォルダー対応の価値は、数を増やすことではなく、必要な横断範囲だけを一つの中心から扱える点にあります。

まとめ

ChatGPTデスクトップアプリ26.715の複数フォルダー対応により、Codexは関連する複数リポジトリを一つのローカルプロジェクトで検索、読み取り、編集できます。主は新しいチャット、Git操作、設定検出の基準となり、副は関連コードの参照・変更先になります。

まず完了条件に最も近いフォルダーを主にし、必要な副を二つか三つ追加してください。検索、読み取り、小さな編集、設定検出、主の切り替え後の差を順に確認し、結果を説明できてから対象を広げます。中心を一つ決めることが、複数リポジトリを扱いやすくする要点です。