Agent Package Manager（APM）：再現可能なAIエージェントのためのDevOpsガイド

Agent Package Manager (APM): 再現可能なAIエージェントのためのDevOpsガイド

GitHub Copilot、Claude Code、またはCursorをチーム向けにカスタマイズしているなら、きっと私がぶつかったのと同じ壁に当たっているはずです。週末をかけて、完璧な一式の指示、プロンプト、スキル、チャットモードを作り込み、それらを .github/ と .claude/ にコミットします。ところがプロジェクトに別のチームメイトが参加すると、設定が数週間前にドリフトしていたため、まったく別のエージェント体験になってしまうのです。

AIエージェントの設定用の package.json はこれまで存在しませんでした。――しかし、いまは違います。

APM (Agent Package Manager) は、Microsoftによるオープンソースプロジェクトで、エージェント設定を、npm、pip、NuGetがコード依存関係を扱うのと同じように扱います。apm.yml ファイルでプロジェクトが必要とするものを宣言し、ロックファイルをコミットすれば、すべての開発者やCIランナーが数秒でまったく同じエージェントセットアップを得られます。

この記事ではDevOpsの観点からAPMを見ていきます。まず初回のインストール手順を追い、その後 awesome-copilot のマーケットプレイスと連携して、あなた自身で何も書かなくても、実戦投入済みのプラグイン、スキル、エージェントを取り込めるようにします。

なぜDevOpsにAPMが重要なのか

microsoft/apm README にある公式のタグラインは、率直にこう言っています：

APM – Agent Package Manager。AIエージェント向けの、オープンソースでコミュニティ主導の依存関係マネージャ。package.json、requirements.txt、または Cargo.toml のようなものだが、AIエージェントの設定のための仕組み。

プラットフォームエンジニアリングの観点では、これはコード側で通常当然のものとして扱っているいくつかのことを可能にします：

• 再現性。 apm.lock.yaml は、すべての依存関係をフルの40文字のコミットSHAに固定するため、今日クローンしても6か月後にクローンしても、同じエージェント挙動になります。
• 移植性。 同じマニフェストが、GitHub Copilot、Claude Code、Cursor、OpenCode、Codexのすべてで機能します。1度書いて、チーム内のあらゆるエディタで実行できます。
• ガバナンス。 中央のレジストリがないため、単一の侵害ポイントがありません。すべてがgitから解決され（SSHまたはHTTPS経由）、インストール時に組み込みの apm audit が、隠れたUnicodeやプロンプトインジェクションのペイロードをスキャンします。
• CIフレンドリー。 microsoft/apm-action が公式に用意されており、Code Scanning向けのSARIF出力があり、さらにマトリクスビルドやネットワーク遮断環境向けのビルドのために bundle-and-ship フロー（apm pack / apm unpack）も用意されています。
• 実行時のフットプリントなし。 セキュリティドキュメント によれば、APMにはテレメトリも、コールバックも、任意のコード実行もありません。実際には、git clone に cp にマニフェストを加えただけです。

APMはまだ作業中のドラフトです（マニフェストのスキーマは0.1、CLIは0.xレンジ）。そのためバージョンを固定し、たまにある“荒いエッジ”は許容しておく必要がありますが、ツールとしての形はすでにとても有用です。

平易な言葉で理解するAPMの中核コンセプト

APMは、いくつかの概念を導入します。ここでは、それが実際に何を意味するのかを説明します。

重要なDevOpsの要点は、apm.yml、apm.lock.yaml、そして .github/、.claude/、.cursor/ 配下に配備されたファイルはすべてコミットされることです。apm_modules/ はコミットされません。これはnpmの真逆であり、意図的にそうなっています。つまり、github.com上のCopilotや、まだ apm install を実行していないチームメイトでも、正しいコンテキストが得られるのです。

APM CLIのインストール

APMはmacOS、Linux、Windows x86_64向けのネイティブバイナリを提供しています。あなたの環境に合うインストーラを選んでください。

LinuxおよびmacOS：

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

Windows（PowerShell）：

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

