Slide 1

Slide 1 text

Autonomous Driving with E2E and Generative AI 3⼈で1000GPU超を統合運⽤する? マルチクラウド&オンプレを跨ぐ、構築と運⽤のリアル! Platform Engineering Kaigi 2026 Turing 株式会社 ⼤⼾ ⼀希 CFP提出時(2026-06時点)と状況が⼀部変わったため、Proposalと内容が⼀部異なるところがあります © 2026 TURING, INC.

Slide 2

Slide 2 text

イントロ ⾃⼰紹介 ⼤⼾ ⼀希 Turing 株式会社 Staff Software Engineer Turingでは、GPU学習基盤‧マルチクラウド基盤の設計と運⽤ MLOpsでは、データセット管理‧学習⾼速化‧可観測性を改善に従事 通信事業者でのResearch Engineer(Security / Network)からキャリアを開始 過去には、国内事業者(Security / 事業開発)、外資ベンダー2社(クラウドSA / 海外部署所属 SRE)、国内AI deep tech(ML Platform / 推論基盤)などを経験 2

Slide 3

Slide 3 text

イントロ 今⽇の流れ 会社‧チーム‧学習基盤 話すこと 02 少⼈数運⽤の経緯と限界 少⼈数で複数基盤を運⽤する⼯夫 共通化の判断とAI活⽤の実態 ⾃動化の途中経過と残る判断 03 構成管理と運⽤の⾃動化 01 話さないこと 04 AIエージェントの利⽤実態/ 知識共有 05 まとめ 構築⼿順‧障害対応の詳細 個別の構築‧障害対応は、⼀部をTech Blogで公開 3

Slide 4

Slide 4 text

イントロ 会社紹介 Co-Founder, CEO ⼭本 ⼀成 名称 Turing 株式会社 創業 2021年8⽉20⽇ 将棋AI「Ponanza」開発 将棋名⼈に初めて勝利 HEROZで上場を経験 事業内容 完全⾃動運転 AI の開発 本社 東京都⼤⽥区平和島 代表取締役 ⼭本 ⼀成 写真:CEO ⼭本 ⼀成 ⼤きな産業で世界と戦う 企業を⽬指して 2021年に創業 出典:tur.ing/about/(2026-09-24確認) 資本⾦ 3000万円 社員数 106名 4

Slide 5

Slide 5 text

イントロ ⾃動運転動画 公式動画:youtube.com/watch?v=9GBO0jtLaT0 5

Slide 6

Slide 6 text

イントロ 組織紹介 ⾃動運転の開発 第1グループ 第2グループ 第3グループ 第4グループ Driving AI Driving System インフラ MLOps モデル開発 Edge/ 組み込み 学習基盤 開発効率向上 出典:jobs.tur.ing/company/organization/ (2026-09-24現在) 2026/7 にインフラ専任へ (2025/10 MLOpsとして採⽤) 6

Slide 7

Slide 7 text

イントロ 既存環境関連業務 チーム紹介 4つの学習基盤の運⽤‧障害対応 4 他チームからの機能追加要望への対応 ⼈のインフラチーム タイトルの3⼈はCFP提出時の体制 既存環境での他チームとの連携 次期GPU計算基盤に関する活動 オンプレミスに強みのある エンジニア中⼼に、次期基盤の 構築関連業務にも注⼒ 参考:Turing TechTalk #36 turipo.tur.ing/LpxotJKK/ 7

Slide 8

Slide 8 text

イントロ 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

Slide 9

Slide 9 text

イントロ データの流れ 整形済み⾛⾏データ データセット⽣成 学習データ 動画‧ログ ∕ 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

Slide 10

Slide 10 text

本題 少⼈数で、要望に応える余⼒を作る 02 少⼈数運⽤の経緯と限界 なぜ、改善に使える時間が⾜りなかったか 03 構成管理と運⽤の⾃動化 何を揃え、どこに環境差を残したか 04 AIエージェントの利⽤実態と知識共有 運⽤者に残る判断と、利⽤者に必要な知識は何か これまでの取り組みをPlatform Engineeringの実践として振り返る(Platform Engineering は社内認知は低い) 10

Slide 11

Slide 11 text

経緯と限界 チームとクラスター数の変遷 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

Slide 12

Slide 12 text

