Claude Media
Claudeは縦書き・ルビを含む日本語文書をどう解析するか

Claudeは縦書き・ルビを含む日本語文書をどう解析するか

縦書きとルビ付きの日本語文書は、ページの縮小規則とPDFのテキスト層で読み取りやすさが変わります。A4スキャンでルビが何ピクセルになるかを計算します。

縦書きとルビは専用機能ではなく画像入力として読まれる

画像解析とPDFのドキュメントに、縦書きやルビを扱う専用の項目はありません。画像として渡した文書は通常の視覚入力として読まれます。PDFはページごとに画像へ変換され、抽出されたテキストが画像と並べて渡されます。縦書きの読み順やルビの切り分けは、この汎用の仕組みの上で決まります。

そのため精度を左右するのは、日本語組版の知識より先に入力の作り方です。ルビが縮小でつぶれていないか。PDFのテキスト層が紙面の読み順と食い違っていないか。縦書き文書で最初に効くのは、この2点です。

A4スキャンのルビは縮小でどこまで小さくなるか

Claudeは画像を28×28ピクセルのパッチに分け、パッチ1枚を1視覚トークンと数えます。画像は「長辺の上限」と「視覚トークン数の上限」の両方に収まる最大サイズまで縮小されます。上限は標準ティアが長辺1568ピクセル・1568トークン、Claude 4.7以降の高解像度ティアが長辺2576ピクセル・4784トークンです。

長辺だけを見ていると見落とします。A4を130dpiで読んだ1075×1520ピクセルは、どちらの辺も1568以下です。それでもトークン数は39×55=2145で上限を超えるため、標準ティアでは924×1307に縮小されます。この例は座標ガイドに載っています。同じスキャンは、高解像度ティアなら縮小されず、1075×1520のまま読まれます。2145トークンが上限の4784に収まるためです。

この規則を縦書きの紙面に当てはめて計算します。前提は、A4を300dpi(2480×3508ピクセル)で読み、本文10.5pt、ルビは本文の半分の5.25ptで組んだ紙面です。ルビは元画像で約22ピクセルの大きさになります。

数字

約22ピクセルのルビが縮小後に何ピクセルになるか

  • 標準ティア・1ページ丸ごと

    約8px

    2480×3508 → 924×1307(倍率0.37)

  • 高解像度ティア・1ページ丸ごと

    約14px

    2480×3508 → 1623×2296(倍率0.65)

  • 標準ティア・紙面を4分割

    約16px

    1240×1754 → 924×1307(倍率0.75)

  • 高解像度ティア・紙面を4分割

    約22px

    1240×1754のまま縮小なし

縮小規則(参考実装)で算出。ルビを本文の半分とした仮定の計算です

標準ティアで1ページ丸ごと渡すと、ルビは8ピクセル前後まで小さくなります。本文の文字も、43.75ピクセルが約16ピクセルになります。

スキャン解像度を上げても、この差は縮まりません。600dpiで読んだA4は、標準ティアで300dpiと同じ924×1307に縮小されます。高解像度ティアでも、300dpiと600dpiはどちらも1623×2296です。解像度を上げて意味があるのは、上限に届くまでの範囲だけです。

効くのは切り出しです。ただし枚数が増えた分、視覚トークンも増えます。標準ティアで紙面を4分割すると、1枚1551トークンが4枚で約6200トークンになり、丸ごと渡す場合の4倍です。高解像度ティアでは1枚2835トークンの4枚で約1万1千トークンになり、丸ごとの4756トークンの約2.4倍です。公式も、高解像度ティアは同じ画像で最大3倍ほど視覚トークンを使うと書いています。

制限事項にある「200ピクセル未満の画像」は、画像全体の大きさの話です。文字の大きさの目安ではありません。ルビの判読は、縮小後の画像で文字が何ピクセルになるかで考えます。標準ティアでも、1000×1000ピクセルの切り出しなら縮小されず、1296トークンで読まれます。ルビを元の大きさのまま読ませたいときの目安になります。

