Alamofireとは？Swiftでの使い方・async/await対応とURLSessionとの使い分け【5.12系】

Alamofireは、AppleのURLSessionの上に載るSwift製のHTTP通信ライブラリです。この記事では、2026年10月時点の最新である5.12系を前提に、Swift Package ManagerとCocoaPodsでの導入、async/awaitでのGET・POST、RetryPolicyによる再試行、認証トークンの更新、証明書ピンニングまでを動くコードで示します。5.12.1で最低OSがiOS 15へ上がった変更点と、URLSessionだけで書く方が筋のよい場面の線引きも、判断基準として整理します。

まとめ：Alamofire 5.12系を入れる条件とURLSessionで足りる場面の線引き

AlamofireはURLSessionを置き換えるものではなく、URLSessionに再試行・認証ヘッダの付与・レスポンス検証・証明書ピンニングの「部品」を足すライブラリです。iOS 15以降ならURLSession自体がasync/awaitに対応しているため、APIを数本呼ぶだけのアプリでは依存を増やす理由は薄くなりました。

入れる価値があるのは、トークン更新の待ち合わせ、冪等なリクエストの自動再試行、マルチパートアップロードの進捗、証明書ピンニングのうち2つ以上を自前で書くことになる案件です。導入はSwift Package Managerで5.12系を指定し、最低OSはiOS 15と見なして設計します。

Alamofireの構造：URLSession上のSwift製HTTP通信

Alamofireは、URLSessionの上に載るSwift製HTTP通信ライブラリです。その位置づけと構造を理解するには、「通信そのものは誰が行っているか」から処理の担当範囲を分けて考えると迷いません。

Alamofireが担う範囲とURLSessionに任せたままの通信処理の切り分け

AlamofireのGitHubリポジトリは、自身をFoundationのURLローディングシステムの上に作られたインターフェースと説明しています。実際の接続・TLS・HTTP/2やHTTP/3の処理はURLSessionが行い、AlamofireはSession型がその委譲を受けて、リクエストの組み立てからレスポンスの解釈までを担います。

Alamofireが足すのは、パラメータのエンコード、validate()によるステータス検証、Codableへのデコード、RequestInterceptorによる加工と再試行、ServerTrustManagerによる証明書評価です。通信の速さや安定性がURLSessionより上がるわけではありません。ここを誤解して「通信が速くなるから入れる」と判断すると、効果のない依存が残ります。

5.12系の最新版と最低OS要件がSPMとCocoaPodsで食い違う現状

2026年10月4日時点の最新は5.12.2（2026年9月10日公開）で、中身は版番号の更新だけです。実質の変更は直前の5.12.1のリリースノートにあり、Package.swiftをSwift 6.4向けに更新して、最低OSをiOS 15・macOS 12・tvOS 15・watchOS 9へ引き上げました。

Package.swiftとAlamofire.podspecの記載が揃っていないのが実情です。新規案件ではiOS 15を最低線として扱い、iOS 14以前の端末を切れない案件は5.11系で止めるか、通信層を別の方式で書くかを先に決めておきます。

Alamofire導入：Swift Package ManagerとCocoaPods

ここではSwift Package ManagerとCocoaPodsを導入経路として取り上げ、Alamofireの依存を追加する手順と既存案件での移行判断を示します。2026年に新しく始めるならSwift Package Manager一択です。

Package.swiftとXcodeでAlamofire 5.12系を指定する手順

アプリのプロジェクトなら、Xcodeの「File」メニューから「Add Package Dependencies…」を開き、リポジトリURLを入れて「Up to Next Major Version」で5.12.0以上を選びます。ライブラリやサーバーサイドのパッケージでは、Package.swiftに次のように書きます。

// swift-tools-version: 6.4
import PackageDescription

