0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kai_kou(甲斐 甲)

Dapr Agents v1.0入門 — KubernetesネイティブなAIエージェントを本番運用する

0
Last updated at Posted at 2026-03-24

Dapr Agents v1.0 概要 — KubernetesネイティブなAIエージェントフレームワーク

はじめに

2026年3月23日、CNCF（Cloud Native Computing Foundation）がKubeCon + CloudNativeCon Europe 2026で Dapr Agents v1.0 の一般提供（GA）を発表した。Dapr Agents は、分散アプリケーションランタイム Dapr の上に構築された Python フレームワークで、AIエージェントを本番環境で耐障害性高く運用するための基盤を提供する。

LangGraph や CrewAI といったエージェントフレームワークが「LLMの推論ロジック」に注力するのに対し、Dapr Agents は「インフラ層の信頼性」に特化している。障害からの自動復旧、30以上のデータベースへの状態永続化、SPIFFE による暗号学的アイデンティティなど、本番運用に不可欠な機能をフレームワークレベルで提供する点が特徴的である。

この記事で学べること

  • Dapr Agents v1.0 のアーキテクチャとコア概念
  • ローカル環境でのセットアップ手順とサンプルエージェント実装
  • マルチエージェント協調の仕組みと実装パターン
  • 既存フレームワーク（LangGraph、CrewAI）との使い分け

対象読者

  • AIエージェントを本番環境にデプロイしたいエンジニア
  • Kubernetes 上でエージェントワークロードを運用するプラットフォームエンジニア
  • エージェントフレームワーク選定を行う技術リーダー

TL;DR

  • Dapr Agents v1.0 は CNCF プロジェクトとして初の本番対応AIエージェントフレームワーク
  • アクターモデルにより、1台のマシンで数千エージェントをミリ秒レイテンシで起動できる
  • LLMプロバイダーの切り替えはYAML変更のみ — コード変更不要
  • NVIDIA との1年間の共同開発を経てGAに到達。ZEISS Vision Care が本番導入済み

Dapr Agents アーキテクチャ — Python Agent Code / Dapr Sidecar / Infrastructure の3層構成

Dapr Agents のアーキテクチャ

Dapr とは何か

Dapr（Distributed Application Runtime）は、マイクロサービスの構築を簡素化するランタイムで、CNCF Graduated プロジェクトとして広く採用されている。状態管理、Pub/Sub メッセージング、サービス間通信などの分散システムパターンを、サイドカープロキシ経由で標準化されたAPIとして提供する。

Dapr Agents は、この Dapr のインフラ層の上に「エージェント」という抽象を追加したフレームワークである。

コア概念

Dapr Agents のアーキテクチャは、以下の4つの柱で構成される。

コア概念 役割 従来のフレームワークとの違い
Durable Agent ワークフロー支援型の耐障害エージェント実行 推論ステップごとに状態を永続化。Pod再起動後も途中から再開
Actor Model エージェントを軽量アクターとして表現 Scale-to-Zero対応。数千エージェントを低リソースで起動
Dapr Conversation API LLMプロバイダーの抽象化 YAMLコンポーネント変更だけでモデル切り替え可能
SPIFFE Identity エージェント間の暗号学的認証 各エージェントに固有の暗号IDを付与し、相互認証を実現

アクターモデルによるスケーリング

Dapr Agents の公式ドキュメントによると、エージェントとそのタスクはアクター（Actor）として表現される。アクターは「計算と状態の単一ユニットで、スレッドセーフかつネイティブに分散可能」な軽量オブジェクトである。

この設計により、以下のスケーリング特性が実現される。

  • Scale-to-Zero: アイドル状態のエージェントはメモリから解放され、リクエスト時にミリ秒で復元される
  • 高密度配置: 1台のマシンで数千のエージェントを二桁ミリ秒のレイテンシで起動可能
  • 最小リソース消費: CPU・メモリの要件が極めて低い

セットアップとサンプル実装

前提条件

インストール手順

Dapr CLI のインストールと初期化を行う。

# Dapr CLI インストール（macOS/Linux）
curl -fsSL https://raw.githubusercontent.com/dapr/cli/master/install/install.sh | /bin/bash

# Dapr ローカル環境の初期化
dapr init

# Docker コンテナの確認（dapr, zipkin, redis が起動）
docker ps

プロジェクトの作成と Dapr Agents のインストールを行う。

# プロジェクト作成
uv init my-agent-project
cd my-agent-project

# Dapr Agents インストール
uv add dapr-agents

ローカル LLM として Ollama を使用する場合、以下でモデルを準備する。

# Ollama インストール（macOS/Linux）
curl -fsSL https://ollama.com/install.sh | sh

