GMO Flatt Security Blog

GMO Flatt Security株式会社の公式ブログです。プロダクト開発やプロダクトセキュリティに関する技術的な知見・トレンドを伝える記事を発信しています。

GMO Flatt Security株式会社の公式ブログです。
プロダクト開発やプロダクトセキュリティに関する技術的な知見・トレンドを伝える記事を発信しています。

現場のAI活用希望 vs セキュリティ - 板挟みコーポレートエンジニアのためのセキュリティ・ガバナンス実践録

技術 AI

はじめに

こんにちは。GMO Flatt Security株式会社でコーポレートセキュリティエンジニアをしています、hamayanhamayanです。

様々な企業で生成AIの活用が進んでいることと思います。その流れは当社も例外ではなく、今年に入ってから、生成AIの全社的な利用、生成AIを利用した診断業務の効率化、生成AIを活用した製品開発と、怒涛のように生成AIの利活用が進んでいます。

そんな中でコーポレートエンジニアは、ビジネスの前進に必要な生成AIの利活用は止めたくない、しかし、企業の責任としてセキュリティやガバナンスは疎かにできないという板挟みの中にいると思います。私も例外ではなく様々な情報を集め、リスク評価を行い、社内整備を進めてきました。

本稿は、私がその過程で得た知識を凝縮した記事となります。生成AIに馴染みの無い方にも手にとって貰えるよう初歩的な部分から説明していて、また、内容を広く浅く扱っていますので既に生成AIを利用しているエンジニアにとっても新しい観点が得られれば幸いです。

加えて、いざ業務の中に生成AIを取り込むとなった時に参照すべきドキュメントに関しても幅広く集めてみました。リンク集的にも活用いただけると思います。

同じような状況で悩むエンジニアにとって、参考になればと思います。

また、本記事で観点を紹介するような議論・整理を経てGMO Flatt Securityは日本初のセキュリティ診断AIエージェント「Takumi」や、LLMを活用したアプリケーションに対する脆弱性診断・ペネトレーションテストを提供しています。ご興味のある方はリンクよりサービス詳細をご覧ください。

会社と生成AIを取り巻く環境について

まず、本稿で取り扱う予定の会社と生成AIを取り巻く環境について、簡単にまとめてみました。

中心に生成AIを提供するプロバイダがあり、その周りに色々なサービスが展開されています。生成AIを打ち出しているWebサービスに限らず、普段の業務で利用しているサービスで生成AIの機能がどんどん搭載されて来ているのをみなさんも感じていると思います。

このように色々ある要素について、「生成AI本体」「生成AIを利用するWebサービスやアプリケーション」「生成AIを組み込んだ内製システム」の大きく3つのグループに分けて、その中身についての簡単な紹介を行った後、セキュリティ上また考慮すべき観点について紹介していきます。最後に、総合的なまとめとお伝えしきれなかった補足事項を紹介し、生成AIを利用するうえで必要な知識を本稿にて広く浅く理解していただけたらと思います。

生成AI本体

まずは、生成AIそのものから見ていきましょう。

生成AIとは

生成AIは、学習したデータに基づいて、文章、画像、音声など、新しいコンテンツを「生成」する人工知能の一種です。過去のパターンを分析し、それらを用いて創造的なアウトプットを生み出すことができます。これにより、人間がこれまで行ってきたデザインや執筆といった作業の一部を自動化・支援することが可能になります。

一番分かりやすく生成AIを理解できるのは、チャットベースでのやり取りです。Googleが出しているGeminiは以下のようにチャットで生成AIと会話できるWebサービスを提供しています。

（先ほどの生成AIについての説明はGeminiによる自己紹介です。）生成AIの仕組みを利用者目線で見てみると、入力を与えると、生成AIで処理が行われて、出力が返ってくるという認識で問題ありません。また、生成AIは会話の中でこれまでの情報を覚えておくということができます。先程の回答は長いのでもっと短い文章にしてもらいましょう。

このように入力を追加した場合でも、これまでの文脈を理解した状態で出力を作成してくれます。よって、生成AIは会話中の状態を記憶して適宜利用するという性質もあります。これはコンテキストウィンドウと呼ばれるもので、会話内だけで利用される一時的な記憶の仕組みになります。

