LLMはなぜ外部ツールを呼び出せる？Function Callingの内部動作とエージェント設計

多くのエンジニアが「LLMはただのテキスト生成器」と誤解していますが、実はGPTモデルは外部ツールを呼び出し、まるで人間のようにタスクを遂行できます。この強力な機能が「Function Calling」です。しかし、その内部でLLMがどのようにしてツールを呼び出すべきかを判断し、引数を生成しているのか、そしてどのようにして信頼性の高いLLMエージェントを構築するのか、その具体的なメカニズムは意外と知られていません。

この記事では、OpenAIのFunction Callingの内部動作を深く掘り下げ、LLMが外部ツールと連携する仕組みを解明します。具体的な実装コードを交えながら、ツールの定義からモデルがツールを呼び出すまでのフローを詳細に解説し、さらに自律的なLLMエージェントを設計する上でのベストプラクティスと、よくあるハマりどころの回避策を提示します。この記事を読めば、あなたのLLMアプリケーションは単なるチャットボットから、強力なタスク実行エンジンへと進化するでしょう。

LLMはなぜ外部ツールを呼び出せる？Function Callingの内部動作

LLMが外部ツールを呼び出せるのは、プロンプトの一部として与えられたツール定義を解釈し、ユーザーの意図に合わせて最適なツールとその引数を「推論」する能力があるからです。これは、LLMが単なる知識ベースの検索ではなく、複雑な推論と行動計画を実行できることを示しています。

OpenAI Function Calling (Tool Calling) の進化と現状

OpenAIのFunction Callingは、モデルがトレーニングデータ外の最新情報にアクセスしたり、特定のアクションを実行したりするための強力なメカグラムです。初期の functions パラメータから、現在はより柔軟な tools パラメータを使用する tool_calling へと進化しました。これにより、JSONスキーマで定義された関数ツールだけでなく、自由形式のテキスト入出力に対応するカスタムツールもサポートされるようになっています。

特に、additionalProperties: false や required フィールドによる厳密なスキーマ定義、そして2024年6月に導入された Structured Outputs（strict: true を関数定義に設定することで、生成される引数が提供されたスキーマに準拠することを保証）は、モデルがより正確にツールを呼び出すための重要な改善点です。

Model Context Protocol (MCP) とは？

Model Context Protocol (MCP) は、2024年11月にAnthropicによって提案され、OpenAIやGoogleも採用を進めている、AIモデルと外部ツールやデータソースを接続するための標準プロトコルです。これは、コンテキストがモデルにどのように渡されるか、ツール呼び出しがどのように呼び出されるか、結果がどのように解釈されるかを定義する構造化された方法を提供します。

OpenAIは2026年半ばにAssistants APIをMCPに移行する予定であり、この動きはAssistants APIの将来的な非推奨化を示唆しています。MCPは、異なるAIベンダー間でのツール連携の互換性を高め、より堅牢でスケーラブルなAIエージェントシステムの構築を可能にするための重要なステップとなります。

OpenAI Function Calling の基本的なフローと実装

このセクションでは、OpenAIのFunction Callingがどのように機能するかを、具体的なPythonコードを交えて解説します。Function Callingは、以下の5つの高レベルなステップで構成されます。

1. 関数スキーマの定義

モデルに利用可能な関数をJSONオブジェクトとして tools パラメータ内に記述します。このスキーマは、モデルが関数を呼び出すべきタイミングとそのために必要な引数を理解するための「取扱説明書」となります。

{
  "type": "function",
  "function": {
    "name": "get_current_weather",
    "description": "指定された場所の現在の天気を取得する",
    "parameters": {
      "type": "object",
      "properties": {
        "location": {
          "type": "string",
          "description": "都市と州、例: San Francisco, CA"
        },
        "unit": {
          "type": "string",
          "enum": ["celsius", "fahrenheit"]
        }
      },
      "required": ["location"],
      "additionalProperties": false // 推奨: モデルがスキーマにないプロパティを生成するのを防ぐ
    }
  }
}

