👀 ひとつで、セキュリティ調査が走り出す——Sysdig Secure のリアルタイム脅威検知におけるインシデントレスポンスを、Factory の Droid で自動化して自宅ラボで試してみた

セキュリティ監視サービスの Sysdig が脅威を見つけて Slack に通知したとき、その通知に 👀 を付けるだけで、Factory の AI エージェント「Droid」が自動で調べて報告する。その仕組みを、TK の自宅のホームラボで試した報告です。

（2026-10-18 実施）

16:12、検証用のコンテナが、攻撃者をまねて「セキュリティソフトを止める」操作をしました。
16:24、Sysdig の通知が Slack の #threats に届きました。
16:28、TK がその通知に 👀 を 1 つ付けました。
そして 16:35、Factory の Droid（AI エージェント）が 9 つのタスクを終え、調査報告 5 通と、報告用のチャンネル #dr への要約 1 通がそろいました。

人が手を動かしたのは、絵文字を 1 つ付けたことだけです。この記事は、その 7 分間に裏で何が起きていたのかを、画面の記録と一緒にたどります。

---

この記事に出てくるもの

本文に入る前に、登場するサービスと道具を紹介します。どれも、この先の章で何度も出てきます。

名前	ひとことで言うと	この仕組みでの役目
Sysdig	サーバーやコンテナを見張る、セキュリティ監視のサービス	怪しい挙動を数秒以内に検知し、関連する検知を相関分析して「Threat（脅威）」にまとめる。Automation の機能を設定して、Threat を Slack に知らせる
Slack	チームのチャットのサービス	Sysdig の通知が届く場所（#threats）。調査の報告もここに返る
👀（目の絵文字）	Slack で投稿に付けるリアクション	「この通知を調べて」という人からの合図
reaction bot	今回作った小さなプログラム（Slack App）	👀 に気づき、Factory に調査を頼む
Factory	AI エージェントにソフトウェアの計画・開発・レビュー・出荷を任せるためのプラットフォーム（この節の最後で詳しく説明）	webhook で依頼を受け、tk-mini2 の Droid に調査を始めさせる
Factory の Droid	Factory の AI エージェント。この記事では単に「Droid」とも書く	調査の手順書に沿って Sysdig などの記録を読み、判定して報告を書く
tk-mini2	TK の自宅にある Mac	Droid が実際に動くコンピューター
nuc-home	TK の自宅にある Kubernetes クラスタ（小型 PC 4 台）	見張られる側。reaction bot もここで動く

つまり、流れは一本です。

Sysdig が見つける → Slack に通知が届く → 人が 👀 を付ける → reaction bot が Factory に頼む → Factory の Droid が調べる → Slack に報告が返る

図 1　全体の流れ。上の段が 6 つのステップ、中の段が今回のテストでの時刻、下の段がだれの仕事か。

図 1 の 6 つのステップは、だれが受け持つかで 3 つに分かれます。① と ② は Sysdig の仕事、③ は人の仕事、④〜⑥ は今回作った仕組みが自動で行う仕事です。人が手を動かすのは ③ の 👀 だけで、④ から先は人が何もしなくても進みます。

この流れを 2026-10-18 に TK の自宅のホームラボで最初から最後まで通して試し、うまく動くかを確かめたのが、今回のテストです。テスト用のチャンネルではなく、ふだん Sysdig の通知が届く #threats を使いました。

Factory と Droid について

この仕組みの中心にいるのが Factory です。Factory の公式サイト（https://factory.com/）と文書（https://docs.factory.com/）をもとに、2026-10-18 時点の内容を紹介します。

Factory とは

Factory は、AI エージェントを使ってソフトウェアを作る会社であり、そのためのプラットフォームの名前です。公式サイトは「Make your software improve itself（ソフトウェアが自分を改良していくようにする）」「Build your autonomous software factory（自律して動くソフトウェア工場を作る）」と掲げています。

ソフトウェアの計画、開発、レビュー、出荷までを、自律して動く AI エージェントに任せる、というのが Factory の考え方です。人は目標と決まり（ポリシー）を決め、AI エージェントが計画し、作り、確かめます。公式サイトは、大事にしていることとして次の 3 つを挙げています。

柱	内容
Control（制御）	どこで動かすか、どう学ばせるか、どのモデルを使うかを、使う側が決められる
Governance（統制）	決まりの範囲の中で、仕組みが自分を改良し続ける
Value（価値）	開発での使われ方と効果を、事業の成果に結び付けて測れる

特定の AI モデルに縛られないことも特徴です。Claude、GPT、Gemini、Grok、DeepSeek、Mistral、Qwen、Llama などから選べ、設定を変えるだけで切り替えられます。今回の調査では Claude Opus 5.5 を選んでいます。

Droid とは

Droid は、Factory の AI エージェントです。デスクトップのアプリ（Factory App）、ターミナル（Droid CLI）、ブラウザ（app.factory.ai）のどこから使っても、同じように動きます。

Droid は、人と会話しながら作業するだけではありません。決まったきっかけで、人の操作なしに動くこともできます。このとき Droid は、つながった外のサービス（connector や MCP）の道具を使い、手順書（SKILL）に沿って作業します。してはいけない操作は、hooks で事前に止められます。

この仕組みで使った Factory の機能

この仕組みは、Factory を 2 つの場面で使っています。1 つは、仕組みを作る場面です。もう 1 つは、今回のテストで調査を動かす場面です。どちらで何を使ったかを、PR の記録と、tk-mini2 に残る Droid の作業の記録で確かめました。

