テキスト系AIを活用したシステム開発の9つのポイント
2017年より、AIを活用したシステム開発に関わってきました。そこで、今回は企業内でAIの活用を検討するために必要なポイントを、事例を交えながら解説します。
AIはテキスト系と画像系に分類でき、今回はテキスト系AIの活用になります。
1.ユースケースの検討
まずは、ユースケースの検討を行います。アプローチとして、組織の視点、業務の視点、AI機能の視点があります。全てに共通することとして、ユーザー特定が重要になります。また、1案ではなく複数案を検討しましょう。現時点で良くてもフィジビリティー（実現可能性）の面でシステム化できない可能性があります。
組織の視点
自社の特定の組織（営業部、人事部、総務部、情報システム部等）での課題を洗い出して、ユースケースを検討するアプローチです。
この場合は、「ユーザー＝特定の組織」となるケースが多く、ユースケースの検討がし易く、システム開発プロジェクトは同組織のメンバーが中心となります。
ビジネスで想定されるユースケース（例）（出典：EnterpriseZineの記事,Accenture）が参考になります。業務の視点
自社の特定の業務プロセス（例：設計、製造、営業、保守等）での課題を洗い出して、ユースケースを検討するアプローチです。
この場合も、ユーザーがその業務を担う組織になることが多いですが、複数の組織を跨ぐ（設計から製造に引継ぎを行うユースケース等）場合もあります。プロジェクトマネジメントの観点では両組織のメンバーが中心となるべきです。（なぜか両組織とは異なる情報システム部がリードすることがありますが、成功裡なプロジェクト活動をする点ではお勧めしません）
製造業におけるGenerative AI活用ユースケース例（出典：microsoft）が参考になります。AI機能の視点
特定の部門や業務プロセス視点ではなく、AIの得意な機能（検索、分析、翻訳等）視点で課題を洗い出して、ユースケースを検討するアプローチです。
このアプローチは、情報システム部やDX推進部が中心となってプロジェクトを進めている場合かと思います。ユースケースの検討は、ユーザーの特定と課題の現場感がとても重要ですので、自社の特定の組織を巻き込めるかが勝負になります。
企業内ChatGPTのユースケース（出典：QUNIE）が参考になります。
2.価値の検討
ユースケース毎に価値の検討を行います。一般的にはROI（Return on Investment、投資対効果）を算出します。
以前（ITベンダーに所属していた時）の私は、ROIで価値がでないユースケースは排除していました。しかしながら、生成AIの急速な成長をを考えると、現時点でROIがでなくても”別の価値”があるのであれば、システム化しても良いのではと考えています。
ここで言う”別の価値”とは、以下の点が挙げられます。
・AIを活用したシステムで得られるデータで新しい価値が産まれる
・人材が不足していて、今後も人材を獲得することが困難である
・同業他社で同様の生成AIを活用したシステム導入が始まっている
ただし、（経営層による）スポンサーは継続的なシステム運営には重要なので、ROI＋”別の価値”を文書化、合意形成を得ることが必要となります。
ここで、AIをどのように活用するかによって、価値が変わるケースを紹介します。例えば、コールセンターにAIを導入する場合、下図のように、1）オペレーターをチャットボットに置換えるパターンと、2）オペレーターのサポートにAIを活用するパターンが考えられます。
1）は人件費が抑えられる可能性があるが、ユーザー視点でサービスレベルが下がる可能性があります。
2）は1人あたりの対応時間が減ることで人件費を抑えられる可能性はありますが、1）ほどの効果は期待できません。一方で、新人オペレーターでもAIがサポートをすることで対応品質の向上に繋がる可能性があります。
このように、似たようなユースケースでも価値が変わるケースがある点を留意してください。
3.優先順位づけ
全てのユースケースにおいて、優先順位を行います。例えば、以下の項目毎に1-5点を付け、総合得点で高いものから優先順位づけをする方法があります。ただし、項目によっては最低ラインを設けても良いかもしれません。特に①〜③については、評価の低いものはシステム開発中に要件変更や中止リスクがあります。
①インパクト（期待効果）
②実現しやすさ
③求められる回答精度
④優先度
⑤関係者の少なさ（単一組織か複数組織を跨ぐか）
徳島県三豊市が、2023年6月から東京大学松尾研究室と協力し、ChatGPTを用いた市民向けの「ゴミ出し案内」の実証実験（出典：三豊市）が良い教訓となります。実証実験1回目の正答率が62.5％、2回目の正答率が94.1％でしたが、本格導入の条件として設定していた99%に届かなかったため導入を断念したとのことです。
当時のChatGPTがGPT-4.0ではあり、現時点のChatGPTより回答精度は下がるものの、99％の正答率は厳しいと感じます。（③の評価で最低ライン以下だったかもしれません）
4.QA頻度の検討
具体的にシステム化の検討に移る前に、会話シナリオの検討を行うことをお勧めします。
今回検討しているユースケースにおいてQAの頻度が高い「よくあるQA」を答えれば良いのであれば、分類ベース（orロジックベース）のAIを活用すれば良いです。一方で、「稀なQA」も答えられる必要があるのであれば、生成AIやRAGの活用が考えられます。
5.回答形式の検討
回答形式は「一問一答」と「一問多答」があります。さらに、深掘りするために「更問（さらとい）」（会話のドリルダウン）をすることで、ユーザーが欲しい回答を提供していく方法があります。
例えば、ChatGPTは基本的に「一問一答」ではあるが、回答が十分ではない場合は「更問」をすることでユーザーが欲しい回答に辿り着くようになっています。
「一問多答」形式での事例として、アサヒビール株式会社の「生成AIを使った技術情報検索システム」（出典：PROMPTY）があります。このシステムでは、検索した技術文書（過去資料）と生成AIが生成した要約文を表示します。この場合、あくまでユーザーの過去資料の検索補助を効率化することに焦点を置いています。よって、多くの過去資料の中から、1つの回答を表示する「一問一答」より、関連する資料をランキング形式で表示する「一問多答」の方が効率が良いと言えます。
ちなみに、徳島県三豊市の事例は、「一問一答」＋「更問」を採用しています。「一問多答」＋「更問」が許容されていれば、正答率は改善できたかもしれません。
6.手法別LLMを活用した開発
以下の5つに分けることができます。①〜③は多くの企業で取り入れている手法であり、コスト次第では実現可能です。
一方で、④〜⑤は高い専門性が必要な上にコストもかかります。「③RAGの利用」では精度が得られない場合に検討する領域になります。
①プロンプトエンジニアリング
既存LLMのサービスを活用し、プロンプトを作成
②LLMのAPI活用
既存LLMのAPIを活用し、アプリへ組み込み
③RAGの利用
既存LLMを活用し、外部DB検索を組み合わせ
④ファインチューニング
事前学習されたLLMに、独自のデータセットを追加トレーニング
⑤独自LLMの開発
ゼロからLLMを開発
7.プロジェクトに求められるロール
今回は、デジタルスキル標準ver.1.２ 第3章「人材類型・ロール」（出典：IPA）の用語に合わせて説明します。
「6.手法別LLMを活用した開発」①〜④について、求められるロール（人材類型）を記載します。⑤については、実現可能な企業が限られ、LLMのAI研究者が必要となるので割愛します。また、ロール（人材類型）ではデザイナーおよびサイバーセキュリティはユースケースおよび構築するシステム次第となるため割愛します。
次に、社内のリソースを活用した内製化チームのみで実装するか、外部ベンダーも頼るか検討が必要になります。①と②は内製化チームのみで対応可能です。
①はプロンプトエンジニアリングや、利用ルールの取り決めといった社内調整が主なタスクとなります。
②はSlackをフロントエンドに活用したシステム構築を例にすると、OpenAIのAPI仕様に沿ってアプリの開発をします。ビジネスアーキテクトはPMと社内コンサル、ソフトウェアエンジニアはシステム構築を担います。
③はシステム構築の他に、外部DBの準備が必要となります。その外部DBを準備するために、データサイエンティストのロールが必要となりますが、もう少し深掘りしたいと思います。
「データ利用」をするためには、「データ準備」が重要になります。外部DBに投入するデータ（例：QA集）が初回のみであるか、継続的にデータを追加するかで、後段で解説するシステム化に大きく影響します。
教科書的に言うと以下のA.〜D.の流れとなりますが、多くの会社ではA.とB.はシステム毎に所管する組織や情報システム部が代行しているかと思います。実際にシステム開発を始めると、必要なデータの準備のために社内調整に時間がかかり、プロジェクトの遅延、必要なデータの取得ができないなど問題が発生します。プロジェクト開始前にデータを所管する組織とコミュニケーションを取ることが重要です。
データ準備
A.データスチュワードが、組織全体のデータを管理
B.データエンジニアが、対象のカタログからETLツールを作成
C.データサイエンティストが、データ加工データ利用
D.データサイエンティストが、加工されたデータをもとに分析
8.システム化の検討
システム化においては、導入予定のシステム単体となるのか、複数システムを跨ぐかによって、開発規模が大きく異なります。「データ準備」でも触れましたが、他組織が所管するデータを活用する場合、どのようひデータを取得する仕組みを作るかが重要です。APIが用意されているシステムであれば容易にシステム開発は可能ですが、多くのシステムはそのような仕組みはなく手組みで開発が必要になります。またデータの更新タイミングやメンテナンス等にようにデータ不整合が発生する可能性も秘めています。
また、ユースケースによっては、追加でシステム開発が必要になるかもしれません。
例えば、NTTコミュニケーションズの「生成AIデジタルヒューマンをドラッグストアの従業員として提案」（出典：NTTコミュニケーションズ）を参考にします。同社ではないのですが、デジタルサイネージを活用した商品提案のシステム開発を担当したことがありますので解説します。
お客様との会話については、以前のAIでは苦手だったロングテールの会話（「今日の天気は？」等）が、生成AIの登場により格段に良くなりました。また、在庫情報との連携もできるようになりました。
一方で、デジタルサイネージを活用した商品提案をする場合、商品画像を見せる必要があります。製品が増えるごとにデジタルサイネージに合わせた画像（解像度、向き等）を用意し、外部データとして用意しなければならず、継続的に運用するためにはコストがかかる問題があります。
（将来的にはデジタルサイネージに表示されるコンテンツも自動生成できるようになるとは思いますが、現時点ではできません）
また、音声で会話をする場合、音声をテキストに変換、返答テキストの生成、コンテンツの拾い出し、テキストを音声に変換と、レスポンスに時間がかかります。5秒以上反応がないと間がキツくなるので、デジタルサイネージ側でユーザーを飽きさせない工夫も必要になります。
9.継続的な開発（野良ボット対策）
最後に、継続的な開発の話をします。野良ボットはご存知でしょうか。野良犬からの造語で、管理・メンテナンスがされていないチャットボットのことです。
なぜ、野良ボットが生まれるのか。「利用されなくなった」「担当者が変わった」等、色々理由があると思います。システム開発前に継続的にメンテナンスができる状態か（内製化、外部委託等）、検討をすべきです。
また、社内向けのAIを活用したシステムとする場合、ユーザーへの教育も重要です。チャットボットを構築する場合、利用率がKPIとしていることが多くあると思います。感覚的には、利用対象者の30％〜40％が利用していれば非常に高い利用率といえます。一人でも多くの利用者を増やすために訴求活動やコミュニケティの構築等をしていくことが必要になります。
最後に
今回はポイントをまとめましたが、実際のプロジェクトでは会社の環境、ベンダーとの関わり、予算等の要素からプロジェクトの進め方をカスタマイズする必要があります。