Gemini APIでチャットボットを作ったのに、「今日の天気を教えて」と聞かれてもモデルは天気を知らず、「会議を予約して」と頼まれても実際にカレンダーへ書き込めない――そんな壁にぶつかっていないだろうか。
結論から言うと、この壁を越える標準機能がFunction Calling(関数呼び出し)である。Gemini API公式ドキュメントはFunction Callingを「モデルを外部のツールやAPIに接続する機能」と定義しており、モデル自身が外部システムを直接操作するのではなく、モデルが「どの関数を、どんな引数で呼ぶべきか」を判断し、実行は常にアプリケーション側が担う、という役割分担が徹底されている。出典はGemini API公式ドキュメント(Function calling with the Gemini API)。
本記事では、Function Callingの公式定義から、4ステップの仕組み、関数定義(Function Declaration)の書き方、auto/any/none/validatedのモード切り替え、並列・複合呼び出し、組み込みツールやリモートMCPとの併用、料金への影響、実装のベストプラクティス、Gemini CLIとの使い分けまでを公式ドキュメントに基づいて整理する。仮の例として「照明の明るさと色温度を変更する」という一つの関数を通して、関数定義から結果を返すまでの一連の流れを追っていく。
Gemini APIやGoogle AI Studioの基本的な使い方をまだ確認していない場合は、先にGoogle AIの使い方ガイドを読んでおくと理解しやすい。
Function Callingとは何か|公式定義と3つの活用シーン
【完全無料】AI×SNSで成果を出す100大特典を受け取る
AIの使い方を、SNS運用の実務につなげたい方へ。LINEで特典の案内を受け取れます。
Function Callingとは、Gemini APIのモデルが自然言語の指示から「どの外部関数を、どの引数で呼び出すべきか」を判断し、実際の関数実行と結果の反映をアプリケーション側に委ねる仕組みである。モデル自身がAPIやデータベースを直接操作することはない。
Gemini API公式ドキュメントは、Function Callingについて「モデルを外部のツールやAPIに接続することができる。テキストの応答を生成する代わりに、モデルは特定の関数をいつ呼び出すべきかを判断し、実世界の操作を実行するために必要なパラメータを提供する」と説明している。この定義はGemini API公式ドキュメントに基づく。
公式ドキュメントはFunction Callingの活用シーンを次の表のように整理している。
| 活用シーン | 公式の説明 | 仮の例 |
|---|---|---|
| Take Actions(操作の実行) | 予定の登録・請求書の作成・メール送信・スマートホーム機器の操作など、外部システムをAPI経由で操作する | 「会議を予約して」という指示から日時・参加者を抜き出し、カレンダーAPIへ渡す |
| Augment Knowledge(知識の拡張) | データベース・API・ナレッジベースなど外部の情報源にアクセスする | 「東京の今日の気温は?」という質問に対し、天気APIから最新の気温を取得する |
| Extend Capabilities(能力の拡張) | 計算やグラフ作成など、モデル単体では正確に行いにくい処理を外部ツールに任せる | 複雑な為替計算を計算ツールに実行させ、結果だけをモデルが文章化する |
以降の見出しでは、天気取得やスケジュール登録のような単発の関数ではなく、「照明の明るさと色温度を変更する」という一つの仮の例を通して、関数定義から実装までを一貫して追っていく。
Function Callingの仕組み|4ステップで理解する全体像
Function Callingは、(1)関数定義の提示、(2)モデルへの呼び出し、(3)アプリケーション側での関数実行、(4)実行結果をモデルへ返す、という4ステップのやり取りを1ターンまたは複数ターンにわたって繰り返す仕組みである。モデル自身が関数を実行することはない。
Gemini API公式ドキュメントは、Function Callingの一連の流れを次の4ステップで説明している。
- 関数定義(Function Declaration)を定義する:関数の名前・パラメータ・目的をモデルに伝える
- 関数定義付きでモデルを呼び出す:ユーザーの指示と関数定義をあわせてモデルに送信する
- 関数コードを実行する(アプリケーション側の責任):モデルは関数を自ら実行しない。名前と引数を取り出し、自分のアプリケーション内で実行する
- ユーザー向けの応答を作成する:実行結果をモデルへ送り返し、最終的な自然文の応答を得る
このプロセスは複数ターンにわたって繰り返すことができ、モデルは1回のターンで複数の関数を同時に呼び出す(並列関数呼び出し)ことも、順番に呼び出す(複合関数呼び出し)こともサポートしている。それぞれ後述の見出しで扱う。出典はGemini API公式ドキュメント(日本語版)。
Step1: 関数定義(Function Declaration)を書く
関数定義(Function Declaration)とは、モデルに関数の名前・説明・パラメータのスキーマをJSON形式で伝えるオブジェクトであり、実際の関数の処理ロジックそのものではない。パラメータの記述にはOpenAPIスキーマのサブセットを使う。
ここからは「照明の明るさと色温度を変更する」という仮の例で、関数定義の書き方を見ていく。次のコードは、Pythonでset_light_valuesという関数を定義した例である。
from google import genai
set_light_values_declaration = {
"type": "function",
"name": "set_light_values",
"description": "Sets the brightness and color temperature of a light.",
"parameters": {
"type": "object",
"properties": {
"brightness": {
"type": "integer",
"description": "Light level from 0 to 100",
},
"color_temp": {
"type": "string",
"enum": ["daylight", "cool", "warm"],
"description": "Color temperature",
},
},
"required": ["brightness", "color_temp"],
},
}
def set_light_values(brightness: int, color_temp: str) -> dict:
"""Set the brightness and color temperature of a room light."""
return {"brightness": brightness, "colorTemperature": color_temp}
この仮の例では、brightness(明るさ)とcolor_temp(色温度)という2つの引数を持つ関数を定義し、color_tempは”daylight”/”cool”/”warm”の3値に限定するenumで縛っている。パラメータの型を具体的に指定するほど、モデルが誤った値を渡す可能性は下がる、と公式ドキュメントもベストプラクティスの一つとして挙げている(詳細は後述)。出典はGemini API公式ドキュメント。
Step2〜4: モデル呼び出しから結果を返すまでの実装
Step2ではtools引数に関数定義を渡してモデルを呼び出し、返り値のsteps内にあるtype=”function_call”のステップから関数名と引数を取り出す。Step3でアプリケーション側がその関数を実際に実行し、Step4でprevious_interaction_idを指定したうえで実行結果をtype=”function_result”として送り返すと、モデルは最終的な自然文の応答を生成する。
client = genai.Client()
# Step2: 関数定義付きでモデルを呼び出す
interaction = client.interactions.create(
model="gemini-3.8-flash",
input="Turn the lights down to a romantic level",
tools=[set_light_values_declaration],
)
fc_step = next(s for s in interaction.steps if s.type == "function_call")
print(fc_step)
# type='function_call' name='set_light_values' arguments={'color_temp': 'warm', 'brightness': 25}
# Step3: 関数を実行する(アプリケーション側の責任)
if fc_step.name == "set_light_values":
result = set_light_values(**fc_step.arguments)
# Step4: previous_interaction_idを指定して結果を返す
final_interaction = client.interactions.create(
model="gemini-3.8-flash",
input=[{
"type": "function_result",
"name": fc_step.name,
"call_id": fc_step.id,
"result": [{"type": "text", "text": json.dumps(result)}],
}],
tools=[set_light_values_declaration],
previous_interaction_id=interaction.id,
)
print(final_interaction.output_text)
この仮の例では、”Turn the lights down to a romantic level”(照明をロマンチックな明るさまで下げて)という曖昧な自然文の指示から、モデルがbrightness=25・color_temp=”warm”という具体的な引数を導き出している。ここまでの4ステップを一つのコードにまとめると、外部システムを操作する会話型インターフェースが完成する。
Gemini 3シリーズのモデルは、関数呼び出しの精度を高める内部的な「思考」プロセスを使用しており、SDKがthought signatures(思考シグネチャ)を自動的に処理する。この仮の例ではGemini 3.8 Flash(できることと制限はGemini 3.8 Flashとはで詳しく解説している)を指定しているが、Function Calling自体は3系の他モデルでも同じ枠組みで利用できる。出典はGemini API公式ドキュメント。
Function Calling Modes|auto/any/none/validatedの使い分け
Function Calling Modesは、generation_configのtool_choiceで指定する、モデルが関数呼び出しをどう扱うかの制御方法である。既定値はauto(モデルが判断)で、any(常に関数呼び出しを強制)・none(関数呼び出しを禁止)・validated(関数スキーマ準拠を保証)の4種類が公式に定義されている。
Gemini API公式ドキュメントは、tool_choiceで指定できるモードを次のように定義している。
| モード | 公式の挙動 | 使いどころ |
|---|---|---|
| auto(既定値) | モデルが関数を呼ぶか、直接応答するかを自分で判断する | 通常の会話型アシスタントなど、関数を使うかどうかを毎回モデルに任せたい場合 |
| any | モデルは常に関数呼び出しを予測するように制約される | ユーザーの発話を毎回特定のアクションへ変換したいワークフロー(仮の例:注文フォームの確定処理) |
| none | モデルは関数呼び出しを行うことを禁止される | 一時的に関数呼び出しを止めて、通常のテキスト生成だけを行わせたいデバッグ時 |
| validated | モデルは関数スキーマへの準拠を保証する | 引数の型や必須項目の逸脱を許容できない、厳格な連携が必要な場面 |
anyモードでは、allowed_toolsでtoolsのリストを絞り込むこともできる。次の仮の例は、get_current_temperature関数だけを強制的に呼ばせる設定である。
generation_config = {
"tool_choice": {
"allowed_tools": {
"mode": "any",
"tools": ["get_current_temperature"]
}
}
}
並列関数呼び出し(Parallel Function Calling)で複数の操作を一度に頼む
並列関数呼び出し(Parallel Function Calling)とは、独立した複数の関数を同じターン内で同時に呼び出す仕組みである。tool_choiceを”any”にすると、モデルは条件を満たす関数をまとめて呼び出しやすくなる。
公式ドキュメントは並列関数呼び出しを「独立した複数の関数を一度に呼び出す」機能と説明している。仮の例として、ディスコボールの電源・音楽再生・照明という3つの独立した関数を、一つの指示から同時に呼び出すコードを見てみる。
power_disco_ball = {"type": "function", "name": "power_disco_ball",
"description": "Powers the disco ball.",
"parameters": {"type": "object", "properties": {"power": {"type": "boolean"}}, "required": ["power"]}}
start_music = {"type": "function", "name": "start_music",
"description": "Play music.",
"parameters": {"type": "object", "properties": {
"energetic": {"type": "boolean"}, "loud": {"type": "boolean"}},
"required": ["energetic", "loud"]}}
dim_lights = {"type": "function", "name": "dim_lights",
"description": "Dim the lights.",
"parameters": {"type": "object", "properties": {"brightness": {"type": "number"}}, "required": ["brightness"]}}
client = genai.Client()
interaction = client.interactions.create(
model="gemini-3.8-flash",
input="Turn this place into a party!",
tools=[power_disco_ball, start_music, dim_lights],
generation_config={"tool_choice": "any"},
)
for step in interaction.steps:
if step.type == "function_call":
args = ", ".join(f"{key}={val}" for key, val in step.arguments.items())
print(f"{step.name}({args})")
“Turn this place into a party!”という一つの発話から、power_disco_ball・start_music・dim_lightsという3つの関数呼び出しが同じターンでまとめて返る。独立した操作をまとめて実行したい場面の仮の例として分かりやすい。出典はGemini API公式ドキュメント。
複合関数呼び出し(Compositional Function Calling)で処理を連鎖させる
複合関数呼び出し(Compositional Function Calling)とは、ある関数の実行結果を次の関数の判断材料として使うなど、複数の関数呼び出しを順番に連鎖させる仕組みである。「まず場所を取得し、その場所の天気を取得する」といった複雑な要求に向く。
公式ドキュメントは複合関数呼び出しの仮の例として「ロンドンの気温が20℃より高ければサーモスタットを20℃に、そうでなければ18℃に設定する」という条件分岐を挙げている。
get_weather_forecast_declaration = {
"type": "function", "name": "get_weather_forecast",
"description": "Gets the current weather temperature for a given location.",
"parameters": {"type": "object",
"properties": {"location": {"type": "string", "description": "The location"}},
"required": ["location"]}}
set_thermostat_temperature_declaration = {
"type": "function", "name": "set_thermostat_temperature",
"description": "Sets the thermostat to a desired temperature.",
"parameters": {"type": "object",
"properties": {"temperature": {"type": "integer", "description": "The temperature in Celsius"}},
"required": ["temperature"]}}
client = genai.Client()
interaction = client.interactions.create(
model="gemini-3.8-flash",
input="If it's warmer than 20°C in London, set the thermostat to 20°C, otherwise 18°C.",
tools=[get_weather_forecast_declaration, set_thermostat_temperature_declaration],
)
for step in interaction.steps:
if step.type == "function_call":
print(f"Function to call: {step.name}")
print(f"Arguments: {step.arguments}")
この場合モデルは、まずget_weather_forecastを呼んでロンドンの気温を取得し、その結果を踏まえてset_thermostat_temperatureを呼ぶ、という2段階の判断を一つの複合的なやり取りの中で行う。並列呼び出しとの違いは、後段の関数の引数が前段の結果に依存する点にある。
組み込みツールとの併用(Multi-tool use)|検索やコード実行と組み合わせる
Multi-tool useとは、Google検索やコード実行などGoogle公式の組み込みツールと、自作のFunction Callingを同じリクエストで併用できる仕組みである。Gemini 3モデルはInteractions APIでこれを標準サポートし、previous_interaction_idを渡すことで組み込みツールのコンテキストが自動的に引き継がれる。
公式ドキュメントによれば、複数のツールを同時に有効化し、組み込みツールとFunction Callingを組み合わせることができる。最新情報の検索が必要な場面では、自作の関数だけに頼らずGoogle検索によるグラウンディングを併用したほうが裏取りとして有効なことが多い。主な組み込みツールと料金は次の表の通りである。出典はGemini API公式の料金ページ。
| 組み込みツール | 無料枠 | 有料ティアの料金 | 主な用途 |
|---|---|---|---|
| Google検索(グラウンディング) | Gemini 3モデルは月5,000件の無料検索リクエスト(全モデル共有) | 超過分は1,000件あたり14ドル | 最新情報・事実確認が必要な回答の裏付け |
| Google マップ(グラウンディング) | 1,500 RPD無料(Flash/Flash-Lite共有)、Proは10,000 RPD無料 | 超過分は1,000件あたり25ドル | 場所・経路など地理情報に基づく回答 |
| コード実行(Code execution) | ツール自体は無料 | 生成コードと実行結果を通常のトークン料金で課金 | 計算・データ集計などモデル単体では不正確になりやすい処理 |
| URLコンテキスト | ツール自体は無料 | 取得したページ内容を入力トークンとして課金 | 指定したURLの内容を読み込ませて回答させる |
| ファイル検索(File search) | ツール自体は無料 | エンベディングは100万トークンあたり0.15ドル、取得ドキュメントは通常のトークン料金 | アップロード済みドキュメントからの検索・引用 |
リモートMCPサーバーに接続して外部ツールを使う
リモートMCP(Model Context Protocol)とは、外部のMCPサーバーが提供するツール群を、Interactions APIのtools設定にサーバー名とURLを渡すだけで利用できる仕組みである。毎回Function Declarationを自分で書かずに、MCPサーバー側が公開するツールをそのまま呼び出せる。
公式ドキュメントは、リモートMCPを利用する際の制約として次の2点を挙げている。
- サーバー種別:Streamable HTTPサーバーにのみ対応し、SSE(Server-Sent Events)サーバーはサポートされない
- 命名規則:MCPサーバー名にハイフン(-)を含めることはできず、代わりにsnake_case(アンダースコア区切り)の名前を使う
独自のFunction Declarationを大量に書きたくない場合や、すでに運用されているMCPサーバーの資産を流用したい場合には、まずリモートMCP接続を検討するとよい。
Function Callingの料金|追加費用はかかるか
Function Calling自体は、Gemini API公式の料金ページに掲載されている「ツールの料金」一覧に個別の項目として存在しない。自作の関数はモデルへの入力・出力トークンとして計算されるだけで、関数呼び出しという機能そのものに追加課金は発生しない。
公式のGemini API料金ページの「ツールの料金」表には、Google検索・Googleマップ・コード実行・URLコンテキスト・パソコンの使用・ファイル検索・カスタムツールエンドポイントが掲載されているが、利用者が自分で定義するFunction Calling自体は独立した課金項目として存在しない。これは、関数定義・モデルが生成する引数・関数実行結果が、すべて通常の入力/出力トークンとして数えられるためである。モデル単価の詳細はGemini API料金の読み方2026を参照してほしい。
ただし、Function Callingと組み込みツールを併用する場合は話が別になる。実際に費用へ影響する主なパターンは次の表の通り。
| 項目 | 追加課金 | 備考 |
|---|---|---|
| 自作の関数(Function Calling) | なし(標準のトークン料金のみ) | 関数定義・引数・結果テキストはすべて入力/出力トークンとして計算される |
| Google検索によるグラウンディング | 無料枠超過分から課金 | Gemini 3モデルは月5,000件無料、その後1,000件あたり14ドル |
| コード実行(Code execution) | なし(標準のトークン料金のみ) | 生成コードと実行結果は出力/入力トークンとして課金される |
| リモートMCPサーバー接続 | ツール自体は無料 | MCP経由で実行される関数呼び出しの結果は通常のトークンとして計算される |
「Function Callingを使うと追加料金がかかるのでは」と身構える必要はなく、料金設計はあくまでモデルの標準単価がベースになる。仮の例として、gemini-3.8-flashで100回のFunction Calling付きリクエストを送っても、Google検索などの有料ツールを呼んでいない限り、通常のテキストのみの会話と同じ単価体系で計算される。
実装のベストプラクティスとよくある失敗
Function Calling実装のベストプラクティスとは、関数説明を明確にする、命名規則を統一する、型を厳格にする、有効化するツール数を絞る、エラーハンドリングを実装する、といった公式ドキュメントが挙げる具体的な設計指針である。
公式ドキュメントは、推奨されるベストプラクティスとして次の8項目を挙げている。
- 関数と引数の説明:明確かつ具体的に書く
- 命名:スペースや特殊文字を含まない分かりやすい名前にする
- 厳格な型付け:integer/string/enumなど具体的な型を使う
- ツール選定:有効化するツールは10〜20個までに抑える
- プロンプト設計:文脈と指示を丁寧に与える
- 検証:関数呼び出しの内容を実行前に検証する
- エラーハンドリング:堅牢なエラー処理を実装する
- セキュリティ:外部APIに応じた適切な認証を使う
公式ドキュメントは、ツール呼び出しの直前にXML/YAML/JSONのような構造化テキストの出力をモデルに強制すると、まれにMalformed_Function_Callというエラーで失敗する既知の問題があると説明している。推奨される回避策は、構造化テキストの代わりにupdate()のような専用の関数呼び出しへ「作業メモ」を持たせることであり、ツール呼び出し前に生のXMLタグを出力させる指示を避けるだけでも改善するとされている。出典はGemini API公式ドキュメント。
そのほか、対応するパラメータのスキーマはOpenAPIスキーマの一部に限られ、非常に大きい・深くネストしたスキーマは拒否されることがある点、Pythonでサポートされるパラメータ型にも制限がある点は、実装前に把握しておきたい。
Gemini CLIとの違い|自分で実装すべきか、CLIに任せるかの判断基準
Gemini APIのFunction Callingは開発者が自分の関数定義とアプリケーションコードを書いて連携させる仕組みであるのに対し、Gemini CLIはコード理解やファイル操作などの組み込みツールをあらかじめ備えたコマンドラインツールであり、利用者が個別のFunction Declarationを書く必要はない。
「自分の業務システムや社内APIをGeminiから呼び出したい」という要件であれば、Function Callingで独自の関数を定義するのが本筋である。一方、「ローカルのコードを読み書き・実行してほしい」「リポジトリを要約してほしい」といった開発者向けの定型作業であれば、あらかじめ組み込みツールを備えたGemini CLIの使い方を使うほうが、関数定義を書く手間がかからない。両者は排他的ではなく、Gemini CLI自体もMCPサーバー経由でツールを拡張できるため、CLIでの自動化とAPIでのFunction Callingを用途に応じて使い分けるのが現実的な判断基準になる。
仮の例として、社内の在庫管理システムのAPIをGeminiに呼ばせたい場合はFunction Callingで自作の関数を定義し、「このリポジトリのテストを実行してカバレッジを教えて」という定型的な開発作業であればGemini CLIに任せたほうが早い、という切り分けになる。
よくある質問(FAQ)
- Q1. Function CallingとStructured Output(構造化出力)はどう違いますか?
- Function Callingはモデルに外部の関数を呼ばせて実際の処理を実行させる仕組みであるのに対し、Structured Outputはモデルの最終的な応答そのものを指定したJSON形式に整形する機能である。両者は排他的ではなく、公式ドキュメントはGemini 3シリーズのモデルでFunction CallingとStructured Outputを組み合わせて、一貫したフォーマットの応答を得る使い方を紹介している。
- Q2. ChatGPTのtools(Function calling)とGeminiのFunction Callingの違いは何ですか?
- どちらも「モデルが外部関数の呼び出しをJSON形式で提案し、実行はアプリケーション側が行う」という基本設計は共通している。呼び出し方や返り値の構造(GeminiはInteractions APIのsteps、previous_interaction_idによる会話継続など)はプラットフォームごとに異なるため、乗り換えを検討する場合は各社の公式リファレンスで引数の形式を確認する必要がある。両モデルの得意分野の違いはGeminiとChatGPTの違いはどっち?で整理している。
- Q3. NotebookLMでもFunction Callingは使えますか?
- NotebookLMは、アップロードした資料の要約・音声概要生成・質問応答に特化したツールであり、利用者が自分でFunction Declarationを書いて外部関数を呼び出すAPIは公開されていない。資料整理や要約を目的とするならNotebookLMの使い方、外部システムとの連携を自分で組みたいならGemini APIのFunction Calling、と目的で使い分けるとよい。
- Q4. Geminiのスマホアプリ(公式アプリ)でFunction Callingは使えますか?
- Function CallingはGemini APIの開発者向け機能であり、スマホの公式アプリのUI上で関数定義を書く画面は用意されていない。スマホアプリ側の操作手順はGeminiスマホアプリの使い方を参照し、外部システムとの連携を組みたい場合はAPIキーを発行してFunction Callingを実装する必要がある。
- Q5. Google AI Plus/Pro/Ultraプランに入っていればFunction Callingを使えますか?
- Plus/Pro/Ultraは主にGeminiアプリやGoogle Workspaceでの利用枠を広げる個人向けサブスクリプションであり、Function CallingはGemini APIをAPIキーで直接呼び出す開発者向け機能である。課金体系が異なるため、プランの違いはGoogle AIプランの違い、API側の単価はGemini API料金の読み方2026で別々に確認する必要がある。
- Q6. Deep Researchエージェントを使えば、自分でFunction Callingを実装する必要はなくなりますか?
- Deep Researchエージェントは、複数ステップの調査タスクをあらかじめ組み込まれたツール群で自動的に処理するため、単純な調査目的であれば自分で関数を定義する必要は薄れる。一方で、社内システムや独自APIとの連携など、Google公式が用意していない外部システムを操作したい場合は、引き続きFunction Callingで自作の関数を定義する必要がある。用途の違いはGeminiのDeep Researchの使い方で解説している。
- Q7. Function Callingで同時に使えるツールの数に上限はありますか?
- 公式ドキュメントは明確な上限値は示していないが、ベストプラクティスとして有効化するツールセットは10〜20個程度までに抑えることを推奨している。ツール数が増えるほどモデルが適切な関数を選びにくくなるため、必要な関数だけを都度有効化する設計が望ましいとされている。
まとめ
Function Callingは、Gemini APIのモデルに「何の関数を、どんな引数で呼ぶべきか」を判断させ、実際の実行と結果の反映は常にアプリケーション側が担う、という役割分担の上に成り立つ仕組みである。関数定義(Function Declaration)を書き、モデルを呼び出し、関数を実行し、結果を返す、という4ステップさえ押さえれば、天気取得のような単発の処理から、並列・複合的な連鎖処理、組み込みツールやリモートMCPとの併用まで、同じ枠組みの中で組み立てられる。
料金面では、自作の関数を呼ぶこと自体に追加課金はなく、標準のトークン料金の範囲で扱える。まずは本記事の仮の例をそのまま動かしてみて、次にauto/any/none/validatedのモードを切り替えながら、自分のユースケースに合わせた関数定義を一つずつ増やしていくのが、実装を安定させる近道になる。
あわせて読みたい・姉妹メディア
