Windows 11の共有フォルダーにアクセスできない（0x80070035）を解決｜ゲストログオン禁止・SMB署名の正しい対処

Windows 11で共有フォルダーにアクセスできない（0x80070035）を最短で解決する｜「ネットワークパスが見つかりません」の原因と安全な恒久対処

Windows 10 と Windows 11 が混在するネットワークで、Windows 11 側からファイル／フォルダー／アプリ共有先の PC にアクセスすると 「ネットワークパスが見つかりません (0x80070035)」 が表示される問題について、業務復旧を最優先にする即効の回避策と、セキュリティを確保した恒久対処を体系立てて解説します。約200台規模の組織でも短時間で展開できるよう、手順・ポリシー設定・検証ポイント・ロールバックまでを一気通貫でまとめました。

症状の整理

Windows 11 端末から共有先（Windows 10、Windows 11、NAS、複合機など）に接続しようとすると、エクスプローラーや \\サーバー名\共有名 の指定で 0x80070035 が表示される。
ネットワーク一覧に相手が見えても、ダブルクリックするとエラー／タイムアウトとなる。
Windows 10 からは従来どおり接続できる場合がある（Windows 11 だけ失敗）。
社内 DNS が不安定な環境では、名前では失敗するが \\IPアドレス\共有名 なら一時的に接続できるケースもある。

この現象は、Windows 11 の SMB（ファイル共有）既定値が Windows 10 より厳格化されたことに起因することが多く、ゲストログオン禁止やSMB 署名必須と既存環境の設定不整合が重なると発生します。

原因の概要（なぜ Windows 11 で起きやすいのか）

Windows 11 では、セキュリティ強化の流れに合わせて SMB の既定挙動が変わりました。特に以下の差分が、Windows 10 時代の「緩い」共有運用と噛み合わず 0x80070035 を誘発します。

観点	Windows 10（従来）	Windows 11（新しい既定）	影響しやすいケース
ゲストログオン	条件により許容されることがあった	既定で禁止	共有先が「ユーザー名・パスワードなし（Everyone/Guest）」運用
SMB 署名	「必須でない」構成が一般的	必須／推奨度が高い構成が普及	共有先が署名に対応していない／不整合
SMB1	残存していても接続できた機器あり	SMB1 無効が前提	古い NAS・複合機・旧OS しか SMB1 を話せない
防火壁/探索	既存ルールで動くことが多い	プロファイル/ルール厳格化	TCP 445 閉塞、ネットワーク探索オフ
名前解決	NetBIOS/ブロードキャストに依存	DNS 依存度が高い	WINS/NetBIOS 混在で不安定、LLMNR/NBNS 競合

暫定的な回避策（即効性重視：まず業務を動かす）

まずは業務停止を避けるため、Windows 11 端末側で一時的にセキュリティ強化設定を緩め、Windows 10 時代と同様の接続を可能にします。実施後は速やかに恒久対処へ移行してください。

<ol>
  <li><strong>管理者権限で PowerShell を起動</strong></li>
  <li>次の 3 行を、1 行ずつ実行</li>
</ol>

<pre><code class="language-powershell">Set-SmbClientConfiguration -EnableInsecureGuestLogons $true -Force

Set-SmbClientConfiguration -RequireSecuritySignature $false -Force Set-SmbServerConfiguration -RequireSecuritySignature $false -Force

<ol start="3">
  <li><strong>PC を再起動</strong>し、共有フォルダーにアクセスできることを確認</li>
</ol>

<div>
  <p><strong>ポイント</strong></p>
  <ul>
    <li><code>-EnableInsecureGuestLogons $true</code>：ゲストログオン禁止を解除し、匿名（Guest）ベースの共有にも接続可能にします。</li>
    <li><code>-RequireSecuritySignature $false</code>：SMB 署名を<strong>必須ではない</strong>状態にし、署名に非対応／不整合な共有先との互換性を確保します（署名自体を常に無効化するものではありません）。</li>
    <li>この回避策により、多くの Windows 11 環境で 0x80070035 が解消した報告があります。</li>
  </ul>
</div>

<aside>
  <p><strong>セキュリティ注意</strong>：インターネット接続のある端末でゲストログオン許可を放置するのはリスクが高いです。<strong>恒久対処を適用でき次第、回避策を解除</strong>してください。</p>
</aside>

<details>
  <summary>回避策を元に戻すコマンド（ロールバック）</summary>
  <pre><code class="language-powershell">Set-SmbClientConfiguration -EnableInsecureGuestLogons $false -Force

Set-SmbClientConfiguration -RequireSecuritySignature $true -Force Set-SmbServerConfiguration -RequireSecuritySignature $true -Force Restart-Computer

