Busabase × Kimi Code
Kimi Code のナレッジベース
セッションの添付資料から検証できる証拠へ
Kimi Code は構造化された MCP 結果や添付資料への参照を保持します。Busabase には、チームが確認した結論を共有レコードとして残します。要約、元の値、添付原本を分け、セッション内の参照を他の Agent が開けるファイルと混同しないことが大切です。
Busabase の製品画面（英語）。
要約・原本・承認済みの事実を分ける
ツールの要約は結果の理解に、構造化フィールドは返却値の保存に使います。画像、CSV、リンク先の原本はレビューの根拠です。参照をまとめても、承認状態は個々の主張に付けます。要約を読んだだけで契約原本を確認済みにはしません。
実行の文脈
作業ファイル、指示、一時的な観測は実行環境に残します。
根拠への参照
主張を支える出典、観測時刻、適用範囲を保存します。
承認済みのチーム記録
現行レコードへの参照を通じて承認済みの値と未解決の問いを渡します。
要約は承認済み、JSON は確認待ち
架空の仕入先審査では、文章に承認済みとあっても structuredContent が status=pending のままかもしれません。契約画像は未読で、リンク先も未取得です。都合のよい回答を選ばず、両方の値と確認状況を記録します。
架空の例です。実際の顧客データや実測結果ではありません。
提案レコードの例
| 項目 | 例の値 | 証拠・判断 |
|---|---|---|
| summary.status | approved | conflict |
| structuredContent.status | pending | unresolved |
| source_page_or_row | CSV page 1; pages 2–3 unread | incomplete |
| review_decision | request missing evidence | not accepted |
- 01要約と JSON の不一致
- 02契約画像が未読
- 03CSV のページ取得が未完了
- 04リンク先が未取得
- 05原本を共有できない
- 06出典付きで確認済み
仕入先の判断前に証拠を揃える
次のタスクには、CSV の残りのページ、契約画像、JSON の状態不一致など、確認する対象を明示します。修正値にはページや行を紐付けます。確認済みの項目だけを承認し、ほかは未解決のまま残せます。
次の Agent に残す情報
レコード項目の例
claim_id、raw_value、source_page_or_row、attachment_ref、evidence_status、review_decision
Busabase が kimi-file:// を直接読めるとは扱いません。許可を得て原本を共有可能な場所に移し、ハッシュと機密区分を残して参照を検証します。原本を確認できない結論は保留し、ツール実行の許可と事実の承認を分けます。
出典＋観測時刻
ファイル、行、コミット、URL と実際の確認時刻を紐付けます。
適用範囲＋承認状態
対象の環境や成果を明示し、根拠のない項目は未解決にします。
責任者＋次の確認
判断の管理担当と再検証が必要になる条件を指定します。
調査から正式レコードへ
- 01既存レコードを読み、Space、Base、head を確認します。
- 02根拠のあるフィールドだけを提案し、出典と不明点を残します。
- 03承認前の提案には changeRequest 権限を選びます。write は広い権限で、人の承認を必須にする設定ではありません。
- 04権限のあるレビューとマージの後、正式レコードを読み返し、次のタスクに版と不明点を渡します。
セッション後も根拠にアクセスできるようにする
再利用する側の権限で原本を開きます。参照が失効していれば履歴を残して再確認を求めます。新しい出典で値が変わるときは、旧出典と新出典を添えて対象フィールドの変更を提案します。
よくある質問
別の Agent は kimi-file:// を開けますか？
開けると決めつけないでください。Kimi のセッション内参照なので、許可を得て原本を共有し、出典とハッシュを保持して受け取り側で確認します。確認前は証拠を利用不可として扱います。
元のメモリーを置き換えますか？
いいえ。元の指示やセッションの記憶は実行に使い、共有する確認済みの事実と出典をここに残します。使うときに最新版を読みます。
同時更新はどう扱いますか？
提案前に現在の head を読みます。変更されていたら差分を確認し、新しい証拠を上書きせず提案を修正します。