早速アップグレードしたところ、「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（Sealed System Volume）の項目（Sealed）がYesになっているはずです。

話を先に進めます。

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

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

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

まとめ

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

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

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

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

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

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

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

スイッチコントロール自体をオンにするにはサイドボタンを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

これで、

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

を直接開けます。

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

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あたりはまだ安定して使えるのかな？

前回の記事でOllamaを使ってみたものの、遅過ぎて使えない。
なのでllama.cppを直接ビルドして使ったら Ollamaの約4倍の速度が出た！ そんなお話です。

llama.cppのインストールからAIモデルを動かすまでをさらっとまとめてみます。

llama.cppがollamaより早いと聞いて

前回は iMac2017 に Ollama をインストール、ローカルでAIモデルを動かしてみました。

でも遅い、あまりにも遅い。
動いたことには感動だけれど 1.92 t/s くらいで字面を追うのは地味にストレス。

もう少し軽いモデルはないかと色々試してみました。

軽いモデルを使えば若干速度は上がるもののやはり性能が落ちます。
わけわかんないこと回答したり、なぜか英語と日本語のノイズ混じりの不思議な文章になっていたり。

軽さと賢さはトレードオフと知りながらも、何かないかと試していました。

結論としては・・・

ない！多分！（残念

やはり無理があったかと諦めかけたのですが、もう一つの可能性として 実行環境を変えてみたらどうなるだろう、と。
反応速度も上がるらしいと聞いたので llama.cpp を直接使ってみることにしました。

llama.cppについて

実は Ollama の内部では llama.cpp が推論エンジンとして動いています。

• llama.cpp = 「LLMをローカルで高速実行するための低レイヤー推論エンジン」
• Ollama = 「llama.cppなどを内部で利用して、モデル管理や実行を簡単にした上位ツール（ラッパー）」

Ollamaを使えば、手軽で簡単にローカルAIを試すことができます。
例えば画像を読み込ませれば楽々読み込んで説明してくれる。超簡単。

が、その反面動作はもっさりしてしまう。
スペックが足りてないのだから仕方ないけど。

そこで余計なものは省き、直接 llama.cpp を適切な設定で動かせばもう少し快適に走らせることができるかなと。

iMac2017のような古いPCではその差が顕著に出るかもしれない。

まずはHomebrew版 llama.cpp を試す

最初にHomebrewにある llama.cpp を試してみました。

brew install llama.cpp

でも結論から言うと、ダメ。

速度的には多少（気持ち程度）良くなった気がしますが、ただトークン/sを見てもさほど変わらない。
変わらないなら意味がない。（※1）

テキストチャットでの問答くらいなら問題はありません。

Githubからllama.cppを持ってきてビルド。メタルはオフ

さて、自分の環境に合わせてビルドしたらどのくらい変わるのか。
Githubなんて必要な時にたまに眺めるくらいで使ったことなんてなかったけれど、トライしてみます。

まずは cmake と git をhomebrewからインストール

brew install cmake git 

次に llama.cpp のリポジトリをクローン（手元にダウンロード）します。

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

自分の環境に合わせてビルドします。

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

オプションの説明

-DGGML_NATIVE=ON

実行しているパソコンのCPUが持つ高速化命令（AVX2やNEONなど）をフルに使うように指示します。速度アップ。

-DGGML_ACCELERATE=ON

Apple Accelerateフレームワーク(BLAS実装)をリンクするオプション。
高精度・超高速の数学計算用機能（Accelerate）を有効にします。CPUでの計算が速くなります。

-DGGML_METAL=OFF

MacのGPUを使う機能（Metal）を「オフ」にし、cpuオンリーで使用する。

最初はメタルをオフにせずビルドし、画像を読む --mmproj も使って画像を説明させようとしました。
ところが何回やってもエラーで止まってしまう。
そのまま設定を詰めていくよりいっそのこと cpuオンリー にしたほうが良いように思えたのでそのように。
結果としてうまく行きました。
足を引っ張るGPUを切ったからか通常のレスポンスも、僅かにですが、早いです。

兎にも角にもインストールは完了。

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

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

モデルファイル（gguf）をダウンロードして実行

さぁAIの脳みそとも言うべきモデルファイルを入手します。
Hugging Face からモデルを検索してダウンロードしました。

