VMwareのダウンロード（やユーザ登録）に失敗する時は

--- 以下、Geminiの回答を編集した ---

企業ドメインのメールアドレスが必須らしい。
無いと Broadcomサイトで "user info. verification error" といったエラーが発生して進められない。
回避するための代替策は主に3つ。

目的（VMwareの無料版ダウンロード、商用ライセンスの管理など）に合わせて、以下の方法をお試しください。

1. 拒否対象外の「パブリックドメイン」を試す [1]

Broadcomのシステムは、Gmail、Yahoo Mail、Proton Mail（.me）などの主要なフリーメールを一律でブロックしていますが、一部のドメインはまだチェックをすり抜けて登録できるケースがユーザーコミュニティ（Reddit）で報告されています。

• 試す価値のあるアドレス: iCloud Mail (@icloud.com)、Mail.com、またはインターネットプロバイダ（OCN、So-net、NUROなど）から提供されている「プロバイダメール」 [2, 3]
• 注意点: 登録できた場合も「ベーシックユーザー」扱いとなり、製品の無料ダウンロード等は可能ですが、企業の有償ライセンス（Site ID）の紐付けには制限がかかる場合があります。 [4, 5, 6]

2. 自分専用の「独自ドメイン」を取得する（個人事業主・開発者向け） [7]

今後も海外のエンタープライズ製品（Broadcom、Cisco、Oracleなど）を個人で利用する機会がある場合、自身で年間数百円〜千円程度の独自ドメインを取得し、専用メールアドレスを作成するのが最も確実かつ根本的な解決策です。 [8, 9]

• 手順: お名前.com や Google Domains（現Squarespace） 等で独自のドメイン（例: yourname@mysite.com）を取得し、メール機能（ホスティングサービス）を設定します。
• メリット: 企業のフィルターに引っかからなくなり、ビジネス用としても信頼性が高まります。 [6, 9, 10]

3. パッケージ管理ツール（Homebrewなど）を利用する（開発環境の構築が目的の場合）

もし今回の目的が「VMware Workstation Pro」や「VMware Fusion」などのツールをPCにインストールすることだけであれば、Broadcomのサイトから直接ダウンロードするのを諦め、コマンドラインからインストールするという回避策もあります。 [2]

• Mac（Fusion）の場合: ターミナルを開き、brew install --cask vmware-fusion を実行する。 [2]
• Windows（Workstation）の場合: Windows Package Manager (winget) を使い、コマンドプロンプトで winget install VMware.WorkstationPro を実行する。
• ※これらの方法であれば、Broadcomアカウントの作成やログインの手間（ドメインエラー）を完全にスキップしてアプリケーションを導入できます。 [2]

Ref.

[1] https://knowledge.broadcom.com
[2] https://www.reddit.com
[3] https://www.reddit.com
[4] https://www.youtube.com
[5] https://knowledge.broadcom.com
[6] https://docs.automic.com
[7] https://symphonict.nesic.co.jp
[8] https://freeconsultant.jp
[9] https://gyo-gaku.com
[10] https://www.neo.space

DNSによるセキュリティ対策、ドメイン年齢加味

--- 以下、Gemini回答を編集した ---

一般的な無料パブリックDNS（1.1.1.2 / 9.9.9.9など）

• 危険なサイト（マルウェアやフィッシングなどの既知の脅威サイト）の自動ブロック（無害なIPを回答）はあるが、「新規ドメイン（作成からN日以内）をすべて遮断する」という個別設定はできない。 [1, 2]

ドメイン年齢でのフィルタリングが可能な低コストサービス

• NextDNS

• 特徴: 専用の「新規登録ドメインのブロック」スイッチがあり、最も手軽でお薦め。
• 月30万クエリまで無料。 超えると月額約300円〜
• マイページから細かなフィルタリング設定可。例、セキュリティタブ内に「新規登録ドメインのブロック（Newly Registered Domains）」という、専用のスイッチあり。

• Cloudflare Gateway / Cloudflare One

