記事一覧に戻る
開発

開発会社はAIをどこまで使っているのか|安くなるのは開発まで、変わったのは品質

2026年9月4日 約5分で読めます
この記事の結論

AIを使っても開発費は安くなりません。安くなるのは開発工程までで、保守・運用やセキュリティ、規模の大きい領域では効きません。代わりに変わったのは品質です。数十万円規模の案件でもテストを全部書けるようになりました。

「AIを使っているなら、その分安くなりますよね」。開発の相談で実際に聞かれる質問です。この記事は、FUNBREWが自分たちの現場でAIをどこまで使っているか、それが発注する側に何を返しているのかを、正直に書いたものです。宣伝として「AIで安く早く」と言うつもりはありません。むしろ、安くなる部分と、ならない部分の線をはっきりさせることが、発注側にとっていちばん役に立つと考えています。

開発現場でAIをどこまで使っているのか

結論から言えば、コーディングからサーバーの調査、ドキュメントの作成まで、あらゆる工程で使っています。特定の作業だけに限定して使っているわけではありません。

いちばん効いているのは、引き継ぎ案件の調査

他社が作ったシステムを引き継ぐとき、開発者は当時の開発者・開発会社・使われていた技術・そのときの顧客の状況までを想像しながら調査する必要があります。細部から入るのではなく、全体像の把握から入ることが多い仕事です。

ここで難しいのは、顧客自身も全体像をうまく説明できないことがままあるという点です。長く使われてきたシステムほど、経緯を知る人が社内に残っていません。そこで、AIで軽く調査して仮説を立てたうえで、「実は当時、こういう事件があったのではないですか」と顧客に聞いてみます。すると、顧客側にも記憶が戻り、会話をしながらプロジェクトの輪郭が見えてくる——という進め方をしています。

引き継ぎ調査の最難関は技術ではなく、「その機能が何のために使われているか」という業務側の理解で、これは聞かないと分かりません。AIは、その質問を作るところで効いています。実際の調査で何を見て判断しているかは手を入れるより作り直した方が早いと判断するとき、顧客側から何が出てくるかはシステム引き継ぎで用意する資料は何かに書いています。

人の手が残っているところ

AIを使っても、人の手が必要な仕事は多く残っています。顧客の業務のヒアリング、日本固有の事情の考慮といった部分です。

ここで起きた変化は「その仕事もAIに任せられるようになった」ではありません。コーディングなどの作業が早くなった分を、顧客とのやりとりに充てられるようになった、という変化です。時間の再配分であって、代替ではない、というのが実感に近い説明です。

AIを使うと開発費は安くなるのか

率直に言えば、安くなるのは開発工程までです。ここから先は、ほとんど効きません。

安くならない領域

  • 保守・運用 —— 動き続けるものを見守る仕事は、書く速度が上がっても総量が減りません。
  • セキュリティ —— 想定外の使われ方を洗い出す作業は、人が把握しておく必要が残ります。
  • 規模が大きくなったとき —— システム全体の整合性を保つ部分が難所になります。

規模が大きくなると何が起きるか

AIを使って自分たちで作ってみる、という選択肢は、以前より現実的になりました。小さく作って動かすところまでは、実際に到達できます。難しくなるのはその先で、機能が増えるほど全体の整合性が合わなくなり、直しては壊れるという往復が起きやすくなります。どこを直すと何に影響するかを見通す部分は経験が要る領域で、開発会社の側に分があるのはここです。

これは「だから開発会社に頼むべき」という話ではありません。どこまでは自分たちでやれて、どこから難しくなるのかという線を知っておくと、外注する範囲を賢く決められます。

本当に変わったのは、費用ではなく品質

費用が下がらないのなら、何が変わったのか。品質は大きく向上したと自信を持って言えます。

数十万円の案件でも、テストを全部書けるようになった

従来、小規模な案件ではテストコードを書く工数が予算に収まらず、手動確認で済ませる判断をせざるを得ない場面がありました。現在は、数十万円規模の案件であってもテストを全部書けます。発注する側から見た利益は、値引きではなくこちらです。納品後に想定外の壊れ方をする確率が下がる、という形で返ってきます。

