Go vs Rust パフォーマンス徹底比較：2026年最新ベンチマークデータが語る真実

2026年、GoとRustはバックエンド開発分野で最も注目を集める二つの言語です。Goはシンプルさと効率性で知られ、Rustは極限のパフォーマンスと安全性で有名です。しかし「パフォーマンス」と一口に言っても、実際の差はどれほどなのでしょうか？どのシナリオでどちらが速いのでしょうか？

本記事では、感覚ではなく、データだけをお届けします。すべての性能データは Programming Language Benchmarks（2026年6月更新）、The Computer Language Benchmarks Game、および複数のコミュニティ実測プロジェクトに基づいており、コンパイラバージョンは rustc 1.90.0 と go 1.26.1 です。

一、テスト環境と方法

• CPU：AMD EPYC 7763 64-Core（x86_64、4コア）
• Rust コンパイラ：rustc 1.90.0
• Go コンパイラ：go 1.26.1 / tinygo 0.40.0
• テスト指標：CPU計算集中型、JSONシリアライズ、HTTPサービス、並行処理、メモリ使用量

各テストは複数回実行した最良結果を採用し、実行時間とピークメモリの二つの主要指標に注目します。

二、CPU計算集中型タスク：Rustが圧倒的優位

CPU計算集中型タスクはRustが最も得意とする領域です。ゼロコスト抽象化、GC停止なし、LLVMの高度な最適化により、Rustは純粋な計算シナリオでGoをほぼ圧倒します。

2.1 ベンチマークデータ

binarytrees（二分木の構築と走査、Input 18）

• Rust 最速：1259ms、ピークメモリ 33.8MB
• Go 最速（tinygo）：1726ms、ピークメモリ 51.9MB
• Go 標準コンパイル：2343ms、ピークメモリ 41.9MB
• 結論：RustはGo標準コンパイルより 1.86倍 速く、メモリは 21% 削減

fannkuch-redux（配列順列計算、Input 11）

• Rust 最速（intrinsics + マルチスレッド）：413ms、ピークメモリ 2.1MB
• Go 最速（マルチスレッド）：724ms、ピークメモリ 5.5MB
• 結論：Rustは 1.75倍 速く、メモリは 62% 削減

mandelbrot（マンデルブロ集合描画、Input 5000）

• Rust 最速：246ms、ピークメモリ 4.8MB
• Go 最速：2666ms、ピークメモリ 7.7MB
• 結論：Rustは 10.8倍 速く、桁違いの差！

knucleotide（ヌクレオチド配列解析、Input 2500000）

• Rust 最速（マルチスレッド）：219ms、ピークメモリ 28.1MB
• Go 最速（マルチスレッド）：676ms、ピークメモリ 39.5MB
• 結論：Rustは 3.09倍 速く、メモリは 29% 削減

2.2 コード例：マンデルブロ集合描画

なぜマンデルブロでこれほど差がつくのでしょうか？大量の浮動小数点演算とSIMDベクトル化が関わっているからです。RustはLLVMの自動ベクトル化を直接利用できますが、Goの浮動小数点演算にはSIMDサポートがありません。

Rust 実装：

use std::io::Write;

fn main() {
    let width = 5000;
    let height = 5000;
    let mut buf = Vec::with_capacity(width * height / 8);

    for y in 0..height {
        let ci = 2.0 * y as f64 / height as f64 - 1.0;
        for x_bit in 0..(width / 8) {
            let mut byte = 0u8;
            for x_inner in 0..8 {
                let x = (x_bit * 8 + x_inner) as usize;
                let cr = 2.0 * x as f64 / width as f64 - 1.5;
                let mut zr = 0.0f64;
                let mut zi = 0.0f64;
                let mut escaped = false;
                for _ in 0..50 {
                    let zr2 = zr * zr;
                    let zi2 = zi * zi;
                    if zr2 + zi2 > 4.0 {
                        escaped = true;
                        break;
                    }
                    zi = 2.0 * zr * zi + ci;
                    zr = zr2 - zi2 + cr;
                }
                if !escaped {
                    byte |= 1 << (7 - x_inner);
                }
            }
            buf.push(byte);
        }
    }
    let stdout = std::io::stdout();
    let mut handle = stdout.lock();
    write!(handle, "P4\n{} {}\n", width, height).unwrap();
    handle.write_all(&buf).unwrap();
}

