Busabase x Amp coding agentAmpのナレッジベース
Ampは1つのcoding taskをProject、Thread、remote Orb、CLI、複数deviceへ引き継げます。この連続性はexecution contextとして有用ですが、他のteamやAgentが証拠を確認せず再利用できるreviewed factとは異なります。
実行の地図
Project、Thread、Orbはそれぞれ別の問いに答える。
Amp Projectはコードベースと共通設定、Threadは一つの作業に含まれる依頼・応答・道具の利用・ファイル変更、Orbは隔離された遠隔実行環境を管理します。知識記録は三者を根拠として参照しますが、いずれも単独では承認済みの結論になりません。
| Ampの層 | 管理するもの | 長期利用の限界 |
|---|---|---|
| Project | リポジトリ、プロジェクト設定、共通の実行条件 | コードベースを束ねるが業務上の事実を承認しない |
| Thread | 会話、道具、ファイル、変更、引き継ぎ | 共有・保管・書き出し・削除が可能 |
| Orb | 遠隔マシン、ファイル、サービス、実行結果 | 作業場所であり判断権限ではない |
| 審査済み記録 | 採用した結論、根拠、責任者、有効期限 | 差分を伴う提案と審査でのみ更新 |
Thread boundary
共有できるThreadはprovenanceであり、自動的なtruthではない。
Amp Threadにはprompt、reply、tool call、file、device handoff、commitからの参照が残ります。Visibilityはprivate、workspace、group、unlistedです。正確なThread URLを証拠にし、再利用に必要なdecision-sized resultだけをpromoteします。
指示と拡張の置き場所
作業規則、再利用手順、実行コード、承認済み事実を分ける。
Ampは目的に応じて異なる仕組みを読み込みます。すべてを巨大な文脈ファイルへまとめると、古い事実と過剰な権限が同居します。
| 仕組み | 適した内容 | 置かない内容 |
|---|---|---|
| AGENTS.md | リポジトリ構成、コマンド、規約、レビュー手順 | 顧客・公開・障害対応の変動状態 |
| Skill | スクリプトや資料を伴う限定的な手順 | 手順が出した最新結果の自動採用 |
| Plugin | 道具、コマンド、イベント、画面、制御処理 | 正式記録を無審査で所有すること |
| MCP | 外部の道具、資料、認証付き呼び出し | 応答をそのまま承認済み知識とみなすこと |
| Busabase | 審査できる記録、文書、ファイル、Skill、App | リポジトリ内のコードレビューの代替 |
拡張機能の境界
Skillは必要時に手順を読み、Pluginはコードを動かし、MCPは外部システムへ接続する。
Ampは用途を絞ったMCP serverをSkillへ同梱し、必要な時だけ道具を見せる方法を推奨します。Pluginは道具・コマンド・イベント・画面・Skillを登録し、利用中の環境でコードを実行します。実行コード、版管理された手順、外部応答を別々に審査します。
必要時に読む指示、スクリプト、資料、任意のMCP
道具と実行時イベントを追加するコード
利用範囲と認証を持つ外部接続
どの拡張も自分では採用できない審査済み結果
Orbの境界
遠隔実行では認証情報と道具の置き場所が変わる。
Orbは新しい遠隔環境として起動し、端末を閉じた後も作業できます。手元のAmp設定は自動では移りません。共有可能な設定はリポジトリ、ブラウザ認証はremote MCP definitions、秘密情報は専用保管先に置きます。
端末固有の設定とブラウザ認証
リポジトリ設定、Orb secrets、remote MCP
端末を越えて会話と実行参照を保持
作業やteamを越える審査済みの結論だけを保持
実行証拠
後から結論を検証できるだけのAmp実行情報を残す。
Project、Thread、実行場所、リポジトリ時点、指示と拡張、重要な外部呼び出し、確認結果を小さくまとめます。会話全体を複製する必要はありません。
amp_projectAmp Projectと対象リポジトリamp_thread追跡可能なThread URLまたはIDrun_locationOrb、runner、手元のCLIguidance_snapshotAGENTS.mdと利用したSkillの版external_calls判断に使ったPlugin/MCP呼び出しgit_result起点branch、commit、diff、公開後のrevisionproofテスト、portal、画面、外部からの再確認
知識として残す条件
Threadを開けなくても理解できる結果だけを共有する。
何が変わったか、根拠は何か、誰が採用したか、いつ再確認するかを記録します。後続Agentへ無関係な依頼履歴やOrb権限を引き渡しません。
amp_outcome再利用する結論の識別子thread_evidence結論を裏づけるThreadと実行結果affected_scope影響するProject、service、teamreview_owner採否に責任を持つ担当者review_state採用、条件付き採用、却下、後継ありchecked_on根拠を最後に確かめた日recheck_on次に内容を見直す日Promoteしない
Threadの大半はexecution historyに残す。
Current taskの外で判断に影響するknowledgeだけをreviewへ送ります。
Exploration、failed commands、temporary notes、hypotheses
Source、config、tests、repository instructions
Architecture decisions、verified runbooks、release facts、incident conclusions
Evidence、owner、scope、freshnessがないclaim
実務上の確認
Ampで知識を扱う時のFAQ
BusabaseはAmp Threadの代わりになりますか？
なりません。Threadは作業の経緯、Busabaseはその中から審査して採用した結果を保持します。
すべてのThreadから記録を作りますか？
作りません。その作業を離れた後も別の判断を導く結果だけを提案します。
Unlisted Threadだけを根拠にできますか？
来歴には使えますが、公開範囲が変わっても残るコード、テスト、外部確認も添えます。
Amp Skillだけで審査を強制できますか？
できません。Skillは作業手順です。正式採用は権限とChange Requestで制御します。
Orbは手元のMCP設定を引き継ぎますか？
自動では引き継ぎません。公式文書は手元の設定とrepository/remote definitionsを分けています。
1つのThreadから始める
Verified Amp outcomeをreviewed team knowledgeへ変える。
Completed taskを選び、Threadとrepository evidenceを付け、accountable ownerが1つのbounded proposalをreviewします。