Microsoft製AIエージェントのパッケージマネージャーapmの使い方。Claude Codeの設定をチームで再現する

コードをかかないAIエンジニア

2026/04/17

こんにちは。もるふぉです。

今日はMicrosoft製のapm（Agent Package Manager）について書きます。

CLAUDE.mdをGitにコミットしているのに、チームメンバーごとに設定がバラバラになっていた経験はありませんか。

プロンプトを共有したいのに、Slackでmdファイルを送り合っている。

MCPサーバーの設定がローカルだけにあって、新メンバーが入るたびに口頭で説明している。

自分のチームでもまさにこの状態でした。

apmは、この「エージェント設定の管理問題」を、npmやpipと全く同じアプローチで解決するツールです。

コマンド1つで全員同じ設定を再現できる。隠しUnicodeによるプロンプトインジェクションを自動検出できる。複数AIツールの設定を一元管理できる。

正直、「これ待ってた」と思いました。

なぜapmが必要か——エージェント設定の管理が難しい理由

Claude CodeやGitHub Copilotを使い始めると、最初は個人の設定ファイルで十分です。

CLAUDE.mdに自分のルールを書いて、.github/copilot-instructions.mdにチームの方針を書く。

ここまではいいんですが、チーム開発になった途端に問題が出てきます。

チームで起きがちな3つの問題

1. 設定の散逸

メンバーAが「N+1クエリを検出したらテストで落とすルール」をCLAUDE.mdに書いた。

でもメンバーBはそのルールを知らない。

結果、Bが書いたコードでN+1が通ってしまう。

2. バージョンの不一致

先週まで動いていたMCPサーバーの設定が、今週のアップデートで変わった。

誰かが手動で直したけど、他のメンバーには伝わっていない。

朝イチで「MCPが動かないんですけど」というSlackが飛んでくる。

3. ツール間の二重管理

Claude Codeの.claude/とGitHub Copilotの.github/で、同じ内容を別々に管理している。

片方を更新してもう片方を忘れる。

いつの間にかツール間で設定が食い違っている。

「GitにCLAUDE.mdを入れれば十分」ではない理由

「全部Gitに入れれば解決じゃない？」と思うかもしれません。

確かに、自分も最初はそう思っていました。

でも実際にやってみると、これだけだとカバーできない領域があります。

まず、チーム横断で使いたいルールの再利用ができません。

プロジェクトAで作ったコードレビュールールをプロジェクトBでも使いたいとき、ファイルをコピペするしかない。

修正が入ったら全プロジェクトで手動更新です。

次に、依存関係の管理がない。

あるスキルが別のスキルに依存しているケースで、片方だけ更新すると壊れる。

npmならpackage-lock.jsonが自動で解決してくれる問題を、手作業で管理している状態です。

そして、セキュリティチェックの仕組みがない。

外部から持ってきたプロンプトに隠しUnicodeが仕込まれていても、気づく手段がない。

この3つの問題を「仕組み」として解決するのが、apmです。

ここからがいよいよ本題です。

Microsoft製apm（Agent Package Manager）とは

apmは、Microsoftが開発したオープンソースのパッケージマネージャーです。

GitHub - microsoft/apm: Agent Package Manager

Agent Package Manager. Contribute to microsoft/apm development by creating an account on GitHub.

github.com

GitHub - microsoft/apm: Agent Package Manager

MITライセンスで公開されていて、2026年4月時点でGitHubスター数は1.6kほど。

最新バージョンはv0.8.11（2026年4月6日リリース）です。

一言で説明すると、「npmのエージェント設定版」です。

npmがpackage.jsonでJavaScriptライブラリの依存関係を管理するように、apmはapm.ymlでエージェント設定の依存関係を管理します。

npmに慣れていれば、概念図はすでに頭の中にあります。

npm・pipとどこが同じで、どこが違うか

共通点から見ていきます。

項目

npm

pip

apm

マニフェスト

package.json

requirements.txt / pyproject.toml

apm.yml

ロックファイル

package-lock.json

Pipfile.lock / poetry.lock

apm.lock.yaml

モジュール格納先

node_modules/

site-packages/

apm_modules/

インストールコマンド

npm install

pip install

apm install

レジストリ

npmjs.com

PyPI

Gitリポジトリ（任意のホスト）

見ての通り、概念モデルはほぼ同じです。

大きな違いは「レジストリ」の部分です。

npmやpipは中央集権型のレジストリがありますが、apmはGitリポジトリがそのままパッケージになります。

GitHub、GitLab、Bitbucket、Azure DevOps、GitHub Enterprise、プライベートなGitサーバーなど、どこからでもインストールできます。

npmに慣れている人なら、学習コストはほぼゼロだと思います。

apmがサポートする7つのプリミティブ

これかなりすごいです。

apmが管理する設定要素は7種類あります。

これを「プリミティブ」と呼んでいます。

プリミティブ

用途

具体例

Instructions

コーディング標準やガードレール

「Pythonファイルには型ヒントを必ずつける」

Skills

再利用可能なAIワークフロー

