2026年9月18日時点で、今日見ておきたいGitHub Repositoryを3件だけ選びました。今回は「社内ナレッジ基盤」「職種別AIの配り方」「回答そのものの設計」という3方向です。
| Repository | 何これ？ | 最短の入口 | 私の評価 |
|---|---|---|---|
| WeKnora ↗ | RAGからAgent・自動Wikiまで一体化した知識基盤 | Docker / Web UI | ★★★★★ |
| knowledge-work-plugins ↗ | 職種別のSkill・Command・Connectorを配る公式Plugin集 | Claude plugin | ★★★★★ |
| i-have-adhd ↗ | Coding Agentに「結論を埋めるな」と教える出力Skill | Plugin / Skill | ★★★★☆ |
1. WeKnora ↗：RAGを「検索箱」で終わらせない
結局何なのか
WeKnoraはTencentが公開しているLLM知識基盤です。PDFやOffice文書などを取り込み、RAGによるQ&Aだけでなく、ReAct Agent、MCP Tool、長期Memory、Wiki生成まで同じWorkspaceへまとめています。
現在のREADMEではv0.8.0が案内され、SkillをDocker / E2B / Cube sandboxで実行する仕組みや、複数WorkspaceのRBAC、監査Log、Langfuseによる観測まで含みます。単なる「Vector DBに文書を入れてChatするUI」より、かなり運用側へ踏み込んだ構成です。
技術的に面白いところ
面白いのは、RAG・Agent・Wikiを別製品として分けず、同じ知識の取り込みと権限境界の上に載せていることです。
特にWiki Modeは、検索結果を毎回その場で返すだけでなく、Agentが文書群からMarkdown Wikiを構成し、Revision HistoryやRollbackまで持たせます。「検索できる知識」と「育てる知識」を同じ基盤へ寄せる発想です。
最短で試す
入口は公式READMEのGetting StartedとDocker構成です。まずRepositoryをCloneし、.env を用意してDocker Composeで立ち上げるのが分かりやすいです。
LLMやEmbedding Providerは別途設定が必要です。Ollamaを含む複数Providerへ対応していますが、全部入りの機能を最初から有効化する必要はありません。まず小さなKnowledge BaseでQ&Aを試す方が構造を掴みやすいです。
注意点
本体はMIT Licenseですが、LICENSEにはthird-party componentごとの別Licenseが明記されています。再配布や組み込みでは本体のMIT表示だけ見て終わらせない方がよいです。
また、v0.8.0のSkill sandboxでDocker backendを使う場合、Docker socketへのアクセスは強い権限境界になります。公式docs自身もHostのDocker socketをContainerへ渡すことが実質的にHost root相当の権限を持つ点へ注意を促しています。機能が多い分、Production導入では「どこまで有効にするか」を先に決めたい基盤です。
私の判断
今日の実用枠です。
RAG製品は検索精度だけで比較しがちですが、実運用では権限、更新、観測、知識の修正、Agentの実行境界まで必要になります。WeKnoraはそこを一つの製品面として見せているので、採用しなくても「社内AI基盤に何が要るか」のChecklistとして読む価値があります。
2. knowledge-work-plugins ↗：AIを職種ごとに「配布可能な仕事の型」にする
結局何なのか
Anthropicのknowledge-work-pluginsは、Sales、Customer Support、Product Management、Marketing、Legal、Finance、Dataなど、知識労働の職種ごとにClaudeのPluginをまとめたRepositoryです。
2026年9月18日時点のREADMEでは11種類。各Pluginは単なるPromptではなく、Skill、Slash Command、Connector、必要に応じたSub-agentを一つのPackageとして持ちます。Claude Cowork向けが主ですが、Claude Codeでも利用できます。
技術的に面白いところ
重要なのは「賢いAgentを1体作る」より、職種ごとの業務契約をファイルとして配る方向へ進んでいることです。
Repository上の基本構造はMarkdownとJSON中心で、PluginごとにManifest、MCP接続、Command、Skillを分けています。つまり、モデルをFine-tuningするのではなく「どの知識をいつ使い、どのToolへ接続し、どの操作を明示Commandにするか」をVersion Controlできます。
最短で試す
Claude Codeでは公式READMEに次の手順があります。
claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install productivity@knowledge-work-plugins
まずproductivityなど外部Systemへの書き込みが少ない用途で構造を見るのが安全です。その後、自社のToolや用語、Processに合わせてSkillや.mcp.jsonを調整できます。
注意点
LicenseはApache-2.0です。ただし、Pluginが参照するConnector先はSlack、Notion、CRM、Data Warehouseなど外部Serviceです。RepositoryをCloneしただけで全機能が動くわけではなく、各Serviceの接続・権限・契約は別に必要です。
また、LegalやFinanceという名前でも、Pluginを専門家判断そのものの代替と見るべきではありません。ここで面白いのは「専門職の正解集」より、業務ContextとToolingをどうPackageするかという設計です。
私の判断
今日の技術トレンド枠です。
Agent開発の単位がPromptからSkillへ、さらに職種単位のPlugin bundleへ上がってきています。特定Vendorの形式ではありますが、「AI社員を作る」のではなく「仕事の型をRepositoryで配る」と考えると、他のHarnessにも移植できる設計上のヒントが多いです。
3. i-have-adhd ↗：Agentの能力ではなく「答えの見せ方」をSkill化する
結局何なのか
i-have-adhdは、Coding Assistantの回答をAction-firstにする小さなSkill / Pluginです。
READMEで掲げる規則は10個。「次のActionから始める」「複数Stepは番号を振る」「Tangentsを抑える」「最後に具体的なNext Stepを一つ置く」など、モデルのCoding能力ではなく情報の出し方を変えます。
技術的に面白いところ
変わり種に見えますが、設計上はかなり本質的です。
Agentの品質は「正しい答えを内部で持てたか」だけでは決まりません。長いPreambleや大量の補足で、実行すべき1行が埋もれればHuman-in-the-loopの速度は落ちます。このRepositoryは、そのInterface問題をPromptの好みではなく再利用可能なSkillとして切り出しています。
最短で試す
READMEではRepositoryを指定してPlugin / Skillとして導入する方法が案内されています。中核はskills/i-have-adhd/SKILL.mdなので、導入前にそこを読んで、自分のAgentへそのまま適用したい規則か確認するのが最短です。
ForkしてRuleを調整する運用も想定されています。
注意点
LicenseはMITです。
名前にADHDとありますが、これは医療的な治療・支援効果を検証したSoftwareとして紹介されているわけではありません。README自身も「ADHD diagnosis neededではない」とし、LLMのResponse Styleを変えるSkillとして説明しています。
また「Listを5項目まで」「Tangentsを抑える」といったRuleは、Security Reviewや複雑な設計判断では重要条件まで削る可能性があります。常時System Ruleにするより、用途に応じてActivationする方が安全です。
私の判断
今日の変わり種／発想枠です。
大規模なAgent Frameworkではありません。しかし「能力を増やすSkill」だけでなく、Humanが次に動きやすくするSkillも独立した価値を持つ、と分かりやすく示しています。Agent UXを考える材料として面白いRepositoryです。
3件を比べる
| Repository | 実用性 | 技術的な面白さ | 最短の入口 | 主な注意点 |
|---|---|---|---|---|
| WeKnora ↗ | ★★★★★ | ★★★★★ | Docker / 小さなKB | 多機能ゆえ運用境界が広い。Sandbox権限にも注意 |
| knowledge-work-plugins ↗ | ★★★★☆ | ★★★★★ | Pluginを1つ読む／入れる | Claude中心。Connectorの権限・外部契約は別管理 |
| i-have-adhd ↗ | ★★★★☆ | ★★★★☆ |
SKILL.mdを読む |
短文化Ruleが複雑Taskの重要条件を削る場合がある |
今日1件だけ見るなら
私は knowledge-work-plugins を見ます。
理由は、11個のPluginそのものより「Skill・Command・Connector・Sub-agentを職種単位でPackageする」という境界の切り方です。Agentを強くする方法がモデル変更だけではなく、仕事の構造をRepositoryへ落とす方向へ進んでいることが見えます。
WeKnoraはすぐ使える大きな製品として強く、i-have-adhdは小さなInterface設計として面白い。その間にあるknowledge-work-pluginsは、今後さまざまなAgent Harnessへ一般化しやすい設計材料として、今日いちばん読む価値があると判断しました。