プロジェクトに伴走する Agent を Slack に置く

AI社会実装勉強会第64回 https://machine-learning-workshop.connpass.com/event/410211/
の発表資料です。

Transcript

1. プロジェクトに伴⾛する Agent を Slack に置く 2026/10/31 熊懐 葵
2. 今⽇の流れ 6 つの章で話します 01 モチベーションとゴールイメージ 02 動かしてみた結果 03 全体構造 04 コンテナの中⾝‧連携 05 deployの流れ 06 コンテナが壊れたときの対処
3. 01 モチベーションとゴールイメージ
4. 第1章 モチベーションとゴールイメージ 状況 プロジェクト 進める側に必要なこと 社内で始まったプロジェクトを、進めて コンセプトとゴールを正しく理解したう いくことになった えで、何を作るのかを詰めていく コンセプト 何を作る？ ゴール 詰めていく 理解する プロジェクトが始まった
5. 第1章 モチベーションとゴールイメージ 課題: 初動で詰まりそうだった ⽂脈 コンセプトやゴールは、 Slack 上のやり取りの中で決 まってきた。⽂脈は、スレッ やりたいこと しかし 初動では「何から⼿を付ける ⽂脈を読み返して、その都度 か」を、ゴールからズレずに 確認するには、時間がかかる 決めたい ドに散らばっている ズレずに スレッドに散らばった⽂脈 何から⼿を付けるか、決めたい 読み返すたびに、時間がかかる
6. ゴールイメージ Slack 上に、 伴⾛する Agent を 1 つ置く まず、ここから …（やり取り） こんな感じで進めよ う！ Agent 全部読む メンバー Agent ゴール Agent 1 決まるまでの⽂脈を読む コンセプトが決まるまでの、Slack 上の やり取りを、上から下まで読んで、⽅向 性を理解する 2 提案する ⽂脈をもとに「まず何をすればよいか」 を提案する。⽅針や⽅向性はズレにくい 3 同じ⽅向を⾒て、進む ゴールを⾒失わずに、プロジェクトを前 に進められるのではないか
7. 02 動かしてみた結果
8. 結果 こんな感じで動きます 1 メンションすると、返信が来る Slack で Agent にメンションして、進 捗を聞いた。 2 ⽂脈を読んで、答える ゴール、今までやっていたこと、現在 やっていることを、スレッドの内容か ら整理している。 3 固有名詞も伏せて出⼒する 「外部向けに固有名詞は伏せて」と頼 んだので、団体名などは伏せて書かれ ている。
9. 結果 続けて、会話もできる 1 返信を作っている途中の動きも⾒える 「Checking context...」と表⽰され、Agent が⽂脈を確認してい る様⼦がわかる。待っている間も、動いていることが⾒える。 2 同じスレッドで、続けて聞ける 別のスレッドを⽴てず、続きのやり取りとして「これからはどん なことをしようとしていますか？」と質問している。
10. 結果 ⽂脈を読んで、会話できる 1 ⽂脈を読んで、会話できる 直近のやり取りで合意された内容をもとに、「これからやろうと していること」を整理して返している。 2 固有名詞は、ここでも伏せて出⼒ 団体名などは伏せたまま。⼈と話すように、質問を重ねて確認で きる。
11. 03 全体構造
12. 第3章 全体構造 OpenClaw とは Agent を動かすための基盤。 Docker で⼊れられる。 やってくれること Slack とつながり、メンションを受け取る Claude を呼んで、返事を考える 配布元（docker pull で取得） ghcr.io/openclaw/openclaw 使⽤しているバージョン（digest で固定） 2026.7.1 Agent の指⽰書と記憶を、ファイルとして持つ Agent が、コマンドを実⾏する これらを担う中⼼のプロセスを Gateway と呼ぶ（第4章） 設定や記憶のファイルは volume（コンテナの外にある保存場所）に置かれる
13. 第3章 全体構造 全体図 EC2 OpenClaw のコンテナ Claude Slack Socket Mode コンテナから接続 動いている間 GitHub App で認証 GitHub（repo） config/‧scripts/ コンテナの中⾝（第4章で説明） Dockerfile deploy のとき memory の蓄積 EBS（volume） コンテナの外にある保存場所 /home/node/.openclaw にマウント Agent の指⽰書
14. 第3章 全体構造 — コンテナの元（image）と、コンテナの外の保存場所（volume） コンテナは image から作り、volume をつないで動かす OpenClaw のコンテナ マウントとは コンテナの外にある保存場所を、コ ンテナの中のフォルダとして、つな ぐこと。つなぐと、ふつうのフォル ダのように読み書きできる。書いた ものは、外の保存場所に残る。 マウントする コンテナを作る コンテナの中のフォルダとして使えるようにする /home/node/.openclaw volume（EBS） image 役割 deploy のとき コンテナの元 役割 コンテナの外にある保存場所 作り直す deploy のとき 残る
15. 第3章 全体構造 — コンテナの元（image）と、コンテナの外の保存場所（volume） image と volume には、何が⼊っているか image deploy で作り直す 次の 3 つを合わせて、image として build する 配布元の image（OpenClaw 本体） ghcr.io/openclaw/openclaw · digest で固定 ＋ volume（EBS） 残る Agent が使う、⼈からの指⽰と、これまでの⽂脈 ⼈が書く指⽰書 deploy で上書きコピー ⼈が書き、git で管理 AGENTS.md, SOUL.md, USER.md Dockerfile で⾜すもの gh, git, util-linux, ユーザー ghbroker ＋ 記憶‧記録 deploy では触らない repo から焼き込むもの（設定とスクリプト） Agent が動いている間に書き⾜す（記憶、会話ログなど） config/openclaw-config.json, scripts/ memory/, sessions/ ⼈が書く指⽰書は GitHub から届け、Agent が書き⾜す記憶‧記録は deploy では触らない
16. 第3章 全体構造 — 起動までの流れと、起動後の書き込み ⼈が書くものと Agent が書くものを分ける GitHub config/ scripts/ ① deploy で 焼き込まれる image ③ コンテナの元になる コンテナの元。作り直す OpenClaw の コンテナ Dockerfile volume（EBS） AGENTS.md コンテナの外にある保存場所 ④ マウントする （コンテナの中のフォルダ SOUL.md ⼈が書く指⽰書 として使えるようにする） USER.md ② deploy で コピーされる 記憶‧記録 /home/node/.openclaw （memory/、sessions/） ⑤ 動いている間、 ずっと書き⾜す EC2 ⼈が書く指⽰書は、GitHub から deploy で届ける。Agent が書き⾜す記憶‧記録は、deploy では触らない。
17. 04 コンテナの中⾝‧連携
18. 第4章 コンテナの中⾝‧連携 第3章の図で、まだ説明していない 4 つ EC2 Socket Mode OpenClaw のコンテナ Claude Slack ④ Slack との連携。別のスレッドも 読める？ GitHub（repo） ① コンテナの中⾝（3 つのユーザー） ③ GitHub App の秘密鍵を使った接 EBS（volume） ② volume の外に置いた Secret Secret コンテナの外にある保存場所 続
19. 第4章 コンテナの中⾝‧連携 コンテナの中は、3 つのユーザー ユーザー ファイルやプロセスの持ち主。ほかのユーザーの情報を読めるかは、ユーザーごとに決まる プロセス 動いているプログラムの実体。どのユーザーの権限で動くかが、プロセスごとに決まる OpenClaw のコンテナ root node ghbroker entrypoint.sh（起動時のみ） Gateway GitHub の broker 起動の準備をして、Gateway になる OpenClaw の中⼼。Slack と接続し、 Claude を呼び、記憶を管理し、コマンド を実⾏する Slack の broker このあと説明 このあと説明
20. 第4章 コンテナの中⾝‧連携 起動直後と、起動後 図1 起動直後 root 図2 node ghbroker 起動後 root entrypoint.sh node ghbroker Gateway 権限を下げて node node で ghbroker 起動 で起動 へ移る 起動の準備をするプ ロセスは残らない Slack の broker entrypoint.sh が、2 つの broker を起動する GitHub の broker Slack の broker GitHub の broker 同じプロセスが、node に下がって Gateway になる
21. broker ＝ Agent の代わりに、Secret を使って外部の API を呼ぶプロセス ghbroker: 秘密鍵を、別のユーザーに持たせる EC2 上の Secret ファイル（root だけが読める） projecta-broker.env 起動時に読む OpenClaw のコンテナ root node entrypoint.sh ghbroker ① 秘密鍵を渡して起動 Gateway GitHub の broker ② 秘密鍵を消し、権限を下げて Gateway に なる 秘密鍵 （環境変数） Agent が実⾏するコマンド × ③ node からは読めない 同じユーザーなら環境変数を読めるが、別ユーザー
22. 第4章 コンテナの中⾝‧連携 — GitHub の broker（ghbroker）を使うとき Agent の⼿元に来るのは、短期の token だけ ⑤ その token で gh を実⾏ GitHub ② 秘密鍵で署名して頼む ③ 短期の token OpenClaw のコンテナ root node ghbroker Gateway GitHub の broker 起動後は、何も残らない 秘密鍵 （ここから出ない） Agent が実⾏するコマンド（gh） ① token を頼む ④ token を受け取る
23. 第4章 コンテナの中⾝‧連携 — ④ Slack との連携 Slack とは、Socket Mode でつながっている EC2 Socket Mode とは Slack メンションされた メンション OpenClaw のコンテナ Slack で起きたこと（メ ンションなど）を、 スレッド 返信 Socket Mode コンテナから接続 WebSocket の接続で、ア root node Gateway ghbroker プリに届ける⽅式 接続は、コンテナ側から Slack につなぎに⾏く Slack でメンションする と、Agent が返信してくれ る EBS（volume） → ただし、これだけではで きないことがある
24. 第4章 コンテナの中⾝‧連携 — ④ Slack との連携 ④ Slack との連携で、別のスレッドは読める？ EC2 答え Slack Socket Mode メンションされた コンテナから接続 OpenClaw のコンテナ 読めない スレッド 別のスレッド × 中⾝を読めない 公式の Slack プラグイン root node Gateway は、トークンを接続‧イベ ghbroker ント受信‧返信にしか使わ ない できないことの例 • 別スレッドの中⾝を読む • チャンネルの履歴を読む • メンバー情報を取得する EBS（volume） → そこで、Slack の broker を置いた
25. 公式の接続ではできない操作を、Agent に代わって Slack の API で⾏う Slack の broker がやること Slack Socket Mode（メンション‧返信） Slack の API を呼ぶ（公式の接続ではできない操作） OpenClaw のコンテナ root node Gateway ghbroker Slack の broker 許可したチャンネル だけ 頼む スレッドの中⾝を読む slack-thread-context チャンネルの履歴を読む slack-channel-history メンバー情報を取得する slack-channel-members 結果を返す（トークンは返さない） GitHub の broker
26. 05 deployの流れ
27. 第5章 deployの流れ — 第3章の図の ① ② の⽮印を⾒る deploy で、何が、どこに届くのか GitHub config/ A A: image に 焼き込む scripts/ OpenClaw の コンテナ image コンテナの元。作り直す Dockerfile volume（EBS） AGENTS.md B コンテナの外にある保存場所 SOUL.md USER.md C: 触らない（EC2 上） ⼈が書く指⽰書 B: volume に コピーする C D 記憶‧記録 （memory/、sessions/） D: 触らない （volume の中） Secret EC2 上 EC2 A‧B は、deploy が運ぶ（repo にあるもの）。C‧D は、運ばない（repo の外。そのまま残る）。
28. 第5章 deployの流れ — 1〜3: EC2 に届くまで GitHub Actions が、EC2 に deploy を頼む GitHub config/ EC2 の scripts/ root Dockerfile 1 ⼈が GitHub Actions を実⾏する 2 OIDC で AWS のロールを借りる（⻑期の鍵は置かない） 3 SSM で、EC2 の root に 3 つを送る OpenClaw の コンテナ node ghbroker AGENTS.md SOUL.md USER.md SSM で届いた 3 つ ⼈ 1 SHA GitHub Actions 2 取得⽤ 取り込み⽤ AWS（SSM） SHA deploy するコミットのID 取得⽤ node に GitHub から取ってこさせるスクリプト 取り込み⽤ Secret EC2 上 root が照合して取り込むスクリプト 3 EC2 に届くのは、SHA とスクリプトだけ。コードの中⾝は送らない。 EC2
29. 第5章 deployの流れ — 4〜7: 取得と検証 取得は node、検証は EC2 の root GitHub config/ EC2 の scripts/ root Dockerfile 5 node が、ghbroker の token で GitHub から取得 SHA 4 root が node に、取得⽤スクリプトを実⾏させる SHA OpenClaw の コンテナ node ghbroker 6 node が bundle を root に返す（中⾝は信⽤しない） AGENTS.md SOUL.md USER.md ⼈ GitHub Actions 7 root が、取り込み⽤スクリプトで照合する SHA node が返した bundle のコミットの SHA と、SSM で届いた SHA を⽐ SSM で 届いた 3 つ べる。 SHA 完全に⼀致したときだけ取り込む 検証から反映までは、EC2 の root が、node から触れない場所で、⼀ 取得⽤ 続きに⾏う Secret EC2 上 取り込み⽤ AWS（SSM） EC2 の root は、GitHub と通信しない。外と話すのは node だけ。 EC2
30. 第5章 deployの流れ — 8〜12: 反映と起動 EC2 の root が反映し、作り直して起動する GitHub config/ EC2 の 焼き込む scripts/ root Dockerfile 11 9 image 焼き込んで作り直す SOUL.md USER.md OpenClaw の コンテナ node volume（EBS） AGENTS.md コンテナの元になる コピー コンテナの外にある保存場所 ⼈が書く指⽰書 10 マウントする 12 ghbroker 作り直して起動 記憶‧記録は 合流 そのまま残る 記憶‧記録 （memory/、sessions/） ⼈ 保存した世代 image‧ GitHub Actions AWS（SSM） Secret 触らない ファイル‧記録 8 今動いている世代を、1 つだけ保存 EC2 8 今の世代を 1 つ保存 9 検証済みのコードに置き換える 10 指⽰書をコピー deploy が触らないもの 11 焼き込んで、コンテナを作り直す 12 healthy と SHA を確認 Secret と、記憶‧記録
31. 06 コンテナが壊れたときの対処
32. 第6章 コンテナが壊れたときの対処 コンテナが⽌まると、通常の deploy は通らない 5 GitHub config/ EC2 の image scripts/ root コンテナの元。作り直す Dockerfile volume（EBS） AGENTS.md コンテナの外にある保存場所 SOUL.md ⼈が書く指⽰書 USER.md ⼈ SSM で 届いた 3 つ docker exec 4 できない × OpenClaw の コンテナ node ghbroker 6 ⽌まっている 記憶‧記録 （memory/、sessions/） SHA GitHub Actions 取得⽤ 取り込み⽤ AWS（SSM） 取得する node と、token をくれる ghbroker は、⽌まったコンテナの中にいる。だから 4 で⽌まり、5‧6 には進まない。 直すための deploy が、壊れたコンテナに依存している。 EC2
33. 第6章 コンテナが壊れたときの対処 — どう復旧するか 取得と検証を迂回して、保存した世代から戻す GitHub config/ EC2 の image scripts/ root コンテナの元。作り直す OpenClaw の コンテナ Dockerfile node ghbroker volume（EBS） AGENTS.md コンテナの外にある保存場所 SOUL.md ⼈が書く指⽰書 healthy を確認 USER.md 作り直す 記憶‧記録 ⼈ 1 Actions: rollback 2 AWS（SSM） （memory/、sessions/） 保存した世代 image‧ ファイル‧記録 保存した世代で戻す 3 4〜7 番（取得と検証）を迂回して、保存した世代から直接コンテナを作り直す。GitHub、node、ghbroker は使わない。 保存した世代は、第5章の 8 で、deploy のたびに保存していたもの（検証を通ったものを取り込む直前に、1 つだけ）。 EC2
34. プロジェクトに伴⾛する Agent を、安全に動かし続けるために まとめ 01 やりたいこと Slack の⽂脈を読んで、プロジェクトに伴⾛する Agent を 1 つ置く 02 結果 Slack の⽂脈を把握して会話もできる、プロジェクトに伴⾛する Agent を置けた 03 全体構造 ⼈が編集する部分は GitHub、Agent に任せる部分は volume に分けた 04 連携 Secret は broker だけが持つ。Agent には短期の token や結果だけを渡す 05 deploy 取得は node、検証と反映は EC2 の root。SHA が⼀致したものだけを取り込む 06 復旧 ⽌まると通常の deploy で直せない。別経路⽤にバックアップを残している（⼀応の対策） ありがとうございました
35. 補⾜ コンテナの中⾝‧連携 — token ファイル broker は、誰の依頼でも受けるのか？ ここまでの説明 でも そこで Secret は broker が持ち、 待ち受けているだけだと、コ broker に頼んでよい⼈だけを Agent は broker に頼むだ ンテナの中のプロセスなら、 受け付ける。その⽬印が け。broker は、コンテナの中 誰でも broker に頼めてしま token ファイル。読めるプロ で待ち受けている う。Secret を使った操作を、 セスだけが、頼める 誰にでもさせてしまう 次の 2 枚で、GitHub の broker と Slack の broker が、token ファイルをどう置いているかを⾒る
36. 補⾜ 第4章の図に、token ファイルを⾜す GitHub の broker: token ファイルの流れ token ファイルとは broker に頼んでよい⼈の⽬印。 Secret そのものではない。 動くユーザー: ghbroker 待ち受け: コンテナの中だけ broker が持つ Secret: GitHub App の秘密鍵 GitHub OpenClaw のコンテナ root このあと GitHub に頼む node ghbroker Gateway GitHub の broker 起動後は、何も残らない 秘密鍵 （ここから出ない） 3 1 起動時に作る 2 Agent が実⾏するコマンド（gh） ① 起動時に、broker が token ファイルを作る ② gh の wrapper が、token ファイルを読む（node も読める） token ファイル ghbroker が作る‧node も読める ③ token ファイルの内容を添えて、broker に token を頼む このあとの流れは、前の図（短期の token だけ）と同じ
37. 補⾜ 第4章の図に、token ファイルを⾜す（例: スレッドを読む） Slack の broker: token ファイルの流れ token ファイルとは 動くユーザー: node 待ち受け: コンテナの中だけ broker が持つ Secret: Slack のトークン Slack broker に頼んでよい⼈の⽬印。 Secret そのものではない。 4 Slack の API を呼ぶ（conversations.replies） OpenClaw のコンテナ root node ghbroker Gateway Slack の broker 許可したチャンネル だけ 1 token ファイル node だけが読める 5 3 GitHub の broker 2 slack-thread-context ① 起動時に、broker が token ファイルを作る ② コマンドが、token ファイルを読む ③ token ファイルの内容を添えて、スレッドの内容を頼む ④ broker が Slack の API を呼び、スレッドを受け取る ⑤ スレッドの内容を、コマンドに返す（トークンは返さない）