AI Session Notes - 2026-03-27

Go が Web バックエンドに選ばれる本当の理由

学んだこと

• Go が Web 開発に向く理由は goroutine（並行処理）ではなく、運用面の強さが主因
• ビルドが速くて楽: シングルバイナリにコンパイルされ、依存ランタイム不要でデプロイできる
• メモリフットプリントが小さい: Python/Node.js/Java と比べてプロセスのメモリ消費が少ない
• 起動が高速: JVM のようなウォームアップが不要。コンテナのスケールアウト時にすぐリクエストを受けられる
• コンテナ向き: 上記すべてが合わさり、Kubernetes 等での運用と相性が良い
• 典型的な CRUD アプリ（DB を読み書きするだけの Web）では、ボトルネックは DB の I/O 待ちであり、goroutine の並行処理能力はあまり関係ない。この程度なら Node.js の async/await や Python の非同期でも十分対応できる

goroutine が真価を発揮するケース

• goroutine が活きるのは「DB の読み書き以外の仕事が重い」ケース:
• リアルタイムチャット / 通知システム: 数万ユーザーが WebSocket で常時接続。1 goroutine ≒ 数 KB なので 1 プロセスで数万〜数十万接続を捌ける
• API ゲートウェイ / アグリゲーター: 1 リクエストに対して裏で複数のマイクロサービスを同時に呼び、結果をまとめて返す
• ストリーミング処理: ログ収集サーバー、IoT デバイスからのデータ受信など
• プロキシ / ロードバランサー: Traefik、Caddy など Go 製のプロキシが多い

アプリ	やること	ボトルネック	goroutine の恩恵
ブログ、EC サイト	DB 読み書き	DB の I/O	少ない
チャットサーバー	数万接続を維持	接続数 × メモリ	大きい
API ゲートウェイ	複数 API を並行呼出	外部 API の応答待ち	大きい

プロセス・スレッド・goroutine の違い

学んだこと

• プロセス: アプリそのもの。自分専用のメモリ空間を持ち、他のプロセスとは完全に独立。起動にもメモリにもコストがかかる（重い）
• スレッド: プロセスの中の作業員。プロセス内のメモリを共有して使える。プロセスより軽いが、1 本あたり約 1MB のメモリを消費する
• goroutine: Go 独自の「めちゃくちゃ軽いスレッドのようなもの」。1 個あたり数 KB のメモリ消費で、スレッドと比べて桁違いに軽い

スレッド:   1 本 ≒ 1MB   → 1 万本 = 10GB
goroutine: 1 個 ≒ 数KB  → 1 万個 = 数十MB

Rails の同時処理モデルと Go との使い分け

学んだこと

• Rails（Puma）はワーカー（プロセス）× スレッドで同時リクエスト数が決まる。例: ワーカー 3 × スレッド 3 = 同時 9 リクエスト
• 通常の CRUD リクエストは数百 ms で完了しスレッドがすぐ空くため、この構成で十分に捌ける
• WebSocket の場合は話が変わる: 接続している間ずっとスレッドを占有するため、同時接続数がスレッド数に制限される
• Rails: 1 万人接続 → スレッド 1 万本 → メモリ数十 GB（現実的に厳しい）
• Go: 1 万人接続 → goroutine 1 万個 → メモリ数十 MB（余裕）

Rails と Go の適材適所

	Rails	Go
強み	CRUD 中心の Web アプリ。開発速度が圧倒的に速い	大量の同時接続、リアルタイム処理、高トラフィック
具体例	EC サイト、管理画面、ブログ	チャット、リアルタイム対戦ゲーム、プロキシ

• 実際の現場では「メインの Web アプリは Rails、チャット機能だけ Go のマイクロサービス」という構成もよくある

リアルタイム対戦ゲーム（大富豪のような）が Go に向く理由

• ブラウザで複数人が常時接続してゲーム状態を共有する仕組みは、WebSocket の常時接続が前提
• 誰かがカードを出したら即座に全プレイヤーにブロードキャストする必要があり、goroutine の軽さが活きる
• Go はコンパイル済みネイティブコードで処理が速く、GC の停止時間も短いため低レイテンシが求められるゲームに適している

メタ情報

• ツール: Claude Code
• 関連技術: Go, goroutine, Ruby on Rails, Puma, WebSocket, プロセス, スレッド, コンテナ, Kubernetes