AI に何かを行わせる場合、的確に指示を伝える必要がある。今回は AI に簡単なモデリングをさせることで、評価してみた。
1. サンプル(1) 日本人家族モデルの作成
初めはわざと大雑把な指示を出して、AI から得られた回答を元に修正依頼を出すというやり方を行なった。
初期指示: 「日本人家族を構成するモデルを書いて」
最初の提案として、具体的な家族構成を文章で記述（おじいちゃん、お父さん、長男など）。
修正指示: 「クラス図のような感覚で」
UML風にクラス化（例: おじいちゃんクラス、属性: 年齢=70, 関係: 孫=長男）。
各メンバーに属性と関係性を設定し、家族のつながりを表現。
汎用化: 「もっと汎用的な家族ならどうなる？」
具体性を排除し、高齢世代A, 中年世代A, 若年世代など抽象クラスに変更。
統合: 「ひとまとめで表現できるかな？」
1つの家族メンバー (FamilyMember)クラスに集約。
- 属性: 年齢層 (若年/中年/高齢), 役割 (自由記述)
- 関係: パートナー, 親, 子, 兄弟姉妹（全て自己参照で柔軟対応）
2. サンプル(2) 企業組織モデルの作成
前回のやり取りを踏まえ、指示をある程度細かくしてみた。
初期指示: 「会社（どこにでもある企業）の一般的な組織をUML風で汎用的なモデルに」
- 組織メンバー (OrganizationMember)クラスを提案。
- 属性: 役割, 階層 (上位/中間/下位), 責任
- 関係: 上司, 部下, 同僚, 部署間リンク
- 従業員の扱い: 「この組織には人が存在する、つまり従業員だ。それはどうなる？」
それでも、クラスの分割や統合については人の判断が必要のようだ。AI からはどちらにするのか問い合わせがあった。
2つの選択肢を提案:
- 属性で区別（雇用形態追加）
- 別クラス化（Employeeクラスを分離）
決定（人の判断）: 「従業員を別クラスとして分離が良い」
最終モデル:
- OrganizationMember: 管理者向け（役割, 階層, 従業員への参照）
- Employee: 従業員向け（役割, 雇用状態, スキル, 上司への参照）
- 関係: OrganizationMember が Employeeを管理。
3. 指示のコツ（まとめ）
明確な指示が鍵:「何を（家族/企業）」「どんな形式で（UML風/文章）」「どのくらい具体的に（汎用/詳細）」を伝えると、（現時点の）AI は正確に反応する。
例: 「別クラスにして」「ひとまとめで」は、構造の意図を明確化。
試行錯誤の成果: 具体→汎用、複数クラス→単一クラスなど、柔軟に調整可能。
4. 成果物の特徴
- 家族モデル: 1クラス (FamilyMember) であらゆる家族構成を表現。
- 企業モデル: 2クラス (OrganizationMember, Employee) で管理と従業員を分離、柔軟な組織構造に対応。
共通点: 抽象性と拡張性を持ちつつ、具体例で実用化可能。
5. サンプル(3) 汎用的な小学校モデルの作成
ここまでの結果を踏まえ、詳細を明示しAIにモデルを作成してもらった。
初期指示: 「小学校には、教員と生徒がいます。教員は校長、教頭、主任、一般教員から成り立っています。学校の責任者は校長で、その下に教頭、主任、一般教員という階層になっています。教員には属性として、名前、住所、電話番号（連絡先）、性別、生年月日、担当科目があります。そして、主任、一般教員に限りクラスを持っています。ただ数名クラスを持たない主任、一般教員もいます。 生徒は、1年生から6年生までいます。人クラスは概ね30人から40人程度います。各学年のクラスは３クラスか４クラスです。生徒の属性としては、名前、性別、生年月日、住所、親の連絡先（２つ以上）と親の名前があります。 汎用的な複数クラスとしてUML風に作ってもらえますか？」
汎用的な小学校モデル（UML風）
クラス: 教員 (Teacher)
属性:
- 名前 (Name): 文字列
- 住所 (Address): 文字列
- 電話番号 (PhoneNumber): 文字列（連絡先）
- 性別 (Gender): {男, 女, その他}
- 生年月日 (BirthDate): 日付
- 担当科目 (Subject): 文字列（例: "算数", "国語"）
- 役割 (Role): {校長, 教頭, 主任, 一般教員}（階層を表す）
関係性:
- 上司 (Supervisor): Teacher（0または1、自己参照、校長以外に適用）
- 部下 (Subordinate): Teacher（0～複数、自己参照、校長/教頭/主任に適用）
- 担当クラス (AssignedClass): Class（0～1、主任と一般教員のみ、クラスを持たない場合もあり）
クラス: 生徒 (Student)
属性:
- 名前 (Name): 文字列
- 性別 (Gender): {男, 女, その他}
- 生年月日 (BirthDate): 日付
- 住所 (Address): 文字列
- 親の連絡先 (ParentContacts): 文字列リスト（2つ以上）
- 親の名前 (ParentNames): 文字列リスト（2つ以上）
- 学年 (Grade): {1, 2, 3, 4, 5, 6}
関係性:
- 所属クラス (EnrolledClass): Class（1、必須）
クラス: クラス (Class)
属性:
- クラス名 (ClassName): 文字列（例: "3年A組"）
- 学年 (Grade): {1, 2, 3, 4, 5, 6}
- 定員 (Capacity): 整数（30～40程度）
関係性:
- 担任 (ClassTeacher): Teacher（0または1、主任または一般教員）
- 生徒リスト (Students): Student（30～40、複数）
もっと具体的に支持
下記、お買い物アプリのUML風のクラス図（テキスト）、Java（Spring Boot）、データベース（MySQL）、UI（Angular）を作ってください。Javaのコードにする場合にはDDDを意識してください。データベースはなるべく正規化してください。
- ユーザ（名前、住所、電話番号、email、カード情報）
- (email, password）でログインする
- 商品を一覧から選ぶ
- お買い物かご見て購入する商品、合計金額を確認する
- 商品（商品名、値段、特徴、数量）
- お買い物かご（ユーザ、商品）
結果はここに書かないが、意図しているものと合致した。
オブジェクト思考のような属性と操作（振る舞い）を指定し、何を作らせたいのか構成（クラス図、 DDDを意識したSpring Boot のコード、データベース、Angular や React）も含めれば適した解を AI が与えてくれるかもしれない。構成については AI が作ったものを人間が意識する必要があるかはまた別の議論が必要だ。
属性と操作（振る舞い）か属性とシナリオを定義すれば十分なのか検証してみたいところだ。
