シュナイダー・エレクトリックがLangSmithを用いてLLMOpsの基盤を構築した方法

Schneider Electric は、エネルギー技術のグローバルリーダーであり、産業・企業・家庭の電気化、自動化、デジタル化を通じて持続可能性を推進しています。従業員数は 16 万人、年間売上高は約 400 億ユーロに達し、同社は野心的な AI プログラムを実行しています。これは 350 名の専門家からなる社内 AI ハブで、エネルギー消費の最適化、資産寿命の延長、開発者の生産性向上のために 60 以上のエージェント（自律型プログラム）を展開しています。

重要インフラ向けに大規模な AI を展開する

Schneider の広範な AI プログラムは以下の 3 つのカテゴリーにわたります：

• エネルギー消費を削減するために製品に直接知能を組み込むこと（例：ルームコントローラーにおけるサーマル学習）。
• 需要と生産を予測するために AI を使用し、顧客が電力使用量をより安価で環境負荷の低い時間帯へシフトできるようにすること。
• より複雑なグリッド管理やカスタマーサクセス、炭素排出量ソフトウェアシステムの照会など、運用上の摩擦を軽減するエージェント型コパイロットを展開すること。

これらの目標にはすべてエージェントが組み込まれており、厳格なデータ所在地要件とサイバーセキュリティ制御の下で重要インフラ上で動作しています。Schneider は、チームが迅速に構築できるようにしつつ、データの管理、デプロイメント、品質に対するコントロールを維持できる共通のエージェントプラットフォームを必要としていました。

"精度の課題、回答の質の課題、ガードレールの課題は非常に現実的なものです。大規模にソリューションを展開する際には、LangSmith のようなツールが必要です。信頼性や何が起こっているかを理解することと関連するすべてが、私たちにとって極めて価値あるものです。"

– フィリップ・ランバッシュ氏、シュナイダーエレクトリック CAIO（最高 AI オフィサー）

シュナイダーの AI プラットフォームチームは、AI ハブ内に位置し、広大な技術環境（マルチクラウド、クラウドからエッジまで、あらゆる種類の AI）において AI スクワッドが確実に成果を達成できるよう、共有インフラストラクチャを提供しています。

以下のゲストブログでは、LangSmith とより広い LangChain エコシステムを中心に LLMOps 能力を構築した物語を共有します。その目的は以下の通りです：

• 100 カ国以上で 14 万人の従業員にサービスを提供する AI アシスタントの精度と品質を継続的に改善して展開する。
• カスタマーサクセスマネージャー コパイロットを展開するための LLMOps マチュアリティフレームワークを共同構築する。
• LangSmith Deployment のタスクキューモデルを活用して、見積もりワークフローを加速する

*著者：****ヨアン・ベルシハンド氏、AI プラットフォーム VP（最高責任者）*

*ニコラス・ゴティエ氏、アジェンティック AI エンジニアリング 製品オーナー *

*アマリー・ゲラン氏、アジェンティック AI エンジニアリング AI エンジニア *

課題：従来の MLOps から LLM システムへの転換

自信を持って大規模に運用するためには、専用の LLMOps の分野が不可欠です。これがなければ、私たちのチームは盲目で飛行することになります。従来の MLOps アプローチは LLM ベースのシステムにはそのまま適用できず、以下のようなリスクが生じます：

• エージェントの動作を生のアプリケーションログを超えてデバッグする能力に限界があること。
• プロンプトやモデルの変更に対する精密な測定が欠如していること。
• GenAI およびエージェントシステムの本番環境への準備完了を検証することが困難であること。

アーキテクチャ：3 つの柱

私たちは、エージェント型製品のライフサイクルを反映する 3 つの柱を中心に AI プラットフォームの LLMOps（LLM オペレーションズ）機能を構築しました。1) 可観測性、2) 評価、3) デプロイメントです。

1. 可観測性：セルフホスト型 LangSmith、製品ごとに 1 つのワークスペース

可観測性は、「何が起きているかを見ることができる」という状態をもたらします。