• 特徴: 企業・個人向けのセキュアDNS（SASE）ソリューション。
• 費用: 50ユーザーまで無料。[1, 3, 4]
• 管理画面のポリシー設定から、ドメイン年齢（Domain Age）でブロック可。

• AdGuard DNS (一部無料)

• 特徴: 広告ブロックで有名なサービス。
• 費用: 月間無料枠あり（一定のクエリ数まで）超えると有料プランへ移行する。 [4, 5, 6]
• セキュリティ用の独自フィルターを適用して危険なドメインやフィッシングサイトへのアクセスを抑制可。

まとめ

設定不要な手軽さ重視なら「1.1.1.2（Cloudflare）」や「9.9.9.9（Quad9）」で十分効果あり。
ドメイン年齢を基準に厳密に管理するなら、「NextDNS」か「Cloudflare Gateway」への乗り換えが最適。 [1, 2, 3, 4]

Ref. 

[1] https://developers.cloudflare.com

[2] https://www.bdo.com

[3] https://developers.cloudflare.com

[4] https://blog.cloudflare.com

[5] https://www.captaindns.com

[6] https://european-alternatives.eu

OPNsenseでのOpenVPNリモートアクセス設定

CA証明書とサーバ証明書がすでに準備できている状態で、残りの手順をGeminiに解説してもらい、少しだけ編集を加えた。
--------------------------------------------------------------------

残りの設定手順を、大きく5つのステップに分けて解説します。

これまでの確認事項（OPNsense 26.1.6、英語UI、IPv4限定、全通信をVPS経由にしてセキュリティDNSで保護する構成）をすべて反映した、決定版の設定手順書です。

手元での整理や今後の運用の記録としてお役立てください。

OpenVPN Remote Access Setup Guide (OPNsense 26.x)

Step 1: Create a User & Client Certificate

現在のバージョンでは、ユーザー作成と証明書の発行を個別のメニューで行い、Common Name を使ってシステム内部で紐付けます。

1-1. Create the User

1. System > Access > Users に移動し、右上の ＋ (Add) をクリックします。

2. 以下の項目を入力します。

   • Username: 任意のユーザー名（例: vpnuser）

   • Password: 任意のパスワード

3. 画面最下部の Save をクリックします。

1-2. Create the Client Certificate

1. System > Trust > Certificates に移動し、右上の ＋ (Add) をクリックします。

2. 以下の通り設定します。

   • Method: Create an internal Certificate

   • Descriptive name: 識別しやすい名前（例: vpnuser_cert）

   • Issuer: 事前に作成済みの CA証明書 を選択

   • Type: Client Certificate

   • Common Name: Step 1-1で作成した Username と完全に一致する文字列 を入力

3. 画面最下部の Save をクリックします。

Step 2: Configure the OpenVPN Instance (Server)

すべてのトラフィックとDNSクエリをVPS上のOPNsenseに集約するための核心的な設定です。

1. VPN > OpenVPN > Instances に移動し、右上の ＋ (Add) をクリックします。

2. 各セクションの項目を以下のように設定します。

[General Settings]

• Description: 任意の識別名（例: VPS_Secure_VPN）

• Role: Server

• Protocol: UDP

• Port: 1194（デフォルト）

[Cryptographic Settings]

• SSL/TLS Service Certificate: 事前に作成済みの サーバ証明書 を選択

[Authentication Settings]

• Authentication: Local Database を選択

[Server Settings]

• Server (IPv4): VPNクライアントに割り当てる仮想IP帯（例: 10.8.0.0/24）

  ⚠️ 自宅のLAN環境（192.168.x.xなど）と絶対に重複しない独立したネットワークを入力してください。

[Routing Settings]

• Local Network: 【空欄】（すべての通信をRedirectするため指定不要）

• Redirect gateway: default を選択

  💡 これにより、出先や自宅からのすべてのインターネット通信がOPNsense（VPS）を経由するようになります。

[DNS Settings]

