Buda vs Amp：開発スレッドの継続か、業務責任の継続か
「ノート PC を閉じても動くか」だけでは Amp と Buda を区別できない。Amp Orbs はリモートマシンで動き、再開時には会話、ファイル、サービスが残ると説明されている。Amp の代替を考えるなら、次の担当者と、維持すべき文脈を問いたい。
Amp の仕事の単位は thread であり、プロジェクト、コード変更、ツール操作、共同作業を結ぶ。Buda は永続的な Agent ワークスペースに業務責任を置く。両者には重なりがあり、クラウドの有無で比較するのは正確ではない。
一つ目の場面：PC を閉じる
Amp では各 Orb thread がコード、プラグイン、開発ツール、起点となる文脈を持つ新しい隔離環境を得る。依存関係の導入、アプリ実行、ブラウザー起動、変更のテストが可能で、Changes、Files、Terminal から結果を確認できる。
Agent が完了し操作が止まると Orb は一時停止する。新しいプロンプトで再開すると会話、ファイル、サービスが残る。Web、CLI、Mac、iOS で同じ thread を扱える。Buda もクラウドで実行し、持続する Drive とファイル、ブラウザー、ターミナル、Git を提供する。
PC を起動し続けなくてよい点は共通する。環境を thread とプロジェクトに結びつけるか、Agent の継続的な資料に結びつけるかが比較軸だ。
二つ目の場面：同僚に渡す
Amp thread にはプロンプト、回答、ツール操作、ファイル変更が残る。共有や他 thread の参照、同僚を招いたライブ作業ができ、Workspace は共有プロジェクト、設定、Skills、MCP、請求をまとめる。個人専用の開発ツールという説明は不正確だ。
コード調査では、同僚が diff、ターミナル、再現証拠を調べて修正を続けられる。環境と履歴が一つのタスクにまとまることは、工程の引継ぎに有用だ。
ただし見えることと許可されることは違う。ファイル変更、コード公開、顧客への約束にはそれぞれ境界がある。Buda でも同じ規則が必要で、成果物を見られるだけで全行動が承認済みにはならない。
三つ目の場面：翌週も実行する
Amp は Automations を公開している。現在の thread にスケジュールとプロンプトを保存し、履歴を引き継いで実行する。必要なら Orb が再開し、イベント駆動 Orbs も文書化されている。定期作業ができないという比較は成立しない。
次回に何を引き継ぐべきかを考える。遅いクエリの調査はプロジェクト設定とコードツールが中心になる。部門横断の週報は出典リスト、以前の検証、形式、複数の審査者、再利用手順を必要とする。これは文脈の管理方法の選択だ。
Buda では調査、コンテンツ、顧客対応の Agent が継続資料を別々に保持できる。安定した手順は Skill、明確な定期仕事は Automation にできる。Buda AI Marketplace で Skill を検索・導入し、受入条件を加える。継続責任があることは無条件の実行許可ではない。
機能一覧ではなく二種類の成果物を試す
開発調査ならコード、再現手順、確認可能な変更、テスト結果、次の提案を求める。顧客問題の要約なら承認済み資料、出典対応、責任者が確認できる結論、人に聞くべき質問を求める。
これは導入試験の設計であり、実測結果の主張ではない。同じ場面内で入力と受入条件を揃え、設定時間、文脈の不足、再説明、審査時間を記録する。片方のコード作業と他方の要約を速度で比べない。
コードプロジェクト中心なら Amp の thread、Orb、Workspace を優先して試す。役割が異なり資料が周期をまたぐなら、Buda で各 Agent の責任を管理しやすくなるか検証する。
移行の前に文脈を棚卸しする
単発タスク、プロジェクト、継続業務の情報を分け、閲覧者、変更者、承認事項を定義する。有用なコード thread と再現証拠を、一段落の要約に縮めて失わない。
業務も会話履歴の丸ごとコピーでは移行できない。承認済み入力、出典、受入条件、障害対応、未決事項を取り出す。秘密情報と顧客データの権限を確認する。クラウドだけで安全性は保証されない。
Buda の初回は小さくてよい。承認済み資料から週報案を作り、出典と未解決事項を残す。受け入れた後に再利用とスケジュールを決める。評価するのは次回の再説明の減少で、Agent の数ではない。
導入試験の前に確認すること
Orb は停止するたびに消えるか？
いいえ。各 thread は新しい隔離環境で始まるが、再開時には会話、ファイル、サービスが残ると説明されている。新規作成と毎回の初期化は別だ。
Amp は定期実行できるか？
できる。現在の thread に一回または反復の Automation を設定し、文脈を保てる。イベント駆動 Orbs もある。文脈の所有を比較すべきだ。
チームで共有できるか？
できる。Workspace はメンバー、thread、プロジェクト、共有設定を含む。実際の可視性と管理者ポリシーは確認が必要で、協働機能が全業務権限を満たすとは限らない。
すべて Buda に移す必要があるか？
ない。有用な開発 thread を残し、部門をまたぐ責任を一つ Buda で試す。資料の引継ぎと承認を設計し、既成の相互接続を仮定しない。