読了時間:12 minutes

あなたのコードベースは大きくなっています。モジュール間の依存関係が増えていきます。アーキテクチャのドキュメントは、書かれる前に古くなってしまいます。あなたのGradleビルドが 自動的に 実際のコード構造から最新の図を生成できたらどうでしょうか?これはまさに、Graphify + PlantUML Gradle プラグイン パイプラインが行うことです:graphify . --no-viz`Knowledge Graph を抽出する./gradlew generateKnowledgeGraphDiagram`これをPlantUML図に変換します。ゼロLLM、ゼロ手動、100%決定的。

目次

[]

問題:コードに常に遅れを取る図表

数千行を超えるプロジェクトはこの症候群に直面します:

  1. プロジェクトの始めにアーキテクチャ図を描きます

  2. コードが進化し、依存関係が変わる

  3. �図は装飾的な嘘になる

  4. 誰もそれをアップデートしない、なぜならそれは面倒だから。

  5. 新参者はそれに基づいて判断し、間違いを犯す

@startuml
skinparam backgroundColor #FEFEFE
skinparam ActivityBackgroundColor #FDEDEC
skinparam ActivityDiamondBackgroundColor #FFF3CD

start

:Diagramme d'architecture créé\n(manuellement, à la main);

:Le code évolue\n(nouvelles classes, nouvelles dépendances);

:Diagramme obsolète\n(ne reflète plus le code);

if (Qui met à jour ?) then (Personne)
    :Documentation mensongère;
    note right: Les nouveaux développeurs\nse basent dessus... et font des erreurs
