OneDrive「ファイル オンデマンド」と業務アプリ ── プレースホルダーが壊す前提と対策

「デスクトップに保存したCSVを業務アプリが読めない」「今まで動いていた取込処理が、PC入れ替え後に『ファイルが見つかりません』で落ちる」「エクスプローラーで見るとファイルはあるのに、アプリで開くとエラーになる」── ここ数年、お客様からこの種の相談が定番化しています。

調べていくと、原因はアプリのバグではなく、OneDriveの「デスクトップ・ドキュメントの自動バックアップ」(既知のフォルダーの移動、KFM)と「ファイル オンデマンド」であることが少なくありません。デスクトップの実体は C:\Users\<名前>\OneDrive\デスクトップ に移動しており、そこに見えているファイルの一部は、ローカルに実体のない「プレースホルダー」です。ユーザーも情シスも、この変化に気づかないままPCを使っています。

つまり、「ローカルディスクにファイルがある」という業務アプリの暗黙の前提が、いつの間にか「クラウドにファイルがあり、ローカルには見かけだけがある」という前提に置き換わっているのです。この記事では、中小企業の情シス担当者とWindowsアプリ開発者を対象に、プレースホルダーの仕組み、ファイル属性による状態判定、業務アプリが踏む典型的な落とし穴、開発側・情シス側それぞれの対策、そして「ファイルが読めない」相談を受けたときの切り分け手順までを、Microsoft Learnの一次情報にもとづいて整理します。

1. まず結論

• デスクトップ・ドキュメント・ピクチャは、KFMによって C:\Users\<名前>\OneDrive\ 配下へ移動していることがあります。新PCの初期セットアップで有効化されやすく、組織ではポリシーで一斉適用もできます。固定パスを前提にしたアプリはここで壊れます。¹
• ファイル オンデマンドは現在の同期アプリで既定で有効です。他のデバイスやWebで作られたファイルは、ローカルに実体のない「オンライン専用」のプレースホルダーとして見えます。²³
• プレースホルダーの正体は、Cloud Files API(cldflt.sysミニフィルター)が管理するリパースポイントです。エクスプローラーにもファイルAPIにも普通のファイルとして見え、開くと自動でダウンロード(ハイドレーション)されます。⁴
• 状態はファイル属性で判定できます。FILE_ATTRIBUTE_OFFLINE、RECALL_ON_DATA_ACCESS、PINNED、UNPINNEDなどが目印で、attribコマンドではO・P・Uの文字で見えます。属性の確認だけならダウンロードは発生しません。⁵⁶⁷
• 業務アプリの典型的な事故は、「開けない」「遅い」「属性誤判定」「監視イベントの嵐」「同期との競合」の組み合わせです。オフラインやOneDrive停止時はハイドレーションが失敗し、一括処理は全ファイルのダウンロードを誘発します。⁴⁸
• アプリ側の対策は「プレースホルダーを尊重する」ことです。列挙時に属性で判定して不用意に開かない、必要ならFILE_FLAG_OPEN_NO_RECALLを使う、データフォルダーをOneDrive配下に置かない、が基本です。⁹¹⁰
• 情シス側の対策は「ピン留めの運用」と「ポリシーでの統制」です。業務フォルダーは「常にこのデバイス上に保持する」で実体を保証し、KFMとファイル オンデマンドはグループポリシー/Intuneで意図を持って構成します。ストレージセンサーが「使っていないファイルをオンライン専用に戻す」動きをすることも忘れないでください。¹¹¹²

一文でまとめるなら、「エクスプローラーに見えているファイル」と「ローカルディスクに実体があるファイル」は、もう同じではないということです。

2. 何が起きているのか ── KFMとファイル オンデマンド

2.1. デスクトップはもう C:\Users\<名前>\Desktop ではないかもしれない

OneDrive同期アプリには「既知のフォルダーの移動」(Known Folder Move、KFM)という機能があります。設定画面では「バックアップ」「重要なフォルダーをバックアップする」などと表示されるもので、有効にするとデスクトップ・ドキュメント・ピクチャの実体がOneDriveフォルダー配下へ移動(リダイレクト)されます。¹

新しいPCの初期セットアップ(OOBE)でMicrosoftアカウントや職場アカウントにサインインすると、フォルダーのバックアップが既定で提案され、そのまま進めると有効になる構成が広く出回っています。組織では「Windowsの既知のフォルダーをOneDriveにサイレントに移動する」ポリシー(KFMSilentOptIn)で、ユーザーに何も聞かずに一斉適用することもできます。¹¹¹