機能	内容	仕組みを作るとき	今回のテスト
Droid のセッション（Factory App・CLI）	人と会話しながら、Droid が作業する	✅ 設計、コード、テスト、文書、PR づくりを、Factory App の Droid と進めた	✅ automation の実行も 1 つの Droid のセッション
サブエージェント	作業の一部を、別の Droid に任せる	✅ 独立検証で、検証役の Droid（worker・explorer）を使った	―
Automations	スケジュール、Slack の投稿、GitHub のイベント、webhook をきっかけに、Droid を自動で動かす	✅ webhook の automation を作り、Droid の道具でプロンプトを差し替えた	✅ webhook をきっかけに調査が動いた
Remote Control	自分で用意したコンピューターを Factory につなぎ、Droid をそこで動かす。Factory の中継サービスを通すので、受け口のポートを開けなくてよい	✅ tk-mini2 をつないだ	✅ 調査は tk-mini2 で動いた
Connectors・MCP	Slack や Sysdig などのサービスとつなぎ、Droid が使える道具を増やす	✅ Slack と Sysdig の記録を読んだ	✅ Slack への投稿、Sysdig の記録の読み取り
SKILL・hooks	Droid の作業の手順と、してはいけない操作の検査を決める	✅ hooks を作り、Sysdig の SKILL を組み込んだ	✅ 手順書に沿い、読み取りだけで調べた

この仕組みの位置づけ

Factory の公式サイトは、Droid が 24 時間動かせる使い方の例として 6 つを挙げています。問い合わせの振り分け、チケットからのコード作成、コードレビュー、QA、障害対応（Incident Response）、文書づくりです。

今回の仕組みは、このうちの**障害対応（Incident Response）**に近い使い方です。Factory の障害対応は「アラートを受けた Droid が原因を調べる」もので、今回はアラートが Sysdig の Threat、調べるきっかけが人の 👀 です。また、今回のテストでは、Droid は読み取りだけで調べ、止める・隔離するといった対処はテストの範囲に入れていません。

---

1. 結果のまとめ

テストは合格です。 攻撃の模擬で起こした新しい Threat の通知に 👀 を付けると、reaction bot が Factory の webhook automation（決まった URL に依頼が届くと、Droid の作業を自動で始める機能）を起動しました。自宅の Mac（tk-mini2）で動く Factory の Droid が、読み取りだけで 9 つのタスクを調べ、スレッドに最終報告 5 通、#dr に要約 1 通を投稿しました。

指標	値
👀 から #dr の要約まで	6 分 54 秒（16:28:52 → 16:35:46）
調査の開始から最終報告まで	6 分 11 秒（16:29:20 → 16:35:31）
操作から Sysdig の検知まで	数秒以内（例：16:13:03 の操作 → 16:13:03 に High の検知）
最後の検知から通知まで（相関分析）	約 11 分（16:13:16 → 16:24:27）
Slack への投稿	受付のお知らせ 1 通、開始 1 通、進捗 9 通、最終報告 5 通、#dr の要約 1 通
調査が環境に加えた変更	0 件（停止・隔離・削除なし。読み取りのみ）
調査の判定	🟡 判断保留（証拠不足）・確信度: 中・危険度: 低

判定が「判断保留」なのは、失敗ではありません。調査は「挙動は実際にあった」「守りは止まっていない」までを証拠で確定させ、「この操作は正当な検証か」だけは記録が足りないとして、TK に判断を返しました。決めきれないことを決めつけない、という設計どおりの振る舞いです（詳しくは 4.6）。

---

2. 背景：なぜ「👀」なのか

Sysdig Secure は、怪しい挙動を検知し、関連する検知を相関分析して Threat にまとめます。そして、Sysdig Secure の Automation（自動化の機能）に「新しい Threat ができたら Slack の #threats に投稿する」という設定をしてあるため、Threat ができるたびに通知が届きます。しかし通知は「何かが起きた」と知らせるだけで、それが攻撃なのか検証なのか、どこまで影響したのかは、人が Sysdig の画面を何枚も開いて調べる必要があります。

今回作った仕組みでは、人が「これを調べて」と意思表示した通知だけを、すぐに自動で調べる形にします。その意思表示が 👀 です。ここに至るまでに、2 つの制約を越えました。

1. Slack が無料プランで、Workflow Builder が使えない。 「👀 が付いたら何かを起こす」を Slack の標準機能では組めません。そこで、👀 を拾う Slack App（reaction bot）を自分で作り、home-nuc クラスタで動かすことにしました。

2. Factory の Delegations は、bot からの依頼を受け付けない。 最初の設計では、reaction bot が @Factory とメンションして Delegations に調査を頼む予定でした。ところが 2026-10-18 の #test での確認で、bot の投稿は成功したのに、Factory からの返信は 4 分以上ありませんでした。理由は、Factory の文書と Slack の記録を突き合わせるとわかります。

   • Factory の Delegations の文書は、@Factory とメンションした投稿の送り主に、2 つの条件を求めています。「接続した Factory の組織にアカウントを持つこと」と「Slack と Factory で同じメールアドレスを使うこと」です。Factory は、このメールアドレスで送り主を照合します。Factory が応答しないときの確認事項にも、このメールアドレスの一致が挙がっています。
   • TK 自身は、この条件を満たしています。Slack と Factory で同じメールアドレスを使っているからです。
   • しかし、最初の設計で @Factory の投稿を送るのは、TK ではなく reaction bot です。👀 を付けたのは TK でも、Slack にメンションを投稿するのは bot で、Factory から見た送り主は bot になります。
   • Slack の記録では、reaction bot のアカウントは bot で、メールアドレスを持っていません。そのため、Factory は送り主を Factory のアカウントと照合できず、依頼として受け付けられません。

   人の操作なしに Droid を動かす方法として、Factory には automation があります。Slack の投稿で起動する automation もありますが、起動のきっかけは「チャンネルへの新しい投稿」で、👀 のようなリアクションでは起動できません。外のサービスが HTTP で依頼する webhook の automation なら、reaction bot から直接起動できます。

