役員SNS
この規模を、このスピードで、学習を加速する基盤へ。——チューリングのインフラをつくる二人
完全自動運転AIの開発には、膨大な計算力が必要になります。しかし、GPUを確保して並べるだけで、学習が進むわけではありません。データを供給するストレージ、ノードをつなぐネットワーク、OSやドライバ、学習ジョブを管理するソフトウェア。そして、MLエンジニアがそれらを使って実験を進めるための環境。計算資源を実際の学習につなげるには、いくつものレイヤーを横断した設計と改善が必要です。
AIの推論基盤やアプリケーション開発を経験し、学習を支える仕事を求めて入社した大戸さん。長年IaaS基盤を作り、「この規模のインフラを、このスピードで作れるなら」と入社を決めた神尾さん。二人とも、GPU/HPCの専門家としてチューリングに来たわけではありません。これまで培った技術を持ち込みながら、未知の領域へと仕事を広げています。
なぜ、この挑戦を選んだのか。どこまで技術に踏み込み、何を自分たちで変えるのか。そして、次の仲間にどんな強さを求めているのか。二人に聞きました。
学習を支える仕事へ。大きな基盤を作る現場へ。
——まず、チューリングを選んだ理由を教えてください。
大戸：私はこれまで、バックエンドやアプリケーションの開発、SRE、クラウドの技術支援など、いろいろな立場でシステムに関わってきました。
AIディープテック企業では、AIを使ったSaaSの推論基盤や、それに関連するアプリケーションを作っていました。推論側は経験できたのですが、学習側はまだやったことがなかった。次は、学習に関わるソフトウェアやプラットフォームを作りたいと思ったんです。
もう一つの理由は「働き方」です。前職ではフルリモート環境下で海外チームに在籍しており、多くの学びがあった一方で、言語の壁、リモート特有の難しさも実感しました。そのため、対面かつ母国語で細かなニュアンスを共有し、チームで密に議論を深められる環境に身を置きたいと考えたことも、入社の大きな理由です。
——その中で、なぜ自動運転だったのでしょうか。
大戸：車が好きなんです。それに、自分の感覚として、自動車産業は日本にとって「最後の砦」とも思える大きな産業です。その産業が大きく変わるところに、自分の技術と時間を賭けたいと思いました。
好きな分野であること、これまでの経験を活かせること、まだやったことのない挑戦ができること。その三つが重なっていたのがチューリングでした。
神尾：私はヤフーとサイバーエージェントで、長くIaaS基盤を作ってきました。OpenStackを使ったクラウドの開発や運用、仮想化の性能改善などです。
もともとは自分でWebサイトを作って運営していて、もっと大きなサービスがどう動いているかを知りたくてヤフーに入りました。そこから、サービスを支える基盤の側へ仕事が広がっていきました。
——神尾さんにとって、入社の決め手は何でしたか。
神尾：規模とスピードです。「国内でこんなスピード感で、こんなにデカいインフラに触れるところがあるのか」と思ったことが、個人的には決め手でした。
大きいインフラがすでにあることも魅力ですが、それが今まさに大きくなっていて、自分が作る側に入れることが重要でした。IaaSでの経験を使いながら、GPU基盤という新しい領域に取り組める。難しそうだと思いましたし、それがやってみたい理由でもありました。
——大戸さんは、MLOpsとして入社してからインフラへ仕事を広げていますね。
大戸：最初はSlurm（※1）もLustre（※2）も、名前すら聞いたことがありませんでした。使ったことも、触ったこともなかったです。2025年10月にMLOpsとして入社して、最初にAmazon SageMaker HyperPod（※3）に触れた。今振り返ると、それがこの話の始まりだったのかもしれません。
そこから学習基盤に関わる中で、大きなインフラを作っていく話を聞きました。やったことのないことに挑戦したかったし、AIインフラを支える仕事は、AIが進化しても必要とされ続けるのではないか、と個人的に考えていた。そこにも惹かれました。
ただ、インフラチームへ移りたいと思った理由は、規模だけではなかったんです。
※1：Slurm…複数ユーザーで効率よく学習を進めるためのジョブスケジューラ。
※2：Lustre…機械学習分野などで多く利用される、高速なファイルアクセスを提供する分散ファイルシステム。
※3：Amazon SageMaker HyperPod…Slurmクラスタの構築・運用を効率化するAWSのマネージドサービス。
計算資源を、チューリングの学習に合う基盤に。
——ほかには、どんな理由があったのでしょうか。
大戸：MLOpsとして学習する側に近いところにいると、基盤の使い勝手や、学習の進め方に合わせて改善できる部分が見えてきました。
大きなインフラを作ることに加えて、それをチューリングの学習に合う形で使ってもらい、学習効率を高めたかったんです。計算資源があっても、データの準備や環境の使い方で時間がかかれば、実験は思うように進みません。そこをソフトウェアや運用の仕組みも含めて変えたいと思いました。
——その課題を、インフラチームで解決したいと考えた。
大戸：はい。当時のインフラチームは人数が足りず、基盤の構築や維持に対応する中で、利用者にとっての使いやすさや学習の進め方に合わせた改善にまで、十分に手が回らない状況でした。
少なくとも私からは、インフラと、モデルの学習を進めるMLエンジニアの間にあるこの領域に、継続的に踏み込んで改善を進める担い手が足りないように見えたんです。これは会社として解くべき課題で、自分がやってきたアプリケーション開発やSRE、プラットフォーム開発の経験を使えば貢献できると思いました。それもあって、自分からインフラチームに移りたいと伝えました。
神尾：基盤を使う側にいたから、どこに改善の余地があるかが見えていたわけですね。IaaSでも、リソースを提供する側の見方と、使う側の見方には違いがあります。提供側では正常でも、利用者が処理を進めるには手間がかかることがある。提供側と利用者の両方の視点で考えられるのは、大きな強みだと思います。
大戸：そうですね。VMが立っているか、GPUが認識されているかだけでなく、その上で学習が効率よく進んでいるかを見たいです。そのためには、インフラ側だけを変えればいいとも限りません。利用者と話して、ワークロードやデータの使い方を理解したうえで、どこを変えるのが効果的かを考える。そういう仕事がしたかったんです。
——「学習効率を高める」ときには、何を見ているのでしょうか。
大戸：GPUの利用率も見ますが、それだけではありません。ジョブを開始できるまでの待ち時間、データを準備する時間、障害が起きてから再開するまでの時間も、学習の進み方に関わります。
利用者の「遅い」「使いづらい」という言葉から、具体的に何が問題なのかを切り分けたいです。ストレージの性能が足りないのか、環境の準備が複雑なのか、状態が分からず調査に時間がかかるのか。原因によって、必要な改善は変わります。
神尾：基盤の性能を上げても、それが利用者の問題点の解消につながらなければ効果は出にくいですよね。逆に、使い方を聞いたことで、基盤側の設計を変えるべきだと分かることもある。インフラの都合とワークロードの都合を合わせて考えるのが、プラットフォームの仕事だと思います。どちらか一方の知識だけでは決められないので、会話が必要になります。
——大戸さんが入社理由に挙げた、対面で働けることにもつながりますね。
大戸：私にとっては、かなりつながっています。問題がまだ整理できていない段階でも、顔を合わせて話せる。実際にどう使っていて、何に困っているかを、その場で掘り下げられる。基盤を大きくすることと、学習者が使いやすくすることを、同じ仕事として考えられる。その距離感は、このチームで働く魅力です。
学習が止まった。そのとき、どこまで潜れるか。
——利用者の問題を追う中で、技術的にはどのくらい深く入るのでしょうか。
大戸：必要なところまでです。「学習が進まない」という現象でも、原因はアプリケーション、データの読み込み、ネットワークなど、いろいろ考えられます。
AWSのFSx for Lustre（※4）でI/Oの問題が起きたときは、通信経路や接続状態まで調べました。GPU間通信のテストが正常でも、ストレージ通信まで正常だとは判断できなかったんです。途中では、特定のストレージへの書き込み集中を疑いました。でも、データ配置とメトリクスを突き合わせると、その説明は合わない。そこで仮説を変えて、別の層の状態を調べていきました。(参考記事)
※4：Amazon FSx for Lustre…AWS環境でLustreを管理・運用できるフルマネージドサービス。
神尾：仮想化の性能を調べるときも、VMの中だけで答えが出るとは限りません。ホスト側のCPUやメモリ、ストレージ、ネットワークに加えて、仮想化を実現しているハイパーバイザ層のロジックなども大きく影響します。
大事なのは、各層を意識して切り分けていくことです。どの条件で起きて、どの条件では起きないかを確かめる。もっともらしい説明を思いついても、すぐにそれが原因だと決めつけない。観測した結果から、調べる範囲を絞っていきます。
——クラウドでは、自分たちから見えない部分もありますよね。
大戸：あります。そこで、自分たちで観測できることと、サービス側に確認してもらうことを整理します。何が起きていて、何は正常で、どこまで再現できたか。それを持って、クラウド側の担当者と調査を進めます。
見えない部分があるからこそ、こちらで確かめられることを明確にしたい。利用者側の設定や構成で変えられるものがあれば、効果を検証する。マネージドサービスでも、仕組みを理解することは必要です。
神尾：オンプレミスでは、自分で確認・変更できる範囲が広くなります。ただ、触れる場所が多い分、全部を疑っていては時間がかかる。観測した事実を使って切り分ける考え方は共通しています。オンプレミスの経験があると、OSやハードウェアに近い、例えばドライバやファームウェアの問題などにも触れる機会は多いと思います。でも、クラウドやバックエンドでも、必要に応じてその層まで調べてきた人はいます。
大戸：採用でも、環境の名前だけでは判断したくないです。バックエンドの性能問題を追っていたら、OSのI/Oや通信に原因があった。そこで仕組みを理解して、設定やコードを変えた。そういう経験は、この仕事につながります。必要なのは、普段扱っている範囲で説明がつかないときに、その先へ踏み込めることだと思います。
——調査した後は、どこまで担当するのでしょうか。
神尾：実際に何を変えるかまで考えます。設定を直すのか、ソフトウェアの修正が必要なのか、構成を見直すのか。原因を説明できることと、使える状態にすることの両方が必要です。それに、同じ問題が起きたときに、毎回同じ人が調べ直す形にはしたくない。判断に使った情報や手順を残し、仕組みに反映していくことも大事です。
大戸：私も、調査から得た知識は監視や構成管理へ還元していくべきだと考えています。一時的な復旧にとどまらず、次回以降の検知をいかに早めるか、ユーザーのダウンタイムをどう最小化するかまで思考を巡らせたいからです。 時には、根本原因が不明なままでも学習の再開を判断しなければならないことがあります。そのような状況下では、既知の事実と未知の事象を冷静に整理し、原因調査とサービス復旧のための対処を並行して進めるようにしています。
まず動かす。その経験で、次の設計を変える。
——「このスピードで作れる」という魅力は、実際にはどんな仕事に表れていますか。
大戸：Google Cloudでは、240 GPUのSlurmクラスタを約2週間で立ち上げました。確保できた計算資源を、一日でも早く学習に使えるようにする必要がありました。
ただ、2週間で完成形を作れたわけではありません。まず学習を動かせるところまで持っていき、その後の運用で分かったことを使って、構成や運用を改善していきました。(参考記事)
神尾：使われる前に、すべてを予測するのは難しいです。実際の負荷や使い方から初めて分かることがある。そのときに、最初の構成を変更できることが重要になります。速く作ることと、後で変更できること。その両方を考える必要がありますね。
大戸：ただ、インフラでは試すための環境を簡単に用意できないこともあります。オンプレミスなら機材や設備が必要ですし、クラウドでも、検証用のGPUを追加で確保できるとは限りません。確保できてもコストがかかる。セキュリティ上、アクセス権限やデータの持ち出し方にも制約があります。本番と同じ環境をもう一つ作って、気軽に試行錯誤することが難しい場面があるんです。
だから、何をどこまで検証できるかを考える必要があります。小さな環境で確認できる部分、実際の負荷でないと分からない部分を分ける。そのうえで、変更する範囲とタイミング、影響が出たときの対応を決めます。
その結果から、次の設計を変えていく。最初のAWS環境でも、移行や運用で構成管理や観測性の不足に向き合い、そこで得た教訓を、次の環境の設計に活かしました。(参考記事)
神尾：検証できない部分が残るときに、何を根拠に進めるかが難しいですね。コードを元に戻しても、実行中のジョブや書き換わったデータまで元に戻るとは限りません。影響が出る範囲や、復旧に必要な時間まで考える必要があります。
どんな結果なら次へ進み、何が起きたら止めるのか。その判断を、関係者と共有しておく。速く進めるには、確認を省くのではなく、限られた検証の中で何を確かめるべきかを絞り込む技術が必要だと思います
OSのプロビジョニングでも同じです。インストールできるだけでなく、そのノードがクラスタに参加して処理を実行できるか、交換時に同じ状態へ戻せるかまで考えます。
——構築した後の運用まで、設計に含まれているんですね。
神尾：はい。途中で失敗したときに、どの段階まで処理が進んだかを把握できるか、設定変更をどう届けるか、意図した状態になっていると確認できるか。最初に一台で成功した手順を、そのまま台数分繰り返すだけでは運用しきれなくなります。IaaSを作ってきた経験は、そういうところに持ち込めると思います。
大戸：私も、設定をどこに置くかは運用とセットで考えます。イメージに入れるのか、起動時に適用するのか、稼働中に変更できるようにするのか。置き場所によって、変更のために何を止め、何を作り直すかが変わります。
学習を止めずに届けたい変更もあれば、ノードの再作成まで必要な変更もある。その違いを設計に反映したいです。
神尾：管理の仕組みを増やせば解決するわけでもありません。仕組みが増えるほど、理解することも増えるので。
大戸：「Less is more」は、そこでも意識したいですね。必要な機能を備えつつ、状態を理解しやすく、変更しやすい構成にする。自動化そのものを目的にせず、学習や改善に使える時間を増やしたいです。
GPU未経験でも、技術的に強い人と働きたい。
——改めて、どんな人に来てほしいですか。
大戸：GPUやSlurmを使った経験の有無よりも、何か一つ、技術的に深く取り組んできたものがある人です。バックエンドでも、クラウドでも、オンプレでも構いません。
必要ならOSやネットワーク、ストレージまで調べ、理解したことをコードや設定に反映してきた。さらに、その変更が利用者の問題を解決したかまで確かめてきた。そういう経験を聞きたいです。
神尾：自分が使っているものの中で、何が起きているかに関心を持てる人ですね。用意された方法だけでは解けないときに、もう少し中を見てみようと思えるか。自分もIaaSでは、仮想化ソフトウェアやOS、ハードウェアに近い部分まで扱ってきました。GPU基盤でも、知っている範囲で答えがなければ、その先を調べる必要があります。その過程を楽しめる人と働きたいです。
——「GPU未経験でも歓迎」と、技術的な要求水準はどう両立しますか。
大戸：私自身、SlurmもLustreも知らないところから始めました。ただ、それまでの開発やSREの経験が土台になっていたのは確かです。何を観測するか、どう問題を分けるか、変更をどう管理するか。その経験に新しい知識をつなげてきました。
だから、最初から全部知っていることは求めません。一方で、新しいことを学んで判断し、実装を進める力は期待します。ここに来れば自然に専門性が身につく、ということではないと思っています。
神尾：使ったツールの名前より、具体的な問題の話を聞きたいです。最初に何を疑って、何を計測して、どこで考えを変えて、最後に何を直したのか。
仮説が外れた話でもいいんです。その後にどう調べ直したかに、その人の考え方が出ます。そういう経験を聞くと、一緒に仕事をする姿を想像しやすいですね。
——公開記事を読んで、「このレベルにはまだ届かない」と感じる人にはどう伝えたいですか。
大戸：最初から全部理解できる必要はありません。ただ、「ここは自分の経験とつながる」「自分なら次にこれを調べたい」と思える部分があるといいですね。
これまでの経験や学び方から、数か月後には私達と同じくらい踏み込んだ技術的な議論ができるようになり、ゆくゆくはチームの施策をリードしていただけそうか。そこを見たいと思っています。
同時に、私たちが持っていない経験や異なる視点を持ち込み、チームに新たな風を吹き込んでくれるような方とぜひ一緒に働きたいです。
技術を深く調べることだけが強さではありません。利用者の困りごとを理解し、どこに手を入れるべきかを見極めて改善を進める力も重要です。私がインフラチームへ移った理由も、まさにそこでした。
神尾：GPU未経験だから、自分の経験は使えないと思わなくてもいいです。OS、ネットワーク、ストレージ、分散システムなど、つながるものはあります。
その土台を使って新しい領域へ入る意欲があるなら、ぜひ話を聞いてみたいですね。分からないことを整理し、ほかの人の知識も借りながら進められることも、技術者としての強さだと思います。
AIが進化する今、自分の判断で前に進める仕事を。
——少人数で改善を進めるために、どんなことに取り組んでいますか。
大戸：構成管理や自動化に加えて、AIエージェントの活用も進めています。今年（2026年）の9月に開催された「Platform Engineering Kaigi」では、一次調査や定型作業の実行に向けた取り組みを紹介しました。
調査や実装を進める手段は増えています。一方で、回答の解釈や、共有基盤への影響確認、提案を採用するかという判断は必要です。(参考登壇)
神尾：CI/CDや自動テスト、隔離された実行環境が整っていれば、AIエージェントにコードを変更してもらい、テストして直すサイクルを速く回せます。でも、共有ストレージやネットワークの変更まで、同じ感覚で何度も試せるとは限りません。実装を速く進められるとしても、その変更を本番環境に反映してよいかは、別に判断する必要があります
AIが作った変更にも、実際の設備や運用の制約はあります。セキュリティ上その権限を渡してよいか、必要な計算資源を確保できるか、変更中の学習をどう扱うか。コードだけでは完結しない判断です。
だから、技術を理解した人が、利用者や関係者と一緒に判断する必要がある。AIに調査や実装を助けてもらいながら、どこまで任せ、どこで人が確認するかも設計したいですね。
大戸：進めることで生じるリスクだけでなく、待つことで失われる学習時間もあります。全部分かるまで待てばよいわけでも、速く変更すればよいわけでもない。
神尾：何が分かれば進められるかを考えて、会社として必要なスピードを出す。その判断と結果に責任を持つところに、この仕事の難しさと面白さがあると思います。
——これから加わる人には、どんな仕事を担ってほしいですか。
大戸：計算資源が増えても、学習者がそれを効率よく使える基盤を作ってほしいです。構成管理や障害復旧、ストレージやネットワークの性能、ジョブの実行環境、使い勝手。自分の得意なところから入りつつ、何を変えれば学習が進むのかを考え、設計と実装を担ってほしい。
チューリングは「The Bitter Lesson」を行動指針に掲げています。計算規模の拡大を重視する会社で、その計算を実際の学習につなげるのが、自分たちの仕事だと捉えています。(行動指針)
神尾：今の規模で成立している構成や運用が、その先でも成立するとは限りません。ノードの構築や交換、設定管理、性能の確認、復旧の仕組み。次の規模に向けて、考え直すことがあります。
新しく入る人には、その人の経験から見える課題もあると思います。「ここはこう作れる」「この運用は変えられる」と持ち込んでもらって、議論しながら形にしたいですね。
——難しさも含めて、今この仕事を選ぶ意味は何でしょうか。
神尾：入社の決め手に戻りますが、この規模のインフラを、このスピードで作っていけることです。これまでの経験を活かして、さらに大きなものに挑める。今、まさにその基盤をゼロから作り上げていく過程に携われることが魅力でした。もちろん、これまでの経験だけでは足りない場面もあります。それも理解したうえで、この挑戦に取り組んでいきたいと思いました。
大戸：AIの技術が凄まじいスピードで進化する中、「自分の判断で手に汗握るような挑戦ができるのは、今のこの形では最後かもしれない」という想いから、今回の挑戦を選びました。「いつかやろう」と思っているうちに、エンジニアの仕事の姿そのものが変わってしまうかもしれないと感じたからです。
AIが使われ続ける限りAIインフラも長く必要とされますが、そこで人が担う役割は変化し、多くの判断をAIに任せるようになるはずです。だからこそ今は、AIエージェントに任せるだけでは解決できない未知の課題に対し、限られた環境下で試行錯誤しながら巨大な基盤を動かし、AIの学習を自らの手で前に進めたい。AIと協調しながら、共に成長していける面白さがここにはあります。
一方で、インフラのスケールだけを追いたいわけではありません。構築した基盤によってMLエンジニアの実験サイクルが高速化し、その技術的成果が明確な「事業貢献」へと繋がっていくこと。それが何よりのやりがいです。 この仕事の延長線上には、「大好きな車」と「日本の自動車産業の未来」があります。これまでの技術と経験をフルに活かし、事業の成長と産業の未来に貢献していきたいと考えています。
——最後に、候補者へ一言お願いします。
神尾：大きなインフラを、自分で考えて作りたい人には、ぜひ話を聞いてほしいです。GPUの経験がなくても、深く取り組んできた技術があれば、持ち込めるものはあると思います。
得意な領域に閉じず、必要なところまで調べて、手を動かして形にする。そういう仕事を一緒にしたいですね。
大戸：バックエンドでも、クラウドでも、オンプレでも構いません。難しい問題を調べて、何かを作ったり直したりしてきた経験を聞かせてください。
これからやることにも、分からないことはたくさんあります。うまくいかないことがあれば、そこから学んで次の進め方を変える。「それでも前に進む」という姿勢で、周囲と議論しながら実装まで進めたいです。
大きな計算基盤を作り、それを会社の学習に最適な形へ育てていく。この課題なら自分の技術を使えそうだと感じた方と、ぜひ話してみたいですね。
次の計算基盤を、一緒に作る仲間へ。
SlurmもLustreも知らないところからHyperPodに触れ、学習者の使い勝手と学習効率に改善の余地を見つけ、自らインフラチームへの異動を志願した大戸さん。IaaS基盤で培った経験を、規模とスピードのある現場に持ち込んだ神尾さん。
二人が求めているのは、自分の専門領域を深く理解し、必要ならその境界を越え、理解したことを設計や実装につなげる力です。
次の構成をどう作るか。増える計算資源をどう使い切るか。利用者が学習を進めるために、何を変えるべきか。
チューリングは、その判断と実装を一緒に担う仲間を募集しています。詳しくは、求人ページをご確認ください。
