AppRun入門 共用型・専有型の違いとプライベート環境の構築手順

AppRunとは何か

さくらインターネットが2025年12月9日に正式リリースしたAppRunは、コンテナイメージを渡すだけでアプリを公開できるマネージドサービスだ。裏側ではKubernetesとKnativeが動いている。Knativeは元々Google CloudがCloud Runの基盤として開発し、2021年にCloud Native Computing Foundation（CNCF）へ寄贈されたオープンソースだ。

ただし利用者がKubernetesやKnativeを直接触る場面はない。具体的には、コンテナイメージとポート番号を指定するだけで、ロードバランシング、オートスケール、TLS終端までAppRunが処理してくれる。つまり、インフラ構築や運用にかける時間を削り、アプリ開発に集中できるわけだ。

この記事では以下の内容を扱う。

• 共用型と専有型の料金・機能比較
• 専有型でSEGを使ったプライベート環境の構築手順
• apprun-cliによるCI/CDパイプラインへの組み込み方法
• AWS App RunnerやCloud Runとの違い

それでは、AppRunが用意している2つのプランから見ていこう。

この記事の前提条件

手順を進めるにあたり、以下の準備が必要になる。

• さくらのクラウドのアカウントを持っていること。コントロールパネルの基本操作に不安がある場合は先にそちらを確認してほしい
• Docker がローカル環境にインストールされていること
• コンテナの基本的な概念（イメージ、レジストリ、ポートマッピング）を理解していること
• 専有型を試す場合はサービスプリンシパルの作成権限が必要。IDポリシーの設定方法についてはこちらの記事で詳しく解説している

共用型と専有型を比較する

AppRunには共用型と専有型がある。それぞれの違いを以下の表にまとめた。

共用型はコストを抑えたい場面に向く

共用型の最大の強みはKnativeベースのゼロスケールだ。アクセスがない時間帯にインスタンスが0になり、その間は課金されない。そのため、個人開発やトラフィックの読めない初期サービスに適している。

料金体系は1時間単位の従量課金で、最小構成なら約5円/時間だ。月額に直すと約3,720円からスタートできるため、検証用途でも手を出しやすい価格帯といえる。

とはいえ、ゼロスケールにはデメリットもある。インスタンスが0の状態からリクエストを受けると、コンテナの起動が完了するまで数秒から十数秒の待ち時間（コールドスタート）が発生する。レスポンス速度が求められるサービスでは、最小インスタンス数を1以上に設定しておくほうが安全だ。

もう1つ注意したいのが、共用型ではプライベートネットワーク接続ができない点だ。クラウド上のデータベースやストレージへの通信はすべてインターネット経由になる。DB接続を含む構成では、次に紹介する専有型を選ぶ必要がある。

専有型はネットワーク分離が必要な環境向け

一方で、専有型ではユーザー専用のVMが割り当てられる。他のユーザーとリソースを共有しないため、パフォーマンスが安定しやすい点が特徴だ。

最小構成は1vCPU/2GBメモリで月額約11,000円、最大8vCPU/8GBメモリまでスケールアップできる。しかし専有型を選ぶ最大の理由は、スペックよりもプライベートネットワーク接続だろう。さくらのクラウドのスイッチにサービスエンドポイントゲートウェイ（SEG）を介して接続することで、クラウド上のデータベースやストレージへインターネットを経由せずプライベートIPで直接通信できる。

したがって、エンタープライズシステムや自治体業務のように外部へトラフィックを流したくないケースでは、この仕組みが不可欠になる。国産クラウドとしてのセキュリティ基盤についてはさくらのクラウドのSOC2 Type1取得に関する記事でも解説しているので、あわせて確認してほしい。

専有型でプライベート環境を構築する5ステップ

ここからは専有型AppRunで、プライベートなコンテナ実行環境を組み立てる流れを解説する。共用型にはない設定が複数あるため、順を追って進めよう。全体像としては、ネットワーク準備 → 認証設定 → クラスター起動 → イメージ準備 → 動作確認という流れになる。

