C++Builder が LLVM/Clang を採用する理由（セキュリティ編）

はじめに

近年、ソフトウェア開発の現場では「サイバーセキュリティ」がこれまで以上に重要なテーマとなっています。
その流れの中で、C++について次のような意見を目にする機会が増えました。

• 「C++ は危険だから使うべきではない」
• 「メモリ安全な言語に置き換えるべきだ」
• 「C++ で作られたソフトは脆弱性の温床だ」

こうした議論がある一方で、C++ は現在も多くの分野で使われ続けています。
そして C++Builder もまた、C++ を必要とする現場で利用されている開発環境です。

本ブログでは、Maksim Menshikov氏のブログ「C++, LLVM, and Cybersecurity」の内容をベースに、
なぜ C++Builder が LLVM/Clang を採用するのかを、特にセキュリティの観点からできるだけ分かりやすく整理して紹介します。

なお、本ブログは、C++Builder の操作手順や設定を解説する記事ではありません。
しかし「C++Builder を使うことがセキュリティ的に問題にならないか？」と感じたことがある方にとっては、背景を整理する材料になるはずです。

C++とLLVM/Clang、そしてセキュリティ

1. 「C++ は危険」という話は、どこまで正しいのか？

まず前提として、C++ は メモリ安全（Memory Safe）な言語ではありません。
これは「C++ が劣っている」という意味ではなく、C++ が設計された当初から

• 高い性能
• ハードウェアに近い制御
• 大きな自由度

を優先する思想を持っていたためです。

その結果として、C++ では以下のような問題が起こり得ます。

• バッファオーバーラン
• Use-after-free（解放済みメモリの参照）
• ダングリングポインタ
• 未初期化メモリ参照
• 未定義動作（Undefined Behavior）

つまり「C++ は危険」という主張には、確かに根拠があります。

2. ただし「C++ は危険だから捨てるべき」とは限らない

セキュリティの議論では「C++ は危険」という言い方が注目されがちですが、元記事ではそれを単純に断定するのではなく、
設計や実装、運用の工夫によって安全性を高めることができるという立場で話が進みます。

つまりC++は、危険なコードを書けてしまう一方で、安全なコードを書くこともできる言語であり、適切な使い方が重要だという考え方です。

そして現実として、世の中には C++ で書かれた膨大なコード資産があります。
それは単なる過去の遺産ではなく、現在も以下のような分野で必要とされています。

• OS
• データベース
• ブラウザ
• ゲームエンジン
• 組み込み機器
• 産業機器
• 医療機器
• 金融システム

これらは性能や制御性が求められる領域であり、C++ が今後も長く使われる理由でもあります。
C++Builder のユーザー層は、まさにこうした領域と重なることが多いと言えます。

3. セキュリティの問題は「言語」だけで決まらない

「C++ は危険」という話は分かりやすい一方で、セキュリティの問題は言語だけで決まるわけではありません。

たとえば、同じ C++ でも

• 設計が丁寧
• テストが十分
• 静的解析を活用
• 依存ライブラリを最新化
• 安全なコーディング規約を守っている

ならば、現実的に十分堅牢なソフトウェアを作ることは可能です。

逆に、仮にメモリ安全な言語であっても、

• 認証・認可の設計ミス
• 入力検証不足
• 設定ミス
• 依存ライブラリの脆弱性放置

などで事故は起こり得ます。

つまり、セキュリティは「言語」だけで決まる単純な話ではなく、
開発プロセスや設計、運用の積み重ねによって左右されます。

4. C++ 標準は「安全な方向」に進化している

C++ は歴史が長い言語ですが、現在も進化を続けています。
特に C++20 / C++23 以降の標準は、結果として安全性にも寄与する方向に進んでいます。

例えば次のような機能は、

• 曖昧さを減らす
• 意図を明確に書ける
• ミスをコンパイル時に検出しやすくする

といった点で、堅牢なコードを書くための土台になります。

• Concepts（型制約）
• constexpr の拡張
• 初期化規則の改善
• オブジェクトライフサイクルの明確化
• 標準ライブラリの拡充

5. C++ の弱点：Undefined Behavior（未定義動作）

C++ の安全性を語るうえで、避けて通れないのが「未定義動作（Undefined Behavior）」です。

これは簡単に言うと、

「こういうコードを書いた場合、結果は保証しない」
「何が起きても仕様上は正しい」

という状態です。

未定義動作は厄介で、

• たまたま動くこともある
• あるコンパイラでは動くが、別のコンパイラでは壊れる
• 最適化レベルを変えたら壊れる
• OS更新で壊れる

といった形で、トラブルや脆弱性の温床になり得ます。

6. コンパイラ最適化は、速度を上げるが危険にもなり得る

コンパイラの最適化は、性能を上げるために重要です。
しかし未定義動作が含まれるコードに対しては、

• 最適化によって意図しないコード生成になる
• “安全だと思っていた動き” が消える

といったことが起こり得ます。

この点は、C++Builder を含むすべての C++ 開発環境に共通する話です。

7. ではどうする？ → ツールと検証の進化が鍵

ここで LLVM の話につながります。

現代の C++ では、セキュリティ向上のために次のような検証手法が発展しています。

