こんにちは。スタッフでエンジニアの、かじしまです。
先日、「UX for AI」の読書会に参加しました。著者の
私はこれまでエンジニアとして、AI技術の検証やPoC（概念実証）を行い、新しいモデルやフレームワークの導入にも積極的に取り組んできました。
しかし、正直なところ「AIって本当にプロダクトの価値を高めているのだろうか？」という疑念をずっと持っていました。
AIプロジェクトが立ち上がっても、「何を作るべきか」が曖昧なまま進み、途中で立ち消えてしまう。
あるいは、AIを導入しても期待した精度や効果が得られず、最終的には人の手作業で補っている。
そんな現場を何度も見てきたからです。
「AIを活かす」とはどういうことなのか。
この本を通してようやく、その答えの輪郭が見えてきました。
AIを導入すること自体が目的ではなく、ユーザーの課題を深く理解し、その体験の中でAIが自然に価値を発揮する状態をデザインすること。
それが本当の“AIを活かす”ということなのだと気づかされました。
AIによって工数が減るだけではなく、ユーザーの満足や体験の質が確実に向上したとき、初めてAIはプロダクトの一部として「生きている」と言える。
この読書会は、その本質を考え直すきっかけになりました。
AIプロジェクトの85％が失敗する理由
書籍や読書会の中で特に印象的だったのは、「AIプロジェクトの85%以上が失敗している」という事実です。その主な原因は、UX設計やユースケース選定の誤りにあると分析されていました。
失敗しないAIプロジェクトには、他のプロジェクトと同様に「ユースケースの選定」が不可欠です。
書籍には、経験豊富な農家の仕事をAIで置き換えようとして失敗したケースが紹介されていました。
「畑に水やりのタイミングをAIで判断する」という提案でしたが、農家さんは長年の経験から「長靴で土を蹴れば分かる」と言います。経験豊富な自分たちにAIから水やりのタイミングを教わることは、屈辱的ですらあったそうです。実際に農家が求めていたのは「畑の中で水やりが不要なエリアを知り、水を節約したい」ということでした。
こうしたユースケースのズレが、AI導入の失敗を招いていたのです。
私は、業務のRPA化（自動化）に携わる中で「使う人に喜ばれる業務」とAIのユースケースには共通点があると気付きました。
ユースケースの選定に有効なストーリーボード
ユーザーが本当に解決したい課題を捉えたユースケース選定を誤らないためには、まずユーザーのコンテキストを知ることが不可欠です。
書籍ではストーリーボードを用いてユーザーの状況や本当に解決したい課題（Jobs To Be Done）を可視化する手法が紹介されていました。著者の言葉を借りると、「ただ描けばいいのではなく、価値を見える化することが重要」です。
「ユーザーのコンテキストを把握するためにストーリーボードを使う」という大本さんの言葉が印象的でした。また、「ストーリーボードは上手な絵を描く必要はなく、修正を繰り返すことが大切だ」という意見も心に残りました。
ストーリーボードという言葉は知っていましたが、何のために役立てるか納得することができました。
AIファーストには情報設計（IA）が不可欠
ストーリーボードによってユーザーのコンテキストや本当に解決したい課題を可視化することの重要性を学びましたが、それと同じくらい重要なのが「情報設計（IA）」です。
AIを導入したプロジェクトでは、どんなデータや知識を、どのコンテキストで使うのかという設計が成果を大きく左右します。
書籍では「AIファーストのUX設計」という考え方が紹介されていました。「AIファースト」と聞くと、AI以外を排除するような印象を持たれがちですが、実際にはAIを活用して人間の能力を拡張し、ユーザーに最適な情報や体験を届けることが目的です。
例えばECサイトのおすすめ商品ページでは、以下の違いがあります。
- IAがないAI（AIファーストでない設計）：無関係な提案が並び、ユーザーのニーズから外れてしまう
- IAがあるAI（AIファーストな設計）：ユーザーの「今日は何をしに来ましたか？」という目的を問いかけ、状況に合わせて必要な情報を適切に提示できる
さらに、「AIファーストIAの原則」として、以下の5つが挙げられていました。
私はこれまで「AIには大量のデータを学習させることが重要」と考えていましたが、それだけでは不十分なことに気づきました。
AIの力を引き出し、ユーザーにとって本当に価値ある体験を提供するには、ユーザー中心の設計や情報設計（IA）の原則を意識した情報設計を行うことが必要です。
実践的な手段も知ることができた
書籍には理論だけでなく、実践的な手段も多く記載されていました。特に印象に残ったのは、プロトタイプの改善を繰り返すRITEです。
RITEはRapid Iterative Testing and Evaluationの略で、ラフなプロトタイプでユーザーにとって有用な体験となっているかを検証し、素早く改善を繰り返す方法です。
また、書籍にはOpen AI社のユーザビリティテスト不要説について言及されていました。私は「ユーザビリティテストがなくなってしまうのか」と解釈してしまいましたが、読書会での議論で、ユーザビリティテストの存在を否定するのではなく、ラフなプロトタイプを使ってユーザビリティテストを行い、すぐに改善策を出すということだと理解しました。読書会に参加していなかったら、間違えた解釈のままでいるところでした。
RITEは綺麗なプロトタイプや詳細なレポートを作ることが目的ではなく、実際にAIから出力される情報を使って素早く修正を繰り返していくこと、プロトタイプを通じて「本当に解くべき問題は何か？」という問いに答える姿勢が大切です。
AIプロジェクトにもUX設計が不可欠
今回の読書会を通じて、AIプロジェクトにもUX設計が不可欠であることを改めて習得しました。
書籍によるとAIプロジェクト失敗理由の第1位は「ユーザーにとって需要がない」ことだそうです。成功の鍵は、技術ありきではなく、ユーザーや現場の課題を把握し、ユースケース選定や情報設計を丁寧に行うことだと気づきました。
また、「好きな技術を使ってみたい」という自己満足に陥ることは、「プロダクトマネジメント領域で指摘されるビルドトラップと同じマインドセットだ」という参加者の言葉も印象に残っています。
新しい技術や手法については、よく分かっていないものも多くあり、手当たり次第に調べてみたくなります。だからこそ、現場の課題やニーズを見極め、最適なものを選び、ユーザーや組織にとって価値ある成果につなげることが重要だと感じました。
今後も、ユーザー中心の視点と広いアンテナを持ち、技術とデザインの両面から学びを深めていきたいと思います。
