WordPress運営でAPI連携を始めると、最初に襲ってくるのが認証エラー。次に襲ってくるのがWAFです。
そして、私のようにVBA記事をメインに書いてる社内SEには、もう1つ刺客がいます。
ConoHa WINGの「SiteGuard Lite」というサーバー側のWAFです。
こいつ、普通に書いたVBAコードを「攻撃」と判定してくれます。
知らんて。
この記事では、私が4日間で除外した4つの誤検知ルールと、その回避方法をまとめました。
「ConoHa WAFのせいでVBA記事が投稿できない」と困っている人は、たぶん同じ場所でハマっているはずです。
ある日、VBA記事が投稿できなくなった
事の発端は、Power AutomateでWordPressにリライト記事を自動投稿するシステムを組んでいた時のことです。
Claude APIでリライトされた記事を、REST API経由でWordPressの下書きに保存する。
仕組み自体はシンプル。
でも、Power Automateの実行履歴を見ると、HTTP 2(WordPress POST)で403エラーが連発していました。
レスポンスの中身を開いてみると、HTMLのブロックページが返ってきていました。
閲覧できません (Forbidden access) 閲覧できません (Forbidden access) 指定したウェブページを表示することができません。 Powered by SiteGuard Lite
Powered by SiteGuard Lite。
君か__。
ConoHa WAFとSiteGuard WP Pluginは別物
ここで最初の混乱がありました。
WordPressには既に「SiteGuard WP Plugin」を入れていました。
有名なセキュリティプラグインです。
てっきり、こいつが反応してるのかと思って、設定を一通り見直しました。
でも、いくら設定を変えても403は消えませんでした。
知らんて。
調べていくと、ConoHa WINGには2種類のWAFが存在することが分かりました。
- SiteGuard WP Plugin:WordPressプラグイン側のWAF。WordPress管理画面で設定する。
- SiteGuard Lite:ConoHa WINGサーバー側のWAF。ConoHaコントロールパネルで設定する。
名前が似てるんですが、別物です。
403で蹴ってきていたのは、後者の「SiteGuard Lite」の方でした。
サーバー側のWAFは、WordPressの管理画面からは見えません。
ConoHa WINGのコントロールパネルにログインして、サイト管理 → サイトセキュリティ → WAF と進んで、ようやくログが見えます。
誤検知ルール①:MsgBoxがXSS判定される
WAFログを開いた瞬間、私の頭は真っ白になりました。
1つ目のブロックログ。
日時:2026-05-14 03:08:00 攻撃ターゲットURL:https://kamoroguya.com/wp-json/wp/v2/posts 攻撃元IPアドレス:4.190.143.221 攻撃内容:クロスサイトスクリプティングの試みの可能性2(msgbox)
クロスサイトスクリプティング。
msgbox。
分かりますか、この絶望感。
「MsgBox」は、VBAで最も基本的な関数の1つです。
「Hello, World!」を表示するときに最初に教わるあれ。
これがXSS判定。
VBAブログとしては死活問題です。
WAFログから該当ログの左にある「除外」ボタンをクリック。
「対象の攻撃を除外しますか?」と聞かれて、「はい」を選択。
5分待って再テスト。
1つ目の記事は、これで通りました。
誤検知ルール②:Replace関数がSQLインジェクション判定
「これで全部解決」と思ったのも束の間。
2記事目で、また403が返ってきました。
WAFログを確認。
日時:2026-05-14 22:17:41 攻撃ターゲットURL:https://kamoroguya.com/wp-json/wp/v2/posts 攻撃元IPアドレス:4.190.143.220 攻撃内容:SQLインジェクションからの防御97(replace関数)
今度はReplace関数。
SQLインジェクションの定型パターンに「REPLACE」が含まれているため、VBAの「Replace」関数も同じ扱いになるようです。
VBAの文字列操作で頻出する関数なので、これも除外しないと記事の半分以上が投稿できません。
同じ手順で除外。
普通に通る。
でも、これは始まりに過ぎませんでした。
誤検知ルール③:汎用のクロスサイトスクリプティング検知
3記事目で発生した403は、もう少し汎用的なルールでした。
具体的なキーワードまでは特定できなかったのですが、「クロスサイトスクリプティングの一般的なパターン」に該当したようです。
VBA記事の場合、コードの中にHTMLタグっぽい記述が混ざることがあります。
例えば、文字列処理の説明で「<div>」のような表記が出てくる場合。
これが攻撃パターンと類似していると判定されたんだと思います。
3つ目のルール、除外。
除外、除外、除外。
「いつまで除外するんだろう」という疑問が頭をよぎります。
誤検知ルール④:and/or演算子がSQLインジェクション判定
そして極めつけが、これです。
日時:2026-05-18 03:07:49 攻撃ターゲットURL:https://kamoroguya.com/wp-json/wp/v2/posts 攻撃元IPアドレス:4.190.143.221 攻撃内容:SQLインジェクションからの防御22(and/or,</>)
and、or。
あの、ふつうに英語の「and」と「or」です。
「and/or」というパターンは、確かにSQLインジェクションでよく使われます。
でも、技術記事を書いていれば「and」も「or」も日常的に出現する単語です。
「ifとelseのandとorの違いは…」みたいな文章を書いたら、もう引っかかります。
知らんて。
これも除外。
除外ルール、これで4つ目。
除外作業の具体的な手順
ConoHa WAFのログから個別ルールを除外する手順は、シンプルです。
- ConoHa WINGのコントロールパネルにログイン
- 左メニュー「サイト管理」
- 対象ドメインに切り替え(kamoroguya.com)
- 左メニュー「サイトセキュリティ」
- 上タブ「WAF」をクリック
- 表示切替「ログ」を選択
- 該当ログの左にある「除外」ボタンをクリック
- 「対象の攻撃を除外しますか?」 → 「はい」
- 5分待ってから再テスト
[スクショ: WAFログ画面の「除外」ボタン]
注意点が1つ。
除外したルールは、サイト全体に適用されます。
「この記事だけ除外」「このIPだけ除外」みたいな絞り込みはできません。
SQLi-22(and/or)を除外すると、サイト全体で「and」「or」を含むリクエストがWAFを通過するようになります。
セキュリティとしては若干緩くなります。
ただ、WordPress REST APIは内部でSQLを直接実行する仕組みではないので、影響は限定的だと判断しました。
ConoHa WAFには「IPホワイトリスト」がない
除外作業を続けながら、私はずっと違和感を抱えていました。
「Power AutomateのIPだけ許可すればいいんじゃ?」
普通のWAFには「特定のIPを許可する」ホワイトリスト機能があります。
これがあれば、信頼できるIPからのアクセスは全部通せます。
でも、ConoHa WINGのWAFには、この機能がありません。
あるのは「特定のIPを拒否する」ブラックリスト機能だけ。
逆のホワイトリストはなし。
つまり、除外できるのは「攻撃パターン(ルール)」だけ。
「特定の送信元」を例外扱いにはできません。
ちなみに、Power AutomateのIPも固定ではありません。
4.190.143.220、4.190.143.221、13.230.234.191、と実行ごとに変わります。
仮にホワイトリストがあっても、IPリストの管理が大変。
結局、ルール除外で対応するのが現実解でした。
VBAブログとConoHa WAFの構造的な相性問題
ここまでで気付いたこと。
VBAブログ × ConoHa WAFは、構造的に相性が悪い。
理由は単純で、VBAやPowerAppsで使う関数名や演算子が、攻撃パターンと被るからです。
誤検知される可能性が高い表現を、いくつか書き出しておきます。
- MsgBox → XSS判定
- Replace → SQLi判定
- and、or → SQLi判定(SQLi-22)
- Insert、Update、Delete、Select → SQLi判定(未確認、可能性大)
- Format、Eval、Execute → コード実行系判定(未確認)
- Mid、Left、Right → 文字列操作系判定(未確認)
VBAの定番関数、ほぼ全滅です。
これらを記事に書くたびに、WAFが反応する可能性があります。
SQL系のキーワードも全部。
VBAブログ運営者は、ConoHa WAFと永遠に戦うことになります。
3つの選択肢と、私が選んだ道
VBA記事 × ConoHa WAFの誤検知問題に対する選択肢は、3つあります。
選択肢A:個別ログ除外を続ける
記事を投稿するたびに失敗が出て、その都度除外していく方法。
メリット:セキュリティを大きく落とさない。
デメリット:対応に時間がかかる。新規ルールに当たるたびに止まる。
選択肢B:必要時だけWAFをOFF
リライト作業時だけ、ConoHa WAFを一時的にOFFにする運用。
メリット:確実に通る。作業がスムーズ。
デメリット:OFFの間はサイトが無防備。切り忘れるリスク。
選択肢C:ConoHa WAFを完全OFF
そもそもConoHa側のWAFを常時OFFにして、SiteGuard WP PluginだけでWordPressを守る運用。
メリット:誤検知地獄から完全に解放。
デメリット:サーバー側のセキュリティ層が消える。
私が選んだのは「A+α」
結論として、私はAの「個別除外」を続けつつ、長期的には Bや C も視野に入れる方針にしました。
理由は3つあります。
1つ目:1ヶ月もすれば主要な関数の誤検知パターンは出尽くす。
2つ目:除外作業はWAFログから1クリックで完結する。
3つ目:本物の攻撃ログも見えるので、サイトの状態が把握できる。
実際、WAFログを見ていると、本物の攻撃(.envファイル探索、wp-config.php探索、error_log.php探索)が大量に記録されています。
1日10件以上、海外のVPSから攻撃が飛んできます。
これらはWAFが正しくブロックしてくれています。
つまり、ConoHa WAFは「VBA記事に対して過剰反応する」けど、「本物の攻撃にはちゃんと反応する」。
これを承知の上で、誤検知パターンだけを少しずつ削っていく運用が、私には合っていました。
「先書き→上書き」パターンで効率化
除外作業を続ける中で、もう1つ発見がありました。
「Power Automateで投稿失敗するたびに、Claude APIのコストが消える」問題です。
HTTP 1(Claude API)は成功している。
HTTP 2(WordPress POST)で403で失敗。
でも、Claude APIの課金は発生済み。
1回 約10円とはいえ、失敗が積み重なるとバカになりません。
そこで、「リライト処理」とは別に「WAFテストだけのフロー」を新設しました。
このフローは、Claude APIを使わず、元記事をそのままWordPress POSTに投げるだけ。
無料でWAFテストできる仕組みです。
さらに、フロー設計で「先書き→上書き」パターンを採用しました。
- SharePointから「待機中」の記事を取得
- ステータスを先に「WAFテスト失敗」に書き込む
- WordPress GETで元記事取得
- WordPress POSTで元記事を投げる
- 成功時にステータスを「WAFテスト済み」に上書き
失敗時は、ステータスが「WAFテスト失敗」のまま残ります。
後で見返した時に、どの記事が引っかかっているかが一目で分かる。
この設計、社内SEらしい発想だなと自分でも思います。
このパターンの詳細は、別記事で解説予定です。
[INTERNAL_LINK: Power Automate「先書き→上書き」パターン解説記事]
22記事のWAFテスト結果
「先書き→上書き」フローを4時間ずらしのスケジュールで自動実行した結果が、これです。
22記事の処理結果(2026/05/16時点) - WAFテスト済み(成功):9件 (41%) - WAFテスト失敗:2件 (9%) - 待機中(未処理):8件 (36%) - 要確認(既存リライト試行):3件 (14%) WAF通過成功率:9/(9+2) = 81%
4ルールを除外した時点で、約8割の記事がWAFを通過するようになりました。
残り2件の失敗(PostID:40 VBA変数Dim、PostID:257 VBA実務CSV)は、まだ未知の検知ルールに当たっている可能性が高いです。
このペースなら、22記事全部のWAFテストを完了するまでに、あと数日かかる見込み。
地味な作業ですが、本番のリライト処理を走らせる前に、ここを潰しておけば失敗が激減します。
まとめ:VBAブログ運営者のWAFとの付き合い方
ここまでの経験を、社内SE視点でまとめます。
- ConoHa WAFは2層構造:プラグイン側とサーバー側がある。403のエラーメッセージで「SiteGuard Lite」が出ていればサーバー側。
- IPホワイトリストはない:除外できるのは「攻撃パターン(ルール)」だけ。
- VBA関数は誤検知の宝庫:MsgBox、Replace、and/orなど、定番関数が引っかかる。
- 個別除外で対応可能:WAFログから1クリックで除外できる。
- 本物の攻撃はWAFで防げる:.env、wp-config.php、error_log.phpの探索などは正しくブロック。
- 長期的にはWAF OFFも選択肢:VBAブログとの相性が悪すぎる場合は、SiteGuard WP Pluginだけの運用も検討。
ConoHa WAF、君は優秀なんです。
本物の攻撃はちゃんと止めてくれる。
ただ、VBAという文化圏のことを、ほんの少しでいいから理解してほしい。
MsgBoxは攻撃じゃないです。
VBAの第1歩目です。
__
この記事が、同じく ConoHa WAF と戦っている VBA ブログ運営者の助けになれば幸いです。
関連記事として、Power AutomateとClaude APIでブログリライトシステムを構築した経緯も書いています。
WordPress XMLRPCの攻撃ログが6,998件溜まっていた話も、同じ流れで書きました。
個人ブロガーがAPI連携を始めると、こういうトラブルが連鎖していきます。
でも、1つずつ潰していけば、必ず通れる道が見つかります。
社内SE、こういう作業が一番得意ですよね。
むしろ楽しい。
知らんて。
コメント