DependabotでAgent Package Manager（APM）の依存を更新する：apm.ymlの書き方ごとに何が書き換わるかを確かめた

どうも！オペ部の西村祐二です！

APM（Agent Package Manager）で、Agent Skillsやプロンプト、指示ファイルを apm.yml の依存として共有していると、依存先の新しいバージョンに追従するのは手作業になりがちです。2026年11月3日に、Dependabot version updatesがAPMに対応しました。

この記事では、GitHubにリポジトリを作らず、公式のDependabot CLIをローカルで動かして確かめた結果をまとめます。apm.yml の書き方（タグ、コミットSHA、ブランチ）ごとにDependabotが何を書き換えるのか、apm.lock.yaml がどう再生成されるのかに加えて、更新されない書き方や、3日のクールダウンなど運用で気をつける点も扱います。

今回の変更点

• 日付: 2026年11月3日（GitHub Changelog）
• 変更の要点: apm.yml に書いたgit依存について、Dependabotが更新PRを作成。apm.lock.yaml があれば再生成。version updatesだけが対象で、security updatesは含まれない
• 提供範囲: github.comの全プランでGA。GitHub Enterprise Serverは3.24で提供予定
• 公式リンク: Changelog、Dependabot supported ecosystems and repositories: APM

apm.ymlの書き方ごとの動き

確かめた結果とドキュメントの記述を合わせると、apm.yml の書き方によって、Dependabotの動きとPRで変わるファイルが次のように分かれます。図は自作した概念図で、公式のものではありません。

dependencies.apm と devDependencies.apm のどちらも対象です。apm.lock.yaml がない場合、Dependabotはロックファイルを新しく作りません。ローカルパス、mcp:、Azure DevOps、短縮したSHAで書いた依存も更新しないとドキュメントに書かれています（こちらは試していません）。

SHAピンの書き換え先になるのは注釈付きのタグ（git tag -a で作るタグ）だけで、軽量タグとブランチは使わないとdependabot-coreのREADMEにあります。軽量タグしかないリポジトリをSHAで固定した場合は試していません。

dependabot.ymlにapmのエントリを足す

apm.yml があるディレクトリを指定して、package-ecosystem: "apm" のエントリを足します（Changelogとドキュメントの手順どおりの書き方です）。

version: 2
updates:
  - package-ecosystem: "apm"
    directory: "/"
    schedule:
      interval: "weekly"

試してみる

環境と確かめ方

• macOS 26.7.2（arm64）、Docker（Colima 0.10.3）
• Dependabot CLI v1.97.0、updaterイメージ ghcr.io/dependabot/dependabot-updater-apm:latest（2026年11月5日（UTC）ビルド。イメージに入っているAPM CLIは0.34.0）
• 最初の apm.lock.yaml を作るためのAPM CLI 0.35.0

Dependabot CLIは .github/dependabot.yml を読まず、ジョブ定義のファイルで動きます。上の dependabot.yml と同じ内容を、次のジョブ定義で渡しました。

job:
  package-manager: apm
  allowed-updates:
    - update-type: all
  experiments:
    enable-beta-ecosystems: true
  source:
    provider: github
    repo: example/apm-demo-a
    directory: /

dependabot update -f input.yml --local ./proj-a -o out.yml

--local で指定したフォルダを取得元にして更新ジョブが動きます。GitHub上にPRは作られず、本来作られるPRの内容（タイトルと更新後のファイル）がログに出ます。依存先はすべてパブリックリポジトリで、GitHubのトークンは渡していません。画像は、ログに出た更新後のファイルをフォルダのコピーに書き込み、git diff で表示する自作のスクリプト（show-prs.py）の出力です。

1. ロックファイルがない場合

次の apm.yml に対して実行しました（apm.lock.yaml なし）。

name: dependabot-apm-demo-a
version: 1.0.0
targets:
  - claude
dependencies:
  apm:
    # タグで固定
    - microsoft/azure-skills#v1.2.97
    # コミット SHA で固定（初回コミット）
    - microsoft/apm-sample-package#318a84391e7f7a39e3a3f4b5a1bbb09c45ee8a6e
    # ref なし
    - anthropics/skills/skills/frontend-design
    # オブジェクト形式
    - git: https://github.com/tbhb/vale-ai-tells.git
      ref: v1.35.0
