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は、そのための道具として開発しています。

良かったらダウンロードして使ってみてください。