オイオイオイ書くわアイツ

ほうクソブログですか……たいしたものですね

ナレッジ管理くんを作りたかった、AI サマ〜〜〜

はじめに

プロジェクト管理とナレッジ管理を分けた方が良い。 あるいは、両方マジでやる必要がある。

プリミティブな発想としては、プロジェクトの各ステップで然るべきドキュメントを作り、さらに然るべき方法で社内 wiki を走査して整理してくださいね、というルールを敷きたい。 が、そういうのってルールで強制して片手間にやらせても微妙じゃないすか、とも思う。

片手間はやっぱ微妙で、マジでナレッジ管理に取り組みたい。 結局「別に直接仕事を進めてくれるわけではない、延々と wiki を管理してくれる謎の人」に会社がいくら払いたいか、みたいな話でもある。 俺も個人 wiki （てか Obsidian）をそれなりに真面目に管理していて、

  • 俺がなんかやるたびに「君！ページを作りたまえ！」を言ってくれる人
  • 定期的に wiki をランダムに読みまくり、リンクを整理してくれる人

などがいると良いなと思うが、そんな人は雇っていない。 人間は高いので。 ところで、生成 AI は人間より安い。 して、今回は特に 俺がなんかやるたびに「君！ページを作りたまえ！」を言ってくれる人 を AI サマにやってもらおうと思う。

俺の Obsidian の現状

で、まず俺の個人 wiki がどんなもんかというと、基本的には文中リンクによるページ間のネットワーク、転じて俺の脳のネットワークが気持ちよくなるように管理したいと思っている。 ページ名を語や短文にして、リンクを貼りながら文章を書きたい。 趣味活動っぽい例としては、ルーミスの「やさしい人物画」を読み直したときに序文がめっちゃよかったので、やさしい人物画の序文の名言.md として以下を書いた。

真に精神を集中すべきものは君自身に対してであり、君の作品は君の行った頭脳的修行の結果おのずと表れるのである

「はじめに」でエグい良いことを言っていて、要するに「絵は "何を描くことを 選んだ のか" という意思決定の話であり、お前が良いニンゲンでないとしょうがない」みたいな話。つまり、[ [ 根っこが腐っていてはジューシーフルーツは実らない ] ] ということ。

根っこが腐っていてはジューシーフルーツは実らない.md は以下。

ジューシーフルーツ

こうすると、「あー俺が "良い" と思う言葉ってやっぱりジューシーフルーツ永田だな」と思い、脳のネットワークが気持ちよくなる。 が、一方で、読書してるときに本の内容から一旦離れて、自分の脳のネットワークを見なければいけない。 このコンテキストスイッチがだるいんで、脳のネットワーク管理を放棄しがちになる。 脳のネットワーク庭師として生成 AI サマに活躍してもらいたい。

AI サマにお願いする:Linear->n8n->Cursor

本 -> ジューシーフルーツ永田 の例で生成 AI サマの活躍の機会を考えると、

  1. 本を読んで思ったことをテキトーに書き殴る場所（aka. プロジェクト管理 ）
  2. ジューシーフルーツ永田に話を繋げる場所（aka. ナレッジ管理 ）

が分かれていると嬉しいと思う。 「AI に俺の脳のネットワークを前提にプロジェクトの話をちょろっと聞いてもらう」を期待していて、プロジェクト管理の情報を渡しすぎると AI がバカになると心配している。 ジューシーフルーツ永田脳だけを AI に渡す上で、プロジェクトとナレッジの置き場所が分かれていると一定便利な気はする。

ツール選定

で、俺は趣味の活動について真面目なプロジェクト管理をやっていないが、これを機に始めることにした。 ツールとしては Linear を選ぶ。 これはマジでノーポリシーで、会社くんが Linear を使ってオシャレをしたがっているので、会社への忠誠心を示すために選んだ。

「Linear でなんか起きたときにええ感じになんかやる」部分には色々な手段がある。 俺は一端のエンジニアなので自分でコードを書いて実装しても良いが、今回は n8n を使う。 会社への忠誠心を示すために選んだ。

実際に作ったもの

会社への忠誠心の賜物として、以下のような n8n ワークフローを作ることとなった。 ざっくりいうと、

  1. Linear のイベントをフィルタする
    • 「Linear 内の issue に対して NeedDoc ラベルをつける」イベントを受け取ってワークフローが発火する
  2. Linear から情報を集める
    • 3 で使うために issue 内のコメントなり description なりを取得している
  3. AI サマにお願いをする
    • Cursor Background Agents API に「良い感じにしてちょ」とお願いしている

