生成AI活用のフロントランナー
【第11回】鉄道の安全をAIエンジニアリングで次のステージへ（前編）

「【第10回】鉄道の安定運行を支えるAIの進化の鍵、エスノグラファー」はこちら＞

複数のAIエージェントが協調して目的を達成

——現在、ATOSのAIエージェントは、特定の装置、トラブルケースに限定した試験で運用への適用可能性を検証する段階に達しています。しかし、ここに至るまでにはさまざまな課題があったと聞きました。プロジェクトでは日立にあるATOSに関する知見の取り込みを担っている吉田さんですが、具体的にはどのような課題があったのでしょうか。

吉田
ATOSとは、JR東日本が首都圏の列車を安全・正確に運行させるために用いる世界最大規模の鉄道運行管理システムです。今回の共同検証では、万が一ATOSにトラブルが生じた際に、必要な情報を提示することで迅速な復旧を支援するAIエージェントの開発に取り組んでいます。
私たちはプロジェクトの初期段階で、外部データベースとして「問い合わせ履歴DB」、「障害報告DB」をそれぞれ参照するAIエージェントを2種類用意し、入力した質問に応じてどちらか適切なエージェントが回答を返すチャット形式の仕組みをJR東日本に提案しました。
しかし、評価は芳しくありませんでした。というのは、ATOSは、1日に数百万人が利用する首都圏の列車の安定運行を担っており、トラブル復旧の判断にミスは許されません。その時に単一のAIエージェントの回答を判断材料とするのは、情報が偏っていたり、必要な情報が抜け落ちていたりする可能性があり、リスクが大きい。多角的で信頼性の高い回答が欲しい、ということでした。そこで、私たちは、複数のAIエージェントを組み合わせて回答させることを考えました。

——複数のAIエージェントを組み合わせたアーキテクチャーとは、具体的にどのような構成なのでしょうか。開発全体を統括している細包さん、聞かせてください。

細包
現時点では、4つのAIエージェントで構成されたアーキテクチャーとなっています。まず、「アラートの意味説明エージェント」。これは文字通り、アラート情報を入力すると、その意味を示してくれるエージェントです。
次に「アラート原因不足情報判断エージェント」は、アラート情報とシステム構成図を突き合わせて、どの装置に不具合があるかを推測します。さらに、原因装置を高い確度で特定するために必要な不足情報——例えばランプの色や点滅状況など——をユーザーに要求する機能も持っています。
さらに「影響判断エージェント」は、現在発生しているトラブルが継続した場合に列車運行や利用者にどのような影響が及ぶかを推定します。
また「対策提示エージェント」は、現時点で得られている情報をもとに、過去に実施された対策を提示するものになります。そして、各AIエージェントとのやりとりは一問一答形式のチャットではなく、アラート情報をもとに導き出された各エージェントの回答が領域ごとに表示され、ユーザーは一目で複数の情報を確認することができます。このアーキテクチャーをベースに、現在AIエージェントの実用性について実証実験を行っています。

試行、失敗、再試行の繰り返しで経験値を蓄積

——このアーキテクチャーにたどり着くまでに、さまざまな試行錯誤があったかと思います。今回のAIエージェントの全体設計を担当されている奥田さん、いかがでしょうか。

奥田
これまでも、そして現在も高精度な回答を引き出すための試行錯誤は続いています。例えば、複数のエージェントを組み合わせるにしても、その方法によってはかえって精度が落ちることがあります。実際、このアーキテクチャーの前段階では、各エージェントの上位にそれぞれ指示を生成する「ファシリテートAI」を設けていましたが、現時点では除外しています。上位のエージェントと処理を行うエージェントの双方がハルシネーションを起こすリスクがあり、精度を損なう要素になりうるからです。
アーキテクチャーの他にも、LLMのモデルは何を使うのか、さらにAIエージェントを業務に適用させるために——ファインチューニング、RAG*²、コンテキストエンジニアリングなど——どの技術を使うのかなど、検討すべき項目は数々あります。そして、その組み合わせは多様にあり、私たちは現在もその最適解をめざして可能性を排除することなく日々検証を続けています。
＊2　RAG：Retrieval-Augmented Generation／検索拡張生成

