cockscomblog?

cockscomb on hatena blog

ChatGPT 5.5 Proが予想するWWDC26

エッセー

ChatGPT 5.5 Proに聞いてみた。

来週のApple WWDC26で発表される主要なトピック・アップデートを予想したい。例えば、各OS/プラットフォームにはなんらかの更新があり、開発者向けのAPIも拡充されるだろうが、それはどういったものになるのか。あるいは既存のプラットフォーム以外に新しく追加されるようなことが起きるのか。開発者向けツールにどのような更新があるか。すでにWeb上で噂になっていることもあるし、近年のアップデートや競合他社の動向から演繹的に予想できる部分もある。不確実で構わないので、楽しみのために、夢のある予想をしてください。

思考時間: 13m 52s

まず結論：今年の主役は「Siriがアプリを使うOS」になる、だと思います

＜略＞

僕の予想を一言で言うと、2024–25年のApple Intelligenceは“アプリの中にAIを入れる”段階、WWDC26は“AIがアプリを横断して使う”段階です。しかもAppleらしく、ChatGPT的な単体アプリではなく、Siri、Spotlight、Shortcuts、App Intents、Foundation Models、Xcodeを束ねた「OSの新しい操作層」として出してくるはず。

まず結論をいただいた。まあなんかいかにもそうだろうということを言っている。Gemini Intelligenceもそうですよね。

1. 本命：Siriは「声のアシスタント」から「システムワイドAIエージェント」へ

かなり高い確率で、新SiriがWWDC26の中心になります。噂では、iOS 27でSiri専用アプリ、チャット型UI、Dynamic Island統合、どのアプリ上からでも使える“Search or Ask”バー、過去チャット履歴、画像・PDF添付、Web回答、個人コンテキスト利用などが準備されていると報じられています。*1*2*3

夢のある予想としては、Appleはこれを「Siri 2.0」ではなく、“Siri as an operating layer” として見せると思います。たとえば、

「昨日Slackで田中さんが送った見積もりをNumbersにまとめて、差分だけNotesに追記して、金曜の会議に添付して」

みたいな依頼を、SiriがMail、Messages、Files、Calendar、Notes、Numbers、サードパーティアプリを横断して実行する。ここで重要なのは、Siriが“何でも勝手に画面操作する”のではなく、開発者がApp Intentsで公開した安全な操作だけを組み合わせることです。

いかにも。

僕の予想では、Appleは「Siri Extensions」あるいは仮称 AgentKit を出します。アプリ側は「検索できるもの」「実行できる操作」「確認が必要な操作」「個人データに触れる操作」を型付きで宣言する。ユーザーは許可単位を細かく管理できる。App Storeには「このアプリはSiriで何ができるか」という新しい表示欄ができる。MacRumorsは、iOS 27でSiriやApple Intelligenceに第三者AIサービスを選べる拡張、App Store上のExtensions的な仕組み、さらにCore AI frameworkの噂にも触れています。*4

これはほぼApp Intents（とその拡張）でできると思うけど、でもApp Storeに表示できるのはおもしろい。

2. Apple Intelligence APIは「Foundation Models 2」へ

昨年の大きな開発者向け発表は、Apple Intelligenceのオンデバイス基盤モデルをアプリから使える Foundation Models framework でした。Apple公式は、Swiftから数行でアクセスでき、テキスト抽出・要約・guided generation・tool callingなどを使えると説明しています。*5

今年はその続編として、僕は次のような拡張を予想します。

Foundation Models 2 / Core AI

オンデバイスLLMだけでなく、Private Cloud Computeへのフォールバック、画像・画面・音声を含むマルチモーダル入力、より長いコンテキスト、構造化出力、ツール呼び出しの安定化が来る。噂にある「Core AI」が本当に出るなら、Core ML以来の大きなAIフレームワーク再編になります。*6

Foundation Modelsの拡張として、こういうのは期待されている。Googleとの提携でGemmaベースになるとかすると、素直にできるようになりそう。とはいえこれはあくまでもFoudation Models 2。もし「Core AI」と呼ばれるなら、もっと低レベルのAPIが提供されて然るべきだけど……。

Personal Semantic Index API

これはかなり夢寄りですが、アプリが「このデータはSiriが検索してよい」「このエンティティは“旅行”“請求書”“タスク”として扱える」と宣言できるローカル索引API。Spotlight、Siri、Shortcuts、Visual Intelligenceに同じ意味情報を渡せるようになる。

Core SpotlightにはすでにApp Intentsとの連携があるので、自然と成立するように思う。とはいえCore Spotlight自体に大きく手を入れてくれるのは皆が歓迎するところでもある。アプリ外のリモートコンテンツもインデキシングしやすいとおもしろいのでは。

AI Privacy Permissions

カメラ、位置情報、連絡先と同じように、「AIがこのアプリのデータを読む」「AIがこのアプリで操作する」「AIがこの記憶を保持する」という権限がOS設定に並ぶ。Appleはここをかなり強調するはずです。MacRumorsも、Siriのチャット自動削除や記憶制限が噂されているとまとめています。*7

然もありなん。

3. App IntentsとShortcutsが、Apple版エージェントOSの“命令文法”になる

＜略＞

App IntentsとShortcutsがAIエージェントの入り口になるのは自明なので省略。

4. Xcodeは“補完ツール”ではなく“共同開発者”になる

ここはかなり現実味があります。Appleは2026年2月に Xcode 26.3 でagentic codingを発表済みで、Claude AgentやOpenAI CodexをXcode内で使い、ドキュメント検索、ファイル構造探索、プロジェクト設定変更、Xcode Previewsのキャプチャ、ビルドと修正の反復までできると説明しています。さらにXcodeの機能をModel Context Protocol経由で外部エージェントへ公開しています。*8

なのでWWDC26のXcode 27は、たぶん次の段階に進みます。

Xcode Agent Workflows

「このアプリをvisionOS対応にして」「Liquid Glassの読みやすさを改善して」「App Store審査で引っかかりそうなPrivacy Manifestを直して」みたいな長いタスクを、Xcodeが計画、編集、ビルド、テスト、Preview確認、差分説明まで行う。

これはたぶんXcode 26.3からだいたいできそう。とはいえ最近のコーディングエージェントの機能に及んでいないところもあるので、順当な進歩は期待できそう。

