はじめに
直近の個人開発では、Java（Spring Boot）を使って医療系アプリを開発したのですが、今回はさらに高い壁に挑戦したくなり、モダンなバックエンドの筆頭であるGo言語（Gin）を使ったリアルタイム駆動型のカンバンボードプラットフォーム「FlowDeck」を構築しました。
現実、完全未経験のGoでWebSocketの並行処理やRedis Pub/Subを組み上げるのは、生成AI（Claude）のサポートなしでは100%不可能でした。特にきつかったのは、Go の書き方にも、リアルタイム通信にもあまり慣れていなかったことです。無理ゲーです。
したがって今回は、AIを「技術の本質を理解するためのペアプログラマー」として徹底的に使い倒して開発したことで、
「どこで詰まったか」
「何が難しかったか」
「どうやって抜けたか」
を、できるだけそのまま書きます。
1. まず、Goの時点でかなり苦戦した
今回のバックエンドは Go で作りました。
選んだ理由は、なんとなく「速そう」「リアルタイム処理に向いていそう」というイメージがあったからです。
あと、転職活動において、武器として強そうだったからです。
ただ、実際に触ってみると、最初の印象はかなり厳しかったです。
普通のCRUDならまだしも、WebSocket を使って複数ユーザーの状態を同期させようとすると、一気に話が難しくなります。
特にしんどかったのは、接続中のユーザーをどう管理するかです。
「ひとりずつの接続を覚えておいて、誰がどのボードを見ているかを管理して、切断されたら後始末もする。」
言葉にすると単純ですが、実際にコードにすると全然うまくまとまりませんでした。アノテーションが充実していたSpring Bootとはレベルが違い、記述の仕方の見当もつけることが出来ませんでした。
ここは生成AIにかなり助けられました。
ただコードを出してもらうだけでなく、
「なぜこの形にするのか」
「切断されたときはどう処理するのか」
「どこが壊れやすいのか」
をひとつずつ聞きながら進めました。
正直、AIがなかったら最初の実装段階で止まっていました。
2. ローカルでは動くのに、本番を考えると急に不安になる
WebSocket でリアルタイムに動くものを作っていると、ローカルでは問題なくても、本番を考えた瞬間に不安が一気に増えます。
たとえば、サーバーが1台ならなんとか動いていても、あとから台数が増えたらどうなるのか。
ユーザーAがAサーバー、ユーザーBがBサーバーにつながったとき、ちゃんと同じ状態を見られるのか。
このあたりを考え始めると、「あれ、これ思ったより簡単じゃないぞ」となりました。
リアルタイム処理は、画面に表示されているものを動かすだけでは終わりません。
裏でちゃんと同じ状態を共有できていないと、すぐにズレます。
このズレがあると、使っていてかなりストレスになります。
そこで、サーバー同士でイベントをやり取りする仕組みとして Redis の Pub/Sub を使う形に変えました。
「誰かがカードを動かした」という情報だけをGo サーバーが全部をひとりで抱えるのではなく、Redis 経由で他のサーバーにも伝える形にしました。（これも生成AIから薦めてもらったことです。）
このへんは技術的にはそれなりに難しいのですが、Upstash Redisなど、クラウドサービスが充実していたので、何とか実装出来ました。
3. Next.js も、ただの画面作りでは終わらなかった
フロントエンドは前回同様、 Next.js で作りました。
ここも普通のフォームや一覧画面だけならまだしも、リアルタイムで状態が変わる画面にすると、急にややこしくなります。
カードを動かしたら即座に反映される。
他のユーザーが触った変更もすぐ見える。
この「すぐ」があるだけで、画面の作り方がかなり変わります。
単にuseStateを更新すれば終わり、ではなくて、
「いつサーバーに送るか」
「受け取った更新をどう反映するか」
「画面が一瞬おかしく見えないか」
みたいなことを考えないといけません。
Next.js は便利ですが、こういうリアルタイム系の挙動を入れると、急に自由度の高さが難しさに変わります。
ここも、見た目をきれいにすることより、まず壊れないことを優先しました。
おしゃれさよりも、ちゃんと動くこと。
この順番を守るだけでも、かなり作業しやすくなりました。
4. 生成AIは「答えを出す道具」より「詰まりどころを整理する道具」だった
今回いちばん感じたのは、生成AIはただコードを吐かせるためのものではなかった、ということです。
むしろ役に立ったのは、
何が分かっていないのかを整理すること
難しい仕組みを、まず小さく分解すること
実装したあとに、どこが危ないかを見直すこと
でした。
Go の並行処理も、WebSocket の接続管理も、Redis を挟んだ構成も、最初から全部理解して進めることは私には到底できません。
わからないところを AI に投げて、返ってきた説明をまた自分で噛み砕いて、何とか形にしていった、という感じです。
「AIがあるから簡単に実装出来た」
というより、
「AIがないと、たぶん途中で諦めていた」
のほうが近いです。
5. 作ってみて分かったこと
今回の開発で痛感したのは、リアルタイム系の開発は見た目以上に難しい、ということでした。
画面が動くのは当然で、その裏で
接続が切れたらどうするか
複数人が同時に触ったらどうなるか
サーバーが増えたらどう崩れるか
エラーが出たらどこを直すか
まで考えないといけません。
しかも、Go は普通のWeb開発より少しクセがあります。
だからこそ、ただ動くだけでかなり達成感がありました。
おわりに
今回は、Go × WebSocket × Redis で、リアルタイムに動くカンバンボードを作りました。
正直、最初はかなり無謀だったと思います。
Go も、リアルタイム処理を前提としたNext.js も、思っていたよりずっと難しかったです。
それでも、生成AIに助けられながら少しずつ進めたことで、
「難しいものでも、分解すればなんとか形になる」
という感覚はかなりつかめました。
ソースコードや構成の詳細は GitHub にまとめました。
https://github.com/MasahiroTatsuta/FlowDeck