WordやExcelにSQLやOLEが出てくる理由
（統合業務環境の光と影）

by
  • WordやExcelには差込印刷やOLEオブジェクトなど複雑な機能が存在するが、これは1990年代にMicrosoftが企業向け統合業務環境を構築するために設計したCOMとOLEのアーキテクチャに由来する。
  • MicrosoftはVBAという共通スクリプト言語でOfficeアプリを横断した自動化を実現し、Lotus 1-2-3やWordPerfectといった競合を駆逐する戦略的な囲い込みにも成功した。
  • しかしこの密結合な設計はMelissaやILOVEYOUといったマクロウイルスの温床となり、2000年代に深刻なセキュリティ被害をもたらした。
  • 根本的な設計変更は困難だったため、Microsoftはセキュリティ層の追加とXML標準形式への移行で対処し、Windows 10でようやく権限分離による現代的な保護体制が整った。

関連記事

1. WordやExcelで見かける専門用語

WordやExcelを使っていると、日常的な操作の延長でデータベースや企業システムを連想させる言葉が突然現れることがあります。
「SQLクエリ」「SharePoint」「OLEオブジェクト」「ODBC」「Exchangeサーバ」などなど。

Officeに潜む専門用語の正体 差込印刷 ODBC SQLクエリ Excelのデータを Wordへ流し込む OLEオブジェクト ダブルクリックで 埋め込み元アプリが起動 変更が即座に反映 Outlook連携 連絡先リスト ↓ 差込印刷の宛先に これらはすべて1990年代のアーキテクチャ設計の痕跡 COM / OLE / ODBC

1.1. 差込印刷とSQLクエリ

たとえば、差込印刷です。
Wordで案内状や請求書を一括作成しようとすると、データソースの選択画面でODBCやSQLクエリという言葉が出てきます。
ExcelのシートをデータソースにもできますしAccessのテーブルに直接接続することもできます。
Outlookの連絡先をそのまま差込印刷の宛先として流し込む機能もあります。

1.2. 文書内の埋め込みOLEオブジェクト

Excelのシートに埋め込まれたWordの文書、Wordの文書内で生きたまま更新されるExcelのグラフ、こういった複合ドキュメントはOLEオブジェクトとして機能します1。
ダブルクリックすると埋め込み元のアプリが起動して編集でき、変更は即座に親ドキュメントに反映されます。

WordやExcelは、ただの文書作成ソフトではなく、驚くほど複雑な仕組みを持っています。
この背景にあるのは、1990年代に下された、ある決断の痕跡です。

2. 初期のWord・Excelの競合

1980年代、WordやExcelはそれぞれ独立した単体アプリとして登場しました。

Office統合の歴史：1987〜1993 // OLE Automation — 外からExcelを直接操作 Set MyObj = CreateObject(“Excel.Sheet”) 1987 DDE アプリ間 メッセージ通信 Win 2.0 1991 OLE 1.0 複合ドキュメント 文書に文書を 埋め込む 1993 OLE 2.0+COM オブジェクトを 直接掴んで操作 Excel 5.0 1993 VBA Office共通の 自動化言語 横断スクリプト UNIXのパイプ哲学（小さく分離）とは対照的な「深く踏み込む連携」設計

Excelは1985年にMacintosh向けに発売され、1987年にWindows版が出ました。
表計算ソフトでの当時の競合はLotus 1-2-3。
DOS上で動くキーボード操作中心の製品でした2。

WordはMS-DOS版が1983年、Macintosh版が1984年、Windows版が1989年に登場しました。
こちらも一太郎やWordPerfectという強力な競合があり、法律事務所や官公庁に深く根付いていました。

WordやExcelはGUIとマウス操作を前提にした設計を持ち込み、セルへの直接入力、グラフ作成、書式設定といった機能が視覚的に扱えるようになりました。

2.1. アプリ間通信とDDE（Dynamic Data Exchange）

WordやExcel、PowerPointをまとめて、Microsoft Officeとして最初に発売されたのは1990年です。
この時点では一つのパッケージとして束ねて販売するというだけで、アプリ同士が深く連携していたわけではありませんでした。

