Azure DevOps Server Patch 6でTFVCポリシーを保存できない理由と移行・一時再有効化

Azure DevOps Server Patch 6の適用後、TFVCの既存チェックインポリシーは表示できるのに、追加・編集した内容を保存できない場合があります。これは権限設定の破損やPatch 6の単純な不具合ではなく、レガシー形式のTFVCチェックインポリシーを段階的に廃止するための意図的な変更です。

2026年7月21日に公開されたPatch 6では、旧形式ポリシーの保存が既定で無効化されました。一方、既存のポリシーデータは引き続き読み取れます。公式には、必要なプロジェクトだけ保存を一時的に再有効化できますが、これは恒久対策ではありません。管理者は例外を最小限に絞り、標準ポリシーを新形式で作り直すか、カスタムポリシーを新しいAPIと保存方式へ移行する必要があります。(Microsoft Learn)

Patch 6適用後にTFVCチェックインポリシーで起きること

Patch 6適用後の動作を整理すると、次のようになります。

操作	Patch 6適用後の動作
既存の旧形式ポリシーを表示する	読み取り可能
既存ポリシーを使ってチェックイン時に評価する	現段階では継続可能
旧形式ポリシーを新規作成する	既定では保存不可
旧形式ポリシーを編集して再保存する	既定では保存不可
「Obsolete」と表示されない新形式ポリシーを作成する	対応するVisual Studioから移行可能
旧形式ポリシーの保存を一時的に戻す	管理者がプロジェクト単位で実施可能
将来も旧形式を使い続ける	非推奨。今後のパッチでさらに制限される可能性あり

保存だけを先に止め、読み取りを残しているのは、既存プロジェクトを突然停止させずに移行期間を確保するためです。Microsoftは、今後のパッチでも段階的な廃止を継続すると明記しています。現在読めるからといって、その状態が将来も維持されるわけではありません。(Microsoft Learn)

Azure DevOps Server 2022.2のPatch 6とは別物

今回の変更が含まれるのは、2025年12月公開の現行Azure DevOps Serverに対するPatch 6です。

Azure DevOps Server 2022 Update 2を使用している環境では、同じTFVCポリシー変更は2026年7月21日公開のPatch 11に含まれます。2025年6月に公開された「Azure DevOps Server 2022 Update 2 Patch 6」は別のパッチであり、今回のTFVC変更とは直接関係ありません。(Microsoft for Developers)

製品	該当パッチ
Azure DevOps Serverの現行リリース	Patch 6
Azure DevOps Server 2022 Update 2	Patch 11
Azure DevOps Server 2022 Update 2 Patch 6	今回とは別の旧パッチ

パッチ番号だけで判断すると、誤ったリリースノートやインストーラーを参照する恐れがあります。最初に製品のメジャーバージョンまで確認してください。

保存できない理由はレガシー保存方式の廃止

TFVCのチェックインポリシーには、次のようなものがあります。

ビルドが成功していることを要求するBuildポリシー
チェンジセットへのコメントを要求するChangeset Comments Policy
作業項目の関連付けを要求するWork Itemsポリシー
コード分析の実行を要求するCode Analysisポリシー
独自に開発されたカスタムチェックインポリシー

Microsoftは、これらのポリシーをサーバーに保存する仕組みを変更しています。従来の実装と保存方式には制約があるため、旧形式を「Obsolete」として扱い、新しい保存モデルへ切り替えています。(Microsoft for Developers)

移行は大きく次の順序で進められています。

新形式への移行手段を提供する
旧形式の新規保存を停止する
旧形式の読み取りや実行も段階的に停止する

Patch 6は、Azure DevOps Server側で旧形式の保存を既定で止める段階に相当します。そのため、「一覧は開ける」「現在の設定も読める」「しかしOKを押して保存すると失敗する」という、一見すると矛盾した動作になります。

これは公式に解決策または回避策が用意された仕様変更であり、修正パッチが出るまで待つ種類の障害ではありません。基本的な解決策は新形式への移行で、一時的な回避策がプロジェクト単位の保存再有効化です。

Patch 6の影響か、権限やクライアントの問題かを切り分ける

