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経由で操作する方が安全です。

何が起きたか

2026年1月30日、さくらインターネットはさくらのクラウドについて SOC2 Type1 報告書を新たに取得したと発表した。基準日は 2025年10月31日。

ここで押さえておきたいのは、今回の対象がデータセンターではなくクラウドサービスそのものだという点だ。つまり、物理インフラの管理だけでなく、ユーザーが直接触るサービスレイヤーのセキュリティ統制を第三者が評価したことになる。その結果、データセンターからサービスへと SOC 対応の範囲が一段広がった。

この動きは、近年のAIを活用した自律型セキュリティ診断の進化と合わせて見ると、クラウドサービスのセキュリティ体制が攻めと守りの両面から強化されていることがわかる。

SOC2 とは何か

まず前提を整理しておこう。SOC2（Service Organization Control 2）は、米国公認会計士協会（AICPA）が策定した、サービス提供組織の内部統制を評価する監査基準だ。評価の軸になるのが Trust Service Criteria（信頼サービス規準） と呼ばれる 5 つの領域になる。

規準	内容
セキュリティ	不正アクセスからの保護
可用性	サービスの安定稼働
処理の完全性	データ処理の正確性
機密性	機密情報の適切な管理
プライバシー	個人情報の保護

独立した監査人がこれらの規準に沿って統制の状況を評価する。

Type1 と Type2 の違い

	Type1	Type2
評価の対象	ある一時点での統制の設計	一定期間にわたる統制の運用
例え	設計図を見る	実際の運用を見る
期間	スナップショット	通常 6〜12 ヶ月
信頼度	設計の妥当性を確認	設計が継続的に機能していることを確認

言い換えれば、Type1 は「仕組みがきちんと設計されているか」のスナップショット評価。一方、Type2 は「その仕組みが実際に機能し続けているか」の継続評価だ。したがって、Type1 を取得してから Type2 に進むのが一般的な流れになる。

さくらインターネットの SOC 取得の歩み

では、今回の取得はどのような背景から生まれたのか。実は突然のものではない。さくらインターネットが長年積み重ねてきたセキュリティ対応の延長線上にある。

時期	取得内容
2017年5月	石狩データセンターで SOC2 Type1 を初取得
2020年10月	SOC2 Type2 および SOC3 報告書を取得
2025年7月	SOC2 / SOC3 報告書を更新
2026年1月	さくらのクラウドで SOC2 Type1 を新たに取得

このように、データセンターの物理セキュリティから始まり、Type2 への昇格を経て、今回はクラウドサービス単体での取得に至った。この段階的な拡大は、SOC 対応の成熟度を示している。

国産クラウドの SOC2 対応状況

それでは、さくらインターネットの取得を文脈づけるため、主要な国産クラウド事業者の SOC2 対応状況を整理してみよう。

事業者	SOC2 Type1	SOC2 Type2	特記事項
KDDI（KDDIクラウド）	取得済	8 年連続取得	通信キャリア系で最も長い実績
IIJ（IIJ GIO）	取得済	取得済	DC 含む包括的な SOC 対応
GMOクラウド	取得済	—	ConoHa 等一部サービスが対象
NTT Com（SDPF）	取得済	取得済	グローバル展開に伴う SOC 対応
さくらインターネット	DC + クラウド	DC のみ	今回クラウド単体の Type1 を新規取得

この中で特に目を引くのは、KDDI が Type2 を 8 年連続で維持している点だ。さくらインターネットはデータセンターでは Type2 まで到達しているものの、クラウドサービス単体では今回が Type1 の起点となる。そのため、次のステップは当然、クラウドサービスでの Type2 取得だろう。

SOC2 と他のセキュリティフレームワークの位置づけ

ただし、SOC2 はクラウドセキュリティを評価するフレームワークの一つにすぎない。他にもいくつかの基準がある。ここでは、日本で実務に関わる主要な基準を横並びで比較する。

