Azure Artifactsは、Azure DevOpsでNuGet、npm、Python、Maven、Cargo、Universal Packagesなどの依存パッケージを「フィード」で一元管理するためのパッケージ管理サービスです。結論から言うと、今回確認すべきポイントは「すぐに全環境を移行しなければならない変更」ではなく、フィードのスコープ、アクセス許可、アップストリーム ソース、ストレージ上限、Azure Pipelinesとの使い分けを見直すことです。(Microsoft Learn)
特に、社内ライブラリをAzure DevOpsで配布しているチーム、CI/CDでパッケージを復元・発行している開発者、Azure DevOps Serverを使っている管理者は、設定のまま運用を続けてよいか確認しておきたい内容です。なお、Microsoft Learnの該当ページでは、日本語版の最終更新日は2025年12月17日、英語版の最終更新日は2025年9月22日と表示されています。本記事では、2026年5月8日時点で確認対象となった公式情報として、実務上の影響と確認ポイントを整理します。(Microsoft Learn)
Azure Artifactsとは
Azure Artifactsは、チームや組織で使うパッケージを保存、管理、共有するためのAzure DevOpsの機能です。Azure Portalで仮想マシンやストレージアカウントのように作成する単体リソースではなく、Azure DevOpsの組織・プロジェクト内にある「Artifacts」メニューからフィードを作成して使います。(Microsoft Learn)
たとえば、次のような用途で使います。
| 利用シーン | Azure Artifactsでできること |
|---|---|
| 社内共通ライブラリの配布 | NuGet、npm、Maven、Pythonなどのパッケージを社内向けに公開する |
| CI/CDでの依存関係管理 | Azure Pipelinesからパッケージを復元・発行する |
| 外部レジストリのキャッシュ | nuget.org、npmjs.com、Maven Centralなどのパブリックレジストリのパッケージをフィード経由で利用する |
| リリース管理 | フィード ビューを使ってPrereleaseやReleaseのように公開段階を分ける |
| 大容量成果物の共有 | Universal Packagesで通常のパッケージ形式に収まらないファイル群を扱う |
重要なのは、Azure Artifactsが「ビルド成果物を一時的に次のステージへ渡す場所」ではなく、「バージョン付きパッケージを継続的に管理する場所」だという点です。Azure PipelinesのArtifactsは、パイプライン実行で生成されたファイルやパッケージを後続タスクに渡すためのもので、Azure Artifactsとは役割が異なります。(Microsoft Learn)
何が変わるのか：機能追加よりも「運用設計の再確認」が重要
公式情報で押さえるべき変更点・確認点は、派手な新機能というより、Azure Artifactsを安全に使うための設計項目です。導入済みの環境では、次の観点で棚卸しするとよいでしょう。
| 確認項目 | 公式情報で示されている内容 | 実務への影響 |
|---|---|---|
| 対応パッケージ | NuGet、npm、Python、Maven、Cargo、Universal Packagesなどをサポート | 複数言語の依存関係を1つの運用ルールで管理しやすくなる |
| フィード作成 | 名前、可視性、スコープ、アップストリーム ソースを指定して作成 | 作成時のスコープ選択を誤ると、後から運用が複雑になる |
| 無料ストレージ | 組織ごとに2GiBの無料ストレージが提供される | 小規模検証には十分だが、本番利用では容量監視が必須 |
| ストレージ監視 | 組織レベル・プロジェクトレベルで使用量を確認できる | 古いパッケージや不要バージョンの削除計画が必要 |
| アクセス許可 | Reader、Upstream Reader、Publisher、Ownerなどのロールで制御 | 開発者、CI/CD、管理者に最小権限を割り当てる必要がある |
| アップストリーム ソース | 外部フィードやパブリックレジストリのパッケージを1つのフィード経由で扱える | 依存関係の取得先を統制しやすくなるが、ソース順序の設計が重要 |
Azure Artifactsでは、フィードを作成するときに「誰が使えるか」「プロジェクト単位か組織単位か」「パブリック ソースのパッケージを含めるか」を決めます。これは単なる初期設定ではなく、あとからの権限管理、パッケージ参照、CI/CD設定に直結します。(Microsoft Learn)
対象者と影響範囲
Azure Artifactsの影響は、パッケージを発行する開発者だけに限られません。Azure DevOpsの管理者、パイプライン担当者、セキュリティ担当者も確認が必要です。
| 対象者 | 主な確認ポイント | 放置した場合のリスク |
|---|---|---|
| Azure DevOps管理者 | フィードのスコープ、可視性、課金、ストレージ使用量 | 不要な公開、容量不足、パッケージ発行停止 |
| 開発者 | NuGet.config、.npmrc、pip.conf、settings.xmlなどの接続設定 | ローカルでは動くがCIで復元に失敗する |
| DevOps担当者 | Azure Pipelinesの復元・発行権限、ビルドサービスのロール | パイプラインでパッケージを取得・保存できない |
| セキュリティ担当者 | パブリックレジストリ利用、アップストリーム ソース、依存関係の取得順 | 意図しない外部パッケージの利用や依存関係混乱 |
| Azure DevOps Server利用者 | Azure DevOps Servicesとの機能差、対応パッケージ種別 | クラウド前提の手順をそのまま適用して失敗する |
Azure DevOps Services、Azure DevOps Server 2022、Azure DevOps Server 2020では、利用できるパッケージ種別に差がある場合があります。特にAzure DevOps Serverを使っている組織は、クラウド版の手順だけを前提にせず、自社バージョンでの対応状況を確認してから展開してください。(GitHub)
管理者が最初に確認すべき設定
フィードのスコープは「プロジェクト単位」か「組織単位」か
Azure Artifactsのフィードは、プロジェクト スコープまたは組織スコープで作成できます。プロジェクト スコープは特定プロジェクト内での利用に向き、組織スコープは複数プロジェクトから参照する共通パッケージに向いています。公式情報では、組織スコープのフィードをプロジェクト スコープへ変換できない点も示されています。(Microsoft Learn)
判断基準は次の通りです。
| 判断軸 | プロジェクト スコープが向く場合 | 組織スコープが向く場合 |
|---|---|---|
| 利用範囲 | 1つの開発プロジェクトだけで使う | 複数プロジェクトで共通利用する |
| 権限管理 | プロジェクト単位で閉じたい | 組織横断で共有したい |
| 例 | 特定サービス専用のnpmパッケージ | 社内共通UI部品、共通SDK、共通NuGetパッケージ |
| 注意点 | 他プロジェクトからの参照設計が必要 | 作成後のスコープ変更に制約がある |
迷った場合は、「誰がそのパッケージを使うか」で判断します。1つのリポジトリや1つのサービスに閉じるならプロジェクト スコープ、複数チームが使う基盤ライブラリなら組織スコープを検討します。
パブリック フィードは慎重に扱う
パブリック フィードは、インターネット上のユーザーにパッケージを共有できる仕組みです。ただし、パブリック フィードはパブリック プロジェクトに紐づくものであり、MicrosoftはAzure DevOpsのパブリック プロジェクトが2027年からプライベートへ変換されることも案内しています。さらに、新たにパブリック プロジェクトを有効化できる組織には制約があり、Microsoftはパブリック プロジェクト用途ではGitHubの利用を推奨しています。(Microsoft Learn)
社外公開が目的なら、Azure Artifactsを「公開レジストリの代替」として安易に使うのではなく、NuGet.org、npmjs.com、GitHub Packagesなどとの役割分担を決めるべきです。特に社内専用パッケージを扱う場合は、パブリック プロジェクトや匿名アクセスの設定が混在していないか確認してください。
アクセス許可はロールごとに分ける
Azure Artifactsでは、フィードごとにユーザーやグループへロールを割り当てます。代表的なロールは次の通りです。(Microsoft Learn)
| ロール | できること | 割り当てる相手の例 |
|---|---|---|
| フィード リーダー | パッケージの表示、ダウンロード、復元 | パッケージを使うだけの開発者 |
| フィードおよびアップストリーム リーダー | リーダー権限に加え、アップストリームからパッケージを保存 | 外部レジストリ経由で依存関係を取得する開発者、ビルドサービス |
| フィード パブリッシャー | パッケージの発行、昇格、非推奨化 | ライブラリを公開する開発者、CI/CD |
| フィード所有者 | パッケージ削除、フィード設定変更、アップストリーム管理 | Azure DevOps管理者、パッケージ管理責任者 |
実務では、全員をフィード所有者にする運用は避けるべきです。パッケージを使うだけの開発者にはReader、発行するCIにはPublisher、設定変更を行う管理者だけにOwnerを付与する、というように分けます。
Azure Pipelinesからパッケージを取得・発行する場合は、ビルドサービスアカウントの権限も確認してください。既定でビルドサービスに一定のロールが割り当てられるケースはありますが、プロジェクトやフィードのスコープによって期待通りに動かないことがあります。(Microsoft Learn)
アップストリーム ソースの設定で依存関係を統制する
アップストリーム ソースを使うと、Azure Artifactsの1つのフィードから、社内パッケージと外部レジストリのパッケージをまとめて扱えます。アップストリーム ソースが有効な場合、Azure Artifactsはフィードにインストールされたパッケージのコピーを自動的に保存します。これにより、外部レジストリへ毎回直接アクセスするのではなく、フィードを経由した依存関係管理が可能になります。(Microsoft Learn)
ただし、設定時には次の点に注意が必要です。
| 注意点 | 内容 |
|---|---|
| 権限 | アップストリーム ソースからパッケージをインストールするには、コラボレーター以上の権限が必要 |
| 管理権限 | アップストリーム ソースの追加・削除にはフィード所有者またはフィード管理者が必要 |
| Maven | Mavenスナップショットはアップストリーム ソースではサポートされない |
| 取得順序 | 複数ソースがある場合、どのソースを先に見るかがパッケージ解決に影響する |
特に重要なのは、アップストリーム ソースの順序です。フィードはソースを順番に確認し、最初に見つかったソースからパッケージを返します。社内パッケージと外部パッケージで同じ名前が存在する場合、意図しないパッケージが解決される可能性があります。依存関係の混乱を避けるため、社内フィード、外部フィード、パブリックレジストリの優先順位を明確にしてください。(Microsoft Learn)
ストレージ、サイズ、数の制限を確認する
Azure Artifactsは、組織ごとに2GiBの無料ストレージを提供しています。検証や小規模利用では始めやすい一方、本番運用では古いバージョンが蓄積しやすく、上限に達すると新しいパッケージを発行できなくなります。公式情報では、上限に達した場合は既存パッケージを削除して空き容量を確保するか、課金設定を行って制限を引き上げる手順が示されています。(Microsoft Learn)
主な制限は次の通りです。
| 項目 | 制限・注意点 |
|---|---|
| パッケージIDあたりのバージョン数 | 5,000バージョン |
| フィードごとのパッケージID数 | 無制限 |
| アップストリーム数 | パッケージの種類ごとに、フィードあたり20 |
| NuGet | 1ファイルあたり500MiB |
| npm | 1ファイルあたり500MiB、package.jsonは375KBの追加制限 |
| Maven | 1ファイルあたり500MiB |
| Python | 1ファイルあたり500MiB |
| Cargo | 1ファイルあたり500MiB |
| Universal Packages | 1ファイルあたり4TiB |
Universal Packagesは大容量ファイルを扱える一方、非常に多くのファイルを含む場合は発行に失敗する可能性があります。大量ファイルをそのまま発行するのではなく、ZIPやTARにまとめる運用も検討してください。(Microsoft Learn)
導入時の実務手順
Azure Artifactsをこれから導入する場合は、いきなり全リポジトリを移行するのではなく、1つのパッケージ種別と1つの開発チームから始めるのが現実的です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 事前整理 | 対象パッケージ種別を決める | NuGet、npm、Maven、Pythonなど、最初に扱う形式を絞る |
| フィード作成 | Artifactsからフィードを作成する | 名前、可視性、スコープ、アップストリーム有無を決める |
| 権限設定 | ユーザー、グループ、ビルドサービスにロールを付与する | Reader、Publisher、Ownerを分ける |
| クライアント設定 | NuGet.config、.npmrc、pip.conf、settings.xmlなどを更新する | ローカルとCIで同じフィードを参照する |
| パイプライン設定 | 復元、ビルド、テスト、発行の流れを構成する | 発行権限と認証方式を確認する |
| リリース管理 | フィード ビューや昇格ルールを決める | PrereleaseとReleaseを分ける |
| 運用監視 | ストレージ使用量と古いバージョンを確認する | 保持ポリシーを有効化する |
公式のベストプラクティスでは、リポジトリごとに1つのフィードを使うこと、複数フィードやパブリックレジストリを使う場合はアップストリーム ソースを使うこと、古いパッケージバージョンを削除するために保持ポリシーを有効化することが推奨されています。(Microsoft Learn)
移行・展開で失敗しやすいポイント
Azure Pipelinesの成果物と混同する
よくある失敗は、Azure Artifactsを「ビルド成果物置き場」として使おうとすることです。ビルド結果のZIP、テスト結果、デプロイ用ファイルを次のステージへ渡すだけなら、Azure PipelinesのPipeline ArtifactsやBuild Artifactsが適しています。一方、バージョン付きライブラリとして継続的に配布するならAzure Artifactsが向いています。(Microsoft Learn)
判断基準はシンプルです。
| 目的 | 適した機能 |
|---|---|
| パイプラインの途中で生成物を次のステージに渡す | Pipeline Artifacts |
| ビルド成果物をリリースや検証で使う | Build ArtifactsまたはPipeline Artifacts |
| NuGetやnpmなどの依存パッケージを社内配布する | Azure Artifacts |
| 任意の大容量ファイル群をバージョン付きで共有する | Universal Packages |
フィードのスコープを後から変えようとする
最初に「とりあえず」で組織スコープのフィードを作ると、後からプロジェクト単位で分離したい場合に困ることがあります。公式情報では、組織スコープのフィードをプロジェクト スコープへ変換できないことが示されています。導入前に、利用範囲、管理者、公開対象、将来のチーム分割を確認してください。(Microsoft Learn)
CI/CDのサービスアカウントに権限がない
ローカル環境ではパッケージを復元できるのに、Azure Pipelinesで失敗する場合、ビルドサービスアカウントの権限不足が原因になりやすいです。パッケージを読むだけならReader、アップストリームから保存するならUpstream Reader以上、発行するならPublisher以上が必要です。(Microsoft Learn)
保持ポリシーを設定せずにバージョンが増え続ける
CIで毎回パッケージを発行する設計にすると、短期間で大量のバージョンが蓄積します。古いバージョンが増えるとストレージを消費し、上限到達時に新しいパッケージを発行できなくなります。保持ポリシーを使って、必要な最新バージョンだけを残す運用にしましょう。(Microsoft Learn)
フィード ビューを使わず、未検証パッケージを全員に見せてしまう
Azure Artifactsでは、パッケージを@Prereleaseや@Releaseのようなフィード ビューへ昇格できます。早期検証用と本番利用向けを分けないと、未検証のパッケージを別チームが取り込むリスクがあります。外部チームや組織全体で使うパッケージほど、ビューの可視性と昇格ルールを決めておくべきです。(Microsoft Learn)
活用シーン別のおすすめ設計
社内共通ライブラリを配布する場合
共通UIコンポーネント、社内SDK、認証ライブラリなど、複数プロジェクトで使うパッケージはAzure Artifactsと相性が良いです。組織スコープのフィードを検討し、Publisherを限られたメンテナーに絞ります。利用チームにはReaderを付与し、Releaseビューに昇格したバージョンだけを参照させると、品質管理がしやすくなります。
外部パッケージの取得を統制したい場合
NuGet.orgやnpmjs.comから直接取得するのではなく、アップストリーム ソースを使ってAzure Artifacts経由にすると、依存関係の取得先を一元化できます。外部レジストリ障害時の影響を抑えたい場合や、パッケージ取得経路を監査したい場合に有効です。ただし、ソース順序と権限設計を誤ると、意図しないパッケージ解決につながります。(Microsoft Learn)
大容量ファイルを共有したい場合
Universal Packagesは、通常の言語パッケージに収まらないファイル群を扱う場合に便利です。たとえば、社内ツールの配布、テストデータ、ビルド済みバイナリ群などに使えます。ただし、デプロイごとの一時的な成果物であればPipeline Artifactsのほうが自然です。長期保管するバージョン付き成果物か、一時的にパイプライン間で渡すファイルかで使い分けましょう。
Azure Artifacts導入前チェックリスト
公開前、移行前、パイプライン展開前には、次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| フィードの目的 | 社内配布、外部パッケージキャッシュ、CI/CD発行のどれか |
| スコープ | プロジェクト単位か、組織単位か |
| 可視性 | Privateでよいか、Publicが本当に必要か |
| 権限 | Reader、Publisher、Ownerを分けているか |
| ビルドサービス | Azure Pipelinesが復元・発行できるロールを持つか |
| アップストリーム | 有効化する外部ソースと順序を決めたか |
| パッケージ制限 | サイズ、バージョン数、アップストリーム数に収まるか |
| ストレージ | 2GiB無料枠、本番利用時の課金、保持ポリシーを確認したか |
| フィード ビュー | Prerelease、Releaseなどの運用ルールを決めたか |
| Azure DevOps Server | 自社バージョンで対象パッケージが使えるか |
よくある質問
Azure Artifactsは無料で使える？
組織ごとに2GiBの無料ストレージが提供されます。ただし、本番運用で多数のパッケージやバージョンを扱う場合は、無料枠を超える可能性があります。上限に達すると新しいパッケージを発行できないため、ストレージ監視と課金設定を事前に確認してください。(Microsoft Learn)
Azure ArtifactsはGitHub Packagesの代わりになる？
社内のAzure DevOps中心の開発ではAzure Artifactsが使いやすい場面があります。一方、社外公開やGitHub中心のオープンな配布ではGitHub Packagesや各言語の公式レジストリを使うほうが自然な場合もあります。特にAzure DevOpsのパブリック プロジェクトには今後の扱いに注意が必要です。(Microsoft Learn)
パッケージを削除したら復元できる？
フィードを誤って削除した場合、Azure Artifactsには元の状態へ復元するための30日間の期間があります。この期間中はフィード名が予約され、パッケージのダウンロードや書き込みはできません。完全削除後はパッケージの表示や復元ができなくなるため、削除操作は管理者に限定するべきです。(Microsoft Learn)
最初に何から始めるべき？
まずは、1つのリポジトリ、1つのパッケージ種別、1つのフィードから始めるのが安全です。フィードのスコープと可視性を決め、PublisherとReaderを分け、Azure Pipelinesで復元・発行できることを確認します。その後、保持ポリシー、フィード ビュー、アップストリーム ソースを整備して、本番運用へ広げていきます。
まとめ
Azure Artifactsは、Microsoft Azure環境やAzure DevOpsを使う開発チームにとって、依存パッケージを一元管理するための重要な機能です。今回の公式情報で特に確認すべきなのは、新機能の有無よりも、フィード設計、アクセス許可、アップストリーム ソース、ストレージ制限、Azure Pipelinesとの使い分けです。
すでに利用している場合は、まず「フィードのスコープ」「パブリック設定」「ビルドサービスの権限」「2GiB無料枠と保持ポリシー」「アップストリーム ソースの順序」を確認してください。これから導入する場合は、小さなフィードから始め、Reader、Publisher、Ownerを分けた最小権限の運用にすることで、後からの移行や展開で失敗しにくくなります。
コメント