Awarefy AI を半年間運用してみて分かった OpenAI / LLM / ChatGPT をビジネスやプロダクトに投入する際に必ず知っておきたい 10 のこと
はじめに
こんにちは。@iktakahiro 池内です。
この記事は、昨今さまざまな領域で存在感を増し続ける LLM およびその 周辺技術、そのなかでも大きなシェアを誇るであろう OpenAI 社のテクノロジーである ChatGPT や AI 機能 をビジネスやプロダクトに投入する利用するにあたり、必ず知っておきたいことについてまとめたものです。
株式会社Awarefy と Awarefy AI について
筆者が CTO を務める株式会社Awarefy（アウェア-ファイ） は、「心の健康を支えるデジタル・メンタル・プラットフォームを実現する」をミッションに掲げるヘルスケアテック領域のスタートアップです。「デジタル認知行動療法アプリ Awarefy」を開発、運営しています。
株式会社Awarefy は、2023年4月に「Awarefy AI 構想」を立ち上げました。
構想の立ち上げにあわせ、OpenAI 社の GPT 3.5 Turbo を活用した Awarefy AI チャット機能をプロダクトのいち機能として、リリースしました。
リリース以後、AI 搭載機能は非常に好評で、リリースから3ヶ月後の資金調達を推し進める原動力のひとつにもなりました。
LLM のプロダクション環境での利用実績として約半年程度が経過したなか、その運用のなかで得られた知見や、陥りがちなミスやトラブルについてのナレッジをシェアし、国内外での LLM の活用促進が進む一助となればという動機から、本記事の執筆と公開にいたりました。
本記事では、LLM およびその周辺技術を、AI 技術、またはたんに AI と呼称します。
対象読者・想定読者
本記事の対象読者および想定読者は次のとおりです。
AI / LLM / OpenAI ならびに関連技術を利用したプロダクトをつくりたいと考えているかた
AI / LLM / OpenAI の技術を導入するうえでのリスクや考慮事項について知りたいと考えているかた
この記事で分かること
この記事を通読することで、下記についての理解を深められます。
AI、特に OpenAI の提供する AI を利用したサービスを企画、開発するうえで、必ず知っておいたほうがよい制約や仕様、ルールについての理解が深まる
AI を導入したプロダクトを商用環境で運用している実体験に基づいた注意点や、ノウハウ、AI との付き合い方についての理解が深まる
それでは 必ず知っておきたい 10 のこと、ひとつずつ見ていきましょう。
1. OpenAI API の利用規約について知る
OpenAI API を利用してサービスを提供するにあたり、まず利用規約を把握する必要があります。
OpenAI API に限った話ではないのですが、サービスを利用するうえで、利用規約については少なくとも下記の2つの観点でチェックする必要があります。
自社が、OpenAI API の利用規約を遵守できているかどうか
OpenAI API の利用規約に、自社の利益を損ねる条項や自社のプライバシーポリシーなどと衝突する条項が含まれていないかどうか
前者については、自社のユースケースや、これからつくるプロダクトのアイデアが、そもそも利用規約上禁止されていないかについてあらかじめ確認する必要があります。
Disallowed usage of our models として、OpenAI がサービスの禁止事項のそして列挙しているもののなかには、「 Weapons development（兵器の開発）」といった内容もあれば、新規事業や既存事業の改善のアイデアとして含まれそうなものもあり、すべての項目をいちど精査しておくことをお勧めします。
Automated determinations of eligibility for credit, employment, educational institutions, or public assistance services
上記によると、与信や雇用、教育機会や公共サービスの利用資格を自動的に判断する用途に使ってはならない、ということになります。例えば、新卒一括採用のフィルタリングを OpenAI 社のモデルに委ねる、ということをしてしまうと、このポリシーに違反する可能性があります。アダルト系コンテンツとしての利用は禁止、有資格者の確認を通さないファイナンシャルアドバイスとしての利用も禁止です。
注意するべきは、エンドユーザー向けに入力インターフェースを提供する場合、エンドユーザーの投稿するコンテンツについても注意を払う必要がある、という点です。この点は後述します。
ヘルスケア・医療の領域でみると、健康状態の診断や治療方法の指示が禁止項目に含まれます。いわゆる医療行為については、AI の有無に関わらず医療サービスではないサービスでは行ってはならないことになっていますから当然の制限なのですが、生成されたテキストがどのように解釈されうるか、といった点にまで配慮し、ユーザーおよび自社に対するリスクヘッジを行うのが妥当だと考えられます。
2. OpenAI のブランドガイドラインについて知る
利用規約に近い話ですが、OpenAI のブランドガイドラインも一読するべき情報です。
Open AI API の利用が一大ムーブメントとなったとき、「ChatGPT搭載」のような表現を含む製品発表やプレスリリースが多く行われていたさまをみなさんも目にしたかと思います。
ブランドガイドラインによると、「{{自社ブランド名}}GPT」のような呼称はせず、「Powered by GPT-4」という表現をすることが求められています。ブランドガイドの公表を受けて、自社サービス名の変更対応を行っている、という例も見かけました。他者の商標権を侵害していないかの確認は社名や製品名の「命名」における基本事項のひとつではありますが、分かりやすさや流行り、みんなやっているからという理由で確認を怠ると、のちのちブランド変更を迫られたりするなどの事業リスクになり得ます。
2023年9月11日時点では、GPT について商標出願中のステータスということで、ただちに商標権の侵害とはならないのではないかと考えられますが、OpenAI API を利用する以上は、利用規約とともにブランドガイドに従っておくことが将来にわたっての事業リスクを軽減することに繋がります。
特許情報プラットフォーム J-PlatPat で調べると、「ＧＰＴ」という文字商標は「ＯｐｅｎＡＩ ＯｐＣｏ， ＬＬＣ」（表記ママ）を出願人として2023年6月21日に商標登録されています。「ＣＨＡＴＧＰＴ」については同出願人より申請されているものの審査待ちというステータスのようです。
（Web サイトの使用上詳細情報の URL を直接掲載できないのですが、GPT などで調べると各社が商標を取得しようとしているさまも閲覧できますので、眺めてみても面白いです。）
3. コストについて知る
OpenAI API の利用には従量課金制による課金が発生します。
API を利用している方はご存じの内容かと思いますが、GPT-3.5 Turbo のモデルで入力 1,000トークンに対し $0.0015、出力 1,000 トークンあたり $0.002 の費用が発生します。「トークン」というのはなかなか厄介な概念で、文字列や単語数と単純に対応するわけではありません。特に日本語の場合の予測の困難さは顕著で、費用を見積もる場合、文字数 x 2 から 3 程度と、バッファを持っておく必要があります。
OpenAI がトークナイザーを公開しているので、英語入力と日本語入力との扱いの違いが体感できます（このトークナイザーは、GPT-3.5、GPT-4 の場合の算出とは異なる点に注意）。
また、LLM の特徴としてテキストの生成 = 出力がありますが、この出力トークンに対しても課金が発生します。出力の内容は完全にコントロールできないことから、実際に入出力が完了してみないと、全体でどの程度のトークンが消費されたのかの確定が行えない、という難しさがあります。
この課題に対する対処としては、1. 悲観的に見積もっておくこと、2. 各種制限値を利用すること の2点があげられます。
ひとつめの ”悲観的な見積もり” については、1タスクあたり（コスト的な観点での）ワーストケースを見積もっておくことをお勧めします。エンドユーザー向けに提供している SaaS などの場合、原価として認識しておく必要があります。
2つめの ”各種制限値を利用する” についてですが、例えば GPT-3.5 Turbo の 4k モデルの場合、4k（4,000 トークン）がシステム上の上限になりますので、1リクエストあたりの費用がこれを上回ることはありません。16k モデルの場合、ワーストケースの費用も4倍になる、ということを計算に入れておきます。
また、OpenAI API のリクエストでは `max_tokens` というパラメータを指定できます。`max_tokens` はリクエストに対する生成テキストの上限トークンとなるため、見積もりを行う際の上限値としても利用できます。
ここで難しいのは、OpenAI は max_tokens に 収まる 良い感じの切りのよいテキスト を常に生成してくれるとは限らず、人間から見たときの文章の途中で生成が途絶えてしまうことがあるということです。この現象は ChatGPT の Web インターフェースでも見られる振る舞いで、裏側で `max_tokens` に達したために生成を中断した、ということが原因となり発生しています。
👆 Awarefy AI の場合
Awarefy のビジネスモデルは、サブスクリプションモデルです。Awarefy 全体として、従量課金となるようなポイントは今のところはないため、AI に関するコストが増えすぎると、サービスの利益率を圧迫することとなってしまいます。そこで Awarefy の場合、AI 関連機能に 利用回数制限を設けることで、コストコントロールを行えるようにしました。
Awarefy のプロダクトマネージャ、デザイナともディスカッションを重ね、利用回数制限に達した、ということがマイルドに伝わるようなユーザーコミュニケーションを心懸けるようにしました。
OpenAI API だけがコストなのか
OpenAI API を活用するうえで、コストは非常に大きな関心事であると思います。しかしながらじっさいのところ、従量課金制により課金されるサービスというのは OpenAI API に限りません。
たとえば、クラウドストレージサービスの Amazon S3 を利用する場合、GB あたり 0.023USD の費用がかかります。
動画配信のサービスをしていれば、動画配信のトラフィック従量課金がコストの一定を占めることになりえるポイントでしょう。OpenAI API も従量課金制の SaaS のひとつであるため、それ自体が特に珍しいというわけではありません。OpenAI API のコスト面が注目されている理由があるとすると、「文字の入出力」という現代では相対的に扱いが小さくなったデータサイズの感覚からいって API の使用料金が高額である、という感覚的なものが理由ではないかと考えています。
OpenAI API に限って言うと、モデルのプライシングダウンも実施していることから、いまのところ需要とのバランスを保とうとしているように見えます。しかしながら、コスト構造の一端を一社に握られているという事実も否めないため、この点をどのようにリスク評価するか、ということは関心事になるでしょう。
4. OpenAI API サービスの安定性について知る
OpenAI のテクノロジーはさまざまな観点で革命的な変化を起こしていますが、それはモデルの性能の高さだけではなく、SaaS として即座に LLM のベネフィットを享受できるエコシステムをつくりあげた、という点が大きなインパクトだったのではないかと筆者は考えています。
同時に、自社のアプリケーション全体からみたときに、OpenAI API は「外部サービス」のひとつです。外部サービスの場合、サービスの可用性（システムを障害で停止することなく稼働しつづける能力や性能のこと）については自社でコントロールすることはできず、サービスプロバイダにその品質を委ねることになります。
OpenAI の提供するサービスの稼働状況に関するステータスは次の URL で参照できます。
何を基準とするかですが、現時点で OpenAI API の可用性は、非常に高いとは言えない 状況にあると言えます。
参考指標 : SaaS 向け SLA におけるサービスレベル項目のモデルケースによると、基幹業務系の サービス稼働率は 99.9%以上、 基幹業務系以外は 99% 以上
後述の「レイテンシー」でもふれますが、明確なサービスダウンのほかに、レスポンスタイムの低下がしばしば見られます（世界中で OpenAI API が高頻度で利用されていることを考えると、むしろ高い可用性を維持していると見なすこともできると思いますが）。
いずれにせよ、自社サービスが OpenAI API を利用する場合、外部サービスとしての OpenAI API の可用性が自社サービスの可用性にも影響を及ぼします。
OpenAI API の場合、代替製品が他にはないという現実が、サービス運用者の頭を悩ませています。OpenAI API の依存度の高いサービスの場合、OpenAI API が長時間サービスダウンすることがプロダクトやひいては事業の継続リスクにも繋がっていきます。OpenAI API が 単一障害点（SPOF）になり得る、という点に注意を払い、導入するかどうかを決定するべきでしょう。
👆 Awarefy AI の場合
一般的な対策にはなりますが、AI 関連機能を非同期処理にする、失敗時のリトライ処理を適切に行うようにする、ユーザーにステータスを分かりやすく伝える、といったことがこの対策になります。Awarefy としてはできていることとできていないことがあり、鋭意、改善をしているところでもあります。
また、OpenAI API への一極集中を避けるために、OpenAI API 以外の API を利用できるような対策も講じています。OpenAI API 以外の選択肢については後述します。
5. レイテンシーについて知る
前項で、OpenAI API の可用性について触れました。システムの運用観点ではもうひとつ避けて通れないのが、レイテンシーの問題です。
レイテンシーとは、狭義にはネットワーク通信における遅延を示す言葉です。例えば、LINE のようなチャットを相手に送信した場合、送信した情報が相手の端末に届くまでに、数ミリ秒から数秒の遅延（時間差）が生じます。レイテンシーはほとんどの場合、短ければ短いほど良いものとされ、長いレイテンシーは、ユーザーにとって「遅い」「重たい」と認識されます。
ここでは、OpenAI API の API を呼び出してから、テキスト全体の生成が完了しレスポンスを受け取るまでの時間をレイテンシーと呼称します。このレイテンシーには、ネットワークを介したデータの送受信の時間も含まれますが、レイテンシーの割合の多くを占めるのは、LLM のテキスト生成時間です。
モデルによって大きくことなりますが、例えば、GPT-3.5 Turbo でチャットのような短文を生成する場合には 1秒から10秒、もう少し長い、3−5段落の文章を GPT-4 で生成する場合 30秒〜60秒程度の時間を要します。
さまざまなシステムの応答性能が高まった現代において、1つのリクエストに数秒以上もかけてしまった時点で、ユーザーにとって快適なシステムであるとは見なされないでしょう。このレイテンシーのボトルネックが LLM の実行時間にある以上、OpenAI API のクライアント側で抜本的な対処することはできません。
ChatGPT の場合、ストリーム（逐次）処理を行うことで、ユーザーの体感のストレスを緩和する方略をとっています。OpenAI API にも、ストリーム処理を行うためのパラメータが存在するため、これを利用するのがユーザー体験向上のための1案でしょう。
OpenAI API をサービスに組み込む場合、処理の完了までに数秒から数十秒かかる場合がある、という前提でサービスやシステムを設計する必要があります。
GPT-4 よりも GPT-3.5 のほうがコストも安く生成速度にすぐれることから、利用モデルの選定において、テキストの生成速度は無視できない要素の一つです。拙速は巧遅に勝る、という言葉もありますが、賢いが遅い GPT−4 を選ぶか、賢さは劣るが速い GPT-3 を選ぶか、よく検討する必要があります。
6. OpenAI API 以外の選択肢について知る
これまで、OpenAI の提供するサービスの可用性やレイテンシーに触れ、OpenAI API が単一障害点（SPOF）になることのリスクについて言及しました。そのなかで「OpenAI の代替製品がない」と述べたのですが、この表現はもちろん正確ではなく、正しくは、GPT-4 が使えるのは OpenAI API だけ、ということになるでしょうか。しかしそれほど GPT-4 は強力であり、ベンダーロックインのリスクがありながら、多くのユーザーを獲得しているという現実があります。
そんな OpenAI API ですが、代替製品がないわけではありません。
代替、というと色々語弊があるのですが、その役割を担う、あるいは既に担っている可能性が高いのが、Microsoft Azure に搭載されている Azure OpenAI Service（AOAI） です。
AOAI は、大変な語弊を恐れずに言うと、Azure のサービスを経由して提供される OpenAI API であり、RESTFul API の仕様から料金体系まで、ほぼほぼ同じものです。引き続き語弊のある説明をしますと、OpenAI API がさまざまな機能を投入、アップデートしていくなか、その安定バージョンが AOAI に搭載されていくといった位置づけで運用されているように見えます。
AOAI は API レベルでみると OpenAI API と（ほぼ）同じものと見なすことができ、かつインフラとしても両者は（おそらく）独立していることから、OpenAI API の可用性を補完しうる存在の最有力候補です。
しかしながら、AOAI は実質的に OpenAI API であることと、Microsoft 社と OpenAI 社との資本関係を鑑みると、同一のエコシステムのなかにロックされていることには変わりないと考えるひとも少なくないでしょう。すなわち、我々は GPT-x 以外の選択肢についても知っておく必要があるということです。
そのなかで筆者が有力視しているのが、AWS の Bedrock と Google の Vertex AI、およびサービス内で提供される LLM です。当社の検証の結果、現状公開できる情報でいうと、Google の PaLM 2 は生成速度、品質ともに高く、GPT-4 に迫る勢いを感じています（※ その他は追って情報公開をお待ちください）。
LLM でいうと、Anthoropic の LLM Claude 2（クロード2）にも注目しています。Anthropic は、Amazon が大型出資を実施するなど、注目度の高い企業ではないかと思います。
バイナリが公開されている オープン型の LLM を採用し、モデルのセルフホスティングを行ったうえでサービス提供をするという道もあります。
rinna（りんな）の japanese-gpt-neox-3.6b や、サイバーエージェントの open-calm-7b などがオープン型の LLM の1例です。
※ LLM の公開ムーブメントにともない、オープンソース、OSS、商用可能オープンソース、などの オープンソース関連の呼称の乱立や誤用が広まっていますが、本記事ではその点については本論としないため、「多くの人が使えるように公開されている = オープン型」という程度の区別にとどめています。
オープン型の LLM のセルフホスティング方式の場合、外部サービスの可用性やサービス継続性、利用規約などに縛られず、LLM の機能を供給できるということが最大の魅力となります（商用利用可・不可などのモデル自体の利用規約は別途存在する点に注意）。
ちなみにセルフホスティングといっても、いわゆるマネージドサーバー方式になるかというとそうでもなく、Amazon SageMaker のようなクラウド上の機会学習サービスと連携する方法もとることができます。
しかしながら、OpenAI API の強みは SaaS であること、というのが筆者の主張です。セルフホスティングの場合、LLM の導入からサービス運用にかかる負担は自社でカバーする必要があります。肝心のモデル自体の品質についても、総合的に言えば GPT-4 のほうが優れている、というのが多くのユーザーの見立てではないでしょうか。
とはいえ、少数の企業による寡占やベンダーロックインを回避するという意味においても、オープン型の LLM のプロジェクトは非常に意義深いものであることは間違いありません。
7. コンテンツフィルタリングについて知る
Azure OpenAI Service について触れた流れで、コンテンツフィルタについても言及しておきます。2023年9月11日時点、AOAI の API には、「コンテンツフィルタ」がかかっています。
Azure OpenAI Service には、コア モデルと共に動作するコンテンツ フィルタリング システムが含まれています。 このシステムは、プロンプトと入力候補の両方において、有害なコンテンツ出力の検出と防止を目的とした、分類モデルのアンサンブルを経由して実行することで機能します。 コンテンツ フィルタリング システムは、入力プロンプトと (出力される) 入力候補の両方で、有害な可能性があるコンテンツ特有のカテゴリを検出し、アクションを実行します。
コンテンツフィルタは AI の入出力に有害なコンテンツ（暴力的な発言など）が含まれていないかをチェックするセーフティバーのような役割をするものなのですが、扱いの難しい点として、その判定も AI が行っており、かつ利用社側が（まだ）コントロールできない、ということがあります。
当社の事例として、社内文書のある翻訳タスクを AOAI を利用し実行していたところ、人の目から見て特段有害とは見受けられないテキストの翻訳タスクがコンテンツフィルタによって完了できない、という問題にあたったことがありました。AI が応答するべきかどうかも AI のアルゴリズムに握られているようで、なんとも不安になるできごとでした。
この仕様により、例えば「テキストが暴力的であるかどうかのリスクのスコアリング」を AOAI に行わせることは難しくなります（スコアリングの手前でコンテンツフィルタが発動してしまう可能性があるため）。
コンテンツフィルタについては、申請により制御の幅を広げる緩和措置がありますが、緩和の条件として実質的な社内利用に限るなどの制約も生じるため、ユーザー開放型のサービスにおいてはコンテンツフィルタは無視できない存在です。
コンテンツフィルタは Microsoft の掲げる「責任あるAI」の原則にもとづく取り組みのひとつとされています。したがって、各社の個別の自由にはまだそこまで柔軟に対処はなされないのではないかと見ています。
なお、AOAI ではない OpenAI API には、コンテンツフィルタと同等の機能はないのですが（内部的には動作している可能性はあります）、OpenAI API には Moderation API があります。Moderation API は、OpenAI の API が Usage Policies に違反した使われ方をしていないかを調べるエンドポイントです。この Moderation API の判定結果をもってコンテンツフィルタリングを行う、という方式をとることができます。
OpenAI API の ラッパー（= 便利な機能を被せて利便性を向上させたもの） 的なサービスを提供する場合、サービスプロバイダがそのように意図していなくても、エンドユーザーが Open AI API のポリシーに違反する使い方をしてしまう可能性があります。この場合、サービスプロバイダが OpenAI API の利用を禁止されるリスクもあるため、コンテンツフィルタや Moderation API は、自分たちを守るためにも利用を検討するべき機能と捉えられると思います。
8. データの管理について知る
今後、AI 機能がさまざまな領域に普及していくにつれ、データの保護、とりわけシビアな管理が求められる行政や医療機関において、データが国内に保存されているか、国外に保存されているかというデータ管理のロケーション（リージョン選択）は大きな関心事です。
OpenAI API の場合、リージョン選択を行うことはできません。AOAI の場合、モデルにより異なりますが、リージョンの選択肢が提供されています。
上記ドキュメントによると、GPT 3.5 Turbo も GPT-4 も 東日本リージョンで提供されているため、扱うデータの保管場所が日本国内に限定される場合でも、AOAI を導入できる可能性があるでしょう。
2023年8月28日に発表された、エンタープライズ向け ChatGPT においては、 データセンターのリージョンを含めて多くのオプションが提供される期待もあります。
また、ChatGPT 登場以後、入力データ（多くの場合、チャットの入出力）が、AI の再学習に用いられるのかどうか、ということに関心が向けられてきました。この点については既に多くの情報が存在しますので詳細な説明を割愛しますが、OpenAI API の利用規約に則れば、API 経路での入出力についてのデータの再利用・再学習は行われないことになっています。
しかし、利用規約に書いてあるからといって実際に発生する確率がないとは言い切れません。これは AI や OpenAI API に限らず、サービスプロバイダが意図しない形での情報漏洩や流出が発生する、ということが可能性としては考えられるためです。したがって利用規約の記載に関わらず、社内の機密情報を OpenAI API / ChatGPT には入力しない、というポリシーで運用している組織は少なくないと考えられます。
データ管理やセキュリティはあらゆる組織にとって重大な関心事のため、この点において AI の利用の慎重論がでてくることについて理解はできます。しかし、エンタープライズ向け ChatGPT に見られるように、サービスプロバイダ側のセキュリティレベルの引き上げが行われることと平行して、AI SaaS の利用がより広まっていくのではないかと筆者は予想しています。もちろんその流れのなかで、セルフホスティング方式も一定の存在感を残し続けることでしょう。
9. AI を導入する上での自社の競合優位性について知る
OpenAI API の公開以後、AI 関連サービスのアップデート情報を目にしない日はないほどに、じつにさまざまなケースで AI の利活用が進んでいます。それゆえに、「AI を導入した」という程度では新規性や優位性はないのではないか、という冷静な見方も強くなってきているように思います。
筆者はよく、AI は iPhone x Google マップのようなもの、という例えを使うのですが、例えば飲食店の口コミサービスをつくろうとしたときに、店舗情報に Google Map（的なもの）がなかったら、非常に不便ですよね。いっぽうで、ユーザーは Google Map があるから、その口コミサービスを見に来ているわけではありません。あくまで、素敵な飲食店に出会いたい、という体験を求めに口コミサービスを見に来ているはずです。その意味では、将来的には AI の存在は 狩野モデルでいう「当たり前品質」の範疇になっていくのではないかとさえ思っています。
とはいえ、これは多くの人々が経験していることですが、自社の本質的なユーザー体験をエンハンスする存在としての AI は、極めて強力なものだと筆者も体感しています。
👆 Awarefy AI の場合
Awarefy では、AI 機能の第一弾となる「AI チャット」という機能をリリースした際、あくまでも「Awarefy AI 構想」の第一歩であるという意識を社内ではしっかり持つようにし、プレスリリースにもそのようなメッセージを込めました。Awarefy AI はそれ自体が主役ではなく、Awarefy が提供するユーザー体験のすべてを下支えする、縁の下の力持ちのような存在であるべきだと考えたためです。
ごく個人的には、新規サービスを考えるうえで AI や LLM を起点にしてしまうと、模倣可能性が高く、自社のMOAT（競合優位性）を築くまでに、他社や大資本にマーケットを取られてしまうリスクが相当にあることをあらかじめ検討しておく必要があるでしょう（AI でなくても、常にそのようなリスクはありますが…）。
OpenAI API や ChatGPT の薄い ラッパーのようなサービスも、事業継続性という意味ではリスクが小さくないでしょう。なぜなら、公式サービスである OpenAI 側が機能を拡充していった際に、サードパーティを使うメリットが薄れていくからです。しかし、複数の LLM を束ねる類のサービスはじつのところ多く存在し、いくつかは一定のユーザーの支持を獲得しているように見えます。サービスではなく開発ツールですが、LangChain は人気が根強いツールのひとつです。
スピード勝負で荒波を乗りこなすという観点では良いチャレンジだと思いますし、個人的にも何かやってみたい分野の1つであります。
また、これはどちらかというとエンドユーザーに向けた話ですが、AI や LLM の運用には少なくないコストがかかることは先に述べたとおりです。したがって “無料で GPT-x が利用できます”、と謳うサービスは、あくまでもキャンペーンの一環として事象者側が一時的にコストを負担している、という事実を理解するべきです。当初は無料でも、早晩有料化するか、広告などのマネタイズを行い、OpenAI に支払う原価をまかなう必要が生じます。さまざまなサービスが生まれ生活が便利になっていくことに僕もわくわくしていますが、サービスの信頼性や継続性は個別にしっかりと判断していく必要のあることです。
10. プロンプトエンジニアリングについて知る
ChatGPT 以後、「プロンプト」や「プロンプトエンジニアリング」もすっかり聞き慣れた言葉となりました。それまでは、”黒い画面” として一部ビジネスパーソンから忌避されているという噂のコマンド･プロンプトが第一想起だったはずなのですが…。とりわけ、○○式 のように呼称される、少しひねりの効いた（？）プロンプト開発が話題になった時期もありました。
そんななかで、プロンプトエンジニアリングは模倣が容易のため、プロンプトエンジニアリングによって競合優位性を獲得することはできない、といった認識も広まりつつあるかと思います。これについて筆者は、一発芸としてのプロンプトエンジニアリングについてはそのとおりだが、サービスを継続的に運用・改善していくなかでのプロンプトエンジニアリングは競合優位性となり得る、という意見を持っています。
プロンプトエンジニアリングの結果発明されるプロンプトは、数百文字程度のテキストからなることが多く、確かにコピーが容易です。チャットのやりとりを通じてプロンプトを露出させる「プロンプトインジェクション」という手法も出回り、秘匿することも難しい可能性があるのは事実だと思います。しかしいっぽうで、これはプロダクトの中に組み込んでみてはじめて実感できることですが、プロンプトエンジニアリングは一度リリースして終わる、というものではなく、日々改善・検討を行う必要がでてくる継続的な営みなのです。
プロンプトをメンテナンスする必要が生じる理由は2点あります。
リリース後に判明したあらたなユースケースやユーザー要望、問題に対応するため
LLM のバージョンアップに対応するため
前者については、特にエンドユーザー向けに AI 機能を提供している場合、特にテキストを自由入力できるインターフェースを提供している場合に生じることが多いでしょう。
LLM バージョンアップについては、Awarefy でも運用に苦労している点です。
OpenAI のモデルおよび API には改廃がある
OpenAI の LLM には、バージョンが付与されています。gpt-3.5-turbo-0301 というモデルの 末尾の 0301 がバージョンです。これはリリース日（2023年3月1日）を元に採番されているようです。2023年6月に gpt-3.5-turbo についてバージョンアップが行われ、gpt-3.5-turbo-0613 がリリースされ、0301 は同年9月に廃止予定とアナウンスが行われました（その後、2024年6月まで延長されることがアナウンスされた）。
GPT-4 についても、gpt-4-0314 につづいて gpt-4-0613 がリリースされました。
OpenAI の場合、API が強制的に廃止されてしまいますので、古いバージョン（gpt-3.5-turbo-0301 や gpt-4-0314 ）を使い続ける、という選択肢はとれません。あらゆる意味で上位互換のモデルにアップデートが行われればいいのですが、LLM の場合単一やごく少数の評価指標でモデルを評価することが実質できないため、ユースケースによっては、品質が劣化、劣化したと感じてしまうケースがあります。したがって、従来バージョンの品質を維持できるよう、最新バージョンのモデルをいちはやく試し、場合によってはプロンプトを変更し、バージョンの改廃に備えることが重要です。
この点、オープン型の LLM をセルフホスティングしておくと、モデルのライフサイクルは自社で管理できますので、バージョン改廃についての一定のリスクを軽減できます。
とにかく、外部要因も相まって、プロンプトエンジニアリングは継続的に行う必要がある、ということはあらかじめ認識しておく必要があります。加えていうと、旧バージョンで有効だったプロンプトエンジニアリングのハック的手法が、新バージョンではまったく通用しなくなる可能性もあるということです。そのため、OpenAI 公式の提供するプロンプトエンジニアリングに関する情報を信頼できる情報とみなし、その他は一時的な参考情報としてみながら、自社でノウハウを蓄積していくことをお勧めします。
👆 Awarefy AI の場合
Awarefy の AI 開発における特徴として、プロンプトエンジニアリングやプロンプトの評価を、社内に所属する専門の心理職（公認心理師 / 臨床心理士）が行っている、という点があげられます。プロンプトの評価はそれだけで一大トピックになるほど奥深い領域ですが、現時点では「専門家による評価」が AI の生成の品質を担保する有効な手段の1つであると筆者は認識をしています。Awarefy のなかでは、さまざまな独自の評価軸で、AI の生成したテキストについての評価を行い、プロンプトエンジニアリングを行っています。
また、 Awarefy では gpt-3.5-turbo-0301 から gpt-3.5-turbo-0613 への切り替えにあたり、すべてのプロンプトをゼロからつくりなおしました。影響度合いは LLM のユースケースによると考えられますが、Awarefy の場合は影響が非常に大きかったです。次回 GPT-x のバージョンアップについて、楽しみ半分、タスクが増える恐怖半分といった心持ちです。
まとめ / 今回取り扱わなかったこと
今回「OpenAI / LLM / ChatGPT をビジネスやプロダクトに投入する際に気をつける x のこと」という切り口で、Awarefy AI 開発と約半年に渡る運用をつうじて得たナレッジを共有しました。どんなことでもそうですが、PoC（概念実証）と実運用との間には大きな隔たりがあります。筆者自身も「プロンプトエンジニアリングは模倣できるから大したことがない」と高を括っていたふしがありましたが、実際には「運用こそがすべて（運用できる体制があることに強い価値がある）」というふうに認識を改めたりもしました。このナレッジ共有がみなさまのお役に立てば幸いです。
また今回、おそらく関心を持つ方が多いであろう「ファインチューニング」や「RAG（自社データ活用）」については取り扱いませんでした。Awarefy ではこれらのナレッジをいままさに蓄積している段階のため、頃合いをみてまた記事を公開できればと思っています。
謝辞
今回記事の執筆にあたって、株式会社Awarefy のメンバーに多くの支援をいただきました。この記事に記載したナレッジは、僕個人の活動を通じてではなく、Awarefy としての活動を通じて得たものであることは言うまでもありません。一部ですが Awarefy や Awarefy AI の中の人をご紹介します。
代表CEO のおがわーるです。AI 構想は 2023年に入りすぐに形にすることを意思決定しました。
Awarefy プロダクトマネージャー あいり おだ。Awarefy AI も一緒につくっています。
プロダクトマーケティングマネージャーの 僧侶系デジタルマーケター秦くん。今回記事の執筆にあたり、レビューやクリエイティブ制作のディレクションを行ってくれました。
Awarefy ひとり目デザイナ りゅーくん。Awarefy はもちろん Awarefy AI のユーザー体験や UI をデザインしています。本記事中のクリエイティブ制作もしてくれました。
そんな株式会社 Awarefy では、Awarefy AI 構想をはじめとする、ヘルスケア、特にメンタルヘルスケアの領域にイノベーションを起こす事業やプロダクトを一緒につくる仲間を積極的に募集しています。今回の記事を読んで当社で働くことにご興味をお持ちいただけたかたは、ぜひお気軽にコンタクトしてください。
それではまた。
お読みいただいてありがとうございます。