Amazon Comprehend Medicalとは？5系統APIと料金・東京リージョン非対応の実装判断【2026年版】

Amazon Comprehend Medicalは、英語の臨床テキストから病名・薬剤・検査値・PHI（保護対象保健情報）を抽出し、ICD-10-CM・RxNorm・SNOMED CTのコードへ結び付けるマネージドAPIです。対応言語は英語（US-EN）だけで、東京リージョン（ap-northeast-1）にエンドポイントが用意されていません。この記事では5系統APIの使い分け、100文字＝1ユニットという課金単位、20KBの入力上限とTPS制限から逆算する分割設計、日本語の診療録を扱うときの構成、そして案件として採用するか見送るかの判定条件までを実装目線で整理します。

まとめ：英語限定と東京リージョン非対応を前提にした採否の結論

採用してよいのは、扱う文書が英語の臨床テキストであり、出力に標準コード（ICD-10-CM・RxNorm・SNOMED CT）が要る案件です。米国・カナダ・アイルランド・ロンドン・シドニーのいずれかで処理を完結できるなら、自前のNLPモデルを訓練するより速く着地します。逆に、日本語カルテの要約や日本語での質問応答が主目的なら、この製品は選びません。英語化の前処理を挟むぶんだけ固有名詞と用量表記が崩れ、精度の説明責任が増えるためです。

費用面では、エンティティ抽出のNERe APIが1ユニット0.01米ドル、RxNormリンクが0.00025米ドルと、同じ100文字あたりで40倍の開きがあります。全文をNEReに通す設計は、要件を満たしていても請求額で破綻しがちです。PHI検出はSafe Harborの18項目をタグ付けしますが、匿名加工の最終責任は呼び出し側に残ります。信頼度スコアのしきい値設計と人によるレビュー工程を含めて見積もる前提で読み進めてください。

Comprehend Medicalの定義と通常版Comprehendの機能差

AWSはComprehend Medicalを「医師の記録、退院サマリ、検査結果、症例記録といった非構造の臨床テキストから有用な情報を検出して返すサービス」と定義しています。汎用の自然言語処理サービスであるAmazon Comprehendとは料金体系もAPIエンドポイントも別建てで、医療エンティティに特化した学習済みモデルが動きます。

診療記録から7カテゴリのエンティティと属性・特性を抽出する流れ

DetectEntitiesV2が返すカテゴリはANATOMY、BEHAVIORAL_ENVIRONMENTAL_SOCIAL、MEDICAL_CONDITION、MEDICATION、PROTECTED_HEALTH_INFORMATION、TEST_TREATMENT_PROCEDURE、TIME_EXPRESSIONの7種です。公式ガイドは7カテゴリを列挙する一方、同じページの要約行に「6カテゴリ」という旧記述が残っています。行動・環境・社会的健康のカテゴリが2022年11月に追加された経緯によるもので、実装時は列挙側を正としてください。

抽出結果はEntity（実体）、Category（大分類）、Type（種別）、Attribute（属性）、Trait（特性）、Relationship Type（関係）の6クラスで構造化されます。「chronic pain in left leg」という記述なら、痛みがエンティティ、chronicがACUITY、leftがDIRECTION、legがSYSTEM_ORGAN_SITEとして関係付けられ、それぞれに信頼度スコアが付きます。

Amazon Comprehendとの違いは英語限定と医療エンティティの粒度

本体のAmazon Comprehendは日本語を含む複数言語で感情分析やエンティティ認識ができ、東京リージョンでも動きます。読み方や日本語での可否、本体側の料金はAmazon Comprehendとは？読み方・できること・料金と日本語で使える機能で整理しました。医療用の語彙と否定表現の判定を求めるなら、本体のカスタムエンティティ認識を訓練するより、Comprehend Medicalの学習済みモデルを英語で回すほうが工数が小さくなります。

