開発現場で頻繁に課題として挙がるのが、「LLMに外部ツールを使わせる際の制御の難しさ」です。
「APIを叩かせたいのに、引数の形式を間違える」「勝手に架空の関数を実行しようとする」「指示したフォーマットを守らない」……。
皆さんも、こうしたLLMの「お行儀の悪さ」に頭を抱えた経験があるのではないでしょうか？
特に業務システムとの連携においては、99%の精度ではなく、100%の形式準拠が求められます。ここで推奨したいのが、Claude 2.1（およびその系譜にあるAnthropicモデル）とXMLタグを組み合わせたプロンプト設計です。
OpenAIのFunction Callingは便利ですが、ブラックボックス的な要素が強く、微調整が難しい場合があります。一方でClaudeのアプローチは、プロンプト内で明示的にXML構造を定義することで、確実な制御を可能にします。
本記事では、システムプロンプトのテンプレートを公開します。これらは、RAG（社内検索）、タスク管理、複合ワークフローといった具体的なユースケースに合わせて最適化したものです。
理論だけでなく、明日からすぐにプロトタイプに組み込める実践的な「型」を持ち帰ってください。さあ、まずは動くものを作ってみましょう！
本テンプレート集の活用とClaude 2.1の優位性
なぜ、今あえてClaudeのAPI活用、特にClaude 2.1で確立された設計思想に注目すべきなのでしょうか？ 生成AIの進化は急速ですが、このモデルが提示した「大規模なコンテキストウィンドウ」と「XMLタグを用いたTool Use（ツール利用）の設計思想」は、現在のエンジニアリングにおいても重要なスタンダードとなっています。経営と技術の両面から見ても、この安定性は大きな武器になります。
なぜOpenAIではなくClaude系を選ぶのか
ChatGPTの最新モデルなども非常に優秀で、コンテキストウィンドウの拡大や推論能力の向上が進んでいますが、業務システム連携の観点、特に「長文ドキュメントを参照しながらの厳格なツール利用」においては、Claudeのアーキテクチャが適しているケースが多く見られます。
Claudeを推す主な理由は、「コンテキストへの忠実性（Faithfulness）」と「制御のしやすさ」です。Claudeはシステムプロンプトで与えられた指示、特に「やってはいけないこと（Negative Constraints）」を遵守する能力が高く、エンタープライズ向けのシステムへの組み込みにおいて信頼性が高い傾向にあります。
また、API定義やツール定義をプロンプト内に記述する際、ClaudeはXMLタグ（<tools>, <tool_description>など）による構造化データを正確に認識します。これは、最新のSkills機能やProjects機能（CLAUDE.md）とも親和性が高く、プロンプトエンジニアリングによってモデルの挙動を精密にコントロールし、最短距離でビジネス価値を生み出したい開発者にとって、極めて扱いやすい特性です。
Tool UseにおけるXML構造化の重要性
Claude 2.1以降、Anthropicは一貫してTool UseにおいてXML形式の記述を推奨しています。これは単なる好みの問題ではありません。XMLの開始タグと終了タグ（例: <result>...</result>）は、LLMにとって「情報の境界線」を明確にする強力なシグナルとなります。
JSONも構造化データとして優秀ですが、長大なコンテキストの中では埋もれやすく、閉じ括弧の欠落などの構文エラー（Syntax Error）のリスクがあります。対してXMLは、視認性が高く、ストリーミング処理時のパースも容易です。
本記事で紹介するテンプレートは、このXMLの特性を活かし、「思考（Thinking）」と「実行（Action）」を分離する設計になっています。このアプローチは、最新のClaudeモデルにおいても、ハルシネーション（幻覚）を抑制し、意図した通りの動作を引き出すためのベストプラクティスとして機能します。
本記事のテンプレートの使い方
これから紹介するテンプレートは、Pythonの anthropic クライアントライブラリで使用することを想定しています。
基本的には、system パラメータに渡す文字列として設計されています。変数の埋め込み部分（{{VARIABLE}}のような表記）を、皆さんの環境に合わせて書き換えるだけで、エージェントが即座に動き出します。
なお、Claudeの最新モデルへ移行する場合も、このプロンプト設計の基本思想はそのまま通用します。むしろ、モデルの推論能力が向上しているため、このテンプレートを用いることで、より複雑なタスクでも安定した動作が期待できます。公式ドキュメントで推奨されている「入力・出力形式の固定」や「制約条件の明記」といった要素も網羅しており、将来的なモデルアップデートにも耐えうる設計です。
基本設計：API定義を認識させるシステムプロンプトの「型」
まずは、すべてのベースとなる基本テンプレートを見ていきましょう。ここで重要なのは、いきなりツールを使わせるのではなく、「思考の連鎖（Chain of Thought）」を経由させることです。
ツール定義の標準フォーマット
Claudeにツールを認識させる際は、以下のようなXML構造で定義を与えます。これをシステムプロンプトの冒頭に配置します。
<tools>
<tool_description>
<tool_name>get_weather</tool_name>
<description>
指定された都市の現在の天気を取得します。都市名が必要です。
</description>
<parameters>
<parameter>
<name>city</name>
<type>string</type>
<description>都市名（例: 東京, 大阪, ニューヨーク）</description>
<required>true</required>
</parameter>
</parameters>
</tool_description>
</tools>
CoT（Chain of Thought）を強制するインストラクション
APIの誤実行を防ぐための秘訣は、<thinking>タグ内で計画を立てさせることです。モデルに「まず考えろ、それから動け」と指示することで、パラメータの不足やツールの選択ミスを劇的に減らすことができます。
基本テンプレート：汎用ツール定義プロンプト
以下が、ベースとして使用しているシステムプロンプトのテンプレートです。
SYSTEM_PROMPT_TEMPLATE = """
あなたは、与えられたツールを活用してユーザーの課題を解決するAIアシスタントです。
以下のツールを利用可能です：
<tools>
{tools_xml_definition}
</tools>
回答を生成する際は、以下のステップに従ってください：
1. ユーザーの入力を分析し、ツールを使用する必要があるか判断してください。
2. ツールを使用する場合は、まず <thinking> タグ内で以下の点を検討してください：
- どのツールが適切か
- 必要なパラメータはすべて揃っているか
- パラメータの値は正しい形式か
3. ツールを実行するためのXMLを出力してください。
形式: <function_calls><invoke><tool_name>ツール名</tool_name><parameters><param_name>値</param_name></parameters></invoke></function_calls>
ツールを使用する必要がない場合、または情報が不足している場合は、ユーザーに自然な言葉で回答してください。
"""
この「型」を守るだけで、エージェントの挙動は驚くほど安定的になります。
テンプレート①：社内ナレッジ検索（RAG）連携用プロンプト
B2B領域で需要が高いのが、社内Wikiやドキュメントを検索して回答するRAG（Retrieval-Augmented Generation）システムです。ここでは、ユーザーの曖昧な質問を検索クエリに変換する部分に焦点を当てます。
ユースケース：社内Wikiやドキュメントの検索
ユーザーは「経費精算どうやるんだっけ？」のように質問してきます。これをそのまま検索APIに投げても、良い結果は得られません。AIに「経費精算 手順 申請期限」のようなキーワードへ変換させる必要があります。
実装コード例と出力サンプル
# RAG用システムプロンプト
RAG_SYSTEM_PROMPT = """
あなたは社内ヘルプデスクAIです。以下のツールを使用して、社員の質問に答えてください。
<tools>
<tool_description>
<tool_name>search_knowledge_base</tool_name>
<description>社内規定やマニュアルを検索します。</description>
<parameters>
<parameter>
<name>query</name>
<type>string</type>
<description>検索キーワード（スペース区切りで複数指定可）</description>
</parameter>
</parameters>
</tool_description>
</tools>
重要事項:
- ユーザーの質問から、検索に最適なキーワードを抽出してください。
- <thinking>タグ内で、なぜそのキーワードを選んだか説明してください。
- 検索結果が得られた後は、必ずその情報を元に回答し、情報源が不明な場合は正直に「わかりません」と答えてください。
"""
# ユーザー入力例
user_input = "先週の出張旅費の申請っていつまでだっけ？"
# 期待されるClaudeの出力
"""
<thinking>
ユーザーは出張旅費の申請期限について尋ねています。
検索キーワードとして「出張旅費」「申請期限」「締め切り」が適切だと考えられます。
</thinking>
<function_calls>
<invoke>
<tool_name>search_knowledge_base</tool_name>
<parameters>
<query>出張旅費 申請期限 締め切り</query>
</parameters>
</invoke>
</function_calls>
"""
このように、思考プロセスを経由させることで、「先週の」といった検索にノイズとなる情報を除去し、本質的なキーワードのみをAPIに渡すことができます。
テンプレート②：タスク管理ツール（Jira/Notion）操作用プロンプト
次に、情報の取得（GET）だけでなく、作成・更新（POST/PUT）を行うケースです。ここでは「情報の不足を検知して聞き返す（Slot Filling）」機能が重要になります。
必須パラメータの不足を確認させる対話フロー
Jiraでチケットを切るには「プロジェクト名」「要約」「担当者」などが必須です。ユーザーが「バグ見つけたから登録しといて」としか言わなかった場合、AIは即座にツールを実行せず、不足情報をヒアリングしなければなりません。
実装コード例と出力サンプル
# タスク管理用システムプロンプト
TASK_SYSTEM_PROMPT = """
あなたはプロジェクト管理アシスタントです。Jiraへのチケット登録を代行します。
<tools>
<tool_description>
<tool_name>create_ticket</tool_name>
<description>新しいJiraチケットを作成します。</description>
<parameters>
<parameter>
<name>project_key</name>
<type>string</type>
<description>プロジェクトキー（例: PROJ, DEV）</description>
<required>true</required>
</parameter>
<parameter>
<name>summary</name>
<type>string</type>
<description>チケットのタイトル</description>
<required>true</required>
</parameter>
<parameter>
<name>description</name>
<type>string</type>
<description>詳細な内容</description>
<required>true</required>
</parameter>
</parameters>
</tool_description>
</tools>
ルール:
- 必須パラメータが不足している場合、ツールを実行してはいけません。
- 不足している情報をユーザーに質問してください。
- すべての情報が揃った段階でのみ、<function_calls>を出力してください。
"""
# ユーザー入力例
user_input = "ログイン画面のバグ報告チケット作って"
# 期待されるClaudeの出力
"""
<thinking>
ユーザーはチケット作成を求めていますが、以下の必須情報が不足しています：
1. プロジェクトキー（project_key）
2. 詳細な内容（description）
タイトル（summary）は「ログイン画面のバグ報告」と推測できますが、確実性を期すために確認が必要です。
ツールを実行するには情報が不十分です。
</thinking>
承知いたしました。チケットを作成するために、いくつか追加で教えていただけますか？
対象のプロジェクトキー（例：DEV）と、バグの具体的な状況（再現手順など）を教えてください。
"""
このテンプレートでは、<required>true</required> という定義と、「不足している場合は実行しない」というルールを組み合わせることで、エラーとなるAPI呼び出しを未然に防いでいます。
テンプレート③：条件分岐を含む複合ワークフロー自動化
さらに高度な、「調査結果に応じて次の行動を変える」エージェントの実装例です。これは従来のRPAでは分岐が複雑になりすぎる領域ですが、LLMなら柔軟に対応できます。
ユースケース：障害アラート対応（調査→判断→通知/起票）
例えば、システムのアラートを受け取った際、「ログを確認」し、そのエラーレベルが「Critical」なら「電話通知API」を、「Warning」なら「Slack通知API」を叩く、といった判断です。
複数のツールを使い分けるための判断ロジック記述
WORKFLOW_SYSTEM_PROMPT = """
あなたはシステム監視オペレーターです。状況に応じて適切な対応を行ってください。
<tools>
<tool_description>
<tool_name>check_server_logs</tool_name>
<description>サーバーの最新ログを取得します。</description>
</tool_description>
<tool_description>
<tool_name>send_slack_alert</tool_name>
<description>Slackチャンネルに通知を送ります。</description>
</tool_description>
<tool_description>
<tool_name>trigger_emergency_call</tool_name>
<description>担当者に緊急電話をかけます。重大な障害時のみ使用。</description>
</tool_description>
</tools>
判断ロジック:
1. まず check_server_logs を実行して状況を確認します。
2. ログに "FATAL" または "CRITICAL" が含まれる場合は、trigger_emergency_call を使用してください。
3. それ以外（"ERROR", "WARN"）の場合は、send_slack_alert を使用してください。
"""
# 期待されるClaudeの出力（ログ確認後の2ターン目）
"""
<thinking>
ログの確認結果："[2023-10-27 10:00:00] FATAL: Database connection failed"
"FATAL"エラーが検出されました。
判断ロジックに基づき、緊急電話（trigger_emergency_call）を実行する必要があります。
</thinking>
<function_calls>
<invoke>
<tool_name>trigger_emergency_call</tool_name>
<parameters>
<message>データベース接続障害が発生しました。至急対応が必要です。</message>
</parameters>
</invoke>
</function_calls>
"""
このように、プロンプト内に簡易的な if-then ロジックを記述できるのが、Claude 2.1の強力な点です。
実装トラブルシューティングと品質管理
最後に、これらを本番環境で運用する際によく直面するトラブルとその対策を共有します。
よくあるエラー：ハルシネーションによる存在しない引数の生成
ツール定義に含まれていないパラメータ（例: api_key や user_id など、内部で自動付与すべきもの）を、AIが生成してしまうことがあります。
対策: システムプロンプトに以下の制約を追加します。
「定義されている
<parameters>以外の引数は生成しないでください。認証情報などはシステム側で付与されます。」
APIレスポンスが長すぎる場合の処理（truncate戦略）
Claude 2.1は200kトークンまで扱えますが、APIの戻り値が巨大なJSON（数メガバイトなど）だと、処理速度が低下しコストも嵩みます。
対策: APIからLLMに結果を渡す前に、Python側でデータを間引きます。
# Python側での処理例
def truncate_response(response_data, max_chars=5000):
s = json.dumps(response_data)
if len(s) > max_chars:
return s[:max_chars] + "... (以下略)"
return s
本番運用前のテストケース作成ガイド
実際の開発プロジェクトでは、以下の3パターンのテストケースを用意することが推奨されます。
- Happy Path: 理想的な入力で正しくツールが呼ばれるか。
- Missing Info: 情報不足時に正しく聞き返せるか。
- Out of Scope: ツールで解決できない質問（「今日の天気は？」に対して天気ツールがない場合など）に、「できません」と答えられるか。
これらを自動テスト化することで、プロンプトを修正した際のリグレッション（デグレード）を防ぐことができます。
まとめ
Claude 2.1のAPI活用において、XMLタグを用いた構造化プロンプトは、単なるテクニックではなく、信頼性の高い業務システムを構築するための「マナー」と言えます。
今回ご紹介した3つのテンプレート（RAG、タスク管理、複合ワークフロー）は、実務で頻出するパターンをカバーしています。これらをベースに、対象のAPI定義を流し込むだけで、プロトタイプから本番実装までの開発工数を大幅に短縮できるでしょう。
AI開発は単に「動く」段階から、ビジネス要件に合わせて「確実に制御できる」段階へとシフトしています。ぜひ、このテンプレートを活用して、皆さんの手で革新的なAIエージェントをスピーディーに構築してみてください。どのようなエージェントが生まれたか、皆さんの知見もぜひ共有していただければと思います！
コメント