ハクソク

世界を動かす技術を、日本語で。

Show HN: エージェントが管理するカーパシー風LLMウィキ（MarkdownとGit）

13時間前原文(github.com)

概要

  • WUPHFはAIエージェント用のコラボレーションオフィスを提供
  • 24時間稼働、1コマンドで即利用開始
  • ノートブック＋Wikiで知識共有と蓄積を実現
  • 多様なバックエンド・エージェント・アクションプロバイダーに対応
  • MITライセンス・オープンソース、セルフホスト・APIキー持ち込み方式

AIエージェントのための共有ブレイン型オフィス「WUPHF」

  • SlackのようなUIでAIエージェントが1つのオフィス空間に集結
  • CEO、PM、エンジニア、デザイナー、CMO、CROなど、役割ごとにエージェントを可視化
  • 全員が議論・タスク主張・成果物提出をリアルタイムで行うコラボレーション体験
  • APIの裏側に隠れず、作業状況が常に見える化
  • WUPHF.com（The Officeネタ）の実用版として動作
  • 24時間365日稼働、1コマンドで即オフィス起動

導入手順・前提条件

  • エージェントCLIが必要（デフォルトはClaude Code、--provider codexでCodex CLIも可）
  • tmux（--tuiモード用）、Web UIはデフォルトでヘッドレス起動
  • コマンド一発：npx wuphf で自動的にブラウザが開き、オフィス参加
  • グローバルインストールも可能：npm install -g wuphf && wuphf
  • ソースからのビルドも対応（Goが必要）：git clone → go build
  • フォーク・リブランド・独自エージェントパック追加も容易（FORKING.md参照）

メモリ：ノートブックとWikiによる知識管理

  • 各エージェント専用ノートブック、チーム全体で共有するWikiを実装
  • Wikiはローカルgitリポジトリ（~/.wuphf/wiki/）として管理、cat/grep/git clone等も利用可能
  • ノートブック→Wikiへの昇格フロー：再利用可能な知識のみ昇格、エージェントが昇格タイミングを判断
  • Wikiは知識グラフとして機能：エンティティごとのファクトログ、LLMによる要約、矛盾・孤立・リンク切れ検出
  • バックエンド選択肢：markdown（デフォルト）、nex、gbrain、none（Wiki無効）

オプション・コマンド

  • --memory-backend <name>：組織メモリバックエンド選択
  • --no-nex：Nexバックエンドをスキップ
  • --tui：tmux TUI利用
  • --pack <name>：エージェントパック選択
  • --opus-ceo：CEOをSonnetからOpusにアップグレード
  • --provider <name>：LLMプロバイダ指定
  • --collab：コラボモード起動（デフォルト有効）
  • --web-port <n>：Web UIポート変更
  • wuphf init / shred / --1o1：初期化・セッション終了・1:1チャット

外部連携・アクション

  • Telegramブリッジ：/connectコマンドで双方向連携
  • OpenClawブリッジ：既存OpenClawエージェントのオフィス参加
  • アクションプロバイダー：ローカルCLI（デフォルト）またはComposio（クラウド連携）を選択
  • エージェントによるメール送信・CRM更新等も対応

WUPHFの特徴とベンチマーク

  • 毎ターン新鮮なセッション、履歴蓄積なし
  • エージェントごとのMCPツールスコープ、DM時は4ツール、フルオフィス時は27ツール
  • プッシュ駆動型エージェント起動、アイドル時リソース消費ゼロ
  • Claude Code・Codex・OpenClaw混在利用可能
  • ノートブック＋Wikiの知識管理（GBrain/Nex連携も可）
  • MITライセンス・無料・セルフホスト
  • ベンチマーク例：10ターンCEOセッションで87kトークン/ターン、97%キャッシュヒット率、$0.06/5ターン

Wikiレイヤーの詳細

  • Markdown＋gitをソース・オブ・トゥルースとし、Bleve（BM25）＋SQLiteでインデックス構築
  • エージェントごとにプライベートノートブック、チームで共有するWiki
  • ドラフト→Wiki昇格フロー、状態管理と自動アーカイブ
  • エンティティごとのファクトログ、要約生成は「Pam the Archivist」名義でコミット
  • [[Wikilinks]]サポート、リンク切れ検出・赤色表示
  • 日次Lintで矛盾・古いエントリ・リンク切れを自動検出
  • /lookupコマンドでBM25検索と引用付き回答
  • SQLiteでメタデータ管理、ベクトルDB未実装（必要ならsqlite-vecで拡張可）
  • カノニカルID管理、スラッグの一意性・マージ・リダイレクト
  • 単一オフィス内での動作、クロスオフィス連携は未対応

