人間の役割を前提にしたエージェント設計

まず大前提として、LLMエージェントは人間の代わりではなく、あくまで協働パートナーとして設計されるべきです。人間の強みは、価値判断や責任の負担、組織や個人の文脈を踏まえた意思決定にあります。逆にエージェントの強みは、情報の探索と整理、繰り返し作業の高速処理、多数の選択肢の検討といった部分です。どちらか一方に全面的に寄せるのではなく、長所の組み合わせを意識することが重要です。

そのためには、まず対象となる業務を分解し、「判断が重いステップ」と「事務的なステップ」を見極める必要があります。たとえば、顧客クレームへの対応であれば、事実関係の整理や過去ケースの検索、文面のドラフト作成などはエージェントに任せやすい領域です。一方で、無償対応の範囲をどこまで認めるか、今後の関係性への影響をどう考えるかといった判断は、人間に残すべき領域になります。

エージェント設計では、こうした業務分解の結果を踏まえ、「エージェントが自律的に完結してよい範囲」「必ず人間の承認を要する範囲」「人間の判断のために情報整理だけ行う範囲」という三つのゾーンを明確に定義します。そのうえで、各ゾーンごとにエージェントの権限とインターフェースを調整することで、協調の前提が整っていきます。

介入ポイントと「ハンドル」のデザイン

人間とエージェントの協調をうまく機能させるには、人間側から見て「いつでも介入できる」という感覚が重要です。一度エージェントに仕事を渡したら最後、内部で何が起きているか分からず、誤った結果だけが突然返ってくるという状態では、ユーザーは安心して任せることができません。

そこで鍵になるのが、介入ポイントとハンドルのデザインです。介入ポイントとは、ワークフローの中で人間が必ず確認や承認を行うステップのことであり、ハンドルとは人間がエージェントの振る舞いを調整するための操作手段です。具体的には、エージェントが提案したプランを一覧で表示し、ユーザーに「採用」「修正」「却下」を選ばせる画面や、エージェントが作成したドラフトを編集するエディタ、処理を途中で止める停止ボタンなどが該当します。

さらに、エージェントがどのように考えて行動したのかを、ユーザーに分かりやすく提示することも重要です。エージェントの内部で起きている推論プロセスを完全に可視化することは難しいにしても、「まず過去三ヶ月のデータを集計し、その結果をもとに二つの案を比較した」といった簡潔な説明を添えるだけで、ユーザーの安心感は大きく変わります。このような「思考過程の外在化」は、人間の同僚が報告するときの作法に近く、エージェントをチームの一員として扱う感覚を育てます。

信頼を育てるユーザー体験と「手放し運転」の範囲

協調設計のゴールは、ユーザーがエージェントを徐々に信頼し、適切な範囲で「手放し運転」を許容できる状態を作ることです。ここで重要なのは、最初から高い自律性を与えるのではなく、段階的に信頼を積み重ねることです。

初期段階では、エージェントに「提案」や「ドラフト」だけを任せ、最終決定は必ず人間が行う形が望ましいでしょう。このフェーズでは、エージェントの提案がどれだけ有用か、どの程度の頻度で修正が必要かを観察し、ユーザー自身もエージェントとの付き合い方を学んでいきます。この過程で、「この種類の仕事ならば、エージェントに任せても大丈夫そうだ」という感覚が少しずつ育っていきます。

次の段階では、リスクの低い領域から自動実行の範囲を広げていきます。たとえば、内部向けの週次レポートの更新や、定型的なリマインドメールの送信などは、自動化しやすい領域です。一方で、対外的なコミュニケーションや契約関連の処理などは、長く人間のレビューが必要な領域として残るかもしれません。組織として「どのレベルのリスクならエージェントに任せてよいか」という方針を共有し、それに沿って権限設定を行うことが、健全な信頼関係の前提になります。

最終的には、ユーザー体験そのものが、エージェントへの信頼に大きな影響を与えます。誤りが起きたときに、どれだけ素早く原因を特定し、修正できるか。ユーザーが「この結果はおかしい」と感じたとき、ワンクリックで人間の担当者に切り替えられるか。そうした「失敗への備え」が整っているほど、ユーザーは安心してエージェントに仕事を任せることができます。人間とエージェントの協調設計とは、単に役割分担を決めるだけではなく、信頼が徐々に醸成されるユーザー体験の流れ全体をデザインする営みでもあります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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