この​記事で​分かる​こと

  • 財務モデルのファイル名に持たせるべき5つの要素と、事故につながる命名の悪い例
  • バージョン番号(メジャー・マイナー)とステータス表記の実務的な使い分け
  • Excelの公式機能「Spreadsheet Compare(Inquire)」で2つのファイルの中身を突合する具体的な手順
  • Spreadsheet Compareが使えない環境(Mac版・Web版・標準エディション)での代替運用

結論:ファイル​名の​秩序と​中身の​差分、​両方が​なければ​「どこが変わったか」は​分からない

財務モデルのバージョン管理は、2つの層に分けて考える必要があります。1つはファイル名・保存場所の秩序で、「今どれが最新か」を一意に決める層です。もう1つは中身の差分比較で、「前の版から具体的に何が変わったか」を突き止める層です。前者だけでは「最新のファイルは分かるが、前の版と何が違うのかは分からない」状態になり、後者だけでは「何が変わったかは分かるが、そもそもどのファイルを比較すればよいのか迷う」状態になります。本記事は、この2層をそれぞれどう設計し、Excelの標準機能でどう突合するかを実務手順として扱います。

前提の出典を追跡する仕組み(Source Mapping)とChange Logシートの基本的な型は財務モデルの​Source Mapping・​Audit Trailで扱っており、本記事はその続編にあたります。あちらがモデル内部の「前提の根拠」を扱うのに対し、本記事はファイルという単位でのバージョン管理と、版と版の間の差分を機械的に検出する方法に焦点を当てます。書式や色分けのルールは財務モデルの​書式規律を、レビュー後の引き継ぎ作法はモデルレビューと​引き継ぎの​作法を、それぞれ参照してください。

バージョン​管理が​崩れると​何が​起きるか:現場で​起きがちな​事故パターン

複数人が同じ案件のモデルを並行して触る現場では、ファイル管理が崩れる典型パターンがいくつかあります。メールやチャットで「モデル_最新版.xlsx」を送り合ううちに、受け取った側がローカルで手直しして送り返し、送信元と受信側でどちらが最新か分からなくなる。クラウドストレージの同期が競合し、同じファイルが「(1)」付きで複製される。投資委員会(IC)の直前になって、手元のファイルが本当に最終確認済みの版なのか自信が持てなくなる。いずれも珍しい話ではありません。

こうした事故の根はほぼ共通していて、ファイル名だけを見て中身の違いを判断しようとしていることにあります。「_v2」「_最新」「_修正後」といった表記は、人間が目で見て何となく順序を推測する手がかりにはなっても、実際にどのセルの数式や前提値が変わったのかは教えてくれません。この種のリスクは一般にスプレッドシートリスクと呼ばれる領域の一部であり、ファイル単位のバージョン管理はその入り口にあたります。次の章から、ファイル名の設計とバージョン番号の使い分けを具体的に見ていきます。

ファイル​命名規則の​設計:​5つの​要素で​「今どれが最新か」を​一意に​する

ファイル名に持たせるべき要素は、案件・チームによって多少の増減はあっても、基本形は次の5つに集約できます。①案件コード(社名を直書きしない識別コード)/②モデル種別(3表・LBO・DCF等の略称)/③バージョン番号(メジャー.マイナー)/④保存日(YYYYMMDD)/⑤ステータス(Draft/Review/Final等)です。

図1:ファイル命名規則の5要素と良い例・悪い例 ①案件コード 社外に漏れても 案件が特定されない 識別コードにする この例 ALPHA ②モデル種別 3表・LBO・DCF等の モデル種類を 短縮表記する この例 3SS(三表) ③バージョン メジャー.マイナーの 2階層番号 (次章で詳説) この例 v2.1 ④保存日 YYYYMMDD形式で 保存した日付を 明示する この例 20260820 ⑤ステータス Draft/Review/ Finalの3段階で 進捗を明示する この例 Review 良い例(5要素を過不足なく含む) ALPHA_3SS_v2.1_20260820_Review.xlsx 悪い例(バージョン・日付・ステータスの区別がなく、何が最新か判断できない) モデル_最新版_修正2_これで確定.xlsx → 「最新」「確定」は書いた本人の主観であり、後から見た人には版の順序も日付も分からない
図:ALPHA・3SS・​v2.1等は​説明用の​仮の​値です。​5要素を​アンダースコアで​連結すると、​ファイル​名だけで​版の​順序と​進捗状況が​一意に​読み​取れます。

