Claude CodeとCodexの共通ルールをshared/で管理する
この記事で学べること
- Claude CodeとCodexの共通方針を
shared/へ集約する理由 - rules・skills・workflowを役割ごとに分けるディレクトリ設計
- 正本とツール別アダプターを分け、更新漏れを減らす運用方法
Claude CodeとCodexの共通ルールはshared/に集約する
Claude CodeとCodexへ同じ方針を渡すには、共通ルールの正本と、各ツールが読み込むアダプターを分けます。このリポジトリでは、方針をshared/へ集約し、rules、skills、workflowを役割別に配置しています。重複コピーを減らしても、参照経路と同期確認は別途必要です。
この記事では、「共通ルールの正本とツール別の読込ファイルをどう分けるか」という問いに焦点を当て、実行前の前提、作業手順、完了を確かめる方法を扱います。
最後まで読むと、「共通ルールの正本とツール別の読込ファイルをどう分けるか」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。
shared/を正本にしてツール別アダプターへ接続する
ハーネス(AIに渡すルール、作業手順、検証方法をまとめた仕組み)エンジニアリングを進めていくと、AIに渡すルールファイルが増えていきます。最初は1ファイルで管理できていたものが、内容の追加とともに肥大化し、「どこに何が書いてあるか」がわかりにくくなります。
このサイトでは、CLAUDE.mdが長くなりすぎる問題に直面しました。禁止ルール、コンテンツの書き方、デプロイ手順、レビュー基準を1ファイルへ重ねると、重要なルールが埋もれます。
特定の作業に関係するルールだけをAIへ渡したくても、1ファイルに混在していれば不要な情報まで含まれます。
shared/ディレクトリの構造
この問題の対処として、このリポジトリでAIに参照させたい共有ファイルを shared/ という独自ディレクトリに集め、その中を役割で分類する設計にしました。
新入社員に渡すマニュアルで例えると:
shared/rules/→ 「会社の規則と禁止事項」shared/skills/→ 「各業務の手順書」shared/workflow/→ 「複数ステップの作業フロー」
この3つの分類を使います。
rules/に共通ルールを置く
禁止事項と方針を記録するファイル群です。「何をしてはいけないか」「このプロジェクトではどのような方針を取るか」を記述します。
たとえば content-i18n.md(コンテンツの言語方針)、no-ui-regression.md(UI変更の禁止範囲)、build-and-deploy.md(デプロイの制約)などです。ルールは条件ではなく方針として書き、AIが判断に迷わないよう明確にします。
skills/に再利用する作業手順を置く
特定のタスクを実行するための手順書です。新入社員が「この作業はどうやるんだっけ」と参照するマニュアルに相当します。
blog-writing/SKILL.md(ブログ記事の書き方)、editorial-review/SKILL.md(編集レビューの手順)などが該当します。AIはタスクを開始するときに関連するスキルファイルを参照し、手順に沿って作業を進めます。
workflow/に作業の順序を置く
複数のステップをまたいで進める作業フローを記述するファイル群です。ルールやスキルが単一のルール・手順であるのに対し、ワークフローは「最初から最後までの作業の流れ」を示します。
たとえば「記事を書いてから翻訳し、レビューして公開する」という一連の流れを記述するファイルです。
shared/への集約でClaude CodeとCodexのルール差分を減らす
ファイルを役割で分類することで、起点となる指示ファイルやadapterから明示的に参照したときに、AIが「今の作業に必要な情報はどこにあるか」を把握しやすくなります。
CLAUDE.mdには「詳細はshared/rules/content-i18n.mdを参照」という形で参照先だけを書き、詳細を別ファイルに移動できます。CLAUDE.mdをコンパクトに保ちながら、必要な情報はすべてshared/配下に整理されている状態です。
また、ファイルが役割ごとに分かれていると、ルールを更新したいときに「どのファイルを変更すればよいか」が明確です。すべてが1ファイルにある状態では、1つの変更が他の記述に意図せず影響する場合があります。
共有ルールの正本とツール別アダプターを分けて更新する
shared/ディレクトリを設計するときに重要なのは、「どこに何を置くか」の基準を最初に決めることです。基準がないと、ファイルが増えるにつれて分類が曖昧になります。
私が使っている判断基準は次のとおりです。
- 「やってはいけないこと」や「このプロジェクトの方針」→
rules/ - 「この作業の手順」→
skills/(サブディレクトリにSKILL.mdとして置く) - 「複数ステップにわたる作業フロー」→
workflow/
判断に迷う内容は、まず rules/ に入れて、後で必要であれば分類を変えます。
まとめ:共通方針をshared/へ集約し、アダプターだけをツール別に保つ
ルールファイルが増えたら、役割で分類します。shared/rules/は禁止事項と方針、shared/skills/は作業手順、shared/workflow/は複数ステップの流れを保持します。
参照経路が明確になれば、AIは必要な情報を見つけやすくなり、CLAUDE.mdも短く保てます。更新対象も特定しやすくなります。
最初に、Claude CodeとCodexへ重複して書いているルールを1つ選び、共通の正本と参照先へ分けます。利用するツールが1つだけ、またはルールが少数で変化しない場合は、このディレクトリ分割が管理負荷を増やすことがあります。