gemma-3-4b-it-qat-Q4_K_M.gguf　あたりが安定して動いてくれる気がします。
Googleが開発したオープンなAIモデル「Gemma 3」を、PCやスマートフォンなどの一般的な端末で軽量・高速に動かせるように最適化した、テキストおよび画像（マルチモーダル）対応のAIモデルファイルです。

ダウンロードが完了したらいよいよ実行します。

#パスは環境に合わせて
llama-cli -m ./models/gemma-3-4b-it-qat-Q4_K_M.gguf

起動したら　hi　とだけ挨拶してみます。

Loading model...


▄▄ ▄▄
██ ██
██ ██  ▀▀█▄ ███▄███▄  ▀▀█▄    ▄████ ████▄ ████▄
██ ██ ▄█▀██ ██ ██ ██ ▄█▀██    ██    ██ ██ ██ ██
██ ██ ▀█▄██ ██ ██ ██ ▀█▄██ ██ ▀████ ████▀ ████▀
                                    ██    ██
                                    ▀▀    ▀▀

build      : b9691-2e88c49c9
model      : gemma-3-4b-it-qat-Q4_K_M.gguf
modalities : text

available commands:
  /exit or Ctrl+C     stop or exit
  /regen              regenerate the last response
  /clear              clear the chat history
  /read <file>        add a text file
  /glob <pattern>     add text files using globbing pattern


> hi

Hi there! How’s your day going so far? Is there anything I can help you with today? 😊 

Just let me know what’s on your mind!

[ Prompt: 17.5 t/s | Generation: 8.5 t/s ]

> 

動きましたね。Ctrl+Cで終了します。

Generation: 8.5 t/s

なので Ollama の時（※1）の 1.92 t/s や、
homebrewで入れた llama.cpp の 1.5 t/s に比べると4倍以上の速度になりました。

速度感の比較

画面収録の影響が出てますがそれでも以前よりぜんぜんマシ

前回のollamaでの実行速度

ブラウザからアクセスして llama-ui（WebUI）も使える

これまでは llama-cli で動かしてきましたが、 llama-server で起動するとブラウザからアクセスして ChatGPT のような画面で使うこともできます。
httpサーバーを起動

llama-server -m ./models/gemma-3-4b-it-qat-Q4_K_M.gguf

ブラウザを立ち上げ、http://localhost:8080/にアクセスすると、llama-ui という画面にアクセスできます。
こっちの方が馴染みがありますね。画面を見ると相変わらず訳わかんないこと言ってますが笑

ちなみにWebUI使うとやはりちょっと遅いです。

WebUIと、ターミナルからcurlでアクセスしたものとの差を比較してみます。

別のターミナルウインドウを開き、

curl http://localhost:8080/v1/chat/completions -H "Content-Type: application/json" -d '{ "model": "gemma-3", "messages": [{"role": "user", "content": "部屋に5本のキャンドルが灯っています。風が吹いて2本が消えました。翌朝、部屋には何本のキャンドルが残っているでしょうか？ 理由も添えて答えてください。"}]}'

と打つと同じように答えてくれますが、

• WebUI → 約6.68 t/s
• curl → 約8.4t/s

1.25倍くらいの速度差があります。

まとめ

とりあえず簡単なチャットならストレスなく行えるようになりました。

本当は、ビルドしたら早くなったのでそうすると良いよーって言いたかったのですが、
この記事を書いている最中にアップデートしてみたらollamaもHomebrew版 llama.cppも普通に早くなったって言うね・・・

なんだったんじゃーーーー！

んまぁ、少しでも早く動くならいいか。

次の記事では画像を読ませて、その画像について説明させてみます。

ということで一連の流れを備忘録として記事化しました。
では。

Macでスクショを撮る時に、
アプリのウインドウ幅やドロップシャドウのオンオフだったりを調整したい時があります。

そんな時に役立つやり方。その備忘録。

ターミナルなどのウインドウサイズをピクセル単位で調整する

ターミナルのスクリーンショットを撮るのにウインドウの幅を決めたかったのです。
でも手動で、しかもピクセル単位で調整するなんて・・・なかなかに大変。

具体的には、画面収録する際に決めたサイズにしたいものの、一度閉じてしまうと再現するのが難しい。微妙に違ってしまう。

でも設定から決められるのは「列」と「行」。
「サイズを揃える」と言う意味では出来なくもないんだけど、結構アバウト。

なんとなくこう言うのはピシッと揃えたい。

と言うことでそんな時はターミナルから AppleScript を使えば正確なピクセル指定が可能です。

