Claude Code創薬活用、JCRファーマが10日で本番稼働の理由

2026年8月4日、「製薬企業向け Claude Code on AWS ワークショップ」が開かれました。10社を超える製薬企業から、創薬研究者と研究IT担当者が集まったとのことです。「規制が厳しい業界ほど、AI導入は遅れるものだ」。僕はこれまで、そう思い込んでいた側の人間でした。ですが今回のワークショップの中身を調べていくと、その前提は崩れていったのです。

参加者アンケート（回答47件）の総合満足度は、4.70/5.00という結果でした。第一三共の研究者は、コーディングエージェントを手放せないとまで語っています。JCRファーマにいたっては、ワークショップからわずか10日で研究部門への展開を始めました。GxPという厳格な承認プロセスを抱える業界で、なぜここまで速く動けたのでしょうか。今日はその中身を、1つずつ丁寧に見ていきたいと思います。

「規制業界はAI導入が遅い」という思い込みが崩れた理由

このワークショップの正式名称は「AIエージェントは創薬研究をどう変えるか」というものでした。主催者はAWSです。対象は、AIコーディングエージェントを初めて触る人から幅広く想定されていました。すでに研究業務でClaude Codeを活用している人も含まれていたそうです。参加した10社超の中には、社内でAI活用に慎重な文化を抱える企業も含まれていたでしょう。

僕がまず驚いたのは、参加者から寄せられた声でした。「ワークショップに参加して世界が変わった」という声が届いていたのです。「わずか半日で欲しい研究アプリが作れたことに感動した」という声もありました。「自社で利用していく際のイメージが掴めた」という声もあったのです。こうした感想が、公式ブログでまとめて紹介されていました。半日という短い時間で、研究者自身がアプリを作れてしまう体験だったのです。専門のエンジニアに依頼して何週間も待つという従来の感覚とは、まったく違う世界だと感じました。

ここで気になるのが、なぜ半日で作れるのかという点でしょう。従来の業務アプリ開発では、要件定義を研究者からエンジニアに伝える必要がありました。そのうえでエンジニアが設計・実装し、確認してもらうという往復が発生していたのです。この往復こそが、時間のかかる最大の原因だったのでしょう。Claude Codeのようなコーディングエージェントであれば、研究者自身が自分の言葉で要望を伝えるだけで済みます。その場でアプリの形になっていくのでしょう。往復そのものを削れることが、半日という速さの正体だったと、僕は理解しました。

製薬業界は、承認プロセスや品質管理の基準（GxP）が厳格な業界の代表格です。新しいツールを1つ導入するだけでも、社内稟議やセキュリティ審査に時間がかかりがちでしょう。だからこそ、「AI活用は後回しになりやすい業界」というイメージが僕の中にもありました。金融や保険といった、他の規制業界でも似た構図があるかもしれません。

僕はAIコンサルタントとして、中小企業の稟議に何度も立ち会ってきました。新しいツールの導入稟議には、たいてい3つの壁があります。1つ目は、情報セキュリティ部門によるベンダー審査でしょう。取引先の実績やデータの取り扱い体制を細かく確認する工程で、ここだけで数週間かかることも珍しくありません。2つ目は、法務によるデータ処理契約の確認です。個人情報や機密情報をどこまで外部のサービスに渡せるかを、契約書のレベルで詰めていく作業でしょう。3つ目は、データガバナンス委員会のような社内組織が行う、最終的なリスク評価です。この3段階を毎回ゼロからやり直すとなると、稟議だけで数ヶ月かかってしまうのも無理はありません。

ところが実際には、ワークショップという「まず触ってみる場」を用意することで、参加のハードルを下げていました。いきなり全社導入を決めるのではなく、半日の体験を起点に検討を始めるのです。この設計自体が、規制業界でAI活用を進めるための1つの答えだったと、僕は感じました。

この構造は、他の規制業界にもそのまま当てはまるかもしれません。金融や保険、医療機器といった業界でも、承認プロセスの重さを理由にAI活用を後回しにしている企業は少なくないでしょう。ですが今回の製薬企業の事例を見る限り、業界の重さと導入の遅さは、必ずしも一致しないのかもしれません。

