コードの視覚化: 複雑なコードを図に変える方法

5,000行のCOBOLプログラムを読めば、各ステートメントが何をするのかがわかります。そのプログラムの依存関係グラフを見れば、それが何に接続し、何に依存し、変更すると何が壊れるのかがわかります。メインの実行パスのフローチャートを見れば、さまざまな入力に対してプログラムがどのように動作するかがわかります。これら3つの図を合わせると、ソースコードを1日かけて読むよりも、わずか10分でより多くの実用的な洞察が得られます。これこそがコード可視化の核心的な価値提案です。テキストによる論理を、行ごとに読むだけではわからない関係性、流れ、リスクを明らかにする空間的で視覚的な構造に変換するのです。

コード可視化は単一の手法ではなく、フローチャート、UML図、依存関係グラフ、シーケンス図、状態図、呼び出しグラフなど、それぞれ異なる課題に適した様々な表現方法の集合体です。適切な課題に対して適切な表現方法を選択することが、重要なスキルとなります。この記事では、図の種類、コードから図を自動生成するツール、図をコードとして同期させるアプローチ、そしてレガシーシステムと最新システムの両方でエンタープライズ可視化がどのように機能するかについて解説します。

認定条件 SMART TS XL システム全体にわたる図を生成します

SMART TS XL COBOL、JCL、Java、.NET、Python、RPG、SQLなど、環境内のあらゆる言語とプラットフォームを解析し、すべての構造的関係を表す統一された相互参照モデルを構築することで、エンタープライズシステムの可視化における課題を解決します。生成される図は手描きの成果物ではなく、実際のコードの構造分析から直接出力されるため、常にコードベースの現在の状態と同期しています。

その コードの視覚化 の能力 SMART TS XL 複数の図タイプを生成します。

• 依存関係マップ どのプログラム、モジュール、コンポーネントが他のどのプログラム、モジュール、コンポーネントに依存しているかを、システム全体から個々のコピーブックメンバーやデータベース列に至るまで、あらゆる粒度レベルで表示します。
• 通話グラフ どのプログラムが他のどのプログラムを呼び出すかを示し、言語の境界を越えて任意の開始点から任意の深さまでたどることができる。
• データフロー図 特定のフィールドまたはデータ要素が、その発生源から読み書きまたは変換されるすべての場所まで、システム内をどのように移動するかを追跡する。
• 衝撃図 提案された変更から生成されるもので、その変更が行われた場合に影響を受けるすべてのコンポーネントを示します。

その アプリケーション依存関係マッピング この機能は、システムレベルにまで拡張され、アプリケーション全体がどのように相互作用するかを示すマップを作成します。これは、アーキテクチャレビュー、近代化計画、および規制遵守文書の作成に使用されます。

実施するチーム向け レガシーの近代化, SMART TS XLの視覚化は計画の基盤となります。現在のシステムの依存関係マップは移行の順序を決定し、呼び出しグラフはどのコンポーネントを独立して変換できるかを特定し、影響図は計画された変更が、変更されたコンポーネントに依存するコンポーネントで予期しない障害を引き起こさないことを検証します。

コードの視覚化とは何ですか?

コード可視化とは、ソースコード、その構造、動作、依存関係を、テキスト形式ではなくグラフィカルな形式で表現する手法です。可視化されたコードベースは、テキストでは容易に伝えられない情報、つまり、どのコンポーネントが他のコンポーネントに依存しているか、条件分岐を通じて実行がどのように流れるか、モジュールが時間とともにどのように相互作用するか、そして複雑さがどこに集中しているかを明らかにします。

コードベースの規模が大きくなるにつれて、コードの可視化の必要性も高まります。500行程度のスクリプトであれば、開発者は全体の構造を頭の中で把握できます。しかし、15個のマイクロサービスとレガシーメインフレームからなる50万行の分散システムでは、誰も全体像を把握することはできません。可視化によって、その構造が図として外部化され、システムの進化に合わせて共有、参照、更新できるようになります。

コードの視覚化は、異なるユーザー層に対してそれぞれ異なる効果を発揮する。

• 開発者向け フローチャートとコールグラフを使用して、実行ロジックを理解し、予期しない動作をデバッグし、リファクタリングを計画します。
• 建築家 依存関係グラフとコンポーネント図を使用して、構造的な健全性を評価し、移行計画を立てる。
• 品質保証エンジニア フローチャートと制御フロー図を使用して、すべての分岐を網羅するテストケースを設計する
• 運用チーム シーケンス図を使用してリクエストの流れを追跡し、パフォーマンスのボトルネックを特定する。
• 非技術系関係者 計画段階やコンプライアンスレビューの際に、簡略化されたフローチャートやコンポーネント図を使用してシステムの範囲を理解する。

