C++のコーディング規約の主な種類とチームでの決め方

C++のコーディング規約は、命名や書式をそろえる「スタイル」の規約と、事故につながりやすい言語機能の使い方を決める「安全性」の規約に分かれます。代表的なものにGoogle C++スタイルガイドとC++ Core Guidelinesがあり、ほかに安全性・セキュリティ・組込み開発に向けた規約もあって、どれを土台にするかは既存のコードと開発対象で決まります。

主な規約の特徴と選び方、clang-formatやclang-tidyで規約をチームに定着させる手順、そして規約の運用を担うテックリードの仕事を、Offers の求人データとあわせてまとめました。

C++のコーディング規約の目的と、スタイルと安全性の2つの層

C++のコーディング規約の目的は、チームの誰が書いても同じように読めるコードにして保守の手間を減らすことと、不具合や脆弱性につながる書き方を前もって避けることの2つです。前者を受け持つのが命名・インデント・行の長さを決めるスタイルの規約で、後者を受け持つのがメモリ管理や型変換などの使い方を決める安全性の規約です。

Google C++スタイルガイドは、コードベース全体で書き方を一貫させる理由として、書式の議論に時間を使わずに重要な問題へ集中できることと、整形ツールなどの自動化が正しく働くことを挙げています（Google C++ Style Guide・2026年10月確認）。

Google C++スタイルガイドは書式だけでなく言語機能の使い方まで決めているため、両方の層にまたがる規約です。言語が変わっても規約の考え方は同じで、Java の例は「Javaのコーディング規約」で扱っています。

C++で規約が欠かせない理由

C++は同じ処理を書く方法が多く、メモリを直接扱えるぶん、書き方の違いがそのまま不具合や脆弱性の差になりやすい言語です。C++ Core Guidelines は、静的な型の安全性と資源（メモリなど）の安全性を重視し、言語の中で誤りを生みやすい部分を取り除くか最小にする方法を示す指針だと説明されています（Microsoft Learn・2026年10月確認）。

C++の言語規格が改訂されるたびに新しい書き方が加わる点も、規約が要る理由です。チームで使ってよい規格のバージョンと機能を決めておかないと、同じリポジトリの中に古い書き方と新しい書き方が混ざり、読む人がそのたびに意図を推し量ることになります。

C++の主なコーディング規約6つの特徴

C++で参照される主な規約は、汎用の2つ、安全性・セキュリティ・組込み向けの3つ、OSS（オープンソースソフトウェア）のプロジェクトの規約の6つです。向いている開発と、前提にするC++の規格のバージョンが規約ごとに違います。

• 汎用の規約として、Google C++スタイルガイドと C++ Core Guidelines
• 安全性向けに、MISRA（The Motor Industry Software Reliability Association）が発行する MISRA C++:2023
• セキュリティ向けに、米カーネギーメロン大学のSEI（ソフトウェア工学研究所）のCERT（SEIのセキュリティ部門）がまとめた SEI CERT C++ Coding Standard
• 日本の組込み向けに、IPA（情報処理推進機構）の ESCR（Embedded System development Coding Reference）C++
• OSSのプロジェクトの規約として、LLVM（コンパイラ基盤のプロジェクト）・WebKit・Chromium の規約

出所: 各規約の公式ページ（2026年10月確認）。

Google の C++ 規約は汎用の開発の土台にしやすい

Google C++スタイルガイドは、命名・書式から言語機能の使い方までを1つの文書で決めており、規約を持たないチームが最初の土台にしやすい規約です。2026年10月時点のガイドはC++20をターゲットにし、C++23の機能は使わないとしており、対象の規格は今後も上がると明記しています（Google C++ Style Guide）。

命名は、型と関数の名前を単語の頭を大文字にする形（PascalCase）、変数の名前を小文字とアンダースコアでつなぐ形（snake_case）で書き、クラスのデータメンバーには末尾にアンダースコアを付けます。インデントはスペースのみで2文字ずつ、1行は80文字までです。書式の誤りの検出には cpplint というツールが案内されています。

英語の原文に加えて、有志による日本語の全訳（Google C++ スタイルガイド 日本語全訳）もあり、底本は2025年8月時点の原文です。ChromiumはこのGoogleの規約に従い、例外だけを自前の文書に書く形をとっています。

C++ Core Guidelines はツールで検査する前提の指針