観点	SOC2	ISMS（ISO 27001）	ISMAP	CSA STAR
策定元	AICPA（米国）	ISO/IEC（国際）	日本政府	CSA（国際）
評価方式	監査人によるレポート	認証機関による審査	政府の評価委員会	自己評価 or 第三者評価
主な用途	委託先管理・B2B 評価	情報セキュリティ全般	政府調達の前提条件	クラウド固有のリスク評価
公開範囲	NDA ベースで開示	認証取得の事実は公開	登録リストを公開	レジストリで公開
日本での浸透度	エンタープライズ中心	広く普及	官公庁必須	まだ限定的

この中で特に注目すべきは ISMAP（政府情報システムのためのセキュリティ評価制度） だ。2020年に導入され、約 1,200 の管理策で構成される。政府クラウドに採用されるためには ISMAP 登録が事実上の前提条件となっている。

さくらインターネットは 2023年11月にガバメントクラウドに条件付きで採択された。その後も要件達成を進め、2025年12月時点で 122 項目中 116 項目の技術要件を達成済みとされる。こうした背景を踏まえると、今回の SOC2 取得もガバメントクラウド対応の流れの一環と見ることができる。

実務面での影響 — なぜ気にすべきか

ここからは、今回の SOC2 取得がクラウド利用者にとって具体的にどう影響するかを見ていく。

1. クラウド選定時の客観的な判断材料が増える

クラウドサービスを導入する際、「セキュリティは大丈夫か」という問いに対して、ベンダーの自己申告ではなく独立した監査人による評価報告書を確認できるようになる。特に、エンタープライズ案件や ISMS 取得企業では委託先の統制評価を求められる場面が増えている。そうした場面で SOC2 報告書はそのまま判断材料として使える。

2. 国産クラウドの選択肢が広がる

データ主権やレイテンシの観点から国産クラウドを選びたいケースは少なくない。しかし、これまでは SOC2 未取得という点がネックになることがあった。今回の取得により、さくらのクラウドも SOC2 という国際的に認知された基準を満たし、AWS や GCP と同じ土俵で比較検討できるようになった。

3. コンプライアンス対応の工数を減らせる

自社で SOC2 や ISMS の認証を維持している企業にとって、利用するクラウドサービスが SOC2 報告書を持っていれば、委託先管理の監査工数を大幅に削減できる。逆に言えば、SOC2 報告書がないクラウドを使っている場合、自社で独自に統制評価を行う必要があり、その分のコストと時間がかかっている。

SOC2 報告書を確認する際の7つのチェックポイント

実際に SOC2 報告書を閲覧する機会を得たとき、どこを見ればよいのか。以下の 7 つのポイントを押さえておけば、報告書の内容を正しく評価できる。

1. 対象範囲（Scope）: どのサービスが対象か。「さくらのクラウド」全体か、特定コンポーネントか
2. 選択された Trust Service Criteria: 5 つのうちどれが評価対象か。セキュリティのみの場合もある
3. 監査意見（Opinion）: 無限定適正意見か、限定付き意見か、不適正意見か
4. 例外事項（Exceptions）: 統制の逸脱が発見されていないか
5. 補完的統制（Complementary User Entity Controls）: 利用者側で実装すべき統制が何か
6. サブサービス組織の取り扱い: データセンターなど外部委託先の統制をどう扱っているか
7. 基準日 / 評価期間: Type1 なら基準日、Type2 なら評価期間を確認

この中で特に見落としやすいのが「補完的統制」だ。SOC2 報告書は「サービス提供者側の統制」を評価したものであり、利用者側で対処すべきセキュリティ対策が別途記載されている。これを無視してしまうと、SOC2 を取得したサービスを使っているにもかかわらず、セキュリティインシデントが発生するという事態になりかねない。報告書を「取得済み」の事実だけで安心するのではなく、中身を読んで自社側の対応事項を把握することが不可欠だ。