Windowsにおけるアプリ間通信の試みは、1987年のWindows 2.0で「DDE（Dynamic Data Exchange）」として始まりました3。
「DDE」は、あるアプリが別のアプリにメッセージをブロードキャストしてデータを受け渡す仕組みで、たとえばExcelのセル「r1c1」の値を他のアプリから取得するといったことができました。
クライアントとサーバーが「アプリ名」「トピック」「アイテム」という三層の文字列キーで情報をやり取りするシンプルな設計でした4。

2.2. OLEとCOM（内部に手を突っ込む設計）

Microsoft Officeの密結合な設計として、DDEの次に登場するのが、「OLE」です。

1991年に、WordとExcelに「OLE 1.0」という機能が導入されます。
「OLE（Object Linking and Embedding）」は、文書に文書を埋め込む機能です。
たとえば、Wordの文書にExcelのスプレッドシートを「生きたまま」埋め込み、Excelで編集した変更がWord上に即座に反映される、という機能で、「複合ドキュメント」という概念を実現しました。

そこに、「COM（Component Object Model）」という仕組みが加わります。
これは、Windowsでソフトウェア部品同士をつなぐための共通の仕組みです。

「OLE 2.0」では、COMの上に実装し直され、さらに「OLE Automation」という仕組みへと発展し、アプリ同士をつなぐ仕組みは進化します。

「OLE Automation」は、「VBA」のもととなる技術で、あるアプリが別のアプリの公開オブジェクトをスクリプト言語から直接操作できる技術です5。

具体的には次のようなコードでExcelを外から操作できました。

Set MyObj = CreateObject("Excel.Sheet")
MyObj.Cells(1, 1).Value = "Hello"Code language: JavaScript (javascript)

相手アプリを「起動して操作する」のではなく、その内部オブジェクトを「直接掴んで動かす」感覚に近いです。

この設計思想は、コマンドを小さく分離するUNIXのパイプ哲学とは対照的です。
WindowsのOLEとCOMは、アプリ同士が互いの内部構造に深く踏み込んで連携する方向を選んだのです。

2.3. VBAという共通言語（1993年）

OLE Automationを企業の業務で実際に使えるものにしたのが、1993年のExcel 5.0で導入されたVBA（Visual Basic for Applications）です。

それまで各Officeアプリは独自のマクロ言語を持っていました。
これが、VBAによってOffice全体をまたぐ共通の自動化言語が整いました6。

VBAは、OLE Automationのクライアントとして機能し、WordのマクロからExcelオブジェクトを操作する、ExcelのマクロからOutlookでメールを送る、といったアプリを横断する自動化が少しの知識でできるようになりました。

2.4. ビジネス的な囲い込み戦略

この密結合なアプリケーション設計には、Microsoftのビジネス戦略も絡んでいました。

1990年代前半、MicrosoftはLotus 1-2-3やWordPerfectといった強力な専業アプリと戦っていました。
Microsoftがとった戦略は、個別アプリの性能で真正面から勝負するより、スイートとして統合することでした。

Officeに追加された、これらの連携機能は、企業のIT部門にとってはとても有用でした。
これまで、さまざまな専門ソフトが必要だった業務フローが、Officeスイートを組み合わせることで、完結するようになったからです。
差込印刷でExcelの顧客データをWordに流し込む、AccessのデータベースをExcelから直接クエリする、Outlookの連絡先をWordで加工するといった一連の業務が、スクリプトで自動化できるようになったのは、当時 画期的なことでした。

企業が一度Office環境に移行すれば、VBAで組んだ業務自動化スクリプト、差込印刷のテンプレート、PST形式のメールアーカイブが溜まっていきます。
WordとExcelとOutlookが深く連携するほど、そのどれかを他社製品に置き換えることが難しくなります。
Lotus 1-2-3もWordPerfectも、1990年代中盤までにシェアを失いました7。

3. セキュリティという代償（2000年代の負の遺産）

