ユーザに主導権を返すUI｜AI業務管理秘書たすきばが"ゲートキーパー"を作らない設計
このサービスの設計を貫く一文
たすきばの UI 設計には、一つだけ、強い信念があります。
人間は、自分に主導権があると、満足する。
サービスがゲートキーパーとして君臨する設計は、この心理に正面から反します。たすきばは、その逆を選びました。
具体的に何が違うのかというと、
- プラン変更・解約・Storage Add-on のダウングレード
- メンバー追加・ロール変更・退会処理
- データのエクスポート（CSV / Markdown / Excel）
これらすべてが、 運営との往復ゼロで完結する UI になっています。今日は、B 章の最終回として、その設計判断の中身を書きます。
一般的な業務 SaaS の “罠”
業務 SaaS の多くは、解約や縮小操作にあえて摩擦を入れています。
- 解約ボタンを深い階層に隠す
- 「解約理由を 10 項目選んでください」のような心理障壁を入れる
- 「サポートに連絡してください」のような中間ステップを入れる
これらは、ユーザを取り戻すための猶予時間を稼ぐ意図があります。ビジネス上の合理性はあります。
ただ、ユーザ視点で見れば、これは 「自由を奪う設計」 です。 「ここを離れたい」 と思った瞬間に、サービスに引き止められる感覚は、後味が悪い。たすきばは、その後味を残したくありません。
これは 『嫌われる勇気』ノート ②（課題の分離） で書いた発想とほぼ同じです。 ユーザがサービスを使い続けるかどうかは、ユーザの課題 であって、私の課題ではない。私の課題は、ユーザが「続けたい」と思える価値を提供することだけです。
“来るものも出るものも拒まない” を実装する
具体的に、たすきばの主要操作の UI 設計はこうなっています。
プラン変更
テナント設定画面の「プラン」セクションで：
- 現プラン（例: Beginner）
- 「Expert に変更する」「Pro に変更する」 ボタン
- 「変更内容を確認」ダイアログで料金プレビュー
- 即時切替
——運営承認は不要。テナント管理者の権限で完結します。
解約
同じ画面の最下部に：
- 「テナントを解約する」 ボタン
- 確認ダイアログ（「○○ さんの全データは削除されます」）
- 即時解約
——「解約理由を選んでください」のような中間ステップは入れません。 任意で フィードバックを送る リンクを併設しています（送らなくても解約は完了します）。
Storage Add-on のダウングレード
ストレージ容量を増やしている場合：
- 現在の容量と使用量を表示
- スライダーで希望容量を選択
- 「次回請求から ¥xx 減額」とリアルタイム表示
- 確認ボタンで即時反映
——「ダウングレード前に運営にご相談ください」のような表示は出しません。
エクスポート機能 — “あなたのデータはあなたのもの”
たすきばは、ユーザが自分のデータを いつでも持ち出せる ようにしています。
| 対象 | フォーマット |
|---|---|
| ナレッジ | Markdown 一括ダウンロード |
| リスク / 課題 | CSV エクスポート |
| 振り返り | CSV / Markdown |
| メモ | Markdown |
| プロジェクト | CSV（タスク含む） |
これは、ユーザがたすきばから いつでも出ていける状態 を保つためです。
データを人質に取られる感覚があると、ユーザは安心して使えません。逆に、いつでも持ち出せる状態にしておくと、ユーザは安心して 使い続けて くれます。
「自由を保証することで信頼を得る」 ——これは、 連載第 2 回 で書いた「依存させない距離感」とも、一直線につながる発想です。
“ゲートキーパー” を作らないための運用ルール
運営者として、 「ここで止まってくださいね」と言わない 運用にしています。
- プラン変更の事前承認 → 不要
- 解約理由の聞き取り → 任意
- メンバー追加上限 → 設定可能だが、テナント管理者の自由
- ロール変更の運営承認 → 不要
例外は、 法令遵守 / セキュリティ違反対応 のみ。これも、ユーザにとっての安全性のための例外であり、運営の都合のための例外ではありません。
唯一の例外: 自己ロール変更禁止
ひとつだけ、ユーザの自由を制限している箇所があります。
管理者は、自分自身のロールを下げることができない。
これは、テナント内で「最後の管理者がいなくなる」状況を防ぐためのセーフティネットです（ADR-0014）。ロール変更履歴は監査ログに残し、 別管理者によるロール変更だけを許可する 設計にしています。
「ユーザを縛る」ためではなく、 「運用上の事故を防ぐ」 ためです。
このような例外があるとき、 UI ではちゃんと 理由を明示 します。
「自分自身のロールは変更できません。他の管理者からの変更を依頼してください。」
こう書くことで、制限の存在を理不尽に感じさせない設計にしています。たすきばは「禁止」を伝えるときも、必ず 代替手段 を一緒に書く——これがルールです。
“UI = API 認可一致” の原則
少しテクニカルな話になりますが、たすきばは：
UI で押せないボタンは、API でも受け付けない。
という原則を守っています（ADR-0014）。
具体的には、
- UI でボタンを disabled にする → 同時に API 側でも 403 Forbidden を返す
- UI でメニューを非表示にする → 同時に API 側でもアクセス不可
これは、 「ユーザに見えている景色 = 操作できる範囲」を物理的に一致させる 設計判断です。
ユーザが 「ボタンが見えたから押した。けど 403 になった」 という体験は、 UI が嘘をついている ことになります。たすきばは、UI が嘘をつかない設計を貫きます。
まとめ
たすきばの UI 設計は、 「ユーザに主導権を返す」 一点に集約されます。
- プラン変更・解約・ダウングレード → セルフサービス
- データエクスポート → いつでも可能
- 自己ロール変更禁止 → 例外として明示
- UI = API 認可一致 → UI が嘘をつかない
一見すると、これらは 「運営の手間を増やしているだけ」 に見えるかもしれません。実際、これらの実装には時間がかかりました。
しかし、結果としてユーザに渡しているのは 「自由」 です。そして、 『嫌われる勇気』ノート ③（いま、ここ） で書いたように、 自由は信頼の土台になります 。短期で見ると損な選択ですが、長期で見ると、これが一番続く形だと信じています。
B 章のまとめ
これで B 章（プロダクト概要・リリース）の 4 本を書き終えました。
- B-1: リリース告知 + サービス全体像
- B-2: 提案機能の中身
- B-3: 課金体系の考え方
- B-4（本記事）: ユーザに主導権を返す UI
ここから K 章—— コミュニティ・募集・文化 に入ります。明日は 「共感を採用フィルタにする」 という、技術力ではなく価値観で人を集める発想の話です。
関連記事
- 3 プラン × 従量課金の考え方 — 儲けるための課金ではなく、続けるための課金 — 連載第 9 回・課金哲学
- 『嫌われる勇気』ノート ②（課題の分離）— 相手の評価はあなたの課題ではない — 「主導権を渡す」発想の出どころ
- 『嫌われる勇気』ノート ③（いま、ここ）— 過去と未来から、いまを取り戻す — 「自由は信頼の土台」の発想
たすきば について
たすきば Knowledge Relay の UI は、 「ユーザに主導権を返す」 という信念で設計されています。 プロダクトページ で、実際の画面遷移とセルフサービス操作をご覧いただけます。