そこで、reaction bot が Factory の webhook automation に HTTP で直接依頼する方式に切り替えました。この方式なら、Factory の Droid は tk-mini2 で動きます。tk-mini2 には、Sysdig の MCP、調査の手順書（SKILL）、書き込みを止める hooks、作業記録のリポジトリがそろっています。

Slack が有料プランなら、どう変わるか

ここまでの工夫の多くは、Slack が無料プランであることから来ています。Slack の Workflow Builder は Pro プラン以上で使え（エンタープライズでなくてよい）、「絵文字のリアクションが使われたとき（When an emoji reaction is used）」をきっかけにワークフローを始められます（Slack のヘルプ「Build a workflow」）。

	今の仕組み（無料プラン）	有料プランの場合
👀 に気づく	自作の reaction bot（home-nuc で動く）	Workflow Builder の絵文字のきっかけ
Factory を起動する	reaction bot が webhook を送る	ワークフローが別のチャンネルに新しい投稿をし、その投稿で Factory の Slack automation（送り主を「Bots only」にする）を起動する
自分で作る・動かすもの	bot のコード、Pod、Secret、Slack App	ワークフローと automation の設定だけ

有料プランなら、reaction bot とそれを動かす Pod は要らなかった可能性が高い、と言えます。ただし、次の 2 点は試していません。

• ワークフローから @Factory とメンションする形は、送り主がワークフロー（Slack のアプリ）になるため、今回の bot と同じ理由で Delegations に受け付けられない可能性があります。
• Factory の Slack automation は、チャンネルへの新しい投稿で起動します（スレッドの返信では起動しない）。以前の記録（段階 2）では、この automation が組織で使えず 401 になっています。今も同じかは確かめていません。

---

3. テストの環境と仕組み

3.1 環境の全体像：どこで、何が動いているか

図 2　テスト環境の全体像。2026-10-18 時点の配置を、kubectl・Factory・Slack の記録で確かめて描いた。

テストの舞台は、大きく 2 つに分かれます。上の帯がインターネット上のサービス（SaaS）、下の帯が TK の自宅ラボです。

インターネット上のサービス

サービス	この仕組みでの役割
Sysdig Secure / Monitor（jp1 リージョン）	検知を相関分析して Threat に束ね、Automation で Slack に通知する。調査のときは MCP で証拠を渡す
Slack（ワークスペース tk-lab）	#threats に通知が届き、#dr に要約が届く。TK が 👀 を付ける場所
Factory	webhook を受け、Factory の Droid の実行を tk-mini2 に割り当てる。Slack 連携で報告を投稿する
GitHub	手順書とプロンプト（tk-team-home）、マニフェスト（home-nuc）、reaction bot の image（ghcr.io）を置く

自宅ラボ

自宅ラボには、Kubernetes クラスタ nuc-home と、Mac の tk-mini2 があります。

• クラスタ nuc-home は NUC 4 台（nuc1〜nuc4）でできています。Kubernetes v1.32.7、Ubuntu 22.04.5 LTS、Docker 28.3.2、ネットワークは Calico です。制御プレーン（kube-apiserver・etcd など）は nuc1 で動きます。
• Sysdig エージェント（sysdig 名前空間）は、shield-host が 4 台すべてに 1 つずつ、shield-cluster が 2 つ動いています。
• reaction bot（security-tools 名前空間）は、nuc3 と nuc4 に 1 つずつ、計 2 つ動いています。2 つは同じ働きをし、Slack は 1 つの 👀 をどちらか一方に届けます。今回のテストの 👀 は nuc4 の bot が受け取りました。
• 攻撃の模擬（threat-e2e-2 名前空間の Pod attack-sim-c）は、nuc4 で動きました。図 2 の赤い枠です。
• tk-mini2 は Factory に登録した self-hosted のコンピューターで、Factory の Droid がここで調査を実行します。tk-team-home の作業コピー、Sysdig MCP の設定、クラスタへの kubectl を持っています。

名前空間ごとに、通信の範囲を NetworkPolicy で絞っています。reaction bot の外向き通信は DNS とインターネットの 443 番だけで、家の中の別の機器には出られません。攻撃の模擬の Pod は、同じ名前空間と DNS にしか出られません。「攻撃者役」が本当に外へ何かを送ることはできない作りです。

図 2 の右端にあるとおり、家の中に受け口を開けていないことも、この構成の特徴です。Sysdig エージェントも、reaction bot も、tk-mini2 も、自分から外のサービスへ接続します。reaction bot が Slack の Socket Mode を使うのはこのためで、Slack からの呼び出しを家の中で待ち受ける必要がありません。tk-mini2 も同じです。Factory の文書によると、Remote Control は Factory の中継サービス（relay）を通してつながるため、受け口のポートを開ける必要がありません。

3.2 処理の流れ：だれが、何を受け持つか

図 3　処理の流れ。丸数字は今回のテストで実際に起きた順番。色は持ち主を表す。

図 2 が「どこにあるか」なら、図 3 は「どの順に動くか」です。3 つの帯に分かれています。上の帯が「検知して知らせる」、中の帯が「👀 で起動し、調べる」、下の帯が「報告する」です。

