合同会社小村ソフト
相談する
メニュー

OLEオブジェクトとは何か ── 埋め込み・リンクの仕組みと業務文書の落とし穴

· 更新日: · · Windows, OLE, COM, Office, Access, Windows開発, レガシー資産

「Wordの仕様書の表をダブルクリックしたら、突然メニューがExcelに変わった」「ファイルサーバーを移設したら、文書に貼ってあった表が更新されなくなった」「Accessのデータベースに画像を入れていったら、ファイルが上限の2GBに突き当たった」── 業務文書とデータベースの困りごとをたどっていくと、かなりの確率で同じ技術に行き着きます。OLEオブジェクトです。

OLEはObject Linking and Embedding(オブジェクトのリンクと埋め込み)の頭字語で、別のアプリケーションが作った文書データを、埋め込みまたはリンクとして入れ物の文書に統合する仕組みです。1 WordにExcelの表を「オブジェクトとして」貼るあの機能の正体であり、1990年代からWindowsの文書文化を支えてきました。今のWindowsでも仕組みごと現役ですが、新しい文書で積極的に使う技術というより、過去に作られた大量の文書・データベースの中で出会う技術になっています。

この記事では、中小企業の情シス担当者と業務アプリ開発者を対象に、OLEオブジェクトの正体(埋め込みとリンク)、文書の中でどう保存され(複合ファイル・構造化ストレージ)、どう動くのか(In-Place Activation)という仕組みから、リンク切れ・ファイル肥大化・セキュリティといった実務の落とし穴、そして今どう付き合うべきかまでを一枚につなぎます。

1. まず結論

  • OLEオブジェクトの正体は、文書に埋め込み(Embed)またはリンク(Link)できるCOMオブジェクトです。COM・構造化ストレージ・統一データ転送というOLEの土台技術の上に成り立っており、IOleObject などの複合ドキュメント固有のインターフェースを公開します。2
  • 埋め込みとリンクの違いは「データ本体をどこに置くか」です。埋め込みは本体を文書内に保存するため自己完結する代わりに文書が大きくなり、元データとの自動同期はありません。リンクは参照だけを持つため文書は小さく元の変更を反映できますが、リンク元が動いて変更後の場所をたどれなくなると切れます。34
  • 埋め込みオブジェクトの保存の器は複合ファイル(構造化ストレージ)です。「1つのファイルの中のファイルシステム」であるIStorage/IStreamの階層に、オブジェクトのデータと(通常は)表示用キャッシュが格納されます。旧Office形式(.doc/.xls)自体がこの複合ファイルで、現行形式でもレガシーなOLE埋め込みのバイナリはこの形式です(新しいOffice文書同士の埋め込みは、ファイルのままZIP内に収まることもあります)。56
  • ダブルクリックの正体は動詞(verb)の実行です。入れ物アプリが IOleObject::DoVerb で主動詞を実行するとOLEがサーバーアプリを起動し、埋め込みなら双方が対応していればIn-Place Activation(メニューの合成)、リンクなら常に別ウィンドウで開きます。78
  • リンクの追跡はモニカ(リンク元の名前と場所)が担います。文書に保存されるのは名前と場所の情報や更新設定と(通常は)表示用キャッシュだけで、データ本体はリンク元に残るため、ファイルサーバーの移設や改名で行き先をたどれなくなるとリンク切れが起きます。94
  • Accessで画像やファイルを格納する用途では、OLEオブジェクト型フィールドは今や非推奨です。添付ファイル型のほうが柔軟で、元ファイルのビットマップ化を行わないぶん記憶域の効率も上です(リンクやアクティブ化などOLE固有の動作が必要な場合は別)。1011
  • OLEは攻撃経路でもあります。細工されたOLEオブジェクトによる任意コード実行の脆弱性は実際の標的型攻撃に使われました。任意のファイルを包めるOLEパッケージはとりわけ危険で、Word・Excel・PowerPointでのアクティブ化をレジストリ設定で禁止する強化策が公的ガイドラインでも推奨されています。1213
  • 新規の設計で埋め込みに頼るのは避け、既存文書は「開ける環境の維持」と「棚卸し」で延命します。OLEオブジェクトを使い続けるかは場面ごとの判断です(9章の判断表)。

この記事の知識マップ

OLEオブジェクトの正体は、文書に埋め込みまたはリンクできるCOMオブジェクトです。埋め込みはデータ本体を文書内に保存するため自己完結する代わりにファイル肥大化の原因になり、リンクは文書側にモニカが持つ「名前と場所」や更新設定と(通常は)表示用キャッシュだけを保存し、データ本体はリンク元に残すため、ファイルサーバーの移設や改名で変更後の場所をたどれなくなるとリンク切れが構造的に起きます。保存の器は「ファイルの中のファイルシステム」である構造化ストレージ(複合ファイル)で、旧Office形式(.doc/.xls)はファイル自体がこの複合ファイルで、現行形式でもレガシーなOLE埋め込みのバイナリはこの形式で格納されます(新しいOffice文書同士の埋め込みは、ファイルのままZIP内に収まることもあります)。ダブルクリックの正体はオブジェクト自身が決める主動詞の実行、In-Place Activationは埋め込みだけの仕組みで、コンテナーとサーバー双方の対応が前提です。編集は作成元アプリ(OLEサーバー)が前提で、無い環境では文書側に表示用キャッシュが保存されていればそれを見るだけになります(キャッシュを持つかどうかは作成時の指定で決まります)。リンク元の変更の反映は、自動更新か手動更新かのリンク更新の設定によります。細工されたOLEオブジェクトは任意コード実行の攻撃経路として実際に使われたため、OLEパッケージのアクティブ化はレジストリ設定で組織的に禁止します。Accessでの画像・ファイルの格納には、OLEオブジェクト型ではなく添付ファイル型が推奨されます。