• DNS Servers: 1.1.1.2, 9.9.9.9 など（セキュリティ機能付きDNSのIPを個別に入力）

3. 画面最下部の Save をクリックし、ページ上部に表示される Apply changes を押します。

Step 3: Configure Firewall Rules

外からのVPN接続を受け入れ、接続後にインターネット（WAN）へ通信を抜くためのファイアウォールとNATの設定です。

3-1. WAN Side Rule (外部からの接続許可)

1. Firewall > Rules > WAN に移動し、＋ (Add) をクリックします。

2. 以下の通り設定します。

   • Action: Pass

   • Protocol: UDP

   • Destination: WAN address

   • Destination port range: From 1194 To 1194

3. Save をクリックします。

3-2. OpenVPN Side Rule (VPNからインターネットへの通信許可)

1. Firewall > Rules > OpenVPN に移動し、＋ (Add) をクリックします。

2. 以下の通り設定してVPNからの全通信を通します。

   • Action: Pass

   • Protocol: any

   • Source: any

   • Destination: any

3. Save をクリックし、画面上部の Apply changes を押して反映させます。

3-3. Outbound NATの確認

1. Firewall > NAT > Outbound を確認します。

2. モードが Automatic であれば自動でVPNセグメントもNATされます。もし Manual や Hybrid にしている場合は、Step 2で設定したVPNの仮想IP帯（例: 10.8.0.0/24）がWANへ抜ける（Interface: WAN, Source: VPNネットワーク, Translation: WAN address）割当ルールが存在することを確認してください。

Step 4: Export Client Configuration

PCやスマホにインポートするための設定ファイル（.ovpn）を出力します。

1. VPN > OpenVPN > Client Export に移動します。

2. Remote Access Server: Step 2で作成したインスタンスを選択。

3. Export type: File Only を選択。

4. 画面下部の Accounts / Certificates に Step 1 のユーザー名が表示されていることを確認します。

5. HostnameにターゲットVPNサーバのホスト名またはIPアドレスを設定します。

6. その横にある Cloud/Download ボタン（ダウンロードアイコン） をクリックしてファイルを保存します。

Step 5: Client Connection Test

1. 利用するクライアント端末（PC、スマホ等）に公式アプリ OpenVPN Connect をインストールします。

2. Step 4で出力した .ovpn ファイルをアプリにインポートします。

3. Step 1-1で決めた Username と Password を入力し、トグルスイッチをONにして接続します。

接続後の確認

接続完了後、クライアント端末のブラウザ等で以下の確認を行ってください。

• 「確認君」などのIP確認サイトにアクセスし、表示されるグローバルIPアドレスがVPS（OPNsense）のものに変わっていること。

• DNSの漏洩確認サイト（dnsleaktest.com など）で、クエリの送信元が Step 2 で指定したセキュリティDNS（CloudflareやQuad9）になっていること。

WeChatをパソコンで安全に使用するには

書きかけ。

WeChatのサプライチェーンリスクを抑制するためのアイデア。

CopilotとGeminiに訊いて、抜粋、編集した　↓

---

方針

---

1. WeChatで機密情報を扱わない運用ルールを明文化する

• 「機密・機微情報はWeChatで送らない」
• 画面共有時も機密資料を開かない
• チャット内ファイル・URLの取り扱いを制限

---

導入・設定

---

2. VMwareゲストOSインストール

• （既に構築済みとして委細省略）

3. ホストへのアプリインストール、設定
3-1. OBS Studioインストール
3-2. VB-AUDIO Virtual Cableインストール

4. 物理セキュリティ、自動ログイン禁止、ロック、アップデート

• ホスト、VMで定期ウイルススキャン設定
• 個人デスクトップPC以外では自動ログインを絶対に有効化しない
• ブラウザのホーム画面に"ブラウザアップデート"を設定
• 自動アップデートされないものをリスト化し、定期アップデート
• スマホ・PCの画面ロック・OS更新・アプリ更新を徹底
  ※スマホは短時間アイドルでロック、PCは離席時ロック

