Young Leaves

Agent Package Manager (APM) を使用してAIコーディング用の資材をパッケージのように管理する

AI コーディングにおいてInstructions やSkills、MCP のような概念が一般化するにつれて、これらを開発者の環境でどのように管理すればよいかの課題が出てきます。今回はMicrosoft がOSS として公開したAgent Package Manager (APM) を使い、YAML ファイルで定義された設定を基にAI コーディング用の資材をまとめてセットアップする方法を説明します。

若葉 香月
5 May, 2026

実施環境

項目 バージョン
OS Windows 11 Pro
APM v0.12.1

前提条件、注意事項

  • 本記事は2026年5月5日現在の内容となります。今後のアップデートにより仕様変更が発生することがあります。
  • 2026年5月5日現在まだv1 リリースではないOSS です。現時点でも頻繁なリリースが行われています。実業務で使用する場合はアップデートによる影響を考慮した上で導入してください。
  • Instructions とは? Skills とは? のような基本的なことは記載しません。

Agent Package Manager (APM) とは

概要

Agent Package Manager (以下APM) はMicrosoft が提供する、AI コーディングに必要な各種設定をpackage.json のようにパッケージ管理できるOSS です。同じ略称の Application Performance Management/Monitoring (APM) とは別物です。
AI コーディングにおいて、Instructions やSkills、Agent の定義、Hook やMCP サーバーのような設定が一般的になりました。それにつれて、AI コーディング環境のセットアップが手間になる、開発者ごとに設定している資材が異なる、AI コーディングに関するナレッジが個人に依存してしまい他のメンバーに共有されない、脆弱性のある資材をインストールしてしまう、みたいな課題が発生しました。APM では専用のYAML ファイルを使用し、AI コーディングに必要な資材をパッケージのように管理できます。セットアップ時はコマンドを1つ実行するだけで準備ができ、開発者間で同じ定義ファイルを使うことで資材の差異を削減できます。加えて、現時点では実験的な機能ですがポリシーファイルを使用することで、APM でインストール可能な資材を制限できます。APM で初期構築を行うことで、AI コーディングにおける各種資材の課題を解消できます。
APMはコマンドベースのツールです。インストール後はコマンドでSkillsや資材を管理できます。コマンドベースのため、手動操作だけでなくスクリプトやCI/CD パイプラインのようなツールにも組み込みやすいのが特徴です。
APM は主に Python で実装されています (インストールはスクリプトにより行われます)。リリース状況や現在のIssue などを確認したい場合はリポジトリを確認してください。
APM – Agent Package Manager

管理対象の資材、サポートされているツール、リポジトリ

APM で管理対象となる資材は以下となります。

  • Instructions
  • Skills
  • Prompts
  • Agents
  • Hooks
  • Plugins
  • MCP Servers

APM がサポートしているAI コーディングツールは以下となります。Codex CLI は Instructions を compile コマンド経由で扱うなど制約があります。その他のツールは主要機能をサポートしています。

  • GitHub Copilot
  • Claude Code
  • Cursor
  • OpenCode
  • Codex CLI
  • Gemini

各種ツールのapm install でどのような資材をインストールできるか、compile で何が追加されるかの詳細は以下のページを参照してください。
Supported tools

APM はHTTPS またはSSH をサポートしているGit リポジトリであればどこからでもインストールできます。公式のドキュメントでは以下のツールが例として記載されています。

  • GitHub
  • GitLab
  • Bitbucket
  • Azure DevOps
  • GitHub Enterprise

パッケージインストールの細かい情報は以下のページを参照してください。
Install from anywhere

APM のインストール

APM を使用するにはPC 上にAPM のインストールおよびGit のインストールが必要です。インストール方法はWindows ではPowerShell を使用し、macOS/Linux ではShell を使ってインストールします。既存のコマンド以外にScoop やHomebrew、pip のようなパッケージマネージャーからインストールもできます。今回はWindows のPowerShell とmacOS/Linux のShell を使った方法を紹介します。

Windows のPowerShell は以下のコマンドでインストールをします。

# WindowsにAPMをインストールする
# 管理者権限や実行ポリシーで制限されている場合は、そちらに合わせて実行する
irm https://aka.ms/apm-windows | iex