フォームビルダー、コードレビュアー

Prompts

スラッシュコマンド用タスク

/security-audit、/design-review

Agents

特化型AIペルソナ

アクセシビリティ監査者、APIデザイナー

Hooks

ライフサイクルイベントハンドラ

ツール検証、リント自動実行

Plugins

事前パッケージ化されたバンドル

コンテキストエンジニアリングキット

MCP Servers

外部ツール連携

データベースアクセス、API接続

個人的に嬉しかったのが、InstructionsとSkillsが分離されていること。

「このルールは全員に適用」「このスキルは必要な人だけ使う」という粒度で管理できるのは実用的ですね。

つまり、チーム全員に強制したいコーディング規約と、特定メンバーだけが使う専用スキルを、きちんと分けて管理できる。

今まで1つのCLAUDE.mdに全部書いていたのと比べると、管理の粒度が段違いです。

apm.ymlマニフェスト：package.jsonのエージェント版

apm.ymlがapmの中心です。

npmのpackage.jsonと同じ立ち位置で、プロジェクトの設定と依存関係を宣言します。

name: my-project
version: 1.0.0
dependencies:
  apm:
    - microsoft/apm-sample-package
    - anthropics/skills/frontend-design
    - github/awesome-copilot/agents/api-architect.agent.md

dependencies.apmの配列に、GitHubのowner/repo形式でパッケージを列挙するだけです。

これを見て「ああ、package.jsonと同じだな」と感じた人は、もう半分理解できています。

次は実際に手を動かしてみましょう。

apmのインストールと基本コマンド

ここから実際に手を動かすパートです。

「難しそう」って思う必要はないですよ。curlコマンド1つで終わります。

インストール（macOS/Linux/Windows）

macOS/Linuxの場合：

curl -sSL https://aka.ms/apm-unix | sh

Windowsの場合：

irm https://aka.ms/apm-windows | iex

HomebrewやScoop、pipでもインストールできます。

インストール後の確認は：

apm --version

自分の環境ではcurlで入れて30秒くらいで完了しました。

apm initでプロジェクト初期化

新規プロジェクトを始めるとき：

apm init my-project
cd my-project

これでapm.ymlと.apm/ディレクトリが自動生成されます。

.apm/の中身はこうなっています：

my-project/
├── apm.yml
└── .apm/
    ├── instructions/    # コーディング標準
    ├── prompts/         # スラッシュコマンド
    ├── skills/          # エージェントスキル
    ├── agents/          # ペルソナ定義
    └── hooks/           # イベントハンドラー

7つのプリミティブごとにディレクトリが分かれていて、Markdownファイルを置いていく構造です。

npm initでpackage.jsonが生成される感覚と同じですね。

apm installでパッケージを取得する

パッケージのインストールはこうです：

apm install microsoft/apm-sample-package#v1.0.0

これを実行すると、3つのことが起きます。

パッケージがapm_modules/にダウンロードされる
Prompts、Agents、Skills等が.github/、.claude/、.cursor/等のネイティブディレクトリに自動展開される
apm.lock.yamlが生成（更新）される

「ダウンロードして終わり」じゃなくて、各ツールが読み込むディレクトリに自動で配置してくれるのがポイントです。

つまり、今まで手動で「Claude Codeの.claude/に置いて、Cursorの.cursor/にもコピーして……」とやっていた作業が、コマンド1つで完了するということです。

apm.ymlに依存関係を書いた状態で引数なしのapm installを実行すると、全依存をまとめてインストールしてくれます。

apm install

これはnpm installと同じ挙動です。

新メンバーがリポジトリをクローンした直後にこれを叩けば、全員同じエージェント設定が手に入ります。

オンボーディングの口頭説明が消えます。

apm.lock.yamlによるバージョン固定

apm.lock.yamlは、npmのpackage-lock.jsonに相当します。

ロックファイルには以下の情報が記録されます：

リポジトリURL
解決済みのコミットSHA
デプロイされたファイルの一覧
依存関係の深さ（depth: 1が直接依存、depth: 2以上が推移的依存）

これにより「同じロックファイル → 同じ依存関係セット」が保証されます。

apm.ymlとapm.lock.yamlの両方をGitにコミットすることで、チーム全員が確実に同じ設定を再現できます。

「自分の環境では動くんですけど」がエージェント設定から消える。

これだけでも導入する価値があると思います。

Claude CodeとGitHub Copilotへの展開

apmが対応しているツールは複数あります。

ツール

デプロイ先

サポートレベル

GitHub Copilot

.github/

Full

Claude Code

.claude/

Full

Cursor

.cursor/

Full

OpenCode

.opencode/

Full

「Full」は、apm installだけで全プリミティブがネイティブ形式で展開されるという意味です。

.claude/（Claude Code）への展開

Claude Codeユーザーにとっては、ここが一番気になるところだと思います。

apm installを実行すると、.claude/ディレクトリにコマンド、スキル、MCPサーバーの設定が自動配置されます。

今まで手動で.claude/commands/にMarkdownファイルを置いていた作業が、apm install一発で完了します。