5. VMwareのクリップボード分離設定を行う

• 対象VMを停止
• .vmx に以下を設定
  • isolation.tools.copy.disable = "TRUE"
  • isolation.tools.paste.disable = "FALSE"
  • isolation.tools.dnd.disable = "TRUE"

6. スマホ側でWeChatの「起動ロック（生体認証）」を有効化する

• WeChat：自分 → 設定 → プライバシー → アプリロック

7. スマホから「ログイン中端末」と「ログイン履歴」を定期確認する運用を入れる

• 「Windows/Mac WeChatにログイン中」バナーから即時ログアウト
• 設定 → アカウントのセキュリティ → ログインデバイスで不審端末削除

8. VM用カメラ構成を見直す（優先：仮想カメラ → ROM型カメラ）

• OBS等で仮想カメラ化
• 物理直結が必要ならROM型UVCカメラを使用

9. ホストOSのUACを「常に通知」に設定し、BadUSBの権限昇格を阻止する

• UACを最も厳しいレベルに設定

10. ホストのWindowsへの追加策

• ホストOSのファイアウォールでゲストからの通信をブロック
• USBデバイスの多くを禁止（運用難易度考慮して、採否検討）

10-1. ホストWindowsで「新規HIDデバイスの自動インストール禁止」ポリシーを設定する

• 既存デバイスを事前に接続
• gpedit.msc → デバイスのインストールの制限
• 「他のポリシー設定で記述されていないデバイスのインストールを禁止」を有効化

10-2. 必要に応じてUSBストレージのみ許可する例外ポリシーを設定する

• 「これらのデバイスクラスのフラグに一致するドライバーを使用したデバイスのインストールを許可する」を有効化
• クラスGUIDを登録

---

日常運用

---

11. 物理セキュリティ、自動ログイン禁止、ロック、アップデート（運用版）

• スマホ・PCの画面ロック・OS更新・アプリ更新を徹底

12. VPN利用時は「スマホと同一国の出口IP」を原則とする

• 日本利用時はVPNも日本リージョン
• 新規アカウント＋海外IP＋VMを避ける

13. QRコード認証時に「承認画面の文言を必ず読む」ルールを徹底する

• 承認前に端末名・IP・場所を確認
• スマホの自動ロック時間を30秒〜1分に設定

14. VMでUSBデバイスを使う場合の基本運用

14-1. VM会議後にカメラ・マイク・USBパススルーを毎回切断する

• 会議終了時にVMからデバイス割り当て解除
• USBハブの物理スイッチ等で遮断

15. VMでWeChatを使わない時間帯は、PC画面ロックを徹底する

• 離席時は必ず Win + L

16. ビデオ会議用VMは「会議直前に起動し、終了後すぐシャットダウン」する

• 常時起動を避ける
• 「起動→利用→終了」を標準手順化

17. WeChatアカウントで友人承認による解除を「最終手段」とする

• SMS認証・顔認証を優先
• 依頼する場合は日本番号の海外版WeChatユーザーに限定

---

A note on this month's Patch Tuesday

https://www.microsoft.com/en-us/msrc/blog/2026/05/a-note-on-patch-tuesday (05/12)

-----------------------------------------------------　以下、Geminiコメント抜粋

Claude Mythos Previewや、ご提示いただいたMicrosoft社の2026年5月のMSRCブログ（A note on this month's Patch Tuesday）に関するトピックは、まさに今、ITセキュリティ業界の最前線で激しい議論が行われているテーマです。

ご質問いただいた3つの問い（世間の共通認識か、Microsoftの手法は標準的か、エンドユーザーは判断可能か）について、現在のセキュリティ実務とエンドユーザーの心理から紐解いて解説します。

---

1. 「出荷前のコードレビュー・監査」はエンドユーザーの共通認識と言えるか？

結論： 強い要望としては急速に共通認識化しつつありますが、**「エンドユーザーが自覚的に求める」というよりは、「業界標準（サプライチェーンセキュリティ）としての義務化」**という形で社会に定着しつつあります。

