ひとことで言うと
渡されたテキストそのものを解析して、実体・キーフレーズ・感情・言語・PII を返す NLP API です。事前学習モデルなので学習データは不要で、DetectPiiEntities のようにリクエスト単位で呼べます。分類と実体認識だけは自前データでカスタムモデルを作れます。
要するに、文章に対する検問所です。倉庫（S3）を巡回して危ないものが置いてないか調べる警備員（Macie）とは仕事が違います。Comprehend はいま通ろうとしている1通のテキストを、その場で開けて中身を言う。だから GenAI のパイプラインでは、プロンプトが FM に入る前と、応答がユーザーに出る前のゲートの位置に置かれます。
なぜ生まれたか
テキストから「人名・地名・金額・感情」を取り出すのは NLP の定番タスクですが、自前でやると学習データの用意とモデル保守が丸ごと乗ってきます。公式の言い方では、Comprehend は「テキスト解析の専門知識がなくてもシンプルな API で自然言語処理を使えるようにする」ものです。事前学習モデルは AWS 側が継続的に学習させるので、利用者は精度維持の運用を持ちません。
もう1つの流れが PII です。個人情報が「どこに・何文字目から何文字目まで」入っているかは、正規表現では住所や氏名に届きません。Comprehend は PII を専用の実体型（NAME / ADDRESS / SSN / CREDIT_DEBIT_NUMBER / AWS_SECRET_KEY など）として持ち、オフセット付きで返す形にしました。これが AIP-C01 の D3 で名指しされている理由です。
| 何が不便だったか | Comprehend の答え |
|---|---|
| NLP タスクごとに学習データとモデル保守が要る | 事前学習モデルを API で呼ぶだけ（学習データ不要） |
| 自社カテゴリへの分類は既製モデルでは無理 | Comprehend Custom（AutoML でカスタム分類・カスタム実体認識） |
| カスタムモデルの版を作り続ける運用が重い | フライホイール（学習・評価の版管理をオーケストレーション） |
| 個人情報の位置を正規表現で当てられない | PII 実体型をオフセット・スコア付きで返す |
| S3 の文書を読む側に PII を見せたくない | S3 Object Lambda アクセスポイント（GET の応答をリダクト／アクセス制御） |
何に使うか
| 用途 | 使い方 | 関連する試験ドメイン |
|---|---|---|
| プロンプト・応答の PII 検出 | DetectPiiEntities（位置を返す）／ContainsPiiEntities（含むかどうかだけ） | D3 |
| PII のリダクション | 非同期バッチジョブ。伏字にした入力テキストのコピーが返る | D3 |
| S3 から読む時点でのリダクション | S3 Object Lambda アクセスポイント＋ComprehendPiiRedactionS3ObjectLambda | D3 |
| PII を含む文書へのアクセス制御 | 同アクセスポイント＋ComprehendPiiAccessControlS3ObjectLambda（ContainsPiiEntities を使う） | D3 |
| 実体抽出（メタデータ生成） | DetectEntities。RAG のチャンクに付けるメタデータの供給元 | D1 |
| 意図・感情の判定で分岐する | DetectSentiment / DetectTargetedSentiment を Step Functions の分岐条件に使う | D1 |
| 言語判定してモデル・プロンプトを振り分ける | DetectDominantLanguage | D1 |
| 自社カテゴリへの分類 | カスタム分類モデル＋エンドポイント（リアルタイム時） | D1 |
| 文書群のトピック整理 | トピックモデリング（ドキュメントクラスタリング） | D1 |
試験でどう問われるか
Comprehend が単独の主役になるのは PII のときだけ、と割り切って構いません。それ以外は「Bedrock に投げる前の前処理」「多層防御の1層目」として選択肢に並びます。逆に PII のシナリオでは、Macie との取り違えを狙った問題が定番です。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| PII の検出は Comprehend か Macie か | 対象がアプリを流れるテキスト（プロンプト・チャット履歴・API のペイロード）→ Comprehend | Macie。Macie は S3 のバケット／オブジェクトを走査する側で、リクエスト経路には立てない |
| 「S3 に溜まった文書に個人情報が無いか棚卸ししたい」 | 対象がS3 に保存済みのオブジェクト、成果物が検出結果（findings） → Macie | Comprehend で全オブジェクトをループさせる案（棚卸しの道具ではない） |
| 「PII を含むかどうかだけ判定して弾きたい」 | 位置が要らず含有の有無で足りる → ContainsPiiEntities | DetectPiiEntities（動くが、必要のないオフセットまで取っている。アクセス制御の Lambda が使うのは前者） |
| 「PII を伏字にしたテキストを得たい」 | リダクションは非同期バッチジョブが必要 | 「リアルタイム分析でリダクトする」。リアルタイムでできるのは位置の特定まで |
| 多層防御の構成を選ばせる | 入力を Comprehend で前処理 → Bedrock → Lambda で後処理 → API Gateway、の層構造 | Guardrails だけで PII 要件を満たすと書いた選択肢（層が1つしかない） |
| 「S3 から読む人に応じて PII を隠したい」 | 取得経路そのものを変える → S3 Object Lambda アクセスポイント | バケットポリシー／KMS で暗号化（アクセスの可否は変わるが、中身の伏字にはならない） |
| 会話から意図を取り出して分岐 | 意図認識・実体抽出の前処理として Comprehend | Amazon Lex（ボットの対話管理まで抱える。前処理だけが欲しい構成では過剰） |
| RAG のチャンクにメタデータを付けたい | DetectEntities で抽出した実体をメタデータに入れる | 埋め込みモデルの次元を上げる案（メタデータフィルタの話に答えていない） |
1問拾える境目: PII 検出の対応言語は英語とスペイン語だけです（公式は「英語またはスペイン語のテキスト文書」と明記）。「日本語のチャットログから PII を検出する」というシナリオで Comprehend を素直に選ぶと外れます。言語ごとの対応範囲は機能によって違い、言語判定（Dominant language）だけは対応言語が広いという非対称も覚えておくと迷いません。
実務でどう使うか
- カスタムモデルをリアルタイムで使うにはエンドポイントが要ります。 事前学習モデル（実体・感情・PII）は API を呼ぶだけですが、カスタム分類・カスタム実体認識のリアルタイム推論はエンドポイントの作成が前提です。公式は「リアルタイムのカスタム分類の費用は、設定したスループットとエンドポイントが有効だった時間の両方に基づく」と明記しています。使っていなくても立っている限り課金されるので、オートスケーリングを設定するか削除します
- リアルタイム分析の入力は 100 KB まで（UTF-8）。長文書はチャンクに割るか非同期ジョブに回します
- リダクションの出力は入力テキストのコピーです。元テキストを消すと、伏字前の情報はどこにも残りません。監査で原本が要るなら別に保持する設計にします
- 入力形式は原則 UTF-8 テキストですが、カスタム分類とカスタム実体認識だけは画像・PDF・Word ファイルも受けます。ここだけ例外なので、「PDF を Comprehend に直接渡せるか」は機能ごとに答えが変わります
- Comprehend はモデル改善のためにコンテンツを保存することがあると公式に書かれています。機密データを扱う設計では、この一文の存在自体が設計レビューの論点になります
- 出力とストレージボリュームは自分の KMS キーで暗号化できます
「PII 検出＝安全」ではありません。返るのはスコア付きの推定で、確実な検出ではありません。リダクションを法的な非識別化の根拠にできるかは別問題で、Comprehend の PII をコンプライアンス上の de-identification として扱う設計はレビューで落ちます。試験でも実務でも、Comprehend は層の1枚であって最後の砦ではない、という置き方をします。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon Macie | Macie は S3 のデータ資産を走査して findings を出す（保管の話）。Comprehend は渡されたテキストをその場で解析する（経路の話）。「S3 のバケットを」と書いてあれば Macie、「プロンプトを」「チャットを」なら Comprehend |
| Amazon Bedrock Guardrails | Guardrails は Bedrock の呼び出しに組み込む検閲層で、有害表現・トピック遮断・PII まで面倒を見る。Comprehend はBedrock の外に置ける汎用のテキスト解析。多層防御の設問では両方が別々の層として並ぶ |
| Amazon Lex | Lex は意図認識に加えて対話の状態管理とスロット充填まで持つボットの器。意図・実体だけ取りたいなら Comprehend |
| Amazon Kendra | Kendra は検索（質問に対して文書を返す）。Comprehend は解析（テキストの属性を返す）。方向が違う |
| Amazon Comprehend Medical | 医療テキスト専用の別サービス。AIP-C01 の In-Scope 表に並ぶのは Comprehend 側 |
| Amazon Transcribe の PII リダクション | Transcribe は音声から起こした転写に対してリダクトする。すでにテキストなら Comprehend、音声からならまず Transcribe |
想起チェック
Q1. シナリオに「PII」が出てきました。Comprehend と Macie のどちらかを、何を見て決めますか。
検査対象が「保管されている S3 のオブジェクト」か「経路を流れるテキスト」かで決めます。前者は Macie（バケットを走査して findings を出す）、後者は Comprehend（リクエスト単位で解析する）。GenAI のプロンプト・応答は必ず後者です。
Q2. 「PII を伏字にしたテキストが欲しい」。リアルタイム分析で足りますか。
足りません。リダクションは非同期バッチジョブが必要です。リアルタイム分析でできるのは PII エンティティの位置とタイプの特定までです。
Q3. `DetectPiiEntities` と `ContainsPiiEntities` を使い分ける基準は？
オフセットが要るかどうかです。伏字や部分マスクのように位置を使うなら DetectPiiEntities、「PII を含む文書へのアクセスを止める」のように可否だけ決めるなら ContainsPiiEntities。S3 Object Lambda のアクセス制御関数は後者を使います。
Q4. Comprehend で「立てっぱなしだと課金され続ける」のはどの構成ですか。
カスタムモデルのリアルタイム推論用エンドポイントです。設定したスループットとエンドポイントが有効だった時間で課金されます。事前学習モデルの API 呼び出し（実体・感情・PII）にはエンドポイントが要らず、この課金も発生しません。