デジタルバンクにおいて、口座残高をでっち上げるサポートボットは、単に役に立たないだけでなく、非常に危険です。金融に関する会話には、正確な数値、確認済みの受取人、そしてあらゆる主張に対する監査証跡が求められます。大規模言語モデル（LLM）は会話には長けていますが、ハルシネーション（もっともらしい嘘）を起こします。「口座の残高はいくらですか？」とユーザーが尋ねたとき、モデルは想像ではなく、データベースを参照しなければなりません。それこそが関数呼び出し（function calling）が強制するものであり、この構築における核心です。

GoogleのGemma 4は、複雑な指示に従い、地域的な方言を含む自然な対話を行える、能力の高い310億パラメータのモデルを開発者に提供します。Google AI Studioと組み合わせることで、ツールを定義し、エッジケースをテストし、サーバーに触れる前に動作するJavaScriptをエクスポートできる、迅速なプロトタイピング環境となります。ここでの目標は、口座残高を確認し、取引ステータスを追跡し、請求書を支払うフィンテック・サポートエージェントです。重要なのは、ユーザーがナイジェリア・ピジンで話した場合には、金融に関する事実を捏造することなく、トーンを合わせてナイジェリア・ピジンで応答することです。

金融ボットにおいて関数呼び出しが重要な理由

関数呼び出しがなければ、言語モデルはあらゆる質問をクリエイティブ・ライティング（創作）の演習として扱ってしまいます。残高を尋ねれば、学習データのパターンから抽出した、もっともらしく聞こえる数値を捏造するかもしれません。現実のお金が関わる場合、そのような失敗モードは許容できません。

関数呼び出しはこの流れを逆転させます。モデルの役割は残高を知ることではありません。意図を認識し、正しいツールを選択し、パラメータを抽出することです。ユーザーが「残高を確認して」と入力すると、Gemma 4は account_id を含む get_balance への呼び出しのような、構造化されたJSONリクエストを出力します。バックエンドがその呼び出しを基幹銀行システムに対して実行し、実際の数値を取得して会話に戻します。モデルが人間向けの文章を生成するのは、その後のことです。すべての回答は、バックエンドへのツール呼び出しに基づいています。モデルは外部ロジックによって制御されているため、ハルシネーションはAPIの境界で食い止められます。

このパターンは、明確な監査証跡も作成します。各ツールのリクエストとその対応する結果は、メッセージ履歴にログとして記録されます。規制当局やリスク管理チームは、いつ残高が確認され、ユーザーがどの数値を受け取ったかを正確に検査できます。

Google AI Studioでのエージェント設計

ワークフローはGoogle AI Studio内から始まります。対話と指示への追従に最適化された指示チューニング済みモデルである gemma-4-31b-it を選択します。

次に、厳格な境界を設定するシステム指示（system instructions）を記述します。デジタルバンクの場合、トーンはプロフェッショナルで、直接的かつ冷静であるべきです。しかし、指示はそれ以上に踏み込む必要があります。口座データを決して推測しないこと、取引ステータスを勝手に決めつけないこと、ツールの結果を確認せずに請求書の支払いを完了させないことを、モデルに明示的に伝えます。ユーザーがナイジェリア・ピジンで書いた場合は、モデルもナイジェリア・ピジンで返答すべきです。ユーザーが英語に切り替えた場合は、モデルもそれに従います。システムプロンプトは、信頼性と安全性のポリシーを平易な言葉でエンコードする場所です。

次に、ツールのスキーマを定義します。これらはモデルとバックエンドの間の「契約」だと考えてください。少なくとも以下の3つが必要です。

  1. get_balance
    パラメータ: account_id (string, 必須)
    戻り値: 現在の残高と通貨。

  2. get_transaction_status
    パラメータ: transaction_reference (string, 必須)
    戻り値: 保留中、完了、失敗などのステータスとタイムスタンプ。

  3. pay_bill
    パラメータ: biller_code (string, 必須), amount (number, 必須), account_pin (string, フローに応じて任意)
    戻り値: 確認リファレンスまたはエラーメッセージ。

各スキーマは、関数名、説明、パラメータのプロパティを記述する標準的なJSON形式を使用します。説明（description）フィールドは極めて重要です。モデルがいつ各ツールを呼び出すべきかを理解できるように記述してください。曖昧な説明は誤ったツールの選択につながるため、具体的に記述します。「ユーザーが現在の口座残高を知りたいときに get_balance を使用してください。取引履歴には使用しないでください」といった具合です。

ブラウザでのプロトタイピング

