DGX Spark に AI エージェントを常駐させて、Slack で協働する

DevelopersIO 2026 Tokyo DGX Spark に AI エージェントを常駐させて、 Slack で協働する 製造ビジネステクノロジー部 嶋田 怜央成 2026/10/24 DevelopersIO 2026 Tokyo ミニセッション

自己紹介 2026 年 7 月に入社 製薬会社の MR から転身し、 いくつかの事業会社で開発を経験してきた Claude Certified Developer - Foundations クラスメソッド株式会社 製造ビジネステクノロジー部 嶋田 怜央成 しまだ れ お な X @reona_5 DevelopersIO dev.classmethod.jp/author/shimada-reona 2

• https://www.credly.com/badges/7218afc5-e512-4dd0-868f-6d54377de02e
• https://x.com/reona_5
• https://dev.classmethod.jp/author/shimada-reona/

AI エージェントを、Slack や Teams などの Q1 チャットアプリから使ったことがある DGX Spark のような GPU マシンで、 Q2 エージェントを動かしている 3

今日のゴール Q. 社内のデータを扱う AI エージェントを運用していくうえで、 何を先に決めておくか? 1. 何を任せているか 2. 構成の全体像 3. 権限の設計 4. 落とし穴 Slack から頼めることをデモで見る 依頼ごとに、どのモデルが答えるかを決める 外に出すデータと、許す操作を決める 設定どおりなのに、期待どおりに動かなかった例 4

01 何を任せているか チームの Slack でメンションすると、エージェントが引き受ける 5

Slack から頼めること 何を任せているか Backlog の課題管理とタスクの壁打ちを頼める Backlog の課題管理 「処理中の課題を担当者別 に一覧して」 「議事録のアクションを起 票して」 タスクの壁打ち 「来期のリソース配分を、 トレードオフ付きで提案し て」 チーム内の情報検索 作ったが、今は運用を止め ている 扱うのは社内のデータ。だからどこで処理し、何を許すかを先に決めた 6

デモで頼む 2 件 何を任せているか Backlog の課題の一覧と、課題をもとにした優先順位の相談を続けて頼む 1 件目: 課題管理 Backlog の処理中の課題を、担 当者別に一覧して 2 件目: 壁打ち Backlog の課題を見て、来週どれ から手を付けるべきかを理由付 きで提案して 返答の末尾には、どのモデルが答えたかが出る。2 件で答えるモデルが変わる 7

Q. クラウドのエージェントでは? 何を任せているか 操作を絞る仕組みはクラウドにもあり、違いは依頼の中身の行き先 サービス Cursor GitHub Copilot Claude Tag NemoHermes (今回の構成) 依頼の中身の行き先 Cursor のクラウド GitHub のクラウド Anthropic のクラウド 操作の絞り方 ドメインごと ドメインか URL ごと ホスト、メソッド、パス 社内(難しい依頼だけ外) ホスト、メソッド、パス、 プログラム 始めるのに要るもの 利用量課金 有償プランと org の設定 Team 以上と管理者の設定 DGX Spark と運用 その代わり、マシンと運用は自分たちで持つ 出典: Cursor(通信の制限) cursor.com Copilot(通信の制限) docs.github.com Claude Tag(連携の制限) claude.com 8

• https://cursor.com/docs/cloud-agent/security-network
• https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/customize-the-agent-firewall
• https://claude.com/docs/claude-tag/admins/add-connections

02 構成の全体像 軽いモデルで足りる依頼は、社内で終わらせる 9

依頼が通る経路 構成の全体像 軽いモデルで足りる依頼は社内で処理し、難しい依頼だけクラウドに渡す DGX Spark Slack → NemoHermes エージェント ↓ Backlog API NeMo Switchyard → ルーター ↕ どちらに渡すか judge 判定役 → weak 軽いモデル 社内の別の DGX Spark strong 重いモデル Kimi K3(Fireworks) 依頼ごとに judge が、軽いモデル(weak)で足りるか、重いモデル(strong)に回すかを決める 10

