0
✦ 品質
🛡 セキュリティ
⚙ 保守性
📋 概要
C++17とOpenGL 3.3 Coreで構築された2×4木造建築フレームのミニCADアプリケーション。外部の数学・JSON・UIライブラリを一切使わず、線形代数・レイピッキング・JSONパーサ・ストロークフォントをすべて自前実装しており、建物仕様をhouse.jsonから読み込み71以上の構造部材を手続き的に生成・描画・CSV出力できる。
🎯 今すぐ直すべき3点
-
src/json_parser（推定） 自作JSONパーサにおける入力バリデーション（文字列長・ネスト深さ・不正エスケープ）を追加し、house.jsonに悪意ある入力が渡された際のバッファオーバーフローやスタックオーバーフローを防ぐ↗
-
house.json JSONスキーマ定義ファイル（house.schema.json等）を追加し、幅・奥行・窓/ドア位置の型・範囲・必須フィールドを明示することで、不正な入力による未定義動作を防ぐ↗
-
CMakeLists.txt（推定） AddressSanitizer（-fsanitize=address）およびUBSanitizer（-fsanitize=undefined）をCMakeのDebugビルドオプションに追加し、自作線形代数・JSONパーサにおけるメモリ安全性の問題を早期検出できるようにする↗
🔍 検出された問題 (6件)
🟥 Critical
📄 src/json_parser（推定ファイル名）
自作JSONパーサにおける入力検証の欠如リスク
外部ライブラリを排除した自作JSONパーサは、RFC 8259準拠の境界チェック（深すぎるネスト・巨大文字列・不正なUnicodeエスケープ）が実装されていない可能性が高い。house.jsonに細工されたペイロードを渡されると、スタックオーバーフローやバッファオーバーリードによりプログラムのクラッシュや未定義動作を引き起こす危険がある。
🟥 Critical
📄 src/math（推定ファイル名）
自作線形代数ライブラリにおける数値安定性・境界チェック未保証
glm等の検証済みライブラリを使わず自前実装した行列・ベクトル演算は、ゼロ除算（投影行列のFOV=0時など）・逆行列の特異行列ケース・float精度誤差の累積が未テストである可能性がある。CADアプリとして実寸(mm)精度を要求する場面でサイレントな計算誤差が発生すると、部材配置・ピッキング判定が静かに狂い、デバッグが困難になる。
🟧 Warning
📄 src/stroke_font（推定ファイル名）
自作ストロークフォントのグリフデータがハードコードされている可能性
寸法線の数値描画に使うストロークフォントのグリフ定義が静的配列等でソースにハードコードされている場合、フォントの追加・修正にコンパイルが必要になり、国際化（全角・単位記号追加等）や文字セット拡張のコストが高い。また静的配列サイズミスによるOOBアクセスリスクも存在する。
🟧 Warning
📄 src/picking（推定ファイル名）
AABBピッキング判定でのローカル空間変換の正確性が未検証
READMEに「回転部材はローカル空間でAABB判定」と記載されているが、回転行列の逆変換をレイに適用する実装で転置と逆行列を混同すると、斜め部材（斜めスタッド等）のピッキング精度が劣化する。ユーザーが意図と異なる部材を選択してしまい、CSV出力データの誤りにつながる危険がある。
🟨 Suggestion
📄 README.md
READMEにビルド手順・依存バージョンの明示が不足
GLFW・GLEWの必要バージョン、CMakeの最低バージョン、各プラットフォームでのセットアップコマンドがREADMEに記載されていない。コントリビューターや採用担当者がビルドを試みた際に環境依存の失敗が起きやすく、ポータビリティのアピールが半減する。
🟨 Suggestion
📄 tests/（推定・不在）
ユニットテストが存在しない（推定）
自作線形代数・JSONパーサ・ストロークフォントという品質がプロジェクト全体の正確性を左右するコンポーネントに対してテストコードが確認できない。これらのコンポーネントは回帰バグが他のモジュールに波及しやすく、リファクタリング時の安全網がない状態でのコード変更はサイレントな計算誤差を埋め込むリスクがある。
✅ 良い点
- 外部数学ライブラリ（glm等）を使わず自前実装した線形代数・カメラ・レイピッキングが、依存関係ゼロのポータブルなビルド環境（Windows/macOS/Linux同一ソース）を実現しており、組み込み・業務CAD環境への移植コストが低い
- house.jsonによるデータ駆動設計が、部材生成ロジックとUI/レンダリングの関心を分離しており、建物仕様変更時にC++コードを変更せず設定ファイルのみの修正で対応できる拡張性を持つ
- 全部材へのID（例: S-014）・ゾーン・断面・材長・材種の付与というBIM的アプローチが、CSV出力と組み合わさることで積算・拾い出しワークフローへの実用的な接続を示している
🔧 リファクタ提案
- 自作JSONパーサをsrc/json/JsonParser.h + JsonParser.cppとして独立モジュール化し、GoogleTestまたはCatch2でRFC 8259のエッジケース（空オブジェクト・深いネスト・Unicode）を網羅するユニットテストを追加する
- 線形代数ライブラリのVec3・Mat4・Quatをテンプレートクラスとして再設計し、float/double両対応にすることで、将来的な高精度モード（建築mm精度→μm精度）への対応コストを下げる
- 部材生成ロジック（Stud/Plate/Joist等の配置計算）をFrameBuilderクラスとして切り出し、house.jsonのパース結果であるBuildingSpecをDTOとして注入するDependency Injectionパターンに変更することで、テスト時にjsonファイルなしでパラメータを直接渡せるようにする
🔒 セキュリティ注意点
- house.jsonをユーザー指定パスから読み込む場合、パストラバーサル（../../../etc/passwd等）を防ぐためにrealpath/canonicalによるパス正規化と許可ディレクトリの制限を実装すること
- 自作JSONパーサで文字列トークンをchar配列に格納する実装の場合、入力文字列長に対する上限チェック（MAX_STRING_LEN）を設けていないとスタックバッファオーバーフローが発生する。std::stringへの切り替えまたは明示的な長さ制限ガードを追加すること
📤 PRコメント出力
このレビューをGitHub PRコメントとして貼り付けられるMarkdown形式で出力します。
Generated with CodeLens AI v1.0
Designed & Developed by Mize
View Creator
mize1978.github.io
本レビューは CodeLensAI による自動解析結果であり、リポジトリ所有者による投稿・承認を意味しません。公開リポジトリを対象に生成され、公開アーカイブに保存されます。