Serverless Autoresearch：バイブコーディングでML実験パイプラインをサーバーレス化した記録

Sun, 29 Mar 2026 16:00:00 +0900

バイブコーディングの本当の価値は、コードを速く書くことだけにあるのではありません。高くつく実験を、より安く、より速く繰り返せる運用のあり方を設計することにあります。

チョン・ドヒョン - ROBOCO首席コンサルタント

たいていの人はバイブコーディングを、まずWebアプリのプロトタイピングやCRUD自動化と結びつけます。しかしROBOCOのserverless-autoresearchリポジトリは、このフレームを大きく広げます。このプロジェクトは、Andrej Karpathyのautoresearchが前提とする「H100を1台、数時間つかんでおく」やり方の代わりに、AWS SageMaker Spotの上で並列実験を短く爆発的に実行する構造を作っています。¹

この事例が興味深いのは、結果が安く出たからではありません。このリポジトリには、最初のアイデアを練り上げる深層インタビュー、計画中心のアーキテクチャ設計、クラウドインフラのデバッグ、反復実験の自動化、失敗を文書とスキルへ還元していく過程がすべて残っています。とくにdocs/vibe-coding-tutorialは、コードの説明書ではなく、対話型のAIコーディングが実際にどうエンジニアリングの成果物として固まっていくのかを示すログに近いものです。²

まず数字から整理しておく必要があります。チュートリアルは2026年3月27〜28日の初期実行区間を中心に、25回の実験、総費用0.44ドル、最高val_bpb 1.0643を記録しています。²³ 一方でリポジトリのREADMEは、その後に拡張された図として83回の実験を約3.5時間、約1.33ドルで実施する方向を示し、もとの逐次実行に比べ2.3倍速く、5〜18倍安い構造であることを強調しています。¹ つまり「0.44ドル」は初期検証の費用であり、「1.33ドル」は拡張された運用モデルの費用です。二つの数値は矛盾しておらず、異なる段階の結果です。

TL;DR

serverless-autoresearchは、バイブコーディングをWebアプリ自動化ではなく、ML実験パイプラインとクラウド運用設計の問題へ拡張した事例です。
核心は、H100を長く占有するやり方の代わりに、SageMaker Spotベースの並列実験によって安い失敗と速い学習を可能にした点にあります。
良い結果は、コード生成量よりも、問題定義・計画・インフラ検証・失敗を文書とスキルへ還元する運用のあり方から生まれます。

1. このプロジェクトが実際に変えたこと

Karpathyのオリジナルのautoresearchは一度に一つの実験を回し、基本的にはH100のような高性能GPUを長く占有する流れに近いものです。serverless-autoresearchは、この流れを並列進化（parallel evolution）に変えました。¹⁴

核心は二つです。

実験一つを長くつかんでおく代わりに、複数の候補を同時に短く実行します。
GPUを24時間つけておく代わりに、必要なときだけSpotインスタンスを立ち上げ、終わったらすぐに落とします。

このリポジトリはこれをHUGI（Hurry Up and Get Idle）パターンと呼んでいます。¹ サーバーを長く維持する代わりに、短く一気に計算してただちにアイドル状態へ戻る方式です。この単純な転換が費用構造を完全に変えます。「サーバーレス」という言葉が関数呼び出しだけを意味するのではなく、GPUワークロードにも適用可能な運用哲学であることを示しているわけです。

チュートリアルを基準に見ると、実際の検証もかなり具体的です。

区間	内容	費用
初期の成功実験	L40S Spotで最初のend-to-end成功	$0.06
バッチサイズの罠の検証	4回の並列実験で誤った仮説を除去	$0.07
5世代の自律進化	20回の実験で最適パラメータを探索	$0.31
合計	25回の実験	$0.44

つまりこのプロジェクトのポイントは「安いGPUでも動く」ことではなく、安い失敗をたくさん買えるという点にあります。⁵⁶⁷³

2. チュートリアルが示す本当のポイント

2.1 曖昧な依頼は深層インタビューで絞り込むべき

チュートリアルの最初の場面はコードではなく質問です。ユーザーは「autoresearchの実験を再現したい」という依頼とともに、必要なら深層インタビューをするよう指示します。⁸ その結果、目標は単なる再現ではなく次の三つとして定義し直されます。

SageMaker Managed Spot Trainingベースのサーバーレス実行
OMCベースの自律反復実験
教育用／デモ用に再利用可能な文書化

これは小さく見えて非常に重要な転換です。漠然とした「再現」は、しばしばオリジナルを真似るだけで終わります。一方、インタビューを経れば「何を学ぶのか」「何を自動化するのか」「何を残すのか」が明確になります。バイブコーディングはプロンプトを長く書く技術ではなく、良い問題定義を引き出すインタビューの技術に近いという事実を示しています。

2.2 実装より先に計画モードが必要

第2章でAIはすぐにコードを書きません。まず上流のautoresearchコードベースと、ユーザーの既存のSageMakerパターンを探索したうえで、候補生成器・バッチランチャー・結果収集器・選択モジュールに分かれたパイプライン構造を計画します。⁴

途中でユーザーが「クラウドの利点である並列実行とHUGIを積極的に活用せよ」という条件を追加すると、設計は逐次実行からpopulation-based parallel evolutionの構造へ変わります。⁴ この箇所は、バイブコーディングが「AIが勝手に書いたコード」ではなく、計画段階でアーキテクチャを修正できてはじめて有用性が大きくなるという点をよく示しています。