Azure DevOpsパイプラインをClaude Codeで点検する: 制作会社の承認付き公開フロー

制作会社の公開前チェックで、PRの差分、ステージングURL、クライアント承認メモ、Azure Pipelinesのrun画面が別々に残っていると、「軽微修正です」の一言で公開事故まで進みます。今日まず直す1箇所は、PR承認と本番公開承認を同じチェックにしないための公開フロー表です。

この記事では、制作会社がAzure DevOpsパイプラインを使って、承認付き公開フローを作る前に、Claude Codeで点検メモを作る流れを書きます。対象は、Webサイト、LP、採用ページ、キャンペーンページを毎週公開しているディレクターとフロントエンド担当者です。Azure Pipelinesのapprovals and checks、ManualValidation、branch policiesを、制作現場の言葉に置き換えます。

参考にした一次情報は、Pipeline deployment approvals、ManualValidation@1 task、release gates and approvals、branch policies、pipeline tasks referenceです。公開確認の考え方は、制作会社のクラウド公開フローともつながります。

この記事の要点

• 制作会社の公開事故は、コードミスだけでなく、PR承認、ステージング確認、本番承認、戻し方が同じ会話に混ざる時に起きる。
• Azure Pipelinesのenvironment approvalsは、本番環境へ入る前の門にする。YAML内のManualValidationは、ステージングURLや差分を人が見る待ち時間に使う。
• Branch policiesはmainやrelease branchを守るために使い、PR reviewer、build validation、comment解決を公開前の入口に置く。
• Claude Codeには、pipeline YAML、PR差分、チェックリスト、公開手順を読ませ、抜けている承認と証跡を表にさせる。
• 人が見る範囲は、クライアント承認、文言・法務・広告表現、公開日時、戻し方、請求や納品範囲です。

制作会社の公開フローで起きる失敗シーン

ディレクターが見ている画面は、Azure ReposのPR、ステージングURL、Figmaまたは修正指示、クライアントのチャット、Azure Pipelinesのrun画面です。小さな文言修正でも、公開対象が採用LP、広告LP、料金ページなら、表示崩れや古い文言がそのまま売上や問い合わせに響きます。

よくあるのは、PRではコード差分だけ承認され、ステージングURLの確認がチャットで流れ、本番公開は別の担当がpipelineを再実行する形です。あとで問題が出ても、誰が何を見てOKにしたのか、どのURLを見たのか、戻すcommitは何かが追えません。制作会社では、速度よりも「承認の種類を分ける」方が事故を減らします。

Azure Pipelinesのapprovals and checksでは、static checks、pre-check approvals、dynamic checks、post-check approvals、exclusive lockの順で確認されると説明されています。ManualValidation@1はstageの中でrunを止め、人が確認してから続けるtaskです。Branch policiesはmainなどのbranchを守り、reviewer、build、status checkをPR前後に置くためのものです。この3つを混ぜずに並べるのが、制作会社向けの第一歩です。

Claude Codeに任せる範囲と人が見る範囲

PR画面とpipeline YAMLを前にして、Claude Codeに任せるのは抜け漏れの表作りです。trigger、branch、build、test、staging deploy、manual validation、production environment、rollback note、client approval、通知先を読み取り、どこで人が止めるかを表にします。

人が見る範囲は、クライアントが承認した範囲、広告表現、薬機法や景表法に近い表現、料金、公開日時、SNSや広告との同時公開、戻し方です。Claude Codeは「このLPは公開してよい」と判断しません。代わりに、「公開前に見るURL、差分、承認者、戻し方が足りない」と警告する役目です。

Azure側では、環境のapprovals and checksとYAML内のManualValidationの役割を分けます。本番環境に入る門はenvironment approval。ステージングURLを見てクライアント確認を待つ一時停止はManualValidation。PRをmainへ入れる前の保護はbranch policy。ここを分けておくと、公開が止まった時に「PRが止まったのか、本番承認が止まったのか、クライアント確認が止まったのか」が見えます。

3つのUse case

Use case 1: PR承認と本番承認を分ける