※上記のファイル名例は説明用の仮設例です。案件コード・数値・日付は架空のものであり、実在の案件を示すものではありません。

案件コードは社名や案件を直接連想させない記号にするのが安全です。案件が外部に漏れることを避けるだけでなく、メールの誤送信や共有フォルダの権限設定ミスがあった場合の被害も抑えられます。モデル種別は、社内で使う略称を統一しておけば十分で、「3SS」「LBO」「DCF」のように3〜4文字に収めると、後続のバージョン番号や日付と並べたときに読みやすくなります。

バージョン​番号の​付け​方:メジャー・​マイナーと​ステータス​表記の​使い分け

バージョン番号は、前章で触れたSource Mapping・Audit Trailで扱ったChange Logシートの版番号と、ファイル名の版番号を必ず一致させます。ここがずれると、Coverシートを見ても「このファイルが本当に最新か」を判断できなくなり、命名規則を整えた意味が失われます。番号の刻み方には、次のような実務的な目安があります。

段階 バージョン表記 ファイル名のステータス 典型的なタイミング
初稿作成v0.1〜v0.9Draftモデリングプランに沿って骨組みを組む段階
レビュー提出v1.0Review上司・チームレビューに初めて回す
軽微な前提修正v1.1、v1.2…Review(継続)ヒアリング反映・数値の微修正
意思決定用に確定v2.0FinalIC提出・契約前提の確定等の節目
確定後の改訂v2.1〜Final(改訂)IC指摘の反映・契約条件変更の反映

※以下は説明用の仮設例です。段階・タイミングの区分は一般的な実務慣行を基にした説明であり、特定案件の実例ではありません。

ポイントは、マイナー番号の刻みは軽微な修正、メジャー番号の繰り上げは意思決定の節目という原則を、チーム内で明文化しておくことです。原則がないと、人によって「メジャーを上げるべき変更」の基準がばらつき、結局ファイル名だけでは版の重みが分からなくなります。用語としてのバージョン管理の定義はモデルの​バージョン​管理もあわせてご覧ください。

フォルダ​運用と​クラウドの​バージョン​履歴の​併用

ファイル名の秩序に加えて、フォルダ構成も版の混乱を防ぐ役割を持ちます。基本形は「作業中(Working)」「提出済み(Submitted)」「アーカイブ(Archive)」の3階層に分け、Finalステータスに達したファイルはSubmittedへ移動、次の版の作業はWorkingで続ける、という運用です。Submittedフォルダの中身は、後から誰かが誤って上書き保存しないよう、読み取り専用属性を付けるかPDFでも並行保存しておくと安全です。

OneDriveやSharePointでファイルを管理している場合は、Microsoft公式のバージョン履歴機能も併用できます。ファイルを右クリックして「バージョン履歴」を選ぶと、過去に保存された版の一覧が表示され、必要な版を選んで復元できます。OneDriveの既定では、ファイルのバージョン履歴は30日間保持されると案内されています(組織の管理者が無効化している場合は利用できません)。この機能は「うっかり上書きしてしまった直前の状態」を取り戻す保険としては有効ですが、後述するように2つの版の中身がどう違うかを一覧で示す機能ではない点には注意が必要です。

命名規則だけでは​分からない​こと:​「中身の差分」を​確認する​必要性

ここまでのファイル名・フォルダの秩序は、「今どれが最新か」「過去の状態に戻せるか」を担保しますが、「前の版から具体的にどのセルが変わったのか」までは教えてくれません。この問いに答えるには、2つのファイルを実際に突き合わせる作業が必要です。典型的には次の3つの場面で必要になります。