C++ Core Guidelines は、Bjarne Stroustrup と Herb Sutter が編集する、モダンC++を安全に使うための指針で、継続的に更新される文書として公開されています（C++ Core Guidelines・2026年10月確認）。対象のモダンC++は、2026年10月時点でC++20とC++17です。

C++ Core Guidelines は、ルールを人が暗記して守るものではなく、ツールが違反を見つけるための対象として書いたと説明しています。既存のコードベースへ少しずつ導入することも前提です。Visual Studio はルールの一部をコード分析（C++ Core Check）として持ち、clang-tidy にも cppcoreguidelines- で始まるチェックがあります。

MISRA C++:2023は安全性が重視されるシステム向けの規約

MISRA C++:2023は、安全性が重視されるシステムでC++17を使うための規約で、2023年10月に発行された最新版です（MISRA・2026年10月確認）。前提の言語規格は2017年版の国際規格（C++17）で、文書は MISRA のウェブストアで電子版を購入できるほか、印刷版も注文できます。ストアで売られているのは、2026年の正誤表（TC1:2026）を反映した文書です（MISRA のストア・2026年10月確認）。

不具合が重大な結果につながるシステムを想定した規約です。汎用のアプリケーションに当てはめるなら、守る手間と得られる安全性のつり合いを先に見積もっておく必要があります。

SEI CERT C++はセキュリティの欠陥を減らすための規約

SEI CERT C++ Coding Standard は、セキュリティ上の欠陥を減らすためのルールを集めた規約で、2016 Edition が電子版で公開されています（SEI CERT C++ Coding Standard・2026年10月確認）。C++14 を前提に作られ（CERT C++ の Scope）、C言語版の CERT C Coding Standard も参照し、前提に置いた規約です。

外部からの入力を扱うサーバーやライブラリでは、CERT のルールを安全性の土台に加えると、脆弱性につながる書き方を検査で拾いやすくなり、clang-tidy の cert- で始まるチェックがその入口になります。セキュリティの観点から規約を考える流れは「セキュアコーディング規約」で詳しく扱っています。

IPAのESCR C++は日本の組込み開発向けのコーディング作法

ESCR C++ Ver. 2.0は、IPA（情報処理推進機構）のソフトウェア高信頼化センターが2016年10月1日に発行した、組込みソフトウェア向けのコーディング作法ガイドです（IPA・2026年10月確認）。改訂前のガイドから、準拠する言語規格をC++03からC++11/C++14へ改め、新しい機能のルールを加えています。

電子版は IPA のサイトから無償でダウンロードできます。書籍版（定価1,528円・税込）は2024年4月に販売を終えました。作法とルールの番号はC言語版と共通にしてあるため、C言語とC++が混在する組込み開発で規約をそろえやすい点が特長です。C言語版の考え方は「C言語のコーディング規約」で扱っています。

LLVM・WebKit・ChromiumはOSSに貢献するときに従う規約

LLVM・WebKit・Chromium の規約は、それぞれの OSS プロジェクトにコードを送るときに従う規約で、ほかの開発で使うなら clang-format の既定の書式として取り入れる形が手軽です。LLVMの規約は、特に断りがない限りC++17で書くとし、既存のコードを直すときはそのコードの書き方に従うことを原則にしています（LLVM Coding Standards・2026年10月確認）。

WebKitの規約は、タブではなくスペースを使い、インデントを4文字にし、switch文の case ラベルを switch と同じ位置にそろえると定めています（WebKit Code Style Guidelines・2026年10月確認）。Chromiumは、clang-format が整形した結果をコードレビューで常に受け入れる方針を規約に書いています（Chromium C++ style guide・2026年10月確認）。

C++のコーディング規約は既存コードと開発対象で選ぶ

C++のコーディング規約は、既存のコードがあるかと、何を開発するかの2点で選ぶと迷いにくくなります。既存のコードがあればその書き方に合わせるのが先で、新しく決めるときは開発対象に合った安全性の規約を選び、書式は clang-format の既定のスタイルから選ぶのが近道です。

既存のコードがあるなら既存の書き方に合わせる

既存のコードがあるプロジェクトでは、どの規約が優れているかより、既存のコードの書き方に合わせることを優先します。Google C++スタイルガイドは既存のコードとの一貫性を原則の1つに挙げ、LLVMの規約も既存のコードを大規模に再整形するだけの変更は望まないと明記しています。

