ひとりで始めた AI駆動開発、チームに広げて何が変わったのか

https://modn-tech.connpass.com/event/408631/

Transcript

1. L I G H T N I N G TA L K ／ A I 駆 動 開 発 ひとりで始めた AI駆動開発、 チームに広げて何が変わったのか @kenichi_odo 2026.10.27 AI駆動開発の悩みを語り合う会
2. なんでもプログラマー Salesforce × フロントエンド開発 社内AI活用推進 おおど けんいち @kenichi_odo や って き た こ と iOS / Android アプリ、Web アプリ（SAStruts）、 ストアドプロシージャ集計システム、Go + GAE GIS（地図）システム、 Salesforce 業務 SPA、プログラミングスクールフロントエンド講師、etc...
3. 会社紹介 株式会社フィーチャーブランチ 官公庁から企業まで、社会を支えるシステムを Salesforce で手がける Engineering Excellence, Social Progress 卓越した技術力で、社会の可能性を追い求める 中央省庁 千万人規模のシステムを、短納期で 地方自治体 数十自治体向けの、ミッションクリティカルな防災の仕組み エンタープライズ 数千人規模の予約システム サービス Salesforce 開発 Salesforce CoE 外部システム連携 DX・AI 推進支援
4. ひとりでの利用からチーム導入までの歩み 個人 チーム AI 界隈 Kiro ハーネスエンジニアリング 2025.7 2026.2 プレミアムシート 2025.8 ChatGPT 公開 Claude Code プレビュー Codex GA 2022.11 2025.2 2025.10 2023 利用サービス 2024 2025 2026 ChatGPT Cursor Claude（2024.4〜） Claude Code（2025.6〜） Codex（2025.11〜） FB 自作の AI レビュー 仕様駆動開発 2025.1 2025.12 Claude Code の PoC 全メンバー配布 2025.6 2025.11
5. 問題提起 チーム開発で抱えていた3つの悩み 1 2 ドキュメント 3 レビュー 実装 Jira や Excel で 管理がバラバラ コードレビューが回らない チームでの実装が難しい コーディング観点のレビューは自分ひとり チームは Salesforce には強いが、 どこに何があるか分からず、迷子になる 複数の案件が並行していて、見きれない モダンなフロントエンドは書き慣れていない プロトからの積み重ねで、 コードがスパゲッティ状態 仕様書.xlsx PJ-101 … PR 〇〇の対応 ? ? 一覧.xlsx PJ-245 △△の修正 PR PR PR PR PR PR PR PR PR PR 案件A 案件B 案件C プロト 4 プロト 3 プロト 2 プロト 1
6. 仕様書 ／ 暫定対処 2025年12月時点の仕様駆動ツールの課題 小さなバグ 1件 Kiro requirements.md design.md tasks.md レビューが 重い Spec Kit 機能 1つ spec.md plan.md research.md datamodel.md quick start.md contracts/ tasks.md ※ 2025年12月時点。小さな修正向けの軽い使い方（Kiro の Bugfix Spec など）は、2026年2月以降に出た チームで回せなかった理由 メンバーごとに、得意な技術も業務の知識も違う 当時のモデルはまだ弱かった ドキュメントの多い運用を、チームで回し続けるのは難しい
7. 仕様書 ／ 恒久対処 1ファイルを基本とする Spec の構成 Spec --title: '〇〇 仕様書' status: 'active' --- Kiro requirements.md design.md ## 概要（Overview） tasks.md ## 受け入れ条件（Acceptance Criteria） Spec Kit ## 対応範囲（Scope） spec.md ## 設計判断（Decisions） plan.md ID research.md D1 data-model.md quickstart.md D2 contracts/ D3 ADR（設計判断の記録）の形。1行に1つの判断・理由・状態 判断 理由 状態 送り先が決まらなければ、 メールは送ったら取り消せない。 送らずに止める 誤送信より、止めて個別に案内する 判定材料が取れないときは、 NG を見た利用者は申請に動く。 NG ではなく「確認できず」と出す 照会の失敗を NG と出すと、要らない申請を招く コピーした案件の担当は、 担当がコピー元のままだと、 一律でコピーした人の部署にする コピーした人の一覧に案件が出てこない 有効 有効 #B で撤回 tasks.md ## 対応詳細（Implementation） ## 対応状況（Progress Tracking） 大きな機能 README.md 〇〇.md △△.md フォルダに分けても、受け入れ条件と設計判断は README.md に書く #B＝この判断を後から覆した別の Spec
8. 仕様書 ／ 恒久対処 ADR の横断検索 リリース 1 リリース 2 Spec Spec Spec Spec Spec Spec Spec Spec Spec Spec この挙動、なぜ？ スクリプトで横断して探す 全 Spec の設計判断の表から リリース 3 Spec Spec Spec Spec Spec ✓ 判断と理由が見つかる ID リリース 4 リリース 5 Spec Spec Spec Spec Spec D1 Spec Spec Spec Spec Spec D2 判断 判定できなければ 「確認できず」と出す 通知先が0件でも、 操作は成功にする 理由 NG を見た利用者は申請に動く。 照会の失敗を NG と出すと、 要らない申請を招く 宛先がいない場面も 普通に起こる。 エラーにすると業務が止まる 2025.12 から1年近くで 各 Spec の設計判断の表 フォルダに分けた Spec も、設計判断は README.md Spec 1,000 ファイル超
9. レ ビ ュー ／ 暫 定 対 処 API 自作による AI レビューの行き詰まり 自作（Claude API） Claude Code GitHub Actions Spec 呼び出し元 Spec 呼び出し元 テスト テスト ✕ 変更ファイルだけを読む ✓ 変更ファイルから、関係する所まで探す 外のファイルは見に行けない。変更ファイルが増えるほど時間がかかる 呼び出し元・テスト・Spec も読む 変更ファイル そのほかのファイル 自作では、ツールとループから自前で作る必要があり、変更ファイルを読む実装で精一杯だった Claude Code にはツールとループが最初からある。人が書くのは、探し方と止めどころのプロンプトと設定 足りたら止める 上限は 50 ターン
10. レ ビ ュー ／ 恒 久 対 処 Claude Code GitHub Actions による観点別の並列レビュー AI が読むもの スキル 文書 コードレビュー コードレビューの 観点表 コーディング規約 仕様との照合 仕様書の観点表 Spec（仕様書） まとめて投稿 行コメント・総評 デグレ診断 デグレ診断 ① 変わった所を抜き出す（PR の意図は見ない） PR の作成 Spec（仕様書） ② Spec と突き合わせる 動作確認項目の作成 動作確認項目の 作り方 それぞれ投稿 動作確認項目 手作業の洗い出し データパッチや事前作業など PR コメントの @claude リリース作業の 洗い出し方 手作業の要否 質問への回答 PR の作成とは別に呼ぶ 返信
11. 実装 ／ 暫定対処と恒久対処 ハーネスで狭める品質のばらつき できあがりの品質 ハーネスあり シニア 依頼 AI ジュニア 道具を配っただけ 人によってばらばら 読ませる パートナー ハーネス AGENTS.md コーディング規約 どこに何があるか スキル 機能仕様書 Spec いまの仕様を1か所に 決めたこと プロジェクトのルール 3人とも、この辺りに寄る 低い CI の AI レビュー 品質 高い
12. 全体図 全工程で共有するハーネスと改善ループ 工程ごとの人と AI 仕様書づくり 人 インプットを 集める 実装 レビュワーが承認 レビュー 担当者が 動作を確かめる Spec を元に依頼 レビュワーが 完成を確認 AI が Spec を書く Claude Code・Codex が書く PR レビュー CI Issue から Spec のひな形を作る コーディング規約に沿う コード・仕様書レビュー 業務フローを引く 機能仕様書でいまの仕様を読む デグレ診断・手作業の洗い出し 仕様書の観点表で点検 セルフレビューして PR を作る 動作確認項目の作成 AI どの工程の AI も同じものを読む ハーネスの改善ループ 実施して分かったことを、ハーネスに戻す ハーネス AGENTS.md スキル Spec 機能仕様書 CI どこに何があるか 手順・コーディング規約 決めたこと いまの仕様 PR レビュー
13. 課題 チーム展開後に残る課題 新しい AI 情報のキャッチアップと適用 – 更新頻度の高いモデルや新機能、サービス 「これ AI がやったので分からない」をなくす （私です） – AI が正しさを判断できない業務（ドメイン）の理解が必要 AI なら計画も実装も文書も一瞬。ボトルネックはテスト – 手動 E2E から脱却し、Playwright などで E2E を自動化する – unit test も整備する ROI – OpenTelemetry で使用状況を取り始めた – 効果を測る軸は？ コードの変更量・コミット数・PR 数・不具合の数・作業時間
14. まとめ 1 情報を集約して、品質のぶれを減らす 2 業務の正しさは、AI に決められない 3 人がやらないことを決めきる AI の物量 Spec 機能仕様書 AI の出力 スキル ? 1か所に集約 業務 技術 AI と仕組みで AI ただし 誰が頼んでも ばらつきが減る 確かめていく 正しさは 人が判断する また 人が見る 人は見ない CI・テストが確かめる AI は決定論的ではなく、確率的。 作れることと、正しいと言えることは別。 AI の物量は、人では見きれない。 仕様・規約・手順を1か所に集めると、 技術の正しさは、AI と仕組みで 人は Spec と業務の正しさを見る。 品質を保てる確率は上げられる 確かめられるようになりつつある 見ない所は CI とテストで確かめる 誰が頼んでも「作る」までの 出来がそろいやすくなる 業務の正しさは、人が判断する 決めきるから、AI の速さについていける