2026.08.01 開発

Capacitorとは？Ionic製ネイティブランタイムの仕組みと8系要件・採用判断を解説

Capacitorは、HTMLとCSSとJavaScriptで作ったWebアプリを、iOSとAndroidのネイティブアプリとして配布するための実行環境です。公式ドキュメントはこれを「cross-platform native runtime」と表現しています。開発したIonicチームは2022年10月にOutSystemsへ合流し、2025年2月には商用製品の販売終了が告知されました。それでもランタイム本体は無償のオープンソースとして更新が続き、npmのlatestタグは2026年8月1日時点で8.5.0です。この記事では、Capacitorが何をどこまで肩代わりする道具なのかという構造の話から、8系が求める開発環境、そして受託案件で採用してよい条件と見送るべき場面までを実装者の目線で整理します。

まとめ：Capacitorの構造と2026年時点の採用判断

先に結論を書きます。Capacitorが担当するのは、Webの資産をネイティブの器に載せて端末機能へ橋渡しする層だけです。画面の描画はWebViewが引き受け、カメラや位置情報はプラグイン経由でOSのAPIを呼びます。UIコンポーネントを提供するIonicフレームワークとは層が違うため、ReactでもVueでも素のJavaScriptでも、既存のWeb資産のまま載せられます。

版の状況も押さえておきます。@capacitor/coreのlatestは8.5.0（2026年7月31日公開）、nextタグは9.0.0-alpha.6（同年7月14日公開）。8.0.0の登場は2025年12月8日でした。8系は開発環境の要求水準を一段引き上げており、Node 22以上、Xcode 26.0以上、Android SDK 36（compileSdkとtargetSdk）、Android minSdk 24が前提になります。CI環境のイメージが古いままだと、コードに触れる前にビルドが止まります。

採用可否の線引きは単純です。既存のWeb資産があり、画面がフォーム・一覧・カメラ・地図といった業務系の範囲に収まり、配信がストア更新で足りるなら有力な選択肢。逆に高フレームレートの描画やネイティブUIの質感が要件なら選びません。もう1つ、2027年12月31日に終了するAppflowを運用設計の前提に置かないこと。この3点を守れば、Capacitorは費用対効果の読みやすい構成になります。

Capacitorとは何か：Webアプリを端末で動かすネイティブランタイムの構造

CapacitorがWeb Nativeランタイムと呼ばれる理由と担当範囲

Capacitorのアプリは、ネイティブのシェル（iOSならUIViewController、AndroidならActivity）の中にWebViewを1枚置き、そこへビルド済みのWeb資産を読み込む形で動きます。画面はWebの技術で描かれ、端末の機能はJavaScriptからブリッジを経由してネイティブコードへ渡されます。公式が対応プラットフォームとして挙げるのはiOS、Android、そしてWeb（PWA）です。

ここで分かるのは、Capacitorが「アプリの見た目」をほとんど提供しないという点です。ボタンの形もスクロールの挙動も、Web側で組んだ実装どおりの表示・動作です。ネイティブらしい操作感が欲しければUIライブラリを別に選ぶか、自前で作り込む必要があります。この構造の得失を発注側の視点で整理した記事として、クロスプラットフォームアプリ開発のメリット・デメリットと主要フレームワークの選び方も併せて読むと、選定の全体像がつかみやすくなります。

ネイティブプロジェクトをリポジトリに置く運用とCordovaとの違い

CapacitorとCordovaの最も実務的な差は、生成されたiosディレクトリとandroidディレクトリの扱いにあります。Cordovaでは、これらはビルドのたびに作り直される中間生成物という位置づけでした。設定はconfig.xmlに集約し、ネイティブ側へ手を入れるにはフックを書くのが定石です。

Capacitorは逆の立場を取ります。ネイティブプロジェクトをソース管理下に置き、Xcodeでも Android Studioでも直接編集してよい。プッシュ通知の証明書設定も、ネイティブSDKの追加も、各プラットフォームの流儀のまま書けます。設定ファイルもXMLではなくcapacitor.configで、TypeScriptから型付きで書けます。

反面、iOSとAndroidの設定を人が保守する範囲は増えます。Cordovaのように1つの設定ファイルだけ見ればよい世界ではありません。ネイティブの知識がゼロのチームだと、証明書の期限切れやSDKバージョンの更新で止まります。