• 入力: PR URL、差分、build結果、reviewer、main branch policy、公開対象ページ。
• 出力: PRで見る項目、本番前に見る項目、クライアント承認で見る項目の3列表。
• 人の確認: 料金、広告表現、法務確認、クライアント承認、公開日時、戻し方を見る。

PR承認は「mainへ入れてよいか」の確認です。本番承認は「いま公開してよいか」の確認です。この2つを同じapproveにすると、制作会社では事故が増えます。Claude Codeには、PR templateやpipeline YAMLから承認の種類を抜き出させ、人が公開判断を分けます。

Use case 2: ステージングURLでManualValidationを止める

• 入力: staging URL、確認者メール、差分要約、スクリーンショット、戻し方、期限。
• 出力: ManualValidation@1のinstructions案と、確認者が見るチェックリスト。
• 人の確認: スマホ表示、フォーム送信、画像差し替え、リンク、計測タグ、クライアントOKを見る。

ManualValidationは、pipeline runの途中で人が見る時間を作るためのtaskです。制作会社なら、長いYAMLを見せるより、staging URL、PR差分、確認項目、戻し方をinstructionsにまとめる方が現場で使えます。Claude Codeには文面案を作らせ、人は承認者と期限を決めます。

Use case 3: 本番environmentのapprovals and checksを表にする

• 入力: production environment名、approver、branch control、business hours、exclusive lock、通知先。
• 出力: 本番環境へ入る前の門、順番、担当者、timeout、失敗時の連絡先表。
• 人の確認: 自分の変更を自分で承認しない設定、夜間公開、広告開始時刻、戻し担当を見る。

本番公開はYAMLだけで守るより、environment側のapprovals and checksも見ます。Azure DevOpsのUIで本番environmentに承認者を置き、branch controlやbusiness hoursを組み合わせると、公開判断がpipelineの外側でも残ります。Claude Codeには、現在の設定メモとYAMLを突き合わせ、抜けた門を出させます。

コピペで使えるプロンプト

あなたは制作会社のAzure DevOps公開フロー点検担当です。
目的は、PR承認、ステージング確認、クライアント承認、本番公開承認、戻し方を混ぜないことです。

入力:
- azure-pipelines.yml
- PR template
- branch policyのメモ
- production environmentのapprovals and checksメモ
- ステージングURLの確認項目
- 直近の公開事故または差し戻しメモ

出力:
1. PRで見る項目、本番前に見る項目、クライアント承認で見る項目の3列表
2. ManualValidation@1に入れるinstructions案
3. production environmentに置くapprovals and checks案
4. branch policyで守る項目: reviewer、build validation、comment解決、status check
5. 今日30分で直す1箇所

制約:
- クライアント承認、広告表現、料金、法務確認、公開日時はAI判断にしない
- 自分の変更を自分だけで本番承認する設計にしない
- staging URL、PR差分、rollback noteを承認文面に入れる

動く確認コード

次のコードは、pipeline textにstaging、ManualValidation@1、server pool、production environment、rollback noteがあるかを見ます。実Azureには接続しません。制作会社の初回レビューでは、まずこの程度の機械チェックで「本番前に人が止まる場所があるか」を見ます。

const pipelineText = [
  "trigger:",
  "  branches:",
  "    include:",
  "      - main",
  "stages:",
  "  - stage: Build",
  "    jobs:",
  "      - job: build",
  "        steps:",
  "          - script: npm ci && npm run build",
  "  - stage: DeployStaging",
  "    jobs:",
  "      - job: deploy_staging",
  "        steps:",
  "          - script: echo deploy staging",
  "  - stage: ClientCheck",
  "    jobs:",
  "      - job: wait_for_client",
  "        pool: server",
  "        steps:",
  "          - task: ManualValidation@1",
  "            inputs:",
  "              notifyUsers: [email protected]",
  "              instructions: Check staging URL, PR diff, rollback note, and client approval.",
  "  - stage: DeployProduction",
  "    jobs:",
  "      - deployment: production",
  "        environment: production",
  "        strategy:",
  "          runOnce:",
  "            deploy:",
  "              steps:",
  "                - script: echo deploy production"
].join(String.fromCharCode(10));

