OneDrive上のファイルが「Office（Word/Excel/PowerPoint）で直接作成されたのか」それとも「ローカルで作って後からアップロードされたのか」をMicrosoft Graph APIのメタデータだけで判別したい――この要望は多い一方で、driveItemには想像以上の制約があります。本記事では、判別が難しい理由と、実務で破綻しない回避策を具体例つきで整理します。
やりたいこと：OneDrive上のファイルの“置かれ方”を区別したい
判別したい経路は大きく次の2つです。
- A：Officeで直接作成して保存（Word/Excel/PowerPoint／Office for the web などで新規作成 → OneDriveへ保存）
- B：ローカル作成→後からアップロード（ブラウザアップロード、同期クライアント、アプリからのアップロード等）
監査・ガバナンス、データ分類、権限設計、社内ルール（「社外共有前に承認が必要」など）の自動化では「AとBで扱いを変えたい」ことがよくあります。ところが、Microsoft Graph APIのdriveItemは“判別の決定打”になりそうな情報が常に返るわけではありません。
結論：Graph APIだけで100%確実な判別はできない
先に結論です。現時点の運用実態として、Microsoft Graph APIの標準メタデータだけで「Officeで作成」か「アップロード」かを100%確実に言い切れる、信頼できるフィールドは存在しません。
createdBy.userは取得できても、createdBy.applicationが返らない／空になるケースがある- ドキュメント上は存在するはずの
driveItemSource.applicationなどが、実際の応答に入ってこないことがある - Graphの各種ファセット（付加情報）は「記録されているときだけ返る」ため、作成時点でアプリ情報が捕捉されていなければAPIからも取れない
つまり「このフィールドを見ればOK」という設計は崩れやすく、要件によっては別の仕組みで補強する必要があります。
まず押さえる：driveItemで見える情報と、見えない情報
Graph APIでOneDriveファイルを扱う中心はdriveItemです。代表的に参照されるフィールドと“作成元判別”への効き具合を整理します。
| フィールド例 | 何が分かるか | A/B判別への有効度 | 注意点 |
|---|---|---|---|
createdDateTime | アイテムがOneDrive上で作成された日時 | 低 | 「いつ置かれたか」であって「どの経路か」は分からない |
createdBy.user | 作成者（ユーザー） | 低 | Office作成でもアップロードでもユーザーは同じになりやすい |
createdBy.application | 作成に関わったアプリ情報 | 中（入っていれば） | 返らない／空になることがあり、判定の前提にしづらい |
lastModifiedBy | 最後に更新した主体 | 低〜中 | 「作成元」ではなく「最後の更新元」。Officeで開いた時点で上書きされる |
fileSystemInfo | ファイルシステム由来の作成/更新時刻 | 低（推定の材料） | アップロード/同期時にローカル時刻が持ち込まれることがあるが一貫しない |
driveItemSource | 由来に関する情報（ドキュメント上の概念） | 中（入っていれば） | 常に入るわけではなく、環境差が大きい |
sharepointIds | SharePoint側の識別子 | 間接的 | 監査ログ突合や外部DBで追跡する際のキーに役立つ |
「アプリ情報が取れるなら勝ち」と考えがちですが、実際には“取れたときだけ参考にする”扱いが安全です。イメージとして、createdByは次のような形で返ってくる可能性があります（概念例）。
{
"createdBy": {
"user": { "displayName": "Taro Yamada" },
"application": { "displayName": "Word" },
"device": { "displayName": "PC-001" }
}
}重要なのは、上のapplicationやdeviceが常に埋まるわけではない点です。欠落していても異常ではない前提で、ロジックと運用を組み立てる必要があります。
なぜ一貫した判別が難しいのか
「Officeで作成したならOfficeのアプリ名が必ず入るのでは？」と期待しがちですが、実務上は次の要因で崩れます。
アプリ経路が多すぎて“作成”の定義が揺れる
- Officeデスクトップアプリで新規作成 → 保存先がOneDrive
- Office for the webで新規作成
- Teamsからファイル作成（実体はSharePoint/OneDrive）
- OneDrive同期クライアントがローカルの新規ファイルを検知してアップロード
- ブラウザでドラッグ&ドロップ
- 社内アプリがGraph経由でアップロード
ユーザーの体感では全部「作った」ですが、システム的には「どこで新規生成されたか」「誰がPUTしたか」「クラウド上でテンプレート生成したのか」などが混在します。結果として、単一メタデータに正規化して残すのが難しくなります。
“記録されていない情報は返らない”という前提
Graphで返る各種ファセットは、常に網羅的に補完されるわけではありません。たとえば作成時点でアプリ情報が捕捉されなかったり、サービス間連携の都合で落ちたりすると、後から復元できません。取得できない＝存在しないではなく、取得できない＝記録されていない／露出しないという解釈が安全です。
同期・アップロードは“見た目がOffice作成に近い”
同期クライアント経由の場合、ユーザーはローカルでWordを開いて保存しただけに見えます。しかしシステム的には「ローカルファイルを同期がアップロードした」挙動になるため、Office由来の情報が残らないことがあります。逆に、アップロード直後にOfficeで開いて保存すると、更新履歴の主体がOfficeっぽく見えてしまうこともあります。
要件を先に決める：100%必要か、推定で良いか
設計が迷走しがちなポイントは「判別精度の要件」を決めないまま実装に入ることです。実務では、次のように要件に応じて戦略を変えるのが現実的です。
| 要件 | おすすめ戦略 | 現実的な精度 | コスト/影響 |
|---|---|---|---|
| 誤判定ゼロが必須（監査・規制対応） | 自前タグ付け＋ログ突合（二重化） | 高（設計次第で限りなく100%に近づける） | 実装・運用コストは高め |
| 運用上、多少の不明/例外は許容 | 監査ログ併用（不足分はUnknown） | 中〜高 | ライセンス/保持期間/検索設計が必要 |
| UX改善のための参考情報が欲しい | Graphメタデータの推定（ヒューリスティック） | 低〜中 | 安いが誤判定を前提にする |
以降では「Graph単体では決定打がない」前提で、現場で採用されやすい回避策を3系統に分けて解説します。
回避策：自前で“経路タグ”を持たせる
判別が業務要件として重要なら、最も堅いのは経路情報を自分たちで記録する設計です。Graphの既存メタデータに期待するのではなく、「このファイルはどの経路で置かれたか」をアップロード時や作成時に書き込みます。
よく使われるタグ付けの実装パターン
| 方法 | 保存場所 | メリット | デメリット/注意点 |
|---|---|---|---|
| Open Extension（拡張属性） | driveItemの拡張 | 実装が比較的簡単。Graphだけで読み書きできる | 設計を誤ると拡張が乱立。検索性に限界がある |
| Schema Extension | 拡張スキーマ | 組織内で統一しやすい。将来の拡張に強い | 定義・運用の設計が必要。利用条件の確認が必要 |
| SharePointのカスタム列 | ドキュメントライブラリ列 | UI（ライブラリ表示/検索/フィルタ）に載せやすい | OneDriveとSharePointの境界、列の適用範囲に注意 |
| 外部DBに保存 | 自社DB | 自由度が高い（端末/アプリ/署名なども保存可） | IDの突合、移動/コピー/削除時の追従が必要 |
「アップロード経路」を確実に記録するコツ
自社アプリやバッチがGraphでアップロードするなら、アップロード直後に次のような情報をセットします。
- route：
upload/sync/appUploadなど - sourceApp：アップロード元アプリ名（自社アプリ名、バージョン）
- ingestedAt：取り込み日時（サーバー時刻）
- traceId：処理ID（障害解析用）
取得はたとえば次のように行います（$selectで必要最小限にすると通信量と権限確認が楽になります）。
GET /me/drive/items/{item-id}?$select=id,name,createdDateTime,createdBy,lastModifiedBy,driveItemSource,fileSystemInfo,sharepointIdsOpen Extensionでタグを付ける概念例：
POST /me/drive/items/{item-id}/extensions
Content-Type: application/json
{
"@odata.type": "microsoft.graph.openTypeExtension",
"extensionName": "com.contoso.origin",
"route": "appUpload",
"sourceApp": "ContosoUploader/1.2.3",
"ingestedAt": "2026-01-06T12:34:56Z",
"traceId": "9f3b..."
}後で読むときは、拡張を展開して取得します（概念例）。
GET /me/drive/items/{item-id}?$expand=extensions($filter=id eq 'com.contoso.origin')この方式の強みは「判別ロジックがメタデータの不安定さに引きずられない」ことです。Graphの返却が揺れても、自前タグがあれば運用で崩れにくくなります。
「Officeで直接作成」をどうやってタグ付けする？
ここが一番難所です。ユーザーがOfficeアプリから通常操作で作ったファイルは、あなたのシステムが作成瞬間に介入できません。そこで、要件に応じて次のいずれかを選びます。
- 割り切り：Office作成はタグが付かない＝
Unknown扱いにし、必要時はログで追う - 導線を寄せる：社内ポータルから「テンプレート作成」させ、テンプレート生成を自社側で行ってタグ付けする
- イベントで補完：作成イベント検知（差分取得やフロー）で、条件に合う場合だけタグを補完する（ただし100%は保証できない）
「タグの空欄＝Office作成」と決め打ちすると、同期や外部アプリ作成が混ざって崩れるため、基本はUnknownを許容する設計が安全です。
回避策：監査ログや別系統のログで補う
「Graphのメタデータに無いなら、別のところに記録されていないか？」という発想です。OneDriveは実体としてSharePoint Online基盤の上にあり、環境によっては監査ログ（操作ログ）に「作成」「アップロード」「同期」などの操作が残ることがあります。
ログ併用が向くケース
- 既存ファイルも含めて“後追い”で分類したい
- 誰が・いつ・何をしたかまで追跡したい（ガバナンス/監査）
- 誤判定の説明責任が必要（「なぜアップロード扱いにしたのか」）
ログ併用の現実的な注意点
ログは万能ではありません。採用前に次を必ず確認します。
- 保持期間：何日分残るか。過去分が必要なら保持の拡張が必要になることがある
- ライセンス/権限：参照できるロール、監査機能の範囲
- 粒度：「作成」と「アップロード」が同じイベントに見える場合がある
- 突合キー：ログ上のURL/パスと、Graphの
driveItemをどう結び付けるか
| 補完ソース | 期待できること | 想定される課題 |
|---|---|---|
| 監査ログ（Microsoft 365/SharePoint/OneDrive） | 操作種別（作成/アップロード/同期 等）、操作者、端末情報が取れる場合がある | 保持期間・検索性・取得APIが環境依存 |
| 同期クライアントのログ（端末側） | 同期経路かどうかの根拠を持てる | 端末回収や集中管理が必要。全端末は現実的でない |
| 自社アプリ/ゲートウェイのログ | アップロード経路なら確実に残せる | Office直作成には介入できない |
ログ併用の実務的な落としどころは、「GraphでUnknownになったものだけログ検索に回す」「分類精度が必要な部署/サイトだけログ突合する」のように、コストをコントロールする設計です。
回避策：Graphメタデータで“推定”する（ただしUnknown前提）
「厳密性は不要だが、できる範囲で自動判定したい」という要件では、Graphメタデータの組み合わせで推定する手があります。ただしこれは確定判定ではなくスコアリングとして扱うのが安全です。
推定に使われがちなシグナル例
| シグナル | 推定の考え方 | ハマりどころ |
|---|---|---|
createdBy.applicationが存在 | Office由来の可能性が上がる | 存在しないケースが多い。無いからアップロードとは言えない |
driveItemSourceが存在 | 由来情報が取れる可能性 | 常に入るわけではない |
fileSystemInfo.createdDateTimeが過去 | ローカル作成→後日アップロードの可能性 | 時刻が引き継がれない／Office直作成でも差が出ることがある |
| 作成直後の更新者がOffice系に見える | Officeで開かれた痕跡 | アップロード後にOfficeで開けば同様になる |
推定ロジックは「3値（A/B/Unknown）」にする
推定で重要なのは、無理にA/Bの二択にしないことです。実務では次の3値が安定します。
- Aっぽい：アプリ情報が明確に取れているなど、根拠が強い
- Bっぽい：ローカル作成時刻の持ち込み等、複数根拠が一致
- Unknown：根拠が弱い/矛盾する/情報が欠落している
Unknownを許容すると、誤判定による業務事故（本来はアップロードなのにOffice作成扱いでフローをスキップ等）を減らせます。
検証のすすめ：社内テナントで“メタデータの癖”を把握する
同じGraph APIでも、テナント設定・利用アプリ・同期の有無で返り方が変わることがあります。実装前に、社内で最低限の再現テストをして「どの経路だと何が取れるか」を把握しておくと、無駄な期待値を下げられます。
| テストシナリオ | 作り方の例 | 確認ポイント | 期待するアウトプット |
|---|---|---|---|
| Office for the webで新規作成 | OneDrive画面から「Word文書」を作成 | createdBy.application / driveItemSource | 取れればA判定の根拠に使える |
| Officeデスクトップで新規作成→OneDrive保存 | Wordで新規作成しOneDriveへ保存 | アプリ情報の有無、fileSystemInfoの差 | 取れない場合はUnknown前提に切り替える |
| ブラウザアップロード | ドラッグ&ドロップでアップロード | fileSystemInfoがローカル時刻を持つか | B推定のスコアリング材料にする |
| 同期クライアント経由 | 同期フォルダにファイル保存 | Office作成との見分けが付くか | 区別困難なら“BかUnknown”として扱う |
テスト結果は、仕様の“正解”を求めるよりも、自社環境で運用に耐える判断基準を作るのが目的です。結果として「A/Bの二択は無理」と分かれば、早期にタグ付けやログ併用へ舵を切れます。
設計例：分類パイプライン（おすすめの落としどころ）
実務で事故が少ないのは、次のような“二段構え”です。
| 段階 | やること | 判定 | 狙い |
|---|---|---|---|
| 一次判定 | 自前タグ（拡張属性/列/DB）を確認 | 確定（自社経路分） | アップロード/アプリ経由は確実に分類 |
| 二次判定 | Graphメタデータでスコアリング | Aっぽい/Bっぽい/Unknown | コストを抑えて参考分類 |
| 最終補完 | 必要なものだけ監査ログで突合 | 確定または根拠付け | 高精度が必要なケースだけ深掘り |
擬似コードにすると、イメージは次のようになります。
if hasCustomTag(item):
return tag.route // 例: appUpload, sync, ...
else if hasStrongOfficeSignal(item):
return "officeLikely"
else if hasStrongUploadSignal(item):
return "uploadLikely"
else:
return "unknown"「unknownを残すのは弱い」と感じるかもしれませんが、実務ではunknownがある方が安全です。unknownを“例外処理の入口”として、監査ログ検索や人手確認へ回せるためです。
実装の実務ポイント：ID設計と突合の考え方
自前タグや外部DB、ログ併用をする場合、どのキーで追跡するかが重要です。OneDrive/SharePointは「リネーム」「移動」「コピー」が頻繁に起こるため、パスやURLだけに依存すると追跡が破綻します。
- 推奨：
driveId + itemId（同一ドライブ内で追跡する） - 併用：
sharepointIds系（ライブラリのアイテム固有IDを使える場合） - 非推奨：パス文字列、表示名、
webUrlのみ（移動・改名で変わる）
また、外部DBで「作成元」を持つなら、次のイベントも設計に入れておくと運用が安定します。
- 移動/改名：同一IDのままか、別IDになりうるかを確認し、追跡ロジックに反映
- コピー：コピー先は“新規作成”として扱うか、元の経路を引き継ぐかを定義
- 削除/復元：復元時にタグや突合がどうなるか
現場で使えるチェックリスト
最後に、設計・実装の抜け漏れを防ぐためのチェックリストです。
| チェック項目 | OKの目安 |
|---|---|
| 判別精度の要件を決めたか | 100%必須／推定でOK／Unknown許容、が明文化されている |
| Graph単体で完結させる前提になっていないか | メタデータ欠落時の扱い（Unknown）が設計されている |
| 自前タグの保存場所を決めたか | Open Extension/列/外部DBのどれかで統一されている |
| 突合キーが安定しているか | driveId+itemId、またはsharepointIds等で追跡できる |
| 移動・コピー・復元の扱いを決めたか | “経路タグ”がどう引き継がれるか運用ルールがある |
| ログ併用の前提（保持/権限/コスト）を確認したか | 保持期間、検索手段、権限が現実的である |
よくある質問
createdBy.applicationが返ってきたら、それだけでOffice作成と断定できますか？
断定はおすすめしません。返ってくること自体は強い手掛かりですが、環境・経路・タイミングで欠落することがあり、逆に「アップロード後にOfficeで編集した」などで見え方が変わる可能性があります。A/B/Unknownの3値にして、根拠の強さで扱いを分けるのが安全です。
driveItemSource.applicationがドキュメントにあるのに取れないのはバグですか？
“取れない＝必ずしもバグ”とは限りません。Graphではファセットが記録されていない場合、プロパティ自体が返らないことがあります。テナント設定、対象がOneDrive/SharePointのどちらか、作成経路などで差が出るため、実装側は「無い前提」で落ちないように作るのが実務的です。
Microsoft側へ改善要望を出す価値はありますか？
あります。現場のニーズとして「作成元アプリの一貫したメタデータ」は強く、同様の要望が集まるほど優先度が上がりやすくなります。社内で再現条件（どの経路で欠落するか）を整理してから、フィードバックやコミュニティで共有すると議論が進みやすくなります。
結局、最も堅い設計はどれですか？
「自社が関与する経路（アップロードやテンプレート生成）では必ずタグ付け」「それ以外はUnknownとして、必要時だけ監査ログで追う」というハイブリッドが、コストと精度のバランスが取りやすいです。特に“誤判定が許されない”業務では、Graph単体に依存しない設計がほぼ必須になります。
まとめ：Graphの“空欄”を前提に、設計で勝つ
Microsoft Graph APIでOneDriveのファイル作成元を判別したい場合、createdBy.applicationやdriveItemSourceのような情報は手掛かりになり得ますが、常に取得できるとは限りません。したがって、確実な判別が必要なら「自前で経路タグを持つ」「監査ログを併用する」「推定はUnknown前提で扱う」という設計に寄せるのが現実解です。メタデータの揺れに振り回されない構成にしておくと、将来の仕様変更や経路追加にも耐えられます。
コメント