このような生成AIの利用に関して、会社における生成AI利用の考慮すべき観点を見ていきましょう。既存のWebサービスと異なる視点を中心に、セキュリティ的な観点とそれ以外の観点も含め、包括的に見ていきましょう。

観点1: これまでと同様のリスク評価やセキュリティチェック

入力を入れると、生成AIが処理をして、出力が返されるという構図を説明しましたが、この構図は特にこれまでのWebサービス利用とは変化が無い部分です。そのため、これまでにWebサービス利用の際に実施してきたリスク評価やセキュリティチェックについては同様の内容で実施することができます。

利用に際して、法令遵守に関する観点も同様にあります。生成AIと法については本稿では扱いませんが、一例として文化庁のAIと著作権といった資料もあり、法務部門との連携が生成AIではより求められています。また、場合によっては国外の法律についても考慮が必要な場合もあります。例えば、EUのAI法はEUにある支店で働いている従業員にも適用されますので、国際的な動きにも追従していく必要があります。

観点2: 「入力された情報を使ってモデルが学習するか」

これまでのWebサービスと大きく違う部分が、入力した情報を使って生成AIのモデルを学習する可能性があるという部分です。過去、ChatGPTの利用による情報漏洩の可能性のニュースが世間を賑わせた 1 こともあり、色々な生成AI関連のサービスのヘルプを見ても、モデルの学習に関わる文章を頻繁に見かけます。

確認する際に注意すべき点として、プランによってモデルを学習するかどうかのポリシーが異なっている場合があったり、Webサービス上での行動によっては入出力がモデルの学習に使われうることがあります。ビジネスユースであれば、どういう形であってもモデルの学習には利用されないというのが理想なので、ヘルプを細かい所まで読み、仕様やポリシーを把握しておくことが重要です。

  • OpenAIではプライバシーについて消費者向けとエンタープライズ向けではポリシーが異なり、他の生成AIであっても個人向けとエンタープライズ向けではポリシーが異なる場合が多いです
  • 他にも、Claudeのエンタープライズ向けヘルプ Is my data used for model training? を読むと、フィードバックを明示的に行うことで会話の内容がモデルの学習に使われるという記載があり、利用の仕方によってはモデルの学習に送られる可能性を認識しておく必要があります
    • 同ページで、フィードバックを無効化する設定方法も紹介されています

コラム：コンテキストウィンドウについて
先ほどの生成AI本体の説明において出てきたコンテキストウィンドウとモデルの学習について少し補足しておきます。一見、コンテキストウィンドウの利用はある種の学習のように見えますが、このコンテキストウィンドウに格納された情報は会話のみにしか利用されず、他の利用者からは参照することができません。

モデルの学習による情報漏洩リスクは、学習されたモデルが他者と共用されていることから発生するリスクですので、コンテキストウィンドウを利用した文脈を理解した回答というのは、モデルの学習とは別物であることを認識しておく必要があります。

観点3: 生成AIの出力結果に関する制限を意識した利用

他のタイプのWebサービスと比べ、特に生成AIの出力結果に関しては制限があることを理解し、注意しながら利用する必要があります。この点については、以下のように各社が安全性や制限についての資料を公開しているので参考にしながら、重要な決定やレポートに関しては再度確認するなど、業務に組み込む際にはこういった制限を意識しておく必要があります。

  • GeminiのKnown limitations of LLM-based interfaces like Geminiとして出力結果に関するリスクを紹介しています
  • AnthropicヘルプのOur Approach to User Safetyではユーザーの安全性に対して様々な対策を講じていますが、一方で「These features are not failsafe, and we may make mistakes through false positives or false negatives.」のように対策の限界についても記載があります

生成AIの動作は完全にコントロールすることができず、出力が安定しない場合があります。このような点も他のWebサービスとの違いとして認識し、業務利用する際に考慮が必要なポイントです。

観点4: ローカルでの生成AIや生成AIの提供基盤を活用する

これまでに記載してきたセキュリティ観点について、利用しようとする生成AIが要件を満たさない場合があります。そのような場合に検討できる選択肢として、ローカル生成AIや生成AIの提供基盤があります。

生成AIは色々な会社によって開発され、いくつかの提供形態があります。

利用形態 代表例
リモートでの生成AI インターネットを通じてクラウド上に存在する生成AIを利用する形態 Google Gemini, Anthropic Claude, OpenAI GPT
ローカルでの生成AI ユーザ自身のコンピュータやサーバ上で直接生成AIを実行する形態 Meta Llama, Google Gemma