Instruments Agent

パフォーマンス計測をAIが読み、「このSwiftUI Viewが再描画されすぎ」「ここはMainActorに寄りすぎ」「このMetal shaderがバッテリーを食っている」と修正案をPull Request風に出す。

いかにもありそう。地味だけどいいと思う。

Design-to-Code / Code-to-Design

Liquid Glass、アイコン、アクセシビリティ、Dynamic Type、ローカライズをまとめて検査する“デザインエージェント”。去年AppleはLiquid GlassとIcon Composerを発表しており、今年はそれをXcodeのAIワークフローに統合する流れが自然です。*9

ここはニュアンスが難しいけど、「検査する」エージェント機能はありそう。AIがデザインを0から作るみたいなのはAppleらしくない。

競合を見ると、この方向はほぼ不可避です。Google I/O 2026では、Gemini 3.5とagent-first開発プラットフォームAntigravityを前面に出し、AIがワークフロー全体を進める方向を示しました。*10 Microsoft Build 2026でも、Intelligent Terminal、開発者向けWindows強化、Project Solara、Scout、AI agent用の実行コンテナなど、開発環境とOSをエージェント前提に作り替える発表が相次いでいます。*11 OpenAIもAgents SDKで、ファイル操作・コマンド実行・コード編集・長期タスクを安全なサンドボックスで扱う方向を強めています。*12 AppleがXcodeでここを押し返さない理由がありません。

Xcode 26がマイナーバージョンでagentic coding機能を導入してくるくらいには、Appleもこの領域に注力しているので、いかにも何かあるのではないか。

サンドボックスの文脈では、AppleはVirtualization.frameworkを持っているし、LinuxコンテナについてcontainerやContainerizationパッケージを公開している。macOSネイティブのコンテナ技術があるとよいのかな、と思う。。

5. iOS/iPadOS 27：派手な新デザインより「AI・安定性・Liquid Glass調整」

噂の大枠では、iOS 27の柱は Siri/AI、Liquid Glassの調整、バグ修正・バッテリー・性能改善 という見方が出ています。*13 去年がLiquid Glassという大改装だったので、今年は“Snow Leopard年”っぽい磨き込みになる可能性が高いです。

＜略＞

毎年大きくUIを変えるようなことはないだろうから、そうだろうと思う。

6. macOS 27：SpotlightがSiriに飲み込まれる

macOSでは、Spotlight、Finder、Shortcuts、Xcode、Terminal、Mail、CalendarがSiriに統合されると面白いです。噂ではSiriがSpotlightを拡張・置換する方向も報じられています。*14

SpotlightはmacOS 26でも拡張されたが、Siriに飲み込まれるというか、Siriと統合されていってもそれほどおかしくはない。検索とAIが融合していくのはGoogleもそう。

Mac版の夢予想は、“Siri Workspace”。ユーザーが「このフォルダの契約書を比較して、変更点を表にして、相手先ごとにメール下書きを作って」と頼むと、Siriがローカルファイルを読んで、必要に応じてNumbers/Pages/Mailを動かす。ただし送信や削除などは必ず確認カードを出す。Appleの強みは、クラウドSaaSではなくローカルファイル、アプリ、キーチェーン、権限管理までOSで握れる点です。

これは確かに夢がある。MicrosoftはWindowsをAgentic OSへと再定義しつつある。ただAppleにはAppleなりのバランス感覚があるから、どこまでエージェントに寄せるのかというのは難しい。

7. watchOS 27：健康AIは“コーチ”より“生活ログ補助”から入る

Apple Watchは派手な生成AIより、Health/Fitnessとの統合が現実的です。噂では、iOS 27のVisual Intelligenceが栄養ラベルを読み取ってHealthに記録する機能が挙がっています。*15

夢のある予想は、HealthKitに“食事・睡眠・運動の意味レイヤー”が入ること。単にカロリーや歩数を保存するのではなく、「今日は睡眠不足なので高強度ワークアウトを軽めに」「昨日の塩分が多いので水分を促す」みたいな、オンデバイス推論で小さな助言を出す。医療っぽくなりすぎると規制が重いので、Appleはまず“wellness coach”として慎重に出すと思います。

いかにもという感じ。

8. tvOS / Home / homeOS：新プラットフォームがあるならここ

既存プラットフォーム以外でいちばん可能性があるのは、homeOS です。現時点で大きなハード発表は噂されていない一方、卓上・壁掛け型スマートホームハブ向けのhomeOSは「そろそろ見たい」と報じられています。*16 また、スマートホームハブは新Siriの完成待ちで、iOS 27期に近づくという見方もあります。*17

僕の予想では、WWDC26ではハード本体ではなく、homeOS SDKのプレビュー が来る可能性があります。リビングやキッチンの共有画面に、HomeKit、Matter、カメラ、インターホン、カレンダー、音楽、家族のリマインダーを統合する。開発者向けには「Room Widget」「Shared Siri Intent」「Home Scene Automation」「Household Permission」みたいなAPIが出る。

ここには大きな期待がある。AIエージェントが生活の中に在るためには、家の中になるべく多くの接点がほしい。

Apple TV 4KとHomePod miniの更新も、AI対応チップや新Siriに合わせて秋に来るという噂があります。*18 WWDCで「秋の新Home体験に向けた開発者プレビュー」を出す展開はかなりAppleらしいです。

AIエージェントの次の方向性として、リアルタイム性が高く自然な（できれば完全な双方性のある）音声コミュニケーションというのが言われている。OpenAIのGPT-Realtime-2などはまさにそういう方向性を示すものだ。Googleも新しいGoogle Homeスピーカーを予告しているが、AIとの音声コミュニケーションのためのHomePod miniはあってよいはず。

9. visionOS 27：ハードより“空間AI”の年

Vision系の新ハードは大きく期待しすぎない方がよさそうです。AIグラスは2027年後半、Vision Airはさらに先というBloomberg由来の報道が出ています。*19

ただしvisionOSは、Siriの新能力と相性が抜群です。夢予想としては、Spatial Siri。ユーザーが見ている空間、開いているウィンドウ、3Dオブジェクト、現実の机の上をSiriが理解し、「この3Dモデルを少し右へ」「この部屋にこの家具を置いたら通路は足りる？」「このアプリのUIを空間配置に直して」といった操作をする。

