Argo CDとAtlantisで実現するインフラ管理のセルフサービス化 ──小規模SREチームで支えるプラットフォーム 2026/09/26 Platform Engineering Kaigi 2026 株式会社アンドパッド 開発本部 サービスプラットフォーム部 部長 角井 暖 © 2026 ANDPAD All Rights Reserved. 1 

自己紹介 角井 暖 / Dan Kadoi ● ● ● ● @cass7ius ERP パッケージベンダーで DevOps を経験し、 2019 年 8 月よりアンドパッドの SREに参画 コンテナ化プロジェクト、SRE/DBREチームの テックリードなどを経て、2026年より部長に 就任 SRE / DBRE / セキュリティの 3 チームを管掌 © 2026 ANDPAD All Rights Reserved. 2 

この発表は「SREへの依頼をPull Requestに変えた話」 ● 小規模なSREチームによる、インフラ管理のセルフサービス化の事例 ● 変更の入口はPull Requestに一本化。適用はプラットフォームの仕事 ● 前半：なぜGitOpsだったのか、依頼をPull Requestに変えるとは何か ● 後半：入口 → 境界 → 検証 → 適用 の4段階で、どのように整備したか ● 最後に、何がどれだけ変わったか ● 気になった点、もっと詳しく聞きたい点はぜひブースへ © 2026 ANDPAD All Rights Reserved. 3 

前提と、起きていたこと 事業と組織、そしてマイクロサービス化のあと © 2026 ANDPAD All Rights Reserved. 4 

ANDPADとは ※ ANDPADは現場の効率化から経営改善まで一元管理できる クラウド型建設プロジェクト管理サービスです クラウド上で最新の情報を共有 スマホで撮影した写真、 データを活用して、 チャットで共有された ・資料作成 資料や各現場の図面 ・検査報告書作成 データ 入力 写真 工程表 チャット 報告 受発注 検査 引合粗利 図面 データ 活用 ・帳票作成 ・データ資産... ※『建設業マネジメントクラウドサービス市場の動向とベンダシェア（ミックITリポート 2025年12月号）』（デロイト トーマツ ミック経済研究所調べ） © 2026 ANDPAD All Rights Reserved. 5 

マルチプロダクト戦略を小規模なSREチームで支える ● ● フェーズも体制も異なるプロダクト開発チームが多数あり、横断的な関 心事を扱うチームが施策の展開や技術支援をしている SREは中央集中型の小規模チームで、Embedded SREはなし 開発チームA 開発チームB QA QA Frontend Backend Native App 開発チームC 開発チームD Frontend Frontend Frontend Backend Backend Backend Native App 横断的な関心事を扱うチーム （SRE, DBRE, CRE, セキュリティ, FinOps など） © 2026 ANDPAD All Rights Reserved. 6 

マイクロサービスアーキテクチャの採用とその後 ● ● ● ● ● もともとは、巨大なRailsアプリがひとつだけ 事業成長に伴って拡大する開発リソースをフル活用するため、マイクロ サービスアーキテクチャの採用を決定 2021年頃、マイクロサービスの共通実行基盤をEKSで構築。アプリのデ リバリー以外の関心事を抽象化 ○ テレメトリ収集と計装、サービスディスカバリとL7負荷分散、外部 公開の手法などを、SREで機能提供 デリバリーは各チームの裁量に委ね、新規事業の立ち上げを加速 その結果、数年の時を経て3つの課題が顕在化 © 2026 ANDPAD All Rights Reserved. 7 

顕在化した3つの課題 1. デリバリーパイプラインのサイロ化 — 運用ナレッジがチーム内に閉じる 2. インフラ管理の自律性の低下 — 強い権限を要する作業がSREへの依頼に 3. システム構成の不透明化 — 命令的なデプロイと手作業の変更の蓄積 プロダクトが増えるほど掛け算で大きくなる 重なり合う問題として、まとめて手を打つ必要があった © 2026 ANDPAD All Rights Reserved. 8 

どう解くことにしたか 考え方と、プラットフォームの全体像 © 2026 ANDPAD All Rights Reserved. 9 

3つの課題の根は、変更の経路がばらばらだったこと ● ● ● ● 課題1はチームごとの経路、課題2はSREへの依頼、課題3は手作業 決めたのは1本の標準経路 ○ 入口はPull Request、適用はプラットフォーム その経路の型としてGitOpsを採用。あるべき状態をGitに宣言する OpenGitOpsの4原則（opengitops.dev） ○ 宣言的：あるべき状態が宣言で表現されている ○ バージョン管理され不変：履歴が残り、書き換えられない ○ 自動的にpull：エージェントが自動で取得する ○ 継続的にリコンサイル：実状態を観測し、寄せ続ける © 2026 ANDPAD All Rights Reserved. 10 

