さくらインターネットが提供する「さくらのクラウド」が、ガバメントクラウドの対象クラウドサービスとして正式に採択されました。

デジタル庁は2026年3月27日、さくらのクラウドについて、すべての技術要件を満たしたことを確認し、同日以降、本番環境の提供が可能になったと公表しています。 また、さくらインターネットも、305項目すべての技術要件への適合が確認され、令和5年度および令和8年度のガバメントクラウドサービス提供事業者として採択されたことを発表しています。

これは、国産クラウドの選択肢が公共領域でも現実的に広がったという意味で、大きなニュースです。

一方で、ITエンジニアやSIerの現場では、次のような現実的な不安も出ています。

クラウドサービスが正式採択されたことと、そのクラウドを安全に導入・運用できることは、同じではありません。

これから重要になるのは、さくらのクラウドを理解し、要件に合わせて設計・構築・運用できるパートナーの存在です。

国産クラウドの選択肢が、いよいよ現実的になってきた

これまでガバメントクラウドというと、AWS、Google Cloud、Microsoft Azure、Oracle Cloud Infrastructureなど、外資系クラウドを中心に議論されることが多くありました。

その中で、さくらのクラウドがガバメントクラウドの対象クラウドサービスとして正式採択されたことは、国産クラウドの選択肢が公共領域でも現実的に広がったという意味で、大きな転換点です。

特に、行政・自治体・公共性の高いシステムでは、データの保管場所、運用主体、国内法との整合性、サポート体制などが重要になります。

そのため、国内事業者が提供するクラウドを選択肢に入れられることは、多くの企業・自治体にとって大きな意味があります。

一方で、クラウドサービスが正式採択されたからといって、すぐに現場で問題なく使えるわけではありません。

実際の導入では、要件整理、構成設計、ネットワーク設計、セキュリティ設計、監視・バックアップ設計、運用体制づくりまで含めて検討する必要があります。

なぜ今、「さくらのクラウドを扱えるパートナー」が注目されているのか

さくらのクラウドがガバメントクラウドの対象クラウドサービスとして正式採択されたことで、国産クラウド活用への期待は大きく高まりました。

一方で、現場では次のような流れで、実務面の課題が見え始めています。

つまり、今後は「さくらのクラウドが使えるかどうか」ではなく、 「さくらのクラウドを使って、安全にシステムを構築・運用できる体制を作れるか」が問われる段階に入っています。

現場で問われている3つの課題

1. 運用管理補助者・MSP（マネージドサービスプロバイダー）不足への不安

ガバメントクラウドを自治体が利用する場合、クラウド環境やクラウドサービスの運用管理を補助する「ガバメントクラウド運用管理補助者」の役割が重要になります。

これは一般的にいうと、クラウドの設計・設定・運用を支援する MSP（マネージドサービスプロバイダー） に近い役割です。

MSPとは、クラウドやサーバ、ネットワークなどのIT基盤について、構築後の監視・運用・保守・障害対応などを継続的に支援する事業者を指します。

ただし、ガバメントクラウドにおける「運用管理補助者」は、一般的なMSPと完全に同じ意味ではありません。 地方公共団体のクラウド利用を支える立場として、責任分界や運用範囲を明確にしたうえで関わる必要があります。

現場で不安視されているのは、AWSやAzureに対応できる事業者は多くても、さくらのクラウドの仕様や設計思想を理解し、公共領域の要件に合わせて構築・運用できる事業者がまだ限られているのではないか、という点です。

このような状況を避けるためには、早い段階でさくらのクラウドに対応できる導入・運用パートナーへ相談し、構成案・費用感・運用体制を整理しておくことが重要です。

2. 305項目の技術要件を、誰が現場で運用するのか

さくらのクラウドは、デジタル庁により305項目すべての技術要件への適合が確認され、ガバメントクラウドの対象クラウドサービスとして正式採択されました。

これは非常に大きな実績です。 一方で、クラウドサービス提供事業者が技術要件を満たしたことと、利用者側のシステムが安全に設計・運用されることは、同じではありません。

実際の現場では、以下のような設計・運用判断が必要になります。

• どのサービスをどの構成で使うべきか
• 外部公開領域と内部管理領域をどう分離するか
• 権限管理やアクセス制御をどう設計するか
• ログ・監視・バックアップをどこまで実装するか
• 障害発生時の一次対応を誰が行うか
• 月次報告や監査対応に必要な情報をどう残すか