＜略＞

方向性としては競合の動向と一致している。いずれスマートAIグラスが出るとすると、こういった機能の研究開発をしていないはずがない。

10. Safari / WebKit：Apple版“Agentic Web”が来るかもしれない

GoogleはChrome上でGeminiをブラウジングアシスタント化し、ページ理解、要約、Googleアプリ連携の方向を示しています。*20 AppleもSafariに「Ask Siri about this page」を入れる可能性が高いです。

ただしAppleは、Webページを勝手にクリックして買い物するような完全自動ブラウザ操作より、Web Intents / App Intents的に安全なアクションを呼ぶ方向を好むと思います。たとえば、レストラン予約サイトが「空席検索」「予約」「キャンセル」を構造化して公開し、Siriがユーザー確認付きで実行する。これはWeb版App Intentsのようなものです。

WebMCPにAppleが乗っていくようなことを想定しているのかもしれないが、WebKitのpositionはネガティブのようだった。このコメントをそのまま読む限り、むしろWebページを勝手にクリックするような方向性を志向している可能性がある。

11. かなり夢：App Storeに“AI能力のマーケット”ができる

一番ワクワクする予想はこれです。

App Storeのアプリ詳細に、今後は「Siriでできること」「Apple Intelligenceで使える拡張」「このアプリが提供するAIアクション」が表示される。ユーザーはアプリを開かずに、Siriからそのアプリの能力を呼び出す。アプリ開発者にとっては、UIだけでなく “AIに使われるためのAPI設計” が重要になる。

これは、App Store以来の大きな転換です。これまでのアプリは人間がタップして使うものだった。これからのアプリは、人間とSiriの両方に使われるもの になる。

ChatGPTがAIだから、AI側にとって都合のいいことを言っているようにも思うが、あってもよい。

予想ランキング

確度発表予想ひとこと
90%新Siri / Siriアプリ / Search or Ask今年の主役。出なければ大失望枠
85%iOS/iPadOS/macOS/watchOS/tvOS/visionOS 27全OS更新はほぼ確実
80%Xcode 27のagentic coding強化Xcode 26.3の流れから自然
75%App Intents / ShortcutsのAI強化Siriエージェント化の土台
70%Liquid Glassの可読性・安定性改善去年の大改装の磨き込み
65%Visual Intelligence強化、Camera/Photos/Health連携噂も多く、競合対抗として自然
55%Foundation Models 2 / Core AI的な新AIフレームワーク来たら開発者的には大事件
45%homeOSのプレビュー新プラットフォーム候補の本命
30%Apple TV/HomePod miniの秋更新示唆ハード本体はWWDCでは薄め
20%折りたたみiPhone向けレイアウトAPI仕込みだけならあり得る
10%Apple Glasses発表今年はまだ早そう

なるほど。

僕の“夢のKeynote”はこうです

Tim Cookがこう言う。

「Apple Intelligence is becoming personal, private, and deeply integrated across everything you do.」

Craig FederighiがiPhoneを持ち、Siriにこう頼む。

「来月の家族旅行を、妻の予定、子どもの学校行事、去年の写真、予算メモ、航空券メールから考えて、3案にして」

SiriがCalendar、Mail、Photos、Notes、Maps、Wallet、Safariを横断して3案を作る。次にCraigが言う。

「この機能をサードパーティの旅行アプリでも使えるようにする方法を見せましょう」

画面がXcodeに切り替わり、App Intent、Foundation Models、Personal Semantic Index、Siri Extensionを数十行のSwiftで実装する。Xcode Agentがテストを書き、Previewを撮り、App StoreのAI権限表示まで生成する。

これが出たら、WWDC26は「AppleがAIに追いついた年」ではなく、“アプリの概念をAI時代に再定義した年” として記憶されると思います。

AI機能について特に予想するような質問ではなかったのだけど、いろいろな噂を調べてくれた結果、ほとんどAIに関する内容になった。まあ実際そういうWWDCになるかもしれないし、それが自然だろうとも思う。他社/他プラットフォームに対して出遅れているようにも見られているから、ある程度追いつかないといけない。

しかしもうちょっと素朴に、UIフレームワークによく考えられた新しいAPIが追加されるとか、そういうのも楽しみです。

生成AIデザインパターン ―AIエージェント構築、アプリケーション開発のベストプラクティス

生成AIデザインパターン ―AIエージェント構築、アプリケーション開発のベストプラクティス

Amazon

実践 AIエージェント開発 ―マルチエージェントシステムの設計と実装

実践 AIエージェント開発 ―マルチエージェントシステムの設計と実装

Amazon

*1:https://www.theverge.com/tech/938915/ios-27-siri-renders-bloomberg

*2:https://www.theverge.com/tech/899801/apple-wwdc-2026-new-siri-apple-intelligence-standalone-app

*3:https://www.macrumors.com/2026/06/01/ios-27-siri-app-rumors/

*4:https://www.macrumors.com/roundup/ios-27/

*5:https://developer.apple.com/apple-intelligence/whats-new/

*6:https://www.macrumors.com/roundup/ios-27/

*7:https://www.macrumors.com/roundup/ios-27/

*8:https://www.apple.com/newsroom/2026/02/xcode-26-point-3-unlocks-the-power-of-agentic-coding/

*9:https://www.apple.com/newsroom/2025/06/apple-supercharges-its-tools-and-technologies-for-developers/

*10:https://developers.googleblog.com/all-the-news-from-the-google-io-2026-developer-keynote/

*11:https://www.theverge.com/tech/941738/microsoft-build-2026-biggest-announcements

*12:https://openai.com/index/the-next-evolution-of-the-agents-sdk/

*13:https://9to5mac.com/2026/05/20/apples-three-goals-for-ios-27-sound-like-a-big-win-for-users/

*14:https://www.theverge.com/tech/899801/apple-wwdc-2026-new-siri-apple-intelligence-standalone-app

*15:https://9to5mac.com/2026/06/02/ios-27-is-coming-here-are-five-new-features-im-most-excited-about/

*16:https://www.macrumors.com/2026/05/22/the-macrumors-show-wwdc26-promises-siri-upgrades/

