アイデアを8年間、ずっと温めたままにしていた経験はありますか？「いつか作ろう」と思いながら、毎回「難しすぎる、退屈すぎる、失敗リスクが高すぎる」という理由で先延ばしにしてきた、あのプロジェクト。Google Perfettoチームのシニアエンジニア、Lalit Magantiがまさにそうでした。
ところが2025年末、AIコーディングエージェントを試してみたことで、何かが変わりました。「今回は本当にできそうだ」という感覚。結果として250時間、3ヶ月でsyntaqliteというSQLite開発者ツールをリリースしました。 でも、この話が本当に面白いのは——成功ストーリーではなく、失敗と再スタートの記録だという点です。
これは何?
Lalit MagantiはGoogleでPerfettoというパフォーマンス分析ツールを開発しています。 このツールにはSQLiteベースのクエリ言語があり、ユーザーがフォーマッター、リンター、エディタ拡張を求めるようになってきました。問題は、既存のSQLiteツールがすべて不完全、または遅い、あるいは柔軟性に欠けていたことです。
「それなら最初からきちんと作ろう」と思うかもしれませんが、SQLiteのパーサーをゼロから作るのは、言語に公式仕様がなく、ソースコードが極めて複雑なCで書かれているため、サイドプロジェクトとしてやるには難しすぎて退屈な作業でした。 400以上の文法ルールをひとつひとつ定義し、それぞれのテストを書き、バグを修正する……。そのため8年間「やりたいけどできない」という状態が続いていました。
なぜこの話が「非開発者」にも重要なのか
これはコーディングの話のように見えますが、本質は違います。「難しすぎて退屈で先延ばしにしてきたプロジェクトを、AIでついに始められるようになった」という話なんです。マーケターの自動化システム、デザイナーのデザインシステム、企画者のデータパイプライン——あなたにもこういうプロジェクトがありませんか？
何が変わるのか?
Lalitの3ヶ月は大きく2つのフェーズに分かれます。そしてこの2つのフェーズの違いこそが、この記事の核心です。
フェーズ1：バイブコーディング（1月）——失敗
2025年のクリスマス休暇中に「Claude Codeマックスプラン（月額200ポンド）で全部バイブコーディングできるか？」を試してみました。 技術的な判断から実装まで、ほぼすべてをAIに任せ、自分は「半技術的なマネージャー」の役割だけを担いました。
結果は？機能的には動きました。パーサー、フォーマッター、ウェブプレイグラウンドまで出来上がり、500以上のテストも生成されました。でも1月末にコードを詳しくレビューしてみると——完全なスパゲッティでした。
関数はランダムなファイルに散らばり、1つのファイルが数千行になり、Pythonの抽出パイプラインは自分でも理解できない状態。アプローチの有効性は証明できましたが、このコードで実際のユーザーをサポートすることはとてもできませんでした。
結局すべて捨てて、最初からやり直しました。
フェーズ2：エージェンティックエンジニアリング（2〜3月）——成功
2回目の挑戦で大きく変わったのは、自分自身の役割です。
| フェーズ1：バイブコーディング | フェーズ2：エージェンティックエンジニアリング | |
|---|---|---|
| 人間の役割 | 半技術的なマネージャー | 設計者＋レビュアー |
| 設計の判断 | AIに委任 | 人間が直接行う |
| コードレビュー | 最小限 | すべての変更をレビュー |
| リファクタリング | 「後でやる」 | 各バッチ後に即実施 |
| AIの用途 | すべて | 実装＋リサーチ＋反復作業 |
| 結果 | スパゲッティコード → 全面廃棄 | リリース可能なプロダクト |
Simon Willisonが整理したエージェンティックエンジニアリング（Agentic Engineering）の概念がまさにこれです。 Andrej Karpathyが作った「バイブコーディング（Vibe Coding）」がコードを忘れてしまうものだとすれば、エージェンティックエンジニアリングはAIがコードを書きつつ、人間が設計・検証・方向性を決めるというやり方です。
始め方のポイント：AIで先延ばしにしてきたプロジェクトを動かす
プロトタイプはバイブコーディングで。プロダクションには絶対使わない
最初のフェーズでAIに「これは実現できる？」を検証してもらうのは素晴らしい戦略です。Lalitも、バイブコーディングの1ヶ月がアプローチの有効性を証明してくれたと言っています。ただし、そのコードをプロダクションで使おうとした瞬間に崩れます。プロトタイプ ≠ プロダクション。
設計は必ず人間が行う
AIは「この関数をこう実装して」には優れていますが、「このAPIはユーザーにとって良い体験を与えるか？」には弱いです。 アーキテクチャ、公開API、ユーザー体験——これらは「客観的に検証できる正解」がない領域であり、AIが最も苦手とするところです。
リファクタリングを習慣にする
AIが産業規模でコードを生成するなら、リファクタリングも産業規模でやる必要があります。やらなければ、すぐに手に負えなくなります。Lalitは「大量生成バッチのたびに‘これは汚いか？’と自問した」と言っています。 AIには見えない大きな抽象化は人間が方向を示し、実行はAIに任せましょう。
AIをリサーチアシスタントとして活用する
Lalitが最もROIが高かったと言うのはコード生成ではなくリサーチです。 知らないアルゴリズムを習得するのに1〜2日かかるところを、1時間の対話で完結。VS Code拡張APIを初めて学ぶのにかかる1日を1時間に短縮。慣れていない領域への参入障壁を大幅に下げてくれます。
「スロットマシン依存」に気をつける
「もう一回プロンプトしてみよう」——AIコーディングで最も危険な落とし穴です。 疲れているときにプロンプトは曖昧になり、結果は悪くなり、さらに試して、さらに疲れる悪循環。こういうときはAIを切って自分で書いた方が早いです。AIの使用にもエネルギー管理が必要です。
METR研究が示す不都合な真実
METRの2025年RCT研究によると、熟練したオープンソース開発者がAIツールを使うと、むしろ19%遅くなったという結果が出ました。 さらに驚くべきことに？開発者たちは自分が20%速くなったと信じていました。Lalitの経験とまったく一致します——AIは「速くなった感覚」を与えますが、設計負債と理解度の喪失という見えないコストがあります。
さらに深掘りしたい人へ
Eight years of wanting, three months of building with AI — Lalit Magantiによる完全な振り返り記録。プロジェクトジャーナルとコミット履歴を証拠として示した、誠実な記録です。
Agentic Engineering Patterns — Simon Willisonが整理したAIコーディングエージェント活用パターン。バイブコーディングとエージェンティックエンジニアリングの違いを明確に解説しています。
METR: Measuring AI Impact on Developer Productivity — 「AIツールが熟練開発者を19%遅くする」というRCT研究。体感速度と実際の速度のギャップをデータで示しています。
Karpathy's Vibe Coding vs Agentic Engineering — バイブコーディングを生み出したKarpathy自身も認める限界。趣味用とプロダクション用の違いとは。
