Thoughtful, detailed coverage of everything Apple for 34 years
前週号 | 日本語版ホーム | 次週号

#1713: Apple Intelligence のセキュリティとプライバシー、iPhone 用 Slack にポストする際の問題、In Your Face の消えない通知、Apple の長持ち白書

Apple Intelligence を巡るセキュリティ、プライバシー、安全性の問題に興味ある人たちに、TidBITS セキュリティ編集者でありクラウドコンピューティングの専門家でもある Rich Mogull が、Apple Intelligence がいかにして AIにおける業界最高レベルのセキュリティ、プライバシー、および安全性を達成するかを解説する。一方 Adam Engst は In Your Face を検討する。この Mac用アプリは、あなたが無視できないやり方でイベントやタスクの通知を提供する。Adam はまた、iPhone 版のアプリからポストできなくなっている Slackユーザーのために解決法を紹介する。それからもう一つ、Apple の最新のホワイトペーパーを紹介する。長持ちするデバイスについて Apple がどう考えているかが垣間見えて興味深い白書だ。今週注目すべき Mac アプリのリリースは Fantastical 3.8.19 と Cardhop 2.2.18、Final Cut Pro 10.8, Compressor 4.8, Motion 5.8、Lightroom Classic 13.4、OmniFocus 4.3.1、それに Quicken 7.8 だ。

Adam Engst  訳: 亀岡孝仁  

Slack が iPhone で "Only Some People Can Post" となるエラーに対処

先週、私は iPhone 上の Slack で投稿をブロックする問題に遭遇した。代わりに、Slack は、下部にある通常なら私がメッセージを入力する所に "Only some people can post (限られた人だけが投稿出来る)" と表示した (左下)。それは単純な権限の問題ではなかった - 私は管理者であり、問題のチャンネルの所有者でもある。

初めてそれが起こった時、私は投稿するためにただ私の Mac に切り替えた。それは私のアカウントに関連したものではなく、クライアントアプリの問題であることを示していた。更に1日か2日、私は iPhone から Slack に何も投稿する必要はなかったが、次回の投稿で私はその制限にイライラして、Slack を強制終了させた (右下)。その簡単な行動が問題を解決したのでホッとした。私レベルのユーザーが享受すべき投稿権を取り戻す方法を他に何も考え付かなかったからだ

"Only some people can post." error in Slack and force-quitting the Slack app

何れにせよ、私はその問題を宇宙線のせいにし、生きていくこととした。しかしながら、数日後、Glenn Fleishman が同じ問題に遭遇したと言い、翌日、この問題は私の iPhone で再発した。明らかに、この問題は単なる1回限りの出来事ではなかった。この問題が皆さんの所で発生した場合、App Switcher で Slack を上方にスワイプして強制終了しよう。

iPhone や iPad のアプリを強制終了するのは、言うことを聞かないアプリやフリーズしたアプリをリセットする場合にのみ役立つことをお忘れなく - それは iOSにアプリを自動的に管理させるよりも多くのメモリと電池電力を消費する ("iOS アプリの強制終了や iOS デバイスの強制再起動を習慣にしてはいけない理由" 21 May 2020 参照)。

討論に参加

Adam Engst  訳: 亀岡孝仁  

In Your Face、イベントやタスクに対して無視出来ない通知を提供

"アラーム求む: カレンダーとリマインダーの持続的な通知がなぜ必要か" (11 May 2023) で、私は Calendar の今後のイベントや Reminders のタスクについてユーザーに通知する Apple のデフォルトのやり方は不十分であると主張した。通知を見逃したり無視したりしたが故に、時間通りに出席したり、タスクを完了したり出来なくなるのはよくあることである。

問題は名前そのものにある - Apple は私たちに 通知 を与えてきたが、我々が必要なのは アラーム である。バナー通知は消える前に短時間しか表示されないし、アラート通知は解除するまで残るが、解除を強制するものは何もない。対照的に、Clock アプリで設定したアラームは、停止するまで再生される - それ等はあなたの注意を喚起し、相互作用を必要とする。

この記事以降、私はカレンダーイベントや時限付きリマインダーを見逃さないようにする2つのアプリを見つけた。それ等は Apple が提供してきたものを改善はするが、どちらも問題を完全には解決していないので、私は Apple がバナーやアラートに加えて3番目の通知としてアラームを追加するよう世論に訴え続けようと思う。この記事では、Blue Banana Software の Mac アプリ In Your Face を見て行く;クロスプラットフォームアプリ Due は今後取り上げたいと思っている。

In Your Face は目の前に現れる

In Your Face は、究極のモーダルダイアログ (それが閉じられない限り作業の続行が出来ない) を表示することで、時限付きイベントやリマインダーを見逃さないようにする。それは画面全体を乗っ取るテーマ別の全画面アラートで、OKボタンをクリックしてそれを閉じるまで Mac に戻って仕事が出来るようにならない。アラートの下部にあるボタンを使って、事前に設定した時間、或いはそのイベントが始まる迄、アラートをスヌーズすることも出来る。私は本来スヌーズするのは好きではないが、この場合、In Your Face は会議の 15 分前に警告し、スヌーズを使用して 14 分後に別のアラートを表示して、次の予定を忘れないようにするのを確実にするが、その間時間に気を取られないようにしてくれる。

In Your Face alert

OK ボタンの上のアイコンは、イベントのメモにアクセスし、デフォルトのカレンダーアプリでイベントを開かせてくれる。イベントにビデオ通話リンクが含まれている場合、In Your Face は参加を容易にしてくれる。アラート画面で、ビデオカメラのアイコンをクリックするか、J を押すか、或いはポップアップメニューを使える。また、イベントが始まった後に、In Your Face のメニューバーリストでそのイベントのビデオカメラアイコンをクリックするか、或いはユーザー定義のキーボードショートカットを使って、通話に参加することも出来る。

In Your Face video links

In Your Face を設定する

In Your Face の豊富な設定は、どのカレンダーやリマインダーリストを見るかを指定させてくれる。余り重要でないイベントやリマインダーに邪魔されるとすぐにうっとうしく感じるので、これは便利である。私は、全てのリマインダーに対してオフにしている。と言うのも、それ等に割り当てた時間は、主として通知を表示するために与えたものだからである;私がその正確な時間にタスクを完了する必要があることは殆ど無い。私がそのようなタスクを持っている場合、In Your Face が見ることの出来る特別なリストを作成する。

カレンダー/リストレベルの制御では十分に詳細でない場合、In Your Face は、承諾されたイベント、アラート付きのイベント、およびビデオ会議へのリンクを含むイベントにアラートを制限する Event Filters を作成させてくれる。それでは十分ではない? タイトル、メモ、または場所のテキストを使ってイベントのアラートを表示させないようにする除外ルールを作成することも出来る。もっと欲しい? 除外ルールは、パターンマッチングすらもサポートする。多層階の建物で働いている場合、他の階のイベントのアラートのみが必要であれば、適切な部屋番号に一致するパターンを構築出来る。

