ChatGPTでPoCを作りたい！と言われた時にどこまで作るか、の認識合わせ用メニュー

これは何

ChatGPTでプロトタイプを作成したい（概念検証したい、PoC）と言われた際、実際にはいくつかの段階が存在します。一般的に、エンジニアはこれらの段階を意識して会話を進めますが、要件を提供する側は必ずしもその詳細を把握していないことがあり、双方の理解がすぐに一致しないことがあります

そこで、ChatGPTのPoCでどこまで作るかを６段階のメニューをあらかじめ用意しました

1. ChatGPTのためのプロンプトとシナリオ集（ドキュメント）
2. gpt APIのPlayGroundでの確認
3. script + gpt API
4. gpt API をwrapper APIで包み込む
5. GUIまで用意
6. 内部利用ではなく一般公開する

下に行くほど、できることが増えるますが（Quality 向上！）、インフラコストや開発リードタイムが伸びます（Cost、Delivery 悪化！）

下の方のメニューがゴールの場合でも、いきなり下のメニューを作るのではなく、上のメニューから順番に開発し、それぞれでチェックポイントを設ける開発の仕方が良いと思っています

名称	gptの最低限技術検証	アクセス数制限の緩和	出力の乱数要素を軽減	token数制限の緩和	コピペ作業の自動化	指定フォーマットでのDBやファイルへ保存	認証情報の隠蔽化	監査ログの保存
ChatGPTのためのプロンプトとシナリオ集（ドキュメント）	◯	△*1	X	X	X	X	X	X
gpt APIのplaybookでの確認	◯	◯	◯	◯	X	X	X	X
script + gpt API	◯	◯	◯	◯	◯	◯	X	X
gpt API をwrapper APIで包み込む	◯	◯	◯	◯	◯	◯	◯	◯
GUIまで用意	◯	◯	◯	◯	◯	◯	◯	X *2
内部利用ではなく一般公開する	◯	◯	◯	◯	◯	◯	◯	X *2

*1 ChatGPT plusの契約をすれば多少は緩和されるが、経験的にAPI利用と比べるとだいぶ制限が厳しい
*2 Wrapper APIを叩けば◯

なお、ここではfine tuningについては言及しません。fine tuningなしでもできることはかなり多いです。fine tuning後のモデルを利用する場合はgpt APIを利用するパターンになります

メニュー表

ChatGPTのためのプロンプトとシナリオ集（ドキュメント）

ChatGPTのアプリケーションをそのまま利用するケース。よくブログやTwitterなどで目にするため、成果物のイメージが実はこれであることも多いです

そもそもgptでこの問題を解けるか？の検証がゴールだったらこれで十分なことが多いです

主な成果物は

1. ChatGPTへのプロンプト
2. ChatGPTの出力に合わせて、追加でどのような依頼を行うべきかのシナリオやベストプラクティス集 with プロンプト

図1. ChatGPTのアプリケーションをそのまま利用する例

ChatGPTのアカウントが必要です。また、gpt-4を利用するためには月額20ドルのChatGPT plusを契約する必要があります（2023/04/18 現在）
また、アカウントごとのリクエスト数に制限が厳しめです（利用状況によって変わるらしい）

gpt APIのPlayGroundでの確認

ChatGPTのWebアプリケーションではなく、gpt APIを使うケース。AzureのOpenAIサービスも少し引数や準備が変わるが同じ使い方ができます（コストも一緒）。
ChatGPTのアカウントに対して、API利用登録が必要（アカウント自体は同じものが使える）。18ドルの無償枠も存在するが基本的にクレジットカード情報が必要です。またgpt-4の利用にはwish listに並ぶ必要があります（2023/04/18 現在）

図2 gpt API (Chat)のplayground の画面例

ChatGPTと比べてAPIを利用することで以下のことが新たにできるようになります