第一三共の研究者92%が語った、コーディングエージェントを手放せない理由

第一三共は、このワークショップで「創薬DRY解析はコーディングエージェントでどう変わったか」という発表をしています。DRY研究とは、実験を伴わないデータ解析中心の研究領域を指す社内用語とのことでした。実際に試薬を使う「ウェット研究」と対になる呼び方として、社内で定着しているのでしょう。発表の中身は、僕にとってかなり具体的なものでした。

DRY研究者へのアンケートでは、92%が「コーディングエージェントがなくなったら業務に影響する」と回答しています。さらに85%は「時間やスキルの制約でできなかった作業が、できるようになった」と答えていました。数字だけを見ると、抽象的な満足度調査に見えるかもしれません。ですが発表には、もう1つ具体的な事例も添えられていました。

大量の化合物データセットに対するSAR分析、つまり構造活性相関の分析があります。従来は4ヶ月ほどかかっていた作業が、今回は約1時間で完了したと報告されました。4ヶ月と1時間、この差はあまりにも大きいと感じます。もちろんすべての作業がここまで短縮されるわけではないでしょう。それでもこの1例だけで、研究者がコーディングエージェントを手放したくない理由が伝わってきます。研究者にとって、待ち時間の短縮は単なる効率化ではなく、試したい仮説の数そのものを増やす変化なのではないでしょうか。

ここで注意しておきたいのが、92%や85%という数字の読み方でしょう。これは「導入すれば誰でも同じ効果が出る」という保証ではありません。あくまで、ワークショップに参加し実際に触った研究者の実感を集めた数字でした。それでも、コーディングエージェントに懐疑的だった人まで含めて考えてみましょう。9割前後が肯定的な回答を寄せたという事実は軽視できません。導入前に懐疑的だった層の意見が変わったこと自体、現場に本当に根づいた証拠だったのだと思いました。

僕自身も、Claude CodeをMCPサーバー（外部ツールをつなぐ仕組み）と組み合わせ、日々の業務に使っています。データの整理や資料の下書きが、以前より圧倒的に速くなった実感がありました。研究者にとってのSAR分析は、僕にとっての資料作成やリサーチにあたるのでしょう。分野はまったく違っても、「時間のかかる作業をAIに任せ、人間は判断に集中する」という構図は同じだと気づきました。僕の場合も、リサーチ資料を集める時間そのものが少なくなったのです。その分だけ、集めた情報をどう解釈するかという判断に時間を割けるようになりました。

JCRファーマがわずか10日でBedrock環境を稼働させた設計の中身

JCRファーマの事例については、AWS公式ブログへの寄稿記事に詳細が紹介されています。同社はClaude CodeをAmazon Bedrock経由で導入しました。この選び方には、明確な理由が3つあったのでしょう。

1つ目は、既存のAWS基盤をそのまま使えることでした。Anthropicと別途契約を結ぶ必要がなく、社内の調達プロセスを新たに作り直す手間が省けます。2つ目は、研究データを国内にとどめられる点でした。推論プロファイルを東京・大阪リージョンに限定する構成にしたと説明されています。3つ目は、入力データがモデルの学習に使われないというセキュリティ要件を満たせることでした。製薬企業にとって、この3つ目はとりわけ重要な条件だったのでしょう。

JCRファーマの10日という速さは、この3段階の壁を最初から迂回できたことが大きかったのだと思います。既存のAWS基盤を使うということは、情報セキュリティ部門によるベンダー審査を、新たにやり直す必要がなかったのでしょう。推論プロファイルを国内リージョンに限定した点も見逃せません。法務が確認すべきデータ処理契約の範囲を、既存の契約の枠内に収められたということです。入力データがモデルの学習に使われないという要件も、データガバナンス委員会が過去に一度検証済みの条件だったのでしょう。ゼロから3つの壁を越え直すのではなく、すでに越えていた壁の上にClaude Codeを乗せる。この順番の違いこそ、10日と数ヶ月を分けた最大の理由だったのだと、僕は見ています。

