Busabase × nanobot
nanobot のナレッジベース
個人の記憶を、チームが維持できる知識へ
nanobot の永続メモリーや履歴を使いながら、チームで共有する業務上の事実を Doc と Base に保存できます。個人の好みは元の記憶に残し、共有知識には出典と責任者を付けます。
接続ガイド →
記憶の永続化とチームの承認は別
会話、履歴、長期メモリー、GitStore は継続性や版の追跡を支えます。チーム知識にはさらに出典、責任者、適用対象、承認状況が必要です。長く残ることと組織として受け入れたことを分けます。
SOUL、USER、MEMORY を丸ごと移さず、共有する必要のある結論を選びます。業務規則は Doc、具体的な事実は Base に置き、出典と責任者、承認状態を関連付けます。個人の習慣や背景は元の層に残します。
保存先と維持する責任を決める
方針 Doc
規則の全文、対象、例外、出典を保存し、方針の責任者が説明を維持します。
知識 Base
継続管理する事実ごとに、キー、値、出典 URL、責任者、適用範囲、状態を保存し、方針 Doc に関連付けます。
更新 Skill
読み取り、根拠の確認、変更提案の手順を保存します。データへの権限を与えるものではありません。
結果レコード
タスクと成果物、決定、未確認事項を関連付けます。次の実行は終了状態から推測せず、実際の結果を読みます。
記憶と正式な方針が違うときは両方の根拠を残す
記憶から書き換える前に共有方針を読みます。項目や段落単位で差異を示し、記憶の出典と現行版を確認します。根拠があれば変更を提案し、不足していれば確認事項として残します。
個人メモリーを渡さず共有知識を再利用
リンク、適用範囲、出典、未確認事項を渡し、受け手が自分の権限で読み直します。権限差や失効した出典は責任者へ伝えます。更新後は正式レコードを入口にし、古い個人の記憶だけで判断しません。
確認できる引き継ぎを残す
引き継ぎには読んだレコード、回答の根拠、適用範囲を示します。修正案には ChangeRequest のリンクと変更項目を添え、責任者が変更前後と理由を確認できるようにします。承認後は正式レコードと結果を確認します。提案、承認判断、更新済みの値を区別し、受け手は未承認の結論を正式な事実として使いません。出典が失効していれば履歴と適用範囲を残し、責任者に新しい根拠を求めます。
既存の事実一件で最初の確認を行う
- 01
出典の分かる既存の方針や事実を選び、変更を頼む前に責任者を決めます。
- 02
現行レコードを読み、出典、適用範囲、版を返すよう指示します。対象資料を確認してから書き込みへ進みます。
- 03
変更前後、理由、根拠を示す範囲の限られた提案を作ります。人のレビューが必要なら、権限を持つ判断までは提案として保持します。
- 04
別のタスクから正式レコードを読み直し、値と出典を確認します。却下・未解決の変更は正式な回答に入れません。
接続と権限の境界
公式設定ではリモート HTTP MCP と OAuth が説明されています。認証と接続経路は現行ガイドに従います。記憶した指示は書き込み権限を与えず、Git の履歴も業務上の承認を意味しません。次の作業では共有レコードの現行版を読みます。
調整して使える指示
記憶した結論を支える共有方針を探し、個人メモは公開しないでください。正式な方針と違うなら両方の出典と修正案を示し、無断で上書きしたり記憶を承認と扱ったりしないでください。
接続前によくある質問
GitStore の変更履歴はチームの承認を意味しますか？
履歴は変更を記録します。チームでの承認には事実と根拠に結び付く権限のある判断が必要です。両方を残し、同じ出来事と扱いません。
元のメモリーを置き換えますか？
実行用の文脈や個人の好みは元の場所に残します。他の人が参照・検証・更新する知識だけを共有します。
一回の動作はどう確認しますか？
既存レコードのリンクと出典を確認し、根拠のある修正を一件提案します。差分を見て、承認された正式レコードを読み直します。提案リンクだけでは変更完了を確認できません。