ドイツ鉄道のAIエージェント100万体構想はAmazon Bedrock AgentCoreでどう実現されるか - AWS Summit Hamburg 2026 参加レポート
ベルリンオフィスの小西です。
2026年5月20日、ドイツ・ハンブルクで開催されたAWS Summit Hamburgに参加してきました。
講演やブース、どこを見てもAI一色。印象に残ったのが、Deutsche Bahn（以下DB、ドイツ鉄道）によるAIエージェント活用のセッションでした。
講演タイトルは「Deutsche BahnにおけるAIエージェント: Amazon Bedrock AgentCoreのベストプラクティス」。
前半はAWSのSimon氏によるBedrock AgentCoreのベストプラクティス紹介、後半はDBによる実践事例という構成でした。
AgentCoreについてはすでに多くの弊社ブログが上がっているため（参照）、この記事では ドイツ鉄道がどのようにBedrock AgentCoreを導入したか の話を中心にまとめようと思います。
Deutsche Bahnとは
Deutsche Bahnはドイツの国有鉄道会社で、従業員23万人、子会社880以上のヨーロッパ最大級の鉄道事業者です。
今回の登壇者はDB Systel（DBグループのITサービス子会社）のRené Schneider氏（↑の写真）。Senior Vice President, Infrastructureとして、DBグループ全体のインフラ運用を統括する立場の方です。
Deutsche Bahnが抱える課題
まずはDBが置かれている状況を少し補足。
DBは近年 深刻な運行品質の低下 に直面中。
2025年の長距離列車の定時運行率は過去最悪の60.1%でした。改めて数字で見るとなかなか厳しい。実際、ドイツに住んでいると電車の遅延やキャンセルは日常茶飯事です...。
原因はインフラの老朽化、設備維持費や投資の後回し、大規模改修工事にともなう速度制限や路線閉鎖などなど。
問題が増えるばかりのインフラに対し簡単に人手は増やせず、むしろ効率化が急務ということが、AIエージェントの導入の推進力になりました。
AIエージェントへの取り組みの経緯
Schneider氏によると、DBがエージェントAIの検討を始めたのは2025年11月。グループCIOから「将来的に100万のエージェントをガバナンスする方法を考えて」というお題が降ってきたとのこと。
2026年1月にPoCを開始して。そして約2ヶ月後には本番稼働を達成する異例の早さ。
本番ユースケース: 中央運行管理システムの自動パッチ適用
対象システム
PoCの対象となったのは、ドイツ全土の列車運行を管理する中央運行管理・オーケストレーションシステムです。34,000km以上の軌道、5,400以上の駅、1日あたり20,000本以上の列車のすべてを束ねるDBの基幹システムです。Schneider氏いわく「この分野に本気で取り組むには小さなシステムでは意味がない」と。
課題
システムを支えるサーバーは2,500台以上。セキュリティパッチや機能パッチをほぼ毎日適用する必要がありますが、これだけの台数に対して、複雑なインターフェースや依存関係を考慮しながらパッチ当てするのは、人手では膨大な工数がかかります。
エージェント構成
DBが採用したのは「agents-as-tools」パターン。
構成は以下の通り。
- Orchestrator Agent: Amazon SQS経由でパッチ要求のタスクを受信し、全体のフローを制御する
- Triage Agent: パッチの影響範囲や規模を分析し、サマリーを作成する
- Human-in-the-loop: Triage Agentのサマリーをもとに、人間が自動適用か手動対応かを判断する
- Patching Agent: 承認後、MCP Server経由でEC2インスタンスにパッチを適用する。人間と違い、2,500台のサーバーを同時並行で処理できる
完全自動化ではなくHuman-in-the-loopを組み込んでいます。エージェントが影響を分析し、人間が最終判断を下す役割分担が機能しているとのことでした。
また、フレームワークにはAWSのオープンソースフレームワークであるStrands Agentsを採用しています。「将来的にAWSから別のプロバイダーに移行する可能性も考慮して、オープンソースのフレームワークを選んだ」ということでベンダーロックインを避けたかったようです。
Strands Agentsについては、弊社記事もあわせてご覧ください。
AIエージェント・エコシステムの設計思想
この成功を受けて、DBはグループ全体でAIエージェントを運用するためのエコシステム構築に進んでいます。目標は 将来的に100万エージェントを運用できる基盤 の整備です。前半AWS側の発表でも「中央レジストリ」や「プラットフォームチームへの投資」が推奨されていましたが、DBは全社規模で実践しようとしています。
「デジタルオフィスワーカー」というメンタルモデル
セッションで特に興味深かったのが AIエージェントを「デジタルオフィスワーカー」として扱う 考え方です。
人間の社員と同じように、エージェントにも以下のライフサイクルがあるとしています:
- Hiring（採用）: エージェントの作成。スキルや役割を定義する
- Onboarding: 環境への接続、権限の付与
- Collaboration: Microsoft TeamsやAmazon Qを通じた社員とのやり取り
- Feedback: パフォーマンスの評価と改善
23万人の社員がTeams上で必要なエージェントを都度 採用、教育し、昇格させながら業務を進める、そんな世界観を描いているようでした。
2種類のエージェント
DBでは、エージェントを2種類に分類しています。
1. On-behalf Agent（代行型）
ユーザー自身のIDと権限で動作するエージェントです。メールの作成、カレンダー管理、会議の議事録作成といったタスクを担当します。ユーザーがPCをシャットダウンすると、このエージェントも停止します。ユーザーの「分身」としての位置づけです。
2. Enterprise Agent（企業型）
こちらは独自のIDと権限を持ち、従業員と同じようにID管理やアクセス制御の対象となるエージェントです。ユーザーの操作に依存せず常時稼働し、先述の運行管理システムのパッチ適用のような企業レベルのタスクを自律的に実行します。
この分類により「誰の権限で動くのか」「いつ停止するのか」が明確になります。
セキュリティとガバナンス
100万エージェントを運用するとなると、セキュリティとガバナンスが課題になります。
ゼロトラストの原則
「すべてのエージェントは侵害されている前提で扱う」ゼロトラストの考え方に則り、6層のセーフティネットを設け、技術的なセキュリティ（認証・認可、暗号化、ネットワーク分離）に加え、機能的なガードレール（データプライバシー、規制対応）も含まれます。
エージェントカード
各エージェントには「エージェントカード」と呼ばれるIDカード的なものが付与されます。GoogleのA2AプロトコルのAgent Cardに基づいた仕組みで、ここに オーナー（責任者） が明記されます。
エージェントが何か問題を起こした場合、責任を負うのはエージェントではなく オーナーである人間 です。100万体のエージェントがいても、責任の所在は必ず一人の人間に帰結するこの原則はシンプルですが重要です。
ネットワーク分離
エージェント生成段階ではアクセス権が一切ありません。DB内のどのシステムとも通信できない状態からスタートし、段階的にツールや他のエージェントへのアクセスが付与されていきます。人間の新入社員の権限が最初は小さいのと似ています。
自律レベルモデル
DBでは、自動運転のレベル分けの考え方をエージェントにも適用しています。
最初はアシスタントとして支援のみ行うレベルからスタートし、信頼を獲得するにつれて段階的に権限と自律性を拡大していきます。
- まずはアシスタントとして人間の業務を補助
- 「直近の20回のレスポンスがすべて正確だった」→ より多くの責任を付与
- 最終的にはエージェントが自律的に意思決定・実行
Schneider氏は「自動運転と同じで、いきなりLevel 5にはしない」と話していました。
企業ガバナンス階層
ガバナンスは3層構造で管理されています。
- Corporate Level: DBグループ全体に適用されるルール
- Business Unit Level: 880の子会社それぞれの規制対応
- Department Level: 部門固有のガードレール
エージェントカードに所属ビジネスユニットの情報が含まれているため、エージェントは自動的に該当するガードレールの適用を受けます。人間の社員が所属部署のルールに従うのと同じ仕組みを、エージェントにも適用しているわけです。
トレーサビリティ
DBのトレーサビリティは4つの柱で構成されています。
- Task: エージェントが受けたタスクの記録。誰から、何を依頼されたか
- Process: どう処理したか。判断基準、ガードレールの適用状況、エスカレーションの有無
- Result: 最終的な出力
- Next Step: 後続エージェントへの引き渡しやHuman-in-the-loopのトリガー
全エージェントのトレース情報を集約し、ワークフォースの稼働状況をダッシュボードで可視化しています。「AIエージェントの勤怠管理」のようなものらしいです。
今後の展望
Schneider氏は「6ヶ月前はDBの中で誰もAIエージェントの話をしていなかった。それが今はエコシステムが稼働している」と振り返っていました。
そして次の目標は、現在DBが運用している2,500以上のユースケースを、12ヶ月以内にAIエージェントへ移行するとのこと。
最後に
短い時間で盛りだくさんの内容でした。実際このセッションは非常に人気で入場待ち状態。
現実的にはまだまだ課題は山積みなんでしょうが、基幹システムでの実績があるだけに、ただの理想論には聞こえません。DBの今後の改善に一利用者としても期待したいです。
