Windows と Mac の2台運用でたまった環境の摩擦を、朝のうちに片づけた記録

主作業機を Mac に移してからも、Windows のノートPCは併用している。夜のあいだ Mac で進めた分がリモートにあり、朝は Windows 機の前に座る。この日も、最初に手をつけたのは実装ではなく、噛み合っていない環境の帳尻合わせだった。

ホットキーが効かない

Ctrl+Shift+V を押しても何も起きなかった。このホットキーは、クリップボードの画像をファイルに落として Claude Code へ渡すために使っている。常駐しているはずの AutoHotkey が上がっていないのではないか、と疑った。起動しているかどうかと、このホットキーがどのスクリプトで定義されているかを調べさせた。

落ちてはいなかった。再起動後の立ち上がりが遅れていただけで、調べた時点ではもう常駐していた。もう一度押すと、何事もなかったように効いた。その直後に貼ったスクリーンショットは、ちゃんと clip_20260809_064920.png として保存されている。

再起動の直後は「壊れた」と「まだ来ていない」の区別がつかない。今回は後者だった。

今動いているモデルは、定額の枠内なのか

ついでに気になっていたことを聞いた。 Fable 5 はいつまで使えるのか。

無料の提供期間は7月19日で終わっていた。その後は Max プランに恒久搭載された、という答えだった。ところが画面には、クレジットを買うか Opus 5 に切り替えるかを迫る関所が出る。クレジットは買っていない。それなのに、このセッション自体が Fable 5 で動いている。

ヘルプ記事を確認させて、からくりが分かった。 Max プランには、週次の使用上限の50%まで Fable 5 を追加料金なしで使える枠が標準で入っている。動かしていたのはクレジットではなく、この枠のほうだった。だから「いつまで」は日付ではなく量で決まる。使い切ればまた関所が出るし、週次のリセットで復活する。

残高ゼロの表示は「もう使えない」ではなく、「別売りのクレジットは持っていない」だけを意味していた。

画面への映り込みが気になると相談したとき、助言を5点もらっていた。日中はブルーライト低減を切る、輝度を上げる、背景の純黒をやめる、照明の位置を変える、ガンマと黒レベルを一段上げる。このうち一番の悪手として名指しされたのが、日中もブルーライト低減をかけたままにしていたことだった。輝度が落ちるうえに、黄ばみで文字のコントラスト感まで鈍る。夜だけ OS 側の夜間モードで時間を指定するほうが、モニター側でかけるより副作用が小さい。

使っているモニターは3枚あるが、外から設定を変えられたのはウルトラワイドの1枚だけだった。残り2枚は制御の問い合わせに応答しない。専用ソフトは入れず、Windows の API を PowerShell から直接叩くスクリプトを書かせて操作した。

ここで妙なことが起きた。ピクチャーモードに当たる制御コードは、読み出した値が実際のモードを表していない。元に戻せることを先に確かめるつもりで、読み出したのと同じ値をそのまま書き戻させた。本来なら何も起きないはずの操作で、モニターはリーダーモードからユーザー設定へ切り替わった。狙って解除したのではなく、安全確認のつもりの操作でブルーライト低減が外れた、というのが正確な経緯だ。

外れた瞬間、画面が眩しくなった。黄色いフィルターが取れて、白が本来の白に戻ったからだ。助言の2つめは「輝度を上げる」だったが、フィルターを外した時点で実効輝度はもう上がっている。額面どおりに足すと過剰になるので、逆に 90 から 75 へ下げさせた。

ガンマと黒レベルは、この経路からは触れなかった。モニター本体のボタンから操作するしかない。夜間モードの時間指定も見送った。設定の実体がバイナリで、壊すと設定アプリ自体が開かなくなる。

変更前後の全設定値とターミナル設定のファイル、操作に使ったスクリプト、一括で戻すスクリプトを memo に残させた。ピクチャーモードだけはスクリプトで戻せない、という但し書きも含めて。読み出しが当てにならない以上、リーダーに対応する値が分からないからだ。

ターミナルと、その隣の純黒

ターミナルの既定の配色は、背景が完全な純黒だった。助言の3つめがそのまま当てはまる。背景を #1E1E1E にした配色を新しく作って既定に据えた。背景を持ち上げた分だけ黒い文字が埋もれるので、ANSI の黒と青も合わせて調整させた。青は背景に対するコントラスト比が 2.87 しかなかったので、4.58 まで引き上げた。

片方を濃いグレーにしたら、隣が問題になった。ウルトラワイドの右半分に出している X が、完全な純黒だったからだ。左だけグレーに変わったことで、右の黒さが際立った。

サイト側の設定では直らなかった。背景の選択肢は「明るい」と「ブラック」の2択で、昔あった濃紺グレーの選択肢は廃止されている。クッキーで旧設定を書き戻させても、サーバーが即座に上書きした。

他人の拡張を入れる手はある。ただ、この種の拡張は全サイトの読み取りと改変を要求する。仕事で使っているブラウザには入れたくない。自作の拡張ならどうか、と提案した。 X 向けに自分で作った拡張がすでにあり、対象サイトの権限も content script も持っている。 CSS を1枚足すだけなら、権限は1つも増えない。

どこが黒を当てているかは、推測ではなく DevTools の実測で確かめさせた。 body はインラインで純黒を持ち、コンテナは1つのクラスに集約されていた。ほかに純黒のインライン要素が38個あったが、すべて 40×40 のアバターの下地で、アイコン画像の下に隠れて見えない。上書きが要るのは2つだけだった。

残っていたヘッダーの黒

