Function Callingとは？AIエージェントの仕組みとLangGraph実装

現在では、LLMと外部ツールを組み合わせることで、自社データの検索、計算、テスト、ファイル操作などを行う「自社専用AIエージェント」を開発できるようになっています。

しかも、小規模な試作であれば、APIや既存のフレームワークを活用することで、以前よりもはるかに少ないコードで実現できます。

その中心となる技術が、今回紹介する「Function Calling」です。

「最近のAI、ただチャットするだけじゃなくて、自分でファイルを書き換えたり、プログラムをテストしたりしてない……？」

そう感じている方は非常に鋭いです。ここ最近、AI（大規模モデル：LLM）を取り巻く技術は、単に「それっぽい文章を生成する」というフェーズから、「外部のツールを自律的に使いこなして作業を完結させる」というフェーズへと劇的な進化を遂げています。

この進化の裏側にあるのが、「Function Calling（ファンクションコーリング）」や「Tool Use（ツール利用）」と呼ばれる技術、それらを応用した「AIエージェント（AI Agent）」という設計パターンです。

今回は、この仕組みの基本から、AIエージェントがどのような歴史をたどって現代の最新ツールへ繋がっているのか、そして「私たち開発者自身が、この高度な仕組みをどのように自作し、実務に活用できるのか」を分かりやすく解説します！

LLMに「電卓」を渡す技術：Function Callingとは？

LLMは文章を作るのが非常に得意ですが、実は「正確な計算」や「リアルタイムな情報の取得（今日の天気や最新の株価など）」は大の苦手です。なぜなら、LLMは本質的に「次に来る確率が最も高い言葉」を予測しているだけだからです。

例えば、LLMに $12,345 \times 67,890$ の計算をさせると、一見もっともらしい嘘（ハルシネーション）を平気で出力してしまうことがあります。

そこで登場したのが Function Calling（関数呼び出し） です。

これは、LLM自体に計算をさせるのではなく、「外部の関数やAPI（電卓や天気予報APIなど）を使うための指示書を作らせる」というアプローチです。

具体的な流れ：

ユーザー： 「$12,345 \times 67,890$は？」と入力する。
LLM： 「自分では正確に計算できない。よし、掛け算のツールを使おう」と判断。
LLMの出力： multiply(a=12345, b=67890) という「関数の呼び出し命令」をデータとして出力。
システム側： 実際のプログラム（電卓）がそれを実行し、結果（838102050）を得る。
LLMの出力： その結果を受け取って、「答えは 838,102,050 です」とユーザーに自然な日本語で返す。

LLM自身に計算させず、得意なプログラムに任せる。これによって、AIの回答の正確性は飛躍的に向上しました。

開発者は既存のLLMにこの機能を「後付け」できるのか？

「GoogleのGeminiやOpenAIのGPTにそんな機能があるのは分かったけれど、自分たちが作った独自のシステムやローカル環境の関数もLLMに組み込めるの？」

結論から言うと、完全に可能です。 むしろ現在のAIアプリケーション開発ではこれが標準的な手法となっています。

組み込み方には大きく分けて2つのアプローチがあります。

アプローチA：API標準の機能を使う

GeminiやGPTなどの主要なAPIには、最初から開発者が独自の関数を登録できる仕組みがあります。自分が作ったプログラム（例：自社の顧客データベース検索関数など）の「名前」と「説明文」をLLMに伝えておくだけで、LLMはユーザーの質問に応じて「この関数をこの引数で動かしてください」という指示を自動で返してくれます。

アプローチB：プロンプトで制御する（オープンソースLLM向けなど）

LangChain（ラングチェーン）などのフレームワークを使うことで、APIに標準機能がなくても「プロンプト（指示文）」の工夫だけで同様の仕組みを実装できます。 LLMに対してあらかじめ以下のように指示をしておきます。

「あなたは calc(式) というツールを使えます。もし計算が必要なら、文章を出力するのをやめて、Action: calc(式) とだけ出力してください」

LLMからこの形式のテキストが返ってきたら、自前のプログラム側でそれを検知し、計算結果を再度LLMに流し込む（コンテクストの再投入）という処理をプログラムで自動化するのです。

実務で好まれる「最も洗練された設計パターン」とは？

「自然言語のチャット文の中に、無理やり関数の実行コマンドを混ぜ込むのはパース（解析）エラーが起きそうで怖い……」

そう思われた開発者の方、その直感は100点満点です。

実務のシステム開発で最も好まれるのは、「LLMには一切文章を喋らせず、純粋なデータ（JSON）だけを出力させる」という手法です。

[ユーザーの質問]
       │
       ▼
[LLM (1回目)] ──「文章は出力せず、JSONだけを返す」
       │
       ▼ （JSONを解析）
[自前システムでの実行] ──「データベース検索や計算を行う」
       │
       ▼ （実行結果をコンテクストに追加）
[LLM (2回目)] ──「これまでの文脈をすべて統合して、ユーザーへの回答を生成」

