すべてのエージェントシステムは、同じ厄介なトレードオフに直面します。コードレビューやGitの履歴に耐えうる、深く整理されたナレッジベースが欲しい一方で、ランタイムは高速で集中力を維持している必要があります。これら2つのニーズは互いに相反します。指示を保存すればするほど、それらすべてをプロンプトに放り込んで、あとはうまくいくのを祈るという誘惑に駆られます。しかし、その「祈り」には高い代償が伴います。
Agent Project Contextのエコシステムにおいて、この緊張関係は2つのレイヤーに明確に分かれています。APCは耐久性を、APXは速度を担当します。両者がどのように相互作用するか、そしてなぜAPXがあえてすべてのスキル定義をプリロードしないのかを理解することは、多くの最適化ガイドが教えるよりも多くのことをプロンプトエンジニアリングについて教えてくれます。
アーカイブとエンジン
APCの役割は永続性です。再利用可能なスキルファイルを、プレーンなMarkdownドキュメントとして .apc/skills/ 配下に保存します。これらのファイルはリポジトリ内に存在するため、バージョン管理と共に扱われます。デプロイ手順を変更するプルリクエストを作成したり、6週間前のセキュリティポリシーのロールバックをdiffで確認したりできます。エージェントが「いつ、何を」知っているべきだったのかを正確に監査することも可能です。不適切なデプロイが実行された際や、コンプライアンス監査官から質問を受けた際、このレビューのしやすさは極めて重要になります。
一方、APXは「今この瞬間」を生きています。ユーザーとモデルとの実際の会話を管理するのがその役割です。その目的は知識をアーカイブすることではなく、知識を正確に使用することにあります。APXがスキルを「永続的な荷物」として扱うと、システム全体が低速化します。コンテキストウィンドウが埋まり、トークンコストが上昇します。さらに悪いことに、モデルの注意力が現在のリクエストとは無関係な指示へと分散してしまいます。
だからこそ、スキルの本体はオンデマンドでロードされるのです。
肥大化したプロンプトの真のコスト
ほとんどのチームは、トークンにコストがかかることを理解しています。しかし、無関係なトークンが「精度」を損なうということに気づいているチームはわずかです。
APXが利用可能なすべてのスキルを毎ターン注入すると、プロンプトはノイズだらけになります。モデルは、デプロイのランブック、セキュリティガイド、APIスタイルリファレンス、テストチェックリスト、オンボーディングのFAQを一度に受け取ることになります。コンテキストウィンドウが大きくても、モデルが「シグナル」を見つけるためにまず「ノイズ」をふるい分けなければならない場合、推論の質は低下します。ローカルのテスト設定に関する質問に答えている最中に、本番デプロイ用のセキュリティ要件に固執してしまうかもしれません。単純なバグ修正に対して、リリースチェックリストの手順をハルシネーション（幻覚）として混ぜ込んでしまうかもしれません。無関係なテキストが1段落増えるごとに、それは注意を逸らす要因となります。
計算は単純です。ほとんどのターンにおいて、ほとんどのスキルは必要ありません。エラーログの迅速な修正を求めている場合、デプロイのランブックやセキュリティ強化ガイドの全文は必要ないはずです。必要なのは、モデルがエラーを確認し、プロジェクトの規約を理解し、正しいファイルを編集することです。無関係なスキルの本体をロードすることは、モデルの助けにはなりません。むしろ、実際の課題に取り掛かる前に、モデルに不要なデータをフィルタリングさせる強制的な負担を強いることになります。
オンデマンドロードの仕組み
その仕組みはシンプルですが、意図的なものです。APCは引き続き「正解（ground truth）」を保持します。スキルの定義は、本来あるべき場所、つまり .apc/skills/<name>.md に留まります。
APXはそれらのファイルをアクティブなメモリにミラーリングすることはありません。代わりに、スキルの名前をまとめたコンパクトなレジストリを作成します。モデルはこのリストを見て、カタログが存在することを理解します。利用可能な機能を確認したりブラウズしたりする必要がある場合、モデルは list_skills を呼び出すことができます。これにより、データ量を増やすことなく可視性を確保できます。
タスクが実際にスキルファイルにエンコードされた正確な構文、詳細な手順、または特定の制約を必要としたとき、モデルは load_skill を呼び出します。その時点、かつその時点においてのみ、APXはAPCからMarkdownの全文を取得し、コンテキストに注入します。指示は「必要な時に、必要な分だけ」届き、本来の目的のために一度だけ使用されます。これにより、システムが不要な重荷を抱え続けることを防ぎます。
ライブラリをインポートすることと、すべての関数定義をメインファイルに直接貼り付けることの違いを想像してみてください。前者はコードベースの可読性を保ちますが、後者は偶然コンパイルが通るだけの混乱を招きます。
スキルが衝突したときに勝つのは誰か
APXはスキルをロードする際、明確な優先順位も適用します。すべての環境が同じであるわけではなく、一般的なアドバイスがローカルな知識を上書きすべきではありません。
プロジェクトスキルが最優先されます。これらのファイルは、現在のリポジトリの .apc/skills/ に配置されます。これらは、チーム固有の規約、カスタムラッパー、レガシーな命名基準、および特定のツールチェーンを定義します。プロジェクトが独自のデータベースマイグレーション処理を定義している場合、その定義が優先されます。
次にグローバルスキルがあります。これらは、プロジェクト自体が何も定義していない場合に適用される、組織全体のパターンをカバーします。これらは標準ライブラリとして機能します。
組み込みランタイムスキルは、フォールバックとして最下層に位置します。これらは、すべてのエージェントが理解すべきであるが、特定のプロジェクトが再定義するまでもない汎用的な機能を扱います。
この階層化されたアプローチにより、リポジトリは自身の動作を制御し続けることができます。グローバルスキルや組み込みスキルが、チームが意図的にカスタマイズしたワークフローを誤って乗っ取ってしまうことはありません。
実践における具体例
一般的なメンテナンスタスクを想定してみましょう。チームメイトがチャットにエラーログを貼り付けます。トレースバックは、ユーティリティモジュール内の単一のヌルリファレンスを指しています。修正は、おそらく2行の防御的コーディングで済みます。
オンデマンド・ローディングのないシステムでは、APXは知っているすべてのスキルをコンテキストに詰め込んでしまいます。モデルは、その2行に触れる前に、考慮すべき40ページものテキストを抱えることになります。リリースチェックリストを見て、バージョンを上げるべきかどうか迷ったり、セキュリティガイドを見て、単なるヌルチェックが必要な関数に対して入力バリデーションを検討したり、デプロイメント・ランブックを見てステージング環境のことを考え始めたりします。モデルは迷走し、レスポンスは遅くなり、トークン消費量は増大します。
APXのオンデマンド設計では、モデルは名前だけを見ます。モデルは [release-checklist]、[security-guide]、[deployment-runbook]、および [error-handling] が存在することを知っています。最初の3つは無視します。プロジェクトのヌル安全性に関する規約が特定のルールを持っている場合は、[error-handling] をロードするかもしれません。そしてバグを修正します。無関係なスキルはコンテキストウィンドウに入ることさえありませんでした。プロンプトがクリーンに保たれたため、モデルは集中力を維持できました。
同じ論理は、タスクが実際に複雑な場合にも当てはまります。後でエージェントに本番環境へのデプロイ準備を依頼した場合、デプロイメント・ランブックをロードし、セキュリティガイドを参照し、リリースチェックリストを、それらのステップが関連するタイミングで正確に実行できます。知識は常にそこにありました。ただ、適切な瞬間を待っていただけなのです。
アーキテクチャとしてのプロンプト・ディシプリン
APCとAPXの分離は、単なる実装の詳細ではありません。それはプロンプト・ディシプリン（規律）の哲学です。APCは知識を永続的に保存し、レビュー可能で、バージョン管理され、安全なものにします。APXは、その知識のうちどれだけを現在の有効なコンテキストに含めるかを決定します。
豊富なスキルカタログは資産です。肥大化したプロンプトは負債です。目標は、コンテキストを常にアクティブにすることなく、ポータブルに保つことです。リポジトリにはチームがこれまでに書いたすべての指示が含まれているべきですが、エージェントは当面のタスクに役立つものだけを読み取るべきです。
もしシステムが、すべてのターンですべてのスキルの本体をモデルに持たせることを強いるなら、あなたはインテリジェントなアシスタントを作っているのではなく、参照デスクへのあらゆる質問に対して、アーカイブ全体を引きずってくる司書を作っていることになります。すべてを保存し、重要なものだけをロードする。そうすることで、エージェントの速度を維持し、コンテキストをクリーンに保ち、推論を鋭く保つことができるのです。