#	担い手	受け持つこと
①〜③	Sysdig エージェント（shield-host）	コンテナの中の挙動をシステムコールで見張り、Sysdig Secure へ送る
③〜④	Sysdig Secure の Threats engine と Automation	検知を相関分析して Threat に束ね、「New Threat」で Slack に通知する
⑤	TK	通知を読み、調べたいものに 👀 を付ける
⑥〜⑦	reaction bot	👀 を受け取り、チャンネル・投稿者・絵文字を照合してから、署名つき webhook を送る。スレッドに受付のお知らせを書く（image sha-a510b15f）
⑦〜⑧	Factory webhook automation	署名を確かめ、本文をフィルター（"source": "tk-sysdig-reaction-bot"）で照合し、実行を tk-mini2 に割り当てる。1 時間 10 回まで
⑧〜⑪	Factory の Droid（tk-mini2 で動く）	調査の手順書（SKILL）に沿って 9 タスクを実行。Sysdig MCP・kubectl・作業記録を読むだけ。報告をスレッドと #dr に投稿

図の右下にある赤い枠は、この仕組みに組み込んだ「守り」です。特に大事なのは次の 2 つです。

• webhook の本文は「どの投稿か」を指すだけ。 Droid が使うのは本文の source・channel・message_ts だけで、ほかの項目は参考にとどめます。本文は「証拠データ」として扱い、中に命令が書かれていても従いません。channel と message_ts を許可リストと照合したあと、通知の本文は Slack から、Threat の詳細は Sysdig から、自分で取り直します。だれかが偽の本文を送っても、偽の内容のまま調査が進むことはありません。
• 調査は読み取りだけ。 hooks が書き込み系の操作を止めます。Pod の停止や隔離といった対処は、今回のテストの範囲に入れていません（6.3）。

---

4. テストの実況：16:12 から 16:35 まで

ここからは、今回のテストを時間の順にたどります。まず全体の流れを 1 枚で見ておきます。

図 4　今回のテストの時系列。時刻は Slack の投稿時刻、reaction bot のログ、Factory の配信記録、Sysdig の検知記録から取った。

Sysdig のルールは、操作から数秒以内に検知しています。そのあと Sysdig が検知を相関分析して 1 つの Threat にまとめ、通知するまでが約 11 分。人が通知を読んで 👀 を付けるまでが約 4 分、Factory の Droid による自動調査が約 7 分です。真ん中の 4 分だけが人の時間で、👀 が付くまで自動では何も始まりません。調べるかどうかは、人が決めます。

4.1 攻撃の模擬と、Sysdig の検知

16:12:36、threat-e2e-2 名前空間に Pod attack-sim-c が作られました。中身は sleep だけの alpine コンテナです。その後の約 30 秒で、外から 4 回のコマンド実行（kubectl exec）が届き、攻撃者がよく使う一連の操作をなぞりました。

Sysdig Secure の Threat 詳細（Highlights）。左上が判定（Open・Malicious・Medium Confidence）、中ほどが反応した 4 つのルール、下半分がプロセスの親子関係。

プロセスの親子関係（下半分）を上から読むと、何が起きたかがわかります。

1. systemd → containerd-shim-runc-v2 → runc は、コンテナの外から exec が入ってきたことを示します。
2. busybox sh -c 'sh /tmp/falco >/dev/null 2>&1 &' が、一時領域に falco という名前のプログラムを作って起動しました。
3. 同じ流れで cat /etc/shadow（パスワード情報のファイルの読み取り）と nc 127.0.0.1 4444（通信ツールでの接続の試み）が動きました。
4. 次の exec で pkill -f '^sh /tmp/falco$' が走り、その falco を止めました。Sysdig はこれを「セキュリティソフトへの妨害」と見て、High を付けています。

ここに仕掛けがあります。止められた falco は本物の Falco ではなく、同じ台本が直前に作った偽物（中身は sleep 3600）です。本物を止めずに、「止めようとする」挙動だけを再現しています。

最後の検知（Last Rules Occurrence）。上がイベントの一覧、下が Kubernetes の操作記録（Activity Audit）。

上のイベント一覧では、16:13:03 と 16:13:15 の High（セキュリティソフトへの妨害）、Medium（一時領域からの実行、パスワード情報の読み取り）、Info（通信ツールの起動）が並びます。下の Activity Audit には、kubernetes-admin による kube exec が 16:12:45、16:12:59、16:13:03、16:13:14 の 4 回記録されています。この 4 回が、後で調査の T4 がつかむ「どこから操作されたか」の答えになります。

Threat 全体の集計。ルール 4 つ、Occurrence 1 つ。最初の検知が 4:12:45 pm、最後が 4:13:16 pm。

Threats in Evaluation（評価中の Threat）の画面。ホスト nuc4 の単位で、2 つの Malicious な Threat（Falco Tampering… と Recon Credential…）が束ねられている。

この 2 枚を並べると、ID が 2 種類あることに気づきます。上の Threat 詳細の ID は 01a14de5-…、下の Threats in Evaluation（と Slack の通知）に出る ID は 01a14ddb-… です。調査の最終報告は、出典 S1 で「Threat 01a14de5（occurrence 01a14ddb）」と両者を結び付けています（occurrence は、Threat の中の発生の記録です）。Slack の通知の画面に出る「Threat ID」は、この occurrence の ID です。

Sysdig の Automation「New Automation Oct 11」の実行記録。「New Threat」を受けて「Send Slack 1」（#threats）を実行する。右側の変数は、この画面で選んでいた別の実行（threat-e2e / attack-sim）のもの。

Sysdig から Slack への通知は、この Automation の設定で送られます。Sysdig が何もしなくても Slack に投稿するわけではなく、「New Threat（新しい Threat）が起きたら Slack に投稿する」という 2 つの箱だけの設定をしてあるから、通知が届きます。

4.2 検知から通知まで：Sysdig が行う相関分析

Sysdig の検知そのものは、操作から数秒以内です。 4.1 の画面（Threat 全体の集計と、最後の検知のイベントと Activity Audit）で、Kubernetes の操作記録とルールの検知の時刻を並べると、次のようになります。

