【2026年8月最新】C言語sizeof演算子の使い方完全ガイド｜配列・構造体・ポインタでハマる罠と対策

「配列の要素数を取ろうとsizeofを使ったのに、関数の中に入れた瞬間に値がおかしくなる」——C言語を書いたことがある人なら、一度はこの罠にハマった経験があるのではないでしょうか。

sizeof演算子は、C言語の中でも最も基本的でありながら、最も誤解されやすい機能のひとつです。配列の要素数を取得する、構造体のメモリサイズを調べる、ポインタのサイズを確認する——用途はシンプルなのに、「配列がポインタに変わる」「構造体のサイズが単純な合計と一致しない」といったC言語特有の仕様が絡むと、途端に挙動が読めなくなります。

この記事では、sizeof演算子の基本的な使い方から、配列・構造体・ポインタそれぞれで起こりがちな罠、実務でのバグパターンと防止策までを、正確な技術情報にもとづいて整理します。さらに後半では、こうした細かい仕様を人間がすべて暗記していなくても、AIが正確なコードを書いてくれる時代になったことが、非エンジニアの経営者にとって何を意味するのかもあわせて解説します。

代表菅澤

正直に言うと、私自身はC言語のsizeofの仕様を全部覚えているわけではありません。ただ、経営者としてこの記事を読む価値はあると思っています。なぜなら「なぜエンジニアが慎重になるのか」が分かると、開発を依頼するときの会話の質が変わるからです。

AI鬼管理山崎

今日は技術的な正確性を最優先にしつつ、非エンジニアの方でも「何が難しいポイントなのか」の輪郭がつかめるように整理していきます。最後まで読むと、細部を暗記する必要がなくなった理由も見えてくるはずです。

この記事を最後まで読むと、次の7つが明確になります。

01 BASICS sizeof演算子とは何か（基礎知識） C言語で最初に習うのに、最後まで正確に理解されにくい演算子

sizeofは関数ではなく演算子です。カッコを付けてsizeof(int)のように書くことが多いため関数だと誤解されがちですが、実際には+や*と同じ「単項演算子」の一種です。型名に対して使う場合はカッコが必須ですが、変数や式に対して使う場合はカッコを省略できます（sizeof x;のような書き方も文法上は可能です）。

sizeofが返す値の型はsize_tという符号なし整数型です。size_tの実際のビット幅は処理系（コンパイラ・OS・CPUアーキテクチャ）によって異なり、32bit環境では32bit、64bit環境では64bitになるのが一般的です。printfでsize_t型の値を出力する際は、書式指定子として%zuを使うのが標準的な作法です。

1-1. コンパイル時に評価されるという性質

sizeofの大きな特徴は、多くの場合コンパイル時に評価される点です。つまり、プログラムを実行する前に、コンパイラが型情報から結果を計算して確定させます。これは実行時にコストがかからないという意味で、パフォーマンス上のメリットでもあります。

ただし例外があります。C99以降で導入された可変長配列（VLA: Variable Length Array）に対してsizeofを使う場合は、配列のサイズが実行時にならないと分からないため、実行時に評価されることになります。「sizeofは必ずコンパイル時に決まる」と断定してしまうと、このVLAのケースで誤りになる点は覚えておく必要があります。

#include <stdio.h>

int main(void) {
    printf("sizeof(char)  = %zu\n", sizeof(char));
    printf("sizeof(int)   = %zu\n", sizeof(int));
    printf("sizeof(double)= %zu\n", sizeof(double));
    return 0;
}
/* 出力例（多くの一般的な環境）:
   sizeof(char)  = 1
   sizeof(int)   = 4
   sizeof(double)= 8
   ※ 実際の値は処理系によって異なり得る */

代表菅澤

ここで大事なのは「4バイトになるはず」と決め打ちしないことだそうです。うちのエンジニアも「環境依存の値を決め打ちしたコードは、別のマシンやコンパイラでビルドした瞬間に壊れる」とよく言っています。

02 ARRAYS 配列とsizeof：要素数の計算方法 sizeofを使った定番の要素数取得テクニックと、その落とし穴

配列に対してsizeofを使うと、配列全体が占めるバイト数が返されます。これは「要素数 × 1要素あたりのサイズ」で計算された値です。この性質を利用すると、次のような式で配列の要素数を求めることができます。

