Excelの10の問題点

Microsoft Excelは、ビジネスの現場で最も広く使われているツールの一つである。表計算、データ分析、簡易的なデータベースとして、多くの企業が日常業務で活用している。しかし、規制要件が厳格化する現代において、とりわけ21 CFR Part 11などの規制遵守の観点から、Excelには看過できない問題点が存在する。本稿では、監査証跡、セキュリティ、バージョン互換性を中心に、Excelが抱える10の構造的問題点を明らかにする。

10の問題点――一覧

本稿で扱う10の問題点を先に一覧で示す。「何が起きるか」は現場で観測される現象、「GxPでの帰結」は規制対応上どこに効くかである。

問題点1：監査証跡の不在

何が問題なのか

Excelには、標準機能として包括的な監査証跡（Audit Trail）機能が実装されていない。「誰が、いつ、何を、なぜ変更したか」という記録が自動的に残らないため、データの変更履歴を追跡することが極めて困難である。

具体的な影響

製薬業界などの規制産業では、Part 11により電子記録の完全性が求められる。21 CFR §11.10(e) は、監査証跡を次のように要求している。

FDAはData Integrity and Compliance With Drug CGMP: Questions and Answers（最終版ガイダンス）において、audit trail を「電子記録の作成・変更・削除に関する一連の出来事を再構成できる、セキュアでコンピュータ生成されたタイムスタンプ付き電子記録」と定義している。「再構成できる」が要点である。ファイルの最終更新日時が分かることと、経緯を再構成できることは別物である。

Excelの「変更履歴の記録」機能は、レガシーの「ブックの共有」に付属する専用機能であり、既定の保持期間は30日、機能をオフにすれば全履歴が消える。記録する側が記録を消せる仕組みは、定義上「セキュア」でも「独立」でもない。この点の詳細と、代替となる「変更内容（Show Changes）」やバージョン履歴の実務的な位置づけは、姉妹記事Excelを使用する場合の管理留意点で整理している。

また、固有のユーザーIDによるアクセス制御がExcel単体では成立しないため、「誰の操作か」を機械的に紐づけられない。監査証跡の各要素（固有のユーザーID、日時のタイムスタンプ、作成・変更・削除の詳細、変更理由）のうち、Excelが自動で残せるものは実質的に存在しない。

査察ではどう指摘されるか――FDA Warning Letterの実例

「アナリストが電子データを自由に変更・削除できる状態だった」という指摘は、抽象論ではなく現実に発出されている。文書番号で特定できる例を挙げる。

この事例はHPLCソフトウェアに関するものであってExcelそのものではない。しかし指摘の構造は完全に同じである。すなわち「操作者が自分でデータを消せる」「消した者を追跡できない」――この2点が揃えば、ツールが何であれ同じ指摘を受ける。Excelはこの2点を、既定でどちらも満たしてしまう。

問題点2：電子署名機能の欠如

何が問題なのか

Part 11では、電子記録の承認に電子署名が要求される。§11.100(a) は「各電子署名は一人の個人に固有でなければならず、他者に再使用・再割当てされてはならない」と定め、§11.70 は「電子署名は、通常の手段によって切り離し・複写・転記されて電子記録を偽造できないよう、当該電子記録にリンクされていなければならない」と定めている。

Excelにはデジタル署名機能が存在するが、これはファイル全体に対する署名であって、特定のデータ行や承認プロセスに対する署名ではない。「この検査結果を、この人が、この日時に、この立場で承認した」という粒度の記録にはならない。

実務上の困難

品質管理部門が検査結果を承認する際、Excelでは「承認者名を手入力する」「別途紙の承認書を作成する」といった代替手段に頼らざるを得ない。前者はセルに文字列を書いているだけで、§11.200(a) が要求する二要素の識別要素を伴わない。後者はハイブリッド運用となり、紙と電子のどちらが原本かという別の論点を呼び込む（紙が正か電子が正かを参照）。