——ここまでの話だと変更も多かったように思われますが、このAIエージェントの設計と技術実装に携わった山室さん、その経験はどのようなものでしたか。

山室
大きな変更としては、ATOSの開発拠点である日立 大みか事業所の熟練エンジニアの知見の取り込みがあると思います。最初はトラブル報告書や手順書など既存のドキュメントをAIに学ばせて回答を得るアーキテクチャーを描きましたが、期待した成果が得られませんでした。検証を進める中で、文書には記されていない、日立の熟練者ならではの知見が欠かせないことが明らかになりました。そして私たちは、エスノグラファーが収集したトラブル復旧時の知見をLLMに取り込むという初の挑戦に取り組むことになります（関連記事）。
もとよりこのプロジェクトはウォーターフォール型ではなくアジャイル型の開発になると認識しており、ここでも既存の構成を前提とした単純な修正では対応しきれず、エージェント間の連携フローからコンテキストエンジニアリング・知識統合プロセスの再構築など、多くの見直しが必要となりました。
ATOSのような大規模制御システムに適用するAIエージェントの事例はまだ希少で、実現の方法論が明確に固まっているわけではありません。その中で、高信頼なものを効率的につくろうとするならば、短いサイクルで試行、失敗、再試行を繰り返すことでシステムを磨き上げていくのが最適なやり方であり、柔軟な見直しや再設計も必要なものだったと思います。

奥田
この現場の知見を正確に回答に反映させるためのLLMエンジニアリングはもっとも難しく、かつ知見の蓄積があったプロセスです。

——それでは、次回は本プロジェクトのLLMエンジニアリングについて詳しく聞いていきたいと思います。

「後編」はこちら＞

細包 愛子（ほそかね あいこ）
日立製作所　デジタルシステム＆サービス
AI＆ソフトウェアサービスビジネスユニット
マネージド＆プラットフォームサービス事業部
AIサービス本部 生成AIサービス開発部 AIサービスG

自然言語処理を中心としたデータ分析案件に従事。報告書などのテキストデータ分析案件に従事。報告書などのテキストデータを活用したトラブル対応支援のAIサービス開発に参画。2024年より生成AIサービス開発部に異動し、業務特化型LLMの開発や適用を推進中。

奥田 太郎（おくだ たろう）
日立製作所　デジタルシステム＆サービス
AI＆ソフトウェアサービスビジネスユニット
デジタル事業開発統括本部 Data＆Design
GenAIソリューション＆ビジネス
GenAIソリューションG

メーカーでエンジニアとしての経歴を持つ。日立では、機械学習モデルをAPIとしてクラウド上にデプロイするサーバレスアーキテクチャのテンプレート設計・開発や、電力分野向けのデータ分析支援や分析などを通じた価値提案を実施。近年では、生成AIの技術検証支援(RAGシステム精度検証、生成AIプロトタイプ開発支援)を実施。

山室 みどり（やまむろ みどり）
日立製作所　デジタルシステム＆サービス
AI&ソフトウェアサービスビジネスユニット
デジタル事業開発統括本部 Data＆Design
GenAIソリューション＆ビジネス GenAIソリューションG

エネルギー関連企業にて設備保守業務を経験した後、データ分析や機械学習モデル構築を通じて、社内課題の解決と現場業務の効率化を推進。 その後、日立製作所のGenerative AI事業推進センタに従事し、鉄道事業をはじめとするさまざまな産業領域において、生成AI活用のユースケース設計からプロトタイプ開発まで担当。

吉田 息吹（よしだ いぶき）
日立製作所　デジタルシステム＆サービス
社会ビジネスユニット　インフラ制御システム事業部
交通制御システム本部　ATOSセンタ

システムエンジニアとして、運行管理システムの列車制御システム設計開発に従事し、システムの検討から機能設計、試験、現地インストール、保守まで幅広く経験。現在は、運用・保守におけるAIエージェント開発プロジェクトへの参画や、インフラ向けシステム開発の高効率化に向けた生成AI活用推進にも取り組んでいる。