見落としがあった。上部の固定ヘッダーだけが黒いまま残っていたので、それを指摘した。

原因は、測る要素を間違えていたことだった。決め打ちした祖先要素の背景を測って「透明」と出たので、問題なしと判断していた。スクリーンショットでは明らかに暗く見えていたのに、測定結果のほうを信じて自分の目を否定したことになる。

正体は、65% の黒を重ねたすりガラスだった。半透明なので、下地を #1E1E1E にしても合成後は rgb(10,10,10) にしかならず、ほぼ黒のまま残る。下地ではなく、重ねる色そのものをグレーの半透明に差し替えて解決した。このクラスが使われているのはページ内の3箇所だけで、画像を全画面で開いたときの暗幕は別のクラスを使う。暗幕のほうは黒いまま残る。

反映には拡張のリロードとタブのリロードの両方が要る。拡張だけ読み直しても、開きっぱなしのタブには新しい CSS が入らない。リロードはスキル経由でやらせた。拡張の管理画面にエラーバッジが出ていたが、中身は前からある通信と通知まわりのエラーで、今回の追加が原因のものはゼロだった。

コミットは学習ゲートを飛ばして通した。それより頼んだのは、戻し方を残すことだ。どう設定したかと、どう戻すかが書いてあれば、気が変わったときに同じ場所へ戻れる。

Mac で進めた分を、Windows へ引き取る

夜のあいだの作業は Mac 側にあって、リモートに push してある。直近8日間に更新のあったリポジトリを洗い出して、ローカルへ取り込ませた。プルが7本、こちらに無くて新規に落としたものが5本、すでに最新だったものが5本だった。

ついでに拾いものがあった。音声通知のリポジトリで、Mac 側では失われたことになっていたセリフ定義20本が、この Windows 機に残っていた。 2台運用では、片方がいつも正で、もう片方がその写しだとは限らない。

もう一度、更新漏れがないか確認させた。リモートにあってローカルに無いものはゼロだった。ただし逆方向、こちらからまだ返していないものは残っていて、そこは積み残しゼロではない。

1個古いはずだった HTML

Mac で作ったはずの HTML を1本、ローカルで開いてほしいと頼んだ。自炊した本の巻末付録から起こした、ダイヤル錠のパターンをまとめたページだ。記憶では150パターンのはずだったが、開いてみると数字が違った。 100万通りが125通りまで絞れる、という中身だった。

そのページには、ヘッダーに4本のリンクを並べて相互に行き来できる版があったはずだった。手元のものにはナビが出ていない。バージョンが1つ古いのだろう、と思った。

ブラウザ越しに Mac 側のセッションへ調べさせて、両機のファイルを突き合わせた。 Mac と Windows で完全に一致していた。古かったのではない。ローカルサーバーで配信して開いていたせいで、ナビが消えていただけだった。あのナビは file:// で開いたときにだけ出る作りになっている。

file:// で開き直すとナビは出た。代わりに文字化けした。 Windows で開くと化ける、というところまでは分かったが、原因はまだ追っていない。

dev と共有される tsconfig

前夜のデプロイが Server Build で落ちていた。原因は .nuxt/tsconfig.app.json が壊れた JSON になっていたことで、dev サーバーとの競合だった。 generate はビルド用のディレクトリを別に使うようにしてあるのに、tsconfig だけは dev と共有されている。 dev がそのファイルを書いている最中に generate が読むと、書きかけの JSON を掴んで落ちる。

dev を止めて再実行したら 20.9 分で通った。そこで聞いた。根本的な解決が分離だとしたら、それはもうやったのか。

やっていなかった。 dev を止めただけの回避で、恒久対応は案を書いただけだった。そのうえで調べさせると、分離は素直に取れないと分かった。

apps/web/tsconfig.json が .nuxt/ を references で直接指している。静的な JSON なので環境変数を読めず、ビルド用ディレクトリを切り替えても参照先は変わらない。 vite や esbuild は、ソースファイルの位置から親を辿ってこの tsconfig を見つけ、そこから .nuxt/ を読みにいく。環境ごとに参照先を変えるには、ビルドのたびに tsconfig そのものを書き換えるしかない。 git の管理下にあるファイルを毎回書き換えるのは避けたい。

ここで引っかかった。運用ドキュメントには「tsconfig は分離されていない」という事実だけが書き足されていた。事実だけ渡されても、読んだ側は何をすればいいか決められない。分離しない理由まで書いてあれば、落ちたときに「dev を止めて再実行する」で終わる。 理由のほうを書かせた（72bab8bb）。

あわせて2つ断った。デプロイ前に「dev が動いているので落ちる可能性があります」と警告して判断を仰ぐのは要らない。 dev を動かせと言ったのは自分なので、動いていていい。落ちたら落ちたで、止めて再実行すればいい。 Claude 側が勝手に dev を止めるのも要らない。他のセッションが確認用に立てたものを奪えば、起動と停止の奪い合いになる。

壊れていたものと、見方がずれていたもの

この朝に手をつけたものを並べてみると、壊れていたものはほとんどなかった。起動が遅れていただけのホットキー、別売りのクレジットが無いと告げていただけの表示、読み出しが実態を返さない設定値、測る要素を間違えたヘッダー、配信の仕方で消えたナビ。ずれていたのは、こちらの見方のほうだった。 tsconfig だけは本当に噛み合っていないが、それも分離できない理由が分かった時点で、運用で回す話に変わった。

輝度 75 が適正かどうかは、まだ分からない。数日使ってから決める。

#Windows #macOS #AutoHotkey #Chrome拡張#ディスプレイ設定 #Nuxt