Part 11準拠システムでは、文書の編集・レビュー・承認・廃止ごとに電子署名を記録し、ユーザーID・日時・変更タイプを自動記録し、全バージョン履歴を保持することが求められる。Excelにはこれらの機能が標準装備されていない。電子署名に付随する三つの明示事項（署名者の氏名、署名の日時、署名の意味）については、電子署名の3つの明示事項で解説している。

問題点3：アクセス制御の限界

何が問題なのか

Excelのパスワード保護機能は、ファイル全体または特定のシートやセル範囲に対する単純な読み取り・編集制限しか提供しない。ユーザーごとに異なるアクセス権限を詳細に設定することは不可能である。

そもそもシート保護について、マイクロソフト自身が次のように明言している。

提供元が「セキュリティ機能ではない」と述べている仕組みを、査察対応の統制手段として説明するのは無理がある。

セキュリティリスク

例えば、営業部門が顧客データベースをExcelで管理している場合、閲覧権限のみ必要な担当者と編集権限が必要な管理者を明確に区別できない。結果として、過剰な権限付与によるデータ漏洩や誤操作のリスクが増大する。

Part 11準拠システムでは、ユーザーの役割に応じた詳細なアクセス制御（Role-Based Access Control）が必須である。§11.10(d) は「システムへのアクセスを権限のある個人に限定すること」を、§11.10(g) は「権限のある個人のみが、システムを使用し、記録に電子署名し、入出力装置にアクセスし、記録を変更し、または当該作業を実施できることを保証する権限チェックの使用」を求めている。Excelではこのような高度な権限管理は実現できない。

問題点4：バージョン互換性の問題

何が問題なのか

Excelは頻繁にバージョンアップが行われるが、旧バージョンと新バージョン間で完全な互換性が保証されていない。特に、複雑な数式やマクロ、新機能を使用したファイルは、旧バージョンで正常に動作しない可能性がある。

業務への影響

企業内で複数のExcelバージョンが併存する状況は珍しくない。ある部門で作成したファイルが別の部門で正しく表示されない、数式の計算結果が異なるといった問題が起き、業務効率を低下させる。

Compatibility Versions――マイクロソフト自身が「計算結果は変わり得る」と認めた仕組み

GxPの観点で重要なのは、この問題についてマイクロソフトが公式に対処に乗り出したという事実そのものである。マイクロソフトは2024年12月3日、Microsoft 365 Insider Blog で5つの文字列関数（LEN、MID、SEARCH、FIND、REPLACE）の改善と、Compatibility Versions という仕組みの導入を告知した。

これは、既存ファイルの計算結果を保護しつつ改善を実装するための、周到な設計である。同時に、規制対応の観点からは次の含意を持つ。

問題点5：データ整合性の脆弱性

何が問題なのか

Excelでは、ユーザーが自由にセルの値を変更、削除、上書きできる。データ入力時のバリデーション（入力規則）は設定可能だが、わずか数クリックで無効化でき、また値の貼り付けによって迂回もできるため、データの整合性を保証する仕組みとしては不十分である。

現場での失敗例

在庫管理システムをExcelで運用している企業では、担当者が誤って数式を削除し、在庫数が実態と乖離するという事態が発生する。このような人為的ミスを防ぐ堅牢な仕組みがExcelには存在しない。Part 11準拠システムでは、データの完全性を保証するため、入力値の検証、データの関係性チェック、変更不可能なロックメカニズムなどが実装されているが、Excelではこれらの機能を確実に実装することができない。

より深刻なのは「Excelの仕様そのものがデータを書き換える」ことである

人為的ミスは、教育と手順で減らすことができる。しかしExcelの設計仕様に起因するデータ破壊は、担当者がどれだけ注意しても防げない。次の4つは、いずれもマイクロソフトの公開文書または査読付き文献で裏が取れる、既知の重大な問題である。

（1）オートコレクト――世界標準の命名規則が「ツールに合わせて」変更された

Excelは入力された文字列を日付らしいと判断すると、自動的に日付に変換する。マイクロソフト自身が次のように書いている。