差が出るのは粒度です。本体のエンティティ認識で「200 mg」は数量に丸められますが、Comprehend MedicalはDOSAGEという属性として薬剤エンティティに紐付けます。投与経路のROUTE_OR_MODE、投与頻度のFREQUENCY、力価のSTRENGTHまで別属性で返るため、処方内容をそのまま表へ落とせます。

NEGATIONなどの特性判定が構造化データ生成で効く実装場面

特性（Trait）は文脈からの判定結果です。NEGATIONは「服用していない」「所見なし」を示し、DIAGNOSISは確定診断、SIGNは医師が記録した他覚所見、SYMPTOMは患者の自覚症状を区別します。PAST_HISTORYは今回の受診より前の情報、PERTAINS_TO_FAMILYは家族歴、HYPOTHETICALは仮定の記述を表します。

治験の患者スクリーニングでは、この特性の扱いが結果を左右する要素です。「no history of diabetes」を否定と判定できなければ、除外すべき候補が抽出結果に混じります。単純なキーワード一致で組んだ既存処理を置き換える価値は、ここに出ます。

Comprehend Medicalの5系統APIの役割と使い分けの実装基準

同期APIは5系統あり、それぞれに非同期のバッチジョブが対応します。旧DetectEntitiesも残っていますが、公式リファレンスは「DetectEntitiesV2がDetectEntities操作を置き換える。新しいアプリケーションではすべてV2を使うこと」と明記しています。

DetectEntitiesV2とDetectPHIの出力差と選択の判断軸

DetectEntitiesV2はPHIを含む7カテゴリを一度に返します。DetectPHIはPHIだけに絞った専用オペレーションで、種別はADDRESS、AGE、EMAIL、ID、NAME、PHONE_OR_FAX、PROFESSIONの7つです。マスキングだけが目的ならDetectPHIを選びます。単価がNEReの7分の1で、返却されるエンティティ数も絞られるため、後段の突合処理が軽くなります。

PHIとPII（個人を特定できる情報）は定義が重なりつつ範囲が違います。日本の個人情報保護法との対応関係を確認するならPII（個人を特定できる情報）とは？piiデータの定義・種類と個人情報の違いを先に読んでおくと、要件定義での取り違えを避けられます。

ICD-10-CM・RxNorm・SNOMED CTのオントロジーリンクの違い

オントロジーリンクは、検出したエンティティを標準コードへ推論で結び付ける処理です。3系統の用途と制約を並べます。

モデル版は自動更新されます。2026年3月19日の更新でInferICD10CMは3.3.0.20251001系、InferRxNormは3.3.0.20221107系、InferSNOMEDCTは3.3.0.20220301系になりました。2025年11月3日の更新では、2025年10月1日発効の2026年版ICD-10-CMコードセットへの対応が入っています。コード表の年度が要件に含まれる案件では、この更新履歴を追う運用が要ります。

同期APIと非同期バッチジョブの切り替えを決める処理量の目安

同期APIは1リクエストで1文書を処理します。非同期はS3上のファイル群をStartEntitiesDetectionV2Jobなどで一括処理する方式です。切り替えの基準は文書量と応答要件で、画面から1件ずつ解析する用途は同期、夜間に数万件を回すなら非同期を選びます。SNOMED CTコードが要件に入った時点では、後述のTPS制限から非同期前提へ切り替えてください。

boto3での呼び出しとModelVersionを記録する運用手順

クライアント名はcomprehendmedicalで、本体のcomprehendとは別です。リージョン指定を省略すると東京が既定になる環境では、エンドポイント不在で失敗します。呼び出し時にリージョンを明示してください。

レスポンスにはModelVersionが含まれます。モデル更新が自動で入る製品では、抽出結果とモデル版を対にして保存しておかないと、後から精度差の原因を切り分けられません。監査対応が要る案件では、入力のハッシュ・ModelVersion・信頼度スコアの3点を同じレコードに残す設計を推奨します。

API別の従量料金と無料枠85,000ユニットからの費用試算

課金単位は100文字＝1ユニットで、1リクエストあたり最低1ユニットが計上されます。無料枠はサービス利用を開始した最初の1か月に85,000ユニット（850万文字）で、どのAPIに使っても構いません。

