Azure DevOps パイプライン成果物がダウンロードできない（500 Something went wrong）原因と回避策：DownloadPipelineArtifact・REST API・Azure CLI

Azure DevOps のパイプライン実行結果から成果物（artifact）をダウンロードしようとすると「500 – Something went wrong!」で失敗することがあります。設定ミスなのかサービス障害なのかを切り分けつつ、今すぐ成果物を取り出すための REST API / Azure CLI の回避策、タスク置き換えまで実務目線で整理します。

現象：Azure DevOps でパイプライン成果物（artifact）がダウンロードできない

Azure DevOps の Pipelines では、ビルドやテストの結果として生成したファイル一式を「成果物（artifact）」として発行し、後続工程や手元の PC にダウンロードして利用できます。ところが、パイプライン実行結果の画面（Run の詳細）から成果物をダウンロードしようとすると、次のようなエラーで失敗し、作業が止まってしまうことがあります。

エラー例

500 - Something went wrong!
We've encountered an error and cannot fulfill this request.

ポイントは「500（サーバーエラー）」であることです。クライアント側（ブラウザやユーザー操作）の問題に見えても、実態としては Azure DevOps 側の処理で例外が起きている可能性が高く、同じプロジェクト・同じ成果物だけでなく、複数の実行（Run）で共通して再現するケースもあります。

最初にやるべき切り分け：サービス障害か、個別設定か

原因が「自分のパイプライン設定」なのか「Azure DevOps のサービス側（アウトージ／不具合）」なのかで、取るべき行動が変わります。まずは再現範囲を短時間で確認して、無駄な修正を避けましょう。

確認観点	チェック内容	判断の目安
再現範囲	同じ成果物だけでなく、別 Run / 別パイプラインでも 500 になるか	複数で再現するならサービス側の可能性が上がる
ユーザー差	別ユーザー（同権限）でも同じ 500 になるか	権限不足なら 403/404 が出やすい。500 が続くなら障害寄り
環境差	ブラウザを変える／シークレットで試す／拡張機能を無効化する	UI の表示崩れは改善することがあるが、500 自体は解決しないことも多い
時間差	一定時間をおいて再試行すると直るか	ロールアウト起因の一時不具合では自然復旧することがある

この時点で「設定変更で直すべき問題」なのか「待てば直る／別経路で取り出すべき問題」なのかが見えてきます。特に、突然ダウンロードだけが広範囲に失敗しはじめた場合は、まずサービス障害を疑うのが現実的です。

根本原因として多いパターン：Azure DevOps 側の一時障害（アウトージ）

質問のように、複数のパイプライン実行で共通して成果物ダウンロードが失敗し、エラーが 500 の場合、ユーザー側で完全に解決できない「サービス側の障害」であることがあります。報告事例では、新機能のロールアウトが引き金となり、その後にロールバック（巻き戻し）されて復旧した、という流れが説明されることもあります。

このタイプの障害では、パイプライン YAML やタスク設定をいじっても根本解決にならないため、次の動きが現実的です。

Azure DevOps のステータス（障害情報）や既知の問題の投稿が出ていないか確認する
一定時間をおいて再試行する（復旧後は UI から普通に落とせるようになることが多い）
復旧を待てない場合は、後述の REST API / Azure CLI の回避策で成果物だけ先に取り出す

「自分のパイプライン設定が壊れたのでは？」と焦りやすいポイントですが、500 が広範囲に出ているときは、むしろ設定は触らず、取得経路を変えるほうが安全です。

前提知識：Build Artifacts と Pipeline Artifacts の違い

Azure DevOps の「成果物」と一言でいっても、歴史的経緯から大きく 2 系統があります。いま自分がどちらを使っているかを把握すると、タスクの選定や切り分けが一気に楽になります。

観点	Build Artifacts（従来）	Pipeline Artifacts（推奨）
主な利用シーン	クラシックなビルド/リリース（GUI）と相性が良い	YAML パイプラインの標準的な成果物
発行タスク	PublishBuildArtifacts	PublishPipelineArtifact
取得タスク	DownloadBuildArtifacts	DownloadPipelineArtifact@2
運用のクセ	古い手順書が多いが、混在すると迷子になりやすい	命名とパスを決めておくと後続ジョブが安定する