この仕様が、科学の側に実害をもたらした。ゲノム研究では、ヒト遺伝子の公式記号として SEPT2（Septin 2）や MARCH1（Membrane Associated Ring-CH-Type Finger 1）といった名称が使われていた。これらをExcelに貼り付けると日付に変換される。そして変換された状態のまま補足資料として公表されると、下流のソフトウェアはその行を遺伝子として認識できず、黙って捨てる。

被害の規模は査読付き文献で定量されている。

• Ziemann M, Eren Y, El-Osta A.「Gene name errors are widespread in the scientific literature」Genome Biology 17:177（2016年）――主要ゲノム学ジャーナルの補足Excelファイルをプログラムで走査した結果、遺伝子リストを含む論文の約5分の1（19.6%）に、誤変換された遺伝子名が含まれていた。原著
• Abeysooriya M, Soria M, Kasu MS, Ziemann M.「Gene name errors: Lessons not learned」PLOS Computational Biology（2021年7月30日）――2014〜2020年の論文を走査したところ、補足Excel遺伝子リストを含む論文の30.9%（3,436／11,117件）に誤変換が含まれ、2016年の指摘以降も減っていなかった。原著

そして2020年、HGNC（HUGO Gene Nomenclature Committee／ヒト遺伝子命名委員会）は、遺伝子記号そのものを改名した。HGNCが Nature Genetics に公表した命名ガイドラインには、記号を変更すべき場面の一つとして次が明記されている。

なお、Excel for Microsoft 365 および Excel 2024 以降には 「自動データ変換（Automatic Data Conversion）」 の設定が追加され、①先頭ゼロの除去、②16桁以上の数値の切り捨て、③文字「E」を含む数値の指数表記化、④日付らしい文字列の日付変換――を個別に無効化できるようになった。設定場所は Windows版が File ＞ Options ＞ Data ＞ Automatic Data Conversion、Mac版が Excel ＞ 環境設定 ＞ 編集 ＞ 自動データ変換である（Microsoft Support「Set automatic data conversions」）。ただしこれはユーザー環境側の設定であり、ファイルに埋め込まれるものではない。他者が別の端末で開けば、その端末の設定が適用される。規制対象記録を扱うのであれば、この設定を組織全体で統一し、その状態を記録として残す運用が必要になる。

（2）CSV取り込み時の自動型変換――先頭ゼロと桁落ち

機器から出力されたCSVをExcelで開く、という手順は試験室で日常的に行われている。しかしマイクロソフトは次のように述べている。

ロット番号 00123 は 123 になり、16桁以上の識別番号は上位15桁だけが残る。しかもこの変換は、開いて保存し直した時点で確定する。元のCSVを上書き保存してしまえば、原本は失われる。「原本はCSVである」という取決めを文書化していない現場では、この時点で ALCOA+ の Original が崩れている。

回避策としてマイクロソフトが案内しているのは、①列をテキスト書式にしてから入力する、②アポストロフィを前置する、③Power Query（データの取得と変換）で列をテキストとして読み込む、④上記の自動データ変換設定を無効化する――である。③のPower Queryによる取り込みが、規制対象データでは最も推奨できる。変換手順自体がクエリとして保存され、再現・レビューが可能になるためである。

（3）浮動小数点演算（IEEE 754）――表示と内部値の乖離

Excelは IEEE 754 仕様に基づいて数値を格納する。マイクロソフトは次のように明記している。

同ページが挙げている例が示唆的である。=(43.1-43.2)+1 をセルに入力し、表示形式を指数15桁にすると、0.9 ではなく 0.899999999999999 が表示される。マイクロソフトはこれをExcelの欠陥ではなくIEEE 754仕様に厳密に従った結果であると説明しており、他の表計算ソフトでも同様であるとしている。

