top of page
検索

Function Callingで学ぶAIエージェントの実装パターン ━ Workshop 2レポート

  • ynakahira
  • 11月4日
  • 読了時間: 12分

更新日：11月5日

はじめに


株式会社PROMPT-X(プロンプトX)は、2025年10月10日に開催したAIエージェント講座において、3つのワークショップを通じてAIエージェント技術の実践的な実装方法を解説しました。


本記事では、その中核となる Workshop 2「Function Calling実践」 の内容を詳しくご紹介します。


前回のWorkshop 1では、LLMのコンテキストウィンドウが拡大し、実用性が現実味を帯びている現状について紹介しました。今回のWorkshop 2では、AIエージェントの心臓部とも言える Function Calling（関数呼び出し） 技術に焦点を当て、IoPクラウドからデータを取得するエージェントを構築しました。



AIエージェント実用化の転換点 ━ 2023年6月13日


Function Calling


Function Callingは、 LLM（大規模言語モデル）が必要に応じて外部のツールやAPIを呼び出す技術 です。


2023年6月13日、OpenAIによってFunction Callingが発表されました。これは、LLMエージェントが 「実験的なハック」から「堅牢なエンジニアリング」の領域へと移行した 重要な転換点です。


それ以前にも、Auto-GPT（2023年3月30日リリース）やBabyAGI（2023年3月28日発表）といったLLMをベースにエージェントを実現する試みは存在していました。しかし、これらはプロンプトエンジニアリングに頼った不安定な実装であり、実用的なタスクを完遂させるのは困難でした。


Function Callingの登場により、開発者は構造化されたJSON形式で確実に関数呼び出しの意図を受け取れるようになりました。これにより、LLMは「回答に必要な情報を外部から取得する」「計算ツールを使う」「データベースにアクセスする」といった 動的な行動を信頼性高く 実行できるようになったのです。


WorkflowとAgentの違い


Workshop 1とWorkshop 2の違いを理解するには、Anthropic社が提唱する WorkflowとAgentの区別 が参考になります


料理に例えるなら、 Workflow は「レシピ通りに手順を進める」ようなもので、 Agent は「冷蔵庫の中身を見て、即興で料理を考える」に近いでしょう。


Workshop 1：Workflow型

  • 予め定義されたコードパスでLLMとツールを編成

  • システムプロンプトに知識を埋め込む

  • LLMは提供された知識から回答を生成

  • 処理の流れは設計者が制御


Workshop 2：Agent型

  • LLM自身がプロセスとツール使用を動的に制御

  • LLMが「いつ」「どのツールを」「どのように」使うかを判断

  • ツール実行の結果を見ながら次の行動を決定

  • 処理の流れはLLMが自律的に判断


この違いは決定的です。Workflowは「予め決められた手順を実行」するのに対し、Agentは「状況を見ながら自律的に判断」するのです。


Workshop 1（Workflow）: LLMに行わせる処理をあらかじめ決めておき、クエリに応じて回答を生成。Workshop 2（Agent）: LLMが状況に応じて必要なツール（API）を動的に選択・実行。
Workshop 1（Workflow）: LLMに行わせる処理をあらかじめ決めておき、クエリに応じて回答を生成。Workshop 2（Agent）: LLMが状況に応じて必要なツール（API）を動的に選択・実行。


実践課題：SAWACHI気象データ取得エージェント


IoP クラウド (SAWACHI)


高知県が推進する「IoP（Internet of Plants）」は、園芸用ハウスなど圃場内の植物の状態をIoTセンサーで可視化し、農業の生産性向上を目指すプロジェクトです。その基盤となるのが SAWACHIデータ連携基盤 です。


SAWACHIは現在、 1,000人以上の農家 が利用し、そのデータは 1兆レコード を超えています。


なぜ3段階API設計なのか


Workshop 2では、このSAWACHI Chabudai Service APIから気象データを取得するAIエージェントを構築しました。


SAWACHIのAPIは、以下の 3段階設計 になっています：


ree



第1段階：Model API ( `get_models` )

  • 利用可能なデータモデルの一覧を取得

  • 例：「気象データモデル」「圃場環境モデル」など


第2段階：Asset API (`get_assets`)

  • 各モデル配下のデバイス階層構造を取得

  • 構造：県 → 市町村 → →→ 圃場 →→→ センサー


第3段階：Data API (`get_data`)

  • 特定デバイスの実測データ（時系列）を取得

  • 気温、湿度などのセンサー値


このような設計になっている理由は データ規模 にあります。SAWACHIは1兆件以上のレコードを管理しています。「デバイスXの気温を教えて」という単純なクエリでも、全データをスキャンするのは非現実的です。


ree

