はじめに

  • こんにちは、エンタープライズクラウド事業部の新川です。今週は Oracle AI World 2026 に参加するため、ラスベガスに来ています。

  • イベントは現地時間 10/25（日）から開催です。初日に、「Build the App You Wish Existed: An AI + OCI Hackathon」(HAC1396)に参加しました。同じく当社から参加した今井さんと2人で臨んだ、初めてのハッカソンです。しかも、海外のエンジニアに混ざってのチーム戦で、どきどきわくわくでした。

  • ハッカソンはブログ2本立てで紹介します。こちらの記事（概要編）では、ハッカソンの概要と参加レポートを書きます。技術的な内容は、今井さんの技術編でご紹介します。

ハッカソンの概要

  • 「あったらいいなと思うアプリを、AI で形にする」チーム戦のハッカソンです。実際の課題や日常の不便を解決するアプリを、数時間で、アイデア出しから動くところまで作ります。

    • 開催日時: 10/25（日） 13:00〜17:00（現地時間）。カタログには「4時間」とありましたが、開始前の説明やセッションが入るため、実際に開発に使えた時間は約2時間半です。
    • 形式: 4〜5人のチームで、OpenAI の Codex などの AI 開発ツールを使って開発します。1つのテーブルに2チームが座ります。
    • 審査: 専用の AI 審査アプリにアプリを提出すると、自動で採点とフィードバックが返ってきます。最後に、上位3チームが会場全体に向けてプレゼンします。
  • 主催者の説明では、このハッカソンは、今年のセールスキックオフで700人を対象に開いた企画を、社外向けに広げたものだそうです。コーディング未経験の人も参加して、アプリを作ってデプロイまで経験したことがとても楽しかったそうで、顧客やパートナー向けにも開催することになった、と話していました。短い時間でも、実際にかなりのことができるという体験を届けたい、という思いが伝わってきました。

事前準備

  • 渡航の数日前に Zoom の説明会がありました。私たちは「どんな開発をするのか」「他の参加者と交流できるのか」「言葉の壁を乗り越えられるのか」と、期待と不安が入り混じっていました。

  • 説明会では、当日の流れや持ち物、AI 審査アプリの使い方が案内されました。ノート PC と、チームに最低1人の GitHub アカウントが必要です。私たちも準備を進め、開始までに、OpenAI の Codex のインストールを済ませ、API キーは有効期限があるため当日に設定しました。

当日の様子

到着とランチ

  • 12:00 に会場へ到着しました。入口でボックスランチが用意されていて、3種類から選べます。私はターキーのサンドイッチを選びました。開けてみると、りんごが丸ごと1個入っていて驚きました。サンドイッチはしっかりボリュームがあって満足でした。

チームとテーブル

  • テーブル5に、2チームが向かい合って座り、まずはご挨拶をしました。本来のチームは4〜5人でしたが、2名が欠席となり、私と今井さん、Danさんの3人チームになりました。

審査の仕組み

  • 開発の前に、主催者から進め方の説明がありました。まずは審査の仕組みです。

    • AI 審査アプリ: アプリを作ったら、専用のポータルに提出します。ポータルが、アプリを自動で巡回して動作を確認し、数分で採点とフィードバックを返します。強みと弱みが具体的に分かるため、改善して再提出できます。
    • リーダーボード: 提出のたびに順位表が更新されます。スコアが上がることも、下がることもあります。審査の対象は、最高点ではなく最新の提出です。主催者は「終盤に差をつけているなら、それ以上いじらない判断も大事」と話していました。
    • 審査の考え方: 採点基準は、VC（ベンチャーキャピタル）が投資を判断するときの視点で作られています。「どんな課題か」「誰の課題か」「どう解決するか」を具体的に書く必要があり、アプリを作るだけでなく、そのアプリがなぜ必要かを考えさせる作りでした。

  • 事前案内の資料によると、配点は5つの観点で合計100点です。

観点 配点
課題の深刻さ(需要の現実性) 25%
ターゲット顧客と市場 20%
解決策と製品設計 20%
技術的な実装とデモ 20%
差別化と投資適格性 15%

開発の進め方のコツ

  • 次に、Codex を使った開発のコツが紹介されました。特に強調されていたのが、最初の1時間の使い方です。目安は次のとおりです。

    時間 やること
    00〜10分 作る成果を決める（長引いても15分まで）
    10〜20分 MVP と評価の方法を決める
    20〜45分 最初の1機能を作る
    45〜60分 動くものを公開して、最初に提出する
  • ポイントは、作り込む前に「動くものを公開して、一度提出する」ところまで通しておくことです。
    • 最初の1時間は小さく動かす: アイデア決めは迷ったら AI に相談して短く切り上げ、MVP（実用最小限の機能）は小さく決めます。
    • 評価（Eval）を最初に考える: 「どうなっていれば良いアプリか」を決め、改善のたびにその評価を回して、良くなったかを確認します。
    • 小さなタスクに分ける: 設計や計画は大きなモデルに、実装は速いモデルに任せます。大まかな指示では品質が落ちるため、タスクを小さく分けるのがコツだそうです。
    • 公開 URL と GitHub: 提出には、公開 URL（動くデモ）と、GitHub のリポジトリが必要です。チームで見られる状態にしておくと、終了後もコードが残ります。
    • 認証は入れない: MVP にログイン機能は入れない方がよい、という助言がありました。トラブルの原因になりやすく、審査アプリにも余計な手順が増えるためです。


開発スタート

  • アイデアを出し合い、AI と相談しながら MVP を決めて、開発に入りました。私たちが作ったのは、障害のタイムラインから、経営層向け・技術者向け・顧客向けの3種類の報告文を作るアプリです。開発は、仕様をまとめた SPEC.md をもとに Codex に作らせる進め方でした。結果や詳しい開発の様子は、今井さんの技術編をご覧ください。

おわりに

  •  初めてのハッカソンで、結果はほろ苦いものになりましたが、とても良い経験ができました。Codex を使った開発は初めてで、技術的な知見が深まりました。また、海外の方とコミュニケーションを取りながらの参加は、英語でのやり取りに苦労しました。それでも、画面を見せて状況を共有して、なんとか乗り越えられました。
  • 開発の中身や、公開でつまずいた経緯は、今井さんのブログに詳しく書かれています。ぜひあわせてご覧ください。