最近、VS Code + Claude Code に調べものやログの集計を任せることが増えました。前回の記事「Claude Codeに作業させた証跡をEasyBlocks Syslogに集約してみた」では、Claude Code の行動を syslog に記録する仕組みをご紹介しました。
今回は記録したログを、
Claude Codeに読ませて分析させたらどうなるだろう？
ということを試します。
セキュリティの世界にはSIEM(Security Information and Event Management)という仕組みがあります。各機器のログを集約し、横断的に突き合わせて脅威を見つける、いわば「ログの相関分析」です。
とても強力ですが、製品やサービスは高価で、運用にも専門知識と人手がかかります。「導入したいが、いきなりフルSIEMはハードルが高い」という声は少なくありません。
本記事では、その相関分析という核心価値の入口だけを、EasyBlocks Syslogに溜めたログとClaude Codeで低コストに体験してみます。
相関分析とは何か
たとえば「ログイン失敗が1件」だけを見ても、何の異常も感じません。日々大量に出るノイズの一つです。
ところが、「同じ送信元から・同じ宛先へ・5分おきに・何日も・ずっと失敗し続けている」と分かったらどうでしょうか？
1件ずつでは無害に見えるログも、時系列で束ねた瞬間に「調査すべき異常」へと姿を変えます。これが相関分析です。単独のログでは決して気づけないものを、複数のログの「点」を「線」につないで見つけ出す。今回はこれを実データでやってみます。
構成
- 各種ネットワーク機器(ルーター/ファイアウォール/WiFi APなど)
- EasyBlocks Syslog(192.0.2.10)… ログの集約・保存を担う土台
- Claude Code(クライアントPC 192.0.2.50 で稼働)… 分析役
実際の流れとしては以下のようになります。
[各機器] → syslog → [EasyBlocks Syslog 集約/保存] → CSVエクスポートAPI → [Claude Code が相関分析] → 日本語で報告
前回のブログが「記録する側」、今回が「分析する側」。EasyBlocks Syslogが全てのログを一か所に集約しているからこそ、Claude Codeが横断的に突き合わせられる、という関係です。
※注意： 本記事に登場するIPアドレス・ホスト名・ユーザー名・ログは、すべて実際の値をダミーに置き換えたサンプルです。また本検証は、自社で運用するEasyBlocks Syslogに蓄積されたログに対して実施したものです。
STEP① ログ取得：Web UIではなくCSVエクスポートAPIを使う
EasyBlocks Syslogには、HTTP POSTでログをCSV取得できる「CSVエクスポートAPI機能」があります（Web UI の基本設定で有効化が必要です）。今回はWeb UIから手作業でダウンロードするのではなく、Claude CodeからAPIを直接叩いて取得→そのまま分析まで一気通貫で行います。
エンドポイントへ、参照したいテーブルや絞り込み条件をJSONで渡すだけです。
{
"name": "root",
"password": "（後述の方法で安全に渡す）",
"table": "ilogs",
"limit": 3000,
"condition": {
"datetime": ["2026/06/01", "2026/06/16"],
"program": ["TELNETD"]
}
}conditionで期間やプログラム名を指定できるため、ノイズに埋もれさせず狙ったログだけを取得できます。これは大量ログをそのまま投げ込むより、はるかに効率的です。
ハマりポイント① パスワードをコマンドに平文で書かない
APIには管理者の認証情報が必要です。とはいえ、パスワードをコマンドやスクリプトに平文で書けば、シェルの履歴や証跡に残ってしまいます。
そこでWindowsのDPAPI(実行ユーザーだけが復号できる暗号化)を使い、平文を一度もコマンドに出さない運用にしました。
# 事前に一度だけ。平文を打つのはこの瞬間だけ
"パスワード" | ConvertTo-SecureString -AsPlainText -Force | ConvertFrom-SecureString | Set-Content "$env:TEMP\sp.sec"
# 実行時は復号して利用(コマンド本文にパスワードは現れない)
$sec = Get-Content "$env:TEMP\sp.sec" | ConvertTo-SecureString
$pw = [System.Net.NetworkCredential]::new("", $sec).Passwordこの一手間が後で効いてきます(最後の「おまけ」で回収します)。
ハマりポイント② host列はあてにならない
今回の環境では、EasyBlocks Syslog(192.0.2.10)は別のルーター/FW(`core-router`)から転送されたログを集約していました。そのためCSVのhost列はほぼ全件がcore-routerになります。
「どの機器のログか」は host では区別できず、メッセージ本文のパターンで判別する必要がありました。環境ごとにこうした前提が変わる点は、最初に押さえておくと安心です。
STEP② 主役の発見：2年間、誰も気づかなかった「沈黙のTelnetビーコン」
取得したログをClaude Codeに時系列で読ませたところ、外部からの攻撃よりも先に、あるプライベートアドレスの機器による奇妙な振る舞いが浮かび上がりました。
まずは単独のログ。これだけ見ても、何ということはありません。
Jun 15 09:23:32 core-router TELNETD: permission denied, 10.10.0.x「プライベートアドレス 10.10.0.x を持つ機器から Telnet ログインがあり、拒否された」――ありふれた失敗ログです。
ところが時系列に並べると、景色が一変します。
Jun 15 09:23:32 core-router TELNETD: permission denied, 10.10.0.x
Jun 15 09:28:32 core-router TELNETD: permission denied, 10.10.0.x
Jun 15 09:33:32 core-router TELNETD: permission denied, 10.10.0.x
Jun 15 09:38:32 core-router TELNETD: permission denied, 10.10.0.x
…（以降、終日きっかり5分間隔で延々と継続）…
Jun 15 23:58:32 core-router TELNETD: permission denied, 10.10.0.x
同じ時刻間隔で延々と並ぶ Telnet ログイン失敗(IP はマスキング済み)
ログイン失敗の時間間隔は常に5.0分 ― 自動化の証拠(実データ)
Claude Codeによる分析コメントは次の通りです。
- 規則性：平均間隔はきっかり5.0分。人手では不可能で、自動化されたプロセスが動いている。
- 継続期間：保存されている最古のログ(約2年前)から現在まで、どの時点を調べても必ず存在する。つまり約2年間、誰にも気づかれずに鳴り続けてきた。
- 結果：観測した範囲で成功は0回。すべてpermission denied。
- プロトコル：平文で非推奨のTelnetを使ってネットワーク機器へ。これ自体がセキュリティ衛生上の問題。
- 足跡の特異性：この機器はsyslog 、Telnet失敗以外の痕跡がまったくない「沈黙の存在」。
- 稼働の相関：終日ではなく、機器が動いている間だけビーコンが出る。たとえば 6/15 は 09:23 開始で、稼働開始の時刻まで推測できる。
単独では永遠にノイズとして埋もれていたログが、「同一送信元 × 同一宛先 × 厳密な周期 × 失敗の連続」という相関の視点を入れた瞬間、2年間放置されてきた要調査の異常として立ち上がりました。
なお、この 10.10.0.x が具体的に何の機器なのかは、ログだけでは特定できません。プライベートアドレスではありますが、LAN 内の端末なのか、それとも VPN 経由で払い出されたアドレスなのかも判別できず、Telnet失敗以外の手がかりが残っていないためです。正体は「認証情報が古いまま放置された監視スクリプト」のような無害なものかもしれませんし、そうでないかもしれません。
ですが、ここで重要なのは正体を即座に言い当てることではありません。相関分析の価値は、「2年間誰も気づかなかった事象を”これは要調査だ”と可視化し、しかるべき担当者に渡せる状態にすること」にあります。特定や対処はその次のステップ。まずは「気づけていなかった」状態から抜け出せたこと自体が、この分析の成果です。
STEP③ 脇役の確認：外部からの偵察スキャン
ついでに、外部からのアクセスも見てみました。こちらは派手ですが、結論から言うといずれもファイアウォールが弾いており、すでに対処できているリスクです。
- ある39分間だけで、同一サブネット203.0.113.0/24の13個のIPが一斉に出現し、社内の複数IPへ広範囲にポートをばらまいていた(ボットネット型の分散スキャン)
- 別の単独IP198.51.100.245は、連続したアドレス帯を端から舐めつつ、ポートも次々に変える「縦横スキャン」を実施。
- 狙われたのは 23(Telnet) 5900(VNC) 22(SSH) といった、リモート接続や認証突破を狙う定番ポート。
Jun 01 00:00:06 core-router Rejected at IN(...) filter: TCP 203.0.113.9:xxxxx > 192.0.2.34:58888
Jun 01 00:01:xx core-router Rejected at IN(...) filter: TCP 203.0.113.29:xxxxx > 192.0.2.37:34567
Jun 01 00:02:xx core-router Rejected at IN(...) filter: TCP 203.0.113.31:xxxxx > 192.0.2.40:32324
拒否された通信の宛先ポート上位(実データ。内部ノイズのポートは除外)
個々の拒否ログは数件ずつで埋もれますが、送信元を `/24` 単位でまとめると「組織的な偵察」として浮上します。これも立派な相関分析です。
ただ、本当に怖いのは派手な外部攻撃よりも、その陰で2年間も見過ごされていた、正体不明の機器による異常のほうでした。
おまけ：分析していたClaude Code自身の証跡も、ちゃんと残っていた
ここで前回の記事を思い出してください。Claude Codeの行動をsyslogに記録する仕組みを作った、という話でした。
ということは今回この分析をしていたClaude Code自身の作業ログも、その仕組みで記録されているはずです。別の EasyBlocks Syslog(192.0.2.11)を覗いてみると、確かに今日の作業がすべて残っていました。
Jun 16 14:20:59 client-pc claude-code: user=user01 session=xxxx event=PostToolUse tool=WebFetch url="https://blog.plathome.co.jp/claudecode-ebsyslog/"
Jun 16 15:48:31 client-pc claude-code: user=user01 session=xxxx event=PostToolUse tool=Edit file_path="article-draft"
Jun 16 15:49:44 client-pc claude-code: user=user01 session=xxxx event=PostToolUse tool=PowerShell cmd="(記事をWordに組み上げるスクリプト)"
Jun 16 15:52:10 client-pc claude-code: user=user01 session=xxxx event=PostToolUse tool=PowerShell cmd="$sec = Get-Content $env:TEMP\sp.sec | ConvertTo-SecureString ..."
分析していたClaude Code自身の行動ログ(マスキング済み・抜粋)
今日1日分で100件。
内訳はPostToolUse 78件、UserPromptSubmit 19件、SessionStart 3件。
ツール別では PowerShell 32件、Edit 20件、Read 9件、Write 5件、WebFetch 3件…と並びます。
つまりログの取得・分析だけでなく、この記事そのものを執筆し、図を描き、Word に組み上げていく全工程が、丸ごと証跡として残っていたのです。関連する既存記事を読み直したWebFetchの記録まで写っていました。
極めつけは、一番新しいログ、これはこの証跡を取得しに行ったコマンドそのものです。観測する側が、同時に観測されているその構図が、文字どおり最後の1行に刻まれていました。
ここで嬉しい発見が2つありました。
1つ目は、認証情報が一切漏れていないこと。
記録されたコマンドは Get-Content …sp.sec | ConvertTo-SecureString のような形ばかりで、パスワードの平文はどの証跡にも残っていませんでした。STEP① の「平文を打つのは一度だけ」という運用が、監査ログの上でも裏付けられた格好です。
2つ目は、連載としての対称性が綺麗に閉じたこと。
「行動を記録する側(前回)」と「ログを分析する側(今回)」、そして「分析していた本人の行動もまた記録されていた(おまけ)」。EasyBlocks Syslogにすべてが集約されているからこそ成立する、ぐるりと一周する構図です。
正直な限界：これはフルSIEMの代替ではありません
今回試したこの方法には明確な限界があります。
- リアルタイム性はない：APIで取りに行って分析する「定点観測」です。常時監視や即時アラートはできません。
- 一度に読める量に限りがある：大量ログをそのまま渡すことはできず、conditionで狙い撃ちして絞る前提です。
- 自動アラートはできない：人が「気になる観点」を投げて初めて分析が走ります。完全自動の検知運用ではありません。
だからこそ、これはフルSIEMの代替ではなく、「相関分析の入口を体験するスモールスタート」という位置づけが正直なところです。逆に言えば、まずはここから始めて、相関分析の価値を体感してから本格導入を検討する、という現実的な順序が取れます。
まとめ
高価なフルSIEMをいきなり導入しなくても、EasyBlocks Syslogにログを集約しておけば、Claude Codeに相関分析の「入口」を担わせることができました。
しかも今回は、外部攻撃の可視化にとどまらず、2年間も埋もれていた、正体不明の機器による異常を、時系列の相関から掘り起こすことができました。たとえ正体を即座に特定できなくても、「要調査の事象」として可視化できたこと自体が、大きな一歩です。
ログは、集約して初めて「線」になります。そしてその土台があれば、より長期の保存や、定例レポート化といった次のステップにも自然につながっていきます。
まずはログの収集・集約にEasyBlocks Syslogシリーズをご検討いただければ幸いです。
▼シリーズ累計導入実績7,000社以上！「EasyBlocks Syslogシリーズ」
