⚫

AI でウェブサービス開発をして公開するまでの話

に公開
テーマ「この春、始めたこと」
Firebase
Cloudflare
囲碁
Gemini
AI コーディング
tech

1. はじめに

本記事は、ゼロベースで AI にウェブサービスを開発してもらって世の中に公開するまでのお話です。 AI でシステム開発したという話は NTT データさんの「設計書・コード・テストを全部AIに書かせて半年間開発してみたよ」などもあるのですが、ビジネスクライアント向けプロダクトであることもあり、具体的な内容に関する言及がどうしても少なくなっています。そこで、本記事ではさらに踏み込んで、具体的な生産性や技術スタックなどについても言及した上で、 AI による開発の事例を紹介します。

2. 開発したもの

囲碁のノート という囲碁に特化したノート共有サービス（ユーザー生成コンテンツサービス）を開発しました。

ちなみに LP の囲碁の写真は AI で画像生成したわけではなく、下記の写真を利用させてもらいました。

AI でもそれっぽい写真は生成できるようになってきてはいるのですが、よく見ると線がだまし絵のようになっていたりします。せっかく囲碁界を盛り上げるために商用利用可能なフリー素材を作っている方がいるので、利用させてもらうのが良いでしょう。

3. なぜ開発したか

数年前、たまたまテレビをつけたら囲碁番組をやっていたことがきっかけで、久しぶりに『ヒカルの碁』を読んだらハマったのと、ちょうど自分の子どもが習い事を始める時期で思考や礼儀を身につけさせる習い事として囲碁は良さそうだなと思ったことが重なり、子どもと一緒に自分も一緒に囲碁を習い始めました。

囲碁を学ぶ際に書籍は潤沢にあるのですが、ウェブ上で情報を集めようとしたときにいくつか課題を感じました。 X や YouTube は新しい情報がたくさん流れてくるのですが、一方的な発信であるため、自分で同時に検討がしづらい（碁盤の情報を手元に再現しづらい）という問題があります。また、囲碁のウェブサービスについては対局、詰碁、学習動画などが主なコンテンツとなっていて、囲碁の情報という観点ではインプットが主体となっています。

学習はインプットとアウトプットが対になっています。インプットは書籍や YouTube で充実していますが、「棋譜を動かしながら自分の思考を言語化する」というアウトプットに関しては、汎用的な SNS では機能不足を感じました。

囲碁特化型のインタラクティブなノート環境が欲しいと考えましたが、私自身フロントエンド主体のアプリケーションは詳しくありません。そこで、仕様策定からコーディング、デプロイまで、 AI をフル活用したらどこまでいけるかを検証しつつ開発したのが、この囲碁のノートです。

4. 開発プロジェクト

4.1. 開発メンバー

4.1.1. 私

今回の開発では AI にプロンプトを入力し、 AI の指示に従って動く、でも AI に何でも任せるのはさすがに怖すぎるのでチョットダケ自我がある生体インターフェイスです。

4.1.2. AI（Gemini さん）

今回の開発では Gemini（最初は 2.5、途中から 3.1）のみ使いました。

Google Workspace に Gemini があったのでこれから使い始め、問題があれば別の AI を検討しようと思っていましたが、最終的に特に問題なく Gemini で進められたため、他の AI は検討もしていません。

最初は Google Workspace で利用できた Gemini ウェブアプリから利用をはじめました。ある程度ボリュームがでるまではウェブアプリのみで開発を進めました。適度に利用制限がかかるようになったタイミングで課金（AI Ultra Access）し、ウェブアプリの Gemini ではプロジェクト全体が把握できなくなってきたところでローカルの開発環境に移行しました。最終的には AI コードエディターの Google Antigravity に落ち着いています。

ちなみに Gemini のことは普段は「Gemini さん」（じぇみにさん）と呼んでいます。本文でも今後 Gemini さんと呼びます。

4.2. 開発期間

2026 年 1 月から 5 月までの話（既に公開していますが、開発は鋭意継続中です）。基本的な部分は最初の 2 ヶ月くらいでできて、後は細かい修正の繰り返しです。なお、フルタイム稼働ではなく、本業[1]の傍らの余暇を利用して開発したので、公開までの実際の開発工数は 1.5-2 人月程度だと思われます。

後述のサービス構成図を見るとわかるように単純に見えて割と複雑なシステムなので、一般的なソフトウェア開発会社が古典的な見積手法を用いると 20 人月は超えてくるかと思います。ざっくりと AI（Gemini さん）のサポートによるパフォーマンスは人間の 10 倍くらいあると考えられます（誇張表現[2]）。

4.3. 開発コスト

最初の 3 ヶ月間はウェブアプリで開発していたため、もともと利用していた Google Workspace の付属品と考えれば実質 0 円です。 2 ヶ月くらい AI Ultra Access（月額 3 万円程度）を利用しているので、これまでで 6 万円くらいかかっています。開発環境のランニングは 0 円です（無料範囲内）。