情報を社内環境に留めておきたい場合など、オフラインで動作させることで要件を満たせる場合は、ローカル生成AIが活用できます。マシンパワーが必要などのデメリットもありますが、オフライン動作による大きなメリットを活用できます。

また、生成AIをそのまま利用するのではなく、後述する（AWS Bedrockのような）生成AIの提供基盤を経由して利用することで、場合によってはより厳しいポリシーの下で生成AIを活用できる場合があります。提示されたポリシーが社内基準に合わない場合は、別の提供元から利用することも検討できます。

どの生成AIのモデルを選択するかについては、行政機関のアナウンスも参考にすることができます。例えば世間を騒がせたDeepSeekについては、個人情報保護委員会やデジタル庁が資料を提供しています。

生成AIを利用するWebサービスやアプリケーション

生成AI × Webサービスやアプリケーション

次は、生成AIを利用するWebサービスやアプリケーションという枠組みで利用例を考えてみましょう。昨今では、AIを全面に打ち出しているサービスが次々と登場し、世間を賑わせています。有名なところだと、DevinやCursorといったサービス・アプリケーションが有名ですね。日本初・セキュリティ診断AIエージェントであるTakumiという製品も最近弊社から登場しました。

また、情報システム担当の頭を悩ませていると想像しているのが、既存のこれまで利用してきたアプリケーションにAI機能が日々追加され、利用可能になっていることです。このまま利用可能にしておいても良いのか、制限すべきなのか、日々判断を迫られていることと思います。

背後に生成AIがある構造について

セキュリティ観点を考える前に、生成AIを利用するWebサービスやアプリケーションのアーキテクチャをざっくり見てみましょう。実際にはサービスの背後がどうなっているかは正確には把握できないのですが、扱われている情報などを踏まえモデル化して考えてみることにします。

生成AIを利用したアプリケーションやWebサービスは、背後でなんらかの生成AIに依存してサービスを展開している場合が多く、ユーザと生成AIの間に生成AIアプリケーションやWebサービスが入り、必要なデータの連携などが行われています。

単純な生成AIの利用と比べて大きく違うのはデータ連携部分です。

  • DevinやCursorのようなAI利用を打ち出している生成AIアプリでは、生成AIに操作させたいWebサービスやファイルなどを連携させることで、そこにある情報を生成AIが利用しながらサービスを提供してくれます
  • Windows 11やEdgeに搭載されているCopilotや、Atlassianが提供するAtlassian Intelligenceのように既にデータを取り扱っているサービスが続々AI機能を発表し、自身のプラットフォームにある情報や既に取り扱っている情報と生成AIを組み合わせてサービス提供しているものもあります
  • また、最近は生成AIプロバイダが直接データ連携の機能を提供しているものもあります。例えばClaudeでも検索機能やGoogle Drive連携をサポートするようになりました
  • 他にも、利用者によるサービス連携がサポートされている場合もあり、例えば、MCPを利用したサードパーティのアプリやサービスの連携も標準化や活用が進んでいます

観点1: 生成AI本体における考慮事項は同様に確認が必要

最終的には生成AIを使っていることから、前章で取り扱った生成AI本体における考慮事項は同様に確認が必要になります。生成AIに対する利用者からの不信感を払拭するためか、各サービスでその仕組みや対策について丁寧に解説している公開記事を多く発行しています。このような公開資料を参考にしながら、リスク評価や利用要件を満たすかどうかの確認が行えます。

サプライチェーンのような形で生成AIが登場することで確認する上での複雑性は上がってきていますが、「学習されないこと」また「データ保持に関する部分」については重点的に確認すべき観点になると思います。

また、一部サービスについては利用している生成AIや提供基盤も公表されているため、それらのホワイトペーパーも参照しながらサービス全体のリスク評価に利用できます。実際にAIを活用したサービスの資料を見ていくと、背後で使われている生成AIの種類はそれほど多くなく、背後にある生成AIに関わる評価結果は流用しながら効率的に評価を進めていくと良いです。

観点2: 導入済みサービスや製品における追加のAI機能リリース