複数アナリストの並行編集をマージする場面:同じモデルを分担して触った後、誰がどこを変更したのかを一つずつ確認しないまま統合すると、意図しない上書きが起きます。他人から受け取ったモデルをレビューする場面:前回渡された版と今回の版を比較すれば、修正依頼した箇所以外に手が入っていないかを確認できます。IC提出直前の最終確認の場面:直前のドラフトと提出用ファイルの間に、意図しない変更が紛れ込んでいないかを最終チェックする場面です。数式そのものの追跡はExcelの​数式監査の​技術で扱うセル単位のトレースが有効ですが、これは1つのファイルの中で数式のつながりを追う技術です。ファイルとファイルの間で何が変わったかを機械的に洗い出すには、別のアプローチが必要になります。

Spreadsheet Compare​(Inquire)の​使い​方:有効化から​比較結果の​見方まで

Excelには、2つのブックの差分を検出するMicrosoft公式のツールとして「Spreadsheet Compare」(Inquireアドイン経由での呼び出しも可能)が用意されています。数式・値・セル書式・マクロ(VBA)の違いを、シートごと・セルごとに検出して色分け表示する機能です。ただし、このツールはMicrosoft 365 Apps for enterprise等、一部の法人向けエディションのExcel for Windowsに限定されており、Mac版・Web版・一般的な家庭/個人向けエディションでは利用できません。まず自分の環境で使えるかどうかを、次の手順で確認します。

手順 操作
①アドインを有効化Excelの「ファイル」→「オプション」→「アドイン」を開き、「管理」欄で「COMアドイン」を選択して「設定」をクリック。一覧の「Inquire」にチェックを入れてOK
②起動リボンに表示された「Inquire」タブから「Compare Files」を選択(スタート画面から単体アプリのSpreadsheet Compareを起動し、「Home」タブの「Compare Files」から始めることも可能)
③比較対象を選ぶ青いフォルダアイコンで旧バージョン(Compare側)、緑のフォルダアイコンで新バージョン(To側)のファイルを選択
④比較項目を選ぶ左ペインのチェックボックスで、数式・値・セル書式・マクロ等、比較したい項目を選択(すべて選ぶことも可能)
⑤結果を確認左右2ペインに両ファイルのシートが並んで表示され、差分箇所が色分けされる(入力値の変更は緑系、計算値の変更は別の色で表示)。下部ペインでセルの詳細と凡例を確認できる

比較結果は、必要に応じてエクスポートしたりコピーしたりできるため、「前版からの変更点」をそのままレビューコメントやIC説明資料に転記する用途にも使えます。前提一覧​シートのSource列を整えていれば(Source Mapping・​Audit Trail参照)、Spreadsheet Compareで検出した差分セルと突き合わせることで、「どの前提が」「いつの版で」「どう変わったか」までを一貫して説明できるようになります。

Spreadsheet Compareが​使えない​環境での​代替運用

法人向けエディション以外のExcelを使っている場合や、Macで作業している場合は、Spreadsheet Compareそのものは使えません。この場合でも、次のような運用でカバーできます。

クラウドのバージョン履歴で見た目を比較する:OneDrive・SharePointの「バージョン履歴」から過去の版を開き、現行版と並べて目視で確認する方法です。数式単位の厳密な差分検出はできませんが、レイアウトや数値の大きな変化には気づけます。数式をテキスト化して突き合わせる:Excel標準の関数を使い、旧版・新版それぞれのシートで数式を文字列として抜き出し、隣り合う列で一致・不一致を確認する自作の点検シートを用意する方法です。値のみを比較したい場合は、対応するセル同士をIF関数で照合し、不一致のセルにフラグを立てる簡易シートでも代用できます。モデルの完全性をチェックサムで検証する:ファイル全体の改変有無を大まかに確認する方法として、モデルチェックサムの​設計の考え方も参考になります。

どの方法も、Spreadsheet Compareほどの網羅性はありません。だからこそ、法人向けエディションが使える環境では積極的にSpreadsheet Compareを使い、使えない環境では「命名規則とChange Logの精度をより厳密にする」ことで補う、という使い分けが現実的です。