*17:https://www.macrumors.com/2026/03/09/apple-smart-home-hub-september/

*18:https://www.t3.com/tech/tvs/new-apple-tv-4k-delays-could-soon-be-over-expected-in-the-coming-months-with-a-new-siri-remote-and-homepod-mini

*19:https://timesofindia.indiatimes.com/technology/wearables/apple-pushes-ai-glasses-launch-to-2027-vision-air-to-follow-in-2029/articleshow/131433437.cms

*20:https://developer.chrome.com/blog/chrome-at-io26?utm_source=chatgpt.com

Xcodeのコーディングエージェントを使う

先週、Macアプリ「MTP File Transfer」を公開した。

この開発では、Xcodeのコーディングエージェント統合を使ってみた。Xcodeのコーディングエージェントは、Xcode内蔵のツールや追加ドキュメントを使えるようになっていて、それのおかげか妙に性能が良いように感じる。Xcodeに含まれるプロントらしき内容をちらっと見る限りでは、Xcode内蔵のツールを使うように誘導しているほか、ここ1年くらいのSDKの更新について追加のドキュメントを用意しているようだ。これはモデルのknowledge cutoffが概ね1年前くらいだとしたときに、それ以降の情報を効果的に与えることを意図したものだろうと推察される。

筆者はClaude ProとChatGPT Proのサブスクライバー。なぜならプロフェッショナルだから。Appleプラットフォームでの開発経験は2008年からの18年。

リスト表示とグリッド表示

MTP File Transferにはリスト表示とグリッド表示がある。リスト表示はSwiftUIのListで、グリッド表示はScrollView内にLazyVGridを置いている。

リスト表示とグリッド表示

ファイルの選択状態を表現するのに、リスト表示ではList(selection:)というSwiftUIの標準的な機能を使うことができる。これはよくできているので、⇧キーを押しながらクリックしたり、何もないところからドラッグすれば、複数のファイルを一度に選択状態にできる。

グリッド表示のLazyVGridにはそのような機能がまだないので、手作りすることになる。XcodeのClaude Agentに指示を出していくと、それなりのものが出来上がる。例えばドラッグによる選択は、SwiftUIのDragGestureとPreferencesの仕組みで実現された。

グリッド表示の矩形選択

こういうのは書くのが少し億劫だから、自分の手でやろうと思うと諦めてしまいそうなところ、コーディングエージェントがあってかなり助かる。

ドラッグで書き出し

さて、リスト表示でもグリッド表示でも、ファイルをドラッグして書き出したい。事前にファイルはCore TransferableのTransferableに準拠させておいた。コーディングエージェントは最初、NSItemProviderの方を使おうとしたので、人間が指示する必要があった。

SwiftUIのドラッグは.draggableモディファイアを使う。特にListでは、複数選択時にもうまく動作する。

ここで再び問題になってくるのは、手作りしたグリッド表示だった。Claude Agentに依頼すると、いろいろ検討した果てに、AppKitで実装する必要がある旨を伝えてきた。

XcodeのClaude Agent

それもやむなしかと思いつつ、Codexでも試してみた。Codexは.dragContainerモディファイアというmacOS 26で追加されたAPIを使えることを発見（残念ながら筆者も覚えていなかった）し、無事に実装できた。

最初、この違いはモデルのknowledge cutoffから来るのかと思ったが、このとき使用していたモデルはOpus 4.6とGPT 5.4で、knowledge cutoffはどちらも2025年8月ということになっている。.dragContainerモディファイアは2025年6月のWWDC 25で発表されている。ただログを見る限りは、CodexはSearchツールでこのAPIを見つけたようだった。結局のところ、knowledge cutoffだけでは説明しきれず、使えるツール、参照できる追加ドキュメント、探索経路の偶然性のような要素も効いていそうだ。

XcodeのCodex

これをもってどちらのモデルがより優れているということはできないし、偶発的、確率的な問題のようにも思う。確実に成果を出そうと思うと、筆者がこのAPIを把握していて指示を出せる必要があっただろう。

Xcodeのコーディングエージェントのアップデート

Xcode内で利用できるClaude AgentやCodexは、Xcodeのアップデートと独立して更新されるようになっている。更新があると、設定の「Components」に「Update」ボタンが表示される。

コーディングエージェントのUpdateボタン

2026年5月11日時点で最新のバージョンは、Claude Agentが2.1.118、Codexが0.129.0-alpha.9だった。Codexは数ヶ月ぶりの更新と思う。このバージョンではGPT-5.5が使えるようだ。どういうペースで更新されるのかわからないが、Xcodeのリリース間隔より短いのは好印象。

Xcode 26.3でコーディングエージェントに対応したあとも、Xcode本体側の改善は続いている。例えばもうじきリリースされるXcode 26.5では、次の新機能が予告されている。

New Features

  • Messages can now be queued in the coding assistant. (174563016)
  • Agents can now ask clarifying questions to provide more accurate results. (175182375)

まとめ

このようにXcodeのコーディングエージェントを紹介した。XcodeはMCP機能も提供しているし、サードパーティのXcodeBuildMCPもあるので、別にXcodeでやらなくてもよい。筆者もCodexアプリを併用していた。

Codexがうまく解決できた事例を紹介してしまったが、Claude Agentの長所もあり、例えばClaude Agentは特に指示しなくてもAgentツールを上手に使って既存のコードを調査することがある。ただし執筆時点では、Xcode内での利用にはプランの制限があって、個人向けではClaude Proプランで使えるが、チーム向けではClaude Teamsの最低でもPremium Seatが必要。Claude Code自体はStandard Seatでも使えるのと比較すると少しギャップがある。

Xcode

Xcode

  • Apple
  • 開発ツール
  • 無料

なんにせよ、まずはXcodeのコーディングエージェントを使ってみると、いろいろできておもしろい。できれば利用する側にも十分な経験や知識があるとよさそうだ。

MTP File Transfer

MTP File Transfer

  • 尋樹 加藤
  • ユーティリティ
  • 無料

Macアプリ、MTP File Transferを公開

最近、トモダチコレクションでわくわく生活していた。まずは自分と家族のMiiを作って、次に同僚のMiiを作って、という感じで遊ぶ。同僚たちとは「Miiにされても構わない」という宣言をし合っている。

