Azure DevOpsで新規プロジェクトを作成する際、バージョン管理にTFVCを使いたいのに選択肢が表示されないことがあります。多くは組織設定でTFVCリポジトリの作成が禁止されているのが原因です。解除手順と再発防止、TFVC運用の注意点までまとめます。
症状：新規プロジェクトでTFVC（Team Foundation Version Control）が見当たらない
本来、Azure DevOpsのプロジェクト作成時やRepos（Azure Repos）周りの画面で、GitだけでなくTFVC（集中型のバージョン管理）を選べるケースがあります。しかし、次のような状態だと「TFVCを使いたいのに出てこない」問題に遭遇します。
- 新規プロジェクト作成画面で、バージョン管理（Version control）の選択肢がGitのみで、TFVCが表示されない
- Reposでリポジトリを追加しようとしても、TFVCの選択肢が出ない（もしくはTFVC関連の項目が見当たらない）
- 「ポリシー」「プロセス」「プロジェクト設定」を探しても、TFVCを有効化する項目が見つからない
この現象は「あなたの操作ミス」ではなく、組織（Organization）側の設定が原因になっていることが多いです。
原因：組織で「TFVCリポジトリの作成を無効化」する設定が有効になっている
MicrosoftはTFVCをいきなり削除したわけではありませんが、Gitを優先する流れの中で、新規TFVCリポジトリの作成を制御するトグル（切り替え）が導入されています。これにより、組織側で「TFVCを作らせない」設定がONだと、プロジェクト作成画面からTFVCの選択肢が消えたり、作成できなくなります。
ポイントは次の3つです。
- この設定は「新規TFVCリポジトリの作成」にだけ影響し、既存のTFVCリポジトリを壊すものではありません。
- 設定は組織レベルとプロジェクトレベルの両方に存在し、組織設定が優先されます。
- 既定でトグルが有効（＝TFVC作成禁止がON）になる方向で案内されており、今後は無効化できなくなる可能性にも触れられています。
| 状態 | 新規TFVCリポジトリ作成 | 既存TFVCリポジトリ | 新規プロジェクト作成時の表示 |
|---|---|---|---|
| 「Disable creation of TFVC repositories」がON（作成禁止） | できない | 影響なし（利用は継続） | TFVCが表示されない／選べないことがある |
| 「Disable creation of TFVC repositories」がOFF（作成許可） | できる | 影響なし | TFVCが表示され、選べるようになる |
※「既存TFVCに影響しない」「新規作成のみ制御」という点が重要です。必要なタイミングだけOFFにして作成し、作成後に戻す運用も可能です。
解決策：Organization settingsで「Disable creation of TFVC repositories」をオフにする
結論としては、組織設定で「TFVC作成禁止」を解除すると、TFVCの選択肢が復活します。Microsoft Q&Aでも、同様の手順が案内されています。
操作手順（Azure DevOps Servicesの例）
- Azure DevOpsを開き、対象のOrganizationに切り替えます
- Organization settings（組織設定）を開きます
- 左メニューからReposを選びます
- Repositoriesを開きます
- Disable creation of TFVC repositories（TFVCリポジトリの作成を無効化）をオフにします
- 再度、新規プロジェクト作成画面へ進み、バージョン管理の選択肢にTFVCが表示されるか確認します
上記のメニュー名は英語UIの表記です。日本語UIの場合も、項目の配置はほぼ同じで、Repos（リポジトリ）配下に「リポジトリ作成を無効化する」趣旨のトグルが存在します。
作成後に「作成禁止」を戻すべき？
組織ポリシーとして「新規TFVCを増やしたくない」場合は、必要なTFVCリポジトリを作成したあとにトグルをONへ戻す運用が現実的です。トグルは新規作成だけを抑止するもので、既存TFVCを利用できなくするものではありません。
設定が見つからない・変更できないときのチェックポイント
「手順通りに辿れない」「トグルが見当たらない」「オフにできない」場合は、権限や表示条件が原因のことがあります。Azure DevOpsの設定画面は、所属ロールやセキュリティグループにより表示・操作できる範囲が変わります。
| 状況 | よくある原因 | 対処の考え方 |
|---|---|---|
| Organization settings自体が表示されない | 組織管理者ロールを持っていない | Organization Owner / 管理者に依頼して設定変更してもらう（または適切な管理グループへ追加してもらう） |
| Repos > Repositoriesが見当たらない | サービス（Repos）が無効化／UIが変更／権限不足 | まずプロジェクト/組織でReposが有効か確認し、権限が不足していないか確認する |
| トグルをオフにしたのにTFVCが出ない | キャッシュ、別のOrganizationを見ている、プロジェクトレベルで制限が残っている | ブラウザを再読み込み／Organizationを再確認／プロジェクト設定側の制限も確認（ただし組織設定が優先） |
| 将来的にオフにできないのでは？ | ロードマップで無効化不可の可能性に言及 | TFVCが必須な理由を整理し、並行してGitへの移行計画も検討する |
権限面での実務的な判断としては、「プロジェクト管理者」では足りず、組織設定を操作できる管理権限が必要になるケースが多いです。作業が止まる場合は、まず管理者に「ReposのRepositories設定にあるトグルの変更が必要」と伝えるのが最短です。
補足：Gitで作ってしまったプロジェクトにTFVCを追加できる？
「もうGitでプロジェクトを作成してしまった。TFVCに切り替えたい」という相談もよくあります。Azure DevOpsでは、プロジェクト管理者がGitプロジェクトへTFVCリポジトリを追加することが可能とされています（逆も同様）。これにより、ワークアイテムやビルドなどプロジェクト資産を維持しつつ、新しいバージョン管理方式を採用できます。
ただし、追加には注意点があります。
- TFVCはプロジェクトあたり1つのTFVCリポジトリという前提で設計されています。
- TFVCリポジトリは、作成後に削除できない（また、TFVCリポジトリ自体の作成・削除・リネームといった操作には制約がある）ため、命名・設計を慎重に行うべきです。
- プロセステンプレート由来の権限適用の都合で、TFVCのプロジェクトルート（例：
$/ProjectName）に対して、プロジェクト管理者が権限を整備する手順が案内されています。
GitプロジェクトへTFVCを追加する場合に押さえたい権限（目安）
公式ガイドでは、Version Controlの管理画面でプロジェクトルート（例：$/ProjectName）を選び、プロジェクトの既定グループに対する許可を揃える流れが紹介されています。代表的な考え方を表にまとめると次のイメージです（環境・運用ポリシーにより調整してください）。
| 対象グループ（例） | 最低限揃えたい権限の考え方 | 狙い |
|---|---|---|
| [ProjectName]\Readers | Readのみ許可、その他は未設定 | 閲覧者の読み取り権限を明確化 |
| [ProjectName]\Contributors | Check in / Check out / Read など、通常開発に必要な権限を許可 | 開発者が日常的に作業できる状態にする |
| [ProjectName]\Build Administrators | ビルドやラベル付け等に必要な権限を許可 | ビルド運用・自動化を阻害しない |
「何をどこまで許可するか」は組織のガバナンス次第です。まずは“TFVCのルート配下で、Readersは読むだけ、Contributorsは通常作業、Build管理はCI/CDを回す”という原則を置くと整理しやすくなります。
GitとTFVCの違い：どちらを選ぶべきか
Azure DevOpsではGitが新規プロジェクトの既定であり、将来的な投資もGitに寄ることが明言されています。一方でTFVCは「機能が完成しており互換性は維持する」という位置付けです。つまり、TFVCを使う“強い理由”がある場合に選ぶのが現実的です。
| 観点 | Git | TFVC |
|---|---|---|
| モデル | 分散型。手元でコミットし、後でpushできる | 集中型。履歴の主な管理はサーバー側 |
| オフライン作業 | 強い（履歴・差分など多くの操作がローカルで可能） | ワークスペース方式により異なる（サーバーワークスペースは接続前提が多い） |
| ブランチ運用 | 軽量で頻繁なブランチ作成に向く | パスベースのブランチ。サーバー上で作成する設計 |
| ロック運用 | 基本はロックに頼らずマージで解決 | ロックを前提にした運用が取りやすい |
| 大規模・バイナリ | 大容量はGit LFS等の設計が必要 | 非常に大きいコードベースや大きなバイナリを扱う運用に言及あり |
| 将来性 | 新規投資の中心 | 機能は完成（feature complete）で互換性は維持、ただし新規作成は段階的に抑制 |
上の表は、公式の比較・説明に基づく要点を噛み砕いたものです。特に「Gitが既定」「TFVCは互換性維持だが今後の投資はGit」という点は、意思決定に大きく影響します。
それでもTFVCを選ぶ“強い理由”になりやすいケース
- ファイルのロック運用が必須（設計・DCCツール・特定のバイナリ資産など、同時編集の衝突が許されない）
- 非常に巨大なコードベースで、集中型の管理や特定のワークスペースモデルが都合が良い
- 既存の社内ルール（チェックインポリシー、フォルダ単位の権限、運用フロー）がTFVC前提で固まっている
TFVCにはサーバーワークスペース／ローカルワークスペースのモデルがあり、運用上の設計がGitと大きく異なります。TFVC前提のルールがある組織は「なぜTFVCなのか」を言語化しておくと、組織設定の変更依頼も通りやすくなります。
TFVC運用の注意点：プロジェクト作成前に知っておくと事故が減る
TFVCリポジトリは「後から消せない」前提で設計する
TFVCはGitと違って、複数リポジトリを気軽に増やしたり、作ったものを整理目的で削除したりしづらい設計です。作成後に削除できない前提で、プロジェクト名・ルートパス・フォルダ構成を最初に固めることが重要です。
パイプライン面：TFVCはYAMLではなくClassicが前提
CI/CDの設計で見落としやすいのがここです。Azure Pipelinesでは、TFVCはClassic pipelinesのみサポートで、YAMLはサポートされません。最初からYAML運用を前提にしているチームは、TFVCを選ぶと運用設計が破綻する可能性があります。
Gated check-in運用でエラーが出たときの観点
TFVCでgated check-in（棚卸し＝shelvesetを作ってビルドし、問題なければチェックイン）を使う場合、エラーの原因が「コード」ではなく設定（権限スコープ）であることがあります。たとえば shelveset が見つからない系のエラーでは、ジョブの認可スコープ設定（プロジェクトに限定する設定）が影響する可能性が示されています。組織設定またはプロジェクト設定のPipelinesタブ側の設定も合わせて確認すると切り分けが早くなります。
よくある質問
「Disable creation of TFVC repositories」をオフにすると、既存の運用に影響はある？
影響するのは「新規TFVCリポジトリの作成可否」です。既存のTFVCが突然使えなくなるものではない、という説明がされています。
組織設定とプロジェクト設定、どっちを直せばいい？
このトグルは組織レベルとプロジェクトレベルの両方にあり、組織設定が優先されます。まずは組織側を確認するのが近道です。
今後もTFVCを新規で使い続けられる？
TFVC自体を直ちに削除するとはされていない一方で、新規プロジェクト・新規組織に対して段階的に抑制する方針や、将来的にトグルを無効化できなくなる可能性にも触れられています。TFVCが必須な場合でも、並行してGit移行の選択肢を持っておくのが安全です。
まとめ：TFVCが選べないときは「組織設定の作成禁止」を疑う
Azure DevOpsで新規プロジェクト作成時にTFVCが表示されない場合、原因の多くは組織設定でTFVCリポジトリ作成が無効化されていることです。Organization settings > Repos > Repositories にあるDisable creation of TFVC repositoriesをオフにすることで、TFVCが選べる状態に戻ります。
ただし、TFVCは作成後に削除できないなど運用上の癖があり、パイプラインもYAMLではなくClassic前提です。単に「出てこないから有効化する」ではなく、組織の開発標準やCI/CD方針まで踏まえて判断すると、後戻りコストを抑えられます。
コメント