0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@masaki_ohta

呪文（プロンプト）のパッチワークから「ツールの契約」へ。AIに自律判断させるための設計手法

0
Posted at

はじめに

AIエージェントの開発において、誰もが一度は通る「最悪のアンチパターン」があります。

それが、プロンプト（システム指示書）の肥大化によるシステムの崩壊です。

エージェントが想定と異なる動きをしたり、ツールの実行でエラーを起こしたりするたびに、開発者は慌ててプロンプトに「指示のゴミ」を追加し始めます。

  • 「ツールAを使った後は、必ずツールBの引数を確認して実行すること」
  • 「もし検索結果が0件なら、より抽象的なキーワードに変えてリトライすること」
  • 「予算が10万円を超える場合は、絶対に承認ツールを呼ばないこと」
  • 「あなたは優秀なAIです。決して間違えないでください」

結果として、プロンプトは長大で複雑な「呪文」と化し、AIはどのルールを守るべきか判断できなくなります。最悪の場合、指示を完全に無視し始めるか、実行不可能な「それっぽい嘘（ハルシネーション）」を吐き出します。

この記事では、なぜプロンプトにこのような「業務フローや制約の制御」を書き込んではいけないのか、その本質を暴きます。

そして、最先端AIエージェントフレームワーク 「Synapse」 が提示する、**「ツールのカプセル化（契約）」と「システム（Harness）による物理的なランタイム制御」**という極めて堅牢な設計手法について解説します。

1. プロンプトは「思考の原則」を書く場所である

大前提として、プロンプトですべての挙動をコントロールしようとするのは、開発者の怠慢であり傲慢です。

プロンプトに書くべきなのは、エージェントの「役割定義（ペルソナ）」と「判断の方針（何に重きを置いて考えるべきか）」という、本質的な「思考の原則」だけです。

ツールの使い方、例外処理、リトライロジック、あるいはユーザー権限によるアクセス制限などをメインプロンプトに書き込むと、何が起きるでしょうか。

AIがそのツールを使わないフェーズや、全く無関係な思考をしている最中であっても、プロンプトに書かれた「無関係なツールの膨大なルールや制約」が常にLLMの脳内（コンテキスト窓）に居座り、認知能力を圧迫し続けます。

条件分岐や動作フローを文章でひたすらプロンプトに書き連ねるのは、ソフトウェア工学的には「グローバル変数にすべての処理ロジックを詰め込む」のと同じくらい最悪な設計です。

2. ツール設計に「思考」を残すな

エージェントの動作を安定させるための鉄則。それは、**「ツール設計からLLMの思考（判断）を排除すること」**です。

本来、システム側（コード）で決定できる処理手順を、LLMの確率的な判断に委ねてはいけません。

失敗例：ツール連携をAIに考えさせる

  [ ツールAを実行してデータを取得 ]
                │
                ▼ (LLMが「次にツールBを呼ぶべきか」をその都度判断する)
  [ ツールBを実行して処理を完了 ]

これをLLMにやらせると、高確率で以下の問題が発生します。

  • なぜかツールBを呼ばずに処理を終了する
  • 引数のフォーマットを間違える
  • すでに取得済みなのに、無駄にツールAを再実行する

解決策：一連の確定処理は1つのツールにまとめる

LLMは「Aを実行した後は、必ずBを呼ぶ」という保証を絶対に持ちません。
決まっている処理の流れは、最初からシステム側（APIやプログラム）で1つのツールとしてラップし、AIには「そのまとまったツールを1回呼ぶ」という判断だけをさせます。

LLMにやらせるべきなのは「判断と方針決定」であり、「決まりきった手順の実行」ではないのです。

3. 引数名と description は「第三のプロンプト」である

ツールの定義情報（APIスキーマや引数名、説明文）は、単なるシステム的なメタデータではありません。

「AIに対する強力な指示経路（第三のプロンプト）」 として機能します。

引数設計のアンチパターンと改善

// NGな引数設計：AIが意味を解釈できない
{
  "args": "20260517_user_data"
}

// OKな引数設計：引数名自体がAIへの強烈な指示になる
{
  "userId": "U-100",
  "startDate": "2026-05-01",
  "endDate": "2026-05-17"
}

引数名そのものが「何を渡すべきか」の自己説明になっていなければなりません。

ツールの description を「要約」と「使い方」に分解する