Ionicフレームワークとの役割分担とCapacitor単体で使う判断

混同されやすい2つですが、担当する層が違います。Ionicフレームワークはボタン・リスト・モーダルといったUIコンポーネント群で、iOSとAndroidそれぞれの見た目に寄せた部品を提供します。Capacitorはその下でアプリを端末上のプロセスとして成立させ、ネイティブAPIへの通り道を用意する側。同じチームが作っていますが、依存関係は片方向です。

したがってCapacitorだけを単体で使えます。既存のReactアプリやNext.jsで作った静的書き出しをそのまま載せる構成は珍しくありません。判断基準は明快で、モバイルらしいUIの質感を短時間で揃えたいならIonicを併用し、すでに自社のデザインシステムやUIライブラリがあるならCapacitorだけを入れる。既存資産を捨ててIonicへ寄せる理由は、通常ありません。

公式プラグインとネイティブAPI呼び出しで押さえる実装の作法と工数

公式プラグイン36種が覆う守備範囲と選定時に確認すべき更新状況

ネイティブ機能はプラグインとして提供されます。公式ドキュメントに掲載されている公式プラグインは36種。カメラ、位置情報、ファイルシステム、プッシュ通知、ローカル通知、設定値の保存（Preferences）、共有、クリップボード、連絡先、カレンダー、バーコードスキャナ、Google Maps、バックグラウンド実行（Background Runner）、端末内で言語モデルを動かすLocal LLMまで並びます。

プラグインには3つの出所があります。Capacitorチームが保守する公式、コミュニティが保守するもの、そして互換層で動くCordovaプラグイン。選定時に見るべきは名前ではなく更新状況です。目安として、最終リリースが1年以上前で、かつ8系の要件（Android SDK 36）に追随していないものは、ビルドが通らない可能性を先に疑ってください。

独自プラグインをSwiftとKotlinで書く場合の分岐と工数の目安

公式にもコミュニティにもない機能は、自分でプラグインを書きます。実装言語はiOSがSwift、AndroidがJavaまたはKotlin（Javaとの違いとK2コンパイラの現在地）、Web向けのフォールバックがJavaScript。3つの実装に共通のインターフェースを定義し、JavaScript側からは同じ関数として呼び出す構造になります。

工数の見立ては、機能の性質で大きく割れます。値を1つ返すだけの薄いラッパなら、両OSとWebのフォールバック、型定義まで含めて1〜2人日。これが権限要求を伴うもの、アプリのライフサイクルをまたぐもの、バックグラウンドで動き続けるものになると数倍に膨らみます。特にAndroid側のバックグラウンド制約とiOS側の権限ダイアログは、OSの版ごとに挙動が変わるため検証の手数がかかります。

Cordovaプラグインを併用する場合に確認したい互換性と保守の制約

Capacitorは既存のCordovaプラグインを取り込めます。移行案件では実際に助かる仕組みです。ただし無条件ではありません。

  • config.xmlを前提にした設定やフックは動作しない（Capacitorはこの仕組みを持たない）
  • ネイティブプロジェクトを書き換えるタイプのプラグインは、手動での取り込みが必要になる場合がある
  • Cordova本体の開発は縮小しており、プラグイン側の更新が止まっているものが多い

実務上の判断としては、Cordovaプラグインは移行期の橋渡しと割り切ります。恒久的に依存するなら、同等の公式プラグインへ置き換えるか、自前のプラグインとして書き直す前提で見積もっておくほうが安全です。

Capacitor 8系の動作要件と移行で詰まりやすい変更点の整理

Node 22・Xcode 26・Android SDK 36という土台の要件

8系への移行で最初に当たる壁は、コードではなく環境です。公式の移行ガイドが示す要件は、Node.js 22以上、Xcode 26.0以上、iOSのデプロイメントターゲット15.0、Android側はminSdk 24でcompileSdkとtargetSdkがともに36、Android Studioは Otter（2025.2.1）以上、Android Gradle Pluginが8.13.0でGradle wrapperが8.14.3。

この要件はローカルの開発機だけでなく、CIのランナーイメージにも同じだけ効きます。Xcode 26系が載ったmacOSイメージを使えるか、Node 22のイメージへ切り替えられるかを先に確認してください。iOS側の検証端末をどの版に合わせるかは、iOS 26.6の変更点と業務端末での適用判断で整理した観点がそのまま使えます。