In Your Face event filters

また、イベントがアラートされるまでの時間、複数の画面のどれにアラートを表示するか、アラートと一緒に再生する音、およびデフォルトのスヌーズ時間を設定することも出来る。In Your Face はスマートで、もし特定されていれば、移動時間も含められる。

In Your Face settings

追加の In Your Face 機能

In Your Face の核となる機能は1つだけだが、開発者の Martin Hoeller は、歓迎する人がいると思われる幾つかの追加機能を加えている:

私はこれらの追加機能のどれも使わない。カレンダーに関しては、今後のイベントのメニューバーリストも提供し、メニューバーに現在のイベントを表示できる Fantastical に依存している。私もまたリマインダーを多用しているので、In Your Face のカスタムリマインダーを使うよりも、iPhone、Apple Watch、またはHomePod で Siri を使って Reminders にタスクを追加する方が簡単である。

何れにしても、私は In Your Face の核となる機能を評価しており、インストールして以来、一度もイベントを見逃していない。それは本質的に一つの芸しかしない子馬かもしれないが、それはとても良い芸である! In Your Face は、Mac App Store から月額 $1.99 または年間 $19.99 で入手できるが、Setapp でも手に入る。定期購読にアレルギーのある人には、最大3台迄の Mac で働く $59.99 の生涯ライセンスもある。

討論に参加

Rich Mogull  訳: Mark Nagata   

Apple Intelligence が AI のセキュリティ、プライバシー、安全性に新たな基準を設ける

誰もが Apple による Apple Intelligence の発表を楽しみにしていたが、既に Apple ならではの強力な基準線に慣れ親しんでいるはずのセキュリティ・コミュニティーでさえ、その発表で語られたセキュリティ、プライバシー、および安全性に関する詳細を (歓迎の) 驚きをもって受け止めた。Apple は iPhone からクラウドへと繋がる革新の技術をもって一連の難問を巧みに操ってみせたが、それは私たちが他のどこで見たものをも超越していた。

私はクラウドセキュリティに取り組んで十年以上働いてきたし、サイバーセキュリティの仕事をしてきた期間全部を合わせればそれよりもっと長いが、そんな私でも本当に感銘を受けた。Apple Intelligence とその背後にある Private Cloud Compute システムのデザインは、過去十年間に Apple が積み上げたセキュリティとプライバシーへの幅広い投資を活用することで AI 業界に新たな基準を打ち立てるものとなる。

これがなぜそれほどまでに重要なものなのか、いかにして Apple が (すべて語られた通りに働くと仮定してのことだが) それをやってのけることができたのかを理解するために、ここではまずその“これ”というのがどのような種類の AI であるのか、そこで生まれるリスクがどんなものか、Apple がどうやってそのリスクに対処しようとしているのかを概観しておく必要がある。

Apple Intelligence とはどのような種類の AI か、Siri とどう違うのか?

人工知能にはさまざまな種類のものがあるが、そのすべてが学習に基づいて問題を解決するために数学的なモデルを使っている。例えばパターン認識もそのように働く。(どうか AI 研究者の皆さん、単純化し過ぎと咎めないで頂きたい。) 皆さんの iPhone や Mac も、既にさまざまの機能で AI に依存している。例えば Siri の音声認識、Photos の顔認識、iPhone で撮影した写真の画像処理などだ。従来 Apple はこれらの機能が“機械学習”により駆動されていると説明してきたが、現在 Apple はこれらを "AI" と呼んでいる。

今では皆さんもきっと ChatGPT について聞いたことがあるだろう。これは、生成 AI チャットボットだ。生成 AI のアルゴリズムはテキスト、画像その他によるリクエストから新しいコンテンツを作成する。主にあらかじめ準備された応答のみを返す Siri とは違って、生成 AI チャットボットはもっとずっと広範なリクエストを処理することができる。お話をしてくれと Siri に頼めば、Siri はデータベースの中から一つ話を選んでくれるだろう。けれども ChatGPT にお話をしてくれと頼めば、その場で新しい話を作ってくれる。

Open AI の ChatGPT や、Anthropic の Claude や、Google の Gemini は、すべて Generative Pre-trained Transformer (お分かりだろうがこれが GPT、あらかじめ訓練された生成的変成器) の実例だ。実際のところ、これらの GPT は Large Language Model (LLM、大規模言語モデル) の一部分とも言える。LLM はあらかじめ膨大な量のテキスト (インターネットの大きな部分) でトレーニングされ、そのデータを使うことによりプロンプトに応じてどの単語が次に来るべきかを予想して新しい答を作成する。LLM はもともとテキストを扱うものだが、他のタイプの生成 AI は画像やオーディオ、さらにはビデオまで作成できる。(それらすべてがディープフェイク作成のために悪用されるかもしれない。) 生成 AI は極めて強い能力を持つが、そのためには膨大なコンピューティングのパワーが必要であるとともに、とんでもない失敗に陥ることもしばしばある。また、新たなセキュリティの問題やプライバシーの懸念を生むのみならず、安全性の諸問題もそこに内在している。

Apple の初めての生成 AI への進出は Apple Intelligence の傘下で登場する。Apple はその従来の AI 機能では必要とされていなかった形でセキュリティ、プライバシー、安全性を優先させるために開発作業を進めているところだ。

AI のセキュリティ、プライバシー、安全性はお互いにどう違うか?

これら3つの用語は互いに関係しており、ある程度は相互に依存しているけれども、それぞれが独自の領域を持つ:

セキュリティこそがプライバシーと安全性を構築するための基盤となる。もしもそのシステムがセキュアでなければ、プライバシーや安全性を保証することは不可能だ。

どんなオンラインサービスでも同じことだが、プライバシーには選択が伴う。プロバイダはどのプライバシーオプションを提供するかを選び、顧客はそれをもとにそのサービスを利用するか否か、どのように利用するかを選ぶ。多くのコンシューマ向け AI プロバイダはデフォルトで、自らのモデルを改良するためにユーザーのプロンプト (つまり AI に尋ねた質問) を利用する。だから、あなたが入力したものは何でも、おそらくは断片的にだが、誰か他の人への回答に使われるかもしれない。プラス面を言えば、大多数のプロバイダではプロンプトが利用されるのをオプトアウトできるようにしているし、データや履歴を削除するオプションも提供している。

多くの AI プロバイダは安全性を保証するための努力をしているが、ソーシャルネットワークと同じように、プロバイダ各社はそれぞれ異なる定義を用い、何が許容範囲にあるかについてそれぞれ異なる方針を持つ。それが容認できない人がいるのも当然だ。

生成 AI はどのように機能するか?

AI は信じられないほど複雑なものだが、この記事の目的のために単純化して、3つの中核的な要素と、2つの追加オプションのみに焦点を当てることにしよう。これらすべてが組み合わさることで モデル が生み出される:

想像して頂けると思うが、より効率的に接続され、より多くのニューロンを持ち、より大きな頭脳が、より大きなデータセットでトレーニングされた場合に一般的により良い結果が得られる。どこかの会社が汎用目的の膨大なモデルを構築した場合、それは 基盤モデル と呼ばれる。基盤モデルは、多くの異なる状況の中へ統合させて特定の目的、例えばプログラムコードを書く目的のために特化して強化することができる。

基盤モデルを強化するために使われるオプションのコンポーネントとして、主なものが2つある:

これらすべてがどのように組み合わさるかを説明するために、例としてヘルプシステムに AI を統合させる状況を考えよう。基盤モデル AI の開発者は新しい LLM を作ってそれを巨大なコンピュータ・クラスターにロードし、それから膨大なデータセットでそれをトレーニングする。その結果は ChatGPT と似ていて、トレーニングされた言語で“理解”し文章を書くことができる。プロンプトに対する反応としてどの単語をどの順番で並べるかを判断するのだが、その際にトレーニングで学んだことのすべてと、異なる単語がどのように結び付き関連付けられるかの統計的可能性を基準とする。

その後で顧客が自分独自の微調整用データ、例えばそのソフトウェアプラットフォームの情報資料などを追加して基盤モデルをカスタマイズし、その結果の LLM をヘルプシステムに組み込む。基盤モデルが言語を理解し、微調整がそのプラットフォームに関する具体的な詳細情報を提供する。もしもそのプラットフォームで多くのことが変化する状況であるならば、開発者が RAG を利用することによって、微調整後のモデルが最新の情報資料を取り寄せ、再トレーニングや再調整の必要なしに増補した結果が得られるようになる。

すべてがうまく行けば、まるで魔法のように感じられるはずだ。けれどもここでの問題は、LLM が (あるいは画像生成ツールなど他の生成 AI が) 失敗に陥りがちなことだ。統計的に可能性の高い関連性は理解しているのだが、必ずしも... 現実を理解していない。私は ChatGPT に家族で観る PG-13 (13 歳未満) 指定のコメディ映画のリストを尋ねたことがあるが、返された結果の半数が R 指定 (17 歳未満は保護者同伴指定) の映画だった。(私たちが実際に選んだ映画も R 指定だったので、結局あまり問題ではなかったが。) この種の誤りはよく "ハルシネーション (幻覚)" と呼ばれていて、完全に除去することは不可能だというのが通説だ。"confabulation (作り話)" の方が相応しい用語だと主張する人もいる。"ハルシネーション" に狂気じみた空想の感じがあるのに対して、"confabulation" は欺く意図なしに話を作り上げる意味だからだ。

生成 AI はどのようにセキュリティ、プライバシー、安全性に影響するか?

生成 AI の複雑さそのものが、幅広い種類の新たなセキュリティの問題を生み出す。それらすべてをここで紹介するよりも、Apple が iPhone ユーザーに提供する AI サービスにそれらの問題がどのように影響するかに焦点を絞りたい。問題の核心は、Apple Intelligence が何らかの役に立つためには十分なハードウェア能力を得るためにも少なくとも部分的にはクラウド上で動作する必要があることだ。ここで Apple が直面する難問をいくつか挙げてみよう:

これらの難問は非常に複雑なものだ。メジャーな基盤モデルの大多数はある程度セキュアだと言えるだろうが、顧客のプロンプトにはアクセスできる。このことが Apple にとってより厄介なのは、iPhone も iPad も Mac も非常にパーソナルなものであって、ローカルにも iCloud 上でもプライベートな情報にアクセスできるようになっているからだ。ChatGPT に代わる新たな AI チャットボットを作ることを Apple に求めている人など誰もいない。人々が望むのは、自分たちのことを理解していて iPhone 上や iCloud 上にある自分たちの情報を利用しつつパーソナルな結果を返してくれる Apple 製 AI だ。

Apple が取り組むべき難問は、生成 AI のパワーをセキュアに活用しつつ、パーソナルなデータの最もパーソナルな部分をも利用できるようにして、その際に親しい人からも、犯罪者からも、政府からもアクセスされないプライベートなものに保てるようにすることだ。

Apple Intelligence はどのようにセキュリティとプライバシーを管理するか?

Apple のやり方は、デバイス上にあるハードウェアとソフトウェアのスタックに対する完全なコントロールを活用する。Apple Intelligence はまず AI プロンプトの処理をローカルなシステム (その iPhone、iPad、Mac) 上で A17 Pro または M シリーズのチップに内蔵された Neural Engine コアを使って実行しようと試みる。タスクがそれを超える処理能力を必要とする場合、Apple Intelligence はそのリクエストを Private Cloud Compute と呼ばれるシステムに送り、それがクラウド上にある Apple の基盤 AI モデルを走らせる。

公開された基盤モデルに依存する代わりに、Apple は独自の基盤モデルを構築して、それを独自のクラウドサービス上で走らせる。このクラウドサービスは Apple silicon チップで駆動され、私たち個人が持つ Apple デバイスを保護しているものと同じセキュリティ機能の多くを使う。そして Apple はそれらの機能をさらなる保護で強化して、誰も顧客のデータにアクセスできないようにする。悪意ある Apple 従業員も、物理的およびデジタルな Apple のサプライチェーンにある設備も、政府のスパイも、決してアクセスできない。

それはセキュリティとプライバシーの驚くべきエンジニアリング手法だ。私は普段から大袈裟な言い回しをする習慣はない。セキュリティは複雑なものであり、敵対者に攻撃され得る弱点が 必ず あるものだ。けれどもこれは、私の経歴の中でも大袈裟な言い回しが正当化されるごく稀な状況の一つだ。

Apple Intelligence がどのように機能するかについて Apple はあらゆる詳細を明かしている訳ではないが、Apple の基盤モデルの概要と、Private Cloud Compute におけるセキュリティの概要と、Apple Intelligence の諸機能に関する情報を既に公開している。これらの情報に加えて、以前から公開されている Apple の Platform Security Guide が複数のデバイスとサービスにわたって Apple のセキュリティがどのように働いているかを詳しく述べていることを考え合わせれば、Apple がどのように Apple Intelligence をセキュアにしようと計画しているかが理解できる。

Apple はどの基盤モデルを使うか、それは顧客データを含むのか?

