OCLP関連フォーラムでも「問題なく動いている」との成功報告が続々と上がってきていたので、今回もサクサクっとアップデートしていきます。

ただし safari27のフリーズ問題は進展がなかったので今回はスルー。

macOS Sequoia 15.8.2へアップデート

いつものようにアップデートしていきます。

まずはOCLPのバージョンチェックから

現在は OCLP 2.5.1 です。
問題なし

最新バージョンでない人はアップデートしておきましょう。

ソフトウェアアップデートから更新

システム設定を開き、一般 > ソフトウェアアップデート を開くと、
更新一覧が表示されます。
ただし「今すぐアップデート」は押さず、その隣の iマーク を押す。

すると TahoeやSafari 27.2にチェックが入っているという罠 を回避できます。

ちゃんと macOS Sequoiaのアップデート にチェックしてから「今すぐアップデート」ボタンを押下

ダウンロードが始まります

「準備中」になってからしばらく待つと再起動。

OCLPルートパッチを適用

再起動してきたらOCLPがルートパッチの不在を検出し、インストールするか聞いてきます。→「OK」

インストールしたら再起動

無事に macOS Sequoia 15.8.2 (24H232) になりました

まとめ

今回も問題なくアップデートできました。

safari 27.2 はインストールしていません。
動画のあるページでフリーズしてしまう不具合は未だ進展なし、といった様子。いつかなんとかなるんだろうか・・・。
全ての人に影響があるわけではなさそうなので、問題ない人には問題ないんでしょうけど。
一つ前のバージョンのsafariに戻したいなんてことがあったらこちらを参考に。

Safariを「最新版のひとつ前」にアップデートする方法 スタンドアローンのPKGを使う

Safariのスタンドアローンpkgを使って、一つ前のバージョンをインストールしていきます。通常、ソフトウェアアップデートを使って更新すると最新版にアップデートされます。が、その最新版で問題が起こる場合、一つ手前のバージョンに留めておきたい...

www.wholenotism.com

2026.09.23

あと関係ないけど、そろそろ OCLP 3.0.0 が来そうですね。
今は rc.5 のようですが、Tahoeのインストールに踏み切っている人もいてちゃんと動いているようです。期待しかない。

とりあえず今回は以上！

ERROR: [BiliBili] xxxxxxxxxx: Unable to extract initial state;

ブラウザで表示させると 404エラー としてリダイレクトされます。

なんかおかしいなと思いつつユーザーのページからリンクで飛ぶと・・・問題なく表示されました。ん？？？

さらにBilibiliのトップページを開いたら「自動翻訳が有効になりました」というポップアップが出現。
どうやら仕様の変更があったようです。

そこでURLをよく見てみると

https://www.bilibili.com/ja/video/xxxxxxxxxxxx/

/ja/ という言語設定が付加されてました。
zh-Hans や en に変えるとページの言語も切り替わります。

仕様変更によって 言語付きURLでなければ404を返すようになっていた ようです。

先ほどはブックマークで保存していた検索結果を表示、その画面では古いurlのままだったので404エラーが発生。改めて新しいURLの方で検索したら問題なく表示されました。

気づくまでにちょっと時間がかかりました。

てことで新しい方のurlを渡してみると

ID  EXT  RESOLUTION
0   html unknown

・・・だめじゃん。
htmlしか返ってこない。たぶん404のhtml？確かめてないけど。

yt-dlpの方も新しいURLを正しく認識できていない可能性があります。

結局、2つファイルを修正したところ、無事にダウンロードできるようになりました。

yt-dlpでBilibiliのurlが解析できていない問題

yt-dlpが動画情報を正常に取得できず、次のような結果に。

[info] Available formats for player:
ID EXT  RESOLUTION │ PROTO │ VCODEC  ACODEC
────────────────────────────────────────────
0  html unknown    │ https │ unknown unknown

動画の映像や音声のフォーマットではなく、HTMLしか取得できていません。

ブラウザでは動画を再生できるので、URL自体が無効というわけでもなさそうです。

ログを見ると
（旧url）bilibili.com/video/ の方は

[BiliBili] Extracting URL:...

（新url）bilibili.com/ja/video/ の方は

[generic] Extracting URL:...
WARNING: [generic] Falling back on generic information extractor

Bilibiliのurlだと認識されず、ジェネリックなinformation extractorで処理されてしまっているようです。

そこで、Bilibili用のextractorが言語付きURLを認識できるように修正しました。

yt_dlp/extractorのファイルを修正する

yt-dlpは extractor のファイルが動画ページから動画IDや再生に必要な情報などを取得します。

今回の修正では関係する2つのファイルを変更しました。

• lazy_extractors.py
• bilibili.py

念の為、変更前にそれぞれバックアップを取っておいてください。修正は自己責任で。

対象ファイルの場所について

bilibili.py と lazy_extractors.py のある場所は、OSや yt-dlp のインストール方法によって異なります。

macOSだけでも Homebrew、pip、pipx、MacPortsなど複数の方法があり、環境によってインストール先が異なるため、ここですよとは言いづらいのです。

ファイルの場所が分からない場合は、
ご自身のOSと yt-dlp のインストール方法を伝えたうえで、ChatGPTなどのAIアシスタントに確認してみてください。

多分それが一番早い。（＾＾；

ちなみに自分は macOS、pipx で入れたので

~/Library/Application Support/pipx/venvs/yt-dlp/lib/python3.13/site-packages/yt_dlp/extractor/

でした。

修正したファイル①：lazy_extractors.py

lazy_extractors.py は、yt-dlpの遅延読み込み（Lazy Loading）に関係するファイルです。
URLパターンなどを利用して必要な候補を絞り込み、必要な Extractor だけをロードします。

BiliBiliIE クラスの _VALID_URL、
修正前は次のようになっていました。（1500行目）

_VALID_URL = 'https?://(?:www\\.)?bilibili\\.com/(?:video/|festival/[^/?#]+\\?(?:[^#]*&)?bvid=)(?P[aAbB][vV])(?P[^/?#&]+)'

この正規表現では、/video/ などのパスは対象になりますが、/ja/video/ のように言語コードが先頭に追加された形式は対象になりません。

次のように変更します。

_VALID_URL = 'https?://(?:www\\.)?bilibili\\.com/(?:[a-zA-Z-]+/)?(?:video/|festival/[^/?#]+\\?(?:[^#]*&)?bvid=)(?P[aAbB][vV])(?P[^/?#&]+)'

追加したのはこれ、

(?:[a-zA-Z-]+/)?

ドメイン bilibili\\.com/ の後に言語設定の部分を足しました。

これで新旧両方のurlに対応できます。

#旧url
https://www.bilibili.com/video/BVxxxxxxxxxx/
#新url
https://www.bilibili.com/ja/video/BVxxxxxxxxxx/

修正したファイル②：bilibili.py

bilibili.py は、Bilibiliの動画情報を取得するための実際の処理を定義しているファイルです。

対象となるのは、こちらも BiliBiliIE クラスの _VALID_URL です。

修正前（372行目）

_VALID_URL = r'https?://(?:www\.)?bilibili\.com/(?:video/|festival/[^/?#]+\?(?:[^#]*&)?bvid=)(?P[aAbB][vV])(?P[^/?#&]+)'

