APM（Agent Package Manager）とは？AIエージェント設定をnpm方式で一元管理するMicrosoft製OSSの仕組み

APM（Agent Package Manager）は、Claude CodeやGitHub Copilotといったコーディングエージェントの設定一式を、npmやpipと同じ感覚で宣言・配布できるMicrosoft製のオープンソースです。この記事では、APMが管理するprimitiveの中身、apm installを中心としたコマンド体系、apm.lock.yamlによる再現性、apm auditやapm-policy.ymlのセキュリティ統制までを、公式ドキュメントとGitHub・PyPIの一次情報をもとに整理します。略語が同じ「APM」でも性能監視ツールとは別物である点や、まだpre-1.0である現時点で自社に入れるべきか・見送るべきかの判断基準まで、運用担当が意思決定できる粒度で扱います。

まとめ｜APMはAIエージェント設定の依存関係をnpm方式で再現・統制するMicrosoft製OSS

APMは、AIコーディングエージェントの設定（指示・スキル・プロンプト・hook・MCPサーバーなど）をapm.ymlに宣言し、apm install一発で各ハーネスへ展開する依存関係マネージャです。MITライセンスのOSSでGitHubのmicrosoft組織配下に置かれ、apm.lock.yamlが40桁のコミットSHAを固定するため、クローンしたメンバー全員が同一の設定を再現できます。

価値が出るのは、複数のエージェントを併用し、スキルやMCPの数が増え、チームや顧客へ設定を配布する組織です。逆に、単一ハーネスを個人で使い設定が数ファイルに収まる段階では、現時点のAPMはオーバースペックになります。2026年6月時点でCLIはv0.23系のpre-1.0であり、破壊的変更を前提に段階導入する姿勢が現実的です。

APM（Agent Package Manager）の定義とMicrosoft製OSSとしての位置づけ

APMの発想は単純です。ソースコードの依存関係をpackage.jsonやrequirements.txtが再現性をもって管理してきたのと同じことを、散らばりやすいAIエージェントの設定に適用します。

npm・pipのAIエージェント版という設計思想と解決する課題

AIコーディングエージェントは、コーディング規約・プロンプト・スキル・MCP接続情報といった「文脈」を読み込んで初めて役立ちます。ところが、その文脈は各開発者が手作業でセットアップするのが実情で、移植性も再現性もありません。APMは、必要な依存をapm.ymlに1度宣言しておけば、リポジトリをクローンした開発者がapm installを実行するだけで、推移的依存（パッケージが依存する別パッケージ）まで含めて同じ設定が数秒で揃う状態を作ります。

混同されやすい3つの「APM」（性能監視・Atom・エージェント）の判別

「APM」という略語は3つの異なる対象を指すため、検索時に取り違えが起きます。実務では最初にここを切り分けてください。

「apm install」で検索するとDatadogやAtomの情報が混ざるのはこのためです。本記事が扱うのは3つ目のAgent Package Managerで、性能監視のAPMとは技術領域も用途も重なりません。社内で話題にするときは「エージェント設定のAPM」と一言添えると誤解を避けられます。

開発元・ライセンス・現行バージョンv0.23系という現況

APMはMicrosoftのGitHub組織（github.com/microsoft/apm）でMITライセンスで公開され、Pythonで実装されています。リポジトリの作成は2025年9月18日で、Daniel Meppiel氏が始めたプロジェクトをMicrosoft組織配下で育てている形です。GitHubのスター数は2026年6月29日時点で約3,030に達し、同年4月時点の約1,700から短期間で倍増しました。CLIのバージョンはPyPIのapm-cliで確認でき、4月の0.8.11から6月時点でv0.23系まで進んでいます。機能拡張は活発な一方、まだ1.0未満（pre-1.0）です。安定版に到達していない事実は、後述する導入判断で重みを持ちます。

APMが一元管理する7種のprimitiveと対応AIエージェント（ハーネス）の範囲

APMが扱うのは単なる設定ファイルのコピーではありません。エージェントを構成する複数種類の部品（primitive）を、ハーネスごとの正しい場所へ振り分けて配置します。

instructions・skills・prompts・agents・hooks・plugins・MCPの管理対象