恒久的な推奨対処（セキュリティ確保と運用の標準化）

<table>
  <thead>
    <tr>
      <th>観点</th>
      <th>推奨設定・作業</th>
      <th>補足</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>認証</td>
      <td><strong>ゲスト共有を廃止</strong>し、<strong>ユーザー名＋パスワード</strong>へ移行。AD 環境ならドメインアカウントを付与。</td>
      <td>共有権限：<code>Authenticated Users</code> または対象グループ／NTFS 権限：最小権限。共用IDではなく個人アカウント＋グループで制御。</td>
    </tr>
    <tr>
      <td>SMB 署名</td>
      <td>可能なら <code>RequireSecuritySignature</code> を<strong>true</strong>（必須）へ戻す。</td>
      <td>GPO：「コンピューターの構成 &rarr; Windows の設定 &rarr; セキュリティの設定 &rarr; ローカル ポリシー &rarr; セキュリティ オプション」内の<br>「Microsoft ネットワーク クライアント／サーバー: 通信にデジタル署名」を組織方針へ合わせて設定。</td>
    </tr>
    <tr>
      <td>プロトコル</td>
      <td><strong>SMB1 は無効のまま維持</strong>し、SMB v2/v3 で運用。</td>
      <td>SMB1 しか話せない機器は更改検討。やむを得ない場合は隔離ネットワークで限定運用。</td>
    </tr>
    <tr>
      <td>ネットワーク探索</td>
      <td>設定 &rarr; ネットワークとインターネット &rarr; ネットワークの詳細設定 &rarr; すべてのネットワーク で、<br><strong>ネットワーク探索</strong>と<strong>ファイルとプリンターの共有</strong>を有効化。</td>
      <td>ドメイン/プライベート プロファイルのみ有効、パブリックでは無効を推奨。</td>
    </tr>
    <tr>
      <td>ファイアウォール</td>
      <td>「<strong>ファイルとプリンターの共有 (SMB‑In)</strong>」受信ルールを許可。</td>
      <td>TCP 445 を確認。必要に応じて 137/138/139（NetBIOS）も見直し。</td>
    </tr>
    <tr>
      <td>名前解決</td>
      <td>DNS を正に。短縮名で不安定なら <code>\\IPアドレス\共有名</code> で緊急接続し、後で DNS を修正。</td>
      <td>DNS サフィックス/ゾーン/スカベンジ、重複Aレコード、逆引きの整合性を点検。</td>
    </tr>
  </tbody>
</table>

<h3>グループポリシー（GPO）で一括配布する</h3>
<p>約200台規模では、個別操作ではなく GPO で統一展開するのが確実です。</p>

<ol>
  <li>OU 単位で対象端末を整理（Windows 11 のみを対象にする WMI フィルターを併用）</li>
  <li><strong>緊急用 GPO</strong>（回避策）：必要なら短期間だけ「SMB 署名“必須でない”」「SMB クライアントのゲストログオンを許可」を配布</li>
  <li><strong>恒久 GPO</strong>：ユーザー認証への移行、SMB 署名必須、ファイアウォール許可、探索設定などを反映</li>
  <li><code>gpupdate /force</code> で反映、段階展開（パイロット → 全体）</li>
  <li>ロールバック用に「元の構成 GPO」も保持し、リンクの優先順位で切り替え可能にする</li>
</ol>

<details>
  <summary>WMI フィルター例（Windows 11 のみ対象）</summary>
  <pre><code>SELECT * FROM Win32_OperatingSystem

WHERE Version LIKE “10.0%” AND BuildNumber >= 22000 AND ProductType = 1

※ Windows 11 は内部バージョンが「10.0」で、ビルド 22000 以上が目安です。

<details>
  <summary>GPO の代表的な設定場所（管理用テンプレート）</summary>
  <ul>
    <li>コンピューターの構成 → 管理用テンプレート → ネットワーク → <strong>Lanman ワークステーション</strong> → 「<strong>安全でないゲストログオンを有効にする</strong>」</li>
    <li>コンピューターの構成 → Windows の設定 → セキュリティの設定 → ローカル ポリシー → セキュリティ オプション<br>「Microsoft ネットワーク クライアント: 通信にデジタル署名(常に)／(クライアントが同意した場合)」<br>「Microsoft ネットワーク サーバー: 通信にデジタル署名(常に)／(クライアントが同意した場合)」</li>
    <li>コンピューターの構成 → 管理用テンプレート → ネットワーク → ネットワーク接続 → Windows ファイアウォール → ドメイン プロファイル／プライベート プロファイル</li>
  </ul>
</details>

200台規模での実践展開プラン（安全・迅速・可逆）