OLEオブジェクトの知識マップOLEオブジェクトがCOMを前提とし構造化ストレージとIDataObjectと動詞を利用する構造、編集がOLEサーバーを前提としIn-Place Activationがコンテナーとサーバー双方の対応と埋め込みを前提とすること、複合ファイルが構造化ストレージの実装を担い旧Office形式がその複合ファイルを利用すること、埋め込みが肥大化の、リンクがリンク切れの原因になり得ること、埋め込み・リンクが通常は表示用キャッシュを保持すること(有無は作成時の指定による)、リンクが更新設定で構成されること、OLEパッケージのアクティブ化の危険とその防止、Accessでの画像・ファイル格納にはOLEオブジェクト型より添付ファイル型が推奨されることを示す図前提とする利用する利用する利用する実装を担う利用する原因になり得る利用する原因になり得る前提とする利用する用いるのは非推奨推奨される対応原因になり得る防止するで構成できる前提とする実装を担う前提とする前提とする利用する利用するで構成できる利用する利用するOLEオブジェクトCOM(コンポーネントオブジェクトモデル)構造化ストレージIDataObject動詞(verb)複合ファイルCLSID(Class ID)埋め込み(Embedding)ファイル肥大化リンク(Linking)モニカリンク切れIn-Place ActivationMicrosoft WordAccessのOLEオブジェクト型Accessでの画像・ファイル格納Accessの添付ファイル型OLEパッケージのアクティブ化任意コード実行OLEパッケージのアクティブ化防止Microsoft IntuneOLEサーバーOLEコンテナー表示用キャッシュリンク更新の設定旧Office形式(.doc/.xls)OLEパッケージ

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全25件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. OLEオブジェクトの正体 ── 別アプリの文書を丸ごと持ち込む仕組み

ワープロ文書の中に表計算の表を入れ、その表をダブルクリックすると表計算ソフトの編集機能がその場で使える ── OLE複合ドキュメント(compound document)は、この体験を実現するための仕組みです。ユーザーは1つの文書の中で、複数のアプリ由来のデータを操作できます。2

その実体はCOMです。複合ドキュメントのオブジェクトとは、既存の文書に埋め込むかリンクできるCOMオブジェクトであり、IUnknown に加えて IOleObject・IViewObject2 といった複合ドキュメント固有のインターフェースを公開します(リンクオブジェクトはさらに IOleLink を実装します ── 6章)。オブジェクト自身の保存は IPersistStorage で行い、入れ物(コンテナー)が渡す IStorage に自分のデータを書き込みます(IPersistStream を使う実装なら、書き込み先は IStream になります)。つまりOLE複合ドキュメントは、COM・構造化ストレージ・統一データ転送という3つの土台の上に建っています。2

OLE複合ドキュメントの3つの土台OLE複合ドキュメントは、オブジェクトの実体を定めるCOMと、文書内への保存を担う構造化ストレージと、埋め込み・リンク作成の入り口になる統一データ転送という3つの土台技術の上に成り立っているCOM（オブジェクトの実体）OLE複合ドキュメント構造化ストレージ（保存）統一データ転送（作成の入り口）

図1: 複合ドキュメントは単独の技術ではなく、COM・構造化ストレージ・統一データ転送の組み合わせでできている。

オブジェクトの持ち込み方が、名前のとおり2つあります。14

  • 埋め込み(Embedding): オブジェクトのデータ本体を、入れ物の文書の中に丸ごと保存します。文書は元ファイルから独立するので、他のPCへ渡しても参照が切れることはありません(ただし編集には作成元アプリが必要です ── 7章)。編集しても元データには影響しません。その代わり、同じ内容をリンクで持つ場合より文書は一般に大きくなり、元データを変更しても埋め込んだコピーには反映されません。3
  • リンク(Linking): 文書には参照(リンク)や更新設定と(通常は)表示用の情報だけを置き、データ本体はリンク元(多くは別のファイル)に残します。文書は小さく保たれ、リンク元の変更をリンクしているすべての文書に反映できます(すぐ反映されるかは、文書側のリンク更新の設定 ── 自動更新か手動更新か ── によります15)。複数の文書から同じデータを共有したい場合に向きます。4
埋め込みとリンクの違い埋め込みはデータ本体を入れ物の文書の中に丸ごと保存して自己完結する代わりに文書が大きくなり、リンクは文書に参照や更新設定と通常は表示用情報だけを置いてデータ本体はリンク元ファイルに残るため、文書は小さく、リンク更新の設定（自動か手動か）に応じてリンク元の変更を反映できる入れ物の文書（Word文書など）埋め込み：データ本体ごと保存リンク：参照・設定と表示情報（通常）自己完結するが大きくなるリンク元ファイル（本体はここ）元の変更を反映できる（設定次第）

図2: 埋め込みとリンクの違いは「データ本体をどこに置くか」であり、可搬性・サイズ・更新の性質がここから分かれる。

もうひとつ押さえておきたいのは、既存のデータから埋め込み・リンクを作る操作が、コピー&ペーストやドラッグ&ドロップと同じデータ転送(IDataObject)から始まることです(「オブジェクトの挿入」からの新規作成や既存ファイルからの作成は、登録されたクラスやファイルから直接オブジェクトを作る、データ転送を経ない別経路です)。OLEサーバーは自分のデータを IDataObject で提供し、専用のクリップボード形式を通じて「これを埋め込みオブジェクトとして貼れる」「リンクとして貼れる」という選択肢を入れ物側に渡します。「形式を選択して貼り付け」ダイアログに並ぶ「〜 オブジェクト」がまさにそれです。16 クリップボードとドラッグ&ドロップの仕組みそのものは前回の記事で扱ったので、本記事は貼られた後のオブジェクトの側を追いかけます。

3. どこで出会うか ── 文書とデータベースの中に眠っている

OLEオブジェクトは、新しく作るものというより「既存の資産の中で出会うもの」です。代表的な遭遇場所を挙げます。

場所 入り口 中身の例
Word / Excel / PowerPoint 「挿入」→「オブジェクト」、「形式を選択して貼り付け」 Excelワークシート、Word文書、図、数式
Access OLEオブジェクト型フィールド 画像、Excelシート、各種ファイル
リッチテキスト(RTF)文書 ワードパッドなどでの貼り付け 図、他アプリのオブジェクト
古い帳票・仕様書 過去の担当者の運用 「ダブルクリックで開く」前提の埋め込み

