最近は日常の中で生成AIを使うことが当たり前になってきました。 調べものを手伝ってもらったり、文章を整理してもらったり、夕食の献立を考えてもらったり。 私自身も日々の生活の中で生成AIを活用していて、 気づけば 「優秀な助手」 のような存在になっていました。 生成AIは、私たちの作業をサポートしてくれるとても便利なツールです。

私は今回、生成AIを活用したDXプロジェクトに関わることになりました。

対象は医療現場におけるある業務プロセスです。 医療の現場では多くの業務が日々行われており、その中には専門知識や経験に依存するプロセスも少なくありません。

そこで今回、生成AIを活用して業務プロセスを支援できないかという検証が行われることになりました。

今回扱うことになった技術「RAG」

今回のシステムでは、RAG（Retrieval Augmented Generation）というアーキテクチャを扱うことになりました。

RAGは、外部のデータを検索し、その情報をもとに生成AIが回答を作る仕組みです。 一般的なLLMは幅広い知識を持っていますが、 当然ながら特定の業務に関する情報をすべて知っているわけではありません。 そのため、必要な情報を外部データから取得し、それをコンテキストとして与えた上で回答を生成するというのがRAGの基本的な考え方です。

LLMに知識を扱わせる2つの方法

生成AIに特定の知識を扱わせる方法はいくつかありますが、代表的なものとして次の2つがあります。

① モデルを追加学習する方法（Fine-tuning）

1つ目は、モデルを追加学習する方法（Fine-tuning）です。 特定のデータを使ってモデルを再学習させることで、専門的な知識やタスクへの適応を行います。

メリットとしては、以下の点があります。

• 特定のタスクに最適化できる
• 推論時に外部検索が不要

一方で、次のような運用面の課題もあります。

• 学習用データの準備が必要
• モデルの再学習コストがかかる
• 知識を更新するたびに再学習が必要

② 外部データを検索する方法（RAG）

もう1つが、RAG（Retrieval Augmented Generation）です。

RAGでは、モデル自体を学習させるのではなく、 外部のデータベースから関連情報を検索し、その内容をコンテキストとして与えた上で回答を生成します。

この方法のメリットは、以下の点です。

• モデルを再学習せずに知識を扱える
• データを更新すればすぐ反映できる
• 情報源を管理しやすい

ただし、次のような課題点もあります。

• 検索精度に回答品質が影響される
• データ構造や検索設計が重要になる

今回のプロジェクトでは、このRAGのアーキテクチャを前提としたシステムを構築することになりました。

AIを「使う」のと「作る」のは全然違う

これまでの私は、AIを「使う側」でした。 困ったときに質問したり、アドバイスをもらったり。しかし今回の開発では、 AIをどう動かすかを設計する側になります。

つまり、

• どの情報を取得するのか
• その情報をどうプロンプトに渡すのか
• どのように回答を生成させるのか

といった部分を設計する必要がありました。

AIは優秀な助手ですが、どう働くかを決めるのは開発者側です。

AIを使うことと、AIを基盤としてシステムを作ることは全く違う。

この視点の違いに気づかされました。

RAGを実装してみて分かった難しさ

実際にRAGの仕組みを構築してみると、思っていたよりも難しい部分がいくつかありました。

例えば、最初の頃はAIにこんな質問をしていました。

「〇〇について教えて」

しかし返ってくる回答は、どこか的外れなものばかりでした。 RAGで情報を取得しているはずなのに、期待している答えになりません。 原因を調べていくと、質問が抽象的すぎたことに気づきました。

「〇〇について教えて」という問いは一見シンプルですが、

• 用語の意味を知りたいのか
• 仕組みを知りたいのか
• 関連情報をまとめてほしいのか

AI側からすると、意図がはっきりしません。 つまり、AIが何をすればいいのか分からなかったのです。

• 何を知りたいのか
• どの観点で回答してほしいのか

を具体的に指示するようにすると、回答の精度は大きく改善しました。

このとき感じたのは、

「何が知りたいのかを具体的に伝えないといけないのは、AIも人間も同じだな」

ということでした。

もう一つの想定外の壁

もう一つ、想定していなかった壁もありました。 それは 医療データ特有の表現です。

医療分野のデータを扱っていると、生理現象や排せつなどに関するワードが自然に登場します。 しかしLLMには安全性の観点からコンテンツフィルタが組み込まれており、特定の表現が含まれると処理が制限されてしまうことがありました。 その結果、本来は医療文脈として問題のないデータでも、 AI側ではコンプライアンス上の理由で処理できないケースがありました。

医療の世界ではごく普通に使われる言葉でも、 一般的なAIサービスでは想定されていないケースがあるのだと実感しました。

AIを使ったシステムを作るときは、 モデルの性能だけでなく こうした制約も含めて設計する必要があるのだと学びました。

AI開発で感じたこと

今回の開発を通して感じたのは、 AIを使うことと、AIをシステムとして扱うことは全く別の体験だということでした。

普段、生成AIを使うときは「質問をすれば答えてくれるツール」という感覚があります。 しかし実際にシステムとして組み込むと、

• どのように質問を構造化するのか
• どのデータを取得するのか
• どんな形で回答させるのか

といった設計が必要になります。

また、これまでのシステム開発との違いも強く感じました。これまでエンジニアとしてコードを書くときは、書いたコードは基本的にその通りに動くものでした。ロジックを実装すれば、その通りに処理が実行されます。

しかしAIを使ったシステムでは、こちらの指示が必ずしも意図した通りに伝わるとは限りません。同じ質問でも回答が変わることがあったり、指示の仕方によって結果が大きく変わることもあります。

• 質問が抽象的すぎると意図が伝わらない
• データの構造によって検索精度が変わる
• 業界特有の表現がAIの制約に引っかかる

こういった部分を考慮して試行錯誤しながら調整していく必要がありました。

AIはとても便利なツールですが、 どう働くかを決めるのは開発者側の設計です。 今回の開発は、 これまでのようにAIを「使う」だけではなく、 AIを「設計する」視点を学ぶ経験になりました。

◆Ribertéについて◆

「ゆたかな未来のきっかけを。」

働くことがすべてではない社会。
会社員は副業。そんな未来もあっていいんじゃないか。
Ribertéは一人一人が本来持っている、人生のゆたかな未来を届けます。
お互いの個を尊重し、自分を成長させ、ゆたかな未来を広げます。

「姿勢を重んじ、手を汚して共に学ぶ組織」

Ribertéが最も重視しているのは"姿勢"です。
お客様と共に新しい技術や方法を学び、泥臭く、手を汚しながら、解決策を実行に移します。
"できない理由"を探すのではなく、"どうすればできるか？"を自ら考え、判断し、
必要なリスクを取って、迅速に行動。
そんな起業家精神の文化に、大きな目標に向かって刺激のあるチームで協力し切磋琢磨して、
仕事を楽しむ。
これこそが、"Ribertéの最大の価値"だと考えています。

合同会社Ribertéでは一緒に働く仲間を募集しています