コマンドによる指定（例：{左始点、上始点、右終点840px（幅）、下終点500px（高さ）}）

osascript -e 'tell application "Terminal" to set bounds of front window to {0, 0, 840, 500}'

また、個人的にGoogle Mapのスクリーンショットを画像引用することも多いのですが、
その際にブラウザ幅を手動で変更するとこれまた微妙に違ってしまう。

そんな時にもこれ、便利です。
ちなみに、tell application "Firefox"...とした場合、「プライバシーとセキュリティ」の項目として許可を必要とする場合があります。

許可したときは

システム設定 > プライバシーとセキュリティ > オートメーション

に ターミナル があるのでここから変更が可能です。

SS（スクリーンショット）のドロップシャドウをオフ

スクショを撮る時、
command + shift + 4 を押してから スペースキー を押し、撮りたいウインドウにマウスオーバー + クリックで、そのウインドウのSSが撮れます。

デフォルトでドロップシャドウが付きます。普段はこれでOK
でもドロップシャドウを消したい時もある。

そんな時はOption キーを押しながらクリック するとドロップシャドウがオフになります。

もし常時オフにしたい場合はターミナルから↓

# 常時オフ
defaults write com.apple.screencapture disable-shadow -bool true
killall SystemUIServer

# 元に戻す
defaults write com.apple.screencapture disable-shadow -bool false
killall SystemUIServer

まとめ

微妙に面倒くさかったことが解決できました。

もちろん画像編集ソフトでリサイズすれば良いっちゃ良いんですが、載ってる字が細かいと文字が潰れちゃいそうで・・・。

一応解決したのでOK

何かのヒントにでもなれば幸いです。
こんなことで悩む人はあまりいないと思いますが（笑）
それでは。

このアップデートには重要なセキュリティ修正が含まれ、すべてのユーザに推奨されます。

Sonoma 14.8.7へのアップデート

いつものように作業します。
毎度のことなのでさらっと。

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

1. まずはOpenCore Legacy Patcher(OCLP)が最新かチェック

最新は2.4.1 が latest
大丈夫

2. ソフトウェアアップデートからアップデート

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

その他の利用可能なアップデート
アップデート項目を確認して「今すぐアップデート」

規約に同意

ダウンロード

アップデート準備中

再起動

3. OCLP Rootパッチを適用

再起動してきたらRootパッチを当てるよう促されるので「OK」

処理が終わったら
再起動

4. バージョンチェック

りんご > このMacについて から確認
無事 sonoma 14.8.7（23J520） になりました

システム設定の通知を消す

再起動直後には特に赤いマーク（バッジ）はついてません。
が、ソフトウェアアップデートを開くなどすると更新通知が付きます。

それを消すには

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

% softwareupdate -l

Software Update Tool

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

赤いバッジが消えます。

まとめ

今回も問題なくアップデート完了。
不具合はなさそうです。今のところ。

やってみたくなったので試してみました。

まぁ結論としてはもちろん動くし、使えます。いや使えるというのはちと・・・語弊がある？

OllamaのインストールからローカルでAIモデルを動かすまで、その一通りの流れを備忘録として記事化。

Local LLMを動かすにはApple Mチップ（Apple Silicon）が良い？

Apple独自のアーキテクチャがAI処理と非常に相性が良いらしい。

通常、CPUとGPU（グラフィック）のメモリは分けて搭載されているが、近年のMacはこれらが一体になった「ユニファイドメモリ」を採用。
これにより、搭載されているメモリのほぼ全てをAIモデルの読み込みに使えるため、大容量のモデルを快適に動作させることができる。

そしてLLMを動かすにはGPUの性能が重要。
Apple Mチップはチップ内に強力なGPUを内蔵しており、これが高速処理を可能にする、のだとか。

と、ここまで書いておいてなんですが、そんなこたぁどうでも良い。

だって手元にあるのは、貧弱なグラフィックボードを搭載し、Mチップを搭載していないIntel Mac（iMac2017）なのだから！それで動かした結果どうなのかという検証なのだから！

・・・。

負け惜しみはさておき、必要なものを見ていきます。

ローカルLLMを動かすために必要なツール

AIモデルファイルは例えるなら「脳」。
脳だけでは何もできません。動かすための「入れ物（実行環境）」が必要。それが Ollama などのツールです。

モデルファイルが「ゲームのディスク」、実行環境が「ゲーム機」と言ったらわかりやすいのかもしれない。イメージ的に。

