クラス関連図・Call Graph・Jarviz 3Dマップと積み上げてきた3段階のアプローチを、ここで一度まとめて振り返ります。JSONLという共通フォーマットが言語の壁を越える鍵になっていたことに、書きながら改めて気づかされました。

3段階の可視化アプローチ整理

Javaコード可視化3段階アプローチ図

図1: Javaコード可視化 — クラス関連図・コールグラフ・Jarviz 3Dの3段階アプローチ

段階視点ツール・手法得られる情報主なユースケース
① 構造 Class関連図 ASM / JavaParser
PlantUML / Mermaid		 継承・実装・集約・依存の関係構造 設計レビュー・DIP確認・レガシー解析
② 振る舞い Method Call Graph ASM（静的）
Java Agent（動的）		 誰がどのメソッドを呼ぶか デバッグ・影響範囲分析・テスト設計
③ 俯瞰 Jarviz 3Dマップ jarviz-lib + jarviz-graph システム全体のホットスポット・クラスタ構造 アーキテクチャ評価・マイクロサービス化設計

3段階は排他的ではなく、実際には組み合わせて使う。 「3Dマップでホットスポットを発見 → Call Graph で呼び出し経路を追う → Class図で設計を確認」 というボトムアップの分析が特に有効だ。

JSONLフォーマットの汎用性が持つ意味

このシリーズで最も重要な発見は Jarviz の3Dマップは JSONL の可視化エンジンであるという事実だ。

JSONL — 1行で1つの依存関係を表すシンプルなフォーマット 
{"appSetName":"System","appName":"service-A","sourceClass":"...","sourceMethod":"...","targetClass":"...","targetMethod":"..."}

6フィールドのこのフォーマットさえ生成できれば、 Java・Python・Kotlin・TypeScript・Go ——どの言語のコードも同じ3Dマップで俯瞰できる。 さらに appName を使えば異なる言語で書かれたマイクロサービスを 一つのマップに統合することも可能だ。

💡 マルチ言語マイクロサービスの統合可視化

Java の order-service、Python の analytics-service、 Kotlin の notification-service の JSONL を1ファイルに結合して jarviz-graph に渡すと、言語の壁を超えたシステム全体の依存マップが生成される。 これは既存のIDEツールでは難しい視点だ。

可視化実践でよくある落とし穴

落とし穴症状対処
リフレクション呼び出しを見逃す Call Graphで辺が途切れ、実際の依存関係が欠落する 動的解析（Java Agentトレース）と組み合わせてカバレッジを補完する
JARのスコープを広げすぎる JDK・フレームワーク内部の辺が大量に出て3Dマップが読めない 解析対象を自プロジェクトのパッケージプレフィックスに絞り込む
appNameを全サービスで同一にする マイクロサービス間の依存が区別できず、3Dマップ上で1つの塊になる サービス単位でappNameを変え、JSONL結合後に色分け表示する
静的解析だけで完結と思い込む 実行時にのみ生成されるProxyクラスのコールが可視化されない 静的解析は「設計の骨格」把握用と割り切り、実行パス検証は動的解析に委ねる

シリーズ習得チェックリスト

  • Javaクラス間の5種類の関係（継承・実装・コンポジション・集約・依存）を説明できる
  • ASM を使って JAR からクラス関係を抽出するコードを書ける
  • JavaParser を使ってソースコードからコンポジションと集約を区別して抽出できる
  • INVOKE系バイトコード命令（invokevirtual・invokeinterface 等）の違いを説明できる
  • ASM の MethodVisitor を使って Call Graph を生成できる
  • 静的解析と動的解析のトレードオフを理解し、使い分けられる
  • CallEdge を JSONL 形式で出力するコードを書ける
  • Jarviz の JSONL フォーマットの6フィールドの意味を説明できる
  • Python（ast）または他言語で JSONL を生成して3Dマップを表示できる
  • 3Dマップからホットスポット・孤立ノード・モジュール間依存を読み取れる

次のステップ

🔄
動的解析との統合
Java Agent のトレースログを JSONL に変換し、静的解析の結果とマージして精度を高める
📊
CI/CD への組み込み
ビルドパイプラインで自動的に JSONL を生成し、アーキテクチャの劣化を継続的に監視する
🌐
他言語への展開
TypeScript（ts-morph）・Kotlin（Compiler API）・Go（go/ast）で JSONL 生成スクリプトを実装する
🗄️
グラフDBへの投入
JSONL を Neo4j / Amazon Neptune に投入し、Cypher クエリで高度な依存分析を行う
🤖
AI との組み合わせ
抽出した依存グラフを LLM に渡し、リファクタリング提案や設計問題の自動検出を試みる

✅ シリーズを振り返って

PART 01 から PART 06 まで、「コードを眺める」から「コードを可視化する」へのアプローチを体系的に解説した。 中でも JSONL フォーマットという共通言語を使うことで、 特定の言語やツールに縛られない汎用的な可視化基盤が作れるという発見は、 多言語が混在するモダンなシステム開発において特に価値があると考えている。 ぜひ手元のプロジェクトで試してみてほしい。