本当にクレイジーな時代になりました。新しいAIツールやアイデアが、開発者の働き方をほぼ毎日のように塗り替えていきます──自分のAIワークフローを改善するために時間を投じた途端、新しいものが出てきて、組み立てたばかりのワークフローが古く見えてしまう。これは、かつてのApple系プラットフォーム開発の感覚とは正反対です。新しいツール群はもともと年に一度の発表でまとめて出てきて、WWDCの週は少なくとも僕にとっては「業務時間中のクリスマス」のようなもの──落ち着いていて、見通しが立って、ワクワクするイベントでした。
この心地よさは、しばらく前からじわじわ崩れていました。オープンソースのSwift、Swift Evolutionプロセス、数週間ごとにリリースされるパッケージやツール、Swift on Android──こうしたものが少しずつ、動きの中心をWWDCの枠の外へ押し出してきました。ただ、流れが本当に変わったのはChatGPTとClaude Codeの登場以降です。正直なところ、エージェント以前の時代、つまり「開発者のためのAI」がほぼチャットウィンドウとオートコンプリートを意味していた頃、僕はAIツールに懐疑的でした。それがこの12か月のどこかで変わって、それ以来「自分の開発ワークフローはそもそも今どういう形をしているのか」を探り続けています。多くの人と同じように。
そんな中でAppleがWWDC26を6月8日の週に開催すると発表し、こうはっきり書いてくれたのは素直に嬉しかったです：「AIの進化と、ワクワクするような新しいソフトウェアおよび開発者向けツールを含む、Appleプラットフォームへの素晴らしいアップデート」。そこで腰を据えて、自分にこう問いかけてみました──Appleにしか出せず、しかも僕のエージェント駆動の開発ワークフローを最も改善してくれるものを5つ挙げるなら何か？ その答えがこの記事です。
ℹ️ 過去のWWDCウィッシュリストの約33%は、実際にリリースされています。WWDC24のウィッシュリストからは2件が後から実現しました：WWDC25でのString Catalogの複数選択と、Xcode 26.3のMCPサーバーの新しい
RenderPreviewツール（サイクル途中の2月にリリース）です。Appleはちゃんと届けてくれます──ときにはWWDC本番の外側で。
#1 – LLMグレードのUI内省API
エージェントに「コードを変更したあと、画面が本当に正しく見えているか」を確認させたいとき、現状の選択肢は2つです：マルチモーダルモデルにスクリーンショットを送る（遅い、コストがかかる、脆い）か、Peekabooやxcodebuildmcp経由でアクセシビリティツリーを取得する（マシだけど、AX APIはそもそもスクリーンリーダーのために設計されたもの）。AXツリーが教えてくれるのは*「これは『保存』というラベルのボタンです」*まで。そのボタンが44pt、コーナー半径が12、16ptスペーシングのHStackに入っていて、0.3秒のトランジションでフェードインし、タップで非同期のネットワーク呼び出しを発火する──そういう情報は出てきません。
XcodeのView Debuggerは、すでにこの多くを公開しています。実行中のアプリで、各ビューのフレーム、モディファイアスタック、Constraints、レイヤープロパティ、アタッチされたジェスチャー認識器を構造化された形で見ることができます。足りないのは、それらのテキスト形式・機械可読なエクスポートです。想像してみてください、僕のエージェントが実行中のアプリにこう尋ねられるとしたら：「インタラクティブな要素ごとに、サイズ・色・ジェスチャー・アニメーション・非同期フックを含むレイアウトツリー全体をJSONでください」。クリック対象の決定が決定論的になります。エージェントはポーリングではなく、正しい非同期処理を待てるようになります。タップしたあとには、新しいレイアウトを読んで期待状態と比べることができます──スクリーンショットを一度も撮らずに。
そしてもしSimulatorがSwiftUI Previewsのようなホットリロードに対応し──同じ内省APIをPreviews自身も公開してくれたら──UI作業のイテレーションサイクルは、人間が回す場合もエージェントが回す場合も、分単位から秒単位に縮みます。
エージェントにとって、アクセシビリティツリーは間違った抽象です。あれはスクリーンリーダーのユーザーが線形にナビゲートするために最適化されています。エージェントがたどるべきなのは本物のビュー階層です：クリック可能な領域、スクロール可能なエリア、ロード状態、アニメーションのタイミング、非同期フック。Xcodeのデバッグ専用トグルとして**「AI評価のためにアニメーションを無効化」**があれば、エージェントはアプリ全体を分単位ではなく秒単位で歩けるようになります。さらに視野を広げて、このAPIをシステム全体に拡張し──デバッガーの下にあるアプリだけでなくすべてのアプリが公開する形にすれば──エージェントはシステム上のどんなアプリでもナビゲートできるようになり、開発者にはデバッグモード時に追加のデバッグ向け機能も使える、という構図ができます。
エージェントが購読できる、構造化されたレイアウト／スタイル／ジェスチャーAPIがほしいです──それに加えて「アニメーションを無効化」のデバッグトグル、そしてSwiftUI PreviewsとSimulator（ホットリロード付き）にも同じ表面があってほしいです。
#2 – インテントレベルのUIフローのためのSwift DSL
正直に言います：僕はUIテストを一切書いていません。ゼロです。CrossCraft、TranslateKit、Posters──どれにもUIテストはありません。書こうとするたび──2024年やそれ以前──次のレイアウト調整で壊れて、テストを直すのにバグそのものを直すよりも長い時間を費やすことになりました。あきらめました。それ以降は1本も書いていません。
問題はテストすること自体ではなく、アンカリングの方です。今のテストはアクセシビリティID、ボタンのラベル、ピクセル位置に紐づいているので、NextをContinueに名前変更したり、シェブロンアイコンに差し替えたりするだけで全部壊れます。本当に表現したいのは意図です：「次の画面に進ませるボタンをタップする」。これを読んだ人間なら、ラベルが何であれ何をすればいいか分かります。
願い#1がエージェントに「画面の上で何が起きているか」の構造化された見方を与えるとすれば、こちらは開発者に、エージェントが歩くべきフローを記述するためのSwiftネイティブなDSLを与えます。Appleが設計する小さなマークアップ言語、それも@Observable、@Model、#Previewを生んだのと同じマクロツールキットで表現されたもの：
#UIFlow("ホーム画面から9×9のパズルを作成する") {
action("新しいパズルを開始する")
choose("9×9", from: "グリッドサイズのピッカー")
action("作成を確定する")
wait("生成が完了するまで", timeout: .seconds(30))
expect("空の9×9パズルグリッドが表示される")
}動詞は意図しているとおりに、意図ベースの形にしてあります。action("新しいパズルを開始する")はボタンの名前ではなく、結果を名指しています。もし僕の画面に「新しいパズルを開始する」ためのはっきりしたアフォーダンスが1つもなかったら、それは他のどんなことよりも先にテストが捕まえるべきユーザビリティバグです：レイアウトツリー全体を持ったLLMは、初めてアプリを試すユーザーのかなり良い代理になります。エージェントが明確な一致を見つけられないなら、僕の情報設計がたぶん見直しを必要としています。
そしてパフォーマンスのベースラインと同じように、システムはフローが初めて成功した時点でリファレンススナップショットを保存できます──ピクセルパーフェクトな目標ではなく、僕が以前承認したレイアウトの状態を。次回以降の実行で、エージェントはこう比較します：この状態は良かった、これが新しい状態、ユーザーは「空の9×9グリッド」を望んでいる──リファレンスではそうだったか、今もそうか？ 人間が見ても「壊れている」と言うときだけ落ちるテストにとって、ちょうどいいファジーさです。
Appleが設計するSwift DSLがほしいです。僕がUIフローを意図ベースで記述し、エージェントが実行中のアプリに対してそれを実行し、リファレンススナップショットによって「以前承認した状態にレイアウトがまだ一致しているか」をエージェントに伝えてくれる──そういう仕組みです。
#3 – もっと能力の高いオンデバイスLLM
5つの中で、今すぐにでも動かしたいのがこれです。オンデバイスLLMはプライバシー、レイテンシ、コストで勝てるので、外部API呼び出しを何十か所もこれに置き換えたい。でもSystemLanguageModel.defaultは入力＋出力合わせて4,096トークンでキャップされています──iPhoneでも、僕の36GB M4 Max Mac Studioでも同じ上限です。コンテキストを増やす方法も、より大きなモデルを要求する方法も、ユーザーが自分のモデルを持ち込む方法もありません。
これは二重の機会損失です。Mac Studioには30GB以上の使われていないRAMがあって、システムはそれを使ってより良い回答を返してはくれません。そしてサードパーティのモデル提供者──Mistral、Qwen、来年に素晴らしいSwiftコーディング向け14Bを出すかもしれない誰か──は、アプリがすでに使っているシステム表面に接続する経路を持っていません。
僕がほしいのは、要求ベースのAPIです。開発者が呼び出し側で表現できる、直交する2つの軸：
推論バジェット – この呼び出しはどれくらいの考える時間を許容できるか？ メモを分類するのは即時でなければなりませんが、長文ドキュメントの要約なら数秒かけてより丁寧に走らせていい。
モデル能力 – モデルにはどれくらいの能力が必要か？ カレンダーイベントへのタグ付けなら、利用可能な最小モデルでも問題ありません。仕上げ済みのメールを書いたり、構造化データを推論したりするなら、その端末で動く最大のモデルがほしくなります。
それに加えて当然ながら、プロンプトが実際に必要とする最低コンテキストウィンドウも。現状、オンデバイスAPIはおおむねこんな形です──きれいですが、SystemLanguageModel.defaultに固定されています：
let session = LanguageModelSession()
let response = try await session.respond(to: prompt)僕がほしいのは、呼び出しの要求をセッション境界で宣言して、システム側に合うモデルを選ばせる形です：
let session = LanguageModelSession(
requirements: .init(
minimumContextTokens: 32_000,
capability: .high,
inferenceBudget: .relaxed
)
)
let response = try await session.respond(to: prompt)システムはこの要求を、実際に手に入るもの──どのモデルがインストールされているか、RAMはどれだけ空いているか、Neural Engineはどれくらい忙しいか──と突き合わせて選びます。そしてもう一つ、RAMがオーバーロードしないようリクエストをキューイングしてほしい：2つのモデルを並列で走らせてMac Studioを何度クラッシュさせたか分かりません。Swiftのasyncがシステム上の他のすべてのリソースを面倒見てくれているのに、推論だけが手作業で調整しなければいけない例外であってほしくありません。
僕がAppleに本気で取り組んでほしいのは、ユーザーがインストールするサードパーティモデルを第一級の概念として扱うことです。ユーザーはシステム設定 → Apple Intelligence → インストール済みモデルに行って選びます：Apple純正、Mistral、Qwenコーダーのファインチューン──信頼できて、ストレージに余裕のあるものを。アプリは1行も変更しません。なぜなら、システムにはモデル名ではなく能力の言葉で話しかけているからです。ユーザーが選んだモデルが呼び出しの要求を満たすなら、システムはそれを使います。満たさないなら、システムは要求を満たすインストール済みモデルにフォールバックします。アプリは「どのモデルが呼び出しを引き受けたか」には関心がなく、「自分の要求が満たされたかどうか」だけに関心があります。AppleはAPI契約のコントロールを保ち、ユーザーは自分の端末にどのモデルを置くかをコントロールし続けます。
同じテーマで、システム全体の単一モデルレジストリも。今の僕のディスクには、OpenWhisprが使うparakeet-tdt-0.6b-v3モデルが入っていて──さらに僕が動かしている他の2つの文字起こしパイプラインも、それぞれが同じモデルの自分用コピーをダウンロードしてきます。Qwenのモデルでも同じことが起きています：LM Studioが持っていて、別件の自プロジェクトはCLI経由で自分用のコピーをわざわざ取ってくる──すでにあるものを使い回さずに。混乱です。統一されたインストールレジストリがあれば、Mac上のどのアプリでも「すでに何があるか」を発見して再利用できるようになります。今のように、ツールごとに自分のコピーを管理する必要はなくなります。
ついでにお願いを：EUでも初日にローンチしてください。 🙏
ユーザーがインストールできるサードパーティモデル、システム管理のRAMとリクエストキューイング、共有された単一のモデルレジストリ──そしてEUでの初日対応も含めた、要求ベースのオンデバイスLLM APIがほしいです。
#4 – AIエージェント向けのヘッドレスXcode
最近の僕は、ほとんどの時間をコードを書くことに使っていません。スペックを書いて、エージェントからのPRをレビューして、TestFlightビルドがiPhoneに届くのを眺めています。今は、僕のClaude CodeとCodexのセッションを全プロジェクトにわたってオーケストレーションするMac mini向けアプリを作っているところです──基本的にはPlanKitとTandemKitが今やっていることに、Sandcastle的な「Macアプリをコンパニオンアプリからリモート操作する」という発想を加えたもの──ネイティブのmacOSアプリとして仕立て、TestFlightベータで配信して、外出先からでもレビューできるようにする、というものです。Mac miniはそこに置いておいて、エージェントが自律的に作業し、僕は自分でXcodeを開かないまま結果をレビューします。
このワークフローでは、Xcodeを見る必要はほとんどありません。IDEのウィンドウ、Project Navigator、ソースエディター──もう僕のためのものではありません。エージェントのためのものです。そしてエージェントにウィンドウは要りません。要るのはAPIです。
僕が本当にほしいのは、メニューバーの中のXcode Serverです：MCP表面をフルに公開し、複数プロジェクト間でビルドをスケジューリングし（大きなSwiftコンパイルが2つコアを取り合わないように）、プロジェクトごとに必要なときだけderived dataを掃除し、ウィンドウは1つも開かないヘッドレスなビルドデーモン。xcodebuild --daemonにIDEの賢い部分を残して、UIを引きはがしたものを想像してください。手で書く開発者にはフルのXcodeが残ります──でも、たくさんのアプリにわたってエージェント艦隊を指揮する立場の僕たちにとっては、ウィンドウのないXcodeは本気でリソースと摩擦を節約してくれます。（ビルドスケジューリングとderived data周りは、結局自分のアプリで実装することになりそうです──でも、組み込みでやってくれた方がやっぱりきれいです。）
メニューバーに置ける、ヘッドレスでエージェントファーストのXcode Serverがほしいです。
#5 – LLMネイティブ開発のための新しいパラダイム
ここからは思弁的な話です。Appleが開発者を本当の意味で驚かせた最後のとき──誰もビンゴカードに書いていなかったような発表──は2019年のSwiftUIでした。もうすぐ7年前です。AIエージェントは、僕たちの働き方にとって今世代の地殻変動です。そして自問してしまいます：SwiftとSwiftUIは、この新しい世界のためのプリミティブとして本当に正しいままなのだろうか？
LLMは、自分が生成する対象の言語が、最初からLLMを前提にして設計されていれば、もっと信頼できるコード生成器になるかもしれません──曖昧なDSLの罠が少なく、直交した合成がしやすく、レイアウトと振る舞いが、人間にも読めてエージェントにも内省できる単一の宣言的形式で表現される、そんな言語に。あるいは新しい言語ですらなく、僕がまだうまく思い描けない新しいパラダイムなのかもしれません。それが何であれ、僕はそういう瞬間を期待しています。
Appleは「AIの進化」というフレーズでハードルを上げました。最終的に開発者向けに出てくるものが、Geminiベースで動くSiriと、Xcodeコーディングアシスタントの磨き込みやバグ修正だけなら、それはがっかりです。プラットフォームレベルでの作り直しを見せてください。
AIネイティブなパラダイム──次のSwiftUIモーメントがほしいです。
まとめ
Appleはなかなかない位置にいます──シリコン、OS、IDE、App Store、そしてモデルそのものを、すべてこの会社がコントロールしているからです。このリストにあるほとんどすべての願いは、その統合されたスタックでなければうまくやれないものばかりです。だから僕はいまだに乗り換えずにApple系プラットフォーム上でビルドし続けていますし、だからWWDC26がAIツーリングに対してその優位を本気で活かす年になることを期待しています──「後付けのAI」として扱う年ではなく。Keynoteを観ながら、このリストをずっと開いておくつもりです。
あなたのリストには何が載っていますか？ BlueskyかMastodonで教えてください。
P.S. – これは願いというよりバグに近い気がしてTop 5には入れませんでしたが、僕の本当の最上位はこのダイアログです：
お願いだから、お願いだから、これを1日に50回も見せるのをやめてください。毎回。すべての。セッションで。何度も。何度も。修正のためにWWDCを待つ必要もありません。先にお礼を言っておきます。🤍 （このワークアラウンドを使っています。）