正本を決めたら、次は配信経路を決める
rule.md だけを人間が編集する
前回 は、Codex と Claude Code の global instruction を手で同期するのをやめて、rule.md を正本にするところまでを書きました。
今回は、その rule.md を実際に ~/.codex/AGENTS.md と ~/.claude/CLAUDE.md へ配る流れを書きます。自分用の agent-config-core では、書き手が触るのは rule.md だけにして、配信先の2ファイルは生成物として扱います。
構成は小さくしています。
agent-config-core/
├── rule.md # Source of Truth（共通ルール本文）
├── deploy.sh # rule.md を 2 ターゲットへ配信
├── validate.py # secret や private path らしい文字列の検査
├── test.sh # 一時 home で deploy.sh を空試行
├── LICENSE
└── README.mdこのくらいの構成なら、あとから読み返しても「どこを直せばよいか」がすぐ分かります。
deploy だけに責務を集めすぎない
配信コマンドを 1 つにまとめると便利ですが、いきなり本番反映だけを用意すると少し怖いです。そこで、反映前に見る段階を分けました。
validate.py:rule.mdの中身を検査するtest.sh: 一時 home で配信結果を確認するdeploy.sh: 本番の home に反映する
この3段階にしておくと、「内容がおかしい」「配信先が違う」「本番反映したい」のどこにいるかが分かりやすくなります。
反映前に validate.py で見る
secret や private path を混ぜない
rule.md は公開 repository に置ける前提で作っています。だから、secret、token、private path、会社や案件の生情報は入れません。
validate.py は、その前提を破らないための最低限の検査です。完璧な情報漏えい防止ではありませんが、うっかり混ぜやすい文字列を先に見つける役割があります。
python3 validate.pyここで引っかかったら、rule.md の書き方を見直します。配信先にコピーする前に止められるので、心理的にも扱いやすいです。
検査で守れる範囲を過信しない
この手の検査は、最後の防波堤ではなく最初の確認です。公開できない内容を rule.md に入れない、という前提は人間側で守る必要があります。
自分は、rule.md には公開してよい汎用ルールだけを書くことにしました。端末固有の path や private な補足は、別の overlay 側に置きます。ここを混ぜると、また「どこまで公開してよいか」を毎回考えることになります。
test.sh で一時 home に配る
本番 home を触る前に空試行する
次に、test.sh で一時 home を作って deploy.sh の動きを見ます。
./test.sh本番の ~/.codex/AGENTS.md や ~/.claude/CLAUDE.md を触る前に、一時 directory に配信して、ファイルが期待通り作られるかを確認します。ここで見たいのは、本文の正しさというより、配信先とファイル生成の動きです。
この段階を挟むと、新しい端末で初めて使うときも落ち着いて進められます。自分の home directory を直接触る前に、配信の形だけ確認できるからです。
配信先は生成物として扱う
test.sh で確認する配信先も、本番の配信先も、どちらも生成物です。人間が長期的に編集する場所ではありません。
この割り切りがあると、レビュー対象が小さくなります。見るべきものは rule.md と配信 script で、生成後の2ファイルを別々に育てる必要はありません。
deploy.sh で本番反映する
2ターゲットへ同じ内容を配る
最後に、本番反映です。
./deploy.shdeploy.sh は rule.md を読み、~/.codex/AGENTS.md と ~/.claude/CLAUDE.md の 2 ターゲットへ同じ内容をコピーします。ここで大事なのは、片方だけ特別扱いしないことです。
Codex 用の表現と Claude Code 用の表現を別々に作り込むと、また同期対象が増えます。両方に読ませたい共通の前提だけを rule.md に置き、それを同じ内容で配る。差分を作らないことが目的です。
端末を増やしても同じ流れにする
端末を増やしたときも、やることは変えません。
git pull
python3 validate.py
./test.sh
./deploy.sh新しい端末でも、既存端末でも、同じ順番で確認します。端末ごとの配信先は local file ですが、正本は repository 側の rule.md なので、git pull してから配るだけです。
この形にしてから、片方のエージェントだけ古い指示で動くことはかなり減りました。自分が気にする対象が rule.md に寄ったからです。
この形にした理由
履歴は rule.md の git 側で追う
何をいつどう変えたかは、rule.md の git history を見れば分かります。配信先の ~/.codex/AGENTS.md と ~/.claude/CLAUDE.md は端末ローカルの生成物です。
この線引きをしておくと、後から「なぜこのルールを足したのか」を追いやすくなります。端末ごとの差分ではなく、正本の差分だけを見ればよいからです。
ライブラリ部分は別サイクルで足せる
rule.md は、両エージェントに常時読ませたい前提の置き場です。再利用可能な作業手順やレビュー手順まで全部入れると、すぐに重くなります。
そこで、作業手順は persona-skills-core という別 repository に切り出しました。agent-config-core は単独でも動き、必要になったら skill 管理の repository を任意で接続する。最初から全部入りにしない方が、あとで扱いやすいと判断しました。
続きはこちら
次の記事では、rule.md では持ちきれない「再利用したい作業手順」を、Codex と Claude Code の両方から呼べるようにする話へ進みます。