操作（Activity Audit の kube exec）	ルールの検知（イベント）	差
16:12:45　1 回目	16:12:45　Threat の最初の検知	0 秒
16:13:03　3 回目（偽の falco を pkill）	16:13:03　High「セキュリティソフトへの妨害」	0 秒
16:13:14　4 回目	16:13:14〜16:13:16　残りのルール	0〜2 秒

Falco のルールがシステムコールを見張り、操作が起きた瞬間に反応しています。遅いのは検知ではありません。

では、通知までの約 11 分は何に使われたのでしょうか。Sysdig の記録を使うと、Sysdig の中で起きたことを時刻つきで 4 つの段階に分けられます。

段階	時刻	記録
① 最初の検知で、発生の記録（occurrence）が作られる	16:12:45.685	occurrence の startTime。occurrence の ID（01a14ddb-…）に埋め込まれた時刻も同じ
② 最後の検知	16:13:16.300	occurrence の lastSignal
③ 評価が終わり、Threat が作られる	16:24:24.953	Threat の ID（01a14de5-…）に埋め込まれた時刻
④ Automation が #threats に通知する	16:24:27	Slack の投稿時刻（③ の 2 秒後）

Sysdig のこれらの ID は UUID の第 7 版（UUIDv7）で、先頭に、作られた時刻をミリ秒で持っています。occurrence の ID の時刻が startTime とミリ秒まで一致するので、この読み方で正しいことも確かめられます。

この表から、約 11 分のほとんど（② から ③ までの 11 分 8 秒）は、Threat を作るまでの評価の時間だとわかります。Automation が通知を送ったのは、Threat ができてから 2 秒後です。

評価の間に Sysdig が行うのが、相関分析です。Sysdig の文書（Threat Management の Signal Correlation）は、検知を次の 3 つの観点で束ねると説明しています。

• 同じ相手か（Entity Matching）：同じコンテナ、同じホスト、同じクラウドのユーザーにかかわる検知をまとめる。
• 時間が近いか（Time Proximity）：決まった時間の窓の中で続いた検知をまとめる。
• 重大度（Event Severity）：High の検知は、1 件だけでも必ず Threat を作る。ほかの重大度の検知は、Threat の文脈として加わる。

さらに、同じ場所で同じ挙動が繰り返されると、1 つの occurrence にまとめられます。

今回は、同じ Pod で約 30 秒のあいだに起きた 4 つのルール・合計 8 回の検知が 1 つの occurrence に入り、評価の結果、1 つの Threat「Falco Tampering and Credential Access」になりました。Sysdig の記録には、評価の結果として、分類（MALICIOUS）、確信度（MEDIUM）、promotionTags の High（High の検知を含むこと。文書の「High の検知は必ず Threat を作る」と合う）、Sysdig の AI（Sysdig Sage）が付けた名前と説明が残っています。8 回ばらばらに通知が来るのではなく、「1 つの攻撃の流れ」として 1 通で届いたわけです。

Sysdig の文書には、評価にかける時間の長さは書かれていません。言えるのは、今回の実測が 11 分 8 秒だったという事実です。この時間は、ノイズを減らして人が読む通知を 1 通にするためのもので、こちらの仕組みでは縮められません。

4.3 通知が #threats に届く

#threats に届いた通知の全体。Resource（nuc-home・nuc4・threat-e2e-2・attack-sim-c）、Status、Source、Image、反応したルール 4 つが並ぶ。

16:24:27、相関分析を終えた Threat の通知が #threats に届きました。

通知の冒頭部分。「Threat created with name 'Falco Tampering and Credential Access'」。下に 👀 が 1 つ付き、スレッドに返信がある。

通知の題名は「Threat created with name 'Falco Tampering and Credential Access'」です。TK はこれに 👀 を付けました。

4.4 👀 から、調査の開始まで

👀 が付いた瞬間から、次の 3 つが 1 秒以内に起きました（reaction bot のログと Factory の配信記録より）。

時刻（JST）	起きたこと	記録
16:28:52.232	Factory が配信を受け付け、実行に回す（290 バイト・Dispatched）	Factory の配信記録
16:28:52.655	bot が webhook の成功（status 200）を記録	webhook accepted channel=C0C85KNED3M … status=200
16:28:52.931	bot がスレッドに受付のお知らせを投稿	posted notice … webhook_ok=True

スレッドの最初の 3 通。bot の「👀 を受け付けました」、Droid の「調査を開始しました（自動実行）」、作業工程（9 タスク）。

最初の 1 通は reaction bot の受付のお知らせです。「Factory に自動調査を依頼しました。結果はこのスレッドに投稿されます。」とあり、👀 を付けた人に「届いた」ことをすぐ伝えます。

16:29:20、Droid が「【自動調査報告】調査を開始しました（自動実行）」と投稿しました。この 1 通は、同じスレッドを二重に調べないための印も兼ねています。続けて、9 つのタスクの工程表（目安 15〜25 分）が出ます。工程表は調査が終わると「完了（所要 6 分）」に書き換わり、各タスクの結果の記号が並びます。

Factory の automation 詳細。WEBHOOK URL とシークレットのフィンガープリントは、この記事ではぼかしてある。

Factory の側では、automation「Sysdig Threat 自動調査（👀 webhook）」が受け付けています。ペイロードフィルター、1 時間あたりの最大実行回数 10、実行先 tk-mini2、モデル Opus 5.5 が見えます。右下のイベントの先頭 2 行が今回のテストで、07:28 の Webhook 配信（= 16:28 JST）と、07:29 の「実行中」です。それより下の行は、今回のテストより前の実行です。「成功率 67%」は 7 日間の値で、今回のテストがまだ実行中だったため成功に数えられていない時点のものです。

