「検証合格」の生成AI製Excelが、Microsoft Excelで開いた段階で修復された一例――修復ログが示した、機械検証の死角

＜２０２６年７月２２日以前のコンテンツ一覧はこちら＞

生成AIにExcel編集を任せる担当者・依頼者が、納品前に一度は確認しておきたいこと（※本稿は筆者自身が経験した1件の追跡記録であり、一般的なOOXML実装やExcel全般についての普遍的な主張ではありません）

はじめに：この一件は「バグ」というより「検証範囲の見落とし」に見えた

生成AIにExcelファイルの修正を依頼し、「ファイルの再読み込みに成功」「ZIPとして正常」「数式の再計算でエラーなし」という報告を受け取った。その数分後、実際にMicrosoft Excelでそのファイルを開いた担当者の画面に、こう表示された。

今回、私たち自身の検証用資料（生成AIによるExcel生成の失敗パターンを集めた比較表そのもの）を作成する過程で、まさにこの現象が発生しました。皮肉なことに、私たちが「実Excelで開いて修復ログが出ないことを確認する」ことを最重要ゲートとして文書化していた、その当のファイルで、そのゲートを省略した結果として起きた出来事です。

本稿は、この一件を実例として、「機械検証に合格した」という報告がなぜ安全の証明にならないのかを、実際に何が起きたかに沿って解説します。技術者向けの原因分析だけでなく、生成AIにファイル作業を依頼する立場の方が、次に同じような報告を受け取ったときに何を確認すればよいかも合わせてまとめました。

第1章：何が起きたか――「合格」のすぐあとに届いた修復ログ

経緯を整理すると、次のような順序でした。

1. 生成AIが、既存のExcelファイル（すでに6つのシートに正式な「テーブル」機能とオートフィルターが設定済みだった）に対して、見出し行の固定・印刷設定などの改善を加えた。

2. 作業後、生成AI自身が「ファイルの再読み込み」「ZIP構造の検査」「数式の再計算」という3種類の機械検証を実行し、いずれも異常なしと報告した。

3. ファイルを受け取った担当者が、実際にMicrosoft Excelで開いたところ、「エラーが検出されました」という警告が表示され、「はい」を選ぶと自動修復が実行された。

4. 修復ログ（recoveryLog）には、6つのシートすべてで「テーブル」と「オートフィルター」が削除された旨が記録されていた。

ファイルは一見、正常に開けます。数字も文字も欠けていません。しかし、絞り込みボタンも、テーブルとしての機能も、6シート分すべてが静かに失われていました。エラーメッセージを読み飛ばして「開けたから大丈夫」と保存してしまえば、この欠落に気づく機会はそのまま失われます。

第2章：なぜ「検証済み」のはずのファイルが壊れたのか

原因を一つずつ遡ると、単一の不具合ではなく、複数の判断が積み重なって起きたことがわかりました。

①「オートフィルターがない」という判定が、そもそも不完全だった

Excelのオートフィルターには、少なくとも2つの実装があります。ワークシート単体に設定する素朴な絞り込みと、正式な「テーブル」機能（内部的にフィルターを持つ構造化オブジェクト）です。前者の有無だけを確認するプログラムでは、後者としてすでに絞り込み機能が実装されている状態を「未設定」と誤判定します。今回、まさにこの誤判定が起点になりました。

②「ないなら追加しよう」が、既存の定義と衝突した

①の誤判定に基づき、すでにテーブルとして絞り込み範囲が定義済みの範囲に対して、ワークシート単体のオートフィルターを重ねて追加しました。同じセル範囲に対して、構造化されたテーブル側の定義と、単純なワークシート側の定義が二重に存在する状態です。少なくとも今回使用したExcelは、この状態を修復対象として扱いました。この重複がOffice Open XML（ECMA-376）の該当条項で明確に禁止されているかどうかまでは、本稿では確認できていません。確実に言えるのは「Excel自身の検証ロジックが、この状態を正常と認めなかった」という観測事実です。

③「数式を再計算しないといけない」というルールが、別の副作用を生んだ

ファイルに数式が含まれる場合、値のキャッシュを最新化するための再計算が必要です。これ自体は妥当な手順ですが、その再計算に、Excel本体ではない別の表計算エンジンを使いました。このエンジンは数式の再計算はできても、テーブル定義をExcelと完全に同一の形式で書き戻す保証はありません。実際に該当ファイルを調べたところ、6つのテーブル定義のうち最も大きいものは約2,962バイトから779バイトへ、7割以上小さくなっていました。単なる整形の違いではなく、構造の一部が失われた形跡です。

