先日、OpenAI社から ChatGPT-5 がリリースされました。
特に、コーディング能力が上がったという話なので、今回、GhatGPT-5と共創してフロントエンドアプリケーションを開発してみました。
そこで、今回はChatGPT-5と共創してフロントエンドアプリケーションを開発する方法についてまとめます。
フロントエンドアプリの技術スタック
今回、開発したフロントエンドアプリの技術スタックは次のようになります。
- 言語
JavaScript - フレームワーク
React - ライブラリ
- ルーティング
react-router-dom （React Router v6） - UIコンポーネント
- @mui/material
- @mui/icons-material
- @emotion/react
- @emotion/styled
- 国際化（i18n）
react-intl
それから、ここで開発するフロントエンドアプリケーションですが、APIを介してマイクロサービスが管理する法人顧客データにアクセスするという構成になっています。
ここでは、法人顧客を管理するためのフロントエンドアプリケーションを法人顧客管理アプリケーション、法人顧客を管理するためのマイクロサービスを法人顧客管理サービス、法人顧客管理アプリケーションと法人顧客管理サービスをあわせて法人顧客管理システムと呼びます。
なので、法人顧客管理アプリケーションを開発する前提として、法人顧客管理サービスが既に開発されており利用できる状態になっていることが前提になります。
フロントエンドアプリの仕様の定義
フロントエンドアプリの仕様の定義は、次のように進めます。
- フロントエンドアプリの仕様を定義する
どのように仕様を定義するかも含めてGPT-5と決めていきます（共創）。 - その内容でアプリのソースコード、および、必要な定義ファイル一式を生成するようにGPT-5に指示する
- GPT-5が生成したソースコード一式を実行してアプリを起動し、それが仕様通りになっているか検証する
- 不具合があれば、次回から不具合がでないように仕様を改善する
このプロセスを、フロントエンドアプリが不具合なく実行されるまで繰り返し、フロントエンドアプリの仕様を完成させます。
今回定義したフロントエンドアプリの仕様の構成は次のようになります。- アプリケーション名
法人顧客管理システム - プロジェクトの目的
「本プロジェクトでは、これらのサーバーから API を介してデータをやりとりする React フロントエンドアプリケーション（JavaScript） を構築します」などプロジェクトの目的を記述します。 - 技術スタック
- 言語
JavaScript - フレームワーク
React - ライブラリ
- ルーティング
react-router-dom （React Router v6） - UIコンポーネント
- @mui/material
- @mui/icons-material
- @emotion/react
- @emotion/styled
- 国際化（i18n）
react-intl
- ルーティング
- 言語
- GPTに生成してほしい成果物
ソースコードや必要な定義ファイル一式を生成してくZipに固めてください。
npm install 一発で導入可能なように、package.json に依存関係を含めてください。
さらに以下を満たしてください：
•src/setupProxy.js を含めること。
•npm install → npm start でアプリが起動し、サーバー API と通信できる状態にしてください。 - 共通仕様
ここでは、個々のAPIや画面に共通する仕様について次のような観点で記述します。- 基本設定
ここでは、ロケール、タイムゾーン、認証などアプリケーションの基本的な設定事項について記述します。 - 国際化
ここでは、国際化(i18n）に関する指示について記述します。 - API 通信（プロキシ設定）
ここでは、APIを発行するドメインに対するプロキシに関する指示について記述します。 - ルーティング
ここでは、ルーティングや、ナビゲーション規約に関する指示について記述します。 - バリデーション
ここでは、次のような観点でバリデーションに関する指示について記述します。- 入力保持
- 検証タイミング
- テーブル／ページネーション
- 国際化
- エラー表示
- 数値/文字入力
- 送信前の正規化（submit時）
- 日本語入力フィールド
- サーバー側バリデーション
- エラーレスポンス仕様
- UI/UX
ここでは、次のような観点でUI/UXに関する指示について記述します。- レイアウト
- 一貫したスタイル
- テーブル／ページネーション
- 国際化
- アクセシビリティ
- レスポンシブ
- 余白・見出し
- 通知
- 画面関連
- 基本設定
- API仕様
ここでは、サーバーのAPIの仕様について次のような観点で記述します。 - 画面仕様
ここでは、画面の仕様について次のような観点で記述します。- 画面キー
他の場所で使うために画面キーを定めます。 - 画面タイトル
画面に表示する画面タイトルを記述します。 - 目的
一覧表示など、画面の目的を記述します。 - 関連API
画面に関連する上記サーバーAPIのタイトルを記述します。 - 遷移
例えば、戻るボタンを押下するとどの画面に遷移するのかなど画面遷移を記述します。
遷移先の画面には画面タイトルを記述します。 - 画面項目
画面の項目を記述します。
その際、入力フィールドか表示フィールドか明示します。
それから、
支払方法（必須、プルダウン：銀行/クレジットカード、デフォルト=銀行）
※実際にシステムに渡す値は、銀行の場合、BANK_ACCOUNT、クレジットカードの場合、CREDIT_CARD
のように、選択の場合、表示される値と実際にシステムに渡す値を明示します。
また、
銀行コード（必須、テキスト入力、数字4桁）
のように、バリデーションに関する情報も明示するようにします。
- 画面キー
- ルーティング
モデルドリブン開発
「モデルを中心にシステム開発を行い、モデルから自動的に実装を生成する世界」を目指して提唱された考え方にMDA（Model-Driven Architecture：モデル駆動アーキテクチャ）があります。
具体的には、PSM（Platform Specific Model）まで創れば、それに基づいて自動的にソースコードやデータベースのスキーマが生成されるというものです。
MDAは、2001年にOMG(Object Management Group)によって提唱されたものですが、当時の技術では、事実上、それを実現することはできませんでした。
しかし、2025年の現在、生成AIの目覚ましい進歩によって、ようやくMDAの目指した世界が実現できるようになりました。
ここでは、今回、実際に行った、モデルをベースに自動的にソースコードを生成してシステムを開発するモデルドリブン開発の流れについて説明します。
MDAのCIM、PIM、PSMは、ビジネスストラクチャマトリクスの型、種類、実例に対応します。
それでは、ビジネスストラクチャマトリクスも参照しながら、CIM、PIM、PSMの順で、法人顧客管理システムを開発する流れを見ていきましょう。
CIMの設計
MDAでは、CIM（Computation Independent Model）を計算機処理に依存しないモデルと位置づけています。
つまり、CIMは業務をモデル化してもので、それを実現するシステムに依存しません。
なので、技術の進歩によって、CIMの実現手段であるシステムが置き換わっても、業務の本質を表すCIMが変わることはありません。
さて、CIMはビジネスストラクチャマトリクスでいうと「型」の部分になります。
ビジネスストラクチャマトリクスの縦軸でいうと、システム開発で関係するのは、アプリケーション、データ、ITの部分になります。
なので、CIMは、アプリケーションタイプ、データタイプ、ITタイプということになります。
なお、エンタープライズアーキテクチャでいうと、それぞれ、アプリケーションアーキテクチャ、データアーキテクチャ、テクノロジーアーキテクチャになります。
ここでは、IT基盤は除外して、アプリケーション、データの部分を対象にして説明します。
一つひとつ見ていきましょう。
データタイプの設計
データタイプは、概念レベルのデータで、データタイプの構造が概念データモデル、あるいは、概念レベルのドメインモデルになります。
下図は、UMLのクラス図で描いた法人顧客のドメインモデルです。
このドメインモデルを見ると、このビジネスでは、次のような観点で法人顧客を管理することがわかります。
- 法人番号を持つ法人をベースに法人顧客を管理する。
- 国税庁が管理する13桁の法人番号や、全世界の企業を一意に識別できる9桁のDUNSナンバーを法人番号の候補として考えることができます。
- 法人は、関連会社の関係もわかるようにする。
- 法人顧客ごとに複数の顧客担当者を定義できるようにする。
- 法人顧客ごとに複数、支払手段を設定できるようにする。
- 同じ法人顧客でも、契約先、出荷先、請求先など役割の違いが識別できるようにする。
- すでに取引がある顧客かまだ取引がない潜在的な顧客かなど顧客のステータスが識別できるようにする。
- 例えば、業種、規模、地域など様々な切り口で法人顧客を分類できるようにする。
本ドメインモデルは、業務の概念構造を表したもので、システムでどう実現されるかは考慮されていません。
なので、ドメインモデルを構成する各エンティティがリレーショナルデータベースのテーブルとして実現される場合もあれば、非構造化データの文書として実現される場合もあります。
次に、下図は、法人顧客の概念データモデルの法人顧客エンティティのライフサイクルを分析したステートマシンです。
これをみると、次のことがわかります。
- 未登録の状態の顧客は、登録されることによって未取引の状態になり、取引開始によって取引中状態になる。
- また、取引停止によっって停止中状態になり、取引終了によって取引終了状態になる。
- それから、未登録の状態の顧客を登録することで、取引中にすることもできるし、取引中の顧客を取引終了にすることもできる。
- 逆に、取引停止中の顧客の取引を再開することもできるし、取引中の顧客の取引を取消すこともできる。
- また、未取引中と取引中の顧客のみ、顧客情報を変更することができる。
- なお、顧客情報を変更する一環として、顧客担当者と支払方法を設定することができる。
顧客担当者は、未取引中と取引中の顧客に対して設定できるが、支払方法は、取引中の顧客でないと設定することができない。
法人顧客は、ドメイン駆動設計の集約ですが、集約のライフサイクルを分析することで、適切なユースケースやドメインロジックを抽出することができます。
例えば、上記例であれば、「取引停止」や「取引再開」など状態を変化させる操作がユースケースになります。
また、「未登録の状態でなければ顧客登録はできない」といったドメインの制約が、状態遷移の中で自然に見えてきます。
アプリケーションタイプの設計
次に、アプリケーションタイプですが、これは、概念レベルの本質的な（製品や技術に左右されない）アプリケーションの型で、ビジネスアーキテクチャの一つ、ジョブを支援する役割を表します。
システム開発するときは、まず、ビジネスアーキテクチャのビジネスプロセスから、アプリケーションタイプのユースケースを洗い出します。
下図は、産業機械を製造、販売する会社のバリューチェーンの例です。
このバリューチェーンを見ると、顧客管理の主なプロセスは、「顧客の獲得」、「顧客の活性化」、「顧客の維持」、「顧客の処分」であることがわかります。
これから、法人顧客管理システム（アプリケーションタイプ）の主なユースケースは次のようになると考えられます。
このユースケースは、ビジネスプロセスを構成するアクション、あるいは、顧客管理者というジョブのタスクと同義であり、システムでどう実現されるかは考慮されていません。
なので、このユースケースが業務パッケージの機能として実現される場合もあれば、スクラッチ開発のシステムの機能として実現される場合もあります。
さらに、上述した法人顧客エンティティのライフサイクルを考えると、 顧客の登録、顧客情報の変更、顧客の取引終了ユースケースだけでなく、業務上、次のようなユースケースがあることがわかります。
なお、ここでは、顧客担当者の設定ユースケースと支払方法を設定ユースケースは、顧客情報の変更ユースケースを拡張した形にしています。
さらに、顧客をさまざまな分析軸で分類することがあると考え、顧客情報の変更ユースケースの一環として、顧客の分類ユースケースを追加しています。
PIMの設計
MDAでは、PIM（Platform Independent Model）をIT基盤に依存しないモデルと位置づけています。
つまり、PIMはシステムをモデル化しものですが、業務を実現するシステムの論理的な仕組を表したものでもので、それを実装するIT基盤に依存しません。
なので、技術の進歩によって、PIMの実装手段であるIT基盤が置き換わっても、システムの論理的な仕組を表すPIMが変わることはありません。
さて、PIMはビジネスストラクチャマトリクスでいうと「種類」の部分になります。
なので、PIMは、アプリケーションカテゴリ、データカテゴリということになります。
ここでは、PIMの設計を、アプリケーションアーキテクチャの設計の流れで見ていきましょう。
ここでは、アプリケーション戦略によってマイクロサービスアーキテクチャが適用されたことを前提とします。
そして、法人顧客を管理するためのフロントエンドアプリケーションを法人顧客管理アプリケーション、法人顧客を管理するためのマイクロサービスを法人顧客管理サービス、法人顧客管理アプリケーションと法人顧客管理サービスをあわせて法人顧客管理システムと呼ぶことにします。
要件定義
法人顧客管理システムの要件定義は次のような構成になります。
- 機能要件の定義
ここでは、「システムのユーザーがシステムをどう使うか」という視点でユースケースを分析して、CIMの法人顧客管理システム（アプリケーションタイプ）のユースケースを、PIMの法人顧客管理システム（アプリケーションカテゴリ）のユースケースに展開します。 - 非機能要件の定義
- データ要件の定義
ここでは、ドメイン駆動設計の考えか方を適用して、CIMの、法人顧客の概念レベルのドメインモデルを、PIMの論理レベルのドメインモデルに展開します。 - 品質要件の定義
ここでは、法人顧客管理システムのシステム品質に関する要件を定義します。 - 制約条件の定義
ここでは、法人顧客管理システムを開発する上で満たすべき制約があれば定義します。
- データ要件の定義
法人顧客管理システムの機能要件
これまでは、業務的視点でユースケースを考えてきましたが、ここで、「システムのユーザーがシステムをどう使うか」という視点でユースケースを分析し、さらに洗練させてみましょう。
次の図は、システムの視点でユースケースを洗練したモデルです。
これを見ると、顧客情報の照会ユースケースが起点となって、顧客情報の変更ユースケース、顧客担当者の設定ユースケース、顧客の分類ユースケース、支払方法を設定ユースケースが拡張されていることがわかります。
また、顧客との取引開始や取引停止など顧客の状態変化をともなうものは、顧客のステータスの変更と考え、顧客取引の変更ユースケースとして汎化し、顧客情報の変更ユースケースに包含させています。
それから、顧客情報の照会ユースケースと顧客の登録ユースケースは、ともに、顧客一覧の照会ユースケースから派生することがわかります。
法人顧客管理システムのデータ要件
ドメイン駆動設計の考えか方を適用して、CIMの、法人顧客の概念レベルのドメインモデルを、PIMの論理レベルのドメインモデルに展開すると下図のようになります。
まず、ドメイン駆動設計の考えか方を適用して、概念レベルのドメインモデルを構成しているエンティティが、集約なのか、エンティティなのか、値オブジェクトなのか、列挙型なのか識別されていることがわかります。
また、住所や電話番号、電子メールなど、これまでエンティティの属性として定義されていた要素が列挙型として抽出されていることもわかります。
このPIMの論理レベルのドメインモデルは、マイクロサービスのドメインオブジェクトとして実装されます。
また、フロントエンドアプリケーションを設計するときは、各エンティティの属性のうち画面で設定すべきものが、漏れなく、画面の項目として定義されている必要があります。
ユースケースの設計
ここでは、以下を実施します。
- 画面構成の設計
機能要件として定義されたユースケースを実現する画面の全体構成を設計します。 - 画面遷移の設計
個々のユースケース単位に画面遷移を設計します。
法人顧客管理システムの画面構成
下図は、法人顧客管理システムの画面構成になります。
画面構成を設計するときは、個々の画面の画面項目も定義します。
画面項目を定義するときは、論理レベルのドメインモデルを構成する各エンティティの属性で表示されるものが、漏れなく、画面の項目として定義されている必要があります。
画面項目は、上述した画面仕様の画面項目を定義するとき参考になります。
下記は、法人顧客一覧画面の画面項目になります。
- 条件領域
- 法人顧客名
- 顧客役割（選択）
- 顧客ステータス（選択）
- 法人名
- 法人番号
- ダンズナンバー
- 検索（ボタン）
- 追加（ボタン）
- 一覧領域
- 法人顧客名
- 顧客住所
- 郵便番号
- 国
- 都道府県
- 市区町村
- 町域・番地
- 顧客役割
- 顧客ステータス
- 法人名
- 法人番号
- ダンズナンバー
- 法人住所
- 郵便番号
- 国
- 都道府県
- 市区町村
- 町域・番地
- 行数（ページネーションの行数指定）
- 次（ボタン）
法人顧客管理システムの画面遷移
次の図は、UMLのステートマシン図で描いた「顧客の登録」ユースケースの画面遷移です。
その際、例えば、
顧客登録したときは、API「corporate_customer_registration」を呼び、登録後、API「search_customers_page」を呼ぶ。
キャンセルしたときは、API「search_customers_page」を呼ぶ。
などのように、各画面遷移ごとに関連するAPIを定義します。
マイクロサービス側では、それを参考にして、以下のアプリケーション連携モデルの設計、ユースケースの実現性検証を行います。
画面遷移は、上述した画面仕様の「遷移」を定義するとき参考になります。
アプリケーション連携モデルの設計
ここでは、下図のようにフロントエンドアプリケーションとマイクロサービスの連携の流れを設計します。
これを見ると、次のことがわかります。
- 法人顧客管理サービスは、法人顧客を登録する際、法人情報を法人管理サービスに連携する。
- 法人顧客管理サービスは、外部の郵便番号データ配信サービスを利用して住所情報を検証する。
- 法人管理サービスは、国税庁の法人番号システムから法人情報を取得する。
- 法人顧客管理サービスは、ActiveMQと非同期メッセージングを行う。
ここでは、非同期メッセージングによって次の送受信を行うことを想定しています。- 支払方法が使用されたというメッセージの受信
- 顧客担当者が使用されたというメッセージの受信
- 法人顧客が使用されたというメッセージの受信
- 支払方法が追加されたというメッセージの送信
- 支払方法が無効化されたというメッセージの送信
- 支払方法が有効化されたというメッセージの送信
- 顧客担当者が追加されたというメッセージの送信
- 顧客担当者が無効化されたというメッセージの送信
- 顧客担当者が有効化されたというメッセージの送信
- 法人顧客が変更されたというメッセージの送信
ユースケースの実現性検証
最後に、下図のようにフロントエンドアプリケーションとマイクロサービスの連携によって各ユースケースが実現できるか検証します。
これは、UMLのシーケンス図でユースケースの実現性を検証した例です。
各マイクロサービスに対するメッセージが、そのマイクロサービスが実現すべきAPIになります。
これは、上記アプリケーション連携モデルの構成で、「顧客の登録」ユースケースが実現できるか検証している例です。
これを見ると、次のことがわかります。
- 法人顧客管理サービスは、法人顧客を登録する際、法人情報を法人管理サービスに登録する。
- その際、法人管理サービスは、国税庁の法人番号システムから法人情報を取得して法人情報を検証する。
- また、法人顧客管理サービスは、外部の郵便番号データ配信サービスを利用して住所情報を検証する。
PSMの設計および実装
PIMの設計結果に基づいて、以下の順で法人顧客システムを開発します。
法人管理サービスの開発
次の順で法人管理サービスを開発します。
- 外部設計
ユースケースの実現性検証に基づいて、法人管理サービスのAPI仕様を定義します。 - 内部設計
外部設計で定義されたAPIを、法人管理サービスを構成するコントローラー、アプリケーションサービス、ドメインオブジェクト、リポジトリなどのモジュールがどう実現するか設計します。 - 実装・テスト
内部設計の結果に基づいて、法人管理サービスを実装、テストします。
コントローラを実装するときは、OpenAPIに対応させるようにします。
詳細は、OpenAPI対応を参照してください。
OpenAPI対応すると、次のURLでAPIの仕様が確認できるようになるので、それに従って、上述したAPI仕様の内容を記述するようにします。
http://your-domain/swagger-ui.html
法人管理アプリケーションの開発
次の順で法人管理アプリケーションを開発します。
- 法人管理アプリケーションの仕様の定義
上述した、フロントエンドアプリ仕様の定義のプロセスに従って、法人管理アプリケーションの仕様を定義します。 - 法人管理アプリケーションのテスト
法人管理アプリケーションの仕様に基づいて生成AIが実装した法人管理アプリケーションの妥当性を検証します。
以下は、GPT-5が自動生成した法人管理アプリケーションの画面になります。
【法人顧客一覧画面】
ロケールをEnglishにすると次のようになります。
【法人顧客登録画面】
【法人顧客詳細画面】
【法人顧客更新画面】
【法人顧客分類一覧画面】
【法人顧客分類画面】
【法人顧客分類削除画面】
【支払方法選択画面】
【支払方法一覧画面】
銀行の場合
クレジットカードの場合
【支払方法登録画面】
【支払方法編集画面】
【顧客担当者一覧画面】
【顧客担当者登録画面】
【顧客担当者編集画面】
なお、AIベースのオンライン開発環境、Replitに同じ仕様を提示してアプリを生成してもらうと次の図のようになります。
【法人顧客一覧画面】
【法人顧客詳細画面】
このように、一度、フロントエンドアプリの仕様を作成しておけば、様々な開発環境で使うことができます。
