「AI を使って開発しています」——最近、Web 制作会社や開発会社のサイトでこうした文言を見かける機会が増えました。ただ、発注する側からすると「具体的に何が変わるの?」「品質は大丈夫なの?」という疑問が先に立つのではないかと思います。私たちゼットリンカーでも、2025年の後半あたりから本格的に AI ツールを開発フローに組み込み始めました。この記事では、Next.js 16 と Claude Code を中心に、受託開発の現場で実際に何が起きているのかを、できるだけ正直にお伝えします。
先に、要点をまとめます。
- Claude Code・Cursorは「AIが全自動でシステムを作るツール」ではなく、人間のエンジニアが判断し、AIが手を動かす関係です
- AIに任せやすい作業(CRUD画面生成・テストコード生成)と、人間が判断すべき作業(認証・認可設計、パフォーマンス判断)は明確に分かれています
- 発注側の見積もり・納期への影響は「単純に安く・早くなる」ではなく、「同じ予算でできることの幅が広がる」「手戻りの影響範囲を早く洗い出せる」という形で現れます
- AI駆動開発をうたう開発会社には、発注前に「誰がレビューするか」「コードやデータをどの契約のAIサービスに送るか」「別の会社に引き継げる形で納品されるか」を確認します(後半の質問リスト)
Claude Code や Cursor とは何か?——非エンジニアの方へ
Claude Codeはターミナルで動くAIコーディングエージェント、Cursorはエディタに組み込まれたAI支援機能という違いがあります。
まず、この記事で何度か登場する「Claude Code」と「Cursor」について、技術者でない方にも分かるように説明させてください。
Claude Code は、Anthropic 社が提供している AI アシスタント「Claude」の開発者向けツールです。ターミナル(黒い画面)の中で動作し、エンジニアが自然言語で指示を出すと、コードの生成・修正・ファイル操作などを行ってくれます。イメージとしては「コードが書ける、とても優秀なアシスタントが隣の席に座っている」という感覚に近いかもしれません。
Cursor は、AI 機能が組み込まれたコードエディタ(プログラムを書くためのソフト)です。コードを書いている最中に AI が補完候補を出してくれたり、選択した部分を「こう直して」と指示すると書き換えてくれたりします。
どちらも「AI がプログラムを全自動で作ってくれるツール」ではありません。あくまで人間のエンジニアが判断し、AI がその指示に基づいて手を動かすという関係です。料理に例えるなら、AI は非常に手際のいい調理アシスタントであって、献立を考えるシェフではありません。
私たちの使い分け
正直に言うと、Claude Code と Cursor はかなり用途が重なる部分があります。ただ、私たちゼットリンカーでは概ね次のように使い分けています。
| ツール | 得意な場面 | 動作の仕方 |
|---|
| Claude Code | 新しい機能をまとまった単位で作るとき、既存コードの大きなリファクタリング、テストコード生成、プロジェクト全体を横断する作業 | ターミナルで自然言語の指示を受け、複数ファイルを自律的に編集する |
| Cursor | 日常的なコーディング中の補完、小さな修正やバグフィックス、コードを読みながら素早く理解したいとき | エディタ上でリアルタイムに補完・書き換え候補を提示する |
この使い分けの背景には、両ツールの得意分野の違いがあります。Claude Codeは複数ファイルにまたがる自律的なタスク遂行を得意とする一方、Cursorはエディタとの統合の深さとリアルタイム性で強みを持ちます。実務では、まとまった機能追加はClaude Codeに任せ、その後の細かい調整をCursorで詰める、という流れが定着してきました。
2026年時点では両ツールとも機能面での重なりが増えており、Cursorにもエージェント的にコマンドラインから操作できるモードが追加されるなど、境界は年々曖昧になっています。ただ、私たちが実際の案件で感じている体感としては、複数ファイルにまたがる大きめのタスクを最後まで自律的にやり切る場面ではClaude Codeの完遂力に安定感があり、細部を人間が見ながら調整するようなタスクではCursorの手触りのほうが速い、という住み分けは今も変わっていません。ツール選定そのものよりも、「どの粒度の作業をどちらに任せるか」という運用ルールを社内で明文化しておくことのほうが、結果的にチーム全体の生産性に効いてきます。
具体的に何が速くなるのか?
定型的な画面生成・テストコード生成・型とバリデーションの整合性チェックは大きく速くなりますが、要件の判断や設計そのものは人間の仕事のまま変わりません。
「AI を使うと開発が速くなる」とよく言われますが、すべてが均一に速くなるわけではありません。速くなる部分と、あまり変わらない部分があります。
AI に任せやすい作業
- 定型的な CRUD 画面の生成。 管理画面の「一覧・詳細・作成・編集」といった画面は、構造がパターン化されています。
- 型定義とバリデーションの整合性を保つ作業。 TypeScript の型と Zod スキーマと Firestore のデータ構造を一致させる作業は、AI が得意です。
- テストコードの生成。 「この関数に対するテストケースを書いて」と指示すれば、かなり実用的なテストコードが出てきます。
- コンポーネントの初期実装。 shadcn/ui のコンポーネントを組み合わせた UI の初期実装も、AI が下書きを作り、人間がデザインと突き合わせて調整する流れが定着してきました。
- 既存コードの読解・要約。 引き継いだプロジェクトの構造を把握する際、AIに「このディレクトリの役割を説明して」と聞くと、画面やデータの流れのたたき台がすぐに出てきます。引き継ぎの調査で何を確かめるかは、Next.jsアプリの保守引き継ぎで受け取るものと確認することにまとめています。
人間が判断すべき部分
- 認証・認可の設計。 「誰がどの画面にアクセスできるか」は業務ルールそのものです。AI がコードを書くことはできますが、ルールの正しさを判断できるのは人間だけです。
- パフォーマンスのボトルネック判断。 AI は「こう書けば動く」コードは出せますが、「この画面ではこのアプローチが最適」という判断は人間が行う必要があります。
- エラーハンドリングの方針。 ネットワークエラーへの対処方針はビジネス要件そのものなので、AI が勝手に決めるべきものではありません。
- セキュリティパッチの影響範囲判断。 Next.js本体の脆弱性パッチが公開された際、自社のシステム構成に該当するかどうかの一次判断はAIの提案を参考にしつつ、最終的には人間のエンジニアが確認する必要があります。
要するに、「書く」作業は速くなりましたが、「考える」「決める」作業のウェイトは変わっていません。

