ニフティには所属部署での業務のほかに、有志による社内活動が存在します。もちろん強制ではなく、それぞれが興味のある分野について、自主的に活動しています。なかには会社公認のもと予算がつき、社内業務に貢献しているケースも。業務とは別のやりがいや、自分の専門外の知見を得られることが、一つのモチベーションになっています。 今回はその一つである、「AI活用推進チーム」にスポットを当てます。前編では、活動に参加するきっかけや普段の活動内容などについて聞きました。後編では、印象に残っているAIチームでのプロジェクトや所属部署の業務とチーム外活動の両立について、また、今後チャレンジしてみたいことについて語ってもらいます。 エンジニアだけでなくビジネスサイドからも「AIを使いたい」という声が挙がるように みなさんがAIチームで手がけたプロジェクトのなかで、特に印象深いものを教えてください。 藤岡さん 前回も少しお話ししましたが、セキュリティチームに寄せられる社内からの問い合わせに対して、自動回答を行うAIエージェントを開発しています。昨年の夏頃から着手し始めて、もう少しでリリースできるところまできました。 もともとはセキュリティチームにいる同期から山本くんが相談を受けて、スタートしたプロジェクトです。本当にゼロからの開発で、「どんなシステムを作り、どういったゴールを目指すのか」「どう工数を削減するか」「いかに効果を最大化するか」など、相談してくれた同期と山本くんと私の3人で試行錯誤しながら進めてきました。 上司から指示を受けたタスクではなく、自分たち自身でやりたいと始めたことが形になり、それが会社のためになる。入社2年目にしてそういう経験をできたのは大きいと思いますし、印象深いですね。 山本さん 私もその案件は印象深いのですが、他で言うとカスタマーセンターの部署から寄せられた相談ですね。お客様対応のログデータを分析するにあたって、個人情報や社内情報のマスキングを自動化できないかと。使えそうなツールや技術を使ったり試したりするうちに知見も溜まっていきましたし、単純に楽しかったですね。マスキングは個人的にあまり触れてこなかった領域でもあるので。技術的に難しい部分も多く完成には至っていませんが、なんとか形にしたいです。 中井さん、小林さんはいかがですか？ 中井さん 少し古い話ですが、2023年頃に社内のエンジニアがニフティ内で使うSlackBotを開発したんです。「myfriendGPT」という、ChatGPTのAPIを活用したツールでした。開発当初に比べてChatGPTのモデルも高性能になっていますし、画像読み込み機能もつけたいということで、私がツールを引き継いでリニューアルすることになったんです。これはエンジニアとしての価値観が変わったプロジェクトとして、印象に残っていますね。 ニフティって全社的にインナーソースを推奨していて、社内の誰かが作ったソースコードに別の人が機能を追加するなどして、「みんなで育てていこうよ」みたいな思想があるんです。ある時、自分がリニューアルしたSlackBotにまた別の機能を付与したBotを作った人がいて。それまで自分は「ツールを提供すること」が貢献だと思っていましたが、新しいツールのベースとなるものを作ることも、別の形の貢献なんだなと気づきました。 小林さん もちろん個別のプロジェクトで印象に残っているものはたくさんありますが、私のなかではAI活用を推進する活動を続けられていること自体への感慨がありますね。社内SlackにAI相談窓口を作った当初は10人くらいだったチャンネルが、今では80人に増えて多くの相談が寄せられるようになりました。嬉しかったのは、エンジニアだけでなく、営業などビジネス側の社員からも反応してもらえたこと。「これまであまりAIに触れてこなかったけど、このチャンネルを通じて興味を持ち、今は積極的に活用している」と言ってくれたんです。 AIシステムを開発するだけでなく、チャンネルに寄せられる相談に対して「こんなツールがありますよ」「こういった活用方法がありますよ」といった提案もしていて、少なからず各部署の工数削減に貢献できている実感がありますね。 チーム外活動も大切な仕事。本業との両立と所属部署の理解 山本さんはOJTが終了してすぐにAIチームへの参加を決めたそうですが、配属先が決定してこれから仕事を覚えていこうという時期にチーム外活動も並行して行うのは、負担が大きいのではないかと感じます。不安はなかったですか？ 山本さん 私が入った時点では、そこまで大きな負担になる印象はなかったです。当初は有志が集まって、各自の課題をAIで解決した知見を共有するくらいの温度感でしたから。私もそれまで趣味としてAI関連の情報は集めていたので、色々と情報交換ができたらいいなという気持ちでした。ただ、社内からの相談窓口を設けて、去年の年末あたりから少しずつ本格化してきたこともあり、段々と両立が難しくなってきていることは事実ですね。 それでもやはり、両方やりたいと。 山本さん やりたいですね。所属部署の業務はもともと私が持っていた技術とマッチしていなかったところもあり、インプットするべきことが非常に多いんです。最初はそこで気持ちが落ち込むこともあったのですが、AIチームの集まりが、ある意味「憩いの場」になっていました。本業以外で気分転換になったり、モチベーションをキープできる場があるというのは、とても大きいと思います。 小林さん 私と山本くんは同じ部署なのですが、本業も忙しいですしAIチームでの相談案件も詰まってきていて、現状は完璧に両立ができているかというと微妙なところです。ただ、私たちとしては所属部署での仕事も、チーム外活動もどちらも頑張りたい。マネージャーにも相談したところ、業務時間の2割はAIチームに使っていいと言ってくださっています。ですから、本業が多忙な時期でもなるべく2割はチーム外活動の時間を確保するようにしていますね。私の上司を含め、何かやりたいと言えば基本的には背中を押してくれるのがニフティの良さだと思います。 藤岡さんは、業務との両立についてはいかがですか？ 藤岡さん 私も割合で言うと、やはり本業8割、AIチーム2割といったところです。私と中井さんは同じ部署なのですが、わりと柔軟性が高いというか、上司、部署メンバーとも非常に理解のある方ばかりなんです。たとえば、AIチームのほうで緊急の大きな案件が入った時には、そっちに全振りしてもいい、くらいのことを言われています。つい先日も、丸々1日をAIチームに使わないといけない状況があったのですが、その時は所属部署の方がフォローしてくださいました。上長だけでなく、全社的にこうした活動への理解があるので、かなりやりやすいですね。 中井さん 本当にありがたい限りです。上長や部署のメンバーも「チーム外活動も、あなたの大事な仕事だからね」という理解のもと、背中を押してくださっていると感じます。だから、AIチームの仕事が忙しい時はフォローするよと。 あとは、チーム外活動も基本的には会社をよくするためにやっていることであって、それをみんなが理解してくれているんですよね。「確かに、それは今やるべきだよね。だから、部署のタスクのなかで期限に余裕があるものは調整して、AIチームにリソースを割いたほうがいいよね」といった柔軟性があるんです。それは我々AIチームに限らず、全てのチーム外活動に対して同じような意識があるのではないかと。 AIの価値を最大化し、ニフティ全体へ広げていく 最後に、みなさんがこのAIチームで今後チャレンジしたいことを教えてください。 山本さん 当面の目標としては、先ほどもお話ししたようにセキュリティチームへの問い合わせを自動回答するAIエージェントを形にしたいですね。また、それを実装して効果測定ができてからの話にはなりますが、カスタマーセンターだけでなく他の部署にもQ＆Aのやりとりはあるので、色々なケースで展開できるようなものを開発して効果を最大化したいと考えています。 もう少し、先の目線で言うと、そもそもAIって単純作業や運用作業を代替させて、人間が新しいアイデアを発想したり、サービスの品質向上に注力できる状況を生むためのもの。ですから、社内のAI活用をさらに推進して、ニフティの社員が本来やるべきことに集中できる環境をつくっていきたいですね。 藤岡さん 直近では、このAIチームで得た新しい知見を生かして、所属部署の業務改善につなげていきたいと思っています。自分たちを被験体にして、「こんなシステムを作って、この業務を自動化しました」という事例を数多く生んでいきたいですね。 最終的な目標は、それら事例を全社に公開して、今はあまりAIを活用できていない人が関心を持つきっかけを作りたいです。AIのことがよくわからない、うまく使えていない人の気持ちは、僕自身がそうだったからこそよくわかります。僕がこの1年間、AIチームで体験した驚きを、多くの人にシェアしたいですね。 中井さん 相談窓口に寄せられる相談を見ていると、どのお悩みにも共通点があるというか、同じ技術で解決できそうなことって意外と多いなと感じます。先ほど山本くんが話してくれたマスキングの件もそうですよね。 最初はイチ部門の課題を解決するために作ったシステムが、じつは多くの職種の業務に適用できるということになれば、我々がかけた労力が何倍もの効果を生んで報われます。ですから、相談窓口に寄せられる問い合わせをなるべく丁寧に拾い上げて、できれば具体的なプロトタイプを開発して提案するというところまで踏み込んでいきたい。そういう事例を多く作っていきたいと考えています。 では最後に、リーダーの小林さん、締めていただけますか。 小林さん まずは今やっていることを引き続き頑張ることですね。もっと多くの人に、幅広い部署に相談窓口の存在を知ってもらい、それに対して我々に何ができるかを突き詰めていく。あとは、AI活用のハードルを少しでも下げていきたいと考えています。たとえば、AIツールを使って開発したいエンジニアにAWSのアカウントを貸し出す時も、現状は申請の手続きにやや手間取る部分があります。もちろん、セキュリティ面も考慮してある程度のハードルは設けなくてはいけませんが、できれば多くの人がもう少し気軽に使ってみたいと思える仕組みをつくっていきたい。エンジニアに限らず、ビジネスサイドの人たちも当たり前にAIを活用できる環境をつくるためのサポートをしていきたいですね。 前編もご覧ください！ 今回はニフティのAI活用推進チームのインタビューの様子をお届けしました。あわせて前編もご覧ください。 【インタビュー】社内各部署の困りごとをAIで解決。好きな分野を突き詰めながら、本業外でも会社に貢献する【AI活用推進チーム 前編】 ニフティでは、さまざまなプロダクトへ挑戦するエンジニアを絶賛募集中です！ ご興味のある方は以下の採用サイトよりお気軽にご連絡ください！ このインタビューに関する求人情報/ブログ記事 ニフティ株式会社 求人情報