厄介なのは、エクスプローラー上の見た目がほとんど変わらないことです。シェルの既知フォルダーAPI(SHGetKnownFolderPathや.NETのEnvironment.GetFolderPath)は移動後の正しいパスを返すため、行儀よく書かれたアプリは動き続けます。壊れるのは、C:\Users\%USERNAME%\Desktop のような固定パスを設定ファイルやコードに埋め込んでいるアプリです。PC入れ替え後に取込処理が「ファイルが見つかりません」で落ちる典型パターンは、これです。

2.2. ファイル オンデマンド ── 見えているのに実体がない

もうひとつの主役が「ファイル オンデマンド」(Files On-Demand)です。有効な環境では、OneDrive上の全ファイルがエクスプローラーに見えますが、中身は開かれるまでダウンロードされません。この機能は現在の同期アプリでは既定で有効であり、Microsoftも有効のままの運用を推奨しています。²³

状態はエクスプローラーの状態アイコンで見分けられます。¹³

ここで重要なのは真ん中の状態です。一度開いてローカルに実体ができたファイルも、ユーザーの「空き領域を増やす」操作や、後述するストレージセンサーによって再びオンライン専用へ戻ることがあります。「先月は動いていたのに」という再現性の低い障害の一因です。³¹²

3. プレースホルダーの正体 ── Cloud Files APIとリパースポイント

ファイル オンデマンドは、Windows 10 バージョン1709で導入されたCloud Files API(クラウドファイルAPI)という OS の仕組みの上に実装されています。ファイルシステム側の実働部隊は cldflt.sys(サービス名 CldFlt、「Windows Cloud Files Filter Driver」)というファイルシステムミニフィルターで、OneDriveはこのAPIを使う「同期プロバイダー」のひとつです。⁴⁷

プレースホルダーは技術的にはリパースポイントです。ファイルシステム上にはファイル名・サイズ・タイムスタンプなどのメタデータ(約1KB)だけが存在し、中身のデータはありません。アプリがファイルを開いて読むと、ミニフィルターが要求を検知して同期プロバイダーにデータ転送を指示し、ダウンロード完了を待ってから読み取りが進みます。この取り寄せをハイドレーション、逆にローカルの実体を捨ててプレースホルダーに戻すことをデハイドレーションと呼びます。⁴

リパースポイントと聞くと「リパースポイントを検出したら特別扱いする」既存コードとの相性が心配になりますが、Cloud Files APIは互換性のため、同期エンジンと %systemroot% 配下のプロセス以外にはリパースポイントであることを隠します。普通のアプリからは「少し開くのが遅いだけの普通のファイル」に見えるわけです。この徹底した透過性こそが、便利さと同時に「アプリが気づかないまま前提を壊される」原因にもなっています。⁴ リパースポイントそのものの仕組みは「NTFSの内部構造」で解説しています。

エクスプローラーのプロパティで見ると、プレースホルダーは「サイズ」には本来のサイズが表示されるのに「ディスク上のサイズ」がほぼ0という特徴的な見え方をします。「サイズがあるから実体もあるはず」という思い込みは、ここでは通用しません。

4. ファイル属性で状態が分かる

プレースホルダーの状態は、通常のファイル属性として公開されています。主なものは次のとおりです。⁵

コマンドプロンプトの attrib コマンドは、これらを1文字で表示・設定できます。O がオフライン属性、P がピン留め、U が非ピン留めです。⁶ OneDriveのファイル オンデマンド状態との対応は、Microsoftのドキュメントで次のように整理されています。⁷

1つ注意があります。状態の切り替えには順序があります。オンライン専用(U)のファイルを「ローカルで利用可能」にしたいとき、-pだけを実行してもUが付いたままで実体は取得されません。Microsoftのドキュメントも、いったん+p(常に利用可能)にして実体をダウンロードさせてから-pする手順を示しています。⁷ 既存の状態を確実に切り替えるスクリプトでは、attrib +p -uのように反対側の属性も同時に外すのが安全です。

PowerShellで判定する例です。属性を見るだけならハイドレーションは発生しないので、調査や一括チェックに安心して使えます。