const required = [
  { name: "main branch trigger", pattern: /- main/ },
  { name: "staging stage", pattern: /DeployStaging/ },
  { name: "manual validation", pattern: /ManualValidation@1/ },
  { name: "server pool for manual validation", pattern: /pool:\s*server/ },
  { name: "production environment", pattern: /environment:\s*production/ },
  { name: "rollback note in approval text", pattern: /rollback/i }
];

const findings = [];
for (const rule of required) {
  if (!rule.pattern.test(pipelineText)) {
    findings.push({ item: rule.name, fix: "add this gate before production release" });
  }
}

const productionIndex = pipelineText.indexOf("DeployProduction");
const validationIndex = pipelineText.indexOf("ManualValidation@1");
if (productionIndex !== -1 && validationIndex !== -1 && validationIndex > productionIndex) {
  findings.push({
    item: "approval order",
    fix: "place client/manual validation before production deployment"
  });
}

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

このコードが空のtableを出せば、最低限の文字列は揃っています。もちろん、実際の承認者やenvironment checkはAzure DevOps側のUI設定も見る必要があります。Claude Codeには、このコード結果、YAML、UI設定メモを合わせて、公開前レビュー表を作らせます。

Pitfall: よくある落とし穴

原因: PR approveを本番公開OKと同じ意味にする。直し方: PRではmainへ入れる可否、本番environmentでは公開可否、ManualValidationではステージングURL確認を分けます。承認名も「コードレビュー」「クライアント確認」「本番公開」に分けます。

原因: ManualValidationのnotifyUsersだけで承認権限を制御した気になる。直し方: 通知先と承認可能者は同じとは限りません。environment approvalや権限設定を見て、誰がapproveできるかを別表にします。

原因: 戻し方を書かずに公開する。直し方: rollback commit、直前artifact、戻し担当、連絡先をManualValidationのinstructionsか公開メモに入れます。戻せない公開は、承認ではなく賭けになってしまいます。

原因: branch policyを外して急ぎ対応する。直し方: 緊急時の例外ルールを先に作り、事後レビュー、期限、承認者、戻し方を残します。急ぎのたびにmainを直接触ると、制作会社の運用はすぐ崩れます。

よくある質問

Q. ManualValidationとenvironment approvalはどちらを使えばよいですか？ A. 役割が違います。ステージ内で人に確認させたい時はManualValidation、本番environmentへ入る門を作りたい時はapprovals and checksを使います。

Q. クライアント承認はAzure DevOpsに入れるべきですか？ A. クライアントがAzure DevOpsを使わないなら、承認メールやチャットのURLを公開メモへ残す形でもよいです。ただし、誰が、いつ、どのURLを見たかはpipeline runと結びます。

Q. 制作会社でもbranch policyは必要ですか？ A. 必要です。小さな文言修正でも、料金、採用、広告LPは売上や問い合わせに影響します。main branchはreviewer、build、comment解決で守ります。

Q. Claude Codeにapproveさせてもよいですか？ A. いいえ。Claude Codeは差分要約、抜け漏れ、チェックリスト作りまでです。本番公開、クライアント承認、広告表現、料金は人が見ます。

研修・相談につなげるなら何を見るか

制作会社でAzure DevOps公開フローを直す時は、CI/CDのYAMLだけでは足りません。PR template、branch policy、staging URL、クライアント承認、ManualValidation、production environment、rollback noteを1枚で見る必要があります。Claude Codeに任せるなら、まず現状のYAMLと公開手順から「どこで人が止まるか」を表にするのが近道です。

この公開フローを自社案件に合わせて整えたい場合は、Claude Code研修・相談で、実際のPR、pipeline YAML、公開チェックリストを題材にできます。相談前に持ってくるものは、直近のPR URL、公開手順、ステージングURLの確認項目、戻し方メモだけで十分です。

実際に試した結果

この記事では、Azure DevOps公式資料、pipeline approvals、ManualValidation@1、branch policies、記事内JavaScript確認コード、内部リンク、CTA、frontmatter、slugを確認しました。コードはManualValidation、server pool、production environment、rollback noteの有無を見ます。今日まずやる1手は、直近のazure-pipelines.ymlを開き、PR承認、ステージング確認、本番承認を3列に分けることです。