re:Invent 2025: Agentic AIで製薬文書ワークフローを変革するScriptivaの取り組み
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Reinventing Pharma Document Workflows to Unlock Value at Scale with Agentic AI
この動画では、ZSのパートナーであるPranava GoundanとRaghav Sharmaが、agentic AIを活用した製薬文書ワークフローの変革について解説しています。単一の臨床試験で90以上の規制文書が必要とされ、約10人年の労力がかかる現状の課題を指摘し、Scriptivaというアクセラレーターを紹介しています。このソリューションは、ナレッジレイヤー、エージェントオーケストレーションフレームワーク、デジタル化サービスなどで構成され、テンプレート管理やMicrosoft Wordプラグインを通じてメディカルライターの作業を支援します。プランナーエージェント、オーサリングエージェント、クリティークエージェントが連携し、監査可能で規制対応したコンテンツを生成することで、臨床開発プロセスを約3ヶ月短縮し、患者への医薬品提供を加速させることを目指しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
製薬文書ワークフローの課題とagentic AIによる解決の可能性
皆さん、こんにちは。本日のトークにご参加いただきありがとうございます。私の名前はPranava Goundanと申しまして、ZSのパートナーを務めております。ライフサイエンスR&D AI能力を統括しております。皆さん、こんにちは。私の名前はRaghav Sharmaと申しまして、ZSのパートナーで、ニューデリーオフィスを拠点としております。私は医薬品開発プラクティスのテクノロジーを統括しており、クライアントの医薬品開発ライフサイクルの旅を加速させるための次世代アセットとアクセラレーターの構築に注力しております。ここに来られてとても嬉しく思いますし、このセッションに参加するためにお時間を割いていただいた皆様に心から感謝申し上げます。それでは、Pranavaに今日のキックオフをお願いしたいと思います。
ええ、もちろんです。では、会場にいらっしゃる皆さんの中には、これがすでに非常に重要な問題だと思われている方もいらっしゃるかもしれません。一方で、なぜこれが取り組むべき重要な問題なのか、つまりagentic AIで製薬文書ワークフローを改善することがなぜ重要なのか疑問に思っている方もいらっしゃるでしょう。では、まず臨床試験開発プロセスを見てみましょう。皆さんの多くがご存知のように、 治療法を市場に投入するためには、規制当局が監視し監督する非常に広範な臨床試験を実施します。
さて、今日これらのプロセスにおいて臨床試験を実施する際、単一の臨床試験について、例えば臨床研究が実施される5年から8年の期間にわたって、規制当局に提出する必要がある文書が90以上あります。これは最初に臨床試験のプロトコルを申告することから始まり、臨床研究の結果を提出し、承認を得るために規制当局に提出するところまで続きます。さて、これは今日非常に時間のかかるプロセスです。提出されるこれら90以上の文書を作成するために、ほぼ10人年分の労力が費やされています。これは臨床試験プロトコルを作成したり、インフォームドコンセントフォームやこれらの文書全体を作成するメディカルライターの仕事です。
そして想像できるように、その作成作業の多くは反復的な労力であり、実際には多くの低価値タスクを含んでいます。では、これらの低価値タスクはどこから来るのでしょうか。さて、臨床試験プロトコル文書を書こうとすると考え始めると、参照する可能性のある入力文書の多くは、レビューしなければならない他の文書であることに気づき始めますが、消費しなければならないデータソース、構造化されたデータソースもあります。残念ながら今日、ライフサイエンスにおけるデータエコシステムは多くの分野で非常に断片化されていることがわかっているため、適切な情報を見つけ、文書に組み込む可能性のある適切な情報を入手することに労力がかかります。
そして明らかに、さまざまな異なるデータソースを扱っている場合、それはエラーの可能性につながります。多くの場合、規制当局がこれらの文書に特定のテンプレートに従うことを要求しているにもかかわらず、私たちが組織から組織へと仕事をする中で見つけることは、これらのテンプレートが、単一の組織内でさえも標準化されていないということです。テンプレートが時間とともに進化してきたため、または異なる治療領域にわたる医薬品の異なる提出が異なるテンプレートを使用しているため、または異なる地域が異なるテンプレートを使用しているために、テンプレートの変種が存在しています。
もちろん、この全ての作業は非常に手作業が多いです。ドキュメントを作成して提出する際に、これら全ての情報をまとめることを考えると、明らかに手作業が集中的に必要になります。そして最後に、これらのドキュメントは規制当局に提出する必要があるため、広範囲にわたる慎重なレビューを経ます。しかしレビュープロセスもまた人間主導のプロセスであり、ある専門家から別の専門家への引き継ぎがプロセス全体を通じて遅延や非効率性を生み出し、実際にリスクの可能性につながります。
これが現在の臨床ドキュメント作成の文脈におけるプロセスです。そして皆さんに思い出していただきたいのは、臨床ドキュメント作成は製薬ワークフローにおける唯一のドキュメント生成ではないということです。彼らは医師と関わるために医療プロセスでドキュメントを生成しなければなりません。治療法を商業化するためにドキュメントを生成し、規制当局と継続的に関わるためのドキュメントを作成する必要があります。ですから、このようなものを通じて推進できる影響の範囲は非常に劇的です。
agentic AIでこれをどのように解決できるでしょうか？私たちにとっての機会は次の通りです。ドキュメント生成自体をサポートするだけでなく、適切なagentic AIワークフローを開発できるでしょうか？過去数年間に起こったLLMと技術の進化により、それらがコンテンツ生成に非常に優れていることは分かっています。また、実際にデータを処理することにも非常に優れています。ですから、最終的にドキュメントに変換される必要がある全ての入力データ処理について考えると、そのデータ生成の多くもagentic AIワークフローによって強化することができます。
しかし、それだけではありません。これらの規制提出において、必要とされるドメインを深く組み込む必要があります。全ての知識、科学的知識、規制に関する知識がこのプロセスを通じて組み込まれなければならず、それにはワークフロー自体にインテリジェンスを組み込むことが必要です。
デジタル化された方法で、単一のドキュメントだけでなく、ドキュメントのエコシステム全体に対して再利用性を推進できるようにします。最後に、機会は、これをエンタープライズスケールで実行できるかということです。今日存在する全てのシステムを変更したくありません。入力の観点からも出力消費の観点からも、今日存在する記録システムにシームレスに接続できるようにしたいのです。これら全てを正しく実行できれば、単一の臨床試験で約3ヶ月のタイムライン短縮を推進できます。ですから、臨床開発プロセスだけでも可能性は非常に大きいのです。
ドキュメント中心からプロセス中心への発想転換とScriptivaの紹介
もし私たちがagentic AIを活用したプロセス変革を推進することで、臨床開発プロセスを累計で約3ヶ月短縮できれば、それは患者さんにより早く医薬品を届けられることを意味し、これは大きなインパクトのあるステートメントです。それでは、私たちがドキュメント作成についてどのように考えているか、少しお話ししたいと思います。私たちにとって大きな洞察は、ドキュメントの作成を個別のドキュメントとして考えるのをやめるべきだということです。今日、私たちは臨床試験プロトコル文書や同意説明文書、あるいはさらに下流の臨床試験報告書の作成について考えています。個別のドキュメント作成に焦点を当てるのではなく、ドキュメントは単なるアウトプットとして考えるべきなのです。
実際、ドキュメントを作成するプロセスは、データの変換、データの統合、知識の導出、そしてその知識をドキュメントに埋め込むという広範なプロセスです。では、どうすれば適切なエンドツーエンドのagent対応ワークフローを構築し、それらのワークフローを最適化できるでしょうか？最適化の多くは、実際には人とプロセスの変革です。そして、コンテンツの再利用を促進する方法でこれをどのように行うのか？つまり、ドキュメント中心で考えるのではなく、私たちのアドバイスは、このプロセス全体をプロセス中心の変革そのものとして考えるべきだということです。そして、それが私たちが行ってきたことです。
さて、多くの皆さんは、では実際に何を作ったのかと疑問に思っていることでしょう。それでは、私たちが作成したコア技術をお見せする短いデモに移りたいと思います。これはScriptivaと呼ばれるアセットベースです。同僚のRavに引き継ぐ前に、短いデモでご紹介します。
Scriptivaのアーキテクチャとナレッジレイヤーを核としたエージェント連携の仕組み
さて、これが私たちのアクセラレーターScriptivaのデモでした。私たちはこれを複数のクライアントで使用し、ドキュメント作成の取り組みを加速させるお手伝いをしてきました。デモでご覧いただいたように、Scriptivaはテンプレート管理、プロンプト管理、マッピングルールエンジン、そしてMicrosoft Wordプラグインベースの作成体験といった、すべての基盤機能を提供します。これは、メディカルライターが今日行っている作成方法と非常によく合致しています。そして、ここで重要な説明をさせていただきたいのは、Scriptivaはプロダクトではないということです。ScriptivaはSaaSオファリングではありません。クライアントのエコシステム内でカスタマイズして組み込むことができる、アクセラレーターベースのモデルなのです。
私たちは、すべてのクライアントが異なるテクノロジーと異なるプラットフォームに投資していることを理解しています。彼らには独自のSOPとワークフローがあります。このように、アクセラレーターモデルは、エージェントやプロンプト、テンプレートなどの選択的なコンポーネントを選んでカスタマイズし、クライアントのエコシステム内に組み込むことができる柔軟性を提供します。それでは、Scriptivaソリューションがどのように動いているのか、その内部を見ていきましょう。まず非常に高レベルなソリューション概要から始めますが、私たちのソリューションアプローチは、ケーキとキャンドル戦略と呼ばれるものに基づいています。ここでのケーキは、エンタープライズグレードの基盤プラットフォームを表しています。
ここにあるキャンドルは、今日このプラットフォームによって実現される様々なドキュメントを表しています。このプラットフォームが実現する必要のある基盤的な機能についていくつか触れるとすれば、デジタル化サービス、エージェント開発フレームワーク、オーケストレーションエンジン、そしてナレッジレイヤーなどがあります。この水平的なプラットフォーム、つまりケーキを確立すれば、このプラットフォームをセットアップするための初期投資は必要ですが、ドキュメントやデータのランドスケープ全体にスケールしていく際に、新しいドキュメントやデータのユースケースをオンボードする時に非常に高い効率性が得られます。データと言う時、同じプラットフォームがSTDM生成、ADaM生成、TLG生成、そしてCSRオーサリングに至るまで、すべてを自動化する機能を実現します。
それでは、ソリューションの情報アーキテクチャに移ります。私たちはAWSテクノロジースタックを使用してソリューションを開発しました。これはレイヤードアーキテクチャです。すべてのコンポーネントには触れませんが、ソリューションの基盤となるコンポーネントのいくつかについてお話しします。このページを下から上に向かって読んでいくと、最初の基盤レイヤーはデジタル化レイヤーです。なぜこのレイヤーが重要なのでしょうか?それは、すべてのソースデータが、エージェントが利用できる機械可読形式で利用可能にされる必要があるからです。これらのソースシステムは、上流のドキュメント、プロトコル、ICFフォーム、CSRなどの過去のドキュメントを表しており、これにはメタデータ仕様のデジタル化も含まれます。基本的に、エージェントがオーサリングプロセスを実行できるようにするために必要なすべてのものです。
このデジタル化レイヤーが確立されると、次に重要なレイヤーはナレッジレイヤーです。これはソリューション全体の頭脳と言えるでしょう。このレイヤーは、ドキュメント、データ、マッピングルール、関係性など、すべての点を結びつけます。ナレッジレイヤーの重要性を例で説明すると、例えばICFドキュメントのあるセクションがオーサリングされたとします。このナレッジレイヤーは、上流のドキュメントは何だったのか、下流のドキュメントの特定のセクションをオーサリングするために使用された上流のドキュメントのセクションは何だったのか、このセクションをオーサリングするために使用されたプロンプトは何だったのか、このセクションのオーサリングに関与したエージェントは何だったのか、という情報を保持しています。
基本的に、このレイヤーはソリューションを監査可能な状態にすることを可能にし、また非常に基本的な運用ユースケースを処理するのにも役立ちます。例えば、プロトコルは修正が行われることがよくあります。プロトコルの修正が発生した場合、このナレッジレイヤーは、プロトコルのあるセクションが変更されたため、更新が必要な下流のドキュメントはこれらですという情報を提示します。ある意味で、このナレッジレイヤーは、ドキュメントの山を、よく接続された、追跡可能で、インテリジェントなドキュメントのネットワークに変換し、それによってエージェントが正確で、監査可能で、規制に対応したコンテンツを生成できるようにしているのです。
これら2つの基盤レイヤーが確立されると、次のレイヤーはテンプレート管理とプロンプト管理になります。ここでは、ユーザーがテンプレートの異なるバージョンと関連するプロンプトを管理するための機能を提供します。この上にあるのがエージェントオーケストレーションフレームワークで、オーサリングに必要なさまざまなエージェント、例えばオーサリングエージェント、プランニングエージェント、クリティークエージェントなどが展開され、セットアップされます。最上位には消費レイヤーがあります。消費レイヤーの例としてはScriptivaがあります。ライブアシスタントやコパイロットアシスタントを用意することで、メディカルライターが今日の執筆体験を容易にすることができます。
それでは、ソリューション概要の最後のセクションに移ります。これは少し詳細なビューで、ナレッジレイヤー、エージェント、ツール、そしてメモリの構成要素が、どのようにすべて連携してエンドツーエンドのオーサリング体験を実現するかを説明しています。これも例を使って説明しましょう。メディカルライターとして、ドキュメントを選択し、おそらく1つのセクション、または複数のセクションをオーサリングするとします。この情報がプランナーエージェントに渡されるとすぐに、プランナーエージェントはナレッジレイヤーにアクセスします。特定のセクションをオーサリングするために必要な上流のドキュメントは何か、上流のデータソースは何かという情報を取得します。また、そのセクションをオーサリングするために必要な変換ルールを取得するためにもナレッジレイヤーにアクセスします。これは単純なコンテンツのコピー&ペーストなのか、コンテンツの要約なのか、それとも何らかの計算が必要なのか、といったことです。
プランナーエージェントがこれらすべての情報を取得すると、アクションプランを生成し、さまざまなエージェントのオーケストレーションを開始します。この例として、プランナーエージェントはオーサリングエージェント、トーンリファインメントエージェント、そしてクリティークエージェントを呼び出して、適切な情報を生成します。
本質的に、これらすべてのエージェントは、さまざまなツールのスイートによって動作しています。ツールレイヤーの例としては、データコピーツール、テーブル抽出ツール、または画像抽出ツールがあります。これらすべてのツールが、エージェントがその仕事を実行できるようにしているのです。そして、これらの異なるエージェント間でこれらすべてのインタラクションが行われている間、すべての情報はメモリレイヤーに保存されます。
このメモリー層はユーザーフィードバックも保存します。つまり、エージェントが特定のセクションを生成し、メディカルライターがそれに編集を加えた場合、その情報がメモリーに保存されるため、次回の反復では、それがオーサリングエージェントへのフィードバックループとして機能します。このようにして、ナレッジ層、エージェント、ツール、そしてメモリーの構成が一体となって、エンドツーエンドのオーサリング体験を完成させます。ということで、これで全体的なソリューションアプローチと、内部で異なるエージェントとナレッジ層がどのように連携してエンドツーエンドのオーサリング体験を実現しているかについての説明を終わります。それでは、Pranavaに戻して、プレゼンテーションを締めくくってもらいます。
技術とドメイン知識の融合によるワークフロー変革の実現
ZSがどのようにドキュメント生成ワークフローを変革するための技術基盤を構築し、変革しているか、少しでも垣間見ていただけたかと思います。 しかし、それはあくまで技術面だけの話です。この取り組みの大きな部分として、私たちのプレゼンテーションのタイトルを振り返ってみても、プロセス変革そのものが重要であり、ワークフロー変革はこの側面の中核的な要素となっています。今日のプレゼンテーションではそこには触れませんでしたが、私たちは少なくともトップ10のライフサイエンス企業のうち4社と協力し、このドキュメントオーサリングエコシステムをエージェンティックワークフローで構築し、変革してきた経験という恩恵を受けています。
私たちは、Raghavが説明したこれらすべてを構築するために必要なデータとテクノロジーを理解する能力だけでなく、それを臨床文書生成、実際には製造文書生成、そして他の様々な文書生成において今日行われているワークフロー全体に関する深いドメイン経験と深いドメイン知識と組み合わせることが、重要な要素であると考えています。そして最も重要なのは、これらの薬や治療をより早く患者さんに届けるためのタイムライン短縮という、私たちが約束した影響を実際に実現するために、これらをどのように統合するかということです。これこそが私たちを差別化するものだと考えており、皆さんとお話しできることを大変嬉しく思います。
今日は概要をお伝えしただけだと思います。このトーク後にご質問があれば、喜んでフォローアップさせていただき、皆さんと関わり、私たちが取り組んできたことについてもう少し詳しくお話しさせていただきます。皆さん、本当にありがとうございました。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion