株式会社Algomatic様

「セキュリティはスピードを守るためのガードレール」ー急成長中のAlgomaticが実践する、全社横断の脆弱性対策と高速開発の両立

生成AIを活用し、企業の業務・組織・システム変革を支援する株式会社Algomatic。複数の事業やプロジェクトが並行して立ち上がり、最先端のAI技術を活用した開発がハイスピードで立ち上がる同社では、多様なクラウド環境が日々増え続ける中で、脆弱性の全容把握と迅速な対応体制の構築が課題となっていました。

そうした中、インフラ全体を横断したリスクの可視化と、継続的な脆弱性管理の仕組みづくりを支えたのが、脆弱性管理クラウド「yamory」です。コーポレート室の萩原涼介氏に、導入の背景や活用状況、導入後の変化、そして今後の展望について伺いました。

課題

• 複数のクラウド環境で多数のプロジェクトが並行して動く中、脆弱性の影響範囲を横断的に把握しづらかった。
• IT関連業務を兼務する体制の中で、一部のエンジニアに負荷が集中し、セキュリティ対応が後回しになりやすかった。
• 検知した脆弱性への対応経緯や判断理由を、ログとして記録・管理する仕組みが未整備だった。

• 実証コード（PoC）の有無など明確な根拠に基づき、優先的に対応すべきリスクを即座に判別できる点。
• 日本語情報やFAQが充実しており、専門知識が深くなくても理解しやすく運用しやすい点。
• 他ツールの一部機能ではなく、専用ツールとして導入することで、現場全体のセキュリティ意識向上につなげることができる点。

導入後の効果

• 従来は多くの時間と工数を要していた影響調査が、ダッシュボード上で一元管理により迅速に完結できるようになった。

• 社内で脆弱性や最新トレンドに関する会話が増え、チーム全体のセキュリティ感度が向上した。

• 認証取得も見据えた重要施策として位置づけられ、リスク管理状況を経営層に可視化・共有しやすくなった。

萩原氏：
私は現在、株式会社Algomaticのコーポレート室という部署に所属しています。当社は、生成AIを活用し、企業の業務・組織・システムの変革を支援しているスタートアップです。コンサルティングや施策開発を通じて、さまざまな企業のAI活用を推進しています。

私自身はコーポレートエンジニアとして、主なコーポレートITとセキュリティ領域を担当しています。日々のIT基盤の整備や運用に加えて、情報セキュリティの強化も担っており、幅広い領域を兼務しながら、効率的にセキュリティ対策を推進しています。
 

萩原氏：
業務環境は、ほぼ全てクラウドで運用しています。複数の主要なクラウドサービスを利用しており、その中で多くのプロジェクトが並行して動いています。

当社では各本部ごとに、お客様ごとの案件を多数抱えているため、管理対象となるアセット数も非常に多くなっています。その結果、全体像を横断的に把握することが難しいというのが正直なところでした。また、お客様の状況によっては、Algomaticの環境をそのままご利用いただくケースもあります。そうした中で、私のようなセキュリティ担当者が手動で全てを把握し、リスクを管理し続けるのは、かなり難しい状況でした。
 

萩原氏：
当社のように複数事業やプロジェクトが並行して進む環境では、セキュリティは事業スピードを支える基盤だと考えています。新しい取り組みを安心して進めるためにも、リスクを早く把握し、適切にコントロールできる環境が大切です。その一方で、導入前は新しい脆弱性やサプライチェーンリスクの情報が出てきた際に、「それが当社に関係するものなのか」「どの程度優先して対応すべきなのか」、「すでに自動で対処されているものなのか」といった判断材料をすぐに整理しづらいことが課題でした。

例えば、特定のクラウドサービスで脆弱性情報が公開された場合でも、各担当者がその情報を認識しているのか、対応方針に迷っていないかを、私自身が横断的に把握することが難しい状況でした。社内からも課題意識が上がっており、お客様のためにも、自社を守るためにも、「対応が必要なものに対して確実にアクションを起こし、その判断や対応履歴を正しく記録できる仕組みを整えるべきだ」という声が強くなっていました。
 

萩原氏：
幸いにも具体的な被害が発生したわけではありませんでしたが、社内に「本当にこのままで大丈夫だろうか」という漠然とした不安感があったと思います。

