この記事でわかること
-
エンタープライズ顧客のセキュリティ要件を判断する実践的なアプローチ
-
「開発フローを止めない」セキュリティ施策
-
「要件通り」より「目的達成」で合意を取る代替案提示のコツ
エンタープライズ向けサービスの開発において、「セキュリティ要件が開発の足かせになる」という課題は多くの現場で指摘されています。特に成長期のスタートアップでは、限られたリソースの中でエンタープライズ顧客の厳しいセキュリティ要件にどう対応すべきか、現実的な解決策が求められています。
大規模言語モデル（LLM）を活用したプロダクト及びソリューションを提供する株式会社ELYZAで情報セキュリティを担当する馬場匠見氏は、エンジニア出身の視点を活かし、開発現場を理解したセキュリティ対応を推進しています。
本記事では、馬場氏へのインタビューを通じて、開発生産性を維持しながらエンタープライズ顧客の信頼を獲得する現実的なアプローチをお伝えします。
株式会社ELYZA
2018年9月創業。LLMの研究開発から、LLMを活用した業務支援プロダクト・ソリューションまで幅広く手がける。エンタープライズ顧客への導入実績も豊富で、セキュリティ要件への対応にも積極的に取り組んでいる。
【会社URL】：株式会社ELYZA
【サービスURL】：ELYZA Works｜法人向け生成AI活用ツール
馬場 匠見
株式会社ELYZA 情報セキュリティ担当 慶應SFC増井研究室修士課程修了。未踏事業採択。企業研究所にて研究開発、スタートアップにて新規営業支援B2B SaaSの開発を経て現職。エンジニア出身の強みを活かし、開発現場の視点でセキュリティ対応を推進している。
【X（旧Twitter）】：https://x.com/TakumiBaba
目次
大企業とスタートアップ、両方を知るからこそ見える「今、対応すべきセキュリティ要件」
まず、ELYZA社での馬場さんのお仕事について教えてください。
弊社はLLMの研究開発からDXソリューションの提供、プロダクト化までを一貫して手掛ける企業であり、私は情報セキュリティ全般を担当しています｡
弊社がLLMを研究し始めたのは2019年ですが、その頃より、エンタープライズのお客様に対してDXソリューションを提供してきました。最近はLLMの認知の高まりを受けて、今まで以上に幅広いお客様からお問い合わせをいただくことが増えましたが、引き続きエンタープライズのお客様も多くいらっしゃり、セキュリティ要件としても、エンタープライズ企業のお客様が求める水準を満たすことが求められます。
また、エンタープライズのお客様が求めるセキュリティ要件に対しては、直球的な対応だけでなく、要件の裏にある目的を汲み取り、多層防御や代替案を組み合わせた現実的なアプローチで応えることが多くなっています。
これまでのご経験が、現在のエンタープライズ対応業務にどのように活かされていますか？
今までのキャリアにおいて大企業とスタートアップの両方を経験したことが、今の仕事に大きく活かされています。新卒では大企業の研究組織に入り、その後はスタートアップで初期メンバーのエンジニアとして働きました。
この経験のおかげで、エンタープライズ向け製品に求められる機能の必要性を肌で理解できています。例えば、SSO（シングルサインオン）やログ機能は、スタートアップの視点だけだと「少ないリソースを調整する観点で、本当にそこまで必要？」と疑問に思うかもしれませんが、大規模組織では管理コストを考えると必須の機能です。このように、大規模組織において求められるセキュリティ水準を理解し、その前提に立って設計・提案をすることで、エンタープライズのお客様と共通言語を持って対話できると感じています。
確かに、スタートアップでは「自分たちで工夫すれば済む」と思いがちな機能も、大規模組織では管理の観点から必須になりますね。その両方を経験されているからこそ、お客様の要望の背景が理解できるということでしょうか。
そうですね。大企業の基準を経験を以て理解していることもありますが、それに加えて、お客様との対話の重要性を理解しているのも、また重要な点だと考えています。また、前職ではソフトウェアエンジニアをやりながら、カスタマーサポートとしてお客様と直接お話しする機会が多かったんです。自分が作ったプロダクトを提供して、実際に使っている方々から直接ご意見をいただく中で、ユーザビリティの改善点や操作方法について貴重なフィードバックをいただきました。
そういった経験から、エンジニアの立場であっても、開発だけしていればいいというわけではなく、お客様との対話を欠かさず行い、またいただいたフィードバックは反映するなど、やれることは何でもやらないとプロダクト開発はうまくいかないということを学びました。この経験は、現在のエンタープライズ対応の姿勢にも繋がっていると感じています。
業界で変わるセキュリティ要件 ―「法規制」「業界ガイドライン」に基づき多角的に判断を実施
エンタープライズ顧客から実際に求められるセキュリティ要件で、「これは絶対に外せない」というものと「交渉の余地がある」ものは、どのように見極めていますか？
業界ごとに多種多様で一概には定まらないところがあります。ただ、確実に外せない要件は、法規制・業界ガイドラインです。これらに未対応である場合、商談自体が成立しなくなってしまうこともあります｡それ以外にも、社内規定によって方針が定められている企業もあります。
ただ、法規制・業界ガイドライン等は業界等によって全然違うんですね。例えば、金融業界であれば取り扱う顧客情報の機密性から一般に公開されているデータを主に扱う業界とは求められる基準が格段に上がります。
業界や事業内容によって大きく変わるということですが、実際にどのように見極めを行っているのですか？
セキュリティチームだけでこの見極めをすることは困難です。各業界の専門知識を持っている人に手助けしてもらいながら見極めていくことが必要です。
弊社のセキュリティチームは私を含む2名体制ですが、だからこそフットワーク軽く関係者にヒアリングできる強みがあります。ビジネス側のメンバーと密に相談したり、お客様にヒアリングを実施したりして、多角的に情報を集めています。こうしたチーム連携により、より適切な判断ができますし、実装時にも明確な方針を持って進められます。
具体的にはどのような体制で顧客対応をされているのですか？
商談は基本的にビジネスメンバーが担当し、私はセキュリティシートでの回答や必要に応じたミーティング参加でサポートしています。セキュリティ関連の質問は私が回答しますが、業界特有の背景や顧客事情については、ビジネス側と密に連携して適切な判断を心がけています。
優先度の判断に迷うケースで、よくある例があれば教えてください。
例えば、IPアドレス制限機能（特定のネットワークからのみアクセスを許可する機能）は、エンタープライズ向けによく求められる機能です。しかし、これが「絶対に必要」なのか「あったら嬉しい」程度なのかは、お客様によって異なります。
こうした判断は、セキュリティチーム単独では難しいため、お客様やビジネスメンバーと話して「お客様にとってどの程度重要ですか？」「代替手段でも問題ありませんか？」という風に情報を収集し、最終的に優先度を決めています。
顧客との対話を通してインサイトを探り、「多層防御」で顧客要件を満たす
顧客から要求された要件に対して、技術的・コスト的に対応が困難な場合、どのように代替案を提示されていますか？
要望通りの対応ができない場合は確かにありますが、重要なのは自分たちが提供できる方法で、お客様が求めている水準と同等のセキュリティレベルを実現できることを示すことです。そのプロセスを通じて合意を取ることを重視しています。
多くの場合、要件を掘り下げていくと「このデータを絶対に守りたい」「法的に満たさなければいけない基準がある」「社内規定でこうしなければいけない」といったインサイト（根本的な目的）が見えてきます。重要なことは、そうしたお客様の目的は通常、単一の対策だけで達成されているわけではないということです。
具体的にはどのようなアプローチを取られているのですか？
多層的な防御施策を組み合わせることで、確実に保護できる状態を作ります。「基本的な防御策に加えて、さらに複数の追加対策も実施しているので、総合的には求められている水準と同等のセキュリティを実現できています」ということを、お客様との対話の中で具体的に説明し、理解していただくことが重要です。
なるほど。こうした多層防御は、商談の時に急遽準備するものではないということですね。
その通りです。多層防御は普段からの積み重ねが前提です。日頃から開発や運用における基礎的なセキュリティ対策を着実に積み重ねておき、「これなら同等レベルの保護ができている」と自信を持って説明できる状態を作っておくことが、代替案提示の基盤になります。
開発スピードとセキュリティを両立させる「自動化」と「シフトレフト」の実践
セキュリティ要件を満たしながら開発スピードを落とさないために、どのような工夫や仕組みを心がけていますか？
セキュリティ施策を本格導入する場合は、レビュープロセスを仕組み化することで自動でチェックされる体制を構築することを目指しています。これが開発スピードをできるだけ落とさないことに繋がると考えています。具体的には、開発者が特別な手順を意識することなく、通常の開発からデプロイまでの流れの中で自然とセキュリティ関連の施策やチェックが行われている状態を作ることです。例えば、CI/CD（※1）の中でセキュリティチェックを回しておくといったことをやっています。
※1 CI/CD：継続的インテグレーション/継続的デプロイメントの略。コードの変更を自動的にテスト・ビルド・デプロイする仕組み
セキュリティ施策の導入前に、試験的な検証もしていますか？
はい、新しいセキュリティ施策を検討する際は、まず試験的に手動で実施して開発チームからフィードバックをもらいます。「こういうチェックを考えているんですが、どうでしょう？」という形で感想を聞いて、効果が確認できれば自動化を進めていきます。
いきなりシステムに組み込むのではなく、段階的に進められるのは開発現場にとってもありがたいですね。では、自動化が難しい場合はどのように対応されていますか？
その場合は、できる限り今までのフローに乗るような形で組み込みます。チェックポイントが一つ増える程度に留めて、既存のワークフローの延長線上で、標準的な手順に従えば運用が回るという形に落ち着かせます。
なぜこのアプローチを取るかというと、新しいツールやワークフローを追加することを極力避けたいからです。新しいツールを一つ導入するだけで、開発者が気にしなければいけない要素が格段に増えてしまいます。そうなると、忘れたりミスしたりすることが多くなるので、本当に意味があるものでない限り、既存の仕組みを拡張する方向で対応した方がいいと思います。
なるほど、既存システムを最大限活用する現実的なアプローチですね。一方で、開発プロセスの上流から対策することも重要だと思うのですが、設計段階で後戻りを避けるために気をつけているポイントはありますか？
はい、私たちは「シフトレフト」という考え方を重視しています。開発の工程は要件定義から始まって設計、実装、テスト、運用という順序で流れていきますが、この工程のなるべく早い段階（設計段階や要件定義の段階）からセキュリティ施策を組み込んで、早期にセキュリティ上の問題や脆弱な箇所を見つけて、なるべく早い段階で直しましょうという考え方です。
弊社でも、設計段階からセキュリティチームによる設計レビュー等の施策を実施しています。これにより実装後に大きな修正が必要になるリスクを減らせています。
早期のセキュリティレビューは、他部署にとってもメリットがありますか？
設計の早い段階からセキュリティチェックが済んでいることで、関係者の安心感は確実に向上していると思います。「後から大きな問題が発覚するリスクが減った」「安心して開発を進められるようになった」という声も社内から上がっています。開発チーム側にとって、途中で大幅な設計変更を求められる心配が減るので、集中して開発に取り組めるというメリットがあります。
エンジニア経験を生かした開発チームとの信頼関係の構築
開発チームから「セキュリティ要件の実装が大変だ」という声が上がった時、どのようにバランスを取って解決されていますか？
その場合は、開発チームと一緒に「どういう実装方法なら現実的か」を検討するようにしています。私自身も同じプロジェクトの一員として、必要な施策を一緒に実現していく立場なので、対立するのではなく、協力して合理的な解決策を見つけることを重視しています。
こうした検討を通じてお互いの理解が深まります。開発者にとっては、施策の意味や目的をしっかり理解できるメリットがありますし、私にとっても、開発者から提案された複数の実装案を比較検討することで、より合理的な方法を見つけることができます。
エンジニア出身だからこそできる、開発チームとのコミュニケーション方法があれば教えてください。
お願いしていることが実装面でどれくらい大変で、どれだけチャレンジングなのかを肌感覚で理解できるのは、非常に重要だと思っています。 例えば、「これは1週間程度の作業量だな」とか「この実装は技術的に難易度が高そうだな」といった見積もりができるので、大変な案件ほど積極的に設計段階からフォローに入ったり、定期的に情報共有したりして、適切なタイミングでサポートできます。
開発側の知識があることで、プロジェクトの難易度やスケジュール感を正確に把握できるのは大きなアドバンテージですね。開発チームとの日常的なコミュニケーションはどのように行っていますか？
プロダクト開発チームの毎日の定例会議に継続して参加して、コミュニケーションを取り続けています。セキュリティ関連で悩み事があればすぐに相談してもらえますし、ちょっとした疑問でも気軽に声をかけてもらえる関係を作っています。
正直なところ、私自身が開発の状況を知りたくて参加している面が大きいんですが（笑）、そういう日常的なコミュニケーションを通じて、いつでも気軽に相談できる関係を築くことを大切にしています。
セキュリティ要件の「厳格化」より「変化」に注目すべき
今後、エンタープライズ向けのセキュリティ要件はさらに厳しくなると予想されますが、開発現場はどのように対応していくべきだと考えますか？
厳しくなる要件に後追いで対応するという発想よりも、常に変化し続ける要件に合わせて自分たちも変化していく姿勢の方が重要だと思います。 変化は必ずしも「厳しくなる」だけではありません。自分たちの事業も進化していて、攻める市場やターゲット顧客が変われば、求められるセキュリティ対策も変わります。そうした事業の変化に合わせて、セキュリティ対応も柔軟に調整していく必要があります。
技術の変化による影響についてはいかがですか？
技術革新は、市場構造を根本から変え、求められるセキュリティ要件も大きく変化させます。LLMの登場が良い例ですね。市場が大きく変わり、従来とは全く異なるセキュリティ要件が生まれました。こうした技術革新に対して、いち早く市場や要件の変化を捉えて対応できる組織の方が競争力を維持できると思います。
こうした流れについていけない事業者も多いので、急激な変化への「対応力」こそが長期的な勝ち筋になると考えています。
これからエンタープライズ対応に携わるエンジニアの方に向けて、アドバイスをお願いします。
最も重要なのは顧客理解です。どんなお客様を相手にしているのか、どんなセキュリティレベルを求めているのか、どの業界の方なのか。ドメイン知識がないと適切なセキュリティ対応はできません。
情報収集の手段は、チームメンバーへの聞き取り、セキュリティシート、商談参加など様々ありますが、重要なのは「お客様が何を求めているのか」「自分たちに何ができるのか」「ギャップをどう埋めるか」の解像度を上げることです。
馬場さんのお話を通じて、セキュリティと開発生産性は対立するものではなく、エンジニア視点での現実的なアプローチがあることがよくわかりました。
限られたリソースでも、エンジニア経験を活かして開発現場を理解し、顧客要件の本質を捉えることで、効果的なセキュリティ対応は実現できます。自動化と既存フローの活用、多層防御による目的達成、そして変化への適応力を組み合わせることで、持続可能なエンタープライズ対応が可能になると思います。
ライター
