【象印マホービン×塩野義製薬×AWS】生成AI開発の現在地とこれから―開発生産性を高める、現場での生成AI実践知
生成AIは開発や業務改善を加速させる一方、現場では「ツール導入＝定着・成果」にならない難しさも浮き彫りになっている。 本イベント「生成AI開発の現在地とこれから―開発生産性を高める、現場での生成AI実践知 #Women@AWS Building with Impact」では、少人数体制での導入・運用、規制領域での品質担保、AI駆動開発の実践まで、3名の登壇者が具体事例とともに共有した。本記事では、各講演の要点を実務の観点からまとめる。
生成AIは開発や業務改善を加速させる一方、現場では「ツール導入＝定着・成果」にならない難しさも浮き彫りになっている。
本イベント「生成AI開発の現在地とこれから―開発生産性を高める、現場での生成AI実践知 #Women@AWS Building with Impact」では、少人数体制での導入・運用、規制領域での品質担保、AI駆動開発の実践まで、3名の登壇者が具体事例とともに共有した。本記事では、各講演の要点を実務の観点からまとめる。
アーカイブ動画
システム現場発 生成AI実践ロードマップ〜少人数で実現するAWS内製開発〜
演者プロフィール
象印マホービン株式会社
経営企画部 システムグループ
サブマネージャー
浦﨑 香菜子（うらさき・かなこ）氏
「よしなにやってくれる」はずが... システム現場で直面した生成AIの壁
最初に登壇したのは、象印マホービン株式会社（以下「象印マホービン」）経営企画部 システムグループの浦﨑氏。金融系企業2社でのキャリアを経て、2023年に同社へ転職した。現在は基盤チームで、AWSをはじめOSやミドルウェアなどの構築・運用保守を担う。講演では、AIを専門にしてきた立場ではないからこそ、「現場でどう使えるか」という目線で生成AIとの向き合い方を語った。
炊飯ジャーや生活家電で知られる象印マホービン。同社のシステムグループは社員と協力会社を合わせて21名という体制で、全社のシステム業務を担っている。
数年前、浦﨑氏は生成AIに期待を抱いていた。
「要件をわたせば、開発からテストまで“よしなに”やってくれるのではないか」（浦﨑氏）
しかし現実は異なった。チャット型生成AIでは、プロジェクトの背景を都度説明し、回答をコピーし、動作確認してエラーが出ればまた質問するという作業が生まれた。
残るサーバーは片手で数えるほど：属人化と「AIのウソ」が生んだ新たな危機
同社ではここ数年でオンプレミス環境からAWS（クラウド環境）への移行を進め、残るオンプレサーバーは片手で数えるほどになっていた。しかしAWSの活用が進む一方で、有識者の退職により属人化が深刻化していた。
2025年度のはじめ、基盤チームは開発チームに助けを求めた。開発チームの協力により、AWSのIAM（アクセス管理サービス）利用者数は1.5倍に、Lambda（サーバーレス実行環境）の本数は半年で約2倍に拡大した。既存コードのリファクタリングや他サービスとの連携も進んだ。
しかし新たな課題が生まれた。開発チームはアプリケーション開発の知見はあるものの、AWSに関する専門知識は十分ではない。社内の汎用AIを活用して開発を進めていたが、AWSのアップデートに追いつけず、ハルシネーション（AIの誤った回答）を信じてしまうケースが発生。さまざまな質問が基盤チームに寄せられるようになった。
30分の衝撃：Amazon Q Developer導入へ、予算・セキュリティの壁を破る「三点突破」戦略
転機となったのは、AWS社が開催する生成AIワークショップへの参加だった。浦﨑氏はAmazon Q Developer（AWSのAIコーディングエージェント）を使ったアプリケーション開発を体験し、約30分でIAMロール申請用のアプリケーションを完成させた。
この体験をきっかけに、「社内でも使えるのではないか」という手応えを得た一方で、事業会社として導入を進めるには越えるべきハードルもあったという。そこで浦﨑氏は、導入検証に向けてコストとセキュリティ・現状の課題整理・検証の設定の3点を軸に社内調整を進めた。
コスト面では、AWSサミットで得た知見をもとにストレージ構成を見直し、コスト削減を実施。そこで捻出した予算を、Amazon Q Developer導入の原資として提案した。またセキュリティ面については、学習データが自動的にオプトアウトされる仕組みがある点を説明し、リスク懸念を抑えた形で話を進めたという。
あわせて、現状の課題も明確にした。従来の汎用的なチャット型AIでは、プロジェクト背景を都度説明し、生成結果をコピー＆ペーストして試すといった手間が発生しやすく、AWSのアップデートに追随できずハルシネーションを前提に使わざるを得ない場面があることを説明した。
検証の設定として導入は一気に広げるのではなく、まずは少人数でのスモールスタートを選択。全社展開して失敗した際の影響を避けるため、AIに対して特別積極的でも消極的でもない「ニュートラル」なメンバーを対象に、約2カ月間の検証を行ったうえで、導入可否を検討したいと説明したという。
ツール導入後の“放置”が生んだ利用率4倍増への教訓
このようなプロセスを経て、いよいよAIコーディングエージェントの導入検証を開始。期間中、メンバーへのアンケートでは全員が生産性向上を実感したという結果が得られた。特にIDE上で直接ファイルを更新できる点や、AWSの公式ドキュメントに基づいた信頼性の高い回答が得られる点が高く評価されたという。その結果、2025年12月よりさらにメンバーを拡大してAmazon Q Developerの導入決定に至った。
一方で、導入を振り返っての反省点も語られた。検証開始当初は「ツールをわたせば自然に使われるだろう」と考え、使い方のレクチャーを行わずに進めていたという。しかしその期間は想定ほど活用が進まず、後からハンズオン形式のレクチャー会を実施したところ、利用頻度が約4倍に増加した。簡単なアプリやゲームを題材に、AIエージェントを使って実際に手を動かす体験を共有したことで、初めて具体的な活用イメージが浸透したという。
「AIを手段に」価値創出へ集中するエンジニア像
講演の終盤、浦﨑氏はAmazon Q Developerを含むAIコーディングエージェントを、便利ツールに終わらせないために現在実施していること、今後取り組みたいことを紹介した。
これまで同社では、Excelに画面キャプチャを貼り付けた作業手順書やパラメータシートが主流だったが、こうした形式は人間には分かりやすい一方で、AIにとっては文脈を捉えにくい。そこで、前提や意図が伝わる構造を意識したドキュメントへと見直しを進めている。また、新規に作成するAWSリソースについては、コンソール操作に頼らずIaC（Infrastructure as Code）で管理する方針とし、人とAIが同じ情報を参照できる状態を作ることで、属人化を抑え、再現性の高い運用につなげていく考えだ。加えて、プロンプトの書き方が個人に依存しないよう、チーム全体で共通のコンテキストを整理することや、データやログを集約してAIが参照できる基盤を整えることも検討している。
こうした取り組みの根底にあるのは、「AIコーディングエージェントを使うこと自体がゴールではない」という考え方だ。生成AIはあくまで手段であり、最終的に問われるのは、それをどう事業貢献や顧客への価値創出につなげるか。目的や前提を整理し、設計し、判断する役割は人間にあり、AIと協働することで生まれた余白を、より本質的な価値づくりにどう使うのか。その問いを持ち続けることこそが、浦﨑氏が考える生成AI時代のエンジニア像だ。
最後に浦﨑氏は、「AI時代のエンジニアに求められる本質は変わらない」と語った。
重要なのは、インプットをもとに試し、アウトプットし、振り返るというサイクルを、これまで以上に速く回すこと。AIコーディングエージェントの活用自体がゴールではなく、それを通じて事業や顧客への価値創出につなげることこそが、最終的な目的だと強調した。
生成AIを活用したSHIONOGIでの価値創出と実践知
演者プロフィール
塩野義製薬株式会社
DX推進本部 データサイエンス部
Generative AIグループ
山下 彩花（やました・あやか）氏
製薬DXの鍵：AI活用を駆動する「対話・プラットフォーム化・技術獲得」の三本柱
続いて登壇したのは、塩野義製薬株式会社 DX推進本部 データサイエンス部の山下氏。薬学部出身で、入社当初は臨床試験のデータマネジメントに携わってきた人物だ。2020年のデータサイエンス部門立ち上げを機に異動し、データサイエンス／データエンジニアリングを経て、2024年10月に新設されたGenerative AIグループへ。現在は生成AIを用いた社内ソリューション開発の推進と、データを生成AI活用に適した形に整える「Data for AI」の基盤整備を担っている。
山下氏が所属するデータサイエンス部は、社内外のデータを集積する基盤を構築し、データ活用技術を通じてヘルスケアソリューションの創出と業務プロセスの変革に貢献することをミッションとしている。なかでもGenerative AIグループでは、社内のさまざまなバリューチェーンデータを扱いながら、効率的かつガバナンスの効いた生成AI活用を広げるためのアプリケーション開発を進めている。
取り組みの軸は大きく3つ。各部門や経営層へのヒアリングを通じてニーズを拾い上げる「対話によるビジネスチャンス創出」、複数アプリでアーキテクチャを共有しながら統制の効かせ方を検討する「プラットフォーム化」、そしてプロトタイピングや研修を通じて知見と人材を積み上げる「技術獲得」である。これらを通じて、AIアプリ開発のPDCAサイクルを高速に回すことを重視しているという。
規制文書作成の壁に挑む：メディカルライティング支援の全貌
ここから話は、医薬開発領域における生成AIプロジェクトの具体事例の紹介へ。
医薬品が世に出るまでには、研究から申請承認まで10年以上を要する。臨床試験だけでも3年から7年かかるとされ、この期間の短縮は社会的にも大きなインパクトを持つ。
製薬企業における生成AI活用の可能性は幅広い。経営の意思決定支援から文書検索、規制文書の作成まで、さまざまなテーマが存在する。ただし、法令や規制への準拠、データのセキュリティとプライバシーの確保が常に求められる点が、この業界特有の難しさだ。
山下氏が着目したのは、臨床試験で必ず作成する規制文書だった。治験実施計画書（プロトコール）は試験の設計図となる文書であり、治験総括報告書（CSR）は試験終了後の包括的な報告書だ。これらの作成には一文書あたり数十から数百時間を要し、特にCSRでは文書間の転記のような機械的な作業も多く含まれていた。
この課題を解決すべく「メディカルライティング支援アプリケーション開発プロジェクト」を発足。スコープは初稿の作成支援までとし、人によるレビューは残す方針を採った。
CSRの場合、「ICH-E3 治験報告書」というガイドラインに章構成が定められており、そのガイドラインに準拠した社内テンプレートが用意されている。山下氏のチームは、引用元となる各種文書（プロトコールや解析帳票など）を準備したうえで、社内テンプレートへのマッピング定義を作成。生成AIによって新規作成やサマライズを行う仕組みを構築し、CSR1〜13全章のドラフトがおよそ10分程度で生成できるようになった。
アプリケーションの画面では、参照文書をアップロードしたうえで、各章構成ごとにタブが設けられている。それぞれの章にはプリセットされたプロンプトがあり、ユーザーであるメディカルライターが実行ボタンを押すと文書が生成される。生成された文書は即座にプレビューでき、必要に応じて編集も可能だ。現在は、メディカルライターによる修正を含めて文書作成業務がどの程度効率化できるかにチャレンジしている。
なぜAIアプリ開発が1年で実現できたのか？ 「内製環境」と「業務部門との高速アジャイル」
ここから山下氏は、本プロジェクトを通じて得られた、生成AIプロジェクト推進のポイントをまとめる。
Generative AIグループ発足から約1年で複数のAIアプリケーションを形にできた背景として、「試しやすい開発・検証環境」と「内製で素早く回す力」の2点を挙げた。もともと社内でAWSの活用基盤が整っており、セキュリティを意識した形で安全に実験できる環境があったことが、生成AI活用のスピードを押し上げたという。
加えて、Amazon Bedrockなど新しいサービスを積極的に取り込みながら、最新技術をまず使ってみて理解する姿勢を徹底している。そうすることでいち早く試作品を作り、学びを次の開発に反映するサイクルを回せている点が強みだと語った。
生成AIでアプリ開発を進めるうえで重要なポイントとして、業務部門との密なコミュニケーションも強調された。今回のメディカルライティング支援では、ユーザーとなる薬事・文書作成の業務部門と週2回程度のミーティング機会を設け、業務要件をすり合わせながらアジャイルに改善している。「このUIは使いづらい」「ここはこう直したい」といった現場の声を素早く拾い、対話を通じて仕様へ落とし込むことが、継続的に前進できる要因となっている。
開発を閉じたチーム内で完結させない点も、推進上の工夫として語られた。業務部門の声を聞きながら、必要に応じてパートナー企業やAWSのSA（ソリューションアーキテクト）にも相談し、技術選定や設計の不確実性を減らしている。規制や品質要件が厳しい領域だからこそ、社内外の知見を組み合わせながら、実装を前に進める体制づくりが重要だという考えだ。
エンジニアが担うべき「人の役割」とキャリアの磨き方
講演の最後に山下氏は、AI時代のエンジニアキャリアについて私見を述べた。
生成AIがコードを生成してくれる時代になり、コーディングの効率は大きく向上している。生成されたコードのレビューは依然として必要だが、「まず形にして試す」というサイクルを高速に回せるようになった点は、大きな変化だという。こうした変化を前向きに捉え、楽しむ姿勢が重要だと語った。
一方で、AIがすべてを代替するわけではない。今後より重要になるのは、「人にしかできないこと」にフォーカスすることだ。どこにビジネスチャンスがあるのか、各バリューチェーンのニーズや業務部門が抱える課題を言語化し、それをアプリケーションにどう反映するか。その橋渡しがエンジニアの腕の見せ所であり、業務部門とのコミュニケーションの重要性はこれまで以上に高まっていく。暗黙知になりがちな業務知識やプロセスを言葉にし、AIに渡せる形に整えていくことも欠かせない。
そして、もう一つが、学び続ける姿勢だ。AIを使いこなすための技術習得は不可欠であり、最新の情報をキャッチアップしたうえで、まずは自分で使ってみる。プロトタイプとして実際に形にすることで感覚をつかみ、習得した技術をどの業務・課題に適用できるかを常に考える。その積み重ねこそが、生成AI時代のキャリアを切り拓いていくと山下氏は締めくくった。
生成AI時代のエンジニアへ：AI駆動開発の実践と学び
演者プロフィール
アマゾン ウェブ サービス ジャパン合同会社
プロフェッショナルサービス部門
Cloud Infrastructure Architect
森川 恵海（もりかわ・えみ）氏
AI駆動開発を阻む三大課題
最後に登壇したのは、アマゾン ウェブ サービス ジャパン合同会社（以下「AWS社」）のデリバリーコンサルタント、森川氏。2021年にクラウドサポートエンジニアとしてAWS社に入社し、2024年にプロフェッショナルサービスへ異動して以降は、お客さまの課題解決に伴走する立場で現場に立っている。
生成AIの登場でソフトウェア開発は劇的に変化した。GitHub CopilotやAmazon Q Developerなど、コーディングを自動化するツールが急速に普及している。こうした流れで注目されているのがAI駆動開発だ。
これは、従来のように人間中心で開発を進めてAIを補助的に使うのではなく、AIによるタスク実行を前提に開発プロセスそのものを設計するという考え方である。AIにどのようなコンテキストをわたせばよいのか、どうすれば高品質な実装を引き出せるのかを起点にプロセスを組み立てる点が特徴だ。
しかし森川氏は、実際にAI駆動開発を進めるなかで3つの大きな課題に直面したという。1つ目はコンテキストがうまく伝わらない問題だ。プロジェクト全体の設計思想、過去の意思決定の背景、チーム固有のルールや暗黙知がAIには届かない。森川氏の経験では、生成AIが社内用語を誤解し、意図と異なるコードを生成してしまうことがあった。
2つ目は一貫性のある出力にならないことだ。生成AIは非決定論的なふるまいをするため、同じプロンプトでも毎回違う実装が生成される。人によってプロンプトの書き方も異なり、生成したコードで命名規則やエラーハンドリングが異なる事態が起こりうる。
3つ目は変更の影響範囲が追跡しにくいことだ。AIが何をどう変更したのか、後から確認することが困難になる。森川氏は実際に「テストに失敗しなくなった」と喜んでいたところ、テストコード自体が作り変えられていて、本来検証すべき内容がテストされていなかったという経験を語った。
AI駆動開発を成功させる鍵：「Everything as code」による3段階サイクル
これらの課題を解決するために森川氏が取り入れたのが「Everything as code」という考え方だ。これはAWS Well-Architectedフレームワークで定義されている手法で、ネットワーク、インフラ、ドキュメント、設定など開発ライフサイクルのさまざまな側面にバージョン管理、テスト、デプロイという同じ原則を適用する。
最も重要なのは「人間しか知らないことをなくす」ことだと森川氏は述べる。手動での設定変更、口頭での指示、暗黙的なルール、オフラインの会話。これらすべてをコードとして明示的に表現することで、AIはプロジェクトの全体像を理解し、適切なコードを生成しやすくなる。
「これがAI駆動開発成功の鍵となる」（森川氏）
ここで、森川氏は「Everything as code」をプロジェクトで実践した例を紹介。プロジェクトでは、1週間以上のスプリントを10回ほど回すアジャイル開発で進行した。すべてのAWSリソースはAWS CloudFormation（インフラをコードで定義するサービス）で管理し、ドキュメントもマークダウンで管理した。
プロジェクトは3つの段階で進められた。まずドキュメントの生成として、設計書やAPI仕様書、開発手順書をマークダウン形式で作成。次にコード生成では、Amazon Q Developerにドキュメントを参照するよう設定し、一貫性のある実装を可能にした。ただしこの際、生成されたコードは必ずレビューして進めた。そして3段階目がドキュメントの更新だ。コードを更新したら必ずドキュメントも更新する、ドキュメントが更新されればコードを更新するというように、2段階目と3段階目のサイクルを繰り返すようにした。
3割の工数削減と、人に求められる「丁寧な設計とレビュー」
続いて森川氏は本プロジェクトを通じて得られた成果を3つの観点から紹介した。
1つ目はドキュメント作成だ。設計書や手順書などのドキュメントは主に生成AIが作成し、コード側でAPIパラメーターの制限を定義すると、その内容をAIが読み取って自動的にドキュメントへ反映する仕組みを構築した。これにより人は内容の妥当性を確認するレビューに集中できるようになった。
2つ目はインフラ構築である。AWS CloudFormationのテンプレートについては、ベース部分を生成AIに作成させたうえで、設定項目のレビューや動作検証を人が担う形とした。これにより、ゼロから書く作業を省きつつ、品質を担保したインフラ構築が可能になった。
3つ目はアプリケーションコードの実装だ。既存の類似コードをAIに参照させることで、プロジェクトの文脈に合った実装を効率よく進めることができるようになった。
これらの結果、当初見込んでいた作業時間から体感で約3割の削減を実現。削減できた時間は、セキュリティの強化やログ出力の最適化、ドキュメントの拡充などより多くの機能実装に充てられたと森川氏は振り返る。
一方で苦労した点もある。生成AIは必要以上に複雑なコードを生成することがあり、人間によるコードレビューは必須だ。また、設計が曖昧だと想定外のコードが生成されるため、最初に人間が丁寧に設計する必要があることも実感したという。さらに、生成AIの非決定論的な挙動も課題として残され、人間が必要な場所がまだあることが浮き彫りになったという。
「価値ある仕事」に集中するための3つの指針
森川氏はAI時代のエンジニアに必要な姿勢として3つのポイントを挙げた。
1つ目は、人間ならではの価値を発揮すること。要件定義、ドメイン知識の理解、ビジネス価値の判断など、AIには難しい領域に注力する。2つ目はAIを敵視せず、協働するパートナーとして受け入れること。3つ目は常に学び続ける姿勢だ。
「効率化できた時間で何ができたのかが重要。ただAIを使って何割効率化できましたというだけではダメで、その時間で新たにどのような価値を生み出せるかが大切」（森川氏）
AIは実装を加速させるツールだが、思考を代替するものではない。人間がしっかり設計し、AIと協働できる環境を作ることが、より価値の高い開発につながる。
【Q&Aセッション】
Q&Aセッションでは、登壇者3名がイベント参加者から投げかけられた質問に回答した。
Q. 専門が異なる業務部門との週2回の打ち合わせは大変でしたか？
山下氏：専門領域が異なるため、最初は苦労した部分がありました。私自身は医薬品開発の領域出身だったので、文書作成の大まかなイメージは持っていましたが、メディカルライターさんが実際にどこを意識して文書を作成しているのか把握するまでには時間がかかりました。アプリケーションに落とし込む際にはUIへのこだわりや文書のフォーマットなど、細かい部分も意識する必要があり、週2回の打ち合わせの中で要件やUIの調整を進めていきました。
Q. 資格学習に生成AIをどのように活用しましたか？
浦﨑氏：分からなかった問題を深掘りするために活用しています。AWSの認定試験では四択問題が多いのですが、間違えたときは大抵二つで悩んで外したケースが多いです。その選択肢について「なぜこれが違うのか」をもっと深掘りして教えてほしいという形で壁打ちをしています。何回同じことを聞いても嫌がられないので、心理的にも助かっています。
Q. 検証期間中に全員が生産性向上を実感されたとのことですが、最初から全メンバーがポジティブな姿勢でしたか？
浦﨑氏：どちらかというとニュートラルなメンバーを対象に選びました。ただ、開発チームのリーダーがとてもポジティブに取り組んでくださり、メンバーに声かけをしてくださったことが、検証を進めるうえで大きかったと感じています。
Q. 他部門の業務の成果物を出力するフロントの検討で、どのようなことを念頭に置いて取り組みましたか？
山下氏：CSRなどはガイドラインに記載内容が決まっているため、ある程度出力させたい内容は明確です。ただ、社内の事情を含んだプロンプトを作成する際には、実際のユーザーであるメディカルライターさんにドラフトを評価してもらいながら進めました。章によっては生成が難しいパートもあり、対話を重ねながらどういったプロンプトなら意図した品質で文章が生成されるか試行錯誤しました。
Q. 象印マホービン株式会社では、会社全体でAI活用には積極的な雰囲気なのでしょうか？
浦﨑氏：全社的に導入している汎用AIについては、約9割の方が使っているというアンケート結果がありますので、わりと積極的な雰囲気だと感じています。
Q. 「Everything as code」は非エンジニアも使える発想でしょうか？
森川氏：使える発想だと思います。思考をドキュメントにアウトプットしておくことで、そのアウトプットを繰り返し使え、プロンプトに差が出にくくなります。チーム内でプロンプトを安定させたい時などにも応用できる考え方です。
Q. AI活用を進めるにあたって一番難しいと思ったことは何ですか？
浦﨑氏：プロンプトが個人に依存するので、出力が人によってまちまちになることです。また、AIの出力を過信してしまう方もいて、業務に生かしていく難しさを感じています。
山下氏：AIを使うリテラシーやプロンプトの書き方には知識の差があり、そのリテラシーの底上げが課題です。研修や教育施策を実施していますが、どう使いこなせるかという観点を持っているかどうかでAI活用の進み方が全然違ってきます。
森川氏：AI活用を始める際の最初の一歩が一番の障害だと思います。使い始めると便利さに気づけるのですが、その導入部分をどう乗り越えるかが山場だと感じています。
Q. ウォーターフォール開発からAI駆動開発への移行において、開発者のリスキリングに関する経験があれば教えてください。
森川氏：（質問者の）ウォーターフォール開発での役割分担（設計、コーディング、検証）から、AI駆動開発で「一人のデベロッパーが設計からテストまでをAI駆動で一気通貫に行うのがベストプラクティス」と考えている、というご意見はおっしゃる通りだと思います。ただ、一人のデベロッパーが一気通貫で行うのがベストかどうかは開発の仕方にもよると考えています。例えば仕様書を作成してからそれをベースにそれぞれで開発を進めるなど、AI活用しながら進める方法は何かしらあるのではないでしょうか。
Q.製薬分野におけるAI導入で、今後ブレイクスルーになる領域はどこでしょうか？
山下氏：AI創薬や研究・創薬の分野が盛んだと思います。弊社でもマシンラーニングやバイオインフォマティクス、ケモインフォマティクスなどに取り組んでいます。また、今日ご紹介した文書作成の効率化は、どの業務にもつながる領域なので、横展開や応用を広げていきたいと考えています。AIの使い方の型が決まれば応用が効くと思っています。
※バイオインフォマティクス：生物学（Biology）と情報学（Informatics）を融合させ、膨大な生物学的データ（DNA配列、タンパク質構造など）をコンピューターを使って解析し、生命の仕組みや法則を解明する学問分野・技術
※ケモインフォマティクス：化学（Chemistry）と情報学（Informatics）を組み合わせた分野で、コンピューターと情報技術を用いて、化学物質の構造・性質・活性などの膨大なデータを効率的に管理・解析・予測し、医薬品開発や新素材開発などを加速する技術
Q. AWSでは、社内で勉強会などが活発に行われているのでしょうか？
森川氏：はい、社内にコミュニティがあり、勉強会が開かれています。AWSはアップデートが非常に多いので、みんながキャッチアップできるよう、それぞれが工夫しながら協力して勉強会を開いています。
Q.塩野義製薬では生成AIの品質チェックをどのように行っていますか？
山下氏：かっちりした形式というよりは、人による評価をすることが多いです。モデルのバージョンアップが必要になった際に、生成結果がどれぐらい変わるか、変えたくない部分がバージョンアップ後も維持できているかなどの確認は、現在は目視で行っています。
文＝宮口 佑香（パーソルイノベーション）
※所属組織および取材内容は2025年11月時点の情報です。
アマゾン ウェブ サービス ジャパン合同会社
https://aws.amazon.com/jp/
アマゾン ウェブ サービス ジャパン合同会社の採用情報
https://aws.amazon.com/jp/careers/
おすすめイベント
関連するイベント