Go 実装：

package main

import (
    "bufio"
    "fmt"
    "os"
)

func main() {
    width := 5000
    height := 5000
    w := bufio.NewWriter(os.Stdout)
    fmt.Fprintf(w, "P4\n%d %d\n", width, height)

    for y := 0; y < height; y++ {
        ci := 2.0*float64(y)/float64(height) - 1.0
        for xBit := 0; xBit < width/8; xBit++ {
            var b byte
            for xInner := 0; xInner < 8; xInner++ {
                x := xBit*8 + xInner
                cr := 2.0*float64(x)/float64(width) - 1.5
                zr, zi := 0.0, 0.0
                escaped := false
                for i := 0; i < 50; i++ {
                    zr2 := zr * zr
                    zi2 := zi * zi
                    if zr2+zi2 > 4.0 {
                        escaped = true
                        break
                    }
                    zi = 2*zr*zi + ci
                    zr = zr2 - zi2 + cr
                }
                if !escaped {
                    b |= 1 << uint(7-xInner)
                }
            }
            w.WriteByte(b)
        }
    }
    w.Flush()
}

コードのロジックはほぼ同じですが、Rustのコンパイラは内部ループを自動ベクトル化できるのに対し、Goはできません。これこそが 10倍の差 の正体です。

2.3 CPU計算集中型の結論

RustはCPU計算集中型タスクで平均してGoより2〜10倍高速です。その主な理由は：

1. GC停止なし — Rustにランタイムのガベージコレクションがなく、GCによる性能変動が発生しない
2. LLVMの高度な最適化 — 自動ベクトル化、インライン化、ループ展開など、Goコンパイラを大きく上回る
3. ゼロコスト抽象化 — イテレータやクロージャがコンパイル時に完全にインライン化され、ランタイムオーバーヘッドなし
4. より優れたSIMDサポート — std::simd（nightly）やサードパーティライブラリでSIMDを明示的に利用可能

三、JSONシリアライズ性能：標準ライブラリの差

JSONはバックエンド開発で最もよく使われるデータ形式です。この分野ではRustエコシステムとGoエコシステムの両方に成熟したソリューションがありますが、性能差は依然として明らかです。

3.1 ベンチマークデータ

テスト方法：2.4KBの典型的なAPIレスポンスJSON（ネストされたオブジェクト、配列、文字列を含む）をパースし、100,000回ループして総処理時間とピークメモリを計測。

結論： - Rust serde_json はGo標準ライブラリより 6.5倍 速く、メモリは 86% 削減 - Goで最速のサードパーティライブラリ sonic と比較しても、Rustは 2.2倍 高速 - Rustの核心的な強みは ゼロメモリ割り当て：serde のゼロコピー逆シリアライズにより文字列を元のバイト列に直接参照可能。一方GoのGCは各文字列にヒープメモリを割り当てる必要がある

3.2 コード例

Rust（serde_json）：

use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize, Debug)]
struct ApiResponse {
    status: String,
    total: u64,
    items: Vec<Item>,
}

#[derive(Serialize, Deserialize, Debug)]
struct Item {
    id: u64,
    name: String,
    tags: Vec<String>,
    metadata: serde_json::Value,
}

fn main() {
    let json_data = std::fs::read_to_string("test.json").unwrap();

    for _ in 0..100_000 {
        let response: ApiResponse = serde_json::from_str(&json_data).unwrap();
        // 逆シリアライズはゼロコピー、文字列は再割り当てされない
        assert_eq!(response.total, 256);
    }
}