規格判定への影響は明白である。規格値「0.9%以下」に対して計算結果が 0.899999999999999 であれば適合、0.900000000000001 であれば不適合となる。丸め処理をどこで、何桁で行うかを手順書に定めていなければ、判定は担当者の表示形式設定に依存する。これは §11.10(a) の「一貫した意図した性能」に直接抵触する。対処としてマイクロソフトが挙げているのは ROUND 関数の明示的な使用と、「表示桁数で計算する（Set precision as displayed）」オプションである。ただし後者は「元に戻せず、失われたデータは復元できない」とマイクロソフト自身が警告しているとおり、規制対象記録では極めて危険な設定であり、使用すべきではない。

（4）1900年うるう年バグ

Excelは1900年2月29日を存在する日付として扱う。これはバグではなく、意図的に維持されている仕様である。

マイクロソフトはこれを修正しない理由として、修正すれば既存の全ワークシートの日付が1日ずれること、WEEKDAY 関数の戻り値が変わり数式が誤動作すること、他プログラムとのシリアル日付互換性が失われることを挙げている。修正しない場合に生じる問題は「1900年3月1日より前の日付について WEEKDAY 関数が誤った値を返す」の一点のみであり、1900年以外のうるう年（2100年など、100で割り切れて400で割り切れない年）は正しく扱われる。

実務上、GxP記録で1900年2月以前の日付を扱うことはまずない。したがってこの問題の実害は限定的である。しかし本稿でこれを挙げるのには理由がある。バリデーション時に「日付計算の境界値テスト」を設計する際、Excelの日付シリアル値がグレゴリオ暦と1日ずれる区間が存在することを知らずに期待値を組むと、テストそのものが誤る。ツールの仕様を知らないままバリデーションを書くことの危険性を示す好例である。

問題点6：同時編集の制約

何が問題なのか

Excel Onlineや共同編集機能により同時編集は可能になったものの、デスクトップ版Excelでローカルに保存されたファイルは、基本的に一人のユーザーしか編集できない。共同編集が成立するには、ファイル形式と保管場所の両方の条件を満たす必要がある。

コラボレーションの障壁

複数の部門が関与するプロジェクトで、予算管理表をExcelで作成する場合、条件を満たさなければ各部門が順番にファイルを編集する必要がある。これはリアルタイムのコラボレーションを阻害し、意思決定のスピードを遅らせる要因となる。

OneDrive／SharePointによる改善と、GxPでの読み替え

OneDriveまたはSharePoint Onlineにファイルを保存することで、リアルタイムの同時編集が可能になり、この問題は大幅に軽減される。複数のユーザーが同時に編集でき、他のユーザーのセル選択が異なる色で表示され、@メンション機能による通知・コメントも利用できる。

ただしローカルパス（C:\）に保存されたファイルや SharePoint On-Premises 環境では共同編集は利用できないため、組織としての統一的な運用方針が必要である。

問題点7：スケーラビリティの限界

何が問題なのか

Excelには行数と列数の上限が存在する。マイクロソフトの公式仕様は次のとおりである。

これは Excel 2007 以降の全バージョン（Microsoft 365 を含む）に共通する技術的制約である。また、ファイルサイズが大きくなると動作が極端に遅くなり、最悪の場合クラッシュする。大量データの処理には本質的に不向きである。

参考として、Googleスプレッドシートの上限は1,000万セルまたは18,278列（列 ZZZ）である（Google ドライブ ヘルプ「Google ドライブに保存できるファイル」）。列数だけを見ればExcelより多いが、セル総数に上限がある点はExcelと異なる。いずれにせよ、「表計算ソフトの上限を意識しなければならない規模のデータ」は、すでに表計算ソフトで扱うべき規模を超えていると考えるのが健全である。

ビッグデータ時代の課題

IoTセンサーから収集される大量のデータや、顧客の行動ログなど、現代のビジネスで扱うデータ量は急速に増加している。Excelでこれらを扱おうとすると、パフォーマンスの問題に直面し、分析作業そのものが困難になる。