つまり、305項目の技術要件を満たしたクラウドを使うには、その上で構築するシステム側にも、相応の設計力・運用力が求められます。

3. AWS・Azure人材とのスキルセットの壁

もう一つの論点は、エンジニアのスキルセットです。

現在のクラウド人材市場では、AWS、Azure、Google Cloudなどの経験を持つエンジニアは比較的見つけやすい一方で、さくらのクラウドを実務レベルで扱えるエンジニアやSIerは、まだ限られていると考えられます。

そのため、さくらのクラウドを選択肢に入れる場合は、単に「クラウド経験者がいるか」ではなく、以下の観点で確認することが重要です。

• さくらのクラウドのサービス体系を理解しているか
• サーバ、スイッチ、ルータ、VPN、DB、ストレージの構成を設計できるか
• さくらのクラウド特有の料金体系や制約を踏まえて見積もれるか
• 監視・バックアップ・ログ・障害対応まで運用設計できるか
• AWSやAzureとの違いを説明し、適切に比較できるか

クラウドの選定では、製品そのものの機能だけでなく、導入を支える人材・パートナーの有無が成否を左右します。

さくらのクラウド導入でつまずきやすいポイント

1. AWSやAzureと同じ感覚で設計してしまう

クラウドの基本的な考え方は共通していますが、サービス体系やネットワーク構成、料金体系、監視方法、運用の考え方はクラウドごとに異なります。

AWSやAzureの知識があることは大きな強みですが、そのままさくらのクラウドに置き換えればよいとは限りません。 さくらのクラウドのサービス特性を理解したうえで、構成を組み立てる必要があります。

2. ネットワークとセキュリティの設計が後回しになる

さくらのクラウドでは、サーバ、スイッチ、ルータ＋スイッチ、VPNルータ、ロードバランサ、オブジェクトストレージ、AppRun、DBアプライアンスなど、さまざまなサービスを組み合わせて構成を検討します。

特に重要なのは、外部公開する領域と内部管理する領域をどう分けるかです。 インターネット公開、VPN接続、閉域接続、管理用ネットワーク、WAF、監視、ログ取得などを、要件に合わせて整理する必要があります。

3. 構築だけで終わり、運用設計が不足する

クラウド導入でよくある失敗は、構築まではできたものの、運用体制が整っていないケースです。

たとえば、以下のような点が曖昧なままだと、運用開始後に問題が起きやすくなります。

• 障害発生時に誰が一次確認するのか
• リソース使用率をどの頻度で確認するのか
• ログをどこまで確認するのか
• バックアップ取得状況をどう確認するのか
• 証明書や契約更新を誰が管理するのか
• 月次報告として何を提出するのか

安心して運用するためには、構築段階から保守・運用・報告までを見据えておくことが重要です。

弊社は、さくらのクラウドのパートナーとして導入を支援しています

弊社は、さくらのクラウドのパートナーとして、クラウド導入・構成検討・運用支援に取り組んでいます。

さくらのクラウドの導入では、単にサーバを作成するだけではなく、要件に応じてネットワーク、セキュリティ、監視、バックアップ、運用体制まで含めて設計する必要があります。

弊社では、さくらのクラウドを活用したシステム基盤について、導入前の相談から構成検討、見積、運用設計まで支援しています。

弊社の強みは、単にクラウドリソースを用意するだけではありません。

「どの構成なら安全に運用できるか」
「どこまでをマネージドサービスに任せるべきか」
「どこから運用設計が必要になるか」
「月次報告や保守体制として何を整えるべきか」

こうした現場目線の論点まで含めて、さくらのクラウド活用を支援できる点が弊社の特徴です。

このようなご相談に対応できます

さくらのクラウド導入では、早い段階でパートナーに相談することが重要

さくらのクラウドは、今後さらに注目されるクラウドになると考えられます。

一方で、クラウド導入は「どのサービスを使うか」だけで成功するものではありません。 要件に合わせた構成を設計し、セキュリティ・運用・コストまで含めて検討する必要があります。

特に、公共・自治体・準公共領域のシステムでは、要件整理の段階からクラウド構成を意識しておくことが重要です。 あとからネットワークや運用を追加しようとすると、構成変更や見積もりのやり直しが発生しやすくなります。