当時はセキュリティチームとして構成情報を一元的に管理できていたわけではなく、本来であれば脆弱性情報が出るたびに対象を突き合わせて、適切な担当者にアサインしていくのが理想でした。ただ、それを人手で回していく中で、本当に漏れなく拾えているのかについては、正直全く自信が持てませんでした。また、「脆弱性対応を進めた方が良い」と声を上げると、どうしても特定のエンジニアに負荷が集中しやすくなりますし、納期が厳しい中では「今すぐ対応すべきなのか」と判断が後回しにされることもありました。そうした状況を見ていて、個人の頑張りに依存するのではなく、自然と正しい対応が回る仕組みを作る必要があると感じていました。
 

萩原氏：
元々は別件で、アシュアード社のセキュリティチェックシート関連の業務を効率化するために「Assuredクラウド評価」の導入を検討していました。その流れの中で、上司から「脆弱性管理ツールも提供している」と紹介されたのが、「yamory」を知ったきっかけです。実際に情報を見た時に、「もしかするとこちらの方を先に導入したいかもしれない」と感じたのを覚えています。

特に魅力に感じたのは、単に脆弱性を検知できるだけではなく、実証コード（PoC）の有無や、具体的にどう対応すべきかといったレポートが非常に充実していた点です。中でも大きかったのは、一定の根拠に基づいて対応の優先順位を自動で付けてくれるオートトリアージ機能でした。正直、脆弱性対応において「これは本当に今すぐ対応すべきか」という判断に多くの時間をかけたくないという思いがありました。そうした中で、緊急の高いものから優先的に対応するという判断基準をチーム全体で持てることは、運用面でも文化づくりの面でも非常に大きいと感じました。また、国産ツールであることも安心材料でした。脆弱性情報が日本語で整理されているので、現場で理解しやすく、すぐにアクションにつなげやすい点が大きな決め手でした。
 

オートトリアージ機能

萩原氏：
ソースコード管理ツールに標準搭載されている機能や、海外製のセキュリティツールなども一通り確認しました。ただ、機能としては十分でも、実際に運用していくことを考えると管理負荷がかなり大そうだという印象を受けました。

特にUIの見やすさや使いやすさという点では、「yamory」が圧倒的に優れていると感じました。そのため、本格的に細かいコスト比較をするというよりは、「どうやってyamoryを導入するか」という前提で社内稟議を進めていった部分があります。

当社のように限られたリソースを効率的に活用しなければならない環境では、全てを中央集権的に管理をすることが必ずしも最適解ではないと考えています。むしろ、各チームや担当者が主体的にセキュリティを推進できる体制を作ることが重要です。その意味で、「yamory」は単なる管理ツールではなく、組織全体のセキュリティ意識や行動を後押しする存在になり得ると感じました。そうした点を強く打ち出しながら、社内で導入を進めていきました。
 

萩原氏：
現場のエンジニアからはかなり率直な意見が上がりました。例えば、「自分たちの負荷が増えるのではないか」「全社としてどう対応するのかガイドラインはあるのか」「既存の機能で十分ではないか」といった問いです。

ただ、私自身が伝えたのは、「状況に応じて柔軟に対応を変えられることこそ、スピードを守る上で重要だ」ということでした。セキュリティが開発のブレーキになるべきではないと考えているので、そのためのガードレールとして「yamory」を導入したいと説明しました。例えば、緊急度の高い脆弱性が見つかったとしても、明確な理由があってすぐにアップデートしないのであれば、その判断をきちんと記録に残せばよい。そういう柔軟な運用ができることが重要だと考えています。

また、他のツールの一部機能として脆弱性情報が表示されるだけではなく、専用ツールとして通知が届く環境を作ること自体が、エンジニア一人ひとりのセキュリティ意識を高める上でも非常に有効だと捉えています。
 

萩原氏：
現在は、アプリケーションのライブラリスキャン機能を中心に活用しています。各リポジトリに組み込み、利用しているライブラリの脆弱性を継続的にスキャンできる体制を整えています。ソースコード管理ツールとも連携しており、現時点では特に大きな問題なく運用できています。
これによって、各プロジェクトごとの状況を把握しながら、必要な対応をスムーズに進められるようになりました。一方で、コンテナイメージやクラウド環境のスキャンについては、これから段階的に広げていきたいと考えています。まずはライブラリ管理の基盤を整えた上で、対象範囲を広げていくイメージです。
 

