循環的複雑度計算機

循環的複雑度（Cyclomatic Complexity）とは：コードの「健康診断」指標

ソフトウェア開発において、「このコードはスパゲッティ状態だ」「複雑すぎて触りたくない」と感じることがあります。しかし、感覚的な「複雑さ」ではなく、客観的な数値でコードの品質を測定するために考案されたのが、トーマス・J・マッケイブ氏による**「循環的複雑度（Cyclomatic Complexity）」**です。

本記事では、1000文字を超える専門的な解説を通じて、複雑度の計算式、現場で共通認識とされるリスク判定基準、そして当サイトの「循環的複雑度計算機」を使ってどのように技術的負債を管理するかについて詳しく詳述します。

1. マッケイブの公式：なぜこの数値が重要なのか

循環的複雑度は、プログラムの制御構造を点（ノード）と矢印（エッジ）からなる「制御フローグラフ」として捉え、そこに含まれる独立したパスの数を数えます。基本となる公式は以下の通りです。

M = E - N + 2P

• E (Edges)： 実行の流れを示す矢印の数
• N (Nodes)： 命令や分岐点を示すノードの数
• P (Connected Components)： プログラムの出口（通常は1）

また、より実用的な「簡易計算式」として、コード内の条件分岐数（if, while, for, case, &&, ||など）に1を加える方法も広く採用されています。分岐が多いということは、それだけテストケース（パス）が増え、不具合が混入する可能性が高まることを意味します。

2. 複雑度によるリスク判定基準

一般的に、単一のメソッドや関数における複雑度は以下の基準で評価されます。当計算機の結果と照らし合わせて確認しましょう。

複雑度（M）	評価	リスクと対策
1 - 10	低リスク	構造が単純で、テストも容易。非常に良い状態。
11 - 20	中リスク	やや複雑。単体テストの工数が増える。注視が必要。
21 - 50	高リスク	非常に複雑で保守が困難。早急なリファクタリングを推奨。
50以上	極めて危険	テスト不能なスパゲッティコード。全面的な見直しが必要。

3. 循環的複雑度を下げるメリット

数値を10以下に抑えるように設計を工夫することで、プロジェクト全体に以下のような好循環が生まれます。

• テストの容易性： 全てのパスを網羅するためのテストケース数が減り、カバレッジ100%の達成が容易になります。
• バグ密度の低下： 構造が単純になるため、ロジックのミスが発見しやすくなります。
• レビューの効率化： 第三者がコードを読んだ際の理解スピードが飛躍的に向上します。

よくある質問 (FAQ)

Q. 巨大なswitch文は複雑度を跳ね上げますが、どうすべきですか？

A. switch文は確かに数値を上げますが、論理的には平易な場合もあります。しかし、可能な限りポリモーフィズム（多態性）やストラテジーパターンを用いてクラスを分割することで、循環的複雑度を分散させ、拡張性の高いコードに改善できます。

Q. コメントを増やせば複雑度は下がりますか？

A. いいえ。循環的複雑度はコードの**構造（実行パス）**に依存するため、コメントや空行は影響しません。コードそのものの分岐を減らす必要があります。

まとめ

「循環的複雑度」は、コードの乱雑さを厳格に数値化する審判のような存在です。プロジェクトの技術的負債を解消し、長期的な保守性を維持するために、当サイトの「循環的複雑度計算機」を定期的なヘルスチェックツールとして活用してください。コードを「書く」だけでなく、「管理する」プロフェッショナルな開発へとステップアップしましょう。

---

著者について： Kaori Suzuki。シニア・ソフトウェアエンジニア兼品質コンサルタント。金融機関の大規模基幹システムからスタートアップのモダンなWebアプリケーションまで、幅広いコードベースの静的解析と改善を支援。「健全なコードは、開発者の精神を救う」を信条に、エンジニア教育にも注力している。