チェックインポリシーを保存できない原因が、必ずしもPatch 6だけとは限りません。次の表を使って切り分けます。

状況	疑うべき原因
Patch 6適用直後から、管理者を含む全員が旧ポリシーを保存できない	Patch 6による旧形式保存の無効化
既存ポリシーは表示され、一覧に「Obsolete」がある	旧形式ポリシーが残存
一部のユーザーだけ保存できない	プロジェクトレベルの権限不足
古いVisual Studioだけで保存に失敗する	新形式に対応していないクライアント
標準ポリシーは移行できるが、独自ポリシーだけ失敗する	カスタムポリシーのAPIまたはシリアライズ方式
新形式ポリシーも保存できない	権限、クライアント、拡張機能、サーバーログを追加調査
チェックイン自体ができず、ポリシーも画面に表示されない	廃止処理がさらに進んだ状態や隠れた旧ポリシーメタデータ

TFVCチェックインポリシーを追加、編集、削除するには、通常はプロジェクトレベルの「Edit project-level information」権限が必要です。Project Administratorsに所属していても、個別ユーザーや別グループに明示的な拒否が設定されていないか確認してください。(Microsoft Learn)

Patch 6が適用されているか確認する

Microsoftは、ダウンロードしたパッチインストーラーにCheckInstallを付けて実行する確認方法を案内しています。

<patch-installer>.exe CheckInstall

Azure DevOps Server上で実行し、インストール済みと表示されるか確認します。ファイル名は実際にダウンロードしたPatch 6のインストーラー名へ置き換えてください。(Microsoft for Developers)

移行前に影響を受けるプロジェクトを洗い出す

いきなりポリシーを削除したり、一時再有効化を全プロジェクトへ適用したりしてはいけません。最初に影響範囲を一覧化します。

最低限、次の情報を記録してください。

確認項目	記録する内容
プロジェクト	TFVCを使用しているプロジェクト名
ポリシー名	Build、Work Items、Code Analysisなど
表示状態	「Obsolete」の有無
設定値	対象ビルド、クエリ、パス、ルールセットなど
種類	Visual Studio標準またはカスタム
配布方法	VSIX、社内インストーラー、手動DLL配置など
利用クライアント	Visual Studioのエディションとバージョン
業務影響	保存不可のみか、チェックインも停止しているか
管理責任者	ポリシーの内容を判断できる担当者
移行期限	一時再有効化を終了する予定日

設定画面のスクリーンショットだけでなく、パスフィルター、作業項目クエリ名、コード分析ルールセット、カスタムポリシーDLLのバージョンも残します。

特にカスタムポリシーは、開発者やソースコードが不明なまま削除すると、同じ条件を再現できなくなることがあります。

TFVCチェックインポリシーの保存を一時的に再有効化する考え方

Patch 6の公式リリースノートでは、管理者が必要に応じてプロジェクト単位で旧形式ポリシーの保存を一時的に再有効化できると説明されています。(Microsoft Learn)

ただし、公開されているリリースノートには、一時再有効化に使う設定名、コマンド、データベース操作手順までは記載されていません。そのため、インターネット上で推測されたレジストリ値やSQLをそのまま実行するのは危険です。

対象ビルド向けの正式な手順が管理資料やサポート情報に提示されていない場合は、Microsoft Supportへ次の情報を添えて、プロジェクト単位の一時再有効化手順を確認します。

Azure DevOps Serverの製品バージョン
適用済みパッチ
対象プロジェクト名
TFVCチェックインポリシーの種類
標準ポリシーかカスタムポリシーか
Visual Studioのバージョン
発生しているエラーメッセージ
一時再有効化が必要な理由
移行完了予定日

一時再有効化の実施手順

運用上は、次の順序で進めるのが安全です。

