AIコーディングツール5カテゴリ比較｜Cursor・Devin・Lovable・Replit・LangChainの選び方

Cursor、Devin、Lovable、Replit、LangChain を1枚のランキング表に並べて「どれが一番賢いか」を比べても、導入判断にはほとんど使えません。壊れる理由は単純です。5つは同じ土俵で競っているのではなく、別々の作業面を売っているからです。同じ「AIコーディングツール」という言葉でくくった瞬間に、比べるべき軸が消えてしまいます。

この記事を書いているのは、単体のdeep dive記事だけでは答えられない問いに何度もぶつかったからです。

個別のdeep dive記事を並べて読み返すと、4本がそれぞれ別の軸で対象を切っていることに気づきました。Cursorの記事はARR成長や評価額の推移という企業の成長物語を軸に置いています。Devinの記事は「委任可能タスクの3条件」という一つの判断フレームに絞り込んでいます。Lovableの記事はPlan Mode→Agent Mode→GitHub syncというbuild workflowの段階で読み解いています。Replitの記事は「立ち上げコストvs保守コスト」という別の軸で書かれています。4本それぞれの切り口はその対象単体を読むには正しいのですが、どれか一つを借りても「では自社はどれから入れるべきか」という横串の問いには答えられません。成長物語の軸ではLovableとReplitの違いを説明できず、委任可能タスクの軸はCursorの日常的な編集作業には当てはまらず、workflowの軸は非同期実行を主軸に置くDevinとは噛み合わないからです。4本を書き終えたあとに残ったのは、この空白でした。

本記事は、その横串の選定軸だけをdocsベースで組み立てる試みです。大規模組織での導入検証に基づくものではなく、各社公式ドキュメントの読解と、個別記事の執筆で得た範囲の判断であることを先にお断りしておきます。

価格・プラン・利用上限は変化が速いため、最終判断の前に各社の最新ドキュメントを必ず確認してください。以下で比べているのは値段そのものではなく、5つが引き受けている作業面の違いです。

---

前提: 作業面とコードの正本

比較を始める前に、2つの言葉を定義します。定義しておかないと、この先の主張は反証できない、つまりただの感想になってしまいます。

作業面とは、そのツールが実際に引き受ける仕事の範囲を指します。この記事では次の3点で決まるものとして扱います。

1. 誰が主役か(人間がエディタで書き続けるのか、AIのセッションが作業の単位になるのか)
2. コードの正本がどこにあるか(次に定義)
3. 何に対して課金されるか(seatなのか、実行量に応じたcomputeなのか)

コードの正本とは、障害や不整合が起きたときに「これが正しい状態だ」と宣言できる置き場所と、そこへのmerge権限の所在を指します。GitHubのrepoなのか、Lovableのproject内部なのか、Replitのworkspaceなのか。ここがずれていると、AIがどれだけ賢くても運用は壊れます。

「同じ箱に入っていても責任が違うものは比較にならない」という切り口自体は、この記事が初めてではありません。OSSレイヤーでVibe Coding時代のAIエージェントOSS7カテゴリ整理に一度使った論法を、今回は商用ツール側に当てています。違うのは、そこでは「責務」という言葉で止めていた区分を、ここでは作業面という言葉として定義し切っている点です。

以下、この2語で5つの選択肢を並べ直します。

---

全体像: 5つの作業面

この表だけでも、Cursor vs Devin と Lovable vs Replit は比較になりやすい一方で、LangChainは「買うツール」というより「自分で作るための部品」であることが分かります。以下の各節でも、LangChainだけは比較の対象ではなく別レイヤーとして扱います。

---

選定を決める3つの変数: 主役・正本・課金単位

ツール名を見る前に、次の3つを自分のチームに当てはめると選定がぶれにくくなります。逆に言えば、この3つの答えさえ一致していれば、あとは好みで選んでも大きな失敗にはなりません。

主役: 人間かAIセッションか

• 人間がエディタで書き続ける前提なら Cursor 寄りです。AIはエディタ内やPRレビューの支援役にとどまります。
• チケット単位でAIに任せたいなら Devin 寄りです。セッション単位で非同期に回し、PRで受け取る設計がしやすくなります。
• 自然言語からアプリを先に形にしたいなら Lovable か Replit です。Webアプリ起点ならLovable、ブラウザ完結のworkspaceならReplitが近くなります。
• 自社固有のエージェントを組みたいなら LangChain / LangGraph / LangSmith です。

正本: どこを「正」と宣言するか

既存のGitHub repoを正本にするならCursorとDevinが自然です。LovableはGitHub syncを組めばGitHubへ正本を寄せられますが、組まない限りproject内部が正本になります。Replitはworkspace起点の開発と相性がよく、まずはブラウザで完結させたい場面に向きます。LangChain stackは自社repoとruntimeを自分で管理する前提です。

この「正本」という軸には、権限とレビューの設計も含めて考えます。誰がsecretsを持つか、誰がPRやdeployを承認するか、誰がusage budgetを監視するか。これらはdemoでは見えず、導入後に初めて差になって現れる論点です。正本が曖昧なチームほど、ここでつまずきます。