Apple は Apple AXLearn フレームワークを使って独自の基盤モデルを作り出した。このフレームワークは 2023 年にオープンソースのプロジェクトとして公開されている。思い出して頂きたいが、モデルとはさまざまのソフトウェアアルゴリズムをデータの集成を用いてトレーニングした結果のことだ。

Apple はトレーニングのために顧客のデータは利用しないが、ライセンスを受けたデータに加えて、ウェブをクロールする AppleBot と呼ばれるツールを使ってインターネットから収集したデータを利用する。AppleBot は以前から存在していたものだが、これまであまり注目を得てこなかった。インターネットから収集したデータには個人のデータも含まれるので、Apple はその種の情報をフィルター分けして取り除こうと試みる。

基盤モデルを作成する他の会社と同様に、Apple はモデルの能力をトレーニングするために膨大な量のテキストを必要とする。だからこそウェブクローラーが必要となるのだ。モデルや検索索引に統合するために許可なく知的財産をかき集めるので、ウェブ収集には賛否両論がある。私は一度 ChatGPT にクラウドセキュリティに関する質問を尋ねてみた。この分野については私もたくさんの文章を書いてきたことがあるのだが、返ってきた結果は私が過去に書いた文章に非常によく似ていた。私の文章がそのままコピーされたと確信があるかと問われればそうとも言えないが、ChatGPT のクローラーが私のコンテンツを取り込んだことは間違いないと思う。

Apple は現在、個々のウェブサイトを AppleBot の収集から除外することも可能だと言っているが、それはいずれそうなるというだけの話だ。既存の基盤モデルからコンテンツを削除する方法があるのか否かという点に関して Apple は何も述べていない。除外ルールが公表されるより前からモデルのトレーニングは始まっているからだ。Apple にとってそれは良い印象を与えるものではないが、除外するためにはクリーンになったデータセットでモデルをトレーニングし直さなければならず、それもまた可能なことには違いない。

Apple は汚い言葉や価値の低いコンテンツをフィルターすることもしている。確実なところは分からないが、可能な限り有害なコンテンツのフィルターもしているのではないかと思われる。トレーニングの際に、人間によるフィードバックをモデルが取り入れることもしており、Apple はセキュリティの問題 (プロンプト・インジェクションなど) や安全性の問題 (有害なコンテンツなど) に対処するための敵対者試験も実行している。

その基盤モデルは私のデータを使って微調整されたのか?

Apple はあらかじめトレーニングされた基本モデルを微調整するのでなく、その代わりに アダプター を微調整する。アダプターとは、例えば電子メールメッセージの要約といった個々のタスクのための、微調整を施されたレイヤーだ。生成 AI 一般についてさきほど説明したことを思い返せば、Apple はモデル全体に微調整を施す代わりに、もっと小規模のアダプターを微調整する。それは、さきほど挙げた例の中で会社が製品の情報資料のヘルプシステムを微調整したことと同様だ。

その上で Apple は、ユーザーがどんなタスクを試みているかに応じてその場で適切なアダプターに交換する。これは、ローカルなデバイス上で限られた資源を用いて異なる使用事例を最適化するためのエレガントな方法と言える。

Apple が公開した情報資料に基づけば、どうやらその微調整はパーソナルなデータを使わないようだ。とりわけ、微調整を施されたアダプターはリリースされる前にテストと最適化の処理を受けるのだから。もしも個人データでトレーニングされているのだとすれば、テストや最適化が不可能となるだろう。また、Apple はデバイス上とクラウド上とで異なる基盤モデルを使っていて、個々のリクエストごとに必要とされるパーソナルなセマンティックデータのみを送信するので、そのことからも Apple が個人データでの微調整をしていないと推察できる。

Apple Intelligence はデバイス上でどのようにしてセキュアに動作するのか?

ある意味、私たちのデバイス上でセキュリティを維持することは Apple にとって問題の中の最も容易な部分だ。それは、Apple が十年以上かけてセキュアなデバイスを構築する努力をしてきたからだ。デバイス上で Apple は2つの広範な問題を解決する必要がある:

さきほども説明したように、Apple Intelligence はまずそのリクエストをデバイス上で処理できるか否かを調べる。それから、適切なアダプターをロードする。もしそのタスクがパーソナルなデータにアクセスする必要があれば、Spotlight に似たセマンティックな索引を使ってそのデバイス上で処理される。それがどのように実行されるかを Apple は詳しく述べていないが、私の推測では RAG を使って必要なデータを索引から取り寄せるのだろうと思う。この作業を処理するのは Apple silicon の異なるコンポーネント、中でも最も重要なのが Neural Engine だ。これが理由となって、Apple Intelligence はあらゆるデバイス上で動作する訳ではなく、十分にパワフルな Neural Engine と十分なメモリを必要とする。

この時点で、広範囲にわたるハードウェア・セキュリティが働き始めるが、それはこの記事で扱える範囲を遥かに超えている。Apple は暗号化、セキュアなメモリ、A シリーズと M シリーズのチップ上のセキュアなコミュニケーションという複数のレイヤーを活用することで、承認を受けたアプリケーションのみが情報をやり取りできるようにし、データがセキュアに保たれるようにし、個々の処理が攻撃を受けてシステム全体が壊れる事態が起こらないようにする。

アプリのデータはデフォルトでは索引付けされないので、Apple があなたの銀行取引情報を見ることはない。iOS 上のあらゆるアプリはそれぞれ異なる暗号化鍵を用いてコンパートメント化されており、アプリの開発者が意図的にそのデータを索引の中へ“出版”する必要がある。このデータには インテント が含まれるので、アプリは情報のみならずアクションを出版することもでき、Apple Intelligence が Siri にそれを利用させるようにもできる。また、開発者が自分のアプリのためにセマンティックな情報 (例えば旅行プランがどうなっているかなど) を出版することもできる。

別の言葉で言えば、アプリの開発者がそれを許してそのための構築をした場合を除いて、アプリのデータが Apple Intelligence に含まれることはない。加えて、私の推測ではユーザーの手でデータの組み込みを無効化することもできるのではないかと思う。なぜなら、無効化の機能は Siri と Spotlight に対して、iPhone と iPad 上では Settings > Siri & Search で、Mac 上では System Settings > Siri & Spotlight > Siri Suggestions & Privacy で、既に実装されているからだ。

たとえ Siri リクエストがあなたの個人データをアプリのデータと組み合わせていたとしても、デバイス上の既存のセキュリティがアプリから見える情報に制限を付けている。Siri が保護されたデータを Siri リクエストの一部としてアプリに提供できるのは、そのアプリがその保護されたデータ (例えばメッセージングアプリが連絡先にアクセスする場合など) へのアクセスをあらかじめ許されている場合に限られる。Apple Intelligence についても同じことが引き続き成り立つだろうと私は期待している。そうすれば、セキュリティ研究者の言う confused deputy problem (混乱した使節の問題) を防ぐことができるだろう。このような設計により、悪意あるアプリがオペレーティングシステムを欺いてプライベートなデータを他のアプリから取り寄せることを防げるはずだ。