ポイント: additionalProperties: false を追加することで、モデルがスキーマに定義されていない余計な引数を生成するのを防ぎ、引数の厳密性を高めることができます。また、required フィールドで必須引数を明示します。

2. ユーザーメッセージとツールリストを含むリクエストの送信

Chat Completions APIを呼び出す際に、ユーザーのメッセージと、ステップ1で定義したツールリストを tools パラメータに含めて送信します。tool_choice="auto" は、モデルが自動的にツールを呼び出すかどうかを判断することを意味します。

import openai

# OpenAIクライアントの初期化 (APIキーは環境変数等で管理することが推奨されます)
client = openai.OpenAI(api_key="YOUR_OPENAI_API_KEY")

messages = [{"role": "user", "content": "San Franciscoの天気は？"}]
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_current_weather",
            "description": "指定された場所の現在の天気を取得する",
            "parameters": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "都市と州、例: San Francisco, CA"
                    },
                    "unit": {
                        "type": "string",
                        "enum": ["celsius", "fahrenheit"]
                    }
                },
                "required": ["location"],
                "additionalProperties": false
            }
        }
    }
]

response = client.chat.completions.create(
    model="gpt-4o", # 最新モデルの使用を推奨
    messages=messages,
    tools=tools,
    tool_choice="auto" # モデルがツールを呼び出すか、直接応答するかを自動判断
)

3. モデルからのツール呼び出しの受信

モデルは、ユーザーのクエリに対して直接テキストで応答する代わりに、呼び出すべきツールとその引数を含む tool_calls 配列を返します。これが、LLMが外部ツール連携の意図を表明する瞬間です。

{
  "id": "chatcmpl-...",
  "object": "chat.completion",
  "created": 1677649420,
  "model": "gpt-4o",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "tool_calls": [
          {
            "id": "call_abc123",
            "type": "function",
            "function": {
              "name": "get_current_weather",
              "arguments": "{\"location\": \"San Francisco, CA\"}"
            }
          }
        ]
      },
      "finish_reason": "tool_calls" // モデルがツール呼び出しを意図したことを示す
    }
  ],
  "usage": {
    "prompt_tokens": 82,
    "completion_tokens": 18,
    "total_tokens": 100
  }
}

finish_reason: "tool_calls" は、モデルがテキスト応答ではなく、ツール呼び出しを生成したことを示します。

4. アプリケーション側での関数の実行

アプリケーション側で、モデルが要求した関数を、提供された引数で実行します。このステップは、LLMが生成した「計画」を実際の「行動」に移す部分です。

import json

def get_current_weather(location, unit="fahrenheit"):
    """指定された場所の現在の天気を取得する"""
    # 実際のAPI呼び出しやデータベースクエリを模倣
    if "San Francisco" in location:
        return json.dumps({"location": location, "temperature": "72", "unit": unit})
    elif "Tokyo" in location:
        return json.dumps({"location": location, "temperature": "25", "unit": unit})
    else:
        return json.dumps({"location": location, "temperature": "unknown"})

tool_calls = response.choices[0].message.tool_calls
function_response = None
if tool_calls:
    for tool_call in tool_calls:
        function_name = tool_call.function.name
        function_args = json.loads(tool_call.function.arguments)

        if function_name == "get_current_weather":
            function_response = get_current_weather(
                location=function_args.get("location"),
                unit=function_args.get("unit")
            )
            print(f"Function response: {function_response}")
            break # この例では最初のツール呼び出しのみを処理

5. 結果をモデルに送り返す

実行結果を tool ロールとしてメッセージ履歴に追加し、再度モデルにリクエストを送信します。これにより、モデルはツールの実行結果を「見て」、最終的なユーザーへの応答を生成したり、次のツール呼び出しを計画したりできます。

# ステップ2のリクエストで使用したmessagesリストを更新
messages.append(response.choices[0].message) # assistantのtool_callsメッセージを追加