let package = Package(
    name: "MyAPIClient",
    platforms: [.iOS(.v15), .macOS(.v12)],
    dependencies: [
        .package(url: "https://github.com/Alamofire/Alamofire.git", from: "5.12.0")
    ],
    targets: [
        .target(
            name: "MyAPIClient",
            dependencies: [.product(name: "Alamofire", package: "Alamofire")]
        )
    ]
)

platformsをAlamofire側より低くすると解決時にエラーになります。プロダクトは通常Alamofireを選び、動的リンクを強制するAlamofireDynamicは理由がある場合だけに留めます。

CocoaPods trunkの読み取り専用化予定と既存Podfile案件の移行判断

既存案件でpod 'Alamofire'を書いている場合も、CocoaPodsのtrunkには5.12.2まで登録されています。ただしCocoaPods公式ブログの読み取り専用化計画では、2026年11月1日〜7日に試験運用を行い、12月2日にtrunkが新しいPodspecを受け付けなくなる予定です（日程は確定ではないと注記あり）。

既存のビルドが壊れるわけではありません。止まるのは、以降のバージョン更新の受け取りです。Alamofire以外のPodも同じ条件になるため、Podfileの依存がすべてSPMに対応しているなら、次の改修のついでにSPMへ寄せる判断が妥当です。

Alamofireの実装：async/awaitでGET・POSTするコード

ここからは、REST APIを呼ぶクライアントを最小構成で書いてみます。async/awaitでGET・POSTを実行し、JSONをCodableの型で受け取るコードを使って、Alamofireの使い方を確かめます。

serializingDecodableとvalidateによるGETの型付き受信

async/awaitでは、serializingDecodableが返すタスクからvalueを待つ書き方が基本です。公式のUsage.mdによると、validate()はステータスが200..<300の範囲にあることと、Acceptに指定した型とContent-Typeの一致を確認します。

import Alamofire
import Foundation

struct User: Decodable, Sendable {
    let id: Int
    let name: String
}

struct NewUser: Encodable, Sendable {
    let name: String
}

final class APIClient {
    // Sessionはプロパティで保持する（解放されると通信がsessionDeinitializedで失敗する）
    private let session = Session(interceptor: RetryPolicy())
    private let baseURL = "https://api.example.com"

    func fetchUser(id: Int) async throws -> User {
        try await session.request("\(baseURL)/users/\(id)",
                                  headers: [.accept("application/json")])
            .validate()
            .serializingDecodable(User.self)
            .value
    }

    func createUser(name: String) async -> Result<User, AFError> {
        let response = await session.request("\(baseURL)/users",
                                             method: .post,
                                             parameters: NewUser(name: name),
                                             encoder: JSONParameterEncoder.default)
            .validate(statusCode: [201])
            .serializingDecodable(User.self)
            .response
        // 失敗時のステータスはresponse.response?.statusCodeで取れる
        return response.result
    }
}

valueは失敗時にAFErrorを投げます。画面側でステータスに応じた表示を分けたいときは、createUserのようにresponseを受け取り、HTTPURLResponseと結果を両方見ます。

JSONParameterEncoderによるPOST送信と201以外の失敗判定

上のPOSTは、Encodableな構造体をJSONParameterEncoder.defaultでJSONボディに変換し、Content-Type: application/jsonを付けて送ります。辞書を組み立てる必要はありません。

作成APIが201を返す仕様なら、validate(statusCode: [201])で他のステータスを失敗として扱うと、200で中身が空という想定外の応答を見逃しません。範囲での一括検証より、APIの仕様書に書かれた値をそのまま指定する方が、テスト時の不具合を早く見つけられます。

cURLDescriptionで送信内容を確かめるデバッグと5.11系の遅延開始

AlamofireのRequestは、送信した内容を同じ意味のcURLコマンドとして出力できます。.cURLDescription { print($0) }をつなげると、ヘッダとボディを含むコマンドがログに出るので、サーバー担当者に再現手順として渡せます。認証ヘッダもそのまま出力されるため、本番ビルドでは#if DEBUGで囲んでください。