Apple Intelligence はリクエストをクラウドへ送るか否かをどうやって判断するか?

Apple はその部分の詳細をまだ明かしていないが、いくつかの推測は可能だ。

さきほども述べた通り、多くの形式の生成 AI に対するリクエストのことを私たちは プロンプト と呼ぶ。例えば「この書類を校正せよ」というのがプロンプトだ。まず最初に、AI はそのプロンプトを トークン に変換する。トークンは AI が処理のために使うテキストの塊だ。トークンの個数は LLM のパワーの尺度の一つだと言える。モデルの ボキャブラリー とは、そのモデルが認識するすべてのトークンの集まりのことだ。

今述べた校正の例で言えば、トークンの個数はそのリクエストのサイズと、リクエストの中で提供されるデータ (この例では校正すべき書類) のサイズによって決まる。モデルの概要を述べた記事の中で、Apple はボキャブラリーの規模がデバイス上で 49,000 トークン、クラウド上で 100,000 トークンと記している。iPhone 15 Pro は毎秒 30 トークン程度の速さで応答を生成できる。

私の見るところ、Apple は少なくとも2つの基準によってリクエストをクラウドへ送るか否かを判断するようだ:

リクエストがクラウドへ送られた後には何が起こるのか?

ここがまさに、Apple がそのセキュリティモデルでかつての自らを超える成果を出したところだ。ユーザーのプライバシーを保ちつつプロンプトをクラウドへセキュアに送信するメカニズムを Apple は必要としていた。その後でシステムは (機密を要する個人データを含む) プロンプトを処理しつつ、Apple 自身も他の誰もそのデータにアクセスできないようにしなければならない。そして最後に、システムは世界に向けてその前の2つのステップが検証可能な形で正しいことを保証しなければならない。ただ単に私たちに信用するよう訴えかける代わりに、Apple は複数通りのメカニズムを構築して、クラウドを信用できるか否かをデバイスが判断でき、Apple を信用できるか否かを世界が判断できるようにした。

いったいどうやって Apple はそれらの難問すべてを処理したのか? それは、新しい Private Cloud Compute (PCC) を使うことによってだ。これはカスタム構築されたハードウェアとソフトウェアのスタックであって、認証可能な信用を伴って LLM をセキュアかつプライベートにホストするものだ。

Private Cloud Compute におけるセキュリティの概要を述べた記事はこう書いている:

Private Cloud Compute はユーザーのデータを処理する方法についていくつかの保証を与えられるように設計されています:

  • ユーザーのデバイスが PCC に送るデータは、そのユーザーの推論リクエストを満たす目的のためだけに使われます。PCC はそのデータをユーザーがリクエストした作業を実行する目的のためだけに利用します。
  • ユーザーのデータはそれに対する応答が返される時点までのみ、それを処理する PCC ノードに留まります。リクエストが満たされた後は PCC がそのユーザーデータを削除し、応答が返された後にはいかなるユーザーデータもいかなる形でもそこに残ることはありません。
  • ユーザーのデータが Apple の手に渡ることは決してありません。生産サービスまたはハードウェアに管理者権限を持つスタッフでさえ、それを見ることはできません。

上位レベルの用語で言えば、Private Cloud Compute は私たちが コンフィデンシャル・コンピューティング と呼ぶ機能の類に属する。コンフィデンシャル・コンピューティングではタスクに特定のハードウェアが割り当てられ、そのハードウェアを強化することによって物理的アクセスが可能な人からの攻撃や覗き見さえも防ぐことができる。Apple が説明する脅威モデルには高度に洗練されたスキルを持ちそのハードウェアに物理的にアクセスできる人物が登場する。これは防御すべき最も困難なシナリオと言えるだろう。Amazon Web Service の Nitro アーキテクチャも同様の実例だ。

さて、以下では Private Cloud Compute をいくつか小さな要素ごとに分けて順々に説明しよう。クラウドとコンフィデンシャル・コンピューティングで長年の経験を持つセキュリティのプロフェッショナルである私のような者にさえ、これはなかなか複雑だ。

どのデータがクラウドへ送られるか?

送られるのはそのプロンプトと、望ましい AI モデル、およびそれを支える推論データだ。そこにはユーザーがタイプしたり話したりしたプロンプトに含まれない連絡先その他のアプリデータも含まれるだろうと私は推測している。

デバイスはリクエストの送り先をどのように知るか、どのようにそのセキュリティとプライバシーを保証するか?

Private Cloud Compute (PCC) のコアユニットは ノード と呼ばれる。ノードがサーバの集まりなのか、それとも一つのサーバの中のプロセッサの集まりなのかを Apple は明かしていないが、セキュリティの観点からはどちらでも大差はない。PCC ノードは、他の Apple デバイスが使うものと同じ Secure Enclave を組み込んだ、詳細が明かされていない Apple silicon プロセッサを使う。この Secure Enclave が暗号化を担うとともに、CPU 外部にある暗号化鍵を管理する。高度にセキュアな金庫だと思えばよい。そのセキュリティ運用のため専用に少量の処理能力が用意されている。

個々のノードはそれぞれ独自のデジタル証明書を持っており、その中にそのノードの公開鍵と、いくらかの標準的なメタデータ、例えばその証明書の有効期限などが含まれている。その公開鍵の対となる秘密鍵は、そのノードのサーバ上の Secure Enclave に保存される。公開鍵を使って暗号化されたデータはすべて、それと対になる秘密鍵を使ってのみ復号化できる。これは、事実上あらゆるところで用いられている公開鍵暗号方式だ。

ユーザーのデバイス上にあるクライアントソフトウェアは、まずいくらかの単純なメタデータを使って PCC のロードバランサーに連絡する。すると、必要なモデルの中にある適切なノードに向けてそのリクエストを転送できるようになる。ロードバランサーはそのユーザーのリクエストを処理する準備ができているノードのリストを返す。そしてユーザーのデバイスが選ばれたノードの公開鍵を使ってリクエストを暗号化するので、そのノードのみがそのデータを読める唯一のハードウェアだという状態になる。

忘れないで頂きたいが、Secure Enclave のお陰で、ノードから秘密鍵を抽出できる方法はない。(対照的に、ソフトウェアのみの暗号化システムではその点が問題となる。) その結果として、それらのサーバの外からリクエストを読み取れる手段はないはずだ。ロードバランサー自体がリクエストを読む方法もない。これは適切なノードに向けて転送しているだけだからだ。たとえ攻撃者がロードバランサーに侵入してトラフィックを別のハードウェアへ誘導したとしても、そのハードウェアがリクエストを読むことはできない。復号化のための鍵がないからだ。