まとめ・評価ポイント

  • WUPHFはAIエージェント向けの次世代コラボレーション基盤
    • ノート＋Wikiで知識の蓄積・共有・再利用を実現
    • APIに隠れない、可視化されたAIチームワーク
    • プラグイン的に既存エージェントセットアップへWikiのみ追加も可能
  • オープンソース・MITライセンス、セルフホスト/カスタマイズも容易
  • 導入コマンド：npx wuphf@latest
  • 詳細・デモ・ソース：https://github.com/nex-crm/wuphf
  • Wiki設計・昇格フロー・BM25優先戦略など、技術的な深掘りも歓迎

Hackerたちの意見

Karpathyの元の投稿の文脈: https://x.com/karpathy/status/2039805659525644595 https://xcancel.com/karpathy/status/2039805659525644595
メモを自動化する意味がわからない。テキストをコピーしてノートに貼り付けるのは全然うまくいかなかったし、今はそれを100倍にするの？私にとってメモを取る意味は、情報源を批判的に読むこと、自分のメンタルモデルに当てはめること、そしてそれを記録することなんだ。時々、詳細を調べるけど、メンタルモデルを形作ることが一番大事だと思ってる。
└
いくつかの科学的研究では、これらのマークダウンコレクションが完全にLLMによって管理されると出力品質が低下することが示されていて（人間が管理する場合は逆に向上する）、それが面白いと思った。これらの文書は人間がキュレーションするのがベストだと思うけど、無監視の管理は決して答えではない、特に負債やドリフトについて意識的に考えないときは。
└
AIを使って膨大な雑務をやらせて、その後一度も見返さない人が多いのは深刻な問題だと思う。ものすごい無駄。
└
まず、これは単なるメモ取り以上のものだよ。人間の介入を最小限にしてエージェント間の作業を調整するための（また別の）ハーネスのように見える。だから、メンタルモデルを自分で構築する必要がないっていうのがポイントの一つじゃないの？むしろ共有されたLLMの「脳」にオフロードするべきだと思う。これで本当に価値のあるもの（製品のオーナーにとって価値があるもの）を作ることができるかどうかは大いに議論の余地があるけど。プロンプトとエージェントのハーネスだけで価値のある製品を作ることができるとは思えない。その時点で、製品自体は誰でも（再）作成できるようになって、製品開発はコモディティ化されて、唯一の価値はトークンだけになる。私の仮説は、「スケールしないことをする」[0]が将来も引き続き当てはまるだろうけど、「スケールしないこと」の内容は変わるだろうということ。そうは言っても、私は最近、ノート取り、リサーチ、リンク、分割、知識ベースの再構成のためのスキルを設定した後、ついにObsidianを使い始めた。構造を維持するための時間をかけたことはなかったけど、今は自分が怠けてできない作業をすべてやってくれるデジタル秘書がいる。ランダムな考えやアイデアをメモしておくだけで、エージェントがそれを構造化してくれたり、フォローアップの質問をしてくれたり、他の進行中の作業に関連付けてくれたりする。情報源を読むことやメンタルモデルを構築する作業はまだしてるけど、ほぼ無料で高品質なノートが得られてる。[0]: https://www.paulgraham.com/ds.html
└
2月末から「LLMがウィキを書く」バリエーションを運営してる。Fly.ioのsprites.devで動かしてて、公開はしてるけど特に宣伝はしてない。完全にClaudeでバイブコーディングした。アプリ側とコンテンツの両方をね。アプリ側は他のエージェントインスタンスにコンテンツをアクセス可能にして、ルートにいくつかのドキュメントをリストし、検索機能を提供して、ブラウザで読みやすいタイポグラフィで表示できるようにしてる。生のマークダウンではなくてね。すごく便利で、新しいスプライトや何かを作成して、Claudeをルートに向けて、zswapを設定するように指示すると、その環境でどうやってやるかを正確に知ってる。何かが変わって、動作させるために調整が必要な場合は、レポートを書いて既存のドキュメントに統合するように頼むこともできる。
└
返信する意味がないよ。人間じゃない相手と議論してるから、会話には意味も影響もなくて、時間とエネルギーの無駄だよ。
└
最初はこれがパロディだと思ったよ。無駄な製品の名前が、同じ名前の無駄な製品（Wuphf.com）から取られてるからね。
└
メモ取りについては全く同意だね。私たちはメモを軽視しすぎてる。屋根裏部屋や地下室が物を溜め込む原因になるみたいに。ほとんどのことはメモに残す必要がないし、LLMはノイズを増やしすぎる。自分が確認したりフィルターしたりすることはほとんどないからね。JA Westenbergが数日前にいい動画エッセイを作ってたよ： https://youtube.com/watch?v=3E00ZNdFbEk
└
同感だね。結局のところ、これはLLMに任せるほど重要じゃないのか？っていう質問に戻るよね。もし答えが「はい」なら、そもそもやる意味がないし、答えが「いいえ」なら手動でやらなきゃいけない。個人的には、この種の自動化には価値があると思ってる。タグの分類やインデックス作成みたいな、そうでなければ失われてしまうものはLLMに向いてる気がする。理想的な解決策かどうか、他の検索エンジンの方が良かったのかは別の話だね。
└
同じことを考えてたけど、メモとスロップを明確に分けることができると思うよ。例えば、すべてのメモをチェックして簡単に勝てるところがあればPRを作るようなcronジョブみたいなもの。最近はこういう風にコーディングしてる：新しい非クリティカルなセクションやユニットテストをレビューするのが面倒なときは、`// SLOP`ってマークしておく。後で必要があれば全体を見直して、クソテストよりはマシだから、期待値を低めに設定しておけば大丈夫。
製品名にAIを入れれば、億万長者になれる。ブログ記事にKarpathyを入れれば、Anthropicに主任エンジニアとして雇われる。流行が続く限りお金を搾り取る。誰も顧客のニーズを考えてないし、みんな波に乗ろうとしてるだけ。
└
NFTやブロックチェーン、さらにはWeb 2.0の熱狂に似てるよね（あの時は少なくとも何かを作ったし、資金調達も厳しかったから抑えられてたけど）。このLLMの技術は、実際に可能性と価値があって、学んだり遊んだりするのがすごく楽しい。倫理的でない限り、儲けられるってことをずっと前に受け入れたから、関わっていきたいな。価値のあるクールなものを作りながら、VCやPEのお金が動いてるのを楽しめるしね。
└
そうだよね、動くものは動く。みんながAIツールを作ってる理由があるんだよ。みんなそれを買ってるし。誰かがClaude Codeの代わりになる世界クラスのCLIハーネスを作って、メモリやデザインの問題を解決してくれるのを待ってる。LLMを使ったウェブデザインはまだまだ悪夢だよ。
└
わかりました、サー/マーム/どちらでもない方。去年、これの前にHubSpotの創業者ダーメシュ・シャーの支援を受けてAIネイティブのCRMを作ったんだ。収益も上がって、コンテキストグラフのインフラに焦点を当てるように進化させて、企業向けのPoCもやった。それが自分の仕事を助けるために作った個人プロジェクトに集約されたんだ。コンテキストインフラを使いやすくするための正しいインターフェースになったみたい。Anthropicでのプリンシパルエンジニアの仕事には興味ないよ（以前はHubSpotのプロダクトマネージャーで、今よりずっと良い収入を得てたから）。いくつかの賭けをして、顧客と話しながら進化させてきたから、古い競合はまだ「ステルス」でAI CRMを作ってるけどね。波がどうであれ、価値を引き出すべきものはまだあるって知ってる。
自己構築するアーティファクトの領域は面白くて、最近のLLMのバージョンがそれにどんどん適応してきてるから、今は盛り上がってる。特に「コーディング」系のやつね。最近、依存関係を最小限に抑えつつ、エージェントをローカルで制御するプロジェクトを試してみた。プロンプトで与えられた長期的なタスクを遂行するために、自分のSQLiteデータベースを構築・整理していて、ローカルのWikipediaコピーにアクセスしてデータを得てる。エージェントのドリフトを実験するための最小限のハーネスとツールを使ってる。画像処理ツールをこのフレームワークに追加するのも簡単だし（base64でエンコードして、llama.cppに渡すだけ）、便利で多用途なツールだよ。例えば、以前は請求書や領収書を処理するスクリプトを使っていて、Amazon Textractを使って金額や日付、ベンダーを抽出してた。今は、既存の請求書ツールを使いながら、Amazon Textractのリクエストをllama.cppモデルの呼び出しに置き換えられるし、プロンプトを使うことでよりクリエイティブな会計ができるようになった。カメラの画像のシーケンスから物理ロボットを動かすためのこのコードのバリエーションも試してみたけど、簡単なケースでは動いて目標に到達するものの（使ってるLLMはロボットを運転するために明示的に訓練されてないけど）、実用的には遅すぎる（次のアクションを選ぶのに10秒かかる）。今使ってるディープラーニングを使わないコントローラーは、視覚処理ループを20Hzでやってる。[0]https://github.com/GistNoesis/Shoggoth.db/
マークダウンを使ってるみんなに、leafっていうターミナルのマークダウンプレビューアーを紹介したいな： https://github.com/RivoLink/leaf
レビューしたよ： https://zby.github.io/commonplace/agent-memory-systems/revie... 24時間でフロントページに載った第三のLLMウィキだね！明らかにホットな話題だ。自分もこのレースに参加してるから、客観的ではないかもしれないけど、このシステムのためにウィッシュリストをまとめたよ： https://zby.github.io/commonplace/notes/designing-agent-memo... みんなが自分のシステムをコーディングしてるのを見ると、協力のチャンスがあればいいのにって思う。努力の重複が多すぎる気がする。
└
見てるよ :)
└
あなたのメモ、すごく興味深いね、ありがとう。気になるんだけど、文体から見るとLLMが書いたのは明らかだね。こういうデザインノートについては、自分の言葉で書き直すためのメンタルTODOリストみたいなものがあるの？
└
「借りられるアイデア」セクション、めっちゃ好き。絶対に借りることをおすすめするよ。全てを正直に言うと、私たちはKarpathyがLLMウィキのアイデアを思いつくずっと前からコンテキストインフラの会社（nex.ai）を始めて、WUPHFにはほとんどその情報を公開していなかったけど、今少しずつ開放し始めてる。比較の中での懸念が、私たちのコンテキストインフラがすでに対処していることを見て嬉しいよ。それでも、コラボして学びを共有するのは大歓迎だし、もちろん重複は避けたいね。
└
そうだね、生成型スロットマシンは孤独を感じさせる。君は「チャンスがあればいいのに」って言ってるけど、そんなのないの？
「ゴミの情報が入れば、ゴミの要約が出る」という警告は、強調したい部分だね。自分のLLM機能では、人間の目が入らないとエージェントが書いた内容が一番早く劣化する。6ヶ月後には、自信満々に間違ったエントリーができてて、リントパスがどれが間違ってるかも分からない。昇進のフローには人間のレビューが必要なのか、それともエージェントが自己昇進できるのか？
誰かがこれを解決するために、StackOverflowの復活版を作るべきだと思う。人間がキュレーションした分散型知識グラフで、集団的なLLMが問題解決に取り組みながら、昔ながらの方法で質問をする感じ。自分のエージェントが「ここで壁にぶつかったよ、これがSOに投稿された質問だ。答えが出たら後で戻ってくるようにフラグを立てておくね」って言ってくれるなら、全然オッケー。
ちょっと考えを刺激するために言うけど、TiddlyWikiコミュニティ（自己修正型の単一HTMLファイルのウィキ、もう20年以上の歴史がある）がAIツールの探求をしてるのはもちろんだけど、必ずしもエージェント環境としてではないんだよね。マークダウンプラグインもあるし、ファイルを実行可能にしたり、自給自足のウェブアプリにしたりするプラグインもある。Gitはちょっと問題が多いけど。仮に、単一ファイルのエージェント型ウィキが自分で歩き回って自己編集するっていうのもあり得るかもね。
アイデア自体はいいと思うけど、システムには各ファイルのイテレーションに対するスナップショットやデータの強化が欠けてるんだよね。もしコードが壊れたりバグがあったりしたら、エージェントがコードをロールバックして、その理由を説明する強化を生成することで、新しいスナップショットを作成できるはず。もう一つの問題は意見の重みなんだけど、オペレーティングシステムの制作中に整合性と一貫性をどうやって保証するの？衝突やビジネスルールの違反を避けるためにはどうするの？それと、持続的なメモリについてだけど、今のところあなたのシステムは時間的メモリと非時間的メモリ（ビジネスルール、ソフトウェアの挙動や機能、セキュリティポリシー、エージェント間のガバナンス）を区別してないよね。アイデアはいいけど、チームとして機能するためにはこれも考慮しないといけないね。