4.4. 開発手法

最初は単一ファイルのモックから始めて徐々にプロジェクト規模の構成に移していきました（後述の「リファクタリング」を参照）。そこからはマイルストーンとタスクを Markdown で記述し、 Gemini さんが全体把握しやすいようにリポジトリ内で管理しています。集計のための簡易スクリプトを Gemini さんが作ってくれたので、タスクを進める際のワークフローとして利用しています。

ちなみに途中から GitHub を利用し始めたので GitHub でイシュー管理をしようと思ったのですが、 Gemini さんと相談したら「個別のタスクが GitHub で管理されていることは構わないが、全体の関連やこれまでのノウハウの知見という意味だと GitHub に存在するその他のタスクはコンテキスト外に追いやられてしまうので、一定レベルでの記述はリポジトリ内に残しておいた方が良い」みたいなことを言ったので、じゃあリポジトリ内で管理するかといった感じです。

5. 設計

5.1. 技術スタック

  • Node.js
  • Firebase/GCP（バックエンド）
    • Authentication
    • Hosting
    • Cloud Storage
    • Firestore
    • Cloud Run
    • Google Analytics 4（GA4）
  • Cloudflare（CDN）
  • OpenCV（画像解析）
  • ONNX（AI 解析）
  • Algolia（全文検索）
  • Resend（メール配信）
  • GitHub Actions（CI/CD）

5.2. サービス構成図

囲碁のノートのサービス構成図は概ね以下の通りです。

6. AI に解決してもらった課題

今回の開発では以下のようないくつか難しいポイントがあったと思いますが、（こちらの意図も多少与えつつ） Gemini さんに聞いたら大体何とかしてくれました。

  • インタラクティブ碁盤
  • リファクタリング
  • バックエンドアーキテクチャ
  • CI/CD
  • SPA + SSR + CDN
  • AI 解析
  • 画像認識
  • 全文検索、棋譜検索
  • メール配信
  • PV 集計

6.1. インタラクティブ碁盤

最初は単一の HTML で碁盤が操作できるという簡単なものから実装を始めました。何となく既存の JavaScript ライブラリーを利用するところから始めるんだろうなと思ってプロンプトでも既存のライブラリーの名前を挙げながら進めていましたが、全然動きませんでした。

ある時突然 Gemini さんが自前でのサンプル実装をはじめ、それが動作したことから意図せずスクラッチ開発になりました。独自機能を載せるときにライブラリー特有の何かにぶつかることはなかったので、結果良かったのだと思います。特に、囲碁の棋譜を扱うのに SGF という標準的なフォーマットがあるのですが、意外と奥が深く、これらをサービスで必要な分だけサポートするためには、既存のライブラリーだけでは難しかったかもしれません。

6.2. リファクタリング

単一 HTML からアプリケーションとしての体裁をなすまでの間にすでにコードの肥大化が発生し、 Gemini ウェブアプリではファイルの修正が正しく行えないケースがありました。 Flash はもちろん Pro でも機能の欠落などを起こし、使い物にならなくなってきました[3]。

適当にウェブアプリケーションとして成り立つような実装モデルを検討してもらい、クライアントサイド MVC にリファクタリングされました。 React や Vue などのモダンフレームワークに移行する可能性もこのタイミングであったように思いますが、ある程度の単位に適切に管理さえされていれば AI にとってはどちらでもそんなに違いがないように思います。同様に TypeScript に移行することも可能であったと思いますが、適切な単位に分解されたコードであれば AI は文脈ベースで自然と正しいシグネチャを推論できるので、人間が介在しない本プロジェクトにおいては型を適切に設計するということ自体が AI の作業コストになってしまう可能性があり、 JavaScript のまま進めている現状が最適なのかもしれません。この辺りは機会があれば別のプロジェクトで別の進め方をして比較してみたいものです。

次の大きいリファクタリングは碁盤エディター機能でした。碁盤エディターは描画ロジック、操作ロジック、囲碁のルールロジック、外部サービス連携（AI 解析）などが複雑に絡み合っており、修正が別のバクを生むような状態でした。 Gemini さんなら一定の巨大コードになってしまっても適切に修正を入れられると期待していたのですが、タスクに対して近視眼的になるので他の影響を無視してバグになってしまうようでした。

MVC にしろ巨大コントローラー（碁盤エディター）にしろ、関心領域ごとに適切に分割して疎結合にすることで、変更が別のバグを生むという状況を解決できます。このあたりは人間の開発と同じですね。

6.3. バックエンド

