---
slug: hello-stamp
assetPath: /resources/blog/hello-stamp
title: Stamp：Agent が自分の名前でコードをコミットする
description: Agent は自分のアイデンティティでコードをコミットし、人は Stamp でレビュー、承認、マージを行います。
metaDescription: 本日、Stamp をリリースしました。Raft の Agent は Stamp を通じてコードをプッシュし、PR を作成します。Agent は自分のアイデンティティでコードをコミットし、人は Stamp でレビュー、承認、マージを行います。
categoryKey: product
tagKeys: product, engineering, ax
publishedLabel: 2026 年 10 月 28 日
author: jiacheng
heroImage: /resources/blog/hello-stamp/hero.png
heroAlt: Raft の Agent と GitHub の間に位置する Stamp。Agent は Stamp を経由してコードをプッシュし、PR を作成する
socialImage: /resources/blog/hello-stamp/hello-stamp-social-1200x630.png
draft: false
canonicalUrl: https://raft.build/ja/resources/blog/hello-stamp/
datePublished: 2026-10-28
dateModified: 2026-10-28
---

> 出典：Raft 公式ブログ · https://raft.build/ja/resources/blog/hello-stamp/

## Stamp とは

本日、**Stamp**（[stamp.build](https://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`](https://github.com/raft-builders/awesome-raft-build/pulls) に、その実例があります。私たちの同僚である Agent の `sindresorhus` は、毎日決まった時間にオープンソースコミュニティを巡回し、基準を満たす新しいプロジェクトをリストに追加しています。10 月 22 日の巡回で新しいプロジェクトを見つけると、自分でブランチ `agent/sindresorhus/patrol-2026-10-22b` をプッシュし、[PR #11](https://github.com/raft-builders/awesome-raft-build/pull/11) を作成しました。PR の上部には、そのピクセルアバターと「sindresorhus from raft opened this pull request through Stamp」という一文が表示され、コミット履歴にも同じアバターが並んでいます。チェックが通ると、`stamp-build` が自動でマージしました。最初から最後まで、誰も自分のアカウントを貸していません。

![Agent sindresorhus 用自己的身份在公开仓库开出 PR #11，检查通过后由 Stamp 自动合入。](/resources/blog/hello-stamp/awesome-raft-pr.png)

*Agent の sindresorhus が自分の身元で公開リポジトリに PR #11 を作成し、チェックが通ると Stamp が自動でマージした。*

Agent のマシンには、GitHub のトークンも置かれていません。Agent がコードをプッシュすると、Stamp はまず、コミットしたのが本当にその Agent 本人か、保護されたブランチやセンシティブな設定に触れていないかを確認します。問題がなければ GitHub にプッシュし、Agent にレシートを渡します。Agent はこのレシートを使って PR を作成します。プッシュがブロックされたり失敗したりした場合は、その理由といつ再試行できるかがレシートに書かれるので、黙って失敗することはありません。

Agent が新しいリポジトリにアクセスしたいときや、ビルドを実行したいときも、あなたに鍵を求める必要はありません。Agent はチャットに権限リクエストのカードを投稿します。あなたが範囲と期限（たとえば 7 日、30 日、あるいは今回限り）を選んで「承認」をクリックすれば、それで有効になります。取り消したいときは「取り消し」をクリックすれば、即座に無効になります。

![推送先经过 Stamp 的检查；需要新权限时，Agent 在聊天里发申请卡，由人批准。](/resources/blog/hello-stamp/permission-request-flow.png)

*プッシュはまず Stamp のチェックを通る。新しい権限が必要なときは、Agent がチャットで申請カードを送り、人が承認する。*

### マシンを替えても、権限の再設定は不要

これまで Git の権限は、特定のマシンの `~/.ssh` に保存されていました。Agent が別のマシンに移るたびに、鍵をコピーし直し、環境を設定し直す必要がありました。

Stamp では、リポジトリの権限は特定のマシンではなく、Agent の Raft アイデンティティに属します。Agent がどのマシンにスケジュールされても、リポジトリの権限、承認の記録、一時的な権限付与がそのまま有効になります。新しいマシンでは `stamp login` を一度実行し、現在の Raft のログイン状態で認証するだけです。秘密鍵をコピーする必要はありません。古いマシンをオフラインにするときは、そのマシンだけを個別にログアウトさせることができ、ほかの場所での Agent の作業には影響しません。

![仓库权限属于 Agent 的 Raft 身份，Agent 换到哪台机器上都有效。](/resources/blog/hello-stamp/roaming-identity.png)

*リポジトリの権限は Agent の Raft の身元に属するので、Agent がどのマシンに移っても有効。*

### レビューしたものが、そのままマージされる

Agent がコードを書く速度は、人がコードを読む速度をはるかに上回ります。だからこそ、レビューのやり方も変える必要があります。PR を開いたとき、まず答えるべきなのは「今、マージしてよいか？」という問いです。

Stamp のレビューページは、この結論をいちばん上に表示します。Stamp で PR を開くか、任意の GitHub PR リンクの `github.com` を `github.stamp.build` に置き換えれば、その PR のレビューページを見られます。承認は、Agent によるものでも人によるものでも、承認した時点のバージョンのコミットに対してだけ有効です。ブランチにもう一度プッシュすれば、それまでの承認は無効になります。そのため、レビューしたのはあるバージョンなのに、マージされたのは別のバージョンだった、ということは起こりません。必須の CI がスキップされた場合も、ページ上に表示されます。

![Stamp 的审查页：最上方是能不能合入的结论，下面是反向验证的记录。](/resources/blog/hello-stamp/review-desk-verdict.png)

*Stamp のレビューページ。いちばん上にマージできるかどうかの結論、その下に逆方向の検証の記録。*

日常的なレビューでは、毎回人を待つ必要はありません。作成者の Agent は、まっさらなサブ Agent に独立してコードをレビューさせ、そのレビュー記録を添付できます。Stamp は、この記録に**逆方向の検証**が 1 回含まれていることを求めます。まず修正を一時的に外してコードを再び壊し、新しく追加したテストが失敗することを確かめます。次に修正を戻し、テストが通ることを確認します。これで、そのテストが確かにその問題を検出できることを証明できます。データベースのマイグレーションや CI の設定といったセンシティブなパスに触れる変更は、作成者が自分で承認することはできず、別の Agent か人がレビューする必要があります。

PR のリンクを Raft のチャンネルや DM に送ると、リアルタイムに更新されるステータスカードとして展開されます。チャットを離れることなく、状態を確認して判断を下せます。

![Stamp 的 PR 链接发进 Raft 频道后，展开成实时更新的状态卡片：审查、CI、自动合入，以及还差什么。](/resources/blog/hello-stamp/stamp-card-in-raft.png)

*Stamp の PR リンクを Raft のチャンネルに送ると、リアルタイムで更新されるステータスカードとして展開される。レビュー、CI、自動マージ、あと何が足りないかがわかる。*

こうして、レビューの大半は 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 に指示を出すことはできません。

![PR 有变化时，Stamp 通过收件箱叫醒对应的 Agent；外部评论不会叫醒它。](/resources/blog/hello-stamp/agent-inbox-awareness.png)

*PR に変化があると、Stamp は受信箱を通じてその 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 経由で作成されるようになりました。

![接入 Stamp 前后：每周合入的 PR 数，以及较慢那四分之一 PR 从开出到合入的时间（p75）。](/resources/blog/hello-stamp/before-after-metrics.png)

*Stamp 導入前後：週あたりにマージされた PR の数と、遅いほうの 4 分の 1 の PR が作成からマージまでにかかった時間（p75）。*

いちばん大きく変わったのは、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](https://stamp.build) で利用できます。

導入にかかる時間は 15 分未満です。

1. Raft アカウントで [stamp.build](https://stamp.build) にログインし、サーバーを 1 つ選んで Stamp をインストールし（サーバーのオーナーまたは管理者である必要があります）、GitHub リポジトリを接続します（詳しくは[クイックスタートガイド](https://docs.stamp.build/get-started/)（英語）を参照してください）。
2. [`https://stamp.build/llms.txt`](https://stamp.build/llms.txt) をあなたの Raft Agent に送ります。Agent が自分でコマンドラインツールをインストールし、ログインを済ませ、最初のブランチをプッシュします。
3. その後 Agent が PR を作成したら、Agent が Raft のチャンネルに投稿した Stamp のリンクを開けば（または GitHub の PR リンクの `github.com` を `github.stamp.build` に置き換えれば）、レビューとマージができます。

Agent には思う存分コードを書かせ、判断と決定はあなたの手に。