【C#】unsafeコードの使い方とポインタ操作による高速化・メモリ制御の解説

2026年3月16日2026年5月5日

構文・制御フロー

C#は、ガベージコレクション（GC）による自動メモリ管理や強力な型安全性を備えた、モダンな高水準言語です。

しかし、画像処理や数値シミュレーション、低レベルなハードウェア制御など、極限のパフォーマンスが求められる領域では、これらの「安全装置」がオーバーヘッドとなる場合があります。

そこで提供されているのがunsafeコードという仕組みです。

本記事では、C#においてポインタを直接操作するためのunsafeキーワードの使い方から、メモリ制御による高速化のテクニック、そして使用上のリスクまでを、プロフェッショナルな視点で詳しく解説します。

目次 [ close ]

C#におけるunsafeコードの役割と基本概念

C#の設計思想の根幹には「メモリ安全性」がありますが、unsafeキーワードを使用することで、開発者は型安全性のチェックを意図的にバイパスし、CやC++のようなポインタ操作を行うことが可能になります。

これは、プログラムが直接メモリ領域の特定のアドレスを参照し、値を書き換えることができることを意味します。

なぜ「unsafe」が必要なのか

通常、C#の配列アクセスでは、実行時に「境界チェック（Bounds Checking）」が行われます。

これにより、配列の範囲外へのアクセスによるメモリ破壊を防いでいますが、ループ処理が数億回繰り返されるようなケースでは、このチェックが無視できないコストとなります。

また、Windows APIなどの外部アンマネージライブラリとデータをやり取りする際、ポインタを直接渡す必要がある場合もあります。

unsafeコードは、決して「危険だから使うべきではない」ものではなく、「開発者が責任を持ってメモリを管理することを宣言する」ための機能です。

正しく使用すれば、マネージド言語の利便性を享受しつつ、クリティカルな箇所のみをネイティブコードに近い速度で動作させることができます。

unsafeブロックを有効にするための準備

C#でポインタを扱うには、プロジェクト全体でunsafeコードを許可する設定が必要です。

デフォルトでは安全性の観点から無効化されています。

プロジェクトファイルでの設定

.NETプロジェクト（.csproj）において、<AllowUnsafeBlocks>タグをtrueに設定します。

XML

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <!-- unsafeコードの使用を許可する -->
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
  </PropertyGroup>
</Project>

また、Visual Studioのプロジェクトプロパティから「ビルド」タブを選択し、「アンセーフコードの許可」にチェックを入れることでも同様の設定が可能です。

ポインタ操作の基礎知識

unsafe環境では、C言語と同様のポインタ型を利用できます。

主な演算子と型について解説します。

ポインタ型と演算子

C#で利用可能なポインタ型には、int、char、void*などがあります。

これらを操作するために以下の演算子を使用します。

&（アドレス演算子）：変数のメモリ番地を取得します。
*（間接参照演算子）：ポインタが指すアドレスにある値にアクセスします。
->（アロー演算子）：構造体のポインタからメンバにアクセスします。

基本的なポインタ操作の例を以下に示します。

using System;

class Program
{
    static unsafe void Main()
    {
        int value = 100;
        // 変数valueのアドレスを取得
        int* p = &value;

        Console.WriteLine($"元の値: {value}");
        Console.WriteLine($"アドレス: {(long)p:X}");

        // ポインタ経由で値を書き換える
        *p = 200;

        Console.WriteLine($"変更後の値: {value}");
    }
}

実行結果

元の値: 100
アドレス: 7FFD5E3C4A10
変更後の値: 200

メモリの固定（pinning）とfixed文の重要性

C#のランタイムであるCLR（Common Language Runtime）には、ガベージコレクション（GC）が搭載されています。

GCはメモリの断片化を防ぐために、実行中にオブジェクトのメモリ配置を移動させることがあります。

ポインタが指しているオブジェクトがGCによって移動してしまうと、ポインタは無効なメモリ領域を指すことになり、アプリケーションのクラッシュやデータ破損を引き起こします。

これを防ぐために使用するのがfixed文です。

fixed文によるアドレスの固定

fixed文を使用すると、指定したコードブロック内において、対象のオブジェクトをメモリ上に「ピン留め（Pinning）」し、GCによる移動を禁止することができます。

using System;

class ArrayPointerExample
{
    static unsafe void Main()
    {
        int[] numbers = { 10, 20, 30, 40, 50 };

        // 配列の先頭アドレスを固定する
        fixed (int* p = numbers)
        {
            // ポインタ演算によるアクセス
            for (int i = 0; i < numbers.Length; i++)
            {
                // *(p + i) は p[i] と等価
                Console.WriteLine($"Element {i}: {*(p + i)}");
            }
        } 
        // fixedブロックを抜けると、GCによる移動が再び許可される
    }
}

実行結果

Element 0: 10
Element 1: 20
Element 2: 30
Element 3: 40
Element 4: 50

fixed文は、ヒープ上に確保されたマネージドオブジェクトのアドレスを安全に取得するための必須知識です。

stackallocによる高速なスタックメモリ確保

通常、C#で配列を作成するとヒープ領域にメモリが確保されますが、stackallocキーワードを使用することで、スタック領域にメモリを確保できます。

スタック確保のメリット

スタック領域はGCの管理対象外であるため、割り当てと解放が極めて高速です。