課金単位: 何が増えると費用が動くか

月額のheadline priceだけで判断すると失敗しやすい領域です。editor seatのような固定費で増えるのか、Background AgentsやACU、creditのような実行量ベースで増えるのか、hostingや監視基盤のような運用コストで増えるのか。この3種類のどれが支配的になりやすいかは、ツールごとに構造が違います(詳細は各ツールの節と、後半の「著者の持ち帰り」で扱います)。

---

Cursor: 人間が運転席に座ったまま加速する

Cursorを選ぶときの本質は、「AIにコードを書かせるか」ではなく、既存のソフトウェア開発ループをどこまでエディタ中心に保ったまま加速できるかにあります。

Cursor docsでは、Agentがコードベースを探索し、複数ファイルを編集し、コマンドを実行し、エラー修正まで進める前提で整理されています。project rulesは.cursor/rulesに置け、GitHub integrationとBackground Agentsを組み合わせると、issueやPR起点の非同期実行にもつなげられます。つまりCursorは、フォアグラウンドの編集とバックグラウンドの非同期実行を、1つのエディタ体験の中に両方持たせる設計です。

Cursorは、「エンジニアが自分のエディタを手放したくない、しかしエディタがAIの都合に合わせた別物になるのも避けたい」という組織に合いやすい選択肢です。完全自律よりも、人間がハンドルを持ったまま速くするツールとして見ると位置づけが安定します。

Devin: チケットを非同期で委譲する

Devinを検討するときは、エディタの拡張として見るより、チケット駆動で動くAIメンバーとして捉えたほうが実態に近くなります。

Devin docsでは、セッションごとの作業、GitHub / Jira / Slack連携、usage budget、Session Insights、エンタープライズ向けの導入が整理されています。課金はACUで管理され、Coreはpay-as-you-go、Teamsはseatと月次ACUを組み合わせる設計です。Devinの導入判断は、どれだけ賢いかではなく、どれだけ安全にbacklogを流せるかにかかっています。

Devinは、「AIにコーディング支援をしてほしい」組織より、「境界が明確なタスクをAIに渡し、あとでPRを受け取りたい」組織に向いています。人間との同期的な会話より、非同期のタスクキューをどうさばくかが重要な現場ほど効きやすいツールです。

---

Lovable と Replit: 正本の置き場所で分かれる2つのbuilder

LovableとReplitは、どちらも「セットアップなしですぐ作り始める」という価値提案が近く見えます。しかし主戦場は1点で分かれます。コードの正本を最初からGitHubに寄せる設計か、workspace自体を正本として使い切る設計か、という点です。

Lovable docsでは、GitHub integration、Supabase integration、workspace roles、custom domains、Code mode、credit制、Business planのSSO・制限付きproject・データ学習からのオプトアウトが整理されています。GitHubを接続すれば双方向同期が可能で、GitHubを正本として扱う設計を取りやすくなります。PMや創業者が会話からWebアプリを先に形にし、あとから開発フローに接続したい場面に向きます。

Replit docsでは、ブラウザ完結のworkspace、Agent、Design Canvas、公開機能、Secrets、チームでの共同編集、モバイルアプリ、プランごとのcreditが案内されています。ローカル環境なしでbuild・run・shareまで一気通貫にしたいかどうかで判断すると使い分けやすくなります。教育やハッカソン、個人開発のように環境配布のコストを減らしたい場面に向きます。

どちらを選んでも、後からGitHubへ正本を移せる設計にしておくかどうかが、prototypeで終わるか、継続運用するproductになるかの分かれ目です。

---

LangChain stack: buildする側の部品

LangChainをここまでの4つと同じ粒度で比べると混乱します。LangChainはend-user toolというより、自社でagentを構築するためのframework・runtime・監視基盤の組み合わせだからです。

LangChain docsでは、create_agentを中心とした高レベルAPI、LangGraphのdurable execution(処理を永続化する実行)とhuman-in-the-loop、Deep Agentsの計画・サブエージェント・ファイルシステム指向のワークフロー、LangSmithのトレーシング・モニタリング・評価・アラートが分かれています。要するに、LangChain stackを選ぶのは「AIコーディングツールを買う」ときではなく、自分たちのagent productを作るときです。

buildする側に回る覚悟がある組織にだけ向きます。deploy、secrets、guardrails、コスト管理を誰が運用するか、単純なchat appではなくdurable workflowやHITLが必要か、repo・CI・評価・prompt versioningを回せる開発組織の成熟度があるか。この3点が揃わないなら、まずCursorかDevinで既製のtoolを使う方が安全です。

---

再整列: 責任分界で並べ直す

ここまでの5つを、もう一度「誰が主役か」ではなく「責任をどこに置くか」で並べ替えます。

