良いプロンプトを覚えるより、AIが何をできるかを知る
名義：roto
1. 「どう聞けばいいか」から考えそうになった
前回の記事では、AI活用の相談に向き合う中で、問題はAIの使い方だけではなく、仕事に必要な知識の通り道にもあると書いた。
前回も書いたとおり、ヒアリングから私が要約したのは、「AIを活用したいけれど、どうやって使えばよいか分からない」という内容だった。
この問いに答えようとすると、最初に思いつきやすいのは、使いやすいプロンプトを用意することだ。
「この順番で入力してください」
「目的、条件、出力形式を書きましょう」
そうした型が役に立たないわけではない。何もない状態から質問を始めるより、入口になる型があったほうが試しやすい。
けれども、型だけを渡しても、「自分の仕事の何に使えるのか」が見えていなければ、使い道は広がらない。良い聞き方を覚える前に、聞こうとしている相手が何をできるのかを知らなければならない。
私は、AI活用を考える順番を、ここでも入れ替える必要があると思った。
2. 「AIが使える」だけでは、できることが分からない
一口にAIといっても、できることは同じではない。
入力した文章に答えるだけのものもあれば、長い資料を読めるものもある。新しい情報を調べられる場合もあれば、与えられた情報だけで回答する場合もある。ファイルを作成・変更したり、コードを実行したり、外部のサービスと接続して操作したりできるものもある。
さらに、同じ名前のAIを使っていても、利用する画面、契約、接続されている機能、渡された権限によって、実際にできることは変わる。
ここからは、現場でのヒアリングから直接確認した事実ではなく、AI活用を設計する中での私の整理である。
AIの能力は、モデルそのものの賢さだけでは決まらない。
モデルの能力
× 利用できる道具
× アクセスできる情報
× 与えられた権限
= その場で実際にできること
だから、「AIに頼めばできます」という説明だけでは足りない。どのAIを、どの環境で、何と接続して使うのかまで見なければ、仕事に使える範囲は分からない。
3. まず四つの段階に分けてみる
AIができることを理解するとき、私は大きく四つの段階に分けて考えると整理しやすいと思っている。
一つ目は、考える支援である。文章の要約、比較、分類、案出し、説明の言い換えなど、渡された情報をもとに回答する。
二つ目は、情報へ到達する支援である。検索したり、指定された資料や接続先を読んだりして、回答に使う材料を集める。
三つ目は、作業する支援である。ファイルを作る、表を更新する、コードを実行するなど、回答を返すだけでなく、手元の成果物を変える。
四つ目は、外部へ働きかける支援である。メッセージを送る、予定を登録する、システムの状態を変更するなど、別の人やサービスに影響する操作を行う。
この四段階は、どこまで任せるかを見るための整理である。文章の整理だけで足りる仕事もあれば、外部操作が必要な仕事もある。
重要なのは、自分が今使っているAIが、どの段階まで実行できる状態なのかを知ることである。
4. 能力を知らないと、依頼がずれる
能力が分からないままプロンプトだけを工夫すると、依頼と実際の機能がずれやすい。
例えば、AIが参照できない社内資料について「過去の事例から判断して」と頼んでも、その資料に基づく回答はできない。検索機能がないのに最新情報を求めれば、確認されていない内容を答えとして受け取る危険がある。
反対に、ファイルを扱えるAIへ、毎回すべての文章を貼り付けて要約だけを頼んでいるなら、使える能力の一部しか見えていない可能性がある。
ここでは、依頼とAIの機能がかみ合っていない。ない能力を言葉で補おうとし、ある能力は知らないまま使わずにいる。
どれほど丁寧な指示を書いても、接続されていない情報を読むことはできない。反対に、できる作業を知らなければ、AIはいつまでも「質問に答えるだけの画面」に見える。
5. プロンプトは呪文ではなく、仕事の依頼である
AIの能力が見えたあとで、プロンプトの役割も変わって見えてくる。
プロンプトは、特定の言葉を並べれば急に性能が上がる呪文ではない。そのAIが使える能力に対して、目的、材料、条件、期待する結果を渡す仕事の依頼である。
文章を整理してもらうなら、何のために、誰が読み、何を残したいのかを伝える。複数の資料を比較してもらうなら、対象となる資料と比較の観点を渡す。ファイルを扱えるなら、どのファイルを対象にするのかを決める。
言い回しの巧さよりも、AIが仕事をするために必要な材料がそろっているかのほうが重要になる。
一方で、できることと、やってよいことは同じではない。AIが実際のファイルや外部サービスを扱えるほど、どこまで任せるかを別に考える必要がある。この境界の設計は大切だが、ここでは詳しく扱わない。
まず必要なのは、プロンプト集を増やすことではなく、使うAIの能力を具体的な仕事の言葉へ翻訳することだ。
6. 導入前に、能力の地図をつくる
AIを仕事へ持ち込む前に、最低限、次の点を確認しておくとよい。
- 文章への回答だけか、資料やファイルも扱えるか
- 新しい情報を検索できるか、渡した情報だけで答えるか
- 回答案を出すだけか、実際の成果物を変更できるか
- 外部の人やサービスへ操作を行えるか
- その機能を使うために、どの情報と権限が必要か
これは製品の機能一覧を眺めるだけでは終わらない。
AIの変化は速い。機能一覧を一度読んでも、実際に使う頃には状況が変わっていることがある。結局は、仕事の中で使いながら確かめるしかない。
使っていると、気になる機能や活用事例が出てきて、自分でも検索するようになる。検索や閲覧を続ければ、関連する記事や動画も表示される。そこで知った使い方をまた試す。私の場合は、この繰り返しで、AIを「質問に答える画面」ではなく、仕事のどこに使えるかで見るようになった。
「要約できる」ではなく、「会議記録から、次の担当者が判断できる要点を整理できる」のように、仕事の場面へ置き換える。反対に、「社内の過去事例を知っている」と思い込まず、実際にどの資料へアクセスできるかを確認する。
そこまで分かれば、次に試す仕事も選びやすい。
7. AIの能力が分かっても、知識は生まれない
ただし、AIが何をできるかを理解しても、前回の記事で見えた問題が消えるわけではない。
AIが資料を読めても、ベテランの経験がどこにも残っていなければ、その判断は材料にできない。検索できても、検索する対象がなければ答えには届かない。
AIの能力が分かると、AIに任せられる範囲と、人の経験へ接続すべき範囲を分けやすくなる。
ここは、今後の活動で確かめていきたい仮説でもある。AIの能力を仕事の言葉で示せば、利用者は自分の困りごととAIを結びつけやすくなるのか。単にプロンプト例を配るより、実際の使い道を見つけやすくなるのか。相談会の中で確認していきたい。
そして、その先には別の課題が残る。
答えを持っているベテランが忙しいとき、どうすれば知識継承の活動へ参加してもらえるのか。
次回は、知識を「引き出す」前に考えたい、ベテランとの向き合い方について書く。