AIネイティブな製品設計：AIを後付けするのではなく、AIを最優先に考えた製品を作る方法

AIネイティブ製品とは、モデルを削除しても何も使えなくなる製品のことです。今日、AIネイティブを謳う製品のほとんどは、AIがなくても問題なく動作します。つまり、それらはAIネイティブではありません。AIは後付けされたものであり、違いはブランド名ではなく、アーキテクチャにあります。

最も分かりやすいテストは、削除テストです。製品を開き、すべてのモデル呼び出し、すべてのチャットパネル、すべてのキラキラしたボタン、「AIサマリー」の行を頭の中で削除してみてください。何が残りますか？もし、いくつかの装飾が失われたものの、完全に機能する製品であれば、それはAI後付け製品です。もし、主要な表面が失われた空っぽの殻であれば、それはAIネイティブ製品です。Linearは、新しい表面に関しては削除テストに合格しますが、Cursorはモデルがなければ何も残らないため、即座に削除テストに不合格となります。2024年にチャットサイドバーをリリースしたほとんどのエンタープライズSaaSは、重要なものを何も失わないため削除テストに合格しますが、これこそが問題なのです。

この記事は、そのテストの運用版です。 AIネイティブとAI後付けを区別する6つの原則、Linear、Cursor、Granola、Perplexity、Arc Searchの5つの実例に基づいた製品分解分析（各原則がどのように実装されているかを示す）、AIをサイドパネルに後付けしたものの何のメリットも得られなかった2つの製品の教訓、そして出荷前にどのチームでも実行できる出荷前チェックリスト。

AIネイティブとは、モデルが製品そのものであり、機能ではないことを意味します

「AIネイティブ」という言葉は、OpenAIのキーと光るエフェクトとともにあらゆる製品に安易に使われ、その意味が空虚になってしまっています。より明確な定義があります。AIネイティブ製品とは、モデルが主要なインターフェースであり、その他のUIはモデルを使いやすく、責任を持ち、高速に動作させるために存在する製品です。チャットパネル、フォームフィールド、ダッシュボード、サイドレールなどはすべて、モデルを支えるための足場に過ぎません。モデルは、いわば耐力壁のようなものです。

これは一見当たり前のことのように思えますが、実際の製品の出荷方法を見るとそう簡単にはいきません。2024年の標準的なエンタープライズパターンは、既存のダッシュボードをそのまま残し、右端にチャットパネルを追加するというものでした。モデルは製品に含まれていますが、製品はモデルを中心に構築されているわけではありません。ユーザーはチャットパネルを無視して、元のUIを使って目的のタスクをすべて完了できます。これは、どれほど目立つAIアイコンがあっても、AIを後付けしただけの製品の典型例です。

同じ製品のAIネイティブバージョンであれば、主要なワークフローはモデルを中心に再構築されます。ダッシュボードはプロンプトとなり、フォームは会話となり、エクスポートは生成処理となります。モデルはもはや無視できるものではなく、インターフェースそのものになります。このような製品は出荷がはるかに困難になるため、ほとんどのチームは後付けのAIで妥協してしまうのです。

AIネイティブ製品設計の6つの原則

コアサーフェスとしてのモデル、入力としてのプロンプト、デフォルトのエージェンシー、透明なサーフェス、意図的なモデル表示、設計上の制約としてのレイテンシー。研究に値するAIネイティブ製品は、必ずこれらの6つの原則のいずれか、あるいは両方を兼ね備えています。

これらの原則は、6つのうち4つを満たせばAIネイティブ製品になる、といったチェックリストではありません。これらは姿勢です。開発初日からモデルをインターフェースとして扱うチームは、自然とこれらの原則のほとんどを満たします。一方、モデルをスプリント12で追加する機能として扱うチームは、すべての原則を満たせず、チャットサイドバーをリリースすることになります。

以下の原則は、機能ではなく、意思決定として捉えられています。それぞれの原則には、AIネイティブ製品におけるデフォルトの姿勢と、AIを後付けした製品におけるデフォルトの姿勢があります。この2つの姿勢のギャップこそが、CursorとCopilotプラグインを搭載した他のテキストエディタとの違いです。

モデルをコアインターフェースとして、サイドパネルとしてではなく

最初の原則は最も単純でありながら、最も違反されている原則です。なぜなら、チャットサイドバーをリリースするエンタープライズSaaSはすべて、開発初日からこの原則を満たしていないからです。

