プロジェクト単位のナレッジ管理（後編）
この記事は、研究室AI基盤の構築シリーズの第４回です。
- 第1回：研究室で管理しやすい学生用AIハブの導入
- 第2回：カスタムモデルで「良いAI活用方法」を埋め込む
- 第3回：プロジェクト単位ナレッジ管理のコンセプトとインデックス機能の実装
- 第4回：プロジェクト単位ナレッジ管理の検索・登録機能の実装（⇦いまここ）
- 第5回：もう一つのナレッジとしてのAIエージェント（次回予定）
- 第6回：ユースケース：引き継ぎ資料の作成支援AIとプロジェクトナレッジとしての利用（最終回予定）
第３回は、プロジェクトナレッジ自作の前編として、フリーズ済みプロジェクトをフォルダ構造ごとナレッジ化する考え方と、それをQdrantへ登録するindexerを紹介しました。
後編では、そこにMCPによる検索・原本参照・登録機能を加えたfilesystem-knowledge-bridge（以下、FKB）v0.2.1を題材に、プロジェクトナレッジを実際に使うための考え方と運用方法を紹介します。
1. はじめに
前回の記事では、フリーズ済みプロジェクトをナレッジとして管理するという考え方と、それをQdrantへインデックス化する FKB v0.1.0 を紹介しました。
その後、このナレッジの検索・閲覧と、登録方法について検討し、MCP（Model Context Protocol）による検索・閲覧機能、および登録機能を追加した FKB v0.2.1 として整理しました。FKBのリポジトリはこちらです。
本記事では、個々の実装やAPIの説明ではなく、
- なぜプロジェクト単位で検索するのか
- なぜ登録方法をここまでシンプルにしたのか
- どのような運用を想定しているのか
という、設計の考え方を中心に紹介します。さらに、
- AIチャットから利用する方法
- AIエージェントから利用する方法
- 小規模チーム向けの運用方法
まで含めて、プロジェクトナレッジを実際に活用するための構成をまとめています。
実際の導入手順や設定方法については、本記事後半およびGitHubリポジトリのREADMEを参照してください。
2. 全体コンセプト
前編では、プロジェクトをどのような単位でナレッジ化するかについて考えました。
一般的なRAGでは、社内Wikiやファイルサーバ全体を一つのナレッジとして扱い、「とりあえず全部検索する」という使い方が多く見られます。一方で、ソフトウェア開発や研究活動では、相談したい対象は最初からある程度決まっていることがほとんどです。
例えば、
- 研究室でのNodeREDの利用事例について相談したい
- Open WebUIの設定方法を知りたい
- 昨年の研究プロジェクトを参考にしたい
というように、「どのプロジェクトについて相談したいか」が先に決まっているケースが多くあります。そこでFKBでは、プロジェクトを単位としてナレッジを管理することを基本方針としています。
また、FKBは、ナレッジ管理システムそのものを作ることを目的としていません。既存のナレッジ管理システムの多くは、認証や権限管理、WebUI、ワークフロー、監査ログなど、多くの機能が含まれますが、それらを一つのプロジェクトで実現しようとすると、システムは急速に複雑になってしまいます。
そこで FKBは 「プロジェクトをAIへ橋渡しする」ことだけに責務を限定します。具体的には、FKBが担当する機能は次の3つだけです。
- プロジェクトの検索
- 必要に応じた原本参照
- プロジェクトの登録
それ以外のユーザー認証、WebUI、ファイル管理、ワークフロー、ジョブ管理などの機能は、既存のシステムへ任せることを前提とし、シンプルで軽量なブリッジとなることを目指しています。
詳細は、リポジトリのREADMEやソースコードをみてもらうとして、FKB は、大きく次の３つのサービスからなります。
- Knowledge Read MCP
- Knowledge Register MCP
- Knowledge Upload API
以下、これらの使い方を、その考え方とともに紹介します。
3. FKBの使い方
注意 :FKBの個人ナレッジ、所有者、ownerの概念は、あくまで対象範囲を限定して検索の精度・効率をあげるための機能です。他のユーザから見えないようにするという権限ではありません。aliceのナレッジも含めて検索してと問い合わせれば参照可能なので注意してください**
簡単な登録と検索だけなら、前回紹介したようにCLIのkb-indexとkb-searchで使うことができます。今回は、MCPとしてAIと連携して使う方法を紹介します。FKBは、ベクトルDBのQdrant以外に依存関係がないように設計しているので、好きなAIツールと連携して使うことができるはずですが、OpenWebUIとの連携のみテストをしています。ここでは、OpenWebUIと連携した時の使い方について紹介していきます。
なお、OpenWebUI自体の導入についてはこの記事シリーズの第１回または他のインストール紹介記事を参照してください。また、FKBのサービスを立ち上げる方法は、リポジトリのREADMEやINSTALLを参照してください。
3.1. MCPサービスの登録
まず、Open WebUIから個人ナレッジを自動的に検索対象へ含めるには、Open WebUI側で利用者情報をMCPに伝える必要があります。それにはMCPへの問い合わせ時にヘッダーの転送を有効にしておきます。
docker-compose.ymlのopen-webuiサービスのところで、次の設定を加え、再構築しておきます。
environment:
ENABLE_FORWARD_USER_INFO_HEADERS: "true"
この設定が有効な場合、FKBはOpen WebUIから転送されたユーザー名をownerとして利用し、sharedナレッジと本人のpersonalナレッジを検索します。
利用者情報を取得できず、ownerも明示されなかった場合は、sharedナレッジだけを対象とし、その旨をToolの結果へ返します。
再起動したら、次にMCPサービスを連携できるように設定します。
OpenWebUIに管理者アカウントでログインし、管理者パネル（Admin Panel）から、設定（Settings）→連携（Integrations）を選択し、External Tool Servicesのところの＋アイコンで接続を追加（Add Connections）を選びます。すると接続の編集画面が表示されるので次のように設定します。
- 名前：Knowledge Read
- ID: knowledge-read-mcp
- URL: http://knowledge-read-mcp:8000/mcp
- 認証：なし
- アクセス権：使う人のアカウントかグループを設定
名前やIDは、好きな名前を設定すればいいです。URLはDocker内部のネットワーク名です。これは検索・閲覧のサービスです。続いて登録のためのサービスを設定します。同様に接続を追加（Add Connections）で次のように設定します。
- 名前：Knowledge Register
- ID: knowledge-register-mcp
- URL: http://knowledge-register-mcp:8001/mcp
- 認証：なし
- アクセス権：使う人のアカウントかグループを設定
使う場合には、チャットの入力欄下のアイコンでツールを選んで、使いたいサービスをオンにします。
いちいちチャットごとにオンにするのが面倒な場合は、カスタムモデルの設定でツールとして設定しておくといいでしょう。
図のようにツールの下のSearch Toolsにカーソルを持ってくると候補が表示されるので、ここから選択しておきます。
3.2. プロジェクトを探し、限定して検索する
一般的なRAGでは、ナレッジ全体を検索対象とすることがほとんどです。社内Wikiや文書管理システムでは、「必要な情報をどこから探してくるか分からない」ということも多いため、まずは全体を検索するという考え方は自然です。しかし、誰々先輩の卒論プロジェクトを参照したい、研究室でYOLOを使ったプロジェクトを調べたい、姿勢推定をやってた研究はどれだっけ？というように、相談したい対象は最初からある程度限定されていることがほとんどです。これを最初から「全部検索」すると、プロジェクトが増えてくると、
- 関係のないプロジェクトまで検索してしまう
- 同じような名前や実装が混ざる
- トークン消費が増える
といった問題が発生します。そこで FKB では、 まず話題にしたいプロジェクトを決め、そのプロジェクトだけを検索するという使い方を基本に考えました。つまり、Collection （＝ナレッジに登録したプロジェクト）を単なる保存単位ではなく、AIが検索対象を限定する単位として利用します。
FKB では、ナレッジの検索と閲覧は Knowledge Read MCP サービスで実現します。このサービスは次の３つの機能をもっています。
- list_knowledge_projects: 共有およびownerで指定した個人プロジェクトを列挙
- search_knowledge: 共有および個人プロジェクトを横断で、またはプロジェクトを限定して検索
- read_knowledge_source: プロジェクトの原本のファイルを取得
これらの機能で、プロジェクトを検索し限定し、必要なら原本を見るという流れを確認していきます。
もちろん、最初からプロジェクト名を覚えているとは限らないので、最初は話題にしたいプロジェクトを限定せずAIに相談していきます。試しに今参照できるプロジェクトを列挙してみましょう。
参照できるプロジェクトを列挙して
とAIに問いかけると ** list_knowledge_projects ** 機能によって、プロジェクト一覧とその説明を出力します。
前回kb-indexで登録したサンプルプロジェクトと、前もって登録しておいてFKBのプロジェクトが列挙されています。
しかしこれはタイトルとメタ情報を列挙しているだけで、これで参照したいプロジェクトを探して限定するのは難しいです。
プロジェクト横断検索からの絞り込み
そこで、プロジェクト横断検索によって自然にプロジェクトを検索し、絞り込んでいきます。
例えばまず、AIに
「LIDARに関連するプロジェクトを教えて」
と尋ねます。すると、 search_knowledge機能が呼び出され、関連しそうなプロジェクトを検索します。
その結果学生Bの引き継ぎ資料が関係しそうだということがわかります。その上で関連資料としておいてあるプログラムコードの情報も返してくれます。
プロジェクトが一つに絞りきれない場合は関連のありそうなプロジェクトを複数列挙してくるので、〇〇のプロジェクトについて相談したいといえば、プロジェクトを特定できます。
プロジェクト内のファイルを横断した相談
プロジェクトが特定できたので、次に、このプロジェクトについての相談をします。例えばこれが引き継ぎ資料だとして、どこをどう追いかけたらいいのかわからないので、卒論にそってプログラムを解読したいと思います。そこで、
卒論とプログラムを比較して、卒論の実験結果を理解するために、どのプログラムをどの順番で読めばいいか教えて。
と問いかけてみます。
長いので一部だけ抜粋しています。
必要になったら原本を読む
通常はチャンク検索だけで十分ですが、ソースコードや設定ファイルなどは前後の文脈も重要です。
そのため、FKB では、検索結果だけで判断できない場合に限り、MCP経由で原本を参照できるようにしています。
床面推定について気になったので、そのプログラムであるcam.test07.pyについてさらに詳しく聞いてみます。
read_knowledge_source の機能によって１個１個のファイルを読み込んで分析しています。
ただ卒論PDFについては、indexerが対応していない形式だったようで、その点については改めて情報を送るようにいわれています。
このように、最初から大量のファイルをAIへ渡すのではなく、必要になったときだけ原本を読むという設計にすることで、検索精度とトークン消費のバランスを取っています。
AIエージェントでは指示書に記載
CLIやチャットでは会話の中でプロジェクトを指定できますが、AIエージェントではエージェント指示書で対象となるプロジェクトを指定しておきます。Claude Code や Cline など、多くのAIエージェントには、Agent.md のような「エージェントへの指示書」があります。そこへ、
Knowledge Projects
- filesystem-knowledge-bridge
- PyNode
のように参照するプロジェクトを書いておけば、以後の検索対象は自動的にそのプロジェクトに限定されます。これによって、毎回検索対象を指定する必要がなくなり、より自然な形でプロジェクトナレッジを利用できます。指示書に記載するプロジェクトは事前にチャットの会話でAIに探させておきます。
3.3. プロジェクトをナレッジに登録する
ナレッジ登録に対する考え方
検索対象をプロジェクト単位で限定するという考え方が決まると、次は「そのプロジェクトをどう登録するか」という問題になります。この部分は権限、シンプルさ、使いやすさで一番試行錯誤が必要でした。最終的には、**「フリーズ済みプロジェクトをナレッジとして登録する」**を実現することだけに絞り、できるだけシンプルな方法で実現できるように考えました。登録の流れは次のとおりに考えました。
ここで、権限とかセキュリティとかを考えるとどんどん複雑化するので、研究室内部のネットワークに限る（あるいはOpenWebUIのユーザに限る）、内部ユーザは信用するというように割り切り、所有者の概念も、単に検索範囲を限定するための情報として扱うことにしました。
ただ、ここで重要なのは、ついうっかり消しちゃうような事故を防ぐために登録した原本は自動削除しないということです。そのために、保存済み原本は一度登録すると上書きも削除もしません。どうしても削除したい場合は、直接ファイルシステムから手動で削除します。一方で、Qdrantのインデックスは再構築可能なデータとして扱い、必要に応じて削除・再インデックスできる、という設計にしました。
シンプルさを優先
さらに、複数で使うシステムとして、登録機能を考えると
- ジョブキュー
- 同時登録
- 差分更新
- バージョン管理
- 削除
- ロールバック
など、さまざまな機能を追加したくなります。これも、登録頻度はそんなに高くないはずなので、思い切って
- 同時登録はエラーを返す
- 削除は管理者が行う
- 上書きは自動で行わない
という、意図的にシンプルな仕様にしました。
UIは既存ツールを利用
登録のUIについても自作するのはやめて既存ツールから登録が行えるように登録用のMCPだけ用意しました。既存ツールから登録したり、後で専用UIを作成したりできます。
ただ、標準の登録方法がないと不便なので、OpenWebUIのAIチャットを使って登録できるような設定例をつけておきました。
Open WebUIによる登録の例
登録には Knowledge Register MCP サービスと、Knowledge Upload APIサービスを使います。前者はincomingフォルダにおいたプロジェクトを、原本フォルダにコピーしてインデックスをQdrantに登録する機能で、後者はincomingフォルダにファイルをアップロードする機能です。どちらもDockerネットワーク内部の他のツール（今回の場合はOpen WebUI）からアクセスすることを前提に、Docker外部にポートを公開せず、認証も行いません（Open WebUIの認証に頼る）。
Open WebUIからの登録は、登録専用のカスタムモデルを作成して実施します。実は専用モデルじゃなくても可能ですが、誤登録を避けるためには専用モデルのほうが向いています。
ファイルアップロードのAPIだけはMCPのサービスになっていません。これは現在の構成でMCP Toolの引数としてファイル本体を渡す場合、base64などでテキスト化する必要があり、大きなファイルの転送には向いていないためです。登録したいプロジェクトファイルそのものは、直接（NFSマウントやSMBマウントした）incomingフォルダに直接コピーするか、Knowledge Upload APIでアップロードします。
Knowledge Upload APIは、AIのTool機能で使うことを想定したUIも何もないシンプルなREST APIです。Open WebUIから利用するためには、まずToolでこのAPIに添付ファイルをアップロードします。管理者でログインし、WorkspaceのToolから新しいツールを作成します。ここに次のようなプログラムを指定します。（このプログラムはリポジトリのopenwebui/knowledge_uploader_tool.pyという名前で置いてあります）。
"""
title: Knowledge Project Uploader
author: filesystem-knowledge-bridge
version: 0.1.0
required_open_webui_version: 0.10.0
requirements: httpx>=0.27
"""
from __future__ import annotations
from pathlib import Path
from typing import Annotated, Any
import httpx
from pydantic import BaseModel, Field
class Tools:
"""Open WebUIの添付ZIPをknowledge-upload-apiへ転送するTool。登録処理は行わない。"""
class Valves(BaseModel):
upload_api_url: str = Field(
default="http://knowledge-upload-api:8002",
description="filesystem-knowledge-bridge uploader APIのURL",
)
uploads_root: str = Field(
default="/app/backend/data/uploads",
description="Open WebUIコンテナ内のアップロード保存ディレクトリ",
)
timeout_seconds: int = Field(default=300, ge=1, le=3600)
def __init__(self) -> None:
self.valves = self.Valves()
@staticmethod
def _file_record(item: dict[str, Any]) -> dict[str, Any]:
record = item.get("file") or item.get("files")
if not isinstance(record, dict):
raise ValueError("添付ファイル情報を取得できません")
return record
@staticmethod
def _owner(__user__: dict[str, Any] | None) -> str:
if not __user__:
raise ValueError("Open WebUIのユーザー情報を取得できません")
name = str(__user__.get("name") or "").strip()
if name:
return name
email = str(__user__.get("email") or "").strip()
if email and "@" in email:
return email.split("@", 1)[0]
raise ValueError("ownerへ変換できるユーザー情報がありません")
def _path(self, record: dict[str, Any]) -> Path:
file_id = str(record.get("id") or "")
filename = str(record.get("filename") or "")
if not file_id or not filename:
raise ValueError("添付ファイルのIDまたはファイル名がありません")
path = Path(self.valves.uploads_root) / f"{file_id}_{Path(filename).name}"
if not path.is_file():
raise FileNotFoundError(f"添付ファイルの実体が見つかりません: {path}")
return path
async def upload_project(
self,
project: Annotated[
str,
(
"ユーザーが指定したproject名を一字一句変更せず渡してください。"
"日本語、空白、アンダースコア、ハイフンを保持し、短縮・要約・翻訳しないでください。"
"未指定の場合だけ空文字列を渡してください。"
),
] = "",
__files__: list[dict[str, Any]] | None = None,
__user__: dict[str, Any] | None = None,
__event_emitter__=None,
) -> str:
"""添付された1個のZIPをincomingへアップロードします。
このToolはアップロードと展開だけを行い、登録・インデックス作成は行いません。
添付ファイルがない場合は呼び出さないでください。
成功後は、同じownerとprojectを使ってRegister MCPの
register_incoming_projectを呼び出してください。
projectを省略した場合はZIPファイル名から推定します。
"""
files = __files__ or []
if len(files) != 1:
raise ValueError("ZIPファイルを1個だけ添付してください")
record = self._file_record(files[0])
filename = str(record.get("filename") or "")
if not filename.lower().endswith(".zip"):
raise ValueError("ZIPファイルを添付してください")
project_name = project.strip() or Path(filename).stem
owner = self._owner(__user__)
file_path = self._path(record)
if __event_emitter__:
await __event_emitter__(
{
"type": "status",
"data": {
"description": "ZIPをincomingへアップロードしています...",
"done": False,
},
}
)
async with httpx.AsyncClient(timeout=self.valves.timeout_seconds) as client:
with file_path.open("rb") as source:
response = await client.post(
f"{self.valves.upload_api_url.rstrip('/')}/uploads/projects",
data={"owner": owner, "project": project_name},
files={"archive": (filename, source, "application/zip")},
)
if response.is_error:
detail = response.text
try:
detail = response.json().get("detail", detail)
except Exception:
pass
raise RuntimeError(
f"アップロードに失敗しました ({response.status_code}): {detail}"
)
result = response.json()
if __event_emitter__:
await __event_emitter__(
{
"type": "status",
"data": {
"description": "incomingへのアップロードが完了しました",
"done": True,
},
}
)
return (
f"アップロード完了: owner={result['owner']}, project={result['project']}, "
f"incoming_path={result['incoming_path']}。"
"続けてRegister MCPのregister_incoming_projectを同じowner/projectで呼び出してください。"
)
登録専用のモデルは、Workspaceのモデルから作成し、knowledge-register-mcpと上のToolを使えるようにTool Searchから設定した上で、次のようなシステムプロンプトを設定します。
あなたはfilesystem-knowledge-bridgeの登録専用アシスタントです。
プロジェクト登録の依頼を受けたら、次の規則に従ってください。
1. 添付ZIPがある場合
- upload_projectを呼び出してincomingへ配置する。
- アップロード成功後、返されたownerとprojectを使って
register_incoming_projectを呼び出す。
2. 添付ファイルがない場合
- 指定されたprojectがincomingにあるものとして
register_incoming_projectを呼び出す。
3. project名が省略され、ZIPが添付されている場合
- ZIPのファイル名からproject名を推定してupload_projectを呼び出す。
4. アップロードに失敗した場合
- register_incoming_projectは呼び出さない。
5. アップロード成功後に登録が失敗した場合
- incomingにはファイルが残っていることを説明し、
再アップロードではなく登録の再実行を案内する。
通常の検索や一般質問には回答せず、検索用モデルの利用を案内してください。
登録機能を使ってみる
プロジェクトを登録したいときは、登録専用モデルを指定して、登録したいファイルを添付して、「登録して」と指示するだけです。
という自然な操作で利用できます。利用者は、QdrantやCollectionなどの内部構造を意識する必要はありません。また、プロジェクトファイルが巨大な場合は、あらかじめ別途incomingにファイルをコピーしておいて、登録専用モデルで、ファイル添付せずに登録してとだけ書けば、incomingにすでにあるファイルを対象として登録します。
4. 運用モデル
FKB は、認証やファイル管理を含めた統合システムを作る代わりに既存の運用環境に合わせて組み合わせられることを想定しています。そのためにFKB 自体には権限の管理機能がありません。所有者とかの概念も単に検索範囲を限定するためのもので、他人から見えなくするものではありません。
事故を防ぐために削除だけは慎重になって、FKB自体が登録した原本を削除することはないように設計しています。
じゃぁ、実際の運用上ファイル権限やセキュリティの問題をどうするかというと、サービスを公開する範囲を限定することで、運用します。限定する範囲としては、現在想定している運用モデルは、大きく２通りあります。物理的（あるいはVPNなど）にアクセスする人が限定されているネットワークで運用するモデルと、Docker composeの内部ネットワークだけに限定するモデルです。
4.1. 制限ネットワークモデル（研究室・組織向け構成）
研究室のサブネットなど、アクセスする人が限られているネットワークに対してMCPを公開するモデルです。研究室内で共有して問題のない研究用途のナレッジに限定するのであれば、MCPをDockerの外に公開しても、アクセス範囲を研究室サブネットやVPN利用者に限定する構成を取りやすくなります。
incomingフォルダ、原本フォルダも、NFSサーバなどに実体を用意し、Dockerからbindマウントするとともに、研究室の他のPCに対してもexportしておきます。
このとき、incomingフォルダはRead-Write、原本フォルダはRead-Onlyでexportしておくと、登録したいプロジェクトをNFS(またはSMB)でマウントした、incomingフォルダにコピーしておいて、登録作業だけMCPで依頼するということができ、巨大なプロジェクトではこちらの方が効率的です。
原本については、AIはMCP経由で参照できるようにしていますが、人間が原本を参照したいときにはNFS/SMBでマウントしたフォルダから直接原本を参照できます。このときにRead-Onlyにしておくことで、勝手に原本を消してしまう事故を防ぐことができます。
MCPについても、Dockerのportマップで、研究室内部ネットワークからアクセスできるように公開しておきます。これによりAIエージェントなどのツールからもプロジェクトの参照が可能となります。
私の研究室では、こちらの構成をとっていて、研究室外部からアクセスしたい場合は、VPN経由でサブネットにアクセスしてから利用する構成を考えています。
この構成では、
- 原本はファイルサーバで一元管理
- バックアップやアクセス権限も既存の運用をそのまま利用
- AIは読み取り専用で利用
という役割分担になります。
研究室や社内ネットワークなど、既にファイルサーバを運用している環境では、この構成が最もシンプルです。
また、大学では学外からのアクセスについても、大学が提供するVPNを利用することで、安全な通信路を確保できます。
つまり、認証や通信経路は既存のインフラへ任せ、filesystem-knowledge-bridge はナレッジの登録・検索だけを担当します。
4.2. Docker閉じ込めモデル
一方で、個人開発や小規模チームでは、研究室内にサーバを建てられない場合や、VPNなどによらず外部ネットワークからもアクセスするために、クラウド上にサーバを立てたいケースがあります。
このような環境ではFKBには認証もないのでこれをそのままDockerコンテナ外部に公開することはできません。この場合はDockerコンテナ内で完結するようにポートマップをせずに構成します。incomingフォルダや原本フォルダも名前付きボリュームを使って、Docker内部に閉じ込めます。
そうしておいて、唯一の外部に公開する口として、OpenWebUIのみportマップによって外部に公開します。そうすると全ての機能はOpenWebUIを経由しないと利用できないことになるので、アカウント管理やセキュリティはOpenWebUIに任せることができます。
AIエージェントからMCPを使いたいなどの要望には対応できませんが、MCPを対応づけたカスタムモデルをOpenWebUIでAPIキーを発行して公開することで、MCP付きモデルとして利用できます。プロジェクトの登録なども全てOpenWebUIを経由して行います。
OpenWebUIは利用者の多いOSSなので、セキュリティについても自作の小規模ツールでどうにかするよりよっぽど安心できます。アカウント管理についてもAuthentikと連携してSSOを構築する方法などノウハウが広く知られているので、対応しやすいです。
この構成では、
- 原本もDocker Volumeで管理
- Knowledge Register MCPやKnowledge Read MCP, Knowledge Upload APIはDocker内部だけで公開
- 外部へ公開するのはOpen WebUIだけ
という構成になります。
利用者はOpen WebUIからプロジェクトを登録・検索するだけでよく、内部サービスを直接意識する必要はありません。
4.3. 注意点
どちらのモデルを採用したとしても、メンバーは信用するというモデルに立っていることに注意してください。内部ネットワークモデルであれば、ネットワークにアクセスできるメンバ、Docker閉じ込めモデルであればOpenWebUIに登録したメンバー。これらのメンバーが見ることには問題ない範囲で運用する必要があります。所有権はあくまで検索範囲限定のためで権限じゃない。見ようと思えば参照できるし、Qdrantに登録したデータを削除することもできます（消しても簡単に再構成できます）。唯一、原本データについてのみはそもそも消さないという運用によって事故を防いでいます。
5. まとめ
前編では、AIが活用しやすいプロジェクトナレッジとはどのようなものかを考え、その実現方法としてフリーズ済みプロジェクトを単位としたインデックス化について紹介しました。
後編では、そのナレッジをどのように検索し、どのように登録・運用するかという視点から、filesystem-knowledge-bridge の設計について紹介しました。
本プロジェクトで目指したのは、多機能なナレッジ管理システムではありません。むしろ、
- プロジェクト単位で検索対象を限定する
- 必要になったときだけ原本を参照する
- 登録処理はできるだけ単純にする
- 認証やUIは既存システムへ委ねる
というように、責務をできるだけ小さく分割し、既存の仕組みと組み合わせて利用できる「軽量なナレッジブリッジ」を目指しました。
AIがソフトウェア開発へ深く入り込むようになった現在、「プロジェクトの知識をどのようにAIへ渡すか」は、これまで以上に重要なテーマになっています。一方で、プロジェクトナレッジの管理方法やAIとの連携方法については、まだ決定版と呼べるものはなく、さまざまな試行錯誤が続いています。filesystem-knowledge-bridge も、その一つの提案です。
研究室におけるプロジェクトのナレッジ化という非常にニッチなテーマですが、それでも
「AIへ渡す単位をプロジェクトと考えること」
「プロジェクトを検索対象として局所化すること」
という考え方は、多くの開発現場で応用できるのではないかと思っています。
本プロジェクトが、AI時代のプロジェクトナレッジについて考えるきっかけになれば幸いです。
関連リンク
この記事は、研究室AI基盤の構築シリーズの第４回です。
- 第1回：研究室で管理しやすい学生用AIハブの導入
- 第2回：カスタムモデルで「良いAI活用方法」を埋め込む
- 第3回：プロジェクト単位ナレッジ管理のコンセプトとインデックス機能の実装
- 第4回：プロジェクト単位ナレッジ管理の検索・登録機能の実装（⇦いまここ）
- 第5回：もう一つのナレッジとしてのAIエージェント（次回予定）
-
第6回：ユースケース：引き継ぎ資料の作成支援AIとプロジェクトナレッジとしての利用（最終回予定）
https://github.com/kato-lab/filesystem-knowledge-bridge