<?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-27T17:14:16.599Z</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[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>
    <entry>
        <title type="html"><![CDATA[MCPであらゆるツールを接続してGitLab Duo Agent Platformを拡張]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/extend-gitlab-duo-agent-platform-connect-any-tool-with-mcp/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/extend-gitlab-duo-agent-platform-connect-any-tool-with-mcp/"/>
        <updated>2026-03-05T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>ソフトウェア開発の管理では、複数のツールを同時に扱うことが求められます。Jiraで課題を追跡し、IDEでコードを記述し、GitLabでコラボレーションするといった具合です。こうしたプラットフォーム間のコンテキストの切り替えは集中力を妨げ、デリバリーを遅らせます。</p><p>GitLab Duo Agent Platformの<a href="https://about.gitlab.com/topics/ai/model-context-protocol/" rel="">MCP</a>サポートにより、Jiraをはじめ、MCPに対応するあらゆるツールを、AIを活用した開発環境に直接接続できるようになりました。課題の照会、チケットの更新、ワークフローの同期など、すべてを自然言語で、IDEを離れることなく実行できます。</p><h2 id="この記事で学べること">この記事で学べること</h2><p>このチュートリアルでは、以下の内容を解説します。</p><ul><li><strong>Jira/Atlassian OAuthアプリケーションのセットアップ</strong> — セキュアな認証を設定します</li><li><strong>GitLab Duo Agent Platformの設定</strong> — GitLab Duo Agent PlatformをMCPクライアントとして設定します</li><li><strong>3つの実践的なユースケース</strong> — 実際のワークフローのデモをご覧ください</li></ul><h2 id="前提条件">前提条件</h2><p>開始する前に、以下の要件を満たしていることをご確認ください。</p><table><thead><tr><th>要件</th><th>詳細</th></tr></thead><tbody><tr><td><strong>GitLabインスタンス</strong></td><td>Duo Agent Platformが有効なGitLab 18.8以降</td></tr><tr><td><strong>Jiraアカウント</strong></td><td>OAuthアプリケーションを作成できる管理者権限を持つJira Cloudインスタンス</td></tr><tr><td><strong>IDE</strong></td><td>GitLab Workflow拡張機能がインストールされたVisual Studio Code</td></tr><tr><td><strong>MCPサポート</strong></td><td>GitLabでMCPサポートが有効化済み</td></tr></tbody></table><h2 id="アーキテクチャの概要">アーキテクチャの概要</h2><p>GitLab Duo Agent Platformは<strong>MCPクライアント</strong>として機能し、Atlassian MCPサーバーに接続してJiraのプロジェクト管理データにアクセスします。Atlassian MCPサーバーは認証を処理し、自然言語のリクエストをAPI呼び出しに変換して、構造化されたデータをGitLab Duo Agent Platformに返します。このプロセス全体を通じて、セキュリティと監査管理が維持されます。</p><h2 id="パート1jira-oauthアプリケーションの設定">パート1：Jira OAuthアプリケーションの設定</h2><p>GitLab Duo Agent PlatformをJiraインスタンスに安全に接続するには、Atlassian Developer ConsoleでOAuth 2.0アプリケーションを作成する必要があります。これにより、GitLabのMCPサーバーにJiraデータへの認可されたアクセス権が付与されます。</p><h3 id="セットアップ手順">セットアップ手順</h3><p>手動で設定する場合は、以下の手順に従ってください。</p><ol><li><strong>Atlassian Developer Consoleへのアクセス</strong><ul><li><a href="https://developer.atlassian.com/console/myapps" rel="">developer.atlassian.com/console/myapps</a>にアクセスします。</li><li>Atlassianアカウントでサインインします。</li></ul></li><li><strong>新しいOAuth 2.0アプリの作成</strong><ul><li>「<strong>Create</strong>」→「<strong>OAuth 2.0 integration</strong>」をクリックします。</li><li>アプリ名を入力します（例：「gitlab-dap-mcp」）。</li><li>利用規約に同意し、「<strong>Create</strong>」をクリックします。</li></ul></li><li><strong>権限の設定</strong><ul><li>左サイドバーの「<strong>Permissions</strong>」に移動します。</li><li>「<strong>Jira API</strong>」を追加し、以下のスコープを設定します。<ul><li><code className="">read:jira-work</code> — 課題、プロジェクト、ボードの読み取り</li><li><code className="">write:jira-work</code> — 課題の作成と更新</li><li><code className="">read:jira-user</code> — ユーザー情報の読み取り</li></ul></li></ul></li><li><strong>認可の設定</strong><ul><li>左サイドバーの「<strong>Authorization</strong>」に移動します。</li><li>お使いの環境のコールバックURLを追加します（<code className="">https://gitlab.com/oauth/callback</code>）。</li><li>変更を保存します。</li></ul></li><li><strong>認証情報の取得</strong><ul><li>「<strong>Settings</strong>」に移動します。</li><li>「<strong>Client ID</strong>」と「<strong>Client Secret</strong>」をコピーします。</li><li>これらの認証情報はMCP設定に必要なため、安全な場所に保管してください。</li></ul></li></ol><h3 id="インタラクティブウォークスルーjira-oauthのセットアップ">インタラクティブウォークスルー：Jira OAuthのセットアップ</h3><p>以下の画像をクリックして開始してください。</p><p><a href="https://gitlab.navattic.com/jira-oauth-setup" rel=""><img alt="Jira OAuthセットアップツアー" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772644850/wnzfoq43nkkfmgdqldmr.png" /></a></p><h2 id="パート2gitlab-duo-agent-platformのmcpクライアントの設定">パート2：GitLab Duo Agent PlatformのMCPクライアントの設定</h2><p>OAuth認証情報の準備ができたら、GitLab Duo Agent PlatformをAtlassian MCPサーバーに接続するための設定を行います。</p><h3 id="mcp設定ファイルの作成">MCP設定ファイルの作成</h3><p>GitLabプロジェクトの <code className="">.gitlab/duo/mcp.json</code> にMCP設定ファイルを作成します。</p><pre className="language-json shiki shiki-themes github-light" code="{
  &quot;mcpServers&quot;: {
    &quot;atlassian&quot;: {
      &quot;type&quot;: &quot;http&quot;,
      &quot;url&quot;: &quot;https://mcp.atlassian.com/v1/mcp&quot;,
      &quot;auth&quot;: {
        &quot;type&quot;: &quot;oauth2&quot;,
        &quot;clientId&quot;: &quot;YOUR_CLIENT_ID&quot;,
        &quot;clientSecret&quot;: &quot;YOUR_CLIENT_SECRET&quot;,
        &quot;authorizationUrl&quot;: &quot;https://auth.atlassian.com/oauth/authorize&quot;,
        &quot;tokenUrl&quot;: &quot;https://auth.atlassian.com/oauth/token&quot;
      },
      &quot;approvedTools&quot;: true
    }
  }
}
" language="json" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#24292E">{
</span></span><span class="line" line="2"><span style="--shiki-default:#005CC5">  &quot;mcpServers&quot;</span><span style="--shiki-default:#24292E">: {
</span></span><span class="line" line="3"><span style="--shiki-default:#005CC5">    &quot;atlassian&quot;</span><span style="--shiki-default:#24292E">: {
</span></span><span class="line" line="4"><span style="--shiki-default:#005CC5">      &quot;type&quot;</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">&quot;http&quot;</span><span style="--shiki-default:#24292E">,
</span></span><span class="line" line="5"><span style="--shiki-default:#005CC5">      &quot;url&quot;</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">&quot;https://mcp.atlassian.com/v1/mcp&quot;</span><span style="--shiki-default:#24292E">,
</span></span><span class="line" line="6"><span style="--shiki-default:#005CC5">      &quot;auth&quot;</span><span style="--shiki-default:#24292E">: {
</span></span><span class="line" line="7"><span style="--shiki-default:#005CC5">        &quot;type&quot;</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">&quot;oauth2&quot;</span><span style="--shiki-default:#24292E">,
</span></span><span class="line" line="8"><span style="--shiki-default:#005CC5">        &quot;clientId&quot;</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">&quot;YOUR_CLIENT_ID&quot;</span><span style="--shiki-default:#24292E">,
</span></span><span class="line" line="9"><span style="--shiki-default:#005CC5">        &quot;clientSecret&quot;</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">&quot;YOUR_CLIENT_SECRET&quot;</span><span style="--shiki-default:#24292E">,
</span></span><span class="line" line="10"><span style="--shiki-default:#005CC5">        &quot;authorizationUrl&quot;</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">&quot;https://auth.atlassian.com/oauth/authorize&quot;</span><span style="--shiki-default:#24292E">,
</span></span><span class="line" line="11"><span style="--shiki-default:#005CC5">        &quot;tokenUrl&quot;</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">&quot;https://auth.atlassian.com/oauth/token&quot;
</span></span><span class="line" line="12"><span style="--shiki-default:#24292E">      },
</span></span><span class="line" line="13"><span style="--shiki-default:#005CC5">      &quot;approvedTools&quot;</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#005CC5">true
</span></span><span class="line" line="14"><span style="--shiki-default:#24292E">    }
</span></span><span class="line" line="15"><span style="--shiki-default:#24292E">  }
</span></span><span class="line" line="16"><span style="--shiki-default:#24292E">}
</span></span></code></pre><p><code className="">YOUR_CLIENT_ID</code> と <code className="">YOUR_CLIENT_SECRET</code> は、パート1で生成した認証情報に置き換えてください。</p><h3 id="gitlabでmcpを有効化">GitLabでMCPを有効化</h3><ol><li>「<strong>グループ設定</strong>」→「<strong>GitLab Duo</strong>」→「<strong>Configuration</strong>」に移動します。</li><li>「Allow external MCP tools」にチェックが入っていることを確認します。</li></ol><h3 id="接続の確認">接続の確認</h3><p>VS Codeでプロジェクトを開いてGitLab Duo Agent Platformのチャットで次のように入力してください。</p><pre className="language-text" code="What MCP tools do you have access to?
" language="text" meta=""><code>What MCP tools do you have access to?
</code></pre><p>次に、以下のように入力します。</p><pre className="language-text" code="Test the MCP JIRA configuration in this project
" language="text" meta=""><code>Test the MCP JIRA configuration in this project
</code></pre><p>この時点で、IDEからAtlassian MCPウェブサイトにリダイレクトされ、アクセスの承認を求められます。</p><p><img alt="Atlassian MCPウェブサイトへのリダイレクト" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643461/z5acqjgguh0damnnde9g.png" title="MCPのAtlassianウェブサイトへのリダイレクト" /></p><p><br /><br /></p><p><img alt="アクセスの承認" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643461/rwowamm8nsubhpixtn3i.png" title="アクセスの承認" /></p><p><br /><br /></p><p><img alt="JIRAインスタンスを選択して承認" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643461/chuzqd0jeptfwvoj7wjr.png" title="JIRAインスタンスを選択して承認" /></p><p><br /><br /></p><p><img alt="成功！" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643462/bsgti5iste2bzck19o5y.png" title="成功！" /></p><p><br /><br /></p><h3 id="mcpダッシュボードでの確認">MCPダッシュボードでの確認</h3><p>GitLabには、IDEに組み込みの<strong>MCPダッシュボード</strong>も用意されています。</p><p>VS CodeまたはVSCodiumで、コマンドパレット（macOSでは <code className="">Cmd+Shift+P</code>、Windows/Linuxでは <code className="">Ctrl+Shift+P</code>）を開いて「<strong>GitLab: Show MCP Dashboard</strong>」を検索してください。ダッシュボードは新しいエディタータブで表示され、以下の情報を確認できます。</p><ul><li>設定済みの各MCPサーバーの<strong>接続ステータス</strong></li><li>サーバーが公開している<strong>利用可能なツール</strong>（例：<code className="">jira_get_issue</code>、<code className="">jira_create_issue</code>）</li><li><strong>サーバーログ</strong> — リアルタイムで呼び出されているツールを確認可能</li></ul><p><img alt="MCPサーバーのダッシュボードとステータス" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643462/mmvdfchucacsydivowvn.png" title="MCPサーバーのダッシュボードとステータス" /></p><p><br /><br /></p><p><img alt="サーバーの詳細と権限" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643462/tcocgdvovp2dl42pvfn8.png" title="サーバーの詳細と権限" /></p><p><br /><br /></p><p><img alt="MCPサーバーログ" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772643466/mougvqqk1bozchaufsci.png" title="MCPサーバーログ" /></p><p><br /><br /></p><h3 id="インタラクティブウォークスルーmcpのテスト">インタラクティブウォークスルー：MCPのテスト</h3><iframe src="https://player.vimeo.com/video/1170005495?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="Testing MCP"></iframe><script src="https://player.vimeo.com/api/player.js"></script><h2 id="パート3実践的なユースケース">パート3：実践的なユースケース</h2><p>統合の設定が完了したら、JiraをGitLab Duo Agent Platformへの接続を実現できる3つの実践的なワークフローを見ていきましょう。</p><h3 id="プランニングアシスタント">プランニングアシスタント</h3><p><strong>シナリオ：</strong> スプリントプランニングの準備として、バックログをすばやく評価し、優先事項を把握し、ブロッカーを特定する必要があります。</p><p>このデモでは以下の操作を紹介します。</p><ul><li>バックログの照会</li><li>未割り当ての高優先度課題の特定</li><li>AIによるスプリント推奨の取得</li></ul><h4 id="プロンプト例">プロンプト例</h4><p>GitLab Duo Agent Platformのチャットで以下のプロンプトをお試しください。</p><pre className="language-text" code="List all the unassigned issues in JIRA for project GITLAB
" language="text" meta=""><code>List all the unassigned issues in JIRA for project GITLAB
</code></pre><pre className="language-text" code="Suggest the two top issues to prioritize and summarize them. Assign them to me.
" language="text" meta=""><code>Suggest the two top issues to prioritize and summarize them. Assign them to me.
</code></pre><h3 id="インタラクティブウォークスループロジェクトプランニング">インタラクティブウォークスルー：プロジェクトプランニング</h3><iframe src="https://player.vimeo.com/video/1170005462?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="Project Planning"></iframe><script src="https://player.vimeo.com/api/player. js"></script><h3 id="コードからの課題トリアージと作成">コードからの課題トリアージと作成</h3><p><strong>シナリオ：</strong> コードレビュー中にバグを発見し、IDEを離れることなく、関連するコンテキストに沿ってJiraの課題を作成したい場合です。</p><p>このデモでは以下の手順を紹介します。</p><ul><li>コーディング中のバグの特定</li><li>自然言語を使ったJira課題の詳細な作成</li><li>コードのコンテキストに沿った課題フィールドの自動入力</li><li>現在のブランチへの課題のリンク</li></ul><h4 id="プロンプト例-1">プロンプト例</h4><pre className="language-text" code="Search in JIRA for a bug related to: Null pointer exception in PaymentService.processRefund().
If it does not exist create it with all the context needed from the code. Find possible blockers that this bug may cause.
" language="text" meta=""><code>Search in JIRA for a bug related to: Null pointer exception in PaymentService.processRefund().
If it does not exist create it with all the context needed from the code. Find possible blockers that this bug may cause.
</code></pre><pre className="language-text" code="Create a new branch called issue-gitlab-18, checkout, and link it to the issue we just created. Assign the JIRA issue to me and mark it as in-progress.
" language="text" meta=""><code>Create a new branch called issue-gitlab-18, checkout, and link it to the issue we just created. Assign the JIRA issue to me and mark it as in-progress.
</code></pre><h3 id="インタラクティブウォークスルーバグレビューとタスク自動化">インタラクティブウォークスルー：バグレビューとタスク自動化</h3><iframe src="https://player.vimeo.com/video/1170005368?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="Bug Review"></iframe><script src="https://player.vimeo.com/api/player.js"></script><h3 id="クロスシステムのインシデント調査">クロスシステムのインシデント調査</h3><p><strong>シナリオ：</strong> 本番環境でインシデントが発生し、Jira（インシデントチケット）、GitLabプロジェクト管理、コードベース、マージリクエストからの情報を照合して根本原因を特定する必要があります。</p><p>このデモでは以下を実演します。</p><ul><li>Jiraからのインシデント詳細の取得</li><li>GitLabの最近のマージリクエストとの照合</li><li>関連する可能性のあるコード変更の特定</li><li>インシデントタイムラインの生成</li><li>修正計画の設計とGitLabのワークアイテムとしての作成</li></ul><h4 id="プロンプト例-2">プロンプト例</h4><pre className="language-text" code="&quot;We have a production incident INC-1 about checkout failures. Can you help me investigate with all available context?&quot;
" language="text" meta=""><code>&quot;We have a production incident INC-1 about checkout failures. Can you help me investigate with all available context?&quot;
</code></pre><pre className="language-text" code="Create a timeline of events for incident INC-1 including related Jira issues and recent deployments
" language="text" meta=""><code>Create a timeline of events for incident INC-1 including related Jira issues and recent deployments
</code></pre><pre className="language-text" code="Propose a remediation plan
" language="text" meta=""><code>Propose a remediation plan
</code></pre><h3 id="インタラクティブウォークスルークロスシステムのトラブルシューティングと修正">インタラクティブウォークスルー：クロスシステムのトラブルシューティングと修正</h3><iframe src="https://player.vimeo.com/video/1170005413?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="Cross System Investigation"></iframe><script src="https://player.vimeo.com/api/player.js"></script><h2 id="トラブルシューティング">トラブルシューティング</h2><p>よくあるセットアップの問題と解決策を以下にまとめます。</p><table><thead><tr><th>問題</th><th>解決策</th></tr></thead><tbody><tr><td>「MCP server not found」</td><td><code className="">mcp.json</code> ファイルが正しい場所にあり、適切にフォーマットされていることを確認してください。</td></tr><tr><td>「Authentication failed」</td><td>OAuth認証情報を再確認し、Atlassianでスコープが正しく設定されていることを確認してください。</td></tr><tr><td>「No Jira tools available」</td><td><code className="">mcp.json</code> を更新後にVS Codeを再起動し、GitLabでMCPが有効になっていることを確認してください。</td></tr><tr><td>「Connection timeout」</td><td><code className="">mcp.atlassian.com</code> へのネットワーク接続を確認してください。</td></tr></tbody></table><p><br /> 詳細なトラブルシューティングについては、<a href="https://docs.gitlab.com/ja-jp/user/gitlab_duo/model_context_protocol/mcp_clients/" rel="">GitLab MCPクライアントのドキュメント</a>をご参照ください。</p><h2 id="セキュリティに関する考慮事項">セキュリティに関する考慮事項</h2><p>JiraをGitLab Duo Agent Platformと統合する際は、以下の点にご注意ください。</p><ul><li><strong>OAuthトークン</strong> — 認証情報を安全に管理してください。</li><li><strong>最小権限の原則</strong> — Jiraスコープは必要最小限のみ付与してください。</li><li><strong>トークンのローテーション</strong> — セキュリティ管理の一環として、OAuth認証情報を定期的にローテーションしてください。</li></ul><h2 id="まとめ">まとめ</h2><p>MCPを通じてGitLab Duo Agent Platformをさまざまなツールに接続することで、開発ライフサイクルとのインタラクションが大きく変わります。この記事では、以下の方法を学びました。</p><ul><li><strong>自然言語による課題の照会</strong> — バックログ、スプリント、インシデントについて自然言語で質問できます。</li><li><strong>DevSecOps環境全体での課題の作成と更新</strong> — IDEを離れることなくバグを報告し、チケットを更新できます。</li><li><strong>システム間の情報照合</strong> — JiraのデータをGitLabのプロジェクト管理、マージリクエスト、パイプラインと組み合わせることで、全体的な可視性が得られます。</li><li><strong>コンテキスト切り替えの削減</strong> — プロジェクト管理とのつながりを維持しながら、コードに集中できます。</li></ul><p>この統合は、MCPの可能性を体現するものです。AIを通じてツールへの標準化されたセキュアなアクセスを提供し、ガバナンスやセキュリティを損なうことなく、デベロッパーがより効率的に作業できる環境を実現します。</p><h2 id="関連リソース">関連リソース</h2><ul><li><a href="https://about.gitlab.com/ja-jp/blog/duo-agent-platform-with-mcp/" rel="">Model Context Protocol統合</a></li><li><a href="https://about.gitlab.com/topics/ai/model-context-protocol/" rel="">Model Context Protocolとは</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/agentic-ai-guides-and-resources/" rel="">エージェント型AIに関するガイドとリソース</a></li><li><a href="https://docs.gitlab.com/ja-jp/user/gitlab_duo/model_context_protocol/mcp_clients/" rel="">GitLab MCPクライアントのドキュメント</a></li><li><a href="https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-complete-getting-started-guide/" rel="">GitLab Duo Agent Platformを始める：完全ガイド</a></li></ul><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>Albert Rabassa</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/albert-rabassa/</uri>
        </author>
        <published>2026-03-05T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLab コンテナスキャン完全ガイド：SBOM生成から運用監視まで5つのスキャン手法]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/complete-guide-to-gitlab-container-scanning/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/complete-guide-to-gitlab-container-scanning/"/>
        <updated>2026-03-05T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>コンテナの脆弱性は、次のデプロイメントを待ってくれるわけではありません。イメージのビルド時や、コンテナが本番環境で稼働している間など、あらゆるタイミングで発生する可能性があります。