今回の「UI で 500」のような問題は、どちらの成果物でも起こり得ます。ただし、パイプライン側の改善（タスク更新・統一）を進めるなら、Pipeline Artifacts に寄せるほうが長期的には得です。

パイプライン側でできる改善：古いタスクから新しいタスクへ切り替える

サービス障害とは別に、成果物の扱いが古いタスクのままになっている場合、将来的なトラブル回避のためにタスクを更新しておく価値があります。特に YAML パイプラインでは、従来の Build Artifacts 系よりも Pipeline Artifacts 系を推奨する流れが強くなっています。

まずは「発行」と「取得」をセットで揃えるのが鉄則です。発行が Build Artifacts のままなのに、取得だけ Pipeline Artifacts に置き換えると期待通りに取れないことがあります。

PublishPipelineArtifact の YAML 例（発行側）

ビルド出力を成果物として発行する代表例です。

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.SourcesDirectory)/dist'
    artifact: 'drop'

DownloadPipelineArtifact@2 の YAML 例（取得側）

成果物名を指定して、作業ディレクトリに落とす最小例です。

- task: DownloadPipelineArtifact@2
  inputs:
    artifact: 'drop'                 # ダウンロードしたい成果物名
    path: '$(Pipeline.Workspace)'    # 保存先パス

成果物名が分からない場合は、パイプライン実行結果の「Artifacts」欄に表示される名前（発行時に指定した名前）を確認します。名前の揺れがあると、タスクは成功しても期待した成果物が取れていないように見えるので、成果物名の命名規則を決めて固定しておくと運用が楽になります。

今すぐ欲しいときの回避策：REST API ＋ curl で直接ダウンロード

Web UI や標準タスクで 500 が出て止まっているときでも、成果物の取得経路を変えると回避できることがあります。代表例が Azure DevOps の REST API を直接呼び出して、成果物の downloadUrl を取得し、その URL から zip 等でダウンロードする方法です。

前提

個人用アクセストークン（PAT）を用意する（User settings > Personal access tokens）
少なくとも「Build の読み取り（Build Read）」相当の権限が必要
PAT をログや履歴に残さない（平文貼り付けは避ける）

Run ID（buildId）を確認する小ワザ

REST API や CLI では、対象 Run を示す ID（buildId / run-id）が必要になります。UI 上では「Run の詳細ページの URL」に含まれることが多いので、ブラウザのアドレスバーを確認するのが最短です。

URL に buildId=123456 のようなパラメータがある
表示上は「Run ID」と書かれていることもある

チーム内で問い合わせが頻発するポイントなので、「Run ID の見方」を手順書に 1 行だけ入れておくと、障害時のやり取りがスムーズになります。

手順：成果物の情報を取得する（downloadUrl を得る）

curl -u :<PAT> \
  "https://dev.azure.com/<ORG>/<PROJECT>/_apis/build/builds/<BUILD_ID>/artifacts?api-version=7.1-preview.5"

<ORG>：組織名
<PROJECT>：プロジェクト名
<BUILD_ID>：対象のビルド／パイプライン実行 ID（Run ID）

レスポンス JSON の中に、成果物ごとの downloadUrl が含まれます。成果物名を指定してピンポイントに取得するパターンもあります。

GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/artifacts?artifactName={name}&api-version=7.1-preview.5

手順：downloadUrl から成果物をダウンロードする

curl -L -u :<PAT> "<downloadUrl>" -o artifact.zip

-L：リダイレクト追従（downloadUrl は内部的にリダイレクトされることがあります）
-o artifact.zip：保存するファイル名（任意）

ダウンロード後は、zip を展開して中身を確認します。UI では落ちないのに REST API 経由では取れるケースがあるため、「復旧待ち」と並行して進めたいときに有効です。

（任意）downloadUrl を自動で抜き出す

レスポンス JSON から downloadUrl を目視で探すのがつらい場合は、Linux/macOS なら jq、Windows なら PowerShell の JSON 処理で自動化できます。

# jq の例（artifact 名が drop の downloadUrl を抜き出すイメージ）
curl -u :<PAT> "https://dev.azure.com/<ORG>/<PROJECT>/_apis/build/builds/<BUILD_ID>/artifacts?api-version=7.1-preview.5" \
  | jq -r '.value[] | select(.name=="drop") | .resource.downloadUrl'