規制産業では、臨床試験データや製造記録など、数十万件規模のデータを長期間保管・分析する必要があるが、Excelではこのような大規模データの管理は現実的ではない。加えて、保管期間の長さがこの問題を増幅する。数十万行のブックを10年後に開いて、当時と同じ計算結果を再現できるかという問いには、別の困難が伴う（電子記録の長期保存が困難な理由を参照）。

問題点8：セキュリティ脆弱性への露出

何が問題なのか

Excelファイルに埋め込まれたマクロ（VBA）は、マルウェアの運搬手段として長く使われてきた。また、ファイルの暗号化機能も、パスワードが短く単純な場合には解読される可能性がある。

サイバー攻撃のリスク

Excelファイルを起点とする標的型攻撃は、現在も継続して観測されている。商用セキュリティベンダーである Fortinet の FortiGuard Labs は2024年6月、ウクライナを標的とした攻撃で、VBAマクロを埋め込んだExcelファイルが Cobalt Strike の展開に用いられたとする調査報告「Menace Unleashed: Excel File Deploys Cobalt Strike at Ukraine」を公表している（FortiGuard Labs）。

報告によれば、この攻撃はウクライナ語で作成された軍事予算関連を装うExcelファイルを用い、利用者にマクロの有効化を促す社会工学的手法を伴っていた。多段階のマルウェア配信によって最終的に Cobalt Strike のペイロードを展開し、C2サーバーと通信を確立する。

セキュリティ対応の進展――インターネット由来マクロの既定ブロック

マイクロソフトは、Windows版のAccess、Excel、PowerPoint、Visio、Word において、インターネット由来のファイルに含まれるVBAマクロを既定でブロックする変更を実施した。この変更の適用時期は更新チャネルごとに異なる。

この機能は Mark of the Web（MOTW） という技術に基づいている。Windowsは、インターネットゾーンまたは制限付きサイトゾーンから取得したファイルに ZoneId 属性を付与する。ZoneId=3（インターネットゾーン）のファイルはマクロがブロックされ、利用者には「Enable content（コンテンツの有効化）」ボタンを持たない SECURITY RISK バナーが表示される。ZoneId=2（信頼済みサイト）であればブロックされない。

ただし次の点に注意が要る。

• Windows以外は対象外。Mac版Office、Android／iOS版Office、Office on the web には、この変更は適用されない
• MOTWはNTFS上のファイルにのみ付与される。FAT32でフォーマットされたデバイスに保存されたファイルには付かない
• 既に「Enable content」を押したことがあるファイルは、信頼済みドキュメントとして扱われ、変更後もマクロが動く
• OneDrive／SharePointから「デスクトップアプリで開く」を選んだファイル、OneDrive同期クライアントがダウンロードしたファイルには MOTW が付かない

つまり「2022年7月以降はマクロが安全になった」という理解は正しくない。既定値が変わり、リスクが大幅に軽減されたことは事実だが、利用者が「Enable content」に相当する操作を行う社会工学的手法の有効性は依然として高い。過信は禁物である。

暗号化の強度と、その限界

暗号化そのものは強固である。マイクロソフトによれば、Office 2016 以降で Open XML 形式（.xlsx 等）を既定値で暗号化した場合、AES（256ビット鍵長）、SHA-2、CBC が使用される。またAgile Encryptionの仕様上、パスワードのハッシュ化は spinCount 回（既定 100,000 回）反復される。

一方、Office 97-2003 のバイナリ形式（.xls 等）は RC4 でしか暗号化できない。マイクロソフトは「RC4 は推奨されない」と明記し、Open XML 形式での保存を推奨している（Microsoft Learn「Cryptography and encryption in Office 2016」）。古い .xls ファイルが長期保管庫に残っている組織は、この点を棚卸ししたほうがよい。

ただし暗号アルゴリズムが強固であっても、パスワードが短く単純であれば総当たり攻撃の対象になる。強力なパスワード（12文字以上、大小英字・数字・記号の組合せ）の使用と、そもそもファイルパスワードに依存しない設計（保管場所側のアクセス制御と暗号化）が本筋である。

問題点9：バックアップとリカバリの困難さ