図の種類とそれぞれの使用場面

視覚化の種類によって、答えられる質問は異なります。質問に対して不適切な図の種類を使用すると、結果が混乱を招きますが、適切な図の種類を使用すれば、すぐに明確な理解が得られます。

図の種類	最も適切な質問への回答	以下のためにベスト
フローチャート	このロジックでは、実行はどのように進むのでしょうか？	意思決定ロジック、デバッグ、オンボーディング
シーケンス図	コンポーネント間でどのようなメッセージが、どのような順序でやり取りされるのか？	APIとのやり取り、非同期フロー、デバッグ
クラス図	データ構造とその関係性について教えてください。	オブジェクト指向設計、リファクタリング、ドキュメント作成
依存関係グラフ	何が何に依存し、システムはどの程度密接に結合しているのか？	影響分析、リファクタリング、移行計画
状態図	システムはどのように状態間を遷移するのか？	プロトコルロジック、UIステートマシン、組み込みシステム
コンポーネント図	システムの構成要素はどのように組み立てられ、接続されているのですか？	アーキテクチャレビュー、オンボーディング、クラウド移行
コールグラフ	どの関数が他のどの関数を呼び出すのか？	デッドコード検出、パフォーマンスプロファイリング、影響分析
制御フロー グラフ	関数を実行する際に考えられるすべてのパスは何ですか？	テスト、複雑性分析、安全性が重要なレビュー

フローチャート：意思決定ロジックを可視化する

フローチャートは、プロセスやプログラムの実行の流れを表し、標準化された図形を用いて、分岐点、分岐、ループ、終端状態を示します。長方形はプロセス、ひし形は分岐点、平行四辺形は入出力、楕円は開始点と終了点を表します。

フローチャートは、人間が自然な思考プロセス（一連の処理）をどのように捉えるかに直接対応しているため、最も広く理解されている視覚化形式です。コードベースに不慣れな開発者が決済処理ロジックのフローチャートを読めば、コードを読むよりも早く理解できます。フローチャートを見たQAエンジニアは、4つの分岐があることを認識し、それらを網羅する4つのテストケースを設計できます。

プログラミングの文脈において、フローチャートが最も効果的なのは以下のケースです。

• 単一の関数またはプロシージャにおける分岐ロジックの説明
• コードを書く前にアルゴリズムを設計する
• コンプライアンスまたは監査目的で業務ルールを文書化する
• エラー発生時にどのパスが通ったかを追跡することでデバッグを行う。

シーケンス図：時間経過に伴う相互作用

シーケンス図は、オブジェクトやコンポーネントが時間順にどのように相互作用するかを示します。横軸は参加者（サービス、クラス、ユーザー）を表し、縦の矢印はそれらの間で時系列順に渡されるメッセージを示します。シーケンス図は、分散システム、マイクロサービス間の通信、およびAPIの動作を理解するための主要なツールです。

モノリシックアーキテクチャでは、シーケンス図によって、単一のリクエストがさまざまなレイヤーを通してメソッド呼び出しの連鎖をどのように引き起こすかが明らかになります。マイクロサービスアーキテクチャでは、どのサービスが他のサービスと、どのような順序で、そして各メッセージがどのようなデータを伝えるかが示されます。シーケンス図は、並列化可能なシーケンシャル呼び出しや、不要なデータベース往復を引き起こすN+1クエリパターンによって引き起こされるパフォーマンス問題を診断するための最も効果的なツールです。

依存関係グラフ：構造的健全性の概要

依存関係グラフは、コンポーネント、モジュール、パッケージ、クラス、サービス、またはファイル間の方向性のある関係を示します。AからBへの矢印は、AがBに依存していることを意味します。循環依存関係（AがBに依存し、BがAに依存する）は、グラフ上でサイクルとして表示され、すぐに視覚的に確認でき、すぐに対処できます。

依存関係グラフから以下のことが明らかになる。

• 高ファンインノード：他の多くのコンポーネントが依存しており、高リスクの単一障害点となる。
• 高ファンアウトノード：他の多くのコンポーネントに依存しており、単一責任の原則に違反する可能性がある
• 循環依存関係: 相互結合により独立したデプロイメントが妨げられ、リファクタリングが困難になる
• アーキテクチャレイヤー違反下位レベルのコンポーネントが上位レベルのコンポーネントに依存しており、設計のずれを示している。