GitLab はこうした現実に対応するため、コンテナライフサイクルのさまざまな段階に対応した複数のコンテナスキャンアプローチを提供しています。</p><p>本ガイドでは、GitLab が提供するコンテナスキャンの種類、各機能の有効化方法、および初期設定に役立つ一般的な構成についてご説明します。</p><h2 id="コンテナスキャンが重要な理由">コンテナスキャンが重要な理由</h2><p>コンテナイメージのセキュリティ脆弱性は、アプリケーションライフサイクル全体にわたってリスクをもたらします。ベースイメージ、OSパッケージ、アプリケーションの依存関係はいずれも、攻撃者が積極的に悪用する脆弱性を含んでいる可能性があります。コンテナスキャンはこれらのリスクを早期に、本番環境に到達する前に検出し、利用可能な場合は修正方法を提供します。</p><p>コンテナスキャンはソフトウェアコンポジション分析（SCA）の重要なコンポーネントであり、コンテナ化されたアプリケーションが依存する外部依存関係を把握し、保護するために役立ちます。</p><h2 id="gitlab-コンテナスキャンの5つの種類">GitLab コンテナスキャンの5つの種類</h2><p>GitLab は5つの異なるコンテナスキャンアプローチを提供しており、それぞれがセキュリティ戦略において固有の目的を果たします。</p><h3 id="_1-パイプラインベースのコンテナスキャン">1. パイプラインベースのコンテナスキャン</h3><ul><li>機能：CI/CDパイプラインの実行中にコンテナイメージをスキャンし、デプロイ前に脆弱性を検出します。</li><li>最適な用途：シフトレフトセキュリティ、脆弱性のあるイメージが本番環境に到達するのを防止</li><li>利用可能なプラン：Free、Premium、Ultimate（Ultimateではより高度な機能を利用可能）</li><li><a href="https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/" rel="">ドキュメント</a></li></ul><p>GitLab は Trivy セキュリティスキャナーを使用してコンテナイメージの既知の脆弱性を分析します。パイプラインの実行時にスキャナーがイメージを検査し、詳細なレポートを生成します。</p><h4 id="パイプラインベースのコンテナスキャンを有効にする方法">パイプラインベースのコンテナスキャンを有効にする方法</h4><p><strong>オプション A：事前設定済みのマージリクエスト</strong></p><ul><li>プロジェクトで <strong>Secure &gt; セキュリティ設定</strong> に移動します。</li><li>「コンテナスキャン」の行を見つけます。</li><li><strong>マージリクエストで設定</strong> を選択します。</li><li>必要な設定を含むマージリクエストが自動的に作成されます。</li></ul><p><strong>オプション B：手動設定</strong></p><ul><li><code className="">.gitlab-ci.yml</code> に以下を追加します。</li></ul><pre className="language-yaml shiki shiki-themes github-light" code="include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml
" language="yaml" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#22863A">include</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="2"><span style="--shiki-default:#24292E">  - </span><span style="--shiki-default:#22863A">template</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">Jobs/Container-Scanning.gitlab-ci.yml
</span></span></code></pre><h4 id="一般的な設定">一般的な設定</h4><p><strong>特定のイメージをスキャンする：</strong></p><p>特定のイメージをスキャンするには、<code className="">container_scanning</code> ジョブの <code className="">CS_IMAGE</code> 変数を上書きします。</p><pre className="language-yaml shiki shiki-themes github-light" code="include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_IMAGE: myregistry.com/myapp:latest
" language="yaml" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#22863A">include</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="2"><span style="--shiki-default:#24292E">  - </span><span style="--shiki-default:#22863A">template</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">Jobs/Container-Scanning.gitlab-ci.yml
</span></span><span class="line" line="3"><span emptyLinePlaceholder>
</span></span><span class="line" line="4"><span style="--shiki-default:#22863A">container_scanning</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="5"><span style="--shiki-default:#22863A">  variables</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="6"><span style="--shiki-default:#22863A">    CS_IMAGE</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">myregistry.com/myapp:latest
</span></span></code></pre><p><strong>重大度のしきい値でフィルタリングする：</strong></p><p>特定の重大度基準を持つ脆弱性のみを検出するには、<code className="">container_scanning</code> ジョブの <code className="">CS_SEVERITY_THRESHOLD</code> 変数を上書きします。以下の例では、重大度が <strong>High</strong> 以上の脆弱性のみが表示されます。</p><pre className="language-yaml shiki shiki-themes github-light" code="include:
  - template: Jobs/Container-Scanning.gitlab-ci.yml

container_scanning:
  variables:
    CS_SEVERITY_THRESHOLD: &quot;HIGH&quot;
