摩擦を意図的にデザインする

フリクションレスは死んだ。あらゆるタップ、あらゆる確認、あらゆる間を取り除こうとした10年がかりの疾走は、プロダクトを「タップして祈る」スロットマシンに変えてしまった。そして2026年の最良のチームは、静かに摩擦を元に戻している。偶然ではない。意図的に。特定の場所で、特定の理由で。

摩擦はUXの敵ではない。摩擦は、UXが敬意を示す方法だ。ワンタップでアカウントを削除させるプロダクトは、ユーザーを尊重していない。先にアカウント名を入力させるプロダクトは尊重している。間こそがメッセージなのだ。

偶発的な摩擦は別物

「摩擦は悪」という主張のほとんどは、偶発的な摩擦の話だ。ラグ。分かりにくいUI。ダークパターン。2026年にFAX番号を聞いてくるフォーム。プロダクトが何も役に立たないうちから、メール確認、SMSコード、セットアップウィザードを要求するオンボーディング。この種の摩擦は悪だ。誰も擁護していない。

意図的な摩擦はまったく別のものだ。ユーザーが偶然ではなく本当の決断を下せるように、重大な局面で入れる意図的な間である。Apple Payの2回目のプッシュ。GitHubのリポジトリ名を入力して削除する仕組み。Cursorがコードに触れる前に見せるdiff。

偶発的な摩擦はバグ。意図的な摩擦は機能。この2つを混同した結果、業界はワンタップのアカウント削除ボタンの隣に、問い合わせフォームの「このページを離れますか」モーダルを並べることになった。

摩擦が価値を生む6つの場所

摩擦が価値を生むのは特定の文脈だ。その6つを、不在がユーザーをどれだけ痛めつけるかの順に並べる。

取り消せない操作

ユーザーが元に戻せないものには、すべて摩擦が必要だ。アカウント削除。データベースのドロップ。force-push。ゴミ箱を空にする。端末の初期化。誤タップのコストは回復不能なので、プロダクトはユーザーに意図を確認する時間を与える義務がある。

GitHubのリポジトリ削除は教科書的な例だ。削除ボタンが有効になる前に、ユーザーはリポジトリ名を一字一句正確に入力する。この摩擦は演出ではなく、筋肉の記憶を意図的な選択に変換する強制機能だ。StripeはAPIキーの失効で、AWSはリソース削除で同じ手法を使っている。「DELETEと入力」パターンが存在するのは、筋肉の記憶が意図に勝つからであり、取り消せない操作は筋肉の記憶に負けるわけにいかないからだ。

お金の流れ

お金を動かすプロダクトはすべて、ユーザーに確認ステップを提供する義務がある。Stripe Checkoutはあえて2ステップのフローになっている。1画面目でカード情報、次の画面で内容確認と確定。この「余分な」ステップこそが売りだ。ユーザーは、請求が確定する前に、何を、誰に、何のために払うのかを目にする。

Apple Payのダブルクリックも、同じ発想をハードウェアに凝縮したものだ。ユーザーは1秒の間を挟んで2回コミットしてから、お金が動く。その2回目の押下が、支払いと事故の違いだ。

フリクションレスな支払いは存在する。サブスクリプションと呼ばれ、アプリストアで最も苦情の多いカテゴリでもある。それには理由がある。確認ステップを外してもユーザーは幸せにならない。プロダクトに付け込まれていると感じるだけだ。

AIのツール呼び出し

AIが実際のアクションを起こそうとするたびに、つまりファイルシステムへの書き込み、コマンド実行、メール送信、APIの呼び出しのたびに、ユーザーには承認の間を得る権利がある。

Cursorの承認・却下式diffは最高の手本だ。モデルが変更を提案し、diffが表示され、ユーザーは変更が反映される前に承認、却下、編集ができる。Claudeのアーティファクト承認も同じ形をとる。コードエージェントがファイル編集を提案し、ユーザーがレビューし、それからコミットする。この摩擦が信頼のレイヤーだ。それがなければ、エージェントはコードベースを壊す速い手段でしかない。

2024年と2025年にこのステップを省いたAIプロダクトは、多くの信頼を燃やした。承認の間を組み込んだものこそ、ユーザーが実際に走らせっぱなしにするプロダクトだ。

アカウント削除と破壊的な設定

