C言語のfree関数でメモリを正しく解放する方法とエラーを防ぐ注意点を解説

2026年4月18日

ポインタ・メモリ管理

C言語におけるプログラミングにおいて、メモリ管理は最も基本的かつ重要なスキルの1つです。

JavaやPythonといったガベージコレクション（GC）を備えた言語とは異なり、C言語ではエンジニアが自らの手でメモリの確保と解放を管理しなければなりません。

その中心となるのがfree関数です。

適切にメモリを解放しないプログラムは、メモリリークを引き起こし、最終的にはシステム全体のクラッシュを招く恐れがあります。

本記事では、free関数の基本的な使い方から、実務で発生しやすいエラーの回避策、そして安全なメモリ管理を実現するためのベストプラクティスまで、テクニカルライターの視点で詳しく解説します。

目次 [ close ]

メモリ管理の重要性とfree関数の役割

C言語のプログラムが実行される際、メモリ領域は大きく分けて「スタック領域」と「ヒープ領域」の2つに分類されます。

スタック領域は、関数のローカル変数などが格納される場所で、関数の終了とともに自動的に解放されます。

一方、プログラムの実行中に動的にサイズを決定して確保されるメモリは「ヒープ領域」に配置されます。

このヒープ領域のメモリは、OSから借りている状態であり、使い終わった後は必ず返却しなければなりません。

この「返却」を行うための標準ライブラリ関数がfreeです。

ヒープ領域と動的メモリ確保

動的メモリ確保には、主にmalloc、calloc、reallocといった関数が使用されます。

これらの関数は、要求されたバイト数のメモリブロックをヒープから切り出し、その先頭アドレスをポインタとして返します。

動的に確保したメモリは、プログラムが明示的に解放しない限り、プログラムが終了するまで残り続けます。

小規模なツールであればOSが終了時に一括回収してくれますが、サーバーアプリケーションや組み込みシステムのように長時間稼働するプログラムでは、解放漏れが致命的な問題となります。

free関数の基本的な使い方

free関数を使用するには、標準ライブラリのstdlib.hをインクルードする必要があります。

構文と引数

free関数のプロトタイプ宣言は以下の通りです。

C言語

#include <stdlib.h>

void free(void *ptr);

引数ptrには、malloc、calloc、またはreallocによって返されたメモリブロックの先頭アドレスを渡します。

戻り値はありません。

free関数の使用例

以下に、メモリを確保し、使用した後に正しく解放する基本的なプログラム例を示します。

C言語

#include <stdio.h>
#include <stdlib.h>

int main() {
    // 10個のint型要素を持つ配列を動的に確保
    int *array = (int *)malloc(10 * sizeof(int));

    if (array == NULL) {
        fprintf(stderr, "メモリの確保に失敗しました\n");
        return 1;
    }

    // メモリの使用
    for (int i = 0; i < 10; i++) {
        array[i] = i * 10;
        printf("%d ", array[i]);
    }
    printf("\n");

    // 使用が終わったメモリを解放
    free(array);

    // 解放後はポインタを使用しないようにNULLを代入するのが安全
    array = NULL;

    return 0;
}

実行結果

0 10 20 30 40 50 60 70 80 90

このコードでは、mallocで確保した領域をfree(array)によってOSに返却しています。

解放後にarray = NULL;としている点については、後述する安全対策のセクションで詳しく解説します。

なぜメモリ解放を怠ってはいけないのか

C言語初心者にとって、freeを書く作業は手間に感じられるかもしれません。

しかし、これを怠ることはプロフェッショナルな開発においては許されません。

メモリリーク（Memory Leak）の恐怖

メモリ解放を忘れると、確保されたメモリが「どこからも参照されていないのに、使用中としてマークされている」状態になります。

これがメモリリークです。

例えば、ループの中でメモリ確保を行い、解放を忘れた場合を考えてみましょう。

C言語

void leaking_function() {
    int *data = (int *)malloc(1024 * sizeof(int));
    // 何らかの処理
    // free(data); を忘れている
}

int main() {
    while (1) {
        leaking_function();
    }
    return 0;
}

このプログラムを実行すると、leaking_functionが呼ばれるたびに約4KBのメモリが消費され続けます。

短時間で物理メモリを使い果たし、システムがスワップ（ディスクへの書き出し）を始めて動作が極端に重くなるか、OSのOOM Killerによってプロセスが強制終了されます。

リソースの枯渇とシステムの不安定化

メモリは有限のリソースです。

特にメモリ制約の厳しい組み込み機器や、高可用性が求められるネットワークサーバーでは、わずかなリークが数日、数週間後のシステムダウンを引き起こします。

「プログラムが終了すればOSが回収してくれる」という考えは、バッチ処理のような短命なプログラム以外では通用しません。

free関数に関連する典型的なエラーと原因

free関数は単純に見えて、非常にデバッグが困難なバグの原因になりやすい側面を持っています。

ここでは代表的な3つのエラーについて解説します。

二重解放（Double Free）

既にfreeしたポインタに対して、再度freeを実行してしまうことを「二重解放」と呼びます。

C言語

int *ptr = (int *)malloc(sizeof(int));
free(ptr);
free(ptr); // 二重解放：未定義の動作を引き起こす

二重解放が発生すると、ヒープ管理情報が破壊され、プログラムが即座にクラッシュするか、あるいは「脆弱性の原因」となります。

攻撃者はこのヒープの不整合を利用して、任意のコードを実行させることが可能になるため、セキュリティの観点からも極めて危険です。

不正な領域の解放

