はじめに
NVDA 日本語版と、関連するアプリやサービスの開発を続けています。
KCトーカー2 + SK-Chat AI については前回の記事で紹介しました。
2026年6月26日の「NVDA日本語チームチャリティートーク」では Nuime Desktop を紹介しました。
現在は NVDA 日本語版と日本語点訳エンジンを（相互に依存する）別々のプロジェクトに再構築して、それぞれの分野の開発コミュニティの支援や活性化を目指す取り組みを進めています。
この作業の途中で GitHub のメンションを確認していたら、見落としていた記事に気づきました（私はときどき NV Access の issue からメンションされて、必要な場合には返信や調査をしています）。
その内容が、実は先日のチャリティートークですこし話題になった「画面レビュー」に関連するものだったので、すこし詳しく書いてみることにしました。
画面レビューとは
画面レビュー（Screen Review）は、NVDAの3つのレビューモードの1つで、NVDA+テンキー7（および NVDA+テンキー1）で切り替えます。
GDI（レガシーなWindows描画API）を使うアプリにおいて、画面上に表示されたテキストを、アプリのアクセシビリティ対応状況に関わらず読み上げたりコピーしたりできます。
技術的仕組み
NVDAはアプリのプロセスにDLLを注入し、GDI（Graphics Device Interface） のテキスト描画関数（ExtTextOutW/A、TextOutW/A、BeginPaint、BitBltなど）をMicrosoft Detoursライブラリでフックします。描画されるテキスト・位置・フォント・色を横取りし、ディスプレイモデルと呼ばれる仮想的なテキストバッファをメモリ上に構築します。画面レビューはこのバッファを参照します。
JAWSはかつてカーネルモードの仮想ビデオドライバで画面テキストを横取りしていました。NVDAは登場したときからユーザーモードのAPIフックでより安全・軽量な実装を採用していました。
歴史
画面レビューは元々Flat Review（フラットレビュー） と呼ばれ、NVDA 2013.2で現在の3モード（オブジェクト/ドキュメント/画面）に再編されました。
上記の Issue#3484 はその直後に報告されたタミル語の文字化け問題で、「Flat Reviewでは正しく読めていたがScreen Reviewで読めなくなった」という回帰バグです。
技術的課題
グリフ→文字の逆変換の限界
GDIフックで取得できるのは描画後のグリフインデックスであり、元の文字コードに戻すにはフォントのcmapテーブルを逆引きする必要があります。この方式では以下が正しく扱えません：
- 合字（リガチャ）: 複数の文字が1つのグリフに結合されるケース（fi → f+i）で情報が失われる
- OpenType文脈依存字形: アラビア語の語頭/語中/語末形など
- IVS（異体字セレクタ）: 日本の漢字の異体字
- 複雑な文字結合: タミル語の子音+記号の結合など
日本語特有の問題
- 縦書きテキスト: GDIの
ExtTextOutはフォントのescapementで縦書きを表現するため、文字の物理的な並び順は横書きと同じ。画面レビューは縦方向のレイアウトを認識できず、文字が横に並んで読めてしまう - IME変換候補: 多くの日本語IMEは独自描画やDirectWriteを使用するため、変換候補が画面レビューで読めない
- 複雑なフォント合成: 全角/半角混在やフォントリンク環境での文字化け
制限と将来
- モダンなアプリでは使えない: WPF、Direct2D/DirectWrite、WebベースのアプリはGDIを使わないためテキストを取得できません
- Windows Storeアプリ: プロセス注入がブロックされるため機能しません
非推奨化の経緯
2026年4月、seanbudd氏がIssue#3484を「Not planned」としてクローズし、「GDI/画面スクレイピングは非推奨技術であり、再設計はリスクが大きい。今後、画面レビューの実装/設計変更はサポートしない」と表明しました。これに対しCyrilleB79氏が#20024「Advertise screen review deprecation」を起票し、「非推奨なら公式に文書化すべき」と主張しています。
代替の方向性
アクセシビリティAPI（UI AutomationやIAccessible）が適切に実装されたアプリでは、オブジェクトレビューやドキュメントレビューを使う方が信頼性が高く、画面レビューはそれらのフォールバックです。将来的な代替として、Windows OCR APIの活用や、特定アプリ向けのアドオンによる補完などが考えられますが、NVDA本体での実装は未定です。
PDFアクセシビリティとの類似
この問題を考えると、PDFアクセシビリティとの構造的な類似に気づかされます。
PDFは「印刷して紙で読む」ためのページ記述形式であり、画面上のグリフ配置情報は持っていても、見出し・段落・本文といった論理構造はタグ付けがなければ失われます。
タグ付きPDFは、視覚表現の後付けとして構造情報を追加する試みですが、一つのファイルに2つの異なる情報体系（コンテンツストリームとタグツリー）を共存させるため、両者の同期が常に問題になります。タグを修正しても見た目が変わらない、あるいは見た目を微調整したらタグ構造が壊れる。これは日常的に起こります。
画面レビューもまったく同じ構造を持っています。GDIは「画面に正しく表示する」ために設計されたAPIであり、そこからテキスト情報を後付けで取得している。PDFのコンテンツストリームとタグツリーの関係は、GDIの描画命令とディスプレイモデルの関係にそっくりです。
どちらも「アクセシビリティを考慮せずに作られた視覚表現」を後からアクセシブルにしようとする苦肉の策であり、その限界は構造的に避けられません。
これに対する本質的な解決策は、最初からアクセシビリティを前提に設計された形式（born-accessible） だけがもたらします。
HTMLがその典型で、マークアップ自体が意味構造を持ち、CSSで見た目を調整します。一つの情報源から視覚表現とアクセシビリティ表現の両方を生成できる。アプリの世界ではUI Automationがこれに相当し、コントロールの種類・状態・値・名前を標準化された方法で公開します。
画面レビューもタグ付きPDFも、「ないよりはまし」な改善策ではあっても、born-accessibleな形式にかなうものではありません。
そして、その過渡期の苦しさ、レガシーな技術に依存せざるを得ない環境と、新しい標準への移行が進む環境のギャップは、アクセシビリティ技術全体に共通するテーマです。