このように、LLMの主な役割を「次にするべき行動を判断して、必要なデータ（引数）をパッキングすること」に限定し、実行は自前の安全なプログラムに任せる。

そして得られた結果を、もう一度これまでの会話履歴（文脈）の中に「外部からの返答」として追加して、LLMに再度推論させる。

この「推論（思考）」と「実行（行動）」のサイクルをぐるぐる回す構造こそが、AI開発における「自律型エージェント（AI Agent）」のコアな設計パターンです。

コンセプトから実用へ：AIコーディングエージェントの歴史

現在、私たちの手元で動く開発ツールは、この「データ出力 ⇄ 外部プログラム実行 ⇄ コンテクスト再投入」のサイクルを極限まで研ぎ澄ませたものです。この驚異的な進化の系譜を振り返ってみましょう。

① 2023年春：概念の誕生（AutoGPT / BabyAGI）

「自律型エージェント」という言葉が世界的なブームになった最初のきっかけは、2023年3月に登場したオープンソースプロジェクト AutoGPT や BabyAGI でした。 LLMに目標（ゴール）を与えるだけで、自らタスクを分解し、Google検索やファイル作成を自動で繰り返す姿は人々に大きな衝撃を与え、エージェント技術の可能性を世に知らしめました。

② 2023年夏：ターミナル上での実用化（Aider）

コンセプト倒れになりがちだった初期のエージェントに対し、開発者が日常的に使える実用ツールとして登場したのが Aider（エイダー） です。ターミナル上で動作し、Gitと緊密に連携しながら「LLMにコードを書き換えさせ、問題がなければ自動でGitコミットまでさせる」という、開発エージェントの実践的なスタイルを確立しました。

③ 2024年春：初の本格的「AIエンジニア」の衝撃（Devin）

2024年3月、Cognition社が発表した Devin（デヴィン） は、「世界初の完全自律型AIソフトウェアエンジニア」として業界に激震を走らせました。 Devinは、独自のサンドボックス（仮想環境）、内蔵ブラウザ、ターミナルをフルに使いこなし、GitHubのIssue（課題）を読み解いて、自分でテストコードを書いて実行し、エラーを自己修復しながらプログラムをデプロイするまでのプロセスを完全自動化してみせました。

④ 2024後半〜現在：IDE（エディタ）への自然な融合（Cursor）

Devinが「AIに丸投げする」アプローチだったのに対し、人間がコードを書く普段のIDE（統合開発環境）にエージェントをシームレスに融合させたのが Cursor です。「Composer」などの機能により、LLMが自律的に複数のファイルを一度に検索・修正・適用するプロセスを、人間がエディタ上でリアルタイムに監視・指示できるようにしたことで、エージェント開発は「一部の先進的な実験」から「全開発者の日常」へと普及しました。

⑤ 2025年〜：エージェント・ファーストの深化（Claude Code / Google Antigravity）

そして現在、AIエージェントはプラットフォームの枠組みを超えてさらに進化しています。

Claude Code： AnthropicがリリースしたCLIエージェントツール。Claude自体の高い推論能力と高速なレスポンスを活かし、ターミナル上で自律的なバグ修正やテスト実行を爆速で行います。
Google Antigravity： まさに「エージェント・ファースト」の次世代開発プラットフォームです。LLM自体の「数百万トークンを一度に扱える超・長大コンテクスト」をフルに活かし、プロジェクト全体の構造を丸ごと把握しながら、仮想環境で自律的なビルドやテストを回し続けます。

【実用に挑む】自分だけの「特化型エージェント」を自作しよう！

「DevinやCursorのような高度なシステムは、Googleや海外のスタートアップにしか作れないのでは？」

そう思う必要は全くありません。実は、これらと全く同じ仕組みの「自社・自分専用エージェント」は、私たちでも今すぐ自作することができます。

自作エージェントがこれほど現実的になった理由は3つあります。

1. 100%構造化されたデータの出力（Structured Outputs）

現在の主要なLLM（GeminiやGPTなど）には、出力されるJSONが指定したスキーマ（型）に完全に一致することを保証する機能があります。これにより、LLMがパースエラーを起こする確率が実質ゼロになり、システムとの連携が劇的に安定しました。

2. 軽量なエージェント・フレームワークの普及

Pythonだけでなく、Node.js/TypeScript向けのライブラリである LangGraph (JS/TS)、CrewAI などを利用すれば、「LLMに判断させる」➔「関数を実行する」➔「結果をコンテクストに戻す」というループ処理を、型安全かつわずか数十行のコードで実装できます。

ここで、LangGraph（TypeScript版）を使った具体的な実装サンプルコードを見てみましょう。

LangGraphによるエージェントの実装コード例（TypeScript）

以下は、自前で用意した「計算ツール（電卓）」をLLMに持たせ、「推論 ➔ 電卓実行 ➔ 結果の再投入 ➔ 最終回答」という自律サイクルを自動的にぐるぐる回す、TypeScriptによるエージェント実装です。