対象プロジェクトを限定する 全プロジェクトを一律に戻さず、旧形式の保存が本当に必要なプロジェクトだけ選びます。
既存設定を記録する ポリシー名、設定値、対象パス、関連するビルドやクエリを保存します。
終了日時を先に決める 「移行が終わったら解除する」ではなく、変更申請に再無効化日時を明記します。
対象ビルド用の公式手順で一時再有効化する Microsoftから案内されたプロジェクト単位の方法だけを使用します。
旧形式の運用を継続するのではなく、新形式を作成する 一時再有効化中に行うべきことは、旧形式の修正ではなく移行です。
チェックインテストを行う ポリシーに違反するケースと満たすケースの両方を試します。
旧形式を削除し、一時再有効化を解除する 新形式で正常に動作することを確認してから旧形式を外します。
変更記録を残す 対象プロジェクト、作業者、実施日時、移行前後のポリシーを記録します。

一時再有効化は、業務継続のための短い移行窓として扱います。新しい旧形式ポリシーを追加したり、適用範囲を広げたりするために使用すると、将来のパッチ適用時に同じ問題が再発します。

Visual Studioの「Enable」とは別の機能

Visual Studioのチェックインポリシー画面には、個々のポリシーを有効化する「Enable」と無効化する「Disable」があります。しかし、これはポリシー評価のオン・オフを切り替える機能です。

Patch 6によるサーバー側の旧形式保存制限を解除するものではありません。Visual Studioで「Enable」を押しても、旧形式の保存禁止は解消されません。(Microsoft Learn)

標準チェックインポリシーを新形式へ移行する手順

BuildやWork Itemsなど、Visual Studio標準のポリシーは、新形式に対応したVisual Studioから同等のポリシーを追加し直します。

対応するVisual Studioへ更新する

Microsoftのリリースノートでは、新形式を扱える最低ビルドとして、次のバージョンが示されています。

製品	リリースノートに記載された対応ビルド
Visual Studio 2022	17.14 Preview 3、17.13.6、17.12.7、17.10.13、17.8.20の各対応ライン以降
Visual Studio 2019	16.11.46以降
Visual Studio 2017	15.9.72以降

実際の作業では、使用中のサポートチャネルで提供されている最新の安定版へ更新するのが安全です。古いVisual Studioから設定すると、新形式ではなく旧形式として保存しようとする可能性があります。(Microsoft Learn)

新形式を追加する

プロジェクト管理者がVisual Studioで次の画面を開きます。

Team Explorer
  > Settings
    > Team Project
      > Source Control
        > Check-in Policy

その後、次の手順で移行します。

一覧にある旧ポリシーと設定値を記録する
「Add」を選択する
同じ種類のうち、名前に「Obsolete」が付いていないポリシーを選ぶ
旧ポリシーと同じパラメーターを設定する
保存する
テスト用の変更を作成し、ポリシーが評価されるか確認する
新形式の動作確認後に旧形式を削除する

Microsoftも、旧ポリシーと同じパラメーターを使い、「Obsolete」と表示されない新しいポリシーを追加する方法を案内しています。(Microsoft Learn)

削除より先に新形式を作る

旧形式を先に削除しないでください。

たとえばWork Item Query Policyを削除した後で、参照していた共有クエリ名や条件が分からなくなると、同じチェックイン制御を再現できません。Buildポリシーでも、参照していたビルド定義が不明になる可能性があります。

移行は次の順番にします。

設定記録
  ↓
新形式の追加
  ↓
違反時・正常時のテスト
  ↓
旧形式の削除

カスタムポリシーについても、Microsoftは既存ポリシーを削除する前に移行を完了するよう注意しています。(Microsoft Learn)

カスタムチェックインポリシーの移行方法

独自開発したチェックインポリシーは、Visual Studio上で追加し直すだけでは移行できない場合があります。

Azure DevOps Serverでは、Microsoft.TeamFoundationServer.ExtendedClientのバージョン19.254で、新しいTFVCポリシークラスとメソッドが追加されています。カスタム実装は、新しい型とJSONベースの保存方式へ更新します。(Microsoft Learn)

主な変更点は次のとおりです。

旧実装	新実装
`PolicyBase`	`CheckinPolicyBase`
`IPolicyCompatibility`	`IPolicyCompatibilityJson`
`BinaryFormatter`中心の保存	`JsonSerializerSettings`を使ったJSON保存
`GetCheckinPoliciesForServerPaths`	`GetCheckinClientPoliciesForServerPaths`
`GetCheckinPolicies`	`GetCheckinClientPolicies`
`SetCheckinPolicies`	`SetCheckinClientPolicies`
暗黙的に保存されていたprivateプロパティ	必要に応じて`[JsonProperty]`を付与

