powered by TechFeed
表示モード
Deep Dive

「とりあえずAI搭載」が製品を壊す — いつAIを入れるべきか、デザインの現場が示す判断軸

11月11日、IEEE Spectrumが「When Does It Actually Make Sense to Put AI Into Products?」と題した記事を公開した。フライパンから煙が上がった瞬間、ユーザーは存在しないノブに手を伸ばし、「弱めて」と2回叫んだあとで鍋をコンロから下ろした——AIが応答するより先に。これはKunovskyがAI搭載IHクッキングヒーターの開発支援中に目撃した場面だが、「とりあえずAI」の失敗がいかに具体的かを象徴している。サンフランシスコのデザインコンサルティング会社Ideoでインダストリアルプロダクトデザインチームを率いるSavannah Kunovskyに、IEEE SpectrumがAI統合の「正しい判断軸」を掘り下げたインタビューだ。

11月11日、IEEE Spectrumが「When Does It Actually Make Sense to Put AI Into Products?」と題した記事を公開した。フライパンから煙が上がった瞬間、ユーザーは存在しないノブに手を伸ばし、「弱めて」と2回叫んだあとで鍋をコンロから下ろした——AIが応答するより先に。これはKunovskyがAI搭載IHクッキングヒーターの開発支援中に目撃した場面だが、「とりあえずAI」の失敗がいかに具体的かを象徴している。サンフランシスコのデザインコンサルティング会社Ideoでインダストリアルプロダクトデザインチームを率いるSavannah Kunovskyに、IEEE SpectrumがAI統合の「正しい判断軸」を掘り下げたインタビューだ。


「とりあえずAI」が製品を壊す

Kunovskyが最初に指摘するのは、AIを入れる動機の問題だ。「CEOが次の決算発表前に取締役会に"AI戦略"を約束してしまった」「競合がAI搭載版を出した」といったプレッシャーで、チームがAI統合を進めるケースが多いという。

AIが既存の仕組みを破壊した典型例として、Kunovskyはいくつかの事例を挙げる。

  • **Humane AI Pin**:スクリーンを持たないウェアラブル端末で、スマートフォンの代替を目指したが、ユーザーが慣れ親しんだインターフェースを捨てさせる代わりに提供したのは「より遅く、信頼性の低い」操作体験だった。
  • 車のタッチスクリーン化:音量や空調のコントロールが物理ボタンからタッチスクリーンや音声メニューに移行した結果、以前は感覚だけで操作できた動作に、目線を道路から外す必要が生じた。欧州の自動車安全評価プログラムEuro NCAPが物理コントロールを再評価しているのはその反映だ。

そして冒頭で触れたIHクッキングヒーターの事例に戻る。AIに調理内容を伝えると火力を自動管理する設計だったが、緊急時にユーザーが取る行動は「叫ぶ→AIの応答を待つ」ではなく「手を伸ばす→鍋を退かす」だった。「瞬時に、感覚で、ストレス下でやらなければならない操作は、物理的に保つべき」というのがKunovskyの結論で、ノブは結局残すことになった。

「良いAI統合」の判断フレーム

Kunovskyが提示する判断軸はシンプルだ。「その機能は、ユーザーがやろうとしていることを助けるか?」。これはAI固有の問いではなく、すべてのプロダクト設計に通じる基準だと彼女は言う。

また、AIの実装手段をLLM(大規模言語モデル)に限定しないことも重要と強調する。コンピュータビジョン、センサーフュージョン、オンデバイスモデルなど、タスクに合った技術を選ぶことが、AIを使うか否かの判断と同じくらい重要だ。

アクセシビリティ分野はKunovskyが最も可能性を評価する領域だ。補聴器がうるさいレストランで聞きたい声だけを拾うAI機能、視覚障害者がスマートフォンのカメラを向けると周囲の状況を音声で伝えるBe My Eyes、リアルタイム通訳イヤホンなど、いずれも「人間を体験の中心に置いたまま、知覚・理解・行動を拡張する」設計になっている。

非決定論的AIとプロダクト定義の変化

生成AIは同じ入力に対して毎回異なる出力を返す。これは従来のソフトウェア開発の手法を根本から変える。

従来のプロダクト開発は「仕様を書き、その通りに動くかテストする」という決定論的なサイクルで成立していた。しかし生成AIを組み込む場合、出力は確率的であり、すべての挙動を仕様として列挙することは原理的にできない。Kunovskyによれば、このためプロダクト定義は「システムが動いて良い空間を定義する」ことにシフトする。

具体的には、「AI evaluations」(モデルの出力品質を継続的に評価するための基準・テストスイート)と「AI constitutions」(モデルの挙動を導くために書かれた原則・ガイドライン)が、LLMを使う製品における新しい形のプロダクト定義になりつつあるという。従来の仕様書や受け入れテストに相当する役割を、これらが担うイメージだ。チームがAIを「制御」するのではなく「方向付ける」という発想の転換が求められる。

人間による上書きは「オプション」ではなく「必須」

AIシステムへの手動介入経路は、非常時のボタン一つではなく、操作の取り消し、提案の編集、機能のオフといった日常的な粒度で提供される必要がある。

Ideoが開発に関わった教育ツールEthiqlyでは、AIが生徒にフィードバックを返す前に、必ず教師が内容を承認するステップを設けている。「ユーザーがいつでも制御を取り戻せると知っているとき、AIに任せることへの抵抗感が大幅に下がる」とKunovskyは述べる。AIへの信頼はシステムの性能だけでなく、制御可能性の設計によって醸成されるという視点は、今後のプロダクト設計に広く応用できる原則だ。


詳細はWhen Does It Actually Make Sense to Put AI Into Products?を参照していただきたい。