#include <stdio.h>

int main(void) {
    int arr[10];
    size_t total_bytes   = sizeof(arr);         /* 配列全体のバイト数 */
    size_t element_bytes  = sizeof(arr[0]);      /* 1要素分のバイト数 */
    size_t element_count  = total_bytes / element_bytes;

    printf("total_bytes  = %zu\n", total_bytes);
    printf("element_bytes = %zu\n", element_bytes);
    printf("element_count = %zu\n", element_count); /* 10 になる */
    return 0;
}

2-1. なぜこの計算式が成立するのか

配列は同じ型の値がメモリ上に連続して並んだデータ構造です。したがって「配列全体のバイト数」は「1要素のバイト数 × 要素数」に必ず一致します。sizeofはコンパイル時に配列の型情報（要素の型と個数）を把握しているため、この計算が正確に行えます。

この方法は配列そのものが宣言されているスコープで使う限り、非常に信頼性の高いテクニックです。ループ処理の上限を決めるときなど、C言語では定番のイディオムとして広く使われています。

2-2. 多次元配列でのsizeof

多次元配列でもsizeofの考え方は同じです。int matrix[3][4];のような2次元配列であれば、sizeof(matrix)は「3×4×sizeof(int)」に相当するバイト数を返します。行数を知りたければsizeof(matrix) / sizeof(matrix[0])、列数を知りたければsizeof(matrix[0]) / sizeof(matrix[0][0])という形で、次元ごとに分解して計算していくのが基本の考え方です。

AI鬼管理山崎

配列のsizeofは「型が分かっている実体に対して使う」のが大前提です。この前提を忘れると、次の章で説明する『関数に渡した瞬間に結果が変わる』という有名な罠にはまります。

03 STRUCTS 構造体とsizeof：アライメント・パディングの罠 構造体のサイズが「メンバーの単純合計」と一致しないことがある理由

構造体（struct）に対してsizeofを使うと、そのメンバー全体を格納するのに必要なバイト数が返されます。ここで多くの人がつまずくのが、「メンバーのsizeofを単純に足し算した値」と、構造体全体のsizeofが一致しないことがあるという点です。

3-1. アライメント（メモリ整列）とパディングとは

多くのCPUアーキテクチャでは、特定の型のデータを「その型のサイズの倍数となるメモリアドレス」に配置したほうが、読み書きの効率が良くなる（場合によっては、整列していないアクセスがエラーになる環境すらある）という性質があります。この「型ごとに決められた配置ルール」のことをアライメント（メモリ整列）と呼びます。

コンパイラは、構造体のメンバーをこのアライメントのルールに沿って配置しようとします。その結果、メンバーとメンバーの間に「使われない隙間」が挿入されることがあります。この隙間のことをパディングと呼びます。パディングが入ると、構造体全体のサイズは各メンバーのsizeofを単純に足し合わせた値より大きくなることがあります。

たとえば「1バイトのchar」の直後に「4バイトのint」を並べた構造体を考えると、intを4バイト境界に配置するために、char直後に数バイトのパディングが挿入されるケースがあります。ただし具体的に何バイトのパディングが入るかは、コンパイラ・ターゲットCPU・最適化設定によって変わる実装依存の挙動であり、「必ずこうなる」と断定できるものではありません。気になる場合は、手元の環境で実際にsizeof(構造体名)を出力して確認するのが確実です。

3-2. パディングを抑える方法とそのトレードオフ

コンパイラによっては#pragma packや、GCC/Clangの__attribute__((packed))といった拡張機能で、パディングを詰めて構造体を小さくすることができます。ただしこれらは標準C言語の機能ではなくコンパイラ拡張であり、移植性が下がったり、整列されていないメモリアクセスによる速度低下・一部環境でのエラーを招いたりする可能性があります。安易に使う前に、本当にサイズ最小化が必要な場面かどうかを見極める必要があります。

代表菅澤

正直「パディング」という言葉を初めて聞いたとき、意味が分かりませんでした。ただ「構造体のサイズは単純な足し算にならないことがある」という一点だけ覚えておけば、エンジニアとの会話で置いていかれずに済みます。

04 FUNCTION ARGS 関数に配列を渡すときの罠（ポインタへのdecay） C言語で最も有名な初心者の落とし穴のひとつ

