Googleは2026年10月1日、サーバー向けの公式ライブラリ「Google Cloud API Client Libraries for Swift」を発表した。Swift 6.2以降で、Cloud StorageやAI、アクセス権を管理するIAMなど、100を超えるGoogle Cloudサービスを利用できるとしている。
Swiftでサーバーアプリを開発する環境はすでに整っていたが、Google Cloudの各種APIを公式ライブラリから利用できるようになった。バージョン0.4.0からは一般提供（GA）となり、本番環境での利用もサポートする。
ただし、APIへ接続するための定型処理をSDKに任せられるようになることと、アプリの権限設計や障害時の動作まで自動的に安全になることは別だ。Googleの発表と提供方針を見ると、公式SDKに任せられる範囲と、開発者自身が判断すべき部分が分かる。
SwiftのサーバーからGoogle Cloudを公式ライブラリで呼び出せる
VaporやHummingbirdは、SwiftでHTTPリクエストを受け取り、処理を振り分けたり、データベースと連携したりするためのWebフレームワークだ。Swiftの公式ドキュメントでも、LinuxやmacOS上でサーバーを開発するための選択肢として紹介されている。
今回のGoogle Cloud向けライブラリが担うのは、こうしたサーバーアプリからGoogle Cloudのサービスを呼び出す部分だ。
たとえばHummingbirdで利用者からのリクエストを受け取り、その内容をGoogle CloudのAIサービスへ送るバックエンドを作る場合、WebサーバーとGoogle Cloud APIのクライアントでは役割が異なる。
GoogleのCloud Run配備ガイドでは、HummingbirdからGeminiを呼び出すHTTPサービスをCloud Runへ配備する例を示している。SwiftでWebサーバーを書くところから、Google Cloudへの認証、API呼び出し、Cloud Runへの配備までを一つの手順として確認できるようになった。
ライブラリはGoogle CloudのサービスとAPIバージョンごとに分かれ、Swift Package Managerから必要なパッケージだけを追加する。
設計文書によると、認証や通信などの共通処理を担うライブラリと、各サービスの仕様から自動生成されるクライアントを分けた構成になっている。
アプリが実際に利用するサービスだけを依存関係へ追加できるため、Google Cloud向けの巨大なSDKを丸ごと組み込む必要はない。
iPhoneやMac向けアプリをSwiftで開発してきたチームにとっては、既存のSwiftの知識をバックエンドでも活用しやすくなる。アプリ独自のデータ型を共通パッケージにまとめれば、クライアントとサーバーで同じ型定義を共有することもできる。
ただし、共有できるデータ型やビジネスロジックと、SwiftUIやUIKitなどAppleのUI技術に依存するコードは別だ。バックエンドをSwiftで書いたからといって、iPhoneアプリの画面コードまでLinux上でそのまま使えるわけではない。
Google Cloudとの通信は、すべてgRPCではない
Googleの発表では、SwiftNIO、HTTP/2、gRPCといった技術が紹介されている。ただし、Google Cloud API Client Libraries for Swiftが、すべてのサービスでgRPCを使うわけではない。
設計文書の通信方式の説明では、大半の自動生成クライアントは標準でHTTP上のREST/JSONを利用するとしている。一方、Cloud Storageの一部や高性能なストリーミングAPIなど、gRPCを必要とするサービスには専用のgRPC通信層を使う。
Secret Managerの一覧取得処理でも、HTTPクライアントを使ったGETリクエストを確認できる。
開発者から見えるSwift APIはasync/awaitで統一されていても、その内部で使われる通信方式まで一つに統一されているわけではない。既存のHTTPプロキシや監視ツールとの相性を考える場合にも、「Google CloudのSwift SDKはすべてgRPC」と考えないほうが実装に即している。
HTTP通信を支える仕組みには、Swiftのサーバー開発で広く使われる非同期ネットワーク技術が利用されている。接続ごとに専用スレッドを割り当てて待機させるのではなく、データを送受信できるタイミングに応じて処理を進めることで、ネットワーク待ちの間にも別の処理を進められる。
一方、SwiftNIOの説明では、イベントループ上で長時間かかるブロッキング処理を実行すると、同じイベントループで処理するほかの接続まで止まってしまうと説明している。非同期APIを利用していても、アプリ側で重い処理をどこに置くかは性能に影響する。
Swift 6の並行処理チェックについても、守れる範囲を分けて考える必要がある。SDKの公開型は、並行処理の間で安全に受け渡せることを示すSendableに対応する。
Swiftの言語ガイドが説明するデータ競合とは、複数の処理が同じ変更可能なデータへ不適切に同時アクセスする問題だ。
Swiftの型システムでこうした問題を検査できても、Google CloudのIAM権限が適切かどうかや、同じリクエストによってデータベースへ二重に書き込まれるといった業務上の問題まで防げるわけではない。
SDKに任せられることと、開発者が決めること
クラウドAPIを利用する際には、認証情報の取得、通信エラー後の再試行、大量の結果を取得するときのページ処理など、サービスを問わず繰り返し必要になる処理がある。
Googleの公式SDKがまとめて扱うのは、こうしたAPI接続に共通する処理だ。一方、アプリにどの権限を与えるかや、Cloud Runへどのように配備するかまで自動的に決めてくれるわけではない。
Googleの設計文書と利用ガイドを役割ごとに整理すると、次のようになる。2026年10月3日に確認した公式資料に基づく整理であり、実際の性能や運用結果を測定したものではない。
| 作業 | SDKが担う処理 | アプリ側に残る設定・判断 |
|---|---|---|
| 認証 | 実行環境から認証情報を探し、トークンを保持・更新する | どのサービスアカウントに、どのIAM権限を与えるか |
| 再試行 | 一時的なエラーなどで、安全に繰り返せるリクエストを再送する | 業務上の重複実行を避け、待ち時間や再試行条件を決める |
| 一覧取得 | AsyncSequenceを使い、ページトークンや次ページの取得を処理する |
全件を自動取得するか、ページ単位で扱うか |
| Cloud Runへの配備 | 配備後のサービスからGoogle Cloud APIを利用できる | APIの有効化、IAM権限、コンテナのビルドと配備 |
表の根拠はGoogleの認証設計、再試行ガイド、一覧取得ガイド、Cloud Run配備ガイドである。実際に必要な設定は、利用するサービスやアプリの要件によって異なる。
認証にはApplication Default Credentials（ADC）が利用できる。ADCは、実行している環境に応じて利用可能な認証情報を探す仕組みだ。
たとえばローカル開発ではGoogle Cloud CLIで取得した認証情報を使い、Cloud Runではサービスに割り当てたサービスアカウントを使う、といった違いをライブラリ側で吸収できる。
ただし、どのサービスアカウントへどの権限を与えるかは開発者が決める必要がある。Cloud Runの公式例でも、専用のサービスアカウントを作り、Geminiを利用するための「Vertex AI User」ロールを付与する手順は別に行う。
認証処理を書く手間が減っても、「何へのアクセスを許可するか」という権限設計までSDKが決めるわけではない。
再試行にも具体的な条件がある。既定では、60秒または10回の試行のうち、先に達した時点で再試行を終了する。待機時間には指数バックオフを使い、最初は1秒、最大1分まで延ばす。
また、同じ操作を繰り返しても結果が変わらない「冪等」なリクエストかどうかについて、SDKは保守的に判断し、標準ではGETとPUTだけを該当するとみなす。
再試行するのは、一時的なエラーが起き、なおかつ安全に繰り返せるリクエストの場合や、データを送信する前に失敗したことが分かる場合だ。
開発者は、クライアント全体または個々のリクエストについて再試行ポリシーを変更できる。ただし、本来は冪等ではない操作を「安全に再試行できる」と指定すれば、同じ処理が複数回実行される可能性がある。
公式SDKに再試行を任せる利点は、障害を自動的になかったことにできる点ではない。どのエラーで再試行し、何秒待ち、いつ諦めるかを共通の仕組みで管理できる点にある。
GAになったが、0.xでは互換性に留保もある
公式リポジトリでは、9月30日付のREADME変更で、提供状況の説明が公開プレビューから「0.4.0以降はGA」へ変更された。
現在のREADMEでは、0.xの段階でも本番環境での利用をサポートし、必要な修正を提供すると明記している。一方、1.0へ到達するまでは、小規模な互換性を壊す変更を加える可能性も残している。
また、設計文書の冒頭には「APIは安定しておらず、本番コードで使う準備ができていない」という以前の記述が残っている。これは現在のREADMEにあるGAの説明と一致しないため、実際の提供状態を判断する際には、READMEの「Status and Stability」と最新のリリース情報を基準に確認するほうがよい。
GAになったからといって、将来の更新でも既存コードが必ずそのまま動くという意味ではない。
各サービス向けのパッケージの多くは、Google Cloudのサービス仕様から自動生成されている。その仕様自体に互換性を壊す変更が入れば、Swift側のAPIにも影響する可能性がある。Googleはこうした変更を検出し、0.xではマイナーバージョンを上げるとしている。
また、READMEではswift-tools-versionの変更を破壊的変更とは扱わないとしている。そのため、ライブラリのバージョンだけを固定していても、必要なSwiftのバージョンが変わればビルド環境へ影響する場合がある。
現在サポートしているのはSwift 6.2、6.3、6.4の直近3マイナーバージョンで、最低対応バージョンは今後も更新される。LinuxではUbuntu 24.04と互換ディストリビューションでテストされ、macOSは15以降が対象となっている。
Macでバックエンドを開発し、Linuxコンテナとして本番環境へ配備する使い方も想定されているが、導入時には利用するパッケージとSwiftツールチェーンの組み合わせを確認する必要がある。
iPhoneアプリ向けSDKとは役割が違う
今回のライブラリは、iPhoneやMacアプリから直接Google Cloudの管理APIを利用するためのSDKではない。
公式の製品区分では、Firebase Apple SDKとGoogle Cloud API Client Libraries for Swiftの役割を分けている。
Firebase Apple SDKは、端末側のユーザー認証やFirebase Security Rulesなどを利用する。一方、今回のGoogle Cloud向けライブラリは、サーバー側でサービスアカウントやADCを使い、Google Cloudの各種サービスへアクセスすることを想定している。
クライアントとサーバーをどちらもSwiftで書けるからといって、サーバー用の管理権限を持つ認証情報までiPhoneアプリへ組み込んでよいということにはならない。
端末から直接Firebaseへアクセスする機能と、自前のバックエンドを通してGoogle Cloudのサービスへアクセスする機能を分けて設計する必要がある。
Swiftのコード資産や開発経験をすでに持つチームにとっては、公式ガイドに沿って小さなCloud Runサービスを作り、必要なGoogle Cloud API、IAM権限、再試行時の挙動を試せる環境が整った。
この発表だけから、Swiftがほかのサーバー言語より高速なのか、運用コストを抑えられるのかまでは判断できない。それでも、既存のSwift資産を生かしながら、Google Cloud APIとの接続部分を公式ライブラリへ任せられることが、採用を検討するうえで新しい選択肢になる。