現状把握：共有先（ホスト側）の種類（Windows 10/11/NAS/複合機）と認証方式を棚卸し。ゲスト運用の共有を洗い出し。
ポリシー方針：原則「ゲスト共有廃止・SMB 署名必須・SMB1 不使用」。例外は期限付き。
パイロット：代表部署 10～20 台で緊急 GPO → 接続確認 → イシュー収集。
本番段階展開：部署単位に順次リンク適用。各段で KPI（接続成功率・チケット件数）を確認。
ロールバック戦略：障害時は GPO のリンク順序を切替またはリンク無効化。緊急回避コマンドをドキュメント化。
是正計画：例外共有（ゲスト・旧 NAS）は更改スケジュールと代替案（部門ファイルサーバー、OneDrive/SharePoint 等）を合意。

トラブルシューティング深掘り（原因切り分けの実務手順）

<h3>1) 通信路の健全性を確認</h3>
<pre><code class="language-powershell"># 共有先まで 445/TCP が開いているか

Test-NetConnection -ComputerName サーバー名またはIP -Port 445 # 念のため DNS 解決もチェック Resolve-DnsName サーバー名 ping -a サーバー名

Test-NetConnection が失敗するなら、まずファイアウォール（クライアント／サーバー／区画間FW）やネットワーク ACL を見直します。

<h3>2) SMB クライアント設定を確認</h3>
<pre><code class="language-powershell">Get-SmbClientConfiguration | fl EnableInsecureGuestLogons, RequireSecuritySignature, EnableSecuritySignature</code></pre>
<p><code>EnableInsecureGuestLogons</code> が <code>False</code>、かつ共有先がゲスト運用なら接続不可になります。</p>

<h3>3) キャッシュされたセッションを整理</h3>
<pre><code class="language-powershell"># 既存の接続をすべて切断（注意）

net use * /delete /y # 指定資格情報で明示接続（推奨） net use \サーバー名\共有名 /user:ドメイン\ユーザー名パスワード

資格情報が競合しているケースは少なくありません。毎回異なる資格情報で同じサーバーへ接続はできません（SMB の仕様）。

<h3>4) 資格情報マネージャーを活用</h3>
<pre><code class="language-powershell"># 保存済み資格情報を確認

cmdkey /list # 事前に保存（端末共有PCなどで有効） cmdkey /add:サーバー名 /user:ドメイン\ユーザー名 /pass:パスワード

<h3>5) イベントログで失敗理由を特定</h3>
<ul>
  <li>アプリケーションとサービス ログ → Microsoft → Windows → <strong>SMBClient</strong>／<strong>SMBServer</strong> → Connectivity／Security</li>
  <li>セキュリティ ログ（ログオン失敗、資格情報の不一致、署名関係のイベント）</li>
</ul>
<p>ゲスト拒否・署名不一致・資格情報不備など、エラーの根拠が残ります。</p>

<h3>6) ネットワーク探索とサービス依存</h3>
<ul>
  <li>サービス：<code>Function Discovery Provider Host</code>、<code>Function Discovery Resource Publication</code>、<code>SSDP Discovery</code>、<code>UPnP Device Host</code> が停止していると探索に失敗しやすくなります。</li>
  <li>探索は <em>接続の前提ではない</em> ため、探索に頼らず <code>\\サーバー名\共有名</code> で直接指定できる状態に整えるのが理想です。</li>
</ul>

<h3>7) SMB1 は使わない（やむを得ない場合は隔離）</h3>
<pre><code class="language-powershell">Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol</code></pre>
<p>SMB1 を有効化すると脆弱性リスクが跳ね上がります。<strong>機器側で SMB2/3 を有効化</strong>するか、機器更改・ネットワーク隔離で対処してください。</p>

よくあるパターン別・現場対応チャート

症状/ログ	想定原因	対処
0x80070035、Windows 11 だけ失敗	ゲスト共有＋Windows 11 のゲスト禁止	即時：回避コマンド適用。恒久：ユーザー認証へ移行、署名必須へ戻す。
資格情報の入力を求められ続ける／認証ループ	キャッシュ競合、別ユーザーで既存セッション	`net use * /delete /y` 後、正しい資格情報で明示接続、資格情報マネージャーに保存。
名前では失敗、IP なら通る	DNS 設定不備、重複レコード	DNS を修正（A レコード・サフィックス）。暫定で `\\IP\共有名`。
Test-NetConnection 445 失敗	FW/ACL で 445/TCP 閉塞	「ファイルとプリンターの共有 (SMB-In)」許可。中間 FW を開放。
特定の古い NAS だけ不可	NAS が SMB1 のみ	NAS 側で SMB2/3 を有効化。不可なら更改 or 隔離。
ドメインPC間でのみ不可	署名必須の不整合	クライアント／サーバーの署名設定を統一。GPO で「常に署名」に揃える。

