APM（Agent Package Manager）は、エージェントプリミティブ ― .prompt.md や .instructions.md のような、エージェントの指示を担う Markdown ファイル ― を管理・配布するためのコマンドラインツールである。このウィキにおける APM の記述は、その作者自身が書いた エージェントプリミティブとコンテキストエンジニアリングで信頼性の高い AI ワークフローを構築する方法 に基づいており、同記事は APM をそれらのファイルに欠けていたインフラストラクチャのレイヤーとして提示している。
APM が答えとして提示されている主張は、エージェントプリミティブはコードではなく自然言語で書かれた本物のソフトウェア ― モジュール化され、再利用可能で、依存関係とバージョンを持つもの ― であり、Markdown ファイルを手作業で配布しながら MCP の依存関係を環境間で一貫させておくことは手に負えなくなる、というものである。ソースが示すたとえは明示的で、繰り返し述べられている。APM は、npm が JavaScript に対して果たしている役割を、エージェントプリミティブに対して果たすことを意図しており、記事は npm のパッケージ配布の仕組みが JavaScript の成長を可能にしたと評価している。
このツールは、既存の VS Code のワークフローを置き換えるのではなく拡張するものとして説明されている。ソースは、日々の開発はそのままであり、同じ apm run コマンドがどのランタイムがインストールされていても動作すると述べている。
機能
2 つの役割が説明されている。ランタイムマネージャーとしての APM はエージェント CLI のランタイムをインストール・設定する。ソースはこれを、ベンダーの CLI がそれぞれ独自のインストール手順、設定要件、互換性マトリクスを持っていることへの対応として位置付けている。パッケージマネージャーとしての APM は、プリミティブを、その依存関係、設定、ランタイムとの互換性とともに、配布可能なパッケージにまとめる。
プロジェクトの設定は、ソースが package.json に相当すると呼ぶ apm.yml ファイルに置かれ、名前付きスクリプト、依存関係、入力パラメーターを定義する。ソースの具体例では、同じプロンプトファイルに対して異なるランタイムを呼び出すスクリプト ― 1 つは security-review.prompt.md を指定して copilot を呼び出し、もう 1 つは同じファイルを指定して codex を呼び出す ― を宣言し、ghcr.io/github/github-mcp-server への MCP の依存関係を宣言している。
ソースが示すコマンドは npm の形に倣っている。プロジェクトを開始する apm init、エージェントプリミティブのファイルを Agents.md ファイルに変換する apm compile、MCP の依存関係をインストールする apm install、そしてワークフローを実行するための、--param 引数を伴う apm run <script> である。ソースは、現時点での配布は apm.yml とプリミティブのファイルを共有することによって行われる ― チームメンバーがリポジトリをクローンし、コンパイルし、インストールする ― と述べ、apm publish はリリース済みのコマンドではなく今後の課題としている。
採用とエコシステム
このツールの本番運用側を担うのは APM の GitHub Action であり、ソースは、同じプロジェクトのスクリプトをプルリクエストのイベントに応じて CI パイプラインの中で実行する様子を示している。そこではワークフローのマトリクスの値が apm.yml のスクリプト名に対応している。この構成では、APM が宣言された MCP の依存関係をインストールし、入力パラメーターをプロンプトファイルに受け渡すため、エディターで開発されたプリミティブがそのままデリバリープロセスの一部として実行される ― ソースはこれを Continuous AI と呼んでいる。
APM は、ソースが予測するエコシステムの発展の 4 段階 ― プリミティブのファイル、次にエージェント CLI のランタイム、次にパッケージ管理、そして共有ライブラリとコミュニティパッケージによる活発なエコシステム ― のうち、3 番目の段階を占めている。この位置付けは作者自身による自分のツールの捉え方であり、ソースは APM 自体の採用状況の数字も、評価も、バージョン番号も報告していない。