そのため、さくらのクラウドの活用を検討している場合は、できるだけ早い段階で導入・運用パートナーに相談することをおすすめします。

まとめ：さくらのクラウド活用は「導入できるパートナー選び」が重要になる

さくらのクラウドがガバメントクラウドの対象クラウドサービスとして正式採択されたことにより、国産クラウド活用の可能性は大きく広がりました。

一方で、これからの現場では、次の問いがより重要になります。

弊社は、さくらのクラウドのパートナーとして、導入前の相談から、構成設計、見積もり、運用設計まで支援しています。

さくらのクラウドの活用を検討されている方は、ぜひお気軽にご相談ください。

参考情報

• デジタル庁：ガバメントクラウド
• さくらインターネット：令和5年度および令和8年度 ガバメントクラウドサービス提供事業者に採択
• さくらインターネット：さくらのパートナーネットワーク

※本記事は、公開情報をもとに、さくらのクラウド導入・運用における実務上の論点を整理したものです。 ガバメントクラウドに関する個別要件や対応可否については、案件ごとに確認が必要です。

さくらインターネットの AppRun Dedicated（専有型）は、自由度が高い反面、Terraform で apply が通っても activeNodeCount=0（Podが1つも立ち上がらない） という事象によく陥ります。

実案件で特定した「ドキュメントには載っていない仕様」と、復旧のための黄金フローを記録します。

---

1. 起動失敗の 9 割を占める「SEG」の疎通不足

AppRun 専有型のワーカーノードは、デフォルトで外部ネットワークから隔離されています。

• 罠の正体: ワーカーが起動しても、自身の管理用 コントロールプレーン や、イメージを Pull するための コンテナレジストリ に到達できず、Pod の作成（イメージプル）に失敗します。
• 解決策: プライベートスイッチ側で SEG (Service Entrance Gateway) を有効化し、以下のエンドポイントを接続先として明示的に許可してください。
  • *.sakuracr.jp（コンテナレジストリ）
  • AppRun 専有型コントロールプレーン
  • （必要なら）オブジェクトストレージ

2. Terraform のスペック指定（500 Internal Server Error）

HCL で cpu や memory を定義する際、**「物理的に存在しない組み合わせ」**を指定すると、プロバイダー経由の API 叩き上げ時に 500 エラーで即死します。

• NG例: cpu = 4, memory = 8 （4vCPU/8GB は存在しない）
• OK例: cpu = 4, memory = 4 または cpu = 1, memory = 2
• 復旧のコツ: 起動しない原因がリソース不足か設定ミスかを切り分けるため、まずは 1vCPU / 2GB の最小構成で activeNodeCount=1 を目指すのが鉄則です。

3. IP Pool の衝突：runner との「1bit」の争い

ネットワーク設計時、ユーザー用の IP Pool が AppRun のシステムコンポーネント（runner や LB）と重複すると、ASG の作成や割当に失敗します。

• 罠の正体: frontend の IP pool を .20 開始にすると、内部の管理用 IP と衝突するケースがあります。
• 解決策: Pool 開始アドレスを .21 以降にずらして設計します。Terraform# 成功パターンの IP Pool 定義例 network_interface { ip_address_pool { start = "10.20.0.21" # .20を避けて開始 end = "10.20.0.29" } }

4. eth0=shared 時の Default Gateway 制限

• 症状: ASG 作成時に 400 (defaultGateway must not be set) エラー。
• 原因: フロントエンド ASG で eth0=shared を使用している場合、他のプライベート NIC に gateway を設定することは仕様上禁止されています。
• 対策: プライベート側の NIC 定義から gateway 設定を削除してください。

5. 【最重要】「更新」不可。再作成こそが唯一の反映

Terraform で ip_address_pool や NIC 設定を書き換えて apply しても、実環境に反映されないことがあります。

• 理由: 既存の ASG/LB が存在する場合、内部の構築スクリプトが「作成済み」と判定して処理をスキップするためです。
• 鉄則: 設定変更時は terraform destroy → terraform apply による全削除・再作成が、現状最も確実な反映手段です。

---

2026-02-03 最終復旧ログ：正常起動へのチェックリスト

もし /healthz が 503 を返し続けているなら、以下の順に確認してください。