Claude Mythosのような超高度AIの登場により、脆弱性を、見つかったものから順次パッチを当てる」という後手の運用（リアクティブ）では守りきれないという危機感が世界中で共有されています。

しかし、一般のエンドユーザー（非エンジニアの消費者や一般企業）の認識は以下のような状態です。

• 理想のシチュエーション： 「AI時代なのだから、メーカーは出荷前にAIでバグを全部洗い流してから製品を出してほしい」という期待。
• 現実の共通認識： ユーザー自身がソースコードの監査体制をチェックすることは不可能なため、米国政府の「米大統領令14028号（安全なソフトウェア開発：SSDF（NISTの Secure Software Development Framework））」やヨーロッパの「サイバーレジリエンス法（CRA）」といった法規制や公的ガイドラインを満たしている製品を選ぶ、という形で間接的に要求が具現化しています。

---

2. Microsoft社のAIやコードレビュー手法は「標準的」か？

結論： 現時点では「最先端のトップランナー（デファクトスタンダードの雛形）」であり、まだ業界全体の「一般的な標準」とは言えません。

これが「標準」と言い切れない理由は3つあります。

1. マルチモデルのハイブリッド運用： 単一のAIにコードを読ませるだけでなく、異なる特性を持つ複数の高度AIモデルを組み合わせ、さらに「人間の専門家（MSRC）」が最終検証を行う重層的なパイプラインを組んでいます。これだけの投資ができる企業は世界でも一握りです。
2. 発見数の爆発（AI-finder era）： ブログにある通り、AIの導入によって「すでに調査し尽くしたはずの古いコード」からも大量の脆弱性が再発見され、パッチのリリース規模が肥大化しています（2026年5月は130件超の大量パッチ）。この規模の検証と修正を毎月回せる体制自体が、まだ標準ではなく「Microsoft級の超大手だからできる力技」です。
3. 過渡期である点： Microsoft自身もブログで "We are still early in this work（この取り組みはまだ初期段階にある）" と述べており、手法自体を現在進行形で模索している段階です。

---

3. その「標準的」水準をエンドユーザーは判断可能か？

結論： エンドユーザーが技術的な中身（どんなAIモデルをどう使っているか）を直接判断することは不可能です。 したがって、「外部認証」や「メーカーの開示姿勢」を指標にするしかありません。

エンドユーザーがソフトウェアの安全性を評価する際、現実的には以下の「代替指標」を使って判断することになります。

判断の拠り所となる3つの指標

• SBOM（ソフトウェア部品表）と安全宣言：
  製品にどんな部品が使われ、どうテストされたかを証明する「SBOM」や、米NISTの「SSDF（セキュアソフトウェア開発フレームワーク）」に準拠しているかどうかのベンダー自己宣言。
• パッチ公開の透明性と一貫性：
  Microsoftのように「AIで見つかった脆弱性を、既存のセキュリティ基準（CVSSや悪用可能性インデックス）に基づいて淡々と検証・公開しているか」という実績。脆弱性が増えたことを隠さず公表する姿勢そのものが、信頼性の判断材料になります。
• セキュリティベンダーによる第三者評価：
  JPCERT/CCやIPA、あるいは大手のセキュリティリサーチ企業がその製品の脆弱性対応をどう評価しているかという二次情報。

---

まとめ

Claude Mythos級のAIが普及した現代、「AIにコードレビューをさせてから出荷する」ことは、数年以内にソフトウェア業界の最低限の“身だしなみ（標準）”になると予想されます。

しかし、現時点ではMicrosoftのような巨人がその「新しい標準」を力づくで作っている最中です。私たちユーザー側は、コードの中身を覗けない以上、「そのメーカーが最新のAI脅威/AI防御のトレンド（SFIなど）に追随し、透明性を持って情報を開示しているか」を企業の信頼性として見極めていく必要があります。

-----------------------------------------------------　以上、Geminiコメント抜粋

以前訊いた時は『Open Sourceに比べてクローズドソースの競争優位は大きく削がれていく』旨のコメントだった。
MSFTの追い上げ。

WordPressの脆弱性対策の考え方

 https://share.google/aimode/PtfNBGH3gBPTKoB81

『Q. WordPressを使う場合、脆弱性パッチの発表を待つだけで良い?

A. 結論から言うと、脆弱性の発表を待つだけの「後追い」対策では不十分です。

おっしゃる通り、修正パッチが出る前に攻撃が行われる「ゼロデイ攻撃」や、プラグインの組み合わせによる予期せぬ隙を突かれるリスクは常にあります。

「WordPressを使わない」という選択肢は、現代のWeb運用において「非常に有力なリスク回避策」として再評価されています。その場合の主な代替案と、判断のポイントを整理しました。

1. 「WordPressを使わない」という選択肢

セキュリティを最優先にするなら、以下の2つの方向性が現実的です。

• 静的サイトジェネレーター（SSG）への移行 (例: Astro, Hugo, Gatsby)
• 仕組み: サーバー上でPHPを動かさず、あらかじめ生成したHTMLファイルを配信します。
• メリット: データベースや実行プログラムがないため、「WordPress特有の脆弱性」が物理的に存在しなくなります。 読み込みも爆速です。
• デメリット: 更新にエンジニア知識が必要になる場合が多いです。
• SaaS型CMSへの移行 (例: microCMS, Contentful, または Shopify, Note Proなど)
• 仕組み: システムの管理・保守をすべてサービス提供元に任せます。
• メリット: セキュリティアップデートを自分でする必要がなく、インフラ側の責任を負わなくて済みます。
• デメリット: 月額費用がかかることや、デザイン・機能のカスタマイズに制約が出ることがあります。

2. WordPressを使い続けるなら「発想の転換」が必要

もし、操作性やコスト面でWordPressを使い続けたい場合は、「脆弱性を防ぐ」から「攻撃を無効化する」という考え方にシフトする必要があります。

• 「静的化」プラグインの活用: 管理画面はローカルや閉鎖環境に置き、表側のサイトはHTMLとして書き出して公開する手法です。
• WAF（Web Application Firewall）の導入: 脆弱性の有無に関わらず、不審な通信（攻撃パターン）をネットワークの入り口で遮断します。
• フルマネージド・ホスティング: セキュリティ対策をサーバー側で一括代行してくれる高機能なサーバー（Kinstaや、国内の法人向けWP専用プランなど）を利用する。

3. 判断の基準

• 「更新頻度が低い」「フォームや会員機能が不要」なサイト
  → WordPressを捨てて、静的サイトにするのが正解です。管理の手間とリスクがゼロになります。
• 「毎日更新する」「多機能なプラグインが必要」なサイト
  → WordPressを使いつつ、強力なWAFとバックアップ、徹底した権限管理に投資する必要があります。

「WordPress＝無料・簡単」という認識は過去のものです。現在は、「使いやすさと引き換えに、相応の防御コスト（または手間）を払うツール」になっています。

』　以上 Geminiとの会話から抜粋

DAEMON Toolsにマルウェア混入。約1か月も公開されたままに

https://www.nichepcgamer.com/archives/post-128563.html (05/07)

『Windows用仮想ドライブアプリ、DAEMON Toolsにマルウェアが混入していたことが明らかになりました。

マルウェアが混入していたのは無料版のDAEMON Tools Lite バージョン12.5.1 (カスペルスキーによると12.5.0.2421から12.5.0.2434)。このバージョンにはトロイの木馬・バックドアが含まれており、2026年4月8日から2026年5月4日までDAEMON Tools公式サイトに公開されていました。

・・・中略・・・

マルウェアの含まれていないDAEMON Tools Lite バージョン12.6.0 (12.6.0.2445)を公開しました。

・・・中略・・・

もし、今も使っていて、継続的にアップデートをされている方はお気をつけください。マルウェア混入バージョンをインストールされた方は、OSのクリーンインストールを強く推奨いたします。』