<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <id>https://about.gitlab.com/blog</id>
    <title>GitLab</title>
    <updated>2026-04-17T12:48:01.938Z</updated>
    <generator>https://github.com/jpmonette/feed</generator>
    <author>
        <name>The GitLab Team</name>
    </author>
    <link rel="alternate" href="https://about.gitlab.com/blog"/>
    <link rel="self" href="https://about.gitlab.com/ja-jp/atom.xml"/>
    <subtitle>GitLab Blog RSS feed</subtitle>
    <icon>https://about.gitlab.com/favicon.ico</icon>
    <rights>All rights reserved 2026</rights>
    <entry>
        <title type="html"><![CDATA[お客様事例：日立プラントサービス]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/epic-tokyo-2025-hitachi-hps/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/epic-tokyo-2025-hitachi-hps/"/>
        <updated>2026-04-17T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<h2 id="株式会社日立プラントサービスについて">株式会社日立プラントサービスについて</h2><p>株式会社日立プラントサービスでは、産業プラントや水インフラ、ライフサイエンス分野において、お客さまのデータから価値を創出し、デジタルイノベーションを加速するための、日立の先進的なデジタル技術を活用したソリューション・サービス・テクノロジーである「Lumada」を推進しています。</p><h2 id="株式会社日立プラントサービスの挑戦">株式会社日立プラントサービスの挑戦</h2><p>同社では、開発現場において、「人財強化」、「品質向上・維持」、「国内での情報管理」、「開発プロセス標準化」という4つの課題に直面していました。プロジェクトごとに異なるツールが乱立することで教育コストが増大し、セキュリティチェックの属人化による品質のバラつきも懸念されていました。また、生産性向上のカギを握る生成AI活用では、医療データや重要インフラ情報などの機微情報を扱う事業特性上、データを社外や海外へ送信することに強い懸念があり、導入の大きな足かせとなっていました。</p><h2 id="gitlabの活用方法">GitLabの活用方法</h2><p>同社は、これらの課題解決に取り組むため、開発基盤にGitLabを選定。開発の最適化とAI活用、情報管理の徹底という3つのポイントを重視し、担当者個人の生産性向上に加えてプロセス全体を最適化し、さらに機微情報の海外流出を確実に防げる仕組みであることを評価しました。パートナーに選定したグループのITサービス企業である株式会社日立システムズは、統合運用サービスで培ったノウハウをGitLabへと展開し、次世代型の開発基盤を構築。開発現場で利用されていた複数のツールをGitLabへと一本化しました。こうして開発プロセスの標準化を図るとともに、教育コストを低減し、組織全体でスムーズにノウハウを共有できるようになりました。</p><p>中でも、高度なセキュリティ／コンプライアンスを備えながら、先進的なAIを活用できるようにしたアーキテクチャはグループ内外で高く評価されました。新たな開発基盤は、国内リージョンのAWS環境でSelf-Managed版のGitLabを稼働させ、生成AIのClaudeと連携しています。これにより、パブリッククラウドを使ってもデータを国内にとどめ、セキュアな状態で活用できるローカルLLM環境を実現しました。さらに、GitLabのAI機能であるGitLab Duoを採用し、高い機密性のもとでコードレビューの自動化やコード提案、チャット機能による開発支援が可能になりました。CI/CDパイプラインには自動セキュリティスキャンを実装。AIとDevSecOps環境を最大限に活用することで、開発スピードを高めながら脆弱性を早期発見できるようになったのです。</p><p>今後は、AIコーディングを開発ライフサイクル全体へと本格導入し、開発者の負担軽減と組織全体の生産性を大幅に向上させる計画です。大切なのは、単なるツールの導入で終わらせないこと。現場の要望に合わせて環境設計を行い、定着化に向けた勉強会や問い合わせ対応などの運用支援を含め、組織に新しい文化を浸透させながら、開発現場のモダナイズを進めていきたい考えです。</p><p>両社は、この新たな開発基盤の成功をグループ全体へと横展開し、高品質なデジタルサービスを通じて、お客さまとの価値協創をさらに加速させる方針です。</p><p>*本内容は2025年11月当時の情報をもとに制作しております</p><h2 id="️事例pdfを無料でダウンロードする">▶️事例PDFを<a href="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776046067/lnw1a4zv8yl8kyjrqh42.pdf" rel="">無料でダウンロードする</a></h2>]]></content>
        <author>
            <name>GitLab Japan Team</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/gitlab-japan-team/</uri>
        </author>
        <published>2026-04-17T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLab 18.11リリース]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/gitlab-18-11-release/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/gitlab-18-11-release/"/>
        <updated>2026-04-16T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>本ブログは、<a href="https://docs.gitlab.com/releases/18/gitlab-18-11-released/" rel="">GitLab 18.11 release notes</a>の抄訳です。内容に相違がある場合は、原文が優先されます。</p><h1 id="gitlab-1811リリースノート">GitLab 18.11リリースノート</h1><p>2026年4月16日、GitLab 18.11が以下の機能とともにリリースされました。</p><p>また、すべてのコントリビューターの皆さまに感謝申し上げます。今月の注目コントリビューターもご紹介します。</p><h2 id="今月の注目コントリビューターrinku-cさん">今月の注目コントリビューター：Rinku Cさん</h2><p><a href="https://gitlab.com/therealrinku" rel="">Rinku C</a>さんは、2025年9月の参加以降、GitLab全体で80件以上の改善をマージしたレベル4コントリビューターです。</p><p>Developer Relationsチームのシニアフルスタックエンジニア、<a href="https://gitlab.com/aharadon" rel="">Arianna Haradon</a>さんの推薦により、今回の表彰が実現しました。この賞は、長期にわたるRinkuさんの持続的かつ意義あるインパクトを称えるものです。Rinkuさんは、<a href="https://gitlab.com/gitlab-org/gitlab/-/merge_requests/219236" rel="">プロジェクトおよびグループアクセストークンの作成フォームにスコープを必須とする</a>ことでセキュリティに敏感なフローを強化し、<a href="https://gitlab.com/gitlab-org/gitlab/-/merge_requests/217618" rel="">ジョブログのnext/previousナビゲーション</a>、<a href="https://gitlab.com/gitlab-org/gitlab/-/merge_requests/223570" rel="">空の検索を最近の検索から除外する改善</a>、<a href="https://gitlab.com/gitlab-org/gitlab/-/merge_requests/224628" rel="">ファイルツリーの整理</a>など、日常的なGitLab体験を向上させる数多くのアップデートを行いました。これらはすべて、一般的なワークフローをより明確で使いやすくするためのUIの改善です。Rinkuさんは、誰も手を付けないような作業にも積極的に取り組み、コードベースの健全性を保ち、意義ある持続的な価値をもたらしています。コントリビュートに感謝します！</p><hr /><h2 id="主要な機能">主要な機能</h2><h3 id="脆弱性修正がgitlab-duo-agent-platformで一般提供開始">脆弱性修正がGitLab Duo Agent Platformで一般提供開始</h3><ul><li><strong>利用可能プラン：</strong> Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/agentic_vulnerability_resolution/" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/585626" rel="">関連イシュー</a></li></ul><p>エージェント型SASTの脆弱性修正機能が、GitLab 18.11のGitLab Duo Agent Platformで一般提供開始（GA）となりました。SASTスキャンの一環として、SAST誤検知の検出後、または個別のSAST脆弱性に対して手動でトリガーした場合に実行されます。</p><p>エージェント型SAST脆弱性修正の特長：</p><ul><li>検出内容を自律的に分析し、周辺のコードコンテキストを推論します。</li><li>重大度が「重大」および「高」のSAST脆弱性に対して、提案されたコード修正を含むレビュー可能なマージリクエストを自動作成します。</li><li>品質評価を提供し、レビュアーが提案された修正に対する信頼度を素早く把握できます。</li><li>脆弱性詳細ページから直接修正を適用できます。</li></ul><p>フィードバックは<a href="https://gitlab.com/gitlab-org/gitlab/-/issues/585626" rel="">イシュー585626</a>にてお待ちしています。</p><h3 id="gitlabデータ分析基本エージェントが一般提供開始">GitLabデータ分析基本エージェントが一般提供開始</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/data_analyst/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/20337" rel="">関連エピック</a></li></ul><p>データ分析エージェントはAIチャットアシスタントで、GitLabプラットフォーム全体のデータをクエリ、可視化し、インサイトを導き出せます。</p><p><a href="https://docs.gitlab.com/ja-jp/user/glql" rel="">GitLab Query Language（GLQL）</a>を基盤として、サポート対象の<a href="https://docs.gitlab.com/ja-jp/user/glql/data_sources/" rel="">データソース</a>に関するデータを取得・分析し、ソフトウェア開発の健全性やエンジニアリング効率について明確で実用的なインサイトを提供します。</p><p>これらのインサイトはエージェントの出力内で直接可視化でき、イシューやエピックに埋め込んでさらに評価できます。</p><h3 id="ciエキスパートエージェントがベータ版として公開">CIエキスパートエージェントがベータ版として公開</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/ci_expert_agent/" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/587460" rel="">関連イシュー</a></li></ul><p>AIを活用したCIエキスパートエージェントがベータ版として利用可能になりました。このエージェントは、空の<code className="">.gitlab-ci.yml</code>からではなく、GitLab上のコードを基に、最初の動作するパイプラインを作れるよう支援します。</p><p>GitLab Duo Agent Platformを使用してリポジトリを検査した後、ビルドやテストプロセスについていくつかのガイド付き質問を行います。その結果をもとに、レビュー・編集・コミットが可能なすぐに実行できるパイプラインを生成します。</p><p>パイプラインの作成が会話形式のコンテキストに沿った体験になると同時に、YAMLを本格的に調整・最適化したい段階になれば、すべてを自分で制御できます。</p><h3 id="脆弱性の重大度が自動オーバーライド可能に">脆弱性の重大度が自動オーバーライド可能に</h3><ul><li><strong>利用可能プラン：</strong> Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/application_security/policies/vulnerability_management_policy/#severity-override-policies" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/epics/15839" rel="">関連エピック</a></li></ul><p>脆弱性のデフォルト重大度は、必ずしも組織の実際のリスクを反映しているわけではありません。たとえば、内部専用サービスにおける重大なCVEが、公開アプリケーションと同じ緊急度で対応すべきとは限りません。それにもかかわらず、チームは自社のリスクモデルに合わない検出結果のトリアージに多くの時間を費やしています。</p><p>脆弱性管理ポリシーにより、CVE ID、CWE ID、ファイルパス、ディレクトリなどの条件に基づいて脆弱性の重大度を自動調整できるようになりました。ポリシーが適用されると、デフォルトブランチ上の条件に一致する脆弱性の重大度が更新されます。手動によるオーバーライドは引き続き優先され、すべての変更は脆弱性の履歴と監査イベントに記録されます。</p><p>トリアージ作業を削減し、ビジネスにとって最も重要な検出結果にデベロッパーが集中できるようにします。</p><h3 id="サブグループおよびプロジェクトでサービスアカウントの作成が可能に">サブグループおよびプロジェクトでサービスアカウントの作成が可能に</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/profile/service_accounts/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/17754" rel="">関連エピック</a></li></ul><p>サブグループおよびプロジェクトでサービスアカウントを作成できるようになりました。トップレベルグループの広範なボットの代わりに、単一のサブグループまたはプロジェクトに専用のサービスアカウントを関連付け、そのネームスペースの他のメンバーと同様にアクセスを管理できます。グループおよびサブグループのサービスアカウントは、作成されたグループまたはその配下のサブグループやプロジェクトに招待できます。プロジェクトサービスアカウントは、そのプロジェクト内に限定されます。</p><h3 id="サービスアカウントがgitlab-freeで利用可能に">サービスアカウントがGitLab Freeで利用可能に</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/profile/service_accounts/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/20439" rel="">関連エピック</a></li></ul><p>サービスアカウントがGitLab.comのすべてのプランで利用可能になりました。以前はPremiumおよびUltimateに限定されていたサービスアカウントにより、個々のチームメンバーに認証情報を紐付けることなく、自動化されたアクション、データアクセス、スケジュール処理を実行できます。チームの変更に関係なく認証情報を安定的に維持する必要があるパイプラインやサードパーティのインテグレーションで広く使用されています。GitLab Freeでは、トップレベルグループごとに最大100個のサービスアカウント（サブグループやプロジェクトで作成されたものを含む）を作成できます。</p><h3 id="詳細制限付きパーソナルアクセストークンが利用可能にベータ版"><strong>詳細制限付き</strong>パーソナルアクセストークンが利用可能に（ベータ版）</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/auth/tokens/fine_grained_access_tokens/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/18555" rel="">関連エピック</a></li></ul><p>詳細権限付きパーソナルアクセストークン（PAT）がベータ版として利用可能になりました。従来のPATはユーザーが所属するすべてのプロジェクトとグループへのアクセスを付与しますが、詳細権限付きPATでは各トークンのアクセス先を特定のリソースやアクションに絞り込めます。万が一トークンが漏洩・侵害された場合の影響範囲を大幅に縮小できます。</p><p>既存のPATはこれまでどおり動作し、詳細権限なしのレガシーPATも引き続き作成できます。</p><p>今回のベータリリースではGitLab REST APIの約75%をカバーしています。REST APIの完全なカバレッジ、GraphQLの適用、管理者によるポリシーコントロールはGAリリースで対応予定です。</p><p>フィードバックは<a href="https://gitlab.com/groups/gitlab-org/-/epics/18555" rel="">エピック18555</a>にてお待ちしています。</p><h3 id="セキュリティダッシュボードにトップcweチャートを追加">セキュリティダッシュボードにトップCWEチャートを追加</h3><ul><li><strong>利用可能プラン：</strong> Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/application_security/security_dashboard/#top-10-cwes" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/epics/17422" rel="">関連エピック</a></li></ul><p>新しいセキュリティダッシュボードでトップCWEチャートが利用可能になりました。プロジェクトまたはインスタンス全体で最も一般的なCWEを特定し、トレーニング、改善、プログラムの最適化の機会を見つけられます。ダッシュボードデータを重大度別にグループ化したり、重大度、プロジェクト、レポートタイプでフィルタリングできます。</p><h3 id="kubernetesへのgitalyデプロイ">KubernetesへのGitalyデプロイ</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/administration/gitaly/kubernetes/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/6127" rel="">関連イシュー</a></li></ul><p>完全にサポートされたデプロイ方法として、Kubernetes上にGitalyをデプロイできるようになりました。Kubernetesのオーケストレーション機能を活用したスケーリング、高可用性、リソース管理により、GitLabインフラストラクチャの管理の柔軟性が向上します。以前は、Kubernetesへのデプロイにはカスタム構成が必要で公式サポートがなかったため、コンテナ化された環境で信頼性の高いGitalyクラスターを維持することが困難でした。</p><h3 id="マージリクエストパイプラインの手動実行時にインプットを再設定可能に">マージリクエストパイプラインの手動実行時にインプットを再設定可能に</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/ci/pipelines/merge_request_pipelines/#run-a-merge-request-pipeline-with-custom-inputs" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/547861" rel="">関連イシュー</a></li></ul><p>CI/CDインプットを使うと、パイプラインの実行時にパラメータ値を変更して動作をカスタマイズできます。これまでこの機能はマージリクエスト（MR）パイプラインでは利用できませんでしたが、今回のリリースでMRパイプラインにも対応しました。</p><p>MRパイプライン向けにインプットを設定した後、マージリクエストの新しいパイプラインを実行するたびに、インプットを変更してパイプラインの動作を変更できます。</p><hr /><h2 id="agent-platformの中核機能">Agent Platformの中核機能</h2><h3 id="gitlab-duo-agentic-chatのデフォルトモデルがhaiku-45からsonnet-46に更新">GitLab Duo Agentic Chatのデフォルトモデルがhaiku 4.5からSonnet 4.6に更新</h3><ul><li><strong>利用可能プラン：</strong> Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/model_selection/#default-models" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/595042" rel="">関連イシュー</a></li></ul><p>GitLabのAgentic Chat体験を向上させるアップデートを行いました。Agentic ChatのデフォルトモデルがVertex AIでホストされるClaude Haiku 4.5からClaude Sonnet 4.6にアップグレードされました。Claude Sonnet 4.6は推論と応答品質が向上していますが、Haiku 4.5と比べてGitLabクレジット消費量が多くなります。</p><p><a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/model_selection/#select-a-model-for-a-feature" rel="">モデル選択</a>設定から、Haikuを含む代替モデルを選択できます。すでに特定のモデルを選択している場合、その選択は維持されます。このアップデートはデフォルトのみに影響し、既存の選択を上書きしません。モデルごとのクレジット消費量の詳細については、<a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/" rel="">GitLabクレジットのドキュメント</a>をご確認ください。</p><h3 id="カスタムフロー定義でツールを設定可能に">カスタムフロー定義でツールを設定可能に</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/custom/#create-a-flow" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/work_items/2147" rel="">関連イシュー</a></li></ul><p>カスタムフロー定義内でツールオプションとパラメータ値を直接設定し、LLMのデフォルト値を上書きできるようになりました。カスタムフロー内でのツールの動作をより正確かつ一貫して制御でき、ガードレールや特定のパラメータ値の適用が容易になります。</p><h3 id="mistral-aiがgitlab-duo-agent-platformのセルフホストモデルとして利用可能に">Mistral AIがGitLab Duo Agent Platformのセルフホストモデルとして利用可能に</h3><ul><li><strong>利用可能プラン：</strong> Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/administration/gitlab_duo_self_hosted/supported_llm_serving_platforms/#cloud-hosted-model-deployments" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/587872" rel="">関連イシュー</a></li></ul><p>GitLab Duo Agent Platformが、セルフホストモデルデプロイ向けのLLMプラットフォームとしてMistral AIをサポートしました。GitLab Self-Managedをご利用のお客様は、既存のサポート対象プラットフォーム（AWS Bedrock、Google Vertex AI、Azure OpenAI、Anthropic、OpenAI）と並行してMistral AIを設定できます。AI機能の運用方法の選択肢がさらに広がりました。</p><hr /><h2 id="スケールとデプロイ">スケールとデプロイ</h2><h3 id="gitlabクレジットダッシュボードで過去の月を表示可能に">GitLabクレジットダッシュボードで過去の月を表示可能に</h3><ul><li><strong>利用可能プラン：</strong> Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#view-credit-usage-details" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/590843" rel="">関連イシュー</a></li></ul><p>カスタマーポータルのGitLabクレジットダッシュボードで、過去の請求月を遡って確認できるようになりました。請求管理者は日々の使用状況の推移や期間ごとの消費パターンを比較し、請求書の内容と照らし合わせて確認できます。以前はダッシュボードに当月の請求月のみが表示されていました。この改善により、管理者はクレジット配分についてより的確な判断を行い、過去のデータに基づいて将来のニーズを予測できます。</p><h3 id="gitlabクレジットのサブスクリプションレベル使用量上限の設定">GitLabクレジットのサブスクリプションレベル使用量上限の設定</h3><ul><li><strong>利用可能プラン：</strong> Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#set-a-monthly-usage-cap-for-on-demand-credits" rel="">ドキュメント</a></li></ul><p>管理者がサブスクリプションレベルでオンデマンドクレジットの月間使用量上限を設定できるようになりました。オンデマンドクレジットの消費総量が設定された上限に達すると、そのサブスクリプションのすべてのユーザーに対してGitLab Duo Agent Platformへのアクセスが自動的に一時停止され、次の請求期間の開始時または管理者が上限を調整するまで継続されます。この設定により、予期しない超過料金に対する確実なガードレールを提供し、Agent Platformのより広範な展開における主要な障壁を取り除きます。上限は請求期間ごとに自動的にリセットされ、管理者には上限到達時にメール通知が送信されます。</p><h3 id="ユーザーごとのgitlabクレジット上限の設定">ユーザーごとのGitLabクレジット上限の設定</h3><ul><li><strong>利用可能プラン：</strong> Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#set-a-per-user-usage-cap" rel="">ドキュメント</a></li></ul><p>管理者が請求期間ごとにGitLabクレジットのユーザーごとの使用量上限をオプションで設定できるようになりました。個々のユーザーの総クレジット消費量が設定された上限に達すると、そのユーザーのみGitLab Duo Agent Platformへのアクセスが一時停止されます。他のユーザーは影響を受けません。特定のユーザーが組織全体のクレジットを偏って消費することを防ぎ、管理者が使用量の配分をきめ細かく制御できます。ユーザーごとの使用量上限はサブスクリプションレベルの使用量上限と連動し、先に到達した上限が適用されます。</p><h3 id="linuxパッケージの改善">Linuxパッケージの改善</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/omnibus/settings/database/#upgrade-packaged-postgresql-server" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/omnibus-gitlab/-/work_items/9734" rel="">関連イシュー</a></li></ul><p>GitLab 19.0では、PostgreSQLの最低サポートバージョンがバージョン17になります。この変更に備えて、<a href="https://docs.gitlab.com/ja-jp/administration/postgresql/replication_and_failover/" rel="">PostgreSQLクラスター</a>を使用していないインスタンスでは、GitLab 18.11へのアップグレード時にPostgreSQL 17への自動アップグレードが試行されます。</p><p><a href="https://docs.gitlab.com/ja-jp/administration/postgresql/replication_and_failover/" rel="">PostgreSQLクラスター</a>を使用している場合、またはこの<a href="https://docs.gitlab.com/ja-jp/omnibus/settings/database/#opt-out-of-automatic-postgresql-upgrades" rel="">自動アップグレードをオプトアウト</a>する場合は、GitLab 19.0にアップグレードするために<a href="https://docs.gitlab.com/ja-jp/omnibus/settings/database/#upgrade-packaged-postgresql-server" rel="">PostgreSQL 17に手動でアップグレード</a>する必要があります。</p><h3 id="コンテナレジストリメタデータデータベースのバックアップとリストアのサポート">コンテナレジストリメタデータデータベースのバックアップとリストアのサポート</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/administration/backup_restore/#metadata-database" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-com/gl-infra/data-access/durability/-/work_items/45" rel="">関連イシュー</a></li></ul><p>Linuxパッケージインストール向けのGitLab<a href="https://docs.gitlab.com/ja-jp/administration/backup_restore/" rel="">バックアップRakeタスク</a>と、Cloud Native（Helm）インストール向けの<a href="https://docs.gitlab.com/ja-jp/charts/backup-restore/" rel="">backup-utility</a>が、<a href="https://docs.gitlab.com/ja-jp/administration/packages/container_registry_metadata_database/" rel="">コンテナレジストリメタデータデータベース</a>に対応しました。メタデータデータベースに格納されているblob、manifest、タグなどのデータへの参照をバックアップでき、悪意のあるまたは偶発的なデータ破損からの復旧が可能になります。</p><h3 id="検索のグループ向け新しいナビゲーション体験">検索のグループ向け新しいナビゲーション体験</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/group/manage" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/20521" rel="">関連エピック</a></li></ul><p>検索のグループ一覧が改善され、GitLabインスタンス全体でのグループの発見が容易になりました。再設計されたインターフェースでは、2つのビューを持つタブレイアウトを採用しています。</p><ul><li><strong>アクティブタブ：</strong> アクセス可能なすべてのグループを閲覧し、関連するコミュニティやプロジェクトを発見できます。</li><li><strong>非アクティブタブ：</strong> アーカイブされたグループや削除保留中のグループを表示し、グループのライフサイクルステータスを確認できます。</li></ul><p>これらの変更により、グループの発見が効率化され、参加可能なグループの可視性が向上します。</p><h3 id="プロジェクトの非同期転送">プロジェクトの非同期転送</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/group/manage" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/20521" rel="">関連エピック</a></li></ul><p>以前のバージョンのGitLabでは、大規模なグループやプロジェクトの転送がタイムアウトになることがありました。今回、転送・アーカイブ・削除などの操作に統一された状態管理モデルを導入したことで、動作の一貫性が向上し、状態履歴や監査詳細の可視性が改善されました。また、転送処理が非同期化され、長時間の操作でもタイムアウトが発生しにくくなっています。</p><hr /><h2 id="統合devopsとセキュリティ">統合DevOpsとセキュリティ</h2><h3 id="clickhouseがself-managedデプロイで一般提供開始">ClickHouseがSelf-Managedデプロイで一般提供開始</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/integration/clickhouse/#set-up-clickhouse" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/architecture/gitlab-data-analytics/-/work_items/51" rel="">関連イシュー</a></li></ul><p>GitLab Self-Managedインスタンス向けに、GitLab <a href="https://docs.gitlab.com/ja-jp/integration/clickhouse/" rel="">ClickHouseインテグレーション</a>の推奨事項と設定ガイダンスが改善されました。独自のクラスターを持ち込むか、ClickHouse Cloud（推奨）セットアップオプションを使用できます。このインテグレーションは複数のダッシュボードを支え、アナリティクス領域内のさまざまなAPIエンドポイントへのアクセスを提供します。</p><p>このスケーラブルで高パフォーマンスなデータベースは、GitLabアナリティクスインフラストラクチャにおける大規模なアーキテクチャ改善計画の一環です。</p><h3 id="duosdlcトレンドダッシュボードでのgitlab-duo-agent-platformアナリティクスの強化">Duo・SDLCトレンドダッシュボードでのGitLab Duo Agent Platformアナリティクスの強化</h3><ul><li><strong>利用可能プラン：</strong> Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated</li><li><strong>アドオン：</strong> Duo Pro、Duo Enterprise</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/analytics/duo_and_sdlc_trends/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/20540" rel="">関連エピック</a></li></ul><p>GitLab DuoおよびSDLCトレンドダッシュボードが改善され、ソフトウェアデリバリーへのGitLab Duoの影響を測定するためのアナリティクス機能が強化されました。月間Agent Platformユニークユーザー数とAgentic Chatセッション数の新しいシングルスタットパネルが追加されました。また、シート割り当てに対する使用率（%）として表示されていたメトリクスが、使用回数のみを報告するように更新されました。この変更により、新しい使用量課金モデルのAgent Platform使用量が反映されていなかった<a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/590326" rel="">問題</a>が解消されます。</p><h3 id="glqlがプロジェクトパイプラインジョブのデータソースにアクセス可能に">GLQLがプロジェクト、パイプライン、ジョブのデータソースにアクセス可能に</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/glql/data_sources/" rel="">ドキュメント</a></li></ul><p><a href="https://docs.gitlab.com/ja-jp/user/glql/" rel="">GitLab Query Language（GLQL）</a>が3つの新しいデータソース（プロジェクト、パイプライン、ジョブ）にアクセスできるようになりました。これらの新しいデータソースは埋め込みビューとしても利用でき、パイプライン結果、ジョブステータス、プロジェクト概要をWiki、イシューやマージリクエストの説明、リポジトリのMarkdownファイルに直接表示できます。GLQLは<a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/data_analyst/" rel="">データ分析エージェント</a>の基盤でもあり、これらの新しいタイプにより、エージェントはCI/CDジョブの結果の検査、障害のデバッグ、パイプライン実行の詳細な概要の提供、およびネームスペース内のプロジェクトの正確な概要の提供が可能になります。</p><h3 id="mavenおよびpythonのsbomスキャンにおける依存関係の解決">MavenおよびPythonのSBOMスキャンにおける依存関係の解決</h3><ul><li><strong>利用可能プラン：</strong> Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/application_security/dependency_scanning/dependency_scanning_sbom/#dependency-resolution" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/20461" rel="">関連エピック</a></li></ul><p>SBOMを使用したGitLabの依存関係スキャンが、MavenおよびPythonプロジェクトの依存関係グラフの自動生成に対応しました。以前は、正確な依存関係分析にはロックファイルまたはグラフファイルの提供が必要でした。今回の改善により、これらのファイルが利用できない場合はアナライザーが自動的に生成を試みるようになり、MavenおよびPythonプロジェクトでロックファイルなしでも依存関係スキャンを有効にしやすくなりました。</p><h3 id="高度なsastのインクリメンタルスキャン">高度なSASTのインクリメンタルスキャン</h3><ul><li><strong>利用可能プラン：</strong> Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/application_security/sast/gitlab_advanced_sast/#incremental-scanning" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/20508" rel="">関連エピック</a></li></ul><p>GitLab高度なSASTで、コードベースの変更された部分のみを分析するインクリメンタルスキャンが可能になりました。リポジトリ全体のスキャンと比較してスキャン時間が大幅に短縮されます。この機能は差分ベースのスキャンをさらに進化させたもので、コードベース全体の完全な結果を生成します。</p><p>変更されたコードのみをスキャンすることで、速度を犠牲にしたり摩擦を増やしたりすることなく、セキュリティテストを開発ワークフローにシームレスに統合できます。</p><h3 id="未検証の脆弱性ベータ版">未検証の脆弱性（ベータ版）</h3><ul><li><strong>利用可能プラン：</strong> Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/application_security/sast/gitlab_advanced_sast/#report-unverified-vulnerabilities" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/15649" rel="">関連エピック</a></li></ul><p>高度なSASTが、未検証の脆弱性（ソースからシンクまで完全にトレースできない検出結果）を脆弱性レポートに直接表示できるようになりました。検出漏れ（偽陰性）よりも誤検出（偽陽性）が多くなることを許容できる場合には、この機能を有効にしてください。</p><p>この機能はベータ版です。フィードバックは<a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/596512" rel="">イシュー596512</a>にてお待ちしています。</p><h3 id="kubernetes-135のサポート">Kubernetes 1.35のサポート</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/584225" rel="">関連イシュー</a></li></ul><p>GitLabがKubernetesバージョン1.35を正式にサポートしました。アプリケーションをKubernetesにデプロイしてすべての機能にアクセスするには、接続されたクラスターを最新バージョンにアップグレードしてください。詳細については、<a href="https://docs.gitlab.com/ja-jp/user/clusters/agent/#supported-kubernetes-versions-for-gitlab-features" rel="">GitLabの機能でサポートされているKubernetesのバージョン</a>をご確認ください。</p><h3 id="コンテナレジストリ-メタデータ-データベースのpreferモード">コンテナレジストリ メタデータ データベースのpreferモード</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/administration/packages/container_registry_metadata_database/#prefer-mode" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/595480" rel="">関連イシュー</a></li></ul><p>コンテナレジストリ メタデータ データベースを<code className="">prefer</code>モードに設定できるようになりました。これは、既存の<code className="">true</code>および<code className="">false</code>の値に加わる新しい設定オプションです。preferモードでは、レジストリがインストールの現在の状態に基づいて、メタデータデータベースを使用するかレガシーストレージにフォールバックするかを自動的に検出します。</p><p>データベースにインポートされていない既存のファイルシステムメタデータがある場合、メタデータのインポートが完了するまでレガシーストレージが引き続き使用されます。データベースがすでに使用されている場合、または新規インストールの場合は、レジストリがデータベースを直接使用します。</p><p>今後のリリースで、<code className="">prefer</code>モードは新規Linuxパッケージインストールのデフォルトになる予定です。既存のインストールには影響しません。詳細については、<a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/595480" rel="">イシュー595480</a>をご確認ください。</p><h3 id="パッケージ保護ルールがterraformモジュールに対応">パッケージ保護ルールがTerraformモジュールに対応</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/packages/package_registry/package_protection_rules/" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/592761" rel="">関連イシュー</a></li></ul><p>これまで、ビルトインのGitLab Terraformモジュールレジストリからモジュールを公開しているチームには、新しいモジュールバージョンのプッシュを制限する手段がありませんでした。パッケージ保護ルールは複数のパッケージ形式に対応していたものの、<code className="">terraform_module</code>は対象外だったため、インフラストラクチャチームはプロジェクトレベルでプッシュを制御できませんでした。</p><p>今回、<code className="">terraform_module</code>を対象としたパッケージ保護ルールを作成できるようになり、最小ロールに基づいてプッシュアクセスを制限できます。この機能はUI、REST API、GraphQL API、GitLab Terraformプロバイダーリソースから利用できます。</p><h3 id="リリースエビデンスにパッケージが含まれるように">リリースエビデンスにパッケージが含まれるように</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/project/releases/release_evidence/#include-packages-as-release-evidence" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/283995" rel="">関連イシュー</a></li></ul><p>GitLabリリースの作成時、パッケージレジストリに公開されたパッケージは自動的にリリースに関連付けられませんでした。チームはパッケージURLを手動で構築し、APIやパイプラインスクリプトを通じてリリースリンクとして添付する必要があり、手間がかかるうえ不完全なリリースレコードのリスクがありました。</p><p>パッケージのバージョンがリリースタグと一致する場合、GitLabがリリースエビデンスにパッケージを自動的に含めるようになりました。手動の手順なしにリリースと関連パッケージ間の検証可能で監査可能なリンクが作成され、ソースコード、アーティファクト、パッケージが1つの完全なリリーススナップショットにまとめられます。</p><h3 id="wikiサイドバートグルの位置変更によるアクセス性向上">Wikiサイドバートグルの位置変更によるアクセス性向上</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/project/wiki/#sidebar" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/580569" rel="">関連イシュー</a></li></ul><p>Wikiサイドバートグルが、制御対象のサイドバーのすぐ横の左側に配置されるようになりました。</p><p>サイドバーが折りたたまれている場合でも、フローティングコントロールとしてトグルが表示されたままになるため、ページの先頭までスクロールすることなく再度開けます。</p><h3 id="wikiページのアクションバーが固定表示に">Wikiページのアクションバーが固定表示に</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/project/wiki/" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/590255" rel="">関連イシュー</a></li></ul><p>Wikiページのアクションバーが固定表示されるようになり、ページをスクロールしても常に画面上に表示されます。以前は、編集やページ履歴の表示、テンプレートの管理などにアクセスするにはページの先頭までスクロールする必要がありました。ページタイトルと主要なアクション（編集、新しいページ、テンプレート、ページ履歴など）が、ページのどこにいても手の届く場所に表示されます。</p><h3 id="エピックのウェイト">エピックのウェイト</h3><ul><li><strong>利用可能プラン：</strong> Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/work_items/weight/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/12273" rel="">関連エピック</a></li></ul><p>エピックがウェイトに対応し、計画時に大規模なイニシアティブの見積もりと優先順位付けが容易になりました。</p><p>エピックを子イシューに分解する前に、初期見積もりを表す暫定ウェイトを割り当てられます。エピックを分解すると、すべての子イシューからのロールアップ合計を反映してウェイトが自動的に更新されます。これは、イシューやタスクのウェイトロールアップの動作と一貫しています。</p><p>エピック詳細ページでは、暫定ウェイトと子イシューからのロールアップウェイトの両方を確認でき、時間の経過とともに見積もりを洗練するために必要なインサイトを得られます。</p><h3 id="悪用可能性リスクの高いマージリクエストのブロック">悪用可能性リスクの高いマージリクエストのブロック</h3><ul><li><strong>利用可能プラン：</strong> Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/application_security/policies/merge_request_approval_policies/#vulnerability_attributes-object" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/epics/16311" rel="">関連エピック</a></li></ul><p>以前は、マージリクエスト（MR）の承認ポリシーは脆弱性の重大度に基づいてMRをブロックできましたが、すべての脆弱性が同じリスクを持つわけではありません。CVSSの重大度だけでは、CVEが実際に悪用されているかどうかや悪用の可能性はわかりません。その結果、承認ポリシーがノイズの多いものとなり、デベロッパーとセキュリティチームの時間が浪費されていました。</p><p>Known Exploited Vulnerability（KEV）およびExploit Prediction Scoring System（EPSS）データを使用してMR承認ポリシーを設定できるようになりました。検出結果がKEVカタログに含まれている場合（実際に悪用されている場合）、またはEPSSスコアがしきい値を超えている場合に、ブロックまたは承認を要求できます。MRのポリシー違反にはKEVおよびEPSSのコンテキストが含まれ、デベロッパーはセキュリティゲートがトリガーされた理由を理解できます。</p><p>セキュリティチームにどの検出結果をブロックまたは警告するかの正確な制御を提供し、アラート疲労を軽減し、現在の脅威状況に沿った適用を実現します。</p><h3 id="脆弱性へのcvss-40スコアの割り当て">脆弱性へのCVSS 4.0スコアの割り当て</h3><ul><li><strong>利用可能プラン：</strong> Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/severities/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/epics/18697" rel="">関連エピック</a></li></ul><p>CVSS 4.0は、脆弱性の重大度を評価・格付けするための業界標準の最新バージョンです。UIでCVSS 4.0スコアを表示・確認できるようになりました（脆弱性詳細ページおよび脆弱性レポートを含む）。APIを使用したスコアのクエリも可能です。</p><h3 id="脆弱性レポートの行操作の改善">脆弱性レポートの行操作の改善</h3><ul><li><strong>利用可能プラン：</strong> Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/application_security/vulnerability_report/" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/561414" rel="">関連イシュー</a></li></ul><p>以前は、脆弱性レポートから詳細ページに移動するには、行内の説明テキストをクリックする必要がありました。</p><p>今回の改善で、行のどこをクリックしても詳細ページに直接移動できるようになりました。脆弱性の説明やファイルの場所のリンク表示はマウスを合わせたときのみ表示されるようになり、キーボードナビゲーションも改善されています。</p><p>これらの変更により、脆弱性レポートがより直感的で使いやすくなりました。</p><h3 id="セキュリティダッシュボードのpdfエクスポート">セキュリティダッシュボードのPDFエクスポート</h3><ul><li><strong>利用可能プラン：</strong> Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/application_security/security_dashboard/#export-as-pdf" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/epics/18203" rel="">関連エピック</a></li></ul><p>セキュリティダッシュボードをレポートやプレゼンテーション用にPDFとしてエクスポートできるようになりました。エクスポートには、アクティブなフィルターを含むダッシュボードのすべてのチャートとパネルの現在の状態が反映されます。</p><h3 id="セキュリティ設定プロファイルでのsastスキャン">セキュリティ設定プロファイルでのSASTスキャン</h3><ul><li><strong>利用可能プラン：</strong> Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/application_security/configuration/security_configuration_profiles/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/19951" rel="">関連エピック</a></li></ul><p>GitLab 18.9では、<strong>シークレット検出 - デフォルト</strong>プロファイルによりセキュリティ設定プロファイルを導入しました。GitLab 18.11では、<strong>静的アプリケーションセキュリティテスト（SAST） - デフォルト</strong>プロファイルが追加され、SASTにも対応しました。CI/CD設定ファイルを一切編集することなく、標準化された静的解析のスキャン設定をすべてのプロジェクトに適用できます。</p><p>このプロファイルは2つのスキャントリガーを有効にします。</p><ul><li><strong>マージリクエストパイプライン：</strong> オープンなマージリクエストのあるブランチに新しいコミットがプッシュされるたびに、SASTスキャンを自動実行します。結果にはマージリクエストによって導入された新しい脆弱性のみが含まれます。</li><li><strong>ブランチパイプライン（デフォルトのみ）：</strong> 変更がデフォルトブランチにマージまたはプッシュされた際に自動実行され、デフォルトブランチのSAST態勢の包括的なビューを提供します。</li></ul><h3 id="グループセキュリティダッシュボードのセキュリティ属性フィルター">グループセキュリティダッシュボードのセキュリティ属性フィルター</h3><ul><li><strong>利用可能プラン：</strong> Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/application_security/security_dashboard/#filter-the-entire-dashboard" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/epics/18201" rel="">関連エピック</a></li></ul><p>グループセキュリティダッシュボードの結果を、グループ内のプロジェクトに適用されたセキュリティ属性に基づいてフィルタリングできるようになりました。</p><p>利用可能なセキュリティ属性は以下のとおりです。</p><ul><li>ビジネスインパクト</li><li>アプリケーション</li><li>ビジネスユニット</li><li>インターネット露出</li><li>ロケーション</li></ul><h3 id="セキュリティマネージャーロールベータ版">セキュリティマネージャーロール（ベータ版）</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/permissions/#security-manager" rel="">ドキュメント</a></li></ul><p>セキュリティマネージャーロールがベータ版として利用可能になりました。セキュリティ専門家向けに設計された新しいデフォルトの権限セットを提供します。セキュリティチームはセキュリティ機能にアクセスするためにデベロッパーやメンテナーロールを必要とせず、過剰な権限付与の懸念を解消しながら職務分離を維持できます。</p><p>セキュリティマネージャーロールのユーザーには以下のアクセス権限があります。</p><ul><li><strong>脆弱性管理：</strong> グループおよびプロジェクト全体の脆弱性の表示、トリアージ、管理（脆弱性レポートおよびセキュリティダッシュボードを含む）。</li><li><strong>セキュリティインベントリ：</strong> グループのセキュリティインベントリを表示し、全プロジェクトのスキャナーカバレッジを把握。</li><li><strong>セキュリティ設定プロファイル：</strong> グループのセキュリティ設定プロファイルの表示。</li><li><strong>コンプライアンスツール：</strong> グループまたはプロジェクトの監査イベント、コンプライアンスセンター、コンプライアンスフレームワーク、依存関係リストの表示。</li><li><strong>シークレットプッシュ保護：</strong> グループのシークレットプッシュ保護の有効化。</li><li><strong>オンデマンドDAST：</strong> グループのオンデマンドDASTスキャンの作成と実行。</li></ul><p>開始するには、グループに移動し、<strong>管理 &gt; メンバー</strong>を選択してメンバーを招待し、セキュリティマネージャーロールを割り当ててください。</p><h3 id="脆弱性レポートの識別子リストポップオーバー">脆弱性レポートの識別子リストポップオーバー</h3><ul><li><strong>利用可能プラン：</strong> Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/user/application_security/vulnerability_report/" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/564939" rel="">関連イシュー</a></li></ul><p>脆弱性レポートの各行にプライマリCVE識別子がクリック可能なリンクとして表示されるようになりました。複数の識別子が存在する場合、**「+N more」**のポップオーバーですべての識別子が一覧表示されます。リスト内の各識別子は外部参照（CVE、CWE、WASCデータベースなど）にリンクしており、レポートを離れることなく詳細にすばやくアクセスできます。</p><h3 id="gitlab-runner-1811">GitLab Runner 18.11</h3><ul><li><strong>利用可能プラン：</strong> Free、Premium、Ultimate</li><li><strong>提供形態：</strong> GitLab Self-Managed、GitLab.com、GitLab Dedicated、GitLab Dedicated for Government</li><li><strong>リンク：</strong> <a href="https://docs.gitlab.com/ja-jp/runner" rel="">ドキュメント</a></li></ul><p>GitLab Runner 18.11もリリースしました。GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに返送する高いスケーラビリティを備えたビルドエージェントです。GitLab Runnerは、GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。</p><h4 id="新機能">新機能：</h4><ul><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39286" rel="">バンドルされた依存関係を含む<code className="">concrete</code>ヘルパーイメージの作成</a></li><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39280" rel="">環境変数ではなくRunner設定からジョブルーターのフィーチャーフラグを読み取り</a></li></ul><h4 id="バグ修正">バグ修正：</h4><ul><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39329" rel="">リファクタリング後のRunnerバイナリパスの誤り</a></li><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39279" rel="">キャッシュ操作時のパイプラインハング</a></li><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39276" rel="">GitLab Runner 18.9.0の<code className="">docker-machine</code>バイナリがCVE-2025-68121を参照</a></li><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39201" rel=""><code className="">DOCKER_AUTH_CONFIG</code>からのクレデンシャルヘルパーバイナリが見つからない場合にRunnerがジョブペイロードの認証情報にサイレントフォールバック</a></li><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/38307" rel=""><code className="">CONCURRENT_PROJECT_ID</code>が異なるジョブ間で一意でなく、ビルドディレクトリで競合が発生</a></li><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/37220" rel="">アーティファクトのアップロードがレスポンスヘッダーのタイムアウトで失敗</a></li><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/3116" rel="">失敗した<code className="">pre_build_script</code>の後にユーザー定義の<code className="">after_script</code>が実行され、<code className="">post_build_script</code>がバイパスされる</a></li></ul><p>すべての変更の一覧はGitLab Runner <a href="https://gitlab.com/gitlab-org/gitlab-runner/blob/18-11-stable/CHANGELOG.md" rel="">CHANGELOG</a>をご覧ください。</p><hr /><h2 id="関連トピック">関連トピック</h2><ul><li><a href="https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&amp;state=closed&amp;label_name%5B%5D=type%3A%3Abug&amp;or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&amp;or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&amp;or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&amp;milestone_title=18.11" rel="">バグ修正</a></li><li><a href="https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&amp;state=closed&amp;label_name%5B%5D=bug%3A%3Aperformance&amp;or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&amp;or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&amp;or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&amp;milestone_title=18.11" rel="">パフォーマンスの改善</a></li><li><a href="https://papercuts.gitlab.com/?milestone=18.11" rel="">UIの改善</a></li><li><a href="https://docs.gitlab.com/ja-jp/update/deprecations/" rel="">非推奨と削除</a></li><li><a href="https://docs.gitlab.com/ja-jp/update/versions/" rel="">アップグレードノート</a></li></ul><hr /><h3 id="インストール">インストール</h3><p>新規にGitLabをセットアップする場合は、<a href="https://about.gitlab.com/install/" rel="">GitLabダウンロードページ</a>をご覧ください。</p><h3 id="アップデート">アップデート</h3><p><a href="https://about.gitlab.com/update/" rel="">アップデートページ</a>をご確認ください。</p><h3 id="ご不明な点がある場合">ご不明な点がある場合</h3><p>ご質問やご意見をお聞かせください。本リリースについてご不明な点がある場合は、<a href="https://forum.gitlab.com/" rel="">GitLabフォーラム</a>にアクセスして質問を投稿してください。</p><h3 id="gitlabサブスクリプションプラン">GitLabサブスクリプションプラン</h3><ul><li><a href="https://about.gitlab.com/pricing/" rel="">Free</a>
ユーザー向けの永久無料機能を提供</li><li><a href="https://about.gitlab.com/pricing/premium/" rel="">Premium</a>
チームの生産性と調整を強化</li><li><a href="https://about.gitlab.com/pricing/ultimate/" rel="">Ultimate</a>
組織全体のセキュリティ、コンプライアンス、プランニングに対応
GitLabのすべての機能を<a href="https://about.gitlab.com/free-trial/?hosted=saas" rel="">無料</a>でお試しいただけます。</li></ul><p><em>--------------------</em></p><h3 id="過去の日本語リリース情報">過去の日本語リリース情報</h3><ul><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-10-release/" rel="">GitLab 18.10</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-09-release/" rel="">GitLab 18.9</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-08-release/" rel="">GitLab 18.8</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-07-release/" rel="">GitLab 18.7</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-06-release/" rel="">GitLab 18.6</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-05-release/" rel="">GitLab 18.5</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-04-release" rel="">GitLab 18.4</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-03-release" rel="">GitLab 18.3</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-02-release/" rel="">GitLab 18.2</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-01-release/" rel="">GitLab 18.1</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-0-release/" rel="">GitLab 18.0</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-11-release/" rel="">GitLab 17.11</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-10-release/" rel="">GitLab 17.10</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-9-release/" rel="">GitLab 17.9</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-8-release/" rel="">GitLab 17.8</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-7-release/" rel="">GitLab 17.7</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-6-release/" rel="">GitLab 17.6</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-5-released/" rel="">GitLab 17.5</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-4-released/" rel="">GitLab 17.4</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-3-released/" rel="">GitLab 17.3</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-2-released/" rel="">GitLab 17.2</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-1-released/" rel="">GitLab 17.1</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-16-11-released/" rel="">GitLab 16.11</a></li></ul>]]></content>
        <author>
            <name>GitLab Japan Team</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/gitlab-japan-team/</uri>
        </author>
        <published>2026-04-16T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLab 18.11: GitLabクレジットの予算管理機能]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/gitlab-18-11-budget-guardrails-for-gitlab-credits/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/gitlab-18-11-budget-guardrails-for-gitlab-credits/"/>
        <updated>2026-04-16T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>GitLab Duo Agent PlatformをオンデマンドのGitLabクレジットとともに活用しているチームは、以前よりも速くリリースし、バグを早期に発見し、かつては数スプリントを要していた作業を自動化しています。しかし、導入が拡大するにつれ、財務・調達・プラットフォームの各チームから、AIへの支出が適切に管理され、予測可能で制御可能であることを示すよう求める声も高まっています。</p><p>AI導入拡大の最大の障壁は、テクノロジーへの懐疑心ではありません。支出管理に対する不安です。予算上限がなければ、忙しい月に予期しない費用が発生するリスクがあります。ユーザーごとの上限がなければ、一部のヘビーユーザーが月末前にチームのクレジットを使い切ってしまう可能性があります。どちらの仕組みもなければ、ソフトウェア開発においてエージェント型AIの活用を拡大したいエンジニアリングリーダーは、予算承認のために多くの手順を踏まなければなりません。</p><p><a href="https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-is-generally-available/" rel="">一般提供（GA）</a>の開始以来、GitLab Duo Agent Platformは利用状況のガバナンスと可視化の機能を提供してきました。GitLab 18.11では、<a href="https://about.gitlab.com/ja-jp/blog/introducing-gitlab-credits/" rel="">GitLabクレジット</a>の利用制御機能として、支出上限と予算ガードレールを新たに導入します。これにより、組織はクレジットの消費状況をさらに細かく管理し、透明性を高めることができます。</p><h2 id="gitlabクレジットの管理">GitLabクレジットの管理</h2><p>GitLab 18.11では、GitLabクレジットの消費を管理する3つの層を追加します。サブスクリプションレベルの支出上限、ユーザーごとのクレジット上限、そして上限の状態と適用状況の可視化です。</p><h3 id="サブスクリプションレベルの支出上限">サブスクリプションレベルの支出上限</h3><p>請求アカウントマネージャーは、サブスクリプション全体のオンデマンドGitLabクレジット消費に対して、月次の上限を設定できるようになりました。</p><p>設定の流れは次のとおりです。</p><ul><li><strong>上限の設定：</strong> サブスクリプションの「GitLabクレジット」設定にある<code className="">Customers Portal</code>で上限を設定します。</li><li><strong>支出上限の自動適用：</strong> オンデマンドの利用量が上限に達すると、次の月次期間が始まるまで、そのサブスクリプションの全ユーザーのDAP（Duo Agent Platform）アクセスが一時停止されます。</li><li><strong>柔軟な調整：</strong> 月の途中で上限を引き上げたり無効にしたりすることで、アクセスを復元できます。</li></ul><p>上限は月次期間ごとにリセットされ、変更しない限り設定した上限が引き継がれます。利用データはリアルタイムではなく定期的に同期されるため、上限に達してから適用が有効になるまでの間に、わずかな追加利用が発生する場合があります。詳しくは<a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/" rel="">GitLabクレジットのドキュメント</a>をご参照ください。</p><h3 id="ユーザーレベルの支出上限">ユーザーレベルの支出上限</h3><p>クレジットの消費量はユーザーによって異なります。これは想定の範囲内ですが、一部のヘビーユーザーがクレジットプールの大部分を占めると、他のメンバーが月末前にアクセスできなくなる可能性があります。</p><p>ユーザーごとのクレジット上限を設定することで、特定のユーザーが公平な上限を超えて消費することを防げます。</p><ul><li><strong>一律のユーザー上限：</strong> GitLab GraphQL APIを通じて、サブスクリプション上のすべてのユーザーに均一のクレジット上限を設定できます。サブスクリプションレベルの上限とは異なり、ユーザーごとの上限はすべてのクレジットソースにまたがる、そのユーザーの総消費量に適用されます。</li><li><strong>カスタムのユーザー個別オーバーライド：</strong> 差別化した上限が必要な組織向けに、GraphQL APIを通じて特定ユーザーに個別のクレジット上限を設定できます。たとえば、スタッフエンジニアには高めの割り当てを設定し、それ以外のメンバーには標準の上限を適用するといった運用が可能です。</li><li><strong>個別の適用：</strong> ユーザーが上限に達しても、GitLab全体へのアクセスは維持されます。停止されるのは、次の請求サイクルが始まるまでのDuo Agent Platformのクレジット利用のみです。他のユーザーは、自分自身の上限またはサブスクリプションレベルの上限のいずれか早い方に達するまで、中断なく作業を続けられます。</li></ul><h3 id="可視化と通知">可視化と通知</h3><p>サブスクリプションレベルの上限に達した場合、GitLabは請求アカウントマネージャーにメール通知を送信します。これにより、上限の引き上げ、次の期間まで待機、クレジットの再配分といった対応を速やかに行えます。</p><p>GitLab内では、グループオーナー（GitLab.com）とインスタンス管理者（Self-Managed）が、ユーザーごとの上限に達してブロックされたユーザーを確認し、GraphQL APIを通じて上限を調整することでアクセスを復元できます。</p><h2 id="予算ガードレールがai利用のスケールを支援する理由">予算ガードレールがAI利用のスケールを支援する理由</h2><p>組織がAI導入を加速させるにあたり、ガードレールは不可欠です。その理由を以下に説明します。</p><h3 id="予測可能なai予算">予測可能なAI予算</h3><p>GitLab Duo Agent Platformの利用制御機能は、オンデマンドのGitLabクレジットを活用することで、AIを予算として管理しやすい予測可能な支出項目に変えます。これにより、ソフトウェア開発ライフサイクル全体にわたってエージェントを展開しやすくなり、財務部門への説明、更新の正当化、四半期ごとの支出計画が容易になります。</p><h3 id="ガバナンスとチャージバック">ガバナンスとチャージバック</h3><p>大規模な組織では、AIの消費量を社内予算やコストセンター、部門方針と連携させる必要があります。ユーザーごとの上限は、プラットフォームチームがクレジットを公平に配分し、個人レベルで消費量を追跡するための明確な仕組みを提供します。APIによるインポート機能により、エンタープライズ規模での上限管理も現実的に行えます。GitLabクレジットダッシュボードのユーザーごとの利用データと組み合わせることで、消費パターンを把握し、社内のチャージバックや予算配分プロセスの参考にすることができます。</p><h3 id="スケールへの自信">スケールへの自信</h3><p>多くのお客様は、少人数のパイロットグループからGitLab Duo Agent Platformを始めます。利用制御機能は、そのパイロットを組織全体に拡大する際のリスクを排除します。予算を保護するハードな上限が設けられているため、数百人から数千人の開発者にDuo Agent Platformを展開しても安心です。想定より早く利用量が増加した場合でも、上限に達するだけで、予期しない請求は発生しません。</p><h2 id="シートベース課金と可視性の課題に向き合う">シートベース課金と可視性の課題に向き合う</h2><p>多くのAIコーディングツールは、コスト管理にシートベースのアプローチを採用しています。一定数のシートを定額のユーザー単価で購入する、シンプルながらも柔軟性に欠けるモデルです。開発者がツールを1日10回使っても、まったく使わなくても同じ料金を支払います。さらにベンダーがシート料金に加えてプレミアムモデルや超過料金を導入すると、シートベースのライセンスが約束していたコストの予測可能性が損なわれていきます。</p><p>GitLabは異なるアプローチを取っています。ハードな上限と一元化されたガバナンスダッシュボードを備えた従量課金制です。チームが実際に使った分だけ支払うという柔軟性と、強制力のある支出上限によるコストの予測可能性を両立しています。</p><h2 id="実際の利用制御シナリオ">実際の利用制御シナリオ</h2><p><strong>一例として、月次予算を守りたい中規模のSaaSカスタマーを挙げます。</strong> 200名のエンジニアリング組織が、オンデマンド利用の想定量に合わせたサブスクリプションレベルの上限を設定します。エンジニアリングVPは、新しいチームのオンボーディング中であっても、GitLab Duo Agent Platformの支出が承認済み金額を超えないことを財務部門に自信を持って説明できます。月の途中で上限に近づいた場合、請求アカウントマネージャーが通知を受け取り、上限を引き上げるか次の期間まで待つかを判断できます。</p><p><strong>GitLabでは、チーム間の利用を公平に保ちたい大企業とも多く連携しています。</strong> 開発者2,000名を擁するグローバルな金融サービス会社がユーザーごとの上限を活用し、公平なアクセスを確保しています。複雑なリファクタリングプロジェクトに取り組むスタッフエンジニアにはAPIを通じて高い個別割り当てを設定し、多くの開発者には標準の一律上限を適用しています。クレジットプールを使い切るユーザーはなく、プラットフォームチームはGitLabクレジットダッシュボードのユーザーごとの利用データを活用して消費パターンを把握し、四半期ごとの予算計画に役立てています。</p><h2 id="はじめ方">はじめ方</h2><p>利用制御機能は、GitLab 18.11を実行しているGitLab.comおよびSelf-Managedの両方のお客様にご利用いただけます。設定場所は、範囲とお客様の役割によって異なります。</p><p><strong>サブスクリプションレベルの上限</strong></p><p>請求アカウントマネージャーは、Customers PortalでサブスクリプションレベルのオンデマンドGitLabクレジット上限を設定します。</p><ol><li><code className="">Customers Portal</code>にサインインします。</li><li>サブスクリプションカードで<strong>GitLabクレジット</strong>の設定に移動します。</li><li>月次のオンデマンドクレジット上限を有効にし、希望する上限値を入力します。</li></ol><p><strong>一律のユーザー上限</strong></p><p>一律のユーザー上限は、名前空間オーナー（GitLab.com）またはインスタンス管理者（Self-Managed）がGitLab GraphQL APIを通じて設定できます。利用可能な設定方法の最新情報については、<a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/" rel="">GitLabクレジットのドキュメント</a>をご確認ください。</p><p><strong>カスタムのユーザー個別オーバーライド</strong></p><p>差別化した上限を設定する場合、名前空間オーナー（GitLab.com）とインスタンス管理者（Self-Managed）はプログラムで個別の上限を設定できます。これは自動化やInfrastructure as Codeのワークフローにも適しています。</p><p><strong>利用状況と上限のステータスを確認する</strong></p><ul><li><strong>Customers Portal：</strong> 詳細な利用状況と上限のステータスを確認できます。</li><li><strong>GitLab.com：</strong> グループオーナーは<strong>設定 &gt; GitLabクレジット</strong>でブロックされたユーザーを確認できます。</li><li><strong>Self-Managed：</strong> インスタンス管理者は<strong>管理 &gt; GitLabクレジット</strong>で上限のステータスとブロックされたユーザーを確認できます。</li></ul><h2 id="gitlab-duo-agent-platformはスケールの準備ができています">GitLab Duo Agent Platformはスケールの準備ができています</h2><p>利用制御機能はGitLab 18.11でご利用いただけます。組織全体にGitLab Duo Agent Platformを展開する前に適切なガードレールを待っていた方にとって、今がその時です。上限を設定し、より多くのチームにDuo Agent Platformを展開して、より速いリリースを実現しましょう！</p><blockquote><p><a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/" rel="">GitLabクレジットと利用制御の詳細はこちら</a>。</p></blockquote>]]></content>
        <author>
            <name>Bryan Rothwell</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/bryan-rothwell/</uri>
        </author>
        <published>2026-04-16T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[LLM利用率80%への道筋 ピクシブが実践した「People・Process・Technology」開発環境の三位一体の変革とは？]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/developers-summit-2026-spring-event-report/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/developers-summit-2026-spring-event-report/"/>
        <updated>2026-04-16T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>2026年2月、GitLabは「Developers Summit 2026」に出展しました。本イベントにてスタッフ・リージョナル・マーケティングマネージャー川口 修平が、ピクシブ社のプロダクト開発ギルド Unit Leadのbash様と講演をおこないましたので、本記事にてその模様をレポートします。本講演ではピクシブ社がLLM利用率80％を実現した道筋について、川口がbash様からお話を伺いました。</p><p><img alt="スタッフ・リージョナル・マーケティングマネージャー川口 修平" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300557/f5tilfouvx6il813daog.png" title="スタッフ・リージョナル・マーケティングマネージャー川口 修平" /></p><h3 id="ピクシブ社とは">ピクシブ社とは</h3><ul><li>創作プラットフォーム「pixiv」を中核としてさまざまな創作活動を楽しむための事業を展開</li><li>社員数約400名で、そのうち開発者は約230名、エンジニアは約170名</li></ul><h3 id="gitlabとは">GitLabとは</h3><ul><li>GitLabとは、AIネイティブDevSecOpsプラットフォーム</li><li>GitLabは100ヵ国以上100,000以上の組織、5,000万以上のユーザーが利用</li></ul><p><img alt="GitLabとは" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300556/x78nxrnwucp2aezdgiz4.png" /></p><h3 id="gitlab社とは">GitLab社とは</h3><ul><li>2,000名以上の従業員（66ヵ国以上）</li><li>オールリモート企業（世界中にオフィス無し）</li></ul><h2 id="beyond-the-code時代へ-ピクシブ社のなかで起きている変化とは">Beyond the code時代へ ピクシブ社のなかで起きている変化とは？</h2><p>Developers Summit 2026のテーマは「Beyond the Code」です。LLMの性能向上により、ソフトウェア開発における定型作業の自動化など、バックオフィスやプロダクト開発の現場での、業務が最適化されています。</p><p>そうしたなかで、ピクシブ社ではどのような変化が起きているか伺いました。</p><p>「現在のエンジニアリングにおいて、単にコードを書き出す作業（タイピング）の価値よりも、その背後にある設計思想や『なぜそれを作るのか』という思考の価値がより高まっています。</p><p>・背景をどう読み取り、なぜそのアプローチを選んだか<br />
・ほかにどんな選択肢があり、なぜそれをしなかったか</p><p>という思考プロセスが、より重要になってきています。</p><p>ピクシブ社内にエンジニアギルドという組織があり、そこでそういったプロセスを大事にすることを2018年から行なってきました。少し先手を打てたかなというところがあり、これに沿って成果を上げようとしています。」</p><h2 id="llm利用率80を実現ピクシブが実践したpeopleprocesstechnology三位一体の変革とは">LLM利用率80％を実現！ピクシブが実践した「People・Process・Technology」三位一体の変革とは？</h2><p><img alt="LLM利用率80％を実現！ピクシブが実践した「People・Process・Technology」三位一体の変革とは？" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300557/bf2q2iv8npbkrevn1nn5.jpg" title="ピクシブ社プロダクト開発ギルドUnit Lead、bash氏" /></p><p>ピクシブ社のこうした変化は、まさに「Beyond the Code」を体現したものです。このような変化に対応する際に避けて通れないのが「自分たちがまず変わること」だと思います。</p><p>けれど人は成功体験があったり確立されたプロセスがあったりすると、簡単に変わることはできません。そこで紹介したいのが、「People（人）、Process（プロセス）、Technology（テクノロジー）」というアプローチです。これは、まずTechnologyを抜本的に変え、それに合わせてProcessを整備し、それに応じてPeopleが変わっていくというアプローチになります。</p><p><img alt="「People（人）、Process（プロセス）、Technology（テクノロジー）」" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300553/ggrofuaaefmlz98fmf6h.png" /></p><p>GitLab社には、この変革実現アプローチでLLM時代に対応しているお客様が多くいらっしゃいます。ピクシブ社でも、同様のアプローチにてLLM利用率80％を達成されたとのことです。実際、どのようにして進められたのかをbash様に伺いました。</p><h3 id="_3つの要素が螺旋形に絡み合いながら進化してきた">3つの要素が螺旋形に絡み合いながら進化してきた</h3><p>「我々の変革は線形に進んできたわけではありません。それぞれの要素が螺旋形に絡み合いながら進化してきました。</p><p>たとえば新しい技術を選定すると、人の行動が変わります。それに合わせて仕組みも変わってきて、そうこうしているうちに、次の新しい技術やバージョンが進展し、さらに変容するといった感じです。こういった相互作用を生み出しながら動いてきたのが実際のところです。</p><p>こうした変革の成果として、LLM利用率80％・社内満足度90％・活用意欲向上95％を達成しました。」</p><p><img alt="3つの要素が螺旋形に絡み合いながら進化してきた" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300555/e5flajpmbn4jufsjgvkj.png" /></p><p>ピクシブ社のLLM利用率80％という成果は、従業員各自が勝手にLLMを使ったというデータではありません。会社が決めたLLMを会社が決めたルールに沿って使った成果であり、そう考えるとLLM利用率80％というのは非常に素晴らしいです。</p><p>ここからはLLM利用率80％という成果を、People・Process・Technologyという3つの観点でどう達成されたかを伺います。</p><h3 id="technologyの変革-gitlab-ultimate有償版の導入へ">Technologyの変革 | GitLab Ultimate有償版の導入へ</h3><p><img alt="Technologyの変革 | GitLab Ultimate有償版の導入へ" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300553/pem3xgd49evviusemriy.png" /></p><p>まずはTechnologyの変革について、bash様に時系列で教えていただきました。</p><p>「まず2013年にGitLabをGUI付きGitサーバーとして導入しました。2024年に大きな転換点がありGitLab Ultimateを導入し、SDLC（ソフトウェア開発ライフサイクル）をEnd to Endでカバーする基盤として本格的に整備を開始しています。</p><p>また、セキュリティスキャンや開発のバリューストリームの可視化などを実装し、それと両輪みたいなかたちでLLMの活用も開始しました。」</p><h4 id="gitlabを選定した理由">GitLabを選定した理由</h4><p>次にGitLabを選定した理由について伺いました。</p><p>「ツールチェーンvsプラットフォームがひとつの論点になりました。そのなかでツールチェーンと比べGitLabならコストを圧縮できるうえ、ライフサイクルを一貫して全体最適を狙いやすいという結論が出たのです。</p><p>ブラックボックス的なベンダーロックインにならないこともポイントでした。そのほか、セルフマネージメントで、必要に応じバッチをあてたりバージョンアップしたりできるという柔軟性も決め手になっています。」</p><h4 id="gitlab導入によるツールチェーンの解消">GitLab導入によるツールチェーンの解消</h4><p><img alt="GitLab導入によるツールチェーンの解消" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776217764/k59vea5wbi5ck5uuf56g.png" /></p><p>GitLabを選定いただく理由として、ツールチェーン解消というポイントはよく挙げられます。そこで、ツールチェーンを運用するなかでの苦労について、bash様に伺いました。</p><p>「エンジニア個人としては、ツール選びは楽しいですし自分にフィットする良いものを選びたいという気持ちはあります。そういったジレンマと戦う必要がある点が苦労ですね。</p><p>組織レベルに引き上げて考えると、ツールチェーンに含まれるプロダクトはたくさんあります。これらをそれぞれで選定していると、契約上のスケールメリットが乏しくなるのです。小口契約ですと既成プランしか選択肢にならず、大口だとできるような大きな相談ができなくなりますからね。</p><p>また社内で使うツールのフラグメントがあると、メンバー異動が大変だったり、キャッチアップが難しかったり問題がどんどん出てきます。実用の苦労としては、個人・チームレベル・組織全体の最適が少しずつずれてくるという点がありますね。</p><p>さらに、ツールチェーンでやるといろいろ選べるので、ところどころ入れ替えが難しい。意図せぬシャドーIT化だったり、外部ソリューションに頼るべきところを自分たちで作り込んでしまったりといった問題も発生します。」</p><p>反対にプラットフォームのメリットについてうかがったところ、bash様は次のように話されました。</p><p>「全体最適を追求しやすかったり、組織レベルでマクロの成果を見定めやすかったりする点が魅力ですね。ここで鍵となるのが人です。人をプラットフォームに寄せる必要が出てきて、ここが重要なポイントであり難しい点ですね。」</p><h4 id="gitlab-ultimateを導入しセキュリティ対策に着手した背景">GitLab Ultimateを導入しセキュリティ対策に着手した背景</h4><p><img alt="GitLab Ultimateを導入しセキュリティ対策に着手した背景" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776217764/fq6ihuwnobueybhkxbro.png" /></p><p>次にGitLab Ultimate導入によるセキュリティ対策に着手した背景について、bash様に伺いました。</p><p>「安全性・堅牢性を高めるためセキュリティが重要なのはもちろんですが、開発ライフサイクルとしても、インシデントはペースを乱す要素です。我々の開発体制は、運用とばらばらではありません。</p><p>プロダクトを作って運用して、動かして維持してというのをホールチーム体制で続けているので、インシデントは開発時でも重要なイシューです。コードpush時のCIでは防げないサプライチェーンアタックや、外部要因で突然脆弱性が問題になることがあります。こういった問題を回避し、ホールチーム体制での開発継続性を大事にしたかったのです。」</p><h4 id="gitlab-ultimateを活用したピクシブのセキュリティ対策">GitLab Ultimateを活用したピクシブのセキュリティ対策</h4><p>LLMの利用にあたって、セキュリティ脆弱性は重大な課題になります。IPAが毎年出しているレポートによれば、「2025年の企業におけるセキュリティ脅威 Top10」の第4位が「システムの脆弱性を悪用した攻撃」でした。またLLMが生成したコードについては、その45％に脆弱性が含まれているという調査もあります。</p><p>こうしたなかで、ピクシブがどのようなセキュリティ対策を行っているか伺いました。</p><p><img alt="GitLab Ultimateを活用したピクシブのセキュリティ対策" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300558/zetxd9f9q7uwnfu05xe7.png" /></p><p>「いろいろあります。マージリクエストを実行する際、常に機械チェックをかけています。あとメインブランチを常にリリース可能な状態にしており、そこにあるソースコードに対し常にセキュリティスキャンをかけている状況です。ほかにもIaC構築や権限分離、レビュー・テスト・ライブラリ管理・アップデートなど、基本的な対策を忠実に行っています。</p><p>ただ、セキュリティは果てのない戦いなので、もう大丈夫とかもう十分な水準ということはありません。日々、改善し続けるためみんなで頑張っているという状況です。」</p><p>ピクシブが行っているのはリリース前のセキュリティスキャンだけ（DevOps+Sec）ではありません。開発サイクル全体でセキュリティスキャンが常に行われている状態（DevSecOps）です。</p><p>このように堅牢な体制があるからこそ、ピクシブでは自由にできる面もあるとのことでした。具体的に、どのようなことを自由に行えているのかbash様に伺いました。</p><p>「たとえば開発者が自分にとって使いやすいIDEやツールを選べるように、複数の選択肢を設けています。また業務用PCも、ベンダーもスペックも自由にアレンジできる制度を長く運用している状況です。全体最適化を狙いつつ、各個人にあったツールを使っていこうという裁量の幅も設けています。」</p><h3 id="processの変革-組織体制の整備">Processの変革 |　①組織体制の整備</h3><p><img alt="Processの変革 |　①組織体制の整備" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300559/ezjeke9kibifmm9znk29.png" /></p><p>次にProcessの変革についてbash様に伺いました。</p><p>「まず組織体制の整備は欠かせません。LLM活用の取り組みは経営層と連携し、全社的に行わなければなかなか進まないと思います。各組織がそれぞれ単独で頑張っても難しいので、CTOの牽引力がキーとなり組織として横断的に推進する体制を整えました。</p><p>開発サイクル全体でみるとCOE（Center of Excellence）を設置し、プロダクトを横断する関心事として進めています。LLMについては、組織の技術推進という文脈で専任部署が中心となって取り組みを進めた感じです。</p><p>トップダウンでガイドラインを示し、LLMを活用しようというメッセージを出しました。一方で現場は自律的に、現場に即したものをどんどん活用し盛り上げています。トップダウンとボトムアップの両面から、推進しているという感じですね。」</p><h3 id="processの変革-sdlcの整備">Processの変革 |　②SDLCの整備</h3><p>「Processの変革について、2点目はSDLCの整備ということで、開発サイクルの健康診断を実施しました。パフォーマンスチューニングにプロファイリングが必要なように、『計測なくして改善なし』です。</p><p>その結果、わかりやすいボトルネック工程があったわけでなく、複合的な問題が複数見つかりました。それに合わせた次の取り組みを考えていこうという状況です。」</p><p>bash様がお話しされた「開発サイクルの健康診断」というキーワードは、まさにGitLabの特徴を表しています。GitLabは、開発サイクル全体のデータがひとつのプラットフォームに集約されるので、その一元化されたデータに基づいた生産性の可視化をすることができます。この可視化された生産性に基づいて開発サイクルの健康診断を実施されたとのことでした。</p><h3 id="processの変革-評価制度の整備">Processの変革 |　③評価制度の整備</h3><p>「Processの変革について、3つ目は評価制度の整備です。特に新しい評価制度を作ったわけでなく、生産性指標を評価に使うなという話はずっとしています。</p><p>これはよくあるアンチパターンとして、生産性指標を評価に用いることでうまくいかなくなるというのはよく聞いていました。うまくいかないことをペナルティと捉えてしまったりとか、『なぜそうなったか』を詰めたりするのは本当によくありません。</p><p>生産性指標はあくまで改善のための情報であり、人を評価査定するための道具でないとはよく言っています。」</p><p>Processの変革について最後に、社内で好意的に受け止められたかをbash様に伺いました。</p><p>「好意的というか『うまくいったらいいね』と、温かい目で見守ってくれた感じです。</p><p>私としても、これがみんなの飛びつくような高関心領域になるとまで期待していません。ただ『ちょっと手間をかけるといっぱいいいことがある』という風に思ってもらえたら上々だな、と考えています。」</p><h3 id="peopleの変革-whole-teamカルチャー醸成">Peopleの変革 | ①Whole Teamカルチャー醸成</h3><p>最後にPeopleの変革についてbash様に伺いました。</p><p>「ひとつ目は『Whole Team』カルチャーの醸成です。ひとつのチームとしてプロダクトに関する責任を持つことで、職種や役割を超えた相互支援ができます。</p><p>品質・セキュリティ・パフォーマンスなど、推進担当の仕事にしてしまうのでなく、自分たちの仕事という意識をもつのです。そうしてCoEがそれを支援する、というのを前提にします。」</p><h3 id="peopleの変革-llmの性能を最大化する環境への配慮">Peopleの変革 | ②LLMの性能を最大化する環境への配慮</h3><p>「次に、LLMを開発を支える強力なツールと捉え、性能を最大限に引き出せるよう、情報の整理の仕方（コンテキストの渡し方）を工夫することです。これまで人間が読むための情報としてまとめてきたコンテキストを、これからはLLMも読みやすくしなければならないという風に考え方を転換します。そうしてコンテキストを、LLMが処理できる組織知としての情報にするのです。」</p><h3 id="peopleの変革-強い意志と責任感">Peopleの変革 | ③強い意志と責任感</h3><p>「3つ目は強い意志と責任感です。『LLMがこう出力したから』は理由になりません。自分の責任として『なぜ』を突き詰めるのです。</p><p>前述したエンジニアギルドというところの活動で、『なぜそれをするのか』を考える習慣をエンジニア全員に頑張って根付かせてきました。こういった活動も役立っているなと思います。」</p><h3 id="採用について工夫していること">採用について工夫していること</h3><p>入ってくる方にどういった素質があれば、ピクシブのこういった環境に適応できるのでしょうか。bash様に採用で重視する点を伺いました。</p><p>「ミッションへのコミットメントをベースに、組織・事業・プロダクト・システムなどみんなで作っていくことについて大事にしていますね。」</p><h2 id="ピクシブが目指すbeyond-the-code時代におけるあるべきエンジニア像とは">ピクシブが目指すBeyond the code時代におけるあるべきエンジニア像とは？</h2><p><img alt="ピクシブが目指すBeyond the code時代におけるあるべきエンジニア像とは？" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300556/y8ceh3zywuayp0bvhwmo.jpg" /></p><p>最後にピクシブが目指すBeyond the code時代におけるエンジニア像を伺いました。</p><p>「エンジニアとはエンジニアリングを行う職種で、エンジニアリングとは、再現可能なプロセスを確立して継続することだと考えています。</p><p>確かにコードを書ける能力は重要で、我々もエンジニアに求めるところです。エンジニア職といっても、インフラエンジニア、社内ライフエンジニア、開発エンジニアなどたくさんの役割がありますが、コードを通じて対話をする基礎能力は、どのエンジニアであれ役割であれ共通です。</p><p>もちろん全員が常にコードを書くわけではありませんし、役割ごとに業務も違います。ただし問題をどう解釈しどんな手段で解決するか、という判断基準は共通であるべきです。なぜそれをしてなぜほかのやり方を取らなかったのか、を説明する責任はどのエンジニアにもあります。</p><p>コードを書かないことの先にあるものを、今まで大事にしてきました。今後もそれを大事にして、まぐれ当たりでない再現可能なプロセスを積み重ねていく本質追求の姿勢が、エンジニアにとって重要だと考えます。」</p><h2 id="まとめ">まとめ</h2><p>本講演ではピクシブがLLM利用率を48％から80％へ、わずか1年で拡大させた変革の全体像をお話いただきました。ピクシブは、Technology、Process、Peopleという3つの要素を三位一体で変革してきたとのことです。</p><p>Technologyの変革ではツールチェーンをGitLabに統合し、プロセス全体にセキュリティを組み込むなどしてLLM活用の土台として整備しました。</p><p>Processの変革では経営と連携し、全社プロジェクトとしてCOEを立ち上げたとのことです。そうしてソフトウェア開発ライフサイクル全体を可視化し、守るべきガイドラインを示し、そのうえで評価制度を整備しました。</p><p>最後にPeopleの変革では、Whole Teamカルチャーを醸成して、ひとつの目標を共有して全員で助け合う文化を根付かせたとのことです。そうしてLLMの性能を最大化するための配慮をしました。</p><p>ピクシブでは、この3つを変革することで、Beyond the code時代の変化に対応していったということです。今回のお話が皆様のヒントになれば幸いでございます。</p><p><img alt="ノベルティのシール" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300557/actim4eue89tuftgp1gj.jpg" title="ノベルティのシール" /></p><blockquote><p>生産性のオーバーヘッドを極小化する開発支援ツール戦略を加速。<a href="https://about.gitlab.com/ja-jp/blog/epic-tokyo-2025-pixiv/" rel="">お客様事例：ピクシブ</a>を読む</p></blockquote>]]></content>
        <author>
            <name>GitLab Japan Team</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/gitlab-japan-team/</uri>
        </author>
        <published>2026-04-16T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[Claude Opus 4.7がGitLab Duo Agent Platformで利用可能になりました]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/claude-opus-4-7-is-now-available-in-gitlab-duo-agent-platform/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/claude-opus-4-7-is-now-available-in-gitlab-duo-agent-platform/"/>
        <updated>2026-04-16T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p><a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/" rel="">GitLab Duo Agent Platform</a>が、Anthropicの最新モデルである<a href="https://www.anthropic.com/news/claude-opus-4-7" rel="">Claude Opus 4.7</a>をサポートしました。本日より、<a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/context/#gitlab-duo-agentic-chat" rel="">Agentic Chat</a>でのモデル選択や、GitLabインスタンス全体のエージェント型ワークフローでご利用いただけます。</p><p>ソフトウェアデリバリーライフサイクル全体でエージェントを活用しているチームにとって、Opus 4.7は最も重要なタスク、すなわち継続的な推論と正確な指示遵守、そして結果を返す前に自身の出力を検証する能力が求められる、複雑なマルチステップ作業において、大きな改善をもたらします。</p><h2 id="あらゆるエージェントワークフローで推論能力が強化">あらゆるエージェントワークフローで推論能力が強化</h2><p>最も大きな向上は、難易度の高い長時間の作業をOpus 4.7がいかに処理するかという点です。GitLabの社内評価では、Sonnet 4.6およびOpus 4.6の両方を上回るパフォーマンスが確認されました。この組み合わせは、複合的なエラーが大きなコストにつながる、CI/CDパイプライン、コードレビュー、脆弱性解消、その他のマルチツールワークフローにおいて、エージェントがより効率的に動作することに直結します。</p><p>エージェントワークフローを確立しているチームは、Opus 4.7が以前のモデルより正確に指示を解釈する点にご注目ください。これにより、複雑な条件付きタスクをより忠実に実行できます。たとえば、マルチステップの修正シーケンスを処理するエージェントは、各ステップを指定どおりに完了するため、予測可能で監査しやすい結果をチームにもたらします。</p><h2 id="エージェントがコードから本番環境への作業を前進させる">エージェントがコードから本番環境への作業を前進させる</h2><p>ソフトウェア開発ライフサイクルのあらゆる段階に組み込まれたエージェントの可能性は、作業が人の手を待つことなく前進し続けることにあります。Opus 4.7は、その可能性を実際に、より確実なものにします。</p><p>コード生成とテスト作成の段階では、Opus 4.7が結果を返す前に自身の出力を検証する能力により、エージェントはより大きな恩恵を受けます。やり取りの回数が減り、反復速度が上がり、開発者の集中を妨げる割り込みも少なくなります。セキュリティと脆弱性のワークフローでは、指示遵守の精度向上により、エージェントはマルチステップの修正シーケンスを最後までやり遂げ、途中での軌道修正が不要になります。</p><p>CI/CDにおいて、パイプラインの失敗はチーム全体のボトルネックになりかねませんが、ここでOpus 4.7の長期的な一貫性が最も威力を発揮します。失敗を調査し、ログを分析し、修正案を提案するエージェントは、実行途中でコンテキストを失うことなく、一連の作業を首尾一貫して処理します。問題はエスカレーションされるのではなく、解決されます。</p><p>GitLab Duo Agent Platformは、こうした段階を設計上連携させています。Opus 4.7は、それらすべてを横断する知能レイヤーを強化します。これにより、計画・開発・セキュリティ・デプロイメントをまたいで連携するエージェントが、あらゆる引き継ぎ地点で、より高い能力を持つモデルによる意思決定の恩恵を受けられます。</p><h2 id="料金と利用方法">料金と利用方法</h2><p>Claude Opus 4.7は、<a href="https://docs.gitlab.com/ja-jp/administration/gitlab_duo/model_selection/" rel="">モデル選択</a>よりGitLab Duo Agent Platformで本日から利用可能です。Duo Agent Platformで利用可能なモデルの一覧とクレジット消費量については、<a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#models" rel="">ドキュメント</a>をご参照ください。</p><p>GitLab Duo Agent Platformの<a href="https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/" rel="">無料トライアル</a>を今すぐ開始できます。GitLabの無料プランをご利用中の場合は、<a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom" rel="">こちらの手順</a>に従って、数ステップでDuo Agent Platformにサインアップできます。</p><p>GitLab PremiumまたはUltimateの既存サブスクライバーの方は、<a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/turn_on_off/" rel="">Duo Agent Platformをオンに</a>するだけで、サブスクリプションに<a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#included-credits" rel="">含まれている</a>GitLabクレジットをすぐにご利用いただけます。</p><p><em>このブログポストには、改正証券法第27A条および改正証券取引所法第21E条の意味における将来の見通しに関する記述が含まれています。これらの記述に反映された期待は合理的であると考えていますが、実際の結果や成果が重大に異なる可能性のある既知・未知のリスク、不確実性、前提、その他の要因に左右されます。これらのリスクおよびその他の要因の詳細については、SECへの提出書類の「リスク要因」の見出しをご参照ください。当社は、法律で義務付けられている場合を除き、このブログポストの日付以降にこれらの記述を更新または修正する義務を負いません。</em></p>]]></content>
        <author>
            <name>Rebecca Carter</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/rebecca-carter/</uri>
        </author>
        <published>2026-04-16T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLab 18.11：CI エキスパートとデータアナリストAIエージェントで開発ギャップを解消]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/ci-expert-and-data-analyst-ai-agents-target-development-gaps/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/ci-expert-and-data-analyst-ai-agents-target-development-gaps/"/>
        <updated>2026-04-16T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>AIが生成するコードは、それを取り巻く仕組みが追いつけないほどのスピードで増え続けています。 コードが増えれば、レビュー待ちのマージリクエストが積み重なり、設定すべきパイプラインが増え、デリバリーの状況について誰も答える時間がないまま疑問だけが蓄積されていきます。 そして、現在チームが使っているほとんどのツールは、このペースに対応できるように設計されていません。</p><p>GitLab 18.11では、AIがほとんど手をつけてこなかった開発ライフサイクルの特定のギャップに対処するため、Duo Agent Platform向けの2つの新しい基盤エージェントが登場します。</p><ul><li>CI エキスパートエージェント（ベータ版）は、コードを書き終えてから実際にパイプラインを動かすまでの間に生じるギャップを解消します。</li><li>データアナリストエージェント（一般提供開始）は、コードをリリースした後、そのデリバリーの実態を把握しようとする際に生じるギャップを解消します。</li></ul><p>これらは、汎用アシスタントでは解決できない課題領域です。GitLabの外で動くツールでも、YAMLファイルを生成したり質問に答えたりすることはできます。しかし、これまでのパイプラインのパフォーマンス、障害が集中する箇所、実際のMRサイクルタイムといったコンテキストは持ち合わせていません。そうしたコンテキストはGitLabの中にあります。これらのエージェントも同様です。</p><h2 id="ci-エキスパートエージェントで素早くciをセットアップ">CI エキスパートエージェントで素早くCIをセットアップ</h2><p>AIによってコードを書くこと自体はこれまでになく簡単になりました。しかし、そのコードを実際に動くパイプラインに乗せるまでのプロセスは、多くのチームにとって数日、あるいは数週間後の課題として残ったまま—もしくは永遠に後回しにされています。空白のページという問題は、エディターの中にはもうありません。今や <code className="">.gitlab-ci.yml</code> の中にあります。</p><p>CI設定の経験がない開発者は、YAMLでの言語検出の書き方も、適切なテストコマンドの指定方法も、プッシュ前に結果を検証する手順も知りません。チームは過去のプロジェクトから設定をコピーしてくるか（それが今の状況に合っていなくても）、ドキュメントをつなぎ合わせるか、以前に経験したことのある一人の担当者を待つしかない状況になりがちです。その担当者が不在であれば、CIは「後でやる」課題になります。そして「後で」は「永遠にやらない」になります。</p><p>CIが実装されないまま放置されると、その影響はあらゆる場所に現れます。変更は信頼性のある安全網なしにリリースされ、リグレッションはパイプラインではなく本番環境で発覚し、誰も「ビルドを壊した人」と呼ばれたくないために変更が大きく危険なバッチへと膨らんでいきます。やがてチームは暗闇の中で作業することを当然のこととして受け入れるようになり、ドキュメント化されていないノウハウや場当たり的なテストに頼るようになります。すべての変更に組み込まれた、速くて予測可能なフィードバックループとはほど遠い状態です。</p><p>ベータ版として提供開始となったCI エキスパートエージェントは、そうした摩擦を取り除きます。リポジトリを検査し、使用言語とフレームワークを特定した上で、実際の構成に合わせたビルドとテストのパイプラインを提案—そして Agentic Chat上でわかりやすい言葉で各判断の理由を説明します。目標は、手でYAMLを書くことなく、数分でパイプラインを稼働させることです。</p><p>CI エキスパートエージェントの機能：</p><ul><li>リポジトリを認識したパイプライン生成：言語、フレームワーク、テスト設定を自動検出</li><li>有効で実行可能なビルド・テスト設定を生成</li><li>Agentic Chat上で各ステップをわかりやすく説明する、初めてのパイプライン構築ガイド付きフロー</li><li>設定の変換なしに使えるネイティブのGitLab CI セマンティクス</li></ul><p>GitLabの内部で動作し、実際のパイプラインの動作履歴にアクセスできるため、改善のたびにチームの実際の作業パターンを学習し、静的なサンプルだけに頼ることがありません。</p><iframe src="https://player.vimeo.com/video/1183458036?badge=0&amp;autopause=0&amp;player_id=0&amp;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="CI/CD Expert Agent"></iframe><script src="https://player.vimeo.com/api/player.js"></script><br /><br /><p>CI エキスパートエージェントは、Duo Agent Platformが有効な環境において、GitLab.com、セルフマネージド、Dedicatedのいずれでも、Free、Premium、Ultimateの各エディションでご利用いただけます。</p><h2 id="データアナリストエージェントで自然言語によるgitlab-データのクエリを実現">データアナリストエージェントで自然言語によるGitLab データのクエリを実現</h2><p>AIはチームのリリーススピードを上げました。しかし、その作業の進捗状況に関する基本的な疑問への回答は、以前よりもむしろ難しくなっています。</p><p>MRはレビューにどれくらい滞留しているか？どのパイプラインがチームの足を引っ張っているか？デプロイ目標は実際に達成されているか？かつてはダッシュボードをちらりと見るだけで答えられた問いです。しかし今や、コードもチームも複雑さも増した結果、データはGitLabの中に存在するにもかかわらず、アクセスするにはアナリティクスチームへの依頼、ダッシュボードリクエストの提出、あるいはGLQLの習得が必要になっています。</p><p>データアナリストエージェントはそのギャップを解消します。自然言語で質問するだけで、Agentic Chat上に即座に可視化された回答が返ってきます。クエリ言語も不要、ダッシュボードのリクエスト提出も不要、誰かが回答をまとめるまで待つことも不要です。</p><p>例えば、このエージェントは以下のようなロールに対して、次のようなトピックに関する問いに回答できます。</p><ul><li>エンジニアリングマネージャー：MRサイクルタイム、プロジェクト別スループット、レビューが止まる箇所</li><li>開発者：コントリビューションパターン、自分のMRをブロックしているフラッキーテスト、パイプラインのスピードトレンド</li><li>DevOpsおよびプラットフォームエンジニア：パイプラインの成功/失敗率、ランナーの使用率、デプロイ頻度</li><li>エンジニアリングリーダーシップ：ポートフォリオ横断のデプロイ頻度、プロジェクトの健全性メトリクス、リードタイムの比較</li></ul><p>18.11で一般提供開始となったこのエージェントは、MR、課題、プロジェクト、パイプライン、ジョブをカバーし、ベータ版から対象範囲が拡大してソフトウェア開発ライフサイクル全体をカバーします。データアナリストエージェントはGitLabの既存データに対してクエリを実行するため、コンテキストは常に最新の状態に保たれ、メンテナンスが必要な外部パイプラインや同期を維持すべきサードパーティツールも不要です。生成されたGitLab Query Language（GLQL）クエリはコピーしてGitLab Flavored Markdownがサポートされる場所ならどこでも使用でき、ワークアイテムやダッシュボードへの直接エクスポートもロードマップに予定されています。</p><iframe src="https://player.vimeo.com/video/1183094817?badge=0&amp;autopause=0&amp;player_id=0&amp;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="Data Analyst agent demo"></iframe><script src="https://player.vimeo.com/api/player.js"></script><br /><br /><p>データアナリストエージェントは、Duo Agent Platformが有効な環境において、GitLab.com、セルフマネージド、DedicatedのいずれでもFree、Premium、Ultimateの各エディションでご利用いただけます。</p><h2 id="_1つのプラットフォームつながったコンテキスト">1つのプラットフォーム、つながったコンテキスト</h2><p>両エージェントはGitLabの内部で動作し、すでにそこにあるコード、パイプライン、課題、マージリクエストへのアクセスを持ちます。それが、プラットフォームネイティブのAIと切り離されたアシスタントとの違いです。コンテキストは常に最新に保たれ、使えば使うほど有用性が増していきます。CI エキスパートエージェントとデータアナリストエージェントは、AIがコードを速く書く手助けをするだけでなく、作り上げたものを理解し、リリースし、維持するためのプラットフォームに向けた、具体的な2つの前進を体現しています。</p><blockquote><p><a href="https://about.gitlab.com/ja-jp/gitlab-duo/" rel="">GitLab Duo Agent Platformの無料トライアルを開始</a>して、これらの基盤AIエージェントをぜひ体験してください。</p></blockquote>]]></content>
        <author>
            <name>Corinne Dent</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/corinne-dent/</uri>
        </author>
        <published>2026-04-16T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLab 18.11：マージ可能なAIコード修正で脆弱性修正を自動化]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/automate-remediation-with-ready-to-merge-ai-code-fixes/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/automate-remediation-with-ready-to-merge-ai-code-fixes/"/>
        <updated>2026-04-16T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>AIはどのセキュリティチームがレビューできるよりも速くコードを生成しています。かつては管理可能だった静的アプリケーションセキュリティテスト（SAST）の脆弱性バックログは、今や解析が困難なほど膨大なリストへと膨れ上がっています。デベロッパーが1件ずつ手作業で調査・修正することを期待するのは、プロセスとは言えません。それはボトルネックです。答えは人的労力を増やすことではなく、自律型パイプラインです。GitLab Duo Agent Platform内の<a href="https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/agentic_vulnerability_resolution/" rel="">Agentic SAST脆弱性解決機能</a>は、まさにその課題のために構築されました。</p><p>一般提供（GA）となったAgentic SAST脆弱性解決機能は、SAST脆弱性を修正するマージ可能なコードフィックスを自動生成します。この機能により：</p><ul><li>デベロッパーはフローを維持できます</li><li>脆弱性は本番環境に到達する前に解決されます</li><li>AppSecチームはトリアージと、修正完了の確認のためにデベロッパーを追いかける時間を削減できます</li></ul><p>Agentic SAST脆弱性解決機能は、アプリケーションセキュリティの未来形です。GitLab 18.11はさらに、より高速なSASTスキャン、スマートな優先順位付け、プラットフォーム全体にわたる強力なガバナンスも提供します。</p><h2 id="フローを維持したまま自動修正">フローを維持したまま自動修正</h2><p>AIがコードを大規模に生成するようになると、状況が一変します。かつて線形に増加していたセキュリティバックログは、AIアシストによるコミットのたびに複利で積み重なります。デベロッパーに頭の切り替えを強いて手動で脆弱性を修正させ続けるだけでは、この問題は解決しません。<a href="https://about.gitlab.com/ja-jp/resources/developer-survey/" rel="">GitLabの2025 DevSecOpsレポート</a>によると、デベロッパーはすでに月あたり11時間を、リリース後の脆弱性修正（つまり、新しい機能の開発ではなく、すでに本番環境で悪用可能な問題の対処）に費やしています。</p><p>Agentic SAST脆弱性解決機能は、そのサイクルの経済性を変えます。SASTスキャンが完了すると、検出結果が自動的に<a href="https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/false_positive_detection/" rel="">SAST誤検出検知</a>フローを開始します。真陽性と確認されたものは直接Agentic SAST脆弱性解決フローへと送られ、GitLab Duo Agent Platformが以下を実行します：</p><ul><li>脆弱性をコンテキストを踏まえて分析</li><li>根本原因に対処する修正を生成</li><li>自動テストによって修正を検証</li></ul><p>デベロッパーは信頼スコア付きのマージ可能なマージリクエストを受け取り、脆弱性の修正方法について十分な情報に基づいた判断を下せます。スプリントはスケジュール通りに進み、デベロッパーはフローを維持し、脆弱性は本番環境に到達する前に解決されます。</p><p>ソフトウェア開発の加速は、スキャナーの待ち時間をなくすことも意味します。GitLab 18.11では<a href="https://docs.gitlab.com/ja-jp/user/application_security/sast/gitlab_advanced_sast/#incremental-scanning" rel="">Advanced SASTのインクリメンタルスキャン</a>が導入され、デベロッパーはフルスキャンの完了を待たずに脆弱性の結果を確認でき、パイプラインも止まりません。</p><iframe src="https://player.vimeo.com/video/1183195999?badge=0&amp;autopause=0&amp;player_id=0&amp;app_id=58479%2Fembed" allow="autoplay; fullscreen; picture-in-picture" allowFullScreen frameBorder="0" style="position:absolute;top:0;left:0;width:100%;height:100%;"></iframe><h2 id="スコアではなくビジネスリスクで修正の優先順位を決める">スコアではなく、ビジネスリスクで修正の優先順位を決める</h2><p>自律型修正が機能するのは、その判断の根拠となるシグナルが信頼できる場合に限ります。重大度スコアが実際の悪用可能性を反映していない場合、デベロッパーはシグナルを信頼しなくなり、無視し始めます。</p><p>GitLab 18.11は、この問題に4つのレベルで対処します。まず、<a href="https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/severities/#critical-severity" rel="">脆弱性スコア</a>が現在最も新しい業界標準であるCVSS 4.0に基づくようになりました。より細かい指標によって実際の悪用可能性が的確に評価されます。GitLabに表示されるスコアは、現実世界のリスクを測る現行の業界標準を反映しています。</p><p>次に、AppSecチームは<a href="https://docs.gitlab.com/ja-jp/user/application_security/policies/vulnerability_management_policy/#severity-override-policies" rel="">ポリシーベースのルール</a>を定義でき、CVE（共通脆弱性識別子）、CWE（共通脆弱性タイプ一覧）、ファイルパス/ディレクトリなどのシグナルに基づいて脆弱性の重大度スコアを自動的に調整できます。ポリシーが設定されると、重大度の上書きがただちに適用されるため、デベロッパーはスキャナーの生データではなく、実際のビジネスリスクを反映したバックログをもとに作業できます。</p><p>リスクベースの適用はバックログにとどまりません。AppSecチームは、KEV（既知の悪用脆弱性）ステータスやEPSS（悪用予測スコアリングシステム）スコアのしきい値に基づいてマージをブロックまたは警告する<a href="https://docs.gitlab.com/ja-jp/user/application_security/policies/merge_request_approval_policies/#vulnerability_attributes-object" rel="">承認ポリシー</a>を設定できます。マージがブロックされた際、デベロッパーはその脆弱性が自分の環境を考慮していないスコアではなく、現実世界の悪用可能性データに基づいていることを把握できます。</p><p>最後に、<a href="https://docs.gitlab.com/ja-jp/user/application_security/security_dashboard/#top-10-cwes" rel="">新しい「上位CWE」セキュリティダッシュボードチャート</a>により、プロジェクト全体でどの脆弱性クラスが最も頻繁に出現しているかを把握できます。個々の検出結果を追いかけるのではなく、パターンを特定し、根本原因レベルで優先順位を付け、複利的に積み重なる前にシステム的なリスクに対処できます。</p><h2 id="運用オーバーヘッドを抑えながらセキュリティコントロールを強化">運用オーバーヘッドを抑えながらセキュリティコントロールを強化</h2><p>自律型修正パイプラインの品質は、その下支えとなるセキュリティスキャナーのカバレッジに依存します。スキャナーの適用が一貫していなければ、パイプラインに流れ込む検出結果は不完全となり、修正も同様に不完全になります。</p><p>GitLab 18.11では、<a href="https://docs.gitlab.com/ja-jp/user/permissions/#default-roles" rel="">Security Manager</a>という、セキュリティ担当者向けに特化して設計された新しいデフォルトロールが導入されます。Security Managerロールにより、セキュリティチームはコードの変更やデプロイ権限なしに、セキュリティスキャナーの適用、セキュリティポリシーの定義と設定、脆弱性のトリアージ・修正ワークフローの管理、コンプライアンスフレームワークと監査ストリームの維持が可能になります。セキュリティチームは業務に必要なアクセス権のみを持ち、コードとデプロイの権限はデベロッパーに維持されます。</p><p>AppSecチームにとって、複数のプロジェクトとグループにわたって一貫したSASTスキャナーのカバレッジを確保することが、大幅に容易になりました。<a href="https://docs.gitlab.com/ja-jp/user/application_security/configuration/security_configuration_profiles/" rel="">SASTコンフィギュレーションプロファイル</a>により、セキュリティチームは一箇所でスキャン設定を定義し、1回の操作でグループ内の全プロジェクトに適用できます。チームはもはや、YAMLポリシーファイルの作成と維持、デベロッパーへのスキャナー設定依頼、各プロジェクトのカバレッジギャップの手動確認を行う必要はありません。</p><h2 id="エージェント型脆弱性修正を今すぐ始める">エージェント型脆弱性修正を今すぐ始める</h2><p>GitLab 18.11は、1つのプラットフォームで脆弱性ワークフローの全体像を提供します：脆弱性を自動修正するAI、脆弱性ノイズを解消するスマートな優先順位付け、そしてセキュリティチームに適切なアクセス権とカバレッジをスケールで提供するガバナンスコントロールです。</p><blockquote><p>GitLab Duo Agent Platformがどのようにして自動修正をデベロッパーのワークフローに直接組み込むかを確認するには、<a href="https://about.gitlab.com/ja-jp/free-trial/?utm_medium=blog&amp;utm_source=blog&amp;utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_automate-remediation-with-ready-to-merge-ai-code-fixes" rel="">今すぐGitLab Ultimateの無料トライアルを開始してください</a>。</p></blockquote>]]></content>
        <author>
            <name>Alisa Ho</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/alisa-ho/</uri>
        </author>
        <published>2026-04-16T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLab 19.0の破壊的な変更ガイド]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/a-guide-to-the-breaking-changes-in-gitlab-19-0/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/a-guide-to-the-breaking-changes-in-gitlab-19-0/"/>
        <updated>2026-04-15T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>GitLab 17.0では80件、GitLab 18.0では27件の破壊的な変更がありました。次期リリースのGitLab 19.0では、15件になる見込みです。</p><p>メジャーアップグレードにおける破壊的な変更の管理は、組織全体にわたる調査と調整が必要なため、時間がかかることはよく理解しています。そのため、<a href="https://docs.gitlab.com/development/deprecation_guidelines/#how-do-i-get-approval-to-move-forward-with-a-breaking-change" rel="">破壊的な変更承認要件</a>を導入しました。この要件により、破壊的な変更を進める前に、影響の軽減策と上位承認が必須となります。このプロセスは機能しており、件数をさらに削減するための取り組みを続けています。</p><p>以下に、GitLab 19.0のすべての破壊的な変更をデプロイタイプと影響度別に整理しています。自信を持ってアップグレードするために必要な軽減手順も併せてご確認ください。</p><h2 id="デプロイウィンドウ">デプロイウィンドウ</h2><p>知っておくべきデプロイウィンドウは以下のとおりです。</p><h3 id="gitlabcom">GitLab.com</h3><p>GitLab.comへの破壊的な変更は、次の2つのウィンドウに限定されます。</p><ul><li><strong>2026年5月4日〜6日</strong>（09:00〜22:00 UTC）— メインウィンドウ</li><li><strong>2026年5月11日〜13日</strong>（09:00〜22:00 UTC）— コンティンジェンシーフォールバック</li></ul><p>その他の多くの変更は、月内を通じて引き続きロールアウトされます。各ウィンドウで発生する破壊的な変更の詳細については、<a href="https://docs.gitlab.com/update/breaking_windows/" rel="">破壊的な変更のドキュメント</a>をご覧ください。</p><p><strong>注意：</strong> 例外的な状況により、破壊的な変更がこれらのウィンドウをわずかに超える場合があります。</p><h3 id="gitlab-self-managed版">GitLab Self-Managed版</h3><p>GitLab 19.0は2026年5月21日より提供開始予定です。</p><blockquote><p><a href="https://about.gitlab.com/releases/" rel="">リリーススケジュール</a>の詳細はこちら。</p></blockquote><h3 id="gitlab-dedicated">GitLab Dedicated</h3><p>GitLab 19.0へのアップグレードは、割り当てられたメンテナンスウィンドウ内に実施されます。詳細および割り当てられたメンテナンスウィンドウは、Switchboardポータルでご確認いただけます。GitLab DedicatedインスタンスはリリースN-1で維持されるため、GitLab 19.0へのアップグレードは2026年6月22日の週のメンテナンスウィンドウ中に実施されます。</p><p>GitLab 19.0での削除予定項目の一覧は、<a href="https://docs.gitlab.com/update/deprecations/?removal_milestone=19.0&amp;breaking_only=true" rel="">非推奨機能ページ</a>でご確認ください。ご自身のデプロイ環境に応じた今年のリリースへの準備方法を以下でご説明します。</p><h2 id="破壊的な変更">破壊的な変更</h2><p>影響度が高い破壊的な変更は以下のとおりです。</p><h3 id="影響度高">影響度：高</h3><p><strong>1. NGINX IngressのサポートがGateway API（Envoy Gateway）に置き換え</strong></p><p><em>GitLab Self-Managed版（Helmチャート）</em></p><p>GitLab HelmチャートはNGINX Ingressをデフォルトのネットワークコンポーネントとしてバンドルしてきました。NGINX Ingressは2026年3月にサポート終了（EOL）を迎えたため、GitLabはGateway API（Envoy Gateway）を新しいデフォルトに移行します。</p><p>GitLab 19.0からは、Gateway APIとバンドルされたEnvoy Gatewayがデフォルトのネットワーク設定になります。Envoy Gatewayへの移行をすぐに実施できない場合は、バンドルされたNGINX Ingressを明示的に再有効化できます。このNGINX Ingressは、GitLab 20.0での完全削除が予定されるまで引き続き利用できます。</p><p>この変更の影響を受けないケース：</p><ul><li>Linuxパッケージで使用しているNGINX</li><li>外部管理のIngressまたはGateway APIコントローラーを使用しているGitLab HelmチャートおよびGitLab Operatorインスタンス</li></ul><p>GitLabは、完全削除までの間、フォークされたNGINX Ingressチャートとビルドにベストエフォートのセキュリティメンテナンスを提供します。スムーズな移行のため、19.0アップグレード前に、提供されているGateway APIソリューションまたは外部管理のIngressコントローラーへの移行計画を立ててください。</p><p><a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/590800" rel="">非推奨通知</a></p><p><strong>2. GitLab HelmチャートからバンドルのPostgreSQL、Redis、MinIOを削除</strong></p><p><em>GitLab Self-Managed版（Helmチャート）</em></p><p>GitLab Helmチャートは、概念実証（PoC）環境やテスト環境でのGitLabセットアップを容易にするため、Bitnami PostgreSQL、Bitnami Redis、および公式MinIOチャートのフォークをバンドルしてきました。ライセンスの変更、プロジェクトメンテナンス、パブリックイメージの提供状況の変化により、これらのコンポーネントはGitLab HelmチャートおよびGitLab Operatorから代替なしで削除されます。</p><p>これらのチャートは、本番環境での使用は推奨されないことが明示されており、クイックスタートのテスト環境を構築することのみを目的としていました。</p><p>バンドルのPostgreSQL、Redis、またはMinIOを使用しているインスタンスをお持ちの場合は、<a href="https://docs.gitlab.com/ja-jp/charts/installation/migration/bundled_chart_migration/" rel="">移行ガイド</a>に従って、GitLab 19.0にアップグレードする前に外部サービスを設定してください。LinuxパッケージのRedisおよびPostgreSQLはこの変更の影響を受けません。</p><p><a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/590797" rel="">非推奨通知</a></p><p><strong>3. Resource Owner Password Credentials（ROPC）OAuthグラントを削除</strong></p><p><em>GitLab.com | Self-Managed版 | Dedicated</em></p><p>OAuthフローとしてのResource Owner Password Credentials（ROPC）グラントのサポートは、GitLab 19.0で完全に削除されます。これは、ROPCを固有のセキュリティ上の制限を理由に削除するOAuth RFC Version 2.1標準への準拠によるものです。</p><p>GitLabはすでに、2025年4月8日よりGitLab.com上のROPCにクライアント認証を義務付けています。また、削除前に制御されたオプトアウトを可能にするための管理者設定が18.0で追加されました。</p><p>19.0アップグレード後は、クライアント認証情報を使用している場合でも、ROPCはいかなる状況でも使用できません。このグラントタイプを使用しているアプリケーションや統合は、アップグレード前に認証コードフローなどのサポートされているOAuthフローに移行する必要があります。</p><p><a href="https://gitlab.com/gitlab-org/gitlab/-/issues/457353" rel="">非推奨通知</a></p><p><strong>4. PostgreSQL 16のサポート終了 — PostgreSQL 17が新しい最低要件</strong></p><p><em>GitLab Self-Managed版</em></p><p>GitLabはPostgreSQLの<a href="https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/" rel="">年次アップグレードサイクル</a>に従っています。GitLab 19.0ではPostgreSQL 17が必要な最低バージョンとなり、PostgreSQL 16のサポートは終了します。</p><p>PostgreSQL 17はGitLab 18.9から利用可能であるため、19.0リリース前であればいつでもアップグレードできます。</p><p>Linuxパッケージ経由でインストールした単一のPostgreSQLインスタンスを実行しているインスタンスでは、18.11アップグレード時にPostgreSQL 17への自動アップグレードが試みられる場合があります。アップグレードに十分なディスク容量があることを確認してください。</p><p>PostgreSQL Clusterを使用しているインスタンス、または自動アップグレードをオプトアウトしているインスタンスでは、GitLab 19.0にアップグレードする前にPostgreSQL 17への手動アップグレードが必要です。</p><p><a href="https://gitlab.com/gitlab-org/gitlab/-/issues/589774" rel="">非推奨通知</a> | <a href="https://docs.gitlab.com/ja-jp/omnibus/settings/database/#upgrade-packaged-postgresql-server" rel="">アップグレードガイド</a></p><h3 id="影響度中">影響度：中</h3><p>影響度が中程度の破壊的な変更は以下のとおりです。</p><p><strong>1. LinuxパッケージのUbuntu 20.04サポートを廃止</strong></p><p><em>GitLab Self-Managed版</em></p><p>Ubuntu 20.04の標準サポートは2025年5月に終了しました。GitLabの<a href="https://docs.gitlab.com/ja-jp/install/package/#supported-platforms" rel="">Linuxパッケージサポートプラットフォームポリシー</a>に基づき、ベンダーによるOSサポートが終了した時点でパッケージのサポートも終了します。</p><p>GitLab 19.0からはUbuntu 20.04向けパッケージの提供を終了します。GitLab 18.11が、このディストリビューション向けの最後のLinuxパッケージリリースとなります。</p><p>現在Ubuntu 20.04でGitLabを実行している場合は、GitLab 19.0へのアップグレード前に、Ubuntu 22.04または<a href="https://docs.gitlab.com/ja-jp/install/package/#supported-platforms" rel="">サポートされているオペレーティングシステム</a>にアップグレードする必要があります。Canonicalは移行を支援する<a href="https://documentation.ubuntu.com/server/how-to/software/upgrade-your-release/" rel="">アップグレードガイド</a>を提供しています。</p><p><a href="https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/8915" rel="">非推奨通知</a></p><p><strong>2. Redis 6のサポートを削除</strong></p><p><em>GitLab Self-Managed版</em></p><p>GitLab 19.0ではRedis 6のサポートが削除されます。アップグレード前に、外部のRedis 6デプロイを使用しているインスタンスはRedis 7.2またはValkey 7.2に移行する必要があります。Valkey 7.2はGitLab 18.9でベータ版として提供開始され、GitLab 19.0での一般提供（GA）が予定されています。</p><p>Linuxパッケージに含まれるバンドルのRedisはGitLab 16.2以降Redis 7を使用しており、影響を受けません。外部のRedis 6デプロイを使用しているインスタンスのみ対応が必要です。</p><p>一般的なプラットフォームの移行リソースは以下のとおりです。</p><ul><li><strong>AWS ElastiCache：</strong> <a href="https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/supported-engine-versions.html" rel="">Redis 7.2またはValkey 7.2</a>にアップグレード</li><li><strong>GCP Memorystore：</strong> <a href="https://cloud.google.com/memorystore/docs/redis/supported-versions" rel="">Redis 7.2またはValkey 7.2</a>にアップグレード</li><li><strong>Azure Cache for Redis：</strong> Azureでは管理型のRedis 7.2またはValkey 7.2はまだ利用できません。Azure VMまたはAKS上でセルフホストするか、GitLab 19.0 GAでValkey 7.2をサポートするLinuxパッケージインストールを使用してください。</li><li><strong>セルフホスト：</strong> Redis 6インスタンスをRedis 7.2またはValkey 7.2にアップグレード。</li></ul><p><a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/585839" rel="">非推奨通知</a> | <a href="https://docs.gitlab.com/ja-jp/install/requirements/" rel="">要件ドキュメント</a></p><p><strong>3. <code className="">heroku/builder:22</code>イメージが<code className="">heroku/builder:24</code>に置き換え</strong></p><p><em>GitLab.com | Self-Managed版 | Dedicated</em></p><p>Auto DevOpsで使用するクラウドネイティブビルドパック（CNB）ビルダーイメージが<code className="">heroku/builder:24</code>に更新されました。この変更は、<a href="https://docs.gitlab.com/ja-jp/topics/autodevops/stages/#auto-build" rel="">Auto DevOpsのAuto Buildステージ</a>で提供される<a href="https://gitlab.com/gitlab-org/cluster-integration/auto-build-image" rel=""><code className="">auto-build-image</code></a>を使用するパイプラインに影響します。</p><p>ほとんどのワークロードは影響を受けませんが、一部のユーザーには破壊的な変更となる場合があります。アップグレード前に<a href="https://devcenter.heroku.com/articles/heroku-24-stack#what-s-new" rel="">Heroku-24スタックのリリースノート</a>と<a href="https://devcenter.heroku.com/articles/heroku-24-stack#upgrade-notes" rel="">アップグレードノート</a>を確認し、影響範囲を把握してください。</p><p>GitLab 19.0以降も<code className="">heroku/builder:22</code>を引き続き使用する必要がある場合は、CI/CD変数<code className="">AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER</code>を<code className="">heroku/builder:22</code>に設定してください。</p><p><a href="https://gitlab.com/gitlab-org/cluster-integration/auto-build-image/-/issues/79" rel="">非推奨通知</a></p><p><strong>4. MattermostをLinuxパッケージから削除</strong></p><p><em>GitLab Self-Managed版</em></p><p>GitLab 19.0では、バンドルされたMattermostがLinuxパッケージから削除されます。Mattermostは2015年にGitLabとのバンドルが開始されましたが、その後スタンドアロンデプロイの選択肢が充実しました。また、Mattermost v11では<a href="https://forum.mattermost.com/t/mattermost-v11-changes-in-free-offerings/25126" rel="">GitLab SSOが無料プランから非推奨化</a>されたことで、バンドル統合の価値が低下しました。</p><p>バンドルのMattermostを使用していないお客様には影響がありません。現在使用している場合は、Mattermostドキュメントの<a href="https://docs.mattermost.com/administration-guide/onboard/migrate-gitlab-omnibus.html" rel="">GitLab OmnibusからMattermost Standaloneへの移行</a>を参照して移行手順を確認してください。</p><p><a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/590798" rel="">非推奨通知</a></p><p><strong>5. LinuxパッケージのSUSEディストリビューションサポートを廃止</strong></p><p><em>GitLab Self-Managed版</em></p><p>GitLab 19.0では、LinuxパッケージのSUSEディストリビューションサポートが終了します。対象は以下のとおりです。</p><ul><li>openSUSE Leap 15.6</li><li>SUSE Linux Enterprise Server 12.5</li><li>SUSE Linux Enterprise Server 15.6</li></ul><p>GitLab 18.11がこれらのディストリビューション向けの最後のLinuxパッケージバージョンとなります。推奨される移行方法は、基盤となるOSを変更せずにアップグレードを継続できるよう、既存のディストリビューション上でGitLabの<a href="https://docs.gitlab.com/ja-jp/install/docker/installation/" rel="">Dockerデプロイ</a>に移行することです。</p><p><a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/590801" rel="">非推奨通知</a></p><h3 id="影響度低">影響度：低</h3><p>影響度が低い破壊的な変更は以下のとおりです。</p><p><strong>1. SpamcheckをLinuxパッケージおよびGitLab Helmチャートから削除</strong></p><p><em>GitLab Self-Managed版</em></p><p>GitLab 19.0では、<a href="https://docs.gitlab.com/ja-jp/administration/reporting/spamcheck/" rel="">Spamcheck</a>がLinuxパッケージおよびGitLab Helmチャートから削除されます。これは主に大規模なパブリックインスタンスに関連する機能であり、GitLabの顧客ベースではエッジケースに該当します。削除により、大多数のお客様のパッケージサイズと依存関係が削減されます。</p><p>現在Spamcheckを使用していないお客様には影響がありません。バンドルのSpamcheckを使用している場合は、<a href="https://gitlab.com/gitlab-org/gl-security/security-engineering/security-automation/spam/spamcheck" rel="">Docker</a>を使用して個別にデプロイできます。データ移行は不要です。</p><p><a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/590796" rel="">非推奨通知</a></p><p><strong>2. Slashコマンド統合（Slack）を削除</strong></p><p><em>GitLab Self-Managed版 | Dedicated</em></p><p><a href="https://docs.gitlab.com/ja-jp/user/project/integrations/slack_slash_commands/" rel="">SlackのSlashコマンド統合</a>は、同等の機能をより安全に提供する<a href="https://docs.gitlab.com/user/project/integrations/gitlab_slack_application/" rel="">GitLab for Slackアプリ</a>への移行に伴い非推奨となります。</p><p>GitLab 19.0からは、SlackのSlashコマンドの設定および使用ができなくなります。この統合はGitLab Self-Managed版およびGitLab Dedicatedにのみ存在するため、GitLab.comユーザーへの影響はありません。</p><p>インスタンスへの影響を確認するには、<a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/569345#am-i-impacted" rel="">影響確認ガイダンス</a>をご参照ください。</p><p><a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/569345" rel="">非推奨通知</a></p><p><strong>3. API経由のBitbucket Cloudインポートでアプリパスワードが使用不可に</strong></p><p><em>GitLab.com | Self-Managed版 | Dedicated</em></p><p>AtlassianはBitbucket Cloudのアプリパスワード（ユーザー名/パスワード認証）を非推奨とし、この認証方式が2026年6月9日に機能停止することを発表しています。</p><p>GitLab 19.0からは、GitLab APIを通じてBitbucket Cloudからリポジトリをインポートする際、アプリパスワードの代わりに<a href="https://support.atlassian.com/organization-administration/docs/understand-user-api-tokens/" rel="">ユーザーAPIトークン</a>が必要になります。Bitbucket ServerからのインポートやGitLab UI経由でのBitbucket Cloudからのインポートは影響を受けません。</p><p><a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/588961" rel="">非推奨通知</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/588961#am-i-impacted" rel="">影響確認</a></p><p><strong>4. Exploreプロジェクトページからトレンドタブを削除</strong></p><p><em>GitLab.com | Self-Managed版 | Dedicated</em></p><p><strong>Explore &gt; プロジェクト</strong>の<strong>トレンド</strong>タブおよび関連するGraphQL引数がGitLab 19.0で削除されます。トレンドアルゴリズムはパブリックプロジェクトのみを対象としているため、内部または非公開プロジェクトを主に使用するSelf-Managedインスタンスでは効果が低い状況でした。</p><p>GitLab 19.0リリースの1か月前に、GitLab.comの<strong>トレンド</strong>タブはスター数の降順に並べた<strong>アクティブ</strong>タブにリダイレクトされます。</p><p>合わせて削除されるもの：<code className="">Query.adminProjects</code>、<code className="">Query.projects</code>、<code className="">Organization.projects</code> GraphQLタイプの<code className="">trending</code>引数。</p><p><a href="https://gitlab.com/groups/gitlab-org/-/work_items/18493" rel="">非推奨通知</a></p><p><strong>5. コンテナレジストリストレージドライバーの更新</strong></p><p><em>GitLab Self-Managed版</em></p><p>GitLab 19.0では、2つのレガシーコンテナレジストリストレージドライバーが置き換えられます。</p><ul><li><strong>Azureストレージドライバー：</strong> レガシーの<code className="">azure</code>ドライバーは新しい<code className="">azure_v2</code>ドライバーのエイリアスになります。手動での対応は不要ですが、信頼性とパフォーマンス向上のため、積極的な移行を推奨します。移行手順は<a href="https://docs.gitlab.com/ja-jp/administration/packages/container_registry/#use-object-storage" rel="">オブジェクトストレージのドキュメント</a>をご参照ください。<a href="https://gitlab.com/gitlab-org/gitlab/-/issues/523096" rel="">非推奨通知</a></li><li><strong>S3ストレージドライバー（AWS SDK v1）：</strong> レガシーの<code className="">s3</code>ドライバーは新しい<code className="">s3_v2</code>ドライバーのエイリアスになります。<code className="">s3_v2</code>ドライバーはSignature Version 2をサポートしないため、<code className="">v4auth: false</code>の設定は透過的に無視されます。アップグレード前にSignature Version 4への移行を実施してください。<a href="https://gitlab.com/gitlab-org/gitlab/-/issues/523095" rel="">非推奨通知</a></li></ul><p><strong>6. <code className="">ciJobTokenScopeAddProject</code> GraphQLミューテーションを削除</strong></p><p><em>GitLab.com | Self-Managed版 | Dedicated</em></p><p><code className="">ciJobTokenScopeAddProject</code> GraphQLミューテーションは、GitLab 18.0のCI/CDジョブトークンスコープ変更と同時に導入された<code className="">ciJobTokenScopeAddGroupOrProject</code>への移行に伴い非推奨となります。アップグレード前に、非推奨のミューテーションを使用している自動化やツールを更新してください。</p><p><a href="https://gitlab.com/gitlab-org/gitlab/-/issues/474175" rel="">非推奨通知</a></p><p><strong>7. <code className="">ci_job_token_scope_enabled</code> Projects API属性を削除</strong></p><p><em>GitLab.com | Self-Managed版 | Dedicated</em></p><p><a href="https://docs.gitlab.com/ja-jp/api/projects/" rel="">プロジェクトREST API</a>の<code className="">ci_job_token_scope_enabled</code>属性はGitLab 19.0で削除されます。この属性はGitLab 18.0で基盤となる設定が削除された際に非推奨となり、以降は常に<code className="">false</code>を返していました。</p><p>CI/CDジョブトークンのアクセスを制御するには、<a href="https://docs.gitlab.com/ci/jobs/ci_job_token/#control-job-token-access-to-your-project" rel="">CI/CDジョブトークンのプロジェクト設定</a>を使用してください。</p><p><a href="https://gitlab.com/gitlab-org/gitlab/-/issues/423091" rel="">非推奨通知</a></p><p><strong>8. GitLab.comで未認証のProjects APIページネーション制限を適用</strong></p><p><em>GitLab.com</em></p><p>プラットフォームの安定性を維持し、一貫したパフォーマンスを確保するため、GitLab.comのProjects List REST APIへの未認証リクエストすべてに対して、最大オフセット上限50,000が適用されます。たとえば、1ページあたり20件の結果を取得する場合、<code className="">page</code>パラメーターは最大2,500ページに制限されます。</p><p>より多くのデータへのアクセスが必要なワークフローは、キーセットベースのページネーションパラメーターを使用する必要があります。この制限はGitLab.comにのみ適用されます。GitLab Self-Managed版およびGitLab Dedicatedでは、オフセット制限はデフォルトでフィーチャーフラグ配下で無効になります。</p><p><a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/585176" rel="">非推奨通知</a></p><h2 id="影響確認対応に役立つリソース">影響確認・対応に役立つリソース</h2><p>お客様がGitLabインスタンスへの影響を把握できるよう、専用のツールを開発しました。影響を確認したら、各変更に関連するドキュメントに記載されている軽減手順を参照し、GitLab 19.0へのスムーズな移行を実現してください。</p><p><strong><a href="https://gitlab.com/gitlab-com/support/toolbox/gitlab-detective" rel="">GitLab Detective</a>（Self-Managed版のみ）：</strong> この実験的なツールは、設定ファイルとデータベースの値を確認することで、GitLabインストール環境の既知の問題を自動的に診断します。注意：このツールはGitLabノード上で直接実行する必要があります。</p><p>有料プランをお持ちで、これらの変更について質問があるかサポートが必要な場合は、<a href="https://support.gitlab.com/" rel="">GitLab サポートポータル</a>からサポートチケットを開いてください。</p><p>GitLab.comの無料ユーザーの場合は、<a href="https://docs.gitlab.com/ja-jp/" rel="">GitLabドキュメント</a>、<a href="https://forum.gitlab.com/" rel="">GitLabコミュニティフォーラム</a>、<a href="https://stackoverflow.com/questions/tagged/gitlab" rel="">Stack Overflow</a>などのコミュニティリソースを通じてサポートを受けられます。</p>]]></content>
        <author>
            <name>Martin Brümmer</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/martin-brmmer/</uri>
        </author>
        <published>2026-04-15T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLabとVertex AI on Google Cloud：エージェント型ソフトウェア開発の加速]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/gitlab-and-vertex-ai-on-google-cloud/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/gitlab-and-vertex-ai-on-google-cloud/"/>
        <updated>2026-04-14T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>GitLab Duo Agent Platformは、組織がソフトウェアをビルド、セキュア化、そして提供する方法を再定義しつつあります。2026年1月の一般提供開始以来、このプラットフォームはソフトウェア開発ライフサイクルのあらゆる段階にエージェント型AIをもたらしています。Duo Agent Platformは、ソフトウェアチームと専門エージェントが連携して計画、コーディング、レビュー、セキュリティ脆弱性の修正を行う、インテリジェントなオーケストレーションレイヤーです。</p><p>このパートナーシップを通じて、<a href="https://about.gitlab.com/gitlab-duo-agent-platform/" rel="">GitLab Duo Agent Platform</a>はVertex AI on Google Cloudとの統合によりソフトウェア開発のオーケストレーションとライフサイクルコンテキストを自動化します。Vertex AIはエージェント呼び出しのモデル層を担い、ソフトウェアチームはすでに定義済みのGoogle Cloudポリシーに従って推論を実行しながら、イシュー、マージリクエスト、パイプライン、セキュリティワークフローの作業を継続できます。</p><p>Google CloudのVertex AIモデルの進化により、Google CloudユーザーはGitLab Duo Agent Platformをさらに活用できるようになっています。GitLabではAIを活用したDevSecOpsコントロールプレーンを、Vertex AIの急速に進化するAIインフラ基盤と、Duo Agent Platformの柔軟なデプロイ・統合オプションが支えています。この組み合わせにより、エンタープライズスケールで動作する、より高度でガバナンスの効いたエージェント型ワークフローが実現します。</p><p><img alt="Google CloudのVertex AIと連携してエージェント型ソフトウェア開発とガバナンスを備えたAIワークフローを実現するGitLab Duo Agent Platformの概念図" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1776165990/b7jlux9kydafncwy8spc.png" /></p><h2 id="開発ライフサイクル全体にわたるエージェント">開発ライフサイクル全体にわたるエージェント</h2><p>多くのAIツールは、コードをより速く生成するという単一のタスクに集中しています。GitLab Duo Agent Platformはそれをさらに超え、計画からセキュリティレビュー、リリースまで、ソフトウェア開発ライフサイクル（SDLC）全体にわたってAIエージェントをオーケストレーションします。これは、多数のプロジェクトとリリースを抱える多くのチームを対象としています。このスケールにおいて、AIコーディングアシスタントは継続的なイノベーションに必要ではありますが、それだけでは十分ではありません。</p><p>単一目的のコーディングアシスタントがプロジェクトの全体像を把握することはほとんどありません。バックログの状況、オープン中のマージリクエスト、失敗したジョブ、セキュリティの検出結果はGitLabに蓄積されていますが、コーディングアシスタント内の別のチャットウィンドウはSDLCのその全体像を引き継ぐことができません。このギャップは、手動によるハンドオフ、コンテキストを持たないAIへの重複した説明、そして一つのシステムとして設計されたわけではないツール間のデータフローをマッピングしようとするガバナンスチームという形で表れます。</p><p>GitLab Duo Agent Platformは、エンジニアが日々使用するオブジェクト上でエージェントとフローを動作させることで、このギャップを埋めます。Google Cloudを推論の基盤として選択している場合、Vertex AIはエージェントが呼び出すモデルとサービスを提供し、GitLabのAI Gatewayがアクセスを仲介することで管理者はどこに何が接続されているかを明確に把握できます。例えば、GitLab Duo Planner Agentはバックログを分析し、エピックを構造化タスクに分解し、優先順位付けフレームワークを適用することで、次に何を構築するかをチームが判断するのを支援します。Security Analyst Agentは脆弱性をトリアージし、平易な言葉でリスクを説明し、優先順位に従って修正を推奨します。ビルトインのフローはこれらのエージェントをエンドツーエンドのプロセスへと連結し、開発者がすべてのハンドオフを手動で管理する必要をなくします。</p><p>GitLab Duo Agent PlatformのAgentic Chatは、開発者にとって統合された体験を提供します。自然言語でクエリを投げかけることで、プロジェクトのイシュー、マージリクエスト、パイプライン、セキュリティの検出結果、コードベースといった全体像を踏まえた多段階の推論に基づくコンテキスト対応の回答が得られます。GitLabがSDLCの統一データモデルを持つ記録システムとして機能しているため、GitLab Duoエージェントは、スタンドアロンのツール固有AIアシスタントでは到達できないライフサイクルコンテキストをもとに動作します。</p><h3 id="vertex-aiによる能力の拡張">Vertex AIによる能力の拡張</h3><p>GitLab Duo Agent Platformはモデルフレキシブルな設計となっており、タスクごとに最適なパフォーマンスを発揮するモデルへと異なる機能をルーティングします。このアーキテクチャの選択はGoogle Cloud上で効果を発揮します。Vertex AIはファウンデーションモデルと関連サービスのマネージド環境として機能し、幅広いモデルエコシステムとマネージドインフラを提供することでプラットフォームの能力をさらに引き出します。</p><p>Vertex AIを通じて利用できる最新世代のAIモデルは、以前のバージョンと比較して推論、ツール使用、長文コンテキスト理解において大幅な改善をもたらします。これらはまさに、GitLabのエージェントが大規模で複雑なコードベースを持つ多くのプロジェクトとチームにわたって依拠するプロパティです。基盤モデルにおけるより長いコンテキストウィンドウと豊富なツール連携により、エージェントが一度のパスで達成できることが広がり、深いバックログ分析やモノレポのセキュリティレビューといったワークロードに特に重要な意味を持ちます。</p><p>幅広いファウンデーションモデルへのアクセスを提供する<a href="https://cloud.google.com/model-garden" rel="">Vertex AI Model Garden</a>により、ベンダーロックインではなく、パフォーマンス、コスト、規制要件に基づいてこれらの選択を行う自由がお客様に与えられます。</p><p>さらに、GitLabのお客様はDuo Agent PlatformにBYOM（Bring Your Own Model）を利用することで、承認済みのプロバイダーとゲートウェイをセキュリティモデルが期待する場所に配置できます。<a href="https://about.gitlab.com/blog/agentic-ai-enterprise-control-self-hosted-duo-agent-platform-and-byom/" rel="">18.9リリースにおけるセルフホスト型Duo Agent PlatformとBYOMの解説</a>では、その仕組みが詳しく説明されています。このデプロイオプションにより、お客様はソフトウェア開発プロセスに合わせてカスタマイズできるより広いモデルの選択肢へのアクセスを得られます。適切なワークフローに、適切なモデルを、適切なガードレールとともに。</p><p>GitLabがVertex AIを基盤として選択したのは、エンタープライズグレードの信頼性と比類ないモデルの幅広さへのニーズによるものです。Vertex AIとModel Gardenは、LLMホスティングの重労働を完全に抽象化し、迅速なバージョン提供、堅牢なセキュリティ、厳格なガバナンスをシームレスに統合に組み込んでいます。Geminiモデルの提供にとどまらず、Vertex AIはサードパーティおよびオープンソースモデルの豊富なカタログへのグローバルかつ低レイテンシのアクセスを提供します。</p><p>GoogleCloudの業界をリードするデータプライバシーとモデル保護へのアプローチと組み合わせることで、Vertex AIはGitLabの次世代デベロッパーエクスペリエンスを支える明確な選択肢として浮上しました。</p><p>Vertex AI Model GardenをバックエンドへIntegrateすることで、GitLabはDevSecOpsプラットフォームを強化しながら、その複雑さをユーザーに負わせることがありません。開発チームは基盤となるLLMの評価や管理に煩わされることなく、アプリケーション構築のための効率的なAI支援ワークフローを体験できます。</p><p>GitLabはクラウドオーケストレーションを完全に抽象化し、開発者が優れたコードの記述に集中できる環境を提供する一方、Vertex AIはその支援となる機能を動かしています。</p><h2 id="google-cloudをご利用のお客様への意義">Google Cloudをご利用のお客様への意義</h2><p>GitLab Duo Agent Platformはすでに、一つのガバナンスの効いた記録システムの中でソフトウェアライフサイクル全体にわたって動作するAIエージェントを提供しています。Google Cloud上では、Vertex AIがモデルとインフラ層を継続的に進化させながら、迅速なイノベーションを可能にします。</p><p>Google Cloudをご利用のお客様にとって、この統合は厳格なエンタープライズガバナンスを維持しながらソフトウェア提供を効率化することを意味します。プラットフォームエンジニアリンググループにとっては、クライアントサイドのツールを数十種類カタログ化するのではなく、GitLab内の提案、分析、修正を担うVertex AI連携モデルを標準化することを意味します。セキュリティプログラムは、エージェントが開発者がすでに検出結果をトリアージしている場所と同じ場所で修正を提案・検証することで、頭の切り替えを減らし、管理されていないチャネルへ流出していた作業を削減できます。</p><p>クラウドの費用対効果とポリシーの観点から、GitLab内からVertexへのエージェント推論をまとめることで、Google Cloud上ですでに運用している契約や統制に近い形で使用量を管理でき、調達プロセスを迂回する重複支出やシャドーパスを回避するのに役立ちます。</p><p>Vertex AIはGitLab Duo Agent Platformの基盤インフラプロバイダーであるため、組織はAIツールチェーンの断片化を管理するオーバーヘッドとリスクなしに、デベロッパーの生産性を大幅に向上させることができます。チームは単一のセキュアな記録システムの中で足並みを揃え、アプリケーションをより速くビルドし、確信を持ってリリースできるようになります。</p><p>GitLabとGoogle Cloudのコラボレーションは2018年から続いています。今日、これはAIの実験から、Google Cloud上での完全にガバナンスが効いたエージェント型ソフトウェア開発へと移行する組織にとって、最も包括的なパスの一つとなっています。GitLabがエージェントオーケストレーションとデベロッパーコンテキストを拡充し、Vertex AIがモデル能力とエージェントインフラの限界を押し広げていく中で、共同顧客にとっての価値は今後も成長し続けるでしょう。</p><blockquote><p><a href="https://about.gitlab.com/free-trial/" rel="">GitLab Duo Agent Platformの無料トライアルを開始</a>して、Google Cloud上でのGitLabとVertex AIのパワーをぜひご体験ください。</p></blockquote>]]></content>
        <author>
            <name>Regnard Raquedan</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/regnard-raquedan/</uri>
        </author>
        <author>
            <name>Rajesh Agadi</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/rajesh-agadi/</uri>
        </author>
        <published>2026-04-14T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[Monday Merge 4月号：GitLab 18.10、エージェント型AIの勢い、そして大きなコミュニティの節目]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/monday-merge-2026-april-13/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/monday-merge-2026-april-13/"/>
        <updated>2026-04-13T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>こんにちは、Fatimaです。4月のMonday Mergeへようこそ。</p><p>今月は内容が盛りだくさんです。GitLab 18.10、エージェント型AIへのアクセス拡大、Claude Marketplaceでの大きな前進、グローバルなハッカソン、そしてお客様による実際の素晴らしい成果についてお話しします。</p><p>取り上げる内容がたくさんあるので、さっそく見ていきましょう👇👇👇👇👇👇👇</p><p><img alt="GitLab 18.10" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782465/iqzcxratajkcnnnzdzky.png" /></p><p>AIによってコードを書くスピードはこれまでになく速くなりました。しかし、多くのチームが実感しているように、もはや本当のボトルネックはそこではありません。</p><p>問題は、その後のプロセスです。</p><p>GitLab 18.10は、エージェント型AIをソフトウェアライフサイクルのより深い部分に組み込み、あらゆる規模のチームがより簡単に、より手頃に、そしてより実用的に導入できるように設計されています。</p><p>私が特に注目しているポイントをいくつかご紹介します：</p><ul><li><strong>無料プランにもエージェント型AIを提供</strong>：GitLab.comの無料プランを利用しているチームでも、GitLabクレジットの月額コミットを購入することで、ユーザー単位の課金なしにGitLab Duo Agent Platformを利用できるようになりました</li><li><strong>Agentic Code Reviewのコストを固定化</strong>：コードレビュー1件あたり25セント（現在はGitLabクレジット1つで4件）となり、コストの予測性を保ちながら、すべてのプロジェクトやマージリクエストにスケール可能になりました</li><li><strong>SASTの誤検出判定機能が一般提供開始</strong>：GitLab Duo Agent Platformを利用するGitLab Ultimateユーザー向けに提供され、セキュリティおよび開発チームが重要な脆弱性とその対応をより適切に優先付けできるようになります</li><li><strong>60以上の改善</strong>：プランニングからセキュリティ、CI/CDまで、このリリースはコミット間でチームのボトルネックを解消することに焦点を当てています</li></ul><p>ここでの大きな変化は明確です。コードを書くスピードを上げるAIから、その後に必要となるすべてのソフトウェアエンジニアリング業務を支援するAIへと移行しているのです。</p><p><strong>🔗 <a href="https://www.linkedin.com/redir/redirect?url=https%3A%2F%2Fabout%2Egitlab%2Ecom%2Freleases%2F2026%2F03%2F19%2Fgitlab-18-10-released%2F&amp;urlhash=0Act&amp;trk=article-ssr-frontend-pulse_little-text-block" rel="">リリースノートの詳細はこちら。</a></strong></p><h2 id="gitlab-duo-agent-platformがclaude-marketplaceで利用可能に">GitLab Duo Agent PlatformがClaude Marketplaceで利用可能に</h2><p><img alt="" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782462/nnub3neiya1njshibrz2.png" /></p><p>組織は、既存のAnthropicとの契約を活用してGitLabを購入し、エンタープライズレベルのセキュリティ、品質、ガバナンスを維持しながら、ソフトウェアライフサイクル全体でエージェント型AIを統合・活用できるようになりました。</p><p><img alt="Flowlands" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782462/zmcxtubkzub1uobe4crl.png" /></p><p><strong>（はい…Flowlandsは実在します。まあ、概念として。）</strong></p><p>最近、GitLabのテーマパークについて何か見かけたなら、それは見間違いではありません。</p><p>Flowlandsは、エイプリルフールの企画でした。ソフトウェア開発が“物理的な体験”になるという、少し突飛で完全に想像上の世界です。</p><p>でも正直なところ、みんな行ってみたいですよね。</p><p>🎢🎡🎪🎠 見逃した方は、ぜひテーマパークのカルーセルをご覧ください！（ダジャレです😄）</p><h2 id="gitlab-hackathon-2026年4月16日23日"><strong>GitLab Hackathon: 2026年4月16日〜23日</strong></h2><p><img alt="GitLab Hackathon" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782464/jk3o4ynp6lj3spttkmzg.png" /></p><p>現実に戻りましょう。</p><p>グローバルGitLabハッカソンは2026年4月16日から23日まで開催され、プラットフォームやコミュニティに実際に触れながら参加できる最高の機会のひとつです。</p><ul><li>実際のGitLabプロジェクトに貢献</li><li>グローバルなオープンソースコミュニティと協働</li><li>コード、ドキュメント、UXなど幅広い分野で開発</li><li>賞品を獲得し、GitLabプロフィールを強化</li></ul><p>初心者でも経験者でも、参加して実際に手を動かし始める絶好のチャンスです。</p><p>🔗 <a href="https://www.linkedin.com/redir/redirect?url=https%3A%2F%2Fcontributors%2Egitlab%2Ecom%2Fhackathon&amp;urlhash=4KIo&amp;trk=article-ssr-frontend-pulse_little-text-block" rel="">こちらから参加できます。どなたでも歓迎です！</a></p><h2 id="カスタマースポットライトcanada-life"><strong>カスタマースポットライト：Canada Life</strong></h2><p><img alt="Canada Life" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782462/qtg3vpbyxo0pvdepesbv.png" /></p><p>今月特に印象的だったのは、チームが本格的にAIを活用したときに何が起こるかを目の当たりにしたことです。</p><p>私たちはCanada Lifeと提携し、2日間のAIハッカソンを実施しました。開発、セキュリティ、コンプライアンス、ビジネス部門から100名以上が参加し、実際にエンタープライズレベルのソリューションを構築しました。</p><p>その結果は驚くべきものでした：</p><ul><li>わずか48時間で10件のエンタープライズ向けAIソリューションを構築</li><li>コードレビュー時間を40％削減</li><li>リリースノート作成時間を90％削減</li><li>コンプライアンス違反を80％削減</li></ul><p>さらに、コストを96.7％削減したレガシーコードのモダナイゼーション支援ツールや、オンボーディング時間を半分に短縮した開発者向けオンボーディングアシスタントなども開発されました。</p><p>彼らの言葉を借りると：</p><p><em>「もし48時間でこれだけのことができるなら、</em></p><p><em>この先に何が待っているのか想像してみてください。」</em></p><h2 id="今後のイベント"><strong>今後のイベント</strong></h2><p><img alt="GitLab Events" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782462/stbub39txwqdkbaczo3d.png" /></p><p>今月はオンライン・オフラインともに多数のイベントを予定しており、ぜひご参加いただければ嬉しいです。</p><p>注目のイベントをいくつかご紹介します：</p><p><img alt="イベントいちらん" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782465/ggioajzrs6lkyavbqta4.png" /></p><p>🔗 <a href="https://www.linkedin.com/redir/redirect?url=https%3A%2F%2Fabout%2Egitlab%2Ecom%2Fevents%2F&amp;urlhash=dRaL&amp;trk=article-ssr-frontend-pulse_little-text-block" rel="">Wherever you are in the world, there’s something happening so check out our events page here!</a></p><h2 id="今月のおすすめ"><strong>今月のおすすめ</strong></h2><p><img alt="今月のおすすめ" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782461/s8g358gll3ai4wfmrw8v.png" /></p><p>今月も興味深い記事をいくつか紹介します。</p><p>政府機関のチームがAIを活用したDevOpsによってどのようにモダナイゼーションを進めているのか、技術的負債の削減からライフサイクルの早い段階でのセキュリティ組み込みまでを探っています。</p><p>また、企業全体でのAI導入がどのように進化しているのかにも注目しています。特に、単なるコード生成を超えてワークフローを統合する方法や、SDLC全体にわたる複雑性の管理について考察しています。</p><p><img alt="記事一覧" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782466/zgarpxfpp5hxyxgssjbh.png" /></p><p>🔖 少し時間があるときにじっくり読めるよう、ぜひブックマークしておいてください！</p><p><img alt="画像出典：Chemical Heritage Foundation" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1775782465/cjsggxtiohfdgqqijrwm.png" /></p><p>画像出典：Chemical Heritage Foundation</p><p>本当に、この4月はたくさんのことが起きています。エージェント型AIによって、より多くの実験や探求の余地が生まれていて、こんな言葉を思い出しました。</p><p>「新しいアイデアに心を開き、いろいろ試してみることでさまざまなことが起こり得る。」</p><p>ケブラーの発明者であるステファニー・クオレクの言葉です。まさに今の状況にぴったりだと感じます。</p><p>AIが反復的な作業の多くを担うようになることで、開発者はより自由に実験し、探求し、次のものを創り出す余地を手にしています。</p><p>お読みいただきありがとうございました。ウェブキャストやIssueでお会いできるのを楽しみにしています。そして、これからも対話を続けていきましょう。それでは、いつものようにHappy Merging!</p><p><img alt="Fatima" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1770180580/nz0ipehzgtcb757kl0ux.png" /></p><p><a href="https://www.linkedin.com/in/sugaroverflow/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B3ix%2FZ9%2BgTBmIWuSHZsMZRw%3D%3D" rel="">Fatima Sarah Khalid</a>｜Senior Developer Advocate, GitLab</p><p>このニュースレターが気に入ったら、ぜひチームに共有してください。
そして👉<a href="https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg" rel="">YouTubeチャンネル</a>の登録もお忘れなく！</p>]]></content>
        <author>
            <name>GitLab Japan Team</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/gitlab-japan-team/</uri>
        </author>
        <published>2026-04-13T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[3月のサプライチェーン攻撃から学ぶパイプラインセキュリティ]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/pipeline-security-lessons-from-march-supply-chain-incidents/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/pipeline-security-lessons-from-march-supply-chain-incidents/"/>
        <updated>2026-04-07T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p><em><strong>注：GitLab製品は、本記事で言及されている侵害されたパッケージバージョンを使用していませんでした。</strong></em></p><p>わずか12日間で4件の独立したサプライチェーン攻撃が発生し、継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインが高度な脅威アクターにとって格好の標的となっていることが明らかになりました。</p><p>2026年3月19日から31日にかけて、脅威アクターは以下のツールを侵害しました。</p><ul><li>オープンソースのセキュリティスキャナー（Trivy）</li><li>Infrastructure as Code（IaC）セキュリティスキャナー（Checkmarx KICS）</li><li>AIモデルゲートウェイ（LiteLLM）</li><li>JavaScript HTTPクライアント（axios）</li></ul><p>いずれの攻撃も同じ侵入口を狙っていました。それがビルドパイプラインです。
本記事では、何が起きたのか、なぜパイプラインが特に脆弱なのか、そしてGitLabの集中型ポリシー適用（以下で定義するポリシーを使用）が、これらの攻撃パターンを本番環境に到達する前にブロック・検出・封じ込める方法を解説します。</p><h2 id="数百万人が信頼するツールがわずか数分で侵害された">数百万人が信頼するツールが、わずか数分で侵害された</h2><p>サプライチェーン攻撃のタイムラインは以下のとおりです。</p><h3 id="_3月19日trivyセキュリティスキャナーが攻撃のベクターに">3月19日：Trivyセキュリティスキャナーが攻撃のベクターに</h3><p><a href="https://github.com/aquasecurity/trivy" rel="">Trivy</a>は、世界で最も広く使われているオープンソースの脆弱性スキャナーの1つです。脆弱性を検出するために<em>パイプライン内</em>で実行されるツールです。</p><p>3月19日、TeamPCPと呼ばれる脅威アクターグループが<a href="https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/" rel="">侵害された認証情報を使用し</a>、<code className="">aquasecurity/trivy-action</code> GitHub Actionの76バージョンタグ（全77件中）および<code className="">aquasecurity/setup-trivy</code>の全7タグに悪意のあるコードをforce-pushしました。同時に、トロイの木馬化されたTrivyバイナリ（v0.69.4）が公式配布チャネルに公開されました。このペイロードは認証情報を窃取するマルウェアで、Trivyスキャンを実行したすべてのパイプラインから環境変数、クラウドトークン、SSHキー、CI/CDシークレットを収集しました。</p><p>このインシデントには<a href="https://nvd.nist.gov/vuln/detail/CVE-2026-33634" rel="">CVE-2026-33634</a>が割り当てられ、CVSSスコアは9.4でした。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は数日以内にこれを既知の悪用済み脆弱性カタログに追加しました。</p><h3 id="_3月23日次はcheckmarx-kicsが標的に">3月23日：次はCheckmarx KICSが標的に</h3><p>TeamPCPは窃取した認証情報を使い、CheckmarxのオープンソースプロジェクトであるKICS（Keeping Infrastructure as Code Secure）に攻撃対象を移しました。<code className="">ast-github-action</code>および<code className="">kics-github-action</code> GitHub Actionに<a href="https://thehackernews.com/2026/03/teampcp-hacks-checkmarx-github-actions.html" rel="">同じ認証情報窃取マルウェアを注入し</a>、3月23日の12:58〜16:50 UTCの間、これらのアクションを参照するCI/CDパイプラインはすべて、APIキー、データベースパスワード、クラウドアクセストークン、SSHキー、サービスアカウントの認証情報などの機密データを密かに外部に送信していました。</p><h3 id="_3月24日trivyの侵害された認証情報を経由してlitellmも被害を受ける">3月24日：Trivyの侵害された認証情報を経由してLiteLLMも被害を受ける</h3><p>月間9,500万ダウンロードのLLM APIプロキシであるLiteLLMが次の標的になりました。TeamPCPは、TrivyでスキャンしていたLiteLLM自身のCI/CDパイプラインから収集した認証情報を使用し、PyPIにバックドアを仕込んだバージョン（1.82.7および1.82.8）を<a href="https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html" rel="">公開しました</a>。</p><p>バージョン1.82.7を標的としたマルウェアは、<code className="">litellm/proxy/proxy_server.py</code>にインポート時に実行されるbase64エンコードされたペイロードを直接注入していました。バージョン1.82.8を標的としたものは、Pythonインタープリタ起動時に自動実行される<code className="">.pth</code>ファイルを使用していました。LiteLLMをインストールするだけでペイロードが起動してしまう仕組みです。攻撃者は窃取したデータ（SSHキー、クラウドトークン、.envファイル、暗号資産ウォレット）を暗号化し、本物のドメインに似せた<code className="">models.litellm.cloud</code>に外部送信しました。</p><h3 id="_3月31日単純なパッケージングミスがaiコーディングアシスタントのソースコードを流出させる">3月31日：単純なパッケージングミスがAIコーディングアシスタントのソースコードを流出させる</h3><p>TeamPCPの攻撃キャンペーンがまだ続く中、あるソフトウェア企業が59.8 MBのソースマップファイルを含むnpmパッケージを公開してしまいました。そのファイルには、AIコーディングアシスタントの完全な未縮小TypeScriptソースコードへの参照が含まれており、自社のCloudflare R2バケットでホストされていました。</p><p>この流出により、1,900のTypeScriptファイル、512,000行以上のコード、44の隠し機能フラグ、未公開のモデルコードネーム、そして知る人ぞ知る場所へのアクセス方法を知っていれば誰でも確認できるシステムプロンプトの全文が公開されてしまいました。エンジニアの<a href="https://dev.to/gabrielanhaia/claude-codes-entire-source-code-was-just-leaked-via-npm-source-maps-heres-whats-inside-cjo" rel="">Gabriel Anhaia氏が解説したように</a>、「<code className="">.npmignore</code>またはpackage.jsonのfilesフィールドの設定ミスが1つあるだけで、すべてが露出してしまいます」。</p><h3 id="_3月31日axiosとサプライチェーンへのもう1つのトロイの木馬">3月31日：axiosとサプライチェーンへのもう1つのトロイの木馬</h3><p>同日、週間1億ダウンロード超のJavaScript HTTPクライアントであるaxios npmパッケージを狙った<a href="https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html" rel="">高度なキャンペーンが実行されました</a>。</p><p>侵害されたメンテナーアカウントによりバックドアを仕込んだバージョン（1.14.1および0.30.4）が公開されました。悪意のある依存関係（<code className="">plain-crypto-js@4.2.1</code>）が注入され、macOS、Windows、Linuxで動作するリモートアクセス型トロイの木馬（RAT）がデプロイされました。2つのリリースブランチともに39分以内に感染し、マルウェアは実行後に自己消去するよう設計されていました。</p><h2 id="これらの攻撃に潜む共通パターン">これらの攻撃に潜む共通パターン</h2><p>5件のインシデントを通じて、3つの明確な攻撃パターンが浮かび上がってきます。いずれもCI/CDパイプラインがその入力に対して暗黙的に持つ信頼を悪用するものです。</p><h3 id="パターン1汚染されたツールとアクション">パターン1：汚染されたツールとアクション</h3><p>TeamPCPのキャンペーンは、ある根本的な前提を突いていました。それは、パイプライン<em>内</em>で実行されるセキュリティツール自体は信頼できるという思い込みです。GitHubアクションのタグやPyPIパッケージのバージョンが悪意のあるコードに解決された場合、パイプラインはそれを環境シークレット、クラウド認証情報、デプロイトークンへのフルアクセス権限で実行してしまいます。パイプラインはタグを信頼するため、検証ステップが存在しないのです。</p><p><strong>推奨されるパイプラインレベルの対策：</strong> 可変バージョンタグではなく、不変の参照（コミットSHAまたはイメージダイジェスト）にツールとアクションをピン留めしてください。ピン留めが現実的でない場合は、既知の正常なチェックサムまたは署名に対してツールと依存関係の整合性を検証してください。検証に失敗した場合は実行をブロックします。</p><h3 id="パターン2知的財産ipを漏洩するパッケージング設定ミス">パターン2：知的財産（IP）を漏洩するパッケージング設定ミス</h3><p>設定ミスのあるビルドパイプラインが、デバッグ成果物をそのまま本番パッケージに含めて出荷してしまいました。<code className="">.npmignore</code>またはpackage.jsonのfilesフィールドの設定ミスが1つあれば十分です。公開前の検証ステップを設けておけば、こうした問題は毎回防ぐことができます。</p><p><strong>推奨されるパイプラインレベルの対策：</strong> パッケージを公開する前に、パッケージの内容を許可リストに対して検証し、予期しないファイル（ソースマップ、内部設定ファイル、.envファイル）をフラグとして検出し、チェックに失敗した場合は公開ステップをブロックする自動チェックを実行してください。</p><h3 id="パターン3推移的依存関係の脆弱性">パターン3：推移的依存関係の脆弱性</h3><p>axiosへの攻撃は、axiosを直接使用しているユーザーだけでなく、依存関係ツリーが侵害されたバージョンに解決されるすべてのユーザーを標的にしました。ロックファイル内で一度依存関係が汚染されると、組織全体のビルドインフラに波及する可能性があります。</p><p><strong>推奨されるパイプラインレベルの対策：</strong> 依存関係のチェックサムを既知の正常なロックファイルの状態と比較してください。予期しない新しい依存関係やバージョン変更を検出し、未検証のパッケージを導入するビルドをブロックします。</p><h2 id="gitlabパイプライン実行ポリシーによる各攻撃パターンへの対処">GitLabパイプライン実行ポリシーによる各攻撃パターンへの対処</h2><p>GitLabパイプライン実行ポリシー（<a href="https://docs.gitlab.com/ja-jp/user/application_security/policies/pipeline_execution_policies/" rel="">PEP</a>）は、セキュリティチームおよびプラットフォームチームが、開発者が<code className="">.gitlab-ci.yml</code>で定義した内容に関わらず、組織全体のすべてのパイプラインに必須のCI/CDジョブを注入できる仕組みです。PEPで定義されたジョブは、<code className="">[skip ci]</code>や<code className="">[no_pipeline]</code>ディレクティブを使ってもスキップできません。ジョブは開発者のパイプラインを前後から挟む<em>予約済み</em>ステージ（<code className="">.pipeline-policy-pre</code>および<code className="">.pipeline-policy-post</code>）で実行できます。</p><p>3つのパターンすべてに対応するパイプライン実行ポリシーをオープンソースプロジェクトとして公開しています：<a href="https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies" rel="">Supply Chain Policies</a>。これらのポリシーは独立してデプロイ可能で、それぞれテスト用の違反サンプルが同梱されています。各ポリシーの仕組みをご紹介します。</p><h3 id="ユースケース1パッケージ公開時の意図しない情報露出を防ぐ">ユースケース1：パッケージ公開時の意図しない情報露出を防ぐ</h3><p><strong>問題：</strong> ビルドパイプラインが公開時の検証をスキップしたため、ソースマップファイルがAIコーディングツールのnpmパッケージに含まれてしまいました。</p><p><strong>PEPによるアプローチ：</strong> この種のエラーに特化したオープンソースのパイプライン実行ポリシーを作成しました：<a href="https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/artifact-hygiene.gitlab-ci.yml?ref_type=heads" rel="">Artifact Hygiene</a>。</p><p>このポリシーは、公開ステップが実行される前に、アーティファクトタイプ（npmパッケージ、Dockerイメージ、またはHelmチャート）を自動検出してその内容を検査する<code className="">.pipeline-policy-pre</code>ジョブを注入します。npmパッケージに対しては、3つのチェックを実行します。</p><ol><li><strong>ファイルパターンのブロックリスト。</strong> npm packの出力をスキャンし、ソースマップ（.map）、テストディレクトリ、ビルド設定、IDE設定、src/ディレクトリを検出します。</li><li><strong>パッケージサイズゲート。</strong> AIツールを流出させた59.8 MBパッケージのように、50 MBを超えるパッケージをブロックします。</li><li><strong>sourceMappingURLスキャン。</strong> 外部URL（大手AI企業のソースコードを露出させたR2バケットのパターン）、インラインのdata: URI、JavaScriptバンドルに埋め込まれたローカルファイル参照を検出します。</li></ol><p>違反が検出されると、パイプラインは失敗したCIジョブのログに明確なレポートを出力して終了します。</p><pre className="language-text" code="=============================================
FAILED: 3 violation(s) found
=============================================
BLOCKED: dist/index.js.map (matched: \.map$)
BLOCKED: dist/index.js contains external sourceMappingURL
BLOCKED: dist/utils.js contains inline sourceMappingURL

This check is enforced by a Pipeline Execution Policy. If this is a false positive, contact the security team to update the policy project or exclude this project.
" language="text" meta=""><code>=============================================
FAILED: 3 violation(s) found
=============================================
BLOCKED: dist/index.js.map (matched: \.map$)
BLOCKED: dist/index.js contains external sourceMappingURL
BLOCKED: dist/utils.js contains inline sourceMappingURL

This check is enforced by a Pipeline Execution Policy. If this is a false positive, contact the security team to update the policy project or exclude this project.
</code></pre><p>このポリシーには、ユーザーが設定できるCI変数はありません。開発者が無効化したり回避したりすることはできません。例外はポリシーレベルでセキュリティチームが管理するため、意図的なプロセスと明確な監査証跡が確保されます。</p><p>リポジトリには意図的な違反を含むテストプロジェクト（examples/leaky-npm-package/）が含まれており、組織にデプロイする前にポリシーの動作を確認できます。<a href="https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/README.md" rel="">README</a>には、セットアップとデプロイの完全なクイックスタートガイドが含まれています。</p><p><strong>検出できる問題：</strong> これらのコントロールのどれか1つでもあれば、AI企業のソースコード流出は防げていた可能性があります。</p><ul><li>ソースマップファイルはファイルパターンのブロックリストに引っかかります。</li><li>59.8 MBというサイズはサイズゲートに引っかかります。</li><li>外部R2バケットを指すsourceMappingURLはURLスキャンに引っかかります。</li></ul><h3 id="ユースケース2依存関係の改ざんとロックファイル操作を検出する">ユースケース2：依存関係の改ざんとロックファイル操作を検出する</h3><p><strong>問題：</strong> axiosへの攻撃では、インストール時にRATを実行する悪意のある推移的依存関係（<code className="">plain-crypto-js</code>）が導入されました。侵害が行われた期間中にnpm installを実行したすべての人がトロイの木馬を取り込んでしまいました。</p><p><strong>PEPによるアプローチ：</strong> <a href="https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/dependency-integrity.gitlab-ci.yml" rel="">Dependency Integrityポリシー</a>は、パッケージエコシステム（npmまたはPython）を自動検出し、3つのチェックを実行する.pipeline-policy-preジョブを注入します。</p><p><strong>npmプロジェクトの場合</strong>（<code className="">package-lock.json</code>、<code className="">yarn.lock</code>、または<code className="">pnpm-lock.yaml</code>によってトリガー）：</p><ol><li><strong>ロックファイルの整合性。</strong> <code className="">npm ci --ignore-scripts</code>を実行します。<code className="">node_modules</code>の内容がロックファイルの指定と異なる場合、失敗します。これにより、package.jsonは更新されたがロックファイルが再生成されていないケースを検出し、SRIインテグリティハッシュも検証します。</li><li><strong>ブロックパッケージスキャン。</strong> ロックファイルの完全な依存関係ツリーを、侵害が確認済みのパッケージバージョンのGitLab管理リストである<code className="">blocked-packages.yml</code>と照合します。同梱のブロックリストには<code className="">axios@1.14.1</code>、<code className="">axios@0.30.4</code>、<code className="">plain-crypto-js@4.2.1</code>が含まれています。</li><li><strong>未宣言の依存関係の検出。</strong> インストール後、node_modulesの内容をロックファイルと比較します。ディスク上に存在するがロックファイルに存在しないパッケージは改ざんの証拠です（例：追加パッケージを取得する侵害されたpostinstallスクリプト）。</li></ol><p><strong>Pythonプロジェクトの場合</strong>（<code className="">requirements.txt</code>、<code className="">Pipfile.lock</code>、<code className="">poetry.lock</code>、または<code className="">uv.lock</code>によってトリガー）：</p><ol><li><strong>ロックファイルの整合性。</strong> 分離された仮想環境にインストールし、ロックファイルからのインストールが成功することを確認します。</li><li><strong>ブロックパッケージスキャン。</strong> 同じブロックリストのアプローチです。同梱リストには<code className="">litellm==1.82.7</code>および<code className="">litellm==1.82.8</code>が含まれています。</li><li><strong>.pthファイルの検出。</strong> site-packagesの<code className="">.pth</code>ファイルをスキャンし、実行可能なコードパターン（<code className="">import os</code>、<code className="">exec(</code>、<code className="">eval(</code>、<code className="">__import__</code>、<code className="">subprocess</code>、<code className="">socket</code>）を検出します。これはLiteLLMバックドアが使用したまさにその仕組みです。</li></ol><p>違反が検出されると：</p><pre className="language-text" code="=============================================
FAILED: 1 violation(s) found
=============================================
BLOCKED: axios@1.14.1 is a known-compromised package

This check is enforced by a Pipeline Execution Policy.
" language="text" meta=""><code>=============================================
FAILED: 1 violation(s) found
=============================================
BLOCKED: axios@1.14.1 is a known-compromised package

This check is enforced by a Pipeline Execution Policy.
</code></pre><p>このポリシーは<em>ストリクトモード</em>で動作します。コミット済みのロックファイルに存在しない依存関係は、パイプラインをブロックします。開発者が依存関係を追加する必要がある場合は、更新されたロックファイルをコミットします。ポリシーはインストールされたバージョンがコミットされたバージョンと一致することを確認します。コミットされていないものが現れた場合（例：侵害されたアップストリームパッケージ経由で注入された推移的依存関係）、パイプラインはブロックされます。</p><p><strong>検出できる問題：</strong> <code className="">plain-crypto-js</code>という新規かつ未確認の依存関係の導入は、未宣言の依存関係チェックによってフラグが立てられます。<code className="">axios@1.14.1</code>バージョンはブロックパッケージスキャンによって検出されます。LiteLLMの<code className="">.pth</code>ファイルは<code className="">.pth</code>検出チェックによって検出されます。各攻撃に対して、少なくとも1つ、多くの場合は2つの独立した検出シグナルがあります。</p><h3 id="ユースケース3侵害されたツールを実行前に検出ブロックする">ユースケース3：侵害されたツールを実行前に検出・ブロックする</h3><p><strong>問題：</strong> TeamPCPは、信頼できるTrivyとCheckmarxのGitHubアクションタグを悪意のあるバージョンに置き換えました。これらのタグを参照するパイプラインはすべて、認証情報を窃取するマルウェアを実行してしまいました。</p><p><strong>PEPによるアプローチ：</strong> <a href="https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/tool-integrity.gitlab-ci.yml" rel="">Tool Integrityポリシー</a>は、GitLab CI Lint API（またはフォールバックとして<code className="">.gitlab-ci.yml</code>を評価する仕組み）にクエリを発行し、コンテナイメージの参照を抽出して、セキュリティチームが管理する承認済みイメージ許可リストと照合する<code className="">.pipeline-policy-pre</code>ジョブを注入します。</p><p>許可リスト（<code className="">approved-images.yml</code>）は、イメージごとに3つの制御をサポートしています。</p><p><strong>承認済みリポジトリ：</strong> リスト上のリポジトリからのイメージのみが許可されます。未知のリポジトリはパイプラインをブロックします。</p><p><strong>許可されているタグ：</strong> 承認済みリポジトリ内でも、特定のタグのみが許可されます。これにより、未テストバージョンへの移行を防ぎます。</p><p><strong>ブロックされているタグ：</strong> リポジトリが承認済みであっても、既知の侵害バージョンを明示的にブロックできます。同梱の許可リストは、TeamPCPがトロイの木馬化した正確なバージョンである<code className="">aquasec/trivy:0.69.4</code>から<code className="">0.69.6</code>をブロックします。</p><p>違反が検出されると、他のジョブが実行される前にパイプラインが失敗します。</p><pre className="language-text" code="=============================================
FAILED: 1 violation(s) found
=============================================
BLOCKED: aquasec/trivy:0.69.4 (job: trivy-scan)

 - tag &#39;0.69.4&#39; is known-compromised

This check is enforced by a Pipeline Execution Policy.
" language="text" meta=""><code>=============================================
FAILED: 1 violation(s) found
=============================================
BLOCKED: aquasec/trivy:0.69.4 (job: trivy-scan)

 - tag &#39;0.69.4&#39; is known-compromised

This check is enforced by a Pipeline Execution Policy.
</code></pre><p>許可リストは、ポリシープロジェクトに対するMRを通じて管理されます。新しい承認済みイメージを追加するには、セキュリティチームがMRを開きます。新たな侵害への対応には、ブロックするタグを追加するだけです。コードの変更は不要で、YAMLだけで管理できます。</p><p><strong>検出できる問題：</strong> 未承認のタグを持つイメージが検出されると、ポリシーはイメージのリポジトリ名とタグを許可リストと照合します。一致しない場合、スキャナーが実行される前にパイプラインをブロックし、認証情報の外部送信を防ぎます。</p><p><em>注：上記のサンプルを拡張することで、PEPをタグではなくダイジェストへのピン留めを強制するために使用できます。これはforce pushに対して耐性があります。このサンプルは、より基本的なタグベースの適用パターンを示しています。</em></p><h2 id="pepを超えてgitlabのサプライチェーン防御">PEPを超えて：GitLabのサプライチェーン防御</h2><p>パイプライン実行ポリシーは適用のレイヤーですが、サプライチェーン保護において多層防御（defense-in-depth）戦略の一部として機能するときに最大の効果を発揮します。GitLabは、サプライチェーン保護においてPEPを補完するいくつかの機能を提供しています。</p><h3 id="シークレット検出">シークレット検出</h3><p><a href="https://docs.gitlab.com/ja-jp/user/application_security/secret_detection/" rel="">GitLabのシークレット検出</a>は、認証情報がそもそもリポジトリに入り込むことを防ぎ、侵害されたパイプラインツールが収集できる情報を大幅に削減します。2026年3月の攻撃の文脈では：</p><ul><li>リポジトリに保存された認証情報は、攻撃者にとって発見しやすく、ローテーションも遅くなります。Trivyのインシデントでは、ローテーションプロセス自体も悪用されました。Aqua Securityのローテーションはアトミックではなく、攻撃者は古いトークンが完全に失効する前に新たに発行されたトークンを取得しました。GitLabのシークレット検出には、漏洩したGitLabトークンの自動失効機能と、サードパーティプロバイダーへの認証情報失効通知を行うパートナーAPIが含まれており、侵害発生時の対応を迅速化します。</li><li>シークレット検出と適切なシークレット管理（短命トークン、Vault基盤の認証情報、パイプラインシークレットへの最小限の露出）を組み合わせることで、信頼済みツールが悪意を持つ動作をした場合でも、攻撃者がアクセスできる範囲を制限します。</li></ul><h3 id="ソフトウェアコンポジション解析scaによる依存関係スキャン">ソフトウェアコンポジション解析（SCA）による依存関係スキャン</h3><p>GitLabの<a href="https://docs.gitlab.com/ja-jp/user/application_security/dependency_scanning/" rel="">依存関係スキャン</a>は、ロックファイルとマニフェストを解析することで、プロジェクトの依存関係における既知の脆弱性を特定します。2026年3月の攻撃の文脈では：</p><ul><li>LiteLLMについては、侵害されたバージョン（1.82.7、1.82.8）がGitLabのアドバイザリデータベースで追跡されており、影響を受けるPythonプロジェクトに自動的にフラグを立てます。</li><li>axiosについては、依存関係スキャンが組織内のすべてのプロジェクトで侵害されたバージョン（1.14.1、0.30.4）を特定し、セキュリティチームに影響範囲の評価と認証情報ローテーションの優先順位付けのための一元的なビューを提供します。</li><li>同様に、TeamPCPのCanisterWorm伝播によって侵害されたすべてのnpmパッケージも、使用されている場合はフラグが立てられます。</li></ul><p><a href="https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/" rel="">GitLabコンテナスキャン</a>は、デプロイメントで使用される脆弱なコンテナイメージを検出します。Trivyの侵害については、コンテナスキャンがコンテナレジストリまたはデプロイメントマニフェストに現れたトロイの木馬化されたTrivyのDockerイメージ（0.69.4〜0.69.6）にフラグを立てます。</p><h3 id="マージリクエスト承認ポリシー">マージリクエスト承認ポリシー</h3><p><a href="https://docs.gitlab.com/ja-jp/user/application_security/policies/merge_request_approval_policies/" rel="">マージリクエスト承認ポリシー</a>は、依存関係のロックファイルやCI/CD設定への変更がマージされる前にセキュリティチームの承認を必須とすることができます。これにより、サプライチェーン攻撃が一般的に導入する種類の変更に対して、人間によるチェックポイントが確保されます。</p><h3 id="近日公開予定依存関係ファイアウォールアーティファクトレジストリslsaレベル3の認証と検証">近日公開予定：依存関係ファイアウォール、アーティファクトレジストリ、SLSAレベル3の認証と検証</h3><p>今後予定されているGitLabのサプライチェーンセキュリティ機能は、レジストリとパイプラインという2つの重要なコントロールポイントにおけるポリシー適用を強化します。依存関係ファイアウォールとアーティファクトレジストリは非準拠のパッケージをブロックし、SLSAレベル3の認証によってアーティファクトが承認されたパイプラインで生成され、改ざんされていないという暗号学的な証明が提供されます。これらを組み合わせることで、セキュリティチームはソフトウェアサプライチェーンへの入出力を検証可能な形で管理できるようになります。</p><h2 id="あなたの組織にとっての意味">あなたの組織にとっての意味</h2><p>AI支援型の脅威が高まる中、CI/CDパイプラインへの攻撃はますます一般的になっています。TeamPCPのキャンペーンは、1つの侵害された認証情報が信頼済みツールのエコシステム全体にどう波及するかを示しています。</p><p>影響を受けたコンポーネントを使用していた場合は、すべてのパイプラインシークレットが露出したという前提で行動してください。直ちにローテーションし、永続的なバックドアがないかシステムを監査してください。いずれの場合も、認証情報を定期的にローテーションし、短命トークンを使用することで、将来の侵害のブラスト半径を制限できます。</p><p>推奨事項をまとめます：</p><ol><li><strong>可能な限り、依存関係をチェックサムにピン留めしてください。</strong> TeamPCPが悪用した可変バージョンタグは、セキュリティ境界ではありません。すべての<a href="https://docs.gitlab.com/ja-jp/ci/components/#manage-dependencies" rel="">CI/CDコンポーネント</a>、アクション、コンテナイメージにはSHAピン留め参照を使用してください。</li><li><strong>実行前の整合性チェックを実行してください。</strong> パイプライン実行ポリシーを使用して、パイプラインジョブが実行される<em>前</em>にツールと依存関係の整合性を確認してください。これが<code className="">.pipeline-policy-pre</code>ステージです。</li><li><strong>公開するものを監査してください。</strong> すべてのパッケージ公開ステップには、アーティファクトの内容を自動検証する処理を含めてください。ソースマップ、環境ファイル、内部設定はビルド環境から外部に出すべきではありません。<a href="https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies" rel="">Supply Chain Policy</a>プロジェクトは、npm、Docker、Helmアーティファクトのすぐにデプロイできる出発点を提供しています。</li><li><strong>依存関係のドリフトを検出してください。</strong> すべてのパイプライン実行において、依存関係の解決結果をコミット済みロックファイルと比較してください。予期しない新しい依存関係を監視します。</li><li><strong>ポリシー管理を集中化してください。</strong> セキュリティチェックを含めることを開発者の記憶に頼らないでください。開発者が削除やスキップをできないポリシーを通じて、グループまたはインスタンスレベルで適用してください。</li><li><strong>セキュリティツール自体が標的になると想定してください。</strong> 脆弱性スキャナー、静的アプリケーションセキュリティテスト（SAST）ツール、AIゲートウェイは侵害される可能性があります。各ツールの権限は最低限必要なものに限定し、その他へのアクセスが不可能であることを確認してください。</li></ol><h2 id="gitlabでパイプラインを保護する">GitLabでパイプラインを保護する</h2><p>2週間にわたり、攻撃者はソフトウェア開発エコシステムで最も広く採用されているツールの一部を使用している組織の本番パイプラインを侵害しました。</p><p>教訓は明確です。ビルドパイプラインには、ネットワークやクラウドインフラに適用するのと同じレベルの集中管理されたポリシー駆動の保護が必要です。</p><p>GitLabパイプライン実行ポリシーは、その適用レイヤーを提供します。個々のプロジェクト設定に関わらず、すべてのプロジェクトのすべてのパイプラインでセキュリティチェックが実行されることを保証します。依存関係スキャン、シークレット検出、マージリクエスト承認ポリシーと組み合わせることで、2026年3月に見られたクラスの攻撃をブロック、検出、封じ込めることができます。</p><p><a href="https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies" rel="">Supply Chain Policies</a>プロジェクトは、大手AI企業の流出事故の背後にある種類のエラーを正確に検出する、動作するパイプライン実行ポリシーを提供しています。npmパッケージ、Dockerイメージ、Helmチャートに対応しています。クローンして、グループにデプロイし、今後のサプライチェーン攻撃に備えてすべてのパイプラインを準備してください。</p><p>集中管理されたパイプラインポリシーを始めるには、<a href="https://about.gitlab.com/ja-jp/free-trial/devsecops/" rel="">GitLab Ultimateの無料トライアル</a>にサインアップしてください。</p><p><em>このブログ記事には、1933年証券法第27A条（改正済み）および1934年証券取引法第21E条の意味における「将来の見通しに関する記述」が含まれています。これらの記述に反映された予想は合理的であると信じておりますが、実際の結果や成果を大幅に異なるものにする可能性のある既知および未知のリスク、不確実性、前提条件、その他の要素の影響を受けることがあります。これらのリスクおよびその他の要素に関するさらなる情報は、SECへの提出書類の「リスク要因」という見出しの下に記載されています。法律で要求される場合を除き、このブログ投稿の日付以降にこれらの記述を更新または修正する義務を負いません。</em></p>]]></content>
        <author>
            <name>Grant Hickman</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/grant-hickman/</uri>
        </author>
        <published>2026-04-07T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[チームの計画がはかどる、GitLab 18.10のアジャイル新機能]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/agile-planning-gets-a-boost-from-new-features-in-gitlab-18-10/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/agile-planning-gets-a-boost-from-new-features-in-gitlab-18-10/"/>
        <updated>2026-03-23T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>GitLabのアジャイル計画体験が大幅に強化されます。 GitLab 18.10から導入される新しいワークアイテムリストと保存済みビューにより、長年要望の多かった2つの機能が実現します。すべてのワークアイテムタイプを一覧表示する統合リストと、カスタマイズしたリスト設定を保存して再利用できる保存済みビューです。</p><p>これらの機能により、以下のことが可能になります。</p><ul><li>日常のワークフローにおいて繰り返し設定する必要のあったフィルター設定が不要になります</li><li>チーム全体が統一された方法で作業を確認・評価できます</li><li>標準化されたレポート作成やステータス確認が容易になります</li></ul><h2 id="ワークアイテムとは">ワークアイテムとは？</h2><p>これまで、エピックとイシューはそれぞれ別のリストページに存在していたため、ユーザーはページ間を行き来する必要がありました。ワークアイテムリストは、エピック・イシューをはじめとするすべてのワークアイテムタイプを単一の統合リストにまとめ、異なるワークアイテムタイプごとにページを切り替える手間をなくします。</p><p>この機能は、今後提供予定のより高度な計画機能の基盤でもあります。すべてのワークアイテムタイプを一か所に集約することで、エピック・イシューなどのアイテム間の関係性や構造を一目で把握できる階層ビュー（テーブルビューなど）の実現への道が開かれます。</p><p>リストビューや階層ビューにとどまらず、ボードなどの他の一般的なワークフローもこの統合された体験に組み込んでいく予定です。その結果、計画に必要なすべてのビューが一か所に集まり、保存済みビューを通じてチームと共有できるようになります。製品の異なる部分をまたいで移動する必要はなくなります。</p><p>なぜ「イシュー」ではなく「ワークアイテム」と呼ぶのか、疑問に思われるかもしれません。簡単に言うと、「イシュー」という言葉は今後の展開に対応できないからです。近い将来、ワークアイテムタイプは、その名称も含めて自由に設定し、組織のプランニング階層に合わせてカスタマイズできるようになります。既存の名称に縛られた体験では、その柔軟性が損なわれてしまいます。「ワークアイテム」は、独自の裁量で作成できるモデルの基盤となる概念です。</p><p><img alt="ワークアイテムリストのビュー" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1774028606/ae9ugijwjsyv3ktiks0n.png" /></p><h2 id="ワークアイテムへの移行の背景は">ワークアイテムへの移行の背景は？</h2><p>2024年、私たちはワークアイテムフレームワークを基盤とした<a href="https://about.gitlab.com/blog/first-look-the-new-agile-planning-experience-in-gitlab/" rel="">GitLabにおける新しいアジャイル計画体験のビジョン</a>を発表しました。その記事では、エピックとイシューが別々の体験として存在していたため、計画オブジェクト全体で一貫した機能を期待するチームとは齟齬が生じていたという核心的な問題を説明しました。その解決策といして登場したのがワークアイテムフレームワークです。一貫性を実現し、GitLabの計画ツール全体で新たな機能を実現可能にするために設計された統合アーキテクチャです。ワークアイテムリストと保存済みビューは、その道のりにおける一歩です。</p><h2 id="保存済みビューとは">保存済みビューとは？</h2><p>保存済みビューを使用すると、フィルター・並び替え順・表示オプションを含むカスタマイズされたリスト設定を保存し、後から呼び出すことができます。日常的な確認作業を効率化し、チーム全体で一貫した標準的な作業確認方法をサポートすることを目的としています。</p><p><img alt="Saved view" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1774028606/izmg27ckskpkdofgvonr.png" /></p><h2 id="今後の展望">今後の展望</h2><p>GitLabが行っている変更の理由を理解するには、GitLabが目指す先をイメージしていただくことが助けになります。</p><p>目標は単なるワークアイテムリストではありません。現在のフィルタースコープを保持しながら、さまざまなビュータイプ（リスト・ボード・テーブルなど）をスムーズに切り替えられる計画体験の実現です。</p><p>そこに保存済みビューを組み合わせることで、各ワークフロー専用のビューを作成できます。イテレーションプランニング、バックログリファインメント、ネストされたテーブルビューを使ったポートフォリオレベルの計画など、さまざまな用途に対応します。</p><p>各ビューはすぐに使える状態で、フィルタリングや作業の表示方法が統一されており、チームと共有することができます。このフレームワークは、ボードのあらゆるワークアイテム属性に対するフルスイムレーンサポートなど、今後のより強力な機能実現への道も開きます。</p><p>日々使用しているツールの変更が、作業の妨げになることは十分に理解しています。既存のエピックおよびイシューリストページを中心としたワークフローを構築されている場合、見た目や使い心地は変わるでしょう。決してその点を軽く考えているわけではありません。</p><p>この方針は短期間で決めたものではありません。長年にわたるフィードバック、ワークアイテムフレームワークへの多大なアーキテクチャ投資、そして統合された体験が長期的にチームをより良くサポートできるという確信を反映したものです。移行には慣れが必要だと思いますが、皆さまのご意見をもとに継続的に改善を重ねてまいります。</p><h2 id="フィードバックをお聞かせください">フィードバックをお聞かせください</h2><p>ぜひこれらの新機能をお試しください。そして、ワークアイテムリストと保存済みビューについてのご意見を<a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/590689" rel="">フィードバックイシュー</a>にてお知らせください。皆さまのコメントが、これらの機能のさらなる改善につながります。</p>]]></content>
        <author>
            <name>Matthew Macfarlane</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/matthew-macfarlane/</uri>
        </author>
        <published>2026-03-23T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLab 18.10リリース]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/gitlab-18-10-release/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/gitlab-18-10-release/"/>
        <updated>2026-03-19T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>本ブログは、<a href="https://about.gitlab.com/releases/2026/03/19/gitlab-18-10-released/" rel="">GitLab 18.10 Release</a>の抄訳です。内容に相違がある場合は、原文が優先されます。</p><h1 id="gitlab-1810リリース">GitLab 18.10リリース</h1><h2 id="エージェント型sastの誤検出判定機能とfreeでのクレジット購入に対応したgitlab-1810をリリース">エージェント型SASTの誤検出判定機能とFreeでのクレジット購入に対応したGitLab 18.10をリリース</h2><p>このたび、SASTの誤検出判定（GitLab Duo Agent Platform対応）、Freeでのクレジット購入、パスキーによる安全なサインイン、作業アイテムリストと保存済みビューなど、さまざまな新機能を搭載したGitLab 18.10のリリースを発表しました。</p><p>これらの機能は、今回のリリースに含まれる60件以上の改善点のほんの一部です。以下で、すべてのアップデートをご確認ください。</p><p>GitLabコミュニティの皆さまからは、GitLab 18.10に対して212件ものコントリビュートをいただきました。GitLabでは<a href="https://about.gitlab.com/community/contribute/" rel="">誰でもコントリビュート可能</a>です。皆さまのご協力に心より感謝いたします。</p><p>来月のリリース予定については、<a href="https://about.gitlab.com/releases/whats-new/" rel="">What&#39;s newページ</a>をご覧ください。</p><hr /><p><img alt="notable-contributor-logo" src="https://about.gitlab.com/images/notable-contributor-logo.svg" /></p><h2 id="notable-contributor注目のコントリビューター">Notable Contributor（注目のコントリビューター）</h2><p>今月の<a href="https://contributors.gitlab.com/docs/notable-contributors" rel="">Notable Contributor</a>は、<a href="https://gitlab.com/official.harshith1" rel="">Harshith Sudar</a>さんです。</p><p>Harshithさんは現在レベル3のコントリビューターであり、コミュニティツールやアナリティクスの改善に大きくコントリビュートしています。トリアージの自動化、コントリビューター表彰機能から<a href="https://about.gitlab.com/gitlab-duo/" rel="">GitLab Duo</a>の使用状況インサイトまで、幅広い領域でインパクトのあるコントリビュートを続けています。</p><p>Harshithさんのコントリビュートは、GitLabのDevRelエンジニアリング部門のフルスタックエンジニアである<a href="https://gitlab.com/leetickett-gitlab" rel="">Lee Tickett</a>氏が最初に認め、推薦しました。Harshithさんの取り組みは、自動化やコントリビューター向けエクスペリエンスの改善を通じて、舞台裏からコントリビューターを支える仕組みを強化しています。例えば、triage-opsの<code className="">IssueSummary</code>プロセッサーを<a href="https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/3589" rel="">複数プロジェクトに対応させるよう更新</a>し、<a href="https://contributors.gitlab.com" rel="">contributors.gitlab.com</a>を含むコミュニティプロジェクト全体のサマリー作成と可視化を容易にしました。また、<a href="https://gitlab.com/gitlab-org/developer-relations/contributor-success/contributors-gitlab-com/-/merge_requests/1250" rel="">新しい「コンテンツ追加」ボタンとフロー</a>の実装により、コントリビューターが自身のプロフィールからブログ記事、動画、その他のコンテンツを直接登録し、リワードを獲得できるようになりました。</p><p>さらに、アナリティクスやGitLab Duoの使用状況インサイトにもコントリビュートしています。主な成果として、<a href="https://gitlab.com/gitlab-org/gitlab/-/merge_requests/207511" rel="">GitLab Duoの使用量算出方法の改善</a>、<a href="https://gitlab.com/gitlab-org/gitlab/-/merge_requests/218870" rel="">180日間のデフォルト制限の撤廃</a>によるAIの長期的な影響分析の改善、<a href="https://gitlab.com/gitlab-org/gitlab/-/merge_requests/216715" rel="">DORAメトリクスの日付範囲定数の統合</a>、そして<a href="https://gitlab.com/gitlab-org/gitlab/-/merge_requests/207796" rel="">バリューストリームアナリティクスのカスタムステージラベルピッカーへの無限スクロール追加</a>によるスケーラブルなアナリティクス体験の向上があります。これらの変更により、チームは実際のプロジェクトにおけるGitLabの活用状況をより深く理解できるようになりました。</p><p>Harshithさんのコメント：</p><blockquote><p>「コントリビュート活動を通じて特に楽しんでいるのは、コミュニティ内でアイデアが丁寧に議論されるプロセスです。<a href="https://gitlab.com/gitlab-org/developer-relations/contributor-success/contributors-gitlab-com/-/merge_requests/1288" rel="">MR !1288</a>に関するディスカッションのように、提案が協力的に検討される様子は大変励みになり、素晴らしい学習体験にもなりました。このコミュニティの一員であることを嬉しく思っており、今後もさらに多くのコントリビュートを続けていきたいと考えています。」</p></blockquote><p>Harshithさん、GitLabのコードベースとコントリビューターエクスペリエンスの向上へのご尽力、ありがとうございます。</p><p>Harshithさんとつながり、コントリビュートの詳細を知りたい方は、<a href="https://gitlab.com/official.harshith1" rel="">GitLabプロフィール</a>および<a href="https://www.linkedin.com/in/harshith-s-a44169282/" rel="">LinkedInプロフィール</a>をご覧ください。</p><hr /><h2 id="gitlab-1810の主な改善点">GitLab 18.10の主な改善点</h2><h2 id="sastの誤検出判定gitlab-duo-agent-platform対応">SASTの誤検出判定（GitLab Duo Agent Platform対応）</h2><blockquote><p>GitLab.com: Ultimate、Duo Core、Duo Pro、Duo Enterprise<br />
Self-Managed: Ultimate、Duo Core、Duo Pro、Duo Enterprise<br />
GitLab Dedicated: Ultimate、Duo Core、Duo Pro、Duo Enterprise</p></blockquote><p>GitLab 18.7でベータ版として導入されたSASTの誤検出判定機能が、GitLab 18.10で一般提供開始となりました。</p><p>セキュリティスキャンの実行時に、GitLab Duo Agent Platformが重大度「致命的」および「高」のSAST脆弱性を自動分析し、誤検出の可能性を判定します。評価結果は脆弱性レポートに直接表示されるため、チームは不確実性に悩まされることなく、的確なトリアージを行えます。</p><p>主な機能は以下のとおりです。</p><ul><li><strong>自動分析</strong>: セキュリティスキャンのたびに、手動操作なしで誤検出判定が自動実行されます。</li><li><strong>手動実行オプション</strong>: 脆弱性の詳細ページから、個別の脆弱性に対してオンデマンドで誤検出判定を手動実行することも可能です。</li><li><strong>重大な検出結果に集中</strong>: 「致命的」と「高」の重大度のSAST脆弱性に限定して分析を行うことで、最も重要な部分のノイズを効果的に削減します。</li><li><strong>コンテキストを踏まえたAI推論</strong>: 各評価では、コードのコンテキスト、データフロー、静的解析に特有の脆弱性特性を考慮し、検出結果が誤検出である可能性がある理由（または実際の脆弱性である理由）を説明します。</li><li><strong>既存ワークフローとのシームレスな統合</strong>: 結果は脆弱性レポート上で、既存の重大度、ステータス、修正情報と一緒に表示されるため、既存のワークフローを変更する必要はありません。</li></ul><p>この機能は、GitLab Duo Agent Platformが有効なUltimateのお客様がご利用いただけます。グループまたはプロジェクトの設定で機能を有効にする必要があります。フィードバックは<a href="https://gitlab.com/gitlab-org/gitlab/-/issues/583697" rel="">イシュー583697</a>からお寄せください。</p><p><a href="https://docs.gitlab.com/user/application_security/vulnerabilities/false_positive_detection" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/19789" rel="">エピック</a></p><p><img alt="SASTの誤検出判定（GitLab Duo Agent Platform対応）" src="https://about.gitlab.com/images/18_10/sast-false-positive-detection.png" /></p><hr /><h2 id="freeでの-gitlabクレジット購入gitlabcom">Freeでの GitLabクレジット購入（GitLab.com）</h2><blockquote><p>GitLab.com: Free、GitLab Credits</p></blockquote><p>GitLab.comのFreeグループのオーナーは、GitLabクレジットを購入してAI機能を利用できるようになりました。月額のクレジット購入量を設定し、年間契約にコミットすることで、<a href="https://docs.gitlab.com/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom" rel="">GitLab Duo Agent Platformのエージェントとフロー</a>にアクセスできます。クレジットは毎月自動的に更新されるため、チームは常に必要なリソースを確保し、より速く、よりスマートに開発を進められます。</p><p>主なポイントは以下のとおりです。</p><ul><li><strong>使用量ベースの料金体系</strong>: ベースプランのサブスクリプションなしで、月額のクレジットコミットメントを購入可能です。</li><li><strong>セルフサービスでの購入</strong>: GitLabの購入フローからクレジットを直接購入できます。</li><li><strong>シームレスなアップグレードパス</strong>: PremiumまたはUltimateに後からアップグレードした場合も、クレジットのコミットメントは引き継がれます。</li><li><strong>使用状況の追跡</strong>: GitLabクレジットダッシュボードからクレジットの使用状況を確認できます。</li></ul><p>この<a href="https://docs.gitlab.com/subscriptions/gitlab_credits/?tab=GitLab.com#buy-gitlab-credits" rel="">購入オプション</a>は、現在GitLab.comのFreeトップレベルグループのみで利用可能です。</p><p><a href="https://docs.gitlab.com/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/20165" rel="">エピック</a></p><p><img alt="Freeでの GitLabクレジット購入（GitLab.com）" src="https://about.gitlab.com/images/18_10/Free_Credits_Purchase_Image.png" /></p><hr /><h2 id="パスキーによる安全なサインイン">パスキーによる安全なサインイン</h2><blockquote><p>GitLab.com: Free、Premium、Ultimate<br />
Self-Managed: Free、Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>GitLabがパスワードレスサインインおよびフィッシング耐性のある2要素認証（2FA）方式としてパスキーに対応しました。パスキーは公開鍵暗号方式と生体認証（指紋、顔認証）またはデバイスのPINを使用して、アカウントに安全にアクセスする仕組みです。</p><p>パスキーの主なメリットは以下のとおりです。</p><ul><li><strong>パスワード不要の利便性</strong>: パスワードを覚える必要なく、デバイスの生体認証やPINでサインインできます。</li><li><strong>マルチデバイス対応</strong>: デスクトップブラウザー、モバイルデバイス（iOS 16以降、Android 9以降）、FIDO2/WebAuthn対応のハードウェアセキュリティキーでパスキーを利用できます。</li><li><strong>フィッシング耐性のあるセキュリティ</strong>: 秘密鍵はデバイスの外に出ることはありません。GitLabは公開鍵のみを保存するため、万が一GitLabサーバーが侵害された場合でもアカウントは保護されます。</li><li><strong>自動2FA統合</strong>: 2FAが有効なアカウントでは、パスキーがデフォルトの2FA方式として自動的に利用可能になります。</li></ul><p>パスキーの利用を開始するには、アカウント設定からパスキーを追加してください。ご質問やフィードバックは<a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/366758" rel="">イシュー366758</a>からお寄せください。</p><p><a href="https://docs.gitlab.com/auth/passkeys/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/10897" rel="">エピック</a></p><iframe width="560" height="315" src="https://www.youtube.com/embed/LN5MGRdTHR8?si=F0mcUAbEg0-dEYWu" title="YouTube video player" frameBorder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerPolicy="strict-origin-when-cross-origin" allowFullScreen></iframe><hr /><h2 id="作業アイテムリストと保存済みビューの導入">作業アイテムリストと保存済みビューの導入</h2><blockquote><p>GitLab.com: Free、Premium、Ultimate<br />
Self-Managed: Free、Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>GitLabのプランニング体験が、作業アイテムリストと保存済みビューにより大幅にアップグレードされます。長らくご要望いただいていた2つの機能をまとめてお届けします。</p><ul><li><strong>作業アイテムリスト</strong>は、エピック、イシュー、その他の作業アイテムを1つの統合されたリストにまとめ、作業アイテムの種類ごとに別々のページを切り替える必要をなくします。プランニングオブジェクト間の関係がより把握しやすくなります。</li><li><strong>保存済みビュー</strong>では、フィルター、ソート順、表示オプションを含むカスタマイズされたリスト構成を作成・保存できます。定期的な確認作業が効率化され、チーム全体での標準的な表示方法を確立できます。</li></ul><p>これは、GitLab作業アイテムの統一アーキテクチャに向けた次のステップであり、GitLabのプランニングツール全体での一貫性と新しい機能の実現を目指しています。</p><p>ご意見・フィードバックは<a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/590689" rel="">イシュー590689</a>からお寄せください。</p><p><a href="https://docs.gitlab.com/user/work_items/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/17530" rel="">エピック</a></p><p><img alt="作業アイテムリストと保存済みビュー" src="https://about.gitlab.com/images/18_10/work_items_list_and_saved_views.png" /></p><hr /><h2 id="カスタムエージェントがmcpで外部データにアクセス可能に">カスタムエージェントがMCPで外部データにアクセス可能に</h2><blockquote><p>GitLab.com: Premium、Ultimate</p></blockquote><p>AIカタログのカスタムエージェントを、Model Context Protocol（MCP）を通じて外部のデータソースやツールに接続できるようになりました。GitLabの外に出ることなく統合が可能です。</p><p>これは実験的機能です。フィードバックは<a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/593219" rel="">イシュー593219</a>からお寄せください。</p><p><a href="https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/ai_catalog_mcp_servers/" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/590708" rel="">イシュー</a></p><p><img alt="カスタムエージェントがMCPで外部データにアクセス可能に" src="https://about.gitlab.com/images/18_10/enable_custom_agents_to_access_external_data_via_mcp.png" /></p><hr /><h2 id="正規表現によるマージリクエストのタイトル命名規則の適用">正規表現によるマージリクエストのタイトル命名規則の適用</h2><blockquote><p>GitLab.com: Premium、Ultimate<br />
Self-Managed: Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>一貫性のあるマージリクエストのタイトルを維持することは、Conventional Commitsフォーマットや社内トラッキングシステムとの連携など、構造化された命名規則に依存しているチームにとって重要です。従来、こうした規則を適用するには外部ツールやカスタムCI/CDパイプラインジョブが必要でしたが、パイプライン実行後にマージリクエストのタイトルが変更された場合に再検証が行われず、非準拠のタイトルのままマージされてしまうという課題がありました。</p><p>プロジェクト設定でマージリクエストの必須タイトル正規表現を設定できるようになりました。設定後、GitLabはマージ可能性チェックとしてマージリクエストのタイトルをパターンに照合します。タイトルが準拠するまでマージがブロックされ、タイトルの最終変更時点にかかわらず常に検証が実施されます。</p><p>設定するには、プロジェクトの<strong>設定 &gt; マージリクエスト</strong>に移動し、<strong>Title must match required pattern</strong>（タイトルは正規表現に一致する必要があります）フィールドに正規表現パターンを入力してください。</p><p>既存のマージリクエストワークフローはこれまでどおり動作します。このチェックは、タイトル正規表現を明示的に設定したプロジェクトにのみ適用されます。</p><p><a href="https://docs.gitlab.com/user/project/merge_requests/title_validation/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/20108" rel="">エピック</a></p><p><img alt="正規表現によるマージリクエストのタイトル命名規則の適用" src="https://about.gitlab.com/images/18_10/create-enforce-mr-title-naming-convention.png" /></p><hr /><h2 id="aiによるシークレット誤検出判定ベータ版">AIによるシークレット誤検出判定（ベータ版）</h2><blockquote><p>GitLab.com: Ultimate、Duo Core、Duo Pro、Duo Enterprise<br />
Self-Managed: Ultimate、Duo Core、Duo Pro、Duo Enterprise<br />
GitLab Dedicated: Ultimate、Duo Core、Duo Pro、Duo Enterprise</p></blockquote><p>セキュリティチームは、テスト用クレデンシャル、サンプル値、プレースホルダートークンなど、実際のシークレットではないにもかかわらず誤って検出されるシークレット検出の誤検出の調査に多大な時間を費やしています。誤検出はアラート疲れを引き起こし、スキャン結果への信頼を損ない、本当のセキュリティリスクから注意をそらします。</p><p>GitLab 18.10では、AIを活用したシークレット誤検出判定（ベータ版）を導入し、本当に重要なシークレットに集中できるようにしました。セキュリティスキャンの実行時に、GitLab Duoが重大度「致命的」および「高」のシークレット検出の脆弱性を自動分析し、誤検出かどうかを判定します。</p><p>AIによる評価結果は脆弱性レポートに直接表示され、セキュリティエンジニアは即座にコンテキストを把握し、より迅速で確信を持ったトリアージを行えます。</p><p>主な機能は以下のとおりです。</p><ul><li><strong>自動分析</strong>: セキュリティスキャンのたびに、手動トリガーなしで誤検出判定が自動実行されます。</li><li><strong>手動トリガーオプション</strong>: 脆弱性の詳細ページから、個別の脆弱性に対してオンデマンドで誤検出判定を手動トリガーすることも可能です。</li><li><strong>重大な検出結果に集中</strong>: 「致命的」と「高」の重大度の脆弱性に限定し、シグナル対ノイズ比を最大化します。</li><li><strong>コンテキストを踏まえたAI推論</strong>: 各評価には、コードのコンテキストと脆弱性の特性に基づき、検出結果が真のポジティブである可能性がある理由（またはない理由）の説明が含まれます。</li><li><strong>信頼度スコア</strong>: 各検知には信頼度スコアが付与され、モデルの確信度に基づいてレビューの優先順位付けが可能です。</li><li><strong>既存ワークフローとのシームレスな統合</strong>: 結果は脆弱性レポート上で、既存の重大度、ステータス、修正情報と一緒に表示されます。</li></ul><p>この機能は、Ultimateのお客様に無料ベータとしてご利用いただけます。グループまたはプロジェクトの設定で有効にする必要があります。フィードバックは<a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/592861" rel="">イシュー592861</a>からお寄せください。</p><p><a href="https://docs.gitlab.com/user/application_security/vulnerabilities/secret_false_positive_detection/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/20152" rel="">エピック</a></p><p><img alt="AIによるシークレット誤検出判定（ベータ版）" src="https://about.gitlab.com/images/18_10/secret-false-positive-detection.png" /></p><hr /><h2 id="cicdジョブでのランタイムインプットの使用">CI/CDジョブでのランタイムインプットの使用</h2><blockquote><p>GitLab.com: Free、Premium、Ultimate<br />
Self-Managed: Free、Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>CI/CD変数を使用した動的なジョブ設定には課題がありました。変数は複雑なオーバーライド階層に従うため管理が難しく、さまざまなユースケースに対応できない場合がありました。</p><p>ジョブレベルで明示的な型付きインプットを定義する<code className="">inputs</code>が利用可能になりました。ジョブインプットを使用して、ジョブがランタイムで受け入れる値を定義・制御できます。ジョブインプットでは以下が可能です。</p><ul><li>型安全性（string、number、boolean、array）</li><li>静的な値または既存の変数を参照するデフォルト値</li><li>使用可能な値の厳密なリストの定義</li><li>インプット値を検証するための正規表現のサポート</li></ul><p>ジョブインプットは、ユーザーの操作なしにデフォルト値を使用できますが、ジョブのリトライ時や手動ジョブの実行時に値を変更することも可能です。</p><p><a href="https://docs.gitlab.com/ci/jobs/job_inputs/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/epics/17833" rel="">エピック</a></p><hr /><h2 id="gitlab-1810のその他の改善点">GitLab 18.10のその他の改善点</h2><h3 id="markdownテーブルでのタスクアイテムのサポート">Markdownテーブルでのタスクアイテムのサポート</h3><blockquote><p>GitLab.com: Free、Premium、Ultimate<br />
Self-Managed: Free、Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>Markdownのテーブルセル内でタスクアイテムのチェックボックス構文を直接使用できるようになりました。</p><p>従来、これを実現するにはHTMLとMarkdownの組み合わせが必要で、保守が困難でした。</p><p>この改善により、イシュー、エピック、その他のコンテンツ内の構造化されたテーブルレイアウトで、タスクの完了状況を直接追跡しやすくなりました。</p><p><a href="https://docs.gitlab.com/user/markdown/#task-lists-in-tables" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/21506" rel="">イシュー</a></p><hr /><h3 id="macos-tahoe-26およびxcode-26ジョブイメージ">macOS Tahoe 26およびXcode 26ジョブイメージ</h3><blockquote><p>GitLab.com: Premium、Ultimate</p></blockquote><p>macOS Tahoe 26とXcode 26を使用して、最新世代のAppleデバイス向けアプリケーションの作成、テスト、デプロイが可能になりました。</p><p><a href="https://docs.gitlab.com/ci/runners/hosted_runners/macos/" rel="">macOSのホステッドRunner</a>を利用することで、開発チームはGitLab CI/CDに統合された安全なオンデマンドビルド環境で、macOSアプリケーションをより迅速にビルド・デプロイできます。</p><p><code className="">.gitlab-ci.yml</code>ファイルで<code className="">macos-26-xcode-26</code>イメージを指定して、ぜひお試しください。</p><p><a href="https://docs.gitlab.com/ci/runners/hosted_runners/macos/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-com/gl-infra/-/work_items/1694" rel="">エピック</a></p><hr /><h3 id="gitlab-helmチャートレジストリが一般提供を開始">GitLab Helmチャートレジストリが一般提供を開始</h3><blockquote><p>GitLab.com: Free、Premium、Ultimate<br />
Self-Managed: Free、Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>Helmを使用してKubernetesアプリケーションのデプロイを管理しているチームは、GitLab Helmチャートレジストリを本番ワークロードに活用できるようになりました。ベータ版として提供されていたこのレジストリが、主要なアーキテクチャおよび信頼性の問題が解決されたことで、一般提供開始となりました。</p><p>一般提供に向けた主な改善として、1,000件を超えるチャートの<code className="">index.yaml</code>エンドポイントの制限の解消、新しく公開されたチャートバージョンがインデックスに反映されないバックグラウンドインデックスのバグ修正、AppSecセキュリティレビューの完了、GitLab Geoを使用したセルフマネージドのお客様向けの高可用性を確保するHelmメタデータキャッシュのGeoレプリケーションサポートの追加が含まれます。</p><p>プラットフォームチームおよびDevOpsチームは、パーソナルアクセストークン、デプロイトークン、CI/CDジョブトークンによる認証をサポートした標準的なHelmクライアントワークフローを使用して、HelmチャートをGitLabから直接公開・インストールできます。ソースコード、パイプライン、セキュリティスキャンとともにチャートを一元管理できるようになりました。</p><p><a href="https://docs.gitlab.com/user/packages/helm_repository/" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/573715" rel="">イシュー</a></p><hr /><h3 id="sbomベースの依存関係スキャンでjava-gradleビルドファイルに対応">SBOMベースの依存関係スキャンでJava Gradleビルドファイルに対応</h3><blockquote><p>GitLab.com: Ultimate<br />
Self-Managed: Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>SBOMを使用したGitLabの依存関係スキャンが、Javaの<code className="">build.gradle</code>および<code className="">build.gradle.kts</code>ビルドファイルのスキャンに対応しました。</p><p>従来、Gradleを使用したJavaプロジェクトの依存関係スキャンにはロックファイルが必要でした。今回のリリースでは、ロックファイルが存在しない場合、アナライザーが自動的に<code className="">build.gradle</code>および<code className="">build.gradle.kts</code>ファイルのスキャンにフォールバックし、脆弱性分析のために直接的な依存関係のみを抽出・レポートします。この改善により、Gradleを使用するJavaプロジェクトでロックファイルなしでも依存関係スキャンを容易に有効化できます。</p><p>マニフェストフォールバックを有効にするには、CI/CD変数<code className="">DS_ENABLE_MANIFEST_FALLBACK</code>を<code className="">&quot;true&quot;</code>に設定してください。</p><p><a href="https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/#manifest-fallback" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/588788" rel="">イシュー</a></p><hr /><h3 id="pubパッケージマネージャーを使用したdartflutterプロジェクトのライセンススキャン対応">Pubパッケージマネージャーを使用したDart/Flutterプロジェクトのライセンススキャン対応</h3><blockquote><p>GitLab.com: Ultimate<br />
Self-Managed: Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p><code className="">pub</code>パッケージマネージャーを使用したDartおよびFlutterプロジェクトのライセンススキャンに対応しました。従来、DartまたはFlutterで開発するチームは、オープンソース依存関係のライセンスをGitLab内で直接特定することができず、ライセンスポリシー要件を持つ組織にとってコンプライアンスの盲点となっていました。</p><p>ライセンスデータは、Dartの公式パッケージリポジトリである<a href="https://pub.dev" rel="">pub.dev</a>から直接取得され、他のサポートされているエコシステムとともに結果が表示されます。Dart/Flutterの依存関係スキャンと脆弱性検出は、すでにサポートされています。</p><p><a href="https://docs.gitlab.com/user/compliance/license_scanning_of_cyclonedx_files/#data-sources" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/18351" rel="">エピック</a></p><hr /><h3 id="クレジット使用データのcsvダウンロード">クレジット使用データのCSVダウンロード</h3><blockquote><p>GitLab.com: Premium、Ultimate<br />
Self-Managed: Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>請求管理者は、Customers PortalのGitLabクレジットダッシュボードからクレジットの使用データをCSVファイルとして直接ダウンロードできるようになりました。</p><p>エクスポートには、現在の請求月の日別・アクション別のクレジット消費の内訳が含まれ、コミットメント、免除、トライアル、オンデマンド、付属クレジットの使用状況が確認できます。</p><p>財務チームおよびオペレーションチームは、このデータを使用して手動でのデータ収集やサポートリクエストなしに、Excel、Googleスプレッドシート、BIツールでコスト配分、チャージバックレポート、使用状況分析を実施できます。</p><p><img alt="クレジット使用データのCSVダウンロード" src="https://about.gitlab.com/images/18_10/fulfillment-credits-dashboard-csv-export.png" /></p><p><a href="https://docs.gitlab.com/subscriptions/gitlab_credits/#export-usage-data" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/customers-gitlab-com/-/work_items/14504" rel="">イシュー</a></p><hr /><h3 id="gitlabクレジットダッシュボードでのユーザーソート">GitLabクレジットダッシュボードでのユーザーソート</h3><blockquote><p>GitLab.com: Premium、Ultimate<br />
Self-Managed: Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>エンタープライズ管理者は、GitLabクレジットダッシュボードの<strong>ユーザーごとの使用状況</strong>テーブルを、クレジット使用合計またはユーザー名でソートできるようになりました。</p><p>デフォルトのソート順は使用クレジット合計（降順）であるため、スクロールせずに最も使用量の多いユーザーをすぐに確認できます。</p><p>このビューにより、数千人のGitLab Duoユーザーを管理する管理者は、コスト配分、チャージバックレポート、ライセンス利用状況の監査のために使用量の多いユーザーを迅速に特定できます。</p><p><img alt="GitLabクレジットダッシュボードでのユーザーソート" src="https://about.gitlab.com/images/18_10/fulfillment-credits-dashboard-sorting.jpg" /></p><p><a href="https://docs.gitlab.com/subscriptions/gitlab_credits/#view-the-gitlab-credits-dashboard" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/customers-gitlab-com/-/work_items/15608" rel="">イシュー</a></p><hr /><h3 id="グループおよびインスタンスのコード検索に対応した-gitlab-blob-search">グループおよびインスタンスのコード検索に対応した GitLab Blob Search</h3><blockquote><p>GitLab.com: Free、Premium、Ultimate<br />
Self-Managed: Free、Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p><a href="https://docs.gitlab.com/user/duo_agent_platform/agents/tools/#:~:text=REST%20API%20endpoint.-,GitLab%20Blob%20Search,-gitlab_blob_search" rel=""><code className="">gitlab_blob_search</code></a>ツールにより、GitLab AIエージェントが以下の範囲でコード検索を実行できるようになりました。</p><ul><li>グループ内のすべてのプロジェクト</li><li>インスタンス上のアクセス可能なすべてのプロジェクト</li></ul><p>従来、Blob Searchは単一プロジェクトに限定されるか、明示的なプロジェクトIDの指定が必要でした。この変更により、AI搭載ワークフローで複数の関連プロジェクトにまたがるコードの発見と再利用が容易になりました。</p><p><a href="https://docs.gitlab.com/user/duo_agent_platform/agents/tools/#:~:text=REST%20API%20endpoint.-,GitLab%20Blob%20Search,-gitlab_blob_search" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/593221" rel="">イシュー</a></p><hr /><h3 id="exploreのプロジェクトの新しいナビゲーション体験">Exploreのプロジェクトの新しいナビゲーション体験</h3><blockquote><p>GitLab.com: Free、Premium、Ultimate<br />
Self-Managed: Free、Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p><strong>Explore</strong>のプロジェクトページを整理し、長い間蓄積されてきた冗長なオプションを削除しました。シンプルになったインターフェースは、2つの主要なビューに集中しています。</p><ul><li><strong>アクティブ</strong>タブ：最近のアクティビティがあり、開発が進行中のプロジェクトを確認できます。</li><li><strong>非アクティブ</strong>タブ：アーカイブされたプロジェクトや削除予定のプロジェクトにアクセスできます。</li></ul><p>冗長なタブを削除しました。</p><ul><li><strong>スター数が最も多い</strong>プロジェクトは、<strong>アクティブ</strong>または<strong>非アクティブ</strong>タブをスター数でソートすることで確認できます。</li><li><strong>すべて</strong>のプロジェクトは、<strong>アクティブ</strong>と<strong>非アクティブ</strong>の両方のタブを表示することで確認できます。</li><li><strong>トレンド</strong>タブは、機能の制限と低い利用率のため、GitLab 19.0で完全に削除されます。</li></ul><p>整理されたデザインは、他のプロジェクトリストとの視覚的な一貫性を確保しています。より論理的な構成と柔軟なソートオプションにより、従来と同じコンテンツにすべてアクセスできます。</p><p><img alt="Exploreのプロジェクトの新しいナビゲーション体験" src="https://about.gitlab.com/images/18_10/tenant_scale_explore_projects_ux_update.png" /></p><p><a href="https://docs.gitlab.com/user/project/working_with_projects/#explore-all-projects-on-an-instance" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/13786" rel="">エピック</a></p><hr /><h3 id="gitlab-duo-agent-platform向けセルフホストvertex-ai">GitLab Duo Agent Platform向けセルフホストVertex AI</h3><blockquote><p>Self-Managed: Premium、Ultimate</p></blockquote><p>GitLab Duo Agent Platform Self-Hostedで、Vertex AIがサポートされるLLMプラットフォームとして利用可能になりました。</p><p>Vertex AI上でホストされるAnthropicモデルを、GitLab Duo Agent Platform機能に使用するよう設定できるようになりました。</p><p><a href="https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_llm_serving_platforms/#configure-authentication-with-google-vertex-ai" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/591604" rel="">イシュー</a></p><hr /><h3 id="プロジェクトからエージェントとフローを直接有効化">プロジェクトからエージェントとフローを直接有効化</h3><blockquote><p>GitLab.com: Premium、Ultimate<br />
Self-Managed: Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>メンテナーおよびオーナーが、現在のコンテキストを離れることなく、プロジェクトまたはExploreページから直接エージェントとフローを有効化できるようになりました。</p><p>トップレベルグループのオーナーは、グループおよびエージェントやフローを有効にする特定のプロジェクトも選択でき、ワークフローの設定を効率化できます。</p><p><a href="https://docs.gitlab.com/user/duo_agent_platform/agents/custom/#enable-an-agent" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/588012" rel="">イシュー</a></p><hr /><h3 id="gitlab-runner-1810">GitLab Runner 18.10</h3><blockquote><p>GitLab.com: Free、Premium、Ultimate<br />
Self-Managed: Free、Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>GitLab Runner 18.10もリリースしました。GitLab Runnerは、CI/CDジョブを実行し、結果をGitLabインスタンスに返送する高いスケーラビリティを備えたビルドエージェントです。GitLab Runnerは、GitLabに含まれるオープンソースの継続的インテグレーションサービスであるGitLab CI/CDと連携して動作します。</p><h4 id="新機能">新機能:</h4><ul><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39085" rel="">ビルドポッドのPodレベルリソースをKubernetes Runnerで定義可能に</a></li><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39192" rel="">すべてのRunnerプロジェクトのGoバージョンおよびパッケージ更新を自動化</a></li></ul><h4 id="バグ修正">バグ修正:</h4><ul><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/39105" rel="">RoleARNを使用したS3キャッシュが、キャッシュ未存在時に404ではなく403を返す問題を修正</a></li><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/37872" rel="">ヘルパーイメージ<code className="">gitlab-runner-helper:x86_64-v16.11.1-nanoserver21H2</code>使用時に<code className="">init-permissions</code>エラーが発生する問題を修正</a></li><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/28136" rel="">macOS: LaunchAgent - M1アーキテクチャでサービスが初期化できない問題を修正</a></li></ul><p>すべての変更点のリストは、GitLab Runnerの<a href="https://gitlab.com/gitlab-org/gitlab-runner/blob/18-10-stable/CHANGELOG.md" rel="">CHANGELOG</a>をご覧ください。</p><p><a href="https://docs.gitlab.com/runner" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/boards/9726167?label_name%5B%5D=group%3A%3Arunner%20core&amp;milestone_title=18.10" rel="">イシューボード</a></p><hr /><h3 id="conan-20パッケージレジストリのサポートベータ版">Conan 2.0パッケージレジストリのサポート（ベータ版）</h3><blockquote><p>GitLab.com: Free、Premium、Ultimate<br />
Self-Managed: Free、Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>パッケージマネージャーとしてConanを使用するCおよびC++開発チームから、GitLabでのレジストリサポートが長く求められていました。従来、Conanパッケージレジストリは実験的機能の段階でConan 1.xクライアントのみをサポートしていたため、最新のConan 2.0ツールチェーンに移行したチームの採用には限界がありました。</p><p>Conanパッケージレジストリが、Conan 2.0に対応し、実験的機能からベータ版に昇格しました。今回のリリースでは、v2 API完全互換性、レシピリビジョンサポート、検索機能の改善、<code className="">--force</code>フラグを含むアップロードポリシーの適切な処理が含まれます。標準的なConanクライアントワークフローを使用して、Conan 2.0パッケージをGitLabから直接公開・インストールでき、JFrog Artifactoryなどの外部アーティファクト管理ソリューションへの依存を軽減できます。</p><p>このアップデートにより、CおよびC++の依存関係を管理するプラットフォームエンジニアリングチームは、ソースコード、CI/CDパイプライン、セキュリティスキャンとともにパッケージ管理をGitLab内で一元化できます。Conanレジストリはプロジェクトレベルおよびインスタンスレベルのエンドポイントに対応しており、パーソナルアクセストークン、デプロイトークン、CI/CDジョブトークンによる認証が可能です。</p><p>一般提供に向けた改善にご協力ください。ご利用の感想は<a href="https://gitlab.com/groups/gitlab-org/-/work_items/6816" rel="">エピック</a>からお寄せください。</p><p><a href="https://docs.gitlab.com/user/packages/conan_2_repository/" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/585819" rel="">イシュー</a></p><hr /><h3 id="専用uiでのコンテナ仮想レジストリの管理ベータ版">専用UIでのコンテナ仮想レジストリの管理（ベータ版）</h3><blockquote><p>GitLab.com: Premium、Ultimate<br />
Self-Managed: Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>前回のマイルストーンでコンテナ仮想レジストリがベータとして提供開始された際、プラットフォームエンジニアは複数のアップストリームコンテナレジストリ（Docker Hub、Harbor、Quayなど）を単一のプルエンドポイントの背後に集約できるようになりました。しかし、すべての設定にはAPI呼び出しが直接必要であり、レジストリの作成・管理、アップストリームの設定、変更の処理にスクリプトや手動のcurlコマンドを維持する必要がありました。</p><p>コンテナ仮想レジストリをGitLab UIから直接作成・管理できるようになりました。グループレベルのコンテナレジストリページから、新しい仮想レジストリの作成、認証情報を含むアップストリームソースの設定、既存の構成の編集、不要になったレジストリの削除が可能です。GitLabを離れたりAPI呼び出しを記述したりする必要はありません。UIは既存のコンテナレジストリ体験とシームレスに統合されており、仮想レジストリがグループのアーティファクト管理ワークフローの中でファーストクラスの機能となりました。</p><p>この機能はベータ版です。フィードバックは<a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/589630" rel="">フィードバックイシュー</a>からお寄せください。</p><p><a href="https://docs.gitlab.com/user/packages/virtual_registry/container/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/19283" rel="">エピック</a></p><hr /><h3 id="sbomベースの依存関係スキャンがセルフマネージドに拡張">SBOMベースの依存関係スキャンがセルフマネージドに拡張</h3><blockquote><p>GitLab.com: Ultimate<br />
Self-Managed: Ultimate</p></blockquote><p>GitLab 18.10では、新しいSBOMベースの依存関係スキャン機能の限定提供ステータスをセルフマネージドインスタンスに拡張しました。</p><p>この機能は、GitLab 18.5でGitLab.comのみを対象とした限定提供として初めてリリースされ、フィーチャーフラグ<code className="">dependency_scanning_sbom_scan_api</code>の下でデフォルトでは無効化されていました。</p><p>追加の改善と修正により、新しいSBOMスキャン内部APIを確実に使用できるようになり、このフィーチャーフラグをデフォルトで有効化しました。この内部APIにより、依存関係スキャンアナライザーは全コンポーネントの脆弱性を含む依存関係スキャンレポートを生成します。CI/CDパイプライン完了後にSBOMレポートを処理していた従来の動作（ベータ版）とは異なり、<a href="https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/#how-it-scans-an-application" rel="">改善されたプロセス</a>ではCI/CDジョブ実行中にスキャン結果を即座に生成し、カスタムワークフロー向けに脆弱性データへの即時アクセスが可能になりました。</p><p>問題が発生したセルフマネージドのお客様は、<code className="">dependency_scanning_sbom_scan_api</code>フィーチャーフラグを無効化することで、従来の動作にフォールバックできます。</p><p>この機能を使用するには、v2依存関係スキャンテンプレート<code className="">Jobs/Dependency-Scanning.v2.gitlab-ci.yml</code>をインポートしてください。</p><p>この機能に関するフィードバックをお待ちしております。ご質問、コメント、チームとのやり取りについては、<a href="https://gitlab.com/gitlab-org/gitlab/-/issues/523458" rel="">フィードバックイシュー</a>からお問い合わせください。</p><p><a href="https://docs.gitlab.com/user/application_security/dependency_scanning/dependency_scanning_sbom/" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/546429" rel="">イシュー</a></p><hr /><h3 id="セキュリティ構成プロファイルでのパイプラインシークレット検出">セキュリティ構成プロファイルでのパイプラインシークレット検出</h3><blockquote><p>GitLab.com: Ultimate<br />
Self-Managed: Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>GitLab 18.9では、プッシュ保護から始まる<strong>Secret Detection - Default</strong>プロファイルとともにセキュリティ構成プロファイルを導入しました。このプロファイルを使用して、単一のCI/CD設定ファイルも変更することなく、標準化されたシークレットスキャンを数百のプロジェクトに適用できます。</p><p><strong>Secret Detection - Default</strong>プロファイルにパイプラインベースのスキャンも含まれるようになり、開発ワークフロー全体にわたるシークレット検出の統一的な制御を提供します。</p><p>このプロファイルは3つのスキャントリガーを有効にします。</p><ul><li><strong>プッシュ保護</strong>: すべてのGitプッシュイベントをスキャンし、シークレットが検出されたプッシュをブロックすることで、シークレットがコードベースに入ることを防ぎます。</li><li><strong>マージリクエストパイプライン</strong>: オープンなマージリクエストがあるブランチに新しいコミットがプッシュされるたびに自動的にスキャンを実行します。結果にはマージリクエストで導入された新しい脆弱性のみが含まれます。</li><li><strong>ブランチパイプライン（デフォルトブランチのみ）</strong>: 変更がデフォルトブランチにマージまたはプッシュされたときに自動的に実行され、デフォルトブランチのシークレット検出状態の完全な可視化を提供します。</li></ul><p>プロファイルの適用にはYAML設定は不要です。プロファイルはグループに適用してすべてのプロジェクトにカバレッジを伝播させるか、個別のプロジェクトに適用してより詳細な制御を行えます。</p><p><a href="https://docs.gitlab.com/user/application_security/configuration/security_configuration_profiles/" rel="">ドキュメント</a> | <a href="https://gitlab.com/groups/gitlab-org/-/work_items/19802" rel="">エピック</a></p><hr /><h3 id="クレジット使用状況をgitlab-duo-agent-platformセッションにリンク">クレジット使用状況をGitLab Duo Agent Platformセッションにリンク</h3><blockquote><p>GitLab.com: Premium、Ultimate<br />
Self-Managed: Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>GitLabクレジットダッシュボードで、クレジット消費を生成したGitLab Duo Agent Platformセッションに直接リンクできるようになりました。</p><p>ユーザー別の詳細ビューで、Agent Platform使用行（<strong>Agentic Chat</strong>や<strong>基本エージェント</strong>など）の<strong>アクション</strong>列がクリック可能なハイパーリンクとなり、対応するセッションの詳細に遷移できます。</p><p>このリンクにより、請求からAIセッションの動作への直接的な監査証跡が提供されます。管理者は、別々のシステム間でタイムスタンプを手動で照合することなく、クレジット使用状況の調査、サポートのエスカレーション、コンプライアンスレビューを実施できます。</p><p><img alt="クレジット使用状況をGitLab Duo Agent Platformセッションにリンク" src="https://about.gitlab.com/images/18_10/fulfillment-credits-dashboard-dap-session-links.jpg" /></p><p><a href="https://docs.gitlab.com/subscriptions/gitlab_credits/#gitlab-credits-dashboard" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/579139" rel="">イシュー</a></p><hr /><h3 id="プロジェクトのリモートフローにネットワークアクセス制御を設定">プロジェクトのリモートフローにネットワークアクセス制御を設定</h3><blockquote><p>GitLab.com: Premium、Ultimate<br />
Self-Managed: Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>プロジェクト内のGitLab Runnerを使用するフローに対して、<a href="https://docs.gitlab.com/user/duo_agent_platform/environment_sandbox/" rel="">ネットワークアクセス制御</a>を設定できるようになりました。</p><p>ネットワーク宛先の制御を維持しながら、安全な外部統合を実現します。プロジェクトのメンテナーは、必要なAPI接続、MCPサーバー、サードパーティサービスを許可しつつ、セキュリティ境界を適用する柔軟性を備えています。</p><p>ネットワークアクセス制御は、<code className="">agent-config.yml</code>の<code className="">network_policy</code>セクションで設定します。<code className="">agent-config.yml</code>はブランチ保護ルールおよびマージリクエスト承認ワークフローによって保護されています。</p><p><img alt="プロジェクトのリモートフローにネットワークアクセス制御を設定" src="https://about.gitlab.com/images/18_10/projectlevel_network_access_control_for_remote_flows.png" /></p><p><a href="https://docs.gitlab.com/user/duo_agent_platform/environment_sandbox/#configure-a-network-policy" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/593560" rel="">イシュー</a></p><hr /><h3 id="パイプライン管理のためのgitlab-mcpサーバーツール">パイプライン管理のためのGitLab MCPサーバーツール</h3><blockquote><p>GitLab.com: Premium、Ultimate<br />
Self-Managed: Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>新しい<code className="">manage_pipeline</code>ツールにより、CI/CDパイプラインをGitLabプロジェクト内で管理できるようになりました。このGitLab MCPサーバーツールを使用すると、AIエージェントがパイプラインの作成、キャンセル、リトライ、削除、メタデータの更新を単一の呼び出しで実行できます。複数のステップを組み合わせてパイプラインワークフローを自動化する必要がなくなりました。</p><p>その他のGitLab MCPサーバーツールのご要望があれば、<a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/566375" rel="">フィードバックイシュー</a>からお知らせください。</p><p><a href="https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server_tools/#manage_pipeline" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/583826" rel="">イシュー</a></p><hr /><h3 id="プロジェクトメンテナーがカスタムエージェントとフローを有効化可能に">プロジェクトメンテナーがカスタムエージェントとフローを有効化可能に</h3><blockquote><p>GitLab.com: Premium、Ultimate<br />
Self-Managed: Premium、Ultimate<br />
GitLab Dedicated: Ultimate<br />
GitLab Dedicated for Government: Ultimate</p></blockquote><p>従来、AIカタログからのAIエージェントとフローの有効化には、トップレベルグループの権限が必要でした。</p><p>ExploreレベルまたはプロジェクトレベルでAIカタログを閲覧する際、プロジェクトのメンテナーが自身のプロジェクトで直接エージェントとフローを有効化できるようになりました。</p><p><a href="https://docs.gitlab.com/user/duo_agent_platform/flows/custom/#enable-a-flow" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/590573" rel="">イシュー</a></p><hr /><h3 id="ideおよびcicdパイプラインでのagent-skillsのサポート">IDEおよびCI/CDパイプラインでのAgent Skillsのサポート</h3><blockquote><p>GitLab.com: Premium、Ultimate<br />
Self-Managed: Premium、Ultimate<br />
GitLab Dedicated: Ultimate</p></blockquote><p>GitLab Duo Agent Platformが、AIエージェントに新しい機能と専門知識を付与するための新しい標準規格である<a href="https://agentskills.io/specification" rel="">Agent Skills仕様</a>に対応しました。</p><p>プロジェクトのワークスペースレベルでAgent Skillsを定義し、特定のフレームワークでのテスト記述など、特定タスクに対する専門知識とワークフローをエージェントに付与できます。エージェントは該当するタスクに遭遇した際、関連するスキルを自動的に検出・ロードします。</p><p>名前、ファイルパス、カスタムスラッシュコマンドでスキルを手動でトリガーすることも可能です。Agent SkillsはIDE内のフローやAgentic Chat、CI/CDパイプラインで実行されるフローからアクセスでき、仕様をサポートする他のAIツールでも利用できます。</p><p><a href="https://docs.gitlab.com/user/duo_agent_platform/customize/agent_skills/" rel="">ドキュメント</a> | <a href="https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/issues/1984" rel="">イシュー</a></p><hr /><h3 id="実験的機能">実験的機能</h3><h4 id="ジョブアドミッション制御のためのrunnerコントローラー">ジョブアドミッション制御のためのRunnerコントローラー</h4><p>Runnerコントローラーにより、Runner割り当て前にCI/CDジョブにカスタムポリシーを適用できるようになりました。Runnerコントローラーはジョブルーターに接続し、カスタムルールに基づいて受入または拒否の判断を行います。アドミッション制御、コンプライアンスの適用、コストおよびリソースガバナンスにご活用ください。コントローラーはインスタンスRunnerに対応しており、適用前の安全な検証のためのドライランモードもサポートしています。これは<a href="https://docs.gitlab.com/policy/development_stages_support/" rel="">実験的機能</a>です。詳細は、<a href="https://docs.gitlab.com/tutorials/build_runner_admission_controller/" rel="">チュートリアル: Runnerアドミッションコントローラーの構築</a>をご覧ください。</p><hr /><h3 id="バグ修正パフォーマンスの改善uiの改善">バグ修正、パフォーマンスの改善、UIの改善</h3><p>GitLabでは、ユーザーの皆さまに最高のエクスペリエンスを提供することに取り組んでいます。リリースのたびに、バグの修正、パフォーマンスの改善、UIの向上に努めています。GitLab.comの100万人以上のユーザーの方も、他のプラットフォームをお使いの方も、快適でスムーズなご利用をお届けします。</p><p>以下のリンクから、18.10で提供されたすべてのバグ修正、パフォーマンス改善、UI改善をご確認いただけます。</p><ul><li><a href="https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&amp;state=closed&amp;label_name%5B%5D=type%3A%3Abug&amp;or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&amp;or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&amp;or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&amp;milestone_title=18.10" rel="">バグ修正</a></li><li><a href="https://gitlab.com/groups/gitlab-org/-/issues/?sort=updated_desc&amp;state=closed&amp;label_name%5B%5D=bug%3A%3Aperformance&amp;or%5Blabel_name%5D%5B%5D=workflow%3A%3Acomplete&amp;or%5Blabel_name%5D%5B%5D=workflow%3A%3Averification&amp;or%5Blabel_name%5D%5B%5D=workflow%3A%3Aproduction&amp;milestone_title=18.10" rel="">パフォーマンスの改善</a></li><li><a href="https://papercuts.gitlab.com/?milestone=18.10" rel="">UIの改善</a></li></ul><hr /><h2 id="非推奨deprecation">非推奨（Deprecation）</h2><p>新しい非推奨機能および現在非推奨となっているすべての機能のリストは、<a href="https://docs.gitlab.com/ee/update/deprecations.html" rel="">GitLabドキュメント</a>でご確認いただけます。今後の破壊的変更の通知を受け取るには、<a href="https://about.gitlab.com/breaking-changes.xml" rel="">破壊的変更RSSフィード</a>をご購読ください。</p><h2 id="削除と破壊的変更">削除と破壊的変更</h2><p>削除されたすべての機能のリストは、<a href="https://docs.gitlab.com/ee/update/deprecations.html" rel="">GitLabドキュメント</a>でご確認いただけます。今後の破壊的変更の通知を受け取るには、<a href="https://about.gitlab.com/breaking-changes.xml" rel="">破壊的変更RSSフィード</a>をご購読ください。</p><h3 id="変更履歴">変更履歴</h3><p>名前付きの変更点については、各チェンジログをご確認ください。</p><ul><li><a href="https://gitlab.com/gitlab-org/gitlab-foss/blob/master/CHANGELOG.md" rel="">GitLab</a></li><li><a href="https://gitlab.com/gitlab-org/gitlab-runner/blob/main/CHANGELOG.md" rel="">GitLab Runner</a></li><li><a href="https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md" rel="">GitLab Workflow for VS Code</a></li><li><a href="https://gitlab.com/gitlab-org/cli/-/releases" rel="">GitLab CLI</a></li></ul><h3 id="インストール">インストール</h3><p>新規にGitLabをセットアップする場合は、<a href="https://about.gitlab.com/install/" rel="">GitLabダウンロードページ</a>をご覧ください。</p><h3 id="アップデート">アップデート</h3><p><a href="https://about.gitlab.com/update/" rel="">アップデートページ</a>をご確認ください。</p><h3 id="ご不明な点がある場合">ご不明な点がある場合</h3><p>ご質問やご意見をお聞かせください。本リリースについてご不明な点がある場合は、<a href="https://forum.gitlab.com/" rel="">GitLabフォーラム</a>にアクセスして質問を投稿してください。</p><h3 id="gitlabサブスクリプションプラン">GitLabサブスクリプションプラン</h3><ul><li><a href="https://about.gitlab.com/pricing/" rel="">Free</a>
ユーザー向けの永久無料機能を提供</li><li><a href="https://about.gitlab.com/pricing/premium/" rel="">Premium</a>
チームの生産性と調整を強化</li><li><a href="https://about.gitlab.com/pricing/ultimate/" rel="">Ultimate</a>
組織全体のセキュリティ、コンプライアンス、プランニングに対応
GitLabのすべての機能を<a href="https://about.gitlab.com/free-trial/?hosted=saas" rel="">無料</a>でお試しいただけます。</li></ul><p><em>--------------------</em></p><p><em>監修：ソリス ジェレズ / Jerez Solis @jerezs （GitLab合同会社 ソリューションアーキテクト本部 ソリューションアーキテクト）</em></p><h3 id="過去の日本語リリース情報">過去の日本語リリース情報</h3><ul><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-09-release/" rel="">GitLab 18.9</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-08-release/" rel="">GitLab 18.8</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-07-release/" rel="">GitLab 18.7</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-06-release/" rel="">GitLab 18.6</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-05-release/" rel="">GitLab 18.5</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-04-release" rel="">GitLab 18.4</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-03-release" rel="">GitLab 18.3</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-02-release/" rel="">GitLab 18.2</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-01-release/" rel="">GitLab 18.1</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-18-0-release/" rel="">GitLab 18.0</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-11-release/" rel="">GitLab 17.11</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-10-release/" rel="">GitLab 17.10</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-9-release/" rel="">GitLab 17.9</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-8-release/" rel="">GitLab 17.8</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-7-release/" rel="">GitLab 17.7</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-6-release/" rel="">GitLab 17.6</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-5-released/" rel="">GitLab 17.5</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-4-released/" rel="">GitLab 17.4</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-3-released/" rel="">GitLab 17.3</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-2-released/" rel="">GitLab 17.2</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-17-1-released/" rel="">GitLab 17.1</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-16-11-released/" rel="">GitLab 16.11</a></li></ul>]]></content>
        <author>
            <name>GitLab Japan Team</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/gitlab-japan-team/</uri>
        </author>
        <published>2026-03-19T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLab 18.10がAIネイティブなトリアージと修正機能を導入]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/gitlab-18-10-brings-ai-native-triage-and-remediation/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/gitlab-18-10-brings-ai-native-triage-and-remediation/"/>
        <updated>2026-03-19T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>GitLab 18.10では、脆弱性管理の品質とスピードの向上に焦点を当て、AIを活用したさまざまな新しいセキュリティ機能が導入されました。これらの機能を組み合わせることで、デベロッパーが誤検出の調査に費やす時間を削減し、自動修正をワークフローに直接組み込めるようになるため、セキュリティの専門知識がなくても脆弱性を修正できる環境が実現します。</p><p>新機能の概要は以下のとおりです。</p><ul><li><strong><a href="https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/false_positive_detection/" rel="">静的アプリケーションセキュリティテスト（SAST）の誤検出判定</a></strong> <strong>の一般提供が開始されました。</strong> このフローでは、LLMによるエージェント型推論を使用して、脆弱性が誤検出である可能性を判定できるため、セキュリティチームと開発チームは重大な脆弱性の修正に優先的に取り組めるようになります。</li><li><strong><a href="https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/agentic_vulnerability_resolution/" rel="">エージェント型SAST脆弱性の修正</a></strong> <strong>がベータ版として提供開始されました。</strong> エージェント型SAST脆弱性解決は、検証済みのSAST脆弱性に対する修正案を含むマージリクエストを自動的に作成します。修正までの時間が短縮され、高度なセキュリティ専門知識の必要になるケースが少なくなります。</li><li><strong><a href="https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/secret_false_positive_detection/" rel="">シークレットの誤検出判定機能</a></strong> <strong>がベータ版として提供開始されました。</strong> このフローは、AIを活用したノイズ削減をシークレット検出にも適用し、ダミーやテスト用のシークレットにフラグを付けてレビューの負担を軽減します。</li></ul><p>これらのフローは、GitLab Duo Agent Platformを使用するGitLab Ultimateのお客様にご利用いただけます。</p><h2 id="sastの誤検出判定機能でトリアージ時間を短縮">SASTの誤検出判定機能でトリアージ時間を短縮</h2><p>従来のSASTスキャナーは、コードパスが到達可能かどうかや、フレームワークが既にリスクを処理しているかどうかに関係なく、疑わしいコードパターンにすべてフラグ付けしていました。ランタイムコンテキストがなければ、実際の脆弱性と危険に見えるだけの安全なコードを区別できません。</p><p>そのため、デベロッパーは誤検出と判明するまで、検出結果の調査に何時間も費やす可能性がありました。時間の経過とともにレポートへの信頼が低下し、実際のリスクの修正を担当するチームの作業が遅延する原因となっていたのです。</p><p>各SASTスキャンの後、GitLab Duo Agent Platformは新しい「致命的」と「高」の重大度の検出結果を自動的に分析し、以下の情報を付加します。</p><ul><li>検出結果が誤検出である可能性を示す信頼度スコア</li><li>AI生成による判定理由の説明</li><li>UIにより「誤検出の可能性が高い」と「実際の脆弱性の可能性が高い」を簡単に目視で識別できるバッジ</li></ul><p>これらの検出結果は、以下のように<a href="https://docs.gitlab.com/ja-jp/user/application_security/vulnerability_report/" rel="">脆弱性レポート</a>に表示されます。レポートをフィルタリングして「誤検出ではない」とマークされた検出結果を絞り込むことで、チームはノイズの選別ではなく実際の脆弱性への対応に時間を使えるようになります。</p><p><img alt="脆弱性レポート" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1773844787/i0eod01p7gawflllkgsr.png" /></p><p>GitLab Duo Agent Platformの評価はあくまで推奨事項です。すべての誤検出の判定はユーザーが管理でき、エージェントの推論をいつでも監査して信頼性の高いモデルを構築できます。</p><h2 id="脆弱性を自動修正に変換">脆弱性を自動修正に変換</h2><p>実際に脆弱性であると判明しても、まだ作業の半分が完了したにすぎません。修正には、コードパスの理解、安全なパッチの作成、他の部分への影響がないことの確認が必要です。</p><p>SASTの誤検出判定フローによって脆弱性が誤検出ではない可能性が高いと判定された場合、エージェント型SAST脆弱性解決フローが自動的に以下を実行します。</p><ol><li>リポジトリから脆弱なコードとその周辺のコンテキストを読み取る</li><li>高品質な修正案を生成する</li><li>自動テストによって修正を検証する</li><li>以下を含む修正案のマージリクエストを作成する：<ul><li>具体的なコード変更</li><li>信頼度スコア</li><li>変更内容とその理由の説明</li></ul></li></ol><p>このデモでは、GitLabがSAST脆弱性を検出からレビュー可能なマージリクエストまで自動的に処理する様子をご覧いただけます。エージェントがコードを読み取り、修正を生成・検証し、明確で説明可能な変更を含むMRを作成する流れをご確認ください。デベロッパーにセキュリティの専門知識がなくても、より迅速に修正を行えるようになります。</p><iframe src="https://player.vimeo.com/video/1174573325?badge=0&amp;autopause=0&amp;player_id=0&amp;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"></iframe><script src="https://player.vimeo.com/api/player.js"></script><p>AI生成の提案と同様に、マージを行う前に提案されたマージリクエストを慎重にレビューしてください。</p><h2 id="実際のシークレットを特定">実際のシークレットを特定</h2><p>シークレット検出は、チームが結果を信頼できて初めて有用なものとなります。レポートにテスト用の認証情報やプレースホルダーの値、サンプルトークンが大量に含まれていると、デベロッパーは実際の漏洩を修正するよりも、ノイズのレビューに時間を浪費してしまう可能性があります。その結果、修正が遅延し、スキャンへの信頼が低下しかねません。</p><p>シークレットの誤検出判定機能は、チームが重要なシークレットに集中し、より迅速にリスクを軽減できるよう支援します。この機能がデフォルトブランチで実行されると、自動的に以下が行われます。</p><ol><li>各検出結果を分析し、テスト用の認証情報、サンプル値、ダミーシークレットの可能性を特定する</li><li>検出結果が実際のリスクか誤検出の可能性が高いかの信頼度スコアを付与する</li><li>実際のシークレット、ノイズのいずれかとして扱われる理由の説明を生成する</li><li>脆弱性レポートにバッジを追加し、デベロッパーがステータスを一目で確認できるようにする</li></ol><p>デベロッパーは、脆弱性レポートからシークレット検出の結果に対して「<strong>誤検出を確認</strong>」を選択することで、この分析を手動でトリガーすることもできます。リスクのない検出結果を除外し、実際のシークレットへの対応をより速やかに開始できます。</p><h2 id="aiを活用したセキュリティ機能を今すぐお試しください">AIを活用したセキュリティ機能を今すぐお試しください</h2><p>GitLab 18.10では、SASTとシークレット検出における誤検出ノイズの削減から、修正案を含むマージリクエストの自動生成まで、脆弱性ワークフロー全体をカバーする機能が導入されました。</p><p>AIを活用したセキュリティ機能がレビュー時間の短縮と検出結果のマージ可能な修正への変換にどのように役立つかをご確認いただくには、<a href="https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/?utm_medium=blog&amp;utm_source=blog&amp;utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_gitlab-18-10-brings-ai-native-triage-and-remediation" rel="">GitLab Duo Agent Platformの無料トライアルを今すぐ開始</a>してください。</p>]]></content>
        <author>
            <name>Alisa Ho</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/alisa-ho/</uri>
        </author>
        <published>2026-03-19T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLab 18.10：エージェント型AIがさらに多くのチームで利用可能に]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/gitlab-18-10-agentic-ai-now-open-to-even-more-teams-on-gitlab/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/gitlab-18-10-agentic-ai-now-open-to-even-more-teams-on-gitlab/"/>
        <updated>2026-03-19T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>エージェント型AIは、ソフトウェア開発のあり方を大きく変えつつあります。しかし多くのチーム、特に中小規模のチームにとって、AIの導入は「すべてか無か」の選択を迫られるものでした。つまり、プラットフォームのフルサブスクリプションを契約するか、AIをまったく使わないかの二択しかありませんでした。</p><p>GitLab 18.10で、この状況が変わります。本日より、GitLab.comのFreeプランを利用するチームは、<a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/" rel="">GitLabクレジット</a>を購入して月額料金にコミットすることにより、<a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/" rel="">GitLab Duo Agent Platform</a>をすぐに利用開始できます。サブスクリプションのアップグレードは不要です。GitLab有料プランの追加はまだ検討していないものの、AIを活用した開発を始めたいチームにとって、エージェント型AIへの本格的なエントリーポイントとなります。</p><p>モデルはシンプルで、利用するユーザー数ではなくAIが実行した作業に対して課金されます。グループオーナーがグループの請求設定からGitLabクレジットを購入して月額料金にコミットすると、チーム全体がGitLab PremiumおよびUltimateのお客様と同じAIエージェントとワークフローにアクセスできるようになります。計画、コード生成、自動コードレビュー、パイプライン診断のすべてを、共有クレジットプールから利用可能です。</p><p><a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#gitlab-credits-dashboard" rel="">GitLabクレジット</a><a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#gitlab-credits-dashboard" rel="">ダッシュボード</a>により、グループオーナーはどのエージェントやワークフローがクレジットを消費しているかを把握でき、AI関連の支出を実際の作業成果に直接紐づけることが可能です。</p><p><img alt="月額コミットメント50クレジットのプール、使用状況の追跡、オンデマンドクレジット消費、Duo Agent Platformのユーザーあたりのクレジット割り当てを表示するGitLabクレジットダッシュボード" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1773867549/jdrzquwptvjnbr7eqd56.png" /></p><h2 id="購入したその日からgitlab-duo-agent-platformを利用可能">購入したその日からGitLab Duo Agent Platformを利用可能</h2><p>グループオーナーがクレジットを購入すると、チームの全メンバーがすぐにGitLab Duo Agent Platformの利用を開始できます。</p><p>一般的なワークフローは次のとおりです。</p><p>まず、ソフトウェアの機能リクエストから始めます。GitLab Duo Chat（エージェント）で<a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/planner/" rel="">プランナーエージェント</a>を開き、必要な内容を自然言語で記述します。エージェントがそれを構造化された作業アイテム（説明、ラベル、関連付けを含むイシュー）に分解し、プロジェクトに直接作成します。これまで手作業のイシュー整理に半日かかっていた作業が、わずか数分で完了します。</p><p>作成されたイシューの1つを選び、<a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/developer/" rel="">デベロッパーフロー</a>を割り当てて作業を開始します。エージェントがイシューのコンテキストを読み取り、要件に沿ったコードを生成し、テストを実行して、レビュー用のマージリクエストを作成します。リファクタリングや拡張、プロジェクトのコンテキスト内でのコード説明など、より反復的な作業には<a href="https://docs.gitlab.com/ja-jp/user/gitlab_duo_chat/agentic_chat/" rel="">GitLab Duo Chat（エージェント）</a>も活用できます。</p><p>マージリクエストの準備が整うと、<a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/code_review/" rel="">コードレビューフロー</a>が多段階の自動レビューを実行します。変更内容のスキャン、リポジトリコンテキストの取り込み、差分に紐づいた構造化されたインラインフィードバックの投稿が行われます。人間のレビュアーは初回の機械的なチェックを省略し、アーキテクチャやビジネスロジックに集中できます。</p><p>パイプラインが失敗した場合は、<a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/fix_pipeline/" rel="">CI/CDパイプライン修正フロー</a>がエラーログを読み取り、根本原因を特定して修正案を提示します。チームは、ジョブログを手動で確認しなくても、解決の糸口を得ることができます。</p><p>GitLab Duo Agent Platformは、1つのクレジットプールでソフトウェア開発をイテレーションからデプロイまで支援します。</p><p>エージェントとワークフローの利用開始は簡単で、計画からデプロイまで3分以内で完了します。詳細はこちらのデモをご覧ください。</p><iframe src="https://player.vimeo.com/video/1175244743?badge=0&amp;autopause=0&amp;player_id=0&amp;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="18.10 Main Demo V2"></iframe><script src="https://player.vimeo.com/api/player.js"></script><h2 id="定額コードレビュースケールしてもコストを予測可能">定額コードレビュー：スケールしてもコストを予測可能</h2><p>GitLab Duo Agent Platformで利用できるすべてのワークフローの中で、自動コードレビューはコストが予測可能であるという点で、最も早く価値を実感できる機能です。</p><p>コードレビューフローの料金は、マージリクエストのサイズやリポジトリの複雑さ、内部で実行されるステップ数に関係なく、レビュー1回あたり一律0.25 GitLabクレジットとなります。4回のレビューで1クレジットです。チームが月に500件のマージリクエストを処理する場合でも50,000件の場合でも、レビュー数に基づいてコストを直接予測できます。</p><p>この数字をもう少し詳しく見てみましょう。手動のコードレビューはコストだけでなく時間もかかり、コンテキストスイッチングが絶えず必要になるため、開発に支障をきたします。コードレビューフローによる時間の節約は、レビュー量の増加に伴い大幅なコスト削減につながる可能性があります。キューで待機させるのではなく、数百件のレビューを同時に実行できるため、時間の節約とコスト削減の効果が急速かつ複合的に高まります。</p><p>GitLabのFreeプランを利用しているチームは、月間クレジットプールのうちコードレビューに充てる割合を正確に把握し、計画を立てることが可能です。</p><blockquote><p><a href="https://about.gitlab.com/ja-jp/blog/agentic-code-reviews-with-flat-rate-pricing/" rel="">コードレビューフローの仕組み</a>と、エンジニアリング組織のスケーリングにおける意義について詳しくご確認ください。</p></blockquote><h2 id="premiumで価値を最大化">Premiumで価値を最大化</h2><p>FreeプランのGitLabクレジットは、エージェント型AIへの直接的な道筋を提供します。チームがGitLabをより幅広く活用している場合、Premiumは経済性と機能の両方を兼ね備えた選択肢です。</p><p>月額29ドル/ユーザーの<a href="https://about.gitlab.com/ja-jp/pricing/" rel="">GitLab Premium</a>には、プロモーションオファーとしてユーザーあたり12 GitLabクレジットが含まれています。20人のチームであれば、追加費用なしで月240クレジットを利用でき、約960回の自動コードレビュー、またはコードレビュー、計画、開発ワークフロー、パイプライン修正を組み合わせた利用が可能です。</p><p>GitLab Duo Agent Platformは、Premiumが提供する機能の一部にすぎません。大量パイプライン向けの高度なCI/CD、ガバナンスのためのマージ承認とコードオーナー、プロジェクト全体で統一されたコンテキストを持つ単一データレイヤー内で動作するAIも含まれています。</p><p>Freeプランでクレジットを使用し、AIがワークフローの中心になりつつあると感じているチームにとって、プロモーションクレジットが含まれるPremiumが次の選択肢となるのは自然の流れでしょう。Premiumでは、より多くのプラットフォーム機能を利用でき、チームとともに成長する基盤となります。</p><h2 id="今すぐ始めましょう">今すぐ始めましょう</h2><p>GitLab 18.10はすでに提供が開始されており、すぐにご利用いただけます。エージェント型AIでスピードアップしたいチームも、現在の作業方法を支えるフルプラットフォームが必要なチームも、ソフトウェア開発プロセスを加速するための明確な道筋があります。</p><ul><li><strong>FreeプランのGitLab.comをご利用のチーム：</strong> グループの請求設定から<a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#for-the-free-tier-on-gitlabcom" rel="">GitLab クレジットの月額コミットメントを購入</a>し、今すぐGitLab Duo Agent Platformの利用を開始してください。</li><li><strong>フルプラットフォームを検討されているチーム：</strong> <a href="https://docs.gitlab.com/ja-jp/subscriptions/choosing_subscription/" rel="">チームに最適なGitLabサブスクリプションを見つける</a>か、<a href="https://about.gitlab.com/ja-jp/free-trial/" rel="">GitLab Ultimateの無料トライアルを開始</a>してください。</li></ul><p>チームへのクレジット設定は迅速かつ簡単です。詳細はこちらのデモをご覧ください。</p><iframe src="https://player.vimeo.com/video/1175238100?badge=0&amp;autopause=0&amp;player_id=0&amp;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 Credits Purchase Flow"></iframe><script src="https://player.vimeo.com/api/player.js"></script><hr /><h2 id="faq">FAQ</h2><p><strong>GitLabクレジットの月額コミットメントとは何ですか</strong></p><p>月額コミットメントは、グループオーナーがグループ全体の共有プールとして適用されるクレジット数を選択する、使用量ベースの購入オプションです。チームがGitLab Duo Agent Platformの機能を使用するとクレジットが消費されます。詳細は<a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/" rel="">GitLabクレジットのドキュメント</a>をご確認ください。</p><p><strong>現在、GitLabクレジットを購入できるのは誰ですか</strong></p><p>GitLab PremiumおよびUltimateのお客様は、プロモーションクレジットがすでにサブスクリプションに含まれています。18.10以降、FreeプランのGitLab.comトップレベルグループネームスペースでも、セルフサービスのグループ請求を通じてクレジットの月額コミットメントを購入できるようになりました。最新の対象条件については、<a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/" rel="">GitLabクレジットのドキュメント</a>をご確認ください。</p><p><strong>Freeプランでクレジットによって利用可能になるAI機能は何ですか</strong></p><p>クレジットを持つチームは、PremiumおよびUltimateのお客様と同じエージェント型AI機能とモデルにアクセスできます。プランナーエージェント、デベロッパーフロー、コードレビューフロー、CI/CDパイプライン修正フロー、GitLab Duo Chat（エージェント）、コード提案、カスタムエージェントとワークフローなどが含まれます。全機能の一覧は<a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/" rel="">Duo Agent Platformドキュメント</a>をご確認ください。</p><p><strong>自動コードレビューの費用はいくらですか</strong></p><p>コードレビューフローは、マージリクエストのサイズや複雑さに関係なく、レビュー1回あたり一律0.25 GitLabクレジットの定額料金です。最新の価格詳細については、<a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/code_review/" rel="">コードレビューフローのドキュメント</a>をご確認ください。</p><p><strong>Freeプラン＋クレジットからGitLab Premiumにアップグレードできますか</strong></p><p>GitLab 18.10では、営業担当を通じて月額クレジットコミットメントを持つ無料ネームスペースからPremiumへのアップグレードを利用可能です。オプションについては<a href="https://about.gitlab.com/ja-jp/contact-sales/" rel="">GitLab営業チーム</a>にお問い合わせください。</p>]]></content>
        <author>
            <name>Talia Armato-Helle</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/talia-armato-helle/</uri>
        </author>
        <published>2026-03-19T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[エージェント型コードレビューを1件0.25ドルで]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/agentic-code-reviews-with-flat-rate-pricing/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/agentic-code-reviews-with-flat-rate-pricing/"/>
        <updated>2026-03-19T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>コードレビューは今や、完全に予算外のボトルネックになりつつあります。AIの支援により、開発者はかつてないスピードでコードをリリースしていますが、レビューはそのスピードに追いついていません。AIコーディングツールを導入したチームでは、コードレビューにかかる時間が<a href="https://byteiota.com/ai-code-review-bottleneck-kills-40-of-productivity/" rel="">91%増加</a>しています。大企業のエンジニアは、プルリクエストがマージされるまで平均<a href="https://dzone.com/articles/shifting-bottleneck-how-ai-is-reshaping-the-sdlc" rel="">13時間待つ</a>という状況であり、<a href="https://techcrunch.com/2026/03/09/anthropic-launches-code-review-tool-to-check-flood-of-ai-generated-code/" rel="">エンジニアリングチームの44%</a>が「コードレビューの遅れがデリバリーにとって最大のボトルネック」と回答しています。</p><p>こうした課題に対し、AIを活用したレビューツールが次々と登場しています。しかし、その多くには落とし穴があります。それは、変更の規模や複雑さによって料金が変わるトークン課金モデルのため、コストを予測できないという点です。新しいツールの中には、1件あたり15〜25ドルかかるものもあります。このような料金体系では、チームは優先度の高い変更のみに絞ってレビューを行うことになり、結局、レビュー待ちの行列は解消されません。</p><p>今回ご紹介するGitLab Duo Agent Platform内のエージェント型AI機能であるコードレビューフローは、1件のレビューあたり0.25ドルの定額制です。すべてのマージリクエスト、すべてのプロジェクトにおいて、毎回同じ料金で利用できます。</p><h2 id="仕組み">仕組み</h2><p>マージリクエストが作成されると、コードレビューフローは自動的にマルチステップのレビューを実行します。変更内容のスキャン、関連するリポジトリのコンテキストの調査、パイプライン・セキュリティの検出結果・コンプライアンス要件との照合、そして構造化されたインラインフィードバックの生成までを自動で行います。</p><p>レビュー結果は、差分の変更だけでなく、プロジェクトで実際に起きていることを踏まえた内容になります。また、GitLab内で動作するため、スタンドアロンツールでは実現できないことが可能です。エンジニア1人のIDEで1件ずつ処理するのではなく、組織全体で数百件のレビューを並行して実行できます。</p><p>コードレビューの動作をデモでご確認ください：</p><iframe src="https://player.vimeo.com/video/1174920981?badge=0&amp;autopause=0&amp;player_id=0&amp;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="18.10 DAP Code Review"></iframe><script src="https://player.vimeo.com/api/player.js"></script><h2 id="シンプルな計算確かなコスト削減">シンプルな計算、確かなコスト削減</h2><p>1件のレビューコストは0.25 GitLabクレジット（定価0.25ドル）です。つまり、1クレジットで4件のレビューを実行できます。月に500件のマージリクエストをマージするチームでも、50,000件のチームでも、計算式は同じです。</p><p>トークンの見積もりは不要です。マージリクエストの複雑さによってコストが変わることもありません。スプレッドシートで計算できる、1件あたりの定額コストです。</p><p>参考までに、シニアエンジニアが手動でコードレビューを行うと、1件あたり約15分、つまり約25ドルの人件費がかかります。自動レビューであれば0.25ドルで済むため、1件あたりのコストを99%削減できます。さらに、レビューはキューで待機するのではなく、並行して実行されます。このため、コスト削減だけでなく、マージリクエストのブロックが数時間ではなく数分で解消されます。</p><h2 id="定額制がゲームチェンジャーになる理由">定額制がゲームチェンジャーになる理由</h2><p>従量課金制では、どのマージリクエストにAIレビューを適用するかを選択せざるを得ませんでした。しかし、0.25ドルであれば、選択は不要です。すべてに適用することができます。</p><p><strong>すべてのマージリクエスト、すべてのプロジェクトで実行。</strong> コードレビューフローをすべてのマージリクエストで自動的にトリガーするよう設定できます。エージェントがキューを処理する間、エンジニアはアーキテクチャやメンタリングに集中できます。</p><p><strong>スケールにかかわらず一貫した標準を適用可能。</strong> プロジェクトごとにカスタムのマージレビュー手順を定義できます。あるプロジェクトは組み込みフローを使用し、別のプロジェクトはClaude CodeやCodexを使用し、さらに別のプロジェクトはカスタムエージェントを実行する、といった構成も可能です。すべてが並行して実行され、それぞれのガードレールに沿って、一か所で確認できます。</p><p><strong>レビューキューのボトルネックを解消。</strong> 最近のソフトウェア開発でボトルネックとなっているのは、コード作成ではなく、レビューの完了を待つことです。定額制で、並行して実行できるAIレビューにより、数日かかっていたキューが数分のプロセスに変わります。</p><blockquote><p><strong>GitLabクレジットについて</strong> GitLabクレジットはDuo Agent Platformの利用量を示す単位で、1クレジット＝1ドルに相当します。<a href="https://docs.gitlab.com/ja-jp/subscriptions/gitlab_credits/#buy-gitlab-credits" rel="">GitLabクレジットの仕組み</a>についてはこちらをご覧ください。</p></blockquote><h2 id="今すぐ始める">今すぐ始める</h2><p>エージェント型コードレビューの0.25ドル定額料金は、GitLab.com、Dedicated、または18.8.4以降のSelf-ManagedインスタンスでGitLab Duo Agent Platformをご利用の場合、今すぐ利用可能です。今すぐコードレビューフローをデフォルトで有効にして、チームが作成するすべてのマージリクエストに適用しましょう。</p><p><img alt="エージェント型コードレビューを適用する" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1774273288/zoyqfwsb81v9lv7y8ddf.png" /></p><blockquote><p><a href="https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/?utm_medium=blog&amp;utm_source=blog&amp;utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_agentic-code-reviews-with-flat-rate-pricing" rel="">GitLab Duo Agent Platformの無料トライアルを開始</a>して、実際の動きをご確認ください。すでにGitLabをご利用いただいているお客様は、ご担当の営業担当者にお問い合わせください。</p></blockquote>]]></content>
        <author>
            <name>Karishma Kumar</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/karishma-kumar/</uri>
        </author>
        <published>2026-03-19T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLab Runner とは？インストールから設定・活用まで解説]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/what-is-gitlab-runner/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/what-is-gitlab-runner/"/>
        <updated>2026-03-17T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p><a href="https://about.gitlab.com/ja-jp/topics/ci-cd/cicd-pipeline/" rel="" title="CI/CDパイプラインとは？">CI/CDパイプライン</a>を成功に導く陰の立役者、それが <strong>GitLab Runner</strong> です。<code className="">.gitlab-ci.yml</code> ファイルに定義されたジョブを実行し、テストの起動、アプリケーションのビルド、コードのデプロイを担います。</p><p>Runnerがなければ、パイプラインは設計図のままです。Runnerがあれば、それは具体的な動作として再現できるものになります。本記事では、GitLab Runnerとは何か、インストール・設定の方法、そして最大限に活用するためのベストプラクティスをご紹介します。</p><h2 id="gitlab-runnerとは">GitLab Runnerとは？</h2><p><strong>GitLab Runner</strong>は<a href="https://about.gitlab.com/ja-jp/blog/what-is-open-source/" rel="" title="オープンソースとは？">オープンソース</a>のGoで書かれたアプリケーションで、CI/CDパイプラインのジョブを実行します。デベロッパーがコードをプッシュすると、GitLabがパイプラインをトリガーし、利用可能なRunnerにジョブを振り分けます。RunnerはジョブをRunnerし、その結果（ログ、アーティファクト、ステータス）をGitLabに返します。</p><p><strong>パイプライン</strong>とは、ジョブ（コンパイル、テスト、デプロイ）を自動化した一連の流れのことです。<strong>Runner</strong>は、特定のマシン上でそれらを実行するエージェントです。RunnerのExecutorは、ジョブが実行される環境（<a href="https://about.gitlab.com/ja-jp/blog/what-is-docker/" rel="" title="Dockerとは？">Docker</a>、Shell、<a href="https://about.gitlab.com/ja-jp/blog/what-is-kubernetes/" rel="" title="Kubernetesとは？">Kubernetes</a>など）を定義します。</p><blockquote><p><strong><a href="https://about.gitlab.com/ja-jp/free-trial/devsecops/?utm_medium=blog&amp;utm_source=blog&amp;utm_campaign=eg_apj_x_trial_x_ja_blog_ja" rel="">→ GitLab UltimateおよびGitLab Duo Enterpriseを無料でお試しください。</a></strong></p></blockquote><h2 id="gitlab-cicdで利用できるrunnerの種類">GitLab CI/CDで利用できるRunnerの種類</h2><p>GitLab Runnerでは、アクセスを許可する対象に応じて、次の<a href="https://docs.gitlab.com/ja-jp/ci/runners/runners_scope/" rel="">Runnerスコープ</a>を利用できます。</p><ul><li><strong>インスタンスRunner</strong>：GitLabインスタンス上のすべてのグループとプロジェクトで利用可能。</li><li><strong>グループRunner</strong>：グループ内のすべてのプロジェクトおよびサブグループで利用可能。</li><li><strong>プロジェクトRunner</strong>：特定のプロジェクトに紐付けられています。通常、プロジェクトRunnerは一度に1つのプロジェクトのみで使用されます。</li></ul><p>これらのRunnerは、2つの方法でホストできます。</p><ul><li><strong>ホスト型Runner</strong>：GitLabが管理し、GitLab.com上で利用可能。インストール不要で、素早く開始できますが、設定の自由度は制限されます。</li><li><strong>セルフホスト型Runner</strong>：独自のサーバー、仮想マシン、またはクラスター上にインストール・設定・管理します。完全なコントロールが可能で、特定の環境にも柔軟に対応できます。</li></ul><h2 id="gitlab-runnerがサポートするエグゼキューター">GitLab Runnerがサポートするエグゼキューター</h2><p>GitLab Runnerのインストール時には、<strong>Executor</strong>（ジョブが実行される環境）を選択する必要があります。Executorの選択は、パイプラインのセキュリティ、パフォーマンス、柔軟性に直接影響します。</p><p>主なExecutorは以下のとおりです。</p><ul><li><strong><a href="https://docs.gitlab.com/ja-jp/runner/executors/docker/" rel="">Docker</a></strong>：各ジョブを隔離されたコンテナ内で実行します。高速かつ柔軟で、ほとんどのプロジェクトに推奨されます。</li><li><strong><a href="https://docs.gitlab.com/ja-jp/runner/executors/shell/" rel="">Shell</a></strong>：ホストマシン上でジョブを直接実行します。シンプルですが、分離性はありません。</li><li><strong><a href="https://docs.gitlab.com/ja-jp/runner/executors/kubernetes/" rel="">Kubernetes</a></strong>：Kubernetesのポッド内でジョブを実行し、ネイティブなスケーラビリティを備えています。</li><li><strong><a href="https://docs.gitlab.com/ja-jp/runner/executors/virtualbox/" rel="">VirtualBox / Parallels</a></strong>：macOSなど特定の環境でジョブを実行します。</li></ul><p>選択はニーズによって異なりますが、ほとんどのプロジェクトでは<strong>Docker</strong>が最適です。Executorの詳細については、<a href="https://docs.gitlab.com/ja-jp/runner/executors/" rel="">ドキュメントをご覧ください</a>。</p><h2 id="gitlab-runnerのインストール方法">GitLab Runnerのインストール方法</h2><p><a href="https://docs.gitlab.com/ja-jp/runner/install/" rel="">GitLab Runnerのインストール</a>方法は、使用するOSとターゲット環境によって異なります。以下に代表的なシナリオをご紹介します。</p><h3 id="linuxへのインストールdebianubuntu">Linuxへのインストール（Debian/Ubuntu）</h3><p>Linuxは、特にサーバー側でセルフホスト型Runnerをホストする最も一般的な環境です。インストール方法は次の3通りです。</p><ul><li>GitLabの公式リポジトリ経由</li><li><code className="">.deb</code>または<code className="">.rpm</code>パッケージ経由</li><li>バイナリファイル経由</li></ul><p>以下の例は、<strong>Debian/Ubuntu</strong>において<a href="https://docs.gitlab.com/ja-jp/runner/install/linux-repository/" rel="">GitLabリポジトリからパッケージをインストール</a>する手順を示しています。</p><ol><li>GitLabの公式リポジトリを追加します。</li></ol><pre className="language-shell shiki shiki-themes github-light" code="curl -L &quot;https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh&quot; | sudo bash
" language="shell" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#6F42C1">curl</span><span style="--shiki-default:#005CC5"> -L</span><span style="--shiki-default:#032F62"> &quot;https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh&quot;</span><span style="--shiki-default:#D73A49"> |</span><span style="--shiki-default:#6F42C1"> sudo</span><span style="--shiki-default:#032F62"> bash
</span></span></code></pre><ol start="2"><li>GitLab Runnerの最新バージョンをインストールします。特定バージョンをインストールする場合は次のステップに進んでください。</li></ol><pre className="language-shell shiki shiki-themes github-light" code="sudo apt install gitlab-runner
" language="shell" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#6F42C1">sudo</span><span style="--shiki-default:#032F62"> apt</span><span style="--shiki-default:#032F62"> install</span><span style="--shiki-default:#032F62"> gitlab-runner
</span></span></code></pre><ol start="3"><li>特定バージョンのGitLab Runnerをインストールする場合：</li></ol><pre className="language-shell shiki shiki-themes github-light" code="apt-cache madison gitlab-runner

sudo apt install gitlab-runner=17.7.1-1 gitlab-runner-helper-images=17.7.1-1
" language="shell" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#6F42C1">apt-cache</span><span style="--shiki-default:#032F62"> madison</span><span style="--shiki-default:#032F62"> gitlab-runner
</span></span><span class="line" line="2"><span emptyLinePlaceholder>
</span></span><span class="line" line="3"><span style="--shiki-default:#6F42C1">sudo</span><span style="--shiki-default:#032F62"> apt</span><span style="--shiki-default:#032F62"> install</span><span style="--shiki-default:#032F62"> gitlab-runner=17.7.1-1</span><span style="--shiki-default:#032F62"> gitlab-runner-helper-images=17.7.1-1
</span></span></code></pre><p><code className="">gitlab-runner</code>の特定バージョンを<code className="">gitlab-runner-helper-images</code>の同バージョンなしにインストールしようとすると、次のようなエラーが発生する場合があります。</p><pre className="language-shell shiki shiki-themes github-light" code="sudo apt install gitlab-runner=17.7.1-1

...

The following packages have unmet dependencies:
 gitlab-runner : Depends: gitlab-runner-helper-images (= 17.7.1-1) but 17.8.3-1 is to be installed
E: Unable to correct problems, you have held broken packages.
" language="shell" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#6F42C1">sudo</span><span style="--shiki-default:#032F62"> apt</span><span style="--shiki-default:#032F62"> install</span><span style="--shiki-default:#032F62"> gitlab-runner=17.7.1-1
</span></span><span class="line" line="2"><span emptyLinePlaceholder>
</span></span><span class="line" line="3"><span style="--shiki-default:#005CC5">...
</span></span><span class="line" line="4"><span emptyLinePlaceholder>
</span></span><span class="line" line="5"><span style="--shiki-default:#6F42C1">The</span><span style="--shiki-default:#032F62"> following</span><span style="--shiki-default:#032F62"> packages</span><span style="--shiki-default:#032F62"> have</span><span style="--shiki-default:#032F62"> unmet</span><span style="--shiki-default:#032F62"> dependencies:
</span></span><span class="line" line="6"><span style="--shiki-default:#6F42C1"> gitlab-runner</span><span style="--shiki-default:#032F62"> :</span><span style="--shiki-default:#032F62"> Depends:</span><span style="--shiki-default:#032F62"> gitlab-runner-helper-images</span><span style="--shiki-default:#24292E"> (= </span><span style="--shiki-default:#032F62">17.7.1-1</span><span style="--shiki-default:#24292E">) but 17.8.3-1 is to be installed
</span></span><span class="line" line="7"><span style="--shiki-default:#6F42C1">E:</span><span style="--shiki-default:#032F62"> Unable</span><span style="--shiki-default:#032F62"> to</span><span style="--shiki-default:#032F62"> correct</span><span style="--shiki-default:#032F62"> problems,</span><span style="--shiki-default:#032F62"> you</span><span style="--shiki-default:#032F62"> have</span><span style="--shiki-default:#032F62"> held</span><span style="--shiki-default:#032F62"> broken</span><span style="--shiki-default:#032F62"> packages.
</span></span></code></pre><ol start="4"><li>Runnerを登録します。</li></ol><pre className="language-shell shiki shiki-themes github-light" code="sudo gitlab-runner register
" language="shell" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#6F42C1">sudo</span><span style="--shiki-default:#032F62"> gitlab-runner</span><span style="--shiki-default:#032F62"> register
</span></span></code></pre><h3 id="windowsおよびmacosへのインストール">WindowsおよびmacOSへのインストール</h3><p>プロジェクトにビルド固有の要件がある場合は、次の手順に従ってWindowsまたはmacOSにGitLab Runnerをインストールすることもできます。</p><ul><li><a href="https://docs.gitlab.com/ja-jp/runner/install/windows/" rel="">GitLab RunnerをWindowsにインストールする</a></li><li><a href="https://docs.gitlab.com/ja-jp/runner/install/osx/" rel="">GitLab RunnerをmacOSにインストールする</a></li></ul><h3 id="dockerによるrunnerのインストール">DockerによるRunnerのインストール</h3><p>DockerはGitLab Runnerをセットアップする最もシンプルかつ迅速な方法の一つです。複雑なインストール作業なしにDockerコンテナ内でRunnerを実行でき、隔離された再現性の高い環境を活用できます。</p><p>迅速なテストや一時的な開発環境、またはすでにコンテナを多用しているチームに最適な方法です。</p><ol><li>コンテナを起動します。</li></ol><pre className="language-shell shiki shiki-themes github-light" code="docker run -d --name gitlab-runner --restart always \ 
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \ 
  gitlab/gitlab-runner:latest

" language="shell" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#6F42C1">docker</span><span style="--shiki-default:#032F62"> run</span><span style="--shiki-default:#005CC5"> -d</span><span style="--shiki-default:#005CC5"> --name</span><span style="--shiki-default:#032F62"> gitlab-runner</span><span style="--shiki-default:#005CC5"> --restart</span><span style="--shiki-default:#032F62"> always</span><span style="--shiki-default:#005CC5"> \ 
</span></span><span class="line" line="2"><span style="--shiki-default:#6F42C1">  -v</span><span style="--shiki-default:#032F62"> /srv/gitlab-runner/config:/etc/gitlab-runner</span><span style="--shiki-default:#005CC5"> \
</span></span><span class="line" line="3"><span style="--shiki-default:#005CC5">  -v</span><span style="--shiki-default:#032F62"> /var/run/docker.sock:/var/run/docker.sock</span><span style="--shiki-default:#005CC5"> \ 
</span></span><span class="line" line="4"><span style="--shiki-default:#6F42C1">  gitlab/gitlab-runner:latest
</span></span></code></pre><ol start="2"><li>Runnerを登録します。</li></ol><pre className="language-shell shiki shiki-themes github-light" code="docker exec -it gitlab-runner gitlab-runner register
" language="shell" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#6F42C1">docker</span><span style="--shiki-default:#032F62"> exec</span><span style="--shiki-default:#005CC5"> -it</span><span style="--shiki-default:#032F62"> gitlab-runner</span><span style="--shiki-default:#032F62"> gitlab-runner</span><span style="--shiki-default:#032F62"> register
</span></span></code></pre><h3 id="kubernetesによるrunnerのインストール">KubernetesによるRunnerのインストール</h3><p>KubernetesへのGitLab RunnerのインストールはGitLabのHelm Chartを使用します。これはKubernetesクラスター内にGitLab Runnerインスタンスをデプロイする公式の方法です。</p><p>GitLabのHelm ChartからGitLab Runnerをインストールする手順は以下のとおりです。</p><ol><li>GitLab Helmリポジトリを追加します。</li></ol><pre className="language-shell shiki shiki-themes github-light" code="helm repo add gitlab https://charts.gitlab.io
" language="shell" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#6F42C1">helm</span><span style="--shiki-default:#032F62"> repo</span><span style="--shiki-default:#032F62"> add</span><span style="--shiki-default:#032F62"> gitlab</span><span style="--shiki-default:#032F62"> https://charts.gitlab.io
</span></span></code></pre><ol start="2"><li>アクセス可能なGitLab Runnerのバージョンを確認します。</li></ol><pre className="language-shell shiki shiki-themes github-light" code="helm search repo -l gitlab/gitlab-runner
" language="shell" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#6F42C1">helm</span><span style="--shiki-default:#032F62"> search</span><span style="--shiki-default:#032F62"> repo</span><span style="--shiki-default:#005CC5"> -l</span><span style="--shiki-default:#032F62"> gitlab/gitlab-runner
</span></span></code></pre><ol start="3"><li>GitLab Runnerの最新バージョンにアクセスできない場合は、次のコマンドでチャートを更新してください。</li></ol><pre className="language-shell shiki shiki-themes github-light" code="helm repo update gitlab
" language="shell" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#6F42C1">helm</span><span style="--shiki-default:#032F62"> repo</span><span style="--shiki-default:#032F62"> update</span><span style="--shiki-default:#032F62"> gitlab
</span></span></code></pre><ol start="4"><li><code className="">values.yaml</code>ファイルでGitLab Runnerを設定した後、必要に応じてパラメーターを変更しながら次のコマンドを実行します。</li></ol><pre className="language-text" code="# For Helm 3

helm install --namespace &lt;NAMESPACE&gt; gitlab-runner \ 
  -f &lt;CONFIG_VALUES_FILE&gt; \ 
  gitlab/gitlab-runner
" language="text" meta=""><code># For Helm 3

helm install --namespace &lt;NAMESPACE&gt; gitlab-runner \ 
  -f &lt;CONFIG_VALUES_FILE&gt; \ 
  gitlab/gitlab-runner
</code></pre><ul><li><code className="">&lt;NAMESPACE&gt;</code>：GitLab RunnerをインストールするKubernetesの名前空間。</li><li><code className="">&lt;CONFIG_VALUES_FILE&gt;</code>：カスタム設定が含まれるvaluesファイルへのパス。作成方法はドキュメントをご参照ください。</li><li>特定バージョンのGitLab Runner Helm Chartをインストールする場合は、<code className="">helm install</code>コマンドに<code className="">--version &lt;RUNNER_HELM_CHART_VERSION&gt;</code>を追加してください。任意バージョンのHelm Chartをインストールできますが、新しい<code className="">values.yml</code>ファイルは古いバージョンと互換性がない場合があります。</li></ul><p>KubernetesでGitLab Runnerをインストールする詳細については、<a href="https://docs.gitlab.com/ja-jp/runner/install/kubernetes/#install-gitlab-runner-with-the-helm-chart" rel="">ドキュメント</a>をご覧ください。</p><blockquote><p>GitLab Runnerのインストールについてのよくあるご質問は、<a href="https://docs.gitlab.com/ja-jp/runner/faq/" rel="">FAQ</a>をご参照ください。</p></blockquote><h2 id="gitlab-runnerの登録方法">GitLab Runnerの登録方法</h2><p>インストール後、<a href="https://docs.gitlab.com/ja-jp/runner/register/" rel="">GitLab Runnerを登録</a>することで、GitLabインスタンスからジョブを取得できるようになります。この手順では、インストール済みのRunnerを1つ以上のGitLabインスタンスに接続します。</p><p>GitLab Runnerの登録方法はいくつかあります。本記事では、<a href="https://docs.gitlab.com/ja-jp/runner/register/#register-with-a-runner-authentication-token" rel="">認証トークンを使用したRunner登録</a>に焦点を当てます。</p><p><strong>前提条件</strong></p><ul><li>Runner認証トークンを取得してください。次のいずれかの方法で取得できます。<ul><li>インスタンス、グループ、またはプロジェクトのRunnerを作成する。手順については<a href="https://docs.gitlab.com/ja-jp/ci/runners/runners_scope/" rel="">Runnerの管理に関するドキュメント</a>をご参照ください。</li><li><code className="">config.toml</code>ファイル内のRunner認証トークンを確認する。Runner認証トークンのプレフィックスは<code className="">glrt-</code>です。</li></ul></li></ul><p>Runnerが登録されると、設定内容は<code className="">config.toml</code>ファイルに保存されます。このファイルはGitLab Runnerのメイン設定ファイルで、RunnerとCI/CDジョブの実行に必要なすべての設定を含んでいます。このファイルはいつでも編集でき、変更内容はサービスの再起動なしに次のジョブから反映されます。</p><p>Runner認証トークンを使用してRunnerを登録するには、次の手順を実施します。</p><ol><li>インストール方法に応じた登録コマンドを実行し、</li><li>GitLabインスタンスのURL（GitLab.comまたはGitLab Self-Managed）を入力し、</li><li>Runner認証トークンを入力し、</li><li>RunnerとジョブタグのDescriptionを追加し、</li><li>選択したExecutor（Docker、Shell、Kubernetesなど）を入力します。</li></ol><p>同一のホストマシン上で異なる設定を持つ複数のRunnerを登録するには、<code className="">register</code>コマンドを繰り返します。また、同一の設定を複数のホストマシンに登録するには、<a href="https://docs.gitlab.com/ja-jp/runner/fleet_scaling/#reusing-a-runner-configuration" rel="">各Runner登録で同じRunner認証トークンを使用</a>してください。</p><p>非インタラクティブモードを使用して、追加の引数でRunnerを登録することもできます。</p><p>Linuxを例に挙げると：</p><pre className="language-shell shiki shiki-themes github-light" code="sudo gitlab-runner register \
  --non-interactive \
  --url &quot;https://gitlab.com/&quot; \
  --token &quot;$RUNNER_TOKEN&quot; \
  --executor &quot;docker&quot; \
  --docker-image alpine:latest \
  --description &quot;docker-runner&quot;
" language="shell" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#6F42C1">sudo</span><span style="--shiki-default:#032F62"> gitlab-runner</span><span style="--shiki-default:#032F62"> register</span><span style="--shiki-default:#005CC5"> \
</span></span><span class="line" line="2"><span style="--shiki-default:#005CC5">  --non-interactive</span><span style="--shiki-default:#005CC5"> \
</span></span><span class="line" line="3"><span style="--shiki-default:#005CC5">  --url</span><span style="--shiki-default:#032F62"> &quot;https://gitlab.com/&quot;</span><span style="--shiki-default:#005CC5"> \
</span></span><span class="line" line="4"><span style="--shiki-default:#005CC5">  --token</span><span style="--shiki-default:#032F62"> &quot;</span><span style="--shiki-default:#24292E">$RUNNER_TOKEN</span><span style="--shiki-default:#032F62">&quot;</span><span style="--shiki-default:#005CC5"> \
</span></span><span class="line" line="5"><span style="--shiki-default:#005CC5">  --executor</span><span style="--shiki-default:#032F62"> &quot;docker&quot;</span><span style="--shiki-default:#005CC5"> \
</span></span><span class="line" line="6"><span style="--shiki-default:#005CC5">  --docker-image</span><span style="--shiki-default:#032F62"> alpine:latest</span><span style="--shiki-default:#005CC5"> \
</span></span><span class="line" line="7"><span style="--shiki-default:#005CC5">  --description</span><span style="--shiki-default:#032F62"> &quot;docker-runner&quot;
</span></span></code></pre><h2 id="runnerの動作確認と使用開始">Runnerの動作確認と使用開始</h2><p>ワークフローにRunnerを組み込む前に、正常に動作しているかどうかを確認してください。</p><ol><li>GitLab UIで確認する。</li></ol><p>a. プロジェクト内で <strong>設定 &gt; CI/CD &gt; Runners</strong> に移動します。</p><p>b. Runnerが<strong>アクティブかつ正常</strong>であることを確認します。</p><ol start="2"><li>選択したインストール方法に応じて<strong>コマンドライン</strong>で確認します。</li><li><code className="">.gitlab-ci.yml</code>ファイルを作成してシンプルなパイプラインでテストします。</li></ol><pre className="language-yaml shiki shiki-themes github-light" code="
test-runner: 
  stage: test 
  script: 
   - echo &quot;Hello GitLab Runner&quot; 
   - hostname 
   - date 
tags: 
   - my-tags # ⚠️ Replace with YOUR runner&#39;s tags
" language="yaml" meta="" style=""><code><span class="line" line="1"><span emptyLinePlaceholder>
</span></span><span class="line" line="2"><span style="--shiki-default:#22863A">test-runner</span><span style="--shiki-default:#24292E">: 
</span></span><span class="line" line="3"><span style="--shiki-default:#22863A">  stage</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">test</span><span style="--shiki-default:#24292E"> 
</span></span><span class="line" line="4"><span style="--shiki-default:#22863A">  script</span><span style="--shiki-default:#24292E">: 
</span></span><span class="line" line="5"><span style="--shiki-default:#24292E">   - </span><span style="--shiki-default:#032F62">echo &quot;Hello GitLab Runner&quot;</span><span style="--shiki-default:#24292E"> 
</span></span><span class="line" line="6"><span style="--shiki-default:#24292E">   - </span><span style="--shiki-default:#032F62">hostname</span><span style="--shiki-default:#24292E"> 
</span></span><span class="line" line="7"><span style="--shiki-default:#24292E">   - </span><span style="--shiki-default:#032F62">date</span><span style="--shiki-default:#24292E"> 
</span></span><span class="line" line="8"><span style="--shiki-default:#22863A">tags</span><span style="--shiki-default:#24292E">: 
</span></span><span class="line" line="9"><span style="--shiki-default:#24292E">   - </span><span style="--shiki-default:#032F62">my-tags</span><span style="--shiki-default:#6A737D"> # ⚠️ Replace with YOUR runner&#39;s tags
</span></span></code></pre><h2 id="gitlab-runnerのセキュリティと最適化のベストプラクティス">GitLab Runnerのセキュリティと最適化のベストプラクティス</h2><p>設定が不適切なGitLab Runnerは、パフォーマンスの低下やセキュリティ上の問題を引き起こす可能性があります。<a href="https://about.gitlab.com/ja-jp/topics/ci-cd/cicd-pipeline/" rel="" title="CI/CDパイプラインとは？">CI/CDパイプライン</a>を最大限に活用するためのベストプラクティスをご紹介します。</p><h3 id="runnerのセキュリティ">Runnerのセキュリティ</h3><ul><li><strong>隔離された環境を優先する</strong>：ホストマシン上でコマンドを直接実行するShellモードではなく、ジョブ間の明確な分離を提供する<strong>Docker</strong>または<strong>Kubernetes</strong>のExecutorを優先して使用してください。</li><li><strong>権限を制限する</strong>：必要でない限り、RunnerにAdminの権限を付与しないでください。攻撃対象領域を減らすため、最小限の権限で設定してください。</li><li><strong>タグによるアクセスを制御する</strong>：特定のジョブのみが実行されるよう、Runnerに特定のタグを割り当ててください。これにより、意図しないジョブが機密性の高いRunner上で実行されるリスクを防げます。</li></ul><h3 id="パイプラインのパフォーマンスと速度">パイプラインのパフォーマンスと速度</h3><ul><li><strong>軽量イメージを使用する</strong>：Docker ExecutorではビルドやCI要件に最適化されたイメージを選択してください（例：十分であれば<code className="">ubuntu</code>ではなく<code className="">alpine</code>）。これによりコンテナの起動時間を短縮できます。</li><li><strong>キャッシュを設定する</strong>：GitLabのキャッシュ機能を活用して、複数のパイプライン間で依存関係や生成ファイルを再利用してください。これにより全体的な実行時間が短縮されます。</li><li><strong>並列実行する</strong>：ジョブを並列で実行できる複数のステージに分割し、パイプライン全体の時間を短縮してください。</li></ul><h3 id="メンテナンスと信頼性">メンテナンスと信頼性</h3><ul><li><strong>Runnerを定期的に更新する</strong>：各バージョンにはバグ修正と新機能が含まれています。RunnerをGitLabのバージョンと同期させておくことで、互換性と安定性が確保されます。</li><li><strong>Runnerを監視する</strong>：組み込みメトリクス（例：Prometheus経由）を使用して、負荷、ジョブ実行時間、リソース使用状況を追跡してください。これによりボトルネックを事前に把握できます。</li><li><strong>冗長性を確保する</strong>：重要な環境では、負荷を分散しインシデントによるパイプライン停止を防ぐため、複数のRunnerをインストールしてください。</li></ul><h2 id="gitlab-cicdをさらに活用するために">GitLab CI/CDをさらに活用するために</h2><p><strong>GitLab Runner</strong>は、GitLabのCI/CDパイプライン、セキュリティテスト、完全な自動化と連携することで真の価値を発揮します。共有サービスモデルにおけるGitLab Runnerフリートの管理に関するベストプラクティスについては、<a href="https://docs.gitlab.com/ja-jp/runner/fleet_scaling/" rel="">ドキュメント</a>もあわせてご覧ください。</p><blockquote><p><strong><a href="https://about.gitlab.com/ja-jp/free-trial/devsecops/?utm_medium=blog&amp;utm_source=blog&amp;utm_campaign=eg_apj_x_trial_x_ja_blog_ja" rel="">→ GitLab UltimateおよびGitLab Duo Enterpriseを無料でお試しください。</a></strong></p></blockquote><style>html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}</style>]]></content>
        <author>
            <name>GitLab Japan Team</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/gitlab-japan-team/</uri>
        </author>
        <published>2026-03-17T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[コンプライアンス管理の自動化：GitLabを活用した実践ガイド]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/automated-compliance-management/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/automated-compliance-management/"/>
        <updated>2026-03-16T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>企業を取り巻く環境は複雑化しており、コンプライアンスはその中でも特に重要な規制上の要件となっています。とりわけ<a href="https://about.gitlab.com/ja-jp/solutions/software-compliance/" rel="">ソフトウェア開発</a>の分野においては、法令・規制・倫理・業界固有の要件を満たすために、組織が遵守すべき数多くのルール、ガイドライン、ベストプラクティスが存在します。コンプライアンス基準は法的拘束力のある法律から任意のフレームワークにまで及び、適法かつ責任ある事業運営を支えるとともに、データ、顧客、企業の評判を守るための役割を担っています。</p><p>本記事では、開発プロセスにおいて継続的なコンプライアンスを確保する方法を解説します——自動化によって余計な負荷をなくし、開発の妨げにならずに支援する仕組みを実現する方法です。GitLabのウェビナーから抜粋した動画も併せてご紹介します。</p><blockquote><p><strong><a href="https://page.gitlab.com/webcast-april8-dapwebinar-apac.html?utm_medium=webinar&amp;utm_source=blog&amp;utm_campaign=eg_japan_fmm_webcast_x_ja_" rel="">ウェビナー &quot;Intelligent Orchestrationが導くAgentic AIの未来&quot; を無料でご覧ください。</a></strong></p></blockquote><h2 id="コンプライアンス基準に取り組む際の課題">コンプライアンス基準に取り組む際の課題</h2><p>従来のコンプライアンスアプローチは摩擦を生み出し、開発チームの作業速度を低下させます。管理業務が増加し、時間とリソースが消耗されることで、セキュリティが「後でやればいい」と後回しにされがちになります。</p><h2 id="コンプライアンス管理の自動化実践例">コンプライアンス管理の自動化：実践例</h2><p>セキュリティ分野で急成長中のB2B企業が、新たな顧客獲得を目指しているとします。市場環境とターゲット顧客から、情報セキュリティ分野における厳格な基準（例：ISO 27001）の遵守が求められています。</p><p>このような認証の取得には、<a href="https://about.gitlab.com/blog/how-gitlab-can-support-your-iso-compliance-journey/" rel="">組織を挙げた相当な準備</a>が必要です。開発チーム、マネージャー、セキュリティチームが緊密に連携し、日常業務のプレッシャーの中でも認証取得と成長の両立を実現しなければなりません。</p><blockquote><p><strong>12倍の迅速な展開：GitLabの完全な統合により、Hiltiは効率を実現。</strong></p><p><a href="https://about.gitlab.com/ja-jp/" rel="">GitLab</a>は完全な可視性、包括的なコード管理、充実したセキュリティスキャンを提供し、Hiltiの新たなソフトウェア能力を支えています。Hiltiがいかにソフトウェア開発を革新したかをご覧ください。<strong><a href="https://about.gitlab.com/ja-jp/customers/hilti/" rel="">事例を読む</a></strong></p></blockquote><h3 id="企業内でのコンプライアンス実装">企業内でのコンプライアンス実装</h3><p>コンプライアンス基準を組織内に導入するには、体系的なプロセスが必要です。</p><ol><li><strong>コンプライアンスプロセスの定義：</strong> 監査人の要件から具体的な対応策を導出する</li><li><strong>現状のコンプライアンス状況の把握：</strong> 対象プロジェクトの定義</li><li><strong>是正措置の実施：</strong> プロジェクトへの新しいプロセスと修正の実装</li><li><strong>コンプライアンスの証明：</strong> 経営陣と監査人へのレポーティング</li></ol><p>最大の課題は、情報収集に伴う高い手動作業コストです。このプロセスへの複数チームの関与が、調整コストの増大と日常業務の中断を招きます。</p><h2 id="gitlabによるコンプライアンス管理の自動化手順ガイド">GitLabによるコンプライアンス管理の自動化：手順ガイド</h2><p>コンプライアンス基準の認証に関するすべての要件がソフトウェア開発の範囲に含まれるわけではありません。しかし、開発チームの認証取得における手動作業を最小限に抑え、時間を節約するために、GitLabはコンプライアンス管理の自動化を支援します。</p><p>目標は、担当者が形式的なチェック作業に追われるのではなく、本来の業務に集中できるようにすることです。</p><h3 id="_1-compliance-centerの活用">1. Compliance Centerの活用</h3><p>GitLabのCompliance Centerは、すべての情報を一目で把握できる中央ダッシュボードです。この一元的なビューから、対象となるすべてのプロジェクトのコンプライアンス状況を確認できます。</p><p>Compliance Centerにアクセスするには、GitLabアカウントの左側ナビゲーションバーで「<strong>Secure</strong>」&gt;「<strong>Compliance Center</strong>」をクリックしてください。</p><blockquote><p><strong><a href="https://page.gitlab.com/webcast-april8-dapwebinar-apac.html?utm_medium=webinar&amp;utm_source=blog&amp;utm_campaign=eg_japan_fmm_webcast_x_ja_" rel="">ウェビナー &quot;Intelligent Orchestrationが導くAgentic AIの未来&quot; を無料でご覧ください。</a></strong></p></blockquote><h3 id="_2-フレームワークの作成">2. フレームワークの作成</h3><p>各コンプライアンス基準を確実に遵守するには、対応するフレームワークを活用する必要があります。各組織には、業界標準、規制要件、または内部ポリシーに基づく固有のコンプライアンス要件があります。これらは「Frameworks」タブにおいて、自動的に監視・適用されるようGitLabでモデル化できます。</p><p>GitLabでは、<a href="https://about.gitlab.com/ja-jp/blog/how-to-use-gitlabs-custom-compliance-frameworks-in-your-devsecops/" rel="">独自フレームワークの作成</a>も、既存の<a href="https://gitlab.com/gitlab-org/software-supply-chain-security/compliance/engineering/compliance-adherence-templates" rel="">テンプレート</a>を自社ニーズに合わせてカスタマイズして利用することも可能です。</p><p><em>この動画（英語）では、新しいフレームワークを作成するプロセスをステップバイステップでご案内します。</em></p><iframe width="560" height="315" src="https://www.youtube.com/embed/bSwwv5XeMdQ?si=azLY5wJlSLkX2Fgc" title="YouTube video player" frameBorder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerPolicy="strict-origin-when-cross-origin" allowFullScreen></iframe><p>新しいフレームワーク を作成するには、以下の手順が必要です。</p><ul><li><strong>名前と説明を設定する：</strong> フレームワークの目的と重要性を伝えます。</li><li><strong>カラーバッジを選択する：</strong> プロジェクト横断的なフレームワークの識別子として機能します。</li><li><strong>（オプション）フレームワークをデフォルトとして設定する：</strong> 最初からコンプライアンス要件が維持されるようにし、ガイドレールを設定します。</li><li><strong>要件を追加する：</strong> 上位のコンプライアンス目標を表します。</li><li><strong>名前と説明を追加する：</strong> 要件の目的と重要性を伝えます。</li><li><strong>コントロールを設定する：</strong> 自動的に確認・検証できる技術的なチェックを定義します。</li></ul><p><strong>例：</strong> 「Segregation of Duties」という要件は、コードレビューの実施を確保します。自身のマージリクエストの承認を防止するために、「Author approved merge request is forbidden」と「At least one approval」というコントロールを作成することで、コードの変更が必ず別の担当者によってレビュー・承認されるよう保証します。</p><blockquote><p><strong><a href="https://page.gitlab.com/webcast-https://page.gitlab.com/webcast-april8-dapwebinar-apac.html?utm_medium=webinar&amp;utm_source=blog&amp;utm_campaign=eg_japan_fmm_webcast_x_ja_" rel="">ウェビナー &quot;Intelligent Orchestrationが導くAgentic AIの未来&quot; を無料でご覧ください。</a></strong></p></blockquote><p>新しいフレームワークに対する具体的な要件が定義されたら、フレームワークを作成できます。コンプライアンス要件はフレームワークを通じて自動チェックに変換されるため、手動による確認は不要になります。</p><p>このポリシーはプロジェクトに適用できるようになります。</p><h3 id="_3-フレームワークをプロジェクトに追加する">3. フレームワークをプロジェクトに追加する</h3><p>コンプライアンス監視を開始するには、フレームワークを対象プロジェクトに適用する必要があります。</p><p>「<strong>Projects</strong>」タブでは、すべてのプロジェクトと適用されているフレームワークを確認できます。個別のプロジェクトに新しいフレームワークを追加するには、「<strong>Action</strong>」列でプロジェクトを編集して対応するフレームワークを追加します。</p><p>一括編集機能を使用すると、すべてのプロジェクトにフレームワークを一度に追加できます。</p><ul><li>すべてのプロジェクトを選択する</li><li>「<strong>Choose one bulk action</strong>」オプションをクリックする</li><li>「<strong>Apply frameworks to selected projects</strong>」をクリックする</li><li>「<strong>Select framework</strong>」をクリックして対応するフレームワークを選択する</li><li>「<strong>Apply</strong>」をクリックする</li></ul><p>フレームワークをプロジェクトに追加すると、開発チームを妨げることなくコンプライアンス監視が自動的に開始されます。別途のオンボーディングや手動入力のフォームは不要です。</p><h3 id="_4-コンプライアンスステータスレポートの活用">4. コンプライアンスステータスレポートの活用</h3><p>コンプライアンスステータスレポートは、プロジェクトと対応する要件の概要を提供します。どの要件が達成され、どれが未達成かを明確に把握できます。</p><p>Compliance Centerの「<strong>Status</strong>」タブでは、すべてのプロジェクトにわたるフレームワーク遵守状況の詳細ビューを確認できます。</p><p>フィルター機能により、多数のプロジェクトを抱える大規模な組織でも簡単にナビゲートできます。レポーティングをニーズに合わせてカスタマイズし、各ステークホルダーに関連するレポートを正確に生成することが可能です。</p><p>ステータスレポートは、緑と赤のフラグによって現在の要件を視覚的に素早く評価し、特定のコントロールを通知し、煩雑な監査なしに問題を迅速に特定できるため、透明性を実現します。</p><p>これにより、コンプライアンス状況と講じるべき対策を明確に把握できます。</p><h3 id="_5-コンプライアンス違反を直接解決する">5. コンプライアンス違反を直接解決する</h3><p>ステータスレポートで失敗した要件が表示された場合は、<a href="https://about.gitlab.com/blog/how-to-transform-compliance-observation-management-with-gitlab/" rel="">直接解決</a>できます。各プロジェクトについて、どのコントロールが失敗したかが表示されます。対応するエラーをクリックすると、問題のドキュメントが開きます。</p><p>ドキュメントに加えて、関連するプロジェクト設定に直接誘導されるため、対象プロジェクト内を長時間検索することなく、問題をすぐに修正できます。</p><blockquote><p><strong><a href="https://page.gitlab.com/webcast-april8-dapwebinar-apac.html?utm_medium=webinar&amp;utm_source=blog&amp;utm_campaign=eg_japan_fmm_webcast_x_ja_" rel="">ウェビナー &quot;Intelligent Orchestrationが導くAgentic AIの未来&quot; を今無料でご覧ください。</a></strong></p></blockquote><h3 id="_6-複数プロジェクトにわたるコンプライアンス要件の是正">6. 複数プロジェクトにわたるコンプライアンス要件の是正</h3><p>複数のプロジェクトにコンプライアンス要件を定義している場合は、すべてを手動で確認するのではなく、関連する修正を自動化して実行できます。そのためにセキュリティポリシーを活用します。セキュリティポリシーは、セキュリティ関連のコントロールをプロジェクト・グループ・フレームワークレベルで標準ワークフローの一部として適用するものです。</p><p>GitLabアカウントの左側ナビゲーションバーで「<strong>Secure</strong>」&gt;「<strong>Policies</strong>」をクリックしてください。</p><p>「<strong>New Policy</strong>」から、複数プロジェクトに対する自動コンプライアンス要件を有効化できます。選択できるポリシーは以下のとおりです。</p><ul><li><a href="https://docs.gitlab.com/user/application_security/policies/scan_execution_policies/" rel="">Scan execution policy</a>：パイプラインの一部として、またはスケジュールに従ってセキュリティスキャンを実行します。</li><li><a href="https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/" rel="">Merge request approval policy</a>：プロジェクトレベルの設定と、スキャン結果に基づく承認ルールを適用します。</li><li><a href="https://docs.gitlab.com/user/application_security/policies/pipeline_execution_policies/" rel="">Pipeline execution policy</a>：プロジェクトパイプラインの一部としてCI/CDジョブを強制実行します。</li><li><a href="https://docs.gitlab.com/user/application_security/policies/vulnerability_management_policy/" rel="">Vulnerability management policy</a>：デフォルトブランチで検出されなくなったセキュリティ上の脆弱性を自動的に修正します。</li></ul><p>たとえば「Secret Detection」の分野で包括的なセキュリティ対策を設定するには、以下の手順に従ってください。</p><ul><li>「<strong>New Policy</strong>」をクリックする</li><li>「<strong>Scan execution policy</strong>」を選択する</li><li>名前を定義する</li><li>ポリシーの適用範囲として以下のいずれかを選択する</li><li>すべてのプロジェクト（「<strong>all projects in this group</strong>」）</li><li>特定のプロジェクト（「<strong>specific projects</strong>」）または</li><li>コンプライアンスフレームワーク（「<strong>projects with compliance framework</strong>」＋関連フレームワーク）</li><li>「<strong>Configuration Type</strong>」でポリシーのテンプレートを使用するか、個別設定を使用するかを選択する</li><li>新しいポリシーを保存する</li></ul><p>保存されると、ポリシーは自動的に適用されます。このプロジェクトでのすべてのパイプライン実行に「Secret Detection」要件が含まれるようになります。</p><h3 id="_7-gitlabによるレポーティングと監査サポート">7. GitLabによるレポーティングと監査サポート</h3><p>コンプライアンス管理の自動化は、開発者の日常業務をサポートするだけでなく、関連するステークホルダーへのレポーティングも容易にします。Compliance Centerを使用すると、規制当局、顧客、その他のステークホルダーとのコミュニケーションを効率化する包括的なレポーティングツールが利用できます。</p><p>Compliance Centerでは以下の情報を確認できます。</p><ul><li>コンプライアンスフレームワークでカバーされている<strong>プロジェクトの総数</strong></li><li><strong>コンプライアンス達成率</strong>（コンプライアンス要件を満たしているプロジェクトの割合）</li><li>組織全体の<strong>アクティブなフレームワーク</strong></li><li>対応が必要な<strong>重大な違反</strong></li></ul><p>GitLabは情報の流れを自動化し、手動の調整作業を排除してリアルタイムデータを処理することで、ステータスの把握を効率化します。豊富なエクスポート形式により、外部へのレポーティングも容易に実現できます。</p><blockquote><p><strong>GitLabを活用したコンプライアンスプロセスについて、<a href="https://about.gitlab.com/ja-jp/sales/?utm_medium=blog&amp;utm_source=blog&amp;utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_automated-compliance-management" rel="">お問い合わせをお待ちしております。</a></strong></p></blockquote><h2 id="gitlabによる自動化されたコンプライアンス管理のメリット">GitLabによる自動化されたコンプライアンス管理のメリット</h2><ul><li><strong>Single Source of Truth：</strong> 手動のExcelリストや調整ミーティングの代わりに、GitLabがコンプライアンス管理の一元的な拠点を提供します。</li><li><strong>統合されたコンプライアンス：</strong> 追加のプロセス負荷なしに、コンプライアンスを開発プロセスに組み込みます。</li><li><strong>高い効率性：</strong> 追加の手動ワークフローなしにコンプライアンスを実現します。</li><li><strong>直接的な対応：</strong> GitLabはコンプライアンスチェックを自動化し、違反を即座に検出してシンプルに解決できるようにします。</li><li><strong>フォーカスの向上：</strong> 開発チームが日常業務に集中できるようになります。</li><li><strong>高いセキュリティ：</strong> コンプライアンスが<strong>組織の根幹に根付く</strong>ようになります。</li><li><strong>可視性の向上：</strong> コンプライアンス担当者とコンプライアンス対策の組織内での認知度が高まります。</li><li><strong>簡素化されたレポーティング：</strong> 監査人が関連するすべての証拠をタイムリーに受け取れます。</li></ul><blockquote><p><strong>「この最適化されたアプローチは、コンプライアンスを後手対応の重い作業から、組織の成長に合わせて拡張できる能動的な仕組みへと変えていきます」</strong></p><p>– Karolina Franz、Solutions Architect @GitLab</p><p><strong><a href="https://page.gitlab.com/webcast-april8-dapwebinar-apac.html?utm_medium=webinar&amp;utm_source=blog&amp;utm_campaign=eg_japan_fmm_webcast_x_ja_" rel="">ウェビナー &quot;Intelligent Orchestrationが導くAgentic AIの未来&quot; を無料でご覧ください。</a></strong></p></blockquote><h2 id="gitlabによるコンプライアンスプロセス">GitLabによるコンプライアンスプロセス</h2><p>GitLabによるコンプライアンス管理の自動化には数多くのメリットがあります。本記事の冒頭で述べたように、コンプライアンス基準を確保するには組織に体系的なプロセスが必要です。</p><p>GitLabは以下の方法でそのようなプロセスの構築を支援します。</p><ul><li><strong>コンプライアンスプロセスの定義：</strong> 独自フレームワークにより、あらゆるコンプライアンス基準をモデル化・監視できます。これにより、ボトルネックなしに組織全体でコンプライアンスをスケールできるようになります。</li><li><strong>現状のコンプライアンス状況の把握：</strong> 包括的な監視によってすべての関連プロジェクトと要件を把握し、監査前に違反を通知するため、迅速な対応が可能です。</li><li><strong>是正措置の実施：</strong> ポリシーを活用することで、すべてのプロジェクトとチームにわたってコンプライアンス基準を自動的に確保できます。</li><li><strong>コンプライアンスの証明：</strong> レポーティングにはCompliance Centerを利用できます。すべてのプロジェクトを一元的に表示し、手動のステータス確認とワークフローを排除して、証拠が正確に提供されるよう保証します。</li></ul><h2 id="まとめ">まとめ</h2><p>コンプライアンスは一度限りの監査プロジェクトではなく、ソフトウェア開発に直接統合される必要がある継続的なプロセスです。手動による検査や孤立したワークフローはすぐに限界に達し、チームの作業速度を低下させます。</p><p>GitLabを使用することで、コンプライアンス要件を自動化・検証可能な基準に変換できます。フレームワーク、ポリシー、一元的な監視を通じて、開発者への追加負荷なしに、コンプライアンスが<strong>透明性・拡張性・実行力</strong>を備えたものになります。こうしてコンプライアンスは、セキュアなソフトウェア開発と持続的な成長のための信頼できる基盤となります。</p><blockquote><p><strong>規制要件を開発プロセスに直接組み込む</strong></p><p>コンプライアンス管理を自動化し、開発チームの力を引き出して、組織全体でコンプライアンスを持続的にスケールさせましょう。</p><p><strong><a href="https://about.gitlab.com/ja-jp/free-trial/?utm_medium=blog&amp;utm_source=blog&amp;utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_automated-compliance-management" rel="">今すぐ始める</a></strong></p></blockquote>]]></content>
        <author>
            <name>Sarah Matthies</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/sarah-matthies/</uri>
        </author>
        <author>
            <name>Karolina Franz</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/karolina-franz/</uri>
        </author>
        <published>2026-03-16T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[AIのパラドックスを解くカギはインテリジェント・オーケストレーション【GitLab Transcend Japanレポート】]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/event-report-transcend-tokyo-2026/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/event-report-transcend-tokyo-2026/"/>
        <updated>2026-03-10T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>2026年2月10日、GitLab は「GitLab Transcend Japan」を開催しました。本記事では、ビデオとセッションの模様を中心にレポートします。</p><h2 id="saasはagentic-aiの主語であるべき"><strong>SaaSはAgentic AIの「主語」であるべき</strong></h2><p><img alt="" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762586/uqq532hneioadonhyl6i.jpg" title="GitLab合同会社 Head of Japan 小澤 正治" /></p><p>GitLab は2026年2月10日、東京・六本木ヒルズクラブで「GitLab Transcend Japan」を開催しました。今回のイベントは、世界12都市で同日開催されたグローバルカンファレンスの一環で、GitLabを先進的に活用されている国内ユーザーの皆様の中から、グローバルで選定された方々を招待して実施しました。</p><p>オープニングセッションには、GitLab Head of Japan 小澤 正治が登壇。小澤は、AIが急速に普及し「手段」として定着しつつある現状を踏まえ、Tech <a href="https://about.gitlab.com/ja-jp/blog/what-is-saas/" rel="">SaaS</a>のあり方を再定義する必要性について以下のように語りました。</p><p>「これからは、<a href="https://about.gitlab.com/ja-jp/topics/agentic-ai/" rel="">Agentic AI</a>（自律型のAI）そのものを主語として考えるSaaSなのか、それともSaaSというプラットフォームを主語にして考えるAgentic AIなのか、この違いが問われる時代になります」</p><p>統合プラットフォームであるGitLabは、ソフトウェア開発における複雑なワークフローをコントロールし、すべてのトランザクションをデータとして蓄積しています。そして、この膨大かつ正確なデータ群のおかげで、人やAIはコンテキスト（文脈）としてその全容を理解できるようになるのです。つまり、AIが精度の高い回答を提供してくれるか否かは、こうしたデータがそろっているかどうかが大きなカギになるわけです。「これこそ、GitLabが提供できる根源的な価値になります」（小澤）。</p><p>小澤は、現在の日本企業を取り巻く環境について、3つの重要なトピックを挙げました。サイバーセキュリティと法規制、円安と輸出規制、および2025年の崖と人材不足です。</p><p>サイバーセキュリティと法規制では、サイバー攻撃によるインシデントが多発する中、NIST（米国国立標準技術研究所）のガイドラインなど、国内外の法規制への対応が必須となっています。もはやセキュリティは「努力目標」ではなく「経営課題」と言える状況です。円安と輸出規制では、円安が輸出企業にとって追い風になる一方、欧州のサイバーレジリエンス法（CRA）やGDPRなどの規制をクリアしなければグローバル市場で戦えません。これらがビジネスのハードルになるケースが増えてきています。最後の2025年の崖と人材不足では、レガシーシステムのモダナイゼーションを推進できるIT人材の確保が多くの企業にとって悩みの種になっています。</p><p>GitLabは、これらの課題に対しシングルプラットフォームという価値でこたえることができます。</p><p>小澤は、「ソフトウェア開発のすべてをGitLab上で行うことで、データは単一のデータストアに蓄積されます。分断されたツール群では成し得ないこのデータとコンテキストの一元化こそが、AI活用における最大の武器になります。また、コンプライアンスやガバナンスに強制力を効かせながら、効率を下げずにソフトウェア開発することで、安心・安全なデリバリーが可能になるのです」と語りました。</p><h2 id="インテリジェントオーケストレーションがソフトウェア開発の未来を切り拓く"><strong>インテリジェント・オーケストレーションがソフトウェア開発の未来を切り拓く</strong></h2><p><img alt="" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762585/aquhu0vpb07ibmortwhg.jpg" title="会場の様子" /></p><p>続いて、会場のスクリーンで全世界に向けたビデオが放映されました。GitLab CEO Bill Staplesをはじめとする経営陣、そして先進的なユーザー企業が登場し、AI時代の新たなソフトウェア開発戦略の発表の場です。</p><p>Staplesは、「月曜の朝、コーヒーを片手にPCを開き、仕事をスタートさせます。しかし、実際にコードを書く時間はどれくらいあるでしょう？」と語りかけます。<a href="https://about.gitlab.com/ja-jp/developer-survey/japan/" rel="">25万人の開発者を対象とした調査</a>によると、開発者が実際にコードを書いている時間は、1日平均でわずか52分に過ぎません。残りの時間は、会議、承認待ち、障害対応、およびその他の雑務に奪われているのです。</p><p>これがAIのパラドックスです。AIコーディングツールは、生産性10倍とうたいますが、それは業務全体のわずか10〜20%に過ぎないコーディング時間を短縮しているだけ。前後のプロセスにあるボトルネックが解消されない限り、ビジネス全体のデリバリー速度は劇的には向上しないのです。</p><p>この課題を解消するために、Staplesは「インテリジェント・オーケストレーション」という方向性を提唱します。これまでの開発は、人間がバケツリレーのように工程を渡していく「ステージベース」でした。これからは、AIエージェントが自律的にタスクを拾い、プロセス間を繋ぐ形へとシフトします。</p><p>「人間はループの上に立ち、エージェントをオーケストレーション（指揮）する役割へと進化します」（Staples）と語ります。雑務から解放され、戦略や創造的な意思決定に集中する未来の姿がそこにあります。</p><p>続いて、このビジョンを実践している企業として、サウスウエスト航空社のManaging Director、Grant Morris氏が登場しました。同社は、個別最適化されたツール群を捨て、GitLabでソフトウェア開発の全プロセスを統合。セキュリティとコンプライアンスを担保しながら開発者がビジネス価値の創出に集中できる環境を整備しています。</p><p>AI活用についてGrant氏は、「セキュリティ修正や依存関係のアップデートなど、エンジニアが疲弊するルーティンワークをAIエージェントに任せています」と語ります。さらに将来は、「AIエージェントがバックグラウンドで常にコードを監視し、リファクタリング（ソフトウェアの内部コード構造を整理する作業）やアップグレードを自律的に提案してくれるようになるでしょう。つまり、技術的負債という概念自体が過去のものになります」と語りました。</p><p>続いて登場したGitLab CPMOのManav Khuranaは、インテリジェント・オーケストレーションを実現するための製品戦略について解説しました。</p><p>まずは、AIエージェントをGitLab内で機能させる基盤となるAgentic Coreの進化。リポジトリやイシューなどをAIがコンテキストとして理解できるように構造化する独自技術を提供します。汎用的なエージェントに加え、各社独自のノウハウを組み込んだCustom Agentsを作成・公開できるAI Catalogを用意し、JiraやSlackなど外部ツールからもコンテキストを取得するためにModel Context Protocol （MCP）にも対応します。</p><p>既存機能の強化では、複雑なYAMLを書かずにAIと対話しながらパイプラインを構築できるAIファーストのCI/CDビルダーや、あらゆる成果物をGitLab内で一元管理し、AIエージェントが機密性の高い状態でも安全にアクセスできる仕組みを構築します。</p><p>GitLabは、SaaSだけでなく、オンプレミス環境でも利用できます。AIもオンプレミスで利用できるよう、ガバナンスを効かせた状態でAIを活用できる環境も提供します。独自のAIモデルを持ち込むBYOM（Bring Your Own Model）や、インターネット遮断環境（エアギャップ）にも対応します。</p><p>ビデオの終盤には、Oracle Group VPであるVictor Restrepo氏が登場し、GitLabとの強力なパートナーシップについて語りました。Restrepo氏は、Oracle Cloud Infrastructure （OCI）のコストパフォーマンスとGitLabの効率性を組み合わせることでインフラコストを削減し、その分をイノベーション投資に回すクラウドエコノミクスの重要性を強調。「政府系クラウドや専用リージョンを持つOCI上でGitLabを稼働させれば、厳しい規制が課される業界でもセキュアにAIを活用できるようになります」とGitLabとの親和性についても語りました。</p><h2 id="コンテキストを理解し自律的に動くaiエージェント"><strong>コンテキストを理解し、自律的に動くAIエージェント</strong></h2><p><img alt="" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762585/etl4f4uhcggrndlhwgr2.jpg" title="GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一" /></p><p>ビデオで披露された最新機能について、次のセッションで実機デモを交えた解説が行われました。その際にも強調されたのは、コンテキストの重要性です。AIエージェントが的確な仕事をするためには、プロジェクトの全容を理解している必要があります。企画から監視までをシングルプラットフォームで管理しているGitLabだからこそ、AIは断片的な情報ではなく、プロジェクトの全履歴という文脈を理解した上で自律的に動くことができるのです。</p><p>デモでは、まず<a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/planner/" rel="">Duo Planner Agent</a>を紹介。「こんな感じの機能をリリースしたい」という人間からの曖昧な指示に対し、AIはバックログや現状のコードベースを分析し、数分で具体的なタスクへと分解し、実行計画を立案してくれます。<a href="https://docs.gitlab.com/ja-jp/cli/duo/cli/" rel="">Duo CLI</a>のデモでは、ターミナル上での作業をAIが支援してくれる様子が披露されました。対話内容はWeb UIと同期されるため、開発者はツール間を行き来することなく、シームレスに作業を継続できます。</p><p><a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/" rel="">Foundational Flows</a>のデモでは、CIパイプラインが失敗した際にワンクリックでAIがログを解析してくれました。原因の特定から修正コードの作成、そして修正用マージリクエストの作成まで、AIが自律的に支援してくれます。<a href="https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/" rel="">Security Analyst Agent</a>も便利です。脆弱性が検出された際に、単に警告を出すだけではなく、AIエージェントが「なぜ危険なのか」を解説し、具体的な修正パッチを作成してくれます。</p><p><img alt="" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762585/a9yas83dxdhjopxifx5z.jpg" title="写真左から株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏、GitLab合同会社 Head of Japan 小澤正治" /></p><p>最後のセッションには、国内の先進事例として、株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏をお招きし、小澤とのFireside Chatを実施しました。かつてはシステムや言語が乱立する課題を抱えていた同社は内製化へと大きく舵を切り、大規模かつ多数のプロジェクトを効率的に推進しています。詳細なセッション内容は、近日中に公開予定です。</p><p>この日のイベントでは、Staplesの以下の発言が印象に残りました。</p><p>「ソフトウェア開発は、コードを書くことから価値を創ることへと変化しています」</p><p>GitLabは単なるツールから、人間とAIエージェントが協調して働くための基盤である「インテリジェント・オーケストレーション・プラットフォーム」へと進化します。AIのパラドックスを乗り越え、開発者が真のイノベーションに注力できる未来へ。「Transcend（=超越）」というイベント名にふさわしい、新たな時代が幕を開けます。</p>]]></content>
        <author>
            <name>GitLab Japan Team</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/gitlab-japan-team/</uri>
        </author>
        <published>2026-03-10T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[Monday Merge 3月号：コード高速化のその先：インテリジェント・オーケストレーションの台頭]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/monday-merge-2026-march-9/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/monday-merge-2026-march-9/"/>
        <updated>2026-03-09T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p><strong>AIは、コードを書く方法を根本的に変えました。しかし、ソフトウェアの「提供方法」そのものを自動的に変えたわけではありません。</strong></p><p><strong>コード生成が高速化する一方で、レビュー、テスト、セキュリティスキャン、デプロイといった下流工程に新たなボトルネックが生まれています。</strong></p><p>これが、私たちが「AIパラドックス」と呼ぶ現象です。</p><p>今月のMonday Mergeでは、計画、開発、セキュリティ、デプロイにわたるSDLC全体でのインテリジェント・オーケストレーションがこの課題にどのように対応し、エンタープライズDevSecOpsをどのように再構築しているのかを探ります。</p><h2 id="gitlab-189エージェント型aiがプラットフォームのさらに深部へ">GitLab 18.9：エージェント型AIがプラットフォームのさらに深部へ</h2><p><img alt="GitLab 18.9：エージェント型AIがプラットフォームのさらに深部へ" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772623381/sobem8usbdsht8jl1unz.png" /></p><p>2月の締めくくりに、25以上の改善とエージェント型AI機能の大幅な進化を含むGitLab 18.9をリリースしました。</p><h3 id="セルフマネージド環境向け-gitlab-duo-agent-platform"><strong>セルフマネージド環境向け GitLab Duo Agent Platform</strong></h3><p>GitLab Duo Agent Platformは、オンラインライセンスを持つセルフマネージドのお客様向けに提供開始となりました。自社インフラ内でエージェント型AI機能を必要とするエンタープライズチームにとって、これは大きな前進です。</p><h3 id="エージェント型sast脆弱性解決ベータ"><strong>エージェント型SAST脆弱性解決（ベータ）</strong></h3><p>SAST脆弱性のトリアージと修正は、アプリケーションセキュリティにおいて最も時間のかかる作業のひとつであることが多いです。GitLab 18.9では、GitLab Duoが次のことを実行できるようになりました。</p><ul><li>脆弱性を分析する</li><li>周辺コードの文脈を推論する</li><li>コンテキストを考慮した修正を生成する</li><li>マージリクエストを自動作成する</li><li>レビュアーの信頼度を示す品質スコアを提供する</li></ul><p>単一の提案を出すのではなく、GitLab Duoはコードベース全体を推論し、十分に検討された修正提案を生成します。</p><h3 id="gitlab-189のその他の改善点"><strong>GitLab 18.9のその他の改善点</strong></h3><p>新しい折りたたみ可能なファイルツリーによりリポジトリをナビゲートでき、ページ読み込み回数を減らしながら、より効率的にプロジェクト構造を閲覧できます。
GitLab.comではWebベースのコミット署名が利用可能になり、Web上のコミットがGitLabの署名キーで自動的に署名されます。</p><p>そして、本リリースに530件以上の貢献をしてくださったGitLabコミュニティの皆さまに心より感謝します。GitLabでは誰もが貢献できることを18.9は証明しています。</p><p><img alt="Transcend" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772623383/xhcvcceyvjtww9emfbsj.png" /></p><p>先日開催されたGitLab Transcendのバーチャルイベントでは、AIエージェントが計画、開発、テスト、セキュリティ、デプロイにわたって単一のプラットフォーム上でどのように連携し、エンタープライズのガードレールやガバナンス要件に沿って動作するのかをご紹介しました。</p><p>Southwest Airlines社からは、GitLab Duo Agent Platformがどのようにチームのミッションクリティカルなソフトウェアをより迅速に提供しながら、24時間365日の航空運航に必要なレジリエンスを維持しているかについてお話しいただきました。また、SDLC全体でエージェントが協働するライブデモも実施し、特定の工程だけでなく、デリバリーライフサイクル全体をどのようにモダナイズできるかを探りました。</p><p>イベントを見逃した方は、こちらからフル録画をご覧いただけます👇</p><p><a href="https://about.gitlab.com/ja-jp/events/transcend/virtual/" rel="">GitLab Transcendを視聴する</a></p><h2 id="技術デモ"><a href="https://about.gitlab.com/events/transcend/virtual/" rel=""></a>技術デモ</h2><p><img alt="技術デモ" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772623380/tch0unrnnwz2yjz7ba7y.png" /></p><p><a href="https://page.gitlab.com/webcasts-mar4-security-workflows-emea-amer.html" rel=""></a></p><h3 id="_3月19日-開発現場でのgitlab-duo-agent-platform">📅 3月19日 –  開発現場でのGitLab Duo Agent Platform</h3><p>本セッションでは、</p><ul><li>Duo Agent Platformを活用して、計画、Issueからのマージリクエスト（MR）作成、エージェント型コードレビューなど、複数ステップのワークフローを自動化する方法</li><li>GitLabの基盤エージェント（PlannerやSecurity Analystなど）を活用してSDLCを効率化する方法</li><li>GitLabの統合データモデルによる、コンテキストに応じたコード生成でコーディングを高速化する方法</li><li>AI駆動のセキュリティワークフローで脆弱性を自動検出・修復する方法</li><li>AIを活用した根本原因分析とガイド付きの修正により、パイプラインエラーを迅速に解決する方法</li></ul><p>をご紹介します。</p><p>👉 こちらからご登録ください。</p><p><a href="https://page.gitlab.com/webcasts-mar19-gitlab-duo-agent-platform-jp.html?utm_medium=social&amp;utm_source=twitter&amp;utm_campaign=eg_apac_cmp_webcast_ai_ja_20260319_apac_jp_cmp_techdemo_aisdlc_introtoduo" rel="">開発現場でのGitLab Duo Agent Platform</a></p><p><a href="https://page.gitlab.com/webcasts-mar12-gitlab-duo-agent-platform-emea-de.html" rel=""></a></p><h2 id="今月のおすすめ"><strong>今月のおすすめ</strong></h2><p><img alt="今月のおすすめ" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772623380/ejkfu5adv7bjwzwyevpd.png" /></p><p>今月は、インテリジェント・オーケストレーションの背景にあるより広い視点について、さらに深く掘り下げています。</p><p>CEOのBill Staplesは、AI時代におけるソフトウェアデリバリーについて語っています。</p><p>また、Chief Product and Marketing OfficerのManav Khuranaは、AIが単なる高速なコード生成を超え、品質、セキュリティ、そしてライフサイクル全体の最適化へと拡張されることで、真にイノベーションサイクルの加速が実現することを探っています。</p><p>さらに、セキュリティリーダーシップの観点からは、ソフトウェアライフサイクル全体におけるAI主導の変化に対応するため、エンタープライズがどのように組織構造モデルを進化させる必要があるのかという議論が続いています。</p><p>ポイントソリューションを超え、システム全体の変革を見据えている方にとって、これらの視点は一読の価値があります。</p><p><a href="https://www.cxotalk.com/episode/intelligent-orchestration-software-delivery-for-the-ai-era-with-ceo-of-gitlab" rel="">Intelligent Orchestration: Software Delivery for the AI Era, with CEO of GitLab</a></p><p><a href="https://thenewstack.io/gitlab-ceo-on-why-ai-isnt-helping-enterprise-ship-code-faster/" rel="">GitLab CEO on why AI isn’t helping enterprises ship code faster</a><a href="https://www.cxotalk.com/episode/intelligent-orchestration-software-delivery-for-the-ai-era-with-ceo-of-gitlab" rel=""></a><a href="https://www.cxotalk.com/episode/intelligent-orchestration-software-delivery-for-the-ai-era-with-ceo-of-gitlab" rel=""></a></p><p><a href="https://www.runtime.news/from-faster-coding-to-accelerated-innovation-cycles-how-intelligent-orchestration-unlocks-ais-promise/" rel="">From faster coding to accelerated innovation cycles: How intelligent orchestration unlocks AI&#39;s promise</a></p><p><a href="https://thenewstack.io/federate-security-gitlab/" rel="">The one structural shift CISOs must make before AI outpaces their security strategy</a><a href="https://www.runtime.news/from-faster-coding-to-accelerated-innovation-cycles-how-intelligent-orchestration-unlocks-ais-promise/" rel=""></a></p><p>最後に、インテリジェント・オーケストレーションの本質を表す言葉をご紹介します。</p><blockquote><p>「全体は部分の総和に勝る。」― アリストテレス</p></blockquote><p>インテリジェント・オーケストレーションは、まさにこの考えを体現しています。</p><p>AIが孤立した場面で活用されるだけでは、その効果は限定的です。しかし、統一されたコンテキストとエンタープライズのガードレールのもとで、エージェントがソフトウェアライフサイクル全体にわたり協調すれば、その成果は実際に測定可能なソフトウェア開発速度として現れます。</p><p>お読みいただきありがとうございました。ウェブキャストやIssueでお会いできるのを楽しみにしています。そして、これからも対話を続けていきましょう。それでは、いつものようにHappy Merging!</p><p><img alt="" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1770180580/nz0ipehzgtcb757kl0ux.png" /></p><p><a href="https://www.linkedin.com/in/sugaroverflow/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B3ix%2FZ9%2BgTBmIWuSHZsMZRw%3D%3D" rel="">Fatima Sarah Khalid</a>｜Senior Developer Advocate, GitLab</p><p>このニュースレターが気に入ったら、ぜひチームに共有してください。
そして👉<a href="https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg" rel="">YouTubeチャンネル</a>の登録もお忘れなく！</p>]]></content>
        <author>
            <name>GitLab Japan Team</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/gitlab-japan-team/</uri>
        </author>
        <published>2026-03-09T00:00:00.000Z</published>
    </entry>
</feed>