Amazon Bedrock Managed Knowledge Base に画像ベースの日本語 PDF を取り込んでパース精度を検証してみた
こんにちは！AI 事業本部のこーすけです。
2026 年 6 月 17 日に、フルマネージドな RAG サービス Amazon Bedrock Managed Knowledge Base が一般提供（GA）されました。前回の記事では、テキストレイヤーのない画像ベースの PDF（星取り表・システム構成図）を FM パーサーが Markdown やテキスト記述に変換してくれることを確認しました。
Managed Knowledge Base では、パーサーの選択自体が Managed parser という自動パース機能に置き換わっています。そこで今回は、前回と同じ画像ベースの PDF と質問セットを使って、Managed Knowledge Base のパーシングでの画像、図表の取り込み精度を検証してみました。
前提知識
Amazon Bedrock Managed Knowledge Base とは
ベクトルデータベースやデータ取り込みパイプラインの管理を AWS に任せられる、フルマネージドな RAG サービスです。従来の Knowledge Bases（本記事では「Custom KB」と呼びます）との違いを整理するとこうなります。
| 項目 | Custom KB（従来） | Managed KB |
|---|---|---|
| ベクトルストア | ユーザーが構築・管理（OpenSearch Serverless 等） | AWS 管理（ユーザーからは見えない） |
| データソース | S3 等 | S3 / SharePoint / Confluence / Google Drive / OneDrive / Web Crawler の 6 コネクタ |
| パース | デフォルトパーサー or FM パーサーを選択 | Managed parser（既定・自動選択） |
| 埋め込み・リランク | ユーザーが選択 | サービス管理（カスタム指定も可） |
Managed parser とは
Managed KB のデータ取り込みで既定になっているパース戦略です。コンソールの注釈には「The Bedrock service will parse your content with an optimal strategy.（Bedrock サービスが最適な戦略でコンテンツをパースします）」とあり、対応データと出力が次のように示されています。
パース対象のデータ（Data parsed）:
- テキスト文書（Word、Excel、html、markdown、.txt、.csv など）
- 画像
- 構造化・整形されたテキスト文書
- 表
- ビジュアル要素の多い文書（Visually rich documents）
- 音声
- 動画
パーサーの出力（Parser output）:
- 抽出されたテキスト
- 画像・ビジュアル・図・チャートの説明文
- 音声・動画の文字起こし
従来の FM パーサーでやっていた図表のテキスト化を、サービス側が自動で判断してやってくれるイメージかと思います。
なおチャンキングについては、Default / Fixed-size / No chunking の 3 択から選べる設定項目が残っています（階層・セマンティックチャンキングはコンソールからは確認できませんでした）。
また、AWS の発表ブログではこの自動パースの仕組みを「Smart Parsing」と呼んでいます。
参考ドキュメント:
検証内容
前回の FM パーサー検証と同じ条件を Managed KB に適用します。
サンプルデータ
-
星取り表 PDF（hoshitori.pdf） — 製品プランごとの機能対応表（◯ / △ / × の表）
-
システム構成図 PDF（architecture.pdf） — AWS サービスのアイコンと矢印で構成されたアーキテクチャ図
評価用の質問セット
それぞれの資料の読み取りを試す質問セットを用意しました。
hoshitori.pdf についての質問
- 「機能『外部共有』はスタンダードプランで使えますか」
- 「プロプランでしか使えない機能をすべて挙げてください」
- 「○ が一番多いプランはどれですか」
architecture.pdf についての質問
- 「Web サーバーはどのデータベースに接続していますか」
- 「構成図に登場する AWS サービスをすべて挙げてください」
- 「シングル AZ 構成になっているコンポーネントはありますか」
手順
ステップ 1: サンプル資料を S3 へ配置
今回の検証用の S3 バケットを作成し、上記の PDF を格納します。
ステップ 2: Managed Knowledge Base の作成
コンソールから作成します。Amazon Bedrock AgentCore > Knowledge Base から、「Create Managed Knowledge Base」を選択します。
埋め込みモデルも「Managed embeddings model」と「Bedrock embeddings model」が選択できるようになっています。今回は使いなじみのある「Titan Text Embeddings V2」を選択しました。
データソースには先ほど用意した S3 バケットを指定します。
つづいて、パーサーの設定とチャンキング戦略を設定します。
パーサーは先述の通り「Managed parser」となります。
また、チャンキング戦略の設定は、埋め込みモデルを「Bedrock embeddings model」にした場合のみ変更ができるようです。今回はデフォルトのままにしました。
自分でチャンキングを工夫したい場合は、埋め込みモデルの選択時に「Bedrock embeddings model」を選ぶ必要がある点に注意してください。
ここまで設定したら「ナレッジベースの作成」を押下すれば、投入したデータのパース、エンベディングを行ってくれます。
データソースの追加が完了した後、同期を実行すれば早速使えるようになります。
参考ドキュメント:
ステップ 3: 検証スクリプトの作成
Retrieve API でチャンクの中身（Managed parser のパース結果）を確認します。
前回の記事のように OpenSearch Serverless のインデックスを直接覗くことができなくなっているためです。
クエリを実行し、取得されるスコア上位のチャンクを表示することで間接的に確認します。
import boto3
client = boto3.client("bedrock-agent-runtime", region_name="ap-northeast-1")
KB_ID = "XXXXXXXXXX" # 作成した Managed KB の ID
QUESTIONS = [
"機能『外部共有』はスタンダードプランで使えますか",
"プロプランでしか使えない機能をすべて挙げてください",
"○ が一番多いプランはどれですか",
"Web サーバーはどのデータベースに接続していますか",
"構成図に登場する AWS サービスをすべて挙げてください",
"シングル AZ 構成になっているコンポーネントはありますか"
]
# Retrieve でパース結果（チャンク）を確認
for q in QUESTIONS:
print(f"########## クエリ: {q} ##########")
res = client.retrieve(
knowledgeBaseId=KB_ID,
retrievalQuery={"text": q},
retrievalConfiguration={"managedSearchConfiguration": {"numberOfResults": 10}},
)
for i, result in enumerate(res["retrievalResults"], 1):
print(f"=== チャンク {i}（score: {result.get('score')}）===")
print(result["content"]["text"])
検証結果
取り込み結果の確認
スクリプトを実行しチャンクの中身を確認したところ、Managed parser による日本語 PDF のパース品質はあまり高くないと感じました。
構成図（architecture.pdf）は、内容は拾えているが品質が粗いという印象です。<analysis> タグ付きの説明文チャンク（image_type / caption / extraction / relationships / description という構造）が生成されており、コンポーネント一覧や接続関係（ユーザー → ALB → ECS → Redis / RDS / S3）、図中の注記の内容自体は概ね正確に抽出されていました。
ただし、チャンクとしての品質には課題が目立ちました。
- 説明文が英語で生成される — 日本語の資料なのに説明文はほぼ英語で、「ユーザー/ブラウザ (User/Browser)」のような日英併記が混在します。日本語で質問する RAG のインデックスとしてはミスマッチと思われます。
- 同じ説明文の重複断片が大量にチャンク化 — 上位 10 件の大半が同一説明文の切れ端で、チャンク分割も
<analysis>の構造を無視して文の途中でぶつ切りになっています。 - 崩れた生テキストチャンクが混在 — 判読不能なチャンクも、そのままインデックスに入っています
確認されたチャンクの例を 3 つ示します。
例 1: FM による説明文チャンク — 図の内容は正確に拾えていますが、日本語資料に対して英語ベース・日英併記の出力になっています。
<analysis> <image_type> Technical Diagram / Data Flow and Process Flow Diagram (中略) <title> AWS Cloud
Architecture Diagram - Web Application Infrastructure with VPC </title> (中略) <extraction>
**Main Components:** - ユーザー/ブラウザ (User/Browser) - shown in yellow/gold box on the left
- HTTPS protocol/connection - ALB (Application Load Balancer) - labeled as "Application Load Balancer"
- Web アプリ (Web Application) - Amazon ECS (Fargate / マルチAZ) - shown in blue box
- キャッシュ (Cache) - Amazon ElastiCache (Redis) - shown in green box (後略)
例 2: 文の途中から始まる重複断片チャンク — 例 1 と同じ説明文の切れ端が、Files) - という文の途中からぶつ切りでチャンク化されています。こうした断片が検索上位を埋めていました。
Files) - Amazon S3 - shown in purple box - VPC boundary indicated by dashed lines with CIDR notation
(10.0.0.0/16) **Data Flow Labels:** - HTTPS (from User/Browser to ALB)
- セッション情報 (Session Information - from ALB to Cache) - SQL (from Web Application to Database) (後略)
例 3: 崩れた生テキストチャンク — 図のレイアウトをそのまま読んだと思われる判読不能なテキストも、1 つのチャンクとしてインデックスされています。
VPC (10.0.0.0/16) 1-+ HTTPS ALB Web P711 Amazon ECS Application Load Balancer (Fargate / VLFAZ) I SQL
[SIGNATURE] DB 1711 Amazon ElastiCache Amazon RDS Amazon S3 (Redis) (PostgreSQL / RDS AZ AZ )
ECS 92312 2 DO AZ 1 S3 11 DB
星取り表（hoshitori.pdf）のパース精度はさらに悪く、全く元の表から情報を抽出できませんでした。返ってきたチャンクは次のような崩れたテキストのみでした。
Example Notes 1
(2026#7 / )
>')- 7°0
- [ ] [ ] [ ]
11 [ ] [ ] [ ]
[X] [ ] [ ]
1751 [X] [ ] [ ]
...
SSO() [X] [X] [ ]
日本語のプラン名・機能名がほぼ読み取れておらず、表は [ ] / [X] の羅列に崩れています。構成図では生成されていた説明文チャンクに相当するものは、3 クエリ × 上位 10 件のどこにも現れませんでした。
その結果、星取り表を狙った 3 つの質問すべてで、関係のない構成図のチャンクが検索上位を独占し、肝心の表はほぼヒットしないという状態になっていました。
ナレッジベースのテストを実行する
最後に先ほどの質問に答えられるかを確認します。
「ナレッジベースのテスト」を実行し、先ほど用意した質問文をテストしていきます。
結果は Retrieve でのチャンクの確認からわかる通りですが、パースが崩れていた星取り表に関する質問（1〜3）にはまともに答えられず、説明文チャンクが生成されていた構成図に関する質問（4〜6）には概ね回答できています。
考察
今回の結果を整理すると、Managed parser には日本語資料に対して次の品質課題があると言えます。
- 図の説明文が英語で生成され、日英混在のチャンクになる（内容の抽出自体はできている）
- 日本語の表は OCR 段階で崩れ、根拠情報がインデックスから失われる
- 重複断片や判読不能な生テキストチャンクがノイズとして混ざる
前回の FM パーサーでは、パースに使うモデルとプロンプトを自分で選べたため、日本語の表も Markdown として正確に取り込めていました。Managed parser では現状はその制御ができていないように見えます。
終わりに
本記事では、GA されたばかりの Amazon Bedrock Managed Knowledge Base に画像ベースの日本語 PDF を取り込み、Managed parser のパース品質を検証しました。
ベクトルストアの管理が不要・数クリックで RAG が立ち上がるという手軽さは、確かに魅力的ですが、日本語の図表資料に対しては、説明文が英語で生成される、表の読み取りが崩れるなど、パースを自分で制御できていた前回の FM パーサー（Custom KB）に及ばない結果となりました。
パース品質をユーザー側でチューニングできないマネージドサービスだからこそ、採用前に自分たちの実資料を取り込んで、Retrieve でチャンクの中身まで確認することをおすすめします。
現時点で日本語の図表資料が主体のユースケースでは、Custom KB + FM パーサーの構成が引き続き有力だと思います。とはいえ GA 直後のサービスなので、日本語読み取りの精度やパース品質は今後の改善に期待したいです。
同じように Managed Knowledge Base の採用を検討している方の参考になれば嬉しいです。最後まで読んでいただきありがとうございました！
