AI駆動開発で実践してきたこと

Transcript

1. AI AI駆動開発で実践してきたこと 〜どこまで任せて、どう品質を守るか〜
2. AGENDA 今日の話の構成 前半は「何がどこまでできるのか」、後半は「実際どうやってきたか」 前半（約15分）：全体像編 Claude Codeとは何か／開発タスクの一生で見る「任せられる範囲」 後半（約15分）：実践編 品質を安定させるために実際やってきたこと（ハーネスを育てる／仕様の書き方） Claude Codeを使ったことがない人にも分かるように、前提から話します AI駆動開発で実践してきたこと 2 / 28
3. W H AT I S C L A U D E CO D E Claude Code とは チャットAIと違い、「提案」ではなく「作業」をするエージェント型AIツール Anthropic社のAIコーディングエージェント 指示すると、ファイル編集・コマンド実行・テスト実行まで自律的にこなす チャットAIとの違い チャットAI：質問に「答え」を返す Claude Code：手を動かして「成果物」を作る 使える形態も拡大中 CLI（ターミナル） AI駆動開発で実践してきたこと → GitHub連携 → ブラウザからのクラウド実行 3 / 28
4. HOW IT WORKS どう動くのか：自律ループ 1行ずつの補完ではなく、「書く→動かす→直す」のループを自律的に回す コードを編集 → ビルド・実行 → テスト → 失敗したら自分で修正 ↻ 人間は指示を出して、結果を確認する側に回る 従来のコード補完（1行ずつ提案するタイプ）との一番の違いはここ AI駆動開発で実践してきたこと 4 / 28
5. PRICING 料金の温度感 従量課金。普段使いのモデルなら数時間のコーディングで数ドル程度 料金はトークン（読み書きしたテキスト量）×モデル単価で決まる チームでは Amazon Bedrock 経由で利用 請求はAWSアカウントに一本化。月額プランのような利用回数制限なし モデルは使い分ける：普段はバランス型（Sonnet）、難所だけ上位（Opus） ※ 目安：Sonnet 5 は100万トークンあたり入力$3／出力$15（2026年9月時点） ※ 金額は使い方で大きく変動します AI駆動開発で実践してきたこと 5 / 28
6. OVERVIEW 全体像：開発タスクの一生マップ 人間／AI／共同で色分けすると、人間専任は「最初と最後」だけになる プロジェクト最初期（共同）：アーキテクチャ・技術選定／環境構築手順の設計 Issue作成 → レビュー・マージ 環境構築 → → 仕様書 → 実装 → テスト → Git / PR → CI/CD → デプロイ 全工程に横串（共同）：ハーネスエンジニアリング（AIが働きやすい環境の整備） 人間 AI・自動化 人間+AIの共同 ※ ここから工程を順に見ていきます AI駆動開発で実践してきたこと 6 / 28
7. STEP 1-2 / 6 工程1-2：環境構築・仕様書 環境はlockfileで再現可能にし、仕様書のドラフトはAIが書く 環境構築：依存関係はlockfile（ package-lock.json 等）で固定 誰の環境でもコマンド1つで同じ環境を再現できる セットアップ手順・スクリプトもAIが書ける。AIが読める形にしておけば、AI自身も環境を整えられる 仕様書：要件を壁打ちしながらAIがドラフト作成 既存コードから現状仕様の書き起こしも効く 人間の仕事は「書くこと」から「正しいかを判断すること」へ AI駆動開発で実践してきたこと 7 / 28
8. STEP 3-4 / 6 工程3-4：実装・テスト 実装もテストも「書く→実行→落ちたら修正」までワンループでAIが回す 実装：ループごと任せられる。Terraform / CDK などのIaCも同じ土俵 テスト：テストケース設計→テストコード実装→実行→修正までAI テストケース設計 → テストコード実装 → 実行 → 失敗したら修正 ↻ ※ テストの「正解の基準」が妥当かのレビューは人間に残る（→後半の品質の話につながる） AI駆動開発で実践してきたこと 8 / 28
9. STEP 5-6 / 6 工程5-6：Git操作・CI/CD ブランチ作成からPR作成・説明文まで標準機能。CI/CDの定義もAIが書く git / gh CLI をAIが直接操作 ブランチ運用、コミット分割、PR作成+変更内容の説明文生成 lint / test / build のCI、デプロイパイプラインのワークフロー（YAML）作成も任せられる AI駆動開発で実践してきたこと 9 / 28
10. NEW EXPERIENCE Issueを渡すと、レビュー待ちのPRが返ってくる 修正のやりとりまでGitHub上で完結する。ローカル環境もエディタも不要 Issueを渡す → AIが実装 → PRが返ってくる → 人間がレビュー 修正も、PRにレビューコメントを入れてClaudeに修正依頼するだけ。同じPRが更新されて返ってくる 指摘は日本語の文章でOK。コードを書かない人もレビューコメントで開発に参加できる AI駆動開発で実践してきたこと 10 / 28
11. HUMAN'S ROLE それでも人間に残る3つ 残るのは「何を作るか」「良し悪しの判断」「権限の付与」 01 02 03 Issue作成 レビュー アカウント・認証情報 何を作るか・なぜ作るかの定義。タスクの入 品質の最終責任。AIによる自動レビューは補 AIに渡す権限の範囲を人間が設計する。暴走 口であり、ここの質が成果の質を決める。 助になるが、承認するのは人間。 を防ぐ統制であり、安全装置。 「人間が残る」=不完全さではなく、統制点が明確ということ AI駆動開発で実践してきたこと 11 / 28
12. SUMMARY 1/2 前半まとめ 実作業の大半はAIに任せられる。人間は「定義・判断・権限」に集中する 誰がやるか やること 人間 Issue作成（タスクの用意） / AI 環境構築 人間+AIの共同 / 仕様書作成 アーキテクチャ・技術選定 / レビュー / 権限・認証情報の管理 実装（IaC含む） / テスト / Git操作 / CI/CD / ハーネス整備（AIの作業環境づくり） ※ ここまでが「できること」の話 AI駆動開発で実践してきたこと 12 / 28
13. ただし—— 任せただけでは、 品質は安定しない AIは指示のたびに出来がブレるし、同じミスも繰り返す。 後半は、それを仕組みで抑えるために実際やってきたことの話。 AI駆動開発で実践してきたこと 13 / 28
14. PRACTICE OVERVIEW 実践の全体像：実際に回してきた流れ 「型を先に作り、仕様を固めてから任せる」——準備に投資してから実装をAIに渡す ① アーキテクチャ・規約 → 正解の形を決める → ⑤ Skillで実装 テストコード込み → ② 見本サンプル 形を見せる ⑥ 実装から設計書生成 → → ③ Skill化 手順書にする → ④ 仕様の用意 要件+変更点+テストケース ⑦ 設計書レビュー PDFで完結 ここから順に見ていきます。前半で触れた「ハーネス」「仕様」の実践版 AI駆動開発で実践してきたこと 14 / 28
15. P R E PA R AT I O N 1 準備(1)：アーキテクチャとコーディング規約を先に決める AIに書かせる前に、「正解の形」を人間が決める。ここが曖昧だと出力がブレる 最初にアーキテクチャ（層構造・依存の方向）とコーディング規約を設定 AIと壁打ちしながら決めるが、決めるのは人間 規約は行動レベルで具体的に 「きれいに書く」では行動が変わらない。「DBアクセスは必ずrepository層を経由」のように書く では、どういう思想でこの「正解の形」を決めたか（→次の2枚） AI駆動開発で実践してきたこと 15 / 28
16. DESIGN PHILOSOPHY 設計思想：品質保証をテストに寄せる 機械的な正しさはテストで自動的に担保し、人間は「業務的に正しいか」に集中する AIに実装を任せる以上、品質保証の軸をテストに置く アーキテクチャもテストのしやすさから逆算して設計 網羅テスト+ミューテーションテストで、テスト自体の質まで機械的に担保 ミューテーションテスト=コードにわざとバグを埋め込み、テストが検知して落ちるかを確認する「テストのテスト」 これで人間のレビューは「業務的に正しいか」の判断に絞れる AI駆動開発で実践してきたこと 16 / 28
17. ARCHITECTURE 関数型アーキテクチャ：AIの苦手な「構造化」を強制する 構造をアーキテクチャ側である程度強制し、テストコードを書きやすい状態を保つ 副作用（DB・外部アクセス）と純粋なロジックを分離する構成 純粋関数=同じ入力なら必ず同じ出力。入出力が明確でテストが書きやすい 構造化はAIが苦手な部分。アーキテクチャ側で「従うべき形」を決めて崩れを防ぐ 前ページのテスト重視の思想と地続き：テストしやすい構造を先に敷いておく AI駆動開発で実践してきたこと 17 / 28
18. P R E PA R AT I O N 2 準備(2)：見本となるサンプルを作る 文章の規約より、動く見本1つ。AIはサンプルの形を忠実に真似る 代表的な処理を規約どおりに実装したサンプルを先に作成 以後の実装は「このサンプルと同じ形で」と指せる → 出力の形が揃う 規約（ルール）とサンプル（例）はセットで効く AI駆動開発で実践してきたこと 18 / 28
19. P R E PA R AT I O N 3 準備(3)：実装手順をSkill（手順書）にする 毎回同じ説明をするくらいなら手順書化する。誰が・いつ頼んでも同じ品質になる Skill=AIが読む作業手順書（手順+チェックリスト+テンプレートのセット） 実装用Skill：仕様の読み方→実装の進め方→テストコード作成までを定義 レビューはレビュー用Skillを用意し、サブエージェント（別のAI）に実行させる 実装した本人（AI）に自己採点させず、まっさらな目でレビューさせるため プロンプトで毎回説明すると説明の質でブレる。Skillなら品質が再現可能 AI駆動開発で実践してきたこと 19 / 28
20. GROWING THE HARNESS ハーネスは「育てる」もの：ミスの受け皿4段階 AIのミスは「注意」ではなく「環境」で再発防止する セッションが変わるとAIは記憶ゼロの「別人」。注意は消えるが、環境は残る ① 毎回言う プロンプト → ② 常に読ませる 規約・ルール → ③ 機械的に検証 lint・テスト → ④ 手順書化 Skill 左ほど手軽だが揮発し、右ほど手間だが確実に資産になる ミスが起きるたびに、対策をこの4段階のどこかに1つ入れる。これが「育てる」の正体 AI駆動開発で実践してきたこと 20 / 28
21. CASE STUDY 実例：このスライドもSkillで作っている ミス1つ→手順書に1行。積み重ねがそのまま品質の履歴になる スライド作成Skillに実際に追記されたルール（すべて実際のミス由来） 「絵文字はPDF化で描画されない → 使用禁止」 「はみ出しに気づけない → 全ページ画像化して目視検証を必須化」 最初は崩れたスライドを出してきた → 今は同じ手順で安定して回る ミス発生 → AI駆動開発で実践してきたこと 手順書に1行追記 → 同じミスが再発しなくなる ↻ 21 / 28
22. S P E C I F I C AT I O N 仕様の用意：要件定義書+変更点+テストケース 仕様は「文書（ルール）+テストケース（例）」のセットで渡すと、解釈のブレを大きく減らせる 用意したもの：要件定義書 / 要件変更点 / テストケース（GWT形式） 文書だけ渡すと、AIは解釈の隙間を勝手に埋めてしまう。検証可能なテストケースが出力を縛る GWT=Given（前提）・When（操作）・Then（期待結果）の3点で書く受け入れ基準 例：Given カートに商品が1つある / When 同じ商品を追加 / Then 数量が2になる 具体例なので人間同士の認識合わせにも効き、テストコードとの対応も素直 AI駆動開発で実践してきたこと 22 / 28
23. I M P L E M E N TAT I O N 実装：仕様+Skillで、テストコードまで一括 仕様一式を渡してSkillで実装。テストコード作成・実行・修正までワンループ 仕様一式を渡す 要件+変更点+GWT → Skillで実装 テストコード込み → テスト実行・修正 落ちたら自分で直す → サブエージェントがレビュー レビュー用Skill → 人間の最終レビュー 準備（規約・サンプル・Skill）が効いて、誰の指示でも出力の形が揃う 人間は結果とコードの最終レビューに集中できる AI駆動開発で実践してきたこと 23 / 28
24. D O C U M E N TAT I O N 設計書は実装から生成する 設計書は「書く」ものから「実装から起こす」ものへ。実装と乖離しない 実装完了後、コードから設計書をAIが書き起こす レビューは設計書を基に行う（コードを直接読むより見通しが良い） 修正が入ったら設計書も追随して再生成できる 実装 → 設計書を生成 AI駆動開発で実践してきたこと → 設計書でレビュー → 修正+再生成 ↻ 24 / 28
25. DELIVERABLES ドキュメントはPDFで通す（エクセルは使わない） 設計書はPDF出力し、お客様レビューまでPDFで完結させる テキスト（Markdown）→PDF生成なので、AIによる生成・再生成と相性が良い エクセル設計書は自動生成・差分管理と相性が悪く、AIからも扱いにくい お客様レビューもPDFへのコメントで運用 AI駆動開発で実践してきたこと 25 / 28
26. SUMMARY 2/2 後半まとめ 型と仕様への先行投資が、AIの出力を安定させる 思想：品質保証はテストに寄せる（網羅+ミューテーション）。人間は業務的な正しさに集中 型：アーキテクチャ（関数型）・規約・見本サンプル・Skill（=ハーネス。ミスのたびに育てる） 仕様：要件定義書+変更点+テストケース（GWT）のセットで渡す ドキュメント：実装から生成し、PDFで完結 どれも一度作れば、チームの資産として残る AI駆動開発で実践してきたこと 26 / 28
27. CONCLUSION 全体まとめ 実作業の大半はAIに任せられる。人間は「定義・判断・環境整備」に集中する 前半：開発タスクの一生の大半は、すでにAIに任せられる 後半：任せて品質を保つ鍵は、型と仕様への先行投資 まずはIssueをひとつ、AIに渡すところから始められます AI駆動開発で実践してきたこと 27 / 28
28. AI CLOSING 実作業はAIへ、人間は定義・判断・環境整備へ 型と仕様への投資が、チームの資産になる ご清聴ありがとうございました