生成AI製品の構築：まず知っておくべきこと

はじめに

生成AIは試すのは簡単ですが、人々が信頼できる製品に仕上げるのはかなり困難です。チームなら、数日で言語モデルをチャットインターフェースに接続することは可能です。しかし、そのインターフェースに実際の顧客からのリクエストに対応させ、アクセス権限を遵守させ、社内データを扱わせ、誤った回答から回復させることは、まったく別の話です。

ビジネス用途での生成AI導入を検討している企業にとって、最初の決断は「どのモデルを使うか」ではありません。その課題に対して、そもそも新しい製品が必要なのかどうか、ということです。既製のAIツールでニーズの大部分をカバーできる場合もありますが、既存のソフトウェアでは必要なワークフローに対応できない場合、カスタム実装の方が理にかなっています。後者を検討している企業は、SysGearsの生成AIエンジニアに相談し、自社の特定のユースケースに基づいて構築される製品の技術的要件を検討することができます。

生成AI製品は、単に自社ブランドのインターフェースの背後にモデルを配置するだけでは済まない。モデルが言語処理を担当するとしても、アプリケーションのその他の部分が、モデルがどのような情報を参照できるか、他のソフトウェアと連携できるか、そして回答が的を外した場合にどう対応するかを決定する。これらの決定は、モデル自体の選択と同様に、製品の有用性に影響を与える。

社内アシスタントが、古いポリシー文書を取得してしまうと、従業員を誤った方向に導いてしまう可能性があります。顧客レコードへのアクセス権限を与えると、回答の質と同様にアクセス権限の管理も重要になります。アプリケーションがレコードを変更できる場合、説得力はあるものの誤った回答が、実際の損害を引き起こす恐れがあります。

これらは、リリース後に後付けで修正できるような細部ではありません。これらは、アーキテクチャや必要なエンジニアリングの労力、さらには製品の運用維持にかかるコストを含むAI開発コストに影響を及ぼします。企業は、開発に着手する前に、範囲を絞り込む余地があるうち、あるいは既存のツールで対応可能だと判断できるうちに、これらの点を十分に検討すべきです。

生成AIが必要な問題から始める

説得力のあるデモは、実際にはごくありふれたビジネス上の問題を覆い隠してしまうことがあります。例えば、従業員が社内文書の検索に過度な時間を費やしている場合、セマンティック検索システムで十分かもしれません。一方、長い文書を解釈し、特定の詳細を抽出し、複数の情報源からの情報を用いて回答案を作成する必要がある場合は、言語モデルの方がより実質的な価値をもたらす可能性があります。

この区別は当初から重要です。生成AIが真価を発揮するのは、ソフトウェアが雑然とした非構造化データを理解したり、文脈に依存する文書を起草したりする必要がある場合です。しかし、固定されたルールに基づいて行われるタスクについては、多くの場合、通常のスクリプトの方が運用コストが安く、信頼性も高いものです。

例えば、絶え間なく寄せられる製品に関する問い合わせに対応する卸売業者を例に挙げよう。顧客は同じ商品を様々な表現で説明するため、生成AIアプリケーションなら、その要求を理解し、関連する仕様を抽出し、返信案を作成することができる。一方、在庫状況は別の問題だ。在庫情報はリアルタイムの在庫記録から取得する必要があり、提示価格はモデルがたまたま算出した数値ではなく、会社の価格設定ルールに従わなければならない。

この役割分担を明確にしておく価値があります。言語処理はモデルに任せ、予測可能な業務は可能な限り従来のソフトウェアに任せるべきです。

開発に着手する前に、実際に何を改善すべきかを明確にすべきです。営業担当者が見積書を作成するのに要する時間を短縮できるかもしれませんし、顧客がサポート担当者を待たずに回答を得られるようになるかもしれません。いずれにせよ、現在のプロセスがどのように機能しているかを記録しておきましょう。そうしないと、チームは新しいAIインターフェースの導入を祝うだけで、それが実際に業務を容易にしたかどうかを把握できないままになってしまう可能性があります。

自社開発か外部調達か：実際にどの程度の制御が必要か？

「自社開発か購入か」という判断は、完全な所有権と利便性の二者択一として提示されることが多い。実際には、その中間にもいくつかの選択肢が存在する。

文章作成支援、会議の要約、文書分析、あるいは汎用的な調査といった、馴染みのある機能が必要な場合、既製のAIツールは合理的な出発点となります。こうした製品は通常、エンジニアリング作業が少なく済み、基盤となるインフラの多くはベンダーが管理します。企業は、専用の開発プロジェクトに資金を投じる前に、従業員がその機能を有用だと感じるかどうかをテストすることができます。