Expressのルートを一つも書く前に、AI Studioのチャットパネル内で会話フロー全体をテストしてください。これにより、バックエンドのやり直しにかかる数日間を節約できます。ナイジェリア・ピジンでクエリを入力してみます：「Wetin remain inside my account?」。Gemma 4が正しく get_balance の呼び出しを出力するか、それとも学習データから答えようとするかを観察します。もしパラメータが間違っている場合（例えば account_id の代わりに account_number を使用している場合など）は、その場でスキーマの説明を修正します。

失敗モードもテストしてください。リファレンス番号を提供せずに、取引ステータスを尋ねてみます。指示が適切になされているモデルであれば、不足しているパラメータをユーザーに尋ねるか、あるいは手元にある情報でツールを呼び出し、バックエンドにバリデーションエラーを返させるかのいずれかを行うはずです。こうした挙動は、本番環境ではなくサンドボックスで確認しておく必要があります。

プロンプトとスキーマが正しく動作したら、JavaScriptコードをエクスポートします。AI Studioは、システムプロンプト、ユーザーメッセージ、およびツール定義を使用してAPIリクエストを構成する、クリーンなスニペットを生成します。これがバックエンドロジックの基盤となります。

Express バックエンドの構築

エクスポートしたコードをExpressアプリケーションに組み込みます。アーキテクチャは単純ですが、実行ループが極めて重要な要素となります。

ユーザーのメッセージとセッション履歴を受け取るPOSTエンドポイント（例えば /chat）をセットアップします。これらをGemma 4のエンドポイントに転送します。ホスティングの選択に応じて、OpenAI互換APIまたはGoogle独自の推論エンドポイント経由でアクセスできます。

モデルからのレスポンスは、2つのカテゴリのいずれかに分類されます。最終的なテキストメッセージであるか、あるいはデータを要求する tool_call を含んでいるかです。ツールコールを受け取ったら、バックエンドに対して対応する関数を実行します。データベースに問い合わせて残高を取得したり、決済プロセッサに問い合わせて請求ステータスを確認したりします。ツール実行の結果を、ロールが tool の新しいメッセージとして会話履歴に追加し、更新された配列全体をGemma 4に送り返します。

モデルが最終的なテキスト回答を返すまで、このループを繰り返します。その回答は、提供した実際のデータに基づいたものになります。ループの各パスは単なるHTTPリクエストであり、ツールの実行を async/await でクリーンに処理できるため、Expressを使えばこの調整は容易です。

開発の初期段階では、これらのツールコールをモックデータで代用してください。サンプルのアカウントIDと残高をマッピングした単純なJavaScriptオブジェクトがあれば、ループが機能することを確認するには十分です。重要なのは、壊れやすいサードパーティの銀行APIと統合する前に、インタラクションパターンを検証しておくことです。

プロトタイプから本番環境へ

動作するプロトタイプは本番用の銀行インフラではありませんが、プロトタイプから本番環境への道のりは明確です。

モックデータを実際のコアバンキングAPIに置き換えます。get_balance ツールを、RESTまたはgRPC経由で台帳システムに接続します。pay_bill を実際の決済スイッチに接続します。これを行う際、モデルや会話ロジックを変更する必要はありません。ツールハンドラーの実装を入れ替えるだけで済みます。

セッション管理のためにRedisを追加します。金融における会話の状態は機密性が高く、規制の対象となります。メッセージ履歴を安全に保存し、設定したタイムアウト後に期限切れにし、ユーザーのセッションがリクエスト間で漏洩しないようにする必要があります。Redisは、TTLポリシーと高速なキー検索によってこれを実現します。

トラフィックが増加したら、推論をvLLMに移行します。AI Studioはプロトタイピングには最適ですが、GPUクラスター上のvLLMを使用したセルフホスト型の推論により、大規模な環境でのレイテンシ、バッチ処理、コストの制御が可能になります。Gemma 4はvLLM上で効率的に動作し、ツール呼び出しの挙動は変わりません。

真の教訓

信頼できるフィンテックエージェントを構築するには、モデルのサイズよりも、アーキテクチャの制約が重要です。Gemma 4は、コードスイッチングされたナイジェリア・ピジンを解析し、複雑な意図をルーティングするのに十分な推論能力を備えていますが、安全性はツールループによってもたらされます。すべての残高はリアルタイムで取得されます。すべての請求支払いは外部システムによって確認されます。捏造されることは何もありません。

まずはブラウザ上のAI Studioから始め、Expressのループでロジックを堅牢にし、会話の流れが完璧になったら実際の銀行インフラに切り替えます。これこそが、人々が本当にお金を預けられるようなボットをリリースする方法です。

Source: Building a Full Gemma 4 Google AI Studio Project: A Fintech Support Agent

Optional learning community: GyaanSetu AI on Telegram