Shopify「River」と「Aquifer」— Slack 常駐エージェントとそれを支える社内エージェント基盤¶

作成日: 2026-09-27 出典: Burke Libbey / Javier Moreno / River「Under the River」Shopify Engineering（2026-05-28）関連: 社内saasデータ統合基盤_ai活用_事例比較_整理 / メルカリ_arca_ai時代の高速プロトタイピング基盤_整理 / 社内aiエージェント基盤_company_brain_比較_整理 / stripe_toolshed_minions_社内mcpとコーディングエージェント_整理

0. 要点（3行）¶

一言で: 「エージェントは公開チャンネルでしか働かせない」ことで、個人の試行錯誤を全社の資産に変えた。River は Slack 常駐のエージェントで、コード・テスト・PR・データウェアハウス・本番トレースを扱い、マージされる PR の8本に1本が River 共著。
支えているのは基盤 Aquifer。構成要素は session / harness / sandbox / gateway / 永続イベントログ / credentials proxy / observability。設計原則は「セッションだけは死なせない（プロセス・sandbox・マシンは使い捨て）」と「頭脳（harness）と手（sandbox）を分離する」。
新しいエージェント製品は新しい基盤ではなく「profile（設定の束）」として足す。River も PR レビューもヘッドレス agent も同じ基盤の上の profile。前提として 2024 年にモノレポ化（World）と Nix による環境の再現性に投資していた。

1. 前史 — 2024年の「退屈な」賭け¶

2024年春の Shopify は、多数のリポジトリ、チームごとにバラバラの開発環境、遅いフィードバックという状態だった。そこで2つの決定をした。

決定	中身	痛み	見返り
モノレポ化	Shopify が出すもの全部を1リポジトリ「World」に	CI を桁違いにスケール、merge queue とビルドキャッシュが基盤化、テスト基盤を作り直し	リポジトリ直下のエージェントが全領域を横断できる
Nix で全部作る	開発環境・CI・本番イメージを1つの再現可能な基盤に	散らばった前提を1つずつ剥がす	dev / CI / 本番が同じ環境

賭けの言葉は「コードはますます AI が書くようになる。インフラはその土台にならなければならない」（2024年初頭）。

2つの気づき 1. エージェントに優しい ≒ 人間に優しい。再現できない環境はエージェントも再現できない。分断されたリポジトリはエージェントも横断できない。書き残されていない知識は誰も学べない。エージェントは技術的負債を可視化する。 2. ローカルのエージェントには天井がある。各自の PC で動くエージェントの工夫は、そのセッションと一緒に消える。エージェント同士も学び合わない。

2. River — 公開チャンネル限定の Slack エージェント¶

sequenceDiagram
    participant U1 as 社員A
    participant Sl as 公開Slackチャンネル
    participant Rv as River
    participant U2 as 社員B
    participant Wd as World モノレポ / DWH / 本番トレース
    U1->>Sl: @river で質問
    Sl->>Rv: セッション開始
    Rv->>Wd: ファイルを読む・クエリ・テスト実行
    Rv->>Sl: 途中経過を投稿
    U2->>Sl: リンクを見て合流し制約や方針転換を追加
    Sl->>Rv: 新しい文脈
    Rv->>Wd: 会話を失わずに作業継続
    Rv->>Sl: 結果 / PR
    Note over Sl: スレッドは検索可能な記録になり<br>次の人の出発点になる

呼び出しは公開チャンネルで @river。DM は不可。すべての会話が、社内に既定で公開されたスレッドになる
できること: コードを読む、テストを回す、PR を出す、データウェアハウスにクエリする、本番トレースを見る、悪い計画には反論する
セッション中央値 19分、ツール呼び出し中央値 50回
その会話コーパスを分析し、パターンを River のスキル・プロンプト・既定値に還元する。モデルの再学習なしに賢くなる
誰かが River で問題を解くと、スキルの更新・AGENTS.md の差分・新しい共有スキルなどの「記憶」が World に残る

利用規模（直近30日）¶

指標	値
River セッション	59,918
使われた Slack チャンネル	5,170
関与した社員	7,000人超（5月上旬から約1,200人増）
River 共著でマージされた PR	3,536
マージ PR に占める River 共著	8本に1本

数値は River 自身が毎セッション書き込む river_sessions テーブルから出している。

3. Aquifer — 「100個の River」を作るための基盤¶

River を出すと、他チームが「うちにも」と言い出した（PR レビュー、リサーチ、マイグレーション、コンプライアンススキャン、性能調査…）。1つの River は作れたが、「100個の River を作れるもの」はまだ無かった。そこで作ったのが Aquifer。