依頼をPull Requestに変え、セルフサービス化を促進 ● ● ● ● 依頼のかたち：チャットで相談 → SREが手で作業 → 記録は手順書の中 Pull Requestのかたち：宣言で表現、履歴はGit、適用はプラットフォー ム 開発チームとの接点は残して、強い権限ではなくレビューで安全性を担 保 SREは変更の代行者ではなく、安全に変更できるプラットフォームの提 供者 © 2026 ANDPAD All Rights Reserved. 11 

プラットフォームの全体像 ● 変更はPull Requestから入り、適用はプラットフォーム側が行う Argo CD sync Kubernetesクラスター 各Application クラスター内で pull インフラの設定を管理する GitHubリポジトリ群 あるべき状態をGitに宣言する Atlantis Pull Request上で plan / apply apply クラウド / SaaS AWS・監視・ID基盤 ほか © 2026 ANDPAD All Rights Reserved. 12 

インフラの設定を管理するリポジトリ群 ● ● ● ● アプリ用モノレポ（開発チームが管理） ○ マイクロサービスのApplicationの定義と、チーム固有のHelm Chart プラットフォーム用モノレポ（SREが管理） ○ 基盤コンポーネントと、Argo CD自体の設定 （ApplicationSet・AppProject） ○ 共通のCIワークフローと、クラスター全体に効くポリシー 共通Helm Chartリポジトリ（SREが提供し、各チームが参照） Terraformモノレポ（開発チームとSREが共同で管理） 「誰が何を変えられるか」は、まずリポジトリの分け方で決まる © 2026 ANDPAD All Rights Reserved. 13 

Argo CDとは ● ● Gitのマニフェストをあるべき状態として読み取り、クラスター内から継 続的に同期するGitOpsツール CIに書き込み権限を渡さず、差分の自動適用はApplicationごとに宣言 Kubernetesクラスター pull merge 開発チーム アプリ用モノレポ Pull Requestを出す main = あるべき状態 Argo CD 差分を収束 各Application CI：検証のみ © 2026 ANDPAD All Rights Reserved. 14 

Atlantisとは ● ● ● TerraformのplanとapplyをPull Request上から実行するOSS 実行結果がPull Requestにコメントされ、コードレビューが容易に Pull Request経由の変更では、Gitの状態と実環境がずれにくい © 2026 ANDPAD All Rights Reserved. 15 

Pull Requestが適用されるまでの4段階 ● ● 標準化した経路では、どの変更も4つの段階を同じ順で通る この段階を整備することで、課題がどう解決されるかを見ていく 段階 その段階で決めること 効いた課題 入口 どこに何を書くか 課題1 デリバリーパイプラインのサイロ化 境界 誰が何を変えられるか 課題2 インフラ管理の自律性の低下 検証 適用前に何を確かめるか 課題3 システム構成の不透明化 適用 誰が適用するか 課題2・課題3 © 2026 ANDPAD All Rights Reserved. 16 

書く場所と形を揃える 1つのモノレポに集め、ディレクトリの形を全チームで共通にする 課題1 デリバリーパイプラインのサイロ化を解消 入口 → 境界 → 検証 → 適用 © 2026 ANDPAD All Rights Reserved. 17 

インフラの設定は、決まったリポジトリに集める ● 変更の入口は、開発チームもSREも同じPull Request Pull Request 開発チーム アプリ用モノレポ プラットフォーム用モノレポ 共通Helm Chartリポジトリ SREチーム Terraformモノレポ © 2026 ANDPAD All Rights Reserved. 18 

【Kubernetes】1ディレクトリ = 1 Application clusters///// ├── helmfile.yaml # Helm Chart の参照とvaluesの重ね順 ├── values.yaml # 環境固有の設定値 ├── image.values.yaml # CI が更新するイメージタグ（コミット SHA） └── secrets.yaml # 暗号化された秘匿値 ● ● ● 値はディレクトリ内で完結し、実行時に外から値を注入しない Helm Chartは同じリポジトリ内の charts// を参照。外部の Chartはバージョンを固定 このディレクトリを見るだけで「何がどう出来上がるか」が分かる © 2026 ANDPAD All Rights Reserved. 19 

