コードを1行も書かないCTOのAI駆動開発

AI駆動開発カンファレンス2026夏 資料

Transcript

1. コードを1行も書かない CTOのAI駆動開発 「書く」を捨てた先に残ったたった2つの仕事 ランスティア株式会社/クマイ総研 熊井悠 2026.7.31 AI駆動開発Conference Summer
2. 本登壇で話したいこと その1 その2 その3 約3年間の AI駆動開発の歴史 まだ残る たった2つの仕事とは？ エンジニアが AI時代に目指す道は なぜコードを 書かなくなったのか？ AI駆動開発における 重要な2つのポイント どのようなキャリアを 目指していくべきか 目的 AI駆動開発の時代に何をインストールすべきか解説します！
3. 自己紹介 熊井 悠（本名：竹下祐豪） ランスティア株式会社 CEO/CTO エンジニア→PM→ITコンサル PMとして400-500人月/年のプロジェクト管理を実施 システムPM/インフラPM 両方を経験していることが特徴 「クマイ総研」というAI駆動開発コミュニティを運営 ・シンプレクス（2015-2018） ：Javaエンジニア・PL・PM ・ベイカレントコンサルティング（2019-2020）：ITコンサルタント ・2社起業（2019-2025 / 2020-現在） ・受託開発を中心としたビジネスを展開 ・2023年からAIを活用したシステム開発検証（OpenAI APIの自社組み込み） ・2024年から本格的にAI駆動開発をチーム展開 ・2025年 Rinstack リリース / GEAR.indigo 事業譲受
4. その1 約3年間のAI駆動開発の歴史
5. はじめに：当社の紹介 ランスティア株式会社 2020年 創業。システム受託開発ベンチャーとして事業を行ってきた。 2024年頃よりAIスタートアップとしてプロダクト開発などの事業も実施。 直近では日本全国にAI駆動開発を浸透するべく活動中！
6. 大きな変遷の紹介 2023年7月 2023年9月 2024年4月 1 2 3 要件定義生成検証 コード生成検証 AI駆動組織へ 要件定義領域でOpenAI Cursorを利用したコード AI駆動開発の組織化に着 APIを利用してフロー図作 生成の検証。既存コードの 手。UI生成系のサービス 成などできないかを検証。 拡張や相談であれば使える が登場したことで明確なチ 当時の性能では難易度が高 ようにはなってきた。 ーム分けをすることで体制 かった。 を実現した。
7. AI駆動開発の変遷① 2024年❶ 開発チーム Bizチーム プリセールス・上流工程 GitHub Push/Merge 結果 CI・CDパイプライン デプロイ 結果 テスト環境・本番環境 不具合報告（Issue） 単体テスト実行・セキュリティスキャンなど QAチーム
8. AI駆動開発の変遷② 2024年❷ 開発チーム Bizチーム プリセールス・上流工程 GitHub Push/Merge オフショアチーム 結果 CI・CDパイプライン デプロイ 単体テスト実行・セキュリティスキャンなど 結果 テスト環境・本番環境 不具合報告（Issue） リファクタリング・追加開発など QAチーム
9. AI駆動開発の変遷③ 2025年 AI駆動開発チーム ノウハウ・ツール提供 Issue定義（受託ならSales担当も） フィードバック 開発チーム Bizチーム GitHub Push/Merge AIエージェント 結果 CI・CDパイプライン デプロイ 単体テスト実行・セキュリティスキャンなど 結果 テスト環境・本番環境 不具合報告（Issue） 常に最新情報からAI駆動開発の進化をはかるチーム QAチーム
10. AI駆動開発の変遷④ 2026年 AI駆動開発チーム ノウハウ・ツール提供 Issue定義（受託ならSales担当も） フィードバック AIエージェント Bizチーム GitHub Push/Merge 単体テスト実行・ セキュリティスキャンなど 結果 テスト環境・本番環境 不具合報告（Issue） 設計レビュー 品質管理チーム 結果 CI・CDパイプライン デプロイ 常に最新情報からAI駆動開発の進化をはかるチーム テスト設計・実行（半自動化）
11. 僕の担当するCTOの仕事は？ PjM・PdMの監督/指示、品質の担保（リリース判定） （直下）プロジェクトの開発 （直下）プロダクトの開発 （その他）AI駆動開発の仕組みづくり CTO PjM プロジェクト開発 プロジェクト開発 PdM プロダクト開発 プロダクト開発
12. 直下の開発案件のAI駆動開発 生産性 自社AIプロダクト開発は「開発〜リリース」まで5日間で完了 プロダクト開発 プロジェクト開発 （受託開発） ・設計〜開発〜テストも全般完了 ・AWS構築・デプロイ〜CI/CDも全てAIにて完了 約10人月の受託開発は2週間で完了 ・80％の開発は10時間で完了 ・その後、VibeOpsの概念により1.5週で完了 結果として2026年はコードを1行も書いてません。
13. なぜAI駆動開発で最速化できているか？ これまでの経験として ①仕組みの構築経験が多い ②フルスタックな学習を継続的につづけている
14. ①仕組みの構築経験が多い SIer時代に事業部（100プロジェクト超）にて 下記の導入をやってきたため、仕組みの導入や浸透経験がかなり豊富 GitHub（SVNから移行） Slack（全社展開） CI/CD（Jenkins） コンテナ化（Docker） PagerDuty（運用系） クラウド化（AWS） 自動テスト
15. ②フルスタックになる学習を継続的につづけている 年間1技術の学習・経験をモットーにつづけている。 なお、必ず実務をセットにすることにしている。 言語：Java、JavaScript（Vue/React） 、C++/ C#、Python インフラ：AWS設計/構築、Google Cloud設計/構築、 （オンプレ） DB：Oracle、MySQL、PostgreSQL その他：機械学習（ML） 、ブロックチェーン、AI（LLM）エージェント 要件定義・設計はエンプラ標準のものを重点的に書籍等で学習。
16. どう作用するか？ ①仕組みの構築経験が多い ②フルスタックになる学習を継続的につづけている 「仕組み」を作って 「選択・目利き」をする仕事が かなり進めやすい。 これが、そのままAI駆動開発化につながっている。
17. その2 まだ残るたった2つの仕事とは？
18. 残る2つの仕事はなんだ？ 前述の通り「仕組み」を作って「選択・目利き」をする AI駆動開発チーム ノウハウ・ツール提供 フィードバック 設計レビュー 品質管理チーム AIエージェント Bizチーム Issue定義（受託ならSales担当も） 常に最新情報からAI駆動開発の進化をはかるチーム GitHub Push/Merge 結果 単体テスト実行・ CI・CDパイプライン セキュリティスキャンなど デプロイ 結果 テスト環境・本番環境 不具合報告（Issue） テスト設計・実行（半自動化）
19. 一方で僕の時間の使い方を見てみる 会議 （お客様MTG） 移動 会議 （お客様MTG） 移動 会議 （お客様MTG） 仕組みの メンテナンス ほぼ外出しており コーディングなどの作業は ほぼしていない ただこれでも 設計・開発・レビューはしている。
20. 理由は、エージェント自走型に注力しているから AI駆動開発の支援コンサル時の社内資料の抜粋 自走するために「何ができるか」 「どう進めるか」を チューニングし続ける
21. AI駆動開発の仕組み化のポイント エージェント自走型を達成する際の仕組みは次の3つがポイントとなる 1 2 3 開発プロセスを 並列エージェントへ 着手前に 開発しておく 経験値と学習を スキルへ
22. ①並列エージェント：背景となる「Anthropicエンジニアブログ」 『並列処理チームによるCコンパイラの構築』記事に書かれていて特に役立ったものを列挙する。 記事の概要 Anthropicの研究者Nicholas Carliniが、16個のClaude Opus 4.6エージェントを並列稼働させ、 RustベースのCコンパイラをほぼ自律的に構築した実験レポート。 約2,000セッション、APIコスト約$20,000（約300万円）で、 10万行のコンパイラがLinuxカーネルをコンパイルできるレベルに到達した。 エッセンス ・無限ループハーネスで永久ループ ・並列化のアーキテクチャで各エージェントは専用環境で稼働 ・仕様駆動×テスト駆動（TDD）
23. ①並列エージェント：運用している並列エージェントのフロー 構造 フロー Parent Agent CLAUDE.md を読みタスクを分解・並列実行 Task 調査 Task テスト ぼく Claude Code 〇〇を作って 調査 Task 実装 OK! 既存実装（あれば）を調査 仕様書生成 方針と仕様を作成 各タスクはサブエージェントで実行 TDD→実装→リファクタ 完了まで永久ループ 仕組みのポイント ・テストファースト ・結果出力ログは最小化＋コンテキスト節約 ・タスクの粒度を自動調整 完了チェック！ E2Eテスト 動作確認・検証
24. ①並列エージェント：実際の処理の流れを図解する Issue設定 調査 調査 仕様・設計 実装・UT ミクロレビュー 実装・UT 記載 調査 チェック 実装・UT ポイント ・ほとんどの思考をSkillで各工程に仕込む ミクロレビュー マクロレビュー ミクロレビュー チェック ・各工程の成果を常に数値判定 ・マクロ/ミクロの二重チェック
25. ②着手前に開発：AIが参照・改修するためのコードセットを用意 仕組みのメンテナンスはAI駆動開発の仕組み（Skill・CLAUDE.mdなど）だけではなく 次作る際に「コンテキスト」になりうるコードセット（サンプル）を用意しておく コードセット AI駆動の仕組み プロジェクト 開始！ 要件定義 ・設計 CI/CD ▲事前に用意していくことでスタートダッシュが切れる いきなり導入（0日導入）からアジャイルでスタートする 開発 ・テスト
26. ②着手前に開発：いわゆる「0日導入」のステップ 1. プロジェクト開始時に「コードセット」を環境（テスト環境）にデプロイ 2. お客様と「コードセット」をもとに要件定義・設計をする 3. ドキュメントは「コードセット」前提の雛形を差分修正するのみ 4. 可能な限り定例会では「アップデート」したものを見せる 導入 要件 要件 要件 実装 実装 実装 人間は、要件をイシュー化しパイプラインへ伝達する
27. ②着手前に開発：1つのイシューフロー ドキュメント システムを見せて 要件定義をする 事前にリバース エンジニアリング ドキュメント更新 0日導入 Issue登録 クラウド環境へ デプロイ 稼働開始 Update コードありきのAI駆動開発で 無駄なステップを最大限排除する ＝車輪の再発明の防止
28. ③スキル構築：どのように理想的なスキルを用意するか？ 自分が設計するなら〜の経験則に裏打ちされた思考をSkill化 レビュー観点やズレのチェックをSkill化 単体テスト設計などテスト設計をSkill化 その結果を必ず評点をつけて判定。そしてループさせる 並列で動いたものをミクロでレビューし、 最後に総合的にマクロでレビューすることで全体を担保
29. ③スキル構築：仕組み化・スキル化のポイントはAI任せにしない 必ず普段の自分の思考プロセスから考える 単発・単体で終わらせず連続したフローとする 書籍などの学習で内容を随時補う 常にメンテナンスをしていく 各工程・並列実行時の整合性など 漏れがないようにチェック対象を選別する
30. ここまで実現できると・・・？ 実は「選択・目利き」はほぼなくなる。 結論、残る2つの仕事は「仕組みづくり」と「思考」 そして思考は主に2つを意識する。 技術：QCDを高める方法を考える ビジネス：何を作るか考える
31. そして、 「思考＝壁打ち」ではなく、正しい思考フロー 正しい 情報源 正しい 思考フレームワーク 正しい フィードバック コミュニケーション 現場を見る コンテキストを集める フレームワーク選定 イシュー定義 思考のフィードバック バイアスの排除 開発プロセスほどではないが、 思考の仕組みを作ることで 正しい選択肢を確率高く導くことができる 参考▶︎
32. その3 エンジニアがAI時代に目指す道は
33. エンジニアがAI時代に目指す道は？ ここまでの話を振り返ると、次が求められるもの ・仕組みを構築する ・思考フローを磨く つまり、これらを継続的に取り組み・学び アウトプットできる道が最高
34. さらにブレイクダウンしてみると、これらが重要！ ・仕組みを構築する → 技術知見（設計・アーキテクチャ）を高める → フルスタックな知識を手にいれる → 仕組み化（AI駆動やCI/CD）できる力をつける ・思考フローを磨く → あらゆる手段で思考の土台の知識を手にいれる → 思考フレームワークを身につけ、引き出す → 思考から得られたアウトプットをどう評価するか考える
35. あれ？よく言われる「ドメイン知識」は？
36. 元コンサルタントとして経験したのは① ドメイン知識が 「頭の中に完全に揃っていること」はほぼない つまり一人では限界がある。 個人的にも得意と思っていた「金融」領域も クライアントの副社長と会話したら システム側の知識だけだったと思い知った=視座が低い
37. 元コンサルタントとして経験したのは② 正しい「イシュー定義」をもとに 最短で必要な情報を集めるといった思考プロセスが重要。 どう集めるか、どう整理するか、どう評価するか、が大事！ Garbage In, Garbage Out 「ゴミを入力すると、ゴミしか出力されない」 正しい「解」に辿り着くための 思考のフロー化（情報入手→整理・分析→判定）が大前提
38. まとめ ぜひ下記を取り組めるポジションを目指すことをおすすめします ・仕組みを構築する → 技術知見（設計・アーキテクチャ）を高める → フルスタックな知識を手にいれる → 仕組み化（AI駆動やCI/CD）できる力をつける ・思考フローを磨く → あらゆる手段で思考の土台の知識を手にいれる → 思考フレームワークを身につけ、引き出す → 思考から得られたアウトプットをどう評価するか考える
39. さいごに。 本日の補足スライドは下記よりダウンロード可能です！ ぜひどうぞ！ こちら
40. 以上となります！ ご清聴ありがとうございました