else (Quelqu'un)
    :Mise à jour manuelle\n(2-3 heures de travail);
    note right: Déjà obsolète\nà la prochaine PR
endif

stop

@enduml

質問は、図が必要か? ではない — みんなそれが必要だと知っている。質問は:誰がそれらを最新の状態に保っているのですか?

答え:誰も。ただし自動の場合を除く。

解決策:決定論的なKnowledge Graph → PlantUMLパイプライン

原理はシンプルです:手で図を描く代わりに、それを実際のコード構造から生成される。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

actor Développeur
component "Graphify
(pip install graphifyy)" as Graphify
collections "graphify-out/graph.json
(ナレッジグラフ)" as KGJSON
component "PlantUML Gradle プラグイン\n(generateKnowledgeGraphDiagram)" as Plugin
component "KnowledgeGraphParser" as Parser
component "KnowledgeGraphRenderer" as Renderer
component "PlantumlService\n(検証 + PNGレンダリング)" as PS
collections "diagrams/knowledge-graph/\n(.puml + .png)" as Output

Développeur --> Graphify : graphify . --no-viz
Graphify --> KGJSON : extrait la structure\ndu code source
Développeur --> Plugin : ./gradlew generateKnowledgeGraphDiagram
Plugin --> Parser : parse(graph.json)
Parser --> Plugin : KnowledgeGraph\n(noeuds + arêtes + communautés)
Plugin --> Renderer : render(graph, filters)
Renderer --> Plugin : code PlantUML\ndéterministe
Plugin --> PS : validateSyntax + generateImage
PS --> Output : .puml + .png

note bottom of Plugin
  Pipeline DÉTERMINISTE
  Aucun appel LLM
  Résultat reproductible
end note

@enduml

2つのコマンド。それだけです。

# Étape 1 : extraire le Knowledge Graph
graphify . --no-viz

# Étape 2 : générer les diagrammes PlantUML
./gradlew generateKnowledgeGraphDiagram

結果? ファイル`.puml` et .png`中`diagrams/knowledge-graph/, Git でバージョン管理され, 常にコードと最新の状態を保つ。

ステップ 1: Graphifyをインストールし、ナレッジグラフを抽出する

インストール

Graphifyはあなたのコードベースを分析し、構造化されたナレッジグラフを構築するPythonツール:

# Méthode recommandée
uv tool install graphifyy && graphify install --platform opencode

# Alternative avec pip
pip install graphifyy && graphify install --platform opencode

除外を設定する

ファイルを作成`.graphifyignore`プロジェクトのルートに置き、ビジネスロジックに属していないファイルを除外します:

# Secrets — JAMAIS dans le graphe
*-context.yml
*.env

# Fichiers générés
build/
.gradle/

# Tests fonctionnels
src/functionalTest/

Knowledge Graphを�抽出する

graphify . --no-viz

フラグ`--no-viz`HTMLの生成をスキップします (Gradleパイプラインでは不要です)。 結果はファイルです。`graphify-out/graph.json`含む :

  • 結び目:クラス、関数、ファイル―そのタイプとコミュニティとともに

  • エッジノード間の関係 (EXTRACTED はコードから、INFERRED は LLMによって)

  • コミュニティ: 自動的にグループ化されたリンクされたノード

構造の例`graph.json`
{
  "nodes": [
    {"id": "0", "label": "LlmService", "file_type": "code", "community": 0},
    {"id": "1", "label": "ApiKeyPool", "file_type": "code", "community": 0},
    {"id": "2", "label": "PlantumlService", "file_type": "code", "community": 1}
  ],
  "links": [
    {"source": "1", "target": "0", "relation": "uses", "confidence": "EXTRACTED", "weight": 0.9},
    {"source": "0", "target": "2", "relation": "calls", "confidence": "INFERRED", "weight": 0.7}
  ]
}

ソースコード (.kt, .java) は tree-sitter によってローカルで分析されます,�異議なしのLLM. ドキュメントファイルのみ (.adoc, .md) LLMを呼び出して意味的抽出を行う必要があります。 それで`--update`Kotlin コードではほぼ瞬時に実行されます。

ステップ 2:GradleプラグインがKnowledge GraphをPlantUMLに変換します

パイプラインアーキテクチャ

プラグイン`com.cheroliv.plantuml`タスクを組み込む`generateKnowledgeGraphDiagram`変換する`graph.json`PlantUML図の形で完全に決定論的:

@startuml
skinparam backgroundColor #FEFEFE

participant "Gradle" as G
participant "知識グラフダイアグラム生成タスク" as Task
participant "KnowledgeGraphParser" as Parser
participant "ナレッジグラフレンダラー" as Renderer
participant "Plantumlサービス" as PS

collections "graphify-out/graph.json" as JSON

G -> Task : execute
Task -> JSON : read
Task -> Parser : parse(graph.json)
Parser --> Task : KnowledgeGraph\n(noeuds + arêtes + communautés)
Task -> Renderer : render(graph, filters)
Renderer --> Task : code PlantUML\n(déterministe)
Task -> PS : validateSyntax(plantumlCode)
alt syntaxe valide
    Task -> PS : generateImage → .png
else syntaxe invalide
    Task -> Task : save .puml avec warning
end

@enduml

内部コンポーネント

コンポーネント 役割

KnowledgeGraphParser

解析`graph.json`サポート 3 フォーマット : ネイティブ graphify (nodes+links), レガシー (communities), flat. 数値 ID をラベルに解決します。

KnowledgeGraphRenderer

決定的に変換する一つ`KnowledgeGraph`PlantUML コード。タイプ別にグループ、パッケージにコミュニティ、自動凡例。

GenerateKnowledgeGraphDiagramTask

Gradleタスクは、parse → render → validate → PNGをオーケストレーションします。Gradleプロパティ経由で設定可能。

kgmodels.kt

データモデル:KnowledgeGraph, KnowledgeGraphNode, KnowledgeGraphEdge, KnowledgeGraphCommunity, EdgeType。

PlantumlService

構文検証 + PNGレンダリング(プラグインのすべてのタスクで再利用)

レンダリングルール

レンダラーは決定論的な視覚的慣習を適用します:

エッジのタイプ PlantUML記法 意味

�抽出された

-→(実線, 黒)

ソースコードから抽出された関係 (確実性)

推論された

..>(点線)

LLMによって推論された関係 (信頼スコア)

あいまいな

--x(赤い点線)

�曖昧な関係 (確認が必要)

コミュニティは、自動色パレットを持つ PlantUML パッケージとしてレンダリングされます。

ステップ3:日常での使用

完全図

# Générer le diagramme du Knowledge Graph complet
./gradlew generateKnowledgeGraphDiagram

出力:diagrams/knowledge-graph/knowledge-graph-full.puml(空).png

コミュニティで絞り込む

# Une seule communauté
./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.community=community_0

# Limiter le nombre de noeuds (lisibilité)
./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.community=community_0 \
  -Pplantuml.kg.maxNodes=15

エッジの種類でフィルタリング

# Uniquement les relations certaines (EXTRACTED)
./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.edgeTypes=EXTRACTED

# Relations certaines + inférées
./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.edgeTypes=EXTRACTED,INFERRED

ノードの種類と信頼度でフィルター

# Uniquement les classes de code
./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.nodeTypes=code

# Seuil de confiance minimum (pour les INFERRED)
./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.minConfidence=0.7

カスタム出力ディレクトリ

./gradlew generateKnowledgeGraphDiagram \
  -Pplantuml.kg.outputDir=docs/architecture

プロパティの完全な参照

所有権 デフォルト 説明

plantuml.kg.community

(すべて)

名前でコミュニティをフィルタリング(部分一致)

plantuml.kg.edgeTypes

(皆)

カンマで区切られたエッジの種類:EXTRACTED, INFERRED, AMBIGUOUS

plantuml.kg.minConfidence

0.0

エッジの最小信頼しきい値

plantuml.kg.maxNodes

(無制限)

表示する最大ノード数

plantuml.kg.nodeTypes

(すべて)

ノードの種類、カンマで区切られた(例`class`, code)

plantuml.kg.outputDir

diagrams/knowledge-graph

ファイルの出力ディレクトリ`.puml` et .png

Gradle ワークフローにおける完全なパイプライン

ワークフローのタイプ

@startuml
skinparam backgroundColor #FEFEFE
skinparam ActivityBackgroundColor #E8F4FD
skinparam ActivityDiamondBackgroundColor #FFF3CD
skinparam ActivityBorderColor #2C3E50

start

partition "抽出" {
    :graphify . --no-viz;
    note right: Analyse le code source\ntree-sitter (local, pas de LLM)

    :graphify-out/graph.json;
    note right: Noeuds + arêtes\n+ communautés
}

partition "世代" {
    :./gradlew generateKnowledgeGraphDiagram;
    note right: Pipeline déterministe\nparse → render → validate → PNG

    if (Filtres actifs ?) then (Oui)
        :Appliquer filtres\n(community, edgeTypes,\nmaxNodes, nodeTypes);
    else (Non)
        :Diagramme complet;
    endif

    :diagrams/knowledge-graph/\nknowledge-graph-full.puml\nknowledge-graph-full.png;
}

partition "統合" {
    :git add diagrams/knowledge-graph/;
    :git commit;
    note right: Diagrammes versionnés\ntoujours à jour avec le code
}

stop

@enduml

開発サイクルへの統合

パイプラインは開発の重要な段階に自然に統合されます:

@startuml
skinparam backgroundColor #FEFEFE

state "開発" as dev
state "�抽出
graphify . --no-viz" as extract
state "生成\n./gradlew generateKnowledgeGraphDiagram" as generate
state "コミット
バージョン管理されたダイアグラム" as commit

[*] --> dev
dev --> extract : Code modifié
extract --> generate : graph.json à jour
generate --> commit : .puml + .png générés
commit --> dev : Diagrammes dans le repo

note right of extract
  Quasi instantané sur du code Kotlin
  (tree-sitter, pas de LLM)
end note

note right of generate
  Déterministe
  Pas de LLM
  Résultat reproductible
end note

@enduml

インクリメンタルアップデート

コードが変更されたとき、ゼロからグラフ全体を再構築するわけではありません:

# Mise à jour incrémentale (fichiers modifiés uniquement)
graphify . --update

# Puis régénérer les diagrammes
./gradlew generateKnowledgeGraphDiagram

--update`再抽出のみ 変更されたファイル (SHA256で検出された`graphify-out/cache/) Kotlin のコードでは、tree-sitter がローカルで動作し LLM を呼び出さないため、ほぼ瞬時に動作します。