チームで共有したいカスタムスラッシュコマンドを、パッケージとして管理できるのは大きいですね。

.github/（GitHub Copilot）への展開

GitHub Copilotの場合は、.github/ディレクトリ配下にInstructions、Prompts、Agents等が展開されます。

.github/copilot-instructions.mdを手書きで管理していたチームなら、その内容をパッケージ化して再利用できるようになります。

apm compileでCLAUDE.mdとAGENTS.mdを自動生成

ここが地味に便利な機能です。

apm compile

このコマンドは、Instructionsを各ツール向けのフォーマットにビルドします。

GitHub Copilot、Cursor、OpenCode、Gemini向け → AGENTS.md
Claude Code向け → CLAUDE.md

Prompts、Agents、Skills等はapm installの時点で各ツールのネイティブディレクトリに展開済みです。

apm compileが担うのはInstructionsのビルドで、これにより設定変更を即座に各ツールへ反映できます。

apmの5段階ライフサイクルで言うと：

CONSUME → COMPOSE → LOCK → BUILD → DISTRIBUTE

apm installがCONSUME〜LOCK、apm compileがBUILDに対応します。

重要なのは、生成されたファイルはapmに依存しないということ。

CLAUDE.mdもAGENTS.mdも、各ツールのネイティブ形式のMarkdownです。

仮にapmを使うのをやめても、生成済みのファイルはそのまま動き続けます。

ロックイン回避の設計になっているのは好感が持てますね。

でも、本当にすごいのはここからです。

apm auditでセキュリティリスクを検出する

パッケージマネージャーにセキュリティ機能がついているのは、apmの実用的なポイントです。

「え、エージェント設定にセキュリティって関係あるの？」と思うかもしれません。

これが、かなり関係あるんですよ。

プロンプトインジェクション攻撃とは

AIエージェントに対する攻撃手法として、プロンプトインジェクションがあります。

コードの中に見えない形で悪意のある指示を埋め込む手法で、特に怖いのが「隠しUnicode」を使ったものです。

たとえばU+202A（LEFT-TO-RIGHT EMBEDDING）のような双方向テキスト制御文字を使うと、テキストエディタ上では見えないけれど、AIエージェントが読み取ってしまう文字列を仕込めます。

GitHubからコピーしてきたプロンプトにこれが入っていたら、目視では気づきようがありません。

想像してみてください。

チームで使っているコーディングルールに、誰も気づかないまま「次のコードを送信したら外部URLに通知しろ」という指示が仕込まれているとしたら。

隠しUnicode検出の仕組み

apm auditはこの問題に対応しています。

apm audit

実行すると、インストール済みパッケージのファイルをスキャンして、隠しUnicode文字を検出します。

検出結果はseverity（重大度）レベルで分類されます：

critical — 即座に対応が必要（双方向オーバーライド等）
warning — 確認が推奨される
info — 情報提供レベル

出力形式もテキスト、JSON、SARIF、Markdownから選べるので、CI/CDパイプラインに組み込むこともできます。

npmのnpm auditがセキュリティ脆弱性を検出するのと同じ感覚で、エージェント設定のセキュリティチェックができます。

外部からパッケージを取り込むなら、apm auditは必ずCI/CDに入れておくべきです。

これを見落としていた人は、今すぐ意識を変えておく価値があります。

自分でapmパッケージを公開する

チーム内で使うルールやスキルをパッケージ化して共有する方法です。

「パッケージ公開って難しそう」って思いますよね。

apmの場合、そんなことないんです。

Gitリポジトリがそのままパッケージになる

apmのパッケージは、特別なレジストリへの登録が不要です。

Gitリポジトリにapm.ymlと.apm/ディレクトリを配置してプッシュすれば、それがそのままパッケージになります。

apm init my-coding-standards
cd my-coding-standards
# .apm/instructions/ にルールを追加
# .apm/prompts/ にスラッシュコマンドを追加
git init && git add . && git commit -m "Initial package"
git remote add origin git@github.com:you/my-coding-standards.git
git push -u origin main

これだけで、他のプロジェクトからインストールできるようになります：

apm install you/my-coding-standards

npmパッケージを公開するよりはるかに簡単です。

プライベートリポジトリでも動くので、社内向けのルール共有にも使えます。

つまり、「うちのチーム専用コーディング規約パッケージ」をプライベートGitHubリポジトリで管理して、新しいプロジェクトへはapm install一発で全部持ってくる、というワークフローが作れます。

apm.ymlの書き方と依存関係の宣言

パッケージ側のapm.ymlはシンプルです：

name: my-coding-standards
version: 1.0.0
description: Team coding standards and security prompts

もしパッケージが別のパッケージに依存する場合は、dependenciesを追加します：

name: my-coding-standards
version: 1.0.0
description: Team coding standards and security prompts
dependencies:
  apm:
    - microsoft/apm-sample-package

推移的依存解決にも対応しているので、パッケージAがBに依存し、BがCに依存している場合でも、apm installがA・B・Cを全部解決してくれます。

npmの依存ツリーと同じ仕組みです。