アプリケーション情報と初期サンプルを整理する

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

業務アプリケーションを作り始めるときに、アプリケーション全体の名前・概要・管理主体と、ログオン画面の案内を整えます。あわせて、初期設定に含まれるサンプルのロール、モデル、メニュー、文面を確認し、業務で使うものを決めます。

ここでは「顧客・商品管理」を例にします。顧客や商品はそれぞれのモデルですが、システム名はそれらをまとめたアプリケーション全体の名前です。モデルや項目を追加する方法は、次の最初のアプリケーションを作るで説明します。

2. Wagby11で実現できること

2.1 アプリケーションの名前と説明を整える

ルートのAppSchemaに、アプリケーション全体の情報を設定します。管理者は、ログオン後に「システム → システム運用 → このアプリケーションについて」を開き、設定した内容を確認できます。

2.2 ログオン画面を業務に合わせる

ログオン画面の見出しにはシステム名を使います。英語表示では英語名を使います。副題には「顧客と商品の情報を共有します」と表示し、利用者がどの業務アプリケーションへ入るかを確認できるようにしました。

ロゴと背景画像には、利用する画像を用意して指定します。設定の文字列だけでなく、画像の中に描かれたサンプルの名前も確認してください。ロゴの代替テキストには、その画像が表す名前を付けます。代替テキストを変えても、画像そのものの文字は変わりません。

2.3 初期サンプルを使うものと使わないものに分ける

既存の設定を確認してから、不要なサンプルを整理します。すでに業務向けに整っている設定は、そのまま使えます。初期の設計情報全体を削除する必要はありません。

システムモデルと必要な管理ロールは保持します。不要な業務モデルを外す場合も、他の定義から参照されていないかを確認します。定義を削除することと、保存済みのDBデータや実行時のロールを整理することは別に考えます。

2.4 変更を反映し、利用者ごとに確認する

1. 設計情報を検証し、コード生成と必要なビルドを行います。
2. REST APIとWeb UIを再起動し、ログオン画面の名前・副題・画像を確認します。
3. 管理者でアプリケーション情報と管理メニューを確認します。
4. 業務の利用者でログオンし、必要なメニューから既存データを参照できることと、許可した操作だけが使えることを確認します。
5. 操作マニュアルの名称・案内も更新し、画面と一致することを確認します。

画面を再読み込みするだけで、起動済みサーバーの定義が更新されるわけではありません。生成・起動の進め方は手動で生成・起動する場合も参照できます。

3. AIへの指示例

最小限の指示例

顧客・商品管理として使うので、アプリケーション情報とログオン画面を整え、不要な初期サンプルがないか確認してください。

AIは英語名、概要、副題、画像の扱い、サンプルを見直す範囲などを、既存の定義と業務の説明から類推して補います。管理する部署や、残したい機能・利用者が分かっている場合は具体的に伝えます。この短い指示だけで、以下の詳細例と同じ設定になるとは限りません。

より詳細な指示例

このWagby11のREADME.md、HOWTODEV.mdとAppSchemaのguide・必要なreferenceを確認してください。
既存の顧客・商品管理を保持し、アプリケーション全体の情報とログオン画面を整えてください。

・システム名は「顧客・商品管理」、英語名はCustomerProductManagementにしてください。
・概要は「顧客の連絡先と商品情報を管理するアプリケーション。」、管理主体は「営業企画部」にしてください。
・作成日・更新日時と、今回の設定内容の変更履歴を記録してください。
・副題は「顧客と商品の情報を共有します」にしてください。
・ロゴは顧客・商品管理の業務用画像とし、代替テキストも「顧客・商品管理」にしてください。
・背景は入力内容を読み取りやすい淡い画像にしてください。画像内にも不要なサンプル名がないことを確認してください。
・サンプルのロール、モデル、メニュー、表示文言、初期データ、ワークフローのコメント、メール文面と予約IDの使用状況を調べてください。
・G_STANDARD（標準ユーザ）は通常のアプリケーション利用者に標準で付与する初期ロールとして保持し、モデルの権限、メニューの認可、利用者への割り当てが業務に合っているか確認してください。
・不要と判断した設定を整理する場合は、関連する定義との整合性を保ち、変更した内容と残した理由を説明してください。
・システムモデル、必要な管理ロール、既存の業務モデル・主キー・データを保持してください。

設計情報の検証・コード生成・必要なビルド後、REST APIとWeb UIを再起動してください。
ログオン画面、管理者のアプリケーション情報、管理メニュー、業務利用者のメニューと操作権限を確認してください。
操作マニュアルの案内も更新し、変更したファイルと確認結果を説明してください。

4. 編集されるAppSchemaの例

以下はルートのdesigner/repository/appschema.yamlへ設定する内容の抜粋です。既存の環境設定・ロール・モデル等を保持して、対象の部分を変更します。利用者は構文を覚えなくても、アプリケーションの名前、管理する部署、画面で伝えたい案内をAIへ指示できます。

description:
  system_name: 顧客・商品管理
  system_name_en: CustomerProductManagement
  overview: 顧客の連絡先と商品情報を管理するアプリケーション。
  owner: 営業企画部
  version: '1.0'
  created_at: '2026-10-31'
  updated_at: '2026-10-31T09:30:00+09:00'
  history:
    - version: '1.0'
      date: '2026-10-31'
      author: 営業企画部
      comment: 利用開始に向けてアプリケーション情報を設定

environment:
  login:
    position: center
    subtitle: 顧客と商品の情報を共有します
    logo: /images/customer-product-logo.svg
    logo_alt: 顧客・商品管理
    background_image: /images/customer-product-background.svg

description.versionは、作成する業務アプリケーション自身の管理番号です。日付や履歴も、そのアプリケーションの実際の内容に合わせます。logoとbackground_imageには、用意した画像へのパスを指定します。

この例の画像はWeb UIのsrc/main/resources/static/imagesへ配置し、/images/ファイル名で指定しています。画像ファイルそのものも管理対象に含めます。サンプルの整理対象はリポジトリごとに異なるため、ここではロールやモデルを一括削除する定義例は掲載していません。

5. 参考資料

guide：最小アプリケーション構成

designer/docs/appschema/html/guide/01-project/03-minimum-application.html

guide：モデルを作成する

designer/docs/appschema/html/guide/03-model/01-create-model.html

reference：AppSchema全体構成

designer/docs/appschema/html/reference/02-root-schema.html

reference：共通ロール定義

designer/docs/appschema/html/reference/04-roles.html

reference：permissions（CRUD権限定義）

designer/docs/appschema/html/reference/07-permissions.html