段階的な絞り込みにより、効率的なデータ取得が可能になります。これは、ユーザーの自然な思考プロセス「どんなデータがある？」→「どこにある？」→「見せて」にも合致しています。



ReActパターンの実装


Observation → Thought → Action


AIエージェントが複雑なタスクを遂行するには、ReAct（Reasoning + Acting）パターンが有効です。2022年10月に発表された手法で、以下のループ構造を持ちます：


  1. Observation（観察） : 現在の状況を分析

  2. Thought（思考） : 次に何をすべきか推論

  3. Action（行動） : ツール/APIを実行

  4. 結果を観察し、1に戻る


このパターンにより、LLMは結果を見ながら方針を修正できます。単発の命令実行ではなく、 対話的な問題解決 が可能になるのです。


Gemini 2.5 Proをthinkingモデルとして


Workshop 2では、Gemini 2.5 ProをReActパターンの中核（thinkingモデル）として使用しました。


選定理由：

  • 現状最大級のコンテキストウィンドウ：100万トークン

  • 組み込み思考能力：明示的な推論過程を生成

  • 安定したFunction Calling：ツール呼び出しの信頼性が高い

  • コスト効率：他の最上位モデルと比較してリーズナブルであり、無料枠も存在する


Difyワークフローでの実装


参加者には、事前に構築した Dify DSL（YAML形式）ワークフロー を提供しました。このワークフローには以下が実装されています：


  • 3つのツール定義（`get_models`, `get_assets`, `get_data`）

  • ReActループ制御（最大50回の反復）

  • API呼び出し履歴管理（`api_history`変数）

  • レスポンス前処理ロジック（後述）


ワークフローをインポートし、SAWACHI APIの認証情報を設定するだけで、すぐに動作を試せるような内容にしました。



実行例：気温データ取得の流れ


ユーザーが「高知市の気温を教えて」とクエリすると、以下のように処理が進みます：


1回目のループ

  • Observation: ユーザーが気温データを要求している

  • Thought: 「まず利用可能なデータモデルを確認する必要がある。気温データは気象センサーに関連しているはずだ。」

  • Action: `get_models`を実行


2回目のループ

  • Observation: モデル一覧を取得。気象データを扱うモデルが見つかる

  • Thought: 「気象データモデルを発見した。このモデル配下のAsset階層を取得し、高知県のデバイスを探そう。」

  • Action: `get_assets`を気象データモデルのIDで実行


3回目のループ

  • Observation: ルートレベルで「高知県」が存在

  • Thought: 「高知県が見つかった。この配下の市町村レベルに降りていく必要がある。」

  • Action: `get_assets`を`path=高知県`で実行


4-5回目のループ

  • Observation: 「中央西エリア」の中に「南国市」「香南市」など12市町村が表示

  • Thought: 「複数の市町村がある。南国市のデータを確認してみよう。」

  • Action: `get_assets`を`path=kochi/chuonishi/nankoku`で実行


6～N回目のループ

  • 南国市で利用可能な気象データから気温データを探す。

  • Thought: 「気温データのデータIDが見つかった。実測データを取得しよう。」


最終ループ

  • Action: `get_data`で特定したデータIDのデータを取得

  • 結果: 「高知県南国市のの気温は25.3℃です（2025年10月10日 14:30時点）」


このように、LLMが状況を見ながら段階的にゴールに近づいていきます。


重要なのは、 どのAPI呼び出しも事前に決められていない 点です。ユーザーのクエリ内容によって、必要なAPI呼び出しの回数も順序も変わります。これこそが、Workflowではなく Agent の特徴です。


Workshop 2の実装では、各API呼び出しの結果が`api_history`に蓄積され、次の判断材料となります。LLMは過去の結果を踏まえて「次はどうするか」を自律的に決定するのです。



大規模データとLLMの限界


302万文字という壁


ここ、 レスポンスが巨大な場合の処理 を工夫したので紹介します。


気象 Asset APIレスポンスサイズ：

- サイズ： 3.1MB （3,204,704バイト）

- 文字数： 302万文字

- 推定トークン数： 150万～210万トークン


対して、Gemini 2.5 Proのコンテキストウィンドウは 100万トークン です。


つまり、 Asset APIのレスポンスだけでコンテキストウィンドウを超過してしまうのです。


このような大きなレスポンスは決して珍しいものではなく、複雑なウェブサイトのHTMLや、ログファイルも長大になる場合があります。


Workshop 1との比較


Workshop 1で拡大したコンテキストウィンドウについて紹介しましたが、このような実世界で遭遇することのあるデータの大きさについて比較してみましょう：


ree

Workshop 1の知識ベースは文庫本３冊近くでしたが（30件以上のIoP記事を統合）、31.5万文字で約2.3万トークンでした。これはシステムプロンプトに問題なく収まります。