④ 3種類の機械検証は、いずれもExcel本体の検証基準そのものではなかった

ファイルの再読み込みが成功する、ZIPとして展開できる、数式の再計算でエラーが出ない――このどれも、ファイルとして最低限「壊れていない」ことしか保証しません。二重に定義されたテーブルとオートフィルターの組み合わせが、Excel自身の検証ロジックとしては不正である、という判定は、これら3つのどの検証にも現れませんでした。実際にファイルを開いて確かめる4つ目の工程だけが、この種の不整合を検出できました。

第3章：見落とされやすい5つの死角

この一件を振り返って洗い出した、生成AIによるファイル編集で特に見落とされやすい死角を、5つにまとめます。

1. 「機能がない」という判定は、確認した実装方法の数だけの確からしさしか持たない：同じ機能（今回で言えばオートフィルター）が複数の実装方法で存在しうる場合、一つの方法だけを見て「ない」と判定するのは早計です。既存ファイルを編集する前に、関連する既存の構造物（テーブル、名前付き範囲、入力規則など）を機能名ではなく実体として棚卸しする必要があります。

2. 「足りないものを足す」は、常に安全な操作とは限らない：追加しようとしている機能が、実は別の形ですでに存在していないかを、追加の直前に確認する一手間が必要です。特に同じセル範囲に対する重複定義は、多くのファイル形式で想定外の状態になります。

3. 「本家ではない実装」を検証工程に挟むと、検証と副作用が同時に起きうる：数式の再計算やファイル変換のために、対象アプリケーション本体ではない別のソフトウェアを経由させることは珍しくありません。ただし、そのソフトウェアが検証したい対象（今回のケースなら数式）以外の要素（テーブル定義）にどこまで忠実かは、別問題として確認する必要があります。

4. 複数の機械検証が「異常なし」でも、合算して「安全」にはならない：ファイル再読み込み・構文検査・再計算という3つの検証は、互いに異なる種類の不具合しか検出できません。3つとも通過したという報告は、「3種類の不具合がなかった」以上の意味を持たず、4つ目の不具合の不在を保証しません。

5. 修復ログは、能動的に確認しない限り目に入らない：Excelは多くの場合、警告を出したうえで自動修復を行い、ユーザーが「はい」を押せばそのまま開けてしまいます。修復ログ自体は保存されますが、参照しない限り「何が削除されたか」は誰にも気づかれません。開けたことと、無傷であることは別の話です。

第4章：現場で使える確認ポイント

技術に詳しくない担当者でも、次の点を確認するだけで多くの見落としに気づけます。

1. 納品前に、実際に対象アプリケーションで開いているか：ファイル再読み込みや構文検査は、対象アプリケーション本体の検証ロジックの代わりにはなりません。最終確認は必ず実物のアプリケーションで行い、警告バーやポップアップが一切出ないことを確認してください。

2. 「検証しました」と言われたら、何を、どこまで検証したかを尋ねる：「エラーは出ませんでした」という報告は、どの検証エンジンで確認したかによって意味がまったく異なります。対象アプリケーション本体での開封・保存・再度の開封まで含まれているかを、具体的に確認してください。

3. 既存の高度な機能がある場合は、編集前に一覧化してもらう：テーブル、名前付き範囲、入力規則、条件付き書式、外部リンク、マクロなど、見た目には現れにくい機能を編集前に列挙し、編集後にすべて残っているかを照合する一手間が、事故を防ぎます。

4. 別のソフトウェアを経由する工程があるかを確認する：数式の再計算やファイル形式の変換に、対象アプリケーション本体ではない別のソフトウェアが使われていないか。使われている場合、その工程の前後で構造上の変化がないかを別途確認してください。

5. 修復ログの有無そのものを、完了条件に含める：「開けること」ではなく「修復ログが一件も出ないこと」を納品条件にしてください。修復ログが出た場合は、その場で一つだけ直して再配布するのではなく、原因を切り分けたうえで検証をやり直す必要があります。

第5章：役割別チェックリスト

生成AIにファイル編集をさせる開発者・実装者の方へ：既存ファイルを編集する前に、対象範囲に既存の構造化オブジェクト（テーブル等）がないかをプログラムで確認する処理を、必ず組み込んでください。数式再計算のために本家以外のエンジンを使う場合は、そのエンジンが書き戻した部分（特にテーブル・図形・条件付き書式など）のファイルサイズやXML構造を、処理前後で比較する検査を加えることをおすすめします。そして、どれだけ機械検証を積み重ねても、最終ゲートは必ず対象アプリケーション本体での開封・保存・再開封にしてください。自己点検の例：「今回の変更は、対象アプリケーション本体で一度も開かずに納品されていないか」「機械検証は何種類あり、それぞれ何を検出できて、何を検出できないと言えるか」。この2つに即答できない場合、見直しの優先度は高いと考えてよいでしょう。