ここがsizeofに関する最も有名な罠です。C言語では、配列を関数の引数として渡すと、その配列は「配列の先頭要素を指すポインタ」に変換（decay）されます。関数の内部では、受け取った引数はもう「配列」ではなく「ポインタ」として扱われるため、その中でsizeofを使うと、配列全体のサイズではなく、ポインタ自体のサイズが返ってきます。

#include <stdio.h>

void check_size(int arr[]) {
    /* ここでの arr は実際にはポインタ (int*) として扱われる */
    printf("関数内: sizeof(arr) = %zu\n", sizeof(arr));
}

int main(void) {
    int numbers[10];
    printf("呼び出し元: sizeof(numbers) = %zu\n", sizeof(numbers));
    check_size(numbers);
    return 0;
}
/* 出力例（64bit環境の場合）:
   呼び出し元: sizeof(numbers) = 40   (10要素 × 4バイト)
   関数内:     sizeof(arr)     = 8    (ポインタ自体のサイズ)
   ※ 具体的な数値は環境により異なるが、
     「呼び出し元と関数内で値が変わる」という現象自体は
     C言語の仕様として一貫して発生する */

4-1. なぜこの仕様になっているのか

C言語の設計上、配列を関数の引数として値渡しでまるごとコピーする仕組みは用意されていません。その代わりに、配列名を渡すと自動的に先頭要素へのポインタへと変換される、という規則が採用されています。これは効率面での合理的な設計判断ではありますが、結果として「配列のつもりで渡した引数が、関数の中ではポインタになっている」という初心者にとって直感に反する挙動を生みます。

この仕様を知らずに「関数の引数でsizeofを使えば元の配列サイズが取れるはず」と思い込んでコードを書くと、意図しないバイト数（多くの場合4バイトや8バイトといったポインタ自体のサイズ）が返ってきて、後続の処理がすべて狂ってしまいます。

4-2. 正しい対処法

この問題を回避する最も確実な方法は、要素数を別の引数として明示的に渡すことです。C言語の標準ライブラリ関数（例：qsortやmemcpy）も、配列本体とは別に要素数やバイト数を引数として受け取る設計になっているのは、この仕様上の制約に対応するためです。

AI鬼管理山崎

この『配列を渡すとポインタになる』という仕様は、C言語を学ぶ人の多くが一度は踏む罠です。逆に言えば、ここでハマった経験がある人ほど、C言語の設計思想を体で理解しているとも言えます。

05 POINTERS & TIMING ポインタのサイズと評価タイミング 「何を指しているか」に関係なく一定であること、評価タイミングの原則と例外

ポインタ自体のsizeofは、そのポインタが何の型を指しているかに関係なく、同じ処理系であれば一定です。これは、ポインタが「値そのもの」ではなく「メモリアドレス」を保持する変数だからです。int型を指すポインタも、double型を指すポインタも、構造体を指すポインタも、同じ処理系であれば同じバイト数になるのが一般的です（32bit環境なら4バイト、64bit環境なら8バイトが多いですが、これも実装依存です）。

#include <stdio.h>

int main(void) {
    int    *p_int    = NULL;
    double *p_double = NULL;
    char   *p_char   = NULL;

    printf("sizeof(p_int)    = %zu\n", sizeof(p_int));
    printf("sizeof(p_double) = %zu\n", sizeof(p_double));
    printf("sizeof(p_char)   = %zu\n", sizeof(p_char));
    /* 多くの64bit環境ではいずれも 8 になる（指す型に関係なく同じ） */
    return 0;
}

5-1. sizeofの評価タイミング：原則と例外

前半の章でも触れたとおり、sizeofは原則としてコンパイル時に評価されます。式の中身（例えば関数呼び出しを含む式）を実際に実行するわけではなく、その式が持つ「型」だけを見て、必要なバイト数を計算します。そのため、sizeof(some_function())のように書いても、some_function()自体は呼び出されず、戻り値の型のサイズだけが計算される、という点は覚えておくとよい性質です。

ただし、C99以降で導入された可変長配列（VLA）に対するsizeofだけは例外です。VLAは配列のサイズが実行時に決まる変数（関数の実行中に決まるサイズを使って宣言する配列）であるため、そのsizeofも実行時に評価される必要があります。「sizeofは常にコンパイル時に決まる」という説明を見かけたら、このVLAの例外があることも合わせて押さえておくと、より正確な理解になります。

