1.0UX TIMEShttps://uxdaystokyo.com/articles高橋 祐哉https://uxdaystokyo.com/articles/author/yuya-takahashi/rich600338<blockquote class="wp-embedded-content" data-secret="0Z307a3bwp"><a href="https://uxdaystokyo.com/articles/ux-for-ai-report/">ただの「AIツール使い」でなく「AIを設計する側」に回るための必須知識：「UX for AI」ワークショップレポート</a></blockquote><iframe sandbox="allow-scripts" security="restricted" src="https://uxdaystokyo.com/articles/ux-for-ai-report/embed/#?secret=0Z307a3bwp" width="600" height="338" title="“ただの「AIツール使い」でなく「AIを設計する側」に回るための必須知識：「UX for AI」ワークショップレポート” — UX TIMES" data-secret="0Z307a3bwp" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" class="wp-embedded-content"></iframe><script> /*! This file is auto-generated */ !function(d,l){"use strict";l.querySelector&&d.addEventListener&&"undefined"!=typeof URL&&(d.wp=d.wp||{},d.wp.receiveEmbedMessage||(d.wp.receiveEmbedMessage=function(e){var t=e.data;if((t||t.secret||t.message||t.value)&&!/[^a-zA-Z0-9]/.test(t.secret)){for(var s,r,n,a=l.querySelectorAll('iframe[data-secret="'+t.secret+'"]'),o=l.querySelectorAll('blockquote[data-secret="'+t.secret+'"]'),c=new RegExp("^https?:$","i"),i=0;i<o.length;i++)o[i].style.display="none";for(i=0;i<a.length;i++)s=a[i],e.source===s.contentWindow&&(s.removeAttribute("style"),"height"===t.message?(1e3<(r=parseInt(t.value,10))?r=1e3:~~r<200&&(r=200),s.height=r):"link"===t.message&&(r=new URL(s.getAttribute("src")),n=new URL(t.value),c.test(n.protocol))&&n.host===r.host&&l.activeElement===s&&(d.top.location.href=t.value))}},d.addEventListener("message",d.wp.receiveEmbedMessage,!1),l.addEventListener("DOMContentLoaded",function(){for(var e,t,s=l.querySelectorAll("iframe.wp-embedded-content"),r=0;r<s.length;r++)(t=(e=s[r]).getAttribute("data-secret"))||(t=Math.random().toString(36).substring(2,12),e.src+="#?secret="+t,e.setAttribute("data-secret",t)),e.contentWindow.postMessage({message:"ready",secret:t},"*")},!1)))}(window,document); //# sourceURL=https://uxdaystokyo.com/articles/wp-includes/js/wp-embed.min.js </script> https://uxdaystokyo.com/articles/wp-content/uploads/2025/12/uxforaireport.png1280720UX DAYS TOKYOスタッフの高橋です。2025年11月15日に、グレッグヌーデルマン氏のワークショップに参加し、大きな学びがあったのでレポートします。 AIツールの潮流に溺れていた私 正直に言いますと、私はこれまで、GoogleやOpenAIから発表される最新ツールを追いかけ、それらを使いこなすことこそが「AI活用」だと思っていました。 新しいAIモデルが出るたびに触っては「すごい！」と感動する日々。そうして詳しくなれば、いつか自分も価値あるAIプロダクトが作れるようになると信じて疑いませんでした。 しかし、技術の進化スピードはあまりに速く、キャッチアップするだけで精一杯です。終わりのない情報収集に、私は「AI疲れ」を感じていました。 そんな時、現状を打破するきっかけとなったのが、UX DAYS TOKYOが主催したGreg Nudelman氏の「UX for AI」ワークショップでした。当初は「この流行に乗り遅れたくない」という焦りからの参加でしたが、頭をガツンと殴られるような衝撃を受けました 。私は「AIを活用する」ということの意味を、まったく理解していなかったのです。 AIを知ろうともせず、使いこなそうとしてた自分 参加申し込み後、運営の大本さんから「予習しておかないと、当日は何もわからずに終わるよ！」とアドバイスをいただき、事前の勉強会に参加させていただくことになりました。ただ、AIツールはいくつか使っていたし、予備知識は持っている自負がありました。 しかし、事前勉強会のなかで、私は大本さんから衝撃的な事実を教わります。 「AIは、確率で動いている」 それまで私は、AIをもっと高次元で完璧な論理で動く「魔法の箱」のように捉えていました。しかし実際は、膨大なデータから「次に来る言葉としてもっともらしいもの」を確率的に選んでいるに過ぎません。 自分は、AIは難しく分からないものと思い込み、AIの仕組みを全くよく知らずにAIを使いこなそうとしていたことに気づきました。そして、ワークショップにおいても、このAIの仕組みを考慮せず、「魔法の箱」と捉えると失敗するということを知りました。 AIプロジェクトは85%失敗している ワークショップ当日、講師のGreg氏はこう切り出しました。  「世の中のAIプロジェクトの約85%は失敗に終わっている」 多くの企業が、AIの特性を理解しないまま「魔法の箱」を期待し、巨額の資金を投じて失敗しています。Greg氏が指摘した失敗の典型例は以下の通りです。 「なんでもできる」を目指した結果、特定の課題解決につながらず、誰にも使われないものになる もっともらしい嘘（ハルシネーション）や、偏見・差別的な回答をするリスクを考慮していない AIは万能ではありません。PdMやデザイナーにとってより重要なのは、「AIが魔法ではなく、使われないリスクや間違えることによるビジネス損失」を見積もることです。 従来のシステム開発と異なり、確率で動くAIに「100%の精度」は保証できません。だからこそ、「ユーザーやビジネスにどれだけの利益と損失があるか」を事前に計算して設計しなければ、プロダクトは成立しないのです。 今までと全然違う！成功するためのAIプロダクトの作り方 多くの失敗プロジェクトは、この利益と損失を考慮せず、「精度が上がれば収益を見越せる」と見切り発車してしまっています。 そこで、利益と損失を冷静に分析するためにワークショップで学んだのが、「バリューマトリクス」というフレームワークです。 AIの不確実性を評価できる「バリューマトリクス」 AIプロダクトが成功するためには、一見凄そうな感覚だけでローンチしたり、投資したりせず、間違えるリスクも踏まえて、冷静に利益とコストを分析する必要があります。ワークショップでは、「バリューマトリクス」という画期的なフレームワークを教えてくれました。 バリューマトリクスは、AIが「真陽性」「真偽性」「偽陽性」「偽陰性」という四象限のいずれかにおいて、確率的に動作するという仕組みを前提に、それぞれの事象を定量的に評価するフレームワークです。ワークショップでは、鍋の吹きこぼれを検知するAIプロダクトを例に分かりやすく説明してくれました。 人間が鍋の火を見張らずに、自動で検知してくれたら便利そうに感じます。しかし、AIが間違える可能性を考慮した場合、どれだけリスクがあるのでしょうか。先ほどの四象限ごとに利益とコストを金額に置き換えてみます。 間違いには、「【偽陽性】吹きこぼれを誤検知する（実際は吹きこぼれない）」か、「【偽陰性】吹きこぼれたことを検知しなかった」の2つがありえます。仮に誤検知しても、火を弱めるという少ない作業コストと、火が弱まる（利益の減少）程度で済みますが、吹きこぼれてしまったとなると、ガスコンロを掃除するという大きな作業コストが発生します。 このように、一見便利そうなものでも、大きな損失やコストリスクを抱えていれば、ユーザーは使いません。利益という面でも、ユーザーが現状課題に費やしているコストが小さい場合は利益が大きくならないため、必要ないと判断されることもあります。（畑の水分量を予測するAIを作ったが、農家の人は足で踏むだけで予測できていた例） 面白いのは、このような評価はプロダクトによって全然異なる点です。例えば、私は採用面接の内容を要約するプロダクトを考えたのですが、面接で話していないことをAIが盛り込んでしまう偽陽性のケースは致命的になります。逆に面接で話されていたことが省略される偽陰性には大きなリスクはありません。 このような起こりうるケースごとの考え方は不確実なAIだからこそ必要であり、従来のアプリケーション開発とは全く異なる方法です。 理論だけでは学べないワークショップ「体験」の凄さ ワークショップでの最大の収穫は、理論だけではない「体験」でした。アイデア出しから始まり、検証を経て、実際にAIと対話しながらコードを書く手法（バイブコーディング）を用いて、1日でプロダクトを形にするプロセスを実践しました。ツールを使う側から設計する側になった瞬間でした。 ワークショップを受ける前は、なんでもかんでもAIで解決できるだろうと考えていましたが、今ではAIの良し悪しを判断し、設計に生かすことが出来る確信を持っています。この確信は、ひとりでGreg氏の書籍などを学んでいても掴めなかったと思います。 貴重な気づきと体験の場を企画してくださったUX DAYS TOKYOに、心から感謝したいと思います。ありがとうございました。