サイバーセキュリティ領域を担うアシュアード

内山：本セッションは「セキュリティ評価プラットフォーム事業とともに変わり続けるアーキテクチャ」という内容でお話しさせていただきます。

本日は2名でお話しさせていただくのですが、私は内山と申します。株式会社アシュアードでバックエンドを中心にサービスの開発であったり、QAやSRE機能を持つ技術基盤チームのマネージャーをしております。

大橋：大橋と申します。株式会社アシュアードでSREをしております。本日はどうぞよろしくお願いいたします。

内山：最初に簡単に弊社のことをご紹介させてください。株式会社アシュアードは、Visionalグループの会社です。Visionalグループは「新しい可能性を、次々と。」というグループミッションのもと、世の中の課題解決に資する事業を数多く展開しています。

株式会社アシュアードはサイバーセキュリティ領域を担う会社で、クラウドサービスのセキュリティ信用評価「Assuredクラウド評価」、取引先企業のセキュリティ信用評価「Assured企業評価」、脆弱性管理クラウド「yamory」を運営しています。

セキュリティ評価の課題を解決する「Assuredクラウド評価」

内山：皆さんは、セキュリティチェックシートに回答したことはありますか？　回答したことがある方はご存知だと思いますが、クラウドサービスを導入する際には、自社のセキュリティ基準を満たしているかを確認するため、各企業が独自の質問票を送り、回答を求めるという習慣があります。

クラウドサービスの事業者様からすると、顧客ごとにフォーマットの異なる多様なチェックシートの一つひとつに回答する作業はとても大変です。一方で、クラウドサービスを利用する企業様からしても、1社で利用するサービスが数百にも及ぶと言われている中で、その全てを個別に精査するには膨大な時間がかかります。

そもそも、返ってきた回答を正しく判断するためには、高度なセキュリティの専門知識が不可欠です。しかし、現在の日本ではそうしたセキュリティ人材が不足しています。そこで私たちは、この問題をプラットフォームとして解決していきたいと考えています。

「Assuredクラウド評価」は、そのようなセキュリティ評価情報を集約し、企業のクラウド活用を支えるプラットフォームです。先ほどお話ししたAssured独自の調査フォーマットによる回答をベースに、セキュリティ専任チームが作成した評価レポートやWebサイトから得られる情報、第三者認証などの公開情報を集約しており、これらの情報を活用してクラウドサービスの活用を促進していただくためのサービスです。

また、セキュリティ評価情報だけでなく、自社で利用されているクラウドサービスを洗い出す「サービス検知機能」や、それらを管理するための「サービス台帳機能」など、セキュリティ評価に関わる一連の業務フローを支える機能も提供しています。

2022年にサービスをリリースし、現在では大手企業を中心に1,000社以上の企業様に導入いただいています。

2025年6月には、クラウドサービスだけでなく、取引先企業のセキュリティ評価を行う「Assured企業評価」もリリースしました。こちらもAssuredのセキュリティ専門家が第三者機関として委託先企業様やサプライチェーン全体におけるリスクを評価するサービスです。

ちなみに、「Assuredクラウド評価」事業は、1枚のExcelシートから始まりました。

現在のアーキテクチャはこちらです。本日は、1枚のExcelシートから現在のアーキテクチャに至るまでの変遷や、その経緯についてお話しいたします。

YAML管理とCI/CD導入でチェックシートの作成を効率化

内山：「Assuredクラウド評価」を立ち上げるにあたり、私たちはクラウドサービスを利用する企業様のセキュリティ担当者の方々をはじめ、事業の開発責任者、セキュリティ専門など、100人以上の方にお話を伺ってきました。

対話を重ねる中で、世の中にある「セキュリティチェックシート」には、明確なソースがあることが徐々に分かってきました。それは、経済産業省や総務省が提示しているチェックシートであったり、そのベースとなっているISO/IEC 27001や27017といった標準規格、あるいはNIST SP 800-53といったセキュリティガイドラインです。

これらは文章表現こそ異なりますが、本質的に確認しようとしていることは共通しています。そのため、これらを統一されたフォーマットへと集約することで、既存のバラバラなチェックシートを置き換えられるのではないかと考え始めました。

