[{"data":1,"prerenderedAt":809},["ShallowReactive",2],{"/ja-jp/blog/complete-guide-to-gitlab-container-scanning":3,"navigation-ja-jp":36,"banner-ja-jp":447,"footer-ja-jp":457,"blog-post-authors-ja-jp-Fernando Diaz":693,"blog-related-posts-ja-jp-complete-guide-to-gitlab-container-scanning":707,"blog-promotions-ja-jp":748,"next-steps-ja-jp":800},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":23,"extension":24,"externalUrl":25,"featured":14,"heroImage":17,"isFeatured":14,"meta":26,"navigation":14,"path":27,"publishedDate":20,"rawbody":28,"seo":29,"slug":13,"stem":32,"tagSlugs":33,"tags":34,"template":15,"updatedDate":19,"__hash__":35},"blogPosts/ja-jp/blog/complete-guide-to-gitlab-container-scanning.yml","GitLab コンテナスキャン完全ガイド：SBOM生成から運用監視まで5つのスキャン手法",[7],"fernando-diaz",[9],"Fernando Diaz","コンテナの脆弱性は、次のデプロイメントを待ってくれるわけではありません。イメージのビルド時や、コンテナが本番環境で稼働している間など、あらゆるタイミングで発生する可能性があります。\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/)をご覧ください。","security",{"slug":13,"featured":14,"template":15},"complete-guide-to-gitlab-container-scanning",true,"BlogPost",{"heroImage":17,"body":10,"authors":18,"updatedDate":19,"date":20,"title":5,"tags":21,"description":23,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png",[9],"2026-03-09","2026-03-05",[11,22],"tutorial","GitLab のさまざまなコンテナスキャン方法を詳しく解説し、コンテナライフサイクルの各段階でセキュリティを確保する方法をご紹介します。","yml",null,{},"/ja-jp/blog/complete-guide-to-gitlab-container-scanning","seo:\n  config:\n    noIndex: false\n  title: GitLab コンテナスキャン完全ガイド：SBOM生成から運用監視まで5つのスキャン手法\n  description: GitLab のさまざまなコンテナスキャン方法を詳しく解説し、コンテナライフサイクルの各段階でセキュリティを確保する方法をご紹介します。\n  ogTitle: GitLab コンテナスキャン完全ガイド：SBOM生成から運用監視まで5つのスキャン手法\ncontent:\n  heroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1772721753/frfsm1qfscwrmsyzj1qn.png\n  body: >-\n    コンテナの脆弱性は、次のデプロイメントを待ってくれるわけではありません。イメージのビルド時や、コンテナが本番環境で稼働している間など、あらゆるタイミングで発生する可能性があります。\n\n    GitLab はこうした現実に対応するため、コンテナライフサイクルのさまざまな段階に対応した複数のコンテナスキャンアプローチを提供しています。\n\n\n    本ガイドでは、GitLab が提供するコンテナスキャンの種類、各機能の有効化方法、および初期設定に役立つ一般的な構成についてご説明します。\n\n\n    ## コンテナスキャンが重要な理由\n\n\n    コンテナイメージのセキュリティ脆弱性は、アプリケーションライフサイクル全体にわたってリスクをもたらします。ベースイメージ、OSパッケージ、アプリケーションの依存関係はいずれも、攻撃者が積極的に悪用する脆弱性を含んでいる可能性があります。コンテナスキャンはこれらのリスクを早期に、本番環境に到達する前に検出し、利用可能な場合は修正方法を提供します。\n\n\n    コンテナスキャンはソフトウェアコンポジション分析（SCA）の重要なコンポーネントであり、コンテナ化されたアプリケーションが依存する外部依存関係を把握し、保護するために役立ちます。\n\n\n    ## GitLab コンテナスキャンの5つの種類\n\n\n    GitLab は5つの異なるコンテナスキャンアプローチを提供しており、それぞれがセキュリティ戦略において固有の目的を果たします。\n\n\n    ### 1. パイプラインベースのコンテナスキャン\n\n\n    * 機能：CI/CDパイプラインの実行中にコンテナイメージをスキャンし、デプロイ前に脆弱性を検出します。\n\n    * 最適な用途：シフトレフトセキュリティ、脆弱性のあるイメージが本番環境に到達するのを防止\n\n    * 利用可能なプラン：Free、Premium、Ultimate（Ultimateではより高度な機能を利用可能）\n\n    * [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/)\n\n\n    GitLab は Trivy セキュリティスキャナーを使用してコンテナイメージの既知の脆弱性を分析します。パイプラインの実行時にスキャナーがイメージを検査し、詳細なレポートを生成します。\n\n\n    #### パイプラインベースのコンテナスキャンを有効にする方法\n\n\n    **オプション A：事前設定済みのマージリクエスト**\n\n\n    * プロジェクトで **Secure > セキュリティ設定** に移動します。\n\n    * 「コンテナスキャン」の行を見つけます。\n\n    * **マージリクエストで設定** を選択します。\n\n    * 必要な設定を含むマージリクエストが自動的に作成されます。\n\n\n    **オプション B：手動設定**\n\n\n    * `.gitlab-ci.yml` に以下を追加します。\n\n\n    ```yaml\n\n    include:\n      - template: Jobs/Container-Scanning.gitlab-ci.yml\n    ```\n\n\n    #### 一般的な設定\n\n\n    **特定のイメージをスキャンする：**\n\n\n    特定のイメージをスキャンするには、`container_scanning` ジョブの `CS_IMAGE` 変数を上書きします。\n\n\n    ```yaml\n\n    include:\n      - template: Jobs/Container-Scanning.gitlab-ci.yml\n\n    container_scanning:\n      variables:\n        CS_IMAGE: myregistry.com/myapp:latest\n    ```\n\n\n    **重大度のしきい値でフィルタリングする：**\n\n\n    特定の重大度基準を持つ脆弱性のみを検出するには、`container_scanning` ジョブの `CS_SEVERITY_THRESHOLD` 変数を上書きします。以下の例では、重大度が **High** 以上の脆弱性のみが表示されます。\n\n\n    ```yaml\n\n    include:\n      - template: Jobs/Container-Scanning.gitlab-ci.yml\n\n    container_scanning:\n      variables:\n        CS_SEVERITY_THRESHOLD: \"HIGH\"\n    ```\n\n\n    #### マージリクエストでの脆弱性の確認\n\n\n    マージリクエスト内でコンテナスキャンの脆弱性を直接確認することで、セキュリティレビューをシームレスかつ効率的に実施できます。CI/CDパイプラインにコンテナスキャンを設定すると、GitLab はマージリクエストの[セキュリティウィジェット](https://docs.gitlab.com/ja-jp/user/project/merge_requests/widgets/#application-security-scanning)に検出された脆弱性を自動的に表示します。\n\n\n    ![マージリクエストに表示されたコンテナスキャンの脆弱性](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/lt6elcq6jexdhqatdy8l.png \"マージリクエストに表示されたコンテナスキャンの脆弱性\")\n\n\n    * マージリクエストの「セキュリティスキャン」セクションまでスクロールすると、コンテナイメージで新たに検出された脆弱性と既存の脆弱性の概要が確認できます。\n\n    * **脆弱性** をクリックすると、重大度レベル、影響を受けるパッケージ、利用可能な修正ガイダンスなど、検出内容の詳細情報にアクセスできます。\n\n\n    ![GitLab セキュリティ - MRでの詳細表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/hplihdlekc11uvpfih1p.png)\n\n\n    ![GitLab セキュリティ - MRでの詳細表示](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/jnxbe7uld8wfeezboifs.png \"MRでのコンテナスキャン脆弱性の詳細\")\n\n\n    この可視性により、開発者とセキュリティチームはコンテナの脆弱性が本番環境に到達する前に発見・対処できるようになり、セキュリティがコードレビュープロセスに統合されます。\n\n\n    #### 脆弱性レポートでの脆弱性の確認\n\n\n    マージリクエストのレビューに加え、GitLab はプロジェクト内のすべてのコンテナスキャン結果を一元的に確認できる[脆弱性レポート](https://docs.gitlab.com/ja-jp/user/application_security/vulnerability_report/)を提供しており、セキュリティチームに包括的な可視性をもたらします。\n\n\n    ![コンテナスキャンでフィルタリングされた脆弱性レポート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547524/gagau279fzfgjpnvipm5.png \"コンテナスキャンでフィルタリングされた脆弱性レポート\")\n\n\n    * プロジェクトのサイドバーで **セキュリティとコンプライアンス > 脆弱性レポート** に移動してレポートにアクセスします。\n\n    * ここでは、ブランチ全体で検出されたすべてのコンテナ脆弱性が集約されて表示され、重大度、ステータス、スキャナーの種類、特定のコンテナイメージでフィルタリングする強力なオプションが利用できます。\n\n    * 脆弱性をクリックすると、脆弱性ページにアクセスできます。\n\n\n    ![脆弱性ページ - 1番目のビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547520/e1woxupyoajhrpzrlylj.png)\n\n\n    ![脆弱性ページ - 2番目のビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547521/idzcftcgjc8eryixnbjn.png)\n\n\n    ![脆弱性ページ - 3番目のビュー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547522/mbbwbbprtf9anqqola10.png \"コンテナスキャン脆弱性の詳細\")\n\n\n    [脆弱性の詳細](https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/)では、影響を受けるコンテナイメージとレイヤーが正確に示されるため、脆弱性の発生源を容易に追跡できます。脆弱性をチームメンバーに割り当て、ステータスを変更（検出済み、確認済み、解決済み、却下済み）し、コラボレーションのためのコメントを追加し、修正作業の追跡のために関連するイシューをリンクすることができます。\n\n\n    このワークフローにより、脆弱性管理がスプレッドシートによる管理から開発プロセスの一部へと変わり、コンテナセキュリティの検出結果が体系的に追跡・優先順位付け・解決されるようになります。\n\n\n    #### 依存関係リストの確認\n\n\n    GitLab の[依存関係リスト](https://docs.gitlab.com/ja-jp/user/application_security/dependency_list/)は、コンテナイメージ内のすべてのコンポーネントをカタログ化した包括的なソフトウェア部品表（SBOM）を提供し、ソフトウェアサプライチェーンの完全な透明性をもたらします。\n\n\n    * **セキュリティとコンプライアンス > 依存関係リスト** に移動すると、プロジェクト全体でコンテナスキャンが検出したすべてのパッケージ、ライブラリ、依存関係のインベントリにアクセスできます。\n\n    * このビューは、ベースOSパッケージからアプリケーションレベルの依存関係まで、コンテナ内で実際に稼働しているものを把握するために非常に役立ちます。\n\n\n    ![GitLab 依存関係リスト](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/vjg6dk3nhajqamplroji.png \"GitLab 依存関係リスト（SBOM）\")\n\n\n    パッケージマネージャー、ライセンスの種類、または脆弱性のステータスでリストをフィルタリングすることで、セキュリティリスクやコンプライアンス上の問題をもたらすコンポーネントを素早く特定できます。各依存関係エントリには関連する脆弱性が表示されるため、単独の検出結果としてではなく、実際のソフトウェアコンポーネントのコンテキストでセキュリティの問題を把握できます。\n\n\n    ### 2. レジストリ向けコンテナスキャン\n\n\n    * 機能：`latest` タグで GitLab コンテナレジストリにプッシュされたイメージを自動的にスキャンします。\n\n    * 最適な用途：手動のパイプラインを実行することなく、レジストリイメージの継続的なモニタリングを実施\n\n    * 利用可能なプラン：Ultimate のみ\n\n    * [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/#container-scanning-for-registry)\n\n\n    `latest` タグが付いたコンテナイメージをプッシュすると、GitLab のセキュリティポリシーボットがデフォルトブランチに対してスキャンを自動的にトリガーします。パイプラインベースのスキャンとは異なり、このアプローチは継続的脆弱性スキャンと連携して、新たに公開されたアドバイザリーを監視します。\n\n\n    #### レジストリ向けコンテナスキャンを有効にする方法\n\n\n    1. **Secure > セキュリティ設定** に移動します。\n\n    2. **レジストリ向けコンテナスキャン** セクションまでスクロールします。\n\n    3. 機能をオンに切り替えます。\n\n\n    ![レジストリ向けコンテナスキャン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547512/vntrlhtmsh1ecnwni5ji.png \"レジストリ向けコンテナスキャンの切り替えスイッチ\")\n\n\n    #### 前提条件\n\n\n    * プロジェクトのメンテナーロール以上\n\n    * プロジェクトが空でないこと（デフォルトブランチに少なくとも1つのコミットが必要）\n\n    * コンテナレジストリの通知が設定済みであること\n\n    * パッケージメタデータデータベースが設定済みであること（GitLab.com ではデフォルトで有効）\n\n\n    脆弱性は脆弱性レポートの **コンテナレジストリの脆弱性** タブに表示されます。\n\n\n    ### 3. マルチコンテナスキャン\n\n\n    * 機能：単一のパイプライン内で複数のコンテナイメージを並行してスキャンします。\n\n    * 最適な用途：マイクロサービスアーキテクチャや複数のコンテナイメージを持つプロジェクト\n\n    * 利用可能なプラン：Free、Premium、Ultimate（現在ベータ版）\n\n    * [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/multi_container_scanning/)\n\n\n    マルチコンテナスキャンは動的な子パイプラインを使用してスキャンを並行実行するため、複数のイメージをスキャンする際のパイプライン全体の実行時間を大幅に短縮できます。\n\n\n    #### マルチコンテナスキャンを有効にする方法\n\n\n    1. リポジトリのルートに `.gitlab-multi-image.yml` ファイルを作成します。\n\n\n    ```yaml\n\n    scanTargets:\n      - name: alpine\n        tag: \"3.19\"\n      - name: python\n        tag: \"3.9-slim\"\n      - name: nginx\n        tag: \"1.25\"\n    ```\n\n\n    2. `.gitlab-ci.yml` にテンプレートを追加します。\n\n\n    ```yaml\n\n    include:\n      - template: Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml\n    ```\n\n\n    #### 詳細設定\n\n\n    **プライベートレジストリからイメージをスキャンする：**\n\n\n    ```yaml\n\n    auths:\n      registry.gitlab.com:\n        username: ${CI_REGISTRY_USER}\n        password: ${CI_REGISTRY_PASSWORD}\n\n    scanTargets:\n      - name: registry.gitlab.com/private/image\n        tag: latest\n    ```\n\n\n    **ライセンス情報を含める：**\n\n\n    ```yaml\n\n    includeLicenses: true\n\n\n    scanTargets:\n      - name: postgres\n        tag: \"15-alpine\"\n    ```\n\n\n    ### 4. 継続的脆弱性スキャン\n\n\n    * 機能：パイプラインを実行することなく、新しいセキュリティアドバイザリーが公開された際に自動的に脆弱性を作成します。\n\n    * 最適な用途：デプロイ間のプロアクティブなセキュリティモニタリング\n\n    * 利用可能なプラン：Ultimate のみ\n\n    * [ドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/continuous_vulnerability_scanning/)\n\n\n    従来のスキャンは、スキャン実行時の脆弱性しか検出できません。しかし、昨日スキャンしたパッケージに対して、明日新しい CVE が公開された場合はどうなるでしょうか。継続的脆弱性スキャンは、GitLab アドバイザリーデータベースを監視し、新しいアドバイザリーがコンポーネントに影響を与える際に自動的に脆弱性レコードを作成することでこの課題を解決します。\n\n\n    #### 仕組み\n\n\n    1. コンテナスキャンまたは依存関係スキャンジョブが CycloneDX SBOM を生成します。\n\n    2. GitLab はこの SBOM からプロジェクトのコンポーネントを登録します。\n\n    3. 新しいアドバイザリーが公開されると、GitLab はコンポーネントが影響を受けるかどうかを確認します。\n\n    4. 脆弱性レポートに脆弱性が自動的に作成されます。\n\n\n    #### 重要な考慮事項\n\n\n    * スキャンは CI パイプラインではなく、バックグラウンドジョブ（Sidekiq）経由で実行されます。\n\n    * 新しいコンポーネント検出には、過去14日以内に公開されたアドバイザリーのみが対象となります。\n\n    * 脆弱性では「GitLab SBoM Vulnerability Scanner」がスキャナー名として使用されます。\n\n    * 脆弱性を解決済みとしてマークするには、引き続きパイプラインベースのスキャンを実行する必要があります。\n\n\n    ### 5. 運用コンテナスキャン\n\n\n    * 機能：スケジュールされた間隔で Kubernetes クラスター内の稼働中のコンテナをスキャンします。\n\n    * 最適な用途：デプロイ後のセキュリティモニタリングとランタイム脆弱性の検出\n\n    * 利用可能なプラン：Ultimate のみ\n\n    * [ドキュメント](https://docs.gitlab.com/ja-jp/user/clusters/agent/vulnerabilities/)\n\n\n    運用コンテナスキャンは、ビルド時のセキュリティとランタイムセキュリティの間のギャップを埋めます。GitLab Agent for Kubernetes を使用して、クラスター内で実際に稼働しているコンテナをスキャンし、デプロイ後に発生する脆弱性を検出します。\n\n\n    #### 運用コンテナスキャンを有効にする方法\n\n\n    [GitLab Kubernetes Agent](https://docs.gitlab.com/ja-jp/user/clusters/agent/install/) を使用している場合、エージェント設定ファイルに以下を追加できます。\n\n\n    ```yaml\n\n    container_scanning:\n      cadence: '0 0 * * *'  # 毎日深夜0時\n      vulnerability_report:\n        namespaces:\n          include:\n            - production\n            - staging\n    ```\n\n\n    また、GitLab Kubernetes Agent によるスケジュールスキャンを強制する[スキャン実行ポリシー](https://docs.gitlab.com/ja-jp/user/clusters/agent/vulnerabilities/#enable-via-scan-execution-policies)を作成することもできます。\n\n\n    ![スキャン実行ポリシー - 運用コンテナスキャン](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547515/gsgvjcq4sas4dfc8ciqk.png \"運用コンテナスキャンのスキャン実行ポリシー条件\")\n\n\n    #### 結果の確認\n\n\n    * **運用 > Kubernetes クラスター** に移動します。\n\n    * **エージェント** タブを選択し、エージェントを選択します。\n\n    * **セキュリティ** タブを選択してクラスターの脆弱性を確認します。\n\n    * 結果は **脆弱性レポート** の **運用上の脆弱性** タブにも表示されます。\n\n\n    ## GitLab セキュリティポリシーによるセキュリティ態勢の強化\n\n\n    GitLab セキュリティポリシーを使用すると、自動化されたポリシー駆動型のコントロールを通じて、コンテナワークフロー全体で一貫したセキュリティ標準を適用できます。これらのポリシーは、要件を開発パイプラインに直接組み込むことでセキュリティをシフトレフトし、コードが本番環境に到達する前に脆弱性を検出・対処できるようにします。\n\n\n    #### スキャン実行ポリシーとパイプラインポリシー\n\n\n    [スキャン実行ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/scan_execution_policies/)は、プロジェクト全体でコンテナスキャンがいつ・どのように実行されるかを自動化します。すべてのマージリクエストでコンテナスキャンをトリガーし、メインブランチの定期的なスキャンをスケジュールするポリシーなどを定義できます。これらのポリシーにより、各プロジェクトの CI/CD パイプラインで手動でスキャンを設定することなく、包括的なカバレッジが確保されます。\n\n\n    使用するスキャナーのバージョンを指定し、スキャンパラメーターを一元的に設定することで、新しいコンテナセキュリティの脅威に対応しながら組織全体の一貫性を維持できます。\n\n\n    ![スキャン実行ポリシーの設定](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/z36dntxslqem9udrynvx.png \"スキャン実行ポリシーの設定\")\n\n\n    [パイプライン実行ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/pipeline_execution_policies/)は、コンプライアンス要件に基づいてパイプラインにカスタムジョブを注入（または上書き）するための柔軟なコントロールを提供します。\n\n\n    これらのポリシーを使用して、コンテナスキャンジョブをパイプラインに自動的に注入したり、コンテナの脆弱性がリスク許容度を超えた場合にビルドを失敗させたり、特定のブランチやタグに対して追加のセキュリティチェックをトリガーしたり、本番環境向けコンテナイメージのコンプライアンス要件を適用したりすることができます。パイプライン実行ポリシーは自動化されたガードレールとして機能し、手動操作なしですべてのコンテナデプロイメントにセキュリティ標準が一貫して適用されるようにします。\n\n\n    ![パイプライン実行ポリシー](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/ddhhugzcr2swptgodof2.png \"パイプライン実行ポリシーのアクション\")\n\n\n    #### マージリクエスト承認ポリシー\n\n\n    [マージリクエスト承認ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/merge_request_approval_policies/)は、コンテナの脆弱性を含むマージリクエストを指定された承認者がレビューし、承認することを要求することでセキュリティゲートを適用します。\n\n\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\n    | --------- | ----------- | ------------------------ |\n\n    | パイプラインベース | すべてのビルド時    | シフトレフトセキュリティ、脆弱なビルドをブロック |\n\n    | レジストリスキャン | 継続的なモニタリング  | 保存されたイメージの新しい CVE を検出    |\n\n    | マルチコンテナ   | マイクロサービス    | 並行スキャン、パイプラインの高速化        |\n\n    | 継続的脆弱性    | デプロイ間       | プロアクティブなアドバイザリーモニタリング    |\n\n    | 運用        | 本番環境のモニタリング | ランタイム脆弱性の検出              |\n\n\n    包括的なセキュリティのためには、複数のアプローチを組み合わせることをお勧めします。開発中の問題を検出するためのパイプラインベースのスキャン、継続的なモニタリングのためのレジストリ向けコンテナスキャン、そして本番環境の可視性のための運用スキャンを組み合わせてご活用ください。\n\n\n    ## 今すぐ始める\n\n\n    コンテナセキュリティへの最短ルートは、パイプラインベースのスキャンを有効にすることです。\n\n\n    1. プロジェクトの **Secure > セキュリティ設定** に移動します。\n\n    2. コンテナスキャンの **マージリクエストで設定** をクリックします。\n\n    3. 作成されたマージリクエストをマージします。\n\n    4. 次のパイプラインに脆弱性スキャンが含まれるようになります。\n\n\n    その後、セキュリティ要件と GitLab のプランに応じて、追加のスキャンの種類を段階的に導入してください。\n\n\n    コンテナセキュリティは一度実施すれば完了するものではなく、継続的なプロセスです。\n\n    GitLab の包括的なコンテナスキャン機能を活用することで、ビルドからランタイムまでコンテナライフサイクルのあらゆる段階で脆弱性を検出できます。\n\n\n    > GitLab がセキュリティ態勢の強化にどのように役立つかについての詳細は、[GitLab セキュリティ & ガバナンス ソリューションページ](https://about.gitlab.com/solutions/application-security-testing/)をご覧ください。\n  authors:\n    - Fernando Diaz\n  updatedDate: 2026-03-09\n  date: 2026-03-05\n  title: GitLab コンテナスキャン完全ガイド：SBOM生成から運用監視まで5つのスキャン手法\n  tags:\n    - security\n    - tutorial\n  description: GitLab のさまざまなコンテナスキャン方法を詳しく解説し、コンテナライフサイクルの各段階でセキュリティを確保する方法をご紹介します。\n  category: security\nconfig:\n  slug: complete-guide-to-gitlab-container-scanning\n  featured: true\n  template: BlogPost\n",{"config":30,"title":5,"description":23,"ogTitle":5},{"noIndex":31},false,"ja-jp/blog/complete-guide-to-gitlab-container-scanning",[11,22],[11,22],"y7_jhJCMul0Un2qekSrT-2qGaKjCDpl40rQYeS383Fk",{"data":37},{"logo":38,"freeTrial":43,"sales":48,"login":53,"items":58,"search":367,"minimal":400,"duo":417,"switchNav":426,"pricingDeployment":437},{"config":39},{"href":40,"dataGaName":41,"dataGaLocation":42},"/ja-jp/","gitlab logo","header",{"text":44,"config":45},"無料トライアルを開始",{"href":46,"dataGaName":47,"dataGaLocation":42},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":49,"config":50},"お問い合わせ",{"href":51,"dataGaName":52,"dataGaLocation":42},"/ja-jp/sales/","sales",{"text":54,"config":55},"サインイン",{"href":56,"dataGaName":57,"dataGaLocation":42},"https://gitlab.com/users/sign_in/","sign in",[59,86,183,188,289,349],{"text":60,"config":61,"cards":63},"プラットフォーム",{"dataNavLevelOne":62},"platform",[64,70,78],{"title":60,"description":65,"link":66},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":67,"config":68},"プラットフォームを探索",{"href":69,"dataGaName":62,"dataGaLocation":42},"/ja-jp/platform/",{"title":71,"description":72,"link":73},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":74,"config":75},"GitLab Duoのご紹介",{"href":76,"dataGaName":77,"dataGaLocation":42},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":79,"description":80,"link":81},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":82,"config":83},"詳細はこちら",{"href":84,"dataGaName":85,"dataGaLocation":42},"/ja-jp/why-gitlab/","why gitlab",{"text":87,"left":14,"config":88,"link":90,"lists":94,"footer":165},"製品",{"dataNavLevelOne":89},"solutions",{"text":91,"config":92},"すべてのソリューションを表示",{"href":93,"dataGaName":89,"dataGaLocation":42},"/ja-jp/solutions/",[95,120,143],{"title":96,"description":97,"link":98,"items":103},"自動化","CI/CDと自動化でデプロイを加速",{"config":99},{"icon":100,"href":101,"dataGaName":102,"dataGaLocation":42},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[104,108,111,116],{"text":105,"config":106},"CI/CD",{"href":107,"dataGaLocation":42,"dataGaName":105},"/ja-jp/solutions/continuous-integration/",{"text":71,"config":109},{"href":76,"dataGaLocation":42,"dataGaName":110},"gitlab duo agent platform - product menu",{"text":112,"config":113},"ソースコード管理",{"href":114,"dataGaLocation":42,"dataGaName":115},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":117,"config":118},"自動化されたソフトウェアデリバリー",{"href":101,"dataGaLocation":42,"dataGaName":119},"Automated software delivery",{"title":121,"description":122,"link":123,"items":128},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":124},{"href":125,"dataGaName":126,"dataGaLocation":42,"icon":127},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[129,133,138],{"text":130,"config":131},"アプリケーションセキュリティテスト",{"href":125,"dataGaName":132,"dataGaLocation":42},"Application security testing",{"text":134,"config":135},"ソフトウェアサプライチェーンの安全性",{"href":136,"dataGaLocation":42,"dataGaName":137},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":139,"config":140},"ソフトウェアコンプライアンス",{"href":141,"dataGaName":142,"dataGaLocation":42},"/ja-jp/solutions/software-compliance/","software compliance",{"title":144,"link":145,"items":150},"測定",{"config":146},{"icon":147,"href":148,"dataGaName":149,"dataGaLocation":42},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[151,155,160],{"text":152,"config":153},"可視性と測定",{"href":148,"dataGaLocation":42,"dataGaName":154},"Visibility and Measurement",{"text":156,"config":157},"バリューストリーム管理",{"href":158,"dataGaLocation":42,"dataGaName":159},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":161,"config":162},"分析とインサイト",{"href":163,"dataGaLocation":42,"dataGaName":164},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":166,"items":167},"GitLabが活躍する場所",[168,173,178],{"text":169,"config":170},"大企業",{"href":171,"dataGaLocation":42,"dataGaName":172},"/ja-jp/enterprise/","enterprise",{"text":174,"config":175},"スモールビジネス",{"href":176,"dataGaLocation":42,"dataGaName":177},"/ja-jp/small-business/","small business",{"text":179,"config":180},"公共部門",{"href":181,"dataGaLocation":42,"dataGaName":182},"/ja-jp/solutions/public-sector/","public sector",{"text":184,"config":185},"価格",{"href":186,"dataGaName":187,"dataGaLocation":42,"dataNavLevelOne":187},"/ja-jp/pricing/","pricing",{"text":189,"config":190,"link":192,"lists":196,"feature":276},"リソース",{"dataNavLevelOne":191},"resources",{"text":193,"config":194},"すべてのリソースを表示",{"href":195,"dataGaName":191,"dataGaLocation":42},"/ja-jp/resources/",[197,230,248],{"title":198,"items":199},"はじめに",[200,205,210,215,220,225],{"text":201,"config":202},"インストール",{"href":203,"dataGaName":204,"dataGaLocation":42},"/ja-jp/install/","install",{"text":206,"config":207},"クイックスタートガイド",{"href":208,"dataGaName":209,"dataGaLocation":42},"/ja-jp/get-started/","quick setup checklists",{"text":211,"config":212},"学ぶ",{"href":213,"dataGaLocation":42,"dataGaName":214},"https://university.gitlab.com/","learn",{"text":216,"config":217},"製品ドキュメント",{"href":218,"dataGaName":219,"dataGaLocation":42},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":221,"config":222},"ベストプラクティスビデオ",{"href":223,"dataGaName":224,"dataGaLocation":42},"/ja-jp/getting-started-videos/","best practice videos",{"text":226,"config":227},"インテグレーション",{"href":228,"dataGaName":229,"dataGaLocation":42},"/ja-jp/integrations/","integrations",{"title":231,"items":232},"検索する",[233,238,243],{"text":234,"config":235},"お客様成功事例",{"href":236,"dataGaName":237,"dataGaLocation":42},"/ja-jp/customers/","customer success stories",{"text":239,"config":240},"ブログ",{"href":241,"dataGaName":242,"dataGaLocation":42},"/ja-jp/blog/","blog",{"text":244,"config":245},"リモート",{"href":246,"dataGaName":247,"dataGaLocation":42},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":249,"items":250},"つなげる",[251,256,261,266,271],{"text":252,"config":253},"GitLabサービス",{"href":254,"dataGaName":255,"dataGaLocation":42},"/ja-jp/services/","services",{"text":257,"config":258},"コミュニティ",{"href":259,"dataGaName":260,"dataGaLocation":42},"/community/","community",{"text":262,"config":263},"フォーラム",{"href":264,"dataGaName":265,"dataGaLocation":42},"https://forum.gitlab.com/","forum",{"text":267,"config":268},"イベント",{"href":269,"dataGaName":270,"dataGaLocation":42},"/events/","events",{"text":272,"config":273},"パートナー",{"href":274,"dataGaName":275,"dataGaLocation":42},"/ja-jp/partners/","partners",{"background":277,"textColor":278,"text":279,"image":280,"link":284},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":281,"config":282},"ソースプロモカード",{"src":283},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":285,"config":286},"最新情報を読む",{"href":287,"dataGaName":288,"dataGaLocation":42},"/ja-jp/the-source/","the source",{"text":290,"config":291,"lists":293},"会社情報",{"dataNavLevelOne":292},"company",[294],{"items":295},[296,301,307,309,314,319,324,329,334,339,344],{"text":297,"config":298},"GitLabについて",{"href":299,"dataGaName":300,"dataGaLocation":42},"/ja-jp/company/","about",{"text":302,"config":303,"footerGa":306},"採用情報",{"href":304,"dataGaName":305,"dataGaLocation":42},"/jobs/","jobs",{"dataGaName":305},{"text":267,"config":308},{"href":269,"dataGaName":270,"dataGaLocation":42},{"text":310,"config":311},"経営陣",{"href":312,"dataGaName":313,"dataGaLocation":42},"/company/team/e-group/","leadership",{"text":315,"config":316},"チーム",{"href":317,"dataGaName":318,"dataGaLocation":42},"/company/team/","team",{"text":320,"config":321},"ハンドブック",{"href":322,"dataGaName":323,"dataGaLocation":42},"https://handbook.gitlab.com/","handbook",{"text":325,"config":326},"投資家向け情報",{"href":327,"dataGaName":328,"dataGaLocation":42},"https://ir.gitlab.com/","investor relations",{"text":330,"config":331},"トラストセンター",{"href":332,"dataGaName":333,"dataGaLocation":42},"/ja-jp/security/","trust center",{"text":335,"config":336},"AI Transparency Center",{"href":337,"dataGaName":338,"dataGaLocation":42},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":340,"config":341},"ニュースレター",{"href":342,"dataGaName":343,"dataGaLocation":42},"/company/contact/#contact-forms","newsletter",{"text":345,"config":346},"プレス",{"href":347,"dataGaName":348,"dataGaLocation":42},"/press/","press",{"text":49,"config":350,"lists":351},{"dataNavLevelOne":292},[352],{"items":353},[354,357,362],{"text":49,"config":355},{"href":51,"dataGaName":356,"dataGaLocation":42},"talk to sales",{"text":358,"config":359},"サポートを受ける",{"href":360,"dataGaName":361,"dataGaLocation":42},"https://support.gitlab.com","support portal",{"text":363,"config":364},"カスタマーポータル",{"href":365,"dataGaName":366,"dataGaLocation":42},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":368,"login":369,"suggestions":376},"閉じる",{"text":370,"link":371},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":372,"config":373},"GitLab.com",{"href":56,"dataGaName":374,"dataGaLocation":375},"search login","search",{"text":377,"default":378},"提案",[379,381,386,388,392,396],{"text":71,"config":380},{"href":76,"dataGaName":71,"dataGaLocation":375},{"text":382,"config":383},"コード提案（AI）",{"href":384,"dataGaName":385,"dataGaLocation":375},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":105,"config":387},{"href":107,"dataGaName":105,"dataGaLocation":375},{"text":389,"config":390},"GitLab on AWS",{"href":391,"dataGaName":389,"dataGaLocation":375},"/ja-jp/partners/technology-partners/aws/",{"text":393,"config":394},"GitLab on Google Cloud",{"href":395,"dataGaName":393,"dataGaLocation":375},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":397,"config":398},"GitLabを選ぶ理由",{"href":84,"dataGaName":399,"dataGaLocation":375},"Why GitLab?",{"freeTrial":401,"mobileIcon":405,"desktopIcon":410,"secondaryButton":413},{"text":44,"config":402},{"href":403,"dataGaName":47,"dataGaLocation":404},"https://gitlab.com/-/trials/new/","nav",{"altText":406,"config":407},"GitLabアイコン",{"src":408,"dataGaName":409,"dataGaLocation":404},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":406,"config":411},{"src":412,"dataGaName":409,"dataGaLocation":404},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":198,"config":414},{"href":415,"dataGaName":416,"dataGaLocation":404},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":418,"mobileIcon":422,"desktopIcon":424},{"text":419,"config":420},"GitLab Duoの詳細について",{"href":76,"dataGaName":421,"dataGaLocation":404},"gitlab duo",{"altText":406,"config":423},{"src":408,"dataGaName":409,"dataGaLocation":404},{"altText":406,"config":425},{"src":412,"dataGaName":409,"dataGaLocation":404},{"button":427,"mobileIcon":432,"desktopIcon":434},{"text":428,"config":429},"/switch",{"href":430,"dataGaName":431,"dataGaLocation":404},"#contact","switch",{"altText":406,"config":433},{"src":408,"dataGaName":409,"dataGaLocation":404},{"altText":406,"config":435},{"src":436,"dataGaName":409,"dataGaLocation":404},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":438,"mobileIcon":443,"desktopIcon":445},{"text":439,"config":440},"料金ページに戻る",{"href":186,"dataGaName":441,"dataGaLocation":404,"icon":442},"back to pricing","GoBack",{"altText":406,"config":444},{"src":408,"dataGaName":409,"dataGaLocation":404},{"altText":406,"config":446},{"src":412,"dataGaName":409,"dataGaLocation":404},{"title":448,"button":449,"config":454},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":450,"config":451},"GitLab Transcendを今すぐ視聴",{"href":452,"dataGaName":453,"dataGaLocation":42},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":455,"icon":456,"disabled":14},"release","AiStar",{"data":458},{"text":459,"source":460,"edit":466,"contribute":471,"config":476,"items":481,"minimal":684},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":461,"config":462},"ページのソースを表示",{"href":463,"dataGaName":464,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":467,"config":468},"このページを編集",{"href":469,"dataGaName":470,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":472,"config":473},"ご協力をお願いします",{"href":474,"dataGaName":475,"dataGaLocation":465},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":477,"facebook":478,"youtube":479,"linkedin":480},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[482,527,580,623,650],{"title":184,"links":483,"subMenu":498},[484,488,493],{"text":485,"config":486},"プランの表示",{"href":186,"dataGaName":487,"dataGaLocation":465},"view plans",{"text":489,"config":490},"Premiumを選ぶ理由",{"href":491,"dataGaName":492,"dataGaLocation":465},"/ja-jp/pricing/premium/","why premium",{"text":494,"config":495},"Ultimateを選ぶ理由",{"href":496,"dataGaName":497,"dataGaLocation":465},"/ja-jp/pricing/ultimate/","why ultimate",[499],{"title":49,"links":500},[501,503,505,507,512,517,522],{"text":49,"config":502},{"href":51,"dataGaName":52,"dataGaLocation":465},{"text":358,"config":504},{"href":360,"dataGaName":361,"dataGaLocation":465},{"text":363,"config":506},{"href":365,"dataGaName":366,"dataGaLocation":465},{"text":508,"config":509},"ステータス",{"href":510,"dataGaName":511,"dataGaLocation":465},"https://status.gitlab.com/","status",{"text":513,"config":514},"利用規約",{"href":515,"dataGaName":516,"dataGaLocation":465},"/terms/","terms of use",{"text":518,"config":519},"プライバシーに関する声明",{"href":520,"dataGaName":521,"dataGaLocation":465},"/ja-jp/privacy/","privacy statement",{"text":523,"config":524},"Cookie 優先設定",{"dataGaName":525,"dataGaLocation":465,"id":526,"isOneTrustButton":14},"cookie preferences","ot-sdk-btn",{"title":87,"links":528,"subMenu":537},[529,533],{"text":530,"config":531},"DevSecOpsプラットフォーム",{"href":69,"dataGaName":532,"dataGaLocation":465},"devsecops platform",{"text":534,"config":535},"AI支援開発",{"href":76,"dataGaName":536,"dataGaLocation":465},"ai-assisted development",[538],{"title":539,"links":540},"トピック",[541,545,550,555,560,565,570,575],{"text":105,"config":542},{"href":543,"dataGaName":544,"dataGaLocation":465},"/ja-jp/topics/ci-cd/","cicd",{"text":546,"config":547},"GitOps",{"href":548,"dataGaName":549,"dataGaLocation":465},"/ja-jp/topics/gitops/","gitops",{"text":551,"config":552},"DevOps",{"href":553,"dataGaName":554,"dataGaLocation":465},"/ja-jp/topics/devops/","devops",{"text":556,"config":557},"バージョン管理",{"href":558,"dataGaName":559,"dataGaLocation":465},"/ja-jp/topics/version-control/","version control",{"text":561,"config":562},"DevSecOps",{"href":563,"dataGaName":564,"dataGaLocation":465},"/ja-jp/topics/devsecops/","devsecops",{"text":566,"config":567},"クラウドネイティブ",{"href":568,"dataGaName":569,"dataGaLocation":465},"/ja-jp/topics/cloud-native/","cloud native",{"text":571,"config":572},"コーディングのためのAI",{"href":573,"dataGaName":574,"dataGaLocation":465},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":576,"config":577},"エージェント型AI",{"href":578,"dataGaName":579,"dataGaLocation":465},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":581,"links":582},"ソリューション",[583,586,588,593,597,600,603,606,608,610,613,618],{"text":130,"config":584},{"href":125,"dataGaName":585,"dataGaLocation":465},"Application Security Testing",{"text":117,"config":587},{"href":101,"dataGaName":102,"dataGaLocation":465},{"text":589,"config":590},"アジャイル開発",{"href":591,"dataGaName":592,"dataGaLocation":465},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":594,"config":595},"SCM",{"href":114,"dataGaName":596,"dataGaLocation":465},"source code management",{"text":105,"config":598},{"href":107,"dataGaName":599,"dataGaLocation":465},"continuous integration & delivery",{"text":156,"config":601},{"href":158,"dataGaName":602,"dataGaLocation":465},"value stream management",{"text":546,"config":604},{"href":605,"dataGaName":549,"dataGaLocation":465},"/ja-jp/solutions/gitops/",{"text":169,"config":607},{"href":171,"dataGaName":172,"dataGaLocation":465},{"text":174,"config":609},{"href":176,"dataGaName":177,"dataGaLocation":465},{"text":611,"config":612},"公共機関",{"href":181,"dataGaName":182,"dataGaLocation":465},{"text":614,"config":615},"教育",{"href":616,"dataGaName":617,"dataGaLocation":465},"/ja-jp/solutions/education/","education",{"text":619,"config":620},"金融サービス",{"href":621,"dataGaName":622,"dataGaLocation":465},"/ja-jp/solutions/finance/","financial services",{"title":189,"links":624},[625,627,629,631,634,636,638,640,642,644,646,648],{"text":201,"config":626},{"href":203,"dataGaName":204,"dataGaLocation":465},{"text":206,"config":628},{"href":208,"dataGaName":209,"dataGaLocation":465},{"text":211,"config":630},{"href":213,"dataGaName":214,"dataGaLocation":465},{"text":216,"config":632},{"href":218,"dataGaName":633,"dataGaLocation":465},"docs",{"text":239,"config":635},{"href":241,"dataGaName":242,"dataGaLocation":465},{"text":234,"config":637},{"href":236,"dataGaName":237,"dataGaLocation":465},{"text":244,"config":639},{"href":246,"dataGaName":247,"dataGaLocation":465},{"text":252,"config":641},{"href":254,"dataGaName":255,"dataGaLocation":465},{"text":257,"config":643},{"href":259,"dataGaName":260,"dataGaLocation":465},{"text":262,"config":645},{"href":264,"dataGaName":265,"dataGaLocation":465},{"text":267,"config":647},{"href":269,"dataGaName":270,"dataGaLocation":465},{"text":272,"config":649},{"href":274,"dataGaName":275,"dataGaLocation":465},{"title":290,"links":651},[652,654,656,658,660,662,664,668,673,675,677,679],{"text":297,"config":653},{"href":299,"dataGaName":292,"dataGaLocation":465},{"text":302,"config":655},{"href":304,"dataGaName":305,"dataGaLocation":465},{"text":310,"config":657},{"href":312,"dataGaName":313,"dataGaLocation":465},{"text":315,"config":659},{"href":317,"dataGaName":318,"dataGaLocation":465},{"text":320,"config":661},{"href":322,"dataGaName":323,"dataGaLocation":465},{"text":325,"config":663},{"href":327,"dataGaName":328,"dataGaLocation":465},{"text":665,"config":666},"Sustainability",{"href":667,"dataGaName":665,"dataGaLocation":465},"/sustainability/",{"text":669,"config":670},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":671,"dataGaName":672,"dataGaLocation":465},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":330,"config":674},{"href":332,"dataGaName":333,"dataGaLocation":465},{"text":340,"config":676},{"href":342,"dataGaName":343,"dataGaLocation":465},{"text":345,"config":678},{"href":347,"dataGaName":348,"dataGaLocation":465},{"text":680,"config":681},"現代奴隷制の透明性に関する声明",{"href":682,"dataGaName":683,"dataGaLocation":465},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":685},[686,688,691],{"text":513,"config":687},{"href":515,"dataGaName":516,"dataGaLocation":465},{"text":689,"config":690},"Cookieの設定",{"dataGaName":525,"dataGaLocation":465,"id":526,"isOneTrustButton":14},{"text":518,"config":692},{"href":520,"dataGaName":521,"dataGaLocation":465},[694],{"id":695,"title":9,"body":25,"config":696,"content":698,"description":25,"extension":24,"meta":702,"navigation":14,"path":703,"seo":704,"stem":705,"__hash__":706},"blogAuthors/en-us/blog/authors/fernando-diaz.yml",{"template":697},"BlogAuthor",{"name":9,"config":699},{"headshot":700,"ctfId":701},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659556/Blog/Author%20Headshots/fern_diaz.png","fjdiaz",{},"/en-us/blog/authors/fernando-diaz",{},"en-us/blog/authors/fernando-diaz","lxRJIOydP4_yzYZvsPcuQevP9AYAKREF7i8QmmdnOWc",[708,723,735],{"content":709,"config":721},{"heroImage":710,"body":711,"authors":712,"updatedDate":714,"date":715,"title":716,"tags":717,"description":720,"category":11},"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)してください。",[713],"Alisa Ho","2026-03-25","2026-03-19","GitLab 18.10がAIネイティブなトリアージと修正機能を導入",[718,11,719],"product","features","ノイズを排除して実際の脆弱性を特定し、修正案につなげるGitLab Duo Agent Platformの機能をご紹介します。",{"featured":31,"template":15,"slug":722},"gitlab-18-10-brings-ai-native-triage-and-remediation",{"content":724,"config":733},{"title":725,"description":726,"authors":727,"heroImage":729,"date":730,"body":731,"category":11,"tags":732},"GitLab.comのセキュリティ強化：多要素認証の必須化","Secure by Designへのコミットメントの一環として、GitLabが多要素認証（MFA）を必須化する方法と、それがユーザーに与える影響について解説します。",[728],"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具体的なタイムラインとその他のリソースについては、ロールアウト日までに段階的に共有される予定です。この重要な変更についてご覧いただき、ありがとうございます。",[11,718],{"featured":31,"template":15,"slug":734},"strengthening-gitlab-com-security-mandatory-multi-factor-authentication",{"content":736,"config":746},{"heroImage":737,"body":738,"authors":739,"updatedDate":741,"date":742,"title":743,"tags":744,"description":745,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1759320418/xjmqcozxzt4frx0hori3.png","[パイプライン変数](https://docs.gitlab.com/ja-jp/ci/variables/#use-pipeline-variables)は、GitLab\nCI/CDパイプラインを実行時にカスタマイズする便利な方法として長く活用されてきました。しかし、CI/CDセキュリティのベストプラクティスが進化するにつれ、パイプラインのカスタマイズに関してより強力な制御が必要であることが明らかになりました。制限のないパイプライン変数では、パイプライントリガー権限を持つユーザーが、検証や型のチェックなしに値を上書きできてしまいます。\n\n\n\nセキュリティ上の考慮事項に加えて、パイプライン変数には適切なドキュメントと明示的な宣言が欠けているため、どのような入力が想定され、パイプライン全体でどのように使用されるかを理解することが困難です。これにより、メンテナンスの課題が生じ、[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)プロセスに対する適切なガバナンスの確立が難しくなります。\n\n\n\n## パイプライン入力の導入\n\n\n\nパイプライン変数に依存する代わりに、GitLabの[パイプライン入力](https://docs.gitlab.com/ja-jp/ci/inputs/#for-a-pipeline)機能の使用を強く推奨します。パイプライン入力には次の利点があります：\n\n\n\n* **明示的な宣言**: 入力は`.gitlab-ci.yml`で明示的に宣言する必要があり、自己文書化されます。\n\n\n* **型安全性**: 異なる入力型(文字列、ブール値、数値、配列)をサポートします。\n\n\n* **組み込みの検証**: 入力値の自動検証が行われます。\n\n\n* **セキュリティの向上**: 変数インジェクション攻撃のリスクがなく、宣言された入力のみが外部から渡されます。\n\n\n\n### 基本的な例\n\n\n\n```yaml\n\nspec:\n  inputs:\n    deployment_env:\n      description: \"ターゲットデプロイメント環境\"\n      type: string\n      options: [\"staging\", \"production\"]\n      default: \"staging\"\n    enable_tests:\n      description: \"テストスイートを実行\"\n      type: boolean\n      default: true\n\ntest:\n  script:\n    - echo \"テストを実行中\"\n  rules:\n    - if: $[[ inputs.enable_tests ]] == true\n\ndeploy:\n  script:\n    - echo \"$[[ inputs.deployment_env ]]へデプロイ中\"\n```\n\n\n\nCI/CD入力が検証付きで型安全なパラメータ渡しを実現する方法については、この[チュートリアル](https://about.gitlab.com/blog/ci-cd-inputs-secure-and-preferred-method-to-pass-parameters-to-a-pipeline/)をご覧ください。\n\n\n\n## パイプライン変数の制限\n\n\n\nパイプライン入力への移行を効果的に進め、パイプライン変数からの移行を促進するには、[「パイプライン変数が使用できる最小ロール」](https://docs.gitlab.com/ja-jp/ci/variables/#restrict-pipeline-variables)設定を構成する必要があります。この設定により、パイプラインをトリガーする際にどのロールがパイプライン変数を使用できるかを細かく制御できます。\n\n\n\n**プロジェクトレベル:** プロジェクトの **[設定] > [CI/CD] > [変数] > [パイプライン変数が使用できる最小ロール]** の順に移動して、設定を構成します。\n\n\n\n利用可能なオプション:\n\n\n\n* **誰にも許可しない**(`no_one_allowed`) - 推奨される最も安全なオプションです。すべての変数の上書きを防ぎます。\n\n\n* **デベロッパー**(`developer`) - デベロッパー以上のロールが変数を上書きできます。\n\n\n* **メンテナー**(`maintainer`) - メンテナーロール以上が必要です。\n\n\n* **オーナー**(`owner`) - プロジェクトオーナーのみが変数を上書きできます。\n\n\n\n**グループレベル:** グループメンテナーは、**[設定] > [CI/CD] > [変数] > [パイプライン変数を使えるデフォルトロール]**の順に移動して、グループ内のすべての新規プロジェクトに適用される安全なデフォルト値を設定できます。これにより組織全体で一貫したセキュリティポリシーを確保できます。ここでも、デフォルト値として**誰にも許可しない**を使用することを推奨します。これにより、このグループ内の新規プロジェクトは安全なデフォルト設定で作成されます。なお、プロジェクトオーナーは引き続きこの設定を変更できます。\n\n\n\nパイプライン変数が完全に制限されている場合(「誰にも許可しない」の場合)、[事前入力された変数](https://docs.gitlab.com/ja-jp/ci/pipelines/#prefill-variables-in-manual-pipelines)は「新しいパイプラインUI」フォームに表示されません。\n\n\n\n## パイプライン変数から移行する方法\n\n\n\n### ギャップを埋める\n\n\n\n組織内には、パイプラインをトリガーする際に一度も使用したことがないにもかかわらず、パイプライン変数がデフォルトで有効になっているプロジェクトが存在する可能性があります。これらのプロジェクトは、中断のリスクなしにより安全な設定に移行できます。GitLabは、グループ設定を通じて[移行機能を提供](https://docs.gitlab.com/ja-jp/ci/variables/#enable-pipeline-variable-restriction-for-multiple-projects)しています：\n\n\n\n* **[設定] > [CI/CD] > [変数]** の順に移動します。\n\n\n* **パイプライン変数を使用していないプロジェクトで、パイプライン変数を無効にする**で、**マイグレーションの開始**を選択します。\n\n\n\nこの移行は、過去に使用したことがないすべてのプロジェクトのプロジェクト設定を通じて、パイプライン変数を安全に無効にするバックグラウンドジョブです。\n\n\n\n### パイプライン変数を入力に変換\n\n\n\n特定されたパイプライン変数ごとに、対応するパイプライン入力を作成します。\n\n\n\n**変更前(パイプライン変数を使用)**\n\n\n\n```text\n\nvariables:\n  DEPLOY_ENV:\n    description: \"デプロイメント環境\"\n    value: \"staging\"\n  ENABLE_CACHE:\n    description: \"デプロイメントキャッシュを有効化\"\n    value: \"true\"\n  VERSION:\n    description: \"アプリケーションバージョン\"\n    value: \"1.0.0\"\n\ndeploy:\n  script:\n    - echo \"$DEPLOY_ENVへバージョン$VERSIONをデプロイ中\"\n    - |\n      if [ \"$ENABLE_CACHE\" = \"true\" ]; then\n        echo \"キャッシュが有効です\"\n      fi\n```\n\n\n\n**変更後(パイプライン入力を使用)**\n\n\n\n```text\n\nspec:\n  inputs:\n    deploy_env:\n      description: \"デプロイメント環境\"\n      type: string\n      default: \"staging\"\n      options: [\"dev\", \"staging\", \"production\"]\n\n    enable_cache:\n      description: \"デプロイメントキャッシュを有効化\"\n      type: boolean\n      default: true\n    \n    version:\n      description: \"アプリケーションバージョン\"\n      type: string\n      default: \"1.0.0\"\n      regex: '^[0-9]+\\.[0-9]+\\.[0-9]+$'\n\ndeploy:\n  script:\n    - echo \"$[[ inputs.deploy_env ]]へバージョン$[[ inputs.version ]]をデプロイ中\"\n    - |\n      if [ \"$[[ inputs.enable_cache ]]\" = \"true\" ]; then\n        echo \"キャッシュが有効です\"\n      fi\n```\n\n\n\n### トリガージョブの移行\n\n\n\n`trigger`キーワードでトリガージョブを使用している場合は、ジョブレベルの`variables`を定義していないこと、またはトップレベルの`variables`、`extends`、`include`からの変数の継承を無効にしていないことを確認してください。変数が暗黙的にダウンストリームにパイプライン変数として渡される可能性があるためです。ダウンストリームプロジェクトでパイプライン変数が制限されている場合、パイプラインの作成は失敗します。\n\n\n\nパイプライン変数の代わりに、パイプライン入力を使用するようにCI構成を更新することを検討してください。\n\n\n\n```yaml\n\nvariables:\n  FOO: bar\n\ndeploy-staging:\n  inherit:\n    variables: false # そうしないとFOOがダウンストリームにパイプライン変数として送信されます\n  trigger:\n    project: myorg/deployer\n    inputs:\n      deployment_env: staging\n      enable_tests: true\n```\n\n\n\n## まとめ\n\n\n\nパイプライン変数からパイプライン入力への移行は、変数インジェクションからCI/CDインフラを保護するセキュリティ強化であり、同時により優れたドキュメント、型安全性、検証を提供します。これらの制限を実装し、パイプライン入力を採用することで、セキュリティを向上させるだけでなく、パイプラインをよりメンテナンスしやすく、自己文書化され、耐障害性の高いものにすることができます。\n\n\n\n移行には初期の労力が必要ですが、長期的なメリットは移行コストをはるかに上回ります。まず、新規プロジェクトのグループレベルでパイプライン変数を制限ることから始め、次に上記の段階的なアプローチを使用して既存のパイプラインを体系的に移行してください。\n\n\n\nセキュリティの強化は、終わりのない継続的なプロセスです。パイプライン入力は、保護されたブランチ、ジョブトークン許可リスト、コンテナレジストリ保護など、他のGitLabセキュリティ機能を補完し、より安全なCI/CD環境を構築するための重要なステップです。\n\n\n\n> パイプライン入力を始めるには、[GitLab Ultimateの無料トライアルに今すぐ登録](https://about.gitlab.com/ja-jp/free-trial/devsecops/)してください。\n",[740],"Fabio Pitino","2025-11-12","2025-11-04","パイプライン変数からパイプライン入力への移行でセキュリティを強化",[11,561,22,105],"このガイドでは、明示的な宣言、型安全性、検証の実装など、パイプラインのカスタマイズに関するより強力な制御について説明します。",{"featured":14,"template":15,"slug":747},"migrate-from-pipeline-variables-to-pipeline-inputs-for-better-security",{"promotions":749},[750,764,775,786],{"id":751,"categories":752,"header":754,"text":755,"button":756,"image":761},"ai-modernization",[753],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":757,"config":758},"Get your AI maturity score",{"href":759,"dataGaName":760,"dataGaLocation":242},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":762},{"src":763},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":765,"categories":766,"header":767,"text":755,"button":768,"image":772},"devops-modernization",[718,564],"Are you just managing tools or shipping innovation?",{"text":769,"config":770},"Get your DevOps maturity score",{"href":771,"dataGaName":760,"dataGaLocation":242},"/assessments/devops-modernization-assessment/",{"config":773},{"src":774},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":776,"categories":777,"header":778,"text":755,"button":779,"image":783},"security-modernization",[11],"Are you trading speed for security?",{"text":780,"config":781},"Get your security maturity score",{"href":782,"dataGaName":760,"dataGaLocation":242},"/assessments/security-modernization-assessment/",{"config":784},{"src":785},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":787,"paths":788,"header":791,"text":792,"button":793,"image":798},"github-azure-migration",[789,790],"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":794,"config":795},"See how GitLab compares to GitHub",{"href":796,"dataGaName":797,"dataGaLocation":242},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":799},{"src":774},{"header":801,"blurb":802,"button":803,"secondaryButton":807},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":44,"config":804},{"href":805,"dataGaName":47,"dataGaLocation":806},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/ja-jp/","feature",{"text":49,"config":808},{"href":51,"dataGaName":52,"dataGaLocation":806},1777493652757]