GetBinaryFormatterをオーバーライドしていたポリシーは、GetJsonSerializerSettingsも実装します。TypeNameHandlingにはObjectsを指定し、従来保存していた型情報をJSON側でも復元できるようにします。

Visual Studio 16以前を対象にする拡張機能では、従来BinaryFormatterを上書きしていなかった場合でも、追加のシリアライズバインダー実装が必要になることがあります。(Microsoft Learn)

カスタムポリシーを自動移行する場合

カスタムポリシーでは、次の仕組みを使った移行も用意されています。

旧ポリシーへIPolicyMigrationを実装する
ToNewPolicyTypeで新しいポリシークラスを生成する
旧設定値を新しいインスタンスへコピーする
MigrateFromOldPoliciesを呼び出す

IPolicyMigrationを実装していない旧ポリシーは自動移行時にスキップされ、新形式として保存されません。標準ポリシーとカスタムポリシーでは移行方法が異なる点に注意してください。(Microsoft Learn)

旧ポリシーが表示されずチェックインもできない場合

廃止処理が進んだ環境では、旧ポリシーがTeam Explorerから見えなくなっているのに、サーバー上にはメタデータだけが残り、チェックインがブロックされることがあります。

Microsoftは、この状態から復旧する最終手段として、.NET FrameworkのC#コンソールアプリから次の旧APIを実行し、ポリシーを削除する方法を公開しています。

teamProject.SetCheckinPolicies(null);

この処理は、保存制限を一時的に解除するものではありません。プロジェクトに保存されている旧チェックインポリシーを削除する破壊的な処理です。

実行にはProject Administrator権限が必要で、処理後は新形式のポリシーを改めて追加しなければなりません。実行前に、対象プロジェクト、ポリシー内容、設定値を必ず記録してください。(Microsoft for Developers)

Patch 6の段階で既存ポリシーをまだ読み取れる場合は、最初からこの削除方法を使うのではなく、Visual Studioによる通常の新形式移行を優先します。

TFVCを継続するかGitへ移行するかの判断基準

Patch 6が直接廃止するのは、TFVCそのものではなく旧形式のチェックインポリシーです。そのため、直ちにすべてのTFVCリポジトリをGitへ変更しなければならないわけではありません。

ただし、MicrosoftはTFVCを機能完成済みと位置付け、今後の新規投資はGitを中心に行う方針を示しています。既存TFVCの互換性は維持されるものの、長期計画ではGit移行も検討すべきです。(GitHub)

状況	適した方針
大規模なTFVC運用があり、短期移行が難しい	新形式TFVCポリシーへ先に移行
カスタムポリシーのソースコードを保守できる	新APIへ改修して当面TFVCを継続
カスタムポリシーの保守担当者がいない	パイプラインやGitポリシーへの置き換えを優先
新規開発や小規模なリポジトリ	Gitを第一候補にする
TFVC固有のパス権限や集中管理に強く依存	機能差を調査し、段階移行
PRレビューやCIを中心に品質管理したい	Gitのブランチポリシーへ移行

TFVCポリシーをGit運用へ置き換える例

TFVCのチェックインポリシーとGitのブランチポリシーは、完全な一対一対応ではありません。目的を分解して置き換えます。

現在のTFVCポリシー	短期的な対応	Git移行後の代替例
Build	新形式のBuildポリシー	PRのBuild validation
Work Items	新形式のWork Itemsポリシー	Check for linked work items
Changeset Comments	新形式のChangeset Comments Policy	PRテンプレート、説明文検査、ステータスチェック
Code Analysis	新形式のCode Analysisまたはカスタムポリシー	CIパイプラインの静的解析と品質ゲート
Forbidden Patterns	新形式またはカスタムポリシー	パイプラインスクリプト、PRステータスチェック
Custom Path Policy	新形式のパス制御	ブランチポリシーやビルドのパスフィルター
独自承認ルール	カスタムポリシー改修	必須レビュー、外部ステータスチェック

