重度身体障害者は、AI時代に開発者になれるのか

先日、「バイブコーディングと当事者開発 ― LLM時代における障害者のソフトウェア開発参加の可能性 ―」という論文を発表しました。

タイトルだけ見ると、少し難しく感じるかもしれません。

「バイブコーディング」とは何か。
「当事者開発」とは何か。
なぜそれが障害者のソフトウェア開発参加と関係するのか。

この記事では、論文の内容を専門知識がない方にも伝わるように、できるだけ普通の言葉で説明します。

この論文で考えたかった問いは、とてもシンプルです。

重度の身体障害がある人は、AI時代にソフトウェアを「使う側」だけでなく、「作る側」になれるのか。

結論から言えば、私は「なれる」と考えています。

ただし、それは「AIがあれば障害がなくなる」という話ではありません。
そうではなく、AIによって「何をできる人が開発者なのか」という条件そのものが変わり始めている、という話です。

バイブコーディングとは何か

バイブコーディングとは、自然言語でAIに指示を出しながらソフトウェアを作る開発スタイルです。

従来のプログラミングでは、開発者はコードを一行ずつ書きます。変数名、関数名、括弧、セミコロン、インデント、エラー処理など、細かい構文を正確に扱う必要がありました。

しかし、バイブコーディングでは、たとえば次のようにAIに指示します。

ログイン画面を作って。
エラー文を日本語にして。
このボタンをもっと押しやすくして。
このエラーの原因を調べて修正して。

もちろん、これだけで必ず完璧なソフトウェアができるわけではありません。

AIが間違えることもあります。動かないコードを出すこともあります。セキュリティ上危ない実装を提案することもあります。だから、人間による確認、修正、テスト、レビューは必要です。

それでも大きく変わったことがあります。

ソフトウェア開発の入口が、「コードを手で書けること」から「作りたいものを言葉で説明できること」へ移り始めたのです。

これは、身体に制約のある人にとって、とても大きな変化です。

従来のプログラミングは、身体への要求が大きかった

プログラミングは、頭だけでする作業のように見られがちです。

しかし実際には、かなり身体的な作業でもあります。

キーボードを速く正確に打つ。
画面上のコードを読み続ける。
大量のエラーメッセージを確認する。
開発環境を操作する。
何時間も集中して作業する。

これらは、運動機能や視覚、認知的な処理に大きく依存しています。

たとえば、スイッチ入力やアイトラッキングを使っている人にとって、一文字ずつコードを書くことは非常に負荷が高い作業です。

print("hello world") のような短いコードであっても、入力方法によっては多くの操作と時間が必要になります。

まして、Webアプリケーションやデータ処理ツールのようなものを一から作るとなれば、従来の方法では非常に大きな壁がありました。

つまり、これまでのソフトウェア開発では、本人のアイデアやニーズがどれだけ明確でも、「コードを直接操作する身体能力」が参加条件になっていた面があります。

AIは「コードを書く身体」への依存を減らす

バイブコーディングが重要なのは、ここです。

AIに自然言語で指示できるようになると、開発者が直接コードを打つ量は大きく減ります。

もちろん、入力がゼロになるわけではありません。AIに指示を出す必要はあります。結果を確認する必要もあります。うまくいかなければ、別の言い方で修正を頼む必要もあります。

しかし、求められる入力の性質が変わります。

精密なプログラミング言語を一文字ずつ入力するのではなく、自然言語で「何をしたいか」「どこが違うか」「どう直したいか」を伝える作業になります。

これは、障害を「治す」ことではありません。

身体の状態は変わっていません。
手が速く動くようになるわけでもありません。
長時間キーボードを打てる身体になるわけでもありません。

変わるのは、ソフトウェア開発という作業の側です。

開発プロセスが、身体に求める条件を変え始めているのです。

「使う人が作る人になる」という転換

この論文で一番大事にしたかったのは、支援技術の話です。

支援技術、つまりAssistive Technologyは、障害のある人の生活や学習、仕事を助けるための技術です。

しかし、支援技術の開発では、長い間、障害当事者は主に「使う側」に置かれてきました。

もちろん、ユーザーテストに参加する、フィードバックを出す、共同設計に関わる、といった形で当事者が参加することはあります。それ自体はとても重要です。

ただ、それでも多くの場合、最終的に作る人は専門の開発者でした。

そこには、どうしても距離が生まれます。

開発者がどれだけ親身であっても、24時間365日その身体で生活している当事者が感じている細かな不便を、完全に理解することは難しい。

たとえば、

• ボタンの位置が少し遠いだけで疲労が増える

• エラーが出たときの表示が不安を強める

• 一見便利な機能が、実際の介助場面では使いにくい

• 「正しい予測」でも、自分の言葉としては違和感がある

こうした感覚は、仕様書やインタビューだけでは伝わりきらないことがあります。

だからこそ、当事者自身が「気づく → 作る → 試す → 直す」というサイクルを回せるようになることには、大きな意味があります。

AIは、当事者のニーズとソフトウェア開発の間にあった距離を縮める可能性があります。

それが、論文でいう「使う人が作る人になる」という転換です。

専門性がなくなるのではなく、専門性の場所が変わる

ここで誤解してほしくないのは、「AIがあるから専門性はもう不要」という話ではないことです。

むしろ、専門性は残ります。

ただし、その場所が変わります。

これまで重要だったのは、コードを直接書く力でした。

これから重要になるのは、