1. SEG の有効化: レジストリとコントロールプレーンへの経路があるか？（IP は 10.20.0.5/24 等でセグメント内に存在するか）
2. リソースの最小化: 1vCPU / 2GB でスケジューリングに成功するか？
3. DNS 更新: LB 再作成で Public IP が変わっていないか？（salessight.east-cloud.jp の A レコードを新 IP に向け直したか）
4. 証明書の反映: LB 再作成直後は証明書が一時的に self-signed になるケースがあるため、数分待機してブラウザから確認。

---

「Apply は成功するが、中身は死んでいる」 という AppRun Dedicated 特有の挙動を理解すれば、デバッグ時間は劇的に短縮されます。

---

AppRun Dedicated 構築トラブルに関するよくある質問（FAQ）

Q: activeNodeCount が 0 のまま、一向に 1 になりません。何を確認すべきですか？

A: まずは SEG（Service Entrance Gateway）の設定を確認してください。 専有型ワーカーは、デフォルトで外部ネットワークから遮断されています。SEG で「コンテナレジストリ（*.sakuracr.jp）」および「AppRun専有型コントロールプレーン」への接続許可設定が漏れていると、イメージのプルができず、ノードが活性化しません。

Q: Terraform でスペック変更（CPU/メモリ）を apply したのに反映されません。

A: AppRun Dedicated の仕様上、既存リソースの「更新」が効かない項目があります。 特に ASG（Auto Scaling Group）や LB の内部設定は、リソースが存在すると構築スクリプトが処理をスキップする設計になっています。設定変更を確実に反映させるには、一度 terraform destroy でリソースを削除してから再作成（apply）を行ってください。

Q: ASG 作成時に「500 Internal Server Error」が発生します。原因は何ですか？

A: 指定したワーカークラス（CPU/メモリの組み合わせ）が実在しない可能性があります。 例えば 4vCPU / 8GB といった組み合わせは提供されていないため、API 側でエラーとなります。4vCPU / 4GB や 2vCPU / 2GB など、さくらインターネットが公式に提供しているスペック表に準じた値を指定してください。

Q: ロードバランサー（LB）を再作成したらサイトにアクセスできなくなりました。

A: LB の Public IP アドレスが変更されている可能性があります。 LB を再作成すると、新しい Public IP が割り当てられます。お使いの DNS サービス（さくら外の DNS や A レコード等）にて、salessight.east-cloud.jp などのドメイン向け先を新しい IP アドレスへ手動で更新する必要があります。

Q: IP Pool の設定で注意すべき「衝突」とは何ですか？

A: AppRun の管理用コンポーネント（runner）との重複です。 同一セグメント内で .20 付近のアドレスはシステム側で使用されるケースが多いです。ユーザー用の IP Pool 開始アドレスを .21 以降に設定することで、アドレスの奪い合いによる起動失敗を回避できます。

---

この記事の内容が、AppRun Dedicated の構築で夜通しデバッグしているエンジニアの助けになれば幸いです。

GitHub ActionsとSelf-hosted RunnerでVPC内DBにmigrateを実行する方法

AppRun構成でCI/CDを成立させる実践設計

---

📚 さくらのクラウドで作るモダンアーキテクチャ（全5回）

• 第1回：さくらのクラウドで作るモダンアーキテクチャ入門
• 第2回：さくらのクラウドVPC設計完全解説
• 第3回：GitHub Actions × Self-hosted Runner（イマココ）
• 第4回：AppRun専有型と共用型の違い
• 第5回：Terraformで再現するさくらのモダンアーキテクチャ

---

はじめに

AppRunを使ったモダン構成で、ほぼ確実にぶつかる問題があります。

それが

VPC内部にあるデータベースに、CI/CDからどうやってmigrateを流すか

という問題です。

通常のCI/CDでは、

• GitHub Actions
• GitLab CI
• CircleCI

などのクラウドCIが使われます。

しかしこれらは インターネット上の環境で実行されるため、VPC内部には直接アクセスできません。

今回の構成では、

• データベースはVPC内
• DBはグローバル公開しない
• AppRun専有型を利用

という設計なので、

CIからDBに直接アクセスすることができません。

---

なぜ普通のCIではダメなのか

構成を整理します。

GitHub Actions
     ↓
Internet
     ↓
AppRun
     ↓
VPC Router
     ↓
Database

ここで問題になるのは

GitHub ActionsはVPCの外にいる

という点です。

つまり、