規約を変えたいときは、新しく書くコードと手を入れたファイルから順に新しい規約を当てていく進め方が現実的です。全ファイルを一度に整形すると、変更履歴（git blame など）から誰がなぜその行を書いたかを辿りにくくなります。

新しく決めるなら書式と安全性で土台を分ける

新しく規約を決めるときは、書式は clang-format の既定のスタイルから1つを選び、安全性のルールは開発対象に合った規約から必要な部分を選ぶと、ゼロから書くより短い時間でチームの合意をとれます。clang-format の設定で土台に指定できる既定のスタイルは、LLVM・Google・Chromium・Mozilla・WebKit・Microsoft・GNU（GNU プロジェクトのコーディング標準）の7つです（Clang-Format Style Options・2026年10月確認）。

書式は好みで議論が割れやすいので、既定のスタイルのうち既存のコードに近いものを選び、変える項目を最小限にするのが合意への近道です。安全性のルールは、C++ Core Guidelines や CERT のチェックを最初は警告として流し、件数を見ながら段階的に必須へ上げていくと、開発を止めずに導入できます。

テックリードの求人に見るコード品質をそろえる仕事

チームのコードの書き方と品質をそろえる仕事は、Offers の正社員求人では、テックリード以外の求人より多くテックリードの職務として書かれています。規約の文書を書くことそのものより、コードレビューや開発プロセスの整備を通じてコードの品質をそろえることが求められている点が特徴です。

タイトルにテックリードかテクニカルリード（英語表記を含む）を含む Offers の正社員求人では、求人本文にコードレビューの語が載るものが31.5%、開発プロセスの語が載るものが28.8%でした（Offers（株式会社overflow）調べ・正社員求人 n=111・2022年3月〜2026年9月公開）。

デザイナーやPdMなども含むテックリード以外の正社員求人と比べると、コードレビューは4.1倍、開発プロセスは3.8倍の割合です（倍率はOffersが算出）。

出所: Offers（株式会社overflow）調べ・タイトルにテックリードかテクニカルリード（英語表記を含む）を含む正社員求人111件とそれ以外の正社員求人3,197件・2022年3月〜2026年9月公開。

比べる相手を職名にエンジニアや開発などを含む求人に絞ると、コードレビューの語は10.0%、開発プロセスの語は8.6%で、テックリード職の求人はどちらも約3倍（3.2倍と3.3倍）の割合でした。

コーディング規約の語そのものを挙げるテックリード求人は少数です。規約を文書にすることより、レビューやCI（継続的インテグレーション）、開発プロセスを整えて、書き方とコードの品質をチームでそろえる仕事が求められていると読めます（求人の記載率からの編集部の見立てです）。

開発チームが自分たちで生産性を上げる仕組みづくりの実例は、CTOの登壇をまとめた「チームが自律して生産性を改善できる3つの原則」で紹介しています。

テックリード職の求人の提示年収

タイトルにテックリードかテクニカルリード（英語表記を含む）を含む Offers の正社員求人の提示年収は、年収下限の中央値が700万円、年収上限の中央値が1,199.5万円で、上限が800万円以上の求人は94.3%でした（Offers（株式会社overflow）調べ・年収の下限と上限を記載した正社員求人 n=106・2022年3月〜2026年9月公開）。

本文にC++を含む正社員求人の提示年収は、年収下限の中央値が500万円、年収上限の中央値が900万円でした（Offers（株式会社overflow）調べ・年収の下限と上限を記載した正社員求人 n=147・2022年9月〜2026年5月公開）。

規約の整備やコードレビューを任された経験が、どの企業でどう評価されるかは、実際の求人と届くオファーで確かめるのが早道です。Offers に経歴を登録しておくと、設計やレビューの経験に対して、どんな企業からどんな職名でオファーが届くかで市場での評価を確かめられます。

C++の求人では規約の名前より設計の経験が問われる

本文にC++を含む Offers の正社員求人では、コーディング規約の語が載るものは1件もなく、コードレビューも0.7%（1件）にとどまり、設計・アーキテクチャの語は88.6%でした（Offers（株式会社overflow）調べ・本文にC++を含む正社員求人 n=149・2022年9月〜2026年5月公開）。

正社員求人全体でも、MISRA・CERT・C++ Core Guidelines・Google のスタイルガイドの名や、clang-format・clang-tidy の名を挙げる求人は1件もありませんでした。