devDependencies:
  apm:
    # 開発用の依存（タグで固定）
    - stbenjam/skillsaw#v0.20.0

更新対象になった依存ごとに1件ずつ、計3件のPRが作られました。

• タグ: microsoft/azure-skills#v1.2.97 が #v1.2.110 になりました。変わったのはその1行だけで、コメント行や並び順はそのままです
• コミットSHA: 初回コミットのSHAが、注釈付きタグ v1.0.0 のコミット（fb28516...）に書き換わり、行末に # v1.0.0 が付きました
• devDependencies: stbenjam/skillsaw が #v0.22.0 になりました。このPRの依存は、ログ上で本番用ではない依存（development）として扱われています。dependabot.ymlの groups 設定でPRをまとめる機能とは別のものです
• refなし・オブジェクト形式: どちらも更新の確認対象にならず（ログの Checking if ... に出てきません）、PRも作られませんでした
• ロックファイル: 3件とも変わったのは apm.yml だけで、apm.lock.yaml は作られないままでした

azure-skills は、リモートには v1.2.114 までタグがありますが、選ばれたのは v1.2.110 でした。ログには次のように出ています。

INFO Filtered git tag v1.2.111 for microsoft/azure-skills: released 2026-11-03 (2/3 cooldown days)
INFO Filtered git tag v1.2.113 for microsoft/azure-skills: released 2026-11-04 (1/3 cooldown days)
INFO Filtered git tag v1.2.114 for microsoft/azure-skills: released 2026-11-05 (0/3 cooldown days)

ジョブでは cooldown を設定していませんが、ドキュメントにあるとおり、version updatesには何も設定しなくても3日のクールダウンがかかり、公開から3日経っていないバージョンは選ばれません。毎日タグを打つパッケージだと、PRで上がるバージョンは常に数日前に公開されたものになります。日数は cooldown の default-days などで変えられるとドキュメントにありますが、今回は試していません。

2. ロックファイルがある場合

apm lock で apm.lock.yaml を作った2つのフォルダで実行しました。どちらの apm.yml にも、手順1と同じく name、version、targets: [claude] を書いています（下は依存の部分だけの抜粋です）。

dependencies:
  apm:
    - stbenjam/skillsaw#v0.20.0

dependencies:
  apm:
    - microsoft/azure-skills#v1.2.97
    - microsoft/apm-sample-package#main

ブランチを試したフォルダでは、apm.yml を一度mainの1つ前のコミットに向けてロックし、その後 #main に戻して、ロックファイルの resolved_ref も main に書き換えました。ロックした後にブランチが進んだ状態を再現するためです。

• タグ: apm.yml と apm.lock.yaml の2ファイルが変わりました。ロックファイルでは、resolved_commit と resolved_ref（v0.20.0 → v0.22.0）が更新されました。同じリポジトリからインストールされる個別のスキル（skills/skillsaw-*）6件も、この2項目は同じように更新されました。content_hash が新しい値になったのは本体を含む7件中3件で、残りの4件は同じ値のままでした。このフォルダでは skillsaw を dependencies に書いたので、PRの依存は dependencies として扱われています
• ブランチ: 変わったのは apm.lock.yaml だけで、resolved_commit がmainの先頭コミットに、content_hash がそのコミットの内容に対応する値になりました。apm.yml は #main のままです
• ロックファイルがないブランチ: 別のフォルダで、ロックファイルを置かずに microsoft/apm-sample-package#main だけを書いて実行すると、依存として読み込まれず、PRもエラーも出ませんでした
• apm_version: どちらも apm.lock.yaml の apm_version が 0.35.0 から 0.34.0 に変わりました。ロックファイルを作った手元のAPM CLIではなく、Dependabotが使うAPM CLIのバージョンが書き込まれます

手元のAPM CLIのほうが新しいと、Dependabotが更新PRを作るたびに apm_version が下がる行が差分に入ります。依存の更新とは関係のない行です。なお、2026年11月6日時点で、Dependabot側のAPM CLIを0.35.0に上げ、apm.yml の targets: かロックファイルの deployments から配置先が分かるときは apm lock ではなく apm install で再生成する変更がdependabot-coreのPRとして出ています（未マージ）。マージされると、この差分や再生成の方法は変わる可能性があります。

