Linear migration metadata¶

• Linear issue: TAK-262
• Linear URL: https://linear.app/takayuki-komoda/issue/TAK-262/core-gui-項目設定と一覧表示設定をシンプル化する
• Linear status: Backlog
• Linear team: Takayuki Komoda
• Linear project: EPAA Core
• Linear assignee:
• Linear labels:
• Linear created: 2026-09-06T10:55:47.750Z
• Linear updated: 2026-09-16T21:31:18.531Z
• Linear archived:

---

Original description¶

背景¶

Core GUI の 項目 タブでは、各項目に フォーム順、詳細順、一覧順 が表示されている。

さらに左端の上下矢印は フォーム順を上へ / フォーム順を下へ として formOrder だけを入れ替える実装になっているが、画面上の列名は 移動 であり、詳細順や一覧順も動くように誤解しやすい。

通常の生成アプリでは、登録・更新フォームと詳細画面の項目順は同じでよい。分ける必要があるケースは詳細モード向けであり、簡単モードで フォーム順 と 詳細順 を別々に見せると利用者の理解負荷が高い。

要件¶

• Core GUI の簡単モードでは、フォーム順 と 詳細順 を統一した 表示順 として扱う。
• 表示順 の変更は、登録画面・更新画面・詳細画面の順序に同じ値として反映する。
• 左端の上下矢印は、簡単モードでは 表示順 を入れ替える操作として分かる表示にする。
• 一覧順 は一覧テーブルの列順であり、入力/詳細の表示順とは別物として扱う。
• 詳細モードで フォーム順 と 詳細順 を分けて残す場合は、その用途差が分かるUI文言にする。

受入条件¶

• 簡単モードで、利用者が フォーム順 と 詳細順 の違いを判断しなくてよい。
• 簡単モードの上下矢印で並び替えた場合、登録・更新・詳細の項目順が同じ順序になる。
• 一覧テーブルの列順は 一覧順 として別に調整できる。
• 既存 metadata の form_order / detail_order との互換方針が設計に明記されている。
• 既存アプリで form_order と detail_order が異なる場合に、簡単モードでどう表示・保存するかが明確である。
• YAML直接編集だけでしか扱えない設定を正式仕様にしない。

注意事項¶

• この issue は Core GUI の項目設定UI整理を対象とする。
• 生成アプリ側の画面レイアウト全体再設計は対象外。
• 一覧順 の廃止は対象外。入力/詳細順と一覧列順は別物として維持する。
• TAK-246 の画面棚卸および簡単モード/詳細モード整理の一部として扱う。

追加要件¶

• 一覧順 は一覧画面の列順であり、項目 タブの項目一覧には表示しない。
• 一覧の列順・列幅・ソート可否・表示形式は 一覧表示 タブに集約する。
• 項目 タブでは、入力フォーム・詳細表示・登録/更新可否など、項目そのものの基本設定に絞る。

追加受入条件¶

• 簡単モードの 項目 タブに 一覧順 が表示されない。
• 一覧の並び順を変更したい場合は 一覧表示 タブから操作できる。
• 項目 タブと 一覧表示 タブで、同じ一覧列順を二重管理しているように見えない。

追加方針: 項目定義と一覧表示定義の分離¶

• 項目定義と一覧表示定義は完全に分けて考える。
• 項目 タブは、データ項目そのものの定義に絞る。
  • 例: 項目名、日本語名、データ型、入力UI、必須、編集可否、登録/更新/詳細で使うか。
• 一覧表示 タブは、一覧画面に出す列の定義に絞る。
  • 例: 表示項目、列順、列幅、ソート可否、表示形式。
• list_visible は基本UIから外し、正式な一覧列定義は list_columns に一本化する。
• 既存の list_visible / list_column_order は、互換または list_columns 未作成時の初期生成候補として扱うか、廃止・移行する方針を設計で決める。

追加受入条件¶

• 簡単モードの 項目 タブに、一覧表示に出す/出さない設定が表示されない。
• 一覧列の追加・削除・順序変更・幅・ソート可否は 一覧表示 タブだけで操作できる。
• 項目 タブの保存によって、既存 list_columns が意図せず増減しない。
• 一覧表示 タブの保存によって、項目定義側の基本属性が意図せず変更されない。
• 既存 metadata で list_columns がない場合に、list_visible から初期列を作るかどうかの移行ルールが明記されている。

確定方針: ハイブリッドUI¶

ユーザー合意済みの方針として、項目設定と一覧表示設定は責務を分けつつ、項目追加時の一覧反映が面倒にならないUIにする。

• YAML の正本は list_columns に一本化する。
• fields.<name>.list_visible / list_column_order は新規UIの主要設定として扱わない。
• 項目 タブには詳細な一覧設定を置かない。
• ただし 項目 タブには 一覧に表示 チェックだけを置く。
• 項目 タブの 一覧に表示 チェックは、list_visible ではなく list_columns への追加/削除ショートカットとして動作させる。
• 新規項目追加時は、条件に合う項目を自動で list_columns に追加する。
• 一覧表示 タブでは、一覧列の追加/削除、列順、幅、表示形式、ソート可否、キーワード検索対象、既定ソートを管理する。
• 一覧表示 タブに 項目から一覧を作成 または 未追加項目を追加 の導線を用意する。

