ハッカソンでキーボードに一度も触れなかったチームが優勝しました。AIエージェントが夜通し10万行のコードを書き上げ、そのうち7万行はテストコードでした。開発者は設計書だけ渡して退勤したんです。これがソウルの真ん中で実際に起きたことです。
これは何?
ラルフトン（Ralphton）は「人間は退勤してAIがコーディングする」というコンセプトのハッカソンです。開発者コミュニティのチームアテンション（Team Attention）がカカオベンチャーズと共同開催し、グローバル大手テック企業のOpenAIが後援しました。2026年2月28日から3月1日にかけてソウル城北区で開催され、OpenAIシンガポールの開発者たちが現地に直接足を運びました。
従来のハッカソンは、参加者が夜通し自らコードを書き、その成果物を評価する形式でしたよね。ラルフトンはまったく異なります。参加者はアイデアと設計書（PRD、スペック）だけを提出し、実際のコーディングはAIエージェントが行います。初日にハーネスエンジニアリング（harness engineering）——つまり、AIが正しく動作できるよう環境と制約条件を設計する作業——を完了すれば、AIエージェントが夜通し自律的にコーディングし、翌朝に審査員が成果物を評価する仕組みです。
予選を通過した9チームが本戦に参加しました。スタートアップの開発者や創業者などが参加し、Banksalad共同創業者のファン・ソンヒョン氏（現在The Venturesテックリード）もLLMベースのパズルWebを制作しました。AIエージェントスタートアップを運営するキム・ウヨン氏は、楽譜PDFを解析して移調（キー変換）を自動化するサービスを開発しました。
何が変わるのか?
優勝チームの事例が最もわかりやすく示しています。このチームは固定カメラ映像をもとに家事を自動化するボットを作りましたが、注目すべきはその過程です。
最初から最後まで、参加者はキーボードに一度も触れませんでした。その代わりに、開発前にAIエージェント同士に133回のソクラテス式問答（Socratic reasoning）を行わせ、設計の曖昧さ指数を0.05まで下げました。AIエージェントが「この要件はAを意味しますか、それともBですか？」とお互いに問い答えしながら、人間が見落とすかもしれない設計の抜け穴を自ら発見したのです。
10万行のうち7万行がテストコードという点も印象的です。AIが「とりあえず動くコードを書いて、テストは後で」という姿勢ではなく、最初から検証可能なコードを設計しました。複数のAIエージェントを活用する過程で発生しうる誤った出力（ハルシネーション）も、このテストコードが事前に防いでいました。
| 従来のハッカソン | ラルフトン | |
|---|---|---|
| 開発者の役割 | 自らコードを書く | 設計書 + ハーネスエンジニアリング |
| コーディングの主体 | 人間 | AIエージェント |
| 徹夜する対象 | 開発者 | AI（開発者は退勤） |
| 品質保証 | コードレビュー | AIエージェント間133回の問答 + 70%のテストコード |
| 核心となる能力 | コーディングスキル | 設計力 + AI環境の設計 |
一方、失敗した事例もありました。あるチームは進行中にスペックを急いで拡張し、ワークトラック3つを並行実行した結果、デプロイが停止して異常ループに陥りました。結局、コードを直接修正しなければなりませんでした。AIエージェントに明確な設計なしで過度な自律性を与えると、むしろ逆効果になることを示した事例です。
3位チームは別のアプローチを見せました。コスト最適化に注力し、高価なモデルから安価なモデルに切り替えながらも、同じパフォーマンス指標を達成しました。AIエージェント時代の競争力は、単に「最良のモデルを使うこと」だけでなく、「同じ結果をより効率的に生み出すこと」にもあることを示す証拠です。
以前は、1人の開発者がビジネスをスケールアップするのには明らかな限界がありましたが、今回のラルフトンを通じて、その壁が完全に崩れたことを確認しました。
— チャン・ドンウク、カカオベンチャーズ理事
チームアテンションのチョン・グボン開発者も「AIをツールとして使う段階を超えて、AIエージェントの活用法をどれだけ深く内面化できるかが、企業の真の競争優位（moat）になるだろう」と語りました。
始め方のポイント
ラルフトンが示したのは、結局「ハーネスエンジニアリング」の実践です。開発者が自らコードを書く代わりに、AIエージェントがきちんと機能できる環境を設計するということです。すぐに始められる手順をまとめました。
- PRD（製品要件文書）をしっかり書くことから始める
ラルフトン優勝チームの成功の秘訣は「キーボードを触らなかったこと」ではなく、「設計書を極限まで精緻に書いたこと」です。AIエージェントに渡す前に、要件の曖昧さを可能な限り排除してください。「こんな解釈もできるのでは？」という疑問が出てきたら、まだ文書が不十分なサインです。 - AIエージェント間の検証ループを設計する
優勝チームが133回の問答を行わせた理由があります。1つのエージェントがコードを書いたら、別のエージェントが「これはスペックに合っているか？」を検証するループを作る必要があります。Claude CodeのCLAUDE.mdに検証ルールを入れたり、CI/CDパイプラインに自動テストを連携させたりするところから始めてみてください。 - テストコードを先に書かせる
「本コードが先、テストは後で」ではなく「テストを先に、本コードはその後」に順序を変えてください。優勝チームのコードの70%がテストだったのは偶然ではありません。AIエージェントが自分の成果物を自ら検証できる基準を先に作ってあげることが大切です。 - スペック変更は最小限に、並行実行は慎重に
失敗したチームからの教訓です。進行中のスペック拡張や無計画な並行実行は、AIエージェントを混乱させます。1つの明確なワークトラックを最後まで押し進めるほうが得策です。 - ハーネスエンジニアリングをチームの資産として蓄積する
CLAUDE.md、MCPサーバーの設定、検証スクリプト——これらを個人の環境ではなくリポジトリにコミットしてください。次のプロジェクト、次のチームメンバーが同じハーネスを使えるようにしてこそ、複利効果が生まれます。
ハーネスエンジニアリングとは？
プロンプトエンジニアリング → コンテキストエンジニアリング → ハーネスエンジニアリングへと進化しています。
プロンプト＝「何を聞くか」
コンテキスト＝「何を見せるか」
ハーネス＝「AIが動作する全体環境（スキャフォールディング、制約、検証ループ）をどう設計するか」
ラルフトンは、このハーネスエンジニアリングをハッカソンという極限の環境で実証した事例です。
