AZURE Kubernetes Service (AKS) 上の AI ツールチェーンオペレーターアドオンと LLM 推論を使用してツール呼び出しを統合する

この記事では、OpenAI スタイルのツール呼び出しをサポートする AI ツールチェーン演算子 (KAITO) 推論ワークスペースを Azure Kubernetes Service (AKS) に構成してデプロイします。また、vLLM メトリックとローカル関数モックを使用してツール呼び出し機能を検証する方法についても説明します。

ツールの呼び出しとは

ツール呼び出しにより、大規模な言語モデル (LLM) が外部関数、API、またはサービスとインターフェイスできるようになります。 LLM では、単にテキストを生成するのではなく、次の決定を行うことができます。

"天気 API を呼び出す必要があります。"
「電卓を使う必要がある」
"データベースを検索する必要があります。"

これは、ユーザーの要求に基づいて選択したパラメーターを使用して定義された "ツール" を呼び出すことによって行われます。ツールの呼び出しは、次の場合に役立ちます。

予約、集計、または計算を行うチャットボット。
幻覚を最小限に抑える必要があるエンタープライズ LLM アプリケーション。
エージェントフレームワーク (AutoGen、LangGraph、LangChain、AgentOps など)。

運用環境では、AI 対応アプリケーションでは、多くの場合、自然言語の生成以上のものが必要です。ユーザーの意図に基づいてアクションを実行する機能が必要です。ツール呼び出しは、外部ツール、API、またはカスタムロジックをリアルタイムで呼び出すことによって、LLM がテキスト応答を超えて拡張できるようにします。これにより、言語の理解と実行のギャップが埋め込まれるので、開発者は正確で便利な対話型の AI アシスタント、エージェント、自動化ワークフローを構築できます。 LLM は、静的な応答に依存する代わりに、ライブデータにアクセスし、サービスをトリガーし、ユーザーに代わって安全かつ確実にタスクを完了できるようになりました。

AKS にデプロイすると、ツール呼び出しはスケーラブルでセキュリティで保護され、運用の準備が整います。 Kubernetes は、vLLM などの高パフォーマンスランタイムを使用して推論ワークロードを柔軟に調整できる一方で、ツールの使用の可観測性とガバナンスを確保します。このパターンにより、AKS オペレーターとアプリ開発者は、モデルまたはツールをよりシームレスに個別に更新し、信頼性を損なうことなく高度な AI 機能をデプロイできます。

その結果、AKS を呼び出すツールは、コンテキスト対応、アクション対応、エンタープライズ対応の最新の AI アプリを構築するための基本パターンになりました。

KAITO を使用したツール呼び出し

このデプロイモデルを合理化するために、AKS の AI ツールチェーンオペレーター (KAITO) アドオンは、ツール呼び出しサポートを使用して推論サービスを実行するためのマネージドソリューションを提供します。 KAITO 推論ワークスペースを利用することで、ツール呼び出しと OpenAI 互換 API の組み込みサポートを使用して、スケーラブルな GPU アクセラレーションモデルエンドポイントをすばやく起動できます。これにより、ランタイムの構成、依存関係の管理、またはインフラストラクチャの手動スケーリングの運用オーバーヘッドがなくなります。

[前提条件]

この記事では、既存の AKS クラスターがすでにあることを前提としています。クラスターがない場合は、 Azure CLI、 Azure PowerShell、または Azure portal を使用してクラスターを作成します。
AKS クラスターは、Kubernetes バージョン 1.33 以降で実行されています。クラスターをアップグレードするには、「 AKS クラスターのアップグレード」を参照してください。
Azure CLI バージョン 2.77.0 以降をインストールして構成します。バージョンを確認するには、az --version を実行します。インストールまたは更新するには、「 Azure CLI のインストール」を参照してください。
AIツールチェーンオペレーターアドオンがクラスターで有効になっています。
ツール呼び出しをサポートする、デプロイされた KAITO 推論ワークスペース。サポートされているモデルを vLLM で呼び出すツールについては、公式の KAITO ツール呼び出しに関するドキュメントを参照してください。
既定の構成で workspace‑phi‑4-mini-toolcallKAITO ワークスペースをデプロイしました。

KAITO 推論ワークスペースが実行されていることを確認する

kubectl get コマンドを使用してワークスペースのデプロイを監視します。
```
kubectl get workspace workspace‑phi‑4‑mini-toolcall -w
```
出力で、リソース (ResourceReady) と推論 (InferenceReady) の準備が完了し、ワークスペースが成功したことを確認します (WorkspaceSucceededtrue)。

推論 API を提供する準備ができているかどうかを確認する

ワークスペースの準備ができたら、 kubectl get コマンドを使用してサービスエンドポイントを見つけます。
```
kubectl get svc workspace‑phi‑4-mini-toolcall
```
注