• 何を作るべきかを考える力

• 自分や他者のニーズを言語化する力

• AIの出力を見て、良いか悪いか判断する力

• 危険な実装や不十分な設計に気づく力

• 小さく作って試し、改善していく力

です。

コードを書く技術の一部はAIに委任できるようになりました。
しかし、「何が本当に必要か」を判断する力は、AIに丸投げできません。

特に支援技術の領域では、この判断力はとても重要です。

なぜなら、支援技術で最も価値のある知識の一つは、「実際の生活の中で何が困るのか」を知っていることだからです。

この知識は、当事者の生活経験の中にあります。

AI時代の開発では、その生活経験が、より直接的に開発の中心へ入ってくる可能性があります。

能力の再構成

論文の中では、この変化を「能力の再構成」と呼びました。

少し難しい言葉ですが、言いたいことはシンプルです。

これまでソフトウェア開発の能力は、次のようなものとして考えられてきました。

コードを書けること。
キーボードを速く打てること。
画面上の情報を素早く読み取れること。
開発環境を自在に操作できること。

しかし、AIと協働する開発では、能力の中心が少しずつ変わります。

何を作りたいかを構想する。
AIに意図を伝える。
出てきたものを評価する。
違うと思ったら方向を変える。
必要な人に届く形にする。

つまり、「コードを直接操作する能力」から、「AIと対話しながら目的を実現する能力」へと、開発能力の定義が移り始めています。

これは、障害のある人にとって非常に重要です。

なぜなら、従来は身体的な制約によって低く見積もられていた能力が、AIとの接続によって別の形で発揮される可能性があるからです。

「できないことができるようになる」というより、「できる／できないを決めていた条件が変わる」と言った方が近いかもしれません。

ただし、AIがすべてを解決するわけではない

もちろん、バイブコーディングには限界もあります。

第一に、AIを使うためには、インターネット環境、デバイス、利用料金が必要です。これは新しい格差を生む可能性があります。

第二に、AIが作ったコードには間違いや脆弱性が含まれることがあります。特に、個人情報や生活に関わる支援技術では、安全性の確認が欠かせません。

第三に、AIツール自体が十分にアクセシブルでない場合があります。スクリーンリーダーとの相性、キーボード操作、視覚的なUIへの依存など、ツール側にも課題があります。

第四に、今回の論文は主に重度身体障害、特に運動機能の制約を念頭に置いています。認知障害、学習障害、精神障害など、異なる障害のある人にとって、AIとの開発体験がどうなるかは、さらに検討が必要です。

だから、この記事で言いたいのは「AIがあれば大丈夫」という楽観論ではありません。

むしろ、AIによって新しい可能性が開く一方で、その可能性にアクセスできる人とできない人の差が生まれるかもしれない、ということも含めて考える必要があります。

では、何から始めればいいのか

論文では、障害のある当事者がバイブコーディングを始めるための段階的な方法も提案しました。

最初から大きなアプリを作る必要はありません。

まずは、チャット型のAIに小さなツールを作ってもらうところから始めればいいと思います。

たとえば、

• 文章を整えるツール

• 定型文を作るツール

• CSVや表を変換するツール

• 日々の記録を整理するツール

• 自分の入力しにくさを補う小さな補助ツール

などです。

最初の段階では、コードの中身を全部理解する必要はありません。

まずは「動くかどうか」を確認する。
次に「ここをこう変えて」と頼んでみる。
少しずつ、AIとのやり取りの仕方を覚える。

そうしていく中で、コードの構造や開発の考え方は、後から少しずつ身についていきます。

大事なのは、完璧に勉強してから作るのではなく、小さく作りながら学ぶことです。

EqualFrontiersとして考えていること

EqualFrontiersは、AIとアクセシビリティ、そして当事者の社会参加を重要なテーマにしています。

私たちが目指しているのは、障害のある人を単に「支援される側」に固定しないことです。

支援技術を使う。
AIを使う。
ソフトウェアを使う。

それだけでなく、

支援技術を作る。
AIを評価する。
ソフトウェア開発に参加する。
自分たちの生活を、自分たちの視点から設計し直す。

そういう方向へ進みたいと考えています。

今回の論文は、そのための理論的な土台の一つです。

障害当事者がAIを使って開発に参加することは、単に便利なツールを作れるという話にとどまりません。

それは、「誰が開発者になれるのか」「誰の知識が技術に反映されるのか」「誰が社会の設計に参加できるのか」という問いにつながっています。

おわりに

バイブコーディングによって、ソフトウェア開発の参入条件は変わり始めています。

これまで開発者に求められていたのは、コードを書く身体でした。

しかしこれからは、何を作りたいかを考え、AIに伝え、出てきたものを評価し、必要な形に近づけていく力が、より重要になります。

その変化は、重度身体障害のある人にとって、新しい参加の道を開く可能性があります。

もちろん、課題はあります。安全性、品質、費用、ツールのアクセシビリティ、教育機会など、考えるべきことは多くあります。

それでも、私はこの変化に大きな可能性を感じています。

障害のある人が、ソフトウェアを「使う側」だけでなく「作る側」になる。
自分の困りごとを、自分の言葉でAIに伝え、試し、直し、共有する。
その積み重ねが、これまでとは違う支援技術のあり方を作っていくかもしれません。

AI時代の開発者の条件は、すでに変わり始めています。

そしてその変化は、障害当事者が開発の中心に立つための、大きなチャンスでもあります。