株式会社フォトクリエイト様

脆弱性管理を重要な経営テーマとして全社で推進―脆弱性対応を高度化し、半年で組織の標準運用へ

株式会社フォトクリエイトは、スクール写真やマラソンをはじめとするスポーツイベントなど、さまざまな領域で写真の撮影・販売サービスを展開しています。写真販売サイトや関連システムをクラウド環境で運用する同社にとって、アプリケーション、クラウドインフラ、ホスト、コンテナなどを横断して脆弱性を管理することは、サービスの信頼性を維持するための重要なテーマです。また、AIコーディング支援の活用によって開発量が増えるなか、依存ライブラリを継続的に把握・管理できる仕組みも求められていました。

本インタビューでは、同社の開発部長を務める林氏に、各開発チームで進めていた脆弱性管理を、yamoryによってどのように標準化し、組織的な運用として定着させたのかをお聞きしました。会社として重要なプロジェクトに位置づけた背景や、本格運用から約半年で、リスクの高いものから対応を大きく前進させた要因、開発者が主体的に対応できるようになった組織の変化について伺いました。

課題

• DependabotやRenovateを活用して依存ライブラリの脆弱性対応に取り組む一方、アプリケーションからクラウドインフラ、ホスト、コンテナ、EOLまでを一元的に管理し、共通の基準で運用する体制へ高度化することが次のテーマだった。
• 検知された脆弱性の優先順位づけを各チームが個別に判断しており、事業やシステムへの影響を踏まえた共通の判断基準を持つ必要があった。
• AIコーディング支援の活用によって開発量や依存ライブラリが増えるなか、構成や脆弱性を継続的に把握・管理する重要性が高まっていた。

• オートトリアージ機能によって対応優先度が整理され、外部の依存ライブラリに対して日々新たに発見される脆弱性の中で、たとえ多数の脆弱性が同時に検知された場合でも、リスクの高いものから対応しやすい点。
• Immediate（最優先に対応すべき脆弱性）に分類されたものを絞り込めることに加え、米国CISAのKEVカタログへの掲載有無や、リモートコード実行が可能かといった情報を確認し、影響の大きい脆弱性を優先できる点。
• 脆弱性の概要や影響、対策方法が分かりやすい日本語で整理されており、シンプルなUIで現場のエンジニアも理解しやすい点。
• アプリケーションライブラリ、クラウドインフラ、ホスト、コンテナ、EOLまでを一元管理でき、API連携やスキャン設定を自社の運用に合わせてカスタマイズできる点。

導入後の効果

• 会社として重要なプロジェクトに位置づけ、本格運用から約半年で、優先度の高い脆弱性について最短ですべて対応を完了できるようになった 。

• 脆弱性対応を各開発チーム個別の判断に委ねるのではなく、各開発チーム、マネージャー、部長、取締役が状況を共有し、リスクの高いものから継続的に解消する組織的な運用が定着した。

• APIを活用したタスク管理ツールへの自動登録やSlackへの通知、MCPサーバーを介したClaude Codeからの情報参照により、脆弱性管理を既存の開発フローに組み込んだ。

林氏：
私は開発部長として、部内の組織運営と各開発チームのマネジメントを担っています。開発部は、当社の各事業・プロダクトに関わるシステム開発を担当しています。

当社は、スクール写真や、マラソンをはじめとするスポーツイベントの写真など、さまざまな領域で撮影・販売サービスを展開しています。これらの写真販売サイトや関連システムを、クラウド環境で運用しています。
 

林氏：
導入前からDependabotやRenovateなどを活用し、依存ライブラリの更新や脆弱性対応は継続して行っていました。各開発チームがそれぞれの担当領域で自律的に運用しており、対応そのものは回っていた一方で、進め方や管理方法は開発チームごとに最適化された状態でした。そこでさらに組織的な対応水準を上げるために、アプリケーションだけでなく、AWS、ホスト、コンテナ、EOLまでを組織横断で一元的に把握し、共通の基準に揃えることで運用を高度化することを目指しました。 

また、AIコーディング支援の活用によって開発量が増えるなか、利用する依存ライブラリの種類や更新機会も増えていきます。開発生産性を高めながら、ソフトウェア構成と脆弱性を継続的に把握できる仕組みを整える必要がありました。
 

開発部 部長　林 氏

林氏：
効率的な脆弱性管理を実現するためにどのようなツールがあるかを調査していた際、経済産業省が発行している「ソフトウェア管理に向けたSBOMの導入に関する手引」のドキュメントを拝見し、そこに「yamory」が掲載されていたのが最初のきっかけです。

また、脆弱性管理について検索していた際にも上位に挙がるツールであったため、サービス名自体は以前からよく認知していました。そのため、組織横断での管理体制へ高度化するにあたり、有力な候補となりました。

林氏：
複数の製品・サービスを比較し、当社の運用に適合するかを検証しました。外部の依存ライブラリやクラウドインフラなどに対して、日々新たに発見される脆弱性を効率的に管理できる必要がありました。特に重視したのは、多数の脆弱性が検知された場合でも、事業やシステムへの影響を踏まえて優先順位を判断し、実際の対応につなげやすいことでした。

最も評価したのは、オートトリアージ機能です。多数の脆弱性が検知された場合でも、リスクに応じて優先度が整理されるため、どこから対応すべきかを判断しやすくなります。

