設計エラーをファイルとIDから追跡する

1. このページで伝える機能

エラーに含まれるファイル名・YAMLパス・定義ID・英語識別名を使い、修正すべき設計情報と参照関係を特定できます。

2. Wagby11で実現できること

2.1 ファイルとYAMLパスで場所を絞る

生成や設計情報の読み込みでエラーになった場合は、最初に元のメッセージとログを保存します。エラーが示すファイルとYAMLパスを確認し、分割されたAppSchemaのどの定義かを特定します。生成済みJavaや出力HTMLだけを書き換えて回避せず、原因となる元の設計情報を直します。

2.2 存在しない参照先と定義の不整合を直す

たとえば顧客の参照先にUnknownCustomerという存在しない英語識別名が指定されていたら、表示名が「顧客」のモデルを探すだけでなく、実際のname_enと主キー項目を照合します。正しい参照先がCustomer、主キーがcustomerIdなら、参照元もその組に直します。

論理型で許可される設定か、参照先の主キーや型と一致するか、相互参照に必要な定義が揃っているかも確認します。画面の表示・入力制御、モデルの入力制約、権限は役割が異なるため、一つの設定だけで代用しないようにします。

2.3 入力チェックは制約IDと文言を分けて追う

入力エラーでは、制約IDから対象の検証を、message_codeからメッセージリソースを追います。同じ文章が複数の項目で使われる場合もあるため、文言だけで原因を決めません。詳細は入力チェックメッセージを参照してください。

修正後は設計情報を再検証し、必要な生成・ビルドを行います。構造エラーが消えたことに加えて、代表的な正常値と異常値、対象利用者の画面とAPIで意図どおりになるか確認します。画面に反映されない場合は定義の反映状況も確認します。

3. AIへの指示例

最小限の指示例

生成エラーのログから、どの定義を直せばよいか調べてください。

AIはメッセージ中のファイル・YAMLパス・識別子をたどり、参照先や制約の候補を類推します。元のエラー全文と変更した内容を伝えると、無関係な定義の変更を避けやすくなります。最小限の指示だけで次の詳細例と同じ手順になるとは限りません。

より詳細な指示例

元のエラー全文を保持し、ファイル、YAMLパス、定義ID、name_enから原因の記述を特定してください。参照エラーでは参照元と参照先の実在、主キーと型を照合し、表示名ではなく英語識別名で確認します。
入力チェックでは制約IDとmessage_codeを分けて調べ、構造・画面制御・モデル制約・認可を混同しないでください。Wagby11のguide・referenceの許可された設定を確認し、生成物ではなく元定義への最小限の修正案を提示します。
修正後は再検証・必要な生成とビルド、正常値と異常値、画面とAPIの結果を確認してください。既存のデータ・権限・migration_idは保持します。

4. 編集されるAppSchemaの例

次はCustomerモデルの主キーcustomerIdを参照する正しい定義の抜粋です。実際にはエラーに示されたモデルと項目に合わせます。構文を覚えなくても、期待する参照先とエラー全文をAIへ伝えられます。

# 参照元モデルのattributesの抜粋
- name: 顧客
  name_en: customerId
  type: reference
  fk: { entity: Customer, field: customerId }

制約IDは検証を識別するために維持し、message_codeに対応する文言はメッセージリソースで管理します。エラーを消すためだけに、必須チェックや権限を外す修正にはしません。

5. 参考資料

guide：エラーメッセージ索引

designer/docs/appschema/html/guide/appendix/05-error-message-index.html

guide：トラブルシューティング

designer/docs/appschema/html/guide/appendix/04-troubleshooting.html

reference：AppSchema構造のバリデーション

designer/docs/appschema/html/reference/internals/02-schema-validation.html

reference：入力チェック

designer/docs/appschema/html/reference/11-validation.html