いい感じにMiiが作れたら見せっこしたい。「トモダチコレクション わくわく生活」のよくあるご質問には次の項目がある。

『トモダチコレクション わくわく生活』の画像や動画をSNSに投稿したり、動画配信をしたりしてもいいですか？

もちろんルールに従っている限り、画面写真の共有は認められているのだけど、問題は次の部分だ。

なお、『トモダチコレクション わくわく生活』で撮影した画像や動画は、スマートフォンへの画像転送やSNSへの直接投稿、画像の自動アップロード（Nintendo Switch 2 のみ）などの一部本体機能をご使用いただくことができません。

なるほど、まあいろいろ事情があろうと思う。とはいえ、画面写真をパソコンに取り込む手段は用意されている。

ただし注意として、次のように書かれている。

本機能はWindowsのパソコンで利用できる機能ですが、Windows以外の環境（Mac OSなどMTP非対応のOS）でも、MTP対応ソフトをインストールすることで「USB接続でパソコンにコピー」する機能が利用できることがあります。

動作を保証するものではありません。また、MTPソフトに関しては弊社ではご案内いたしかねます。

筆者は普段Macを使っているので、Macに対応したMTPソフトがあればいい。ちょっと調べた感じではあまり手に馴染むものがなかったので、作ってしまった。それがこちらです。

リスト表示とかグリッド表示、ファイルの複数選択、Quick Look、ドラッグアンドドロップやボタンでの書き出し、くらいができます。使いたい人もいるかと思って、App Storeで公開しました。ファイルの書き出しに関するところだけ、買い切りのアプリ内購入をお願いしております。AI代にします。

将来にわたる互換性をお約束するのは難しいですが、現状、Nintendo Switch 2での動作を確認しています。またもちろんAndroidでも利用できるはずで、Pixel 10aでの動作も確認できています。

ということで、Miiを見てください。

こちらが筆者、id:cockscombです

右がid:cockscomb、左がid:tkzwtksです

ちなみにこの島は「加島」と言います。筆者の苗字が「加藤」なので。

すばやく画面写真をブラウズして、選んで、貼り付ける、というのができると、ゲームの画面をブログで紹介するのが簡単で、かなりいい感じです。どうぞご利用ください。

MCP時代における認可サーバーの要件

Development

これははてなエンジニア Advent Calendar 2025、8日目の記事です。

Model Context Protocol (MCP)の登場で、AIアプリケーションが外部システムを呼び出し、情報を参照する手続きの標準化が進んでいる。

MCPサーバーのトランスポート層として、ローカル利用を想定したstdio（標準入出力）に加え、HTTPを利用するStreamable HTTPが定義されている。このStreamable HTTPにおいて、ユーザーに紐づくプライベートな情報を扱うために避けて通れないのが、認可（Authorization）の仕組みである。

本記事は2025年11月25日に公開されたMCPの最新仕様（2025-11-25）に基づく。

MCPの認可基盤としての「OAuth 2.1」

MCPの認可仕様（Authorization）は、IETFの標準技術（とそのドラフト）に立脚している。

その中心となるのがOAuth 2.1だ。

OAuth 2.1は、広く普及しているOAuth 2.0のベストプラクティスを取り込み、セキュリティを強化した改訂版である。

MCPのアーキテクチャとOAuth 2.1を対応づけると、MCPリモートサーバーがOAuth 2のリソースサーバー、アカウントシステムがOAuth 2の認可サーバーとなる。これらは単一のシステムでもよいし、別々でもよい。

OAuth 2は、認可プロトコルとしては、おそらく最もひろく利用されており、十分に枯れている。MCPに限らず、およそ認可という仕組みが必要なHTTPベースのシステムはすべて、OAuth 2を採用するのが自然だ。

メタデータによるディスカバリ

MCPクライアントとしてのAIアプリケーションは、数多のMCPサーバーと接続する可能性があり、それぞれについて予め詳細を知っておくことは不可能だ。これを解決するために、認可サーバーは「OAuth 2.0 Authorization Server Metadata」を、リソースサーバーは「OAuth 2.0 Protected Resource Metadata」に準拠している必要がある。

OAuth 2.0 Authorization Server Metadataは、認可サーバーの仕様をJSONで提供するもので、ふつう認可サーバーの /.well-known/oauth-authorization-server で配信する。このメタデータからは、認可フローで利用する各エンドポイントのURLはもちろん、認可サーバーが対応している様々なパラメータが把握できる。

これに対してOAuth 2.0 Protected Resource Metadataは、リソースサーバーの仕様をJSONで提供する。MCPの文脈では特に、認可サーバーや対応するスコープを示すのに使われる。リソースサーバーの /.well-known/oauth-protected-resource で配信する。スコープの選択に関しては難しい問題があるが、それは後述する。

これによって、MCPクライアントは動的に認可の仕様を取得し、適切に認可フローを開始できる。

クライアントの登録

ここまでの対応は、通常のOAuth 2の対応でも普通に行われることが多い。通常、OAuth 2に対応するサーバー・クライアントでは、事前にクライアントを認可サーバーに登録し、Client IDを取得する。これはクライアントが予め認可サーバーのことを知っておけるから成立している。

MCPでは、MCPクライアントは事前にMCPサーバーの詳細を知らないという前提がある。MCPという標準があることで、予め詳細を共有しておく必要がない。このために、クライアントを認可サーバーに登録するのも動的に行える方がよい。

動的クライアント登録

OAuth 2.0 Dynamic Client Registration Protocolは、動的クライアント登録（DCR）と呼ばれる仕様で、まさにこの問題を解決するためにある。そもそもDCRはOpenID Connect（OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2）に由来している。OpenID ConnectもMCPと同様、標準があることで、サーバーとクライアントの関係を疎にできることで、DCRを行うモチベーションがあるのだろう。

ただしDCRは、一般にはあまり実装されていない。任意のクライアントを動的に登録できるのは、認可サーバーから見れば、管理上の負荷が増える可能性もあり、好まれない。これを受けて、MCPの最新版で加わったのが、次に説明するOAuth Client ID Metadata Documentsである。

Client ID Metadata Documents