自動追加・取込の除外候補¶

• id
• tenant_id
• lock_version
• シーケンス/自動採番など、一覧表示価値が低い内部識別項目
• 登録ユーザー、更新ユーザー
• 登録日、更新日
• 長文項目
• text 型
• varchar でデータ長が一定以上の項目。初期案は 20 以上とするが、設計時に閾値を確定する。

追加受入条件¶

• 項目追加時に、一覧表示向きの項目が自動で list_columns に反映される。
• 項目 タブの 一覧に表示 ON/OFF と 一覧表示 タブの列追加/削除が、同じ list_columns を見て一貫して表示される。
• list_visible と list_columns の二重管理に見えない。
• 手動で一覧列を追加・削除する操作は維持される。
• 自動追加対象外の項目でも、必要なら 一覧表示 タブで手動追加できる。
• 既存 metadata の list_visible / list_column_order をどう移行または互換読み込みするかを設計で明記する。

追加方針: 文言キー入力の廃止¶

ユーザー合意済みの方針として、各種 文言キー は通常UIで入力・編集させない。

• テーブル/リソースの文言キーは、テーブルコードまたは resource 名から自動生成する。
• フィールドの文言キーは、フィールド名から自動生成する。
• 選択肢/固定値の文言キーは、値のコードまたは値名から自動生成する。
• 生成されるキーは安定して予測可能な命名規則にする。
• 日本語表示名、項目名、選択肢名称などの表示文言は、それぞれの設定画面で直接入力する。
• 多言語翻訳が必要な場合のみ、詳細モードの 文言 / 多言語 画面で翻訳文言を編集できるようにする。
• 簡単モードの 項目 タブや基本設定には 文言キー、単位キー、出力ファイル名キー などのキー入力欄を表示しない。

追加受入条件¶

• 簡単モードで、利用者が 文言キー を理解・入力しなくてよい。
• 既定の文言キーが、テーブル名/フィールド名/値名から自動生成される。
• 既存 metadata に明示的な文言キーがある場合の互換読み込み・保存方針が設計に明記されている。
• 多言語翻訳を使わない単一言語運用では、文言 画面を触らずにアプリを作成できる。
• 多言語翻訳が必要な場合だけ、詳細モードで生成済みキーに対する翻訳文言を編集できる。

最新確定方針: 項目一覧の順番項目¶

ユーザー合意済みの方針として、項目 タブ内の順番項目は簡単モードでは 1 つにまとめる。

• 簡単モードでは フォーム順 を標準の表示順として扱う。
• 簡単モードでは 詳細順 と 一覧順 を表示しない。
• 簡単モードで フォーム順 を変更した場合、詳細順 と 一覧順 には同じ値を自動的に設定する。
• 詳細順 と 一覧順 を個別に調整したい場合だけ、詳細モードで表示・編集できるようにする。
• 左端の上下矢印は、簡単モードでは フォーム順 を入れ替える操作として扱い、変更後の値を 詳細順 と 一覧順 にも同期する。
• 詳細モードでは、フォーム順、詳細順、一覧順 を個別表示してもよいが、各順番がどの画面に効くか分かる文言にする。

追加受入条件¶

• 簡単モードの項目一覧で、順番に関する列は実質 1 種類だけに見える。
• 簡単モードで項目順を変更すると、フォーム・詳細・一覧の順番値が同じ値で保存される。
• 詳細モードでだけ、フォーム・詳細・一覧の順番を個別に確認・調整できる。
• 既存 metadata の form_order / detail_order / list_column_order の読み込み・保存互換が保たれる。
• 既存アプリで 3 種類の順番値が異なる場合、簡単モード表示時にどう扱うかを設計で明記する。

追加方針: 一覧専用の列名/略称¶

ユーザー合意済みの方針として、フォーム/詳細画面で使う項目名と、一覧画面で使う列名は必要に応じて分離できるようにする。

• 項目 タブの日本語名は、フォーム・詳細・バリデーション・CSVなどで使う標準ラベルとして扱う。
• 一覧画面だけ短い名前で表示したい場合に備え、一覧表示 タブの列設定に 一覧表示名 または 列名 を用意する。
• 一覧表示名 は詳細モードでのみ表示・編集できるようにする。
• 簡単モードでは 一覧表示名 を表示しない。未設定の場合は項目の日本語名を自動的に使う。
• 例: フォーム/詳細では 請求予定日、一覧では 予定日 のように略称を設定できる。
• 設定場所は 項目 タブや生成アプリの詳細画面ではなく、一覧表示 タブの列詳細設定とする。
• 一覧列追加時は、初期値として項目の日本語名を反映する。
• 多言語対応時は、一覧専用ラベルも文言キーをユーザー入力させず、テーブル名・フィールド名・一覧列用途から自動生成する。

追加受入条件¶