多くの開発者は、ツールの説明文（description）を適当な1つの文章で済ませます。
しかし、オーケストレーターはこの説明文だけを見て「今このツールを使うべきか」を判断するため、ここが曖昧だと致命的なツール選択ミスや誤用を引き起こします。

Synapseでは、ツール定義を明確に分離します。

  • summary: このツールが物理的に「何をするものか」
  • usage (または evaluation): いつこのツールを使うべきか、また「何をしてはいけないか」という契約

ツールは単なる「できることの定義」ではありません。「どう使われるべきか」の『契約』であるという認識を持つことが、設計の本質です。

4. Synapseが提供する「評価基準の局所カプセル化」 (evaluation)

「ツールAの戻り値が0件だった場合は、検索語を抽象化して再試行する」といった個別ルールのプロンプト汚染を防ぐため、Synapse Frameworkはツール側に評価ロジックを閉じ込める evaluation フィールドを提供しています。

const searchTool = {
  name: "search_docs",
  summary: "社内ドキュメントを検索します。",
  schema: {
    args: [{ name: "query", type: "STRING", required: true, desc: "検索クエリ" }]
  },
  // ツール実行結果の「自己評価ロジック」をここにカプセル化する
  evaluation: `
    検索結果が0件の場合は失敗と判定せよ。
    その場合、検索クエリのキーワードをより抽象的、あるいは一般的な単語に置き換えて、
    再度 search_docs ツールを実行するタスクを計画に自動追加せよ。
  `
};

この evaluation 指示は、メインプロンプトには一切含まれません。
「AIが search_docs ツールを実行し、その結果を受け取った直後の『評価フェーズ』」においてのみ、一時的にAIのコンテキストに注入されます。

これにより、平時（初期計画時や他のツールを使っている時）に無関係な制約でAIの脳内が汚染されるのを完全に防ぐことができます。必要な時に、必要な契約だけが動的に適用される美しい設計です。

5. 「禁止事項」はプロンプトでおねがいせず、コードで物理的に止める

「予算が10万円を超える場合は、絶対に承認ツールを実行しないでください」
これをプロンプトに赤字で書いても、AIはいつか必ず間違えます。

AIに禁止事項を考えさせてはいけません。システム側（コード）で選択肢そのものを奪い、物理的にブロックするのが商用の鉄則です。

Synapseは、AIのライフサイクルに強制介入する Harness（ハーネス） を提供します。

ツールを存在ごと抹消する (disableTool)

権限や状況に応じて、AIからツールという選択肢そのものを消し去ります。存在しないツールをAIが誤用することは物理的に不可能です。

const harness = {
  async beforePrompt(prompt, ctx) {
    const userRole = ctx.getGlobalState("userRole");
    if (userRole !== "admin") {
      // 一般ユーザーの場合、AIの脳内から「全削除ツール」の定義そのものを抹消する
      ctx.disableTool("delete_all_records");
    }
    return prompt;
  }
};

実行直前にシステムレベルでブロックする (beforeTool & terminate)

万が一、AIがプロンプトインジェクション等によって禁止されたツールを実行しようとした場合、ツールの実処理が走る「直前」のフックで検知し、AIの思考ループごと強制遮断（キルスイッチ）します。

const harness = {
  async beforeTool(call, ctx) {
    if (call.name === "approve_budget") {
      const amount = call.args.amount as number;
      if (amount > 100000) {
        // AIに「本当にいいですか？」と聞く余地を与えず、システム側で即時強制終了する
        ctx.terminate("エラー: 10万円を超える予算承認はシステムルールにより即時ブロックされました。");
      }
    }
    return call;
  }
};

まとめ

プロンプトに制約やフローを書きまくる「呪文調整」の開発からは、もう卒業しましょう。

  • ツール設計から**「AIの判断（思考）」を排除**し、1つの意味ある単位でカプセル化する。
  • 引数名や description を**「第三の指示経路」**として極限まで精緻化する。
  • ツールの個別評価ルールは、メインプロンプトを汚さず evaluation に閉じ込める。
  • 禁止事項やセキュリティ境界は、プロンプトでお願いせず Harness によってコードレベルで実力行使する。

AIに任せるべき「自由な知性」と、システムが死守すべき「決定論的な制御」の境界線を美しく引くこと。
これこそが、商用レベルで絶対にブレないAIエージェントシステムを構築するための唯一の王道です。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?