そこで私たちは、独自のExcelフォーマットを作り、既存のチェックシートを置き換えられるのか試すことにしました。国内外を問わずあらゆるセキュリティガイドラインを読み漁り、セキュリティ専門家の力も借りながらプロトタイプの構築を進めていく中で、いくつかの課題が見えてきました。

例えば、設問を変更した際にその背景や履歴が残らないという点や、文章表現に極めて高い正確性が求められ、誤字脱字も許されないといった点です。また、そもそもExcel自体のレイアウトを整える作業が大変だということがわかってきました。

こうした編集作業の困難さに直面した際、これは本質的に「コード管理」や「デプロイ管理」と同じ課題なのではないかと思いつきました。

そこで、設問やカテゴリの情報を一旦YAMLで管理する形にしました。具体的には、YAMLをGitHubにプッシュすることで、CIによりテキストのLintを実行し、スプレッドシートが自動生成される仕組みを構築しました。

これにより、チェックシートの精度を継続的に向上させることが容易となりました。こうして作り上げたチェックシートを、あるクライアントにご覧いただいたところ「網羅的で分かりやすい」という評価をいただくことができました。

セキュリティと拡張性を両立させる基盤としてのKubernetes

内山：システム化の道筋が見えてきたところで、まずはMVPとして小さく開発をスタートすることにしました。

「Assuredクラウド評価」は、自らが膨大なセキュリティ情報を取り扱うサービスであるため、当初から一定以上のセキュリティ品質を担保することが求められていました。また、システムの利用者としては「クラウドサービス利用企業様」、情報を登録する「クラウド事業者様」、社内で評価を行う「セキュリティエキスパート」という複数の役割が存在します。そのため、それぞれの専用画面を含む、役割ごとに分離されたアプリケーション構成が必要になることは、初期段階から見えていました。

ビジネスの検証結果次第でターゲットユーザーや提供価値が柔軟に変わりえる一方で、土台となる技術基盤には揺るぎない堅牢さが求められていたのです。

そこで我々が選択したのがKubernetesでした。一般的に、新規事業の立ち上げフェーズでKubernetesを採用することは少ないと思います。オーバースペックになりがちですし、学習コストや運用コストの面でオーバーヘッドが大きくなる懸念があるからです。

MVPは必要最小限の価値を提供することに集中すべきフェーズであり、厳密な構成管理までが強く求められる場面は少ないかもしれません。しかし私たちは、Kubernetesが持つ「一度セキュアなクラスターとして構築してしまえば、そのセキュリティが担保された基盤の上でアプリケーションを柔軟に切り替えられる」という特性に着目しました。リソース構成の変更や宣言的なマニフェストによる複数アプリケーションの自由なロールアウト、ノードを含めた自動スケーリングなど、Kubernetesであれば将来的に規模が拡大しても、基盤自体に手を入れることなくシステムを成長させていけると考えたのです。

そして、Assuredという事業特性を鑑みると、MVPの段階からでもこうした機能が一定必要になると判断し、導入することにしました。

当初の技術スタックは、このような形でスタートしています。ここまでの取り組みは弊社のテックブログでも詳細に解説しておりますので、ご興味ある方はぜひご一読いただけるとうれしいです。

ここまでは、事業がいかにして立ち上がってきたかという経緯をお話しいたしました。ここからは、事業の成長に伴いアーキテクチャがどのように進化を遂げてきたのか、その変遷について大橋より発表いたします。

性質の異なる機能への対応と、Cloud Runによる開発アジリティの向上

大橋：「Assuredクラウド評価」では、リリースから様々な機能改善や機能開発を行ってきました。機能開発を進める上で、既存のアプリケーションとはリクエストの系統が異なる、もしくは個別の制約がある開発も出てきました。

例えば、「Assuredクラウド評価」では、従来の独自の質問票による調査結果レポートに加え、提供するレポートの種類を増やしました。具体的には、アプリケーションへの実際のアクセスに基づき、HTTPヘッダやDNSの設定情報などからセキュリティ対策情報を推定し可視化する「ウェブ評価レポート」や、認証情報などの公開情報を集約した「サービス概要レポート」といった、異なる切り口のレポートを提供しています。