Homebrew、Scoop、またはpip（代替パス）：

# Homebrew
brew install microsoft/apm/apm

# Scoop（Windows）
scoop bucket add apm https://github.com/microsoft/scoop-apm
scoop install apm

# pip（動作するが、ネイティブインストーラが推奨）
pip install apm-cli

インストールを確認し、更新がないかチェックします：

apm --version
apm update --check

apm update は、あなたのマシンにそれを入れたのと同じネイティブインストーラを使って自動的にアップグレードします。

初めての apm.yml

既存のリポジトリにマニフェストを雛形として作成します：

cd my-devops-project
apm init -y

これにより、だいたい次のような apm.yml が作成されます。dependencies guide からそのまま引用した、より詳しいバージョンです。各行がもたらすものが分かるように注釈を付けています:

name: your-project
version: 1.0.0
dependencies:
  apm:
    # Anthropic のスキル一式（SKILL.md とアセットを含むフォルダ）
    - anthropics/skills/skills/frontend-design

    # awesome-copilot マーケットプレイスのプラグイン
    - github/awesome-copilot/plugins/context-engineering

    # 任意のリポジトリからの 1 つのエージェント原子（プリミティブ）ファイル
    - github/awesome-copilot/agents/api-architect.agent.md

    # タグに固定したフルの APM パッケージ
    - microsoft/apm-sample-package#v1.0.0

    # 任意の Git ホスト（GitLab、Bitbucket、Azure DevOps、セルフホスト）
    - https://gitlab.com/acme/coding-standards.git

    # ローカルパス（モノレポで便利）
    - ./packages/my-shared-skills

    # サブパスと参照（ref）が必要なときのオブジェクト形式
    - git: https://gitlab.com/acme/coding-standards.git
      path: instructions/security
      ref: v2.0

  mcp:
    # GitHub MCP レジストリからの MCP サーバー参照
    - io.github.github/github-mcp-server

