アンチグラビティでチケット予約サイトを作ってみた― システムエンジニア歴26年の私が、本気で驚いた理由 ―
IhyFactory
「ホームページが作れる」程度の話だと思っているとしたら、
このツールの本質は、まだ見えていないかもしれません。
最近話題の アンチグラビティ（Antigravity）。
「プログラミング不要でWebアプリが作れる」という声を聞き、
システムエンジニアとして26年、
数多くの業務システムやWebサービスの現場を経験してきた私は、
正直こう思っていました。
「ふーん、またよくある初心者向けの簡易ツールかな」と。
しかし、2025年4月に IhyFactory として独立し、
経営者の立場で「本当に使えるITとは何か」を考えるようになってから、
このツールを実際に触ってみて、認識が一変しました。
これは単なる制作ツールではありません。
サービスを生み出そうとする“ビルダー”の重力を変えるプラットフォームです。
私が考える「ビルダー（Service Builder）」とは
この記事で言う ビルダー とは、
単に「作業として作る人」ではありません。
- 自分のアイデアを形にして、世の中に届けたい人
- 不便や課題を「仕組み」で解決したい人
- エンジニアではないけれど、サービスを構築（Build）しようとする人
「いつか自分のサービスを持ちたい」
そう考えたことがあるなら、あなたはもう立派なビルダーです。
私自身、長い間「作る側」にいましたが、
独立してから初めて
“サービスを生み出す側の不安” を実感しました。
だからこそ、
技術で立ち止まらなくて済む環境には、大きな価値があると感じています。
実践検証：チケット予約サイトを作ってみた
今回、検証として
実運用を想定したチケット予約サイト を構築しました。
見た目はシンプルですが、
裏側ではデータの整合性が非常に重要になります。
実装した主な機能
- イベント作成・管理
- チケット種類作成（一般・前売りなど複数在庫）
- 予約フォーム
- 仮予約メール送信
- 本予約確定処理
- マイページからの予約変更・キャンセル
- 当日のQRコードチェックイン処理
結論から言うと、
このレベルの仕組みが、数時間で形になりました。
管理画面とユーザー画面が自然に連動し、
予約・在庫・状態が破綻しない。
26年間、「ここが一番壊れやすい」というポイントを見続けてきた身として、
この完成度とスピード感には、正直驚かされました。
エンジニアが本当に驚いたのは「DB」と「SQL」
初心者の方が
「画面が分かりやすい」「操作が簡単」
と感じる一方で、
私が最も衝撃を受けたのは、
データベース（DB）の挙動 です。
DB（データベース）とは何か
DBとは、
情報を整理して保存する箱 のようなものです。
予約システムでは、
- 誰が
- どのイベントを
- 何枚予約して
- 今どんな状態か
といった情報を、
常に矛盾なく管理し続ける必要があります。
通常の開発では何が必要か
従来であれば、
- SQL（データ操作専用の言語）を書く
- 予約登録処理
- 在庫を減らす処理
- キャンセル時に在庫を戻す処理
- 同時アクセス時の制御
こうした処理を、
一行ずつコードで書いてきました。
私自身、
「在庫が合わない」「二重予約が起きた」
そんな障害対応で、
深夜までログを追い続けた経験が何度もあります。
アンチグラビティの凄さ
アンチグラビティは、
この複雑なDB更新処理を、SQLを書かずに成立させています。
ビルダーは、
裏側のロジックで挫折することなく、
サービスの本質（ユーザー体験）に集中できる。
これはエンジニアの仕事を奪うものではなく、
アイデアを形にする速度を極限まで高める仕組み だと感じました。
工程が消えたわけではない、という現実
ここは、どうしても伝えておきたい点です。
アンチグラビティは、
- 要件定義
- 設計
- プログラミング
- テスト
といった工程を、
あたかも存在しないかのように見せてくれます。
しかし、
工程そのものが消えたわけではありません。
従来のシステム開発の流れ
これまで私たちは、
- 要件定義
- 概要設計
- 詳細設計
- プログラミング
- テスト設計
- テスト
- バグ修正
- 再テスト
- 導入
- 保守・運用
こうした工程を経て、
ようやくユーザーが触れる画面を世に出してきました。
場合によっては、ここまでに数ヶ月かかることも珍しくありません。
アンチグラビティは、
これらを 最初から完成形に近い形で提示してくれます。
だからこそ、
「どこで判断が必要か」を知らずに進むと、
後から修正が難しくなる場面が必ず出てきます。
ビルダーが陥りやすい3つの落とし穴
例外処理の抜け
- 戻るボタンを連打されたら？
- メールアドレスを間違えたら？
「正常に使われる前提」だけで考えると、
思わぬトラブルにつながります。
拡張できない設計
最初の設計次第で、
「あとから追加したい」が難しくなることがあります。
セキュリティと権限管理
- 他人の予約が見えてしまう
- URL直打ちで管理画面に入れてしまう
初心者ほど見落としやすいポイントです。
ビルダーがアンチグラビティを賢く使う方法
おすすめしたいのは、この流れです。
- まずは自分で作ってみる
- 触る中で「分からない点」を言葉にする
- 判断が必要な部分だけ、経験者の視点を借りる
すべてをプロに任せきるわけでもなく、
すべてを一人で抱え込むわけでもない。
作れるところは自分で作り、
判断が必要なところだけ経験者の視点を借りる。
このバランスが、今の時代には合っています。
最後に：1人のエンジニアとして、ビルダーへ
アンチグラビティは、
突然生まれた魔法ではありません。
世界中のエンジニアが、
長い年月をかけて積み上げてきた
設計思想と失敗の歴史の上に成り立っています。
「簡単に作れる」からこそ、
どう使うかを考える。
私は、26年のキャリアを過去の自慢にするつもりはありません。
独立したばかりの ビルダーの一人として、
新しいサービスを生み出そうとする人の隣に立ちたい。
もし、あなたのビルドの途中で迷いが生じたら、
いつでも IhyFactory にご相談ください。
あなたのアイデアに、
私の経験を掛け合わせて、
次の一歩を一緒に作れたら嬉しいです。
投稿者プロフィール