【Kubernetes】ApplicationSetで自動生成する generators: - git: repoURL: < アプリ用モノレポ > revision: main directories: - path: clusters//*/*/* ● ● ● ディレクトリを追加すればApplicationも増える。1つずつ手で書く必要 なし チームによっては、設定ファイルを起点にするgeneratorも併用 テンプレートはプラットフォーム用モノレポにあり、全チーム共通 © 2026 ANDPAD All Rights Reserved. 20 

【Terraform】モノレポで構造を揃える //envs// //modules/... aws/modules/... ● ● ● ● # 1 つの実行単位 # プロダクト固有モジュール # 共通モジュール provider → プロダクト → 環境の3階層。stateとオーナーの単位を一致 1実行単位 = 1環境ディレクトリ。400件程度を1つのリポジトリで管理 ディレクトリパターンが揃っていれば、他所のコードを真似して書き始 められる 共通モジュールはSemVerで管理し、バージョンを指定して参照 © 2026 ANDPAD All Rights Reserved. 21 

【Terraform】atlantis.yamlで実行単位を宣言 projects: - name: - dir: ./aws//envs/ autoplan: when_modified: - "**/*.tf*" - "**/.terraform.lock.hcl" - "../../modules/**" # モジュール変更も plan対象 ● ● 実行単位の名前はパスから機械的に決まる命名規則。ファイル冒頭に明 文化 モジュールを変更すると、それを参照する実行単位も自動でplan対象に なる © 2026 ANDPAD All Rights Reserved. 22 

境界を宣言して権限を委譲する 触れる範囲を宣言で決め、その単位で権限を渡す 課題2 インフラ管理の自律性の低下を解消 入口 → 境界 → 検証 → 適用 © 2026 ANDPAD All Rights Reserved. 23 

