Linear migration metadata¶

• Linear issue: TAK-265
• Linear URL: https://linear.app/takayuki-komoda/issue/TAK-265/core-gui-ワークフロー定義画面のコード入力と承認ステップ初期名を整理する
• Linear status: Backlog
• Linear team: Takayuki Komoda
• Linear project: EPAA Core
• Linear assignee:
• Linear labels:
• Linear created: 2026-09-15T13:10:09.771Z
• Linear updated: 2026-09-15T15:27:27.157Z
• Linear archived:

---

Original description¶

背景¶

Core GUI のワークフロー定義画面で、ワークフローコードおよび承認ステップコードが利用者に入力可能な項目として表示されている。

しかし、これらのコードは内部識別子としては必要だが、通常利用者が指定・編集する項目ではない。利用者はワークフロー名、利用アプリ、状態、承認順、承認グループなどの業務設定に集中できるべきである。

また、承認ステップの初期表示名が1件目は 一次承認、2件目以降が 承認2、承認3 となっており、命名規則が揃っていない。

要件¶

• ワークフロー定義画面の簡単モードでは、ワークフローの コード をユーザーに入力させない。
• ワークフローコードは新規追加時に内部で自動発行する。
  • 例: workflow_1, workflow_2, workflow_3 など。
  • 既存コードと重複しないように採番する。
• 登録後のワークフローコードは、名称変更しても不用意に変更しない。
• 承認ステップの コード も簡単モードではユーザーに入力させない。
• 承認ステップコードは追加時に内部で自動発行する。
  • 例: step_1, step_2, step_3 など。
  • 既存ステップコードと重複しないように採番する。
• 承認ステップの初期表示名は、1件目から 承認1、承認2、承認3 のように統一する。
• 現行の 一次承認 と 承認2 が混在する初期値は廃止する。
• コードをどうしても確認・編集する必要がある場合だけ、詳細モードまたは開発者向け表示で扱う。

受入条件¶

• 簡単モードで、ワークフロー コード 入力欄が表示されない。
• 簡単モードで、承認ステップ コード 入力欄が表示されない。
• 新規ワークフロー追加時に、ユーザーがコードを入力しなくても一意なコードが保存される。
• 新規承認ステップ追加時に、ユーザーがコードを入力しなくても一意なコードが保存される。
• 承認ステップを3件追加した場合、初期表示名が 承認1、承認2、承認3 になる。
• 既存ワークフロー/既存ステップのコードは互換維持し、読み込み・保存で壊さない。
• 詳細モードでコードを表示する場合も、通常利用者が編集必須と誤解しない文言・配置にする。

注意事項¶

• この issue は Core GUI のワークフロー定義画面を対象とする。
• 承認ロジックそのもの、承認候補者解決、ワークフロー実行APIの変更は対象外。
• 既存YAML / DB に保存済みの workflow_code、step_code は互換維持する。
• コード自動採番ルールは、既存コードとの重複回避と名称変更時の安定性を設計に明記する。

追加方針: 選択肢はコードではなく名称を主表示にする¶

ユーザー合意済みの横断方針として、Core GUI の選択UIでは、内部コードを主表示にせず、利用者が理解できる名称を表示する。

今回の対象では、ワークフロー定義画面の 承認グループ 選択肢が sample_sales などのコード表示になっているが、通常ユーザーには意味が分からないため、グループ名称を表示する。

• 承認グループ の選択肢はグループコードではなくグループ名称を主表示にする。
• 必要に応じて詳細モードまたは補助表示で 営業部（sample_sales） のようにコードを併記してよい。
• 簡単モードではコードだけの表示を禁止する。
• この方針は承認グループに限らず、Core GUI 全体の選択肢に適用する。
  • グループ
  • アプリ
  • ワークフロー
  • 承認ステップ
  • 項目
  • 一覧パターン
  • 固定選択肢
  • 参照マスタ
• 内部的な保存値は従来通りコードでよいが、画面上の主表示は名称にする。
• 名称が空または重複する場合だけ、補助情報としてコードを併記する。

追加受入条件¶

• ワークフロー定義画面の 承認グループ ドロップダウンで、コードだけが表示されない。
• グループ名称が存在する場合は、名称を主表示として選択できる。
• 保存値は既存互換のためグループコードを維持する。
• Core GUI の他の選択UIでも、コードだけ表示になっている箇所を洗い出し、名称主表示に揃える。
• 詳細モードでコードを併記する場合も、名称よりコードが目立つ表示にしない。

追加方針: 条件JSON はワークフロー定義画面から削除する¶

ユーザー確認により、現行実装で condition_json が標準対応している条件は { "always": true } と { "always": false } のみであり、業務条件としての 以上、以下、= などの判定は行っていない。

この状態で 条件JSON を利用者に入力させても意味が伝わらず、この承認を使う/使わない だけの設定を作っても、承認ステップを削除または無効化すれば足りるため、詳細モードでも通常設定としては不要とする。