• 簡単モードでは、項目名と一覧列名の違いを利用者が意識しなくてよい。
• 詳細モードの 一覧表示 タブでのみ、一覧専用の列名/略称を設定できる。
• 一覧専用列名が未設定の場合、一覧列ヘッダーには項目の日本語名が表示される。
• 一覧専用列名を設定した場合、フォーム/詳細画面の項目ラベルには影響しない。
• 既存 metadata / i18n に一覧列ラベル相当の設定がある場合の互換読み込み・保存方針を設計に明記する。

追加方針: 文字列長バリデーション¶

ユーザー合意済みの方針として、文字列項目では 最大長 だけでなく、最小文字数や固定文字数も設定できるようにする。

• 最大長 は DB 型にも反映する。例: string + 最大長=5 は varchar(5) として生成する。
• 最小文字数 は入力/APIバリデーションとして扱う。例: 3文字以上5文字以内 の 3。
• 固定文字数 は商品番号・管理番号・自動採番コードなど、桁数固定の業務コード向けに設定できるようにする。
• 固定文字数 を指定した場合、最小文字数と最大長の両方に同じ文字数を適用するか、同等のバリデーションとして扱う。
• DB 型は原則 char(n) ではなく varchar(n) を使う。固定桁は DB 型ではなくバリデーションで担保する。
• char(n) は標準UIの選択肢には出さない。必要になった場合のみ個別拡張として扱う。
• これらの設定は簡単モードには出さず、詳細モードの項目詳細設定で扱う。

追加受入条件¶

• 文字列項目で 3文字以上5文字以内 のような範囲指定ができる。
• 商品番号などで 8文字固定 のような固定長指定ができる。
• 最大長 は生成DBの varchar(n) と画面/APIの最大文字数バリデーションに反映される。
• 最小文字数 と 固定文字数 は画面/APIの入力バリデーションに反映される。
• 固定文字数 を設定しても DB 型は標準では char(n) にならない。
• 既存 metadata に length しかない場合の互換読み込み・保存方針を設計で明記する。

追加方針: 項目設定の画面用途別カテゴリ¶

ユーザー合意済みの方針として、項目設定は設定名の羅列ではなく、どの画面・用途に効く設定かでカテゴリ分けして表示する。

• 一覧
  • 一覧表示対象、一覧専用列名/略称、列順、列幅、表示形式、ソート可否、一覧での空表示、一覧リンク表示などを扱う。
  • 一覧列の詳細設定は 一覧表示 タブ側に集約する。
• 登録・更新フォーム
  • 入力UI、必須、編集可否、初期値、フォーム順、フォーム幅、入力バリデーション、正規化などを扱う。
  • 簡単モードでは登録・更新を原則まとめて扱い、必要な場合だけ詳細モードで登録時/更新時の差分を表示する。
• 詳細
  • 詳細表示対象、詳細順、読み取り専用表示、空表示、リンク表示などを扱う。
  • 簡単モードではフォーム順と同じ値を使い、詳細順の個別調整は詳細モードに寄せる。
• 検索
  • 一覧検索、詳細検索、他画面から参照・選択される時の検索対象、検索方式、検索条件UI、複数検索、候補表示などを扱う。
  • 他の画面の検索 に効く設定であることが分かる文言にする。
• 詳細モードでは、必要に応じて CSV、文言/多言語、権限/監査、高度なDB/バリデーション などのカテゴリを追加表示する。

追加受入条件¶

• 項目設定画面で、各設定が 一覧、登録・更新フォーム、詳細、検索 のどれに効くか分かる。
• 簡単モードでは、利用者が一覧列幅とフォーム幅、一覧順とフォーム順、一覧検索と他画面検索を混同しにくい表示になっている。
• 一覧に関する詳細設定は 一覧表示 タブに集約され、項目タブと二重管理に見えない。
• 登録・更新・詳細・検索のうち、標準では同じ値でよい設定は簡単モードで統合表示される。
• 個別調整が必要な設定だけ、詳細モードでカテゴリ別に表示される。

追加方針: 固定選択肢と参照マスタの候補設定を分ける¶

ユーザー合意済みの方針として、選択候補を持つ項目は 固定選択肢 と 他テーブル参照（参照マスタ） を明確に分けて設定できるようにする。

• 固定選択肢
  • YAML 上の value_set として候補値を持つ項目。
  • 候補の保存値、表示名、表示順を Core GUI で管理できるようにする。
  • 選択肢ソート は固定選択肢に対する候補表示順の設定として扱う。
  • 簡単モードでは 選択肢ソート を表示せず、既定値は YAMLの登録順 とする。
  • 詳細モードでのみ、YAMLの登録順、表示順番号、表示名順、保存値順 などを選べるようにする。
• 他テーブル参照（参照マスタ）
  • 保存値は xxx_id などの参照IDで、候補は参照先テーブルから取得する項目。
  • 固定選択肢用の 選択肢ソート は表示しない。
  • 候補表示名、候補検索対象、候補の並び順、検索UIは参照マスタ側の設定として扱う。
  • 簡単モードでは候補の並び順を表示せず、既定値は 表示名の昇順 とする。
  • 詳細モードでのみ、参照マスタ候補の並び順や検索対象を調整できるようにする。
