期待と現実:GPT4のマルチモーダル機能を使ってみた所感
はじめに
こんにちは、DAAEの栗山です。
今回はGPT4のマルチモーダル機能を使ってみた所感をまとめます。画面項目の画像を作成し、それを読み込ませてコードを出力したり、画面項目の画像の説明をさせたりしました。最後にその所感を記します。
画面項目の画像からReactのコードを生成する
「新規ユーザー登録」画面の画像を作成し、それを入力し、Reactのコードを作成してみました。
プロンプト(画像+命令)
プロンプトのテキスト部分
これは新規ユーザー登録機能で、ユーザー情報を入力する画面です。
この画面のコードをReact + tailwindで書いてください。
出力結果の一部
出力結果を実行した結果
結果まとめ
入力した画像を実現するコードは出力されませんでした(基本的なコード例が出力されました)。実行してみたところ、画面項目が足りません。
このような出力を得るのであれば「テキストでの入力」で十分可能です。さらにGPT4ではなく、GPT3.5で十分です。ちょっと残念な結果でした。
画面項目の画像から「項目と機能」を抽出する
画像から直接コードを生成することは難しそうなので、画像の内容を読み取らせることにしました。
先ほどと同じ画像を入力し、プロンプトは変更します。
プロンプト
これはソフトウェアのユーザー登録機能の画面仕様書です。
この画面にある「項目」とその「機能」を洗い出してください。
出力結果
了解しました。画面仕様書の内容を基に「項目」とその「機能」を洗い出します。
### 項目と機能
1. **氏名**
- 機能: ユーザーの氏名を入力するテキストボックス
2. **氏名 (フリガナ)**
- 機能: ユーザーの氏名のフリガナを入力するテキストボックス
3. **性別**
- 機能: ユーザーの性別を選択するラジオボタン
- 男性: 男性を選択
- 女性: 女性を選択
- その他: その他の性別を選択
- 回答しない: 性別の回答をスキップ
4. **生年月日**
- 機能: ユーザーの生年月日を入力するためのテキストボックス
- 年: 誕生年を入力
- 月: 誕生月を入力
- 日: 誕生日を入力
5. **郵便番号(ハイフンなし)**
- 機能: ユーザーの郵便番号をハイフンなしで入力するテキストボックス
- 住所検索: 郵便番号を元に住所を自動で検索するボタン
6. **都道府県**
- 機能: ユーザーの都道府県を入力するテキストボックス
7. **市区町村**
- 機能: ユーザーの市区町村を入力するテキストボックス
8. **番地**
- 機能: ユーザーの番地を入力するテキストボックス
9. **建物名・部屋番号**
- 機能: ユーザーの建物名や部屋番号を入力するテキストボックス
10. **確認画面へ進む**
- 機能: 入力内容の確認画面へ進むためのボタン
これがソフトウェアのユーザー登録機能の画面仕様書に基づいた項目と機能の洗い出しとなります。
結果まとめ
基本的には、画面に明示的に記載のある内容がテキストで説明されました。
以下の点でミスがありました。
入力した画像では「姓」「名」となっているが、出力では「氏名」と改変された。
「必須」が出力に反映されなかった。
※ちなみに、これに続けて以下のプロンプトを与えることで「必須」についても追記されました。
good, 必須 or 非必須についても考慮し、やり直してください。
抽出した「項目と機能」からコードを生成する
前項で抽出した「項目と機能」からコードを生成しました。この際「項目と機能」を抽出したチャットでは繰り返しエラーが出てしまったので、「項目と機能」をコピーしほかのチャットで実行しました。
プロンプト
以下は画面仕様書から読み取った画面の項目とその機能です。このコードをReact + tailwindで作成してください。
ファイル名:Registration.tsx
### 項目と機能
1. **氏名** - 必須
- 機能: ユーザーの氏名を入力するテキストボックス
2. **氏名 (フリガナ)** - 必須
- 機能: ユーザーの氏名のフリガナを入力するテキストボックス
※省略
9. **建物名・部屋番号** - 非必須
- 機能: ユーザーの建物名や部屋番号を入力するテキストボックス
10. **確認画面へ進む**
- 機能: 入力内容の確認画面へ進むためのボタン
出力結果の実行結果
結果まとめ
「画像をテキストに変換する」というステップを踏んだ結果、画像には存在する、項目の配置情報などが失われました。
この結果では、わざわざ画像で入力するメリットは感じません。「ユーザー登録画面のサンプルコードを書いて。画面項目は~~」といったプロンプトで同様の出力を得られるでしょう。
抽出した「項目と機能」からテストケースを生成する
今度は、抽出した「項目と機能」からコードではなくテストケースを作成してみます。
プロンプト
以下は画面仕様書から読み取った画面の項目とその機能です。この画面のテストケースを作成してください。結果はmarkdownのソースコード形式でください。
### 項目と機能
1. **氏名** - 必須
- 機能: ユーザーの氏名を入力するテキストボックス
2. **氏名 (フリガナ)** - 必須
- 機能: ユーザーの氏名のフリガナを入力するテキストボックス
省略
9. **建物名・部屋番号** - 非必須
- 機能: ユーザーの建物名や部屋番号を入力するテキストボックス
10. **確認画面へ進む**
- 機能: 入力内容の確認画面へ進むためのボタン
結果
※はじめは箇条書きで出力されたので、それをマークダウン形式にするよう指示したものです。
結果まとめ
「項目と機能」で記した内容については、対応するテストケースが作成されました。
しかしながらテストケースとしては不十分です。「最大文字数」や「必須項目が未入力の時のボタン押下時の動作」といった大事なポイントが抜けています。
まとめ(GPT4のマルチモーダル機能ができること)
今回の結果からGPT4のマルチモーダル機能のポイントを列挙します。
シンプルに画像を読み込み、テキストで解説する機能である。
人間のように「画像に明記されていない部分」を読み取る能力はない。
ミスが起こるので精度向上のための工夫が必要(別途OCRなどで文字を読み取って突き合わせるなど)
最後に(所感)
GPT4のマルチモーダル機能は、正直なところ恐れていたほどのインパクトはありませんでした。私は実のところ、これによりエンジニアやテストエンジニアの業務が一変してしまうのではないかと思っていたのです。
現在のところマルチモーダルの機能は「画像で明示的に示された内容をテキストに変換する」ことにとどまっているようです。
「LLMにテキストを入力する」場合は、入力されたテキストから、その背景にある前提や知識を抽出したり、それを出力に利用することが可能ですが、現状のマルチモーダル機能ではそこまでのことはできません。
今後、マルチモーダル機能が発展し、言葉で表現することが難しい情報を直接LLMに与えることが可能になると、画面設計書から直接テストケースを作ったり、コードを出力することが高い精度で可能になるでしょう。そのような未来にはまだ達していないようです。
さて、マルチモーダル機能が大きな技術革新であることは間違いなく、今後はこれを有効活用する方法を模索したいです。
\もっと身近にもっとリアルに!DAAE公式Twitter/
お問合せはお気軽に
SHIFTについて(コーポレートサイト)
https://www.shiftinc.jp/
SHIFTのサービスについて(サービスサイト)
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
PHOTO:UnsplashのIlya Pavlov