# モデルの取得と起動
ollama pull qwen3:0.6b
ollama serve

最初のエージェント実装

天気情報を返す Durable Agent の実装例を示す。Dapr Agents の Getting Started に基づく構成である。

まず、ツール関数を定義する。

# function_tools.py
import time

def slow_weather_func(city: str) -> str:
    """指定された都市の天気を取得する（模擬的な遅延あり）"""
    time.sleep(2)  # 外部API呼び出しを模擬
    weather_data = {
        "Tokyo": "晴れ 22°C",
        "London": "曇り 15°C",
        "New York": "雨 18°C",
    }
    return weather_data.get(city, f"{city}の天気データは取得できません")

次に、Durable Agent を定義する。

# agent.py
from dapr_agents.llm import DaprChatClient
from dapr_agents import DurableAgent
from dapr_agents.agents.configs import AgentMemoryConfig, AgentStateConfig
from dapr_agents.memory import ConversationDaprStateMemory
from dapr_agents.storage.daprstores.stateservice import StateStoreService
from dapr_agents.workflow.runners import AgentRunner
from function_tools import slow_weather_func


def main() -> None:
    weather_agent = DurableAgent(
        name="WeatherAgent",
        role="Weather Assistant",
        instructions=["Help users with weather information"],
        tools=[slow_weather_func],
        llm=DaprChatClient(component_name="llm-provider"),
        memory=AgentMemoryConfig(
            store=ConversationDaprStateMemory(
                store_name="agent-memory",
            )
        ),
        state=AgentStateConfig(
            store=StateStoreService(store_name="agent-workflow"),
        ),
    )

    runner = AgentRunner()
    try:
        runner.serve(weather_agent, port=8001)
    finally:
        runner.shutdown()


if __name__ == "__main__":
    main()

Dapr コンポーネント設定

LLM プロバイダーとステートストアを YAML で定義する。resources/ ディレクトリに配置する。

LLM プロバイダー設定 (resources/llm-provider.yaml):

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: llm-provider
spec:
  type: conversation.openai
  version: v1
  metadata:
  - name: key
    value: "ollama"
  - name: model
    value: "qwen3:0.6b"
  - name: endpoint
    value: "http://localhost:11434/v1"

ステートストア設定 (resources/agent-workflow.yaml):

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: agent-workflow
spec:
  type: state.redis
  version: v1
  metadata:
  - name: redisHost
    value: localhost:6379
  - name: redisPassword
    value: ""
  - name: actorStateStore
    value: "true"

会話メモリ設定 (resources/agent-memory.yaml):

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: agent-memory
spec:
  type: state.redis
  version: v1
  metadata:
  - name: redisHost
    value: localhost:6379
  - name: redisPassword
    value: ""

実行とテスト

Dapr CLI 経由でエージェントを起動する。

uv run dapr run --app-id weather-agent \
  --resources-path resources \
  -- python agent.py

別のターミナルからタスクを送信する。

curl -i -X POST http://localhost:8001/agent/run \
  -H "Content-Type: application/json" \
  -d '{"task": "What is the weather in Tokyo?"}'

レスポンスに含まれるワークフロー ID でステータスを確認できる。

curl -i -X GET http://localhost:8001/agent/instances/{WORKFLOW_ID}

エージェント実行フロー — HTTP Request → AgentRunner → DurableAgent → Dapr Sidecar → Response

LLM プロバイダーの切り替え

Dapr Agents の大きな利点は、LLM プロバイダーをコード変更なしに切り替えられる点にある。Dapr の Conversation API がプロバイダーを抽象化しているため、YAML コンポーネントの type と metadata を変更するだけで済む。

Ollama から OpenAI に切り替える場合の設定例を示す。

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: llm-provider
spec:
  type: conversation.openai
  version: v1
  metadata:
  - name: key
    value: "sk-..."  # OpenAI API Key
  - name: model
    value: "gpt-4o"

Python コードは一切変更する必要がない。この設計により、開発環境ではローカル LLM（Ollama）、本番環境ではクラウド LLM（OpenAI / Azure OpenAI）という使い分けが容易になる。

マルチエージェント協調

Dapr Agents は、複数のエージェントが協調して動作するマルチエージェントシステムをネイティブにサポートする。協調パターンは2種類提供されている。

1. Service-to-Service Invocation（同期型）

エージェント間の直接通信パターン。Dapr のサービス間呼び出し機能により、サービスディスカバリ、エラーハンドリング、分散トレーシングが自動で組み込まれる。

リーダーエージェントがリサーチエージェントに調査を依頼し、結果を集約するようなワークフローに適している。

2. Pub/Sub メッセージング（非同期型）

