Azure DevOps の無料組織で「Overview／Dashboards／Wiki／Pipelines しか見えない」「Pipelines に Releases や Task groups がない」という相談がとても多く寄せられます。本記事はその2大トラブルをまとめて解消するための実践ガイドです。管理者が最短で原因を切り分け、確実に復旧できるよう、手順・判断基準・代替策まで具体的に整理しました。
目次
Azure DevOps プロジェクトに Repos／Boards／Test Plans などのタイルが表示されない
症状の具体例
- プロジェクトの左ナビに Overview／Dashboards／Wiki／Pipelines しか表示されない。
- Repos／Boards／Artifacts／Test Plans のタイルが見当たらない。
- 無料組織（Free tier）で新規プロジェクトを作成した直後に発生しやすい。
最初に押さえるポイント
タイルの表示／非表示は「プロジェクトで該当サービスが有効か」「自分のアクセス権が十分か」「ライセンスや試用が有効か」で決まります。プロセス（Basic／Agile／Scrum／CMMI）は主に 作業項目の種類や状態 に影響しますが、UI が簡素化されることで「機能がない」と誤解されることもあります。以下の表を使い、上から順に確認してください。
原因と解決策の早見表
| 主な原因 | 解決策 |
|---|---|
| プロセスが Basic – 画面やワークフローが最小構成で、機能が乏しく見える | Agile／Scrum／CMMI で新規プロジェクトを作成するか、要件を満たす場合は既存プロジェクトの プロセス変更 を検討。 操作例：Project Settings → Overview → Process（プロセス変更は条件あり。影響範囲と互換性を事前確認） |
| 機能が無効化されている – 組織またはプロジェクトで Repos／Boards／Test Plans サービスが OFF | Organization Settings → Projects →（対象プロジェクト） で Boards／Repos／Test Plans を ON。 プロジェクト側の Project Settings → General → Services 等にも同様のトグルがある場合は有効化。 |
| アクセス レベルが Stakeholder – 権限が限定的で、ナビに一部タイルが出ない | Organization Settings → Users で自分の Access level を Basic に変更。 Free tier では 1 組織につき 5 ユーザーまで Basic 無料（状況により変動するため、組織の課金設定で要確認）。 |
| 無料枠の機能制限 – Test Plans などは試用（トライアル）開始が必要 | 課金／ライセンス管理の画面で 「Start free trial」 を実行して有効化。 有効化後にブラウザー再読み込み／再ログイン。 |
一括チェック手順
- Project Settings → Overview でプロセスを確認（必要なら変更）。
- Organization Settings で対象プロジェクトの Boards／Repos／Test Plans を ON。
- Organization Settings → Users で自分を Basic へ（可能なら割当）。
- ブラウザーのシークレットウィンドウで再ログインし、表示を再確認。
画面別の詳しい操作例
Organization Settings でサービスを ON にする
- 右上の歯車アイコンから Organization settings を開く。
- Projects → 対象プロジェクトを選択。
- Settings / Services などのセクションで Boards／Repos／Test Plans／Artifacts を Enabled に切り替え。
ユーザーのアクセス レベルを Basic にする
- Organization settings → Users を開く。
- 自分のアカウントを選択して Access level: Basic を割り当て（可能であれば無料枠を活用）。
- 必要に応じて対象プロジェクトの Project Administrators にも追加。
プロセスの見直し（Basic → Agile/Scrum/CMMI を検討）
- Project Settings → Overview → Process から現在のプロセスを確認。
- レポーティングやステート管理、バックログの精度が必要なら Agile／Scrum／CMMI ベースの新規プロジェクトを作成し、リポジトリやパイプラインを移行するのが安全。
- 既存プロジェクトのプロセス変更は条件や制約があるため、影響（作業項目タイプ・ステート）を十分に検証した上で実施。
無料枠とライセンスの注意点
- Basic 無料枠：組織あたり一定人数まで Basic を無償付与できる場合がある（組織の課金設定を要確認）。
- Test Plans：専用ライセンス（または試用）が必要。Trial を開始するとタイルが表示／利用可能になることがある。
- Artifacts：利用状況によっては課金・クォータが関係する。最初は表示を有効にし、必要に応じて課金設定を見直す。
補足：ブラウザー・キャッシュによる見かけの不具合
- ブラウザーのキャッシュや権限更新の伝搬遅延で、設定直後にタイルが反映されないことがある。
- シークレットウィンドウ／別ブラウザーで再ログインし、組織 URL が正しいか も併せて確認。
Pipelines に「Releases（リリース パイプライン）」と「Task groups（タスク グループ）」が表示されない
症状の具体例
- Pipelines メニューを開いても Releases が見当たらない。
- Pipelines → Library を見ても Task groups が表示されない。
- Classic UI を使っていたチームが、ある日突然作成ボタンを失う／メニューが消える。
原因と解決策の早見表
| 主な原因 | 解決策 |
|---|---|
| Classic Release Pipeline の作成が禁止 設定になっている | Organization Settings → Pipelines → Settings と、Project Settings → Pipelines → Settings の両方で、Disable creation of classic release pipelines を OFF（無効化）にする。 |
| Task groups は Classic 専用 で、YAML では表示されない | 再利用が必要なら Classic パイプライン を有効化して利用するか、機能を YAML テンプレート に置き換える。 |
| タスク制限 によりビルトインタスク／拡張が無効 | Organization Settings → Pipelines → Settings → Task restrictions で、必要なタスクや Marketplace 拡張を有効化（許可）する。 |
| 権限不足（特に Release 管理権限） | ユーザーの Access level を Basic 以上 にし、Project Settings → Security で Release administrators または Project administrators へ追加。 |
設定手順（Releases を再表示）
- 組織側設定を確認：Organization Settings → Pipelines → Settings を開き、Disable creation of classic release pipelines を OFF に。
- プロジェクト側設定も確認：Project Settings → Pipelines → Settings で同じ項目を OFF にする（組織とプロジェクトの両方で有効化が必要な場合がある）。
- ブラウザーを再読み込みし、Pipelines → Releases が表示されるか確認。
設定手順（Task groups を再表示）
- Classic パイプライン有効化：上記の Releases 復活手順と同様。
- Library の確認：Pipelines → Library を開き、左メニューに Task groups が現れるかを確認。
- YAML 移行の検討：長期的には Task group を YAML テンプレートへ移行することで、コードレビューや再利用の一貫性を高められる。
YAML への置き換え戦略
Classic（ビジュアルデザイナー）で「タスクをまとめて再利用」していた場合、YAML では テンプレート で代替します。テンプレートは別ファイル化しておくことで、複数パイプラインから共通呼び出しが可能です。
テンプレート化の基本
- 共通処理を
.azure-pipelines/templates/配下に YAML で分離。 - 呼び出し元で
templateディレクティブを使用し、パラメータで可変部分を渡す。 - テンプレートにも
parametersを定義できるため、Task group の入力引数の代わりになる。
テンプレート例（ビルド & デプロイの共通化）
# .azure-pipelines/templates/deploy.yml
parameters:
environment: 'dev'
serviceConnection: ''
packagePath: 'drop/**/*.zip'
stages:
* stage: Deploy_${{ parameters.environment }}
jobs:
* deployment: DeployWebApp
environment: ${{ parameters.environment }}
strategy:
runOnce:
deploy:
steps:
- task: DownloadPipelineArtifact@2
inputs:
artifact: 'drop'
path: '$(Pipeline.Workspace)'
- task: AzureWebApp@1
inputs:
azureSubscription: ${{ parameters.serviceConnection }}
appType: 'webApp'
appName: 'my-webapp-${{ parameters.environment }}'
package: '$(Pipeline.Workspace)/${{ parameters.packagePath }}' # azure-pipelines.yml（呼び出し例）
trigger:
- main
stages:
- stage: Build
jobs:
- job: Build
steps:
- task: NodeTool@0
inputs:
versionSpec: '18.x'
- script: npm ci && npm run build
- task: PublishPipelineArtifact@1
inputs:
targetPath: 'dist'
artifact: 'drop'
- template: .azure-pipelines/templates/deploy.yml
parameters:
environment: 'dev'
serviceConnection: 'sc-azure-dev'
packagePath: 'drop/**/*.zip'
Task group → YAML 置換パターン
| Task group での意図 | YAML での置換 | ポイント |
|---|---|---|
| ビルド後の共通デプロイ処理 | ステージテンプレート（上記例） | 環境をパラメータ化し、サービス接続を外から注入 |
| 複数プロジェクト横断の共通ラッパー | テンプレートを専用 Git リポジトリで共有 | テンプレートの参照を resources: repositories: で管理 |
| パッケージ名やパスの切替 | parameters による切替 | 入力検証やデフォルト値で安全性を担保 |
タスク制限（Task restrictions）の落とし穴
- セキュリティ強化のために Allow only specific tasks が ON だと、必要タスクが非表示・失敗する。
- マーケットプレース拡張のタスクは別途許可が必要。社内ポリシーで審査／承認フローを整備すると安全。
権限モデルの整理（とくに Release）
| 領域 | 最低限の権限 | 補足 |
|---|---|---|
| リリースの作成・編集 | Release administrators / Release managers | 環境ごとに承認ワークフローがある場合は、環境権限も確認 |
| Pipelines 全般 | Basic 以上 | Stakeholder は機能限定で、UI 上の表示がそもそも出ないことがある |
| サービス接続の利用 | Service connection の使用権限 | 「参照できるが使えない」状態に注意。パーミッションを個別付与 |
運用チームのための「最短復旧フロー」
- 自分の権限を確保：Organization settings → Users で Access level = Basic、プロジェクト管理者に追加。
- サービスの有効化：Organization settings → Projects →（対象） で Boards／Repos／Test Plans を ON。
- ライセンスの有効化：必要に応じて Test Plans の試用を開始。
- Pipelines 設定：Organization と Project の両方で Classic Release の作成禁止を OFF。Task restrictions を見直し。
- 確認：シークレットウィンドウで再ログインし、タイル／メニュー表示を確認。
よくある質問（FAQ）
Q. Basic プロセスでは本当に Boards が使えないの？
Basic は UI とワークフローを最小化したプロセスで、「使える機能が少なく見える」 のが特徴です。要件が増えてきたら Agile／Scrum／CMMI へ移行（もしくはそれらで新規作成）を検討するのが定石です。最優先は「サービスが有効」「アクセス レベルが Basic 以上」になっているかで、ここが揃わないと表示自体が出ないことがあります。
Q. 既存プロジェクトのプロセスは安全に変更できる？
変更には条件・制約があります。チームの運用を止めないためには、新プロセスで 検証用プロジェクト をまず作り、作業項目のマッピング（タイプ／ステート）を確認してから本番適用するのがおすすめです。
Q. Releases を使わずに YAML だけで CD できる？
はい。YAML の マルチステージ（CI + CD） を使えば、Classic Release と同等のフローを構築できます。環境ごとの承認は environments と checks を使って表現し、手動承認やゲートもコード化できます。
Q. Test Plans のタイルが見えないままだけど？
多くの場合は ライセンス（または試用）未有効 が原因です。課金／ユーザー割当の画面で Test Plans を有効化し、再ログイン後に表示を確認してください。
Q. タイルは見えるのに機能が使えない
表示と権限は別です。たとえば Repos が見えても Read 権限がないと参照やクローンができません。プロジェクトの Security でグループ／チーム権限を点検してください。
ケーススタディ：ゼロからの復旧例
背景
- 無料組織で新規にプロジェクト作成。
- 左ナビに Overview／Dashboards／Wiki／Pipelines だけが表示。
- Pipelines 内にも Releases／Task groups は表示されない。
対応
- Users で自分の Access level を Basic に昇格。あわせてプロジェクト管理者に追加。
- Projects 設定 で Boards／Repos／Test Plans を Enabled に切替。
- Billing／ライセンス で Test Plans の試用を開始。
- Pipelines 設定（組織・プロジェクト両方）で Disable creation of classic release pipelines を OFF。
- Task restrictions で必要タスク（たとえば AzureWebApp など）を許可。
結果
- 左ナビに Repos／Boards／Test Plans／Artifacts が表示されるようになった。
- Pipelines に Releases と Task groups が復活。
- 以後は YAML テンプレート化を進め、Classic 依存を段階的に縮小。
ガバナンスとセキュリティのベストプラクティス
- 最小権限：Basic 権限以上は必要最小限のメンバーに。Release やサービス接続の使用権限は役割ベースで付与。
- 監査のしやすさ：Classic の構成は UI 内だけで完結しがち。YAML テンプレートへ移行して Pull Request レビューの対象に。
- 拡張タスクのリスク管理：Marketplace からのタスクはソース／更新履歴／権限要求を確認。Task restrictions を使いホワイトリストで管理。
- スケール戦略：複数チームで同じタスクグループを使っていたら、テンプレート化して共通 Git で配布し、破壊的変更はメジャーバージョン分岐。
- フェーズ移行：Classic をすぐに廃止できない場合は「新規は YAML、既存は順次移行」の二段構えで進める。
トラブル別チェックリスト（保存版）
| 現象 | 見る場所 | 判定／アクション |
|---|---|---|
| Repos／Boards／Test Plans が出ない | Organization settings → Projects →（対象） | 各サービスのトグルを Enabled に |
| Stakeholder しか割り当てられていない | Organization settings → Users | Basic を割当（無料枠があれば活用） |
| Test Plans のタイルが出ない | Billing／ライセンス管理 | 試用（またはライセンス）を開始 |
| Pipelines に Releases がない | Org／Project → Pipelines → Settings | Disable creation of classic release pipelines を OFF |
| Task groups が出ない | Pipelines → Library | Classic を有効化／YAML テンプレートに移行 |
| ビルトインタスクが使えない | Pipelines → Settings → Task restrictions | 当該タスクを許可（Allow） |
| 表示は出たが操作できない | Project settings → Security | Release administrators 等の権限を付与 |
まとめ
- タイル不足は「サービスの有効化」「アクセス レベル」「（必要に応じて）プロセス見直し」「ライセンス有効化」の順に点検すると、短時間で復旧できます。
- Releases／Task groups の非表示は Classic 機能の作成禁止設定やタスク制限、権限不足が主因になりがち。組織とプロジェクトの 両方 の設定を確認しましょう。
- 中長期的には YAML テンプレート化 を進め、共通ロジックをコードとして管理することで、ガバナンス・再現性・拡張性を同時に高められます。
- 無料枠や試用を正しく使うと、追加課金や再インストールなしで必要機能をすぐに有効化できます。
コメント