の文脈で 依存関係グラフとアプリケーションリスク依存関係グラフが提供する構造的な洞察は、変更計画に直接役立ちます。コンポーネントを変更する前に、その依存関係グラフによって影響を受ける可能性のある範囲全体が明らかになります。

状態図：条件を横断する振る舞いの論理

状態図（または状態遷移図）は、システム、オブジェクト、またはプロトコルが取り得る異なる状態と、イベントや条件によってトリガーされるそれらの状態間の遷移を示します。状態図は、現在の動作が履歴コンテキスト、認証フロー、注文処理パイプライン、組み込みデバイスのファームウェア、ネットワークプロトコルの実装などに依存するあらゆるロジックにとって不可欠です。

状態図は、考えられるすべての現在の状態と考えられるすべての入力に対して「次に何が起こるか？」という問いに答えるため、動作の完全性を指定および検証するための最も正確なツールとなります。

コード可視化ツール：手動から自動化へ

図を作成する際の実際的な課題は、常に最新の状態に保つことです。1月に正確だった手描きの図も、3回の機能開発スプリントを経て3月には時代遅れになってしまいます。以下に紹介するツールは、手動で図を作成するツールから、ソースコードから直接図を生成するシステムまで多岐にわたります。

図をコードとして扱う：同期ソリューション

図の陳腐化に対する最も効果的な解決策は、図をコードとして表現することです。つまり、図をテキスト定義として表現し、ソースコードとともにバージョン管理システムに保存します。コードが変更されると、図の定義も同じコミットで変更されます。図は同じリポジトリに存在し、同じレビュープロセスを経るため、常に同期が保たれます。

Search Console のデータにあるクエリ群「コードと図の同期」「コードベースと図の同期」「リアルタイムのコードと図の一貫性」は、チームが従来の図作成ツールで直面する現実的な問題を反映しています。コードとしての図は、この問題を構造的に解決します。

マーメイド は、最も広く採用されているダイアグラム・アズ・コードツールであり、GitHub、GitLab、Notion、Obsidian、およびほとんどの最新のドキュメントプラットフォームでネイティブにサポートされています。

プラントUML 複雑なUML図のためのより豊富な構文を提供し、企業文書作成において広く利用されている。

@startuml
class OrderService {
  +createOrder(items: List<Item>): Order
  +cancelOrder(orderId: String): void
  -validatePayment(payment: Payment): Boolean
}

class Order {
  +id: String
  +status: OrderStatus
  +items: List<Item>
  +createdAt: DateTime
}

class PaymentService {
  +charge(amount: Decimal, card: Card): Transaction
  +refund(transactionId: String): void
}

OrderService --> Order: creates
OrderService --> PaymentService: delegates payment to
@enduml

D2 は、より読みやすい構文と自動レイアウトを備えた、より新しいダイアグラム・アズ・コード言語であり、複雑な依存関係グラフにおいて、Mermaidよりも大規模なダイアグラムをより適切に処理します。

API Gateway -> Auth Service: authenticate
API Gateway -> Order Service: route order request
Order Service -> Inventory Service: reserve stock
Order Service -> Payment Service: charge card
Order Service -> Notification Service: send confirmation
Payment Service -> Bank API: process transaction

Graphviz（DOT言語） 自動化パイプラインにおける依存関係グラフと呼び出し階層のための最適なツールです。

digraph dependencies {
  rankdir=LR;
  node [shape=box];
  "OrderController" -> "OrderService";
  "OrderService" -> "InventoryRepository";
  "OrderService" -> "PaymentGateway";
  "OrderService" -> "NotificationService";
  "InventoryRepository" -> "Database";
  "PaymentGateway" -> "StripeAPI";
}

自動コードから図への変換ツール

開発者が図の定義を記述する「図をコードとして記述する」方法以外にも、ソースコードを直接解析して図を自動的に生成するツールがいくつかあります。

ツール	それが生み出すもの	言語	統合
プラントUML	クラス、シーケンス、UML図	複数（注釈またはマニュアルより）	IntelliJ、VS Code、Maven
ソーストレイル	対話型依存関係グラフ、呼び出しグラフ	C、C ++、Java、Python	スタンドアロン版 + IDEプラグイン
CodeVisualizer (VS Code)	リアルタイムフローチャート、依存関係グラフ	Python、JS、TS、PHP	VSコード拡張機能
Doxygen + Graphviz	呼び出しグラフ、インクルードグラフ、クラス階層	C、C ++、Java	CI / CDパイプライン
py2cfg / pycallgraph	制御フローグラフ、呼び出しグラフ	Python	CLI / スクリプト
JavaParser + Graphviz	メソッド呼び出しグラフ、パッケージ依存関係	Java	ビルド ツールの統合
SMART TS XL	言語間依存関係マップ、呼び出しグラフ、フロー図	COBOL、JCL、Java、Python、RPG、.NET、SQL	エンタープライズ、メインフレーム

