実際に移行されるもの
コンテンツは移行されますが、構造は移行されません。 Kiroのワークスペースステアリングは .kiro/steering/ に、グローバルステアリングは ~/.kiro/steering/ に、どちらもプレーンな .md ファイルとして保存されています。Codexは AGENTS.md ファイルを読み込みます。文章自体は編集なしで移行できますが、問題はそれをどこに配置するかです。
「1ディレクトリにつき1ファイル」が支配的な制約です。 Codexの検出プロセスは探索（ウォーク）です。「プロジェクトのルート（通常はGitのルート）から開始し、Codexは現在の作業ディレクトリまで探索します... パス沿いの各ディレクトリにおいて、AGENTS.override.md、次に AGENTS.md、そして project_doc_fallback_filenames に指定されたフォールバック名の順にチェックします。Codexは1ディレクトリにつき最大1つのファイルを含めます。」
1つのパスにある6つのステアリングファイルは、最大でも1つのファイルになります。これらを1つのルート AGENTS.md に結合するか、あるいはそれらが制御するコードが存在するディレクトリに分散させるかのどちらかになります。そして、後者の選択肢こそがCodexのモデルが想定している設計です。
グローバルステアリングは「最初のファイル」ルールでマッピングされます。 Codexのホームディレクトリにおいて、「AGENTS.override.md が存在すればそれを読み込みます。存在しない場合は AGENTS.md を読み込みます。Codexはこのレベルで最初の空でないファイルのみを使用します。」したがって、個人用ルールを格納していた ~/.kiro/steering/ ディレクトリは、正確に ~/.codex/AGENTS.md という1つのファイルになります。オーバーライドファイルは一時的な切り替えに便利です。「ベースファイルを削除せずに一時的なグローバルオーバーライドが必要な場合は、~/.codex/AGENTS.override.md を使用してください。」
マージ順序が明記されていますが、これは一部の人が想定する順序とは逆です。 「Codexはルートから順にファイルを結合し、空行で連結します。現在のディレクトリに近いファイルほど、結合されたプロンプトの後半に表示されるため、以前のガイダンスを上書きします。」後勝ちです。これは「具体的なルールは一般的なルールに勝る」というKiroの直感にきれいにマッピングされますが、優先度ルールではなく、結合されたプロンプト内での位置によって実現されています。
Kiroの4つのインクルージョンモードには、Codexにおける同等機能がありません。 これは実質的な損失であるため、何を諦めることになるのかを整理しておく価値があります。
inclusion: always はデフォルトであり、直接マッピングされます。これらのファイルはKiroでも無条件であり、Codexでも無条件のままです。
fileMatchPattern を伴う inclusion: fileMatch は、「指定されたパターンに一致するファイルを操作しているときのみ」ファイルを読み込みます。ドキュメントにはその理由が明確に記されています。「これにより、必要なときだけ専門的なガイダンスを読み込むことで、コンテキストの関連性を維持し、ノイズを減らします。」Codexにはパターンをトリガーとする読み込みはありません。fileMatch ファイルは、常に読み込まれるか、まったく読み込まれないかのどちらかになります。
inclusion: manual ファイルは、「チャットメッセージ内で #steering-file-name を使って参照することでオンデマンドで利用可能」になり、「スラッシュコマンドとしても表示」されます。Codexにはオンデマンドでの指示の添付機能はありません。
名前と説明を持つ inclusion: auto は、関連性ベースのモードです。これも存在しません。
Kiroは、これらのモードが存在する理由を直接的に説明しています。それらは「パフォーマンスを最適化し、必要なときに関連するコンテキストを確実に利用できるようにする」のに役立ちます。これらを取り除くということは、残したすべてのファイルに対して、実行するたびにコスト（コンテキスト量）を支払う必要があることを意味します。
AGENTS.md は、Kiroの内部であってもすでにCodexのように動作しています。 Kiroはこの標準をサポートしていますが、ドキュメント化された違いが1つあります。「AGENTS.md ファイルはインクルージョンモードをサポートしておらず、常に含まれます。」Kiroの設定の一部がすでに AGENTS.md にある場合、その部分はそのままコピーするだけであり、すでに無条件読み込みの状態で運用していたことになります。
バイト制限は、誰も予想しない失敗モードです。 「Codexは空のファイルをスキップし、結合されたサイズが project_doc_max_bytes（デフォルトは32 KiB）で定義された制限に達するとファイルの追加を停止します。」停止するのです。警告は出ません。ドキュメントに記載されている解決策はどちらも利用可能です。「制限に達した場合は、制限を引き上げるか、ネストされたディレクトリに指示を分割してください。」
ここで2つの事実を組み合わせて考えてみましょう。Kiroユーザーは通常、同等のCodex環境よりも多くのステアリングテキストを保持しています。これはまさに、インクルージョンモードのおかげで大量のテキストを低コストで保持できたからです。それを無条件のファイルにフラット化すると、予想よりも早く32 KiBに達してしまいます。これは、why Codex skips your AGENTS.md rules の背景にある、警告なしの不足と同じ種類の問題です。
スペック（仕様）は移行されません。 Kiroのスペックは構造化された成果物です。すべてのスペックは .kiro/specs/<name>/ の下に requirements.md、design.md、tasks.md を生成し、ユーザーストーリー、アーキテクチャ、および個別の実装タスクを追跡します。Codexにはこれらを受け取るスペックシステムがありません。ファイルはMarkdownなので、必要であればリポジトリに残りますが、エージェントが進捗を追跡するアクティブな成果物ではなくなります。
クラウドステアリングには、知っておくべき制限があります。 Web上でKiroを使用していた場合、「『グローバルステアリング』はローカルの ~/.kiro/steering/ ディレクトリを指し、クラウドのサンドボックスはこれを読み取ることができません」という点に注意してください。これが、Kiroがクラウドセッション用にConfiguration Sync（設定同期）を提供している理由です。CodexのグローバルファイルはCodexを実行しているマシン上に存在するため、どこで実行する場合でも同様の疑問が生じます。」
手動移行の手順
ステップ 1: トピックごとではなく、配置場所ごとに再構成する
すべてを1つのルート AGENTS.md に結合したいという衝動を抑えてください。それは最も簡単な方法ですが、確実にバイト制限に直面することになります。
代わりに、ステアリングファイルをそのガイダンスが適用される場所ごとに分類し、それぞれが制御するディレクトリに配置します。fileMatchPattern が "app/api/**/*" であったステアリングファイルは、app/api/AGENTS.md になります。"src/components/**/*" を対象としていたものは、src/components/AGENTS.md になります。Codex自身の推奨事項もこれと一致しています。「Codexは現在のディレクトリに達すると探索を停止するため、オーバーライドは専門的な作業にできるだけ近い場所に配置してください。」
これにより、fileMatch が行っていたことの大部分を補うことができます。すべてではありません（Codexはエージェントが読み込むファイルではなく、作業ディレクトリをトリガーにするため）。しかし、app/api で作業している開発者にはAPIのガイダンスが適用され、コンポーネントのガイダンスは適用されません。これこそが目的だったはずです。
真に普遍的なコンテンツについては、1つのルート AGENTS.md を作成し、短く保ちます。技術スタック、コーディング規約、ビルドおよびテストコマンドなどです。ここには inclusion: always のファイルのみを移動し、それ以外は配置しないでください。
ネストされたディレクトリが、上位のガイダンスを拡張するのではなく置き換える必要がある場合は、そのディレクトリで AGENTS.override.md を使用します。Codexはそれを最初にチェックし、同じ階層の AGENTS.md の代わりに使用します。
実用的な注意点が2つあります。リポジトリですでに別のファイル名を使用している場合は、名前を変更するのではなく、登録してください。~/.codex/config.toml に project_doc_fallback_filenames = ["TEAM_GUIDE.md", ".agents.md"] を記述すると、Codexはこれらを指示ファイルとして扱います。ドキュメントでは「このリストにないファイル名は、指示の検出において無視されます」と警告されています。また、GitHubでCodexのコードレビューを使用している場合、レビューのルールは「ルールが制御するコードに最も近い AGENTS.md 内」の ## Code Review Rules セクションに記述する必要があります。
ステップ 2: manualファイルとautoファイルの扱いを決定し、結果を測定する
inclusion: manual および inclusion: auto ファイルは、行き場を失ったファイルです。これらはトラブルシューティングガイド、移行手順、「たまにしか必要とされないコンテキストの重いドキュメント」などであり、これこそがKiro自身が説明するmanualモードに最適なものでした。
これには、3つのまともな選択肢と、1つの悪い選択肢があります。1つ目は、それらを無条件に昇格させ、実行するたびにコストを支払うこと。2つ目は、ネストされたディレクトリに配置し、誰かがそこで作業するときだけ読み込まれるようにすること。3つ目は、エージェントが求められたときに読み取る通常のリポジトリドキュメントとして残すことで、これが元の挙動に最も近くなります。悪い選択肢は、それらをルートファイルに結合することです。これを行うと、すぐに32 KiBに達し、本当に必要なガイダンスが失われ始めます。
その後、検証を行います。Codexにはその方法が正確にドキュメント化されており、再構成の後にこのステップをスキップすべきではありません。
リポジトリのルートから codex --ask-for-approval never "Summarize the current instructions." を実行し、グローバルファイルとプロジェクトファイルが優先順位通りに表示されることを確認します。codex --cd subdir --ask-for-approval never "Show which instruction files are active." を実行して、ネストされたオーバーライドが広範なルールを置き換えていることを確認します。完全な監査を行うには、「codex -c log_dir=./.codex-log を使用してプレーンテキストのTUIログを有効にし、./.codex-log/codex-tui.log を確認」します。
これが思ったよりも簡単な理由は2つあります。キャッシュと戦う必要はありません。「Codexは実行するたびに（および各TUIセッションの開始時に）指示チェーンを再構築するため、手動でクリアするキャッシュはありません。」また、ガイダンスが切り捨てられているように見える場合、ドキュメントには直接的な解決策が示されています。project_doc_max_bytes を引き上げるか、ネストされたディレクトリに分割することです。
設定を行う際は、Codex独自のメモリレイヤーについても別途検討してください。これは存在しますがデフォルトではオフになっており、その独自の挙動を理解する価値があります。turning on Codex's local memories では、保持される内容とその制御方法について解説しています。
より良い方法：事実に対する「コンテキスト家賃」の支払いをやめる
上記はすべて実際の再構成作業であり、Kiroでは決して強要されなかったトレードオフ、すなわち「どのガイダンスを実行のたびに読み込む価値があるか」という選択を迫られることになります。
このトレードオフが存在するのは、指示と事実が同じ場所に保存されているからです。指示は短く、行動に関するものです（例：「ここで make test-payments を実行する」、「セキュリティに通知せずにキーをローテーションしない」）。事実は長く、参照用のものです（例：なぜAPIがパスでバージョン管理されているのか、社内用語の意味、どのサービスがどのキューを所有しているか）。Kiroでは、インクルージョンモードによって事実を低コストで保持できたため、両方をステアリングに含めることができました。しかしCodexでは、32 KiBの上限に対して、実行のたびにそれらのコストが課されます。
これらを分割すれば、上限を気にする必要はなくなります。AGENTS.md ファイルは小さく行動に関するものだけに留め、事実はエージェントが必要に応じて読み取るストアに保存します。MemoryLake は3つのステップでセットアップできます。
ステップ 1: APIキーを作成する
サインインし、ダッシュボードからAPIキーを生成します。これは指示チェーンの一部ではないため、保持されている内容が project_doc_max_bytes にカウントされたり、ネストされたディレクトリに複製したりする必要はありません。
ステップ 2: 最初のメモリをアップロードする
ここが、manual および auto ステアリングファイルの本来の居場所です。トラブルシューティング手順、アーキテクチャ上の決定とその背景、ドメイン用語、移行手順書、レビューで何度も繰り返している回答などです。
行動に関するルールは AGENTS.md に残します。コマンド、規約、およびすべての実行で適用されるべきルールこそが、指示チェーンの本来の目的です。
ステップ 3: AIとエージェントを接続する
Codexをストアに向けます。たまにしか必要とされないガイダンスが、常駐することなく利用可能になり、ルートファイルは上限を大幅に下回るサイズに収まります。そして、常に適用されるべきガイダンスは、実際に従うことができるほど十分に短くなります。これこそが、why agents ignore your instruction files で解説しているポイントです。
実務における変化
最初の変化は、32 KiBが設計上の制約ではなくなることです。現状では、エージェントに知っておいてほしいすべての事実が、従わせたいすべての指示と、1つの予算内で競合しています。
2つ目は、インクルージョンモードを失うことによる損失が少なくなることです。fileMatch はディレクトリ配置によって部分的に回復可能ですが、manual と auto は不可能です。そして、常に読み込まれるファイルよりも、ストアの方が「オンデマンドで利用可能」という本来の挙動にずっと近い存在です。
3つ目は、スペックがデッドエンド（行き止まり）にならなくなることです。Kiroの requirements.md、design.md、tasks.md には、実際の決定事項や推論が保持されています。Codexにはこれらを追跡する機能はありませんが、その中の決定事項は、まさに読み取り可能な状態に維持する価値のある永続的な知識です。これは turning project docs into AI memory で主張されている通りです。
KiroからCodexへの移行におけるベストプラクティス
- 結合するのではなく、分散させる。 Codexは1ディレクトリにつき最大1つのファイルしか含めないため、ガイダンスはそれが制御するディレクトリに配置します。
- ルートファイルは短く保つ。
inclusion: alwaysのコンテンツのみをそこに配置します。 fileMatchを配置場所に変換する。app/api/**/*というパターンはapp/api/AGENTS.mdになります。- 拡張ではなく置き換えのために
AGENTS.override.mdを使用する。 Codexは同じディレクトリ内のAGENTS.mdよりも前にこれをチェックします。 - 名前を変更する代わりに、代替ファイル名を登録する。
project_doc_fallback_filenamesを設定するとCodexがそれらを読み込みます。リストにない名前は無視されます。 - 制限を意識して監視する。 読み込みは警告なしに
project_doc_max_bytes（デフォルトは32 KiB）で停止します。制限を引き上げるか、分割してください。 - ドキュメントに記載されたコマンドで検証する。
codex --ask-for-approval never "Summarize the current instructions."や--cd subdirバリアント、さらに監査用のTUIログを使用します。 - スペックをそのまま移植しようとしない。 ファイルはドキュメントとして残し、その中の決定事項をエージェントが実際にアクセスできる場所に抽出します。
結論
Codexの指示モデルは、意図的にKiroよりもシンプルに設計されています。ツリーを探索し、1ディレクトリにつき1つのファイルを取得し、結合し、32 KiBで停止します。シンプルさは機能であり、移行は主に「地理的」な問題、つまり各ガイダンスをそれが制御するコードが存在する場所に配置することに帰結します。
移行できないのは条件付き読み込みであり、これは後から気づくのではなく、事前に計画しておくべき部分です。分散できるものは分散し、Codexが提供するコマンドで検証し、たまにしか参照しない資料は、実行のたびにコストがかからない場所に移動してください。