Officeの「オブジェクトの挿入」ダイアログでは、新規オブジェクトの作成と既存ファイルからの作成、そして「アイコンで表示」が選べます。「形式を選択して貼り付け」では、データの形式に加えて埋め込みにするかリンクにするかを選べます。この2つのダイアログはOLEの標準ダイアログ(Insert Object / Paste Special)そのもので、MFCにはこれらを表示するためのクラスまで用意されています。1718

OLEオブジェクトに出会う場所WordやExcelのオブジェクトの挿入と形式を選択して貼り付け、AccessのOLEオブジェクト型フィールド、リッチテキスト文書への貼り付けという複数の入り口があり、いずれもオブジェクト形式（埋め込み・リンク）を選んだときに同じOLEオブジェクトを文書やデータベースの中に作るOLEオブジェクト（埋め込み・リンク）オブジェクトの挿入オブジェクト形式で貼り付けAccessのOLE型フィールドRTF文書への貼り付け

図3: 入り口は複数あるが、オブジェクト形式(埋め込み・リンク)を選んで作られるものは同じOLEオブジェクトなので、困りごとの構造も共通する。

Accessは特に重要な遭遇場所です。OLEオブジェクト型は「ExcelスプレッドシートやWord文書、図、音声などのオブジェクトをテーブルに埋め込み・リンクする」ためのフィールド型で、上限は約1GBです。10 社員写真や製品画像をこの型で保存してきたデータベースは今も現場に残っています(そして高確率で肥大化しています ── 7章)。

4. 中を覗く ── 複合ファイルと構造化ストレージ

埋め込まれたオブジェクトは、文書ファイルの中にどう保存されているのでしょうか。答えは構造化ストレージ(Structured Storage)です。

構造化ストレージは、1つのファイルの中に階層構造を作る仕組みで、しばしば「ファイルの中のファイルシステム」と呼ばれます。ディレクトリに相当するストレージ(IStorage)と、ファイルに相当するストリーム(IStream)で構成され、ルートストレージの下にサブストレージやストリームを入れ子にできます。5 COMはこの仕組みの標準実装として複合ファイル(Compound Files)を提供しており、複合ファイルはFATでもNTFSでも同じように開ける、ファイルシステムに依存しない単一ファイル形式です。ファイル形式そのものは [MS-CFB](複合ファイルバイナリ形式)として公開仕様になっており、ストレージやストリームを列挙するディレクトリエントリには、格納物の作成元を識別するCLSIDを持たせられます。619

この構造が、複合ドキュメントの器としてそのまま働きます。入れ物の文書がオブジェクトごとにサブストレージを用意し、IPersistStorage で永続化するオブジェクトはそこに自分のデータを書き込む(2章で触れた IPersistStream で永続化するオブジェクトは、ストレージではなくストリームに書き込みます)。ストレージにCLSIDが入っていれば、それを見るだけで「このオブジェクトはどのアプリで開くべきか」が分かる ── ダブルクリックで正しいアプリが起動するのは、この仕掛けのおかげです。2

複合ファイルの内部構造複合ファイルはルートストレージの下にディレクトリ相当のストレージとファイル相当のストリームの階層を持ち、IPersistStorageで永続化する埋め込みオブジェクトはサブストレージに、IPersistStreamで永続化するオブジェクトはストリームに保存され、埋め込みオブジェクトのストレージには作成元アプリを識別するCLSIDを持たせられ（空のこともある）、表示用キャッシュのストリームは通常保存されるが作成時の指定によっては持たないこともあり、1つのファイルの中のファイルシステムとして働くルートストレージ（文書本体）ストリーム：本文データストレージ：埋め込み（IPersistStorage）ストリーム：オブジェクトのデータストリーム：表示用キャッシュ（通常）CLSIDで作成元を示せる（任意）ストリーム：IPersistStream永続化

図4: IPersistStorageで永続化する埋め込みオブジェクトは文書内のサブストレージに保存され(IPersistStream永続化ならストリームに)、CLSIDを持たせれば「どのアプリで開くか」を伝えられる。

身近な事実をひとつ。旧Office形式の .doc / .xls は、それ自体が複合ファイルです。Word文書の実体が複合ファイルのストリームとして格納され、埋め込みオブジェクトはサブストレージに収まる ── OLEの保存基盤とOfficeのファイル形式は、長らく同じものでした。現行の .docx / .xlsx はZIPベースのOpen XML形式に変わりましたが、レガシーなOLEオブジェクトを埋め込むと、そのバイナリ(oleObject*.bin)は今も複合ファイル形式で格納されます(新しいOffice文書同士の埋め込みは、.xlsx などのファイルがそのままZIP内に格納されることもあります)。複合ファイルは「過去の形式」ではなく、文書の中に入れ子で生き続けています。19

旧Office形式と現行形式でのOLEオブジェクトの器旧Office形式の.docや.xlsはファイル自体が複合ファイルで埋め込みオブジェクトはそのサブストレージに収まり、現行の.docxや.xlsxはZIPベースのOpen XMLだが、レガシーなOLE埋め込みのバイナリは今も複合ファイル形式で格納される（新しいOffice文書同士の埋め込みはファイルのままの格納もある）.doc／.xls（旧形式）ファイル自体が複合ファイル.docx／.xlsx（現行）ZIPベースのOpen XMLレガシーOLEの.binは複合ファイル新Office埋め込みはファイルのまま

図5: ファイル形式が世代交代しても、OLEオブジェクトの器としての複合ファイルは入れ子で残っている。

5. 動く仕組み ── 動詞(verb)とIn-Place Activation

埋め込みオブジェクトのダブルクリックで何が起きるのかを追いかけます。

OLEオブジェクトは、自分に対して実行できる操作を動詞(verb)として定義しています。「編集」「開く」、音声なら「再生」といった具合です。入れ物アプリはユーザーの操作(典型的にはダブルクリック)を受けて IOleObject::DoVerb を呼びます。このとき主動詞(OLEIVERB_PRIMARY)を選ぶのはオブジェクトの側で、表なら編集、音声なら再生と、オブジェクトの性質に応じた既定動作が実行されます。DoVerb はOLEサーバーアプリを自動的に起動します。7

