【生成AIによる業務変革LOG #7】

Function CallingでLLMを「業務アシスタント」に！RAGとの使い分け、導入の課題、最新動向を解説

• ・
  はじめに
• ・
  なぜFunction Callingが注目されているのか
• ・
  Function Callingの仕組みとは？
• ・
  RAGとは？Function Callingとの違い
• ・
  Function CallingとRAGの使い分け
• ・
  実際に使ってみたうえでの課題
• ・
  おわりに

ここ数年、大規模言語モデル（LLM）の進化は目覚ましく、日常的な業務でも活用される場面が増えてきました。その中でも、LLMの機能をさらに広げる技術として「Function Calling」や「RAG（Retrieval-Augmented Generation）」が注目を集めています。
私も最近、展示会向けにLLMを使ったデモを作る機会があり、その中でFunction Callingを実際に試してみました。
本記事では、Function Callingとは何か、なぜ注目されているのか、そしてRAGとの違いや使い分けについて、実体験を交えてわかりやすく紹介していきます。

近年、LLMの進化は目覚ましく、この記事を読まれている方の中にも、文章の要約や生成で活用した経験がある方は多いのではないでしょうか。
しかし、現実のビジネスの現場では、「情報を生成する」だけでなく、「何かを実行する」ことが求められる場面が増えてきています。
例えば「明日の東京の天気を教えて」と聞かれた場合、LLMが知識から推測するよりも、最新の天気APIにアクセスして正確なデータを取得するほうが適切です。こうした場面で力を発揮するのが、Function Callingです。
Function Callingを使えば、LLMが外部のAPIやツールと連携し、ユーザーの意図に応じた"具体的なアクション"を実行できるようになります。単なる情報提供にとどまらず、現実の操作や処理を担える――それが、Function Callingが注目されている大きな理由です。

Function Callingとは、ユーザーの入力からLLMが「特定のツール（関数）」の実行が必要かどうかを判断し、必要な引数を関数に渡す仕組みのことです。LLMが手元の情報だけでは対応できないケースにおいて、適切なツールを使って問題を解決するための手段とも言えるでしょう。

図 Function Callingの概略

私の作ったデモをもとに、使い方の流れを説明したいと思います。

今回私が作ったのは、ローカル環境で動作するLLMを使った「旅行アドバイザーAI」のデモです。このデモでは、次のようなステップでFunction Callingが使われています。

1. ユーザーがLLMに指示を出す
   「ニューヨークの観光スポットを３つ教えてください」
2. LLMがその意図を理解し、必要な関数（API）を呼び出す
   LLMが観光情報を検索する「get_sightseeing_spot」関数を選び、引数として「ニューヨーク」を指定
3. 関数が実行され、結果が返ってくる
   APIから観光地の名前、関連URLなどの結果を取得
4. LLMがその結果を自然な言葉に変えて返答する
   「観光地名：URL」のフォーマットで出力させています

ポイントは、関数の設計と呼び出しに必要な情報を自然言語ベースでやりとりできることです。私が実際にデモを作ったときも、関数の説明を記載しておけば、LLMがうまく文脈を判断して必要なタイミングで関数を呼び出してくれて、とても便利でした。

Function Callingと並んで、LLMをより便利に使うための代表的な技術がRAG^*です。
RAGとFunction Callingは何が違うのでしょうか？簡単に整理すると、次のような違いがあります。

Function CallingとRAGはどちらかが優れているというわけではなく、目的によって使い分けるべき技術なのです。

• *
  外部データに有用な情報を蓄えておくことで、LLMが扱える知識を広げ、より正確な回答を導くための仕組み

では、Function CallingとRAGをどのように使い分ければいいのでしょうか？それぞれの特徴を踏まえて、向いている場面を整理してみました。

Function Callingが向いている場面

• 何かの処理を自動化したい時（例：データ取得、レポート作成、通知送信）
• ユーザーの指示に応じてAPIを呼び出す必要がある時
• LLMを「業務アシスタント」「実行エージェント」として使いたい時

RAGが向いている場面

• 大量の文書やナレッジから、必要な情報を検索・回答させたい時
• 最新情報や企業独自データに基づく自然な会話が求められる時
• FAQチャットボットや社内ナレッジQAなどの構築

このように、それぞれに適した場面がありますが、現実のユースケースでは両者を組み合わせて使うこともあります。例えば、RAGで在庫情報を検索・取得し、その情報をもとに、Function Callingで不足分の在庫を自動発注する、といった流れです。
このように、RAGで「知識を補う」、Function Callingで「処理を実行する」と役割を分けて連携させることで、より高度なアプリケーションが実現できます。

Function Callingはとても便利な仕組みですが、実際に使ってみると「ツールの呼び出し判断をLLMに任せる難しさ」を感じる場面がありました。
私が作ったデモでも、意図した関数がうまく選ばれなかったり、引数の値が微妙にズレて処理が正しく実行されないことがありました。
このあたりは、関数の説明を丁寧に書いておくことや、引数を適切に導くためのプロンプト設計がとても重要だと実感しました。
Function Callingは強力な機能ですが、「賢く使ってもらうための工夫」はまだまだ必要だと感じています。

Function Callingは、LLMに「実行力」を与えることで、単なる質問応答や文章生成を超えた活用を可能にします。一方、RAGは「知識の補強」によって、LLMの出力をより正確で信頼できるものにします。
最近では、こうした技術を組み合わせ、より柔軟に連携させるための仕組みとして、「MCP（Model Context Protocol）^**」も注目されており、複雑なユースケースでも自然な対話を実現できる可能性があります。
今後、LLMがより高度な業務支援を担っていく上で、Function CallingやRAG、そしてMCPのような技術はますます重要になると感じています。今回のデモ制作を通じて、LLMの「次の可能性」に触れられたのは、とても良い経験でした。

• **
  Function CallingやRAGなど複数の拡張手法を統一的に扱えるプロトコル。