CursorとDevinは、どちらもエンジニアリング組織向けですが、責任の置き所が違います。Cursorは人間が主役のまま、編集とPRレビューの往復に責任が残ります。DevinはAIセッションが主役で、レビューの責任はPRを受け取る人間に移ります。完全な二者択一ではなく、Cursorで日常開発を回しつつDevinにbacklogを投げるという併用は、責任の置き所さえ分けておけば現実的です。

LovableとReplitは、「すぐ作り始める」という価値は近くても、正本の既定値が違います。Lovableは会話からアプリを組み、GitHub syncで正本を後から移せます。Replitはworkspaceそのものが正本になりやすく、移行性を最初から意識しておく必要があります。

LangChain stackは、この4つの代替ではなく、その先で自分たちのagentを作る側の選択肢です。買うツールの比較に混ぜると判断がぶれます。

これを踏まえて、状況別にまず見るべき選択肢を並べると次のようになります。

---

著者の持ち帰り

ここまでの整理から、私が持ち帰る結論は1つです。この5つを賢さで一列に並べる比較は、導入判断には使えません。第一変数はコードの正本とレビュー責任をどこに置くかで、賢さは第二変数です。

迷うなら、正本を既存のGitHubに固定したまま人間が運転席を保てる選択肢、つまりCursor型から始めるべきだと考えています。Devin型の非同期委譲は、レビューSLAとusage budgetを運用できる体制が先にあるチームだけが踏むべき一歩です。この順番が逆になっている、つまり体制がないままDevin型を先に入れると、賢さ以前に運用が崩れます。

ただしこの立場には境界があります。私が根拠にしているのは各社公式docsの読み込みと、Cursor・Devin・Lovable・Replitそれぞれの個別記事を書いてきた範囲の判断であり、大規模組織での導入検証に基づくものではありません。ここから先は反証を歓迎します。

課金単位についても、同じ境界の中で言えることがあります。

月額のheadline priceだけを見て判断すると、実際に効いてくる負担を見誤りやすいと私は見ています。Cursor Docsのpricing案内はeditor seatと実行量ベースのagent実行分を分けて説明し、Devin DocsのBilling/ACUはACUという実行量ベースの単位を前面に出し、Lovable DocsのPlans and creditsはメッセージ単位のcredit消費を核に据え、Replit DocsのReplit Coreも同様にcredit形式で使用量に応じて費用が動く設計です。4社に共通するのは、固定のseat/plan料金を入り口にしつつ、実際の費用は実行量に応じて動く構造を採用している点です。ここから私は、月額のheadline priceよりもusage-based部分の方が費用の支配的な変数になりやすいと見ていますが、これは各社の課金単位の構造から導いた推論であり、自社や他社での実測に基づくものではありません。

委譲する粒度についても、実務では机上の議論より先に答えが出ます。

2週間の試験導入で確認できれば十分だと考えているのは、次の4点です。

1. 既存repoやworkflowに無理なく入るか
2. 誰がreview / deployの責任を持つか明確か
3. usage budgetの見通しが立つか
4. 失敗したoutputを修正する運用が回るか

この4点さえ確認できれば、あとはツールの相性の問題です。

---

出口: 判断材料を渡す

この記事で言いたかったのは、「Cursorが勝つ」でも「Devinが正解」でもありません。5つのうちどれを選ぶかより先に、コードの正本とレビュー責任をどこに置くかを決めてほしい、というのが私の願いです。それさえ決まれば、ツールの選定はむしろ簡単な部類の意思決定になります。

もう少し踏み込みたい方向けに、実際に書いてきた個別記事を置いておきます。

• Cursorとは？AIコードエディタの使い方と運用ポイントを解説 — Cursor単体をdocsベースで読み解いた記事です。本記事はそこに、他の作業面との横串比較と、選定の第一変数であるコードの正本・レビュー責任を足しています。
• Devinは職能の代替か、委任先か——導入判断の分かれ目 — Devinを「代替か委任先か」という軸で読んだ記事です。本記事はその委任判断を、Cursorとの責任分界比較へ拡張し、併用の現実解を示しています。
• Lovableとは？Plan Mode・Agent Mode・GitHub連携で読むVibe Codingガイド — Lovable単体の運用論点を掘り下げた記事です。本記事ではReplitとの正本の違いに絞って対比しました。
• Replitの使いどころ：ブラウザIDEとAI Agentの導入判断メモ — Replit単体の運用論点を掘り下げた記事です。本記事ではLovableとの正本の違いに絞って対比しました。

この記事自体、docsをもとにした一度目の整理です。各社の課金体系や作業面は今後も変わるはずなので、大きな変更があれば書き直すつもりです。

---

参考リソース

Cursor

• Cursor Docs: Background Agents
• Cursor Docs: Rules
• Cursor Docs: Pricing

Devin

• Devin Docs
• Devin Docs: Billing / ACU

Lovable

• Lovable Docs: Plans and credits
• Lovable Docs: Integrations

Replit

• Replit Docs: Introduction
• Replit Docs: Replit Core

LangChain

• LangChain Docs
• LangGraph Docs
• LangSmith Docs