報告書の閲覧方法

なお、SOC2 報告書は一般には公開されない。NDA 等の条件のもとで開示されるのが通常だ。そこで、主要クラウドプロバイダの報告書へのアクセス方法を整理しておく。

プロバイダ	アクセス方法
AWS	AWS Artifact（マネジメントコンソール内で NDA 同意後にダウンロード）
Google Cloud	Compliance Reports Manager（同意後にダウンロード）
Microsoft Azure	Service Trust Portal（NDA 同意後）
さくらのクラウド	営業担当またはカスタマーセンター（[email protected]）に問い合わせ

AWS・GCP・Azure がセルフサービスで報告書にアクセスできるのに対し、さくらのクラウドは問い合わせベースだ。そのため、クラウド選定の検討フェーズで報告書を確認したい場合は、早めに連絡しておくことをおすすめする。

今後の展望 — Type2 への道のりと注目ポイント

一般的に、SOC2 Type1 を取得した組織は 1〜2 年以内に Type2 への移行を目指す。さくらインターネットはデータセンターでは既に Type2 を取得しているため、クラウドサービスでの Type2 取得も時間の問題だろう。

加えて、さくらインターネットは近年、インフラ面でも大きな動きを見せている。

• GPU クラウド: 高火力シリーズで NVIDIA H100/H200 を提供、2025年に TOP500 で世界 49 位にランクイン
• データセンター投資: 石狩 DC の大規模拡張に 53 億円を投じ、2026年に新棟稼働予定
• ガバメントクラウド: 2023年11月に条件付き採択、技術要件の達成が進行中

このように、インフラの拡大とセキュリティ認証の強化が並行して進んでいる。クラウドサービスの信頼性は性能だけでは測れない。だからこそ、第三者評価の積み重ねが、選ぶ側にとっての判断材料になる。

よくある疑問

SOC2 を取得していれば安全なのか

SOC2 はあくまで「統制が設計・運用されているか」を評価したものであり、「絶対にセキュリティインシデントが起きない」ことを保証するものではない。報告書に記載された補完的統制を利用者側で実装しなければ、SOC2 取得済みサービスを使っていてもリスクは残る。

Type1 だけで十分か

Type1 は設計の妥当性を確認したスナップショット評価だ。そのため、継続的に統制が機能しているかは Type2 でなければ確認できない。委託先管理の観点からは、Type2 の方が信頼性が高い。ただし、Type1 の取得自体が「統制を設計し、監査を受け入れる体制がある」ことの証明にはなるため、まったく無意味ということではない。

ISMAP と SOC2 はどちらが上か

両者は目的と評価方式が異なるため、単純な上下関係にはない。ISMAP は日本政府の調達要件であり、SOC2 は国際的な委託先管理の基準だ。両方を持っていることが、国内外の顧客に対する信頼性の幅を広げる。

まとめ

• SOC2 Type1 は、内部統制の設計が適切であることを第三者が評価したもの
• 今回は「さくらのクラウド」サービス単位での取得がポイント
• 国産クラウドの SOC2 対応は KDDI、IIJ、NTT Com が先行しており、さくらはクラウド単体での Type1 が起点
• ISMAP やガバメントクラウドの文脈と合わせて読むと、国産クラウドのガバナンス体制は着実に厚みを増している
• 報告書を閲覧する際は、対象範囲・監査意見・補完的統制を必ず確認する
• SOC2 報告書を「取得済み」の事実だけで終わらせず、中身を確認して自社の対応事項を把握することが不可欠

参考リンク

• 【さくらのクラウド】「SOC2 Type1報告書」を新たに取得 | さくらインターネット
• 情報セキュリティへの取組み | さくらインターネット
• 令和5年度新規募集分 ガバメントクラウドの対象となるクラウドサービスの公募結果について | デジタル庁
• ISMAP — 政府情報システムのためのセキュリティ評価制度
• SOC2 — AICPA Trust Services Criteria