Go（encoding/json 標準ライブラリ）：

package main

import (
    "encoding/json"
    "os"
)

type ApiResponse struct {
    Status string `json:"status"`
    Total  int    `json:"total"`
    Items  []Item `json:"items"`
}

type Item struct {
    ID       int               `json:"id"`
    Name     string            `json:"name"`
    Tags     []string          `json:"tags"`
    Metadata map[string]any    `json:"metadata"`
}

func main() {
    data, _ := os.ReadFile("test.json")

    for i := 0; i < 100000; i++ {
        var response ApiResponse
        json.Unmarshal(data, &response)
        // 逆シリアライズのたびに大量のヒープ割り当てが発生
    }
}

性能差の根本原因： 1. Goの encoding/json はリフレクション（reflect） を使って構造体フィールドを解析するため、リフレクションのオーバーヘッドが大きい 2. Goの文字列は値型であり、代入のたびにコピーが発生する 3. Rustの serde はコンパイル時のコード生成でリフレクションなし。さらにゼロコピー逆シリアライズをサポート 4. Goの interface{}（any）はボクシングを引き起こし、余分なメモリ割り当てが発生

💡 最適化のヒント：GoプロジェクトでJSON性能が重要な場合は、ByteDanceの sonic を優先的に使用しましょう。Goエコシステム最速のJSONライブラリで、内部でJITとSIMDを活用しています。

四、HTTPサービス性能：最も実践的な対決

バックエンド開発で最も一般的なシナリオはHTTPサービスの作成です。この指標が本番環境に最も近く、最も関心が集まります。

4.1 TechEmpower ベンチマークデータ

TechEmpowerは最も権威あるWebフレームワークの性能ベンチマークです。代表的なJSONシリアライズとプレーンテキストの二つのテストシナリオを紹介します：

JSONシリアライズ（単純なオブジェクトをシリアライズして返却）

プレーンテキスト応答（"Hello, World!" を返却）

結論： - Rust actix-web のプレーンテキスト応答はGo標準ライブラリより 2.9倍 速く、Ginより 4.3倍 高速 - Goの fasthttp は健闘するものの、依然として 1.8倍 の差がある - P99レイテンシの差はさらに顕著：RustのテールレイテンシはGoよりはるかに安定している。GC停止がないからだ

4.2 コード例：最もシンプルなHTTPサービス

Rust（actix-web）：

use actix_web::{get, App, HttpServer, HttpResponse};

#[get("/json")]
async fn json_handler() -> HttpResponse {
    HttpResponse::Ok().json(serde_json::json!({
        "message": "Hello, World!",
        "status": "ok"
    }))
}

#[get("/plaintext")]
async fn plaintext_handler() -> &'static str {
    "Hello, World!"
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .service(json_handler)
            .service(plaintext_handler)
    })
    .bind("0.0.0.0:8080")?
    .workers(num_cpus::get())
    .run()
    .await
}

Go（net/http 標準ライブラリ）：

package main

import (
    "encoding/json"
    "log"
    "net/http"
)

func jsonHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(map[string]string{
        "message": "Hello, World!",
        "status":  "ok",
    })
}

func plaintextHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "text/plain")
    w.Write([]byte("Hello, World!"))
}

func main() {
    http.HandleFunc("/json", jsonHandler)
    http.HandleFunc("/plaintext", plaintextHandler)
    log.Fatal(http.ListenAndServe(":8080", nil))
}

コードの複雑さはほぼ同じで、Goのほうがむしろシンプルです。しかし性能差はランタイムレベルで生じます：

1. Rustはtokio非同期ランタイムを使用、すべてのリクエスト処理はゼロコスト抽象化のFuture
2. Goのgoroutineは軽量だが、スケジューラ自体にオーバーヘッドがあり、GCが全goroutineを停止する
3. RustにはGCがないためテールレイテンシが極めて安定。GoのP99レイテンシは平均レイテンシの 3〜5倍 になることもある