実際の開発フローはどう変わったか?
「要件を人間が整理する→実装をAIが下書きする→人間がレビューする」という3工程のうち、実装工程の時間が短縮され、レビュー工程の比重が相対的に増えています。
以下は、よくある機能追加を題材にした進め方の例です。特定のお客様の事例ではありません。自社で検討している機能に置き換えて読んでください。題材は「問い合わせフォームの入力内容を要約してSlackに通知する機能を追加する」という依頼です。
従来のフローでは、エンジニアが要件を確認したあと、フォームのバリデーション実装、Server Actionの実装、Slack Webhook連携、エラーハンドリングをすべて手作業で書き、その後にテストコードを書いていました。
Claude Codeを使ったフローでは、要件確認後に「このフォームの送信内容を要約してSlack Webhookに通知するServer Actionを実装して。Zodでバリデーションし、失敗時はユーザーにエラーメッセージを表示する」という指示を出すと、実装の下書きがその場で生成されます。その後、エンジニアが生成されたコードをレビューし、既存の設計パターン(Data Access Layerの置き方など)に沿っているか、エラーメッセージが業務要件と一致しているかを確認・修正します。テストコードもAIに下書きさせ、境界値や異常系のケースが漏れていないかを人間が確認します。
この流れでは、人が手で書く時間が減る一方、生成されたコードを読んで確かめる時間の比重が増えます。書く作業が減った分を、既存の設計に合っているか、業務のルールどおりか、を確かめる工程に回せるようになった、というのが私たちの実感に近い変化です。
同様の変化は、既存システムの保守フェーズでも起きています。たとえばNext.js本体にセキュリティパッチが公開されたとき、パッチ適用後に主要機能が壊れていないかを確認する回帰テストは、従来であれば全画面を人間が目視で確認する必要がありました。現在は、AIエージェントに変更差分の影響範囲を洗い出させ、影響がありそうな画面から順に人間が確認するという順序に変えています。全画面を同じ重みで見るのではなく、見る順番に根拠を持たせるための使い方です。パッチ対応をどう仕組み化するかについては、Next.jsのCVE対応は誰がやるのかで詳しく解説しています。
発注側にとって何が変わるのか?
見積もり金額が単純に下がるわけではなく、同じ予算でできる範囲が広がる方向に変化が現れます。
見積もりへの影響
正直に言うと、AI ツールの導入によって見積もり金額が大幅に下がるかというと、そう単純な話ではありません。コードを書く時間が短縮される分、一部の工程は確かに効率化されています。ただし、受託開発の見積もりにはヒアリング、要件定義、設計、テスト、レビュー、ドキュメント作成など、コーディング以外の工程が多く含まれています。
むしろ私たちが意識しているのは、同じ予算でできることの幅が広がるという方向です。たとえば、これまでは予算の都合で管理画面をシンプルな一覧表示にとどめていたところを、AIによる実装の下書き速度を活かして、検索・フィルタ・CSVエクスポートまで含めた機能をご提案できるケースが増えています。
納期への影響
実装フェーズのスピードが上がることで、全体のスケジュールに多少の余裕が生まれることはあります。ただ、受託開発のスケジュールを左右する最大の要因は、多くの場合「お客様側の確認・意思決定にかかる時間」です。
私たちの実感としては、AI 導入によって手戻りが起きたときに、影響範囲を早く洗い出せるようになったことのほうが大きいです。たとえば納品直前に「この画面のレイアウトを変更したい」という要望が入った場合、どのコンポーネントとどのテストに影響するかをAIに一覧にさせ、人がその一覧を確かめてから修正に入れます。
品質への影響
AI が生成したコードをそのまま納品することはしません。私たちのフローでは、AI が生成したコードは必ず人間のエンジニアがレビューします。
テストコードの下書きをAIに任せられるようになったことで、これまで後回しになりがちだった異常系や境界値のテストまで書く余地ができました。ただし、AIが書いたテストは「何を確かめているか」を人が読んで確認しないと、通るだけのテストが混ざります。
一方で、注意すべき失敗パターンもあります。AIに大きすぎる粒度で指示を出すと、意図しない箇所まで書き換えてしまい、レビューに想定以上の時間がかかることがあります。この失敗を避けるため、私たちは1回の指示を「1つの機能・1つのファイル群」程度に区切り、都度レビューを挟むという運用にしています。役割ごとにAIを分担させる具体的な進め方は、Next.js受託開発でClaude Codeのサブエージェントをどう使う?役割分担で工数と品質を両立する設計で詳しく解説しています。
AI駆動開発をうたう開発会社に、発注前に何を確認すればいい?
「誰がどうレビューするか」「コードやデータをどの契約のAIサービスに送るか」「別の会社に引き継げる形で納品されるか」の3点は、見積もりの金額より先に確認します。
AIを使っていること自体は、品質の保証にも減点にもなりません。違いが出るのは使い方です。商談の場で聞ける形にすると、次の5つになります。
| 確認する質問 | 答えに含まれていてほしいこと |
|---|
| AIが書いたコードは、誰がどうレビューしますか? | レビューする人と、何を見るか(認証・認可、エラー時の動き、既存設計との整合)が具体的に出てくるか |
| ソースコードや業務データを、どのAIサービスにどの契約で送りますか? | 法人向けの契約かどうか。送ってはいけないデータ(個人情報など)をどう扱うか |
| テストはどこまで書き、AIが書いたテストは誰が確認しますか? | 正常系だけでなく、異常系・権限の違いを確かめるテストがあるか |
| 納品物に、AI向けの指示ファイルや設計のメモは含まれますか? | CLAUDE.md・AGENTS.md などの指示ファイルや設計の判断理由が、次に保守する人に渡るか |
| AIを使ったことは、見積もりのどこに反映されていますか? | 実装の工数と、要件整理・レビュー・テストの工数を分けて説明できるか |
2つ目の質問は、とくに確認しておきたいところです。たとえばAnthropicは、Claude Codeについて、Team・Enterpriseプランや API などの商用の契約で送られたコードやプロンプトは、利用者が自ら提供を選んだ場合を除いて生成モデルの学習に使わない、と説明しています。一方、個人向けのFree・Pro・Max・Ultraプランは、設定がオンなら学習に使われます(Claude Code Docs: Data usage、2026年11月3日確認)。同じツールでも契約によって扱いが変わるため、ツール名ではなく契約の種類で聞きます。
4つ目は、将来、保守を別の会社や社内の担当に移すときに効いてきます。AIへの指示ファイルには、そのプロジェクトのコーディング規約や、触ってはいけない箇所が書かれていることが多く、引き継ぐ側にとって設計書の代わりになるためです。保守を引き継ぐときに受け取るものの全体は、Next.jsアプリの保守引き継ぎで整理しています。
AI 駆動開発で変わらないもの
要件整理・業務理解・コードの最終責任は、AIツールを導入した後も変わらず人間の開発会社が担います。
要件整理は人間の仕事
「AI を使っているなら、要件もざっくりで大丈夫ですか?」と聞かれることがたまにあります。答えは「いいえ」です。むしろ逆で、AI にコードを書かせるためには、従来以上に要件を明確にする必要があります。
AI は曖昧な指示に対して「それっぽい」ものを作ってしまう傾向があります。だからこそ、ヒアリングと要件定義の工程はこれまでと同じか、それ以上に丁寧に行うようにしています。要件を仕様として明文化してからAIに実装させる「仕様駆動開発」の考え方については、仕様駆動開発(SDD)とは|AIの作り直しを減らす仕様の書き方でも扱っています。
業務理解の深さが品質を決める
受託開発の品質は、結局のところ「お客様の業務をどれだけ理解しているか」で決まります。AI は業務知識を持っていません。私たちゼットリンカーでは、AI ツールの導入で空いた時間を、業務理解やコミュニケーションに振り向けるよう意識しています。
コードの責任は開発会社にある
AI が書いたコードであっても、それを採用してシステムに組み込む判断をしたのは人間です。納品物の品質に対する責任は、当然ながら私たち開発会社が負います。これはNext.js本体のセキュリティパッチへの追従といった納品後の運用フェーズでも同様で、AIエージェントに一次チェックを任せつつ、最終判断とその結果への責任は人間のチームが持つという体制を維持しています。
まずは、現在依頼を検討しているシステムの要件を、箇条書きで3〜5行程度メモしてみることをおすすめします。それだけでも、AI駆動開発がどこまで効くプロジェクトかの見立てがしやすくなります。
まとめ
この記事で持ち帰れることは、AI駆動開発が「開発のどの工程を速くし、どの工程は変わらないか」の見分け方と、発注前に開発会社へ確認する5つの質問です。
Claude Code や Cursor といった AI ツールは、受託開発の「手を動かす」部分を短くします。ただし、それは「考える」工程——要件整理、業務理解、設計判断——の重要性が下がったことを意味しません。私たちゼットリンカーは、AI を道具として使いこなしながら、お客様の業務課題に向き合うことを開発の軸に据えています。AI 時代の受託開発で大切なのは、ツールの新しさではなく、それを扱うチームの誠実さと技術力です。
Next.js×AIエージェントによる業務自動化の全体像は、【2026年版】Next.js × AIエージェントで業務を自動化する実務ガイドで解説しています。あわせてご覧ください。
また、設計・実装・レビューといった役割ごとにClaude Codeを分担させる進め方は、Next.js受託開発でClaude Codeのサブエージェントをどう使う?役割分担で工数と品質を両立する設計で詳しく解説しています。
AI駆動開発を前提にした開発の進め方について、事例や要件が固まっていない段階でも構いません。15分のカジュアル相談(営業目的ではなく、状況整理を目的とした対話)からお受けしています。
本記事はNext.js 16.x時点の情報です。(2026年10月13日更新:発注前に開発会社へ確認する質問の章を追加し、AIサービスの学習利用に関する記述を公式ドキュメントで確認しました)
技術仕様・対象バージョンは本文と参照先をご確認ください。
最終更新:2026年11月3日