障害時は「とにかく素早く取り出す」が大事なので、可能ならこのあたりまでスクリプト化しておくと強いです。

PAT を安全に扱うコツ

回避策が「PAT を使う」以上、漏洩対策をセットで考える必要があります。実務でよく効くのは次の運用です。

PAT は最小権限（Build Read など）にする
有効期限を短めにし、用途が終わったら失効させる
シェルの履歴に残る形で貼らない（環境変数、入力プロンプト、CI のシークレット機能を使う）
成果物に機密情報が混ざらないよう、発行前に除外ルール（.gitignore 的な発想）を持つ

もう一つの回避策：Azure CLI（az）で成果物をダウンロード

UI が不安定なときは、Azure CLI の Azure DevOps 拡張（azure-devops）を使って成果物を取得する方法も現場で重宝します。内部的には REST API を呼び出すため、ブラウザ UI の問題から切り離して操作できます。

前提

Azure CLI がインストールされている
拡張機能 azure-devops を追加済み
Build Read 権限を持つ PAT がある

拡張機能の追加と既定値の設定

az extension add --name azure-devops

az devops configure 
--defaults organization=[https://dev.azure.com/myorg](https://dev.azure.com/myorg)

PAT でログイン（履歴に残さない工夫込み）

コマンド例としては次のようになりますが、実運用では PAT を平文で履歴に残さないよう注意してください。

echo "mypat with build read permission" | \
  az devops login --organization https://dev.azure.com/myorg

履歴を避けたい場合は、環境変数 AZURE_DEVOPS_EXT_PAT に PAT を設定して実行する方法が定番です。

# 例：bash/zsh の場合
export AZURE_DEVOPS_EXT_PAT="<PAT>"

成果物のダウンロード

az pipelines runs artifact download \
  --organization https://dev.azure.com/myorg \
  --project "My Project" \
  --run-id 123456 \
  --path "./artifacts" \
  --artifact-name "drop"

–run-id：パイプライン実行 ID（buildId に相当）
–artifact-name：成果物名
–path：保存先ディレクトリ

CLI の良さは、取得処理をスクリプト化してチーム内に共有できる点です。障害が起きたときに「とりあえずこのコマンドで落として」と伝えられるだけで、復旧待ちの停滞を最小化できます。

よくある落とし穴：障害ではなく、保持期間（Retention）で成果物が消えている

エラーが常に 500 とは限りませんが、成果物が「もう存在しない」ことでダウンロードできないケースもあります。特に、古い Run の成果物を後から取りに行く運用では、保持期間（Retention）に引っかかりやすいです。

一定日数が経過した Run は自動的に削除される設定になっている
削除されると成果物も合わせて消え、UI で見えていてもダウンロードできないことがある
重要な Run は「保持（Retain）」や「Keep forever」相当の設定で残す

チームで「いつでも過去成果物を取れる前提」で運用しているなら、保持期間の設計を見直すだけでトラブルが激減します。障害対応のドサクサで見落としがちなので、チェックリスト化しておくのがコツです。

権限・ネットワーク・ブラウザの観点で確認しておきたいこと

500 の場合はサービス側が濃厚ですが、現場では複合要因も起こります。次の項目は「障害ではない」ケースを潰すために役立ちます。

カテゴリ	よくある原因	対処の例
権限	プロジェクト閲覧はできるが Build Read が不足している／特定のパイプラインに制限がある	プロジェクト権限と、パイプラインのセキュリティ設定を確認する
ネットワーク	プロキシ／SSL インスペクションで大きなファイル取得が不安定	別ネットワークで試す、CLI でリトライを入れる
ブラウザ	拡張機能、キャッシュ、Cookie が UI の挙動を壊している	シークレット、別ブラウザ、拡張機能無効で再現性を見る
成果物の中身	想定以上に巨大、ファイル数が多すぎる、不要ファイルを含めている	成果物を「配布に必要な最小限」に絞る（ビルド出力の整理）

特に成果物が巨大化していると、障害が起きていない時でも「ダウンロードが遅い／途中で失敗する」など別の痛みが出ます。CI で成果物を発行するときは、配布に必要なものだけに絞るのが長期的には最強の対策です。

止めないための運用設計：障害を前提に“代替ルート”を用意する

Azure DevOps は十分に安定していますが、クラウドサービスである以上、ゼロ障害はありません。成果物が業務の要（たとえばリリース用パッケージ）なら、「ダウンロードできない日がある」前提で設計すると強くなります。

手順書を用意：UI が落ちたら REST API / Azure CLI で落とす手順をチーム wiki に置く
成果物名を固定：artifact 名の揺れをなくし、CLI のコマンドをコピペで使える状態にする
重要成果物は二重化：必要に応じて Azure Storage など別ストレージへも複製する（機密とコストに注意）
保持期間を設計：監査・再現のために必要な Run は保持するルールを決める

ここまでやると、障害が起きても「作業が止まる」から「取得ルートを切り替えて続けられる」に変わります。現場の生産性はこの差が大きいです。

まとめ：まず障害を疑い、待てないときは API / CLI で取り出す

成果物ダウンロードで 500 – Something went wrong! が広範囲に出るなら、サービス側の一時不具合の可能性が高い
パイプライン側は「発行と取得」を揃え、可能なら Pipeline Artifacts（PublishPipelineArtifact / DownloadPipelineArtifact@2）へ寄せる
復旧を待てないときは、REST API＋curl で downloadUrl を取得して直接ダウンロードする
スクリプト化するなら、Azure CLI（az）＋ azure-devops 拡張でのダウンロードが運用しやすい
PAT は最小権限・短期限・漏洩対策をセットで扱う

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure DevOps パイプライン成果物がダウンロードできない（500 Something went wrong）原因と回避策：DownloadPipelineArtifact・REST API・Azure CLI

現象：Azure DevOps でパイプライン成果物（artifact）がダウンロードできない

最初にやるべき切り分け：サービス障害か、個別設定か

根本原因として多いパターン：Azure DevOps 側の一時障害（アウトージ）

前提知識：Build Artifacts と Pipeline Artifacts の違い

パイプライン側でできる改善：古いタスクから新しいタスクへ切り替える

PublishPipelineArtifact の YAML 例（発行側）

DownloadPipelineArtifact@2 の YAML 例（取得側）

今すぐ欲しいときの回避策：REST API ＋ curl で直接ダウンロード

Run ID（buildId）を確認する小ワザ

手順：成果物の情報を取得する（downloadUrl を得る）

手順：downloadUrl から成果物をダウンロードする

（任意）downloadUrl を自動で抜き出す

PAT を安全に扱うコツ

もう一つの回避策：Azure CLI（az）で成果物をダウンロード

拡張機能の追加と既定値の設定

PAT でログイン（履歴に残さない工夫込み）

成果物のダウンロード

よくある落とし穴：障害ではなく、保持期間（Retention）で成果物が消えている

権限・ネットワーク・ブラウザの観点で確認しておきたいこと

止めないための運用設計：障害を前提に“代替ルート”を用意する

まとめ：まず障害を疑い、待てないときは API / CLI で取り出す

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure DevOps パイプライン成果物がダウンロードできない（500 Something went wrong）原因と回避策：DownloadPipelineArtifact・REST API・Azure CLI

現象：Azure DevOps でパイプライン成果物（artifact）がダウンロードできない

最初にやるべき切り分け：サービス障害か、個別設定か

根本原因として多いパターン：Azure DevOps 側の一時障害（アウトージ）

前提知識：Build Artifacts と Pipeline Artifacts の違い

パイプライン側でできる改善：古いタスクから新しいタスクへ切り替える

PublishPipelineArtifact の YAML 例（発行側）

DownloadPipelineArtifact@2 の YAML 例（取得側）

今すぐ欲しいときの回避策：REST API ＋ curl で直接ダウンロード

Run ID（buildId）を確認する小ワザ

手順：成果物の情報を取得する（downloadUrl を得る）

手順：downloadUrl から成果物をダウンロードする

（任意）downloadUrl を自動で抜き出す

PAT を安全に扱うコツ

もう一つの回避策：Azure CLI（az）で成果物をダウンロード

拡張機能の追加と既定値の設定

PAT でログイン（履歴に残さない工夫込み）

成果物のダウンロード

よくある落とし穴：障害ではなく、保持期間（Retention）で成果物が消えている

権限・ネットワーク・ブラウザの観点で確認しておきたいこと

止めないための運用設計：障害を前提に“代替ルート”を用意する

まとめ：まず障害を疑い、待てないときは API / CLI で取り出す

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル