VBAでブロック回避!Officeのセキュリティ強化と安全なサインイン対策

最近、Microsoft OfficeのVBAマクロを使って外部のWebサイトにサインインしようとしたら、突然ブロックされてしまって驚いた方もいるのではないでしょうか。私も州政府サイトからデータを取得する業務を任されていた時期に、同じような状況に陥り途方に暮れた経験があります。どうやらOfficeのセキュリティ強化が原因で、古い認証方式が「安全ではない」とみなされ、アクセスを拒否されてしまうケースが増えているようです。今回は、そうしたブロックを回避するためのレジストリ設定やグループ ポリシーによる対処、そしてログイン方式を見直す方法など、私自身が試してきた知見をまとめてみました。少しでもお役に立てれば幸いです。

VBAによるWebサイトアクセスがブロックされる背景

VBAのマクロでWebサイトにログインしてデータを取得するケースは、業務の自動化を図る上でよくあります。とくに定期的に情報を更新したい場面や、リモートデータを素早くExcelに落とし込みたいときなどには欠かせない手法です。しかし2024年1月以降、Microsoft Officeのセキュリティアップデートが原因で、この方法がブロックされる事態が増えています。

2024年1月以降に顕在化した問題

多くのユーザーが2023年まではまったく問題なく動いていたVBAマクロなのに、更新後から「Microsoft Officeが“https://…”へのアクセスをブロックしました。このソースは安全でないサインイン方式を使用している可能性があります」といったメッセージに悩まされるようになったと報告しています。私も同様のメッセージに出くわし、「え、昨日までは動いてたのに…」と思わず頭を抱えたものです。

レガシーな認証方式が原因

Officeがブロックをかける背景には、従来の基本認証(ベーシック認証)などのレガシーなログイン方式に対するセキュリティ制限の強化があります。最新のOfficeは、サイバーセキュリティの脅威が増す中で、安全ではないとみなされる方式をできるだけ排除する方向へ進んでいます。その一環として、OAuthやモダン認証を使用しないアクセスは危険扱いされる可能性が高まり、VBAマクロのQueryTablesやWinHTTPを使った古い方法でログインしようとすると、あっさりブロックされてしまうようになりました。

手動ログインとVBAログインの差

個人的な体験談として、手動でブラウザを開いて同じサイトにログインし、手入力でデータをコピーする分には問題がないのに、いざVBAからアクセスすると弾かれてしまう状況に陥りました。これでは自動化のメリットが失われてしまうどころか、余計な業務が増えてしまって大変ですよね。

確認すべき初期チェック項目

1. WindowsとOfficeのバージョンが最新かどうか
2. 最新のセキュリティ更新プログラムが当たっているか
3. QueryTablesやWinHTTPなどを使っていないか
4. basichostallowlistのレジストリを設定しているか
5. グループ ポリシーで設定が上書きされていないか

これらの基本的なチェックを行ったうえで、もし問題が続くようなら、次に紹介する方法を一つずつ試してみましょう。

レジストリ「basichostallowlist」の活用

Microsoft Officeが「安全ではないサインイン方式」と判断してブロックする場合でも、特定の信頼できるサイトをあらかじめホワイトリストに加えることで回避できるケースがあります。ここで登場するのがbasichostallowlistというレジストリキーです。

レジストリ設定の具体的手順

Officeのポリシー関連キーにbasichostallowlistを追加または編集し、対象のWebサイトのドメインを指定すると、Officeがそのサイトへのアクセスを「許可」扱いにしてくれる仕組みです。レジストリエディタから手動で編集することもできますが、コマンドラインで行う場合は以下のようになります。

REG ADD HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Common\Identity /t REG_EXPAND_SZ /v basichostallowlist /d "www.example.com"

上記のように、スラッシュやプロトコル（https://など）は含めず、「ドメイン名のみ」を指定するのがポイントです。例えばhttps://www.example.com/test_page/ にアクセスする場合でも、「www.example.com」とだけ記載します。

手動設定する場合は、後からいつでもドメイン名を追加・削除しやすいのがメリットです。

設定反映のタイミング

設定を追加しただけでは、Office側で反映されるまで少し時間がかかることがあります。特にWordやExcelなどアプリケーションを起動しっぱなしの状態でレジストリを更新すると、再起動しないと反映されないケースがあります。私も試したとき、設定を入れた直後はブロックメッセージが出続けましたが、Officeを完全に終了し、PCを再起動した後には正常にアクセスできるようになりました。

実際にレジストリを編集するときは、万が一に備えてバックアップを取る癖をつけています。以前、誤って余計なキーを消してしまい、Office自体の動作がおかしくなったことがあるので注意が必要です。