• DBを公開しない限り
• CIはDBに接続できない

という状態になります。

しかしDBを公開するのは、セキュリティ的に好ましくありません。

---

解決策：Self-hosted Runner

この問題を解決するのが

Self-hosted Runner

です。

これは簡単に言うと、

GitHub Actionsの実行環境を自分のサーバーに置く仕組み

です。

つまり、

• RunnerをVPC内に配置
• GitHub ActionsのジョブをRunnerで実行

することで、

CIからVPC内部のリソースにアクセスできるようになります。

---

Runner配置の構成

今回のシリーズでは以下の構成を採用します。

GitHub Actions
      ↓
Self-hosted Runner
      ↓
VPC Router
      ↓
Database

RunnerをVPC内部に配置することで、

• DBアクセス
• migrate実行
• 内部API接続

が可能になります。

---

Runnerを配置するセグメント

第2回で紹介したネットワーク構成を思い出してください。

VPC
 ├─ public-app-seg
 ├─ private-db-seg
 └─ runner-seg

Self-hosted Runnerは

runner-seg

に配置します。

理由は以下です。

• AppRunと役割が異なる
• DBアクセスを制御しやすい
• CI用リソースを分離できる

CI用のサーバーは、必ず専用セグメントに分離するのが安全です。

---

Runnerのもう一つの問題：インターネットに出られない

RunnerをVPC内部に配置すると、もう一つ問題が発生します。

それは

Runnerがインターネットに出られない

という問題です。

RunnerはCI実行時に以下の通信を行います。

• GitHub Actions API
• pip install
• npm install
• Docker image pull
• 外部APIアクセス

そのため 外向き通信が必須になります。

---

NAT VMの役割

ここで必要になるのが

NAT VM

です。

NAT VMは、

VPC内部のサーバーがインターネットへ出るための出口

として機能します。

構成は以下のようになります。

Runner
   ↓
VPC Router
   ↓
NAT VM
   ↓
Internet

RunnerはNAT VMを経由してインターネットへ接続します。

---

AWSとの違い

AWSでは

• NAT Gateway

を利用します。

一方、さくらのクラウドでは

NATはVMで構築する

のが一般的です。

ただしメリットもあります。

• コストが安い
• 構成の自由度が高い
• 通信制御が細かくできる

---

NAT VMを含めた全体構成

最終的なネットワーク構成は以下になります。

Internet
   ↓
Cloudflare
   ↓
AppRun[VPC]
   ├─ public-seg
   │    └─ NAT VM
   │
   ├─ runner-seg
   │    └─ Self-hosted Runner
   │
   └─ private-db-seg
        └─ Database

通信フロー：

Runner → NAT VM → Internet → GitHub
Runner → VPC Router → Database

この構成により

• CI/CD
• VPC内部通信
• DB保護

を両立できます。

---

Runnerセットアップ

RunnerはGitHubからスクリプトを取得して起動します。

mkdir actions-runner
cd actions-runnercurl -o actions-runner.tar.gz -L https://github.com/actions/runner/releases/latest/download/actions-runner-linux-x64.tar.gztar xzf actions-runner.tar.gz./config.sh --url https://github.com/your-repo --token TOKEN
./run.sh

これでRunnerがGitHubと接続されます。

---

GitHub Actions設定例

Djangoのmigrate実行例です。

name: migrateon:
  push:
    branches:
      - mainjobs:
  migrate:
    runs-on: self-hosted    steps:
      - uses: actions/checkout@v4      - name: Install dependencies
        run: |
          pip install -r requirements.txt      - name: Run migrate
        run: |
          python manage.py migrate

重要なのはここです。

runs-on: self-hosted

これによりジョブは

VPC内部のRunner

で実行されます。

---

Runner運用で気をつけること

Runnerは公開しない

RunnerはCI実行環境です。

外部公開すると攻撃対象になります。

必ずVPC内部に配置します。

---

Runnerは専用セグメントに置く

CI環境は分離します。

理由：

• セキュリティ
• 負荷分離
• トラブル影響範囲

---

Runnerは使い捨ても可能

高度な構成では

• Runner自動生成
• Job終了後削除

という設計もあります。

今回はシンプル構成を採用します。

---

まとめ

AppRun構成でCI/CDを成立させるには

Self-hosted Runner + NAT VM

が必要になります。

理由はシンプルです。