こちらも変更点は lazy_extractors.py と同じです。
ドメインの後の言語コードに対応させます。(?:[a-zA-Z-]+/)?を追加。

_VALID_URL = r'https?://(?:www\.)?bilibili\.com/(?:[a-zA-Z-]+/)?(?:video/|festival/[^/?#]+\?(?:[^#]*&)?bvid=)(?P[aAbB][vV])(?P[^/?#&]+)'

さらにプレイリスト（video/BVxxxxxxxx?p=3みたいなの）だとエラーになることに気がついたので追加で修正。

修正前（782行目）

getter=lambda entry: f'https://www.bilibili.com/video/{video_id}?p={entry["page"]}')

ここはurlを文字列として生成しているので直接 /ja/ を追加しました。

getter=lambda entry: f'https://www.bilibili.com/ja/video/{video_id}?p={entry["page"]}')

-I, --playlist-items ITEM_SPEC のオプションを使っても、
結局 ?p=1 みたいなurlで解析するので書き換えが必要になる場合があります。

ほかにもあるかもしれないけど、単体とプレイリストしか自分は扱わないのでこれで十分かな。

まとめ

これで無事にファイルフォーマットを取得、ダウンロードできるようになりました。

今回の問題は、Bilibiliの言語付きURLをyt-dlpが正しく扱えなかったことが原因でした。

そしてこれはあくまで一時的な回避策です。修正前のファイルをバックアップしておき、自己責任で修正してください。

yt-dlpが正式に更新されるまではこれで凌ぐことにします。
同じ症状に遭遇した方の参考になれば幸いです。

では。

追記

記事を書いたその日にyt-dlpがアップデートされました。
使っていた nightly 2026.10.10.233141 -> 正式リリース版 ver.2026.10.21.233146 にアップデート。
ただbilibili.pyはアップデートされていないので書き換えが必要、lazy_extractors.pyはリネームするか書き換えが必要です。

追記@2026.10.24

プレイリストをDLしようとするとエラーが出ることに気がついたのでbilibili.pyを追加で修正。

Googleが開発したオープンAIモデル 「Gemma3（4）」 を使い、チャッピーみたいなチャットAIがローカルに爆誕しました。
能力的には・・・使えるかと言うとまぁ「動かせる」程度のもので、そもそもスペックが低いのでそれは仕方ない。

その後、AI同士で延々と会話をさせてみたり、paddleOCRと組み合わせて、より精確なOCRにトライしてみたりしてましたが、
2026年1月に公開された Qwen3-TTS というモデルを最近知りました。

数秒のサンプルをもとに、その声で指定したテキストを読み上げてくれる、とかなんか面白そう。

てことで試してみました。
そのステップと使い方などの備忘録。

そもそもQwen3-TTSはIntel Macで動くのか？

AIに聞いてみると

Intel Mac（x86_64）における Qwen3-TTS の公式および標準的なローカル実行は、Apple Silicon（M1〜M4）向けの Metal/MPS 最適化や、専用フレームワーク（MLX）を前提としているため、基本的に非推奨・または実用上のハードルが極めて高い状態です。

現状の仕様と注意点

• Apple Silicon専用機能の不在: Metal（MPS）や MLX といったMac向け高速化エンジンは Intel Mac では動作しません。
• CPU実行の制限: PyTorchのCPU版（–device cpu）や互換ビルドで無理やり動作させることは理論上可能ですが、1.7B / 0.6B といった大規模なモデルをCPUのみで推論させることになり、生成速度が非常に遅く、実用的ではないとされています。
• 公式・主要なセットアップ手順: 通常は uv や pip を使い、Apple Siliconなら –device mps オプションをつけて実行します。Intel Mac用の特別な公式ビルドや最適化ガイドは提供されていません。

などと言われました（震え声）。

が、大丈夫です。結論から言えば動きます。

そう、llama.cpp + gguf ならね！

…なんてドヤる必要はないのですが、
脅されたわりには結構すんなり動いてくれたのでその情報をシェアします。

あらためて TTS（Text-to-Speech）とは

TTS（Text-to-Speech）：文字（テキスト）データを、コンピュータやAIを使って自然な音声に変換する技術のことです。
日本語では「音声合成」や「読み上げ機能」とも呼ばれます

以前、「VOICEVOX」というものを使ってみたことがありました。こちらは用意されているキャラクターの声を使用するもの。

一方、ボイスクローン（音声クローン）は自分の声などのサンプルを使い、本人が話していない内容でも自由に喋らせる音声合成技術のこと。

そのクローニングに定評があるのが、「Qwen3-TTS」というモデルらしいのです。

Qwen3-TTSにはいくつかバリエーションがあって、
VOICEVOXのようにあらかじめ用意されている音声をもとに生成するモデル（CustomVoice）、
テキストによる指示（自然言語）だけで新しい声をデザインするモデル（VoiceDesign）、
そしてゼロショット音声複製（ボイスクローニング）の baseモデル です。

今回はこのbaseモデルを使ってみます。

llama.cppのインストールについて

少し前までなら、Homebrewが使えたのですが、
OSをアップデートして改めて入れようとしたら「Intel Macなんてもうサポートしないよ！」と言われ、インストールすらさせて貰えませんでした。

現在は MacPorts や pip（pipx） を使っています。

基本的には以前の記事

llama.cppで始めるローカルAI入門—古いIntel Macでも意外と動く【8.5 t/s】

古いIntel MacでローカルLLMが動くのか、どの程度動くのかの検証です。前回の記事でOllamaを使ってみたものの、遅過ぎて使えない。なのでllama.cppを直接ビルドして使ったら Ollamaの約4倍の速度が出た！ そんなお話です...

www.wholenotism.com

2026.06.18

と同じなのですが、備忘録としてMacPortsを使ったインストール手順も書いておきます。念のため。
わかる人は読み飛ばしてください。

llama.cppをgithubからクローンしてビルドした後、Qwen3-TTSの入手、実行とすすめます。

まずは MacPorts をインストール

まずは、Homebrewの代わりとして MacPorts をインストールしていきます。
ターミナルから作業。

「Xcode用コマンドラインツール（Command Line Tools）」をインストール

xcode-select --install

次に使用しているOSにあったMacPortsをダウンロード。

→ macports.org

Sequoiaなのでリストにある「macOS Sequoia v15」を選択。

保存された MacPorts-2.12.6-15-Sequoia.pkg を開いてインストールします。

インストールできたら動作確認とポートツリーの更新。
ターミナルから

sudo port selfupdate

次に git と cmake をインストール。

sudo port install cmake git

llama.cppをリポジトリからクローンしてビルド

リポジトリからクローンします。保存先はお好きなように。

#git clone <リポジトリURL> <ローカル保存先パス>
git clone https://github.com/ggml-org/llama.cpp.git ~/llama.cpp

このiMac2017に搭載されている Intel Iris Plus Graphics 640 では、使えるどころか足を引っ張ることにしかならないので最初からメタルはオフ、CPUオンリーでビルドします。

cd ~/llama.cpp
cmake -B build -DGGML_NATIVE=ON -DGGML_ACCELERATE=ON -DGGML_METAL=OFF
cmake --build build --config Release -j

