生成AIの答えは、どこまで仕事で使えるのか。製薬・規制業務で問われる「根拠」

製薬・ライフサイエンス領域でも、生成AIを専門文書の作成工程へ組み込む取り組みが公表され始めています。

治験関連の情報から必要な内容を抽出し、複数の情報を整理した上で規制関連文書の初稿作成を支援するなど、生成AIの利用先は、個人の文章作成やアイデア出しから具体的な業務プロセスへ広がっています。

実証段階では文書作成時間の削減が確認された事例もあり、AIが専門文書の初稿を作れるようになった先で、担当者の仕事がどう変わるのかを考える段階に入りつつあります。

初稿が早くできた後にも、確認する仕事は残る

生成AIが作った文書を開けば、必要な情報が整理され、文章として読める状態になっています。

これまで一から書いていた初稿が短時間で用意されれば文書作成にかかる時間は変わりますが、その後、担当者は記載された情報がどの資料を基にしているのか、参照した情報は現在も有効なのかを確認します。

複数の資料に異なる記載があればどちらを使うべきかを判断し、気になる記述があれば元の資料へ戻るため、初稿作成が早くなっても、関連資料を一つずつ探し直して文章の根拠を最初から確認するのであれば、確認に使う時間は大きく残ります。

生成AIを仕事へ組み込むなら、何を生成できるかだけでなく、生成後の確認作業まで含めて仕事がどう変わるのかを見る必要があります。

モデルの回答精度が上がっても、担当者が毎回同じ資料探索を繰り返していれば、文書を書く時間が別の確認作業へ移っただけで、業務全体が変わったとは言えません。

文書を探せるようにすると、次の問題が見えてくる

ディーシステム社内でも、申請書などの業務文書を検索可能にする取り組みを行っています。

規制関連文書の初稿を生成する仕組みとは業務も目的も異なりますが、これまで人がファイルやフォルダを探していた業務文書を検索し、利用しやすい状態へ変えようとすると、似た種類の問題が見えてきます。

必要な文書へ早くたどり着けば資料を探す時間は減らせますが、実際の仕事では、検索対象にどの文書を含めるのか、似た名称で作成時期の異なる文書があればどれを参照するのか、検索結果を確認したいときに元の文書へどう戻るのかという判断が続きます。

文書が更新された後、新しい内容をいつ利用できる状態にするのか。扱う情報によって利用できる人が異なるなら、誰が何を参照できるのかも整理しなければなりません。

検索機能によって文書を見つける方法が変わっても、その情報を次の仕事へ使うための確認を毎回担当者個人へ戻してしまえば、新旧の確認や元資料の探索は人の作業として残ります。

AIが何を使ったのか分からなければ、担当者が探し直す

専門文書の初稿へ生成AIを使う場合、この問題はさらに具体的になります。

AIが作った文章に違和感がなく、自然に読めたとしても、担当者は文章の読みやすさだけではなく、どの情報を使って書いたのかを確認したい場面があります。

参照対象が曖昧なら、生成された文章を読んだ後に関連しそうな文書を探し、どこに同じ記載があるのかを確認することになるため、AIが情報を探す時間を短縮していても、人が根拠を探し直せば、同じ探索作業が別の工程へ移ります。

どの情報をAIが利用できるのかを整理し、業務上必要な場面で元の情報へ戻れるようにしておけば、担当者が確認のたびに資料探索を最初からやり直す必要はありません。

元情報へ戻るときに必要な粒度は業務によって異なり、文書単位で確認できればよい仕事もあれば、記載箇所までたどる必要がある仕事もあります。

「出典を表示する機能が必要だ」と先に決めるのではなく、担当者がその業務で何を確認しているのかを見ておかなければ、機能を増やしても確認作業は残ります。

古い情報が残れば、新旧を見分ける仕事が増える

業務文書やルールは、新しい文書の追加や既存資料の改訂によって更新されていきます。

AIや検索の対象に古い情報と新しい情報が混在すれば、担当者は回答を得るたびに「これは現在も有効な情報なのか」を確認することになり、検索導入前にはファイルを探していた人が、導入後には新旧の文書を見比べるようになっただけでは、確認に使う時間は十分に減りません。

情報を更新したとき、その変更をAIが利用する環境へどう反映し、古い情報をどう扱うのか。更新後には、想定した情報が実際に利用されていることをどう確認するのか。