導入済みのサービスにAI機能がどんどん追加され、サービスや製品が扱っている情報と生成AIを活用した機能がリリースされていることを感じていると思います。AI機能を利用することで情報管理基準が下がっていないか、追加のリスクはあるだろうか？という気持ちを抱えつつ、なるべく社内での利活用を進めていきたいと言う気持ちもあると思います。

サービス提供側もそのような状況を理解しており、AI機能のリリースと共にとても丁寧な説明を各社リリースしています。社内での利活用を考える際はそのようなリソースをまずは参照することから始めることをオススメします。

検討の結果、社内利用を一旦止めたいという選択肢も可能性としてあると思います。そういった選択が取れるよう、追加された生成AI機能については管理者側がコントロールしやすいよう、サービスによってはポリシー設定が用意されています。リスクに応じて、例えば以下のような、無効化の設定展開が可能です。

観点3: データ連携時の注意点

生成AI本体の「観点3: 生成AIの出力結果に関する制限を意識した利用」でも触れましたが、基本的に生成AIの動きを完全にコントロールすることはできません。プロンプトによってある程度動きを指示することはできますが、「〜してはいけない」とプロンプトに含めたにも関わらず、その動作を実行してしまったというのを経験したことのある人も多いと思います。

この生成AIの制御不可能性とデータ連携について考えると、「〜してはいけない」という部分はプロンプト外、つまり、生成AIに情報が送られる前に行うのが確実です。

  • どのサービスでも言えるのが生成AIと連携させる情報は必要最小限にする、つまり、最小権限の原則が同様に適用できます
  • サービスによっては細かい認可設定が行える場合もあります。例えば、CursorならIgnore Filesという機能を使って機微な情報をデータ連携から外すことができます。このようにプロンプトレベルではなく、それ以前の段階での除外設定が行える場合があります

生成AIの制御不可能性をより深く考えると、データ連携を行った際のリスク評価では、連携されたデータ、Webサービス、あるいは、計算能力を最大限悪用された時に何ができるかということを考えることになります。このような生成AIの制御不可能性と複数の連携の危うさについては以下の記事で語られています。

blog.flatt.tech

blog.flatt.tech

これらの想定に対して、どれだけの可能性で情報漏洩リスクが顕在化するかという評価は企業毎に様々かと思いますが、このような生成AIのある意味での暴走が、情報漏洩や重要で危険な操作を引き起こすという可能性は認識しておく必要があります。この問題に対する対策も上記の記事で解説しています。合わせてご覧ください。

生成AIを組み込んだ内製システム

生成AIシステムを内製する

最後に生成AIシステムを内製する場合を考えてみましょう。会社の業務によりあったシステムを構築するため、生成AIを組み込んだ内製システムを開発することもあると思います。Microsoft Copilot StudioやDifyといったローコードで内製できるものもありますが、ここでは開発を伴う内製について扱うことにしましょう。

開発時は、生成AIを利用するためのAPIを活用できます。ClaudeであればAnthropic APIという形で提供されていますし、OpenAIやGeminiもAPIを提供しています。

また、パブリッククラウドが提供しているAI提供基盤からもAPIが利用できます。AWSによるBedrock、GCPによるVertex AI、AzureによるAzure AI Foundryといった基盤が代表的です。これらの提供基盤はそれぞれのパブリッククラウドの情報管理ポリシーに従いつつ、生成AIプロバイダが提供している各モデルを同様に提供してくれます。場合によっては生成AIプロバイダから直接APIを利用するのではなく、AI提供基盤からAPIを利用する選択肢が要件を満たす場合もあるため、選択肢として活用できます。

生成AIを利用したアプリケーションの開発時は、LangChainといった生成AIフレームワークがよく利用されます。生成AIフレームワークは、RAGやナレッジを活用したデータ連携に対するサポートやAPIを利用する結合部分などの標準的な実装をサポートしてくれるため、本来のビジネスロジックに集中しやすくなります。本ブログの記事で生成AIフレームワークのセキュリティリスクにフォーカスした記事があるので、こちらも合わせて是非読んでみてください。

blog.flatt.tech

観点1: 通常の開発 + 生成AIアプリ固有の開発時の注意点

生成AIアプリケーションを内製する上で、通常の開発で出てくる脆弱性やセキュリティ懸念事項に加えて、生成AIアプリケーション固有の懸念事項についてもカバーしていく必要があります。この点については、本ブログで良質な記事が沢山公開されているので必読です。（もちろん、通常の開発で出てくる脆弱性に対する記事も同様にカバーが必要なので、とても参考になります）