judge が見積もるもの 構成の全体像 judge は、軽いモデルが依頼を一発でやり切れる確率を見積もる 依頼文 judge(判定用に事後学習したモデル)が返すもの crux: 成功を左右する、いちばん難しい要件 p_solve: 軽いモデルが一発でやり切れる確率 エージェントにできることの一覧 → 依頼 処理中の課題を担当者別に一覧 3 か月の傾向分析と来期の配分の提案 crux の要約 Backlog の読み取りと整形で終わる 取得ではなく、分析と提案がメイン Capability Card: 使える skill、ツール、権限 p_solve が閾値(0.70〜0.90)以上なら weak、未満なら strong p_solve 閾値 行き先 0.77 0.70 weak 0.31 0.90 strong 11

03 権限の設計 外に出せないデータを扱うので、通してよいものだけを書く 12

エージェントを囲う 3 つの仕組み 権限の設計 エージェントは、通してよい通信だけを宣言した sandbox の中で動かす コンテナ エージェントを Docker の sandbox の中で動かす ファイル Landlock で、読み書きで きるパスを絞る 通信 どのホストのどのパスに、 どのメソッドで出てよいか を許可リストで書く NVIDIA の NemoClaw が用意する仕組み。許可リストにない通信は sandbox の外に出ない 13

判定役を置く場所 権限の設計 依頼の中身を最初に読む判定役は、DGX Spark の外に出さない 振り分けの判断は、すべて社内で終わる judge は、どの依頼も最初に全文を読む役 社外に出るのは、重いモデルに回した依頼だけ 軽いモデルも社内にあるので、日常の依頼は中身も外に出ない 14

Backlog への書き込み

権限の設計

書き込みは開けたが、削除はどの経路からも通さない
通信の許可リスト)