3. 新しいバージョンを apm lock で解決できない場合

ブランチを試したフォルダに書いていた microsoft/azure-skills#v1.2.97 は、PRになりませんでした。Dependabotは更新先を 1.2.110 と判断したうえで、ロックファイルを再生成する apm lock で失敗しています。

microsoft/azure-skills -- Failed to download dependency microsoft/azure-skills: Agent Plugin portable identity is owned by plugin.json; conflicting apm.yml fields: name, version

手元のAPM CLI 0.35.0でも、azure-skills#v1.2.110 は同じメッセージでロックできず、v1.2.97 はロックできました。失敗したのは、Dependabotが使うAPM CLIが古いからではなく、このバージョンのパッケージを現時点のAPM CLI（0.35.0）では解決できないためでした（2026年11月6日時点）。

一方、ロックファイルがない手順1のフォルダでは、同じ v1.2.110 への更新がPRとして作られています。ロックファイルがないと apm lock が走らないので、apm lock で解決できないバージョンへの更新もPRになります。ロックファイルを置いておけば、解決できない更新はPRにならず、Dependabotのエラーとして記録されます。

ローカルのCLIでは、dependency_file_not_resolvable というエラーの種類とともに上のメッセージが出ました。GitHub上でどう表示されるかは確かめていません。

検証結果の考察

• 確認できたこと: タグ（ロックファイルなし・あり）、コミットSHA（ロックファイルなし）、ブランチ（ロックファイルなし・あり）の組み合わせで、書き換え先と変わるファイルがドキュメントの説明どおりに分かれました。refなしとオブジェクト形式のエントリは更新されず、ロックファイルがないとブランチのピンは対象になりませんでした
• 公式情報の記述だけで、試していないこと: コミットSHAとロックファイルの組み合わせ、軽量タグしかないリポジトリのSHAピン、registries.default を設定したときの短縮形の扱いは、ドキュメントとREADMEの記述によるもので、今回は試していません
• 運用上の注意点: 自動で更新したい依存は、owner/repo#v1.2.0 のようにrefを付けた文字列の形で書く必要があります（apm.yml で registries.default を設定している場合、短縮形は更新されないとドキュメントにあります）。新しいバージョンは、cooldown を設定していなければ公開から3日経つまで選ばれません。ロックファイルがある場合は、apm_version がDependabot側のAPM CLIのバージョンに変わる行もPRの差分に入ります

今回はローカルのDependabot CLIで検証したため、GitHub上のPRの見た目（本文、ラベル）や、スケジュールでの実行は確かめていません。特に、GitHub上で enable-beta-ecosystems が要るかは分かっていないので、PRが作られない場合は上のメッセージを確認する必要がありそうです。プライベートリポジトリの依存、cooldown や groups の設定、package-scopedタグ（review-v1.4.0 のような、パッケージ名を前に付けたタグ）も試していません。社内のプライベートリポジトリにスキルを置いている場合に、今回の結果がそのまま当てはまるかは分かりません。

まとめ

Changelogによると、.github/dependabot.yml に package-ecosystem: "apm" を足すと、Dependabotが apm.yml の依存を更新するPRを作るようになりました。ローカルのDependabot CLIで確かめた範囲では、タグとコミットSHAのピンでは apm.yml が書き換わり、ブランチのピンでは apm.lock.yaml だけが更新され、refなしやオブジェクト形式の依存は更新されませんでした。

Agent Skillsの更新をDependabotに任せるなら、依存をタグかSHAで固定した文字列の形で書き、apm.lock.yaml もコミットしておくのが良さそうです。ロックファイルがあれば、ブランチのピンも更新の対象になり、apm lock で解決できないバージョンへの更新はPRにならずにエラーとして記録されます。

誰かの参考になれば幸いです。

参考リンク:

• Dependabot version updates support Agent Package Manager（GitHub Changelog）
• Dependabot supported ecosystems and repositories: APM（GitHub Docs）
• Dependabot options reference: cooldown（GitHub Docs）
• dependabot-core: apm（GitHub）
• dependabot-core PR #16792: Regenerate apm.lock.yaml with apm install when it records deployments（GitHub）
• Dependabot CLI（GitHub）
• microsoft/apm（GitHub）