経緯と限界 計算基盤の⽤途 ⽤途 運⽤の実態 社内の学習基盤 ⾼額なGPUを ⽌めたままにしたくない 顧客向けサービスや 推論を動かす基盤ではない 24時間365⽇の対応保証や、正式なSLOを⽰すものではない 勤務時間外も⻑時間の学習が続く 停⽌は学習‧開発の遅れにつながる 12

Slide 13

Slide 13 text

経緯と限界 学習‧実験に集中できる基盤の提供 GPU使⽤率の推移(社内ダッシュボード∕2026年8⽉) GC1 AWS GMO GCP 障害‧計画停⽌で GPU使⽤率が低下 利⽤上の制約も学習の妨げに データ配置を最適化 コスト‧権限を考えて配置 安定稼働を維持 迅速な復旧で学習中断を抑制 利⽤者ニーズに対応 機能改善で試⾏錯誤を⽀援 環境の増加で運⽤負荷が増⼤し、機能要望も増えたため GC1‧GMOを含めた運⽤の効率化が急務に 13

Slide 14

Slide 14 text

構成管理と⾃動化 GC1‧GMOでも⾃動化を進める GC1 GMO オンプレ 国内 IaaS 先⾏担当者が構築 AWS GCP パブリッククラウド 現環境は⼤⼾が構築(1⼈で担当) 既存環境へ展開 IaC‧CI/CDを整備済 GCPの構築‧運⽤はブログで公開 AWSの詳細も近⽇公開予定 GCP構築‧運⽤の記事:zenn.dev/turing_motors/articles/fd34d82e0e56d7 14

Slide 15

Slide 15 text

構成管理と⾃動化 AWS/ GCP で実現できていたこと 構成をコード化 (Gitで管理) CI/CD (GitHub Actions) AI Agent (Claude/ Devin) 障害調査 (Datadog/ SSH) 構成変更 (失敗はSlack通知) GC1‧GMOへの展開と、調査から実⾏までの連携を進める 社内では、業務に必要なあらゆるAIサービスを会社負担利⽤でき( Turing Unlimited AI制度 )、Devin なども整備されている 15

Slide 16

Slide 16 text

構成管理と⾃動化 共通化できない部分 GC1‧GMO AWS‧GCP 物理基盤‧提供側の制約 サービス仕様による制約 Turingだけでは変更できない範囲も 例:FWルール設定変更など Terraform / Terragruntで構成を変更 マネージドサービスの仕様には制約 同じにできない部分は受け⼊れ、できる範囲で構成変更を共通化 16

Slide 17

Slide 17 text

構成管理と⾃動化 ノード内の構成変更を3層に分ける 01 02 03 Boot image 再起動を伴う基本構成 カーネル‧ドライバなど Startup script ノード固有の初期化 マウント‧NIC‧Account DB接続など Ansible 稼働中の設定変更 原則、ジョブを⽌めずに適⽤ 17

Slide 18

Slide 18 text

構成管理と⾃動化 設計思想は揃え、実装は環境に合わせる 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

Slide 19

Slide 19 text

構成管理と⾃動化 実⾏中の学習ジョブを中断せずに変更する Boot image / Startup scriptの変更(クラウドの例) 新規割当を停⽌ (Drain) ジョブ終了を待つ VMの再作成 復旧 再起動が不要な設定変更 稼働中ノードへAnsibleで適⽤ mainへのマージ時に⾃動実⾏ 技術状態の基準⽇:2026-09-24 GC1‧GMOは変更時の⾃動適⽤を 整備予定∕⼿動適⽤の部分が残る 19

Slide 20

Slide 20 text

構成管理と⾃動化 再作成されるVMへの設定変更 ノードを置換 AWS‧GCP 適⽤版を確認 設定を適⽤ 動作を確認 1. 適⽤状況を定期確認(AWSは5分ごと) 2. 最新のplaybookが適⽤済みか確認 3. 未適⽤のノードにplaybookを適⽤ GC1‧GMOでは、再作成後の定期再適⽤は⾏わない ノード交換のたびに、ディスクが初期化される構成ではない 再構成はインフラチームが計画する作業で、頻度も低い 20

Slide 21

Slide 21 text

構成管理と⾃動化 障害調査業務の効率化 Datadog 監視 監視設定:Terraform Datadog Agent:Ansible ランブック 対応⼿順 ⼈とAIが 調査 監視と⼿順はセットで整備 (ex. ゾンビプロセス発⽣やOOMと学習 ジョブの関連を調査) 障害記録(Notion)からランブック(Markdown)を作り 次の調査に活⽤する 21