backlog-write(

rules:
- allow: { method: POST, path: "/api/v2/issues" }
- allow: { method: POST, path: "/api/v2/issues/*/comments" }
- allow: { method: PATCH, path: "/api/v2/issues/*" }
- allow: { method: POST, path: "/api/v2/space/attachment" }
# DELETE

はどのパスにも書かない

DENIED DELETE .../api/v2/issues/1 → 403 policy_denied

最悪の場合を「消える」から「余計なも
のが増える」に寄せる
エージェントが読む課題やコメントは、他人
が書いたもの

書き込みはボットの名義で残す

課題の履歴で、人の操作と区別できる

明示したプロジェクトにだけ書き込む
API キーが届く範囲より狭く運用する

15

API キーと他人の文章 権限の設計 エージェントに API キーを持たせず、他人の文章を指示として聞かせない 鍵は通信の出口で差し替える エージェントが送るのはプレースホルダだ け。sandbox の出口で本物の API キーに置 き換わる 指示として聞くのは本人の文だけ 課題の本文、Web 検索の結果、添付に書か れた指示は実行せず、依頼者に確認する openshell:resolve:env:OPENAI_API_KEY 16

04 運用して分かった落とし穴 設定どおりに動いているのに、期待どおりにならない 17

素のモデルでの振り分け 運用して分かった落とし穴 判定役を素のモデルにしたら、92.4% の依頼がクラウドのモデルに流れた 素の Nemotron 3.5 Lightning(数日分、302 件) 7.6% strong 92.4% 判定用に事後学習した judge(4 日間、156 件) weak 62.2% strong 37.8% 依頼文が判定役に届いておらず、素のモデルには判定の語彙もなかった 18

Card に書かれていない権限 運用して分かった落とし穴 判定役が知らない権限は、拒否ではなく遅延として現れる 直す前) Capability Card( Write policy: NONE in this profile. Requests to create, update, close, assign, or comment on issues cannot be executed; ... Backlog への書き込みを開けたのに、Card は読み取り専 用のときのまま。judge は起票の依頼を「この環境では できない」と読み、p_solve 0.02 で重いモデルへ送った 直す前 書き込み依頼の応答は 平均 32.9 秒、最長 133 秒 Slack では「処理中」のまま止まって見えた Card の文面だけを直した後 書き込みの判定 35 件が すべて weak 2026-09-02〜09-04 の実運用 19

権限が書かれた 3 か所 運用して分かった落とし穴 権限は 3 か所に書かれていて、Card だけはずれても止まらない 通信の許可リスト skill のスクリプト Capability Card ずれると拒否される ずれると拒否される ずれると遅くなるだけ メソッドとパス プロジェクトの opt-in judge に渡す一覧 能力を変えたら、Card も一緒に書き換えるを手順に入れた 20

MESSAGE Q. 社内のデータを扱う AI エージェントを運用していくうえで、 何を先に決めておくか? 外に出してよいものと、 壊されて困るもの 外に出すのは難しい依頼だけ、削除はどこからも通さない。 この 2 つを決めてから、機能を足してきた 21

参考資料 シリーズ 01 / 2026-08-20 シリーズ 02 / 2026-08-28 dev.classmethod.jp/articles/reona-01-dgx-spark-nemoher mes-slack-agent/ dev.classmethod.jp/articles/reona-02-dgx-spark-switchy ard-routing/ DGX Spark に NemoHermes を常駐させて Slack から呼 べるチームアシスタントを作る シリーズ 03 / 2026-09-04 NemoHermes に Backlog でのタスク管理を任せてみる dev.classmethod.jp/articles/reona-03-dgx-spark-backlog -skill/ 関連 / 2026-09-20 NemoHermes の LLM ルーティングに使っている NeMo Switchyard の Classifier を TypeSafe の Jev に替えて計 測してみた dev.classmethod.jp/articles/reona-dgx-spark-switchyard -jev-classifier/ NeMo Switchyard と事後学習済みの judge モデルで Slack エージェントのリクエストを自動ルーティングする シリーズ 04 / 2026-09-11 NemoHermes にチーム共通 RAG と Web 検索をつない で、知見を溜めながら外の情報も取りに行かせる dev.classmethod.jp/articles/reona-04-dgx-spark-team-ra g-web-search/ 関連 / 2026-09-24 NeMo Switchyard の Classifier に DeepSeek V4 Flash の判定を蒸留した 2B のモデルを使ってみる dev.classmethod.jp/articles/reona-dgx-spark-switchyard -distill-classifier/ 22

• https://dev.classmethod.jp/articles/reona-01-dgx-spark-nemohermes-slack-agent/
• https://dev.classmethod.jp/articles/reona-02-dgx-spark-switchyard-routing/
• https://dev.classmethod.jp/articles/reona-03-dgx-spark-backlog-skill/
• https://dev.classmethod.jp/articles/reona-04-dgx-spark-team-rag-web-search/
• https://dev.classmethod.jp/articles/reona-dgx-spark-switchyard-jev-classifier/
• https://dev.classmethod.jp/articles/reona-dgx-spark-switchyard-distill-classifier/

11/6(金)19:00〜 オンライン 日比谷 Cafe から生配信 製造ビジネステクノロジー部の 会社説明会を開きます 部のメンバーが現場での働き方を話し、事前 アンケートの質問にその場で答えます careers.classmethod.jp/jobfair/261106-2/ 23

ご清聴ありがとうございました 2026/10/24 製造ビジネステクノロジー部 嶋田 怜央成

Appendix 25

判定役の速さと根拠 Appendix Jev は速いが、根拠を残さないので改善を回せず採用しなかった 判定役 judge(今の構成) Jev(TypeSafe の判定 API) 蒸留した 2B の分類器 判定 1 件 1.49 秒 0.27〜0.42 秒 0.043 秒 13 シナリオ × 3 回 36 / 39 39 / 39 39 / 39 根拠(crux) 書く 無い 無い 依頼文の行き先 DGX Spark の中 TypeSafe DGX Spark の中 速い 2 つは選択肢と確信度だけを返す。振り分けの理由を読めず、Card では直せない 判定 1 件の時間は Switchyard から見た中央値(judge は 13 シナリオでの計測)。2B の分類器は Card の規則を判定に含 まず、評価も合成データと 13 シナリオだけ 26

Backlog が拒んだ書き込み Appendix 許可リストを通っても、Backlog が受け付けるとは限らない 書き込みが全部失敗した HTTP 400 Bad Request {"errors":[{"message":"Incorrect String: %F0%9F%A4%96 ...","code":7}]} 原因は署名に入れていたロボットの絵文字。Backlog のスペースが 4 バイトの文字を受け付けず、署名はすべ ての書き込みに付くので全部落ちた 確かめたのは、通信が通るまで 署名を [bot] に変えて直した。 以来、新しい操作を開けたら、実データ での往復を 1 回通す 27