【Kubernetes】AppProjectで触れる範囲を宣言する spec: destinations: [ < チームのnamespace> ] namespaceResourceWhitelist: - { group: apps, kind: Deployment } - { group: batch, kind: CronJob } roles: - name: developer policies: - p, proj::developer, applications, sync, /*, allow - p, proj::developer, applications, action/*, /*, allow # update は許可しない。マニフェストの変更は Pull Request から ● ● チーム名・IdPのグループ名・AppProject名を一致させ、境界を1つに統 一 強い権限を配るのではなく、扱えるリソース種別とNamespaceを宣言で 制限 © 2026 ANDPAD All Rights Reserved. 24 

【Terraform】オーナー定義とapply権限を委譲する ● ● state・CODEOWNERS・apply権限を、同じオーナー単位に揃える ○ applyできる範囲は、AtlantisのExternal command機能で限定 ○ 横断チームは委譲済み、開発チームはこれから AtlantisはECS on Fargateで実行し、強い権限は人ではなく実行基盤に © 2026 ANDPAD All Rights Reserved. 25 

適用前に差分を検証する 構造が同じなので、同じ検証をすべての変更にかける 課題3 システム構成の不透明化を解消 入口 → 境界 → 検証 → 適用 © 2026 ANDPAD All Rights Reserved. 26 

【Kubernetes】適用前にCIで差分を検証する ● ● ● ● ● プロダクトのソースコードのリポジトリと、アプリ用モノレポは別々 イメージタグ更新のPull Requestは、共通ワークフローが自動で作成 プロダクト側のCIがモノレポに対して行うのは、Pull Requestの起票ま で ディレクトリ構造が全チーム共通なので、検証を一律にかけられる ○ 変更のあったApplicationごとに、テンプレート展開・ポリシー・ス キーマを検証 テンプレートの展開結果だけで完結するので、CIにクラスターの認証情 報は不要 © 2026 ANDPAD All Rights Reserved. 27 

【Terraform】適用前にplanで差分を確認する ● ● ● Atlantisが、Pull Request上にplanの結果をコメントとして記録 「何が変わるか」を、起票者とレビュー担当が同じ画面で確認してから apply 手作業による変更が減り、コードと実際の構成のずれも起きにくい状態 へ © 2026 ANDPAD All Rights Reserved. 28 

適用をプラットフォームに任せる 人ではなくArgo CDとAtlantisが適用する 課題2 自律性の低下と課題3 不透明化を、あわせて解消 入口 → 境界 → 検証 → 適用 © 2026 ANDPAD All Rights Reserved. 29 

【Kubernetes】適用はクラスター内のArgo CDが行う ● ● ● ● どのチームのApplicationも、クラスター内のArgo CDが適用する 適用に必要な権限はArgo CDが持つ。CIや開発チームに渡す必要がない 適用されるのはmainの内容だけ ○ targetRevisionはテンプレート側で固定し、全チーム共通 本番は例外なくレビュー、開発環境は自動マージ。統制はこの1点に集約 © 2026 ANDPAD All Rights Reserved. 30 

【Terraform】applyはAtlantisの実行基盤が行う ● ● ● applyを実行するのはSREのローカルではなく、Atlantisの実行基盤 起動はPull Request上のコメントによるイベント駆動 ○ 誰がいつ適用したかがPull Requestに残る applyが成功し、インフラが期待どおりになってからマージ ○ 期待と違えば修正をプッシュし、planからやり直す ○ マージ後は、mainの内容と実環境が一致した状態 © 2026 ANDPAD All Rights Reserved. 31 

GitOpsの4原則に照らすと、到達点は同じではない ● ● ● Atlantisはイベント駆動のため、pullとリコンサイルは未達 Argo CDはドリフト検出が全Application、復帰はself-heal有効時 差は残るが、Pull Requestを通り、適用の主体が人でない点は共通 OpenGitOpsの4原則 Kubernetes（Argo CD） Terraform（Atlantis） 宣言的 ○ ○ バージョン管理され不変 ○ ○ 自動的にpull ○ ✕ 継続的にリコンサイル △ ✕ © 2026 ANDPAD All Rights Reserved. 32 

結果 何がどれだけ変わったか © 2026 ANDPAD All Rights Reserved. 33 

現場で起きた反応 ● ● ● ● SREが手動で管理していた設定も、徐々にimportしIaC化 変更の依頼者が自分でPull Requestを起票する流れが定着 「プラットフォームに移行して運用が楽になった」という声が、他チー ムの動機づけに SREへの依頼待ちが減り、レビューで設計の意図を共有する時間へ © 2026 ANDPAD All Rights Reserved. 34 

たくさんの変更が、Gitを通って流れるようになった ● ● ● 最初のApplicationが稼働した2025年1月を基準にしている 開発チームが触る2つのモノレポで、Pull Requestが伸び続けている SREの規模を変えないまま、多くの変更がGitを通って流れた © 2026 ANDPAD All Rights Reserved. 35 

載るものは増えても、SREの範囲は増えない ● ● ● ● アプリ用モノレポでのデプロイに移行したサービスは、全体の1/3程度 Argo CDのApplicationは、2025年初めの十数件から150件程度に Terraformの実行単位は、2024年末の数十件から400件程度に 委譲が進むほど、SREの管理範囲が増えても変更量の増加は小さい © 2026 ANDPAD All Rights Reserved. 36 

まとめ 課題・考え方・仕組み・結果 © 2026 ANDPAD All Rights Reserved. 37 

まとめ ● ● ● ● ● 課題：マイクロサービス化のあと、サイロ化・自律性の低下・不透明化 が重なった 考え方：変更の経路を標準化し、SREへの依頼をPull Requestに変更 ○ 強い権限は人ではなく基盤に置き、レビューで安全性を担保する 仕組み：入口・境界・検証・適用の4段階を、Argo CDとAtlantisで揃え た 結果：開発チームが触るモノレポのPull Requestは4倍以上に ○ SREの規模を変えないまま、変更のスループットを安全に増やせた 残課題は2つ ○ 既存の仕組みからプラットフォームへの移行は、まだ道半ば ○ Terraform側のドリフト検出は未整備 © 2026 ANDPAD All Rights Reserved. 38 

We are hiring! https://engineer.andpad.co.jp/ 技術スタックや募集ポジションを 掲載してます！ © 2026 ANDPAD All Rights Reserved. 39 

Appendix © 2026 ANDPAD All Rights Reserved. 40 

プラットフォームの全体像 ● ● 変更の入口は開発チームもSREも同じPull Request 本番環境のリソースを直接変更できる強い権限は人に配らない Pull Request アプリ用モノレポ 開発チームが管理するk8sマニフェスト 開発チーム プラットフォーム用モノレポ SREが管理するk8sマニフェスト Argo CD sync クラスター内で pull Kubernetesクラスター 各Application 共通Helm Chartリポジトリ SREが提供し、各チームが参照 SREチーム Terraform モノレポ 各チームが管理するインフラ、SaaS設定 Atlantis Pull Request上で plan / apply apply クラウド / SaaS AWS・監視・ID基盤 ほか © 2026 ANDPAD All Rights Reserved. 41