tk-mini2 で動く Factory の Droid のセッション。冒頭にプロンプトの「目的」「固定値」「1. 依頼の受け取り」が見え、下の状態表示は「T1〜T8 調査（T1・T2 完了）」。

実行中のセッションは、Factory のアプリからそのまま覗けます。プロンプトの冒頭には、監視するチャンネル、報告先、Sysdig の bot の ID、使う手順書の場所などの固定値が並びます。「1. 依頼の受け取り」には、webhook の本文を「証拠データ」として扱い、source・channel・message_ts だけを使う、と最初に書いてあります。

4.5 9 つのタスク：1 つ終わるたびに 1 通

調査は 9 つのタスクに分かれています。並べ方には意味があります。

図 5　調査の組み立て。T1 で対象を決め、T2〜T8 を 3 つの問いに分けて答え、T9 で判定して報告にまとめる。

T2〜T8 は、3 つの問いに重なりなく、漏れなく振り分けられます（問いの立て方は、この記事での整理です）。

• 問い ①「挙動は本当にあったか」：T2（何が検知されたか）と T3（何が起きたか）
• 問い ②「その操作は正当か」：T4（どこから操作されたか）と T8（その活動は正当か）
• 問い ③「影響はどこまでか」：T5（権限）、T6（守り）、T7（広がり）

この 3 つの問いへの答えが、そのまま判定（T9）の材料になります。以下、各タスクの進捗の投稿を順に見ます。

T1：通知の確認と Threat の特定。

T1 は入口です。通知が Sysdig の正規の bot からのものかを確かめ、調べる Threat を 1 つに決めます。Droid が Slack から取得した通知のデータには題名しか入っておらず、Threat の ID がありませんでした。そこで、「通知の ±30 分・名前が一致・nuc-home」という条件で代替照合し、候補 9 件から 1 件に絞りました。

T2：何が検知されたか。T3：何が起きたか。

T2 は、4 つのルールが合計 8 回反応し、中心が「セキュリティソフトへの妨害」（防御の回避）だとまとめました。T3 は、約 30 秒のあいだに外からのコマンド実行で一連の操作があったこと、そして止められたのが同じ操作で作られた偽の falco だったことを突き止めています。4.1 で画面から読み取った仕掛けを、Droid も自力で見抜いたわけです。

T4：どこから操作されたか。T5：どれくらいの権限があったか。

T4 は、操作の入口が管理者アカウント kubernetes-admin（cluster-admins グループ）による pods/exec 4 回だと特定しました。Pod は kubectl apply の形で作られています。T5 は、Pod が特権（privileged）、ホストのプロセスやネットワークの共有、ホストのディスクの取り込みを、どれも使っていないことを確かめました。

T6：守りは効いていたか。T7：ほかに広がっていないか。

T6 は、この調査で一番大事な確認です。「セキュリティソフトへの妨害」が本物の守りに届いていたら、一大事だからです。結果、nuc4 の Sysdig エージェントは 2 日 3 時間前から動き続け、再起動は 0 回、検知の前後 91 秒間も毎秒の処理記録に途切れがありませんでした。T7 は、検知の ±2 時間に nuc-home で出た検知がこの Pod の 9 件だけだったこと、使われたイメージ（alpine:3.20）に重大な脆弱性がないことを確かめています。一方で、過去 7 日に threat-e2e 系の名前空間で同じ種類の検知が 52 件あることも見つけました。

T8：その活動は正当か。

T8 は作業記録を読みに行きました。この仕組みを作ったときの作業記録には「attack-sim 系の Pod で通知を再現する」検証の手順があり、名前空間には外向きの通信を絞る設定もありました。しかし、threat-e2e-2 と attack-sim-c を名指しする記録は見つかりませんでした。さらに、検証のための操作を許す場所を定めた決まり（権限モデル）の一覧に、threat-e2e-2 は入っていません。

「テストらしく見える」ことと「正当な検証だと記録で確かめられた」ことは、別の話です。T8 はこの線を越えず、確かめられた事実だけを書いています。

4.6 最終報告 5 通：結論から出典まで

16:35:26 から 16:35:31 の 5 秒間に、最終報告 5 通が続けて投稿されました。1 通ごとに役割が決まっていて、どの 1 通も単独で読めるように書かれています。

(1/5) 結論。判定、危険度、人の対応、対象、特定のしかた。

(1/5) 結論 は、忙しい人がこれだけ読めば足りる 1 通です。判定は 🟡 判断保留（証拠不足）、確信度は中。危険度は低で、理由は「本物の Falco とエージェントは止まらず、Pod に特権はなく、外向き通信は遮断」の 3 点です。人の対応は「判断待ち（急ぎでない）」。TK が 16:12 の操作をだれがやったか確かめれば確定する、と次の一歩まで書いてあります。

(2/5) 何が起きたか（時系列）。Pod の作成から最後の検知までの 40 秒。

(2/5) 時系列 は、Pod の作成（16:12:36）から最後の検知（16:13:16）までの 40 秒を一本の線に並べています。最後に「実行 → 防御の妨害の試み → 認証情報の探索 → 内部への接続の試み」と攻撃の流れにまとめ、「ただし妨害の対象は偽のプロセス」と添えています。

(3/5) 判定の根拠。① 挙動は実際にあったか、② 正当な活動か、③ ほかの判定にしなかった理由。

(3/5) 判定の根拠 は、この報告の心臓部です。① で挙動の実在を確定させ、② で正当性の材料を並べ、③ で「ほかの判定にしなかった理由」を 3 つとも書いています。判定の考え方を木にすると、次のようになります。

図 6　判定の木。4 つの判定の定義は調査の指示書（プロンプト）から、木の形は (3/5) の理由づけを並べ直したもの。

