Skip to content
Apothem
コンセプト

エージェントアーキテクチャ

Apothem が、フック面やルール形式の異なる 17 種類の AI ハーネスにわたって、単一のエージェント能力コホートをどのように投影するか。

これは開発者向けの技術仕様ページです。Apothem の内部語彙 —— アダプタークラス、マテリアライザー、伝播マニフェスト、姉妹規約への収束 —— を、一般の読者向けにやわらげることなくそのまま使用します。

Apothem は単一の共有プロファイル(~/.config/apothem/profile.yaml)を読み込み、 登録済みの 17 個のアダプター向けにハーネスネイティブな構成を生成します。 これらのハーネスはエージェント能力モデルを共有していません。すなわち、 ツール呼び出し前のフックを公開するものもあれば、フラットな .md ファイルから ルールを実行するもの、すべてのルールを単一の指示ファイルに埋め込むもの、 インストール時にプロファイル駆動の構成をレンダリングするものもあります。 このページでは、その相違点と、それをまたいで Apothem が適用する規律を整理します。

ハーネスごとのエージェント能力マトリクス

以下のマトリクスは 17 種類すべてのハーネスを対象とします。列は、各ハーネスが 公開する PreToolUse フック面、Apothem がルールを有効化するために用いる形式、 アダプタークラス(アダプタークラスの解説を参照)、 そしてアダプターがマテリアライザーを介してネイティブ構成をレンダリングするか どうかです。

ハーネスPreToolUse フック面ルール有効化形式アダプタークラスマテリアライザー
antigravityネイティブフック面は存在するが、Apothem はサポート資料のみGEMINI.md および Antigravity CLI プラグインルールクラス Iなし
claude-codeネイティブ PreToolUse / PostToolUse / Stop / SessionStartrules/ 配下のフラットな .md ルールクラス II-Aなし(ベンダー設定テンプレート)
codebuddyなし.codebuddy/rules/apothem-rules.md プロジェクトルールファイルクラス Iなし
codexネイティブ hooks.json ライフサイクルフックAGENTS.md およびインストール済みスキルが参照するサポートルールクラス Iなし
cursorなし.mdc ワークスペースルール(MDC フロントマター: description / globs / alwaysApply)クラス Iなし
gemini-cliなし単一の GEMINI.md に埋め込まれたルールクラス Iなし
github-copilotなし(IDE 拡張機能であり、ツール呼び出しフックなし).github/copilot-instructions.md 内のルールクラス Iなし
glmなし(モデルバックエンドであり、エージェントツール面なし).apothem/providers/glm.toml バックエンドプロバイダー構成(ルールコホートなし)クラス Iなし
hermesサポート資料のみconfig.yaml および外部スキルディレクトリクラス II-Bconfig.yaml
kimi-codeなしAGENTS.md および .kimi-code/.apothem/support/ 配下のサポートルールクラス Iなし
kiroなし(Kiro のエージェントフックはアダプターの対象外).kiro/steering/apothem-rules.md ステアリングファイルクラス Iなし
open-clawサポート資料のみopenclaw.json および追加スキルディレクトリクラス II-Bopenclaw.json
opencodeサポート資料のみプロファイルでレンダリングされた JSON およびネイティブのコマンド・スキル・エージェントクラス II-Bopencode.json
qwen-codeネイティブ PreToolUse / Stop / SessionStartQWEN.md およびネイティブのコマンド・スキル・エージェントクラス II-Bsettings.json / QWEN.md
traeなし.trae/rules/apothem-rules.md プロジェクトルールファイルクラス Iなし
windsurfなし.devin/rules/ 内のルールクラス Iなし
zedなしプロジェクトルートの .rules フラットファイルクラス Iなし

マトリクスに関する注記:

  • claude-code は参照アダプターです。ネイティブの PreToolUse、 PostToolUse、Stop、SessionStart フックを備え、ベンダー設定テンプレートを 同梱します。CLAUDE.md は意図的に管理しません —— そのファイルはオペレーターが所有する領域です。
  • codexhooks.json を通じてネイティブのライフサイクルフックを インストールし、エージェントを TOML に変換し、コマンドプロンプトを Codex スキルとしてラップし、config.toml はオペレーター所有のまま残します。
  • antigravity~/.gemini/GEMINI.md をグローバルコンテキストの アンカーとして保持し、~/.gemini/antigravity-cli/plugins/apothem/ 配下に Apothem プラグインをインストールします。フックファイルは、アダプターが Antigravity のフックスキーマ変換を担うまで、サポート資料として保持されます。
  • cursor は、ベンダーの MDC フロントマター(descriptionglobsalwaysApply)を備えた .mdc ファイルを介してルールを有効化します。 アダプターは単一ファイルの .cursorrules を書き込みません。
  • windsurf.devin/rules/ を使用します。アダプターは単一ファイルの .windsurfrules を書き込みません。
  • hermesopen-claw はネイティブ構成ファイルをレンダリングし、 各ハーネスが文書化しているスキルディレクトリ設定を通じて Apothem の サポートスキルディレクトリを接続します。サポートされていない共有コホートは、 Apothem が所有するサポートサブツリー配下に残ります。
  • qwen-code はコンテキストとフックディスパッチ用に文書化された settings.json キーをレンダリングし、その後 Qwen ネイティブの コマンド・スキル・エージェントディレクトリを使用します。