NERe・PHI・オントロジー3種の1ユニット単価の実測差と段階割引

AWSのPrice List API（バージニア北部・2026年7月30日取得）から抜き出した単価です。単位は米ドル、段階は月内の累計ユニット数で切り替わります。

注目すべきは段階割引の効き方の違いです。NEReは200万ユニットを超えると10分の1になりますが、InferRxNormは全段階で同額です。SNOMED CTリンクはICD-10-CMリンクの15倍で、オントロジー3種の中では突出しています。コード体系の選定は精度だけでなく、この単価差でも決まります。

電子カルテ1万件をPHI検出したときの月額コストの概算の手順

AWS公式の試算例は1チャート5ページ・1ページ1,700文字を前提にしています。1万件なら1万×5×1,700÷100で85万ユニット。PHId APIの第1段階0.0014米ドルを掛けて月額1,190米ドルです。同じ処理量をNEReで回すと8,500米ドルになり、7倍以上に膨らみます。

公式例の3.5万チャート・月では、NEReで297.5万ユニットとなり、段階割引を適用した合計は15,975米ドルです。全文をエンティティ抽出に通す前提で概算すると、この規模で年間19万米ドルに届きます。先にDetectPHIで匿名化し、必要な章だけをNEReへ渡す二段構成に落とすと、対象文字数を1桁減らせる案件が少なくありません。

1リクエスト最低1ユニット課金が短文の大量処理で効く落とし穴

最低課金は1リクエスト1ユニット、つまり100文字ぶんです。30文字のチャットログを1件ずつ投げる設計では、実際の文字数の3倍以上を支払います。100万件なら100万ユニット、NEReで1万米ドルです。

回避策は単純で、複数の短文を1リクエストにまとめ、返却されたオフセットで元レコードへ割り戻します。区切り文字を挟むぶんだけ文脈がつながって誤検出が増える場合があるため、まとめる件数は精度を実測しながら決めてください。

入力文字数上限とTPS制限を踏まえた分割処理とリトライの設計

クォータは同期と非同期で別に定義されています。上限を超えるとTextSizeLimitExceededExceptionが返るため、前処理側で分割する設計が前提になります。

20KB上限に対する退院サマリのオフセット維持分割の実装パターン

同期の最大文書サイズは、DetectEntitiesV2・DetectEntities・DetectPHIが20KB、InferICD10CMとInferRxNormが10KB、InferSNOMEDCTが5KBです。DetectEntitiesV2のText引数は「20,000バイト未満」と定義され、最大長は20000で指定されています。UTF-8のバイト数基準なので、英語想定でも記号やアクセント付き文字が混じると想定より早く上限に当たります。

分割で崩れるのはオフセットです。APIは開始位置と終了位置を数値で返すため、分割後のチャンク内オフセットに元文書の先頭位置を加算して復元する処理を必ず持たせます。AWSは分割用のサンプルsegment.pyを配布していますが、章立ての境界で切らないと否定表現が分断されるため、改行や見出しを優先して切るロジックを足すほうが安全です。

InferSNOMEDCTの2TPS制限がボトルネックになる条件

同期の秒間トランザクションは、DetectEntitiesV2・DetectEntities・DetectPHI・InferRxNorm・InferICD10CMが40TPS・40,000CPSに対し、InferSNOMEDCTだけが2TPS・5,000CPSです。5KBの文書を投げると1リクエストで秒間文字数の枠をほぼ使い切ります。

秒間2件では1万文書に80分以上かかります。日次バッチなら許容できても、対話型の画面から同期で叩く設計は成立しません。SNOMED CTが要件なら、非同期ジョブで前処理しておき、画面側は結果を参照するだけにします。

バッチジョブの70KB・1GB上限と同時実行10本の運用制約

非同期ジョブの制約は次のとおりです。ジョブ設計は、この4つの数値から逆算します。

• 個別ファイルの最大サイズ：70KB
• 1ジョブに含められるファイル数：最大500万
• 1ジョブの合計サイズ：1GB
• オペレーションごとの同時実行ジョブ数：10

