[{"data":1,"prerenderedAt":860},["ShallowReactive",2],{"/en-us/blog/tags/inside-gitlab/":3,"navigation-ja-jp":20,"banner-ja-jp":437,"footer-ja-jp":450,"inside GitLab-tag-page-ja-jp":660},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":11,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},"/en-us/blog/tags/inside-gitlab","tags",false,"",{"tag":9,"tagSlug":10},"inside GitLab","inside-gitlab",{"template":12},"BlogTag","content:en-us:blog:tags:inside-gitlab.yml","yaml","Inside Gitlab","content","en-us/blog/tags/inside-gitlab.yml","en-us/blog/tags/inside-gitlab","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":433,"_type":14,"title":434,"_source":16,"_file":435,"_stem":436,"_extension":19},"/shared/ja-jp/main-navigation","ja-jp",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":377,"minimal":411,"duo":424},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/ja-jp/","gitlab logo","header",{"text":30,"config":31},"無料トライアルを開始",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"お問い合わせ",{"href":37,"dataGaName":38,"dataGaLocation":28},"/ja-jp/sales/","sales",{"text":40,"config":41},"サインイン",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,188,193,299,359],{"text":46,"config":47,"cards":49,"footer":72},"プラットフォーム",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"最も包括的かつAIで強化されたDevSecOpsプラットフォーム",{"text":53,"config":54},"プラットフォームを詳しく見る",{"href":55,"dataGaName":48,"dataGaLocation":28},"/ja-jp/platform/",{"title":57,"description":58,"link":59},"GitLab Duo（AI）","開発のすべてのステージでAIを活用し、ソフトウェアをより迅速にビルド",{"text":60,"config":61},"GitLab Duoのご紹介",{"href":62,"dataGaName":63,"dataGaLocation":28},"/ja-jp/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"GitLabが選ばれる理由","GitLabが大企業に選ばれる理由10選",{"text":68,"config":69},"詳細はこちら",{"href":70,"dataGaName":71,"dataGaLocation":28},"/ja-jp/why-gitlab/","why gitlab",{"title":73,"items":74},"利用を開始：",[75,80,85],{"text":76,"config":77},"プラットフォームエンジニアリング",{"href":78,"dataGaName":79,"dataGaLocation":28},"/ja-jp/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"開発者の経験",{"href":83,"dataGaName":84,"dataGaLocation":28},"/ja-jp/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/ja-jp/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":170},"製品",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"すべてのソリューションを表示",{"href":97,"dataGaName":93,"dataGaLocation":28},"/ja-jp/solutions/",[99,125,148],{"title":100,"description":101,"link":102,"items":107},"自動化","CI/CDと自動化でデプロイを加速",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[108,112,116,121],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/ja-jp/solutions/continuous-integration/",{"text":113,"config":114},"AIアシストによる開発",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"ソースコード管理",{"href":119,"dataGaLocation":28,"dataGaName":120},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":122,"config":123},"自動化されたソフトウェアデリバリー",{"href":105,"dataGaLocation":28,"dataGaName":124},"Automated software delivery",{"title":126,"description":127,"link":128,"items":133},"セキュリティ","セキュリティを損なうことなくコードをより迅速に完成",{"config":129},{"href":130,"dataGaName":131,"dataGaLocation":28,"icon":132},"/ja-jp/solutions/security-compliance/","security and compliance","ShieldCheckLight",[134,139,144],{"text":135,"config":136},"Application Security Testing",{"href":137,"dataGaName":138,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":140,"config":141},"ソフトウェアサプライチェーンの安全性",{"href":142,"dataGaLocation":28,"dataGaName":143},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":145,"config":146},"Software Compliance",{"href":147,"dataGaName":145,"dataGaLocation":28},"/solutions/software-compliance/",{"title":149,"link":150,"items":155},"測定",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[156,160,165],{"text":157,"config":158},"可視性と測定",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"バリューストリーム管理",{"href":163,"dataGaLocation":28,"dataGaName":164},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":166,"config":167},"分析とインサイト",{"href":168,"dataGaLocation":28,"dataGaName":169},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":171,"items":172},"GitLabが活躍する場所",[173,178,183],{"text":174,"config":175},"Enterprise",{"href":176,"dataGaLocation":28,"dataGaName":177},"/ja-jp/enterprise/","enterprise",{"text":179,"config":180},"スモールビジネス",{"href":181,"dataGaLocation":28,"dataGaName":182},"/ja-jp/small-business/","small business",{"text":184,"config":185},"公共機関",{"href":186,"dataGaLocation":28,"dataGaName":187},"/ja-jp/solutions/public-sector/","public sector",{"text":189,"config":190},"価格",{"href":191,"dataGaName":192,"dataGaLocation":28,"dataNavLevelOne":192},"/ja-jp/pricing/","pricing",{"text":194,"config":195,"link":197,"lists":201,"feature":286},"関連リソース",{"dataNavLevelOne":196},"resources",{"text":198,"config":199},"すべてのリソースを表示",{"href":200,"dataGaName":196,"dataGaLocation":28},"/ja-jp/resources/",[202,235,258],{"title":203,"items":204},"はじめに",[205,210,215,220,225,230],{"text":206,"config":207},"インストール",{"href":208,"dataGaName":209,"dataGaLocation":28},"/ja-jp/install/","install",{"text":211,"config":212},"クイックスタートガイド",{"href":213,"dataGaName":214,"dataGaLocation":28},"/ja-jp/get-started/","quick setup checklists",{"text":216,"config":217},"学ぶ",{"href":218,"dataGaLocation":28,"dataGaName":219},"https://university.gitlab.com/","learn",{"text":221,"config":222},"製品ドキュメント",{"href":223,"dataGaName":224,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":226,"config":227},"ベストプラクティスビデオ",{"href":228,"dataGaName":229,"dataGaLocation":28},"/ja-jp/getting-started-videos/","best practice videos",{"text":231,"config":232},"インテグレーション",{"href":233,"dataGaName":234,"dataGaLocation":28},"/ja-jp/integrations/","integrations",{"title":236,"items":237},"検索する",[238,243,248,253],{"text":239,"config":240},"お客様成功事例",{"href":241,"dataGaName":242,"dataGaLocation":28},"/ja-jp/customers/","customer success stories",{"text":244,"config":245},"ブログ",{"href":246,"dataGaName":247,"dataGaLocation":28},"/ja-jp/blog/","blog",{"text":249,"config":250},"リモート",{"href":251,"dataGaName":252,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":254,"config":255},"TeamOps",{"href":256,"dataGaName":257,"dataGaLocation":28},"/ja-jp/teamops/","teamops",{"title":259,"items":260},"つなげる",[261,266,271,276,281],{"text":262,"config":263},"GitLabサービス",{"href":264,"dataGaName":265,"dataGaLocation":28},"/ja-jp/services/","services",{"text":267,"config":268},"コミュニティ",{"href":269,"dataGaName":270,"dataGaLocation":28},"/community/","community",{"text":272,"config":273},"フォーラム",{"href":274,"dataGaName":275,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":277,"config":278},"イベント",{"href":279,"dataGaName":280,"dataGaLocation":28},"/events/","events",{"text":282,"config":283},"パートナー",{"href":284,"dataGaName":285,"dataGaLocation":28},"/ja-jp/partners/","partners",{"backgroundColor":287,"textColor":288,"text":289,"image":290,"link":294},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":291,"config":292},"ソースプロモカード",{"src":293},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":295,"config":296},"最新情報を読む",{"href":297,"dataGaName":298,"dataGaLocation":28},"/ja-jp/the-source/","the source",{"text":300,"config":301,"lists":303},"Company",{"dataNavLevelOne":302},"company",[304],{"items":305},[306,311,317,319,324,329,334,339,344,349,354],{"text":307,"config":308},"GitLabについて",{"href":309,"dataGaName":310,"dataGaLocation":28},"/ja-jp/company/","about",{"text":312,"config":313,"footerGa":316},"採用情報",{"href":314,"dataGaName":315,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":315},{"text":277,"config":318},{"href":279,"dataGaName":280,"dataGaLocation":28},{"text":320,"config":321},"経営陣",{"href":322,"dataGaName":323,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":325,"config":326},"チーム",{"href":327,"dataGaName":328,"dataGaLocation":28},"/company/team/","team",{"text":330,"config":331},"ハンドブック",{"href":332,"dataGaName":333,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":335,"config":336},"投資家向け情報",{"href":337,"dataGaName":338,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":340,"config":341},"トラストセンター",{"href":342,"dataGaName":343,"dataGaLocation":28},"/ja-jp/security/","trust center",{"text":345,"config":346},"AI Transparency Center",{"href":347,"dataGaName":348,"dataGaLocation":28},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":350,"config":351},"ニュースレター",{"href":352,"dataGaName":353,"dataGaLocation":28},"/company/contact/","newsletter",{"text":355,"config":356},"プレス",{"href":357,"dataGaName":358,"dataGaLocation":28},"/press/","press",{"text":35,"config":360,"lists":361},{"dataNavLevelOne":302},[362],{"items":363},[364,367,372],{"text":35,"config":365},{"href":37,"dataGaName":366,"dataGaLocation":28},"talk to sales",{"text":368,"config":369},"サポートを受ける",{"href":370,"dataGaName":371,"dataGaLocation":28},"/support/","get help",{"text":373,"config":374},"カスタマーポータル",{"href":375,"dataGaName":376,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":378,"login":379,"suggestions":386},"閉じる",{"text":380,"link":381},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":382,"config":383},"GitLab.com",{"href":42,"dataGaName":384,"dataGaLocation":385},"search login","search",{"text":387,"default":388},"提案",[389,392,397,399,403,407],{"text":57,"config":390},{"href":62,"dataGaName":391,"dataGaLocation":385},"GitLab Duo (AI)",{"text":393,"config":394},"コード提案（AI）",{"href":395,"dataGaName":396,"dataGaLocation":385},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":398},{"href":111,"dataGaName":109,"dataGaLocation":385},{"text":400,"config":401},"GitLab on AWS",{"href":402,"dataGaName":400,"dataGaLocation":385},"/ja-jp/partners/technology-partners/aws/",{"text":404,"config":405},"GitLab on Google Cloud",{"href":406,"dataGaName":404,"dataGaLocation":385},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":408,"config":409},"GitLabを選ぶ理由",{"href":70,"dataGaName":410,"dataGaLocation":385},"Why GitLab?",{"freeTrial":412,"mobileIcon":416,"desktopIcon":421},{"text":30,"config":413},{"href":414,"dataGaName":33,"dataGaLocation":415},"https://gitlab.com/-/trials/new/","nav",{"altText":417,"config":418},"GitLabアイコン",{"src":419,"dataGaName":420,"dataGaLocation":415},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":417,"config":422},{"src":423,"dataGaName":420,"dataGaLocation":415},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"freeTrial":425,"mobileIcon":429,"desktopIcon":431},{"text":426,"config":427},"GitLab Duoの詳細について",{"href":62,"dataGaName":428,"dataGaLocation":415},"gitlab duo",{"altText":417,"config":430},{"src":419,"dataGaName":420,"dataGaLocation":415},{"altText":417,"config":432},{"src":423,"dataGaName":420,"dataGaLocation":415},"content:shared:ja-jp:main-navigation.yml","Main Navigation","shared/ja-jp/main-navigation.yml","shared/ja-jp/main-navigation",{"_path":438,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":439,"button":440,"config":445,"_id":447,"_type":14,"_source":16,"_file":448,"_stem":449,"_extension":19},"/shared/ja-jp/banner","GitLab Duo Agent Platformがパブリックベータ版で利用可能になりました！",{"text":441,"config":442},"ベータ版を試す",{"href":443,"dataGaName":444,"dataGaLocation":28},"/ja-jp/gitlab-duo/agent-platform/","duo banner",{"layout":446},"release","content:shared:ja-jp:banner.yml","shared/ja-jp/banner.yml","shared/ja-jp/banner",{"_path":451,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":452,"_id":656,"_type":14,"title":657,"_source":16,"_file":658,"_stem":659,"_extension":19},"/shared/ja-jp/main-footer",{"text":453,"source":454,"edit":460,"contribute":465,"config":470,"items":475,"minimal":648},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":455,"config":456},"ページのソースを表示",{"href":457,"dataGaName":458,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":461,"config":462},"このページを編集",{"href":463,"dataGaName":464,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":466,"config":467},"ご協力をお願いします",{"href":468,"dataGaName":469,"dataGaLocation":459},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":471,"facebook":472,"youtube":473,"linkedin":474},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[476,499,553,586,620],{"title":46,"links":477,"subMenu":482},[478],{"text":479,"config":480},"DevSecOpsプラットフォーム",{"href":55,"dataGaName":481,"dataGaLocation":459},"devsecops platform",[483],{"title":189,"links":484},[485,489,494],{"text":486,"config":487},"プランの表示",{"href":191,"dataGaName":488,"dataGaLocation":459},"view plans",{"text":490,"config":491},"Premiumを選ぶ理由",{"href":492,"dataGaName":493,"dataGaLocation":459},"/ja-jp/pricing/premium/","why premium",{"text":495,"config":496},"Ultimateを選ぶ理由",{"href":497,"dataGaName":498,"dataGaLocation":459},"/ja-jp/pricing/ultimate/","why ultimate",{"title":500,"links":501},"ソリューション",[502,507,510,512,517,522,526,529,532,537,539,541,543,548],{"text":503,"config":504},"デジタルトランスフォーメーション",{"href":505,"dataGaName":506,"dataGaLocation":459},"/ja-jp/topics/digital-transformation/","digital transformation",{"text":508,"config":509},"セキュリティとコンプライアンス",{"href":137,"dataGaName":138,"dataGaLocation":459},{"text":122,"config":511},{"href":105,"dataGaName":106,"dataGaLocation":459},{"text":513,"config":514},"アジャイル開発",{"href":515,"dataGaName":516,"dataGaLocation":459},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":518,"config":519},"クラウドトランスフォーメーション",{"href":520,"dataGaName":521,"dataGaLocation":459},"/ja-jp/topics/cloud-native/","cloud transformation",{"text":523,"config":524},"SCM",{"href":119,"dataGaName":525,"dataGaLocation":459},"source code management",{"text":109,"config":527},{"href":111,"dataGaName":528,"dataGaLocation":459},"continuous integration & delivery",{"text":161,"config":530},{"href":163,"dataGaName":531,"dataGaLocation":459},"value stream management",{"text":533,"config":534},"GitOps",{"href":535,"dataGaName":536,"dataGaLocation":459},"/ja-jp/solutions/gitops/","gitops",{"text":174,"config":538},{"href":176,"dataGaName":177,"dataGaLocation":459},{"text":179,"config":540},{"href":181,"dataGaName":182,"dataGaLocation":459},{"text":184,"config":542},{"href":186,"dataGaName":187,"dataGaLocation":459},{"text":544,"config":545},"教育",{"href":546,"dataGaName":547,"dataGaLocation":459},"/ja-jp/solutions/education/","education",{"text":549,"config":550},"金融サービス",{"href":551,"dataGaName":552,"dataGaLocation":459},"/ja-jp/solutions/finance/","financial services",{"title":194,"links":554},[555,557,559,561,564,566,570,572,574,576,578,580,582,584],{"text":206,"config":556},{"href":208,"dataGaName":209,"dataGaLocation":459},{"text":211,"config":558},{"href":213,"dataGaName":214,"dataGaLocation":459},{"text":216,"config":560},{"href":218,"dataGaName":219,"dataGaLocation":459},{"text":221,"config":562},{"href":223,"dataGaName":563,"dataGaLocation":459},"docs",{"text":244,"config":565},{"href":246,"dataGaName":247},{"text":567,"config":568},"お客様の成功事例",{"href":569,"dataGaLocation":459},"/customers/",{"text":239,"config":571},{"href":241,"dataGaName":242,"dataGaLocation":459},{"text":249,"config":573},{"href":251,"dataGaName":252,"dataGaLocation":459},{"text":262,"config":575},{"href":264,"dataGaName":265,"dataGaLocation":459},{"text":254,"config":577},{"href":256,"dataGaName":257,"dataGaLocation":459},{"text":267,"config":579},{"href":269,"dataGaName":270,"dataGaLocation":459},{"text":272,"config":581},{"href":274,"dataGaName":275,"dataGaLocation":459},{"text":277,"config":583},{"href":279,"dataGaName":280,"dataGaLocation":459},{"text":282,"config":585},{"href":284,"dataGaName":285,"dataGaLocation":459},{"title":300,"links":587},[588,590,592,594,596,598,600,604,609,611,613,615],{"text":307,"config":589},{"href":309,"dataGaName":302,"dataGaLocation":459},{"text":312,"config":591},{"href":314,"dataGaName":315,"dataGaLocation":459},{"text":320,"config":593},{"href":322,"dataGaName":323,"dataGaLocation":459},{"text":325,"config":595},{"href":327,"dataGaName":328,"dataGaLocation":459},{"text":330,"config":597},{"href":332,"dataGaName":333,"dataGaLocation":459},{"text":335,"config":599},{"href":337,"dataGaName":338,"dataGaLocation":459},{"text":601,"config":602},"Sustainability",{"href":603,"dataGaName":601,"dataGaLocation":459},"/sustainability/",{"text":605,"config":606},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":607,"dataGaName":608,"dataGaLocation":459},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":340,"config":610},{"href":342,"dataGaName":343,"dataGaLocation":459},{"text":350,"config":612},{"href":352,"dataGaName":353,"dataGaLocation":459},{"text":355,"config":614},{"href":357,"dataGaName":358,"dataGaLocation":459},{"text":616,"config":617},"現代奴隷制の透明性に関する声明",{"href":618,"dataGaName":619,"dataGaLocation":459},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":35,"links":621},[622,624,626,628,633,638,643],{"text":35,"config":623},{"href":37,"dataGaName":38,"dataGaLocation":459},{"text":368,"config":625},{"href":370,"dataGaName":371,"dataGaLocation":459},{"text":373,"config":627},{"href":375,"dataGaName":376,"dataGaLocation":459},{"text":629,"config":630},"ステータス",{"href":631,"dataGaName":632,"dataGaLocation":459},"https://status.gitlab.com/","status",{"text":634,"config":635},"利用規約",{"href":636,"dataGaName":637,"dataGaLocation":459},"/terms/","terms of use",{"text":639,"config":640},"プライバシーに関する声明",{"href":641,"dataGaName":642,"dataGaLocation":459},"/ja-jp/privacy/","privacy statement",{"text":644,"config":645},"Cookieの設定",{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":649},[650,652,654],{"text":634,"config":651},{"href":636,"dataGaName":637,"dataGaLocation":459},{"text":639,"config":653},{"href":641,"dataGaName":642,"dataGaLocation":459},{"text":644,"config":655},{"dataGaName":646,"dataGaLocation":459,"id":647,"isOneTrustButton":91},"content:shared:ja-jp:main-footer.yml","Main Footer","shared/ja-jp/main-footer.yml","shared/ja-jp/main-footer",{"allPosts":661,"featuredPost":833,"totalPagesCount":858,"initialPosts":859},[662,689,712,731,750,769,788,813],{"_path":663,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":664,"content":672,"config":682,"_id":685,"_type":14,"title":686,"_source":16,"_file":687,"_stem":688,"_extension":19},"/ja-jp/blog/developers-summit-2025-spring-event-report",{"title":665,"description":666,"ogTitle":665,"ogDescription":666,"noIndex":6,"ogImage":667,"ogUrl":668,"ogSiteName":669,"ogType":670,"canonicalUrls":668,"schema":671},"AI活用の鍵はGitLabの一貫したコンテクスト 【Developers Summit 2025 イベントレポート】","2025年2月、GitLabは「Developers Summit 2025」に出展しました。本イベントにてシニアソリューションアーキテクト 佐々木直晴が講演をおこないましたので、本記事にてその模様をレポートします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663625/Blog/Hero%20Images/3508_resized.jpg","https://about.gitlab.com/blog/developers-summit-2025-spring-event-report","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"AI活用の鍵はGitLabの一貫したコンテクスト 【Developers Summit 2025 イベントレポート】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-03-13\",\n      }",{"title":665,"description":666,"authors":673,"heroImage":667,"date":675,"body":676,"category":677,"tags":678},[674],"GitLab Japan Team","2025-03-13","本講演のテーマは、ソフトウェア開発の現場が抱えているAI活用の課題とその解決策です。シニアソリューションアーキテクト[佐々木直晴](https://gitlab.com/naosasaki)は「ソフトウェア開発の現場で、AI時代の新しいサイロが発生している」と考えています。本講演でその解決策として紹介しているのが、GitLabのAI機能群「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」です。\n\n## コードがどういう背景のもとで書かれたかといった情報までAIに与えるべき\n\n### 組織全体でコンテクストを共有することができているGitLabだからこそ持てたコンセプト\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_DSC1989_resized.jpg)\n*Developers Summit 2025での講演の様子*\n\n本講演における最初のブロックにて佐々木は、コードが書かれた背景に関する情報までAIに与えることが大切なのでは、と語りかけました。\n\nソフトウェア開発の現場でAIを使う際は、断片的なエラーコードのみ渡してその理由を探らせるなどします。しかしAIの可能性を引き出すには、そのコードがどういう背景のもとで書かれ、なぜそう決まったかという情報まで与えるべきです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_TOH3572_resized.jpg)\n*GitLab合同会社 シニアソリューションアーキテクト 佐々木直晴*\n\n佐々木はGitLabのAI機能群「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」は、こういったコンセプトを持っていると話しました。そうして、このコンセプトは「我々の会社だからもてたもの」と言います。\n\nGitLabはご存知のとおり、オフィスを持たずオールリモートの働き方を実践している企業です。オールリモートを実現するには、ドキュメントによるコミュニケーションが重要になります。\n\n経緯や議論をドキュメントとして残し、「なぜそう決まったか」も含め組織全体でコンテクストを共有する必要があるのです。オールリモートではメンバー間の誤解が生まれないように、記録に残るコミュニケーション技術が必要になります。\n\nそのうえで佐々木は「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)のコンセプトは、コンテクストを組織全体で共有できているGitLabだからこそ持てたものと思っている」と話しました。\n\n## AI時代の新しいサイロが発生した\n### 現在のソフトウェア開発において、AIの活用レベルは3段階に分類される\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit.jpg)\n次のブロックで佐々木は、現在のソフトウェア開発現場におけるAI活用の課題について説明しました。\n\nAIをソフトウェア開発に利用しているという会社は、2023年には64％だったところ、2024年には78％に上がっている* 状況です。今年の調査であれば、100％に近い数字になっていると想定されます。\n\nこのようにソフトウェア開発においてAIはデフォルトになっているものの、現場によって「段階がありレベル感が違う」と佐々木は話しました。活用レベルは大きく分けて3つにわけられ、各レベルで別々の課題が生じているのです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__1_.jpg)\n\nまず、ソースコードの生成にAIを活用するのが、活用レベル1です。「ここはかなりコモディティ化している」と佐々木は話しました。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__2_.jpg)\n\nソフトウェア開発の様々な局面で、AIを活用するのが活用レベル2です。たとえば以下のような利用があげられます。\n\n- 議論の内容をAIに要約させる\n- 会議の文字起こしをさせる\n- トラブルが起きたらAIにコードを渡して原因を解析させる\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__3_.jpg)\n活用レベル3は、局面に応じて優れたLLMを採用して使い分けている状態です。たとえばチケット管理はこのLLMを利用し、ソースコードの推奨はこのLLMにさせるといった使い分けをします。\n\n### AIの活用レベルごとに異なる課題が生じている\n\n佐々木は「我々はマーケットを見て、それぞれの活用レベルで課題があると思っている」と指摘しました。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__4_.jpg)\n「活用レベル1：ソースコードの生成にAIを活用」での課題は、AIが局所的な利用にとどまってしまっていることだと佐々木は指摘しました。\n\nソフトウェア開発のなかでも、ソースコードを記述している時間は21％に過ぎない* という調査結果があります。仕事場所がオフィスでも自宅でも、誰にも邪魔されず集中してコードを書ける日はなかなかありません。打ち合わせが入ったりメンバーのタスク管理をしたり、トラブルで呼び出されたりします。\n\nソースコードの記述にAIを使うこと自体はよいことです。しかしAI活用がソースコードの記述にとどまっているということは、AI活用が局所的な効率化に限定されているとも言えます。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__5_.jpg)\n「活用レベル2：ソフトウェア開発の様々な局面でAIを活用」は、AIをいろいろなシーンで使えていて一見素晴らしいように見えます。しかし、「いろいろなところに様々な機能のAIがあり過ぎて統一したいという意見が多い」と佐々木は指摘しました。\n\nソフトウェア開発にAIを使用する全世界の組織のうち、約74％は「ツールチェーンを統合したい」と答えたという調査結果があります。AIのライセンス費用や使い勝手の違いなどがあり、1つにまとめたいという課題が生じているのです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__12_.jpg)\n\n「活用レベル3：各局面に応じて優れたLLMを採用」は、一見良い状態にみえます。チケット管理やコーディングなど、それぞれのシーンで優れたAIを利用できているためです。\n\nしかし「それぞれのシーンで共有されたAIとのコンテクストが、コーディングのときに失われている」と佐々木は指摘しました。AIがそれぞれのツールに特化して閉じており、経緯や議論が個別のツールに取り残されてしまっているのです。\n\nAI間でのコンテクスト共有が不十分なので、コーディング段階でAIがいろいろな推奨をしてくれるものの、その内容には違和感が生じます。佐々木は「これはAI時代の新たなサイロだと我々は定義している」と話しました。\n\n## GitLabだからこそ提案できる、AI利用の課題に対する解決策 \n### GitLabにはソフトウェア開発用のプラットフォームとして必要な機能が一通りそろっている\n\n前項で紹介したAI利用の課題に対して、GitLabが提案するのがGitLabにおけるAI機能群「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」です。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は「オールリモートでコンテクストを共有しながら会社運営をする我々だからこそできる提案」と、佐々木は強調しています。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__6_.jpg)\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)の紹介をする前に、「そもそもGitLabとは何か」について佐々木が説明しました。\n\nGitLabではソフトウェア開発において、以下のような機能が必要と考えています。\n\nチケット管理をする機能、チケット管理のなかで詳細な議論ができる機能\nソースコードリポジトリ機能\nコミットしたら、自動的に何かをしてくれるCIの仕組み\nセキュリティスキャンなど\n\n「これら機能をばらばらに提供するのでなく、ひとつのプラットフォームとして提供するのがGitLab製品のコンセプト」と佐々木は説明しました。GitLabはソフトウェア開発に必要な機能を集約したDevSecOpsプラットフォームです。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__7_.jpg)\n\nこうした製品コンセプトが評価され、[2024  Gartner®  Magic  Quadrant™for  DevOps Platformsにおいて、GitLabが高く（画像の一番右上）に評価された](https://about.gitlab.com/ja-jp/blog/gitlab-named-a-leader-in-the-2024-gartner-magic-quadrant-for-devops/)ことを、佐々木は紹介しました。\n\n### 今までのAIはスポットで来てもらう助っ人、GitLab Duoは「勝手を知っているチームの一員」として働く\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__8_.jpg)\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__9_.jpg)\n\n前項で紹介したように、ソフトウェア開発にはいろいろな機能が必要になります。GitLabのAI「[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)」は、それら機能においてAIが同じコンテクストをもってサポートすると佐々木は解説しました。\n\nイシュー割り当てや議論要約、ソースコード生成、テストコードやテストケースの生成、また実装から詳細な説明用の資料を生成するなどの工程を、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は一貫してサポートします。[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)はインターネットだけでなく、自社内のAIのゲートウェイを向けることにより自社のネットワークから出ずにAIを使えるのも強いと佐々木は強調しました。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を使えば、以下のような\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__10_.jpg)\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/2025-02-14_Developers_Summit__11_.jpg)\nDevSecOpsのループ全ての局面にAIの力をまぶすことができます。\n\n- 計画・議論\n- ロードマップ・スケジュール構築\n- イシューの作成・アサイン\n- 開発・検証\n- デプロイ\n- パフォーマンスのモニタリングとカイゼン\n\n佐々木は、「たとえて言うなら、今までのAIはスポットでちょっと来てもらう助っ人のようなものだった」と指摘しました。スポットの助っ人は、タスクの背景などは分かりません。限定的な情報のなかで、サポートをしなければならないのです。\n\nたとえば断片的なエラーだけ渡され「これは何か」と聞かれても、AIは与えられた情報のなかで提案を返すしかありません。佐々木は「AIは本当ならもっとできるはず、というのが我々の思いだ」と強調しました。\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_TOH3594_resized.jpg)\n一方GitLab Duoは、「勝手の知っているチームの一員として働く」と佐々木は指摘しています。GitLabを使えば、ソフトウェア開発におけるものづくりの全ての作業を同じプラットフォーム内で実行することが可能です。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、これらGitLabにおける活動を多く把握しています。たとえば、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、ソースコードの内容を変更した背景や流れを理解しているわけです。そのため、そのソースコードをプッシュしてCIで失敗したら、GitLab Duoはより深く原因の分析をおこなえます。\n\nまたソフトウェア運用中に、深刻な脆弱性が見つかったとしましょう。このとき[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は「脆弱性に対応するには、リポジトリのこのファイルとこのファイルをこう直したらいいですよ」と提案してくれるのです。\n\nこのように局面をまたいだAIの使い方は、単一のデータストアがないとできないと佐々木は強調しました。リポジトリ・チケット管理・CI・セキュリティスキャンなどソフトウェア開発に必要な機能を、GitLabは全て有しています。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)は、GitLabのなかでこれら機能と同一プラットフォームに存在し、その全ての活動を把握しているわけです。それゆえに、スポットの助っ人でなくチームの一員として活躍することができます。\n\n最後に佐々木は、[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)を使ったデモを紹介しました。\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/_DSC2007_resized.jpg)\n本デモでは、CIが失敗した理由を[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)に調べさせています。そうするとGitLab Duoは、エラーログだけからは推察することが難しい関数や引数の型を使った修正例を提案しました。本デモでGitLab Duoは、デプロイが失敗した原因を、ソースコードの変更内容まで鑑みて分析しているのです。\n\nChatGPTにエラーログだけを渡して解析させるように、AIをスポットの助っ人として使うやり方であれば、コンテクストは共有されません。そのため、この修正例は出ないのではないかと佐々木は強調しました。\n\n[GitLab Duo](https://about.gitlab.com/ja-jp/gitlab-duo/)はトラブル発生時に、断片的なログから推奨を返すのでなく、過去の計画まで遡りなぜ失敗が起こったかというところまで助けてくれます。本講演の最後で佐々木は、開発者がより創造的な作業に集中できる環境を作りたいという思いでGitLabを提供させていただいていると語りました。\n\n＊参考元：[GitLab「2024 グローバルDevSecOpsレポート」](https://about.gitlab.com/ja-jp/developer-survey/?utm_medium=blog&utm_source=blog&utm_campaign=eg_apac_brand_x_x_ja_gitlabjapanblogseo_developers-summit-2025-spring-event-report) \n\n## 会場で配布したお土産について\n\n\u003Cimg src=\"https://res.cloudinary.com/about-gitlab-com/image/upload/v1752174658/Blog/a8q0fxpkysdomfbarvfj.jpg\">\n会場にて本講演のアンケートに答えて下さった参加者の方には、バレンタインデーのチョコとナノブロックをお渡ししました。このナノブロックは、GitLabのロゴがモチーフとなっています。かわいらしいこのロゴの形は、狸をイメージしていることはご存知でしたでしょうか？\n\n![デブサミ2025](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687627/Blog/Content%20Images/image5_resized.jpg)\n","devsecops",[280,9,679,680,681],"DevSecOps","DevSecOps platform","AI/ML",{"slug":683,"featured":91,"template":684},"developers-summit-2025-spring-event-report","BlogPost","content:ja-jp:blog:developers-summit-2025-spring-event-report.yml","Developers Summit 2025 Spring Event Report","ja-jp/blog/developers-summit-2025-spring-event-report.yml","ja-jp/blog/developers-summit-2025-spring-event-report",{"_path":690,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":691,"content":697,"config":706,"_id":708,"_type":14,"title":709,"_source":16,"_file":710,"_stem":711,"_extension":19},"/ja-jp/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"title":692,"description":693,"ogTitle":692,"ogDescription":693,"noIndex":6,"ogImage":694,"ogUrl":695,"ogSiteName":669,"ogType":670,"canonicalUrls":695,"schema":696},"GitLab Duo開発の現場から： AIモデルの大規模な検証とテスト方法","LLMをどのように評価し、ユースケースに適合させ、ユーザーにとってより良い回答が得られるように微調整しているのか。その舞台裏をご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659856/Blog/Hero%20Images/blog-hero-banner-1-0178-820x470-fy25.png","https://about.gitlab.com/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Duo開発の現場から： AIモデルの大規模な検証とテスト方法\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Susie Bitters\"}],\n        \"datePublished\": \"2024-05-09\",\n      }",{"title":692,"description":693,"authors":698,"heroImage":694,"date":700,"body":701,"category":702,"tags":703,"updatedDate":705},[699],"Susie Bitters","2024-05-09","**_生成系AIは、ソフトウェア開発業界における重要な変化であり、ソフトウェアの開発、保護、および運用を容易にします。この新しいブログシリーズでは、GitLabの製品チームとエンジニアリングチームが、必要なAI機能をエンタープライズ全体に統合し、どのように作成、テスト、デプロイするかをご紹介します。GitLab Duoの新機能によってDevSecOpsチームがお客様にどんな価値をもたらせるようになるか、見ていきましょう！_**\n\nGitLabは、お客様からの信頼を大切にしています。信頼を維持するためには、[GitLab Duo](https://about.gitlab.com/gitlab-duo/) AI機能をどのように構築し、評価し、高品質を確保しているかについて透明性を持つことが重要です。GitLab Duo機能は多様なモデルセットを備えており、それによって幅広いユースケースをサポートし、顧客に柔軟性を提供しています。GitLabはデフォルトで、単一のモデルプロバイダのみに依存していません。現在、[Google](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/main/ai_gateway/models/vertex_text.py?ref_type=heads#L86)および[Anthropic](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/blob/main/ai_gateway/models/anthropic.py?ref_type=heads#L62)の基盤モデルを使用していますが、GitLab Duoのユースケースに適したモデルを継続的に評価しています。このブログでは、AIモデルの検証プロセスを詳しくご紹介します。\n\n>ライブデモ開催！ GitLab 17バーチャルローンチイベントで、AI主導のソフトウェア開発の未来を体験しませんか。[【今すぐ登録する】](https://about.gitlab.com/seventeen/)\n\n## LLMを理解する\n\n大規模言語モデル（LLM）は、プラットフォーム全体の多くのAI機能を強化する生成系AIモデルです。膨大なデータセットで訓練されたLLMは、直前の文脈に基づいて一連の流れの中で次の単語を予測します。入力プロンプトが与えられると、プロンプトに条件付けられた単語の確率分布からサンプリングすることで、人間が書いたようなテキストを生成します。\n\nLLMは、インテリジェントなコード提案、会話型チャットボット、コード説明、脆弱性分析などを可能にします。特定のプロンプトに対して多様な出力を生成する能力があるため、標準化された品質評価が困難です。LLMはさまざまな特性に合わせて最適化できるので、多くのAIモデルが積極的に開発されています。\n\n## 大規模なテスト\n\nインプットとアウトプットがより簡単に定義され、テストできる従来のソフトウェアシステムとは異なり、LLMは、微妙で、また多様でもあり、文脈に依存するアウトプットをよく生成します。これらのモデルをテストするには、品質が主観的で変わりやすいことや、アウトプットがの確率的に変動することを考慮した包括的な戦略が必要です。したがって、LLMのアウトプットの質を個別にまたは経験に基づいて判断するのではなく、LLMの全体的な動作パターンを調べる必要があります。これらのパターンを理解するには、大規模なテストが必要です。大規模なテストとは、膨大で多様なデータセットやユースケースにわたるシステムやアプリケーションのパフォーマンス、信頼性、堅牢性を評価するプロセスを指します。当社の[集中評価フレームワーク（CEF）](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/)は、数十のユースケースに結びついた何千ものプロンプトを利用することで、重要なパターンを特定し、基礎となるLLMとそれらが統合されているGitLab Duo機能の全体的な動作を評価できます。\n\n大規模なテストによって、次のような効果があります。\n\n- __品質を確保する：__ 大規模なテストを行うことで、さまざまなシナリオやインプットでこれらのモデルの品質と信頼性を評価できます。大規模にモデルの出力を検証することにより、パターンを特定し、体系的なバイアス、異常、不正確さなどの潜在的な問題を軽減できます。\n- **パフォーマンスの最適化：** テストをスケールアップすることで、GitLabは実際の条件下でLLMのパフォーマンスと効率を評価できます。これは、アウトプット品質、レイテンシー、コストなどの要因を評価し、GitLab Duo機能に組み込まれたこれらのモデルを最良の状態に保つ作業を指します。\n- **リスクを軽減する：** LLMを大規模にテストすれば、重要なアプリケーションにLLMをデプロイする際のリスクを軽減できます。さまざまなデータセットやユースケースで徹底的なテストを実施することで、潜在的な故障モード、セキュリティの脆弱性、倫理的懸念を特定し、顧客に影響を与える前に対処できます。\n\nGitLabプラットフォーム内でのデプロイの信頼性と堅牢性を確保するには、LLMの大規模なテストが不可欠です。GitLabは、さまざまなデータセット、ユースケース、シナリオを含む包括的なテスト戦略に投資することにより、潜在的なリスクを軽減しながら、AIを活用したワークフローの可能性を最大限引き出すようにに取り組んでいます。\n\n### 大規模にテストする方法\n\nLLMを大規模にテストする手順は次のとおりです。\n\n#### ステップ1 ：本番環境用プロキシとしてプロンプトライブラリを作成する\n現在、他社はAIをトレーニングするために顧客データを表示して使用していますが、GitLabは使用していません。 その結果、本番環境での規模でさまざまな操作ーを模倣する包括的なプロンプトライブラリーを開発する必要がありました。\n\nこのプロンプトライブラリは質問と回答で構成されています。質問は本番環境で実際にあるようなクエリやインプットで、回答はグラウンドトゥルース（理想的な回答の基準）を表します。このグラウンドトゥルースは、目標とする回答として考えることができます。質問も回答も人間が生成した可能性がありますが、必ずしもそうではありません。このような質問と回答の組み合わせから、比較基準や参照フレームができあがり、モデルや機能間の違いを明らかにできます。複数のモデルが同じ質問を受け、異なる回答を生成する場合、グラウンドトゥルースを使用して、実際の回答に最も近いものを提供したモデルを決定し、それに応じてスコアを付けることができます。\n\nここでも、包括的なプロンプトライブラリーの重要な要素は、必ず本番環境で実際ありうるインプットに最も近いものとなるということです。私たちは、基盤となるモデルが特定のユースケースにどの程度適合していて、また自分たちの機能がどの程度うまく機能しているかを知りたいのです。多数のベンチマークプロンプトデータセットがありますが、これらのデータセットは、GitLabにある機能のユースケースを反映していない可能性があります。当社のプロンプトライブラリは、GitLabの機能やユースケースを対象に設計されています。\n\n#### ステップ2 ：ベースラインモデルのパフォーマンス\n\n本番環境のアクティビティーを正確に反映するプロンプトライブラリを作成したら、これらの質問を[さまざまなモデル](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/foundation_models/)に入力して、顧客のニーズをどの程度満たしているかをテストします。\n\n各回答をグラウンドトゥルースと比較し、以下のような一連のメトリクスに基づくランキングを提供します：[コサイン類似度スコア](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#similarity-scores)、[クロス類似度スコア](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#cross-similarity-score)、[LLMジャッジ](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#llm-judge)、[LLMジャッジによるコンセンサスフィルタリング](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/#consensus-filtering-with-llm-judge)。この最初のイテレーションは、各モデルがどの程度うまく機能しているかのベースラインを提供し、機能の基盤となるモデルの選択の指針となります。簡潔に説明するため、ここでは詳細に触れませんが、[メトリクスの詳細についてはこちら](https://about.gitlab.com/direction/ai-powered/ai_framework/ai_evaluation/metrics/)をご覧ください。これはまだ解決された問題ではないのでご注意ください。広範囲にわたるAI業界は、新しい技術の研究と開発を積極的に行っています。GitLabのモデル検証チームは、業界の動向を把握し、GitLab Duoが使用するLLM測定やススコアリング方法を継続的に改善しています。\n\n#### ステップ3 ：機能開発\n\n選択したモデルのパフォーマンスのベースラインができたので、自信を持って機能を開発できます。プロンプトエンジニアリングは多くの話題を呼びますが、検証を行わずにプロンプト（またはその他の手法）を介してモデルの動作を変更することだけに焦点を当てると、暗闇の中で作業しているようなものとなり、プロンプトを過剰適合させる可能性が非常に高くなります。1つの問題を解決することはできても、それ以上の問題を引き起こしてしまいます。何が起こるかは分かりません。モデルのパフォーマンスのベースラインを作成することで、必要なすべてのユースケースで時間の経過とともにどのように行動が変化しているかを追跡できます。GitLabでは、アクティブな開発中に機能のパフォーマンスを日々再検証し、すべての変更が全体的な機能性を確実に向上させるようにしています。\n\n#### ステップ4 ：何度も繰り返す\n\nここでは、実験的イテレーションの仕組みを説明します。各サイクルで、大規模なテストのスコアを調べてパターンを特定します。\n\n- 最も弱い分野の共通点は何ですか？\n- 特定のメトリクスや特定のユースケースに基づいた機能でパフォーマンスが低下していますか？\n- 特定の種類の質問に対して一貫したエラーが表示されていますか？\n\n大規模なテストを行ってこそ、このようなパターンが浮き彫りになり、実験に集中できるようになります。これらのパターンに基づいて、特定の分野や特定のメトリクスでパフォーマンスを向上させるさまざまな実験やアプローチを提案します。\n\nしかし、大規模なテストは高価で時間がかかります。より高速で低コストのイテレーションを可能にするために、ミニプロキシとして機能する小規模なデータセットを作成します。焦点を絞ったサブセットには、改善したいと考えている質問と回答の組み合わせが含まれるように重み付けをします。一方、より広範なサブセットには、変更が機能全般に悪影響を及ぼしていないかを確認するために、他のすべてのユースケースとスコアのサンプリングも含まれます。変更を加えて、焦点を絞ったデータのサブセットに対して実行します。新しい回答はベースラインと比較してどうでしょう？グラウンドトゥルースと比較するとどうでしょうか？\n\n焦点を絞ったサブセットで取り組んでいる特定のユースケースに対応するプロンプトが見つかったら、機能の他の分野に悪影響を与えないようにするために、より広範なデータのサブセットに対してそのプロンプトを検証します。新しいプロンプトが検証メトリクスによりターゲット領域でのパフォーマンスを向上させ、それ以外の領域でのパフォーマンスを低下させないと確信した場合にのみ、その変更を本番環境にプッシュします。\n\n集中評価フレームワーク（CEF）全体が新しいプロンプトに対して実行され、前日のベースラインと比べて機能全体のパフォーマンスが向上したかを検証します。このようにして、GitLabは常にイテレーションを行い、GitLabエコシステム全体でAIを使用した機能の最新かつ最高のパフォーマンスを確保しています。これにより、より迅速に、協力ながら作業を続けられます。\n\n### GitLab Duoをさらに優れたものにするために\n\nGitLab Duoの機能開発にどのくらい責任を持って取り組んでいるのかご理解いただいていると幸いです。このプロセスは、[GitLab Duoコード提案](https://docs.gitlab.com/ee/user/project/repository/code_suggestions/)と[GitLab Duoチャット](https://docs.gitlab.com/ee/user/gitlab_duo_chat.html)を一般提供したことにより開発されました。また、GitLab Duoの機能をイテレーションする際に、この検証プロセスを開発プロセスに統合しました。さまざまな試行錯誤があり、1つを修正したと思えば別の3つで問題が発生するというようなことがよくありました。しかし、そのような影響についてデータに基づいたインサイトがあり、GitLab Duoが常に改良されているという確信材料となっています。\n\n\u003Cbr>\n\n*監修：大井 雄介 [@yoi_gl](https://gitlab.com/yoi_gl)\n（GitLab合同会社 ソリューションアーキテクト本部 本部長）*\n\n>今すぐ[【GitLab Duoの無料トライアル】](https://about.gitlab.com/gitlab-duo/#free-trial)を始めましょう。\n\n## 「GitLab Duo開発の現場から」シリーズをもっと読む\n\n- [GitLab Duo開発の現場から：AIモデルの大規模な検証とテスト方法](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale/)\n- [GitLab Duo開発の現場から：AIインパクト分析ダッシュボードによるAIのROI測定](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-ai-impact-analytics-dashboard-measures-the-roi-of-ai/)\n- [GitLab Duo開発の現場から：GitLabにおけるAI機能のドッグフーディングの取り組み](https://about.gitlab.com/ja-jp/blog/developing-gitlab-duo-how-we-are-dogfooding-our-ai-features/)\n- [GitLab Duo開発の現場から：AI生成コードの安全性確認と詳細なテスト](https://about.gitlab.com/ja-jp/blog/how-gitlab-duo-helps-secure-and-thoroughly-test-ai-generated-code/)\n\n ## リソース\n- [GitLab AI Transparency Center](https://about.gitlab.com/ai-transparency-center/)\n- [GitLabの製品開発におけるAI倫理原則](https://handbook.gitlab.com/handbook/legal/ethics-compliance-program/ai-ethics-principles/)\n- [GitLab AIを活用したディレクションページ](https://about.gitlab.com/direction/ai-powered/)\n\n\u003Cfigure class=video_container>\n\u003Ciframe width=560 height=315 src=\"https://www.youtube-nocookie.com/embed/LifJdU3Qagw?si=A4kl6d32wPYC4168\" title=\"YouTube video player\" frameborder=0 allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" allowfullscreen=\"\">\u003C/iframe>\n\u003C/figure>\n","ai-ml",[681,679,680,704,9],"features","2024-06-06",{"slug":707,"featured":91,"template":684},"developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale","content:ja-jp:blog:developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale.yml","Developing Gitlab Duo How We Validate And Test Ai Models At Scale","ja-jp/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale.yml","ja-jp/blog/developing-gitlab-duo-how-we-validate-and-test-ai-models-at-scale",{"_path":713,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":714,"content":720,"config":725,"_id":727,"_type":14,"title":728,"_source":16,"_file":729,"_stem":730,"_extension":19},"/ja-jp/blog/event-report-devopsdive2024summer",{"title":715,"description":716,"ogTitle":715,"ogDescription":716,"noIndex":6,"ogImage":717,"ogUrl":718,"ogSiteName":669,"ogType":670,"canonicalUrls":718,"schema":719},"DevOpsDive2024 Summerで、ソフトウェア開発におけるセキュリティを考える【イベントレポート】","2024年6月12日に開催した「GitLab DevOpsDive2024 Summer」のイベントレポートをお届けします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665902/Blog/Hero%20Images/heroimage_devopsdive.jpg","https://about.gitlab.com/blog/event-report-devopsdive2024summer","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevOpsDive2024 Summerで、ソフトウェア開発におけるセキュリティを考える【イベントレポート】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-10-07\",\n      }",{"title":715,"description":716,"authors":721,"heroImage":717,"date":722,"body":723,"category":677,"tags":724},[674],"2024-10-07","2024年6月12日、GitLabはGINZA SIXの地下にある観世能楽堂において国内で3回目のプライベートイベント「DevOpsDive2024 Summer」を開催しました。本イベントは、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)／[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)にかかわる人々が集い、集合知を作りたいという思いでスタート。今回のテーマは「ソフトウェア開発におけるセキュリティを考えよう」に設定しました。能楽専門の公演場を会場に、登壇者が足袋を履いて能舞台で話をするという演出は、デベロッパー界隈を少し賑わしたようなので、イベントがあったことを知っている読者の皆様もいらっしゃるかもしれません。このブログでは、当日の模様をお伝えします。\n\n## シフトレフトでサイバー攻撃に立ち向かう\n\nこの日は、6月ながら都内で気温が30度を超える真夏日になりました。アイスブレイクに登壇した川口 修平は、「暑い中、激アツなイベントへようこそ」と会場を沸かせ、「終了後の懇親会ではオリジナルビールで乾杯しましょう！」と呼びかけました。ビールは[GitLabのイシュー](https://docs.gitlab.com/ee/user/project/issues/)を使って醸造所の担当者とやり取りしながら作り上げたものです。\n\n*![商品名：Gitlab Hazy Gen3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/instagram.jpg)\n[イシューを使って作り上げたビールの紹介（Instagram）](https://www.instagram.com/p/C8bZdKEylKM/?utm_source=ig_web_copy_link&igsh=MzRlODBiNWFlZA==)*\n\nこのように親しみやすい雰囲気で始まったイベントですが、日本において[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)はまだまだこれから。実際に、『DX白書』でも北米の[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)利用率52.9％に対し、日本は9.3％にすぎません。このギャップを埋めるためには、サイバーセキュリティの現状を正しく理解し、それと対峙するためのソフトウェア開発について考えておく必要があります。\n\n1人目の登壇者となった[タニウム合同会社 ](https://www.tanium.jp/)Chief IT Architect 楢原 盛史氏は、「見えないものは守れません」と話します。現在、私たちが直面している主な脅威はランサムウェアとサプライチェーン攻撃で、脅威は脆弱性のある場所を起点に忍び込んできます。\n\n> 全社で1万台のPCを使っている企業は、平均20％が管理されていない“野良端末”であると言われています。そして、攻撃者はここを狙ってくるのです。\u003Cbr>\n> （楢原 盛史氏）\n\n![DSC4331](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4331.jpg)\n*タニウム合同会社 Chief IT Architect 楢原 盛史氏*\n\n同氏は、サイバー攻撃の対象は組織が管理するハードウェアにインストールされたすべてのソフトウェアであり、中でもセキュリティ対策が万全でない自社開発のソフトウェア、およびそれに組み込まれたOSSが狙われやすいと指摘します。実際に、OSSコードベースの80％に脆弱性が含まれると言われており、ソフトウェア・サプライチェーン攻撃では、主に[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)パイプラインが狙われます。\n\n実際に、昨今は大企業が攻撃されて被害に遭ったニュースが数多く報じられています。私たちは、被害者の金銭的損害や株価の暴落を目にしていますし、医療機関への被害は生命を危うくする事態に直結します。経営もこれらの事態を深刻に受け止めていますから、セキュリティへの投資はホットな話題になってきました。\n\nとはいえ、ほぼすべてのシステムはネットワークと切り離すことができません。完全に切り離されたシステムであっても、ファイルやデータのインポートを通じて外部と全く情報をやり取りしないことはないでしょう。実用性を重視する以上、完全なセキュリティを保つのは事実上不可能であると言っていいかもしれません。\n\nその中で、脅威に立ち向かうためには、シフトレフトの原則が大切になります。米国家情報長官室（ODNI）は、DevSecOpsが重要だと通達し、取り組みの必要性を強調しています。日本でも、デジタル庁が『セキュリティ・バイ・デザインガイドライン』を発行しました。そこでは、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)がセキュリティ品質を底上げできると明記されています。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)でセキュアな開発ライフサイクルを実現し、高速かつ頻繁なテストサイクルを回すことが、セキュリティを担保するひとつの答えになるのです。\n\n## 責任を自分に集中させて仕組みを作り、その後に分散する\n\n![DSC4608](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4608.jpg)\n*左よりCloudflare Japan株式会社 エバンジェリスト 亀田治伸氏、くら寿司株式会社 執行役員 DX本部長 中林 章氏、GitLab合同会社カントリーマネージャー小澤正治*\n\nイベントの後半は、3者の鼎談セッションになりました。[GitLab Japan](https://about.gitlab.com/ja-jp/) Country Manager小澤 正治をモデレーターに、[くら寿司株式会社](https://www.kurasushi.co.jp/) 執行役員 DX本部長 中林 章氏、および[Cloudflare Japan株式会社](https://www.cloudflare.com/ja-jp/) エバンジェリスト 亀田 治伸氏が登壇。話題は、くら寿司の[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)推進事例が中心になりました。\n\nくら寿司は、数ある回転寿司チェーンの中で、技術への投資による業務効率化を率先して実行してきた企業です。たとえば、食べ終えたお皿を自動的に洗い場まで流す仕組みである「水回収システム」を業界で初めて開発したことは有名で、寿司ロボットをいち早く回転寿司で導入するなど、その後も技術投資を続けて様々な作業工程の自動化とおいしさを追い求めています。デジタル投資にも積極的で、「くら寿司ならでは」のDXを推進中。様々なタッチポイントから流入する予約システムや、店舗のタッチパネル型オーダーシステムなどの強化／開発を進めています。現在は、「お客様サービスと事業活動のリアルタイム連携」を目指すフェーズにあります。\n\nただ、同社はそこに至るまでに本質的な課題を抱えていました。中林氏は、「プロセスが整備されておらず、成果物の紐づけ管理が不十分でした」と話します。戦略会議が2週間ごとに開催されるため、開発サイクルはそれに合わせる必要があります。開発プロセスを統合管理することも必要で、要件定義書やスケジュール、ソースコードのレポジトリといったすべての成果物および中間成果物を必要な人が必要なタイミングで入手できる環境を整える必要もありました。\n\n![DSC4593](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4593.jpg)\n*くら寿司株式会社 執行役員 DX本部長 中林 章氏*\n\nこの状況を抜本的に解決するために、中林氏は[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)という文化を取り入れることを決断。[GitLab Ultimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)を採用し、他社とは一味違うDXに向けて進み始めます。多くのB2C企業は、顧客に会員登録してもらってロイヤルティを高めていく方向性で顧客戦略を考えます。一方、くら寿司はインバウンド顧客など一過性の顧客も大切にしなければなりません。そのため、ロイヤルティ向上施策と一見さん施策の両面で、多数のプロジェクトを同時並行し、スピード感をもって進められるようになりました。戦略会議で進捗報告し、新規施策の提案と承認、および新たなニーズの把握と共有を行うプロセスもGitLabで最適化。短期サイクルを実現するバックアップ体制も整えました。\n\nセキュリティについてはどうでしょう。中林氏は、「“セキュリティが担保されている”とはどのような状態なのでしょう。静的／動的検査をすればセキュリティが担保できるわけではないですよね。そこで、私たちはプロセス、ルール、成果物のすべてが正しく管理されていることが大切であるという結論に達しました」と話します。\n\n> 経営者にセキュリティを完璧に理解してもらうことは難しいものです。ですから、まず責任を自分に集中させて、仕組みを作りあげることが大切。そして、その後に破壊します。つまり、責任を分散するわけです。\u003Cbr>\n（中林 章氏）\n\n[GitLab Ultimate](https://about.gitlab.com/ja-jp/pricing/ultimate/)は、この流れを実現できるプラットフォームです。ビジネスにおけるバックログを記録しておけば、それを部門や現場がプロダクトのバックログとして認識できます。要件定義書からスケジュール、ソースコードまで、すべてを一元的に管理できるGitLabがあれば、経営と現場をつなぐことができるのです。さらに、プロセスの中にセキュリティを担保する仕組みを組み込み、業務の中でセキュリティをチェック／実装できるようになります。\n\n![DSC4701](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4701.jpg)\n*Cloudflare Japan株式会社 エバンジェリスト 亀田 治伸氏*\n\n\u003Cbr>\n亀田氏は、くら寿司のリアルな現場の話を聞いて、次のような印象を持ったと語ります。\n\n> 多くの企業を見ていると、権限が属人化しているケースをよく見ます。スタートアップなどの少数精鋭組織ではそちらの方が合うのでしょうが、規模が大きくなると難しくなります。くら寿司さんが集中管理から分散管理へと移行させるやり方は理想的で、GitLabを使えば権限委譲をうまくやれることも体感的に理解できます。\u003Cbr> \n交通ルールを守れば、絶対に事故は起こりません。しかし事故は起きています。つまり、全員がまじめにルールを守らないのです。コンピュータが絡むデジタルにおいて、これは大きな教訓になりそうです。GitLabを使ってミスが起こりにくい仕組みを作ることが大切になるかもしれません。くら寿司さんはグローバル展開していますし、文化の違いも仕組み作りで乗り越えられる部分もあるでしょう。\u003Cbr>\n（亀田 治伸氏）\n\nくら寿司は、人々がデジタルに触れているタイミングをすべて機会としてとらえ、ビジネスに生かすという大きな目標に向かっています。グローバル展開を積極化させる中、セキュリティのルールが国・地域によって異なるという課題にも、すべての地域のメンバーが安心・安全に使えるデジタルを提供するという方向で一つひとつ解決しています。さらに、貴重なエンジニアを確保していけるような、楽しく働きやすい職場づくりを心がけ、エンジニアにとって心地よいカルチャーを育んでいきます。\n\nGitLabを使えば、経営と現場がつながり、グローバルでセキュリティを担保する仕組みが実現します。そしてGitLabは、風通しの良い文化の醸成にも寄与します。くら寿司はGitLabで多くの成果を得ながらDXを推進しています。GitLabを開発プラットフォームとしてビジネスを加速するくら寿司の今後にご注目ください。\n\n![DSC4937](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687886/Blog/Content%20Images/_DSC4937.jpg)",[280,9,679,680],{"slug":726,"featured":6,"template":684},"event-report-devopsdive2024summer","content:ja-jp:blog:event-report-devopsdive2024summer.yml","Event Report Devopsdive2024summer","ja-jp/blog/event-report-devopsdive2024summer.yml","ja-jp/blog/event-report-devopsdive2024summer",{"_path":732,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":733,"content":739,"config":744,"_id":746,"_type":14,"title":747,"_source":16,"_file":748,"_stem":749,"_extension":19},"/ja-jp/blog/event-report-japan-it-week-autumn",{"title":734,"description":735,"ogTitle":734,"ogDescription":735,"noIndex":6,"ogImage":736,"ogUrl":737,"ogSiteName":669,"ogType":670,"canonicalUrls":737,"schema":738},"Japan IT Weekレポート：AIがDevSecOpsを加速する。GitLabソリューションの現在地","2024年10月23～25日に開催されたJapan IT Weekにおいて、GitLabブースで実施したミニセミナーの内容をレポートします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665336/Blog/Hero%20Images/GitLab____.jpg","https://about.gitlab.com/blog/event-report-japan-it-week-autumn","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Japan IT Weekレポート：AIがDevSecOpsを加速する。GitLabソリューションの現在地\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-12-11\",\n      }",{"title":734,"description":735,"authors":740,"heroImage":736,"date":741,"body":742,"category":677,"tags":743},[674],"2024-12-11","GitLabは2024年10月23～25日、千葉・幕張メッセで開催された「Japan IT Week」に出展しました。今回はブース出展で、多くのお客様に来場いただき、[DevSecOp](https://about.gitlab.com/ja-jp/topics/devsecops/)sの価値とGitLabのソリューションについてお伝えすることができました。本稿では、ブースで開催したセミナーで、皆様にお伝えした内容をまとめて紹介します。\n\n![GitLabノベルティ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/GitLab______.jpg)\n*配布したGitLabノベルティ*\n\n## DevOpsからDevSecOps、シフトレフトへ\n\nGitLabのブースには、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)や[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)にそれほど詳しくない方や、いままさにスタートさせようという方もいらっしゃいます。そこで、私たちは多くのセッションで、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)から[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)に至る歴史についてお伝えするようにしています。今回も15分というわずかな時間の中で、一定のボリュームをこの解説に割くことにしました。\n\nすでに広く知られているように、[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)が生まれたのは、開発チームと運用チームが協力関係を築く方が、開発から運用に至るプロセスの効率化につながると期待されたためです。開発部門は、迅速に多種のソフトウェアを作りたいと考え、一方の運用部門は本番リリース後のリスクを懸念します。[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)は、両部門が対立するのではなく、仲良く目標に向かおうとする文化を醸成する考え方で、多くの組織がこれを取り入れて成功しました。\n\n![IT Week会場の様子](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/IT_Week_____.jpg)\n*会場の様子*\n\n[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)は、開発チーム＋運用チームの[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)に、Sec＝セキュリティ チームを加え、3つのチームが開発段階から協力することで全体最適を図ろうという考え方です。仲良く仕事に取り組む文化はもちろん必要ですが、セキュリティが加わることで大きく変わる部分があります。それが、シフトレフトと呼ばれるものです。\n\n開発から運用の流れは、一般的な作業工程表と同様に、左から右に流れるプロセスとして作図します。シフトレフトは、「左側に移動する」ことで、セキュリティチェックを前倒しで行う変革です。たとえば、開発が完了し、運用前にチェックするという工程では、セキュリティに不備が発見されれば手戻りが発生し、リリースが遅れます。そして、そのような状況は、開発コストが増えることにつながります。[DevOps](https://about.gitlab.com/ja-jp/topics/devops/)によって開発と運用は一連の流れになっているため、開発段階から随時セキュリティチェックを実施することで、プロセスの全体最適を図り、効率を高め、コストを下げ、プロジェクトのサイクルを高速化することができるのです。\n\nしかしながら、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)には多くの人がかかわり、複雑なプロセスを管理する必要があります。すべてを可視化し、最適化するためには、概念で理解するだけでは不可能で、その実現をサポートする“ツール群”が必要になります。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)をやりたいけれど、スタートするだけでも大変で、プロジェクトを回し続けるために[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)の管理に多大な労力がかかることになれば、本末転倒です。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)をひとつのプラットフォームとして実現するソリューションがあれば理想でしょう。GitLabは、まさにそんな[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のプラットフォームなのです。\n\nそして、GitLabは、AIを搭載することで、さらに多機能で開発・運用の生産性を高めるプラットフォームへと進化しています。今回、ブースセミナーで主にお伝えしたのは、進化し続けているAI機能についてです。\n\n![GitLab合同会社 営業本部 コマーシャル営業部 アカウントエグゼクティブ 皆川 弘貴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/GitLab_________________________________________.jpg)\n*GitLab合同会社 営業本部 コマーシャル営業部 アカウントエグゼクティブ 皆川 弘貴*\n\n## AIはDevSecOpsに何をもたらすか\n\nブースセミナーでは、[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)にAIを適用する価値についてわかりやすく表現するために、「AI DevSecOps 1.0と2.0の違い」として説明しました。\n\nAI DevSecOps 1.0は、コード生成の補助が主体になります。「こんなコードを、この言語で書きたい」というプロンプトを入力すると、AIが自動的にコードを生成してくれます。これがバージョンアップしてAI DevSecOps 2.0になると、プロセス全体の効率化のためにAIを活用します。開発ワークフローのさまざまな場面でAIがサポートしてくれるのです。\n\n1.0のAIはいわば「作業ロボット」ですが、2.0ではAIが「バディ（仲間、同僚）」になるようなイメージと言えばわかりやすいでしょうか。\n\n1.0の段階であっても、生産性の向上には重要な役割を担えます。コード生成に加えてバグの自動修正や、AIによる脆弱性の抽出もできるでしょう。中でも、オープンソースプロジェクトにおいて、コール先のさらにコール先までたどって脆弱性を発見する際にAIは大いに役立つでしょう。\n\n2.0はGitLabの目指しているところです。[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のリーダーとして、開発プロセス全体を効率化したいと考えているためです。そのため、1.0の中でもよりロボットに近い個別の機能を持つAIは、お客様が自由に選択できるようにしています。一方、ワークフローをまたいで動く「人間の意思」をサポートするAIは、GitLabというプラットフォーム側で用意します。\n\n近くリリースする予定の[GitLab Duo Workflow](https://about.gitlab.com/ja-jp/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development/)が、その第一歩です。このAIは、プロンプトを入れると応答してくれる、ロボットのように受動的なAIではありません。開発テーマを与えると、計画やタスク、コードなどをユーザーと一緒に考えて、提案してくれる能動的なAIなのです。本物のバディのようなAIとしてご利用いただきたいと考えています。\n\n## GitLabが進めているAI実装のいま\n\n[GitLab Duo Workflow](https://about.gitlab.com/ja-jp/blog/meet-gitlab-duo-workflow-the-future-of-ai-driven-development/)は、リリース後も進化を続け、理想の姿へと近づけていきます。では、GitLabはまさにいま、どこまでのAI機能を搭載しているのでしょう。最終日の特別セッションで、現在の「AI-powered DevSecOpsプラットフォーム」が搭載する機能の一部を紹介しました。\n\n開発チーム向けの機能としては、AI利用のコーディング補助機能[Code Suggestions](https://about.gitlab.com/ja-jp/solutions/code-suggestions/)が真っ先に挙げられるでしょう。そのほか、レビュー担当者を推奨してくれるSuggested Reviewers、マージリクエスト（MR）の際に加えられた変更内容の説明を自動記述するSummarize MR changes、MRの各レビューにおいて内容を要約するSummarize my MR reviews、必要なGitコマンドを教えてくれるHelp with Git commandsなども開発生産性を高めてくれるAIです。\n\n![GitLab合同会社ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト 小松原 つかさ](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/GitLab__________________________________________________.jpg)\n*GitLab合同会社ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト 小松原 つかさ*\n\nセキュリティ／運用チーム向けの機能としては、コードの説明を自動生成するExplain this codeが面白いでしょうか。デジタルに詳しくない経営幹部向け、CIO向け、もしくはエンジニア向けなど、対象読者がわかりやすいようにAIが説明文を作ってくれます。そのほか、脆弱性の説明をしてくれるExplain this vulnerability、MRにテストコードを自動で書いてくれるGenerate Tests in MRなども役立つでしょう。\n\n全体最適を図るAIとしては、イシューで議論された内容を要約するIssue Summaries、AIにチャット形式でイシューやエピックについての説明や要約を生成してもらうGitLab Chat、ソフトウェア開発ライフサイクル全体の生産性について過去の傾向の中から異常値を検出するValue streams forecastingなどが挙げられます。\n\nコード自動生成やコードレビューのように基本的な機能を用意する一方で、「GitLabはAIを使って[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)のライフサイクルすべてを効率化させる」よう進化しようとしている方向性はご理解いただけると幸いです。\n\n## 3社のパートナー様にもご講演いただきました\n\n今回は、パートナー様に壇上に立ってもらうセッションも用意し、それぞれに興味深い内容をお話いただくことができました。\n\n[株式会社ジークス](https://www.zyyx.jp/) 久保 仁詩氏からは、ユーザー／パートナーとして見たGitLabと他製品の違いについてご講演いただきました。GitLabは、企業レベルのプロジェクトに最適で、グループ、サブグループ、プロジェクトにより、案件ごとにサブグループを切って多層的な階層構造を作れます。ツール切り替え不要のオールインワンプラットフォームであるため、UIは包括的で多機能です。\n\n「他製品でもできることはありますが、顕著な違いがあるのはセキュリティ関連の機能群です。本来の意味で[DevSecOps](https://about.gitlab.com/ja-jp/topics/devsecops/)を実現できるプラットフォームであると言えるのは、GitLabの最大の価値でしょう」（久保氏）\n\n![SB C&S株式会社 佐藤 梨花氏](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/SB_C_S___________.jpg)\n*SB C&S株式会社 佐藤 梨花氏*\n\n[SB C&S株式会社](https://cas.softbank.jp/) 佐藤 梨花氏には、[Platform Engineering](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)について紹介いただきました。GitLabは[Platform Engineering](https://about.gitlab.com/ja-jp/solutions/platform-engineering/)を実現するツールの1つという位置づけではありますが、極めて好相性です。大規模／分散開発を行っているチームとの親和性が高く、インフラ自動化要素を備えます。ワンプラットフォームであり、サードパーティー連携が豊富な点も魅力です。\n\n「個人的に良いなと感じるのは、ぜんぶそろっているので小さく始めやすいところ。いきなり大きく始めるのはリスクが高いため。少しずつ始めて範囲を広げていくことを望む組織は多く、GitLabを選択しておけば、成功を積み重ねて適用範囲を拡大していけます」（佐藤氏）\n\n[株式会社サーバーワークス](https://www.serverworks.co.jp/) アプリケーションサービス部 遠藤 広也氏からは、AWS CodeCommitからGitLabへの移行についてお話いただきました。AWS CodeCommitは、7月に新規顧客受付を停止しました。既存ユーザーは利用し続けることができるものの、新機能開発が停止されたため、有力な移行先としてGitLabが注目されています。\n\n参考：[【徹底解説！】AWS CodeCommitからGitLabへの移行ガイド](https://about.gitlab.com/ja-jp/blog/ultimate-guide-to-migrating-from-aws-codecommit-to-gitlab/)\n\n移行にあたっては、AWS CodeCommitをGitLabにミラーリングするやり方が良さそうです。両プラットフォームを並行稼働させられるため、移行リスクは最小化されます。遠藤氏は、単なる移行にとどまらないGitLabを使う運用効率化メリットについて、2つの機能を紹介してくれました。\n\n遠藤氏は、「GitLabの環境で[Code Suggestion](https://about.gitlab.com/ja-jp/solutions/code-suggestions/)を使えば確実に生産性を高められます。また、GitLabでもAWS CodePipelineと容易に連携できます。AWS側でソースプロバイダー設定を変更するだけで、クラウド[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)をそのまま使えるのは魅力的です」と話しています。\n\n![GitLab合同会社 営業本部 コマーシャル営業部 アカウントエグゼクティブ 権 東彬](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687807/Blog/Content%20Images/GitLab________________________________________.jpg)\nGitLab合同会社 営業本部 コマーシャル営業部 アカウントエグゼクティブ 権 東彬\n",[280,9,679,680],{"slug":745,"featured":91,"template":684},"event-report-japan-it-week-autumn","content:ja-jp:blog:event-report-japan-it-week-autumn.yml","Event Report Japan It Week Autumn","ja-jp/blog/event-report-japan-it-week-autumn.yml","ja-jp/blog/event-report-japan-it-week-autumn",{"_path":751,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":752,"content":758,"config":763,"_id":765,"_type":14,"title":766,"_source":16,"_file":767,"_stem":768,"_extension":19},"/ja-jp/blog/event-report-japan-it-week-spring-1",{"title":753,"description":754,"ogTitle":753,"ogDescription":754,"noIndex":6,"ogImage":755,"ogUrl":756,"ogSiteName":669,"ogType":670,"canonicalUrls":756,"schema":757},"DevOpsからDevSecOpsへ: IT Week 2024 春イベントレポート【前編】","2024年4月末に東京ビッグサイトで開催されたJapan IT Weekで実施したセミナーの内容を下敷きに、GitLabの最新情報をお伝えします。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666522/Blog/Hero%20Images/_NYG2319.jpg","https://about.gitlab.com/blog/event-report-japan-it-week-spring-1","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevOpsからDevSecOpsへ: IT Week 2024 春イベントレポート【前編】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-07-04\",\n      }",{"title":753,"description":754,"authors":759,"heroImage":755,"date":760,"body":761,"category":677,"tags":762},[674],"2024-07-04","*今回から2回に分けて、2024年4月末に東京ビッグサイトで開催されたJapan IT Weekで実施したセミナーの内容を下敷きに、GitLabの最新情報をお伝えします。前編では、DevSecOpsの最新状況とGitLabの価値について、パートナー様やお客様のご意見を取り入れながら紹介していきます。*\n\n## DevOpsをより高品質にするPlatform Engineering\n\nアプリケーション開発のやり方は、テクノロジーの進化とともに変化し、最適化されていきます。変化のスピードは2000年代に入ると加速し、近年はより高まっているように感じられるのは、テクノロジーの進化と多様化が進んでいるためでしょう。その中で、いくつも最新ワードが流行し、消費されることになりますが、時代を象徴する言葉は永く私達の記憶に刻まれることになるでしょう。\n\nいま、注目を集めているワードは、どのようなものでしょう。[SB C&S株式会社](https://cas.softbank.jp/)の佐藤 梨花氏は、「Platform Engineering」を取り上げます。Platform Engineeringは、開発プラットフォームの硬直化を防ぐ概念。開発効率の高いプラットフォームをいち早く取り入れ、モダン化できる状況を整えることで、開発生産性と開発品質をどちらも向上させようとする考え方です。DevOpsを信頼性の高いものとして安定的に運用するために必要なものとして有名なのはSREですが、SREとは別のアプローチでDevOpsをより高速に回し、最適化し続けるものがPlatform Engineeringであると言えばわかりやすいでしょうか。\n\nPlatform Engineeringは、GitLabと相性が良いことも好印象です。[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)にSAST/DASTを組み込んだ自動化はもちろん、イシューとエピック、Wikiによる情報共有、そしてプロジェクトの状況を可視化するアナライズ機能など、GitLabはPlatform Engineeringの成功に必要なさまざまな機能を備えています。VSM（Value Stream Mapping）を使った成果測定手法も確立しつつあり、これからも注目されることになるでしょう。\n\nDevOpsをうまく回すための手法が、最新のワードとして取り上げられるのは興味深い事実です。DevOpsは、すでに「当たり前の存在」になったと言えるのかもしれません。[アジャイル開発](https://about.gitlab.com/ja-jp/solutions/agile-delivery/)と親和性が高いことで普及が後押しされたという側面はありますが、DevOpsの概念であるDevelopment＝開発とOperation＝運用が連携／協力して、フレキシブルかつスピーディに業務を遂行することで得られる価値が多くの企業で実証されたことも重要なポイントでしょう。\n\n![DSC2328_202404JapanITWeekYukiMurakami](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687928/Blog/Content%20Images/_DSC2328.jpg)\n*GitLab合同会社 営業本部 エンタープライズ営業部 シニア アカウントエグゼクティブ 村上 裕紀*\n\nDevOpsというワードが生まれた当初は、あくまでもコンセプトであり考え方にすぎなかったのですが、それを実現するツール群が提供されるようになったことで、そのコンセプトを実際のプロセスに適用できるようになりました。DevOpsの登場で、「できるだけ早く多くの機能を実装したい」という開発者たちと、「できるだけ安全かつ継続的に運用したい」という運用チームの立場の違いを吸収し、両者が連携して効率的にプロジェクトを進められるようになったのです。\n\nこの流れに乗ってGitLabも進化を続けています。[2023年にガートナーのマジック・クアドラント](https://about.gitlab.com/blog/gitlab-leader-gartner-magic-quadrant-devops-platforms/)において、DevOpsプラットフォームのリーダーに位置づけられ、フォレスター・リサーチのThe Forrester Waveでは唯一のリーダーポジションを得ています。開発、テスト、Deployのプロセスを自動化できるだけでなく、DevOpsの全プロセスを網羅する機能群を提供し、それらが有機的に結びついた開発生産性の高いプラットフォームとなっていることが評価されました。\n\n## DevOpsにセキュリティを組み込むDevSecOpsの価値\n\nDevSecOpsという最新のコンセプトは、[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)をDevOpsのプロセスに組み込むものです。[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)／コンプライアンスの重要性が高まり、“説明可能な”[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)が求められるいま、多くの日本企業が注目し、アーリーアダプターが成果を出し始めています。そして、GitLabはすでにDevOpsを超えてDevSecOpsを実現する機能を提供しています。\n\n「DevSecOpsを実現するツール」を調べると、多くの選択肢が目に止まるかもしれません。実際に、DevSecOpsを実現するために、活用できるツールにはさまざまなものがあります。ただ、その中でGitLabは唯一、「DevSecOpsをやりたければGitLabがあれば良い」という統合ソリューションを提供できるのです。開発者、セキュリティチーム、運用チームを一連のプロセスの中で統合できるのはGitLabだけです。\n\n「複数のツールを組み合わせてDevSecOpsをDIYで作る」やり方も可能ではありますが、その場合「DIYしたDevSecOpsの運用コスト」が必要になります。GitLabならそれが必要ないことは大きなメリットで、開発、テスト、Deployという一連のプロセスを自動化し、[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)を含めた開発プロセスすべてを管理できます。\n\nさらに、[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)機能として最も重視される脆弱性の早期検知においても、強力なエンジンを提供しています。この機能はテストプロセスの後に組み込まれ、開発してすぐテストするというDevOpsの流れをそのまま持ち込めば、開発者は自分の書いたコードや使用するライブラリに脆弱性が含まれるかどうかをすぐに理解することができます。計画段階においてはイシューに要件を付加しておけば、どのレベルの[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)が必要かどうかを振り返って判断することもでき、レビュー時に再確認することも容易です。自動化と人手による検証をどちらも可能にし、開発からリリースに至る全工程に[セキュリティ](https://about.gitlab.com/ja-jp/solutions/security-compliance/)を持ち込み、必要なところは自動化できるようになるのです。\n![DSC1407_202404JapanITWeekYoheiKawase](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687928/Blog/Content%20Images/_DSC1407.jpg)\n*GitLab合同会社 カスタマーサクセス本部 カスタマーサクセスマネジメント部 シニアカスタマーサクセスマネージャー 川瀬 洋平*\n\nひとつのプラットフォームでDevSecOpsを実現することで、ツールを連携させて運用するコストはなくなり、ライセンスコストも最小化します。GitLabのユーザーインタフェースは直感的で評価は高く、開発生産性は大きく向上します。自動化により、開発プロセスはスピードアップします。GitLabが外部委託した調査では、ユーザー企業が収益を生み出すアプリケーション開発プロセスおいて427％のROIを実現し、6か月未満で投資を回収できたことが明らかになりました。\n\nさらに、GitLabでは、DevSecOpsプロセスに[AI](https://about.gitlab.com/ja-jp/gitlab-duo/)を取り入れ、より強力にプロセスの効率化を支援しています。[AI](https://about.gitlab.com/ja-jp/gitlab-duo/)の進化、およびその使い方の熟成が進めば、数字として表面化する成果もより優れたものになると期待されています。\n\n## CI/CDでリリース1回あたりの作業時間を9分の1に\n\n最後に、日本ですでにDevSecOpsに取り組んでいる事例を紹介します。ブースセミナーに登壇した[株式会社キャラウェブ](https://www.chara-web.co.jp/) クラウドパートナーグループ 副部長 中山 桂一氏は、GitLabの導入支援を実施する立場からのコメントをいただき、[株式会社ジークス](https://www.zyyx.jp/) 新規事業開発室 久保 仁詩氏には自社での活用状況についてお話いただいています。\n\nジークスの久保氏が最も顕著な成果を得られたと感じているのは、[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)による自動化です。作業時間の短縮だけでなく、人為的ミスをなくすことにもCI/CDは役立っています。\n\n![DSC1773_202404 Japan IT Week Kubo san from ZYYX](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687928/Blog/Content%20Images/_DSC1773.jpg)\n*株式会社ジークス 新規事業開発室 久保 仁詩氏*\n\nリリースプロセスでは、まず手順書を準備し、モジュールを作成。ターミナルに接続してコマンドを実行する作業をサーバ台数分繰り返す必要がありました。これらをすべて開発者の手作業で実施していたころには、3人がそれぞれ30分をかける必要のあるプロセスで、実行コマンドの入力（手順書のコピー＆ペースト）ミスやリリース漏れなどのリスクがありました。\n\n[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)を導入すれば、これらのプロセスはすべて自動化されます。その結果、導入後には、1人の開発者が実行結果を確認するためにわずか10分の時間をかけるだけで済むようになりました。ジークスでは、スモールスタートで効果を確認し、[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)を採用するプロジェクトを拡大。現在はモバイル領域にも[CI/CD](https://about.gitlab.com/ja-jp/solutions/continuous-integration/)を適用し、月間平均80時間に相当する業務効率化を達成しました。さらに、リリースタイミングは月次や週次ではなく、1日に5回できるようになりました。\n\nキャラウェブの中山氏は、GitLabで開発プロセスを管理する価値は大きいと紹介してくれました。具体的には、マージリクエストの際に、自動的に脆弱性検査とライセンスチェック、コード品質検査を実施することで手戻りは最小限に抑えられます。9種のセキュリティテストを同時に走らせ、静的スキャンに加えて動的な脆弱性スキャンも実施することができます。マージ後に再度セキュリティテストを実行することで、安心できるセキュリティレベルを保証することも可能です。\n\n![DSC1811_202404JapanITWeekNakayamasan](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687928/Blog/Content%20Images/_DSC1811.jpg)\n*株式会社キャラウェブ クラウドパートナーグループ 副部長 中山 桂一氏*\n\n\u003Cbr>\nブースセミナーにパートナー様とお客様が登壇してくださったように、日本でもDevSecOpsは徐々に浸透してきています。アーリーアダプターからはすでに数多くの成功者が生まれています。これからもDevSecOpsの発展とGitLabにご注目ください。\n\n\u003Cbr>\u003Cbr>\n＜[後編を読む：DevSecOpsで人材問題は解決できるか](https://about.gitlab.com/ja-jp/blog/event-report-japan-it-week-spring-2/)＞",[280,9,679,680],{"slug":764,"featured":91,"template":684},"event-report-japan-it-week-spring-1","content:ja-jp:blog:event-report-japan-it-week-spring-1.yml","Event Report Japan It Week Spring 1","ja-jp/blog/event-report-japan-it-week-spring-1.yml","ja-jp/blog/event-report-japan-it-week-spring-1",{"_path":770,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":771,"content":777,"config":782,"_id":784,"_type":14,"title":785,"_source":16,"_file":786,"_stem":787,"_extension":19},"/ja-jp/blog/event-report-japan-it-week-spring-2",{"title":772,"description":773,"ogTitle":772,"ogDescription":773,"noIndex":6,"ogImage":774,"ogUrl":775,"ogSiteName":669,"ogType":670,"canonicalUrls":775,"schema":776},"DevSecOpsで人材問題は解決できるか: IT Week 2024 春イベントレポート【後編】","2024年4月末に東京ビッグサイトで開催されたJapan IT Weekで実施したセミナーの内容を下敷きに、GitLabの最新情報をお伝えするシリーズの「後編」です。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666515/Blog/Hero%20Images/_DSC1507.jpg","https://about.gitlab.com/blog/event-report-japan-it-week-spring-2","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"DevSecOpsで人材問題は解決できるか: IT Week 2024 春イベントレポート【後編】\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2024-07-18\",\n      }",{"title":772,"description":773,"authors":778,"heroImage":774,"date":779,"body":780,"category":677,"tags":781},[674],"2024-07-18","*2024年4月末に東京ビッグサイトで開催されたJapan IT Weekで実施したセミナーの内容を下敷きに、GitLabの最新情報をお伝えするシリーズの「後編」です。前編では、DevSecOpsの最新状況とGitLabの価値について紹介しましたが、今回は人材がテーマ。一見GitLabのソリューションと遠いところにあるように感じられるかもしれませんが、実はGitLabを活用してDevSecOpsを推進すれば、人材育成や人材確保を進めることができるのです。*\n\u003Cbr>\n[前編を読む:DevOpsからDevSecOpsへ\n](https://about.gitlab.com/ja-jp/blog/event-report-japan-it-week-spring-1/)\n## 開発者たちに気分良く仕事をしてもらうために\n\nデジタル化が急速に進んだ近年、デジタル人材の確保が困難になっていると言われるようになってきました。実際に、『DX白書2023』では、2022年度においてDXを推進する人材の「質」を確保できている企業はわずか6.1％にすぎず、大幅な不足を感じている企業が過半に上ります。2021年度がそれぞれ10.7％、30.5％であったことからも、年々人材の確保が厳しくなっていることがわかります。\n\n一方、米国においては人材が充足されつつあるようです。グローバルエコノミーの時代、人材を海外に求めるという手段はあるかもしれませんが、為替リクスは大きな足かせになります。日本において、デジタル人材はあらゆる業界から引く手あまたで、人材側が企業を選べる状況と言えるでしょう。\n\n人材にとっては喜ばしいでしょうが、企業にとっては切実な悩みです。そこで、この状況を解決するための1つの手段として、「デベロッパー・エクスペリエンス」を高めることに注目してみてください。\n\n![DSC2630_ToshiIto](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687917/Blog/Content%20Images/68A1C322-771B-4CA0-B996-73A58E7050BC_1_105_c.jpg)\n\n*GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト 伊藤 俊廷*\n\nデベロッパー・エクスペリエンスは、直訳すると開発者体験になります。最近あちこちで聞くカスタマー・エクスペリエンス＝顧客体験の開発者版と言えばわかりやすいでしょうか。これを向上させるカギは、デジタル人材たちに気分良く能力を発揮してもらう環境を整備すること。給与やオフィス環境、マシンスペックなどのハード面、文化とコミュニケーション、成長機会、低い認知負荷などのソフト面のどちらのアプローチも必要になります。\n\nただし、ハード面にはコストという制約があります。そこで、今回はソフト面においてデベロッパー・エクスペリエンスを向上させるという方向性について解説します。まずは、DevSecOpsと親和性の高いセキュリティ人材の体験向上から見ていきましょう。\n\n## DevSecOpsはセキュリティ人材の体験を高める\n\nデジタル人材の中でも、セキュリティ人材は最も確保が困難と言われる分野です。脅威は進化し続けている上に多様化し、常に最新の脅威について学び続ける必要もあります。[株式会社野村総合研究所](https://aslead.nri.co.jp/) プラットフォームサービス開発一部 宮原 俊介氏は、DevSecOpsによってセキュリティ人材の負担軽減と育成を期待できると考えています。\n\nDevSecOpsでは、シフトレフトの考え方を取り入れ、システム開発における設計、開発、テストというプロセスでもセキュリティ診断を実施します。これにより、単体テスト、統合テストといったアプリケーションの機能面のテストが完了してからセキュリティ診断をすることによる手戻りを抑制できます。\n\nそして、DevSecOpsというコンセプトが現実的になっているのは、それらのプロセスにおいて多様な自動化ツールが用意されている点にあります。従来型のやり方では、セキュリティ人材はセキュリティ診断と修正のレビューに忙殺されることになりますが、あらかじめセキュリティが担保されているアプリケーションに対して、最終チェックという形で専門的な診断を行う業務に注力できるようになるのです。\n\n![DSC1517_202404JapanITWeekImage](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687918/Blog/Content%20Images/_DSC1517.jpg)\n\nDevSecOpsを実現するためには、3つの要素があると言われています。それらは、技術、プロセス、および文化です。ここで文化がクローズアップされていることに着目してください。DevSecOpsでは、開発、運用、セキュリティの各チームが協力してサービス価値の最大化を図ります。ゴールは共通しているため、チーム間で継続的に改善・学習する体制が出来上がっています。これは、セキュリティ人材のデベロッパー・エクスペリエンス向上につながる継続的な学習機会と、有意義なコミュニケーションの機会を提供することにつながります。\n\n## GitLabで作り上げる文化がデベロッパー・エクスペリエンスに好影響\n\nセキュリティ人材を中心に見てきましたが、DevSecOpsは、セキュリティ人材だけでなく、あらゆるデジタル人材のデベロッパー・エクスペリエンスの向上に役立ちます。GitLabは、市場にある中で唯一“DevSecOpsプラットフォーム”と呼べる統合的なソリューションです。では、GitLabを使うことで、デベロッパー・エクスペリエンスの向上にどのように役立つのでしょうか。\n\nまずは、文化とコミュニケーションいう側面から見ていきましょう。GitLabは、開発構想を含めたすべての情報を一元管理する開発者のためのSSOTとして機能します。過去をすべて可視化できるだけでなく、現在の状況もリアルタイムに反映されていきます。開発者は、GitLab内でコミュニケーションを取ることができ、だれが何をやっているのかを理解しながら、自分のやるべきことを進めることができます。\n\n履歴がすべて残るため、口頭による指示で、言った／言っていないと論争になることはありません。指示がコロコロ変わっても、責任の所在は明確になります。これは、指示の内容について開発者が納得できる説明が必要になることと同義ですから、自然に開発プロジェクトとビジネス側の関係も良くなっていくでしょう。\n\n![NYG2321_202404JapanITWeekimage](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687917/Blog/Content%20Images/_NYG2321.jpg)\n\n成長機会では、手前味噌になりますがGitLabというデファクト・スタンダードを実際に仕事で使う経験を得られることは大きなメリットです。開発者は、「GitLabを使える」という市場価値の高いスキルを得ることができます。一見、開発者側にとって魅力的でも企業側からは離職リスクを高めるポイントに見えるかもしれませんが、市場から人材を調達しやすく、経験はなくてもポテンシャルの高い人材に魅力を感じてもらえるプロジェクトを展開できるというメリットが勝るはずです。\n\n低い認知負荷についても解説しておきます。GitLabは、DevSecOpsプラットフォームであり、DevSecOpsを実現する機能を包括的に提供しています。そのため、ポイントソリューションである各種ツールの使い方を個別に学習する必要がありません。「何をやりたいか」という本質的な理解があれば、GitLab内ですべてを完結させることができるのです。これは、開発者が“ツールの専門家”にならず、プロジェクト全体を見渡す視野を得られるという点において重要な要素です。\n\nさらに、自動化を加速できることも大きな価値を生みます。リリースの際に、モニターをターミナルで一杯にしながらサーバごとにコマンドを打ち込んだり、手順書からコピー＆ペーストしたりする必要はありません。こうした「スキルアップにつながらないものの、時間を使ってやらなくてはならない作業」を最小化することは、デベロッパー・エクスペリエンスに良い影響を与えてくれます。\n\n## 開発者の提案に寄り添う姿勢を\n\n最後に、ビジネス側やプロジェクトリーダーの方々に向けて、開発者のやる気を引き出すコミュニケーションをどうすれば良いかについて触れておきます。\n\n優秀な開発者は最新のテクノロジーを活用したがるものです。これに制約をかけると、彼らのモチベーションは維持できません。新規で必要な機能があり、その開発を依頼するケースで、最新のテクノロジーを使用したいと提案された場合、コストやセキュリティリスクなどを列挙し、無下に却下するのではなく、寄り添う姿勢を見せてください。\n\n緊急を要する案件でない限り、プロジェクトでそのテクノロジーを使えばどのようなメリットがあるか、コストはどれくらいかかるか、リスクはどこにあるか、という検証をする価値は大きいのです。その上で提案を却下したとしても、開発者が納得のいく説明をできれば、彼らは高いモチベーションを維持し、常に最新のテクノロジーにアンテナを張って次の提案を持ってきてくれるでしょう。その中に、ビジネスの価値を大きく飛躍させる種が眠っているかもしれません。\n\n![NYG2316_202404JapanITWeekimage](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687917/Blog/Content%20Images/_NYG2316.jpg)\n",[280,9,679,680],{"slug":783,"featured":91,"template":684},"event-report-japan-it-week-spring-2","content:ja-jp:blog:event-report-japan-it-week-spring-2.yml","Event Report Japan It Week Spring 2","ja-jp/blog/event-report-japan-it-week-spring-2.yml","ja-jp/blog/event-report-japan-it-week-spring-2",{"_path":789,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":790,"content":796,"config":807,"_id":809,"_type":14,"title":810,"_source":16,"_file":811,"_stem":812,"_extension":19},"/ja-jp/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"title":791,"description":792,"ogTitle":791,"ogDescription":792,"noIndex":6,"ogImage":793,"ogUrl":794,"ogSiteName":669,"ogType":670,"canonicalUrls":794,"schema":795},"GitLabにおける「Docs as Code」の5つのポイント","この記事では、GitLabのテクニカルライターがDocs-as-Codeワークフローを用いてGitLabをどのように利用しているのかを、5つのポイントに分けてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660257/Blog/Hero%20Images/pen.jpg","https://about.gitlab.com/blog/five-fast-facts-about-docs-as-code-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabにおける「Docs as Code」の5つのポイント\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suzanne Selhorn\"},{\"@type\":\"Person\",\"name\":\"Susan Tacker\"},{\"@type\":\"Person\",\"name\":\"Diana Logan\"}],\n        \"datePublished\": \"2022-10-12\",\n      }",{"title":791,"description":792,"authors":797,"heroImage":793,"date":801,"body":802,"category":803,"tags":804},[798,799,800],"Suzanne Selhorn","Susan Tacker","Diana Logan","2022-10-12","\n\nGitLabでは、「Docs-as-Code」ワークフローを使うことで、単一のプラットフォームとしてGitLabを使ってGitLabのドキュメントを作成・管理しています。少しわかりづらいでしょうか？\n\nGitLabのテクニカルライティングチームは、GitLabを使って[GitLabドキュメント](https://docs.gitlab.com/)の計画、作成、レビュー、編集、公開までを一貫して行っています。Docs-as-Codeワークフローを導入することで、熱意ある少人数の効率的な備えたチームで膨大な量のコンテンツを生み出すことが可能になっています。\n\nDocs-as-Codeに馴染みがない方のために、簡単にご説明します。\n\n[Docs-as-Code](https://idratherbewriting.com/trends/trends-to-follow-or-forget-docs-as-code.html#what-is-docs-as-code)とは、製品ドキュメントの開発や公開を、ソフトウェアコードの開発と同じツールやプロセスを用いて行う手法です。ドキュメントファイルはコードファイルと同じリポジトリで管理され、バージョン管理も可能です。\n\nご自身が所属する組織でGitLabにDocs-as-Codeワークフローを採用できるか気になっている場合は、ぜひこの記事を読み進めてください。GitLabチームが実践している5つの方法をまとめてご紹介します。\n\n## GitLabを使ってGitLabの機能とドキュメントの更新を計画\n\nプロダクトマネージャー、UXデザイナー、エンジニア、品質管理チームは連携して機能の開発計画を立てます。リリースを計画する際に、Kanbanボードを使ったり、サードパーティのツールでイシューを作成したりするチームも多いかと思います。\n\nGitLabでは、エピックとイシュー[イシュー](https://gitlab.com/gitlab-org/technical-writing/-/issues/680)を使って作業計画を立て、[イシューボード](https://gitlab.com/groups/gitlab-org/-/boards/4340643?label_name%5B%5D=Category%3ADocs%20Site)を用いて進捗を管理します。GitLabでは透明性を重視しているため、計画に関するディスカッションも含め、こうした情報には誰もがアクセスできるようになっています。そのため、テクニカルライティングチームは開発の進行状況をいつでも把握できる環境にあります。\n\n![イシューの計画](https://about.gitlab.com/images/blogimages/planning_issue.png)\n\n大規模なドキュメント作業を行う場合、その進捗をGitLabで管理し、変更はGitLabを使用して行い、イシューが完了したらGitLabで完了マークを付けます。1年後に変更の理由を振り返りたい場合、GitLabで検索すれば、誰がどのような理由で変更を加えたのかを確認できます。現在、複数のツールを使って作業している方は、一度にすべてを一元的に管理できる環境を想像してみてください。より迅速かつ効率的に作業を進められると思いませんか？通常ならメールやウェブサイト、Slackを見て回って見失ったディスカッションを探すのに時間を費やしていたかもしれませんが、それがすべてGitLabに集約されているため、無駄な時間を省けます。\n\nもしWikiを愛用していて、不可欠だという場合でもご安心ください。GitLabにはWiki機能も備わっています。\n\n## GitLabを使ってドキュメントのフィードバックをやりとり\n\nライターとして一定の経験がある方なら、コンテンツのレビューを依頼する際の手間をよくご存じでしょう。\n\nGitLabでは、デベロッパーがすべての新機能に関するコンテンツの初稿を作成します。そして、そのコンテンツはコードと同じリポジトリに保存されます。機能に関するドキュメントは、GitLabの開発プロセスにおける「完了の定義（DoD）」の一部です。デベロッパーはその初稿をライターに割り当て、ライターはそれをレビューし、提案を加え、アイデアや必要な編集内容を作成者であるライターに返します。\n\nライター自身もコンテンツの変更を行う場合は、マージリクエスト（MR）を作成します。MRを作成するのがライターであれ、デベロッパーであれ、サポートエンジニアであれ、コミュニティのコントリビューターであれ、誰でもお互いの作業に簡単にコメントできる仕組みになっています。\n\nマージリクエストでは、「提案」ボタンを選択するだけで簡単にコメントできます。1行、または複数行単位でコメントを付けることができ、変更や編集を提案できます。MRを作成した本人は、その変更を簡単に適用したり、別の提案を作成し議論したりできます。他のユーザーを会話に招待するには、コメントにユーザー名を入力します。すると、相手にコメントがGitLabのTo Doアイテムとして表示されます。このようにして、あらゆる変更について議論でき、透明性があり、誰もが参加できる環境が整っています。\n\n![提案](https://about.gitlab.com/images/blogimages/suggestion.png)\n\nドキュメントの内容はMarkdown形式で記述されており、プレーンテキストに似ているため、ファイルのバージョン間の違いを簡単に確認でき、誰がどの変更をコミットしたのかも把握できます。\n\nPDFやWordドキュメント、Googleドキュメントでコメント機能を使ってレビューを行った経験がある方も多いでしょう。このワークフローを試すと、どれだけ効率的に作業が進むかを実感できるはずです。古いバージョンのドキュメントが使われることもなく、誰かのコメントを意図せず削除してしまうようなこともありません。\n\nまた、変更の理由を知りたい場合も、ページの履歴を簡単に確認でき、特定の行について誰が「担当者」であるかもすぐに確認できます。\n\n![担当者の表示](https://about.gitlab.com/images/blogimages/blame.png)\n\n複数のバージョンのPDFドキュメントを管理したり、誰がどの変更を提案したのかを探したりする必要はもうありません。すべての管理がGitLab内で完結するため、手間が省けます。\n\n## GitLabを使ってドキュメントの内容をプレビュー\n\nGitLabでは、ドキュメントサイトのコンテンツをローカルで生成するツールを提供していますが、マージリクエストから直接ドキュメントサイトを簡単に共有することもできます。新しいアイデアを試していて、それを誰かに見せたい場合は、マージリクエストを開き、「アプリレビュー」を生成すると、変更されたドキュメントサイトを公開URLで確認できるようになります。\n\n![アプリレビュー](https://about.gitlab.com/images/blogimages/view_app.png)\n\n変更内容を確認でき、イテレーションを行うことも、そのままコミットすることも可能です。次にこれに関連する、GitLabの便利な機能をもうひとつご紹介します。\n\n## GitLabを使ってすべてのコンテンツの変更をテスト\n\nドキュメント内のリンクをテストしたり、スペルや文法のルールを確認したりするために、サードパーティーのツールが使っている方も多いかと思います。\n\nGitLabでは、Nanoc（リンクのテスト用）やVale（スペル・文法の確認用）などのサードパーティツールを使用していますが、これらのツールもGitLabに統合でき、ライターのワークフローにも組み込むことができます。\n\n各ライターは、自身のローカル環境でこれらのツールを使用し、ドキュメントの読解レベルや文法修正などをすべて確認できます。これらのツールを持っていないコントリビューターには、パイプラインで自動的にテストを実行し、すべてのコミットに対して結果を表示する仕組みを導入しています。\n\n![Lintエラー](https://about.gitlab.com/images/blogimages/lint_error_2.png)\n\nデベロッパーとして、文章の専門知識に自信がない場合、マージリクエストのパイプラインで重要な文法やブランディングルールに従っていないために処理が進まないことがあります。GitLabでは、さまざまなルールを定め、それぞれに優先順位を付けています。そのため、[スタイルガイド](https://docs.gitlab.com/ee/development/documentation/styleguide/)や[単語リスト](https://docs.gitlab.com/ee/development/documentation/styleguide/word_list.html)を用意しているだけでなく、テストを実行してコンテンツがそうしたルールに沿ったものになっているかを確認しています。\n\n## GitLabを使ってHTML出力を生成し、その出力をGitLab Pagesでホスト\n\nGitLabのCI/CDパイプラインは、Markdown形式のコンテンツをHTMLに変換してコンパイルします。その後、出力内容をGitLab Pagesを介して、[docs.gitlab.com](http://docs.gitlab.com)にホストします。\n\n![パイプライン](https://about.gitlab.com/images/blogimages/pipeline2.png)\n\nパイプラインによって出力を生成することで、必要なときにいつでもドキュメントサイトを更新できます。製品は月に一度リリースされますが、ドキュメントサイトは1時間ごとに更新されます。そのため、docs.gitlab.comでは常に最新の情報が提供されており、時にはリリース前の情報も公開されます。開発計画や実装に関するイシューはGitLabの透明性の方針に基づき公開されているため、機能の事前発表を行うことに問題はありません。\n\nこのように、GitLabが「Docs-as-Code」ワークフローを重視する理由は数多くあります。最初はドキュメント作成を1つのツールで完結させることに慣れずに戸惑うかもしれませんが、GitLabはライター全員のワークフローを最初から最後までサポートしており、長年の実績がその効果を証明しています。\n\nGitLabでのテクニカルライティングにおける「Docs-as-Code」ワークフローについて詳しくは、次の動画をご視聴ください。\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/ZlabtdA-gZE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\nオープンソースドキュメントへのコントリビュート方法は、「[ドキュメントの更新方法](https://docs.gitlab.com/ee/development/documentation/workflow.html#how-to-update-the-docs)」でご確認いただけます。ぜひご参加ください。\n","insights",[805,806,9],"careers","contributors",{"slug":808,"featured":6,"template":684},"five-fast-facts-about-docs-as-code-at-gitlab","content:ja-jp:blog:five-fast-facts-about-docs-as-code-at-gitlab.yml","Five Fast Facts About Docs As Code At Gitlab","ja-jp/blog/five-fast-facts-about-docs-as-code-at-gitlab.yml","ja-jp/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"_path":814,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":815,"content":821,"config":827,"_id":829,"_type":14,"title":830,"_source":16,"_file":831,"_stem":832,"_extension":19},"/ja-jp/blog/tips-for-async-communication",{"title":816,"description":817,"ogTitle":816,"ogDescription":817,"noIndex":6,"ogImage":818,"ogUrl":819,"ogSiteName":669,"ogType":670,"canonicalUrls":819,"schema":820},"非同期コミュニケーションを機能させるには何が必要か？オールリモートのGitLabの働き方に見る “ルールと文化”のつくり方","GitLabのソリューションアーキテクトが語る、効果的なリモートワークの実践をご紹介。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749662910/Blog/Hero%20Images/async_communication_key_visual.jpg","https://about.gitlab.com/blog/tips-for-async-communication","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"非同期コミュニケーションを機能させるには何が必要か？オールリモートのGitLabの働き方に見る “ルールと文化”のつくり方\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab Japan Team\"}],\n        \"datePublished\": \"2025-01-31\",\n      }",{"title":816,"description":817,"authors":822,"heroImage":818,"date":823,"body":824,"category":825,"tags":826},[674],"2025-01-31","*写真：左よりGitLab合同会社 シニアソリューションアーキテクト佐々木直晴、スタッフソリューションアーキテクト 伊藤俊廷。書籍 『[GitLabに学ぶ 世界最先端のリモート組織のつくりかた](https://www.shoeisha.co.jp/book/detail/9784798179421)』 と 『[GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術](https://www.shoeisha.co.jp/book/detail/9784798185736)』 を手に*\u003Cbr>\u003Cbr>\n\n## 目次\n1. リモートワーク＝非同期コミュニケーションが発生すること\n2. 非同期コミュニケーションを改善するには？\n3. 非同期・同期コミュニケーションはどう使い分ける？\n4. オールリモート環境における効率的なオンボーディング\n5. オールリモート環境における生産的なコミュニケーション法\n6. GitLabのソリューションアーキテクトの役割とスキル\n\u003Cbr>\n\u003Cbr>\n\nコロナ禍を経た昨今、リモートワークを廃止し出社を前提とする企業が増えています。公益財団法人日本生産性本部がおこなった「第16回 働く人の意識調査※」によれば、テレワーク実施率は14.6%で過去最低を更新したとのことです。\n\n※参考：2025年1月30日公開 [第16回 働く人の意識調査 | 調査研究・提言活動 | 公益財団法人日本生産性本部](https://www.jpc-net.jp/research/detail/007214.html)\n\nリモートワークではコミュニケーションが不足しがちだったり、生産性が低下しやすかったりなどさまざまな課題が指摘されています。コロナ禍で多くの企業が導入を急いだ期間が過ぎ、日本企業におけるリモートワークは曲がり角に差し掛かっているのでしょう。それでもなお、企業はリモートワーク導入をすすめるべきなのでしょうか。\n\n今回は、リモートワークを前提とした「[all-remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/)（オールリモート）」を実践されているGitLab社の担当者に「GitLabの働き方」について詳しく聞きました。オフィスを持たないGitLab社の働き方に、興味を持たれている方も多いのではないでしょうか。\n\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3704_resized.jpg)\n*GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト 佐々木直晴*\n\nそういった方の期待を裏切るかもしれませんが、今回話を聞いた伊藤・佐々木は、リモートワークを無条件に肯定してはいません。リモートワークはあくまで目的を達成するための手段であり、目的ではないというのがふたりの考えです。\n\n佐々木によれば __”[Everyone can contribute](https://handbook.gitlab.com/teamops/equal-contributions/)（誰もが貢献できる）”__ というGitLab社のミッションを実現する手段として、all-remoteが役立つということです。たとえばGitLab社では「サンフランシスコに住んでいないとエンジニアとして働けない」といったことはありません。採用をおこなう地域に一定のルール（※）はあるものの、少なくともオフィスがある場所でしかGitLabで働けないわけではないのです。\n\nall-remoteを実現できているおかげで、通信環境さえあれば他の地域で暮らすエンジニアもGitLab社で活躍できます。「”[Everyone can contribute](https://handbook.gitlab.com/teamops/equal-contributions/)”を重視し、『オフィスがあった方がいいね』とならないのはGitLab社の企業文化の特徴的な部分だ」と佐々木は話しました。\n\n今回のインタビューでは、ふたりにGitLab社がどのようにリモートワークを活用しているかをうかがっています。GitLab社の働き方を知りたい方、自社のリモートワーク導入に悩んでいる担当者の方はぜひ参考にしてください。\n\n※現在は、エンティティがある地域やPEOを通じて雇用が可能な地域でのみ採用を行っており、地域によっては職種を限定しています。\n\n\u003Cbr>\n\n> ーー GitLabにおける、ふたりのお仕事・役割・入社の経緯を教えてください\n## GitLabの先進的な働き方に興味を持ち ソリューションアーキテクトとして入社\n\n__伊藤__：わたしは、GitLabのソリューションアーキテクトというプリセールスエンジニアです。お客様がGitLabを導入される際に、技術面・ビジネス面それぞれの課題に対して、どのように解決できるかを一緒に考え、最適な活用方法をご提案しています。また、製品の価値をお客様のビジネスにどう活かすかを検討しながら、継続的にエンゲージメントを築くことも私の重要な役割です。\n\nGitLabには、LinkedInでリクルーターに声をかけられたことがきっかけで興味を持ち入社しました。GitLabの製品自体にも興味があったのですが、ハンドブック中心にall-remoteでドキュメンテーションをしている点にも興味を持ったのです。きっと先進的な働き方が確立されていると想定し、それを体験したかったです。\n![伊藤 俊廷](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3669_resize.jpg)\n*GitLab合同会社 ソリューションアーキテクト本部 スタッフソリューションアーキテクト 伊藤 俊廷*\n\n__佐々木__：わたしも、伊藤と同じくソリューションアーキテクトです。ソリューションアーキテクトは、GitLabを導入することで、お客様の業務やビジネスがどう変わるかにも着目します。お客様の近くで、課題を発見するという面白さがある役割ですね。\n\n入社前からGitLabを使っていて、製品自体に興味があった点はわたしも同じです。それ以外に透明性がすごいという印象もありましたね。\n\nGitLabでは以前にオペレーションのミスで、本番データベースが喪失したという事故がありました。その際、GitLabはその復旧作業をYouTubeでライブ中継していて、すごいなと思っていたのです。GitLabに入社することになったと周囲に報告した際に『復旧作業をライブ中継していた会社だよね』と言われたのは覚えています。\n\n> ーー おふたりが考えるリモートワークの定義を教えてください。\n## リモートワーク＝非同期コミュニケーションが発生すること\n### オフィスに行かないことがリモートワークではない\n\n__伊藤__：GitLabというより我々の考えになりますが、一般に言われているようにオフィスに行かないことがリモートワークという風に定義していません。\n\nたとえば東京と大阪にオフィスがあれば、オフィス間での仕事は必然的にリモートです。東京にしかオフィスがない会社でも、目の前の人とメールやSlackでやり取りするなどして、リモートでコミュニケーションをとります。突き詰めると一般的なオフィスワーカーは、働いているほんとんどの時間をリモートワークな状態で進めているのではないかと考えるようになったのです。\n\n必ずしも人と人が、いつも同じ場所・タイミングで仕事をするわけではありません。メールやSlackなどで、[非同期のコミュニケーション](https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/)が発生することになります。\n\nこういった非同期のコラボレーションが発生することが、リモートワークとも言えますね。一方で、対面や電話、Zoomでの会議などは、同期コミュニケーションです。\n\n> ーー GitLabで実践されているall-remoteとはどんなものか教えてください\n\n### all-remoteとは物理的に集まるオフィスがなく、在宅での業務を基本とすること\n\n__伊藤__： 物理的にみんなが集まるオフィスがなく、在宅で仕事をすることが基本となるのがall-remoteです。リモートの人がいたりリモートでない人がいたりという状態でなく、全員がリモートで働けることをall-remoteと呼んでいます。\n\nall-remoteは『ほかの人と一切会わない』 ”[strictly remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/stages/#10-strictly-remote)” ではありません。GitLabは対面で会うことも重視しています。GitLabチームメンバーが少ないころは、9ヵ月に1度は世界のどこかで集まるということもしていました。  \n\n> ーー 全ての企業がリモートワークを実践すべきだと思いますか？\n\n### どんな企業でも、無理にリモートワークへ切り替える必要はない\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3764_resize.jpg)\n\n__佐々木__： 非同期・同期どちらのコミュニケーションが良くて、どちらが駄目というわけではありません。それぞれの特性があります。\n\n同期コミュニケーションには、Slackやメールなどと違いすぐに返事が返ってくるという良さがありますね。柔らかい状態で何か議論をはじめて輪郭をはっきりさせるフェーズにおいては、早い同期コミュニケーションが合っています。\n\n一方、ある程度枠が決まり分担して作業できたり、確認にインターバルがとれたりするフェーズでは非同期コミュニケーションも可能です。非同期のコミュニケーションは早さが劣りますが、メールなどが残りあとで探すことができます。\n\n__伊藤__：我々もZoomでちょっと話しながら、互いにアイデアを出し合うということはします。あと、たとえば製品チームなどが、大枠の設計をする際などは同期のコミュニケーションを使っていますね。同期コミュニケーションならではの良さがあるのです。同期コミュニケーションが適している企業は、無理に[all-remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/stages/#9-all-remote)や[hybrid-remote](https://handbook.gitlab.com/handbook/company/culture/all-remote/stages/#5-hybrid-remote)に切り替える必要はありません。\n\nただ、非同期コミュニケーションが必ず発生するということを意識できていない組織が大半を占める印象はあります。同期コミュニケーションが適している企業でも、非同期コミュニケーションが一切不要なわけではなく、情報を一元的にドキュメント化をするデメリットは基本的にはないはずです。\n\n### 手段が整っていないから「うちはリモートワークに向かない」と思い込んでいるケースも\n\n__佐々木__：自分のところはリモートに向いていない、というのを聞くことがありますが本当にそうなのか疑問に思うことはあります。手段が整っていないから、リモートワークが向いていないと感じているだけなのか、鶏と卵の関係のような問題だと思いますね。\n\nたとえばドキュメントが整備されていなかったり、情報が集まっていなかったりすれば、確認の作業が多くなります。『この場合って、どうすればいいんだっけ』という確認作業が、その都度必要になるときは同期的な速いコミュニケーションと相性がいいのです。その結果、同じ場所にいた方が効率はいいよねってことになります。\n\nそうして非リモートで常に同じ場所で仕事をしていると、速いコミュニケーションがより促進されるわけです。ドキュメントが残らず、その場限りのコミュニケーションになりがちで、リモートが合わないという風になってしまいます。リモートワークが向かない状況は、何が原因で作り出されているのかにフォーカスする必要がありますね。\n\n## 非同期コミュニケーションを改善するには？\n### 非同期コミュニケーションの難しさを認識したうえで、意識的に改善できるかどうかが課題\n![伊藤俊廷](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3736_resize.jpg)\n\n__伊藤__：リモートワークか否かは関係なく、非同期のコミュニケーションはどうしても比重が増すと思うのですね。ソフトウェアエンジニアでもマーケティングの広報担当でも、ペアプロや資料作りを他のメンバーとずっと一緒にやるということはありません。そのため、非同期のコミュニケーションをどうやってうまくやるかに着目する必要があるのです。\n\n同期のコミュニケーション自体は、皆さんもあんまり工夫せずにできると思います。しかし非同期につなげるため、同期した内容を残すという意味のドキュメンテーションが意識できていないことが多いのではないでしょうか。非同期のコミュニケーションをどう改善するかが、多くの組織における喫緊の課題のように思います。\n\n> ーー GitLabがリモートワークを成立させるうえで大切にされているSSOTとは何かを教えてください。\n\n### SSOTは信頼できる唯一の情報源\n__佐々木__：SSOTは『Single Source of Truth』の略語で、信頼できる唯一の情報源という意味の言葉です。普段仕事をしているなかで『この点に関する情報はこれが正しい』というのを、ひとつ持ちます。そうして、それに誰もが適切にアクセスできる状態にするのです。\n\n__伊藤__：たとえばどういうお金は会社の経費として申請してよくて、会計上のコードはこれですといった話がありますね。[GitLabでは、こういった情報をインターネット上のハンドブックにまとめて公開](https://handbook.gitlab.com/handbook/finance/expenses/)しているのです。そこに書いてあることが最も確からしく、議論の前提となる情報であるという信頼性があるのがSSOTになります。\n\nGitLabではハンドブックのほか、Google Docsに保存したミーティングノートやチケットなども利用している状況です。本当であれば全ての情報がハンドブックに集約できるとよいのですが、運用上それは現実的ではありません。\n\nここに正しい情報がある、という認識がみんな揃っていることが重要と考えています。たとえば交通費精算のルールがハンドブックにあるため、誰かに精算の基本ルールを何回も聞く必要はありません。\n\n### 「正しい情報がここにある」と社員の意識が向くことが大事\n![佐々木と伊藤](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3819_resize.jpg)\n\n__伊藤__：ハンドブックがあって、そこにSSOT性の高い情報が集約されていることが重要かと思います。SlackやZoom、チケットシステムを導入しても、ハンドブックのように情報を長期的かつ正しく保存する運用をしないと大人数での非同期コミュニケーションは難しいです。『ここに書いてあることが正』という情報としてハンドブックがあることで、みんなの意識がここへ向かうというのが重要かなと思います。\n\n> ーー 非同期コミュニケーション・同期コミュニケーションをどう使い分けているか教えてください。\n## 非同期・同期コミュニケーションはどう使い分ける？\n## 業務の枠組みが決まってくるなどしたら、非同期コミュニケーションへ移行を検討する\n\n__佐々木__：速いコミュニケーションは重要ですので、同期コミュニケーションも活用します。ある程度枠組みが決まってきたり分担して作業したりができるようになってから、非同期のコミュニケーションを検討するイメージです。非同期のコミュニケーションはスピードが劣るものの、情報を残してあとで確認することができます。\n\n### 同期のコミュニケーションはニュアンスを持たせやすい\n\n__佐々木__：Slackなどの文字上・非同期のコミュニケーションに比べ、同期のコミュニケーションはニュアンスを持たせやすいですね。ちょっと敏感な話をするときは、いきなりSlackでどーんとやるのでなく、Zoomで『そういえば、あれさ』という風に話すようにしています。\n\n> ーー 確かに文字ベースで厳しく注意されても、冷たく感じてしまうかもしれません。Zoomなど同期のコミュニケーションであれば、感情などのニュアンスを持たせられるのは分かります。\n全てにおいて、同期もしくは非同期のコミュニケーションが優れているわけではないということですね。コミュニケーションの特性や必要性を考えて、うまく使い分けることが重要ということでしょうか。\n\n__佐々木__：はい、そうですね。\n\n> ーー リモートワークが前提のGitLabにおいて、オンボーディングをどのように実践されているか教えてください。\n\n## オールリモート環境における効率的なオンボーディング\n### 数百のタスクが集まったチケットを自分のペースでこなす\n\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3707_resize.jpg)\n\n> ーー GitLabに入社したい、転職したいという方は、all-remoteの現場でどのようなオンボーディングが実施されているか気になると思います。\n\n__伊藤__：[GitLabのオンボーディング](https://handbook.gitlab.com/handbook/people-group/general-onboarding/)では、ベースとしてメンバーごとにチケットが作成され、そこに数百のタスクが箇条書きで記載されています。それらを1ヵ月程度の時間をかけてこなすという感じですね。\n\nたとえばPCのセットアップや、トレーニングビデオの視聴といったタスクが並んでいます。『ここを学んで欲しい』『PCのセットアップをする』など入社にあたって当たり前に必要となることがチケットにまとめてあるのです。これらをこなせば、自分で仕事がすすめられるまでになります。\n\n全員が同じオンボーディングを完了することで、同じスタートラインに立てるわけです。たとえばハンドブックのどのあたりにどのようなことが記載されているという感覚が身につき、あとから適切に参照できるようになります。\n\n> ーー オンボーディングの際に、トレーナーのような役割の方はつきますか？\n\n__伊藤__：はい、[トレーナー役の『バディ』](https://handbook.gitlab.com/handbook/people-group/general-onboarding/onboarding-buddies/)が新人につきます。ずっとつくというより、毎日1回、1対1で状況や困ったことがないかを確認するイメージです。\n\n## オールリモート環境における生産的なコミュニケーション法\n### チケットによるオンボーディングのよいところは、研修の全体像が可視化されること\n\n__伊藤__：この仕組みのいいところは、全体像がみえる点です。ほかの会社でもオンボーディングの際は、ドキュメントを渡されると思います。一方でGitLabのオンボーディングでは、あちこち見に行かなくてもチケットをみれば研修の全体像が把握できるのです。\nチケットの仕組みを使っているので、チケット内で質問したりバディが状況をチェックして適宜フォローしたりもできます。all-remoteでは新人も不安になりやすいですが、それを取り除ける施策だと思いますね。\n\n> ーー 作業に集中するための「フォーカスタイム」をどのように確保されているか教えてください。\n\n### フォーカスタイムを入れておけば、自動的にミーティングが拒否される\n\n__伊藤__：\nフォーカスタイムは、Googleカレンダーに適宜登録します。なかにはフォーカスタイムの自動登録が可能なツールを使っているメンバーもいますね。\n\nフォーカスタイムを入れておけば、自動的にミーティングは拒否されます。それでも必要に応じて入ってきてしまうこともあるのですが、フォーカスタイムをしない場合に比べ入りづらくなりますね。作業に集中する時間の確保が求められるソフトウェア開発や技術調査、プレゼン作成などをする必要があるメンバーにとって、フォーカスタイムは特に必要です。 \n\n> ーー 非同期コミュニケーションを円滑にするためにおこなっているという「Coffee Chat」について教えてください。\n### Coffee Chatはオフィスで日常的におこなわれる立ち話を代替する手段\n\n__伊藤__：[Coffee Chat](https://handbook.gitlab.com/handbook/company/culture/all-remote/informal-communication/#coffee-chats)は雑談することを目的としたミーティングで、Zoomを使っておこないます。Coffee Chatは、非同期を加速させる手段として推奨されていますね。\n\nSlack上だけのやりとりとなり、なかなか会えないという人は社内にたくさんいます。こういった人たちと同期コミュニケーションをすることで、非同期のコミュニケーションを加速させるわけです。 \n\nただCoffee Chatは、どちらかというとall-remoteのデメリットを表しているとも思います。all-remoteでは、オフィスで日常的におこなわれるような立ち話はできません。立ち話で普通に話す方が、もっとスムーズに雑談ができるわけです。\n\nそういった観点では、Coffee Chatは立ち話の下位互換だとは思います。all-remoteで立ち話の役割を補助するのが、Coffee Chatの仕組みです。\n\n__佐々木__：普通のオフィスであれば、コーヒーを飲みにコーヒーサーバーの周りに集まって偶発的なコミュニケーションが生まれることがありますね。それをオンラインでできないか、というのがCoffee Chatのコンセプトだと理解しています。\n\nコーヒーサーバーのところで、たまたま顔を合わせた人とコミュニケーションをとるような、ランダムさが重要だと思うのです。たとえば、たまたまコーヒーサーバーのところで、隣の部署の人と顔を合わせることがありますね。そのとき『そういえばキャンプ好きでしたよね』といった何気ない会話で、雑談がはじまったりもします。\n\nそういった雑談で、繋がりができる良さがあると思いますね。困ったときに『そういえばマーケティング部門に、この前話した人がいたから相談してみよう』みたいなことがあります。\n\n僕はそういったランダムさが好きで、週1回ツールで自動的にマッチングされた人とCoffee Chatをしていますね。\n\n> ーー ふたりをはじめ、GitLabの皆さんがどのようにリモートワークを実践されているか伺いたいと思います。\u003Cbr>\n> 普段はどこでお仕事をされていますか？\n\n![伊藤俊廷](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3876_resize.jpg)\n\n__伊藤__：自宅で仕事をすることが多いです。海外や国内の出張時にはホテルのなかで仕事をしています。モバイルディスプレイを持ち込んで、自宅の環境となるべく遜色のないように工夫していますね。\n\n> ーー ワーケーションをされている方はいらっしゃいますか？\n\n__伊藤__：我々はロール的に対面でお客様と打ち合わせをする機会が多いので難しいですが、ロールによってはかなりしていますね。\n\nたとえばテクニカルサポートエンジニアは、メールベースで回答して時々Zoomでお客様と打ち合わせするといった感じなのでしやすいと思います。たとえば、シンガポール在住のサポートエンジニアがワーケーションとして日本に来るとか、そういったことができる環境は整備されています。\n\n__佐々木__：\nワーケーションとまではいかなくても、僕はリモートワークの良さを活用する意味で時間を有効活用するようにしています。\n\nたとえば2時間ほど隙間時間ができたら、休日だと混んでいる美術館へ行くとか髪を切りに行くなどして、その時間分は朝少し早く起きて仕事したり、夜にやって調整などをしていますね。そういう融通がきくという点は一部のエンジニアにとって福利厚生というか魅力だと思いますので、僕はあえてXに投稿したりしています。\n\nもちろん『本当はこの時間に打ち合わせをしたかったのに、いなかったからできなかった』といったような迷惑がかからないようにはしていますね。\n\n> ーー 仕事をする時間は決まっていますか？個人の裁量に委ねられているのでしょうか？\n\n__伊藤__：契約上は何時間働くなど最低限の決まりはありますが、基本的には個人の裁量に任せられていますね。たとえば我々はお客様対応が中心なので、それが滞りなく進められていれば良いということになります。\n\n__佐々木__：\nサポートエンジニアやSREの人などにはオンコール体制があり、その時間はトラブルや問い合わせに対応できるようにしないといけないというのはあります。ただ、それも毎日ずっとというわけではないので、ある程度柔軟にはできると思います。\n\n> ーー 他企業がリモートワークに失敗している原因について、ご意見をお聞かせください。\u003Cbr>\n> リモートワークでコミュニケーション不足になったり生産性が低下したりして、リモートワーク導入が失敗している企業が少なくありません。これらの原因について、ご意見をお聞かせいただければと思います。\n\n__伊藤__：リモートワークでは、コミュニケーション不足は絶対的に起こるので、工夫するしかないですね。たとえば会社の文化にも依存するのですが、オンライン会議などでカメラをオンにしない方もいます。そういった点も、コミュニケーション不足の原因になっているのではないかと思いますね。\n\n> ーー カメラは重要でしょうか？\n\n__伊藤__：はい。Coffee Chatのときも含め、GitLabでは全員ではないもののほとんどの人がカメラをつけています。カメラをつけるかつけないかで、Zoomでコミュニケーションをとるときなどの情報量も違いますね。\n\nコミュニケーション不足は避けられないにしても、その不足を補うという点でカメラをオンにするのは重要だと思います。\n\n> ーー コミュニケーションの工夫という点では、GitLab様の文化で素晴らしいと思った点があります。オンライン会議などでお子さんや飼い犬が映っても、それを悪とせずコミュニケーションのきっかけにするということですね。こういった文化も、GitLab様でコミュニケーション不足を防ぐ意味で有効かなと思いました。が起きにくい理由かなと思いました。\n\n__伊藤__：ミーティングの質にもよりますが、割と社内で許容されていますね。\n\n> ーー リモートワークにして生産性が低下した、という企業も存在するようですが、どう思われますか？\n\n__伊藤__：特にオフィスがある状態からの予期せぬ社会的変化によるリモートワークの強制導入においては、そのように感じる背景はよく理解できるが、そもそも本当にリモートワークの実施前後で生産性を測っているのかは気になりますね。何となくの印象で『生産性が落ちた』と言われていることも多いのではと考えています。特にマネジメント側からすると、リモートワークでは従業員の顔が見えず何をしているかわかりません。それで、『生産性が下がった』と感じていることもあると思います。単にチャットツールを多用するだけではない非同期コミュニケーションにおける工夫やドキュメント化を徹底的に推進してもやはりだめだったのかについて気になります。\n\n> ーー ソリューションアーキテクトという職種について教えていただきたいと思います。\u003Cbr>\n> まずはソリューションアーキテクトの職務範囲について教えてください。\n\n## GitLabのソリューションアーキテクトの役割とスキル\n![佐々木直晴](https://res.cloudinary.com/about-gitlab-com/image/upload/v1749687537/Blog/Content%20Images/_TOH3907_resize.jpg)\n\n__佐々木__：[厳密な定義はHandbookに記載](https://handbook.gitlab.com/job-families/sales/solutions-architect/)されていますが、ここではもう少し主観的に紹介しますね。ソリューションアーキテクトには、仕事の方向性が大きく分けて3つあると考えます。\n\nひとつ目はお客様に向けた方向性で、これは一番重要で割合の大きな部分だと考えます。ソリューションアーキテクトは単に技術営業として製品を紹介したり、デモをしたりするだけではありません。\n\nお客様の組織やプロセスをよく観察し、ときにはお客様自身も気付いていない課題やその解決策を提示・提案する活動があります。この活動には自社製品の知識だけでなく、開発手法・クラウドネイティブ技術・プロジェクトマネジメントといったスキルも必要です。ソリューションアーキテクトの個性や強みが活きる領域だと思いますね。\n\nふたつ目は社内です。社内に対しても、ソリューションアーキテクトの価値を発揮できるチャンスがあります。たとえば営業メンバーに対し、製品の新機能が持つ価値や解決可能な課題を説明し全員が概念として扱えるようにするイネーブルの要素です。\n\n個人的にはこういう仕事も好きで、社内でGeneral (Yorozu) Discussion Lunch Chatという場を週1回運営しています。General (Yorozu) Discussion Lunch Chatでは昼ご飯を食べながら、メンバーが質問し合ったり情報をシェアしたりするのです。\n\n最後はマーケット全体に向けた方向性になります。たとえばDevSecOpsの取り組みについては認知度が高まってきているとはいえ、十分とはいえません。クラウド技術のように先行して広まった概念に比べると一般化しているとは言えず、まだまだ知ってもらう必要があると思っています。イベント登壇やマーケティング組織と連携してのコンテンツ作成といった手法で、認知度向上に努めるのも重要な仕事ですね。\n\nこのようにソリューションアーキテクトには、やるべきことがたくさんあるとは言えるでしょう。ただ個人的には、走り回れるホワイトスペースが多くて非常にやりがいがあり楽しく感じています。\n\n> ーー ソリューションアーキテクトに英語スキルはどのくらい必要ですか？\n\n__佐々木__：もちろん英語スキルが高ければ高いほどいいのですが、いくつかの観点でお答えできればと思います。\n\n__伊藤__：自分は経験的に入社時期と組織の規模に大きく相関すると考えています。日本で採用される場合、日本にいる関連するロールでのチームメンバーが増えるにつれて、英語の必要性が少しずつ減っていくことを、他社での経験も含めて、体感しました。\n\n> ーー どういった場面で必要になりますか？\n\n__佐々木__：日常的に英語を読み書きするシーンはありますが、AIやツールの使いやすいところではあります。一番地力が必要になるのは、対面で会話する必要があるシーンですね。定例のような事前準備がしやすいシーンでなく、初めて対面するお客様や海外支社のメンバーと話すシーンでは特に英語力が求められます。\n\n> ーー TOEICスコアなどは関係がありますか？\n\n__佐々木__：よく『TOEIC L&Rテストの点がよくても英語で活躍できるわけじゃない』『TOEIC  L&Rテストはスピーキングがないので意味がない』という説も聞きます。しかし、そもそも聞けないと答えられないので、リスニングパートについては関係があると思いますね。リーディングはツールの活用でなんとかなるケースもあると思います。\n\n__伊藤__：AIを翻訳領域で活用すれば、英語で会話できる必要はなくなるという意見も耳にします。しかし、たとえAIベースの翻訳ツールが今後さらに進化したとしても、翻訳処理の遅延が完全になくなることはありません。\nまた、ビジネスでもプライベートでも、AI翻訳を介した会話で本当に人間関係を築けるのかには疑問が残ります。たとえば、海外のメンバーを含む社内のアクティビティや食事に参加したとき、自分だけが翻訳デバイスを使っていたら、意図せずとも他のメンバーから声をかけられる機会が減ることは容易に想像できると思います。\n\n上級レベルの英語運用力が測れない欠点はあるものの、私はTOEICは客観的に英語力を図るひとつの手段と考えます。外資系ソフトウェアベンダーの世界に入る前に、TOEIC L&Rテストと並行してTOEIC S&Wテストも受け、自分の英語での会話力向上に継続的に取り組んできました。\n\n> ーー 英語スキルを向上させるために、どんな努力をしていますか？\n\n__佐々木__：GitLabでは業務の必要に応じ、研修やトレーニングを受けるための費用を年間＄10,000ほど支援してくれます。この支援を活用して、英会話などの研修を受けたりアプリを利用したりといったことをかなりしましたね。あとは積極的に海外のメンバーとCoffee Chatをして、英語力を磨いています。\n\n> ーー 入社時に比べ、英語をつかうのには慣れましたか？\n\n__佐々木__：GitLab入社前は英語を使う環境はなかったので、本当に不安だった記憶があります。今では社内のメンバーであれば、何とかなるだろうという気持ちは持てるようになりました。\n\n社内メンバーなら最悪何回か聞き直したり、表現を変えて話し直したりすることができますからね。ただ、お客様相手ではそれができずまだ緊張するので、継続して英語力向上に取り組んでいく必要があると思っています。\n\n> ーー ソリューションアーキテクトのお仕事をする際の、よくある1日のスケジュールを教えてください。\n\n__佐々木__：以下のような感じですね。\n    \u003Ctable>\n        \u003Cthead>\n            \u003Ctr>\n                \u003Cth width=\"100\">時間\u003C/th>\n                \u003Cth>イベント\u003C/th>\n            \u003C/tr>\n        \u003C/thead>\n        \u003Ctbody>\n            \u003Ctr>\n                \u003Ctd>08:00\u003C/td>\n                \u003Ctd>下の子を幼稚園のバス停まで送る。\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>09:00\u003C/td>\n                \u003Ctd>位置情報ゲーム（Ingress）をしながら帰宅。その後、コーヒーを飲みながら業務開始。\u003Cbr>\n                午前中は打ち合わせがなく、集中して技術検証と新規ハンズオンのコンテンツ作成をおこなう。\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>13:00\u003C/td>\n                \u003Ctd>昼食を食べながら、同僚とZoomで製品の新機能について議論\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>14:00\u003C/td>\n                \u003Ctd>新規のお客様とディスカバリーミーティング*\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>15:30\u003C/td>\n                \u003Ctd>APAC SA Weekly Call（定例）で最近の案件について共有\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>17:00\u003C/td>\n                \u003Ctd>上の子を習い事まで送り、近くのコワーキングスペース（個室）を借りてオンライン英会話と仕事\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>19:00\u003C/td>\n                \u003Ctd>習い事が終わった子どもを迎えに行って帰宅\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>20:00\u003C/td>\n                \u003Ctd>夕食をすませ子どもと遊ぶ\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>22:00\u003C/td>\n                \u003Ctd>なんだかんだ気になって、Slackなどで仕事の対応をしてしまう（良くない日）\u003C/td>\n            \u003C/tr>\n            \u003Ctr>\n                \u003Ctd>24:00\u003C/td>\n                \u003Ctd>就寝\u003C/td>\n            \u003C/tr>\n        \u003C/tbody>\n    \u003C/table>\n\n＊ディスカバリーミーティング：顧客の業務プロセス、要件、課題を深く理解し、効果的なソリューション設計のための情報を収集する初期段階の重要な会議\n\n> ーー ありがとうございました。\n\n> [GitLabで募集中のポジションはこちら](https://about.gitlab.com/jobs/all-jobs/)","culture",[9],{"slug":828,"featured":91,"template":684},"tips-for-async-communication","content:ja-jp:blog:tips-for-async-communication.yml","Tips For Async Communication","ja-jp/blog/tips-for-async-communication.yml","ja-jp/blog/tips-for-async-communication",{"_path":834,"_dir":247,"_draft":6,"_partial":6,"_locale":7,"seo":835,"content":841,"config":852,"_id":854,"_type":14,"title":855,"_source":16,"_file":856,"_stem":857,"_extension":19},"/ja-jp/blog/demystifying-ci-cd-variables",{"title":836,"description":837,"ogTitle":836,"ogDescription":837,"noIndex":6,"ogImage":838,"ogUrl":839,"ogSiteName":669,"ogType":670,"canonicalUrls":839,"schema":840},"GitLabの環境変数をわかりやすく解説","CI/CD変数はジョブやパイプラインを制御するのに便利（かつ柔軟に利用可能）なツールです。この記事では、GitLabの環境変数について知っておくべき情報をすべてご紹介します。","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664679/Blog/Hero%20Images/blog-image-template-1800x945__24_.png","https://about.gitlab.com/blog/demystifying-ci-cd-variables","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLabの環境変数をわかりやすく解説\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2021-04-09\",\n      }",{"title":836,"description":837,"authors":842,"heroImage":838,"date":844,"body":845,"category":846,"tags":847,"updatedDate":851},[843],"Veethika Mishra","2021-04-09","[CI/CD](https://about.gitlab.com/ja-jp/topics/ci-cd/)変数は、さまざまな方法で定義・使用でき、高い柔軟性を持っています。変数はジョブやパイプラインを制御する上で非常に便利で、`.gitlab-ci.yml`設定ファイルに値をハードコーディングせずに済みます。このブログ記事では、変数のスコープや機能を分かりやすくお伝えするため、変数の定義や使い方に関する情報を網羅的に整理し、全体像をご紹介します。記事全体をとおして、関連するドキュメントがリンクされています。\n\n\n[GitLab\nCI/CD](https://docs.gitlab.com/ee/ci/)では、値を定義して保存することで、変数を使用してジョブをカスタマイズできます。変数を使用すれば、値をハードコーディングする必要はありません。GitLabでCI/CD変数を定義するには、**「設定」>>「CI/CD」>>「変数」**の順に移動します。または`.gitlab-ci.yml`ファイルで定義することも可能です。\n\n\n変数は、異なるデプロイ環境（`testing`、`staging`、`production`など）におけるサードパーティサービスの設定に役立ちます。それらの環境に紐づけられたサービスは、必要なAPIエンドポイントを指す変数を変更するだけで、簡単に変更できます。また、変数を使用してジョブを設定し、ジョブ実行時にジョブ内で環境変数として利用できるようにすることも可能です。\n\n\n![GitLabは、.gitlab-ci.ymlファイルを読み込んで、参照される変数をスキャンし、GitLab\nRunnerにその情報を送信します。変数情報はRunnerに渡され、Runnerによって出力されます。](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_processing.jpeg)\n\n\n## 変数と環境の関係\n\n\nソフトウェア開発プロセスには、製品をユーザー向けにリリースする前にテストするステージが含まれます。[環境](https://docs.gitlab.com/ee/ci/environments/)は、これらのステージの内容を定義するために使用されるもので、チームや組織によって異なる可能性があります。\n\n\n一方、変数とは、ユーザーによる製品の操作によって変化する可能性のあるデータ値を指します。これには、年齢や好み、またはタスクフローにおける次のステップを決定する要素となるあらゆる入力が該当します。\n\n\n[環境変数](https://docs.gitlab.com/ee/administration/environment_variables.html)という言葉は、皆さんもよく耳にされると思います。これは、ある環境で定義されているものの、アプリケーションの外部に存在する変数を指します。GitLab\nCI/CD変数を使用すると、デベロッパーはコード内で値を設定できます。変数の使用には、コードの柔軟性が保証されるという利点があります。GitLab\nCI/CD変数を使用すれば、コードに変更を加えることなく、特定の環境にデプロイされたアプリケーションを変更できます。これにより、アプリケーションの外部で設定の環境変数を変更するだけで、テストの実行やサードパーティサービスの統合を簡単に行えます。\n\n\n## CI/CD変数のスコープ\n\n\n![CI/CD変数の優先順位：1) 手動によって実行、トリガー、スケジュールされたパイプライン変数、2)\nプロジェクトレベル、グループレベル、インスタンスレベルの保護変数、3) 継承されたCI/CD変数、4)\nymlに定義された、ジョブレベルのグローバル変数、5) デプロイ変数、6)\n定義済みのCI/CD変数](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variables_precedence.jpeg)\n\n\n### `.gitlab-ci.yml`に定義された変数\n\n\nGitLabには、ジョブ環境で利用する必要がある変数を追加できます。これらのCI/CD変数は、`.gitlab-ci.yml`ファイルのデータベースURLのような、機密性の低いプロジェクト設定を保存するために使用されます。この変数は、複数のジョブやスクリプトで再利用でき、必要な場所で値を参照できます。値を変更する場合は、変数を一度更新するだけで、変数が使用されているすべての箇所に変更が反映されます。\n\n\n### プロジェクトのCI/CD変数\n\n\nリポジトリ固有の要件に縛られることなく、[プロジェクト設定](https://docs.gitlab.com/ee/ci/variables/#for-a-project)でCI/CD変数を定義できます。これにより、CI/CDパイプラインで利用できるようになります。これらの変数は、リポジトリの外部（`.gitlab-ci.yml`ファイルには保存されません）に保存されますが、CI/CDの設定やスクリプトで引き続き利用可能です。変数を`.gitlab-ci.yml`ファイル外に保存することで、これらの値のスコープをプロジェクト内のみに限定し、プロジェクトにプレーンテキストとして保存されることを防ぎます。\n\n\n### グループおよびインスタンスのCI/CD変数\n\n\n一部の変数は、グループレベル、あるいはインスタンスレベルで適用でき、グループやインスタンス内のすべてのプロジェクトで有用となる可能性があります。[グループまたはインスタンス設定](https://docs.gitlab.com/ee/ci/variables/#for-a-group)で変数を定義することで、それらのスコープ内にあるすべてのプロジェクトにおいて、実際の値がわからなくても、変数を使用できるようになります。下位スコープの変数を作成する必要もありません。たとえば、複数のプロジェクトにおいて更新が必要な共通の値がある場合、1か所で最新の状態に保つことで管理しやすくなります。また、パスワードの値を実際に知らなくても、複数のプロジェクトで特定のパスワードを使用することも可能です。\n\n\n## 環境としてのジョブとパイプライン\n\n\nGitLab\nCI/CDの変数は、環境変数としてだけでなく、`.gitlab-ci.yml`設定ファイル内でパイプラインの動作を設定するためにも使用されます。この場合、特定の環境に依存しない状況でも利用できます。また、プロジェクト、グループ、インスタンスの設定に保存しておくことで、パイプライン内のジョブで利用可能になります。\n\n\n以下に例を示します。\n\n\n```  \n\njob:  \n  rules:  \n    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  \n  script:  \n  - echo \"This job ran on the $CI_COMMIT_BRANCH branch.\"  \n```\n\n\nスクリプトセクション内で使用されている変数（例：`$CI_COMMIT_BRANCH`）は、定義されたジョブのスコープ内で実行されます。このスコープは「ジョブ環境」と呼ばれます。つまり、ジョブが開始されると、GitLab\nRunnerはDockerコンテナを起動し、その環境でジョブを実行します。Runnerはその変数（および他のすべての定義済み変数やカスタム変数）をジョブに提供します。さらに、その値をログ出力に表示することも可能です。\n\n\nただし、この変数は、ジョブの実行タイミングを決定するために、`if:`セクション**でも**使用されます。ただし、そのセクション自体は環境ではないため、これらの変数を「CI/CD変数」と呼びます。CI/CDジョブを動的に設定する際に使用できるのは**もちろん**、ジョブの実行時に環境変数としても利用できます。\n\n\n## 定義済み変数\n\n\nGitLab\nCI/CDパイプラインが開始されたタイミングで、[定義済み変数](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)がすでに存在します。ユーザーは変数自体を定義せずに、コミットやプロジェクト、パイプラインの詳細などの値にすぐにアクセスできます。\n\n\n## カスタムCI/CD変数\n\n\n![Runnerは、2種類のカスタムCI/CD変数（タイプとファイル）を作成できます。](https://about.gitlab.com/images/blogimages/demystifying-ci-cd-variables/variable_types.jpeg)\n\n\nGitLabでは、設定でCI/CD変数を作成する際に、変数に対してより詳細な設定オプションを利用できます。次のような追加の設定オプションを使用して、機密性の高い変数をより厳密に管理することが可能です。\n\n\n**環境スコープ**：ある変数を特定の環境でのみ使用する必要がある場合に、その環境でのみ使用できるように設定します。たとえば、デプロイトークンを`production`環境でのみ使用できるように設定できます。\n\n\n**保護変数**：環境スコープと同様に、デフォルトブランチなどの保護ブランチでパイプラインが実行される場合にのみ、変数を使用できるように設定できます。\n\n\n**変数タイプ**：一部のアプリケーションでは、設定をファイル形式で渡す必要があります。そうした設定が必要なアプリケーションを利用する場合は、変数タイプを「File」に設定します。この方法でCI/CD変数を設定する場合、Runnerが環境内で変数を利用できるようにする際に、実際に一時ファイルに変数を書き出し、そのファイルパスを変数の値として保存します。その後、アプリケーションに必要なファイルパスを渡すことで設定が適用されます。\n\n\nご紹介した変数の定義方法や使用方法に加えて、GitLabでは、手動でパイプラインを実行する必要がある場合に、事前入力済みの変数を生成する機能が導入されました。事前入力済みの変数が生成されることで、エラーの発生リスクが軽減され、パイプラインを実行しやすくなります。\n\n\n**マスクされた変数**：[マスクされた変数](https://docs.gitlab.com/ee/ci/variables/#mask-a-cicd-variable)は、変数の値が表示されないように**ジョブログに隠された**CI変数です。\n\n\n**マスクおよび非表示化された変数**：[GitLab\n17.4](https://about.gitlab.com/ja-jp/blog/gitlab-17-4-released/)で導入された[マスクおよび非表示化された](https://docs.gitlab.com/ee/ci/variables/#hide-a-cicd-variable)変数は、ジョブログと同じマスキング機能を利用し、**設定UI**でも**値を非表示**にします。これらの変数を機密データ（シークレットなど）に使用した場合、誤って公開されてしまう可能性があるため、推奨されません。\n\n\n## シークレット\n\n\nシークレットとは、機密性が高く、秘密に保つべき認証情報のことを指し、以下のようなものが該当します。\n\n\n* パスワード\n\n* SSH鍵\n\n* アクセストークン\n\n* その他、漏洩すると組織に害を及ぼす可能性のある認証情報\n\n\nGitLabでは現在、キーやトークン、その他のシークレットをプロジェクトレベルで安全に管理するために、HashiCorp Vault、Google\nCloud Secret Manager、Azure Key\nVaultを活用できます。これにより、[CIで外部シークレットを使用](https://docs.gitlab.com/ee/ci/secrets/)することが可能です。そのため、セキュリティ上の理由から、これらのシークレットを他のCI/CD変数から分離して管理できます。\n\n\n### GitLabシークレットマネージャー\n\n\nGitLabでは、CIにおける外部シークレットのサポートに加えて、GitLab内でシークレットを安全かつ便利に保存するための[ネイティブなシークレット管理ソリューション](https://gitlab.com/groups/gitlab-org/-/epics/10108)の導入にも取り組んでいます。このソリューションは、お客様がGitLab固有のコンポーネントや環境で保存されたシークレットを使用したり、ネームスペースグループやプロジェクトレベルでのアクセスを簡単に管理したりする上でも役立ちます。\n\n\n## 関連リンク\n\n*\n[GitLabネイティブシークレットマネージャーでソフトウェアサプライチェーンのセキュリティを強化](https://about.gitlab.com/blog/gitlab-native-secrets-manager-to-give-software-supply-chain-security-a-boost/)\n\n\n***免責事項**：このブログには、今後リリース予定の製品、機能、および機能性に関する情報が記載されています。ただし、それらの情報はあくまで参考のために提供されているため、購入や計画の判断材料として使用することはお控えください。すべてのプロジェクトと同様に、このブログおよびリンク先のページに記載されている項目は、変更または遅延される場合があります。製品、機能、機能性の開発、リリース、およびタイミングに関する決定権は、GitLabに帰属します。*\n","engineering",[848,704,9,849,109,850],"CD","CI","tutorial","2025-01-13",{"slug":853,"featured":6,"template":684},"demystifying-ci-cd-variables","content:ja-jp:blog:demystifying-ci-cd-variables.yml","Demystifying Ci Cd Variables","ja-jp/blog/demystifying-ci-cd-variables.yml","ja-jp/blog/demystifying-ci-cd-variables",1,[662,689,712,731,750,769,788,813],1758326267130]