ウェブ評価レポートでは多数の外部アプリケーションに対してアクセスした結果の情報を分析するため、想定外の事態が発生したとしても、メインのアプリケーションには影響しないように分離しておく必要がありました。

また、セキュリティ評価機能だけではなく、セキュリティ評価サイクル全体をサポートする機能も開発することになりました。その中でも特に「サービス検知機能」では、ご利用企業の従業員の方がアクセスされたウェブサイトのログを取得するため、評価機能と比較してリクエスト量の大幅増加が見込まれました。そのため、メインのアプリケーションとは別のネットワークで管理する必要性が生じました。またログを効率的にバッファリングする仕組みや高いスケーラビリティを確保するために、軽量なランタイムや言語を選択する必要がありました。

そして、「Assuredクラウド評価」ではクラウドサービス事業者向けにも機能開発をしてきました。例えばAssured以外で受け取ったセキュリティチェックシートに対し、Assured上の回答を元に回答を生成するための「AI回答サポート」という機能を提供しています。AI回答サポートでは過去の回答データを元にLLMが回答を自動生成しています。当時は未知の部分が大きかったLLMを、多層防御の観点でメインのアプリケーションとは分離しておきたいという考えがありました。

これらを解決するために、メインのアプリケーションが動くKubernetesクラスター上ではなく、マネージドサービスを活用してメインのアプリケーションとは別のネットワークやリソース上で動くサブシステムを用途に合わせてそれぞれ構築しました。

そしてアーキテクチャだけではなく、技術スタックも機能によって柔軟に変更し、メインのアプリケーションのScalaだけではなく、GoやPythonも使用するようになりました。

Pull Request単位の検証環境構築でQAフローを最適化

大橋：続けて、QAフローを改善するにあたり、アーキテクチャを変更した件についてお話しします。当時は開発者以外が検証できる環境がステージング環境のみでした。

そのため、開発者以外がQAを実施するには、ステージング環境にマージしてから行う必要があり「不具合を見つけたときにどのPull Request（以下、PR）の影響か特定するのが難しい」「リバート作業などの運用負荷が高い」「マージ前のフィードバックサイクルが回せず開発速度が低下する」といった問題がありました。

そこで、マージ前にPRごとに独立した検証環境を構築することで、早期のフィードバックと開発アジリティの向上を目指しました。

実装にはGitHub Actionsを利用し、PRごとにCloud Runでアプリケーションを立ち上げる仕組みを構築しました。Kubernetesクラスター上にポッドを建てることも検討しましたが、PRごとの検証環境はQA時以外はほぼアクセスがありません。そのため、Cloud Runのスケール・トゥ・ゼロ機能を活用することで、開発体験を損なうことなくインフラコストを最適化できると判断しました。

リクエストがある時のみコンテナを起動し、アイドル時には課金が発生しないため、多数のPR環境を並行稼働させてもインフラコストを抑えられています。Cloud Runでのプレビュー環境作成について、弊社のテックブログで詳細に触れているため、ぜひご一読ください。

Terraformモノレポ化とTerragrunt・Atlantisによるスケーラブルなインフラ管理

大橋：続いて、機能追加だけではなく、委託先の会社のセキュリティ評価を行う新規サービス「Assured企業評価」を立ち上げることになりました。

新規サービスの立ち上げにあたり、私たちはあえて既存のKubernetesクラスターに相乗りする道を選びました。コスト削減というよりは、実績のあるセキュリティや監視の基盤をそのまま踏襲し、立ち上げスピードを最大化させたかったからです。

ただ、インフラを共有するとなると、Terraform側にもこれまで以上のテナント分離やガバナンスが必要となります。そのとき、既存の構造では対応しきれない限界が見えてきました。

マルチプロダクト化を進める上で最初に顕在化した問題は、Terraformリソース定義の分散でした。これまでは、基盤リソースとアプリケーションリソースが既存サービスのリポジトリにあったため、新規サービスから基盤を利用しようとすると、Terraformのデータソースを経由した暗黙的な依存関係が発生していました。これにより、元のシステムで基盤インフラを変更すると、どのサービスが壊れるか予測できなくなり、変更の心理的ハードルが極端に上がっていました。