• UI上は、項目の候補種別として 固定選択肢 / 他テーブル参照 / 候補なし が分かる表示にする。
• 固定選択肢の候補順と、参照マスタの検索・候補順を同じ設定名で扱わない。

追加受入条件¶

• 固定選択肢項目では、簡単モードで候補順設定が表示されず、YAML登録順で候補が表示される。
• 他テーブル参照項目では、簡単モードで候補順設定が表示されず、参照先表示名順で候補が表示される。
• 詳細モードで、固定選択肢の候補順と参照マスタの候補順を別々に設定できる。
• 固定選択肢では 選択肢ソート、参照マスタでは 参照候補の並び順 のように、用途が分かる文言になっている。
• 参照マスタ項目に固定選択肢専用の option_sort が表示されない。
• 既存 metadata の option_sort は固定選択肢用として互換読み込み・保存する。
• 参照マスタ候補の既定並び順、表示名項目、検索対象をどう metadata / generator で表現するかを設計に明記する。

追加方針: 候補検索対象の簡単モード非表示¶

ユーザー合意済みの方針として、固定選択肢および他テーブル参照の候補検索対象は、簡単モードでは表示しない。

• 固定選択肢
  • option_search_targets 相当の候補検索対象は詳細モードでのみ表示・編集する。
  • 簡単モードの既定値は 表示名 とする。
  • 保存値 value を検索対象に含めるかどうかは詳細モードでだけ選べるようにする。
• 他テーブル参照（参照マスタ）
  • 参照候補の検索対象は詳細モードでのみ表示・編集する。
  • 簡単モードの既定値は参照先の 表示名 とする。
  • 参照先コード、電話番号、部署名など表示名以外を候補検索に含めたい場合だけ、詳細モードで設定する。
• UI文言は 選択肢検索対象 だけではなく、固定選択肢では 固定選択肢の検索対象、参照マスタでは 参照候補の検索対象 のように用途が分かる表現にする。

追加受入条件¶

• 簡単モードで、候補検索対象の設定欄が表示されない。
• 固定選択肢の候補検索は、未設定時に表示名を対象にする。
• 他テーブル参照の候補検索は、未設定時に参照先表示名を対象にする。
• 詳細モードでだけ、保存値や参照先コードなど表示名以外を検索対象に追加できる。
• 既存 metadata の option_search_targets は固定選択肢用として互換読み込み・保存する。
• 参照マスタ候補検索対象をどう metadata / generator で表現するかを設計に明記する。

追加方針: 選択肢依存項目 の名称と説明を見直す¶

ユーザー指摘により、現行の 選択肢依存項目 というラベルおよび この項目の選択肢を、他項目の値に応じて絞り込むための依存項目です。 という説明は、利用者向けに意味が分かりにくく、クレームの温床になり得るため見直す。

option_dependencies の実体は、固定選択肢や参照候補を取得し直す時に、どの入力項目の値を条件として使うかを指定する詳細設定である。例として、部署 の選択値によって 役職 の候補を絞り込む場合、役職 側で条件元項目として 部署 を指定する。

• 簡単モードでは非表示にする。
• 詳細モードでも 選択肢依存項目 というラベルは使わない。
• 名称は 検索項目 とする。
• 候補が固定選択肢の場合も参照マスタの場合も、候補検索・候補絞り込みに使う項目として 検索項目 に統一する。
• 説明文は抽象語を避け、この項目の候補を検索・絞り込みする時に使う項目を選びます。例: 部署を選ぶと役職候補を絞り込む。 のように具体例を含める。
• 候補取得や再取得制御の内部用語を、通常利用者向け説明に出さない。

追加受入条件¶

• Core GUI に 選択肢依存項目 というラベルが表示されない。
• 簡単モードで、検索項目 の設定欄が表示されない。
• 詳細モードでのみ 検索項目 として表示される。
• 詳細モードの説明文を読めば、どの項目を選べばよいか具体例で分かる。
• 既存 metadata の option_dependencies は互換読み込み・保存するが、利用者向け文言には内部名を出さない。

追加方針: 検索方式と検索演算子を矛盾なく扱う¶

ユーザー指摘により、検索方式 と 検索演算子 を独立した設定として自由に選べるUIは見直す。完全一致 と設定しているのに内部演算子だけ LIKE にできるような状態は、画面表示と生成される検索条件の整合性が崩れるため許容しない。

• 簡単モードでは、検索方式 と 検索演算子 を別々に表示しない。
• 簡単モードでは、利用者向けには 検索条件 または 検索種別 として、意味が一貫したプリセットを選ばせる。
  • 例: 完全一致 は = / IN 相当。
  • 例: 部分一致 は LIKE / ILIKE 相当。
  • 例: 前方一致 は LIKE 'xxx%' / ILIKE 'xxx%' 相当。
  • 例: 以上 は >= 相当。
  • 例: 以下 は <= 相当。
  • 例: より大きい は > 相当。
  • 例: より小さい は < 相当。
  • 例: 範囲指定 は BETWEEN / >= / <= 相当。