バックエンドサービスの選定にあたっては、コスト要件が割と大きいファクターを占めていたので、料金を抑えやすい環境を選定してもらいました。最終的な判断ポイントはドキュメント DB か RDB か（Firebase か Supabase か）というところですが、サービスの性質上書き込みが少なく、一つのドキュメント内に非正規化した情報を詰め込んで読み取りコストを減らす方針（fan-out による N+1 問題への対応）がとれるとのことでドキュメント DB に軍配が上がりました。判定材料を出したのも軍配を上げたのも私ではなく Gemini さんですが。

6.4. CI/CD

サービス構成図には記載がありませんが、 GitHub Actions でテストやビルド、デプロイを回しています。小規模開発なのでローカル環境（emulator）、開発環境（development）、本番環境（production）の 3 系統しかありません。ブランチやタグによって開発環境にデプロイするか本番環境にデプロイするかが決まります。

Gemini はコード内にいろいろとハードコーディングしがちなので、環境依存の部分を環境変数（シークレット）に切り出しているのですが、油断するとハードコードされます。特にドメインがハードコードされると環境問題が発生して大変です。ある程度熟練すれば専用エージェントなんかで解決できる問題なのかもしれませんが、現状では「人間ががんばる」でなんとかやってます。

なお、単体テストについては単純に作成してもらうと観点漏れが多く、メインの実装に比べて細かく指示してやる必要がありました。単体テストはカバレッジを上げることをあまりせず、セキュリティールールなどの重要なコアロジックのみ重点的に実装し、 E2E テストについてもクリティカルパスのみ通れば良しとしています[4]。 AI は高速で変更を加えることができるので、細部が壊れても全体的な整合が保たれていれば大丈夫です。どちらかというと素早く直せるということの方が重要だと思います。

6.5. SPA + SSR + CDN

これもバックエンドアーキテクチャのコスト要件に関わってくるのですが、 Firebase はデータのアクセス数に対してコストがかかるため、データの読み取りを極力抑えるための仕組みが必要です。 CDN で読み取り回数を抑えたいのですが、囲碁のノートには限定公開や予約公開のような機能があるため、 Firebase Hosting だけでは成り立ちません。そこで Cloudflare Workers/KV を利用してエッジサーバー上でアクセス許可判定を行うようにしています。 Cloudflare Workers KV は読み取りに比べて無料枠では書き込みの制限が強いので、書き込み回数を減らすような工夫も実装されています。

6.6. AI 解析

囲碁にかかせない AI 解析ですが、オープンソースの KataGo を利用しています。

最初はコストを抑える目的でクライアントで解析させるようにしました。モデルを ONNX に変換し、クライアントでモデルをダウンロードして推論を実行することで、モデルの通信コストのみで AI 解析ができることを期待したわけです。

実際に動かしてみたところ 1 局面分の計算だけで処理に時間がかかり[5]、通常の AI 利用のように探索[6]を行うのは難しい状態でした。これでは AI 機能が利用できるなどとサービスで謳うことはできません。

そこで、クライアントサイドに加えて、サーバーサイドでも KataGo を動かせるようにしました。ただしサーバーとして KataGo を動かせば、当然動いているだけコストがかかってしまうので、 Cloud Run で解析リクエストがあるときのみ動くようにし、 WebSocket で接続して連続解析を実現しました。 Cloud Run であれば同時最大インスタンス数がコントロールできるので、上限コストを見積もることができます。

ただしやはり本質的にはクラウドコストは抑えたいので将来的にはクライアント完結するような何かが作れると良いなと思っています。 Gemini さん、がんばって。

6.7 画像認識

碁盤を写真に撮影して、写真画像から碁盤の状況を再現できる機能も実装しています。候補としては、 OpenCV などの古典的な画像解析手法を用いたもの、 CNN 系の深層学習を利用したもの、 LLM API を利用したものが挙げられました。それぞれ Gemini さんがプロトタイプが実装したところ、 CNN 系の深層学習は汎用学習済みモデルを利用しても精度が悪く、自分で学習する気にもなれなかったので OpenCV vs LLM になりました。チューニングのしやすさ、ランニングコストといった観点で、決定論的な出力が得られ、かつクライアントサイドで運用コストゼロで動かせる OpenCV が最終的に選択されました。

碁盤はサイズが 9 路盤、 13 路盤、 19 路盤と可変であったり、 19 路盤は大きいので写真から碁盤がちょっとはみ出て碁盤判定が難しいといった問題が山積みです。特に後者については外挿処理は精度が悪く、一定レベルの人力補正が必要という状態です。でもそういった割り切りもサービス開発あるあるですね。

ファーストチャレンジで精度が悪かった時に Gemini さんはつい「別の方法を試しましょう」と言ってくるので、それをなだめてチューニングさせていくのがなかなか骨が折れる作業でした。あとデータ解析系のあるあるだと思いますが、「こんな感じで実装して」と「実装できました」の間で厳密にロジックをチェックすると乖離していることがよくあるので、注意が必要です。今回のような解析では、手法がバグっていても精度が出ればよいので特に問題はありませんが。