コアインターフェースとは、ユーザーが製品を開いたときに最初に手に取るものがモデルであることを意味します。サイドパネルとは、既存のUIの横にモデルが配置され、必要に応じて利用可能になるものの、デフォルトでは無視される状態を指します。Perplexityはコアサーフェスです。Notion AIのスラッシュコマンドは、書き込みコンテキスト内ではほぼコアサーフェスです。Cluelyは、画面全体にオーバーレイとして表示されるコアサーフェスです。標準的なSaaSダッシュボードの右側にドッキングされているチャットアイコンは、サイドパネルの理想的な例です。

テストは、ユーザーが製品を初めて開いたときに最初に表示される画面です。最初に表示されるのがプロンプトフィールド、回答画面、またはモデル駆動型のプライマリビューであれば、その製品はコアサーフェスです。最初に表示されるのが、隅にチャットアイコンが表示された元のダッシュボードであれば、その製品はサイドパネルであり、最初のセッション以降はAIは無視されます。

既存製品の修正は容易ではありません。チャットパネルを右側にドッキングしたままにしておくことはできません。モデルをプライマリサーフェスに置き換えるか、ファーストクラスのアクションとして中央ワークフローに組み込む必要があります。これは機能追加ではなく、デザイン変更にあたるため、ほとんどのチームはこれを行わず、代わりにサイドバーをリリースします。

プロンプト入力方式がフォーム入力方式に取って代わる

2つ目の原則は入力モデルそのものです。ここでは、ドロップダウン、複数ステップのウィザード、空の状態のフォームが自然言語入力に置き換えられます。

プロンプト入力方式とは、ユーザーが自分の言葉で入力したい内容を入力し、モデルがその構造を推測する方式です。フォーム入力方式とは、ユーザーが製品が事前に定義した構造化されたフィールドに入力し、モデルは何もする必要がない方式です。CursorのCmd-Kはプロンプト入力方式です。LinearのコマンドパレットとAIもプロンプト入力方式です。Perplexityは製品全体がプロンプトとして機能します。Kreaの画像入力フィールドは、参照画像で拡張されたプロンプト入力方式です。Lovableは、文章からアプリ全体を構築するプロンプト入力方式です。

フォーム入力方式が常に間違っているわけではありません。構造化データの中には、フォームに入力すべきものもありますし、あらゆる操作をプロンプト経由で強制するのは、それ自体が設計上の誤りです。重要なのは、どの入力をフォームよりもモデルで処理できるかを検討し、まずそれらのフォームを置き換えることです。設定画面、検索フィルター、レポートビルダー、クエリインターフェースなどは、まさにその代表例です。ユーザーの名前、メールアドレス、クレジットカード情報は、そうではありません。

多くの製品に共通する問題点は、あらゆるフォームをそのまま残し、代替のエントリーポイントとしてプロンプトを追加していることです。ユーザーは同じ操作を行うために2つの方法を覚えなければならず、どちらか一方だけを使うよりも不便です。プロンプトはフォームと共存するのではなく、置き換えるべきであり、プロンプトがフォームよりも優れたパフォーマンスを発揮するようになったら、チームはフォームを廃止するべきです。

デフォルトでエージェンシーとは、製品が指示するのではなく、自ら行動することを意味します。

3つ目の原則は自律性です。AIネイティブ製品は許可を待たずに作業を行い、AIを後付けした製品はキー入力ごとに確認を求めます。

デフォルトでのエージェンシーとは、ユーザーが意図を表明した際に製品がアクションを実行し、実行した内容を表示し、ユーザーが操作を取り消せるようにすることを意味します。デフォルトでのパーミッションとは、製品がアクションを実行することを提案し、ユーザーが確認ボタンをクリックし、製品が再度確認を求め、ユーザーが諦めることを意味します。Cursorのエージェントは、ユーザーに確認を求めることなくファイルを編集します。Granolaは、ユーザーに確認を求めることなくメモを文字起こしし、補足します。Arc Searchは、ユーザーに確認を求めることなく、検索、要約、そして回答の提示を行います。製品は、交渉ではなく、行動しているのです。