macOS/Linux では以下のコマンドでインストールします。Unix インストーラーの場合は環境変数がサポートされているため、指定したバージョンのAPM をインストールできます。

# macOS/LinuxにAPMをインストールする
curl -sSL https://aka.ms/apm-unix | sh

# 特定のバージョンを指定してAPMをインストールする
curl -sSL https://aka.ms/apm-unix | sh -s -- @v0.11.0

その他パッケージマネージャーを使ったインストール方法やバイナリの手動インストールは以下のドキュメントを参照してください。
Installation

APM の基本的な流れ

APM では以下のように各種パッケージを管理を行います。

  1. APM プロジェクトを作成する
  2. 必要なパッケージをインストールしマニフェストを更新する
  3. マニフェストをGit リポジトリにプッシュする
  4. 他の開発者はGit リポジトリをクローンしパッケージをインストールする

1. APM プロジェクトを作成する

初めにAPM の準備を行うため、APM のプロジェクトを作成します。

# APMのプロジェクトを作成する(すべてをyesで設定)
apm init -y apm-test-project

init コマンドを実行するとプロジェクト用のフォルダとAPM のマニフェスト・apm.yml が作成されます。init 直後に作成したマニフェストに記述される内容は以下となります。

name: test-project
version: 1.0.0
description: APM project for test-project
author: HogeHoge
dependencies:
  apm: []
  mcp: []
includes: auto
scripts: {}

マニフェストはプロジェクトのフォルダ内に作成されます。

apm-test-project
└ apm.yml

2. 必要なパッケージをマニフェストにインストールする

init コマンドでAPM のマニフェストを作成後、必要なパッケージをインストールします。パッケージのインストールは install コマンドを使用します。install コマンドでは、ローカルPC にパッケージをインストールすると共に、マニフェストへ自動的に追加を行います。また、初回のインストール時にはパッケージのリポジトリ情報やハッシュ値を管理するapm.lock.yaml ファイルを作成します。今回の例では公式で提供されている microsoft/apm-sample-package をインストールします。

# プロジェクト内に移動する
cd apm-test-project

# apm-sample-packageをまとめてインストールする
apm install microsoft/apm-sample-package

# パッケージの内容を検出しAGENTS.mdファイルを作成する
# この場合、GitHub Copilot用のAGENTS.mdが作成される
apm compile

コマンド実行後、apm-sample-package に含まれる各種フォルダ、資材が所定の位置に配置されます。今回の実行例では .github フォルダ配下に配置されています。初回インストール時には apm_modules フォルダが作成され、インストールしたパッケージはこの中に配置されます。同時に .gitignore が無い場合やapm_modules の記載がない場合は .gitignore に設定を追加します。

.github
├── agents
│   └── design-reviewer.agent.md
├── instructions
│   └── design-standards.instructions.md
├── prompts
│   ├── accessibility-audit.prompt.md
│   └── design-review.prompt.md
├── skills
│   └── style-checker
│       └── SKILL.md
├ apm_modules
└ .gitignore

apm.yml にも自動で追加されていることを確認します。

name: test-project
version: 1.0.0
description: APM project for test-project
author: HogeHoge
dependencies:
  apm:
  - microsoft/apm-sample-package
  mcp: []
includes: auto
scripts: {}

3. マニフェストをGit リポジトリにプッシュする

必要なパッケージをインストールしマニフェストを更新したら、apm.yml と apm.lock.yaml をGit リポジトリにプッシュします。注意点はAPM でインストールしたパッケージの資材は自身のGit リポジトリで管理しないようにします。自身のリポジトリで管理してしまうと、インストール元の更新を取り込めず資材に差異が発生し、AI の出力に影響を与える可能性があります。そのため、APM でインストールしたパッケージの管理はAPM 経由でアップデートやアンインストールを行ってください。

4. 他の開発者はGit リポジトリをクローンしパッケージをインストールする

マニフェストをプッシュ後、他の開発者はリポジトリをクローンしてパッケージのインストールを行います。今回はAPM のプロジェクトを apm-test-project としているため、リポジトリ名は読み替えてください。

# GitリポジトリをCloneしフォルダを移動する
git clone https://github.com/<org>/apm-test-project.git
cd apm-test-project

# マニフェストに設定されたパッケージをインストールする
apm install