import { tool } from "@langchain/core/tools";
import { z } from "zod";
import { BaseMessage, Annotation } from "@langchain/core/messages";
import { ChatOpenAI } from "@langchain/openai";
import { StateGraph, START, END } from "@langchain/langgraph";
import { ToolNode } from "@langchain/langgraph/prebuilt";

// 1. エージェントの「記憶（状態）」の型とスキーマを定義
// messages配列を累積していく状態を管理します
const StateAnnotation = Annotation.Root({
  messages: Annotation<BaseMessage[]>({
    reducer: (x, y) => x.concat(y),
    default: () => [],
  }),
});

// 2. LLMに持たせたい「自前の関数（ツール）」を定義
// Zodスキーマを使って引数の型定義と説明文をLLMに伝えます
const calculateMultiply = tool(
  async ({ a, b }) => {
    return (a * b).toString();
  },
  {
    name: "calculate_multiply",
    description: "2つの数値を掛け算する関数。LLMはこれを見て引数を決定します。",
    schema: z.object({
      a: z.number().describe("1つ目の数値"),
      b: z.number().describe("2つ目の数値"),
    }),
  }
);

const tools = [calculateMultiply];
const toolNode = new ToolNode(tools);

// モデルにツールを登録（バインド）
const model = new ChatOpenAI({
  modelName: "gpt-4o",
  temperature: 0,
}).bindTools(tools);

// 3. ノード（処理ステップ）の定義
// LLMを呼び出し、次の行動（文章かツール実行か）を判断させるノード
const callModel = async (state: typeof StateAnnotation.State) => {
  const response = await model.invoke(state.messages);
  return { messages: [response] };
};

// LLMの返答を見て、ツールを動かすか、それとも終了するかを判定する条件分岐関数
const shouldContinue = (state: typeof StateAnnotation.State) => {
  const lastMessage = state.messages[state.messages.length - 1];
  
  // LLMが「ツールを呼び出したい」と判断（tool_callsが存在）した場合
  if (lastMessage.additional_kwargs.tool_calls && lastMessage.additional_kwargs.tool_calls.length > 0) {
    return "tools"; // toolsノードに進む
  }
  return END; // 終了
};

// 4. グラフ（ネットワーク）の構築
const workflow = new StateGraph(StateAnnotation)
  // ノード（点）を追加
  .addNode("agent", callModel)
  .addNode("tools", toolNode)
  // エッジ（線）を追加して流れを定義
  .addEdge(START, "agent")
  // 条件付きエッジ：agentノードの次は、shouldContinue関数の判定によって分岐させる
  .addConditionalEdges("agent", shouldContinue)
  // ツールを実行したら、再度agentノードに戻って考え直させる（ループ構造）
  .addEdge("tools", "agent");

// 5. コンパイルして実行可能なアプリにする
const app = workflow.compile();

// 実行エントリーポイント
async function main() {
  const inputs = {
    messages: [{ role: "user", content: "12345かける67890の計算結果を教えて？" }],
  };

  const stream = await app.stream(inputs);
  for await (const chunk of stream) {
    // 状態の遷移をリアルタイムに出力
    for (const [node, state] of Object.entries(chunk)) {
      const lastMsg = (state as any).messages?.[(state as any).messages.length - 1];
      console.log(`[${node}] 現在の出力:`, lastMsg?.content || "(ツール実行中...)");
    }
  }
}

main().catch(console.error);

このTypeScriptコードでも、最後の .addEdge("tools", "agent") によって、ツール実行結果を持った状態で再度 agent ノードに戻る循環構造が綺麗に表現されています。

型安全な定義により、エージェントの内部状態（StateAnnotation）の管理も強固になり、大規模な自律型ワークフローを安全に本番環境へ載せることが可能になりました。

3. 「自社専用」という最大の武器

Cursorは「コードを書く汎用ツール」ですが、あなたが作るエージェントは「自社の社内データベースを検索し、独自の計算ロジックを通して、社内Slackに結果を投稿する」といった、他には絶対に真似できない「超ドメイン特化型」の仕事にフォーカスさせることができます。

まとめ：AIは「相談相手」から「一緒に働く同僚」へ

かつてのLLMは、質問に対して長文のテキストを返すだけの「チャットボット」でした。

しかし、Function Callingという形でLLMにデータ連携の司令塔としての役割を与え、自前のプログラムで実行結果をコンテクストにフィードバックするというアプローチにより、AIは自律的に考え、行動し、自ら間違いを修正する「エージェント」へと変貌を遂げました。

この驚異的な仕組みは、巨大企業だけの特権ではありません。

APIを叩く簡単なスクリプトと、自前のビジネスロジック（関数）を組み合わせるだけで、今日からあなたも「自分の業務を代わりに進めてくれる優秀なデジタル同僚」を誕生させることができます。

AIにどんな「手足」を授け、どんな仕事を任せるか。これからの開発の主戦場は、まさにこの「カスタムエージェントの自作」へとシフトしていきます。皆さんも一歩先を行くエージェント開発に、今すぐ挑戦してみませんか？