ジョブの開始・停止系は5TPS、一覧・詳細取得系は10TPSです。ポーリング間隔を1秒未満に詰めると、詳細取得側でスロットリングされます。ジョブIDごとに5秒間隔で確認する程度で足ります。加えて、非同期ジョブのファイルパスに連続したスラッシュを使えない仕様があるため、S3キーの組み立てでは区切りの重複を除去してください。

日本語の診療録をTranslateで英語化する連携構成と精度リスク

Comprehend Medicalが検出するのは英語（US-EN）のテキストのみで、文字エンコードはUTF-8です。日本語のカルテをそのまま投げても医療エンティティは返りません。国内案件でこの制約を回すには、前段に翻訳を挟むか、別のモデルへ寄せるかの二択になります。

Amazon Translateを前段に置く構成で崩れる用語と対処

紙のカルテやスキャンPDFが起点なら、OCRで文字化したうえで翻訳し、Comprehend Medicalへ渡す3段構成になります。翻訳側の料金と使い方はAmazon Translateとは？料金・無料枠と使い方（boto3）を解説にまとめています。

この構成で崩れるのは、日本固有の薬剤名と用量表記です。先発品名の音訳は成分名に落ちず、InferRxNormのコードが引けません。「1日3回毎食後」のような服用指示も、直訳ではFREQUENCY属性として拾われにくくなります。対処は前処理での辞書置換です。院内の採用薬マスタを一般名（英語）へ変換する対応表を持ち、翻訳前に置き換えます。翻訳工程を挟む案件では、この辞書整備が工数の中心になると見込んでください。

BedrockのLLMとComprehend Medicalを併用するRAG構成

AWSの規範ガイダンスは、Comprehend MedicalとLLMを組み合わせる構成を示しています。抽出はComprehend Medicalが担い、要約や質問応答、カスタムエンティティの追加はBedrock上のモデルが担う分担です。標準コードへの紐付けという決定論的な処理と、文章生成という確率的な処理を分けられるため、監査時に「どの値がどのAPI由来か」を説明できます。

医療分野に特化したモデル提供も動いています。Anthropic、医療支援AI「Claude for Healthcare」を正式発表、注目の特徴と狙いで扱った動きのように、LLM側が臨床文書の扱いを強化している状況では、抽出専用APIとの役割分担を設計時点で決めておく価値があります。

日本語のまま処理する場合にComprehend Medicalを選ばない基準

判断は明快です。出力に標準コードが要らず、日本語のまま要約や分類ができればよい案件では、Comprehend Medicalを選びません。翻訳工程の精度検証と辞書保守という固定費が、得られる構造化の価値を上回ります。この場合はBedrock上のモデルへ直接投げ、抽出項目をスキーマで縛るほうが総工数が小さくなります。

逆に、レセプト請求や治験データのように出力コードが決まっている案件では、翻訳工程を含めてもComprehend Medicalが有利です。コード付与の根拠が信頼度スコアとして数値で残るため、人によるレビュー範囲をしきい値で区切れます。

利用可能リージョンとHIPAA適格性から見る医療案件での適否

データの保存場所とコンプライアンス要件は、国内の医療案件で最初に詰める論点です。ここを曖昧にしたまま実装へ進むと、結合テスト後に構成をやり直す事態になります。

東京リージョン非対応が国内の医療案件の設計に与える制約と回避策

AWS SDKのエンドポイント定義（botocore・2026年7月30日取得）でcomprehendmedicalが持つリージョンは、バージニア北部、オハイオ、オレゴン、カナダ中部、アイルランド、ロンドン、シドニーの7つです。GovCloud（米国西部）とFIPSエンドポイントも定義されています。東京と大阪は含まれません。本体のAmazon Comprehendがap-northeast-1で使えるため、同じ感覚で設計すると認証エラーではなくエンドポイント解決の失敗で気付きます。