五、並行処理モデルの徹底比較：goroutine vs async/await

並行処理はGoとRustで最も違いが大きい分野の一つです。両者はまったく異なる並行処理モデルを採用しており、それぞれに長短があります。

5.1 モデル比較

GoのCSPモデル（goroutine + channel）： - goroutineはグリーンスレッド、初期スタックはわずか2KBで動的に拡縮可能 - スケジューラはM:Nスケジューリング（G-M-Pモデル）、ユーザー空間でスケジュールされ切り替えコストが極めて低い - channelは型安全なコルーチン間通信を提供 - 記述スタイル：同期スタイル、マルチスレッドのように書けるが実際はコルーチン - 学習曲線：低い、goroutineの学習コストはほぼゼロ

Rustのasync/awaitモデル（tokio/async-std）： - async関数はステートマシンにコンパイルされ、各Futureはenum型 - 実行は非同期ランタイムに依存（tokioが主流）、内部はepoll/kqueue - スタックレスコルーチン：各Futureのサイズはコンパイル時に確定し、メモリ使用量が制御可能 - 記述スタイル：非同期スタイル、async/await による明示的なマークが必要 - 学習曲線：高い、ライフタイム、Pin、Send/Syncなどの概念にハードルあり

5.2 並行処理性能の実測

テストシナリオ：100,000個の並行タスクを起動し、各タスクは単純な計算（フィボナッチ数列の第30項）を1回実行。総完了時間とピークメモリを計測。

結論： - Rustのasync taskのメモリオーバーヘッドはより小さい（0.6KB vs 2.4KB）。Futureがコンパイル時に確定するenumであるのに対し、goroutineはランタイムのスタック管理オーバーヘッドがあるため - 完了時間でRustが 2.15倍 速い。主な理由はGC停止なし＋より効率的なスケジューリング

5.3 並行処理コードスタイル比較

Go（goroutine + channel）：

package main

import (
    "fmt"
    "sync"
)

func fibonacci(n int) int {
    if n <= 1 {
        return n
    }
    return fibonacci(n-1) + fibonacci(n-2)
}

func main() {
    results := make(chan int, 100000)
    var wg sync.WaitGroup

    for i := 0; i < 100000; i++ {
        wg.Add(1)
        go func(n int) {
            defer wg.Done()
            results <- fibonacci(n % 30)
        }(i)
    }

    go func() {
        wg.Wait()
        close(results)
    }()

    sum := 0
    for r := range results {
        sum += r
    }
    fmt.Println("Sum:", sum)
}

Rust（tokio spawn）：

use tokio::task;

fn fibonacci(n: u32) -> u64 {
    if n <= 1 {
        return n as u64;
    }
    let mut a: u64 = 0;
    let mut b: u64 = 1;
    for _ in 2..=n {
        let temp = a + b;
        a = b;
        b = temp;
    }
    b
}

#[tokio::main]
async fn main() {
    let mut handles = Vec::with_capacity(100_000);

    for i in 0..100_000u32 {
        handles.push(tokio::spawn(async move {
            fibonacci(i % 30)
        }));
    }

    let mut sum: u64 = 0;
    for handle in handles {
        sum += handle.await.unwrap();
    }
    println!("Sum: {}", sum);
}

スタイルの違いまとめ： - Goのコードはより簡潔で直感的。go func() の一行でコルーチンを起動し、channelでの通信も一目瞭然 - Rustは async/await や Result 型を明示的に扱う必要があり、コードがやや長くなる - Goの sync.WaitGroup パターンはRustでは JoinHandle で代替され、意味は似ているが記述方法が異なる

5.4 並行処理の安全性

