AIのスピードに負けないための開発フロー

https://sotas.connpass.com/event/398322/
Sotas×カミナシ×estie｜AIのスピードに開発組織はどう追いつくのか？ (2026/10/15) 登壇資料

Transcript

1. AI のスピードに負けないための開発フロー 開発の中で、AI に任せたことと⼈に任せたこと 三上和⾺ X：@kyuridenamida 株式会社 estie（エスティ） テックリード 2025 年末からの副業を経て、2026 年 7 ⽉に estie へ参画。新規プロダクトの開発とAI エージェント を使う開発フローの改善を担当。 前職では約 9 年、検索‧マッチング品質の改善や NLP‧ML Platform の開発に従事。 Sotas × カミナシ × estie 合同 LT 2026-10-15 © 2026 estie, Inc. 1
2. estie は商業⽤不動産の情報や業務を⽀える Web アプリを作っています 商業⽤不動産とは、オフィスや物流施設など、事業のために使われる不動産のこと © 2026 estie, Inc. 2
3. 何を作っているか：顧客データを取り扱う新規プロダクト AI に任せやすい形で少⼈数で業務アプリをゼロから作っている 少⼈数 新規 ⾃前 DB なし セールス、PM、EM、開発者 （PM = プロダクトマネージャー、EM = エンジニア リングマネージャー） お客様の業務データを預かる セキュリティ要件が厳しい 顧客データは別サービスに隔離 アプリは API 経由でしか触れない AI に任せやすくするための設計判断 2 つ 業務ルールがコードに載っている 永続化層は遠くに ドメインの⽤語と制約をコードとその構造に反映 。 AI 向けの説明書を別に書くのは最後 DB などデータを保存する層は別リポジトリ。 アプリ側から直接触れない © 2026 estie, Inc. 3
4. AI で実装が速くなってもそのままでは開発は速くならない AI で実装は速くなった。でも、開発全体は速くなったのか？ よくある困りごと 2 つ ① AI が意図通りに動かない ② ⼈間が律速になる 規約を知らない。⽂脈を知らない。 何を作るか決めるのも、正しいか確かめるのも⼈間。 考慮漏れのあるコードを平気で出す。 AI の出⼒が⼈間の前で渋滞する。 直させる往復のせいで結局⼈の時間が消える。 速くなったのは実装だけで、その前後が詰まる。 © 2026 estie, Inc. 4
5. やったことは 2 つ ① AI が⾃律的にコンテキストを取れる環境を⽤意する コーディングならハーネス（コード資産そのものの品質‧指⽰書‧規約‧決定的な検査‧AIの検査）の強化 困りごと①への対処 （意図通りに動かない） 議論‧出荷‧監視なら、Slack, Jira, Confluence, Datadog の Plugin, MCP の連携の強化 ② ⼈の時間は判断と検証に使う ⼈がやらなくていい作業は AI に渡す ⼈は何を作るか‧正しいかの判断に時間を使う 困りごと②への対処 （⼈間が律速になる） この 2 つを開発サイクルの全部のステップでやっている © 2026 estie, Inc. 5
6. プロダクト開発のサイクル 各ステップに⼈の時間を⾷う作業が存在！ 議論 ⽂脈の説明とチケット起こしに時間がかかる ユーザー要望 実装 チャネルが散らばり、集約が⼿間 コードの質が不安。並列エージェントの監視が⼤変 監視 検証 アラート初動の仮説検証と修正 意図通りか分からない。⼤きい PR を読めない 出荷 リリースノート‧マニュアルの追従 ステップごとに、困りごとと、やっていることを順に紹介します © 2026 estie, Inc. 6
7. 議論 1/6 ありがちな 困りごと 議論：議論の前後にある作業を AI に渡す ⽂脈の説明と、決めたことをチケットに起こして進捗を書く⼿間が⼤きい AI Slack の会話とチケット GitHub の PR コメント コミットログ 会話の要約を、スプリント計画‧振り返りの材料に ハドル（Slack の⾳声通話）の AI 議事録‧スレッド‧PR コメント‧コミッ トログを、決定事項とアクションに整理して Wiki へ。議論の前に AI に先に まとめさせる AI チケットの作成や整理 チケット作成‧ラベル‧エピック‧説明⽂‧進捗コメントを、Claude Code の定期実⾏（決まった時刻に⾃動で動かす）が MCP 経由で書く AI に任せた 要約、チケットの作成‧整理‧進捗コメント © 2026 estie, Inc. ⼈に任せた 話して決める。何を優先するか 7
8. 実装 2/6 ありがちな 困りごと 実装①：コードも⽂書も AI への良質なコンテキストにする 規約違反や設計崩しのコードを書かないか不安 良いフィードフォワード（書く前に渡す） 良いフィードバック（書いた後に返す） AGENTS.md AI への指⽰ファイル。索引だけを置き、詳細はコー ドと同じリポジトリの⽂書へ 決定的な検査 Claude Code が実装する 毎回同じ答えを返す検査。テスト‧型チェック‧ linter。編集直後‧push 前‧CI の 3 回当てる ドメイン駆動設計（DDD）で書かれたコード 検証スキル 業務ルールがコードに書いてある。構造そのものが 説明になる レビュー観点を書いた指⽰ファイル。例：フロント エンドのデザインレビュー。AI ⾃⾝に当てさせてか ら PR にする AI に任せた 規約を読んで実装し、検査と検証スキルで⾃分で直す © 2026 estie, Inc. ⼈に任せた 規約と⽂書を整える。ドメインモデルの設計 8
9. 2/6 実装②：先に作らせて後で⾒る ありがちな 困りごと 途中で質問されると⼈間の⼿が⽌まる 実装 Claude Code 下書きの PR（Draft PR） Claude Code ブリーフ Preview（次で紹介）も⽴つので URL を開くだけで動作確認できる 迷った点は要確認事項に Claude Code やってほしいことを 書いたファイル Claude Code Claude Code 調査、実装、検証、下書きの PR まで質問せずに進む。途中は⾒ない AI に任せた 調査から下書きの PR と Preview まで質問せずに進む © 2026 estie, Inc. ⼈に任せた ブリーフを書く。できた PR を後で⾒る 9
10. 検証 3/6 ありがちな 困りごと 検証①：PR ごとに Preview を⽴て誰でも触れるようにする 動作を確かめられるのがエンジニアだけだと確認が⼈に詰まる AI が⾃由にできる場所：アプリ側（Two-Way Door = 戻せる変更） PR #1 の Preview PR #2 の Preview PR #3 の Preview 永続化層‧インフラ （One-Way Door = 戻せない変更） 別サービスに隔離。アプリ側リポジトリから スキーマや保存データを直接は触れない … DB 側も PR ごとに Preview が⽴つ ラベル 1 枚で PR ごとに環境が⽴つ。push で更新、クローズで消える DB PR #A DB PR #B … アプリの Preview から指名して接続。 スキーマ変更もマージ前に試せる PM も CS も AI で機能変更の PR を作り、⾃分の Preview で確かめてからレビ ューに出す。エンジニアでなくても、作って試すまで⼀⼈で回る リポジトリの壁 AI に任せた アプリ側の変更。Preview は PR ごとに⾃動で⽴つ © 2026 estie, Inc. ⼈に任せた Preview で動作を確かめる。 One-Way Door だけ念⼊りに⾒る 10
11. 検証 3/6 ありがちな 困りごと 検証②：コードを読む代わりに意図と実物を確かめる ⼤きい PR を真っ向から読めない AI が書く変更説明のページ（意図の説明 HTML） 何のための変更か ⼈間が⾒る 3 つと、触って確かめる 2 つ セキュリティ 顧客データの経路‧権限‧外部送信 設計 ドメインモデルとアーキテクチャ。ここは⼈ 間が⾯倒を⾒る価値がある データの破壊的操作など データマイグレーションなど、戻せない変更 が含まれていないか 全体像：どの構造を変えたか 個々の差分：何を変えたか Preview で触る QA 会 AI に任せた 変更説明のページを書く。QA 会の指摘を直す © 2026 estie, Inc. ⼈に任せた コードではなく実物の挙動を確かめる ⼤きな機能はみんなで約 30 分触る。指摘を 表に集め、AI がまとめて直す 設計と、データの破壊的操作の判断。実物を触る 11
12. 出荷 出荷：デプロイは AI 以前からも⾃動化されているものの、改善の余地もある 4/6 ありがちな 困りごと 顧客向けリリースノート‧お知らせ‧操作マニュアルを変更に追従させる⼿間が残る 検証環境（stg）へ ⾃動デプロイ main にマージ ⼈がリリースを承認 本番（prd）へ ⾃動デプロイ 失敗時は⾃動で 巻き戻し ここは AI 以前からこの形。⼈がやるのはリリースの承認だけ 次に AI で⼿を打とうとしているのは、伝える仕事（試⾏中） リリースノート 顧客向けお知らせ 操作マニュアル リポジトリで管理し、マージ済み PR から AI が更新の PR を作る。⼈は承認するだけ AI に任せた ⾃動デプロイ。お知らせ‧マニュアルの PR 作成 © 2026 estie, Inc. ⼈に任せた リリース候補と、お知らせの承認 12
13. 監視‧要望 5-6/6 ありがちな 困りごと 監視‧ユーザー要望：初動の調査は AI。ユーザーの声は 1 か所に集める アラートの初動と、散らばった要望の集約に時間がかかる 監視 ユーザー要望 監視ツールが異常を検知し、チャットへ通知 商談‧サポートの会話に Slack の絵⽂字リアクションを付けると、 専⽤チャンネルへ⾃動転送 Runbook‧監視メトリック‧ログに沿って判断 顧客の声と課題が 1 か所に集まり、AI の⾒落とし減らすための良いコ ンテキストになる。 対応チケットは⼈が⾒る前に AI が証拠を集めて調査ログを書き、 問題を解決する暫定的なPRも作成 社内の分析環境で、監査ログから利⽤状況ダッシュボードを AI と作 った（PM が整備） AI に任せた アラート後の証拠集め + 調査ログ + 解決PR。 要望の集約と⼈間向けダッシュボード © 2026 estie, Inc. ⼈に任せた PRの妥当性の判断。次に何を作るかの議論 13
14. まとめ 従来の開発サイクルの⾻格をなぞった上で、 AI に任せられる部分を任せた 開発全体は速くなったのか？ → 速くなったと思っている。PR数は⽉ 42 本から 146 本に（6 ⽉ → 9 ⽉） ① AI のために環境を⽤意した（指⽰書‧規約‧検査‧Preview環境‧MCP‧スキル‧永続化層隔離） ② ⼈の時間は判断と検証に使った ③ ⼈は AI が何をしたかを把握しながら開発している 議論 ユーザー要望 実装 監視 検証 出荷 estie では、不動産領域の新規プロダクトを AI 前提の開発フローで⼀緒に作るエンジニアを募集しています 採⽤情報：https://hrmos.co/pages/estie/jobs © 2026 estie, Inc. 14