5.11.0（2025年12月）では、Requestの準備処理がresume()まで実行されない遅延方式が既定になりました。生成直後にrequest.requestを読む古いコードは値が空になり得ます。以前の挙動が必要ならSession(requestSetup: .eager)で戻せます。

認証・再試行の設定：RequestInterceptorとRetryPolicy

Alamofireを選ぶ理由の大半は、この章で扱う認証とリトライの機能にあります。RequestInterceptorによる処理とRetryPolicyの既定値を押さえ、認証トークンの更新や再試行の条件を設定します。

RetryPolicyの既定は2回まで・0.5秒起点の指数バックオフでPOSTは対象外

RetryPolicy.swiftのソースを読むと、既定値は再試行2回、待ち時間は「2の再試行回数乗×0.5秒」で、0.5秒・1秒の順に待ちます。対象のステータスは408・500・502・503・504、対象のメソッドはDELETE・GET・HEAD・OPTIONS・PUT・TRACEです。

// 再試行を3回に増やし、429（レート制限）も対象に加える
let policy = RetryPolicy(
    retryLimit: 3,
    retryableHTTPStatusCodes: RetryPolicy.defaultRetryableHTTPStatusCodes.union([429])
)
let session = Session(interceptor: policy)

POSTが外れているのは、冪等性の考え方とAPIでの担保方法のとおり、同じ注文を二重に作る事故を防ぐためです。POSTも再試行したい場合は、サーバー側で冪等キーを受け付ける設計を先に入れます。ジッターは既定に入っていないので、多数の端末が同時に再試行する負荷が気になるなら、指数バックオフとジッターの実装判断を参考にRequestRetrierを自作します。

AuthenticationInterceptorでトークン更新を待ち合わせる実装

アクセストークンの期限切れ対応で厄介なのは、複数の通信が同時に401を受けたとき、更新処理を1回だけ走らせて残りを待たせる制御です。AdvancedUsage.mdが示すAuthenticationInterceptorは、この待ち合わせとスレッド制御を引き受けます。

実装するのはAuthenticatorプロトコルの4メソッドです。applyでヘッダを付け、refreshでリフレッシュトークンを使って更新し、didRequestで401などを認証失敗と判定し、isRequestで送信時のトークンが現行のものかを比べます。公式例は期限の5分前をrequiresRefreshの条件にしています。トークンの寿命そのものは、API認証の方式選定とトークン寿命の決め方でサーバー側と合わせて決めてください。

ServerTrustManagerで証明書ピンニングを入れる際の全ホスト評価の落とし穴

金融や医療のアプリで中間者攻撃への対策を求められたときは、ServerTrustManagerにホストごとの評価方法を登録します。PinnedCertificatesTrustEvaluatorはアプリに同梱した証明書と、PublicKeysTrustEvaluatorはその公開鍵とサーバー側を照合します。

詰まりやすいのは初期値です。allHostsMustBeEvaluatedは既定でtrueのため、同じSessionから登録していないホスト（画像CDNなど）へ送った通信が失敗します。証明書の更新時期に同梱の証明書を差し替え忘れると全通信が止まるので、更新時に鍵を使い回す運用をサーバー側と取り決めたうえで、公開鍵を固定する方式を基本にします。

URLSessionとAlamofire：iOS 15以降で依存を足す判断基準

最後に、Alamofireを入れるかどうかを決める基準を言い切ります。

URLSessionのasync APIの範囲とAlamofireが必要な条件比較

iOS 15以降では、URLSessionのdata(for:delegate:)が1回のawaitでデータとレスポンスを返します。単純な取得とデコードなら、Alamofireとの差は数行です。

判断の線は「自前で書く部品が2つを超えるか」です。再試行・トークン更新・ピンニングのうち2つ以上が要件にあるなら、Alamofireを入れた方が保守の総量は小さくなります。