SPM既定化でCocoaPods構成から移るときの判断と手戻り

8系ではCLIが新規作成するiOSプロジェクトがSwift Package Manager構成になりました。CocoaPodsを既定とする時代が終わったという合図です。

既存プロジェクトが即座に壊れるわけではありません。判断すべきは、依存しているプラグイン群がSPMに対応しているかどうか。1つでも未対応が残るなら、移行を急いで手戻りを作るより、CocoaPods構成のまま8系へ上げて様子を見る選択が現実的です。逆に新規案件なら、既定のSPM構成で始めて構いません。

Android側のレイアウト名変更とSystem Barsプラグインへの寄せ方

Android側では、bridge_layout_main.xmlが削除され、capacitor_bridge_layout_main.xmlへ名前が変わりました。レイアウトを差し替えて画面を組んでいたアプリは、参照名の修正が必要になります。

設定面ではandroid.adjustMarginsForEdgeToEdgeが削除され、端末の上下バーとの余白調整はSystem Barsプラグインへ寄せる方針に変わりました。iOS側は、viewDidAppearとviewWillTransitionの通知をフレームワークが自動で発行するようになったため、同じ処理を独自の拡張で入れていたコードは削除します。放置すると通知が二重に飛びます。ユーザーエージェントへ文字列を追加するappendUserAgent設定でも空白の扱いが修正されているため、UAで分岐しているサーバー側の処理があれば、そこも合わせて確認してください。

Appflow終了が決まった前提でCapacitorを採用してよい条件

Capacitor本体とIonic商用製品を切り分けて読む視点

2025年2月11日、Ionicは商用製品の販売終了を発表しました。対象はクラウドビルドとライブ更新のAppflow、Identity Vault、Auth Connect、Secure Storage、Portals。同日付で新規販売が停止し、既存のAppflow利用者のアクセスは2027年12月31日までとされています。

一方で同じ発表は、Ionic FrameworkとCapacitorについて「無償のオープンソースのまま維持する」と明言しています。理由も添えられており、これらがOutSystemsのモバイル基盤の一部を構成しているためです。npmのリリース状況もそれを裏づけます。8.5.0が2026年7月31日、その前の8.4.2が7月14日と、月次に近い間隔で更新が続いています。

読み違えてはいけないのは、この2つを一緒くたにすることです。止まるのは有償サービスであって、ランタイム本体ではありません。

新規案件でCapacitorを採用してよい条件と見送るべき場面

ここは言い切ります。次の3条件がそろうなら、Capacitorは有力です。

  • 再利用できるWebアプリまたはSPAの資産が既にある（またはWeb版とアプリ版を同時に出す予定がある）
  • 画面の要件がフォーム・一覧・詳細・カメラ撮影・地図表示といった業務系の範囲に収まる
  • チームにWebフロントエンドの開発者がいて、ネイティブ専任を新たに採る予定がない

逆に、次のいずれかに当たるなら採用しません。カジュアルゲームのような常時描画が必要なもの、カメラ映像のリアルタイム加工、BLEやバックグラウンド位置情報が主機能のもの、そしてOS標準UIの質感が要件として明記されている案件です。WebViewを1枚挟む構造上、描画とネイティブ機能の往復にコストがかかるためで、後から工夫で埋まる差ではありません。この領域はFlutterとReact Nativeの違いと2026年の判断基準で整理した2択か、素直なネイティブ実装のほうが総額で安く収まります。

ライブアップデート運用を移行計画なしに前提化してはいけない理由

Web資産を差し替えるだけで修正を配れる。この性質は魅力的ですが、運用設計の土台に置くのは避けてください。理由は2つあります。

1つは提供元の事情です。Appflowのライブ更新は2027年12月31日で止まります。それまでに自前の配信基盤を作るか、サードパーティのサービスへ移すかを決めなければならず、その移行工数は当初の見積もりに入っていないことがほとんどです。もう1つはストア側の規約で、アプリの主要機能や目的を変えるような更新を審査を通さず配ることは認められていません。実務で使えるのは、文言修正や軽微な不具合対応までの範囲です。「即日で直せるから初期品質は後追いでよい」という前提で計画を組むと、両方の制約に同時にぶつかります。

