はじめに
Gemini API Developer Competitionに参加した感想と学びをまとめる。
簡単に大会を説明すると
- Google版chatGPTである、「Gemini」のAPIを使ったシステムを開発する
- ソースコードとデモ動画を提出して、審査を受ける
- 賞金総額100万ドル
賞金総額からgoogleがGemini APIにかける本気度を感じる熱い大会だった
目次
- 開発体制と設計
- 何を作ったか
- 気をつけていたことと学び
- 感想まとめ
1. 開発体制と設計
Webエンジニア2人とAndroid(Flutter)エンジニアの自分、動画担当者の4人チーム。 技術スタックの兼ね合いでWebエンジニア2人がそれぞれフロントとサーバーを担当し、自分がデザイン、ディレクション、サポートを担当することになった。
フロントはNext, サーバーはFirebaseを使うことになった。 よくある一番楽なプロトタイプの設計だと思う。
少しだけ変えたのは、フロントから直接geminiを呼ばずに、firebse functionsかfirestoreを必ず挟むようにしたところ。
AIのモデルをいっぱい作ったので、どのAIを呼ぶかをfiresbase側で管理したほうが楽だという理由でこうしてある。
詳細を知りたい方はソースコードを見てね。（モノレポにしてあります）
graph LR
subgraph フロントエンド
A[Next.js]
D[Firebase Hosting]
end
subgraph バックエンド
B[Firestore]
E[Firebase Functions]
G[firebase authentication]
end
subgraph 外部API
C[Gemini API]
end
A --> B
B --> C
B --> E
E --> C
A --> D
A --> G
G --> B
2. 何を作ったか
デモ動画公開中なので見てね。
簡単にいうと「AI裁判所」のウェブアプリ。
争っている二人が使うことで、公平で法律的な視点から判決を下すことができる。
発案者は自分。
サービスの目的は
- 裁判を起こすコストがネックで泣き寝入りしてしまう人を減らす
- （細かい争いは自分達で解決することによる）裁判所の負担を軽減する
どういうふうに使うか
- 争いが起きる
- アプリで裁判部屋を作成
- 先に部屋に入りつつ、相手を部屋に招待して参加を待つ
- 部屋の中で、自分専属のAI弁護士と会話して主張をまとめる
- （自動）相手側の主張がまとまったら、AI弁護士どうしで会話が行われる
- （自動）AI弁護士同士の会話を受け、AI裁判官が判決を下す
- 判決内容を確認する
3. 気をつけていたことと、その成功と失敗
開発期間も1ヶ月もなく、それぞれの稼働も週末の数時間という状況だったので、どんなにしょぼくても動くものを絶対完成させるという目的で工夫をした。
二人がスムーズに作業できるように、以下のことに気をつけた。
- できるだけコミュニケーションコストを下げるために役割分担を明確に分けた
- 動けない時間を作らないために、最初にワイヤーをしっかり決め、フロント / サーバーの接続部分のインターフェースは集まって話しながら明確に文書化した
- 口頭でのコミュニケーションが重要なので、進捗報告会と作業会で週に2回集まる時間を設けた
- ソースコードの質も保ちたかったので、レビュー体制を整えることにした
- 一人はサポートに回る（デザイン、発表、マネジメント）
この中で1~3は上手くハマった。
二人の作業で待ち時間や手戻りはほとんど発生せず、スムーズに作業を進めることができただろう。 完成することができたのは1~3のおかげもあると感じる。
ただ、4と5は正直失敗だった。
レビュー体制の失敗
コードの質を保つことで、締め切り直前の機能追加に強くしたり、バグの少ないプロダクトにしようと考えた。 しかし、レビューをちゃんと通るようなコードにする手間や、レビュー待ちの時間があることで 開発者から不満が出たので、途中でレビュー体制をやめた。開発開始から2週間目に差し掛かるくらいのタイミングだったと思う。
ここで失敗だったのは、進捗が遅れる可能性があるレビュー体制をとったことではなく、途中で辞めてしまったことだと考えている。
議論になった後「ソースコードは評価項目ではないため、質を保つことのメリットより開発スピードを優先する」という結論に至ったが、しっかりと評価項目を再確認すると、「バグの少なさ」が評価項目に含まれていた。
レビュー体制をやめたことで、コード自体の質が下がるだけでなく、出来上がるプロダクトのバグが増えることになった。
結局最終的なプロダクトはバグを多く抱えるプロダクトになっており、最後の追い込みがバグの消化に費やされることになった。
多少議論が長引いても、レビュー体制を続けることを納得してもらうべきだっと今は感じている。
もちろん、これは今回のコンペが1ヶ月以上の開発時間を与えられていたからであり、二日間のハッカソンなどで同じことをすべきかどうかは、アイデアの実現がどの程度の難易度なのかによると思う。
一人はサポートに回ることの失敗
これは完全に失敗だったわけではない。 ただ、デザインも自分でやっていたことが失敗だった。
デザインの経験がなく、「ノンデザイナーズデザインブック」を読んだ程度の自分では、フロント側のエンジニアの満足するデザインにすることができなかった。
結果的にフロント側で1ページコーディングしてもらったデザインに合わせる形になった。
まだ、ワイヤーレベルのデザインしか作っていなかったため被害は抑えられたが、もし作り切ってからそれを使わないということになれば、相応ロのタイムロス（とやる気のロス）が発生していただろう。
今回の反省は、素直にデザイナーさんを入ってもらうか、それができないなら、「〇〇のサイトを参考にする」という形でデザインの方向性を示す程度にとどめるべきだったと感じている。
（もしくは、普段からある程度のデザインセンスを磨いておく？）
4. 感想まとめ
今回参加して得た一番の収穫は、コミュニケーションの重要性とコードの品質を保つことの難しさだ。
今回ちゃんと完成まで辿り着けたのは、週に2回集まったからというのも大きい。（もちろんエンジニア2人の尽力があってこそ） コミュニケーションをしっかり取ることで、逆に時間の無駄を省くことができるため、時間がない時ほどコミュニケーションを取ることが重要だと感じた。
また、コードの品質に関しては、今までのハッカソンではあまり意識しなかったが 最低限の基準を決めておかなければ、なし崩し的にどんどん品質が下がってしまうし、一度下がった品質を上げるのは非常に困難なため、 ハッカソンであっても一定の基準を設けるべきだと感じる。
ましてや、ハッカソンの参加の目的が「技術力の向上」であるならば 一定の品質を保ちつつスピードを上げるという練習をする必要があるので 基準を設けるのは非常に重要だと思う。
おまけ： geminiの感想
最後にgeminiを1ヶ月バッチリ触った感想。
サービスの質としては、ほとんどの場面でchatGPTを超えていると感じた。
chatGPTとClaudeとgithub copilotとの比較だが、コード生成のクオリティが最も高いのはgeminiだと感じた。（主観です。）
また、課金のサブスクリプションであるGoogleOneに無料期間がある点やGoogle Driveの2TBストレージとgoogle meetsの時間制限廃止がオマケでついてくるのも地味にデカい。
正直そこまで期待していなかったが、chatGPTよりGeminiの方がオススメです。
APIの使い心地はほぼほぼchatGPTのAPIと同じで、品質も高く、料金も安い（gemini 1.5 flashとGPT4-o miniを比べた場合）。