Azure ReposのGitブランチポリシーでは、PRの必須化、レビュー人数、作業項目のリンク、コメント解決、ビルド検証、外部ステータスチェックなどを組み合わせられます。(Microsoft Learn)

既存プロジェクト内でTFVCとGitを併用できるため、最初に影響の小さいアプリケーションだけGitへ移し、ブランチポリシーとパイプラインを検証する段階移行も可能です。(GitHub)

一時再有効化と移行で避けるべき失敗

Patch 6をすぐアンインストールする

今回の保存制限は意図された変更です。単純にパッチを戻しても、次回以降の更新で再び問題になります。

Azure DevOps Serverのパッチにはセキュリティや不具合修正も含まれるため、ポリシー問題だけを理由にロールバックするのではなく、新形式への移行を優先します。Microsoftも最新かつ安全なバージョンを維持するよう推奨しています。(Microsoft for Developers)

全プロジェクトで旧形式の保存を戻す

一時再有効化はプロジェクト単位で使えるよう設計されています。影響のないプロジェクトまで戻すと、旧形式ポリシーが新たに増える恐れがあります。

古いポリシーを先に削除する

設定値、パス、共有クエリ、ビルド定義が分からなくなり、新形式を再現できなくなる可能性があります。必ず新形式を作成し、検証した後で削除します。

Visual Studioの「Enable」で直そうとする

これはポリシー評価の有効化であり、Patch 6の保存ブロック解除ではありません。

チェックイン時のポリシーオーバーライドで済ませる

個別のチェックインを例外承認しても、旧形式ポリシーの保存方式は変わりません。日常的なオーバーライド運用に切り替えると、品質管理が形骸化します。

データベースを直接更新する

公開されていないテーブルやレジストリ値を推測して変更すると、サポート対象外の状態や将来のアップグレード失敗につながる可能性があります。一時再有効化には、対象ビルド向けの正式な手順だけを使用してください。

管理者が取るべき対応を時系列で整理

直ちに行うこと

Azure DevOps Serverの製品バージョンとパッチを確認する
Patch 6または2022.2 Patch 11の適用状況を確認する
TFVCを使用する全プロジェクトを一覧化する
「Obsolete」と表示されるポリシーを洗い出す
現在の設定値とカスタムDLLを記録する
ポリシー設定の不要な変更を一時停止する

次の保守時間帯で行うこと

Visual Studioを対応バージョンへ更新する
テスト用プロジェクトで新形式を追加する
ポリシー違反時と正常時のチェックインを検証する
標準ポリシーを本番プロジェクトで新形式へ置き換える
カスタムポリシーの改修要否を判断する

保存できず移行を進められない場合

対象プロジェクトだけを特定する
一時再有効化の終了日時を決める
Microsoftから対象ビルド用の正式手順を取得する
必要な期間だけ保存を再有効化する
新形式への移行後、直ちに例外を解除する

移行後に行うこと

旧形式ポリシーが残っていないか再確認する
複数バージョンのVisual Studioで動作を確認する
一時再有効化が解除されていることを確認する
カスタムポリシーのソースと配布手順を保管する
Gitおよびブランチポリシーへの中長期移行計画を作る

Patch 6への正しい対応は「必要な範囲だけ戻し、すぐ移行する」

Azure DevOps Server Patch 6でTFVCチェックインポリシーを保存できなくなるのは、レガシー機能の段階的廃止に伴う仕様変更です。既存ポリシーを読み取れるのは移行猶予であり、旧形式を今後も使い続けられることを保証するものではありません。

まずPatch 6の適用状況と「Obsolete」ポリシーを確認し、対応するVisual Studioから新形式を追加してください。どうしても旧形式の保存が必要な場合だけ、対象プロジェクトを限定して一時再有効化し、その期間内に移行を完了させます。

最終的には、標準ポリシーを新形式へ置き換え、カスタムポリシーを新APIへ改修するか、Gitのブランチポリシーとパイプラインへ役割を移すことが必要です。

この記事を書いた人

佐藤健司

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