2026-07-06

「AI」と対比するときの「人間」という呼び方が気になる

仕事をしていて「人間」という言葉を使う機会が、ここ1年ほどで急激に増えた。もちろん、ほとんどの場合は「AI」と対比する形で使っている。

これまで、「人間」を意識していなかったわけではない。むしろそこに関してはUIデザイナーとして常に向き合ってきた。しかしその「人間」とは「ユーザー」であって、「人間」と呼ぶことはほとんど無かった。それどころか、個別の「ユーザー」のことをよく知り、敬意をもつべきものとされてきたはずだ。

ユーザーだけではない。開発者もそうだ。AIを開発者がどう利用するかを考えているときには、やはり「AI」と「人間」が対比される。エンジニアとかデザイナーとかPMとかではなく、そこでは「人間」と呼ばれる傾向があるように思う。

「AI」と対比するときの「人間」という呼び方は、生物の「種（しゅ）」のように感じる。

AIを活用したプロセスを組むなりサービスを構築するなりするとき、どうしても「AIが得意（可能）で人間が不得意（不可能）なこと」「AIが不得意（不可能）で人間が得意（可能）なこと」がそれぞれ何なのかというところに注目してしまう。そして「AIにはこれをやってもらおう」「人間にはこれをやってもらおう」という話になっていく。そのとき、個別の「人間」には目を向けづらい。

こういうとき、同じ文化や社会を共有する存在として「人間」を見るのではなく、超越した存在の視点から、「人間」と「AI」の駒を配置する話をしているように感じてしまう。ひとりひとりの「人間」が、親から生まれ育ち、教育を受け、社会や文化を構成している、人格をもつ存在であるという認識が抜けていないだろうか、自分がそういう言い方をするときにそう思われてしまわないだろうか、と不安になる。

AIは人間とは違う。どこからか集めてきたデータを大量の計算機資源で学習し、膨大な知識をもとに判断を下すことができ、チャットでは人格があるように振る舞っている。しかし、その人格は模倣であるし、社会を構成しているわけでも文化の担い手であるわけでもない。

「人間」のあり方が、AIのあり方に引っ張られてしまっていないだろうか。あるいは、「人間」に対してAIのような存在であることを求めてしまっていないだろうか。ひとりの人間として、AIを使いつつも、ひとりひとりの人間には敬意をもって向きあっていきたい。

2026-06-09

思考slop

AIの出現で、10倍とか100倍とかそういうスピードでモノが作られる、それに合わせて10倍とか100倍のスピードでモノゴトが進むようになった。そういうところで働いていると、自分の頭をAIに合わせて高速化する必要があるような気がしてしまう。自分自身がAIを使って速く仕事をするようになるだけでなく、同僚先輩後輩部下上司すべてが高速化している。周囲で生成されていくモノの多さ、それを使って進んでいくモノゴトの速さにもついていかなければならない。

最近、その速さがメンタルに与える影響が不安になってきている。というより、たぶん自分のメンタルの状態がその影響を受けてかなり変化してしまった。早朝に目が覚めると、そのまま脳みそが活発に働きだして、いろいろなことを考えはじめてしまう。なので、朝4時とか5時とかまだ起きなくていい時間帯に目が覚めて、そのまま眠れなくなってしまうということが増えた。

今だってそう。この記事はそういうタイミングで考えたことをリアルタイムに書いている。

AIでモノゴトが速く進むようになるのは、たぶん脳みそにとってかなり刺激的なことなのだろう。ヒートアップした脳みそがその興奮を忘れられぬまま、刺激を求めて起きた直後の早朝から動いてしまっているのではないかと思う。

これは科学的な裏付けのある話ではない。あくまで自分にいま起きていることはこうなのだろうという話だ。

あの、AI驚き屋と呼ばれる人たちの中にもそういう状態の人がいたのではないだろうか。すごいことをできるAIが次々と登場する。その刺激と興奮が忘れられなくて、もはやAIの何かが登場するだけで興奮できてしまう。そういうふうに脳みそが変わってしまったことが「驚き屋」のやたらハイテンションな投稿の文面に反映されていたのではないだろうか。

繰り返して言う。これは科学的な裏付けもなければ、本当にただの憶測である。

AIによる低品質で大量な生成物を「AI Slop」と呼ぶらしい。であれば、いまの自分の脳みそは次から次へと考えが浮かんでは消える、「思考slop」みたいな状態になっている。眠ろうと思っても次々あれこれと考えてしまって休まらない。思考が休まらないので身体も休まらない。そんな状態にある。人間の脳は無意識下で常にいろんなことを思い浮かべているという話を聞いたことがあるが、その思い浮かんだものが次々と意識される状態になっているのかもしれない。そうやって次々考えてしまうことに、脳みそが興奮してしまっている状態なのではないか。

