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

Claudeは縦書き・ルビをどう処理しているか

Claudeの公式ドキュメントには「縦書き」や「ルビ(振り仮名)」を専用にサポートするという記載はありません。PDFや画像として文書をアップロードした場合、Claudeはページを1枚の画像として視覚的に処理し、通常の画像理解と同じ仕組みで文字を読み取ります。つまり縦書き・ルビへの対応は、専用機能としてではなく、汎用的な視覚解析能力の延長として実現されています。

この前提を確かめるため、縦書きにルビを振った日本語の短文画像を作成し、実際にClaudeに読み取らせて検証しました。

縦書き文書は日本語特有のレイアウトであり、英語圏を主な検証対象とする視覚解析モデルの一般的な評価データには含まれにくい種類の入力です。公式の制限事項リストにも縦書きという言葉自体は登場しません。だからこそ、実際に読ませて確認する意味があります。

検証方法

実在する古典籍や商用のスキャン文書をそのまま使うと、フォントの癖・紙の劣化・OCRレイヤーの有無など複数の要因が結果に絡み、どこが縦書き・ルビ由来の難しさなのかを切り分けにくくなります。そこで今回は、要因を絞り込むために次の条件で自作のテスト画像を用意しました。

• 24文字の短い縦書き文章(「霧雨が降る、蔵前の下町で、彼女は静かに佇んでいた。」)
• 5か所の漢字・漢字二字熟語にルビ(振り仮名)を付与
• 一般的な日本語ゴシック体フォントで、スキャンノイズの無いクリーンな描画

この画像をClaudeに渡し、「この画像の文章をそのまま書き起こしてください」という指示だけを与えて結果を確認しました。

正しく読み取れた範囲

書き起こし結果は元の文章と一致しました。確認できたポイントは次のとおりです。

• 縦書きの読み順: 右の列から左の列へ、各列は上から下へ読むという伝統的な順序を、追加の指示なしに正しく認識した
• ルビの分離: 「霧雨(きりあめ)」「蔵前(くらまえ)」のようなルビを、本文の文字とは別の付随情報として扱い、書き起こし本文にルビの読みを混入させることはなかった
• 句読点混じりの列の処理: 「、」「。」を含む列でも文字送りが崩れず、区切りとして正しく認識した

漢字の熟語(「下町」「静か」など)とその読みが1対1で対応しない場合(送り仮名を含む語)でも、ルビの範囲を本文の対応する文字数に正しく合わせて認識できていました。

苦手な範囲・注意が必要な点

今回の検証はクリーンな描画画像であり、実際の書籍スキャンや古い文書とは条件が異なります。Claudeの視覚解析全般に関する公式の制限事項として、次の点が明記されています。

• 200ピクセルを下回るような小さい画像や、低画質・回転した画像では判読を誤る(hallucinate)ことがある
• 座標やレイアウトの位置特定は近似値であり、厳密な数値としては扱えない
• 画像から抽出した数量(文字数・項目数など)は正確とは限らない

縦書き文書に置き換えると、次のような場面でこれらの制限が影響しやすいと考えられます。

• 振り仮名が本文の文字に対して極端に小さく書かれ、200ピクセル相当を下回る解像度でスキャンされた場合
• 崩し字・草書体など、現代の標準的なフォントと字形が大きく異なる場合
• 複数段組みが混在し、読み順の判断自体が人間にとっても曖昧な紙面構成の場合

PDFとしてアップロードする場合も、Claudeは各ページを画像として処理する仕組みのため、同じ視覚解析の制限がそのまま当てはまります。ページ数やリクエストサイズの上限、ページあたりの処理方法はClaudeのPDF読み込み・画像解析の使い方とアップロード上限で扱っています。

PDFはテキスト層と画像の両方が渡される

今回の検証は画像ファイルを直接読ませたケースですが、PDFとしてアップロードした場合はもう一段仕組みが複雑になります。公式ドキュメントによると、Claudeへ送られたPDFはまずページごとに画像へ変換され、同時に各ページのテキストがシステム側で抽出されて、画像とテキストの両方がセットでClaudeに渡されます。Claudeは最終的にテキストと画像の両方を参照して回答します。

この2系統構成は縦書き文書にとって見落としやすい注意点です。画像側の読み取りは今回の検証で確認したとおり、縦書きの読み順を正しく扱えます。一方でテキスト抽出の系統は、PDF内部の文字コード配列順に依存する一般的なPDFテキスト抽出の性質上、縦書きレイアウトの視覚的な読み順とは異なる順序でテキストが並ぶ可能性があります。抽出されたテキストの語順が画像から読み取れる語順とずれている場合、Claudeがどちらの情報を優先して解釈するかは文書ごとの内容次第で変わり得ます。縦書きのPDFで書き起こし結果に違和感がある場合は、テキスト層が原因になっていないかを疑う価値があります。