私たちは、LangSmith を AWS EKS（Elastic Kubernetes Service）上でセルフホスト構成としてデプロイし、企業のセキュリティ境界の背後に統合しています。このアプローチにより、厳格なデータプライバシーが確保され、サードパーティへのデータ流出に関する内部ポリシーとのコンプライアンスも満たされます。

可観測性側における重要な設計上の決断は、ワークスペースのインスタンス化モデルをどのように構造化するかという点でした：各 AI 製品に対して 1 つのワークスペースを設け、すべての環境（開発、QA、プレプロダクション、本番）にまたがって運用します。もう一つの代替アプローチである「環境ごとに 1 つのワークスペース」という方法は、私たちが実現したいループを分断してしまいます。つまり、オフライン評価のために本番からのトレースを開発用データセットへ戻すというプロセスです。

開発と本番を同じワークスペース内に共存させることで、当社の専門知識を持つ専門家（SME）は本番のトレースに注釈を付け、直接データセットへプッシュすることができます。これらの例はその後、エージェントの新しいバージョンに対して再生され、改善が検証されます。

実務的には、これはデータセット、注釈、実験が、それらが由来する本番環境のトレースと密接に連携していることを意味し、実際の利用状況から学習してシステムパフォーマンスを継続的に改善しやすくします。

本番環境の事例：「One Jo」

社内 AI アシスタントである One Jo は、160,000 名のシュナイダーエレクトリック従業員を対象に、107 カ国で展開されています。すべての会話は LangSmith を通じてトレースされながら、厳格なデータプライバシー基準が維持されます。本番環境のトレースはチームによって体系的に再利用され、回帰テスト用データセットを構築するために活用されており、これにより各新しいモデルやプロンプトの反復版が実際の利用状況に対して検証可能となっています。これらの同じトレースはまた、ドリフト（性能変化）に対する即座の可視性を提供し、チームが時間の経過に伴うパフォーマンスの変化を迅速に検知して対応することを可能にします。

2. 評価：オフライン、オンライン、および成熟度フレームワーク

観測可能性（Observability）によって私たちは「何が起きているかを見られる」という段階に至りましたが、評価（Evaluation）によって私たちは「リリースするかどうかを決定できる」という段階に至りました。私たちはここに三つの側面で多大な投資を行いました。

第一に、オフライン評価のアクセラレーターです。私たちは Agentic RAG の GitHub テンプレートを Azure および AWS で提供しており、LangSmith SDK を基盤とした軽量な評価 CLI（コマンドラインインターフェース）も併せて提供しています。

目的は、すべての AI チームが実験を実行する方法を標準化することです。同じデータセットの規約と、同じ評価器インターフェース（openevals パターンに基づいて構築されたもの）を使用します。

その結果、新しいチームは初期設定から意味のあるオフライン評価スイートへの移行を迅速に行えるようになりました。

第二に、LLMOps（大規模言語モデル運用）の成熟度フレームワークです。 60 以上の AI プロダクトを抱える中で、トレーシングと評価の導入には多大な労力が必要です。そこで私たちは、主要な機能を追跡するための内部 LLMOps 成熟度モデルを策定しました：*このプロダクトは計測可能（instrumented）になっていますか？オフライン評価スイートを持っていますか？本番環境でオンライン評価者が稼働していますか？ユーザーフィードバックが循環して再利用されていますか？*

これを通じて、LangSmith API に対する自動レポートを構築しました。スケジュールされた GitHub ワークフローにより、LangSmith の機能に対するすべての AI プロダクトの統合ビューが生成され、採用状況と進捗の継続的な可視化を実現しています。

LLMOps の成熟度レベルは、AI プロダクトライフサイクルに組み込まれており、ユースケースを*探索→孵化→産業化→運用*へと移行させるゲートレビューの一部として活用されています。

第三に、専門家の関与。適切なツールがあっても、評価において最も難しい部分はドメインの専門知識をループに組み込むことです。私たちは内部のSME（専門知識を持つ者）の役割を、開発者レベルの表面領域を露出させることなく、注釈キューやデータセットへのアクセス権を与えるカスタムLangSmithロールにマッピングしました。現在、AI製品の約20%には、少なくとも1つのアクティブな注釈キューがあり、SMEが参加しています。これにより、ドメインの専門家はエンジニアリングスキルを必要とせず、実際の事例を直接レビューおよび注釈付けして評価に貢献することができます。