また、リポジトリが分かれていることでリソースのラベリングルールも形骸化し、コスト管理も難しい状況でした。そこで私たちはインフラの「Single Source of Truth」を確立するために、Terraform専用のモノレポ構成へと移行しました。物理的にコードを一箇所に集めることで、見えなかった依存関係をコードとして明示化し、システム横断での変更影響をコントロール可能な状態へと再構築しました。

TerragruntとAtlantisによる並行開発の安定化

大橋：モノレポ化によってリソースの管理は整理されましたが、スケーラビリティのリスクの懸念が出てきました。システム全体を一つのstateで管理し続けると、リソースが増えるにつれて変更時の影響範囲が肥大化するだけでなく、Terraformの実行がタイムアウトすることが予測されました。

そこで私たちは問題が顕在化する前にアーキテクチャを刷新し、TerraformのラッパーであるTerragruntを導入して、リソースのライフサイクルに基づいてstateを分割する戦略を取りました。

これにより、applyの影響範囲を必要最小限にし、変更時のリスクと確認コストを大幅に削減できました。また、dependencyブロックによりモジュール間の依存関係をコードとして明示的に管理できるようにしたことで、影響範囲がひと目で把握できるようになり、影響調査の属人化も解消されました。結果として、将来的なリソース増大にも耐えうるスケーラブルな構造を実現できました。

モノレポ化とTerragruntの導入によりstateが細分化され、開発アジリティは飛躍的に向上しました。しかし、変更の回転数が上がったことで、今度は並行開発時の競合が新たなボトルネックとして浮上しました。単なるstateのロック競合だけでなく、複数のPRが同時に進行することで発生する先祖返りや意図しないリソース削除といった事故のリスクが高まることが予測されました。

そこでPRのライフサイクルに合わせてplan/applyの自動排他ロックを提供するOSSのAtlantisを導入し、PR単位で対象のモジュールをロックする仕組みを構築しました。Terragruntによるstateの物理分割とAtlantisによる変更の論理ロックを組み合わせることで、互いの作業を阻害せず、かつ安全にデプロイできる並行稼働モデルを実現しました。これにより、組織が拡大してもインフラ変更が渋滞しないスケーラブルな開発体制が整いました。

こうして同一Kubernetesクラスター上にアプリケーションを配置し、ネットワークやクラスターは共用で使いつつも、サービスごとにリソースを管理できるようになりました。

ニアリアルタイム連携からAirbyte・dbtによる信頼性の高いデータ活用へ

大橋：最後に、データ基盤の変遷についても触れていきたいと思います。

「Assuredクラウド評価」では、もともとEmbulkを使用して1日1回メインDBのデータをBigQueryに連携していました。しかし、より早い周期で数値を追いたいというニーズが出てきたため、Datastreamを使用してBigQueryにニアリアルタイムで連携できるようにしました。

そしてデータドリブンな意思決定を加速するため、様々なデータソースの統合が求められるようになりました。例えば、Salesforceにある営業データの連携による顧客インサイトの強化、GitHub MetricsによるDevOps指標の分析などです。また、DatastreamではPostgreSQLのレンジ型に対応できないといった課題もありました。

そこで、SaaS・DBを問わず300以上のデータソースに対応したOSSのELTプラットフォームであるAirbyteを導入しました。豊富なコネクタを活用することで多様なデータソースに対応可能となり、新しいデータソースの追加も簡単になりました。これにより、ビジネスニーズに応じた柔軟なデータ統合が実現できるようになりました。

dbtを活用した多段データレイヤーと品質テストの自動化

大橋：データ活用が進む中で、2つの課題が顕在化しました。

1つ目はセンシティブ情報保護の属人化です。BigQueryのポリシータグ機能を使用してセンシティブ情報を保護していたのですが、タグの付与が手動運用になっていました。このため運用コストが高く、スケールしづらい上に、属人的でタグの付与漏れが発生しやすいという課題がありました。

2つ目はデータの無秩序な拡大です。分析用のビューやアドホッククエリが乱立してしまい、どれが正式なデータなのかがわからない状態となっていました。