install コマンドを実行後、.github フォルダが作成されパッケージインストール時に追加した各種資材が追加されたことを確認します。このように一度マニフェストに定義を行い共有することで、AI コーディングに必要な各種資材の一貫性を維持できます。

現在のマニフェストの状態をパッケージ化する

APM では各種資材をまとめたパッケージを作成できます。まとまったパッケージを環境内に展開することで、パッケージを毎回インストールする必要が無くなる、ネットワークを使用できない環境でもパッケージをインストールできます。プラグインを作成するには pack コマンドを使い、プラグインの展開を行うには unpack コマンドを使います。

# 現在のパッケージ状態をプラグインにする
apm pack --target <AIツール> --archive
apm pack --format plugin --output ./<出力先>

# パッケージ化したプラグインを展開する
apm unpack <パッケージのパス>

APM の各種コマンド

APM はコマンドベースのツールのため、パッケージの管理からツールのアップデートをコマンド操作で行います。コマンドの実行は apm <コマンド> の形式で実行します。今回は基本的なコマンド、オプションを紹介しますが、より詳細なコマンドを知りたい場合は以下のドキュメントを参照してください。
CLI Commands

APM コマンド、ツールのバージョン確認

APM でどのようなコマンドがあるか確認したい場合は --help オプション、APM のバージョンを確認したい場合は --version を使います。

# APMのコマンドを確認する
apm --help

# APMの現在のバージョンを確認する
apm --version

APM のプロジェクトを作成する

「APM の基本的な流れ」で記載したように、APM のプロジェクトおよびマニフェストを作成するには init コマンドを使います。何も指定しない場合は対話形式で設定を行い、-y のオプションを指定すると全て yes の状態で作成されます。

# APMのプロジェクトを対話形式で作成する(対話形式)
apm init <プロジェクト名>

# APMのプロジェクトをデフォルトの設定で作成する
apm init -y <プロジェクト名>

パッケージをインストール/アンインストールする

APM でパッケージのインストールやマニフェストへの追加を行いたい場合は install コマンドを使います。パッケージ名はリポジトリで指定された名前を入力します。

# APMのマニフェストで指定されたパッケージをまとめてインストールする
apm install

# 特定のパッケージのみインストールしマニフェストに追加する
apm install <パッケージ名>

# バージョンを指定してパッケージをインストールしマニフェストに追加する
apm install <パッケージ名>#<バージョン>

APM のマニフェストにMCP サーバーを追加する場合も install コマンドを使用します。MCP サーバーの定義は stdio コマンド、MCP レジストリ、リモートURL からインストールできます。今回の例はMCP レジストリから追加します。

# MCPレジストリからMCPサーバーを追加する
# transportオプションを付けていない場合「Error installing dependencies: 'str' object has no attribute 'get'」のエラーとなる
apm install --mcp io.github.github/github-mcp-server --transport http

他のMCP サーバーの追加方法は以下のドキュメントを参照してください。
MCP Servers

APM のマニフェストからパッケージをアンインストールしたい場合はuninstall コマンドを使います。アンインストールはインストールと違い、特定のパッケージを指定する必要があります。

# APMのマニフェストからパッケージをアンインストールする
apm uninstall <パッケージ名>

# パッケージのアンインストールをDry-runする
# 実行時にどの定義やパッケージ、資材が削除されるか確認できる
apm uninstall --dry-run <パッケージ名>

現在のマニフェストの状態をパッケージ化する

APM は現在のマニフェストの状態をパッケージとしてまとめることができます。また、プラグイン化することで、APM に依存しない形での提供、Marketplace への公開もできます。APM で現在の状態をパッケージ化するには pack コマンドを、パッケージを展開するには unpack コマンドを使います。

# 現在の状態をパッケージ化する
apm pack --target <AIツール> --archive

# パッケージを展開する
# tar.gz形式のファイルパスを指定する
apm unpack <パッケージのパス>

パッケージをプラグインとして提供するにはプラグイン用にフォーマットをします。

# プラグインとして出力する
apm pack --format plugin --output <出力先フォルダ>

指定可能なAI ツールや出力方式は以下のドキュメントを参照してください。
apm pack - Pack distributable artifacts

