Nielsen Norman Group最新研究：AI検索と従来検索の使い分け＋UXポストモーテム手法

Nielsen Norman Group（NN/g）の最新ニュースレターから、AI個人開発者に役立つ2つの研究知見を紹介する。

1. GenAI for Complex Questions, Search for Critical Facts

出典: Nielsen Norman Group — 2026年2月27日

調査の概要

NN/gは、ユーザーがAIチャットボット（ChatGPT、Gemini等）と従来の検索エンジンをどう使い分けているかを調査した。結果、両者は競合ではなく補完関係にあることが明らかになった。

ユーザーがAIを選ぶ場面

1. 探索的なタスク（何を探すかまだ分からない時）

従来の検索ではキーワードを事前に知っている必要がある。一方、AIは曖昧なプロンプトでも方向性を示してくれる。

「広いアイデアから始めて、AIモデルを使って具体化していく。『実際に何が欲しいのか？』を見つけるのに役立つ」

例：Kindleを購入したユーザーが「無料で本を読む方法」をChatGPTに質問。Libby、パブリックドメインサイト、Prime Readingなど6つの選択肢を得て、自分に合う方法を絞り込んだ。

2. 複数の制約を同時に処理する時

ゴルフ旅行の計画（3-4泊、4コース、1人1000ドル以下、特定地域）のような複合条件は、AIが得意とする領域。

「複数の制約がある時はChatGPTを使う。Google より3-4個の条件を同時に扱える」

3. 情報の集約・比較（レビューのまとめなど）

複数サイトのレビューを読む代わりに、AIに「このクルマの評判をまとめて」と依頼する。

「セールスパーソンと話しているようだけど、売り込みのプレッシャーがない」

4. ワーキングメモリの負荷軽減

情報を比較する際、AIに「表形式でメリット・デメリットをまとめて」と依頼すれば、自分でメモを取る必要がなくなる。

ユーザーが従来の検索を選ぶ場面

1. 検証が必要な時

AIの回答を得た後、従来の検索で事実確認するユーザーが多い。AIは「便利だが誤りがある」という認識が定着している。

「これがChatGPTの魅力が失われる瞬間だ」（誤った回答を発見した参加者）

2. 価格や重要な数値を確認する時

「実際の数字、具体的なデータの話になると懐疑的になる。これは自分に影響するから。AIでは必ず元のソースに戻って確認する」

3. ハイステークスな意思決定

20ドルのスマートホーム製品なら間違っても問題ない。だが高額なクルマを買う時は、AIだけに頼らない。

「健康系の情報は特に、大学や政府の医療サイトのような信頼できるソースを直接見たい」

引用（Citations）だけでは信頼問題は解決しない

AIツールが出典リンクを表示しても、「どの主張がどの出典に対応しているか」が分かりにくい。

「出典のないテキストが大量にある。それは上の出典からなのか、どこから来たのか分からない」

2. Project Postmortems for UX Teams

出典: Nielsen Norman Group — 2026年2月27日

ポストモーテムとは

完了したプロジェクトを分析し、何が起きたか、なぜ起きたか、どんなシステム変更が必要かを明らかにする手法。

「失敗したプロジェクトだけでなく、成功したプロジェクトにも実施すべき」

例えば、新しいチェックアウトフローがコンバージョンを15%上げる予測だったのに、実際は40%上がった。なぜ成功したかを理解すれば、意図的に再現できる。

スプリントレトロスペクティブとの違い

観点	レトロスペクティブ	ポストモーテム
タイミング	毎スプリント	プロジェクト完了後
視点	前向き（プロセス改善）	後ろ向き（結果分析）
焦点	チームのプロセス	特定プロジェクトの成果

両者は補完関係にあり、どちらも必要。

効果的なポストモーテムの構成要素

1. 適切な参加者（6-10人）

コアチームメンバー
プロダクトマネージャー
意思決定に関与したステークホルダー
外部視点を持つ関連チームの誰か（オプション）

2. 事前に定義された成功基準

成功の定義がないと、「5%の改善は良かったのか？」で議論が紛糾する。プロジェクト開始時に成功指標を定義しておくこと。

3. 心理的安全性

「個人を責めるのではなく、何が起きたかを理解し、システムを改善する場」

間違いが出てきた時の問いは「なぜこの人はミスしたか？」ではなく「なぜ我々のプロセスはこのミスを許したか？」

4. 根本原因分析（Five Whys）

問題: 新しいチェックアウトフローで離脱率が高かった

なぜ？ → 支払い情報ステップで混乱した
なぜ？ → 必須フィールドが分かりにくかった
なぜ？ → デザインで必須表示が見えにくかった
なぜ？ → コンポーネントライブラリのデフォルトをそのまま使った
なぜ？ → コンポーネントライブラリのドキュメントにアクセシビリティガイドラインがない

→ 解決策は「デザイナーがもっと注意する」ではなく、「コンポーネントライブラリのドキュメントを更新する」こと。

5. アクショナブルな成果物

❌ 悪い成果物:

「ステークホルダーともっとコミュニケーションを取る」
「リサーチ採用にもっと気をつける」
「これを二度と起こさない」

✅ 良い成果物:

「全ストラテジックプロジェクトで、リサーチフェーズ終了時にステークホルダーレビューゲートを追加」
「リサーチ採用チェックリストに、参加者資格確認ステップを追加」
「ローンチ前チェックリストに、エンジニアリングとのアナリティクス実装レビューを追加」

良い成果物はシステムを変更する。人の約束に頼らない。

6. オーナーと期限の明確化

アクション項目ごとにオーナーと期限を決め、月次でフォローアップする。

個人開発者への示唆

情報収集のワークフロー改善

探索段階 → AIを使って選択肢を洗い出す
具体化段階 → AIに複数条件を同時に伝えて絞り込む
検証段階 → 従来の検索で公式ソースを確認
価格・重要情報 → 必ず一次ソースで確認

一人プロジェクトのポストモーテム

ソロ開発でも、リリース後に振り返りを行う価値はある。

成功要因の特定: なぜ予想より良い結果が出たか？
Five Whysの自己適用: 失敗した時、なぜプロセスがそれを防げなかったか？
アクショナブルな改善: 「次は気をつける」ではなく、チェックリストやテンプレートを作る