" language="yaml" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#22863A">include</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="2"><span style="--shiki-default:#24292E">  - </span><span style="--shiki-default:#22863A">template</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">Jobs/Container-Scanning.gitlab-ci.yml
</span></span><span class="line" line="3"><span emptyLinePlaceholder>
</span></span><span class="line" line="4"><span style="--shiki-default:#22863A">container_scanning</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="5"><span style="--shiki-default:#22863A">  variables</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="6"><span style="--shiki-default:#22863A">    CS_SEVERITY_THRESHOLD</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">&quot;HIGH&quot;
</span></span></code></pre><h4 id="マージリクエストでの脆弱性の確認">マージリクエストでの脆弱性の確認</h4><p>マージリクエスト内でコンテナスキャンの脆弱性を直接確認することで、セキュリティレビューをシームレスかつ効率的に実施できます。CI/CDパイプラインにコンテナスキャンを設定すると、GitLab はマージリクエストの<a href="https://docs.gitlab.com/ja-jp/user/project/merge_requests/widgets/#application-security-scanning" rel="">セキュリティウィジェット</a>に検出された脆弱性を自動的に表示します。</p><p><img alt="マージリクエストに表示されたコンテナスキャンの脆弱性" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/lt6elcq6jexdhqatdy8l.png" title="マージリクエストに表示されたコンテナスキャンの脆弱性" /></p><ul><li>マージリクエストの「セキュリティスキャン」セクションまでスクロールすると、コンテナイメージで新たに検出された脆弱性と既存の脆弱性の概要が確認できます。</li><li><strong>脆弱性</strong> をクリックすると、重大度レベル、影響を受けるパッケージ、利用可能な修正ガイダンスなど、検出内容の詳細情報にアクセスできます。</li></ul><p><img alt="GitLab セキュリティ - MRでの詳細表示" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547514/hplihdlekc11uvpfih1p.png" /></p><p><img alt="GitLab セキュリティ - MRでの詳細表示" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/jnxbe7uld8wfeezboifs.png" title="MRでのコンテナスキャン脆弱性の詳細" /></p><p>この可視性により、開発者とセキュリティチームはコンテナの脆弱性が本番環境に到達する前に発見・対処できるようになり、セキュリティがコードレビュープロセスに統合されます。</p><h4 id="脆弱性レポートでの脆弱性の確認">脆弱性レポートでの脆弱性の確認</h4><p>マージリクエストのレビューに加え、GitLab はプロジェクト内のすべてのコンテナスキャン結果を一元的に確認できる<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/v1772547524/gagau279fzfgjpnvipm5.png" title="コンテナスキャンでフィルタリングされた脆弱性レポート" /></p><ul><li>プロジェクトのサイドバーで <strong>セキュリティとコンプライアンス &gt; 脆弱性レポート</strong> に移動してレポートにアクセスします。</li><li>ここでは、ブランチ全体で検出されたすべてのコンテナ脆弱性が集約されて表示され、重大度、ステータス、スキャナーの種類、特定のコンテナイメージでフィルタリングする強力なオプションが利用できます。</li><li>脆弱性をクリックすると、脆弱性ページにアクセスできます。</li></ul><p><img alt="脆弱性ページ - 1番目のビュー" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547520/e1woxupyoajhrpzrlylj.png" /></p><p><img alt="脆弱性ページ - 2番目のビュー" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547521/idzcftcgjc8eryixnbjn.png" /></p><p><img alt="脆弱性ページ - 3番目のビュー" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547522/mbbwbbprtf9anqqola10.png" title="コンテナスキャン脆弱性の詳細" /></p><p><a href="https://docs.gitlab.com/ja-jp/user/application_security/vulnerabilities/" rel="">脆弱性の詳細</a>では、影響を受けるコンテナイメージとレイヤーが正確に示されるため、脆弱性の発生源を容易に追跡できます。脆弱性をチームメンバーに割り当て、ステータスを変更（検出済み、確認済み、解決済み、却下済み）し、コラボレーションのためのコメントを追加し、修正作業の追跡のために関連するイシューをリンクすることができます。</p><p>このワークフローにより、脆弱性管理がスプレッドシートによる管理から開発プロセスの一部へと変わり、コンテナセキュリティの検出結果が体系的に追跡・優先順位付け・解決されるようになります。</p><h4 id="依存関係リストの確認">依存関係リストの確認</h4><p>GitLab の<a href="https://docs.gitlab.com/ja-jp/user/application_security/dependency_list/" rel="">依存関係リスト</a>は、コンテナイメージ内のすべてのコンポーネントをカタログ化した包括的なソフトウェア部品表（SBOM）を提供し、ソフトウェアサプライチェーンの完全な透明性をもたらします。</p><ul><li><strong>セキュリティとコンプライアンス &gt; 依存関係リスト</strong> に移動すると、プロジェクト全体でコンテナスキャンが検出したすべてのパッケージ、ライブラリ、依存関係のインベントリにアクセスできます。</li><li>このビューは、ベースOSパッケージからアプリケーションレベルの依存関係まで、コンテナ内で実際に稼働しているものを把握するために非常に役立ちます。</li></ul><p><img alt="GitLab 依存関係リスト" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/vjg6dk3nhajqamplroji.png" title="GitLab 依存関係リスト（SBOM）" /></p><p>パッケージマネージャー、ライセンスの種類、または脆弱性のステータスでリストをフィルタリングすることで、セキュリティリスクやコンプライアンス上の問題をもたらすコンポーネントを素早く特定できます。各依存関係エントリには関連する脆弱性が表示されるため、単独の検出結果としてではなく、実際のソフトウェアコンポーネントのコンテキストでセキュリティの問題を把握できます。</p><h3 id="_2-レジストリ向けコンテナスキャン">2. レジストリ向けコンテナスキャン</h3><ul><li>機能：<code className="">latest</code> タグで GitLab コンテナレジストリにプッシュされたイメージを自動的にスキャンします。</li><li>最適な用途：手動のパイプラインを実行することなく、レジストリイメージの継続的なモニタリングを実施</li><li>利用可能なプラン：Ultimate のみ</li><li><a href="https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/#container-scanning-for-registry" rel="">ドキュメント</a></li></ul><p><code className="">latest</code> タグが付いたコンテナイメージをプッシュすると、GitLab のセキュリティポリシーボットがデフォルトブランチに対してスキャンを自動的にトリガーします。パイプラインベースのスキャンとは異なり、このアプローチは継続的脆弱性スキャンと連携して、新たに公開されたアドバイザリーを監視します。</p><h4 id="レジストリ向けコンテナスキャンを有効にする方法">レジストリ向けコンテナスキャンを有効にする方法</h4><ol><li><strong>Secure &gt; セキュリティ設定</strong> に移動します。</li><li><strong>レジストリ向けコンテナスキャン</strong> セクションまでスクロールします。</li><li>機能をオンに切り替えます。</li></ol><p><img alt="レジストリ向けコンテナスキャン" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547512/vntrlhtmsh1ecnwni5ji.png" title="レジストリ向けコンテナスキャンの切り替えスイッチ" /></p><h4 id="前提条件">前提条件</h4><ul><li>プロジェクトのメンテナーロール以上</li><li>プロジェクトが空でないこと（デフォルトブランチに少なくとも1つのコミットが必要）</li><li>コンテナレジストリの通知が設定済みであること</li><li>パッケージメタデータデータベースが設定済みであること（GitLab.com ではデフォルトで有効）</li></ul><p>脆弱性は脆弱性レポートの <strong>コンテナレジストリの脆弱性</strong> タブに表示されます。</p><h3 id="_3-マルチコンテナスキャン">3. マルチコンテナスキャン</h3><ul><li>機能：単一のパイプライン内で複数のコンテナイメージを並行してスキャンします。</li><li>最適な用途：マイクロサービスアーキテクチャや複数のコンテナイメージを持つプロジェクト</li><li>利用可能なプラン：Free、Premium、Ultimate（現在ベータ版）</li><li><a href="https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/multi_container_scanning/" rel="">ドキュメント</a></li></ul><p>マルチコンテナスキャンは動的な子パイプラインを使用してスキャンを並行実行するため、複数のイメージをスキャンする際のパイプライン全体の実行時間を大幅に短縮できます。</p><h4 id="マルチコンテナスキャンを有効にする方法">マルチコンテナスキャンを有効にする方法</h4><ol><li>リポジトリのルートに <code className="">.gitlab-multi-image.yml</code> ファイルを作成します。</li></ol><pre className="language-yaml shiki shiki-themes github-light" code="scanTargets:
  - name: alpine
    tag: &quot;3.19&quot;
  - name: python
    tag: &quot;3.9-slim&quot;
  - name: nginx
    tag: &quot;1.25&quot;
" language="yaml" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#22863A">scanTargets</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="2"><span style="--shiki-default:#24292E">  - </span><span style="--shiki-default:#22863A">name</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">alpine
</span></span><span class="line" line="3"><span style="--shiki-default:#22863A">    tag</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">&quot;3.19&quot;
</span></span><span class="line" line="4"><span style="--shiki-default:#24292E">  - </span><span style="--shiki-default:#22863A">name</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">python
</span></span><span class="line" line="5"><span style="--shiki-default:#22863A">    tag</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">&quot;3.9-slim&quot;
</span></span><span class="line" line="6"><span style="--shiki-default:#24292E">  - </span><span style="--shiki-default:#22863A">name</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">nginx
</span></span><span class="line" line="7"><span style="--shiki-default:#22863A">    tag</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">&quot;1.25&quot;
</span></span></code></pre><ol start="2"><li><code className="">.gitlab-ci.yml</code> にテンプレートを追加します。</li></ol><pre className="language-yaml shiki shiki-themes github-light" code="include:
  - template: Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml
" language="yaml" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#22863A">include</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="2"><span style="--shiki-default:#24292E">  - </span><span style="--shiki-default:#22863A">template</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">Jobs/Multi-Container-Scanning.latest.gitlab-ci.yml
</span></span></code></pre><h4 id="詳細設定">詳細設定</h4><p><strong>プライベートレジストリからイメージをスキャンする：</strong></p><pre className="language-yaml shiki shiki-themes github-light" code="auths:
  registry.gitlab.com:
    username: ${CI_REGISTRY_USER}
    password: ${CI_REGISTRY_PASSWORD}

scanTargets:
  - name: registry.gitlab.com/private/image
    tag: latest
" language="yaml" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#22863A">auths</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="2"><span style="--shiki-default:#22863A">  registry.gitlab.com</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="3"><span style="--shiki-default:#22863A">    username</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">${CI_REGISTRY_USER}
</span></span><span class="line" line="4"><span style="--shiki-default:#22863A">    password</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">${CI_REGISTRY_PASSWORD}
</span></span><span class="line" line="5"><span emptyLinePlaceholder>
</span></span><span class="line" line="6"><span style="--shiki-default:#22863A">scanTargets</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="7"><span style="--shiki-default:#24292E">  - </span><span style="--shiki-default:#22863A">name</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">registry.gitlab.com/private/image
</span></span><span class="line" line="8"><span style="--shiki-default:#22863A">    tag</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">latest
</span></span></code></pre><p><strong>ライセンス情報を含める：</strong></p><pre className="language-yaml shiki shiki-themes github-light" code="includeLicenses: true

scanTargets:
  - name: postgres
    tag: &quot;15-alpine&quot;
