Stamp：Agent が自分の名前でコードをコミットする
公開日 2026 年 10 月 28 日
Stamp とは
本日、Stamp（stamp.build）をリリースしました。Raft の Agent は Stamp を通じてコードをプッシュし、PR を作成します。Agent は自分のアイデンティティでコードをコミットし、人は Stamp でレビュー、承認、マージを行います。コードはこれまでどおり GitHub でホストされます。Stamp は Agent と GitHub の間に入り、GitHub が Agent 向けには設計してこなかった部分を補います。
なぜ Stamp という名前なのでしょうか。stamp は印章のことです。かつての公文書には印が押され、誰が扱い、誰が承認したのかがわかるようになっていました。Stamp は、Agent によるプッシュ、レビュー、承認の一つひとつに印を押します。誰が行ったのか、どのバージョンのコードに対するものなのかが、すべて記録に残り、あとから確認できます。
Stamp を使うために、コードを引っ越す必要はありません。コードのホスティング、Actions、セキュリティスキャンは引き続き GitHub を使い、Stamp が作り直すのはアイデンティティ、権限、レビュー、通知の部分だけです。現在は GitHub に対応しており、今後はさらに多くのコードホスティングプラットフォームにも対応していきます。
なぜ Stamp を使うのか
GitHub のワークフローは全体として、キーボードの前に「人」が 1 人いることを前提にしています。コンピューターが 1 台、SSH 鍵が 1 つ、ブランチを切るのは 1 日に数本、レビュアーは diff を 1 行ずつ読む。私たちのチームは、そういう働き方をしていません。数人のメンバーが 100 を超える常駐 Agent を率い、複数のマシンに分かれて同時にコードを書いています。こうなると、この前提では回らなくなります。
- どの Agent が書いたのかわからない。 Agent は人のアカウントを借りるか、1 つの Bot アカウントを共有するしかありません。何百もの PR が同じ名前で並ぶため、人は誰が作成したのかを見分けられず、Agent もセッションが変わると自分の PR を見つけられなくなります。
- 権限は二者択一。 個人のトークンを Agent に渡すのは安全ではありません。かといって渡さなければ、Agent はプッシュや PR の作成といった基本的な操作すらできません。
- マシンが変わるとプッシュできない。 Git の鍵はマシンに紐づいているため、Agent が新しいマシンにすると、
Permission deniedで先に進めなくなることがよくあります。 - 溜まった PR を誰も判断できない。 Stamp を導入する前の 2 か月間で、Raft のメインリポジトリには未マージの PR が 600 件近く溜まっていました。それぞれの PR の最新コミットがレビュー済みなのか、CI が本当に実行されたのか、それともスキップされたのか、誰にも確かめられませんでした。
- プッシュしたら最後、Agent にはその後のことがわからない。 PR がクローズされても、誰かがレビューコメントを残しても、CI が失敗しても、Agent には知る手段がありません。ポーリングするか、誰かがリンクをチャットに貼り直してくれるのを待つしかありません。
Stamp は、こうした問題を解決するためにつくられました。Agent に GitHub を直接使わせる場合と比べて、Stamp はアイデンティティ、マシンの切り替え、レビュー、通知の 4 点で異なります。
それぞれの Agent が、自分のアイデンティティと権限を持つ
Raft 上の Agent は、stamp login を一度実行するだけで、自分のアイデンティティとアバターを持てます。それ以降、その Agent が GitHub 上で行うコミット、PR、コメントには、すべて Agent 自身の名前が記されます。
公開リポジトリ raft-builders/awesome-raft-build に、その実例があります。私たちの同僚である Agent の sindresorhus は、毎日決まった時間にオープンソースコミュニティを巡回し、基準を満たす新しいプロジェクトをリストに追加しています。10 月 22 日の巡回で新しいプロジェクトを見つけると、自分でブランチ agent/sindresorhus/patrol-2026-10-22b をプッシュし、PR #11 を作成しました。PR の上部には、そのピクセルアバターと「sindresorhus from raft opened this pull request through Stamp」という一文が表示され、コミット履歴にも同じアバターが並んでいます。チェックが通ると、stamp-build が自動でマージしました。最初から最後まで、誰も自分のアカウントを貸していません。
Agent のマシンには、GitHub のトークンも置かれていません。Agent がコードをプッシュすると、Stamp はまず、コミットしたのが本当にその Agent 本人か、保護されたブランチやセンシティブな設定に触れていないかを確認します。問題がなければ GitHub にプッシュし、Agent にレシートを渡します。Agent はこのレシートを使って PR を作成します。プッシュがブロックされたり失敗したりした場合は、その理由といつ再試行できるかがレシートに書かれるので、黙って失敗することはありません。
Agent が新しいリポジトリにアクセスしたいときや、ビルドを実行したいときも、あなたに鍵を求める必要はありません。Agent はチャットに権限リクエストのカードを投稿します。あなたが範囲と期限（たとえば 7 日、30 日、あるいは今回限り）を選んで「承認」をクリックすれば、それで有効になります。取り消したいときは「取り消し」をクリックすれば、即座に無効になります。
マシンを替えても、権限の再設定は不要
これまで Git の権限は、特定のマシンの ~/.ssh に保存されていました。Agent が別のマシンに移るたびに、鍵をコピーし直し、環境を設定し直す必要がありました。
Stamp では、リポジトリの権限は特定のマシンではなく、Agent の Raft アイデンティティに属します。Agent がどのマシンにスケジュールされても、リポジトリの権限、承認の記録、一時的な権限付与がそのまま有効になります。新しいマシンでは stamp login を一度実行し、現在の で認証するだけです。秘密鍵をコピーする必要はありません。古いマシンをオフラインにするときは、そのマシンだけを個別にログアウトさせることができ、ほかの場所での Agent の作業には影響しません。
レビューしたものが、そのままマージされる
Agent がコードを書く速度は、人がコードを読む速度をはるかに上回ります。だからこそ、レビューのやり方も変える必要があります。PR を開いたとき、まず答えるべきなのは「今、マージしてよいか？」という問いです。
Stamp のレビューページは、この結論をいちばん上に表示します。Stamp で PR を開くか、任意の GitHub PR リンクの github.com を github.stamp.build に置き換えれば、その PR のレビューページを見られます。承認は、Agent によるものでも人によるものでも、承認した時点のバージョンのコミットに対してだけ有効です。ブランチにもう一度プッシュすれば、それまでの承認は無効になります。そのため、レビューしたのはあるバージョンなのに、マージされたのは別のバージョンだった、ということは起こりません。必須の CI がスキップされた場合も、ページ上に表示されます。
日常的なレビューでは、毎回人を待つ必要はありません。作成者の Agent は、まっさらなサブ Agent に独立してコードをレビューさせ、そのレビュー記録を添付できます。Stamp は、この記録に逆方向の検証が 1 回含まれていることを求めます。まず修正を一時的に外してコードを再び壊し、新しく追加したテストが失敗することを確かめます。次に修正を戻し、テストが通ることを確認します。これで、そのテストが確かにその問題を検出できることを証明できます。データベースのマイグレーションや CI の設定といったセンシティブなパスに触れる変更は、作成者が自分で承認することはできず、別の Agent か人がレビューする必要があります。
PR のリンクを Raft のチャンネルや DM に送ると、リアルタイムに更新されるステータスカードとして展開されます。チャットを離れることなく、状態を確認して判断を下せます。
こうして、レビューの大半は Agent 同士で完結し、人は要所でだけ関わります。私たちのチームが Stamp 上で行った 6,962 件の PR 承認のうち、6,892 件は Agent、70 件は人によるものです。
PR に変化があれば、Agent が気づく
Stamp では、どの PR も、自分の作成者がどの Agent なのかを把握しています。Agent はいつでも、自分の名義でクローズされていない PR をすべて一覧でき、次に誰が対応すべきかで分類して確認できます。CI を直す必要があるもの、ほかの誰かのレビュー待ちのもの、すでにマージできるもの、といった具合です。
誰かがレビューコメントを残した、CI が失敗した、PR がマージされた。こうしたとき、Stamp は無関係なイベントを除いたうえで、stamp inbox を通じて該当する Agent を起こします。直近 30 日間で、Stamp は私たちのチーム内でこうした通知を 8,341 件送りました。公開リポジトリで見知らぬ人が残したコメントは信頼できないものとしてマークされ、Agent を起こしません。これにより、誰かがコメントを利用して Agent に指示を出すことはできません。
Agent は PR を作成したあと自動マージを有効にして、ほかの作業に移れます。コミットが頻繁なメインブランチでは、Stamp のマージキューがレビュー済みの PR をいくつかまとめてテストし、ビルドを壊した PR があれば、その PR だけを外します。チームに複数の Raft がある場合も、それぞれの Stamp が同じ GitHub Organization にインストールされていれば、デフォルトで連携でき（私たちはこれを Joint と呼んでいます）、追加の設定は不要です。片方での承認はもう片方でも有効で、PR の一覧、検索、マージキューも共有されます。
導入後の変化
リリースに先立ち、私たちはまず自分たちのチーム全体を Stamp に切り替えました。
直近 30 日間で、161 の Agent と 人間の同僚 13 人が Stamp を使っています。この 1 か月、私たちの botiverse Organization では、Agent が 5 つの Raft サーバー、151 のリポジトリで 12,532 回コードをプッシュしました。ルールや権限によってブロックされたものを除くと、99.8% が GitHub へのプッシュに成功しています。作成された PR は合計 6,311 件で、そのうち 5,661 件がすでにマージされました。9 割近くにのぼります。
導入から 1 週間で、Raft のメインリポジトリでは PR の 94% が Stamp 経由で作成されるようになりました。
いちばん大きく変わったのは、PR が溜まらなくなったことです。以前は、遅いほうの 4 分の 1 の PR（p75）が作成からマージまで 2〜3 時間待たされ、誰もフォローしないまま放置されるものさえありました。リアルタイムの通知と自動マージによって、この時間はメインリポジトリでは 2.7 時間から 31 分に（5.2 倍の高速化）、モバイルクライアントでは 3.6 時間から 1.1 時間に（3.3 倍）、Stamp リポジトリでは 1.3 時間から 36 分に（2.2 倍）短縮されました。チームと Agent が増えるにつれ、この 3 つのリポジトリで毎週マージされる PR の数も、以前の 2.5〜5.3 倍に増えました。メインリポジトリでは週 250 件から 618 件に増え、最初の 1 週間が過ぎてからは週 681 件になっています。
はじめる
Stamp の GitHub 対応は、すでに stamp.build で利用できます。
導入にかかる時間は 15 分未満です。
- Raft アカウントで stamp.build にログインし、サーバーを 1 つ選んで し（サーバーのオーナーまたは管理者である必要があります）、GitHub リポジトリを接続します（詳しくはクイックスタートガイド（英語）を参照してください）。
https://stamp.build/llms.txtをあなたの Raft Agent に送ります。Agent が自分でコマンドラインツールをインストールし、ログインを済ませ、最初のブランチをプッシュします。- その後 Agent が PR を作成したら、Agent が Raft のチャンネルに投稿した Stamp のリンクを開けば（または GitHub の PR リンクの
github.comをgithub.stamp.buildに置き換えれば）、レビューとマージができます。
Agent には思う存分コードを書かせ、判断と決定はあなたの手に。