トレードオフは確かに存在します。デフォルトでのエージェンシーには、取り消し機能、監査証跡、そしてモデルが実行した内容を明確に示すインターフェースが必要です。これらがなければ、エージェンシーは敵対的になり、製品はユーザーが望まないアクションを実行し、信頼は失われます。重要なのは、エージェンシーとリカバリーインターフェースを一緒に提供することであり、エージェンシーだけを提供して何も問題が起こらないことを期待することではありません。このトレードオフは、自律性スライダーが第一級の制御要素である、より広範なエージェントUIデザインパターンの議論にも当てはまります。

注意すべき例としては、あらゆる操作のたびに「…を実行しますか？」と確認を求める製品が挙げられます。確認のたびにクリックが必要になり、操作の流れが途切れ、モデルを開発したチームがモデルを信頼していないことを示唆します。チームがモデルを信頼していなければ、ユーザーも信頼しません。そのため、摩擦が保護的なものではなく、臆病なものに感じられるようになるまで、エージェンシーの姿勢を強める必要があります。

透明性のある画面がモデルの説明責任を明確にする

第4の原則は信頼ループです。これは、モデルが何を見て、何を決定し、なぜそうしたのかを、ユーザーが実際に読み取れる画面で示すものです。

透明性とは、システムプロンプトを公開することとは異なります。透明性とは、ユーザーが要求に応じて3つの質問に答えられることを意味します。モデルはどのようなコンテキストにアクセスできたのか？モデルはどのような操作を行ったのか？モデルは何を生成し、その情報源はどこにあるのか？Perplexityは、すべての主張に引用元を付記しています。Cursorは、すべての編集に差分を付記しています。Granolaは、拡張されたメモの横に生のトランスクリプトを付記しています。ユーザーは、モデルが何かを捏造したのではないかと疑う必要は全くありません。なぜなら、情報源はワンクリックで確認できるからです。

これとは正反対なのが「マジックボックス」パターンです。モデルが出力を生成しても、ユーザーはそれを検証する手段がありません。Notion AIの旧バージョンの要約機能は、しばらくの間このパターンで提供されていました。要約が表示され、ユーザーはそれを信頼するしかなかったのです。解決策は、引用を追加し、要約されたコンテンツを確認できる機能を提供することでした。ここから得られる教訓は、透明性はAIネイティブ製品においてオプションではなく、製品が幻覚装置にならないようにするための信頼メカニズムであるということです。

重要なのは、信頼性が損なわれた後に後付けするのではなく、最初から透明性を実装することです。引用なしでリリースされ、後から追加する製品は、ダメージコントロールをしているに過ぎません。最初のバージョンから引用を実装した製品は、その役割を果たしていると言えるでしょう。

デフォルトではモデルの詳細を非表示にし、意図に応じて表示する

5つ目の原則は、温度、モデル名、システムプロンプトを表示するタイミングに関する規律であり、その答えはほとんどの場合、メイン画面には表示されません。

ユーザーはどのモデルバリアントが実行されているかには関心がありません。ユーザーが関心を持っているのは、結果が適切で、高速で、検証可能であるかどうかです。モデル名をメイン画面に表示することは、製品チームのメンタルモデルがユーザーに漏洩することであり、チームが製品の真の目的をまだ決定していないことを示唆します。ChatGPTは以前はモデル選択機能を目立つように表示していましたが、ほとんどのユーザーがGPT-4-TurboとGPT-4oの違いを理解しておらず、選択肢が価値を生み出すどころか意思決定麻痺を引き起こしていたため、ひっそりと非表示にしました。

例外はパワーユーザー向けの画面です。Cursorは、ユーザーが選択肢を求める開発者であるため、モデル選択機能を表示しています。Claude Codeも同様の理由でモデル選択機能を表示しています。Kreaは、ユーザーがパラメータを調整したいと考えているため、生成パラメータを表示しています。原則としては、ユーザーインターフェース上ではモデルの詳細をデフォルトで非表示にし、ユーザーが明示的に制御したい場合に、設定パネルまたは詳細モードで表示するというものです。

問題点は、ユーザーがモデルについて何も知らない製品のホーム画面にモデル選択ツールを表示してしまうことです。あらゆる製品発表資料のヒーロースクリーンショットには、依然としてモデル選択ツールが表示されています。これらの製品のほとんどは、モデル選択ツールを非表示にして、開発チームが適切なモデルに自動的にアクセスできるようにする方が望ましいでしょう。

レイテンシーは最重要設計制約

