AI 機能を考えるときの一番よい出発点は、具体的なタスクです。今だれが何をしていて、どの部分に手間がかかり、役に立つ結果とはどういうものかを教えてください。そのうえで、AI が役立ちそうな部分と、周りのソフトウェアがすべきことを決められます。
たとえばサポートチームなら、承認済みのヘルプ記事をもとに返信の下書きを作るのがそのタスクかもしれません。成功とは、スタッフがすぐに確認できる使える下書きで、参照した情報へのリンクが付いている状態です。何でも答える汎用のチャットボットを追加するより、ずっと明確な目標です。
入力、出力、判断を決める
機能が受け取る情報、返すべき内容、その結果を使う人を書き出してください。確認の質問をすべき場合や、人に引き継ぐべき場合も含めます。返信を提案するだけのツールと、自動で送信するツールとでは、負う責任が違います。
通常のソフトウェアのルールで確実に処理できないかも検討してください。決まった計算や既知の承認ルールは、従来のアプリケーションのロジックで扱うほうが向いていることがあります。曖昧さのある言語のタスクには AI を使い、はっきりしたビジネスルールはコードに残す、という分け方ができます。
使ってよい情報を決める
承認済みの情報源と、それに関わる権限を一覧にしてください。サポートの例なら、返信に使えるのは公開済みのドキュメントと、対応しているスタッフがアクセスを許されている情報です。ほかのお客様の記録を見せてしまってはいけません。
外部のサービスに情報を送る前に、どのデータが本当に必要かを見極め、選んだ事業者の最新の利用規約、データの保持設定、利用できる管理機能を確認してください。製品の宣伝文句だけを根拠に、プライバシーの保証を約束するのは避けましょう。データに関する要件は、実際の業務の流れに合わせて決める必要があります。
操作に境界を設ける
操作を提案する権限と、実行する権限は分けて考えてください。返金の説明文の下書きと、お金を動かす指示とでは、必要な管理が違います。影響の大きい操作では、人が具体的な結果を確認して承認すべき箇所を決めておきましょう。
お客様からの文章、文書、外部のページには、本来のタスクと矛盾する指示が含まれていることがあります。OWASP のプロンプトインジェクションに関するガイダンスでは、このリスクが説明されています。正しく振る舞うようプロンプトでお願いするだけでなく、機能がアクセスできるもの、実行できることに対する制御が必要です。
モデルを評価する前に例を用意する
良い結果と受け入れられない結果の例を含む、代表的なタスクの一式を用意してください。情報が不完全なもの、曖昧な依頼、古くなった資料、機能が断るか担当者に回すべき依頼も含めます。必要に応じて、匿名化した例や合成した例を使いましょう。
回答は承認済みの情報に裏づけられているか。
情報源がないときに、詳細をでっち上げていないか。
利用者のアクセス権と、機能に許された操作の範囲を守っているか。
確認する人が、結果を理解して修正できるか。
役に立つ結果一つあたりの時間とコストは、業務の流れにとって許容範囲か。
手法を比べる前に、これらの確認項目を決めておきましょう。デモで一度見事な答えが出ても、それだけではほとんど何もわかりません。評価は、その機能が扱う仕事の幅全体をカバーする必要があります。
不確かさ、待ち時間、サービス障害に備える
AI の回答は、間違っていたり不完全だったりすることがあります。画面で回答の根拠をどう示すか、利用者がどうやって助けを求められるかを決めてください。サービスが遅いときや使えないときも、依頼を保存する、手作業で続けられるようにするなど、プロダクトのほかの部分はわかりやすい結果を返すべきです。
確認と修正も含めて、業務の流れ全体を測りましょう。下書きがすぐにできても、参照元の手がかりがないためにスタッフが細部まですべて確認しなければならないなら、かえって手間が増えることがあります。NIST の生成 AI リスクプロファイルは、こうしたシステムのリスクを評価し管理するための、より広い参考資料です。
範囲を絞ったリリースと確認の計画から始める
的を絞ったタスクを選び、代表的な利用者と試して、結果を確認してから、機能のできることを広げてください。機能を無効にしたり、手作業の流れに戻したりできる手段を残しておきましょう。モデル、資料、指示を変えたときは、評価用の例でもう一度確認するべきです。
手伝ってほしいタスク：…
使ってよい承認済みの情報：…
役に立つ結果の姿：…
受け入れられない結果：…
人の承認が必要な操作：…
成功を測る基準：…
考えている業務の流れがあれば、タスクの例を送ってください。連携、評価、プロダクトとしての作業をまとめて検討し、運用コストに関わるサービスも含めて考えましょう。