自律エージェント向けの設計には独特のフラストレーションが伴います。複雑なタスクを AI に渡すと、AI は 30 秒 (または 30 分間) 消えてから、結果を返します。私たちは画面を見つめます。うまくいきましたか？幻覚だったのか？コンプライアンスデータベースをチェックしましたか、それともそのステップをスキップしましたか? 私たちは通常、この不安に対して 2 つの極端な方法のいずれかで対応します。システムをブラック ボックスにして、シンプルさを維持するためにすべてを隠すか、パニックを起こしてデータ ダンプを提供し、すべてのログ行と API 呼び出しをユーザーにストリーミングします。 どちらのアプローチも、ユーザーに理想的なレベルの透明性を提供するために必要な微妙なニュアンスに直接対処するものではありません。 ブラックボックスはユーザーに無力感を与えます。データ ダンプにより通知が見えなくなり、エージェントが約束した効率が損なわれます。ユーザーは、何かが壊れるまで、絶え間なく流れてくる情報を無視します。壊れた時点では、それを修正するためのコンテキストが不足しています。 バランスを見つけるための組織的な方法が必要です。前回の記事「Agentic AI の設計」では、AI の意図するアクションを事前に表示する (インテント プレビュー) ことや、AI が独自に実行する量をユーザーが制御できるようにする (自律ダイヤル) など、信頼を構築するインターフェイス要素について検討しました。しかし、どの要素を使用するかを知ることは課題の一部にすぎません。デザイナーにとってより難しい問題は、それらをいつ使用するかを知ることです。 30 秒のワークフローのどの瞬間がインテント プレビューを必要とし、どの瞬間が単純なログ エントリで処理できるのかをどのようにして知ることができるでしょうか? この記事では、その質問に答える方法を紹介します。デシジョンノード監査について説明します。このプロセスでは、デザイナーとエンジニアが同じ部屋に集まり、バックエンド ロジックをユーザー インターフェイスにマッピングします。ユーザーが AI の動作に関する最新情報を必要とする正確な瞬間を特定する方法を学びます。また、表示する意思決定ノードと、その意思決定と組み合わせる関連する設計パターンの優先順位付けに役立つ影響/リスク マトリックスについても説明します。 透明性の瞬間: ケーススタディの例 エージェント AI を使用して最初の事故請求を処理する保険会社、Meridian (仮名) について考えてみましょう。ユーザーは車両の損傷写真と警察の報告書をアップロードします。その後、エージェントは 1 分間姿を消し、リスク評価と提案された支払い範囲を持って戻ってきます。 当初、Meridian のインターフェイスには単に請求ステータスの計算が表示されていました。ユーザーは不満を募らせた。彼らはいくつかの詳細な書類を提出していたが、状況を緩和する内容を含む警察の報告書をAIが検討したのかどうかさえ確信が持てなかった。ブラックボックスは不信感を生み出しました。 これを修正するために、設計チームは意思決定ノード監査を実施しました。彼らは、AI が多数の小さなステップが埋め込まれた 3 つの異なる確率ベースのステップを実行したことを発見しました。
画像分析エージェントは、損傷写真を典型的な自動車事故シナリオのデータベースと比較して、修理費用を見積もりました。これには信頼度スコアが関係していました。 テキストレビュー 警察の報告書をスキャンして、責任に影響を与えるキーワード (過失、気象条件、飲酒など) を探しました。これには、法的地位の確率的評価が含まれていました。 保険契約の相互参照 保険金請求の詳細をユーザーの特定の保険契約条件と照合し、例外や補償範囲の制限を検索します。これには確率的マッチングも含まれます。
チームはこれらのステップを透明性の高い瞬間に変えました。インターフェイス シーケンスは次のように更新されました。
損傷写真の評価: 500 台の車両衝撃プロファイルと比較。 警察報告書のレビュー: 責任に関するキーワードと判例を分析します。 ポリシーの適用範囲の確認: プラン内の特定の除外項目を確認します。
システムには依然として同じ時間がかかりましたが、エージェントの内部動作に関する明示的なコミュニケーションにより、ユーザーの信頼が回復しました。ユーザーは、AI が設計された複雑なタスクを実行していることを理解し、最終的な評価が不正確に思われる場合にどこに注意を向けるべきかを正確に知っていました。このデザインの選択により、不安の瞬間がユーザーとのつながりの瞬間に変わりました。 影響/リスク マトリクスの適用: 隠すために選択したもの ほとんどの AI エクスペリエンスには、処理中に表示される可能性のあるイベントと意思決定ノードが不足することはありません。監査の最も重要な結果の 1 つは、何を非表示にしておくかを決定することでした。 Meridian の例では、バックエンド ログはクレームごとに 50 以上のイベントを生成しました。 UI の一部として処理される各イベントをデフォルトで表示することもできました。代わりに、リスク マトリックスを適用してそれらを排除しました。
ログイベント: サーバーへのpingWest-2 冗長性チェック用。 フィルター判定: 非表示。 (賭け金は少なく、専門性は高い)。
ログ イベント: 修理見積もりと BlueBook の値を比較します。 フィルター判定: 表示。 (ハイステークス、ユーザーの支払いに影響します)。
不必要な詳細を削除することで、適用範囲の検証などの重要な情報の影響力が高まりました。私たちはオープンなインターフェイスを作成し、オープンなエクスペリエンスを設計しました。 このアプローチでは、人々は行われている作業を見ることができると、サービスに対する気分が良くなるという考えを利用しています。具体的なステップ（評価・検討・検証）を示すことで、30秒間の待ち時間を「壊れていないか？」という不安な時間から、何か価値あるものが生まれていると感じる時間（「考えている」）に変えました。 次に、製品の意思決定プロセスをレビューして、明確な情報が必要な重要な瞬間を特定する方法を詳しく見てみましょう。 意思決定ノードの監査 透明性を機能要件ではなくスタイルの選択として扱うと、透明性は失われます。私たちは「UI はどのようにあるべきか?」と尋ねる傾向があります。 「エージェントは実際に何を決定しているのですか?」と尋ねる前に、 デシジョン ノード監査は、AI システムを理解しやすくする簡単な方法です。これは、システムの内部プロセスを注意深くマッピングすることによって機能します。主な目標は、システムが設定されたルールに従わなくなり、代わりに偶然または推定に基づいて選択を行う正確な瞬間を見つけて明確に定義することです。この構造をマッピングすることで、作成者はシステムを使用する人々にこれらの不確実な点を直接示すことができます。これにより、システムの更新は曖昧な記述から、AI がどのように結論に達したかに関する具体的で信頼できるレポートに変わります。 上記の保険のケーススタディに加えて、私は最近、調達代理店を構築するチームと協力しました。システムはベンダー契約をレビューし、リスクにフラグを立てました。当初、画面には「契約の確認中」という単純な進行状況バーが表示されていました。ユーザーはそれを嫌っていました。私たちの調査によると、彼らは条項の欠落による法的影響について不安を感じていることが分かりました。 デシジョンノード監査を実施することでこの問題を修正しました。この記事の最後に、この監査を実施するための段階的なチェックリストを記載しました。 私たちはエンジニアとセッションを実施し、システムがどのように機能するかを説明しました。私たちは「意思決定ポイント」、つまり AI が 2 つの良い選択肢から選択しなければならない瞬間を特定しました。 標準的なコンピュータ プログラムでは、プロセスは明確です。A が発生すると、B も常に発生します。 AI システムでは、プロセスは偶然に基づいていることがよくあります。 AI はおそらく A が最良の選択であると考えますが、確実性は 65% のみである可能性があります。 契約システムでは、AI が責任条件を社内規定と照合している瞬間を発見しました。完璧に一致することはほとんどありませんでした。 AI は 90% の一致で十分かどうかを判断する必要がありました。これは重要な決定点でした。
このノードを特定したら、ユーザーに公開しました。 「契約書の確認」の代わりにインターフェースが更新され、「責任条項は標準テンプレートと異なります。リスクレベルを分析しています。」と表示されました。 この特定のアップデートはユーザーに自信を与えました。彼らは代理人が責任条項をチェックしていることを知っていました。彼らは遅延の理由を理解し、バックエンドで望ましいアクションが発生しているという信頼を獲得しました。また、エージェントが契約書を作成した後、どこをさらに深く掘り下げるべきかもわかっていました。 AI がどのように意思決定を行うかを確認するには、AI ツールの機能に影響を与える (多くの場合隠れた) 選択を行うエンジニア、プロダクト マネージャー、ビジネス アナリスト、主要人物と緊密に連携する必要があります。ツールが実行する手順を書き出します。確率が満たされたためにプロセスの方向が変わるすべての場所にマークを付けます。これらは、より透明性を高めることに重点を置く必要がある場所です。 以下の図 2 に示すように、デシジョン ノード監査には次の手順が含まれます。
チームをまとめる: プロダクト オーナー、ビジネス アナリスト、デザイナー、主要な意思決定者、AI を構築したエンジニアを集めます。たとえば、 厄介な法的契約をレビューするために設計された AI ツールを構築している製品チームについて考えてみましょう。チームには、UX デザイナー、プロダクト マネージャー、UX 研究者、対象分野の専門家として活動する弁護士、テキスト分析コードを作成したバックエンド エンジニアが含まれます。
プロセス全体を描く: ユーザーの最初のアクションから最終結果まで、AI が実行するすべてのステップを文書化します。 チームはホワイトボードの前に立ち、複雑な契約の責任条項を AI が検索する主要なワークフローの全体の流れをスケッチします。弁護士がアップロード50 ページの PDF → システムがドキュメントを読み取り可能なテキストに変換します。 → AI が責任条項のページをスキャンします。 → ユーザーは待ちます。 → 数分後、ツールはユーザー インターフェイス上で見つかった段落を黄色で強調表示します。これは、ツールが対応する他の多くのワークフローでも同様に行われます。
不明確な点を見つける: AI が完全に一致するものが 1 つも存在しないオプションまたは入力を比較する箇所がないか、プロセス マップを確認します。 チームはホワイトボードを見て、あいまいな手順を見つけます。画像からテキストへの変換は、厳密なルールに従って行われます。具体的な責任条項を見つけるには推測が必要です。これらの条項の書き方は企業ごとに異なるため、AI は完全に一致する単語を見つけるのではなく、複数の選択肢を比較検討して予測を行う必要があります。
「最良の推測」手順を特定する: 不明瞭な箇所ごとに、システムが信頼度スコアを使用しているかどうかを確認します (たとえば、85% 確実かどうか)。これらは、AI が最終的な選択を行うポイントです。 システムは、どの段落が標準責任条項によく似ているかを推測する (確率を与える) 必要があります。最良の推測に信頼スコアを割り当てます。その推測が決定ノードになります。インターフェイスは、最終的な条項が見つかったことを示すのではなく、潜在的な一致を強調していることを弁護士に伝える必要があります。
選択を検討する: 各選択ポイントについて、実行されている特定の内部計算または比較を把握します (例: 契約の一部をポリシーに照合する、または壊れた車の写真を破損した車の写真のライブラリと比較する)。 このエンジニアは、システムがさまざまな条項を過去の企業訴訟の標準責任条項のデータベースと比較すると説明しました。テキストの類似性スコアを計算し、確率に基づいて一致を決定します。
明確な説明を作成する: AI が選択を行うときに発生する特定の内部アクションを明確に説明するユーザー向けのメッセージを作成します。 コンテンツ デザイナーは、まさにこの瞬間に向けて特定のメッセージを作成します。本文には次のように書かれています。潜在的な責任リスクを特定するために、文書のテキストと標準的な企業条項を比較します。
画面を更新する: 「契約を確認しています」のような曖昧なメッセージを置き換えて、これらの新しい明確な説明をユーザー インターフェイスに追加します。 設計チームは、汎用の Processing PDF 読み込みスピナーを削除しました。 AI が考えている間に、ドキュメント ビューアの真上にあるステータス バーに新しい説明が挿入されます。
信頼性を確認する: 新しい画面メッセージでユーザーに待ち時間や結果についての簡単な理由が表示されるようにして、ユーザーがより自信と信頼を感じるようにします。
影響/リスク マトリクス AI のプロセスを詳しく観察すると、AI が選択を行うポイントが数多く見つかるでしょう。 AI は、単一の複雑なタスクに対して数十の小さな選択を行う場合があります。それらをすべて表示すると、不要な情報が多すぎます。これらの選択肢をグループ化する必要があります。 影響/リスク マトリックスを使用すると、AI が実行するアクションの種類に基づいてこれらの選択肢を並べ替えることができます。影響/リスク マトリクスの例を次に示します。 まず、リスクが低く、影響が少ない決定を探します。 賭け金も少ないし、影響も少ない
例: ファイル構造の整理またはドキュメントの名前の変更。 透明性の必要性: 最小限。控えめなトースト通知またはログ エントリで十分です。ユーザーはこれらの操作を簡単に元に戻すことができます。
次に、一か八かの大きな影響を与える決定を特定します。 一か八かの大きな影響
例: ローンの申し込みを拒否したり、株式取引を実行したりする。 透明性の必要性: 高い。これらのアクションには作業証明が必要です。システムは、動作する前または動作直後に理論的根拠を実証する必要があります。
すべての買い注文と売り注文を同じように扱う金融取引ボットを考えてみましょう。 50,000 ドルの取引と同じ不透明度で 5 ドルの取引を実行します。ユーザーは、このツールが多額の取引における透明性の潜在的な影響を認識しているかどうか疑問に思うかもしれません。彼らは、システムを一時停止して、一か八かの取引のためにその機能を示す必要があります。解決策は、特定の金額を超えるトランザクションに対してレビュー ロジック ステートを導入し、ユーザーが実行前に決定の要因を確認できるようにすることです。 ノードをパターンにマッピング: 設計パターンの選択ルーブリック エクスペリエンスの主要な意思決定ノードを特定したら、表示する各ノードにどの UI パターンを適用するかを決定する必要があります。 「Designing For Agentic AI」では、インテント プレビュー (一か八かの制御用) やアクション監査 (遡及的安全性用) などのパターンを導入しました。どちらかを選択する際の決め手となるのは、可逆性です。 ごとにフィルタリングします正しいパターンを割り当てるために、影響マトリックスを介して意思決定ノードを実行します。 一か八かで取り消し可能: これらのノードにはインテント プレビューが必要です。ユーザーはアクション (データベースの完全な削除など) を簡単に元に戻すことができないため、実行前に透明性の瞬間が発生する必要があります。システムは一時停止し、その意図を説明し、確認を要求する必要があります。 一か八かの賭けと可逆性: これらのノードは、アクションの監査と元に戻すパターンに依存できます。 AI を活用した販売エージェントがリードを別のパイプラインに移動する場合、ユーザーに通知し、すぐに「元に戻す」ボタンを提供する限り、自律的に移動できます。 このようにノードを厳密に分類することで、「アラート疲労」を回避します。摩擦の多いインテント プレビューは本当に取り消しが不可能な瞬間のみに予約し、その他すべての速度を維持するためにアクション監査に依存します。
リバーシブル 不可逆的 低影響 タイプ: Auto-ExecuteUI: パッシブ トースト / LogEx: ファイルの名前変更 タイプ: 確認UI: 単純な元に戻すオプション例: 電子メールのアーカイブ 高い影響力 タイプ: レビューUI: 通知 + レビュー TrailEx: クライアントへの下書きの送信 タイプ: インテントプレビューUI: モーダル/明示的権限例: サーバーの削除
表 1: 影響と可逆性のマトリックスを使用して、透明性の瞬間をデザイン パターンにマッピングできます。 定性的検証: 「待てよ、なぜ?」テスト ホワイトボード上で潜在的なノードを特定することはできますが、人間の行動によってそれらを検証する必要があります。マップがユーザーのメンタル モデルと一致するかどうかを検証する必要があります。私は「Wait, Why?」というプロトコルを使用しています。テスト。 エージェントがタスクを完了するのを見るようユーザーに依頼します。大きな声で話すように指示してください。彼らが質問するたびに、「待って、なぜそうなったのですか?」または「詰まっていますか？」または「聞こえましたか？」 — タイムスタンプをマークします。 これらの質問はユーザーの混乱を示しています。ユーザーは自分のコントロールが失われていくのを感じます。たとえば、医療スケジュール管理アシスタントに関する調査では、ユーザーはエージェントが予約を入れる様子を観察しました。画面は 4 秒間静止しました。参加者は一貫して、「確認しているのは私のカレンダーですか、それとも医師のカレンダーですか?」と質問しました。
この質問により、透明性の瞬間が欠けていることが明らかになりました。システムは、この 4 秒の待機を 2 つの異なるステップに分割する必要がありました。「空き状況の確認」と、それに続く「プロバイダーのスケジュールとの同期」です。 この小さな変更により、ユーザーが表明した不安のレベルが軽減されました。 システムの動作のみを説明する場合、透明性は失われます。インターフェースは、技術的なプロセスをユーザーの特定の目標に結び付ける必要があります。 「空き状況を確認しています」と表示された画面は、コンテキストが欠如しているため、表示されません。ユーザーは、AI がカレンダーを見ていることは理解していますが、その理由はわかりません。 行動と結果を組み合わせる必要があります。システムは、この 4 秒間の待機を 2 つの異なるステップに分割する必要があります。まず、インターフェースに「カレンダーをチェックして営業時間を確認しています」と表示されます。次に、「予約を確保するためにプロバイダーのスケジュールと同期しています」に更新されます。これにより、技術的なプロセスがユーザーの実際の生活に根ざしたものになります。 地元のカフェの在庫を管理する AI を考えてみましょう。システムで供給不足が発生しました。 「ベンダーに連絡する」または「オプションを検討する」というインターフェースは不安を引き起こします。マネージャーは、システムが注文をキャンセルしているのか、それとも高価な代替品を購入しているのか疑問に思っています。より良いアプローチは、意図した結果を説明することです。「金曜日の配送スケジュールを維持するために代替サプライヤーを評価する」。これにより、AI が何を達成しようとしているのかがユーザーに正確にわかります。 監査の運用化 デシジョン ノード監査を完了し、影響とリスク マトリックスを通じてリストをフィルタリングしました。これで、透明性を保つために重要な瞬間のリストが完成しました。次に、UI でそれらを作成する必要があります。このステップでは、さまざまな部門にわたるチームワークが必要です。デザインツールを使用して自分で透明度をデザインすることはできません。システムが舞台裏でどのように動作するかを理解する必要があります。 ロジックのレビューから始めます。主任システム設計者と面談します。意思決定ノードのマップを持参してください。システムが実際にこれらの状態を共有できることを確認する必要があります。技術的なシステムでは、私が示したい正確な状態が明らかにならないことがよくあります。エンジニアは、システムが一般的な「動作中」ステータスを返しただけだと言うかもしれません。詳細なアップデートを推進する必要があります。特定の通知を送信するにはシステムが必要ですテキストの読み取りからルールの確認に切り替わるとき。その技術的なつながりがなければ、設計を構築することは不可能です。 次に、コンテンツ デザイン チームに参加してもらいます。 AI の動作の技術的な理由はわかっていますが、明確で人間に優しい説明が必要です。エンジニアは基礎となるプロセスを提供しますが、コンテンツ デザイナーはそれを伝える方法を提供します。これらのメッセージを一人で書かないでください。開発者は「関数 402 を実行中」と書くかもしれませんが、これは技術的には正しいですが、ユーザーにとっては意味がありません。デザイナーは「思考」と書くかもしれませんが、これは親しみやすいですが、漠然としすぎています。コンテンツ戦略家は適切な中間点を見つけます。ユーザーを混乱させることなく AI が機能していることを示す、「責任リスクをスキャンしています」などの具体的なフレーズを作成します。 最後に、メッセージの透明性をテストします。最終製品が構築されるまでテキストが機能するかどうかを確認する必要はありません。私は、ステータス メッセージだけが変わる単純なプロトタイプで比較テストを実施します。たとえば、あるグループ (グループ A) には「本人確認を行っています」というメッセージを表示し、別のグループ (グループ B) には「政府データベースを確認しています」というメッセージを表示します (これらは架空の例ですが、要点は理解できます)。次に、どの AI がより安全だと感じるかを尋ねます。特定の言葉が心配を引き起こす一方で、他の言葉は信頼を築くことがよくあることに気づくでしょう。文言はテストして有効であることを証明する必要があるものとして扱う必要があります。 これにより設計プロセスがどのように変化するか これらの監査を実施すると、チームの連携方法が強化される可能性があります。洗練されたデザインファイルを渡すのをやめます。乱雑なプロトタイプと共有スプレッドシートを使い始めます。コアツールは透明マトリックスになります。エンジニアとコンテンツ デザイナーがこのスプレッドシートを一緒に編集します。これらは、ユーザーが読む単語に正確な技術コードをマッピングします。 チームはロジックのレビュー中に摩擦を経験することになります。デザイナーがエンジニアに、経費報告書に提出された取引を AI がどのようにして拒否するかを尋ねたと想像してください。エンジニアは、バックエンドが「エラー: データがありません」のような一般的なステータス コードのみを出力すると言うかもしれません。デザイナーは、これは画面上で実用的な情報ではないと述べています。デザイナーはエンジニアと交渉して、特定の技術的なフックを作成します。エンジニアは、レシート画像の欠落など、欠落しているものをシステムが正確に報告するように、新しいルールを作成します。 コンテンツ デザイナーは、このフェーズでは翻訳者の役割を果たします。開発者は、「ベンダー マッチングの信頼しきい値を計算しています」のような技術的に正確な文字列を作成する場合があります。コンテンツ デザイナーは、その文字列を、特定の結果に対する信頼を構築するフレーズに変換します。ストラテジストはこれを「金曜日の配達を確保するために地元ベンダーの価格を比較する」と書き直しました。ユーザーはアクションと結果を理解します。 部門横断的なチーム全体がユーザー テスト セッションに参加します。彼らは、実際の人間がさまざまなステータス メッセージに反応するのを観察します。画面に「取引を実行しています」と表示されてユーザーがパニックになるのを見て、チームはアプローチを再考する必要があります。エンジニアとデザイナーはより良い表現について意見を合わせます。株式を購入する前にテキストを「十分な資金を確認する」に変更します。一緒にテストすることで、最終的なインターフェイスがシステム ロジックとユーザーの安心感の両方に役立つことが保証されます。 これらの追加アクティビティをチームのカレンダーに組み込むには時間がかかります。ただし、最終的には、チームはよりオープンにコミュニケーションを図り、ユーザーは AI を活用したツールが自分に代わって何を行っているのか (およびその理由) をよりよく理解できるようになります。この統合されたアプローチは、真に信頼できる AI エクスペリエンスを設計するための基礎となります。 信頼は設計上の選択です 私たちは信頼を、優れたユーザー エクスペリエンスから得られる感情的な副産物として見なすことがよくあります。信頼は、予測可能なコミュニケーションの機械的な結果であると考える方が簡単です。 適切な情報を適切なタイミングで提示することで信頼を築きます。ユーザーを圧倒するか、機械を完全に隠すことによって、それを破壊します。 特にエージェント AI ツールおよび製品の場合は、デシジョン ノード監査から始めます。システムが判断を下す瞬間を見つけます。それらの瞬間をリスク マトリックスにマッピングします。賭け金が高い場合は、箱を開けてください。作品を見せてください。 次の記事では、これらの瞬間をデザインする方法、つまりコピーを作成する方法、UI を構成する方法、エージェントが間違った場合に避けられないエラーを処理する方法について説明します。 付録: デシジョンノード監査チェックリスト フェーズ 1: セットアップとマッピング ✅ チームをまとめる: プロダクトオーナー、ビジネスアナリスト、デザイナー、主要な意思決定者と AI を構築したエンジニア。 ヒント: 実際のバックエンド ロジックについてはエンジニアに説明してもらう必要があります。このステップを単独で試行しないでください。 ✅ プロセス全体を描く: ユーザーの最初のアクションから最終結果まで、AI が実行するすべてのステップを文書化します。 ヒント: これらの最初のステップを引き出すには、多くの場合、物理的なホワイトボード セッションが最適です。 フェーズ 2: 隠されたロジックを見つける ✅ 不明確な点を見つける: AI が完全に一致するものが 1 つも存在しないオプションまたは入力を比較する箇所がないか、プロセス マップを確認します。 ✅ 最良の推測手順を特定する: 不明瞭な箇所ごとに、システムが信頼スコアを使用しているかどうかを確認します。たとえば、システムが 85% 確実かどうかを尋ねます。これらは、AI が最終的な選択を行うポイントです。 ✅ 選択を検討する: 各選択ポイントについて、実行されている特定の内部計算または比較を把握します。例としては、契約の一部をポリシーに照合することが挙げられます。別の例には、壊れた車の写真を破損した車の写真のライブラリと比較することが含まれます。 フェーズ 3: ユーザー エクスペリエンスの作成 ✅ 明確な説明を作成する: AI が選択を行うときに発生する特定の内部アクションを明確に説明するユーザー向けのメッセージを作成します。 ヒント: メッセージを具体的な現実に根付かせてください。 AI が地元のカフェでクライアントとの会議を予約する場合、システムがカフェの予約システムをチェックしていることをユーザーに伝えます。 ✅ 画面を更新する: これらの新しい明確な説明をユーザー インターフェイスに追加します。 「契約書の確認」などの曖昧なメッセージを具体的な説明に置き換えます。 ✅ 信頼性の確認: 新しい画面メッセージで、待ち時間や結果についての簡単な理由がユーザーに示されていることを確認します。そうすることで、彼らは自信と信頼を感じることができるはずです。 ヒント: これらのメッセージを実際のユーザーでテストして、達成される特定の結果を理解していることを確認します。