• 入力UIは、検索条件と項目型から自動決定する。
  • 例: 文字列の部分一致はテキスト入力。
  • 例: 固定選択肢の完全一致は select または checkbox group。
  • 例: 日付の範囲指定は from/to 入力。
• 詳細モードで内部演算子を表示する場合でも、検索条件 と矛盾する演算子は選べないようにする。
• 検索方式 という文言を使う場合は、比較条件ではなく入力UIを指す 検索入力方式 のように明確化する。
• YAML / generator 側では、利用者向けプリセットから一貫した operator / widget を生成する。

追加受入条件¶

• Core GUI で、完全一致 と LIKE のような矛盾した検索設定を保存できない。
• 数値・日付・日時項目では、以上、以下、より大きい、より小さい、範囲指定 を選択できる。
• 簡単モードでは、検索設定が 検索条件 または 検索種別 として一貫した選択肢になっている。
• 詳細モードでも、比較演算子と入力UIの不整合をバリデーションで防ぐ。
• 既存 metadata に検索方式・検索演算子が別々に保存されている場合の互換読み込みと正規化方針を設計で明記する。
• DBインデックス設計と検索演算子の対応を設計で明記する。

追加方針: 検索入力方式にラジオボタン・チェックボックスを含める¶

ユーザー合意済みの方針として、検索条件の意味と、検索フォームで使う入力部品は分けて扱う。ただし簡単モードでは利用者が個別に選ばなくてよいよう、項目型・候補数・複数選択可否から自動決定する。

• 検索条件 は比較の意味を表す。
  • 例: 完全一致、部分一致、前方一致、以上、以下、より大きい、より小さい、範囲指定。
• 検索入力方式 は検索フォームの入力部品を表す。
  • 例: テキスト入力、セレクト、ラジオボタン、チェックボックス、チェックボックス複数選択、日付入力、日付範囲、オートコンプリート。
• 固定選択肢や boolean では、候補数が少ない場合に ラジオボタン を使えるようにする。
• 複数候補を選んで検索する場合は、チェックボックス複数選択 を使えるようにする。
• boolean 項目では、チェックボックス または ラジオボタン を使えるようにする。
• 簡単モードでは 検索入力方式 を表示せず、自動決定する。
  • 固定選択肢の候補数が少ない場合: ラジオボタン候補。
  • 固定選択肢の候補数が多い場合: セレクト候補。
  • 複数選択検索の場合: チェックボックス複数選択候補。
  • 参照マスタの場合: オートコンプリート候補。
  • 日付・日時の範囲指定: 日付範囲候補。
• 詳細モードでのみ、必要に応じて 検索入力方式 を手動調整できる。
• 検索条件 と 検索入力方式 の不整合は保存できないようにする。

追加受入条件¶

• 検索フォームで、固定選択肢や boolean にラジオボタンを使える。
• 検索フォームで、固定選択肢の複数選択にチェックボックス複数選択を使える。
• 簡単モードでは、ラジオ/チェックボックスなどの入力方式を利用者が個別設定しなくても適切に自動選択される。
• 詳細モードでのみ 検索入力方式 を確認・変更できる。
• 部分一致 + ラジオボタン のような意味が崩れる組み合わせは保存できない。

追加方針: 詳細画面上部サマリー設定は詳細モードに寄せる¶

ユーザー合意済みの方針として、上部サマリーに表示 相当の設定は機能として残す。ただし簡単モードでは不要なため表示しない。

• 上部サマリーは、詳細画面の上部に親項目の重要情報を読み取り専用で表示するための設定である。
• どの項目を表示するかは、各項目ごとの 詳細画面上部に表示 チェックで指定する。
• YAML 上は detail_layout.header_summary.items として保存する。
• 簡単モードでは、この設定欄を表示しない。
• 詳細モードでのみ、詳細画面上部に表示、表示順、幅、強調、表示形式を設定できるようにする。
• 現行の 上部サマリーに表示 という文言は、利用者には意味が伝わりにくいため 詳細画面上部に表示 など、表示場所が分かる名称へ変更する。
• 機微情報項目は従来通り詳細画面上部サマリーに追加できない。

追加受入条件¶

• 簡単モードで、詳細画面上部サマリー関連の設定が表示されない。
• 詳細モードで、項目ごとに詳細画面上部へ表示するかを設定できる。
• 詳細モードで、表示順・幅・強調・表示形式を設定できる。
• Core GUI 上の文言が 上部サマリーに表示 ではなく、表示場所が分かる名称になっている。
• 既存 metadata の detail_layout.header_summary.items は互換読み込み・保存する。

追加方針: 項目ごとの一意チェックと一意制約テーブルの同期¶

ユーザー指摘により、項目ごとの 一意制約 チェックと、基本設定の INDEX / 一意制約 unique_keys が同じ unique_keys を操作するにもかかわらず、UI上の関係が分かりにくいため整理する。