IDEとの統合：コーディング中の可視化

最新のIDE（統合開発環境）は、個別の図作成ツールの必要性を軽減する視覚化機能を備えている。

VSコード Rustアナライザー、Pylance、またはその他の言語サーバーを使用すると、呼び出し階層（右クリック → プレビュー → 呼び出し階層）が表示され、グラフをインポートできます。CodeVisualizer拡張機能は、Python、JavaScript、TypeScript、およびPHPの関数からリアルタイムのフローチャートを生成します。

IntelliJ IDEA / JetBrains IDE 組み込みの依存関係分析、選択したクラスまたはパッケージから生成される UML クラス図 (右クリック → 図 → 図の表示)、および呼び出し元と呼び出し先を再帰的に表示する呼び出し階層ビューを提供します。

Visual Studioの ビルド時にアーキテクチャ上の制約を適用するためのコードマップ（ソリューションの依存関係グラフ）、アーキテクチャ図、およびレイヤー図を提供します。

既存のコードから図を生成する

既存コードからリバースエンジニアリングによって図を作成することは、レガシーシステムやエンタープライズ環境において最も一般的なユースケースです。そのプロセスは、使用するプログラミング言語と必要な図の種類によって異なります。

コードからクラス図を生成する

Javaおよび.NETの場合、クラス図はソースコードから以下の方法で自動的に生成できます。

• IntelliJ IDEAの組み込みUMLジェネレーター（クラスを選択し、右クリック→ダイアグラム）
• IntelliJプラグインを使用したPlantUMLで、選択したクラスをPlantUML形式にエクスポートします。
• Python 用の Pyreverse (pylint の一部)： pyreverse -o png -p MyPackage mypackage/
• NClass for .NET: コンパイル済みアセンブリからクラス図を生成します

呼び出しグラフと依存関係グラフの生成

呼び出しグラフと依存関係グラフを作成するには、コードベースの静的解析が必要です。

# Python: generate call graph using pycallgraph
pip install pycallgraph2
pycallgraph2 graphviz -- python my_script.py

# Python: generate package dependency graph
pip install pydeps
pydeps my_package --max-bacon 4 --cluster

# Java: generate call graph with javacg
java -jar javacg.jar my_project.jar | python3 parse_cg.py

# COBOL/JCL/Legacy: use SMART TS XL for automatic cross-program dependency maps

コードからフローチャートを生成する

フローチャートの自動生成には、特定の機能の制御フローを解析する必要があります。

# Python: generate flowchart with code2flow
pip install code2flow
code2flow my_module.py --output my_flowchart.png

# C/C++: use Doxygen with CALL_GRAPH=YES in Doxyfile
CALL_GRAPH = YES
CALLER_GRAPH = YES
HAVE_DOT = YES

# Any language: CodeVisualizer VS Code extension
# Right-click any function → Visualize Function Flow

コードと図の同期：図を常に最新の状態に保つ

コード可視化における最も一般的な失敗例は、作成された図が時代遅れになってしまうことです。チームは1月に美しいアーキテクチャ図を作成しますが、コードベースは3回のフィーチャースプリントを経て変更され、4月にはその図はもはや存在しないシステムを記述していることになります。開発者は図を信頼しなくなり、図は誤解を招く成果物として蓄積されていきます。

これを防ぐための3つの戦略：

戦略1：図をコードとしてバージョン管理システムに組み込む。 Mermaid、PlantUML、またはD2の図定義を、それらが記述するコードと同じリポジトリに保存します。コードを変更するすべてのプルリクエストには、対応する図の更新を含めることができます。コードレビュー担当者は、両方の変更をまとめて検証できます。CIパイプラインは、図をレンダリングしてプルリクエストに自動的に添付できます。

戦略2：CI/CDにおける図の自動生成。 ビルドパイプラインを構成して、メインブランチへのマージのたびに、ソースコードから依存関係グラフと呼び出しグラフを再生成します。生成された図はビルド成果物として保存します。「現在のアーキテクチャ」図は常に最新のビルドの出力であり、手動で管理されるファイルではありません。

戦略3：視覚化機能を統合したIDE。 開発中に使用される開発者向けの図については、現在のソースからオンデマンドで図を生成するIDEプラグインを使用することで、同期の問題を完全に解消できます。図は毎回新たに生成されるため、常に最新の状態を保つことができます。

