はじめに
こんにちは、エクスプラザでエンジニアをしているTsucchiiです。
エクスプラザでは**「AI Native」**な企業活動というのを掲げています。
しかし、この言葉の定義は深く、単に「開発にAIを使う」こととは一線を画します。
取締役のkanやCTOの松本の記事にもあるように、私たちはAI活用を以下の3段階で捉えています。
- AI Ready: データ整備や業務の型化が進んだ状態
- AI Driven: AIを「道具」として徹底的に活用し、人間がオーケストレーションする状態
- AI Native: AIが主体的・自律的に業務を推進し、人間は意志決定に集中する状態
(kan@EXPLAZA取締役の記事より)
私たちが目指すのは当然 「3. AI Native」 です。
しかし、理想のシステムを構築するのも大切な一方、リリースのデッドラインも迫ってきます。
そこで今回は、理想を見据えつつも、あえて現段階で可能な 「2. AI Driven」 のアプローチを極限まで推し進めてリリース直前を乗り切ろうと試みました。
複数のAIツール（Vibe Kanban, Claude Code等）を適材適所で組み合わせ、人間が全力で指揮を執る。
私はこのAI Drivenな手法の集合体を「AI Powered」な開発と位置づけ、リリース直前の総力戦に挑みました。
この記事は、AI Nativeを目指す途上で、泥臭くAI Poweredに戦った生存記録とそこで見えたAI Nativeの輪郭について記したいと思います。
AI Poweredの総力戦：戦略と成果
リリース直前の2日間で22PRを消化
今回採用した「AI Powered」な開発とは、単一のAIツールに頼るのではなく、特性の異なるAIエージェントを使い分け、開発プロセスの大部分をAIにオフロードする戦略です。
この戦略を駆使することで、リリース直前のピークタイム（2日間）で22件ものPR（うちAI主導が12件）を消化することに成功しました。
人間一人の人力では到底捌ききれないこの物量を、以下の3つの役割分担（オーケストレーション）で乗り切りました。
1. Vibe Kanban
GitHub Issueを立てると、勝手にPRを作ってくれる自律型エージェント「Vibe Kanban」。
Vibe Kanban には思考コストは低いが数は多いタスクを任せました。
- 役割: 型定義の修正、文言変更、小規模なバグ修正、リファクタリング等
- 実績: Phase 2（2日間）で**12件（全体の55%）**を処理
「これやっといて」とIssueを投げるだけで、次々とPRが上がってくる体験は、まさに**「優秀な作業員を大量に雇った」**感覚でした。
2. ローカルエージェント (Claude Code)
一方、複雑なバグや設計が絡むタスクには、ローカルで動く「Claude Code」で実装しました。
- 役割: 複数ファイルに跨る仕様不整合の調査、複雑なロジックの実装･修正等
- 実績: 全PRの数は少ないが、**変更量の75%**に関与
彼は作業員ではなく、**「頼れる技術パートナー」**として機能しました。
象徴的な対比：Vibe Kanban vs ローカルエージェント
ここで、2つのAIアプローチの違いや棲み分けが表れたケースがありました。
Vibe Kanbanにもコード参照や計画（Plan）機能はありますが、GitHubを介した**「非同期なGit Workflow」**が基本となるため、ローカルでの試行錯誤スピードに決定的な差が出ました。
問題: 特定の操作でイベントが発火しなくなる、再現性の低いUIバグ。
Vibe Kanbanでの対応:
- ブランチを切って実装→PR作成というサイクルで動くため、「修正→動作確認→修正」のループを回すのに時間がかかる。
- 結果、試行錯誤のコストが高く、表面的な修正（イベント処理の変更）にとどまり根本解決に至らず。
- 結果: 50分後にクローズ
ローカルエージェント (Claude Code) での対応:
- ローカル環境で「ログ埋め込み → ホットリロードで動作確認 → ログ確認」のサイクルを秒単位で回す。
- 泥臭いリアルタイムな調査により、複雑な依存関係（無限ループ）を特定。
- 結果: 18分でマージ成功
教訓:
「仕様の決まったタスク」を並列で捌くのはVibe Kanbanが最強ですが、「現象を見ながら泥臭く調査→実装のサイクルを回す」タスクは、ローカル環境で動くエージェントがやはり強いです。
3. 人間：交通整理と最終判断
そして私（人間）の仕事は、コードを書くことではありませんでした。
まさに 「AI Driven」における人間の役割＝オーケストレーター です。
-
役割:
- タスクの切り出しと、適切なAIエージェントへの振り分け（Vibe Kanban vs Claude Code）
- 上がってきた大量のPRのレビューとマージ判断
- 複雑な問題に対する調査方針の策定
なぜ乗り切れたのか？（成功要因の仮説）
AI Poweredな開発は、ただツールを導入すれば成功するわけではありません。
今回、破綻せずに走りきれた要因は、以下の2点にあったと考えています。
1. 技術・コード・要件への理解
AIは平気で嘘をつきますし、微妙にズレた実装を提案してきます。
大量のPRを捌く中で、「この実装は仕様を満たしているか」「このコードは将来の負債にならないか」を正しく判断する能力はやはり不可欠です。
2. 役割分担（棲み分け）の事前設計
「とりあえずAIに投げる」のではなく、「このタスクはVibe Kanban向き」「これはClaude Codeと対話が必要」という判断基準を自分の中に持っていたこと、そこに大きなズレがなかったこともうまくいった要因だと感じました。
- 定型的なタスク → Vibe Kanban（非同期・並列処理）
- 探索的なタスク → Claude Code（同期・対話処理）
一方、これらができないと、破綻する恐れがある手法だということも自覚しなくてはいけないと感じました。
AI Poweredを経験して見えた、AI Nativeへの距離
リリースには無事間に合いました。
冒頭で述べた通り、今回は半確信犯的に「AI Native（理想）」を封印し、「AI Powered（現実解）」を選択しました。
しかし、実際にこの修羅場をAI Poweredで走り切ったことで、あと何があれば、これをAI Nativeにできたのかという差分が、以前よりも解像度高く見えてきました。
ボトルネックは「人間」
今回のプロセスは、定義通り 「AI Driven（人間がオーケストレーター）」 でした。
Vibe KanbanもClaude Codeも優秀でしたが、彼らが動くためには、常に私が「詳細なIssue」や「明確な指示」を与える必要がありました。
結果として、AIの処理能力が上がれば上がるほど、それを管理する人間の負荷（ボトルネック）が増大するという構造的限界を肌で感じることになりました。
AI Nativeへ至るための「ラストワンマイル」
kan@EXPLAZA取締役の記事にある 「AI Native」 とは、AIが自律的に業務を推進し、人間は意志と熱量を持つリーダーになる 世界です。
今回の「AI Powered」な経験を通じて、この世界に到達するために埋めるべき「ラストワンマイル」の正体の輪郭が見えてきました。
1. PMエージェント（Issueの自動生成）
「Issueを書く」仕事をAIに任せる。
Slackなどのメッセージをトリガーに仕様書や議論から自動的にタスクを生成する存在が必要です。
2. コンテキストの動的同期（知識の外部化）
今回一度Vibe Kanbanでのタスクが失敗したのは、「なぜそのコードになっているか」という背景を知らなかったこと･知らせきれなかったことからです。
人間が頭の中に持っている「暗黙知」や「意思決定の履歴」を、AIが常に参照できる形（Vector StoreやCLAUDE.mdの進化版など）に同期し続ける仕組みはやはり不可欠です。
3. QAエージェント（AIレビュワー）
「PRをレビューする」というボトルネックを解消する。
人間が見るのは「仕様通りの挙動か」だけでよく、コードの品質やエッジケースの検証はAI同士で完結させることができれば理想的です。
4. 人間の役割の純化
そうして初めて、人間は「どう作るか（How）」の管理から解放され、｢なぜ作るのか（Why）｣「何を届けるか（What）」の意思決定に100%集中できるようになります。
おわりに
リリース直前で、AIを道具として酷使した2日間。
それは、AI Nativeという理想へ向かうための、「AI Driven」 の実践でした。
現在はまだ、泥臭くAIを使い倒すフェーズも一定存在するかもしれません。
しかし、その先には確実に、エンジニアリングの概念が変わる「AI Native」な未来を見据える必要性を感じました。
参考リンク
「プロダクトの力で、豊かな暮らしをつくる」をミッションに、法人向けに生成AIのPoC、コンサルティング〜開発を支援する事業を展開しております。 エンジニア募集しています。カジュアル面談応募はこちらから: herp.careers/careers/companies/explaza
Discussion