第6の原則は、AIネイティブ製品は、モデルのストリーミング開始に2秒以上かかると動作が遅く感じられるということです。そして、エンジニアリングが修正する前に、設計段階でこの認識を改善する必要があります。

レイテンシーは単なるパフォーマンス数値ではなく、製品のリズムそのものです。最初のトークンが表示されるまでの2秒間の待機時間は無駄な時間であり、ユーザーはその間に不安を感じます。解決策は、応答トークンを1つずつストリーミング配信する（ユーザーがすぐに動きを確認できるようにする）、応答が間もなく表示されることを示すスケルトン状態またはシマー状態を表示する、そして部分的な結果が利用可能になり次第表示する、といった方法を組み合わせることです。 Perplexityはこれら3つすべてを満たしています。Cursorもこれら3つすべてを満たしています。ほとんどのエンタープライズSaaSチャットサイドバーはこれらをどれも満たしておらず、あらゆる操作で不具合を感じます。

ここから生じる設計上の制約は、モデルの実際のレイテンシをテストせずに製品を設計することはできないということです。高速なモックモデルで動作するプロトタイプではレイテンシの問題は明らかにならず、チームは設計レビューでは問題なく動作した製品を出荷しても、本番環境では動作が遅く感じられることになります。重要なのは、最初のプロトタイプから実際のレイテンシを考慮して設計し、その後、感覚的な問題を修正するか、リズムが適切になるまでアーキテクチャを変更することです。

AIネイティブ製品5選（注釈付き）

原則は、出荷された製品で実際に使用されて初めて意味を持ちます。そこで、現在、これらの原則を正しく実践している5つの製品を紹介します。

各製品の分析は簡潔かつ具体的です。各原則において製品が何をしているのか、どこで優れているのか、そしてどこで改善の余地があるのか​​を解説します。これらの製品はどれも完璧ではありません。しかし、いずれもAIを後付けしただけのベースラインをはるかに上回る性能を発揮しており、だからこそ研究する価値があるのです。

Linear、AIネイティブな静かなコマンドインターフェース

LinearのAIは、呼び出すまで目に見えませんが、呼び出すと製品内のあらゆるアクションへの最速の経路となります。

インターフェース：AIは既存のコマンドバー内に存在し、Linearパワーユーザーがほとんどの作業を行う場所であるため、このモデルは重要なユーザー層にとってコアインターフェースとなります。プロンプト：自然言語コマンドによる入力として、純粋なプロンプトを提供します。エージェンシー：高度。AIは交渉なしに課題の作成、説明の編集、トリアージを行います。透明性：アクションはタイムライン上で通常のLinearイベントとして表示されます。表示：モデルの詳細は非表示になっており、トリガーでさえAI機能ではなくLinear機能のように感じられます。レイテンシー：ストリーミング応答、即時トリガー。

Linearが収益を逃す部分。 AIはコマンドバーからの呼び出しに紐づいているため、新規ユーザーは後からその存在に気づきます。より明確なAIファーストのオンボーディングを行うことで、パワーユーザーの静かな利用姿勢を損なうことなく、ロングテール層の導入を促進できるでしょう。

Cursor：エディター自体にAIを組み込む

Cursorは、VS CodeにAIを後付けするのではなく、モデルを中心にエディターを再構築した結果生まれたものです。その結果、これまでにリリースされた中で最も洗練されたAIネイティブの開発者ツールが誕生しました。

インターフェース：モデルはあらゆる場所に存在し、Cmd-K、エージェントモード、オートコンプリート、チャットなど、すべてがエディターのインターフェースに統合されています。プロンプト：プロンプトが主要な操作であり、エディターにはメニューも存在しますが、ほとんどの処理はプロンプトによって行われます。エージェントモード：エージェントモードでは非常に高いエージェント機能を発揮し、製品の編集、コマンドの実行、差分の送信などを自動的に行います。透明性：すべての変更はユーザーが確認する差分として記録され、すべての操作がログに記録されます。情報公開：開発者が求めるモデルの詳細が公開されています。レイテンシ：ストリーミング、並列呼び出し、オプティミスティックUIを採用しています。

Cursorの課題点。エージェントモードのUIは、一部のフローではエディターに付随するチャットパネルのように感じられ、インラインエクスペリエンスにもっと溶け込むべきである。この統合を強化することで、Cursorはコアサーフェス領域へとさらに近づくだろう。

Granola：AIネイティブ、知能を備えたサイレント文字起こし