この流れを決めておかなければ回答の確認は担当者の記憶に依存し、「以前とは内容が変わっていたはずだ」と気づける人が異動したり業務を離れたりした後、同じ違いに気づけるとは限りません。

情報の新旧管理はもともと必要な仕事ですが、生成AIが複数の文書から回答や初稿を作るようになると、担当者が資料を読む途中で行っていた確認を、今度は業務のどこで担保するのかを決めなければなりません。

人が確認するなら、AIを使う意味はないのか

生成AIを専門業務へ利用する話をすると、「最後に人が確認するのであれば、AIを使う意味はないのではないか」という疑問が出ます。

文書作成を「文章を書く」という一つの作業だけで見ればそう思えますが、実際の担当者は、大量の資料から必要な情報を探し、該当箇所を抜き出して複数の情報を整理し、文書の構成を考えて初稿を作った後、根拠を確認して業務上問題がないかを判断し、必要な修正を加えています。

これらを一つの作業として扱わず、情報探索や抽出、整理、初稿作成をAIが支援し、人が確認や判断へ時間を使うように分ければ、最後に人による確認が残っていても仕事の流れは変えられます。

さらに、確認したい記載から根拠となる情報へ戻りやすくしておけば、担当者が元資料を探し直す時間も減らせます。

すべてをAIへ任せることを目標にすると、人が行う工程は「自動化できなかった作業」に見えますが、業務を工程ごとに見れば、資料を探す時間を減らし、その分を内容の確認や業務上使えるかを考える時間へ振り向けることができます。

間違いを見つけた後、どこを直すのか

担当者がAIの生成結果を確認して誤りを見つけ、その場で文章を書き換えれば今回の文書は直ります。

しかし、次に同じ種類の文書を作ったときにも同じ誤りが出れば、別の担当者がまた文章を直すことになり、生成時間が短くなっても、組織には同じ確認と修正が残ります。

誤りを見つけたときには、参照している元文書に問題があるのか、古い情報を利用しているのか、AIへの指示が不足しているのかを見ていく必要があります。

情報を抽出する処理に問題がある場合もあれば、生成した文章の確認方法を見直す必要がある場合もあり、原因によって直す場所は変わります。

修正先を整理できれば、その場で生成された文章だけを直すのではなく、次の生成にも反映される場所へ修正を戻せます。

一人が一度だけ使うなら、その場で文章を直した方が早いこともありますが、組織として利用を続けるなら、問題がどこで生まれたのかを追える状態にしておくことで、同じ確認や修正を担当者ごとに繰り返す状況を減らせます。

製薬・規制関連業務だから見えやすい問題がある

製薬・規制関連業務を「規制が厳しいからAIを使いにくい」と捉えるだけでは、AIが作った情報を実際の仕事へ使うとき、担当者が何を確認しなければならないのかは見えてきません。

専門文書へ記載する情報は、文章として自然に読めるだけでは仕事に使えず、どの情報を基にしているのか、現在利用する情報として適切なのか、人はどこを確認し、問題が見つかったらどこへ戻すのかまで考える必要があります。

AIを使い続けるなら、情報や業務が変わった後も同じ方法で運用できるのかを見ることになります。

こうした論点は製薬業務だけのものではなく、NISTの「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」でも、生成AI固有のリスクを組織が目的や優先事項に合わせて管理するためのクロスセクターの考え方が示されています。

NISTの資料では、人による監督のあり方を一律に決めるのではなく、生成AIのリスクに応じて異なる人とAIの構成が必要になり得ることや、設計・開発・利用・評価を通じた管理が扱われています。

生成された回答だけでなく、情報をどう扱い、人がどこで関わり、利用開始後もどのように状態を確認するのかを見る考え方は、製薬以外の企業が生成AIを業務へ組み込む場合にも重なりますが、製薬・規制関連業務では、それが「担当者はこの記載の何を確認するのか」という日々の作業として具体的に表れます。

PoCでは「できるか」を見る。本番では仕事の流れを見る

生成AIのPoCでは、期待する文書を生成できるのか、必要な情報を抽出できるのか、どの程度の精度が出るのか、作成時間を減らせるのかを確認し、新しい技術を業務へ利用できるか判断します。

本番利用へ進むと、どの文書を参照し、生成された内容のどこを誰が確認するのか、確認で見つけた問題をどこへ戻し、文書が更新されたらいつ利用環境へ反映するのかという、AIを使う人の仕事を決めなければなりません。

