はじめに

Claude Codeのターミナル画面には、ボックス罫線・進行中スピナー・その場での再描画（in-place redraw）が多用されている。見えている分には情報量が多くて便利だが、これをスクリーンリーダー（VoiceOver・NVDA等）が読み上げようとすると、罫線記号や連続する再描画イベントがノイズとして読み上げられ、会話の流れを追えなくなる。

この課題に対して、Claude Code は2026年7月中旬（v2.1.207〜212、Week 29）に screen reader mode を正式リリースした。ビジュアルなターミナル表現を一切やめ、ラベル付きの平文行だけを順番に出力するモードだ。

有効化方法は3通り用意されている。ただし、Claude Codeを自動化パイプラインで動かしている場合（-p/--print のヘッドレス実行）、このモードは本当に効果があるのか。公式ドキュメントには「ヘッドレスモードは変化しない」と書かれているが、実際にフラグと環境変数の両方を使って確かめてみた。

TL;DR

screen reader modeは --ax-screen-reader フラグ／CLAUDE_AX_SCREEN_READER 環境変数／axScreenReader 設定の3通りで有効化でき、優先順位はフラグ > 環境変数 > 設定
インタラクティブセッションでは罫線・スピナーが消え、you: claude: tool: などのラベル付き平文行に置き換わる。表（テーブル）も Header: value の文に変換される
-p（ヘッドレス）実行では、フラグ・環境変数のどちらを付けても出力内容に変化は無い（実機検証で確認）。これは公式ドキュメントの記述と一致する

screen reader modeが解決する課題

Claude Codeの通常のインタラクティブUIは、パーミッション確認をカーソル選択式のメニューで出したり、進行中のツール呼び出しをスピナーで示したりする。スクリーンリーダー利用者にとっては、こうしたビジュアル要素は次のような問題を引き起こす。

ボックス罫線がそのまま音声化され、内容と区別が付かない
スピナーの再描画がイベントとして次々読み上げられ、実際の応答が埋もれる
パーミッション確認の選択メニューが、矢印キー操作前提でスクリーンリーダーの読み上げカーソルと噛み合わない

screen reader modeはこれらを構造的に置き換える。公式ドキュメント（code.claude.com/docs/en/accessibility）によると、主な変更点は以下の通りだ。

罫線・色だけに依存する合図・変化のない部分の再描画を廃止し、スピナーは静的なテキストとして表示される
会話の各メッセージは you:（自分の発言）・claude:（Claudeの応答）・tool:（ツール実行）・tool error:（失敗したツール）・error:（エラー）・Permission Required:（許可待ち）・Cost:（終了時のコスト集計）というラベルで始まる。ラベルは検索可能なので、ターミナルのスクロールバック内をラベル文字列で検索すれば該当箇所へジャンプできる
表（テーブル）はグリッド表示ではなく Header: value という文の並びとして読み上げ可能な形に変換される（Claude Code v2.1.198以降）
パーミッション確認や選択メニューは、矢印キー選択ではなく「番号を入力してEnter」の形式になる。Yes/No確認も y/n の入力式に変わる
Claudeの応答完了・許可待ち発生・5秒以上かかったツールの完了時にターミナルベルを鳴らし、画面を注視していなくても気付けるようにする

3通りの有効化方法と優先順位

用途に応じて3段階の有効化方法が用意されている。

方法	コマンド／設定	適用範囲
フラグ	`claude --ax-screen-reader`	そのセッションのみ
環境変数	`export CLAUDE_AX_SCREEN_READER=1`（PowerShellは `$env:CLAUDE_AX_SCREEN_READER = "1"`）	そのシェルから起動する全セッション
設定ファイル	ユーザー設定に `"axScreenReader": true` を追加	マシン上の全ターミナル（VS Code統合ターミナル含む）