戦略1と戦略2の組み合わせは、チームのドキュメント作成において最も効果的です。つまり、アーキテクチャの意図を示す手書きの図（コードレビューによって常に最新の状態に保たれる）と、構造上の真実を示す自動生成の図（CI自動化によって常に最新の状態に保たれる）を組み合わせるということです。

レガシーシステムにおける複雑なコード依存関係の可視化

レガシーコードベースは、最も困難な可視化問題と、最も緊急な可視化ニーズを抱えています。40年分のCOBOL、JCL、コピーブック、組み込みSQLが蓄積されたメインフレームアプリケーションには、現存するチームメンバーでさえ完全に理解できない依存関係構造が含まれています。ドキュメントが存在するとしても、それは既に原型をとどめないほど変化したシステム向けに書かれたものです。

レガシーシステムの自動依存関係分析には、関連する言語を理解するツールが必要です。Java または Python 用に設計された標準的な可視化ツールは、COBOL を解析できず、JCL ジョブ ストリームの呼び出しパターンを理解できず、COBOL プログラムと、それが書き込む DB2 テーブル、およびそのテーブルから読み取る Java サービスを接続する言語間の接続を追跡できません。 データと制御フローの分析多言語システムにおけるデータの流れを構造的に理解するには、各言語を解析し、それらの間の関連性を統一モデルで解決する必要がある。

従来型環境における具体的な可視化ニーズは、最新システムとは異なります。

• プログラム呼び出しグラフ COBOLプログラムがCALL、PERFORM、LINKを使用して他のどのプログラムを呼び出しているかを示します。
• JCLジョブストリーム図 ステップの実行順序、それらが呼び出すプログラム、およびそれらの間を流れるデータセットを示します。
• 言語間依存関係マップ コピーブックのフィールド定義がDB2列に接続され、それがJavaサービスオブジェクトのフィールドに接続され、さらにそれがREST APIレスポンスに接続される様子を示します。
• 衝撃図 任意の開始コンポーネントから生成され、そのコンポーネントが変更された場合に影響を受けるものを示します。

これらの図は、安全な近代化の基盤となります。コンポーネントをクラウドに移行したり、新しい言語に変換したりする前に、チームはそれが何に接続され、何に依存しているかを把握する必要があります。視覚化がなければ、その知識を得るためにはソースコードから手動で再構築する必要があり、数週間かかる上に不完全な結果しか得られません。

問題に適した図の選択

コードの可視化において最もよくある間違いは、質問内容に対して不適切な種類の図を作成してしまうこと、あるいは抽象度が不適切なレベルの図を作成してしまうことです。以下の意思決定ガイドでは、一般的なエンジニアリング上の質問を最も効果的な図の種類に対応付けています。

工学に関する質問	最適な図の種類	ツール
この機能はどのように機能しますか?	フローチャート	Mermaid、CodeVisualizer、code2flow
この関数を呼び出すのは何ですか？	コールグラフ	Sourcetrail、IDE呼び出し階層、 SMART TS XL
これらのサービスはどのように通信するのですか？	シーケンス図	人魚、PlantUML
このコンポーネントは何に依存しているのでしょうか？	依存関係グラフ	Graphviz、D2、 SMART TS XL
このシステムはどのような状態になり得るか？	状態図	人魚、PlantUML
システムはどのように構成されていますか？	コンポーネント図	PlantUML、Lucidchart、draw.io
この変更はどのような影響をもたらすでしょうか？	インパクト図	SMART TS XL
複雑さはどこに集中しているのか？	依存関係グラフにヒートマップを重ねて表示	コードシーン、 SMART TS XL
これらの授業はどのように関連しているのでしょうか？	クラス図	IntelliJ、Pyreverse、PlantUML

もう一つのよくある間違いは、可視化を継続的な実践ではなく、一度限りの活動として捉えてしまうことです。移行プロジェクト開始前に一度生成され、その後更新されない依存関係グラフは、移行をサポートするものではありません。それは、生成された時点のシステムの状態しか反映しないからです。コードから自動的に生成され、バージョン管理システムに保存され、必要に応じて再生成される図こそが、時代遅れの参照資料となることなく、エンジニアリングプログラム全体を通して有用な情報を提供し続ける図なのです。

視覚化は、ワークフローに統合された場合に最も効果を発揮します。例えば、コードレビュー中に生成して新しい依存関係が意図的なものであることを検証したり、インシデント対応中にクエリを実行して障害の経路を追跡したり、アーキテクチャセッションで使用して、システムの構成方法に関する仮定ではなく、システムの実際の構造に基づいて戦略的な議論を行ったりすることができます。