しかし、1990年代、Officeの普及を支えたVBAの利便性は、2000年代には大きな負の遺産としてのしかかります。

セキュリティという代償（2000年代） Melissa 1999年3月 📄 Word文書を開くとVBAが実行 Outlookで50件に自動送信 被害：約100万台 ILOVEYOU 2000年5月 📧 VBScript、全連絡先に送信 ペンタゴン・CIAも停止 被害：4500万人・約100億ドル 根本原因：脆弱性ではなく「設計通りの機能」の悪用 OLE Automationで他アプリを操作できる仕組みがそのままウイルスに使われた

ここまでの時期のWindowsは、基本的にはシングルユーザーを前提とした設計でした。
これは、信頼できる業務アプリ同士が同一マシン上で連携するという前提で、メモリ保護もプロセス間の分離も今日のOSより緩かったです。

そこに、1999年3月、Melissaウイルスが出現します。

この悪意のあるプログラムは、Word 97/2000のマクロで、「Word文書」として拡散します。
この文書を開くとVBAコードが自動実行され、同じパソコンのOutlookの操作して、その人のアドレス帳の最初の50件に同じ文書をメール送信しました。
VBAがOutlookオブジェクトを生成し、CreateObjectでOutlookを操作してメール送信を自動化するという流れで、これはOLE Automationの仕組みの悪用です8。

2000年5月には、ILOVEYOUウイルスが登場します。
これも、VBScriptというWindowsに標準で含まれるスクリプト実行環境で書かれ、メールの添付ファイルとして拡散します。
添付ファイルを何気なく開くと、スクリプトが実行され、Outlookのアドレスブックにあるすべてのアドレスに同じメールを送信しました。

Melissaの被害が約100万台だったのに対し、ILOVEYOUは10日間で推定4500万人以上に到達し、ペンタゴン、CIA、英国議会を含む大規模組織が一時的にメールシステムを停止させました9。
その被害総額は約100億ドルとされ、社会問題になりました。

3.1. とりあえずの実行制限

注目すべきは、ILOVEYOUがOfficeやWindowsの脆弱性を突いたのではなく、設計通りの機能を悪用したことです。
当時MicrosoftのOfficeチームを率いていたスティーブン・シノフスキーは後に、「セキュリティと利便性のトレードオフで利便性を優先してきた結果だった」と振り返っています。

Microsoftがとった対策は、基本的には「弥縫策」と言えます。
ここまで普及した設計は、かんたんには変わられません。
すでに、企業の業務プロセスがCOMとOLEのアーキテクチャによって自動化されていたので、廃止することは現実的に不可能だったからです。

まず、2000年6月のOutlookアップデートで、外部プログラムがアドレスブックにアクセスしようとした際に警告を出す変更を加えました。
そこで、既存の連携経路に確認ダイアログという柵を追加したものです。

2002年、ビル・ゲイツは Trustworthy Computing を最優先事項とし、新機能より安全性を優先する方針に転換しました。
これにより、マクロはデフォルトで無効になり、添付ファイルの実行制限が強化されました。

ただし、密結合な設計そのものは温存されたままで、セキュリティ層が上に重ねられました。
市販のセキュリティソフトも、極端に不便になるCOMの仕組みそのものを制限することはできず、ウイルスコードと見つけては記録し、一致するファイルを検出してブロックする方式を取りました。

ちょうどこの時期は Windows XPで、パソコンやインターネットが一般家庭に普及した時期でもあります。
今日まで続く「コンピュータウイルスは怖い」という恐怖の一つの大きな要因は、このOfficeの「強力」なアプリ連携設計とも言えるかもしれません。

3.2. Windows10までのセキュリティの段階的な進化

根本的な問題解決として、このセキュリティ設計を確立するまでには、2015年のWindows 10までおよそ10年の月日が流れていきます。

  • Windows XP SP2（2004年）でDEP（データ実行防止）とWindowsファイアウォールが導入され、悪意あるコードがメモリ上で実行される経路を塞ぎ始めました。
  • Windows Vista（2007年）でUAC（ユーザーアカウント制御）とIntegrity Level（プロセスの信頼レベルを階層化する仕組み）が入り、プロセス間の権限分離が進みました。
  • Windows 8（2012年）でSecure Bootが導入され、OS起動前の段階からの保護が加わりました。
  • Windows 10はこれらの積み重ねの上に、仮想化による強い分離を乗せました。