LLMOpsループ:

生産環境の事例：カスタマーサクセス管理（CSM）コパイロット

Schneider Electricのサービス事業部門は、AIを活用した状態ベースメンテナンス、24時間365日のリモートモニタリング、および専門家のサポートを通じて、データセンターやビルの資産パフォーマンス管理を先行的に提供しています。

CSM Copilotは、状態ベースメンテナンスをサポートする複数のAgentic AIソリューションの一つです。これは250名以上のカスタマーサクスマネージャーに対して、あらゆる顧客アカウントまたは契約においてより迅速なインサイトを生成することを可能にします。

CSM Copilot は、初日から SME が LangSmith を活用して設計されました。これにより、SME は継続的な出力レビューや注釈の提供、開発中のシステム動作の調整を通じて、共同で構築された製品の品質に直接影響を与える機会を得ました。その結果、製品は最初の展開時に高いレベルの品質と CSM の採用率を達成しました。

3. デプロイメント：LangSmith デプロイメント、製品ごとのランタイム

ストリーミング、長期メモリ、人間を介したループ（ヒューマン・イン・ザ・ループ）インタラクション、またはバックグラウンド処理を必要とするエージェントについては、AWS および Azure のランディングゾーンにおいて、「Postgres と Redis を備えた Agent Server」の LangSmith デプロイメント参照アーキテクチャに標準化しました。

初期段階から、集中型のエージェントランタイムを実行しないことを選択しました。代わりに、各 AI 製品は独自の専用スタック上で動作します。

この決定を導いたのは、2 つの主要な原則です：

• 「構築したものは自ら運用する」という哲学のもと、当社の AI プラットフォームは、AI チームに対して完成品としてのランタイムを提供するのではなく、堅牢な基盤と舗装された道筋を提供することを目指しています。自らのランタイムを所有することで、AI チームはレイテンシ、コスト、インシデント対応に対する完全なコントロールを維持できます。
• 単一障害点の排除です。集中型のエージェント・ランタイムを導入するとシステム全体のリスクが生じます。誤ったデプロイやリソースの問題が発生すれば、すべてのエージェントに同時に影響が及ぶ可能性があります。一方、製品ごとのランタイムを採用することで、問題は特定のユースケースに限定され、プラットフォーム全体としての回復力を保つことができます。
• ただし、このアプローチにはトレードオフも伴います。管理すべきインフラが増え、アップグレードの調整も多くなります。これが私たちが現在注力している領域です（後述する「今後の展望」をご覧ください）。

すべての製品は、AWS と Azure の両方でクラウド非依存となるように設計された、同じ langgraph.json テンプレートから始まります。以下のバージョンには、大規模企業環境における典型的な要件が含まれています：許可リストに登録されたベースイメージ、企業 CA バンドルとの統合、そしてエージェント・グラフと並行して公開されるカスタムフィードバック HTTP ルートです。

生産環境の事例：デジタルエネルギー部門における仕様書インテリジェンス

当社のデジタルエネルギー部門では、商業施設、産業施設、公共インフラにわたるビルの運用を革新しています。この取り組みの一環として、顧客からの見積もり依頼（仕様書、建築図面、その他の PDF ドキュメントを含む）を分析し、文脈に応じた注釈を自動的に付与するドキュメント処理エージェントを開発しました。その結果、見積もりのワークフローは以前の数時間、あるいは数日かかっていたものが、わずか数分で完了するようになりました。

このエージェントの平均完了時間は約 15 分です。このような長時間実行されるバックグラウンド処理こそが、LangSmith Deployment のタスクキューモデル（task queue model）が設計された目的そのものであり、リアルタイムシステムの性能を損なうことなく、信頼性の高い実行を可能にします。

結果

LangChain とのパートナーシップを通じて、私たちは以下のような形でエネルギー技術の発展を続けています：