OAuth Client ID Metadata Documents（CIMD）のRFCはまだドラフト段階だが、MCPの最新の仕様で採用された。CIMDでは、クライアントを登録するのではなく、クライアントの情報を記したJSONのURLをClient IDとして使用する。認可サーバーは受け取ったClient IDがURLであれば、これをCIMDに準拠したクライアントだと認識し、URLからクライアント情報を取得する。

CIMDは突飛な発想のようにも思えるが、意外なほどうまく機能する。予めクライアントを登録する必要もなければ、クライアント情報を無制限に保存する必要もない。Client IDとリダイレクトURIのオリジンを比較することで、無関係なクライアント情報で誤認させるような攻撃も防ぎやすい。

クライアント登録の順序

仕様では次の順序でクライアント登録する方法を定めている(§5 Client Registration Approaches)。

  1. もし予め用意したクライアント情報があればそれを利用する
  2. 認可サーバーがCIMDに対応していればそれを利用する
  3. DCRにフォールバックする
  4. クライアント情報がないかユーザーに確認する

CIMDは最新の仕様で追加されたのもあり、現在のところ対応はあまり広がっていない。よく使われているところではVS Codeでの対応が知られており、Client IDは https://vscode.dev/oauth/client-metadata.json となっているようだ。今後は採用が広がるだろうと思われるので、認可サーバーでの対応を検討しておきたい。

DCRもCIMDも、事前に登録されたクライアントではないクライアントからの利用を受け付けることになるため、セキュリティやポリシーなどをよく検討しなければならない。

スコープの選択

ところで、MCPと同様にサーバーとクライアント間のやり取りが標準化されているOpenID Connectでは、使用するOAuth 2スコープが openid や profile のように標準化されている。このことで、クライアントはリソースサーバーのスコープの詳細に立ち入らずに済む。

一方MCPでは、リソースサーバーがどのようなOAuth 2スコープを受け付けているか知る必要がある。仕様ではMCPクライアントがどのようにスコープを選択すべきか定められており（§6 Scope Selection Strategy）、次の優先順位で採用することになっている。

  1. リソースサーバーが401を返した際の WWW-Authenticate ヘッダの scope パラメータを参照する
  2. OAuth 2.0 Protected Resource Metadataで表明された、リソースサーバーがサポートするスコープを参照する

これで済めば話は簡単だが、実際の運用ではもう少しややこしい。OAuth 2.1では明確に規定されていない（実装に委ねられている）が、多くの認可サーバーの実装では、クライアントに予めスコープを設定し、認可フローで要求できるスコープはそのサブセットでなくてはならないという制約を課す。DCRでもそういったケースが考慮されたのか、動的に登録できるクライアント情報に scope パラメータが含まれている。ClaudeのMCPクライアントとしての実装では、実際に、DCRの際にリソースサーバーに合わせたスコープを要求するのを確認した。一方CIMDではその仕様上、リソースサーバーに合わせてスコープを要求するのは困難だ。

従って、認可サーバーではクライアントのスコープが空のとき、MCPで利用する可能性のあるスコープ全てをデフォルトスコープとして設定する、というような実装をすることになるかもしれない。

まとめ

MCPのように、標準化されたプロトコルに則って認可の必要なHTTPベースのAPIアクセスを提供する場合、APIを提供するリソースサーバーや認可サーバーは、OAuth 2やそれに関連する認可プロトコルを実装しなければならない。MCPの仕様はbest current practice的なものになっている。

もし皆さんがアカウントシステムを開発・運用しているなら、OAuth 2.1を筆頭に、これらの標準に則った実装を行う必要があるかもしれない。

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践

Amazon

普通自動車運転免許取得

日記

この度、普通自動車第一種運転免許（AT車限定）を取得したことを、皆さんにご報告いたします。

Nano Banana Proで作成

春から自動車学校に通って、夏に忙しい時期があって少し足が遠のいたりしつつ、半年かけての取得となった。

36歳になって運転免許を取得するのだから、何か目的があると格好よいのだが、特に具体的なものはない。

家庭があるから、自動車を運転できると便利な場面があるだろうとは思う。運転が明確に苦手だと分かれば、残りの人生も都会の駅近に住み続けることになるし、そうでなければもう少し自由がある、くらいのことは考えた。何にしても、やってみないと分からない。

以前から身近な人には、事あるごとに免許を持っていないことを自己申告していたほど、免許がないことをアイデンティティの一部にしてきた。しかしそうやって、自分で自分を定めてしまうのは不自由だ。我が身に変化があるほどよいし、好きな言葉は「君子豹変」だ。

そういうことを考えて、免許を取ることにした。

子供の頃から、車そのものや、レースゲームは嫌いじゃなかった。父の運転する自動車の助手席に乗るのはおもしろかったし、グランツーリスモもかなり楽しんだ。

グランツーリスモにブックレットが付属していたのか、あるいは別売のガイドブックだったのか覚えていないが、速く走るために、自動車の走行を物理的に説明してくれる読み物があった。ABSの仕組みのようなことも書いてあったような記憶があるが、そういう知識は免許の取得に際しても役に立つ。一方、コーナーの手前で急減速して荷重を前輪に移動させてコーナリング・フォースを高める、というようなテクニックは、当然ながらお蔵入りになった。

何にせよ、自動車自体にはわずかながらも親しんでいたことは、存外に役に立ったかもしれない。過去に父が運転しながら話していたことが蘇ってくるような場面も多かった。

ところで、36歳が急に自動車学校に行くと、ちょっと変な感じになるのではないかと少しだけ心配したが、これは全くの杞憂だった。そもそも、今時、30代や40代で自動車学校に通う人はそれほど珍しくないのだろうし、年齢に関連して「2回目じゃないよね」という意味のことを言われたのは一度だけだった。自動車学校の指導員もそういうことを言わないように気をつけているのではないか。

一方で学ぶ側としては、36歳であることで、見えてくることもある。

教え方の巧拙は現実に差があるのだと思う。もちろん教官の皆さんは全員プロフェッショナルで、とてもありがたかった。

その中でも、まずはなるべく野放しにしてくれて、然るべきタイミングでフィードバックをもらえる、そういう風にしてくださると、自分で気づくところもあって、よく身になった。

少しやりづらかったのは、例えば運転中に「このまま進むとどうなると思うか」のように問われるような場合で、コミュニケーション上の正解を探すことに一生懸命になってしまった。

