AI駆動開発で受託案件のデリバリー・保守をして感じたこと

TL;DR

• 小・中規模の受託開発は今後儲かるのか？
• 受託の保守、AIで割とやれちゃう
• 人月モデルの開発は今後キツくない？
• LLMフレンドリーなプロジェクト構成にする価値

プロジェクト概要、受託開発ビジネスについて

2024年11月から2025年4月にかけて、AIをフル活用して小・中規模の開発案件のデリバリーと保守をしました。2024年10月から2025年2月にかけてメイン開発を行い、それ以降は保守フェーズに移行しています。この過程で感じたことを備忘録として書いていきます。

結論、受託開発ビジネスはCursorなどの登場以前と以後で大きく変わるでしょう。すでに変わってしまったかもしれませんが。
案件をこなした身からすると、同じ単価感で人月商売をすると、実装が以前より早く終わるため、利幅が減り大変になると感じました。

使用したLLM、技術スタック

技術スタックは、モバイルアプリにReact Native/Expo（iOS/Android両対応）、バックエンドはNode.js。開発過程では、主にCursorを活用してコーディングを行いました。

Cursor上では主に以下のLLMを活用しました。

開発フェーズ（〜2025年2月）

• Claude Sonnet 3.5（メイン）
• GPT-4o / o1（Sonnetで対応困難な場合に補完的に使用）

保守フェーズ（2025年2月〜）

• Claude Sonnet 4
• Claude Opus 4
• Gemini 2.5 Pro

Cursorを活用することで開発速度が大幅に向上しました。

AI駆動開発で苦労した部分、効率化できた部分

UIの実装は大変

特にモバイルのフロントエンドの実装において、LLMでうまくできる部分が少なく、しんどい思いをしました。

Figma上の理想のUIと、開発環境の現行UI、それぞれのスクリーンショットを与えても、LLMの差分判定が全然ダメ。

UIの実装に関して、80%くらいはLLMでいけることが多かったんですが、残りの20%を埋めるために人間の手で実装する必要がありました。Playwright MCPでビジュアルのフィードバックをLLM自身に取得させる、というやり方もありますが、現状のマルチモーダルLLMの画像理解度が人間には遠く及ばず、フィードバックループが回らないという印象です。

バックエンド、インフラはCursorが大車輪の活躍で超効率化

逆にバックエンドについては、コンテキストの与え方次第ですが、実装したい内容をポン出しに近い形で出してきました。
小規模・中規模のソフトウェアであれば、かなりの程度LLMでいけるなと。

インフラ構築においては、以下のワークフローで効率的に作業を進められました：

1. Cursorのエージェントモードを利用し、AWSのGUIなどで構築したリソースのコード化を依頼
2. aws-cliのコマンドを都度確認して実行、取得したデータをもとにTerraformのコードに落とし込ませる
3. 人間がレビュー

インフラはCLIを介して多くの情報にアクセスできるため、AI駆動開発と非常に相性が良いです。terraform planなどのコマンドで、定義されたコードと実環境の差分判定が容易なため、CursorやClaude Codeがフィードバックループを自身で完結させられます。

保守フェーズについて

メインの開発が2025年1月末に完了し、その後は保守・追加開発フェーズに移行しました。

保守期間中に以下の新しいLLMがリリースされ、実践で：

• OpenAI Codex（2025年5月16日）
• Anthropic Claude 4（2025年5月22日）
• Claude Code（Claude 4ベースにアップデート）

クライアントから受けた要望をそのままCodexやClaude Codeに投げることで、100%まではいかないにしろ、5~8割程度のものを出してくれます。それをベースに、少し手直しを加えれば完成します。

稼働時間で請求をする場合、請求する金額が小さくなります。儲かりません。

AI駆動開発で効率化できたこと

羅列する概念の粒度がバラバラですが、以下の分野において特にAI駆動開発の恩恵を受けました：

• フロントエンドの約80%までの開発
• インフラのコード化
• バックエンドのAPI作成
• バックエンドのユニットテスト作成
• 運営用の管理画面（admin画面）の開発
• 保守・運用における細かい変更や修正
• 仕様書や関連ドキュメントの作成

すでにある程度参考にすべきコードが存在する局面では、LLMが強いですね。

人月モデルのビジネスの未来

受託開発の保守フェーズをやってみて思いましたが、このAI時代、全く割に合わないわ、というのが正直な感想です。

稼働に応じて請求をしていたのですが、AIで早く実装できるので売上が減り、しかも単位時間あたりに実装する機能の量は増えます。体感ではより忙しくなり、脳の疲労感は増す一方。

価値転換の時代？時間ベースから成果物ベースに？

受託開発業では人月 or 機能単位で見積もりするのが一般的なはずですが、AIによってビジネスモデルに変化が生じていると感じます。