最後にパスを通しておきます。

echo 'export PATH=~/llama.cpp/build/bin:$PATH' >> ~/.zshrc
source ~/.zshrc

Qwen3-TTSのGGUFをダウンロード

Hugging Faceの ggml-org/Qwen3-TTS-12Hz-1.7B-Base-GGUF からファイルをダウンロードします。

• Qwen3-TTS-12Hz-1.7B-Base-Q8_0.gguf
• mmproj-Qwen3-TTS-12Hz-1.7B-Base-Q8_0.gguf

~/models などのディレクトリを作って入れておきます。

音声サンプルを録音

音声クローンするのにサンプルとなるファイルを用意します。（wav, mp3）
なお著作権には音声も含まれます。無許可での使用は厳禁です。

自分の声を自分で使うなら問題ないので録音して使いましょう。

標準アプリならQuickTime Playerを起動、「新規オーディオ収録」を選び、録音ボタンの横から入力ソースを選択。録音ボタンを押して録音、そして保存。

自然な抑揚で、3〜10秒程度の文を読み上げればOK。

「青い海をのんびりと泳ぐ。こんにちは、私の声のテストです。」
「桜の咲く季節になると、毎年花見にでかけます。カメラの前で少し緊張していますが、準備はバッチリです。」

などなど。

重要なのは話す内容より「声の特徴を正確に伝えること」と「ノイズや不要な要素を混ぜないこと」。録音の自然さ・明瞭さ・声の一貫性。
また、母音・子音、濁音、促音、長音、数字、疑問文などを含めたり、息継ぎなどの自然な間を持たせると良いようです。

保存名を reference-audio.aifc としたなら（オーディオ書き出しの場合は.m4a）

afconvert -f WAVE -d LEI16 reference-audio.aifc

で、wavに変換できます。
同じ場所に reference-audio.wav が作成されます。

今は仮にデスクトップに置いておくとしましょう。

~/Desktop/reference-audio.wav

llama-tts + qwen3-tts を使って実際に音声クローンを試す

ターミナルから、

llama-tts -m ~/models/Qwen3-TTS-12Hz-1.7B-Base-Q8_0.gguf \
  -mm ~/models/mmproj-Qwen3-TTS-12Hz-1.7B-Base-Q8_0.gguf \
  --tts-lang ja \
  --tts-speaker-file ~/Desktop/reference-audio.wav \
  -p "まずは参照音声を指定して、Baseモデルのボイスクローニング機能を確認する。" \
  -o ~/Desktop/test.wav

問題なければデスクトップに -p で入力した文章が音声となって保存されるはずです。

ちなみにこの程度の文章量で30秒ほどかかりました。

timings: prompt eval 1.72s + generation 20.38s + vocoder 7.81s = total 29.91s
output audio = 5.84s (audio time = 0.20x process time)

Q4_K_M.gguf だと27秒くらい。

timings: prompt eval 0.98s + generation 17.96s + vocoder 7.92s = total 26.87s
output audio = 5.92s (audio time = 0.22x process time)

ただし揺れがあるので、必ずしも毎回このような差が出るとは限りません。
早い時はQ8_0で total 20.93s、
Q4_K_Mでは total 18.02s の時もありました。
それぞれ最大9〜10秒ほどのバラツキがあることになります。

そして 0.6B と 1.7B で比べてもそれほど時間差はありませんでした。
クオリティを聴き比べながら色々と試してみることをお勧めします。

ちなみに --seed 42 などランダム性を決定する基準（シード値。数字は任意）を指定すれば毎回同じ出力が得られます。

まとめ

ということで、Intel Macでも

• llama.cppをビルドして付属の llama-tts を使い、
• GGUF化されたモデルを使用

すれば、
自声でテキストから音声を生成することができました。

リアルタイムでの生成は当然ながら無理としても、動画のナレーションなどを生成するには十分かと思います。

また、長い文章を一気に生成するのではなく、細切れにして生成した方がイントネーションの不自然さなどにも対応できると思います。

出力された音声を聞いた時には大興奮でした。
まさか自宅のパソコンで、決して新しいとは言えないiMacでもこれができるんだなと。

ただ声のトーンや感情を乗せるには元の音声ファイルから変える必要があります。
Baseモデルでは、プロンプトで指示をするなどのオプションは現在のところ用意されていません。
テンションを高くしたかったらテンションの高い音声ファイルを用意する必要があります。

用意された声のバリエーションからプロンプトで変化させる CustomVoiceモデル、
最初からプロンプトで声を作っていく VoiceDesignモデル。

でもやりたいのは 音声クローニングさせて、プロンプトで細かい指示を出せるもの。痒いところに手が届きませんね。

勝手なことを言ってますけれども、今回使用したものを生み出してくれたエンジニアさん達には感謝しかありません。ほんとありがとうございます。
お礼を申し上げて今回の結びとします。

では。

あ、次回は先ほどの「やりたかったこと」をやれるかもと手を出して失敗したモデルの件と、可能性を感じているまた別のモデルの方も試して記事にしようと思います。うまくいくかなぁ・・・（期待

重要なセキュリティアップデートが含まれているらしいのでアプデしておきましょう。

いつものようにソフトウェアアップデートからアップデートします。

これはアップデート記事です。インストール自体はこちらを参考に↓

サポート外のiMacにmacOS Sequoiaをインストールする方法と手順【OpenCore Legacy Patcher/OCLP】

iMac2017 に macOS Sequoia（15.7.9） をインストールしました。本来は MacOS 13 Ventura までが、ネイティブサポート（公式サポート）なのですが、例の如く「OpenCore Legacy Patche...

www.wholenotism.com

2026.09.04

OCLPも最新にアップデート

念のためOCLPを最新にアップデートしておきましょう。

Sequoia 15.8.1へアップデート

システム設定のソフトウェアアップデートを開くと確認できます。

でも微妙に罠だよね笑
「その他のアップデート」のiマークから見ると
macOS Tahoe へのアップデートや Safari 27 へのアップデートにチェックが入っているので余計なものは外します。

ちゃんと Sequoia 15.8.1 をチェックします。

「今すぐアップグレード」を押して規約に同意

ダウンロードが始まり

準備が終わったら自動的に再起動します。

再起動後にルートパッチを適用し、さらに再起動

無事、Sequoia 15.8.1 (24H32) になりました。

まとめ

今回も

ソフトウェアアップデート -> ルートパッチ適用

という流れで問題なくアップデートできました。

マイナーアップデートでセキュリティアップデートが主だと思うので、
特に不具合も起きていません。今のところ。

safari 27の動画関連でフリーズする問題は依然として残っています。
ひとつ前のバージョンで留めているので大丈夫ですが、
改善される未来はあるんだろうか。

Safariを「最新版のひとつ前」にアップデートする方法 スタンドアローンのPKGを使う

Safariのスタンドアローンpkgを使って、一つ前のバージョンをインストールしていきます。通常、ソフトウェアアップデートを使って更新すると最新版にアップデートされます。が、その最新版で問題が起こる場合、一つ手前のバージョンに留めておきたい...

www.wholenotism.com

2026.09.23