優先順位は フラグ > 環境変数 > 設定 で、CLAUDE_AX_SCREEN_READER=0 を明示すれば設定が true でも無効化できる。有効化されると、セッション開始時に [Screen Reader Mode: on via flag] のように、どの方法で有効化されたかを示す確認行が最初に出力される（v2.1.206以降のフォーマット）。

なお本モードはv2.1.181以降が必須で、それより前のバージョンでは --ax-screen-reader フラグ自体が error: unknown option '--ax-screen-reader' として拒否される。

実機検証: `-p`（ヘッドレス）実行では何が変わるか

ここまでの内容は公式ドキュメントに基づく説明だが、実際にCLIを操作してみないと本当にそう動くかは分からない。手元の環境（Claude Code v2.1.211）で、-p（非対話・ヘッドレス実行）に対して3パターンを試した。

まず、フラグなしの通常実行。

$ echo "test file" > readme.txt
$ claude -p "readme.txtの中身を1行で教えて" --max-turns 3
readme.txtの中身は1行で、内容は「test file」です。

次に --ax-screen-reader フラグを付けて同じプロンプトを実行する。

$ claude -p "readme.txtの中身を1行で教えて" --max-turns 3 --ax-screen-reader
readme.txtの中身は「test file」の1行です。

さらに CLAUDE_AX_SCREEN_READER=1 を環境変数で指定して、別のプロンプトを実行する。

$ CLAUDE_AX_SCREEN_READER=1 claude -p "1+1は？数字だけ答えて" --max-turns 2
2

いずれの実行でも、インタラクティブモードで見られるはずの [Screen Reader Mode: on via flag] や [Screen Reader Mode: on via env] という確認行は一切出力されなかった。you: claude: といったラベル行も付かず、素のテキスト応答が返るだけだった。つまり -p 実行では、screen reader modeを有効化する3つの方法のどれを使っても、出力に検出可能な変化が生じない。

これは公式ドキュメントの一文と正確に一致する。

Screen reader mode doesn't change non-interactive mode with the -p flag. Non-interactive mode already writes plain text and remains an alternative for scripting.

つまり -p は元から「screen reader mode相当」の平文出力をデフォルトで行っている設計であり、screen reader modeはインタラクティブUI（罫線・スピナー・メニュー）を持つ対話セッション専用の機能ということになる。

著者視点の発見ポイント

screen reader modeの機能自体はアクセシビリティ向けだが、検証を通じて実務上の副次的な発見があった。自動化パイプライン（CI/CD・スケジュール実行・サブエージェント委譲）で claude -p を使う場合、アクセシビリティ設定を気にする必要が構造的に無いという点だ。CLAUDE_AX_SCREEN_READER を環境変数として誤って設定してしまっていても、ヘッドレス実行のスクリプトには一切影響しない。逆に言えば、CI環境で「読み上げ用のラベル行が混ざって出力のパースに失敗する」といった事故も起きない設計になっている。

これは -p の出力契約（プレーンテキストであることの保証）がscreen reader modeより上位の不変条件として扱われていることを意味する。CLIツールの新機能を追加する際、既存の「スクリプト向け出力モード」を機能追加の影響範囲から明示的に除外する設計は、後方互換性を壊さずに新機能を載せる一つの型として参考になる。

まとめ

Claude Codeのscreen reader modeは、罫線・スピナー・矢印キーメニューという通常のインタラクティブUIを、ラベル付き平文とテキスト選択メニューに置き換えるアクセシビリティ機能だ。フラグ・環境変数・設定の3通りで有効化でき、優先順位はフラグが最も強い。

一方で -p によるヘッドレス実行には効果が及ばない。これは実装漏れではなく、「-p は元々スクリプト向けの平文出力である」という既存の設計を screen reader mode がそのまま尊重した結果であることを、実際にフラグと環境変数の両方で確認できた。Claude Codeを対話的に使っていて音声読み上げに難を感じている場合は、まず claude --ax-screen-reader を1セッションだけ試すところから始めるとよい。

参考