APMが依存として宣言・配布できるprimitiveは、コーディング規約などのinstructions、特定タスクの手順を記したskills、スラッシュコマンド化されるprompts、サブエージェント定義のagents、実行フローの特定タイミングで動くhooks、これらを束ねたplugins、外部接続のMCPサーバーの7種類です。とくにskillsは、Anthropicが提唱するAgent Skills仕様（SKILL.md1ファイルでスキルを記述する形式）に準拠しており、APMはその仕様自体ではなく「配送・バージョン固定・監査」を担います。スキルの中身の考え方はClaude Skillsの基本的な仕組みを押さえると、APMが何を運んでいるのかが具体的に見えてきます。

Copilot・Claude Code・Cursorなど主要ハーネス横断の配置先ルール

APMの実用的な強みは、エージェント（ハーネス）を横断できる点です。対応はGitHub Copilot・Claude Code・Cursor・OpenCode・Codex・Gemini・Windsurfなどで、Kiroも挙げられています。apm installはリポジトリ内の.github/や.claude/といったマーカーを検出し、各ハーネスのネイティブな場所へ部品を配置します。スキルは共通の.agents/skills/へ集約し、Claudeだけは例外として.claude/skills/へ展開する割り当てです。複数エージェントを使い分けるチームほど、設定ツールがエージェントごとにバラバラになる問題を一本化できます。Copilot側の挙動はGitHub Copilotのエージェントモードを理解しておくと、何が配布されるかのイメージが付きやすくなります。

dependencies.mcpによるMCPサーバーの宣言的な一括配線

APMは設定ファイルだけでなく、MCP（Model Context Protocol）サーバーの接続情報もapm.ymlのdependencies.mcpに書いて管理します。apm installを実行すると、検出された各ハーネスの設定ファイルへMCPサーバーのエントリが追記され、既存設定は丸ごと置き換えられずに保持されます。たとえばGitHub MCPサーバーを全メンバーの環境へ同じバージョンで配線する、といった運用が宣言1行で済む手軽さです。なお、依存パッケージが芋づる式に持ち込む推移的MCPサーバーは、明示的な信頼指定（--trust-transitive-mcp）が無いと自動登録されません。これは利便性を下げる制約ではなく、知らないMCPサーバーがエディタに勝手に入ることを防ぐ安全設計です。

apm installを中心とした基本コマンドと再現性を支えるlockfileの仕組み

コマンド体系はnpmの語彙にそろえてあり、npmやpipの経験者なら学習コストはほとんどかかりません。日常運用で触るコマンドは限られます。

インストールとapm initで生成される最小マニフェスト

APM本体は、macOS／Linuxならターミナルでワンライナーのインストーラーをaka.msのスクリプト経由で実行し、WindowsはPowerShellで同様に導入します。Homebrew・Scoop・pip（pip install apm-cli）にも対応しており、外部スクリプトの直接実行を避けたい組織でも公式パッケージマネージャ経由で導入可能です。導入後にapm initを実行すると、生成されるのはapm.yml1ファイルだけで、dependencies.apm（部品）とdependencies.mcp（MCPサーバー）が空で用意されます。

2026年6月時点で正しいapm.ymlの記法とバージョンピンの書式

古い解説記事には、dependencies直下にパッケージ名とキャレット表記（^1.2.0）を並べる例が見られますが、これは現行の書式と異なります。2026年6月時点の正しい記法は、dependenciesの下にapmとmcpの2つのサブキーを分け、それぞれにリスト形式で並べ、バージョンは#v1.0.0のようにタグやコミットSHAで固定する形です。

• name: my-agent と version: 1.0.0：このプロジェクト自体のメタ情報
• dependencies: の下に2つのサブキーを置く
  • apm: 配下に部品をリストで列挙（例：- microsoft/apm-sample-package#v1.0.0、- anthropics/skills/skills/frontend-design）
  • mcp: 配下にMCPサーバーを列挙（例：- name: io.github.github/github-mcp-server と transport: http）
• includes: auto：ローカルの .apm/ に自作した部品を同梱する指定

パッケージは組織/リポジトリや組織/リポジトリ/パスの形でGitHubはもちろんGitLab・Bitbucket・Azure DevOpsからも参照できます。dependencies直下にマップで書く旧式と取り違えるとapm installが依存を解決できないため、書式が変わりやすいこの段階では公式ドキュメントのManifest schemaを正としてください。

apm.lock.yamlと40桁SHAが保証するバイト単位の再現性