通常、ソフトウェアアップデートを使って更新すると最新版にアップデートされます。

が、その最新版で問題が起こる場合、一つ手前のバージョンに留めておきたいことがあります。

そんな時に使える方法です。

何が起きた？ Safari 27にアップデートしたらフリーズ、画面真っ白

先日、macOS 15.8、Safari 27 がリリースされました。
そのインストールに先立ち OCLP も最新版にアップデート。せっかくなのでインストーラを作成し、クリーンインストールすることにしました。

無事にインストールは完了し、全て順調に進んでいたかと思われたのですが、SafariでYouTubeを開いたら

画面が真っ白。

一切の操作を受け付けなくなりました。
（正確にはウインドウ内の描画がフリーズ。上部メニューなどは生きてます）

慌てて他のブラウザ(Firefox、brave、Zenなど)で開いたら問題なく再生されます。結局Safariのみ問題が起きているようでした。

元に戻そうにも、Safariはシステムと密接に関連しているため、アプリをただダウングレードすればいいと言う話ではありません。

紆余曲折の末、OSそのものから再インストールすることにしました。

時間かかるんだよね・・・

やりたいこと。Safari 18.6から26.6.1にアップデート

OCLPで macOS Sequoia 15.8 のインストーラーを作成。
それと一緒に入るSafariのバージョンは18.6でした。

Safari 27とは違い、問題なく閲覧できるのでそのまま使おうかとも思ったのですが、セキュリティーの観点からしてもやはりなるべく新しくしておきたいところ。

ということで Safari 18.6 -> Safari 26.6.1 にアップデートしていきます。

※OCLPも最新版にアップデートしておいてください。

まずバックアップする

最初にバックアップを取っておきます。
何が起きても取り返しがつくよう、念の為バックアップは忘れずに。

Safariのブックマークやパスワードなども書き出しておきましょう。

ファイル > ブラウズデータをファイルに書き出す

Safariのスタンドアローンインストールパッケージを入手する

Mr. Macintoshさんがダウンロードリンクをまとめてくれています。（感謝！）
リンク先のPKG自体はAppleのサーバーに置かれています。

→ macOS Safari Full Installer Database. Download Directly from Apple!

「Safari for macOS Sequoia Installer Download」から、

Safari26.6.1SequioaAuto.pkg

をダウンロード。
OSの種別を間違えないように。

Appleは通常二つ前のバージョンまでを残しておくそうです。
AvailableがYesになっているものだけDLできます。

インストールを実行

まずはSafariを終了させます。

実はダウンロードしてきた Safari26.6.1SequioaAuto.pkg をそのままダブルクリックしてもインストールできません。

開いてもエラー。
「インストールできませんでした。
パッケージ ”Safari26.6.1SequoiaAuto.pkg”は追加コンポーネントが必要で、単独ではインストールできません。ソフトウェアの製造元に問い合わせてください。」

まずはパッケージを展開して確認

パッケージをまずは展開してみます。デスクトップにあると仮定します。
ターミナルで実行します。

pkgutil --expand ~/Desktop/Safari26.6.1SequoiaAuto.pkg ~/Desktop/Safari26.6.1-expanded

デスクトップに Safari26.6.1-expanded と言うフォルダができ、その中に展開されます。

Bom
PackageInfo
Payload
Scripts

などが確認できます。

その PackageInfo の中を見ると、

requires-distribution-check="true"

と書いてあります。Distributionが必要というわけです。

（確認だけなので終わったらフォルダごと削除してOKです）

インストール可能なパッケージに再パッケージ化して、インストール

引き続き Safari26.6.1SequoiaAuto.pkg はデスクトップにあると仮定します。

ターミナルから、

productbuild --package ~/Desktop/Safari26.6.1SequoiaAuto.pkg --version 26.6.1 ~/Desktop/Safari26.6.1-wrapped.pkg

Safari26.6.1-wrapped.pkg というファイルが出来上がります。

ダブルクリックで開くとエラーが出る可能性が高いので、さらにターミナルから作業。
実際にインストールします。

sudo installer -pkg ~/Desktop/Safari26.6.1-wrapped.pkg -target /

結果：

Password:
installer: Package name is 
installer: Installing at base path /
installer: The install was successful.

インストール成功。
再起動は必要ありません。

Safariを起動してバージョン確認

さぁ実際にSafariを開いてバージョンを確認してみます。

ドキドキ

Safari > Safariについて

バージョン 26.6.1 （20624.5.1.18.3）

youtubeを開いてみても

フリーズしない！画面真っ白じゃない！

無事アップデートされたようです。

はぁ〜よかった（安堵）

ソフトウェアアップデートはオフ設定に

勝手にアップデートされないように

システム設定 > 一般 > ソフトウェアアップデート > 自動アップデート（iマーク）

から「自動で実行」をすべてオフにしておきましょう。

「セキュリティ対応とシステムファイルをインストール」 に関しては・・・どっちがいいんだろう？

オフがいいのかオンがいいのか判断がつかないので、オンにする場合は自己責任でお願いします。

オフにする場合は別途 SilentKnight をインストールして適宜確認、アップデートで良いと思います。

まとめ

ということで無事にsafariをアップデートできました。
現在は問題なく動作しています。

開発メニューの機能フラグ、メディアの項目にある「MSE player uses GPU renderer」が問題箇所のようです。
26.6.1までは項目としてあり、デフォルトでオフ。チェックが外れています。

これが27だと強制的にオンになっている、かつ、項目が削除されているそうです。

もうさ、HomebrewもIntel Macを切ったのでインストールすらできないんだよね。MacPortsやpip（pipx）に鞍替えしたけど・・・一つで管理できるのはやっぱり楽だよね。色々厳しくなってきたね。

それはさておき、作業手順をまとめます。
Safariを最新バージョンではなく、ひとつ前のバージョンにアップデートしたい場合は

1. バックアップ
2. 使用しているmacOSに対応したSafariのPKGを入手する
3. インストール可能なパッケージに再パッケージ化
4. ターミナルから管理者権限でインストール
5. バージョン、動作確認

なお、参考にした情報元では Safari 27 からのダウングレードに成功したとも書かれています。

今回は18.6からのアップグレードだったので、その点は確認していません。
もしその必要があるなら試してみてもいいかもしれません。
それでは。

（参考URL:「[Help] Updated to macOS 15.8 using OCLP 2.5.0, and now Safari 27 is not working」）

早速アップグレードしたところ、「Root volume dirty, unpatch to continue」と言われてインストールできず。

その時は何かおかしいと思い、revertして（元に戻して）、OCLP 2.5.0もアンインストール。

改めて 2.4.1 をインストールし、ルートパッチをあてて復帰しました。

その後調べて何が起こっていたのか、いるのかを把握。
簡単にですがまとめてみます。

何が起きているのか

OCLP 2.5.0では、ルートパッチが適用できる状態かどうかを複数の条件で判定しているようです。

例えば、

• 現在のSystem VolumeのSeal状態が Broken
• plistのコミット情報を比較（古いバージョンなど）
• plistに既存のルートパッチが適用済みであることを示す情報が残っている

といった内容です。

これらに該当すると、いったんパッチを解除してから続けてくださいねということになります。

