ノダール・ダネリヤ、ShuttleのCEO兼共同創設者 – インタビュー・シリーズ

ノダール・ダネリヤ、ShuttleのCEO兼共同創設者 – インタビュー・シリーズ：ノダール・ダネリヤは、2019年にShuttleを共同創設して以来、CEO兼共同創設者を務め、YC Summer 2020のスタートアップから開発者向けのプラットフォーム・エンジニアリング・カンパニーへの成長を牽引してきた。Shuttle以前は、Provenance Technologies Ltdのチーフ・リスク・オフィサーを務め、量的ヘッジ・ファンド・戦略に取り組んだ。また、ロンドンとGoogleでテクノロジーとデータ関連の役職を歴任した。

Shuttleは、オープンソースのクラウド・インフラストラクチャ・プラットフォームで、コードの注釈からインフラストラクチャを導出することで、バックエンドの開発とデプロイを簡素化し、開発者がRustやその他のコードを書くことに集中できるようにする。プラットフォームは、迅速なデプロイ、すぐに利用できるリソース・プロビジョニング、シームレスなスケーリングを可能にし、13万回以上のデプロイを行った数万人のエンジニアによって使用されている。Shuttleは、ゼロ・コンフィグ、AIアシスト・エクスペリエンスをすべての言語に拡大し、GitHub CopilotやCursorなどのツールと統合することを目指している。

Shuttleを共同創設するきっかけとなった瞬間や不満は何でしたか。最初に解決しようとした問題は何ですか。

転機は、私がクオンツ・ヘッジファンドでトレーディングを率いていたときです。博士号取得者、シニアのプラットフォーム担当者、機械学習研究者など優秀なエンジニアがいましたが、その才能があってもクラウドインフラは常にボトルネックでした。取引モデルやバックエンドサービスの構築は難しい部分ではありません。問題は、安全な稼働、スケーリング、クラウドサービスの接続というデプロイでした。そこですべてが遅くなりました。ある時点では、エンジニアリングチームの半数以上がシステムを動かし続けるためだけにDevOpsの作業をしていました。

印象に残ったのはコードや数学の高度さではありません。非常に能力の高い人たちが、本当に重要なものを作る代わりに、ほとんどの時間をクラウドとの格闘に費やしていたことです。誰も望まない作業でしたが避けられませんでした。「何かを作った」と「それが安定稼働している」の間の摩擦、そのギャップこそShuttleが解決するために生まれたものです。

Shuttleは、現在のAIコーディングツールの波が来る前の2019年に設立されました。AI支援開発が主流になるにつれ、当初のビジョンはどう進化しましたか。

根本の問題は変わりませんでしたが、AIがそれを劇的に増幅しました。私たちが始めたとき、インフラはすでに優秀なエンジニアリングチームの制約要因でした。Copilot、Cursor、Claudeなどが登場すると、そのボトルネックは無視できなくなりました。

突然、開発者は数分でアプリ全体を生成できるようになりましたが、それらはすぐ壁にぶつかりました。AIはコードを書けても、クラウドリソースを確実に設定、管理することはできません。解決しようとしていたギャップは大きくなり、緊急性も増しました。今や数百万人がプロトタイプを作っていますが、本番まで届くのは一部だけです。

ビジョンは「開発者にとってインフラを簡単にする」から「まったく新しい世代の作り手のためにインフラを機能させる」へ進化しました。バックエンドコードは作れてもクラウド設定と格闘したくない個人創業者、小規模チーム、AIエージェントです。従来のエンジニアだけにサービスを提供しているのではありません。対象者は爆発的に増えました。

CursorやGitHub CopilotなどのAIツールはコードの書き方を変えました。ソフトウェアのライフサイクルで最も改善された部分と、チームがまだ苦労している部分はどこですか。

コード生成は飛躍的に進歩しました。その部分はほぼ解決されています。機能を説明するとAIがひな型を作ります。特にフロントエンドは、コンポーネント、スタイル、レイアウトといったパターンがよく理解されているため恩恵を受けました。

チームが苦労するのは、その後のすべて、つまりデプロイ、インフラ、運用です。AIはAPIエンドポイントを生成しても、それを実際に動かすデータベース、ストレージ、キュー、ネットワーク、権限、デプロイパイプラインを自動では作れません。バックエンドインフラはコード生成に追いついていません。

結果として進歩は不均衡です。最初から最後まで簡単になる代わりに、新たな負担が生じます。数分でバックエンド全体を生成した後、安全なデプロイに何日も行き詰まります。AIがチームで実行、保守できる以上のコードを作り、悪化させる場合もあります。今の本当の摩擦はそこにあります。

デプロイはAI生成アプリの最大のボトルネックとよく言われます。コード自体の生成と比べ、これらのシステムを本番運用に移すことが難しい具体的な理由は何ですか。

問題は信頼性と結果です。コード生成では間違いをすぐ見て直せます。インフラの間違いは異なります。誤った権限、設定を間違えたリソース、コストやセキュリティについての誤った想定が一つあれば、後になって初めて表面化する深刻な問題を作ってしまいます。

初期には、AIにアプリコードから自由にインフラを推論させました。デモでは素晴らしく見えましたが、実システムでは破綻しました。AIは、ほぼ正しくても完全には正しくない構成を自信満々に出しました。広すぎる権限、奇妙なリソース選択、知らぬ間に高額になる設定などです。

重要な教訓は、本番環境では境界のない知能が問題を生むことでした。AIに必要なのは自由の拡大ではなく、よりよいガードレールです。AIが提案して加速できても、暴走できないシステムを設計する必要があります。これが、AI生成アプリを本番運用に移すことをコード生成よりはるかに難しくする技術的課題です。