flowchart TB
    subgraph Profiles[profile 群]
        River[River<br>対話型]
        PRReview[PR レビュー<br>自動化型]
        Vanilla[Vanilla<br>ヘッドレス agent]
    end
    subgraph Aquifer[Aquifer 基盤]
        Session[(Session<br>追記専用イベントログ<br>Postgres)]
        Harness[Harness<br>エージェントループ<br>使い捨て]
        Sandbox[Sandbox<br>FS・shell・リポジトリ<br>使い捨て]
        Gateway[Gateway]
        Cred[Credentials proxy]
        Obs[Observability]
    end
    Profiles --> Harness
    Harness -->|履歴を読む・書く| Session
    Harness -->|ツール実行の意図| Sandbox
    Harness --> Gateway
    Sandbox -.->|外部アクセス| Cred
    Harness --> Obs

図の Gateway / Credentials proxy / Observability の具体的なつながり方は記事に書かれておらず、構成要素として名前が挙がっているだけ。配置は自分の推定。

3-1. 分解¶

要素	役割	寿命
Session	永続的な ID。追記専用のイベントログ（Postgres）。「これまで何が起きたか」の正本	永続
Harness	エージェントループ。履歴を読み、モデルを呼び、ツールの意図を出す	使い捨て（再作成が安い）
Sandbox	コードが動く場所。ファイルシステム・shell・リポジトリ。bash / edit / build / test	使い捨て（暖機済みのことも、新品のことも）

3-2. 頭脳と手を分ける¶

harness は sandbox の外に住む（Anthropic「Scaling Managed Agents」2026年4月の "Decouple the brain from the hands" を引用）。ここから3つの性質が得られ、後付けはできない。

性質	理由
安全性	エージェントループが `rm -rf` と同じ被害範囲にいない
交換可能性	モデル・ランタイム・言語を harness 側で替えても sandbox に影響しない
観測性	判断の流れが全部 harness 側にあり、1か所で見える

3-3. Session cell（家畜であってペットではない）¶

セッションが動き出すと、ホスト上に一時プロセス「session cell」を立てる（Go ランタイムと harness が同じプロセスグループ）
アイドルになると終了。次の操作では別ホストに新しい cell が立つこともあるが、会話は Postgres にあるので続きから再開できる
「どのオーケストレーターを使うか」より「セッション単位で cattle-not-pets を妥協しない」原則の方が大事、としている

3-4. profile と3つの利用モード¶

profile は「システムプロンプト・スキル群・拡張・sandbox ポリシー・モデル既定値」をまとめたデータで、Nix でビルドしバンドルとして配る。新しいエージェント製品＝新しいバンドル。

flowchart LR
    Sub[共通基盤<br>session モデル・sandbox・gateway]
    Sub --> Mode1[対話型<br>River<br>永続セッション・人が常駐]
    Sub --> Mode2[自動化型<br>PR レビュー<br>外部システムが起こす・人なしが多い]
    Sub --> Mode3[ジョブ型<br>CI・バッチ<br>使い捨て・セッションログは任意]

「別のアーキテクチャを試すたびに、この3モードのどれかを作り直していた」ので、同じ session モデル・sandbox・gateway で3つを賄う形に落ち着いた。

4. データ・SaaS アクセスの観点で読む¶

観点	記事から言えること	記事に無いこと
DWH	River はデータウェアハウスにクエリする	どの DWH か、権限・行列制御の方法
資格情報	Aquifer に credentials proxy がある	仕組み（トークンの差し替え方、どの SaaS 向けか）。二次情報では「プレースホルダを出口で本物に差し替える」と説明されるが、一次資料では未確認
監査	判断の流れは harness 側で1か所に見える。全会話が公開スレッド	監査ログの保管・検知の仕組み
知識	World にスキル・AGENTS.md・runbook・意図文書が蓄積	—

読み取れる設計思想: データや SaaS へのアクセスを個別に守る前に、「全部の作業が公開の場で、1つの基盤を通る」ことで、監査・学習・再利用を同時に得ている。メルカリ Arca の「外に出る経路を1本にする」とは、守る対象が違う（Arca は通信、Shopify は会話と判断の流れ）が、1か所に集めて見えるようにする点で同じ発想。

5. まとめ — 持ち帰れること¶

一言で: 「エージェントを私物にせず公開の場で働かせ、その下に死なないセッション基盤を敷く」。

状況	Shopify から借りるアイデア
各自のローカル agent の知見が共有されない	公開チャンネル限定の共有エージェントにし、会話ログをスキルに還元
エージェントの種類が増えて基盤が乱立しそう	profile（プロンプト・スキル・sandbox ポリシーの束）として足す
長時間セッションが落ちる	セッションを Postgres の追記ログにし、実行プロセスは使い捨て
エージェントの暴走が怖い	harness を sandbox の外に置き、被害範囲を分ける
導入効果を示したい	エージェント自身にセッション記録テーブルを書かせ、数値を出す

参考リンク¶

Shopify Engineering「Under the River」: https://shopify.engineering/under-the-river
Anthropic「Scaling Managed Agents」（記事内で引用。本ノートでは未読）

作成: 2026-09-27 ／最終更新: 2026-09-27