誰かが私のリクエストを追跡してそれを特定のノードへ誘導することは可能か?

それはできない。そして、これはとてもクールな機能だ。簡単に言えば、Apple があなたの IP アドレスやデバイスのデータを見ることができないのは、サードパーティの中継が使われていて、その種の情報はそこで削除されるからだ。しかしながらそのサードパーティの中継の側でもまた、Apple になりすましたり、データを復号したりはできない。

ノードのリストを得るため最初にロードバランサーに送られるリクエストのメタデータには、識別情報が一切含まれていない。そのメタデータは基本的に、「私の書類を校正するためのモデルが必要です」と言っているのみだ。このリクエストは直接 Apple に行く訳ではなくて、サードパーティの中継を通り、そこで IP アドレスやその他の識別情報が削除される。

こうして、Apple がリクエストを追跡してデバイスを特定することはできないので、攻撃者がそれと同等のことをするためには Apple と中継サービスの双方を攻撃しなければならないことになる。もしも攻撃者が実際にノードに侵入して、特定の標的をそこへ誘導したいと思ったとしても、Apple がロードバランサーの統計的分析を実行していてリクエストの送付先に異常を探知できるようになっているので、そのことが誘導に対するさらなる防御手段となる。

最後にもう一つ、Apple は情報資料の中でこの点に一切触れていないが、ノードの証明書は Apple のオペレーティングシステムとハードウェアの中に埋め込まれた特殊な署名鍵を使って署名されていると推測できる。Apple はそれを何よりも貴重なものとして保護している。この署名認証によって、攻撃者が公式の Apple ノードになりすますことが防がれる。あなたのデバイスはロードバランサーが指示したノードのためにリクエストを暗号化するので、他のどの PCC ノードもそのリクエストを読むことはできない。

クラウド内で走る Apple Intelligence の中で私のデータはどのように保護されるか?

処理のこの段階に来れば、あなたのデバイスは既に「校正リクエストのために PCC が必要です」と送信し終えていて、Apple の中継サービスが既に「これがそれを提供できるノードのリストです」と返信し終えている。その次に、デバイスはまず証明書と鍵を確認してから、リクエストを暗号化してそれをノードへ送信する。

するとロードバランサーがあなたのリクエストをノードに送る。思い出して頂きたいが、ノードは PCC 専用に構築された特殊な Apple サーバの上で動作する。これらのサーバはあなたが持っている Apple デバイスと同じく実績あるセキュリティのメカニズムを使っているので、それが高度な攻撃に対する防御をさらに強化することになる。実際にはどのように働くのだろうか?

セキュアなサプライチェーンの中に構築されたあらゆる PCC ハードウェアも、個々のサーバも、それぞれ実際の使用に供される前にしっかりと検査される。(これらのテクノロジーは、サーバが Apple に届くより前にバックドアが埋め込まれることを避けるために不可欠だ。) そのプロセス全体には高解像度の画像化、検査、サプライチェーン追跡などが含まれており、すべてがサードパーティによって監視される。いったんサーバがチェックに合格すれば、封印され、タンパースイッチが有効になって物理的な変更の試みをすべて探知する。

サーバは起動する際に Apple の Secure Boot プロセスを使用する。これについては Platform Security Guide に説明がある。この手法は Secure Enclave を活用するもので、ロードされるオペレーティングシステムが正しいものであること、コードが注入されていないこと、承認を受けたアプリケーションのみが走れることを複数回の手順を通じて確認する。macOS と同様に、PCC サーバは Signed System Volume (署名済みシステムボリューム) を使う。つまり、オペレーティングシステム自体に暗号法的な署名が入っていて改ざんを受けていないことが確認でき、読み出し専用のボリュームのみから走る。

PCC サーバ上で走るあらゆるソフトウェアは Apple によって開発され Apple の署名を得ているので、悪意のある開発者がオープンソースのツールに変更を加えて問題を起こす可能性が減る。ソフトウェアの大部分は Swift で書かれており、これはメモリ安全性を持つ言語なのでよくある特定のタイプの攻撃によるクラッキングへの耐性がある。さらに、すべてがサンドボックス化その他の標準的な Apple ソフトウェアのセキュリティ管理を使っており、その点は iPhone と同じだ。

起動時に、データボリューム (リクエストを処理するために使われるストレージ) のためのランダムな暗号化鍵が生成される。こうして、サーバ上に保存されている間あなたのデータは暗号化され、Secure Enclave を使ってすべてが保護される。

ここからさらにもっと良くなる。ノードがリクエストの処理を終えた後で、Apple は暗号化鍵を削除してノードを再起動する。だから、過去に保存されていたデータをノードが読むことは一切ない。もはや暗号化鍵がないからだ! 既にシステム全体が、次のリクエストに備えて自らをリセットし終えているのだ。念のために、Apple は何かがまだそこに残っている場合に備えてサーバのメモリを時々リサイクルする。

全体をまとめて言えば、あなたがリクエストを Apple に送ると、それは高度にセキュアな Private Cloud Compute ノードへ行く。そのノードがリクエストを処理するが、その間あなたのデータはずっと暗号化されたままだ。そしてリクエストの処理が終われば、直ちに暗号法的な消去が実行されて、再起動し、次のリクエストへの準備が整う。

私のデータは管理者や、ログファイルや、パフォーマンス監視ツールなどに暴露されるのか?

そんなことはない。Apple はその種の監視 (特権ランタイムアクセス と呼ばれる) を許すソフトウェアをスタックの中に一切含めていない。PCC ノードはコマンドシェル、デバッグモード、開発者ツールなどを持たない。パフォーマンス監視ツールやログ保存ツールはプライベートなデータを削除するために作られたものに限定される。

Apple はどうやって私たちがノードを... その返答を信用できると証明できるのか?

Apple によれば、Private Cloud Compute の正式版ソフトウェアビルドをすべて公開して研究者が評価できるようにするという。デバイスからのリクエストを送ることができるのは、それらの公開ビルドのどれかを走らせていると証明できるノードに限られる。これもまた、Apple Intelligence エコシステムのユニークな部分の一つだ。

Apple はそれを達成するために 透明性ログ を公開する。これは暗号法を通じることで、いったん何かがログに書き込まれればもう変更できなくなる。ブロックチェーンテクノロジーの有効な応用だと言える。このログにはコードを測定した結果 (具体的な内容は現時点では公表されていない) が含まれ、それを使うことでオペレーティングシステムとそのアプリケーションのバイナリがログされたバージョンと同一であることが検証される。