縦書きPDFでは画像とテキスト層が別々に届く

PDFで渡す場合は、もう1段仕組みが増えます。ページごとの画像と、ページごとに抽出されたテキストが、セットでClaudeに渡されます。

くらべる

PDFで届く2つの情報

縮小規則がかかる

ページ画像

縦書きの列の並びとルビの位置は、画像から読み取ります。上で計算した縮小は、PDFでもページ単位の画像にそのまま当たります。

PDFの文字データ

抽出テキスト

PDFに埋め込まれた文字データが元になります。文字データは組版ソフトの出力順に並んでいることがあり、縦書きの紙面の読み順と一致するとは限りません。

2つの情報がずれたときにClaudeがどちらを重く見るかは、PDFのドキュメントに書かれていません。縦書きのPDFで書き起こしの語順に違和感が出たら、テキスト層が原因になっていないかを疑う価値があります。同じページを画像1枚で渡した結果と見比べると、原因を切り分けられます。

PDFのトークンは、ページごとのテキスト(1ページあたり1,500〜3,000トークンが目安)に、画像のトークンが加わります。ページ数やリクエストサイズの上限はClaudeのPDF読み込み・画像解析の使い方とアップロード上限で扱っています。

PDFに指示を書くときは、紙面に印刷されたページ番号ではなく、PDFビューアーが表示するページ番号を使います。PDFのガイドがそう勧めています。表紙や見返しがある本のPDFは、印刷されたページ番号とビューアー上の番号がずれることがあります。

字が小さく密度の高い文庫本のようなPDFは、ページ数の上限に届く前にコンテキストウィンドウを使い切ることがあります。ガイドには、そうした文書をセクションに分けて渡す対処が載っています。

テキスト層のないスキャンPDFでは、文字を検出できずに引用元の特定が失敗することがあります。この失敗はClaudeのCitationsでスキャンPDFを引用できない理由と同じ根にあり、どちらも視覚解析の入力品質に行き着きます。

Bedrockでは引用を有効にしないと画像側が使われない

Amazon BedrockのConverse APIでPDFを渡す場合は、処理モードが2つに分かれます。Opus 4.6以前のClaude on Amazon Bedrockの話で、引用(Citations)を有効にしたときだけ、ページを画像とテキストの両方で読む視覚解析が働きます。

引用を有効にしないと、Converse APIはテキスト抽出だけに切り替わります。このモードでは、PDF内の画像やレイアウトは解析されません。3ページのPDFで、テキスト抽出のみが約1,000トークン、視覚解析が約7,000トークンという目安です。

縦書きの文書では、この差が結果に直結します。テキスト抽出だけのモードでは、前の節で見たテキスト層の語順がそのまま答えの材料になり、ルビの位置や列の並びを画像から読み直す経路がありません。PDF内の図やレイアウトが答えに反映されないときは、引用の有効化を確かめます。引用なしで視覚解析を使いたい場合の選択肢は、InvokeModel APIです。

縦書き文書を渡す前の下ごしらえ

画像とPDFのガイドにある注意点を、縦書きの文書に当てはめると次の順になります。

手順

縦書き文書を読ませる前の4手順

  1. 1

    ページを正しい向きに直す

    回転した画像では誤りが増えます。PDFのガイドも、ページを正しい向きに回転するよう勧めています。縦書きの本を横向きのまま撮ったスキャンは、先に起こします。

  2. 2

    ルビを読ませたい範囲だけ切り出す

    縮小の計算のとおり、ルビの判読が必要な範囲を切り出すほど、縮小の影響を避けられます。本文だけでよいページは丸ごと渡します。

  3. 3

    画像やPDFを先に、指示を後に置く

    画像やPDFをテキストの前に置く構成が推奨されています。

  4. 4

    読み順とルビの扱いを指示に書く

    読み順もルビの出力形式も、依頼文で指定できます。次のコードブロックは、利用者が書く指定の一例です。

右の列から左の列へ、各列は上から下へ読んで書き起こしてください。
ルビは本文に混ぜず、「霧雨【きりあめ】」のように直後の【】に分けて書いてください。