オブジェクトと入れ物の双方がIn-Place Activation(インプレース アクティブ化)に対応していれば、編集は入れ物のウィンドウの中で始まります。このとき入れ物アプリのメニューバーは、入れ物とサーバー両方のメニューを合成した複合メニューバーに置き換わります。Wordの中でExcelのリボンが現れる、あの挙動です。オブジェクトの外側をクリックすると非アクティブ化され、元のメニューに戻ります。8

ダブルクリックからIn-Place Activationまで入れ物アプリはダブルクリックを受けてIOleObjectのDoVerbで主動詞を実行するとOLEがサーバーアプリを起動し、入れ物とサーバーの双方がIn-Place Activationに対応している場合、埋め込みオブジェクトは入れ物のウィンドウの中でメニューを合成して編集され、外側のクリックで非アクティブ化されて元のメニューに戻る（対応していない場合は別ウィンドウでの編集になる）OLE・サーバーアプリ入れ物アプリ（Wordなど）利用者OLE・サーバーアプリ入れ物アプリ（Wordなど）利用者alt[双方がIn-Place Activationに対応][どちらかが非対応]埋め込みオブジェクトをダブルクリックDoVerbで主動詞を実行サーバー起動・メニューを合成その場で編集オブジェクトの外側をクリック非アクティブ化・元のメニューへ別ウィンドウで編集

図6: ダブルクリックの正体はDoVerbによる主動詞の実行で、In-Place Activationではメニューが合成される。

知っておくと切り分けに効く仕様が2つあります。第一に、In-Place Activationは埋め込みオブジェクトを前提とした仕組みであり、リンクオブジェクトは常に別ウィンドウで開きます。データ本体が別の文書にある以上、入れ物の文脈の中で編集させるわけにはいかないからです。18 第二に、In-Place Activationの実装はコンテナー・サーバーの双方にとって任意であり、OLEIVERB_OPEN を使えば埋め込みオブジェクトでも別ウィンドウ編集になります。「同じ文書なのに開き方が違う」ように見えるとき、それは壊れているのではなく、オブジェクトの種類と動詞の違いであることがほとんどです。7

オブジェクトの種類と動詞で決まる開き方埋め込みオブジェクトの主動詞は、入れ物とサーバーの双方がIn-Place Activationに対応していれば入れ物の中での編集になり、どちらかが対応していなければ別ウィンドウになり、OLEIVERB_OPENは常に別ウィンドウで、データ本体が別文書にあるリンクオブジェクトも常に別ウィンドウで開かれる埋め込みリンク主動詞OPENオブジェクトの種類は？どの動詞？常に別ウィンドウ対応時はその場で編集別ウィンドウで編集非対応なら別ウィンドウ

図7: 開き方は「オブジェクトの種類×動詞×その場対応の有無」でほぼ決まり、別ウィンドウで開いても壊れているわけではない。

6. リンクの仕組みとリンク切れ ── モニカが持つ「名前と場所」

リンクオブジェクトの中核はモニカ(moniker)です。モニカはCOMでオブジェクトの所在を名前として表し、必要になったときに解決(バインド)するための部品で、リンクオブジェクトはこれを使ってリンク元の命名・追跡・起動を管理します。リンクだけが実装する IOleLink インターフェースがこの機能を入れ物に提供しており、入れ物は IOleLink の有無で「このオブジェクトは埋め込みかリンクか」を判別できます。9

重要なのは保存のされ方です。リンクを含む文書を保存しても、リンクのデータはリンク元に保存され、文書側に残るのはリンク元の名前と場所の情報・更新設定などのリンク自身の管理情報と、(通常は)表示用のキャッシュだけです。9 つまり文書は「どこの何を表示するか」というメモとリンクの管理情報、そして最後に見たときの表示用キャッシュしか持っていません(正確には、表示用キャッシュを保存するかどうかも作成時の指定で決まり、キャッシュを持たないオブジェクトも作れます20)。

ここから、業務でおなじみのトラブルが構造的に導けます。リンク切れです。ファイルサーバーの移設、フォルダーの改名、共有パスの変更、リンク元ファイルの削除 ── 名前と場所を頼りにする以上、変更後の場所をたどれなくなった時点で解決は失敗します。文書には古い表示キャッシュ(保存されていれば)だけが残り、「表は見えるのに更新されない」「ダブルクリックするとエラーになる」という症状になります。

リンクの解決とリンク切れリンクオブジェクトはモニカが持つリンク元の名前と場所を頼りにファイルを解決して表示と更新を行うが、ファイルサーバーの移設や改名で変更後の場所をたどれなくなると解決に失敗し、文書には古い表示用キャッシュ（保存されていれば）だけが残るリンク切れになるリンクオブジェクトモニカ（名前と場所）解決成功：表示・更新できる解決失敗：リンク切れ移設・改名でたどれない古い表示キャッシュが残る（あれば）

図8: リンクオブジェクトが文書側に持つのは「名前と場所」や更新設定と(通常は)表示用キャッシュだけなので、行き先をたどれなくなればリンク切れは構造的に起きる。

対処は地味です。文書ごとに「リンクの編集」でリンク元パスを付け替えるのが正攻法で、リンクを多用した文書群を抱えているなら、ファイルサーバー移設の計画にはリンクを含む文書の棚卸しと更新を含めるべきです。移設後に気づくと、退職者の作った文書のリンク元を推理する仕事が発生します。

ファイルサーバー移設とリンクの棚卸しリンクを多用した文書群では、移設の前にリンクを含む文書を棚卸しし、移設を実施したあとにリンクの編集でリンク元パスを新しい場所へ付け替えるところまでを移設計画に含めることで、リンク切れの混乱を防ぐ移設計画リンクを含む文書の棚卸し移設の実施リンクの編集でパスを付け替えリンク切れの混乱を防ぐ

図9: リンクの修復は文書単位の地道な作業だからこそ、棚卸しと更新は移設計画の側に組み込む。

