VeriCerts Tech BlogPublicationへの投稿
🤖

GoのAIフレームワーク「Eino」を徹底解説！LangChainGoとの実測比較も

ousiass
に公開
AI
Go
Go
llm
eino
tech

「GoでAIアプリを作りたいけど、PythonのLangChainみたいに便利なフレームワークはないの？」

そう感じたことがある人は多いんじゃないでしょうか。GoはWebサーバーやCLIツールでは定番の言語ですが、AIアプリ開発の文脈ではどうしてもPythonに比べてエコシステムが貧弱に見えがちです。

でも最近、そんな状況を変えるかもしれないフレームワークが登場しました。ByteDance（TikTokの親会社）のオープンソースプロジェクトである CloudWeGo から、Go製AIフレームワーク 「Eino（アイノ）」 が公開されています。

この記事では、Einoの概要から実際の使い方、設定項目の詳細、そしてUbuntu環境で実際に計測した他パッケージとの比較ベンチマーク結果まで、日本語でたっぷり解説します。

Einoとは？

Einoは、Go言語ベースのLLMアプリケーション開発フレームワークです。公式ドキュメントでは次のように説明されています。

Eino['aino] (pronunciation similar to: i know, hoping the framework can achieve the vision of "i know") aims to provide the ultimate LLM application development framework based on the Go language. It draws inspiration from many excellent LLM application development frameworks in the open-source community, such as LangChain and LlamaIndex, while also incorporating cutting-edge research results and practical applications, providing an LLM application development framework that emphasizes simplicity, extensibility, reliability, and effectiveness, and is more in line with Go programming conventions.

— Eino: Overview | CloudWeGo

要するに、LangChainやLlamaIndexからインスピレーションを得つつ、Goのプログラミング規約に沿ったシンプルで拡張性の高いフレームワークです。ByteDanceが社内で実際にLLMアプリを開発してきた知見をもとに作られており、実用性を重視した設計になっています。

GitHubの現状（2026年4月時点）

項目 値
スター数 10.5k
フォーク数 823
コントリビューター 33
コミット数 331
リリース数 166（最新: v0.8.7）
ライセンス Apache-2.0
最終コミット 数時間前（非常に活発）

コミット頻度が非常に高く、活発に開発が続いていることがわかります。

Einoが提供する価値

公式ドキュメントによると、Einoは以下の価値を提供します。

  1. コンポーネント抽象化: LLMアプリ構築に必要な部品（ChatModel、Embedding、Retriever等）の抽象化と実装
  2. ADK（Agent Development Kit）: AIエージェント構築のための高レベル抽象化。マルチエージェントオーケストレーション、Human-in-the-Loopインタラプト機構、事前構築済みエージェントパターンをサポート
  3. 強力なオーケストレーションフレームワーク: 型チェック、ストリーム処理、並行管理、アスペクト注入、オプション割り当てを自動処理
  4. シンプルで明確なAPI設計
  5. ベストプラクティスのコレクション: 統合フローとサンプルの形で提供
  6. DevOpsツール: ビジュアル開発・デバッグからオンライントレース・評価まで

Einoの構成リポジトリ

Einoはいくつかのリポジトリで構成されています。

リポジトリ 役割
eino コアライブラリ。型定義、ストリーミング機構、コンポーネント抽象化、オーケストレーション、ADK
eino-ext コンポーネント実装。OpenAI、Claude、Gemini、Ollama等の具体的な実装。DevOpsツール（eino-ext/devops）も含む
eino-examples サンプルアプリケーションとベストプラクティス

Eino Dev（開発支援プラグイン）について

「Eino Devops」という独立したリポジトリは存在せず、DevOpsツールは eino-ext リポジトリの devops/ ディレクトリ（eino-ext/devops）に含まれています。

Eino Devは GoLand / VS Code プラグインとして提供されており、以下の機能を持ちます。

機能 説明
Graph Orchestration GUIでグラフをドラッグ&ドロップで組み立て、コードを自動生成
Graph Debugging 実行中のグラフをビジュアルにデバッグ

コアコンセプト

Einoのアーキテクチャは大きく3つの柱で構成されています。

1. コンポーネント（Components）

コンポーネントはLLMアプリに必要な「部品」の抽象化です。

"In LLM applications, Components provide atomic capabilities such as: ChatModel (chat-oriented LLM interaction), Embedding (semantic vectorization for text), Retriever (retrieving relevant content), ToolsNode (invoking external tools)."

— Eino: Chain & Graph & Workflow Orchestration | CloudWeGo

主なコンポーネントは以下の通りです。

コンポーネント 役割
ChatModel LLMとのチャット指向インタラクション
Embedding テキストのセマンティックベクトル化
Retriever 関連コンテンツの取得（RAG等）
ToolsNode 外部ツールの呼び出し
Document Loader ドキュメントの読み込み
Indexer ベクトルストアへのインデックス登録

各コンポーネントの具体的な実装は eino-ext リポジトリで提供されており、現在対応しているChatModelプロバイダーは以下の通りです。

プロバイダー インポートパス
OpenAI github.com/cloudwego/eino-ext/components/model/openai
Claude (Anthropic) github.com/cloudwego/eino-ext/components/model/claude
Gemini (Google) github.com/cloudwego/eino-ext/components/model/gemini
ARK (ByteDance) github.com/cloudwego/eino-ext/components/model/ark
Ollama github.com/cloudwego/eino-ext/components/model/ollama
DeepSeek github.com/cloudwego/eino-ext/components/model/deepseek
Qianfan (Baidu) github.com/cloudwego/eino-ext/components/model/qianfan
Qwen (Alibaba) github.com/cloudwego/eino-ext/components/model/qwen
OpenRouter github.com/cloudwego/eino-ext/components/model/openrouter

2. オーケストレーション（Orchestration）

オーケストレーションはコンポーネントを繋ぎ合わせる仕組みです。Einoはオーケストレーションについて明確な哲学を持っています。

"Orchestration should be a clear layer above business logic — do not blend business logic into orchestration. LLM applications center on composing components; components are first-class citizens of orchestration."

— Eino: Chain & Graph & Workflow Orchestration | CloudWeGo

Einoは3種類のオーケストレーション方式を提供しています。

方式 特徴 用途
Chain シンプルな連鎖型有向グラフ、前進のみ 単純なパイプライン処理
Graph 有向循環または非循環グラフ。分岐・並列・ループが可能 複雑なワークフロー
Workflow フィールドレベルのデータマッピングを持つDAG データ変換を伴う高度なフロー

3. ADK（Agent Development Kit）

ADKはエージェント開発のための高レベルなキットです。

"Eino ADK is a Go-first Agent and Multi-Agent development kit. It provides: Unified Agent abstractions with event-driven outputs, Collaboration primitives (Sequential, Parallel, Loop, Supervisor, Plan-Execute), Runner-based execution with callbacks, interrupts, and checkpoints, Tooling to integrate with Eino components and Graph/Chain orchestration."

— Eino: ADK - Agent Development Kit | CloudWeGo

ADKで利用できるエージェント実装には以下のものがあります。

エージェント 説明
ChatModelAgent ツール呼び出し付きのReActスタイルエージェント
Plan-Execute 計画立案と実行を分離したエージェント
Supervisor 複数のサブエージェントを管理するスーパーバイザー
DeepAgents 深い思考を行う高度なエージェント
Workflow ワークフローベースのエージェント

インストールと基本コマンド

インストール

# コアライブラリ
go get github.com/cloudwego/eino@latest

# OpenAIプロバイダー（必要に応じて）
go get github.com/cloudwego/eino-ext/components/model/openai@latest

# Claudeプロバイダー
go get github.com/cloudwego/eino-ext/components/model/claude@latest

# Geminiプロバイダー
go get github.com/cloudwego/eino-ext/components/model/gemini@latest

# Ollamaプロバイダー（ローカルLLM）
go get github.com/cloudwego/eino-ext/components/model/ollama@latest

# ADK（エージェント開発キット）
# ADKはeinoのコアパッケージに含まれています
go get github.com/cloudwego/eino@latest

最もシンプルな使い方（直接呼び出し）

公式ドキュメントのQuick Startより、最もシンプルなChatModelの使い方です。

// 直接コンポーネントを使う場合
model, _ := openai.NewChatModel(ctx, config)
message, _ := model.Generate(ctx, []*schema.Message{
    schema.SystemMessage("you are a helpful assistant."),
    schema.UserMessage("what does the future AI App look like?"),
})

ただし、公式ドキュメントでは「オーケストレーションを使うことで、より多くのことが実現できる」と述べています。その理由は3つあります。

  1. オーケストレーションはLLMアプリの一般的なパターンをカプセル化する
  2. LLMのストリーミングレスポンスの処理という課題を解決する
  3. 型安全性、並行管理、アスペクト注入、オプション割り当てを自動処理する

Chainを使ったオーケストレーション

package main

import (
    "context"
    "fmt"
    "log"
    "os"

    "github.com/cloudwego/eino-ext/components/model/openai"
    "github.com/cloudwego/eino/compose"
    "github.com/cloudwego/eino/schema"
)

func main() {
    ctx := context.Background()

    chatModel, err := openai.NewChatModel(ctx, &openai.ChatModelConfig{
        APIKey: os.Getenv("OPENAI_API_KEY"),
        Model:  "gpt-4o",
    })
    if err != nil {
        log.Fatal(err)
    }

    // Chainの構築（逐次処理）
    chain, err := compose.NewChain[[]*schema.Message, *schema.Message]().
        AppendChatModel(chatModel).
        Compile(ctx)
    if err != nil {
        log.Fatal(err)
    }

    // 実行
    result, err := chain.Invoke(ctx, []*schema.Message{
        schema.UserMessage("Goの良いところを3つ教えて"),
    })
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(result.Content)
}

Graphを使った複雑なワークフロー

// Graphの構築例（公式ドキュメントより）
graph := compose.NewGraph[map[string]any, *schema.Message]()

// ノードの追加
_ = graph.AddChatTemplateNode("node_template", chatTpl)
_ = graph.AddChatModelNode("node_model", chatModel)
_ = graph.AddToolsNode("node_tools", toolsNode)
_ = graph.AddLambdaNode("node_converter", takeOne)

// エッジの定義（データフロー）
_ = graph.AddEdge(compose.START, "node_template")
_ = graph.AddEdge("node_template", "node_model")
_ = graph.AddBranch("node_model", branch)  // 条件分岐
_ = graph.AddEdge("node_tools", "node_converter")
_ = graph.AddEdge("node_converter", compose.END)

// コンパイル
compiledGraph, err := graph.Compile(ctx)
if err != nil {
    return err
}

// 実行
out, err := compiledGraph.Invoke(ctx, map[string]any{
    "query": "今週末の東京の天気は？",
})

Workflowを使ったフィールドレベルマッピング

Workflowは、ノード間でフィールドレベルのデータマッピングができる高度なオーケストレーションです。

// Workflowの構築例（公式ドキュメントより）
wf := compose.NewWorkflow[[]*schema.Message, *schema.Message]()

wf.AddChatModelNode("model", m).AddInput(compose.START)

wf.AddLambdaNode("lambda1", compose.InvokableLambda(lambda1)).
    AddInput("model", compose.MapFields("Content", "Input"))  // modelのContentをlambda1のInputにマッピング

wf.AddLambdaNode("lambda2", compose.InvokableLambda(lambda2)).
    AddInput("model", compose.MapFields("Role", "Role"))

wf.AddLambdaNode("lambda3", compose.InvokableLambda(lambda3)).
    AddInput("lambda1", compose.MapFields("Output", "Query")).
    AddInput("lambda2", compose.MapFields("Output", "MetaData"))

wf.End().AddInput("lambda3")

runnable, err := wf.Compile(ctx)

ChatModelAgentを使ったReActエージェント

package main

import (
    "context"
    "fmt"
    "log"
    "os"

    "github.com/cloudwego/eino/adk"
    "github.com/cloudwego/eino/compose"
    "github.com/cloudwego/eino/schema"
    "github.com/cloudwego/eino/components/tool"
    "github.com/cloudwego/eino-ext/components/model/openai"
)

func main() {
    ctx := context.Background()

    chatModel, _ := openai.NewChatModel(ctx, &openai.ChatModelConfig{
        APIKey: os.Getenv("OPENAI_API_KEY"),
        Model:  "gpt-4o",
    })

    // エージェントの作成
    agent, err := adk.NewChatModelAgent(ctx, &adk.ChatModelAgentConfig{
        Name:        "assistant",
        Description: "A helpful assistant that can use tools",
        Model:       chatModel,
        ToolsConfig: adk.ToolsConfig{
            ToolsNodeConfig: compose.ToolsNodeConfig{
                Tools: []tool.BaseTool{weatherTool, calculatorTool},
            },
        },
    })
    if err != nil {
        log.Fatal(err)
    }

    // Runnerの作成と実行
    runner := adk.NewRunner(ctx, adk.RunnerConfig{Agent: agent})
    iter, err := runner.Stream(ctx, []*schema.Message{
        schema.UserMessage("今週末の東京の天気は？"),
    })
    if err != nil {
        log.Fatal(err)
    }
    for {
        event, ok := iter.Next()
        if !ok {
            break
        }
        // エージェントイベントの処理（モデル出力、ツール呼び出し等）
        fmt.Printf("Event: %+v\n", event)
    }
}

Callbackを使った観測性の確保

// コールバックハンドラーの構築（公式ドキュメントより）
handler := callbacks.NewHandlerBuilder().
    OnStartFn(
        func(ctx context.Context, info *callbacks.RunInfo, input callbacks.CallbackInput) context.Context {
            log.Printf("onStart, runInfo: %v, input: %v", info, input)
            return ctx
        }).
    OnEndFn(
        func(ctx context.Context, info *callbacks.RunInfo, output callbacks.CallbackOutput) context.Context {
            log.Printf("onEnd, runInfo: %v, out: %v", info, output)
            return ctx
        }).
    Build()

// 全ノードに適用
compiledGraph.Invoke(ctx, input, compose.WithCallbacks(handler))

// ChatModelノードのみに適用
compiledGraph.Invoke(ctx, input, compose.WithChatModelOption(model.WithTemperature(0.5)))

// 特定ノード（node_1）のみに適用
compiledGraph.Invoke(ctx, input, compose.WithCallbacks(handler).DesignateNode("node_1"))

設定項目まとめ

ChatModelConfig（OpenAI実装）

以下は openai.ChatModelConfig の主要な設定項目です。

フィールド 型 必須 デフォルト 説明
APIKey string ✅ - OpenAI APIキー
Model string ✅ - モデルID（例: "gpt-4o"）
BaseURL string - - カスタムエンドポイント（Azure等）
ByAzure bool - false Azure OpenAI使用フラグ
APIVersion string Azure時 - Azure APIバージョン
AzureModelMapperFunc func(string) string - - Azureデプロイ名マッピング関数
Temperature *float32 - 1.0 生成のランダム性（0.0〜2.0）
TopP *float32 - 1.0 核サンプリング（0.0〜1.0）
MaxTokens *int - モデル最大値 最大トークン数（非推奨）
MaxCompletionTokens *int - - 最大補完トークン数
Stop []string - - 停止シーケンス
PresencePenalty *float32 - 0 存在ペナルティ（-2.0〜2.0）
FrequencyPenalty *float32 - 0 頻度ペナルティ（-2.0〜2.0）
Seed *int - - 再現性のためのシード値
ResponseFormat *ChatCompletionResponseFormat - - レスポンス形式（JSON等）
LogitBias map[string]int - - トークンバイアス（-100〜100）
User *string - - エンドユーザーID
ReasoningEffort ReasoningEffortLevel - medium 推論レベル（o1系モデル用）
Modalities []Modality - ["text"] 出力モダリティ
Audio *Audio - - 音声出力設定
Timeout time.Duration - なし APIタイムアウト
HTTPClient *http.Client - - カスタムHTTPクライアント
ExtraFields map[string]any - - 追加フィールド（実験的機能等）

Graph/Chain コンパイルオプション

// コンパイル時のオプション
compiledGraph, err := graph.Compile(ctx,
    compose.WithMaxRunSteps(100),       // 最大実行ステップ数
    compose.WithGraphName("my_graph"),  // グラフ名（デバッグ用）
)

CallOption（実行時オプション）

// 実行時に渡せるオプション
result, err := runner.Invoke(ctx, input,
    model.WithTemperature(0.7),                    // 温度の上書き
    model.WithMaxTokens(500),                      // 最大トークン数の上書き
    compose.WithCallbacks(myHandler),              // コールバックの注入
    compose.WithChatModelOption(model.WithTopP(0.9)), // ChatModelノードへのオプション
)

Callbackフックポイント

フック タイミング
OnStart コンポーネント実行開始時
OnEnd コンポーネント実行終了時
OnError エラー発生時
OnStartWithStreamInput ストリーム入力での開始時
OnEndWithStreamOutput ストリーム出力での終了時

ChatModelAgentConfig（ADK）

type ChatModelAgentConfig struct {
    Name        string           // エージェント名
    Description string           // エージェントの説明
    Model       model.ChatModel  // 使用するChatModel
    ToolsConfig ToolsConfig      // ツール設定
    // その他のオプション...
}

他のGoライブラリとの比較

GoでAIアプリを作る際によく比較されるのが以下のパッケージです。

パッケージ 種別 GitHub Stars 最新バージョン 活動状況
Eino AIフレームワーク 10.5k v0.8.7 非常に活発（毎日コミット）
langchaingo AIフレームワーク 9k v0.1.14 停滞気味
go-openai APIクライアント 10.6k v1.41.2 活発

LangChainGoの現状と課題

LangChainGoは知名度が高く、PythonのLangChainの概念に慣れている人には馴染みやすいですが、現在いくつかの問題を抱えています。

2026年3月には「is this project dead?（このプロジェクトは死んでいるのか？）」というIssueが立てられ、「6ヶ月間リリースがなく、多くのPRがクローズされないまま放置されている」という指摘がなされています。2026年4月8日時点で237個のIssueと161個のPRがオープンのまま残っており、メンテナンスが滞っている状況が伺えます。

また、Python版LangChainの設計をそのままGoに持ち込んでいるため、Goらしいシンプルな設計（Go idioms）から外れている部分があるという指摘もあります。

実測ベンチマーク（Ubuntu環境）

Ubuntu 22.04（Go 1.22.5）環境で、3つのパッケージを使って最小限のメッセージオブジェクトを100件生成するプログラムをビルドし、実際にパフォーマンスを計測しました。

テスト内容:

  • Eino: schema.UserMessage() で100件のメッセージ生成
  • LangChainGo: llms.TextParts() で100件のメッセージ生成
  • go-openai: openai.ChatCompletionMessage{} で100件のメッセージ生成

バイナリサイズ

パッケージ バージョン バイナリサイズ
Eino v0.8.7 14.0 MB
LangChainGo v0.1.14 4.8 MB
go-openai v1.41.2 3.9 MB

依存パッケージ数（go.mod）

パッケージ 直接依存 間接依存 go.sum エントリ数
Eino 1 26 137
LangChainGo 1 3 22
go-openai 1 0 2

起動時メモリ使用量（VmRSS ピーク、5回平均）

パッケージ メモリ使用量
Eino 約 11.6 MB
LangChainGo 約 3.6 MB
go-openai 約 3.3 MB

コールドビルド時間（キャッシュなし、3回平均）

パッケージ 平均ビルド時間
Eino 約 10.1 秒
LangChainGo 約 10.5 秒
go-openai 約 8.7 秒

注意: コールドビルド時間はGo標準ライブラリのコンパイルが大部分を占めるため、パッケージ間の差は小さくなっています。

考察

Einoのバイナリサイズやメモリ使用量が他より大きいのは、Einoが本番環境での運用を想定した多くの依存関係を含んでいるためです。具体的には、ByteDanceが開発した高速JSONシリアライザ（bytedance/sonic）、テンプレートエンジン（gonja）、ロギングライブラリ（sirupsen/logrus）などが含まれています。

これはEinoが「APIクライアント」ではなく「フルスタックのAIアプリケーションフレームワーク」であることの表れです。go-openaiとの比較は、ある意味でExpressとNode.jsのhttpモジュールを比較するようなもので、用途が根本的に異なります。

LangChainGoとの比較で見ると、Einoはより多くの機能（ADK、Graph/Chain/Workflow、Callback等）を持ちながらも、メンテナンスが活発であるという点で優位性があります。

Human-in-the-Loop（人間による介入）

Einoの特徴的な機能の一つが、エージェントの実行を途中で一時停止し、人間の確認を挟んでから再開できる仕組みです。公式ドキュメントでは次のように説明されています。

"Any agent or tool can pause execution for human input and resume from checkpoint. The framework handles state persistence and routing."

— cloudwego/eino - GitHub

これにより、例えば「ファイルを削除する前に確認を取る」「重要な決定を人間に委ねる」といったユースケースを自然に実装できます。

Graphが自動処理してくれること

Einoのグラフオーケストレーションが自動で処理してくれる機能は以下の通りです。

"Eino's graph orchestration provides the following capabilities out of the box: Type Checking (Ensures that the input and output types of two nodes match at compile time), Stream Processing (Concatenates message streams before passing them to ChatModel and ToolsNode nodes when needed, and copies the stream to callback handlers), Concurrency Management (Since StatePreHandler is thread-safe, shared state can be safely read and written), Aspect Injection (If the specified ChatModel implementation does not inject callbacks itself, callback aspects will be injected before and after ChatModel execution), Option Assignment (Invoke Options can be set globally, or for specific component types or specific nodes)."

— Eino: Overview | CloudWeGo

機能 説明
型チェック コンパイル時に2つのノードの入出力型が一致するか確認
ストリーム処理 必要に応じてメッセージストリームを連結し、コールバックハンドラーにコピー
並行管理 StatePreHandlerはスレッドセーフ
アスペクト注入 ChatModel実装がコールバックを注入しない場合、フレームワークが自動注入
オプション割り当て グローバル、特定コンポーネントタイプ、特定ノードへのオプション設定が可能

まとめ

Einoは、ByteDanceが社内での実運用経験を元に作り上げた、非常に実践的なGoのAIフレームワークです。

Einoを選ぶべきケース:

  • エージェントや複雑なワークフローを構築したい
  • Graph/Chain/Workflowによる柔軟なオーケストレーションが必要
  • Human-in-the-Loopやチェックポイント機能が必要
  • 活発にメンテナンスされているフレームワークを使いたい
  • ByteDance/CloudWeGoエコシステムとの統合が必要

他の選択肢が向いているケース:

  • シンプルにOpenAI APIを叩くだけなら go-openai が軽量で十分
  • PythonのLangChainからの移行で慣れ親しんだAPIが必要なら langchaingo（ただしメンテナンス状況に注意）

日本語ドキュメントはまだ存在しませんが、公式の英語ドキュメントは非常に充実しており、Quick Startシリーズ（全10章）も整備されています。GoでAIアプリを作ることを検討しているなら、ぜひ一度触ってみてください！

参考リンク

VeriCerts Tech Blog
VeriCerts Tech BlogPublication

VeriCerts株式会社は、Blockchain、IPFS、DID/VC、生成AIなどを活用し、Web3時代の信頼を支える技術を開発しています！技術情報を中心に投稿します！

Discussion