ドッグフィーディング : プラグインは自身をドキュメント化する

PlantUML プラグインは、プロンプトをダイアグラムに変換するために存在します。また、自分の propre コードベースの Knowledge Graph もドキュメント用ダイアグラムに変換できます。これは dogfooding です:プラグインは自分のサービスを利用します。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "標準パイプライン
(ユーザー → ダイアグラム)" as normal {
    [Fichier .prompt] as prompt
    [LlmService\n+ ApiKeyPool] as llm1
    [ProcessPlantumlPromptsTask] as task1
    [Diagramme PNG] as out1

    prompt --> task1
    task1 --> llm1
    llm1 --> out1
}

package "Pipeline Knowledge Graph\n(決定論的、LLMを使用しない)" as kg {
    [graphify-out/graph.json] as kgjson
    [KnowledgeGraphParser] as parser
    [KnowledgeGraphRenderer] as renderer
    [PlantumlService] as ps
    [Diagramme PNG\n(documentation du plugin)] as out2

    kgjson --> parser
    parser --> renderer
    renderer --> ps
    ps --> out2
}

package "パイプライン ドッグフーディング
(LLM → プラグインのドキュメント)" as dogfood {
    [GraphifyPromptAdapter] as gpa
    [Fichiers .prompt\nauto-générés] as auto_prompt
    [LlmService\n+ ApiKeyPool] as llm2
    [ProcessPlantumlPromptsTask] as task2
    [Diagramme PNG\n(documentation LLM)] as out3

    kgjson --> gpa
    gpa --> auto_prompt
    auto_prompt --> task2
    task2 --> llm2
    llm2 --> out3
}