回避策は3つあります。第1に、解析対象を匿名化してから海外リージョンへ送る構成。第2に、東京リージョンのS3とLambdaで前後処理を組み、API呼び出しだけを海外リージョンへ向ける構成。第3に、リージョン制約を満たすため国内提供の別手段へ替える判断です。第2案が現実的な落としどころですが、通信経路とログの保存先まで含めて説明できる状態にしてから採用してください。

HIPAA適格とデータ非保持が示す外部委託時の説明責任の範囲

Comprehend MedicalはHIPAA適格サービスです。PHIを含む通信は暗号化が必須で、既定でTLS上のHTTPSが使われます。AWSは「顧客コンテンツを永続的に保存しない」と明記しており、そのためサービス内での保存時暗号化の設定は不要とされています。

ただし公式ガイドは、専門的な医療助言・診断・治療の代替ではないと繰り返し注意しています。信頼度スコアのしきい値をユースケースごとに定め、高い精度が要る場面では高いしきい値を使い、訓練された医療専門家がレビューしたうえで患者ケアに用いるという条件付きです。受託開発では、この条件をそのまま要件定義書と運用手順へ落とし込む作業が発生します。

2026年6月に第7.0版へ改定された安全管理ガイドラインとの関係

厚生労働省の「医療情報システムの安全管理に関するガイドライン」は、2026年6月に第7.0版が公表されました。概説編・経営管理編・企画管理編・システム運用編・保守委託機関編の5編構成です。医療機関側がこの改定に沿って外部委託とクラウド利用の責任分界を見直す局面では、保存場所が国外になる構成の説明資料が求められます。

医療分野のシステム全体でどう位置付けるかは生成AI開発・AI受託開発の相談段階で整理するのが早い領域です。エンドポイントの所在、データの流れ、レビュー工程の3点を先に固めれば、要件定義の手戻りを抑えられます。

Comprehend Medicalを採用する案件と見送る案件の切り分け

ここまでの制約を踏まえ、採否の条件を言い切ります。玉虫色の結論では判断材料になりません。

英語の臨床文書をコード付きで構造化するなら採用してよい3つの条件

次の3条件がそろえば採用します。第1に、対象文書が英語の臨床テキストであること。第2に、出力にICD-10-CM・RxNorm・SNOMED CTのいずれかのコードが要ること。第3に、処理を提供7リージョンのいずれかで完結できること。この3つを満たす案件では、医療用語辞書と否定表現の判定を自前で作る工数を丸ごと削減できます。

AWSが挙げるユースケースは、患者ケース管理、臨床研究、医療請求とレベニューサイクル管理、そしてオントロジーリンクの4領域です。なかでもコンピュータ支援コーディング（CAC）は、人手で滞留した請求コード付与を置き換えるため投資回収の見通しが立てやすい部類です。

日本語カルテの要約が主目的の案件で採用を見送るべき理由と代替

日本語のカルテを要約したい、あるいは日本語で検索できるようにしたいという要件では見送ります。翻訳の前処理で失われる情報が結果の品質を決めてしまい、Comprehend Medical側の精度を評価できなくなるためです。代替はBedrock上のモデルへ日本語のまま投げる構成です。抽出項目をJSONスキーマで縛り、信頼できない項目は空で返させる設計にすれば、実用水準に届きます。

電子カルテそのものの選定や開発判断が論点なら、先に業務要件を固める段階です。電子カルテとは？種類・メリットと失敗しない選び方・開発判断を解説【2026年】で選定軸を確認したうえで、NLPをどの工程に置くかを決めるほうが順序として無理がありません。

PHIマスキングをこれ1本に任せて失敗に至る典型的なパターン

DetectPHIはSafe Harborの18項目に沿ってPHIを検出しますが、検出漏れがゼロになる保証はありません。信頼度スコアが低い候補を機械的に捨てる実装は、そのまま漏えいリスクになります。しきい値を下げて過検出を許し、人が確認する運用のほうが安全側です。