1. TempartureやTop Pを指定し、出力の乱数要素を軽減することができる（入力に対して出力が完全に一致するとは限らない）
2. gpt-4以降だと入出力のtoken数制限が緩和できる (プロンプトにデータを入れたい時は特に重宝)。最大で32k (chatGPTは4k。おそらく出力文字数にも制限あり)

Frequency penaltyとPresence penaltyの制御は、実はChatGPTのプロンプトで近いことができてしまうため、ここでは「新たににできること」には含めませんでした
ChatGPTそのまま活用と違い、過去の応答（USERとASSISTANT）を直接引数にできるため、会話の状態を明示的にコントロールしやすい、といったメリットもあります（ChatGPTでもできなくはない）

また、ここで開発したAPIの引数は以下のメニューでそのまま使えるといったメリットもあります

script + gpt API

PythonやJavascriptやshellやVBAなどから gpt のAPIをcall するパターン。httpsのエンドポイントにPOSTリクエストを送るだけなので、Pythonでなくても良いです。

PoCを作る組織の環境次第で使いやすい方式を考えるべきです。以下は一例です

• Jupyter notebook (Colaboratory含む)をよく使っているならPython
• 静的HTMLを配布しやすいならjavascript (Confluenceなどに埋め込むパターンも)
• Power Automateなどのノーコードを使っているならそこから

scriptを介することで、以下のことがやりやすくなります

• gptの入力をファイル（ExcelとかXMLとか）から読んで作成
• gptの出力を成形して(csvとか)ファイルに保存（Excelとか）
• gptのAPIをシナリオに合わせて複数自動実行（最初の入力をgptでクラスタリングし、その結果に応じて特定のプロンプトを読み込んだgptにその入力を送るとか）

ここはChatGPTのシナリオ制御＋手作業でもできなくはないが、量が増えるとChatGPTへのコピペ作業が大変になるので、scriptで自動化できるとかなり楽になります

※ここのファイルをDBとの読み込みと書き込みと読み替えてもOK

gpt API をwrapper APIで包み込む

この対応をすることでエンドユーザがgptの認証情報を直接もたなくて済むようになります。ただし、このwrapper API自体には認証処理やIP制限をかけるなどの工夫が必要です

（2023/05/01 追記）AzureでAPI Managementを使った実装例が参照アーキテクチャとして公開されていました。

これを行うことで、

• エンドユーザのサービスごとのコスト集計
• gpt APIへのログの監査

ができるようになります。サービスごとのコスト集計はAzure利用の場合はリソースを分ければ良いが、OpenAIのgpt利用の場合は難しいです（Organizationを分けるとgpt-4のwish listに並び直す羽目に）

組織のポリシー次第だが、機微情報を送ってはならないとしているところが多く、その制約のためにログを監査できる状態にしておく方が望ましいと考えられます

GUIまで用意

これは通常のWebアプリケーション開発と同じく、サーバーサイドのAPIを作っただけではなくフロントエンドまで作ろう、という話です。

内部の生産性向上のツールどまりだったら、script + gpt APIのWrapper API構成で大丈夫なケースが多いと思いますが、リッチな画面があった方が良い、という要求があってもおかしくないです。デザイナーのスキルセットも求められます

内部利用ではなく一般公開する

gpt の出力が完全に制御できないため、一般にgptの出力結果を公開するさいにはいくつかの工夫が必要となります。本件についてはOpenAIのgpt4の強化学習についてのドキュメントが参考になるので、紹介します。

大雑把に

• Hallucination (それっぽい嘘を返す)
• Harmful Content (プラポリ的にやばいやつ)
• 自身のプロンプトなど非公開情報を返さない

が特に意識しなければならないことです。以下の対策（重要な順）を施すことを推奨します

1. 出力をそのまま使わない
2. 事前にさまざまなインプットでテストする
3. プロンプトを工夫する

これはこれで長くなるので本記事では割愛します

最後に

このPoCではどこまで作るのか」「その過程の成果物は何にするか」についての会話が、このドキュメントを参考することで、スムーズになれば幸いです