現行実装では、項目側の一意チェックは { fields: [field_name], expressions: [] } の単一項目 unique key を追加・削除するショートカットである。そのため、同じ単一項目UKは基本設定の一意制約テーブルにも表示されるべきであり、どちらから見ても同じ設定として扱う。

• 項目一覧の一意チェックは、単一項目UKだけを扱うショートカットとする。
• 項目一覧の文言は 一意制約 ではなく この項目だけで一意 のように、単一項目専用であることが分かる名称にする。
• 基本設定の 一意制約 テーブルは、単一項目UKと複合UKの両方を扱う正本UIとする。
• 項目側で この項目だけで一意 をONにした場合、基本設定の一意制約テーブルに同じ単一項目UKが1行だけ表示される。
• 基本設定側で同じ単一項目UKを追加した場合、項目側チェックもONになる。
• 基本設定側で該当単一項目UKを削除した場合、項目側チェックもOFFになる。
• 同じ fields / expressions の一意制約を重複保存できないようにする。
• 複合UKに含まれる項目について、項目側の この項目だけで一意 はONにしない。複合UKは基本設定の一意制約テーブルだけで確認・編集する。

追加受入条件¶

• 項目側チェックと基本設定の一意制約テーブルが同じ unique_keys を一貫して表示・更新する。
• 単一項目UKを二重に登録できない。
• 複合UKを項目側チェックボックスで誤って表現しているように見えない。
• 基本設定の一意制約テーブルで複合UKを設定できる。
• 保存時に重複した unique_keys があれば正規化またはバリデーションエラーにする。
• 既存YAMLに重複 unique_keys がある場合の読み込み・保存時の扱いを設計で明記する。

追加方針: 重複する一意制約は保存時に防止する¶

ユーザー確認により、項目側の単一一意チェックと基本設定の INDEX / 一意制約 unique_keys の両方から同じ一意制約を設定できる場合でも、同一内容の一意制約を重複登録できないようにする。

現状懸念として、生成経路によって index 名の作り方が異なり、同じ fields / expressions の一意制約が重複した場合に、必ずしもGUI上でエラーにならず、別名の重複 index が作られる可能性がある。この状態は仕様として許容しない。

• Core GUI 保存時に、unique_keys の重複を検出する。
• 重複判定は、fields と expressions の正規化後の組み合わせで行う。
  • 項目名・式の大小文字、前後空白、不要なクォートなどの扱いを設計で明確にする。
  • fields の順序を制約順として扱うか、同一項目集合として扱うかを設計で明確にする。
• 重複がある場合は、基本方針として保存エラーにする。
• 自動正規化で1件に潰す場合は、利用者に分からないまま削除せず、保存前に画面上で重複行を明示する。
• 項目側の この項目だけで一意 チェックと、基本設定の一意制約テーブルは同じ単一UKを1件として同期表示する。
• 生成側でも、同一内容の unique index が複数名で作成されないようにする。
• 既存YAMLに重複 unique_keys がある場合は、読み込み時に警告し、保存時には解消を要求する。

追加受入条件¶

• 同じ単一項目UKを、項目側チェックと基本設定テーブルの両方から二重登録できない。
• 同じ複合UKを基本設定テーブルで複数行登録しようとすると、保存前または保存時にエラーになる。
• 重複UKがある状態で、別名のDB unique index が複数作成されない。
• 重複エラーでは、対象の一意制約行と重複内容が分かるメッセージを表示する。
• 既存YAMLの重複UKを読み込んだ場合、利用者がどの行を削除すべきか判断できる表示にする。

追加方針: 機微情報 設定を削除する¶

ユーザー合意済みの方針として、項目設定の 機微情報 / sensitive は通常のCore GUI設定から削除する。

理由は、検索対象にするか、候補検索条件に使うか、詳細画面上部に出すか、監査ログに出すか、CSVに出すかは、それぞれ個別の設定で制御すべきであり、機微情報 という横断フラグは効果が曖昧で利用者に誤解を与えるためである。また、機微情報 という名称は暗号化保存を想起させるが、現行の sensitive は暗号化フラグではない。

• Core GUI の項目設定から 機微情報 チェックを削除する。
• sensitive を新規の通常設定として作成・編集させない。
• 暗号化保存が必要な場合は、別機能として 暗号化保存 など明確な設定名で扱う。
• 候補検索条件、検索対象、詳細画面上部表示、監査ログ、CSV出力などは、それぞれの個別設定で明示的に制御する。
• 既存YAMLに sensitive: true がある場合の互換読み込み・移行方針を設計に明記する。
• 既存実装で sensitive によって上部サマリー、候補依存、監査ログなどを禁止している箇所は、個別設定側のバリデーションへ置き換えるか、移行方針を明確にする。

追加受入条件¶

• 簡単モード・詳細モードともに、項目設定に 機微情報 チェックが表示されない。
• 新規作成・通常編集で sensitive に依存した設定を増やさない。
• 既存 sensitive: true のYAMLを読み込んだ場合、消失・意味変更が利用者に分からないまま発生しない。
• 暗号化保存が必要な要件と、表示/検索/ログ除外の要件が混同されない。
• 検索、上部サマリー、監査ログ、CSV出力の制御は、それぞれの画面・設定で確認できる。