なお、構築中に詰まりやすいポイントについてはAppRun専有型で起動しない場合の対処法にもまとめているので、トラブル時にはそちらも参照してほしい。

ステップ1 — スイッチを作成しSEGを有効化する

まず、さくらのクラウドコントロールパネルでスイッチを作成する。次に、そのスイッチの詳細画面にあるサービスエンドポイントゲートウェイタブからSEGを有効化する。

SEGはプライベートネットワーク内のリソースから、さくらのクラウドのマネージドサービスへ安全に接続するための仕組みだ。ここでIPアドレスとネットマスクを設定し、コンテナレジストリとAppRun専有型コントロールプレーンへの通信を許可しておく必要がある。

この設定を忘れると、ワーカーノードがコンテナイメージを取得できなくなる。見落としやすいポイントなので、他の設定より先に済ませておきたい。

ステップ2 — サービスプリンシパルを作成する

クラスターの起動には適切な権限が必要だ。そこで、さくらのクラウドのIAM機能でサービスプリンシパルを作成し、「さくらのクラウド 作成・削除」の権限を付与する。

サービスプリンシパルとは、リソースを自動管理するための認証情報のことだ。具体的には、AppRun専有型がワーカーノードの増減やネットワーク設定を行うときにこの認証情報が使われる。なお、IAMの権限管理に不慣れな場合は、先にIDポリシーの設定方法を確認しておくことをすすめる。

ステップ3 — クラスターとワーカーノードを起動する

AppRun専有型の管理画面からクラスターを作成する。続いてオートスケーリンググループを追加し、ワーカーノードを起動する。

このとき重要なのはNIC設定だ。ステップ1で作成したSEG有効化済みスイッチを選び、ネームサーバにはSEGのIPアドレスを指定する。この接続設定により、ワーカーノードがプライベートネットワーク経由でコンテナレジストリや管理サーバーと通信できるようになる。

CPUとメモリはアプリの負荷に合わせて選べばよい。初回の検証であれば最小構成で十分だ。

ステップ4 — コンテナイメージを用意してデプロイする

現時点でAppRunはさくらのクラウドのコンテナレジストリ専用となっている。そのため、Docker Hubなど外部レジストリから直接pullしてデプロイすることはできない。外部レジストリへの対応はロードマップに入っているものの、具体的な時期は未定とされている。

外部のベースイメージを使いたい場合は、ローカルでpullしてからさくらのコンテナレジストリに再pushする方法を取る。以下にNode.jsアプリの例を示す。

FROM node:20-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
EXPOSE 8080
CMD ["node", "server.js"]

また、AppRunはx86_64アーキテクチャで動作する点にも注意が必要だ。Apple Silicon搭載のMacでビルドする場合は --platform linux/amd64 を明示的に付けなければならない。

# ビルドしてさくらのコンテナレジストリにpush
docker build --platform linux/amd64 -t my-app.sakuracr.jp/my-app:latest .
docker login my-app.sakuracr.jp
docker push my-app.sakuracr.jp/my-app:latest

イメージのpushが完了したら、ロードバランサをステップ1のスイッチに接続し、アプリケーションを追加する。コンテナポート8080を外部ポート80にマッピングし、ホスト名を指定すれば準備完了だ。

ステップ5 — 接続確認と動作検証

デプロイ後は、プライベートセグメント経由でDBや他のリソースに到達できるか確認する。接続先のプライベートIPは環境変数で渡すと管理しやすい。

外部DNSサービスでAレコードを登録すれば、指定したホスト名で外部からアクセスできるようになる。

確認時に起動しない、通信できないといったトラブルが起きた場合は、まずSEGの設定とNIC設定を見直そう。よくある原因と対処法はこちらの記事にまとめている。

運用で押さえておきたいポイント

構築が完了したら、運用フェーズで気をつけるべきことを整理しておこう。