命名規則×差分比較を​組み込んだ​運用フロー

ここまでの要素を、1つの運用フローとして組み合わせると次のようになります。

図2:命名規則×差分比較の運用フロー ①編集・保存 5要素の命名規則で ファイル名を確定 ②Change Log記載 Ver・変更内容・ 理由・影響範囲を記録 ③Spreadsheet Compareで前版と比較 (使えない環境は代替) ④レビューへ 差分を示しながら 変更点を説明 要修正の場合は版を上げて①へ ⑤Final確定 メジャー版を確定し Archiveへ移動 運用のポイント ファイル名のバージョン番号・Change Logの版番号・Spreadsheet Compareで比較した2ファイルの版番号を、常に一致させる
図:編集→記録→比較→レビュー→確定の​サイクルを​回す​ことで、​「今どれが最新か」と​「何が変わったか」の​両方に、​いつでも​答えられる​状態を​保てます。

命名規則やChange Logを、自分のモデルにどう組み込むか迷ったら

バージョン管理のルールは頭で理解しても、実際に手を動かしながら三表モデルに組み込んでみないと定着しにくいものです。モデリングラボでは、前提一覧シートやCoverシートの設計を含めた実践演習ができます。

→ モデリングラボを​見る

よく​ある​質問​(FAQ)

バージョン​番号は、​ファイル名と​Cover​シートの​どちらで​管理すれば​よいですか。

両方に​同じ​番号を​持たせ、​常に​一致させるのが​基本です。​ファイル名の​番号は​「どのファイルを開くべきか」を、​Cover​シートの​番号は​「開いたファイルが本当にその版か」を​確認する​役割を​持ちます。​片方だけ​更新して​他方を​忘れると、​かえって​混乱の​原因に​なります。

Spreadsheet Compareが​使えない​環境では、​差分比較を​諦めるしか​ありませんか。

網羅性は​落ちますが、​諦める​必要は​ありません。​クラウドの​バージョン​履歴で​過去の​状態を​開いて​目視確認する、​数式や​値を​テキスト​化して​自作の​点検シートで​突き​合わせると​いった​代替運用で​カバーできます。​詳しくは​本文の​代替運用の​章を​参照してください。

Excelの​財務​モデルに、​ソースコード​管理​ツールのような​仕組みを​使うべきですか。

Excel​ファイルは​バイナリ​形式であり、​行単位の​テキスト​差分を​前提とした​仕組みとは​相性が​よく​ありません。​本記事で​扱った​命名規則・​Change Log・​Spreadsheet Compareの​組み​合わせが、​Excelと​いう​形式に​即した​現実的な​代替に​なります。

何世代分の​バージョンを​保管しておくべきですか。

最低限、​各メジャーバージョン​(意思決定の節目に確定した版)は​案件終了まで​保管します。​マイナーバージョンの​中間​ファイルまですべて​残すかは、​フォルダ​容量や​チーム​方針次第ですが、​IC提出用に​確定した​版だけは​削除せず​必ず​Archiveに​残します。

まとめ

財務モデルのバージョン管理は、案件コード・モデル種別・バージョン番号・保存日・ステータスの5要素を持つファイル命名規則と、メジャー・マイナーの使い分けによるバージョン番号の運用で「今どれが最新か」を一意にすることから始まります。それだけでは分からない「前の版から何が変わったか」は、Microsoft公式のSpreadsheet Compare(Inquire)で数式・値・書式・マクロの差分を機械的に検出することで補います。法人向けエディションでこの機能が使えない場合も、クラウドのバージョン履歴や自作の点検シートで代替できます。ファイル名の秩序・Change Logの記録・差分比較の3つを一つのサイクルとして回すことが、複数人が触るモデルを事故なく運用する土台になります。

出典・参考​(2026年8月31日確認)

※本記事は教育目的の一般的な解説であり、法務・税務・投資助言ではありません。設例は理解のための仮設例です。