7. 業務での落とし穴 ── 肥大化・開けない・Accessの画像

落とし穴1: ファイルの肥大化。埋め込みはデータ本体の複製を文書内に持つため、同じオブジェクトをリンクで持つ文書より一般に大きくなります。3 「Excelの表を数十個埋め込んだ報告書が開くのに数十秒かかる」といった相談の原因は、たいていこれです。再編集が不要な表は図として貼る、元ファイルを共有してリンクや図だけを置く、といった運用で回避できます。

埋め込みによる肥大化への対処埋め込みはデータ本体の複製を文書内に持つため文書が大きくなるので、再編集が不要な表は図として貼り、元ファイルを共有して文書にはリンクや図だけを置くことで、本体を文書の中に持たない方向へ寄せて肥大化を回避する埋め込みで肥大化した文書再編集不要なら図として貼る元ファイル共有＋リンクや図だけ本体を文書内に持たない

図10: 肥大化への対処は「データ本体を文書の中に持たない」方向へ寄せるのが基本。

落とし穴2: Accessの画像格納。AccessのOLEオブジェクト型フィールドに画像を入れる設計は、肥大化がとりわけ顕著です。Microsoft自身が、添付ファイル型はOLEオブジェクト型より柔軟で、元ファイルのビットマップ画像を作らないため記憶域の使用効率も高いと明言しています。10 添付ファイル型は .accdb 形式で使え、データベース全体で最大2GB(1ファイルは最大256MB)、画像形式は追加ソフトなしで表示できます。11 逆に言えば、OLEオブジェクト型で画像を保存する新規設計を選ぶ理由はもうありません。既存DBがこの型を使っているなら、添付ファイル型への移行、またはファイルはフォルダーに置いてDBにはパスだけを持たせる設計への移行を検討してください。

AccessのOLEオブジェクト型フィールドの移行判断AccessのOLEオブジェクト型フィールドを見つけたら、リンクやアクティブ化などOLE固有の動作が必要なら現状維持を検討し、画像やファイルを格納しているだけなら添付ファイル型への移行か、ファイルはフォルダーに置いてDBにはパスだけを持たせる設計への移行を選ぶ必要格納しているだけOLEオブジェクト型フィールドOLE固有の動作が必要？現状維持を検討（リンク・アクティブ化）移行する添付ファイル型フォルダー＋パス管理

図11: AccessのOLEオブジェクト型は「OLE固有の動作が必要か」で移行判断が決まり、格納だけなら添付ファイル型かパス管理へ寄せる。

落とし穴3: 「開けない」。埋め込みオブジェクトの編集には作成元アプリ(OLEサーバー)が必要です。アプリのないPCでは保存されている表示用キャッシュを眺めることしかできず(キャッシュされた表示データは、サーバーアプリが利用できなくてもコンテナーから利用できるように設計されています21)、「アイコンで表示」で貼られていた場合は中身を見ることすらできません。なお、表示用キャッシュを持つかどうか自体はオブジェクト作成時の指定(OLERENDER)で決まるため、キャッシュ無しで作られたオブジェクトでは最後の見た目も残りません。20作成元アプリはあるのに開けない場合は、バージョン違いによる「変換」が必要なケース(OLEには変換用の標準ダイアログもあります)、アプリの再インストール等で直るCOMクラス登録(CLSID)の欠落・破損、文書の破損、セキュリティ設定によるブロック(8章)を順に疑います。17

埋め込みオブジェクトが開けないときの分岐ダブルクリックで開けない場合はまず作成元アプリの有無を確認し、なければキャッシュがあればその表示のみ（キャッシュ無しのオブジェクトは表示も不可）と割り切るか導入し、あればバージョンの互換を確認して変換を試し、次に再インストール等で直るCOMクラス登録の欠落・破損を確認し、それでも開けなければセキュリティによるブロックや文書の破損を疑う順で切り分けるないあるいいえはいいいえはい作成元アプリがある？キャッシュがあればその表示のみ・アイコンは開けないバージョンは互換？変換または元アプリを用意COM登録は正常？再インストール等で登録を修復ブロック設定・破損を疑う

図12: 「開けない」の切り分けは、作成元アプリ→バージョン互換→COM登録→ブロック・破損の順で機械的に進められる。

落とし穴4: 「開ける環境」が失われていく。埋め込みの自己完結性は「作成元アプリがどこにでもある」ことを暗黙の前提にしています。アプリの世代交代やOSの変化でこの前提は静かに崩れていきます。埋め込み前提の帳票・仕様書を長期保存するなら、重要文書はPDF化した版を併存させる、開ける環境を仮想マシンで維持する、といった手当てが必要です。

8. セキュリティ ── OLEは攻撃経路でもある

「文書の中に別アプリのオブジェクトを持ち込み、開いた側のPCで実行する」というOLEの構造は、攻撃者から見ても便利な運搬手段です。これは理論上の話ではありません。細工されたOLEオブジェクトを含む文書(PowerPointファイルなど)を開かせて任意のコードを実行させる脆弱性(CVE-2014-4114)は、実際の標的型攻撃に使われました。OLEオブジェクトを格納できるOffice文書形式なら種類を問わずこの経路になり得るため、「開くだけのつもりの文書」が実行の入り口になります。12

とりわけ危険なのがOLEパッケージ(Object Packager)です。これは任意のファイルをOLEオブジェクトとして文書に包み込める古い仕組みで、実行ファイルさえ包めるため、古くから脆弱性と悪用の温床になってきました。22 このため現在では、Word・Excel・PowerPointでOLEパッケージのアクティブ化をレジストリ設定で禁止することが標準的な強化策になっています。オーストラリア政府のEssential Eightに対応したMicrosoftのガイドは、この設定を投入するスクリプトをIntuneで組織に配布する手順を示しています。13

OLEパッケージ経由の攻撃と防御細工された文書に含まれる実行ファイル入りのOLEパッケージを利用者がアクティブ化すると任意のコード実行につながり得るため、OfficeでのOLEパッケージのアクティブ化をレジストリ設定で禁止し、Intuneなどで組織に配布して防ぐ防止細工された文書OLEパッケージ（実行ファイル入り）アクティブ化（起動）任意のコード実行アクティブ化防止の設定Intuneなどで組織に配布