一部環境で効果がない場合

残念ながら、レジストリのbasichostallowlistを設定してもブロックが解除されないという報告がいくつかあります。原因として考えられるのは、ほかのポリシー設定やOfficeのバージョン、あるいはネットワーク環境による競合です。さらに、企業内ネットワークではプロキシサーバー経由のアクセスになっていることも多く、そこに追加の制限や設定が加わっている可能性もあります。

レジストリを編集しても確実に解決するとは限らず、企業内の一部ユーザーでは相変わらずブロックされ続けるケースがあります。

グループ ポリシーによる一括管理

組織的にOfficeのセキュリティ設定を管理している場合、IT管理者がグループ ポリシーを使ってbasichostallowlistの設定を全ユーザーに一括適用できます。部署が多い企業で一台ずつレジストリを触るのは大変ですし、誤設定によるトラブルリスクを避けるためにも、ポリシー側で統合的に管理するのが望ましいです。

管理テンプレート(ADMX)のインポート

Officeの管理用テンプレート(ADMXファイル)をActive Directoryにインポートしておくと、グループ ポリシー管理コンソール上で簡単にOffice特有の設定項目を操作できるようになります。たとえば「Office16.admx」「Office16.adml」ファイルを追加しておけば、Identity関連の設定をUI上で設定可能になります。

グループ ポリシーの設定例

1. グループ ポリシー管理コンソールを開き、対象の組織単位(OU)を右クリック
2. [編集] を選択し、コンピューターの構成もしくはユーザーの構成の「ポリシー」→「管理用テンプレート」→「Microsoft Office 2016」(あるいはバージョンに応じて)を展開
3. [Common/Identity] などの項目にあるbasichostallowlistの設定を有効にし、許可するドメイン名を入力
4. グループ ポリシーが適用されるまで、デフォルトでは数十分かかる場合があるため、「gpupdate /force」で強制的に更新するか、PCを再起動するなどして反映させる

一括適用すれば、ミスや漏れを減らせる点は非常にありがたいです。特に台数が多い環境では大いに助かります。

それでもブロックされる場合

グループ ポリシーで設定を行っても、設定が優先されない別のポリシーがある場合や、Officeのバージョン差異によって反映されないケースもあります。この場合、企業のIT部門やMicrosoftサポートと協力しながら、競合するポリシーやバージョン差異を洗い出す必要があります。

現場でよくあるのが、古い管理テンプレートを使っていて、最新のOfficeポリシーの設定項目が反映できていないというトラブルです。

Officeアプリの起動順序によるワークアラウンド

ちょっと不思議な話ですが、WordやOutlookなど別のOfficeアプリを先に起動しておくと、同じマクロコードでもブロックされないことがあると報告されています。実際に私自身も試してみましたが、先にExcelを立ち上げた状態でVBAを動かす場合と、Outlookを立ち上げた状態で動かす場合で結果が違うことがありました。

一時的な回避策として

この方法は根本的な解決にはなりません。設定やポリシーを変更せずに回避できる可能性があるというだけで、いつまたブロックされるようになるかはわかりません。業務で安定的に使用するには、やはりセキュリティ設定を適切に見直す必要があります。

私の体験談

ある日、徹底的にレジストリとグループ ポリシーを設定してもブロックを解除できず、もう手詰まりだと諦めかけていました。しかし、たまたまOutlookを先に起動してメールチェックをしていた状態でVBAを動かしたところ、すんなりログインできたことがありました。ただ、何度か再現性を確かめるうちに、また同じ設定でもブロックされる時もあって、安定しない印象です。

Officeアプリの連携は内部で複数の認証トークンをやり取りしているそうで、先に起動したアプリがうまくトークンを取得している場合はブロックされない、という説を見かけたこともあります。真偽のほどはわかりませんが、謎の挙動があるのは確かですね。

ログイン方式をモダン認証に切り替える

最終的な解決策として有力なのが、VBAの接続先にモダン認証(例えばOAuth 2.0やOpenID Connect)を導入している場合、VBAのコード側もそれに対応させることです。古い基本認証である限り、Officeのセキュリティ強化の度にブロックされるリスクが高まるからです。

サイト側でのモダン認証サポート状況

ただし、今回のケースのように州政府サイトなど、組織の独自システムを使っている場合はモダン認証を提供していないことも多いです。その場合は、こちら側でいくら準備してもどうにもなりません。運営側に問い合わせて、認証方法をアップデートしてもらう必要があります。

OAuth連携のサンプル

仮にサイトがOAuth認証を提供している場合、VBAでトークンを取得し、それをWebリクエストのヘッダに埋め込む形でアクセスする方法があります。以下は大まかな流れの例です。