Offers の求人を見る限り、特定の規約を知っているかが選考の条件として書かれることはまれです。面接で規約の経験を伝えるなら、どの規約を土台に選び、なぜその例外を設け、どうやってチームに定着させたかを、レビューやCIの仕組みと合わせて説明すると、テックリードの仕事に近い経験として伝わります。

C++のコーディング規約をチームで運用する4つの手順

C++の規約を文書にして配るだけでは、守られる状態は長く続きません。土台の規約と外すルールを1か所に書く、書式を自動整形にする、安全性のルールをCIで検査する、レビューでは機械が見られない点に集中する、の4つを順に整えると、規約がチームに定着します。

土台の規約と外すルールを1か所に書く

チームの規約は、土台にした規約の名前とバージョン、外すルールとその理由を、リポジトリの中の1つの文書にまとめて書きます。理由が残っていないと、後から入ったメンバーがそのルールに従うべきかを判断できないためです。

出所: Google C++ Style Guide（2026年10月確認）。

書式は clang-format で自動整形にする

書式のルールは、clang-format の設定ファイル（.clang-format）をリポジトリに置き、保存時やコミット前に自動で整形する形にすると、レビューで書式を指摘し合う手間がなくなります。設定は既定のスタイルを指定し、変えたい項目だけを書き足す形が基本です。

LLVM のスタイルを土台にインデントだけ4文字にするなら、.clang-format に BasedOnStyle: LLVM と IndentWidth: 4 の2行を書けば足ります（Clang-Format Style Options の設定例）。

Chromium が clang-format の整形結果をレビューで常に受け入れる方針を置いているように、整形ツールの出力を正とする合意を先に作っておくと、書式をめぐる議論そのものがなくなります。

安全性のルールは静的解析でCIに組み込む

言語機能の使い方のルールは、clang-tidy などの静的解析ツールで検査し、CI でプルリクエストごとに走らせると、人の目に頼らずに守られる状態を作れます。clang-tidy には、C++ Core Guidelines（cppcoreguidelines-）、CERT（cert-）、Google（google-）、LLVM（llvm-）の規約に対応したチェックの群があります（Clang-Tidy・2026年10月確認）。

C++ Core Guidelines と CERT のチェックだけを有効にするなら、.clang-tidy に Checks: '-*,cppcoreguidelines-*,cert-*' と書き、いったんすべてのチェックを外してから必要な群を足す形にします。

Visual Studio を使うチームは、コード分析の設定で C++ Core Check のルールセットを有効にできます。MISRA C++:2023 に準拠したいときは、検査に使うツールがそのルールに対応しているかを先に確かめるのが確実です。

コードレビューでは機械が見られない設計と命名の意図に集中する

書式と言語機能の検査を機械に任せると、コードレビューでは、責務の分け方や名前が意図を表しているかといった、ツールでは判定できない点に時間を使えます。C++ Core Guidelines 自身も、ルールは人や機械が考えずに従えるほど厳密ではないと断っています。

規約は一度決めて終わりではありません。チームで使うC++の規格を新しくするとき、新しいメンバーが規約の意図を何度も質問するとき、外したルールが増えてきたときが見直しの合図です。見直しの議論と決定の記録を残すことまでが、規約を運用する人の仕事になります。

C++のコーディング規約とテックリードの仕事の要点

スタイルと安全性の2つの層に分けて考え、既存のコードと開発対象に合わせて土台を選ぶのが、C++のコーディング規約の基本です。

• 規約は、命名や書式をそろえるスタイルの層と、言語機能の使い方を決める安全性の層に分かれる
• 既存のコードがあれば既存の書き方を優先し、新しく決めるなら書式は clang-format の既定のスタイル、安全性は開発対象に合う規約（汎用なら C++ Core Guidelines、安全性重視なら MISRA C++:2023、セキュリティ重視なら CERT C++）を土台にする
• 定着させるには、書式を自動整形、安全性を CI の静的解析、設計と命名をコードレビューと、受け持ちを分ける
• Offers のテックリード求人では、コードレビューと開発プロセスの語がそれ以外の求人（全職種）の約4倍、職名がエンジニア系の求人と比べても約3倍の割合で載り、レビューとプロセスを通じて品質をそろえる仕事がテックリードに求められていると読める

Offers（株式会社overflow が運営）は、エンジニア・デザイナー・PdMなどITプロダクト職の正社員転職に特化したサービスです。チームの規約づくりやコードレビューを担ってきた経験を次の職場でどう生かせるかは、Offers で届くオファーの職名と提示年収から確かめられます。