メソッドの終了と共に自動的に解放されるため、一時的なバッファが必要な場合に非常に有効です。

using System;

class StackAllocExample
{
    static unsafe void Main()
    {
        // スタック上に10個のint領域を確保
        int* block = stackalloc int[10];

        for (int i = 0; i < 10; i++)
        {
            block[i] = i * i;
        }

        for (int i = 0; i < 10; i++)
        {
            Console.Write($"{block[i]} ");
        }
    }
}

実行結果

0 1 4 9 16 25 36 49 64 81

ただし、スタックのサイズには制限（通常1MB程度）があるため、巨大な配列をstackallocで確保しようとするとStackOverflowExceptionが発生するリスクがあります。

大量のデータを扱う場合は、従来のヒープ確保やNativeMemory.Alloc（.NET 6以降）を検討してください。

実践：ポインタ操作による配列処理の高速化

ここでは、通常のマネージドな配列アクセスと、unsafeなポインタアクセスでどれほどのパフォーマンス差が出るかをイメージするためのプログラム例を紹介します。

プログラム例：配列要素の合計値計算

大量の数値データを持つ配列の合計値を計算する処理を、2つの手法で比較します。

using System;
using System.Diagnostics;

class PerformanceComparison
{
    static void Main()
    {
        const int Size = 100_000_000;
        int[] data = new int[Size];
        Random rand = new Random();
        for (int i = 0; i < Size; i++) data[i] = rand.Next(1, 10);

        // 1. 通常のアクセス
        Stopwatch sw1 = Stopwatch.StartNew();
        long sum1 = ManagedSum(data);
        sw1.Stop();
        Console.WriteLine($"Managed Sum: {sum1}, Time: {sw1.ElapsedMilliseconds}ms");

        // 2. ポインタによるアクセス
        Stopwatch sw2 = Stopwatch.StartNew();
        long sum2 = UnsafeSum(data);
        sw2.Stop();
        Console.WriteLine($"Unsafe Sum: {sum2}, Time: {sw2.ElapsedMilliseconds}ms");
    }

    // マネージドな合計計算
    static long ManagedSum(int[] array)
    {
        long total = 0;
        for (int i = 0; i < array.Length; i++)
        {
            total += array[i]; // ここで毎回境界チェックが発生する
        }
        return total;
    }

    // unsafeなポインタ合計計算
    static unsafe long UnsafeSum(int[] array)
    {
        long total = 0;
        fixed (int* pBase = array)
        {
            int* p = pBase;
            int len = array.Length;
            for (int i = 0; i < len; i++)
            {
                total += *p; // 境界チェックなしの直接アクセス
                p++;         // ポインタを進める
            }
        }
        return total;
    }
}

このコードを実行すると、多くの場合においてUnsafeSumの方が高速に動作します。

これは、ループ内での境界チェック（Bounds Checking）が省略されることに加え、CPUのレジスタをより効率的に利用できるためです。

unsafeを使用する際の注意点とリスク管理

ポインタ操作は強力ですが、一歩間違えると致命的なバグの原因となります。

以下の点に留意する必要があります。

1. メモリ破壊のリスク

ポインタを使用すると、配列の範囲外や、全く関係のないメモリ領域を上書きしてしまう可能性があります。

これはバッファオーバーフロー攻撃の脆弱性にも繋がり、システムのセキュリティを脅かします。

2. ガベージコレクションとの競合

fixed文を忘れてマネージドオブジェクトのアドレスを保持し続けると、GCによってオブジェクトが移動した後に「ぶら下がりポインタ（Dangling Pointer）」が発生します。

これはデバッグが極めて困難な不正アクセスの原因となります。

3. 保守性の低下

unsafeコードは、C#の標準的なコードに比べて可読性が低くなりがちです。

また、プラットフォーム（32bit/64bit）によってポインタのサイズが異なるため、移植性（ポータビリティ）を損なう可能性もあります。

原則として、unsafeを使用する範囲は最小限に留め、パフォーマンスがボトルネックとなっていることがプロファイリングによって証明された箇所のみに適用するのがベストプラクティスです。

現代的な代替案：Span<T>とMemory<T>

近年の.NET（.NET Core 2.1以降）では、Span<T>およびReadOnlySpan<T>という型が登場しました。

これらは、unsafeを使わずにポインタに近いパフォーマンスを実現するための強力な手段です。

特徴	ポインタ (unsafe)	Span<T>
安全性	低い（メモリ破壊の恐れ）	高い（型安全・境界チェックあり）
速度	極めて高速	高速（JITによる最適化で境界チェックがほぼ消える）
メモリ領域	ヒープ、スタック、アンマネージ	ヒープ、スタック、アンマネージを統一的に扱える
使用難易度	高い	低い

現代のC#開発においては、まずSpan<T>の利用を検討し、それでも解決できない極限のケースや、特殊なアンマネージド相互運用が必要な場合にのみunsafeを選択するという流れが推奨されます。

Span<T>を使用した例

public static long SpanSum(ReadOnlySpan<int> span)
{
    long total = 0;
    foreach (int value in span)
    {
        total += value;
    }
    return total;
}

このように記述すると、JITコンパイラが「範囲外アクセスが起こり得ない」と判断した場合、自動的に境界チェックを省略したマシンコードを生成します。