はじめに ── 設計書なしで、どこまでアプリが作れるのか
「こんな感じのものが欲しい」とAIに伝えるだけで、本当に動くアプリが出来上がるのか ── 。
最近「バイブコーディング」という開発スタイルを耳にする機会が増えました。細かい設計書を書かず、雰囲気でAIにコードを書かせるアプローチです。便利そうだけど、実際にやったらどうなるんだろう。気になったので、自分で試してみることにしました。
結果として出来上がったのが Gen-Jigsaw というWebアプリです。複数人でAI画像を拡張していくマルチプレイヤーアプリで、GitHubにOSSとして公開しています。
- リポジトリ: kwrkb/gen-jigsaw
この記事では、Gen-Jigsawがどんなアプリなのか、バイブコーディングで開発してみてどうだったか、そしてなぜOSSとして公開したのかについて書いていきます。
Gen-Jigsawとは ── 1枚の画像を、みんなで広げるアプリ
Gen-Jigsawは、複数人で協力してAI画像を拡張していくマルチプレイヤーWebアプリです。
遊び方はシンプルです。
- 最初に1枚の「シード画像」がグリッドの中央に置かれる
- 参加者が隣接する空きセルを選び、プロンプトを入力して新しいタイル画像を生成する
- ルームオーナーが生成された画像を「採用」するか「却下」するかを判断する
- これを繰り返すと、ジグソーパズルのように画像が四方八方へ広がっていく
ポイントは「1人で黙々と画像を広げる」のではなく、みんなで方向性を出し合いながら世界を作っていくところです。
アウトペイントという技術
ここで使われている中核技術が「アウトペイント（Outpainting）」です。
アウトペイントは、既存画像の外側にAIが新たな領域を自然に生成する技術です。単純に画像を引き伸ばすのではなく、文脈や遠近感を維持しながら「絵の外側の世界」を描き足してくれます。
OpenAIのDALL-E 2で2022年に実装され、1枚の絵画や写真をシームレスに拡張できる機能として注目されました（出典: OpenAI DALL-E 2）。
Gen-Jigsawは、このアウトペイントの仕組みを「みんなで遊べる体験」に落とし込んだアプリです。
バイブコーディングで開発してみた
バイブコーディングとは
バイブコーディングは、2025年2月にAndrej Karpathy氏（元Tesla AIディレクター、OpenAI共同創設メンバー）がX（旧Twitter）で提唱した開発スタイルです（出典: Wikipedia – バイブコーディング）。
厳密な設計書を書くのではなく、「こんな感じのものが欲しい」という雰囲気（vibe）をAIに伝えて、対話しながら実装を進めていくアプローチです。仕様を厳密に書く力よりも、方向性を示す力が問われる開発スタイルとも言えます。
実際にやってみた感触
今回の開発では、最初に決めたのは3つの方向性だけでした。
- 「AIで画像を広げていくゲームを作りたい」
- 「複数人で参加できるようにしたい」
- 「リアルタイムで更新が反映されてほしい」
あとはAIとの対話で実装を詰めていきました。
やってみて一番驚いたのは、プロトタイプが出来上がるまでの速さです。アイデアを思いついてから「とりあえず動くもの」が手元にあるまでの時間が、従来の開発と比べて劇的に短くなりました。
一方で、コードの細部を完全に把握しないまま先に進む場面もありました。Karpathy氏自身が「コードの存在を忘れる」スタイルだと表現していますが、まさにそのとおりです。動いているけど、なぜ動いているのか自分でも完全には理解していない瞬間がある。
プロダクション品質を目指すなら、バイブコーディングで素早く形にして、そこからしっかりレビューするという二段構えが現実的だと感じました。
技術構成のポイント
Gen-Jigsawの技術スタックは以下のとおりです。
| 技術 | バージョン | 役割 |
|---|---|---|
| Next.js | 15 | App Router / API Routes |
| React | 19 | UI |
| TypeScript | 5 | 型安全性 |
| TailwindCSS | v4 | スタイリング |
| Prisma | 6 | ORM |
| SQLite | — | ローカルDB |
| Vitest | 3 | テスト |
| Framer Motion | 12 | アニメーション |
技術選定で意識したのは、セルフホスティングしやすいことです。DBはSQLite、ストレージはローカルファイルシステムで動くようにしているので、npm install してすぐ試せます。
リアルタイム通信はSSE
マルチプレイヤーアプリなので、リアルタイムにグリッドの状態を共有する必要があります。ここでは**SSE（Server-Sent Events）**を採用しました。
WebSocketに比べて実装がシンプルで、サーバーからクライアントへの一方向プッシュ配信という用途にはちょうどいい選択です。
同時書き込みの制御
複数人が同じセルに同時に画像を生成しようとする競合を防ぐため、楽観的ロックの仕組みを入れています。ロックのTTLは90秒で、時間内に操作が完了しなければ自動解放されます。
タイル追加のライフサイクル
タイルの追加は以下のフローで進みます。
- ユーザーが空きセルの「+」をクリック → セルがロックされる
- プロンプトを入力して拡張リクエストを作成（QUEUED）
- AI画像生成が実行される（RUNNING → DONE）
- 参加者が投票する
- オーナーが「採用」→ グリッドに追加、または「却下」
- 一定時間（60秒）経過後は投票結果に基づいて自動決定
「みんなで作る」というコンセプトを支えるために、投票と承認のステップを設けているのがこのアプリの設計上の特徴です。
なぜOSSとして公開したのか
Gen-JigsawをOSSにしたのには、2つの理由があります。
AIと人間の協働プロセスを開示したかった
バイブコーディングで作ったコードには、従来の開発とは違う特徴があります。AIがどんな設計判断をして、人間がどこで方向修正をしたのか。その痕跡がコードの中に残っているんです。
リポジトリには CLAUDE.md や AGENTS.md、PLAN.md といったファイルも含まれています。これらはAI支援開発のプロセスそのものを記録したドキュメントです。
従来のOSSは「優れたコードを共有する」ことが中心でした。でもAI前提の開発では、コードだけでなく「どうやって作ったか」自体が他の開発者にとっての価値になるのではないかと考えました。
みんなで遊ぶアプリだから
もう1つの理由はもっとシンプルです。Gen-Jigsawはマルチプレイヤーアプリなので、使ってくれる人がいないと始まらないんですね。
1人で完結するツールなら「まず自分で完成させてから公開する」でもいいかもしれません。でもマルチプレイヤーアプリは、試してくれる人・改良してくれる人がいて初めて育っていくものです。
「作ったから公開する」ではなく、「みんなで広げていくものだから公開する」。Gen-Jigsawのコンセプトとも重なる動機だと思っています。
公開時の注意点 ── 画像生成APIの料金に気をつける
1つ、実際に運用してみて痛感した注意点があります。画像生成APIの利用料金です。
Gen-Jigsawはタイルを追加するたびにDALL-EのAPIを呼び出します。個人で遊ぶ分には大きな問題にはなりませんが、もしWebに公開して誰でもアクセスできる状態にすると、タイル生成のリクエストが積み重なってAPIコストがあっという間に膨らむ可能性があります。
セルフホスティングで試す場合は、以下の点を意識しておくと安心です。
- OpenAI APIキーに**利用上限（Usage Limits）**を設定しておく
- ルームの作成やタイル生成に認証や招待制を導入する
- まずはローカル環境や限定メンバーで試し、公開範囲を段階的に広げる
楽しいアプリだからこそ、コスト面の備えは最初にやっておいた方がいい ── これは実体験からの学びです。
おわりに
今回の開発を通じて感じたことを整理します。
- バイブコーディングはプロトタイプ開発に強力です。アイデアから動くものへの変換が速い。ただし品質の担保には、後からのレビューが欠かせません
- **AI前提アプリのOSS公開は「思考プロセスの共有」**でもあります。コードだけでなく、AIとどう協働したかという情報自体に価値がある時代になりつつあります
- マルチプレイヤーアプリはコミュニティと育てるものです。だからこそOSSにする意味があると感じました
Gen-Jigsawはまだ生まれたばかりのプロジェクトです。興味のある方はぜひリポジトリを覗いてみてください。Issueやプルリクエストも歓迎しています。
- GitHub: kwrkb/gen-jigsaw
- ライセンス: MIT
1枚のタイルから、みんなで世界を広げてみませんか。
コメント