Alamofireを入れない方がよい場面と既存案件で外す・残すの判断

APIが数本で認証も固定キーだけのアプリには入れません。依存が1つ増えるたびに、Xcodeの更新や最低OSの引き上げに追随する作業が発生します。5.12.1のように、ライブラリ側の都合で最低OSが変わることもあります。

既存案件は逆の判断です。Alamofire 5系で動いている通信層を、URLSessionへ書き換えるためだけに改修するのは見送ります。外すのは、iOS 14以前を切れずに5.11系で止める必要が出たときや、通信層を作り直す改修が別の理由で決まったときに限ります。古いAlamofire 4系以前が残る場合は、Swiftの版上げと合わせた改修が避けられません。言語や技術の前提から見直すならSwift・Kotlin・Dartの言語選定の分岐条件、外注で通信層ごと任せるならiOSアプリ開発で要件整理から相談できます。

Alamofireの導入・非同期通信とURLSession比較のよくある質問

Alamofireを使い始めるときに検索されやすい疑問へ、短く答えます。インストール時の動作環境、async/awaitへの対応、URLSessionとの違いを確認するための質問をまとめています。

AlamofireとURLSessionの違いは何ですか？

URLSessionはAppleが提供する通信の本体で、Alamofireはその上に再試行・認証・検証・証明書ピンニングなどの部品を足したラッパーです。通信そのものはどちらを使ってもURLSessionが行います。iOS 15以降ならURLSessionだけでasync/awaitの通信が書けるため、差が出るのは再試行やトークン更新を自前で書くかどうかの部分です。

Alamofireはasync/awaitに対応していますか？

対応しています。serializingDecodableやserializingDataが返すタスクのvalueをawaitで待つのが基本の書き方です。5.10.0（2024年10月）でSendableを含むSwift Concurrencyへの完全対応が入りました。async letで複数のリクエストを並行に投げることもできます。

Alamofireの最新バージョンと動作環境を教えてください

2026年10月4日時点の最新は5.12.2です。Swift Package Managerで導入する場合、5.12.1以降はiOS 15・macOS 12・tvOS 15・watchOS 9以上と、Swift 6.4に対応したツールチェーンが前提になります。podspecには旧来のiOS 10.0表記が残っていますが、新規案件ではiOS 15を最低線と考えて設計してください。

AlamofireのPOSTが失敗しても自動で再試行されないのはなぜですか？

既定のRetryPolicyは、POSTを再試行の対象に含めていません。サーバーに届いて処理された後に応答だけが失われた場合、再送で注文や登録が二重になるためです。POSTも再試行したいなら、サーバー側で冪等キーを受け付けたうえで、retryableHTTPMethodsに.postを加えます。

CocoaPodsからSwift Package Managerへ移行すべきですか？

次の改修のタイミングで移行を勧めます。CocoaPodsのtrunkは2026年12月2日に新しいPodspecの受け付けを止める計画で、以降はAlamofireを含む各ライブラリの更新を受け取れなくなります。既存のビルドはそのまま動くため、急いで切り替える必要はありません。全依存がSPMに対応しているかを先に確認します。

関連記事

• iOSアプリ開発とは？特徴・Swiftでの作り方・費用と外注判断を発注者視点で解説：iOSアプリを外注する前に押さえる全体像
• Combine（Swift）とは？Publisher・Subscriberの仕組みと2026年の採用判断を解説：AlamofireのCombine対応APIを使う前提知識
• SwiftDataとは？@Modelの仕組みとCore Dataとの違い・2026年の採用判断：APIから受け取ったデータの端末内保存
• REST API設計のベストプラクティス｜URI・冪等性・エラー応答のレビュー基準：クライアントから呼ぶAPI側の設計
• WindowsでiOSアプリを開発する方法｜Mac不要でビルドと提出を回す4経路：Macがない環境でのビルドと提出