Granolaは、ユーザーが手動でメモを取っている間、モデルをアンビエントレイヤーとして扱い、会議後に静かにメモを拡張する。

サーフェス：モデルは拡張ステップ全体であり、これが製品の主要価値である。メモを取るサーフェス自体は従来型だが、モデルを覆う膜のような役割を果たす。プロンプト：多くの製品とは異なり、プロンプトは入力としてではなく、後処理として用いられる。ユーザーの手動メモが拡張のプロンプトとなる。エージェンシー：高い。拡張はユーザーの許可なしに行われる。透明性：生の文字起こしと拡張されたメモが並べて表示されるため、ユーザーはあらゆる主張を検証できる。開示：モデルの詳細は非表示になっており、ユーザーはどのモデルが実行されたかを知ることができない。レイテンシー：会議後なので、リアルタイムでのレイテンシーは問題になりません。

グラノーラが収益機会を逃している点。この製品は、デフォルトのサイレントモードに完全に依存するのではなく、会議後にユーザーが簡単なプロンプトで拡張機能を操作できるようにすることで、プロンプト入力方式をさらに強化できます。このインターフェースを追加することで、AIネイティブな姿勢をユーザーの編集制御へと拡張しつつ、デフォルトの環境を損なうことなく実現できます。

Perplexity、検索エンジン自体としてのAIネイティブ

Perplexity、モデルと回答を中心に検索を再構築。入力はモデル、インターフェースはモデル、そして結果もモデルです。

インターフェース：コアインターフェースは最大限に活用され、製品全体がモデルです。プロンプト：プロンプト入力方式が唯一のインタラクションモデルです。エージェンシー：中程度。モデルは質問なしで回答しますが、ユーザーはすべてのインタラクションを明示的に操作します。透明性：すべての主張に引用元を表示し、情報源をインラインで表示し、フォローアップの質問を提示します。表示：モデルの詳細は一般ユーザー向け画面ではほとんど非表示ですが、プロ向け設定で表示されます。レイテンシー：ストリーミング方式で、最初のトークンは高速ですが、より詳細なクエリでは部分的な結果しか表示されません。

Perplexity の課題：エージェントによる詳細な検索モードは、メイン画面に無理やり組み込まれているように感じられます。独立したモードではなく、深度スライダーとして回答フローに統合した方が、より分かりやすいでしょう。そうすることで、初めて利用するユーザーにとってエージェントの原則がより理解しやすくなります。

Arc 検索：ブラウザタブとしてネイティブなAI

Arc 検索では、閲覧から要約までのループ全体がワンタップで完了し、AIはタブ自体に組み込まれており、タブに付属するパネルではありません。

表示：モデルがページを置き換え、「検索」を選択するとリンクのリストではなく回答が返されます。プロンプト：アドレスバーを介してプロンプトが入力として表示されます。これはブラウザ上で最も自然なプロンプト表示方法です。エージェンシー：非常に高い。この製品は複数のページを閲覧し、要約して、ユーザーに尋ねることなく一つの統合結果を提示します。透明性：ソースリンクは統合結果の下部に表示されます。情報開示：モデルの詳細は完全に非表示で、AIはインフラストラクチャとして目に見えません。レイテンシー：複数ページにわたるエージェントアクションとしては驚くほど高速で、読み込み状態がスムーズなため、そのように感じられます。

Arc検索の課題：統合された回答は微妙な点で間違っている可能性があり、透明性を示す表面（リンクされたソース）は機能的ではあるものの、見落としやすいです。回答本文でソース引用をより積極的に提示することで、AIネイティブな姿勢を損なうことなく、信頼ループを改善できます。

AIが隅に置かれたキラキラしたアイコンではなく、表面的な存在である製品をお探しですか？Brainy を雇用する。UXBrainyは、AIファーストの製品戦略とデザイン監査を提供しています。AppBrainyは、Cursorレベルのツールを開発するチーム向けに、完全なAIネイティブ製品UIを提供しています。 ClaudeBrainyは、このリストにある製品のように、2024年のチャットサイドバーのようなものではなく、AI機能を構築したいチーム向けに、スキルパックとプロンプトライブラリを提供しています。

サイドパネルにAIを無理やり追加した2つの事例

AIネイティブ製品が信頼を獲得する一方で、2024年にチャットサイドバーをリリースしたものの利用率が伸び悩み、今や誰もキラキラアイコンをクリックしない理由が分からずに困惑しているエンタープライズSaaSも存在します。