観点2: 入出力の保持、ゼロデータ保持について

生成AIに限った話ではないのですが、生成AIへの入出力情報がサービス上でユーザが使える履歴として、また、サービス側のメンテナンス上の都合で残るようになっている場合があります。サービス上にデータを残したくないという要望に沿うため、サービスによってゼロデータ保持の設定や申請を行うことができます。

  • AWS Bedrockでは入出力を保存しないと表明しており、まずはこのようなデータ保持に関する表記がなされていないかを探してみると良いです。ヘルプに限らず、利用規約なども同時に参照するとデータ保持に関するポリシーを理解することができます。
  • ゼロデータ保持（=データを保持しない）を申請することもできます。例えば、AnthropicではAPIに限り申請が可能です。
  • 不正行為の監視をサービス側が行ってくれている場合があります。この監視は必要に応じて、オプトアウト申請ができる場合があります。例えば、Azure AI FoundryやVertex AIのヘルプに関連する記載を見ることができます。

総合的なまとめと補足事項

最後にこれまでの話を踏まえて、会社で生成AIを利用する場合に考えるべき観点を紹介できなかった部分も含めて総合的にまとめていきましょう。

同様の評価観点と生成AI固有の観点

これまで見てきた様に生成AIに関連したサービスについても、基本的なWebサービスの構造としてはあまり変わりなく、これまでと同様の評価観点でリスク評価などが行えます。これまで、サービスが出している生成AIに関するページをたくさん引用しながら説明を進めてきました。ここ数年、生成AI利用の波がこれまでにないスピードでIT業界に押し寄せている中、安全な生成AI利用の理解に向けて周知を本当に各社努力されていると感じています。これらの資料も評価に非常に役立ちます。

同時に、生成AI固有の観点については、本稿で広く浅く触れてきました。他にも、本ブログで連日お伝えしている生成AIに関するセキュリティ情報を参考にしながら、利用にあたっての評価の参考にしていただきたいと思います。

生成AIの挙動の不安定さ

ここまでに多く言及してきた観点ですが、生成AIの挙動は基本的には不安定であることを前提におく必要があります。

生成AIが制御不可であることを示す、有名な攻撃としてプロンプトインジェクションがあります。悪意ある入力によって生成AIに想定外の動きを行わせる攻撃であり、これによって生成AIを利用するWebサービスが裏で利用しているプロンプト（システムプロンプト）が抜き取られるというケースも多発しています。現状、このようなプロンプトベースの攻撃を100%防ぐのは難しく、緩和による対策が行われているのが現状です。

blog.flatt.tech

生成AIの挙動は基本的には不安定であることを考慮し、生成AIに入力する情報については、匿名化のような前処理を行ったり、データ連携の認可を厳しくしながら生成AIが行える範囲を必要最小限にする。また、生成AIから出力される情報については人間が確認し、また、生成AIが重要な作業を行う場合は人間による承認を行う。そして、場合によっては生成AIの不安定さを許容できるかという方向性で考えるなど、不安定さを前提にしたシステム構成が求められます。

AIの利用に関するガイドライン

AIの安全な利用と利用推進のため、生成AIに関する利用規定やガイドラインを策定する企業や組織もでてきています。弊社でも社内向けにガイドラインを整備し、業務での利活用を進めています。特に、弊社の提供サービスの1つである脆弱性診断・ペネトレーションテストサービスにおいても生成AIを活用した高度化を進めております。NDAや利用規約に生成AIに関する条項を追記させていただきながら、また同時に、診断時の生成AI利用に関する資料を用意してお客様に理解いただくといった、生成AIを使ったサービス提供者としての責任を果たす為の活動を行いつつ、更なる価値をご提供していきます。

会社ごとにガイドラインにどのような内容を含めるかというのは様々かと思いますが、個人的には東京都の文章生成AI利活用ガイドライン・活用事例集が良いサンプルとして参考になるかと思います。都職員向けに書かれた利用者側にフォーカスしたガイドラインなのですが、

  • どういう生成AIサービスが利用でき、
  • どのような情報を入力してよく、
  • 生成AIへのプロンプトや生成物に対してどのような確認をするべきか