• LangChain エコシステム上に構築され、開発中または本番環境で稼働中の AI プロダクトが 60 以上あり、
• エンジニアリングコミュニティおよび SME（中小企業）コミュニティ全体で約 200 名の LangSmith ユーザーがアクティブに利用しており、エネルギー管理と産業自動化における当社のドメイン知識と専門性が、AI プロダクトの中核を担っています。

スケールした LLMOps の構築から得た教訓

LLMOps への初期の賭けは的中しました。 トレースレベルの観測可能性と、本格的なオフライン評価の規律がなければ、私たちのエージェント型製品が生産環境に到達することはなかったでしょう。早期に計装（instrumentation）に抵抗したチームこそが、後に頭の中で非確定的な回帰（regression）をデバッグすることに苦労することになりました。

カスタム機能を開発する前に、標準搭載機能を頼りにしましょう。 評価のための複雑な内部フレームワークを構築するのは魅力的に思えました。振り返れば、重要な教訓は、カスタム機能を開発する前に標準搭載機能に頼る方がよいということです：LangSmith SDK の上に薄い CLI を構築する、既存の権限モデルにマッピングされたカスタムロールを設定する、パブリック API によるスケジュールレポートの実行などです。

セルフホスティングは素晴らしいですが、コストがかかる可能性があります。 LangSmith はセルフホストモードで非常に堅牢ですが、Helm チャートのアップグレード、EKS のライフサイクル管理、バージョンの固定（pinning）、そして時々「SaaS ドキュメントでは動作するが、私たちのネットワークポリシーとは意見が異なる」というデバッグセッションなど、インフラストラクチャと運用コストを払うことになります。コンテキスト上 SaaS が許容されるなら、それを選ぶべきです。

採用は技術ではなく組織次第です。 技術自体は迅速に統合されますが、真の差別化要因は、急速に変化する AI の環境において、複数のチームを共通のプラクティス、標準、ワークフローで一致させることにあります。

LangChain エコシステムは、統合性と柔軟性の間に強力なバランスを提供しています。 ポートフォリオは内部的に一貫性があります（OSS ライブラリ、観測性と評価のための LangSmith、LangSmith Studio を備えた LangSmith Deployment）が、OSS ライブラリはスタンドアロンで使用可能であり、LangSmith はサードパーティ製フレームワークとシームレスに統合されます。これにより、無理な選択を迫られることなく、必要な要素を組み合わせて利用する余地が生まれます。

Schneider Electric と LangChain：今後の展望

プラットフォームへの AI ネイティブエンジニアリングの適用

LLMOps の導入を容易にするため、エージェントのスキル（Skills）やコーディングエージェントの実証実験を行っています。並行して、「製品ごとに 1 つのランタイム」という戦略（詳細はセクション 3：デプロイメント参照）に基づき、LangSmith Deployment ランタイム上でアジェンティックな製品の保守を促進・自動化するためのエージェントスキルへの投資を進めています。

エッジ AI とハイブリッド型アジェンティックシステム

AI 製品のうち、産業環境におけるハードウェアデバイスやゲートウェイなどで動作するエッジでの運用が占める割合は増えています。現在、LangSmith はこれらのシステムのクラウド側のライフサイクル（オフライン評価およびデータセット管理を含む）をサポートしていますが、接続性の制約により、ランタイム実行とオンライン評価は LangSmith 外でローカル側で行われています。LangChain チームと共に、エッジ AI や物理的 AI のシナリオに対応できるようエコシステムを積極的に拡張しており、これが私たちの次のフロンティアです。

「既存の技術でも、今日からエネルギーを 20〜25%節約できます。しかし、私たちは顧客に対して、エネルギーシステムとの次世代レベルのインタラクションを提供したいと考えています。彼らがよりよく理解し、よりよく対話し、さまざまなシナリオをシミュレーションし、その知見に基づいて行動することで、地球規模でのエネルギー消費と炭素排出量に実際に変化をもたらすことを目指しています。」

– フィリップ・ランバッチ氏、シュナイダーエレクトリック CAIO

エージェントが実際に何をしているかを確認する

LangSmith は、エージェントエンジニアリングプラットフォームとして、開発者がすべてのエージェントの意思決定をデバッグし、評価の変更を行い、ワンクリックでデプロイできるように支援します。