3人で1000GPU超を統合運用する？マルチクラウド＆オンプレを跨ぐ、構築と運用のリアル！

Turingでは、完全自動運転AIの開発を支える1,000基超のGPU学習基盤を、少人数のインフラチームで運用しています。対象は、オンプレミスのGC1、国内IaaSのGMO クラウド、AWS、Google Cloudの4環境です。チームはCFP提出時の3人から現在は4人になりましたが、基盤の拡大や障害対応と並行して、運用改善やMLエンジニアの要望に応える時間をどう確保するかが課題になっています。
本セッションでは、その余力を作るために進めてきた構成管理、自動化、AIエージェントの活用を紹介します。AWS・Google Cloudで整えたIaCやCI/CDを既存環境にも広げる中で、Boot image・Startup script・Ansibleの役割をどう分け、どこを共通化し、どこに環境ごとの違いを残したのか。学習ジョブへの影響を抑えながら変更を届けるための判断を共有します。
また、Datadogとランブック、Devinによる一次調査、Semaphore UIを介した定型作業の実行に向けた取り組みも紹介します。利用者自身が調査を始め、実装案を作れるようになった一方で、回答の解釈や共有基盤への影響確認、提案の採否判断は運用者に残りました。ユーザーガイドや社内勉強会を通じて、利用者と基盤の前提知識を共有する活動にも触れます。
自動化はまだ完成していません。想定外のトラブルや、仕組みを作るだけでは解決しなかった課題を含め、少人数で運用を続けながら改善を進める過程を、Platform Engineeringの実践として振り返ります。

Transcript

