こんにちは、クロスイノベーション本部リーディングエッジテクノロジーセンターの大岡叡です。 私は、昨年AWS資格を全種類取得しまして、現在Google Cloudの資格勉強をしております。 AWS資格の勉強法をGoogle Cloudの資格勉強にも適用しようと考え、勉強方法の改善検討をしたところ、AIで自動化できる部分があることに気づきました。本記事では、これまでの勉強法の課題、その課題に対するAIを用いた解決策、そして実際に導入してみての所感をお伝えしたいと思います。 これまでの勉強法の課題 AIを用いた解決策 作成したスキル: /mq（Make Question） スキルを使うための準備 使い方 【Google Cloudに関する問題を作成（メインの使い方）】 【AWSサービスとの比較問題を作成】 【一般的な知識問題を作成】 導入してみての所感 まとめ これまでの勉強法の課題 これまでのAWS資格勉強は以下のフローで進めていました。 【1問ごとに以下を繰り返す】 1. 問題集を解く 2. 分からなかった知識を公式ドキュメントで調べる 3. Notionに問題形式でまとめる（後から復習に活用） この中で2と3にかなり時間がかかっていました。 AIを用いた解決策 課題であった「公式ドキュメントの調査」と「Notionへの問題作成」を、 Claude Codeのスキル機能 を使って自動化しました。 作成したスキル: /mq （Make Question） 作成したスキルはこちら（クリックで表示） --- name: mq description: Google Cloud資格試験の勉強用に、問題を1問Notionにtoggle形式で作成する。問題文を指定して呼び出す。 user-invocable: true argument-hint: "<問題文>" --- # 試験勉強用 問題作成スキル ユーザーが指定した問題文に対して、正確な情報に基づいた回答を調査し、Notionページにtoggle形式で1問追加する。 ## 対象Notionページ - **ページURL**: ` https://www.notion.so/Page-Title-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ` - **ページID**: ` xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ` ## ページ構造 このページには以下の2つのセクションがある: - ` ## Google Cloudに関する知識 {color="orange_bg"} ` — Google Cloud関連の問題を配置 - ` ## 一般的な知識 {color="orange_bg"} ` — それ以外の一般的な知識の問題を配置 ## toggleのフォーマット（Notion-flavored Markdown） 回答作成時・Notion挿入時の両方で使うフォーマット。子要素は必ずタブでインデントすること（インデントしないとtoggle外に出てしまう）。 ``` <details> <summary>**{問題文}**</summary> {回答テキスト} - {箇条書きポイント1} - {箇条書きポイント2} - {箇条書きポイント3} <empty-block/> **参考URL:** - [{ページタイトル1}]({URL1}) - [{ページタイトル2}]({URL2}) </details> ``` ## 実行手順 ### Step 1: 問題の分類 問題文の内容が以下のどちらに該当するか判断する: - **Google Cloud関連**: Google Cloudのサービス・機能に関する問題全般。例: Compute Engine、GKE、Cloud Run、Cloud Storage、BigQuery、VPC、IAM、Cloud SQL、Pub/Sub、Vertex AI、Gemini on Google Cloud など。Googleが開発・提供するモデルやツール（Gemma、Gemini、Imagen、NotebookLM、Google AI Studio等）もこちら - **一般的な知識**: Google固有でない技術知識全般。例: ネットワーキング（TCP/IP、DNS、ロードバランシング）、データベース理論（ACID、CAP定理）、セキュリティ（暗号化、ゼロトラスト）、コンテナ・Kubernetes一般、CI/CD、IaC、機械学習の一般理論、AI倫理、プロンプトエンジニアリング、ソフトウェアアーキテクチャ など ### Step 2: 情報収集 & 挿入位置の特定（並行実行可） 以下の2つは独立しているので、並行して実行してよい。 #### 2a: 情報収集 **Google Cloud関連の場合:** 1. ` mcp__google-dev-knowledge__search_documents ` で公式ドキュメントを検索 2. 検索結果から最も関連性の高いドキュメントの ` parent ` を使い、 ` mcp__google-dev-knowledge__get_documents ` で**必ず**フルドキュメントを取得する（検索結果のチャンクだけで回答を作成しない） 3. 取得したドキュメントが問題の回答に不十分な場合は、以下を試みる: - 同じ検索結果内の別のドキュメントを ` get_documents ` で取得する - 別のキーワードで ` search_documents ` から再検索する 4. 取得したドキュメントのURLを参考URLとして記録 **一般的な知識の場合:** 1. ` WebFetch ` または ` WebSearch ` で信頼できるソースから情報を収集 2. 参考URLを記録 3. Wikipediaは参考URLとして使用しない。以下のような権威あるソースを優先する: - クラウド・インフラ: AWS公式ドキュメント、Microsoft Learn、Red Hat、CNCF - ネットワーク・セキュリティ: IETF RFC、OWASP、NIST、Cloudflare Learning - データベース・データ: PostgreSQL/MySQL公式ドキュメント、MongoDB University - AI/ML: Google for Developers、IBM、NVIDIA Developer Blog、大学サイト（Stanford等） - 一般技術: 著名な技術ブログ（Martin Fowler、InfoQ、DataCamp等） **AWSの知識が必要な場合（カテゴリ問わず）:** 問題の回答にAWSサービスの知識が必要な場合: 1. ` mcp__aws-documentation-mcp-server__search_documentation ` でAWS公式ドキュメントを検索 2. 検索結果から最も関連性の高いページのURLを使い、 ` mcp__aws-documentation-mcp-server__read_documentation ` で**必ず**フルドキュメントを取得する（検索結果のcontextだけで回答を作成しない） 3. 取得したドキュメントが問題の回答に不十分な場合は、以下を試みる: - 同じ検索結果内の別のページを ` read_documentation ` で取得する - 別のキーワードで ` search_documentation ` から再検索する - ` recommend ` で関連コンテンツを探す 4. 必要に応じて ` mcp__aws-documentation-mcp-server__recommend ` で関連コンテンツも探す #### 2b: 挿入位置の特定（state.json） ` state.json ` （スキルと同じディレクトリ）を ` Read ` ツールで読み取り、対象セクションの最後の参考URL行を取得する。 - **Google Cloud関連**: ` google_cloud_last_ref ` の値を使う - **一般的な知識**: ` general_last_ref ` の値を使う ` state.json ` が存在しない場合のみ、 ` mcp__notion__notion-fetch ` でページ全体を取得し、各セクションの最後の参考URL行を特定する。 ### Step 3: 回答の作成 収集した情報に基づき、上記のtoggleフォーマットで1問分の回答を作成する: - 正確かつ簡潔な回答。箇条書きで要点を整理 - 参考URLは必ず含める - 作成するのは **1問のみ** ### Step 4: Notionページを更新 ` mcp__notion__notion-update-page ` を使って、適切なセクションにtoggleブロックを1つ追加する。 #### 挿入方法: replace _ content _ range ` insert_content_after ` は使わない（ ` </details> ` がページ内に多数存在し、 ` ... ` で繋ぐと複数マッチしてエラーになるため）。 Step 2bで取得した参考URL行をセレクタの起点に使い、 ` replace_content_range ` で置換する。 **セクション内にtoggleが既にある場合:** 最後のtoggle内の参考URL最終行から、セクション直後のランドマークまでを ` selection_with_ellipsis ` で指定する。 - **Google Cloudセクションのランドマーク**: ` ## 一般的な知識 {color="orange_bg"} ` - **一般的な知識セクションのランドマーク**: ` <empty-block/> ` （ページ末尾のもの。参考URL起点なら一意になる） ` new_str ` には、参考URL最終行 + ` </details> ` + 新しいtoggle + ランドマーク をすべて含める。 実例（Google Cloudセクション）: ``` selection_with_ellipsis: "arXiv](https://arxiv.org/abs/2406.11409)...## 一般的な知識 {color=\"orange_bg\"}" new_str: {最後の参考URL} </details> {新しいtoggle} ## 一般的な知識 {color="orange_bg"} ``` 実例（一般的な知識セクション）: ``` selection_with_ellipsis: "{最後の参考URL}...<empty-block/>" new_str: {最後の参考URL} </details> {新しいtoggle} <empty-block/> ``` **セクション内にtoggleがない（空のセクション）場合:** セクション見出し＋改行＋ ` <empty-block/> ` をフルテキストで ` selection_with_ellipsis ` に指定する（省略 ` ... ` は使わない）。 #### selection _ with _ ellipsis のルール 1. **セレクタ内で `...` の前後それぞれ最低20文字以上を確保する**（短すぎると一意にならない） 2. **`</details>` をセレクタの終端に使わない**（ページ内に多数存在し、複数マッチする） 3. **セクション見出し単体をセレクタに使わない**（2件マッチする）。ただし、ランドマーク（セレクタ末尾）として使う場合は、開始位置が一意な参考URLなので問題ない 4. **空セクションでは `...` を使わず、フルテキストを指定する**（ ` <empty-block/> ` が複数箇所にあるため ` ... ` を使うと複数マッチする） 5. **`{{}}` を使わない**: ` notion-fetch ` ではURLが ` {{https://...}} ` 形式で返されるが、セレクタには ` {{}} ` なしのURLを使う #### 挿入失敗時のフォールバック ` replace_content_range ` が失敗した場合、 ` state.json ` のキャッシュが古い可能性がある: 1. ` mcp__notion__notion-fetch ` でページ全体を取得 2. 対象セクションの最後の参考URL行を特定し直す 3. 正しいセレクタで再度 ` replace_content_range ` を実行 4. 成功後、 ` state.json ` を更新する ### Step 5: state.json の更新 挿入が成功したら、 ` state.json ` を ` Edit ` ツールで更新する。今回追加したtoggleの参考URL最終行で、対象セクションのキーを上書きする。 - **Google Cloud関連**: ` google_cloud_last_ref ` を更新 - **一般的な知識**: ` general_last_ref ` を更新 これにより、次回のスキル実行時にフルフェッチなしで挿入位置を特定できる。 ## 出力例 ``` <details> <summary>**Vertex AI Searchとは何ですか？主な機能と用途を説明してください。**</summary> Vertex AI Searchは、Google Cloudが提供するエンタープライズ向けの検索ソリューションです。 - Webサイト、構造化データ、非構造化データに対して高品質な検索体験を提供 - LLMを活用した自然言語での検索が可能 - RAG（Retrieval-Augmented Generation）パターンの実装に活用できる <empty-block/> **参考URL:** - [Vertex AI Search overview](https://cloud.google.com/generative-ai-app-builder/docs/enterprise-search-introduction) </details> ``` 今回作成したのは、 問題文を渡すだけで、公式ドキュメント調査からNotionへの問題・解答作成までを一気通貫で行うスキル です。 公式ドキュメントの調査は、Google Developer Knowledge MCPとAWS Documentation MCPを使用し、Notionへの問題・解答作成はNotion MCPを利用します。 以下がNoteBookLMに作ってもらった、このスキルのイメージです。 スキルを使うための準備 以下の準備が必要です。 上記スキルのマークダウンを SKILL.md として作成し、任意のディレクトリの .claude/skills/mq/ 配下に配置する。 Google Developer Knowledge MCPをセットアップする。 Developer Knowledge MCP公式ドキュメント に従って、APIキーを発行する。 以下のコマンドを .claude があるプロジェクトルートで実行する。 YOUR_API_KEY の部分には、発行したAPIキーの値を入力する。 claude mcp add google-dev-knowledge --scope project --transport http https://developerknowledge.googleapis.com/mcp --header "X-Goog-Api-Key: YOUR_API_KEY" AWS Documentation MCPの設定をする。以下のコマンドをプロジェクトルートで実行する。 claude mcp add aws-documentation-mcp-server -s project -e FASTMCP_LOG_LEVEL=ERROR -e AWS_DOCUMENTATION_PARTITION=aws -- uvx awslabs.aws-documentation-mcp-server@latest Notionの準備及びNotion MCPの準備 以下のスクショのように、Notionのページに「Google Cloudに関する知識」と「一般的な知識」のセクションを作成する。 ## 2つの文字サイズで、背景色をオレンジに設定する。（ページのタイトルは受験する資格名など何でもよい。） Notion MCPの設定をする。以下のコマンドをプロジェクトルートで実行する。 claude mcp add --transport http notion --scope project https://mcp.notion.com/mcp Notionの認証＆スキル更新 プロジェクトルートでClaude Codeを立ち上げ、 /mcp コマンドを使用してNotion MCPの認証を通す。 以下のプロンプトをClaude Codeに投げる。 <あなたのNotion URL> の部分は、4. で作成したNotionのページのURLに置き換える。 <あなたのNotion URL> .claude\skills\mq\SKILL.mdのページURLとページIDを上記URLに基づいて更新してください。 以上で準備は終わりです。 使い方 【Google Cloudに関する問題を作成（メインの使い方）】 プロジェクトルートでClaude Codeを起動し、以下のように入力するだけです。 /mq Cloud Runとは何ですか？ するとClaude CodeがGoogle Developer Knowledge MCPを用いて、公式ドキュメントを取得し、正しい情報に基づいて問題・解答を自動でNotion上に作成してくれます。 toggleの中身の一番下に参考URLが書かれ、公式ドキュメントへの導線が張られています。 【AWSサービスとの比較問題を作成】 AWSサービスとGoogle Cloudを比較する問題も作成できます。 その場合は、Claude CodeはGoogle Developer Knowledge MCPだけでなくAWS Documentation MCPを利用して、正しい情報に基づいて問題・解答の作成をしてくれます。 【一般的な知識問題を作成】 クラウドベンダー資格は、問題を解くうえで一般的なIT知識が必要になることも多くあります。 その一般的な知識をまとめるセクションも用意しており、クラウドサービスには関係のない問題も作成することができます。 やり方は同じで、以下のようなプロンプトをClaude Codeに投げます。セクションの分別はClaude Codeがよろしくやってくれるようにスキルで定義しています。 /mq OIDCとOauth2.0の違いは？ 導入してみての所感 このClaude Codeのスキルを使用した勉強をして、先日 Google Cloud Generative AI Leader に無事合格しました。 今まで時間がかかっていた「公式ドキュメントの調査」と「Notionへの問題作成」をClaude Codeに全任せできたので、「問題を解く」・「知識を暗記する」この二つに集中でき、学習効率が飛躍的に向上したように感じました。 まとめ 今回はClaude Codeのスキルを使って勉強効率を上げた話をご紹介しました。 少しでも皆さんが資格勉強をする際の参考になったら嬉しいです。 最後までお読みいただきありがとうございました！ 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @ooka.toru レビュー： @miyazawa.hibiki （ Shodo で執筆されました ）