という順で処理をしている。

最終的な n8n ワークフローの図

実際の動作

上のワークフローはお勉強用に建てた self-hosted な n8n 上で動かしており、練習がてらセルフホスティングの作業も Linear の issue にしていた。 いったん勉強がてら GKE を使っていたが、金かかりそうなんで普通に単一 VM にしました、ということについて、以下の雑な issue がある。

GKEではなく単一VM上でセルフホストする

GKE を使うとやはり kubernetes 運営上のコストが結構かかっており、単純に金の問題があるので。 一旦 e2-micro で動かし、場合に応じて自分で e2-small などに上げていきたい。 docker compose で動かしており、secure 通信には Caddy を用いた。 ここら辺、Caddy だのそもそも https だのよくわかっていないんで、どっかで勉強したくはある。

これはマジでコメントもなしで、この雑な description を作業後に書き足しただけだ。 が、まあやってる中で色々学んだことやら思ったことがあるわけなんで、やはり Obsidian に新しいページを作ったり、既存のページからリンクを張ったりしたい。

で、この issue に NeedDoc ラベルをつけると、なんやかやで Cursor Background Agents が起動し、以下のように頑張ってくれる。

AIサマにお願いする:Linear->Cursor

ところで、Linear には Cursor の公式 integration があります。 Linear では AI エージェント様を issue の担当者としてアサインできる。 Cursor を Linear 内で issue 担当者として扱う integration を使うと、大体上と同じようなことができる。 n8n とかいうのは使わなくて良いッス。

所感

コーディングエージェント様が便利すぎる。

基本的には コーディングエージェントとかいうやつが便利すぎる。 自分でファイルを検索してコンテキストに加えていってくれるんで、「関係ありそうなファイル探して文中リンク使って文章書いてね❤️」みたいなテキトーな指示が通るんでエラい。 なんで、脳のネットワーク置き場の中身によっては、コーディングエージェントをそのまま動かすのが強い。 Linear のようなナウいプロジェクト管理ツールは AI 様と仲良しする機能があるんで、その機能を使ってエージェント様を動かすのが良さそうだ。

コーディングエージェント様が無理な場合

根本的には、ナレッジ管理において「情報のネットワークに新しい経路を通す」を延々と続けて代謝を起こしたい。 ここで、自律的に色々操作できる生成 AI エージェントくんが延々と wiki を編集し続ける、みたいな仕組みは結構便利そうだ。 wiki が notion だったりなんだったりでややこしい場合はコーディングエージェント様直通では管理できないわけだが、このような場合に n8n など使って自前で何とかすると便利かもしれない。 n8n は "Building Custom AI Agents" がウリっぽいんで。

n8n.io

おわりに

今から弊社（ 株式会社 HERP ）への忠誠を再度示して、この文書を仕事にする。 弊社では現在、肥大化していくプロダクトの機能群、プロダクト間の連携、非機能要件のチーム間の連携など、ナレッジ管理が下痢ﾌﾞﾘなために混乱が生じる場面が増えてきている。 が、これは誰かが必要な情報を書くのをサボったという話ではなく、まだ誰もその観点で情報を探索していない という話かもしれん、と今回のひとり遊びで思った。

こういうのについて、何らかの観点で情報を調べて修正してまとめ直す を低コストでやれると嬉しく、現在は生成 AI サマがそこにアプローチできそうだ。 転じて、今までは「情報をまとめまくるくんを雇うわけにはいかないので、情報を生むときのルールを敷いていた」面もあるかもしれん、と思った。 今回は "情報を生むときのルール" 的な考えで 俺がなんかやるたびに「君！ページを作りたまえ！」を言ってくれる人 を作ったが、やはり 定期的に wiki をランダムに読みまくり、リンクを整理してくれる人 の方も整備していきたい。

また、ただのテキストファイル群 + コーディングエージェント という構成が、AI の自律的な情報走査という面で相当強い、というのも印象に残った。 今回は個人用の markdown 群が対象なんで、Cursor Background Agents が使えて簡単で最強だった。 一方、仕事的な場面ではもうちょい余計なものがついた wiki サービスを使う場合が多い。 このような場面では、その wiki サービスを使って十分自律的に動ける AI エージェントくんを作る必要があり、やや面倒かもしれん。 "やや面倒" に対しては n8n で簡易的なエージェントを組むというのが、取り組みの第一歩になりそうではある。 さすがっす。ボキも Linear と n8n はすごいなあ、と思いました。この文書仕事ってことで良いスか？あざす。