Jiraのカスタムフィールド設計実務ガイド：フィールドタイプ・コンテキスト・フィールドスキームで「何を、どこで、必須にするか」を決める

ワークフロー・権限の先に残る、フィールドという土台

当サイトのJira関連記事は、ステータスと遷移（Jiraのワークフロー・課題タイプ設計）、誰が何に触れるか（Jiraの権限・ロール管理実務ガイド）、通知やアサインの自動化（Jiraの自動化ルール実務ガイド）、検索と集計（JQL実務ガイド）、ボードの運用（Jiraのボード運用実務ガイド）、中長期計画（Jiraのロードマップ実務ガイド）、定量レポート（Jiraのレポート実務ガイド）までを扱ってきた。だがこれらの記事はいずれも、作業項目に必要なフィールドがすでに用意されている前提で書かれている。優先度・見積工数・リリース予定日・顧客名といった、標準では用意されていない情報を管理したいとき、どんなフィールドタイプで作り、どのスペースで使えるようにし、どのワークタイプで必須にするかを決めるのがこの記事の主題である。

この記事は、Atlassian公式ドキュメントの仕様から、フィールドを作成できる範囲（サイト全体かスペース限定か）、作成できるフィールドタイプ、同じフィールドに複数の初期値・選択肢を持たせるフィールドコンテキスト、そしてワークタイプごとに必須・非表示を制御する仕組み（旧来はフィールド構成とフィールド構成スキームという2段階の仕組みで、現在は「フィールドスキーム」という単一の設定へ統合が進んでいる）を整理する。あわせて、フィールドを画面のどこに表示するかという画面（スクリーン）の設定までを扱う。ツールそのものの選定は「プロジェクト管理ツール比較」を参照してほしい。

この記事の編集基準

本記事にアフィリエイトリンク・紹介料・掲載料は一切ない。仕様の記述は、Atlassian公式サポートドキュメント（support.atlassian.com）で確認できた範囲に限定している。

フィールドを作れる範囲：サイト全体かスペース限定か

Jiraでカスタムフィールドを作る入口は2つあり、対象のスペースが会社管理かチーム管理かで手順と権限が異なる。

会社管理スペースで使うフィールドは、サイト全体（複数のスペース）で共有できるフィールドとして作成する。手順は、管理パネルで「Work items」を選び、サイドナビゲーションの「Fields」から「Create new field」を選択、フィールドタイプ・名前・説明・オプションを入力して「Create」を選ぶという流れである。この操作にはJira管理者権限が必要になる。

チーム管理スペースのフィールドは、スペース管理者が該当スペースの設定内で追加する。Atlassian公式ドキュメント「Available custom fields for team-managed spaces」は「Fields in team-managed spaces are contained within the space itself」と明記しており、あるチーム管理スペースで作ったフィールドを別のチーム管理スペースや会社管理スペースと共有することはできない。1スペースに作成できるカスタムフィールドは最大50個までという上限もある。

作成できるフィールドタイプ

Atlassian公式ドキュメント「Field types you can create as a Jira admin」は、冒頭で「Once you create a field, you can't change its type」と注意を促している。フィールドタイプは作成後に変更できないため、選択肢式にするか自由記述にするか、数値かテキストかを、最初の作成時点で確定させる必要がある。

このほか、Jiraのワークフロー・課題タイプ設計で扱った親子関係を作る「Parent」フィールドも、フィールドタイプの一つとして用意されている。旧来のEpic linkフィールドの後継として提供されているもので、独自の選択肢を持たない代わりに、対象の作業項目の階層構造を直接参照する。

フィールドコンテキスト：同じフィールドに複数のバリエーションを持たせる

Atlassian公式ドキュメント「What are field contexts?」は、フィールドコンテキストの背景を「Fields in Jira can be used across multiple spaces and work types, but it's rare for a single setup to meet all your needs」と説明している。1つのフィールドを複数のスペース・ワークタイプで使い回したいが、初期値や選択肢まで完全に同じにはできない、という場面で使う仕組みである。

例えば、国ごとに取引先が異なる組織が「取引先」というフィールドを作りたい場合、国の数だけ別々のフィールドを作る代わりに、1つの「取引先」フィールドにコンテキストを複数追加し、コンテキストごとに国別の選択肢を設定できる。異なるコンテキストから入力されたデータも同じフィールドに保存されるため、レポートやダッシュボードでは統一的に集計できる。公式ドキュメントは、フィールド数を減らすことがサイトのパフォーマンス向上にもつながるとしている。

フィールド構成とフィールド構成スキーム、そして統一される「フィールドスキーム」

作成したフィールドを、どのワークタイプで必須にするか、どのワークタイプでは非表示にするかを決める仕組みが、会社管理スペースにはもう一段ある。この部分は現在、Atlassianが仕様そのものを移行させている最中である。

旧来の仕組みは2段階だった。フィールド構成（field configuration）で、ワークタイプ別に「表示するフィールド」「必須にするフィールド」「隠すフィールド」をグループ化し、フィールド構成スキーム（field configuration scheme）で、その構成をどのワークタイプに割り当てるかを決めたうえで、対象のスペースへ関連付ける。スペースが別の構成スキームを使うよう切り替える操作は、対象スペースの設定内の「Fields」から「Actions」→「Use a different scheme」で行う。