品質と責任は、どこで担保しているか

観点判断基準
品質顧客に見せて、実際に使えるかどうか
責任セキュリティ部分のテストカバレッジと、想定外の使われ方をされないかを、人間の側でも把握しておくこと

AIが出したものをそのまま納品する、ということはありません。特に責任の面では、最終的に人が把握していることが条件になります。

「AI活用」を謳う会社を、発注側はどう見ればよいか

これから発注先を選ぶ方に向けて、ひとつだけ視点をお伝えします。AIを使っていること自体は、もう差別化の材料になりません。

見るべきは「AIを使っているか」ではなく「何を解決するか」

現在は汎用のAIモデルで多くのことができるため、少し知識があれば「AIを使った製品」というだけでは特別なことをしている証明になりません。開発会社がAIを使っているのは今後の主流であり、当たり前の状態に近づいています。

したがって、提案を評価するときは「AIを活用しています」という言葉ではなく、自社のどの課題が、どう解決されるのかで見てください。相談の段階で何を伝えると話が早いかは、開発の相談メールに何を書けば話が早いかにまとめています。

「AIで安くなりませんか」と聞かれたら、正直に「開発工程は効率化できますが、保守や運用は変わりません」とお答えしています。値引きの根拠にはならない代わりに、同じ予算で書けるテストの量は増えました。安さではなく、壊れにくさで返ってくる変化だと考えてください。

まとめ

FUNBREWでは、コーディング、サーバー調査、ドキュメント作成まであらゆる工程でAIを使っています。特に引き継ぎ案件では、軽く調査して仮説を立て、それを顧客にぶつけて記憶を引き出すという使い方が効いています。

一方で、AIを使っても費用は安くなりません。安くなるのは開発工程までで、保守・運用やセキュリティ、規模の大きい領域には効きません。代わりに品質が上がり、数十万円規模の案件でもテストを全部書けるようになりました。発注する側にとっての利益は、値引きではなく、納品後の壊れにくさです。

どこまでを自社でやり、どこから任せるか。その線引きの相談からお受けしています。お問い合わせよりご連絡ください。

よくある質問
AIを使っている開発会社なら、費用は安くなりますか。
安くなるのは開発工程までです。保守・運用やセキュリティ、規模が大きくなって全体の整合性を保つ領域では効きません。費用ではなく品質の向上として返ってくる、と考えていただくのが実態に近いです。
AIによって具体的に何が良くなったのですか。
品質です。従来はテストを書く工数が予算に収まらなかった数十万円規模の案件でも、テストを全部書けるようになりました。納品後に想定外の壊れ方をする確率が下がるという形で発注側に返ります。
AIが書いたコードの品質と責任はどう担保していますか。
品質は「顧客に見せて実際に使えるかどうか」で判断しています。責任の面では、セキュリティ部分のテストカバレッジと、想定外の使われ方をされないかを人間の側でも把握しておくことを条件にしています。
AIを使えば自社でシステムを作れますか。
小さく作って動かすところまでは現実的になりました。難しくなるのはその先で、機能が増えるほど全体の整合性が合わなくなり、直しては壊れる往復が起きやすくなります。どこまで自社でやり、どこから任せるかの線を決めておくことをおすすめします。
「AI活用」を掲げる開発会社は選ぶ基準になりますか。
AIを使っていること自体は、もう差別化の材料になりません。汎用のAIモデルで多くのことができるようになったためです。見るべきはAIを使っているかどうかではなく、自社のどの課題がどう解決されるのかです。

この記事をシェア

どこまで自社でやり、どこから任せるかのご相談

範囲の線引きから一緒に整理します。まだ内容が固まっていない段階でも構いません。

この記事に関連するサービス

お困りごとのご相談は無料です。まずは状況をお聞かせください。

最新情報をお届けします

IT活用のヒントやお役立ち情報を定期的にお届けします。

