Mozilla.aiの“Show HN: Cq – Stack Overflow for AI coding agents”は、2026年3月23日にHacker Newsで137 points、48 commentsを集めた。注目された理由は、多くの開発者がすでに体感している問題を正面から扱っているからだ。コーディングエージェントはstale training data由来の失敗を何度も繰り返し、その場しのぎの修正を静的なrepo instructionへ押し込む運用が限界に近づいている。

Mozilla.aiが提示する cq は、エージェント向けのlocal-firstメモリ層だ。Claude CodeとOpenCode向けpluginが、ローカルSQLiteを使うMCP serverに接続し、初期状態ではknowledgeは開発者のマシン外へ出ない。チーム共有が必要な場合はAPI serviceとbrowser review UIを追加し、人間が“knowledge unit”を確認してから他のエージェントへ再利用させる。つまり、巨大なinstruction fileを増やすのではなく、運用中に更新されるworking memoryを作ろうとしている。

エージェントは unfamiliar work の前に commons を問い合わせ、役立つ発見をしたら新しい knowledge unit を提案する。
信頼は単一モデルの権威ではなく、confirmation、reuse、human review から得る設計になっている。
Mozilla.aiはこの仕組みを、単一vendor workflowの機能ではなく、openでcross-modelなstandard候補として位置づけている。

HNで面白かったのは、論点が「より強いモデル」ではなく「日常のagent workflowを忘れにくく、無駄を減らせるか」に置かれていたことだ。Mozilla.aiは、AGENTS.md や CLAUDE.md のようなrepo-level Markdownでは、GitHub Actionsのmajor version更新やAPI quirksのような細く変化の速い知識を扱いにくいと見る。その意味でshared memoryは、古くなり、見直され、再び信頼を獲得する“生きたシステム”になる。

エンジニアリング組織にとって、これは重要な設計転換だ。shared agent memoryが標準レイヤーになれば、競争力の中心はprompt trickではなく、モデル横断で持ち運べるoperational knowledgeの管理へ移る可能性がある。原典: Mozilla.ai blog、GitHub repo。コミュニティ議論: Hacker News.

#knowledge-sharing

Mozilla.aiのcq、コーディングエージェント向けStack Overflow型メモリ層としてHNで議論