代表菅澤

「基本はコンパイル時、でも例外がある」という説明、すごく実務っぽいと思いました。エンジニアの人たちがよく『ケースバイケースです』と言う理由が、こういう細部の積み重ねなんだなと腹落ちしました。

06 COMMON BUGS 実務でありがちなバグパターンと防止策 sizeofまわりで発生しやすい典型的なミスをチェックリスト化

ここまで見てきた仕様を踏まえて、実務のコードレビューで実際によく指摘される、sizeofまわりの典型的なバグパターンを整理します。

6-1. sizeofと文字列長（strlen）の違い

char型の配列に対するsizeofは「配列として確保されているバイト数」を返しますが、strlen関数は「文字列の実際の長さ（終端のヌル文字\0を含まない、実際に使われている文字数）」を返します。この2つは似て非なる値であり、配列の確保サイズと、実際に入っている文字列の長さが常に一致するとは限りません。

#include <stdio.h>
#include <string.h>

int main(void) {
    char buf[100] = "hello";
    printf("sizeof(buf) = %zu\n", sizeof(buf));   /* 100 (確保している配列のサイズ) */
    printf("strlen(buf) = %zu\n", strlen(buf));   /* 5   (実際の文字列の長さ) */
    return 0;
}

6-2. 静的解析・コンパイラ警告を活用する

sizeofまわりのバグの多くは、目視のコードレビューだけでは見落とされがちです。コンパイラの警告オプションを厳しめに設定する、あるいは静的解析ツールを併用することで、こうした「動くけれど危険なコード」を検出しやすくなります。人間の集中力に依存しない仕組みを用意しておくことが、実務では特に重要です。

AI鬼管理山崎

このあたりのチェック項目は、実は「エンジニアの経験と勘」に頼っている現場がまだ多い領域です。だからこそ、次の章で紹介するAIによるレビューの実運用データが効いてきます。

07 GENAI CASE STUDY 【独自データ】GENAI社内のAIコード品質チェック実運用 Max 20xプラン契約会社が、開発現場でAIをどう使っているか

ここでは、弊社（株式会社GENAI）で実際にAIエージェント「Claude Code」を運用している状況を、数値と事例ベースで公開します。今回のテーマであるsizeofのような「細部の仕様」がからむコードレビューの現場で、AIがどう機能しているかをリアルに知っていただくための章です。

弊社では「全ての業務を何かしらClaude Codeに絡ませる」という方針で運用しており、開発領域も例外ではありません。細かい仕様の見落とし（今回のようなsizeofの罠を含む）は、人間のレビューだけに頼るとどうしても抜け漏れが出やすい領域ですが、AIエージェントに一次チェックを任せることで、体感として開発業務における書き捨てスクリプトやツール開発のたびに数時間単位の確認作業が削減されています。

7-1. 弊社全体の業務削減データ（参考）

開発領域に限らず、弊社では複数の業務領域でClaude Codeを活用しています。以下は2026年4月時点の肌感ベースの概算値です。

代表菅澤

sizeofの仕様みたいな「知っている人には常識、知らない人には落とし穴」という細部は、経理や営業の実務にもたくさんあります。うちがClaude Codeを全社で使っているのも、こういう細部のチェックを人間だけに背負わせないためです。

08 BEYOND MEMORIZATION 【独自】仕様の細部を暗記しなくていい時代の経営インパクト sizeofのような低レベルな知識は、経営者にとって何を意味するのか

ここまで読んで「配列がポインタに変わる」「構造体のサイズが単純な合計と一致しない」といった話に、正直ピンとこなかった経営者の方も多いと思います。それは自然なことです。sizeofの仕様は、C言語を専門に扱うエンジニアであっても、油断すると踏み外す繊細な領域だからです。

ただし、ここで考えていただきたいのは「この知識を誰が正確に扱えるか」という問題自体が、この数年で構造的に変わってきているということです。かつては、こうした細部の仕様を正確に把握している人材（経験豊富なCエンジニア）を採用するか、社内で長期間かけて育成するかしか選択肢がありませんでした。

8-1. 「知らないと事故る」から「AIが正確に書いてくれる」へ