なので「Root volume dirty」と言われても、システムボリューム自体が壊れているという意味ではありません。

なぜこのような仕組みになったのか

OCLP 2.5.0からルートパッチの適用方式がすこし変わりました。

この変更は

• すでにパッチが適用済み、
• あるいは何らかの変更が加えられている

ようなシステムボリュームに対して、さらにパッチを上書きすることで問題が発生する可能性を防ぐことを目的としています。

今までは「パッチ解除 → 再起動 → 再パッチ」という手順を省略し、単に上書きしても大きな問題はありませんでした。

が、OCLP 2.5.0ではWi-Fiパッチに仕様変更があり、これまでのようにパッチを解除せず上書きすると問題が生じる可能性があります。

なのでいったん元の状態に戻してからやり直してくださいという手順になったようです。

なお、もう少し分かりやすい表現に変更するための修正パッチを現在準備中だそうです。（※1）

また、
必ずしも今すぐにOCLPをアップデートする必要はありません。

今すぐOSをインストール/アップデートしたい、ということでなければ、
2.4.1のままにしておいても問題ありません。

今後のマイナーアップデートを待ってからアップデートしても大丈夫だと思います。

（※1 「About “Root Volume Dirty” in OCLP 2.5.0 and later」）

OCLP 2.5.0のインストール手順

「新しい OpenCore Legacy Patcher があるよ！」　と言われたら、
「Download and Install」を選択

ダウンロードが始まるのでしばし待つ

インストール

アップデート完了！

OCLPが最新バージョンにアップデートされたから、OpenCoreとルートボリュームパッチをアップデートする？「Yes」

ビルド完了。インストールする？「Install to disk」

インストール先を選択
（※OSがインストールされているディスクを選びます）

選んでインストール

成功。次にルートパッチもアップデートする？「Yes」

「Post-Install Menu」
ここで問題の画面が出てきます。

この時点でOCLP自体のバージョンは2.5.0に、起動ディスクのEFIパーティションには新しいOpenCoreがインストールされています。

ルートパッチも続けてインストールしたいところですが、前述の仕様変更の影響が出てきます。

ターミナルから

diskutil info -plist / と打って表示された情報を見ると

<key>Sealed</key>
<string>Broken</string>

Brokenとなっています。これは「壊れている」わけではなく、
2.4.1のパッチが適用され「変更されている」のでこうなります。

なのでまずはこれを元に戻します。

「Revert Root Patches」を選択してパッチを外し、再起動。

起動したらOCLPが「ルートパッチなしで起動してるよ！パッチを当てる？」と聞いてくるので「OK」
もしくはOCLPを起動して「Post-Install Root Patch」からインストールしましょう。

ちなみに、パッチを当てる前に先ほどと同じくターミナルからdiskutil info -plist / と打てば、
Apple純正の状態に戻ったため SSV（Signed System Volume）の項目（Sealed）がYesになっているはずです。

話を先に進めます。

パッチ適用成功！再起動するか聞かれるので「Reboot」

再起動したらWi-Fiも復活！

これで無事にアップデートが完了しました。

まとめ

「Root volume dirty」という表現とインストール手順の変更のために少々混乱しましたが、

要はまっさらな状態（元の状態）にしてからルートパッチを適用してね、というお話でした。

そして前述の通り、修正パッチかマイナーアップデートされたものが近いうちに出るでしょうから、それを待ってアップデートしても良い気がします。二度手間になるしね。

また何か新しい情報が出たり、修正の必要が出たら追記します。
では。

追記（2026.09.15）：Sequoia 15.8 + Safariのアップデートがリリース

近いうちに・・・とか言ってたらmacOSのほうが先に来ましたね。
Sequoia 15.8 とSafariのアップデートが来ています。

OCLPのアップデートにも合わせたいのでまだ様子見中。
・・・と思ったけど、続々とアップデート成功の報告が上がってきてるのでやろうかな。

追記（2026.09.18）：Safariのアップデートで問題発生（注：自分だけかも）

その後OCLP 2.5.0にアプデ、パッチも前述の通り削除してから再パッチ。問題なくアップデートできました。
そしてどうせならと Sequoia 15.8 のインストーラを作成。そしてクリーンインストール（OCLPとは無関係。調子が悪かったので）。

無事にインストール完了。ルートパッチ適用。softwareupdateからsafariのアップデートをした、までは良かったのですが、そのsafariで問題発生。youtubeなどの動画があるページを開くとフリーズしてしまう。。。他ブラウザは問題なし、Safariだけ。困った。
原因がルートパッチなのか、たまたま失敗してるのか、他に問題があるのかは不明。OSのインストーラDLに失敗するのでMr.MacintoshのリンクからインストールpkgをDL、それも破損などしていたか。
成功報告は多数あるので、おま環なのかなぁ。再度インストーラを作成し、クリーンインストール中。インストーラもOCLPからDL。はたして？

インストール後にわかったこと

やはりsafari27との相性がわるいみたい。ただ悪いのは自分の環境だけかもしれない。 同じような症状の報告がredditにも上がってる。
クリーンインストール後、safariはver18.6で、その状態でyoutubeなどは開ける。閲覧も問題ない。が、27に上げた途端に問題発生。症状としてはxやyoutubeなどを開いて動画があるとフリーズ。ただアプリ自体は死んでいないので上部メニューや戻るボタンは効く。
でもまともに使えなくなるので結局またOSからインストールし直し、再セットアップ。safariはもうこのままでいくことにした。
似たような症状の人は注意が必要。もっと新しいOSインストーラになってしまったら（含まれるsafariが27になったら）詰む可能性あり。

追記（2026.09.21）：OCLP 2.5.1がリリース

OCLP 2.5.1がリリースされました。
変更点は主に「Root volume dirty」あたりのバグフィックスと、表現の更新みたいです。

• Fix “Root Volume Dirty” appearing after unpatching.
• Reword “Root Volume Dirty” to be clearer for users.

Safariが動画のあるページでフリーズすることに対してのfixはなさそう。つまりアプデする意味は特にない、と。（個人的には）
あとmacOS Sequoia 15.8.1 RC（Release Candidate/リリース候補版）が出てます。正式リリースになったらなにか変わるかな。フリーズ・・・直るかな。

追記（2026.09.22）：safariがフリーズする件について

YouTube, X, Vimeo, Facebook, Twitchなど Media Source Extensions を使うサイトで com.apple.WebKit.GPU が100%になって暴走、画面真っ白になってしまう。
その原因はSafari 27で導入された 新しいレンダラー経路（renderer path） にあるようです。
そしてこれはwebkitのバグではなく、またOCLPがどうこうできる範囲でもない様子。つまりOCLPのアップデートを待ってもそれで対応できない問題だということ。

今はOSインストーラで入ったバージョンの18.6。さすがにセキュリティ的にもやばそうだし、
スタンドアローンのインストールパッケージがあるようなので27の一つ前、26.6.1にしようと思います。
追記が長くなってきたので、その辺はまた別記事にします。

Safariを「最新版のひとつ前」にアップデートする方法 スタンドアローンのPKGを使う