問題は、汎用ツールが、本来想定されていないプロセスに適合させなければならない場合に生じます。例えば、レガシーデータベースと連携できなかったり、従業員の役割が異なる場合に適切なアクセス権限を適用できなかったりすることがあります。また、他の業務システムで利用するために、出力結果を再加工する必要がある場合もあります。APIや設定オプションはこうしたギャップを埋めるのに役立ちますが、確立されたワークフローの特殊な要件を必ずしもカバーできるとは限りません。

ワークフロー自体が競争優位性となっている場合、既存の製品が重要な要件を満たせない場合、あるいはアプリケーションが独自データや社内システムとの緊密な連携を必要とする場合、カスタムAI製品の導入はより正当化されやすくなります。

3つ目の選択肢は、外部プロバイダーがホストするモデルを基盤として、独自のアプリケーションを構築することです。企業はインターフェースとその背後にあるロジックを開発し、システムを既存のソフトウェアに連携させ、結果を検証するための独自の仕組みを構築します。 モデル自体にはAPIを通じてアクセスするため、基盤モデルを一から学習させる必要はありません。これにより、企業は自社のワークフローに合わせて製品を設計する余地が生まれますが、それでもプロバイダーの価格設定、モデルの利用可能性、およびサービス制限に依存することになります。

この最後の違いには注目すべきです。カスタムAIアプリケーションの開発と、新しいAIモデルの開発は、まったく異なる取り組みです。基盤モデルの学習には、膨大な計算リソース、専門的な知識、適切なデータ、そして継続的な実験が必要です。ほとんどの企業にとって、そのような負担を負う必要はありません。既存のモデルに、社内文書からの情報検索機能や、慎重に設計されたツールへのアクセス機能を補完すれば、十分である可能性があります。

ワークフローに合わせてアーキテクチャを選択する

ビジネスケースが明確になったら、次の課題はアプリケーションの動作方法を決定することです。モデルは構成要素の一つに過ぎず、必ずしもエンジニアリングに最も時間を要する要素とは限りません。

文書アシスタントの場合、検索拡張生成（RAG）を検討する価値はしばしばあります。アプリケーションは、モデルがトレーニング中に学習した内容だけに依存するのではなく、承認された情報源から関連する文章を検索し、それをプロンプトに含めます。その後、モデルはその資料を用いて回答を構成します。

検索が適切に行われれば、社内ポリシーや最新の製品情報に基づいた回答は、より関連性の高いものになります。しかし、それが確実であるとは限りません。検索によって古い文書が抽出されたり、重要な注意書きが見落とされたり、モデルが誤って解釈してしまうような文章が渡されたりする可能性があります。

検索機能自体も個別にテストする必要があります。文書がどのようにチャンクに分割されるかによって、システムが何を見つけるかが左右されます。また、たとえ優れた検索結果であっても、ユーザーが閲覧すべきでない情報源から得られたものであれば無意味です。検索によってたまたま制限された資料が表面化したからといって、従業員のアクセス権限が無効化されるのではなく、その権限は検索プロセスにも確実に反映されなければなりません。アプリケーション自体が権限管理を徹底する必要があります。その判断をモデルに委ねるべきではありません。

ファインチューニングは別の目的を果たします。適切なトレーニング例が利用可能な場合、モデルの挙動、応答形式、あるいは反復的なタスクパターンの処理を適応させるのに役立ちます。しかし、主な問題が変化する事実へのアクセスである場合、ファインチューニングは検索の単純な代替手段にはなりません。昨年の製品カタログでファインチューニングされたモデルは、今朝何が変わったかを自動的に知ることはできません。

少なくとも初期段階においては、範囲が限定されたアプリケーションに必要なのは、プロンプトとモデルAPIだけかもしれません。それは、入力がどれほど予測可能か、そしてシステムがその出力をどのように処理することが期待されているかによって異なります。すべての応答を膨大な内部文書と照合する必要がある場合、検索機能が必要になるかもしれませんが、より単純なタスクでは、単にオーバーヘッドを増やすだけになる可能性があります。

最初のバージョンはシンプルに保ち、洗練されたデモ用入力だけでなく、実際のリクエストで試してみてください。曖昧な質問や情報が欠落している場合、モデルがどのように対応するかを確認しましょう。知識の不足を認めるのではなく、ごまかそうとする場合は、機能を追加する前に修正すべき点です。