これらを解決するために、SQLベースの変換処理をコードとして管理できるdbtによる多段データレイヤーを構築しました。データを多段レイヤーに分けて品質を段階的に高めるデータ設計パターンであるMedallionアーキテクチャの考え方を参考に、dbtを活用してレイヤーごとに責務を分離しています。具体的には、ソース層には生データ、ステージング層にはクレンジング済みのデータ、インターメディエイト層にはセンシティブ情報にポリシータグを付けてマスクし、パーティショニングやクラスタリングを施した分析用データ、そしてマート層にはBIツール向けに集計済みのデータを配置しました。

この結果、ポリシータグ付与を自動化して属人性を排除し、また各レイヤーの責務を明確にすることでデータの管理を効率化できました。しかし、データの信頼性を担保するには、もう1つ重要な要素が必要でした。それがデータ品質の保証です。

データドリブンな意思決定を行う上で、データの信頼性は不可欠です。しかし、既存の基盤ではデータの整合性チェックが属人的で、異常値や欠損値の検知が遅れていました。この課題を解決するために、dbtテストによる自動品質テストを導入しました。具体的にはデータパイプライン内でのデータの欠損チェック、重要なテーブルでの異常な大量削除の検知、ビジネスルール違反のデータの検証です。これらのテストを1日1回定時に実行しています。
この結果、データ品質の問題を継続的に監視でき、信頼性の高いデータ基盤を構築できました。

全体として、データ基盤のマネージドサービスからセルフホストへの移行によって、データの鮮度、信頼性、完全性、ガバナンスを強化し、さらに多くのデータ統合や高度な分析を行える基盤を構築できました。

こうして事業の成長とともに新たに出てくる課題を解決していき、アーキテクチャは変わり続け、現在の姿になりました。

信頼のプラットフォームへ。変わり続けるアーキテクチャが拓く「新しい信頼のカタチ」

内山：ここからは、今後どのようにアーキテクチャを変えていくかという話をできればと思います。

最初に、Assuredが実現したい世界観として、セキュリティ評価における課題をプラットフォームで解決していくというお話をしました。現在の私たちは、その先の世界についても考えるフェーズに突入しています。

私たちは「信頼で、未知を拓く。」をミッションとして掲げています。会社と会社が取引を行う際に、相手企業と金銭的な取引が可能かどうかを判断するための「与信」という仕組みがあります。

企業間の取引において「信頼」は常に重要な決め手となっており、現代においてはセキュリティ評価もまた、この信頼を形作る不可欠な要素の1つだと考えています。私たちはこの「信頼」という物差しを通じて、会社と会社が手を取り合うための情報を提供し、新たなつながりを創出できる世界を実現したいと考えています。

世の中のセキュリティ水準を底上げする「信頼のサイクル」

内山：今までは上図の左側にあるようなクラウドサービス利用企業やその取引先企業の可視化、運用管理、判断の部分を主に提供してきました。今後は、右側にあるような事業者の可視化、改善、情報開示にも力を入れていきたいと考えています。

例えば、事業者様側が「セキュリティを強化することが新たな取引の獲得に直結する」と実感いただくことで、自発的なセキュリティ水準の向上を促したりといった流れを目指しています。

こういったサイクルが回っていくことで、世の中のセキュリティ水準そのものが底上げされていく。私たちは、そのような世界を創り上げていきたいと考えています。

そして、こうした世界観を実現しようと考えると、新たな可能性が見えてきます。例えば、セキュリティ評価によって、特定の課題が明確になったクラウド事業者に対して、自社サービスを守り改善するためのプロダクトを提供するといった展開も考えられます。

そのようなマルチプロダクト化によってアプリケーションそのものが複雑になれば、ドメインごとにマイクロサービス化していく可能性もあります。そうなれば、アプリケーション間の通信はより複雑になり、トレースも困難になるため、サービスメッシュのような技術の導入の検討が必要になるかもしれません。

さらには、サブシステムも性質の異なるコンポーネントが徐々に増えていくことが予想されます。このように、私たちは事業の成長スピードに合わせ、今後もアーキテクチャを進化させ続けていきたいと考えています。

最後に、アシュアードは一緒に役割を越境して、ともに事業をつくっていく仲間を積極的に募集しています。少しでもご興味をお持ちいただけましたら、ぜひ採用サイトをご確認ください。

本セッションは以上となります。ご清聴いただきありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。