標準機能とカスタマイズの境界

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

Wagby11では、データの構造や画面、権限などをAppSchemaへ定義し、アプリケーションに必要な成果物を生成します。標準機能とは、このように製品が用意する設定や式を使って実現できる機能です。項目の追加、必須チェック、画面の並べ替えなどは、まず標準機能で対応できるかを確認します。

標準の設定では表せない業務判断や独自の処理が必要な場合は、Javaなどによるカスタマイズを検討します。利用者が最初からJavaを書く必要はありません。「いつ、どの条件で、何をしたいか」をAIへ伝え、実現方法と確認すべき点を整理してもらいます。

2. Wagby11で実現できること

2.1 まず標準の設定と式で表せるかを確認する

「自分の業務に固有の条件」でも、標準設定の組み合わせで実現できる場合があります。例えば、金額を数量と単価から求めること、所属部門のデータだけを見せることは、それぞれ計算・データスコープで表現できます。

標準の式も、製品で定められた構文・関数・参照範囲で使います。例えば、初期値の式はフォームを開くときの設定です。画面を経由しない登録でも必ず値を求めたい場合は、保存時計算など、すべての入口に必要な処理を行う仕組みを選びます。

2.2 足りない処理を決められた接続口へ追加する

例えば「受注を保存するとき、顧客の現在の取引停止状態をDBから調べ、停止中なら受注を拒否する」という業務判断は、カスタム検証として実装できます。また「受注の登録に合わせて、別モデルへ独自の履歴を作る」といった処理には、保存前後の業務処理を検討します。

Javaで処理を加える接続口をSPIと呼びます。値の計算、保存前の検証、保存前後の処理など、目的ごとに「いつ呼ばれるか」「どの情報を受け取り、何を返すか」が決まっています。その約束に合う接続口を使い、必要な処理を追加します。

AppSchemaのrulesは、処理の仕様を記録する定義です。実行する契機・条件・処理内容を整理できますが、文章を書くだけで任意の処理が動くわけではありません。対応するJava実装が必要です。利用できるSPIで要件を満たせない場合は、処理の分け方や別の連携方法を検討します。

2.3 画面も標準機能から順に検討する

画面は、まず登録・検索・詳細などの標準画面を使います。次に、親子同時編集やカレンダーなどの標準機能、レイアウト設定、画面アクションを組み合わせて、業務の操作を表せるか確認します。

ボタンを追加したい場合も、画面アクションで画面遷移・条件・確認メッセージなどを設定できるかを先に調べます。既存の処理へ接続する設定と、そのボタンから呼ぶ新しい業務処理を実装することは別です。

guideでは、標準画面・標準の高機能画面、画面アクションと所定の配置場所、登録済みの処理を呼ぶ仕組みの順に確認し、それでも表せない画面をカスタムページとして定義する方針です。カスタムページでは、画面の実装に加え、権限、入力チェック、画面遷移、エラー処理も標準画面と整合させます。AppSchemaへページの識別子を指定するだけで、独自画面の中身まで完成するものではありません。

2.4 定義・実装・確認を順に進める

Java拡張では、最初の指示でAppSchemaの仕様を確認し、次の指示でその仕様に対応するJava実装を作ります。生成ソースを直接書き換えず、カスタマイズ用の場所へ実装を置きます。配置と再生成時の扱いは生成ソースの位置とパッケージ構成を参照してください。

2.5 依頼する前に業務上の条件を整理する

標準機能か拡張かを選ぶ前に、次の内容を具体的にすると判断しやすくなります。

• いつ行うか：画面を開いたとき、保存するとき、保存処理の後など。
• 何を参照するか：入力中の値、保存済みの値、関連モデル、ログオン利用者、外部システムなど。
• どこから使うか：PC画面、モバイル画面、REST API、アップロードなど。
• 失敗したらどうするか：保存を止めるか、警告を出すか、関連する変更も取り消すか。

画面だけで入力を制限しても、APIやアップロードから同じ条件を保証できるとは限りません。独自処理でも権限と入力チェックを保ち、条件に合う場合と合わない場合をテストします。メール送信や外部APIへの依頼は、DB更新の取り消しだけでは元に戻せないため、実行時点・失敗時の再試行も設計します。

3. AIへの指示例

最小限の指示例

受注を保存するとき、取引停止中の顧客なら保存を止めたいです。既存の定義を確認し、標準機能でできるか、Java拡張が必要かを説明してください。

AIはモデルや項目、保存時の検証方法を確認し、未指定の部分を類推して補います。ただし、登録と更新の両方で確認するか、どの項目にエラーを出すかなどは、この指示だけでは確定しません。業務上必要な条件を追加して仕様を確認します。

より詳細な指示例

1回目：実現方法を判断し、仕様を定義する

受注の登録と更新で、参照する顧客の現在の取引停止フラグをDBから確認し、停止中なら保存を拒否したいです。更新時に顧客を選び直さなくても確認し、画面・REST API・アップロードで同じ条件を保証したいです。
既存モデルと標準の入力チェックを確認し、実現方法を説明してください。Java拡張が必要なら、使うSPIと処理のタイミングを説明し、まずAppSchemaの検証定義とruleを用意してください。エラーは顧客の項目へ「取引停止中の顧客は指定できません。」と表示します。既存の必須・参照チェックは保持します。この段階ではJava実装は作らないでください。

2回目：確認した仕様を実装する

確認した検証定義とruleに対応するJava実装を、目的に合うSPIで作成してください。生成ソースは直接変更せず、カスタマイズ用の場所へ配置してください。取引可能・取引停止の顧客、登録・更新、顧客を変えない更新を含め、利用する各入口で検証が働くことをテストしてください。

具体的な定義と実装の進め方は、標準チェックで表せない検証を追加するで説明します。

4. 編集されるAppSchemaの例

AppSchemaは、AIが仕様を反映する設計情報です。構文を覚えるより、どの要望が標準設定になり、どの部分にJava実装が必要かを確認します。

5. 参考資料

• 標準画面 — designer/docs/appschema/html/guide/07-screens/01-standard-screens.html
• カスタム検証 — designer/docs/appschema/html/guide/04-validation/11-custom-validation.html
• カスタムページ — designer/docs/appschema/html/guide/07-screens/13-custom-pages.html
• rules（業務ルール） — designer/docs/appschema/html/reference/08-rules.html
• ui（画面UI定義） — designer/docs/appschema/html/reference/10-ui.html
• 式言語 — designer/docs/appschema/html/reference/16-expression-language.html