もう1つの失敗は、匿名加工の適法性までAPIに委ねる設計です。日本の個人情報保護法における仮名加工情報・匿名加工情報の要件と、Safe Harborの18項目は一致しません。米国基準でタグ付けした結果を国内基準の匿名加工と読み替えた時点で、後段の第三者提供が成立しなくなります。法務確認を工程に含めない案件は、実装前に差し戻すのが正解です。

よくある質問

実装検討でよく確認される点を、公式ドキュメントの記載に沿って整理します。

Amazon Comprehend Medicalは日本語に対応していますか？

対応していません。公式ガイドは「Amazon Comprehend Medicalは英語（US-EN）のテキストでのみ医療エンティティを検出する」と明記しており、文字エンコードもUTF-8の英語が前提です。日本語の診療録を扱う場合は、Amazon Translateなどで英語化してから投げる構成になります。ただし薬剤の先発品名や服用指示は翻訳で崩れやすく、辞書による前処理が必要です。日本語のまま要約や分類をしたいだけなら、Bedrock上のモデルを選ぶほうが構成が単純になります。

Amazon ComprehendとComprehend Medicalの違いは何ですか？

対象領域と料金体系、そしてAPIエンドポイントが別です。本体のAmazon Comprehendは日本語を含む多言語で感情分析やエンティティ認識を提供し、東京リージョンでも使えます。Comprehend Medicalは英語の臨床テキストに特化し、病名や薬剤を検出したうえでICD-10-CM・RxNorm・SNOMED CTのコードへ結び付けます。薬剤の用量や投与経路を属性として個別に返す粒度も本体にはありません。boto3のクライアント名もcomprehendmedicalと別指定です。

Comprehend Medicalは東京リージョンで使えますか？

使えません。AWS SDKのエンドポイント定義でcomprehendmedicalが提供されるのは、バージニア北部、オハイオ、オレゴン、カナダ中部、アイルランド、ロンドン、シドニーの7リージョンとGovCloud（米国西部）です。ap-northeast-1は含まれないため、東京を既定リージョンにしたまま呼び出すとエンドポイント解決で失敗します。国内案件では、前後処理を東京リージョンに置き、API呼び出しだけを海外リージョンへ向ける構成が現実的な選択になります。

料金はいくらかかりますか？無料枠はありますか？

課金単位は100文字＝1ユニットで、1リクエストあたり最低1ユニットが計上されます。バージニア北部の第1段階単価は、NEReが1ユニット0.01米ドル、DetectPHIが0.0014米ドル、InferICD10CMが0.0005米ドル、InferRxNormが0.00025米ドル、InferSNOMEDCTが0.0075米ドルです。無料枠は利用開始の初月に85,000ユニット（850万文字）で、どのAPIに使っても構いません。公式試算では、5ページ1,700文字のチャート1,000件をNEReで処理して850米ドルという例が示されています。

DetectEntitiesとDetectEntitiesV2はどちらを使うべきですか？

新規実装はDetectEntitiesV2です。公式リファレンスは「DetectEntitiesV2はDetectEntities操作を置き換える。新しいアプリケーションではすべてV2を使うこと」と記載しています。V2はAcuityとDirectionを種別ではなく属性として返し、行動・環境・社会的健康のカテゴリにも対応する仕様です。2026年3月19日の更新で両者ともモデル版3.3.0系になりましたが、出力構造が違うため移行時はマッピングの見直しが要ります。レスポンスのModelVersionを保存しておくと差分の追跡が容易です。

関連記事

• Amazon Comprehendとは？読み方・できること・料金と日本語で使える機能：本体サービスの読み方・日本語対応・料金体系を扱う親記事です。
• Amazon Textractとは？機能・料金・使い方と他OCRとの違いを解説：紙のカルテやスキャンPDFを文字化する前段工程の選定に使えます。
• 電子カルテとは？種類・メリットと失敗しない選び方・開発判断を解説【2026年】：解析対象となる電子カルテ側の要件と選定軸を整理しています。
• 医療DXとは？定義・3本柱・2026年度改定から進め方と受託開発の判断まで解説：医療分野のシステム投資をどの順で進めるかの全体像を扱います。