トヨタグループ内製開発組織が追求する、カルチャー&技術両輪の生成AI活用推進 〜CloudWeGo/EinoによるAI Agent民主化事例紹介もあわせて紹介〜 Part#2

Transcript

1. CloudWeGo/Einoで実現する 全社員のAI活用民主化への取り組み Azure OpenAI Dev Day 2025 KINTOテクノロジーズ株式会社 鳥居 雄仁 1
2. 本日のアジェンダ 1. AI民主化への取り組み - なぜ必要か、どう実現するか 2. 作っただけでは使われない - 普及・定着への工夫 3. KTC AIプラットフォーム - 何を作ったか 4. 技術選択の背景 - Go採用とEino選定 5. Einoで実現した機能 - 動的ワークフロー構築の仕組み 6. 実装課題と解決 - Azure連携、運用の工夫 7. 成果と今後の展望 - Multi-Agent、MCP対応 2
3. 自己紹介 鳥居 雄仁 KINTOテクノロジーズ株式会社 グループコアシステム部 共通サービス開発グループ/ AI開発グループ 所属 KINTOの会員基盤や、今回ご紹介する 社内AIプラットフォームの開発などを 行っています 3
4. 今日話すこと・話さないこと 話すこと 社員全員が自律的にAIツールで価値を生み出せる環境づくり Go + Einoを選んだ理由と実装の工夫 社内に広げるための施策 得られた効果 & 今後の展望 話さないこと 個別のAI活用事例の詳細 具体的な業務改善の数値 細かい実装コードの解説 4
5. そもそも民主化とは？ AI活用を「特別な人のもの」から「みんなのもの」へ 段階 キーワード 主な施策 ゴール ① Access 「触れる」 入口を開く チャット UI を全員に開放した状態 だれでも試せる ② Enablement 「使いこなす」 学びを支援 共有テンプレやワークフロー で学習曲線を潰す段階 自力で活用 ③ Culture 「定着する」 改善が循環 成功事例が横展開され、 改善が自然に回り続ける段階 当たり前になる 5
6. なぜ必要か？ 2025 年 KINTO テクノロジーズは 「AIファースト を掲げている 現状、生成 AI は全社へは浸透しきれていない 目指すのは “AI が電気のように当たり前” の職場 その土台となる 共通 AI プラットフォーム を整備する 6
7. KTC AIプラットフォーム 何を作ったか Einoを活用した社内AIアシスタント マルチAIプロバイダー統合 Azure OpenAI、Claude、Gemini を自由に切り替 え EinoのReActエージェントで複数ツールを自動連携 チャットやプロンプトテンプレート、ワークフロー機能など AI活用の民主化 チャット履歴・プロンプト・ワークフローなどの共有機能 成功事例の横展開による組織力向上 7
8. なぜ内製化したのか 内製の強み 全員が使える：ライセンスコストを気にせず全社展開 教育基盤として活用：生成AI研修の共通環境を提供 生成AI開発能力の内製化：技術ノウハウを組織内に蓄積 SaaSとの共存 汎用SaaSは特定の高度なユースケースで活用 内製は日常業務と教育の基盤として位置づけ 8
9. なぜGoを選んだのか 組織戦略としての技術選択 背景: Java/SpringBoot中心の開発に加え、Go採用事例が増加 人材育成: Go開発経験を積める環境づくり あえてGoを選択: Python/TypeScriptの方がLLMライブラリは豊富だが、組織の成 長を優先 開発の経緯と課題 体制: 3人チーム、全員がメイン業務と兼務 当初: ツール実装やReActエージェント等を自前実装 限界: フレームワーク保守に工数を取られ、価値創造が停滞 9
10. Eino採用の決め手 必須要件 ユーザー自身がワークフローを作れるAPIが必須要件 調査の結果、Einoなら実現可能と判明 Einoに決めた理由 動的ワークフロー構築: Orchestration機能により柔軟に構築可能 実装の見通し: JSON → Eino のワークフローSchemaに変換可能 豊富なエコシステム: 30+公式ツール、活発な開発 ByteDance製: Go界隈での実績と信頼 10
11. CloudWeGo/Eino（アイノウ） CloudWeGo ByteDance発 Go製マイクロサービスフレームワーク群 TikTok本番トラフィックで実証済みの高性能・高信頼性 Eino（Embedding Intelligence Native Orchestration） 発音: "I know"に近い CloudWeGoプロジェクトの一部として開発されたLLMフレームワーク LangChain/LlamaIndexのGo版として位置付け 11
12. Einoのキラー機能：Orchestration 部品を組み合わせて複雑な処理を実現 基本コンポーネント(Node): ChatModel（LLM）、Retriever（検索）、 ToolsNode（ツール）、Lambda（独自処理） 自由な接続: 質問→RAG検索→LLM回答→ツール実行を1つのフローに 柔軟な接続: AddEdgeで線形、AddBranchで条件分岐 型安全な接続: ノードの上流・下流の型が合わないとコンパイルエラー 並列実行: 独立した処理は自動的に並列化 視覚的デバッグ: JetBrains/VSCodeでフローを見ながら開発 12
13. Einoノードアーキテクチャ 13
14. Orchestration実装方法 14
15. 動的グラフ構築 1. JSON Schema に永続化 ノード種別と接続情報をそのまま保存 2. 送るだけで再構築＆実行 フロントで JSON を編集 → API に POST → Eino が自動でグラフ生成 3. 現場が自分で作れる GUI＋JSON でエンジニア以外もワークフローを拡張 ※ 動的生成はEinoの型安全性の思想から外れる 　 → 保存時検証で型安全性を担保 ※ 同様の仕組みは Mastra などでも実装可能 (予想) 15
16. Eino機能：ReActエージェント シンプルな独自のアプローチ LLMのToolCalling活用: 明示的な思考ステップなし、LLMのToolCallingに委ねる 暗黙的ループ: LLMがツールを呼ぶ限り自動的に継続 MaxStep安全装置で無限ループを防止 ストリーム対応でリアルタイム応答も可能 ReActエージェントの内部実装：Orchestrationを活用 ReActエージェント自体もEinoのOrchestration機能で実装 AddBranchで条件分岐：ツール実行の有無で処理を制御 16
17. 実装の簡潔さ // 1. ール義 toolInfo := &schema.ToolInfo{ Name: "get_current_time", Desc: "現在の日時を取得します", ParamsOneOf: schema.NewParamsOneOfByParams( map[string]*schema.ParameterInfo{ "timezone": {Type: schema.String}, }), } tool := utils.NewTool(toolInfo, getCurrentTime) // 2. ReActエージェント作成 agent, _ := react.NewAgent(ctx, &react.AgentConfig{ ToolCallingModel: model, Tools: []tool.Tool{tool}, MaxStep: 20, }) 17
18. Azureインフラ構成 エンタープライズ向けAzure完結型設計 18
19. インフラ構成詳細 19
20. 技術スタック詳細 (1) Infrastructure コンテナ実行: Azure Container Apps データストア: CosmosDB for NoSQL, Blob Storage AI実行環境: Azure Functions + Azure AI Foundry (Python) 認証基盤: Azure Entra ID 20
21. 技術スタック詳細 (2) Backend (Go) Webフレームワーク: Huma (OpenAPI自動生成) + Chi Router AI統合: CloudWeGo/Eino (LLMオーケストレーション) Frontend (TypeScript) UIフレームワーク: React 19 + Vite ルーティング: TanStack Router (型安全なルーティング) 状態管理: Jotai (アトミックな状態管理) データフェッチ: TanStack Query UIコンポーネント: shadcn/ui (Radix UI + Tailwind CSS) 21
22. KTC AIプラットフォーム アーキテクチャ 22
23. KTC AIプラットフォームの主要機能 基本機能 チャット: 一般的なチャットUIでEino ReActエージェントによる自動的なツール実 行 プロンプトテンプレート: よく使う質問や指示を定型文として保存・再利用 チャットテンプレート: システムプロンプトとモデル設定をセットで定型化 ワークフロー: 複数の処理を組み合わせた複雑なタスクをGUIで作成 共有機能 すべての機能で「共有」ボタンを実装 チャット履歴の共有：成功した会話を他メンバーが参考に テンプレートの共有：便利な定型文を組織全体で活用 ワークフローの共有：作成したフローを誰でも実行可能に 23
24. 実装上の課題と解決 1. Azure OpenAIのマネージドID認証 課題：Eino組み込みChatModelの認証制約 Eino組み込みのOpenAI ChatModelはAPIKey認証のみ対応（調査不足の可能性あ り） エンタープライズ環境ではマネージドID認証が必要 セキュリティ要件を満たしながらAzure OpenAIを利用したい 解決：CustomChatModel機能でマネージドID対応 EinoのCustomChatModel機能を活用 Azure SDK for GoでマネージドID認証を実装 同様にVertex AI経由のClaudeにも対応 24
25. 実装上の課題と解決 2. AI Foundryエージェント機能の活用 課題：GoでのAI Foundryエージェント機能の制約 AI FoundryのWeb検索エージェントをGoから直接利用できない Python や TypeScript 、 .NET などが必要 解決：PythonでREST API化 + Eino Tool実装 Python（Azure Functions）でWeb検索エージェントを実装 REST APIとして公開し、GoからHTTP経由で呼び出し Eino Toolとして実装することで再利用性向上 25
26. カスタムChatModel実装例 ポイント: Einoの標準インターフェースに準拠することで、ReActエージェントやツー ル機能がそのまま利用可能 26
27. 今後のロードマップ ツール群の充実化 基本ツールの拡充 ファイル操作、データベース連携など基本機能の整備 Eino MCP Tool対応 MCP (Model Context Protocol)エコシステムとの統合 GitHub MCP、Microsoft Learn MCPなどをEino Toolとして利用可能に Multi-Agent機能の実装 Eino Host Multi-Agent対応 ユーザーの意図を認識し、適切な専門エージェントへタスク委譲 複数の専門家（記録、検索、分析など）を1つのインターフェースで統合 必要に応じて複数エージェントを同時実行し、結果を統合 27
28. まとめ CloudWeGo/Einoを使ってみて GoでもAIプラットフォーム開発は十分可能 ただし適材適所で他言語との連携は必要 標準機能の充実とカスタム性 十分に豊富な機能群 必要に応じて容易にカスタムツールを実装可能 最後に、作るだけでなく認知してもらうことが重要 高頻度で更新し告知することで認知につなげる ユーザーからのフィードバックを受け取り、改善に活かす 利用統計からどの機能が使われているかを把握し、改善に活かす 28
29. ご清聴ありがとうございました ぜひ皆さんもCloudWeGo/Einoを試してみてください！ 参考リソース Eino公式ドキュメント: cloudwego.io/docs/eino 29