Linearの破壊的操作の確認は過小評価されている好例だ。プロジェクトのアーカイブは1回確認。プロジェクトの削除は2回確認し、何が消えるのかを表示する。ワークスペースの削除では、ワークスペース名をそのままテキストで入力させる。摩擦は損失の大きさに比例して増える。

Notionも同じグラデーションを使っている。アーカイブは元に戻せるのでワンタップ。削除は戻せないので入力確認の裏側に置く。ユーザーはどちらがどちらかを尋ねる必要がない。摩擦そのものが、リスクの大きさを伝えているからだ。

アーカイブと削除を同じワンタップの操作として扱うプロダクトは、その違いを尊重していない。ユーザーは、たいてい火曜の夜11時に、タップしたボタンが思っていたものと違ったと痛い目を見て知ることになる。

共有と公開の瞬間

公開ボタンには間が必要だ。ツイートの投稿、Slackのチャンネルへの送信、ブログ下書きの公開、クライアントへのFigmaファイルの共有。理論上は取り消せても、実際には恥ずかしい行為だ。送信前の間は、1人に宛てたはずの午前2時のDMが部署全体に流れる事故を防ぐ。

挑発的な返信に対するTwitterの「本当に送信しますか」プロンプトは機能している例だ。Slackの「4,200人にメッセージを送ろうとしています」という警告もそうだ。この摩擦は、ユーザーが後から「聞いてくれればよかった」と思うことを、プロダクトが覚えていてくれるということだ。

公開にも同じ論理が当てはまる。WordPress、Ghost、Webflow、そして使う価値のあるあらゆるCMSは、投稿が公開される前に確認サマリーを表示する。この摩擦が、「公開」と「公開して、すぐ非公開にする羽目になる」との違いだ。

機密データとアカウントアクセス

摩擦が属する場所はログインではない。新しいデバイスの確認がそうだ。機密性の高い操作を初めて行うときの2FAプロンプトがそうだ。「新しい場所からのログインを検出しました」という間がそうだ。

摩擦は玄関ではなく、脅威の接点に置く。新規サインイン時のAppleの確認プロンプトは正しい形だ。復旧用メールを変更する前のGoogleのセッション再認証も正しい形だ。一定額を超える送金で第2要素を求める銀行も正しい形だ。残高を確認するたびに第2要素を求める銀行は間違った形で、本当に重要なプロンプトを無視するようユーザーを訓練してしまう。

摩擦がプロダクトを殺すとき

場所を間違えた摩擦は、ただの悪いプロダクトだ。避けるべき3つのパターンを挙げる。いずれも出荷されたプロダクトで実際に起きた失敗モードだ。

玄関での摩擦。 ログインのための余計なステップ。セッションごとのCaptcha。3日かかるメール確認フロー。ユーザーはまだコミットしていないので、摩擦の一歩一歩が離脱のチャンスになる。摩擦は、ユーザーが残ると決めた後のために取っておこう。

ダークパターンな退会。 ユーザーを去らせないために設計された摩擦。4画面も奥に埋もれた解約ボタン。「すべての特典を失ってもよろしいですか」という罪悪感モーダル。登録にパスワードが不要だったアカウントでの、解約にパスワード入力を求めるパターン。敵意ある摩擦は、短期的な継続率を長期的な評判の毀損に変える。これをやるブランドは代償を払う。

オンボーディングの関門。 プロダクトが何もしないうちから、すべての設定を要求するセットアップウィザード。試しにサインアップしたばかりのプロダクトでの「プロフィールを完成させて続行」という壁。信頼構築の段階での摩擦は、ユーザーがまだ納得していない摩擦だ。正しいパターンはプログレッシブ・ディスクロージャーで、プロダクトが信頼を得るにつれて、ユーザーもより多くを差し出す。

経験則はこうだ。摩擦は入口ではなくアクションに。摩擦はミスのコストに比例して。摩擦は、妨害ではなく配慮としてユーザーに読み取られるものに。

摩擦はデザインの素材だ

ほとんどのチームが犯す間違いは、摩擦を二択で捉えることだ。確認あり、確認なし。2026年の最高のプロダクトを出荷しているチームは、摩擦を形を調整できる素材として扱う。よくある6つの形があり、それぞれ重さが違う。

ポーズ。 タップと実行の間の200msの間。可能な限り軽い摩擦。ホバーで確認するパターンや、反応の遅いボタンに使う。

確認。 1回だけ尋ねるモーダル。プロジェクトのアーカイブや請求書の送信といった、中程度のリスクの操作に対するデフォルトの摩擦。

