Backlogのカスタム属性設計実務ガイド：フィールドタイプ・必須設定・適用する種別で「何を、どこまで必須にするか」を決める

課題管理・権限・連携の先に残る、「何の情報を持たせるか」という論点

「Backlogの課題管理実務ガイド」では、種別・優先度・状態という必須3項目と、カテゴリー・マイルストーンという分類軸を扱った。「Backlogの権限・ユーザー管理実務ガイド」では誰が課題に触れられるかを扱った。だがいずれの記事も、課題に入力できる項目はBacklogが標準で用意しているものに限られる前提で書かれている。顧客名・対応環境・リリース予定バージョン・チェック日といった、標準項目にない情報を課題ごとに管理したいとき、どの形式で作り、必須にするかどうか、どの種別の課題に適用するかを決めるのが、この記事の主題である「カスタム属性」である。

この記事は、Backlog公式ヘルプセンター（Enterpriseユーザーガイド）とBacklog Developer API公式ドキュメントの一次情報にもとづいて、カスタム属性の形式・必須設定・適用範囲・検索への反映・登録数の上限を整理する。同じ論点をJiraで扱った記事が「Jiraのカスタムフィールド設計実務ガイド」であり、2つのツールで設計の発想がどう違うかも随所で対比する。ツールそのものの選定は「プロジェクト管理ツール比較」を参照してほしい。

この記事の編集基準

本記事にアフィリエイトリンク・紹介料・掲載料は一切ない。仕様の記述は、Backlog Enterpriseユーザーガイド（backlog.com/ja/enterprise-help）、Backlogヘルプセンター（help-center.backlog.com）、Backlog公式サイトの料金ページ（backlog.com/ja/pricing）、Backlog Developer API公式ドキュメント（developer.nulab.com/docs/backlog）で確認できた範囲に限定している。

カスタム属性とは何か、どのプランで使えるか

Backlog Enterpriseユーザーガイド「カスタム属性の概要」は、カスタム属性を「課題に対して独自に定義できるデータ」と説明しており、プロジェクトごとに複数のカスタム属性を自由に作成でき、登録した属性は課題検索の条件としても使えるとしている。設定の単位はプロジェクトであり、あるプロジェクトで作ったカスタム属性は、作成元のプロジェクトに閉じる。

利用できるプランには条件がある。Backlog公式サイトの料金ページは、スターター・スタンダードプランではカスタム属性（属性のカスタマイズ）に対応せず、プレミアムプラン以上で使えると明記している。Backlogヘルプセンターの「プランをダウングレードすると、いま使用しているカスタム属性はどうなりますか？」は、プレミアムプラン・プラチナプランのみカスタム属性を利用できるとしたうえで、下位プランへダウングレードした場合の挙動を「カスタム属性はBacklogのデータベース上には保存されたままですが、画面には表示されなくなります」と説明している。既存データが消えるわけではないが、画面上は使えなくなる。

出典：Backlog公式サイト「料金プラン」、Backlogヘルプセンター「プランをダウングレードすると、いま使用しているカスタム属性はどうなりますか？」（いずれも2026年10月2日確認）。

課題管理の運用にカスタム属性を組み込む設計は、プラン選定の段階から織り込む必要がある。「Backlogの課題管理実務ガイド」で扱ったガントチャートがスタンダードプラン以上を要求するのに対し、カスタム属性はさらに一段上のプレミアムプラン以上が条件になる。

作成できる形式：ヘルプセンターの5分類とAPIの8タイプ

Backlog Enterpriseユーザーガイド「カスタム属性の形式」は、カスタム属性の形式を文字列・文章・数値・選択リスト・日付の5つとして説明している。文字列は「課題の件名のように一行で自由な文字入力ができる属性」、文章は「課題のコメントのように複数行の文章を入力することができる属性」で、いずれもキーワード検索の対象になる。数値と日付は、検索時に範囲指定ができる。選択リストは、あらかじめ用意した選択肢から値を選ぶ形式である。この5分類について、同ページは「属性の形式は保存した後は変更出来ません」と明記している。

Backlog Developer APIの「Add Custom Field」（カスタム属性の追加）は、同じ形式をtypeIdという数値で8段階に分けて定義している。

出典：Backlog Developer API「Add Custom Field」（2026年10月2日確認）。

ヘルプセンターが「選択リスト」とまとめている区分を、APIは単一選択・複数選択・チェックボックス・ラジオボタンの4typeIdに分けている。選択肢形式のカスタム属性を作る際は、単一選択か複数選択かを、画面の選択肢表示だけでなく、この区分を踏まえて決める必要がある。なお「保存した後は変更出来ません」という制約は、Update Custom Field APIの更新可能パラメータにtypeIdが含まれていないことからも裏付けられる。形式を間違えたカスタム属性は、作り直すほかない。

必須設定と適用する種別：課題情報の粒度をそろえる2つのパラメータ

Backlog Developer APIの「Add Custom Field」は、形式（typeId）・名前（name）のほかに、requiredとapplicableIssueTypesという2つのパラメータを持つ。

requiredは真偽値で、APIドキュメントは「True to make the Custom field required」と説明している。trueに設定すると、そのカスタム属性は課題の登録・編集時に入力必須になる。

applicableIssueTypesは、このカスタム属性を適用する種別（課題タイプ）のIDを配列で指定するパラメータで、APIドキュメントは「Type ID to enable Custom fields empty=enable for all issue types」と説明している。空のままにすると全ての種別に適用され、特定の種別IDを指定すると、その種別の課題にだけカスタム属性が表示される。

