Goでシステムを作ろう、あるいはGoが得意な開発会社へ外注しようと考えたとき、もっとも知りたいのは「実際にどの企業が、どんな課題に対してGoを選び、何がどれだけ改善したのか」という具体的な事例ではないでしょうか。Goはシンプルな文法と高い実行性能、そしてgoroutineによる並行処理のしやすさから、RubyやPHPで作ったサービスが拡大し、性能やスケーラビリティの壁にぶつかったときの「次の一手」として国内事業会社の採用が相次いでいます。だからこそ、抽象的なメリット論ではなく、実名と数値を伴うリアルな導入事例こそが、自社の意思決定にもっとも役立ちます。
本記事は、Goの導入事例・開発事例・活用事例・成功事例を、発注企業の視点から掘り下げる「事例特化」の解説です。RailsからGoへ移行したBaseconnect（Musubu）が独自のDIコンテナ「dicon」やモック自動生成ツール（impast/mocker）まで作り込んだ事例、ウォンテッドリーがAmazon SNSとGoでお知らせ機能のフォールトトレランスを高めた事例、マネーフォワードが帳票APIにgRPC・マスタAPIにRESTを使い分けながら「Goは関数型のfilter/mapがなく記述量が増える」と語った実体験、そしてリクルートの「Goを使って1年」の振り返りまで、媒体名と一次データとともに具体的に解説します。読み終えるころには、Goを「自社でいつ、どの部分に使い、どう失敗を避けながら成果につなげるか」のイメージが描けるはずです。なお、Go開発の全体像をまだ把握していない方は、まずGo開発の完全ガイドから読むことをおすすめします。
RailsからGoへ移行したBaseconnectの事例
Goの活用事例として国内でもっとも参照される型の一つが、RubyやRailsで作ったサービスをGoへ移行する取り組みです。型のないRailsは初速が速い反面、サービスが拡大すると性能や保守性の課題が顕在化しがちで、その「次の一手」としてGoが選ばれます。ここでは、企業データベースサービス「Musubu」を運営するBaseconnect社の実名事例から、何が成功要因だったのかを具体的に見ていきます。
DIコンテナ「dicon」とモック自動生成で支えたGo移行
Baseconnect社は、Rails中心だった構成からGoへの移行を進めるなかで、Go BFF（Backend For Frontend）層を構築しました（媒体：Baseconnect Tech blog）。注目すべきは、移行をただ「言語を置き換える」作業に終わらせず、開発生産性とテスト効率を維持する仕組みまで作り込んだ点です。同社はGoでの依存解決を扱うDIコンテナ「dicon」を独自開発し、コンポーネント間の結合を整理しました。
さらに、テストを書きやすくするためにモックを自動生成するツール（impast／mocker）も自作し、テスト作成の手間を削減しています。Goは標準でテストしやすい言語とされますが、現実の大規模移行では「テストを楽に書ける土台」を整えなければ移行スピードが落ちます。同社の事例は、Go移行の成否が言語選定そのものよりも、こうした周辺の足回り整備にかかっていることを示しています。
加えて同社は、APIレスポンスのHashをそのまま扱うのではなく、Response Layerでプレーンなクラスにマッピングする設計を採っています。レスポンスの型を明確にしておくことで、フロントエンドとの境界が安定し、改修時の事故を減らせます。発注企業にとっての教訓は、「Goへ移行する」と聞いたときに、言語の速さだけでなく、DI・テスト・レスポンス設計といった足回りまで提案に含まれているかを確認すべき、という点です。
Ruby/Rails→Goへ移すべきタイミングの判断基準
Baseconnectのような事例を読むとき、発注企業がもっとも知りたいのは「では自社はいつGoへ移すべきか」でしょう。判断基準を端的に言えば、ユーザー数やデータ量の増加に対してRails/Laravelの性能やインフラコストが見合わなくなり、特定の処理（一覧の集計、非同期処理、内部API）がボトルネックになったときが目安です。逆に、まだプロダクトマーケットフィットを探っている段階で、初速の速いRailsをGoへ置き換えるのは過剰投資になりがちです。
重要なのは、全面移行ではなく「重い部分だけGoへ切り出す」段階的アプローチです。Baseconnectのように既存のRails資産を残しつつ、性能が要るBFFや内部APIをGoで構築すれば、リスクを抑えながら効果を得られます。これは、後述するメリット・デメリットの判断とも直結する論点であり、移行は技術的判断であると同時に投資判断であることを忘れてはなりません。
riplaがフルスクラッチ受託で技術を選ぶ際も、「速く作るフェーズ」と「強く作り直すフェーズ」を分けて考えます。事業の数字（ユーザー数・データ量・売上・機能追加速度の鈍化）を移行のサインとして読み取り、捨てる技術と残す技術を見極めることが、Go移行を成功させる出発点になります。
ウォンテッドリーとマネーフォワードのGo活用事例
Goの真価は、性能と並行処理、そして障害に強い設計にあります。ここでは、ウォンテッドリーがGoで耐障害性を高めた事例と、マネーフォワードがgRPCとRESTを使い分けながらGoの長所と短所を語った事例から、発注企業が学べるポイントを整理します。いずれも「Goを使えば全部解決」ではなく、用途を見極めて投入している点が共通します。
ウォンテッドリーのAmazon SNS＋Goで耐障害性向上
ウォンテッドリーは、お知らせ（通知）機能において、Amazon SNSとGoを組み合わせてフォールトトレランス（耐障害性）を高めた事例を公開しています（媒体：Findy Engineer Lab）。通知のような非同期処理は、一部のサービスが落ちても全体が止まらない設計が求められます。Goのgoroutineによる並行処理と、Amazon SNSのメッセージング基盤を組み合わせることで、処理を疎結合にし、障害の影響を局所化しています。
この事例が示すのは、Goが「単に速い言語」ではなく、「多数の処理を同時にさばき、障害時にも粘り強く動く基盤」を作りやすい言語だということです。通知・メッセージング・バッチといった裏方の処理は、ユーザーの目に触れにくい一方で、止まると信用を失う領域です。こうした非同期・耐障害性が要る部分こそ、Goの並行処理が活きる典型的なユースケースだと言えます。
発注企業への示唆は、「Goを採用するなら、まず通知や内部の非同期処理から試すと効果と相性を確かめやすい」という点です。ユーザー向けの主要画面を一気に作り変えるより、裏方の耐障害性向上から入る方が、リスクが小さく成果も測りやすくなります。
マネーフォワードのgRPC/REST使い分けとGoのクセ
マネーフォワードは、帳票APIにはgRPC、マスタAPIにはRESTを使い分けるという実践的な事例を語っています（媒体：Findy Engineer Lab）。内部のサービス間通信で型を厳密に揃えたい帳票処理にはgRPCが向き、外部にも公開しうる汎用的なマスタ取得にはRESTが向く、という使い分けです。gRPCを内部通信に使えばAPIレイテンシは概ね10〜50msに収まり、性能面でも有利になります。
同時に同社は、Goの正直な短所も明かしています。「Goは関数型言語のようなfilter/mapがなく、コレクション操作の記述量が増える」という実体験です。RubyやJavaScriptに慣れたエンジニアからすると、同じ処理を書くのにforループが増え、冗長に感じる場面があります。これはGoが「読みやすさのために言語機能をあえて絞る」設計思想を取っているためで、性能と引き換えの設計トレードオフです。
発注企業がこの事例から学ぶべきは、「Goは速いが書き味は素朴」という両面を理解したうえで採用判断をすべき、という点です。記述量の増加は学習や工数に影響するため、提案を受ける際は「なぜその通信方式（gRPC／REST）を選ぶのか」「Goのクセをどう運用でカバーするのか」を確認すると、技術選定の妥当性を見極めやすくなります。
リクルートの「Go1年」とサービス分割の事例
大規模サービスを抱える企業ほど、モノリスをどう分割し、どの言語で何を担うかという設計が成果を左右します。リクルートは、SpringとRailsでサービスを分割しつつ、新たにGoを導入した「Goを使って1年」の振り返りを公開しています（媒体：リクルート テックブログ）。長く使った言語と新しい言語をどう共存させたか、という現実的な学びが詰まった事例です。
「Goを使って1年」が示す導入後のリアル
リクルートの「Goを使って1年」の振り返りは、導入直後の高揚ではなく、一定期間運用したうえでの評価である点に価値があります（媒体：リクルート テックブログ）。Goは学習コストが比較的低く、文法がシンプルなため、チームへの定着が早いとされます。一方で、慣れたRubyやJavaから移ったエンジニアにとっては、前述のfilter/mapの不在のように、書き方を変える必要がある場面もあります。
1年という期間の振り返りは、発注企業にとって「導入してすぐではなく、運用してから真価が問われる」ことを教えてくれます。短期のベンチマークやデモではなく、保守・改修を1年続けたときにチームが回るかどうか——これが技術選定の本当の評価軸です。Goは標準ツールが充実し、フォーマッタやテストが標準装備のため、長期運用での「コードの荒れにくさ」が評価されやすい言語です。
発注の現場では、「導入実績」を聞くだけでなく「導入後どれくらいの期間、どう運用しているか」を確認すると、提案の地に足のつき方が見えてきます。1年運用してなお選ばれ続けているなら、その技術は自社でも長く付き合える可能性が高いと判断できます。
Spring・Rails・Goを共存させるサービス分割設計
リクルートの事例で特筆すべきは、Goへ全面移行したのではなく、SpringとRailsとGoを共存させている点です（媒体：リクルート テックブログ）。STORESがRuby on RailsとSpringの双方を実務で使い分けている事例（媒体：STORES Product Blog）と同様に、大規模サービスでは「1言語ですべてを賄う」より「役割ごとに最適な言語を割り当てる」方が現実的だという示唆があります。
このマルチ言語構成は、クックパッドが100万行超のモノリシックRailsをマイクロサービス化した事例（媒体：AMBI）や、メルカリWebが4年がかりでマイクロサービス化を進めた事例とも地続きです。サービスを適切な単位に分割すれば、性能が要る部分にだけGoを使い、開発速度が要る部分はRailsのまま残すといった柔軟な設計が可能になります。Goはそのなかで、BFFや内部API、性能が要る処理を担う「適材適所のピース」として組み込まれています。
発注企業への教訓は明確です。「Goに乗り換えるか否か」という二択ではなく、「どの部分をGoに任せ、どの部分を既存言語に残すか」という設計判断こそが重要だということです。複数言語を共存させる前提なら、サービス間の境界（APIの型・通信方式）を最初に固めておくことが、後の保守性と引き継ぎ性を大きく左右します。
まとめ
Goの活用事例を振り返ると、成功の共通点は「Goを万能の新言語として全面採用する」のではなく、「性能・並行処理・耐障害性が要る領域に適材適所で投入する」という一点に集約されます。BaseconnectのRails→Go移行は、dicon（DIコンテナ）やimpast/mocker（モック自動生成）で足回りを整えたうえで段階的に切り出した理想形であり、Response Layerによるレスポンス設計が保守性を支えています（媒体：Baseconnect Tech blog）。
ウォンテッドリーのAmazon SNS＋Goは耐障害性の高め方を、マネーフォワードのgRPC（10〜50ms）／REST使い分けは通信設計の考え方とGoのクセ（filter/mapがなく記述量増）を、リクルートの「Go1年」とSpring・Rails・Go共存はマルチ言語での適材適所を、それぞれ教えてくれます（媒体：Findy Engineer Lab／リクルート テックブログ）。自社が「どの部分をGoに任せ、どの部分を既存言語に残すか」を見極め、まずは非同期処理や内部APIなど一部から検証する一歩を踏み出してください。riplaはフルスクラッチ受託と国内開発を組み合わせ、事業から逆算した技術選定と体制づくりを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。