解像度の自動縮小がルビの可読性に影響する仕組み

Claudeの視覚解析は画像を28×28ピクセルのパッチ単位で処理し、解像度が一定の上限を超える画像は処理前に自動で縮小されます。上限は解像度ティアによって異なり、標準ティアでは長辺1568ピクセル、Claude 4.7以降の高解像度ティアでは長辺2576ピクセルが上限です。上限を超えた画像は、縦横比を保ったまま上限に収まる最大サイズへ縮小されます。

この仕組みは縦書き文書のルビにとって無視できない要因です。スキャン解像度そのものが高くても、画像が長辺の上限を超えていれば自動的に縮小され、もともと小さいルビの文字は縮小後にさらに小さくなります。前述の「200ピクセルを下回ると誤読が増える」という制限は個々の文字サイズの話ですが、ページ全体を1枚の画像として送る場合、縮小後のページの中でルビが実質何ピクセル相当になるかは、元の解像度とページ内の文字密度の両方に左右されます。ルビを含む縦書き文書を扱う場合は、ページ単位で画像を送るのではなく、ルビの判読が必要な範囲を切り出して個別に送るほうが縮小の影響を抑えられます。

縦書き対応は「仕様」ではなく「能力の副産物」

今回の検証結果を踏まえると、Claudeが縦書き・ルビを読み取れるのは、日本語の縦書き専用に設計された機能があるからではなく、視覚モデルが学習した一般的な文字認識能力がたまたま縦書きのレイアウトにも対応できている、と捉えるのが実態に近いと言えます。公式ドキュメントが縦書きを明記していない以上、この挙動は将来のモデル更新で改善も後退もあり得る前提で運用したほうが安全です。

得意・不得意の見分け方という観点では、Claude画像解析でできることで扱っている一般的な判断基準がそのまま当てはまります。縦書き文書を業務で扱う場合は、重要な数値や固有名詞を含む箇所だけ書き起こし結果を目視で照合する運用が現実的です。

スキャン文書の画質が悪く文字を検出できないケースでは、Citations機能の引用元特定自体が失敗することもあります。この失敗パターンはClaudeのCitationsでスキャンPDFを引用できない理由で扱っている内容と同根で、根本原因はどちらも視覚解析の入力品質に行き着きます。

業務で縦書き文書を扱うときの実践的な進め方

縦書き文書をClaudeに読ませる業務フローを組むなら、まず対象文書の性質を切り分けるところから始めるのが安全です。現代のフォントで組まれたクリーンなPDF(電子書籍・現代の縦書き印刷物)であれば、今回の検証結果に近い精度が期待できます。一方でスキャンした古い文書・崩し字混じりの資料・複雑な段組みが混在する紙面は、公式が明記する視覚解析の限界に触れやすく、書き起こし結果の全件を人手で確認する前提に切り替えたほうが安全です。

判読が重要な固有名詞・数値・日付が含まれる箇所については、書き起こし結果とルビの読みを別々に確認する2段階のチェックを組み込むと、誤読を見落としにくくなります。ルビが本文の読み間違いを補正する手がかりになる場面もあるため、ルビ情報を書き起こし結果と一緒に保持しておく運用が実務的です。

ページ数の多い文書を一括で処理する場合は、ページごとの書き起こし精度にばらつきが出やすい点も踏まえておく必要があります。全ページを均一に信頼するのではなく、フォントや紙面構成が変わるページ(見出しページ、図版が多いページなど)を事前に洗い出し、そこだけ重点的に確認する運用のほうが、限られたレビュー工数を有効に使えます。書き起こし結果に対する信頼度は文書の種類ごとに一様ではなく、業務での利用実績を社内で記録として蓄積していくことが、次に似た文書を扱うときの判断材料になります。

まとめ

Claudeは縦書きにルビを振った日本語文書を、専用機能としてではなく汎用的な視覚解析能力の応用として処理しています。今回のクリーンなテスト画像では、読み順の把握とルビの分離のどちらも正確でした。一方で、小さい文字・低画質・崩し字といった条件が重なる実文書では、公式が明記する視覚解析の一般的な制限(小さい画像での誤読、位置特定の近似性)がそのまま影響します。PDFとして扱う場合は画像とテキスト抽出の2系統が併走する構造にも注意が必要です。業務利用では、書き起こし結果を鵜呑みにせず、重要箇所だけ目視で照合する運用を組み合わせるのが安全です。