#知識管理

読んで最初に思ったのは、これはかなり地味なのに、かなり大事な話だな、ということだった。AIが自動で書いたメモをそのまま知識ベースに入れるとき、問題になるのは会話ログだけじゃない。むしろ、監査メモとか改善案みたいな「AIが勝手に生成した社内文書」のほうが、うっかり秘密や個人情報を含みやすい。そこをちゃんと危険物として扱っているのが、すごく筋がいいと思った。 特に刺さったのは、「1つでも秘密っぽい文字列があったら全部止める」という方針。普通なら「怪しいファイルだけ除外すればいい」と考えがちだけど、この記事はそこをあえてやらない。部分同期は便利そうに見えて、判断ミスが一番怖い場面では逆に危ない、という感覚がある。こういう場面では、賢くふるまうより、雑にでも止まるほうが信頼できる。実運用の安全策としてかなり納得感があった。 一方で、読んでいて少し冷や汗が出たのは、ゲートを通ったあとを確認する道が別問題として残っていたところだ。`ls` や `cat` が iCloud っぽい挙動でこける、でも存在チェックは通る、というのはかなりいやな状態だと思う。入口のスキャンは成功していても、出口で本当にW

読んでまず思ったのは、これはAIの性能不足というより、こちらの仕事の進め方がまだ「セッションが消える前提」に寄りすぎている、ということだった。 AI coding agent は毎回新しい相手みたいな顔で出てくる。昨日まで何度も話した設計の前提を、今日また説明し直す。あれはたしかに面倒だし、地味に判断の質も落ちると思う。 この記事で面白かったのは、記憶を“賢く”持たせるというより、決めたことをコードの近くに置いてしまう発想だった。`docs/` の中に facts, decisions, guardrails, skills を分けて、しかも Git で履歴を残す。AI の記憶力に期待するのではなく、「次に読むべきものが、毎回ちゃんとそこにある」状態を作る。かなり実務的だし、むしろ人間にも効くやり方だと思う。 ただ、そこまでやっても万能ではない、とはっきり書いているのも好感が持てた。結局のところ、最初の聞き取りも更新も人間がやる。つまり“記憶の自動化”というより、“忘れにくい手続き化”に近い。ここを神話っぽく盛らずに、更新されなければただの `docs/` フォルダになる、と言い切って

この記事を読んでまず思ったのは、AI のメモリ機能って、便利そうに見えるけれど、雑にやるとすぐ壊れそうだということだった。 「覚えておく」だけなら簡単でも、何を、どの単位で、どのくらいの確からしさで残すのかを決めないと、あとで検索しても使い物にならない。そこに OKF みたいな形式を噛ませて、さらに SQLite FTS5 で引けるようにしているのは、かなり筋がいいと思う。単なる“気分のメモ”ではなく、検索できる記録に落としているのがいい。 ただ、読んでいて少し引っかかったのは、ここまで整えると今度は「AI の記憶」というより「人間が扱える知識ベース」にかなり寄っていくことだ。 それは悪いことではない。むしろ、AI の曖昧な内部状態に頼るより、ファイルとして見えて、消せて、タグで絞れて、履歴も残る方がずっと安心感がある。けれど同時に、これって本当に“記憶”なのか、という感覚は残る。実態は、上手に整理された外部メモ帳に近いのではないかと思う。 その「外部メモ帳」にも、ちゃんと思想があるのが面白い。memory/ に Markdown を吐き出して、人間がブラウザで読めるようにしつつ、裏で

GitHubで公開されている `inkeep/open-knowledge` は、ただの markdown editor ではありません。 README の言い方を借りるなら、「Beautiful, AI-native markdown editor and LLM Wiki」。つまり、最初から AI と一緒に使う前提で作られた、見た目のきれいなマークダウン編集環境です。 これ、地味に見えてかなり野心的です。普通のメモアプリは「人が書く」ことが中心ですが、OpenKnowledge はそこに Claude、Codex、Cursor などの agent や harness を組み込んで、人間が書く → AI が手伝う → それを知識として育てる、という流れを狙っているように見えます。個人的には、この発想がかなり今っぽいと思いました。単に文章を書く道具ではなく、AI に読ませて、整えさせて、つなげて、wiki として使う。ここが肝です。 OpenKnowledge は、AI 連携を前提にした markdown editor 見た目は WYSIWYG 寄りで、Google Doc や