Teamsで共有して運用しているOffice Scriptsは、見た目は「チームの資産」に見えても、実体が作成者のOneDriveに残っているケースがあります。退職などで作成者アカウントが削除されると、スクリプトも失われて業務が止まることがあるため、保存先と運用ルールを先に整えておくのが安全です。
Office ScriptsとTeams共有の“落とし穴”
Office Scriptsは、Excel for the web(ブラウザー版Excel)で使える自動化機能で、TypeScriptで処理を記述します。現場では「Teamsのチームで共有しているから安心」と考えがちですが、Teamsはあくまで共有の入口であり、スクリプトの“本体(コード)”がどこに保存されているかは別問題です。
このズレが起きやすいのは、Office Scriptsの保存先が大きく次の2系統に分かれるためです。
- 個人領域(OneDrive):作成者の「My scripts」相当。共有は“アクセス権を渡す”形になりやすい
- チーム領域(SharePoint):Teamsに紐づくチームサイト(SharePoint)のドキュメント ライブラリ側。チーム資産として保持される
| 見た目(現場の認識) | 裏側(実体) | アカウント削除の影響 |
|---|---|---|
| Teamsで共有しているから大丈夫 | 作成者のOneDriveに保存されたまま、閲覧・実行権だけ共有 | 作成者OneDriveが消えると、参照元がなくなり失われる恐れ |
| Teamsのファイル(SharePoint)に置いている | Teamsチームサイト(SharePoint)に保存 | 個人削除の影響を受けにくく、保持はSharePoint運用に従う |
結論:生存性を左右するのは「保存先」
質問のポイントは「Teamsで共有しているか」よりも、スクリプトの実体が個人のOneDriveか、チームのSharePointかです。作成者のアカウント削除は、通常そのユーザーのOneDrive領域の削除(または保持期間経過後の削除)につながるため、個人OneDrive置きのスクリプトは巻き添えになりやすい、という整理になります。
| 保存先 | 作成者アカウント削除時 | 復旧の余地 | 長期運用の向き不向き |
|---|---|---|---|
| OneDrive(個人) | 消失する可能性が高い(保持期間が切れると確定) | 保持期間内なら管理者が救出できる場合あり | ×(属人化しやすい) |
| SharePoint(Teamsチームサイト) | 基本的に消えない(個人削除の影響が小さい) | サイト運用・保持ポリシー次第で復旧しやすい | ◎(チーム資産化できる) |
まずやるべき:いまのスクリプトはOneDriveかSharePointかを判定する
対策を決める前に、現状がどちらなのかを短時間で判定します。ここが曖昧だと、移管したつもりでも実体が動いていないことがあります。
| 確認ポイント | OneDrive(個人)寄りのサイン | SharePoint(チーム)寄りのサイン |
|---|---|---|
| スクリプトの分類 | 「My scripts」側にしか出てこない | チーム(グループ)側のスクリプトとして扱える |
| 利用者の実感 | 作成者がいないと新規作成・修正が止まる | チームのメンバー(適切な権限)が修正できる |
| 保管の導線 | 「共有したリンク」から辿っているだけ | Teamsの「ファイル」→SharePointのライブラリから辿れる |
判定が難しい場合は、スクリプトのコードを一度バックアップしてから移管作業に入るのが安全です。バックアップを取っておけば、最悪でも“再作成”が可能になります。
Office Scriptsの共有パターンを分けて考える
運用現場では「共有」と一言で言っても、実態が異なることが多いです。よくあるパターンを分けると、何を直せば良いかが見えてきます。
個人スクリプトを“共有”して回している(危険度:高)
Excel for the webのOffice Scriptsで作成したスクリプトが、作成者の「My scripts」領域に保存され、Teamsのメンバーに対して参照・実行を許可して使っている状態です。この場合、スクリプトの“本体”はあくまで作成者の個人領域にあるため、作成者アカウント削除で失われやすくなります。
チーム(SharePoint)側にスクリプトを置いている(危険度:低)
Teamsに紐づくSharePointサイト(チームサイト)のドキュメント ライブラリにスクリプトを保存し、チームメンバーが利用する形です。スクリプトはチーム資産になり、作成者が退職してもサイトが残る限りは保持されます。
“バックアップ”としてコードを保管し、再取り込みできるようにしている(危険度:中)
運用上、どうしても個人領域で作る必要がある場合でも、スクリプトのコードを別場所に保管し、再作成・再取り込みできるようにしておく方法です。たとえば、スクリプトのコードをテキストとしてSharePointに保管したり、リポジトリ(Git)でバージョン管理したりします。個人OneDriveが消えても、コードが残っていれば復旧が現実的になります。
アカウント削除で実際に起きるトラブル例
「消えるかどうか」だけでなく、現場では“どの形で困るか”が重要です。影響範囲をイメージできるよう、よくある症状をまとめます。
| 症状 | よくある原因 | まず確認するポイント | 緊急対応 |
|---|---|---|---|
| Teamsからスクリプトが見えなくなった | 参照元が作成者OneDriveで、削除・権限剥奪が発生 | スクリプトの保存先がOneDriveかSharePointか | 保持期間内なら管理者にOneDrive復元を依頼 |
| Power Automateからスクリプト実行が失敗する | 実行アクションが個人スクリプトを参照、接続が無効化 | フローの所有者・接続・参照スクリプトの所在 | スクリプトをSharePoint側へ移管し、フロー参照を差し替え |
| 「このスクリプトは利用できません」など権限エラー | 共有は残っていても所有者不在で権限解決できない | 共有設定と実体の保管場所 | コードを回収して別スクリプトとして再作成 |
| 修正したいのに、誰も編集できない | 作成者が退職し、権限も知識も引き継がれていない | 保守担当が複数いるか、台帳があるか | 「修正できる状態」を先に作る(台帳・バックアップ・権限) |
最優先の予防策:SharePoint(Teamsチームサイト)へ移して“チーム資産化”する
長期運用で一番強いのは、スクリプトの実体をTeamsに紐づくSharePoint側へ置くことです。これにより「個人OneDriveの寿命」と切り離して運用できます。
チーム資産化のメリット
- 退職・異動に強い:作成者のアカウントが削除されても、スクリプトが残りやすい
- 権限管理が一元化しやすい:Teamsのメンバー管理=SharePointの権限管理と揃えやすい
- 保持ポリシーや監査の対象にしやすい:個人資産よりも組織ポリシーで守りやすい
移管前に決めておく運用ルール(ここで差が出る)
ただ移すだけだと、数か月後にまた同じ問題が起きます。最低限、次のルールだけは決めておくのがおすすめです。
| 項目 | 決める内容の例 | 狙い |
|---|---|---|
| 保管場所 | Teamsの「ファイル」直下に「OfficeScripts」フォルダを作り、必ずそこに置く | 探せる・引き継げる状態を作る |
| 命名規則 | [業務]_[対象]_[処理](例:経理_入金_整形) | スクリプト一覧が資産台帳として機能する |
| 責任者 | チーム内に保守担当を2名以上(異動リスクの分散) | “その人しか分からない”を防ぐ |
| 変更管理 | 修正したら履歴メモ(変更日・理由・影響範囲)を残す | 壊したときに戻せる |
移管の具体的な進め方(実務向け)
画面の表記は更新で変わることがありますが、考え方は「コードを回収 → SharePoint側で再登録 → チームで利用確認」です。失敗しにくい手順を、現場で使える粒度でまとめます。
- 現状棚卸し:Teamsで使っているスクリプトを洗い出し、「誰が作ったか」「どのExcelで使うか」「Power Automateで呼んでいるか」をメモします。
- コードを回収:各Office Scriptの中身(TypeScript)をコピーし、ひとまず安全な保管場所へ退避します(後述のバックアップ先に保存)。
- Teamsチームサイトに保管場所を用意:Teamsの「ファイル」タブからSharePointを開き、スクリプト管理用フォルダを作ります(例:
OfficeScripts)。 - SharePoint側でスクリプトを再登録:チームで共有したいExcel(SharePoint上のブック)をExcel for the webで開き、Office Scriptsとしてコードを貼り付けて保存します。保存先がチームサイト側になる状態を作ります。
- 実行確認:Teamsメンバーの別アカウントで実行できること、必要な権限でエラーにならないことを確認します。
- Power Automateを使っている場合は参照差し替え:フローで呼び出すスクリプトが新しいスクリプトを参照するように更新し、接続(コネクタ)もチーム運用に合わせます。
- 旧スクリプトの扱いを決める:すぐ削除せず、一定期間は旧版として残す、または「廃止」フォルダへ移して明示的に管理します。
ポイントは、「Teamsで共有できている」ことをもって移管完了としないことです。必ず「保存先がSharePointになっている」ことを確認してください。確認が難しい場合は、スクリプトの台帳(後述)に“保存先の場所(フォルダ名や管理用の説明)”を記録しておくと事故が減ります。
予防策その2:アカウント削除前に“置き場所(所有)”を移管しておく
現実には、急な退職・異動や、アカウントの停止が先に走るケースもあります。削除が決まった時点で「何から手を付けるか」を決めておくと、取りこぼしが減ります。
削除前チェックリスト(最低限)
| チェック項目 | 確認方法の例 | 対応 |
|---|---|---|
| スクリプトの保存先 | OneDrive(個人)か、SharePoint(チーム)か | OneDriveならSharePointへ移管を最優先 |
| 利用範囲 | Teams内だけか、他部署のフローでも使っているか | 影響範囲が広いほど“先に移す” |
| 自動実行の有無 | Power Automateや定期運用で実行していないか | 参照差し替え・接続見直しまでセットで |
| 保守担当の有無 | 修正できる人が複数いるか | 担当が1人ならサービスアカウント化を検討 |
予防策その3:削除後の救済に頼らない“バックアップ設計”を作る
「万一消えたら管理者が復元できるはず」という運用は、現場では事故になります。なぜなら、保持期間が短い/不明、依頼ルートが遅い、復元しても誰が回収するか曖昧、といった理由で取り戻せないケースがあるからです。そこで、スクリプトをコード資産として扱い、バックアップと変更履歴を持たせると安定します。
おすすめのバックアップ先
- Teamsチームサイト(SharePoint)の専用フォルダ:最も運用に乗せやすい。権限とメンバー管理が揃う
- Git(Azure DevOps / GitHub Enterprise など):変更履歴・レビュー・ブランチが使える。複数人開発に強い
- SharePointリストで台帳管理:スクリプト名、目的、対象ファイル、更新履歴、関連フローを一覧化できる
バックアップを“形だけ”にしないコツ
バックアップの成否は「復元できる形で残っているか」に尽きます。おすすめは、スクリプト1本につき最低限この3点をセットで残すことです。
- コード全文(貼り付けで復元できる)
- 用途と入力/出力の説明(何を壊すとどこに影響するか)
- テスト手順(誰でも動作確認できる)
| 残す情報 | 例 | 復旧時の価値 |
|---|---|---|
| 目的 | 請求書CSVを整形し、集計シートへ貼り付ける | “何のためのスクリプトか”がすぐ分かる |
| 対象ブック/シート | Teams/経理/ファイル/請求書/2025/… | 探す時間を削減できる |
| 前提条件 | ヘッダー行は1行目、列名は固定 | 仕様変更に気づける |
| 戻し方 | 旧版コードを貼り付けて保存(版番号を上げる) | 事故対応が早くなる |
削除後でも救出できる場合がある:管理者によるOneDrive復元の可能性
すでに作成者アカウントが削除されてしまった場合でも、テナントの設定や保持ポリシー次第では、管理者が削除ユーザーのOneDriveを一定期間保持していたり、一時的に復元できたりすることがあります。ここは組織の設定に依存するため断言はできませんが、「救出できる可能性があるうちに動く」ことが重要です。
復旧依頼を出すときに伝えると早い情報
- 削除されたユーザーのUPN(メールアドレス)
- スクリプトの名称一覧(分かる範囲で)
- 利用していたTeamsチーム名・チャネル名
- 関連するExcelファイルの保存場所(SharePointのライブラリ/フォルダ)
- Power Automateで呼んでいる場合はフロー名
復旧できた場合は、復元したOneDriveからスクリプトを回収し、SharePoint(チームサイト)へ移し替えるのが再発防止の王道です。救出が一度できても、同じ運用のままだと次の退職でまた起きます。
長期運用なら有効:専用アカウント(サービスアカウント)で管理する
異動・退職の頻度が高い部署ほど、スクリプトを個人名義で持つのはリスクになります。そこで、スクリプト管理専用のアカウント(例:部門の共有アカウント、サービスアカウント)を用意して、そのアカウントで作成・保管・共有する運用に切り替えると安定します。
サービスアカウント運用の注意点
- 多要素認証(MFA)と管理手順:誰がどのようにログインするか、監査可能な形で決める
- ライセンス:Office Scriptsを使うために必要なライセンス要件を満たす
- パスワード共有の禁止:共有パスワード運用は事故につながるため、管理者手順で安全に運用する
ただし、サービスアカウントは“最後の砦”としては強力ですが、理想はやはりSharePoint側に置いてチームで管理することです。サービスアカウントは「どうしても個人領域に寄る仕様・運用がある」場合に組み合わせると効果的です。
実務で使える:退職・異動に備えた運用テンプレ
最後に、現場でそのまま使えるように「いつ・誰が・何をするか」をテンプレ化します。人が変わっても回る形にしておくと、アカウント削除のたびに慌てなくて済みます。
| タイミング | やること | 担当 | 目的 |
|---|---|---|---|
| 平常時 | スクリプト台帳を更新(用途・保存先・関連フロー) | 運用担当 | 属人化を防ぎ、棚卸しコストをゼロに近づける |
| 平常時 | コードをSharePoint/Gitへバックアップ、変更履歴を残す | 開発者 | 消えても復元できる状態を保つ |
| 削除予定が判明 | 対象者のスクリプトを洗い出し、SharePointへ移管 | チームリーダー | 削除前に“実体”をチームへ寄せる |
| 削除直後 | 影響が出たフロー・運用を監視し、必要なら復元依頼 | 管理者/運用担当 | 止まる業務を最小化する |
| 復旧後 | 原因を記録し、ルール(保存先・命名・責任者)を修正 | 運用担当 | 再発防止を仕組みに落とす |
よくある質問
Teamsのチームに共有しているのに、なぜ「チームのもの」にならないのですか?
共有は“権限を渡す”だけで、実体の保存先が変わらないことがあるからです。スクリプト本体が作成者OneDriveにある状態だと、Teamsで見えていても根本は個人資産です。長期運用なら、実体をSharePoint側へ置く設計に切り替えるのが安全です。
SharePointに移したら、誰でも勝手に編集できて危なくないですか?
危ないのは「権限設計を決めないまま移す」ことです。チームの中でも編集者を限定し、実行だけできる人を増やす、という設計は可能です。少なくとも“編集担当を2名以上”にして、個人に依存しない体制を作るのが現実的です。
Power Automateで使っている場合、何に注意すべきですか?
フローは「どのスクリプトを参照しているか」と「どの接続(アカウント)で実行しているか」で壊れ方が変わります。個人アカウントの接続で回している場合は、アカウント停止・削除で即座に失敗することがあります。スクリプトの保存先だけでなく、フローの所有者・接続の運用もチーム運用に寄せるのが安全です。
まとめ
Teamsで共有しているOffice Scriptsがアカウント削除で消えるかどうかは、スクリプトの実体が作成者OneDriveにあるか、Teamsチームサイト(SharePoint)にあるかで決まります。個人OneDrive置きの運用は、退職・異動で高確率に事故が起きるため、長期運用ならSharePoint側へ移してチーム資産化するのが最優先です。あわせて、削除前の移管手順、バックアップ、サービスアカウントの使い分け、管理者復旧に頼り切らない運用テンプレまで整えておくと、Office Scriptsを安心して業務に組み込めます。

コメント