gists

Amp に関する議論

Ralph の内部ロジックを追う流れで出てきた amp について、その正体・永続スレッド機構・スレッド共有モデルの実用性について議論したログ。

Q1. amp ってなんだっけ

Amp は Sourcegraph が開発している AI コーディングエージェント CLI。

概要

提供元: Sourcegraph (コード検索/ナビゲーションで有名な会社)
種類: Claude Code / Cursor CLI / Aider と同じカテゴリの 自律型コーディング CLI エージェント
公式: ampcode.com

Claude Code との比較

	Amp	Claude Code
提供元	Sourcegraph	Anthropic
裏の LLM	複数モデル (Claude 含む) をオーケストレーション	Claude 専用
スレッド共有	URL (`ampcode.com/threads/xxx`) で共有・再参照可	ローカルセッション
権限バイパス	`--dangerously-allow-all`	`--dangerously-skip-permissions`

Ralph 文脈での位置づけ

ralph.sh はもともと amp 前提 で書かれていた (TOOL="amp" がデフォルト, ralph.sh:8)。後から Claude Code 対応が追加された形。

prompt.md に出てくる:

Thread: https://ampcode.com/threads/$AMP_CURRENT_THREAD_ID

これは amp が各実行に永続的なスレッド URL を発行するため、次イテレーションから過去の実行を read_thread ツールで参照できる 仕組みを利用している。Claude Code 側にはこの機能はないので、その場合は progress.txt の learnings が唯一の引き継ぎ手段になる。

Q2. amp の永続スレッド興味がある。クラウドにコンテキストをアップロードしてるってこと？

はい、その理解で合っている。Amp はスレッド (会話履歴・ツール実行ログ) を Sourcegraph のクラウドに保存 するモデル。

仕組み

各 CLI 実行ごとに $AMP_CURRENT_THREAD_ID が発行され、ampcode.com/threads/<id> という URL が紐づく
会話内容 (プロンプト / LLM 応答 / ツール呼び出しと結果 / 編集差分など) がサーバー側に蓄積
ブラウザで URL を開けば (権限がある範囲で) 閲覧可能
別の Amp セッションから read_thread ツールで 過去スレッドの中身を読み込める → Ralph が iteration をまたいで学びを引き継げる根拠

Claude Code との設計思想の違い

	Amp	Claude Code
セッション保存先	Sourcegraph クラウド	ローカル (`~/.claude/projects/`)
共有	URL 一発	ローカル or 手動エクスポート
チーム機能	スレッドをチームで共有・レビュー前提	基本シングルユーザー
オフライン	不可 (認証必須)	ローカル履歴は読める

プライバシー/セキュリティ上の含意

コード片・diff・エラーメッセージ・環境変数の一部 などがクラウドに送られる可能性がある
Sourcegraph のエンタープライズ顧客向けには self-hosted / 保存無効化オプションもあるはず (要確認)
個人利用で --dangerously-allow-all で回してると、触ったファイルの中身がスレッドログに載る点は意識しておくべき
機密リポジトリで使うなら、組織のポリシー確認 + Amp の data retention / training opt-out 設定を見る必要がある

Ralph 的メリット

この「クラウド永続スレッド」があるおかげで、Ralph は:

iteration 間でコールドスタートしても
progress.txt + read_thread(過去URL) で 実質的な長期記憶 を得られる

Claude Code 版 Ralph だと read_thread 相当がないので、progress.txt の learnings 記述品質がより重要になる、という非対称性が生じている。

Q3. このスレッド共有の概念、現時点で有効なのかな？僕にはそうは思えない。

同意。現時点ではスレッド共有モデルは 限定的な局面でしか効かない。

なぜ微妙か

1. 共有したい単位とスレッドの粒度が合わない

エージェントのスレッドは試行錯誤・手戻り・無駄なツール呼び出しも全部含んだ生ログ。他人が読むには ノイズが多すぎる。結局「要点をまとめた Markdown」や「最終的な diff / PR」を共有した方が早い。

2. 信頼できる成果物は「コードそのもの」

チーム開発のセオリーは:

結論 → コミット / PR / ドキュメント
過程 → commit message / PR description
議論 → Issue / Slack / ADR

これらは全部 リポジトリ or 既存の共有基盤 に乗っている。わざわざベンダーロックインされたスレッド URL を別経路で回すインセンティブが薄い。

3. プライバシー・コンプラのハードル

スレッドには社内コード・API キー・内部パス・ユーザーデータが混入しうる。「とりあえずクラウドに残る」設計は 企業で使う際の摩擦が大きい。逆にローカル完結なら承認フローが要らない。

4. 再現性が無い

共有されたスレッドを見ても、自分の環境で同じ LLM 応答が出るとは限らない。モデルは更新されるし、temperature もある。読み物としては面白いが、実用的な「手順書」にはならない。

5. ロックインコスト

Amp の thread URL は Amp がサービス終了すれば全部死ぬ。自分で書いた Markdown はテキストで永続する。「自分でつくったものを自分の場所に置く」が結局一番強い。

有効そうな限定的ユースケース

教育 / デモ: 「Amp でこう動いた」という実演
Amp のサポート: バグ報告時にスレッド URL 添付
短期間の pair debugging: 同僚に「今詰まってるこれ見て」と投げる
Ralph みたいな同一エージェントの自己参照 ← これは割と効く

結論

基本はローカルで自分が作ったものを共有するのがセオリー

という感覚は正しい。スレッド共有は「リアルタイムで自分の作業を他者/未来の自分に見せる窓」としては便利だが、知識資産化の手段としては弱い。知識は要約して Markdown にして git に入れる、が王道。

Amp の thread も Ralph 的な 同一プロセス内でのメモリ代替 として使うのが一番筋が良くて、「人間同士の共有」はオマケ程度に捉えるのが現実的。

This site is open source. Improve this page.