萩原氏：
当社はいくつかの本部に分かれて組織が動いているため、新しいリポジトリを作る際には「yamory」を導入するよう、各本部に私から声をかけながら導入を進めています。

ポジティブな変化として最も大きいのは、社内全体で脆弱性への感度が明らかに高まったことです。例えば、「こういう脆弱性があるらしい」といった情報共有が自然に行われるようになりましたし、最近世の中で話題になった大きなセキュリティインシデントについても、社内で活発に話題に上がるようになりました。おもしろいのは、自社で直接使っていない技術に関する話題であっても、「それってどういう影響があるんだろう」と自然に関心が向くようになったことです。こうした変化は「yamory」を導入した成果の一つだと感じています。

もちろん、まだ全ての部門で理想的な状態を作れているわけではありません。ただ少なくとも、「セキュリティは日々の開発の中で考慮すべきものだ」という認識が現場に根付き始めています。その中で、アプリケーションライブラリの脆弱性も重要な論点の一つとして捉えられるようになり、現場のエンジニアが自分たちで考え、体制を整えようと主体的に動き始めているケースも出てきています。まさに当初目指していた、現場主導でセキュリティ意識が高まる土壌が育ち始めていると感じています。
 

萩原氏：
脆弱性リスクが当社に影響を及ぼしているかどうかの把握スピードは明らかに上がりました。これまでは確認しようとするだけでも膨大な時間がかかり、複数のエンジニアの手を借りながら調査する必要がありましたが、今では「yamory」のダッシュボードを見れば、一目で状況を把握できる状態になっています。これまで見えていなかったリスクが可視化されたことはもちろんですが、新たに認識したリスクが本当に自社に影響するものなのか、その判断スピードも大きく向上したと感じています。
 

ダッシュボードのサンプルイメージ
 

また、現場をリードするシニアエンジニアからも、「これは本当に良いツールだし、しっかり活用していくべきだ」といった声が上がるようになりました。そうしたメンバーが社内で啓蒙役になってくれているのは、とても大きいですね。ジュニアなエンジニアにとっても、脆弱性や対応の考え方を学ぶための実践的な教材のような役割を果たしていて、教育・トレーニングの観点でも良い効果が出ているとも感じています。

さらに経営陣に対しても、今後、ISMS認証の取得などを見据える中で、非常に重要な施策として認識を得られています。セキュリティ環境が日々変化する中で、「経営からの投資によって、現在のリスクをここまでコントロールできています」と明確に報告できる状態を作れていることは、非常に大きな前進だと思っています。
 

萩原氏：
「yamory」はFAQやドキュメントも含めて情報が充実していて、日々助けられている部分が多いです。一方で、そうした情報が揃っているからといって、「あとで読んで対応してください」とするだけでは、なかなか組織に定着しないとも感じています。だからこそ今後は、単にツールを入れるだけではなく、それをどう組織に浸透させ、文化として根付かせていくかをより意識していきたいですね。

組織体制もようやく落ち着いてきたので、今後は「yamory」のカスタマーサクセス（CS）チームの皆様にも伴走いただきながら、導入直後の担当者でも迷わず使えるような運用テンプレートのようなものを整備していきたいと考えています。そうした仕組みを整えることで、各チームがより主体的にセキュリティ対応を進められる状態を作り、社内全体での浸透を加速させていきたいです。
 

萩原氏：
「yamory」をおすすめするとしたら、単にシステム上の脆弱性を管理・解決するためのツールとしてではなく、「組織全体にセキュリティ意識を根付かせ、組織そのものを強くしていくためのツール」としてお伝えしたいです。

日本語に対応した分かりやすいUI/UX、充実した情報量、そしてサポートチームの手厚い伴走による安心感は非常に大きいと感じています。セキュリティという領域は、「自社は本当に大丈夫だ」と言い切るための材料を見つけるのが難しい分野です。だからこそ、見えていないリスクがあること自体が不安につながりやすいと思います。

その点、「yamory」を活用することで、そうした不安を可視化し、「ここにリスクがあるから早めに対応しよう」と前向きに動ける状態を作ることができます。特に、セキュリティに十分な人手を割けないチームほど、早い段階で「yamory」を導入し、現場と一緒にセキュリティ文化を育てていくことが重要なのではないかと思います。