CodeBoardingとは｜静的解析とLLMでコードベースの構成図を自動生成する8言語対応OSSを実測

CodeBoarding（CodeBoarding/CodeBoarding）は、コードベースを LSP による静的解析で呼び出しグラフにし、その構造を根拠に LLM エージェントがコンポーネントの説明と関係を書いて、Mermaid の構成図と文書を出す MIT ライセンスの OSS だ。GitHubスターは 2.4k、対応言語は 8 つ、入口は CLI・VS Code 拡張・GitHub Action・MCP サーバー・Web プラットフォームの 5 つ。本記事は PyPI から Python 3.12 環境に導入し、LSP サーバーのセットアップ、リポジトリ自身に同梱された解析結果（analysis.json）からの文書レンダリング、キー無しでの実行の挙動を実測した。README の「How it works」図が現行の自己解析結果と食い違っている点も、生成した図で示す。

CodeBoarding は「AI が書いたコードを人が把握し直す」側のツールで、AI コーディングの進め方全体はVibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026にまとめている。

CodeBoardingとは——静的解析の根拠つきでLLMに構成図を書かせる

README 冒頭の定義は次の通りだ（原文）。

See what your AI is building before it breaks. CodeBoarding gives developers and coding agents a visual map of a codebase. It combines static analysis with LLM reasoning to generate architecture diagrams, component-level documentation, and navigable outputs you can use in your IDE, CI, and docs.

読者の3問に答える。

・何ができる：リポジトリを解析して、コンポーネント（部品）の一覧・各部品の説明と主要エンティティ・部品間の関係（ラベル付き矢印）を analysis.json に出す。そこから Mermaid 図と文書を md／html／mdx／rst で書き出し、VS Code 拡張や Web プラットフォームで対話的にたどれる
・何を解決する：手描きの構成図がコードの変更に追いつかない問題と、LLM にコードを丸ごと読ませると根拠の無い部品名が出る問題。呼び出しグラフを先に作るので、LLM は「何がどこを呼ぶか」を見た上で説明を書く
・何を代替する：オンボーディング用に人が書く「アーキテクチャ概要」ドキュメントの初稿と、PR レビューで「この変更はどの部品に触れるか」を口頭で説明する作業。IDE のコードナビゲーションや、AI エージェントにコンテキストを渡すグラフ CLI（後述の比較）とは役割が違う

README が挙げるユースケースは4つで、AI 開発中のアーキテクチャ可視化、AI 生成コードを壊れる前に確認する、大きなリポジトリを短時間で理解する、ローカル・IDE・PR・ドキュメントで同じ視覚モデルを共有する、である。生成例は GeneratedOnBoardings リポジトリに集められ、README は「800 以上の OSS リポジトリを可視化した」と書く（本記事では件数を数えていない）。

CodeBoardingの仕組み：LSPの呼び出しグラフ → クラスタリング → LLMエージェント → レンダリング

処理は4段に分かれる。名前は自己解析結果の 9 コンポーネントに合わせた。

増分実行は fingerprint.json に前回の基準を持ち、incremental サブコマンドは「git 不要で、生成時から変わった部分だけ」を更新する。partial --component-id "1.2" はコンポーネント 1 個だけを書き直す。これとは別に health 検査（health_main.py）があり、LLM を使わずに関数サイズ・ファンイン／ファンアウト・継承深さ・循環・未使用コードを採点して CI のゲートに使える。同梱の自己検査結果は総合スコア 0.868 で、関数サイズは 1,420 エンティティで指摘 0、未使用コード診断は 216 件（警告 80）だった。

READMEの図と自己解析結果のずれ

リポジトリには .codeboarding/ として analysis.json・fingerprint.json・file_coverage.json・static_analysis.pkl・health/ が同梱され、GitHub Actions の codeboarding-sync.yml が main への push ごとに「chore(codeboarding): sync analysis baseline」としてコミットし直している（履歴上、GitHub Action 名義のコミットが 124 件）。この 2026-09-15 生成の analysis.json は 326 ファイル中 171 を解析（155 は未解析、うち 141 は .codeboardingignore による除外）、depth_cap 2、コンポーネント 9 個だ。一方 README の図は 6 コンポーネントで名前も異なり、README が「深い解説はこちら」と指す .codeboarding/overview.md はリポジトリに存在しない（レンダリング成果物はコミットされていない）。自分のリポジトリで使うときも、図の鮮度は analysis.json の metadata.generated_at で確認するのがよい。

実測：PyPIからの導入・LSPセットアップ・レンダリング（Linux）

README は pipx を推奨し、pip なら仮想環境内でと書く。本記事は Python 3.12 の venv で pip を使った。

python3.12 -m venv .venv && . .venv/bin/activate
pip install codeboarding          # README は --extra-index-url https://pip.codeboarding.org/simple/ も案内
codeboarding-setup                # LSP サーバーを ~/.codeboarding/servers/ に取得
codeboarding --help

既存の解析結果から文書を出し直す codeboarding-render はキー不要で、overview.md の先頭に 9 コンポーネントの Mermaid、各コンポーネント文書の先頭にサブコンポーネント（例：Static Analysis Engine の下に LSP Engine and Language Adapters・Project Scanning and Analysis Cache など 4 つ）の Mermaid が出る。冒頭の図はこの overview.md の Mermaid をそのまま描画したものだ。

codeboarding-render .codeboarding/analysis.json --format md --output-dir /tmp/cb-render   # キー不要
ls /tmp/cb-render   # overview.md と 7 つのコンポーネント文書