コンテナイメージの更新フロー

アプリを更新するたびにコンテナレジストリへの再pushが必要になる。手動運用ではミスが起きやすいため、後述するapprun-cliを使ったCI/CDパイプラインの構築を早い段階で検討したい。

オートスケールの挙動

専有型でもCPU使用率をベースにしたオートスケールが利用できる。トラフィック増加時には新しいインスタンスが自動的に立ち上がり、負荷を分散してくれる。ただし共用型と異なり、インスタンスを0にするゼロスケールは専有型では動作しない。常に最低1台のインスタンスが稼働し続ける点を理解しておこう。

監視とログ

AppRunのコンソールからコンテナのログを確認できる。本番運用では外部の監視ツールと組み合わせ、レスポンスタイムやエラー率を継続的に観測する体制を整えておくと安心だ。

apprun-cliでデプロイを自動化する

コントロールパネルでの手動操作に加え、CLIツールのapprun-cliも利用できる。CI/CDパイプラインに組み込む場合はこちらのほうが扱いやすい。

apprun-cliはfujiwaraさんが開発した非公式ツールで、Homebrewまたはgo installでインストールできる。

# Homebrewでインストール
brew install fujiwara/tap/apprun-cli

# または go install
go install github.com/fujiwara/apprun-cli/cmd/apprun-cli@latest

このツールはアプリケーション定義をJSONまたはJsonnet形式のファイルで管理する仕組みだ。既存のアプリケーション設定をエクスポートするには、以下のコマンドを実行する。

# 既存アプリケーション設定をJsonnetファイルに出力
apprun-cli init --name my_web_app --jsonnet > myapp.jsonnet

設定ファイルを編集したら、deployコマンドで反映する。

# 設定ファイルを指定してデプロイ
apprun-cli deploy --app myapp.jsonnet

Jsonnet形式を選ぶメリットは、テンプレート機能を活用できる点だ。例えば、must_env() 関数で環境変数を読み込めるため、シークレット情報をファイルに直接書かずに済む。さらに tfstate() でTerraformの状態を参照したり、secret_value() でSecret Managerにアクセスしたりも可能だ。

GitHub ActionsやGitLab CIのステップに組み込めば、pushのたびにAppRunへ自動デプロイする仕組みが構築できる。なお、アプリケーションが見つからない場合、deployコマンドは新規作成として処理される。つまり、初回も更新も同じコマンドで済む点が運用を楽にしてくれる。

GitHub Actionsでの設定例

参考として、GitHub Actionsでapprun-cliを使う場合の基本的なワークフロー構成を示す。

