LLMエージェント時代のプロダクトマネジメント──仕様は“振る舞い”から設計せよ

機能志向から「振る舞い志向」へのパラダイムシフト

従来のソフトウェア開発において、仕様とは機能と画面の一覧であることが多くありました。どのボタンを押すとどのAPIが呼ばれ、どのデータがどのように更新されるかを、フローチャートや画面遷移図で記述するやり方です。このアプローチは、入力と出力が厳密に定義できる決定論的なシステムに対しては非常に有効でした。

ところが、LLMエージェントは本質的に確率的なシステムです。同じ質問をしても、生成される文章は毎回少しずつ異なりますし、状況の変化やメモリの内容、外部ツールからのレスポンスによっても振る舞いが変わります。このようなシステムに対して「すべての入力パターンと出力を網羅する仕様書」を書こうとすると、すぐに破綻してしまいます。結果として、「なんとなく賢いアシスタントを入れてみたが、どうなっていれば成功なのか分からない」という状態に陥りがちです。

そこで必要になるのが、機能ベースではなく振る舞いベースの仕様設計です。重要なのは「このエージェントはどんな人格・役割を持ち、ユーザーから見てどのように振る舞ってほしいのか」を言語化することです。専門用語をどの程度使うのか、どこまで踏み込んだ提案をしてよいのか、分からないときに黙り込むのではなくどう質問し返すのか、といった対話上の振る舞いに加え、どの外部ツールをどの状況で使ってよいのか、どこから先は必ず人間の承認を挟むのかといった、権限や責任に関するルールも仕様の一部になります。

プロダクトマネージャーは、これらを自然言語で記述された「行動指針」として定義し、それをプロンプトやシステムメッセージ、ポリシーファイルとして実装チームと共有していく必要があります。従来の要件定義書に、人格設計や対話ポリシー、ツール利用ルールといった新しい章が追加されるイメージです。

仕様書としてのプロンプトとポリシー設計

LLMエージェントにおいて、プロンプトは単なる「その場しのぎの魔法の呪文」ではなく、仕様書そのものに近い役割を果たします。とくにシステムプロンプトやロール定義、ツールの説明文などには、プロダクトマネージャーが考え抜いた行動ポリシーが反映されるべきです。

たとえば、カスタマーサポート向けのエージェントを設計する場合、「顧客の感情を先に受け止める」「自社に非がある可能性を軽々しく認めないが、決して責任転嫁もしない」「法的な判断を伴う表現は必ず保留し、人間の担当者にエスカレーションする」といったニュアンスをプロンプトに埋め込むことができます。ここで有効なのは、抽象的な美辞麗句ではなく、実際にあり得る会話例を含めた具体的な指示です。良い応答例と悪い応答例を並べ、どちらを目指すかを明示することで、モデルの振る舞いは大きく変わります。

さらに、ツール利用ポリシーも仕様として明文化する必要があります。どのツールは読み取り専用なのか、どのAPIを呼ぶ際には必ずユーザーに確認を求めるのか、連続して外部サービスを叩きすぎないためのレート制限はどう設計するのかといった点を、プロダクトマネージャーがビジネス側・セキュリティ側の利害を調整しながら決めていきます。その結果は、エージェントのランタイム設定とプロンプト両方に反映されます。

このように、プロンプトとポリシーは「コードではない仕様」でありながら、システムの振る舞いを強く規定します。したがって、プロンプトの改訂は仕様変更そのものであり、変更管理やレビューのプロセスが必要です。誰がどの目的でプロンプトを更新し、それによってどの指標がどのように変化したのかを記録しておくことは、品質とガバナンスの両面から重要になっていきます。

評価・ロールアウト・組織体制の再設計

振る舞いベースの仕様を設計できたとしても、それが「良いかどうか」をどう評価するかという問題が残ります。LLMエージェントでは、一件一件の応答の正しさだけでなく、タスク全体としての成功率、ユーザーが節約できた時間、誤動作によるリスクの頻度と重大性など、複数の指標を組み合わせて判断する必要があります。

実務上は、まず限定されたユースケースを対象に、パイロットユーザーを相手にベータ運用を行うのが現実的です。その際、ユーザーにはなるべくそのままのログを残してもらい、どの場面でエージェントが役に立ち、どの場面でイラッとさせられたのかを定性的・定量的に分析します。プロダクトマネージャーは、その結果をもとに、プロンプトやツール構成、インターフェースを繰り返し調整していきます。評価指標としては、タスク完了までに必要なステップ数の減少、手動対応へのエスカレーション率、ユーザーの主観的満足度などが使われることが多くなります。

ロールアウトの戦略も、従来の機能リリースとは少し異なります。LLMエージェントは、権限の範囲によってリスクが大きく変わるため、最初は「提案のみ」「ドラフトのみ」といった控えめなモードで導入し、一定の実績が確認できてから「自動実行」の範囲を広げていく段階的なアプローチが望ましいでしょう。その過程で、ユーザー教育や利用ポリシーの明文化も並行して進める必要があります。

最後に、組織体制についても触れておく必要があります。LLMエージェントのプロダクトには、モデルのチューニングやプロンプト設計に詳しいメンバー、ドメイン知識を持つ業務側のメンバー、セキュリティ・法務の観点からリスクを見られるメンバーなど、多様な専門性が求められます。プロダクトマネージャーは、その橋渡し役として、技術とビジネスとガバナンスを統合する「翻訳者」のような存在になります。この新しい役割を自覚し、学び続けることが、LLMエージェント時代のPMに求められる最大の資質だと言えるでしょう。