サイトワールド2025イベント JAWS日本語版20周年フォーラム (動画・テキスト)
動画
サイトワールド2025イベント JAWS日本語版20周年フォーラム
対談内容テキスト版(2025.10.18)
〈司会〉本日は、有限会社エクストラ JAWS日本語版20周年記念フォーラムにご参加いただき、誠にありがとうございます。本日、司会を務めさせていただきます、有限会社エクストラ奈木と申します。よろしくお願いいたします。ありがとうございます。
初めに、弊社を代表しまして石川の方からご挨拶を申し上げます。
〈石川〉はい、おはようございます。本日のセミナーにご出席いただきましてありがとうございます。フォーラムのタイトルの通りのテーマで、JAWS日本語版の開発20年を迎えたことを記念したフォーラムで、副題が「自分たちの道具は自分たちで作る、AI時代の…」JAWSだっけ、忘れた。AI時代の、えっと、JAWSの未来という、そういうタイトルで今日はこのフォーラムを開催したいと思います。
1番最初にまずあの、インタビューを聞いていただこうと思います。JAWSの開発を30年間、最初から携わって、中心的な役割を果たしてこられたグレンゴードンさんという全盲のエンジニアがいて、1ヶ月ほど前に私、Zoomでインタビューをしまして、それを、クローンボイスでそれぞれの声に似た合成音声にして、その声で吹き換えをしたものがあります。
後ろで微かに英語のオリジナルのインタビューもちょっと聞こえるかと思います。で、結構似てるなと思いますけど、ご本人に聞かせたら「僕の声と違う」って言われたんで「僕はもっとこんなにフラットでもないし、もっと抑揚がついてるし、もっと声が高い」「日本語は結構平板で、言語的な特性かもしれない」と。で、「だけど声質はよく似てると思いますよ」っていう、はい。
という風な話をしまして、妻に聞かせたら若干不評だったという。はい。で、私の声もちょっと鼻声になっていて、且つ本人よりはちょっと女性的な感じになっています。そんなことも一応ありますが、それをお楽しみいただきつつ、内容にフォーカスを当てていただきたいと思います。それではあの、再生の準備が良ければ行ってみたいと思います。
〈石川〉JAWSのユーザー中心の開発を30年以上に経ってリードし、世界中の視覚障害者の暮らしを変えてきたソフトウェアエンジニアであり、そして全盲の開発者でもあるグレン・ゴードンさんをお迎えできることを、とても光栄に思います。今日はどうぞよろしくお願いします、グレンさん。
〈グレン〉こんにちは、准さん、お招きいただき本当にありがとうございます。
〈石川〉オンラインでご参加いただき、そしてインタビューにご協力いただきありがとうございます。
〈グレン〉喜んで。
〈石川〉では、本日の進め方を皆さんにご説明しますね。私からいくつか焦点を絞った質問をして、それにゴードンさんに順番にお答えいただきます。
では早速最初の質問です。Windowsが普及し始めた初期の時代に、どのようにしてJAWSの開発チームに参加することになったのでしょうか?
〈グレン〉全くの偶然だったんですよ。というのも、私 UCLAでMBAを取得してビジネスの世界に進む代わりにUCLAのビジネススクールでプログラマーとして働き始めたんです。そこで使っていたのがミニコンピューターでしたね。80年代に流行っていたもので、1つのコンピューターに複数の人が同時に繋いで使う仕組みでした。PC自体に知能を持たせるのではなく、知能のほとんどはミニコン側にあってそれをみんなで利用する、そんな感じでした。
ちょうどその頃テッドヘンターが勤めていた会社ディーンブレイジーが経営するメリーランドコンピューターサービスがHP3000用の音声端末を作っていたんです。私はUCLAで働いていた時にその端末を入手して、仕事で音声が使えるようになりました。でも当時の私はこの分野では全くの素人で、スクリーンリーダーについても何も知りませんでした。ただの若いプログラマーに過ぎなかったんです。だからテッドに色々質問しました。電話で何度も話をして彼は惜しみなく知識を共有してくれましたね。やり取りを重ねるうちに互いを知るようになって、自然と友人になりました。
それからは副業のような形で、彼のプロジェクトをいくつか手伝うことにもなったんです。やがてWindowsの時代になると、正直キャリアが閉ざされるんじゃないかと心配しました。Windowsが主流になりつつあったのに、当時は全くアクセシブルじゃなかったからです。そんな時テッドがスクリーンリーダーの開発に取り組もうとしていました。私はそれを聞いて「これは面白いぞ」と思ったんです。自分を助けるだけじゃなく、同時に他の人も助けられますからね。私はとてもワクワクしましたし、強いモチベーションを感じました。そして、1994年4月にヘンタージョイスで働き始めることになりました。
〈石川〉実は私も、かつてメリーランドコンピューターサービスを訪問して点字プリンターを購入したことがあるんですよ。
〈グレン〉あぁ、そうでしたか。その時テッドに会われましたか？
〈石川〉いえ、会っていません。少なくとも気づきませんでしたね。いつその会社を訪問したかは忘れてしまいましたが、購入したのは…名前を忘れてしまったんですけど、パーキンス点字タイプライターをコンピューター化したような製品でした。
〈グレン〉あ、クラマーですね。クラマープリンターを買われたんですね。テッドは今本を書いていて、その中でクラマープリンターについても語っていましたよ。
〈石川〉では次の質問です。JAWSや他の支援ツールがない中で、どのようにしてJAWSの開発を行ったのでしょうか?
〈グレン〉実は面白い話があるんです。当時、DOSはWindowsが出る前に1番よく使われていたOSで、とてもアクセシブルでした。だから、DOSでは特に問題なく作業できたんです。ただ、どうしてもWindowsに入って、ドキュメントを読む必要がありました。というのも、プログラミングAPIに関する文書は、全部Windowsヘルプっていう独自形式のファイルにしかなくて、それを読まないといけなかったんですね。でも、そのWindowsヘルプをDOSで読むツールは、少なくとも私は見つけられなかったんです。
幸いなことに、JAWSはWindows用の最初のスクリーンリーダーじゃありませんでした。おそらく最初は、カナダの会社が出したスリムウェアウィンドウブリッジでしたね。ただそのデモ版は、1度に15分しか動かなくて、終わったらまた再起動しなきゃいけなかったんです。私はそのデモ版を購入して、それを使ってWindowsに入り、ヘルプ文書を読むことができました。必要な情報を集めたらDOSに戻って、エディタでJAWSのコードを書き、コンパイルする。そしてWindowsに戻って実行して、動作を確認する。問題が出たらまたDOSに戻って、直せそうなら直して、再びWindowsでテストする。修正の仕方が分からない時は、またウィンドウブリッジを立ち上げてヘルプを読む。そんな繰り返しだったんです。そうやって、何度も行ったり来たりしながら進めていって、最終的にはJAWSがWindowsで私に必要なサポートを提供できるレベルにまで仕上がったっていう感じですね。
〈石川〉本当に面白い話ですね。あのカナダの会社、シンサボイスだったと思います。その上でお聞きしたいんですが、やっぱりDOSのプロンプト、つまりDOSの画面を立ち上げて、そこでエディターを使って作業していたんですよね。
〈グレン〉はい。DOSでプログラムを書いていました。
〈石川〉コンパイラはボーランドC++ですか？それともMicrosoft C++ですか？
〈グレン〉私たちはMicrosoft C++を使っていました。ただ、私が会社に入った時には、チャックオッパーマンという人物が、すでにWindows版JAWSの最初のバージョンを書いていたんです。
彼はWindowsをよく理解していて、初期設計もうまくできていました。ただ動作はあまり安定せず、主要な部品は揃っていたものの、大量のデバッグが必要でした。そこで入社して最初の数ヶ月、Windowsをほとんど知らなかった私はチャックの書いたコードをテストして、数多くのバグを修正する役を引き受けました。これは私にとって本当に最適な状況でしたね。もし、ゼロから設計しなければならなかったら、ものすごく大変だったと思います。何しろ私はそれまでWindowsを使って仕事をしたこともなかったし、ユーザー体験も理解していなかったし、こういうプログラムをどう作り上げるべきかなんて、全く検討もつかなかったんです。
〈石川〉つまりチャックとあなたは良い組み合わせだったんですね。
〈グレン〉まさに完璧な組み合わせでしたね。小さなバグ修正で自信がつき、やがて大きな課題にも挑めるようになりました。初期版を作ってくれた彼の功績は、本当に大きいと思っています。
〈石川〉痛み止めを作ること自体が痛み止め、ってことですね。
〈グレン〉えぇ、時にそういうものです。
〈石川〉では次の質問です。1990年代半ばのCSUNカンファレンスでの対決Windowsについて聞かせていただけますか?
〈グレン〉もちろんです。ですがその前に、少し背景を説明しておいた方がいいですね。当時を知らない方のために言うと、本当に全く違う世界だったんですよ。
インターネットは存在していましたが、今のように生活の一部というよりは、あくまで、ネットワーク技術の1つだったんです。アクセスできる人は限られていて、人々が集まってアイデアを共有するような場ではありませんでした。単に、ごく一部の人が使えるシステムだったんですね。ですから、技術の情報が今みたいにすぐ広まることはなかったんです。今なら会議に一度も行かなくても、どんな技術があるか常に最新の情報を得られますよね。でも90年代半ばは、CSUNのような会議に行かなければ分からなかったんです。具体的にどんな技術がこれから出てくるのか、知る術がなかったんですね。
そういう環境の中で、マークネルソンとグレッグマイズがイベントを企画しました。Windows用スクリーンリーダーを開発している会社を一部屋に集めて同じタスクを実演させる、というものです。タスクそのものは本当に単純でした。ノートパッドでファイルを開く、段落を読む、Excelで表を開いて、A1やB1に入力して読み上げる、といった具合ですね。とても簡単な課題でしたが、聴衆にとっては、各スクリーンリーダーがどんな風に動くのかを一目で体験できる絶好の機会でした。私たちにとっても大きな宣伝効果があったんです。幸い、うまくやることができました。少なくとも2回は開催されたと思いますが、最初はまずまず、2回目は非常にうまくいったと記憶しています。
〈石川〉まぁ、今の基準からすると本当にシンプルなタスクでしたよね。でも当時あの場にいた聴衆にとっては、開発者自身にとっても、すごく難しくて、挑戦的に感じられたと思います。そしてそれが実際にできた瞬間、まるで奇跡のように思えたんじゃないでしょうか。実は私もあの時聴衆の1人でした。本当に驚きましたし、すっかり魅了されたのを覚えています。
おっしゃった通り、あの時代はそうしたイベントに参加しない限り、最新の支援技術の状況を知る手段はほとんどなかったんです。だからこそ、あのイベントはすごくワクワクしました。そしてグレンが、その実演をとても見事にこなしていたのを、はっきり覚えています。午前中はテッドヘンターさんがCEOとして実演していましたけど、何かの理由で途中で席を外されて、その後グレンが代わりに担当されましたよね。あの時の見事な仕事ぶりは、本当に印象に残っています。
〈グレン〉ありがとう。テッドは本当に頭が切れて、いつも先を見ている人でした。ただ、思ったことを率直に言うタイプでね。あの時も何か言ったか、したかで、ちょっと場がざついたんです。それでじゃあ交代しようかという話になって、私が代わりに出たんです。
〈石川〉確かに彼に何かが起きて、彼は反応に少し気を悪くしたような、そんな記憶があります。
〈グレン〉とはいえ、そうした苦い詳細は、あまり記憶に残らなくなるのが良いですね。
〈石川〉では次です。MicrosoftがMicrosoftアクティブアクシセシビリティを実装するきっかけになった協力や、やり取りについて教えてもらえますか?
〈グレン〉その件については、正直あまり深く関わっていなかったので、細かいことまでは分からないんです。向こうから「こんなことをやっているよ」「もう完成したよ」って教えてもらった、そんな感じでしたね。だから細部までは覚えていません。ただ、私たちがJAWSの開発に取りかかって、他のWindows用スクリーンリーダーもまだまだ初期段階だった頃、Microsoftはスクリーンリーダーの観点でWindowsをアクセシブルにする取り組みを何もしていなかったんです。だから自分たちでデータを集める方法を工夫するしかありませんでした。
最初に使っていた技術は2つあって、そのうちの1つは私はほとんど直接関わらず、手を貸して改良を手伝っただけなんですけどね。それがオフスクリーンモデルと呼ばれるものでした。その話をしても大丈夫ですか？
〈石川〉どうぞ。
〈グレン〉じゃあ説明しますね。DOSの時代は画面に文字が出るとそれがそのままテキストとして残ってビデオバッファーっていう領域から読み取れたんです。だからDOS用のスクリーンリーダーはその仕組みを使って動いていました。つまり、プログラムが画面に文字を書き出すと、常駐しているスクリーンリーダーがユーザーのキー操作に応じて画面上の任意の位置にある内容を読めたんです。テキストバッファーを見れば良かったんですね。
でもWindowsになると事情が変わって、データは全部グラフィックで保持されるようになった。だから、例えば「座標(64.64)に何があるの？」って聞いても、返ってくるのはピクセルの情報だけで、ほとんど役に立たないんです。そこで出てきたのが、オフスクリーンモデルという発想でした。
最終的に画面に描画されるのはグラフィックでも、文字は元々テキストとして扱われていますよね。その描画の瞬間にテキストを横取りして、文字の位置や幅、高さ、属性を全部データベースに記録しておくんです。そうすれば、後からスクリーンリーダーがユーザーに読み上げられる。もちろん言うほど簡単じゃなくて、画面から消されたり、上書きされたりする場合も全部追跡しないといけない。細かい処理が山ほどあるんですけど、これはMicrosoftが関わる前に僕らがアクセシビリティを実現するために使っていた方法の1つなんです。
もう1つの方法もあって、そっちは僕自身も少し貢献できたと思っています。Windowsのヘルプドキュメントを読み込んで分かったのはWindowsには、ボタン、チェックボックス、ラジオボタン、リストボックスみたいな標準コントロールが用意されているってことでした。これがすごく便利で、画面のある位置にあるのがどのウィンドウなのか問い合わせられるんです。一度ハンドルが取れれば、そのコントロールに直接「チェックされてる？」とか「押されてる？」って聞ける。
で、ウィンドウブリッジが出てきた時に気づいたのは、テキスト自体は読んでくれるけど、それが、ボタンなのかチェックボックスなのかは分からない、ということでした。だからオフスクリーンモデルとコントロールの問い合わせを組み合わせればただ「OK」と読むだけじゃなくて「OKボタン」と伝えられるしチェックボックスならチェックの有無まで分かる。これが、スクリーンリーダーが最初にデータを集める2つのやり方だったんです。
Microsoftも割と早い段階でプログラムがスクリーンリーダーに直接情報を提供できる仕組みが必要だって気づきました。そこで登場したのが「Microsoftアクティブアクセシビリティ」いわゆるMSAAです。これを実装しているプログラムなら、コントロールの種類や状態、チェックされているか、展開されているか、などをスクリーンリーダーに返してくれる。スクリーンリーダーとプログラムのやり取りを、より構造化してくれる仕組みだったんです。最初の頃は、僕らがプログラムから無理やり情報をかき集めていたんですが、MSAAのおかげで、より正確でユーザーに役立つ情報が得られるようになったわけです。
〈石川〉スクリーンリーダーの初期は、本当にオフスクリーンモデルに大きく依存していたんですね。そのモデルがどれだけ堅牢で、どれだけ質の高い情報を返せるか、それが、そのスクリーンリーダーが優れているかどうかを決める最大の要素だということですね。
〈グレン〉まさにその通りです。
〈石川〉チャックオッパーマンって、ちょうどその時期にMicrosoftに移ったんですよね。だからもしかすると、MSAAの実装に何らかの形で関わっていたんじゃないかって思うんです。
〈グレン〉えぇ、そうです。チャックはMSAAの開発に、本当に深く関わっていました。1つ、聞いたことのある面白い話があります。
チャックは僕と同じアメリカ人で、当時は多言語環境ってあまり意識してなかったんですね。ある会議で、MSAAをユニコードを前提に考えていなかったことに、誰かがすごく怒ったそうなんです。当時はユニコードそのものがまだ新しくて、悪気があったわけじゃなく、単純にそういう発想がなかっただけなんです。でも幸い他のメンバーが早い段階で気付いて、ユニコード対応にしてくれた。そしてそれが、内部的に完全にユニコードベースだったWindowsNTに移行した時に本当に役立ったんです。
〈石川〉最近FSのポッドキャストを聞いたんですが、そこでテッドヘンターが話していたんです。最初ヘンタージョイスはアメリカ中心、しかも英語中心の会社だったそうです。でも、トビアスウィネスが入社して、多言語対応と同時に点字サポートにも力を入れるように主張したそうですね。
〈グレン〉その通りなんです。テッド本人にとっては、あまり重要じゃなかったテーマだったんですが、私たちがそこに引き込まれるきっかけになりました。トビアスがはっきりと「ヨーロッパや他の国で成功するには、多言語対応は不可欠だ」って示してくれたんです。
そこから僕らは、その分野に力を入れるようになったんですね。そしてIBM、それからIBM JAPANが加わって、日本語のIME対応やユニコードの層を一緒に開発しました。担当者の名前は、正確には覚えてないんですが、少なくとも英語ではコールと呼ばれていました。彼と一緒に仕事をしていたのをはっきり覚えています。おそらく1年くらいは一緒だったと思います。
最初のIMEサポートを動かして、それからWindows95や98向けに、独自のユニコードレイヤーを実装しました。なぜかと言うと、彼らはWindows9XとNTのどちらでも動かしたかったからです。僕らは単一のコードベースを維持したかったんですが、NTのコードはユニコードだったので、Windows95や98向けのユニコードレイヤーを改良する必要がありました。僕は毎晩寝る前に「これで完成だ」と思って、コールにビルドを送っていました。「これは本当にいい出来だ」ってね。でも翌朝になるとコールからメールが届いていて、「いや、また別の問題を見つけたよ」って書いてあるんです。そんな風に少しずつ修正を重ねて繰り返しながら、日本語版を作り上げていったんです。
〈石川〉ヘンタージョイスとIBM JAPANがバージョン3.7と4.5をリリースしたんです。そのあと、私とエクストラがIBM JAPANに代わって、バージョン6から現在まで日本語化を担当することになりました。その基盤と努力のおかげで、私たちは日本語化に取り組むチャンスを得られたんです。
〈グレン〉実際のところ、最初の段階は単なるローカライズなんてものじゃなかったんです。というのも、当時の僕らにはマルチバイト文字セットの概念もなければマルチバイト文字がユニコードとどう関係するのかも理解していませんでした。JAWSもそうした仕組みを扱う準備が全くできてなかったんです。
西ヨーロッパの言語は同じコードページを使っているからまだ簡単なんですが、東アジアの言語に入ると、全く新しい問題が山ほど出てくる。だから初期の頃はその対応にほとんどの時間を費やしていました。単なる翻訳じゃ足りなかったんです。内部から作り直す必要があったんですよ。
〈石川〉私たちがローカライズの役割を引き継いで、バージョン6以降を担当するようになってからも、いくつもの壁に直面しました。その時グレンが、言語プロセッサーやFSテキストサービスを開発して、提供してくれたんです。あれは日本語テキストを点字に変換するためにも、IMEをサポートするためにも、欠かせないものでした。
〈グレン〉聞いている皆さんに言っておきますが、准は自分の貢献をちょっと控えめに話してますね。実際のところ、彼の洞察力やアイデア、そしてサポートがなければ、私たちはここまで開発を進められなかったと思います。確かに私たちは内部の仕組みを作りましたが、それだけでは不十分なんです。どう使われるのか、ユーザーが何を求めているのか、その理解がなければ本当の意味での開発はできません。そういう意味で、准は本当に最高のパートナーでした。
〈石川〉とても親切に言っていただいて、本当にありがとうございます。続いて、JAWSの仮想バッファーとDOM解析は、ウェブアクセスをどう変えましたか?
〈グレン〉そこには、ちょっと面白い話があるんですよ 。僕はずっと、最初に仮想バッファーを導入したのはウィンドウアイズだと思ってたんです。でも、数年前にダグジョフリーにインタビューした時に「あなたが最初にやったのは本当にすごいですね」って言ったら、彼は「いや、僕らはアークティックウィンビジョンから拝借したんだよ」って答えたんです。アークティックウィンビジョンも初期のスクリーンリーダーの1つでしたから、誰が最初かって断言するのは難しいんですよ。きっと、同じアイデアを持っていた人が多かったんだと思います。
いずれにしても、ウェブページって元々視覚的に作られていて、ワープロの文書みたいに、順番に読むことは想定されてないんですよね。でも、僕ら視覚障害者にとっては、一度に取り込める情報って、本当に限られてるんです。点字を使えば多少は増えますけど、 それでもやっぱり少ないままなんですよ。まるで、ストローで情報を少しずつ吸ってるような感覚というか。だからこそ、ウェブページをワープロ文書みたいに上から下へ、文字や単語、行ごとに順番に読める仕組みが必要だったんです。晴眼者は、目を動かせば自然と行きたい場所にたどり着けるんですよね。画面のハイライトやデザインの流れが「ここを見ればいい」「ここが重要だ」と教えてくれる。
でも僕たちはそうはいきません。だからこそ、仮想バッファという仕組みを作ったんです。これは、視覚的にデザインされたウェブページをスクリーンリーダーで理解できる形、つまり、文書のように上から下へ、順番に読める形に並べ替えるための橋渡しなんです。その仕組みは、年月を経て変わっていきました。
最初のバージョンを作ったのはまだ、Webが今のようにインタラクティブじゃなかった頃です。当時は、特定のURLにアクセスすると、ページが読み込まれて、ユーザーがリンクをクリックするまで、何も起こらない。そんな静かな時代でした。その頃のインターネットエクスプローラーには、JAWS側から、「このページのHTMLを全部ください」と要求することができたんです。それで、JAWSがHTMLを解析して、自分たち独自のページモデルを作っていました。そこから、仮想バッファを生成していたんです。どうやってリンクを実行していたかは、正確には覚えていませんが、IEに「このリンクへ移動して」と指示を出す仕組みがあったんですよ。この方法は、最初の1～2 年はうまく機能していました。でも、やがてWebがどんどん進化してページが動的に変わるようになってくると、一度だけHTMLを取得して、それを静的に扱う、という考え方はもう通用しなくなったんです。
それで仮想バッファを丸ごと作り直しました。JAWSがインターネットエクスプローラーに対してページの内容を繰り返し問い合わせるようにしたんです。そして、IE側がページの変化を検知すると、JAWSに通知を送り、仮想バッファを更新できるようにした。そうやって、ユーザーがいつでも最新のページ情報にアクセスできるようにしたんです。
〈石川〉興味深いですね。UIオートメーション、いわゆるUIAの登場は何がきっかけでしたか?法的圧力とか障害者運動、ATベンダーからの要望、それとも、Microsoft自身の判断でしょうか?
〈グレン〉正直、全てを把握しているわけではないんですが、いくつかの出来事がありました。まず、MicrosoftがMSAAを発表しました。でもその後しばらく改良されることはなかったんです。良い点もたくさんありましたが、同時に制限も多かった。例えばテキストのナビゲーションをサポートしていなかったんです。つまりテキストエディターのようなプログラムが文書の内容を公開しようとしてもMSAAではワープロのような用途には対応できませんでした。さらに、セクションを展開したり、折り畳んだりするような複雑なテーブル構造にも対応できませんでした。
一方で同じ頃、LinuxやUnixの世界でも、アクセシビリティに取り組む動きが進んでいて、特にIBMのリッチシュアルツフェガーという人物が中心となっていました。そして「LinuxとWindowsの間で、似たようなインターフェイスがあればいい」「少なくとも機能的には共通のものを持てるようにしよう」という考え方が生まれたんです。そこで登場したのがIAccessible2でした。これはMSAAを土台にして、追加のインターフェースを備えたものです。ただ、なぜMicrosoftがIAccessible2を受け入れなかったのかは分かりません。でも、彼らは採用しなかった。そして完全に独立した形でMSAAの後継となる新しい仕組み、UIオートメーション、UIAを作ることに決めたんです。これはMSAAで得た教訓を踏まえて、次世代のアプローチを実現しようとしたものでした。
90年代後半から2000年代初頭のMicrosoftにはドットネット、特にC#がWindowsを席巻して、将来はみんなC#で書かれるようになるっていう雰囲気がありました。だからUIAの初期サポートはC#だけだったんです。ネイティブなインターフェイスはなくて、裏側のチャンネルみたいなのはあったけど、公表されてませんでした。なのでUIAが実用レベルになるまで時間がかかったんですよね。実際、僕も一度MicrosoftとIAccessible2の関係者が集まる打ち合わせに出たことがあります。両社を統一しようとしたんですけど、その会議は口論になって、結局うまくいかなかったんですよ。で、20年経った今でも、IAccessible2はFirefoxやChromeで使われています。ただそれらのブラウザーもUIAをサポートするようになって、結果的に2つの技術が並立してるんです。
僕たちは両方使っていますね。提供される情報はほぼ同じなんですけど、やり方が2通りあるってことです。これから新しく始めたい人には、当然UIオートメーションを進めます。でも、すでにMSAAをしっかりサポートしているプログラムならIAccessible2の方が有効なことも多いんですよ。そんな感じです。
〈石川〉ありがとうございます。では次の質問です。WAI-ARIAはどうやってアプリのアクセシビリティと結びついたんでしょうか?
〈グレン〉すみません。もう一度お願いできますか?
〈石川〉WAI-ARIAがアプリのアクセシビリティとどう関係してきたのか、ということです。
〈グレン〉それも、先見の明のあったリッチシュアワルツェイガーの発案だったんです。彼はIBMでの仕事を通して、ウェブサイトがどんどん複雑になってきていて、開発者が作ってるUIの種類と、HTMLのタグの名前がずれてきていることに、いち早く気づいたんですよ。つまり、HTMLのタグ名だけじゃ、その構造をちゃんと伝えられなくなっていたんです。
例えば、アコーディオンっていうUIがありますよね。最初は折りたまれた複数行のテーブルで始まって、そこから一部を展開できたり、展開された部分の中に、さらに別の要素があったりする。でも実際の実装は、普通のテーブルにdivをちょっと足すだけみたいなケースが多かったんです。スクリーンリーダーから見れば「これはテーブルです」としか分からなくて、折りたためるとか、展開できる、といったことを伝える手段がなかったんですよね。
そこでリッチたちが考えたのがARIAです。開発者が簡単に使えるHTML属性を用意して自分たちが作っているUIの役割や状態を、スクリーンリーダーに伝えられるようにしたんです。最初はロールやステートから始まって、だんだん多くのプロパティや追加情報に広がっていきました。それで、スクリーンリーダーがより正確にページを説明できるようになった、というわけです。
よく「ARIAをどう評価しますか？」って聞かれるんですけど、僕の答えは「何と比べて？」なんですよね。だって、ARIAがなければ、代わりになるものは何もなかったんです。ウェブぺージはどんどん複雑になっていったでしょうし、もしARIAがなかったら、スクリーンリーダーは全然追いつけなかったはずです。ARIAはそのギャップを埋めてくれたんです。
〈石川〉ここからは、私や今日の聴衆にとって、1番大事な質問になります。なぜ、視覚障害のある開発者が、支援技術の開発の中心にいなければならないのでしょうか?
〈グレン〉JAWSが成功した理由はいくつかあるんですが、大きかったのは、開発を含めたあらゆる段階で、視覚障害のあるスタッフが多く関わっていたことだと思います。初期にはスクリーンリーダーがたくさんあって、1996年の対決Windowsの頃も、多くの製品が競い合っていました。でも3～4年ぐらい経つと、残ったのは私たちとWindow-Eyes。それにあと1～2製品くらいでした。
当時、私は主要な開発者でした。先ほどお話ししたチャックオッパーマンは、私が入社して1年もしないうちにMicrosoftへ移ってしまいましたが、その後も視覚障害のある開発者を何人も採用しました。自分の経験から言うと、自分で実装した機能を日常的に使っていると、不具合にすぐ気づけるんですよね。そして気づいた瞬間に直せる。他のユーザーに渡してテストしてもらう前の段階で、ずっと完成度を高められるんです。この力を複数の開発者が持っていると、プライベート版やパブリック版のベータに出す前から、相当数の不具合を潰せます。早い段階で直せば直すほど修正は簡単ですから、バグを登録して、説明して、修正して、検証して、という一連の流れをいちいち踏まずに済むんです。
それからもう1つ、多分こっちの方がもっと重要なんですが、視覚障害のある開発者って、自分たちが本当に必要とするものをよく理解しているだけじゃなく、それをどう実現するかという技術にも橋渡しできるんです。ユーザーは「これが必要だ」とは言ってくれますが、実現方法までは知りませんよね。でも、視覚障害者の開発者ならユーザーとしての経験もあるし、技術的に可能かどうかも判断できる。「これなら実装できる」と判断できる。その両方を理解できる立場にあるんです。
〈石川〉私はね、再現できるバグは好きなんですけど、再現できないバグは本当に嫌いなんですよ。
〈グレン〉それはみんな同じですよ。
〈石川〉では最後の質問です。これから3～5年を見据えて、AIはスクリーンリーダーとユーザーに、どんなことを可能にすべきだと思いますか?
〈グレン〉えっと、まず最初にお伝えしておきたいのは、これからお話しするのはあくまで私個人の意見なんです。私はFreedom Scientific、つまりVisperoの社員ですが、会社を代表して話すわけではありません。うちの会社には、本当に優秀な人たちがたくさんいて、それぞれに考えやアイディアがあります。だから、私の意見が会社の公式な立場というわけではないんです。まぁ、その前提で聞いてもらえればと思います。
このAIの話については、私自身の考えも、年月を経るごとに少しずつ変わってきました。例えば、JAWSにはピクチャースマートいう機能があります。これは画像をAIに送って、その説明を得る機能なんです。JAWSは、例えばウェブページ上のどこに画像があるかを把握できます。ですから、この画像をチャットGPTや Anthropicに送って説明をもらい、さらに、ユーザーがその画像について質問できる、そんなことが簡単にできるようになっています。この機能は、私たちが最初に取り組んだAIの活用例の1つで、非常に役立つことがわかりました。技術が進歩し、使う人が増えるにつれて、その価値はますます大きくなっています。AIの役割は、私は大きく2つあると思っています。
1つは、「AIがどれだけタスクを早くこなせるか」という点です。例えば、Webで予約を取るとします。本当に重要なのは、全てのボタンを押すことでも、全ての手順を踏むことでもないですよね。大事なのは、予約を完了することなんです。AIがその一連のプロセスを自動的に処理できれば、ユーザーは結果だけを受け取ることができる。これが大きな可能性の1つです。特に今のように AIが急速に発展している過渡期では、ユーザーがまだ自分でサイトにアクセスして操作する必要も多いです。例えば、日付ピッカーのような操作が難しいUIがありますよね。でももしAIが画面上の情報を読み取って、自動で日付を選んでくれるなら、手作業よりずっと早く、ずっとスムーズに操作できます。そして、もちろん時間が経つにつれて、AIに頼める作業の複雑さは劇的に高まっていくはずです。
しかし同時に忘れてはいけないのは、AIも間違えるということです。いわゆるハルシネーションですね。自信満々に、でも全然違う答えを返すことがある。この点について考える時、私は晴眼者のことを思い浮かべます。彼らだって、Amazonのスマートデバイスを買って、モニターを消して、AIだけと会話したいわけではありませんよね。やっぱり画面を見て、自分の目で情報を確かめたいんです。これは特に、データテーブルのような場面で顕著です。
AIに要約させるのは便利ですが 、もし内容が重要なら、自分でもちゃんと確認したい。全てを精査する必要はなくて も、肝心な部分は見ておきたい。ですから私はこれからも、標準的なスクリーンリーダーの機能は欠かせないと考えています。AIが文書の初稿を作ってくれたとしても、仕上げや細かい編集は人間が行う必要があります。AIがいつも正確とは限りませんからね。ユーザーが、自分の目と耳で確認し、自信を持ってこれでいいと思えるようにする。そのためにこそ、スクリーンリーダーは存在し続けると思うんです。
〈石川〉スクリーンリーダー開発の、30年に渡る舞台裏を聞かせていただき、本当にありがとうございました。グレンさんのキャリアは、ユーザー中心の開発の大切さを教えてくれますし、視覚障害のある開発者がリーダーとして関わることの意義を、改めて示してくれたと思います。今日のお話が、これからの新しい協力や、もっと包括的で使いやすい製品作りにつながることを、心から願っています。グレンさん、本当にありがとうございました。
〈グレン〉どういたしまして。准がJAWSを日本市場に広めたことに比べたら、 私ができたことなんて本当に小さなものです。でもこうしてこのイベントに参加できて、とても光栄に思っています。
〈石川〉今日の議論が、新しい協力や、より包括的な製品作りにつがることを心から願っています。本日はありがとうございました。以上で、グレンゴードンさんとのインタビューを締めくらせていただきます。
〈石川〉はい、どうもありがとうございました。こういうインタビューを1ヶ月前にしまして、ま、これを受けて、パネルディスカッションしたいと思います。
パネルリストを紹介します。まずは、Seikenラボの切明政憲さん。そして、有限会社エクストラの北畠一翔さん。で、モデレーターは私が務めさせていただきます。よろしくお願いします。
で、手始めになんですけど、あの、それぞれに、スクリーンリーダーとの、これまでのこう、向き合い方というか、付き合い方というか、について、ちょっと語っていただきたいんですが、ユーザーとして、テスターとして、あるいは開発者として、まぁ、特に切明さんは非常に長いキャリアがあるので、言えることは山ほどあると思うんですけど、その中でこう、特にフォーカスを当てていただければと思います。
〈切明〉はい。えっと、切明です。よろしくお願いいたします。えっと、私が初めてコンピューターに、アクセシブルな状態で触れることができたのは高校2年生、1989年、あるいは88年のことでした。当時はまだMS-DOSの時代で、VDM100っていうスクリーンリーダーがあって、これもまぁ、今回のテーマではありますけれども、当事者ユーザー自身が作った、スクリーンリーダー、齋藤正夫さんが作られたスクリーンリーダーっていうことで、それを最初に触って「すごい、パソコンってのはこうなのか」っていうことを非常に感動して、触り始めたのを覚えています。
その後自分でもプログラミングをするようになって、学生時代は、パソコン部屋に切明って張り紙されたパソコンがあったっていう、そんな状況だったんですけども。それから、次に、Windowsの時代にやっぱり入って、グレンさんもおっしゃってましたけれども「どうするんだろう」っていう、やっぱ非常に不安で、プログラミングそのものができなくなるんじゃないかっていうような不安もあったりして、一時期は、私はUNIXに逃げ込んでいて、なぜUNIXに逃げ込んでいたかって言うと、UIがほとんどDOSと同じで、文字を使ったUIで、だったかだったのでずっとUNIXに入れ込んでいたんですけれども、Outspokenっていうスクリーンリーダーの開発に、石川先生に誘っていただいて、それが2000…2000年でしたっけね。はい。2000年ぐらいのことでしたけれども、その時に誘っていただいて、Windowsのスクリーンリーダーに入ることができました。で、その後は、JAWSの開発にやっぱり誘っていただいて、JAWSのスクリーンリーダーの開発にずっと関わせていただいてるっていう、そんな流れになります。
〈石川〉ありがとうございます。随分端折ってくださったので、また後で話していただければと思います。この3人の中で圧倒的な若者である北畠さん、お願いします。
〈北畠〉はい。エクストラの北畠と申します。えっと、先ほどグレンさんのインタビューですとか、この切明さんのお話でずっとスクリーンリーダーの初期の頃のお話があったんですけれども、その時代を全く知らない、2001年生まれの北畠と申します。現在24歳に、先日なりました。
で、私の場合はですね、まぁもちろんWindowsネイティブと言いますか、Windowsをずっと使っている世代なわけですけれども、初めてコンピューターを触ったのは小学校3年生ぐらいですかね。2010年とか11年とか、それぐらいの時期でした。当時あまりJAWSっていうことをあんまりこう詳しくは知らなかったんですけれども、中学生ぐらいにだんだんこう、スクリーンリーダーとか視覚障害者向けの支援技術っていうのが面白いなという風に思い始めて、中学校3年生ぐらいですかね、JAWS17というバージョンからJAWSユーザーになって、今でもメインでJAWSを使って、仕事や生活をしているという状況です。
で、まぁ、ずっとユーザーとして接してきたわけですけれども、2年ほど前から、開発のテスターも含めた開発側で関わらせていただくようになりまして、今はもちろんエクストラのスタッフとして、今年出た2025とかも含めてローカライズ側にいるわけですけれども。はい、そういう風に、ユーザーから開発者になって、まだ間もないというキャリアになります。どうぞよろしくお願いします。
〈石川〉はい、ありがとうございます。あの、自分の話はあんまりしてもしょうがないので、ここスキップさせていただいて。
私あの、斎藤さんのVDM100っていうMS-DOSのスクリーンリーダーを見てすごい、なんか素晴らしいなと思って。自分も作りたいなと思って、グラスルーツというマイナーなMS-DOSのスクリーンリーダーを作って。だからビデオラムを見れば、画面に書かれている文字が、こうレビューすることができるっていう。まぁ本当にあの、実感として分かりますし。その前にあのJAWSって、MS DOS版っていうのがあって、それはそのさらに前に、フリッパーというスクリーンリーダーがあって、これがとても素晴らしくて、本当はフリッパーみたいなスクリーンリーダーを作りたいっていう風に思ったんですね。で、それであの、メモリ常駐プログラムってどうやって作んのか、とかね。割り込みをこう、なんだろう、取り込んできて情報を取得して、コンセントで出すとか、そういうなんかトリッキーなことも、なんか面白いなと思って以来、なかなか技術は上がっていかなかったんですけれど、スクリーンリーダー開発に関わってきました、という感じです。
JAWSの機能は本当にたくさんあって、未だに何割理解してるのかな。自分が使える機能って、本当に一部でしかないんですよね。で、それは他のスクリーンリーダーでもそうだと思うんですけど、ボイスオーバーもどんどん進化してるしだからおそらく、まぁ多かれ少なかれ誰しもそうだと思うんですけど、オプション設定を変えることで違う動きをしたり全体を把握できてるってことはなかなか大変なことだなと思いますんで、そういったことも含めて今後、もっと使いやすくしていくといいと思っているので、今日の議論の中でそういう話もできたらと思います。
グレンゴードンさんの話を聞いての感想もちょっと聞きたいんですが、切明さん、あの、なんかこう感想があったら教えてください。
〈切明〉ユーザー中心の開発っていうことについて、やっぱり私も全く同じようなことをやっぱりずっと思っていて。何が必要かっていうことを直感的に、それから切実に理解してるのはやっぱりユーザーで、そこをどういう風に開発に、製品の中に組み込んでいくといいのかな、ってそのための最短距離ってのはどういうことなのかなって言うと、やっぱり自分で作ってみることかなっていう風に思ってるんですね。「説明するより見せろ」っていう格言がどうやら、私が前勤めていた会社ではあるらしく、「いや、言ってるぐらいなら作って見せて」っていうことだと思うんですね。で、やっぱそれをこう実践していくことで「あ、こういうことが必要なんだ」っていうことをこう、示していく、形として示していくっていうことの大事さとか、それから、それをこう、製品に入れていくことの大事さとか、そういうことをやっぱずっとずっと長いことやっていらっしゃったグレンさんの功績というのは非常に大きいんだなっていう風に思うし、それを日本で実践してきている先人…まぁ私の上の世代の人たちみんなそうやって必要なものを自分たちで作っていって置いてきたっていうことは非常に大事な功績なんじゃないかという風に思っていて、まだまだ私も学ぶところが大きいなっていう風に思います。
〈石川〉ありがとうございます。ユーザー中心とはいうものの、成功には必ず良き伴走者が必要で、テッドヘンターにも良き伴走者がいたし、斎藤さん1人でやったくさいんですけど、私も、DOSの時代もWindowsの時代もすごい技術を持ったプロのエンジニアの人で、すごく親しくさせていただいて、常にサポートしていただいて、ここまでやってきたっていう経緯があるんです。
北畠さんは、グレンゴードンのインタビューを聞いての感想ってなんかありますか?
〈北畠〉はい。えっと、もちろん当事者としての関わりっていうのはそうなんですけれども、やっぱりその、最初のWindowsのスクリーンリーダーを作るストーリーがあったわけですけれども、無いところから作っていく、自分たちが作ろうとしているものが無いと作れないっていう状態なわけですよね。スクリーンリーダー…画面読みたいからスクリーンリーダーを作るわけですけれども、スクリーンリーダーを作るためにはスクリーンリーダーが必要だみたいな、そういうことがあるかなと思うんですが、そこをどうやって、本当に情報が少ない中でスクリーンリーダーのデモ版を、どうにか動いてるデモ版をこう使って確認してまた直してとかですね。そういう当時の苦労話なんていうのは、今の私たちからすると情報なんていくらでも入手することはできるｍいくらでもまぁ限界があるにしてもできるっていう状況から考えるとすごくあの、なんでしょう、歴史的なこう、経緯を感じるなっていうのを感じました。はい。私からは以上です。
〈石川〉えっと、なんか教科書的な話ばかりだとつまんないので、ここで若干キラーパスを入れたいと思うんですが、JAWSはヘンタージョイスっていう会社をテッドヘンターが作って、そのジョイスさんっていう人は何者か全然ちっとも出てこなくて、多分テッドヘンターになんか、お金を貸してくれたり、そういうことしてくれた人なんじゃないかなって。ちょっと誰にも聞いてないんでよくわかんないんですけど。表に出てきたことがないんですよね。しかし、ヘンタージョイスっていう会社をやってて。2000…何年ですかね、2000…2000…2002～3年ごろにFreedom Scientificっていう会社に、ヘンタージョイスとか、ブレイジーエンジニアリングとか、アーケンストンていう会社があって、このFreedom Scientificが全部M&Aで会社を買って、Freedom Scientificになりました。
で、それからもグレンゴードンとかヘンタージョイスの人々、ただしテッドヘンターを除いてですけど、会社に残ってずっと開発してきたんですが、アメリカではあの、なんていうか、会社を上場するか、あるいは、その会社の評価が高い時に売るのが正しいとされていて、それをしないのは、なんていうかな…懸命ではないという風にされていて、テッドヘンターも売っちゃったわけですね。で、売った後で、つまんなくなったそうなんですよ。お金は入ったけどつまんない。やることなくてつまんない。でも今まで自分がやってきた仕事は必然性があってやっていたことで、情熱もあったしじゃあ、これ以上情熱を傾けられるビジネスっていうか、そういうのを見つけることはできなくて。元々あの、なんて言うんですかね、水上スキーかなんかの選手だったらしいんですけど、ま、そういうことはやったりしてたけれど、高いプレジャーボートを買ってみてもつまんないし、って言ってました。で、つまんないのは、まぁ本人の問題なんだけれど。
実はその、Freedom Scientificはまたさらに、Visperoっていうベンチャーキャピタル、あ、ベクター、ベクターかな?Victorていうベンチャーキャピタルによって買収されて、だんだんと大きな企業になっている。だんだんとユーザー中心の開発とか、こじんまりとしてやってた時代とは違う、なんか質的に違うものになっていくっていう。それがまぁ問題としてあるんじゃないかなっていう風に思います。
で、次にAI時代のスクリーンリーダーについて、ゴードンさんは語っていたんですけど、これもあの、よく分かる話だと思うんですが、これについては切明さんどう思いますか?エージェント機能ということが言われてたと思うんですけど、読み上げてくれるだけじゃなくて、実際に実行してくれるようになることを期待しますか?
〈切明〉はい。えっとですね、私が、今はコード確認しても、何しても、結構AIを使うようになりました。理由はいくつかあるんですけれども、Web検索をしているよりも圧倒的に早いことが多いっていうのがまず1つ。それから、AIが学習をしていくと大体私の考えを読んでくれて、それで行動してくれるようになってくる、っていうことが1つと。そうですね、なのでこの2つの理由でAIを使うことが多いんです。
コードを書いていても、例えば、そうですね、ロジック的に5つ同じようなロジックが並んでいて、それを足したいといった時に、ロジックの最初の部分をちょろっと書き始めると、多分こうだよねって言って10行ぐらいのことをバって書いてくれて。で、わーって読み上げてくれる。多分正しいと思って、とりあえず受け入れて。で、それを精査する方が、10行自分で書くより早かったりするんですよ、やっぱり。なので、そういうことをするようになりました。
Web検索についても、そうですね、 やっぱ、うん、自分で検索を入れて出てきた10件、20件のページを全部読み進めていくよりも、ある程度のことを、知ってしまった後にもう1回それを使って検索をする、引き直すなり、した方が、早いことが多いかなっていうことは、実際感じるようになりました。なので、AIは非常に私にとっては重要な、アクセシビリティの1つの手段にやっぱ今はなりつつあるなと思っています。
で、それを踏まえて、そのエージェントの話なんですけれども、えっとね、私はGeminiを使うことが多いんですけれども、このGeminiにパソコンの画面を共有させながらフォーム入力をしたことがあるんですね。で、どうにもこのフォーム入力が完了しないもんですから 「ねえ、何が足りない？」って聞いたら、「性別がチェックされていません」そうなんだよ、この性別のチェックがどっちに入ってるか分からんのよって思って、それはアクセシビリティ上の問題でですね、ページの作りが良くなくて分からない。で、とりあえず、男性って書いてあるところエンターしとくかって。で、エンター押した瞬間に「チェックされました」って言われたので、あ、ちゃんと見ててくれたんだなって思って、ここまでやれるってことはもう、もう自分で行動してくれてもいいのにな、ってやっぱ思うんですよね。なので今後、エージェント化して、自動的に、あるいは「ここチェックしていいですか?」って聞いてくれて、半自動的なことが起こるようになってくると、随分スクリーンリーダーユーザーのソフトウェアの開発は早く正確になるんじゃないかな、という風に思っています。
〈石川〉はい。えっと、北畠さんどうですか?どういうことをAIによってこう、パワーアップしたスクリーンリーダー…
〈北畠〉そうですね。えっと、ま、スクリーンリーダーっていうのはやっぱりこう、画面の見えないものをこう、音声とか点字に変えることによって教えてくれるっていう性格なソフトだと思うんですけれども、現状AIなしで考えた時に、スクリーンリーダーでできないことっていうのは、誰かに見てもらうっていう風なことがあると思うんですね。で、誰かに見てもらうっていうケースと、それを見てもらった結果、どうしても自分では操作できないので、操作をやってもらうっていう。ま、他の人にですね。まぁそういう2パターンがあると思っていて。えっと、今でもその、ピクチャスマートって先ほど話があったんですけれども、JAWSで、画像を説明させる機能ですね。これで、見てもらうっていう部分に関しては、概ねできるようになったなと私自身も感じてます。先ほど切明さんのフォーム入力の件は多分それに近いものだと思うんですけれども、えっとそれに対して、どうしてもこれ押せないからじゃあ押してよっていうことが言えるととても便利だろうなとは思うんですね。
ただその反面、ちょっと懸念点としては、確かにそうすると早いし、ハルシネーションがあるにしてもある程度正確になるだろうとは思うんですけれども、逆に、なんでしょうね、使う楽しみって言い方かは分からないんですけれども、こう、自分の知らないところで、AIがどんどん操作していくっていう風な感覚になるのがちょっと怖いなっていう風な思いもあって、できないことはAIでもちろんやる、あるいは、できるけれども時間がかかること、難しいことっていうのを助けってもらうっていうのは一つかなと思うんですが、それでもやっぱり、使いどころをこう全てAIに任せるっていうのはちょっと、それはそれで、まぁ良くない部分もあるなという風に、最近感じてるところです。
〈石川〉全部任せてしまうと面白くない、つまんないってことですね。
〈北畠〉そうですね。
〈石川〉最初はなんだかよく分からない画面レイアウトになってて、こう色々と思考錯誤してるうちに、だんだんと画面構成とか、こうなんじゃないかとか、そういうのが分かってきて、なんて言うかな、そのアプリケーションの理解ができるようになってくるっていう、その過程が良いという感じですか。
〈北畠〉そうですね。あの、色々触ってみながら、あ、これはこういう風になってるんだな。
〈石川〉いやぁ、そうですね。あと10分でその、なんかミーティング入んなきゃいけないとか、カレンダーに予定を書き込まなきゃいけないと焦ってさえいなければ、まぁいいなと思うし、それからその、全体の構造をスクリーンリーダーが説明してくれるといいなと思うんですよね。
今あの、ピクチャースマートって言っても、なんて言うかな、こちらの求めてるような視点から説明してくれるとは限らないんですよね。よくあの、誰かに見てもらう時にやっぱりよく、なんというか、勘のいい人っていうか、よく分かってる人はちょうど過不足なく説明してくれたりしますね。で、全くわからない人は、そんなとこ読まないでっていうとこを読み出すじゃないですか。だからよく分かってて、文脈とかも理解してて、あ、こういう風になってますよっていう風に、簡潔に、しかもその、なんて言うかな、必要十分な説明をしてくれると、いいんじゃないかなと思うんですけど、それはやってくれそうですよね。
〈切明〉思います。
〈石川〉はい、そういうようなことがありました。先ほどその、スクリーンリーダー開発をユーザー中心にやってきたFreedom Scientificもやっぱり、グローバルな市場を相手にして開発を継続していくために、色々な局面で新しいバグが見つかって、それを解決していかなければならなくなって、ま、技術的な問題もあるし、それ以外の問題もあるし。ということの話を、グレンさんもしていたと思います。で、まぁ我々も、日本語のJAWSをさらにクオリティを上げて、開発を継続していきたいと考えていますが、その上でなんか、特に外部の切明さんから見て、エクストラはもうちょっとこういうことしなきゃダメだよとか、こういうことを、もう少し課題としてあるんじゃないのっていうこと、まぁあったら、忌憚のないご意見をただきたいと思います。
〈切明〉はい。あの、まずJAWSそのものの話をちょっとさせてください。えっと、日本語版のJAWSで私がどうにかならんもんかなと思ってるのがIME日本語入力のサポートの充実なんですよね。
どういうことかって言うと、今の日本語入力のシステムってすっごい色んなことができるようになってるんですよね。例えば、ユーザーが入力しようとしているものを、それこそAIとかで学習していて、きっとこれだよね、っていうのとか。そういうのをどうしたら、なんて言うのかな、効率的に音声とか点字で伝えられて、うまいことそれが使っていけるんだろうとか、そういうのはとてもその、UIとしての興味が私はあって、どんな風にしたらうまくいくんだろうな、あの例えば、Wordとかでも、自動的にフォーマットをしてくれる機能とかについて、多分オフにされていらっしゃる方も多いんじゃないかという風に思うんですね。
それは理由が2つあって、自分が知らないところで、自分が意図しないことが起きることが困る、ていうことと、ああ、同じか、ていうことだと思うんですね。で、えっと、それは、じゃぁ、裏を返せば「じゃ分かればいいんだよね」ってことだと思うんですよ。今こういうことが起きたっていうことがすぐに分かればいい。でもそれがうまく伝えられていない、スクリーンリーダーが伝えられていないから、自分が意図しないことが起きてしまう。ならば、それをどうやって伝えたらいいんだろうっていう風なことも含めて、日本語の入力をどうやったらこう…もっと効率的に…。今全部打つしかないんですけれども、多分みんな全部打ってないんですよ、見える人って。それをどうしたらいいんだろう。結局その、変換するっていうことが入力の効率を視覚障害者結構落としているので、どうしたらいいんだろうな、みんなに6点漢字覚えてって言うわけにもいかんしねっていう風にも思ってる。それが一番興味がありますね。
あとはそうだなあ。これ私自身が活動できることでもあると思うんですけれども、こんな風にしたらJAWSは便利に使えるよっていうこととか、いうことをこうどういう風に発信してったらいいんだろうなっていうことをちょっと今は、思っています。そんな感じです。
〈石川〉ありがとうございます。北畠さん、どうですか?今会社に入ってみて内情も段々と理解して、取り組んでることもあると思いますので、そういう話でもいいし。ま、ここをやっぱりちょっと強化していかないといけないんじゃないかっていう。
〈北畠〉そうですね。えっと、やっぱりJAWSの、1つのその、ま、特徴でもあり魅力っていうのは、すごく細かいカスタマイズができることだと思ってるんですね。あの、私自身、技術サポートの担当を普段やってまして、皆さんからご質問いただいて、回答するってこともやってるんですけれども、それでもですね、私ですら知らなかった設定っていうのたくさんあるぐらいに、豊富な設定項目があります。で、それを駆使すればかなりいろんな風にあのカスタマイズができて、初期状態のJAWSとはまるで違う読み上げソフトにしてしまうようなこともできるっていう風に言っていいと思うんですけれども。その分ですね、先ほどの切明さんの使い方の発信ってこともちょっと関連するんですけれども、どういう設定ができるのか、あるいはどこをどう弄れば好みの設定になるのかっていうことが手探り状態になっている部分が、私自身もあると思っていますし、たぶんユーザーの皆さんでも多分そのように感じておられるところもあるかなと思うんですけれども。
なのでその、豊富なカスタマイズの、これだけカスタマイズできるのにどう頑張っても変えられないところ、例えば、アルファベットとか数字とか記号とかの全角半角っていうのは、他のスクリーンリーダーだと例えば半角だと高い声で呼んだりとかしますけれども、JAWSは、少なくと私の理解では、元が英語ってこともあるんでしょうけれども、普通の声で読むのが半角の英数字だったりするわけですね。で大文字だとピッチを変えるとか、ま、その気になれば多分全角の文字を低くするとかできるんでしょうけれども、それがまあ一つの限界になってるとかいうところもあって。そのカスタマイズできるところはその活用方法、できないところもその、ここまでできるんだったらもっとここもカスタマイズしたいねとか、そういうところをもっとこう充実させていけるといいのかなっていう風に最近開発とサポートとユーザーとしての立場とひっくるめて考えるところですかね。
〈石川〉ありがとうございます。えっと、私は例えばワードなんかの文書で、見え消し版の文書、つまり、編集が入ってコメントが入ってたりするもの。一応、それは読み…ここから挿入とか、ここから削除っていう風に入るんですけど、ま、音声にせよ点字にせよ、それを決して効率的に作業できるかって言われると、結局1回全部そういうのを消して溶け込み版にして、あるいは一時的に溶け込み版であるかのようにしてマスキングして、編集情報を手で読んでまた直すとかっていう風にしないと、頭の中でそういった追加的な情報があまりにも多すぎると、思考がやっぱり中断されるし疲労するし。もっとなんかないかなっていう風に考え、感じたりはしています。
だからまぁ、スクリーンリーダーは音声と点字で情報を提示するんだけども、その音声情報っていうのは片っ端から揮発していくっていう特性があって、記憶のバッファーにあんまり負担をかけないで、且つ、音声で情報を提示するのにはどうしたらいいのとか。そういったようなことなどは、ま、テーマかなという風に思ってます。
スクリーンリーダーがAI 化することによって、アクセシブルでないアプリケーションとかウェブサイトでもそんなに苦にせずに読んでくれたり操作できたりするようになると思うんですけどで、それは元々アクセシビリティっていうのは、共同作業として実現するっていうことでずっとやってきたはずで、それとその話は、スクリーダーが全部、あるいはAIが全部吸収するので環境障壁を取り除く努力はしなくても大丈夫だ、みたいな風潮になったりするのもどうなのかなっていう。それだけの問題じゃなくて、様々な日常生活の中でその障壁を取り除くっていうその中の一環として、デジタルアクセシビリティもあるので。なんかちょっとジレンマを感じたりもする…。別に回答があるわけではないんですけど、そうは言ってもやっぱりエージェント機能とか、例えば画像認証を求められた時に、それをアクセシビリティを考慮してないものであってもスクリーンリーダーがなんとかするっていう方が現実には助かるわけなんですけど、ま、そういうあの共同作業的な観点っていうか、もちょっと考えたいなと思って。
アクセシビリティの例として、階段、あるいは段差に直面して立ち往生する車いすの障害者のイラストをよく使って説明するんですけど、で、それで段差を解消するっていうのは、社会をアクセシブルにしていくっていうことだと。なので、ありますよっていう風に説明するんですけど。個人モデルっていう方は、ま、リハビリとかね、義足で登れるようにしましょうとか、あるいは、階段を昇降できる電動車いすをその人が使えるようにしましょう、開発してっていう、なんかこう、階段を昇降できる電動車いすイコールAIでパワードされたスクリーンリーダーていうイメージかな、っていう気がしていて。まぁでも、あればあった方がいいに決まってるんだけど、もしかしたらマクロに見るとそれはその、対応性とか、環境障壁を減らしていくっていう方向性に逆行する面もないわけではないのかなっていう風に、まあまあ思ったりはしています、という、はい。私もそういう懸念は感じてます。
大体時間となったようなんですけれども、ま、もしどうしても短く一言という方がいらっしゃれば…。大丈夫ですかね。はい。ということで本日はこのフォーラムにご出席ありがとうございました。皆様にご協力いただきまして、非常に有意義な、対話の場となったと思います。今後また開発30周年記念と私が元気であるかどうかちょっと不透明ですけれどもはい、またやりたいと思いますので、よろしくお願いします。どうもありがとうございました。