Amazon社内で2,000人以上が使うAIエージェント受信箱、Pizza Botを実際に動かしてみた

はじめに

AWSの公式ブログに、Pizza Botというオープンソースプロジェクトの紹介記事が載っていました。

AIエージェントを「受信箱」というメタファーで扱うアプリで、Amazon社内ではすでに2,000人以上が日常業務に使っているそうです。
チャット画面をずっと見張らなくていいというコンセプトに興味を惹かれ、実際にリポジトリをクローンして手元で動かしてみました。

この記事では、Pizza Botが何をするツールなのか、どこが便利なのか、そして実際に触ってみて気づいたことをまとめます。

Pizza Botとは何か

Pizza Botは、バックグラウンドで動くAIエージェント向けのクライアントアプリです。
GitHub上で公開されており、ライセンスはApache License 2.0です。

リポジトリのREADMEには、こんな一文があります。

You don't send an email and then sit watching the outbox until the reply lands.

メールを送ったら、返信が来るまで送信箱を見張り続けたりはしません。
Pizza Botはこの感覚をAIエージェントとのやり取りに持ち込んだアプリです。

画面の構成は3つのビューに分かれています。

• Unread: エージェントが作業を完了したスレッド
• Action: 承認や回答など、人間の判断待ちになっているスレッド
• All: すべてのやり取りの履歴

チャットボットのようにリアルタイムで会話を追いかける必要はありません。
タスクを投げたら、あとは受信箱を覗きにいくだけで済みます。

アーキテクチャは大きく4つの層に分かれています。

• クライアント: Electronデスクトップアプリ、ブラウザ、ターミナル
• サーバー: HTTP経由でエージェントの実行状態を管理する
• ランタイム: DeepAgents/LangGraphというフレームワーク上で動作する
• ストレージ: SQLiteとファイルベースの保存(チェックポイント、スレッド、添付ファイル)

自己ホスト型で、データは自分のマシンに保存されます。
モデルはAnthropic、Amazon Bedrock、Google Gemini、OpenAI、OpenRouter、Ollamaに対応しており、デフォルトで推奨されているのはAnthropic Claudeです。
Model Context Protocol(MCP)サーバーでツールを追加でき、Skill.mdファイルでスキルを自作して拡張することもできます。

何が嬉しいのか

普段のチャット型AIアシスタントは、こちらが画面の前にいる間しか仕事をしてくれません。
数分かかるタスクや、途中で承認が必要なタスク、決まった時間に動かしたいタスクには、正直あまり向いていませんでした。

Pizza Botの発想は、同僚に仕事を頼んだときの感覚に近いです。
頼んだら相手は席を離れて作業に取りかかり、終わったら報告してくれます。
こちらは他の作業をしながら、区切りのいいタイミングで受信箱を確認すればいいだけです。

Amazon社内での使われ方も、会議の準備、メールの下書き作成、Slackの要約、CRMへの記入といった、まさに「ちょっと任せたい雑務」ばかりでした。
チャットで逐一やり取りするには面倒だけれど、完全放置もできない作業を拾ってくれる立ち位置だと感じます。

Amazon社内で使われているのに、AWSがあまり大々的に告知しない理由

ここが個人的に一番気になった点です。
2,000人以上が使っている社内ツールにしては、告知のされ方がかなり控えめでした。

AWSの主要な発表チャネルであるNews BlogやWhat's Newには載っておらず、掲載されたのはOpen Source Blogという、比較的ニッチな発信先だけです。
re:Inventの目玉発表のような扱いも受けていません。

理由をいくつか推測してみます。

• Apache License 2.0のコミュニティプロジェクトとして公開されており、AWSサポートの対象外です
• モデルプロバイダーはAmazon Bedrockに限定されておらず、AnthropicやGoogle Gemini、OpenAI、Ollamaまで幅広く選べます。デフォルト推奨もAmazon Bedrockではなく直接のAnthropic Claudeになっています
• 課金が発生するマネージドサービスではなく、自己ホスト型のクライアントアプリです

AWSのマーケティングは、基本的に自社サービスへの誘導とセットになっているものが多いという印象があります。
Pizza BotはAWSのサービスに縛られない設計思想を持つツールなので、「AWSを使えばこんなことができる」という従来の宣伝の型にははまりにくかったのではないかと思います。
社内で生まれた便利ツールを、律儀にオープンソースとして公開はしたものの、大々的な広告塔にはしなかった、というのが実態に近いのではないでしょうか。

あくまで手元で調べた範囲からの推測であり、AWS側の公式な説明があるわけではない点はご承知おきください。

実際にクローンして動かしてみた

ここからは、実際に手元の環境で動かした記録です。

環境構築

リポジトリをクローンし、READMEに従って依存関係をインストールしました。

git clone https://github.com/pizza-bot-app/pizza-bot.git
cd pizza-bot
npm install