• ワークフロー定義画面から 条件JSON 入力欄を削除する。
• 簡単モード・詳細モードともに、通常UIでは 条件JSON を表示しない。
• 新規作成する承認ステップでは、condition_json は空/null、または既存仕様上必要な既定値に正規化する。
• 既存YAML / DB に condition_json が存在する場合は互換読み込みする。
• 既存 condition_json が { "always": true } の場合は通常の承認ステップとして扱う。
• 既存 condition_json が { "always": false } の場合の表示・保存・移行方針を設計で明記する。
• 将来、金額条件やレコード内容による条件分岐が必要になった場合は、JSON直接入力ではなく、別issueで利用者向けの 承認条件 UIとして設計する。
• 複雑な条件は現行方針どおり custom workflow hook で扱い、Core GUI の通常画面にJSON DSLを露出しない。

追加受入条件¶

• ワークフロー定義画面に 条件JSON という列・入力欄が表示されない。
• 利用者がJSONを書かなくてもワークフローを作成・保存できる。
• 新規承認ステップ追加時に、条件入力を求められない。
• 既存データの condition_json を読み込んでも、保存時に予期せず破壊しない。
• always しか扱えない内部仕様を、利用者向け設定として見せない。

追加方針: 利用アプリ もコードではなくアプリ名称を主表示にする¶

ユーザー指摘により、ワークフロー定義画面の 利用アプリ 選択肢も、アプリコードではなく利用者向けのアプリ名称を主表示にする。

approval_requests などのアプリコードは内部識別子であり、通常ユーザーには意味が伝わりにくい。選択肢では 承認依頼、請求書 のようなアプリ名称を表示し、保存値としては既存互換のためアプリコードを使う。

• 利用アプリ ドロップダウンはアプリ名称を主表示にする。
• コードだけの表示は禁止する。
• 必要に応じて詳細モードまたは補助表示で 承認依頼（approval_requests） のようにコードを併記してよい。
• アプリ名称が未設定または重複する場合だけ、補助情報としてコードを併記する。
• 保存値は既存互換のため application_code を維持する。

追加受入条件¶

• ワークフロー定義画面の 利用アプリ 選択肢で、コードだけが表示されない。
• アプリ名称が存在する場合は、名称を主表示として選択できる。
• 保存時は既存互換の application_code で保存される。
• 一覧・詳細・ドロップダウンの表示で、利用者がアプリコードを理解していなくても選択できる。

追加方針: 非表示コードの自動採番ルール¶

ユーザー合意済みの方針として、ワークフロー定義画面でコードを非表示にする場合、内部コードは表示名から生成せず、安定した連番コードとして自動採番する。

• ワークフローコードは新規作成時に workflow_1, workflow_2, workflow_3 のように自動採番する。
• 承認ステップコードは新規追加時に step_1, step_2, step_3 のように自動採番する。
• 既存コードと重複する場合は、次の未使用番号を採番する。
• 表示名を変更しても内部コードは変更しない。
• 日本語名からローマ字変換、slug化、翻訳生成などでコードを作らない。
• 削除済み番号は原則再利用しない。ただし既存データ互換やローカル未保存行の扱いは設計で明記する。
• 詳細モードで内部コードを表示する場合も、編集必須項目ではなく内部IDとして扱う。

追加受入条件¶

• 営業1課 申請・承認フロー のような表示名でも、内部コードは workflow_1 のように安定した自動採番になる。
• 表示名変更後も、既存の workflow_code / step_code が変わらない。
• 同一テナントまたは同一ワークフロー内でコード重複が発生しない。
• 日本語表示名の変更・表記ゆれ・翻訳により内部コードが変化しない。

追加方針: ワークフロー入力セクションのコードを非表示・自動採番にする¶

ユーザー確認により、ワークフロー段階別入力 の 入力セクション にある コード は、利用者が任意に理解して設定する業務項目ではなく、ステップ別ルールから入力セクションを参照するための内部識別子である。

そのため、通常UIでは 入力セクション のコードを表示・入力させず、追加時に内部で自動採番する。

• 入力セクション の コード は簡単モード・通常UIでは非表示にする。
• 新規入力セクション追加時は input_section_1, input_section_2, input_section_3 のように内部コードを自動採番する。
• 既存コードと重複する場合は、次の未使用番号を採番する。
• 表示名を変更しても内部コードは変更しない。
• 日本語表示名からローマ字変換、slug化、翻訳生成などでコードを作らない。
• 利用者が操作する主項目は 表示名、順序、共通、項目 とする。
• 文言キー も通常UIでは表示・入力させない。多言語設定時のみ翻訳管理側で扱う。
• 詳細モードで内部コードを表示する場合も、編集必須項目ではなく内部IDとして扱う。

追加受入条件¶