受託開発でCapacitorを選ぶときの見積もりと保守体制の判断基準

既存Web資産の再利用率によって見積もりが変わる分岐点と落とし穴

見積もりを分けるのは機能数ではなく、既存Web資産をどれだけそのまま載せられるかです。レスポンシブ対応済みのSPAがあり、タッチ操作を前提に画面が組まれているなら、モバイル化の主作業はネイティブ側の初期構築とプラグイン組み込みに絞れます。一方、PC向け固定幅の画面やjQuery世代の実装が残っている場合、実態はモバイル向けの作り直しに近づきます。

見落としやすいのは、この再利用率と無関係に固定で発生する作業です。証明書と署名の準備、プッシュ通知の設定、アイコンとスプラッシュの生成、ストア掲載情報の作成、審査対応。Web側の完成度がどれだけ高くても、ここは減りません。初回リリースの見積もりでは、この固定費を別建てで積んでおくと後の交渉が楽になります。

ストア審査とネイティブ側の保守を内製と外注で分ける判断の基準

リリース後に効いてくるのは、年1回のOS更新への追随です。iOSとAndroidはそれぞれ年次で新版を出し、ストアが要求するSDKの水準も上がります。実際、8系がXcode 26.0以上とAndroid SDK 36を求めるようになったのがその一例。Web側の機能追加は自社で回せても、この追随作業だけはネイティブの知識と検証端末が必要になります。

分担の基準として使えるのは「頻度」です。週次で変わる画面やビジネスロジックは内製に置き、年数回しか触らないネイティブ層とストア対応は外部に持たせる。この切り方なら、社内にネイティブ専任を抱えなくても継続して運用が回る体制です。当社でもFlutter・React Nativeによるクロスプラットフォームアプリ開発として、Web資産を持つ企業のアプリ化と、リリース後のOS追随を含む保守までを受託しています。既存のWeb実装を見たうえで、Capacitorで足りるのか別の構成が要るのかの切り分けから相談できます。

よくある質問

Capacitorの検討時に実務でよく挙がる質問を5つ整理しました。

CapacitorとCordovaはどちらを選ぶべきですか？

新規で始めるならCapacitorです。Cordova本体は開発が縮小しており、プラグインの更新も止まっているものが目立ちます。CapacitorはCordovaプラグインの互換性を持つため、既存のCordovaアプリからの移行先としても現実的な候補になります。ただし移行時にconfig.xmlの設定とフックは引き継げないため、そこは書き直す前提で工数を見てください。

Ionicフレームワークを使わずにCapacitorだけ導入できますか？

できます。CapacitorはWeb資産をネイティブアプリとして動かす層だけを担当するため、React、Vue、Angular、素のJavaScriptのいずれでも構いません。Ionicが提供するのはUIコンポーネント群で、依存は片方向です。自社のデザインシステムが既にあるなら、Capacitorだけを入れて既存の画面をそのまま載せる構成が素直な選択になります。

Capacitor 8へ上げるとき既存のCocoaPods構成は使えますか？

使えます。8系でCLIが新規作成するiOSプロジェクトはSwift Package Manager構成が既定になりましたが、既存のCocoaPods構成が動かなくなるわけではありません。判断材料は依存プラグインのSPM対応状況で、未対応のものが残っているうちは無理に移らず、まず8系の環境要件（Node 22以上・Xcode 26.0以上）を満たすことを優先してください。

Appflowの終了でCapacitorのアプリは動かなくなりますか？

本体は影響を受けません。終了するのはIonicの有償サービスであるAppflowのビルド機能とライブ更新機能で、期限は2027年12月31日。Capacitor本体は無償のオープンソースとして継続する方針が公式に示されており、実際に2026年7月31日の8.5.0まで更新が続いています。影響が出るのは、Appflowのクラウドビルドやライブ更新に依存した運用をしている場合だけです。

CapacitorとFlutterはどちらが受託開発に向きますか？

要件で分かれます。Web版とアプリ版を同じコードで出したい、既存のWeb資産を再利用したい、開発メンバーがWebフロントエンド中心という条件ならCapacitor。滑らかな画面遷移やアニメーション、ネイティブに近い描画性能が要件ならFlutterです。判断の目安として、画面がフォームと一覧が中心ならCapacitor、独自の表現やリアルタイム描画を含むならFlutterと考えると外しにくくなります。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る