問い ① の答えは「はい」です。4 つのルールが 8 回反応し、プロセスの親子関係もそろっています。だから「誤検知」ではありません。問い ② で行き詰まります。作業記録には検証の手順があるのに、今回の対象を名指しする記録がありません。記録と一致すれば「検証由来の陽性」、記録と矛盾するか広がりの兆候があれば「侵害の疑い」ですが、今回はどちらでもありません。だから「判断保留」です。

ここで Droid は、判断を人に返しました。図 6 の一番下のとおり、TK が「自分がやった」と答えれば検証由来の陽性で確定し、心当たりがなければ侵害の疑いに切り替わって、kubernetes-admin の資格がどこから使われたかを調べることになります。分かれ道が 1 つの質問で決まるところまで、調査が絞り込んでいます。

(4/5) 影響の範囲と現在の状態。権限、守りの状態、広がり、検知時点と現在。

(4/5) 影響の範囲 は、「影響はこの Pod の中に閉じている」と言える根拠を 3 つ並べます。権限（特権なし）、守り（エージェントは無事）、広がり（他の検知なし）です。確かめきれなかった「外向き通信の記録」は ❓ で正直に残しています。Pod は sleep 3600 なので 17:12 ごろに自然に終わる見込み、という先の見通しも書いてあります。

(5/5) 次の一手と出典。人が確認・判断すること 3 つ、まだ分かっていないこと、出典 S1〜S11。

(5/5) 次の一手と出典 は、人に渡す判断を 3 つに絞っています（7 章で取り上げます）。「私（自動調査）はこれらを実行していません」と、調査が何もしていないことも明記しています。最後の出典 S1〜S11 は、どの結論がどの API・どのコマンドから来たかを示します。報告の 1 行 1 行を、後から人が検証できます。

4.7 #dr への要約

16:35:46、報告チャンネル #dr に要約が 1 通投稿されました。

【Threat 自動調査】🟡 判断保留（証拠不足）（確信度: 中）

検証の台本どおりの操作ですが、対象を名指しする作業記録がなく、人の確認を待つ状態です。

📛 Falco Tampering and Credential Access
🎯 nuc-home / threat-e2e-2 / attack-sim-c

10/18 16:12〜16:13 に管理者アカウントが Pod へ 4 回コマンドを送り、台本が自分で作った偽の「falco」を止めるなどの操作をしました。本物の Falco と Sysdig エージェントは稼働を続け、広がりの兆候はありません。

🔹 危険度: 低 ／ 👤 人の対応: 判断待ち
👉 次の一手: この操作を TK（または TK の指示の co-CTO）が行ったかを確かめる。threat-e2e-2 が検証の例外（Q-034）の場所の外である点の扱いを決める。

🔗 詳しい報告（5 通）: 元の通知のスレッドへのリンク

#threats を見ていない人も、#dr の 1 通で「何が起きて、どれくらい危なくて、次に何をするか」がわかります。

要約の中の「Q-034」は、検証のための操作を許す場所を定めた決まりの番号です。「co-CTO」は、TK の指示で作業する AI エージェントです。

---

5. 合否の判定：確認した項目

#	確認した項目	結果	根拠
1	👀 で reaction bot が反応し、webhook が成功する	✅	bot のログ webhook accepted … status=200（16:28:52）
2	bot がスレッドに受付のお知らせを書く	✅	bot のログ posted notice … webhook_ok=True、スクリーンショット s08
3	Factory が配信を受け付け、tk-mini2 で実行が始まる	✅	配信記録（Dispatched）、automation の実行先 tk-mini2、セッション画面 s10
4	開始の投稿と工程表が出る	✅	16:29:20・16:29:21 の投稿
5	9 タスクの進捗が 1 つずつ出る	✅	T1〜T8 の進捗 8 通（T9 の結果は最終報告に含まれる）
6	最終報告 5 通が出て、出典が付く	✅	16:35:26〜16:35:31 の 5 通、出典 S1〜S11
7	#dr に要約が 1 通出る	✅	16:35:46 の投稿
8	調査が環境を変えない	✅	報告 (1/5)・(5/5) の明記。停止・隔離・削除の記録なし
9	秘密情報がログに出ない	✅	bot の設定のログは token・URL・secret を ***REDACTED*** で出力

9 項目すべてが期待どおりでした。

---

6. わかったこと、直したいこと

テストが通ったうえで、記録を突き合わせて見えたことが 3 つあります。直すかどうかは、TK と相談して決めます。

6.1 調査は目安より速かった

工程表の目安は 15〜25 分でしたが、実際は 6 分でした。今回の Threat はルール 4 つ・Pod 1 つと小さかったためです。目安を変える必要はありませんが、大きな Threat でどれくらいかかるかは、これからの実運用で測ります。

6.2 tk-mini2 の kubectl は管理者の資格を持っている

tk-mini2 の kubectl の接続先（context）は kubernetes-admin@kubernetes で、クラスタの管理者の資格です。調査を読み取りだけに抑えているのは、hooks とプロンプトです。hooks は今回も働いていますが、資格そのものを読み取り専用にすれば、守りが二重になります。調査用に、get・describe・logs だけを許す資格を別に用意する改善を提案します。

なお、Droid の投稿は TK のアカウントの名前で表示されます（スクリーンショット s08）。Factory の文書のとおり、webhook の automation を自分として実行すると、Slack への投稿は自分のアカウントから出るためです。人の書き込みとは、【自動調査報告】 と 【進捗】 の接頭辞で見分けられます。

6.3 今回は使っていない機能：Droid に対処まで任せる

今回の Droid は、調べて報告するところで止まりました。しかし Sysdig Secure には、見つけた脅威に対処する機能もあります。Factory の Droid から、それを使わせることもできます。