図13: OLEパッケージは「文書に実行ファイルを同梱できる」仕組みなので、アクティブ化の禁止を組織設定で配る。

情シスの実務としては、次の整理が現実的です。

  • 出所不明の文書のオブジェクトは開かない・開かせない。埋め込みオブジェクトのアクティブ化は「ファイルを開く」のと同じ重みの操作として扱います。
  • OLEパッケージのアクティブ化は組織的にブロックする。通常業務でOLEパッケージが必要な場面はまずありません。13
  • 社内文書の通常の埋め込み・リンクまで一律禁止はしない。リスクの中心はパッケージと細工された文書であり、Excel表の埋め込みを禁止しても得られるものは少なく、業務が止まります。

9. 今どう付き合うか ── 場面別の判断表

ここまでの内容を、場面別の判断に落とします。

場面 推奨 理由
新規の文書運用を設計する 埋め込みに頼らない(図として貼る・元ファイルを共有しリンクは最小限に) 肥大化と「開ける環境」問題を新たに作らない
新規の業務アプリで文書に他アプリのデータを入れたい OLEコンテナー実装ではなく、画像化・PDF化・ファイル添付で設計 OLEコンテナーの実装・保守コストに見合う場面が今はほぼない
既存の埋め込み文書資産 開ける環境を維持しつつ、重要文書はPDF版を併存 自己完結性の前提(作成元アプリ)が崩れていくため
既存のリンク多用文書+サーバー移設 移設計画にリンク棚卸しと更新を組み込む リンク切れは構造的に起きる(6章)
AccessのOLEオブジェクト型(画像・ファイル) 添付ファイル型またはパス管理へ移行 公式に添付ファイル型が柔軟・効率的とされている10
Office環境のセキュリティ OLEパッケージのアクティブ化を組織的に禁止 公的ガイドライン準拠の標準的強化策13

OLEの仕組みそのものは、Windowsが後方互換を守り続けている限り動き続けます。ただし個々のオブジェクトを開けるかどうかは、作成元アプリが残っているかに依存します(7章)。その前提を確保できている限り、慌てて全廃する必要はありません。必要なのは、新しい依存を増やさないことと、すでにある依存の在り処を把握しておくことです。どのファイルサーバーにリンク元があり、どの文書に埋め込みがあり、どのDBがOLEオブジェクト型を使っているか ── この棚卸しができていれば、移設もセキュリティ強化も移行も、計画の中で淡々と進められます。

OLE依存の棚卸しの3つの観点OLEオブジェクトとの付き合い方を計画に落とすには、どのファイルサーバーにリンク元があるか、どの文書に埋め込みがあるか、どのデータベースがOLEオブジェクト型を使っているかという3つの依存の在り処を先に把握しておく必要があるOLE依存の棚卸しリンク元のあるサーバー埋め込みを含む文書OLE型を使うデータベース移設・強化・移行を計画に落とせる

図14: 判断の前提は依存の在り処の把握であり、この棚卸しができていれば移設も強化も移行も計画に落とせる。

10. まとめ

  • OLEオブジェクトは、文書に埋め込みまたはリンクできるCOMオブジェクト。COM・構造化ストレージ・統一データ転送の上に建つ複合ドキュメント技術で、「WordにExcelの表」の正体。
  • 埋め込みは本体を文書内に保存(自己完結・肥大化・同期なし)、リンクは参照・更新設定と(通常は)表示用キャッシュだけ(小さい・反映される・切れる)。違いは「データ本体をどこに置くか」に尽きる。
  • 保存の器は複合ファイル(IStorage/IStream の「ファイルの中のファイルシステム」)。旧Office形式はそれ自体が複合ファイルで、CLSIDを持たせてあれば作成元アプリが分かる(新しいOffice文書同士の埋め込みは、ファイルのままZIP内に収まることもある)。
  • ダブルクリックの正体は DoVerb による主動詞の実行。埋め込みは双方が対応していればIn-Place Activation(メニュー合成)、リンクは常に別ウィンドウ。
  • リンクの実体はモニカが持つ「名前と場所」。だからファイルサーバー移設で行き先をたどれなくなればリンク切れは構造的に起きる。移設計画に棚卸しを。
  • AccessのOLEオブジェクト型は非推奨の選択肢。画像・ファイルは添付ファイル型かパス管理へ。
  • OLEは攻撃経路でもある。OLEパッケージのアクティブ化は組織的に禁止し、出所不明の文書のオブジェクトは開かない。

COMの記事、クリップボードとドラッグ&ドロップの記事、そして本記事で、OLEという言葉の主要な顔(コンポーネント基盤・データ転送・複合ドキュメント)が一通りつながりました。古い技術ですが、業務の現場ではまだ長い付き合いになります。仕組みを知っていれば、トラブルの多くは「構造的にそうなる」と説明がつき、対処も計画に落とせるはずです。

関連記事

関連する相談領域

合同会社小村ソフトでは、OLE・COMが絡むレガシー文書・データベース資産の調査と移行(AccessのOLEオブジェクト型からの脱却、埋め込み文書の棚卸しとPDF化、リンク切れの一括対処)、COMコンポーネントを含む業務アプリの保守・改修、Office連携アプリの設計を扱っています。「この文書、ダブルクリックすると何が起きているのか分からない」という段階からでもご相談いただけます。