自分自身のことを第一に案ずるべきなのだが、こういった健康被害が、これからどんどんいろいろな人に顕在化してくるのではないだろうか。あるいは自分のように既にそうなっている人がそれなりにいるのではないだろうか。この先生きのこるにはどうすればよいのだろうか。ひとまず記事を公開したらもう一回ベッドに入ってみます。おやすみなさい。

2026-06-07

モーダルダイアログの外のライブリージョンの更新を、スクリーンリーダーは読み上げるのか

最近、スクリーンリーダーのユーザーとWebサービスの画面の動作確認をしていて、興味深い挙動の違いを発見したので書き留めておきます。この情報は初心者向けのものではありません。

これを発見したのは、（<dialog> 要素を使わず） aria-modal="true" によって表現されたモーダルダイアログが表示されている状態を動作確認したときでした。その画面の構造を模式的に表現すると以下のようになります。

<div aria-modal="true" role="dialog">
  ここがモーダルダイアログで、いろいろ操作できる
</div>

<div aria-live="assertive">
  ここがライブリージョンになっていて、ダイアログ内の操作へのフィードバックが記載される
</div>

ライブリージョンの部分はいわゆる visually-hidden や sr-only のような、視覚的に見えないがスクリーンリーダーからは知覚できるようなスタイルが与えられていました。つまり、ライブリージョンの内容はほぼ完全にスクリーンリーダーのためのものということになります。

NVDAを使うスクリーンリーダーのユーザーは、問題なく操作できたと報告していました。ところが自分がmacOSのVoiceOverを使いながら試すと、フィードバックが一切なく非常に操作がしづらいように思えました。そしてまた、Accessibility Visualizerでもやはり、ライブリージョンによるフィードバックのようなものが見られない状態になっていました。しかしNVDAのユーザーはフィードバックがあったというのです。

そこから調べた感じだと、どうやら、VoiceOverが、aria-modal="true" の外のライブリージョンの更新を無視してしまう挙動になっているようです。そしてNVDAはそうではないようです。

私はaria-modal="true" によってその外のライブリージョンの更新は無視されるものと思いこんでいて、Accessibility Visualizerもそういう実装をしていました。5年くらい前にそういう報告を受けて、社内ライブラリを修正したりしたのを覚えています。

あらためて、いろいろとAIに聞いたりしてみると、2022年に「Should <dialog> or element with aria-modal cause live regions outside of the dialogs to be ignored? (#1854)（<dialog>や aria-modalを持つ要素は、ダイアログの外のライブリージョンを無視するべきか？）」というIssueがW3Cのariaリポジトリに立てられていたようです。

その冒頭には、以下のように書かれています。

There is a relatively recent bug in Chromium where if a focus is inside of a dialog or an element with aria-modal, live regions are being ignored.

比較的最近のChromiumのバグで、ダイアログ内または aria-modal をもつ要素にフォーカスがあるとき、ライブリージョンが無視されてしまう

この「Chromiumのバグ」はVoiceOverでのみ発生すると報告されています。添付されているサンプルは、現在手元にあるmacのVoiceOverとSafariの組み合わせでも、CodeSandboxのプレビューパネルでは報告通りの挙動をします。ところが、プレビューを新しいウィンドウで開くと、モーダルダイアログが開いているあいだ数字の読み上げが止ってしまいます。Chromeでは、CodeSandboxのエディターの画面でも、報告通りの挙動をします。Safariの挙動はCodeSandboxのエディターに使われている <iframe> 要素が影響しているのかもしれませんが、むしろ「 aria-modal="true" の外のライブリージョンを無視する」という挙動はChromeのほうが一貫しているようにすら思えます。

どうやら、この2022年のIssueにおいても、そして2026年現在においても、VoiceOverだけが aria-modal="true" の外のライブリージョンを読み上げない状況にあるようです。ちなみに、iOSのVoiceOverも同じ挙動をするようです。

ところで、<dialog> 要素はというと、こちらは状況が異なります。<dialog> 要素を showModal() でモーダルダイアログとして使用した場合には、<dialog> 要素以外の部分はアクセシビリティツリーから除外されます。そのため、NVDAでもVoiceOverでも、ダイアログの外のライブリージョンは存在しないものとして扱われ、特に読み上げられたりはしません。

モーダルダイアログ以外のものがアクセシビリティツリーから除外されているという状況は、aria-modal の普及以前に使われていたテクニックが思い出されます。ダイアログ以外のあらゆるものを aria-hidden="true" にするというものです。

このあたりの挙動を確認するための項目を、Accessibility Visualizer用のテストページに用意してあります。Accessibility Visualizerで、どの挙動にあわせたものを提供するべきかは検討中です。

この記事のmacOS VoiceOverの動作確認には macOS Tahoe 26.5.1を、iOS VoiceOverの動作確認にはiOS 26.5を、NVDAの動作確認にはNVDA日本語版2026.1.1jp (2026.1.1.4283) を使用しています。