---
title: Litho
created: 2026-06-30
updated: 2026-07-01
type: entity
tags: [tool, wiki, knowledge-base, markdown, dev-tool, automation]
sources: [raw/articles/litho-deepwiki-rs-code-documentation-2026.md, raw/articles/langchain-openwiki-repo-documentation-agent-2026.md]
confidence: medium
---

# Litho

Litho（`deepwiki-rs`）は、ソースコードから C4 model のアーキテクチャ図と Wiki 風ドキュメントを自動生成する Rust 製の AI 文書化エンジン。README では、コードベース解析、依存関係・構造抽出、LLM によるドキュメント生成、Mermaid 図、CI/CD 連携、外部知識の取り込みを特徴としている。

Yuta の Wiki 文脈では、これは [[digital-gardening-cms]] や [[llm-wiki-pattern]] と同じ「読むたびに都度検索する」のではなく、「コードから持続的に読める知識面を作る」方向の道具。ただし Litho は人間の研究 Wiki というより、コードベース理解・オンボーディング・設計書の鮮度維持に寄っている。同じ方向の [[openwiki]] は、C4 図よりも agent instruction file から参照される repo Wiki と scheduled update に重点を置く。

## Design implications

- 設計書が腐る問題を、手書きドキュメントではなくコード解析と生成のループで扱う。
- C4 の context/container/component/code レベルを出力するため、単なる README 生成よりも構造化された設計理解を狙う。
- CI/CD で毎コミット生成できると説明しており、[[wiki-maintenance-loop]] 的な継続更新をソフトウェア設計書に適用する例になる。
- 生成物は便利だが、アーキテクチャ判断の正しさや命名の妥当性は別途レビューが必要。自動生成 Wiki は、信頼できる最終文書というより、保守される下書き・索引として扱うのが安全。

## Open questions

- 生成された C4 図や説明が、実際の設計意図とずれたときに誰がどう検証するか。
- コードから抽出できない運用上の制約、歴史的経緯、暗黙の責務をどこで補うか。
- LLM 生成ドキュメントを CI/CD に組み込む場合、差分レビューとノイズ抑制をどう設計するか。