apm installを実行すると、apm.ymlの更新に加えてapm.lock.yamlとapm_modules/（自動でgitignore対象）が作られます。lockfileの肝は、各依存をタグやブランチ名ではなく40文字のフルコミットSHAとコンテンツハッシュで固定する点です。外部リポジトリのタグが後から書き換えられても、半年後にクローンした人が同じバイト列の設定を取得できます。CIではapm install --frozenを使うと、lockfileのみを正としてインストールし、ずれがあれば失敗します。npmのnpm ciに相当する、再現性を壊さないための実行モードです。

npm経験者向けの主要コマンド対応表

APMのコマンドはnpmのセマンティクスにそろえてあります。覚えるべき対応関係は次のとおりです。

この5つ以外にも、公開用に固めるapm pack、監査のapm audit、ポリシーのapm policyなど多数のコマンドが揃いますが、日常で最も叩くのはapm installです。新規メンバーのオンボーディングは、クローン後の1コマンドに集約されます。

apm auditとapm-policy.ymlによるサプライチェーン統制の実際

エージェント設定は、実態としてはプロンプトと実行権限を伴うhookの集合体です。悪意あるパッケージを掴むと、機密の漏えいや意図しないコマンド実行に直結します。APMはこの前提に立ち、統制機能を標準で備えます。

「ファイル配置＝実行」という前提と隠しUnicodeスキャンの役割

APMは「ファイルが配置された瞬間にエージェントが読み込む（＝実行に等しい）」という前提に立ち、エージェントが読む前に検査する設計です。すべてのapm installが、目に見えないUnicode（タグ文字などでプロンプトに隠し指示を埋め込む手口）をスキャンし、改ざん防止のためコンテンツハッシュをlockfileへ固定します。手元で随時検査したいときはapm auditを実行し、作業ツリーをスクラッチで再構築して差分を取り、手で書き換えた箇所（ドリフト）を出荷前に検出する仕組みです。テレメトリ送信・外部コールバック・任意コード実行を持たない点も、調達審査で問われやすい論点を先回りでつぶしています。

apm-policy.ymlのtighten-only継承による組織レベルの許可制御