Python の版について補足する。pyproject.toml の requires-python は >=3.12,<3.13 だが、README と PyPI の説明は「Python 3.12 または 3.13」、リポジトリの .python_version は 3.13 と三者が食い違う。pipx で入れるなら README どおり --python python3.12 を明示しておくのが安全だ。また PyPI の 0.14.2 に対して git の最新タグは v0.14.1（2026-09-08）で、main はそこから 18 コミット先だった。

設定とプロバイダ：config.toml・環境変数・モデル

初回実行で ~/.codeboarding/config.toml が生成され、[provider] にキーを 1 つだけ書く方式だ。生成されたファイルのコメントに並ぶのは openai_api_key（openai_base_url で OpenAI 互換プロキシ可）・anthropic_api_key（anthropic_base_url で Azure Foundry 可）・google_api_key・vercel_api_key・aws_bearer_token_bedrock・cerebras_api_key・deepseek_api_key・glm_api_key・kimi_api_key・ollama_base_url、README にはさらに openrouter_api_key・orcarouter_api_key・litellm_base_url／litellm_api_key がある。モデルは [llm] の agent_model で指定し、README の例は gemini-3.8-flash。シェルの環境変数（ANTHROPIC_API_KEY など）が config.toml より優先される。

本記事の環境で codeboarding-setup が生成した ~/.codeboarding/config.toml の先頭は次の形だった（キーは 1 つだけコメントを外す）。

# CodeBoarding user configuration
# Location: ~/.codeboarding/config.toml
# Uncomment and fill in exactly ONE provider key below.
[provider]
# openai_api_key            = "sk-..."
# anthropic_api_key         = "sk-ant-..."
# google_api_key            = "AIza..."
# ollama_base_url           = "http://localhost:11434"

運用に効く環境変数は3つある。

・CODEBOARDING_LSP_REQUEST_TIMEOUT：言語サーバーへの 1 リクエストのタイムアウト秒。既定は C# が 120 秒、他が 60 秒。直近のコミット（#594）で上書き可能になった
・CODEBOARDING_MAX_CONCURRENT_ENGINES：同時に起動する LSP サーバー数の上限。既定は無制限
・CODEBOARDING_TELEMETRY=false または DO_NOT_TRACK=1：テレメトリ停止

テレメトリは既定オンで、TELEMETRY.md によれば送るのはコマンド名・バージョン・成否・実行時間・使用モデルとトークン数、リポジトリの LOC と言語数、言語別のファイル数・ノード数・エッジ数、MCP 呼び出しの情報で、識別子は機械 ID の SHA-256 ハッシュとリポジトリ所有者名。送らないのはソースコード・ファイル名・プロンプト・LLM 出力・API キー・メール・IP。送信先は PostHog（米国）だ。source プロパティで oss／vscode／github_action の別が付く。

CodeBoardingの入口は5つ：CLI・VS Code拡張・GitHub Action・MCP・Web

GitHub Action の使い方は分かりやすい。PR が開かれると解析して構成図の差分をコメントし、マージ後の main push で基準を更新する。CodeBoarding 自身のリポジトリでその運用が回っていて、コミット履歴の 2 割弱（124／649）がこの自動コミットである。

類似ツールとの比較：oh-my-mermaid・Ix・Code Review Graph

「コードベースを図にする／グラフにする」OSS を当サイトの過去記事から並べる。数値は各記事執筆時点で、本記事では再取得していない。

oh-my-mermaid は Claude Code の中で LLM に図を描かせる軽さが取り柄で、CodeBoarding は先に静的解析をして LLM の説明に根拠を持たせ、CI で更新し続けるところが違う。AI エージェント側にコードの構造を渡す目的なら Ix や Code Review Graph の方が直接的で、CodeBoarding の MCP サーバーはその中間に位置する。AI コーディングの「見える化」という意味では、エージェントの履歴とコストを可視化する agentsview や、VS Code 拡張で AI コーディングの習慣を診断する Microsoft AI Engineer Coach と補完関係にある。

ライセンス・メンテナンス状況と採用判断

LICENSE の実体は MIT License（Copyright (c) 2025 CodeBoarding）で、pyproject.toml の記載と一致する。メンテナンス状況の実測値は次の通り。

複数人で継続的に開発され、9 月に入っても 2 日おきにコミットがあり、LSP まわりの修正（bulk didOpen の drain barrier・タイムアウト上書き）が直近の主題だ。Web プラットフォームと VS Code 拡張は同じ会社が提供しており、CLI は MIT だが、Web 側の料金や利用条件は本記事では確認できなかった。

・向いている：AI コーディングで急に増えたリポジトリのオンボーディング資料を初稿から自動化したいチーム。PR ごとに「どの部品に触れたか」を図で示したいレビュー運用
・待った方がよい：C# 主体で dotnet をランナーに入れられない環境（LSP セットアップで C# だけ落ちた）、テレメトリを既定オンにできない組織（環境変数で止められるが要周知）
・確認してから：LLM コスト。README・TELEMETRY.md ともにトークン数は「収集する」とあるが目安は示されていない。まず小さなリポジトリで --depth-cap を下げて測るのがよい

まとめ

参照ソース

・CodeBoarding/CodeBoarding（公式リポジトリ） — README・LICENSE・pyproject.toml・.codeboarding/analysis.json・.github/workflows/（2026-09-16 時点の main）
・codeboarding（PyPI） — 0.14.2・導入手順
・TELEMETRY.md — 収集項目・識別子・オプトアウト
・GeneratedOnBoardings — 生成例の集積
・CodeBoarding-MCP — MCP サーバー（本記事では未検証）