Slide 22

Slide 22 text

構成管理と⾃動化 課題解決までAIを活⽤する構想 DevinとSemaphore-UIの連携は実装中(⼀部実現) Semaphore-UI インフラチーム⽤ AIエージェント 他チーム⽤ Devin 未確⽴のランブック または影響が⼤きい操作 ⼈が判断 承認後に実⾏ 定義済みの定型作業 ⾃動実⾏ 都度承認不要 Devinにroot権限や、クラウドの強い変更権限は持たせない 参考: Semaphore-UI(GUI/ APIで複数の⾃動化ツールを呼び出せるツール) 22

Slide 23

Slide 23 text

AIエージェントの利用実態 MLエンジニアが⾃分で⼀次調査できる AWS‧GCPで利⽤開始 GC1‧GMOは引き続き インフラチームへ依頼 Slackで依頼 Devinが調査 Datadog‧ノードへの SSH(コマンド制限あり) ノードへのログインはクラウドの⼀部のみ∕許可したコマンドで調査 23

Slide 24

Slide 24 text

AIエージェントの利⽤実態 調査回答の先に必要なこと 回答あり 約97% Semaphore-UI連携の実現で ある程度解決する予定 原因の⾒当がついても、 復旧を実⾏する権限はない Devinの回答例(9/15) 66 / 68件 Devinだけで決着 約26% 18 / 68件 社内Slack 68スレッド|4/15〜9/9(2026年)、9/15集計|⼯数削減率ではない 24

Slide 25

Slide 25 text

AIエージェントの利⽤実態 回答結果の解釈には知識が要る ストレージやネットワークの前提を 知らないと、次の確認が難しい Devinの調査途中の回答(抜粋) 最終診断ではない インフラチームが 改めて調査することも 25

Slide 26

Slide 26 text

AIエージェントの利⽤実態 PRを作れても、採否の判断は残る そのままでは、運⽤効率向上の 銀の弾丸にはなり得ない 良かったこと 運⽤者に残ったこと 利⽤者の要望から、 Devinが実装案‧PRを作れる 共有基盤への影響と保守負担を確認 採⽤‧修正‧不採⽤を判断する 例:⼀時領域の変更案は不採⽤にし、要望には別実装で対応した 影響を確認する分、利⽤者からは対応が遅く⾒えることもある 26

Slide 27

Slide 27 text

利⽤者との知識共有 効率的な基盤運⽤とは? 登壇者が観察した⼀部の⾏動(私⾒) ユーザ内で⾃律的に運⽤が 回るのが最も好ましい 27

Slide 28

Slide 28 text

利⽤者との知識共有 各環境のユーザーガイドを整備 AWS ⼈もAIも参照できるよう、ドキュメントの整備を進める GCP 28

Slide 29

Slide 29 text

利⽤者との知識共有 社内インフラ勉強会の実施 次回は「クラウドとは?」を予定 ネットワーク ストレージ 資料はコーディングエージェントにも渡せる形で配布 社内勉強会資料の表紙 29

Slide 30

Slide 30 text

まとめ 仕組みは組み上げつつあるが、道半ば 整えてきた⼟台 ● ● ● ● 構成をコードで管理 監視とランブック 利⽤者⾃⾝による⼀次調査 ドキュメントの充実/ 知⾒共有 全環境への展開と、実⾏系の連携は引き続き整備中 引き続き進めること ● ● ● GC1‧GMOへの構成管理の展開 DevinとSemaphore UIの連携を 運⽤へ 知⾒共有の継続的な実施 30

Slide 31

Slide 31 text

まとめ ⾃動化への道のりは、思っていたより遠い ● ● ● 環境差を受け⼊れ、共通化する範囲を決める 要望と運⽤負担を⾒て、採否を判断する 利⽤者と、基盤を使うための知識を共有する 発表までに形にしたかったが、想定外のトラブルが続いた ⾏動指針:tur.ing/values/ 31

Slide 32

Slide 32 text

最後に 私たちと⼀緒に働きませんか? SRE‧クラウドの経験を GPU基盤の運⽤改善へ ML Platform Engineering‧SRE (GPUクラスタ) インフラエンジニア 募集要項‧応募 jobs.tur.ing 定期的に試乗会を開催 turing.connpass.com 32