何が問題なのか

Excelファイルは通常、個人のPCやネットワークドライブに保存される。組織的なバックアップ体制が整っていない場合、ファイルの紛失や破損時に復旧が困難である。また、特定時点の状態に戻す「ポイントインタイム・リカバリ」も容易ではない。

データ損失のリスク

重要な財務データをExcelで管理している企業で、担当者のPCが故障し、過去数ヶ月分のデータが失われるという事態が実際に発生している。規制産業では、データの完全性と追跡可能性が求められるため、このようなバックアップ体制の脆弱性は重大なコンプライアンスリスクとなる。§11.10(c) は「保存期間を通じて、記録を正確かつ迅速に検索できるよう保護すること」を求めている。

OneDrive／SharePointによる改善

この問題については、OneDriveまたはSharePoint Onlineへの移行により大幅に改善される。具体的には以下の機能が利用可能になる。

• バージョン履歴：ファイルの版が自動保存され、過去の版に復元できる。保持ポリシーは組織の設定に依存する
• AutoSave（自動保存）：マイクロソフトは「AutoSave saves your file automatically, every few seconds, as you work（AutoSaveは作業中、数秒ごとにファイルを自動保存する）」と記載している。ただし利用には Microsoft 365 サブスクリプションと、OneDrive／OneDrive for Business／SharePoint Online への保存が必須である（Microsoft Support「What is AutoSave?」）
• ポイントインタイム・リカバリ：バージョン履歴に残っている範囲で、過去時点の状態に復元できる

バージョン履歴は「永遠に残る」ものではない――自動間引きの実際

ここが最も誤解されやすい点である。SharePoint／OneDrive のバージョン履歴には上限設定があり、その既定が「自動（Automatic）」である場合、古い版は機械的に間引かれる。マイクロソフトはそのアルゴリズムを明示している。

さらに重要な記載がある。同ドキュメントは、ライブラリに設定された上限を超えて削除された版は、通常のごみ箱を経由せず完全に削除され、ごみ箱から復元できないと明記している。管理者がスケジュールした版の削除ジョブについても同様である。

問題点10：規制変更への対応の遅さ

何が問題なのか

規制要件は時代とともに変化する。しかし、Excelベースのシステムでは、新たな規制要件に対応するためにファイル構造や運用ルールを変更することが困難である。特に、過去に作成された大量のファイルを遡って修正することは現実的ではない。

専用システムであれば、要求の変更はデータモデルとロジックの改修として一元的に実施でき、既存データもマイグレーションの対象にできる。Excelでは「改修対象」がファイル単位で数百・数千に散在している。これが本質的な差である。

コンプライアンスリスク

個人情報を含むExcelファイルは、その典型例である。EU一般データ保護規則（GDPR、規則(EU) 2016/679）第17条は、データ主体が管理者に対して自己に関する個人データの消去を求める権利（いわゆる「忘れられる権利」）を定めている。また第30条は、処理活動の記録を保持する義務を定めている。

顧客データベースをExcelで管理している場合、特定の個人の全データを完全に削除し、その削除記録を保持することは、複数のファイルに分散したデータを手作業で探す必要があり、実務上きわめて困難である。さらに厄介なのは、削除したこと自体を証明できない点である。バージョン履歴やバックアップに残った旧版に当該個人のデータが残っていれば、削除は完了していない。

AI機能の追加は、この問題をさらに難しくする――COPILOT関数の例

規制変更への追随という論点は、近年もう一つの様相を帯びている。Excel自体に、再現性のない機能が追加されつつあるということである。

セルに自然言語のプロンプトを書いてAI処理を行う COPILOT 関数について、マイクロソフトは公式ドキュメントで次の点を明記している。

そしてより広い含意はこうである。Excelは今後も機能が追加され、削除され、既定値が変わり続ける。Compatibility Versions（問題点4）、マクロの既定ブロック（問題点8）、自動データ変換設定（問題点5）、COPILOT関数の提供終了（問題点10）――本稿で扱っただけでも、この数年で4件の仕様変更があった。汎用の生産性ツールを規制対象記録の器として使うということは、提供元の製品ロードマップに自社のコンプライアンスを預けるということである。

