本記事では、2025年5月14日に開催されたオンラインイベント「【技術選定を突き詰める】Online Conference 2025」内のセッション「さくらのクラウド開発の裏側」の内容をお届けします。同セッションでは、さくらインターネット株式会社の池添 正隆さんに、ガバメントクラウドへの対応を契機とした開発体制の変革や、認証基盤を刷新した際の技術選定、チームの生産性を高めるコーディングガイドラインについてお話しいただきました。ぜひ本編のアーカイブ動画とあわせてご覧ください。
池添：さくらインターネットのクラウド開発の裏側について、池添がお伝えします。まず自己紹介させてください。現在、クラウド事業本部クラウドサービス部サービス開発でアプリケーションエンジニアを担当しています。主にバックエンドの開発がメインです。担当している機能としては、さくらのクラウドの認証認可、統制基盤の開発です。
略歴ですが、さくらインターネットには2006年に入社しました。データセンター勤務を開始し、2009年頃からさくらの専用サーバーのサービス開発でインフラやミドルウェアを扱っていました。2015年頃からはさくらの専用サーバー、VPSのバックエンド開発に携わり、この頃からアプリケーション開発を行うようになりました。直近では2020年頃に衛星データプラットフォームのTellusのバックエンド開発に携わり、2023年からはさくらのクラウドのバックエンド開発をメインにしています。
さくらインターネットが挑む、クラウド開発の大変革
本日お伝えしたいことは、さくらのクラウドの直近の取り組み、さくらのクラウドのサービス開発で働くアプリケーションエンジニアを取り巻く体制の変化、そしてアプリケーションエンジニアがどういうことを考えて開発を行っているのか、この3点です。
さくらインターネットは1996年に創業し、以来インターネットインフラの提供を主力事業としています。データセンターは東京、石狩、大阪に展開しており、国内のインターネットを支える企業です。 レンタルサーバー、VPS、クラウド、専用サーバー、ハウジングの他、新しいサービスとしてIoTや高火力と呼んでいるAI、人工知能系のGPUを提供するサービスなどを展開しています。本日は特にさくらのクラウドについてお話しします。
さくらのクラウドの主な特徴としては、データ主権が日本にあること、つまり日本のデータセンターで日本の企業が日本の法令に準拠して運用している点、そしてデータ転送量が無料という点です。さくらのクラウドの直近の最重要項目として取り組んでいるのが、ガバメントクラウドへの取り組みです。ニュースなどでご存知の方もいると思いますが、ガバメントクラウドへの取り組みは大きなものです。
政府共通のクラウド利用環境「ガバメントクラウド」
ガバメントクラウドとは、政府の情報システムなどを運用するためのクラウド環境です。デジタル庁が中央にあり、左側にクラウドサービスプロバイダー（CSP）、右側に利用システムがあります。
これは、まずデジタル庁がCSPと契約し、利用料金を支払います。そして確保したCSP各サービスのリソースを、利用者に払い出して使ってもらうという形です。
この目的は、インフラの構築コスト削減、管理工数の削減、セキュリティ水準の向上、開発スピードの向上、継続的改善の実現です。利用者に使いやすくセキュリティも担保され、自身のサービス開発スピード向上につながる環境を提供します。
ガバメントクラウドに関しては、デジタル庁が認定したCSPを使うことになっています。さくらのクラウドもCSPに当たりますが、2023年11月に条件付きで認定されました。その条件は、2025年度末までに全ての技術要件を満たすことです。項目数としては305項目[1]あるのですが、2023年当時でさくらは約半数の技術要件を満たしている状況でした。
30人チームを解体。開発速度を上げるための機能別チームへの再編
さくらのクラウドは2011年11月に開始されたサービスで、2023年時点で約13年経っています。期限が2025年度末までということで、あと2年強で残りの半数の技術要件を満たす必要があり、非常にハードルが高いことが分かります。
この技術要件を満たすために開発を進めるには、これまでのやり方では達成が困難だと判断しました。たとえ人員を増やしても、同じやり方では難しいという話がありました。 そのため、開発のやり方自体を変えていこうと、様々な模索をしてきました。これは現在も常に見直しを続けていますが、まずは2023年当時に行ったことについて説明します。
30人規模チームが抱えていた「成長の壁」
それまでの開発体制は、大きく1つのチームがクラウドの機能を開発していました。当初は10人未満の少人数で始まったチームでしたが、2023年頃には約30人規模になっていました。
当時の課題として、意思決定が難しくなっているという点が挙げられます。他にも、担当機能が多岐にわたるため話すことが多く、ミーティングに時間を取られてしまうといった問題がありました。 そこで、チームを機能単位で分割しました。それぞれのチームが担当機能に責任を持って開発を進めます。
体制変更で大切にした3つの価値観
分割に当たって大事にしたポイントが3つあります。
1つ目は、「ガバメントクラウドのための体制」ではなく、「ガバメントクラウドを契機に改善していく体制」としたことです。既存のお客様の使い勝手を損なわないよう、引き続き使っていただけることを意識しました。ガバメントクラウド自体は、技術要件が達成されたらゴールではありません。そこからさらにサービスを良くし、改善していくことが必要です。これはガバメントクラウドの目的であるセキュリティ向上や開発スピード向上、改善を実現する上でも大切なことです。あくまでガバメントクラウドはゴールではなく、きっかけ、始まりであるという点を意識しました。
もう1つは、中央集権型の体制ではなく、小さなチームで大きな仕事をすることです。1つの大きなものよりも、小さなチームそれぞれが責任感を持って、自身のチームに任された機能に対して責任を持ち取り組んでいくというものです。これはピラミッド型よりもスター型の組織に近く、それぞれのチームが自身の責任分野において、周りのチームと連携を取りながら主導して開発を進めます。
最後に、「ひとりで、早く」ではなく、「みんなで、遠くへ」ということです。PoCなどを作る時は1人で進める方が早い場合もありますが、1人での開発には限界があります。これはチーム開発を大切にし、属人化をなくすことにつながります。これらのポイントを大事にして体制変更を行いました。
分割がもたらした開発速度の向上と効果
実際どうだったかというと、チーム分割により機能単位で意思決定を行えるようになり、サービス開発のスピードが上がりました。チームごとに担当機能を設定することで、以前よりも必要となるドメイン知識の幅を抑えることができました。
1つの大きなチームだった時は、あらゆるクラウド機能について把握する必要があり、新しいエンジニアが開発に参加するハードルが高かったのです。それがチームを分割することで、ドメイン知識の幅を抑え、新しいエンジニアが開発に参加しやすくなりました。実際に、2025年2月には13の新しいサービスをリリースすることができました。
レガシーな認証基盤の刷新と、Django採用の舞台裏
次に、私が参加しているチームについて説明します。私はクラウドAPI開発チームにおり、認証認可および統制基盤の開発を行っています。
課題は13年稼働したレガシーなID管理システム
まず初めにやったことです。当時、認証認可の機能はさくらのクラウドのIaaS基盤の管理システムに載っていました。このシステムはサービス開始時から稼働しているもので、認証認可以外も含め、当時のさくらのクラウドの大部分の機能が動いているシステムでした。このシステムは長く稼働しており、レガシーな部分も多くなっていました。今後スピード感を持って新しい機能を追加していくにあたって、新規開発のコストが高いと考え、認証認可の機能は切り出しを行うことになりました。
新しいシステムを立ち上げるにあたり、まずは調査を行いました。実際の状況把握から始め、データベースの中身のデータ、移行するカラムと残すカラムの精査、切り出す機能やコードの把握、そして移行部分の範囲を確認しました。
また、移行前後で機能に差が出ると問題になるため、特に認証認可の部分においては、差分が出ないように既存機能のリストアップを行いました。機能数としては、エンドポイント単位で約900ありました。それぞれのエンドポイントに対し、移行前後でテストを行うことで、差分がないことを確認するという計画を立てました。
技術選定の決め手は「社内実績」と「開発スピード」
これらの機能を移行することが見えてきたところで、次にシステムを実装するWebフレームワークをどうするかという話になりました。様々なフレームワークが存在しますが、選定にあたって重視したポイントは以下の通りです。
まず、十分な機能を持っているかという点です。例えばORMの機能が十分か、周辺ライブラリは豊富か、フレームワーク自体の開発が活発かどうか、発見された問題にすぐ対応されるか、公式ドキュメントが充実しているかといった点です。そして、パフォーマンスに問題はないか、何よりもスピード感を持って開発を進められるかという点が大きなポイントでした。
これらの観点から検討した結果、Djangoを採用しました。Djangoは開発が活発で、必要な機能を実装するにあたって周辺ライブラリも充実しています。公式ドキュメントも充実しており、キャッチアップがしやすい状況でした。Djangoを触ったことがないエンジニアでもドキュメントを見ながら学習ができます。
何よりも大きかったのは、Django自体が2015年頃から社内VPSや専用サーバーのバックエンドで利用実績があり、コーディングガイドラインなどのノウハウが蓄積されていました。 機能的に十分であり、社内での実績とノウハウがあるため、スピード感を持って開発ができると判断し、Djangoを採用しました。
採用して見えたメリットと今後の課題
Djangoを採用してみて良かった点は、開発が活発でWeb上にも情報が多く、ライブラリが充実していることです。また、社内での実績やノウハウがあったため、チーム開発を素早く立ち上げられたことも良かったです。
良かった点だけでなく、課題になりそうな点も挙げておきます。まずは、1サービスの実装を前提にしている点です。例えばSAML連携を実装する際にライブラリを使うと、1つの外部IDPと連携するような実装になっているものがあります。さくらのクラウドの場合は、組織ごとに複数のIDPと連携する必要があるため、ライブラリの機能をそのまま使えるわけではありませんでした。これはDjangoに限らず、他のフレームワークでもあり得る課題です。
もう1つはパフォーマンスです。現時点では問題になっていませんが、今後リクエスト数が増えてくると、高負荷になることが予想されます。そのため、パフォーマンスの状況を監視しながら、必要に応じてGoなどを使って切り出すことが必要になると思います。
チームの開発生産性を高める、8つのコーディングガイドライン
次に、チーム開発を素早く立ち上げられた要因の一つに、コーディングガイドラインがあると考えています。実際にどのようなものを定義し運用しているか紹介します。
1. マインドセット
まずメンバーのマインドセットとして、『Team Geek』で語られているようなHRTの実践を掲げています。開発に関しては、オブジェクト指向プログラミングで必要な知識としてSOLID原則、他にYAGNI、KISS、ボーイスカウトルールなどを挙げています。これらは必ず守るというよりも、知識として知っておく必要があり、場面に応じて適切に落とし込めると良いのだと考えています。あくまで知識をツールとして使い、知識に縛られないという観点が必要です。
2. コーディングスタイル
コーディングスタイルについては、Pythonを使用しているので、PEP 8に準拠すると定めています。 PEP 8で語られていないもの、例えば1行の文字数を超えた場合の改行位置、if文の書き方、条件の書き方など細かなところもありますが、レビューでビジネスロジックに集中できるよう、ruffを使って自動でフォーマットをかけることで解決しています。
1行の最大文字数に関して、デフォルトのPEP 8だと79文字ですが、最近のモニター環境やエディターを使うと短いという話があったため119文字にしています。これはGitHubでコードレビューする時にコードが折り返されない文字数に設定しています。
3. コード実装
Django、DRFでの実装に関しては次の定義を行っています。モデル、シリアライザ、フォーム、テンプレートはできるだけ薄くし、ビューで機能を凝集させることを意識しています。その上で、必要に応じてビジネスロジックは個別のクラスに切り出すということを行っています。また、インポートの制約として、相互インポートを避けて分かりやすくするようにしています。
4. DB設計
DB設計に関しては、物理削除と論理削除の扱いについて定義しています。基本的には論理削除を行いません。不要なデータはレガシーになってしまったり、真偽値だけで論理削除するようなものだと不要なデータが残ってしまい扱いに困ることがあるためです。ただし、物理削除できないものもあります。例えば注文情報のようなものは常に残しておく必要があるため、状態管理を行います。大事なのは、扱うエンティティに対して正しく状態を整理し管理していくことです。
作成日時や更新日時を示すcreated_atやupdated_atカラムはデフォルトで存在しますが、これらのカラムにビジネスロジック的な意味を持たせないようにしています。例えば、注文日時を管理したいのであれば、ordered_atのような専用のカラムを追加します。これはcreated_atカラムだと意味が消失したり、場合によっては複数の意味を持つことになってしまうのを避けるためです。
5. URL設計
RESTfulなAPIに準拠することを基本としています。リソースの集合を扱う場合はRESTの考え方が非常に扱いやすいですが、例えばリソースのプロパティ、ユーザーのプロフィール情報のようなもののURLをどう表現するかは明確にされていません。そのため、プロパティを表すものに関しては単数形を用いるようにしています。また、CRUD操作以外の動作を表すURL、例えばサーバーの電源をオンにするような場合は、単に集合を扱うものとは違う動作を表現する必要があります。そういったところは、思い切って適切な名前、URLパスを設定するようにしています。
6. ログ設計
ログレベルをしっかり設定することを重視しています。また、ロギングモジュールでログが文字列で出力されると思いますが、ログの全てを文字列として出力せず、適切にプレースホルダーを使うようにしています。これは後でログが整理しやすいためです。現状、チーム状況的に日本語を話すメンバーが多いので、ログの出力は日本語で行っています。
7. ユニットテスト実装
ユニットテストの実装については、読みやすいテストを書くことを重視しています。DRY（Don't Repeat Yourself）を意識しすぎず、読みやすさを重視し、内容の重複や冗長な実装があっても許容します。テスト対象のパターンは、正常系、異常系、境界値をしっかり網羅します。テストの値の比較に関しては、実装と同じロジックで値を比較しないようにしています。 これは、同じロジックで値を生成して比較してしまうと、間違いに気づけない可能性があるためです。 カバレッジについては、あくまで目安と捉え、ロジックの網羅性を重視しています。100%になったらOKという話ではなく、ロジックの部分にも着目するようにしています。
8. コードレビュー
コーディングガイドラインでレビューの原則を定めています。レビューはレビューアとレビューイの共同作業であることを意識し、お互いを尊重すること、そしてレビューはコードを改善するためのプロセスであることを原則としています。
レビューの心構えとして、1つは大きなプルリクエストを作らないことです。大きなプルリクエストはレビューに時間がかかり、やりとりも長くなりがちなので、大きくなりそうであれば意味のある単位で分割し、プルリクエストを分けて出すようにしています。また、レビューを放置しないこと、すぐに着手できない場合はいつ頃着手できるかコメントすること、コメントをつける場合は具体的な内容をコメントすることも定義しています。
まとめ：変革の先へ。さくらのクラウド開発のこれから
ここまで、さくらのクラウドのガバメントクラウドへの取り組みについて紹介しました。ガバメントクラウドとは何か、ガバメントクラウドを契機に起こった開発体制の変更について話しました。さらに、担当している認証認可や統制基盤のシステム開発の裏側として、採用したフレームワークやコーディングガイドラインなどを紹介しました。
私からの発表は以上となります。ご清聴ありがとうございました。
アーカイブ動画・発表資料
イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。
▼動画・資料はこちら
「さくらのクラウド開発の裏側」
※動画の視聴にはFindyへのログインが必要です。