ハーネスをまたぐオーケストレーションの規律

Apothem は 姉妹規約への収束 を適用します。すなわち、同一の オペレーター起動可能なワークフローを、一つの共有形式に押し込むのではなく、 各ハーネスのネイティブな慣用表現へと投影します。claude-code 配下では フラットな .md ファイルとして有効化されるルールが、cursor 配下では .mdc ワークスペースルールに、gemini-cli 配下では GEMINI.md の 埋め込みセクションに、qwen-code では QWEN.md 内の連結参照と ネイティブな探索ディレクトリになります —— 意図は同じで、各ハーネスの方言で 表現されます。

正規マスターコホートは次の場所にあります:

src/apothem/{rules,commands,skills,agents,output-styles,hooks,conformity,statuslines}/

各アダプターはこのコホートのサブセットを伝播します。ハーネスごとの サブセットは src/apothem/lib/propagation-manifest.yaml で宣言されており、 このマニフェストは、どのアーティファクトがどのハーネスにどの形式で届くかに 関する唯一の信頼できる情報源です。アダプターがマニフェスト外のアーティファクトを 発明することはなく、マニフェストが、それをホストする面を持たないハーネスに アーティファクトを割り当てることもありません。

アダプタークラスの解説

Apothem は、共有プロファイルをハーネスネイティブな出力へ翻訳する方法に よって、アダプターを 3 つのクラスに分類します。

  • クラス I —— 生伝播。 アダプターは正規マスターアーティファクト (マニフェストで宣言されたサブセット)を、レンダリング工程なしに直接 ハーネスの構成場所へコピーします。マテリアライザーはありません。 antigravity、codebuddy、codex、cursor、gemini-cli、github-copilot、glm、 kimi-code、kiro、trae、windsurf、zed がクラス I です。
  • クラス II-A —— 生伝播 + ベンダー束縛の設定テンプレート。 アダプターは アーティファクトを生伝播し、加えてベンダーのスキーマに束縛された ベンダー固有の設定テンプレートを管理します。claude-code がクラス II-A です。
  • クラス II-B —— プロファイルでレンダリングされる単一面マテリアライザー。 アダプターは、マテリアライザーを通じて共有プロファイルを単一の ネイティブ構成面へとレンダリングします。hermes、open-claw、opencode、 qwen-code がクラス II-B です。

マテリアライズ時の挙動

クラスの区別は、マテリアライズ時 —— オペレーターがハーネスに対して CLI を実行するとき —— に現れます:

  • apothem install --harness <H><H> 向けのマニフェストサブセットを 伝播し、クラス II-A / II-B のアダプターについてはハーネスネイティブな 構成をレンダリングします。
  • apothem verify --harness <H> は、インストール済みの構成を、現在の プロファイルが生成するであろうものと照合し、ずれを報告します。
  • apothem doctor は、登録済みの全アダプターにわたってハーネスごとの ステータス —— インストール済み / 不在 / ずれあり —— を報告します。

完全なコマンド面については CLI リファレンス を 参照してください。

相違点の分類体系

17 種類のハーネスは 3 つの軸に沿って相違します。マトリクス内の ハーネスごとの違いは、いずれもこのうちの一つに帰着します。

17 種類のハーネスにわたって観測される範囲
フック面ネイティブな複数イベント(claude-code、codex、qwen-code)→ サポートのみのフック資料(antigravity、gemini-cli、hermes、open-claw、opencode)→ なし(codebuddy、cursor、github-copilot、glm、kimi-code、kiro、trae、windsurf、zed)
ルール有効化形式フラットな .md(claude-code)→ プラグインルール(antigravity)→ .mdc ワークスペース(cursor)→ ディレクトリルール(codebuddy、trae、windsurf)→ ステアリングファイル(kiro)→ プロジェクトルートのフラットファイル(zed)→ 単一の埋め込みファイル(codex、gemini-cli、github-copilot、kimi-code)→ 構成から参照されるサポート資料(hermes、open-claw、opencode、qwen-code)→ バックエンドプロバイダー構成(glm)
アダプタークラスクラス I 生伝播 → クラス II-A 生伝播 + ベンダー設定 → クラス II-B プロファイルレンダリングの単一面

Apothem の役割は、これら 3 つの軸がハーネスごとに変化するあいだ、 一貫した単一のオペレーター意図を保ち続けることです。伝播マニフェストと アダプタークラスの契約こそが、その意図を相違をまたいで安定させる 2 つの仕組みです。

On this page