AI機能は、デモで動作した時点では完成ではない。
それが落とし穴だ。3つの簡単な質問を投げかけ、そのうち2つ半に答え、誰もが未来の姿を垣間見る。すると突然、プロダクトロードマップに「AIアシスタント」という機能が、本来あるべき仕様書の代わりに鎮座する。
私はそのプロセスを信用しない。私が信頼するのは、もっとゆっくりとしたプロセスだ。約束を明確にし、失敗ケースを書き出し、退屈な経路をテストし、システムが適切に振る舞えると証明されるまで人間を近くに置いておく。
機能は一度評価されるだけではない。ループを巡る。約束を定義し、失敗セットを構築し、実際の出力をレビューし、それから初めて何を出荷できるかを判断する。
約束から始める
最初の質問は「どのモデルを使うべきか？」ではない。
最初の質問はこれだ。この機能が応答した後、ユーザーが信じてもよいことは何か？
この一文は重要だ。機能が文書を要約するなら、ユーザーはその要約が忠実であると信じる。サポート返信を下書きするなら、ユーザーは返金ポリシーを捏造しないと信じる。取引シグナルを説明するなら、ユーザーはそれが親しみやすい口調の金融アドバイスではないと信じる。
約束を一行で書け：
- 「この機能はリクエストを分類し、適切なワークフローにルーティングする。」
- 「この機能は、人間が承認してから送信する応答の下書きを作成する。」
- 「この機能は内部ドキュメントを検索し、使用したソースを引用する。」
約束が段落になるなら、その機能はまだスコープが定まっていない。
ハッピーパスの前に失敗セットを構築する
ほとんどのAIデモは、偶然にデモを通すように訓練されている。
本当の評価セットには、プロダクトを居心地悪くさせる入力を含めるべきだ：
- 曖昧なリクエスト
- 矛盾する指示
- 欠落したコンテキスト
- 悪意のあるプロンプトインジェクション
- 古いポリシードキュメント
- 重複レコード
- 怒りを含む顧客メッセージ
- 誤処理するとコストがかかるエッジケース
顧客向けAIワークフローの場合、システムの形を信頼する前に少なくとも25の例が欲しい。完璧なベンチマーク行が25ではない。実際の作業を代表する、醜い25の例だ。
評価セットは書類作業ではない。それはプロダクトの境界線である。
モデルの品質とプロダクトの品質を分ける
モデルが優れていても、プロダクトが悪いことはあり得る。
モデルは引用なしで正しい答えを生成するかもしれない。ワークフローは正しいドキュメントを引用しても、重要な警告を埋もれさせるかもしれない。UIは答えが単なる下書きであるにもかかわらず、最終版のように見せてしまうかもしれない。
私はAI機能を階層で評価する：
- タスクを理解したか？
- 正しいソースまたはツールを使用したか？
- ソースの範囲外の主張を避けたか？
- ユーザーが行動できる形で結果を返したか？
- UIはシステムの確信度と限界を明確に示したか？
最初の2つだけがほとんどモデルの問題だ。残りはプロダクトの問題である。
都合が悪く感じられても、人間をループに長く留めておく
AIワークフローの最初のプロダクションバージョンは、通常「送信優先」ではなく「下書き優先」であるべきだ。
それは魔法のように聞こえない。良いことだ。
下書き優先はレビューデータをもたらす。ユーザーが出力のどこを編集し、どこを拒否し、どのフィールドを修正し、そもそも自動化すべきではなかったタスクはどれかを示す。
人間によるレビューステップは恒久的な補助輪ではない。それは計装である。
編集が予測可能になったら、その編集を自動化する。拒否が特定の入力タイプに集中したら、ルーターを変更する。レビュー担当者が常に同じソースを手動で確認しているなら、検索と引用を追加する。
デモがうまくいったからといって人間を外すのではない。レビューログが、システムがその権利を獲得したと示したときに人間を外すのだ。
出荷チェックリスト
AI機能を出荷する前に、以下を整えておきたい：
- 一文の約束
- 醜い例を含む評価セット
- 各例の合格/不合格基準
- プロンプト、ツール呼び出し、ソース、結果のログ記録
- 高リスク出力に対する人間レビューの経路
- モデルが利用不可の場合のフォールバック
- UIから不良出力を報告する方法
これらのどれも、機能の印象を損なわせるものではない。
これらは機能を本物にする。
関連システム：AI実装監査：構築前に行うべきこと では、この同じアイデアを、何を自動化すべきか決めているチーム向けの構築前監査パスとして詳述している。