追加方針: キーワード検索と詳細検索フォームの名称を分ける¶

ユーザー確認により、一覧画面上部の1つの検索ボックスによる検索と、項目ごとの検索フォームは別物として明確に表示する。

• 一覧画面上部の1つの検索ボックスは キーワード検索 と呼ぶ。
  • 複数項目を横断して部分一致検索するための設定である。
  • 例: 請求番号、取引先名、備考をまとめて検索対象にする。
• 項目ごとの条件指定は 詳細検索 または 詳細検索項目 と呼ぶ。
  • 項目単位で完全一致、部分一致、範囲指定などを設定する検索フォームである。
  • 例: ステータス=承認済み、請求日>=2026-09-01、金額>=10000。
• 一覧検索・ソート というセクション名は、必要に応じて キーワード検索・既定ソート のように具体化する。
• キーワード検索方式 は現状 ilike 1種類だけであり、簡単モードでは表示しない。
• キーワード検索の検索対象は キーワード検索対象 として複数選択できるようにする。
• 詳細検索フォームの対象項目や検索条件は、項目ごとの 検索 カテゴリまたは詳細検索設定側で扱う。

追加受入条件¶

• 利用者が、キーワード検索と項目別の詳細検索フォームを混同しない画面文言になっている。
• キーワード検索方式 のように、実質選択肢がない設定を簡単モードに表示しない。
• キーワード検索対象は複数項目を選べる。
• 詳細検索項目は、項目ごとの検索設定として別に確認できる。
• セクション名・ヘルプ文言に、キーワード検索が一覧上部の1つの検索ボックスであることを明記する。

追加方針: list_views のコード入力を通常UIから外す¶

ユーザー指摘により、クエリ list_views の コード は内部識別子としては必要だが、通常利用者が指定・編集する項目ではないため、通常UIから外す。

現行実装では、新規追加時に query_1 のようなコードが自動生成される一方で、画面上に コード 入力欄が表示され、利用者が手入力できる。これは利用者に不要な内部ID管理を求めるため見直す。

• list_views[].code は内部識別子として維持する。
• 通常UIでは コード 入力欄を表示しない。
• 新規クエリ追加時は、名称または連番から安定したコードを自動生成する。
  • 例: query_1, query_2、または名称から生成した slug。
• コード重複時は自動で連番を付与して一意にする。
• 利用者が設定する主項目は 名称、説明、既定、検索語、固定絞り込み、ソート、ページサイズ、表示列とする。
• コードをどうしても確認・編集する必要がある場合だけ、詳細モードまたは開発者向け表示で扱う。
• 既存YAMLにある list_views[].code は互換読み込み・保存する。

追加受入条件¶

• 簡単モードで list_views[].code の入力欄が表示されない。
• 新規 list_view 追加時に、ユーザーがコードを入力しなくても一意な code が保存される。
• 名称を変更しても、既存コードを不用意に変えて保存クエリやホームショートカット参照を壊さない。
• コード重複が発生しないよう自動採番または保存時バリデーションが行われる。
• 既存YAMLのコードは維持され、必要な場合だけ詳細モードで確認できる。

追加整理: list_views.code の扱い¶

• list_views[].code は内部識別子として必要だが、通常ユーザーが指定・編集する項目ではない。
• 簡単モードでは コード 入力を非表示にし、ユーザーは表示名・検索対象・ソート等の実務設定だけを操作する。
• 新規追加時は query_1, query_2 などの安定した一意コードを自動採番する。
• 表示名を変更しても code は変更しない。保存済み条件、URL、ホームショートカット、権限紐づけ等の参照が壊れないようにする。
• 詳細モードでも原則は読み取り専用とし、移行・保守など明確な必要がある場合のみ編集可能にする。
• 既存YAMLの list_views[].code は互換維持する。

追加方針: クエリ / List View の利用者向け名称を 一覧パターン に変更する¶

ユーザー合意済みの方針として、Core GUI の利用者向け画面では クエリ や List View という開発者向け文言を使わず、一覧パターン と表現する。

理由は、クエリ はSQLや開発者向け概念として受け取られやすく、業務ユーザーには「何を設定する場所か」が分かりにくいためである。ここで扱う実体は、一覧画面でよく使う表示条件・並び順・表示列を保存したパターンである。

• 画面上のセクション名・ボタン・見出しでは 一覧パターン を使う。
• YAML / 内部モデル上の list_views は互換維持する。
• 詳細モードや開発者向け説明で内部名を補足する場合のみ list_views を併記してよい。
• 説明文は よく使う一覧の表示条件・並び順・表示列を保存します。 のように、業務ユーザーが用途を想像しやすい表現にする。
• 例示は 未対応一覧、承認待ち一覧、自分の担当一覧 など、実際の業務利用に近い名称にする。

追加受入条件¶