freeに渡すアドレスは、必ずmalloc等で取得した先頭アドレスでなければなりません。

ポインタ演算後のアドレスを渡す：

C言語

int *p = (int *)malloc(10 * sizeof(int));
p++;
free(p); // 誤り：先頭アドレスではない

スタック領域の変数を渡す：

C言語

int x = 10; free(&x); // 誤り：ヒープ領域ではない

これらは実行時にSegmentation Faultや、実行時ライブラリによるエラーメッセージと共に強制終了を招きます。

解放後のメモリ参照（Dangling Pointer）

メモリを解放した後も、そのポインタ変数は解放前のメモリアドレスを保持し続けます。

この状態のポインタをダングリングポインタ（Dangling Pointer：浮いたポインタ）と呼びます。

C言語

int *ptr = (int *)malloc(sizeof(int));
*ptr = 100;
free(ptr);

// printf("%d\n", *ptr); // 危険：解放済みの領域へのアクセス

解放済みの領域にアクセスすると、偶然以前の値が残っていて正常に動いているように見えることもあれば、既に別のデータが書き込まれていて予期せぬ挙動を示すこともあります。

この「時々刻々と状況が変わる」性質が、バグの特定を困難にします。

実践：複雑なデータ構造におけるメモリ解放

単純な変数だけでなく、構造体や多次元配列を扱う場合には、解放の順序が重要になります。

構造体の動的確保と解放

構造体のメンバ自体がポインタを持ち、個別にメモリ確保されている場合、内側から順番に解放していく必要があります。

C言語

#include <stdlib.h>
#include <string.h>

typedef struct {
    char *name;
    int *scores;
} Student;

int main() {
    Student *s = (Student *)malloc(sizeof(Student));
    s->name = (char *)malloc(32);
    s->scores = (int *)malloc(5 * sizeof(int));

    // 解放の順序
    free(s->name);   // 1. メンバの解放
    free(s->scores); // 2. メンバの解放
    free(s);         // 3. 構造体自体の解放

    return 0;
}

もし先にfree(s);を行ってしまうと、s->nameやs->scoresへアクセスする手段が失われ、それらの領域を解放することが不可能（メモリリーク確定）になります。

多次元配列の解放

動的に確保した2次元配列（ポインタのポインタ）も同様に、階層構造を意識した解放が必要です。

C言語

#include <stdlib.h>

int main() {
    int rows = 5;
    int **matrix = (int **)malloc(rows * sizeof(int *));

    for (int i = 0; i < rows; i++) {
        matrix[i] = (int *)malloc(10 * sizeof(int));
    }

    // 解放処理
    for (int i = 0; i < rows; i++) {
        free(matrix[i]); // 各行のメモリを解放
    }
    free(matrix);     // 行ポインタの配列自体を解放

    return 0;
}

メモリ管理を安全に行うためのベストプラクティス

エラーを防ぎ、堅牢なプログラムを書くためのテクニックを紹介します。

解放後のポインタにNULLを代入する

freeした直後にポインタへNULLを代入することを習慣づけましょう。

C言語

free(ptr);
ptr = NULL;

C言語の仕様上、free(NULL);は何もしないことが保証されています。

そのため、もし誤って二度freeを呼んでしまっても、NULLが代入されていれば二重解放によるクラッシュを防ぐことができます。

また、NULLを代入しておけば、後続の処理でポインタを再利用しようとした際に、ヌルポインタ参照として早期にエラー（クラッシュ）が発生するため、ダングリングポインタによる静かなデータの破壊を防げます。

確保と解放を対にする設計

メモリ管理の基本原則は「誰が確保し、誰が解放するか」を明確にすることです。

リソース管理の局所化： 可能であれば、同じ関数内でmallocとfreeを行う。
オブジェクト指向的アプローチ： 構造体を使用する場合、専用の生成関数（create_xxx）と破棄関数（destroy_xxx）を用意する。

C言語

void destroy_student(Student *s) {
    if (s == NULL) return;
    free(s->name);
    free(s->scores);
    free(s);
}

このように破棄を一箇所にまとめることで、解放漏れを防ぎやすくなります。

メモリ管理ライブラリやツールの活用

手動での管理には限界があります。

開発時には以下のツールを活用することを強く推奨します。

ツール名	特徴
Valgrind (Memcheck)	Linuxで標準的なメモリリーク検出ツール。実行時の不正アクセスも検知可能。
AddressSanitizer (ASan)	GCCやClangに内蔵されている高速なメモリエラー検出器。コンパイルオプションで有効化。
Visual Studio 診断ツール	Windows環境でメモリ使用量の推移やリーク箇所を特定可能。

例えば、コンパイル時に-fsanitize=addressオプションを付けるだけで、実行時に詳細なエラーレポートを得ることができます。

まとめ

C言語のfree関数は、限られたコンピュータのリソースを効率的に活用するために不可欠な道具です。

しかし、その自由度の高さゆえに、一歩間違えると二重解放やメモリリークといった深刻なバグを生む刃にもなります。

正しくメモリを管理するためには、以下の3点を常に意識してください。

確保したメモリは、適切なタイミングで必ず一度だけ解放する。
解放した後のポインタにはNULLを代入し、再利用を防止する。
複雑なデータ構造では、確保の逆順で丁寧に解放を進める。

これらの原則を徹底し、Valgrindなどの解析ツールを併用することで、メモリ関連のトラブルに悩まされない高品質なプログラムを構築できるようになります。

メモリ管理を制する者はC言語を制すると言っても過言ではありません。

一歩ずつ、確実なコード記述を心がけましょう。