二重確認。 2つのプロンプトを連続で出し、2つ目は1つ目と変える。最初のプロンプトを習慣で閉じてしまうユーザーが多い場合に使う。

入力して確認。 ユーザーにリソース名、DELETEという単語、あるいはアカウントのメールアドレスを入力させる。意図的な注意を強制する。最も取り消せない操作に使う。

クールダウン。 操作を繰り返したり取り消したりできるようになるまでの待機時間。パニックが起きやすい一括操作やモデレーション操作に使う。

アンドゥウィンドウ。 操作は実行されるが、ユーザーには取り消せる一定の期間がある。Gmailの送信取り消し。Slackの編集可能時間。手間をかければ元に戻せるが、致命的ではない操作に適した形だ。

適切な形は、リスクの大きさ、可逆性、そして操作の実行頻度で決まる。すべてのフローに単一の形を選ぶデザイナーは、すべてのレイアウトに単一のフォントウェイトを選ぶ人と同じやり方をしている。制約はバグであって、機能ではない。

速度と摩擦の関係については、speed is the brandとランディングページデザインの原則を参照してほしい。

摩擦の監査フレームワーク

すべてのフローを、出荷前にこの4つの問いに通そう。答えが間違っていれば、摩擦も間違っている。

1. その操作は取り消せるか? 取り消せるなら、摩擦は軽いか不要でいい。取り消せないなら、摩擦は必須で、ミスのコストに比例させるべきだ。
2. 誤ってタップしたら、ユーザーは何を失うか? 時間、お金、データ、評判。その4つすべてだ。摩擦の形は損失の大きさに合わせる。
3. 摩擦はフローのどこに入っているか? 玄関の摩擦は悪い。アクションの瞬間の摩擦は良い。ユーザーと価値の間にある摩擦は、場所が間違っている。
4. その摩擦は配慮として読めるか、妨害として読めるか? 摩擦に出会ったユーザーは、ブロックされたのではなく尊重されたと感じるべきだ。プロダクトに足止めされていると読めるなら、その摩擦は敵対的だ。

リスクのあるすべてのフローに対して、この4つの問いを順番に当てはめる。多くのチームがこれを飛ばすのは、確認モーダルを追加するエンジニアリングコストは些細なのに、それを置くべきかどうかというデザインの議論は些細ではないからだ。

フロー単位の判断をさらに掘り下げるなら、ウェブデザインの原則、death of the mockup、AIプロダクトのオンボーディングデザインを参照してほしい。

FAQ

UXフローに摩擦を加えるべきなのはいつ?

リスクの高い局面で加える。取り消せない操作、お金の流れ、AIのツール呼び出し、アカウント削除、公開、機密データの変更だ。摩擦は誤タップのコストに比例させ、入口ではなくアクションの場所に置くべきだ。

フリクションレスデザインは死んだのか?

普遍的な目標としてのフリクションレスは死んだ。適切な瞬間でのフリクションレスは、今も正しい。エフォートレスとフリクションレスは同じではなく、リスクの高い局面での意図的な摩擦は、ユーザーを尊重するプロダクトであることを示す。

良い摩擦とダークパターンの違いは?

良い摩擦は、ユーザーが後悔するミスから守る。ダークパターンの摩擦は、ユーザーがすでに下した決断から会社を守る。良い摩擦はアクションの場所にある。ダークパターンの摩擦は、ユーザーと出口の間にある。形は似て見えることもある。だが意図は正反対だ。

信頼を稼ぐレイヤーをつくろう

摩擦は良いUXの反対ではない。プロダクトが自分の存在理由を理解していることを示す、UXの一部だ。2026年に人々が信頼するプロダクトを出荷しているチームは、フローをマッピングし、リスクの高い瞬間に名前をつけ、それぞれに適した摩擦の形を選び、なぜこのフローに確認モーダルがあるのかと経営陣に問われたときもその選択を守り抜いた。

すべてのアクションが同じに感じられるせいで、あなたのプロダクトから信頼が漏れているなら、Brainyに依頼してほしい。私たちはUX監査、フローの再設計、そして「タップして祈る」プロダクトを人が使い続けるプロダクトに変える摩擦のレイヤーを出荷する。摩擦は素材だ。適切な場所に、適切な形で、意図的に使えば、ユーザーが触れるたびに、プロダクトは配慮として読まれる。