AIエージェントを構築する組織は共通の課題に直面しています。ルーチンのステータスチェックであれ複雑な分析であれ、すべてのリクエストが通常、単一の大型で高価なモデルにルーティングされるのです。この画一的なアプローチは、APIコストを押し上げ、予測不能なレイテンシをもたらし、オフラインでの運用の可能性を失わせます。ローカルで解決できるはずのルーチンなクエリでさえ、クラウドホスト型の大規模言語モデル(LLM)への完全なネットワーク往復を必要とすることになってしまいます。
Strands Agentsを使用して構築されたAdaptive Agentic Intelligence Framework(AAIF)は、異なるアプローチを採用しています。すべてのリクエストを単一の大規模モデルにルーティングする代わりに、AAIFは小規模言語モデル(SLM)を使用して定型的なタスクをローカルで処理します。より複雑なリクエストは、クラウドホスト型モデルに経由してルーティングされます。 Amazon Bedrock。このアプローチは、以下の研究上の立場に基づいている。 NVIDIAのBelcakら。彼らは、小規模言語モデルは「エージェントシステムにおける多くの呼び出しに対して十分に強力であり、本質的により適しており、必然的により経済的である」と主張しています。Strands Agentsを基盤とするこのフレームワークは、インテリジェントなモデルオーケストレーションにより、ローカル操作の低レイテンシーを維持しながらコストを削減できることを実証しています。
この記事では、Ollama経由のローカルSLMとAmazon Bedrock経由のクラウドモデルを組み合わせてStrands Agentsを使用するAAIFの主要コンポーネントについて解説します。IoT(Internet of Things)監視シナリオをリファレンス実装として使用します。
ソリューション概要
AAIFはAI処理を3つのレイヤーに整理しており、それぞれが異なるタスクタイプに最適化されています(図1を参照):
- スマートオーケストレーションは、軽量なSLM(llama3.2:1b)を意思決定レイヤーとして使用します。このオーケストレーターは、入力されたリクエストを分類し、ハードコードされたルールに頼らずに適切な処理レイヤーへルーティングします。
- ローカル処理は、デバイステレメトリの取得や画像分析などの定型的なタスクを、ローカルハードウェア上で動作するSLMによって処理します。これは Ollamaを通じて実行されます。これらのタスクは低レイテンシーで、クラウドに依存せずに完了します。
- クラウド処理は、複雑なパターン分析と戦略的な推奨事項を、Amazon Bedrockのフロンティアモデルを通じて処理します。これらのリクエストには、SLMでは確実に提供できない、より広範なコンテキストと複数ステップの推論が必要です。
図1:スマートオーケストレーション、ローカル処理、クラウド処理という3つのAAIF処理レイヤー
図1は、AAIFシステムの完全なアーキテクチャを示しています。中央にはStrandsエージェントがあり、1Bパラメータのオーケストレーターモデルとビジョンモデルの両方をホストするOllamaランタイムに接続しています。このエージェントは3つのツールを公開しています。ローカルのセンサーデータを取得するget_device_telemetry、llama3.2-visionによるデバイス上での画像処理を行うanalyze_camera_feed、そしてboto3を通じてAmazon Bedrockを呼び出して複雑な分析を行うget_expert_insightsです。ユーザーからのリクエストはSLMオーケストレーターを流れ、各リクエストを分類し、タスクの複雑さに応じてローカルツールかクラウドエンドポイントのいずれかにディスパッチします。
図2:Strandsエージェント、Ollamaランタイム、ツール統合、およびAmazon Bedrock接続を示すAAIFシステムの完全なアーキテクチャ
このフレームワークは、インフラストラクチャをフレームワークに合わせて再構築することを求めるのではなく、デプロイの制約に適応します。このアーキテクチャは、8 GBのメモリを備えたRaspberry Piのようなエッジデバイス上、すべての推論がAmazon Bedrockに送られる完全なクラウドデプロイ、あるいはローカルの高速性とクラウドの推論能力を組み合わせたハイブリッド構成で実行できます。この柔軟性は、ルーティングロジック(SLMオーケストレーター)を処理ツールから分離することで実現されており、利用可能なハードウェアやネットワーク接続性に応じて、処理ツールを独立して入れ替えたり再構成したりできます。
前提条件
このチュートリアルを実行するには、以下の前提条件を満たしている必要があります:
- AWSアカウント が必要です。.
- 必要なリージョンでAmazon Bedrock のモデルアクセスが設定されている必要があります。
- Python 3.10+ がインストールされている必要があります。
- Ollama がインストールされ、以下のモデルがプルされている必要があります:
ollama pull llama3.2:1b(オーケストレーター)。ollama pull llama3.2-vision(画像解析)。
- Strands Agents がインストール済みであること:
pip install strands-agents strands-agents-tools. - AWS Command Line Interface (AWS CLI) が適切な認証情報で設定済みであること。
- Boto3 がインストール済みであること:
pip install boto3.
環境をセットアップする
プロジェクトディレクトリを作成し、Ollamaサーバーを起動します:
mkdir aaif-demo && cd aaif-demo
ollama serve必要なモデルをプルします:
ollama pull llama3.2:1b
ollama pull llama3.2-visionという名前のファイルを作成し、 aaif_agent.py 以下のコンポーネントを追加します。
ローカル処理ツールを実装する
Strands Agentsは、エージェントが呼び出せる機能を定義するために @tool デコレータを使用します。まず、ローカル処理用のツールを作成します。
最初のツールはデバイステレメトリデータを取得します。本番環境では、これは実際のIoTセンサーに接続します。このウォークスルーでは、シミュレートされたデバイスデータを使用します:
from strands import Agent, tool
import random
DEVICE_TELEMETRY = {
"sensor-001": {
"device_type": "Temperature Sensor",
"location": "Building A - Floor 2",
"temperature": 72.5,
"humidity": 45.2,
"status": "normal"
},
"camera-001": {
"device_type": "Security Camera",
"location": "Main Entrance",
"fps": 30,
"resolution": "1080p",
"status": "recording"
},
"hvac-001": {
"device_type": "HVAC Controller",
"location": "Building A - Central",
"set_temp": 71.0,
"current_temp": 72.5,
"mode": "cooling",
"status": "active"
}
}
@tool
def get_device_telemetry() -> str:
"""Retrieve current telemetry data from connected IoT devices."""
device_id = random.choice(list(DEVICE_TELEMETRY.keys()))
device_data = DEVICE_TELEMETRY[device_id]
report = f"Device: {device_id} ({device_data['device_type']})\n"
report += f"Location: {device_data['location']}\n"
report += f"Status: {device_data['status']}\n"
for key, value in device_data.items():
if key not in ['device_type', 'location', 'status']:
report += f"{key}: {value}\n"
return report2番目のツールは、ローカルのSLMを使用した画像解析を実行します。llama3.2-visionモデルは完全にローカルのハードウェア上で動作するため、機密性の高いカメラ映像がデバイスの外に出ることはありません:
import ollama
@tool
def analyze_camera_feed(image_path: str) -> str:
"""Analyze visual data from cameras using local vision model."""
stream = ollama.chat(
model='llama3.2-vision',
messages=[{
'role': 'user',
'content': 'Describe this image in one sentence. '
'What are the 3 most important things you see?',
'images': [image_path]
}],
stream=True,
)
full_response = ""
for chunk in stream:
chunk_content = chunk['message']['content']
print(chunk_content, end='', flush=True)
full_response += chunk_content
return f"Object Detection Report:\n{full_response}"クラウド処理の実装
より広範な推論を必要とする複雑な解析のために、Amazon Bedrockを呼び出すツールを作成します。このツールは、オーケストレーターがローカルモデルではリクエストを処理できないと判断した場合にのみ呼び出されます:
import boto3
@tool
def get_expert_insights(context_data: str, question: str) -> str:
"""Get advanced analysis and expert recommendations
for complex questions via Amazon Bedrock."""
client = boto3.client("bedrock-runtime", region_name="us-east-1")
conversation = [
{
"role": "user",
"content": [
{"text": f"Context: {context_data}\n\nQuestion: {question}"}
],
}
]
response = client.converse(
modelId="<<model_id>", //Refer model id [details](https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)
messages=conversation,
inferenceConfig={
"maxTokens": 512,
"temperature": 0.5,
"topP": 0.9
}
)
response_text = response["output"]["message"]["content"][0]["text"]
return f"Expert Analysis:\n{response_text}"スマートオーケストレーションによるStrandsエージェントの設定
AAIFの中核はStrandsエージェントの設定です。エージェントは、ローカルのSLM(llama3.2:1b)をオーケストレーターとして使用します。Strands Agentsは複数のモデルプロバイダーに対応しており、ここではOllamaプロバイダーを使用してオーケストレーターをローカルで実行します:
from strands.models.ollama import OllamaModel
model = OllamaModel(
model_id="llama3.2:1b",
host="http://localhost:11434",
params={
"max_tokens": 300,
"temperature": 0.3,
},
)
system_prompt = """You are a monitoring assistant for operational facilities.
You have access to device telemetry tools, analysis capabilities,
and expert insights to help monitor operations effectively.
When users ask for:
- Device status or telemetry: use get_device_telemetry
- Image or data analysis: use analyze_camera_feed
- Expert advice or complex questions: use get_expert_insights
Always return the complete tool results directly to the user."""
agent = Agent(
model=model,
system_prompt=system_prompt,
tools=[
get_device_telemetry,
analyze_camera_feed,
get_expert_insights,
],
)SLMを利用したオーケストレーターは各リクエストを分析し、ハードコードされたキーワードマッチングによらず、適切なツールにルーティングします。ルーティングは、モデルによるリクエストの理解を通じて行われます:
| リクエスト | ルーティング | レイテンシー |
| 「Check device status(デバイスの状態を確認)」 | ローカルSLM | 低(ローカル推論) |
| 「Analyze this image(この画像を解析)」 | ローカルのビジョンAI | 低(ローカル推論) |
| 「What optimization strategies do you recommend?(どのような最適化戦略をお勧めしますか?)」 | クラウド(Amazon Bedrock) | 高め(ネットワーク往復) |
表1:ローカル推論とクラウド推論の比較におけるリクエスト、ルーティング、およびレイテンシーの見積もり
エージェントの実行
エージェントを設定したら、直接対話できます:
# Local processing - device telemetry
response = agent("What's the current status of our devices?")
print(response)
# Local processing - vision analysis
response = agent("Analyze the camera feed from camera-001")
print(response)
# Cloud processing - complex analysis
response = agent(
"Based on current telemetry patterns, "
"what optimization strategies do you recommend?"
)
print(response)エージェントは各リクエストを自動的に分類し、適切な処理レイヤーにルーティングします。明示的なルーティングルールは必要ありません。
さまざまなデプロイシナリオへの適応
AAIFアーキテクチャは、モデル設定を変更することで、さまざまなインフラストラクチャ要件に適応します:
ワークロードが完全にクラウドで実行され、エッジハードウェアが利用できない場合は、Ollamaのモデル設定をAmazon Bedrockに置き換えてすべての処理を行います。これにより、すべてのリクエストがマネージド型のクラウド推論を経由するようになり、ローカルのGPUリソースを必要とせずに自動スケーリングが得られます。信頼性の高い低レイテンシー接続があり、データレジデンシーの制約がないチームは、この設定から最も恩恵を受けます:
from strands.models import BedrockModel
model = BedrockModel(
model_id="<<model_id>", //Refer model id [details](https://docs.aws.amazon.com/bedrock/latest/userguide/foundation-models-reference.html)
region_name="us-east-1"
)ハイブリッド設定では、ローカルのSLMオーケストレーターをそのまま維持しつつ、ローカルモデルの能力を超えるリクエストのためにクラウドモデルを追加します。これはこのウォークスルーで示したデフォルトのAAIF設定です。ほとんどのリクエストがローカルで解決できる程度に日常的なものですが、一部にはより大きなモデルによる広範な推論を必要とするものがある環境に適しています。コスト削減は、有料のAPIエンドポイントにヒットしないトラフィックの約80パーセントから得られます。
完全にエアギャップ化された環境や厳格なデータ主権要件がある環境では、クラウドツールをより大きなローカルモデルに置き換え、すべての処理をデバイス上で実行します。十分なメモリを備えたハードウェア上で動作する3Bパラメータモデルは、1Bのオーケストレーターが本来エスカレーションするであろう中程度に複雑なタスクを処理できます。トレードオフは、最も難しいクエリに対する推論の深さが低下することですが、メリットはデータが施設外に出ないことです:
model = OllamaModel(
model_id="llama3.2:3b", # Larger local model for complex tasks
host="http://localhost:11434",
)今後の展望:MCPサーバーによる一元化されたツール呼び出し
この記事の実装では、エージェントコード内で直接定義されたローカルツール呼び出しを使用します。複数のエージェントがサービス間でツールを共有する本番環境のデプロイでは、これらのツールをModel Context Protocol(MCP)サーバーとして公開してください。MCPは、ツールの検出と呼び出しのための標準化されたインターフェイスを提供するため、ツール管理を一元化し、さまざまなエージェントや環境間でツールを再利用できます。図3では、AAIFツールを分散型の一元的なツール呼び出しのためのMCPサーバーに変換する方法を示します。
図3に示す分散構成では、Device 1がオーケストレーションのハブとして機能し、SLMルーターとローカルのテレメトリツールを備えたStrandsエージェントを実行します。Device 1はMCPプロトコルを通じて、llama3.2-visionを備えたエッジビジョン処理サーバーを実行するDevice 2に接続します。Device 3は、Amazon Bedrockに接続されたクラウド分析ゲートウェイとして機能します。オーケストレーターの観点からは、MCPトランスポート層がシリアル化とネットワーク通信を透過的に処理するため、すべてのリモートツールはローカルの関数呼び出しのように見えます。
図3:MCPサーバーによる分散型インテリジェンス
クリーンアップ
将来の課金を避けるために、以下のクリーンアップ手順を完了してください:
- Amazon Bedrockのモデルアクセスを無効にする:Amazon Bedrockコンソールを開き、次を選択します モデルアクセス、Amazon Nova Liteのアクセスを取り消します。詳細な手順については、 モデルへのアクセスを管理する 「Amazon Bedrock ユーザーガイド」に記載されています。
- Ollamaサーバーを停止し、ローカルのディスク容量（約2 GB）を空けるためにモデルを削除します：
ollama stop ollama rm llama3.2:1b ollama rm llama3.2-vision - サンプルコードが不要になった場合は、プロジェクトディレクトリを削除してください:
rm -rf aaif-demo
結論
Adaptive Agentic Intelligence Framework と Strands Agents を使用して、コスト効率の高い AI エージェントを構築する方法を紹介しました。定型リクエストをローカルの SLM にルーティングし、複雑な分析には Amazon Bedrock 上のクラウドモデルを温存することで、AAIF は定型処理の低レイテンシーを維持しながら API コストの削減に役立ちます。
本番環境でこのパターンを実行する前に、クラウド推論パスに責任あるAI (responsible AI) の制御を追加してください。これらのリクエストにはツールの出力、取得したデータ、ユーザー入力が含まれるためです。以下をアタッチできます: Amazon Bedrock Guardrails Strands BedrockModelにガードレールIDとバージョンを渡します。そして、有害カテゴリに対するコンテンツフィルター、プロンプトインジェクションフィルター、およびソースデータで裏付けられない応答をブロックする文脈に基づくグラウンディングチェックを適用します。ローカルのSLMティアに同じポリシーを適用するには、その入出力に対してスタンドアロンのApplyGuardrail APIを呼び出します。こうすることで、どのモデルが処理するかに関係なく、すべてのリクエストが単一の安全基準に従うことになります。
このアーキテクチャパターンはIoT監視の枠を超えて応用できます。医療機関は患者モニタリングをローカルで実行し、診断支援をクラウドモデルにルーティングできます。金融サービス企業はトランザクションをオンプレミスで処理し、リスク分析のためにクラウドのキャパシティを確保できます。製造業のチームは品質管理のビジョンモデルをエッジで実行し、最適化のリクエストをクラウドへ送信できます。
Strands Agents を使用したエージェントの構築について詳しく知るには、以下をご覧ください。 Strands Agents ドキュメント。利用可能な基盤モデルについては、次を参照してください: Amazon Bedrock.