プラグインをGit リポジトリに公開することで、GitHub Copilot CLI やClaude Code のようなツールでプラグインとしてインストールできます。以下はGitHub のリポジトリにあるプラグインをGitHub Copilot CLI のプラグインとしてインストールする例です。

# GitHub Copilot CLIのプラグインとしてインストールする
# .apmに出力しtest-projectのバージョン1.0.0の場合、.apm/test-project-1.0.0となる
copilot plugin install <OWNER>/<REPOSITORY>:<出力先フォルダ>/<プロジェクト名>-<バージョン>

AI ツール用のAGENTS.md ファイルを作成する

APM はインストールされている内容に基づき、エージェント用の指針となるAGENTS.md を作成できます。オプションを何も指定しない場合はAPM がフォルダ構成やファイル内容を確認し、どのAI ツール用かを判断します。ファイルを作成するには compile コマンドを使います。

# APMでコンテキストを自動的に検出し作成する
# apm.ymlを更新した場合、再度実行することでAGENTS.mdも更新される
apm compile

# 特定のツール用に指定したAGENTS.mdファイルを作成する
# targetオプションはカンマ区切りで複数のツールを指定できる
# Claude Codeを指定しているため、CLAUDE.mdが作成される
apm compile --target claude

インストール済みパッケージの隠しUnicode 文字をスキャンする

Instructions やSkills の中には隠しUnicode 文字で悪意のある指示や挙動を行おうとすることがあります。APM ではインストール済みのパッケージに対して脆弱性をチェックできます。

# インストール済みのパッケージをまとめてスキャンする
apm audit

# 特定のパッケージのみスキャンする
apm audit --file <ファイルパス>

apm audit で検出されるコンテンツは以下のドキュメントを参照してください。
Content scanning

APM の現在の設定を確認する

APM のプロジェクト情報やCLI の設定を確認する場合は config コマンドを使います。

# APMの設定を確認する
# プロジェクトの設定やAPMのバージョンを確認できる
apm config

APM のバージョンをアップデートする

APM はコマンドからツールのアップデートを行うことができます。APM のアップデートを行う場合は update コマンドを使います。

# APMを最新バージョンにアップデートする
apm update

# APMのアップデートをチェックする (アップデートはしない)
apm update --check

Dev Container を使った自動インストール

APM はコマンドベースのツールのため、Dev Container のような仕組みを使うことで、開発用コンテナのビルドと同時にツールのインストールとパッケージのインストールをまとめることができます。一例として、初回ビルド時にAPM のインストールとパッケージのインストールをまとめて実行する設定は以下となります。

{
  "name": "test-apm-project",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "postCreateCommand": "bash .devcontainer/setup-apm.sh"
}
#!/usr/bin/env bash
set -euo pipefail

SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
REPO_ROOT="$(cd "${SCRIPT_DIR}/.." && pwd)"

cd "${REPO_ROOT}"

if ! command -v apm >/dev/null 2>&1; then
  echo "[devcontainer] Installing APM CLI..."
  curl -fsSL https://aka.ms/apm-unix | sh
fi

APM_BIN="$(command -v apm || true)"
if [ -z "${APM_BIN}" ] && [ -x "${HOME}/.local/bin/apm" ]; then
  APM_BIN="${HOME}/.local/bin/apm"
fi

if [ -z "${APM_BIN}" ]; then
  echo "[devcontainer] APM CLI was not found after installation." >&2
  exit 1
fi

echo "[devcontainer] Installing project dependencies from apm.yml..."
"${APM_BIN}" install

実際に利用する場合はGitHub Copilot CLI やClaude Code のようなツールも必要となるため、用途に合わせてカスタマイズしてください。

APM におけるガバナンスの統制

パッケージを容易に追加可能にすると、開発者によっては悪意のあるパッケージを追加してしまうリスクがあります。管理者としては、このようなリスクを未然に防ぐ必要があります。現時点ではまだ開発中の機能ですが、ポリシーファイルとパイプラインツールを使用することで、信頼性の低いパッケージをapm.yml 内に入れないこともできます。
ポリシーファイルはEnterprise Hub かOrganization、リポジトリの .github 配下に apm-policy.yml ファイルを作成し、設定可能なパッケージを記述します。ポリシーファイルは上位から継承および検知が行われ、子の設定では親より緩い設定はできません。検知される順番は Enterprise Hub > Organization > Repository の順番です。Enterprise Hub では全社的で抑止したいパッケージを、Organization はそれぞれの組織に応じたパッケージ、リポジトリでは個々で制限したい内容を設定します。

