速く作れる。その次は、速く確かめられる開発へ 〜AIネイティブ開発を支える、Shift Down〜 / Can build fast. Next, moving to development where we can verify fast.

五反田AIの登壇資料です

Transcript

1. 五反田AI vol.3｜AIネイティブ開発を支える基盤づくり 速く作れる。その次は、速く確かめられる開発へ 〜AIネイティブ開発を支える、Shift Down〜 2026年8月19日 Asterminds株式会社 r.kagaya
2. 自己紹介 r.kagaya(@ry0_kaga) Asterminds（アスターマインズ）株式会社 共同創業者・CTO 2022年に株式会社ログラスに入社 経営管理SaaSの開発、開発生産性向上に取り組んだのち、 生成AI/LLMチームを立ち上げ、新規AIプロダクトの立ち 上げに従事、その後、25年8月に独立・現職 翻訳を担当したAIエンジニアリングが オライリージャパンより出版
3. Astermindsがつくる、人とAIのためのコンテキストレイヤー 現場に眠る一次情報を、 人とAIの判断・実行を支えるコンテキストへ。 AIヒアリングエージェント InTake 現場の会話や顧客の本音を AIが聞き取り、整理する。 組織の一次情報を、人とAIが活かせる コンテキストレイヤーへ。 2026年3月、シードラウンドの調達を公表
4. AIで実装は速くなった。 品質の確認も、同じように速くできるか？
5. 今日言いたいこと： 品質を確かめる仕組みを、開発者とAIの共通基盤に 月1,000件のPRを作れても、品質確認が人頼みでは追いつかない。 AIが実装・検証・修正を繰り返せる基盤が、ソフトウェア開発の自動運転を支える。
6. 実装の前後が詰まる。そこまでは、もう言われている 前後の確認が人頼みのままなら、待ちが残る。 毎回の品質確認を、どう人頼みから抜け出させるか。 品質確認を基盤へ
7. Shift Down：開発者の負担を、共通基盤で引き受ける Google Cloudは、開発者の負担を共通基盤に移すと提案している。 セキュリティ対策やインフラ管理を、各自が抱えなくて済むようにする。
8. 検証を早めることに加え、毎回の確認を共通基盤に組み込む Shift Leftは、問題を早く見つける考え方。自動テストも含まれる。 Shift Downで検証を共通化し、開発者もAIも同じ基準で確かめる。
9. 指示を待たずに検証が動く、アンビエントな開発へ 現在は、クラウドエージェントとBrowserbaseで全PRの画面QAを実施。 目指す構成：PR更新や定期実行をきっかけに、検証から修正まで回す。
10. AIの速さを成果につなぐため、品質確認の基盤に投資する DORA 2025：AIは、組織の強みも弱みも増幅する。 技術職を対象とした調査結果を、私たちの投資方針につなげる。
11. 少人数で、開発基盤のどこから整えるか？ 毎回繰り返し、合否を定義できる確認から基盤化する。 実装には、進化の速いコーディングエージェントを使う。 それでも、動作や使い勝手を確かめる仕事は残る。 そこで、毎回の動作確認とデザイン確認を基盤に組み込んだ。 最初の投資先は、ブラウザQAとデザインハーネス
12. 「動くか」と「使いやすいか」を、繰り返し確かめる 部品を渡すだけでは、人もAIも選び方に迷う。 作り方のルールと、実際の画面を確かめる仕組みをセットで用意する。
13. 実行環境は借り、合格条件は自分たちで持つ Browserbaseは、AIがクラウド上のブラウザを操作するための基盤。 現在はクラウドエージェントと併用し、全PRで画面の自動QAを回している。
14. ブラウザを動かし直さずに、判定の仕方を改善する 画面やログを保存し、判定基準の見直しには同じ記録を使う。 実装を修正した場合や、記録だけでは判断できない場合は再実行する。
15. ルールで判定できることと、AIで判断することを分ける
16. ブラウザを操作するAIと、合否を判定するAIを分けた
17. 合格条件から逆算して、判断に必要な証拠を残す 現在の独立判定は、保存した画面と合格条件を照合する。 下図は整備したい記録の構成。DOM取得などには、まだ実装上の課題がある。
18. 評価で直すのは、生成した画面だけではない デザイン評価では、実装ではなくルール側の矛盾が見つかった。
19. 次の改善：QAの見逃しや誤判定を、減らしていく 検査の失敗から、テスト・判定方法・記録の取り方を見直す。 例：保存完了の表示に加え、再読込しても値が残るか確かめる。
20. 開発を任せる先が変わっても、品質の基準は共通にする 私の開発の半数は、クラウドエージェントに任せている。 Cursor / Devinでも、共通のルールとブラウザQAを使う。 この検証と改善の仕組みを、開発全体に広げたら？
21. ソフトウェアファクトリー：開発の流れを、仕組みとして動かす 実装・検証・修正をつなぎ、開発全体を回す。 ブラウザQAは、その中の「検証」を担う。 確認結果を、次の修正に使える形で返す。
22. ハーネスが実行を支え、ファクトリーが開発全体を回す
23. ソフトウェアファクトリーには、速く、正しく確かめる仕組みが要る 作る量が増えても、人が確認する量を同じだけ増やさない。 そのために、検証を自動化し、見逃しや誤判定も減らしていく。
24. 人の確認を減らすなら、先に「正しくできた」と確かめる仕組みを作る Light／Dark Factoryは、人がコードを読んで判断するかの違い。 自動化の範囲は、安く確実に検証できる範囲に合わせて広げる。
25. 月1,000件のPRは出せた。では、事業は前に進んだか？ 次に見るのは、顧客に届くまでの時間と、仮説を確かめるまでの時間。 作る速さを、顧客の反応から次の判断をする速さにつなげたい。
26. まとめ
27. まとめ • 毎回繰り返す確認を一つ選び、合格条件と必要な証拠を決める。 • 検証結果を人とAIに返し、修正と再検証につなげる。 • テストや判定方法を見直し、変更前後を比べて改善を確かめる。 • 作る速さに加え、顧客に届けて仮説を確かめるまでの時間を見る。
28. ハイアリングナウです カジュアル面談
29. おわり