ハーネスをまたいだ規約の収束
ベンダーごとに設定フォーマットと実施面が異なるなかで、Apothem がいかにして 1 つの操作者ワークフローを 17 のハーネスにわたり一貫させるか。
17 のハーネス、設定がどこに置かれどんな形をとるかについての 17 通りの見解。Apothem の 仕事は、操作者のワークフローをすべてのハーネスで同一に感じさせることです——規約は一度 書くだけで、Claude Code を使おうと Cursor を使おうと Gemini CLI を使おうと、同じように 振る舞います。本稿では、Apothem が調停する 2 つの分岐を扱います。設定フォーマットと 実施面です。
フォーマットの分岐
各ハーネスは、それぞれ異なるファイル形態からルールを読み込みます。Apothem の プロファイルは、操作者の意図を 1 つの中立な形で保持します。各アダプターはその意図を、 自分のハーネスが期待する形態へとレンダリングします。
| 形態 | ハーネス（例） | Apothem が出力するもの |
|---|---|---|
ディレクトリ内のフラットな .md ルールファイル | claude-code | ハーネスのルールツリーへそのままコピーされるルールファイル |
| ルールディレクトリ内の 1 つに統合されたルールファイル | windsurf、trae | ハーネスが読み取るアクティベーションのフロントマターを持つ 1 つの apothem-rules.md ファイル |
Cursor の .mdc ルール | cursor | Cursor が期待するメタデータヘッダーを伴う 1 つの .mdc ルールファイル |
| 単一ファイルの指示ドキュメント | codex、gemini-cli、github-copilot、zed | プロファイルのルールセットから組み立てられた、連結された 1 つのドキュメント——AGENTS.md、GEMINI.md、copilot-instructions.md、.rules |
フラットな .md ハーネスはルールをそのまま受け取ります。統合ファイルのハーネスは、
ルールがいつ適用されるかをフロントマターで設定する 1 つのルールファイルを受け取ります。.mdc
ハーネスは、ルールファイルの先頭に Cursor のメタデータヘッダーを必要とします。単一ファイルハーネスは、ルールセット全体を
安定した節順序で 1 つのドキュメントへと平坦化する必要があり、それによって操作者は
ターゲットを問わず同じ規約を同じ順序で読めます。中立なプロファイルが唯一の真実の
源です。分岐は各アダプターのレンダリング段階にのみ存在します。
節順序が収束のアンカー
多数のルールを 1 つのドキュメントへ平坦化すると、ハーネス間で順序が入れ替わる恐れがあり、
同じ規約が GEMINI.md とは異なる順序で AGENTS.md に落ちてしまいます。Apothem は
順序をプロファイルのレベルで固定します。ルールセットは宣言された並びを持ち、すべての
単一ファイルアダプターはその順序でそれを巡回します。あるハーネスで「命名規約はコミット
規約より前に来る」と覚えた操作者は、他のどのハーネスでも同じ並びを見つけます。収束は
レンダリングの偶然ではなく——プロファイルが固定する性質です。
実施の分岐
設定フォーマットは目に見える半分です。より難しい半分は実施です。操作者（または エージェント）が行動するその瞬間に、規約をどう責任を持って守らせるかです。
ネイティブな PreToolUse フック
claude-code、codex、qwen-code はネイティブなフック面を公開しています。PreToolUse フックはツール呼び出しが実行される前に発火し、それを検査し、ブロックまたは書き換えます。 これはリアルタイムの実施です。「計画成果物をグローバルな場所に書き込むことを禁ずる」 というルールは、書き込みがディスクに触れる前にそれを拒否するフックになります。Apothem はこれらのフックをハーネスのフック設定へ直接マテリアライズするので、規約はハーネスのランタイムによって 実施されます。
その他のハーネスではラッパーに基づく規律
残りのハーネスは、Apothem が所有する同等の実行前フック面を公開していません。ハーネスがそのための ソケットを一切提供しないところに、Apothem はランタイムのゲートを設置できません。代わりに、 規約はマテリアライズされた設定の中の指示テキストとして運ばれます——エージェントはルールを読んで それに拘束されますが、違反する動作を傍受するランタイムの仕組みはありません。Apothem は 等価性が存在するかのように装うのではなく、違いを明示します。フックに支えられた規約と 指示に支えられた規約は同じ保証ではなく、操作者はどのハーネスがランタイムで実施し、どの ハーネスが指示による規律に頼るのかを見て取れます。
収束が実際に意味すること
操作者は 1 つの規約を書きます。Apothem はそれを 17 のフォーマットへとレンダリングし、 各ハーネスがサポートする最も強い実施を付与します——面が存在する場所ではネイティブな フック、存在しない場所では指示テキストです。ワークフローは収束し、保証はハーネスごとに 正直に述べられます。
だからこそ apothem verify は全体にわたって重要です。ランタイムのフックがドリフトを
捉えられない場所では、操作者は verify を実行して、プロファイルから逸脱したハーネス設定を
検出します。verify コマンドは、ネイティブな実施を欠くすべてのハーネスにとっての収束の
バックストップです。
各ハーネスの実施面は ハーネス で、アダプターの仕組みは アダプター設計の詳細解説 で読めます。