function Test-CloudPlaceholder {
    param([Parameter(Mandatory)][string]$Path)

    $value = [int](Get-Item -LiteralPath $Path -Force).Attributes

    [pscustomobject]@{
        Path               = $Path
        Offline            = ($value -band 0x00001000) -ne 0  # FILE_ATTRIBUTE_OFFLINE
        RecallOnDataAccess = ($value -band 0x00400000) -ne 0  # 中身が全部はローカルにない
        Pinned             = ($value -band 0x00080000) -ne 0  # 常にこのデバイス上に保持
        Unpinned           = ($value -band 0x00100000) -ne 0  # オンライン専用
    }
}

# ドキュメントフォルダー配下のCSVを一括チェック(中身はダウンロードされない)。
# パスは既知のフォルダーAPIで解決する。「ドキュメント」という表示名を直書きすると、
# 実フォルダー名が英語(Documents)の環境やKFMの構成によっては存在しないパスになる
Get-ChildItem ([Environment]::GetFolderPath('MyDocuments')) -Recurse -Filter *.csv |
    ForEach-Object { Test-CloudPlaceholder $_.FullName } |
    Where-Object RecallOnDataAccess |
    Format-Table -AutoSize

[int]にキャストしているのは、.NETのFileAttributes列挙型にはRECALL_ON_DATA_ACCESSなどの名前が定義されていないためです。数値でビット演算すれば問題なく判定できます。

5. 業務アプリが踏む落とし穴

ここからが本題です。プレースホルダーの透過性は普段は便利ですが、業務アプリの典型的な処理パターンと組み合わさると、次の6つの形で表面化します。

5.1. 開くと自動でダウンロードが走る ── オフラインで「開けない」

オンライン専用ファイルを開くと、その場でハイドレーションが始まります。オンラインで小さいファイルなら気づかない速さですが、OneDriveが停止・サインアウト・一時停止しているとき、ネットワークが不調なとき、ファイルが大きいときは、「存在するのに開けないファイル」になります。エラーは ERROR_CLOUD_FILE_PROVIDER_NOT_RUNNING(0x8007016A、「クラウド ファイル プロバイダーが実行されていません」)のようなクラウドファイル系のコードで返ることもあれば、アプリ側のタイムアウトとして観測されることもあります。⁸

さらに罠なのは、File.Exists() に相当する存在確認や属性・サイズの取得は成功することです。「存在確認は通ったのに読み取りで失敗する」という、ローカルディスクの感覚では説明のつかないエラーパターンになります。

5.2. 一括処理が全ファイルのダウンロードを誘発する

フォルダー内の全ファイルを読むバッチ処理、ハッシュ計算、全文検索、独自のバックアップ処理などをOneDrive配下に向けると、触ったファイルすべてのハイドレーションが誘発されます。数GBのフォルダーなら、処理が異常に遅くなるだけでなく、ダウンロードでディスクを圧迫し、低容量のPCでは空き容量不足で別の障害を招きます。ファイル オンデマンドで節約していたはずの容量が、たった1回のフルスキャンで消えるわけです。

なお、ユーザーの明示的な操作なしにアプリがハイドレーションを起こした場合、Windowsがトースト通知を出してユーザーにブロックの選択肢を与えることがあります。ここでブロックされると、そのアプリは以後ダウンロードに失敗し続けます(設定の「ファイルの自動ダウンロード」で解除できます)。「特定のPCでだけ取込が失敗する」の一因です。⁴

5.3. 属性を想定しないコードの誤動作

FILE_ATTRIBUTE_OFFLINEやRECALL_ON_DATA_ACCESSを知らないコードは、思わぬ場所で誤動作します。

• 属性を完全一致で判定している(attributes == FileAttributes.Archive など)ため、プレースホルダーが「想定外のファイル」として除外・エラー扱いされる
• バックアップ・同期系ツールの除外判定が、OFFLINE属性を「テープに退避済み」と解釈してスキップする(あるいは逆に、除外すべきなのに全ファイルを取り寄せる)
• 読み取り専用チェックやアーカイブビットの操作が、属性の組み合わせを壊す

Microsoftはミニフィルター開発者向けのガイダンスで、RECALL_ON_DATA_ACCESSが付いたファイルへ不用意な読み書きを発行しないよう明記しています。カーネルドライバー向けの文書ですが、「この属性が付いたファイルの中身に触れる＝取り寄せコストが発生する」という原則は、ユーザーモードのアプリにもそのまま当てはまります。¹⁰

5.4. FileSystemWatcherと同期の相互作用

