RAYVENで働くのは、正社員だけではありません。副業や業務委託を含めると、2026年7月31日時点で稼働中のメンバーは約30人です。
全員が毎日、同じ社内ツールを使うわけではありません。
それでもWiki、CRM、会議支援、監視、自動化などを人数課金のSaaSでそろえると、利用頻度にかかわらず固定費が積み上がります。
ゲストアカウントを使える場合もあります。しかし、権限や連携機能の制限が、新たな運用負担になります。
そこで私たちは、SaaSを導入してから置き換えたのではなく、社内ツールを選ぶ段階からSaaSを標準にしない方針を取ってきました。
タイトルの「SaaSを使わず」は、すべてのSaaSを排除するという意味ではありません。社内ツールの選定でSaaSを無条件の初期値にせず、自分たちで持つ価値がある領域をセルフホストする、という意味です。
現在、社内基盤にかかる主なインフラ費用は、低価格なVMと社内サーバーの電気代です。
ただし、機器、バックアップ、AI利用料、人が判断する時間も含めて評価する必要があります。「ほぼ無料」ではありません。
この運用を成立させているのが、K3sやGitOpsによる共通基盤と、構築、更新、障害調査、文書化の作業量を減らすAIです。
この記事の結論
- 副業・業務委託を含む組織では、「1人＝1ライセンス」の費用構造が利用実態と合いにくい
- 認証、Secret管理、GitOps、監視を共通化すると、平常時の保守運用はほぼAIだけで回せる
SaaSから移行したのではなく、最初から自分たちで持つことを考えた
これは、導入済みのSaaSを後からすべて置き換えた話ではありません。社内ツールを選ぶ際、最初に次の問いを置いてきた話です。
この機能は、既存の共通基盤に載せて自分たちで運用できないか。
セルフホストできると判断した領域では、OSSを採用し、Gitで構成を管理します。外部との標準的な接点、高い可用性や専門運用が求められる領域、自社で責任を持つ意味が薄い領域だけ、SaaSを選びます。
つまり、SaaSを禁止しているわけではありません。SaaSを無条件の初期値にしていないということです。
約30人でも「1人＝1ライセンス」では割り切れない
メンバー全員が、毎日、同じ機能を使うわけではありません。
- 毎日業務に参加するメンバー
- 週に数日参加する副業エンジニア
- 特定のプロジェクトを担当する業務委託
- 必要なときだけ参加する専門家
このような組織で全員へ同じ有料ライセンスを割り当てると、利用頻度と費用が合わなくなります。
ゲストアカウントを利用できるSaaSもあります。しかし、閲覧範囲、権限設定、API連携などに制限があり、「このメンバーはどの機能まで使えるのか」を確認する手間が発生することもありました。
セルフホストであれば、ライセンス区分ではなく、社内の役割に合わせて権限を設計できます。利用人数が増えるたびに、すべてのツール費用が同じ割合で増えるわけでもありません。
一方で、アカウント発行、権限変更、退職・契約終了時の停止は自社責任です。自由度と責任は切り離せません。
AIがセルフホストの「見えない人件費」を小さくした
セルフホストで重いのは、サーバー代よりも、構成調査、Manifest作成、更新、障害調査、Runbook整備といった運用の人件費です。以前なら、その合計がSaaS料金を上回ることもありました。
現在は、人が最初に目的、制約、公開範囲、停止時の影響を決め、その後の定常運用をほぼAIへ任せています。
前提となるのは、セキュリティをAIの判断に委ねず、共通基盤で強制することです。
- 認証と公開範囲を共通のポリシーで制御する
- Secretを一元管理し、AIは参照名と設定構造だけを扱う
- GitOpsとCIで変更内容と反映履歴を残す
- 監視、ログ、バックアップを共通化する
Secret値はInfisical OperatorがKubernetesへ同期します。高権限が必要な障害調査は定常運用から分離します。
この境界内で、AIが構成調査、Manifestの作成・反映、更新、監視、障害分析、文書化を担います。問題がなければ人は介入せず、異常を検知したときだけ、修正やロールバックの方針を決めます。
人は最初に境界を決め、例外が起きたときに意思決定する。境界内の定常作業はAIが担う。
人の作業を、最初の設計と異常時の判断へ絞ることが、この運用の要点です。
個別のOSSではなく、共通基盤を使い回す
AIだけでセルフホストが安くなるわけではありません。サービスごとに認証、監視、バックアップを作り直さないため、次の要素を共通化しています。
- K3sとProxmoxによる実行・仮想化基盤
- Argo CDによるGitOpsとInfisicalによるSecret管理
- 共通の監視、ログ、バックアップ
- 認証と外部公開範囲の制御
Cloudflare Accessで社内サービスの入口を保護し、Google IdPで本人確認を共通化しています。サービスごとにログイン機能を作らずに済み、到達可能なサービスも共通ポリシーで管理できます。アプリ内部の認可や、メンバーの参加・離脱への対応は第2部で紹介します。
費用面でも、小さな会社には相性のよい組み合わせです。2026年7月31日時点で、Cloudflare Zero Trust Freeには50ユーザーの上限があります。Google側も、IdPとして利用できるCloud Identity Free editionが標準で50ユーザーライセンスを提供しています。約30人規模の私たちは、どちらも無料枠の範囲内です。
無料プランには機能差があり、Cloudflareの標準ログ保持は最大24時間、Cloud Identity FreeはGoogle Workspaceの全機能を含みません。それでも、小さな会社が無料で認証とアクセス制御を共通化できる価値は大きく、Cloudflareさんには足を向けて眠れません。
Git上のdesired stateを各環境へ反映し、新しいサービスでも既存の運用部品を再利用します。ただし、Gitの設定だけでは正常稼働を証明できないため、実環境、監視、バックアップ結果、利用実績は別に確認します。
主な費用がVMと電気代でも「無料」とは呼ばない
現在の主なインフラ費用は、低価格VMと社内サーバーの電気代です。しかし、TCO（総保有コスト）には次も含めます。
| 項目 | 確認する内容 |
|---|---|
| VM | 月額、ストレージ、スナップショット |
| 社内サーバー | 購入費、電気代、故障対応 |
| バックアップ | 保存容量、世代数、復元確認 |
| AI | API・サブスクリプション費用 |
| 人 | レビュー、更新、障害対応時間 |
AIによって作業時間を圧縮できても、ゼロにはなりません。具体的な金額は、請求額、消費電力、作業時間をそろえたうえで、このシリーズの最終部で公開します。
セルフホスト先も、自社サーバーとVPSで使い分ける
セルフホストを決めた後には、どこで動かすかという判断が残ります。
| 配置先 | 向いている領域 |
|---|---|
| 低価格VPS | 外部公開、安定した回線、物理保守を任せたいサービス |
| 社内サーバー | 停止しても事業への影響が限定的、メモリやGPUを多く使う、既存機器を活用できるサービス |
私たちは、一時的に停止しても顧客提供や売上へ直結しない社内向けサービスと、大容量メモリやGPUなどの計算資源を必要とする処理を、主に社内サーバーへ配置しています。一方、外部公開や安定した稼働を優先するサービスには低価格VPSを使います。
本番系と社内・検証系の役割を分け、単一の環境へすべてを集めないようにしています。具体的な役割分担や、停止を許容できる範囲の決め方は、第2部で扱います。
このシリーズで検証すること
- 第1部：AIによって、なぜSaaSを標準にしない運用が可能になったのか
- 第2部：低価格VPSと社内サーバーの役割分担、Cloudflare AccessとGoogle IdPによる公開・認証管理
- 第3部：AIをKubernetesの構築・更新・障害対応へどう組み込むか
- 第4部：実際にセルフホストしている社内ツール
- 第5部：VM、電気代、AI利用料、保守時間を含むTCO
最終的には、次の問いへ数字で答えます。
AIを運用へ組み込めば、小さな会社でもセルフホストは本当に安くなるのか。
SaaSは最初の選択肢ではなく、自前で持てない領域を補うもの
インフラの運用責任は、AIではなく会社と人に残ります。 しかし、人がすべての変更へ都度立ち会う必要はなくなりました。
人は最初に目的、制約、公開範囲、例外時の判断基準を決めます。 共通基盤がその境界を強制し、AIが境界内の構築、更新、監視、文書化を担います。 問題を検知したときだけ、人が修正、回避、ロールバックの方針を決めます。
AIが変えたのは責任の所在ではなく、定常運用へ人が介入する頻度です。認証、Secret管理、GitOps、監視を共通化したことで、平常時の保守運用はほぼAIだけで回せるようになりました。 この分担と共通基盤があるからこそ、約30人が利用する社内ツールを、人数課金のSaaSだけに頼らず運用できています。
次回は、低価格VPS、Proxmox、K3sの役割分担に加え、Cloudflare AccessとGoogle IdPで社内サービスの入口をどう共通管理しているかを紹介します。