セキュリティの考え方（回避策は「橋渡し」、恒久策が本命）

ゲストログオンは原則禁止：ユーザー追跡・監査・最低権限の原則に反します。
SMB 署名は可能な限り必須：中間者攻撃対策。パフォーマンス影響は限定的で、セキュリティ効果が勝ります。
SMB1 は使わない：既知リスク多数。やむを得ない例外は、期限・範囲・ネットワーク分離・監査をセットで。
資格情報管理：端末共用環境では資格情報の保存/削除ルールを整備し、使い回しを避ける。
ログ監査：失敗イベントの定期レビューで不正アクセスや設定ずれを早期検知。

実務に役立つコマンド集（現場メモ）

# 共有一覧（ローカル）
Get-SmbShare

# 共有先に名前で接続（明示資格情報）

net use \サーバー名\共有名 /user:ドメイン\ユーザー名 パスワード

# 既存接続の確認と切断

net use
net use * /delete /y

# SMB クライアント設定の概要

Get-SmbClientConfiguration

# サーバー側（共有を提供しているPC）の署名要件

Get-SmbServerConfiguration | fl RequireSecuritySignature, EnableSecuritySignature

# DNS キャッシュの刷新（必要に応じて）

ipconfig /flushdns

# NetBIOS キャッシュのリロード（必要な場合）

nbtstat -R

巻末チェックリスト（導入・運用・監査）

回避策コマンドの適用・再起動・接続確認を実施した
対象共有のゲスト運用を廃止し、ユーザー認証へ移行した
クライアント／サーバー双方で SMB 署名の方針を統一した
FW の「ファイルとプリンターの共有 (SMB-In)」を許可した（ドメイン/プライベート）
DNS の A レコード／重複／サフィックスを点検した
SMB1 を無効で維持し、例外は隔離と期限を設定した
GPO で段階展開し、ロールバックプランを用意した
イベントログとサポート窓口の KPI を定期レビューする体制を整えた

まとめ

Windows 11 のセキュリティ強化（ゲストログオン禁止・SMB 署名の厳格化）は、従来の「緩い共有」運用と衝突しがちです。まずは本記事の回避策で業務を動かし、続いて恒久対処（ユーザー認証・署名必須・SMB1 排除・DNS/防火壁整備）に段階移行することで、安全かつ確実に 0x80070035 を解消できます。約200台規模でも GPO を軸にすれば、短期間で標準化が可能です。今日から着手し、「つながるだけでなく、守れる」共有基盤へアップグレードしましょう。

※本記事の手順は社内検証環境でテストしたうえで、パイロット → 全体の順に適用してください。環境固有の制約がある場合は、変更管理プロセスに則って進めることを推奨します。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Windows 11の共有フォルダーにアクセスできない（0x80070035）を解決｜ゲストログオン禁止・SMB署名の正しい対処

Windows 11で共有フォルダーにアクセスできない（0x80070035）を最短で解決する｜「ネットワークパスが見つかりません」の原因と安全な恒久対処

症状の整理

原因の概要（なぜ Windows 11 で起きやすいのか）

暫定的な回避策（即効性重視：まず業務を動かす）

恒久的な推奨対処（セキュリティ確保と運用の標準化）

200台規模での実践展開プラン（安全・迅速・可逆）

トラブルシューティング深掘り（原因切り分けの実務手順）

よくあるパターン別・現場対応チャート

セキュリティの考え方（回避策は「橋渡し」、恒久策が本命）

実務に役立つコマンド集（現場メモ）

巻末チェックリスト（導入・運用・監査）

まとめ

この記事を書いた人

コメント

コメントするコメントをキャンセル

Windows 11の共有フォルダーにアクセスできない（0x80070035）を解決｜ゲストログオン禁止・SMB署名の正しい対処

Windows 11で共有フォルダーにアクセスできない（0x80070035）を最短で解決する｜「ネットワーク パスが見つかりません」の原因と安全な恒久対処

症状の整理

原因の概要（なぜ Windows 11 で起きやすいのか）

暫定的な回避策（即効性重視：まず業務を動かす）

恒久的な推奨対処（セキュリティ確保と運用の標準化）

200台規模での実践展開プラン（安全・迅速・可逆）

トラブルシューティング深掘り（原因切り分けの実務手順）

よくあるパターン別・現場対応チャート

セキュリティの考え方（回避策は「橋渡し」、恒久策が本命）

実務に役立つコマンド集（現場メモ）

巻末チェックリスト（導入・運用・監査）

まとめ

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

Windows 11で共有フォルダーにアクセスできない（0x80070035）を最短で解決する｜「ネットワークパスが見つかりません」の原因と安全な恒久対処

コメントするコメントをキャンセル