• 簡単モードで クエリ、List View という文言が主表示されない。
• 一覧表示設定内で、保存済みの表示条件・並び順・表示列のまとまりが 一覧パターン として表示される。
• 一覧パターン の説明を読めば、SQLや開発知識がなくても用途を理解できる。
• 既存YAMLの list_views は変更せず、表示名だけを利用者向けに置き換える。

追加方針: 文言 設定は多言語利用時だけ表示する¶

ユーザー合意済みの方針として、単一言語運用では 文言 / 文言キー / 翻訳 画面を通常操作に出さない。

理由は、各設定画面で入力する 日本語名、一覧表示名、選択肢名、一覧パターン名 などがそのまま表示文言として使われるため、単一言語では別途 文言 画面を操作する必要がないためである。

• 簡単モードでは 文言 関連画面・タブ・入力欄を表示しない。
• 詳細モードでも、多言語設定がOFFの場合は 文言 関連画面を表示しない、または折りたたむ。
• 多言語設定をONにした場合のみ、文言/翻訳 画面を表示する。
• 文言キーはテーブル名、フィールド名、値名、用途から自動生成する。
• 通常ユーザーには文言キーを入力・編集させない。
• 表示名の編集は、それぞれの業務設定画面で行う。
  • 項目名: 項目設定
  • 一覧専用列名: 一覧表示
  • 選択肢名: 固定選択肢
  • 一覧パターン名: 一覧パターン
• 多言語利用時だけ、生成済みキーに対して各言語の翻訳文言を編集できるようにする。

追加受入条件¶

• 単一言語運用では、利用者が 文言 画面を触らずにアプリを作成・編集できる。
• 簡単モードで 文言キー が表示されない。
• 多言語設定OFF時に、文言/翻訳 設定が通常操作の邪魔にならない。
• 多言語設定ON時だけ、翻訳文言を編集できる導線が表示される。
• 既存YAML / i18n 定義に明示的な文言キーや翻訳がある場合の互換読み込み・保存方針を設計に明記する。

追加方針: CSV設定の取込方式と不要項目を整理する¶

ユーザー指摘により、CSV設定の 取込方式 と 欠損レコード処理 を独立した設定として表示する構成は見直す。

現行UIでは 取込方式 に 追加・更新(upsert) / 完全同期(full_sync) があり、別項目として 欠損レコード処理 に エラー / 論理削除 がある。しかし 欠損レコード処理 は 完全同期 の場合にだけ意味を持つ設定であり、追加・更新(upsert) ではCSVに存在しない既存データを処理対象にしないため、独立項目として常時表示すると理解しにくい。

• 利用者向けUIでは、取込方式 と 欠損レコード処理 を1つの選択肢に統合する。
  • 追加・更新のみ: CSVにある行だけ追加または更新する。CSVにない既存データは触らない。
  • 完全同期（CSVにない既存データがあればエラー）: CSVを正本として扱い、既存データがCSVにない場合は取込を止める。
  • 完全同期（CSVにない既存データは論理削除）: CSVを正本として扱い、CSVにない既存データは論理削除扱いにする。
• 内部YAMLは既存互換のため import_csv_mode と import_csv_missing_record_action に変換して保存してよい。
• 欠損レコード処理 という独立項目は通常UIから削除する。

追加方針: 論理削除項目/値の扱い¶

• 論理削除項目 と 論理削除値 は通常UIでは表示しない。
• 論理削除に使う項目は、アプリまたはリソース側で定義済みの標準削除/有効フラグを使う。
• 単なる業務フラグをCSV同期の論理削除先として利用者に選ばせない。
• 論理削除に使える標準項目が存在しない場合は、完全同期（CSVにない既存データは論理削除） を選択不可にするか、設定前提不足としてエラーにする。
• 既存YAMLの import_csv_logical_delete_field / import_csv_logical_delete_value は互換読み込みするが、通常UIでは編集対象にしない。

追加方針: CSV出力ファイル名キーを通常UIから削除する¶

• 出力ファイル名キー は文言キーであり、通常ユーザーが指定する必要はないため通常UIから削除する。
• CSV出力ファイル名は、アプリ名またはリソース名から自動生成する。
  • 例: 請求書.csv、必要に応じて日時付き 請求書_20260917.csv。
• 多言語利用時も文言キーは自動生成し、翻訳が必要な場合だけ文言/翻訳側で扱う。
• 既存YAMLの export_csv_filename_key は互換読み込みするが、通常UIでは表示・入力させない。

追加受入条件¶

• CSV設定画面で 取込方式 と 欠損レコード処理 を別々に理解しなくてよい。
• 追加・更新のみ を選んだ場合、CSVにない既存データは処理対象外であることが画面文言から分かる。
• 完全同期 を選んだ場合だけ、CSVにない既存データの扱いが選択肢に含まれる。
• 論理削除項目 / 論理削除値 が通常UIに表示されない。
• 論理削除できないリソースで、論理削除同期を選べない、または保存時に分かりやすくエラーになる。
• 出力ファイル名キー が通常UIに表示されない。
• CSV出力ファイル名はユーザーが文言キーを入力しなくても自動決定される。