これらの2つのパターンは現在、エンタープライズソフトウェアの至る所で見られ、どちらも製品を使い始めて最初の10秒で診断できます。これらは典型的なAIを無理やり追加したような形状であり、これらのいずれかをリリースしようとしているチームは、ローンチ資料を配布する前に再考すべきです。

誰も開かないチャットサイドバー

最初の注意すべきパターンは、既存のUIの右側にドッキングされたAIパネルです。これはワークフローに何も追加せず、画面スペースを奪い合います。

この形状はよく知られています。 CRM、プロジェクト管理ツール、ヘルプデスク、分析ダッシュボードなど、あらゆるアプリケーションに、AIによるサポートを謳うキラキラ光るアイコン付きのチャットパネルが右側に追加されています。ユーザーは一度チャットパネルを開き、質問をすると、文脈を理解していない一般的な回答が返ってきて、閉じて二度と開くことはありません。チャットパネルが製品に残っているのは、ユーザーがそれを望んでいるからではなく、開発チームが基調講演で発表したからです。

解決策は、チャットパネルを改善することではありません。チャットパネルを廃止し、モデルを中心とした主要なワークフローを再構築することです。フォームをプロンプトに置き換え、レポートビルダーを生成機能に置き換え、検索バーを回答画面に置き換えます。モデルはワークフローの傍らに配置されるのではなく、ワークフローの中に組み込まれるべきです。この再設計を拒否するチームは、チャットサイドバーをリリースし続け、AIの利用率が1%しかない理由をいつまでも疑問に思うでしょう。

誰も要約を求めていない内容を要約するキラキラボタン

2つ目の注意すべきパターンは、あらゆるテキストフィールドに魔法の杖が取り付けられているようなもので、AIが入力内容を書き換えたり、要約したり、展開したりすることを提案するものの、ユーザーは入力し続けるしかないという状況です。

その構造はこうです。あらゆるフォームフィールド、あらゆるテキスト入力欄、あらゆるコメントボックスに、AIによる支援を提供する小さなキラキラボタンが設置されています。開発チームは手軽さからこれを実装しましたが、AIが周囲の文脈を十分に理解していないため役に立たず、ボタンをクリックするよりも自分で文章を書く方が手間がかかるため、ユーザーは無視してしまいます。このボタンは製品全体にフジツボのように付着し、開発チームが追跡している指標（ボタンの視認性）は上昇するものの、本当に重要な指標（ユーザー満足度）は横ばい状態です。

解決策は、チャットサイドバーの修正と同様の構造ですが、範囲はより限定的です。AIが真に役立つ2つか3つのテキストフィールド（長文コンテンツ、構造化データ抽出、大規模ドキュメントの要約など）を選び、そこにAIネイティブの高度なエクスペリエンスを提供します。それ以外のすべてのフィールドからキラキラボタンを削除します。製品は重要な部分においてAIネイティブとなり、不要な要素は排除されました。

AIネイティブ製品の出荷前チェックリスト

AIネイティブを謳う製品に対してこのチェックリストを実行すれば、実際のユーザーに届く前に、後付けのパターンを発見できます。

1. 削除テスト。製品からすべてのモデル呼び出しを頭の中で削除してみてください。何が残りますか？ 完全な機能を持つ製品が残る場合、その製品はAIが後付けされたものです。中身のない空っぽの殻が残る場合、その製品はAIネイティブです。

2. コールドオープンテスト。製品をコールドオープンで起動してみてください。ユーザーが最初に目にする画面は何ですか？ プロンプトフィールド、回答画面、またはモデル駆動型のプライマリビューであれば、画面の原則は成り立っています。隅にチャットアイコンがあるだけの元のUIであれば、画面の原則は成り立っていません。

3. フォームからプロンプトへの監査。製品内のすべてのフォームフィールドをリストアップしてください。各フィールドについて、プロンプトの方がより適切に機能するかどうかを自問自答してください。テストに合格しないものは置き換えてください。

4. エージェンシーの姿勢。ユーザーの意図表明からモデルの動作までの間に表示される確認モーダルの数を数えます。確認モーダルが複数ある場合は、エージェンシーの原則が慎重すぎる可能性があります。より多くの動作を「実行してから元に戻す」方式にしましょう。

