AIドリブンのソフトウェア開発 - うまいやり方とまずいやり方

2025.08.23 塩尻サイバーセキュリティ勉強会

Transcript

1. AIドリブンのソフトウェア開発 AIドリブンのソフトウェア開発 うまいやり方とまずいやり方 うまいやり方とまずいやり方 できるやつを採用しても、 できるやつを採用しても、 現場の生産性も品質も向上しなかったのはなぜか思い出せ 現場の生産性も品質も向上しなかったのはなぜか思い出せ   オカダリョウタロウ (@okdt) オカダリョウタロウ (@okdt)  AI  開発  セキュリティ  ガバナンス Copyright by オカダリョウタロウ
2. なぜ成果が出ないのか？  すごい知見と経験のある優秀な人材を採用した！  ≒ 最新最強のAIモデルを使うツールを導入した！  すごい！束の間、生産性は...上がらない？  Copyright by オカダリョウタロウ
3. 直球ストレートどまんなか出力の切れ味はどうだ！  見た目動作する、でも、CSRF対策なし  セキュリティリスク発生時のログ出力なし  命名規則はフリーダム 規約違反（username? user? ）  表面的には機能するコード しかし...  潜在脆弱性 app.post('/login', (req, res) => { const { username, password } = req.body; if (authenticate(username, password)) { req.session.user = username; res.redirect('/dashboard'); } else { res.status(401).render('login', { error: 'Invalid credentials' }); } });
4. Key Question：本当に成果を決めるものは？  成果は「直球の正論（コンテンツ） 」だけでは決ま らない  成果を決めるのは コンテキスト（前提）× ガバナン ス（意思決定）  優れたコンテンツは、適切なコンテキストとガバナ ンスをふまえてはじめて価値になる コンテンツ コンテキスト ガバナンス 価値ある結論   
5. コンテキストとは  経緯 レガシーシステム、過去の判断、技術的負債の歴史  制限 法規制、契約、技術的依存関係、インフラ制約  習熟 チームスキル分布、経験レベル、学習曲線  リソース 人員、時間、予算、インフラ、ツール環境 AIは「コンテキスト」を理解できない 
6. コンテキストの落とし穴  AIは前提を知らない → 無謀な提案や現実離れした 解決策  歴史的経緯・技術的負債・組織の制約を考慮できな い  チームのスキルセットや学習コストを無視した提案 よくある例： "このフレームワークに全部置き換えよう！"  ! 
7. ガバナンスとは  意思決定プロセス  検討 → レビュー → 承認 → 実行  役割分担  PdM（何を）／ PjM（どう進める）  TL（どう実装するか）  優先順位  安全 ＞ 信頼 ＞ コスト トップダウン ボトムアップ 集中型 分散型  指示型ガバナンス 経営層が基準を定め、集中的に判断 基準：明確・統一 判断：トップダウン  委任型ガバナンス 権限委譲と共通基準の徹底 基準：統一 判断：権限移譲  合意形成型ガバナンス 現場提案と集中審議 基準：集中型 判断：現場参加  自律分散型ガバナンス チーム単位の自律判断 基準：柔軟 判断：現場主導 Copyright by オカダリョウタロウ     バランスが 重要
8. ガバナンスの欠落  直球出力は「誰が／なぜ決めたか」を無視  合意形成なしに進行 → チーム分断  リスク管理・セキュリティ考慮の欠如  長期的なメンテナンス性と信頼性の低下 組織の分断 マネージャー チームリード 開発者A 開発者B 
9. "" "知性" - 活用の鉄則  まずコンテキスト：「何のために、どのように作る か・何を遵守すべきか・どんな前提か・選択肢があ る場合、何を優先するか・不明なら尋ねるべきこ と」の要件情報が必要。  段階的なアウトプット：妥当性をチェックしつつ内 容を示唆を得て調整し、要件と期待のスコープと解 像度のレベルを調整する。  ガバナンス/どのように決めるか：誰が、何を見 て、どうOKにするかはアウトプットの質とは別。  AI活用の3原則  コンテキスト  段階的に示唆を得る  ガバナンス 合言葉「あとで確かめる」よりも「先に教える」 合言葉「うのみにする」ではなく「示唆を得る」
10. ディベロッパー：まずい vs うまい Copyright by オカダリョウタロウ まずいやり方   局所的なプロンプトでAIコード出力、その ままコピペ  セキュリティ対策を無視  コーディング規約を無視 # 再現性のない雑なプロンプト # コードをそのままコ ピペ # セキュリティチェックなし # レビューなし うまいやり方   共通プリプロンプトを提供  Lint/CI＋SASTでチェック  Human In the Loop レビュープロセス確立 # プリプロンプト # 自動セキュリティスキャン # レ ビュー必須 VS
11. Cursorコーディングルール設定例  `.cursor/rules/security_rules.mdc` にセキュリティ指針 をまとめてチーム全体で活用可能 --- description: alwaysApply: true --- ASVS 4.0 Level 2 基準を遵守する。 - 認証 : bcrypt/Argon2 でハッシュ化 - JWT: 適切な有効期限設定 - RBAC: 適切な権限管理 - API Security: HTTPS 必須・入力検証 - セキュリティヘッダー : HSTS, CSP 導入  ルールを置くだけでAI⇔人間の齟齬・手戻りを最小化できる Copyright by オカダリョウタロウ
12. MCP(Model Context Protocol)とは？  AIアシスタントと社内外システム間を安全に接続で きる新しい標準プロトコル  様々なデータ連携をMCPサーバ経由で実現  GitHub、Slack、Google Drive、DB等に接続  チーム全体で「同じ前提・最新データ」を活用  Block、Apollo、Zed、Replit、Codeium、 Sourcegraph等が採用中 https://modelcontextprotocol.io/ AIアシスタント MCPサーバ 標準プロトコル データソース GitHub / Slack DB / ドキュメント チーム全体で同じコンテキスト 一貫性のある高品質な出力 Copyright by オカダリョウタロウ
13. チーム全体で"手戻り激減"AI開発を実現するコツ  `.cursor/rules/`＋MCP活用のポイント  駆け出しエンジニアもシニアも、同じルール・文 脈・最新情報をAIに"先に教えて送り込む"のがカギ  人間レビューやテストを必ず実施（AIのセルフチェ ック―「遵守OK／要修正」も併用）  組織／PJの中で「成功パターン」をチームテンプレ 化して属人化を抑える  AIコード生成品質が安定、事故や手戻りが激減！ AI Dev TL QA PdM rules MCP テンプレ レビュー Copyright by オカダリョウタロウ
14. テックリード：まずい vs うまい まずいやり方   AIからの改善提案を盲信して採用  移行コストやスキル不足によるメンテナン スリスクを無視  チーム内合意形成の不在 # AI が提案した新フレームワーク # メリットだけを考慮 # 現状のシステム分析なし # チームの習熟度を考慮せず うまいやり方   比較表＋影響範囲を明示させて検討  段階的移行計画と技術・組織リスクの評価  関係者の合意で方針決定 # メリット・デメリット分析 # 習熟コスト試算 # PoC 検証後に意思決定 # 段階的な適用範囲設定 VS
15. QA：まずい vs うまい まずいやり方   AIテストを無検証投入  重複・冗長・平坦なテストケース  ビジネスリスク・優先度を考慮せず # AI 生成したテストを全て実行 # 重複ケースがあっても気にしない # リソース消費量が増大 うまいやり方   AIで網羅的テストパターンをドラフト  リスクに基づいて優先度を調整  レポートの精緻化と分析 # AI で広範囲テスト生成 # ビジネス価値に基づく優先度付け # 重要度に応じたリソース配分 VS
16. セキュリティ：まずい vs うまい まずいやり方   OWASP Top10を避けるなどの雑な指令  システム特有の脅威を度外視  ビジネスリスクと切り離した  // セキュリティチェック if (checkOWASPTop10Compliance(code)) { return " 安全 "; } else { return " 危険 "; } うまいやり方   検証レベルの検討 ASVS ＋ 危険なコンポー ネントの特定 KEV ＋ ビジネスリスクを統合  SCA 情報を継続分析  ビジネスリスクによる対応優先度の調整  // 高度なセキュリティ評価 return securityEngine.evaluate({ asvs: getASVSChecks(), kev: getLatestExploits(), bizRisk: getBusinessContext() }); VS
17. Product Management(PdM)：まずい vs うまい まずいやり方   出典不明の市場調査を鵜呑み  データの信頼性検証なし  バイアスのかかった分析を盲信 「 AI が予測した市場規模は 10 億ドル！」 「競合は全て導入済み（要出典） 」 「すぐに投資しないと遅れる！」 うまいやり方   ICEスコアで優先順位付け  仮説検証にAIを活用  複数情報源で裏付け確認 Impact: 顧客価値（定量化） Confidence: 成功確率（データ根拠） Ease: 実現難易度（工数・リソース） VS
18. Project Management(PjM)：まずい vs うまい まずいやり方   AIの楽観予測をそのまま採用  異常に短い開発期間を承認  リスク考慮なしのスケジュール // プロジェクト計画 timeline = ai_suggested_timeline; approve(timeline); // 検証なし うまいやり方   AIでリスク予兆を検知  リスク評価と承認の共有（見えるところで やる）  過去の実績データと比較検証、調整 // プロジェクト計画 risks = ai_risk_detection(); timeline = human_review(risks, ai_timeline); VS
19. Sales & Promotion：まずい vs うまい まずいやり方   AIコピーをそのまま利用→炎上リスク  ブランドトーンの整合性確認なし  法的・倫理的問題を見逃す 「競合他社より 100% 効果的！」 「特許技術で永久保証！」 → 根拠不明な主張 → 法的リスク大 うまいやり方   複数案を生成・比較検討  法務・ブランドチェック必須  A/Bテストで効果検証 1. AI 複数案生成 2. 法務・ブランド確認 3. 小規模 A/B テスト 4. データに基づく最適化 VS
20. Customer Success：まずい vs うまい まずいやり方   AIが勝手に提供内容や価格を提案  顧客との経緯を理解せずに対応  企業信頼の失墜リスクを軽視 「お客様の状況を確認せず、 80% 割引を自動提案して しまいました」 うまいやり方   AIは予兆検知と選択肢ドラフトに特化して 担当  提案は人間が文脈を加味して活用  顧客満足と企業方針の両立を目指す 「 AI が検出した解約リスクを担当者が確認し、状況に 応じた最適な提案と改善方針を共有しました」 VS
21. Site Reliability Engineer(SRE)：まずい vs うまい まずいやり方   AI自動修復を即本番適用  介入時の影響範囲のレビュー・判断なし  権限設定が大きすぎて想定外の副作用の可 能性 # AI 自動修復ツール実行 if detect_issue(): auto_fix = generate_solution() deploy_to_production(auto_fix) # レビューなし、即適用 うまいやり方   AIの対応提案からRunbookを策定  SREによる影響範囲検討と承認を確立  段階的検証と効果測定による調整 # AI 修復プロセス if detect_issue(): solution = generate_solution() notify_engineers(solution) if human_approval(): deploy_with_monitoring(solution) VS
22. UI/UX：まずい vs うまい まずいやり方   ブランドガイドラインを無視した派手なデ ザイン  アクセシビリティ要件を考慮せず  ユーザーテスト省略で主観的判断 デザイン例  ブランド不適合デザイン うまいやり方   AIで複数デザイン案を素早く生成  ブランドガイドラインに沿った調整  WCAGアクセシビリティ基準に準拠 デザインプロセス AI案出し → ブランド適合 → アクセシビリティ確保 VS
23. データアナリスト：まずい vs うまい まずいやり方   AIが出した相関関係を因果関係と誤解  統計的有意性のみで意思決定  ビジネスコンテキスト無視の分析 # 相関係数が 0.8 だから # きっと因果関係がある # 仮説検証なしで施策実行 うまいやり方   AIで探索的データ分析を実施  人間が因果関係を専門知識で解釈  意思決定へ責任を持って接続 # AI で複数の相関パターン発見 # ドメイン知識で仮説構築 # A/B テストで検証後に実装 VS
24. TIPS  空プロンプト禁止：前提を書かずにAIに頼まない  3点セット：①技術前提 ②守るルール ③優先順位 を毎回入れる  AIのセルフチェック：出力の末尾に「守った／直しが必要」を自己 宣言  足あとを残す：誰がOKしたか、根拠は何かをメモ  数字で見る：やり直し回数、違反率、かかった時間を定点観測 AIとの協業を効果的に する5つの基本ルール      Copyright by オカダリョウタロウ
25. AIにも「できるやつ」にもオンボーディングが必要なのよ オンボーディング/プリプロンプトの必須要素  目的：AIに期待する成果物と達成基準  背景：プロジェクト経緯やビジネスコンテキスト  ルール：コード規約やアーキテクチャ制約  禁止事項：避けるべきパターンや技術  優先度：安全性・パフォーマンス・保守性の順位  出力条件：フォーマット・構造・詳細度  自己検証：成果物の妥当性確認手順 オンボーディング比較  新人研修 企業文化・規則・プロジェクト背 景・チーム役割の共有  AIオンボーディング コンテキスト・ガバナンス・規約・ 優先度の明示的注入  共通点 最初の投資がその後の全成果を左右 する
26. ありもののセキュリティ基準を徹底して活用する  OWASP ASVS 5.0の体系的な要件をベースにレベル も指定する(例："OWASP ASVS v5.0 Level 2")  CISA KEVカタログの最新脆弱性情報を活用 (DeepResearchをつけると良い)  業界特化、システム特性、組織固有のリスクをふま えて、対応の重要度、優先を判断していく  AIリスク：OWASP LLM Risk Top 10 / AISVS標準に よるAI固有リスク対策を活用するようおすすめ // 高解像度プリプロンプト例 " あなたはソフトウェアセキュリティ専門家で す。 OWASP ASVS 5.0 の V3( セッション管理 ) をもとに以下のコードをレビューし てください。コンポーネントリスト (SBOM) については、 CISA KEV カタログリス トを照合して有無を報告してください。当社の B2C サービスの データ保護ガイド ラインを踏まえて評価し、修正を提案してください。 " OWASP ASVS CISA KEV ビジネスリスク 組織規範
27. 継続更新の仕組み  KEV自動取得 CISAのKnown Exploited Vulnerabilitiesを自動収集し、最新脅威情報を 常にキャッチアップ  ビジネスリスク四半期更新 ビジネス優先度とリスク評価を四半期ごとに更新し、セキュリティ対応 の優先順位を最適化する。同業他社、類似アーキテクチャのシステムの 被害を踏まえる。  セキュリティ状況の日次更新 CI/CDパイプラインを活用してコンポーネントとソースコードをスキャン し、改善ガイドを得る。また、SBOMを自動生成し、更新する  KEVカタログ  ビジネスリスク  自動更新
28. まとめ  「できるやつ」AI直球出力だけでは成果は出ない。 どうやってオンボーディングするか、どのように権 限を決めるかが肝心  コンテキスト × ガバナンス  ROI実現にはAIオンボーディング＋調整の継続が必 須 コンテンツ （直球出力） コンテキスト （前提） ガバナンス （意思決定） 成功
29. Takeaway  コンテンツ単体の生成で満足しないこと  コンテキスト＋ガバナンスを注入する方法を模索せ よ(RAGとかMCPとかマイクロサービスとか)  継続調整で最適な仕組みを構築していくこと  AIは道具であり、文脈理解と人間判断が成功の鍵  ROI ↑ コンテキスト × ガバナンス = 調整可能な知性の活用