2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

VibeCodeingのためのDevSecOpsを検討・実装してみた話

2
Last updated at Posted at 2026-04-09

はじめに

こんにちは、しまむらです。

個人的に趣味でイベントをやっていて、Mobiriseというレスポンシブデザインにも対応してたビルダーを使ってました。
ただ、すでに同じデザインで5年以上経過したこともあり、AstroとTailWindCSSを使ってWebsiteを大幅にリニューアルしました。

クラウドエンジニアがAIでデザインからコーディングまで…

とかはいっぱい転がりすぎてるので、割愛します

「どう作ったか」よりも、リニューアルに伴うDevSecOps(開発セキュリティ運用)とAIコードの品質検証に焦点を当てて、どのようにフローを設計し検証したかをしたいと思います。

作ったイベントサイトは以下です。

技術スタック・ツール

とはいえ、どういったもので作ったのか?は説明が必要だとおもいます。
フレームワークと開発ツールは以下の通りです。

FrameWork

開発環境

Tool 備考
MacBookAir 自作PCでWindowsのWLS2使ってたんですけど、AI周りの関係とか諸々で切り替えました。満足。
Stitch Google製のFigmaみたいなやつ
GeminiCLI 会社だとClaudeCodeなんで、こっち使ってみてます
VSCode 文言や微調整で、コード直に編集するため

AIコーディング時代のコード品質とレビューの課題

AIがコーディングを補助する環境が増えています。
むしろ、今回のようにAIがコードを作成するが人間がレビューできないという状況がすでにありえる状況だと思っています。人間がボトルネックになっている現状、「レビューをどこまで減らせるか?」が品質担保の大きな課題です。

SonarQubeのCEOがBlogでいい記事を出していて、それに結構影響を受けています。

個人的な理解でいうと、分解すると2つになると思っていて。

  • BlackBoxになっているCodingAgentにどう品質ルールを守らせるか(コード品質の担保)
  • 人間がインプットしたコンテキストとアウトプットをどう一致させるか(機能要件の充足)

という感じでしょうか。

Qiita-ACDC.drawio.png

(1) どうコード品質を満たすのか?

過去のDevSecOpsの文脈を厳密に適用するだけだと考えています。基本に立ち戻りましょう。
可能な限り、Shift Leftする。
今まで人間がレビューし、アジリティの優先の下に許容した脆弱性やその他の指摘、それを解決することを前提にします。作るのはAIですし中身はブラックボックスですから、"できない、優先度が低い"ではなく"できているのが当たり前"にします。

  • セキュリティツールによって、違反を診断
    • Grype / Trivyによる脆弱性診断
    • Grant / ORTによるライセンス診断
    • Aikido.dev / SonarQubeによるSAST
  • SBOMを必ず生成、履歴化することで検知や対応実績を保証する
    • Syft / Trivy / sbom-toolによる生成
  • AI CodeReviewによるロジック分析

(2) どう機能要件の充足を判断するか?

ここはとても難しいところだと思っています。
以下はちょっと考えているとこですが、まだ実装のイメージがついていません。
今回はアウトプットがイベントのWebサイトなので、最終的には人間で目検してます。

  • コードの入力コンテキストと対応チケットの整合をAIで比較
  • Staging環境とチケット内容を比較する仕組みを構築
  • ドメイン知識も関わるため現状は最適化段階
  • この部分がAI適用で特に難しいポイントだと思ってます

今回の開発からリリースまでの施作(Build > Ship > Run)

よくある、開発開始からリリースまでのフェーズでやったことを整理してみたいと思います。

Qiita-ACDC-ページ-2.drawio.png

Buildフェーズ(Local開発環境)

  • AIの指示として、Syft/Grype/Grantを組み合わせてビルド前に脆弱性とライセンスをチェック
  • 本来はここでSASTも完結させたいが、今回はAikido.devの無料枠利用のためリアルタイムチェックできず
  • (昨今の攻撃を考えて)npmの取得をTAKUMI Guard経由にする

Shipフェーズ(GitHub)

  • PushとPRのタイミングで、以下のGitHubWorkflowでのCIチェックを実施する
    • Syft + Grypeでの脆弱性検査
    • Syft + Grantでのライセンス検査
    • Aikido.dev連携でのセキュリティチェック
  • PRが作成されて、CIチェックがOkなら、ステージング環境に自動デプロイ
  • (理想)デプロイ後はAIによるコンテキスト比較チェックを実施
  • (現実)デプロイ後は人間よる動作確認

Runフェーズ(ホスティングサイト)

  • 本番マージ後にリリース完了
  • 毎日、Google Julesにセキュリティエージェントロールを設定して自動スキャン
    • 標準でセンチネルロール(セキュリティ担当者)が準備されてるので、簡単に準備できる
      image.png
    • 脆弱性や問題があれば自動的に修正PR(ドラフト)が作成される
      Qiita-ACDC-ページ-3.drawio.png
  • (Jules/BETA) Suggestion機能で、自動でリポジトリの分析と修正すべき箇所も教えてくれる
  • (Aikido.dev) ページスキャン機能があるので、定期的に問題がないかを確認

4. 各フェーズでのポイントまとめ(画像付き)

  • Build: プッシュ前チェックでの確実な脆弱性とライセンス違反の解消
  • Ship: ステージングでのチケット・コード・環境整合性のAI検証
  • Run: 日次自動スキャン&自動修正PR作成で運用負荷軽減

まとめ

  • AIコーディング時代だからこそ、以下が重要
    • コードに何を守らせるのか?という基準を決め、教えること
    • CIにおける品質ゲートウェイの設計(基準と運用ルール、可監査性)
  • 静的解析やコードレビューAI活用でレビュー負担軽減と品質維持を両立したい
    • ルールを満たすことはAIは得意なので、積極的にルールを教えて、修正させる
  • チケットとコードの整合性確認は今後の課題。実際のプロダクトに活用する場合は、ドメイン知識をどう活かすか?や比較するかの検討は必須だと考えている
  • 定期的な運用スキャンと自動修正PRでセキュリティリスクの早期対応が可能
    • 攻撃側もAIを使って速度・頻度が上がっているなら、防御側もそれに合わせた活動が必須

興味のある方はぜひ試してみてください。
もしご質問や詳細が知りたい場合はコメントお待ちしています。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?