生成AIにファイル作業を依頼する実務担当者・管理者の方へ：「検証済みです」という報告を受け取ったら、「具体的にどのソフトウェアで、どの段階まで確認しましたか」と一言尋ねてください。質問の例：「このファイルは、実際にExcel（または対象のアプリケーション）で開いて、保存し、もう一度開き直しましたか」「編集前にあった機能（絞り込み、表機能、入力規則など）は、編集後にすべて残っていることを、どうやって確認しましたか」。具体的な工程が答えとして返ってくるかどうかで、成果物の信頼度をおおむね判断できます。

第6章：チェックの使いどころ

依頼前：生成AIやツールにファイル編集を任せる契約・依頼をする段階で、第4章の確認ポイントをそのまま質問リストとして使ってください。「実際のアプリケーションで最終確認する工程が入っているか」に明確に答えられない依頼先には、追加の確認を自分たちで用意する前提で臨む必要があります。

納品直前：機械検証がすべて通過したという報告を受けた直後こそ、最も気が緩みやすい瞬間です。ここで実際にアプリケーションを開く一手間を省略しないことが、今回のような事故を防ぐ最後の砦になります。

運用開始後の定期点検：一度は正しく検証されたファイルでも、後から機能が追加されるたびに、新しい構造化オブジェクトと既存の設定が衝突するリスクが積み重なります。ファイルを更新するたびに、簡易な機械検証だけで済ませず、実アプリケーションでの最終確認を習慣にすることをおすすめします。

おわりに：明日からできる3つのこと

第一に、生成AIから「検証済みです」という報告を受け取ったら、その検証が何種類あり、それぞれ何を検出できるものかを一度言葉にしてもらってください。第二に、既存ファイルを編集する依頼をするときは、既存の高度な機能（テーブル、入力規則、外部リンクなど）を編集前に一覧化するよう求めてください。第三に、どれだけ機械検証が「合格」でも、最終的に実物のアプリケーションで開いて保存し直すまでは「完了」と呼ばないでください。

生成AIがファイルを速く、大量に作れるようになったからこそ、検証もまた「速く済ませられるもの」だと錯覚しやすくなります。今回の一件は、その錯覚が実際に自分たちの手元で起きた記録です。層ごとに、工程ごとに、小さな確認を省略しないことが、静かに機能が失われる事態を防ぐ、いちばん現実的な方法だと考えています。

出典

類似の症状が報告された事例（MicrosoftがホストするコミュニティQ&Aフォーラムへの一般ユーザーの投稿。回答者自身、元ファイルを確認できないため原因は未確定としており、本稿の原因説を裏づける一次資料ではありません。あくまで「同様の修復が他でも起きている」という参考情報です）
https://learn.microsoft.com/en-us/answers/questions/5086587/microsoft-excel-365-repairing-my-excel-template-an

Office Open XML（ECMA-376）の公式規格情報。テーブル・オートフィルターがファイル内部で独立した部品として定義されていることの根拠
https://ecma-international.org/publications-and-standards/standards/ecma-376/

本文中で紹介した修復ログは、本記事の執筆者（生成AI）自身が、実際の作業中に生成し、依頼者から実際に共有されたものです。ファイル名・日付以外は原文の記載内容をそのまま引用しています。テーブル定義のバイト数比較（約2,962→779バイト等）は、同じ作業内で執筆者自身がファイルを直接調査して得た数値です。第2章で述べた①〜④の経緯は、この一件について、処理の各段階のファイルを直接比較する形で執筆者自身が追跡した結果であり、一般的なOOXML実装やExcel全般についての普遍的な主張ではありません。特に②の「OOXMLの仕様上の妥当性」については、規格書の該当条項を直接確認したものではなく、「Excel自身がこの状態を修復対象として扱った」という観測事実にとどまります。

なお、この追跡は執筆時点の作業記録に基づくものであり、読者が独立に検証できる形（各段階のファイルSHA-256ハッシュ、使用アプリ・バージョン、実行コマンド、XML差分、recoveryLog原本を並べた証拠表など）では別途保存していません。したがって本稿は、再現可能な証拠一式を伴う技術検証記事ではなく、一件の実務インシデントを執筆者本人の視点でまとめた記録として読んでいただくことを想定しています。

本記事は公開情報および筆者自身の作業記録に基づく要約です。確認できなかった事項については断定を避けています。

本記事は生成AIを用いて作成しました。