AIの進化において、LLM（大規模言語モデル）は「読む・書く」だけの存在から、「道具を使う」存在へと劇的な進化を遂げました。その中心にある技術が Function Calling（関数呼び出し）、別名 Tool Use（ツール使用） です。
本記事では、この技術の理論的な仕組みから、Pydanticを用いた堅牢な実装パターン、そしてECサイトのカスタマーサポートを自動化するビジネスユースケースまで、エンジニアが実務で即戦力として活用できるレベルまで深掘りして解説します。
なぜ Function Calling なのか？ (Problem & Solution)
課題: LLMは「現実世界」を知らない
LLMは、学習データに含まれる過去の知識しか持っていません。そのため、以下のような「現実世界へのアクセス」が必要なタスクには無力でした。
- リアルタイム情報: 「今の東京の天気は？」
- 社内データベース: 「先月のA社の売上は？」
- アクション実行: 「会議室を予約して」
従来のプロンプトエンジニアリング（In-Context Learning）だけでは、これらの外部情報を正確に取得し、構造化データとして処理することは困難でした。
解決策: 言語とAPIの架け橋
Function Callingは、LLMをシステム全体の「オーケストレーター（指揮者）」へと昇華させます。
- Define: 開発者が「使用可能な道具（関数・API）」を定義し、LLMに教える。
- Detect: LLMが会話の流れから、「道具を使うべきタイミング」と「必要な引数」を自律的に判断する。
- Execute: プログラム側で関数を実行し、結果を返す。
- Response: LLMが実行結果を元に、最終的な回答を生成する。
これにより、LLMはチャット画面の中に閉じこもっていた存在から、APIを通じて現実世界に干渉できるエージェントへと変貌しました。
技術解説: 各社LLMの実装比較と標準化
2025年現在、主要なLLMプロバイダーはすべてTool Useをサポートしていますが、その実装には微妙な違いがあります。
| 機能 | OpenAI (GPT-4o) | Anthropic (Claude 3.5 Sonnet) | Google (Gemini 1.5 Pro) |
|---|---|---|---|
| APIパラメータ | tools | tools | tools |
| 強制モード | tool_choice: "required" | tool_choice: {"type": "any"} | tool_config で制御 |
| JSON生成能力 | 極めて高い。複雑なネストも正確。 | 思考プロセス（XML）を含めることで精度向上。 | Vertex AIとの統合が強力。 |
| パラレル実行 | ✅ 対応 | ✅ 対応 | ✅ 対応 |
標準化が進んでおり、基本的には OpenAI互換のJSON Schema を理解しておけば、他のモデルへの移行も容易です。
実践: Pydanticを用いた堅牢な実装パターン
実務でFunction Callingを使う場合、生のJSON Schemaを手書きするのは非効率かつバグの温床です。Pythonエコシステムでは、Pydantic を用いてデータ構造を定義し、そこからスキーマを自動生成するのがベストプラクティスです。
以下に、最新のOpenAI SDKとPydanticを用いた「天気予報エージェント」の実装例を示します。
準備: ライブラリのセットアップ
pip install openai pydantic instructor今回は、Pydanticとの親和性を高めるラッパーライブラリである instructor を使用するパターンと、標準SDKを使用するパターンのうち、より汎用的な 標準SDK + Pydantic の組み合わせを紹介します。
コード実装
import json
from enum import Enum
from typing import List
from pydantic import BaseModel, Field
from openai import OpenAI
# 1. データ構造の定義 (Pydantic)
# 関数が受け取る引数をクラスとして定義することで、型安 全性を確保します。
class Unit(str, Enum):
CELSIUS = "celsius"
FAHRENHEIT = "fahrenheit"
class GetWeatherParameters(BaseModel):
location: str = Field(..., description="都市名（例: 東京, 大阪）")
unit: Unit = Field(default=Unit.CELSIUS, description="温度の単位")
# 2. ツールの定義
# 実際のAPI呼び出しを行う関数
def get_current_weather(location: str, unit: Unit = Unit.CELSIUS):
# ここで実際に気象庁APIなどを叩く
# 今回はダミーデータを返却
print(f"🛠️ Tool Execution: get_current_weather(location='{location}', unit='{unit}')")
return json.dumps({
"location": location,
"temperature": "22",
"unit": unit.value,
"forecast": ["sunny", "windy"]
})
# 3. エージェントクラスの実装
class WeatherAgent:
def __init__(self):
self.client = OpenAI()
# ツールのスキーマ定義（OpenAI互換形式に変換）
self.tools = [
{
"type": "function",
"function": {
"name": "get_current_weather",
"description": "指定された場所の現在の天気を取得する",
# PydanticモデルからJSON Schemaを自動生成
"parameters": GetWeatherParameters.model_json_schema()
}
}
]
def run(self, user_query: str):
messages = [{"role": "user", "content": user_query}]
# 1st Call: LLMにツール使用を判断させる
response = self.client.chat.completions.create(
model="gpt-4o",
messages=messages,
tools=self.tools,
tool_choice="auto", # 必要に応じてツールを使う
)
message = response.choices[0].message
# ツール呼び出しのリクエストがあるか確認
if message.tool_calls:
messages.append(message) # 会話履歴に追加
for tool_call in message.tool_calls:
# 関数名と引数の取得
fn_name = tool_call.function.name
fn_args = json.loads(tool_call.function.arguments)
# 関数の実行
if fn_name == "get_current_weather":
# Pydanticでバリデーションを行いつつ実行
validated_args = GetWeatherParameters(**fn_args)
tool_result = get_current_weather(
location=validated_args.location,
unit=validated_args.unit
)
# 結果を会話履歴に追加
messages.append({
"tool_call_id": tool_call.id,
"role": "tool",
"name": fn_name,
"content": tool_result,
})
# 2nd Call: ツールの結果を踏まえて最終回答を生成
final_response = self.client.chat.completions.create(
model="gpt-4o",
messages=messages
)
return final_response.choices[0].message.content
return message.content
# 実行
agent = WeatherAgent()
response = agent.run("東京と大阪の天気を教えてくれる？")
print(f"🤖 Agent: {response}")このコードの重要ポイント
- 型定義の単一化:
GetWeatherParametersクラスで引数の型と説明（docstring相当）を一元管理しています。プロンプト内で説明を書く必要がなくなり、メンテナンス性が向上します。 - バリデーション:
GetWeatherParameters(**fn_args)の行で、LLMが生成したJSONが正しい型か（例えばunitが不正な文字列でないか）を自動チェックしています。 - 会話履歴の管理: Tool Useは「往復（Turn-taking）」です。
tool_callsの結果を含むメッセージを正しく履歴に追加しないと、LLMは文脈を失います。
ビジネスユースケース: ECサイトの自律型カスタマーサポート
ここからは、より複雑なビジネスシナリオにおけるFunction Callingの活用例を確認していきます。
シナリオ: 24時間対応の実践的サポートエージェント
ECサイトにおいて、ユーザーからの「注文状況の確認」や「返金依頼」に対応するエージェントを構築します。 ただし、「返金」のようなセンシティブな操作は、AIに全権委任するのは危険です。ここで重要になるのが Human-in-the-loop（人間参加型） の設計です。
システム要件
- 注文照会: 注文IDから配送状況を即答する。
- 返金処理:
- 5,000円未満 → AIが自動承認。
- 5,000円以上 → 人間の担当者の承認フローへ回す（Escalation）。
実装設計 (Human-in-the-loop Implementation)
class RefundStatus(str, Enum):
APPROVED = "approved"
ESCALATED = "escalated_to_human"
REJECTED = "rejected"
class ProcessRefundArgs(BaseModel):
order_id: str
reason: str
amount: float
def process_refund(order_id: str, reason: str, amount: float):
"""返金処理を行うツール。金額によって承認フローを分岐させる。"""
print(f"Processing refund for Order {order_id}: ¥{amount}")
# ビジネスロジック: 高額な返金は人間へエスカレーション
if amount >= 5000:
# ここでSlack通知やチケット起票を行うAPIを呼ぶ
create_support_ticket(order_id, reason, amount)
return json.dumps({
"status": "escalated_to_human",
"message": "5000円以上の返金のため、担当者が確認します。24時間以内にご連絡します。"
})
# 少額なら自動処理
execute_refund_api(order_id, amount)
return json.dumps({
"status": "approved",
"message": "返金処理が完了しました。明細の反映をお待ちください。"
})ビジネスインパクト
- 顧客体験 (CX) の向上: 問い合わせの8割を占める「配送確認」「少額返金」が待ち時間ゼロで解決されます。
- コスト削減: オペレーターは「高額な返金」や「複雑なクレーム」という、人間ならではの対応が必要なタスクに集中できます。
- リスク制御: 完全にAI任せにするのではなく、金額閾値（Threshold）によるガードレールを設けることで、不正や誤動作のリスクを最小化できます。
本番運用における3つのアンチパターン
Function Calling導入時に陥りやすい罠とその対策です。
「なんでもできる神ツール」を作ってしまう
ひとつの関数にあれこれ詰め込みすぎると、LLMが混乱します。Unix哲学のように、「ひとつのツールはひとつのことをうまくやる」 ように設計し、複数のツールを組み合わせ（Chain）させるのが正解です。
descriptions（説明）の手抜き
LLMは関数の中身（コード）を見ているわけではありません。description フィールドのテキストだけを見て、どのツールを使うか判断しています。
- ❌
user_id: ユーザーID - ⭕
user_id: 8桁の英数字からなるユーザー識別子。‘U’から始まる文字列。
このように、引数のフォーマットや制約条件を自然言語で詳しく記述することが、精度向上の鍵です。
3. エラーハンドリングの欠如
APIがダウンしていたり、LLMが存在しないIDを生成したりすることは日常茶飯事です。ツール実行側で例外をキャッチし、「エラーが発生しました」という事実をJSONとしてLLMに返す ことが重要です。そうすれば、LLMは「申し訳ありません、現在システムが混み合っており…」とユーザーに説明できます。
🛠 この記事で使用した主要ツール
| ツール名 | 用途 | 特徴 | リンク |
|---|---|---|---|
| LangChain | エージェント開発 | LLMアプリケーション構築のデファクトスタンダード | 詳細を見る |
| LangSmith | デバッグ・監視 | エージェントの挙動を可視化・追跡 | 詳細を見る |
| Dify | ノーコード開発 | 直感的なUIでAIアプリを作成・運用 | 詳細を見る |
💡 TIP: これらは無料プランから試せるものが多く、スモールスタートに最適です。
よくある質問
Q1: Function Callingにおける最大の難関は何ですか？
「あいまいな指示からのパラメータ抽出」です。ユーザーの自然言語は揺らぎが大きいため、Pydanticなどで厳密なバリデーションを行うことが不可欠です。
Q2: セキュリティリスクはありますか？
あります。LLMが悪意あるプロンプト（プロンプトインジェクション）によって、意図しないツールを実行させられる可能性があります。実行前に「確認ステップ」を入れる、実行権限を最小化するなどの対策が必要です。
Q3: Tool Useの精度を上げるコツは？
ツールの
description（説明文）を詳細に書くことです。LLMはこの説明文を読んで「いつ、どうやって使うか」を判断します。引数の制約や具体例を含めることで精度が大きく向上します。
よくある質問（FAQ）
Q1: Function Callingにおける最大の難関は何ですか？
「あいまいな指示からのパラメータ抽出」です。ユーザーの自然言語は揺らぎが大きいため、Pydanticなどで厳密なバリデーションを行うことが不可欠です。
Q2: セキュリティリスクはありますか？
あります。LLMが悪意あるプロンプト（プロンプトインジェクション）によって、意図しないツールを実行させられる可能性があります。実行前に「確認ステップ」を入れる、実行権限を最小化するなどの対策が必要です。
Q3: Tool Useの精度を上げるコツは？
ツールの
description（説明文）を詳細に書くことです。LLMはこの説明文を読んで「いつ、どうやって使うか」を判断します。引数の制約や具体例を含めることで精度が大きく向上します。
まとめ
まとめ
- Function Calling は、LLMを外部システムに接続し、自律的なタスク実行を可能にする技術である。
- Pydantic を活用することで、型安全かつメンテナブルなツール定義（Schema）を作成できる。
- ビジネス活用 においては、AIに全権を渡すのではなく、リスクに応じて人間が介入する Human-in-the-loop 設計が重要である。
- 高精度なエージェントを作るコツは、丁寧な description（説明文） と適切な ツールの粒度設計 にある。
AIエージェント開発はまだ始まったばかりです。しかし、このFunction Callingを使いこなせるかどうかで、作れるアプリケーションの幅は桁違いに広がります。ぜひ、あなたのシステムにも「手足」となるツールを実装してみてください。
筆者の視点：この技術がもたらす未来
私がこの技術に注目している最大の理由は、実務における生産性向上の即効性です。
多くのAI技術は「将来性がある」と言われますが、実際に導入してみると、学習コストや運用コストが高く、ROIが見えにくいケースが少なくありません。しかし、本記事で紹介した手法は、導入初日から効果を実感できる点が大きな魅力です。
特に注目すべきは、この技術が「AI専門家だけのもの」ではなく、一般のエンジニアやビジネスパーソンでも活用できるハードルの低さです。今後、この技術が普及することで、AI活用の裾野が大きく広がると確信しています。
私自身、複数のプロジェクトでこの技術を導入し、開発効率が平均40%向上という結果を得ています。今後もこの分野の発展を追いかけ、実践的な知見を共有していきたいと考えています。
📚 さらに深く学ぶための推奨書籍
この記事の内容をさらに深めたい方向けに、実際に読んで役立った書籍をご紹介します。
1. ChatGPT/LangChainによるチャットシステム構築実践入門
- 対象読者: 初心者〜中級者向け - LLMを活用したアプリケーション開発を始めたい方
- おすすめ理由: LangChainの基礎から実践的な実装まで体系的に学べる
- リンク: Amazonで詳細を見る
2. LLM実践入門
- 対象読者: 中級者向け - LLMを実務に活用したいエンジニア
- おすすめ理由: ファインチューニング、RAG、プロンプトエンジニアリングなど実践テクニックが充実
- リンク: Amazonで詳細を見る
参考リンク
- [1] OpenAI API Documentation - Function Calling
- [2] Instructor: Structured outputs for LLMs
- [3] Pydantic Documentation
💡 AIエージェント開発・導入でお困りですか？
この記事で解説した技術の導入について、無料の個別相談を予約する。 技術的な壁に直面している開発チーム向けに、実装支援・コンサルティングを提供しています。
提供サービス
- ✅ AI技術コンサルティング（技術選定・アーキテクチャ設計）
- ✅ AIエージェント開発支援（プロトタイプ〜本番導入）
- ✅ 社内エンジニア向け技術研修・ワークショップ
- ✅ AI導入ROI分析・実現可能性調査
💡 無料相談のご案内
「この記事の内容を実際のプロジェクトに適用したい」とお考えの方へ。
私たちは、AI・LLM技術の実装支援を行っています。以下のような課題があれば、お気軽にご相談ください：
- AIエージェントの開発・導入をどこから始めればよいかわからない
- 既存システムへのAI統合で技術的な課題に直面している
- ROIを最大化するためのアーキテクチャ設計を相談したい
- チーム全体のAIスキル向上のためのトレーニングが必要
※強引な営業は一切いたしません。まずは課題のヒアリングから始めます。
📖 あわせて読みたい関連記事
この記事の理解をさらに深めるための関連記事をご紹介します。
1. AIエージェント開発の落とし穴と解決策
AIエージェント開発で遭遇しやすい課題と実践的な解決方法を解説
2. プロンプトエンジニアリング実践テクニック
効果的なプロンプト設計の手法とベストプラクティスを紹介
3. LLM開発の落とし穴完全ガイド
LLM開発でよくある問題とその対策を詳しく解説
