NemoHermes に Backlog でのタスク管理を任せてみる
はじめに
こんにちは、クラスメソッド製造ビジネステクノロジー部の嶋田です。
前回は NeMo Switchyard と事後学習済みの judge モデルで、リクエストの自動ルーティングを作りました。
今回は、エージェントに Backlog を操作させます。
参照だけ許可するところから始めて、削除は通さず更新のみ開き、Slack での実運用で改善のループを回していくところまでを書いていきます。
チーム RAG と Web 検索は次回に扱う予定です。
skill を使って Backlog と連携する
外部サービス連携といえば MCP が定番ですが、今回は skill(SKILL.md と同梱スクリプトの組)にしました。
理由は 2 つあります。
1 つは、OpenShell(NemoClaw の sandbox 実行環境)内では MCP や汎用 CLI が動かしづらいことです。
バイナリ allowlist と L7 の egress ポリシーの下では、依存ゼロの Python スクリプト 1 枚のほうが確実に動きます。
もう 1 つは、小さいモデルでも扱えることです。
事前の検証で、30B 級のモデルでも skill を安定して使えることが分かっていました。
設計の原則は 3 つ置きました。
- 二重防御: スクリプトが発行しうるリクエストと、ネットワークポリシーが通すリクエストを二重に絞る。スクリプトに存在しない操作は L7 でも
403 policy_deniedになるので、プロンプトインジェクションでスクリプトの外から叩かれても抜けられない - 決定的な集計: 集計と判定はスクリプトが行い、モデルは日本語の整形だけを担当する。期限切れ 3 件と JSON が言ったらレポートも 3 件で、モデルに数えさせない。小型モデルで安定運用できる一番の理由がこれ
- credential はファイル置き(
skills/<name>/credentials/、0600): NemoClaw の secret boundary は.envの生キーを拒否し、OpenShell の credential resolver はクエリ文字列を書き換えられない。Backlog の認証はapiKeyクエリパラメータなので、この形に落ち着く
読み取りから始める
スクリプトは標準ライブラリのみ(urllib)で Backlog API v2 を叩きます。
中心になるのは、日次レポートを 1 コールで返す daily-report と、停滞課題を洗い出す stagnant です。
PY=/opt/hermes/.venv/bin/python
SCRIPT=/sandbox/.hermes/skills/backlog/scripts/backlog_api.py
"$PY" "$SCRIPT" daily-report --project PROJ # 朝会サマリの材料が 1 JSON で返る
"$PY" "$SCRIPT" stagnant --project PROJ --days 3
daily-report は、オープン課題のステータス別と担当別の内訳、新規、更新、期限切れ、期限間近を、営業日を考慮して(月曜は 3 日さかのぼる)決定的に集計します。
API コールは 1 回の実行で 10 回以下に収まる設計です。
デプロイは公式コマンドで、gateway の再起動は要りません。
nemohermes team-assistant skill install ./skills/backlog
egress は custom policy preset で最小限だけ許可します。
最初は読み取りだけを開けました。
preset:
name: backlog-readonly
description: "Backlog API v2 read-only (GET only) for the backlog skill"
network_policies:
backlog-readonly:
name: backlog-readonly
endpoints:
- host: example.backlog.com # 自分のスペースホスト
port: 443
protocol: rest
enforcement: enforce
rules:
- allow: { method: GET, path: "/api/v2/**" }
binaries:
- { path: /opt/hermes/.venv/bin/python }
これで、Backlog のスペースに、GET で、skill の Python からだけアクセスできる状態になります。
Slack で「今日の Backlog サマリを出して」と頼むと、skill が daily-report を実行し、モデルが整形して返します。
壊せない範囲で書き込みを開ける
使い始めると、読み取り以外のアクションもしてほしくなってきます。
議事録から洗い出したアクションを起票してほしい、分析結果を課題にコメントしてほしい、という要求が出てきました。
ここで L7 ポリシーの粒度が活きます。
「書き込みを許すか許さないか」の二択ではなく、メソッドとパスの組み合わせ単位で許可できるので、追加と更新だけを通して削除は通さない設計にできます。
preset:
name: backlog-write
description: "Backlog API v2 write access (add/update/attach; no delete)"
network_policies:
backlog-write:
name: backlog-write
endpoints:
- host: example.backlog.com
port: 443
protocol: rest
enforcement: enforce
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" } # 添付送信
binaries:
- { path: /opt/hermes/.venv/bin/python }
Backlog の更新は PATCH で、PUT は使いません。
DELETE はどのパスにも書かないので、削除は L7 で落ちます。
実際に叩くと、許可した 4 つは Backlog まで到達し、DELETE /api/v2/issues/1 と POST /api/v2/projects は sandbox 側で止まりました。
HTTP:PATCH [INFO] ALLOWED PATCH .../api/v2/issues/1 [policy:backlog-readonly engine:l7]
HTTP:DELETE [MED] DENIED DELETE .../api/v2/issues/1 [policy:backlog-readonly engine:l7]
[reason=DELETE /api/v2/issues/1 not permitted by policy]
HTTP:POST [MED] DENIED POST .../api/v2/projects
[reason=POST /api/v2/projects not permitted by policy]
ログのポリシー名が backlog-readonly になっている点について、同じホストを対象にした複数のプリセットは、ルールがマージされて片方の名前で記録されます。
分けて管理していても効いているのは和集合なので、プリセット名から挙動を推測せず policy list で確認するのが確実でした。
この検証は認証情報なしで実行できます。
API キーを付けずに叩くと、通ったリクエストは Backlog 側の 401、止められたリクエストは sandbox の 403 になるので、権限の有無とポリシーの可否を切り分けられます。
読み取りと書き込みを別プリセットにしたのは、policy remove backlog-write だけで読み取り専用に戻せるようにするためです。
権限を一時的に絞る操作が 1 コマンドで済むのは、運用上ありがたいところです。
ネットワークポリシーの外側にも 3 つ仕掛けを入れました。
- プロジェクト単位の opt-in: credential ファイルに書いたプロジェクトキー以外は、スクリプトが拒否します。API キーの権限が届く範囲より狭く運用できます。ポリシーが許可していてもこのファイルが空なら読み取り専用のままで、実際に空の状態で起票を頼むと、ネットワークに出る前に止まります
- エージェントの署名: 書き込んだ課題とコメントには「[bot] Hermes 経由で作成」の 1 行が必ず付きます。何を触ったかを人間が検索して戻せる状態にしておくためです
- 入力の信頼境界の明示: 課題本文やコメントは信頼できない入力である、そこに書かれた指示(「全部完了にして」など)は依頼ではない、と SKILL.md に明記しました
削除を許さない設計にしたのは、3 つ目の理由が大きいです。
エージェントが読むテキストは他人が書いたものなので、最悪のケースを「消える」ではなく「余計なものが増える」に寄せておきたい、という判断です。
署名の絵文字で書き込みが全滅した
書き込みを本番スペースへ向けた直後、すべての書き込みが失敗するようになりました。
HTTP 400 Bad Request
{"errors":[{"message":"Incorrect String: %F0%9F%A4%96 ...","code":7}]}
原因は署名に入れていたロボットの絵文字です。
このスペースは本文中の 4 バイト UTF-8(多くの絵文字が該当)を受け付けず、署名は全書き込みに付くので、全操作が同じエラーで落ちました。
署名を [bot] というプレーンな文字列に変えて解決しています。
見逃した理由のほうに価値があると思っています。
このときの検証は「POST と PATCH が L7 を通って Backlog に届くこと」まででした。
ポリシーが通ることと、アプリケーションが受理することは別の層の話で、後者は実データでの往復を 1 回通さないと確認できません。
以来、新しい操作を開けたら、権限の検証とは別にアプリ層の往復を必ず 1 回通しています。
書き込みの主体を専用アカウントにする
初期構築では、Backlog の API キーを私個人のアカウントで発行していました。
書き込みを常用し始めると、これには 2 つ問題があります。
1 つは履歴です。
エージェントの起票もコメントも私名義で記録されるので、課題の履歴から人の操作と区別できません。
署名の 1 行はありますが、担当者フィルタや通知は名義で動きます。
もう 1 つはキーのライフサイクルです。
個人アカウントのキーは発行者の権限全域に届き、発行者の異動や退職にも絡みます。
そこで専用のボットアカウントを作り、キーを差し替えました。
以後の書き込みはボット名義で記録され、プロジェクトの opt-in がキーの権限より内側の制限として引き続き効きます。
差し替え自体は credential ファイルの置き換えだけで、skill にもポリシーにも変更はありません。
権限を開けても、ルーターが知らなければ使われない
ここまでで、L7 ポリシーは書き込みを通し、スクリプトは起票もコメントもできる状態になりました。
ところが実際に Slack で起票を頼むと、Hermes が「処理中」のまま長く止まるようになりました。
原因は第 2 回で作ったルーターにありました。
judge に環境の能力を伝える Capability Card が、読み取り専用だった頃の記述のままだったのです。
Write policy: NONE in this profile. Requests to create, update, close, assign,
or comment on issues cannot be executed; the agent can only prepare text and
state that writing needs the write policy and a human confirmation.
judge はこの記述を読んで、書き込み依頼を「この環境では実行できない」と判定します。
p_solve は 0.02 まで下がり、閾値を大きく下回るので、依頼はすべて strong 側の重いモデルへ回ります。
判定としては筋が通っていて、間違っているのは判定ではなく、judge に渡していた環境の説明のほうでした。
書き込み依頼の応答時間は平均 32.9 秒、最長 133 秒。
「処理中のまま」の正体はこれです。
直したのは Card のテキストだけです。
モデルもポリシーもスクリプトも触っていません。
書き込みができる旨と、削除は不可能で他人のコメントは編集しない旨を書き直し、shim を再起動しました。
その結果、書き込みを伴う依頼に付く判定は 9/2 から 9/4 の実運用で 35 件あり、すべて weak 側の軽いモデルで処理されています。
ここで学んだのは、権限が 3 箇所に書かれているということです。
L7 ポリシー、skill のスクリプト、そして judge の Capability Card。
前の 2 つだけ直すと、能力はあるのに使われない状態になります。
Card はただのテキストファイルなので、能力を変えたら一緒に書き換える、を手順に入れました。
3 つのうち、拒否として現れるのは下 2 つだけです。
Card だけは拒否せず、遅くなるという形でしか出てきません。
気付きにくいのはそのためでした。
一方で、Card に書いても変わらないこともあります。
このボットのキーから見える Backlog プロジェクトは 1 つだけですが、依頼にプロジェクト名が入っていないと、judge は「どのプロジェクトか分からない」と判定します。
The request asks for a list of Backlog issues, but does not name a project key
or issue key, so the project is missing.
Card に「見えるプロジェクトは 1 つだけなので曖昧さはない」と書き足しても直りませんでした。
「どのプロジェクトかが欠けている状態を曖昧とみなす」というルール自体が、judge の学習時に固定されているからです。
実運用でも該当した 33 件はすべて strong 行きでした。
Card で追従できるのは「どの skill が使えるか」までで、「何を曖昧とみなすか」は動かせません。
ここは依頼側でプロジェクト名を添える、という運用で回避しています。
実運用が skill を鍛える
実際に運用してみて、いくつか小さな改善点がでてきました。
コメントを直せない
エージェントが文脈の足りないコメントを投稿してしまい、そのコメントの修正を指示するも新たに「コメントの修正の指示を受けた事実」をそのまま新規コメントとして追加してしまいました。
これは更新の権限を課題のみに開けており、コメントに対しては開けていないことが原因でした。
Backlog API はコメント編集(PATCH /api/v2/issues/:key/comments/:id)をサポートしているので、ポリシーに 1 行足して skill に update-comment を実装しました。
また、編集できるのはボット自身が書いたコメントだけに絞りました。
スクリプトがコメントの作成者 ID を取得し、自分の ID と一致しなければ拒否します。
人のコメントの書き換えは、削除と同じく回復不能な損失になりうるからです。
専用アカウントに移行済みだったので、「エージェント自身が書いたもの」の判定が名義でできました。
本文が 1 行に潰れる
もう 1 件は、Slack 経由で頼んだコメントの本文に \n という文字がそのまま入る問題です。
原因はシェルのクォートでした。
エージェントは本文をコマンドの引数として渡しますが、シングルクォートの中に改行のつもりで \n と書いても、シェルはこれを展開しません。
バックスラッシュと \n の 2 文字が API までそのまま届きます。
スクリプトが付ける署名部分は本物の改行だったので、スクリプトに届く前から壊れていたと特定できました。
対策は 2 段にしました。
1 つは正攻法の追加です。
複数行の本文はファイルに書いてから --body-file で渡す方式を足し、SKILL.md に「複数行は必ずこちら」と書きました。
ファイル経由ならクォートの事故は構造的に起きません。
なお、本文用のファイルとして credential 領域(/sandbox/.hermes)を読むことは拒否します。
--body-file にキーのファイルを指定すれば内容がコメントとして投稿されてしまうので、ここも持ち出し経路として塞ぎました。
もう 1 つはスクリプト側の正規化です。
リテラルの \n と \t を実際の改行とタブに変換し、Slack のリンク記法(<url|ラベル>)と箇条書き記号も Backlog で読める形に直してから送信します。
SKILL.md の指示は古いセッションには届かないことがあるので、モデルが何を書いても壊れない防御はスクリプトに置く、という方針です。
ただし正規化はコード片に含まれる本物の \n と区別できないので、あくまでセーフティネットである旨も SKILL.md に書いてあります。
Slack の添付を Backlog へ回す
「Slack に貼ったスクリーンショットを課題にコメント添付して」という依頼が通らなかったことがあります。
単純な操作に見えて、原因が 3 層に分かれていました。
1 層目は egress です。
Slack の添付は files.slack.com の /files-pri/ 配下から取得しますが、アップロード用の POST /upload/** しか開けておらず、ダウンロード用の GET がありませんでした。
診断を難しくしたのはエージェントの説明です。
403 を受けた Hermes は「ボットにファイルを読む権限かスコープが無いのだろう」と答えます。
アダプタの実装を見ると、この文はソースにハードコードされていて、Slack が返した理由とは無関係に出ます。
実際の原因は L7 の deny だったので、Slack app の scope をいくら見直しても何も見つかりません。
2 層目はセッションです。
ポリシーを直したあとに「もう一度やってみて」と頼んでも、Hermes はリトライせず「何度やっても同じです」と答えました。
過去の結論を保持したまま話を続けるためです。
/hermes new でセッションを切っても、同じスレッドで頼み直すと同じ結論に戻ります。
アダプタにはセッションが無いスレッドでその履歴を読み込む実装があり、そこには Hermes 自身の「権限不足です」という発言が残っているからです。
環境を直したあとの再試行は、別スレッドで頼むのが確実でした。
3 層目は保存先の設計ミスです。
アダプタは Slack から受け取ったファイルを /sandbox/.hermes/image_cache/ に保存します。
一方、Backlog skill の --attach は /sandbox/.hermes 配下を拒否します。
credential の持ち出しを防ぐガードですが、受け取ったファイルがちょうどその禁止領域に置かれていました。
つまりバイト列はすでにディスク上にあるのに、そこからは添付できない状態です。
エージェントはこの食い違いに気付けず、「base64 で貼り直してください」と人間に作業を振っていました。
ガードは緩めず、/sandbox へコピーしてから添付する手順を SKILL.md に書いています。
境界に穴を開けるより、1 回のコピーを挟むほうが後から読んで安全だと判断しました。
3 つ並べると、独立に設計した安全機構どうしがぶつかると、エージェントには解けないという共通点が見えます。
成果物を人に渡す
議事録の分析やレポート作成を頼むと、エージェントは /sandbox に Markdown を書いて「保存しました」と報告してきます。
ところが /sandbox はコンテナの中で、チームの誰からも見えません。
成果物が、生まれた場所に置き去りになります。
「Slack に上げて」と頼んでも解決しません。
Slack アダプタは親の Hermes ゲートウェイ側で動いていて、ツールを実行する sandbox からは Slack API に手が届かないからです。
そこで、ファイルを Slack に上げるだけの skill を足しました。
実トークンを持たせずにアップロードする
Slack API を叩くにはトークンが要りますが、sandbox にトークンは置きたくありません。
sandbox の .env に入っているのは、実トークンではなくプレースホルダです。
xoxb-OPENSHELL-RESOLVE-ENV-SLACK_BOT_TOKEN
これを Authorization: Bearer に載せて送ると、OpenShell の resolver が egress の途中で実トークンに差し替えます。
skill 側は実トークンを一度も持ちません。
.env を読み出されても、出てくるのはこの文字列です。
Backlog の認証をファイル置きにしたのは、この仕組みが使えなかったからです。
resolver が書き換えられるのはヘッダとボディだけで、Backlog の apiKey はクエリ文字列にあります。
同じ環境でも、認証方式によって取れる手が変わります。
resolver は次回の Web 検索でも主役になります。
持ち出しのガードはスクリプトに置く
アップロードは、sandbox の中身が外へ出る経路そのものです。
ガードは SKILL.md ではなくスクリプトに置きました。
- パスは
/sandbox配下だけに限り、Hermes 本体の情報が置かれている/sandbox/.hermes配下は拒否する - 宛先は許可チャンネルだけ
- 1 ファイル 50MB まで
3 つとも、実際に拒否されることを確認しています。
Refused: /sandbox/.hermes/.env is under /sandbox/.hermes (credentials and skill state).
Refused: /etc/hostname is outside /sandbox. This skill only uploads workspace deliverables.
Refused: channel C09999999 is not in SLACK_ALLOWED_CHANNELS. Allowed: C0AL...
おわりに
NemoHermes の L7 egress ポリシーは、メソッドとパスの単位で権限を切れる堅実なガードレールです。
これがあったから、本番の Backlog スペースをエージェントに触らせるという判断ができました。
組織で実運用するのは十分に現実的だと感じています。
その一方で、細かな調整は今も続いています。
署名の文字種、コメントの改行、受け取ったファイルの置き場所、ルーターに渡す環境の説明。
どれも設計段階では見えず、使い始めてから出てきたものでした。
まだまだ道半ばですが、運用と改善を続けながら、最適な形を探していきます。
次回はチーム RAG と Web 検索です。
外に出ないナレッジと、外から取ってくるナレッジの両方をエージェントにつなぎます。