5. 透明性のインベントリ。モデルの出力ごとに、ユーザーはモデルがどのようなコンテキストを持ち、どのような動作を行い、回答がどこから来たのかを確認できるかを問います。これら3つのうちいずれかが欠けている場合、透明性が不十分です。

6. 表示の規律。主要な画面を確認します。モデル名、温度、またはシステムプロンプトが表示されていますか？表示されている場合は、対象ユーザーが技術者でない場合は非表示にします。表示されている場合は、対象ユーザーが技術者である場合は表示したままにします。

7. レイテンシーのリズム。ユーザーの意図表明からモデルの最初の応答トークンまでの時間を測定します。フィードバックがないまま2秒以上経過している場合は、レイテンシーの認識が崩れています。ストリーミング、スケルトン状態、または部分的な結果を追加して、リズムが生き生きと感じられるようにします。

8. スパークルボタンの監査。製品画面全体に表示されるスパークルアイコンの数を数えます。 3つ以上の要素がある場合、そのほとんどはノイズです。重要な2つか3つのインターフェースにAIネイティブな体験を徹底的に実装し、残りは排除しましょう。

9. オンボーディングテスト。初めて利用するユーザーが主要タスクを完了する様子を観察します。モデルが体験を支えたのか、それともユーザーは元のUIを使ってタスクを完了したのか？後者の場合、マーケティングでどんなに謳っていても、AIは後付けです。

10. 信頼失敗時のリカバリー。モデルに意図的に誤った回答を出力させます。製品はどう反応するのか？明確なリカバリーインターフェースがない場合、信頼ループが不完全であり、製品は最初の誤認識でユーザーを失ってしまうでしょう。

これらの10項目のチェックに合格した製品こそ、真にAIネイティブです。完璧ではないかもしれませんが、アーキテクチャは正しく、他のほとんどの問題はそこから解決可能です。これらのチェックのほとんどに合格しない製品は、ローンチ記事でAI機能がどれほど目立つように表示されていても、AIは後付けです。

よくある質問

AIネイティブな製品設計とは？

AIネイティブな製品設計とは、モデルが主要なインターフェースであり、その他のUI要素はモデルの使いやすさ、説明責任、および高速性を確保するために存在することを意味します。最も明確なテストは削除テストです。製品からすべてのモデル呼び出しを削除しても完全に機能する製品が残る場合、その製品はAI後付け型です。中身が空っぽのシェルしか残らない場合、その製品はAIネイティブです。Linear、Cursor、Granola、Perplexity、およびArc Searchは、コアインターフェースにおいてこのテストに合格しています。2024年にチャットサイドバーをリリースしたほとんどのエンタープライズSaaSは、このテストに合格していません。

AIネイティブとAI後付け型の違い

AIネイティブ製品は、モデルを中心に主要なワークフローを再構築します。AI後付け製品は、既存のワークフローをそのまま維持し、AIパネルをサイドバーとして追加します。違いは、ユーザーがコールドオープン時にどこにたどり着くか、入力がプロンプトかフォームか、製品がアクションを起こすか質問するか、そしてモデルを無視しても主要機能が損なわれないかどうかといった点に現れます。AIを後付けした製品は無視できますが、AIネイティブ製品は無視できません。

AIファースト製品設計の原則とは？

AIネイティブとAI後付けを区別する6つの原則があります。モデルをサイドパネルではなくコアサーフェスとして扱うこと。入力はフォームではなくプロンプトであること。デフォルトで権限ではなくエージェンシーを付与すること。モデルに説明責任を持たせる透明性のあるサーフェス。モデルの詳細をデフォルトで非表示にし、意図に応じて表示すること。ストリーミング、スケルトン状態、部分的な結果などを活用し、レイテンシーを第一級の設計制約として扱うこと。研究に値するAIネイティブ製品はすべて、これらの6つの原則のいずれかを組み合わせて実装しています。

AIネイティブ製品の最良の例とは？

Cursorは、開発者ツールとしてこれまでにリリースされたAIネイティブ製品設計の最も洗練された例です。 Perplexityは、消費者向け検索の最も洗練された例です。Linearは、既存の生産性向上インターフェースに組み込まれたAIネイティブ体験の最も洗練された例です。Granolaは、モデルがバックグラウンドで動作する、AIネイティブな環境の最も洗練された例です。Arcの検索は、AIネイティブなブラウザインタラクションの最も洗練された例です。いずれも、既存のUIにAIを無理やり追加するのではなく、モデルを中心に主要なワークフローを再構築しました。