依存関係文字列（dependency string）は一貫したパターンに従います：<host>/<owner>/<repo>[/<sub-path>][#<ref>]。ホストを省略すると、github.com が想定されます。ref の固定（pinning）は標準的な git です：タグ（#v1.0.0）、ブランチ（#main）、または生のコミット（#a1b2c3…）。

APM の使い方: 5 分でわかる手順

APM のメンテナーが共有してくれた、まったく同じ例を使って最初から最後まで実行してみましょう。

1. 1 つのプラグインをその場でインストールする

apm install github/awesome-copilot/plugins/context-engineering

3 つのことが起こります:

1. APM が github/awesome-copilot リポジトリをクローンします（浅い形で depth 1）。その結果を apm_modules/ に配置します。
2. plugins/context-engineering がプラグインフォルダであることを検出します（plugin.json を持っている）そして、そのプリミティブを .github/、.claude/、.cursor/、またはターゲットのエージェントがそれらを期待している場所へコピーします。
3. apm.yml の dependencies.apm: 配下にエントリを追加し、解決されたコミット SHA を apm.lock.yaml に記録します。

2. あるいはフルのマニフェストをコミットしてすべてインストールする

必要な依存関係を含めて apm.yml を手で編集し、その後次を実行します:

apm install

これはマニフェスト内のすべての依存関係（推移的なものも含む）を解決し、各依存をコミット SHA に固定し、プリミティブをプロジェクトへデプロイします。

3. 取り込んだものを確認する

apm deps list          # プリミティブの数を含むフラットな表
apm deps tree          # 推移的依存関係の階層表示
apm view github/awesome-copilot/plugins/context-engineering versions   # タグ/ブランチの一覧

4. 状態を新しく保つ

apm outdated           # ロックファイルとリモート参照の差分
apm deps update        # 再解決してロックファイルを更新
apm uninstall github/awesome-copilot/plugins/context-engineering
apm prune              # 参照されなくなったものを削除

5. 正しいファイルをコミットする

# .gitignore
apm_modules/

apm.yml、apm.lock.yaml、およびデプロイされた .github/、.claude/、.cursor/ ディレクトリをコミットします。チームメンバーは、git pull && apm install の後に同一のエージェントセットアップをすぐに取得できます。

awesome-copilot マーケットプレイスの接続

awesome-copilot は、GitHub のコミュニティがキュレーションした Copilot エージェントのライブラリで、指示（instructions）、スキル（skills）、プロンプト（prompts）、チャットモード（chat modes）、フック（hooks）、プラグイン（plugins）を含みます。Copilot CLI と VS Code におけるデフォルトのマーケットプレイスとして事前登録されており、APM もそれを把握しています。

登録して検索する

apm marketplace add github/awesome-copilot
apm marketplace list
apm search "terraform@awesome-copilot"
apm marketplace browse awesome-copilot

短い @awesome-copilot サフィックスでインストールする

apm install azure-cloud-development@awesome-copilot
apm install devops-oncall@awesome-copilot

これは長い形式の apm install github/awesome-copilot/plugins/azure-cloud-development と同等ですが、入力が楽で、ドキュメントで共有もしやすいです。

決定的に重要なのは、APM メンテナーが言っていたこの点です。awesome-copilot のエントリは、自前の apm.yml を同梱する必要がありません。APM は各フォルダの形（プラグイン、スキル、フックパッケージ、単一のプリミティブファイル）を検出し、それに正しく対応します。作者が最初に APM を採用しなくても、コミュニティのカタログを丸ごと利用できます。

DevOpsで今すぐ入れる価値のある選りすぐり

以下は、どのプロジェクトでも私が手元に置いておくようにしている、いくつかの定番項目です。ピン留めする前に、名称を実際のライブなマーケットプレイスで必ず確認してください。カタログの更新が速いためです。

DevOpsリポジトリ向けの現実的なapm.ymlは、たとえば次のようになるかもしれません：

name: platform-engineering-toolkit
version: 1.0.0
dependencies:
  apm:
    - github/awesome-copilot/plugins/azure-cloud-development#main
    - github/awesome-copilot/plugins/devops-oncall
    - github/awesome-copilot/skills/agent-governance
    - github/awesome-copilot/skills/appinsights-instrumentation
    - github/awesome-copilot/agents/azure-iac-generator.agent.md
  mcp:
    - io.github.github/github-mcp-server

apm installを実行し、結果をコミットすると、チームのすべてのエンジニアは次にプルしたときに同じAzure、DevOps、そしてガバナンス用のツール一式を手にできます。

CIでAPMを実行する

パイプラインの再現性のために、公式のmicrosoft/apm-action（GitHub Actions）を使うか、ほかの任意のCIシステムでネイティブインストーラを利用してください。

ロックファイルの整合性を強制し、セキュリティ監査を実行する最小限のGitHub Actionsの例：

name: Agent Config CI
on: [push, pull_request]

jobs:
  apm:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

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

      - name: Resolve dependencies
        run: apm install --dry-run

      - name: Security audit
        run: apm audit --ci -f sarif -o apm-audit.sarif

      - name: Upload SARIF
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: apm-audit.sarif

押さえておきたいことがいくつかあります：

• apm install --dry-runは、ロックファイルとマニフェストが一致しない場合にジョブを失敗させます。PRでの意図しないドリフトを検知できます。
• apm auditは、ダウンロードしたプリミティブを、隠れたUnicodeやプロンプトインジェクション文字（攻撃の「Glassworm」クラス）についてスキャンし、GitHub Code Scanning向けにSARIFを出力したり、カスタムパイプライン向けにJSONを出力したり、ステップの要約向けにMarkdownを出力したりできます。
• マトリクスビルドやエアギャップ環境のビルドでは、1つのジョブでapm pack --archiveを使ってタールボールを作り、下流のジョブではapm unpackを使って、すべての依存関係を毎回クローンし直さないようにします。

自分のAPMパッケージを公開する

レジストリは存在せず、またapm publishもありません。公開とは文字通り「gitリポジトリへのpush」です。first-packageチュートリアルで推奨されているレイアウトは次のとおりです：

my-team-standards/
├── apm.yml
└── .apm/
    ├── instructions/
    ├── prompts/
    ├── skills/
    ├── agents/
    └── hooks/

ワークフロー：

apm init my-team-standards
# .apm/...にプリミティブを配置
git init && git add . && git commit -m "Initial package"
git tag v1.0.0
git remote add origin https://github.com/my-org/my-team-standards.git
git push -u origin main --tags

チームメイトやほかのリポジトリは、次のようにして消費します：

apm install my-org/my-team-standards#v1.0.0

リリースにはsemverでタグ付けし、CHANGELOGを維持し、破壊的変更は任意のライブラリと同様に扱ってください。

DevOpsのベストプラクティスと落とし穴

怒りの中でAPMを使い始める前に知っておきたかったことの、短いリストです。

• タグ付きでピン留めする。mainではなく。 ブランチを追跡したくなりますが、ロックファイルの肝は、アップグレードが意図的に行われるという点です。#v1.0.0 のような参照を使い、apm deps update でバンプしてください。
• デプロイされたファイルをコミットする。 .github/、.claude/、または .cursor/ をコミットしない場合、github.com の Copilot（そして apm install より前の初回クローン）ではコンテキストが欠落します。
• 執筆（作成）用のヘルパーには devDependencies を使う。 apm init --plugin でプラグインをビルドしているとき、apm install --dev で入れるものは、出荷されるバンドルから除外されます。
• MCP の信頼は明示的に扱う。 推移的（transitive）な MCP サーバーは、自己登録のために --trust-transitive-mcp が必要です。これは面倒ではなく機能です。インストールした .agent.md が、エディタに新しい MCP サーバーを黙って持ち込めるべきではありません。
• APM の deps も、他のサプライチェーンと同様に扱う。 上流リポジトリをレビューし、重要な deps にはコミット SHA でピン留めし、CI で apm audit を実行してください。awesome-copilot の agent-supply-chain skill は、チェックリストとして良い出発点です。
• グローバルインストールにも出番がある。 apm install -g <pkg> は ~/.copilot/、~/.claude/、およびそのほかにデプロイします。これにより、プロジェクトごとのマニフェストに触れずに、どこでも使いたい個人用ユーティリティに便利です。

Conclusion

APM はついに、AI エージェントの設定に対して、私たちがコードに長く行ってきたのと同じ取り扱いを提供します。つまり、マニフェスト、ロックファイル、推移的な解決（transitive resolution）、マーケットプレイス、監査ツール、そして CI 連携です。DevOps やプラットフォームエンジニアリングチームにとって、これは「私の Copilot のほうが速い」から「私たちのチーム全体が、同じ厳選されたエージェントスタックを、再現可能に、毎回メリットとして享受できる」への違いです。

awesome-copilot と組み合わせれば、即戦力のオンランプが得られます。コミュニティがメンテナンスする何百ものプラグイン、スキル、エージェントを、1 行の YAML で任意のプロジェクトに取り込めます。

私のおすすめの次のステップ：

1. APM CLI をインストールし、あなたのリポジトリの1つで apm init を実行する。
2. awesome-copilot から1つプラグインを追加する。たとえば apm install devops-oncall@awesome-copilot。
3. apm.yml、apm.lock.yaml、そしてデプロイされたファイルをコミットし、その後 CI で microsoft/apm-action を組み込む。
4. 慣れてきたら、自分たちのチーム標準を .apm/ 配下にパッケージ化し、リポジトリ間で共有する。

さらに掘り下げたい場合は、ブックマークする価値があるのは次の3ページです：APM docs、CLI リファレンス、および enterprise security guide。

Author

Marcel.LFollow

DevTech における Microsoft MVP - DevOps | DevOps Architect | Microsoft テクノロジー、Agentic AI、IaC & オートメーション（Azure）にフォーカスしたテクニカルスピーカー。GitHub はこちら：https://github.com/Pwd9000-ML

いいね、シェア、フォローはこちら： GitHub | X | LinkedIn

Date: 21-04-2026