解決への道筋

専用システムへの移行検討

これらの問題点を根本的に解決するには、規制要件に対応した専用のデータ管理システムやエンタープライズ向けアプリケーションへの移行を検討すべきである。LIMS（Laboratory Information Management System）、QMS（Quality Management System）、ERP（Enterprise Resource Planning）などが選択肢となる。これらのシステムでは、以下のような機能が標準実装されている。

• 包括的な監査証跡（誰が、いつ、何を、なぜ変更したかの完全な記録）
• 規制要件に準拠した電子署名機能
• ユーザーの役割に応じた詳細なアクセス制御
• データ整合性を保証する検証ルール
• 自動バックアップとポイントインタイム・リカバリ
• 規制変更に対応可能な柔軟なシステム設計

段階的なアプローチ

いきなり全てをExcelから移行するのではなく、まず規制リスクが最も高い領域から優先的に対応する。例えば、Part 11への準拠が必須な製造記録や品質データから着手し、成功事例を積み重ねながら展開範囲を広げていく。具体的には、以下のような優先順位付けが考えられる。

1. 最優先（High Risk）FDA査察対象の電子記録――製造記録、品質試験データ、臨床試験データ。監査証跡と電子署名が制度上の必須要件となる領域である
2. 優先（Medium Risk）個人情報を含むデータベース――顧客情報、従業員情報。削除権への対応と処理記録の保持が求められる
3. 検討（Low Risk）定型的な集計や一時的な分析。ここまでを一律に移行対象とすると、コストに対して得られる統制が見合わない

このように、リスクベースアプローチで段階的に移行することで、組織への影響を最小化しながら確実にコンプライアンスを向上させることができる。移行の判断基準（「いつExcelをやめるべきか」）は、姉妹記事Excelを使用する場合の管理留意点で具体化している。

ハイブリッド戦略――使い分けの対比

全てをExcelから置き換える必要はない。定型的な集計や一時的な分析など、Excelが得意とする用途では引き続き活用し、監査証跡やセキュリティが重要な用途では専用システムを使用するというハイブリッドアプローチも現実的である。判断の分かれ目は次のとおりである。

まとめ

Excelは優れたツールであり、その柔軟性と使いやすさは多くのビジネスパーソンに支持されている。しかし、規制遵守が求められる環境や、データの完全性・セキュリティが重要な用途においては、従来型Excelの設計上の限界が存在する。

本稿で見てきたとおり、その限界には二つの層がある。第一に、監査証跡・電子署名・アクセス制御といった「規制が要求する機能が備わっていない」という層。これは運用と補完的な仕組みでかなりの部分を埋められる。第二に、オートコレクト・浮動小数点・自動型変換・関数の版差といった「Excelの仕様そのものがデータを書き換える」という層。こちらは運用では埋まらない。HGNCが遺伝子記号を改名したという事実は、後者の層の重さを何より雄弁に物語っている。

一方で、マイクロソフトも継続的な改善を進めている。2022年7月のマクロ既定ブロック、2024年12月に告知された Compatibility Versions、自動データ変換設定の追加、OneDrive／SharePointによるバージョン履歴とAutoSave――いずれも実在する改善である。ただしそれぞれに、本稿で見たとおりの適用条件と例外がある。「対策が入ったから安全になった」で止めず、自社の環境で条件を満たしているかを確認することが要る。

Excelの問題点と改善動向の両方を正しく理解し、適切な用途と不適切な用途を見極めることが、コンプライアンスリスクを低減し、業務効率を向上させる第一歩となる。重要なのは、Excelを全面的に否定するのではなく、その限界を認識した上で、組織全体として最適なツールの組み合わせを選択していくことである。技術の進化を味方につけ、より信頼性の高いデータ管理体制を構築していくことが、これからの時代を生き抜く鍵となるであろう。