しかしWorkshop 2のAsset APIは、文字数にして 10倍にもなります。このままではLLMに渡すことすらできません。


解決策：階層ごとのデータ絞り込み


この問題を解決するため、ワークフローには 階層ごとにデータを絞り込む前処理 を実装しました。


入力（Asset API 完全レスポンス、3.1MB）：

{

"kochi": {

"stmprj": {

"ST000001": {

"field_1": {

"env_stmprjsensor_1": {

"temperature": {

"displayName": "温度",

"unit": "℃",

"dataId": "84616001-c803-41cc-b517-024b691f8cd4",

"dataType": "number",

"propertyAttributes": [...],

... (その他のメタデータ)

},

"relative_humidity": {

"displayName": "湿度",

"unit": "%",

"dataId": "...",

"dataType": "number",

"propertyAttributes": [...],

... (その他のメタデータ)

},

"fan_control": { ... },

"light_control": { ... },

... (10数個のプロパティ)

},

"vgw_1": { ... }

},

"field_2": { ... },

... (複数の圃場)

},

"ST000002": { ... },

... (複数の農場)

}

}

}



出力（データ絞り込み処理後、数百文字）：


{

"current_level": "root",

"elements": [

{"name": "高知県", "path": "/kochi"}

],

"properties": []

}


さらに「高知県」を選択（`path="/kochi"`を指定）すると：


{

"current_level": "高知県",

"elements": [

{"name": "南国市", "path": "/kochi/chuonishi/nankoku"},

{"name": "香南市", "path": "/kochi/chuonishi/konan"},

{"name": "香美市", "path": "/kochi/chuonishi/kami"},

...

],

"properties": []

}


この前処理により、 99%以上のデータ抑制 を実現しながら、階層を辿るために必要な情報は保持されます。


重要なのは、単にデータを絞り込むだけでなく、 次にアクセスすべき「path」を明確に提示する 設計になっていることです。LLMは `elements` に表示された選択肢から次のpathを選び、段階的に「高知県」→「南国市」→「圃場_001」→「温湿度センサー」へと階層を辿っていきます。これは、ファイルシステムを`cd`コマンドで移動していくのと似ています。


コンテキストウィンドウとの戦い


この事例が示すのは、 「コンテキストウィンドウに収まらないデータが実世界にはまだまだ存在する」 という現実です。


LLMのコンテキストウィンドウは拡大を続けています。Gemini 2.5 Proの100万トークンは、2025年現在の最大級です。しかし、実世界ではそれを上回るデータを扱う場面にしばしば遭遇します。


Function Calling実装では、以下を考慮する必要があります：

  • APIレスポンスのサイズ見積もり

  • 前処理・フィルタリング戦略

  • 段階的データ取得の設計

  • コンテキストウィンドウの効率的な使用



ツール設計の重要性 ━ Agent-Computer Interface


Function Callingでは、 ツール設計の品質がAgent性能を左右します。


Anthropic社は、「Human-Computer Interface (HCI)に注力するのと同等の努力を、ツール設計に投資すべき」と提唱しています。同社はこれをAgent-Computer Interface (ACI)と呼んでいます。


Workshop 2で行ったこのデータ絞り込み処理の工夫は、まさにこのツール設計の最適化です。この記事でもAnthropicが実例として「ツール最適化に費やした時間 > プロンプト最適化に費やした時間」と明かしています。


Anthropicが提唱する効果的なツール設計の原則


Anthropic社は、エージェントのパフォーマンスはプロンプトエンジニアリングよりもツール設計に大きく依存すると強調しています。同社が提唱する「Agent-Computer Interface (ACI)」の考え方に基づいた、効果的なツール設計の4つの主要原則は以下の通りです。


  1. モデルの立場に立ってツールを設計する (Put yourself in the model's

shoes)

  • 使い方が明確か、説明だけで理解できるか考える

2.　詳細で明確なツール説明を提供する (Provide detailed, clear tool

descriptions)

  • 優れたdescription (自然言語によるツールの説明や使い方) を与える：使用例、エッジケース、入力要件を含む

3.　実際の使用をテストして反復改善する (Test and iterate)

  • Workbenchで多くの例を実行し、モデルのミスを見つける

4.　ポカヨケ設計を適用する (Poka-yoke your tools)

  • 間違いを起こしにくい引数設計にする

  • 入力値のバリデーションを備える


Workshop 3への橋渡し ━ MCPによる標準化



Workshop 2で体験したFunction CallingでAIエージェントを実現できました。しかし、実装してみると課題を感じます：


  • 各ツールの詳細な仕様定義 が煩雑（入力、出力、エラー処理）

  • 前項で説明したLLMが理解できる説明文の作成と改善

  • API変更への追従

  • ツール間の依存関係管理