そして今回使う Ollama は、

• モデルを管理し
• ダウンロードし
• 実行し
• APIとして提供する

それらが簡単に行えるツールの一つです。

Ollamaをインストール

モデルファイルは Ollama からダウンロード、実行することができるので、
まずは Ollama をセッティングし、その後いろんなモデルを試すことになります。

Homebrew版を使います。
Homebrewをあらかじめインストールしておいてください。-> https://brew.sh/ja/

ターミナルから

brew install ollama

% brew install ollama
✔︎ JSON API formula.jws.json Downloaded   32.0MB/ 32.0MB
==> Fetching downloads for: ollama
✔︎ Bottle Manifest ollama (0.23.2) Downloaded   13.9KB/ 13.9KB
✔︎ Bottle ollama (0.23.2) Downloaded   15.0MB/ 15.0MB
==> Pouring ollama--0.23.2.sonoma.bottle.tar.gz
==> Caveats
To start ollama now and restart at login:
brew services start ollama
Or, if you don't want/need a background service you can just run:
OLLAMA_FLASH_ATTENTION="1" OLLAMA_KV_CACHE_TYPE="q8_0" /usr/local/opt/ollama/bin/ollama serve
==> Summary
🍺  /usr/local/Cellar/ollama/0.23.2: 9 files, 40.5MB

Ollamaがインストールされました。

Ollamaを起動

インストールしたOllamaを起動します。

バックグラウンドで常時起動させておきたいなら下記のように入力しデーモンとして起動します。

ターミナルから

brew services start ollama

でも常に動かしておく必要は自分にはないので、使いたい時に起動します。

ollama serve

あるいはインストール時のログにあったように

OLLAMA_FLASH_ATTENTION="1" OLLAMA_KV_CACHE_TYPE="q8_0" ollama serve

と打ち込みます。

• OLLAMA_FLASH_ATTENTION=”1″
  Flash Attention という高速化技術を有効にするための環境変数
  主にGPU向けに最適化された技術なのでCPU環境ではおまじない程度
• OLLAMA_KV_CACHE_TYPE=”q8_0″
  キャッシュを量子化（圧縮）することでメモリ消費量を抑える

※環境変数については公式FAQを参照のこと。

モデルファイルをダウンロードして実行する

さて、今のターミナルウインドウはそのままに、新しいウインドウを開きます。

「Gemma 3:4b-it-qat」というAIモデルを試してみます。

1. 圧倒的な日本語の自然さ: 文脈の理解がスムーズ
2. Intel Macでも動く軽さ: 4b（約40億パラメータ）なので、専用GPUがないiMac 2017でも実用的な速度で返ってくる（※環境による）
3. QAT（量子化）の恩恵: qat 版は精度を維持しつつメモリ消費を抑えているため、Intel Macの限られたリソースに最適

ターミナルから

ollama run gemma3:4b-it-qat

ollama pull gemma3:4b-it-qat で取得だけもできますが、
ollama run gemma3:4b-it-qat とすると実行する際にまだDLしていなければ取得して実行してくれます。

% ollama run gemma3:4b-it-qat
pulling manifest 
pulling 529850705c08: 100% 4.0 GB
pulling 5be6630b666f: 100% 359 B
pulling 3116c5225075: 100% 77 B
pulling 34ec2fc9f116: 100% 413 B
verifying sha256 digest 
writing manifest 
success 
>>> Send a message (/? for help)

動きました。

>>> Send a message　となっているところに質問を書けば会話が始まります。

簡単ですね。素晴らしい。

会話を終えるには ctrl + d
ollama serveしたターミナルでは ctrl + c で終了します。

終了せずに間違ってターミナルを閉じてしまった場合は改めてターミナルを開き、pkill ollama か、
アクティビティモニタを起動して ollama のプロセスを終了させます。

ちなみにモデルは ollama の公式サイトから探せます。

AIのカスタマイズ、Modelfileの作成

そのまま ollama run しても動きますが、より使いやすく、反応の仕方や性格付けをするためにModelfileを作成します。

手順

適当なディレクトリに Modelfile（拡張子なし）というファイルを作成します。
ただそれだと後から分かりづらいので Modelfile.gemma3-creative のように名前をつけると良いかも。
こうすることで複数のModelfileを一箇所において管理できます。

以下の内容を書き込みます。

# ベースとなるモデルを指定
FROM gemma3:4b-it-qat

