[{"data":1,"prerenderedAt":811},["ShallowReactive",2],{"/ja-jp/blog/what-is-rest-api":3,"navigation-ja-jp":40,"banner-ja-jp":451,"footer-ja-jp":461,"blog-post-authors-ja-jp-GitLab France Team":693,"blog-related-posts-ja-jp-what-is-rest-api":708,"blog-promotions-ja-jp":749,"next-steps-ja-jp":802},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":24,"extension":25,"externalUrl":26,"featured":14,"heroImage":17,"isFeatured":14,"meta":27,"navigation":28,"path":29,"publishedDate":20,"rawbody":30,"seo":31,"slug":13,"stem":35,"tagSlugs":36,"tags":38,"template":15,"updatedDate":19,"__hash__":39},"blogPosts/ja-jp/blog/what-is-rest-api.yml","REST APIとは？定義と概要を徹底解説",[7],"gitlab-france-team",[9],"GitLab France Team","REST APIとは何か。そのメリットと活用方法について、よくある疑問にお答えします。\n\n**目次**\n\n* REST APIとは？\n* REST APIの仕組み\n* REST APIの原則\n* REST APIのメリット\n* REST APIの活用事例\n\n## REST APIとは？\n\nREST APIは、**REST（REpresentational State Transfer）アーキテクチャの標準に準拠したAPI（アプリケーション・プログラミング・インターフェース）**です。RESTful APIやRESTful Web APIとも呼ばれます。\n\nAPIとは、2つのアプリケーション間の通信を可能にするソフトウェアです。IT分野では、さまざまなアプリケーションを連携させるうえで欠かせない存在となっています。\n\nAPIを開発する際、開発者は厳密に定められた手法と原則に従う必要があります。2000年以前は、XMLをベースとした複雑で処理負荷の高いプロトコルであるSOAP（Simple Object Access Protocol）が広く使われていました。現在もSOAPは利用されていますが、その多くはREST APIに置き換えられています。\n\nRESTは2000年にアメリカの計算機科学者**Roy Fielding**が博士論文の中で考案しました。以来、REST（REpresentational State Transfer）はAPIを設計する際の主流モデルとなり、*World Wide Web*の発展においても重要な節目となっています。現在、大多数のAPIはRESTをベースとしており、特に**Webサービス、インタラクティブサービス、モバイルサービス**の提供において広く活用されています。以下では、RESTful APIの仕組み、メリット、そして多岐にわたる活用事例について見ていきます。\n\n## REST APIの仕組み\n\n実際の運用において、REST APIはクライアント・サーバー環境の原則に基づいて機能します。RESTful APIは、一方でユーザーやアプリケーションからのリクエストを受け取り、他方でサーバー（アプリケーションまたはデータベース）から返された情報を伝達します。\n\nRESTful APIの仕組みを理解するうえで、いくつかの重要な概念があります。**クライアント**はリクエストを行うエンティティです。たとえば、ブラウザ上で商品カタログを検索しているユーザーがこれにあたります。**API**はクライアントのリクエストをサーバーへ伝え、要求された情報をクライアントに返す役割を担います。APIを経由してやり取りされる情報がリソースです。**サーバー**はリクエストを処理します。上記の例では、検索条件に合致する商品リストを返します。\n\nクライアントからのリクエストは、**HTTPプロトコル**（HyperText Transfer Protocol）を通じて送信されます。主なメソッドとその役割は以下のとおりです。\n\n* GET：サーバーからデータを取得する。\n* POST：サーバーへ情報を送信・公開する（例：登録フォームのデータ）。\n* PUT：サーバー上の情報を更新する。\n* PATCH：既存のリソースを部分的に変更する。\n* DELETE：サーバー上の情報を削除する。\n\nREST APIで使用できるデータ形式はさまざまです。JSON（JavaScript Object Notation）は軽量で読みやすく、多くのプログラミング言語に対応しています。XML（Extensible Markup Language）は複雑なデータ構造を扱うことができ、RSSなどの標準規格との互換性も持ちます。YAMLやHTMLも、リソースのやり取りに頻繁に使用される形式です。\n\n## REST APIの原則\n\nREST APIは、**ソフトウェアアーキテクチャ**におけるRESTの原則に従います。これらの原則は、インターネット上でのデータ転送に最適な、柔軟で軽量なAPIを構築するための指針となっています。\n\nRESTインターフェースを規定する6つのアーキテクチャ原則は次のとおりです。\n\n* **クライアント・サーバーの分離。** クライアントは取得するリソースのURI（Uniform Resource Identifier）のみを把握します。サーバーはHTTPを通じてデータを送信するだけです。\n* **統一インターフェース。** RESTアーキテクチャは、情報の識別、管理、転送の方法を統一し、ハイパーリンクを通じてクライアントに追加リソースを提供します。\n* **オンデマンドコード。** サーバーはクライアントにコードを送信して機能を拡張できます。たとえば、フォームの入力エラーを検出するためのコードがこれにあたります。\n* **階層化システム。** RESTful APIは階層的に構成された複数のサーバー上で実行でき、クライアントへより安定したパフォーマンスの高いサービスを提供します。\n* **キャッシュ。** RESTサーバーはデータをキャッシュしてクライアントへの応答を最適化できます。たとえば、サイトの画像をキャッシュして再利用する場合がこれにあたります。\n* **ステートレス。** クライアントからの各リクエストは独立しており、サーバーによって個別に処理されます。そのため、各リクエストには処理に必要なすべての情報を含める必要があります。\n\n## REST APIのメリット\n\nREST APIのフレームワーク要件を満たすことで、開発者はRESTful APIの数多くのメリットを活かし、効率的で強力なアプリケーションを構築できます。\n\n* **汎用性：** 使用するプログラミング言語の制限がなく、データ形式（XML、PYTHON、JSON、HTMLなど）の選択肢も豊富です。\n* **軽量性：** REST APIの軽量なデータ形式により、モバイルアプリケーションやIoT（Internet of Things）に最適です。\n* **ポータビリティ：** クライアント・サーバーの分離により、プラットフォーム間のデータ交換が容易になります。\n* **柔軟性：** プロトコルの制約を受けないアーキテクチャスタイルです。\n* **独立性：** 開発者はクライアント側とサーバー側を個別に開発できます。\n\nREST APIのメリットは、開発チームの生産性向上とシステムのスケーラビリティとして現れます。REST APIを活用したシステムのスケールアップが容易になり、多数のユーザーと処理に対応できる機能を実現しやすくなります。\n\n### セキュリティ上の考慮事項\n\nRESTful Web APIの構築と管理には課題も存在します。HTTP、APIキー、OAuth（Open Authorization）など複数の認証方式を組み合わせる場合、**ユーザー認証**が複雑になることがあります。大規模で複雑なアプリケーションでは、サーバーとクライアント間の**エンドポイントの増加**が全体の整合性を損なう可能性があり、古いエンドポイントが残存した状態での更新も同様のリスクをはらんでいます。\n\nまた、RESTインターフェースはエンドポイントのURLを通じて識別子などの機密データを送信するという弱点があります。そのため、TLS（Transport Layer Security）による暗号化、堅牢なユーザー認証モデル、不正リクエストへの対処とレート制限の仕組みといった具体的なセキュリティ対策が必要です。\n\n## REST APIの活用事例\n\n開発者はRESTアーキテクチャのAPIを使用して、さまざまなサービスを構築・維持しています。多くのWebおよびモバイルアプリケーションはREST APIを使用してリソースや情報にアクセス・共有しています。クラウド環境では、分散型・ハイブリッドアーキテクチャのサービスを迅速に接続できます。大企業においては、情報システムのコンポーネント間の相互運用性を高めるためにも活用されています。\n\n以下は、有名企業におけるREST APIの活用事例です。\n\n* **Google Search。** このAPIは、Google WebおよびGoogle Imageの検索結果を数百万件リアルタイムで提供します。\n* **Deezer。** この音楽ストリーミングプラットフォームのREST APIにより、数百万曲のデータベースからアルバムやアーティストを検索できます。\n\nECサイトの価格更新、ソースコードのフィールド変更、投稿の自動化、[Kubernetesクラスターのオーケストレーション](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Kubernetes, la solution d'orchestration des conteneurs\")など、RESTful APIの活用範囲は開発者やデジタルアプリケーション開発者の発想次第で無限に広がります。\n\n### GitLabのREST API\n\nGitLabは、外部アプリケーションとの統合・自動化を実現する包括的なツールとAPIスイートを提供しています。GraphQL、Webhook、IDE拡張機能、そしてもちろんREST APIも含まれています。GitLabのREST APIはアクセストークン、OAuth、セッションCookieなど、さまざまな認証方法に対応しています。エンドポイントはDockerfileテンプレート、.gitignore、GitLab CI/CD YAML、オープンソースに対応しています。アジャイルかつクラウドネイティブなアプリケーション開発の可能性を最大限に活かすには、[GitLab REST APIの完全なドキュメント](https://docs.gitlab.com/ja-jp/api/rest/ \"GitLab REST APIのドキュメント\")をご覧ください。\n\n## REST API FAQ\n\n### RESTとSOAP\n\n**RESTとSOAP**は2つのAPIの標準です。REST API（REpresentational State Transfer）はRESTのアーキテクチャ原則に基づいており、軽量かつスケーラブルな方法でサーバーとクライアントを連携させます。REST APIは最も広く使われているAPIの種類です。SOAP（Simple Object Access Protocol）はより古く、より厳格なプロトコルであり、XML形式のみで利用できます。この歴史的な標準は、高いセキュリティレベルを必要とするアプリケーションに現在も使用されています。\n\n### RESTとREST APIの違いは？\n\nRESTは、コンピューターとサーバー間の相互運用性を確保しながら、Webサービスの構築やインターネット上でのデータ交換を容易にするためのソフトウェアアーキテクチャスタイルです。RESTful Web APIは、RESTの基本原則に基づいたAPIの一種です。\n\n### RESTとRESTfulの違いは？\n\nRESTは、Webサービスがシンプル・スケーラブル・高パフォーマンスになるよう設計するためのアーキテクチャ原則の集合体です。APIがこれらの原則に準拠している場合、すなわち標準的なHTTPメソッド（GET、POST、PUT、DELETE）の使用、明確で予測可能なURLによるリソースの整理、サーバー側のステートレス性などを満たしている場合に、そのAPIはRESTfulと呼ばれます。言い換えれば、REST APIであっても、このアーキテクチャのすべてのベストプラクティスを満たしていなければ、必ずしもRESTfulではありません。\n\n### REST APIの原則とは？\n\nREST APIはRESTアーキテクチャの6つの基本原則に従います。それらは、統一インターフェース、オンデマンドコード、階層化システム、キャッシュ、ステートレス、クライアント・サーバーの分離です。最後の原則はRESTful APIの構造の基盤をなすものであり、Webアプリケーションの世界においてこのAPIが成功している根本的な要因です。","devsecops",{"slug":13,"featured":14,"template":15},"what-is-rest-api",false,"BlogPost",{"heroImage":17,"body":10,"authors":18,"updatedDate":19,"date":20,"title":5,"tags":21,"description":24,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662858/Blog/Hero%20Images/API-REST.jpg",[9],"2026-04-10","2024-09-04",[22,23],"DevOps","DevSecOps","オンライン予約アプリ、モバイル決済ソリューション、メッセージングサービスなど、 幅広い開発現場でREST APIが活用されています。本記事ではその仕組みとメリットを解説します。","yml",null,{},true,"/ja-jp/blog/what-is-rest-api","seo:\n  ogTitle: REST APIとは？定義と概要を徹底解説\n  ogImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662858/Blog/Hero%20Images/API-REST.jpg\n  ogDescription: オンライン予約アプリ、モバイル決済ソリューション、メッセージングサービスなど、 幅広い開発現場でREST\n    APIが活用されています。本記事ではその仕組みとメリットを解説します。\n  ogSiteName: https://about.gitlab.com\n  noIndex: false\n  ogType: article\n  ogUrl: https://about.gitlab.com/blog/what-is-rest-api\n  title: REST APIとは？定義と概要を徹底解説\n  canonicalUrls: https://about.gitlab.com/blog/what-is-rest-api\n  description: オンライン予約アプリ、モバイル決済ソリューション、メッセージングサービスなど、 幅広い開発現場でREST\n    APIが活用されています。本記事ではその仕組みとメリットを解説します。\ncontent:\n  heroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662858/Blog/Hero%20Images/API-REST.jpg\n  body: >-\n    REST APIとは何か。そのメリットと活用方法について、よくある疑問にお答えします。\n\n\n    **目次**\n\n\n    * REST APIとは？\n\n    * REST APIの仕組み\n\n    * REST APIの原則\n\n    * REST APIのメリット\n\n    * REST APIの活用事例\n\n\n    ## REST APIとは？\n\n\n    REST APIは、**REST（REpresentational State Transfer）アーキテクチャの標準に準拠したAPI（アプリケーション・プログラミング・インターフェース）**です。RESTful APIやRESTful Web APIとも呼ばれます。\n\n\n    APIとは、2つのアプリケーション間の通信を可能にするソフトウェアです。IT分野では、さまざまなアプリケーションを連携させるうえで欠かせない存在となっています。\n\n\n    APIを開発する際、開発者は厳密に定められた手法と原則に従う必要があります。2000年以前は、XMLをベースとした複雑で処理負荷の高いプロトコルであるSOAP（Simple Object Access Protocol）が広く使われていました。現在もSOAPは利用されていますが、その多くはREST APIに置き換えられています。\n\n\n    RESTは2000年にアメリカの計算機科学者**Roy Fielding**が博士論文の中で考案しました。以来、REST（REpresentational State Transfer）はAPIを設計する際の主流モデルとなり、*World Wide Web*の発展においても重要な節目となっています。現在、大多数のAPIはRESTをベースとしており、特に**Webサービス、インタラクティブサービス、モバイルサービス**の提供において広く活用されています。以下では、RESTful APIの仕組み、メリット、そして多岐にわたる活用事例について見ていきます。\n\n\n    ## REST APIの仕組み\n\n\n    実際の運用において、REST APIはクライアント・サーバー環境の原則に基づいて機能します。RESTful APIは、一方でユーザーやアプリケーションからのリクエストを受け取り、他方でサーバー（アプリケーションまたはデータベース）から返された情報を伝達します。\n\n\n    RESTful APIの仕組みを理解するうえで、いくつかの重要な概念があります。**クライアント**はリクエストを行うエンティティです。たとえば、ブラウザ上で商品カタログを検索しているユーザーがこれにあたります。**API**はクライアントのリクエストをサーバーへ伝え、要求された情報をクライアントに返す役割を担います。APIを経由してやり取りされる情報がリソースです。**サーバー**はリクエストを処理します。上記の例では、検索条件に合致する商品リストを返します。\n\n\n    クライアントからのリクエストは、**HTTPプロトコル**（HyperText Transfer Protocol）を通じて送信されます。主なメソッドとその役割は以下のとおりです。\n\n\n    * GET：サーバーからデータを取得する。\n\n    * POST：サーバーへ情報を送信・公開する（例：登録フォームのデータ）。\n\n    * PUT：サーバー上の情報を更新する。\n\n    * PATCH：既存のリソースを部分的に変更する。\n\n    * DELETE：サーバー上の情報を削除する。\n\n\n    REST APIで使用できるデータ形式はさまざまです。JSON（JavaScript Object Notation）は軽量で読みやすく、多くのプログラミング言語に対応しています。XML（Extensible Markup Language）は複雑なデータ構造を扱うことができ、RSSなどの標準規格との互換性も持ちます。YAMLやHTMLも、リソースのやり取りに頻繁に使用される形式です。\n\n\n    ## REST APIの原則\n\n\n    REST APIは、**ソフトウェアアーキテクチャ**におけるRESTの原則に従います。これらの原則は、インターネット上でのデータ転送に最適な、柔軟で軽量なAPIを構築するための指針となっています。\n\n\n    RESTインターフェースを規定する6つのアーキテクチャ原則は次のとおりです。\n\n\n    * **クライアント・サーバーの分離。** クライアントは取得するリソースのURI（Uniform Resource Identifier）のみを把握します。サーバーはHTTPを通じてデータを送信するだけです。\n\n    * **統一インターフェース。** RESTアーキテクチャは、情報の識別、管理、転送の方法を統一し、ハイパーリンクを通じてクライアントに追加リソースを提供します。\n\n    * **オンデマンドコード。** サーバーはクライアントにコードを送信して機能を拡張できます。たとえば、フォームの入力エラーを検出するためのコードがこれにあたります。\n\n    * **階層化システム。** RESTful APIは階層的に構成された複数のサーバー上で実行でき、クライアントへより安定したパフォーマンスの高いサービスを提供します。\n\n    * **キャッシュ。** RESTサーバーはデータをキャッシュしてクライアントへの応答を最適化できます。たとえば、サイトの画像をキャッシュして再利用する場合がこれにあたります。\n\n    * **ステートレス。** クライアントからの各リクエストは独立しており、サーバーによって個別に処理されます。そのため、各リクエストには処理に必要なすべての情報を含める必要があります。\n\n\n    ## REST APIのメリット\n\n\n    REST APIのフレームワーク要件を満たすことで、開発者はRESTful APIの数多くのメリットを活かし、効率的で強力なアプリケーションを構築できます。\n\n\n    * **汎用性：** 使用するプログラミング言語の制限がなく、データ形式（XML、PYTHON、JSON、HTMLなど）の選択肢も豊富です。\n\n    * **軽量性：** REST APIの軽量なデータ形式により、モバイルアプリケーションやIoT（Internet of Things）に最適です。\n\n    * **ポータビリティ：** クライアント・サーバーの分離により、プラットフォーム間のデータ交換が容易になります。\n\n    * **柔軟性：** プロトコルの制約を受けないアーキテクチャスタイルです。\n\n    * **独立性：** 開発者はクライアント側とサーバー側を個別に開発できます。\n\n\n    REST APIのメリットは、開発チームの生産性向上とシステムのスケーラビリティとして現れます。REST APIを活用したシステムのスケールアップが容易になり、多数のユーザーと処理に対応できる機能を実現しやすくなります。\n\n\n    ### セキュリティ上の考慮事項\n\n\n    RESTful Web APIの構築と管理には課題も存在します。HTTP、APIキー、OAuth（Open Authorization）など複数の認証方式を組み合わせる場合、**ユーザー認証**が複雑になることがあります。大規模で複雑なアプリケーションでは、サーバーとクライアント間の**エンドポイントの増加**が全体の整合性を損なう可能性があり、古いエンドポイントが残存した状態での更新も同様のリスクをはらんでいます。\n\n\n    また、RESTインターフェースはエンドポイントのURLを通じて識別子などの機密データを送信するという弱点があります。そのため、TLS（Transport Layer Security）による暗号化、堅牢なユーザー認証モデル、不正リクエストへの対処とレート制限の仕組みといった具体的なセキュリティ対策が必要です。\n\n\n    ## REST APIの活用事例\n\n\n    開発者はRESTアーキテクチャのAPIを使用して、さまざまなサービスを構築・維持しています。多くのWebおよびモバイルアプリケーションはREST APIを使用してリソースや情報にアクセス・共有しています。クラウド環境では、分散型・ハイブリッドアーキテクチャのサービスを迅速に接続できます。大企業においては、情報システムのコンポーネント間の相互運用性を高めるためにも活用されています。\n\n\n    以下は、有名企業におけるREST APIの活用事例です。\n\n\n    * **Google Search。** このAPIは、Google WebおよびGoogle Imageの検索結果を数百万件リアルタイムで提供します。\n\n    * **Deezer。** この音楽ストリーミングプラットフォームのREST APIにより、数百万曲のデータベースからアルバムやアーティストを検索できます。\n\n\n    ECサイトの価格更新、ソースコードのフィールド変更、投稿の自動化、[Kubernetesクラスターのオーケストレーション](https://about.gitlab.com/fr-fr/blog/kubernetes-the-container-orchestration-solution/ \"Kubernetes, la solution d'orchestration des conteneurs\")など、RESTful APIの活用範囲は開発者やデジタルアプリケーション開発者の発想次第で無限に広がります。\n\n\n    ### GitLabのREST API\n\n\n    GitLabは、外部アプリケーションとの統合・自動化を実現する包括的なツールとAPIスイートを提供しています。GraphQL、Webhook、IDE拡張機能、そしてもちろんREST APIも含まれています。GitLabのREST APIはアクセストークン、OAuth、セッションCookieなど、さまざまな認証方法に対応しています。エンドポイントはDockerfileテンプレート、.gitignore、GitLab CI/CD YAML、オープンソースに対応しています。アジャイルかつクラウドネイティブなアプリケーション開発の可能性を最大限に活かすには、[GitLab REST APIの完全なドキュメント](https://docs.gitlab.com/ja-jp/api/rest/ \"GitLab REST APIのドキュメント\")をご覧ください。\n\n\n    ## REST API FAQ\n\n\n    ### RESTとSOAP\n\n\n    **RESTとSOAP**は2つのAPIの標準です。REST API（REpresentational State Transfer）はRESTのアーキテクチャ原則に基づいており、軽量かつスケーラブルな方法でサーバーとクライアントを連携させます。REST APIは最も広く使われているAPIの種類です。SOAP（Simple Object Access Protocol）はより古く、より厳格なプロトコルであり、XML形式のみで利用できます。この歴史的な標準は、高いセキュリティレベルを必要とするアプリケーションに現在も使用されています。\n\n\n    ### RESTとREST APIの違いは？\n\n\n    RESTは、コンピューターとサーバー間の相互運用性を確保しながら、Webサービスの構築やインターネット上でのデータ交換を容易にするためのソフトウェアアーキテクチャスタイルです。RESTful Web APIは、RESTの基本原則に基づいたAPIの一種です。\n\n\n    ### RESTとRESTfulの違いは？\n\n\n    RESTは、Webサービスがシンプル・スケーラブル・高パフォーマンスになるよう設計するためのアーキテクチャ原則の集合体です。APIがこれらの原則に準拠している場合、すなわち標準的なHTTPメソッド（GET、POST、PUT、DELETE）の使用、明確で予測可能なURLによるリソースの整理、サーバー側のステートレス性などを満たしている場合に、そのAPIはRESTfulと呼ばれます。言い換えれば、REST APIであっても、このアーキテクチャのすべてのベストプラクティスを満たしていなければ、必ずしもRESTfulではありません。\n\n\n    ### REST APIの原則とは？\n\n\n    REST APIはRESTアーキテクチャの6つの基本原則に従います。それらは、統一インターフェース、オンデマンドコード、階層化システム、キャッシュ、ステートレス、クライアント・サーバーの分離です。最後の原則はRESTful APIの構造の基盤をなすものであり、Webアプリケーションの世界においてこのAPIが成功している根本的な要因です。\n  authors:\n    - GitLab France Team\n  updatedDate: 2026-04-10\n  date: 2024-09-04\n  title: REST APIとは？定義と概要を徹底解説\n  tags:\n    - DevOps\n    - DevSecOps\n  description: オンライン予約アプリ、モバイル決済ソリューション、メッセージングサービスなど、 幅広い開発現場でREST\n    APIが活用されています。本記事ではその仕組みとメリットを解説します。\n  category: devsecops\nconfig:\n  slug: what-is-rest-api\n  featured: false\n  template: BlogPost\n",{"ogTitle":5,"ogImage":17,"ogDescription":24,"ogSiteName":32,"noIndex":14,"ogType":33,"ogUrl":34,"title":5,"canonicalUrls":34,"description":24},"https://about.gitlab.com","article","https://about.gitlab.com/blog/what-is-rest-api","ja-jp/blog/what-is-rest-api",[37,11],"devops",[22,23],"5yXkVLJ6M6_XOQFmdnIariq4gObVfi0M2g8biiBKoDY",{"data":41},{"logo":42,"freeTrial":47,"sales":52,"login":57,"items":62,"search":371,"minimal":404,"duo":421,"switchNav":430,"pricingDeployment":441},{"config":43},{"href":44,"dataGaName":45,"dataGaLocation":46},"/ja-jp/","gitlab logo","header",{"text":48,"config":49},"無料トライアルを開始",{"href":50,"dataGaName":51,"dataGaLocation":46},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":53,"config":54},"お問い合わせ",{"href":55,"dataGaName":56,"dataGaLocation":46},"/ja-jp/sales/","sales",{"text":58,"config":59},"サインイン",{"href":60,"dataGaName":61,"dataGaLocation":46},"https://gitlab.com/users/sign_in/","sign in",[63,90,187,192,293,353],{"text":64,"config":65,"cards":67},"プラットフォーム",{"dataNavLevelOne":66},"platform",[68,74,82],{"title":64,"description":69,"link":70},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":71,"config":72},"プラットフォームを探索",{"href":73,"dataGaName":66,"dataGaLocation":46},"/ja-jp/platform/",{"title":75,"description":76,"link":77},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":78,"config":79},"GitLab Duoのご紹介",{"href":80,"dataGaName":81,"dataGaLocation":46},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":83,"description":84,"link":85},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":86,"config":87},"詳細はこちら",{"href":88,"dataGaName":89,"dataGaLocation":46},"/ja-jp/why-gitlab/","why gitlab",{"text":91,"left":28,"config":92,"link":94,"lists":98,"footer":169},"製品",{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"すべてのソリューションを表示",{"href":97,"dataGaName":93,"dataGaLocation":46},"/ja-jp/solutions/",[99,124,147],{"title":100,"description":101,"link":102,"items":107},"自動化","CI/CDと自動化でデプロイを加速",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":46},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[108,112,115,120],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":46,"dataGaName":109},"/ja-jp/solutions/continuous-integration/",{"text":75,"config":113},{"href":80,"dataGaLocation":46,"dataGaName":114},"gitlab duo agent platform - product menu",{"text":116,"config":117},"ソースコード管理",{"href":118,"dataGaLocation":46,"dataGaName":119},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":121,"config":122},"自動化されたソフトウェアデリバリー",{"href":105,"dataGaLocation":46,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":46,"icon":131},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[133,137,142],{"text":134,"config":135},"アプリケーションセキュリティテスト",{"href":129,"dataGaName":136,"dataGaLocation":46},"Application security testing",{"text":138,"config":139},"ソフトウェアサプライチェーンの安全性",{"href":140,"dataGaLocation":46,"dataGaName":141},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":143,"config":144},"ソフトウェアコンプライアンス",{"href":145,"dataGaName":146,"dataGaLocation":46},"/ja-jp/solutions/software-compliance/","software compliance",{"title":148,"link":149,"items":154},"測定",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":46},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"可視性と測定",{"href":152,"dataGaLocation":46,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"バリューストリーム管理",{"href":162,"dataGaLocation":46,"dataGaName":163},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"分析とインサイト",{"href":167,"dataGaLocation":46,"dataGaName":168},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLabが活躍する場所",[172,177,182],{"text":173,"config":174},"大企業",{"href":175,"dataGaLocation":46,"dataGaName":176},"/ja-jp/enterprise/","enterprise",{"text":178,"config":179},"スモールビジネス",{"href":180,"dataGaLocation":46,"dataGaName":181},"/ja-jp/small-business/","small business",{"text":183,"config":184},"公共部門",{"href":185,"dataGaLocation":46,"dataGaName":186},"/ja-jp/solutions/public-sector/","public sector",{"text":188,"config":189},"価格",{"href":190,"dataGaName":191,"dataGaLocation":46,"dataNavLevelOne":191},"/ja-jp/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":280},"リソース",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"すべてのリソースを表示",{"href":199,"dataGaName":195,"dataGaLocation":46},"/ja-jp/resources/",[201,234,252],{"title":202,"items":203},"はじめに",[204,209,214,219,224,229],{"text":205,"config":206},"インストール",{"href":207,"dataGaName":208,"dataGaLocation":46},"/ja-jp/install/","install",{"text":210,"config":211},"クイックスタートガイド",{"href":212,"dataGaName":213,"dataGaLocation":46},"/ja-jp/get-started/","quick setup checklists",{"text":215,"config":216},"学ぶ",{"href":217,"dataGaLocation":46,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"製品ドキュメント",{"href":222,"dataGaName":223,"dataGaLocation":46},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":225,"config":226},"ベストプラクティスビデオ",{"href":227,"dataGaName":228,"dataGaLocation":46},"/ja-jp/getting-started-videos/","best practice videos",{"text":230,"config":231},"インテグレーション",{"href":232,"dataGaName":233,"dataGaLocation":46},"/ja-jp/integrations/","integrations",{"title":235,"items":236},"検索する",[237,242,247],{"text":238,"config":239},"お客様成功事例",{"href":240,"dataGaName":241,"dataGaLocation":46},"/ja-jp/customers/","customer success stories",{"text":243,"config":244},"ブログ",{"href":245,"dataGaName":246,"dataGaLocation":46},"/ja-jp/blog/","blog",{"text":248,"config":249},"リモート",{"href":250,"dataGaName":251,"dataGaLocation":46},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":253,"items":254},"つなげる",[255,260,265,270,275],{"text":256,"config":257},"GitLabサービス",{"href":258,"dataGaName":259,"dataGaLocation":46},"/ja-jp/services/","services",{"text":261,"config":262},"コミュニティ",{"href":263,"dataGaName":264,"dataGaLocation":46},"/community/","community",{"text":266,"config":267},"フォーラム",{"href":268,"dataGaName":269,"dataGaLocation":46},"https://forum.gitlab.com/","forum",{"text":271,"config":272},"イベント",{"href":273,"dataGaName":274,"dataGaLocation":46},"/events/","events",{"text":276,"config":277},"パートナー",{"href":278,"dataGaName":279,"dataGaLocation":46},"/ja-jp/partners/","partners",{"background":281,"textColor":282,"text":283,"image":284,"link":288},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":285,"config":286},"ソースプロモカード",{"src":287},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":289,"config":290},"最新情報を読む",{"href":291,"dataGaName":292,"dataGaLocation":46},"/ja-jp/the-source/","the source",{"text":294,"config":295,"lists":297},"会社情報",{"dataNavLevelOne":296},"company",[298],{"items":299},[300,305,311,313,318,323,328,333,338,343,348],{"text":301,"config":302},"GitLabについて",{"href":303,"dataGaName":304,"dataGaLocation":46},"/ja-jp/company/","about",{"text":306,"config":307,"footerGa":310},"採用情報",{"href":308,"dataGaName":309,"dataGaLocation":46},"/jobs/","jobs",{"dataGaName":309},{"text":271,"config":312},{"href":273,"dataGaName":274,"dataGaLocation":46},{"text":314,"config":315},"経営陣",{"href":316,"dataGaName":317,"dataGaLocation":46},"/company/team/e-group/","leadership",{"text":319,"config":320},"チーム",{"href":321,"dataGaName":322,"dataGaLocation":46},"/company/team/","team",{"text":324,"config":325},"ハンドブック",{"href":326,"dataGaName":327,"dataGaLocation":46},"https://handbook.gitlab.com/","handbook",{"text":329,"config":330},"投資家向け情報",{"href":331,"dataGaName":332,"dataGaLocation":46},"https://ir.gitlab.com/","investor relations",{"text":334,"config":335},"トラストセンター",{"href":336,"dataGaName":337,"dataGaLocation":46},"/ja-jp/security/","trust center",{"text":339,"config":340},"AI Transparency Center",{"href":341,"dataGaName":342,"dataGaLocation":46},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":344,"config":345},"ニュースレター",{"href":346,"dataGaName":347,"dataGaLocation":46},"/company/contact/#contact-forms","newsletter",{"text":349,"config":350},"プレス",{"href":351,"dataGaName":352,"dataGaLocation":46},"/press/","press",{"text":53,"config":354,"lists":355},{"dataNavLevelOne":296},[356],{"items":357},[358,361,366],{"text":53,"config":359},{"href":55,"dataGaName":360,"dataGaLocation":46},"talk to sales",{"text":362,"config":363},"サポートを受ける",{"href":364,"dataGaName":365,"dataGaLocation":46},"https://support.gitlab.com","support portal",{"text":367,"config":368},"カスタマーポータル",{"href":369,"dataGaName":370,"dataGaLocation":46},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":372,"login":373,"suggestions":380},"閉じる",{"text":374,"link":375},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":376,"config":377},"GitLab.com",{"href":60,"dataGaName":378,"dataGaLocation":379},"search login","search",{"text":381,"default":382},"提案",[383,385,390,392,396,400],{"text":75,"config":384},{"href":80,"dataGaName":75,"dataGaLocation":379},{"text":386,"config":387},"コード提案（AI）",{"href":388,"dataGaName":389,"dataGaLocation":379},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":391},{"href":111,"dataGaName":109,"dataGaLocation":379},{"text":393,"config":394},"GitLab on AWS",{"href":395,"dataGaName":393,"dataGaLocation":379},"/ja-jp/partners/technology-partners/aws/",{"text":397,"config":398},"GitLab on Google Cloud",{"href":399,"dataGaName":397,"dataGaLocation":379},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":401,"config":402},"GitLabを選ぶ理由",{"href":88,"dataGaName":403,"dataGaLocation":379},"Why GitLab?",{"freeTrial":405,"mobileIcon":409,"desktopIcon":414,"secondaryButton":417},{"text":48,"config":406},{"href":407,"dataGaName":51,"dataGaLocation":408},"https://gitlab.com/-/trials/new/","nav",{"altText":410,"config":411},"GitLabアイコン",{"src":412,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":410,"config":415},{"src":416,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":202,"config":418},{"href":419,"dataGaName":420,"dataGaLocation":408},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":422,"mobileIcon":426,"desktopIcon":428},{"text":423,"config":424},"GitLab Duoの詳細について",{"href":80,"dataGaName":425,"dataGaLocation":408},"gitlab duo",{"altText":410,"config":427},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":429},{"src":416,"dataGaName":413,"dataGaLocation":408},{"button":431,"mobileIcon":436,"desktopIcon":438},{"text":432,"config":433},"/switch",{"href":434,"dataGaName":435,"dataGaLocation":408},"#contact","switch",{"altText":410,"config":437},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":439},{"src":440,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":442,"mobileIcon":447,"desktopIcon":449},{"text":443,"config":444},"料金ページに戻る",{"href":190,"dataGaName":445,"dataGaLocation":408,"icon":446},"back to pricing","GoBack",{"altText":410,"config":448},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":450},{"src":416,"dataGaName":413,"dataGaLocation":408},{"title":452,"button":453,"config":458},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":454,"config":455},"GitLab Transcendを今すぐ視聴",{"href":456,"dataGaName":457,"dataGaLocation":46},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":459,"icon":460,"disabled":28},"release","AiStar",{"data":462},{"text":463,"source":464,"edit":470,"contribute":475,"config":480,"items":485,"minimal":684},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":465,"config":466},"ページのソースを表示",{"href":467,"dataGaName":468,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":471,"config":472},"このページを編集",{"href":473,"dataGaName":474,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":476,"config":477},"ご協力をお願いします",{"href":478,"dataGaName":479,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":481,"facebook":482,"youtube":483,"linkedin":484},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[486,531,580,623,650],{"title":188,"links":487,"subMenu":502},[488,492,497],{"text":489,"config":490},"プランの表示",{"href":190,"dataGaName":491,"dataGaLocation":469},"view plans",{"text":493,"config":494},"Premiumを選ぶ理由",{"href":495,"dataGaName":496,"dataGaLocation":469},"/ja-jp/pricing/premium/","why premium",{"text":498,"config":499},"Ultimateを選ぶ理由",{"href":500,"dataGaName":501,"dataGaLocation":469},"/ja-jp/pricing/ultimate/","why ultimate",[503],{"title":53,"links":504},[505,507,509,511,516,521,526],{"text":53,"config":506},{"href":55,"dataGaName":56,"dataGaLocation":469},{"text":362,"config":508},{"href":364,"dataGaName":365,"dataGaLocation":469},{"text":367,"config":510},{"href":369,"dataGaName":370,"dataGaLocation":469},{"text":512,"config":513},"ステータス",{"href":514,"dataGaName":515,"dataGaLocation":469},"https://status.gitlab.com/","status",{"text":517,"config":518},"利用規約",{"href":519,"dataGaName":520,"dataGaLocation":469},"/terms/","terms of use",{"text":522,"config":523},"プライバシーに関する声明",{"href":524,"dataGaName":525,"dataGaLocation":469},"/ja-jp/privacy/","privacy statement",{"text":527,"config":528},"Cookie 優先設定",{"dataGaName":529,"dataGaLocation":469,"id":530,"isOneTrustButton":28},"cookie preferences","ot-sdk-btn",{"title":91,"links":532,"subMenu":541},[533,537],{"text":534,"config":535},"DevSecOpsプラットフォーム",{"href":73,"dataGaName":536,"dataGaLocation":469},"devsecops platform",{"text":538,"config":539},"AI支援開発",{"href":80,"dataGaName":540,"dataGaLocation":469},"ai-assisted development",[542],{"title":543,"links":544},"トピック",[545,549,554,557,562,565,570,575],{"text":109,"config":546},{"href":547,"dataGaName":548,"dataGaLocation":469},"/ja-jp/topics/ci-cd/","cicd",{"text":550,"config":551},"GitOps",{"href":552,"dataGaName":553,"dataGaLocation":469},"/ja-jp/topics/gitops/","gitops",{"text":22,"config":555},{"href":556,"dataGaName":37,"dataGaLocation":469},"/ja-jp/topics/devops/",{"text":558,"config":559},"バージョン管理",{"href":560,"dataGaName":561,"dataGaLocation":469},"/ja-jp/topics/version-control/","version control",{"text":23,"config":563},{"href":564,"dataGaName":11,"dataGaLocation":469},"/ja-jp/topics/devsecops/",{"text":566,"config":567},"クラウドネイティブ",{"href":568,"dataGaName":569,"dataGaLocation":469},"/ja-jp/topics/cloud-native/","cloud native",{"text":571,"config":572},"コーディングのためのAI",{"href":573,"dataGaName":574,"dataGaLocation":469},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":576,"config":577},"エージェント型AI",{"href":578,"dataGaName":579,"dataGaLocation":469},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":581,"links":582},"ソリューション",[583,586,588,593,597,600,603,606,608,610,613,618],{"text":134,"config":584},{"href":129,"dataGaName":585,"dataGaLocation":469},"Application Security Testing",{"text":121,"config":587},{"href":105,"dataGaName":106,"dataGaLocation":469},{"text":589,"config":590},"アジャイル開発",{"href":591,"dataGaName":592,"dataGaLocation":469},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":594,"config":595},"SCM",{"href":118,"dataGaName":596,"dataGaLocation":469},"source code management",{"text":109,"config":598},{"href":111,"dataGaName":599,"dataGaLocation":469},"continuous integration & delivery",{"text":160,"config":601},{"href":162,"dataGaName":602,"dataGaLocation":469},"value stream management",{"text":550,"config":604},{"href":605,"dataGaName":553,"dataGaLocation":469},"/ja-jp/solutions/gitops/",{"text":173,"config":607},{"href":175,"dataGaName":176,"dataGaLocation":469},{"text":178,"config":609},{"href":180,"dataGaName":181,"dataGaLocation":469},{"text":611,"config":612},"公共機関",{"href":185,"dataGaName":186,"dataGaLocation":469},{"text":614,"config":615},"教育",{"href":616,"dataGaName":617,"dataGaLocation":469},"/ja-jp/solutions/education/","education",{"text":619,"config":620},"金融サービス",{"href":621,"dataGaName":622,"dataGaLocation":469},"/ja-jp/solutions/finance/","financial services",{"title":193,"links":624},[625,627,629,631,634,636,638,640,642,644,646,648],{"text":205,"config":626},{"href":207,"dataGaName":208,"dataGaLocation":469},{"text":210,"config":628},{"href":212,"dataGaName":213,"dataGaLocation":469},{"text":215,"config":630},{"href":217,"dataGaName":218,"dataGaLocation":469},{"text":220,"config":632},{"href":222,"dataGaName":633,"dataGaLocation":469},"docs",{"text":243,"config":635},{"href":245,"dataGaName":246,"dataGaLocation":469},{"text":238,"config":637},{"href":240,"dataGaName":241,"dataGaLocation":469},{"text":248,"config":639},{"href":250,"dataGaName":251,"dataGaLocation":469},{"text":256,"config":641},{"href":258,"dataGaName":259,"dataGaLocation":469},{"text":261,"config":643},{"href":263,"dataGaName":264,"dataGaLocation":469},{"text":266,"config":645},{"href":268,"dataGaName":269,"dataGaLocation":469},{"text":271,"config":647},{"href":273,"dataGaName":274,"dataGaLocation":469},{"text":276,"config":649},{"href":278,"dataGaName":279,"dataGaLocation":469},{"title":294,"links":651},[652,654,656,658,660,662,664,668,673,675,677,679],{"text":301,"config":653},{"href":303,"dataGaName":296,"dataGaLocation":469},{"text":306,"config":655},{"href":308,"dataGaName":309,"dataGaLocation":469},{"text":314,"config":657},{"href":316,"dataGaName":317,"dataGaLocation":469},{"text":319,"config":659},{"href":321,"dataGaName":322,"dataGaLocation":469},{"text":324,"config":661},{"href":326,"dataGaName":327,"dataGaLocation":469},{"text":329,"config":663},{"href":331,"dataGaName":332,"dataGaLocation":469},{"text":665,"config":666},"Sustainability",{"href":667,"dataGaName":665,"dataGaLocation":469},"/sustainability/",{"text":669,"config":670},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":671,"dataGaName":672,"dataGaLocation":469},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":334,"config":674},{"href":336,"dataGaName":337,"dataGaLocation":469},{"text":344,"config":676},{"href":346,"dataGaName":347,"dataGaLocation":469},{"text":349,"config":678},{"href":351,"dataGaName":352,"dataGaLocation":469},{"text":680,"config":681},"現代奴隷制の透明性に関する声明",{"href":682,"dataGaName":683,"dataGaLocation":469},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":685},[686,688,691],{"text":517,"config":687},{"href":519,"dataGaName":520,"dataGaLocation":469},{"text":689,"config":690},"Cookieの設定",{"dataGaName":529,"dataGaLocation":469,"id":530,"isOneTrustButton":28},{"text":522,"config":692},{"href":524,"dataGaName":525,"dataGaLocation":469},[694],{"id":695,"title":696,"body":26,"config":697,"content":699,"description":26,"extension":25,"meta":703,"navigation":28,"path":704,"seo":705,"stem":706,"__hash__":707},"blogAuthors/en-us/blog/authors/gitlab-france-team.yml","Gitlab France Team",{"template":698},"BlogAuthor",{"name":9,"config":700},{"headshot":701,"ctfId":702},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659488/Blog/Author%20Headshots/gitlab-logo-extra-whitespace.png","1gfblqN0ibYIuWGk7MOTny",{},"/en-us/blog/authors/gitlab-france-team",{},"en-us/blog/authors/gitlab-france-team","Eni-wcJbgxSvctiz4Yjf4UeRk6T6IWt1wK0KuHU907U",[709,725,738],{"content":710,"config":723},{"date":711,"authors":712,"heroImage":714,"title":715,"description":716,"body":717,"category":11,"tags":718},"2026-04-24",[713],"GitLab Japan Team","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776319994/uiregzmtojom32pmlq7y.jpg","開発基盤をGitLabに集約するSBI証券がAI時代に描く展望【GitLab Transcend Japan Fireside Chat】","2026年2月10日にGitLabが開催した「GitLab Transcend Japan」では、株式会社SBI証券 執行役員 IT企画部長 武藤恵慈氏にご登壇いただき、GitLab合同会社Head of Japan 小澤正治とのFireside Chat（対談）を行いました。その模様をレポートします。","2026年2月10日に[GitLabが開催した「GitLab Transcend Japan」](https://about.gitlab.com/ja-jp/blog/event-report-transcend-tokyo-2026/)では、株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈 氏にご登壇いただき、GitLab合同会社 Head of Japan 小澤 正治とのFireside Chat（対談）を行いました。その模様をレポートします。\n\n## AI時代、GitLabはエンタープライズ市場で輝く\n\n「GitLab Transcend Japan」では、国内の先進企業をゲストに招いたFireside Chat（炉端談義）を実施しました。ネット証券業界を牽引する株式会社SBI証券 執行役員IT企画部長 武藤 恵慈 氏とGitLab合同会社 Head of Japan 小澤 正治の対談形式です。\n\n対談に先立って、小澤は今回のイベントで発表された新しいAIのプラットフォームによる「インテリジェント・オーケストレーション」という新戦略を踏まえ、GitLabがエンタープライズ企業に提供できる本質的な価値として、3つのキーポイントを提示しました。\n\n![GitLab合同会社 Head of Japan 小澤 正治](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776320064/i7mwkbtxlh3lundhoojh.jpg \"GitLab合同会社 Head of Japan 小澤 正治\")\n\nまずは、フルコンテキストを保持できること。小澤は、「AIがシステムの状況を正しく理解し、的確に動くための必須条件は、ソフトウェア開発に関わるすべてのトランザクションデータを持っていることです」と語ります。企画から開発、運用までのあらゆる履歴を単一のプラットフォームで管理するGitLabの製品思想が、AI全盛の現在において最大の強みとして生きてきます。\n\n次に、Tech SaaSソリューションでありながらSelf-hostedの選択肢も提供していること。GitLabは、オンプレミス版の提供も引き続き重要な要素と位置づけており、金融機関をはじめとする高いセキュリティ要件や独自のガバナンスが求められるユーザー環境に合わせて、柔軟に活用できる点が強みになります。\n\n最後に、伴走サービスを提供できること。GitLabは日本にもプロフェッショナル・サービス・チームを置き、SBI証券様にもご利用いただいています。小澤は「テクノロジーは、導入して終わりではありません。それを組織にしっかりと定着させ、お客様と一緒になってTo-Be像＝あるべき姿を作り上げていくためには、伴走支援が有効になるケースが多いのです」と話しました。\n\n## SBI証券の開発基盤はシステム乱立状態から内製化へと大きく変わった\n\n対談の冒頭で武藤氏は、SBI証券のシステムの成り立ちと、これまでの歴史について会場にシェアしてくれました。SBI証券は、日本のネット証券業界でナンバーワンの座にあり、いまでも口座数や預り資産残高は飛躍的な成長を遂げています。しかし、創業以来約20年にわたるシステムの歴史は平坦なものではありませんでした。\n\n![株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776320066/ptnyonbnq4z1kha5znhu.jpg \"株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏\")\n\n武藤氏は、「以前は、大手ベンダーさんに大規模なシステムの構築を丸投げしていました。その後、協力していただくベンダーさんやパートナーさんが増え、結果として細かなシステムから大規模システムまでが乱立する状態になってしまったのです。10年前は、まさに“カオス”でしたね」と述懐します。「プログラミング言語も、採用しているプラットフォームもバラバラ。その時々で、最適なものを場当たり的に作っているような状態でした」。\n\n危機感を抱いた同社は、徐々にシステムの標準化に着手。さらに5年ほど前からはクラウドへの移行を強力に推進してきました。\n\n「証券会社として、日々新しいサービスを世に出し続けなければなりません。一方、その裏では老朽化したシステムの移行やリプレイスといった多数のプロジェクトが走っています。現在も、信じられないほど膨大な数の案件が並行して動いている状況です」（武藤氏）\n\n同社は、内製化も進めています。IT部門が自らの手でプロダクトを生み出すことで、変化対応力の高い強力なビジネスプラットフォームを作り上げたいという判断です。2025年、内製化をより強力に推進するにあたって、開発環境を統一し、エンジニアが本来の仕事である「コードを書くこと」に集中できる環境を整えるという大きな決断を下しました。GitLabの導入です。\n\n武藤氏は、「個人的には、システムにかかわる部分は基本的にすべてGitLabの中で一元管理したいと考えています。エンジニアは、コードを書きたいという思いが強いもの。そこを中心に開発サイクルを回せるようにしたかったのです」と話しています。\n\n## 「セキュリティ vs スピード」のジレンマを抱える中で、AIは“ガバナンスの番人”になれるか\n\n![写真左から株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏、GitLab合同会社 Head of Japan 小澤正治](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776320066/ggqhinnyx9bujia9zqct.jpg \"写真左から株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏、GitLab合同会社 Head of Japan 小澤正治\")\n\n証券システムには、「絶対にシステムを止めてはいけない」、「1円たりとも間違えてはならない」という絶対的な使命があります。一方でビジネス側からは「スピード」が求められます。これら相反する要求の間には、どうしてもギャップが生まれてしまいます。\n\n小澤は、「厳しいセキュリティとコンプライアンスが求められる中で、具体的にどのようにAIを活用されていく展望をお持ちでしょうか」と問いかけました。\n\n対して武藤氏は「お客様の資産を守ることが最も重要であり、セキュリティは絶対的なもの」と前置きした上で、現場のリアルな課題についてシェアしてくれました。「確実なシステムを作るために、開発の各フェーズでのチェックや承認を人の手で行っているのが現状です。しかし、個々の確認作業は待ち時間を生みます。さらに、セキュリティチェックがボトルネックになって開発効率を落とす要因になってしまっています」（武藤氏）\n\nコードを早く書くためのコーディングアシスタントとしてAI活用を進めつつ、武藤氏がAIに寄せる真の期待はこのリアルな課題の解決です。AIを「ガバナンスの番人」として機能させたいという展望です。\n\n「プロセスの正当性や、きちんとしたものができているかどうかのチェックを人手だけに頼るのではなく、AIの力を借りたいと考えています。人とAIが協調することで、スピード感を持って、堅実なシステムを生み出す仕組みを作り上げたいのです」（武藤氏）\n\n小澤は、「GitLabは開発効率を落とさずにセキュリティ要件を担保する仕組みづくりを支援できことを強みとしていますが、武藤さんの目から見ると、開発効率とセキュリティは両立できるものなのでしょうか」とさらに核心を突きます。\n\n武藤氏は、「できると思っています」と即答し、「そうしたギャップをうまく埋めてくれる存在がAIであり、GitLabのようなプラットフォームなのだと感じています」と話します。これまで、その解は“成熟したエンジニアを集めること”でした。優秀なメンバーがそろえば、短期間で安全なシステムを作れます。しかしながら、膨大な数の案件が並行して動いている状況において、すべてのプロジェクトをベテランで固めることは不可能です。品質を担保するためにすべてのプロジェクトに画一的かつ重厚なプロセスを適用すれば、開発効率は著しく低下します。そんなジレンマを抱えていた中で、AIが登場しました。\n\n「エンジニア個人の技術力に過度に頼らなくても、AIが品質やセキュリティのチェックをある程度担保してくれる。プロジェクトを効率的に進めるための的確なアドバイスをしてくれる。そうした視点でAIを活用できれば、両立は十分に可能になるでしょう」（武藤氏）\n\n## AIの活用でエンジニアは“本来の働き方”をできるようになる\n\n対談の終盤、テーマはIT人材の確保と定着へと移りました。現在、SBI証券には約300人の社員エンジニアが在籍し、多数のパートナー企業と協力して開発を進めています。内製化を推進する同社ですが、武藤氏は「チームの中でエンジニアを定着させるのはすごく難しいですし、新しい人材を採用するのも容易ではありません。身も蓋もない言い方をしてしまえば、当社のような事業会社のシステム部門は、就職市場でもいまいち人気がないんですよね……」と語り、聴講者の中に大きく頷く方々の姿も見られました。\n\nなぜ定着が難しいのでしょう。巨大な金融システムを安定稼働させるためには、詳細な確認作業や他部門との調整、各種書類作成などにも多くの時間を割くことになります。技術力を高めたいエンジニアにとって、こうした業務スタイルがフラストレーションの原因となるケースも出てきます。\n\n武藤氏は、「ルーティン作業やチェックをAIが担ってくれれば、人がやらなくても大丈夫な部分が圧倒的に増えます。そして、エンジニアはアーキテクチャの設計や、ビジネス側と連携したプロダクト創りそのものに使える時間を存分に確保できるようになるはずです」と語ります。AIが雑務を引き受けることで、エンジニアは本来のクリエイティブな業務に回帰できるのです。武藤氏は、この変化を起こすことができれば人材にとって魅力的な組織になれるとして、次のように語りました。\n\n「事業者側で主体的にビジネス価値を生むプロダクトを作る仕事は、本来エンジニアにとってやり甲斐があるはずなのです。AIの活用でそうした環境を整えることができれば、より多くの優秀なエンジニアが集まり、活躍できる組織になれます。人材獲得や定着の面でも、AIには大いに期待しています」",[719,720,23,274,622,721,722],"AI/ML","customers","security","user stories",{"featured":28,"template":15,"slug":724},"fireside-chat-transcend-tokyo-2026",{"content":726,"config":736},{"category":11,"date":727,"authors":728,"tags":729,"body":732,"title":733,"description":734,"heroImage":735},"2026-04-16",[713],[719,730,720,731,274,721,722],"collaboration","DevSecOps platform","2026年2月、GitLabは「Developers Summit 2026」に出展しました。本イベントにてスタッフ・リージョナル・マーケティングマネージャー川口 修平が、ピクシブ社のプロダクト開発ギルド Unit Leadのbash様と講演をおこないましたので、本記事にてその模様をレポートします。本講演ではピクシブ社がLLM利用率80％を実現した道筋について、川口がbash様からお話を伺いました。  \n\n![スタッフ・リージョナル・マーケティングマネージャー川口 修平](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300557/f5tilfouvx6il813daog.png \"スタッフ・リージョナル・マーケティングマネージャー川口 修平\")\n\n### ピクシブ社とは\n\n* 創作プラットフォーム「pixiv」を中核としてさまざまな創作活動を楽しむための事業を展開  \n* 社員数約400名で、そのうち開発者は約230名、エンジニアは約170名\n\n### GitLabとは\n\n* GitLabとは、AIネイティブDevSecOpsプラットフォーム  \n* GitLabは100ヵ国以上100,000以上の組織、5,000万以上のユーザーが利用\n\n![GitLabとは](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300556/x78nxrnwucp2aezdgiz4.png)\n\n### GitLab社とは\n\n* 2,000名以上の従業員（66ヵ国以上）  \n* オールリモート企業（世界中にオフィス無し）\n\n## Beyond the code時代へ ピクシブ社のなかで起きている変化とは？\n\nDevelopers Summit 2026のテーマは「Beyond the Code」です。LLMの性能向上により、ソフトウェア開発における定型作業の自動化など、バックオフィスやプロダクト開発の現場での、業務が最適化されています。\n\nそうしたなかで、ピクシブ社ではどのような変化が起きているか伺いました。\n\n「現在のエンジニアリングにおいて、単にコードを書き出す作業（タイピング）の価値よりも、その背後にある設計思想や『なぜそれを作るのか』という思考の価値がより高まっています。\n\n・背景をどう読み取り、なぜそのアプローチを選んだか\\\n・ほかにどんな選択肢があり、なぜそれをしなかったか\n\nという思考プロセスが、より重要になってきています。\n\nピクシブ社内にエンジニアギルドという組織があり、そこでそういったプロセスを大事にすることを2018年から行なってきました。少し先手を打てたかなというところがあり、これに沿って成果を上げようとしています。」\n\n## LLM利用率80％を実現！ピクシブが実践した「People・Process・Technology」三位一体の変革とは？\n\n![LLM利用率80％を実現！ピクシブが実践した「People・Process・Technology」三位一体の変革とは？](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300557/bf2q2iv8npbkrevn1nn5.jpg \"ピクシブ社プロダクト開発ギルドUnit Lead、bash氏\")\n\nピクシブ社のこうした変化は、まさに「Beyond the Code」を体現したものです。このような変化に対応する際に避けて通れないのが「自分たちがまず変わること」だと思います。\n\nけれど人は成功体験があったり確立されたプロセスがあったりすると、簡単に変わることはできません。そこで紹介したいのが、「People（人）、Process（プロセス）、Technology（テクノロジー）」というアプローチです。これは、まずTechnologyを抜本的に変え、それに合わせてProcessを整備し、それに応じてPeopleが変わっていくというアプローチになります。\n\n![「People（人）、Process（プロセス）、Technology（テクノロジー）」](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300553/ggrofuaaefmlz98fmf6h.png)\n\nGitLab社には、この変革実現アプローチでLLM時代に対応しているお客様が多くいらっしゃいます。ピクシブ社でも、同様のアプローチにてLLM利用率80％を達成されたとのことです。実際、どのようにして進められたのかをbash様に伺いました。\n\n### 3つの要素が螺旋形に絡み合いながら進化してきた\n\n「我々の変革は線形に進んできたわけではありません。それぞれの要素が螺旋形に絡み合いながら進化してきました。\n\nたとえば新しい技術を選定すると、人の行動が変わります。それに合わせて仕組みも変わってきて、そうこうしているうちに、次の新しい技術やバージョンが進展し、さらに変容するといった感じです。こういった相互作用を生み出しながら動いてきたのが実際のところです。\n\nこうした変革の成果として、LLM利用率80％・社内満足度90％・活用意欲向上95％を達成しました。」\n\n![3つの要素が螺旋形に絡み合いながら進化してきた](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300555/e5flajpmbn4jufsjgvkj.png)\n\nピクシブ社のLLM利用率80％という成果は、従業員各自が勝手にLLMを使ったというデータではありません。会社が決めたLLMを会社が決めたルールに沿って使った成果であり、そう考えるとLLM利用率80％というのは非常に素晴らしいです。\n\nここからはLLM利用率80％という成果を、People・Process・Technologyという3つの観点でどう達成されたかを伺います。\n\n### Technologyの変革 | GitLab Ultimate有償版の導入へ\n\n![Technologyの変革 | GitLab Ultimate有償版の導入へ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300553/pem3xgd49evviusemriy.png)\n\nまずはTechnologyの変革について、bash様に時系列で教えていただきました。\n\n「まず2013年にGitLabをGUI付きGitサーバーとして導入しました。2024年に大きな転換点がありGitLab Ultimateを導入し、SDLC（ソフトウェア開発ライフサイクル）をEnd to Endでカバーする基盤として本格的に整備を開始しています。\n\nまた、セキュリティスキャンや開発のバリューストリームの可視化などを実装し、それと両輪みたいなかたちでLLMの活用も開始しました。」\n\n#### GitLabを選定した理由\n\n次にGitLabを選定した理由について伺いました。\n\n「ツールチェーンvsプラットフォームがひとつの論点になりました。そのなかでツールチェーンと比べGitLabならコストを圧縮できるうえ、ライフサイクルを一貫して全体最適を狙いやすいという結論が出たのです。\n\nブラックボックス的なベンダーロックインにならないこともポイントでした。そのほか、セルフマネージメントで、必要に応じバッチをあてたりバージョンアップしたりできるという柔軟性も決め手になっています。」\n\n#### GitLab導入によるツールチェーンの解消\n\n![GitLab導入によるツールチェーンの解消](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776217764/k59vea5wbi5ck5uuf56g.png)\n\nGitLabを選定いただく理由として、ツールチェーン解消というポイントはよく挙げられます。そこで、ツールチェーンを運用するなかでの苦労について、bash様に伺いました。\n\n「エンジニア個人としては、ツール選びは楽しいですし自分にフィットする良いものを選びたいという気持ちはあります。そういったジレンマと戦う必要がある点が苦労ですね。\n\n組織レベルに引き上げて考えると、ツールチェーンに含まれるプロダクトはたくさんあります。これらをそれぞれで選定していると、契約上のスケールメリットが乏しくなるのです。小口契約ですと既成プランしか選択肢にならず、大口だとできるような大きな相談ができなくなりますからね。\n\nまた社内で使うツールのフラグメントがあると、メンバー異動が大変だったり、キャッチアップが難しかったり問題がどんどん出てきます。実用の苦労としては、個人・チームレベル・組織全体の最適が少しずつずれてくるという点がありますね。\n\nさらに、ツールチェーンでやるといろいろ選べるので、ところどころ入れ替えが難しい。意図せぬシャドーIT化だったり、外部ソリューションに頼るべきところを自分たちで作り込んでしまったりといった問題も発生します。」\n\n反対にプラットフォームのメリットについてうかがったところ、bash様は次のように話されました。\n\n「全体最適を追求しやすかったり、組織レベルでマクロの成果を見定めやすかったりする点が魅力ですね。ここで鍵となるのが人です。人をプラットフォームに寄せる必要が出てきて、ここが重要なポイントであり難しい点ですね。」\n\n#### GitLab Ultimateを導入しセキュリティ対策に着手した背景\n\n![GitLab Ultimateを導入しセキュリティ対策に着手した背景](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776217764/fq6ihuwnobueybhkxbro.png)\n\n次にGitLab Ultimate導入によるセキュリティ対策に着手した背景について、bash様に伺いました。\n\n「安全性・堅牢性を高めるためセキュリティが重要なのはもちろんですが、開発ライフサイクルとしても、インシデントはペースを乱す要素です。我々の開発体制は、運用とばらばらではありません。\n\nプロダクトを作って運用して、動かして維持してというのをホールチーム体制で続けているので、インシデントは開発時でも重要なイシューです。コードpush時のCIでは防げないサプライチェーンアタックや、外部要因で突然脆弱性が問題になることがあります。こういった問題を回避し、ホールチーム体制での開発継続性を大事にしたかったのです。」\n\n#### GitLab Ultimateを活用したピクシブのセキュリティ対策\n\nLLMの利用にあたって、セキュリティ脆弱性は重大な課題になります。IPAが毎年出しているレポートによれば、「2025年の企業におけるセキュリティ脅威 Top10」の第4位が「システムの脆弱性を悪用した攻撃」でした。またLLMが生成したコードについては、その45％に脆弱性が含まれているという調査もあります。\n\nこうしたなかで、ピクシブがどのようなセキュリティ対策を行っているか伺いました。\n\n![GitLab Ultimateを活用したピクシブのセキュリティ対策](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300558/zetxd9f9q7uwnfu05xe7.png)\n\n「いろいろあります。マージリクエストを実行する際、常に機械チェックをかけています。あとメインブランチを常にリリース可能な状態にしており、そこにあるソースコードに対し常にセキュリティスキャンをかけている状況です。ほかにもIaC構築や権限分離、レビュー・テスト・ライブラリ管理・アップデートなど、基本的な対策を忠実に行っています。\n\nただ、セキュリティは果てのない戦いなので、もう大丈夫とかもう十分な水準ということはありません。日々、改善し続けるためみんなで頑張っているという状況です。」\n\nピクシブが行っているのはリリース前のセキュリティスキャンだけ（DevOps+Sec）ではありません。開発サイクル全体でセキュリティスキャンが常に行われている状態（DevSecOps）です。\n\nこのように堅牢な体制があるからこそ、ピクシブでは自由にできる面もあるとのことでした。具体的に、どのようなことを自由に行えているのかbash様に伺いました。\n\n「たとえば開発者が自分にとって使いやすいIDEやツールを選べるように、複数の選択肢を設けています。また業務用PCも、ベンダーもスペックも自由にアレンジできる制度を長く運用している状況です。全体最適化を狙いつつ、各個人にあったツールを使っていこうという裁量の幅も設けています。」\n\n### Processの変革 |　①組織体制の整備\n\n![Processの変革 |　①組織体制の整備](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300559/ezjeke9kibifmm9znk29.png)\n\n次にProcessの変革についてbash様に伺いました。\n\n「まず組織体制の整備は欠かせません。LLM活用の取り組みは経営層と連携し、全社的に行わなければなかなか進まないと思います。各組織がそれぞれ単独で頑張っても難しいので、CTOの牽引力がキーとなり組織として横断的に推進する体制を整えました。\n\n開発サイクル全体でみるとCOE（Center of Excellence）を設置し、プロダクトを横断する関心事として進めています。LLMについては、組織の技術推進という文脈で専任部署が中心となって取り組みを進めた感じです。\n\nトップダウンでガイドラインを示し、LLMを活用しようというメッセージを出しました。一方で現場は自律的に、現場に即したものをどんどん活用し盛り上げています。トップダウンとボトムアップの両面から、推進しているという感じですね。」\n\n### Processの変革 |　②SDLCの整備\n\n「Processの変革について、2点目はSDLCの整備ということで、開発サイクルの健康診断を実施しました。パフォーマンスチューニングにプロファイリングが必要なように、『計測なくして改善なし』です。\n\nその結果、わかりやすいボトルネック工程があったわけでなく、複合的な問題が複数見つかりました。それに合わせた次の取り組みを考えていこうという状況です。」\n\nbash様がお話しされた「開発サイクルの健康診断」というキーワードは、まさにGitLabの特徴を表しています。GitLabは、開発サイクル全体のデータがひとつのプラットフォームに集約されるので、その一元化されたデータに基づいた生産性の可視化をすることができます。この可視化された生産性に基づいて開発サイクルの健康診断を実施されたとのことでした。\n\n### Processの変革 |　③評価制度の整備\n\n「Processの変革について、3つ目は評価制度の整備です。特に新しい評価制度を作ったわけでなく、生産性指標を評価に使うなという話はずっとしています。\n\nこれはよくあるアンチパターンとして、生産性指標を評価に用いることでうまくいかなくなるというのはよく聞いていました。うまくいかないことをペナルティと捉えてしまったりとか、『なぜそうなったか』を詰めたりするのは本当によくありません。\n\n生産性指標はあくまで改善のための情報であり、人を評価査定するための道具でないとはよく言っています。」\n\nProcessの変革について最後に、社内で好意的に受け止められたかをbash様に伺いました。\n\n「好意的というか『うまくいったらいいね』と、温かい目で見守ってくれた感じです。\n\n私としても、これがみんなの飛びつくような高関心領域になるとまで期待していません。ただ『ちょっと手間をかけるといっぱいいいことがある』という風に思ってもらえたら上々だな、と考えています。」\n\n### Peopleの変革 | ①Whole Teamカルチャー醸成\n\n最後にPeopleの変革についてbash様に伺いました。\n\n「ひとつ目は『Whole Team』カルチャーの醸成です。ひとつのチームとしてプロダクトに関する責任を持つことで、職種や役割を超えた相互支援ができます。\n\n品質・セキュリティ・パフォーマンスなど、推進担当の仕事にしてしまうのでなく、自分たちの仕事という意識をもつのです。そうしてCoEがそれを支援する、というのを前提にします。」\n\n### Peopleの変革 | ②LLMの性能を最大化する環境への配慮\n\n「次に、LLMを開発を支える強力なツールと捉え、性能を最大限に引き出せるよう、情報の整理の仕方（コンテキストの渡し方）を工夫することです。これまで人間が読むための情報としてまとめてきたコンテキストを、これからはLLMも読みやすくしなければならないという風に考え方を転換します。そうしてコンテキストを、LLMが処理できる組織知としての情報にするのです。」\n\n### Peopleの変革 | ③強い意志と責任感\n\n「3つ目は強い意志と責任感です。『LLMがこう出力したから』は理由になりません。自分の責任として『なぜ』を突き詰めるのです。\n\n前述したエンジニアギルドというところの活動で、『なぜそれをするのか』を考える習慣をエンジニア全員に頑張って根付かせてきました。こういった活動も役立っているなと思います。」\n\n### 採用について工夫していること\n\n入ってくる方にどういった素質があれば、ピクシブのこういった環境に適応できるのでしょうか。bash様に採用で重視する点を伺いました。\n\n「ミッションへのコミットメントをベースに、組織・事業・プロダクト・システムなどみんなで作っていくことについて大事にしていますね。」\n\n## ピクシブが目指すBeyond the code時代におけるあるべきエンジニア像とは？\n\n![ピクシブが目指すBeyond the code時代におけるあるべきエンジニア像とは？](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300556/y8ceh3zywuayp0bvhwmo.jpg)\n\n最後にピクシブが目指すBeyond the code時代におけるエンジニア像を伺いました。\n\n「エンジニアとはエンジニアリングを行う職種で、エンジニアリングとは、再現可能なプロセスを確立して継続することだと考えています。\n\n確かにコードを書ける能力は重要で、我々もエンジニアに求めるところです。エンジニア職といっても、インフラエンジニア、社内ライフエンジニア、開発エンジニアなどたくさんの役割がありますが、コードを通じて対話をする基礎能力は、どのエンジニアであれ役割であれ共通です。\n\nもちろん全員が常にコードを書くわけではありませんし、役割ごとに業務も違います。ただし問題をどう解釈しどんな手段で解決するか、という判断基準は共通であるべきです。なぜそれをしてなぜほかのやり方を取らなかったのか、を説明する責任はどのエンジニアにもあります。\n\nコードを書かないことの先にあるものを、今まで大事にしてきました。今後もそれを大事にして、まぐれ当たりでない再現可能なプロセスを積み重ねていく本質追求の姿勢が、エンジニアにとって重要だと考えます。」\n\n## まとめ\n\n本講演ではピクシブがLLM利用率を48％から80％へ、わずか1年で拡大させた変革の全体像をお話いただきました。ピクシブは、Technology、Process、Peopleという3つの要素を三位一体で変革してきたとのことです。\n\nTechnologyの変革ではツールチェーンをGitLabに統合し、プロセス全体にセキュリティを組み込むなどしてLLM活用の土台として整備しました。\n\nProcessの変革では経営と連携し、全社プロジェクトとしてCOEを立ち上げたとのことです。そうしてソフトウェア開発ライフサイクル全体を可視化し、守るべきガイドラインを示し、そのうえで評価制度を整備しました。\n\n最後にPeopleの変革では、Whole Teamカルチャーを醸成して、ひとつの目標を共有して全員で助け合う文化を根付かせたとのことです。そうしてLLMの性能を最大化するための配慮をしました。\n\nピクシブでは、この3つを変革することで、Beyond the code時代の変化に対応していったということです。今回のお話が皆様のヒントになれば幸いでございます。\n\n![ノベルティのシール](https://res.cloudinary.com/about-gitlab-com/image/upload/v1776300557/actim4eue89tuftgp1gj.jpg \"ノベルティのシール\")\n\n> 生産性のオーバーヘッドを極小化する開発支援ツール戦略を加速。[お客様事例：ピクシブ](https://about.gitlab.com/ja-jp/blog/epic-tokyo-2025-pixiv/)を読む","LLM利用率80%への道筋 ピクシブが実践した「People・Process・Technology」開発環境の三位一体の変革とは？","2026年2月、GitLabは「Developers Summit 2026」に出展しました。本イベントにてスタッフ・リージョナル・マーケティングマネージャー川口 修平が、ピクシブ社のプロダクト開発ギルド Unit Leadのbash様と講演をおこないましたので、本記事にてその模様をレポートします。本講演ではピクシブ社がLLM利用率80％を実現した道筋について、川口がbash様からお話を伺いました。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1776048599/gt0yoiimqorpdkne4kfm.jpg",{"featured":28,"template":15,"slug":737},"developers-summit-2026-spring-event-report",{"content":739,"config":747},{"heroImage":740,"body":741,"authors":742,"updatedDate":711,"date":743,"title":744,"tags":745,"description":746,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762140/zuh6yujweuoaixks5lul.jpg","2026年2月10日、GitLab は「GitLab Transcend Japan」を開催しました。本記事では、ビデオとセッションの模様を中心にレポートします。\n\n## **SaaSはAgentic AIの「主語」であるべき**\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762586/uqq532hneioadonhyl6i.jpg \"GitLab合同会社 Head of Japan 小澤 正治\")\n\nGitLab は2026年2月10日、東京・六本木ヒルズクラブで「GitLab Transcend Japan」を開催しました。今回のイベントは、世界12都市で同日開催されたグローバルカンファレンスの一環で、GitLabを先進的に活用されている国内ユーザーの皆様の中から、グローバルで選定された方々を招待して実施しました。\n\nオープニングセッションには、GitLab Head of Japan 小澤 正治が登壇。小澤は、AIが急速に普及し「手段」として定着しつつある現状を踏まえ、Tech [SaaS](https://about.gitlab.com/ja-jp/blog/what-is-saas/)のあり方を再定義する必要性について以下のように語りました。\n\n「これからは、[Agentic AI](https://about.gitlab.com/ja-jp/topics/agentic-ai/)（自律型のAI）そのものを主語として考えるSaaSなのか、それともSaaSというプラットフォームを主語にして考えるAgentic AIなのか、この違いが問われる時代になります」\n\n統合プラットフォームであるGitLabは、ソフトウェア開発における複雑なワークフローをコントロールし、すべてのトランザクションをデータとして蓄積しています。そして、この膨大かつ正確なデータ群のおかげで、人やAIはコンテキスト（文脈）としてその全容を理解できるようになるのです。つまり、AIが精度の高い回答を提供してくれるか否かは、こうしたデータがそろっているかどうかが大きなカギになるわけです。「これこそ、GitLabが提供できる根源的な価値になります」（小澤）。\n\n小澤は、現在の日本企業を取り巻く環境について、3つの重要なトピックを挙げました。サイバーセキュリティと法規制、円安と輸出規制、および2025年の崖と人材不足です。\n\nサイバーセキュリティと法規制では、サイバー攻撃によるインシデントが多発する中、NIST（米国国立標準技術研究所）のガイドラインなど、国内外の法規制への対応が必須となっています。もはやセキュリティは「努力目標」ではなく「経営課題」と言える状況です。円安と輸出規制では、円安が輸出企業にとって追い風になる一方、欧州のサイバーレジリエンス法（CRA）やGDPRなどの規制をクリアしなければグローバル市場で戦えません。これらがビジネスのハードルになるケースが増えてきています。最後の2025年の崖と人材不足では、レガシーシステムのモダナイゼーションを推進できるIT人材の確保が多くの企業にとって悩みの種になっています。\n\nGitLabは、これらの課題に対しシングルプラットフォームという価値でこたえることができます。\n\n小澤は、「ソフトウェア開発のすべてをGitLab上で行うことで、データは単一のデータストアに蓄積されます。分断されたツール群では成し得ないこのデータとコンテキストの一元化こそが、AI活用における最大の武器になります。また、コンプライアンスやガバナンスに強制力を効かせながら、効率を下げずにソフトウェア開発することで、安心・安全なデリバリーが可能になるのです」と語りました。\n\n## **インテリジェント・オーケストレーションがソフトウェア開発の未来を切り拓く**\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762585/aquhu0vpb07ibmortwhg.jpg \"会場の様子\")\n\n続いて、会場のスクリーンで全世界に向けたビデオが放映されました。GitLab CEO Bill Staplesをはじめとする経営陣、そして先進的なユーザー企業が登場し、AI時代の新たなソフトウェア開発戦略の発表の場です。\n\nStaplesは、「月曜の朝、コーヒーを片手にPCを開き、仕事をスタートさせます。しかし、実際にコードを書く時間はどれくらいあるでしょう？」と語りかけます。[25万人の開発者を対象とした調査](https://about.gitlab.com/ja-jp/developer-survey/japan/)によると、開発者が実際にコードを書いている時間は、1日平均でわずか52分に過ぎません。残りの時間は、会議、承認待ち、障害対応、およびその他の雑務に奪われているのです。\n\nこれがAIのパラドックスです。AIコーディングツールは、生産性10倍とうたいますが、それは業務全体のわずか10〜20%に過ぎないコーディング時間を短縮しているだけ。前後のプロセスにあるボトルネックが解消されない限り、ビジネス全体のデリバリー速度は劇的には向上しないのです。\n\nこの課題を解消するために、Staplesは「インテリジェント・オーケストレーション」という方向性を提唱します。これまでの開発は、人間がバケツリレーのように工程を渡していく「ステージベース」でした。これからは、AIエージェントが自律的にタスクを拾い、プロセス間を繋ぐ形へとシフトします。\n\n「人間はループの上に立ち、エージェントをオーケストレーション（指揮）する役割へと進化します」（Staples）と語ります。雑務から解放され、戦略や創造的な意思決定に集中する未来の姿がそこにあります。\n\n続いて、このビジョンを実践している企業として、サウスウエスト航空社のManaging Director、Grant Morris氏が登場しました。同社は、個別最適化されたツール群を捨て、GitLabでソフトウェア開発の全プロセスを統合。セキュリティとコンプライアンスを担保しながら開発者がビジネス価値の創出に集中できる環境を整備しています。\n\nAI活用についてGrant氏は、「セキュリティ修正や依存関係のアップデートなど、エンジニアが疲弊するルーティンワークをAIエージェントに任せています」と語ります。さらに将来は、「AIエージェントがバックグラウンドで常にコードを監視し、リファクタリング（ソフトウェアの内部コード構造を整理する作業）やアップグレードを自律的に提案してくれるようになるでしょう。つまり、技術的負債という概念自体が過去のものになります」と語りました。\n\n続いて登場したGitLab CPMOのManav Khuranaは、インテリジェント・オーケストレーションを実現するための製品戦略について解説しました。\n\nまずは、AIエージェントをGitLab内で機能させる基盤となるAgentic Coreの進化。リポジトリやイシューなどをAIがコンテキストとして理解できるように構造化する独自技術を提供します。汎用的なエージェントに加え、各社独自のノウハウを組み込んだCustom Agentsを作成・公開できるAI Catalogを用意し、JiraやSlackなど外部ツールからもコンテキストを取得するためにModel Context Protocol （MCP）にも対応します。\n\n既存機能の強化では、複雑なYAMLを書かずにAIと対話しながらパイプラインを構築できるAIファーストのCI/CDビルダーや、あらゆる成果物をGitLab内で一元管理し、AIエージェントが機密性の高い状態でも安全にアクセスできる仕組みを構築します。\n\nGitLabは、SaaSだけでなく、オンプレミス環境でも利用できます。AIもオンプレミスで利用できるよう、ガバナンスを効かせた状態でAIを活用できる環境も提供します。独自のAIモデルを持ち込むBYOM（Bring Your Own Model）や、インターネット遮断環境（エアギャップ）にも対応します。\n\nビデオの終盤には、Oracle Group VPであるVictor Restrepo氏が登場し、GitLabとの強力なパートナーシップについて語りました。Restrepo氏は、Oracle Cloud Infrastructure （OCI）のコストパフォーマンスとGitLabの効率性を組み合わせることでインフラコストを削減し、その分をイノベーション投資に回すクラウドエコノミクスの重要性を強調。「政府系クラウドや専用リージョンを持つOCI上でGitLabを稼働させれば、厳しい規制が課される業界でもセキュアにAIを活用できるようになります」とGitLabとの親和性についても語りました。\n\n## **コンテキストを理解し、自律的に動くAIエージェント**\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762585/etl4f4uhcggrndlhwgr2.jpg \"GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 吉瀬 淳一\")\n\nビデオで披露された最新機能について、次のセッションで実機デモを交えた解説が行われました。その際にも強調されたのは、コンテキストの重要性です。AIエージェントが的確な仕事をするためには、プロジェクトの全容を理解している必要があります。企画から監視までをシングルプラットフォームで管理しているGitLabだからこそ、AIは断片的な情報ではなく、プロジェクトの全履歴という文脈を理解した上で自律的に動くことができるのです。\n\nデモでは、まず[Duo Planner Agent](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/planner/)を紹介。「こんな感じの機能をリリースしたい」という人間からの曖昧な指示に対し、AIはバックログや現状のコードベースを分析し、数分で具体的なタスクへと分解し、実行計画を立案してくれます。[Duo CLI](https://docs.gitlab.com/ja-jp/cli/duo/cli/)のデモでは、ターミナル上での作業をAIが支援してくれる様子が披露されました。対話内容はWeb UIと同期されるため、開発者はツール間を行き来することなく、シームレスに作業を継続できます。\n\n[Foundational Flows](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/flows/foundational_flows/)のデモでは、CIパイプラインが失敗した際にワンクリックでAIがログを解析してくれました。原因の特定から修正コードの作成、そして修正用マージリクエストの作成まで、AIが自律的に支援してくれます。[Security Analyst Agent](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/)も便利です。脆弱性が検出された際に、単に警告を出すだけではなく、AIエージェントが「なぜ危険なのか」を解説し、具体的な修正パッチを作成してくれます。\n\n![](https://res.cloudinary.com/about-gitlab-com/image/upload/v1772762585/a9yas83dxdhjopxifx5z.jpg \"写真左から株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏、GitLab合同会社 Head of Japan 小澤正治\")\n\n最後のセッションには、国内の先進事例として、株式会社SBI証券 執行役員 IT企画部長 武藤 恵慈氏をお招きし、小澤とのFireside Chatを実施しました。かつてはシステムや言語が乱立する課題を抱えていた同社は内製化へと大きく舵を切り、大規模かつ多数のプロジェクトを効率的に推進しています。詳細なセッション内容は、[開発基盤をGitLabに集約するSBI証券がAI時代に描く展望【GitLab Transcend Japan Fireside Chat】](https://about.gitlab.com/ja-jp/blog/fireside-chat-transcend-tokyo-2026/)で公開しています。\n\nこの日のイベントでは、Staplesの以下の発言が印象に残りました。\n\n「ソフトウェア開発は、コードを書くことから価値を創ることへと変化しています」\n\nGitLabは単なるツールから、人間とAIエージェントが協調して働くための基盤である「インテリジェント・オーケストレーション・プラットフォーム」へと進化します。AIのパラドックスを乗り越え、開発者が真のイノベーションに注力できる未来へ。「Transcend（=超越）」というイベント名にふさわしい、新たな時代が幕を開けます。",[713],"2026-03-10","AIのパラドックスを解くカギはインテリジェント・オーケストレーション【GitLab Transcend Japanレポート】",[719,109,720,23,274,721,722],"2026年2月10日に開催した「GitLab Transcend Japan」の模様をレポートします。\n",{"featured":28,"template":15,"slug":748},"event-report-transcend-tokyo-2026",{"promotions":750},[751,765,777,788],{"id":752,"categories":753,"header":755,"text":756,"button":757,"image":762},"ai-modernization",[754],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":758,"config":759},"Get your AI maturity score",{"href":760,"dataGaName":761,"dataGaLocation":246},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":763},{"src":764},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":766,"categories":767,"header":769,"text":756,"button":770,"image":774},"devops-modernization",[768,11],"product","Are you just managing tools or shipping innovation?",{"text":771,"config":772},"Get your DevOps maturity score",{"href":773,"dataGaName":761,"dataGaLocation":246},"/assessments/devops-modernization-assessment/",{"config":775},{"src":776},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":778,"categories":779,"header":780,"text":756,"button":781,"image":785},"security-modernization",[721],"Are you trading speed for security?",{"text":782,"config":783},"Get your security maturity score",{"href":784,"dataGaName":761,"dataGaLocation":246},"/assessments/security-modernization-assessment/",{"config":786},{"src":787},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":789,"paths":790,"header":793,"text":794,"button":795,"image":800},"github-azure-migration",[791,792],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":796,"config":797},"See how GitLab compares to GitHub",{"href":798,"dataGaName":799,"dataGaLocation":246},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":801},{"src":776},{"header":803,"blurb":804,"button":805,"secondaryButton":809},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":48,"config":806},{"href":807,"dataGaName":51,"dataGaLocation":808},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/ja-jp/","feature",{"text":53,"config":810},{"href":55,"dataGaName":56,"dataGaLocation":808},1777493611707]