エージェント信頼性の2つの設計——プログラム的前提条件とfew-shotツール選択【CCA Foundations対策】

Anthropic Academyの「Claude Code in Action」コースをもとに解説しています。

エージェントの信頼性を高める手段として「プロンプトに指示を追加する」という方法がある。しかしシステムが本番で動き始めると、プロンプト指示だけでは防ぎきれない問題が出てくる。この記事では2つの設計パターンを整理する。

この記事でわかること：

プロンプト指示が「確率的」でプログラム的前提条件が「決定論的」な理由
複数ツールが誤選択される問題に対してfew-shotが有効な理由
「理由付きの例」と「宣言的ルール」の違いと使い分け

プログラム的前提条件：決定論的なワークフロー強制

プロンプト指示の限界

顧客サポートエージェントで「必ずget_customerで顧客を確認してからlookup_orderを呼び出すこと」という指示をシステムプロンプトに書いたとする。

この指示は多くの場合機能するが、確率的だ。顧客が注文番号を最初のメッセージに含めた場合、エージェントは「注文番号があるのでlookup_orderを直接呼び出せばよい」と判断することがある。本番ログで12%のケースがその手順をスキップしていたとする。誤った顧客アカウントへの返金が12%発生することになる。

プログラム的前提条件の設計

前提条件とは「このツールを呼び出す前に、別のツールが成功していなければならない」というコード側のチェックだ。

def lookup_order(order_id: str, customer_context: dict) -> dict:
    # get_customerの結果なしにはlookup_orderを呼べない
    if not customer_context.get("verified_customer_id"):
        raise ValueError(
            "customer_context must contain verified_customer_id. "
            "Call get_customer first."
        )
    # ... 以降の処理

エラーがClaudeに返ると、Claudeは「まずget_customerを呼ぶ必要がある」と認識して手順を修正する。ツール定義レベルで制約が入るため、プロンプトの指示に従うかどうかに関係なく手順が強制される。

使い分けの基準

状況	選択
「できれば守ってほしい」スタイルのガイドライン	プロンプト指示
金銭的・セキュリティ上の影響がある必須手順	プログラム的前提条件
12%のスキップでも許容できる	プロンプト指示
1件のスキップも許容できない	プログラム的前提条件

few-shotの「理由付き例」：曖昧ツール選択の改善

宣言的ルールの限界

ツール説明文に「このツールは〇〇の場合に使う。△△の場合には使わない」と書く宣言的なアプローチがある。明確なケースには機能するが、曖昧なケースで崩れる。

たとえば get_customer と lookup_order のどちらを使うか迷う状況——「最近の購入についてサポートが必要です」というメッセージ——では、ルールを読んでどちらが適切かを推論しなければならない。ルールが「顧客情報を取得する」「注文情報を取得する」という程度だと、Claudeがどちらを選ぶかは一定しない。

理由付きfew-shotの設計

曖昧なケースに特化した例をシステムプロンプトに追加する。重要なのは「どちらを選ぶか」だけでなく「なぜそちらを選ぶか」を例の中で示すことだ。

[曖昧な状況の例1]
ユーザー: 「最近買ったものについて問い合わせたいです」
→ get_customerを使う。
  理由: 注文番号の言及がないため、まず顧客を特定してから注文を調べる順序が正しい。
  注文番号が明示されていない場合はget_customerが起点になる。

[曖昧な状況の例2]
ユーザー: 「注文番号12345のことで連絡しました。顧客番号はわかりません」
→ get_customerを使う（注文番号があってもまず顧客確認）。
  理由: 注文番号は提示されているが、顧客確認なしにlookup_orderを呼ぶと
  誤った顧客アカウントで処理が進む可能性がある。

理由を含む例が「なぜこの判断をするのか」の推論パターンをモデルに示す。宣言的ルールは「何をするか」を教えるが、few-shotは「どう考えるか」を教える。

ツール選択の誤りを改善するステップ

ツール選択が安定しない場合、次の順で対処する：

ツール説明文を確認する：説明が最小限（「顧客情報を取得する」など）であれば、まずここを充実させる。入力形式・典型的な使用例・類似ツールとの使い分けを追記する
それでも解決しない場合：曖昧なケースに特化した「理由付きfew-shot」をシステムプロンプトに追加する

ツール説明を充実させることで解決できる場合は、few-shotを追加するより低コストで効果的だ。few-shotはツール説明の改善後も誤りが残る場合の追加手段として機能する。

複数要求の処理：few-shotでパターンを示す

「注文12345の返金と、注文5678の配送先変更をお願いします」のような複数要求を含むメッセージで、エージェントが一方しか処理しない・パラメータを混同するという問題が起きることがある。

単一要求での精度が高くても複数要求で落ちる場合、エージェントが「1つのメッセージに複数の要求が含まれる」というパターンを処理するfew-shotが不足していることが多い。

[複数要求の処理例]
ユーザー: 「注文12345の返金と注文5678の配送先変更をお願いします」
→ 2つの要求として分けて処理する:
  1. lookup_order(order_id="12345") → 返金条件を確認 → process_refund(order_id="12345")
  2. lookup_order(order_id="5678") → 配送情報を確認 → update_shipping(order_id="5678")
  ※ 2つの注文番号を混同しないよう、それぞれを独立したタスクとして扱う

この例が示すのは「複数要求を分解する」という処理パターンと「パラメータを混同しない」という判断基準だ。前処理レイヤーで分解してから渡すアーキテクチャより低コストで、エージェントがすでに持っている単一要求処理能力を活かせる。

まとめ

プログラム的前提条件：プロンプト指示は確率的、コードによる前提条件チェックは決定論的。金銭的影響のある必須手順には前者ではなく後者を使う
理由付きfew-shot：「何を使うか」の例より「なぜそちらを使うか」の例が曖昧ケースに効く
改善の順序：ツール説明の充実 → それでも解決しなければ理由付きfew-shotを追加
複数要求：パターンを示すfew-shotで分解処理を教える方が前処理アーキテクチャより低コスト