" language="yaml" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#22863A">includeLicenses</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#005CC5">true
</span></span><span class="line" line="2"><span emptyLinePlaceholder>
</span></span><span class="line" line="3"><span style="--shiki-default:#22863A">scanTargets</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="4"><span style="--shiki-default:#24292E">  - </span><span style="--shiki-default:#22863A">name</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">postgres
</span></span><span class="line" line="5"><span style="--shiki-default:#22863A">    tag</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">&quot;15-alpine&quot;
</span></span></code></pre><h3 id="_4-継続的脆弱性スキャン">4. 継続的脆弱性スキャン</h3><ul><li>機能：パイプラインを実行することなく、新しいセキュリティアドバイザリーが公開された際に自動的に脆弱性を作成します。</li><li>最適な用途：デプロイ間のプロアクティブなセキュリティモニタリング</li><li>利用可能なプラン：Ultimate のみ</li><li><a href="https://docs.gitlab.com/ja-jp/user/application_security/continuous_vulnerability_scanning/" rel="">ドキュメント</a></li></ul><p>従来のスキャンは、スキャン実行時の脆弱性しか検出できません。しかし、昨日スキャンしたパッケージに対して、明日新しい CVE が公開された場合はどうなるでしょうか。継続的脆弱性スキャンは、GitLab アドバイザリーデータベースを監視し、新しいアドバイザリーがコンポーネントに影響を与える際に自動的に脆弱性レコードを作成することでこの課題を解決します。</p><h4 id="仕組み">仕組み</h4><ol><li>コンテナスキャンまたは依存関係スキャンジョブが CycloneDX SBOM を生成します。</li><li>GitLab はこの SBOM からプロジェクトのコンポーネントを登録します。</li><li>新しいアドバイザリーが公開されると、GitLab はコンポーネントが影響を受けるかどうかを確認します。</li><li>脆弱性レポートに脆弱性が自動的に作成されます。</li></ol><h4 id="重要な考慮事項">重要な考慮事項</h4><ul><li>スキャンは CI パイプラインではなく、バックグラウンドジョブ（Sidekiq）経由で実行されます。</li><li>新しいコンポーネント検出には、過去14日以内に公開されたアドバイザリーのみが対象となります。</li><li>脆弱性では「GitLab SBoM Vulnerability Scanner」がスキャナー名として使用されます。</li><li>脆弱性を解決済みとしてマークするには、引き続きパイプラインベースのスキャンを実行する必要があります。</li></ul><h3 id="_5-運用コンテナスキャン">5. 運用コンテナスキャン</h3><ul><li>機能：スケジュールされた間隔で Kubernetes クラスター内の稼働中のコンテナをスキャンします。</li><li>最適な用途：デプロイ後のセキュリティモニタリングとランタイム脆弱性の検出</li><li>利用可能なプラン：Ultimate のみ</li><li><a href="https://docs.gitlab.com/ja-jp/user/clusters/agent/vulnerabilities/" rel="">ドキュメント</a></li></ul><p>運用コンテナスキャンは、ビルド時のセキュリティとランタイムセキュリティの間のギャップを埋めます。GitLab Agent for Kubernetes を使用して、クラスター内で実際に稼働しているコンテナをスキャンし、デプロイ後に発生する脆弱性を検出します。</p><h4 id="運用コンテナスキャンを有効にする方法">運用コンテナスキャンを有効にする方法</h4><p><a href="https://docs.gitlab.com/ja-jp/user/clusters/agent/install/" rel="">GitLab Kubernetes Agent</a> を使用している場合、エージェント設定ファイルに以下を追加できます。</p><pre className="language-yaml shiki shiki-themes github-light" code="container_scanning:
  cadence: &#39;0 0 * * *&#39;  # 毎日深夜0時
  vulnerability_report:
    namespaces:
      include:
        - production
        - staging
" language="yaml" meta="" style=""><code><span class="line" line="1"><span style="--shiki-default:#22863A">container_scanning</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="2"><span style="--shiki-default:#22863A">  cadence</span><span style="--shiki-default:#24292E">: </span><span style="--shiki-default:#032F62">&#39;0 0 * * *&#39;</span><span style="--shiki-default:#6A737D">  # 毎日深夜0時
</span></span><span class="line" line="3"><span style="--shiki-default:#22863A">  vulnerability_report</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="4"><span style="--shiki-default:#22863A">    namespaces</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="5"><span style="--shiki-default:#22863A">      include</span><span style="--shiki-default:#24292E">:
</span></span><span class="line" line="6"><span style="--shiki-default:#24292E">        - </span><span style="--shiki-default:#032F62">production
</span></span><span class="line" line="7"><span style="--shiki-default:#24292E">        - </span><span style="--shiki-default:#032F62">staging
</span></span></code></pre><p>また、GitLab Kubernetes Agent によるスケジュールスキャンを強制する<a href="https://docs.gitlab.com/ja-jp/user/clusters/agent/vulnerabilities/#enable-via-scan-execution-policies" rel="">スキャン実行ポリシー</a>を作成することもできます。</p><p><img alt="スキャン実行ポリシー - 運用コンテナスキャン" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547515/gsgvjcq4sas4dfc8ciqk.png" title="運用コンテナスキャンのスキャン実行ポリシー条件" /></p><h4 id="結果の確認">結果の確認</h4><ul><li><strong>運用 &gt; Kubernetes クラスター</strong> に移動します。</li><li><strong>エージェント</strong> タブを選択し、エージェントを選択します。</li><li><strong>セキュリティ</strong> タブを選択してクラスターの脆弱性を確認します。</li><li>結果は <strong>脆弱性レポート</strong> の <strong>運用上の脆弱性</strong> タブにも表示されます。</li></ul><h2 id="gitlab-セキュリティポリシーによるセキュリティ態勢の強化">GitLab セキュリティポリシーによるセキュリティ態勢の強化</h2><p>GitLab セキュリティポリシーを使用すると、自動化されたポリシー駆動型のコントロールを通じて、コンテナワークフロー全体で一貫したセキュリティ標準を適用できます。これらのポリシーは、要件を開発パイプラインに直接組み込むことでセキュリティをシフトレフトし、コードが本番環境に到達する前に脆弱性を検出・対処できるようにします。</p><h4 id="スキャン実行ポリシーとパイプラインポリシー">スキャン実行ポリシーとパイプラインポリシー</h4><p><a href="https://docs.gitlab.com/ja-jp/user/application_security/policies/scan_execution_policies/" rel="">スキャン実行ポリシー</a>は、プロジェクト全体でコンテナスキャンがいつ・どのように実行されるかを自動化します。すべてのマージリクエストでコンテナスキャンをトリガーし、メインブランチの定期的なスキャンをスケジュールするポリシーなどを定義できます。これらのポリシーにより、各プロジェクトの CI/CD パイプラインで手動でスキャンを設定することなく、包括的なカバレッジが確保されます。</p><p>使用するスキャナーのバージョンを指定し、スキャンパラメーターを一元的に設定することで、新しいコンテナセキュリティの脅威に対応しながら組織全体の一貫性を維持できます。</p><p><img alt="スキャン実行ポリシーの設定" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/z36dntxslqem9udrynvx.png" title="スキャン実行ポリシーの設定" /></p><p><a href="https://docs.gitlab.com/ja-jp/user/application_security/policies/pipeline_execution_policies/" rel="">パイプライン実行ポリシー</a>は、コンプライアンス要件に基づいてパイプラインにカスタムジョブを注入（または上書き）するための柔軟なコントロールを提供します。</p><p>これらのポリシーを使用して、コンテナスキャンジョブをパイプラインに自動的に注入したり、コンテナの脆弱性がリスク許容度を超えた場合にビルドを失敗させたり、特定のブランチやタグに対して追加のセキュリティチェックをトリガーしたり、本番環境向けコンテナイメージのコンプライアンス要件を適用したりすることができます。パイプライン実行ポリシーは自動化されたガードレールとして機能し、手動操作なしですべてのコンテナデプロイメントにセキュリティ標準が一貫して適用されるようにします。</p><p><img alt="パイプライン実行ポリシー" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547517/ddhhugzcr2swptgodof2.png" title="パイプライン実行ポリシーのアクション" /></p><h4 id="マージリクエスト承認ポリシー">マージリクエスト承認ポリシー</h4><p><a href="https://docs.gitlab.com/ja-jp/user/application_security/policies/merge_request_approval_policies/" rel="">マージリクエスト承認ポリシー</a>は、コンテナの脆弱性を含むマージリクエストを指定された承認者がレビューし、承認することを要求することでセキュリティゲートを適用します。</p><p>重大度の高い脆弱性が検出された場合にマージをブロックするポリシーや、新しいコンテナの検出結果を導入するマージリクエストにセキュリティチームの承認を要求するポリシーを設定できます。これらのポリシーにより、低リスクな変更の開発速度を維持しながら、脆弱性のあるコンテナイメージがパイプラインを通じて進むことを防ぎます。</p><p><img alt="MRでブロックを実行するマージリクエスト承認ポリシー" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772547513/hgnbc1vl4ssqafqcyuzg.png" title="MRでブロックを実行するマージリクエスト承認ポリシー" /></p><h2 id="適切なアプローチの選択">適切なアプローチの選択</h2><table><thead><tr><th>スキャンの種類</th><th>使用するタイミング</th><th>主なメリット</th></tr></thead><tbody><tr><td>パイプラインベース</td><td>すべてのビルド時</td><td>シフトレフトセキュリティ、脆弱なビルドをブロック</td></tr><tr><td>レジストリスキャン</td><td>継続的なモニタリング</td><td>保存されたイメージの新しい CVE を検出</td></tr><tr><td>マルチコンテナ</td><td>マイクロサービス</td><td>並行スキャン、パイプラインの高速化</td></tr><tr><td>継続的脆弱性</td><td>デプロイ間</td><td>プロアクティブなアドバイザリーモニタリング</td></tr><tr><td>運用</td><td>本番環境のモニタリング</td><td>ランタイム脆弱性の検出</td></tr></tbody></table><p>包括的なセキュリティのためには、複数のアプローチを組み合わせることをお勧めします。開発中の問題を検出するためのパイプラインベースのスキャン、継続的なモニタリングのためのレジストリ向けコンテナスキャン、そして本番環境の可視性のための運用スキャンを組み合わせてご活用ください。</p><h2 id="今すぐ始める">今すぐ始める</h2><p>コンテナセキュリティへの最短ルートは、パイプラインベースのスキャンを有効にすることです。</p><ol><li>プロジェクトの <strong>Secure &gt; セキュリティ設定</strong> に移動します。</li><li>コンテナスキャンの <strong>マージリクエストで設定</strong> をクリックします。</li><li>作成されたマージリクエストをマージします。</li><li>次のパイプラインに脆弱性スキャンが含まれるようになります。</li></ol><p>その後、セキュリティ要件と GitLab のプランに応じて、追加のスキャンの種類を段階的に導入してください。</p><p>コンテナセキュリティは一度実施すれば完了するものではなく、継続的なプロセスです。
GitLab の包括的なコンテナスキャン機能を活用することで、ビルドからランタイムまでコンテナライフサイクルのあらゆる段階で脆弱性を検出できます。</p><blockquote><p>GitLab がセキュリティ態勢の強化にどのように役立つかについての詳細は、<a href="https://about.gitlab.com/solutions/application-security-testing/" rel="">GitLab セキュリティ &amp; ガバナンス ソリューションページ</a>をご覧ください。</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>Fernando Diaz</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/fernando-diaz/</uri>
        </author>
        <published>2026-03-05T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[チームのソフトウェア提供を加速する10のAIプロンプト]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/10-ai-prompts-to-speed-your-teams-software-delivery/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/10-ai-prompts-to-speed-your-teams-software-delivery/"/>
        <updated>2026-03-04T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>AIを活用したコーディングツールにより、開発者はこれまで以上に速くコードを生成できるようになりました。では、なぜチーム全体の <em>リリース速度</em> は上がらないのでしょうか？</p><p>それは、コーディングがソフトウェア提供ライフサイクルの20%に過ぎず、残りの80%がボトルネックになっているからです。コードレビューの滞留、セキュリティスキャンの遅れ、ドキュメントの陳腐化、手動の調整作業の増加が、チームの速度を妨げています。</p><p>嬉しいことに、個人のコーディングを加速する同じAI機能を使って、チームレベルの遅延も解消できます。コーディングフェーズだけでなく、ソフトウェアライフサイクル全体にAIを適用することが重要です。</p><p>以下は、<a href="https://about.gitlab.com/gitlab-duo/prompt-library/" rel="">GitLab Duo Agent Platformプロンプトライブラリ</a>から厳選した、すぐに使える10のプロンプトです。個人の生産性が向上する一方でチームプロセスの改善が追いついていないときに生じる、よくある障害を乗り越えるために役立ちます。</p><h2 id="コードレビューをボトルネックから加速装置へ">コードレビューをボトルネックから加速装置へ</h2><p>AIの支援により開発者はマージリクエストをより速く作成できるようになりましたが、コードレビューのサイクルが数時間から数日に伸びるにつれ、人間のレビュアーはすぐに手に負えなくなります。AIは定型的なレビュー作業を担うことで、レビュアーが基本的な論理エラーやAPI契約違反の発見に時間を取られることなく、アーキテクチャやビジネスロジックに集中できるようにします。</p><h3 id="マージリクエストの論理エラーをレビューする">マージリクエストの論理エラーをレビューする</h3><p><strong>複雑さ</strong>: 初級</p><p><strong>カテゴリ</strong>: コードレビュー</p><p><strong>ライブラリのプロンプト</strong>:</p><pre className="language-text" code="このMRの論理エラー、エッジケース、潜在的なバグをレビューしてください: [MRのURLまたはコードを貼り付け]
" language="text" meta=""><code>このMRの論理エラー、エッジケース、潜在的なバグをレビューしてください: [MRのURLまたはコードを貼り付け]
</code></pre><p><strong>効果</strong>: 自動リンターは構文エラーを検出しますが、論理エラーの発見にはコードの意図を理解する必要があります。このプロンプトは、人間のレビュアーがコードを確認する前にバグを検出し、複数回のレビューサイクルを多くの場合1回の承認で完結させます。</p><h3 id="マージリクエストの破壊的変更を特定する">マージリクエストの破壊的変更を特定する</h3><p><strong>複雑さ</strong>: 初級</p><p><strong>カテゴリ</strong>: コードレビュー</p><p><strong>ライブラリのプロンプト</strong>:</p><pre className="language-text" code="このMRに破壊的変更はありますか？

Changes:
[code diffを貼り付け]