if function_response: # 関数が実行され、結果がある場合のみ追加
    messages.append(
        {
            "tool_call_id": tool_calls[0].id, # 実行したツール呼び出しのID
            "role": "tool",
            "name": function_name, # 実行した関数の名前
            "content": function_response,
        }
    )

second_response = client.chat.completions.create(
    model="gpt-4o", # 最新モデルの使用を推奨
    messages=messages
)
print(second_response.choices[0].message.content)

この「リクエスト → ツール呼び出し → 実行 → 結果をフィードバック → 最終応答」というループが、LLMエージェントが自律的にタスクを遂行する基本的なメカニズムとなります。

LLMエージェント設計におけるFunction Callingの活用とベストプラクティス

Function Callingは、LLMを単なる会話モデルから、計画・実行・反省が可能な自律的なLLMエージェントへと進化させるための基盤技術です。ここでは、エージェント設計におけるFunction Callingの活用方法と、信頼性の高いシステムを構築するためのベストプラクティスを解説します。

LLMエージェントの基本アーキテクチャ

LLMエージェントは、LLMをワークフロー実行と意思決定の管理に活用し、タスクを自律的に実行するシステムです。主要なモジュールとして、以下を組み合わせます。

• 計画 (Planning): タスクを小さなステップに分解し、実行順序を決定します。
• 記憶 (Memory): 過去の会話や実行結果を保持し、長期的なコンテキストを提供します。
• ツール利用 (Tool Use): 外部システムと対話するための様々なツールにアクセスし、ワークフローの現在の状態に応じて適切なツールを動的に選択します。Function Callingがこの中核を担います。

よくあるエラー・ハマりどころとその回避策

Function Callingを用いたエージェント開発では、特有の課題に直面することがあります。

1. モデルが誤った引数で関数を呼び出す、または関数を呼び出すべきときに呼び出さない

原因: 関数定義が不明確であったり、モデルがユーザーの意図を正確に解釈できなかったりするためです。

回避策:

• 明確で具体的な関数名と説明: モデルがいつその関数を使うべきかを理解できるように、具体的で分かりやすい説明を記述します。
• 厳密なスキーマ定義: additionalProperties: false をJSONスキーマに設定し、モデルがスキーマに厳密に従うように強制します。required フィールドで必須引数を明確にします。
• 引数のランタイム検証: アプリケーション側で、関数を実行する前に引数の型と値を検証し、不正な呼び出しを防ぎます。
• エラーメッセージのフィードバック: 関数実行でエラーが発生した場合、そのエラーを構造化されたJSON形式でモデルにフィードバックし、モデルが次のターンで修正できるように促します。

2. コンテキストウィンドウの枯渇とコストの増加

原因: 多数のツール定義や長い会話履歴がコンテキストウィンドウを占有し、トークン使用量が増加するためです。

回避策:

• ツールの選択的ロード (Tool Search): 関連性の高いツールのみを動的にロードするメカニズムをアプリケーション側で実装します。ユーザーのクエリや現在の会話のコンテキストに基づいて、利用可能なツールをフィルタリングします。
• 会話履歴の要約 (Anchored Iterative Summarization): 長い会話セッションでは、過去のメッセージを要約してコンテキストウィンドウの使用量を抑えます。ただし、要約によって重要な情報が失われないよう注意が必要です。
• より小さいモデルの利用: 単純なタスクや特定機能に特化したサブエージェントには、よりコスト効率の良い小さいモデルを使用します。

3. 無限ループまたは予期せぬエージェントの動作

原因: エージェントがツール呼び出しと応答のループから抜け出せなくなったり、意図しないアクションを繰り返したりするためです。

回避策:

• ターン数の上限設定: エージェントのループに最大ターン数を設定し、上限を超えた場合は実行を停止してユーザーに制御を戻すことで、無限ループを防ぎます。
• 明確な終了条件の定義: エージェントのタスクが完了したと判断する明確な条件をプロンプトまたはコードで定義します。
• 人間による介入 (Human-in-the-Loop): 高リスクな決定や曖昧な状況では、人間が介入してエージェントの行動を承認または修正するメカニズムを設けます。
• ガードレールの実装: エージェントの行動範囲を制限するガードレールを定義し、安全で予測可能な動作を保証します。例えば、特定のAPIキーの使用制限や、機密情報へのアクセス制限などです。