OneDrive配下のフォルダーをFileSystemWatcherで監視すると、ユーザーの操作だけでなく同期アプリの活動によるイベントも大量に届きます。他のデバイスでの変更が同期されるたび、ハイドレーション・デハイドレーションで属性やサイズが変わるたびに、Changedイベントが発生し得ます。さらに、監視して取り込んだ結果を同じフォルダーに書き戻す設計だと、書き込み→アップロード→属性更新→再イベントというループで「変更通知の嵐」になります。イベントの間引きや実体確認の設計は「FileSystemWatcher実務ガイド」で扱ったとおりですが、OneDrive配下ではその必要性が一段と高まります。

5.5. 排他ロック中の同期競合と「コピー」ファイル

業務アプリがファイルを排他ロックで開いている間、同期アプリはそのファイルをアップロードも更新もできません。長時間ロックを保持するアプリ(Accessの.accdb、独自形式のデータファイル、ログファイルなど)をOneDrive配下に置くと、同期エラーが常態化します。逆に、複数のPCで同じファイルを編集すると、同期アプリは両方の版を残そうとして、PC名の付いた重複ファイルや「〜のコピー」といった競合コピーを生成します。取込処理が「1フォルダー1ファイル」を前提にしていると、この重複ファイルで誤動作します。ロック設計の基本は「ファイル連携の排他制御の基礎知識」を参照してください。

5.6. ウイルス対策・検索インデクサがハイドレーションを誘発する

ファイルの中身を読むのは業務アプリだけではありません。ウイルス対策ソフトのフルスキャンや検索インデクサも、プレースホルダーの中身に触れればハイドレーションを誘発します。Microsoft DefenderなどはRECALL_ON_DATA_ACCESS属性の付いたファイルをオンデマンドスキャン時にスキップする実装になっていますが、これは製品側の対応であり、すべてのセキュリティ製品が同じ配慮をしてくれるとは限りません。「夜間スキャンのたびにネットワークとディスクが張り付く」「オンライン専用にしたはずのファイルが翌朝すべて実体化している」といった症状が出たら、この線を疑います。¹⁴

6. アプリ開発側の対策 ── プレースホルダーを尊重する

開発者としての基本方針は、プレースホルダーを「壊れたファイル」ではなく「取り寄せコストのあるファイル」として扱うことです。

• 列挙時に属性で判定し、不用意に開かない。フォルダースキャンでは、まず属性(4章の判定)でオンライン専用かを確認し、中身が必要なファイルだけを開きます。ログ収集・ハッシュ計算・プレビュー生成のような「なくても致命的でない」処理は、プレースホルダーをスキップする選択肢を持たせます。

// .NETのFileAttributesに未定義の値は数値で定義する
const FileAttributes RecallOnDataAccess = (FileAttributes)0x00400000;
const FileAttributes RecallOnOpen       = (FileAttributes)0x00040000;

static bool IsCloudPlaceholder(FileAttributes attributes) =>
    (attributes & (RecallOnDataAccess | RecallOnOpen | FileAttributes.Offline)) != 0;

foreach (var file in new DirectoryInfo(watchFolder).EnumerateFiles("*.csv"))
{
    if (IsCloudPlaceholder(file.Attributes))
    {
        log.Warn($"{file.Name} はオンライン専用のため今回は処理をスキップします");
        continue;
    }
    Import(file.FullName);
}

• FILE_FLAG_OPEN_NO_RECALLは「ダウンロードしない」保証ではない点に注意する。CreateFileにこのフラグを指定すると、「取得したデータをローカルストレージへ書き戻さず、リモート側に置いたままにすべき」という意図を示せます。ただしこれはあくまで取得したデータをローカルに定着させないためのフラグで、中身を読めばデータの転送自体は発生します。帯域や遅延そのものを避けたいなら、属性・サイズ・タイムスタンプだけで済ませる ── 読み取りアクセスを要求しない(アクセス権0で開く、列挙結果のメタデータを使う)のが最も安全です。⁹
• エラーメッセージに「OneDrive配下です」と出す。読み取り失敗時に、対象パスが %OneDrive% 配下かを確認してメッセージに含めるだけで、現場とヘルプデスクの切り分け時間が大幅に減ります。0x8007016Aなどのクラウドファイル系エラーを検知したら「OneDriveの状態を確認してください」と案内するのが理想です。
• アプリのデータフォルダーをOneDrive配下に置かない。KFM環境では「ドキュメント」もOneDrive配下です。アプリの設定・データベース・作業ファイルは %ProgramData% や %LocalAppData% に置き、既定の保存先・取込フォルダーの既定値にデスクトップやドキュメントを選ばないでください。どこに何を置くべきかの判断は「Windowsアプリのデータ保存先の選び方」にまとめています。
• ユーザーがOneDrive配下を選んだ場合の挙動を決めておく。保存先をユーザーに選ばせるアプリなら、選ばれたパスがOneDrive配下(環境変数 OneDrive/OneDriveCommercial のパス配下)のときに警告する、あるいはロックファイルやDBの配置だけは拒否する、といった設計判断をあらかじめ仕様に含めます。