以下を確認してください：
1. APIシグネチャの変更
2. publicメソッドの削除またはリネーム
3. 戻り値の型の変更
4. データベーススキーマの変更
5. 設定の破壊的変更
" language="text" meta=""><code>このMRに破壊的変更はありますか？

Changes:
[code diffを貼り付け]

以下を確認してください：
1. APIシグネチャの変更
2. publicメソッドの削除またはリネーム
3. 戻り値の型の変更
4. データベーススキーマの変更
5. 設定の破壊的変更
</code></pre><p><strong>効果</strong>: デプロイ中に破壊的変更が発見されると、ロールバックやインシデントにつながります。このプロンプトにより、その発見をマージリクエストの段階に前倒しできるため、修正がより迅速かつ低コストになります。</p><h2 id="セキュリティをシフトレフトしながら速度を落とさないには">セキュリティをシフトレフトしながら速度を落とさないには？</h2><p>セキュリティスキャンは数百件もの検出結果を生成します。開発者がデプロイの承認を待つ間、セキュリティチームはそれぞれを手動でトリアージしています。検出結果の多くはフォルスポジティブや低リスクの問題ですが、実際の脅威を特定するには専門知識と時間が必要です。AIは実際の悪用可能性に基づいて検出結果を優先順位付けし、一般的な脆弱性を自動修復することで、セキュリティチームが本当に重要な脅威に集中できるようにします。</p><h3 id="セキュリティスキャン結果を分析する">セキュリティスキャン結果を分析する</h3><p><strong>複雑さ</strong>: 中級</p><p><strong>カテゴリ</strong>: セキュリティ</p><p><strong>エージェント</strong>: Duo Security Analyst</p><p><strong>ライブラリのプロンプト</strong>:</p><pre className="language-text" code="@security_analyst このセキュリティスキャン結果を分析してください:

[スキャン結果を貼り付け]

各検出結果について:
1. 実際のリスクかフォルスポジティブかを評価する
2. 脆弱性を説明する
3. 修復方法を提案する
4. 深刻度で優先順位をつける
" language="text" meta=""><code>@security_analyst このセキュリティスキャン結果を分析してください:

[スキャン結果を貼り付け]

各検出結果について:
1. 実際のリスクかフォルスポジティブかを評価する
2. 脆弱性を説明する
3. 修復方法を提案する
4. 深刻度で優先順位をつける
</code></pre><p><strong>効果</strong>: セキュリティスキャンの検出結果の多くはフォルスポジティブや低リスクの問題です。このプロンプトはセキュリティチームが本当に重要な検出結果に集中できるようにし、修復にかかる時間を数週間から数日に短縮します。</p><h3 id="コードのセキュリティ問題をレビューする">コードのセキュリティ問題をレビューする</h3><p><strong>複雑さ</strong>: 中級</p><p><strong>カテゴリ</strong>: セキュリティ</p><p><strong>エージェント</strong>: Duo Security Analyst</p><p><strong>ライブラリのプロンプト</strong>:</p><pre className="language-text" code="@security_analyst このコードのセキュリティ問題をレビューしてください:

[コードを貼り付け]

以下を確認してください：
1. インジェクション脆弱性
2. 認証・認可の欠陥
3. データ漏洩リスク
4. 安全でない依存関係
5. 暗号化の問題
" language="text" meta=""><code>@security_analyst このコードのセキュリティ問題をレビューしてください:

[コードを貼り付け]

以下を確認してください：
1. インジェクション脆弱性
2. 認証・認可の欠陥
3. データ漏洩リスク
4. 安全でない依存関係
5. 暗号化の問題
</code></pre><p><strong>効果</strong>: 従来のセキュリティレビューはコードが書かれた後に行われます。このプロンプトにより、開発者はマージリクエストを作成する前にセキュリティ問題を発見・修正でき、デプロイを遅らせる往復のやり取りを解消します。</p><h2 id="コードの変更に合わせてドキュメントを最新に保つには">コードの変更に合わせてドキュメントを最新に保つには？</h2><p>コードはドキュメントよりも速く変化します。ドキュメントが古かったり不足していたりするため、新しい開発者のオンボーディングには数週間かかります。ドキュメントの重要性はチーム全員が理解していますが、締め切りが近づくと常に後回しになります。標準ワークフローの一部としてドキュメントの生成と更新を自動化することで、手動作業を増やすことなくドキュメントを最新の状態に保てます。</p><h3 id="マージリクエストからリリースノートを生成する">マージリクエストからリリースノートを生成する</h3><p><strong>複雑さ</strong>: 初級</p><p><strong>カテゴリ</strong>: ドキュメント</p><p><strong>ライブラリのプロンプト</strong>:</p><pre className="language-text" code="マージ済みのこれらのMRのリリースノートを生成してください:
[MRのURL一覧またはタイトルを貼り付け]

以下のカテゴリでグループ化してください:
1. 新機能
2. バグ修正
3. パフォーマンス改善
4. 破壊的変更
5. 非推奨事項
" language="text" meta=""><code>マージ済みのこれらのMRのリリースノートを生成してください:
[MRのURL一覧またはタイトルを貼り付け]

以下のカテゴリでグループ化してください:
1. 新機能
2. バグ修正
3. パフォーマンス改善
4. 破壊的変更
5. 非推奨事項
</code></pre><p><strong>効果</strong>: リリースノートを手動でまとめるには数時間かかり、誤りや漏れが生じることもあります。自動生成により、リリースプロセスに負担をかけることなく、すべてのリリースに包括的なノートが揃います。</p><h3 id="コード変更後にドキュメントを更新する">コード変更後にドキュメントを更新する</h3><p><strong>複雑さ</strong>: 初級</p><p><strong>カテゴリ</strong>: ドキュメント</p><p><strong>ライブラリのプロンプト</strong>:</p><pre className="language-text" code="このコードを変更しました:

[コード変更内容を貼り付け]

どのドキュメントを更新する必要がありますか？以下を確認してください:
1. READMEファイル
2. APIドキュメント
3. アーキテクチャ図
4. オンボーディングガイド
" language="text" meta=""><code>このコードを変更しました:

[コード変更内容を貼り付け]

どのドキュメントを更新する必要がありますか？以下を確認してください:
1. READMEファイル
2. APIドキュメント
3. アーキテクチャ図
4. オンボーディングガイド
</code></pre><p><strong>効果</strong>: ドキュメントの乖離は、コード変更後にどのドキュメントを更新すべきかをチームが忘れることで起きます。このプロンプトにより、ドキュメントのメンテナンスが後回しにされる別タスクではなく、開発ワークフローの一部になります。</p><h2 id="計画の複雑さを分解するには">計画の複雑さを分解するには？</h2><p>大規模な機能は計画段階で行き詰まりがちです。チームは作業範囲の定義と依存関係の特定のために何週間も会議を重ねます。複雑さに圧倒され、どこから始めればよいかわからなくなります。AIは複雑な作業を具体的で実装可能なタスクに体系的に分解し、明確な依存関係と受け入れ基準を設定することで、何週間もの計画を集中した実装へと変えます。</p><h3 id="エピックをイシューに分解する">エピックをイシューに分解する</h3><p><strong>複雑さ</strong>: 中級</p><p><strong>カテゴリ</strong>: ドキュメント</p><p><strong>エージェント</strong>: Duo Planner</p><p><strong>ライブラリのプロンプト</strong>:</p><pre className="language-text" code="このエピックを実装可能なイシューに分解してください：

[エピックの説明]

以下を考慮してください：
1. 技術的な依存関係
2. 適切なイシューのサイズ
3. 明確な受け入れ基準
4. 論理的な実装順序
" language="text" meta=""><code>このエピックを実装可能なイシューに分解してください：

[エピックの説明]

以下を考慮してください：
1. 技術的な依存関係
2. 適切なイシューのサイズ
3. 明確な受け入れ基準
4. 論理的な実装順序
</code></pre><p><strong>効果</strong>: このプロンプトにより、1週間分の計画会議が30分のAI支援による分解とチームレビューに変わります。チームはより明確な方向性を持って、より早く実装を開始できます。</p><h2 id="工数を増やさずにテストカバレッジを拡大するには">工数を増やさずにテストカバレッジを拡大するには？</h2><p>開発者はコードをより速く書けるようになりましたが、テストが追いつかないとカバレッジが低下してバグが見逃されます。包括的なテストを手動で書くには時間がかかり、締め切りのプレッシャーの下でエッジケースを見落とすことも多くあります。テストを自動生成することで、開発者はゼロから書く代わりにレビューと改善に集中でき、速度を犠牲にすることなく品質を維持できます。</p><h3 id="ユニットテストを生成する">ユニットテストを生成する</h3><p><strong>複雑さ</strong>: 初級</p><p><strong>カテゴリ</strong>: テスト</p><p><strong>ライブラリのプロンプト</strong>:</p><pre className="language-text" code="この関数のユニットテストを生成してください：

[関数を貼り付け]

以下のテストを含めてください：
1. 正常系
2. エッジケース
3. エラー条件
4. 境界値
5. 不正な入力
" language="text" meta=""><code>この関数のユニットテストを生成してください：

[関数を貼り付け]

以下のテストを含めてください：
1. 正常系
2. エッジケース
3. エラー条件
4. 境界値
5. 不正な入力
</code></pre><p><strong>効果</strong>: テストを手動で書くには時間がかかり、エッジケースが見落とされることもあります。このプロンプトは数秒で網羅的なテストスイートを生成し、開発者はゼロから書く代わりにレビューと調整に集中できます。</p><h3 id="テストカバレッジのギャップをレビューする">テストカバレッジのギャップをレビューする</h3><p><strong>複雑さ</strong>: 初級</p><p><strong>カテゴリ</strong>: テスト</p><p><strong>ライブラリのプロンプト</strong>:</p><pre className="language-text" code="[モジュール/コンポーネント]のテストカバレッジを分析してください：

現在のカバレッジ：[パーセンテージ]

以下を特定してください：
1. テストされていない関数・メソッド
2. カバーされていないエッジケース
3. 不足しているエラーシナリオのテスト
4. テストのない統合ポイント
5. 次にテストすべき優先領域
" language="text" meta=""><code>[モジュール/コンポーネント]のテストカバレッジを分析してください：

現在のカバレッジ：[パーセンテージ]

以下を特定してください：
1. テストされていない関数・メソッド
2. カバーされていないエッジケース
3. 不足しているエラーシナリオのテスト
4. テストのない統合ポイント
5. 次にテストすべき優先領域
</code></pre><p><strong>効果</strong>: このプロンプトは、本番インシデントを引き起こす前にテストスイートのブラインドスポットを明らかにします。チームはより重要な箇所から体系的にカバレッジを改善できます。</p><h2 id="デバッグ時の平均解決時間を短縮するには">デバッグ時の平均解決時間を短縮するには？</h2><p>本番インシデントの診断には数時間かかります。顧客がダウンタイムを経験する中、開発者はログやスタックトレースを調べ続けます。デバッグの1分1分が、生産性と潜在的な収益の損失につながります。AIは複雑なエラーメッセージを解析して具体的な修正案を提示することで根本原因分析を加速し、診断時間を数時間から数分に短縮します。</p><h3 id="失敗したパイプラインをデバッグする">失敗したパイプラインをデバッグする</h3><p><strong>複雑さ</strong>: 初級</p><p><strong>カテゴリ</strong>: デバッグ</p><p><strong>ライブラリのプロンプト</strong>:</p><pre className="language-text" code="このパイプラインが失敗しています：

ジョブ：[ジョブ名]
ステージ：[ステージ]
エラー：[エラーメッセージ/ログを貼り付け]


以下を助けてください:
1. 根本原因を特定する
2. 修正方法を提案する
3. なぜ失敗し始めたかを説明する
4. 同様の問題を防ぐ
" language="text" meta=""><code>このパイプラインが失敗しています：

ジョブ：[ジョブ名]
ステージ：[ステージ]
エラー：[エラーメッセージ/ログを貼り付け]