これらの作業は、プロジェクトごとに繰り返す必要があります。さらに、各プラットフォームや開発者が独自にツール実装を進めた結果、「 M×N問題 」（モデル数×ツール数の組み合わせで個別実装が必要）が深刻化しました。


Workshop 3では、この課題に対する解決策として、Anthropic社が2024年11月に発表したMCP（Model Context Protocol）を紹介します。MCPは統一プロトコルを提供し、ツール定義の標準化を通じてプロジェクト間での再利用を可能にします。詳細は次回の記事でご紹介します。


まとめ：Function Callingの本質


Function Callingが実現したこと


2023年6月13日のFunction Calling発表は、LLMの能力を「知識を語る」から「行動する」へと拡張しました。


これにより：

  • リアルタイムの外部データ統合

  • 動的なツール/API呼び出し

  • マルチステップの問題解決（ReActパターン）


が可能になり、真の意味での AIエージェント が誕生しました。


Workshop 2で学んだ実装のポイント


1. コンテキストウィンドウの限界を理解する

  • すべてのAPIレスポンスが収まるわけではない（※コンテキストウィンドウの詳細はWorkshop 1の記事 )

  • 前処理・フィルタリング戦略が必須（階層絞り込み処理の実例）

  • 段階的データ取得の設計が重要


2. ツール設計の品質に投資する


3. WorkflowとAgentを適切に使い分ける

  • Workflow（Workshop 1）：予測可能なタスク、確実性が必要な場合

  • Agent（Workshop 2）：柔軟性が必要、LLM主導の判断が有効な場合

  • 常にシンプルな解決策から始める



次回予告：Workshop 3「MCP実践」


Workshop 3では、Model Context Protocol（MCP）を使ったツール標準化と共有の実践を解説します。また、エージェントのタスク実行の妨げになる要因についても考察します。Function Callingの課題をどう解決するのか、現在のエージェントはどれだけのタスクに対処できるのか。続編記事もご期待ください。



株式会社PROMPT-Xについて


株式会社PROMPT-X（プロンプトX）は、東京・鹿児島・高知の3拠点を構えるソフトウェアメーカーです。時系列データベースCLOUDSHIPと可視化ソフトRealBoardを軸に、IoT/DXプラットフォーム向けソフトウェアの開発・販売を行っています。高知県の農業データ連携基盤IoPクラウド (SAWACHI) をはじめ、複数の大規模DX/IoTプラットフォームのアーキテクチャ設計・開発・構築を担っています。 INDUSTRIAL-Xグループの一員として、「日本の産業構造変革」の実現に向けてテクノロジーで貢献しています（2024年8月グループ入り）。


クラウド（主にAWSやGCP）や、IoT関連の開発支援サービス、DX/IoTプラットフォーム構築の伴走支援、ソリューションの受託開発サービスも提供しています。


INDUSTRIAL-Xグループについて


株式会社INDUSTRIAL-Xは、「産業全体を底上げして付加価値の創造に繋げる共同利用型プラットフォーム構想」の下、企業や自治体のDX推進支援を行っています。XPaaS（Transformation Platform as a Service）を通じて、ビジネスモデル変革から実装までをトータルに支援します。


採用情報


現在、鹿児島・高知での開発エンジニア採用を強化中です！カジュアル面談も随時お受けできますので、お気軽にご連絡ください。



出典・参考文献


Function Calling関連

  • OpenAI "Function calling and other API updates" (https://openai.com/index/function-calling-and-other-api-updates/)

  • Anthropic "Building Effective Agents" (https://www.anthropic.com/engineering/building-effective-agents)

  • Anthropic "Model Context Protocol" (https://www.anthropic.com/news/model-context-protocol)


AIエージェント歴史

  • Auto-GPT - Wikipedia (https://en.wikipedia.org/wiki/Auto-GPT)

  • Yohei Nakajima "Birth of BabyAGI" (https://yoheinakajima.com/birth-of-babyagi/)

  • ReAct論文 "ReAct: Synergizing Reasoning and Acting in Language Models" (https://arxiv.org/abs/2210.03629)


主要技術・プラットフォーム

  • Dify.ai - The Open Source LLM App Development Platform (https://dify.ai/)

  • Google AI for Developers "Gemini Models" (https://ai.google.dev/gemini-api/docs/models)


Workshop関連

  • Workshop 1「コンテキストウィンドウ最適化とAPI コスト削減」(https://blog.prompt-x.jp/post/ai-agent-workshop-context-window-api-pricing)

  • AIエージェント講座レポート（概要編）(https://blog.prompt-x.jp/post/2025-10-13-workshop-report-1010)


高知県 IoP (Internet of Plants)

  • IoP 公式サイト (https://kochi-iop.jp)


コメント

bottom of page