スクリーンリーダーモードは、拡大鏡やハイコントラストテーマといった一般的なアクセシビリティ機能と同じ設定なのか?
同じ設定ではない。スクリーンリーダーモード(--ax-screen-readerフラグまたは対応する設定でオンにする)は、「端末の視覚的な表示方法が、スクリーンリーダーで読み上げられない、あるいはフリーズしてしまう」という特定の問題に対処するものであり、画面のレンダリングロジック全体を線形のテキスト出力に切り替えることで機能する。拡大鏡、動きの軽減、色覚異常に配慮したテーマといったニーズは、それぞれ別の設定項目に対応している(CLAUDE_CODE_ACCESSIBILITY、prefersReducedMotion、テーマ設定)。これらの設定は、表示自体が視覚的にレンダリングされるかどうかを変えるものではなく、その視覚的表示の細部を調整するだけだ。
つまり、もしニーズが拡大表示や動きの軽減であれば、スクリーンリーダーモードを有効にする必要はなく、そうすべきでもない——それはまったく異なる状況(表示自体がスクリーンリーダーに優しくないこと)のために設計されたものだ。これらは1つのアクセシビリティ総合スイッチの下にあるサブオプションではなく、並行して存在する独立した設定カテゴリーだ。
なぜ特に「進行状況のアニメーション、その場での再描画」といった視覚効果を変更するのか、スクリーンリーダー側に端末画面をどう読み解くか自分で工夫させるのではだめなのか?
問題は、スクリーンリーダーのもともとの設計ロジックが、端末の動的な再描画の方式と本質的に矛盾している点にある。スクリーンリーダーは「画面の内容が順序どおり、安定的に変化する」ことを前提としており、一行を読み終えたら次の行に移る。しかし進行状況のアニメーションやその場での再描画といった効果は、同じ画面領域が高速に、繰り返し上書き更新されるものだ。スクリーンリーダーにとって、この変化パターンは「今どの行を読むべきか」「この内容は新しいものなのか、それとも同じものの繰り返しの更新なのか」を判断するのが非常に難しい。実務上その結果として現れるのが、コミュニティで報告されていたような、スクリーンリーダーが奇妙な文字を読み上げたり、完全にフリーズして応答しなくなったりする現象だ。
スクリーンリーダー側にこの本質的に不安定な表示更新パターンに自力で適応させようとするよりも、端末側で出力方法を直接変える(平易で線形の、一行ずつ印刷するテキストに切り替える)方が、より直接的な解決策だ。つまり問題は出力の源で解決されるのであって、受け取る側(スクリーンリーダー)に、もともとそのために設計されていない表示フォーマットを無理やり処理させるのではない。
もしスクリーンリーダーモードをオンにした結果、以前使い慣れていたある視覚的な機能(バックグラウンドセッションのアタッチなど)が正常に動作しなくなった場合、それは設定を間違えたということなのか?
必ずしも設定ミスとは限らない——公式ドキュメントには明確に「既知の制限」という項目が挙げられており、スクリーンリーダーモードはほとんどの中核機能(完全な会話、ツール権限の承認、出力の確認)をカバーしているものの、元の視覚的インターフェースのすべての機能に一対一で対応しているわけではないことを意味している。バックグラウンドセッションのアタッチは、まさにドキュメントがこのモードではまだ完全にはサポートされていないと明記している項目の一つだ。
より実践的なやり方は、まずある機能がスクリーンリーダーモード下で制限を受けている可能性があると想定し、問題に遭遇したら公式ドキュメントの「既知の制限」セクションを確認し、それが既知の、まだ解決されていないケースに該当するかを確かめることだ。自分が設定を間違えたと思い込んで同じ設定を何度もやり直すのではなく。このモード自体も継続的に調整が進められており、既知の制限の範囲は今後縮小していく可能性があるが、現段階では元の視覚的インターフェースの機能と完全に同等だと仮定すべきではない。
自分は画面を見ることができるが、チームに視覚障害のある同僚がいてClaude Codeを使っている場合、この設定が正しく有効になっているかをどう確認すればよいか?
最も直接的な確認方法は、端末起動時に印刷される確認メッセージを見ることだ——スクリーンリーダーモードが有効になると、起動時に、それがフラグ、環境変数、あるいは設定ファイルのどれによって有効化されたかを明確に示す一行が表示される(古いバージョンでは代わりに「Accessible screen reader mode: on」のようなメッセージが表示される)。この行自体は平易なテキスト形式なので、自分の目で画面を見るだけで確認でき、モードが実際に有効になっているかを判断するためにスクリーンリーダーを自分で操作する必要はない。
もし側面からセットアップを手伝いたい場合、妥当な順序は次の通りだ。まず相手のClaude Codeのバージョンが2.1.181以降かを確認する(バージョン確認コマンドを実行してもらうか、起動時に印刷されるバージョン番号を見る)。次に、相手の利用頻度に応じてどの有効化方法が適しているかを決める。もし相手がほとんど同じマシンで作業しているなら、設定ファイルのaxScreenReader: trueが通常最も手間がかからない——起動のたびにフラグを追加したり、環境変数が正しく読み込まれているか心配したりする必要がない。
Claude Codeのもともとの端末インターフェースは、スクリーンリーダーのユーザーにとって使いやすいものではなかった——ボックス、進行状況のアニメーション、その場での再描画といった視覚効果は、スクリーンリーダーではうまく読み上げられないことが多く、フリーズしたり完全に応答しなくなったりすることさえあった。この問題はコミュニティで明確に報告されていた。NVDAユーザーは、ストリーミング出力や進捗インジケーターの更新時に端末が頻繁にフリーズし、使い続けるためにスクリーンリーダーや端末自体を何度も再起動しなければならなかったと報告している。Claude Codeが後に追加したスクリーンリーダーモードは、まさにこの問題のために設計された。この記事では、実際にどう有効化・無効化するのか、そして有効化した後に挙動が具体的にどう変わるのかをまとめる。
有効化すると、Claude Codeはもともとの視覚的な端末インターフェースを、平易で線形なテキスト出力に切り替える——もはやボックス、進行状況のアニメーション、その場での再描画はなく、代わりにラベル付きの平易なテキストが一行ずつ順に印刷され、VoiceOver、NVDAといったスクリーンリーダーが正しい順序で読み上げられるようになる。このモードをオンにしても、完全な会話を続けたり、ツール使用の権限を承認したり、出力を最初から最後まで確認したりすることは引き続きでき、インターフェースを切り替えたからといって機能が失われることはない。
今回のセッションだけで使いたい場合は、起動コマンドの後に--ax-screen-readerフラグを追加する。あるシェルから起動するすべてのセッションでデフォルトで有効にしたい場合は、環境変数CLAUDE_AX_SCREEN_READERを1に設定し(BashやZshではexport CLAUDE_AX_SCREEN_READER=1、PowerShellでは$env:CLAUDE_AX_SCREEN_READER = "1"を実行)、その行をシェルの設定ファイルに追加すれば、開くすべてのシェルをカバーできる。このマシン上のすべてのセッションでデフォルトで有効にしたい場合は、ユーザー設定ファイルに"axScreenReader": trueを追加する——この設定はVS Code内蔵ターミナルにも適用される。この機能はClaude Code 2.1.181以降が必要であり、それより古いバージョンでは「不明なオプション」というエラーがそのまま返ってくるため、まず自分のバージョンが要件を満たしているか確認する価値がある。
Claudeの返信で以前はボックス描画文字で描かれていた表は、スクリーンリーダーが苦手とするボックスグリッドの代わりに、「項目名:値」という形式で一文ずつ読み上げられるようになる。Claude Codeは印刷したすべての内容を端末のスクロールバック履歴に残すため、スクリーンリーダーのレビューコマンドや端末自体の検索機能を使って、以前の会話内容を遡って読み直せる。このモードは端末インターフェース自体のみを調整するものであり、VS Code拡張機能のチャットパネルを通じてClaude Codeを使っている場合は、別途このモードを有効にする必要はない。また、スクリーンリーダーモードでは元のtui設定は無視される。既知の制限に記載されているバックグラウンドセッションのアタッチ機能を除けば、画面は基本的にフルスクリーンの再描画ではなく、スクロールするテキストとして表示される。
スクリーンリーダーモードでは、Claude Codeはスクリーンリーダーが追いつけるよう、2つの箇所で意図的に一時停止する。1つは確認メッセージを印刷した後で、次のプロンプトを表示する前に3秒間待機し、スクリーンリーダーがその行を読み終える機会を与える。任意のキーを押せばこの待機を早く終わらせることもできる。デフォルトの待機時間が長すぎる、あるいは短すぎると感じる場合は、環境変数CLAUDE_AX_STARTUP_QUIET_MSを使って長さを調整できる。つまりこのモードは単に表示をテキストに切り替えるだけでなく、そのタイミングまでもがスクリーンリーダーの実際の読み上げ速度に合わせて調整されているということだ。
普段スクリーン拡大鏡を使っている、動きを減らす必要がある、あるいは色覚異常に配慮したテーマが必要な場合、スクリーンリーダーモードを有効にする必要はない——こうした状況にはそれぞれ対応する設定がある(CLAUDE_CODE_ACCESSIBILITY、prefersReducedMotion、あるいはテーマ設定などを通じて調整する)。スクリーンリーダーモード自体は「端末の表示そのものが効果的に読み上げられない」という特定の状況のために設計されたものであり、あらゆる視覚的アクセシビリティのニーズをカバーする万能スイッチではない。