特に、Immediate（最優先に対応すべき脆弱性）に分類されたものを絞り込めることに加え、米国CISAのKEVカタログへの掲載有無や、リモートコード実行が可能かといった情報を確認できる点は実用的でした。影響が大きく、早急な対応が必要な脆弱性を素早く特定できるため、限られたリソースでもリスクの高いものから優先して対応できます。すべてを同じ優先度で扱うのではなく、影響の大きいものを見極めやすい点が、実際の運用に適していると感じました。
 

オートトリアージ機能

日本語での表記

林氏：
日々の運用を通じて、シンプルで使いやすいツールだと感じています。当社では、GitHubで管理するアプリケーションの依存ライブラリに加え、AWS、ホスト、コンテナ、EOLの管理まで幅広く活用しています。

使いやすさに加えて、APIやスキャン設定の柔軟性も評価しています。当社では、「yamory」で検知した脆弱性をタスク管理ツールへ自動登録する仕組みや、リスクの高い脆弱性をSlackへ通知する仕組みを構築し、検知から通知・タスク化までの流れを効率化しています。
スキャンのタイミングや対象も自社の運用に合わせて調整できるため、単に導入しやすいだけでなく、既存の開発プロセスに合わせて運用を作り込める点も魅力です。
 

林氏：
最も大きな変化は、脆弱性管理が各チーム個別の判断ではなく、開発部として組織的に取り組む運用として定着したことです。各チームが担当するプロダクトやリポジトリの脆弱性を確認し、優先順位に沿って対応しています。

セキュリティを専門としていないエンジニアも、「yamory」の解説を読みながら対応を進めることで、脆弱性の内容や影響を理解しやすくなりました。メンバー間で共通の用語を使って議論できるようになるなど、開発部全体のセキュリティに関する知識が底上げされたと感じています。

また、開発を管掌する取締役にもアカウントを発行しており、必要に応じて「yamory」のダッシュボードを確認できるようにしています。リスクの推移や対応状況を同じ画面で共有できるため、対応が滞っている場合にも組織としてフォローできます。私自身も、社内の関係者へ状況を説明するための情報を整理しやすくなり、報告にかかる負担が軽減されました。
 

ダッシュボードのサンプルイメージ（画面および数値は「yamory」提供のサンプル）

林氏：
まず前提として、脆弱性は日々新たに公開されるため、どの組織でも常にゼロを維持することは現実的には不可能です。だからこそ、オートトリアージで優先度を整理した上で、リスクの高いものから順に対応しています。それ以外の項目についても、影響範囲の評価と対応方針の判断は完了しており、優先順位に沿って順次対応を進めています。
また、セキュリティ対策は単一の手段に依存せず、WAFによる防御など多層的な仕組みと組み合わせて運用しています。脆弱性の解消はその一つの層であり、優先度の高いものから確実に解消しながら、全体としてリスクを抑える設計にしています。

そのうえで、脆弱性対応を各チームだけに委ねず、会社として重要なプロジェクトに位置づけたことが大きかったと考えています。必要なリソースを確保したうえで、開発部全体で組織的に進めました。

また、重大な脆弱性が検知された場合には、進行中の他のプロジェクトよりも優先して対応する方針を明確にしました。脆弱性対応を「品質を高めるフェーズで行うもの」ではなく、事業継続とお客様からの信頼を支えるために優先すべき取り組みと位置づけたことが、短期間での解消につながったと考えています。
導入初期には、「yamory」のカスタマーサクセスチームに、各チームのリーダーやマネジメント層を交えたオンボーディングを複数回実施していただきました。導入状況や運用上の課題を定期的に一緒に確認できたことで、各チームの運用定着に向けた意識を維持しながら、開発部全体への展開を進めることができました。
運用を続ける中で、外部リスクへの対応の速さにも信頼を感じています。OSSのコンテナスキャンツール「Trivy」の公式配布経路に関するセキュリティリスクが公表された際には、安全性を検証したバイナリを利用できる体制が迅速に整えられました。外部OSSに新たなリスクが生じた場合にも、安心して「yamory」の運用を継続できるよう具体的な対策が速やかに講じられたことは、大きな安心材料になっています。
 

林氏：
現在は、「yamory」を活用した脆弱性管理が、開発部の標準的な運用として定着しています。今後も、アプリケーション、クラウドインフラ、ホスト、コンテナ、EOLを継続的に把握し、リスクの高い脆弱性を速やかに特定・対応できる体制を維持していきます。
また、AI活用によって開発スピードが高まるなかでも、開発生産性の向上とセキュリティ改善を両立できるプロセスを、さらに整備していきたいと考えています。
 

林氏：
まずは一度「yamory」でスキャンし、現在の状況を一元的に把握することをおすすめします。これまで別々に管理していた項目がまとめて並ぶため、幅広く網羅的に実態をとらえられます。現状のリスクを組織内で共有し、今後の対応方針を考えるための有効なきっかけになります。システムの健康診断のようなものだと考えています。

「yamory」の大きな強みは、検知した後に対応すべき優先順位が明確になることです。すべての脆弱性を常にゼロにし続けることは現実的には難しいからこそ、リスクの高いものを素早く特定し、優先順位をつけて対応できることが重要です。
当社では、すべてを一度に解消しようとするのではなく、リスクの高いものから着実に対応することで、無理なく効果的に脆弱性を管理し、解消を進められる運用が定着しました。脆弱性管理を個人任せにせず、組織として継続的に取り組むためにも、まずは現状を一元的に把握し、対応の優先順位を共有するところから始めることをおすすめします。