Azure DevOpsでタスクに親子リンク（Parent/Child）を追加すると、追加した瞬間は何も起きないのに、保存ボタンを押したタイミングでだけエラーが出ることがあります。これは操作ミスというより、Web画面の検証タイミングと親子リンクの仕様が噛み合った結果です。ここでは原因の切り分け方と、すぐに直す手順、再発防止の運用までまとめます。
起きている現象を整理する（リンク追加は通るのに保存で弾かれる）
Azure DevOps（Scrumプロセス）でよく使われる「プロダクトバックログアイテム（PBI）」と「タスク（Task）」の組み合わせでは、通常は PBI →（子）Task という階層が基本です。一方でチーム運用として「PBIがTaskの子になる（逆転する）」のを禁止している場合、誤って不正な親子関係を作ろうとしたときにエラーが発生します。
問題は、リンクを追加した時点ではエラーが表示されず、保存した瞬間にだけエラーが出ることです。体感としては「その場で止めてほしい」のですが、Azure DevOpsのWeb UIはこの動きになりやすい設計です。
| 操作 | 画面上の見え方 | 実際に起きていること |
|---|---|---|
| 親子リンクを追加 | リンクが一覧に追加され、エラーは出ない | フォーム上に「変更案」が乗るだけで、サーバー側の整合性検証は未確定 |
| 保存ボタンを押す | ここで初めてエラーが表示される | サーバーに変更が送られ、親子関係・循環・親の数などがまとめて検証される |
結論：エラーが「保存時」にしか出ない最大の理由
Azure DevOpsのWeb画面で作業項目（Work Item）を編集している間、画面上の変更は一時的に保持されます。リンク追加も同様で、リンク追加＝即サーバー確定ではありません。保存のタイミングで、フィールド変更・リンク追加/削除・状態遷移などがまとめてサーバーへ送られ、そこで初めて整合性チェックが実行されます。
リンク追加時点でリアルタイム検証をしない（できない）理由は主に次のとおりです。
- 検証にサーバー問い合わせが必要なケースが多い（リンク先の種類、既存の親の有無、循環参照の有無、権限など）
- 編集途中は「まだ確定していない変更」が複数あり、途中段階だけ見ても最終形が確定しない
- 毎回厳密チェックをすると、リンク検索や入力のたびに通信が増え、体感速度が落ちる
- 複数タブ/複数人編集などで、保存時点で状況が変わることがある（＝最終判断は保存時が一番正確）
その結果、リンク追加時は「いったん置ける」ように見えても、保存時のサーバー検証で「その親子関係は許可されない」「親は1つだけ」などのエラーになり得ます。これは不具合というより、検証を保存時に寄せている仕様として捉えるのが現実的です。
Azure DevOpsの親子リンクで押さえるべき基本仕様
「親子リンク（Hierarchy）」は、ただの関連付けではなく階層構造（ツリー）を作るためのリンクです。そのため、関連リンクよりも制約が強く、保存時に厳しく検証されます。
親子リンクの代表的なルール
- 1つの作業項目が持てる「親（Parent）」は原則1つ（階層ツリーとして整合させるため）
- 「子（Child）」は複数持てる
- 循環参照（AがBの親で、BがAの親…など）は不可
- 親子関係として想定されない作業項目タイプの組み合わせは、プロセス設定やバックログ構造によって拒否されることがある
リンク種類による性質の違い
同じ「リンク」でも種類によって意味が違います。親子リンクで詰まる場合、そもそも親子リンクを使うべきか、関連リンクで十分かを見直すと解決が早いことがあります。
| リンクの種類 | 目的 | 制約 | よく使う場面 |
|---|---|---|---|
| 親子（Hierarchy：Parent/Child） | 階層（上位→下位）を作る | 親は原則1つ、循環不可、組み合わせ制限が出やすい | Epic→Feature→PBI（User Story）→Task など |
| 関連（Related） | 作業同士の関係性を示す | 比較的自由（複数可）、階層にはならない | 依存関係、参考情報、横断的な関連 |
| 重複（Duplicate） | 同じ内容の重複を示す | 運用ルール次第 | 同一課題の統合、誤登録の整理 |
保存時エラーで特に多い原因パターン
「保存したらエラー」の裏側には、だいたい典型パターンがあります。まずはどれに当てはまるかを切り分けると、対処が速いです。
| よくある原因 | 起こりがちな状況 | 確認ポイント | 対処の方向性 |
|---|---|---|---|
| 親がすでに存在する（親が2つになる） | 既存の親がある作業項目に、さらに「親」を追加 | リンク一覧に既存の「親」リンクが残っていないか | 既存の親を外してから新しい親を設定 |
| 許可されない作業項目タイプの親子 | Taskの下にPBIを入れるなど、バックログ階層を逆転 | 「親」「子」の向きと、親/子それぞれのWork Item Type | 正しい階層（PBI→Task）に戻す。必要ならRelatedで代替 |
| 循環参照（ループ） | 親の親を辿ると自分に戻るようなリンクを作った | リンクを上位へ辿って同じIDが出てこないか | どこかの親子リンクを外してツリーを崩す |
| 権限・アクセスの問題 | リンク先のプロジェクト/エリアに編集権限がない | リンク先が見える/編集できるか、権限設定 | 権限付与 or リンク先を変更 |
| 同時編集で状態が変わった | 開いている間に別ユーザーが親子関係を変更 | 履歴（History）や更新時刻 | 再読み込みして最新状態で再度リンク設定 |
すぐ直す：親子リンクの付け替え手順（標準UIだけ）
保存時エラーの解消は、原因が「親が2つになる」か「親子の向き/タイプが不正」かで手順が変わります。ここでは標準UIだけでできる、最も確実な手順をまとめます。
手順A：既存の親を外してから、新しい親を設定する
- 対象の作業項目（例：タスク）を開きます。
- 上部の「リンク」または「関連作業（Links）」のセクションを開き、現在のリンク一覧を確認します。
- 「親（Parent）」がすでに設定されている場合は、不要な親リンクを削除します（ゴミ箱アイコンなど）。
- あらためて「リンクの追加」から「親（Parent）」を選び、正しい親（通常はPBI）を指定します。
- 保存し、エラーが消えるか確認します。
ポイント：「親を変えたい」のに、先に新しい親を追加してしまうと「親が複数」扱いになって保存で弾かれます。親の付け替えは、削除→追加の順番が安全です。
手順B：そもそも親子リンクにすべきでない場合、Relatedに切り替える
「上位下位ではなく、関連があるだけ」「参照したいだけ」「依存関係を残したいだけ」なら、親子リンクにこだわらずRelatedを使う方が運用が安定します。
- リンク追加で「関連（Related）」を選択
- リンク先ID/検索で対象作業項目を指定
- 保存
親子リンクはバックログ階層・スプリント計画・進捗集計に影響するため、階層にしたい意図が明確なときだけ使うのがおすすめです。
再発防止：タスク作成の入口を変えるとミスが減る
「リンク追加で親を探して付ける」運用は、どうしても付け間違いが起きます。標準機能だけでも、作成の入口を変えるだけで誤リンクが激減します。
PBI側からタスクを作成する（親が自動で正しく付く）
- スプリントバックログやバックログ画面で、PBIの配下に「タスクを追加」する
- またはPBIを開いて、関連作業から子としてタスクを追加する
この方法だと、最初から「PBI→Task」の形で作られるため、逆転（Task→PBI）や付け替えミスが起きにくくなります。
「親を探して紐づける」前に確認したいチェックリスト
- リンクを追加する向きは本当に「親（Parent）」か（「子（Child）」を追加していないか）
- リンク先のWork Item Typeは何か（Task / Product Backlog Item / Bug など）
- すでに親が設定されていないか（特に既存アイテムの付け替え時）
- 親にしたいのは「階層」か「関連」か（Relatedで十分ではないか）
チーム独自ルールを守るための現実的な運用（標準機能のみ）
「PBIがTaskの子になるのは禁止」のようなチームルールは、標準UIだけだと入力中の即時警告が難しい場面があります。そこでおすすめなのが、違反を“作らせない”工夫と、作られてしまった違反を“早く見つける”仕組みの両輪です。
違反を早く見つける：リンククエリで「逆転階層」を検出する
Azure DevOpsのクエリには、親子リンクを辿れる「Work items and direct links（作業項目と直接リンク）」の種類があります。これを使うと、例えば次のような違反を一覧化できます。
- 「子」がPBIで、「親」がTaskになっているもの（階層逆転）
- Taskの親がPBI以外になっているもの（運用上の例外を潰す）
作り方の例（概念）：
- Boards > Queries（クエリ）で新規クエリを作成
- クエリタイプを「作業項目と直接リンク」に変更
- 上側（親）に「Work Item Type = Task」
- リンク種類を「親子（Hierarchy）」に指定
- 下側（子）に「Work Item Type = Product Backlog Item」
- 必要に応じて Area Path / Iteration Path / State などで絞り込み
- 保存して、結果をチームで共有
このクエリをダッシュボードにピン留めしておくと、ルール違反が発生した瞬間に目につきやすくなります。特に、複数チームで同じプロジェクトを触っている場合は効果が大きいです。
違反を作らせない：ルールの「見える化」を先に行う
標準UIが即時警告してくれないなら、チーム側で誤操作を起こしにくい導線を作るのが有効です。
- 運用ガイドに「PBI→Taskが基本。Task→PBIは作らない」を図で掲載する
- スプリント計画の手順を「PBI配下にタスク追加」に統一する
- 親子リンクの用途（階層）とRelatedの用途（関連）を使い分けルールとして定義する
- 違反検出クエリを週次で確認し、違反があればその場で修正する
それでも「入力時に止めたい」場合の選択肢（必要なときだけ）
「保存時に弾かれるのは分かったが、運用としては入力時に止めたい」という場合、標準機能だけでの限界はあります。強く抑止したいときは、次の方向性が現実的です。
| 方向性 | 期待できること | 注意点 |
|---|---|---|
| プロセス設計の見直し | バックログ階層とWork Item Typeを整理し、誤運用の余地を減らす | リンクの入力中チェックそのものが増えるわけではない |
| Marketplace拡張 | ルール違反の検知・警告を強化できる可能性 | 導入審査・運用コストが増える |
| Service Hooks / 外部自動化 | 違反が作られた瞬間に通知、差し戻しフローなどが作れる | 実装・保守が必要（チーム規模次第） |
ただし、いきなり拡張や自動化に寄せるより、まずは「PBI側からタスクを作る」「違反クエリで見える化する」だけでも、現場のストレスと修正コストは大きく下がります。
よくある質問（保存時エラーのモヤモヤを解消）
リンク追加時にエラーが出ないのは不具合では？
多くのケースでは不具合というより、保存時にサーバー側で整合性を確定する設計によるものです。リンク追加の瞬間に完全な検証を行うにはサーバー問い合わせが必要になり、操作感が悪化しやすいため、最終確定の保存時に寄せています。
「親は1つだけ」のエラーが出たら、どこを見ればいい？
まずはリンク一覧に既存の「親（Parent）」が残っていないか確認してください。付け替えのつもりで新しい親を追加すると、保存で弾かれます。削除→追加の順番で行うと安定します。
PBIがTaskの子になってしまうと何が困る？
バックログの階層（上位→下位）が崩れると、スプリント計画、進捗の集計、ボード表示、チームの作業分解の粒度が乱れやすくなります。特に「Taskの下にPBIがある」状態は、作業分解の意図が読み取りにくく、レビュー時の認識齟齬につながりがちです。
親子リンクを外すと履歴やトレーサビリティは消える？
親子関係そのものは外れますが、作業項目の履歴（History）には変更として残ります。階層として追いたい意図があるなら親子リンク、単なる関係性や参照ならRelatedに寄せるなど、目的に合わせると整理しやすくなります。
まとめ（原因・対処・運用を一本化）
Azure DevOpsで親子リンクを追加した際、リンク追加時には何も起きず、保存時にだけエラーが出るのは、Web UIが編集途中の段階で厳密な階層検証をせず、保存時にサーバーでまとめて整合性を確認するためです。対処としては、既存の親リンクがある場合は外してから付け替える、親子の向きやWork Item Typeの組み合わせを正しい階層（通常はPBI→Task）に戻す、必要ならRelatedで代替するのが確実です。再発防止には、PBI側からタスクを作成する導線の統一と、違反検出クエリのダッシュボード化が特に効果的です。
コメント