前回はシステム現場にAI活用事例として
「クレーム処理」の処理フローをChatGPTを活用して
AIに処理フローを書いてもらい技術進化のリアルに驚きました。

今回は続編で「データ構造」や「仕様書」までをChat GPTに書いていただき
実力を検証したいと思います。

改めて「ChatGPT」に付いて対話型AI(ChatGPT)自身に解説してもらいましょう。

ChatGPTは、OpenAIが開発した大規模言語モデルの1つで、機械学習と深層学習技術を使って
自然言語処理タスクを解決できます。ChatGPTは、言語生成、文章の意味理解、文章の類似度
計算など、多様な言語タスクに対応しています。また、ChatGPTは、トレーニング時に膨大な
量のテキストデータを学習することで、高い言語理解力を持ちます。現在、多数のチャットボ
ットやAIアシスタントの開発に活用されています。ChatGPTは、英語だけでなく、多数の言語
に対応しています。2021年の知識を持っており、さまざまな知識を持つ専門家としての役割も
果たしています。

Chat GPTによるAI解説

それでは早速続きの内容をChatGPT教授に作文を依頼してみます。

ChatGPT教授への質問
「クレーム処理台帳をシステム化するためのDB テーブル構造を作成して」

「回答」以下は、クレーム処理をシステム化するためのDBテーブル構造の例です。

  • 【クレーム情報テーブル】
  • customer_id (PK) : 顧客ID
  • customer_name : 顧客名
  • customer_address : 住所
  • customer_email : メールアドレス
  • customer_phone : 電話番号
    【クレーム情報テーブル】
  • claim_id (PK) : クレームID
  • customer_id (FK) : 顧客ID
  • claim_date : クレーム提出日時
  • claim_content : クレーム内容
    【対応情報テーブル】
  • response_id (PK) : 対応ID
  • claim_id (FK) : クレームID
  • response_date : 対応日時
  • response_content : 対応内容
    【解決情報テーブル】
  • solution_id (PK) : 解決ID
  • response_id (FK) : 対応ID
  • solution_content : 解決内容
    上記のテーブルは、以下のような情報を格納します。
  • 顧客情報テーブル : 顧客の基本情報を格納
  • クレーム情報テーブル : 顧客がクレームを提出した内容を格納
  • 対応情報テーブル : クレームに対する対応内容を格納
  • 解決情報テーブル : 対応内容によって解決された問題の内容を格納
    以上のテーブル構造を用いることで、顧客からのクレーム処理をシステム化することで
    以下のような操作が可能になります。

基本はしっかりとおさえています。
以上をベースにして、詳細項目を追加して行けば良さそうです。
7割方は出来上がっております。恐るべしです。

それではもう一歩進んで「仕様書」まで行けるか、教授に問いかけます。

ChatGPT教授への質問
「以上の内容で仕様書作って」

「回答」

【クレーム処理システム仕様書】
概要

顧客からのクレームを処理するためのシステムです。顧客情報、クレーム情報
対応情報、解決情報を格納し、それぞれの情報を関連付けて管理します。

機能要件

2.1 顧客情報の確認
顧客情報テーブルから、顧客の基本情報を確認することができる。
確認できる情報は、顧客ID、顧客名、住所、電話番号、メールアドレスなど。

2.2 クレーム情報の登録
クレーム情報テーブルに、顧客からのクレーム内容を登録することができる。
登録できる情報は、クレームID、顧客ID、クレームの種類、クレームの内容
クレーム提出日時など。

2.3 クレーム情報の確認
クレーム情報テーブルから、顧客が提出したクレーム内容を確認することができる。
確認できる情報は、クレームID、顧客ID、クレームの種類、クレームの内容
クレーム提出日時など。

2.4 対応情報の登録
対応情報テーブルに、クレームに対する対応内容を登録することができる。
登録できる情報は、対応ID、クレームID、対応内容、対応日時など。

2.5 対応情報の確認
対応情報テーブルから、クレームに対する対応内容を確認することができる。
確認できる情報は、対応ID、クレームID、対応内容、対応日時など。

2.6 解決情報の登録
解決情報テーブルに、対応内容によって解決された問題の内容を登録することができる。
登録できる情報は、解決ID、クレームID、解決内容、解決日時など。

2.7 解決情報の確認
解決情報テーブルから、対応内容によって解決された問題の内容を確認することができる。
確認できる情報は、解決ID、クレームID、解決内容、解決

2.8 クレームの状態管理
クレーム情報テーブルに、クレームの状態を管理するカラムを追加する。
クレームが提出された直後は「未対応」、対応が完了したら「対応済み」
問題が解決されたら「解決済み」とする。

2.9 クレームの検索機能
クレーム情報テーブルから、クレームID、顧客ID、クレームの種類、クレームの状態
クレーム提出日時、解決日時などを条件にして、クレームを検索することができる。

2.10 クレームの更新機能
クレーム情報テーブルのレコードを更新することができる。
更新できる情報は、クレームの種類、クレームの内容、クレームの状態、対応内容
解決内容など。