• 入力セクション 一覧に、通常操作として コード 入力欄が表示されない。
• 新規入力セクション追加時に、ユーザーがコードを入力しなくても一意な内部コードが保存される。
• ステップ別ルール は内部コードで保存しつつ、画面上では入力セクションの表示名を主表示にする。
• 入力セクションの表示名を変更しても内部コードは変わらない。
• 文言キー が通常UIで表示されない。
• 既存YAMLの入力セクションコード・文言キーは互換読み込み・保存する。

追加方針: ワークフロー入力セクションの 共通 を削除する¶

ユーザー確認により、ワークフロー段階別入力 の 入力セクション にある 共通 チェックは削除する。

現行実装では common は YAML から読み込まれるが、生成側の表示制御・編集制御で実質利用されていない。利用者にとっても、ステップ別ルール の 編集セクション / 必須セクション と役割が重複して見え、ON/OFFして何が変わるのか判断できない。

• 入力セクション 一覧から 共通 チェックを削除する。
• 簡単モード・詳細モードともに通常UIでは表示しない。
• 新規作成する入力セクションでは common を設定しない、または既定値 false に正規化する。
• 既存YAMLに common がある場合は互換読み込みするが、通常UIでは編集対象にしない。
• 将来、全承認で常に表示する入力欄が必要になった場合は、共通 ではなく 常に表示 など意味が明確な設定として別途設計する。

追加受入条件¶

• 入力セクション 一覧に 共通 チェックが表示されない。
• 利用者が 共通 の意味を理解しなくても、承認中の追加入力設定を保存できる。
• ステップ別ルール による編集対象セクションの制御と、意味のない 共通 設定が二重に見えない。
• 既存YAMLの common を読み込んでも、保存時に予期せず破壊しない。

追加方針: 段階別入力UIを 承認ごとの入力設定 に統合する¶

ユーザー合意済みの方針として、現行の 入力セクション と ステップ別ルール の2段階構造は、通常利用者向けには分かりにくいため、画面上は 承認ごとの入力設定 に統合する。

現行構造では、先に 入力セクション で表示項目セットを作り、その後 ステップ別ルール でどの承認ステップで編集・必須にするかを指定する。しかし利用者目線では、承認ごとに「どの項目を表示し、編集できるか」を直接設定できる方が自然である。

• 利用者向け画面名は 承認ごとの入力設定 とする。
• 入力セクション / ステップ別ルール という見出しは通常UIでは使わない。
• 承認ステップごとに、表示・編集する項目を直接設定するUIにする。
• 設定できる項目は原則次の3つに絞る。
  • 順番: 承認中入力欄内での表示順。数値入力ではなく上下移動またはドラッグで操作する。
  • 項目: 項目設定で作成済みの項目を名称で選択する。
  • 編集: その承認時に入力・更新できるかどうかのフラグ。
• 必須セクション は通常UIから削除する。
• 必須項目 も通常UIでは原則扱わない。必要性が出た場合は、別途 必須 フラグとして項目行に追加するか、詳細モード要件として再検討する。
• 内部YAMLは既存互換のため workflow_input_control.sections / step_rules へ変換して保存してよい。
• 既存YAMLの sections / step_rules は互換読み込みし、統合UIにマッピングして表示する。
• 複数ワークフローがある場合は、対象ワークフローを明示し、そのワークフロー内の承認ステップに対して入力設定する。

追加受入条件¶

• 通常UIで 入力セクション と ステップ別ルール を別々に理解しなくてよい。
• 承認ごとに、表示順・項目・編集可否を直接設定できる。
• 項目選択はコードではなく項目名を主表示にする。
• 順番は数値入力ではなく、行の並び替えで操作できる。
• 編集ONの項目は、その承認時に入力・更新できる。
• 編集OFFの項目は、その承認時に表示のみ、または非表示にするかを設計で明記する。
• 既存YAMLの workflow_input_control を読み込んでも、既存設定が失われない。

追加方針: 項目別例外 を削除する¶

ユーザー確認により、ワークフロー段階別入力 の 項目別例外 は通常UIから削除する。

現行の 項目別例外 は、入力セクション単位の編集可否を特定項目だけ上書きするための設定である。しかし、段階別入力UIを 承認ごとの入力設定 に統合し、承認ごとに項目単位で 編集 をON/OFFできるようにする方針では、例外設定として分ける必要がない。

• 通常UIから 項目別例外 セクションを削除する。
• 簡単モード・詳細モードともに通常操作では表示しない。
• 承認ごとの入力設定で、項目ごとに 編集 フラグを直接設定できるようにする。
• 既存YAMLの field_rules は互換読み込みする。
• 既存 field_rules がある場合は、統合UIの項目単位の編集フラグへマッピングする。
• 保存時は既存互換のため必要に応じて field_rules へ変換してよいが、利用者には 例外 として見せない。

追加受入条件¶

• 画面上に 項目別例外 という見出しが表示されない。
• 利用者が 入力セクション と 項目別例外 の優先関係を理解しなくてよい。
• 承認ごとの入力設定だけで、項目ごとの編集可否を設定できる。
• 既存YAMLの workflow_input_control.field_rules を読み込んでも、既存設定が失われない。