以前、以下の前後編記事を書きました。
子供がiPhoneのスクリーンタイムのパスワードを総当たりで突破した、という家庭の事件をきっかけに、「EasyBlocksのWeb UIに対して同じことをされたら？」と考え、ログイン失敗を検知する監視を設計する、という内容です。
この記事を書いたとき、ブルートフォースアタックの特徴である「短時間の大量試行」を捉えるために、「1分以内に5回以上のログイン失敗が起きたら検知する」という閾値ルールを立てました。
それから数か月・・・。
あの検知ルール、実際のログに当てはめたら、ちゃんと「正解」を出せるのだろうか？
ちょうど手元に、格好の題材がありました。営業技術である私や、営業担当、その他の人含め顧客先や外出先からアクセスして製品デモに使用している社内共用のEasyBlocks Syslogです。この筐体のWeb UIアクセスログには、3か月弱分のログイン試行が溜まっていました。
今回はこのログを、前編で作った「ルール」と、直近の連載で使ってきた「AI（Claude）」の両方で読み解き、答え合わせをしてみます。
結果的には、セキュリティの話だけでなく、思いがけず「デモ機がどう使われているか」という利用実態まで見えてきました。
この記事でやること
同じ1本のログイン試行ログを、2つの視点で読み解きます。
視点①：3か月で失敗は何件あり、それは攻撃だったのか（ルール vs AI）
視点②：デモ機は、いつ・どこから・どれくらい使われているのか
前提：ログイン成功と失敗はログでどう見えるか
以前の記事で確認した通り、EasyBlocksのWeb UIはログイン試行をWebサーバーのアクセスログに残します。ポイントはHTTPステータスコードです。
| ステータス | HTTPとしての意味 | ログインの結果 |
|---|---|---|
| 200 | レスポンスを正常に返した | 失敗（ログイン画面を再描画） |
| 302 | 別URLへリダイレクト | 成功（管理画面へ転送） |
つまり POST /system/login.php に対して 200 が返れば失敗、302 が返れば成功。
この読み方を頭に置いて、実データを見ていきます。
なお本記事のログは、すべて実際の値をダミーにマスキングしたサンプルです。分析は自社運用のデモ機に蓄積された実ログに対して行いました。
視点①：3か月で失敗はたった9件、その正体は？
まず、ログイン試行を集計しました。
3か月弱（4月上旬〜7月上旬）で、login.phpへのPOSTは合計130件。うち成功が121件、失敗はわずか9件でした。デモ機として、とても健全な数字です。
問題は、この失敗9件の中身です。
前編で作った「1分以内に5回以上」のルールに照らすと、1件だけ、条件にピタリ合致するイベントがありました。
4月7日、18秒間に5連続の失敗
ある日の昼前、同一の送信元から立て続けに5回、ログインに失敗している記録が見つかりました。
Apr 7 11:49:47 POST /system/login.php 200 (失敗)
Apr 7 11:49:53 POST /system/login.php 200 (失敗)
Apr 7 11:49:57 POST /system/login.php 200 (失敗)
Apr 7 11:50:02 POST /system/login.php 200 (失敗)
Apr 7 11:50:05 POST /system/login.php 200 (失敗)18秒間に5回の失敗。前編のルールなら、ここで間違いなくアラートが鳴ります。 ルール的には「クロ（ブルートフォース攻撃）」の判定です。
AIに文脈ごと読ませてみる
同じログを、今度は前後の文脈もつけてClaudeに読ませ、「これは攻撃か？」と尋ねました。
返ってきたのは、ルールとは逆の判断でした。
これはブルートフォース攻撃ではなく、正規利用者の打ち間違いの可能性が高いです。理由は、失敗の間隔が6秒・4秒・5秒・3秒と不規則で、機械的な総当たりに特徴的な一定間隔ではないこと。5回で自発的に止まっており、延々と試行を続ける攻撃の挙動と異なること。直前にはログイン画面の正常表示があり、その後も同じ端末から通常の運用アクセスが続いていることです。
実際、失敗の「間隔」をグラフにすると、機械的な規則性のなさが一目で分かります。
端末の正体
この送信元IPをたどると、なんと私自身の業務用PCでした。
この日にログインで手こずった記憶はまったくありません。3か月前の、数回打ち間違えてすぐ入り直した程度の出来事など、覚えているわけもありません・・・。
前編は「子供に聞いたら『総当たりでやった』と白状した」という結末でした。今回は本人（自分）に聞いても分からない。人間の記憶は当てにならない。
だからこそ、ログが正直に残っていることに価値がある。そんな逆説を、身をもって実感しました。
残り4件も、すべて「シロ」
念のため、残りの失敗も1件ずつ確認しました。
結論として、3か月で発生した失敗9件は、すべて正規利用者の操作ミスでした。攻撃は一件もありません。特に典型的だったのが6月11日の例です。
Jun 11 14:46:02 GET /system/login.php 200 (ログイン画面を開く)
Jun 11 14:46:16 POST /system/login.php 200 (失敗＝1回打ち間違い)
Jun 11 14:46:48 POST /system/login.php 302 (32秒後に成功)1回だけ間違えて、32秒後にすぐ正しく入り直す。これ以上ないくらい「普通の人間の操作」です。
余談ですが、このログのブラウザ情報（User-Agent）を見ると Mac の Firefox でした。4/7の打ち間違い（Windowsのブラウザ＝私）とは別の端末で、操作していたのはおそらく別のメンバーです。同じ「打ち間違い」でも、複数のメンバーがそれぞれこの共用デモ機を使っている様子が、こんなところからも読み取れます。
ここで分かったこと：ルールとAIは役割が違う
面白いのは、ルールベースの検知は 4/7 の打ち間違いを「攻撃」として誤検知する一方、6/11 のような「1回ミスして即成功」は閾値に届かず素通りさせるという点です。ルールは高速で機械的に判定できる反面、「誰が・どこから・その後どうなったか」という文脈を捨ててしまいます。
かといってAIが万能なわけでもありません。
AIは文脈を汲んで柔軟に解釈できますが、こうして後からまとめて読ませる「事後分析」であり、リアルタイムの即時検知には向きません。
だからこそ、ルールで即時に一次検知し、AIで文脈込みの二次トリアージをする、という二段構えが現実的、この結論はこれまでの連載でも一貫して見えてきたことでした。
視点②：デモ機は、いつ・どこから使われているのか
せっかく3か月分のログイン成功記録（121件）があるので、視点を変えてみます。
「攻撃の有無」を離れて、「このデモ機が実際どう使われているか」を読み解いてみました。
6割は「AirManage 2」経由 ＝ 外からのアクセス
ログイン成功を、アクセス経路で分けてみました。社内LANから直接アクセスしたものと、リモート管理サービス「AirManage 2」を経由したものです。
成功121件のうち、AirManage 2経由が77件（64%）、社内LAN直接が44件（36%）。
つまりこのデモ機は、主に外出先や顧客先からリモートでアクセスされていると想定できます。どこからでも見せられるという使い方が、そのまま数字に表れていました。
AirManage 2は全EasyBlocksシリーズにサポートとして標準搭載されている、リモート管理のためのSaaSです。こうして「外からデモ機にアクセスする経路」としても日常的に活躍していることが、ログから裏付けられました。
時間帯別アクセス履歴
次に、AirManage 2経由アクセスを時間帯で見てみます。
朝10時台に明確なピークがあり、11時台がそれに続きます。午前のアポイントでデモを見せていると思われます。昼をはさんで午後も夕方まで満遍なく続いており、訪問先を回りながら一日中この機体を使っている様子がうかがえます。
土日は完全にゼロ ＝ 営業カレンダー通り
曜日別に見ると、さらにくっきりします。
平日にきれいに分布し、土日は完全にゼロ。
当たり前と言えば当たり前ですが、デモ機の稼働が営業活動そのものと一致していることが、ログではっきり可視化されます。
まとめ：1本のログが、守りにも攻めにもなる
たった1種類のログイン試行ログでしたが、読む角度を変えるだけで、これだけのことが見えてきました。
視点①：3か月で失敗9件、すべて正規利用者の操作ミスで、攻撃はゼロ。「1分5回」ルールは4/7の打ち間違いを誤検知する一方、AIは文脈から正しく「シロ」と見抜いた。
視点②：AirManage 2経由が6割、朝10時台がピーク、土日ゼロ、月ごとに増加。ログが営業活動の実態を映し出した。
ルールベースの監視は即時・機械的で、一次検知に向いています。AIによる分析は文脈を汲んだ二次トリアージに向いています。
そして何より、その両方を可能にする大前提が「ログがきちんと集約・保存されていること」でした。
ログさえ残っていれば、後からいくらでも、守りにも攻めにも読み解けます。
人間の記憶は、自分の打ち間違いすら覚えていないほど当てになりません。だからこそ、ログを確実に残す仕組みが効いてきます。
まずはログの収集・集約から、という方は、EasyBlocks Syslogシリーズをご検討いただければ幸いです。