JCRファーマは、ワークショップからおよそ10日で研究部門向けの利用環境を整えました。そして、Claude Code on AWSの展開を始めたのです。セキュリティソフトとClaude Code CLIをあらかじめ組み込んだAMIを用意していました。いわば仮想マシンの雛形です。研究者は環境構築で迷うことなく、すぐに使い始められる状態が整っていました。その後、およそ2ヶ月をかけて、研究部門以外にも利用の範囲を広げていったといいます。非研究部門への展開では、経理や薬事といった間接部門の定型業務も対象に含まれていたのでしょう。研究部門で得た手応えを土台に、社内展開のスピードそのものを落とさなかった点が印象的でした。

ここで僕が注目したいのは、「10日」という速さの中身でしょう。ゼロから新しいシステムを作ったわけではありません。既存のクラウド基盤、既存の調達プロセス、既存のセキュリティ要件が、すでに社内にそろっていました。これらを組み替えることなく、その上にClaude Codeを乗せていたのです。規制業界だからこそ、土台を作り直さずに済む設計を選んでいました。この判断自体が、速さの理由だったのだと僕は見ています。

もう1つ見逃せないのが、リージョンを国内に限定した点でしょう。海外リージョンを使えば、コストや性能で有利になる場面もあるはずです。それでも、データを国内にとどめるという制約をあえて選び、その範囲でスピードを最大化する設計にしていました。制約を取り払うのではなく、制約の中でどう速く動くかを考える。この発想の転換こそ、規制業界でAI活用を進める鍵なのだと、僕は思いました。

コストの面でも、この設計は理にかなっていたと思います。新しい契約や新しいベンダーを増やさずに済むため、追加コストは利用量に応じた従量分だけで済んだのでしょう。稟議を通す担当者にとっても、「既存契約の範囲内」という説明はいちばん通しやすい言葉だったのではないでしょうか。

東京のスモールビジネスと製薬企業、AI導入の設計思想は同じだった

僕はふだん、AIコンサルタントとして中小企業やソロプレナーの支援をしています。AI導入がPoC止まりになる理由でも書きました。多くの企業は「試す」ところまでは進んでも、「使い続ける」ところで止まりがちです。今回の製薬企業の事例と、僕がふだん向き合っている中小企業の現場は、規模も業界もまったく違うでしょう。ですが根っこの部分には、共通する設計思想があると気づきました。

中小企業にも、先ほど触れた3段階の壁と似た構図があると、僕は感じています。情報セキュリティのチェックリスト、業務委託契約の見直し、そして経営者自身によるリスク判断でしょう。規模が小さい分、この3段階を1人か2人でまとめて担うことも珍しくありません。だからこそ、誰がどの順番で確認するかを決めておくだけで、稟議のスピードは大きく変わります。

1つ目は、既存の基盤を活かすという発想でしょう。JCRファーマはAWSという既存基盤の上に、Claude Codeを乗せていました。中小企業であれば、すでに契約しているクラウドサービスや業務システムの上に着目してみましょう。AIエージェントを組み込めないか、考えてみる価値があるはずです。ゼロから専用システムを構築するより、はるかに速く動けるでしょう。会計ソフトやチャットツールにAI機能を追加する形なら、社内の説明もしやすいはずです。

2つ目は、扱うデータの範囲を先に決めておくことでしょう。JCRファーマは推論プロファイルを国内リージョンに限定していました。中小企業でも、どの情報をAIに渡してよいか、渡してはいけないかを最初に線引きしておくと、後から慌てずに済むはずです。正直に言うと、僕自身も最初はこの線引きが曖昧で、顧客情報をどこまでAIに渡していいのか迷った時期がありました。それでも、案件ごとにAIへ渡す情報の範囲を最初に決めるようにしてから、判断に迷う場面がかなり減っています。

3つ目は、いきなり全社導入を狙わないことでしょう。今回のワークショップも、半日という短い体験から始まっていました。JCRファーマの展開も、研究部門という限られた範囲から始まり、2ヶ月かけて広げています。小さく始めて、手応えを確かめながら範囲を広げていく。この順番を守るだけで、失敗したときの被害も小さく抑えられるはずです。

