--- title: "Amazon Comprehend Medicalとは？5系統APIと料金・東京リージョン非対応の実装判断【2026年版】" url: "https://www.issoh.co.jp/tech/details/15924/" published: 2026-07-30 updated: 2026-09-22 categories: ["AI"] publisher: "株式会社一創" --- # 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制限から逆算する分割設計、日本語の診療録を扱うときの構成、そして案件として採用するか見送るかの判定条件までを実装目線で整理します。boto3で実行できるコードと、通常版のAmazon Comprehendを同じ処理量で回したときの金額差も並べました。本文中の数値は2026年9月22日に公式ドキュメントで確認した時点のものです。 ## まとめ：英語限定と東京リージョン非対応を前提にした採否の結論 採用してよいのは、扱う文書が英語の臨床テキストであり、出力に標準コード（ICD-10-CM・RxNorm・SNOMED CT）が要る案件です。米国3リージョン・カナダ中部・アイルランド・ロンドン・シドニーのいずれかで処理を完結できるなら、自前のNLPモデルを訓練するより速く着地します。逆に、日本語カルテの要約や日本語での質問応答が主目的なら、この製品は選びません。英語化の前処理を挟むぶんだけ固有名詞と用量表記が崩れ、精度の説明責任が増えるためです。 費用面では、エンティティ抽出のNERe APIが1ユニット0.01米ドル、RxNormリンクが0.00025米ドルと、同じ100文字あたりで40倍の開きがあります。全文をNEReに通す設計は、要件を満たしていても請求額で破綻しがちです。通常版のAmazon Comprehendは同じ100文字単位で第1段階0.0001米ドルなので、医療エンティティが要らない処理まで医療版へ寄せると100倍を支払う計算になります。PHI検出はHIPAAの18識別子に関連するエンティティを返しますが、公式は「Safe Harbor方式が定めるリストと1対1で対応するものではない」と書いています。匿名加工の最終責任は呼び出し側に残る前提で読み進めてください。 ## Comprehend Medicalの定義と通常版Comprehendの機能差 AWSは[開発者ガイドの冒頭](https://docs.aws.amazon.com/comprehend-medical/latest/dev/comprehendmedical-welcome.html)で、Comprehend Medicalを「医師の記録、退院サマリ、検査結果、症例記録といった非構造の臨床テキストから有用な情報を検出して返すサービス」と定義しています。汎用の自然言語処理サービスであるAmazon Comprehendとは料金体系もAPIエンドポイントも別建てで、医療エンティティに特化した学習済みモデルが動きます。 ### 診療記録から7カテゴリのエンティティと属性・特性を抽出する流れ DetectEntitiesV2が返すカテゴリは`ANATOMY`、`BEHAVIORAL_ENVIRONMENTAL_SOCIAL`、`MEDICAL_CONDITION`、`MEDICATION`、`PROTECTED_HEALTH_INFORMATION`、`TEST_TREATMENT_PROCEDURE`、`TIME_EXPRESSION`の7種です。[公式のDetect entities（Version 2）ページ](https://docs.aws.amazon.com/comprehend-medical/latest/dev/textanalysis-entitiesv2.html)は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とは？読み方・できること・料金と日本語で使える機能](https://www.issoh.co.jp/tech/details/3110/)で整理しました。医療用の語彙と否定表現の判定を求めるなら、本体のカスタムエンティティ認識を訓練するより、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」を否定と判定できなければ、除外すべき候補が抽出結果に混じります。単純なキーワード一致で組んだ既存処理を置き換える価値は、ここに出ます。 ## boto3でDetectPHIを実行して抽出結果を目視で確かめる手順 仕様の読み合わせだけで採否を決めると、返却されるスコアの散り方を見落とします。ここでは公式が例示している1文をそのまま投げ、返り値の形を確かめるところまでを手順にします。[boto3のComprehendMedicalクライアント仕様](https://docs.aws.amazon.com/boto3/latest/reference/services/comprehendmedical.html)に沿った呼び出しです。 ### リージョンを明示してクライアントを生成し公式例の1文を投げるコード クライアント名は`comprehendmedical`で、本体の`comprehend`とは別です。リージョン指定を省略すると東京が既定になる環境では、エンドポイント不在で失敗します。呼び出し時にリージョンを明示してください。次のコードはそのまま実行できます。 ``` import boto3 from botocore.config import Config # 東京リージョンにエンドポイントが無いため、呼び出し側でリージョンを明示する cfg = Config(retries={"max_attempts": 5, "mode": "adaptive"}) client = boto3.client("comprehendmedical", region_name="us-east-1", config=cfg) text = "Patient is John Smith, a 48-year-old teacher and resident of Seattle, Washington." res = client.detect_phi(Text=text) print("ModelVersion:", res["ModelVersion"]) for e in res["Entities"]: print(e["Type"], "|", e["Text"], "|", round(e["Score"], 3), "|", e["BeginOffset"], e["EndOffset"]) ``` [公式のDetect PHIページ](https://docs.aws.amazon.com/comprehend-medical/latest/dev/textanalysis-phi.html)が載せている同じ文の応答では、`John Smith`が`NAME`でスコア0.997、`48`が`AGE`で0.999、`teacher`が`PROFESSION`で0.866、`Seattle`が`ADDRESS`で0.963、`Washington`が同じ`ADDRESS`で0.382です。州名だけスコアが1桁低い点に注目してください。しきい値を0.5で切る実装は、この時点で州名を取りこぼします。 ### 返却されたオフセットで原文を後ろからマスキングに置き換える処理 応答に含まれるのは文字位置だけで、マスキング済みのテキストは返りません。置換は呼び出し側の仕事です。後ろから置き換えると位置がずれずに済みます。 ``` def mask(text, entities, threshold=0.2): keep = [e for e in entities if e["Score"] >= threshold] keep.sort(key=lambda e: e["BeginOffset"], reverse=True) out = text for e in keep: tag = "[" + e["Type"] + "]" out = out[: e["BeginOffset"]] + tag + out[e["EndOffset"] :] return out print(mask(text, res["Entities"])) # => [NAME] is a [AGE]-year-old [PROFESSION] and resident of [ADDRESS], [ADDRESS]. ``` しきい値を0.2まで下げているのは、先ほどの州名0.382を拾うためです。匿名化では過検出のほうが安全側に倒れます。逆に、抽出結果を統計や検索に使う場面では高いしきい値へ寄せます。同じAPIでも用途でしきい値が逆方向へ動く点は、要件定義の段階で握っておく項目です。 ### ModelVersionと信頼度スコアを同じレコードへ残す運用手順 応答には`ModelVersion`が含まれます。[DetectEntitiesV2のAPIリファレンス](https://docs.aws.amazon.com/comprehend-medical/latest/api/API%5FDetectEntitiesV2.html)は、この値を「特定の文書バッチに使われたモデルを追跡するために使える」と説明しています。モデル更新が自動で入る製品では、抽出結果とモデル版を対にして保存しておかないと、後から精度差の原因を切り分けられません。 監査対応が要る案件では、入力のハッシュ・ModelVersion・信頼度スコア・しきい値の4点を同じレコードに残す設計を推奨します。半年後に「この患者名がなぜ落ちたのか」を問われたとき、再現できる材料がこれだけあれば説明が可能です。逆に抽出後のテキストしか残していない構成は、再現不能な状態を自分で作っていることになります。 ## Comprehend Medicalの5系統APIの役割と使い分けの実装基準 同期APIは5系統あり、それぞれに非同期のバッチジョブが対応します。旧`DetectEntities`も残っていますが、公式リファレンスは「DetectEntitiesV2がDetectEntities操作を置き換える。新しいアプリケーションではすべてV2を使うこと」と明記しています。 ### DetectEntitiesV2とDetectPHIの出力差と選択の判断軸 DetectEntitiesV2はPHIを含む7カテゴリを一度に返します。DetectPHIはPHIだけに絞った専用オペレーションで、マスキングだけが目的ならこちらが選択肢です。単価がNEReの7分の1で、返却されるエンティティ数も絞られるため、後段の突合処理が軽くなります。 PHIとPII（個人を特定できる情報）は定義が重なりつつ範囲が違います。日本の個人情報保護法との対応関係を確認するなら[PII（個人を特定できる情報）とは？piiデータの定義・種類と個人情報の違い](https://www.issoh.co.jp/column/details/5207/)を先に読んでおくと、要件定義での取り違えを避けられます。 ### DetectPHIが返す9種別と日付・URLを見落とす設計の危うさ 公式のDetect PHIページが表で挙げるPHI種別は9つです。`AGE`、`DATE`、`NAME`、`PHONE_OR_FAX`、`EMAIL`、`ID`、`URL`、`ADDRESS`、`PROFESSION`で、HIPAAの識別子カテゴリ番号も併記されています。日本語の解説記事では`DATE`と`URL`が抜けた7種別で紹介されることがあり、この2つを落とすとマスキング仕様の穴になります。 とくに`DATE`は「患者または患者ケアに関連するあらゆる日付」と定義されており、受診日や手術日がここに入ります。`ID`の定義も広く、社会保障番号・診療録番号・保険番号・口座番号・免許番号・車両番号・機器番号・生体情報番号までを1つの種別で受けます。種別ごとに扱いを変える設計では、`ID`の中身を後段で分類する処理が別途要ると見込んでください。 ### ICD-10-CM・RxNorm・SNOMED CTのオントロジーリンクの違い オントロジーリンクは、検出したエンティティを標準コードへ推論で結び付ける処理です。3系統の用途と制約を並べます。 | API | 結び付ける対象 | 入力上限 | 同期TPS | | ------------- | ----------- | ---- | ----- | | InferICD10CM | 傷病名（診断コード） | 10KB | 40 | | InferRxNorm | 医薬品（成分・剤形） | 10KB | 40 | | InferSNOMEDCT | 所見・解剖・検査・処置 | 5KB | 2 | モデル版は自動更新されます。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制限から非同期前提へ切り替えてください。 ## API別の従量料金と無料枠85,000ユニットからの費用試算 課金単位は100文字＝1ユニットで、1リクエストあたり最低1ユニットが計上されます。[公式の料金ページ](https://aws.amazon.com/comprehend/medical/pricing/)によると、無料枠はサービス利用を開始した最初の1か月に85,000ユニット（850万文字）で、どのAPIに使っても構いません。 ### NERe・PHI・オントロジー3種の1ユニット単価の実測差と段階割引 AWSのPrice List API（バージニア北部・2026年7月30日取得）から抜き出した単価です。単位は米ドル、段階は月内の累計ユニット数で切り替わります。NEReとSNOMED CTの段階は公式料金ページの試算例とも一致しました。 | API | 100万まで | 100万〜200万 | 200万超 | | ---------------------- | ------- | --------- | ------- | | NERe（DetectEntitiesV2） | 0.01 | 0.005 | 0.001 | | PHId（DetectPHI） | 0.0014 | 0.0005 | 0.00025 | | InferICD10CM | 0.0005 | 0.0005 | 0.00025 | | InferRxNorm | 0.00025 | 0.00025 | 0.00025 | | InferSNOMEDCT | 0.0075 | 0.00375 | 0.00075 | 注目すべきは段階割引の効き方の違いです。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リクエストにまとめ、返却されたオフセットで元レコードへ割り戻します。区切り文字を挟むぶんだけ文脈がつながって誤検出が増える場合があるため、まとめる件数は精度を実測しながら決めてください。 ## 通常版Amazon Comprehendと医療版を同じ処理量で比べる手順 「Amazon Comprehend」で調べ始めて医療版に行き着く読者は多く、どちらを使うべきかの判断が曖昧なまま設計に入る例を見ます。両者は名前を共有しているだけで、課金の刻み方も無料枠の条件も別物です。ここでは同じ文書量を両方に通したときの金額を並べます。 ### 100文字1ユニットでも最低課金3ユニットと1ユニットで割れる [通常版Amazon Comprehendの料金ページ](https://aws.amazon.com/comprehend/pricing/)は「NLPリクエストは100文字単位で測定され、1リクエストあたり3ユニット（300文字）の最低課金が発生する」と記載しています。医療版の最低課金は1ユニットなので、刻みが3倍粗いのは通常版のほうです。短文を大量に投げる設計では、この差が実請求に出ます。 単価そのものは逆方向に開きます。通常版の主要NLP APIは1,000万ユニットまで1ユニット0.0001米ドル、医療版のNEReは100万ユニットまで0.01米ドルです。同じ100文字を処理する単価で100倍の差があり、医療エンティティが要らない処理まで医療版に寄せると、請求額だけが跳ねます。 | 比較項目 | Amazon Comprehend | Comprehend Medical | | ------- | ----------------- | ------------------ | | 最低課金 | 3ユニット（300文字） | 1ユニット（100文字） | | 第1段階の単価 | 0.0001米ドル | 0.01米ドル（NERe） | | 無料枠 | 月5万ユニット | 初月8.5万ユニット | | 対応言語 | 日本語を含む多言語 | 英語（US-EN）のみ | | 東京リージョン | あり | なし | ### 無料枠が月50,000ユニットと初月85,000ユニットで違う条件 通常版の無料枠は、キーフレーズ抽出・感情分析・エンティティ認識・言語検出・構文解析を対象に月50,000ユニット（500万文字）です。医療版は初月に85,000ユニットで、翌月からは無料枠がありません。検証期間の設計はこの差から逆算します。 PoCを2か月組むなら、医療版の無料枠が使えるのは1か月目だけという前提で予算を置いてください。2か月目に本番相当の文書量を流すと、いきなり従量課金がそのまま乗ります。検証の順序としては、先に医療版で精度を確かめ、量を伸ばすフェーズを翌月へ送らない組み方が素直です。 ### 東京リージョンで動く本体へ寄せるか医療版を採るかの条件に基づく分岐 分岐は3つの問いで決まります。第1に、出力に医療標準コードが要るか。要らなければ通常版で足ります。第2に、対象文書が英語か。日本語のままなら通常版か、後述のBedrock構成へ寄せます。第3に、データを国外へ出せるか。出せない要件が確定しているなら、医療版は構成そのものが成立しません。 3つとも「医療版が要る」側に振れる案件は、実務では英語の臨床文書を扱う製薬・治験・医療請求の領域に集中します。国内の電子カルテを起点とする案件でこの3条件がそろう例は多くありません。名前が似ているからと医療版を既定にせず、通常版で足りるかを先に潰すのが手順として無駄がない順序です。 ## 入力文字数上限とTPS制限を踏まえた分割処理とリトライの設計 [ガイドラインとクォータのページ](https://docs.aws.amazon.com/comprehend-medical/latest/dev/comprehendmedical-quotas.html)に、同期と非同期で別に定義された上限がまとまっています。上限を超えると`TextSizeLimitExceededException`が返るため、前処理側で分割する設計が前提になります。 ### 20KB上限に対する退院サマリのオフセット維持分割の実装パターン 同期の最大文書サイズは、DetectEntitiesV2・DetectEntities・DetectPHIが20KB、InferICD10CMとInferRxNormが10KB、InferSNOMEDCTが5KBです。DetectEntitiesV2のText引数は「20,000バイト未満」と定義され、最大長は20000で指定されています。UTF-8のバイト数基準なので、英語想定でも記号やアクセント付き文字が混じると想定より早く上限に当たります。 分割で崩れるのはオフセットです。APIは開始位置と終了位置を数値で返すため、分割後のチャンク内オフセットに元文書の先頭位置を加算して復元する処理を必ず持たせます。次の実装は段落境界で切りつつ、各チャンクの先頭位置を保持します。 ``` def split_with_offset(text, limit=19000, sep="\n\n"): """段落境界でUTF-8バイト数を見ながら分割し、(本文, 先頭オフセット) を返す""" chunks, buf, base, pos = [], "", 0, 0 for para in text.split(sep): cand = buf + para + sep too_big = len(cand.encode("utf-8")) > limit if too_big and buf: chunks.append((buf, base)) base = pos buf = para + sep else: buf = cand pos += len(para) + len(sep) if buf: chunks.append((buf, base)) return chunks merged = [] for chunk, base in split_with_offset(long_note): r = client.detect_entities_v2(Text=chunk) for e in r["Entities"]: e["BeginOffset"] += base # 元文書の位置へ戻す e["EndOffset"] += base merged.append(e) ``` AWSは分割用のサンプル`segment.py`をクォータのページから配布していますが、章立ての境界で切らないと否定表現が分断されるため、改行や見出しを優先して切るロジックを足すほうが安全です。「no history of」と病名が別チャンクへ分かれた瞬間に、`NEGATION`の判定が落ちます。 ### InferSNOMEDCTの2TPS制限がボトルネックになる条件 同期の秒間トランザクションは、DetectEntitiesV2・DetectEntities・DetectPHI・InferRxNorm・InferICD10CMが40TPS・40,000CPSに対し、InferSNOMEDCTだけが2TPS・5,000CPSです。5KBの文書を投げると1リクエストで秒間文字数の枠をほぼ使い切ります。 秒間2件では1万文書に80分以上かかります。日次バッチなら許容できても、対話型の画面から同期で叩く設計は成立しません。SNOMED CTが要件なら、非同期ジョブで前処理しておき、画面側は結果を参照するだけにします。なおCPS側のクォータは引き上げ申請ができる一方、InferSNOMEDCTのTPSは一般リファレンスの一覧で調整不可と記載されています。上限緩和で押し切る前提は置かないでください。 ### バッチジョブの70KB・1GB上限と同時実行10本の運用制約 非同期ジョブの制約は次のとおりです。ジョブ設計は、この4つの数値から逆算します。 - 個別ファイルの最大サイズ：70KB（開発者ガイドの記載） - 1ジョブに含められるファイル数：最大500万 - 1ジョブの合計サイズ：1GB - オペレーションごとの同時実行ジョブ数：10 ジョブの開始・停止系は5TPS、一覧・詳細取得系は10TPSです。ポーリング間隔を1秒未満に詰めると、詳細取得側でスロットリングされます。ジョブIDごとに5秒間隔で確認する程度で足ります。加えて、非同期ジョブのファイルパスに連続したスラッシュを使えない仕様があるため、S3キーの組み立てでは区切りの重複を除去してください。 ### 公式2ページで個別ファイル上限が70KBと40KBに割れる扱い ここは2026年9月22日時点で公式の記述が割れています。開発者ガイドのクォータ表は「バッチジョブの個別ファイル最大サイズ：70KB」と書く一方、[一般リファレンスのService Quotas一覧](https://docs.aws.amazon.com/general/latest/gr/comprehend-med%5Fregion.html)は同じ項目を「40キロバイト」とし、InferSNOMEDCTのバッチだけ別枠で「5キロバイト」と定義しています。どちらも調整不可（Adjustable: No）の扱いです。 実装側の落としどころは、厳しいほうの40KB（SNOMED CTは5KB）で分割しておく判断です。70KBで組んでいると、片方の定義が正だった場合にジョブ投入時ではなくファイル単位で弾かれ、原因の切り分けに時間を取られます。検収条件に上限値を書く案件では、どちらのページを根拠にしたかを設計書へ残しておくと、後続の保守で揉めません。 ### 非同期ジョブを起動してS3の出力を受け取るまでの実装用コード例 非同期ジョブはS3の入力プレフィックスと出力プレフィックス、そしてS3へアクセスできるIAMロールのARNを渡して起動します。起動後はジョブIDでポーリングします。 ``` job = client.start_phi_detection_job( InputDataConfig={"S3Bucket": "clinical-notes", "S3Key": "inbox/2026-09"}, OutputDataConfig={"S3Bucket": "clinical-notes", "S3Key": "phi-out"}, DataAccessRoleArn="arn:aws:iam::123456789012:role/ComprehendMedicalS3Access", LanguageCode="en", JobName="phi-nightly-20260922", ) import time while True: d = client.describe_phi_detection_job(JobId=job["JobId"]) st = d["ComprehendMedicalAsyncJobProperties"]["JobStatus"] print(st) if st in ("COMPLETED", "FAILED", "STOPPED", "PARTIAL_SUCCESS"): break time.sleep(5) # 詳細取得系は10TPS。1秒未満で回すとスロットルされる ``` S3キーの末尾にスラッシュを重ねると、連続スラッシュ禁止の仕様に触れます。プレフィックスを変数で組み立てる実装では、連結前に末尾のスラッシュを落とす処理を入れておくと安全です。出力はジョブごとのフォルダへ書かれるため、後続の取り込み処理は`OutputDataConfig`の返り値から実パスを読む形にします。 ## 日本語の診療録をTranslateで英語化する連携構成と精度リスク Comprehend Medicalが検出するのは英語（US-EN）のテキストのみで、文字エンコードはUTF-8です。日本語のカルテをそのまま投げても医療エンティティは返りません。国内案件でこの制約を回すには、前段に翻訳を挟むか、別のモデルへ寄せるかの二択になります。 ### Amazon Translateを前段に置く構成で崩れる用語と対処 紙のカルテやスキャンPDFが起点なら、OCRで文字化したうえで翻訳し、Comprehend Medicalへ渡す3段構成になります。翻訳側の料金と使い方は[Amazon Translateとは？料金・無料枠と使い方（boto3）を解説](https://www.issoh.co.jp/tech/details/3169/)にまとめています。 この構成で崩れるのは、日本固有の薬剤名と用量表記です。先発品名の音訳は成分名に落ちず、InferRxNormのコードが引けません。「1日3回毎食後」のような服用指示も、直訳では`FREQUENCY`属性として拾われにくくなります。対処は前処理での辞書置換です。院内の採用薬マスタを一般名（英語）へ変換する対応表を持ち、翻訳前に置き換えます。翻訳工程を挟む案件では、この辞書整備が工数の中心になると見込んでください。 ### BedrockのLLMとComprehend Medicalを併用するRAG構成 AWSの規範ガイダンスは、Comprehend MedicalとLLMを組み合わせる構成を示しています。抽出はComprehend Medicalが担い、要約や質問応答、カスタムエンティティの追加はBedrock上のモデルが担う分担です。標準コードへの紐付けという決定論的な処理と、文章生成という確率的な処理を分けられるため、監査時に「どの値がどのAPI由来か」を説明できます。 医療分野に特化したモデル提供も動いています。[Claude for Healthcare・Life Sciencesの使い方｜医療コネクタ・HIPAA条件](https://www.issoh.co.jp/tech/details/10585/)で扱った動きのように、LLM側が臨床文書の扱いを強化している状況では、抽出専用APIとの役割分担を設計時点で決めておく価値があります。 ### 日本語のまま処理する場合にComprehend Medicalを選ばない基準 判断は明快です。出力に標準コードが要らず、日本語のまま要約や分類ができればよい案件では、Comprehend Medicalを選びません。翻訳工程の精度検証と辞書保守という固定費が、得られる構造化の価値を上回ります。この場合はBedrock上のモデルへ直接投げ、抽出項目をスキーマで縛るほうが総工数が小さくなります。 逆に、レセプト請求や治験データのように出力コードが決まっている案件では、翻訳工程を含めてもComprehend Medicalが有利です。コード付与の根拠が信頼度スコアとして数値で残るため、人によるレビュー範囲をしきい値で区切れます。 ## 利用可能リージョンとHIPAA適格性から見る医療案件での適否 データの保存場所とコンプライアンス要件は、国内の医療案件で最初に詰める論点です。ここを曖昧にしたまま実装へ進むと、結合テスト後に構成をやり直す事態になります。 ### 東京リージョン非対応が国内の医療案件の設計に与える制約と回避策 AWS一般リファレンスのエンドポイント表（2026年9月22日時点）で`comprehendmedical`が持つリージョンは、バージニア北部、オハイオ、オレゴン、カナダ中部、アイルランド、ロンドン、シドニーの7つです。GovCloud（米国西部）も別途定義され、米国3リージョンとカナダ中部、GovCloudにはFIPSエンドポイントが並記されています。東京と大阪は含まれません。本体のAmazon Comprehendがap-northeast-1で使えるため、同じ感覚で設計すると認証エラーではなくエンドポイント解決の失敗で気付きます。 回避策は3つあります。第1に、解析対象を匿名化してから海外リージョンへ送る構成。第2に、東京リージョンのS3とLambdaで前後処理を組み、API呼び出しだけを海外リージョンへ向ける構成。第3に、リージョン制約を満たすため国内提供の別手段へ替える判断です。第2案が現実的な落としどころですが、通信経路とログの保存先まで含めて説明できる状態にしてから採用してください。こうしたリージョンをまたぐ連携の設計と実装は[API開発・システム連携](https://www.issoh.co.jp/service/system/api/)で請けている領域で、前後処理の置き場所とIAMの切り方まで含めて相談できます。 ### HIPAA適格とデータ非保持が示す外部委託時の説明責任の範囲 Comprehend MedicalはHIPAA適格サービスです。[公式のセキュリティ章](https://docs.aws.amazon.com/comprehend-medical/latest/dev/security.html)のとおり、PHIを含む通信は暗号化が必須で、既定でTLS上のHTTPSが使われます。AWSは「顧客コンテンツを永続的に保存しない」と明記しており、そのためサービス内での保存時暗号化の設定は不要とされています。 ただし公式ガイドは、専門的な医療助言・診断・治療の代替ではないと繰り返し注意しています。信頼度スコアのしきい値をユースケースごとに定め、高い精度が要る場面では高いしきい値を使い、訓練された医療専門家がレビューしたうえで患者ケアに用いるという条件付きです。受託開発では、この条件をそのまま要件定義書と運用手順へ落とし込む作業が発生します。 ### 2026年6月に第7.0版へ改定された安全管理ガイドラインとの関係 厚生労働省の[「医療情報システムの安全管理に関するガイドライン」](https://www.mhlw.go.jp/stf/shingi/0000516275.html)は、2026年6月に第7.0版が公表されました。概説編・経営管理編・企画管理編・システム運用編・保守委託機関編の5編構成です。医療機関側がこの改定に沿って外部委託とクラウド利用の責任分界を見直す局面では、保存場所が国外になる構成の説明資料が求められます。 医療分野のシステム全体でどう位置付けるかは[生成AI開発・AI受託開発](https://www.issoh.co.jp/service/ai/development/)の相談段階で整理するのが早い領域です。エンドポイントの所在、データの流れ、レビュー工程の3点を先に固めれば、要件定義の手戻りを抑えられます。 ## Comprehend Medicalを採用する案件と見送る案件の切り分け ここまでの制約を踏まえ、採否の条件を言い切ります。玉虫色の結論では判断材料になりません。 ### 英語の臨床文書をコード付きで構造化するなら採用してよい3つの条件 次の3条件がそろえば採用します。第1に、対象文書が英語の臨床テキストであること。第2に、出力にICD-10-CM・RxNorm・SNOMED CTのいずれかのコードが要ること。第3に、処理を提供7リージョンのいずれかで完結できること。この3つを満たす案件では、医療用語辞書と否定表現の判定を自前で作る工数を丸ごと削減できます。 AWSが挙げるユースケースは、患者ケース管理、臨床研究、医療請求とレベニューサイクル管理、そしてオントロジーリンクの4領域です。なかでもコンピュータ支援コーディング（CAC）は、人手で滞留した請求コード付与を置き換えるため投資回収の見通しが立てやすい部類です。 ### 日本語カルテの要約が主目的の案件で採用を見送るべき理由と代替 日本語のカルテを要約したい、あるいは日本語で検索できるようにしたいという要件では見送ります。翻訳の前処理で失われる情報が結果の品質を決めてしまい、Comprehend Medical側の精度を評価できなくなるためです。代替はBedrock上のモデルへ日本語のまま投げる構成です。抽出項目をJSONスキーマで縛り、信頼できない項目は空で返させる設計にすれば、実用水準に届きます。 電子カルテそのものの選定や開発判断が論点なら、先に業務要件を固める段階です。[電子カルテとは？種類・機能一覧と比較軸・標準仕様対応の判断を解説【2026年】](https://www.issoh.co.jp/column/details/15243/)で選定軸を確認したうえで、NLPをどの工程に置くかを決めるほうが順序として無理がありません。 ### PHIマスキングをこれ1本に任せて失敗に至る典型的なパターン DetectPHIはHIPAAの18識別子に関連するエンティティを検出しますが、公式は「これらのエンティティはSafe Harbor方式が指定するリストと1対1で対応するものではない」と明記しています。検出漏れがゼロになる保証もありません。信頼度スコアが低い候補を機械的に捨てる実装は、そのまま漏えいリスクになります。しきい値を下げて過検出を許し、人が確認する運用のほうが安全側です。 もう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`と別指定です。 ### Amazon Comprehendのほうが安いと聞きましたが本当ですか？ 単価では本体が大幅に安く、最低課金では医療版のほうが細かい刻みです。本体の主要NLP APIは1,000万ユニットまで1ユニット0.0001米ドル、医療版のNEReは100万ユニットまで0.01米ドルで、同じ100文字あたり100倍の差があります。一方で本体は1リクエスト最低3ユニット（300文字）、医療版は最低1ユニット（100文字）です。短文を大量に投げる設計では本体の最低課金が効くため、実際の請求は文書長の分布を入れて試算してください。 ### Comprehend Medicalは東京リージョンで使えますか？ 使えません。AWS一般リファレンスのエンドポイント表で`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`を保存しておくと差分の追跡が容易です。 ### DetectPHIが返すPHIの種別はいくつありますか？ 公式のDetect PHIページが表で示す種別は9つです。`AGE`、`DATE`、`NAME`、`PHONE_OR_FAX`、`EMAIL`、`ID`、`URL`、`ADDRESS`、`PROFESSION`が並び、それぞれにHIPAAの識別子カテゴリ番号が対応付けられています。日本語の解説では`DATE`と`URL`を落とした7種別で紹介される例があるため、マスキング仕様を起こすときは公式の表を直接確認してください。公式は同時に、これらがSafe Harbor方式のリストと1対1で対応するものではないとも注意しています。 ## 関連記事 - [Amazon Comprehendとは？読み方・できること・料金と日本語で使える機能](https://www.issoh.co.jp/tech/details/3110/)：本体サービスの読み方・日本語対応・料金体系を扱う親記事です。 - [Amazon Textractとは？機能・料金・使い方と他OCRとの違いを解説](https://www.issoh.co.jp/tech/details/3146/)：紙のカルテやスキャンPDFを文字化する前段工程の選定に使えます。 - [Amazon Translateとは？料金・無料枠と使い方（boto3）を解説](https://www.issoh.co.jp/tech/details/3169/)：日本語カルテを英語化する前処理の料金と実装を扱います。 - [電子カルテとは？種類・機能一覧と比較軸・標準仕様対応の判断を解説【2026年】](https://www.issoh.co.jp/column/details/15243/)：解析対象となる電子カルテ側の要件と選定軸を整理しています。 - [医療DXとは？定義・3本柱・2026年度改定から進め方と受託開発の判断まで解説](https://www.issoh.co.jp/column/details/13779/)：医療分野のシステム投資をどの順で進めるかの全体像を扱います。 --- 出典: [Amazon Comprehend Medicalとは？5系統APIと料金・東京リージョン非対応の実装判断【2026年版】]()（株式会社一創）