アプリの密結合の問題の解決には、「信頼の前提を変える」というアプローチが取られました。
同一マシン上のプロセスを無条件に信頼するのをやめ、すべてのアクセスを権限で制御するゼロトラスト的な方向です。
その一つの完成形がWindows 10だったと言えます。
Windows 7やWindows 8などの過去のOSが、無償でアップグレードできるようにしたのは、このセキュリティの完成を目的としていた、と言えます。

3.3. Office Open XMLの標準化（.docx, .xlsx ）

ちなみに、セキュリティの問題を受け、2000年代の機能設計の中心は「標準データ形式」でした。

2003年のOffice 2003では、XMLとWebサービス連携が新機能として登場します。
「XML」はデータを構造化して記述するための形式で、アプリ固有の内部形式に代わる共通の受け渡し手段として機能することになります。
さらに、Office 2007では、標準のファイル形式が .docx や .xlsx などに変更されます。
XMLファイルをまとめてZIPで圧縮するファイル形式で、ECMAやISOで国際標準になり、Microsoftは、独自のデータ形式から転換することになりました。

COMとOLEが「相手アプリのオブジェクトを掴んで動かす」設計なら、WebサービスやXMLは「決められた形式のデータを入口に渡す」設計です。

COMやOLEは、強力ではあるもののセキュリティの問題がありました。
また、相手アプリの実装詳細にも合わせるがあり、バージョンアップで壊れやすい欠点もありました。
一方、XMLによる連携では、データ形式の約束が守られていれば、その先の動作は相手のアプリに任せることができます。
中身を知らなくてよくなり、依存関係が浅くなります10。

4. 現代のOfficeに見える歴史の層

今のOfficeに感じる複雑さは、この歴史的な層の厚さから来ています。

現代のOfficeに残る歴史の層 DDE / OLE / COM 1987〜1993 VBA・マクロ自動化 1993〜 セキュリティ層の追加 2002〜 UAC・DEP Office Open XML .docx / .xlsx 2007〜 Microsoft 365 / クラウド 2010年代〜現在 ↑ 新しい層 なぜ今も残るのか VBAで組まれた業務スクリプト 世界中の企業で今も稼働中 PSTメールアーカイブ 30年分のデータが蓄積済み 差込印刷のODBCテンプレート 企業の業務フローに組み込まれた 「設計ミス」ではなく「合理的判断の積み重ね」が後の自由度を狭めた

差込印刷でSQLという言葉が出てくるのは、ODBCやOLE DBというデータベース接続の仕組みを通じてAccessから企業の基幹システムまでを直接接続することを前提に設計された機能が残っているからです。
PSTファイルがMicrosoft 365のクラウド移行が進んでも消えないのは、企業が30年分のメールアーカイブをその形式で持ち続けているからです。
VBAが今もOfficeに存在するのは、それで組まれた業務自動化スクリプトが世界中の企業で動いているからです。

これは、単なる「設計ミス」と言い切ることはできません。
1990年代という特定の条件（企業向け統合業務環境を一つのベンダーで完結させる、インターネットがまだ脅威として前景化していない、企業IT部門が管理する閉じたネットワーク）では合理的な判断の積み重ねだったからです。

しかし、その判断の積み重ねが後の自由度を狭めました。
密結合のアーキテクチャは変更コストが高く、2000年代のセキュリティ危機に対してもアーキテクチャ改革より「柵の追加」で対処するしかありませんでした。

