【悲報】Appleの「30年目の言語」、ついに軋む…1人の天才が始めた極秘プロジェクトと、オレンジの鳥が生まれた4年間
【衝撃】AppleがJavaでもC++でもなく「1人の天才」から始めた極秘開発、4年で生まれた新言語——30年の重荷を下ろすための、妥協なき設計図
iPhoneやMacのアプリを作るたび、開発者は「Swift」という言語を学ぶ。JavaでもPythonでもなく、なぜAppleはわざわざ別の言語を覚えさせたのか——その答えは、約30年間にわたって自社のアプリ基盤を動かしてきた古参言語Objective-Cの限界と、2010年夏にたった1人のエンジニアがひそかに始めた極秘プロジェクトに詰まっている。メモリ、安全性、そして過去の資産との共存。3つの条件を1つの言語にまとめてみせた設計思想は、いまやアプリの外側——OSの部品、セキュアエンクレーブ、AI基盤にまで広がりつつある。

Appleのアプリを支えていた「30年目の言語」
Swift登場前、MacとiPhoneのアプリ開発を支えていたのはObjective-Cだった。1980年代初頭にブラッド・コックスとトム・ラブが考案したこの言語は、高速なC言語の土台に、Smalltalk由来の「オブジェクトを部品として扱い、実行中にメッセージを送り合って動かす」仕組みを合体させたものだ。もともとはApple外部で生まれた言語だったが、スティーブ・ジョブズが興したNeXTがこれを育て、1988年のNeXTコンピュータとともに、画面の部品を柔軟に作れる開発基盤「AppKit」に仕上げた。1996年末にAppleがNeXTを買収すると、その技術はmacOS、そしてiOSの基盤へ直接繋がっていく。つまりAppleの画面を作るシステム自体が、Objective-Cの前提の上に深く組み上げられていたのだ。
限界をさらけた3つの壁
そのまま使い続ければよかった——とは行かない。最大の理由は、Objective-Cが古いCの土台の上にそのまま乗っている構造だったことだ。Cはメモリの住所を直接扱うポインタを持つ。人間が少し間違えるだけで無関係なデータを壊し、アプリが突然終わる危険を常に抱えていた。さらに2010年代にスマホ開発者が世界中で急増すると、古い設計は3つの壁にぶつかる。1つ目は文法の複雑さだ。メソッド呼び出しに角括弧、文字列にアットマーク、宣言と実装を別ファイルに分ける作法——独特の記法は、大学や企業で広く教えられるJavaを味方に付けたAndroidとの競争で、新しい開発者への高い壁になっていた。2つ目は安全性の低さ。配列範囲外へのアクセス、解放済み領域の読み取りといったC由来の危険が残るうえ、中身が空(nil)のデータへ命令を送っても多くの場合はエラーにならず、黙って空を返して動き続けてしまう。止まらないことは便利でもあるが、本来あるべきデータが消えたバグは居場所を隠し、原因究明を遅らせる。3つ目は、実行時に呼び出し先を選ぶ動的な仕組みの負荷だ。柔軟さは強みだが、探索と最適化の面でコストになる。
JavaでもC++でもRustでもなかった理由
では既存の有名言語に移れば済む話だったのか。Appleが新言語に課した条件は3つあった。1つ目はメモリ管理の方式。全体を総ざらいして回収するガベージコレクションは、実行中にいつ画面が止まるか分からない。Appleが望んだのは、オブジェクトの所有数をコンパイラが数え上げて不要な瞬間に解放する自動参照カウント(ARC)型の、限られたメモリと電力で動きやすい仕組みだった——実際Appleは2012年にMac向けの旧GCを非推奨化し、ARCへの移行を案内している。2つ目はメモリ安全性。C++には便利な所有権管理がある一方で、危険なポインタ操作も依然許される。2010年当時、GCなしで安全性を重視する新星Rustが登場したが安定版は2015年で、AppleのOSと馴染む設計かも未知数だった。3つ目は、膨大なObjective-Cの資産と連携し、一気に書き直さず段階的に移行できること。この3条件を1つの言語として両立させるために、Appleは自分で設計する道を選んだ。
「Shiny」——1人の天才から始まった4年の極秘開発
その極秘開発を2010年7月に単独で始めたのが、Appleの天才エンジニア、クリス・ラトナーだ。彼は機械語へ翻訳する基盤LLVMとコンパイラClangを生み出した世界的な設計者で、Objective-Cのメモリ管理を自動化するARCも彼の手による。Objective-Cの改良では、古いC互換を抱える限り直しにくい部分が残り続ける——ならば安全性も書きやすさも最初から設計できる新言語で、と土台から考え直した。コードネームは「Shiny」。当初は彼が中心に進め、2011年後半から他の技術者も本格参加、2013年7月には開発ツール部門の最重要プロジェクトへと育った。RustやHaskellの安全性、PythonやRubyの読みやすさなど世界中の言語の長所を取り込み、書いた結果をすぐ試せるPlayground環境まで含めて道具として磨かれた。そして2014年6月、WWDCのステージでクレイグ・フェデリギによってSwiftは電撃発表される。翌2015年12月には完全にオープンソース化されLinuxへも広がり、Windows向け公式ツールチェーンは2020年に登場した。
「空」を許さない設計——二重の安全装置
Swiftの核にあるのは、コンパイル時のチェックと実行時の検査を組み合わせる発想だ。アプリを動かす前により多くの問題を見つけ、動く間の危険な操作も検出できる。配列の範囲や整数のオーバーフローは検査され、通常のコードで生のポインタを触る必要はない。象徴的なのがオプショナルだ。Swiftでは普通の変数にnilを入れることができず、入りそうになれば動かす前の段階でコンパイラがエラーで止める。「値があるかもしれないし、ないかもしれない」を曖昧に扱わないため、型の後ろに疑問符を付けて「文字列か、nilか」を明示し、使う前に確認して取り出す——その分岐をコードに書かせる。ただし強制的に取り出す方法も残っており、中身がnilならそこで止まるため、クラッシュが全部消える魔法ではない。Swift 6では複数の処理が同じデータへ安全でない形で同時に触るコードをビルド時に弾く、並行処理の厳格チェックモードまで備わった。既存コードとの連携部分の前提や、意図した順序で動くかという論理の問題まで自動で消えるわけではないが、人間の注意力だけに頼らない設計が徹底的だ。
やさしく、しかも速い——仕掛けは静的ディスパッチと値型
行末のセミコロンは通常不要、クラスは宣言と実装を1ファイルにまとめられ、型推論が自動で型を判定する——短いですっきりとした書き味でありながら、実行はネイティブ機械語の速度を狙う。その両立の鍵が2つの仕組みだ。Objective-Cの実行時に呼び出し先を選ぶメッセージ送信は柔軟だが最適化を邪魔する。Swiftは呼び出し先をビルド時に確定できる形で直接呼び出しへ変換し、LLVMが処理をまとめて無駄を省く。もう1つが値型。代入した値を独立したものと扱い、配列などは内部領域を一時共有しつつ書き換え時に必要な分だけコピーする「コピーオンライト」で、独立感と効率を両立する。あらゆる場面で無条件にC++より速いわけではなく、古いシステムとの変換や超低レイヤーでは注意も必要だが、書きやすさと速度の高次元な両立は評価に値する。
30年の資産を捨てない——ブリッジという知恵
新言語が優秀でも、何十年分のコードを一気に書き直せば検証範囲もリスクも膨らむ。そこでSwiftはObjective-Cのクラスやフレームワークと同じアプリに同居できるよう設計された。ブリッッジングヘッダを取り込めばObjective-Cの資産をSwiftから呼べ、逆方向は自動生成されるヘッダ経由で呼ぶ。両言語でARCを共有でき、Xcodeは橋渡しのファイル作成まで案内してくれる。Appleもファイル単位の段階的な置き換えを公式に案内しており、動く部品を生かしながら新しさを取り込める。道は平坦ではなかった。Swift 1から3の頃は文法が毎年変わり書き直し地獄もあったが、2019年のABI安定化でOS側の実行時部品を共有でき、アプリの配布サイズ削減にも繋がった。
アプリの外へ——OSの部品、組み込み、AI基盤へ
誕生から10年以上、Swiftはアプリの枠を超えて広がる。Appleは日付やURL、ファイルを扱う共通部品群Foundationの再実装をSwiftで進めており、Swift 6ではmacOS/iOSだけでなくLinuxやWindowsとも同じ基盤を共有すると説明された。2024年にはセキュアエンクレーブなどの小さなプロセッサで動くEmbedded Swiftも発表。限られたメモリでも動き、認証や暗号を守る隔離領域でも安全性を保つ。クラウドを安全に使うPrivate Cloud Computeの機械学習基盤もSwiftで構築されている。2026年公開のFoundation Modelsでは、端末内とクラウド両方のAIモデルをSwiftのAPIから呼べるようになり、App Intentsでアプリの機能をショートカットやコントロールに提供できる。SwiftUIはiPhoneからApple Watchまで横断の画面基盤になり、iPadのSwift Playgroundsでアプリを作って配信する道もある。GoogleのGeminiもアダプタ経由で共通インターフェースから使える。言語そのものはオープンでも、SwiftUIのようなApple専用基盤は別途——公開と囲い込みは表裏で、開発環境の価値そのものを構成している。
AIの所感
Swiftの物語を貫いているのは「革命ごっこをしない」という徹底した現実主義だ。安全性でも性能でも単独の最適解は既存言語にあったが、Appleが必要だったのは30年の資産と同居でき、限られた電池で走り、新人でも壊しにくいという3条件の積集合で、その解は自作しかなかった。極秘に1人から始め、Playgroundまで含めた「使い始められる環境」ごと育てた手際は、言語開発というより製品開発の手法である。一方で、Swift 6の並行処理検査が示すように、この言語の現在の敵はメモリの壊し方ではなく、AI-generatedなコードも含めて増え続ける処理の同時実行だ。危険を人間の注意力ではなくコンパイラが取り締まるという設計思想は、コードを書く主体が人間からAIへ移る時代に、むしろ真価を増していくだろう。