Azure AI Foundryで医療テキスト分析を試したい管理者・開発者にとって、今回のポイントは明確です。Text Analytics for Health NextGen PlaygroundがAzure AI Languageの機能として一般提供され、Microsoft Foundryポータル上で診療メモ、退院サマリー、研究要旨などを貼り付けて、医療エンティティ抽出を検証しやすくなりました。
本番APIそのものの使い方が突然変わるというより、医療・ヘルスケア向けNLPの評価、PoC、開発者への引き継ぎをAzure AI Foundry上で進めやすくなる更新です。既存のLanguage Studio利用者は、今後のMicrosoft Foundry移行も含めて、権限、リージョン、コスト、個人情報を含む入力データの扱いを確認しておきましょう。MicrosoftのAzure更新情報では、本件は「Launched」かつ「General Availability」として掲載されています。(マイクロソフト アジュール)
Azure AI FoundryでText Analytics for Health NextGen Playgroundが一般提供
2026年6月4日に公開または更新された公式情報として、Azure AI LanguageのText Analytics for Health NextGen Playgroundが、Microsoft Foundryポータルで一般提供されました。対象はAzure AI FoundryでAzure AI Languageを扱う管理者、開発者、医療情報システム担当者、ヘルスケア向けISVです。
Text Analytics for Healthは、医師のメモ、臨床文書、電子カルテ、退院サマリーのような非構造化テキストから、医療情報を識別・ラベル付けするAzure Languageの事前構築済み機能です。Microsoft Learnでは、診断名、薬剤名、症状・徴候、年齢などの医療エンティティを抽出できる機能として説明されています。(Microsoft Learn)
今回の更新で重要なのは、医療テキスト分析の検証場所がMicrosoft Foundry側に寄ってきたことです。コードを書き始める前に、サンプルの退院サマリーや医師メモを貼り付け、どのような診断名・薬剤・症状・関係性が抽出されるかを画面上で確認できます。開発者だけでなく、臨床情報管理、医療データ分析、製品企画の担当者も、APIの出力イメージを共有しやすくなります。
何が変わったのか
今回の変更は、単に「新しい画面が追加された」という話ではありません。Azure AI Languageの医療向けテキスト分析を、Azure AI Foundryの開発・検証フローに組み込みやすくする更新です。
| 項目 | 変更内容 | 実務上の意味 |
|---|---|---|
| 提供状態 | Text Analytics for Health NextGen Playgroundが一般提供 | プレビュー前提ではなく、本格検証の導線として扱いやすくなる |
| 利用場所 | Microsoft Foundryポータル上のAzure Language関連機能 | Language Studio中心の運用からFoundry中心の運用へ移行しやすくなる |
| 主な対象データ | 退院サマリー、医師メモ、臨床文書、研究要旨など | 医療文書の構造化、検索、分類、コード化支援のPoCに使いやすい |
| 主な利用者 | 臨床情報チーム、医療系ISV、開発者、データ分析担当 | 業務担当者と開発者が同じ画面で出力を確認しやすい |
| 開発への影響 | Playgroundから挙動を確認し、API・SDK実装へ進める | 要件定義とプロトタイプ作成の手戻りを減らしやすい |
Microsoft Learnの更新情報でも、Text Analytics for Health Playgroundが新しいFoundryで利用可能になったこと、さらに一部の新しいLanguage Playgroundでは「Open in Visual Studio Code」により、現在の構成を事前設定済みコードサンプルとしてVS Codeへ出力できることが案内されています。(Microsoft Learn)
Text Analytics for Healthでできること
Text Analytics for Healthは、医療文書を単なるキーワード検索ではなく、医療概念として扱うための機能です。Microsoftのドキュメントでは、1回のAPI呼び出しで主に次の4つの処理を行うと説明されています。(Microsoft Learn)
| 機能 | 何をするか | 例 |
|---|---|---|
| Named Entity Recognition | 医療エンティティを識別する | 診断名、薬剤名、症状、年齢、身体部位など |
| Relation Extraction | エンティティ同士の関係を抽出する | 薬剤と用量、症状と時期、疾患と部位 |
| Entity Linking | 医療概念を標準語彙へ関連付ける | UMLSなどの医療語彙への対応付け |
| Assertion Detection | 文脈上の意味を補足する | 確実性、条件、関連性、時間性など |
たとえば、医師メモに「糖尿病の既往あり。メトホルミン500mgを朝夕内服」と記載されている場合、単に「糖尿病」「メトホルミン」という文字列を拾うだけでは不十分です。薬剤名、用量、服用タイミング、既往か現在の症状か、といった文脈まで見なければ、業務システムや分析基盤では使いにくいデータになります。
Text Analytics for Healthは、こうした非構造化の医療テキストから構造化された情報を取り出すための入口になります。
今回の更新で影響を受ける利用者
今回の一般提供で特に確認すべきなのは、次のような組織や担当者です。
| 対象者 | 影響 | 確認すべきこと |
|---|---|---|
| Azure AI Foundry管理者 | Foundry上でLanguage機能を使う利用者が増える可能性 | 権限、接続済みリソース、ネットワーク制御、監査ログ |
| Azure AI Language利用者 | Language StudioからFoundryへの利用導線が強まる | 既存リソースをFoundryで利用するか、新規Foundryリソースへ移すか |
| 医療系アプリ開発者 | Playgroundで出力を確認してからAPI実装へ進めやすい | REST API、SDK、サンプルコード、例外処理、出力形式 |
| 臨床情報・データ分析担当 | 退院サマリーや医師メモの構造化検証がしやすい | 実データ投入前の匿名化、評価観点、医療者レビュー |
| ISV・SaaS事業者 | 医療文書処理機能のPoCを短期間で作りやすい | 顧客データの取り扱い、リージョン、契約、運用責任分界 |
特に、医療データは機微性が高いため、Playgroundで「試しに実データを貼る」運用は避けるべきです。まずは匿名化したサンプル、公開データ、または社内で利用許可を得た検証用データを使い、精度と出力形式を確認する流れが安全です。
管理者が確認すべき設定
Azure AI FoundryでText Analytics for Healthを利用する前に、管理者は「使えるか」だけでなく、「誰が、どのデータを、どの環境で使えるか」を確認する必要があります。
Azureリソースと権限
まず確認したいのは、Azure AI LanguageまたはFoundryリソースの作成・接続・利用権限です。Microsoftの移行ガイドでは、Language StudioからFoundryへ移行する際の前提として、Azureサブスクリプションと、リソース作成が可能なContributorまたはOwner相当のロールが挙げられています。(Microsoft Learn)
実務では、次のように権限を分けると管理しやすくなります。
| 役割 | 推奨される権限設計 |
|---|---|
| クラウド管理者 | リソース作成、ネットワーク、ID、コスト管理を担当 |
| AI開発者 | Foundryプロジェクト、Language機能、APIキーまたは認証情報を利用 |
| 業務検証担当 | Playgroundでサンプル入力と出力確認のみ実施 |
| セキュリティ担当 | ログ、データ持ち出し、個人情報投入ルールを確認 |
全員に広い権限を付与すると、検証段階で意図しないリソース作成や実データ投入が起きやすくなります。最初は検証用プロジェクトを分け、業務担当者には必要最小限の権限を割り当てるのが現実的です。
既存のLanguage Studioリソースを使うか、新しいFoundryリソースを作るか
すでにAzure AI Languageを利用している組織は、既存リソースをFoundryから使う方法と、新しいFoundryリソースへ移す方法を比較する必要があります。Microsoftの移行ガイドでは、既存のLanguageリソースをFoundry Hubに接続して使う方法と、新しいFoundryリソースへプロジェクトをエクスポート・インポートする方法が案内されています。(Microsoft Learn)
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| 既存Languageリソースを使う | 既存の構成、エンドポイント、運用を大きく変えたくない | Foundryとの接続、RBAC、リージョン互換性を確認する |
| 新しいFoundryリソースを作る | AI機能をFoundry中心に整理したい、新規開発を始める | プロジェクト移行、接続設定、検証環境と本番環境の分離が必要 |
| 検証用に別リソースを作る | まずPoCだけ行いたい | コスト上限、データ投入ルール、削除期限を決めておく |
今回のPlayground一般提供をきっかけに、既存のAzure AI Language利用状況を棚卸ししておくと、今後のFoundry移行がスムーズになります。
Language Studio終了予定への備え
管理者が見落としやすいのが、Language Studioの今後です。Microsoft Learnでは、Azure Language Studioは2027年3月20日にMicrosoft Foundryへ移行予定であり、その日以降Language Studioポータルは利用できなくなる一方、既存のプロジェクト、データ、サービスエンドポイントには影響しないと説明されています。(Microsoft Learn)
つまり、すぐにAPIが止まるわけではありません。しかし、画面操作、検証、プロジェクト管理の中心はFoundryへ移っていきます。
今のうちに確認すべきことは次の通りです。
| 確認項目 | なぜ必要か |
|---|---|
| Language Studioで管理しているプロジェクト一覧 | 移行対象の把握に必要 |
| 利用中のAzure Languageリソース | Foundry接続または新規移行の判断に必要 |
| リージョンとネットワーク構成 | Foundry側で同じ運用ができるか確認するため |
| 利用者と権限 | 移行後に業務担当者が検証できなくなる事態を防ぐため |
| エクスポート手順 | 期限後にLanguage Studio上のエクスポート機能が使えなくなる可能性に備えるため |
開発者が確認すべき実装ポイント
Playgroundは便利ですが、本番開発ではAPI、SDK、認証、ログ、例外処理まで設計する必要があります。Playgroundの結果をそのまま業務判断に使うのではなく、「出力の傾向を理解するための検証環境」として位置付けるのが安全です。
API・SDKの利用方法
Text Analytics for Healthは、REST APIやクライアントライブラリから利用できます。Microsoft Learnの日本語クイックスタートでは、C#、Java、NodeJS、Python、REST APIがサポート対象として案内されています。(Microsoft Learn)
開発チームでは、次の順序で検証すると手戻りを減らせます。
| 手順 | 実施内容 | 成果物 |
|---|---|---|
| Playgroundで検証 | サンプル医療文書を入力し、抽出結果を確認 | 期待する出力項目の整理 |
| APIで再現 | 同じテキストをAPIから送信し、JSON出力を確認 | 実装方針、レスポンス解析方針 |
| 業務データで評価 | 匿名化済みデータで精度と欠落を確認 | 評価表、誤抽出パターン |
| アプリに組み込み | UI、検索、分類、レビュー画面へ連携 | プロトタイプ |
| 運用設計 | ログ、監査、再実行、エラー処理を設計 | 運用手順書 |
重要なのは、Playgroundで「それらしい結果が出た」段階で完了にしないことです。医療文書では、否定表現、既往歴、家族歴、疑い病名、薬剤中止など、業務上の判断に影響する表現が多く含まれます。API実装時は、抽出された単語だけでなく、Assertion Detectionによる文脈情報も確認しましょう。
出力形式とFHIR連携
Microsoftのドキュメントでは、Text Analytics for HealthがFHIR構造で処理結果を返せることも説明されています。FHIRは医療情報システムとの連携で使われる標準仕様の一つです。(Microsoft Learn)
FHIR出力を使うかどうかは、次の基準で判断するとよいでしょう。
| 判断基準 | FHIR出力が向いているケース |
|---|---|
| 既存システム連携 | 電子カルテ、医療データ基盤、FHIRサーバーと連携する |
| データ標準化 | 医療概念を標準形式で扱いたい |
| 長期運用 | 独自JSONよりも将来的な相互運用性を重視する |
| PoC段階 | まずは通常のAPI出力で十分な場合もある |
PoCでは扱いやすい形式から始め、本番連携を見据える段階でFHIRを検討する進め方が現実的です。
コストと課金で注意すべき点
Playgroundで検証を始める前に、コストの見方も確認しておきましょう。Azure Languageの価格ページでは、Standard層は送信されたText Record量に基づいて課金され、1Text Recordは最大1,000文字として扱われると説明されています。たとえば7,500文字の入力は8Text Recordsとしてカウントされます。(マイクロソフト アジュール)
医療文書は1件あたりの文字数が多くなりがちです。退院サマリー、紹介状、経過記録、研究要旨を大量に処理する場合、リクエスト数だけでなく文字数ベースで見積もる必要があります。
| よくある失敗 | 対策 |
|---|---|
| 文書件数だけで見積もる | 1文書あたりの平均文字数、最大文字数、月間件数で試算する |
| Playground検証と本番処理を同じリソースで行う | 検証用と本番用のリソースや予算管理を分ける |
| 長文をそのまま大量投入する | 分割単位、再実行条件、失敗時のリトライ回数を設計する |
| 使用量を後から確認しない | Azure portalのメトリックや予算アラートを設定する |
特にISVやSaaS事業者は、顧客ごとの利用量をどう把握するかが重要です。アプリ側でテナントID、処理件数、文字数、処理日時を記録し、Azure側のメトリックと照合できるようにしておくと、後からコスト説明がしやすくなります。
医療データを扱う上での重要な注意点
Text Analytics for Healthは医療文書処理に有用ですが、医療判断を自動化するための万能な仕組みではありません。Microsoftのドキュメントでも、個人やリソース配分に影響する判断、たとえば請求、人事、治療管理に関する判断は、人間の監督下で行うべきであり、モデルの出力だけに基づくべきではないと明記されています。(Microsoft Learn)
実データ投入前に匿名化ルールを決める
Playgroundは簡単に使えるため、現場担当者が実際の診療文書を貼り付けてしまうリスクがあります。検証開始前に、次のルールを明文化しておきましょう。
| 項目 | 推奨ルール |
|---|---|
| 患者氏名 | 必ず削除または仮名化する |
| 患者ID・保険番号 | 削除または検証用IDに置換する |
| 日付 | 必要に応じて相対日付やダミー日付へ置換する |
| 施設名・医師名 | 検証目的に不要なら削除する |
| 入力可能な文書 | 承認済みサンプルまたは匿名化済み文書に限定する |
| 結果の保存 | スクリーンショットや出力JSONの保管場所を制限する |
「検証だから大丈夫」ではなく、「検証環境ほどルールが曖昧になりやすい」と考えて管理することが重要です。
SDOHや民族性関連データの扱いに注意する
Text Analytics for Healthでは、SDOH、つまり健康の社会的決定要因に関する情報も扱われる場合があります。Microsoftは、SDOHや民族性抽出機能の目的は医療提供者が健康アウトカムを改善する支援であり、対象者や患者集団に対してスティグマ化や否定的推論を行うために使うべきではないと説明しています。(Microsoft Learn)
たとえば、住環境、雇用、生活習慣、家族状況、社会的支援の有無といった情報は、医療支援には役立つ一方で、不適切に使うと差別や不利益判断につながります。システム設計時は、抽出した項目を誰が閲覧できるか、どの業務目的で利用するか、二次利用を許可するかを明確にしましょう。
移行・展開時のチェックリスト
今回の更新を受けて、管理者と開発者が実際に動くなら、次の順序で確認すると安全です。
| フェーズ | 確認内容 |
|---|---|
| 現状把握 | 既存のAzure AI Languageリソース、Language Studio利用状況、担当者を洗い出す |
| 権限整理 | Foundryプロジェクト、接続済みリソース、RBAC、管理者ロールを確認する |
| データルール作成 | Playgroundに入力してよいデータ、匿名化方法、結果保存ルールを決める |
| Playground検証 | 退院サマリー、医師メモ、研究要旨のサンプルで抽出結果を確認する |
| API検証 | REST APIまたはSDKで同じ結果を再現し、レスポンス処理を確認する |
| コスト試算 | 文字数、月間件数、再実行回数をもとにText Record量を見積もる |
| 精度評価 | 医療者または業務担当者が、誤抽出・見落とし・文脈誤りをレビューする |
| 本番設計 | ログ、監査、例外処理、人間による確認フローを組み込む |
| 移行計画 | Language StudioからFoundryへの移行方針と期限を決める |
特に重要なのは、Playground検証と本番利用を混同しないことです。Playgroundは出力を素早く理解するための場所であり、業務システムに組み込むには、API実装、データ保護、監査、医療者レビューが必要です。
よくある疑問
既存のText Analytics for Health APIはすぐ変更が必要ですか
今回の情報だけを見る限り、主な変更点はNextGen Playgroundの一般提供です。既存APIのエンドポイントやアプリ実装が直ちに変更必須になるという案内ではありません。ただし、Language StudioからMicrosoft Foundryへの移行予定があるため、管理画面や検証フローはFoundry中心に見直しておくべきです。
医療文書を貼り付けるだけで構造化できますか
Playgroundでは、診療文書や研究要旨などを貼り付けて抽出結果を確認できます。ただし、実務で使うには誤抽出、否定表現、既往歴、疑い病名、略語の扱いを評価する必要があります。最終的な医療判断や患者対応に使う場合は、人間のレビューを前提にしてください。
日本語の医療文書に対応していますか
Microsoft Learnでは、Text Analytics for Healthが受け取れる非構造化テキストの言語として、英語、ドイツ語、フランス語、イタリア語、スペイン語、ポルトガル語、ヘブライ語が示されています。日本語医療文書を扱う場合は、公式の対応言語、最新ドキュメント、実データでの検証結果を確認してから設計する必要があります。(Microsoft Learn)
Azure AI FoundryとAzure AI Languageの関係はどう考えるべきですか
Azure AI Languageは、Foundry Toolsの中で自然言語処理機能を提供するサービスとして位置付けられています。Microsoftの製品ページでは、Azure AI LanguageがAzure Language in Foundry Toolsとして位置付けられ、Foundry上で自然言語機能を発見、統合、利用しやすくなる流れが説明されています。(マイクロソフト アジュール)
実務上は、Azure AI FoundryをAI開発・検証の入口、Azure AI Languageを自然言語処理の機能群、Text Analytics for Healthを医療テキスト分析の機能として整理すると理解しやすいでしょう。
まず何をすべきか
今回のText Analytics for Health NextGen Playground一般提供は、医療テキスト分析をAzure AI Foundry上で検証しやすくする更新です。管理者は、Foundryへの利用導線、Language Studioからの移行、権限、コスト、データ保護を確認しましょう。開発者は、Playgroundで出力傾向を把握したうえで、REST APIやSDKによる実装、FHIR連携、例外処理、医療者レビューの設計に進むのが現実的です。
最初の一歩としては、匿名化済みの退院サマリーや医師メモを数パターン用意し、FoundryのPlaygroundで抽出結果を確認してください。その結果をもとに、使える項目、誤りやすい表現、業務画面で人間が確認すべき箇所を洗い出すと、本番展開に向けた判断がしやすくなります。
コメント