人間とAI、どちらが書いたコードもCICDでチェックしてみよう

Transcript

1. 人間とAI、どちらが書いたコードも CI/CDでチェックしてみよう 2025.10.21 SATOSHI KANEYASU
2. 2 氏名：兼安 聡 所属：株式会社サーバーワークス アプリケーションサービス部 在住：広島（フルリモート） 担当：DevOps、技術支援、PM、SM SNS(X)：@satoshi256kbyte • 2025 AWS Community Builders • 2025 Japan AWS Top Engineers (AI/ML Data Engineer) • 2025 Japan AWS All Certifications Engineers • 認定スクラムマスター • PMP Speaker Introduction
3. 3 目次 ⚫生成AIを用いた開発と品質面のリスク ⚫GitHub ActionsによるCI/CDパイプラインの作り方 ⚫GitHub Actionsによる品質とセキュリティのチェック ⚫GitHub ActionsからのAWSの操作
4. 生成AIを用いた開発と品質面のリスク
5. 5 AIと協力する開発スタイル – Vibe Coding • AIがコードを生成し、開発者はそのコードをレビュー・修正しながら ソフトウェアを開発する手法を、Vibe Codingと言います • サーバーワークスでは開発に用いる生成AIのソリューションを提供し ています ソースコード
6. 6 Vibe Codingの課題 ⚫ Vibe Coding とはAIに自然言語で指示を与えて開発するスタイルを 指します。 ⚫ 一般的にチャットで会話しながら開発するので、 同じ成果物を得るには会話を再現する必要があります。 （対策となるテクニックは存在しますが本筋から離れるので割愛します） このやり取りを丸ごと再現しないと、 同じ成果物を得るのは難しい
7. 7 仕様駆動開発 ⚫ Vibe Codingの課題に対しての、対策アプローチの一つが、仕様駆動開発です ⚫ Kiroのスペックは要件定義＞設計＞実装計画＞実装という段階を踏みます 要件の入力 要件定義 設計 実装計画 実装 Kiroのスペック requirements. md design.md tasks.md コード
8. 8 AIが作業を途中で打ち切ってしまう AIによるチェックが中途半端 成果物に脆弱性が含まれる 1 2 3 Vibe Codingと仕様駆動開発、両方で起き得る課題
9. 9 AIによるチェックが中途半端になってしまう例 • A-1を実装する • A-2を実装する • A-3を実装する • B-1を実装する • B-2を実装する • B-3を実装する • C-1を実装する • C-2を実装する • C-3を実装する • 実装したプログラムをチェックして、エラーと警告をゼロにする 実装計画 AIの最 終報告 • 最終的にエラーは0件、警告は20件となりました。 残りの20件は動作には問題ない警告です。 ？？？動作に問題ない警告ならOKという条件はなかったはずだが・・・
10. 10 なぜこのようなことが起きるのか？ • A-1を実装する • A-2を実装する • A-3を実装する • B-1を実装する • B-2を実装する • B-3を実装する • C-1を実装する • C-2を実装する • C-3を実装する • 実装したプログラムをチェックして、エラーと警告をゼロにする 実装計画 実装計画に含まれる 作業が多すぎる • チェックを最後にまとめてやってしまっている • AIも溜めてからの最後に一気にテストやチェックはやりきれないことがある
11. 11 AIの成果物に脆弱性が含まれる例 パッケージ名 バージョン ライセンス 依存関係 インストール元 numpy 1.26.4 BSD-3-Clause 依存なし PyPI pandas 2.2.3 BSD-3-Clause numpy PyPI requests 2.32.3 Apache-2.0 urllib3, idna, certifi PyPI fastapi 0.115.0 MIT starlette, pydantic PyPI uvicorn 0.31.0 BSD-3-Clause click, h11 PyPI 識別子 対象パッケージ 影響バー ジョン 深刻度 内容概要 CVSSスコア CVE-2024- 12345 requests ～2.32.3 High 特定のHTTPヘッダー処理に より任意コード実行の可能 性 8.8 使用ライブラリ一覧 脆弱性データベース
12. 12 なぜこのようなことが起きるのか？ ⚫ AIは特に何もしなければ、脆弱性データベースを直接参照していない ⚫ AIは特に何もしなければ、技術的に少しだけ前の情報を元に成果物を作る
13. 13 AIの成果物の課題に対する対策案 AIによるチェックが 中途半端 要件自体を細かくする チェックをこまめに するよう指示する 現象 対策 AIに依存しない チェックを設ける AIの成果物に 脆弱性が含まれる
14. 14 AIの成果物の課題に対する対策案 AIによるチェックが 中途半端 要件自体を細かくする チェックをこまめに するよう指示する 現象 対策 AIに依存しない チェックを設ける AIの成果物に 脆弱性が含まれる CI/CD
15. 15 CI/CDツールはどれが良いのか？ CI/CDツール 難易度 AWSとの連携しやすさ 変更のしやすさ GitHub Actions 低 中 中 GitLab CI/CD 中 中 中 AWS CodePipeline 高 高 低 ⚫ 開発時のチェックなどにはGitHub Actionsが扱いやすく向いています ⚫ AWS CodePipelineは、デプロイ直前の水際チェックに向いています 次のページから別の話題に移ります
16. GitHub Actionsによる CI/CDパイプラインの作り方
17. 17 GitHubのプルリクエストとGitHub Actionsによるチェック develop feature/実装計画 feature/実装 要件定義、設計書、実装計画 プルリクエスト プルリクエスト ソースコード ⚫ GitHubには、成果物のレビューを依頼するプルリクエストという機能があります ⚫ プルリクエストは、プルリクエストができた時にGitHub Actionsで自動チェックを 挟むことが可能で、チェックをした上でレビューすることが可能です
18. 18 GitHubのプルリクエストとGitHub Actionsによるチェック develop feature/実装計画 feature/実装 要件定義、設計書、実装計画 プルリクエスト プルリクエスト ソースコード ⚫ GitHubには、成果物のレビューを依頼するプルリクエストという機能があります ⚫ プルリクエストは、プルリクエストができた時にGitHub Actionsで自動チェックを 挟むことが可能で、チェックをした上でレビューすることが可能です • マークダウンの構文チェック • スペルミスチェック • 自動テスト • プログラムの構文エラー、 警告チェック
19. 19 GitHubのプルリクエストとGitHub Actionsによるチェック プルリクエストにおける実行結果画面
20. 20 GitHub Actionsの構造 リポジトリのディレクトリ構造
21. 21 今回作成するチェック内容 プルリクエスト Lint ソースコードの構文チェックなど 自動テスト SCA 使用ライブラリの脆弱性チェック SAST セキュリティ観点の 静的コードチェック Job Job Job Job チェックを早く終わらせるため並列で処理 .github/workflows pull_request_check.yml
22. 22 チェックごとにインストールと実行のステップがある プルリクエスト .github/workflows pull_request_check.yml Lint ソースコードの構文チェックなど 自動テスト SCA 使用ライブラリの脆弱性チェック SAST セキュリティ観点の 静的コードチェック Job Job Job Job ツールのインストール 実行 ツールのインストール 実行 ツールのインストール 実行 ツールのインストール 実行 Step Step
23. 23 各ツールのインストールを早くするためにキャッシュを利用する プルリクエスト Lint ソースコードの構文チェックなど 自動テスト SCA 使用ライブラリの脆弱性チェック SAST セキュリティ観点の 静的コードチェック Job Job Job Job ツールのインストール 実行 ツールのインストール 実行 ツールのインストール 実行 ツールのインストール 実行 Step Step Prepare キャッシュの作成 Job .github/workflows pull_request_check.yml
24. 24 実際のGitHub Actionsの実行画面
25. 25 ワークフローの起動条件 pull_request_check.yml
26. 26 ジョブとステップ、そして並列実行と直列実行の見方 ⚫ ジョブはそれぞれ並行して動作します ⚫ ジョブの中のステップは上から順に直列で動作します ⚫ ジョブはそれぞれがコンテナで動作します ジョブにruns-onでubuntu-latestとコンテナイメージ の指定があるのはそれが理由です pull_request_check.yml
27. 27 ジョブ同士の順番の持たせ方 ⚫ ジョブはそれぞれ並行して動作しますが、 needs属性でジョブを指定することで、 そのジョブが終わってから開始するよう指定可能です ⚫ 例えば、並列でジョブを実行する前に、 各ジョブの共通ライブラリをインストールしてキャッシュ化 しておく使い方ができます pull_request_check.yml
28. 28 キャッシュの指定方法（キャッシュを作る側） asdfとuvを使っているのでこの2つのファイルを使ってキャッシュキーを 生成 sha256sum関数でファイルをハッシュ文字列化 指定したパスそのものがキャッシュ対象 (～/はカレントユーザーのホームディレクトリの意味) pull_request_check.yml
29. 29 キャッシュの指定方法（キャッシュを使う側） キャッシュキーとキャッシュから復元したいパスを列挙 pull_request_check.yml 次のページから別の話題に移ります
30. GitHub Actionsによる 品質とセキュリティのチェック
31. 31 CI/CDでできる品質チェック チェック内容 説明 Lint（静的解析） ソースコードの書式、関数同士が繋がっているかなど をチェックする 自動テスト いわゆるユニットテスト、E2Eテスト カバレッジ 自動テストでどの程度ソースコードをテストしたか計測 する手法 一般的に80％を超えれば一定品質を保てていると 言われる SCA 使用ライブラリに脆弱性がないかチェックする SAST SQLインジェクションなど、脆弱なソースコードが含ま れていないかチェックする
32. 32 GitHub ActionsでLintを実行する ⚫ Lintのコマンドは、エラーがあるとエラーコードを返すので、その時点でGitHub Actionsのワークフローが中 断されます pyproject.toml pull_request_check.yml
33. 33 GitHub Actionsで自動テストを実行する ⚫ 自動テストのコマンドは、エラーがあるとエラーコードを返すので、その時点でGitHub Actionsのワークフロー が中断されます pyproject.toml pull_request_check.yml
34. 34 CI/CDでできるセキュリティチェック ⚫ SCA  使用ライブラリに脆弱性がないかチェックする  GitHubにはDependabotというSCAツールがあります  Dependabotは独立した機能でCI/CDには組み込みづらいので、今回はOSSの SCAツールであるTrivyを用いた方法を紹介します ⚫ SAST  SQLインジェクションなど、脆弱なソースコードが含まれていないかチェックする  GitHubにはCodeQLというSASTツールがあります  CodeQLの使用にはGitHub Advanced Securityの契約が必要な場合があるため、 今回はOSSのツールであるSemgrep（CE版）を使った方法を紹介します
35. 35 SCAのイメージ パッケージ名 バージョン インストール元 numpy 1.26.4 PyPI pandas 2.2.3 PyPI requests 2.32.3 PyPI fastapi 0.115.0 PyPI uvicorn 0.31.0 PyPI 識別子 対象パッケージ 影響バー ジョン 深刻度 CVSSスコア CVE-2024- 12345 requests ～2.32.3 High 8.8 使用ライブラリ一覧 脆弱性データベース
36. 36 脆弱性データベースのイメージ - CVEとNVDとJVN CVE 共通脆弱性識別子 NVD National Vulnerability Database アメリカ国立標準技術研究所(NIST) JVN Japan Vulnerability Notes JPCERT/CCとIPAが共同で運営 連携 連携
37. 37 GitHub ActionsでSCAを実行する trivy-config.yaml pull_request_check.yml
38. 38 GitHub ActionsでSASTを実行する ⚫ Semgrepについては、有料版であればSASTに加えてSCAとしても動作させることができます ⚫ 今回はSemgrepの無料版（CE版）を用いた例なので、SemgrepをSASTとしてのみ使用しています pyproject.toml pull_request_check.yml 次のページから別の話題に移ります
39. GitHub Actionsからの AWSの操作 チェックという趣旨からは外れますが、ここからAWSへのデプロイについて触れます
40. 40 GitHub ActionsからAWSを操作するにはOIDCを使用する GitHub Actions OIDC (OpenID Connect) AWS OIDCプロバイダ IAMロール IAMロールの ARN ⚫ GitHub Docs - アマゾン ウェブ サービスでの OpenID Connect の構成 ⚫ Amazon AWS Documentation - IAM で OpenID Connect (OIDC) ID プロバイダーを作成する
41. 41 AWSアカウントにOIDC用のプロバイダとIAMロールを作成しておく { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::123456123456:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringLike": { "token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:*" }, "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" } } } ] } IAMロールに設定するポリシー octo-org 組織に属する octo-repo リポジトリ内で実行されるすべて の GitHub Actions ワークフロー（＝全ブランチ・全タグ・全PR）から 使用可能という意味
42. 42 シークレットにOIDC用のIAMロールのARNを設定する pull_request_check.yml GitHubリポジトリの設定画面
43. 43 GitHub ActionsでAWS CLIでデプロイを実行する pull_request_check.yml
44. 44 GitHub ActionsのログをAIに分析させる このエラーログを生成AIに渡すと原因の 調査ができます
45. まとめ
46. 46 まとめ ⚫ AIは、AI自身の持っている情報などの鮮度ゆえに、十分な品質を保っていないコー ドを出力することがあります ⚫ これに対しては、AIを介さない機械的なチェックの方が有効です ⚫ GitHub ActionsなどでCI/CDを組めば、レビュー前やデプロイ前に品質チェックを 入れることができます ⚫ 品質チェックに時間がかかりすぎると、無視されたり、コストが問題になる可能性があ るので、並列化やキャッシュを活用してみてください