について非常に分かりやすく書かれています。

生成AIを使うと情報漏洩にならないか、生成AIの利用が少し怖いということから生成AIの業務での利活用を迷っている社員もいると思います。そのような社員にとって、ガイドラインという形で社内での利用促進を促し、ポジティブに生成AIを利用してもらうきっかけにできます。

前項に書いたように生成AI利用には不安定さが伴います。その不安定さに対する大きな対策の1つが人間によるチェックです。ガイドラインによってそういった点も社員へ共有するというのも、対策として重要な活動の1つになると思います。

また、複数の行政機関によって、会社や組織向けに発行しているガイドラインやガイドブックもあります。活用法に関する記載なども含まれており分量が多くて読むのが大変ですが、網羅的な確認の際には非常に役に立ちます。

1点注意点があり、AIの進化は目まぐるしいため、ここ1、2年くらいに公開された新しい資料を参照するのがおすすめです。例えば、今からAIの業務利用を考える場合では、業務データを使ってモデルをファインチューニングして…というよりかはRAGなどで業務データを参照させながら生成AIと連携したサービスを構築していくという方が多いと思うので、昔の資料だと現在の状況に合わせて読み替えが必要な部分もあります。

コーポレートエンジニアリング観点

最後にコーポレートエンジニアリング観点で生成AIに関するポリシー設定やモニタリング体制についてまとめて終えたいと思います。

生成AIを利用するWebサービスやアプリケーションの観点2でも書きましたがサービス側からポリシー設定ができる場合があります。必要に応じてAI関連機能を無効化するということもできるので、適宜活用することができます。

また、セキュリティ製品でもAI関連サービスに対応しているものがあるため、そちらでも細かなポリシー設定が行える場合があります。既に、AIサービスのブロックに活用している会社も多くあるのではと思います。

  • Zscalerでは「AI & ML Applications Rule」カテゴリがあり、ルールが追加できるようになっています
  • Defender for Cloud AppsでもGenerative AIというカテゴリによってAIの利用をモニタリング可能です
  • Ciscoは、Cisco AI DefenseというAIに特化したセキュリティソリューションを展開しています

生成AIの操作に関する監査ログについては、各社生成AIプロバイダもEnterpriseプランを用意するようになり、限定的ではありますが取得できるようになってきています。

  • 生成AIプロバイダのClaudeやOpenAIでもEnterpriseプランが用意され、監査ログが取得できるようになってきていて、Gemini for Google Workspaceでも一部の監査ログが取得可能です。プロンプトの含めた細かなログを取得したいという場合はサービス側が対応していない場合もあり、生成AIアプリケーションを自作して入出力を記録するという方法の検討も必要になります

おわりに

本稿では、コーポレートエンジニアから見た生成AI利用について考えるべきポイントをまとめて紹介してきました。実は社内でもTakumiを改造した社内AIエージェントが動いています。色々実験しながら動かしていますが、思ったような行動をさせるのは難しいですね。

この記事を書いている途中にMicrosoftからNative Support for MCP on Windowsが発表されました。まだまだ発展途上のMCPエコシステムですが、マーケットプレイスの展望やコード署名のようなプラクティスも入っていき、どんどん良くなっていくかもしれません。生成AI界隈は日進月歩で新しい機能がどんどん発表され、また、IoTにもAIが浸透していき、全てにAIが搭載される未来もそれほど遠くないように思います。このAIビッグウェーブを楽しみましょう！

お知らせ

GMO Flatt Securityは2025年3月から日本初のセキュリティ診断AIエージェント「Takumi」を開発・提供しています。Takumiを導入することで、高度なセキュリティレビューや巨大なコードベース内調査を月額7万円(税別)でAIに任せることができます。

また、セキュリティエンジニアによる脆弱性診断・ペネトレーションテストとして「LLMアプリケーション診断」を正式リリースしました。LLMを活用するアプリケーションの実装のセキュリティリスクをソースコード解析により網羅的に検出します。

今後ともGMO Flatt SecurityはAIエージェントを開発している組織だからこその専門的な深い知見も活かしながら、AIを活用するソフトウェアプロダクトにとって最適なサービスを提供していきます。公式Xをフォローして最新情報をご確認ください！

  1. サムスンやAmazonでの例があります↩

flattsecurity 読者になる

関連記事