JIG(Java の設計可視化ツール)

調査時点: 2026-06。バージョン番号はこの時点のもの。

概要#

リポジトリの説明は「Java でのコードによる設計を可視化によって支援するツール」。かつて “Java Instant-document Gazer” の略称も使われた
GitHub 組織は dddjava、ライセンスは Apache 2.0。主要コミッターは irof(川上精二)、思想面の中心は増田亨
最新版は 2026.6.2(2026-06-11)。Gradle / Maven プラグインで導入し、図の描画に Graphviz が別途要る
JIG の実行には Java 21 以上が必要。解析対象のプロダクトは Java 8 以上でよい

生成するドキュメント#

build/jig/index.html に 9 種類を出力する。

列挙値	ラベル	内容
`Glossary`	用語集	クラス名・パッケージ名を業務用語として一覧化
`PackageRelation`	パッケージ関連	パッケージ間の依存図。相互参照は赤線で警告
`DomainModel`	ドメインモデル	ドメイン層クラスの関連図
`Usecase`	ユースケース	アプリケーション層のサービスメソッド呼び出し一覧
`InboundInterface`	入力インタフェース	コントローラなどの入り口
`OutboundInterface`	出力インタフェース	Repository などの出口
`Insight`	インサイト	設計の洞察・分析情報
`ListOutput`	一覧出力	クラス・メソッドのリスト
`LibraryDependency`	ライブラリ依存情報	依存ライブラリ

旧版には BusinessRuleList・CategoryDiagram・ArchitectureDiagram などの名称もあり、版で変動する。

解析方式と対応言語#

ソースではなくバイトコード(.class)を解析する。コンパイル済みクラスファイルが必要
バイトコードは共通フォーマットなので JVM 言語全般で動く。Scala のチュートリアル(sbt-jig-tutorial)があり、Kotlin も同じ原理で動くとみられるが公式の明記はない

導入(Gradle)#

1
plugins {
2
  id "org.dddjava.jig-gradle-plugin" version "2026.6.2"
3
}

1
./gradlew clean build jig

jig {} ブロックの設定: modelPattern(解析対象パッケージのフィルタ)、documentTypes / documentTypesExclude(出力種類の限定)、outputDirectory。古いクラスファイルによる誤出力を防ぐため、クリーンビルドとの順序に気を付ける。

なぜ「全コード精読」の代替になるか#

「意図を埋め込んでコードを書き、意図が表現されたドキュメントを見る」という、ドキュメント → コードではなくコード → ドキュメントの方向。前提アーキテクチャは Isolating the Domain(presentation / application / infrastructure / domain の層構造)。設計の意図がクラス名・パッケージ名(業務語彙、ユビキタス言語)に体現されていれば、それを集約するだけで設計の全体像と歪み(不正な依存方向の赤線)が現れる。

効果が出る条件・出ない条件#

効果が出やすいのは、Isolating the Domain 準拠の層構造、業務語彙での命名、意味ある粒度のパッケージ分割がそろっているコードベース。

効果が出にくいのは次の場合。

フラットなパッケージ構成(全クラスを 1〜2 パッケージに集約)。関連図が空か無意味になる
クラス名・メソッド名が業務語彙から離れている。Glossary が機能しない
CI の Java が 21 未満、または Graphviz を置けない
アーキテクチャから逸脱した作り(想定外の構造)は可視化されにくい

JIG は「ツールを入れれば可視化される」のではなく「その流儀で書いているから可視化が効く」という順序依存が強い。導入を検討するなら、コードベースが層構造と業務語彙命名になっているかを先に見る。

Glossary の仕組み#

Glossary.java は Collection<Term> を単純にソートして列挙する。Term は識別子・Javadoc の 1 文目・種別からなる。LLM・NLP・embedding は使わず、純粋な静的解析で、規律ある命名と Javadoc に全面的に依存する。命名の揺れを検出・補正する機能は持たない。

要素分解と TypeScript での対応ツール#

JIG をソースから機能要素に分解すると、入力・解析層が 2 つ、出力・ドキュメント層が 9 つになる。TypeScript で同じことをするときに既存ツールで埋まる要素と空白の要素を分けた(2026-06 時点)。

要素	JIG での担当	TypeScript の主要ツール	成熟度
A1. 構造解析(型・メソッド・フィールド・継承・参照)	ASM によるバイトコード解析	TypeScript Compiler API、ts-morph	mature
A2. doc コメント抽出	JavaParser による Javadoc 抽出	@microsoft/tsdoc、TypeDoc 内部	mature
B1. 用語集	Glossary	専用なし。TypeDoc が最も近い	none
B2. モジュール依存図と循環検出	PackageRelation	dependency-cruiser、madge	mature
B3. クラス関連図	DomainModel	TsUML2(v0.17.1、2024-12)、tplant	partial
B4. サービスメソッド(ユースケース)一覧	Usecase	汎用なし。NestJS 限定で swagger 経由	none
B5. 入出力境界の列挙	Inbound / OutboundInterface	@nestjs/swagger、Nestia(NestJS 限定)	partial
B6. メソッド呼び出しグラフ	call hierarchy	Jelly(研究グレード)、TypeScript-Call-Graph(2020 で停止)	none(実用品質)
B7. レイヤ分類と依存方向違反の検出	層判定	eslint-plugin-boundaries、ArchUnitTS、ts-arch	mature
B8. 外部ライブラリ依存	LibraryDependency	Knip(depcheck / ts-prune はアーカイブ済み)	mature
B9. コードメトリクス・一覧	Insight / ListOutput	ESLint complexity、ts-complex、Knip(個別)	partial

空白は B1(用語集のキュレーション)、B4(ユースケース列挙)、B6(実用品質のコールグラフ)の 3 つ。B1 の「概念で束ねる」部分は LLM に向くので命名からドメイン用語集を生成するに、B6 は TypeScript コールグラフの静的抽出に分けた。A1 / A2 は ts-morph + tsdoc で完結するので、新しいツールはその上に乗せる。

更新履歴#

2026-06-19: 初版（ローカル調査ノート）
2026-10-17: Wiki へ移植、概念ページとして再構成。要素分解と TypeScript 対応ツールの表を追加