あわせて読みたい

「発注・準備」に関連する記事です。

まとめ記事

システム開発の流れを完全解説|発注から納品までの全工程

小規模なシステム開発で契約書は必要か|数万円〜30万円の依頼で実際に取り交わしているものと、揉める本当の原因

2026年9月4日

システム開発で「これは追加費用です」と言われるのはどこからか|開発会社の判断軸

2026年9月4日

システム開発の相談メールには何を書けばいいか|開発会社が最初に見ている3つのこと

2026年9月4日

基本設計書の読み方・確認ポイント|発注者が承認前に必ずチェックすべき項目【2026年版】

2026年5月4日

IT補助金採択後の進め方ガイド|交付決定から実績報告・精算まで失敗しない手順

2026年3月22日

ニアショア開発会社の選び方|4拠点比較・費用相場・10項目チェックリスト

2026年3月8日

ベトナムオフショア開発|費用・品質・日本語対応を現場目線で解説

2026年3月8日

システム開発のプロジェクト管理|発注者がやるべきことと成功のコツ

2026年3月7日

システム開発の契約形態|請負と準委任の違いをわかりやすく解説

2026年3月7日

システム開発のテスト工程|発注者が知るべき受入テストの進め方

2026年3月7日

受託開発の完全ガイド|費用・流れ・選び方・成功のポイントを総まとめ

2026年3月3日

開発会社とのコミュニケーション術|プロジェクトを成功に導く伝え方

2026年3月3日

内製 vs 外注どっちが正解?システム開発の判断フレームワーク

2026年3月3日

システム開発で失敗する原因TOP5と防ぎ方

2026年3月2日
まとめ記事

システム開発の流れを完全解説|発注から納品までの全工程

2026年3月2日

API連携とは?費用相場・失敗しない依頼方法・開発会社の選び方を発注者向けに解説

2026年3月1日

要件定義のやり方|システム開発を成功させる最初のステップ

2026年3月1日

プロトタイプ開発とは?メリット・費用・進め方をわかりやすく解説【2026年版】

2026年3月1日

【2026年版】RFP(提案依頼書)の書き方ガイド|失敗しないシステム開発の発注準備

2026年3月1日

失敗しないシステム開発会社の選び方|5つのチェックポイント【2026年版】

2026年3月1日

関連記事

開発
2026年9月4日

小規模なシステム開発で契約書は必要か|数万円〜30万円の依頼で実際に取り交わしているものと、揉める本当の原因

数万円〜30万円規模の開発依頼で実際に何を取り交わしているのか。契約書が無くても揉めなかった条件と、食い違いが起きる本当の原因である「開発の範囲」について、開発会社側の実務から書きました。

システム開発
2026年9月4日

システム開発で「これは追加費用です」と言われるのはどこからか|開発会社の判断軸

開発が始まってから要望が増えたとき、どこから追加費用になるのかを、開発会社が実際に見ている判断軸から解説します。画面と機能リストという2つの基準と、予算が小さいほど融通が利かなくなる理由をまとめました。

システム開発
2026年9月4日

システム開発の相談メールには何を書けばいいか|開発会社が最初に見ている3つのこと

システム開発の相談メールや問い合わせで何を書けば話が早いのかを、開発会社が実際に確認している予算・納期・機能の3点から解説します。予算を伝えた方がよい理由と、決まっていない段階での相談の仕方もまとめました。

システム開発
2026年5月4日

基本設計書の読み方・確認ポイント|発注者が承認前に必ずチェックすべき項目【2026年版】

開発会社から提出された基本設計書の見方がわからない発注者向けに、承認前に必ずチェックすべき7項目を解説。「よくわからないまま承認して後悔した」を防ぐ実務ガイド。

相談のハードル、下げました

まずは気軽にご相談ください

「まだ具体的に決まっていない」「とりあえず話を聞きたい」でも大丈夫。プロトタイプを見ながら、一緒にアイデアを形にしていきましょう。

相談無料 オンライン対応 1週間でプロトタイプ