7. 情シス側の対策 ── ピン留めとポリシーで統制する

情シスの立場では、「ファイル オンデマンドを全部切る」のではなく、業務に必要な場所だけ実体を保証する運用が現実的です。

• 業務アプリが読むフォルダーはピン留めする。エクスプローラーの右クリックから「常にこのデバイス上に保持する」を選ぶか、キッティングスクリプトで attrib +p -u <フォルダー> /s /d を実行します(オンライン専用化済みのファイルが混ざっていても確実にピン留めへ切り替えるため、-uも同時に指定します)。ピン留めされたファイルは実体がローカルに保証され、後述の自動オンライン専用化の対象からも外れます。⁷²
• KFMとファイル オンデマンドは「気づいたら有効」ではなく「意図して構成」する。主なポリシー(グループポリシー/Intune)は次のとおりです。¹¹¹

• ストレージセンサーの動きを把握しておく。ストレージセンサー(Storage Sense)には、一定日数開かれていないクラウドファイルを自動でオンライン専用に戻す機能があり、ポリシー(ConfigStorageSenseCloudContentDehydrationThreshold)で日数を構成できます。既定値は0(自動では戻さない)ですが、ユーザーが設定画面から有効化している場合や、容量の小さい端末向けに組織で構成している場合、「先週まで開けたファイルが雲マークに戻っている」が正常動作として起こります。ピン留めされたファイルは対象外なので、ここでも「業務フォルダーはピン留め」が効きます。¹²²
• ファイル オンデマンドの無効化は影響を見積もってから。FilesOnDemandEnabledを無効にすれば従来型の全量ダウンロード同期になりますが、ディスク消費と初回同期の帯域負荷が跳ね上がります。Microsoftは有効のままを推奨しており、無効化は「対象ユーザーのデータ量が小さい」「ディスクに余裕がある」ことを確認した限定的な措置と考えるべきです。¹¹²
• サポート手順に組み込む。「デスクトップのファイルが読めない」という問い合わせテンプレートに、次章の切り分け手順を組み込んでおくと、担当者が変わっても対応品質が揃います。

8. 切り分け手順 ── 「ファイルが読めない」相談を受けたら

相談を受けたときに、上から順に確認します。

応急処置は、対象フォルダーを右クリックして「常にこのデバイス上に保持する」を選ぶ(または attrib +p /s /d)ことです。これで実体がローカルに揃い、業務は再開できます。そのうえで、恒久対処として6章(アプリ側)と7章(情シス側)のどちらに本質的な原因があるかを判断してください。

なお、ここまで確認して「パスはOneDrive配下ではない」「プレースホルダーでもない」なら、共有フォルダーやパス長など別系統の定番原因に進みます。「ネットワークドライブとUNCパスの落とし穴」「MAX_PATHとWindowsのパス・ファイル名の落とし穴」が続きの地図になります。

9. まとめ

• KFMによって、デスクトップ・ドキュメント・ピクチャの実体は C:\Users\<名前>\OneDrive\ 配下へ移動していることがあります。固定パスを前提にしたアプリはここで壊れます。既知フォルダーAPIで解決するのが第一歩です。
• ファイル オンデマンドは既定で有効で、ローカルに実体のないプレースホルダーが普通に存在します。プレースホルダーはCloud Files API(cldflt.sys)のリパースポイントで、開くと自動でハイドレーションされます。
• 状態はファイル属性(OFFLINE / RECALL_ON_DATA_ACCESS / PINNED / UNPINNED)で判定でき、attribではO・P・Uとして見えます。属性の確認だけならダウンロードは発生しません。
• 業務アプリの事故は、オフライン時のハイドレーション失敗、一括処理による全量ダウンロード、属性を想定しないコード、FileSystemWatcherと同期の相互作用、排他ロックと同期の競合、セキュリティ製品によるハイドレーション誘発、という形で現れます。
• アプリ側は「属性で判定して不用意に開かない」「データフォルダーをOneDrive配下に置かない」「エラー時にOneDrive配下であることを伝える」が基本です。
• 情シス側は「業務フォルダーのピン留め」と「KFM・ファイル オンデマンド・ストレージセンサーのポリシー統制」で、意図した状態を作ります。
• 切り分けは、パス→attrib→OneDrive稼働→ネットワーク→空き容量→記録、の順で機械的に進められます。