加えて、Apple は PCC ノード上で走るソフトウェアスタックのバイナリイメージを公開する。それは自信のあらわれであるとともに、システムが真の意味でセキュアであることを保証する素晴らしい手段となる。ただ単に見えにくい (obscure) から“セキュア (secure)”と言っているのではない。

すぐ上でも書いたように、デバイスがリクエストを送ることができるのは期待される通りのソフトウェアイメージを走らせているノードに限られる。Apple の説明はここのところが少し曖昧だが、私の推測ではノードが暗号法的に署名された測定値も出版するのだろうと思う。その測定値が透明性ログに記載された現行バージョンのソフトウェアのものと一致する必要があるのだ。

最後にもう一つ、Apple はセキュリティ研究者たちのために PCC の Virtual Research Environment (仮想研究環境) を公開して、研究者たちがローカルかつ仮想的なバージョンの PCC ノードをテストすることで Apple の主張を検証できるようにするという。また、ソースコードも一部公開する予定で、そこには Apple が過去に一度も公開したことのない機密のコンポーネントのためのプレインテキストのコードも含まれるという。

でも、Apple はリクエストを ChatGPT に送るのでは?

Apple Intelligence はあなたのデバイスとデータを巡る AI タスクに焦点を置いている。それよりもっと一般的な内容のリクエスト、つまり Apple が世界認識 (world knowledge) と呼ぶものを要するリクエストに対しては、Apple Intelligence がプロンプトを表示して、当初は ChatGPT へ、将来になれば他のサービスへも、リクエストを送信してよいかとユーザーに尋ねる。

個々のプロンプトがユーザーによる承認を必要とする (これが迷惑に感じられるかもしれない) が、Apple は (ChatGPT を運営する) OpenAI が匿名のリクエストに対する IP アドレスの追跡をすることはないと述べた。ChatGPT なり将来 Apple が対応することになる別のサードパーティの AI サービスなりで有料アカウントを持っている人には、そのサービスがそれ独自のプライバシー方針に従ってプライバシーに対処することになる。

Apple がデータを政府に開示することを義務付けられている中国などの国ではどうなるのか? European Union はどうか?

Apple は中国のような国で Apple Intelligence をリリースする予定があるか否かについて何も述べていない。既に公表されている Private Cloud Compute モデルは中国の法律を満たしていない。

既に Apple は Digital Markets Act (DMA, デジタル市場法) があるため EU 域内では当面 Apple Intelligence をリリースしないと発表している。いずれは Apple Intelligence が世界認識 (world knowledge) のためサードパーティのサービスにリクエストを送ることが可能になるだろうが、その種のリクエストにデバイス上や PCC で処理され得るプライベートなデータを含めることはできない。Apple がどのようにしてユーザーのプライバシーを保ちつつ外部サービスにデバイス上のデータと同等の深いアクセスを許すようにするかを見極めるのは難しいが、その際にも EU は DMA 準拠を要求してくることだろう。

Apple がプライベートな AI プラットフォームを構築することにこれほどの努力を注いだのはなぜか?

人工知能を最新のテクノロジー流行に過ぎないとして退けたがる人たちは多いけれども、時間の経過とともに人工知能が私たちの生活と社会に与える影響は非常に大きくなる可能性が高い。

AI モデルは猛烈な勢いで進化を続けている。私自身は生成 AI を使うことでコードを書くプロジェクトに費やす時間を何週間分も節約することができたし、自分の考えを整理したり軽い内容の調査をまとめたりする執筆アシスタントとしても役立つと実感できている。インターネット上で読むあらゆることと同じく、生成 AI を使った結果はきちんと検証するようにしている。

今日ある各種モデルは、書類の内容を要約したり、アプリケーションコードを書いたりデバッグしたりする際の助けになったり、画像を作成したりといった目的である程度うまく機能している。それでも、日々の生活を乗り切るための役に立つパーソナル・エージェントとして使える段階には達していない。そうなるためには、AI が私のパーソナルなデータのすべて、つまり電子メール、連絡先、カレンダー、メッセージ、電話その他にアクセスできることが必要だ。ChatGPT に「私の来月のフライトの旅程の詳細を妻に送れ」と命じることはできないし、たとえ可能になったとしても私は必要な情報を与えるつもりはない。

Apple Intelligence が初めて出荷される時点では、その機能が実現できるものは主として愚かさの減った Siri と、メッセージリストの中の電子メール要約など細かな気配り、どちらかと言えば退屈な要約と、Image Playground や Image Wand といった隠し芸程度だろう。けれどもその後数年経てば、もしもすべてがうまく行ったならば、Siri が成長してSF小説の中のパーソナルなデジタルエージェント (Apple の Knowledge Navigator を思い出そう) に似たものになるかもしれない。Apple silicon の持つ驚くべきパフォーマンスがあってさえ、AI 駆動の機能の一部はいつもクラウドを必要とする。だからこそ Apple は Private Cloud Compute を設計し、構築し、磨き上げることに努力を注いだのだ。その AI プラットフォームを私たちが信頼して、自分の最も機密のデータさえ扱えるようにすることを Apple は望んでおり、その信頼を勝ち得なければならないことを Apple は認識している。理論的には、それは良いことだ。これから Apple Intelligence の諸機能が利用できるようになるにつれて、現実と比べればどうなのかが私たちにも見えてくるだろう。

討論に参加

TidBITS 監視リスト: Mac アプリのアップデート

Fantastical 3.8.19 and Cardhop 2.2.18 Agen Schmitz  訳: Mark Nagata   

Fantastical 3.8.19 と Cardhop 2.2.18

Flexibits がカレンダーアプリ Fantastical 3.8.19 と連絡先管理アプリ Cardhop 2.2.18 をリリースした。Fantastical は Openings Editor のアクセシビリティ対応を改良し、Todoist アカウントのフル再同期が完了済みのタスクも含むようにし、アカウントの暗号化鍵をより手軽に見たりコピーしたりできるようにし、Exchange 上の繰り返すイベントのカテゴリーに施した変更がシリーズ全体に正しく適用されなかった問題を解消し、継続時間を伴うタスクが期限を過ぎると見えなくなったバグを修正した。

Cardhop の連絡先カードのデザインが更新され、今回のリリースで Me Contact Card が全連絡先リストの一番上に表示されるようになり、数多くの長いメモがある場合の検索のパフォーマンスを改善し、ニックネームのフィールドにタイプ入力すると予想外の結果になることがあった問題を修正し、Cardhop が関係性を重複して提案した問題を解消し、連絡先に新たなソーシャルプロファイルを追加するとクラッシュを起こすことがあったバグを修正した。(Flexibits からも Mac App Store からも購読年額 $56.99、無料アップデート、66.1/30.2 MB、Fantastical リリースノート/Cardhop リリースノート、macOS 11+)

Fantastical 3.8.19 と Cardhop 2.2.18 の使用体験を話し合おう