参考リンク

  1. Microsoft Learn, OLE Background. OLEがObject Linking and Embeddingの頭字語に由来すること、OLE文書(複合ドキュメント)が複数アプリ由来のデータを統合すること、コンテナーとサーバーの役割分担、In-Place Activation(ビジュアル編集)の概要と、リンクアイテムがIn-Place Activationされないことについて。 ↩ ↩2

  2. Microsoft Learn, Compound Documents. OLE複合ドキュメントがCOM・構造化ストレージ・統一データ転送の上に成り立つこと、複合ドキュメントオブジェクトが文書に埋め込みまたはリンクできるCOMオブジェクトでありIOleObject・IOleLink・IViewObject2などの固有インターフェースを公開すること、オブジェクトがIPersistStorage/IPersistStreamで自身の保存を管理しコンテナーがIStorageを供給することについて。 ↩ ↩2 ↩3 ↩4

  3. Microsoft Learn, Embedded Objects (COM). 埋め込みオブジェクトが管理情報ごと複合ドキュメント内に物理的に保存されること、リンクで持つ場合より文書が大きくなること、ソースの変更が埋め込みコピーに反映されないこと、他のPCへ渡してもリンクが壊れない可搬性とIn-Place Activationという利点について。 ↩ ↩2 ↩3

  4. Microsoft Learn, Linked Objects. リンクオブジェクトではソースデータがリンク元に残り文書には参照と表示用情報だけが保存されること、文書サイズが小さく保たれること、リンク元の変更がリンクを含むすべての文書に反映されること、リンクのアクティブ化がサーバーアプリを起動することについて。 ↩ ↩2 ↩3

  5. Microsoft Learn, IStorage interface (objidl.h). 構造化ストレージが1つのファイル内での階層的な情報格納を可能にし「ファイルの中のファイルシステム」と呼ばれること、ストレージがディレクトリに、ストリームがファイルに相当すること、ルートストレージの下にサブストレージとストリームを入れ子にできることについて。 ↩ ↩2

  6. Microsoft Learn, Compound Files. 複合ファイルがCOMの提供する構造化ストレージの標準実装であること、既存のフラットなファイルシステムの上で動作しFAT・NTFS・Macのファイルシステム間で相互に開けるファイルシステム非依存の形式であること、標準インターフェースにより内部のオブジェクトを列挙・参照できることについて。 ↩ ↩2

  7. Microsoft Learn, IOleObject::DoVerb method (oleidl.h). 動詞(verb)がオブジェクトの定義するアクションであること、ダブルクリック時の動作を決めるOLEIVERB_PRIMARYはコンテナーではなくオブジェクトが決めること、DoVerbがOLEサーバーアプリを自動的に起動すること、OLEIVERB_OPENが埋め込みオブジェクトを別ウィンドウで開かせることについて。 ↩ ↩2 ↩3

  8. Microsoft Learn, Implementing In-Place Activation. In-Place Activationにより埋め込みオブジェクトをコンテナー文書を離れずに操作できること、アクティブ化時にコンテナーとサーバー双方のメニューを合成した複合メニューバーに置き換わり非アクティブ化で元に戻ること、実装がコンテナー・サーバー双方にとって任意であること、リンクオブジェクトが常に別ウィンドウで開くことについて。 ↩ ↩2 ↩3

  9. Microsoft Learn, Linked Objects and Monikers. リンクオブジェクトがモニカによるソースの命名と、ソースを見つけて起動するバインドを担うこと、IOleLinkがリンクであることの識別とリンク元の管理機能を提供すること、リンクを含む文書の保存時にデータはリンク元に保存され文書側には名前と場所の情報だけが保存されることについて。 ↩ ↩2 ↩3

  10. Microsoft Learn, DataType property (Access). AccessのOLEオブジェクト型がExcelスプレッドシート・Word文書・図・音声などのオブジェクトをテーブルに埋め込み・リンクするための型で上限が約1GBであること、添付ファイル型がOLEオブジェクト型より柔軟であり元ファイルのビットマップ画像を作成しないため記憶域をより効率的に使うことについて。 ↩ ↩2 ↩3 ↩4

  11. Microsoft Learn, Attachment object (Access). 添付ファイル型が.accdb形式のデータベースで使えること、添付できるデータの上限がデータベース最大サイズの2GBで個々のファイルは256MBまでであること、BMP・PNG・JPEGなどの画像形式を追加ソフトなしで表示できることについて。 ↩ ↩2

  12. Microsoft Learn, Microsoft Security Bulletin MS14-060 (CVE-2014-4114). OLEが複合データの作成・編集を可能にする技術であること、細工されたOLEオブジェクトを含むファイルを開かせることで現在のユーザーの権限で任意のコードを実行できる脆弱性、OLEオブジェクトを格納できるOffice形式ほか多くのファイル形式が悪意あるOLEオブジェクトを含み得ること、本脆弱性を突く限定的な標的型攻撃が確認されていたことについて。 ↩ ↩2

  13. Microsoft Learn, Essential Eight user application hardening. オーストラリア政府のEssential Eightに対応した強化ガイドとして、Excel・PowerPoint・WordでのOLEパッケージのアクティブ化をブロックするレジストリキーを投入するPowerShellスクリプトをIntuneで配布する手順が示されていることについて。 ↩ ↩2 ↩3 ↩4

  14. Microsoft Learn, Linking and Embedding. 複合ドキュメントのオブジェクトにリンクと埋め込みの2種類があり、ソースデータの保存場所の違いが可搬性・アクティブ化・更新・サイズに影響することについて。 ↩

  15. Microsoft Learn, OLEUPDATE enumeration (oleidl.h). リンクオブジェクトのキャッシュ更新に自動(OLEUPDATE_ALWAYS)と手動(OLEUPDATE_ONCALL)があり、それぞれリンクダイアログの自動更新・手動更新の選択肢に対応すること、手動ではIOleObject::UpdateまたはIOleLink::Updateの呼び出し時にだけ更新されることについて。 ↩

  16. Microsoft Learn, Creating Linked and Embedded Objects from Existing Data. 埋め込み・リンクオブジェクトの作成がクリップボードやドラッグ&ドロップによるIDataObjectのデータ転送から始まること、OLEサーバーが埋め込み・リンク作成用の専用クリップボード形式を忠実度順に提供すること、「形式を選択して貼り付け」相当のコマンドで埋め込み・リンクを選べることについて。 ↩

  17. Microsoft Learn, Dialog boxes in OLE. OLEの標準ダイアログとしてのInsert Object(新規・既存ファイルからのオブジェクト挿入とアイコン表示)、Paste Special(形式の選択と埋め込み/リンク/アイコン表示の選択)、Change Icon、Convert(埋め込み・リンクアイテムの種類の変換)の役割について。 ↩ ↩2

  18. Microsoft Learn, Selection.PasteSpecial method (Word). Wordの形式を選択して貼り付けに相当するVBAメソッドで、貼り付け形式の指定に加えLink引数によるリンク貼り付けとDisplayAsIcon引数によるアイコン表示を制御できることについて。 ↩

  19. Microsoft Learn, [MS-CFB]: Compound File Binary File Format. 複合ファイルバイナリ形式の公開仕様。1つのファイル内にアプリケーション固有のデータストリームを格納するファイルシステム的構造の定義、ストレージ・ストリームを列挙するディレクトリエントリとそのCLSIDフィールドについて。 ↩ ↩2

  20. Microsoft Learn, OLERENDER enumeration (oleidl.h). 埋め込み・リンクの作成時に要求するローカルキャッシュの種類を示す列挙型であり、OLERENDER_NONEを指定するとローカルにキャッシュされる描画・データ取得の能力を要求しない(表示用キャッシュを持たない)ことについて。 ↩ ↩2

  21. Microsoft Learn, IOleCache interface (oleidl.h). オブジェクト内にキャッシュされる表示用データの制御を提供するインターフェースであること、キャッシュされた表示データはサーバーアプリケーションが起動していない・利用できない場合でもオブジェクトのコンテナーから利用できることについて。 ↩

  22. Microsoft Learn, Microsoft Security Bulletin MS12-002. Windows Object Packagerがファイルへ挿入できるパッケージを作成するツールであること、その不適切な登録・実装に起因するリモートコード実行の脆弱性(CVE-2012-0009)と回避策について。 ↩

