2025年、AWSが発表した「2025 Japan AWS Ambassadors」および「2025 Japan AWS Top Engineers（Security）」に、富士ソフト株式会社の川西 就が選出されました。「2024 Japan AWS Top Engineers （Services）」に続き、Japan AWS Top Engineersとしては2年連続の受賞です。
連続受賞の背景には、エンジニアとしての技術や知識にとどまらず、“運用や体制を含めた面で捉えるセキュリティ”にこだわる姿勢があります。本コラムでは、セキュリティを“点”ではなく“面”で捉える視点、生成AI導入時に見落としがちなクラウド環境でのリスク等を紹介します。
受賞につながったAWS Ambassadors業務や発信活動などの多様な取り組み
―「2025 Japan AWS Top Engineers（Security）」の受賞、おめでとうございます！今回Securityカテゴリーで応募された経緯を教えてください。
ありがとうございます。2024年は、AWSのマイグレーション等幅広い取り組みを通じて、Servicesカテゴリーで受賞できました。2025年は、セキュリティ関連の業務が大半を占めていたことから「今回はSecurityカテゴリーで応募しよう」と自分で判断しました。
今回受賞できたのは、銀行などの高セキュリティ要求案件でのAWS Ambassadors業務や、セミナー登壇・動画作成といった社内外への発信活動等、多様な取り組みが評価につながったからだと考えています。
セキュリティは“点”ではなく、“面”で捉えることが重要
― 日頃からセキュリティに対してどのような方針で取り組まれているのでしょうか？
私が常に意識しているのは、セキュリティを個別の対策の“点”ではなく、全体を俯瞰して“面”で捉えることです。たとえば、EDR（Endpoint Detection and Response）を導入すれば、PCやサーバーなどの端末（エンドポイント）で発生する不審な挙動を検知できます。しかし、これはあくまで一つの“点”の対策に過ぎず「導入したから安心」とは言えません。仮にエンドポイントのセキュリティを突破されたあと、社内ネットワークや重要なシステムへのアクセスが脆弱なままだと、攻撃者は簡単に内部へ侵入し、社内全体へ攻撃範囲を拡大させながら深刻な被害をもたらします。
こうしたリスクを防ぐにはお客様のCSIRT（インシデント対応チーム）運用や対応フローを踏まえたセキュリティアセスメントが重要です。「どのようなインシデントが想定され、どのように通知し、誰が確認するのか」「アラートを受けてどう対応するのか」等、現場の運用体制に合わせた設計でなければ機能しないのです。
AWSのセキュリティ機能は非常に高機能で比較的容易に操作できますが、インシデント対応・監査・ログ運用・権限設計等を包括的に検討する視点が大切です。そのうえで、お客様ごとの運用視点に立った設計と整備が求められると考えています。
一人で要件定義からドキュメント整備まで対応
― これまで特に印象的だった案件はありますか？
特に印象に残っているのは、セキュリティ要件が固まっていない状態から、一人で要件定義からドキュメント整備までを対応したプロジェクトです。プロジェクト開始時、お客様からの要望は漠然としており、プロジェクトメンバーにもセキュリティの専門知識を持つ人がいませんでした。そこで私は、NIST（米国立標準技術研究所）のガイドライン等を利用しつつ、CSIRT運用やガバナンス体制も含めた提案内容を一から組み立てました。要件定義からドキュメント整備まで一貫して対応したことで、結果としてお客様から非常に高い評価をいただきました。
本プロジェクトは、一人ですべて対応する必要があったので業務量が多く、非常に苦労しました。テンプレート化と平準化を進めることで効率化し、次回以降は他のメンバーも対応できるように整備しています。
生成AI導入で不可欠なデータガバナンスの整備
― 最近は、生成AIに関連したセキュリティ相談も増えているかと思います。現場で見えてきた課題などはありますか？
生成AIを業務に取り入れる際は“アクセス権限”が大きなセキュリティリスクになります。生成AIは、ユーザーの代わりに情報を検索・取得する検索ツールのような性質があるので、アクセス権限を詳細に設定しないと、意図せず機密情報が閲覧されかねません。
情報漏えいリスクを低減するために、ファイルのアクセス権限を見直す必要があります。“どのデータが、どこにあり、誰がアクセスできるのか”を把握できていない企業も多く、データガバナンス（データの所在を明確にし、アクセス権限を厳格に管理する体制）が機能していない状態で生成AIを導入してしまうリスクが顕在化しています。
また、クラウド環境ではログを収集して終わりになっているケースも散見されます。情報を集める・守ることは実施できているものの、その情報をどうインシデント対応につなげていくのかを検討されていない企業も少なくありません。特に、システムログに収集した情報の分析・活用方法やインシデント対応について、明確に答えられないという課題は多くの企業で共通していると思います。
生成AIの導入にあたっては、データガバナンスの整備が欠かせません。
若手エンジニアに求めるのは“自分の意見や仮説を持つこと”
― 若手エンジニアの育成や関わり方で意識していることはありますか？
「お客様からこのように言われましたが、どうすればいいですか？」と正解を求めて聞くのではなく、「私はこう考えていますが、どう思いますか？」と自分の意見や仮説を持つ姿勢を大切にしてほしいと伝えています。
―最後に、情シス・若手エンジニアへメッセージをお願いします。
若手の頃は、特に論理的思考力とコミュニケーション能力の二つを意識して鍛えるのがいいと思います。私自身、20代前半は黙々と作業するタイプで、人と話すことはあまり得意ではありませんでした。しかし、20代後半になってお客様向けにプレゼンする機会が増え、提案やプレゼンの仕方、説明の伝え方などを強く意識するようになりました。
論理的思考力は、システムトラブルや障害対応などで原因を整理・特定するときに役立ちますし、コミュニケーション能力はお客様との信頼関係を築く上で欠かせない力だと感じています。若手の頃からこの2つを意識して鍛えることで、エンジニアとしての成長スピードは大きく変わるのではないでしょうか。
また、私自身が若手の頃は、セキュリティの本を読んだり勉強会に出たりしても、あまり理解できなかった経験があります。しかし、最初は分からなくて当然なので、まずは自分が好きなこと、興味を持てることを見つける姿勢が大切です。好きな分野を極めていけば、自然と知識は身に付いていきます。自分の強みを見つけて、成長する過程を楽しんでほしいです。