以下を助けてください:
1. 根本原因を特定する
2. 修正方法を提案する
3. なぜ失敗し始めたかを説明する
4. 同様の問題を防ぐ
</code></pre><p><strong>効果</strong>: CI/CDの失敗はチーム全体をブロックします。このプロンプトは、開発者が通常15〜30分かけて調査する問題を数秒で診断し、デプロイの速度を維持します。</p><h2 id="個人の成果からチームの加速へ">個人の成果からチームの加速へ</h2><p>これらのプロンプトは、チームがソフトウェア提供にAIを活用する方法の転換を示しています。個人の開発者生産性だけに注目するのではなく、チームの速度を実際に制約している調整・品質・ナレッジ共有の課題に対処します。</p><p><a href="https://about.gitlab.com/gitlab-duo/prompt-library/" rel="">プロンプトライブラリ</a>には、計画、開発、セキュリティ、テスト、デプロイ、運用といったソフトウェアライフサイクルの全ステージにわたる100以上のプロンプトが収録されています。各プロンプトは複雑さのレベル（初級・中級・上級）でタグ付けされ、ユースケース別に分類されているため、チームに合ったスタート地点を簡単に見つけられます。</p><p>まずはチームの最も緊急な課題に対応する「初級」タグのプロンプトから始めましょう。チームが自信をつけるにつれ、より高度なワークフローを実現する中級・上級のプロンプトへと探求の幅を広げてください。目標は単に速いコーディングではなく、計画から本番まで、より速く、より安全で、より高品質なソフトウェア提供の実現です。</p>]]></content>
        <author>
            <name>Chandler Gibbons</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/chandler-gibbons/</uri>
        </author>
        <published>2026-03-04T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[AIは脆弱性を検出できるが、リスクの責任は誰がとる？]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/ai-can-detect-vulnerabilities-but-who-governs-risk/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/ai-can-detect-vulnerabilities-but-who-governs-risk/"/>
        <updated>2026-02-27T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>Anthropic社は先ごろ、脆弱性の検出と修正案の提示を行うAIシステム「Claude Code Security」を発表しました。投資家がAIによる従来のAppSecツールの代替可能性に疑問を持ち始めたことで市場はすぐに反応し、セキュリティ関連銘柄が下落しました。多くの人の頭には同じ問いが浮かびました。AIがコードを記述してセキュリティを担保できるなら、アプリケーションセキュリティは時代遅れになるのか、という問いです。</p><p>セキュリティがコードのスキャンのみを意味するなら、答えはイエスかもしれません。しかし、エンタープライズセキュリティは検出だけできればよいというものではありません。</p><p>組織の問いは、AIが脆弱性を発見できるかどうかではありません。それよりもはるかに難しい3つの問題です。</p><ul><li>リリースしようとしているソフトウェアは安全か</li><li>環境が変化し、依存関係、サードパーティサービス、ツール、インフラが絶えず移り変わる中で、リスク体制は変化したか</li><li>AIやサードパーティのソースによって作成される割合が増えたにもかかわらず、依然として自社が責任を負うコードベースをどのようにガバナンスするか</li></ul><p>これらの問いにはプラットフォームとしての答えが必要です。検出はリスクを可視化しますが、次に何をすべきかを決めるのはガバナンスです。</p><p><a href="https://about.gitlab.com/ja-jp/" rel="">GitLab</a>は、ソフトウェアライフサイクルをエンドツーエンドでガバナンスするために構築されたオーケストレーションレイヤーです。チームがAIを活用した開発スピードに対応するために必要な、ポリシー適用、可視性、監査証跡を実現します。</p><h2 id="aiを信頼するにはリスクのガバナンスが必要">AIを信頼するにはリスクのガバナンスが必要</h2><p>AIシステムは脆弱性の特定と修正提案の能力を急速に向上させています。これは重要かつ歓迎すべき進歩ですが、分析は説明責任とは異なります。</p><p>AIが独自の裁量で会社のポリシーを適用したり、許容リスクを定義したりすることはできません。エージェントが運用される境界、ポリシー、ガードレールを設定するのは人間です。職務の分離を確立し、監査証跡を確保し、何千ものリポジトリとチーム全体で一貫したコントロールを維持するのも人間の役割です。エージェントへの信頼は自律性だけから生まれるのではなく、人間が設定した明確に定義されたガバナンスから生まれます。</p><p>ソフトウェアにおいて、エージェント型AIシステムによる記述・変更がますます増える<a href="https://about.gitlab.com/ja-jp/topics/agentic-ai/" rel="">エージェント型AIの世界</a>では、ガバナンスの重要性は低下するどころか、むしろ高まります。組織がAIに与える自律性が高まれば高まるほど、ガバナンスはより強固でなければなりません。</p><p>ガバナンスは不要な手間ではありません。AIを活用した開発を大規模に信頼できるものにするために必要な基盤です。</p><h2 id="llmはコードを見るがプラットフォームはコンテキストを見る">LLMはコードを見るが、プラットフォームはコンテキストを見る</h2><p>大規模言語モデル（<a href="https://about.gitlab.com/blog/what-is-a-large-language-model-llm/" rel="">LLM</a>）はコードを単体で評価します。一方、エンタープライズのアプリケーションセキュリティプラットフォームはコンテキストを理解します。リスクの判断は次のようなコンテキストに依存するため、この違いは重要です。</p><ul><li>変更を加えたのは誰か</li><li>そのアプリケーションはビジネスにとってどれほど重要か</li><li>インフラや依存関係とどのように連携しているか</li><li>その脆弱性は本番環境で実際に到達可能なコードに存在するのか、それとも一度も実行されない依存関係に埋もれているのか</li><li>アプリケーションの実行方法、API、その周辺環境を踏まえると、本番環境で実際に悪用可能か</li></ul><p>セキュリティの判断はこうしたコンテキストに基づいて行います。コンテキストがなければ、検出はノイズの多いアラートを生み出し、リスクを低減するどころか開発を遅延させます。コンテキストがあれば、組織はトリアージを迅速に行い、リスクを効果的に管理できます。ソフトウェアが変化し続ける中でコンテキストも絶えず変化するため、ガバナンスは一度きりの判断では済みません。</p><h2 id="静的スキャンは動的リスクに追いつかない">静的スキャンは動的リスクに追いつかない</h2><p>ソフトウェアのリスクは動的です。依存関係は変わり、環境は変化し、システムはいかなる分析でも完全には予測できない方法で相互作用します。特定時点でのクリーンスキャンでは、リリース時の安全性を保証できません。</p><p>エンタープライズセキュリティが依拠するのは継続的な保証です。ソフトウェアのビルド、テスト、デプロイの過程でリスクを評価する、開発ワークフローに直接組み込まれたコントロールが必要です。</p><p>検出により洞察が得られます。ガバナンスにより信頼が生まれます。そして、組織の大規模かつ安全なリリースを実現するのが、継続的なガバナンスです。</p><h2 id="エージェント型aiの未来をガバナンスする">エージェント型AIの未来をガバナンスする</h2><p>AIはソフトウェアの作り方を根本から変えつつあります。問われるのはもはや、チームがAIを活用するかどうかではなく、いかに安全にスケールさせるかという点です。</p><p>今日のソフトウェアは新規に記述されるのと同じくらい再形成されています。AIが生成したコード、オープンソースライブラリ、何千ものプロジェクトにまたがるサードパーティの依存関係から集められ再構成されているのです。それらすべてのソースにわたってリリースするソフトウェアをガバナンスすることは、アプリケーションセキュリティの中で最も困難かつ重大な部分であり、いかなるデベロッパー向けツールにも対処できない問題です。</p><p>インテリジェントなオーケストレーションプラットフォームとして、GitLabはこの問題に対処するために構築されています。GitLab Ultimateは、ソフトウェアの計画、ビルド、リリースが行われるワークフローに、ガバナンス、ポリシー適用、セキュリティスキャン、監査証跡を直接組み込んでいます。これにより、セキュリティチームはAIのスピードに合わせてガバナンスを実現できます。</p><p>AIは開発を劇的に加速させるでしょう。そして、AIから最大の恩恵を受けられるのは、最も優秀なアシスタントを持つ組織ではなく、強固なガバナンスを通じて信頼を構築できる組織です。</p><blockquote><p>GitLabが組織による<a href="https://about.gitlab.com/ja-jp/solutions/software-compliance/?utm_medium=blog&amp;utm_campaign=eg_global_x_x_security_en_" rel="">AI生成のコードのガバナンスと安全なリリース</a>をどのように支援しているかについては、<a href="https://about.gitlab.com/ja-jp/sales/?utm_medium=blog&amp;utm_campaign=eg_global_x_x_security_en_" rel="">今すぐGitLabにお問い合わせください</a></p></blockquote><h2 id="関連記事">関連記事</h2><ul><li><a href="https://about.gitlab.com/ja-jp/topics/devops/ai-enhanced-security/" rel="">AIとDevOpsを統合してセキュリティを強化</a></li><li><a href="https://about.gitlab.com/blog/the-gitlab-ai-security-framework-for-security-leaders/" rel="">セキュリティリーダーのためのGitLab AIセキュリティフレームワーク</a></li><li><a href="https://about.gitlab.com/blog/improve-ai-security-in-gitlab-with-composite-identities/" rel="">コンポジットIDでGitLabのAIセキュリティを強化する</a></li></ul>]]></content>
        <author>
            <name>Omer Azaria</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/omer-azaria/</uri>
        </author>
        <published>2026-02-27T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLabマネージドサービスプロバイダー（MSP）パートナープログラムのご紹介]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/introducing-the-gitlab-managed-service-provider-msp-partner-program/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/introducing-the-gitlab-managed-service-provider-msp-partner-program/"/>
        <updated>2026-02-26T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p><em>このブログは、GitLabプラクティスの構築を検討しているマネージドサービスプロバイダー（MSP）向けに執筆されています。デベロッパーやエンジニアリングリーダーの方にとっては、皆さまのようなチームのスケーリングと迅速な開発を支援するパートナーを強化するプログラムです。</em></p><p>多くの組織は、最新のDevSecOpsプラットフォームが必要であることを認識しています。しかし、ビジネスが求めるスピードでソフトウェアを提供しながら、プラットフォームのデプロイ、管理、継続的な最適化を行うリソースが不足しているケースが少なくありません。これはMSPにとって大きなビジネスチャンスであり、GitLabはそれを支援する専用プログラムを用意しました。</p><p>このたび、<strong>GitLab MSPパートナープログラム</strong>を発表いたします。これは、認定を受けたMSPがGitLabをフルマネージドサービスとして顧客に提供できるようにする新しいグローバルプログラムです。</p><h2 id="パートナーと顧客にとっての意義">パートナーと顧客にとっての意義</h2><p>GitLabとして初めて、MSP向けに正式に定義されたグローバルプログラムが誕生しました。明確な要件、体系的なイネーブルメント、専任のサポート、そして実質的な経済的メリットが用意されており、パートナーは安心してGitLabマネージドサービスプラクティスの構築に投資できます。</p><p>タイミングも最適です。多くの組織がDevSecOpsへの取り組みを加速させていますが、ソフトウェアの構築とリリースという本来の業務に加えて、複雑な移行、ツールチェーンの拡散、増大するセキュリティ要件への対応に追われているのが現状です。</p><p>GitLab MSPパートナーは、デプロイ、移行、管理、継続的なサポートなど、プラットフォーム運用を担当することで、開発チームが本来の業務に集中できる環境を提供します。</p><h2 id="mspパートナーが得られるメリット">MSPパートナーが得られるメリット</h2><p><strong>経済的メリット</strong>：MSPパートナーは、すべての取引、新規ビジネス、更新において、GitLabパートナーマージンに加えてMSPプレミアムを獲得できます。さらに、デプロイ、移行、トレーニング、イネーブルメント、戦略コンサルティングに対して顧客に請求するサービス料の100%を保持できるため、単一のプラットフォームを中心に複数の継続的な収益源を構築できます。</p><p><strong>イネーブルメントと教育</strong>：バージョンアップデート、新機能、ベストプラクティス、ロードマップの最新情報、ピアシェアリングを網羅した四半期ごとのテクニカルブートキャンプにアクセスできます。推奨されるクラウド認定資格（AWS Solutions Architect Associate、GCP Associate Cloud Engineer）が技術基盤を補完します。</p><p><strong>Go-to-Marketサポート</strong>：MSPには、GitLab認定MSPパートナーバッジ、共同ブランド資産、顧客事例の共同作成への参加資格、Partner Locatorへの掲載、および認定されたデマンドジェネレーション活動向けのMarketing Development Funds（MDF）へのアクセスが提供されます。</p><h2 id="顧客が期待できること">顧客が期待できること</h2><p>GitLab MSPパートナーと連携する顧客は、体系的なマネージドDevSecOpsエクスペリエンス、文書化された再現可能な実装方法論、定期的なビジネスレビュー、そして明確に定義された応答およびエスカレーションパスを備えたサポートを受けられます。</p><p>その結果、開発チームは優れたソフトウェアの構築に集中でき、MSPパートナーがプラットフォームの運用と最適化に注力するという理想的な体制が実現します。</p><h2 id="aiを活用した新たなビジネスチャンス">AIを活用した新たなビジネスチャンス</h2><p>ソフトウェア開発ワークフローにAIを安全に導入したいと考える組織が増えており、経験豊富なチームであっても、大規模な展開には体系的なアプローチが有効です。GitLab MSPパートナーは、より広範なマネージドサービスの一環として、GitLab Duo Agent Platformの導入を顧客に提案できる最適なポジションにあります。</p><p>GitLabのDevSecOpsプラットフォームとMSPが提供する運用の専門知識を組み合わせることで、顧客はガバナンスが確保された環境でAI支援ワークフローを試験的に導入し、データレジデンシーとコンプライアンス要件を満たしながら、社内リソースに過度な負担をかけることなくチーム全体でAI導入を拡大できます。</p><h2 id="このプログラムはお客さまのビジネスに適していますか">このプログラムはお客さまのビジネスに適していますか</h2><p>GitLab MSPパートナープログラムは、以下に該当する場合に最適です。</p><ul><li>クラウド、インフラストラクチャ、またはアプリケーション運用のマネージドサービスを既に提供している</li><li>高付加価値のDevSecOpsをポートフォリオに追加したい</li><li>最新の開発プラットフォームに関心のある技術人材を擁している、または育成したい</li><li>単発の取引よりも長期的な顧客関係を重視している</li></ul><p>既にGitLab SelectおよびProfessional Servicesパートナーである場合、MSPプログラムは既存の専門知識を再現可能なマネージドサービスに転換するための体系的な方法を提供します。</p><h2 id="開始方法">開始方法</h2><p>本プログラムは、<strong>認定MSPパートナー</strong>の指定から開始されます。参加にあたり、最低ARRや顧客数の要件はありません。以下がプログラム参加までの流れです。</p><ol><li><strong>適合性の確認</strong> - <a href="https://handbook.gitlab.com/handbook/resellers/channel-program-guide/#the-gitlab-managed-service-provider-msp-partner-program" rel="">ハンドブックページ</a>に記載されたビジネスおよび技術要件を満たしているか確認します。</li><li><strong>GitLabパートナーポータルから申請</strong> - ビジネスおよび技術に関するドキュメントを添えて申請を提出します。</li><li><strong>90日間のオンボーディングを完了</strong> - 契約、技術イネーブルメント、セールストレーニング、最初の顧客エンゲージメントを網羅した体系的なオンボーディングプログラムです。</li><li><strong>マネージドサービスの提供を開始</strong> - サービスをパッケージ化し、SLAを設定して、顧客へのエンゲージメントを開始します。</li></ol><p>提出された申請は、約3営業日以内に審査されます。</p><blockquote><p>GitLabマネージドサービスプラクティスの構築にご興味がありますか？新規パートナーの方は<a href="https://about.gitlab.com/partners/" rel="">GitLabパートナーへの申請</a>からお申し込みいただけます。既存パートナーの方は、GitLab担当者にお問い合わせいただき、プログラムの詳細やMSPプラクティスを通じて現在顧客に提供しているソリューションについてお知らせください。</p></blockquote>]]></content>
        <author>
            <name>Karishma Kumar</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/karishma-kumar/</uri>
        </author>
        <published>2026-02-26T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLab Duo Agent PlatformとClaudeで開発を加速する]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-with-claude-accelerates-development/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-with-claude-accelerates-development/"/>
        <updated>2026-02-26T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>昨今のソフトウェア開発チームは重要な課題に直面しています。複雑なプロジェクト全体においてコード品質、セキュリティ、一貫性を確保しながら、開発スピードを維持するにはどうすればよいか、という課題です。</p><p>AIコーディングアシスタントは個々のデベロッパーの生産性を向上させましたが、各自の作業はサイロ化しており、開発ワークフロー全体とは切り離されているケースが少なくありません。このような分断により、デベロッパーはツール間でコンテキストを切り替え、AIの提案を手動でコードに反映し、本来であれば自動化できるはずの反復作業に貴重な時間を費やすことを余儀なくされています。</p><p><a href="https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/" rel="">GitLab Duo Agent Platform</a>は、Anthropic社のClaude、OpenAI社のCodexをはじめとする外部AIモデルとのシームレスな統合を実現することで、この問題を解決します。</p><p>GitLab Duo Agent Platform内に外部エージェントを作成することで、組織は使い慣れたGitLab環境を維持しながら、自社のニーズ、ワークフロー、基準に合わせてAI機能をカスタマイズできます。これらのエージェントはプロジェクトのコンテキストを把握し、コーディング基準に従い、最初のアイデアから本番対応コードまで、複雑な複数ステップのタスクを自律的に完了できます。</p><p>では、以下のデモ動画で実際のユースケースを見ていきましょう。</p><figure className="video_container">
  <iframe src="https://www.youtube.com/embed/BPmoVCeyWJA?si=50ktjKxPUNpicXve" frameBorder="0" allowFullScreen="true"> </iframe></figure><h2 id="実際のユースケース">実際のユースケース</h2><p>外部エージェントが開発ライフサイクルをどのように変革するか、3つの活用例をご紹介します。</p><h3 id="_1-アイデアからコードへ">1. アイデアからコードへ</h3><p>空のプロジェクトと詳細なイシューの説明さえ準備すれば、外部エージェント（ここではClaude）がアプリケーション開発のすべてを担ってくれます。このユースケースでは、イシューのタイトルが目的のアプリケーション（「預金額計算ツール」）を示し、イシューの説明にその仕様が記載されています。</p><p>エージェントはコンテキスト（プロジェクト情報、関連アセットなど）を読み取り、イシューに記載された要件を分析した上で、適切なUIコンポーネントを備えたフルスタックのJava Webアプリケーションを生成し、指定された利率でビジネスロジックを実装し、レビュー準備の整ったコードを含むマージリクエストを作成します。</p><p>生成されたアプリケーションには、バックエンドのJavaクラス、フロントエンドのHTML/CSS/JavaScriptファイル、ビルド設定が含まれており、すべて元のイシューの仕様に従っています。チームは、このアプリケーションをローカルでテストして機能を確認します。この作業をエージェントとの自然言語による会話を通じて反復します。</p><p><img alt="アプリケーション要件が記載されたイシュー" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058387/irzlmm0gukanjt7ryq9b.png" title="アプリケーション要件が記載されたイシュー" /></p><p><img alt="アプリケーション実装のマージリクエスト作成を外部エージェントに依頼するプロンプト" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058392/ajr6nquefob7lefdcxng.png" title="アプリケーション実装のマージリクエスト作成を外部エージェントに依頼するプロンプト" /></p><p><img alt="外部エージェントによる実装完了" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058387/gbwwawybg9u4jzibuurw.png" title="外部エージェントによる実装完了" /></p><p><img alt="外部エージェントが新たに作成したアプリケーション" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058387/rijlwchqo1zytp842bld.png" title="外部エージェントが新たに作成したアプリケーション" /></p><p><img alt="アプリケーションのローカルビルドと実行" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058386/aycpfxa0mdbfbxf2ydu3.png" title="アプリケーションのローカルビルドと実行" /></p><p><img alt="アプリケーションのローカルテスト" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058388/rxlvwmzlx8vor92qhotl.png" title="アプリケーションのローカルテスト" /></p><h3 id="_2-コードレビュー">2. コードレビュー</h3><p>品質保証はコード生成で終わりではありません。2つ目のユースケースでは、同じ外部エージェントが自身の作成したアプリケーションの包括的なコードレビューを実施します。マージリクエストのコメントでエージェント宛てにメンションするだけで、コードの強み、重大な問題、中優先度の懸念事項、軽微な改善点、セキュリティ評価、テストに関する注記、コードメトリクス、推奨事項を含む詳細な分析結果が、承認ステータスとともに出力されます。この自動化されたレビュープロセスにより、一貫性が確保され、潜在的な問題を本番環境に到達する前に検出できます。同時に、スキルの高いデベロッパーはルーティン的なコード確認から解放され、アーキテクチャに関する意思決定に集中できるようになります。</p><p><img alt="外部エージェントへのコードレビュー依頼" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058387/ri7x5qkx9bfnidfn8gx1.png" title="外部エージェントへのコードレビュー依頼" /></p><p><img alt="外部エージェントによるコードレビュー結果" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058392/trdamdekrnvkbnfz0twg.png" title="外部エージェントによるコードレビュー結果" /></p><h3 id="_3-コンテナイメージビルド用パイプラインの作成">3. コンテナイメージビルド用パイプラインの作成</h3><p>3つ目のユースケースは、デプロイ自動化というよくあるギャップに対応するものです。マージリクエストにCI/CDパイプラインが存在しない場合、外部エージェントに依頼するだけでパイプラインが作成されます。エージェントは、アプリケーションのビルド、プロジェクトのJavaバージョンに合ったベースイメージを使用したDockerfileの作成、Dockerイメージのビルド、GitLabの組み込みコンテナレジストリへのデプロイを行う完全なパイプライン設定を生成します。パイプラインはすべて自動的に実行され、ビルド、Dockerイメージ作成、レジストリへのデプロイの各ステージが順次処理されます。この間、手動設定や手動操作は必要ありません。</p><p><img alt="パイプラインとコンテナイメージの作成を外部エージェントに依頼するプロンプト" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058392/bwqipksewm1hejuycwqh.png" title="パイプラインとコンテナイメージの作成を外部エージェントに依頼するプロンプト" /></p><p><img alt="外部エージェントが新たに作成したパイプラインとDockerfileファイル" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058395/agyr8hhc1vax7aarsxoj.png" title="外部エージェントが新たに作成したパイプラインとDockerfileファイル" /></p><p><img alt="新たに作成したパイプラインの実行成功" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058395/cdm4mye5edkpemedpxts.png" title="新たに作成したパイプラインの実行成功" /></p><p><img alt="パイプライン実行により新たに作成されたコンテナイメージ" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1772058395/bifx71xz9k7vedbo9xl3.png" title="パイプライン実行により新たに作成されたコンテナイメージ" /></p><h2 id="まとめ">まとめ</h2><p>外部エージェントを活用するGitLab Duo Agent Platformは、組織のソフトウェア開発アプローチを根本から変える存在です。AIツールの孤立化やワークフローの断片化という本質的な問題に対処することで、外部エージェントはチームがすでに使用しているプラットフォームに直接、インテリジェントな自動化をもたらします。Duo Agent Platformでは、AIを別個のコーディングアシスタントとして扱うのではなく、Claudeなどの外部モデルをGitLabのワークフローにシームレスに統合します。これにより、エージェントはプロジェクトの全コンテキストを把握し、組織の基準に従い、開発ライフサイクル全体にわたる複雑なタスクを自律的に処理できます。</p><p>その価値は明確です。開発チームはデリバリーのタイムラインを短縮し、一貫したコード品質を維持し、反復作業を削減することで、スキルの高いエンジニアがルーティン作業ではなくイノベーションに集中できる環境を実現できます。イシューの説明に基づく本番対応コードの生成から、徹底的なコードレビューの実施、デプロイパイプラインの自動化までを担う外部エージェントは、組織固有のニーズと基準を理解した、頼れる協働パートナーになります。</p><p>ソフトウェア開発ライフサイクル全体を通じて、より速く、より高い品質でプロダクトを届けたい方は、ぜひ<a href="https://about.gitlab.com/ja-jp/gitlab-duo-agent-platform/" rel="">GitLab Duo Agent Platformをお試し</a>ください。また、「<a href="https://about.gitlab.com/ja-jp/blog/gitlab-duo-agent-platform-complete-getting-started-guide/" rel="">GitLab Duo Agent Platformを始める：完全ガイド</a>」もあわせてご活用ください。</p>]]></content>
        <author>
            <name>Cesar Saavedra</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/cesar-saavedra/</uri>
        </author>
        <published>2026-02-26T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLabでパスキーによるパスワードレスサインインと2FAが利用可能に]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/passkeys-now-available-for-passwordless-sign-in-and-2fa-on-gitlab/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/passkeys-now-available-for-passwordless-sign-in-and-2fa-on-gitlab/"/>
        <updated>2026-02-25T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>GitLabでパスキーが利用可能になり、より安全で便利なアカウントアクセス方法を提供します。パスキーは、パスワードレスサインインまたはフィッシング耐性のある2要素認証（2FA）方法として使用できます。パスキーを使用すると、デバイスの指紋認証、顔認識、またはPINを使って認証を行うことができます。2FAが有効になっているアカウントでは、パスキーが自動的にデフォルトの2FA方法として利用可能になります。</p><figure className="video_container"> <iframe src="https://www.youtube.com/embed/LN5MGRdTHR8?si=OOebJZzN3LkSmzNv" title="Passwordless authentication using passkeys" frameBorder="0" allowFullScreen="true"></iframe> </figure><p><br /><br /></p><p>アカウントにパスキーを登録するには、プロフィール設定にアクセスし、<strong>アカウント &gt; 認証管理</strong>を選択してください。</p><p>パスキーはWebAuthn技術と、秘密鍵と公開鍵で構成される公開鍵暗号化を使用しています。秘密鍵はデバイス上に安全に保存され、決して外部に送信されることはありません。一方、公開鍵はGitLabに保存されます。仮にGitLabが侵害されたとしても、攻撃者は保存された認証情報を使用してアカウントにアクセスすることはできません。パスキーは、デスクトップブラウザ（Chrome、Firefox、Safari、Edge）、モバイルデバイス（iOS 16以降、Android 9以降）、FIDO2ハードウェアセキュリティキーで動作し、複数のデバイスにパスキーを登録して便利にアクセスできます。</p><p><img alt="Passkeys sign-in with two-factor authentication" src="https://res.cloudinary.com/about-gitlab-com/image/upload/v1767807931/n652nkgvna1rsymlfzpi.png" /></p><p>GitLabは<a href="https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/" rel="">CISA Secure by Design Pledge</a>に署名し、セキュリティ対策状況の改善とお客様がより迅速に安全なソフトウェアを開発できるよう支援することをコミットしています。この誓約の主要な目標の一つは、製造業者の製品全体で<a href="https://about.gitlab.com/blog/last-year-we-signed-the-secure-by-design-pledge-heres-our-progress/#multi-factor-authentication-mfa" rel="">多要素認証（MFA）</a>の使用を拡大することです。パスキーはこの目標の重要な要素であり、GitLabへのサインインをより安全で便利にするシームレスでフィッシング耐性のあるMFA方法を提供します。</p><p>ご質問がある場合、体験を共有したい場合、または潜在的な改善についてチームと直接やり取りしたい場合は、<a href="https://gitlab.com/gitlab-org/gitlab/-/work_items/366758" rel="">フィードバックイシュー</a>をご覧ください。</p>]]></content>
        <author>
            <name>GitLab</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/gitlab/</uri>
        </author>
        <published>2026-02-25T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLabの新しいメトリクスとレジストリ機能でCI/CDのボトルネックを解消]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/new-gitlab-metrics-and-registry-features-help-reduce-ci-cd-bottlenecks/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/new-gitlab-metrics-and-registry-features-help-reduce-ci-cd-bottlenecks/"/>
        <updated>2026-02-25T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>プラットフォームエンジニアやDevOpsエンジニアは、断片化されたツール間の可視性を確保したり、本来スムーズに動作すべきインフラストラクチャを管理したりするために、多くの時間を費やしています。</p><p>現在ベータ版として提供中の2つの新しいGitLab機能は、異なる角度からこの課題に取り組みつつ、同じ目標を共有しています。それは、サードパーティツールを追加することなく、CI/CDインフラストラクチャを直接制御できるようにすることです。1つはパイプラインの監視画面でジョブレベルのパフォーマンスデータを表示する機能、もう1つはビルトインキャッシュを活用して複数のレジストリからコンテナイメージをプルする作業を簡素化する機能です。</p><p>どちらの機能も現在フィードバックを受け付けています。皆さまのご意見が、今後のリリース内容を形作る重要な要素となります。</p><h2 id="cicdジョブパフォーマンスメトリクス">CI/CDジョブパフォーマンスメトリクス</h2><ul><li><strong>対象プラン：</strong> GitLab Premium、GitLab Ultimate</li><li><strong>ステータス：</strong> GitLab.comでは限定公開ベータ版として提供中。GitLab Self-ManagedおよびGitLab Dedicatedでは、ClickHouseの設定後に利用可能</li></ul><p>現状では、特定のジョブの実行時間が増加し始めたタイミングや、パイプラインの実行時間を密かに低下させているジョブを簡単に確認する方法がありません。多くのチームは、以下のような基本的な疑問に答えるために、カスタムダッシュボードを構築するか、ログを手動で調査しています。</p><ul><li>最も遅いジョブはどれか</li><li>失敗率が上昇しているのはどこか</li><li>本当のボトルネックはどのステージか</li></ul><p>CI/CDジョブパフォーマンスメトリクスは、プロジェクトレベルのCI/CD分析ページにジョブに特化した新しいパネルを追加することで、この課題を解決します。</p><p>パイプライン内の各ジョブについて、以下の情報を確認できます。</p><ul><li>標準的な実行時間（P50、中央値）と最悪ケースの実行時間（P95）により、通常の実行と最も遅い実行を素早く比較可能</li><li>失敗率の表示により、不安定なジョブやフレーキーなジョブを特定可能</li><li>ジョブ名とステージ（デフォルトで過去30日間のデータを表示）</li></ul><p>テーブルはソート、ジョブ名での検索、ページネーションに対応しており、プラットフォームチームは、従来は別々のツールやカスタムレポートが必要だった疑問に対して、単一のビューで回答を得られます。</p><p><strong>今すぐお試しください</strong></p><ul><li>プロジェクトに移動し、<strong>分析 &gt; CI/CD分析</strong>を選択してください。</li><li>CI/CDジョブパフォーマンスメトリクスパネルを探し、実行時間や失敗率でソートして、最も遅いジョブや信頼性の低いジョブを見つけてください。</li></ul><p><strong>ドキュメント</strong></p><ul><li><a href="https://docs.gitlab.com/user/analytics/ci_cd_analytics/#cicd-job-performance-metrics" rel="">CI/CD分析 – CI/CDジョブパフォーマンスメトリクス</a></li></ul><p><strong>今後の予定</strong></p><p>ステージレベルのグルーピング機能の開発を進めており、ビルド、テスト、デプロイの各ステージにわたる集計メトリクスを表示し、最適化に注力すべきポイントを素早く把握できるようになります。</p><p><strong>フィードバックをお寄せください：</strong></p><ul><li><a href="https://gitlab.com/groups/gitlab-org/-/work_items/18548" rel="">CI/CDジョブパフォーマンスメトリクスのエピック</a></li></ul><h2 id="コンテナバーチャルレジストリ">コンテナバーチャルレジストリ</h2><p><strong>対象プラン：</strong> GitLab Premium、GitLab Ultimate