1. Autonomous Driving with E2E and Generative AI 3⼈で1000GPU超を統合運⽤する？ マルチクラウド＆オンプレを跨ぐ、構築と運⽤のリアル！ Platform Engineering Kaigi 2026 Turing 株式会社 ⼤⼾ ⼀希 CFP提出時(2026-06時点)と状況が⼀部変わったため、Proposalと内容が⼀部異なるところがあります © 2026 TURING, INC.
2. イントロ ⾃⼰紹介 ⼤⼾ ⼀希 Turing 株式会社 Staff Software Engineer Turingでは、GPU学習基盤‧マルチクラウド基盤の設計と運⽤ MLOpsでは、データセット管理‧学習⾼速化‧可観測性を改善に従事 通信事業者でのResearch Engineer（Security / Network）からキャリアを開始 過去には、国内事業者（Security / 事業開発）、外資ベンダー2社（クラウドSA / 海外部署所属 SRE）、国内AI deep tech（ML Platform / 推論基盤）などを経験 2
3. イントロ 今⽇の流れ 会社‧チーム‧学習基盤 話すこと 02 少⼈数運⽤の経緯と限界 少⼈数で複数基盤を運⽤する⼯夫 共通化の判断とAI活⽤の実態 ⾃動化の途中経過と残る判断 03 構成管理と運⽤の⾃動化 01 話さないこと 04 AIエージェントの利⽤実態/ 知識共有 05 まとめ 構築⼿順‧障害対応の詳細 個別の構築‧障害対応は、⼀部をTech Blogで公開 3
4. イントロ 会社紹介 Co-Founder, CEO ⼭本 ⼀成 名称 Turing 株式会社 創業 2021年8⽉20⽇ 将棋AI「Ponanza」開発 将棋名⼈に初めて勝利 HEROZで上場を経験 事業内容 完全⾃動運転 AI の開発 本社 東京都⼤⽥区平和島 代表取締役 ⼭本 ⼀成 写真：CEO ⼭本 ⼀成 ⼤きな産業で世界と戦う 企業を⽬指して 2021年に創業 出典：tur.ing/about/（2026-09-24確認） 資本⾦ 3000万円 社員数 106名 4
5. イントロ ⾃動運転動画 公式動画：youtube.com/watch?v=9GBO0jtLaT0 5
6. イントロ 組織紹介 ⾃動運転の開発 第1グループ 第2グループ 第3グループ 第4グループ Driving AI Driving System インフラ MLOps モデル開発 Edge/ 組み込み 学習基盤 開発効率向上 出典：jobs.tur.ing/company/organization/ （2026-09-24現在） 2026/7 にインフラ専任へ （2025/10 MLOpsとして採⽤） 6
7. イントロ 既存環境関連業務 チーム紹介 4つの学習基盤の運⽤‧障害対応 4 他チームからの機能追加要望への対応 ⼈のインフラチーム タイトルの3⼈はCFP提出時の体制 既存環境での他チームとの連携 次期GPU計算基盤に関する活動 オンプレミスに強みのある エンジニア中⼼に、次期基盤の 構築関連業務にも注⼒ 参考：Turing TechTalk #36 turipo.tur.ing/LpxotJKK/ 7
8. イントロ TuringのGPUインフラ 1000基超 Gaggle GPU / 全環境でSlurm 国内 IaaS 96 オンプレ GMO クラウド AWS 以降、Gaggleは「GC1」GMO クラウドは「GMO」 Google Cloudは「GCP」と略記 パブリッククラウド Google Cloud 240 パブリッククラウド 単位：GPU基数｜社内資料‧2026-09-24時点 (正確な全量は、社内ポリシーにより⾮公開) 参考：Slurm（オープンソース ワークロード マネージャー）/ GMO GPU クラウド（GPUベアメタルサービス） 8
9. イントロ データの流れ 整形済み⾛⾏データ データセット⽣成 学習データ 動画‧ログ ∕ Amazon S3 Databricks Amazon S3 各環境でデータを取得 GC1 GMO AWS GCP オンプレ 国内 IaaS パブリッククラウド パブリッククラウド Slurm Slurm Slurm Slurm ベアメタル ベアメタル SageMaker HyperPod Compute Engine マウント マウント マウント マウント Lustre Lustre Lustre Lustre 参考：turipo.tur.ing/techtalk42、turipo.tur.ing/techtalk45/ インフラチーム担当 9
10. 本題 少⼈数で、要望に応える余⼒を作る 02 少⼈数運⽤の経緯と限界 なぜ、改善に使える時間が⾜りなかったか 03 構成管理と運⽤の⾃動化 何を揃え、どこに環境差を残したか 04 AIエージェントの利⽤実態と知識共有 運⽤者に残る判断と、利⽤者に必要な知識は何か これまでの取り組みをPlatform Engineeringの実践として振り返る（Platform Engineering は社内認知は低い） 10
11. 経緯と限界 チームとクラスター数の変遷 2024/4 2025/10 期間省略 1⼈ ⼈数 クラスター数 1 チーム ⽴ち上げ 2⼈ 2026/1 2⼈ 2026/4 2⼈ 3⼈ 2026/8 4⼈ … 3 … ⼤⼾⼊社 2 AWS撤退 3 GCP構築 MLOpsとして クラウドを⽀援 GCP 2026/5 GC1 / GMO AWS GC1 / GMO GC1 / GMO GCP 主な時点を抜粋∕横軸の間隔は経過⽉数に⽐例しない（同⼀クラスターの再構築は省略） 4 4 AWS構築 チーム増員 ⼤⼾が兼務開始 中途社員が⼊社 ⼤⼾は7⽉に専任 GC1 / GMO AWS / GCP GC1 / GMO AWS / GCP 11
12. 経緯と限界 計算基盤の⽤途 ⽤途 運⽤の実態 社内の学習基盤 ⾼額なGPUを ⽌めたままにしたくない 顧客向けサービスや 推論を動かす基盤ではない 24時間365⽇の対応保証や、正式なSLOを⽰すものではない 勤務時間外も⻑時間の学習が続く 停⽌は学習‧開発の遅れにつながる 12
13. 経緯と限界 学習‧実験に集中できる基盤の提供 GPU使⽤率の推移（社内ダッシュボード∕2026年8⽉） GC1 AWS GMO GCP 障害‧計画停⽌で GPU使⽤率が低下 利⽤上の制約も学習の妨げに データ配置を最適化 コスト‧権限を考えて配置 安定稼働を維持 迅速な復旧で学習中断を抑制 利⽤者ニーズに対応 機能改善で試⾏錯誤を⽀援 環境の増加で運⽤負荷が増⼤し、機能要望も増えたため GC1‧GMOを含めた運⽤の効率化が急務に 13
14. 構成管理と⾃動化 GC1‧GMOでも⾃動化を進める GC1 GMO オンプレ 国内 IaaS 先⾏担当者が構築 AWS GCP パブリッククラウド 現環境は⼤⼾が構築（1⼈で担当） 既存環境へ展開 IaC‧CI/CDを整備済 GCPの構築‧運⽤はブログで公開 AWSの詳細も近⽇公開予定 GCP構築‧運⽤の記事：zenn.dev/turing_motors/articles/fd34d82e0e56d7 14
15. 構成管理と⾃動化 AWS/ GCP で実現できていたこと 構成をコード化 (Gitで管理) CI/CD (GitHub Actions) AI Agent (Claude/ Devin) 障害調査 (Datadog/ SSH) 構成変更 (失敗はSlack通知) GC1‧GMOへの展開と、調査から実⾏までの連携を進める 社内では、業務に必要なあらゆるAIサービスを会社負担利⽤でき( Turing Unlimited AI制度 )、Devin なども整備されている 15
16. 構成管理と⾃動化 共通化できない部分 GC1‧GMO AWS‧GCP 物理基盤‧提供側の制約 サービス仕様による制約 Turingだけでは変更できない範囲も 例：FWルール設定変更など Terraform / Terragruntで構成を変更 マネージドサービスの仕様には制約 同じにできない部分は受け⼊れ、できる範囲で構成変更を共通化 16
17. 構成管理と⾃動化 ノード内の構成変更を3層に分ける 01 02 03 Boot image 再起動を伴う基本構成 カーネル‧ドライバなど Startup script ノード固有の初期化 マウント‧NIC‧Account DB接続など Ansible 稼働中の設定変更 原則、ジョブを⽌めずに適⽤ 17
18. 構成管理と⾃動化 設計思想は揃え、実装は環境に合わせる GC1 Boot image Startup script Ansible NVIDIA DGX OS なし 段階適⽤予定 GMO AWS GCP 既存OS Packer AMI Packer image なし スクリプト ＋Ansible スクリプト ＋Ansible 段階適⽤中 未適⽤を検出 して適⽤ 未適⽤を検出 して適⽤ AWS：SageMaker HyperPodでノードを管理 GCP：Cluster ToolkitでVMを構築 18
19. 構成管理と⾃動化 実⾏中の学習ジョブを中断せずに変更する Boot image / Startup scriptの変更（クラウドの例） 新規割当を停⽌ (Drain) ジョブ終了を待つ VMの再作成 復旧 再起動が不要な設定変更 稼働中ノードへAnsibleで適⽤ mainへのマージ時に⾃動実⾏ 技術状態の基準⽇：2026-09-24 GC1‧GMOは変更時の⾃動適⽤を 整備予定∕⼿動適⽤の部分が残る 19
20. 構成管理と⾃動化 再作成されるVMへの設定変更 ノードを置換 AWS‧GCP 適⽤版を確認 設定を適⽤ 動作を確認 1. 適⽤状況を定期確認（AWSは5分ごと） 2. 最新のplaybookが適⽤済みか確認 3. 未適⽤のノードにplaybookを適⽤ GC1‧GMOでは、再作成後の定期再適⽤は⾏わない ノード交換のたびに、ディスクが初期化される構成ではない 再構成はインフラチームが計画する作業で、頻度も低い 20
21. 構成管理と⾃動化 障害調査業務の効率化 Datadog 監視 監視設定：Terraform Datadog Agent：Ansible ランブック 対応⼿順 ⼈とAIが 調査 監視と⼿順はセットで整備 (ex. ゾンビプロセス発⽣やOOMと学習 ジョブの関連を調査) 障害記録（Notion）からランブック（Markdown）を作り 次の調査に活⽤する 21
22. 構成管理と⾃動化 課題解決までAIを活⽤する構想 DevinとSemaphore-UIの連携は実装中（⼀部実現） Semaphore-UI インフラチーム⽤ AIエージェント 他チーム⽤ Devin 未確⽴のランブック または影響が⼤きい操作 ⼈が判断 承認後に実⾏ 定義済みの定型作業 ⾃動実⾏ 都度承認不要 Devinにroot権限や、クラウドの強い変更権限は持たせない 参考: Semaphore-UI（GUI/ APIで複数の⾃動化ツールを呼び出せるツール） 22
23. AIエージェントの利用実態 MLエンジニアが⾃分で⼀次調査できる AWS‧GCPで利⽤開始 GC1‧GMOは引き続き インフラチームへ依頼 Slackで依頼 Devinが調査 Datadog‧ノードへの SSH（コマンド制限あり） ノードへのログインはクラウドの⼀部のみ∕許可したコマンドで調査 23
24. AIエージェントの利⽤実態 調査回答の先に必要なこと 回答あり 約97% Semaphore-UI連携の実現で ある程度解決する予定 原因の⾒当がついても、 復旧を実⾏する権限はない Devinの回答例（9/15） 66 / 68件 Devinだけで決着 約26% 18 / 68件 社内Slack 68スレッド｜4/15〜9/9（2026年）、9/15集計｜⼯数削減率ではない 24
25. AIエージェントの利⽤実態 回答結果の解釈には知識が要る ストレージやネットワークの前提を 知らないと、次の確認が難しい Devinの調査途中の回答（抜粋） 最終診断ではない インフラチームが 改めて調査することも 25
26. AIエージェントの利⽤実態 PRを作れても、採否の判断は残る そのままでは、運⽤効率向上の 銀の弾丸にはなり得ない 良かったこと 運⽤者に残ったこと 利⽤者の要望から、 Devinが実装案‧PRを作れる 共有基盤への影響と保守負担を確認 採⽤‧修正‧不採⽤を判断する 例：⼀時領域の変更案は不採⽤にし、要望には別実装で対応した 影響を確認する分、利⽤者からは対応が遅く⾒えることもある 26
27. 利⽤者との知識共有 効率的な基盤運⽤とは？ 登壇者が観察した⼀部の⾏動(私⾒) ユーザ内で⾃律的に運⽤が 回るのが最も好ましい 27
28. 利⽤者との知識共有 各環境のユーザーガイドを整備 AWS ⼈もAIも参照できるよう、ドキュメントの整備を進める GCP 28
29. 利⽤者との知識共有 社内インフラ勉強会の実施 次回は「クラウドとは？」を予定 ネットワーク ストレージ 資料はコーディングエージェントにも渡せる形で配布 社内勉強会資料の表紙 29
30. まとめ 仕組みは組み上げつつあるが、道半ば 整えてきた⼟台 • • • • 構成をコードで管理 監視とランブック 利⽤者⾃⾝による⼀次調査 ドキュメントの充実/ 知⾒共有 全環境への展開と、実⾏系の連携は引き続き整備中 引き続き進めること • • • GC1‧GMOへの構成管理の展開 DevinとSemaphore UIの連携を 運⽤へ 知⾒共有の継続的な実施 30
31. まとめ ⾃動化への道のりは、思っていたより遠い • • • 環境差を受け⼊れ、共通化する範囲を決める 要望と運⽤負担を⾒て、採否を判断する 利⽤者と、基盤を使うための知識を共有する 発表までに形にしたかったが、想定外のトラブルが続いた ⾏動指針：tur.ing/values/ 31
32. 最後に 私たちと⼀緒に働きませんか？ SRE‧クラウドの経験を GPU基盤の運⽤改善へ ML Platform Engineering‧SRE （GPUクラスタ） インフラエンジニア 募集要項‧応募 jobs.tur.ing 定期的に試乗会を開催 turing.connpass.com 32