なぜkizamiが必要か？
なぜドキュメントは失われるのか
こんな経験はないでしょうか。半年前のコードを開くと、見慣れない実装が目に入る。なぜこうなっているのか？
git log には「fix: update logic」とあるだけ。PRには説明がない。Slackの該当メッセージはとっくに流れている。書いた本人はすでに退職しています。
コードは正常に動いている。でも、なぜそうなっているかは誰も知らない。変更するのが怖い。コードレビューに余計な時間がかかる。知識が属人化し、特定の人がいなければ説明できない状態になる。
これがドキュメント管理が抱える問題です。判断の根拠は、決定した瞬間にしか存在しません。議論が終われば消えてしまう。後からコードを読んでも復元はできません。
kizamiはこの課題に向き合うために作られました。「なぜ」を適切なタイミングに記録し、Gitに保存し、コードとの乖離を検知し続ける——そのための軽量なワークフローを提供します。
「AIにドキュメントを修正してもらえばよい」では不十分な理由
AIがコードベース全体を読める時代に、なぜ専用ツールが必要なのか？
端的に言うと：AIは「今のコードが何をしているか」は読めるが、「なぜそう決めたか」は読めない。
AIは結果を読む。kizamiは判断の瞬間を捉える。
コードはあくまで意思決定の「結果」だけを持っています。そのプロセスは残りません。
AIがコードを読んでも復元できないもの：
- 3ヶ月前の負荷テスト結果を根拠にした選択
- 「PostgreSQLでなくSQLiteにした理由」→ コードにはSQLiteしか残っていない
- チームで議論して却下した選択肢
- 当時存在した外部制約（予算、納期、チームのスキルセット）
決定の根拠は、決定した瞬間にしか書けない。 kizamiはその瞬間を捕捉し、Gitに保存し、時間が経っても正確さを保ち続けるために設計されています。
AIは受動的なツールである
「AIに頼めばいい」アプローチは、誰かが「ドキュメントが古い」と気づき、AIに修正を依頼しようと実際に行動することで成立します。しかし、気づいたときにはすでに、当時の文脈は失われています。
ドキュメントが陳腐化する原因は、まさに「誰も覚えていない」ことです。kizamiはCIとgit hookでこれを自動化し、誰かが思い出す前に自動的に検知します。
AIは受動的なツールです。聞かれたときに答えます。kizamiは能動的なインフラです。変化を検知し、通知します。
AIの時代こそ、正確なドキュメントが力になる
AIはコードを読み、変更の候補を提案し、テストを書くことができます。しかし、なぜその設計になったか、どんなトレードオフを経てきたかは、コードからは読み取れません。AIが意図を把握するには、文脈を自然言語で提供する必要があります。
正確なドキュメントはAIにとっての設計図です。ドキュメントが整っているほど、AIのアシストはより的確になります。kizamiは、そのドキュメントを正確な状態に保つための仕組みです。