CursorやClaude Codeを上手く使えば従来の数分の1程度の時間で開発が可能ですが、人間にはAIが100%に仕上げられなかった部分のケツを拭くという仕事が残されています。たいていの場合、この仕事はしんどい運命にあります。

AIを使えば工数が1/3になるから、単価も1/3にするべきなのか。「AI使って早くできるんだから、安くしてよ〜」 と言ってくる顧客もいるはず。個人的な願望も含まれていますが、ここで価値の転換が起こるといいなと思います。

早くできる、というのは本来価値のはずです。

1/2の値段で受注して1/3の時間で実装する、という単位時間あたりの収益性を上げる会社は出てきていますが、業界全体としての価格感や速度感がどう向かっていくのか、まだ未知数です。

※ 要件や仕様を固める時間があるため、実装の時間が1/3になっても、単純にプロジェクトの合計時間が1/3になるわけではないです。念の為

受託開発業は生成AIで廃れるのか？

結論、わかりません（筆者には）。

ジョブ理論によれば 顧客はドリルではなくドリルの穴を求めているわけですが、ソフトウェアの受託開発・保守した結果を顧客は求めているわけで、確定申告を自分でやらずに税理士に依頼するのと変わらないのかなと。

マーケティング、営業、開発、法務、税務など色々職能はありますが、全部自社で行う必要はないはずです。適材適所、現実的な価格で専門性をアウトソースすることができるのであれば、それが望ましいはず。

とはいえ、ソフトウェアの保守のあり方は変わっていくのは間違いないでしょう。

自分の脳の中にとどめて置けるプロジェクト数は限られており、脳のリソース確保のために、プロジェクトを脳の外にダンプしたいです。しかし、人間の工数が完全に0にならない限り、開発・保守のスケールは限界があります。DevinなどのAIエージェントツールは、人間の代わりになる可能性を秘めていますが。

AIがほぼ自動でソフトウェアをメンテできるようになっても、事故る可能性は理論上0にはならないはずで、人間のセーフティーネットは必要です。

日本刀を打つ職人はいなくなっても困りませんが、このアナロジーはソフトウェアエンジニアには適用できません。

ソフトウェアエンジニアがいなくなった世界、AIが修復できないバグが埋め込まれ、世界が阿鼻叫喚に陥る、というシナリオのSFを考えると、ソフトウェアエンジニアが淘汰されることはないとわかるはずです。

LLMフレンドリーなプロジェクト構成にすることの価値

あえて僕がわざわざ言うべくもないことですが、プロジェクトをLLMフレンドリーにすることの重要性は日に日に増しています。

ドキュメントをマークダウンで書いてプロジェクトに突っ込む、あるいは、wikiを参照できるMCPサーバーなどの仕組みを整える、など。

例えば、本記事はCursor上で執筆され、zenn-cliを介してzennに公開されます。
記事を書く度に、Cursorが参照できるコンテキストが増えていきます。十分な文章量があれば、僕の文体を真似て書くこともできるでしょう。
ファクトチェックをしたい場合は、Cursor上でLLMを呼び出せます。サンプルコードの生成も可能。

自社プロダクトの開発では、無限に工夫できることがあるなと思います。
例えば、以下のような使い方がパッと思いつきます：

• コードを参考にQ&A記事を自動で生成する
• 定期的にDBのスキーマを参照して、PdMや社内の非エンジニア向けにプロダクトの説明wikiを自動生成する（DevinのDeepWiki的な）
• PdMの人がClaude Codeを使って、PRD（プロダクト要求仕様書）の壁打ちができるような環境づくり
• 社内の人間がバグレポートを上げやすい環境づくり、そしてそれをClaude CodeやCodexで一次実装させる仕組み
• 過去のプルリクのレビューを吸い上げ、CLAUDE.mdなどに継続的に反映させる仕組み
• Claude Code Actionで一次レビューを行う
• 新しいエンジニアが入ってきた時に、人間に聞かなくても勝手に疑問を解決できるようなリポジトリ・ドキュメント整備
• Slack上の開発チームへの質問をLLMに一次対応させる
• ブラウザ操作AIエージェント（OpenAIのOperatorなど）で、管理画面の操作を行う

人間エンジニアが持っているコンテキストを、いかにLLMからアクセス可能な状態にするかが極めて重要です。
正しいコンテキストを与えたいですが、大規模プロジェクト、レガシーなプロジェクトであればあるほど、そのコンテキストを与えるのがとにかく面倒。逆に考えると、LLM周りのエコシステムには、まだまだ進化の余地があるなと。

おわりに

2025年の後半にかけて、強化学習がスケールされていくはずですが、では実際にそれでどれぐらいプログラミングの性能が上がるのか、体験してみないとわかりません。

今後のLLMの進化が楽しみです。