[{"data":1,"prerenderedAt":839},["ShallowReactive",2],{"/ja-jp/blog/what-is-sbom":3,"navigation-ja-jp":44,"banner-ja-jp":465,"footer-ja-jp":475,"blog-post-authors-ja-jp-GitLab Japan Team|GitLab":709,"blog-related-posts-ja-jp-what-is-sbom":736,"blog-promotions-ja-jp":778,"next-steps-ja-jp":830},{"id":4,"title":5,"authorSlugs":6,"authors":9,"body":12,"category":13,"categorySlug":13,"config":14,"content":18,"date":26,"description":19,"extension":28,"externalUrl":29,"featured":17,"heroImage":21,"isFeatured":17,"meta":30,"navigation":17,"path":31,"publishedDate":26,"rawbody":32,"seo":33,"slug":16,"stem":38,"tagSlugs":39,"tags":42,"template":15,"updatedDate":27,"__hash__":43},"blogPosts/ja-jp/blog/what-is-sbom.md","SBOMの基本と導入方法｜ソフトウェアのセキュリティを守るための実践ガイド",[7,8],"gitlab-japan-team","gitlab",[10,11],"GitLab Japan Team","GitLab","ソフトウェア開発において、セキュリティリスクへの対応は年々重要性を増しています。特に、OSS（オープンソースソフトウェア）の普及に伴い、脆弱性管理やライセンス対応の課題に直面している方も多いのではないでしょうか。\n\nこうした中で注目を集めているのが、ソフトウェアの構成要素を可視化する「SBOM」です。本記事では、SBOMの基本知識や注目されている背景、導入方法などを詳しく解説します。セキュリティの強化や開発の効率化を目指す方は、ぜひ参考にしてください。\n\n## 1. SBOMとは？基本知識と重要性\n\nSBOMは「Software Bill of Materials」の略で、ソフトウェアに含まれるすべての構成要素（コンポーネント）を一覧化した「部品表」のことです。\n\nSBOMには、使用されているOSS、サードパーティ製ライブラリ、独自開発のコンポーネントなど、ソフトウェアを構成するすべての要素を記載します。各コンポーネントのバージョン情報、ライセンス情報、依存関係なども含まれており、これらの情報を一元管理し、製品全体の透明性や安全性を確保する重要な役割を果たします。\n\nなお、NTIA[（国家電気通信情報局）](https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom)は、SBOMに記載すべき「最小限の要素」についてガイドラインで言及しています。具体的には以下の3つの要素になります。\n\n| 要素                                   | 定義                        | 記載すべき項目例・要件                                          |\n| ------------------------------------ | ------------------------- | ---------------------------------------------------- |\n| データフィールド（Data Fields）                | ソフトウェアにおける各コンポーネントの基本的な情報 | ・コンポーネント名 ・サプライヤー名 ・バージョン情報 ・ライセンス情報 ・SBOMデータの作成者 など |\n| 自動化サポート（Automation Support）          | SBOMを自動的に処理するために求められる要件   | SPDXやCycloneDXなどの標準データフォーマットの採用                      |\n| プラクティスとプロセス（Practices and Processes） | SBOMを適切に運用するためのルールや体制     | ・SBOMの配布・配信方法 ・アクセス管理 ・SBOMの作成頻度・深さ など               |\n\n## 2. SBOMが注目されている背景\n\n![SBOMとは3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF3.jpg)\n\n近年、ソフトウェア開発の環境が大きく変化する中で、SBOMの重要性が急速に高まっています。ここでは、SBOMの注目度が高まっている3つの背景について、詳しく見ていきましょう。\n\n### 2-1. ソフトウェアサプライチェーン攻撃の増加\n\nソフトウェアサプライチェーン攻撃とは、開発・供給過程で使用されるソフトウェアやツールに不正なコードや脆弱性を仕込む手法です。この攻撃は、正規の更新プログラムやコンポーネントを介して攻撃が拡散するという特徴があります。信頼される配布チャネルを利用するため攻撃の検知が極めて困難であり、被害が広範囲に及ぶケースも少なくありません。\n\n独立行政法人 情報処理推進機構（IPA）が発表した「[情報セキュリティ10大脅威 2024組織](https://www.ipa.go.jp/security/10threats/10threats2024.html)」（外部サイト）では、サプライチェーンを狙った攻撃が2位にランクインしており、その深刻さが伺えるでしょう。また、同ランキングの5位「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」や7位「脆弱性対策情報の公開に伴う悪用増加」では、脆弱性が指摘されたコンポーネントの存在や依存関係を迅速に把握できなければ、被害拡大の要因になります。\n\nこのような背景から、ソフトウェアの構成要素を詳細に可視化し、脆弱性や不正コードの混入を早期に検知できるSBOMの重要性が高まっています。\n\n### 2-2. OSSの普及\n\nOSSは、現代のソフトウェア開発において不可欠な要素のひとつです。OSSの活用は、開発コストの削減や開発スピードの向上、品質の確保など、多くのメリットをもたらします。\n\n一方で、OSSの利用拡大に関しては、一部課題もあります。特に深刻なのが、OSSコンポーネントを標的としたサプライチェーン攻撃の増加です。また、使用しているOSSの脆弱性対応やライセンスコンプライアンスの確保も、重要な課題となっています。\n\nこのような課題を解決するためにも、OSSを含めコンポーネントのバージョンやライセンス情報まで管理できるSBOMの有効性が注目されるようになりました。\n\n### 2-3. 各国の法規制と経済産業省による推進\n\n世界ではSBOMの導入が加速しています。米国では2020年に発生したSolarWinds事件の影響を受け、2021年に「国家のサイバーセキュリティ向上に関する大統領令を発令しました。これにより、連邦政府機関に製品を提供するソフトウェア開発者や供給者は、正確なSBOMを提供することが求められるようになりました。\n\nまた、EUでも2024年にEUサイバーレジリエンス法（CRA）が施行され、EU市場にデジタル製品を販売する際にSBOM対応が求められます。\n\n国内においては、2024年8月に経済産業省による「[ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0](https://www.meti.go.jp/press/2023/07/20230728004/20230728004-3.pdf)」が公開されるなど、SBOM導入を支援する取り組みが行われています。\n\nこのように国内外でSBOMに関する法規制やガイドラインが強化されているため、今後さらに普及が進んでいくと考えられます。\n\n## 3.  SBOMとクラウドネイティブ・オープンソース活用環境の関係\n\n![SBOMとクラウドネイティブ・オープンソース活用環境の関係](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770982230/s3scr7a59dkfpqsiari5.jpg)\n\n近年はクラウド環境での実行を前提としてソフトウェアの開発・運用を行う「クラウドネイティブ」と呼ばれる手法に注目が集まっています。\n\nクラウドネイティブな開発環境では、マイクロサービスやコンテナ、OSSといったモダンな技術の活用によって効率的な開発と運用を実現できます。しかし、これらの技術を活用することでソフトウェアを構成する要素はより細分化され、全体の管理や監視が難しくなるという課題が発生してしまいます。\n\nそこでSBOMを導入すれば、複雑なソフトウェアの細かな構成要素を可視化できるため、クラウドネイティブのメリットを享受しつつ、セキュリティやコンプライアンスにも対応することが可能です。\n\nただし、後にも触れますがソフトウェア全体の透明性をきちんと確保するためには、SBOMを現実的な観点で運用することが求められます。\n\n## 4. SBOMを導入すべき理由とその効果\n\n![SBOMを導入すべき理由とその効果](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF.jpg)\n\nSBOMの導入によって、セキュリティリスクの可視化や脆弱性管理の効率化など、多くのメリットがあります。ここでは、SBOMを導入すべき理由とその効果について詳しく解説します。\n\n### 4-1. ソフトウェアサプライチェーンリスクの可視化\n\nSBOMを導入する最大のメリットのひとつは、ソフトウェアサプライチェーンのリスクを可視化できる点です。開発・運用するソフトウェアの全構成要素が一覧化され、各コンポーネントのバージョンや依存関係を明確に把握できるため、効率的かつ効果的なセキュリティ対策が可能となります。\n\n特に、複数のベンダーが関与する大規模なシステム開発において、すべてのコンポーネントが同じセキュリティ基準を満たしているかを確認するのは容易ではありません。一方、SBOMがあれば、各ベンダーが提供するソフトウェア部品のセキュリティ状況を統一的に管理でき、潜在的な不備やリスクを早期に発見できます。\n\nこのように、SBOMは組織のセキュリティリスク管理を強化し、セキュリティ事故を未然に防ぐための重要な基盤となります。\n\n### 4-2. 脆弱性管理の効率化と迅速な対応\n\nSBOMを活用すると、システム全体の脆弱性管理を大幅に効率化できます。特に、新たな脆弱性が報告された際の迅速な対応が可能になるのは大きなメリットです。SBOMがあれば、脆弱性が指摘されたコンポーネントや、セキュリティリスクの高い古いバージョンのソフトウェアを即座に特定し、対処することができます。\n\nさらに、各コンポーネント間の依存関係も詳細に記録されているため、特定の脆弱性が他の部品に与える影響範囲の正確な把握が可能です。これにより、問題解決に向けた対応を効率的に進められ、被害を最小限に抑えられます。\n\nこのような迅速で正確な対応力は、セキュリティ事故への対処だけでなく、顧客や取引先からの信頼を維持するためにも欠かせません。\n\n### 4-3. コンプライアンス対応とライセンス管理\n\nSBOMは、ソフトウェア開発におけるコンプライアンス対応とライセンス管理の効率化を支援する強力なツールです。特にOSSを利用する場合、それぞれのコンポーネントには固有のライセンス条件が設定されており、これらを適切に管理しなければなりません。\n\nSBOMを活用すると使用しているOSSのライセンス情報を正確かつ迅速に確認できるため、ライセンス違反のリスクを回避できます。これにより、法的トラブルやブランドイメージの毀損といった事態も防げるでしょう。\n\nまた、ライセンス管理を手動で行う場合、見落としや記録ミスが発生しやすく、チェックに多くの時間を要するケースがあります。SBOMを活用するとライセンス情報の管理を自動化でき、運用効率が大幅に向上するのもメリットのひとつです。\n\n### 4-4. コスト削減や開発の効率化\n\nSBOMの導入は、組織全体のコスト削減や開発の効率化にも寄与します。まず、脆弱性の特定やライセンス違反の確認にかかる手間を大幅に削減できるため、人的リソースの効率的な活用が可能になります。\n\nまた、セキュリティリスクの早期発見と対応が可能になることで、インシデントへの対処や顧客補償にかかるコストを抑えられる点も大きなメリットです。加えて、ライセンス違反による法的対応コストや、プロジェクトの遅延によるペナルティコストなども抑えられます。\n\nさらに、ソフトウェアの全体構成が明確になるため、新しい機能追加やメンテナンス作業も効率的に行えます。そのため、SBOMの活用は、結果として開発チームの生産性の向上にもつながるでしょう。\n\n## 5. SBOMの主要なフォーマット\n\n![SBOMの主要なフォーマット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770982235/wdhjrr3nstszmxrdzkkp.jpg)\n\nSBOMの主要なフォーマットには以下のようなものがあり、ここではそれぞれの特徴について解説します。\n\n* SPDX  \n* CycloneDX  \n* SWIDタグ\n\n### 5-1. SPDX（Software Package Data Exchange）\n\nSPDXは、Linux Foundationが主導するプロジェクトで開発された標準フォーマットです。主にOSSにおけるライセンス情報の把握に活用でき、ISO/IEC 5962:2021として国際標準規格に認定されているのが特徴です。\n\nSPDXの中から必要最低限の項目を絞り込んだ「SPDX Lite」もあり、小規模プロジェクトや簡易的な形で迅速に情報共有をしたいケースに向いています。\n\n### 5-2. CycloneDX\n\nCycloneDXは、OWASPのプロジェクトによって開発されたセキュリティ重視のフォーマットです。各コンポーネント間の依存関係や脆弱性情報を細かに管理できるのが特徴で、ソフトウェアのセキュリティを高めるために重要な要素を記載することが可能です。\n\nそのため、CycloneDXはDevSecOpsを実行する環境や、継続的な脆弱性の評価が求められるなどセキュリティ要件が厳しいプロジェクトでの活用が向いています。\n\n### 5-3. SWIDタグ（Software Identificationタグ）\n\nSWIDタグは、ISO/IEC 19770-2で標準化されているフォーマットでソフトウェア資産管理を目的として活用されます。具体的には、インストールされた対象のソフトウェアにSWIDタグが付与され、個々の製品を識別できる仕組みとなっています。\n\nまた、SWIDタグのタイプによってはパッチ（修正プログラム）を識別するための情報も含まれています。\n\n## 6. SBOMの導入ステップ\n\n![SBOMの導入ステップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF2.jpg)\n\nSBOMを導入するには、社内体制の整備やツールの選定などいくつかのステップを踏む必要があります。\n\n1. 社内体制の構築・ツールの選定  \n2. SBOMの作成と共有  \n3. SBOMの運用と管理　\n\n### 6-1. 社内体制の構築・ツールの選定\n\nSBOMを効果的に導入・運用するためには、まず社内体制を整える必要があります。SBOM活用を推進する責任者を配置し、組織体制を整備しましょう。また、実際にSBOMを管理・運用できる専門的な知識やスキルを持つ人材を確保しておくことも大切です。\n\nSBOMツールの選定においては、自社の目的や規模に応じたものを選ぶことが重要です。選定に迷う場合は、経済産業省の手引を活用するとよいでしょう。\n\n経済産業省の手引には、機能や性能、対応フォーマットなど選定観点の例が示されているため、これらを参考にしながら最適なSBOMツールを選びましょう。\n\n参考：[ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ～全体概要～（経済産業省）](https://www.meti.go.jp/press/2023/07/20230728004/20230728004-3.pdf)\n\n### 6-2. SBOMの作成と共有\n\n選定したSBOMツールを導入したら、対象ソフトウェアのスキャンを行い、コンポーネントを解析します。この段階で、誤検出や検出漏れがないかを慎重に確認しておかなければなりません。\n\nそして、解析したコンポーネントのデータをもとに、SBOMを作成します。SBOMのフォーマットや項目、出力ファイル形式などについてあらかじめ基準を決めておくと、効率的にSBOMの作成を進められます。また、SBOMを対象ソフトウェアの利用者やサプライヤーに共有する際は、その方法についても事前に検討しておきましょう。\n\nたとえば、クラウドストレージやWebサイト、製品への組み込みなど、SBOMの共有方法にはいくつかの選択肢があります。公開範囲やデータ改ざん防止策、サプライヤーからの要件なども踏まえて、適切な方法を採用してください。\n\n### 6-3. SBOMの運用と管理　\n\nSBOMは作成して終わりではなく、継続的な運用と管理が求められます。定期的に脆弱性スキャンを実施し、セキュリティ事故やコンプライアンス違反のリスクがないか確認しましょう。脆弱性情報が自動更新・通知されるツールを活用すれば、効率的かつ正確な運用が可能です。さらに、ソフトウェアのアップデートや新規コンポーネントの追加があった際にはSBOMも適宜更新し、常に最新の状態を保つ必要があります。\n\n## 7. SBOM導入時の課題\n\n![SBOM導入時の課題](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF4.jpg)\n\nSBOM導入時には以下のような課題に直面するケースも少なくないため、事前に把握し必要に応じて対策を検討しておくことが大切です。\n\n* ツール選びが難航する可能性がある  \n* ツール間での出力フォーマットの互換性を確認する必要がある  \n* SBOMの運用には十分なリソースが必要になる  \n* サプライチェーン全体の透明性確保の難しさ\n\n### 7-1. ツール選びが難航する可能性がある\n\nSBOMツールは有償版と無償版を含め多くの選択肢があり、それぞれの特徴を理解したうえで適切なツールを選定しなければなりません。\n\n有償ツールは機能が豊富でサポートが充実していますが、導入コストが高くなる傾向があります。一方、無償ツールはコスト負担が少ないものの、機能やサポート範囲が限定的な場合が多く、使い方によっては十分な効果が得られない可能性があります。さらに、海外製のSBOMツールは問い合わせやサポートが英語のみの場合もあり、言語の壁が障害となるケースも考えられます。\n\nこのように、SBOMツールを選定する際には、ツールの特性だけでなく、自社のニーズやリソースに適合しているかを慎重に評価することが重要です。\n\n### 7-2. ツール間での出力フォーマットの互換性を確認する必要がある\n\n先ほども紹介したように、SBOMにはSPDXやCycloneDXなどのフォーマットが存在しますが、SBOMツールによって出力されるフォーマットが異なります。つまり、ツール間での出力フォーマットの互換性が確保されていない場合、取引先・顧客への情報共有や、データ連携が困難になる可能性があります。例えば、自社がCycloneDXを採用していても、取引先が対応していなければフォーマットの変更が必要になります。\n\nこういった事態を防ぐためにも、自社を取り巻く環境で主流となっているフォーマットを確認してからツールを選定する、または複数フォーマットに対応しているツールを導入するなどの対応が求められます。\n\n### 7-3. SBOMの運用には十分なリソースが必要になる\n\nSBOMを効果的に運用するには、まずツールを使いこなすための専門知識とスキルを持つ人材が必要不可欠です。特に、SBOMの作成や更新、脆弱性情報のモニタリング、影響範囲の分析といった業務を適切に行うには、高度なスキルと経験が求められます。また、有償ツールを導入する場合には、ライセンス料や月額費用といった運用コストが発生するため、予算の確保も課題のひとつです。\n\nさらに、SBOM運用の効果を十分に発揮するためには、運用プロセスの標準化や体制の整備も必要です。運用体制が不十分だとSBOMの管理が滞り、結果としてセキュリティリスクの増大やコンプライアンス違反などを招く可能性が高まります。\n\nこのように、SBOMの効果を最大限に引き出すには十分なリソースを確保する必要があり、これらが不足すると適切に運用できないおそれがあるため、注意が必要です。\n\n### 7-4. サプライチェーン全体の透明性確保の難しさ\n\nSBOM対象となるソフトウェアが多くの依存関係を持つなどサプライチェーンの規模が大きく、かつ複雑化している場合、全体の構成要素を正確に管理するのは現実的な難しさがあります。事実、SBOMは自社内だけで完結する取り組みではなく、利害関係者との間で発生する情報共有の中で、要求事項の不一致やフォーマットの差異などの課題が発生する可能性もあります。さらに、導入・運用事例の少なさ、社内でのノウハウ不足、運用負荷の課題も透明性確保における大きな壁になります。\n\n正確かつ確実にSBOM導入を進めるためには、最初から完全な網羅を目指すのではなく、徐々に可視化の範囲・レベルを高めていき、必要に応じて運用ルールや体制の改善を試みる姿勢が大切だと言えます。\n\n## まとめ：SBOMを活用したセキュリティ対策が求められる\n\nSBOMは、ソフトウェアの構成要素を可視化し、脆弱性やライセンスの管理を効率的に行うための重要なツールです。特に、近年増加しているソフトウェアサプライチェーン攻撃やOSSの普及に伴うセキュリティリスクへの対策として、SBOMの注目度が高まっています。\n\nさらに、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)にセキュリティを融合させた「[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)」の実践においても、SBOMは重要な役割を果たします。セキュリティを確保しながら迅速に開発を進めたい場合にも、SBOMツールの活用を検討してみてください。\n\nより詳しい情報や、今後の[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)の展開について知りたい方は、ぜひ「2025 グローバルDevSecOpsレポート」をご活用ください。世界各地のDevSecOps専門家5000名を対象に行った調査結果をご覧いただけます。\n\n> [2025グローバルDevSecOpsレポートはこちら](https://about.gitlab.com/ja-jp/developer-survey/japan/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_what-is-sbom)  \n\n*監修：ハシュカ アンドリュー / Andrew Haschka [@ahaschka](https://gitlab.com/ahaschka)\n（GitLab フィールド最高技術責任者）*","security",{"template":15,"slug":16,"featured":17},"BlogPost","what-is-sbom",true,{"title":5,"description":19,"authors":20,"heroImage":21,"tags":22,"category":13,"date":26,"updatedDate":27,"body":12},"この記事では、SBOMの基本知識や注目されている背景、導入方法などを詳しく解説します。",[10,11],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663321/Blog/Hero%20Images/SBOM_keyvisual.jpg",[13,23,24,25],"DevSecOps","performance","open source","2025-03-26","2026-02-13","md",null,{},"/ja-jp/blog/what-is-sbom","---\nseo:\n  ogTitle: SBOMの基本と導入方法｜ソフトウェアのセキュリティを守るための実践ガイド\n  ogImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663321/Blog/Hero%20Images/SBOM_keyvisual.jpg\n  ogDescription: この記事では、SBOMの基本知識や注目されている背景、導入方法などを詳しく解説します。\n  ogSiteName: https://about.gitlab.com\n  noIndex: false\n  ogType: article\n  ogUrl: https://about.gitlab.com/blog/what-is-sbom\n  title: SBOMの基本と導入方法｜ソフトウェアのセキュリティを守るための実践ガイド\n  canonicalUrls: https://about.gitlab.com/blog/what-is-sbom\n  description: この記事では、SBOMの基本知識や注目されている背景、導入方法などを詳しく解説します。\ntitle: SBOMの基本と導入方法｜ソフトウェアのセキュリティを守るための実践ガイド\ndescription: この記事では、SBOMの基本知識や注目されている背景、導入方法などを詳しく解説します。\nauthors:\n  - GitLab Japan Team\n  - GitLab\nheroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663321/Blog/Hero%20Images/SBOM_keyvisual.jpg\ntags:\n  - security\n  - DevSecOps\n  - performance\n  - open source\ncategory: security\ndate: '2025-03-26'\nupdatedDate: '2026-02-13'\nslug: what-is-sbom\nfeatured: true\ntemplate: BlogPost\n---\n\nソフトウェア開発において、セキュリティリスクへの対応は年々重要性を増しています。特に、OSS（オープンソースソフトウェア）の普及に伴い、脆弱性管理やライセンス対応の課題に直面している方も多いのではないでしょうか。\n\nこうした中で注目を集めているのが、ソフトウェアの構成要素を可視化する「SBOM」です。本記事では、SBOMの基本知識や注目されている背景、導入方法などを詳しく解説します。セキュリティの強化や開発の効率化を目指す方は、ぜひ参考にしてください。\n\n## 1. SBOMとは？基本知識と重要性\n\nSBOMは「Software Bill of Materials」の略で、ソフトウェアに含まれるすべての構成要素（コンポーネント）を一覧化した「部品表」のことです。\n\nSBOMには、使用されているOSS、サードパーティ製ライブラリ、独自開発のコンポーネントなど、ソフトウェアを構成するすべての要素を記載します。各コンポーネントのバージョン情報、ライセンス情報、依存関係なども含まれており、これらの情報を一元管理し、製品全体の透明性や安全性を確保する重要な役割を果たします。\n\nなお、NTIA[（国家電気通信情報局）](https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom)は、SBOMに記載すべき「最小限の要素」についてガイドラインで言及しています。具体的には以下の3つの要素になります。\n\n| 要素                                   | 定義                        | 記載すべき項目例・要件                                          |\n| ------------------------------------ | ------------------------- | ---------------------------------------------------- |\n| データフィールド（Data Fields）                | ソフトウェアにおける各コンポーネントの基本的な情報 | ・コンポーネント名 ・サプライヤー名 ・バージョン情報 ・ライセンス情報 ・SBOMデータの作成者 など |\n| 自動化サポート（Automation Support）          | SBOMを自動的に処理するために求められる要件   | SPDXやCycloneDXなどの標準データフォーマットの採用                      |\n| プラクティスとプロセス（Practices and Processes） | SBOMを適切に運用するためのルールや体制     | ・SBOMの配布・配信方法 ・アクセス管理 ・SBOMの作成頻度・深さ など               |\n\n## 2. SBOMが注目されている背景\n\n![SBOMとは3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF3.jpg)\n\n近年、ソフトウェア開発の環境が大きく変化する中で、SBOMの重要性が急速に高まっています。ここでは、SBOMの注目度が高まっている3つの背景について、詳しく見ていきましょう。\n\n### 2-1. ソフトウェアサプライチェーン攻撃の増加\n\nソフトウェアサプライチェーン攻撃とは、開発・供給過程で使用されるソフトウェアやツールに不正なコードや脆弱性を仕込む手法です。この攻撃は、正規の更新プログラムやコンポーネントを介して攻撃が拡散するという特徴があります。信頼される配布チャネルを利用するため攻撃の検知が極めて困難であり、被害が広範囲に及ぶケースも少なくありません。\n\n独立行政法人 情報処理推進機構（IPA）が発表した「[情報セキュリティ10大脅威 2024組織](https://www.ipa.go.jp/security/10threats/10threats2024.html)」（外部サイト）では、サプライチェーンを狙った攻撃が2位にランクインしており、その深刻さが伺えるでしょう。また、同ランキングの5位「修正プログラムの公開前を狙う攻撃（ゼロデイ攻撃）」や7位「脆弱性対策情報の公開に伴う悪用増加」では、脆弱性が指摘されたコンポーネントの存在や依存関係を迅速に把握できなければ、被害拡大の要因になります。\n\nこのような背景から、ソフトウェアの構成要素を詳細に可視化し、脆弱性や不正コードの混入を早期に検知できるSBOMの重要性が高まっています。\n\n### 2-2. OSSの普及\n\nOSSは、現代のソフトウェア開発において不可欠な要素のひとつです。OSSの活用は、開発コストの削減や開発スピードの向上、品質の確保など、多くのメリットをもたらします。\n\n一方で、OSSの利用拡大に関しては、一部課題もあります。特に深刻なのが、OSSコンポーネントを標的としたサプライチェーン攻撃の増加です。また、使用しているOSSの脆弱性対応やライセンスコンプライアンスの確保も、重要な課題となっています。\n\nこのような課題を解決するためにも、OSSを含めコンポーネントのバージョンやライセンス情報まで管理できるSBOMの有効性が注目されるようになりました。\n\n### 2-3. 各国の法規制と経済産業省による推進\n\n世界ではSBOMの導入が加速しています。米国では2020年に発生したSolarWinds事件の影響を受け、2021年に「国家のサイバーセキュリティ向上に関する大統領令を発令しました。これにより、連邦政府機関に製品を提供するソフトウェア開発者や供給者は、正確なSBOMを提供することが求められるようになりました。\n\nまた、EUでも2024年にEUサイバーレジリエンス法（CRA）が施行され、EU市場にデジタル製品を販売する際にSBOM対応が求められます。\n\n国内においては、2024年8月に経済産業省による「[ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引ver2.0](https://www.meti.go.jp/press/2023/07/20230728004/20230728004-3.pdf)」が公開されるなど、SBOM導入を支援する取り組みが行われています。\n\nこのように国内外でSBOMに関する法規制やガイドラインが強化されているため、今後さらに普及が進んでいくと考えられます。\n\n## 3.  SBOMとクラウドネイティブ・オープンソース活用環境の関係\n\n![SBOMとクラウドネイティブ・オープンソース活用環境の関係](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770982230/s3scr7a59dkfpqsiari5.jpg)\n\n近年はクラウド環境での実行を前提としてソフトウェアの開発・運用を行う「クラウドネイティブ」と呼ばれる手法に注目が集まっています。\n\nクラウドネイティブな開発環境では、マイクロサービスやコンテナ、OSSといったモダンな技術の活用によって効率的な開発と運用を実現できます。しかし、これらの技術を活用することでソフトウェアを構成する要素はより細分化され、全体の管理や監視が難しくなるという課題が発生してしまいます。\n\nそこでSBOMを導入すれば、複雑なソフトウェアの細かな構成要素を可視化できるため、クラウドネイティブのメリットを享受しつつ、セキュリティやコンプライアンスにも対応することが可能です。\n\nただし、後にも触れますがソフトウェア全体の透明性をきちんと確保するためには、SBOMを現実的な観点で運用することが求められます。\n\n## 4. SBOMを導入すべき理由とその効果\n\n![SBOMを導入すべき理由とその効果](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF.jpg)\n\nSBOMの導入によって、セキュリティリスクの可視化や脆弱性管理の効率化など、多くのメリットがあります。ここでは、SBOMを導入すべき理由とその効果について詳しく解説します。\n\n### 4-1. ソフトウェアサプライチェーンリスクの可視化\n\nSBOMを導入する最大のメリットのひとつは、ソフトウェアサプライチェーンのリスクを可視化できる点です。開発・運用するソフトウェアの全構成要素が一覧化され、各コンポーネントのバージョンや依存関係を明確に把握できるため、効率的かつ効果的なセキュリティ対策が可能となります。\n\n特に、複数のベンダーが関与する大規模なシステム開発において、すべてのコンポーネントが同じセキュリティ基準を満たしているかを確認するのは容易ではありません。一方、SBOMがあれば、各ベンダーが提供するソフトウェア部品のセキュリティ状況を統一的に管理でき、潜在的な不備やリスクを早期に発見できます。\n\nこのように、SBOMは組織のセキュリティリスク管理を強化し、セキュリティ事故を未然に防ぐための重要な基盤となります。\n\n### 4-2. 脆弱性管理の効率化と迅速な対応\n\nSBOMを活用すると、システム全体の脆弱性管理を大幅に効率化できます。特に、新たな脆弱性が報告された際の迅速な対応が可能になるのは大きなメリットです。SBOMがあれば、脆弱性が指摘されたコンポーネントや、セキュリティリスクの高い古いバージョンのソフトウェアを即座に特定し、対処することができます。\n\nさらに、各コンポーネント間の依存関係も詳細に記録されているため、特定の脆弱性が他の部品に与える影響範囲の正確な把握が可能です。これにより、問題解決に向けた対応を効率的に進められ、被害を最小限に抑えられます。\n\nこのような迅速で正確な対応力は、セキュリティ事故への対処だけでなく、顧客や取引先からの信頼を維持するためにも欠かせません。\n\n### 4-3. コンプライアンス対応とライセンス管理\n\nSBOMは、ソフトウェア開発におけるコンプライアンス対応とライセンス管理の効率化を支援する強力なツールです。特にOSSを利用する場合、それぞれのコンポーネントには固有のライセンス条件が設定されており、これらを適切に管理しなければなりません。\n\nSBOMを活用すると使用しているOSSのライセンス情報を正確かつ迅速に確認できるため、ライセンス違反のリスクを回避できます。これにより、法的トラブルやブランドイメージの毀損といった事態も防げるでしょう。\n\nまた、ライセンス管理を手動で行う場合、見落としや記録ミスが発生しやすく、チェックに多くの時間を要するケースがあります。SBOMを活用するとライセンス情報の管理を自動化でき、運用効率が大幅に向上するのもメリットのひとつです。\n\n### 4-4. コスト削減や開発の効率化\n\nSBOMの導入は、組織全体のコスト削減や開発の効率化にも寄与します。まず、脆弱性の特定やライセンス違反の確認にかかる手間を大幅に削減できるため、人的リソースの効率的な活用が可能になります。\n\nまた、セキュリティリスクの早期発見と対応が可能になることで、インシデントへの対処や顧客補償にかかるコストを抑えられる点も大きなメリットです。加えて、ライセンス違反による法的対応コストや、プロジェクトの遅延によるペナルティコストなども抑えられます。\n\nさらに、ソフトウェアの全体構成が明確になるため、新しい機能追加やメンテナンス作業も効率的に行えます。そのため、SBOMの活用は、結果として開発チームの生産性の向上にもつながるでしょう。\n\n## 5. SBOMの主要なフォーマット\n\n![SBOMの主要なフォーマット](https://res.cloudinary.com/about-gitlab-com/image/upload/v1770982235/wdhjrr3nstszmxrdzkkp.jpg)\n\nSBOMの主要なフォーマットには以下のようなものがあり、ここではそれぞれの特徴について解説します。\n\n* SPDX  \n* CycloneDX  \n* SWIDタグ\n\n### 5-1. SPDX（Software Package Data Exchange）\n\nSPDXは、Linux Foundationが主導するプロジェクトで開発された標準フォーマットです。主にOSSにおけるライセンス情報の把握に活用でき、ISO/IEC 5962:2021として国際標準規格に認定されているのが特徴です。\n\nSPDXの中から必要最低限の項目を絞り込んだ「SPDX Lite」もあり、小規模プロジェクトや簡易的な形で迅速に情報共有をしたいケースに向いています。\n\n### 5-2. CycloneDX\n\nCycloneDXは、OWASPのプロジェクトによって開発されたセキュリティ重視のフォーマットです。各コンポーネント間の依存関係や脆弱性情報を細かに管理できるのが特徴で、ソフトウェアのセキュリティを高めるために重要な要素を記載することが可能です。\n\nそのため、CycloneDXはDevSecOpsを実行する環境や、継続的な脆弱性の評価が求められるなどセキュリティ要件が厳しいプロジェクトでの活用が向いています。\n\n### 5-3. SWIDタグ（Software Identificationタグ）\n\nSWIDタグは、ISO/IEC 19770-2で標準化されているフォーマットでソフトウェア資産管理を目的として活用されます。具体的には、インストールされた対象のソフトウェアにSWIDタグが付与され、個々の製品を識別できる仕組みとなっています。\n\nまた、SWIDタグのタイプによってはパッチ（修正プログラム）を識別するための情報も含まれています。\n\n## 6. SBOMの導入ステップ\n\n![SBOMの導入ステップ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF2.jpg)\n\nSBOMを導入するには、社内体制の整備やツールの選定などいくつかのステップを踏む必要があります。\n\n1. 社内体制の構築・ツールの選定  \n2. SBOMの作成と共有  \n3. SBOMの運用と管理　\n\n### 6-1. 社内体制の構築・ツールの選定\n\nSBOMを効果的に導入・運用するためには、まず社内体制を整える必要があります。SBOM活用を推進する責任者を配置し、組織体制を整備しましょう。また、実際にSBOMを管理・運用できる専門的な知識やスキルを持つ人材を確保しておくことも大切です。\n\nSBOMツールの選定においては、自社の目的や規模に応じたものを選ぶことが重要です。選定に迷う場合は、経済産業省の手引を活用するとよいでしょう。\n\n経済産業省の手引には、機能や性能、対応フォーマットなど選定観点の例が示されているため、これらを参考にしながら最適なSBOMツールを選びましょう。\n\n参考：[ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ～全体概要～（経済産業省）](https://www.meti.go.jp/press/2023/07/20230728004/20230728004-3.pdf)\n\n### 6-2. SBOMの作成と共有\n\n選定したSBOMツールを導入したら、対象ソフトウェアのスキャンを行い、コンポーネントを解析します。この段階で、誤検出や検出漏れがないかを慎重に確認しておかなければなりません。\n\nそして、解析したコンポーネントのデータをもとに、SBOMを作成します。SBOMのフォーマットや項目、出力ファイル形式などについてあらかじめ基準を決めておくと、効率的にSBOMの作成を進められます。また、SBOMを対象ソフトウェアの利用者やサプライヤーに共有する際は、その方法についても事前に検討しておきましょう。\n\nたとえば、クラウドストレージやWebサイト、製品への組み込みなど、SBOMの共有方法にはいくつかの選択肢があります。公開範囲やデータ改ざん防止策、サプライヤーからの要件なども踏まえて、適切な方法を採用してください。\n\n### 6-3. SBOMの運用と管理　\n\nSBOMは作成して終わりではなく、継続的な運用と管理が求められます。定期的に脆弱性スキャンを実施し、セキュリティ事故やコンプライアンス違反のリスクがないか確認しましょう。脆弱性情報が自動更新・通知されるツールを活用すれば、効率的かつ正確な運用が可能です。さらに、ソフトウェアのアップデートや新規コンポーネントの追加があった際にはSBOMも適宜更新し、常に最新の状態を保つ必要があります。\n\n## 7. SBOM導入時の課題\n\n![SBOM導入時の課題](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687588/Blog/Content%20Images/SBOM%E3%81%A8%E3%81%AF4.jpg)\n\nSBOM導入時には以下のような課題に直面するケースも少なくないため、事前に把握し必要に応じて対策を検討しておくことが大切です。\n\n* ツール選びが難航する可能性がある  \n* ツール間での出力フォーマットの互換性を確認する必要がある  \n* SBOMの運用には十分なリソースが必要になる  \n* サプライチェーン全体の透明性確保の難しさ\n\n### 7-1. ツール選びが難航する可能性がある\n\nSBOMツールは有償版と無償版を含め多くの選択肢があり、それぞれの特徴を理解したうえで適切なツールを選定しなければなりません。\n\n有償ツールは機能が豊富でサポートが充実していますが、導入コストが高くなる傾向があります。一方、無償ツールはコスト負担が少ないものの、機能やサポート範囲が限定的な場合が多く、使い方によっては十分な効果が得られない可能性があります。さらに、海外製のSBOMツールは問い合わせやサポートが英語のみの場合もあり、言語の壁が障害となるケースも考えられます。\n\nこのように、SBOMツールを選定する際には、ツールの特性だけでなく、自社のニーズやリソースに適合しているかを慎重に評価することが重要です。\n\n### 7-2. ツール間での出力フォーマットの互換性を確認する必要がある\n\n先ほども紹介したように、SBOMにはSPDXやCycloneDXなどのフォーマットが存在しますが、SBOMツールによって出力されるフォーマットが異なります。つまり、ツール間での出力フォーマットの互換性が確保されていない場合、取引先・顧客への情報共有や、データ連携が困難になる可能性があります。例えば、自社がCycloneDXを採用していても、取引先が対応していなければフォーマットの変更が必要になります。\n\nこういった事態を防ぐためにも、自社を取り巻く環境で主流となっているフォーマットを確認してからツールを選定する、または複数フォーマットに対応しているツールを導入するなどの対応が求められます。\n\n### 7-3. SBOMの運用には十分なリソースが必要になる\n\nSBOMを効果的に運用するには、まずツールを使いこなすための専門知識とスキルを持つ人材が必要不可欠です。特に、SBOMの作成や更新、脆弱性情報のモニタリング、影響範囲の分析といった業務を適切に行うには、高度なスキルと経験が求められます。また、有償ツールを導入する場合には、ライセンス料や月額費用といった運用コストが発生するため、予算の確保も課題のひとつです。\n\nさらに、SBOM運用の効果を十分に発揮するためには、運用プロセスの標準化や体制の整備も必要です。運用体制が不十分だとSBOMの管理が滞り、結果としてセキュリティリスクの増大やコンプライアンス違反などを招く可能性が高まります。\n\nこのように、SBOMの効果を最大限に引き出すには十分なリソースを確保する必要があり、これらが不足すると適切に運用できないおそれがあるため、注意が必要です。\n\n### 7-4. サプライチェーン全体の透明性確保の難しさ\n\nSBOM対象となるソフトウェアが多くの依存関係を持つなどサプライチェーンの規模が大きく、かつ複雑化している場合、全体の構成要素を正確に管理するのは現実的な難しさがあります。事実、SBOMは自社内だけで完結する取り組みではなく、利害関係者との間で発生する情報共有の中で、要求事項の不一致やフォーマットの差異などの課題が発生する可能性もあります。さらに、導入・運用事例の少なさ、社内でのノウハウ不足、運用負荷の課題も透明性確保における大きな壁になります。\n\n正確かつ確実にSBOM導入を進めるためには、最初から完全な網羅を目指すのではなく、徐々に可視化の範囲・レベルを高めていき、必要に応じて運用ルールや体制の改善を試みる姿勢が大切だと言えます。\n\n## まとめ：SBOMを活用したセキュリティ対策が求められる\n\nSBOMは、ソフトウェアの構成要素を可視化し、脆弱性やライセンスの管理を効率的に行うための重要なツールです。特に、近年増加しているソフトウェアサプライチェーン攻撃やOSSの普及に伴うセキュリティリスクへの対策として、SBOMの注目度が高まっています。\n\nさらに、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)にセキュリティを融合させた「[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)」の実践においても、SBOMは重要な役割を果たします。セキュリティを確保しながら迅速に開発を進めたい場合にも、SBOMツールの活用を検討してみてください。\n\nより詳しい情報や、今後の[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)の展開について知りたい方は、ぜひ「2025 グローバルDevSecOpsレポート」をご活用ください。世界各地のDevSecOps専門家5000名を対象に行った調査結果をご覧いただけます。\n\n> [2025グローバルDevSecOpsレポートはこちら](https://about.gitlab.com/ja-jp/developer-survey/japan/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_what-is-sbom)  \n\n*監修：ハシュカ アンドリュー / Andrew Haschka [@ahaschka](https://gitlab.com/ahaschka)\n（GitLab フィールド最高技術責任者）*\n",{"ogTitle":5,"ogImage":21,"ogDescription":19,"ogSiteName":34,"noIndex":35,"ogType":36,"ogUrl":37,"title":5,"canonicalUrls":37,"description":19},"https://about.gitlab.com",false,"article","https://about.gitlab.com/blog/what-is-sbom","ja-jp/blog/what-is-sbom",[13,40,24,41],"devsecops","open-source",[13,23,24,25],"Wt_2JV943WZmxbq1jjQMBJh8UFvo9AgFivNK-dofiVc",{"logo":45,"freeTrial":50,"sales":55,"login":60,"items":65,"search":385,"minimal":418,"duo":435,"switchNav":444,"pricingDeployment":455},{"config":46},{"href":47,"dataGaName":48,"dataGaLocation":49},"/ja-jp/","gitlab logo","header",{"text":51,"config":52},"無料トライアルを開始",{"href":53,"dataGaName":54,"dataGaLocation":49},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":56,"config":57},"お問い合わせ",{"href":58,"dataGaName":59,"dataGaLocation":49},"/ja-jp/sales/","sales",{"text":61,"config":62},"サインイン",{"href":63,"dataGaName":64,"dataGaLocation":49},"https://gitlab.com/users/sign_in/","sign in",[66,95,197,202,305,366],{"text":67,"config":68,"menu":70},"プラットフォーム",{"dataNavLevelOne":69},"platform",{"type":71,"columns":72},"cards",[73,79,87],{"title":67,"description":74,"link":75},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":76,"config":77},"プラットフォームを探索",{"href":78,"dataGaName":69,"dataGaLocation":49},"/ja-jp/platform/",{"title":80,"description":81,"link":82},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":83,"config":84},"GitLab Duoのご紹介",{"href":85,"dataGaName":86,"dataGaLocation":49},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":88,"description":89,"link":90},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":91,"config":92},"詳細はこちら",{"href":93,"dataGaName":94,"dataGaLocation":49},"/ja-jp/why-gitlab/","why gitlab",{"text":96,"left":17,"config":97,"menu":99},"製品",{"dataNavLevelOne":98},"solutions",{"type":100,"link":101,"columns":105,"feature":176},"lists",{"text":102,"config":103},"すべてのソリューションを表示",{"href":104,"dataGaName":98,"dataGaLocation":49},"/ja-jp/solutions/",[106,131,154],{"title":107,"description":108,"link":109,"items":114},"自動化","CI/CDと自動化でデプロイを加速",{"config":110},{"icon":111,"href":112,"dataGaName":113,"dataGaLocation":49},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[115,119,122,127],{"text":116,"config":117},"CI/CD",{"href":118,"dataGaLocation":49,"dataGaName":116},"/ja-jp/solutions/continuous-integration/",{"text":80,"config":120},{"href":85,"dataGaLocation":49,"dataGaName":121},"gitlab duo agent platform - product menu",{"text":123,"config":124},"ソースコード管理",{"href":125,"dataGaLocation":49,"dataGaName":126},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":128,"config":129},"自動化されたソフトウェアデリバリー",{"href":112,"dataGaLocation":49,"dataGaName":130},"Automated software delivery",{"title":132,"description":133,"link":134,"items":139},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":135},{"href":136,"dataGaName":137,"dataGaLocation":49,"icon":138},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[140,144,149],{"text":141,"config":142},"アプリケーションセキュリティテスト",{"href":136,"dataGaName":143,"dataGaLocation":49},"Application security testing",{"text":145,"config":146},"ソフトウェアサプライチェーンの安全性",{"href":147,"dataGaLocation":49,"dataGaName":148},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":150,"config":151},"ソフトウェアコンプライアンス",{"href":152,"dataGaName":153,"dataGaLocation":49},"/ja-jp/solutions/software-compliance/","software compliance",{"title":155,"link":156,"items":161},"測定",{"config":157},{"icon":158,"href":159,"dataGaName":160,"dataGaLocation":49},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[162,166,171],{"text":163,"config":164},"可視性と測定",{"href":159,"dataGaLocation":49,"dataGaName":165},"Visibility and Measurement",{"text":167,"config":168},"バリューストリーム管理",{"href":169,"dataGaLocation":49,"dataGaName":170},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":172,"config":173},"分析とインサイト",{"href":174,"dataGaLocation":49,"dataGaName":175},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":177,"type":100,"items":178},"GitLabが活躍する場所",[179,185,191],{"text":180,"config":181},"エンタープライズ",{"icon":182,"href":183,"dataGaLocation":49,"dataGaName":184},"Building","/ja-jp/enterprise/","enterprise",{"text":186,"config":187},"スモールビジネス",{"icon":188,"href":189,"dataGaLocation":49,"dataGaName":190},"Work","/ja-jp/small-business/","small business",{"text":192,"config":193},"公共部門",{"icon":194,"href":195,"dataGaLocation":49,"dataGaName":196},"Organization","/ja-jp/solutions/public-sector/","public sector",{"text":198,"config":199},"価格",{"href":200,"dataGaName":201,"dataGaLocation":49,"dataNavLevelOne":201},"/ja-jp/pricing/","pricing",{"text":203,"config":204,"menu":206},"リソース",{"dataNavLevelOne":205},"resources",{"type":100,"link":207,"columns":211,"feature":291},{"text":208,"config":209},"すべてのリソースを表示",{"href":210,"dataGaName":205,"dataGaLocation":49},"/ja-jp/resources/",[212,245,263],{"title":213,"items":214},"はじめに",[215,220,225,230,235,240],{"text":216,"config":217},"インストール",{"href":218,"dataGaName":219,"dataGaLocation":49},"/ja-jp/install/","install",{"text":221,"config":222},"クイックスタートガイド",{"href":223,"dataGaName":224,"dataGaLocation":49},"/ja-jp/get-started/","quick setup checklists",{"text":226,"config":227},"学ぶ",{"href":228,"dataGaLocation":49,"dataGaName":229},"https://university.gitlab.com/","learn",{"text":231,"config":232},"製品ドキュメント",{"href":233,"dataGaName":234,"dataGaLocation":49},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":236,"config":237},"ベストプラクティスビデオ",{"href":238,"dataGaName":239,"dataGaLocation":49},"/ja-jp/getting-started-videos/","best practice videos",{"text":241,"config":242},"インテグレーション",{"href":243,"dataGaName":244,"dataGaLocation":49},"/ja-jp/integrations/","integrations",{"title":246,"items":247},"検索する",[248,253,258],{"text":249,"config":250},"お客様成功事例",{"href":251,"dataGaName":252,"dataGaLocation":49},"/ja-jp/customers/","customer success stories",{"text":254,"config":255},"ブログ",{"href":256,"dataGaName":257,"dataGaLocation":49},"/ja-jp/blog/","blog",{"text":259,"config":260},"リモート",{"href":261,"dataGaName":262,"dataGaLocation":49},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":264,"items":265},"つなげる",[266,271,276,281,286],{"text":267,"config":268},"GitLabサービス",{"href":269,"dataGaName":270,"dataGaLocation":49},"/ja-jp/services/","services",{"text":272,"config":273},"コミュニティ",{"href":274,"dataGaName":275,"dataGaLocation":49},"/community/","community",{"text":277,"config":278},"フォーラム",{"href":279,"dataGaName":280,"dataGaLocation":49},"https://forum.gitlab.com/","forum",{"text":282,"config":283},"イベント",{"href":284,"dataGaName":285,"dataGaLocation":49},"/events/","events",{"text":287,"config":288},"パートナー",{"href":289,"dataGaName":290,"dataGaLocation":49},"/ja-jp/partners/","partners",{"config":292,"text":295,"image":296,"link":300},{"background":293,"textColor":294},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":297,"config":298},"ソースプロモカード",{"src":299},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":301,"config":302},"最新情報を読む",{"href":303,"dataGaName":304,"dataGaLocation":49},"/ja-jp/the-source/","the source",{"text":306,"config":307,"menu":309},"会社情報",{"dataNavLevelOne":308},"company",{"type":100,"columns":310},[311],{"items":312},[313,318,324,326,331,336,341,346,351,356,361],{"text":314,"config":315},"GitLabについて",{"href":316,"dataGaName":317,"dataGaLocation":49},"/ja-jp/company/","about",{"text":319,"config":320,"footerGa":323},"採用情報",{"href":321,"dataGaName":322,"dataGaLocation":49},"/jobs/","jobs",{"dataGaName":322},{"text":282,"config":325},{"href":284,"dataGaName":285,"dataGaLocation":49},{"text":327,"config":328},"経営陣",{"href":329,"dataGaName":330,"dataGaLocation":49},"/company/team/e-group/","leadership",{"text":332,"config":333},"チーム",{"href":334,"dataGaName":335,"dataGaLocation":49},"/company/team/","team",{"text":337,"config":338},"ハンドブック",{"href":339,"dataGaName":340,"dataGaLocation":49},"https://handbook.gitlab.com/","handbook",{"text":342,"config":343},"投資家向け情報",{"href":344,"dataGaName":345,"dataGaLocation":49},"https://ir.gitlab.com/","investor relations",{"text":347,"config":348},"トラストセンター",{"href":349,"dataGaName":350,"dataGaLocation":49},"/ja-jp/security/","trust center",{"text":352,"config":353},"AI Transparency Center",{"href":354,"dataGaName":355,"dataGaLocation":49},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":357,"config":358},"ニュースレター",{"href":359,"dataGaName":360,"dataGaLocation":49},"/company/contact/#contact-forms","newsletter",{"text":362,"config":363},"プレス",{"href":364,"dataGaName":365,"dataGaLocation":49},"/press/","press",{"text":56,"config":367,"menu":368},{"dataNavLevelOne":308},{"type":100,"columns":369},[370],{"items":371},[372,375,380],{"text":56,"config":373},{"href":58,"dataGaName":374,"dataGaLocation":49},"talk to sales",{"text":376,"config":377},"サポートを受ける",{"href":378,"dataGaName":379,"dataGaLocation":49},"https://support.gitlab.com","support portal",{"text":381,"config":382},"カスタマーポータル",{"href":383,"dataGaName":384,"dataGaLocation":49},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":386,"login":387,"suggestions":394},"閉じる",{"text":388,"link":389},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":390,"config":391},"GitLab.com",{"href":63,"dataGaName":392,"dataGaLocation":393},"search login","search",{"text":395,"default":396},"提案",[397,399,404,406,410,414],{"text":80,"config":398},{"href":85,"dataGaName":80,"dataGaLocation":393},{"text":400,"config":401},"コード提案（AI）",{"href":402,"dataGaName":403,"dataGaLocation":393},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":116,"config":405},{"href":118,"dataGaName":116,"dataGaLocation":393},{"text":407,"config":408},"GitLab on AWS",{"href":409,"dataGaName":407,"dataGaLocation":393},"/ja-jp/partners/technology-partners/aws/",{"text":411,"config":412},"GitLab on Google Cloud",{"href":413,"dataGaName":411,"dataGaLocation":393},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":415,"config":416},"GitLabを選ぶ理由",{"href":93,"dataGaName":417,"dataGaLocation":393},"Why GitLab?",{"freeTrial":419,"mobileIcon":423,"desktopIcon":428,"secondaryButton":431},{"text":51,"config":420},{"href":421,"dataGaName":54,"dataGaLocation":422},"https://gitlab.com/-/trials/new/","nav",{"altText":424,"config":425},"GitLabアイコン",{"src":426,"dataGaName":427,"dataGaLocation":422},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":424,"config":429},{"src":430,"dataGaName":427,"dataGaLocation":422},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":213,"config":432},{"href":433,"dataGaName":434,"dataGaLocation":422},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":436,"mobileIcon":440,"desktopIcon":442},{"text":437,"config":438},"GitLab Duoの詳細について",{"href":85,"dataGaName":439,"dataGaLocation":422},"gitlab duo",{"altText":424,"config":441},{"src":426,"dataGaName":427,"dataGaLocation":422},{"altText":424,"config":443},{"src":430,"dataGaName":427,"dataGaLocation":422},{"button":445,"mobileIcon":450,"desktopIcon":452},{"text":446,"config":447},"/switch",{"href":448,"dataGaName":449,"dataGaLocation":422},"#contact","switch",{"altText":424,"config":451},{"src":426,"dataGaName":427,"dataGaLocation":422},{"altText":424,"config":453},{"src":454,"dataGaName":427,"dataGaLocation":422},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":456,"mobileIcon":461,"desktopIcon":463},{"text":457,"config":458},"価格ページに戻る",{"href":200,"dataGaName":459,"dataGaLocation":422,"icon":460},"back to pricing","GoBack",{"altText":424,"config":462},{"src":426,"dataGaName":427,"dataGaLocation":422},{"altText":424,"config":464},{"src":430,"dataGaName":427,"dataGaLocation":422},{"title":466,"button":467,"config":472},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":468,"config":469},"6月10日のGitLab Transcendに申し込む",{"href":470,"dataGaName":471,"dataGaLocation":49},"/ja-jp/releases/whats-new/#sign-up","transcend event",{"layout":473,"icon":474,"disabled":35},"release","AiStar",{"data":476},{"text":477,"source":478,"edit":484,"contribute":489,"config":494,"items":499,"minimal":700},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":479,"config":480},"ページのソースを表示",{"href":481,"dataGaName":482,"dataGaLocation":483},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":485,"config":486},"このページを編集",{"href":487,"dataGaName":488,"dataGaLocation":483},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":490,"config":491},"ご協力をお願いします",{"href":492,"dataGaName":493,"dataGaLocation":483},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":495,"facebook":496,"youtube":497,"linkedin":498},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[500,545,596,639,666],{"title":198,"links":501,"subMenu":516},[502,506,511],{"text":503,"config":504},"プランの表示",{"href":200,"dataGaName":505,"dataGaLocation":483},"view plans",{"text":507,"config":508},"Premiumを選ぶ理由",{"href":509,"dataGaName":510,"dataGaLocation":483},"/ja-jp/pricing/premium/","why premium",{"text":512,"config":513},"Ultimateを選ぶ理由",{"href":514,"dataGaName":515,"dataGaLocation":483},"/ja-jp/pricing/ultimate/","why ultimate",[517],{"title":56,"links":518},[519,521,523,525,530,535,540],{"text":56,"config":520},{"href":58,"dataGaName":59,"dataGaLocation":483},{"text":376,"config":522},{"href":378,"dataGaName":379,"dataGaLocation":483},{"text":381,"config":524},{"href":383,"dataGaName":384,"dataGaLocation":483},{"text":526,"config":527},"ステータス",{"href":528,"dataGaName":529,"dataGaLocation":483},"https://status.gitlab.com/","status",{"text":531,"config":532},"利用規約",{"href":533,"dataGaName":534,"dataGaLocation":483},"/terms/","terms of use",{"text":536,"config":537},"プライバシーに関する声明",{"href":538,"dataGaName":539,"dataGaLocation":483},"/ja-jp/privacy/","privacy statement",{"text":541,"config":542},"Cookie 優先設定",{"dataGaName":543,"dataGaLocation":483,"id":544,"isOneTrustButton":17},"cookie preferences","ot-sdk-btn",{"title":96,"links":546,"subMenu":555},[547,551],{"text":548,"config":549},"DevSecOpsプラットフォーム",{"href":78,"dataGaName":550,"dataGaLocation":483},"devsecops platform",{"text":552,"config":553},"AI支援開発",{"href":85,"dataGaName":554,"dataGaLocation":483},"ai-assisted development",[556],{"title":557,"links":558},"トピック",[559,563,568,573,578,581,586,591],{"text":116,"config":560},{"href":561,"dataGaName":562,"dataGaLocation":483},"/ja-jp/topics/ci-cd/","cicd",{"text":564,"config":565},"GitOps",{"href":566,"dataGaName":567,"dataGaLocation":483},"/ja-jp/topics/gitops/","gitops",{"text":569,"config":570},"DevOps",{"href":571,"dataGaName":572,"dataGaLocation":483},"/ja-jp/topics/devops/","devops",{"text":574,"config":575},"バージョン管理",{"href":576,"dataGaName":577,"dataGaLocation":483},"/ja-jp/topics/version-control/","version control",{"text":23,"config":579},{"href":580,"dataGaName":40,"dataGaLocation":483},"/ja-jp/topics/devsecops/",{"text":582,"config":583},"クラウドネイティブ",{"href":584,"dataGaName":585,"dataGaLocation":483},"/ja-jp/topics/cloud-native/","cloud native",{"text":587,"config":588},"コーディングのためのAI",{"href":589,"dataGaName":590,"dataGaLocation":483},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":592,"config":593},"エージェント型AI",{"href":594,"dataGaName":595,"dataGaLocation":483},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":597,"links":598},"ソリューション",[599,602,604,609,613,616,619,622,624,626,629,634],{"text":141,"config":600},{"href":136,"dataGaName":601,"dataGaLocation":483},"Application Security Testing",{"text":128,"config":603},{"href":112,"dataGaName":113,"dataGaLocation":483},{"text":605,"config":606},"アジャイル開発",{"href":607,"dataGaName":608,"dataGaLocation":483},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":610,"config":611},"SCM",{"href":125,"dataGaName":612,"dataGaLocation":483},"source code management",{"text":116,"config":614},{"href":118,"dataGaName":615,"dataGaLocation":483},"continuous integration & delivery",{"text":167,"config":617},{"href":169,"dataGaName":618,"dataGaLocation":483},"value stream management",{"text":564,"config":620},{"href":621,"dataGaName":567,"dataGaLocation":483},"/ja-jp/solutions/gitops/",{"text":180,"config":623},{"href":183,"dataGaName":184,"dataGaLocation":483},{"text":186,"config":625},{"href":189,"dataGaName":190,"dataGaLocation":483},{"text":627,"config":628},"公共機関",{"href":195,"dataGaName":196,"dataGaLocation":483},{"text":630,"config":631},"教育",{"href":632,"dataGaName":633,"dataGaLocation":483},"/ja-jp/solutions/education/","education",{"text":635,"config":636},"金融サービス",{"href":637,"dataGaName":638,"dataGaLocation":483},"/ja-jp/solutions/finance/","financial services",{"title":203,"links":640},[641,643,645,647,650,652,654,656,658,660,662,664],{"text":216,"config":642},{"href":218,"dataGaName":219,"dataGaLocation":483},{"text":221,"config":644},{"href":223,"dataGaName":224,"dataGaLocation":483},{"text":226,"config":646},{"href":228,"dataGaName":229,"dataGaLocation":483},{"text":231,"config":648},{"href":233,"dataGaName":649,"dataGaLocation":483},"docs",{"text":254,"config":651},{"href":256,"dataGaName":257,"dataGaLocation":483},{"text":249,"config":653},{"href":251,"dataGaName":252,"dataGaLocation":483},{"text":259,"config":655},{"href":261,"dataGaName":262,"dataGaLocation":483},{"text":267,"config":657},{"href":269,"dataGaName":270,"dataGaLocation":483},{"text":272,"config":659},{"href":274,"dataGaName":275,"dataGaLocation":483},{"text":277,"config":661},{"href":279,"dataGaName":280,"dataGaLocation":483},{"text":282,"config":663},{"href":284,"dataGaName":285,"dataGaLocation":483},{"text":287,"config":665},{"href":289,"dataGaName":290,"dataGaLocation":483},{"title":306,"links":667},[668,670,672,674,676,678,680,684,689,691,693,695],{"text":314,"config":669},{"href":316,"dataGaName":308,"dataGaLocation":483},{"text":319,"config":671},{"href":321,"dataGaName":322,"dataGaLocation":483},{"text":327,"config":673},{"href":329,"dataGaName":330,"dataGaLocation":483},{"text":332,"config":675},{"href":334,"dataGaName":335,"dataGaLocation":483},{"text":337,"config":677},{"href":339,"dataGaName":340,"dataGaLocation":483},{"text":342,"config":679},{"href":344,"dataGaName":345,"dataGaLocation":483},{"text":681,"config":682},"Sustainability",{"href":683,"dataGaName":681,"dataGaLocation":483},"/sustainability/",{"text":685,"config":686},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":687,"dataGaName":688,"dataGaLocation":483},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":347,"config":690},{"href":349,"dataGaName":350,"dataGaLocation":483},{"text":357,"config":692},{"href":359,"dataGaName":360,"dataGaLocation":483},{"text":362,"config":694},{"href":364,"dataGaName":365,"dataGaLocation":483},{"text":696,"config":697},"現代奴隷制の透明性に関する声明",{"href":698,"dataGaName":699,"dataGaLocation":483},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":701},[702,704,707],{"text":531,"config":703},{"href":533,"dataGaName":534,"dataGaLocation":483},{"text":705,"config":706},"Cookieの設定",{"dataGaName":543,"dataGaLocation":483,"id":544,"isOneTrustButton":17},{"text":536,"config":708},{"href":538,"dataGaName":539,"dataGaLocation":483},[710,725],{"id":711,"title":712,"body":29,"config":713,"content":715,"description":29,"extension":719,"meta":720,"navigation":17,"path":721,"seo":722,"stem":723,"__hash__":724},"blogAuthors/en-us/blog/authors/gitlab-japan-team.yml","Gitlab Japan Team",{"template":714},"BlogAuthor",{"name":10,"config":716},{"headshot":717,"ctfId":718},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","5YWHF8vG80rluQ41QjgP7V","yml",{},"/en-us/blog/authors/gitlab-japan-team",{},"en-us/blog/authors/gitlab-japan-team","xs3yRNTInC3nd_gc5t_qSB_BOSquAfXSF9QA2S_y1g8",{"id":726,"title":727,"body":29,"config":728,"content":729,"description":29,"extension":719,"meta":731,"navigation":17,"path":732,"seo":733,"stem":734,"__hash__":735},"blogAuthors/en-us/blog/authors/gitlab.yml","Gitlab",{"template":714},{"name":11,"config":730},{"headshot":717,"ctfId":11},{},"/en-us/blog/authors/gitlab",{},"en-us/blog/authors/gitlab","XCBKIcPoCs6zi2oHG7o-bAp52Jhaw8_zGhIJ2jNrEjU",[737,752,766],{"content":738,"config":750},{"heroImage":739,"body":740,"authors":741,"updatedDate":743,"date":744,"title":745,"tags":746,"description":749,"category":13},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773843921/rm35fx4gylrsu9alf2fx.png","GitLab 18.10では、脆弱性管理の品質とスピードの向上に焦点を当て、AIを活用したさまざまな新しいセキュリティ機能が導入されました。これらの機能を組み合わせることで、デベロッパーが誤検出の調査に費やす時間を削減し、自動修正をワークフローに直接組み込めるようになるため、セキュリティの専門知識がなくても脆弱性を修正できる環境が実現します。\n\n新機能の概要は以下のとおりです。\n\n* **[静的アプリケーションセキュリティテスト（SAST）の誤検出判定](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/false_positive_detection/)** **の一般提供が開始されました。** このフローでは、LLMによるエージェント型推論を使用して、脆弱性が誤検出である可能性を判定できるため、セキュリティチームと開発チームは重大な脆弱性の修正に優先的に取り組めるようになります。\n* **[エージェント型SAST脆弱性の修正](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/agentic_vulnerability_resolution/)** **がベータ版として提供開始されました。** エージェント型SAST脆弱性解決は、検証済みのSAST脆弱性に対する修正案を含むマージリクエストを自動的に作成します。修正までの時間が短縮され、高度なセキュリティ専門知識の必要になるケースが少なくなります。\n* **[シークレットの誤検出判定機能](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/secret_false_positive_detection/)** **がベータ版として提供開始されました。** このフローは、AIを活用したノイズ削減をシークレット検出にも適用し、ダミーやテスト用のシークレットにフラグを付けてレビューの負担を軽減します。\n\nこれらのフローは、GitLab Duo Agent Platformを使用するGitLab Ultimateのお客様にご利用いただけます。\n\n## SASTの誤検出判定機能でトリアージ時間を短縮\n\n従来のSASTスキャナーは、コードパスが到達可能かどうかや、フレームワークが既にリスクを処理しているかどうかに関係なく、疑わしいコードパターンにすべてフラグ付けしていました。ランタイムコンテキストがなければ、実際の脆弱性と危険に見えるだけの安全なコードを区別できません。\n\nそのため、デベロッパーは誤検出と判明するまで、検出結果の調査に何時間も費やす可能性がありました。時間の経過とともにレポートへの信頼が低下し、実際のリスクの修正を担当するチームの作業が遅延する原因となっていたのです。\n\n各SASTスキャンの後、GitLab Duo Agent Platformは新しい「致命的」と「高」の重大度の検出結果を自動的に分析し、以下の情報を付加します。\n\n* 検出結果が誤検出である可能性を示す信頼度スコア\n* AI生成による判定理由の説明\n* UIにより「誤検出の可能性が高い」と「実際の脆弱性の可能性が高い」を簡単に目視で識別できるバッジ\n\nこれらの検出結果は、以下のように[脆弱性レポート](https://docs.gitlab.com/ja-jp/user/application_security/vulnerability_report/)に表示されます。レポートをフィルタリングして「誤検出ではない」とマークされた検出結果を絞り込むことで、チームはノイズの選別ではなく実際の脆弱性への対応に時間を使えるようになります。\n\n![脆弱性レポート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1773844787/i0eod01p7gawflllkgsr.png)\n\nGitLab Duo Agent Platformの評価はあくまで推奨事項です。すべての誤検出の判定はユーザーが管理でき、エージェントの推論をいつでも監査して信頼性の高いモデルを構築できます。\n\n## 脆弱性を自動修正に変換\n\n実際に脆弱性であると判明しても、まだ作業の半分が完了したにすぎません。修正には、コードパスの理解、安全なパッチの作成、他の部分への影響がないことの確認が必要です。\n\nSASTの誤検出判定フローによって脆弱性が誤検出ではない可能性が高いと判定された場合、エージェント型SAST脆弱性解決フローが自動的に以下を実行します。\n\n1. リポジトリから脆弱なコードとその周辺のコンテキストを読み取る\n2. 高品質な修正案を生成する\n3. 自動テストによって修正を検証する\n4. 以下を含む修正案のマージリクエストを作成する：\n\n   * 具体的なコード変更\n   * 信頼度スコア\n   * 変更内容とその理由の説明\n\nこのデモでは、GitLabがSAST脆弱性を検出からレビュー可能なマージリクエストまで自動的に処理する様子をご覧いただけます。エージェントがコードを読み取り、修正を生成・検証し、明確で説明可能な変更を含むMRを作成する流れをご確認ください。デベロッパーにセキュリティの専門知識がなくても、より迅速に修正を行えるようになります。\n\n\u003Ciframe src=\"https://player.vimeo.com/video/1174573325?badge=0&autopause=0&player_id=0&app_id=58479\" frameborder=\"0\" allow=\"autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" title=\"GitLab 18.10 AI SAST False Positive Auto Remediation\">\u003C/iframe>\u003Cscript src=\"https://player.vimeo.com/api/player.js\">\u003C/script>\n\nAI生成の提案と同様に、マージを行う前に提案されたマージリクエストを慎重にレビューしてください。\n\n## 実際のシークレットを特定\n\nシークレット検出は、チームが結果を信頼できて初めて有用なものとなります。レポートにテスト用の認証情報やプレースホルダーの値、サンプルトークンが大量に含まれていると、デベロッパーは実際の漏洩を修正するよりも、ノイズのレビューに時間を浪費してしまう可能性があります。その結果、修正が遅延し、スキャンへの信頼が低下しかねません。\n\nシークレットの誤検出判定機能は、チームが重要なシークレットに集中し、より迅速にリスクを軽減できるよう支援します。この機能がデフォルトブランチで実行されると、自動的に以下が行われます。\n\n1. 各検出結果を分析し、テスト用の認証情報、サンプル値、ダミーシークレットの可能性を特定する\n2. 検出結果が実際のリスクか誤検出の可能性が高いかの信頼度スコアを付与する\n3. 実際のシークレット、ノイズのいずれかとして扱われる理由の説明を生成する\n4. 脆弱性レポートにバッジを追加し、デベロッパーがステータスを一目で確認できるようにする\n\nデベロッパーは、脆弱性レポートからシークレット検出の結果に対して「**誤検出を確認**」を選択することで、この分析を手動でトリガーすることもできます。リスクのない検出結果を除外し、実際のシークレットへの対応をより速やかに開始できます。\n\n## AIを活用したセキュリティ機能を今すぐお試しください\n\nGitLab 18.10では、SASTとシークレット検出における誤検出ノイズの削減から、修正案を含むマージリクエストの自動生成まで、脆弱性ワークフロー全体をカバーする機能が導入されました。\n\nAIを活用したセキュリティ機能がレビュー時間の短縮と検出結果のマージ可能な修正への変換にどのように役立つかをご確認いただくには、[GitLab Duo Agent Platformの無料トライアルを今すぐ開始](https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_gitlab-18-10-brings-ai-native-triage-and-remediation)してください。",[742],"Alisa Ho","2026-03-25","2026-03-19","GitLab 18.10がAIネイティブなトリアージと修正機能を導入",[747,13,748],"product","features","ノイズを排除して実際の脆弱性を特定し、修正案につなげるGitLab Duo Agent Platformの機能をご紹介します。",{"featured":35,"template":15,"slug":751},"gitlab-18-10-brings-ai-native-triage-and-remediation",{"content":753,"config":764},{"heroImage":754,"body":755,"authors":756,"updatedDate":758,"date":759,"title":760,"tags":761,"description":763,"category":13},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png","コンテナの脆弱性は、次のデプロイメントを待ってくれるわけではありません。イメージのビルド時や、コンテナが本番環境で稼働している間など、あらゆるタイミングで発生する可能性があります。\nGitLab はこうした現実に対応するため、コンテナライフサイクルのさまざまな段階に対応した複数のコンテナスキャンアプローチを提供しています。\n\n本ガイドでは、GitLab が提供するコンテナスキャンの種類、各機能の有効化方法、および初期設定に役立つ一般的な構成についてご説明します。\n\n## コンテナスキャンが重要な理由\n\nコンテナイメージのセキュリティ脆弱性は、アプリケーションライフサイクル全体にわたってリスクをもたらします。ベースイメージ、OSパッケージ、アプリケーションの依存関係はいずれも、攻撃者が積極的に悪用する脆弱性を含んでいる可能性があります。コンテナスキャンはこれらのリスクを早期に、本番環境に到達する前に検出し、利用可能な場合は修正方法を提供します。\n\nコンテナスキャンはソフトウェアコンポジション分析（SCA）の重要なコンポーネントであり、コンテナ化されたアプリケーションが依存する外部依存関係を把握し、保護するために役立ちます。\n\n## GitLab コンテナスキャンの5つの種類\n\nGitLab は5つの異なるコンテナスキャンアプローチを提供しており、それぞれがセキュリティ戦略において固有の目的を果たします。\n\n### 1. パイプラインベースのコンテナスキャン\n\n* 機能：CI/CDパイプラインの実行中にコンテナイメージをスキャンし、デプロイ前に脆弱性を検出します。\n* 最適な用途：シフトレフトセキュリティ、脆弱性のあるイメージが本番環境に到達するのを防止\n* 利用可能なプラン：Free、Premium、Ultimate（Ultimateではより高度な機能を利用可能）\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/)\n\nGitLab は Trivy セキュリティスキャナーを使用してコンテナイメージの既知の脆弱性を分析します。パイプラインの実行時にスキャナーがイメージを検査し、詳細なレポートを生成します。\n\n#### パイプラインベースのコンテナスキャンを有効にする方法\n\n**オプション A：事前設定済みのマージリクエスト**\n\n* プロジェクトで **Secure > セキュリティ設定** に移動します。\n* 「コンテナスキャン」の行を見つけます。\n* **マージリクエストで設定** を選択します。\n* 必要な設定を含むマージリクエストが自動的に作成されます。\n\n**オプション B：手動設定**\n\n* `.gitlab-ci.yml` に以下を追加します。\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n```\n\n#### 一般的な設定\n\n**特定のイメージをスキャンする：**\n\n特定のイメージをスキャンするには、`container_scanning` ジョブの `CS_IMAGE` 変数を上書きします。\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\ncontainer_scanning:\n  variables:\n    CS_IMAGE: myregistry.com/myapp:latest\n```\n\n**重大度のしきい値でフィルタリングする：**\n\n特定の重大度基準を持つ脆弱性のみを検出するには、`container_scanning` ジョブの `CS_SEVERITY_THRESHOLD` 変数を上書きします。以下の例では、重大度が **High** 以上の脆弱性のみが表示されます。\n\n```yaml\ninclude:\n  - template: Jobs/Container-Scanning.gitlab-ci.yml\n\ncontainer_scanning:\n  variables:\n    CS_SEVERITY_THRESHOLD: \"HIGH\"\n```\n\n#### マージリクエストでの脆弱性の確認\n\nマージリクエスト内でコンテナスキャンの脆弱性を直接確認することで、セキュリティレビューをシームレスかつ効率的に実施できます。CI/CDパイプラインにコンテナスキャンを設定すると、GitLab はマージリクエストの[セキュリティウィジェット](https://docs.gitlab.com/ja-jp/user/project/merge_requests/widgets/#application-security-scanning)に検出された脆弱性を自動的に表示します。\n\n![マージリクエストに表示されたコンテナスキャンの脆弱性](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/lt6elcq6jexdhqatdy8l.png \"マージリクエストに表示されたコンテナスキャンの脆弱性\")\n\n* マージリクエストの「セキュリティスキャン」セクションまでスクロールすると、コンテナイメージで新たに検出された脆弱性と既存の脆弱性の概要が確認できます。\n* **脆弱性** をクリックすると、重大度レベル、影響を受けるパッケージ、利用可能な修正ガイダンスなど、検出内容の詳細情報にアクセスできます。\n\n![GitLab セキュリティ - MRでの詳細表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/hplihdlekc11uvpfih1p.png)\n\n![GitLab セキュリティ - MRでの詳細表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/jnxbe7uld8wfeezboifs.png \"MRでのコンテナスキャン脆弱性の詳細\")\n\nこの可視性により、開発者とセキュリティチームはコンテナの脆弱性が本番環境に到達する前に発見・対処できるようになり、セキュリティがコードレビュープロセスに統合されます。\n\n#### 脆弱性レポートでの脆弱性の確認\n\nマージリクエストのレビューに加え、GitLab はプロジェクト内のすべてのコンテナスキャン結果を一元的に確認できる[脆弱性レポート](https://docs.gitlab.com/ja-jp/user/application_security/vulnerability_report/)を提供しており、セキュリティチームに包括的な可視性をもたらします。\n\n![コンテナスキャンでフィルタリングされた脆弱性レポート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547524/gagau279fzfgjpnvipm5.png \"コンテナスキャンでフィルタリングされた脆弱性レポート\")\n\n* プロジェクトのサイドバーで **セキュリティとコンプライアンス > 脆弱性レポート** に移動してレポートにアクセスします。\n* ここでは、ブランチ全体で検出されたすべてのコンテナ脆弱性が集約されて表示され、重大度、ステータス、スキャナーの種類、特定のコンテナイメージでフィルタリングする強力なオプションが利用できます。\n* 脆弱性をクリックすると、脆弱性ページにアクセスできます。\n\n![脆弱性ページ - 1番目のビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547520/e1woxupyoajhrpzrlylj.png)\n\n![脆弱性ページ - 2番目のビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547521/idzcftcgjc8eryixnbjn.png)\n\n![脆弱性ページ - 3番目のビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547522/mbbwbbprtf9anqqola10.png \"コンテナスキャン脆弱性の詳細\")\n\n[脆弱性の詳細](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/)では、影響を受けるコンテナイメージとレイヤーが正確に示されるため、脆弱性の発生源を容易に追跡できます。脆弱性をチームメンバーに割り当て、ステータスを変更（検出済み、確認済み、解決済み、却下済み）し、コラボレーションのためのコメントを追加し、修正作業の追跡のために関連するイシューをリンクすることができます。\n\nこのワークフローにより、脆弱性管理がスプレッドシートによる管理から開発プロセスの一部へと変わり、コンテナセキュリティの検出結果が体系的に追跡・優先順位付け・解決されるようになります。\n\n#### 依存関係リストの確認\n\nGitLab の[依存関係リスト](https://docs.gitlab.com/ja-jp/user/application_security/dependency_list/)は、コンテナイメージ内のすべてのコンポーネントをカタログ化した包括的なソフトウェア部品表（SBOM）を提供し、ソフトウェアサプライチェーンの完全な透明性をもたらします。\n\n* **セキュリティとコンプライアンス > 依存関係リスト** に移動すると、プロジェクト全体でコンテナスキャンが検出したすべてのパッケージ、ライブラリ、依存関係のインベントリにアクセスできます。\n* このビューは、ベースOSパッケージからアプリケーションレベルの依存関係まで、コンテナ内で実際に稼働しているものを把握するために非常に役立ちます。\n\n![GitLab 依存関係リスト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/vjg6dk3nhajqamplroji.png \"GitLab 依存関係リスト（SBOM）\")\n\nパッケージマネージャー、ライセンスの種類、または脆弱性のステータスでリストをフィルタリングすることで、セキュリティリスクやコンプライアンス上の問題をもたらすコンポーネントを素早く特定できます。各依存関係エントリには関連する脆弱性が表示されるため、単独の検出結果としてではなく、実際のソフトウェアコンポーネントのコンテキストでセキュリティの問題を把握できます。\n\n### 2. レジストリ向けコンテナスキャン\n\n* 機能：`latest` タグで GitLab コンテナレジストリにプッシュされたイメージを自動的にスキャンします。\n* 最適な用途：手動のパイプラインを実行することなく、レジストリイメージの継続的なモニタリングを実施\n* 利用可能なプラン：Ultimate のみ\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/#container-scanning-for-registry)\n\n`latest` タグが付いたコンテナイメージをプッシュすると、GitLab のセキュリティポリシーボットがデフォルトブランチに対してスキャンを自動的にトリガーします。パイプラインベースのスキャンとは異なり、このアプローチは継続的脆弱性スキャンと連携して、新たに公開されたアドバイザリーを監視します。\n\n#### レジストリ向けコンテナスキャンを有効にする方法\n\n1. **Secure > セキュリティ設定** に移動します。\n2. **レジストリ向けコンテナスキャン** セクションまでスクロールします。\n3. 機能をオンに切り替えます。\n\n![レジストリ向けコンテナスキャン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547512/vntrlhtmsh1ecnwni5ji.png \"レジストリ向けコンテナスキャンの切り替えスイッチ\")\n\n#### 前提条件\n\n* プロジェクトのメンテナーロール以上\n* プロジェクトが空でないこと（デフォルトブランチに少なくとも1つのコミットが必要）\n* コンテナレジストリの通知が設定済みであること\n* パッケージメタデータデータベースが設定済みであること（GitLab.com ではデフォルトで有効）\n\n脆弱性は脆弱性レポートの **コンテナレジストリの脆弱性** タブに表示されます。\n\n### 3. マルチコンテナスキャン\n\n* 機能：単一のパイプライン内で複数のコンテナイメージを並行してスキャンします。\n* 最適な用途：マイクロサービスアーキテクチャや複数のコンテナイメージを持つプロジェクト\n* 利用可能なプラン：Free、Premium、Ultimate（現在ベータ版）\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/multi_container_scanning/)\n\nマルチコンテナスキャンは動的な子パイプラインを使用してスキャンを並行実行するため、複数のイメージをスキャンする際のパイプライン全体の実行時間を大幅に短縮できます。\n\n#### マルチコンテナスキャンを有効にする方法\n\n1. リポジトリのルートに `.gitlab-multi-image.yml` ファイルを作成します。\n\n```yaml\nscanTargets:\n  - name: alpine\n    tag: \"3.19\"\n  - name: python\n    tag: \"3.9-slim\"\n  - name: nginx\n    tag: \"1.25\"\n```\n\n2. `.gitlab-ci.yml` にテンプレートを追加します。\n\n```yaml\ninclude:\n  - template: Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml\n```\n\n#### 詳細設定\n\n**プライベートレジストリからイメージをスキャンする：**\n\n```yaml\nauths:\n  registry.gitlab.com:\n    username: ${CI_REGISTRY_USER}\n    password: ${CI_REGISTRY_PASSWORD}\n\nscanTargets:\n  - name: registry.gitlab.com/private/image\n    tag: latest\n```\n\n**ライセンス情報を含める：**\n\n```yaml\nincludeLicenses: true\n\nscanTargets:\n  - name: postgres\n    tag: \"15-alpine\"\n```\n\n### 4. 継続的脆弱性スキャン\n\n* 機能：パイプラインを実行することなく、新しいセキュリティアドバイザリーが公開された際に自動的に脆弱性を作成します。\n* 最適な用途：デプロイ間のプロアクティブなセキュリティモニタリング\n* 利用可能なプラン：Ultimate のみ\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/continuous_vulnerability_scanning/)\n\n従来のスキャンは、スキャン実行時の脆弱性しか検出できません。しかし、昨日スキャンしたパッケージに対して、明日新しい CVE が公開された場合はどうなるでしょうか。継続的脆弱性スキャンは、GitLab アドバイザリーデータベースを監視し、新しいアドバイザリーがコンポーネントに影響を与える際に自動的に脆弱性レコードを作成することでこの課題を解決します。\n\n#### 仕組み\n\n1. コンテナスキャンまたは依存関係スキャンジョブが CycloneDX SBOM を生成します。\n2. GitLab はこの SBOM からプロジェクトのコンポーネントを登録します。\n3. 新しいアドバイザリーが公開されると、GitLab はコンポーネントが影響を受けるかどうかを確認します。\n4. 脆弱性レポートに脆弱性が自動的に作成されます。\n\n#### 重要な考慮事項\n\n* スキャンは CI パイプラインではなく、バックグラウンドジョブ（Sidekiq）経由で実行されます。\n* 新しいコンポーネント検出には、過去14日以内に公開されたアドバイザリーのみが対象となります。\n* 脆弱性では「GitLab SBoM Vulnerability Scanner」がスキャナー名として使用されます。\n* 脆弱性を解決済みとしてマークするには、引き続きパイプラインベースのスキャンを実行する必要があります。\n\n### 5. 運用コンテナスキャン\n\n* 機能：スケジュールされた間隔で Kubernetes クラスター内の稼働中のコンテナをスキャンします。\n* 最適な用途：デプロイ後のセキュリティモニタリングとランタイム脆弱性の検出\n* 利用可能なプラン：Ultimate のみ\n* [ドキュメント](https://docs.gitlab.com/ja-jp/user/clusters/agent/vulnerabilities/)\n\n運用コンテナスキャンは、ビルド時のセキュリティとランタイムセキュリティの間のギャップを埋めます。GitLab Agent for Kubernetes を使用して、クラスター内で実際に稼働しているコンテナをスキャンし、デプロイ後に発生する脆弱性を検出します。\n\n#### 運用コンテナスキャンを有効にする方法\n\n[GitLab Kubernetes Agent](https://docs.gitlab.com/ja-jp/user/clusters/agent/install/) を使用している場合、エージェント設定ファイルに以下を追加できます。\n\n```yaml\ncontainer_scanning:\n  cadence: '0 0 * * *'  # 毎日深夜0時\n  vulnerability_report:\n    namespaces:\n      include:\n        - production\n        - staging\n```\n\nまた、GitLab Kubernetes Agent によるスケジュールスキャンを強制する[スキャン実行ポリシー](https://docs.gitlab.com/ja-jp/user/clusters/agent/vulnerabilities/#enable-via-scan-execution-policies)を作成することもできます。\n\n![スキャン実行ポリシー - 運用コンテナスキャン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547515/gsgvjcq4sas4dfc8ciqk.png \"運用コンテナスキャンのスキャン実行ポリシー条件\")\n\n#### 結果の確認\n\n* **運用 > Kubernetes クラスター** に移動します。\n* **エージェント** タブを選択し、エージェントを選択します。\n* **セキュリティ** タブを選択してクラスターの脆弱性を確認します。\n* 結果は **脆弱性レポート** の **運用上の脆弱性** タブにも表示されます。\n\n## GitLab セキュリティポリシーによるセキュリティ態勢の強化\n\nGitLab セキュリティポリシーを使用すると、自動化されたポリシー駆動型のコントロールを通じて、コンテナワークフロー全体で一貫したセキュリティ標準を適用できます。これらのポリシーは、要件を開発パイプラインに直接組み込むことでセキュリティをシフトレフトし、コードが本番環境に到達する前に脆弱性を検出・対処できるようにします。\n\n#### スキャン実行ポリシーとパイプラインポリシー\n\n[スキャン実行ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/scan_execution_policies/)は、プロジェクト全体でコンテナスキャンがいつ・どのように実行されるかを自動化します。すべてのマージリクエストでコンテナスキャンをトリガーし、メインブランチの定期的なスキャンをスケジュールするポリシーなどを定義できます。これらのポリシーにより、各プロジェクトの CI/CD パイプラインで手動でスキャンを設定することなく、包括的なカバレッジが確保されます。\n\n使用するスキャナーのバージョンを指定し、スキャンパラメーターを一元的に設定することで、新しいコンテナセキュリティの脅威に対応しながら組織全体の一貫性を維持できます。\n\n![スキャン実行ポリシーの設定](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/z36dntxslqem9udrynvx.png \"スキャン実行ポリシーの設定\")\n\n[パイプライン実行ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/pipeline_execution_policies/)は、コンプライアンス要件に基づいてパイプラインにカスタムジョブを注入（または上書き）するための柔軟なコントロールを提供します。\n\nこれらのポリシーを使用して、コンテナスキャンジョブをパイプラインに自動的に注入したり、コンテナの脆弱性がリスク許容度を超えた場合にビルドを失敗させたり、特定のブランチやタグに対して追加のセキュリティチェックをトリガーしたり、本番環境向けコンテナイメージのコンプライアンス要件を適用したりすることができます。パイプライン実行ポリシーは自動化されたガードレールとして機能し、手動操作なしですべてのコンテナデプロイメントにセキュリティ標準が一貫して適用されるようにします。\n\n![パイプライン実行ポリシー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/ddhhugzcr2swptgodof2.png \"パイプライン実行ポリシーのアクション\")\n\n#### マージリクエスト承認ポリシー\n\n[マージリクエスト承認ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/merge_request_approval_policies/)は、コンテナの脆弱性を含むマージリクエストを指定された承認者がレビューし、承認することを要求することでセキュリティゲートを適用します。\n\n重大度の高い脆弱性が検出された場合にマージをブロックするポリシーや、新しいコンテナの検出結果を導入するマージリクエストにセキュリティチームの承認を要求するポリシーを設定できます。これらのポリシーにより、低リスクな変更の開発速度を維持しながら、脆弱性のあるコンテナイメージがパイプラインを通じて進むことを防ぎます。\n\n![MRでブロックを実行するマージリクエスト承認ポリシー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/hgnbc1vl4ssqafqcyuzg.png \"MRでブロックを実行するマージリクエスト承認ポリシー\")\n\n## 適切なアプローチの選択\n\n| スキャンの種類   | 使用するタイミング   | 主なメリット                   |\n| --------- | ----------- | ------------------------ |\n| パイプラインベース | すべてのビルド時    | シフトレフトセキュリティ、脆弱なビルドをブロック |\n| レジストリスキャン | 継続的なモニタリング  | 保存されたイメージの新しい CVE を検出    |\n| マルチコンテナ   | マイクロサービス    | 並行スキャン、パイプラインの高速化        |\n| 継続的脆弱性    | デプロイ間       | プロアクティブなアドバイザリーモニタリング    |\n| 運用        | 本番環境のモニタリング | ランタイム脆弱性の検出              |\n\n包括的なセキュリティのためには、複数のアプローチを組み合わせることをお勧めします。開発中の問題を検出するためのパイプラインベースのスキャン、継続的なモニタリングのためのレジストリ向けコンテナスキャン、そして本番環境の可視性のための運用スキャンを組み合わせてご活用ください。\n\n## 今すぐ始める\n\nコンテナセキュリティへの最短ルートは、パイプラインベースのスキャンを有効にすることです。\n\n1. プロジェクトの **Secure > セキュリティ設定** に移動します。\n2. コンテナスキャンの **マージリクエストで設定** をクリックします。\n3. 作成されたマージリクエストをマージします。\n4. 次のパイプラインに脆弱性スキャンが含まれるようになります。\n\nその後、セキュリティ要件と GitLab のプランに応じて、追加のスキャンの種類を段階的に導入してください。\n\nコンテナセキュリティは一度実施すれば完了するものではなく、継続的なプロセスです。\nGitLab の包括的なコンテナスキャン機能を活用することで、ビルドからランタイムまでコンテナライフサイクルのあらゆる段階で脆弱性を検出できます。\n\n> GitLab がセキュリティ態勢の強化にどのように役立つかについての詳細は、[GitLab セキュリティ & ガバナンス ソリューションページ](https://about.gitlab.com/solutions/application-security-testing/)をご覧ください。",[757],"Fernando Diaz","2026-03-09","2026-03-05","GitLab コンテナスキャン完全ガイド：SBOM生成から運用監視まで5つのスキャン手法",[13,762],"tutorial","GitLab のさまざまなコンテナスキャン方法を詳しく解説し、コンテナライフサイクルの各段階でセキュリティを確保する方法をご紹介します。",{"slug":765,"featured":17,"template":15},"complete-guide-to-gitlab-container-scanning",{"content":767,"config":776},{"title":768,"description":769,"authors":770,"heroImage":772,"date":773,"body":774,"category":13,"tags":775},"GitLab.comのセキュリティ強化：多要素認証の必須化","Secure by Designへのコミットメントの一環として、GitLabが多要素認証（MFA）を必須化する方法と、それがユーザーに与える影響について解説します。",[771],"Kim Waters","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664923/Blog/Hero%20Images/security-checklist.png","2026-01-09","GitLab.comのすべてのユーザーアカウントのセキュリティ強化のため、GitLabでは、ユーザー名とパスワードを使用してサインインするすべてのユーザーとAPIエンドポイントに対して、多要素認証（MFA）を必須化します。\n\n## 多要素認証必須化の理由\n\n今回の変更は、GitLabの[Secure by Designへのコミットメント](https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/)における重要な取り組みの1つです。MFAは、ソフトウェア開発業界全体で継続的な脅威となっているクレデンシャルスタッフィング攻撃やアカウント乗っ取り攻撃に対する重要な防御手段となります。\n\n## 知っておくべき重要な情報\n\n### 何が変わるのか？\n\nGitLabは、ユーザー名とパスワードで認証するサインインに対して、MFAを必須化します。これにより、パスワードだけでなく、重要な第2の認証レイヤーが追加されます。\n\n### 適用されるケースとされないケース\n\n1. ***適用されるケース：*** ユーザー名とパスワードでGitLab.comにサインインする場合、またはパスワードを使用してAPIに認証する場合\n2. ***適用されないケース：*** アクセスにソーシャルサインオン（Googleなど）またはシングルサインオン（SSO）のみを使用している場合（*注意：SSOを使用していても、直接ログイン用のパスワードを設定している場合は、SSO以外のパスワードベースのログインに対してMFAが必要になります）*\n\n### ロールアウトのタイムライン\n\n1. 実装は今後数か月にわたって段階的に行われます。これは、ユーザーの予期しない中断や生産性の低下を最小限に抑え、アカウントのロックアウトを防ぐことを目的としています。ユーザーグループによって時期は異なりますが、近日中にMFAの有効化を求められます。各グループは、実行したアクション、またはコントリビュートしたコードに基づいて選択されます。以下の方法で通知されます。\n\n   * ✉️ メール通知 - 影響を受けるフェーズの前\n   * 🔔 定期的な製品内リマインダー - 14日前\n   * ⏱️ 一定期間後（メールが届きます） - MFAを有効にするまでGitLabへのアクセスがブロックされます\n\n### 必要な対応\n\n1. ユーザー名とパスワードでGitLab.comにサインインする場合：\n\n   * パスキー、認証アプリ、WebAuthnデバイス、またはメール認証など、利用可能なMFA方法の1つを今すぐ事前に設定することを強くおすすめします。これにより、最も安全でシームレスな移行が保証されます。\n   * GitLab.comの**ユーザー設定**にアクセスします。\n   * **アカウント**セクションを選択します。\n   * **2要素認証**を有効にし、希望する方法（認証アプリやWebAuthnデバイスなど）を設定します。\n   * 必要に応じてアクセスを回復できるよう、**リカバリーコードを安全に保存**してください。\n2. パスワードを使用してAPIに認証する場合：\n\n   * 個人アクセストークン（PAT）への切り替えを事前に行うことを強くおすすめします。詳細については、[ドキュメント](https://docs.gitlab.com/ja-jp/user/profile/account/two_factor_authentication_troubleshooting/#error-http-basic-access-denied-if-a-password-was-provided-for-git-authentication-)をご確認ください。\n\n## よくある質問\n\n*期限までにMFAを有効にしないとどうなりますか？*\n\n* サインインする前にMFAの設定が必要になります。\n\n*CI/CDパイプラインや自動化に影響はありますか？*\n\n* はい、パスワードの代わりにPATまたはデプロイトークンを使用していない場合は影響があります。\n\n*SSOを使用していますが、直接サインインすることもあります。その場合、MFAは必要ですか？*\n\n* はい、フォールバックシナリオを含む、パスワードベースの認証にはMFAが必要です。\n\n*どのようなMFAリカバリーオプションが利用できますか？*\n\n* [トラブルシューティングドキュメント](https://docs.gitlab.com/ja-jp/user/profile/account/two_factor_authentication_troubleshooting/#recovery-options-and-2fa-reset)をご確認ください。*\n\n具体的なタイムラインとその他のリソースについては、ロールアウト日までに段階的に共有される予定です。この重要な変更についてご覧いただき、ありがとうございます。",[13,747],{"featured":35,"template":15,"slug":777},"strengthening-gitlab-com-security-mandatory-multi-factor-authentication",{"promotions":779},[780,794,805,816],{"id":781,"categories":782,"header":784,"text":785,"button":786,"image":791},"ai-modernization",[783],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":787,"config":788},"Get your AI maturity score",{"href":789,"dataGaName":790,"dataGaLocation":257},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":792},{"src":793},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":795,"categories":796,"header":797,"text":785,"button":798,"image":802},"devops-modernization",[747,40],"Are you just managing tools or shipping innovation?",{"text":799,"config":800},"Get your DevOps maturity score",{"href":801,"dataGaName":790,"dataGaLocation":257},"/assessments/devops-modernization-assessment/",{"config":803},{"src":804},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":806,"categories":807,"header":808,"text":785,"button":809,"image":813},"security-modernization",[13],"Are you trading speed for security?",{"text":810,"config":811},"Get your security maturity score",{"href":812,"dataGaName":790,"dataGaLocation":257},"/assessments/security-modernization-assessment/",{"config":814},{"src":815},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":817,"paths":818,"header":821,"text":822,"button":823,"image":828},"github-azure-migration",[819,820],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":824,"config":825},"See how GitLab compares to GitHub",{"href":826,"dataGaName":827,"dataGaLocation":257},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":829},{"src":804},{"header":831,"blurb":832,"button":833,"secondaryButton":837},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":51,"config":834},{"href":835,"dataGaName":54,"dataGaLocation":836},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/ja-jp/","feature",{"text":56,"config":838},{"href":58,"dataGaName":59,"dataGaLocation":836},1777934979374]