LabsにAIコーディング用設計管理ツールdocs-kitを追加しました
Labsに自社開発のdocs-kitを公開しました。AIコーディングのための設計書管理ツールです。AIは設計書を疑わないので、古い設計書は「間違った指示」として働いてしまう。docs-kitは鮮度をgitの履歴から判定し、AIには必要な文書だけを開かせます——手戻りとトークンの両方が減ります。
Labsに自社開発のdocs-kitを公開しました。AIコーディングのための設計書管理ツールです。ユーザーガイド（日本語・英語）とバイナリも公開しています。
AIが実装の大半を書くようになると、ボトルネックは設計書の側へ移ります（→ AIコーディングがもたらすパラダイム・シフト）。
AIは設計書を疑わない
人間は設計書を数行読むだけで違和感に気づきます。「この関数名、もう無いはずだ」——そこで手を止めてコードを確認する。
AIは疑いません。status: currentと書いてあればcurrentとして扱い、しかも従順なので実装のほうを設計書に寄せてきます。 廃止したAPI名で新機能を書き始める。正しく動いていた実装を、古い設計へ書き戻す。どれも指示に忠実に従った結果なので、プロンプトの工夫では直りません。渡している情報が古いことが原因なので、情報の側を直すしかない。
鮮度はgitが判定する
各文書のfront matterに「この文書が責任を持つコード範囲」と「最後に実装と突き合わせたコミット」を持たせます。
scope: [src/core/editing/**] # この文書が責任を持つコード範囲
verified_at: 8f3a1c2e0b7d4a91c3f6e2d8b5a704c1e9f3d602 # 最後に実装と突き合わせた commit
verified_at以降にscopeの中のコードが動いていればstale。
$ docs-kit stale
SPEC-editing-model stale code-changed: 3 files changed since 8f3a1c2
ARCH-overview ok (verified at 8f3a1c2)
ok 1 / stale 1 / broken 0 / skipped 0
判定の根拠がリポジトリの事実なので、「最終更新日」のような自己申告になりません。CIを落とし、内蔵のMCPサーバー経由でAIにも同じ結論が届きます。
読ませる量が減る ＝ トークンが減る
設計書を捨ててコードだけを渡す運用は、毎回コード全体を読ませることになり高くつきます。かといって設計書を全部読ませても同じです。
docs-kitのMCPサーバーは本文を運びません。返すのはパスとメタデータ、200文字の要約だけ。AIはそれを見て「今回は関係ない」を先に判断し、必要な文書だけを自分で開きます。実測では、1回の逆引きで15文書が返って、実際に本文を読んだのは4文書でした。
古い設計書を信じて書き直し、あとで戻す——という手戻りも消えます。鮮度の判定は、トークンの節約でもあります。
使えます
- バージョン — 1.1.0
- 動作環境 — macOS / Linux / Windows。Go製の単一バイナリで、必要なのは
gitだけ - 保存形式 — front matter付きのただのMarkdown。docs-kitをやめても普通に読めます
- ダウンロード — インストール手順
- ドキュメント — ユーザーガイド（日本語・英語）
いま設計中の次のプロダクト（LabsのEXP—002）の設計書もdocs-kitで管理しています。オープンソースとしての公開も準備中です。
AIコーディングのための設計書管理ツール。scopeとverified_atをfront matterに持たせ、鮮度をgitの履歴から判定します。Go製の単一バイナリで、必要なのはgitだけ。
古い設計書による手戻りが消え、MCPは本文を運ばないのでAIは必要な文書だけを開きます。読ませる量が減る＝トークンが減る。