ヘッドレスクラウドセキュリティ（Headless Cloud Security）

Sysdig は、自社の画面（UI）を通さずに、Sysdig のデータ・判断・自動化を AI エージェントから直接使う考え方を「ヘッドレスクラウドセキュリティ」と呼んでいます。Sysdig の API を MCP のサーバーとして提供し、AI のコーディングエージェント（Sysdig のブログでは Claude Code、Codex、Cursor などを例に挙げている）が、それを呼び出して作業します。今回、Factory の Droid が Sysdig Secure MCP で Threat やイベントを読んだのも、この考え方の上に乗っています。

レスポンスアクション（Response Actions）

レスポンスアクションは、Sysdig Secure の機能で、脅威を封じ込めたり、調査の証拠を集めたりします。2026-10-18 にこのテナントで使えるアクションの一覧を Secure MCP で読むと、次のものがありました。

対象	封じ込め	元に戻す	証拠集め
ホスト（コンテナ・プロセス・ファイル）	プロセスの強制終了、コンテナの強制終了・停止・一時停止、ファイルの隔離	コンテナの起動・再開、ファイルの復元	ファイルの取得、システムコールの記録（Capture）
Kubernetes クラスタ	Pod の削除、ロールアウトの再起動、ネットワークの隔離	隔離した接続の解除	ログの取得、ボリュームのスナップショット
クラウド	IAM のユーザー・ロールの隔離、公開設定の解除	アクセスの復元、公開設定の復元	クラウドのログの取得、ボリュームのスナップショット

Secure MCP には、これを実行する道具（submit_response_action）、進み具合を見る道具（get_response_action_status）、元に戻す道具（undo_response_action）があります。つまり、Factory の Droid に「attack-sim-c の Pod を削除する」「コンテナを止める」といった対処を、Secure MCP を通して行わせることができます。

Sysdig は、そのための手順書（スキル）sysdig-runtime-remediate も用意しています。Sysdig の文書とブログによると、このスキルは次のように進めます。

1. 影響を受けるワークロードの影響範囲（つながっているサービス、権限、止められない条件など）を、読み取りだけで調べる。
2. 対処の案を、順番つきで出す。各案について、何をするか、何が壊れるか、元に戻せるか、戻す方法を示す。
3. 壊す操作は 1 つずつ、人がはっきり承認してから実行する。
4. 封じ込めたあと、Pod が作り直されていないかを見張る。

気をつけること（Sysdig の文書より）

• Pod の削除：コントローラー（Deployment など）が管理する Pod は作り直されます。管理されていない単体の Pod は、作り直されません。
• コンテナの強制終了：調査の証拠が失われます。Kubernetes は、止められたコンテナを設定に従って再起動しようとします。
• 前提：Pod の削除やロールアウトの再起動には Cluster Shield 1.14.0 以上、コンテナの操作にはエージェント 13.9 以上と、実行の権限（EXEC）が要ります。上の一覧はテナント全体のもので、nuc-home で実際に実行できるかは、まだ確かめていません。

今回、使わなかった理由

今回のテストは、調査と報告までを範囲にしました。そのため、仕組みも対処をしない作りにしてあります。

• 調査の指示書（プロンプト）は、停止・隔離・削除・Response Action の実行を「どんな場合も行わない」と定め、sysdig-runtime-remediate にも引き継がないとしています。
• hooks（hooks/automation_readonly_guard_v2.py）は、submit_response_action と undo_response_action を拒否します。

これは、対処を今回のテストの範囲に入れなかったためです。今後は、対処も自動で行う予定です。

今後、対処を自動で行うために

たとえば、調査の判定が「🔴 侵害の疑い」になったら、Droid が Secure MCP でレスポンスアクション（例：Pod の削除、ネットワークの隔離）を実行し、結果をスレッドと #dr に報告する、という流れです。そのためには、次のことが必要です。

• 調査の指示書（プロンプト）に、どの判定・どの条件で、どのアクションを実行するかを書く。
• hooks で、許すアクション（submit_response_action のうち決めたもの）だけを通す。
• Sysdig の側で、Droid が使う資格にレスポンスアクションの実行の権限（EXEC）を与え、nuc-home の Cluster Shield とエージェントの版が条件を満たすことを確かめる。
• 実行のあと、Pod が作り直されていないか、証拠が失われていないかを確かめる手順を入れる。

---

7. 人が決めること

最終報告 (5/5) は、人に渡す判断を 3 つに絞りました。

1. 10/18 16:12〜16:13 に threat-e2e-2 で attack-sim-c を動かしたのは、TK（または TK の指示で作業する AI エージェントの co-CTO）か。 そうなら判定は「検証由来の陽性」で確定します。心当たりがなければ「侵害の疑い」として、kubernetes-admin の資格の利用元を調べます。
2. threat-e2e-2 を、検証のための操作を許す場所に加えるか。 今の決まり（権限モデル）では、threat-e2e-2 は検証を許す場所の一覧に入っていません。加えれば、ここでの検証は決まりどおりの作業になります。
3. 検証の実行記録（名前空間・Pod・時刻）を作業記録に残す運用にするか。 残せば、過去 7 日の 52 件のような同種の検知を、次から自動で照合できます。

3 つ目は、この仕組みを育てるうえで効きます。今回の判定が「判断保留」になった理由は、まさに名指しの記録がないことでした。検証のたびに 1 行残すだけで、次の同じ検知は「検証由来の陽性」と自動で判定できるようになります。

このほか、6 章の改善（調査用の読み取り専用の資格）を行うか、6.3 の対処（レスポンスアクション）を、どの判定・どの条件で自動で行うかも決める必要があります。