Claude Code・Cursorだけじゃない：AIネイティブ開発を支えるクラウド基盤の選び方

AIネイティブ開発とは、AIを後から追加するのではなく、企画・設計・実装・テスト・運用まで、開発工程そのものをAI活用前提で設計する開発手法です。

AIネイティブ開発の本質は、AIを後付けの便利機能としてではなく、開発の前提として工程に織り込む点にあります。従来は、開発者が主体となって設計・実装を進め、必要な場面でAIに補完や相談を依頼していました。

AIネイティブ開発では、目標や仕様を渡すと、AIエージェントが計画を立て、コードを書き、テストを実行し、結果を検証するところまで、複数の手順を自律的に進めます。

Claude CodeとCursorは、「エージェント型」対「エディタ型」という単純な二分法で語られますが、現在はそこまで明確に分かれていません。

単純な二分法ではなく、次の評価軸で並べると、両者の重心の違いと重なりが整理できます。

Cursorはコード補完を中心としたエディタ機能に加えて、自律的にコードを調査・編集・実行するAgent機能や、CLI、クラウド実行も提供しています。

Claude Codeもターミナル専用ではなく、IDE拡張、デスクトップアプリ、ブラウザなど複数の起点から利用できます。したがって、両者には操作体験や設計の重心の違いはあるものの、機能が競合する領域も存在します。

ここまでを踏まえると、意思決定は二層に分かれることが分かります。ひとつは、Claude CodeとCursorのどちらを、どの作業に割り当てるかという「ツール選定」。

もうひとつは、それらが呼び出すモデルの推論先や実行環境をどう用意するかという「基盤選定」です。

この二つを混同すると、ツール比較で満足したまま、本当に投資効果の大きい基盤の検討を後回しにしてしまいます。逆に、基盤の話だけを先行させると、現場のツール活用が伴わず、過剰投資に陥ります。

AI開発をスムーズに進められるツールに関しては、こちらの記事で解説しています。

本記事では、基盤選定を分かりやすくするため、AI活用を便宜上、以下2つに分けて解説します。

第1段階は、開発者一人ひとりが、必要に応じてClaude CodeやCursorを呼び出し、コード補完・リファクタリング・バグ修正などを依頼するスタイルです。

この段階では、AIは指示を受けて作業する補助者であり、LLMの推論処理はAnthropicやOpenAIといった外部APIを利用するのが一般的です。料金は利用したトークン量に応じた従量課金が中心で、少人数のチームであれば月あたり数十ドル規模から始められます。

インフラ側で必要になるのは、安定した回線とAPIキーの管理程度で、専用のGPU基盤を用意する必要はほとんどありません。この段階では、基盤よりもツールの使いこなしとプロンプト設計のほうが成果を左右します。

第2段階は、目標を渡せば計画・実行・検証まで自律的に進めるエージェントとして、開発工程に継続的に組み込む段階です。具体的には、

• 複数のエージェントを並列で走らせてリポジトリ全体のリファクタリングやテスト生成を進める
• CI/CDにエージェントを組み込んでIssueのトリアージや脆弱性の検出・修正を自動化
• 自社コードやドキュメントを対象にRAGを構築して社内知識に根拠を置いた生成を行う

などを行います。

オープンソースのLLMを自前でホストし、機密コードを外部に送らずに運用する構成も、この段階で選択肢に入ります。ここまで進むと、外部APIだけで運用を続けるか、自前ホストを併用するかを、コストと要件の両面から比較する必要性が高まります。

第1段階と第2段階では、必要な基盤の前提が大きく異なります。下の表に結論を先に示すと、第1段階はツール活用が主で基盤の関与は小さく、第2段階では基盤設計そのものが検討対象になります。

重要なのは、第2段階に進んだからといって、必ずしも自前GPUが必要になるわけではないという点です。第2段階の中でも、外部APIを継続利用する構成と、自前ホストを併用する構成の両方があり得ます。どちらを選ぶかは、次章の条件で判断します。

前章で触れたとおり、開発工程への組み込みが進んでも、自前GPUが自動的に必要になるわけではありません。ここでは、以下2つの条件で解説します。

• 外部APIを継続利用できるケース
• 自前ホストや専用GPUクラウドが有力になる条件

