「マクロ入りのExcelを複数人で同時に編集したら、動きがおかしくなった」——この相談は珍しくありません。ネット上では「マクロがあると共同編集できない」という言い方も見かけますが、これは正確ではありません。
先に正確な結論を書きます(2026年8月時点、Microsoft公式ドキュメントに基づく)。
論点 | 公式の見解 |
|---|---|
.xlsm(マクロ有効ブック)の共同編集 | 対応している(.xlsx / .xlsm / .xlsb が対象形式) |
共同編集中のマクロの実行 | 問題ないとされている |
共同編集中のマクロ・VBAコードの編集 | 他のユーザーの作業を中断する可能性がある。共同編集していないときに行うよう推奨 |
SaveイベントをつかうVBA | BeforeSave / AfterSave 等で問題が発生する可能性を公式が明記 |
つまり「できない」のではなく、**「できるが、マクロの作りと運用によっては壊れる」**が正確な理解です。以下、公式情報の中身と、実務での対処を順に整理します。
前提: 共同編集が成立する条件
そもそもExcelの共同編集(コオーサリング)には条件があります。Microsoft サポートの公式ページによると、ファイルをOneDriveまたはSharePoint Onlineに保存し、Microsoft 365のサブスクリプション版Excelを使い、ファイル形式が .xlsx / .xlsm / .xlsb であること——この条件が揃って初めて同時編集が動きます。社内ファイルサーバー上のファイルや、買い切り版のExcelでは共同編集は機能しません。
ここで重要なのは、対象形式に.xlsmが明記されていることです。マクロが入っているだけで共同編集の対象外になる、ということはありません。
出典: Microsoft サポート「Excel ブックの共同編集を使用して同時に共同作業を行う」
Microsoft公式が明記している「マクロ×共同編集」の注意点
では何が問題になるのか。公式ドキュメントに書かれている注意点は大きく2つです。
① 共同編集中にマクロを「編集」してはいけない
Microsoft サポートの「Excel でのコオーサリングのベスト プラクティス」には、共同編集中にブックのマクロやVBAコードを変更すると、同時にブックを開いている他のユーザーの作業が中断される可能性があると明記されています。同ページは、VBA関数やマクロの実行は問題ないとしつつ、作成・編集は他のユーザーと共同編集していないときに行うことを推奨しています。
つまり「マクロを直しながら、他の人がデータを入れている」——中小企業の現場でよくあるこの状況が、公式に非推奨とされている使い方です。
② 保存イベント(BeforeSave / AfterSave)をつかうマクロは問題が起きうる
もう一段深い話として、Microsoft Learn(開発者向け公式ドキュメント)の「Excel での共同編集について」は、保存イベントや変更イベントをつかうマクロ・アドインについて、共同編集と自動保存の導入により問題が発生する可能性があると明記しています。「保存したら自動で転記する」「変更されたらログを残す」といった作り込みをしたマクロは、まさにこの類型に該当します。
出典: Microsoft サポート「Excel でのコオーサリングのベスト プラクティス」/ Microsoft Learn「Excel での共同編集について」
なぜ現場で「マクロが壊れた」が起きるのか
公式の記述を現場の言葉に翻訳すると、こうなります。
- 共同編集は「複数人の変更をリアルタイムに合成する」仕組みで、マクロは「1人がファイル全体を制御する」前提で書かれてきた仕組み。設計思想が違う2つを重ねている
- 誰かがマクロを実行して大量のセルを書き換えると、他の人の画面では「自分が触っていないのに値が変わっていく」状態になり、入力と衝突する
- 保存イベント連動のマクロは、自動保存(数秒ごとの保存)のたびに発火しうる設計になってしまう
「マクロのせい」でも「共同編集のせい」でもなく、組み合わせ方の問題です。だから対処も「どちらかを捨てる」ではなく、組み合わせ方を変えることになります。
実務での対処法3つ
対処1: 運用ルールで分離する(今日からできる)
- マクロの編集は、共同編集していない時間帯に行う(公式推奨そのまま)
- マクロ実行のタイミングを決める(例: 毎朝9時に担当者1人が実行。実行中は他の人は開かない)
- BeforeSave / AfterSave に依存するマクロは、ボタン実行型に書き換える
コストゼロで事故は減りますが、「ルールを守り続ける」ことに依存する点が弱点です。担当者が変わると崩れます。
対処2: 「同時に触るデータ」と「マクロが処理するデータ」を分ける
入力用のブック(マクロなし・共同編集)と、集計処理用のブック(マクロあり・1人で操作)を分離し、処理用ブックが入力用ブックを読みに行く構成にします。共同編集とマクロが同じファイルで同居しなくなるため、衝突の構造自体が消えます。ファイルが2つになる管理コストは増えますが、既存のVBA資産を活かしたまま安全にできる現実解です。
対処3: 「同時編集が前提の業務」は、仕組みごと見直す
そもそも複数人が同時に触ることが業務の前提なら、マクロを共同編集に耐えさせる努力よりも、同時編集を前提に設計された環境(Googleスプレッドシート+GAS、またはExcel+Officeスクリプト等)へ処理を移す方が、長期的には保守が楽になるケースが多いです。ただしこれは移行作業を伴うため、先に業務の棚卸しと標準化をやってからが鉄則です。動いているマクロの仕様を誰も説明できない状態で移行を始めると、必ず止まります。
まとめ
- .xlsmの共同編集は公式に対応している。「マクロがあると共同編集できない」は不正確
- ただしMicrosoft公式は、共同編集中のマクロ編集と保存イベント連動のマクロについて問題が起きうることを明記している
- 対処は「運用で分離」→「ファイルを分離」→「仕組みの見直し」の順で検討する。いきなりツール移行から入らない
当社リバレンスでは、マクロだらけで誰も触れなくなったファイルの棚卸し・整理から、業務に合わせた仕組みの再設計までを月額定額でお受けしています。「うちのこのファイル、どの対処が正解?」という段階のご相談だけでも構いません。サービス詳細はこちらからどうぞ。
本記事の公式見解はすべて2026年8月時点のMicrosoft サポートおよびMicrosoft Learnの公開ドキュメントに基づきます。仕様は変更される場合があるため、最新情報は公式ドキュメントをご確認ください。



