AI 1st でエンタープライズ SaaS を立ち上げる / AI 1st Enterprise SaaS

AIを開発に取り入れてみた結果の話 ― 試行錯誤と導入後のリアル ―
https://lapras.connpass.com/event/387940/

Transcript

1. AI 1st でエンタープライズ SaaS を立ち上げる 小林 佳祐 AI を開発に取り入れてみた、その結果。 ― 試行錯誤と導入後のリアル ― 株式会社 kickflow CTO 2026/04/16
2. 2 / 28 自己紹介 小林 佳祐 株式会社 kickflow 取締役 CTO・共同創業者 プロダクト開発や HR を担当 最近は TypeScript がメイン
3. 3 / 28 会社紹介 株式会社 kickflow エンタープライズ向け稟議・ワークフロー SaaS「kickflow」を開発・提供 1→10フェーズ 元々は SmartHR の新規事業子会社で、MBO（経営陣による買収）でスピンアウトした会社 社員約50名、うちエンジニア7名 現在、kickflow とは別に 新規プロダクト を開発中 今日は AI を活用して新規にエンタープライズ向け SaaS を立ち上げている話をします
4. 4 / 28 エンタープライズ SaaS の特徴 要件が多い 求められるドメイン知識が多い・深い 機能数が多くて複雑 高度なセキュリティ機能や監査ログが必要 開発が大変 エンジニアを大量に採用する必要があった ローンチまで時間を要した（1〜2年）
5. 5 / 28 AI があれば少人数でも立ち上げられるのでは？ プロトタイピングやゼロからの立ち上げは AI の得意領域 できるだけ小さい組織での新規プロダクト立ち上げをやってみよう！
6. 6 / 28 チーム体制 職種横断の 最少人数 でチームを組成 エンジニア 2名 デザイナー 1名　 QA 2名　 営業 3名 マーケティング 1名　 ※既存事業と兼務 ※既存事業と兼務 ※既存事業と兼務
7. 7 / 28 新規事業を立ち上げるときにやったこと あらゆる業務を AI 化した 技術選定 要件定義（仕様書作成） コーディング コードレビュー セキュリティチェック QA etc
8. 8 / 28 技術選定 サービス立ち上げの技術選定を AI と壁打ち しながら意思決定 超重要なフェーズなので、Claude だけでなく Codex や Gemini にも セカンドオピニオン をもらう AI（特に Claude ）は聞き方によって回答が変わるので、いろんな角度から検討させる 既存製品の技術スタック 事業計画 事業ドメイン 関連法令 チーム体制 / 今後の採用計画
9. 9 / 28 要件定義（仕様書作成） 仕様駆動開発を採用 仕様書の作成を Claude Code で行う（スキルも 用意） /create-spec で大雑把にやりたいことを CC に伝えて、細部は CC に AskUserQuestion ツ ールでヒアリングさせる 質問に順番に回答し、最後に気に入らない点を 修正依頼 or 自分で修正していく 仕様書をソースコードと同じリポジトリで管理す るのが大前提 仕様書を SSoT として、必ず最新の実装とセッ トで更新していく
10. 10 / 28 設計書 / 実装計画書 最初は作っていたけど、最近はいらないのではないかと思っている 維持されていない設計書があるとノイズになるので、むしろない方がいい いざとなれば、Claude Code に実装から設計書を作成させればいい Claude Code はある程度複雑なタスクだと自律的に Plan モードに入るので、これで十分なことが多い マルチテナント設計、認証、外部サービス連携 など重要な要素に限って作成
11. 11 / 28 コーディングの AI 化 原則手でコードを書かない という開発ポリシーを策定 体感 95%以上 は AI でコードを出力している ルール、スキル、サブエージェントを細かく整備 2回同じミスをしたらルールに追記 1日の中で2回同じプロンプトを打ったら、スキル（コマンド）化 実装時の 仕様書の同期 も Claude Code がやってくれる（ルールで指示） 人間が手でコードを書くと放置されがち
12. 12 / 28 ガードレールの整備 ルールに全部書いていくとコンテキストを無駄に食うので、Lint・フォーマッター・Typecheck・テスト で表現できるものはすべてそっちに寄せる セッションの中で繰り返し実行するので、ちょっとでも遅いとストレス → 高速化 しておく ESLint の一部を oxlint に移行 Prettier を oxfmt に移行 影響のある単体テストだけ実行するようにルールで指示 CI も遅いとストレスなので、5分以内に収まるようにジョブを並列化＆シャードを活用 Supabase CLIの立ち上がりが遅いので、セルフホステッドランナーも検討
13. 13 / 28 動作確認（開発者テスト） 一部 AI でもできるが、まだ 人間がメイン で行う作業 agent-browser または Playwright CLI で Claude Code にテストさせる ページが正しく表示されているか、データを保存できるか、くらいなら検証可能 インタラクティブな操作のテストは苦手 例：ドラッグ＆ドロップで並び替えができることの検証
14. 14 / 28 コードレビュー コーディングの高速化により、最大のボトルネックになるのが コードレビュー 結論、全部レビューするのは諦めた AI は1日に数千〜数万行のコードを出力してくる とてもじゃないけど全部見きれない
15. 15 / 28 CodeRabbit CodeRabbit で PR をレビュー 実装上のバグを見つける能力は、そのへんのエ ンジニアよりすでに優秀 昨年CodeRabbit CLIもリリースされ、ローカ ルでも実行可能に CodeRabbit の指摘を Claude Code に精査させ、 必要なものを修正させる /fix-review コマンド
16. 16 / 28 AIによるコードレビューの勘所 重要なのは、実装するエージェントとレビューするエージェントを完全に分離 すること 実装者とは別の視点でレビューさせることで、観点漏れを防ぐ CodeRabbit が変なレビューをしていたら、ルールファイルに追記するか PR コメントで学習させる CodeRabbit はデフォルトで Claude Code のルールファイルを考慮してくれる Codex によるレビューも今後検証予定
17. 17 / 28 人間のコードレビューの位置づけ 人間は「仕様があるべき姿か」と「クリティカル な問題（システム障害やセキュリティ事故）を起 こさないか」に絞ってレビュー 仕様書の大幅な変更 データベースのマイグレーション 認証・認可 課金ロジック etc PR 作成時に Claude Code Actions で危険な PR を 判定して、 「review required」ラベルを自動的に 付与
18. 18 / 28 セキュリティレビュー Claude Code Security Review で PR 単位でレビュー 別途、ベンダーによる 第三者検証 も定期的に実施 まだ AI だけで専門家の脆弱性診断を代替できない Claude (Opus 4.6) より Codex (GPT 5.4) の方が脆弱性発見能力は高そう Codex Security も試したい
19. 19 / 28 QA の AI 化 PR や仕様書から、AIでテスト観点やテスト設計書を作成 Claude Code を使って Playwright の E2E テストを整備 AI 前提なら、GUI ベースのツール（Autify など）よりも高速かつメンテナンスしやすい テスト環境のデータ整備や初期化も、シードスクリプト経由で実行可能 UI 変更により E2E が失敗すると、自動的に Claude Code Actions で修復
20. 20 / 28 バグ修正 バグチケットは GitHub Issues で管理 /research-issue と /fix-issue というスキ ルを整備 /research-issue でバグの原因を特定。どれく らい自信があるかを100点満点で申告させる 90点以上 → ほぼ原因を特定できているので、 そのまま修正まで進めて OK 80点台以下 → 何かしら不安があるので、 ultrathink を使うか、Codex でダブルチェ ック 軽微なバグの場合、Issue に @claude このバグを 修正して で Claude Code Action でそのまま修正
21. 21 / 28 その他 デザイン: デザイナーが Claude Code でモック作成、PRを出す リリースノートの作成: 本番デプロイ時、Claude Code Actionsで差分を調査して自動的に社内用のリリース ノートを作成、Slackに通知 競合調査: /competitor-research スキルを作成し、指定した競合企業の機能との比較表を作成 セキュリティホワイトペーパーの作成: ISO27017の要件を満たすレベルのドキュメントを作成 発明提案書の作成: 弁理士に特許出願を依頼する書類をスキルで作成
22. 22 / 28 結果
23. 23 / 28 結果 新規事業の立ち上げとしてはかなり順調 開発は高速化した 従来は1か月かかる開発が2,3日で終わるようになった 開発開始から半年でクローズドベータ開始 品質面も大きな問題はない リポジトリはかなり大規模（5100ファイル / 76万行）になってきたが破綻していない バグゼロとはいかないが、それは人間が実装した場合も同じ 開発プロセスの中に QA を初期から入れることでガード 内部品質は少しずつ下がるので、よくないコードは定期的に一掃する必要がある（割窓理論） 運用への AI 活用はこれから
24. 24 / 28 AI 時代のエンジニアとは？
25. 25 / 28 AI 時代のエンジニアとは？ 「エンジニア」という職種自体はなくならないが、求められる役割は変わる 設計や実装の比重が減り、より「何を作るか」を決める意思決定と、AI が働く環境の整備 が主な役割にな る 実際、今回のプロダクトでは顧客との対話にかなり時間を割いている kickflow のときは CEO（元 PdM）や営業に任せていた 究極は、エンジニア全員がテックリードであり、プロダクトマネージャーであるべき
26. 26 / 28 必要な能力 「何を作るか」を判断する能力 ドメイン知識・顧客理解 開発プロセス全体の理解 要求定義・要件定義 ドキュメント作成 AI の能力を最大限発揮させる能力 ソフトウェア開発の知識 コンテキストエンジニアリング / ハーネスエンジ ニアリング 各種 AI ツールに対する知見や導入経験
27. 27 / 28 こうした能力を伸ばすには 言われた通りに作るのではなく、自分の頭で考えて試行錯誤する PdMやデザイナーなど他の職種の領域にマナーを守って越境する AI ツールを積極的に試してみる
28. ご清聴ありがとうございました 宣伝：エンジニアを積極採用しているので、 右のQRコードからぜひ採用サイトを見に来てくださ い。