OneNote の Class Notebook で、これまで普通に使えていた「Distribute Page（ページ配布）」が突然エラーになり、授業の準備が止まってしまった――2025 年に入ってから、学校や企業の現場でこうした相談が急に増えています。本記事では、Web 版 OneNote（onenote.com）の「Uh Oh! It looks like something went wrong!」エラーを中心に、原因の切り分けと現実的な対処法を詳しく解説します。
OneNote Class Notebook の「Distribute Page」エラーの概要
発生している現象
Class Notebook を利用している先生・研修担当者のあいだで、次のような問い合わせが増えています。
- onenote.com（Web 版 OneNote）の Class Notebook タブ ＞ Distribute Page を押すと、画面に「Uh Oh! It looks like something went wrong!」と表示される。
- 同じパネルに表示されるはずの Report ボタンを押しても、何も起こらない。
- 1 年以上問題なく使えていたノートブックで、2025 年 8 月ごろから急に発生し始めた。
- 自分だけでなく、同じ組織内の他の教員や社員にも同じエラーが出ている。
Microsoft の Q&A コミュニティでも、2025 年 8 月以降、まったく同じ「Uh Oh! It looks like something went wrong!」と Report ボタンが効かないという相談が複数投稿されています。
このエラーは、ブラウザー側の一時的な不具合から Microsoft 365 サービス側の障害まで、原因が広範囲に渡るのがやっかいな点です。そこで本記事では、現場で今すぐ試せる対処と、組織単位での正式なエスカレーション方法をセットで整理します。
「Distribute Page」が止まると何が困るのか
- 授業の板書・ワークシートを一斉配布できず、授業開始が遅れる／最悪中止になる
- 社員研修や社内勉強会で、教材ページ配布を OneNote に統一している場合の影響が大きい
- 一部だけでも配布されているのか判断しづらく、生徒や受講者側の「届いていない」問い合わせ対応にも時間が取られる
特にリモート授業・ハイブリッド授業では、Class Notebook のページ配布が授業運営の基盤になっているケースが多いため、早めの切り分けと代替手段の確保が重要です。
なぜ急にエラーが出るのか？よくある原因パターン
「Uh Oh! It looks like something went wrong!」は、内部で何かに失敗したときに出る汎用エラーです。具体的には、次のような原因が重なっている場合がほとんどです。
| 状況 | 主に疑われる原因 | 優先して確認したいこと |
|---|---|---|
| 自分の PC だけで発生 | ブラウザーのキャッシュ破損／拡張機能／一時的なセッション不良 | プライベートウィンドウ・キャッシュ削除・別ブラウザー |
| 同じ組織内の複数ユーザーで発生 | Microsoft 365 側の一時障害／新しい不具合 | サービス正常性／管理センターのメッセージ／サポートチケット |
| 特定ノートブック・特定セクションだけで発生 | 権限設定・ノートブック構造・セクションのサイズや内容 | 他ノートブックで再現有無／ページサイズや添付ファイル有無 |
ブラウザー側の一時的な不具合・キャッシュ破損
Microsoft Q&A では、シークレットウィンドウ（プライベートブラウズ）では正常に Distribute Page が動作したという報告が複数あります。 これは、通常のブラウザーセッションに保存されているキャッシュや Cookie、拡張機能などが悪さをしている典型的なパターンです。
この場合、プライベートウィンドウで成功するかどうかが、ローカル環境起因かサービス起因かを見分ける重要なポイントになります。
拡張機能・セキュリティソフトの影響
広告ブロッカーやトラッキング防止系の拡張機能、企業向けのセキュリティソフトが、Class Notebook のスクリプトや通信をブロックしてしまうことがあります。
- ブラウザー拡張を一時的に無効化したら、急に配布できるようになった
- 社内プロキシやフィルタリングの設定変更後から突然エラーが出るようになった
こうしたケースでは、IT 管理者に協力を依頼して 対象 URL やドメインをホワイトリストに登録する必要があります。
Microsoft 365 サービス側の障害・仕様変更
2024～2025 年にかけて、教師コミュニティやフォーラムでは「ページ配布が『Waiting to start（開始待ち）』のまま動かない」「配布が途中で止まる」などの報告が継続的に見られます。
こうしたケースの多くは、クライアント側の操作ではどうにもならないサービス側の不具合である可能性が高く、個人でできることは切り分けまでです。管理センターのサービス正常性や、公式サポートへの問い合わせが重要になります。
権限やノートブック構成の問題
Class Notebook は、セクションごとに生徒の閲覧・編集権限が複雑に管理されています。権限が通常と異なるセクション（例：生徒は閲覧のみ）に対して配布を試みると、クライアント側でうまく解釈できずエラーになるケースも指摘されています。
特定のノートブックやセクションでのみエラーが出る場合は、別のノートブックやセクションで配布できるかをテストし、権限や構造に起因するかどうかを確認してみましょう。
まずは自分でできる対処手順（先生・現場担当者向け）
現場の先生・研修担当者が自力で取り組める基本的な対処を、重要度順に整理しました。いずれも Microsoft のコミュニティ回答や公式サポート記事でも推奨されている方法です。
| 手順 | 目的・効果 | ポイント |
|---|---|---|
| 1. プライベート／シークレットウィンドウで再試行 | キャッシュや拡張機能の影響を一時的に切り離す | ここで成功するかどうかで、原因の方向性が大きく変わる |
| 2. 通常ブラウザーのキャッシュと Cookie を削除 | 破損したキャッシュや古いセッション情報をリセット | 一度サインアウトしてからキャッシュ削除すると効果的 |
| 3. 別ブラウザーで試す | ブラウザー固有の不具合かどうかを切り分け | Edge／Chrome／Safari など 2 種類以上で比較すると◎ |
| 4. OneNote デスクトップアプリで配布を試す | Web 版限定の不具合かどうか確認し、当面の回避策にもなる | Class Notebook タブが表示されていることを確認 |
ステップ 1：プライベート／シークレットウィンドウで再試行
まずは最も簡単で効果の高い方法です。
- Edge：Ctrl + Shift + N
- Chrome：Ctrl + Shift + N
- Firefox：Ctrl + Shift + P
- Safari（Mac）：メニューから「プライベートウィンドウ」を開く
プライベートウィンドウを開いたら、以下の順に操作します。
- OneNote のサイトにサインインする。
- 問題が起きている Class Notebook を開く。
- Class Notebook タブから Distribute Page を実行する。
ここで正常にページ配布できた場合、多くは「通常ウィンドウ側のキャッシュや Cookie、拡張機能」が原因です。この場合は次のステップ 2・3 に進み、根本的に環境をリセットしておくのが安全です。
逆に、プライベートウィンドウでも同じエラーが出る場合は、サービス側の一時障害や、ノートブック自体の問題の可能性が高くなります。
ステップ 2：ブラウザーのキャッシュと Cookie を削除
プライベートウィンドウで改善する場合、または最近ブラウザーを長期間再起動していない場合は、キャッシュと Cookie を削除しておきましょう。
| ブラウザー | ショートカット | 主な操作手順 |
|---|---|---|
| Edge / Chrome | Ctrl + Shift + Delete | 「閲覧履歴データの削除」で「キャッシュされた画像とファイル」「Cookie とその他のサイトデータ」を選択して削除 |
| Firefox | Ctrl + Shift + Delete | 「履歴を消去」で「キャッシュ」「Cookie」を選択し削除 |
| Safari | なし（メニュー操作） | 「履歴を消去」＋「開発」メニューから「キャッシュを空にする」を実行 |
削除後は必ずブラウザーを一度完全に終了し、再起動してから OneNote にアクセスし直してください。それでもエラーが続く場合は、別ブラウザーでの動作確認へ進みます。
ステップ 3：別ブラウザーで試す
同じ PC でもブラウザーを変えることで、問題が解消することがあります。
- 普段 Edge を使っている場合 → Chrome で試す
- Chromebook・Mac を使っている場合 → 可能であれば別ブラウザーを入れて比較
別ブラウザーで正常に配布できる場合、元のブラウザー固有のバグや拡張機能の干渉が疑われます。そのまま「配布だけ別ブラウザーで行う」運用に切り替えるか、拡張機能の無効化・再インストールを検討しましょう。
ステップ 4：OneNote デスクトップアプリで配布を試す
Web 版でのみエラーが出ている場合、OneNote デスクトップアプリ（Windows 用）からページ配布を行うことで回避できることがあります。Microsoft のコミュニティ回答でも、Web 版でエラーが出る際にデスクトップアプリを代替経路として案内している例があります。
代表的な手順は次の通りです。
- Teams や OneNote Web から、問題の Class Notebook を「デスクトップ アプリで開く」。
- OneNote デスクトップアプリでノートブックが開いたら、上部のリボンの Class Notebook タブをクリック。
- Distribute Page を選択し、配布先のセクションを指定する。
もしデスクトップアプリでも同じようにエラーが出る場合は、サービス側やノートブック構造の問題の可能性が高くなります。その場合は、次の「組織全体での対応」に進んでください。
組織全体で発生している場合の対応（管理者・情報担当者向け）
同じテナント内で複数の教員・社員から「Distribute Page がエラーになる」と報告が来ている場合は、個別端末の問題よりも Microsoft 365 サービス側を疑うべきです。このときは、以下の 3 つの軸で動くと効率的です。
| ステップ | やること | 担当者 |
|---|---|---|
| 5 | Microsoft 365 管理センターでサービス障害を確認する | グローバル管理者／サービス管理者 |
| 6 | ユーザー側から手動でフィードバック・ログを送信する | 影響を受けている教員・ユーザー |
| 7 | 管理センターから正式なサポートケースを登録する | グローバル管理者 |
ステップ 5：Microsoft 365 管理センターでサービス状態を確認
グローバル管理者（またはサービス管理者）は、Microsoft 365 管理センターの「サービス正常性」ダッシュボードから、OneNote／Office for the web／Teams など関連サービスのインシデントを確認します。
- 「OneNote for the web」「Class Notebook」などのキーワードで絞り込み
- 最近のインシデント／アドバイザリに、ページ配布や同期に関する事象が出ていないか確認
- 関連するメッセージがあれば、影響範囲・回復見込み・回避策を現場に周知
ここで既知のインシデントとして掲載されていれば、個別の端末調査よりも「いつ復旧するか」の情報収集に優先度を振りましょう。
ステップ 6：Microsoft へ手動でフィードバック・ログ送信
エラー画面の Report ボタンが機能しない場合でも、Class Notebook にはエラー解析用のログとセッション ID を生成する仕組みが用意されています。Microsoft 公式サポート記事では、以下のような手順が案内されています。
OneNote（Web 版）でのログ取得
- Distribute Page を実行し、問題のエラーをあえて再現する。
- エラー画面が表示された状態で、キーボードの Ctrl + ~ を同時に押す。
- Class Notebook が、エラー発生時のセッション情報とログを内部で収集する。
- 表示されるダイアログから 「Export Logs」 を選択すると、.csv ファイルとしてログがダウンロードされる。
- この CSV を、後述するサポートケースやフィードバックフォームに添付する。
OneNote（Windows アプリ）でのログ取得
- デスクトップ版 OneNote で同じように Distribute Page を実行し、エラーを再現する。
- キーボードの Ctrl + ~ を押すと、セッション ID が生成される。
- このセッション ID をメモし、サポート依頼時に「いつ」「どのノートブックで」発生したかと合わせて伝える。
加えて、ブラウザーの開発者ツール（F12 キー）を開き、Console（コンソール）の赤いエラー行や、Network（ネットワーク）の失敗しているリクエストをスクリーンショットにしておくと、Microsoft 側での解析が格段に進みやすくなります。
ユーザー側からは、Class Notebook タブの Help ＞ Give feedback to Microsoft ＞ Report a problem からも同様のフィードバックを送信できます。組織の中で複数人が同じ現象を再現できる場合は、できるだけ多くのユーザーに送信してもらうことで問題の深刻度を伝えやすくなります。
ステップ 7：管理センターから正式なサポートケースを登録
影響が大きい場合や長期化している場合は、Microsoft 365 管理センターから正式なサポートケースを登録しましょう。
| 情報の種類 | 具体例 | 優先度 |
|---|---|---|
| 発生日時とタイムゾーン | 例：2025/08/05 09:10（日本時間） | 必須 |
| 影響範囲 | 教員 15 名／クラス 30、全員で発生 など | 必須 |
| 再現手順 | どのノートブックで、どのセクション／ページをどう配布したときに起きるか | 必須 |
| エラー表示のスクリーンショット | 「Uh Oh! It looks like something went wrong!」と Report ボタンが映った画像 | 必須 |
| 取得したログ／セッション ID | Ctrl + ~ で生成した CSV、Windows アプリでの Session ID | できれば必須 |
| 端末・ブラウザー情報 | OS、ブラウザーの種類とバージョン、拡張機能の有無 | あると良い |
これらの情報を揃えておくことで、単なる「動きません」という問い合わせではなく、問題の規模とビジネスインパクトが明確なケースとして扱ってもらいやすくなります。
障害発生中の授業を止めないための回避策
サービス側の不具合や調査中のケースでは、どうしても復旧まで時間がかかることがあります。その間、授業や研修を止めないための 現実的な代替手段をいくつか紹介します。
回避策 1：ページをコピーして Teams／SharePoint で配布
- OneNote のページを PDF に印刷（エクスポート）して Teams の「ファイル」や SharePoint ドキュメントライブラリで共有する。
- Teams の「課題」機能に PDF や Word ファイルとして添付し、提出物として管理する。
OneNote 上での直接編集はできませんが、「配布がまったくできない」という状態からは脱出できます。
回避策 2：OneNote デスクトップアプリで手動コピー
デスクトップ版 OneNote からであれば、ページを右クリックして 「移動またはコピー」を使い、生徒のノートブックセクションにコピーすることができます。
- クラス人数が多い場合は手間がかかりますが、どうしてもその時間にだけ必要なページであれば現実的な選択肢です。
- 授業計画上重要なページだけ手動コピーし、その他は復旧後に再配布する、といった優先度づけも有効です。
回避策 3：Class Notebook を使わない配布チャネルを一時的に併用
- クイズや小テストは、Microsoft Forms や LMS のテスト機能で代替する。
- 説明資料は、PowerPoint や PDF として配布し、OneNote への貼り付けは後日まとめて行う。
「すべてを Class Notebook で完結させる」運用は理想的ですが、障害中は 最低限の学習体験を維持することを優先しましょう。
再発防止につながる運用の工夫
ノートブックの設計と権限を見直す
Class Notebook では、コンテンツ ライブラリやコラボレーション スペースなど、役割の異なるセクションが混在します。ページ配布を安定させるためには、次のような設計を心がけるとよいでしょう。
- 配布元のページは、基本的に コンテンツ ライブラリに集約する。
- コラボレーション スペースや権限をカスタム変更したセクションからは、配布元として使わない。
- 1 つのノートブックを長年使い回すのではなく、年度ごと・講座ごとに新規作成する。
こうすることで、権限設定の複雑さやノートブック肥大化に起因するトラブルを減らすことができます。
ブラウザー利用のルール化と定期メンテナンス
- 組織として「OneNote／Class Notebook はこのブラウザーを推奨」という方針を決めておく。
- 長期間 PC をシャットダウンしていない端末には、定期的な再起動とブラウザーのキャッシュクリアを促す。
- 広告ブロッカーやプライバシー保護系拡張機能は、業務アプリへの影響を説明したうえで必要最低限に抑える。
これらはすべて地味な対策ですが、特に共有 PC や職員室 PC では、日々のメンテナンス不足が思わぬ障害を呼び込むことが少なくありません。
トラブル情報の共有テンプレートを作っておく
毎回ゼロから状況を説明していると、教員やヘルプデスクの負担が非常に大きくなります。次のような項目を含んだ「問い合わせテンプレート」を 1 枚作っておくと、対応のスピードと正確さが大きく向上します。
- 発生日時・クラス名・教員名
- ノートブック名・セクション名・ページ名
- 利用端末の種類（PC／タブレット／OS）
- ブラウザー名とバージョン
- プライベートウィンドウでの再現有無
- 別ブラウザーでの再現有無
- スクリーンショット・ログの有無
このテンプレートを、職員室の共有フォルダや Teams チャネルにあらかじめ配布しておけば、障害発生時の情報収集が格段にスムーズになります。
よくある質問（FAQ）
Q. 自分だけでなく複数の教員が同時期に同じエラーになりました。どう考えればよいですか？
A. サービス側の障害や新しいバグの可能性が高いと考えられます。個人のキャッシュ削除やブラウザー変更は最低限試したうえで、Microsoft 365 管理センターでのサービス正常性確認と、サポートケース登録を優先してください。
Q. Distribute Page を押すとエラーになりますが、一部の生徒にはページが届いているようです。
A. ページ配布はバックグラウンドで非同期に進むため、途中まで成功してからクライアント側だけエラーになっている可能性があります。代表の生徒アカウントでノートブックを開き、配布先セクションにページが存在するか確認してください。混乱を避けるため、授業中に一度「配布状況の確認」を行うことをおすすめします。
Q. Teams 経由で開いた Class Notebook でも同じエラーが出ます。
A. Teams から開いた Class Notebook も、内部的には OneNote for the web を利用しているため、同じエラーが再現するのは自然な挙動です。Teams だけの問題かどうかを切り分けるために、ブラウザーから直接 onenote.com にアクセスして同じ操作を試すことをおすすめします。
Q. Distribute Page のボタン自体が見当たりません。
A. これは今回の「Uh Oh!」エラーとは別の事象で、Class Notebook アドインやライセンスの問題である可能性があります。リボンに「Class Notebook」タブが表示されているか、利用アカウントが教育テナントとして正しく設定されているかを確認してください。
Q. Report ボタンが効かないので、Microsoft にどうやって状況を伝えればいいですか？
A. 本文で紹介したように、Ctrl + ~ でログやセッション情報を取得し、管理センターから作成するサポートケースに添付することで、より詳細な情報を Microsoft に届けることができます。併せて、Class Notebook タブの「Give feedback」を利用し、複数の教員から同様のフィードバックを送ると、問題の優先度を上げてもらいやすくなります。
まとめ：個人の切り分け＋組織でのエスカレーションが鍵
OneNote Class Notebook の「Distribute Page」が「Uh Oh! It looks like something went wrong!」エラーで失敗する問題は、ブラウザーのキャッシュや拡張機能、サービス側の一時障害、ノートブックの権限や構成など、さまざまな要因が絡み合って発生します。
- まずは現場レベルで、プライベートウィンドウ・キャッシュ削除・別ブラウザー・デスクトップアプリの 4 ステップを実施して、個別端末の問題を切り分ける。
- 組織全体で再発している場合は、Microsoft 365 管理センターでのサービス正常性確認と、ログ付きのサポートケース登録で正式にエスカレーションする。
- 障害中は、PDF 配布や手動コピー、別ツール併用などの暫定的な回避策で授業・研修を止めないようにする。
この記事を参考に、現場でのトラブルシューティングと、組織としての対応体制づくりを進めていただければ幸いです。
コメント