'トークン取得の例(擬似コード)
Dim http As Object
Set http = CreateObject("MSXML2.XMLHTTP")

http.Open "POST", "https://auth.example.com/oauth/token", False
http.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
http.send "client_id=xxx&client_secret=yyy&grant_type=client_credentials"

If http.Status = 200 Then
    'トークンを抽出
    Dim token As String
    token = ParseJson(http.responseText)("access_token")

    '実際のAPIアクセス
    Dim http2 As Object
    Set http2 = CreateObject("MSXML2.XMLHTTP")
    http2.Open "GET", "https://api.example.com/data", False
    http2.setRequestHeader "Authorization", "Bearer " & token
    http2.send

    If http2.Status = 200 Then
        'データ取得成功
    End If
End If

このように、一度APIのトークン取得用のURLに対して必要な情報を送信し、取得したトークンを使って改めてデータ取得にアクセスする流れになります。基本認証よりも手順は複雑ですが、一度仕組みを作ってしまえば、Officeのアップデートに振り回されるリスクは減ります。

セキュアな環境を保ちつつ、自動化を安定的に運用できるところが大きな魅力です。

追加の考慮ポイントとトラブルシューティング

ここからは、私自身が遭遇したり聞いたりした細かなトラブル例と、その際に確認すべきポイントをまとめます。実際に設定を変えたり、コードを書き換えたりしているうちに、思わぬところでハマることがあるので、網羅的にチェックしてみてください。

複数バージョンのOfficeが混在している場合

組織内のPCによってOffice 2013、2016、2019、Microsoft 365などバージョンがバラバラのことは珍しくありません。すべて同じレジストリキーを使うわけではなく、Officeのバージョンによってレジストリパスやグループ ポリシーのツリー構造が微妙に異なることがあります。同じ設定をしているつもりでも、実は微妙に違っているということが起きがちです。

セキュリティソフトとの干渉

ウイルス対策ソフトや企業向けのエンドポイント保護ツールが、Officeアプリから外部サイトへのアクセスを制御することがあります。特に怪しいHTTPリクエストだと判断されると、通信そのものが遮断されてしまい、Office側のメッセージとは別にアクセス失敗となるケースがあります。IT部門やセキュリティ担当との連携が欠かせません。

対策表

HTML形式の簡単な表を用意しましたので、参考にしてみてください。

最終的なまとめと今後の展望

VBAマクロによる自動ログインとデータ取得を継続したい場合、まずはレジストリのbasichostallowlist設定やグループ ポリシーの適用を試してみる価値があります。それで解決する環境も多いですが、一部では依然としてブロックされることもあります。その場合は、Officeアプリケーションの起動順を工夫するといった回避策を試す、さらに根本的な解決としてサイト側やコード側でモダン認証の導入を検討するのが望ましいと考えます。

私自身、どうしてもモダン認証への切り替えが難しい環境を抱えていたときに、マイクロソフトのサポートに問い合わせて対応方針を尋ねたことがあります。結果的には、サポートでも「レジストリの設定を試す」「グループ ポリシーを確認する」「認証方式の見直しを提案する」というアドバイスが得られ、最終的には企業内のIT部門と連携して問題解決に至りました。

今後のアップデートに備える

Officeのセキュリティポリシーは今後も変化していく可能性が大いにあります。特にクラウドサービスが主流になりつつある現代では、基本認証のようなレガシー方式は段階的に廃止の方向へ進むでしょう。せっかく自動化を組んでも、数か月後のアップデートでまた使えなくなった…という状況を避けるためにも、できるだけ早めにモダン認証やセキュアな通信方式への移行を検討するのがおすすめです。

この記事の結論

1. レジストリbasichostallowlistに対象のドメインを追加する
2. グループ ポリシーで一括管理する場合は、ADMXのバージョンや競合ポリシーを確認
3. 一部環境ではOfficeアプリの起動順などのワークアラウンドが有効だが、あくまで暫定策
4. サイトがモダン認証を提供しているなら、将来的にはそちらへの切り替えが理想

自動化は便利な一方で、セキュリティ強化の波によって動かなくなる可能性も常に秘めています。問題が起きたら、まずは上記の方法を一つずつ試してみて、それでもダメならサポートやサイト運営者との連携を検討してみましょう。

私自身もブロックに悩まされたときは「もうマクロじゃなくて手動でいいかな…」と挫折しそうになりました。でも一度ちゃんと対処方法を覚えると、似たような問題が発生しても応用がきいて乗り越えやすくなるので、ぜひチャレンジしてみてください。