はじめに 近年、ソフトウェア開発において「SBOM (Software Bill of Materials)」というワードを聞くことが増えてきました。 経済産業省が公開するソフトウェア管理に向けたSBOM (Software Bill of Materials) の導入に関する手引 ver 2.0において、「ソフトウェアコンポーネントやそれらの依存関係の情報も含めた機械処理可能な一覧リスト」として説明があるように、SBOMはソフトウェア部品表として広く認識されています。 SBOMに関する記事はこちらもおすすめ SBOMは単なる概念や考え方にとどまらず、実際に運用・共有することを前

イベント概要とこの記事の目的 法人ディベロップ課のS.Sです！ 日々、アプリケーションエンジニアとして、法人ソリューション事業部向き合いで、サービスの開発・保守を行なっております。 先日、AWS のセキュリティイベント 「Security for App Builders @ Loft #1」  に参加してきました。 私は、セキュリティ専門ではないアプリケーションエンジニアですが、 このイベントで、セキュリティへの関心がよりより湧き、 未然に防ぐ具体的なアクションに取り組まねばな、と改めて思わされました。 この記事では、 「Security for App Builders @ Loft #1」 で、何を学んだのかを記すとともに、 「アプリケーションエンジニアで、セキュリティについて気にはなっている」という方の参考になれば幸いです。 改めて、この記事の内容・目的は、以下の 4 点です。 イベント内セッションの概要を記載しつつ、学びと理解を整理する アプリケーションエンジニアのセキュリティ意識や理解を深めてもらう セッション内容の共有と、背景知識やちょっぴりの深掘り情報の共有 セキュリティ専門じゃないアプリエンジニアとして、「これから試してみたい脅威の洗い出しのやり方」のたたき台をまとめる そこそこの分量になっているので、気になるタイトルをポチポチとかいつまんで見ていただけると幸いです。 なぜ、今、アプリケーションエンジニアがセキュリティを強く意識すべきなのか OWASP Top 10 とアクセス制御の不備 冒頭で触れられていたのが  OWASP Top 10  です。 OWASP Top 10 は、Web アプリケーションの代表的なリスクを 10 項目に整理したもの 直近の正式版は  OWASP Top 10: 2021  で、たとえば A01:2021 – Broken Access Control（アクセス制御の不備） A02:2021 – Cryptographic Failures… といった分類があります セッションでは、 OWASP のデータに基づき、「アクセス制御の不備」が一定割合（3.73%）で見つかっている という話がありました。 プロのエンジニアの手で開発されたサービスにおいて、アクセス制御の不備という重大な脆弱性が、およそ4%（100件に4件）も起こり得てしまうという点に驚いたとともに、エンジニアとしてお仕事を続けていれば、誰しも1度は発生させてしまうくらいの可能性があるなと背筋が伸びました。 参考： OWASP Top 10:2021 (英語) https://owasp.org/Top10/ Broken Access Control の解説 (英語) https://owasp.org/Top10/A01_2021-Broken_Access_Control/ シフトレフト：後になるほどコストが跳ね上がる 工数やスケジュールが限られた中での開発で、往々にしてセキュリティ対応は後回しにされてしまいます。 けれども、セキュリティ対応は、 開発ライフサイクルの早い段階で取り込むほど「コストは低い」「被害は小さい」 ので、むしろ開発サイクルのはやい段階で取り組むべしというお話でした。 仕様検討（要件定義）で気づく → 仕様の一部修正で対処可能 実装中に気づく → 実装の修正で対応可能 リリース後に顧客やインシデントで気づく → 影響調査、データ復旧、顧客への説明、信用回復など大きなコスト 絵にするとこんな感じです。 この「セキュリティを開発プロセスの左側に寄せる」考え方が 、 Shift-left（シフトレフト）  です。 矛盾しているように聞こえますが、工数やスケジュールが限られているからこそ、開発サイクルの中でも、なるったけ早くに、セキュリティ対応をすべしということですね。 参考： DevSecOps とは何ですか? https://aws.amazon.com/jp/what-is/devsecops/ AWS Well-Architected Framework – Security Pillar https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html ビルダーのための脅威モデリング さて、ここからが、今回のタイトルに直結する部分です。 （サビです） 「脅威モデリング」とは何か こちらのセッションでは、まず「脅威モデリング」の定義から整理されました。 脅威モデリングとは システムに対する脅威を特定・列挙し、 それぞれにどう対応するかを検討し、優先順位をつけるプロセス 開発ライフサイクルで置く場所は、 計画 → 設計（ここで脅威モデリング） → ビルド → テスト → デプロイ → 保守 です。 絵にするとこうです。 参考： OWASP Threat Modeling Cheat Sheet (英語) https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html AWS Prescriptive Guidance – Threat modeling on AWS (英語) https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/threat-modeling.html 脅威モデリングの進め方 セッションで紹介されていた流れは、以下の 4 ステップでした。 「何を作っているか」を明確にする アーキテクチャ図 データフロー図 何が問題になり得るか洗い出す チームで脅威を議論する 対応方針を決め、優先順位をつける ここでのポイントは、 可視化をして、PJメンバー全員で前提・問題の認識を揃えること → 図がないと、どこに攻撃面があるか議論できない 1 回きりではあまり意味がなく、ライフサイクルに組み込む必要がある という点です。 絵にするとこうです。 STRIDE など、代表的なフレームワーク 脅威モデリングでは、次のようなフレームワークが紹介されました。 STRIDE DREAD PASTA（Process for Attack Simulation and Threat Analysis） Trike VAST（Visual, Agile, and Simple Threat） OCTAVE（Operationally Critical Threat, Asset, and Vulnerability Evaluation） 今回、取り上げられていたのは  STRIDE  でした。 網羅性が高く、チームでの議論の「型」として使いやすい のが理由です。 STRIDE の 6 要素 S: Spoofing identity（なりすまし） 攻撃者が正当なユーザーやシステムであるかのように振る舞うこと 例: 攻撃者が他人のIDとパスワードを不正に入手し、そのユーザーになりすましてシステムにログインする 例: 偽のWi-Fiアクセスポイントを設置し、正規のネットワークであるかのように見せかけて接続させる T: Tampering with data（改ざん） データや通信内容を許可なく変更すること 例: オンラインバンキングの通信を傍受し、送金金額や送金先口座番号を書き換える 例: Webサイトの設定ファイルを書き換え、訪問者を悪意のあるサイトへリダイレクトさせる R: Repudiation（否認） ユーザーが行った操作やアクションを「やっていない」と主張できる状態、またはその証拠がないこと 例: ログ機能が不十分なシステムで、従業員が不正なデータ削除を行ったが、「自分はやっていない」としらを切られ、証拠が出せない 例: 電子署名がないメールで契約の承認を行い、後になって「そのようなメールは送っていない」と主張される I: Information disclosure（情報漏えい） 機密情報が権限のない人間に閲覧・公開されること 例: データベースの設定ミスにより、顧客のクレジットカード情報がインターネット上で誰でも閲覧できる状態になる 例: エラーメッセージに詳細なシステム内部情報（パスやDB構造など）が表示され、攻撃者にヒントを与えてしまう D: Denial of service（サービス拒否） 正当なユーザーがサービスやリソースを利用できない状態にすること 例: Webサーバーに大量のアクセス（DDoS攻撃）を送りつけ、サーバーをダウンさせて一般ユーザーが閲覧できないようにする 例: アカウントロック機能を悪用し、わざとパスワードを何度も間違えて特定ユーザーのアカウントをロックさせる E: Elevation of privilege（権限昇格） 本来持っている権限以上の操作ができるようになること 例: 一般ユーザーとしてログインした攻撃者が、システムの脆弱性を突いて管理者（root/admin）権限を奪取する 例: URLのパラメータを書き換えることで、本来アクセスできない他人の注文履歴ページを閲覧・操作する これを「自分たちのシステム構成図・データフロー図」に対して当てはめていくことで、脅威モデリングができます。 参考： Microsoft – The STRIDE Threat Model (英語) https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats OWASP Threat Modeling Cheat Sheet 内の STRIDE 解説 (英語) https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html#stride ドメイン特有の脅威に目を向ける 一般的に、下記のような 共通の脆弱性  は見つけやすいですが、 SQL インジェクション XSS 典型的な認証バイパス ビジネス／ドメイン特有の脅威  は見逃されがちです。 例： EC サイト 在庫数や価格の改ざん ポイント／クーポンの不正利用 B2B SaaS テナント分離の不備による他社データ閲覧 管理権限の誤委譲・誤設定 サブスクリプションサービス 無料トライアルの不正延長 請求先のなりすまし 脅威モデリングでは、こういった「そのサービス特有のリスク」を意識的に洗い出せる点が大きな価値です。（ドメイン理解の深い事業会社のエンジニアの価値発揮できるポイントですね） チームでやることの意味 脅威モデリングは、セキュリティ専門家だけの作業ではない、「チームでやるべきことである」ということが強調されていました。 プロダクトオーナー アプリケーションエンジニア インフラ／SRE セキュリティ担当 など複数ロールで実施することで、 「多様なペルソナ（攻撃者像・利用者像）」を出し合える 見落としが減る という効果があります。（今の時代は、更に、AI というもう一人の存在の力も借りるのも有効ですね） セキュリティ専門じゃない自分が「脅威の洗い出し」をどう始めたいか 正直な所、私はまだ、日々の開発の中で、 本格的な脅威モデリングを回せていないです。 （新規開発や保守をしていく上での脆弱性診断や対策は行ってはいますが） このセッションを聞いて、「まずはこのくらいのスコープからなら試せそう」と感じたものがあったので、簡単に流れを書いておこうと思います。 新しい機能や API を作るときだけでもよいので対象を絞る ざっくりした構成図・データフロー図を描く（ホワイトボードや Miro 等の書き出せるものでOK） STRIDE の 6 つを観点にして 、「なりすましは？」「改ざんは？」「情報漏えいは？」… を見ていく 出てきた脅威のうち 「すぐ直せそうなもの」 「影響が大きいもの」 を対策に落とす AI を活用した脅威モデリング支援 後半戦では、 AI を活用して脅威モデリングの手間を減らす という話が出ていました。 登場したのは「AI エージェント」的なコーディング／解析支援のイメージで、AWS でいえば  Amazon Q Developer  ですね。（今は、 kiro  ですね） AI にやらせる部分 vs 人間がやる部分 スピードや網羅性に関しては、AI の方が人間よりも優れていることが多いので、うまくAIと人間で分業をして協業することが重要そうだなと感じました。 AI に任せやすい部分： ワークロードの図式化 アーキテクチャ説明文から簡易図を生成させる 想定される脅威の洗い出し 「この構成に対して STRIDE 観点で脅威を列挙して」 想定される脅威への一般的な対応策の候補出し リスク評価のたたき台 「影響度が高そうな順に並べて」 人間が担うべき部分： 脅威モデリングそのものの意義と目的の理解 事業やサービスのドメイン周りの脅威洗い出し 「何を対象に、何のために」脅威モデリングするかの設定 事業戦略・リスク許容度に基づく  優先順位付けと最終判断 「 AI は“脅威のたたき台”を出してもらうところまで 」と割り切り、 最後の判断と、プロダクト側への落とし込みは人間がやる といった線引きで使っていきたいと感じました。 セキュリティのシフトレフトと AI 活用 攻撃は 100% 防げないが、被害は限定できる このセッションは、 「リスクをゼロにはできないが、 被害を限定し、復旧を容易にすることはできる」 という前提から出発していました。 例として挙げられたランサムウェア攻撃の典型フロー： ネットワークスキャン 脆弱性の調査・悪用 ランサムウェアの設置 ランサムウェアがターゲットシステムで動作 情報の窃取や暗号化 どこか一段階でも早く検知・防御できれば、 「完全な被害」から 「一部のシステムだけ」「一部データだけ」で済む可能性が高まる という話です。 DevSecOps と AI の進化 2015年ごろから、セキュアコーディングについて、叫ばれていたが、業務に落とし込むことが物理的な制約のため難しかったけれど、2025年現在のAI の進歩により、実現可能になったので、今こそ改めて、セキュアコーディングへチャレンジをしていけるのではないかというお話でした。 2015 年ごろ DevSecOps という言葉が広がり始める ただしセキュアコーディングの学習コストが大きい 静的解析ツールなどから出る大量のアラートを人力でさばくのは現実的でない 2025 年 AI コーディングエージェントが静的解析結果を解釈し、「どこをどう直すか」まで提案 AWS の例では Amazon Q Developer による 調査（現状のコード理解、セキュリティチェック） ビルド（修正案の提案・コード生成） テスト（テストコード生成） デプロイ（PR レビュー支援、ドキュメント生成） といったフローが紹介されていました。 確かに、やりたい気持ちはあれど、なかなか手を出せていなかったですが、AI エージェントの誕生によって、良い意味で、もうそんな言い訳もできなくなったなと思いました。（← もうやってないは、怠慢かも?） 参考： DevSecOps とは何ですか? https://aws.amazon.com/jp/what-is/devsecops/ Amazon Q Developer でのコード解説や修正の例 https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is-q-developer.html セキュリティトレーニングのテーマ アプリケーションエンジニア向けに、特に挙げられていたテーマは、 ガバナンスとコンプライアンス セキュアコーディング リスクマネジメント ここでも AI を「学びの相棒」として使う例として、紹介されていました。 利用 OSS やライブラリについて 「このライブラリに既知の脆弱性はあるか？」 「この CVE（脆弱性）の影響度と対策を教えて」 自分のコードに対して 「ハードコードされたパスワードやシークレットがないか探して」 「この関数にセキュリティ上の問題はありそうか？」 これについては、既に行なっていましたが、すぐに試せて、かつ、有効な使い方だなと改めて思いました。 IAM 権限設計と IAM Access Analyzer IAM の権限設計に関しても重要なポイントがありました。 「最小権限を人間だけで完全に設計しきろうとすると、どうしても穴が出やすい」 そこで活用が推奨されていた AWS サービスが  IAM Access Analyzer  です。 AWS Identity and Access Management Access Analyzer https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html 機能の例： IAM ポリシーを解析し、「外部アカウントからアクセス可能なリソース」を検出 ポリシーの提案（Policy generation） 実際のアクセスログを分析して、「このロールに必要な最小権限」のポリシー案を生成 ここでも AI を組み合わせると、 「このポリシー JSON はどの権限をどこまで許可しているか、自然言語で説明して」 「最小権限化するために、削れそうなアクションはどれか？」 といった質問を投げることで  理解と設計の速度を上げられる 、という話でした。 自分自身、インフラ側への苦手意識が強いですが、こういった活用法を用いることで、AIエージェントの力を借りつつ、知識習得と堅牢な実装の両方を猛スピードで行なっていけるのでは？とワクワクしました。 マネージドサービスと認証・認可はビジネス差別化になり得る AI が書いたコードのセキュリティオーナーは誰か？ 登壇者の方の問いかけ： 「AI が生成したコードをそのまま本番投入してよいのか？ その結果に対するセキュリティの責任は誰が持つのか？」 結論としては、 「 全員がセキュリティのオーナー 」 あくまで、AI は「候補」を出してくれる 存在 それを採用するかどうか、どうレビューするかは人間と組織の責任 ということでした。 本当にこの通りで、最後に出す判断を下すのは我々人間なので、これまで以上に、出すものは、本当にこれで問題がないのかは、厳格に見極める必要があるなと感じました。 Culture of Security AWS では、社内外で継続的に、 セキュリティに関する発信 勉強会 事例共有 インシデントからの学びの共有 を行い、トップダウンで  「Culture of Security」  を作っているという紹介がありました。 組織やPJ のトップが、セキュリティへの関心や発信を積極的に行うことが、セキュリティへの意識・行動を想起するには重要とのことでした。 参考： AWS セキュリティ文化 https://aws.amazon.com/jp/security/culture-of-security/ AWS Security Blog 一覧 https://aws.amazon.com/blogs/security/ 認証・認可設計は「ビジネス差別化」にもなる 特に印象に残ったのが、 「優れた認証・認可の仕組みは、 セキュリティ対策であると同時に、ビジネスの差別化要因になる」 というお話でした。 各サービスごとにバラバラなユーザー管理をしている ユーザー体験：ログインが面倒、アカウントが分散 事業側：サービス横断の体験・クロスセルが難しい 統合された認証・認可基盤がある 一度ログインすれば複数サービスをシームレスに利用可能 ユーザー行動を横断的に把握できる セキュリティ設計がそのまま UX と事業戦略に効いてくるという例ですね。 認可アーキテクチャの用語整理 認可ロジックをアプリコードにべた書きせず、外部の仕組みに任せやすくするための概念として、以下の用語が紹介されていました。 PEP: Policy Enforcement Point 実際のアクセス要求をブロック／許可する「ゲート」 PDP: Policy Decision Point ポリシーに基づき「許可／拒否」の判定を行うコンポーネント PAP: Policy Administration Point ポリシー（ルール）を管理・編集するコンポーネント PIP: Policy Information Point 判定に必要な属性情報（ユーザー属性、リソース属性など）を提供するコンポーネント この分離により、アプリ側コードは「PEP と対話するだけ」で済み、 認可ルール自体は外部で一元管理しやすくなるとのことでした。 参考： AWS – Amazon Verified Permissions（ポリシーベースの認可サービス） https://aws.amazon.com/jp/verified-permissions/ セキュリティ専門じゃないアプリケーションエンジニアとして、始めてみたい「脅威の洗い出し」（＋AI 活用） 最後に、これまでのセッション内容を踏まえて、 実際に現場で「脅威の洗い出し」をどう始めてみたいか を、具体的な手順として書いてみます。 これから試してみたい「ざっくり手順」 まず、 自分用の「脅威の洗い出し」のざっくり手順（案） はこんなイメージです。 対象を決める いきなり全システムではなく、「これから作る 1 機能 / 1 API」くらいにスコープを絞る ざっくり図を描く 画面遷移 or API と外部サービスの関係、データフローを簡単に図にする 守りたいものを挙げる ユーザー情報、決済情報、社内の機密データ、ポイント残高 など STRIDE を観点に「脅威のたたき台」を AI に出してもらう AI の結果を見ながら、チームで 60〜90 分だけ議論する 「今すぐ対応するもの」を 2〜3 個だけ決めて、実装・レビューに反映する 仕様書を AI に渡して「脅威のたたき台」を作る 要件定義書・仕様書・画面遷移図などを AI に渡して、 「この仕様から想定されるセキュリティリスクを、STRIDE の観点で列挙して」  と依頼する その出力をもとに、チームで 60〜90 分の脅威モデリングミーティングを行う 「AI は“思いつきの網羅”担当、人間は評価と意思決定担当」  くらいに役割分担するイメージで進められたらと思います。 依存ライブラリの脆弱性を AI に要約させる これもすぐにできて、セキュリティリスクを抑える有効な手段なので、書いておきます。 npm audit ​ などの結果や、SCA ツールのレポートを AI に渡し、 「特に優先度が高いものはどれか？」 「どのライブラリは自分たちのアーキテクチャでは影響が小さそうか？」 を整理してもらう これにより、 「アラートの山」から「今すぐ直すべき山」を特定 して、優先度の高い脆弱性を潰せる可能性を高めます。 既存コードベースの「簡易セキュリティ健診」 重要なモジュールや API ハンドラを中心に、AI に次のような観点で探してもらう ハードコードされたパスワード／API キー 認証・認可チェックが抜けていそうなエンドポイント 危険な関数（ eval ​ など）の利用 その結果から「怪しい箇所リスト」を作り、 人間が一つずつレビューしていく AI には広く粗く見てもらって、最後の判断は人間で、という分業で進められたらと思います。 セキュリティ文化を根付かせる動き 脅威の洗い出しを 一度きりのイベントにしない ために、 次のような小さな仕掛けをチーム内で提案してみたいと思っています。 大きな機能追加のたびに 「脅威モデリングをやったか？」をチェックリストに入れる 月 1 回程度の 「インシデント／ヒヤリハット共有会」を開く 上長に、セキュリティ文化を根付かせる発信やアクションを提案する （この記事を読んで頂こう） ここにあげた手段を提案し、発信や実際に定期的イベントを行う いきなり、大きく完璧にやろうとすると、大抵続かない、うまくいかないので、まずは 「新しい機能を作るタイミングで、脅威モデリングを行う」 ところから始めてみたいと考えています。 ゆくゆくは、組織単位で、例えば上記のようなことが浸透していけることが最終ゴールにできればなと思います。 現時点では、ここに書いた「脅威の洗い出しのやり方」はあくまで これから試してみたい案 です。 実際に回してみてうまくいった点・うまくいかなかった点が見えてきたら、続編としてアップデートしていきたいと思います。 追記 開発で携わっているPJ で、早速、新規API を作成する機会ができたので、早速、脅威モデリングをお試しでやってみようとなりました。 初回なので、あまりに厳密にやりすぎず、脅威モデリングにおいて、重要な要素をシンプルに抽出して、進めていきます。 「実際に、やってみた」の記事も書けたら、書きます。