個人ユーザーが今も「なぜOfficeはこんなにも複雑なのか」と戸惑うのは、企業向けの設計遺産を個人向けにも同じ製品として引き継いできた30年分の厚みが、そこに見えているからです。

  1. OLEオブジェクトをダブルクリックすると埋め込み元のアプリがその場で起動する動作は、技術的には「インプレース活性化（In-Place Activation）」と呼ばれます。OLE 2.0で導入された機能で、別ウィンドウを開かず親ドキュメントの中で直接編集できる点がOLE 1.0からの大きな改善でした。 – Object Linking and Embedding – Wikipedia
  2. Lotus 1-2-3は1983年の発売初年度に5400万ドルの売上を記録し、当時のMicrosoftを規模で上回っていました。1987年時点でPCを仕事に使うアメリカ人1500万人のうち4人に1人が1-2-3を使っていたとされます。Windowsへの移行に乗り遅れたことが衰退の主因で、Windowsネイティブ版のリリースはExcel 3.0より1年以上遅れました。 – Lotus 1-2-3 – Wikipedia
  3. DDEより前のアプリ間通信手段はWindowsメッセージングレイヤーのみで、OS↔アプリ間の一方向でした。DDEはこれを拡張してアプリ同士のピアツーピア通信を可能にしましたが、メッセージブロードキャストという設計上の制約から後継技術のOLEに置き換えられていきました。 – Dynamic Data Exchange – Wikipedia
  4. DDEは2017年にWordやExcelを通じたマルウェア配布に悪用される事例が相次ぎ、MicrosoftはWordのDDE機能をデフォルトで無効化する更新を行いました。1980年代の設計が30年後にセキュリティリスクとして顕在化した例です。 – Microsoft Disables DDE Feature in Word to Prevent Further Malware Attacks – Bleeping Computer
  5. OLE AutomationのIDispatchインターフェースは遅延バインディング（実行時に型情報を取得する方式）を採用しており、VBAのようなスクリプト言語から型定義なしに相手アプリを操作できる柔軟性がありました。その反面、早期バインディングと比べて呼び出しコストが増大するという性能上のトレードオフがありました。 – OLE Automation – Wikipedia
  6. VBA以前のExcelには、XLM（Excel 4.0 Macro）と呼ばれる独自マクロ言語がありました。1992年のExcel 4.0で導入されたもので、セルに数式形式でコマンドを記述する方式でした。VBAとは設計が全く異なり、COMにも対応していませんでしたが、後方互換性のために現在のExcelでも動作します。セキュリティリスクから、Microsoftは2022年にXLMマクロをデフォルトで無効化しました。 – At long last, Microsoft is disabling Excel 4.0 macros by default – Malwarebytes
  7. Lotus 1-2-3はWindowsへの移行にあたってOS/2サポートに注力するという戦略ミスを犯し、Windows対応版の出遅れが決定的でした。IBMが1995年にLotusを買収しましたが、最終的には2013年まで販売が続いた後に終了しました。 – The Dilemma of Lotus 1-2-3 – Korn Ferry
  8. Melissaウイルスの作者David Lee Smithは1999年12月に有罪を認め、2002年5月に連邦刑務所で20か月の懲役と5000ドルの罰金刑を受けました。彼はその後FBI捜査に協力し、海外のウイルス作者の摘発にも貢献しています。 – Creator of Melissa Computer Virus Sentenced to 20 Months in Federal Prison – U.S. Department of Justice
  9. ILOVEYOUウイルスの作者Onel de Guzmanはフィリピンの学生でしたが、当時フィリピンにはコンピュータ犯罪を取り締まる法律がなく、不起訴となりました。この事件を受けてフィリピン議会は2000年7月に電子商取引法を制定しています。 – What is the ILOVEYOU virus and how do you protect against it? – TechTarget
  10. この流れの象徴がOffice 2007で導入されたOffice Open XML形式（.docx、.xlsx、.pptx）です。ZIPで圧縮されたXMLファイルの集合体として文書を表現するこの形式は、2006年にEcma Internationalで標準化（ECMA-376）され、2008年にISO/IECの国際標準（ISO/IEC 29500:2008）となりました。独自バイナリ形式（.doc、.xls）から標準ベースの形式への移行は、まさにアプリ固有の内部構造から公開された境界への転換を体現しています。 – Office Open XML – Wikipedia