先週の私はずっとトラブルシューティングの気分だった。中でも重要な問題は Apple の iCloud Private Relay が多くのユーザーに接続エラーを起こしていたことで、ここでは iCloud Private Relay を一時的にオフにする方法を紹介する。また、Mail で Previous Recipients (宛先の履歴) ウィンドウを開いてから Contacts で連絡先を編集すると Mail がクラッシュするという再現可能なバグについても報告する。それからもう一つ、トラブルシューティングはもっと注意深くすべきだという教訓として、Adam Engst が太陽光インバータ接続の問題に取り組んだ体験を語る。結局のところ問題の原因は、無停電電源装置 (UPS) のオプション選択に関係していた。さらに、ウェブ版 Apple Maps がベータ版で登場したニュースと、Reddit が Google 以外の検索エンジンによる索引付けをブロックするというニュースを簡潔に紹介する。今週注目すべき Mac アプリのリリースは Airfoil 5.12.2, Audio Hijack 4.4.3, Fission 2.8.6, Piezo 1.9.3、Little Snitch 6.0.3、Mimestream 1.3.7、それに Pixelmator Pro 3.6.5 だ。
Apple は、Apple Maps on the Web のベータ版を立ち上げて、Apple 機器上で Mapsアプリを使用出来ない、または使用したくない人に対して地図サービスを始めた。Apple によると、このベータ版のウェブサイトは現在英語でのみ利用可能で、macOSまたは Windows が走る Safari および Chromium ベースのブラウザと互換性があるという。しかしながら、私の M1 MacBook Air 上で VMware Fusion 経由のWindows 11 の中で走る Microsoft Edge でテストしたがうまく機能しなかった。Firefox はどのプラットフォームでも未だサポートされていないが、Apple はより多くの言語、ブラウザ、プラットフォームに対する対応を約束している。
プレスリリースで、Apple は次のように言っている：
今や、ユーザーは運転や徒歩での道順を得られます；写真、営業時間、評価、口コミ等を含む素晴らしい場所と有益な情報を見つけられます；Maps の場所カードから直接食べ物を注文する等の行動を起こせます；そして、世界中の都市で食事、買い物、探索する場所を見つけるために企画監修された Guides をブラウズ出来ます。Look Around を含む追加機能は、今後数ヶ月以内に利用可能になります。
一見すると、Maps on the Web は Mac 上の Maps と非常によく似ているように見えるが、場所の共有が改善している兆しが窺える。現在、Mac の Maps から場所へのリンクを共有すると、Apple ユーザーに対しては Maps アプリで開くだけである。Windows ユーザーは Web ブラウザで開くことが出来るが、共有場所とは無関係なことは殆ど何も出来ない。
Maps on the Web のベータ版では、ブラウザのアドレスバーから一つの場所へのURL を共有すると、その受信者はプラットフォームに関係なく、よりフル機能の地図体験が得られる。Windows を使っている場合は、Ithaca に対する現在のmaps.apple.com リンクをこの beta.maps.apple.comリンクと比べて見て欲しい。(この２つの URL で違うのはドメインだけなので、ベータサービスを使うためにURL を編集するのは容易である。) 願わくば、皆さんは以下のエラー画面を見ることがないように望みたい。蛇足だが、この画面では "is" の大文字化か "Busy"の小文字化が是が非でも必要である。
討論に参加
先週後半、多くの Apple ユーザーが、Safari が一部のページを読み込めない、一部のアプリで接続が遅い、または接続されない、エラーメッセージ等々の接続の問題を報告した。Apple の System Status ページで報告されているように、この問題は iCloud Private Relay の停止に関連していることが判明した。２日後、Apple はこの問題を解決したと述べた。
iCloud Private Relay は、２つの Internet リレー、１つは Apple によって運営され、もう１つはサードパーティのサービスによって運営される、を介してトラフィックをルーティングすることにより、iCloud+ 加入者のプライバシーを高める ("連動し合う Apple プライバシー設定で起こる接続性の問題を解決する" 20 June 2022 参照)。iCloud Private Relay は一般的には良いことだが、多くの通信にもう一つの障害発生点を加える。Apple は、このサービスを説明するホワイトペーパーでこれを認めている：
しかしながら、以下に詳述するように、Private Relay が適用出来ない、或いはサービスが利用出来ない場合があります。そのような場合、Private Relayは、ユーザーに明確なステータス情報と制御を提供し、そして、ネットワーク上のすべてのトラフィックを監査する能力を必要とする可能性のある企業やネットワーク事業者に適切な制御を提供すべく設計されています。
この "明確なステータス情報" は、iCloud Private Relay が利用出来ないことに関して一部の人々が見たエラーの理由を説明している。私はこれらのメッセージの１つを受け取った事がないので、それが本当にどれほど明確かは分からない。そうではあるが、問題が発生した場合、iCloud Private Relay は簡単に不能に出来る。
Mac では、System Settings > あなたの名前 > iCloud > Private Relay に行き、スイッチをオフにする。iPhone や iPad でも、Settings > あなたの名前 > iCloud > Private Relay でのインターフェースはほぼ同じである。iCloud Private Relayは明日まで、或いは無期限にオフにすることが出来るが、後者では後でオンに戻すことを忘れない必要がある。
iCloud Private Relay は Apple とサードパーティのリレーを介して全てのトラフィックをルーティングするわけではないことを認識することは重要である。Appleは、"Private Relay は、Safari 内のすべての Web ブラウジングとアプリ内の暗号化されていないアクティビティを保護します" と述べている。この文の２番目の部分が何を包含するかは不明だが、最初の部分は、Arc、Brave、Firefox、或いはGoogle Chrome を使うのであれば、あなたのトラフィックはリレーを介して匿名化されないであろうことを意味する。
一般的に言えば、私は iCloud+ 経由で追加の iCloud ストレージの料金を支払う人は、iCloud Private Relay を有効にすることをお勧めする。それはあなたのトラフィックの一部分のみを保護するとしても、何もないよりはましであり、このサービス停止はあったが、日々の使用に影響を及ぼすことはないはずだ。同時に、私はそれを使う事での現実世界の利益を実際に目にしたことがあるとは言えないので、ただ単に iCloud Private Relay の保護のために iCloud+ を定期購読することはお勧め出来ない。
討論に参加
去年の末ごろ、ある TidBITS 読者が macOS 14 Sonoma の Contacts (連絡先) アプリにおける再現可能なバグを知らせてくれた。そのことを私が記事“Sonoma で Contacts がリストを印刷する時のフリーズから回復する方法”(2023 年 12 月 6 日) に書いた後、Apple が macOS 14.3 でそのバグを修正した。今回も、Contacts アプリと Mail アプリに関連するもう一つのバグを Apple に潰してもらう役に立つことができればと思う。
TidBITS Talk 上で Will_B が報告してくれた今回のバグが普通と違っているのは、2 つの Apple 製アプリ、Mail (メール) と Contacts (連絡先) の間の連携した活動が必要な点だ。次のようにすればバグを再現できる。まず、Mail アプリで Window > Previous Recipients (宛先の履歴) を選ぶ。次に Contacts アプリで、新規の連絡先を追加するか、または既存の連絡先のフィールドのどれかを編集する。そして Contacts アプリで Done ボタンをクリックすると、Mail アプリがクラッシュする。私自身はこのクラッシュから生じる悪影響を何も経験していないけれども、クラッシュの時点で Mail が何をしていたかによっては何らかの破損が起こりかねないことを忘れてはならない。
クラッシュが起こるためには Previous Recipients (宛先の履歴) ウィンドウを開いたままにするか閉じるかは関係しないし、Mail アプリと Contacts アプリのどちらを先に開いたかも関係しない。編集した連絡先の置かれた位置も関係ない。iCloud の連絡先でも Google の連絡先でも私はクラッシュを経験した。時間も要因とはならず、Previous Recipients ウィンドウを開いて閉じてから何日も経って Mail のクラッシュを経験したユーザーもいる。興味深いことに、 Cardhop で連絡先を編集しても同じようにクラッシュが起こるのに、BusyContacts はクラッシュを起こさないと Seth Anderson が TidBITS Talk で報告している。
Will_B によれば macOS 12 Monterey でもベータ版の macOS 15 Sequoia でも同様にクラッシュを再現できたとのことだし、他の人たちが macOS 13 Ventura や macOS 14 Sonoma で再現することを確認している。macOS 11 Big Sur では起こらないと報告している人たちが何人かいるが、長く続いているバグであることは間違いない。私たちの何人かがこのバグを Apple に報告済みだ。
このクラッシュはそれほど一般的に起こるものではないかもしれない。多くの人は Previous Recipients (宛先の履歴) ウィンドウをほとんど使わないのではないかという気もする。Mail アプリはこのウィンドウのためにアプリ内の連絡先リストを維持していて、あなたがメッセージを作成する際に宛先アドレスを提案したり自動補完したりするために使っている。Previous Recipients ウィンドウを開きたいと思う主な理由は、Mail からの提案で誰かのもう使わない、あるいは誤った宛先アドレスが出た場合だ。それをなくすためには、Previous Recipients ウィンドウからそのアドレスを削除する必要がある。当然ながら、Add to Contacts (“連絡先”に追加) ボタンをクリックして項目を Contacts に追加させてから Contacts アプリに切り替えてその連絡先情報を書き加えれば Mail アプリがクラッシュする。
現時点で Mail アプリのクラッシュを防ぐ唯一の方法は、Previous Recipients ウィンドウを開いた後でいったん Mail アプリを終了してから開き直すことだ。それをしないと、あなたが次に Contacts アプリを開いた際に突然 Mail アプリが自分自身のコードにつまずくことになる。
討論に参加
私は自分がトラブルシューティングに関しては人並み以上なのだと思いたいが、最近失敗した経験があって、どうにも扱いにくい問題を個々の要素に切り分けて調べることがいかに重要かという基本を改めて思い知らされるに至った。私が経験したものと正確に同じ問題に遭遇する人は誰もいないだろうと思うので、どうぞこの私の体験談を一般的教訓として受け取って頂きたい。
要約して言えば、我が家の太陽光パネルのインバータに通信障害が起こり、私はそれをネットワークの問題と思ったのだが、結局のところ問題の原因は無停電電源装置 (UPS) のある機能に付随した電源の問題だと分かったのだった。恥ずかしいことに、太陽光パネルの修理技術者に来てもらい、彼がシステムの部品の一つ一つを調べてくれるまで、私は問題の原因に全く気づかなかった。
問題の背景
2015 年に、私たちは 18.9 KWh の太陽光パネルを設置して、地熱ベースの暖房と冷房のために自宅で使う電力と２台ある車の片方、2015 年型 Nissan Leaf のための電力のほとんど全部を賄えるようにした。(ここで「ほとんど全部」と言ったのは、設置時点で将来の使用量を予想しなければならなかったのだが私たちの予想が少し低過ぎたからだ。今では通常、真冬になれば NYSEG からの請求額が数百ドル程度になる。これは夏の間の発電供給分クレジットを使い切った後での金額だ。)
全体的に見てこの太陽光パネルは問題なく働いており、 (パネル１アレイあたり１台で) ３台の SMA Sunny Boy インバータに給電して、これらのインバータが家に電力を供給するとともに、余剰分を近隣のための送電網に供給する。インバータは発電量の統計データをウェブベースの Sunny Portal に送り、そこから毎日の集計が電子メールで私に届く。私は具体的な数字に興味はないが、何か問題が起こればこの電子メールメッセージでそれと分かる。インバータが故障したこともあったし、ポータルとの接続が切れることも時々あるし、一度などは私がトラブルシューティング作業の後にメインの切断スイッチを入れ直すのを忘れていたこともあった。
私たちはバッテリーによる蓄電装置は導入しなかった。もしそれがあれば停電の際にも自宅に給電できて便利なのだが、導入しなかった理由はその当時には停電することが稀で停電してもごく短時間で済んでいたからだ。ただ、個々のインバータに標準的な電源コンセントを取り付けて、停電の最中にも発電中の電力を個別の目的に使えるようにはしておいた。冬期にはスマートフォンを充電するのに十分な電力 (太陽光パネルが雪に覆われてさえいなければ 100-300 ワット程度の出力で、スマートフォンの充電器が消費するのは 5-60 ワット程度)、夏期にはガレージの大型冷凍庫を動かすのに十分な電力 (3000-5000 ワット程度の出力で、冷凍庫が消費するのは通常 150 ワット程度、モーター起動時には一時的におそらく 300 ワット程度) が得られた。
停電は接続を損なう
7 月 10 日から 7 月 16 日までの間に停電が３回あった。最初のものは竜巻警報発令下で起こったが、実際には地元の道路局が舗装工事をしていて、トラックが通過中に我が家に繋がる電線を引っ掛けて切ってしまったのだ。おやおや！ 残りの２回の停電は今や気候変動の結果として一般的になりつつある暴風雨によるものだった。私はここから 12 マイル離れた農場で生まれ育ち、父と一緒に干し草を作るため夏の気候をしっかり観察する習慣がついたけれども、今日の気象パターンは当時のものとは比べ物にならないほど不安定で、それを象徴するかのように今これを執筆している間もご覧の通り次々と気象警報が発令されている。この記事を書き終えたそのすぐ後にもまた停電が起こった。まさに停電が日常になりつつある。
この春にあった停電の後で (これまで私たちは 2024 年中に６回の停電を経験しているが、これは新記録だ)、SMA インバータの接続が切れた。そこで私はインバータにリセット手順を施してポータルとの通信を回復させる必要があった。幸いにもこれを設置した会社である Halco が何を試みるべきかを電子メールで知らせてくれたので、技術者が来てくれるのを待たずに自分で３個のスイッチとブレーカーを正しい順番で切り替えるだけでよかった。
さてそれから季節が進み、最近のもののうち最初となった 7 月 10 日の停電の後に、またもやインバータの接続が切れた。私はまた同じ問題が起こったと思い込んで (それがいけなかった！)、同じリセットの手順を実行した。でも、翌日 7 月 11 日にまた停電になったので、リセットが本当に働いたのかどうか分からなくなった。その後１日かそこら経ってもう一度リセットの手順を実行してみたが、インバータはまだポータルに表示されないままだった。けれどもその後は週末にかけて仕事が忙しく、7 月 15 日になるまでこのシステムを調べる暇がなかった。結局リセットの手順が機能したのか否かを見ることができないまま、その日にまたまた停電が起こり、この停電が私が経験した中では最長の 29 時間も続いた。
この最後の停電の最中、私はインバータの電源コンセントを使って初めて大型冷凍庫に給電をしたので、その日はほとんど一日中インバータをいじっていたようなものだった。送電網への接続を外すと、給電量のみが報告され発電量が報告されなかったので、いったいなぜこうなったのか、本当に冷凍庫の運転を維持できる程度の電力が供給されているのかを確認するためにかなりの時間がかかってしまった。雲が出たり暗くなったりして太陽光発電が危険なほど低レベルになったのかもしれないと思って試しに iMac 用に置いているが使っていない UPS に冷凍庫を接続してみたが、なぜかこの iMac 用 UPS で冷凍庫を動かすことはできなかった。理由は今も分からない。ひょっとするとこの UPS は冷凍庫の消費電力が大き過ぎることを検知したのかもしれないが、150 ワット程度ならば問題なく供給できるはずなのだが。
停電から復旧した後の 7 月 17 日に、私はもう一度リセットの手順を実行したが、やはりうまく行かなかった。さらに何回か試してみてもダメだったので、仕方なく私は Halco に助けを求めた。彼らは私が基本的な手順をすべて試みたことを確認してから、技術者を派遣すると言ってくれた。幸いにも彼はその数日後に時間の余裕ができて、予約した日よりずっと早く来てくれた。そしてすぐさま彼は私が知らなかったテクニックを披露した。つまり、インバータの前面を特定のやり方で叩けば次々に状況メッセージを表示させることができ、そのメッセージの一つが IP アドレスを表示していたので、接続は正しくできていたことが確認された。その通り、トラブルシューティングの手順の一つはケースをぶっ叩くことであって、これはその昔のコンピュータ初期の時代にしていたことと変わらないやり方だ。
コンセントに差し込まれているか？
「問題はどこか内部にあるに違いない」と彼は言い、私たちはネットワーク機器のチェックに取り掛かった。私はインバータから出ている Ethernet ケーブルが Ethernet スイッチに差し込まれているところを見せたが... あれ？ どうしてこのスイッチのアクティビティライトがどれ一つとして点灯していないのだろう？「ひょっとすると停電で焼け切れてしまったのかもしれない」と彼は言ったが、このスイッチは UPS に繋いであると私は反論した。私たちはこのスイッチの電源ケーブルをずっと UPS のところまで辿った。UPS にはこのケーブルの隣に温度監視システム用ハブ (2018 年 7 月 25 日の記事“Wireless Sensor Tag、フリーザーの故障に対処”参照) の電源ケーブルも差し込まれていたが、そちらのアクティビティライトもやはり点灯していなかった。UPS が動作中であるのは間違いなかった。なぜなら、我が家のネットワークを管理している Eero ベースステーションも、iPhone アプリから Honeywell サーモスタットを管理しているデバイスも、どちらもオンラインで稼働中だったからだ。
そこで私たちは UPS を暗い隅から引っ張り出して調べてみた。その時だった、何が起こっていたかに私が気づいたのは！ この APC 製 UPS には“マスター”コンセント (下の写真では左上に見える) が１個と、あといくつかの“制御付き”コンセント (写真で下の方に並ぶ) が付いている。マスターコンセントに繋がれた機器がスリープまたはスタンバイ状態になれば、またはその機器の電源が切られれば、この UPS はエネルギー節約のために制御付きコンセントへの電源を自動的に切る。ただし、このモードはこの UPS 上でデフォルトでは有効化されておらず、Master Enable と書かれた物理的ボタンを押して初めて有効化される。でも、このマスターコンセントには我が家で最も重要なネットワーク機器である Eero Pro が繋がれている。いったいなぜ Eero Pro は制御付きコンセントに電源を供給させ続けてくれなかったのか？ それに、停電の最中に何が起こった結果として制御付きコンセントで電源が無効化されてしまったというのか？
停電になる度に、私はこの APC UPS が発するやかましい警告ビープ音を黙らせるためにいったん UPS を切るようにしている。この UPS は暗い隅に置かれているし、ここを照らす電灯はないので、私はいつも手探りで電源ボタンを探して押している。(写真ではこのボタンが点灯しているが、電源スイッチとステータスライトが別であるのはよくあることだ。) ２回あった停電のいずれかで、私は電源ボタンを探しつつうっかり Master Enable ボタンを押してしまったに違いない。Eero Pro が消費する電力はたった 5 ワットほどなので、おそらくそれは APC UPS が制御付きコンセントの電源を切る判断をする閾値よりも低かったのだろう。それはもっともな話だ。もしも私が Mac をマスターコンセントに繋いでいて、その消費電力が 5 ワットを下回ったなら、再びその Mac を使い始めるまでの間は周辺機器に電力を供給する必要はないだろう。
私がボタンを押してこの APC UPS がマスター/制御付きモードを脱するや否や、問題の Ethernet スイッチと温度監視システム用ハブの電源が入り、双方とも機能を始めた。そして、SMA インバータは直ちにポータルへの接続を再開させた。問題解決だ！
学んだ教訓は
いったいなぜ私はもっと早く自分でこれに気づけなかったのか？ 弁解させて貰えば、我が家の Wi-Fi ネットワークは機能していて、私の iMac は Ethernet と Wi-Fi の双方を使っているので、電源供給の切れた Ethernet スイッチのせいで Ethernet が仕事部屋で使えなくなっているという事実に気づけなかったのだ。今になって思い返せば、Tonya も私もちょっとしたネットワーク接続の問題に気づいていて、それはおそらく Wi-Fi を拡張する仕事部屋の Eero 機器がバックホールのために Ethernet でなくワイヤレスに依存しなければならなかったからなのだろう。
その上、４台あるネットワーク機器のうち２台は機能していて、それらの LED が点灯していた。私は実際インバータから来ている Ethernet ケーブルを抜き差しすることも試していたので、Ethernet スイッチに目をやっていたことは間違いないのに、その電源が落ちていたことに気づけなかった。温度監視システムについては一つも通知が出ないまま何か月も過ぎることがよくあるので、センサーからの通知が届かなくても驚きはしなかった。それに、iPhone から Honeywell サーモスタットをコントロールする必要が生じることも滅多になくて、オフラインになっていることに気づかなかった。(サーモスタットの電源は入っていたが、電源の入っていない Ethernet スイッチに接続されていた。)
言い換えれば、私のトラブルシューティングがいいかげんだったということだ。過去にインバータの接続の問題を一つのやり方で解決したことがあったので、今回も同じだろうと思い込んで、もっと上流まで接続の道を辿ることをしなかった。Halco の技術者に促されてそれを実行した途端に、たちまち問題の所在が明らかになった。
そしてその点こそが、親愛なる読者の皆さん、この話の教訓だ。何らかの技術的な問題を解決しようとして最初の試みが失敗に終わったならば、問題をいくつかの部分に切り分けて、個々の部分が機能しているかどうかを一つ一つ確認することだ。あらゆる問題はそれぞれ違うけれども、どこか一つの部分から始めて可能性を順々に潰して行けば、きっと原因を見つけることができるはずだ。
討論に参加