<strong>ステータス：</strong> ベータ版、18.9でAPI対応</p><p>CI/CDパイプラインにコンテナイメージをプルする多くの組織は、Docker Hub、Harbor、Quay、社内レジストリなど、複数のレジストリに依存しています。これらすべてにわたる認証、可用性、キャッシュの管理は、パイプラインの速度低下や脆弱性の原因となる運用上のオーバーヘッドです。</p><p>コンテナバーチャルレジストリを使用すると、ビルトインキャッシュを備えた単一のGitLabエンドポイントを作成し、複数のアップストリームコンテナソースからプルできるようになります。</p><p>パイプライン設定で各レジストリの認証情報や可用性を個別に構成する代わりに、以下のことが可能です。</p><ul><li>パイプラインを1つのGitLabバーチャルレジストリエンドポイントに向ける</li><li>複数のアップストリームレジストリ（Docker Hub、Harbor、Quay、および長期トークン認証を使用するその他のレジストリ）を設定する</li><li>GitLabがイメージプルを自動的に解決し、プルスルーキャッシュにより帯域幅コストの削減と信頼性の向上を実現</li></ul><p>GitLabをコンテナレジストリの代替として評価しているチームにとって、これは重要な機能ギャップを埋めるものです。すでにマルチレジストリのコンテナワークフローを管理しているチームにとっては、イメージ管理をGitLabに集約し、重複するプルを削減できます。</p><p><strong>現在のベータ版でサポートされている機能</strong></p><ul><li>長期トークン認証を使用するアップストリームレジストリ：Docker Hub、Harbor、Quay、およびその他の互換性のあるレジストリ</li><li>プルスルーキャッシュにより、よく使用されるイメージは初回プル後にGitLabから提供</li><li>APIファーストの設定（UI管理は開発中）</li></ul><p>IAM認証を必要とするクラウドプロバイダーのレジストリ（Amazon Elastic Container Registry、Google Artifact Registry、Azure Container Registryなど）は、今後のイテレーションでの対応を検討中です。</p><p><strong>今すぐお試しください</strong></p><ul><li>コンテナバーチャルレジストリは18.9でAPI対応済みです。</li><li>SaaS（GitLab.com）：CSMにご連絡いただくか、以下のフィードバックイシューにコメントして、グループの機能フラグを有効にするようリクエストしてください。</li><li>Self-Managed：機能フラグを有効にし、APIを使用してバーチャルレジストリを設定してください。</li></ul><p><strong>ドキュメント</strong></p><ul><li><a href="https://docs.gitlab.com/api/container_virtual_registries/" rel="">コンテナバーチャルレジストリAPI</a></li><li><a href="https://docs.gitlab.com/user/packages/virtual_registry/container/#pull-container-images-from-the-virtual-registry" rel="">バーチャルレジストリからコンテナイメージをプルする</a></li></ul><p>コンテナバーチャルレジストリベータ版のウォークスルーをご覧ください：</p><iframe src="https://player.vimeo.com/video/1167512082?title=0&amp;byline=0&amp;portrait=0&amp;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="20260223_Container Virtual Registry Beta_V1"></iframe><script src="https://player.vimeo.com/api/player.js"></script><p><br /><br /></p><p><strong>フィードバックをお寄せください：</strong></p><ul><li><a href="https://gitlab.com/gitlab-org/gitlab/-/issues/589630" rel="">コンテナバーチャルレジストリのフィードバックイシュー</a></li></ul><h2 id="重要な機能の開発にご協力ください">重要な機能の開発にご協力ください</h2><p>GitLabコミュニティの全員がコントリビューターです。これらのベータ版は、コミュニティからのリクエストに基づいて開発されました。</p><ul><li><strong>CI/CDジョブパフォーマンスメトリクス</strong>は、ビルド時間が悪化し始めたタイミングや、パイプラインの信頼性を損なっているジョブを簡単に確認する方法がなかったチームからの要望に基づいています。</li><li><strong>コンテナバーチャルレジストリ</strong>は、複数のレジストリを管理し、ツールの乱立や帯域幅コストを削減しながら、GitLabを中央レジストリとして評価しているエンタープライズのお客様からの要望に基づいています。</li></ul><p>皆さまのフィードバックが、次に開発する機能を形作ります。これらのベータ版の一方または両方をお試しいただき、リンク先のフィードバックイシューでご体験を共有してください。</p><p>これは、今年を通じてハイライトしていく予定のCore DevOpsベータ版シリーズの第1弾です。今後もさらに多くの機能が登場する予定ですので、皆さまのご協力により、できる限り有用なものにしていきたいと考えています。</p>]]></content>
        <author>
            <name>Talia Armato-Helle</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/talia-armato-helle/</uri>
        </author>
        <published>2026-02-25T00:00:00.000Z</published>
    </entry>
    <entry>
        <title type="html"><![CDATA[GitLabパッケージリポジトリのメタデータ署名に使用されるGPGキーの有効期限が延長されました]]></title>
        <id>https://about.gitlab.com/ja-jp/blog/gpg-key-used-to-sign-gitlab-package-repositories-metadata-has-been-extended/</id>
        <link href="https://about.gitlab.com/ja-jp/blog/gpg-key-used-to-sign-gitlab-package-repositories-metadata-has-been-extended/"/>
        <updated>2026-02-24T00:00:00.000Z</updated>
        <content type="html"><![CDATA[<p>GitLabでは、公式のomnibus-gitlabおよびgitlab-runnerパッケージの配布に使用される各種aptおよびyumリポジトリのメタデータに署名するためにGPGキーを使用しています。これにより、パッケージ自体が別のキーで署名されることに加えて、パッケージの整合性を確保しています。</p><p>現在メタデータの署名に使用されているキーのフィンガープリントは<code className="">F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F</code>で、2026年2月27日に期限切れとなる予定でしたが、2028年2月6日まで延長されました。</p><h2 id="なぜ有効期限を延長するのですか">なぜ有効期限を延長するのですか</h2><p>リポジトリメタデータ署名キーの有効期限は、GitLabのセキュリティポリシーに準拠し、キーが侵害された場合の影響を制限するために定期的に延長されています。新しいキーへのローテーションではなく有効期限の延長を行うのは、ユーザーへの影響を最小限に抑えるためです。ローテーションを行った場合、すべてのユーザーが信頼済みキーを置き換える必要があります。</p><h2 id="何をすればいいですか">何をすればいいですか</h2><p>2026年2月17日より前にお使いのマシンでGitLabリポジトリを既に設定している場合は、<a href="https://docs.gitlab.com/omnibus/update/package_signatures/#package-repository-metadata-signing-keys" rel="">新しいキーの取得と追加方法</a>に関する公式ドキュメントをご確認ください。</p><p>新規ユーザーの方は、<a href="https://about.gitlab.com/install/" rel="">GitLabインストールページ</a>または<a href="https://docs.gitlab.com/runner/install/linux-repository.html" rel="">gitlab-runnerインストールドキュメント</a>に従っていただく以外に、特別な対応は必要ありません。</p><p><a href="https://docs.gitlab.com/omnibus/update/package_signatures/#package-repository-metadata-signing-keys" rel="">リポジトリメタデータ署名の検証</a>に関する詳細情報は、Omnibusドキュメントでご確認いただけます。公開キーのコピーを更新する必要がある場合は、<a href="mailto:support@gitlab.com">support@gitlab.com</a>で検索するか、キーID <code className="">F640 3F65 44A3 8863 DAA0 B6E0 3F01 618A 5131 2F3F</code>を使用して、任意のGPGキーサーバーで見つけることができます。</p><p>または、次のURLを使用してpackages.gitlab.comから直接ダウンロードすることも可能です：<code className="">https://packages.gitlab.com/gpg.key</code></p><h2 id="さらにサポートが必要な方は">さらにサポートが必要な方は</h2><p><a href="https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/new?issue&amp;issuable_template=Bug" rel="">omnibus-gitlabイシュートラッカー</a>でイシューを作成してください。</p>]]></content>
        <author>
            <name>Denis Afonso</name>
            <uri>https://about.gitlab.com/ja-jp/blog/authors/denis-afonso/</uri>
        </author>
        <published>2026-02-24T00:00:00.000Z</published>
    </entry>
</feed>