皆さん、メリークリスマス！
今年もクリスマス近辺の投稿枠を狙ってやってきました、クリスマス男のぶくろです。今年もOpenStandiaのAdvent Calendarに参加しています。
昨年はBI を導入しよう！ Power BI と Tableau と Domo と Qlik を比較してみたという記事を書きましたが、今年は生成AIに関する取り組みについてお話ししたいと思います。
対象読者
- 「生成AI案件立ち上げたい！」と考えている方
- 「立ち上げたけど何したらいいかわからない！」と悩んでいる方
ご注意
- AOAI等を利用した開発Tipsなど具体的な話は登場しません
- 情報漏洩防止の観点で曖昧な記載、抽象度の高い表現があります
本題
活動背景や状況
2023年後半に「生成AIの活動を始めよう」という話が持ち上がりました。この記事ではちょうど1年経って、AI案件をやるにあたり「何が大事だったか」を振り返ります。生成AIどころかAIすら素人な筆者がキャッチアップに使ったものとして、以下の資料を参考にしました。
- 生成AIのキャッチアップに使った参考資料
- 内部仕様の理解：Attention is All you need
- サービス仕様の理解：Azure AI Search 公式ドキュメント
- 生成AI適用の考え方の理解：METI/AI事業者ガイドライン
- AI事業者ガイドラインに関しては筆者が勉強会向けに要約したものも合わせてご参照ください
本記事はAI事業者ガイドラインに則り、案件の活動が位置づけられる「AI提供者」(活動A)のパートと、それに派生して立ち上がった部門内特定業種プロジェクトへの生成AI活用を支援する「AI利用者」(活動B) のパートの2部構成で紹介します。
生成AI導入活動
【活動Ａ】AI提供者としての活動
生成AIを活用する業務のターゲティングはもちろん、必要な機能のディスカッションを行い、下図（モック）のような画面を開発チームに実装していただきました。
概ね現在世に出ている生成AI系サービスと大きく差異のないUIになっているかと考えています。
クイックに活用をはじめるため、画面デザインにはコストをかけすぎず、利用イメージをつけていくことを優先しています。
また、RAGの機能では回答に加えて、回答に用いた参照元情報がどのようなファイルかプレビュー＋ダウンロードできる機能になっています。
PoC的に利用を進めていく中で業務の情報を扱う需要が高まってきました。
そこで扱われる情報の機密性を確認し、情報セキュリティ担当者や部門内と機密度の高い情報に対して以下のような機能的アプローチ or 運用的アプローチの議論を実施しました。
| 対応したリスク | 対応方法 |
|---|---|
| 機密性の異なる部門内ファイルが混在することにより、生成AIが関係者外へ情報を提供する | データソース（部外秘、部門内研修資料など機密性の異なるファイル群）ごとにインデックステーブルを分け、RAG利用時に画面からデータソースを選択できるようにする |
| 生成AIからの回答の根拠となるデータソースが本来持ち出し禁止のファイルで画面から持ち出される可能性がある | データソースの機密性に応じて引用元ファイル名の表示だけ行い、ダウンロードやプレビュー表示ができないようにした |
| 生成AIからの回答を利用者が鵜呑みにして誤情報が出回るリスクがある | 回答に注意書きを行い、回答にハルシネーションが含まれる可能性を示唆し、必ず利用者で内容チェックをするよう促した |
AI提供者の立ち上げ時の動きとしては
- すぐ使える環境を クイックに提供 できる
-
セキュリティリスクの対応を優先的 に行う
- 扱われる情報の機密性を分類し、それぞれにあわせたアプローチを決める
- 全てを機能で対応するのではなく 運用で回避するべき 部分も決める
といったことが大事だったと考えています。
【活動Ｂ】AI利用者の支援活動
活動Bについては、活動Aにより構築された生成AI（RAG）基盤をもとに、特定部署にて顧客からの問合せ回答（①）と議事録の要約（②）で生成AIを活用する活動を行いました。
活動概況
-
①問合せ回答のユースケース
- 問合せ回答の検討はWIPな状態で、チューニングなしだと20-25%の回答しか「ほぼ完璧」な状態になく、他は実用不可あるいは人力での修正が多数となることがわかっています。
- これについてはWIPな部分もあるため詳細は割愛します。
- 問合せ回答の検討はWIPな状態で、チューニングなしだと20-25%の回答しか「ほぼ完璧」な状態になく、他は実用不可あるいは人力での修正が多数となることがわかっています。
-
②議事録の要約
- 同じような会議を数百回というオーダーで行う業務があり、その議事録の要約に対して生成AIを活用できないか検討しました。
- 対象の打合せは同様のアジェンダで200-300の対象者にヒアリングを行うもので、議事録フォーマットも決まっているものでした。
- この活動を「プロンプトエンジニアリング」の "エンジニアリング" 部分に着目して考えてみました。
議事録の要約
通常のエンジニアリング、特にシステム開発における工程は下図のようになります。
これを議事録要約のプロンプトエンジニアリングに当てはめると以下のようになると考えました。
要件確認～プロンプト作成
要件には「全ての打合せでアジェンダ・ヒアリング項目が同じ」「議事録として整理したい項目も同じ」「特定の業界用語や略語を使って会話する」といったことがあり、それを踏まえてプロンプトにはアジェンダの骨子、アウトプットの項目（議事録の要点）、用語などを記載しました。
打合せの実施（文字起こし＋プロンプト適用）～コンテキスト確認
本来であれば「議事録の作成」「作成した議事録のチェック（誤字脱字レベルから内容・要点まで）」はアウトソースし、人力で行う部分となります。
今回はそのうちの「議事録の作成」「作成した議事録のチェック（誤字脱字レベルから字句・構文の意味確認まで）」が生成AIにより工数削減することができました。
削減できなかったのは会議のコンテキストを文章化する部分で、特に「前の打合せで話した」「対面で会った時に話した」などの本会議中に出現しなかったトピックに関する言及は人が補足・確認しなければならないことになりました。
結果
今回の対象の打合せは「同じ内容を別々の人に200-300回繰り返す」というもので、生成AIを活用するために要するプロンプトの作成等のコストが上がっても、繰り返すからこそ「文字起こし」から「意味確認」で下げられるコストの削減によって打ち消されるようにできると考えました。
そのため、（生成AIに限らずではありますが）生成AIの適用の前に「準備にかかる工数」と「削減される見込み」の工数がどの程度になるのか、ということを見定めておく必要があると考えています。
おわりに
最後に伝えたいのは「生成AIの導入対象は繰り返し行われる業務であること」に使われるとよいのではないかと考えています。議事録作成の事例で示した通り、導入コストが高いのでコスト回収できるような業務を対象にすると生産性向上に繋がるのではないかと感じました。
たとえば、本記事は「 生成AIに全て書かせて細かい手直しだけする 」をポリシーに記載しました。
これをすることにより来年も骨子・コンテンツを箇条書きで書くだけで全体の文章は生成AIが書けるようになった（＝私が楽になる）のではないかな... と考えています。
参考になれば幸いです！ それではまた！