name: Deploy to AppRun
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build and push image
        run: |
          docker build --platform linux/amd64 -t my-app.sakuracr.jp/my-app:${{ github.sha }} .
          echo "${{ secrets.SAKURA_CR_PASSWORD }}" | docker login my-app.sakuracr.jp -u ${{ secrets.SAKURA_CR_USER }} --password-stdin
          docker push my-app.sakuracr.jp/my-app:${{ github.sha }}

      - name: Install apprun-cli
        run: |
          go install github.com/fujiwara/apprun-cli/cmd/apprun-cli@latest

      - name: Deploy
        env:
          SAKURA_APPRUN_TOKEN: ${{ secrets.SAKURA_APPRUN_TOKEN }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          apprun-cli deploy --app myapp.jsonnet

この例ではmainブランチへのpushをトリガーに、イメージのビルド・push・デプロイを自動実行している。must_env() を使えば、Jsonnet内で IMAGE_TAG などの環境変数を安全に参照できる。

AWS App RunnerやCloud Runとの違い

名前の似たサービスが海外クラウドにもある。主要な違いを表にまとめた。

ゼロスケール対応ではAppRun共用型とCloud Runが並ぶ。一方で、AWS App Runnerは最低1インスタンスが常駐するため、待機中もコストが発生し続ける。

AppRunを選ぶ理由は大きく3つある。国内データセンターで動作すること、円建てで請求が届くこと、そしてさくらのクラウドの既存リソースとプライベート接続できることだ。

データの国内保管が求められる案件や、ガバメントクラウドを見据えた自治体向けシステムでは、この3点が決定打になる。すでにさくらのクラウドを運用している環境なら、追加のネットワーク設計も最小限で済む。

ただし、グローバル展開やマルチリージョン構成が必要な場合はAWSやGoogle Cloudのほうが選択肢は多い。結局のところ、用途に応じた使い分けが現実的だ。

よくある質問

Q1. 共用型と専有型、最初はどちらを選ぶべきか

迷ったら共用型から始めるのがよい。ゼロスケールにより待機コストがかからないため、検証や小規模サービスに適している。その後、プライベートネットワーク接続やリソースの分離が必要になった時点で、専有型へ切り替えれば問題ない。

Q2. 手元のDockerイメージをそのまま使えるか

直接は使えない。現時点ではさくらのコンテナレジストリのみに対応しているため、手元やDocker Hubのイメージは一度さくらのコンテナレジストリにpushし直す必要がある。加えて、x86_64（linux/amd64）でビルドされている必要があるので、Apple Silicon搭載のMacで作ったイメージはそのままでは動かない。ビルド時に --platform linux/amd64 を付けよう。

Q3. 独自ドメインで公開できるか

専有型ではホスト名を指定し、外部DNSサービスでAレコードを登録すれば独自ドメインで公開できる。一方で、共用型にはAppRun単体での独自ドメイン機能がない。ただし、さくらのウェブアクセラレータを前段に置くことで対応は可能だ。その際、リクエスト先をHostヘッダで判別するため、ウェブアクセラレータ側のHostヘッダ設定に注意が必要になる。

Q4. ゼロスケールからの起動にどのくらいかかるか

コンテナイメージのサイズや起動処理によって変わるが、目安は数秒から十数秒だ。コールドスタートを避けたいなら最小インスタンス数を1以上に設定すればよい。ただし、その分は常時課金されるので、コストとのトレードオフになる。アクセス頻度やレスポンス要件に応じて判断してほしい。

Q5. 専有型でもオートスケールは効くか

効く。CPU使用率をベースにコンテナインスタンスを自動で増減する仕組みが備わっている。トラフィック増加時には新しいインスタンスが自動的に立ち上がり、負荷を分散してくれる。ただし、インスタンスを0にするゼロスケールは専有型では使えない点に注意してほしい。

Q6. SEGの設定を忘れるとどうなるか

ワーカーノードがAppRun管理サーバーやコンテナレジストリと通信できなくなる。結果として、コンテナイメージの取得もクラスタの正常運用もできない。専有型を使うなら、SEGの有効化はスキップできない手順だ。

まとめ

AppRunはコンテナデプロイの手間を削り、インフラ管理から開発者を解放するサービスだ。共用型のゼロスケールは待機コストをゼロに抑え、専有型のプライベートネットワーク接続はセキュリティ要件の厳しい環境に応える。

専有型の構築ではSEGの設定が鍵になる。この記事で紹介した5ステップを押さえておけば、プライベートなコンテナ実行環境を迷わず立ち上げられるはずだ。加えて、apprun-cliを導入すればCI/CDパイプラインによる自動デプロイも実現できる。

さくらのクラウドの他の機能と組み合わせることで、よりセキュアで運用しやすいインフラを構築できる。関連記事もあわせて確認してほしい。

• さくらのクラウド IaaS画面の見方
• さくらのクラウド IDポリシー完全ガイド
• AppRun専有型で起動しない場合の対処法

参考リンク

• さくらのクラウド AppRun 公式ドキュメント
• AppRun 正式提供開始プレスリリース
• AppRun専有型でプライベート環境にコンテナを起動する（さくらのナレッジ）
• apprun-cli GitHub リポジトリ
• Knative 公式サイト
• さくらのクラウド コンテナレジストリ