複数エージェントの並列稼働やCI/CDへの組み込みが進んでも、外部APIを主軸に運用を続ける企業は数多くあります。外部APIは、初期投資がほぼ不要で、モデルの更新やスケーリングをサービス側に任せられるという利点があります。

利用量が一定の範囲に収まっている場合や、扱うデータの機密度がそれほど高くない場合、あるいは最新の商用モデルの品質を優先したい場合は、外部APIの継続利用が合理的です。

加えて、法人向けの契約では後述するセキュリティ機能が提供されるため、機密性を理由に一律で外部APIを排除する必要もありません。まずは外部APIで運用し、制約が顕在化した領域から見直すという進め方が、多くのチームにとって現実的です。

自前ホストや専用GPUクラウドが必要になるのは、次のような条件が一定の水準を超えた場合です。これらのうち複数が当てはまるほど、GPUリソースを自社の裁量で確保・制御できる基盤の価値が高まります。

• オープンソースモデルを自前でホストし、推論構成を細かく制御したい
• 利用量が大きく、外部APIとのコスト比較で自前ホストが優位になる
• 契約や規程の都合で、外部事業者へのデータ送信が認められていない
• 独自モデルの追加学習や微調整を行いたい
• 専用の処理能力を安定して確保したい

逆に、いずれも当てはまらない段階で自前GPUを導入すると、稼働率が低いまま固定コストだけが積み上がるおそれがあります。

判断にあたっては、これらの条件を一つずつ自社の現状に照らし、いくつ当てはまるかを確認しておくと、検討の解像度が上がります。

ここで避けたいのは、「AI活用が高度化すれば自前GPUが必要になる」という考えです。

実態は、高度化するほど「外部APIだけで運用するか、自前ホストを併用するか」を比較する必要性が高まる、というものです。判断の基準になるのは、機

• 密要件
• 利用量
• 必要なモデル
• 性能要件
• 稼働率
• 運用体制

といった変数であり、これらが一定水準を超えたときに自前ホストが有力な候補として浮上します。したがって意思決定では、「必要か不要か」を二者択一で決めるのではなく、外部APIと自前ホストを総コストと要件で並べて比較し、自社の条件に照らして選ぶという姿勢が適切です。

GPUをサーバー使用する場合の選び方に関しては、こちらの記事で解説しています。

基盤を比較するときは、感覚ではなく共通の評価軸で並べます。ここでは、性能・容量、拡張性・可用性、コスト、セキュリティ・コンプライアンス、可搬性・ベンダー依存の5軸で整理します。まず各軸と確認すべき数値指標を一覧にし、そのあと軸ごとに解説します。

自前でLLMを動かす場合、GPUの種類とVRAM容量は、利用予定モデル・コンテキスト長・同時実行数から逆算して決めます。VRAMはモデルの重みだけでなく、KVキャッシュやランタイムの処理にも使われるため、重みが載るかどうかだけでは判断できません。

VRAMが不足すると、そのままではモデルを起動できなかったり、扱えるコンテキスト長や同時実行数が制限されたりします。量子化、複数GPUへの分割、CPUオフロードなどで回避できる場合もありますが、いずれも速度低下や構成の複雑化を伴います。

確認すべき数値としては、利用予定モデル、必要なVRAM容量、コンテキスト長、同時実行数、生成速度、P95応答時間などが挙げられます。

複数エージェントを同時に走らせると、負荷は短時間で変動します。必要なときにリソースを増やし、不要になったら減らせる柔軟さがないと、ピーク時に処理が詰まるか、余剰リソースでコストが無駄になるかのどちらかに陥ります。

可用性の観点では、障害が起きたときにどこまで処理を継続できるか、復旧までにどれくらいの時間がかかるかも確認します。評価に使える指標としては、

• 想定稼働率
• GPU起動時間
• 最低利用時間
• SLA
• 障害時のサポート体制

などがあります。特に検証段階では、必要な時間だけ確保して終わったら解放できる構成かどうかが、コストと運用負荷の両面で効いてきます。負荷の山が読めない場合は、拡張のしやすさを優先して選ぶのが安全です。

コストは、外部APIと自前ホストで構造が異なるため、単純な単価比較では判断を誤ります。外部APIでは、以下が主な費用になります。

自前ホストでは、GPU稼働時間に加えて、永続ストレージ、データ転送、制御ノード、監視、障害対応、構築・運用の人件費まで含める必要があります。つまり、両者を並べるときは、表面的な単価ではなく、想定利用量に対する総コストで比較しなければなりません。