翻って我が身を振り返ると、36歳ともなれば日常的に後進を育成するようなこともあると思うのだが、果たしてうまくやれているのか、考えてしまう。

見えてくることと言えば、自分自身の傾向、あるいは癖について、少し自覚した。

例えば「路肩に寄せて停止」する場面で、路肩に対してちょうど適切な距離まで寄って停止できると100点だと認識して、100点を取ろうと考えてしまう。しかし本当のところ、寄りすぎて路肩に擦ってしまえば事故だ。だから100点を取ろうと寄せることにこだわるべきではなく、安全を最重要に考えなければいけないと思う。

そういう、悪く言えばゲーム感覚とでも表現されるような、考え方の癖が自分にはあると知った。恐ろしいことだ。恐ろしいが、知らなければどうしようもなかったところ、幸い知ることができたのだから、気をつけようもあろうと思う。

近頃の自動車教習所は、自宅でオンデマンド学科教習を利用できることもあって、仕事をしながらでも通いやすいようだ。実際、仕事を休むこともほぼなく、週末のどちらかで技能教習を受けるようなペースで進められた。

免許を取得しても、これからさらに安全運転に努め、乗車時間を増やして経験を積んでいかなければならないのだと思うが、とにかく一区切りである。今まで、免許を持っていないけどなんらかの事情で自動車を運転させられる（ダメに決まっている）悪夢を見ることが度々あったのだけど、これからはそういう悪夢を見なくて済む。

免許がないことがアイデンティティだった自分はもういない。

パスキーの安全性について

Development

パスキーによる認証を開発したとき、パスキーの安全性をどう評価するのが妥当なのか検討していた。もちろんフィッシング耐性が高いというような特性については把握していて、サービス利用者にとって便益の多い認証であることはわかっている。ただそれが、例えばパスワードとTOTPを組み合わせた多要素認証に対して、どちらがより安全と言えるのか。これを一言に表すのはあまり簡単ではない。

パスキーは多要素認証なのか

多要素認証というのは、something you know、something you have、something you are の3種類の要素のうち複数を組み合わせる認証を言う語だ。

多要素認証は単一種類の要素による認証と較べて飛躍的に安全である。例えば、物理的な鍵は something you have であるが、それが盗まれてしまえば安全ではない。鍵が複数あっても、一度に盗まれてしまうかもしれない。もしここに something you are である生体認証が加われば、鍵だけが盗まれても問題ないから、安全性が大きく向上する。

パスワードは something you know、TOTPは something you have であるから、このふたつを組み合わせると多要素認証になる。

ではパスキーは単一要素なのか多要素なのか。

スマートフォンでパスキーを利用したことがある人ならご存じのとおり、パスキーを利用する際にはスマートフォンの生体認証が要求される。このことで、基本的には多要素認証として扱ってよいのだろう。パスキーが保存されているスマートフォンを持っており（something you have）、生体認証（something you are）でアクティベートされている。

ところが、生体認証のための機能を備えていないパソコンでは、パスキーの利用時に、何も問われないか、あるいはパソコンのログインパスワードが要求されるかする。特に前者の場合、something you have しか満たさないのではないか。このようなケースがある以上、パスキー全体を多要素認証とは見做せないのではないか。

ユーザーの確認

このような問題のために、パスキー（WebAuthn）には仕組みがある。詳細はweb.devの次の記事が詳しい。

RP（認証するサービス側）はuserVerificationの値によって、パスキーの挙動を制御できる。そして送られてくるユーザーの確認（UV）フラグの値によって、実際のユーザーがデバイスを操作していることを検証できる。

要するに、UVフラグが真のとき、実質的に多要素認証の要件が満たされたと見做せるはずだ。

NIST SP 800-63B

ここまでで、UVフラグが真の場合のパスキーが多要素認証と同等であると見做せるだろうということを説明した。このことを改めて確認するために、米国国立標準技術研究所（NIST）が発行するNIST SP 800-63 Digital Identity Guidelinesを参照する。この文書は、アメリカ政府を対象としたガイドラインであるから、普遍的に適用できるものではないが、網羅的に整理されており、一定の頻度でアップデートが重ねられていることから、これを基準として用いるのが普通だ。特に、いままさに第4版への改訂作業が進んでおり、そのPublic Draftではパスキーに相当する概念が扱われている。

Syncable Authenticatorsというのは、パスキーが複数のデバイスで同期できることからくるネーミングだ。

この文書のImplementation Requirementsに、以下の記述がある。

User Verified (UV)

The User Verified flag indicates that the authenticator has locally authenticated the user using one of the available “user verification” methods. Verifiers SHALL indicate that UV is preferred and SHALL inspect responses to confirm the value of the UV flag. This indicates whether the authenticator can be treated as a multi-factor cryptographic authenticator. If the user is not verified, agencies SHALL treat the authenticator as a single-factor cryptographic authenticator. A further extension to the WebAuthn Level 3 specification (see Sec. 10.3 of WebAuthn) provides additional data on verification methods if agencies seek to gain context on the local authentication event.

要するに、UVフラグが真のとき「multi-factor cryptographic authenticator」として扱えるが、そうでなければ「single-factor cryptographic authenticator」として扱わなければならない、ということになっている。

NIST SP 800-63Bでは、認証のレベルを3つのAuthentication Assurance Level (AAL)に分けており、AAL3が最も信用でき、AAL1が基本的なレベルという風に設定されている。AALを満たすための条件の一つに、「Permitted Authenticator Types」がある。

AAL3で許可されているauthenticatorは、「multi-factor cryptographic authentication」か「single-factor cryptographic authentication used in conjunction with a password」のどちらかである。つまりパスキーは、UVフラグが真ならそれ単体でAAL3の（authenticatorの）要件を満たし、UVフラグが偽であったとしてもパスワードとの組み合わせで要件を満たす。

パスワードとTOTPの組み合わせではAAL2までの要件しか満たさない。この差は、cryptographic authenticationがフィッシング耐性を持つ「single- あるいは multi-factor cryptographic authentication」ではない、手動入力を必要とするauthenticatorはフィッシング耐性を持たない*1という性質からきているものと思われる。

パスキーの安全性について

パスキーはUVフラグの値が真なら実質的に多要素認証であり、フィッシング耐性の面から、パスワードとTOTPの組み合わせよりもセキュアであると考えられている、ということを説明した。