目次 はじめに ECR イメージスキャンとは 構成の全体像 検知の網羅性 通知のノイズ低減 認知のスピード コスト 試算の考え方 試算例 Terraform による構築 1. ECR スキャン設定 2. EventBridge ルール 3. SNS トピック 4. AWS Chatbot（Slack 通知） 実際の通知と運用 導入してみて まとめ はじめに こんにちは、開発本部開発1部トモニテグループのエンジニアの パンダム/rymiyamoto です。 2025年末に Next.js の React Server Components に DoS（サービス拒否）とソースコード露出の脆弱性が公開 され、App Router を使用するサービスでのアップグレード対応が求められました。 このように、利用しているフレームワークやライブラリに深刻な脆弱性が見つかることは珍しくありません。 こうした脆弱性が公開中のサービスに影響していないかを素早く把握できる体制を整えるべく、弊社でも ECR のイメージスキャンを導入しました。 本記事では、その取り組みの一つとして ECR のイメージスキャンを導入した際の設計・構築・運用について紹介します。 同じように ECR のイメージスキャンをこれから導入しようとしている方の参考になれば幸いです。 ECR イメージスキャンとは Amazon ECR のイメージスキャンは、コンテナイメージに含まれるソフトウェアの脆弱性（CVE）を検出する機能です。 スキャンには Basic Scanning と Enhanced Scanning の2種類があります。 項目 Basic Scanning Enhanced Scanning スキャンエンジン Clair（オープンソース） Amazon Inspector2 検出対象 OS パッケージの脆弱性 OS パッケージ + プログラミング言語パッケージ（npm, pip, Maven 等） スキャンタイミング プッシュ時 / 手動 プッシュ時 / 継続スキャン 料金 無料 有料（スキャンしたイメージ数に応じた従量課金） 構成の全体像 導入した構成は以下の通りです。 ECR Enhanced Scanning (Inspector2) ↓ 脆弱性検知 EventBridge Rule (CRITICAL のみフィルタ) ↓ SNS Topic ↓ AWS Chatbot → Slack チャンネルに通知 設計にあたって意識したのは以下です。 検知の網羅性 OS パッケージだけでなく言語パッケージもカバーしたかったため、Enhanced Scanning を採用しました。対応言語の詳細は公式ドキュメントを参照してください。 docs.aws.amazon.com 一方で、OS パッケージの脆弱性検知だけで十分なケースや、まずは無料で始めたいケースでは Basic Scanning も有力な選択肢です。自社の要件に合わせて検討してみてください。 通知のノイズ低減 すべての severity を通知すると対応が追いつかなくなるため、まずは CRITICAL に絞って運用を開始しました。実際に HIGH まで含めて試してみたところ、本当に対応すべき通知が埋もれかねないと感じたので、まずは CRITICAL で運用を開始し、必要に応じてフィルタを広げる方針としています。 認知のスピード 脆弱性の存在に気づかないことが一番のリスクなので、Slack への即時通知を組み込みました。Slack への通知方法としては EventBridge → Lambda で通知内容をカスタマイズする方法もありますが、今回はまず検知できる状態を素早く作ることを優先し、コードを書かずに構築できる AWS Chatbot を採用しました。 コスト Enhanced Scanning は Amazon Inspector2 の料金体系に基づきます。料金は以下の2つで構成されます（2026年4月時点）。 最新の料金は公式ドキュメントをご確認ください。 aws.amazon.com 初回スキャン: イメージがプッシュされた時のスキャン、$0.09 / イメージ 再スキャン: 継続スキャンにより新しい CVE が公開された際の自動再スキャン、$0.01 / イメージ 試算の考え方 スキャン頻度によってコストの構造が異なります。 スキャン頻度 発生するコスト 計算式 プッシュ時 初回スキャンのみ 月間プッシュ数 × $0.09 継続スキャン 初回スキャン + 再スキャン 上記 + 保持イメージ数 × 再スキャン回数/月 × $0.01 弊社では本番環境は継続スキャン、開発環境はプッシュ時スキャンで運用しています。本番環境では新しい CVE が公開されたタイミングでも即座に検知したいため継続スキャン、開発環境では脆弱性を含む実装が入った時点で素早く検知しつつコストも抑えたいためプッシュ時スキャンが適しています。 試算例 例えば、5つのリポジトリに対して月間100回プッシュし、本番では各リポジトリに2イメージを保持（計10イメージ）するケースで試算します。再スキャン回数は月にどれくらいの頻度で対象の CVE が新たに公開されるかに依存しますが、ここでは月15回程度を見込みました。 項目 計算式 コスト 初回スキャン 100 push × $0.09 $9.00 再スキャン 10 images × 15回 × $0.01 $1.50 月額合計 $10.50 実際のコストはリポジトリ数・プッシュ頻度・保持イメージ数によって変わるので、自社の運用に合わせて試算してみてください。 Basic Scanning（無料）と比較するとコストはかかりますが、言語パッケージの脆弱性検知や新規 CVE の自動再スキャンが得られることを考えると、検討する価値はあると思います。 Terraform による構築 1. ECR スキャン設定 まず ECR レジストリに対して Enhanced Scanning を有効化します。 resource "aws_ecr_registry_scanning_configuration" "this" { scan_type = "ENHANCED" rule { scan_frequency = "CONTINUOUS_SCAN" repository_filter { filter = "*" filter_type = "WILDCARD" } } } filter = "*" でレジストリ内のすべてのリポジトリをスキャン対象にしています。リポジトリを個別に指定する方法もありますが、新しいリポジトリを追加した際にスキャン対象への追加を忘れるリスクがあるため、ワイルドカードで全体を対象にしています。 scan_frequency は環境によって使い分けています。本番環境では CONTINUOUS_SCAN 、開発環境では SCAN_ON_PUSH を設定しています。 2. EventBridge ルール resource "aws_cloudwatch_event_rule" "ecr_scan_finding" { name = "ecr-scan-finding-notification" event_pattern = jsonencode ( { "source" : [ "aws.inspector2" ] , "detail-type" : [ "Inspector2 Finding" ] , "detail" : { "status" : [ "ACTIVE" ] , "severity" : [ "CRITICAL" ] , "resources" : { "type" : [ "AWS_ECR_CONTAINER_IMAGE" ] } } } ) state = "ENABLED" } resource "aws_cloudwatch_event_target" "ecr_scan_finding_sns" { rule = aws_cloudwatch_event_rule.ecr_scan_finding.name arn = var.ecr_scan_finding_sns_topic_arn } Enhanced Scanning では Inspector2 がスキャンエンジンとなるため、イベントソースは aws.inspector2 になります。 Basic Scanning の場合は aws.ecr になるので注意が必要です。 3. SNS トピック EventBridge から受け取ったイベントを AWS Chatbot に渡すための SNS トピックを作成します。 resource "aws_sns_topic" "ecr_scan_finding_topic" { name = "ecr-scan-finding-topic" } resource "aws_sns_topic_policy" "ecr_scan_finding_topic_policy" { arn = aws_sns_topic.ecr_scan_finding_topic.arn policy = data.aws_iam_policy_document.sns_ecr_scan_finding_topic_policy.json } data "aws_iam_policy_document" "sns_ecr_scan_finding_topic_policy" { # EventBridge からの Publish を許可 statement { sid = "AllowEventBridgeToPublishSNS" effect = "Allow" actions = [ "sns:Publish" ] principals { type = "Service" identifiers = [ "events.amazonaws.com" ] } resources = [ aws_sns_topic.ecr_scan_finding_topic.arn ] condition { test = "StringEquals" variable = "AWS:SourceAccount" values = [ data.aws_caller_identity.current.account_id ] } condition { test = "ArnEquals" variable = "aws:SourceArn" values = [ "arn:aws:events:$ { data.aws_region.current.name } :$ { data.aws_caller_identity.current.account_id } :rule/ecr-scan-finding-notification" ] } } # Chatbot からの Subscribe を許可 statement { sid = "AllowChatbotToSubscribe" effect = "Allow" actions = [ "sns:Subscribe" ] principals { type = "Service" identifiers = [ "chatbot.amazonaws.com" ] } resources = [ aws_sns_topic.ecr_scan_finding_topic.arn ] condition { test = "StringEquals" variable = "AWS:SourceAccount" values = [ data.aws_caller_identity.current.account_id ] } condition { test = "ArnEquals" variable = "aws:SourceArn" values = [ "arn:aws:chatbot::$ { data.aws_caller_identity.current.account_id } :chat-configuration/slack-channel/alert-to-slack" ] } } } SNS トピックポリシーでは、EventBridge からの Publish と Chatbot からの Subscribe のみを許可しています。 condition で発信元を絞ることで、意図しないリソースからの操作を防いでいます。 4. AWS Chatbot（Slack 通知） 最後に、SNS トピックのメッセージを Slack に転送する Chatbot の設定です。 resource "aws_chatbot_slack_channel_configuration" "chatbot_alert_to_slack" { configuration_name = "alert-to-slack" slack_channel_id = "XXXXXXXXX" # 通知先の Slack チャンネル ID slack_team_id = "XXXXXXXXX" # Slack ワークスペース ID iam_role_arn = var.chatbot_role_arn sns_topic_arns = [ var.ecr_scan_finding_topic_arn, # 他の通知用 SNS トピックもここに追加できる ] guardrail_policy_arns = [ "arn:aws:iam::aws:policy/ReadOnlyAccess" ] logging_level = "ERROR" } これで CRITICAL な脆弱性が検知された際に、Slack チャンネルに通知が届くようになります。 なお、AWS Chatbot では同じ Slack チャンネルに対して複数の configuration を作成できません。そのため configuration_name は alert-to-slack のように汎用的な名前にしています。こうしておけば、今後 WAF のアラートなど別の通知を追加したくなっても sns_topic_arns にトピックを足すだけで済みます。 実際の通知と運用 実際に届く通知は以下のような形式です。 最初は CVE の詳細まで Slack で確認できるものだと思っていたのですが、実際に届く通知には Inspector2 Finding というイベント名と対象の ECR イメージの ARN が表示されるだけで、CVE 名もパッケージ名も表示されませんでした。 そのため、EventBridge の input_transformer を使い、Chatbot のカスタム通知で通知内容を改善しました。 resource "aws_cloudwatch_event_target" "ecr_scan_finding_sns" { rule = aws_cloudwatch_event_rule.ecr_scan_finding.name target_id = "SendToSNS" arn = var.ecr_scan_finding_sns_topic_arn input_transformer { input_paths = { "severity" = "$.detail.severity" "title" = "$.detail.title" "description" = "$.detail.description" "repository" = "$.detail.resources[0].details.awsEcrContainerImage.repositoryName" } input_template = <<TEMPLATE { "version": "1.0", "source": "custom", "content": { "textType": "client-markdown", "title": ":rotating_light: ECR <severity> 脆弱性検出 [環境名 (AWSアカウントID)]", "description": "*重要度*: <severity>\n*リポジトリ*: <repository>\n*脆弱性*: <title>\n*詳細*: <description>" } } TEMPLATE } } ポイントは input_paths でイベントから必要な項目を抽出し、カスタム通知フォーマットで整形している点です。改善後の通知は以下のような形式です。 CVE-ID やパッケージ名、リポジトリ名が表示されるようになり、Slack 上で脆弱性の概要を把握できるようになりました。詳細な対応判断が必要な場合は Inspector2 のダッシュボードを確認する運用ですが、通知を見ただけで対応要否がわかることが増えました。 さらに通知内容を自由にカスタマイズしたい場合は、EventBridge → SNS → Chatbot の経路ではなく、EventBridge → Lambda で整形する方法もあります。 導入してみて CRITICAL に絞った判断はうまくいきました。最初の通知が来たときも「これは本当に対応が必要なものだ」と落ち着いて対処できたので、狙い通りでした。 一方で、Chatbot のデフォルトの通知では CVE の詳細が出ず、正直もう少し情報が出ると思っていました。実際に使ってみて初めて気づいた部分で、 input_transformer を使ってカスタマイズできることも後から知りました。 Terraform での複数環境展開やスキャン頻度の使い分けはすんなりいきました。 まとめ 今回は、フレームワークやライブラリの脆弱性に素早く対応できる体制づくりの一環として、ECR の Enhanced Scanning を導入した事例を紹介しました。 構成としては ECR Enhanced Scanning → EventBridge → SNS → Chatbot → Slack というシンプルなパイプラインですが、Terraform でコード化することで再現性のある形で複数環境に展開できました。 まず検知できる状態を作ることが第一歩、そこさえ超えれば運用しながら精度を上げていけます。本記事がその一歩を踏み出すきっかけになれば嬉しいです。 最後まで読んでいただきありがとうございました！

目次 はじめに 背景と課題 避難訓練の全体像 GUIベースのツールを選定した理由 AIによるシナリオ ...