# パラメータ設定（創造性と正確性のバランス）
PARAMETER temperature 1.0
PARAMETER top_p 0.9
PARAMETER repeat_penalty 1.1

# システムプロンプト（ここで日本語の振る舞いを固定する）
SYSTEM """
あなたは日本語で自然に会話するアシスタントです。
必ず日本語で、わかりやすく説明してください。
機械翻訳のような不自然な表現は避けてください。
"""

パラメータはOllamaのModelfileリファレンスで確認できます。

まずは temperature をいじるのが一番変化を実感しやすいです。プログラミングや事実確認なら 0.1〜0.3、小説執筆やアイデア出しなら 1.0以上 を試してみてください。

カスタムモデルとして登録

ターミナルでModelfileがある場所に移動し、カスタムモデル（例：gemma3-creative）として登録します。

# カスタムモデルの作成 -f で作成したModelfileを指定
ollama create gemma3-creative -f Modelfile.gemma3-creative

# 実行
ollama run gemma3-creative

削除したい時は

# モデルのリスト表示
ollama list
# 削除したい時は
ollama rm gemma3-creative

実際に動かしてみた速度感（トークン/s）

実際に動かしてみた感じが伝わるようGIFにしてみました。伝わるかな？

1.98 tokens/s くらい。

遅いね・・・遅い。

英語なら？

うん、変わらんね。遅すぎる。

ちなみに最近公開された「Gemma4」も試してみました。

Thinking modeというAIが考えている内容（推論）を見ることができて大変興味深いのですが、回答が出てくるまでがもんのすごい遅いので・・・飽きます。最初は楽しいんだけどね。
オフにすることもできるし、そうすると回答までの時間が若干短縮されたように思えたけど遅いことには変わりなし。
ただモデルが悪いのではなく、遅い環境なのが問題なのでそこはお間違い無く。

まとめ

ごくごく簡単に iMac2017 でローカルLLMを動かす説明をしてみました。
速度はお世辞にも快適とは言えません。レスポンスを待つ時間は覚悟が必要です。ただ、ローカルで動く・データが外に出ない・APIコストがかからない という点は大きなメリットです。

なにより素人でも少しいじればAIをローカルで動かせるってすごいよね。

でも実は Ollama の中で動いている llama.cpp を自分の環境に合わせてビルドし、直接使うことによって速度を上げることができるのです。
正直使い道も何もあったもんじゃないなと思っていたのに試してみてビックリ。

4倍くらいは早くなったので、すこしは光明が見えてきたかも？

そのあたりは次の記事で。

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

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

www.wholenotism.com

2026.06.18

しばらく待てば extractor のファイルも更新されるかな・・・と思ってたけどなかなか更新されない。

まぁいい機会だから対処法でも探そうかと。

一応解決したので備忘録も兼ねてシェア。

bilibiliでyt-dlpを使おうとすると412エラー

普通に使おうとすると412エラーが発生。

% yt-dlp -F https://www.bilibili.com/video/ほにゃらら/
[BiliBili] Extracting URL: https://www.bilibili.com/video/ほにゃらら/
[BiliBili] にゃらら: Downloading webpage
[BiliBili] ほにゃらら: Extracting videos in anthology
[BiliBili] ほにゃらら: Downloading wbi sign
[BiliBili] ほにゃらら: Downloading video formats for cid xxxxxxxxxxx
ERROR: [BiliBili] にゃらら: Unable to download JSON metadata: HTTP Error 412: Precondition Failed (caused by <HTTPError 412: Precondition Failed>)

かつて「クッキーを渡せばいける」という話もあったようなのでやってみたけど結果は同じ。

困ったねぇ

対処法：Origin ヘッダーを付与

色々試してみた結果、解決法としては
オプション --add-header "Origin:https://www.bilibili.com" を付与したら通りました。