担当者が変わった後も同じ流れで利用できるのか、利用を続ける中で生成結果の状態をどう確認するのかという運用も加わるため、PoCで生成精度を確認した後、本番ではこうした仕事を一つずつ決めていきます。

モデルの精度をさらに上げても、担当者の確認方法や情報更新の流れまで自動的に決まるわけではありません。

AIを業務の中へ置いたことで、人が行っていた作業のどこが減り、どこに新しい確認が必要になったのかを見るところまで進んで、PoCは現場の仕事の設計へつながります。

モデルを選んだ後にも、設計する仕事が残る

生成AIの議論では、長い文書を扱えるのか、専門的な内容へ対応できるのか、期待する精度を出せるのかといったモデルの性能が注目されます。

モデル選択は業務利用を考える上で必要ですが、同じモデルを使っていても、参照する情報やその更新方法、元文書への戻り方、人が確認する範囲が違えば、現場に残る仕事は変わります。

回答が早くても、根拠を探すために担当者が複数のフォルダを確認すれば探索時間は残り、文書を検索できても、古い情報と新しい情報を毎回人が見分けるなら、その確認は続きます。

AIが初稿を作っても、誤りの原因を追えず、生成された文章だけを毎回修正するのであれば、担当者が変わるたびに同じ確認や修正が繰り返される可能性があります。

技術が動くことと現場の仕事が変わることの間には、誰がどの仕事で使い、導入後にどの作業が残るのかを見る設計があります。

ディーシステムでは、業務システムへ技術を組み込むときに「動いた」という結果だけで終わらせず、生成AIについても、その後の仕事まで見る必要があると考えています。

「生成できた」の先で、仕事を変える

冒頭の規制関連文書作成へ戻ります。

生成AIが治験関連の情報から必要な内容を抽出し、整理した上で専門文書の初稿作成を支援することで、これまで人が文書作成に使っていた時間を減らせるのであれば、その時間を別の仕事へ使えるようになります。

その時間を本当に内容の確認や業務上の判断へ振り向けるには、AIがどの情報を使ったのか、必要なときに元の情報へどう戻るのか、人はどこを確認するのかという、生成された文章の周囲にある仕事まで変えなければなりません。

誤りを見つけたらどこへ戻って直し、文書が更新されたら利用する情報へどう反映するのかまで業務の流れとして決めることで、担当者は資料を探し直したり、同じ確認を繰り返したりする時間を減らし、内容の確認や業務上の判断へ時間を使いやすくなります。

AIが文書を作る時間を短くできたなら、その次は、担当者が資料を探し直す時間や同じ確認を繰り返す時間をどう減らすかまで考える。

生成AIを仕事で使うための設計は、そこまで続いています。

生成AIを、実際の仕事へ組み込むために

生成AIのPoCで成果が見えていても、本番業務へどう組み込み、どの情報を利用して、人がどこを確認するのかを整理する段階で課題が見えることがあります。

生成AIが文章を作れることと、その内容を規制業務で使用できることは同じではありません。

参照した情報は何か。どの記述を根拠にしたのか。誰が確認し、修正し、最終的な責任を持つのか。製薬・ライフサイエンス領域で生成AIを活用するには、回答精度だけでなく、根拠を確認できる業務プロセスと運用設計が必要です。

ディーシステムでは、製薬・ライフサイエンス領域における業務整理、データ活用、生成AIの検証・導入・運用設計を支援しています。

生成AIを規制文書や専門業務へどのように組み込むか、根拠確認やレビュー体制を含めて検討されている場合は、お問い合わせください。

次に読む記事

AI活用を、実証実験で終わらせないために

生成AIが回答を返せることと、その回答を業務で継続的に使えることは別です。

誰が確認するのか、誤りや例外をどう扱うのか、どの業務へ組み込むのか。PoCの後に必要となる運用設計を整理します。

生成AIの出力を、実際の改修でどう確認したのか

生成AIは、コードや修正案を短時間で作れます。

一方で、対象システムの構成、既存機能への影響、実データの条件まで理解しているとは限りません。生成された案を人が検証し、実際の改修へつなげた過程を紹介します。

参照する知識を、現場で使える形へどう整えるのか

生成AIへ社内文書や過去の対応を参照させる場合、情報を集めるだけでは十分ではありません。

何を確認し、どの情報を基に回答したのか。過去の対応を、次の担当者が使える知識へ変えた製薬ヘルプデスクの支援事例を紹介します。