• 静的解析（怪しいコードを警告する）
• 動的解析（実行時に問題を検出する）
• Sanitizer（メモリエラーなどを実行時に検出）
• Fuzzing（異常入力を大量に試して脆弱性を探す）

そしてこれらの多くは、LLVM / Clang を基盤として発展してきました。

8. LLVM は「C++ を捨てる」のではなく「C++ を強くする」

元記事では、LLVM/Clang の役割を「C++ を置き換えるためのもの」ではなく、
C++ をより安全に使うための基盤として捉えています。

LLVM / Clang は、

• モジュール化されていて拡張しやすい
• 診断・解析系ツールと相性が良い
• エコシステムが巨大
• 研究・検証が活発

という特徴を持ちます。

その結果として LLVM は、C++ を「捨てる」方向ではなく、
C++ を「より安全に使う」方向へ押し上げる役割を担っている、という説明になります。

9. C++Builder ユーザーにとっての意味

ここが、C++Builder ユーザーにとって最も重要なポイントです。

C++Builder の最新コンパイラ（bcc64x）は LLVM/Clang ベースです。
つまり C++Builder は、コンパイラ基盤として LLVM の恩恵を受ける方向に進んでいます。

このことは、将来的に

• より強い診断
• より強い解析
• より多くの検証ツールとの親和性

といった面でメリットになる可能性があります。

この記事は「C++Builderの新機能紹介」ではありませんが、
C++Builder が LLVM を採用する意味を、セキュリティ観点で説明していると捉えることができます。

C++Builder で取り入れやすいセキュリティ対策（7つのポイント）

ここまで述べた通り、C++ の安全性は「言語を変えれば終わり」という話ではありません。
C++Builder を使う場合も、コーディング規約・設計・ビルド設定・運用を組み合わせることで、
リスクを現実的に減らすことができます。

以下では、C++Builder ユーザーが実務で取り入れやすい対策を、
「優先順位」ではなく「効果的なポイント」として7つ紹介します。
実際の優先度は、アプリの構成や運用形態によって異なります。

(1) 外部入力の検証を徹底する

C++ の脆弱性は「メモリ破壊」が注目されがちですが、実務では外部入力の扱いが非常に重要です。

C++Builder のアプリでも、

• ファイル入力
• ソケット通信
• REST API
• DB入力
• 画面入力

など、外部から来るデータは必ず検証するのが基本です。

(2) 危険な書き方を減らす

C++Builder でも、次のような書き方はセキュリティ事故の原因になりやすい傾向があります。

• 生ポインタの new / delete の多用
• strcpy / sprintf のような危険な関数
• バッファサイズ管理が曖昧なコード
• メモリ所有権が不明確な API

可能な範囲で、

• RAII（自動解放）
• std::unique_ptr / std::shared_ptr
• std::vector / std::string
• std::array

など、標準ライブラリ中心の書き方へ寄せることが有効です。

(3) コンパイラ警告を減らす

コンパイラ警告を減らすことは、未定義動作や境界値バグの抑制につながります。

• 警告を放置しない
• 型変換の警告を潰す
• signed/unsigned の違いを潰す
• 未使用変数や未初期化の疑いを潰す

(4) 依存ライブラリ（DLL / SDK）を最新化する

C++Builder のコード自体は問題なくても、

• OpenSSL
• libcurl
• zlib
• DBドライバ
• WebView系コンポーネント

など、外部ライブラリ側の脆弱性で事故が起きることがあります。

可能な範囲で「古い DLL を抱え続けない」ことが重要です。

(5) ビルド設定を見直す

C++Builder は Windows アプリ開発が中心のため、
Windows の保護機構（ASLR、DEP など）を活かすのは有効です。

環境・バージョンによって細部が変わるため、本記事では深掘りしませんが、

• リリースビルド設定を適切にする
• 古い互換設定を残さない
• デバッグ情報やログの扱いに注意する

といった点は、セキュリティ上も重要になります。

(6) 64bit へ移行する

32bit より 64bit の方が

• アドレス空間が広い
• OS側の保護機構が強いケースが多い

ため、結果として堅牢性が上がることがあります。

C++Builder では以前から 64bit アプリケーションの開発が可能であり、
可能であれば 64bit への移行を検討する価値があります。

(7) LLVM/Clang 採用のメリットを理解しておく

C++Builder が LLVM/Clang ベースになっていくことで、将来的に

• より強い診断
• より強い静的解析
• より多くの検証ツールとの連携

が期待できます。

特に bcc64x は LLVM/Clang ベースのコンパイラであり、
今後の C++ 標準への追従や、ツールチェーンの発展という面でも重要な位置づけになります。

つまり LLVM 採用は「性能や互換性」だけでなく、
セキュリティの土台としても意味がある、というのがこの記事の主張です。

おわりに

C++Builder で C++ を使う以上、リスクをゼロにすることはできません。
しかし、LLVM/Clang の進化と、日々の運用・設計の工夫によって、
現実的な安全性を確保することは十分可能です。

C++Builder を使う開発現場でも、
「安全な C++ を書く」「危険な部分を減らす」という視点は、今後ますます重要になっていくでしょう。