構成はモノレポになっていて、apps/配下にapi-server、desktop-shell、web、cliが並んでいます。
api-serverはAPIサーバー本体、desktop-shellがElectronのメインプロセス、webがUI部分のViteプロジェクトという役割分担です。

ビルドして起動します。

npm run build && electron .

裏側ではapi-server(tsxで実行)と、ポート5273で立ち上がるwebのVite開発サーバーが動き、Electronのウィンドウがそれを表示する形になっていました。

Amazon Bedrockに接続する

設定画面からモデルプロバイダーを選べます。
今回は手元のAWS CLIですでにSSOログイン済みだったので、Amazon Bedrockを選び、モデルはクロスリージョン推論プロファイルのus.anthropic.claude-sonnet-4-6をus-east-1で使う設定にしました。

APIで直接確認すると、設定は次のように反映されていました。

{
  "provider": "bedrock",
  "model": "us.anthropic.claude-sonnet-4-6",
  "auth": { "type": "profile", "profile": "default", "region": "us-east-1" }
}

IAM権限周りで詰まることもなく、あっさり接続できました。

つまずいたこと

一つだけ困ったことがありました。
動作確認のために何度かElectronアプリを起動し直していたら、ウィンドウが繰り返し前面に出てきて、他の作業の邪魔をするようになったのです。

対処として、アプリ自体は終了せずに、ウィンドウだけ非表示にしました。

osascript -e 'tell application "System Events" to set visible of process "Electron" to false'

これで裏側のAPIサーバーやエージェントのプロセスは動かしたまま、画面を占有せずに作業できるようになりました。
以降の動作確認は、GUIを操作せずAPIを直接叩く形に切り替えています。

動作確認

「AWSについて3行で要約してください」という、外部に一切副作用のない無害なタスクをAPI経由で投げてみました。
Bedrock経由できちんと応答が返ってきて、スレッドの一覧を確認するとunread: trueとして反映されていました。

Unread/Action/Allという受信箱の仕組みが、確かに機能していることを確認できました。
実際に手を動かしてみると、記事で読んだときよりも「エージェントに仕事を投げて放置する」という感覚がはっきり掴めた気がします。

インターネット上に公開してみた

ローカルで動くところまで確認できたので、実際にインターネット上からアクセスできる状態まで持っていくことにしました。

構成は次の通りです。

• フロントエンド: Vercel(apps/webのビルド成果物を静的ホスティング)
• バックエンド: AWS EC2(t3.small)上でDockerコンテナとして稼働。
  SQLiteでスレッドの状態を持つ設計上、常時稼働する1プロセスという制約があり、素直にVM1台構成に合わせました
• インフラ定義: nx-plugin-for-awsのts#infraジェネレーターでCDKの雛形を作り、cdkd(CloudFormationを経由せずAWS SDKを直接呼び出す高速デプロイCLI)でデプロイしました
• TLS: 独自ドメインを新規取得する代わりに、IPアドレスをそのままホスト名に埋め込んで解決してくれるsslip.ioという無料の公開DNSを使い、Caddyで自動的にLet's Encrypt証明書を取得する構成にしました
• Amazon Bedrockの認証: EC2にAWS SSOの一時的な認証情報を使うのは無人稼働に向かないとdocs/STANDALONE_BACKEND.mdに明記されていたので、bedrock:InvokeModel系だけを許可した専用のIAMユーザーを新規に作りました

途中、EC2起動時に実行するUserDataスクリプトのログに、アクセスキーとAPIトークンが平文で出力されてしまう問題を見つけました。
そこについては、気づいた時点で両方とも失効させて再発行し、EC2とVercelの設定を更新してから改めて動作確認をやり直しています。
公式ドキュメントがこの公開構成自体を「Unsupported / discouraged」(レート制限なし、単一の共有トークンのみで認可している)と明記している通り、動かせることと安全に運用できることは別の話だと実感しました。

この記事では、実際にデプロイしたURLは載せません。
レート制限がなく誰でもBedrockを呼び出せてしまう構成なので、公開すると想定外の課金につながりかねないためです。

日本語と英語を切り替えられるようにしてみた

元のPizza Bot(apps/web)はUIがすべて英語固定だったので、試しに日本語/英語の切り替え機能を自分で追加してみました。

• Reactのcontextと辞書オブジェクトによる自前実装で、外部のi18nライブラリは使っていません
• 受信箱本体と設定画面を中心に、主要な画面の文言を日英対応させました
• 選択した言語はlocalStorageに保存し、navigator.languageを見て初期表示の言語を自動判定します

これはPizza Bot本体には取り込まれていない、手元のフォークだけの変更です。
OSSへのコントリビュートというより、実際に手を入れて動かしてみる過程で「ここは自分でも直せそうだ」と思って試した延長線上の作業でした。

最後まで読んでいただきありがとうございました。