結論
社内システム上の多数のアプリケーションがChatGPT APIを活用しているというシチュエーションを想定し、AI共通基盤が持つべき機能とアーキテクチャを検討しました。
ポイントは以下の３つです。
- 社内システム上のあらゆるアプリケーションにChatGPT APIが組み込まれる未来が想定される
- アプリケーションごとに必要な実装は重複するため共通化が可能
- Proxyサーバを社内に配置しそこで共通的な処理を行い、各アプリケーションはAPI呼び出しのみを行う
背景 -ChatGPT APIの2024年を予想する-
2023年5月現在のChatGPT APIの活用状況
2023年3月1日にChatGPT APIであるGPT3.5-turboがリリースされ、あらゆるプレイヤーによってこぞって活用方法が模索されています。
現在の活用状況について知見を深めたかったため、TwitterにてChatGPT APIを使っている方々へ向けてヒアリングを募集したところ、なんと15人ものCEO,CTO,上場企業社員の方々とお話をさせていただくことができました(余談ですがとても濃い話がたくさんできてとても楽しかったです)。
活用方法は様々でしたが、大別すると次の３つに分類できました。
| パターン | 説明 |
|---|---|
| ChatGPTクローン | ChatGPT APIで社内向けのChatGPTを構築し、業務改善に利用する。社員の利用状況の分析やプロンプトの共有など行えるようにしている。 |
| インターフェイス変更 | LineやSlackやキーボードなど別のインターフェイスに組み込んで、使いやすくする。 |
| ドメイン特化 | ドメインを絞ったり、技術的な改善、独自データを注入するなどでより精度の高いタスクを行わせる。 |
GPTは汎用AIであるため多様なユースケースが考えられ、現在続々とドメイン特化アプリが出てきています。
(引用: DS協会_ChatGPTによって描かれる未来とAI開発の変遷 )
また、既存のアプリケーションに対してChatGPT APIを導入することでさらに高いレベルのUXを実現する流れも盛んです。
(引用: DS協会_ChatGPTによって描かれる未来とAI開発の変遷 )
OpenAIの事例(ちょっと先の未来)
ChatGPT APIの活用方法として、一歩先の未来に行っているのがOpenAI自身です。
以下のソースコードは、OpenAIが開発中のChatGPT Plugins(ChatGPTが外部APIを実行する機能)のコードの一部です。なんとコードの中でChatGPT APIが使われています。
「メタデータをJSONで返してください」というプロンプトをChatGPTに投げて、その結果をjson.loadでパースさせてそのまま返り値にしているのです。
(引用: https://github.com/openai/chatgpt-retrieval-plugin/blob/main/services/extract_metadata.py)
ChatGPTは開発支援を行うだけでなく、コードの中にまで入り込んでシステムの一部になっていく可能性が高いと私は思っています。
2024年の未来予想図
上記の流れからDXならぬAIXの流れができて、既存の業務やビジネスをAIで代替できないか探索される時代が来ると思っています。そうすると社内のシステムのあらゆるところでChatGPT APIが使われるようになるでしょう。
ワークフローや自社サービスにもChatGPT APIを使うことで、今までできなかった業務工数削減やビジネス価値向上が実現できるためです。
採用すべきアーキテクチャについて考える
上記未来予想図をもとに、どのようなアーキテクチャが最適か考えていきます。
Lv.1 黎明期の社内アプリ乱立時代
今はほとんどの企業がこの状態だと思います。
社内用ChatGPTの導入や、既存機能へのChatGPT APIの導入などが各々別プロジェクトとして走って社内に構築されています。
バックエンドの機能構成
- 利用回数制限・・・特定ユーザが乱用してコスト破産を起こさないように限界値を設定するため
- リトライ処理・・・OpenAI APIがレートリミット等で失敗することがあるのでバックオフのリトライ処理が必要であるため
- システムプロンプトの注入・・・プロンプトインジェクション対策や、意図しない使われ方をさせないため
- 禁止ワード・・・システムプロンプトを漏らさないようにするため
- キャッシュ・・・コスト削減、E2Eテスト実現のため
データベースに保存されるリクエストログ
- 日付
- ユーザID
- プロンプト
- リクエストパラメータ(temperature等)
- AIのレスポンス
- トークン数(コスト計算のため)
- ステータスコード(エラー判別のため)
管理画面
リクエストごと、ユーザごと、アプリごとの利用状況やコスト分析を行える機能が必要です。
(リクエストごとのログデータ確認画面)
(ユーザごとの利用状況分析)
Azure上での構築
行政や大企業などのエンタープライズでは、ほとんどの場合がAzureでシステムが構築されている模様です。
マイクロソフトがSLAやセキュリティ周りの痒い所にしっかりと手を差し伸べています。
(引用: DS協会_ChatGPTによって描かれる未来とAI開発の変遷 )
Lv.2 共通機能の集約
ChatGPT APIを使ったソリューションの構成や機能はほとんど同じというのがヒアリングの中で得られた所感です。ここで気づくのですが、バックエンドの機能、データベース、管理画面をアプリケーションごとに個別に実装している現状はかなり効率が悪いのではないか？ということです。
つまり、共通機能の集約が可能であるということです。
このレベルにすでに達している企業はほとんどいないと思いますが、アメリカのスタートアップHeliconeがここに対してソリューションを構築しています。
HeliconeはURLを差し替えるだけで、ログの保存や、回数制限・リトライ・キャッシュ等の周辺機能をカバーしてくれるというものです。
HeliconeがChatGPT APIへのProxyサーバになっていて、間で諸々の共通機能を提供するという仕組みになっています。
Heliconeを使うことで、個別のアプリケーションはログの保存や周辺開発から解放され、BackendはAPIを叩くだけにできるようになります。
ただし、Heliconeを使うとログ情報は社内システム外に保存されるため、セキュリティ的懸念が増えます。機密情報等が他社のサーバに保存されることになるのでポリシー的にNGのところが多いでしょう。
また、Heliconeはレイテンシーを緩和させるために、処理をCloudfrare workerに配置し、回数制限等の設定値もリクエストのヘッダーから取得するような実装になっています。
Lv.3 共通基盤化
HeliconeのProxyサーバによる共通機能の集約というソリューションは間違いなくExcellentです。
共通機能を備えたProxyサーバを社内システムに配置し、各アプリケーションはそこを経由してAPIを呼び出すことで開発工数を大幅に抑えることができます。またアプリケーションごとのログが１箇所に集約されるため、高度な利用分析も可能になります。
実際に触ってみたい人へ
上記のシステムを開発したので、個人開発者向けに無料でサービスを提供しています。
ChatGPT APIを使った開発をしている方はぜひ、すぐに使える状態になっているので、一度使ってみていただけたら嬉しいです😆
PS(2023/05/01)
多くの反響いただきとても嬉しいです！
自社への実装についてご相談については以下のURLからお問合せください！