Safariのスタンドアローンpkgを使って、一つ前のバージョンをインストールしていきます。通常、ソフトウェアアップデートを使って更新すると最新版にアップデートされます。が、その最新版で問題が起こる場合、一つ手前のバージョンに留めておきたい...

www.wholenotism.com

2026.09.23

スイッチコントロール自体をオンにするにはサイドボタンを3回押すなどして起動できます（設定すれば）。

レシピを1つしか使わないのであればそれでいいのですが、複数のレシピを使っていると必要になるたび

設定 → アクセシビリティ → スイッチコントロール → レシピ → レシピを起動

と辿っていくのが地味に面倒。

そこで

この設定画面をショートカットから直接開けないものか？

と思って調べてみました。

結論としては設定アプリの「特定の階層を直接開くURL」をショートカットから呼び出すことで実現できることがわかりました。

今回は、それを実際に設定してみます。

ショートカットアプリを使って URLスキーム を開く

設定アプリの URLスキーム を使って目的の設定画面を開きます。

そのために ショートカットアプリ を使います。

まずはショートカットアプリを開き、新規ショートカットを作ります。

アクションは1つだけです。
「アクションを検索」から url と打ち込み

「URLを開く」を選択

「URL」の欄に、次のURLを入れます。

prefs:root=ACCESSIBILITY&path=ScannerSwitchTitle/RecipesIdentifier/LaunchRecipe/LaunchRecipe

これでショートカットを実行すると、

設定 → アクセシビリティ → スイッチコントロール → レシピ → レシピを起動

まで一気に開くことができました。

最後にこれをホーム画面に保存します。

画面下の iマーク から詳細を出し、「ホーム画面に追加」

「URLを開く」の部分を「レシピを開く」などに変更し、アイコンの色などを選んだら「追加」します。

これで完成。

ホーム画面のショートカットをタップすれば、一発で目的の設定画面が開かれます。

今回の目的は複数のレシピからそのとき使いたいものを素早く選べるようにすることなので、これでかなり楽になりました。

URLの構造

「レシピ」の画面までであればもっと短くなります。

prefs:root=ACCESSIBILITY&path=ScannerSwitchTitle/RecipesIdentifier

これで、

設定 → アクセシビリティ → スイッチコントロール → レシピ

を直接開けます。

今回はさらに一段深い「レシピを起動」まで開きたかったので、こうしました。

prefs:root=ACCESSIBILITY&path=ScannerSwitchTitle/RecipesIdentifier/LaunchRecipe/LaunchRecipe

つまり、

• ACCESSIBILITY → アクセシビリティ
• ScannerSwitchTitle → スイッチコントロール
• RecipesIdentifier → レシピ
• LaunchRecipe → レシピを起動

という階層を指定しているわけです。

これらの情報（URL）はどこにあるのか

実はこれはAppleが設定URLとして公開しているわけではなく、
iOSの設定アプリ内部で使われている識別子などを調べ、実機で確認したりユーザー同士で情報を共有したりして明らかにされてきたものなのだとか。

調べてみると、iOSの設定URLをまとめているGitHubリポジトリがいくつかあるようです。

FifiTheBulldog / ios-settings-urls

ios-settings-urls/settings-urls.md at master · FifiTheBulldog/ios-settings-urls

A collection of iOS Settings URLs. Contribute to FifiTheBulldog/ios-settings-urls development by creating an account on ...

github.com

ここに例えば、

• Accessibility
• Accessibility → VoiceOver
• Accessibility → Guided Access
• Safari → Advanced
• General → Software Update
• Battery

など、大量の設定URLがまとめられています。

ほかにも日本語でまとめられているサイトもありました。

ただし、全部が一覧に載っているわけではない、みたい。

今回欲しかったのは

「スイッチコントロール → レシピ → レシピを起動」のurlでした。

でもその前までしか載ってない！

そこで別の資料なども調べていき、RecipesIdentifier 以降の文字列を発見。

実際に試してみたところ、iOS 26.6.1で「レシピを起動」画面まで開くことができました。

いくつかサンプル

せっかくなので、個人的に便利そうなものをいくつか載せておきます。

アクセシビリティのショートカット

prefs:root=ACCESSIBILITY&path=TRIPLE_CLICK_TITLE

スイッチコントロール

prefs:root=ACCESSIBILITY&path=ScannerSwitchTitle

スイッチコントロール → レシピ

prefs:root=ACCESSIBILITY&path=ScannerSwitchTitle/RecipesIdentifier

アクセシビリティのバックタップ

prefs:root=ACCESSIBILITY&path=TOUCH_REACHABILITY_TITLE/Back%20Tap

一般 → キーボード → ユーザ辞書

prefs:root=General&path=Keyboard/USER_DICTIONARY

モバイル通信 → モバイルデータ通信（全て表示）

prefs:root=MOBILE_DATA_SETTINGS_ID&path=SHOW_ALL

大量にあるのでここですべてを掲載することはできませんが、色々試してみると面白いかも。

まとめ

今回やりたかったのは、階層の深い設定画面を簡単に開くことでした。

urlスキーム なるものがあることは知らなかった。
Appleも公開すればいいのに、とちょっと思ったり。

それはさておき、複数のスイッチコントロールレシピを使い分けている人なら、結構便利だと思います。

あと個人的にはモバイル通信させるアプリを結構徹底的に管理してるので、そこが一発で開けるのは嬉しかったりもする。

ただし、保証されたものではないようなので、iOSをアップデートしたら動かなくなる可能性がゼロではないことに注意。
アプデしたらたまに動作確認するくらいの気持ちで使うのがよさそうです。

それでは。

本来は MacOS 13 Ventura までが、ネイティブサポート（公式サポート）なのですが、
例の如く「OpenCore Legacy Patcher（OCLP）」を使ってインストールしていきます。

実際にインストールした手順を、個人的備忘録も兼ねて記事としてまとめました。

サポート外のiMac2017にSequoiaをインストールする

基本的な流れとしては、

1. OCLPを現在の環境（Sonoma）にインストール
2. インストールメディアを作成
3. 各種データのバックアップ
4. OSのインストール
5. ルートパッチの適用（*自動適用）
6. 環境復旧
7. 運用開始

となります。

が、各種データのバックアップや復旧はそれぞれの環境によるので割愛します。

クリーンインストールを前提としています。

macモデルの確認

言うまでもない話ですが、
OS自体がネイティブサポートされている場合は、素直にソフトウエアアップデートから入れましょう。
OCLPは必要ありません。

OCLPにサポートされているmacかは、Supported Modelsを参照してください。

また、OpenCore Legacy Patcherを使用する前に、最新のバージョンに更新して最新のファームウェアを利用できるようにしてください。

そしてmacOS Sonoma以降のインストールには3GB以上のRAMが必要です。

2GBのRAMでは Sonoma や Sequoia をインストールできず、起動すらできない可能性があります。
ご注意を。

まずはOpenCore Legacy Patcherのインストール

まずは OpenCore Legacy Patcher をインストールします。

ダウンロードはこちらから
-> OpenCore Legacy Patcher Release Apps

執筆時の最新は ver2.4.1、Assets から OpenCore-Patcher.pkg をダウンロード。

DLしたらインストール。

macOS Seauoia のインストーラー作成

