実験ロボットから医療画像、自治体窓口まで。AWS×AIによる業務支援の広がり | AWS Summit Japan 2026レポート
こんにちは。今回私は、AWS Summit Japan 2026に参加し、Health Care & Life Science領域から 「AI Scientist - フィジカル AI が実現する眠らないラボ」 と 「AI エージェントが実現する次世代医療ワークフロー」、Public Sector領域から 「体験！生成AIを活用した自治体DX」 の展示を見学しました。
テーマだけを見ると、実験ロボット、医療画像、自治体窓口と、かなり方向性の異なる展示に見えます。しかし実際に見学してみると、どの展示にも共通していたのは、専門性が高く、手間のかかる現場業務を、AIやAWSのマネージドサービスでどう支援するかという視点でした。今回は、新人・初心者の目線から、それぞれの業界背景や課題にも触れながら、展示で学んだことを整理していきます。
AIが実験し、最適解を導く「眠らないラボ」
最初に見学したのは、「AI Scientist - フィジカル AI が実現する眠らないラボ」 です。研究開発やライフサイエンスの実験現場では、仮説を立て、実験し、測定し、結果を分析し、さらに次の実験条件を考えるというサイクルが繰り返されます。
この試行錯誤は研究に欠かせない一方で、実験条件の検討、装置操作、測定結果の確認、データ分析など、多くの時間と手間がかかる作業でもあります。特に、実験装置、測定機器、解析ツールがそれぞれ分かれている場合、データ連携や自動化は簡単ではありません。
展示では、AIが自律的に仮説を立て、ライフサイエンス向けのオートメーションワークステーション実機に実験を指示し、測定結果を解析して次の実験計画を決めるという、Self-Driving Labの世界が紹介されていました。
＜Self-Driving Lab で行われていたこと＞
- Amazon Bedrock上のClaudeが次に試す配合を検討
- Tecan Fluentが実際に分注
- 測定結果をもとにAIが次の実験を計画
印象的だったのは、生成AIが単に文章を作るだけではなく、仮説生成、実験計画、実機への指示、測定結果の分析、次の計画立案まで関わっていた点です。クラウド上のAIが現実世界の実験装置とつながり、試行錯誤のループを回していることを実感しました。
一方で、実機を動かす以上、装置が想定外の状態になった場合のリカバリ、安全性、実験条件の制約、実行回数や推論回数に応じたコストなどは、実運用で必ず考える必要があります。AIに任せる範囲が広がるほど、人間が事前にルールや制約を設計することも重要になると感じました。
医療画像からレポートドラフト生成までを支える次世代医療ワークフロー
次に見学したのは、「AI エージェントが実現する次世代医療ワークフロー」 です。医療現場、とくに放射線科では、CTやMRIなどの読影対象となる画像データ量や業務負荷が大きくなっています。厚生労働省によると、撮影技術の進歩や高齢化により医療需要の増加を背景に、2023年度のCT撮影は約3,448万回、MRI撮影は約1,679万回で、いずれも前年度から増加しています（参照：NDBオープンデータ 2022年度・2023年度の値より引用 (厚生労働省))。
1つの検査でも数百枚の画像を確認することがあり、医師は画像を見るだけでなく、過去検査との比較、患者情報の確認、臨床ガイドラインとの照合、診断レポートの作成まで行う必要があります。
医療ITには技術的な難しさもあります。医用画像ではDICOM、診療情報ではFHIRといった標準規格が使用されます。PACS、RIS、レポートシステムなどが分かれていると、過去画像や過去レポートの確認にも手間がかかります。
展示では、医用画像が到着したことを起点に、AIが画像解析、患者の関連情報収集、過去の画像検査との比較、臨床ガイドラインとの照合、診断レポートドラフトの生成までを支援する流れが紹介されていました。
サービス・要素 | 役割 |
|---|---|
AWS HealthImaging | 医用画像を扱うための基盤 |
AWS HealthLake | FHIRに準拠した医療データを扱う基盤 |
Amazon Bedrock・医療AIモデル | 画像解析、過去レポート参照、レポート作成支援 |
実際のデモ画面では、DICOM画像ビューワー、AIチャット、過去レポートのサマリ、レポート作成パネルが組み合わされていました。医師は画像を確認しながら、AIに追加の質問をしたり、所見を深掘りしたり、レポートドラフトを編集したりできます。
ここで重要だと感じたのは、AIが医師を置き換えるという話ではなく、情報収集や整理、下書き作成を支援することで、医師が確認や最終判断に集中できるようにするという考え方でした。
医療分野では、AIの出力をそのまま信じるのではなく、どの画像のどの部分を根拠にしているのかや信頼度、ガイドラインとの対応を確認できることが重要です。セキュリティ、監査、権限管理、標準規格への対応、既存システムとの連携、コストなども慎重に考える必要があります。
自治体DXを支えるコールセンターとAI窓口対応
最後に見学したのは、「体験！生成AIを活用した自治体DX」 です。自治体の窓口業務では、住民からの問い合わせ対応や申請手続きが日常的に発生します。
利用者側からすると、申請書やマニュアルを読んでも「自分はどの手続きをすればよいのか」「何を提出すればよいのか」が分かりにくいことがあります。一方で職員側も、同じような問い合わせに何度も対応したり、複雑な制度や条件を確認したりする必要があります。
展示では、コールセンター業務の改善とAI窓口対応ソリューションが紹介されていました。Amazon Connectはクラウド型のコンタクトセンターサービスで、電話やチャットなど複数の問い合わせチャネルを扱うことができます。
出典： 窓口応答AIエージェント 資料
＜AI窓口対応ソリューションでできること＞
- 専用受話器を使ってAmazon Connectを簡単に利用できる構成
- 部署や島に1台の電話を置くような現場運用への対応
- AI窓口によるヒアリングと必要手続きの案内
- 申請書やマニュアルをもとにしたナレッジ活用
AI窓口対応ソリューションでは、親しみやすいアバター付きのユーザーインターフェースを通じて、AIが住民からヒアリングを行い、必要な手続きを案内する流れが紹介されていました。
ただし、自治体業務でAIを使う場合にも注意点があります。マニュアルや申請書が古いままだと、AIの回答も誤ったものになる可能性があります。また、個人情報を扱うため、認証、認可、ログ管理、データ保護への適切な対処が非常に重要です。判断が難しいケースや例外対応では、人間の職員へスムーズに引き継ぐ設計も必要だと思いました。
分野を越えて共通していた「現場業務の支援」
今回見学した3つの展示は、対象分野が大きく異なります。1つ目は、AIと実験ロボットを組み合わせたSelf-Driving Lab。2つ目は、医療画像解析からレポートドラフト生成までを支える医療ワークフロー。3つ目は、自治体DXをテーマにしたコールセンターとAI窓口対応です。
最初はまったく別々の展示に見えましたが、振り返ってみると、どれも共通していたのは、専門性が高く手間のかかる現場業務を支援し、人が本来集中すべき判断や対応に時間を使えるようにするための仕組みだったという点です。
分野 | 支援対象 | 人が集中できること |
|---|---|---|
研究開発 | AIと実験ロボットによる試行錯誤 | 仮説検証や結果の解釈 |
医療 | 画像解析、情報収集、経時比較、レポートドラフト生成 | 確認や最終判断 |
自治体窓口 | 問い合わせ対応や申請手続き | 住民対応と例外判断 |
「眠らないラボ」では、AIが仮説を立て、実験し、結果を分析し、次の実験計画を考えるSelf-Driving Labの可能性を学びました。次世代医療ワークフローでは、AIによる画像解析やレポート作成支援だけでなく、DICOMやFHIRといった標準規格に対応したデータ基盤の重要性を知りました。自治体DXでは、AI、ナレッジ、電話・チャット基盤を組み合わせることで、住民と職員の双方を支援できることを学びました。
また、どの展示でもAIだけですべてが完結しているわけではありませんでした。生成AIに加えて、データを管理するサービス、実機や既存システムとつなぐ仕組み、利用者が操作する画面、ログや履歴の管理など、複数の要素が組み合わさっていました。この点から、AWSサービスは単体で覚えるだけではなく、業務課題に合わせてどう組み合わせるかが重要なのだと感じました。
一方で、AIやクラウドを使えばすぐにすべてが解決するわけではありません。コスト、セキュリティ、既存システムとの連携、人間による確認、運用ルールの整備など、実際に使うためには多くの考慮点があります。
今回の参加を通して、私はAWSサービスを単なる個別機能としてではなく、業界課題や業務課題と結びつけて理解することの大切さを感じました。今後は、Amazon Bedrock、AWS HealthImaging、AWS HealthLake、Amazon Connectなどについて、サービス名だけでなく、どのような課題を解決するために使われるのかという視点で学んでいきたいです。
