Azure DevOpsのSprint 271アップデートが公開され、セキュリティ面で見過ごせない変更が加わった。期限切れのPAT（Personal Access Token）をUI・APIの双方から一切変更できなくなったのだ。地味に見えて、実務への影響は小さくない。

「期限切れなのに生きていた」問題、ついに修正

これまでAzure DevOpsでは、PATの有効期限が切れた後でも、特定の条件下で延長や変更が可能な状態が続いていた。「発見されたギャップ」とMicrosoftは表現しているが、要するに設計上の抜け穴だ。

今回のSprint 271からは、期限切れPATはUIからもAPIからも変更できなくなった。対処は明快——新しいトークンを発行するか、既存トークンを再生成するかのどちらかだ。

この変更が意味することは3点に集約される。

  • 真の有効期限強制: トークンは設定した期日に確実に失効する
  • 漏洩・放置トークンのリスク低減: 誰かが流出させたトークンが静かに延命し続けるシナリオを防ぐ
  • 監査・コンプライアンスの整合性: 「このトークンはXX日まで有効のはず」という前提が崩れなくなる

日本のIT現場への影響

日本のエンタープライズ環境では、CI/CDパイプラインやサービス連携にPATを長期間使い回しているケースがまだ少なくない。「とりあえず1年で発行してあとは放置」という運用は珍しくなく、期限が切れそうになったらUIで延長——という習慣が染み付いているチームもある。

今回の変更で、そのフローは完全に機能しなくなった。早めに以下の対応を検討したい。

1. PAT棚卸しの実施 現在使用中のPATの一覧を確認し、有効期限と用途を整理する。Azure DevOpsの組織設定から「Personal access tokens」の一覧が確認できる。

2. 短命トークンへの移行 Microsoftも推奨しているとおり、PATは短期間（30〜90日）で発行し直す運用が望ましい。長期トークンは攻撃対象になりやすい。

3. Microsoft Entra IDベースの認証への移行検討 サービスプリンシパルやマネージドIDを活用したEntraベースの認証に移行できるワークロードは、積極的に移行を進めるべきだ。人間が管理するシークレットを減らすほど、リスクも管理コストも下がる。

合わせて注目：リモートMCPサーバーのパブリックプレビュー

セキュリティ修正と同時に、Azure DevOpsのリモートMCPサーバーがパブリックプレビューに入った。

https://mcp.dev.azure.com/{organization} というエンドポイントをMCPクライアントに設定するだけで、ローカルサーバーを立てることなくAzure DevOpsとのAI統合が可能になる。Visual StudioおよびVS Codeがすでに対応しており、Microsoft FoundryやCopilot Studioへの対応も近く予定されているという。

AIエージェントがAzure DevOpsのワークアイテムやリポジトリを直接操作できるようになる流れは、開発ワークフロー自動化の文脈で注目しておく価値がある。

筆者の見解

PATのセキュリティギャップ修正は、やって当然のことをやった——という評価が正直なところだ。しかし「やって当然のことを確実にやる」のが、実は一番難しく、かつ最も重要でもある。Just-In-Time原則やゼロトラストの観点からすれば、「期限切れトークンが変更可能」という状態はそもそも存在してはならなかった。今回の修正で、トークンのライフサイクル管理がようやく設計意図どおりに動くようになった。

一方で、現場への影響は軽視できない。「今まで通りにできなくなった」ことで、パイプラインが突然壊れるチームも出てくるだろう。変更前に通知があれば、と思わないでもないが——問題は、そもそも期限切れトークンを延命させる運用自体がリスクであって、今こそその設計を見直す機会と捉えるべきだ。

リモートMCPサーバーについては、今後の広がり方を注視したい。Azure DevOpsを中心に据えた開発ワークフローにAIエージェントが組み込まれていく流れは、Microsoft Foundryとの連携も含めて、長期的に面白い方向に進む可能性がある。Azure DevOpsは地味だが堅実なプラットフォームだ。ここが踏み台になって開発自動化が進むなら、それはエンジニアにとって悪くない未来だと思っている。

出典: この記事は Azure DevOps Sprint 271 Update: Expired PATs Can No Longer Be Modified の内容をもとに、筆者の見解を加えて独自に執筆したものです。