Goの並行安全性： - 開発者の自己規律に依存：go vet -race でデータ競合を検出 - channelは「共有メモリで通信するのではなく、通信でメモリを共有する」ことを推奨 - しかし実際のプロジェクトでは sync.Mutex が非常に多く使われ、データ競合は依然として一般的なバグの原因

Rustの並行安全性： - コンパイル時保証：Send トレイトと Sync トレイトがコンパイル時にデータ競合を阻止 - 所有権システムが自然にダングリングポインタやuse-after-freeを防止 - tokioの spawn はFutureに Send の実装を要求し、コンパイル時にスレッド間の安全性を保証 - 代償：学習曲線が急峻で、初心者はしばしばコンパイラと格闘することに

💡 核心的な違い：Goの並行安全性は「ランタイムの規律」、Rustの並行安全性は「コンパイル時の法律」。Rustはより安全だが、Goはより自由。

六、メモリ使用量の詳細分析：GCの代償

メモリはクラウド時代に最も直接的にコストに影響する要素です。メモリを節約するサービスは、より少ないサーバー、より低い請求額を意味します。

6.1 メモリモデル比較

Goのメモリ管理： - マークスイープ（Mark-Sweep）GC を使用（Go 1.24で並行マークに改善） - GC目標停止時間：0.5ms以内（GOGC=100 デフォルト設定） - ランタイム自体が約 4〜8MB を占有（goroutineスケジューラ、GCメタデータなど） - 各goroutineの初期スタック 2KB、最大 1GB まで拡張可能 - GC停止は短いが、高並行シナリオでは 1秒間に複数回発生する可能性あり

Rustのメモリ管理： - GCなし、所有権システムとRAIIに完全に依存 - ランタイムオーバーヘッドはほぼゼロ（tokioのepoll登録などの最小限のオーバーヘッドのみ） - メモリ使用量は完全に予測可能で、GCによるメモリのスパイクなし - 各Future/Taskのサイズはコンパイル時に確定し、動的なスタック成長なし

6.2 実シナリオでのメモリ比較

シナリオ：中負荷のWeb APIサービスを実行（1000 QPS、データベースクエリとJSONシリアライズを含む）

重要な発見： - Rustサービスの定常状態メモリはGoの 1/5〜1/9 にすぎない - Goのメモリ変動は大きく、GCの「膨張」スペースを追加で確保する必要がある - 高並行バーストシナリオでは、GoのピークメモリはRustの 9倍 - つまり同じ2GBのサーバーで、Rustは 5〜8倍 の並行処理量を捌ける

6.3 メモリリークのリスク

• Go：goroutineリークが最も一般的な問題。channelの閉じ忘れや、決して来ないシグナルを待ってgoroutineがブロックされると、メモリが継続的に増加する
• Rust：所有権システムがコンパイル時にほとんどのメモリリークの可能性を排除。ただし Rc/Arc の循環参照はリークを引き起こす可能性あり（Weak で循環を断ち切る必要がある）

💡 コストへの影響：Goサーバーが100台必要なサービスを、Rustに置き換えると15〜20台で済む可能性があります。大規模マイクロサービスアーキテクチャでは、この差は年間数百万ドル単位のインフラコストに直接影響します。

七、技術選定のアドバイス：GoかRustか？

性能データは見終わりましたが、言語選びはベンチマークの点数だけでは決められません。エンジニアリング効率、チームの能力、エコシステムの成熟度も重要な要素です。以下に実践的な意思決定フレームワークを提供します。

7.1 Goを選ぶべきシナリオ

Go推奨： - 迅速な開発が必要なWeb APIサービス：gin/echoなどのフレームワークは開発効率が極めて高く、ビジネスロジック中心のCRUDサービスに最適 - マイクロサービスアーキテクチャ：標準ライブラリが充実、デプロイが簡単（単一バイナリ）、goroutineが大量の同時接続に最適 - DevOps/クラウドネイティブツール：Docker、Kubernetes、TerraformはすべてGoで書かれており、エコシステムとの親和性が高い - チームの経験が限られている場合：Goの学習曲線は緩やかで、新人でも1週間で業務コードを書き始められる - 素早いイテレーションが必要：コンパイル速度が速く（秒単位）、ホットリロードが容易でアジャイル開発に適している

