コーディング自動化の次へ。人の介入をゼロにするファクトリーとサポートAIによる実践

Findy AI x 開発組織サミット2026スポンサーセッション

Transcript

1. コーディング自動化の次へ 人の介入をゼロにするファクトリーと サポートAIによる実践 AI×開発組織Summit 2026 スポンサーセッション 株式会社ベースマキナ
2. 目次 Bottleneck Shift コーディングの左右に移るボトルネック Software Factory ソフトウェアファクトリーの事例と構成 Loop Engineering ループエンジニアリング（フェーズ0〜3） Cloud Factory ファクトリーへの移行（フェーズ4〜7） Beyond The Loop 開発のループの外を自動化する PR 宣伝です！ブースとプロダクトのご案内 2
3. はじめに 自己紹介 髙橋誠二（たかはしせいじ） 株式会社ベースマキナ 代表取締役社長 略歴 @__timakin__ 株式会社ディー・エヌ・エー、株式会社Gunosy等で ソフトウェアエンジニアとして勤務。開発業務に加えて プロジェクトマネジメント・新規事業・中途採用など幅広い業務に従事。 Go言語を中心とした技術カンファレンスへの登壇やOSS活動等も行う。 2020年に株式会社ベースマキナを創業。代表として経営に従事。 AIネイティブな開発体験でヒューマンエラーをなくす プロダクトオペレーション基盤「ベースマキナ」の運営に責任を負う。 好きなこと 写真：よく撮ります。国際コンペで受賞歴あり。 作家ものの食器集め：好きなのですが、よく割ります。 3
4. 01 Bottleneck Shift コーディングの左右に移るボトルネック
5. 01. コーディングの左右に移るボトルネック AIでコーディングのコストはほぼゼロに 見積もりで数年かかる移行をAIエージェントが数週間から数か月で終えられるようになりました。 GitHubでは2026年8月、エージェントが作ったPRが人のPRを上回りました。 会社 Anthropic Asana Uber Airbnb OpenAI AIエージェントで進めた移行 BunをZigからRustへ E2Eテスト4,000ファイルの移行 JUnit 4の60万テストをJUnit 5へ E2Eテスト3,500ファイルの移行 APIの層をPythonからRustへ（移行中） The Pragmatic Engineer「The state of the tech industry in 2026」（2026年10月6日）より。見積もりは各社が示した値です。 見積もり 人年 5年 数年 数年 数年 1.5 実際 日 2週間 4か月 6週間 約5か月 11 5
6. 01. コーディングの左右に移るボトルネック ボトルネックは要件定義と品質保証へ 実装が速くなった分、コーディングの左右に仕事がたまります。 レビューを待つPRが増え、リリースまでの時間は思ったほど縮みません。 コーディングの左 コーディング コーディングの右 As-Is ヒアリング 要件定義 実装 レビュー テスト To-Be ヒアリング 要件定義 AIエージェントが実装 レビュー テスト 人が聞き取る 仕様を書く人を待つ 人を待たずに進む PRがたまる 確認が追いつかない 6
7. 01. コーディングの左右に移るボトルネック 目指すのはシフトではなく全工程の自動化 ボトルネックを左右へ移すだけでは人の時間が開発の速さの上限のままです。 レビューの大部分もAIに任せ、人は要所の承認だけを受け持ちます。 コーディングの左 As-Is ヒアリング To-Be 依頼 チケット・チャット コーディング 要件定義 AIエージェントが実装 AIが要件定義からレビューまで進める 受け入れ条件・実装・テスト・レビュー コーディングの右 レビュー テスト 要所だけ承認 リスクの高い変更 7
8. 02 Software Factory ソフトウェアファクトリーの事例と構成
9. 02. ソフトウェアファクトリーの事例と構成 海外の各社は自社のファクトリーを持つ Stripe Minions Ramp Inspect Shopify DoorDash Spotify River Flux Honk stripe.dev The Pragmatic Engineer Shopify Engineering DoorDash Engineering Spotify Engineering 週1,300件以上の PRがマージ マージされたPRの 約75%を作る マージされたPRの 8件に1件を共同で作る 1か月で13万件の 開発の作業を自動化 AIが作ったPRが 1,500件以上マージ 2026年2月 Minions: Stripe’s one-shot, end-to-end coding agents— Part 2 2026年8月 Why Ramp built its own inhouse coding agent, Inspect 2026年5月 Under the River 2026年8月 Delegating Engineering Work To Cloud-Based Agents 2025年11月 1,500+ PRs Later: Spotify’s Journey with Our Background Coding Agent (Honk, Part 1) 各社の記事より（2026年10月15日に確認）。数字は各社が公表した値です。 9
10. 02. ソフトウェアファクトリーの事例と構成 Warpはファクトリーの基盤を製品として提供 Warpは2026年8月、Warp Factoriesをクローズドベータで公開しました。 warp.devのブログとランディングページより（2026年10月15日に確認） 10
11. 02. ソフトウェアファクトリーの事例と構成 Warpは工程ごとの専門エージェントに割り振る 職長のエージェントが依頼を受け、工程ごとの専門のエージェントに渡します。 人が決めるのは仕様の承認・質問への回答・マージの3つです。 Warp 職長と工程ごとの エージェント 人 Intake 受付 Triage 調査 Planning 計画 Building 実装 Reviewing レビュー Handoff 引き渡し 職長が 依頼を受ける 再現して 変更の範囲を 決める 仕様と 受け入れ条件を 書く PRを作り テストと画面の 証跡を添える 要件とテストと 安全面を 確かめる 結果を 人に渡す Slackや チケットに 起票する 不明点に 答える 仕様を 承認する マージする 11
12. 02. ソフトウェアファクトリーの事例と構成 国内でもファクトリーの実践が進む 加賀谷 諒 @ry0_kaga 横路 隆 Asterminds 取締役CTO Zenn・2026年10月15日 開発プロセスをAIシステムとして組み直し 作ったものを自動で確かめる freee 取締役CAIO freee公式note・2026年9月（DevinCon Tokyo 2026） 開発プロセス全体の自動化を進め エンジニアは「工場長」の役割へ Yuku Kotani @yukukotani Ubie CTO YAPC::Tokyo 2026 のプロポーザル 2023年から社内AIエージェント基盤と ソフトウェア工場を作っている 各記事・プロポーザルの公開ページより（2026年10月15日に確認）。 12
13. 02. ソフトウェアファクトリーの事例と構成 要件定義とレビューに人の介入が残る 各社とも、要件定義とマージ判断にのみ人の責務を残す形で運用しています。 会社 要件定義 実装 検証 レビュー Stripe 人がSlackで依頼する 人が要件を書き AIがIssueに分ける AIが仕様を書き 人が承認する 人が仕様と シナリオを書く Minionが1回で実装 隔離したクラウドの サンドボックスで実装 AIがPRを作る lintとCI（2回まで） テストと手動確認の 証跡がそろってからPR テストと画面の 証跡をPRに添える シナリオと外部サービス の複製で確かめる マージは必ず人がレビュー Minions WorkOS Horizon Warp Factories StrongDM Software Factory 人はコードを書かない マージは必ず人が承認 AIの判定は助言 マージは人 人はコードを読まない 13
14. 03 Loop Engineering ループエンジニアリング（フェーズ0〜3）
15. 03. ループエンジニアリング（フェーズ0〜3） 工程ごとのツールとスキルを段階的に入れる Warpの工程を手本に、今できることから最小限に進めていくのがおすすめです。 工程 Warpでは いま入れて おくもの ・ Intake Triage Planning Building Reviewing 職長が 依頼を受ける 範囲を決めて 仕様と受け入れ条件を書く PRを作り テストと画面の証跡を添える 要件とテストと 安全面を確かめる SlackやAI経由で NotionやLinearに起票 grill-me・pstackなどの 深掘りのスキル 適切なモデルの選定 動作の証跡を撮るスキル CodeRabbitなどの AIレビュー linterの整備 自動テスト（VRTを含む） 受付 調査・計画 実装 レビュー 15
16. 03. ループエンジニアリング（フェーズ0〜3） 8つのフェーズで段階的にファクトリーへ いきなり全自動にはせず、ループエンジニアリングから徐々にファクトリーへ移行します。 ループ リモートで指示 チケットから着手 PRごとのプレビュー PRに動作の証跡 ファクトリー クラウドで実行 Slackで依頼 マルチリポジトリ マルチプロダクト フェーズ0 フェーズ4 フェーズ1 フェーズ5 フェーズ2 フェーズ6 フェーズ3 フェーズ7 16
17. 03. ループエンジニアリング（フェーズ0〜3） フェーズ0 Remote Controlに身体を慣らす ファクトリーの基本は、生産性を均一に上げ、環境に左右されないことです。 目指す姿は、全員が同じ環境で動かすクラウドのエージェントです。 まずはRemote Controlで、手元のエージェントにスマホから指示します。 指示 実行 これまで フェーズ0 フェーズ4から PCの前で指示 スマホから指示 Slackやスマホから指示 手元のPCで動く 手元のPCで動く クラウドで並列に動く 環境が人ごとに違う Remote Controlでつなぐ 全員が同じ環境で動かす 17
18. 03. ループエンジニアリング（フェーズ0〜3） フェーズ1 Notionのチケットを起点に実装させる AIが未着手のチケットから着手の候補を出し、人は選ぶだけです。要件が複雑でないチケットは 「オート実装」のフラグで実装まで即完走させるのがおすすめです。 開発タスク すべて TODO 自分の担当 タスク名 ステータス 緊急度 実装モード T-128 返金一覧に取引IDの検索を足す TODO 高 オート T-129 売上の日次グラフをビューに足す TODO 中 オート T-130 解約の処理を承認つきにする TODO 中 ハイエンド T-127 請求書のCSVに部署名を足す REVIEW 中 オート > /dev-loop からTODOのタスクを3件取得しました 着手するタスクを選んでください ❯ 1. T-128 返金一覧に取引IDの検索を足す 緊急度 高・オート（推奨） 2. T-129 売上の日次グラフをビューに足す 緊急度 中・オート 3. T-130 解約の処理を承認つきにする 緊急度 中・ハイエンド ⏺ Notion ⏺ 18
19. 03. ループエンジニアリング（フェーズ0〜3） フェーズ2 PRごとにプレビュー環境を立てる レビューする人が手元で動かさずに確かめられるようにします。DBは、まずdev環境の共通DBから始めます。 PRごとのDB dev環境の共通DB ここから始める PR #128 PR #129 PR #130 pr-128.dev pr-129.dev pr-130.dev 共通のDB 準備 すぐに用意できる データ 全PRで同じデータを使う PR #128 PR #129 PR #130 pr-128.dev pr-129.dev pr-130.dev DB DB DB 準備 立ち上げの時間と費用がかかる データ PRごとに分けられる 19
20. 03. ループエンジニアリング（フェーズ0〜3） フェーズ3 動作の証跡をPRに貼らせる 動作の証跡を撮るために プランニング（動的なスクリプト生成）を 行うスキルを用意しました。 変更に合わせてスクショ・動画・APIのレスポンスから 撮るものを決めます。 出力は書き写さずにそのままPRに貼ります。 レビューする人は、証跡を見てマージを判断できます。 撮り方を計画して作ったスクリプト await capture("refund-search", async (c) => { await c.goto("/refunds?transaction_id=T-2041"); await c.shot("01-filtered"); await c.goto("/refunds"); await c.shot("02-all"); }, { video: false }); factory-bot commented on #42 動作確認の証跡 取引IDで1件に絞り込む 取引IDが空なら全件 返金一覧 返金一覧 T-2041 取引IDで検索 取引ID 金額 状態 取引ID 金額 状態 T-2041 ¥12,800 返金済み T-2041 ¥12,800 返金済み T-2035 ¥8,900 申請中 API（実際の出力） $ curl -s 'localhost:3000/api/refunds?transaction_id=T-2041' {"total":1,"items":[{"id":"rf_8821","status":"refunded"}]} 20
21. 04 Cloud Factory ファクトリーへの移行（フェーズ4〜7）
22. 04. ファクトリーへの移行（フェーズ4〜7） フェーズ4 クラウドでエージェントを動かす 各自がOAuthでログインし、自分のサブスクリプションの枠で動かします。 ブラウザ操作とVaultを足し、動作の確認までクラウドで済ませます。 手軽に始めるなら、CloudflareのWorkerとSandboxが向いています。 Cloudflare 依頼 Slack Web Worker 依頼の受付と キュー Sandbox（コンテナ） Claude Code・Codexを 各自のOAuthと サブスクリプションの枠で ブラウザ操作 プレビューを開いて 画面で確かめる Vault ログイン情報とAPIキーを預かり、使うときだけ渡す 成果物 PR プレビュー 証跡 22
23. 04. ファクトリーへの移行（フェーズ4〜7） フェーズ5 Slackのスレッドで 依頼から受け取りまで スレッドで頼むとそのままチケットになります。 あいまいな要件はgrill-meやpstackなどで AIが質問を重ねて深掘りします。 PR・プレビュー・証跡は同じスレッドに返したほうが 見逃しが少ないです。 極力Slackを離れずに結果が確かめられると良いでしょう。 BaseMachina を検索 小 12 # factory 10:02 小 小林 @ファクトリー 返金一覧で、取引IDから返金を探せるようにしたいです ファクトリー APP 10:02 チケット T-128 を作りました。要件を確認させてください。 ❓ Q1 - 一致の仕方：取引IDは完全一致で探しますか？ ➡️ 推奨：完全一致（取引IDは貼り付けで入力されるため） 10:05 小 小林 完全一致でお願いします ファクトリー APP 10:31 返金一覧に取引IDの検索を足す #42 受け入れ条件 3/3 ・ スクショ 2枚 ・ APIのレスポンス 1件 PRを見る プレビューを開く 何より、他の人のAIの使いこなし方が見えて互いに成長できます。 23
24. 04. ファクトリーへの移行（フェーズ4〜7） フェーズ6 1つの依頼で複数のリポジトリを直す 関連するリポジトリをクラウドエージェントのワークスペースで紐づけます。同じプロダクトのリポジトリが分かれていても コンテキストを共有して実装の見逃しをなくします。 ワークスペース「請求書」 T-140 請求書の宛名に部署名を出す 受け入れ条件 部署名を登録できる 請求書に部署名が出る ヘルプに書き方がある billing-api #212 部署名の列とAPIを足す 紐づけたGitHubのリポジトリ acme/billing-api DBの列とAPI acme/billing-web 請求書の画面 acme/help-docs ＋リポジトリを紐づける ヘルプの記事 billing-web #88 請求書に部署名を出す help-docs #31 宛名の記事を直す PRの説明に、ほかの2件へのリンクを入れる 24
25. 04. ファクトリーへの移行（フェーズ4〜7） フェーズ7 プロダクトをまたぐコンテキストを整える 用語・設計の判断・作業の手順は共通にし、仕様はプロダクトごと。Intakeは1つで、コンテキストも最大限共有されるのが理想。 コンテキスト（例） 同じファクトリー T-128 返金一覧に 取引IDの検索を足す context/ glossary.md adr/ skills/ T-301 回答に参照した PRを添える products/ basemachina/ tekusapo/ 用語集 設計の判断 dev-loop・pr-evidence・grill-me 仕様・画面・API 仕様・Slackの会話 Intake Planning Building Reviewing 25
26. 04. ファクトリーへの移行（フェーズ4〜7） フェーズ8（おまけ） ソフトウェアファクトリーの究極のKPI ソフトウェアファクトリーのKPIの理想は「無人化率」です。レビュー待ち時間・要件承認待ち時間・ラリー数などで人の介在を計測します。 レビューのラリー数が0になるタスクをあぶり出す自己改善の仕組みまでいけたらベストです。 無人化率 人が介在せずに完了したタスクの割合 人の介在を測る レビュー待ち時間 要件承認待ち時間 レビューのラリー数 要件のラリー数 ほかに必要なもの 動的なモデルルーティング System One Modelがタスクを仕分ける ラリー数が0のタスクをあぶり出す タスクの種類 文言の修正 管理画面の項目の追加 APIの追加 レビュー 要件 0 0 回 0回 2回 回 0回 1回 人の承認を外す候補 人の承認を外す候補 トークンコストの可視化 タスクとモデルごとに見る 26
27. 04. ファクトリーへの移行（フェーズ4〜7） よくある悩み事 Q コンテキストは Q クラウドエージェントでないと Q どこから A 最初はMarkdownで 十分だと考えています。 A そう考えると ハードルが高くなりすぎます。 まずはローカルの ループエンジニアリングから 始めましょう。 A PRごとのサンドボックス環境など インフラの制約がかかるところが いちばんのハードルです。 まずはスキルの整備と Remote Controlで ウォーミングアップしましょう。 どう整備すればいい？ ファクトリーではない？ 手を付ければいい？ 27
28. 05 Beyond The Loop 開発のループの外を自動化する
29. 05. 開発のループの外を自動化する 開発のきっかけになる顧客接点も自動化する ヒアリングやサポートは、エンジニアが兼任しがちな開発の外の仕事です。 商談の記録や問い合わせツールから要望を抽出し、チケットにしてファクトリーに渡します。 開発のループの外 As-Is ヒアリング エンジニアも同席 問い合わせ対応 エンジニアが調べる 後工程 ファクトリー チケット化 人が書く コード修正 データ変更など エンジニアが手で直す ファクトリー To-Be AIが要望を抽出してチケットにする 商談の記録・問い合わせツールから コード修正 データ変更など テクサポAIが対応する 29
30. 05. 開発のループの外を自動化する 抽出はSystem One Modelにて 要望の抽出と仕分けはJevなどのSystem One Modelに任せると安価です。 商談の記録 問い合わせ 「請求書の宛名に 部署名も出せると 助かります」 TypeSafe AIのJev 入力100万トークンで$0.042 出力は無料・応答は70〜500ms Jev 0.94 要望を含む Choice どのプロダクト ベースマキナ Score 4 緊急度（1〜5） Noul System One Model（速い直感） 型の決まった値を1回で並列に返す 型つきの質問を1回で送る 要望をチケットに T-140 請求書の宛名に 部署名を出す LLM（遅い熟考） 文章を1トークンずつ書く 名前は、人の速い直感（System 1）と遅い熟考（System 2）の区別から。TypeSafe AIのブログとドキュメントより （2026年10月16日に確認）。 30
31. 05. 開発のループの外を自動化する 海外ではサポートのチケットからAIが修正PRまで 2026年10月、PylonとDevinが報告から修正のPRまで連携。Devinはエンジニアリングループに集中。 Pylon Devin サポートと コーディングのAI エンジニア 分類 起動 調査と再現 修正 記録 マージ PylonのAIが 不具合に タグを付ける タグで Devinの セッションが始まる コードとログを 調べて再現する 修正の PRを開く 経過とPRを Pylonの チケットに残す マージを チケットに 記録する スレッドで 指示する PRを レビューして マージ 31
32. 05. 開発のループの外を自動化する ループの外の仕事を全自動化する ベースマキナでは、そのためのサポートエージェントを作っています。 BtoBのカスタマーサポートを完遂するAIエージェント 技術的な問い合わせにSlackで一次回答 データ変更を伴う対応も最後まで完遂 要修正のチケットをエージェントへ 開発中 32
33. 05. 開発のループの外を自動化する テクサポAIはSlackで 技術的な問い合わせを完遂 CS・営業がテクサポにメンションすると 調べた経過と回答がスレッドに返ります。 コード・ドキュメント・過去の対応・実データを 根拠に一次回答します。 解決しないときは 調べた内容ごとエンジニアへ引き継ぎます。 エンジニアは調査済みの問い合わせだけを受け取ります。 BaseMachina を検索 B # support-triage ホーム 14:01 小 小林 @テクサポ 請求書の再発行はお客様側の操作でできますか？ A社から問い合わせが来ています DM アクティビティ その他 小 12 👀1 1件の返信 テクサポ APP 14:01 回答をまとめています 【結論】 現在の機能で、お客様自身の操作で再発行できます。 【詳細】 請求画面で対象の請求書を開き「再発行」を選ぶと、 宛名と発行日を変えた PDF を作れます。 再発行分は元の請求書番号に枝番が付き、 元の請求書はそのまま残ります。 【根拠】 • コード: 請求書の再発行処理（該当箇所を見る） • 社内ドキュメント: Notion 「請求書の再発行手順」（最終更新 2026-07-12） 33
34. 05. 開発のループの外を自動化する データ変更も含めてCS対応を全自動化 ベースマキナと連携し、登録したアクションだけで本番のデータを確認・変更します。 登録したアクションだけを実行 自動実行 resume-integration 承認必須 update-billing-address 承認必須 権限・承認・監査ログもベースマキナで管理 get-integration-status PostgreSQL 本番DB（RDSなど） MySQL 本番DB（RDSなど） BigQuery DWH Snowflake DWH REST API 社内API GraphQL 社内API 34
35. 05. 開発のループの外を自動化する 未解決の要修正チケットを MCPでエージェントへ 解決しなかった要修正のチケットはテクサポのMCPで エージェントに渡せます。 ClaudeやClaude Codeから呼び出して 修正のPRまで進めます。 サポートで見つかった不具合もファクトリーで直せます。 claude — ~/billing > 開発中 テクサポの未解決の要修正チケットを見て 直せるものから直して • tekusapo - list_escalations (MCP) (status: " └ 3 件 未対応", needs_fix: true) の部署名が文字化けする T-145 請求書の宛名が途中で切れる T-147 退会後も通知のメールが届く • T-142から直します。CSVの出力で 文字コードの指定が抜けていました。 T-142 CSV • Update(src/export/csv.ts) 行を追加、1行を削除 └ 2 • tekusapo - update_escalation (MCP) └ T-142 を対応中にし、PR #57を記録 35
36. 05. 開発のループの外を自動化する リリースした変更を CS・営業へ先回りで共有 GitHubに取り込まれた変更を テクサポがSlackへ定期的にまとめます。 お客さまに関係する変更と不具合の修正に分け 根拠のプルリクエストを添えます。 ファクトリーが出した変更を CS・営業が自分で説明できます。 BaseMachina を検索 小 # cs-updates 12 テクサポ APP 9:00 最近のプロダクトアップデートまとめ（9/29〜10/5） GitHub のリポジトリに取り込まれた変更です。 example/app（ main ） 変更 24 件 ・ リリース 1 件 GitHub で見る お客さまに関係する変更 • 請求書の一覧で、発行日で絞り込めるようになる変更が入りました #412 • CSVエクスポートで、日付の形式を選べるようになる変更が入りました #405 不具合の修正 • 宛名が長いと請求書のPDFで文字が切れる問題を直す変更が入りました #409 社内向けの改善 • テストとCIの設定を整える変更が入りました #401 #403 リリース • v2.14.0 を公開しました v2.14.0 example/docs（main）に取り込まれた変更はありませんでした。 36
37. 06 PR 宣伝です！ブースとプロダクトのご案内
38. 06. 宣伝です！ブースとプロダクトのご案内 プロダクトと伴走支援でAIネイティブ化を進める プロダクトはベースマキナとテクサポAIの2つです。AIネイティブ化のコンサルティングも提供しています。 プロダクト プロダクト サービス ベースマキナ テクサポAI AIネイティブ化コンサルティング Internal Tool Builder 仕様確認や不具合の切り分けに コードとドキュメントを根拠に Slackで一次回答します。 業務の棚卸しから エージェントの設計、運用の定着まで ベースマキナのチームが伴走します。 業務システム基盤 社内管理画面・ERPリプレイス AI Secure Gateway AIエージェントの実行を統制 AI Workflow 開発中 常駐型AIワークフロー BtoBサポートのAIエージェント 伴走支援 38
39. 06. 宣伝です！ブースとプロダクトのご案内 ベースマキナのお取引先事業者様 金融・メディア・BtoB SaaSを中心に幅広いステージのお客様の業務を支えています。 39
40. 06. 宣伝です！ブースとプロダクトのご案内 ブースでAIのソフトウェアファクトリーを工場見学 ロボが要件定義から運用までを進めるデモを、ベースマキナのブースで公開中！ スマホでもデモが閲覧可能です！ about.basemachina.com /conference/software-factory 40