Platform Engineering Kaigi 2026

AIエージェントもMCPも1本のトレースに — 全アプリOTel統一を支えるプラットフォーム戦略

Tech(課題を解決する個別技術)日本語 - Japaneseプラットフォームエンジニア - Platform Engineerアプリケーション/プロダクト開発者 - DeveloperITアーキテクト - Architect

概要

生成AIの活用が広がり、アプリケーションの裏側にはLLM、AIエージェント、MCPサーバーといった新しいコンポーネントが加わっています。「AIの呼び出しだけ専用ツールで見る」のは簡単ですが、そ れでは通常のマイクロサービスとの間でトレースが途切れ、障害調査のたびにコンテキストを人間が繋ぎ直すことになります。これは計装の問題ではなく、プラットフォームの設計問題です。 ログラスでは、マルチプロダクトを支えるKubernetes共通基盤で、AIに限らず全アプリケーションの計装をOpenTelemetryに統一しています。その結果、マイクロサービスからAIエージェント、MCP、LLMゲートウェイまでが1本のトレースで繋がり、AIコンポーネントを含む障害調査が通常のマイクロサービスと同じ道具立てで完結します。バックエンドはDatadogを採用しつつ、接続は標準のOTLPに寄せています。 これを支えるのが、プラットフォームとしての提供モデルです。開発者はOTel SDKで計装するだけ。OTel関連の設定は共通Helmチャートが既定値として配り、OTel Collectorとテレメトリーパイプラインはプラットフォームが一元管理します。o11yを「各チームの努力」ではなく「基盤の標準機能」として配ることで、AIワークロードが増えても観測性が自然に追従し、組織はAI活用を安心して広げられます。 本セッションでは、ツールの入れ替わりが激しいAI時代に「なぜ標準準拠(OTel)か」という判断軸から、共通Helmチャートで計装設定を「配る」Golden Pathの設計、Collectorパイプラインの構成と運用、多言語(Go/Kotlin/Rust/TypeScript)計装のハマりどころまでをお話しします。AIコンポーネントの観測が分断されて困っている方、o11yの整備を各チーム任せにせず基盤で解きたい方に、明日から使える判断軸と実践手順を持ち帰っていただきます。

OpenTelemetryObservabilityOTel CollectorLLM ObservabilityAI AgentMCPKubernetesHelmGolden Path

スピーカー

mekka
mekka / mekka
株式会社ログラス クラウド基盤チーム SRE

SIerでアプリケーションエンジニアとしてキャリアをスタート ToBのSaaS企業でSRE組織の立ち上げを経験、2024年10月よりログラスに参画。共通基盤部でSRE推進・プラットフォーム開発に従事

@melpo_melGitHub: chmikata