• DBはVPC内部
• CIはインターネット
• Runnerは内部
• Runnerは外に出る必要がある

だから

RunnerをVPC内に置き
NAT VMでインターネットに出る

この構成が最もシンプルで安全です。

---

次回予告

次回は

AppRun専有型と共用型の違い

を解説します。

ここを理解していないと、

• VPC接続できない
• スイッチ接続できない
• ネットワーク設計が破綻する

という事故が起きます。

AppRun設計の核心です。

---

よくある質問（FAQ）

Q1. GitHub ActionsからVPC内のデータベースに接続できますか？

通常のGitHub Actionsはインターネット上で実行されるため、VPC内部のデータベースには直接接続できません。
そのため、VPC内にSelf-hosted Runnerを配置し、そのRunner上でCIジョブを実行する構成が必要になります。

---

Q2. Self-hosted Runnerとは何ですか？

Self-hosted Runnerとは、GitHub Actionsのジョブを自分のサーバーで実行できる仕組みです。
通常はGitHubのクラウド環境でジョブが実行されますが、RunnerをVPC内に配置することで内部リソースへ安全にアクセスできます。

---

Q3. Self-hosted Runnerはどこに配置するべきですか？

Self-hosted Runnerは専用のセグメント（例：runner-seg）に配置するのが推奨です。
AppRunやデータベースと役割が異なるため、ネットワークを分離することでセキュリティと運用性が向上します。

---

Q4. Runnerはインターネットに接続する必要がありますか？

はい。Runnerは以下の通信を行うため、外向き通信が必要です。

• GitHub Actions API
• パッケージダウンロード（pip / npm）
• Dockerイメージ取得
• 外部APIアクセス

そのためVPC内のRunnerはNAT VMなどを経由してインターネットへ接続する必要があります。

---

Q5. NAT VMとは何ですか？

NAT VMとは、VPC内部のサーバーがインターネットへアクセスするための出口となるサーバーです。
RunnerはNAT VMを経由することで、GitHubやパッケージリポジトリへアクセスできます。

---

Q6. AWSの場合はどう構成しますか？

AWSでは通常、

• NAT Gateway
• ECS / EC2 Runner
• GitHub Actions

の組み合わせで同様の構成を作ります。
さくらのクラウドではNAT Gatewayの代わりにNAT VMを構築するケースが多いです。

---

Q7. データベースをグローバル公開してCIから接続するのはダメですか？

可能ではありますが推奨されません。
DBを公開すると攻撃対象が増えるため、VPC内部に閉じたままSelf-hosted Runner経由で操作する方が安全です。

---

📚 さくらのクラウドで作るモダンアーキテクチャ（全5回）

• 第1回：さくらのクラウドで作るモダンアーキテクチャ入門
• 第2回：さくらのクラウドVPC設計（イマココ）
• 第3回：GitHub ActionsとSelf-hosted RunnerでVPC内DBにmigrateを実行する方法
• 第4回：AppRun専有型と共用型の違いを徹底解説
• 第5回：Terraformで再現するさくらのモダンアーキテクチャ

---

はじめに

モダンアーキテクチャの成否は、ネットワーク設計で8割決まります。

特に、さくらのクラウドはAWSとは設計思想が異なります。

• AWS：L3（VPC）中心の抽象化された設計
• さくら：L2（スイッチ）を自分で組む前提の設計

この違いを理解しないままAppRunやDBを配置すると、

• VPC連携がうまくいかない
• 専有型が起動しない
• 稼働コンテナ数が0になる
• 意図せずDBが公開される

といった事故が起きます。

今回は、

• L2（スイッチ）
• L3（VPCルータ）
• SEG（サービスエンドポイント）

この3つを軸に、正しいVPC設計を整理します。

---

1. L2（スイッチ）とは何か？

L2スイッチは、同一セグメント内の通信を担うレイヤーです。

特徴：

• 同一IPレンジ内で直接通信
• ブロードキャストドメインを形成
• ルーティングはしない

さくらのクラウドでは、セグメントを自分で作るのが前提です。

AWSのように「VPCを作れば終わり」ではありません。
まずは どの役割をどのセグメントに分けるか を決めることから始まります。

---

2. L3（VPCルータ）の役割

VPCルータは、異なるセグメント間を接続するL3層です。

主な機能：

