Downloaded 19 times
Uploaded byNaoharu Sasaki
「AI？ダメ絶対！」とは言わせない！ 伝統的な企業文化のなかでも、ソフトウェア開発にAIを 導入するための3つの方法とは？ 2025-07-17 Developers Summit Summer
「AI？ダメ絶対！」とは言わせない！ 伝統的な企業文化のなかでも、ソフトウェア開発にAIを 導入するための3つの方法とは？ 2025-07-17 Developers Summit Summer
![[AWSマイスターシリーズ] AWS Elastic Beanstalk -Python編-](https://cdn.slidesharecdn.com/ss_thumbnails/20121217aws-meister-reloaded-awselasticbeanstalk-pythonpublic-121224234209-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
「AI？ダメ絶対！」とは言わせない！ 伝統的な企業文化のなかでも、ソフトウェア開発にAIを 導入するための3つの方法とは？ 2025-07-17 Developers Summit Summer
- 1.
- 2. ● 自己紹介と会社紹介 ● GitLabとは ●AI活用に対する不安や懸念 ● GitLabが上記をどのように解決するか ● まとめ 今日のアジェンダ 2
- 3.
- 4. 自己紹介 4 x.com/naoharu gitlab.com/naosasaki linkedin.com/in/naoharu-sasaki/ 佐々木直晴 Naoharu Sasaki) SeniorSolutions Architect 2021年 GitLab Senior Solutions Architectとして導入時の技術検証や構築支援、 ワークショップやトレーニングの提供に従事 2010年 野村総合研究所 金融業界のアジャイルプロジェクトを中心にテクニカルリードとして参画 主にJava系Webアプリケーションフレームワークの開発や導入支援など
- 5. GitLab: 会社とコミュニティ 会社 - 包括的なDevSecOpsプラットフォームを GitLab.com、GitLabself-managed、GitLab Dedicatedで展開 - 2014年法人化、2021年10月にNasdaq上場 - 60カ国以上にまたがる2,000名以上の従業員 - All-remote: オフィスを持たない 広範な普及 - 複数の第三者評価でDevOpsプラットフォームの「リーダ」として認知 - Gartner Magic Quadrant、 The Forrester Wave - 100,000以上の組織 - 3,000万以上のユーザ - 毎月第三木曜にGitLab self-managedの新バージョンをリリース 強固なコミュニティ - 2011年設立 - オープンソースモデル - 3,300名以上のコードコントリビュータ 5
- 6. リモートワーク、コミュニケーション、働き方 6 ● 現代の仕事において重要なポイント を発表 ○ 「GitLabで学んだ最高の働き方」 ○「組織の自律自走を促すコミュニ ケーション」 ● 世界最先端のリモート組織を実現す るための書籍を監修 GitLabに学ぶ パフォーマンス を最大化させるドキュメンテー ション技術 GitLabに学ぶ 世界最先端のリ モート組織のつくりかた
- 7.
- 8.
- 9.
- 10.
- 11. 11 GitLab Recognized asa Leader Source: Gartner, Magic Quadrant for DevOps Platforms, Manjunath Bhat, Thomas Murphy, et al., 03 September 2024 2024 Gartner® Magic Quadrant™ for DevOps Platforms Gartnerは、Gartner, Inc.および/または米国とその他の国におけるその関連会社の商標およびサービスマークであり、MAGIC QUADRANTは、Gartner, Inc.および/またはその関連会社の登録商標であり、本書では許可を得て使用しています。All rights reserved. Gartnerは、Gartnerリサーチの発行物に掲載された特定のベンダー、製品またはサービスを推奨するものではありません。また、最高のレーティング又はその他の評価を得たベンダーのみを選択するようにテクノロジーユーザーに助言するものではありません。Gartnerリサーチの発行物は、Gartnerリサーチの見解を表したものであ り、事実を表現したものではありません。Gartnerは、明示または黙示を問わず、本リサーチの商品性や特定目的への適合性を含め、一切の責任を負うものではありません。 この図表は、Gartner, Inc.がリサーチの一部として公開したものであり、文書全体のコンテクストにおいて評価されるべきものです。オリジナルのGartnerドキュメントは、リクエストにより GitLabからご提供することが可能です。
- 12. 「GitLab Duo」 -ソフトウェア開発全体でのAIによる支援 12
- 13.
- 14. GitLab Duoのコンセプト あるべきAI活用 統合されたコンテクスト データストアがひとつに統合されたGitLabだからこそ、ユーザーのワークフロー全体の背景情報をすべて網羅こ れにより、チームはソフトウェア開発全体のAIによる加速を実現可能 単一のデータストア 計画・議論 開発・検証監視とカイゼン デプロイ 継続的デリバリー AIの活用 セキュリティとコンプライアンス 継続的カイゼン 14 統合されたコンテクストを持つAIによる ソフトウェア開発全体に対する支援
- 15.
- 16. 継続的デリバリー AIの活用 セキュリティとコンプライアンス 単一のデータストア 計画・議論 開発・検証 監視とカイゼン デプロイ 継続的カイゼン 16 例:AIがチームの一員になると・・・ ①計画時の議論はソースコード の提案に活用される ① ②ソースコードの変更内容は CI失敗原因分析に活用される ② ③脆弱性を検知したら既存の コードに修正を提案する ③
- 17.
- 18.
- 19.
- 20. 20 理由1: 外部への知的財産流出の懸念 ● 自社の機密情報や、競争優位性がクラウド側に送信され、AIベン ダーがモデルのトレーニングに活用 ●他社へのソースコードの推奨でそれらの技術が流出するリスク AIツール AIツール AIツール AIツール AIツール AIツール AIツール AIツール 実際には一部のAIツールでは、 利用できるトークン数の上限を上げるために、 送信したデータでの学習を許可する という設定が可能なツールも
- 21.
- 22. 22 理由2: AIが生成したものに脆弱性が含まれる懸念 Cybersecurity Risksof AI Generated Code.pdf AIは原理的に脆弱性のあるコードを生成 5つの大規模言語モデル（LLM）に同一のプロンプトを与えた結果、生成さ れたコードスニペットの約半数にバグやセキュリティ上の問題が含まれてい ることが判明。 これらのバグは、メモリリークやバッファオーバーフローなど、悪意のある 攻撃者に悪用される可能性のある深刻なものが含まれる 理由 AIコード生成モデルは、インターネット上に公開されている既存のコードを 学習している。しかし、これらのコードの多くは品質が保証されておらず、 脆弱性を含んだまま公開されている。そのため、AIは「人間が過去に書い た不完全あるいは不安全なコード」を模倣する傾向がある。 また、AIは「動くコードを素早く出力すること」を優先するよう設計されて いる。このため、例外処理や認証チェック、入力検証といったセキュリティ 的に重要な構成要素が省略されることがある。
- 23. 23 理由3: AIが作ったものをレビューできるかという懸念 ● AIは利用上限が許す限り、休まず成果物を生成し続ける ●人間のリソースは有限。量的・質的にもレビューがボトルネックに AIでコーディングが爆速化した今、開発組織が向き合う新たなボトルネック
- 24.
- 25.
- 26. 26 「理由1: 外部への知的財産流出の懸念」への解決策 知的財産の流出 ● 機密情報がより多くの外部事業者へ ●自社が持つ優位性が学習され、他社への 推奨に利用された場合、競争優位性が 失われる可能性も ソフトウェア開発全体への AI利用は トレーサビリティ・責任所在・学習用途利用の有無などを鑑み て、信頼性の高いAIに利用を絞るべきである 最も信頼できる AI＝Local LLM（自社内に閉じた利用） AIツール AIツール AIツール AIツール AIツール AIツール AIツール AIツール
- 27. 27 「理由1: 外部への知的財産流出の懸念」への解決策 オンプレ or クラウド GitLab インスタンス LocalLLM gitlab.com 3rd Party AI 3rd Party AI SaaS Self Managed インターネット AI Gateway AI Gateway GitLab/AIプロバイダーが提供 利用者が構築・運用 外部のAIを選択して 利用することも可能 クラウドベンダーAI プライベート クラウド インターネット
- 28.
- 29.
- 30. 30 「理由2: AIが生成したものに脆弱性が含まれる懸念」への解決策 SAST Static ApplicationSecurity Testing： ソースコードを静的に解析することで脆弱 性を検出。 例：SQLインジェクション 依存関係スキャン パッケージマネージャから依存関係を解析 することで、既知のライブラリの脆弱性を 検出、またSBOMの出力を実現。 例：CVE-2017-5638 (Apache Struts2) ライセンス コンプライアンス パッケージマネージャーの依存関係を解析 し、プロジェクトのポリシーに従った承認 済みや非許可のライセンスを検出。 例：GPLライセンス DAST Dynamic Application Security Testing： 起動中のWebアプリ（レビュー用でも）の ランタイム脆弱性を検出。 例：CSRF Web API Fuzz 起動中のWeb APIにランダムなリクエスト を発行。 例：500 INTERNAL SERVER ERROR Secret Detection コミットしたコードに含まれる資格情報、 シークレット、パスワードなどをチェック し、機微な情報の漏洩を検出。 例：AWS Key、DBパスワード Coverage Guided Fuzz ホワイトボックス的に関数、メソッドにラ ンダムな引数を渡し、実行。 例：ArrayIndexOutOfBoundsException (Java), Heap-Buffer-Overflow (C++) コンテナスキャン Dpkgやrpmなどのパッケージマネージャを 解析し、コンテナ内の既知のライブラリの 脆弱性を検出。 例：Heartbleed, ShellShock
- 31. 31 「理由2: AIが生成したものに脆弱性が含まれる懸念」への解決策 ルートグループ （最上位） サブ グループ A サブ グループB プロジェクトX プロジェクトY プロジェクトZ 任意の CIジョブA ジョブA ジョブA ジョブA 任意の CIジョブB ジョブB パイプライン実行ポリシーにより、セキュリティキャンを現場に委ねず 全社レベルでプロジェクト全体に実行させるように統制可能 パイプライン実行ポリシーにより、親グループで定義されたCIジョブを 配下のプロジェクトでは自動実行させることが可能
- 32.
- 33.
- 34.
- 35. 35 「理由3: AIが作ったものをレビューできるかという懸念」への解決策 ● 品質を高めるだけでなく、メンバーのスキルアップにもつながる重要なプラクティス ●一方で、迅速に行われないと、開発のボトルネックになることも ● 有識者・テックリードに集中しがちなレビュー負荷をオフロードすることが重要 ○ レビューの観点 ■ 機能観点・・・ソフトウェアが設計通り動くか、忘れていることがないか ■ 非機能観点・・正しく動くが、安全じゃない、性能が悪い、拡張性が悪い、など
- 36. 36 「理由3: AIが作ったものをレビューできるかという懸念」への解決策 ● 品質を高めるだけでなく、メンバーのスキルアップにもつながる重要なプラクティス ●一方で、迅速に行われないと、開発のボトルネックになることも ● 有識者・テックリードに集中しがちなレビュー負荷をオフロードすることが重要 ○ レビューの観点 ■ 機能観点・・・ソフトウェアが設計通り動くか、忘れていることがないか ■ 非機能観点・・正しく動くが、安全じゃない、性能が悪い、拡張性が悪い、など 有識者のリソースが使われるべき領域 AIの支援により負荷をオフロード可能
- 37. 37 まとめ ● AI活用は広がる一方で、伝統的・保守的な企業では慎重に判断されがち ● 具体的な懸念は下記 ○情報流出、自社データのトレーニング利用 ○ AIが生成したコードの脆弱性 ○ 成果物が大量にAIにより生成されレビューがボトルネックに ● GitLabのセキュリティスキャンやDuoを活用することで解消可能 この内容を部内で説明してみよう！
- 38.
- 39.
- 40.
- 41.
- 42.