AIの結果、そのまま信じて大丈夫ですか？ ― n8nで“人が理解できる自動化”をつくる
目次
1. はじめに ― AIに「やっておいて」と任せて、その結果を信じられますか？
2. 「見える自動化」という答え
3. 何をする仕組みなのか
4. n8nとは ― 見えて、確かめられる自動化ツール
5. 動かしてみた（実行結果）
6. この考え方を、自分の業務に当てはめる
7. おわりに ― 説明できる自動化を、自分たちの手に
1. はじめに ― AIに「やっておいて」と任せて、その結果を信じられますか？
こんにちは、Y2SのTYです。社内のIT運用や、その業務改善・自動化に携わっています。今回は、普段の業務で感じていた「脆弱性チェックの手間」を、AIとn8n(ワークフロー自動化ツール。詳細は後ほど説明します)で自動化してみた話を紹介します。
AIを使えば面倒な作業はあっという間に片づく――そんな話をよく聞きます。実際その通りだと思いますが、いざ業務で使おうとすると、もう一段の不安が出てきます。「出てきた結果を、そのまま信じてよいのか」。
IT運用には、地味で手間のかかる作業がつきものです。その一つが、機器の脆弱性チェック。脆弱性は毎日のように公表され、その都度こんな確認が必要になります。
- 新しく公表された脆弱性が、自社で使っているバージョンに当てはまるのかを調べる
- 「深刻度が高い」だけでなく、「実際に悪用されているのか」まで見て優先度を決める
- これを毎日、見落とさずに続ける
手作業で追い続けるのは大変で、どうしても抜け漏れが出ます。だからこそ自動化したい――ですが、AIを業務に持ち込もうとすると、二つの引っかかりがあります。
一つは、先ほどの「結果を信じてよいのか」。AIが「この脆弱性が該当します」と返しても、どう判断したのかが見えなければ、そのまま業務には使えません。もう一つは、情報の扱いです。脆弱性チェックで扱うのは「自社がどの製品をどのバージョンで使っているか」という、いわば自社の弱点の一覧。こうした情報を外部のAIサービスに渡すことには、抵抗を感じる方も多いはずです。
そこで、AIの使いどころを変えました。AIに任せるのは「調査そのもの」ではなく、「調査の流れを組み立てること」です。日々更新される脆弱性情報をAIと一緒に組み立てた仕組みで自動的にさばき、運用は社内で完結させる――その全体像が次の図です。
▲ 全体像：「機器一覧」を入力に、n8nの自動化フローが脆弱性を調べ、結果をTeamsへ。フロー自体はAIと一緒に作ります。
2. 「見える自動化」という答え
AIに調査を丸投げすると、結果だけが出てきて、途中で何をどう判断したのかが見えません。いわばブラックボックスです。
代わりに選んだのは、処理の流れそのものを目に見える形にしておくこと。脆弱性を取得し、深刻度を整理し、悪用の有無を調べ、自社バージョンに突き合わせて通知する――その一つひとつのステップを後から人の目で追えれば、結果の根拠を確認できます。これが「見える自動化」です。
これを実現するのが、AIとn8n（エヌエイトエヌ）の組み合わせです。両者の役割を分けるのがポイントです。
- AIが担うのは「作る」こと：要件の整理、処理の流れの設計、細かい部品づくりや修正を、速く・手軽に進めてくれます。
- n8nが担うのは「見える・確かめられる」こと：処理の流れが図で表示され、何をしているか一目で分かります。しかも自社のサーバー（今回はローカルのDocker）で動かせるので、機器の情報を外部のAIサービスに渡さずに済みます。
AIだけでは結果が見えにくく、n8nだけでは作るのに手間がかかる。両方そろって初めて、「AIで楽に作れて、しかも人が中身を理解・検証できる」自動化になります。
3. 何をする仕組みなのか
今回作ったのは、機器の脆弱性情報を集めてTeamsに通知するフローです。入力となる「機器台帳」は、自社で使っている製品とバージョンの一覧。テスト用に、ネットワーク機器のOSやソフトウェアを7台分用意しました（実機ではなく、公開製品名を使った架空のサンプルです）。
処理の流れはこうです。台帳に載った製品ごとに、世界的な脆弱性データベースであるNVD(米国の公式データベース)から関連する脆弱性を取得し、深刻度を整理します。次に、米国政府機関が公開しているCISA KEV――「実際に悪用が確認された脆弱性」のリスト――と突き合わせ、「今すぐ対応すべきもの」を見分けます。さらに、日本語の情報源であるJVNで補足をつけ、最後にTeamsへ要点だけをまとめて送ります。
ここに、ありがちな脆弱性チェックとの違いがあります。多くの場合、脆弱性は深刻度の点数（CVSS）順に並べて終わりです。しかし現場で本当に知りたいのは「点数が高いもの」ではなく「実際に攻撃に使われているもの」です。CISA KEVを組み込むことで、その優先順位づけができるようにしました。
4. n8nとは ― 見えて、確かめられる自動化ツール
ここで、今回使ったn8n（エヌエイトエヌ）というツールについて少し説明します。n8nは、ローコードで業務を自動化できるツールです。最大の特徴は、処理を「ノード」と呼ばれる部品の集まりとして組み立てる点にあります。
一つのノードが、一つの役割を持ちます。今回なら「NVDから取得する」「KEVと突き合わせる」「Teamsに通知する」といった具合に役割ごとに分かれ、これらを線でつないだ全体が「フロー」です。
この作りには、二つの利点があります。
一つは、何をしているかが図で見えること。処理が長いプログラムの中に埋もれず、ノードの並びとして一望できます。「どこで取得し、どこで判定し、どこで通知しているのか」を、作った本人でなくても追えます。
もう一つは、部品ごとに確かめられること。役割がノード単位に分かれているので、全体を通して動かす前に、一つひとつのノードが正しく動くかを確かめられます。確かめ方は、大きく三つあります。
- ノードを開いて入出力を見る：そのノードに「何が入って、何が出たか」をその場で確認できます。たとえばKEVと突き合わせるノードを開けば、どの脆弱性が「悪用確認あり」と判定されたのかをたどれます。
- 「Execute step」で単体実行する：ノードの「Execute step」ボタンを押すと、そのノードだけを動かして出力を確かめられます。前後を全部動かさなくても、その一段だけを試せます。
- ロジックを単体テストで検証する：今回は、判断の中心となる部分（取得結果の整理やKEVとの突合など）を、入力と期待する出力を決めた小さなテストとして個別に検証しました。
結果だけをまとめて受け取るのではなく、組み上げる前に部品ごとの正しさを確かめられる。この「確かめやすさ」こそが、AIに作ってもらったものを安心して使う鍵になります。
なお、すべてを自前で作り込んでいるわけではありません。たとえば「使っているバージョンが脆弱性に当てはまるか」という判定は、自前で比較プログラムを書かず、NVDに問い合わせて「当てはまる」と返ってきたものを採用しています。自分で作る部分と、信頼できる外部に任せる部分を、ノード単位で切り分けられるのもn8nの強みです。
5. 動かしてみた（実行結果）
部品ごとに確かめたら、いよいよ全体を通して動かします。実行すると、結果がTeamsに1通の通知として届きます。台帳の機器それぞれについて「該当する脆弱性があるか」「実際に悪用が確認されているか」が一覧になり、悪用が確認されているもの（CISA KEVに載っているもの）は強調されます。深刻度の高さだけで並べるのではなく、「実際に攻撃へ使われているか」で目立たせるので、まず何から手をつけるべきかが見えてきます。日本語情報がある製品（たとえばChrome）には、通知に日本語のタイトルと参照先も添えられます。
一つひとつを確かめたうえで組み上げているので、この結果も「なぜそう出たのか」をさかのぼって説明できます。これが、最初の「結果を信じてよいのか」という不安への答えです。
6. この考え方を、自分の業務に当てはめる
今回のフローは、特別な権限も大がかりな改修も要りません。必要なのは、自社で動かすn8nと通知先のTeamsくらい。脆弱性情報の取得元（NVD・CISA KEV・JVN）も、すべて公開されているものです。
大事なのは、出来上がりそのものより「考え方」です。まず「毎回手作業で確認していて、抜け漏れが怖いもの」を思い浮かべてください。その手順をAIと一緒にステップへ分解し、n8nのノードとして並べる。図として見えるので、後から「ここはこう判断している」と説明できます。
脆弱性チェックに限りません。定期的な集計、複数システムの情報のとりまとめ、条件に応じた通知――手順がはっきりした作業ほど、この形に向いています。
7. おわりに ― 説明できる自動化を、自分たちの手に
AIを使えば、自動化は驚くほど速く作れます。今回のフローも、ゼロから自分で書くより、ずっと短い時間で形になりました。
ただ、本当に大切なのは「速さ」そのものではありません。中身を自分たちで理解でき、どう判断しているかを説明でき、必要なら直せる――つまり自分たちで把握・管理できている状態にしておくこと。AIに任せるからこそ、結果を鵜呑みにせず、見える形にしておく。その積み重ねが、安心して使える自動化につながります。
この記事が、「AIは使いたいけれど中身が見えないのは不安」と感じている方の参考になればうれしいです。
---
（本記事のフローは検証用に作成したものです。脆弱性情報は各公開APIの利用条件の範囲で取得しています。）