note "同じ LlmService、同じ ApiKeyPool、
同じ PlantumlService
— 複製ゼロ" as N

@enduml

関連付けられた Gradle タスク :

タスク LLM ? 説明

generateKnowledgeGraphDiagram

いいえ

変換`graph.json`PlantUML (決定的)で

generateDiagramDocs

はい

生成する`.prompt`グラフから、LLM(dogfooding)を使って処理しています。

# Documentation déterministe (rapide, pas de LLM)
./gradlew generateKnowledgeGraphDiagram

# Documentation LLM (plus riche, consomme des tokens)
./gradlew generateDiagramDocs

なぜそれが決定的なのか(そしてなぜそれが重要なのか)

パイプラインの重要なポイント`generateKnowledgeGraphDiagram` : 彼はどのLLMも呼び出さない. 変換`graph.json`→ PlantUML は純粋関数です。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

rectangle "決定的パイプライン
(generateKnowledgeGraphDiagram)" as det {
    [graph.json] as json
    [KnowledgeGraphParser] as parser
    [KnowledgeGraphRenderer] as renderer
    [PlantUML code] as puml

    json --> parser : parse
    parser --> renderer : KnowledgeGraph
    renderer --> puml : render (fonction pure)
}

rectangle "パイプライン LLM
(processPlantumlPrompts)" as llm {
    [.prompt] as prompt
    [LlmService] as llmSvc
    [ChatModel] as model
    [PlantUML code] as puml2

    prompt --> llmSvc
    llmSvc --> model : API call
    model --> puml2 : réponse non-déterministe
}

note bottom of det
  Même entrée → même sortie
  Pas de latence réseau
  Pas de coût en tokens
  Reproductible en CI
end note

note bottom of llm
  Même entrée → sortie variable
  Latence réseau (1-5s)
  Coût en tokens
  Nécessite une clave API
end note

@enduml

具体的な利点:

利点 インパクト

再現性

同じ`graph.json`→ 同じ図。正確です。毎回。

ゼロコスト

LLMの呼び出しなし = トークンなし = API請求なし

ゼロレイテンシー

Parse + render は~100msかかり、1〜5秒ではありません。

CI対応

APIキーは必要ありません。変動するLLMの応答によるフレークなテストは発生しません。

バージョン可能

Le .puml`テキストは生成される。私たちそれをできる`diff, PRのレビュアー, Gitでバージョン管理する。

パイプライン自身の図

ループを閉じるために、プラグインによって生成されるパイプラインの図を以下に示します:

@startuml
skinparam backgroundColor #FEFEFE

participant "開発者" as Dev
participant "グラドル" as G
participant "知識グラフ図を生成するタスク" as Task
participant "KnowledgeGraphParser" as Parser
participant "ナレッジグラフレンダラー" as Renderer
participant "PlantUMLサービス" as PS
collections "graphify-out/graph.json" as JSON
collections "diagrams/knowledge-graph/" as Out

Dev -> G : ./gradlew generateKnowledgeGraphDiagram
G -> Task : execute
Task -> JSON : read
Task -> Parser : parse(graph.json)
Parser --> Task : KnowledgeGraph

alt filtres actifs
    Task -> Task : appliquer filtres\n(community, edgeTypes, maxNodes…)
end

Task -> Renderer : render(graph, filters)
Renderer --> Task : code PlantUML

Task -> PS : validateSyntax()
alt valide
    Task -> PS : generateImage()
    PS --> Out : .puml + .png
else invalide
    Task -> Out : .puml (avec warning)
end

@enduml

プロジェクトガバナンスへの統合

私たちのプロジェクトでは、このパイプラインはAIエージェントのためのEAGER/LAZYコンテキスト管理戦略に組み込まれます。ナレッジグラフは、手動のアーキテクチャドキュメントに代わり、構造化され、クエリ可能で、自動的に更新されるグラフを提供します。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

package "EAGER
(常に充電されている)" as eager {
    [PROMPT_REPRISE.adoc\n(contexte session)] as pr
    [INDEX.adoc\n(vue d'ensemble)] as idx
    [GRAPH_REPORT.adoc\n(~50 lignes)] as gr
}

package "LAZY — 戦略
(要請による)" as lazy_strat {
    [Méthodologies] as meth
    [Archives sessions] as sessions
}

