研究と実験から得られた学びを公開します。
ROBOCOは、AIと少人数のチームでどこまで挑戦できるかを実際の課題で確かめます。開発エージェントの完遂、モデル学習の自動化、専門領域のツール開発、クラウド基盤の活用方法を探り、実験条件と観察結果を記録します。期待に届かなかった結果も、次の判断に役立つ根拠として残します。
紹介基準日：2026年10月16日。最新の実験条件と進捗は、各プロジェクトのダッシュボード・研究記録で確認できます。
Ralphループ完遂比較
結果公開 · 後続実験を継続
問い： 開発エージェントは目標を受け取り、人の介入なしに検証を通過するまで開発を完遂できるでしょうか。モデルと実行環境の組み合わせは、その過程にどのような違いを生むでしょうか。
方法： 共通課題としてRealWorldバックエンドを実装させます。作業と検証を繰り返すRalphループを使い、公式Hurlテストで完遂を判定します。モデル・ハーネス・言語・反復上限を実験ごとに記録し、独立した再検証で結果を確認します。ハーネスとは、エージェントがツールを使い、作業を実行する環境です。この実験は、強いモデルが助言し弱いモデルが実行するAdvisor戦略の測定から始まり、モデルと実行環境の組み合わせによる完遂比較へと範囲を広げました。
観察： 複数の組み合わせについて、完遂結果、所要時間、反復回数、トークン使用量を公開しています。実行環境の設定や採点過程の問題が結果を変えた事例も分析し、モデルの能力と実験環境の影響を区別します。
解釈の範囲： 特定の課題と限られた反復実験の結果です。実行時期、ツールのバージョン、課金の定義も確認する必要があります。一つの順位ですべての開発業務の優劣を判断するものではありません。
韓国修能AIベンチマーク
2026学年度の結果公開 · 2027学年度は修能直後に評価予定
問い： 最新のAIモデルは、韓国の大学修学能力試験（修能）の問題をどこまで解けるでしょうか。モデルと実行ツールによって、正答率・時間・費用はどのように変わるでしょうか。
方法： 2026学年度修能の奇数型の原本PDFを画像としてレンダリングし、問題本文をテキストに書き起こさずそのまま提示します。国語・数学・英語の147の固有問題を、OpenAI、Anthropic、オープンモデル系列の複数のモデルに解かせ、ツール・検索・プラグインは無効にします。モデルは確信が持てない問題を棄権でき、棄権は実行エラーと区別して記録します。
観察： モデルごとの解答と採点結果、問題ごとの時間・トークン・費用の推定値をダッシュボードで公開しています。毎年、修能の前に前年度の問題を、修能の直後に新しい問題を同じモデル・プロトコルで評価し、年度ごとの比較ができるように運営します。
解釈の範囲： 公開済みの前年度の問題は、モデルの学習データに含まれている可能性があります。素点を受験生の標準点・パーセンタイル・等級には換算しません。英語のリスニングは公式台本の画像で評価するため、音声を聞き取る評価とは異なります。費用は、まとめて送ったリクエストの値を問題ごとに均等に配分した推定値です。
サーバーレス自動学習実験
結果・コード・チュートリアルを公開
問い： AIがモデルを自動で改善するautoresearch実験を、GPUの常時稼働なしに、必要な分のクラウド費用で実行できるでしょうか。
方法： KarpathyのautoresearchをAWS SageMaker Spotで再現・拡張します。L40SとH100で学習設定を探索し、候補生成・並列学習・結果収集・選択を繰り返します。学習時だけGPUを使うHUGIパターンを適用し、実験ごとの設定と費用を記録します。
観察： 公開記録には、L40SとH100で実施した48件の実験が含まれます。L40Sで見つけた学習設定をH100で再検証した結果に加え、GPUごとの費用・検証指標、起動待ち時間とSpotの利用可能性による影響を公開しています。再現コードと8章のハンズオンチュートリアルも提供します。
解釈の範囲： 特定のモデル・学習時間・GPU構成で得られた結果です。H100と元のプロジェクトの比較には単一実行の結果が含まれるため、繰り返し検証が必要です。費用と所要時間は、リージョン、Spotの利用可能性、起動時間によって変わります。
位相幾何学に基づくディープラーニング効率化実験
Track A完了（仮説棄却） · Track B・Cの進捗はリポジトリを参照
問い： 位相幾何学（トポロジー）と構造数学を活用すると、ディープラーニングモデルの計算量（FLOPs、メモリ、学習時間）を減らせるでしょうか。あるいは、同じ計算量で性能を高められるでしょうか。
方法： 3つのトラックに分けて検証します。Track Aでは、時系列分類でPersistent Homologyの要約特徴量によってモデルサイズを縮小できるかを確認します。Track Bでは、グラフでSimplicial/Cell Complexを使って全域attentionを回避できるかを確認します。Track Cでは、テンソル分解で重みを圧縮し、演算量を減らせるかを確認します。実験はSageMaker Managed Spot Trainingで3つのシードを使って繰り返します。
観察： Track Aでは、小さなモデル（PH-MLP）が4つのデータセットすべてで比較モデル（InceptionTime）よりF1が8〜32ポイント低く、成功基準（低下幅1ポイント以内）を達成できませんでした。特徴量への変換過程で時間的なパターンが失われること、長い時系列で計算コストが大きくなることが原因と分析されました。Track Aの実験費用は全体で約0.40ドルでした。
解釈の範囲： この結果はTrack Aの手法とデータセットに限られます。位相幾何学的アプローチ全体に効果がないという結論ではありません。Track B・Cの結果は、2026年10月16日時点でまだ公開していません。
半導体EDA実験
探索中 · 一部トラックの結果公開
問い： AIと専門知識を学びながら、半導体設計に役立つソフトウェアやモデルを作れるでしょうか。正確性と実際の時間短縮を、それぞれどう確かめるべきでしょうか。
方法： 電子設計自動化(EDA)の領域で、実験追跡ツール、タイミング解析ツール、設計フローの障害診断ツール、電源電圧降下(IR drop)の予測モデルを探ります。実装前に判定基準を定め、基準データと、学習・開発に使っていない別の評価データで検証します。トラックごとの計画・プロトコル・結果・学習チュートリアルを公開しています。
観察： 公開記録には、実験追跡ツールが正確性の基準を満たしながら、目標の時間短縮には届かなかった結果があります。障害診断ツールも、開発に使った事例と別の評価事例で成績が異なりました。正確性、汎化、現場での有用性を分けて検証する必要性につながる学びです。
進捗の範囲： 状態はトラックごとに異なります。結果が公開されたものもあれば、探索中や着手待ちのものもあります。本紹介は研究ログとトラック別記録に基づいており、商用EDAや実際のチップ製造を完成させた成果を示すものではありません。
S3実験
調査 · 一部の実測が完了
問い： Amazon S3をキー・バリューストア、イベント保管、データベースの保存基盤、ファイルI/Oに活用すると、どのような選択肢が生まれるでしょうか。適した条件と、コスト・性能の制約は何でしょうか。
方法： パターンごとの文献調査と直接測定を区別します。S3 Files・Mountpoint for S3・EFSの比較では、クライアントキャッシュを空にした条件で読み書きのワークロードを実行し、遅延・スループット・未対応の操作を記録しました。SageMakerの学習環境でのマウント条件も別途確認しました。
観察： パターン別の調査報告と、ファイルシステムの比較測定結果を公開しています。結果はワークロードとキャッシュ条件によって異なり、性能に加えて適用環境の制約も選択を左右することが分かります。
解釈の範囲： すべてのパターンで実装と実測が完了したわけではありません。ファイルシステム報告の測定日は2026年5月4日で、インスタンス・リージョン・キャッシュ条件を明記しています。クライアントキャッシュを空にしても、サービス内部のキャッシュが残る可能性があるという限界も含めて読む必要があります。
Aurora DSQL比較実験
12件の実験を完了 · 導入判断レポートと利用ガイドを公開
問い： 同じ業務を実行するとき、Aurora DSQLは従来のリレーショナルデータベースと比べ、性能、開発・運用作業、費用、制約にどのような違いがあるでしょうか。
方法： Aurora DSQLをRDS PostgreSQL Multi-AZインスタンス、Aurora PostgreSQL Provisioned、Aurora PostgreSQL Serverless v2と比較しました。同じ注文業務・整合性・遅延目標を基準に、SQL互換性、競合と整合性、OLTPの処理量と遅延、接続、障害と復旧、急増とアイドル、運用作業、大規模な集計、費用を12件の実験で検証しました。実験条件、測定資料、実行コードを公開します。
観察： 固定256接続で、DSQLは遅延目標の範囲内で毎秒24,541件以上を処理しました。比較対象が目標内で達成した最高処理量は、Aurora Serverless v2が11,559件、RDS Multi-AZが5,839件、Aurora Provisionedが3,375件でした。その代わり、クエリ1回の遅延はAuroraの3〜6倍（書き込みp95で約30〜40 ms）で、既存SQL 35項目のうち16項目の修正が必要でした。競合時の再試行とトランザクションの分割（3,000行・300秒）も必須でした。費用はリクエスト100万件あたり約0.31米ドルとリクエスト数に比例し、平均負荷が毎秒約1,100件未満のサービスや、アイドル時間が長いサービスでは固定インスタンスより安くなりました。任意の時点への復元（PITR）には対応していませんでした。
解釈の範囲： 2026年9月24〜29日にソウルリージョンで、1種類の注文業務と約5 GiBのデータを使って実行しました。多くの測定は1回のみで、12件のうち9件は計画の一部だけを実行した最小範囲（MVP）です。DSQLの処理量は負荷生成器の限界に近い下限値であり、DSQLと比較対象の処理量は別の日に、異なる負荷生成器の仕様で測定しました。
実験から、貴社の生産体制へ
これらの実験は、ツールと基盤の選択、検証基準と運用条件の設計に役立つ根拠となります。貴社の環境では、実務で適合性を確かめながらソフトウェアファクトリーのパイロットと構築へつなげます。