先に、言い切ってしまいます。あなたがAIツールを使いこなせていない気がするのは、たぶん、あなたのせいではありません。
白状しますと、筆者自身がそうでした。
筆者はAIと一緒にアプリを作る、いわゆるバイブコーディングをしています（この道に迷い込んだ経緯は、自己紹介で白状しております）。始めたばかりのころは、AIのデスクトップアプリしか存在を知りませんでした。チャット画面に質問を打ち、作業をお願いする。AIはそれに対して、いつも真摯に答えてくれる訳です。
当時の作業風景を思い出すと、なかなか涙ぐましいものがあります。チャット画面でコードを書いてもらい、それを自分でコピーして、エディターに貼り付ける。エラーが出たら、エラー文をまたコピーして、チャットに貼り戻す。この往復を、一日に何十回。それでも「AIと開発ってすごいなあ」と、けっこう満足していたのです。我ながら、おめでたい話です。
ところが、あるとき知ってしまいました。同じAIに、コードエディターの拡張機能として動くモデルがあること。さらに、CLI——黒い画面のコマンドライン経由で動くタイプのAIなら、ファイルを直接読み書きし、編集からテストの実行まで、まとめて作業してくれること。つまりあのコピペの往復は、そもそも要らなかった。試した日から、頼める作業の種類も量も、文字どおり激増しました。
うれしさ半分、脱力半分でした。だって、何か月も一緒に作業してきたのに……。あの何十往復のコピペを、AIは隣でずっと見ていたわけです。追加のティップスとして、ひとことくらい教えてくれても良かったのに、、、
道具は、できることを黙っている
この体験、笑い話のようでいて、道具というものの本質を突いていると思うのです。
AIは、聞けば何でも答えてくれます。でも、こちらが聞かないことは、教えてくれない。 「もっと良い使い方がありますよ」と、向こうから割り込んではこないのです。
会社員時代を思い返すと、この「割り込み」をしてくれるのは、決まって近くの席の先輩でした。新人の筆者が手作業で何かをぽちぽちやっていると、通りすがりに「え、それ、まだ手でやってるの？」と口を挟んでくる。教えを乞うたわけでもないのに、勝手にショートカットやら定型フォーマットやらを置いていく。当時は少々うるさく感じたものですが（すみません）、いま思えば、あの節介こそが道具の使い方の伝達経路だったのです。そして、あの節介が、道具そのものには備わっていない。
もうひとつ大事なことがあります。ユーザーにとって「知らない機能」は、無いのと同じだ、ということです。開発側がどれだけ強力な機能を積んでも、ユーザーの目に入る経路がなければ、その価値はゼロのまま眠り続けます。筆者のCLIが、まさにそれでした。機能は最初からそこに在った。無かったのは、筆者がそれに出会う経路だけ。そして道具の価値は、積んだ機能の総量ではなく、ユーザーに見えた分でしか発揮されないのです。
だから、道具の側に「できることを、伝える仕掛け」を最初から設計しておく必要があります。先輩の節介を、設計で肩代わりする。これが、この記事の主役であるオンボーディングという仕事です。
「教えてくれない」を設計で補う ― AIツールのオンボーディングとは・7つの型
筆者の脱力体験を、作り手の言葉に翻訳しておきます。ここが今日の地図です。
プロダクトのオンボーディングとは
オンボーディングとは、初めてのユーザーが道具の価値にたどり着くまでを案内する、一連の体験設計のことです。人事の世界の「新入社員のオンボーディング」と同じ言葉ですが、ここではプロダクトの話。アカウント作成から「初めて役に立った瞬間」までの道のりを、迷子を出さずに歩いてもらうための設計を指します。
なぜAIツールでとくに重要なのか
従来のソフトは、メニューやボタンの一覧が「できることのカタログ」を兼ねていました。AIツールはその手がかりが薄く、白紙の入力欄だけが置かれがちです。できることの範囲が広いのに、範囲が見えない。この組み合わせが、「何を頼めばいいか分からない」という最初のつまずきを生みます。放置すると、道具を配っても使われない——という、あの定着問題に直結します（この構図は生成AIで業務効率化する方法で書いたとおりです）。
発見可能性（ディスカバラビリティ）とは
ユーザーが、道具のできることを自力で見つけられる度合いを、発見可能性と呼びます。オンボーディングは初回の案内、発見可能性は使い続ける中での「気づける仕掛け」。両方そろって、ようやく機能は「存在する」ことになります。筆者のCLI事件は、発見可能性の欠如が数か月単位の機会損失になった実例です。しかも当人は損失に気づけません。「いまのやり方で満足している」ユーザーの満足は、より良いやり方を知らないだけの満足かもしれない——作り手はそう疑ってかかる必要があります。
オンボーディング設計の7つの型
| 型 | 何をするか | 効く場面 |
|---|---|---|
| 1. 入力例・サジェスト | 「こんなことが頼めます」を数個見せる | 白紙の入力欄の前の停止 |
| 2. テンプレート | 完成形の雛形から始めてもらう | ゼロから作る不安 |
| 3. 選択式ウィザード | 少ない選択肢を一問ずつ聞く | 初期設定・要件の聞き取り |
| 4. 空状態の案内 | データが無い画面を案内板にする | 最初の一歩の迷子 |
| 5. プロダクトツアー | 主要機能を順に指し示す | 画面が多いツール |
| 6. チェックリスト | やることを数個の達成項目にする | 設定が数段階あるとき |
| 7. 最初の成功への最短路 | 価値を体感する瞬間まで最短で連れて行く | すべての土台 |
型1｜入力例・サジェスト
白紙の欄に、例文やよく使う依頼のボタンを添えます。全機能を並べる必要はなく、数個で十分。大事なのは例文の選び方で、そのツールの得意技が伝わり、かつユーザーが自分の仕事に引き寄せやすいものを選びます。「議事録を要約して」のような、押した瞬間に自分の用途が想像できる例が良い例です。最初の一歩さえ示せば、人はそこから自分で広げていきます。
型2｜テンプレート
ゼロから書かせず、完成形の雛形を選んで直してもらう方式です。「白紙から作る」と「あるものを直す」では、心理的な重さがまるで違います。加えてテンプレートには、完成形を見せることで「このツールで作れるものの水準」を無言で伝える効果もあります。品質の期待値合わせを、説明ゼロでやってのける型です。
型3｜選択式ウィザード
聞くべきことを、少ない選択肢の質問に分解して、一問ずつ出す方式です。一度に全部を見せない。選択肢は多くても3〜4個まで、質問は前の答えで次が変わる形にすると、対話のテンポが生まれます。後述しますが、筆者はテレビの初期設定でこの型の威力を体感しました。
型4｜空状態（エンプティステート）の案内
まだデータの無い画面は、放っておくとただの白紙です。そこに「最初にこれをしてみましょう」を置けば、白紙が案内板に変わります。空状態は、初回ユーザーが必ず通るのに、開発の優先度では後回しにされがちな場所——つまり、実はいちばん確実に読まれるのに、いちばん手を抜かれている場所です。ここを埋めるだけで初回体験は目に見えて変わります。
型5｜プロダクトツアーの注意点
画面を順に紹介するツアーは、作り手が満足しがちな型でもあります。ユーザーは早く使いたいので、長いツアーは読み飛ばされる前提で。スキップボタンを目立つ場所に置き、3ステップを超えるなら他の型に分解したほうが届きます。ツアーの完走率が高くても、それは「読まされた」だけかもしれない、という疑いも忘れずに。
型6｜チェックリスト
初期設定が数段階あるなら、進捗の見えるチェックリストにします。「残り2つ」が見えるだけで、人は完走しやすくなります。最初の1つは自動でチェック済みにしておく——「もう始まっている」と感じさせる——のが定番の小技です。
型7｜最初の成功体験までの最短路
7つの型の目的は、結局これひとつです。ユーザーが「お、役に立った」と感じる最初の瞬間まで、何分で連れて行けるか。そのために、成功体験の手前にある登録・設定・入力を、後回しにできるものはすべて後回しにする。機能紹介ではなく、成功体験の前倒しがオンボーディングの本体です。
よくある失敗
| 失敗 | 何が起きるか |
|---|---|
| 全機能ツアー | 情報量に圧倒され、結局どれも試されない |
| 説明書・マニュアル頼み | 読まれない。読ませる前提が既に失敗 |
| 初回に全部設定させる | 価値を体感する前に力尽きる |
| 出しっぱなし | 新機能が追加されても、誰も気づかない |
最後の「出しっぱなし」が、筆者のCLI事件の正体です。オンボーディングは初回だけの仕事ではなく、機能が増えるたびに「それとなく知らせる」継続の仕事でもあります。新機能のリリースノートを書いて満足しない。使っている画面のその場所に、小さく「新しいやり方があります」を置く。読みに来てもらうのではなく、通り道に置くのがコツです。
そしてもうひとつ、1番目の「全機能ツアー」は、社内でいちばん通りやすい失敗でもあります。関係部署の機能を平等に紹介したい、という力学が働くからです。オンボーディングの設計会議では「何を見せるか」より「何を見せないか」が本題だ、と最初に合意しておくと、この力学に流されにくくなります。
効果の測り方
| 指標 | 何が分かるか |
|---|---|
| 初回セットアップ完了率 | 入口で脱落していないか |
| 最初の成功体験までの時間 | 価値到達の道が短いか |
| 翌週の再訪率 | 定着に向かっているか |
派手なPV数より、地味な「翌週の再訪」が定着の先行指標です。数字が悪いときに見るべきは離脱の場所で、どの画面で・どの入力で手が止まったかまで分かって、はじめて7つの型のどれを当てるかが決まります。
進め方4ステップ
①新規ユーザーの目線で自分のツールを最初から触る→②どこで手が止まるかを観察する→③止まった場所に7つの型から合うものを当てる→④3つの指標で測って直す。この繰り返しです。①は自分でやるだけでなく、できれば実ユーザーに近い人に初見で触ってもらうのが確実です。作った本人は、迷い方を忘れてしまっているからです。画面設計全体の進め方はアプリのUI/UXデザインが詳しいです。
——地図はここまで。ここからは、設計の見事さに唸らされた、わが家の新入りの話をさせてください。
テレビは、3択しか聞いてこなかった
最近、わが家のテレビを買い替えました。設置して電源を入れると、初期設定が始まります。身構えますよね、ああいうの。説明書を膝に置いて、長い夜になるやつだと。
ところが、拍子抜けするほどスムーズに終わったのです。
思い返すと、あのテレビはWi-Fiのパスワード入力を除いて、ほとんど何も「入力」させませんでした。画面に出てくるのは、多くても3択くらいまでの選択肢ばかり。お住まいの地域はどれ。アンテナはどのタイプ。ネットに繋ぎますか。リモコンでぽちっ、ぽちっ、と選んでいくだけで、いつの間にか設定が終わっている。説明書は、結局一度も開きませんでした。
これ、さっきの地図でいう選択式ウィザードの、きれいなお手本です。
選択肢が優れているのは、こちらに「思い出させない」からです。自由入力は、答えをこちらの頭の中から取り出させる操作です。「お使いの回線の種別を入力してください」と聞かれたら、筆者は固まります。でも「光回線／ケーブル／その他」と並べば、選べる。答えを知らなくても、見れば分かる形になっているからです。選択肢は、答えを向こうが並べてくれて、こちらは選ぶだけ。判断の重さが、まるで違う。しかも一度に一問ずつだから、迷いようがない。
考えてみれば、あのテレビの初期設定は、実際にはかなりの項目数があったはずなんです。地域、アンテナ、ネット、画質、省エネ設定。全部を一枚のフォームに並べられたら、確実にうんざりしていた。項目の数は同じでも、出し方で体験は別物になる。 これが設計の力というものなのでしょう。
AIツールの初回体験も、まったく同じ作り方ができるはずなんです。「さあ、何でも聞いてください」と白紙を差し出す代わりに、「まずは、どれを試してみますか」と3つ差し出す。それだけで、最初の5分の景色は変わります。
最初の5分に、何を置くか
ここまでを、作り手への言葉にまとめ直します。
最初の5分に置くべきは、機能の紹介ではなく、最初の成功体験までの最短路です。あなたのツールの「お、役に立った」は何か。それを1つに決めて、そこまでの道から、迷う要素を全部どかす。入力は選択肢に、白紙は入力例に、設定はあとまわしに。
「1つに決める」が、実は難所です。作り手には、見せたい機能がたくさんある。でもユーザーの最初の5分は、1本道しか歩けません。社内向けのAIツールなら「いちばん多い部署の、いちばん頻度の高い仕事がひとつ片付く」を最初の成功に据える。プロダクトなら「契約前に感じていた課題がひとつ消える」を据える。決め方の軸は、開発の都合ではなく、ユーザーの動機の側にあります。
そして、勇気がいるのは「見せない」ほうの決断です。せっかく作った機能を、初回画面に全部並べたくなる。その気持ちが、ユーザーを圧倒します。機能を足すほど使われなくなる話は、以前の記事で書いたとおりでして、オンボーディングはその入口版です。最初は3つでいい。残りは、使い込む中で「それとなく」出会わせる。
筆者のCLI事件のような機会損失を防ぐのは、この「それとなく」の設計です。使い込んだユーザーにだけ、次の一歩をそっと見せる。道具の側からの、小さな節介。あれが欲しかったんです、ほんとうに。
あなたのツールを、新規アカウントで開いてみる
明日からできる確認を、ひとつだけ。
自分のプロダクトなり、社内に配ったAIツールなりを、まっさらな新規アカウントで開いてみてください。ログイン直後の画面で、手が止まらずに「最初の成功」までたどり着けるか。時計で測ってみる。何分かかったか、何回迷ったか。
それだけで、あなたのツールのオンボーディングが仕事をしているかどうか、だいたい分かります。筆者も自作アプリでやってみたところ、白紙の画面がひとつ、ぽつんと出てきました。ぐぬぬ。人のことは言えないのでした。
夜のリビングでは、今日も新しいテレビが、静かに次の3択を待っています。設定が終わっても、あの控えめな聞き方は、どこか感じが良かったなと思い出すのです。道具の第一印象は、ああやって作るものなのでしょう。
AIツールのオンボーディングのよくある質問
プロダクトのオンボーディングとは何ですか？
初めてのユーザーがツールの価値を体感する瞬間まで、迷子を出さずに案内する体験設計のことです。入社手続きのオンボーディングと同じ言葉ですが、対象はプロダクトの初回体験。機能紹介ではなく「最初の成功体験までの最短路」を作ることが本体です。
AIツールでオンボーディングがとくに重要なのはなぜですか？
従来のソフトと違い、AIツールはメニューの一覧という「できることのカタログ」が薄く、白紙の入力欄だけが置かれがちだからです。できることが広いのに見えない状態は、最初のつまずきと未活用の機能を生みます。筆者自身、主要な機能の存在を数か月知らずに使っていました。
何から手を付ければよいですか？
新規アカウントで自分のツールを開き、最初の成功体験までの時間を測ることからです。手が止まった場所に、入力例・テンプレート・選択式ウィザード・空状態の案内など7つの型から合うものを当てはめ、完了率と翌週の再訪で効果を確かめます。
プロダクトツアーは入れるべきですか？
短ければ有効ですが、読み飛ばされる前提で設計してください。3ステップを超える説明は、空状態の案内やチェックリストなど「使いながら気づける」型に分解するほうが届きます。ツアーの完走率だけを成果指標にするのは危険です。判断に迷ったら、「この説明は、その操作をする瞬間に、その場所で出せないか？」と問い直してみてください。出せるなら、ツアーで前もって説明する必要はありません。
既存ユーザーに新機能を知らせるには、どうすればよいですか？
リリースノートやお知らせページは、残念ながらほとんど読まれません。効くのは、関係する画面のその場所に「新しいやり方があります」を小さく出す方法です。筆者がCLIの存在を数か月知らずにいたように、ユーザーは能動的には探しに来ない前提で、通り道に置く設計にします。ただし頻度が高すぎると広告扱いされて無視されるので、本当に価値のある更新に絞るのが条件です。
機能が多いツールでは、初回にどこまで見せるべきですか？
最初の成功に必要な最小限だけです。全機能を並べると、情報量がユーザーを圧倒し、どれも試されなくなります。残りの機能は、使い込みに応じて「それとなく」紹介する継続的な仕掛け（新機能の控えめな案内など）に回します。
効果はどの指標で測ればよいですか？
初回セットアップ完了率・最初の成功体験までの時間・翌週の再訪率の3つが基本です。とくに翌週の再訪は定着の先行指標になります。数字の裏の理由を知りたいときは、実ユーザーに初回体験を触ってもらい、手が止まる場所を観察するのが確実です。
この記事は、ARCHECOが運営するメディア「AI・新規事業戦略大学」でお届けしました。ARCHECOは、UI/UXデザインとプロダクト開発を強みに、お客さまと並走しながら「使われるもの」をつくっているチームです。ご相談・お問い合わせはこちらからどうぞ。