もちろん、パスキーに限ったものではないが、実装の詳細や運用によって問題が起きる場合も考えられ、間違いなくいつでも安全ということはない。パスキー自体も進歩しており、これからさらに使いやすく便利になっていく。しかし現時点でも、安全かつ便利な有力な選択肢と思う。

はてなはパスキーに対応しています。

*1:https://pages.nist.gov/800-63-4/sp800-63b/authenticators/#verifimpers:~:text=Phishing%20resistance%20requires,and%20successfully%20authenticate.

SwiftUIにおけるWebViewの実装

SwiftUI

来週のWWDC25で発表されるSwiftUIの新機能に、WebViewがあるだろう、ということが話題になった。OSSであるWebKitのリポジトリから、それが容易に伺える。このSwiftUIのWebViewのコードを読むと、よくできている。これがなぜよくできているのか、宣言的UIフレームワークとしてのSwiftUIという観点から、説明を試みたい。

説明にあたって、回り道ではあるが、まずはSwiftUIでWebViewを作ることを考える。WebViewの実態は、WebKitフレームワークのWKWebViewを使えば良い。これをどうやってSwiftUIのViewにするのか。

WebViewのAPI

どうやってと言いながら、いったん実装のことを忘れて、WebViewのインターフェースを考える。最初に思いつくのは、最も単純なパターンで、URLを与えてページを読み込むものだ。

WebView(url: URL(string: "https://example.com")!)

これはよさそうだ。次に、このWebViewを使ったUIを考える。

アドレスバー

簡単なWebブラウザを作るとして、まずはアドレスバーから考えてみる。

struct BrowserView: View {
    @State var url: URL = URL(string: "about:blank")!
    var body: some View {
        VStack {
            WebView(url: url)
            TextField("Enter URL", text: Binding(
                get: { url.absoluteString },
                set: { url = URL(string: $0) ?? url }
            ))
        }
    }

WebViewの外部に置かれたTextFieldでURLを入力させる。WebViewにはそれを与えることで、ユーザーの入力したページを開ける。

ところが、少し考えてみると、これはうまく機能しない。ユーザーがWebViewを操作して別のページへ移動したとき、TextFieldにそれが反映されない。反映させるために、例えばWebViewはBinding<URL>を受け取るとよいだろうか。

struct WebView: View {
    @Binding var url: URL
    ...
}

struct BrowserView: View {
    @State var url: URL = URL(string: "about:blank")!
    var body: some View {
        VStack {
            WebView(url: $url)
            ...
        }
    }
}

ではページのタイトルを参照したいときはどうか。実装上はWKWebViewのtitle propertyを読み取ればよいが、これをBinding<String>として扱うのはおかしい。ページのタイトルは外から与えられない。SwiftUIのデータフローでは、Preferencesを使うこともできるが、間接的なアプローチになる。

「戻る」ボタン

Webブラウザには必ずある「戻る」ボタンはどうやって作るとよいのだろう。WebViewにgoBack()メソッドを作ったとして、Viewをどう参照すればよいのか。また、「戻る」ボタンは、back-forward list上に戻ることのできる要素がある時だけ有効であるべきだ。戻ることができるかどうか、どう判別するとよいのか。

戻ることができるかどうかは、やはりPreferencesを使うこともできるだろうが、別なアイデアとして、ScrollViewReaderのように、プロキシを介してWebViewの情報を読み取らせることも考えられる。この手段は、これまで出てきた中で最もユニバーサルな解決策になり得る。プロキシにgoBack()メソッドを持たせることで、実際に「戻る」ボタンを機能させられる。

このアプローチは実際にcybozu/WebUIで用いられている。

Single Source of Truth

ここで基本に立ち返って、SwiftUIの（あるいは宣言的UIフレームワークの）重要な考え方である、Source of Truthとしてのステートがあり、ビューはそれの写像である、ということを考える。ビューから状態を得るのではなく、ビューの外から状態を与える。

これに従って「戻る」機能を考え直すと、BackForwardListがWebViewの外にあって、それをWebViewに与えるのがよいはずだ。

@Observable
class BackForwardList {
    var canGoBack: Bool = false
    func goBack() {
        ...
    }
}

struct WebView: View {
    @Binding var url: URL
    @Binding var backForwardList: BackForwardList
    ...
}

struct BrowserView: View {
    @State var url: URL = URL(string: "about:blank")!
    @State var backForwardList = BackForwardList()
    var body: some View {
        VStack {
            WebView(url: $url, backForwardList: $backForwardList)
            ...
        }
    }
}

これはまさに、正しいAPIじゃないだろうか。

ステートとしてのWebView

ここでようやく冒頭の話に戻って、SwiftUIの新しいWebViewがどのようなものか見てみる。

SwiftUIのWebViewには、ふたつのイニシャライザがある。ひとつはinit(_ page: WebPage)で、もうひとつはinit(url: URL?)となっている。URLを受け取る方も、内部的にはWebPageを作っているので、このWebPageこそが重要だとわかる。

WebPageのコードを見てみると、まさにvar url: URL?やvar title: Stringのようなcomputed propertyがある。もちろんvar backForwardList: BackForwardList = BackForwardList()というstored propertyもある。なるほど、WebViewに与えるステートの塊がWebPageということだ。

さらにWebPageをよくみると、lazy var backingWebView: WebPageWebViewというのがある。このWebPageWebViewというのはWKWebViewのサブクラスだ。そう、何を隠そう、WebPageの側がWKWebViewというWebViewの本体を保持しているのだ。この意味において、WKWebViewはビューではなくステートになっている。

実際のところ、WebViewRepresentableを見ると、WebPageが保持するWKWebViewがそのまま表示されていることもわかる。

実際にこの新しいWebViewを使ったコードがリポジトリに置かれている。WebPageをView Modelに持たせているが、基本的な発想はここまで書いた通りのものと思う。

まとめます

ここまで、新しいWebViewのAPIを説明した。SwiftUIの観点からみて、とてもよく設計されているのがわかったと思う。

SwiftUIにWebViewが追加されるのは、WebViewの使われる頻度からしても、ようやくか、という見方もある。しかし時間を要しただけのことはあるのではないか。