現在のClaude Codeのような自律型AIエージェントは、今回取り上げたsizeofの配列decayや構造体のアライメントといった、人間のエンジニアでも間違えやすい仕様を踏まえたコードを、高い精度で生成・レビューできます。もちろん「絶対にミスをしない」と保証されているわけではなく、重要な箇所は人間によるレビューが必要ですが、少なくとも「この仕様を知っている人材を採用・育成できるまで開発を進められない」という制約からは解放されつつあります。

これは経営者にとって、実は非常に大きな意味を持ちます。「専門的なC言語エンジニアを採用・育成しなくても、業務システムの自動化や改修に着手できる」ということだからです。これまで「エンジニアがいないから」という理由で止まっていた社内の業務システム改善が、AIエージェントを介することで動き出す可能性があります。

8-2. 非エンジニアがこの変化を活かすための3ステップ

とはいえ、いきなり「全部AIに任せよう」と考えると失敗しがちです。弊社の導入支援の経験からは、以下のようなステップで着手するのが現実的だと考えています。

弊社（株式会社GENAI）自身も、専任のC言語エンジニアを何人も抱えているわけではありません。それでも、業務で必要になるスクリプトやツールの書き捨て、社内システムの細かい改修を、Claude Codeを介して回せています。「技術者を採用・育成しなくても、業務システムを自動化できる」という時代の変化を、実際に社内で体感している立場から、この記事をお届けしています。

AI鬼管理山崎

sizeofのような話は、経営者の方が自分でコードを書くために知る必要はありません。ただ『こういう細部を正確に扱えるかどうかで、システムの品質が変わる』という感覚だけは持っておくと、AI活用の判断がしやすくなります。

代表菅澤

「エンジニアを雇わないと何もできない」時代から、「AIと一緒に判断すれば動き出せる」時代に変わってきていると感じています。この記事を読んで少しでも興味を持っていただけたら、ぜひ次のステップも見てみてください。

09 CONCLUSION まとめ sizeofの正確な理解と、そこから見える経営への示唆

この記事では、C言語のsizeof演算子について、基本的な使い方から、配列・構造体・ポインタそれぞれで起こりやすい罠、実務でのバグパターンと防止策、そして弊社GENAIの実運用データと、こうした知識を経営者が暗記しなくてよくなった時代の意味までを整理しました。最後にポイントを振り返ります。

最も重要なメッセージをお伝えします。sizeofのような細部の仕様を、経営者自身がすべて暗記する必要はありません。大事なのは「こうした細部の正確性が、システムの品質やバグの有無を左右する」という感覚を持ったうえで、それをAIエージェントに任せるという判断ができることです。

弊社では、Claude Codeを「開発の細部を正確にこなしてくれるパートナー」として位置づけることで、専任のエンジニアを大量に抱えなくても、業務システムの改修や自動化を前に進めています。この考え方に共感いただけた方は、ぜひ以下のAI鬼管理までお気軽にご相談ください。

「技術者を採用・育成しなくても自動化できる」を、AI鬼管理が一緒に設計します

sizeofのような細部の仕様に振り回されず、業務システムの自動化を前に進めたい方へ。
弊社の実運用ノウハウをベースに、個別に導入設計のご相談を承ります。

AI鬼管理山崎

「専門のエンジニアがいないから開発を諦めていた」という方にこそ知ってほしい内容です。まずは無料相談で、あなたの会社に最適な進め方を一緒に見つけましょう。

よくある質問

Q. sizeof(配列)とsizeof(ポインタ)の違いは何ですか？

A. sizeof(配列)は配列全体のバイト数（要素数×1要素のサイズ）を返しますが、sizeof(ポインタ)はポインタ自体が占めるサイズ（多くの環境で4バイトまたは8バイト）を返します。配列を関数に渡すと配列はポインタにdecayするため、関数の内部でsizeofを使うとポインタのサイズが返ってしまう点が典型的な混同ポイントです。

Q. なぜ関数に配列を渡すとsizeofで正しい要素数が取れなくなるのですか？

A. C言語の仕様上、配列を関数の引数として渡すと、その配列は自動的に「先頭要素へのポインタ」に変換（decay）されます。関数の内部では受け取った引数はもう配列ではなくポインタとして扱われるため、sizeofを使うとポインタ自体のサイズが返り、元の配列サイズは失われます。対処法として、要素数を別の引数として明示的に渡す設計が広く使われています。