% yt-dlp -F --add-header "Origin:https://www.bilibili.com" https://www.bilibili.com/video/ほにゃらら/
[BiliBili] Extracting URL: https://www.bilibili.com/video/ほにゃらら/
[BiliBili] にゃらら: Downloading webpage
[BiliBili] ほにゃらら: Extracting videos in anthology
[BiliBili] ほにゃらら: Downloading wbi sign
[BiliBili] ほにゃらら: Downloading video formats for cid xxxxxxxxxxx
[BiliBili] xxxxxxxxxxx: Extracting chapters
[info] Available formats for ほにゃらら:
ID    EXT RESOLUTION FPS │   FILESIZE   TBR PROTO │ VCODEC        VBR ACODEC      ABR
─────────────────────────────────────────────────────────────────────────────────────
30216 m4a audio only     │ ≈687.63KiB   66k https │ audio only        mp4a.40.2   66k
30232 m4a audio only     │ ≈  1.27MiB  124k https │ audio only        mp4a.40.2  124k
30280 m4a audio only     │ ≈  1.27MiB  124k https │ audio only        mp4a.40.2  124k
30016 mp4 640x360     30 │ ≈  2.87MiB  282k https │ avc1.640033  282k video only
30032 mp4 852x480     30 │ ≈  4.13MiB  405k https │ avc1.640033  405k video only
30064 mp4 1280x720    30 │ ≈  7.76MiB  761k https │ avc1.640033  761k video only
30080 mp4 1920x1080   30 │ ≈ 16.44MiB 1613k https │ avc1.640033 1613k video only

最初はクッキー、ユーザーエージェント、Refererヘッダー、Originヘッダーを付けてみましたが、削っていったら Origin だけでも通りました。

Origin:「リクエストがどのドメインから発行されたか」を見ている、ということですね。

「外部からの不正な直リンク（スクレイピング）」として 412 で弾かれていた、という理屈でしょうか。
デフォルトでOriginも送信はしているようです。が、オプションから付与したおかげで何か漏れていた部分で通ったのかもしれません。

たしかにブラウザでも、ユーザーの「動画リスト」ページにブックマークから直接飛ぶと空っぽと表示され、別ページに一旦移ってから再度移動すると表示されるという現象が起きています。

まとめ

今回は 412エラー（前提条件失敗） が発生し、Originヘッダーを付与したら通ったという結果になりました。

今後さらに厳格化されてリファラーやクッキーを見ることがあるかもしれません。

そうなったら

• クッキー：--cookies-from-browser ブラウザ
• ユーザーエージェント：--user-agent
  （Firefoxなら ヘルプ > トラブルシューティング情報 > ユーザーエージェント（の文字列））
• リファラー：--add-header "Referer:https://www.bilibili.com"
• オリジン：--add-header "Origin:https://www.bilibili.com"

あたりを付与していくと何とかなるかも。ならんかも。

他のツールで何か対応してるものないかと探してみたんですけど今は yt-dlp 一強みたいな感じなんですかね。
streamlinkも「プラグインないよ！」って拒否られたし、lux（旧Annie）みたいなものももはや更新されてなさそうだし。

そのうち優秀なエンジニアさんが Extractor の bilibili.py を更新してくれるはず。
それまでは Originヘッダーを付与 で凌ぎましょう。

では。

追記（20260616）：extractor/bilibili.pyを書き換える方法

yt-dlp 2026.6.9にアップグレードしたけれど「bilibili.py」はアップデートされず、そのままでした。残念。
412エラーは前述のように OriginヘッダーとRefererヘッダーを付ければ通りますが、480pまでしかリストが取得できないのでbilibili.pyを直接いじります。

bilibili.py 179行目

'https://api.bilibili.com/x/player/wbi/playurl', bvid,

を

'https://api.bilibili.com/x/player/playurl', bvid,

に変更すれば、
Originヘッダー、Refererヘッダーをつける必要もなく、またリストフォーマットで1080pなども（あれば）表示されるようになります。
（当たるサーバーによってなのか何なのか、412が出る時もありますが2回ほどトライすると通ります。）
（参考：github「bilibili video download fail #16962」）

追記（20260802）

bilibili.py は更新されています。yt-dlpをアップデートしてください。
上記のURL書き換えは必要ありません。

が、別のエラーが発生しています。今の所リトライし続けるしかなさそうです。接続先のCDNエッジによっては完走できる、かも？
-vオプションをつけて、
[debug] Invoking http downloader on "https://upos-sz-mirrorcosov.bilivideo.com/...とか.bilivideo.comだったら途中で停止、
https://upos-hz-mirrorakam.akamaized.net/...とかだったら転送速度は遅いけど完走できる、ような気がします。

yt-dlpでbilibiliの動画ダウンロードが途中で止まる原因を調べたら、CDNキャッシュが関係していそうだった件

bilibiliの動画をyt-dlpでダウンロードしていると、特定のCDNから配信される場合だけ、ダウンロード途中で速度が極端に低下したり、The read operation timed outが発生したりすることがあった。Got err...

www.wholenotism.com

2026.08.03