機密コードを扱う場合でも、「外部APIだから使えない」と一律に判断するのは適切ではありません。法人向けの外部APIでは、サービスや契約によって、次のような機能が提供される場合があります。

• 入力データをモデル学習に利用しない設定
• データ保存期間の制御、Zero Data Retention
• データレジデンシー（処理リージョンの指定）
• 通信・保存データの暗号化
• 監査ログ
• 法人向けの契約・管理機能

したがって評価では、外部送信の可否だけでなく、学習利用の有無、保存期間を具体的に確認します。そのうえで、これらの条件で要件を満たせない場合に、自社の管理境界内で動かせる環境を検討する、という順序が妥当です。

「社内に閉じる」だけでなく、クラウド上でも自社の管理境界内に閉じられるかという視点で見ると、選択肢が広がります。

推論先を後から切り替えられるかどうかは、ベンダー依存のリスクに直結します。自社で開発したエージェント基盤であれば、プロバイダー抽象化層を設けることで、推論先を比較的切り替えやすくできる場合があります。

一方で、Claude CodeやCursorのようなツールでは、対応するプロバイダー、モデル、API形式、ツール呼び出し機能などに制限があり、接続先とモデル名を変えるだけで移行できるとは限りません。

したがって、OpenAI互換のインターフェースがあれば移行が容易、と単純に考えるのは避けます。既製ツールを使う場合は、対応プロバイダー、API形式、モデル機能の互換性を個別に確認し、将来の乗り換えコストを見積もったうえで選定します。

ここでは、状況別の早見表と判断フローを用いて、自社に適した基盤を選ぶ手順を解説します。

基盤の選定に入る前に、自社が第1段階か第2段階か、そして自前GPUを検討すべき条件に当てはまるかを確認します。この確認を飛ばして「とりあえずGPUを確保する」と進めると、稼働率が低いまま固定コストが積み上がり、過剰投資や手戻りにつながります。

逆に、並列稼働や機密要件がすでに顕在化しているのに外部APIだけで運用を続けると、いずれコストやレイテンシ、コンプライアンスのいずれかで問題に直面します。

まずは、利用量・機密要件・必要なモデル・稼働率・運用体制という変数について、自社の現状を棚卸しすることから始めましょう。

自社の状況に近い行を見ることで、投資方針の目安をつけられます。あくまで方向性の目安であり、最終判断は前章の評価軸と自社の要件に照らして行ってください。

たとえば「機密度は低いが独自モデルの学習をしたい」なら、後者を満たすためにGPUリソースを自社裁量で確保できる基盤が要件に入ります。

また、現時点の状況だけでなく、半年後・一年後の利用量や体制の見込みも合わせて確認しておくと、短期間での基盤の作り直しを避けられます。

早見表だけでは自社の位置が定まりにくい場合は、条件を順に分岐させて整理すると判断しやすくなります。次の3つの問いを順に確認していきます。

1. 外部事業者へのデータ送信が認められるか → 認められないなら、自社の管理境界内で動かせる環境が前提
2. 外部APIのコストやレイテンシが制約になるか（並列稼働・大量処理など）→ 制約になるなら、専用GPUクラウドでの自前ホストを比較対象に加える
3. 独自モデルの追加学習が必要か → 必要なら、GPUリソースを自社裁量で確保できる基盤が要件に入る

いずれの分岐でも制限が生じなければ、外部APIの継続利用が合理的です。この分岐を一枚の図にしておくと、社内の合意形成でも使えます。

注意したいのは、この3つの問いは独立しておらず、複数に該当することも多い点です。その場合は、より強い制約から順に満たしていくと、要件の抜け漏れを防げます。

各条件に基づいたAI開発にかかる具体的な費用は、こちらの記事で紹介しています。

AIネイティブ開発では、Claude CodeやCursorといったツールを選ぶだけでなく、それらをどのような基盤の上で動かすかまで考える必要があります。ただし、AI活用を始めたからといって、すぐに専用GPUクラウドやオンプレミス環境を導入する必要はありません。

重要なのは、GPUを導入すること自体を目的にしないことです。自社の利用段階と制約を整理し、まずは必要最小限の構成から始め、利用量や要件の変化に応じて基盤を見直すことが、過剰投資を避けながらAIネイティブ開発を拡張する現実的な進め方です。