AIに簡単に適切なコンテキストを渡したい。
AIには、そのコンテキストを読むだけでなく、整理したり書き換えたりしてほしい。
でも、自分が積み上げた知識をAIに自由に編集させるほど壊されるのが怖くなる。
この矛盾をどうにかしたくて、kakuというローカルファーストのMarkdownノートアプリを作りました。
kakuは、最初からノートアプリとして企画したものではありません。原型は、カップルで利用するAIカウンセリングのWebサービスでした。
この記事では、カウンセリングサービスから始まり、ネットワーク、Git worktree、CRDTを試しながら、なぜ現在のkakuにたどり着いたのかを書きます。
（この文章は自分が話した内容をkakuを使って、Fable5/Solと壁打ちしながらドラフトを作り、Solに書かせたものです）
AIカウンセリングには、過去の文脈が必要だった
最初に作っていたのは、カップルで利用できるWebサービスでした。AIカウンセラーと会話すると、診断や追加の質問が提示され、その結果を次回以降のカウンセリングに利用します。
一度きりの相談であれば、現在のチャットだけをAIに渡せば済みます。しかし、継続的なカウンセリングではそうはいきません。
- 過去のカウンセリング
- ユーザーとパートナーの基本情報
- 診断や質問への回答
- 日々のジャーナル
- それぞれの情報の関係
こうした情報のうち、いまの相談に関係するものを選び、AIに渡す必要がありました。
会話を自動的に記憶する仕組みだけでは、何が次の回答に影響しているのかが分かりません。古くなった情報や、今回の相談とは関係のない情報まで混ざれば、むしろ回答を悪くすることもあります。
そこで、情報をノートとして保存し、関連するノート同士をリンクでつなぐネットワーク構造を作りました。現在の相談に近いノートをたどれば、AIに渡すコンテキストを明確にできると考えたからです。
ネットワークを眺めるのは楽しい。でも、育てるのは大変だった
ネットワーク上でノートを動かし、情報同士のつながりを眺める体験は気持ちのよいものでした。一方で、ネットワークを維持する作業は想像以上に面倒でした。
ジャーナルを書いた後に、「この内容は3週間前のカウンセリングと関係がある」「この診断結果にもつながっている」と考え、リンクを追加しなければなりません。
本来したかったのは内省です。 しかし実際には、AIのためにコンテキストを整備する作業が、人間の仕事になっていました。
AIにリンクを自動で追加させる方法も試しました。ただ、「関連している」とは何かが曖昧です。同じ出来事を扱っている、同じ人物が登場する、考え方が似ている、あるいは正反対の視点を持っている。どれも関連ではありますが、いつもコンテキストとして役立つとは限りません。
精度の問題というより、ネットワークを正しく保つこと自体を目的にしてしまったのが問題でした。ネットワークを操作する行為は、本来の思考や内省の直感とは少しずれていたのです。
「診断してもらう」から「一緒に考える」へ
もう一つ、サービスの目的そのものも変わっていきました。
カップルで一緒にサービスを継続して使うことには、個人向けとは異なる難しさがあります。自分で使い続けるうちに、カウンセリングや診断よりも、考えを掘り下げたり、別の視点から捉え直したりする用途が中心になっていきました。
AIに自分を診断してもらうのではなく、AIと一緒に自分の考えを探索する。
そのための道具として、左にネットワーク、中央にノート、右にAIチャットを置いたWebアプリを次に作りました。ノートを読み書きしながら、関連する情報をコンテキストにしてAIと会話できる形です。
AIには、過去の内容の要約、関連情報の抽出、ノートの作成や編集などを任せるようになりました。ここで初めて、AIは回答を返すだけでなく、知識ベースを育てる側に回りました。
そして、次の問題が出てきました。
AIに既存のノートを直接変更させるのが怖い。
AIに整理してほしい。でも、直接触らせるのは怖い
新しいノートを作るだけなら、不要なものを消せば済みます。しかし既存のノートの要約、統合、分割、追記、リンクの追加まで任せると、AIは人間が書いた文章を直接変更します。
うまくいけば便利です。一方で、大事なニュアンスを削ったり、事実と推測を混ぜたり、まだ残しておきたい記述を「重複」と判断して消したりする可能性もあります。
チャットで修正案を出してもらい、人間がコピー＆ペーストする方法なら安全です。しかし、変更するノートが増えるほど、その方法ではAIエージェントの能力を生かせません。AIが複数のファイルを読み、全体を整理できるのに、最後の反映だけを人間が一つずつ行うことになります。
欲しかったのは、AI機能を持つエディタというより、人間とAIが同じ知識ベースを直接読み書きできる作業空間でした。
MarkdownとGit worktreeで、AIの編集を隔離してみた
そこで、ノートをMarkdownファイルとして管理し、AIには別のGit worktreeで編集させる仕組みを作りました。
AIは隔離された環境で自由にファイルを変更する。人間は差分を確認し、必要な変更だけを取り込む。ソフトウェア開発のブランチとレビューを、ノートの共同編集に持ち込む発想です。
この方法なら、AIに直接ファイルを触らせても元の内容は守れます。しかし、日常的に使うと別の問題が起きました。
人間と複数のAIがそれぞれのworktreeで同じノートを変更すると、当然コンフリクトします。AIを並列に動かすほど、人間が最後にマージとコンフリクト解消を引き受けることになります。
差分の見せ方も簡単ではありませんでした。変更前を基準にした3-way diffを見せるのか、現在のノートとの2-way diffを見せるのか。複数のworktreeをどのように扱うのか。変更を提案として管理するのか。
どの方式も説明はできます。しかし、自分が欲しい体験からは遠ざかっていきました。
欲しかったのは、レビュー工程を精巧にすることではありません。
AIにどんどん編集させ、その間は放置しても大丈夫な状態でした。
**AIの仕事が速くなるほど、人間の後処理が増える仕組みでは意味がありません。**提案の作成、レビュー、マージという手順を毎回踏むのではなく、普段はそのまま仕事を任せ、必要なときだけ変更を選んだり元に戻したりしたい。
Gitは変更を厳密に管理する優れた道具ですが、人間とAIが一つのノートを日常的に触り続けるための操作モデルとしては重すぎました。
そこから現在のkakuが生まれた
試行錯誤の末に残った要件は、次のようなものでした。
- ノートはローカルのMarkdownファイルとして持つ
- 人間とAIが同じファイルを直接読み書きできる
- AIの変更は、人間の変更と区別して確認できる
- AIの変更は、必要な部分だけ採用・破棄できる
- 人間とAIの編集が重なっても、知識ベースを壊しにくい
- ノートのつながりから、チャットに必要なコンテキストを集められる
- 会話を分岐し、複数の方向を並列に掘り下げられる
この要件から、現在のkakuの形ができました。
kakuでは、ワークスペース直下のMarkdownファイルを、人間とAIが共に触るノートにしています。Claude CodeやCodexのような外部AIエージェントは、kaku専用のAPIや編集UIに閉じ込められることなく、普段どおりファイルを読み書きできます。
一方で、採用済みの内容は別に保持します。人間の通常編集は自動的に反映しつつ、AIや外部エディタによる変更は差分として残し、後から採用または破棄できます。人間とAIの編集が重なった部分も区別し、単純な上書きで内容を失わないようにしています。
エディタ内部の同期にはCRDTを使っています。ただし、CRDTを使うこと自体が目的ではありません。重要なのは、コンフリクト解消を人間の日常業務にせず、AIに自由に仕事を任せられることです。
Markdownは保存形式ではなく、人間とAIの共通インターフェース
Markdownを選んだ理由は、可搬性だけではありません。
Markdownファイルなら、人間は好きなエディタで編集できます。AIエージェントも、ファイルを読む、検索する、複数ノートをまとめて変更する、リンクを追加するといった操作を、特別な統合なしに実行できます。
kaku内蔵のAIだけに編集を許す設計にすると、AIの能力はアプリが用意した機能の範囲に閉じます。MCPや専用APIで一つずつ操作を定義することもできますが、ファイルを直接扱えるエージェントにとっては、それ自体が制約になります。
ローカルのMarkdownを共通インターフェースにすれば、Claude Code、Codex、Cursorなど、使い慣れたエージェントをそのまま持ち込めます。 将来より良いエージェントが登場しても、知識ベースを移行する必要はありません。
アプリやAIを交換しても、自分の知識は手元に残る。 この点は、長く使う知識管理ツールでは特に重要だと考えています。
チャットも一本道ではなくしたかった
個人の内省へ用途が変わったとき、チャットの形にも違和感がありました。
考えを掘り下げるときは、一つの問いに一つの結論を出して終わるとは限りません。同じノートについて、「反対意見を聞く」「具体例を考える」「別の理論から見る」といった問いを同時に試したくなります。
そこでkakuでは、1つのノートを起点に会話し、途中からチャットを分岐できるようにしています。ノートのリンクや被リンクなどから関連するコンテキストを集めつつ、会話は複数の方向へ並列に伸ばせます。
最初のカウンセリングサービスでは、ネットワークは人間がAIのために管理するものでした。現在のkakuでは、リンクは人間にとって自然なノートのつながりであり、同時にAIがコンテキストを集める手がかりでもあります。
ネットワークを育てることを独立した仕事にせず、普段の読み書きの結果として構造が残る形を目指しています。
kakuが目指しているもの
kakuを一言で表すなら、AIと共同編集できるローカルファーストのKnowledge Management Systemです。
ただし、「AI機能が付いたノートアプリ」を作りたいわけではありません。
AIが回答を返す場所と、人間が知識を書く場所が分かれていると、コピペや整理や反映が人間の仕事として残ります。反対に、AIだけが知識ベースを更新すると、人間は内容を理解できなくなり、安心して任せられません。
だから、人間とAIが読み書きする場所を一つにする。
人間が書き、AIが整理・分析し、その結果を人間が選びながら知識を育てる。AIエージェントにはファイルを直接扱える能力をそのまま使わせながら、人間は自分の知識を手元に保ち、必要なら簡単に戻せる。
カップルカウンセリングから始まり、ネットワーク、Git worktree、CRDTを試した先で、最後まで残ったのはこの問題でした。
AIに仕事を任せながら、自分の知識を安全に保つ。
kakuは、そのための道具として開発しています。
良かったらダウンロードして使ってみてください。