設計上のトレードオフとベストプラクティス

LLMエージェントの設計には、常にトレードオフが伴います。

設計上のトレードオフ

• 汎用性と効率性: LLMは汎用性が高い一方で、特定のタスクでは非効率になることがあります。タスク特化型のSLM（Small Language Model）エージェントと組み合わせることで、効率性を向上させることができます。
• ステートフル vs. ステートレス: ステートレスエージェントはスケーリングが容易ですが、会話履歴の管理が課題です。ステートフルエージェントは複雑な会話やワークフローに適していますが、永続的な状態管理が必要になります。
• パフォーマンスと複雑性/保守性: 高性能なエージェントは、データ処理、プロンプト管理、ガードレール、オブザーバビリティなど、システム全体の複雑性を増加させます。

ベストプラクティス

• モジュール型サブエージェント設計: モノリシックなエージェントではなく、機能ごとにコンテキストを分離したモジュール型のサブエージェントを構築します。これにより、コンテキストの混同を防ぎ、特定のタスクに特化することでパフォーマンスを向上させます。
• ハーネスとモデルの分離: 検証ロジック、権限チェック、リトライ処理などの信頼性に関するコードは、LLMプロンプト内ではなく、周囲のオーケストレーションコード（ハーネス）に配置します。モデルは推論と意図抽出に集中させ、堅牢な処理はアプリケーション側で担います。
• 厳密なツール定義とスキーマ検証: 各ツールに明確な目的、名前、説明、そして additionalProperties: false を含む厳密なJSONスキーマを定義します。ツール実行前に引数を検証し、不正な引数での関数呼び出しを防ぎます。
• 堅牢なエラーハンドリングとフィードバック: すべてのツール実行を try/except でラップし、エラーが発生した場合はその詳細をJSONとしてモデルに返すことで、モデルがエラーから回復し、次のアクションを調整できるようになります。
• コンテキスト管理の最適化: コンテキストウィンドウの利用率を60〜80%に抑えることを目標とし、長いセッションでは要約やプログレッシブスキル開示（関連するスキルが呼び出されたときにのみツールドキュメントをロード）を実装してコンテキストサイズを管理します。
• オブザーバビリティと評価: 入力、出力、レイテンシ、成功ステータスを含むすべてのツール呼び出しをログに記録し、エージェントセッション全体にわたるトレースIDをキャプチャします。本番環境にデプロイする前に、プロンプト変更に対して自動評価を実行し、信頼性を確保します。

まとめ

この記事では、OpenAI Function Callingの内部動作から、それがどのようにしてLLMエージェントの外部ツール連携を実現しているのかを深く掘り下げました。

• Function Callingは、LLMがプロンプト内のツール定義を解釈し、ユーザーの意図に基づいて最適なツールとその引数を推論することで、外部システムとの連携を可能にします。
• 実装は、関数スキーマの定義、リクエストの送信、モデルからのツール呼び出しの受信、アプリケーションでの関数実行、そして結果のフィードバックという5つのステップで構成されます。
• LLMエージェントを構築する上では、不明確なツール定義、コンテキストウィンドウの枯渇、無限ループといった課題に対し、厳密なスキーマ定義、コンテキスト最適化、ガードレール設置などのベストプラクティスが有効です。
• 将来的には、Model Context Protocol (MCP) のような標準化の動きが、より堅牢で相互運用可能なAIエージェントシステムの基盤となるでしょう。

Function Callingを深く理解し、これらの設計原則とベストプラクティスを適用することで、あなたのLLMアプリケーションは、単なるテキスト生成を超えた、より賢く、より自律的なタスク実行エンジンへと進化させることができます。

さらに深く学びたい方は、OpenAIの公式ドキュメントで最新のAPI仕様と推奨される実装パターンを確認することをお勧めします。