実際に、この3ステップを僕自身の仕事に当てはめて振り返ってみました。最初にMCPサーバーを導入したときは、既存のGoogleカレンダーやNotionと連携させる設定から始めています。ゼロから専用のワークフローを組むのではなく、すでに使っていたツールの上にAIを乗せる形にしました。データの範囲についても、最初は顧客の個人情報を含む資料までAIに読み込ませていいのか迷ったのが正直なところです。今では案件開始時に「渡してよい情報」と「渡さない情報」をリスト化し、クライアントにも共有するようにしました。この小さなルールを決めてから、AIへの指示に迷う時間が目に見えて減っています。規模はまったく違っても、製薬企業が踏んだ手順と、僕が踏んだ手順は驚くほど似ていました。

もちろん、製薬企業と中小企業では、コンプライアンス要件の厳しさがまったく違うでしょう。権限設計の考え方はガバナンス記事で扱いました。規模の大小にかかわらず、「既存基盤の活用」「データ範囲の線引き」「小さく始める」という3つの原則は共通しているはずです。そのまま応用できると、僕は考えました。

「うちの業界は特殊だから」を崩すために、今日からできる3つの視点

ここまで読んで、「製薬企業だからできたことだ」と感じた方もいるでしょう。ですが今回の事例から読み取れるのは、業界の特殊性を言い訳にしない設計の工夫でした。最後に、自社に当てはめて考えるための3つの視点を整理します。

1つ目は、「うちの業界は特殊だから遅くて当然」という前提を、一度疑ってみることでしょう。製薬業界はGxPという、他業界にはない厳格な基準を抱えています。それでも10日で本番利用を始めた企業がありました。自社の「特殊さ」が、本当に導入速度を遅らせる理由になっているのか、具体的に書き出してみる価値があるはずです。

2つ目は、いきなり導入を決めるのではなく、体験の場を先に作ることでしょう。今回のワークショップは、参加者の満足度を大きく高めていました。社内で似た場を作れないか、まず検討してみてください。全社導入の稟議を通すより、小さな体験会を1回開くほうが、はるかにハードルは低いのです。参加者は「わずか半日」という短さで、実際に手を動かしていました。

3つ目は、既存の契約・基盤・セキュリティ要件を棚卸しすることでしょう。JCRファーマの10日という速さは、ゼロから作らなかったからこそ実現していました。自社がすでに持っている契約やインフラの中に、AIエージェントを乗せられる土台がないか、一度確認してみてください。思っている以上に、使える土台が眠っているかもしれません。

この3つの視点に、特別な予算や高度なスキルは必要ないでしょう。むしろ今すでに社内にあるものを見直すだけで、実行できるはずです。規制の重さを言い訳にする前に、まずは自社が持っている土台を棚卸しすることから始めてみてください。

まとめ

「規制が厳しい業界ほど、AI導入は遅れるものだ」という思い込みは、今回の事例を調べる中で崩れていきました。改めて整理すると、次の3点が今回の記事のポイントです。

• Claude Code on AWSワークショップ（8月4日開催）に10社超が参加し、満足度4.70/5.00だった
• 第一三共では研究者の92%が「業務に影響する」と回答し、SAR分析は4ヶ月から約1時間に短縮された
• JCRファーマは既存のAWS基盤を活かす設計を選び、ワークショップからわずか10日で研究部門への展開を始めた

僕自身、この記事を書きながら、規制業界に対する自分の思い込みを恥ずかしく感じました。速さの理由は、特別な魔法ではなかったのです。既存の基盤を活かし、データの範囲を先に決め、小さく始める。この3つを守れば、業界の規模や厳しさに関わらず、同じような速さは再現できるでしょう。まずは自社の「特殊さ」を、具体的に書き出すところから始めてみてください。

次に僕自身がやってみたいのは、実際にBedrock経由でClaude Codeを使っている企業に話を聞きに行くことです。数字の裏側にある、現場のリアルな試行錯誤を、この目で確かめたいと感じました。この記事は、その取材に向けた一歩目のつもりです。