以前書こうと思っていたのですが、バタバタしていてまとめる機会がなかなか無く、やっと時間が取れたので、昔を思い出しながら書いてみます。
1. はじめに：Azure Pipelinesは「おまかせ」で動かない？
Azure DevOpsを使い始めたばかりの頃、私は感動しました。
「.NET Core」というテンプレートを選ぶだけで、勝手にYAMLファイルが生成され、あとは実行ボタンを押すだけ。
「これでCI/CD対応完了だ！」と意気揚々と実行した結果、画面に表示されたのは無情な赤いバツ印（Failed）でした。
なぜ、Microsoft純正のテンプレートなのにそのままでは動かないのか？
今回は、初心者が必ずハマる「デフォルトYAMLの落とし穴」と、その修正ポイントをまとめます。
2. 【罠1】SDKのバージョンが合っていない
デフォルトのYAMLには、多くの場合「どのバージョンの.NET SDKを使うか」という指定が抜けています。その結果、Agent（ビルド用マシン）にインストールされている最新バージョンが使われ、古いプロジェクトや新しすぎるプロジェクトがビルドエラーになります。
解決策：UseDotNet@2 タスクを最初に追加する
ビルド（Build）タスクの前に、明示的にバージョンを指定するタスクを差し込みます。
steps:
- task: UseDotNet@2
displayName: 'Install .NET SDK 8.x'
inputs:
packageType: 'sdk'
version: '8.x' # 自分のプロジェクトのバージョンに合わせる
3. 【罠2】プロジェクトファイルが見つからない
デフォルトでは、リポジトリのルート（一番上の階層）に .csproj や .sln があることを想定しています。しかし、実際の開発では src/ フォルダの中にコードをまとめていることが多いはずです。
解決策：projects プロパティを書き換える
テンプレートのままだと、以下のようなエラーで止まります。
##[error]Project file(s) matching the specified pattern were not found.
これを防ぐために、ワイルドカードを使ってプロジェクトファイルを指定します。
修正前（デフォルト）:
- task: DotNetCoreCLI@2
inputs:
command: 'build'
arguments: '--configuration $(buildConfiguration)'
修正後：
- task: DotNetCoreCLI@2
inputs:
command: 'build'
# リポジトリ全体から.csprojを探すように指定
projects: '**/*.csproj'
arguments: '--configuration $(buildConfiguration)'
4. 【罠3】NuGetリストアの失敗
「ビルドタスクの中で一緒にリストア（ライブラリの復元）もやってくれるだろう」と思いがちですが、ここでも認証エラーやパスの問題が起きることがあります。
解決策：Restoreタスクを分離して明示する
ビルドとは別に restore コマンドを明示的に実行するのが、安定させるコツです。
- task: DotNetCoreCLI@2
displayName: 'Restore NuGet Packages'
inputs:
command: 'restore'
projects: '**/*.csproj'
5. まとめ：デフォルトは「完成品」ではなく「下書き」
Azure Pipelinesが用意してくれるデフォルトのスクリプトは、あくまで「最低限の構成案」です。
1. SDKバージョンを指定する
2. プロジェクトの階層（パス）を正しく伝える
3. リストア、ビルド、テストを順序よく構成する
この3点を意識するだけで、あの赤いエラー画面から卒業できるはずです。