コンテンツにスキップ
LinkedInX

Claude CodeとCodexの共通ルールをshared/で管理する

パステルのリング惑星と軌道を背景に「Claude CodeとCodexの共通ルールをshared/で管理する」を配置した記事カバー パステルのリング惑星と軌道を背景に「Claude CodeとCodexの共通ルールをshared/で管理する」を配置した記事カバー

この記事で学べること

  • Claude CodeとCodexの共通方針をshared/へ集約する理由
  • rules・skills・workflowを役割ごとに分けるディレクトリ設計
  • 正本とツール別アダプターを分け、更新漏れを減らす運用方法

Claude CodeとCodexの共通ルールはshared/に集約する

Claude CodeとCodexへ同じ方針を渡すには、共通ルールの正本と、各ツールが読み込むアダプターを分けます。このリポジトリでは、方針をshared/へ集約し、rules、skills、workflowを役割別に配置しています。重複コピーを減らしても、参照経路と同期確認は別途必要です。

この記事では、「共通ルールの正本とツール別の読込ファイルをどう分けるか」という問いに焦点を当て、実行前の前提、作業手順、完了を確かめる方法を扱います。

最後まで読むと、「共通ルールの正本とツール別の読込ファイルをどう分けるか」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。

shared/を正本にしてツール別アダプターへ接続する

共通ルール、Skill、ワークフローをshared/へ置き、Claude CodeとCodexには薄い接続だけを残します。

ハーネス(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つだけ、またはルールが少数で変化しない場合は、このディレクトリ分割が管理負荷を増やすことがあります。