Shuttleは最近、プラットフォームの次の進化としてNeptuneを発表しました。汎用AIプラットフォームエンジニアという説明は、プロトタイプから本番用バックエンドへ移る開発者にとって実際に何を意味しますか。

Neptuneはコードと本番環境の間で欠けていた層です。開発者やAIエージェントはアプリのロジックを書くことに集中し、必要なインフラの理解、リソースの準備、シークレット管理、デプロイ、サービスのオーケストレーションなど、残りはNeptuneが処理します。

開発者にアプリをクラウドインフラへ翻訳させる代わりに、Neptuneがアプリを理解して周囲のインフラを生成します。コードが設計図となり、Neptuneが実行環境を構築します。DockerfileもTerraformも延々と続く設定も不要です。

プロトタイプから本番へ移る人は、突然DevOpsを学ばなければならない壁にぶつからなくなります。作ったアプリはスケールしても動き続けます。「何かを作った」と「本番で安定稼働している」の間をNeptuneがつなぎます。

開発者がバックエンド生成でAIに依存する度合いを強めるなか、速度と抽象化を、制御、セキュリティ、可観測性の必要性とどう両立させますか。

答えは信頼です。インフラでは能力より信頼が重要です。セキュリティホール、壊れたデプロイ、巨額のクラウド請求といった悪い驚き一つで、人々の信頼を失います。

AIが触れるものはすべて理解可能でレビュー可能でなければならないと、早くから学びました。手動で設定していなくても、開発者は何がなぜ起きているか確認できる必要があります。そのためNeptuneは決定論的なインフラ規則を使います。AIは提案し加速できますが、その動作はすべて、レビュー可能で予測可能、テスト可能な仕様に基づきます。

私たちは「AIが決める」から「AIが制約の中で提案する」へ転換しました。これが楽しいデモと、重要なときに信頼できるものの違いです。開発者は意思決定に使う時間を減らしているのではありません。タイピングを減らし、何を存在させるべきか、何を受け入れられるか、どのトレードオフが妥当かを考える時間を増やしています。最良のチームはAIを、有能な若手エンジニアとして扱います。有用で生産的ですが、最終決定を担う立場ではありません。

個人開発者、スタートアップ、大規模なエンジニアリング組織など、現在Neptuneから最も大きな価値を得ているのはどのようなチームですか。

利用者層は大きく変わりました。Rust側では当初、個人開発者、初期スタートアップ、スケールアップから、自動車、IoT、金融、暗号資産など、信頼性と性能が重要な分野の企業チームまで多様でした。複雑なクラウドインフラの管理負担なしにRustの力を使いたい人たちです。

しかしこの1年でAI主導の開発が台頭し、誰がソフトウェアを作るかが一変しました。個人創業者、インディー開発者、AIエージェント、小規模チーム、従来のソフトウェア企業が皆、前例のない速度でバックエンドコードを生成しています。専門分野のシニアエンジニアだけが対象ではなくなりました。

個人創業者や小規模チームが一度の作業でアイデアからデプロイ済みバックエンドまで進む例を日常的に見ます。設定に何日も費やす必要がないからです。節約するのは時間だけではなく、初期段階で何より重要な勢いです。作る力はあっても、アイデアを公開するためにインフラの専門家になりたくない人たちに、最大の価値があります。

技術的な観点から、NeptuneはAI生成コードをデプロイ可能な本番用バックエンドへ変える際、環境設定、シークレット管理、インフラのオーケストレーションをどう処理しますか。

Neptuneはコードとインフラを統一されたシステムとして扱います。多くのデプロイツールは配送サービスのようなもので、利用者がコンテナを持ち込むと実行を試みます。それでも、クラウドリソースの接続、設定の記述、環境変数への対応、シークレット管理、データベースの準備は利用者の責任です。

Neptuneはそのモデルを逆転します。開発者にアプリをクラウドインフラへ変換させず、アプリを理解して周囲のインフラを生成します。AIネイティブなDevOpsの方法です。コードを設計図とし、シークレット管理、環境設定、リソースのオーケストレーションを含む実行環境をNeptuneが構築します。

重要なのは、AIが決定論的なインフラ規則の中で働くことです。任意の構成は作れません。すべてがレビュー可能かつ予測可能なままであり、本番環境のセキュリティとコスト管理に不可欠です。

AIシステムが他のソフトウェアをますます構築、デプロイ、管理するエコシステムで、Neptuneの役割は今後どう進化すると考えますか。

アイデアと動く製品の間のギャップがほぼゼロになる世界に向かっています。まもなく製品は速く作られるだけでなく、人々の実際の使い方から得られるリアルタイムのフィードバックに基づいて自ら継続的に改善するようになります。

その世界のソフトウェアは静的ではありません。アプリ、エージェント、システムが絶えず生成、変更、進化します。それでもすべてはどこかで実行される必要があり、インフラ、権限、リソース、信頼性が必要です。

長期目標はAI支援DevOpsの標準システム、つまりAIプラットフォームエンジニアになることです。開発者がCursorでコードを書いてもAIエージェントが自律生成しても、Neptuneがそれを完全に稼働し、スケール可能な本番品質のサービスへ導く層になるべきです。

創造性が無限になるなら、インフラが制約になってはいけません。AIエージェントや自ら進化する製品が一般化するなか、クラウドインフラとのやり取りをシームレスで予測可能、安全にするのが私たちの仕事です。その過程を見えないものにし、開発者、創業者、企業がインフラとの格闘ではなく価値の創造に集中できるようにすることに注力しています。

素晴らしいインタビューをありがとうございました。詳しく知りたい読者はShuttleをご覧ください。