2.11 クレームの削除機能
クレーム情報テーブルから、クレームIDを指定して、クレームを削除することができる。

4.1 顧客情報テーブル
顧客からのクレームを処理するためのシステムです。顧客情報、クレーム情報
対応情報、解決情報を格納し、それぞれの情報を関連付けて管理します。

機能要件

2.1 顧客情報の確認

顧客情報テーブルから、顧客の基本情報を確認することができる。
確認できる情報は、顧客ID、顧客名、住所、電話番号、メールアドレスなど。

2.2 クレーム情報の登録

クレーム情報テーブルに、顧客からのクレーム内容を登録することができる。
登録できる情報は、クレームID、顧客ID、クレームの種類、クレームの内容
クレーム提出日時など。

2.3 クレーム情報の確認

クレーム情報テーブルから、顧客が提出したクレーム内容を確認することができる。
確認できる情報は、クレームID、顧客ID、クレームの種類、クレームの内容
クレーム提出日時など。

2.4 対応情報の登録

対応情報テーブルに、クレームに対する対応内容を登録することができる。
登録できる情報は、対応ID、クレームID、対応内容、対応日時など。

2.5 対応情報の確認

対応情報テーブルから、クレームに対する対応内容を確認することができる。
確認できる情報は、対応ID、クレームID、対応内容、対応日時など。

2.6 解決情報の登録

解決情報テーブルに、対応内容によって解決された問題の内容を登録することができる。
登録できる情報は、解決ID、クレームID、解決内容、解決日時など。

2.7 解決情報の確認

解決情報テーブルから、対応内容によって解決された問題の内容を確認することができる。
確認できる情報は、解決ID、クレームID、解決内容、解決

2.8 クレームの状態管理

クレーム情報テーブルに、クレームの状態を管理するカラムを追加する。
クレームが提出された直後は「未対応」、対応が完了したら「対応済み」
問題が解決されたら「解決済み」とする。

2.9 クレームの検索機能

クレーム情報テーブルから、クレームID、顧客ID、クレームの種類、クレームの状態
クレーム提出日時、解決日時などを条件にして、クレームを検索することができる。

2.10 クレームの更新機能

クレーム情報テーブルのレコードを更新することができる。
更新できる情報は、クレームの種類、クレームの内容、クレームの状態、対応内容
解決内容など。

2.11 クレームの削除機能

クレーム情報テーブルから、クレームIDを指定して、クレームを削除することができる。

4.1 顧客情報テーブル

ここまで出来れば完璧です。
もちろんAIに任せっぱなしはいけませんが、既に予想を遥かに超えています。
この仕様に画面遷移(画面説明)などを付加すれば出来上がります。

もう一歩進めて「プログラミング」まで出来るか聞いてみましょう。

ChatGPT教授への質問
「以上の内容のプログラムコードを書いて」

「回答」

一般的には、以下のようなステップに沿ってプログラムを作成することができます。
①データベースに接続するためのコードを書く。
②顧客情報テーブル、クレーム情報テーブル、対応情報テーブル、解決情報テーブルを
作成するためのDDLコードを書く。
③各テーブルに対するCRUD操作を行う関数を定義する。
④顧客情報の確認、クレーム情報の登録、クレーム情報の確認、対応情報の登録
対応情報の確認、解決情報の登録、解決情報の確認に必要なビジネスロジックを実装する。
⑤ビジネスロジックを呼び出すAPIエンドポイントを定義する。

ただし、実際に使用するデータベースの種類やプログラミング言語によって
コードの書き方や構造が異なることに注意してください。

流石にコード作成までは無理でしたね
開発言語によっても違って来ますので、これは致し方ないですね。

しかし、次のステップは「作成した仕様書」を元に「ノーコードアプリ」に指示すれば
画面定義、データ構造まで作る事は時間の問題です。

この分野は直ぐに実装出来そうなのは予想はできますね。
この様に既にシステム開発の現場でのイノベーションは起きています。

様々な業務アプリケーション(SaaS製品)も出回っており、既に「アプリの民主化」も
進んでおり、合わせて「開発現場」も変革しております。

数年後には、現場の想定を遥かに超えて来る事は間違いなさそうです。
これからエンジニアやプログラマーを目指す方々も、この辺を抑えて
自身は何を学ぶべきか?何が必要とされるのか?を
しっかりと考えて行く事が必要になります。

ブログ内でも何度も申しておりますが。

システム開発や利活用は目的では無く手段です。
本当の目的はクレーム処理で有れば「台帳管理を合理化」する事では無く
処理手続きの答え(回答)を自動で行う事です。

そうして人間は「クレーム自体の撲滅」が目的です、ここに知恵を使いたいですね。

先ずはAIの進化で、このレベルのシステム開発とこの業務を行う担当者の業務が全て
合理化(無くなる)事が価値になりそうです。

皆で知恵を出し合いましょう。

-PR-