Goは、高い実行性能と並行処理のしやすさから、RubyやPHPで作ったサービスが拡大した後の「次の一手」として、国内で採用が相次いでいます。
Goで開発を任せる会社を探すとき、知りたいのは、どの企業がどんな課題にGoを選び、何がどれだけ改善したのかです。だからこそ、抽象的なメリット論より、実名と数値を伴う導入事例のほうが自社の判断に役立ちます。事例ごとに見ていきます。全体像をまだ把握していない方は、先にGo開発の完全ガイドをご覧ください。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
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移行の成否が言語選定そのものより、こうした周辺の整備にかかっていると読み取れます。移行の提案に周辺の整備が含まれているかは、投資の中身と、その説明の深さの二つから見えてきます。
- 周辺の仕組み：移行の提案に、DIやテスト、レスポンス設計への投資が書かれているか
- 説明の具体性：周辺の仕組みを、なぜ、どう作ったのかまで説明できるか
同社は、APIレスポンスのHashをそのまま扱わず、Response Layerでプレーンなクラスにマッピングする設計を採っています。レスポンスの型を明確にしておくと、フロントエンドとの境界が安定し、改修時の事故を減らせます。
発注企業にとっての教訓は、「Goへ移行する」と聞いたときに、言語の速さだけでなく、周辺の仕組みまで提案に含まれているかを確認することです。
Ruby/Rails→Goへ移すべきタイミングの判断基準
Baseconnectのような事例を読むとき、発注企業がもっとも知りたいのは「では自社はいつGoへ移すべきか」でしょう。
判断基準を端的に言えば、ユーザー数やデータ量の増加に対してRails/Laravelの性能やインフラコストが見合わなくなり、一覧の集計、非同期処理、内部APIといった特定の処理がボトルネックになったときが目安です。逆に、まだプロダクトマーケットフィットを探っている段階では、初速の速いRailsをGoへ置き換えると過剰投資になりがちです。
重要なのは全面移行ではなく、「重い部分だけGoへ切り出す」段階的なアプローチです。Baseconnectのように既存のRails資産を残しつつ、性能が要るBFFや内部APIをGoで構築すれば、リスクを抑えながら効果を得られます。
移行は技術的な判断であると同時に投資の判断でもあり、後述するメリット・デメリットの判断とも直結します。移行の判断は、まずどの処理が壁になっているかを言えるかどうかから始まります。あわせて、既存のRails資産のうち何を残し、何を手放すかも決めておく必要があります。
- 自社の現状：どの処理が性能やコストの壁になっているかを、具体的に言い表せるか
- 残す資産：既存のRails資産のうち、残す部分と手放す部分を分けて考えられているか
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を入れる部分では、障害時の振る舞いをあらかじめ確かめておくことが欠かせません。
- 障害の影響範囲：一部が落ちたとき、影響がどこまで広がるかを把握しているか
- 効果の測り方：変更前後で、障害時の挙動をどう比べるかを決めているか
発注企業への示唆は、「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が「読みやすさのために言語機能をあえて絞る」設計思想を取っているためで、性能と引き換えの設計トレードオフです。通信方式を選んだ理由と、記述量の増加への備えは、提案で確かめたい二点です。
- 通信方式の理由：gRPCとRESTを用途ごとに選んだ根拠が説明されているか
- Goの書き味への対策：記述量の増加を、学習や運用でどうカバーするか
発注企業がこの事例から学ぶべきは、「Goは速いが書き味は素朴」という両面を理解したうえで採用を判断する、という点です。記述量の増加は学習や工数に影響するため、この両面を前提にしておくと判断を誤りにくくなります。
提案を受けるときは、この二点を押さえると、技術選定の妥当性を測る材料になります。
リクルートの「Goを使って1年」とサービス分割の事例
大規模サービスを抱える企業ほど、モノリスをどう分割し、どの言語で何を担うかという設計が成果を左右します。リクルートは、SpringとRailsでサービスを分割しつつ、Goも取り入れています。
また、新たにGoを導入した後の振り返り「Go1年」を公開しています（媒体：リクルート テックブログ）。長く使った言語と新しい言語をどう共存させたか、という現実的な学びが詰まった事例です。
「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に乗り換えるか否か」という二択ではなく、役割の割り振りという設計判断が問われる、ということです。
複数言語を共存させる前提なら、サービス間の境界（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がなく記述量が増える）を教えてくれます。
リクルートの「Goを使って1年」の振り返りとSpring・Rails・Goの共存は、マルチ言語での適材適所を教えてくれます（媒体：Findy Engineer Lab／リクルート テックブログ）。
自社が「どの部分をGoに任せ、どの部分を既存言語に残すか」を見極め、まずは非同期処理や内部APIなど一部から検証する一歩を踏み出してください。
riplaはフルスクラッチ受託と国内開発を組み合わせ、事業から逆算した技術選定と体制づくりを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。