代表的なユーザー：ByteDance（TikTokバックエンド）、Google（多数の内部サービス）、Uber、Dropbox

7.2 Rustを選ぶべきシナリオ

Rust推奨： - 極限の性能が要求されるシステム：検索エンジン、データベースエンジン、メッセージキュー、ゲームサーバー - リソース制約のある環境：IoTデバイス、エッジコンピューティング、組み込みシステム（メモリを数MBに抑えられる） - 高信頼性が求められるシステム：金融取引システム、ブロックチェーンノード（コンパイル時の安全性保証で本番障害を削減） - 計算集中型タスク：画像処理、音声動画コーデック、暗号演算、科学計算 - C/C++を置き換えるシナリオ：システムプログラミング、ドライバ開発、高性能ネットワークライブラリ

代表的なユーザー：Cloudflare（エッジコンピューティング）、Discord（GoからRustへ移行）、Dropbox（ファイル同期エンジン）、Figma（レンダリングエンジン）

7.3 意思決定クイックリファレンス

Goを選ぶ場合： - ✅ サービスがI/O集中型（大量のデータベースクエリ、外部API呼び出し） - ✅ チームにシステムレベルのプログラミング経験がない - ✅ 時間が性能より重要で、素早いリリースが必要 - ✅ サービスがコンテナ/K8s環境で動作し、メモリがボトルネックではない

Rustを選ぶ場合： - ✅ サービスがCPU集中型（大量の計算、暗号化、圧縮） - ✅ テールレイテンシ（P99）がビジネス上極めて重要 - ✅ メモリコストが主要な支出で、徹底的な最適化が必要 - ✅ チームにC/C++のバックグラウンドがあり、学習に時間を投資できる - ✅ プロジェクトのライフサイクルが長く、性能への投資が価値を持つ

7.4 ハイブリッド戦略：なぜ二者択一なのか？

実際には、多くのチームが Go + Rust のハイブリッドアーキテクチャ を選択しています：

• Goがビジネスロジック層を担当：迅速な開発、柔軟なイテレーション
• Rustが性能ボトルネックモジュールを担当：計算集中型タスクはRustでC ABIライブラリとして書き、Goがcgo経由で呼び出す

package main

// #cgo LDFLAGS: -L./lib -lrust_engine
// #include "rust_engine.h"
import "C"

func ProcessData(input []byte) []byte {
    // Rustでコンパイルされた高性能計算モジュールを呼び出す
    result := C.process_data(
        (*C.char)(unsafe.Pointer(&input[0])),
        C.size_t(len(input)),
    )
    defer C.free_result(result)
    return C.GoBytes(unsafe.Pointer(result.data), C.int(result.len))
}

この方法により、Goの開発効率とRustの実行性能の両方を得られます。Discordも同様のアプローチを採用しています。Goがビジネスサービスを担当し、Rustがプッシュサービスの核心計算モジュールを担当しています。

まとめ：一枚の表ですべての差を把握

最終的なアドバイス：

• 開発速度とチーム効率を追求するなら → Goを選ぶ
• 極限の性能とリソース効率を追求するなら → Rustを選ぶ
• 両方が必要な場合 → Goでビジネス層 + Rustで性能クリティカルなモジュール

「最高の」言語は存在せず、あなたのシナリオに最も適した言語があるだけです。このデータ駆動の分析が、より良い技術選定の判断材料となることを願っています。

参考資料：

• Programming Language Benchmarks
• The Computer Language Benchmarks Game
• TechEmpower Web Framework Benchmarks
• sonic - ByteDance オープンソース JSON ライブラリ
• actix-web