関連する記事

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

関連トピック

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

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

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

よくある質問

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

埋め込みとリンクは何が違うのですか？
データ本体をどこに置くかが違います。埋め込み(Embedding)は、オブジェクトのデータ本体を入れ物の文書の中に丸ごと保存します。文書が元ファイルから独立するので、他のPCに渡しても参照が切れることはありません(ただし編集には渡した先のPCにも作成元アプリが必要です。無い場合は表示用キャッシュが保存されていればそれを見るだけになり、アイコン表示のオブジェクトは中身を確認できません)。その代わりファイルは大きくなり、元データを変更しても文書側には反映されません。リンク(Linking)は、文書には参照(リンク元の名前と場所)や更新設定と表示用の情報だけを置き、データ本体はリンク元ファイルに残します。文書は小さく、リンク元の変更を文書に反映できますが(自動か手動かはリンクの更新設定によります)、リンク元が移動・改名されて行き先をたどれなくなるとリンク切れになります。どちらで貼るかは「形式を選択して貼り付け」や「オブジェクトの挿入」ダイアログで選べます。
文書内の埋め込みオブジェクトをダブルクリックしても開けない・編集できないのはなぜですか？
いちばん多い原因は、そのオブジェクトの作成元アプリが今のPCに入っていないことです。埋め込みオブジェクトの編集は作成元アプリ(OLEサーバー)を起動して行うため、アプリがなければ表示用キャッシュが保存されている場合にそれを表示することしかできず、アイコン表示の場合は中身を見ることもできません。作成元アプリがあるのに開けない場合は、バージョンの違いにより「変換」が必要なケース、再インストール等で直るCOMクラス登録(CLSID)の欠落・破損、文書側の破損、セキュリティ設定によりアクティブ化がブロックされているケースを順に疑ってください。
WordやExcelのファイルが埋め込みオブジェクトで異様に大きくなるのはなぜですか？
埋め込みはデータ本体を文書の中に複製して保存する方式だからです。同じオブジェクトをリンクで持つ文書に比べて、埋め込みを持つ文書は一般に大きくなります。さらに文書には通常、編集用のデータ本体に加えて表示用のキャッシュも保存されます(キャッシュを持つかどうかは作成時の指定で決まります)。ファイルを小さくしたい場合は、埋め込みではなくリンクにする、図として貼り付ける(再編集は不要と割り切る)、元ファイルを別途共有して文書にはリンクや図だけを置く、といった選択肢があります。ただしリンクはリンク元の管理が必要になるため、配布する文書には向きません。
ファイルサーバーを移設したら文書内のリンクオブジェクトが更新されなくなりました。なぜですか？
リンクオブジェクトが文書内に持っているのは、データ本体ではなく、リンク元の名前と場所の情報(モニカ)や更新設定と表示用のキャッシュだけだからです。ファイルサーバーの移設・フォルダーの改名・共有パスの変更などでリンク元の場所が変わり、変更後の場所をたどれなくなると、リンクの解決に失敗し、文書には古い表示用キャッシュだけが残ります(キャッシュを保存しない指定で作られたオブジェクトでは、その表示も残りません)。修復するには、各文書の「リンクの編集」からリンク元のパスを新しい場所に付け替える必要があります。なお、パスは正しいのに反映されない場合は、リンク切れではなく、リンクが手動更新に設定されているだけのこともあるので、更新方法の設定もあわせて確認してください。文書が大量にある場合は移設前にリンクを含む文書を棚卸しし、可能であればリンクの一括更新を計画に組み込んでください。
OLEオブジェクトはセキュリティ上危険だと聞きました。使い続けてよいのでしょうか？
「文書の中に別アプリのオブジェクトを持ち込み、開いた側で実行する」というOLEの構造は、攻撃者にとっても便利な運搬手段であり、細工されたOLEオブジェクトによる任意コード実行の脆弱性が実際の標的型攻撃に使われてきました。特に任意のファイルを包めるOLEパッケージは危険で、オーストラリア政府のEssential Eightのような公的ガイドラインは、Word・Excel・PowerPointでのOLEパッケージのアクティブ化をレジストリ設定で禁止することを推奨しています。社内文書での通常の埋め込み・リンクまで一律に禁止する必要はありませんが、出所不明の文書のオブジェクトは開かない、OLEパッケージのアクティブ化は組織的にブロックする、という運用が現実的な落としどころです。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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

お問い合わせ
ブログ一覧に戻る