スクリーンリーダーモード、実機検証してみた
Claude Codeに2026-07-14に追加されたスクリーンリーダーモードを、二次情報だけで終わらせずサンドボックスで実行。--printでは効果が見えず、対話UIでのみ意味を持つという実測結果をまとめた。
この記事の結論: Claude Code v2.1.208で正式opt-in化された「スクリーンリーダーモード」は、--print（非対話・ワンショット）実行では効果が体感できず、対話UIの装飾レンダリング部分にのみ効くことを実機検証で確認した。有効化は--ax-screen-reader・CLAUDE_AX_SCREEN_READER=1・settings.jsonのaxScreenReaderの3経路で、設定変更だけで有効化できる（追加のインストール等は不要）。
リナ社長（高校生社長のやり手ギャル）× タクヤ（入社3年目）— 今回は、Claude Codeについ先日追加されたばかりのスクリーンリーダーモードを、実際にサンドボックスでフラグを立てて動かしてみた回。（登場人物について）
「拍子抜けした」から始まった検証
「つい先日出たスクリーンリーダーモード、実際にフラグ立てて動かしてみたんですけど、正直拍子抜けしたというか……」とタクヤが切り出す。「--printで同じプロンプト投げても、出力の見た目がほとんど変わらなくて」
「え、それ機能してなくない？」とリナ社長。「うちのブログの自動投稿パイプライン、記事投稿も全部Claude Codeのエージェントで回してるじゃん。そこに影響ある話なら見過ごせないんだけど」
「いえ、機能自体はちゃんとあります。ただ検証の仕方が悪かったというか……順を追って説明しますね」
何が入ったのか
GitHubリリースノートとcode.claude.com/docs/en/changelogの記述を突き合わせたところ、両者は完全に一致していた。時系列を整理するとこうなる。
| バージョン | 公開日 | 内容 |
|---|---|---|
| v2.1.200 | 2026-07-03 | 装飾グリフを非表示化、トランスクリプト記号を短いラベルとして読み上げ、ネストしたテーブルをHeader: value.形式の行に変換。加えて/mcpサーバー一覧がスクリーンリーダー・拡大鏡でフォーカスを追えなかった不具合を修正 |
| v2.1.208 | 2026-07-14（つい先日） | 正式にopt-inの「スクリーンリーダーモード」として体系化。claude --ax-screen-reader実行、CLAUDE_AX_SCREEN_READER=1設定、またはsettings.jsonに"axScreenReader": trueを追加のいずれかで有効化 |
| v2.1.209 | — | 記事執筆時点の最新版 |
「なるほど、v2.1.200の時点で下地は入ってたんですね」とタクヤ。「装飾グリフを消す、テーブルを平文に変換する、みたいな個別の改善が先にあって、v2.1.208でそれをopt-inモードとしてまとめた、という積み上げなんですね」
「へー、地味だけどちゃんと段階踏んでるじゃん」とリナ社長。
サンドボックスで実際に動かした
一次ソースの言い換えだけで終わらせず、実際にサンドボックスでコマンドを叩いた。まずフラグが実在するかどうかの確認から。
$ claude --version
2.1.209 (Claude Code)
$ claude --help | grep -A2 screen
--ax-screen-reader Render screen-reader friendly output
(flat text, no decorative borders or
animations).フラグは確かに存在する。次に、--print（非対話モード）で同じプロンプトを実行し、フラグの有無で出力がどう変わるかをdiffで確認した。
$ claude --print "このプロジェクトの主要ディレクトリを3つ挙げて、それぞれ1行で説明して" > normal.txt
$ claude --ax-screen-reader --print "（同じプロンプト）" > ax.txt
$ diff normal.txt ax.txt
1c1
< Astroプロジェクト構成を確認しました。主要ディレクトリ3つ:
---
> 主要ディレクトリ3つは以下の通りです。
3,5c3,5
< - **`src/content/blog/`** — ブログ記事本体（Markdown/MDX）を格納。投稿ルールは同ディレクトリのCLAUDE.mdで管理
< - **`src/pages/`** — Astroのルーティング対象ページ。新規ページ作成ルールが専用CLAUDE.mdで定義されている
< - **`docs/`** — AdSense審査対策チェックリストなど、サイト運用上のルールドキュメントを格納
---
> - `src/` — サイト本体のソースコード（ブログ記事 `content/blog/` やページ `pages/` など）
> - `docs/` — AdSense審査対策など運用ルールのドキュメント置き場
> - `public/` — ビルド時にそのまま配信される静的アセット一見するとフラグによる差があるように見える。「これ、ちゃんと効いてるってことですよね」と最初はタクヤも思ったという。だが念のため、フラグなしのまま同じプロンプトをもう一度実行してみた。
$ claude --print "（同じプロンプト、フラグ無しで再実行）" > normal2.txt
$ diff normal.txt normal2.txt
1c1
< Astroプロジェクト構成を確認しました。主要ディレクトリ3つ:
---
> 主要ディレクトリ3つ:
3,5c3,5
< - **`src/content/blog/`** — ブログ記事本体（Markdown/MDX）を格納。投稿ルールは同ディレクトリのCLAUDE.mdで管理
< - **`src/pages/`** — Astroのルーティング対象ページ。新規ページ作成ルールが専用CLAUDE.mdで定義されている
< - **`docs/`** — AdSense審査対策チェックリストなど、サイト運用上のルールドキュメントを格納
---
> - **`src/content/`** — ブログ記事のコンテンツ（Markdown等）を格納。専用のCLAUDE.md（執筆・投稿ルール）あり。
> - **`src/pages/`** — Astroのページルーティング定義。新規ページ作成ルールのCLAUDE.mdあり。
> - **`docs/`** — AdSense審査対策チェックリストなど、共通ドキュメントを格納。フラグをまったく触らずに同じプロンプトをもう一度実行しただけでも、フラグあり/なしの比較と同程度の差が出た。つまり最初のdiffは、スクリーンリーダーモードの効果ではなく、LLM応答のゆらぎに過ぎなかった。
「これで分かったのが、--printの非対話・ワンショット実行だと、フラグの効果は普通の応答揺れと区別がつかないってことなんです」とタクヤ。「拍子抜けしたのは、検証の場所を間違えていただけでした」
対話モードでは何が起きているのか
では、このモードは実際どこに効いているのか。scriptコマンドでpty（擬似端末）ごと記録しながら、claudeを対話モードで起動してみた。すると初回セットアップ画面（テーマ選択など）が表示される数秒間だけで、138個のANSIエスケープシーケンスが記録された。カーソル位置を指定する^[[2G、文字色を指定する^[[39mといった制御コードが並ぶ。
$ script -qc "claude" normal_raw.log
（対話モードの初回セットアップ画面を数秒表示させた後に終了）
$ grep -o $'\x1b' normal_raw.log | wc -l
138
$ cat -v normal_raw.log | grep -o '\^\[\[[0-9;]*[A-Za-z]' | sort | uniq -c | sort -rn | head -8
16 ^[[39m
11 ^[[2G
10 ^[[37m
8 ^[[38;5;231m
7 ^[[7G
7 ^[[4G
7 ^[[12G
5 ^[[17G（生ログの抜粋。カーソル位置指定や色指定のエスケープシーケンスが数秒のうちに大量に発生していることが分かる）
^[[2G^[[37m Syntax^[[10Gtheme:^[[17GMonokai^[[25GExtended^[[34G(ctrl+t^[[42Gto^[[45Gdisable)^[[39mこれは対話モードのUIが、カーソル制御や色指定を多用した装飾的な描画を行っていることを示す実測値だ。スクリーンリーダーモードが「非対話では効果が見えず、対話UIの装飾レンダリング部分にのみ効く」という設計になっている裏付けとして読める。
正直に書いておくと、初回セットアップ画面が間に挟まる関係で、--ax-screen-readerを有効にした状態の対話画面とのエスケープシーケンス数を直接比較するところまでは、このセッションでは安全に自動化できず断念した。そこまで踏み込めなかった点は限界として残る。
「地味な機能」か「コスト0の前進」か
「正直、地味な機能だと思うんですよね」とタクヤは最初の評価を口にする。「非対話では効果が見えないし、対話UIの装飾を消すだけの機能なので、うちの自動投稿パイプラインみたいに--print中心で動かしてる用途にはほぼ関係ない気がします」
「いや、それは見方が違うくない？」とリナ社長が食い下がる。「視覚障害あるメンバーがいる開発チームだと、Claude Codeを採用するかどうかの判断材料になるじゃん。しかもこれ、バージョンアップだけで手に入るんだよ。うちの自動投稿パイプラインの基盤がバージョンアップするだけで、追加の契約や導入作業なしで機能が増えてる。調達とかチーム導入の判断材料としては地味どころかデカいと思うけど」
タクヤはここで実機検証の結果を踏まえて考え直す。「そこは……確かにそうですね。効果が対話UI限定だとしても、実際にスクリーンリーダーを使う人がClaude Codeを対話的に操作する場面では意味があります。私が『地味』と思ったのは、自分たちの--print中心の使い方というフィルターがかかっていただけで、機能自体の価値を過小評価していたかもしれません」
「でしょ？」とリナ社長。「で、それウチらの何が変わるの？って話だけど、今のところパイプライン自体には影響ない。でも『アクセシビリティ対応済み』って言えるツールを基盤に使ってるのは、外に説明するときの安心材料にはなるじゃん」
「そこは同意します。あと今回、個人的な収穫は機能そのものより検証方法のほうにありました。非対話と対話でモードの効果がまったく違う場合がある、というのは、他のCLIツールを検証するときにも使える視点だと思います」
二人の評価はこうして、最初の温度差から一致点に落ち着いた。地味に見えるかどうかは検証する場所次第であり、コスト・調達面での実利は確かに存在する、というのが最終的な着地だ。
まとめ
Claude Codeのスクリーンリーダーモードは、v2.1.200での地ならし（装飾グリフ非表示・テーブルの平文化・/mcp一覧のフォーカス修正）を経て、v2.1.208で--ax-screen-reader・環境変数・settings.jsonの3経路によるopt-in機能として正式に体系化された。実機検証の結果、--printの非対話実行では効果が体感できず、対話UIの装飾レンダリング（カーソル制御・色指定）にのみ効く機能であることが分かった。
持ち帰り: 視覚障害のあるメンバーがいる開発チームでClaude Codeの採用を検討している場合、または自分自身がスクリーンリーダーを使う場合は、claude --ax-screen-reader（またはCLAUDE_AX_SCREEN_READER=1、settings.jsonのaxScreenReader）を対話モードで試すのが具体的な次の一歩になる。逆に、CLIツールの挙動を検証する際は「非対話（--print）と対話でモードの効果がまったく違う場合がある」という点を検証設計に組み込んでおくとよい。
あなたのチームに、スクリーンリーダーを使うメンバーがいたら、今のツール選定は変わるだろうか。
参考
- Claude Code Releases – GitHub — v2.1.208のスクリーンリーダーモード追加、v2.1.200の下地整備の一次情報
- Claude Code Changelog – code.claude.com — GitHub Releasesと一致する内容を掲載する公式チェンジログ
コメント