AIネイティブ製品のためのAI UXをどのように設計すればよいでしょうか？

まず、すべての画面で削除テストを実施します。フォームを、ユーザーよりもモデルの方が構造化に適したプロンプトに置き換えます。デフォルトのエージェンシーの姿勢を、質問してから実行するのではなく、実行してから取り消すように設定し、取り消し画面をアクションと同時に提供します。すべてのモデル出力に透明な画面を追加します。消費者向け画面からモデルの詳細を非表示にします。すべてのインタラクションは、モックレイテンシーではなく、実際のモデルレイテンシーを考慮して設計し、最初のトークンが到着するまでに1ビート以上かかる場合は、ストリーミングまたはスケルトン状態を使用してください。この姿勢は、モデルに適応するレイアウトへと移行する、より広範な2026年のウェブデザインのトレンドのシフトにも当てはまります。

AIネイティブ製品がもたらす変化

AIネイティブ製品とは、チャットウィンドウが隅に貼り付けられたSaaSアプリではなく、モデルが主要な媒体であり、UIが膜となる、新しい形の製品です。

AIネイティブ製品（Linearの最新サーフェス、あらゆる場所にCursor、拡張レイヤーにGranola、Perplexityのエンドツーエンド、Arcの検索をインタラクションモデル全体として提供）をリリースしているブランドはすべて、このことを深く理解しています。彼らは製品にAIを追加したのではなく、AIを中心に製品を構築したのです。アーキテクチャ上の決定はあらゆる設計上の選択の根幹であり、入力モデルからレイテンシーのリズム、リカバリーサーフェスに至るまで、あらゆる要素に反映されます。既存のインターフェースにAIを後付けしようとする製品は、マーケティングサイトでどれほどAIファーストを謳っていても、結局は誰も開かないチャットサイドバーや誰もクリックしないキラキラボタンといったものになってしまうでしょう。

2026年のデザインチームにとってのチャンスは、リリースするすべての製品に対して削除テストを真剣に実施することです。製品がこのテストに合格すれば、チームは製品ではなく機能をリリースしていることになります。製品がテストに不合格になった場合（モデルが欠落して中身が空っぽになるという、正しい意味で）、チームは真にAIネイティブなものを構築するチャンスを得ます。そして、上記の原則は、それを実現するための基盤となります。同じ基盤は、より広範な視覚的階層構造の枠組みにも存在し、そこではモデルが従来のUIの周りを回るのではなく、ページ上で最大の視覚的位置を占めるようになります。

より根本的な変化は、ユーザーのソフトウェアに対するメンタルモデルが変化していることです。ユーザーはもはやツールの使い方を学ぶことを期待していません。意図を表明すればツールが応答してくれることを期待しています。旧来のメンタルモデル（フォーム、ダッシュボード、複数ステップのウィザードなど）に基づいて構築された製品は、2年以内に動作が遅く、形式的で、時代遅れに感じられるようになるでしょう。一方、新しいメンタルモデル（プロンプト、回答、アクション、取り消し）に基づいて構築された製品は、まさに現代のニーズを満たすものとなるでしょう。いち早くAIネイティブ化に着手したチームは、それぞれの分野におけるAIネイティブの意味を定義するでしょう。既存のインターフェースにチャットサイドバーを無理やり追加しただけのチームは、AIエンゲージメント指標が低い理由を今後10年間説明し続けることになるでしょう。

もしあなたのチームがAI機能の開発、AI製品の開発、あるいは実際にリリースする製品がどれなのかを検討している段階であれば、このページに記載されている原則はまさに操作マニュアルです。具体的な製品への適用方法についてサポートが必要な場合は、Brainy を雇用するをご覧ください。UXBrainyは、このフレームワークに基づいたAIファーストの製品戦略と包括的なデザイン監査を提供しています。AppBrainyは、ユーザーに実際に使ってもらいたいツールを開発するチーム向けに、AIネイティブな製品UIを提供しています。 ClaudeBrainyは、Claude スキルとプロンプトライブラリを出荷します。これは、2024年のチャットサイドバーのようなものではなく、カーソルのようなAI機能を必要とするチーム向けです。このページで紹介するフレームワークは、出荷前にすべてのプロジェクト、すべての画面で実行されるものです。