切り出すときは、境界の取り方にも注意が要ります。画像のガイドは、文字を大きくするためだけに重要な文脈を切り落とさないよう注意しています。縦書きなら、ルビがかかる親文字や、列の前後を切らない位置で分けます。列の途中で切ると、次の画像との読み順の継ぎ目が曖昧になりやすくなります。

画像を圧縮するときも注意が要ります。JPEGなど非可逆形式の強い圧縮では、テキストが読みにくくなります。細いルビの線は、その影響を受けやすい部分です。

切り出した画像が増えたときの上限と持ち方

縦書きの書籍を4分割で渡すと、10ページで40枚になります。画像の枚数にも上限があります。APIでは、200kトークンのコンテキストのモデルで1リクエスト100枚、そのほかのモデルで600枚までです。claude.aiでは1メッセージ20枚までです。

もう1つ見落としやすいのが、20枚を超えたときの寸法制限です。1リクエストに20枚を超える画像を入れると、全部の画像にさらに厳しい寸法の上限がかかり、超えた画像は invalid_request_error で拒否されます。どちらの辺も2000ピクセル以内に収めるか、20枚以下に抑えれば避けられます。先ほどの4分割は1240×1754なので収まりますが、2分割の2480×1754は2000ピクセルを超えます。

複数の画像を渡すときは、Image 1: のような短いラベルを各画像の前に付けると、依頼文や次のターンで「1枚目の右端の列」のように指せます。

書き起こしの条件を変えて何度も試すときは、Filesで画像を一度だけアップロードして file_id で参照する方法もあります。base64の画像は会話の履歴ごと毎ターン送り直されるため、やり取りが長くなるほどリクエストが大きくなります。

画像解析の制限事項を縦書きに当てはめる

画像解析の制限事項のうち、縦書き文書の作業に効くのは次の3点です。

  • 低画質・回転・極小の画像では、誤読や作り話(hallucination)が起きることがあります。ルビ付きの古い資料や、画質の落ちたコピーが典型です
  • 座標や位置の出力は近似値です。ルビがどの文字にかかるかを座標で返させる使い方は、近似になります
  • 数え上げは不正確になりえます。「ルビが何か所あるか」を数えさせる検証は、書き起こしの正しさの証拠になりません

PDFのガイドは、標準的なフォントと読みやすい文字を勧めています。崩し字や旧字体の資料のように、その条件から外れる紙面では、書き起こしを全件照合する前提にしたほうが安全です。一般的な画像解析の得意不得意はClaude画像解析でできることで扱っています。

業務で使う前に自分の文書で測る

縦書きとルビの精度は、文書の種類ごとに変わります。導入前に、実際の文書から数ページを選んで、条件を変えながら書き起こさせると、どこで崩れるかが分かります。見る条件は次の3つです。

  • 同じ紙面を、丸ごと渡した場合と切り出して渡した場合
  • 同じ文書を、画像で渡した場合とPDFで渡した場合
  • 現代のフォントのページと、見出しや図版の多いページ

照合は本文とルビを別々に行います。固有名詞・数値・日付は、書き起こしとルビの読みを2回に分けて見ると、誤読を見落としにくくなります。ルビが本文の読み違いに気づく手がかりになる場面もあるので、ルビは捨てずに書き起こしと一緒に残します。

ページ数の多い文書では、ページごとに精度がばらつきます。フォントや紙面構成が変わるページを先に洗い出し、そこを重点的に確認する運用が現実的です。モデルが入れ替わるとティアも変わりうるため、同じサンプルで回し直せる形にしておくと、更新のたびの再測定が楽になります。

まとめ

縦書きのルビ付き文書は、画像として渡す場合もPDFの場合も、縮小後にルビが何ピクセル残るかで結果が分かれます。1ページ丸ごとではなく、ルビを読みたい範囲を切り出して渡し、PDFでは抽出テキストの語順も疑う、という順で試すと原因を切り分けられます。

この記事を共有:XはてブLinkedIn