出力は、 ClusterIP または内部アドレスである可能性があります。サービスがリッスンしているポートを確認します。既定の KAITO 推論 API は、HTTP のポート 80 にあります。内部のみである場合は、ローカルでポート転送できます。
kubectl port-forward コマンドを使用して、推論サービスをポートフォワードしてテストします。
```
kubectl port-forward svc/workspace‑phi‑4‑mini-toolcall 8000:80
```
/v1/modelsを使用して LLM が使用可能であることを確認するには、curl エンドポイントを確認します。
```
curl http://localhost:8000/v1/models
```
LLM がデプロイされ、API が動作していることを確認するには、出力は次のようになります。
```
...
{
  "object": "list",
  "data": [
    {
      "id": "phi‑4‑mini‑instruct",
      ...
      ...
    }
  ]
}
...
```

名前付き関数ツールの呼び出しをテストする

この例では、 workspace‑phi‑4‑mini-toolcall ワークスペースでは既定で名前付き関数ツール呼び出しがサポートされているため、LLM が OpenAI スタイルの要求で "ツール" 仕様を受け入れ、"関数呼び出し" 構造体を返すことがわかります。

このセクションで使用する Python スニペットは KAITO ドキュメントのものであり、OpenAI と互換性のあるクライアントを使用します。

LLM が OpenAI スタイルの要求で "ツール" 仕様を受け入れ、"関数呼び出し" 構造体を返すのを確認します。この例では次のとおりです。
- ローカル推論サーバーと通信するように OpenAI 互換クライアントを初期化します。サーバーは、 http://localhost:8000/v1 で実行されていると見なされ、OpenAI スタイルの API 呼び出しを受け入れます。
- get_weatherと呼ばれるツールのバックエンドロジックをシミュレートします。 (実際のシナリオでは、これは天気 API を呼び出します)。
- ツールインターフェイスについて説明します。 Phi-4-mini LLM には、このツールが表示され、ユーザーの入力に基づいて使用するかどうかを決定します。
- サンプルチャットメッセージをモデルに送信し、ツールスペックを提供します。 tool_choice="auto" 設定により、LLM はプロンプトに基づいてツールを呼び出す必要があるかどうかを判断できます。
- この場合、ユーザーの要求は get_weather ツールに関連していたため、ツールの実行をシミュレートし、モデルの選択した引数を使用してローカル関数を呼び出します。
```
from openai import OpenAI
import json

# local server
client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")

def get_weather(location: str, unit: str) -> str:
    return f"Getting the weather for {location} in {unit}..."

tool_functions = {"get_weather": get_weather}

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Get the current weather in a given location",
        "parameters": {
            "type": "object",
            "properties": {
                "location": {"type": "string"},
                "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
            },
            "required": ["location", "unit"]
        }
    }
}]

response = client.chat.completions.create(
    model="phi‑4‑mini‑instruct",   # or client.models.list().data[0].id
    messages=[{"role": "user", "content": "What's the weather like in San Francisco?"}],
    tools=tools,
    tool_choice="auto"
)

# Inspect response
tool_call = response.choices[0].message.tool_calls[0].function
args = json.loads(tool_call.arguments)
print("Function called:", tool_call.name)
print("Arguments:", args)
print("Result:", tool_functions[tool_call.name](**args))
```
出力は次のようになります。
```
Function called: get_weather  
Arguments: {"location": "San Francisco, CA", "unit": "fahrenheit"}  
Result: Getting the weather for San Francisco, CA in fahrenheit...
```
"tool_calls" フィールドが返されます。つまり、 Phi-4-mini LLM が関数を呼び出すことにしました。これで、KAITO 推論デプロイでエンドツーエンドのツール呼び出し動作を確認するモデルの決定に基づいて、サンプルツール呼び出しが正常に解析および実行されました。

トラブルシューティング

モデルプリセットでは、ツールの呼び出しがサポートされていません

サポートされている一覧にないモデルを選択した場合、ツールの呼び出しが機能しない可能性があります。ツール呼び出しをサポートするプリセットが明示的に一覧表示されている KAITO ドキュメントを確認してください。

ランタイムの位置がずれている

KAITO 推論では、ツール呼び出しに vLLM ランタイムを使用する必要があります (HuggingFace Transformers ランタイムでは、通常、KAITO でのツール呼び出しはサポートされていません)。

ネットワーク/エンドポイントの問題

ポートフォワーディングの場合は、サービスポートが正しく転送されていることを確認します。外部 MCP サーバーに到達できない場合は、エラーが発生します。

Timeouts

外部 MCP サーバーの呼び出しには時間がかかる場合があります。アダプターまたはクライアントのタイムアウトが十分に高く設定されていることを確認してください。

Authentication

外部 MCP サーバーで認証 (API キー、ヘッダーなど) が必要な場合は、正しい資格情報を指定してください。

次のステップ

AKS 上の Prometheus と Grafana を使用して、AI ツールチェーンオペレーターアドオンで vLLM 監視を設定します。
KAITO での MCP サーバーのサポートについて説明し、AKS クラスターで標準化されたツール呼び出し例をテストします。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-10-30