変更要約: AZ-400 第3章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
3.1CI パイプラインとビルド
継続的インテグレーション——Azure Pipelines（YAML）、トリガー、エージェント（Microsoft ホスト/セルフホスト）、テンプレート/ステージ、自動テスト——を理解します。コミットごとに自動でビルド・検証します。
AZ-400 の中核はパイプラインです。Azure Pipelines を YAML でコード化し、コミットごとに自動ビルド・テストします。
3.1.1CI パイプラインの構成
- YAML パイプライン：パイプラインをコードとして管理（ステージ→ジョブ→ステップ）。
- トリガー：push/PR/スケジュールで自動起動。CI は push トリガーが基本。
- エージェント：Microsoft ホスト（管理不要） か セルフホスト（独自環境/特殊依存） を選ぶ。
- テンプレート：共通のステップ/ジョブを再利用し、重複を避ける。
「パイプラインのコード化＝YAML」「自動起動＝トリガー（push/PR/スケジュール）」「管理不要＝Microsoft ホストエージェント、独自環境/特殊依存＝セルフホスト」「再利用＝テンプレート」 は AZ-400 で頻出です。CI は早く小さくビルド・テストし、失敗時はパイプラインを止めます。
特定の OS/ツール、社内ネットワーク、GPU など特殊要件があるときはセルフホストエージェントを選びます。通常は Microsoft ホストで十分です。
AZ-400 の CI 設計は「パイプラインをコードで構造化し、速く確実にビルド・テストする」ことを問います。YAML パイプラインは stages→jobs→steps（tasks/scripts）の階層で、trigger（CI＝ブランチ push）と pr（PR トリガー）、schedules（cron）で起動し、pool でエージェントプールを指定します。再利用はテンプレート（step/job/stage/variable テンプレート、パラメーター付き）で行い、組織横断の標準化に効きます。エージェントは Microsoft ホスト（毎回クリーン・管理不要・並列実行数の購入）とセルフホスト（独自 OS/ツール、社内ネットワーク到達、GPU、キャッシュ常駐で高速）を要件で選びます。高速化は、依存関係キャッシュ（Cache タスク）・ジョブの並列/マトリックス実行・成果物の発行（PublishPipelineArtifact）と段階間受け渡し・変更パスフィルターで行います。品質面では、テストを CI に組み込み失敗で停止、テスト結果（PublishTestResults）とカバレッジを発行してダッシュボード化、SAST/依存スキャンを左側（PR/CI）に寄せます（シフトレフト）。環境はサービス接続や変数グループで構成し、シークレットはログに出さない設定にします。設計の要は、YAML でコード化し、テンプレートで再利用、エージェントを要件に合わせ、キャッシュ/並列で速く、テスト失敗で確実に止めることです。
| 観点 | 選択/機能 | 要点 |
|---|---|---|
| パイプライン定義 | YAML（コードとして） | stages→jobs→steps・レビュー/版管理可 |
| 起動条件 | trigger / pr / schedules | CI は push、検証は PR トリガー |
| 実行環境 | MS ホスト / セルフホスト | 管理不要 / 特殊要件・キャッシュ常駐 |
| 再利用と高速化 | テンプレート・キャッシュ・並列 | 重複排除＋ビルド短縮 |
シナリオ：複数の言語/サービスのリポジトリで CI が遅く、各チームがコピペした似た YAML を保守している。→ 共通のビルド/テスト手順をステップ/ジョブテンプレートに切り出してパラメーター化し、各パイプラインから参照（重複排除）。依存関係キャッシュとマトリックス並列実行でビルド時間を短縮。テストは CI に組み込み、PublishTestResults で結果をダッシュボード化。これでリードタイム短縮と一貫性を同時に得ます。
FAQ：Microsoft ホストとセルフホスト、どちらのエージェント？ 標準的な OS/ツールで、メンテナンスを避けたいなら Microsoft ホスト（毎回クリーンで再現性が高い）。特殊な OS/ツール、社内ネットワーク内リソースへの到達、GPU、大きな依存のキャッシュ常駐で高速化が要るなら セルフホスト。コストと並列実行数、メンテナンス負担を踏まえて選びます。
ひっかけ：パイプラインをクラシック GUI（コード化なし）で組むのは、レビュー/バージョン管理/再利用の観点で弱く、AZ-400 は YAML（コードとして）を推奨します。また「ビルドを速くしたい」を闇雲なエージェント増強で解こうとせず、まずキャッシュ・並列/マトリックス・不要ステップ削減を検討します。テストを CI から外して速くするのは本末転倒（変更失敗率が上がる）です。
3.1.2この節のまとめ
- CI＝YAML パイプライン＋トリガー＋エージェント
- 再利用＝テンプレート／成果物＝アーティファクト発行
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. パイプラインの定義をコードとしてリポジトリで管理し、レビュー・バージョン管理したい。何を使いますか？
Q2. 特定の社内ツールや GPU が必要なビルドを実行したい。どのエージェントを使いますか？
Q3. 複数のパイプラインで共通するビルド手順を一元管理し、重複を避けたい。何を使いますか？