まずはOSのダウンロードとインストールメディアの作成を行います。
インストーラにするメディア、およびそのメディアを読むカードリーダなどをあらかじめ用意しておいてください。
今回は MicroSD（32GB）を使いました。

アプリケーションフォルダにある「OpenCore-Patcher.app」を開きます。

「Create macOS Installer」をクリックし、「Download macOS Installer」を選択

今回はSequoiaなのでそれを選択

ダウンロードが始まります

ダウンロードが完了するとインストーラを作るかどうか聞かれます。「Yes」を押下。
後から作業する場合は「No」でも構いません。その場合は先ほどの「Create macOS Installer」から「Use existing macOS Installer」を選び、アプリケーションフォルダにあるインストーラを選んでください。（自動的に選ばれるので確認してクリック）

「Select local disk」
インストーラにするメディアが挿さっているものを選びましょう。（※間違いがないように注意

「消しちゃうけど良いんだよね？データは消えたら戻せないよ？」と聞かれるので「Yes」

インストーラの作成が始まります。そこそこ時間はかかるのでのんびり待ちましょう。

バリデーション（間違いがないか検証）の後、Opencoreをインストールするか聞かれるので「Yes」

今実行している環境に合わせたビルドが行われます。完了したら実際にインストール。「Install to disk」
※インストール先を間違えないように！

Opencoreをインストールできたら「macOS Sequoia インストーラ」の完成です。

macOS Sequoiaをクリーンインストールする

今作ったインストーラから起動、インストールを実行します。

「Reboot」で再起動。
起動音がしたらOptionキーを押し、作成したインストーラを選択して続行します。

毎回クリーンインストールしているので今回も導入先のSSDを「ディスクユーティリティ」から消去。フォーマットしてまっさらに。

あとはSequoiaを通常のようにインストールします。

ルートパッチの適用（*自動適用）

幾度かの自動的な再起動を経て、ついに Sequoia が起動してくるものと思います。

基本的にはもうそれで問題ありません。インストール作業自体は完了です。

以前のmacOSならその後に起動ディスクとなるものにもOCLPのルートパッチを当てなければなりませんでした。
でも今は自動的にパッチが適用されるようです。便利！

ただしOSのアップデートをした後は、手動でのパッチ適用が必要になるのでそこは注意。

環境の復旧、運用開始

あなたがもし Time Machine を使っているなら、そこからの情報を使って復旧させましょう。
全て、ではないかもしれませんがある程度の復旧は楽に行えるものと思います。

そうでない場合（自分の場合は）、あらかじめブラウザやメーラ、フォントやアプリ、環境設定などのデータをとっておき、順次復旧させます。

自分で作った Automatorやショートカットアプリ なんかは意外と見落としがちです。忘れずにバックアップをとっておきましょう。

まぁ慌てずとも、少しづつ復旧させても問題はありません。
不安なら ~/ライブラリ など、まるまるっとバックアップとしてコピーしておいて、諸々終わったら削除するのでもいいでしょう。

Dockにあるシステム設定に Tahoe へのアップグレード通知があるのを消す方法

Sonomaまでは、単純にアップデートの自動実行を切り

ターミナルから

softwareupdate -l

を打ち込めば、赤い通知マークは消えてくれました。

Sequoiaでも消えます。が、すぐに復活します。
残念ながら。

Appleはアップデートの自動実行を全て切っても、裏で通信して通知を出してきます。正直うざいのですがどうしようもないみたい。

仕方ないので、昔から使われている方法を使います。

アプリケーションフォルダを開き、「システム設定」のエイリアスを作成。
そのエイリアスを Dockにドラッグ&ドロップ すればOKです。元の システム設定アイコン がDockにあるなら、オプション > Dockから削除 で消して構いません。

とりあえずこれで赤いバッジは目に入らなくなります。一応ね。

まとめ

しばらくmacOS Sonomaを使ってきましたが、先日14.8.8がリリースされたと思ったら10日ほどで14.8.9がリリース。
アップデートしなきゃと思いつつ時は経ち・・・。もうどうせなら次のSequoiaを入れる良いタイミングなのではないかと思いインストールを実行しました。

その後、特に不具合は見受けられません。

Sonomaが正式なサポートから切られるのはもう時間の問題。
Sequoiaでもほぼほぼ変わらず違和感なく使えるという意味では、そろそろアップグレードしても良いかと思います。

そんなことより、Homebrew が Intel Macのサポートを2027年には外す、それに先立って今の9月からbottleの提供を事実上停止。
すでにインストールしようとするとソースからのビルド（コンパイル）が必要になっているようです。由々しき問題。

何かアップグレードするたびに ソースからビルド、make、install とか時間がかかってかかってしょうがない。

ん〜・・・

-vで詳細なログを出しながら何度か試しているうちに、少し不思議な挙動が見えてきた。

結論から言うと今回の現象は、bilibili側のCDNアクセス時に一部データの遅延によりエラー発生、という可能性が高そう。一度動画を最後まで取得すればその後のダウンロードは安定する。

ただしCDN内部のキャッシュ状態は外部から直接確認できないため、これはあくまで観測結果からの推測となります。

発生した現象：Got error. Retrying (1/10)…

yt-dlpで動画をダウンロードしていると、以下のようなログが出ることがあった。

Got error: Downloaded 87390979 bytes, expected 195457749 bytes. Retrying (1/10)...

つまり、約195MBのデータを受信するはずだったHTTPリクエストが、約87MB受信したところで途中終了している。

その後、何度かリトライされるも、結局完全なファイルとはならずに終了。

CDNによって挙動が違う

興味深かったのは、同じ動画でも配信されるCDNによって挙動が違ったこと。

今回問題が発生したのは、

upos-sz-mirrorcosov.bilivideo.com

一方、別のCDNである、

upos-hz-mirrorakam.akamaized.net

から配信された場合は、ダウンロード速度は遅いものの、途中で止まることなく最後まで完走した。

つまり、

bilivideo.com の場合、
速度は比較的速い
    ↓
途中で速度低下・タイムアウト
    ↓
リトライ


akamaized.net の場合、
速度は遅い
    ↓
しかし安定して完走

という違いがあった。

この時点で、動画ファイルそのものの破損や、yt-dlpの基本的なダウンロード処理が原因である可能性は低そうだと考えた。

socket-timeout を延長してみる

yt-dlpにはソケット通信のタイムアウトを指定する--socket-timeoutオプションがある。

そこで、タイムアウトをすこし長くして試してみた。

yt-dlp --socket-timeout 60 URL

すると、約27～30％付近で止まっていたダウンロードが、少し先まで進むようになった。

約27.9％
    ↓
タイムアウト


タイムアウト時間を延長（--socket-timeout設定）
    ↓
さらに先まで進む

やはり、動画ファイルのデータが特定の場所で壊れているわけではなさそう。
まぁこのような状況が発生するのは1つだけじゃないからね、それはそう。

http-chunk-size を小さくしてみる

次に、HTTPダウンロードのチャンクサイズを小さくして試した。

例えば、

yt-dlp --socket-timeout 60 --http-chunk-size 5M URL

のような設定。

すると、さらにダウンロードが先まで進むようになった。

最終的には、