ポリシーファイルはYAML 形式で以下のように記述されます。

name: "Contoso Engineering Policy"
version: "1.0.0"
enforcement: block         # warn | block | off

dependencies:
  allow:
    - "contoso/**"
    - "microsoft/*"
  deny:
    - "untrusted-org/**"

mcp:
  transport:
    allow: [http, stdio]   # block sse and streamable-http

ポリシーファイルの詳細な設定について、詳細を確認したい場合は以下のドキュメントを参照してください。
Policy Reference

ポリシーファイルで違反を検知するには、 apm audit コマンドを使用し検知を行います。ポリシーファイルはオプションで指定したところから検知できます。

# Organizationのポリシーファイルで検知を行う
apm audit --ci --policy org

# ローカルPC上のファイルを使って検知を行う
apm audit --ci --policy .github/apm-policy.yml

検知されると、以下のようにdenylistに表示されます。例は microsoft/** をdeny に設定した場合の例です。

                                      [>] APM Policy Compliance                                      
┏━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Status   ┃ Check                    ┃ Message                                                     ┃
┡━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ [+]      │ lockfile-exists          │ Lockfile present                                            │
│ [+]      │ ref-consistency          │ All dependency refs match lockfile                          │
│ [+]      │ deployed-files-present   │ All deployed files present on disk                          │
│ [+]      │ no-orphaned-packages     │ No orphaned packages in lockfile                            │
│ [+]      │ skill-subset-consistency │ Skill subset selections match lockfile                      │
│ [+]      │ config-consistency       │ No MCP configs to check                                     │
│ [+]      │ content-integrity        │ No critical hidden Unicode or hash drift detected           │
│ [+]      │ includes-consent         │ No local content deployed -- includes consent check skipped │
│ [+]      │ dependency-allowlist     │ No dependency allow list configured                         │
│          │ dependency-denylist      │ 1 dependency(ies) match deny list                           │
└──────────┴──────────────────────────┴─────────────────────────────────────────────────────────────┘

  dependency-denylist details:
    - microsoft/azure-skills/skills/azure-cost: denied by pattern: microsoft/**

[x] 1 of 10 check(s) failed

audit で失敗した場合、終了コードが1 のエラー終了となるためパイプラインツールで失敗を検知できます。以下はGitHub Actions のようなパイプラインツールを使い、apm.yml またはapm.lock.yaml が更新された時に自動的にエラーを検出できます。

name: APM Policy Check

on:
  push:
    paths:
      - apm.yml
      - apm.lock.yaml
  pull_request:
    paths:
      - apm.yml
      - apm.lock.yaml

jobs:
  policy-check:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Install Microsoft APM CLI
        run: curl -sSL https://aka.ms/apm-unix | sh

      - name: Verify APM policy compliance
        shell: bash
        run: |
          set -o pipefail
          apm audit --ci --policy .github/apm-policy.yml 2>&1 | tee apm-policy-check-result.txt

      - name: Upload APM policy check result
        if: always()
        uses: actions/upload-artifact@v7
        with:
          name: apm-policy-check-result
          path: apm-policy-check-result.txt

今回はorg を指定していますが、Organization の.github にポリシーファイルが存在しない状態で実行した場合、リポジトリのポリシーファイルを参照しないケースがあります。そのため、リポジトリレベルなどで確実に実行させたい場合は apm audit --ci --policy <apm-policy.ymlのパス> で明示的に指定する必要があります。

まとめ

  • Agent Package Manager (APM) はMicrosoft が提供するAI コーディングに必要な各種資材をパッケージ管理できるOSS
  • APM のインストール → マニフェストファイルの更新 → Git リポジトリで共有(プラグインを含む) → 他の開発者がマニフェストを使い設定、の流れで、複数の開発者が一貫したAI コーディングの環境を利用可能となる
  • Dev Container のような仕組みを使うことで、開発環境の構築時に関連するパッケージ設定を自動化することも可能
  • APM はポリシーファイルとパイプラインツールを使うことで、悪意のあるパッケージの追加を事前に防ぐことができる

参考資料