Final Cut Pro 10.8, Compressor 4.8, and Motion 5.8 Agen Schmitz  訳: Mark Nagata   

Final Cut Pro 10.8, Compressor 4.8, and Motion 5.8

Apple が 3 つのプロフェッショナル向けビデオアプリにアップデートをリリースした。Final Cut Pro 10.8Compressor 4.8Motion 5.8 だ。Final Cut Pro と Motion は機械学習による新しい Enhance Light and Color エフェクトを追加してカラー、カラーバランス、コントラスト、およびブライトネスを自動的に向上させるようになった。Final Cut Pro は Apple silicon 搭載モデルの Mac 上で AI により強化されたアルゴリズムを使ってスローモーション映像を作成する Smooth Slo-Mo 機能を追加し、エフェクトをインスペクタからタイムラインまたはビューア内の他のクリップに直接ドラッグできるようにし、リール、シーン、カメラアングル、カメラ名、カスタムメタデータ、またはエフェクト名でタイムラインインデックスを検索できるようにし、タイムラインのスクロールを有効にすると字幕がちらつくことがあった問題を解消し、また 8K ProRes MXF ファイルの共有への対応を追加した。

Compressor 4.8 は Apple Vision Pro、iPhone 15 Pro、iPhone 15 Pro Max で撮影された空間ビデオの左目または右目のアングルをプレビューできるようにし、他のアプリケーションでのステレオスコピックワークフロー用に空間ビデオの左目または右目から見たビデオまたは画像シーケンスを作成できるようにし、共有コンピュータのグループを設定する際に This Computer を選択から外すことができなくなった問題を解消した。

Motion 5.8 は Analyze Motion ビヘイビアを適用してムービーを書き出したり、プロジェクト内で Filter や Properties Inspector を切り替えたり、Analyze Motion ビヘイビアの中で Point モードトラッキングを使って逆向きに解析したりする際の安定性を改善した。また、サードパーティの FxPlug プラグインを使うことに関係したハングを修正するとともに、Project Properties Inspector で Color Processing が Automatic に設定されている場合に Keyer フィルターのレンダリングが正しく動作しなかった問題を解決した。(いずれも無料アップデート、いずれも macOS 13.5 Ventura かそれ以降が必要。Final Cut Pro 新規購入 $299.99、5.07 GB、リリースノート、macOS 13.5+。Compressor 新規購入 $49.99、81.6 MB、リリースノート、macOS 13.5+。Motion 新規購入 $49.99、2.23 GB、リリースノート、macOS 13.5+)

Final Cut Pro 10.8, Compressor 4.8, Motion 5.8 の使用体験を話し合おう

Lightroom Classic 13.4 Agen Schmitz  訳: Mark Nagata   

Lightroom Classic 13.4

Adobe が Lightroom Classic 13.4 をリリースして、このデスクトップ中心の写真カタログ・編集アプリに新しいカメラやレンズ (最近リリースされた iPad Air および iPad Pro の前面および背面カメラも含む) への対応を追加してアップデートした。今回のリリースでは Auto-Sync Settings を使用している場合にレンズのぼかしがすべての画像に適用されなかったバグを修正し、GPS 座標の削除に関する同期の問題を解消し、プリセットを適用した後にトーンカーブ設定が引き継がれなかった問題を修正し、コメントアイコンの表示の問題に対処した。(月額 $9.99/$19.99/$52.99 の Creative Cloud 購読、購読者には無料アップデート、リリースノート、macOS macOS 12+)

Lightroom Classic 13.4 の使用体験を話し合おう

OmniFocus 4.3.1 Agen Schmitz  訳: Mark Nagata   

OmniFocus 4.3.1

The Omni Group が OmniFocus 4.3.1 をリリースして、このタスク管理アプリに改善と安定性の修正を施した。今回のリリースでは Device Focus フィルターをアップデートして Dark モードにも適合するようにし、View Options で欠けていたスペイン語の文字列を復旧し、検索位置を割り当てるポップオーバーをスクロール可能なものにし、フォルダにフォーカスする Omni Automation スクリプトが引き起こすことがあったクラッシュを修正し、新規に作成したアクションのインスペクタノートフィールドに素早くタイプ入力した際に起こることがあったクラッシュに対処した。OmniFocus Pro では、別のコンテクストで視点ルールを変更した際にアプリが視点ルールを自動的に再描画するようにするとともに、レガシーカスタム視点のアップグレードをキャンセルする機能を復活させた。(新規購入は標準版が $74.99、Pro 版が $149.99、または月額 $9.99 の購読、31.5 MB、リリースノート、macOS 13+)

OmniFocus 4.3.1 の使用体験を話し合おう

Quicken 7.8 Agen Schmitz  訳: Mark Nagata   

Quicken 7.8

Quicken Inc. がバージョン 7.8 の Quicken Classic for Mac をリリースして、売却や投資の機会を探るために特定の株を監視する Watchlist 機能を追加した。今回のアップデートではまた、レポートでより効率的にフォルダを作成できるようにし、別の人物あるいは会社から受け取る支払いや利子所得を追跡する Loan to Others 項目を作成できるようにし、取引を編集した後で保存する際にそれが見えるように自動的にスクロールされなかった問題を解消し、Payees & Rules ウィンドウでタブを切り替える際に検索フィールドがクリアされてしまったバグを修正した。(講読年額 $59.88/$83.88/$119.88、購読者は無料アップデート、3.2 MB のインストーラダウンロード、リリースノート、macOS 11+)

Quicken 7.8 の使用体験を話し合おう

ExtraBITS

Adam Engst  訳: Mark Nagata   

Apple、"Longevity, by Design" 白書を公開

新たに出版されたホワイトペーパー "Longevity, by Design" の中で、Apple がこう書いている

Apple では顧客の皆様にとっての最良の体験を作り出すことを常に目指しており、だからこそ私たちは長持ちする製品をデザインしているのです。寿命の長い製品を設計することは会社全体の取り組みであり、早期の意思決定は最初の試作品が作られるよりも遥か以前の段階でなされ、歴史的な顧客使用データと将来の使用予測に導かれて進められます。そのためには、安全とセキュリティとプライバシーに関して妥協することなく、耐久性と修理可能性をうまく両立させることが必要となります。

私たちは常に、新しい設計と製造のテクノロジー、継続するソフトウェアサポート、および修理サービス利用の拡大を通じて、製品の寿命を向上させるための努力を注いでおります。

Apple が望まない方向でさらなる Right to Repair (修理する権利) 規制を検討している各国政府を標的にしたホワイトペーパーだと言ってしまうことは簡単だが、私の観点からはより大きな問題であるデバイス寿命について Apple が社内でどのように考えているのかが垣間見えて興味深い。

元記事を読む | 討論に参加