- 全員が同じ画面を見ていると、新しい利用者は戸惑い、慣れた利用者はもう知っている説明にうんざりします。
- 利用者に合わせて画面を変えるのは確かに効果があります。ただし、なぜその表示になっているのかを説明でき、利用者がオフにできることが条件です。
- 越えてはいけない線ははっきりしています。画面を変えてよいのは利用者が作業をやり遂げやすくするためで、購入へ誘導するためではありません。
従来のWebサイトやアプリの限界
よい店は、初めての客と常連客とで話し方を変えます。初めての客は案内を求め、常連客は手早さを求めるからです。ところが多くのアプリは、全員に同じ画面を見せています。その結果、初めての人は戸惑い、慣れた人はいら立ちます。
全員に同じ流れ（Flow）を使わせるアプリは、作る側には簡単でも、使う側には難しいものです。初心者には案内が、熟練者には近道が、リスクのあるケースには追加の確認手順が必要です。
誰にでも同じWebサイトやアプリは、システムを自分の役割に合わせて読み替える手間を利用者に押しつけます。新入社員はずらりと並んだメニューに向き合い、いつもの利用者は毎回同じ説明を読まされます。言語、視力、端末に制約のある顧客は、自分向けに設計されていない利用の流れ（ジャーニー）で行き詰まるかもしれません。従来のパーソナライズで変わるのは、たいていバナーやおすすめ商品だけです。
アダプティブなAIプロダクト（Adaptive AI Product）はさらに踏み込み、手順の順番、ステップ、説明、手助けを状況に合わせて調整します。ただし、プロダクトを覚えやすく予測しやすい状態に保つには、調整の範囲を決めておく必要があります。利用者は、何がなぜ調整されたのかを知り、システムが覚えている内容を修正でき、いつでも標準の画面に戻れるべきです。
| 従来の形 | 新しい世代のAIプロダクト |
|---|---|
| あらかじめセグメントを分け、決まった数か所のコンテンツを差し替える | いまの状況（コンテキスト）に応じて、説明、ツール、自動化の度合いを動的に選び、その調整を利用者が確認・操作できるようにする |
アダプティブなプロダクトでは、イベント、プロフィール、ルール、フィーチャーフラグをつなぎ、どんなときでも動くデフォルトを用意します。AIは適切な手助けを選ぶのを手伝いますが、権限、価格、中核となる要素は、予測できるルールのもとに置きます。
ビジネスに使える新しい機能
利用者に合わせた正しい調整とは、その人が使い始めたばかりなのか、もう使い慣れているのかに合わせて、順番と説明を変えることです。そのうえで、なぜこの表示なのかをいつでも説明でき、利用者がいつでも全体表示に戻せるようにします。
プロジェクトの形
システムにはまず、誰でも作業を終えられる基本の流れ（Core Journey）があり、そのうえで状況に応じて手助けを増やしたり減らしたりします。初心者向けのオンボーディング、熟練者向けの簡略画面、業種に合わせた説明などです。重要なボタンの位置を頻繁に動かすのは避け、調整は手間がはっきり減る箇所に絞ります。
考えられる機能
機能としては、利用者に合わせたオンボーディング、入力内容で変わるフォーム、状況に応じたヘルプ、次に取るべき行動の提案（Next-best Action）、役割別のワークスペース、好みの記憶、アクセシビリティモード、リセットや「なぜこの表示か」を示すUIなどが考えられます。利用者は、システムが覚えている情報を確認・管理でき、不要な調整を断れなければなりません。
技術とデータ
データ層には、イベントトラッキング、利用者・プロフィールのデータストア、フィーチャーフラグ、同意管理などが含まれます。ルールとモデルを組み合わせて表示のバリエーションを選び、実験基盤（Experimentation Platform）で効果を測ります。重要な機能には、AIが停止したとき、新しい利用者のデータがまだ少ないとき、利用者が記憶されることに同意しないときでも動くデフォルトが必要です。
効果と取り組む理由
新しい利用者は早く覚え、慣れた利用者は少ない手順で作業を終えられます。サポートチームには、役割に合わない画面が原因の質問が来にくくなります。企業は、別々のバージョンをいくつも作らずに、実際の行動をもとに体験を改善できます。ただし、価値が見えるのは、タスクの成功率（Task Success）や利用者の理解度を測ったときです。アプリの利用時間やクリック数だけでは見えてきません。
- 段階的なガイド（Progressive Guidance）が、習熟度に応じて説明の量を変える
- 状況に応じたツール群（Dynamic Toolset）が、いまの状態と権限に合った操作だけを表示する
- 生成UI（Generative UI）が作業に合ったデータ構造やサマリーを作り、制約のないレイアウトを手当たり次第に生成することはない
- 好みの管理（Preference Control）で、利用者が記憶された内容を修正し、デフォルトに戻せる
架空のケース
具体的な利用場面
旅行計画アプリでは、初心者には案内のための質問と詳しい説明を表示します。常連の利用者は目的を短く伝えるだけで、編集できる計画を受け取れます。移動に制約のある家族には、確認の手順を1つ追加します。
もう1つの架空のケースでは、プロジェクト管理のWebアプリケーションを、経営者、マネージャー、新入社員が使っています。経営者には例外と判断待ちの事項が、マネージャーには作業キューと依存関係が見え、新入社員には一歩ずつの案内が表示されます。全員が同じレコードを使い、表示を切り替えることもできます。
利用者が提案を何度も断ったり、前の画面に戻ったりする場合、システムは調整の度合いを下げ、黙って結論を出すかわりに何をしたいのかを尋ねます。まだデータのない新しい利用者には、チームが設計したデフォルトの流れ（Default Journey）を使います。年齢、端末、場所といった、単独では誤りかねないシグナルから役割を推測することはしません。
Adaptation Budget
システムが調整してよいもの、固定しておくもの、利用者が元に戻す方法を決めます。
ナビゲーションや重要な操作を調整する前に、まずコンテンツと案内から始めます。
範囲、リスク、効果の測り方
開発チーム向け · 技術指標
パーソナライズは、利用者を特定の方向へ誘導したり、フィルターバブルを生んだりするおそれがあります。価格、権限、契約上の約束に関わる部分を、開示しないまま調整することは禁止すべきです。Task Completion、Error、Undo、Help Request、User Control、グループ間の結果の差を測り、実験によってAccessibilityが下がっていないかも確かめます。
パーソナライズはフィルターバブルを生んだり、体験を予測しにくくしたりすることがあります。そのため、デフォルト、説明、プライバシーへの配慮、アクセシビリティのテストが必要です。
開発チーム向け · 技術指標
追跡すべき指標：Task Success by Segment、Time-to-Proficiency、Preference Correction、Accessibility Error、Retention
- Discover：実際の業務を追い、通常のケースと例外の実例を集めます。
- Assist：人が主導権を持ったまま、AIに下書きや提案をさせます。
- Act：テストセットに合格してから、ツールを1つずつ使えるようにします。
- Scale：監視、フォールバック、コスト管理、責任者がそろってから範囲を広げます。
やり直し（Undo）やヘルプの依頼が増えたとき、一部の利用者グループで作業の完了率が下がったとき、サポートチームが利用者に画面を説明できなくなったときは、調整を控えめにします。どのバリエーションも、基本の流れ（Core Journey）を壊さずにオフにできなければなりません。
BUSINESS & PRODUCT READINESS
よいパーソナライズは説明でき、利用者が操作でき、プロダクトを予測不能にしない
コンテキストマップ（Context Map）を作り、利用者が自分で伝えた情報、観察した行動、システムが推測した内容を分けます。種類ごとに、同意の取り方、保存期間、確信度が異なるからです。影響を抑えるため、ナビゲーションや操作より先に、案内とコンテンツの調整から始めます。
開発チーム向け · 技術指標
Default Experienceと、元の設定に戻す方法を決めます。セグメントをまたいだテスト、Accessibilityのテスト、データがまだないときのCold Startのテストを行います。Preference Correctionも測ります。利用者がシステムを頻繁に修正しなければならないなら、パーソナライズが余計な手間を生んでいるサインだからです。
コンテキストマップでは、利用者が自分で伝えたデータ、観察できるデータ、システムが推測したデータを分け、それぞれの保存期間と保存する理由を決めます。次に調整の上限（Adaptation Budget）を設け、1つの流れの中で変えてよい箇所の数を制限します。そうすればプロダクトの見慣れた感じが保たれ、テストの負担も抑えられます。
開発チーム向け · 技術指標
アダプティブなルールにはそれぞれ、Owner、Hypothesis、Metric、Default、Rollbackを決めておきます。最初は、オンボーディングや長いフォームのように、利用者がつまずいている証拠がある場面を1つか2つ選びます。いきなりアプリ全体を変えてはいけません。どの部分が効果を生み、どの部分が混乱を招いたのか、区別がつかなくなります。
システムは何を調整できるか
利用者に理由が見えるか
記憶はいつ期限切れになるか
デフォルトは今も完全に動くか
利用者から主導権を奪わずに手助けする賢さを設計する
DNA Makerは、プロダクトチームと一緒にコンテキスト、好み、調整のマップを作り、何を変えてよく、何を固定すべきかの一線を引きます。パーソナライズがパワーユーザーや集めやすいデータだけに偏らないよう、さまざまな習熟度の利用者にインタビューします。
UXチームは、初心者から常連の利用者まで、説明と操作の仕組みを備えたプロトタイプを複数のバリエーションで作り、試してもらいます。テストで見るのは、タスクの成功率、戸惑いの度合い、アクセシビリティです。エンゲージメントの数字だけでは判断しません。
私たちは役割と利用状況の調査を行い、どこを固定し、どこを調整してよく、利用者がどう操作できるかを示すアダプティブな体験のマップ（Adaptive Experience Map）を描きます。本当に必要なデータ・イベントモデル、同意、記憶の仕組みを開発する前に、複数のバリエーションのプロトタイプを作り、利用者が理解できるかを確かめます。
仕組みとしては、アダプティブなWeb・モバイルアプリ、プロフィールと好みの管理画面、AIによる案内、フィーチャーフラグ、実験用のダッシュボードなどが考えられ、利用者グループ別の評価も含みます。新しい利用者が必ずサポートに問い合わせてしまうページが1つあれば、そのページで小さな実験を行い、成功率、自信の度合い、やり直し（Undo）の回数を測れます。
アダプティブなWeb・モバイルアプリ、プロフィールと同意の管理画面、記憶の仕組み、動的な指示（Dynamic Instructions）、スキーマに沿った生成UI、実験・評価の基盤を開発できます。アーキテクチャは、モデルの切り替えや、準備が整っていないときにAIをオフにすることにも対応します。
利用者の習熟度に差がありすぎて1つの流れでは合わないなら、DNA Makerが、調整すべき場面を1〜2か所だけ選び、システム全体をパーソナライズする前に試すお手伝いをします。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
ここに挙げる用語は、状況に合わせて変わる画面、記憶、枠組みの中での生成、アクセシビリティについて話し合うときに役立ちます。利用者が調整をどこまで把握・操作できるのか、データが足りないときのデフォルトは何かを確認するときに使ってください。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| Adaptive UI | ルールに従い、状況に応じて変わる画面。調整する部分は限定し、デフォルトを用意しておく。そうすれば利用者は、どこに何があるか、プロダクトの基本的な動きを予測し続けられる | 初心者には追加の案内が表示される | どの部分を調整でき、どの部分を固定すべきですか？ |
| Dynamic Profile | プロフィールの状態に応じて変わる指示やツールの組み合わせ。時間とともに変わる状況も含むため、情報の出どころ、鮮度、権限、そしてシステムの誤解を利用者が直せる方法が必要になる | 利用者が旅行モードを選ぶと、計画用のツールが開く | プロフィールは誰が定義するのですか？ |
| Memory | システムが利用のたびに状況を引き継ぐために使うデータ。作業に役立つものだけを保存し、期限をはっきり決める。好み、事実、会話履歴を分けて管理し、リスクを抑える | 利用者の同意を得たうえで、食事の制限を覚えておく | 利用者は記憶された内容を確認、修正、削除できますか？ |
| Guided Generation | AIの出力を決められた構造の中に収めること。生成の前に、構造、選択肢、ルールをAIに与えるので、品質が安定し、重要な箇所で人が確認する余地も残る | 計画を、日ごとの予定とアクティビティの一覧として返す | データが欠けている場合にも、スキーマは対応できますか？ |
| Accessibility | さまざまな人が使えるように設計すること。色、文字、キーボード操作、スクリーンリーダーから、わかりやすい言葉づかいまで最初から設計に組み込み、実際の利用者とテストする。後から付け足すものではない | スクリーンリーダーと大きな文字表示に対応する | AIがUIを変えたあとも、基準を満たしていますか？ |