Atlassian公式ドキュメント「Create or edit a field scheme」は、この2段階の仕組みを「フィールドスキーム（field schemes）」という単一の設定に置き換える移行が進行中であることを明記している。原文は「replacing field configurations and field configuration schemes with a single, unified setting called field schemes」としている。新方式では、上部ナビゲーションの「Settings」→「Work items」→「Field schemes」から「Create field scheme」を選んで作成し、スキームにフィールドを追加したあと、フィールドごとに「Change field behavior by work type」を開いて、ワークタイプごとの挙動を設定する。設定できる項目は、そのフィールドを表示するワークタイプを選ぶ「Available on」、必須にするワークタイプを選ぶ「Required on」、ワークタイプ別に説明文を上書きする「Replace field descriptions」の3つである。

この移行は段階的に展開されており、公式ドキュメントは「If you can't see Field schemes on your site, that means you're still on the old experience」と説明している。設定画面に「Field schemes」の項目が見当たらない場合は、旧来のフィールド構成・フィールド構成スキームの操作画面がそのまま使われている状態であり、考え方（フィールドをワークタイプ別にグループ化し、必須・非表示を決め、スペースに関連付ける）は新旧で変わらない。

規模の上限についても記載がある。Atlassian公式ドキュメントは、2026年2月から、フィールド構成の上限を700フィールドまで、フィールドスキームの上限を1スキームあたり150ワークタイプまでとすることを明記している。

画面（スクリーン）：フィールドをどの操作でユーザーに見せるか

フィールドスキーム（またはフィールド構成）が「そのワークタイプでこのフィールドが必須か・有効か」を決める一方、実際にユーザーの入力画面にそのフィールドを表示するかどうかは、画面（screen）という別の仕組みが決める。この2つは独立した設定であり、フィールドスキームで必須にしても、画面にそのフィールドを追加していなければ、ユーザーはそもそも入力する場所がない。

Atlassian公式ドキュメント「Create and set up work item screens」によれば、画面へのフィールド追加は、管理パネルで「Work items」→「Screens」を選び、対象の画面の「More actions」から「Configure」を開いて、画面下部の「Select field」ドロップダウンから追加する。フィールドは「Add tab」でグループ化し、タブとして表示することもできる。

画面はさらに2段階の仕組みで、作業項目のどの操作（作成・編集・閲覧）にどの画面を表示するかへとつながる。Atlassian公式ドキュメント「Manage screen schemes」は、画面スキーム（screen scheme）を「screens your team sees when creating, editing, or viewing a work item」を選ぶ仕組みと説明している。画面スキームには既定の画面（デフォルト）があり、作成・編集・閲覧の各操作に個別の画面が割り当てられていない場合は、この既定の画面が使われる。

画面スキームを、ワークタイプ（課題タイプ）ごとに割り当てるのが、ワークタイプ画面スキーム（work type screen scheme）である。Atlassian公式ドキュメント「Manage work type screens」は「A work type screen scheme associates a screen scheme...with work types」と説明しており、「バグ」には既定の画面スキームを、「改善」には別の画面スキームを、といった割り当てができる。特定のワークタイプに個別の割り当てがない場合は、削除できない既定のエントリが使われる（「If there is no specific entry for a work type, the screen scheme associated with the Default entry will be used」）。なお、ストーリーポイントフィールドは例外扱いで、編集画面に追加していなくても常に編集可能な特別なフィールドとして扱われる。

設計の進め方

ここまでを、新しいフィールドを設計する際の順序として並べ直す。

STEP1：既存フィールドで足りないか確認する。会社管理スペースなら「Fields」の一覧、チーム管理スペースなら該当スペースの設定を確認し、似た目的のフィールドがすでにないかを見る。フィールドを増やしすぎると一覧が探しにくくなるだけでなく、上限（会社管理スペースはフィールド構成700フィールド、チーム管理スペースは50個）にも影響する。

STEP2：フィールドタイプを確定する。選択肢式（表記ゆれを防ぎたい）か自由記述か、数値か日付かテキストかを、作成後に型変更できないという制約を踏まえて最初に決める。

STEP3：複数のスペース・ワークタイプで初期値や選択肢を変えたい場合は、フィールドコンテキストを追加する。1つのフィールドで足りるのか、別フィールドとして分けるべきかは、コンテキストで対応できる範囲かどうかで判断する。

STEP4：会社管理スペースでは、どのワークタイプで必須にするか・表示するかを、フィールドスキーム（設定画面に見当たらない場合は旧来のフィールド構成とフィールド構成スキーム）で設定し、対象スペースへ関連付ける。

STEP5：画面にそのフィールドを追加し、画面スキーム・ワークタイプ画面スキームを通じて対象のスペース・ワークタイプに反映されているかを確認する。フィールドスキームで必須にしただけでは入力画面に現れないため、STEP4とSTEP5は必ずセットで確認する。特定のワークタイプだけステータスの遷移条件でフィールドを制御したい場合は、Jiraのワークフロー・課題タイプ設計で扱った遷移の設定を、誰がそのフィールドを編集できるかという範囲はJiraの権限・ロール管理実務ガイドの「Edit work items」権限を、それぞれ別の仕組みとして確認する。カスタムフィールドの値をトリガーや条件に使った自動化は「Jiraの自動化ルール実務ガイド」に譲る。