Busabase × Google Gemini CLIGemini CLIのナレッジベース
ターミナル実行は復元できても、有用な結果には説明、情報源、レビューが必要です。次のAgentが証拠として使う前に確認します。
3つのローカル成果物
指示、復元ポイント、証拠はそれぞれ別の問題を解決する。
Gemini CLIは階層的なGEMINI.mdを読み込み、checkpointingを有効にするとファイル変更前にローカルcheckpointを保存し、セッション履歴も保持します。これらは現在の実行には役立ちますが、実験の成功や再利用の承認を証明するものではありません。
実験台帳
ターミナルの全文を保存せず、結果を再現できるようにする。
次の担当者が問い、入力、コマンド、環境、結果、制約を再構成できて初めて有用な記録になります。生の成果物は長文へ貼り付けず、リンクで関連付けます。
| フィールド | 記録する内容 |
|---|---|
| hypothesis | この実行で何を確かめるか？ |
| input_ref | どのデータセット、Issue、ファイル、情報源を使ったか？ |
| command | どのタスクや入口を実行したか？ |
| environment | どのリポジトリ、ブランチ、モデル、実行環境か？ |
| result | 何が起きたかを簡潔に説明。 |
| evidence | ログ、出力ファイル、画像、テストはどこか？ |
| review_state | 提案中、レビュー中、承認、却下のどれか？ |
| next_run | 次の試行で何を変えるか？ |
実行のライフサイクル
進行中の出力と、後に残す主張を分ける。
対話実行でも自動実行でも中間出力が生まれます。証拠が付き、レビュー担当者が結論を承認するまでは作業材料として扱います。
問いと受け入れ基準を定義。
既知の環境で動かし成果物を保存。
根拠と制約を含めて結果を要約。
再現性を確認し、根拠のない主張を却下。
後続実行へ正式記録を公開。
証拠を検査できる状態に
結果を、それを支えるファイルや出力の隣に置く。
Busabaseは構造化記録をファイル、文書、Skillと同じワークスペースに置けます。Gemini CLIは承認済み要約を読み、現在の作業で必要なときだけ元の成果物を開きます。
- 主張
- データを失わず移行が完了した。
- 証拠
- Dry-runレポート、件数比較、検証出力。
- 制約
- ステージング用データセットのみで確認。
- レビュー
- データ責任者が次段階への利用を承認。
MCPは接続手段であり信頼モデルではない
Geminiのツール確認とBusabaseのデータレビューを分ける。
Gemini CLIはStreamable HTTP MCPとOAuth discoveryに対応し、ツールを絞り込み、サーバーを明示的に信頼しない限り確認を求められます。Busabaseは別の判断を加えます。ツール呼び出しの成功だけでは、提案値を正式な事実にしません。
このツールを実行してよいか？
ツール確認、include/exclude、サーバー信頼
この値を正式記録にしてよいか？
Change Request、フィールド差分、レビュー、マージ履歴
長期的な実行知識の質問
Gemini CLIナレッジベースのFAQ
BusabaseはGEMINI.mdの代わりですか？
いいえ。GEMINI.mdはプロンプトと一緒に読み込む指示です。Busabaseはフィールド、根拠、責任者、変更履歴を持つレビュー済み結果を保存します。
Checkpointは承認済み結果ですか？
いいえ。Checkpointはローカルの復元機能です。ファイルと会話状態を戻せますが、実行が正しいことやチームの承認は証明しません。
ターミナルログをBaseへ全部コピーしますか？
通常は不要です。簡潔な結果を記録し、関連ログや出力ファイルを証拠としてリンクします。複数実行を比較できる形を保ちます。
自動実行も記録を提案できますか？
接続と権限が許せば可能です。安定したrun keyで重複を防ぎ、共有知識に影響する出力はレビュー担当者がマージします。
最初のワークフローは何がよいですか？
依存関係の評価、移行リハーサル、ベンチマーク確認、障害診断、リリース準備など、繰り返せる調査や検証を選びます。
再現する価値のある結果から始める
次のGemini CLI実行には、ログの山ではなく証拠を渡す。
小さな実験台帳を作り、元の出力を関連付け、結論が次の実行へ渡る前にレビューします。