この2つを組み合わせると、「バグ」種別の課題だけに「発生環境」を必須属性として追加し、「タスク」種別には表示しない、といった設計ができる。「Backlogの課題管理実務ガイド」で扱った種別・カテゴリー・マイルストーンという3つの分類軸に、カスタム属性のrequired・applicableIssueTypesを重ねることで、種別ごとに「何を、どこまで必須入力させるか」という情報の粒度をそろえられる。

形式ごとに追加で決める項目：数値・日付・リストの初期値設計

数値・日付・リスト型のカスタム属性には、共通のname・required・applicableIssueTypesに加えて、形式ごとの追加パラメータがある。Backlog Developer APIの「Add Custom Field」から、形式別に整理する。

出典：Backlog Developer API「Add Custom Field」（2026年10月2日確認）。

日付型の初期値を「当日」にするか「当日から何日後」にするかは、見落とされやすい設計点である。例えば「対応期限」というカスタム属性を作り、initialValueTypeを2・initialShiftを7に設定すれば、課題を新規作成した時点で「当日から7日後」が自動的に入力された状態になる。入力の手間を減らしたい属性では、この初期値設計を先に検討する価値がある。

作成手順：プロジェクト設定から1つずつ作る、または他プロジェクトからコピーする

Backlog Enterpriseユーザーガイド「カスタム属性の設定方法」は、作成手順を次のように説明している。プロジェクトの設定にある「カスタム属性の編集」リンクから、そのプロジェクトに設定されているカスタム属性の一覧画面に進み、「カスタム属性の追加」で必要事項を登録して登録ボタンを押すと作成される。作成後は、課題の追加画面・編集画面でその属性が入力できるようになる。

同じ構成のカスタム属性を複数プロジェクトで使いたい場合は、1つずつ作り直す必要はない。カスタム属性の一覧ページから「他のプロジェクトから属性をコピー」を選ぶと、他のプロジェクトで定義済みのカスタム属性を現在のプロジェクトに複製できる。複数プロジェクトで同じ管理項目を使う組織では、ひな形になるプロジェクトを1つ決めてカスタム属性を整備し、新規プロジェクトの立ち上げ時にこの機能でコピーする運用が、属性の表記ゆれを防ぐ。

検索にどう効くか：高度な検索「その他」タブとキーワード検索の対象範囲

Backlog Enterpriseユーザーガイド「カスタム属性による検索」は、カスタム属性を定義したプロジェクトでは、課題検索の「高度な検索」から「その他」タブを指定することで、カスタム属性を条件にした検索ができるとしている。

検索への乗り方は形式によって差がある。同ページは「文字列、文章のカスタム属性についてはキーワード検索でも検索対象となります」としており、文字列・文章型は、高度な検索を開かなくても通常のキーワード検索に引っかかる。一方、数値・選択リスト・日付型はキーワード検索の対象にならず、高度な検索の「その他」タブからの絞り込みが必要になる。検索で頻繁に絞り込みたい情報を文字列・文章型で持たせるか、数値・選択リスト・日付型で持たせるかは、この違いを踏まえて決めたほうがよい。

登録数の上限

Backlogヘルプセンターの「プロジェクトに追加できる課題数・課題の属性数の上限はありますか？」は、カスタム属性の登録数上限を100個としている。プロジェクトが育つにつれて属性を継ぎ足していくと、この上限に近づく。属性を新設する前に、「Backlogの課題管理実務ガイド」で扱った種別・カテゴリー・マイルストーンという既存の分類軸で足りないかを確認し、似た目的のカスタム属性が既にないかを一覧で見る習慣が、上限への到達を遅らせる。

設計の進め方

ここまでを、新しいカスタム属性を設計する際の順序として並べ直す。

1. 既存項目で足りないか確認する - 種別・優先度・状態の標準項目、カテゴリー・マイルストーンの分類軸（いずれも「Backlogの課題管理実務ガイド」参照）で代替できないかを先に見る。カスタム属性の登録数上限は100個であり、増やしすぎない判断が必要になる。

2. プランを確認する - カスタム属性はプレミアムプラン以上の機能である。スターター・スタンダードプランで運用している場合は、プラン変更の要否を先に関係者と確認する。

3. 形式（typeId）を確定する - 文字列・文章・数値・日付・選択リスト（単一／複数）・チェックボックス・ラジオボタンのいずれにするかを、保存後に変更できないという制約を踏まえて決める。検索で頻繁に絞り込みたい情報かどうかも、ここで考慮する（文字列・文章型はキーワード検索の対象になる）。

4. 必須設定と適用する種別を決める - requiredで入力必須にするか、applicableIssueTypesでどの種別の課題にだけ表示するかを決める。全種別に必須属性を増やしすぎると、関係のない種別の課題でも入力を強制することになる。

5. 数値・日付・リスト型は初期値を設計する - 数値ならmin/max/initialValue/unit、日付ならinitialValueTypeによる当日起点の自動入力、リストならallowInput（自由記述の許可）とallowAddItem（選択肢の追加許可）を、入力の手間と表記ゆれ防止のバランスで決める。

6. 複数プロジェクトで使うなら、ひな形プロジェクトからコピーする - 「他のプロジェクトから属性をコピー」機能で複製し、プロジェクトごとに作り直す手間と表記ゆれを避ける。

まとめ

Backlogのカスタム属性は、Jiraのカスタムフィールドのような「フィールド構成」「フィールドスキーム」「画面」という複数層の仕組みを持たない代わりに、1つの属性定義にrequired（必須設定）とapplicableIssueTypes（適用する種別）という2つのパラメータを持たせることで、同じ問いに答えている。「Backlogの課題管理実務ガイド」で設計した種別・カテゴリー・マイルストーンという分類軸と、「Backlogの権限・ユーザー管理実務ガイド」で設計した誰が触れるかという権限設計に、このカスタム属性の設計を重ねることで、課題情報の粒度と入力の必須度を、プロジェクトの実態に合わせてそろえられる。