Q. 構造体のサイズがメンバーの合計と一致しないのはなぜですか？

A. CPUが特定の型のデータを効率よく読み書きするために、型ごとに決められたメモリ整列ルール（アライメント）があり、これを満たすためにコンパイラがメンバーの間や構造体の末尾に「パディング」と呼ばれる詰め物のバイトを挿入することがあるためです。具体的な挿入量はコンパイラやCPUアーキテクチャによって異なる実装依存の挙動です。

Q. sizeofは実行時に計算されるのですか、それともコンパイル時ですか？

A. 基本的にはコンパイル時に評価され、実行時のコストはかかりません。ただし例外として、C99以降で導入された可変長配列（VLA）に対してsizeofを使う場合は、配列サイズが実行時にしか決まらないため、実行時に評価されます。「常にコンパイル時」と断定せず、この例外も押さえておくと正確です。

Q. アライメントやパディングを気にしないといけないのはどんな場面ですか？

A. 構造体をそのままファイルに保存したり、ネットワーク経由で送受信したりする場面で特に注意が必要です。送信側と受信側でコンパイラやCPUアーキテクチャが異なると、パディングの入り方が変わって構造体のレイアウトが一致せず、データが正しく読めなくなる可能性があります。こうした用途では、明示的なシリアライズ処理を書くのが安全です。

Q. sizeof(arr)/sizeof(arr[0])で要素数を求める方法はいつ使えなくなりますか？

A. この計算式は、配列そのものの実体が見えているスコープでのみ正しく機能します。配列を関数に引数として渡した場合、関数の内部ではその引数はポインタとして扱われるため、この式を使うと誤った結果になります。配列の実体があるスコープ（多くは呼び出し元）で要素数を計算し、必要であれば別の引数として関数に渡す設計が推奨されます。

Q. 非エンジニアの経営者がこうした技術的な仕様を理解する必要はありますか？

A. 細部を暗記する必要はありません。ただし「配列とポインタは別物」「構造体のサイズは単純合計にならないことがある」といった、細かい仕様の正確性がシステムの品質を左右するという感覚を持っておくことは、開発を依頼したりAIの提案を評価したりする際の判断材料として役立ちます。

Q. Claude CodeはC言語のような低レベルなコードも正確に書けますか？

A. 今回取り上げたsizeofの配列decayや構造体のアライメントのような、人間のエンジニアでも間違えやすい仕様を踏まえたコードを高い精度で生成・レビューできます。ただし絶対にミスをしないと保証されるものではないため、重要な箇所は人間によるレビューを組み合わせる運用が現実的です。

監修 最終更新日: 2026年8月1日

菅澤 孝平 株式会社GENAI 代表取締役

• AI業務自動化サービス「AI鬼管理」を運営 — Claude Code を活用し、経営者の業務を「AIエージェントに任せる仕組み」へ転換するパーソナルトレーニングを 伴走構築 で提供。日報・採用・問い合わせ対応・経費精算・議事録・データ集計・営業リスト等の定型業務を、AIに代行させる体制を経営者と一緒に作り込む
• Claude Code 実装ノウハウを 経営者・法人クライアント に直接指導。生成AIを「便利ツール」ではなく 「業務を任せる存在」 として運用する手法を体系化
• 「やらせ切る管理」メソッドの開発者。シンゲキ株式会社（2021年設立・鬼管理専門塾運営）にて累計3,000名以上の学習者を志望校合格に導いた管理メソッドを、AI × 経営者支援 に転用
• 著書『3カ月で志望大学に合格できる鬼管理』(幻冬舎)、『親の過干渉こそ、最強の大学受験対策である。』(講談社)
• メディア出演: REAL VALUE / カンニング竹山のイチバン研究所 / ええじゃないかBiz 他
• 明治大学政治経済学部卒

現在は AI鬼管理（Claude Code活用の伴走型パーソナルトレーニング）を主事業とし、経営者と二人三脚で「AIに業務を任せる仕組み」を実装。「実行を強制する環境」を AI で構築する手法を、自社の実運用知見をもとに発信している。

▸ 代表 菅澤孝平 のプロフィール詳細を見る