← エピソード一覧に戻る Episode 192 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― AIは賢さより先に信頼が問われる
タカシ
今日は SaaS デザインの AIアシストUX を扱います。要約や提案を出すだけなら誰でもできますが、本番業務で使われるかは別問題です。経営目線では、賢いかより、安心して任せられるかが勝負になります。
ミカ
たしかに、AI がそれっぽい答えを出しても、どこから来たのか分からないと怖いです。便利そうで、最後は人が全部確認するなら、結局忙しさだけ増えることもありますよね。速いけれど信用しづらい、そんな状態です。
タカシ
その通りです。AIアシストUXは、賢さの演出ではなく信頼の設計です。根拠を見せる、勝手に進めない、間違えたら戻せる、人へ渡せる。この4つが弱いと、派手でも現場では定着しませんし、利用者はすぐ慎重になります。
ミカ
なるほど。AI 機能って新機能の花形に見えますけど、実際はブレーキとハンドルの設計まで含めて UX なんですね。アクセルだけ強い車みたいにしちゃ駄目だと。運転補助なのに暴走しそうでは、さすがに困ります。
Chapter 2 原則 ― 根拠と制御を見せるAIだけが使われる
タカシ
Notion の Enterprise Search は分かりやすい例です。回答には必ずソースが付き、検索対象も Web や apps を切り替えられる。さらに特定ページや人を Add context で指定できるので、AI に見せる範囲を人が絞れます。
ミカ
それは大きいですね。AI が勝手に全部見て答える感じだと不安ですけど、ここだけ見て考えてねと指定できるなら、かなり使いやすい。答えの精度より、質問の条件を握れる感覚が大事なんだと、すごくよく分かります。
タカシ
しかも Notion の公式記事では、AI Enterprise Search 導入組織で生産性が10〜30%改善したと説明しています。ただし、その価値は魔法の回答より、権限を守りつつ根拠付きで探せることから生まれているんです。
ミカ
AI を入れたから速くなった、じゃなくて、安心して使えるから回数が増えて、結果として速くなるわけですね。信頼の摩擦が減ると利用量が増える、これは SaaS らしい話ですし、継続率にもかなり効きそうです。
Chapter 3 実例1 ― 権限を越えず、根拠を隠さない
タカシ
Slack の AI search も重要です。公式には、AI search answers は自分がアクセス権を持つメッセージやファイルだけを使うと明記されています。しかも管理者はファイル検索を制限できる。便利さより境界管理を優先しているんですね。
ミカ
社内検索系の AI って、賢いほどちょっと怖いですもんね。知らない情報まで勝手に引っ張ってきたら一発アウトですし。見つかることより、見つかりすぎないことが大事な場面があるんだと、いまの話で本当に実感します。
タカシ
Atlassian Rovo も同じ方向です。private document は検索にも Chat にも本人だけが見え、権限変更や削除も index に同期されます。さらにコネクタによっては blocklist で対象範囲を狭められる。AI の前に、まずデータ境界を設計しているわけです。
ミカ
つまり AIアシストUXって、画面の文言だけじゃなく、裏側の接続設計まで含むんですね。UX とセキュリティを別部署の話にすると、ここはすぐ壊れそうです。経営が横串で見るべきテーマだなと、強く思います。
Chapter 4 実例2 ― 間違えた時に人へ戻れるかが本番運用を決める
タカシ
Intercom は失敗時の逃げ道がかなり明確です。Fin は source links を回答文に直接表示し、顧客が No と返したり会話がループしたりすると human support への escalation を提案する。反応がなければ既定で4分後に follow-up します。
ミカ
それ、安心感ありますね。AI に任せたあと沈黙するのがいちばん怖いので、根拠が見えて、駄目なら人へ戻れるなら使いやすい。逃げ道って、性能の弱さじゃなく信頼の条件なんですね。ここはかなり誤解しやすいです。
タカシ
さらに Intercom は AI Agent disclosure を既定で持ち、いつでも team に依頼できると明示しています。Copilot では internal sources を使った回答を黄色で示し、送信前に警告も出す。生成しただけで発火させない設計が効いています。
ミカ
AI ですと名乗る、根拠を出す、危なそうなら止める、人にも渡せる。この一連の流れがあると、AI が前に出ても組織は怖がりにくいですね。派手さより段取りの勝利だなあと、しみじみ強く感じます。かなり本質的です。
Chapter 5 まとめ ― AIアシストUXは監査まで含めて設計する
タカシ
最後に監査です。GitHub Copilot は public code と一致した提案に code reference を付け、URL や license を確認できます。一致は1%未満とされますが、ゼロではない。さらに enterprise の audit log は agent activity を180日保持します。
ミカ
でも audit log に全部入るわけじゃなくて、ローカルの prompt は別設計が要るんですよね。AI を入れたら、何が残るかだけじゃなく、何が残らないかも説明できないとまずそうです。営業も情シスも困ります。
タカシ
まさにそこです。AIアシストUXの失敗は、根拠を見せない、全員に同じ提案を出す、承認前に勝手に進める、やり直しや人への退避路がない、監査前提が曖昧、この5つに集約されます。導入前に必ず潰したいですね。
ミカ
今日のポイントは、AI を入れることじゃなく、信用して使える流れを設計することでした。皆さんの SaaS でも、提案の横に根拠があるか、止められるか、戻せるかを明日ぜひ点検してみてください。そこが定着率の分かれ目です。