組織として「どのパッケージを許可し、何を拒否するか」を定めるのがapm-policy.ymlです。許可リスト・拒否リスト・MCPトランスポートの制限などをYAMLで宣言でき、ポリシーはインストール時（MCPがディスクに触れる前）に評価されます。継承は「厳格化のみ（tighten-only）」で、Enterprise→Org→Repoの順に下り、下位は上位の制限を緩められません。組織で「anthropics/**は禁止」と定めれば、リポジトリ側で上書き許可することはできず、apm audit --ciで同じ検査をブランチ保護に組み込めます。許可されていないパッケージがapm.ymlに紛れ込んだ瞬間に、CIが検知して止める運用になります。

SBOM出力とCI監査が満たす企業の調達・監査要件

企業導入で効くのは、出所（プロベナンス）を機械可読で示せる点です。APMはlockfileを起点に、CycloneDXやSPDX形式でSBOM（ソフトウェア部品表）を書き出せるため、何がディスクに届いたのかを調達・セキュリティ部門へ標準フォーマットで提示できます。CIには公式のmicrosoft/apm-actionがあり、Code Scanning向けのSARIF出力にも対応します。中央レジストリを持たずGitからSSH／HTTPSで解決する構造のため、単一レジストリの侵害が全社へ波及する攻撃面も持ちません。インストール時の静的監査（apm audit）と実行時のhookによる動的監査は守備範囲が異なるので、両方を併用して層構造にするのが現実的です。

pre-1.0のAPMを今導入すべき組織と見送るべき条件の線引き

APMは有望ですが、万人向けではありません。pre-1.0という段階を踏まえ、導入の是非を条件付きで言い切ります。

導入価値が明確に高い組織の3条件

次の条件に複数当てはまるほど、APMの効果は大きく出ます。第一に、Copilot・Claude Code・Cursorなど複数のハーネスを併用していること。エージェントごとに設定ツールが割れる問題を、APMが一本化します。第二に、共有するskillsやMCPサーバーの数が増えており、バージョンずれが品質に直結すること。第三に、新規メンバーのオンボーディングや顧客への成果物配布が頻繁で、「クローン＋1コマンドで同一環境」が運用上の価値を持つことです。これらが揃う組織では、設定の属人化という見えにくいコストを構造的に削れます。

現時点では採用を見送るべき場面と失敗パターン

逆に、次の場合は現時点でAPMを入れるのは過剰です。単一のハーネスしか使わず、個人または少人数で、管理対象がCLAUDE.mdなど数ファイルに収まる段階では、マニフェストとlockfileの運用負荷が便益を上回ります。よくある失敗は二つです。流行を理由に全社の設定を一気にAPM化し、まだ枯れていないコマンド体系の変更に振り回されるパターン。もう一つは、外部パッケージを無審査で大量に入れ、apm auditやSHA固定を運用に組み込まないまま結局リスクを抱え込むパターンです。導入は最小セット（共通の指示・セキュリティhook・全員が使う基本skills）から始め、効いた範囲だけ広げるのが安全です。

v0.23・破壊的変更リスクへの現実的な向き合い方

2026年6月時点のCLIはv0.23系で、まだ1.0に達していません。マイナー更新で挙動や書式が変わる可能性は十分にあります。ミッションクリティカルな本番運用にいきなりロックインするのではなく、重要な依存はコミットSHAでピン留めし、apm updateは同意確認を挟んで段階的に取り込むのが現実的です。本体の更新はapm self-updateで行えますが、更新後はCIのapm install --frozenがドリフトを検知してくれるので、CI監査を先に整えておくと破壊的変更の影響を早期に把握できます。pre-1.0だから使わない、ではなく、pre-1.0だからこそ固定と監査をセットで運用する、という構えが適しています。

よくある質問

APMの導入を検討する際に、実際に問い合わせや検索で頻出する疑問をまとめます。

APMは無料で使えますか？商用利用に制限はありますか？

APMはMITライセンスのオープンソースで、無料で利用でき、商用利用にも実質的な制限はありません。コードの改変・再配布も認められています。パッケージはGitHubに限らずGitLab・Bitbucket・Azure DevOpsからも管理できるため、社内のプライベートGitサーバーで機密性の高い設定を社外に出さずに配布する運用も可能です。

APMを入れると既存のCLAUDE.mdやCursor設定は上書きされますか？

全体が丸ごと置き換えられることはありません。MCPサーバーの設定は、検出した各ハーネスの設定ファイルへエントリとして追記され、既存の内容は保持されたままです。また、ローカルの.apm/に自分で置いたコンテンツは外部依存より優先される「ローカル優先」の原則があるため、チーム共通ルールを一時的に手元で上書きすることもできます。導入前にapm.lock.yamlを確認しておけば、何が入るかを把握したうえで適用できます。

性能監視ツールの「APM」とは何が違うのですか？

まったくの別物です。DatadogやNew Relicの「APM」はApplication Performance Monitoringの略で、本番アプリの遅延やエラーを監視する運用ツール。本記事のAPMはAgent Package Managerの略で、AIエージェントの設定を依存関係として管理する開発ツールです。技術領域も用途も重ならないため、検索時は「エージェント」「Microsoft」などの語を添えると目的の情報にたどり着けます。

中央レジストリが無いのに、どうやってパッケージを探すのですか？

APMはnpmのような中央レジストリを持たず、任意のGitリポジトリがそのままパッケージになります。発見の手段としてマーケットプレイスがあり、GitHubがコミュニティで整備するawesome-copilotはapm marketplace add github/awesome-copilotで登録して利用できます（awesome-copilot自体はGitHub Copilot CLIやVS Codeでは既定のマーケットプレイスとして扱われます）。apm searchやapm marketplaceで候補を探し、apm install 組織/リポジトリの形で直接インストールできます。中央集権を避けることで、単一レジストリの侵害が全体に波及する構造的リスクを持たない設計です。

pip install apm-cliと公式インストーラーはどちらを使うべきですか？

どちらでも導入できます。aka.ms経由のワンライナーは手早く、CIや個人環境では便利です。一方、組織で「外部スクリプトの直接実行は禁止」というガバナンス要件がある場合は、pip install apm-cliやHomebrew・Scoopといったパッケージマネージャ経由のほうが審査を通しやすくなります。エアギャップ環境向けには署名済みアーカイブやミラー導入も用意されているので、自社のセキュリティ方針に合わせて選んでください。

関連記事

• Claude Skillsとは何か：APMが配布するprimitiveの代表格「スキル」の仕様と役割を解説しています。
• GitHub MCPサーバーの基本的な仕組み：APMのdependencies.mcpで配線する具体例として理解が深まります。
• GitHub Copilotのエージェントモードとは：APMの主要な配布先ハーネスの挙動を押さえられます。
• Cursor Proの主な機能：APMが横断対応するハーネスの一つ、Cursorの機能を確認できます。
• Claude Code Actionとは何か：CIにエージェントを組み込む観点で、apm auditのCI統合と合わせて読むと有用です。