似たようなQiita記事はあるのですが、ちょっと調べ物をしたので覚え書き。
TL;DR
Microsoft Office Scriptsからサーバーにfetchを送るときにCORSエラーが出るようになった。Access-Control-Allow-Originに*を設定すれば一応解消される。もうちょっといい方法ないかなあ。
事の発端
１、２年ほど前に、OneDriveに置いてあるExcelからバックエンドのサーバーにデータを送るOffice Scriptsを作って設置しました。設置した当初もCORSの設定は必要だったので、https://*.officescripts.microsoftusercontent.comのドメインに対してAccess-Control-Allow-Originを設定していました。参考：stackoverflow
このスクリプトは数ヶ月に一回程度しか使われていないのですが、今朝になって走らせたら以下のエラーが。
Access to fetch at [...] from origin 'null' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
2025-05-13頃にはこの件がすでに観測されている。
原因
どうやらOffice Scriptsから送られるHeaderが前述のofficescripts.microsoftusercontent.comからnullに変更されたそう。
じゃあAccess-Control-Allow-Originにnullを設定したらよいかというとそうでもなく、MDNによるとAccess-Control-Allow-Originにnullを設定するのは避けるよう記載されている。
null Originとは一体...?
見慣れないOriginなので、一応何者かを確認。
上記のMDNによると、data:やfile:などのリソースやサンドボックス化されたドキュメントから来るリクエストはブラウザがOriginをnullとシリアライズそう。
こちらのStackoverflowでsideshowbarker氏の回答を見ると、リソースがHTMLスタンダードで言うところの"opaque origin"（不透明なオリジン）に当たる場合はoriginがnullとしてシリアライズされる。
じゃあopaque originって何よ
上記のsideshowbarker氏の回答には、以下のケースがopaque originとして判断される：
このリストを眺めるに、なんかイレギュラーっぽいやつとか、cross-originのリソースとか、そういうケースがopaque originになるようす。
トラブルシュート
Access-Control-Allow-Originを*に設定すれば、問題自体はサクッと解決できる。
Office Scriptの公式ドキュメンテーションにも、Access-Control-Allow-Originを*に設定するように、とあるので一応これが公式の解決方法ということになる。
私の場合はこのOffice Scriptを走らせている処理は個人用のものなので、ワイルドカードに設定しておくのもなぁという気持ち。
ひとりごと
Microsoftに振り回されている。
公式ドキュメンテーションに『originはいきなり変わるかもしれないけどよろしく』的なことが書いてあるので、また同じようなエラーが出るかもしれない。