最初は何となく目で確認してこれでいいかなから始めていたのですが、もう少し精度が欲しくなって定量的にやりたくなってきたときに、正解データをためておくために Gemini さんにアノテーションツールを作ってほしい、ついでにアノテーションの結果を利用して画像解析の結果を確認したいとお願いしたら一瞬でできました。このレベルでできるのであれば、アプリケーションに載せてしまって有志なりクラウドワーカーなりを募ってアノテーションをお願いするということも現実的にやろうと思えばできてしまうわけですね。

アノテーション

精度検証

6.8. 全文検索、棋譜検索

Firebase では全文検索が難しいので Algolia を検索エンジンとして利用しています。棋譜の情報も適宜抽出してインデックスに投入することで、棋譜の内容を含めた全文検索や閲覧権限に応じた検索が実現できています。とはいえ具体的にどのような棋譜の情報を抽出するかといったことに関しては今後検討が必要です。

6.9. メール配信

Firebase（Firestore）の Trigger Email 拡張を利用しています。 Firestore の対象コレクションにメールの内容を保存するだけで拡張機能がメールを適切に送信してくれます。自分で再送処理などを実装しなくて良いのはありがたいですね。

6.10. PV 集計

Firebase の標準機能として Google Analytics（GA）連携できることから、 GA で PV を取得しています。 GA だとトラッキング拒否される場合もあって厳密には正しい PV は得られないのですがそこは気にしません。 GA はデータが確定するまでに最大 48 時間のラグがあるので、確定したデータを取得するバッチと、最新のデータを取得するバッチの 2 本立てとしています。 Gemini さんはそういうことは知っているのに、 CDN のキャッシュ時間とミスマッチした集計サイクルを設計するなど CDN の存在を忘れてしまい、全体が把握できていない感じがしますね。

7. 今後の展望

現状のサービスだと特に AI 解析の部分で支出ばかりになってしまうので、記事の有料化や有料アカウントなどのサービスを進めていく予定です。これについても既にある程度 Gemini さんに方針を立ててもらっていますので、実装に着手すれば基本機能は一両日あればでできるのではないかと予想しています。機能をリリースするべきタイミングであったり、お金が絡むので規約まわりの修正等を弁護士（人間）に相談があったりと、いろいろと考慮すべきことはありますが。

8. まとめ

これまで AI 駆動の開発はやったことがなかったのですが、今回の開発を通じて AI を利用して爆速で開発できることがわかりました。まだ全体を把握するマネージャー的な役割の人間がいないとうまくいかないような部分もありますが、それは要件を決めるという役割が人間にしかできないことに起因しているので、逆に人間にしかできないことを除けば AI にお願いできるようなレベルにあるとも言えそうです。より正確に言えば、今回のケースでは自分が意思決定を担う役割を担っていたのでところどころで AI の判断に誤りがあるということがありましたが、役割を人間が決めるということを放棄しても問題ないような場面であれば、 AI ですべてまかなえるようになったのだと思いました。

脚注

  1. コネクトデータというデータ利活用のコンサルや開発などの B2B 企業をやっています。問い合わせフォームからお仕事のご相談お待ちしております。 ↩︎

  2. 念のために説明すると、 20 人月はひとりの人間が 20 ヶ月作業した場合に完了する分量のタスクを表しますが、そもそも「ひとりの人間」がこなせる作業量が異なることに注意が必要です。 ↩︎

  3. ちなみに基本的に開発は Pro にしか任せられないです。当初は AI Ultra Access を利用していなかったので Pro 利用に関する制限が強く、気づくと Flash になっていて頓珍漢なことをやらかす（機能を落としたり勝手に解釈を変えて関係ないことを始めたり）というのをよく繰り返していました。これは相当なストレスだったので、課金して精神的安寧を保てるというのは良いことです。 ↩︎

  4. クリティカルパスに相当する要件は適宜 Markdown ファイルとしてリポジトリ内に出力し、 Gemini さんから都度参照可能な状態としています。 ↩︎

  5. モデルにもサイズが複数あり、サイズの小さな軽量なモデルを利用することで計算時間が緩和されるはずですが、軽量モデルは互換性がなく、最新モデルと同じように単純には動かすことができませんでした。 ↩︎

  6. 囲碁や将棋といったボードゲームでは、モデルによる盤面のポリシー評価（どこに打てば良さそうか）とバリュー評価（どのくらい勝ってそう、負けてそうか）が推論にあたります。これを補完すべく、読みに相当するシミュレーション処理（よく行われるのはモンテカルロ木探索と呼ばれる手法）を通常は行うのですが、前半の推論部分だけで計算コストが大きく、モバイルなども含めた多様な環境下においてはシミュレーション部まで到達しなかったということです。 ↩︎

Discussion