• ルーティング
• NAT
• パケットフィルタ
• VPN接続

AWSで例えると：

• NAT Gateway
• Internet Gateway
• Route Table

をまとめた存在です。

原則はシンプル。

L2で分ける
L3で繋ぐ

---

3. SEG（サービスエンドポイント）を忘れるな

ここが最重要ポイントです。

SEGとは？

SEG（Service Endpoint Gateway）は、

VPC内からさくらのマネージドサービスへ
インターネットを経由せずに接続する仕組み

です。

対象例：

• コンテナレジストリ
• AppRun Dedicatedコントロールプレーン
• オブジェクトストレージ

---

なぜSEGが重要なのか？

AppRun専有型では、

• ワーカーノードがVPC内に存在
• 外部に直接出られない構成も多い

そのためSEGを設定しないと、

• Dockerイメージがpullできない
• デプロイが失敗する
• activeNodeCount=0 のまま止まる

という状態になります。

「ネットワークは正しいのに動かない」場合、
まずSEGを疑うべきです。

---

4. 推奨セグメント構成

今回のシリーズで採用する基本構成は以下です。

Internet
   ↓
Cloudflare
   ↓
AppRun（Frontend）

[VPC内]
  ├─ public-app-seg
  ├─ private-db-seg
  ├─ runner-seg
  └─ SEG（サービス接続）

設計原則：

• DBはprivate-db-segのみ
• DBにグローバルIPを持たせない
• RunnerのみDBアクセス許可
• AppRun専有型はSEG経由でサービス接続

---

5. Terraformでのネットワーク表現例

ここまでの設計は、Terraformでは次のように表現できます。

L2（セグメント）

resource "sakuracloud_switch" "public_app" {
  name = "public-app-seg"
}

resource "sakuracloud_switch" "private_db" {
  name = "private-db-seg"
}

resource "sakuracloud_switch" "runner" {
  name = "runner-seg"
}

L3（VPCルータ）

resource "sakuracloud_vpc_router" "vpc" {
  name = "vpc-router"
  plan = "standard"

  interface {
    switch_id = sakuracloud_switch.public_app.id
    ipaddress = ["192.168.10.1"]
    netmask   = 24
  }

  interface {
    switch_id = sakuracloud_switch.private_db.id
    ipaddress = ["192.168.20.1"]
    netmask   = 24
  }

  interface {
    switch_id = sakuracloud_switch.runner.id
    ipaddress = ["192.168.30.1"]
    netmask   = 24
  }
}

ここで重要なのは、

Terraform上でも
「L2で分け、L3で束ねる」という思想がそのまま表現される

という点です。

---

SEG（概念例）

resource "sakuracloud_service_endpoint" "seg" {
  name      = "seg-main"
  switch_id = sakuracloud_switch.public_app.id

  services = [
    "container-registry",
    "object-storage",
    "apprun-dedicated-control-plane",
  ]
}

※実際の属性はproviderバージョンにより変更される可能性があります。

---

6. AWSとの違い

観点	AWS	さくら
セグメント	自動生成	手動L2作成
サービス接続	VPC Endpoint	SEG
NAT	専用	VPCルータ内蔵
思想	抽象化	明示的設計

さくらは「分かりやすい」代わりに、
自分で理解して組む責任がある。

しかし一度理解すれば、
構造は極めてシンプルです。

---

設計原則まとめ

• L2で役割ごとに分離する
• L3で境界を制御する
• SEGでマネージドサービスへ閉域接続する
• DBは絶対にグローバル公開しない
• AppRun専有型はSEG前提で設計する

---

よくある質問（FAQ）

Q. SEGは必須ですか？

AppRun専有型で閉域構成を組むなら必須です。

---

Q. SEGとNATの違いは？

NATはインターネット経由。
SEGは閉域接続。

---

Q. L2とL3の違いが曖昧です。

L2は同一セグメント内通信。
L3は異なるセグメント間のルーティングです。

---

まとめ

さくらのクラウドでモダンアーキテクチャを組むなら、

L2・L3・SEG

この3点を理解することが最重要。

ここを押さえれば、
AppRun × VPC構成で迷うことはありません。

---

次回は、

GitHub Actions × Self-hosted Runnerで
VPC内DBにmigrateを実行する方法

を解説します。

閉域ネットワークとCI/CDをどう両立させるか。
ここが実運用の核心です。