共有メッセージバスを介した疎結合な協調パターン。イベント駆動型のリアルタイムインタラクションが可能で、タスクの分配やエージェント間の調整に適している。

Dapr Agents のドキュメントでは、以下のエージェントパターンがサポートされている。

パターン 説明 ユースケース
Augmented LLM 単一エージェント + ツール 基本的なタスク実行
Prompt Chaining エージェントの直列実行 段階的な処理パイプライン
Parallelization 複数エージェントの並列実行 独立タスクの同時処理
Routing タスクに応じたエージェント振り分け リクエストの分類と委譲
Orchestrator-Workers オーケストレータが複数ワーカーを統括 大規模な分割統治型ワークフロー
Evaluator-Optimizer 生成→評価のフィードバックループ 品質の反復改善

フレームワーク比較 — Dapr Agents / LangGraph / CrewAI の焦点の違い

既存フレームワークとの比較

Dapr Agents は既存のエージェントフレームワークを置き換えるものではなく、異なるレイヤーに位置する。

比較軸 Dapr Agents LangGraph CrewAI
主な焦点 インフラの信頼性 推論グラフの制御 チーム型タスク管理
耐障害性 ワークフロー組み込み（自動リトライ・復旧） アプリ層で実装が必要 アプリ層で実装が必要
状態管理 30+バックエンド（Redis, PostgreSQL, MongoDB等） メモリ or カスタム実装 メモリ or カスタム実装
スケーリング アクターモデル + Kubernetes ネイティブ 手動スケーリング 手動スケーリング
セキュリティ SPIFFE + mTLS 組み込み 外部実装が必要 外部実装が必要
LLM抽象化 Dapr Conversation API（YAML切り替え） LangChain経由 LiteLLM等
ライセンス Apache 2.0 MIT MIT
ガバナンス CNCF（ベンダー中立） LangChain Inc. CrewAI Inc.

Dapr Agents は「エージェントの推論ロジック」よりも「エージェントが本番で落ちない仕組み」を提供する。そのため、LangGraph でエージェントの推論フローを構築し、Dapr Agents でインフラ層を担保するという組み合わせも現実的な選択肢となる。

本番導入事例: ZEISS Vision Care

CNCF のプレスリリースによると、ZEISS Vision Care は Dapr Agents を使って非構造化ドキュメントから光学パラメータを抽出するシステムを本番運用している。同社はこの導入について「耐障害性があり、ベンダー中立なAIアーキテクチャで、重要なビジネスプロセスを確実に推進している」と評価している。

Kubernetes へのデプロイ

本番環境では Kubernetes クラスタにデプロイすることが推奨される。Dapr は Kubernetes にネイティブ統合されているため、以下の利点がある。

  • Pod の一時的な性質に対応: Pod が再起動・再スケジュールされても、ワークフローの状態は維持される
  • Dapr Sidecar Injector: アノテーション追加だけでサイドカーが自動注入される
  • Helm Chart: dapr init -k で Kubernetes クラスタに Dapr をインストール可能

デプロイメントの基本的な構成例を示す。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: weather-agent
spec:
  replicas: 1
  selector:
    matchLabels:
      app: weather-agent
  template:
    metadata:
      labels:
        app: weather-agent
      annotations:
        dapr.io/enabled: "true"
        dapr.io/app-id: "weather-agent"
        dapr.io/app-port: "8001"
    spec:
      containers:
      - name: agent
        image: my-registry/weather-agent:latest
        ports:
        - containerPort: 8001

dapr.io/enabled: "true" アノテーションにより、Dapr サイドカーが自動注入される。

注意点と制約

Dapr Agents v1.0 を採用する際に留意すべき点がある。

  • Python のみ: 2026年3月時点でサポートされている言語は Python のみ。Go や TypeScript のサポートはロードマップ上にない
  • Dapr の学習コスト: Dapr 自体のコンセプト（サイドカー、コンポーネント、アクター）を理解する必要がある
  • コミュニティ規模: GitHub スター数は約635（2026年3月時点）で、LangChain エコシステムと比較すると小規模
  • エージェントの推論ロジック: 複雑な推論グラフの構築機能は LangGraph ほど充実していない。Dapr Agents の強みはあくまでインフラ層

まとめ

  • Dapr Agents v1.0 は、AIエージェントを本番環境で「落ちない」状態で運用するための CNCF 公式フレームワーク
  • アクターモデルによる高密度スケーリング、30以上のステートストア対応、SPIFFE 暗号認証がインフラ層として組み込まれている
  • LLM プロバイダーは YAML 変更のみで切り替え可能 — ベンダーロックインを回避できる
  • 「推論ロジックは LangGraph、インフラは Dapr Agents」という組み合わせが、本番エージェントシステムの有力な選択肢となる

参考リンク

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?