package "LAZY — Graphify
(ターゲットクエリ)" as lazy_graph {
    [graph.json] as gj
    [Queries\n(query/path/explain)] as queries
}

package "Pipeline PlantUML
(自動生成された)" as puml {
    [generateKnowledgeGraphDiagram] as kgTask
    [generateDiagramDocs] as ddTask
    [Diagrammes PNG] as diagrams
}

Agent --> eager : Lit en début de session
Agent ..> lazy_strat : Charge si type détecté
Agent ..> lazy_graph : Query si besoin structurel
kgTask --> diagrams : Déterministe
ddTask --> diagrams : Via LLM

note right of gr
  Condensé du Knowledge Graph
  God nodes + communautés
  Remplace ECOSYSTEM_OVERVIEW
  (225 lignes → 50 lignes)
end note

@enduml

二つのシステムの結びつきは補完的である:

  • 戦略は「いつ」と「どのように」を管理する— ガバナンス, ワークフロー, アーカイブ

  • GraphifyはQUOIとOÙを管理しますコード構造, 関係, ターゲット絞り込みクエリ

_ セッション戦略はを管理しますいつ et le どう(ガバナンス, ワークフロー, しきい値), Graphifyは管理します何? et le どこ(コードの構造、関係、ターゲットクエリ). PlantUMLパイプラインは管理します何で(決定論的でバージョン管理され、常に最新の図) _

設定 : 5分間のチェックリスト

# ステップ 注文

1

Graphifyをインストール

uv tool install graphifyy

2

除外を設定

作成する`.graphifyignore`

3

Knowledge Graphを抽出する

graphify . --no-viz

4

図を生成する

./gradlew generateKnowledgeGraphDiagram

5

結果をコミットする

git add diagrams/knowledge-graph/

# Script complet en 5 commandes
uv tool install graphifyy
cat > .graphifyignore << 'EOF'
*-context.yml
*.env
build/
.gradle/
EOF
graphify . --no-viz
./gradlew generateKnowledgeGraphDiagram
git add graphify-out/GRAPH_REPORT.adoc graphify-out/graph.json diagrams/knowledge-graph/

落とし穴と緩和策

�罠 説明 緩和

グラフが濃すぎる

大きなプロジェクトは、数百の読み取り不能なノードを生成します

使用する`-Pplantuml.kg.maxNodes=30`そしてコミュニティでフィルタリング

除外が広すぎる

多すぎるファイルが`.graphifyignore`グラフの値を減少させる

まずは credentials と build のみを除外して始める

�矢印の方向

INFERREDエッジはあいまいな方向を持つ可能性がある

フィルターで`-Pplantuml.kg.edgeTypes=EXTRACTED`特定の関係に対してのみ

旧式のグラフ

コードは変わるが、グラフは再構築されない

使う`graphify . --update`定期的にまたはgitフック`graphify hook install`

更新されたコスト

インクリメンタルアップデートはほぼ無料です (tree-sitter local)

ドキュメントだけ(.adoc) LLMトークンを消費する

最終的に得られるもの

@startuml
skinparam backgroundColor #FEFEFE

rectangle "前に" as avant {
    card "手描きの図
常に時代遅れ
誰も更新しない" as av1 #FDEDEC
}

rectangle "後で" as apres {
    card "自動生成されたダイアグラム
コードと常に最新状態
Gitでバージョン管理
決定論的かつ再現可能" as ap1 #E8F8E8
}

avant --> apres : graphify . --no-viz\n+ ./gradlew generateKnowledgeGraphDiagram

@enduml

具体的な利益:

利益 詳細

常に最新のドキュメンテーション

�図は現在のコードを反映しており、手動のスナップショットではありません。

メンテナンスの手間ゼロ

�図はビルドごとに再生成されます

技術的負債の削減

図を手動で維持する必要はありません

新しいもののためのビジュアルコンテキスト

新しい開発者は図を見てアーキテクチャを理解する

ファインチューニングの可能性

ペア (サブグラフ → ダイアグラム) は AI のトレーニングの例です

自動検証

`PlantumlService.validateSyntax()`生成された各図を確認する

迅速なオンボーディング

5つのダイアグラム = アーキテクチャの完全なビュー

(Empty output) なぜがある者は、いかなる「どうすればいいか」にも耐えることができる。 __

Le pourquoi : 図は常に最新状態。Le comment : Gradle パイプライン内の 2 つのコマンド。

リンク

関連記事