あなたの製品にサポートチケットが届き、Claudeにそれぞれへの返信を書かせたいとします。何かを作り始める前に、どれだけ作り込むかを選びましょう。大きく作り込むほど良い結果が得られることが多いですが、その分コストがかさみ、顧客を長く待たせる傾向もあります。
1回のリクエストを送る、コードが決めた順序で複数のリクエストを実行するワークフローを組む、あるいは自分でステップを選ぶエージェントを使う、という選択肢があります。 まずは最もシンプルな方法から始め、テストによってそのシンプルな方法では不十分だと分かったときにだけ、次の段階に進んでください。
次のステップを誰が決めるかを問う
この3つの選択肢は、Claudeが答えた後に何が起きるかを誰が決めるかという点で異なります。
- 1回のリクエストでは、次に起きることは何もなく、Claudeの答えがそのまま結果になります。
- ワークフローでは、あなたのコードが決めます。あらかじめ書いておいた順序で、次のリクエストを送ります。
- エージェントでは、Claudeが決めます。次の各ステップと、使うツールをClaude自身が選びます。
この3つの選択肢の中から選ぶには、まず良い結果とはどのようなものかを書き出してください。 サポートチケットの場合、良い返信とは、顧客の質問に答え、返金ポリシーに従い、送信前の修正がわずかで済むようなものかもしれません。それを書き出しておけば、最もシンプルな方法をそれに照らしてテストし、不十分かどうかを確認できます。
マージされたプルリクエストからリリースノートを下書きする機能を計画しています。まだ何も作っていません。どれだけ作り込むかを選ぶ前に、何を書き出しておきますか？
1回のリクエストから始める
1回のリクエストとは、1回のMessages APIリクエストで、返ってくる答えも1つだけというものです。チケットと一緒に、そのチケット向けにコードが検索したヘルプ記事や、手本として気に入っている過去の返信をいくつか載せることもできます。多くの機能では、この形で組んだ1回のリクエストで大抵は十分です。
自分のチケットに対して1回のリクエストで十分かどうかを確かめるには、先月の実際のチケットで実行してみましょう。それぞれの返信を、良い返信として書き出した内容に照らして採点します。そして、基準を満たさなかった返信を読み、それらがどのような種類のチケットへの返信だったかを見ます。このように、実際の入力と、返ってきたものを採点する方法を組み合わせたテストを、evalと呼びます。
返信が書き出した内容と一致していれば、その1回のリクエストをそのまま出荷し、そこで止めて構いません。一致しない部分については、次の段階に進む前に、リクエストの指示、記事、例を改善しましょう。
1回のリクエストでは不十分だというサインの一つは、ある種類のチケットへの修正が、別の種類のチケットを悪化させることです。例えば、プロンプトに返金ルールを追加したら、技術的な質問への返信が悪くなった、というような場合です。このように一方の修正が他方を犠牲にする状態が続くなら、ワークフローを試してみましょう。
マージされたプルリクエストからリリースノートを下書きする1回のリクエストがあります。先月のリリースでそれを実行し、各ノートを採点しました。どのような結果が出たら、ワークフローを試すべきだと分かりますか？
ステップを書き出せるならワークフローに進む
1回のリクエストでは不十分だと分かったら、最初のチケットが届く前にステップを書き出せる場合に限り、ワークフローを選びましょう。 ワークフローは、タスクがきれいに固定ステップへ分割できる場合に適しています。
サポートチケットのワークフローは、次の2ステップで実行できます。
- 最初のリクエストが、チケットを「返金」「技術的な質問」「一般的な質問」の3種類のいずれかに分類します。
- あなたのコードが、その種類のチケット用のプロンプトとヘルプ記事を添えて、2回目のリクエストでチケットを送ります。
これで各種類のチケットがそれぞれ専用のプロンプトを持つので、返金用プロンプトへの変更が技術的な返信に影響することはありません。
タスクを複数のリクエストに分割すると、ステップとステップの間で何が出力されるかを確認できるようにもなります。各ステップはそれぞれ独立したリクエストなので、次のステップを実行する前に、ログを取り、採点し、チェックできます。例えば、あなたのコードは、最初のリクエストが3種類のうちのいずれかを返したことを確認し、それ以外の答えを人間に回すことができます。
このワークフローでは、2回目のリクエストは最初のリクエストが終わるまで始められないため、顧客の待ち時間が長くなります。より正確な返信を得るためにその待ち時間を受け入れるのであり、実際にそれが得られることをテストで示す必要があります。
あらかじめステップを書き出せない場合、ワークフローはもう適していません。例えば、返信のためにClaudeが顧客の注文を調べる必要があり、次に何を確認するかがそこで見つかったものによって変わる、というような場合です。
どうしてもできない場合にのみエージェントに進む
エージェントを選ぶのは、Claudeが与えられたツールを使って次の各ステップを自分で選ばなければならない、オープンエンドなタスクの場合に限ります。オープンエンドとは、そのタスクに何ステップ必要になるかを予測するのが難しい、あるいは不可能であり、あらかじめステップを書き出すことができない、ということです。
例えば、ある顧客が、荷物が届かなかったと書いてきたとします。Claudeはまずその顧客の注文履歴を調べ、荷物が古い住所に送られていたことを見つけます。そこでClaudeは次に、誤った住所に関するあなたのポリシー記事を読みます。そして返金を発行するか、チケットを更新します。
エージェントはより多くのコストがかかり、その誤りは積み重なっていくことがあります。 エージェントを有用にしている「自分で選ぶ自由」は、同時にテストを難しくもします。エージェントは多くのステップにわたって動作することがあるため、その判断に対してある程度の信頼が必要になります。
エージェントを選ぶ前に、そのタスクについて次の質問に答えてください。
- より良い結果は、高いコストと長い待ち時間に見合うか。
- Claudeはこの種のタスクをうまくこなせるか。
- 誤ったステップを、テスト、レビュー、ロールバックによって検知し、そこから回復できるか。
これらのいずれかの答えが「いいえ」なら、ワークフローか1回のリクエストにとどまりましょう。サポートチケットの場合、それはつまり、ステップを書き出せる種類のチケットについてはワークフローを使い続け、それ以外は人間に回す、ということです。
エージェントが適しているのは、問い合わせの確認と返金の順序がチケットごとに変わる場合だけです。各返金は人間が承認するので、3つ目の質問への答えは「はい」になります。
リリースノートのワークフローは通常のリリースを扱っていますが、中にはあらかじめ列挙できないステップを必要とするものもあります。エージェントなら、レビューも取り下げる手段もなく、顧客に直接公開してしまいます。そうしたリリースについては、どうしますか？
いくつかの機能アイデアで試してみる
いくつかの機能アイデアを3つの選択肢それぞれに当てはめて、どうなるかを見てみましょう。
次に進むべきこと
Claudeで機能を作る前に、良い結果とはどのようなものかを書き出し、1回のリクエストから始め、テストによって不十分だと分かったときにだけ次の段階に進んでください。 今計画している機能についても、同じ選択をしてみましょう。その選択を確認するには、自分の機能で次のステップを誰が決めるのか、そしてどのようなテスト結果が出たら次の段階に進むべきかを、名指しで書いてみてください。
次の段階に進むべきタイミングを教えてくれるテストが、evalです。次は、Introduction to evals（新しいタブで開きます）を受講して、自分のデータで小さなevalを構築してみましょう。
選択を終えた後に役立つページがもう2つあります。自分の機能がClaudeにツールを渡す場合は、Tool use with the Messages API（新しいタブで開きます）で、ツール使用を信頼性高く、応答性良く、より安価に実行する方法を紹介しています。エージェントを選ぶ場合は、What is Claude Managed Agents?（新しいタブで開きます）で、エージェントとそのツールを実行するマネージド環境について解説しています。これにより、その部分を自分で構築する必要がなくなります。