27.9％付近で停止
    ↓
44.7％付近で停止
    ↓
86.4％付近で停止
    ↓
93％付近、速度低下しながらも・・・
    ↓
100％ 完走

という状態になった。

最初は27～30％付近でおかしくなっていたものが、設定を変更すると44％、86％、93％と、徐々に先へ進んでいった。

つまり、その時々で通信が詰まったりしている？けれど一応最後までダウンロードはできる、ということ。

一度100％までダウンロードすると、次はスムーズに

そして今回の検証で最も重要だったのがここ。

まず、タイムアウト時間を延長し、HTTPチャンクサイズを小さくすることで、何度か詰まりながらも最終的に100％までダウンロードした。

そして、その直後に同じURLを、今度はオプションを付けずに再度ダウンロードしてみた。

結果は、

最初から最後までスムーズにダウンロード完了！

bilivideo.comだったのにも関わらず。
この結果から、
一度100％まで取得したことでCDN側のキャッシュ状態が変化し、2回目以降のダウンロードではデータが安定して配信されるようになった、のではないかと思う。
一定のサイズで通信に制限をかけているわけでもなかった。

初回アクセス
    ↓
bilivideo CDN
キャッシュに存在しないデータ
    ↓
originやバックエンドから取得
    ↓
一部のデータ範囲で取得に時間がかかる
    ↓
HTTPレスポンスが遅延
タイムアウトしながらもリトライ
    ↓
徐々にデータ取得
    ↓
100％まで完走
    ↓
（CDN側のキャッシュ状態が改善した可能性）


2回目のアクセス
    ↓
キャッシュから安定して配信

まとめ

ということで　CDNのキャッシュが問題　なのだと思う。多分。
（所詮素人なので勝手な推測ですが）

そしてそれがわかったところでユーザー側にできることはあまりないかもしれない。

ただタイムアウトを長くしたり、チャンクサイズを小さくしたりすることで、途中で失敗せず最後まで取得できる可能性を高めることはできるかもしれない。
そんなことを思ったので簡単にまとめてみました。

重ねて言いますが、あくまでもこれは今回観測した環境での結果、推測であり、すべての状況に当てはまるとは限らないので悪しからず。

動画と音声を別々にDLして結合する

ここで終わってはそれこそ何の役にも立たない話で終わってしまうので、ffmpegを使って結合するやり方を書いておきます。
yt-dlpでも動画と音声をそれぞれダウンロードし、結合しています。
が、不完全なデータを無理やり結合しても不完全なファイルになるわけで、またダウンロードし直して・・・なんてやってたらいつまで経っても終わらない。

そういう時は-Fオプションでリストを表示、-fオプション（小文字）で指定してまずは個別にダウンロードします。

#一般的には「コマンド、オプション、URL」の順（URLの前）に書きますが、後ろでも問題はありません。その方が入力しやすいので
yt-dlp url -F

出力結果例：

30216  m4a audio only     │ ≈ 16.56MiB   66k https │ audio only          mp4a.40.2  66k
30232  m4a audio only     │ ≈ 21.11MiB   84k https │ audio only          mp4a.40.2  84k
30280  m4a audio only     │ ≈ 21.11MiB   84k https │ audio only          mp4a.40.2  84k
30011  mp4 640x360     30 │ ≈ 34.26MiB  136k https │ hvc1.1.6.L120  136k video only
100022 mp4 640x360     30 │ ≈ 30.42MiB  120k https │ av01.0.08M.08  120k video only
30016  mp4 640x360     30 │ ≈ 48.65MiB  193k https │ avc1.640033    193k video only
30033  mp4 852x480     30 │ ≈ 48.98MiB  194k https │ hvc1.1.6.L120  194k video only
100023 mp4 852x480     30 │ ≈ 43.01MiB  170k https │ av01.0.08M.08  170k video only
30032  mp4 852x480     30 │ ≈ 71.04MiB  281k https │ avc1.640033    281k video only
30066  mp4 1280x720    30 │ ≈ 82.85MiB  328k https │ hvc1.1.6.L120  328k video only
100024 mp4 1280x720    30 │ ≈ 70.91MiB  281k https │ av01.0.08M.08  281k video only
30064  mp4 1280x720    30 │ ≈132.65MiB  525k https │ avc1.640033    525k video only
30077  mp4 1920x1080   30 │ ≈168.07MiB  666k https │ hvc1.1.6.L150  666k video only
100026 mp4 1920x1080   30 │ ≈139.98MiB  554k https │ av01.0.08M.08  554k video only
30080  mp4 1920x1080   30 │ ≈285.27MiB 1130k https │ avc1.640033   1130k video only

そしたら左の数字（ID）を指定して個別にDL

#動画1080p av01コーデックを指定
yt-dlp url -f 100026

#音声を指定
yt-dlp url -f 30280

#ちなみに一緒にDLする時は
yt-dlp url -f 100026+30280

それぞれ、.mp4、.m4aファイルが出来上がります。

仮に test.mp4、test.m4a だとすると、

ffmpeg -i test.mp4 -i test.m4a -c copy sample.mp4

で劣化なく sample.mp4 を作ってくれます。
（-c copyはそのままコピーして出力ファイルに詰め替えるの意味で、再エンコードしません）

Mac使いの人はAutomatorで シェルスクリプトを実行 に組み込めば、作成された2つのファイルを選んで右クリックから簡単に結合することもできます。

普段アップデート通知切ってるのでなかなかリアルタイムでは気付けません。
iPhoneのアプデが来てたのでそういえばと思って確認したら来てました。

Sonoma 14.8.8へのアップデート

お馴染みの作業です。

必要に応じてバックアップは取っておきましょう。

まずはOpenCore Legacy Patcher(OCLP)のバージョンチェック

※最新のバージョンになっている必要性があります。

最新は2.4.1 が latest。変わってない
OK

システム設定 – ソフトウェアアップデートからアップデート

システム設定 > 一般 > ソフトウェアアップデート

TahoeじゃなくSonomaの方でアップデートしてくださいね。くれぐれもお間違い無く

「今すぐアップデート」から「同意する」

ダウンロードが始まります

アップデート準備中

終わったら再起動

OCLP Rootパッチを適用

再起動してきたらRootパッチを当てる

処理が終わったら再起動

無事にアップデート完了

バージョンをチェックします
無事に14.8.8 (23J620)になりました

システム設定の通知（赤いバッチ）を消す

更新通知の赤いバッチマーク、邪魔ですよね。
消してしまいましょう。

これも前回と同じ作業です。

1. ネットワーク切断（Wi-Fiをオフ、Lanケーブル引っこ抜く）
2. ソフトウェアアップデート を開き
3. 「自動アップデート」横のiマークから全てオフ設定を確認
4. ターミナルからsoftwareupdate -lを実行

% softwareupdate -l

Software Update Tool

Finding available software
インターネットに接続していないため、Appleソフトウェアアップデートサーバに接続できません。

これで赤いバッジが消えます。

まとめ

問題なくアップデートされました。

今の所、特に不具合は確認されません。たぶん大丈夫。

でもきっと・・・そろそろだよね。サポート切れるの。
次のSequoiaあたりはまだ安定して使えるのかな？