次に「ファイルはあるのに読めない」という相談を受けたら、最初にこう問い直してください。

そのファイルは、本当にローカルディスクにあるのか。それとも、クラウドの見かけだけがそこにあるのか。

関連記事

• Windows I/Oの深層(第5回) ── NTFSの内部構造:MFTから理解するファイルシステム
• FileSystemWatcher実務ガイド - 取りこぼしと重複対策
• ネットワークドライブとUNCパスの落とし穴 ── 業務アプリでファイルサーバー(共有フォルダ)を扱う実務
• ファイル連携の排他制御の基礎知識 - ファイルロックと原子的 claim のベストプラクティス
• Windowsアプリのデータ保存先の選び方 ── SQLite / JSON / レジストリ / Access 判断表
• MAX_PATHとWindowsのパス・ファイル名の落とし穴 ── 260文字制限、予約名、末尾ドット、大文字小文字

関連する相談領域

合同会社小村ソフトでは、「今まで動いていた取込処理がPC入れ替え後に動かない」「特定のPCでだけファイルが読めない」といったOneDrive・クラウドストレージ絡みの業務アプリの不具合調査、プレースホルダーを前提にしたファイル処理・監視処理の設計と改修、KFM・ファイル オンデマンド環境での保存先設計のレビューを扱っています。現象の切り分けからで構いませんので、お気軽にご相談ください。

• Windowsアプリ開発
• 不具合調査・原因解析
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

デスクトップに置いたCSVを業務アプリが「ファイルが見つかりません」と言って読めません。なぜですか？

多くの場合、デスクトップフォルダー自体がOneDriveの「既知のフォルダーの移動(KFM)」によって C:\Users\<ユーザー名>\OneDrive\デスクトップ 配下に移動しているか、ファイルがオンライン専用のプレースホルダーになっていることが原因です。アプリが C:\Users\<ユーザー名>\Desktop のような固定パスを前提にしていると、移動後のファイルを見つけられません。パスが正しい場合でも、オンライン専用ファイルはOneDrive停止時やネットワーク不調時に開けないことがあります。まず対象パスがOneDrive配下かを確認し、attribコマンドでU(オンライン専用)が付いていないかを見てください。応急処置としては、右クリックの「常にこのデバイス上に保持する」で実体をローカルに確保できます。

プログラムからオンライン専用ファイルかどうかを判定できますか？

できます。オンライン専用のプレースホルダーにはFILE_ATTRIBUTE_OFFLINEやFILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS(0x00400000)などの属性が付くため、ファイル属性を調べれば中身をダウンロードさせずに状態を判定できます。属性の取得やフォルダー列挙だけではハイドレーション(ダウンロード)は発生しません。.NETではFileAttributesに定義がない値もあるので、整数にキャストしてビット演算で判定します。どうしても中身を読まずに開きたい場合は、CreateFileのFILE_FLAG_OPEN_NO_RECALLのような手段もあります。

ファイル オンデマンドを無効にすれば問題は解決しますか？

無効化は最後の手段と考えてください。無効にすると同期対象の全ファイルがローカルにダウンロードされるため、ディスク容量と初回同期のネットワーク負荷が大きくなり、Microsoftも有効のままの運用を推奨しています。実務では、業務アプリが読むフォルダーだけを「常にこのデバイス上に保持する」(ピン留め)にするほうが柔軟です。さらに根本的には、アプリのデータフォルダーや取込用フォルダーをOneDrive管理下に置かない設計に直すのが確実です。

「常にこのデバイス上に保持する」にしたのに、いつの間にか雲マークに戻るファイルがあります。なぜですか？

まず、そのファイルに本当にピン留め(P属性)が付いているかをattribコマンドで確認してください。ピン留めされたファイルはストレージセンサーの自動的なオンライン専用化の対象外ですが、ピン留めせずに開いただけの「ローカルで利用可能」なファイルは、ストレージセンサーの設定やポリシーによって一定期間後にオンライン専用へ戻されることがあります。ほかにも、ユーザー自身の「空き領域を増やす」操作や、チームサイトをオンライン専用化するポリシー(DehydrateSyncedTeamSites)でも雲マークに戻ります。業務上必ずローカルに必要なフォルダーは、フォルダー単位でピン留めして運用してください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。