AIアプリ開発の進め方・費用・会社選び｜7ステップと発注前チェックリスト【2026年版】

「AIでアプリを作りたい。だが、何から始めて、いくらかかり、どこに頼めばいいのか分からない」——2026年現在、経営企画やDX推進の部門から最も多く寄せられるのがこの相談です。

状況が読みにくいのには理由があります。この1〜2年で、AIアプリ開発の前提が実際に変わったからです。従来は「作れる人がいるかどうか」がボトルネックでしたが、いまは「何を作るべきかを決められるかどうか」がボトルネックになりました。にもかかわらず、発注側の進め方も、受注側の見積もり方も、多くが従来のままです。

本記事では、公的データと実務の両面から、AIアプリ開発の進め方・費用の決まり方・発注先の選び方を整理します。「相場はいくら」といった単純な数字を提示するのではなく、その数字が何で決まるのかを分解します。そのほうが、実際の意思決定に使えるからです。

「AIアプリ開発」とは何を指しているのか？

2つの意味を混同していないか？

最初に整理すべき点です。この言葉は、まったく異なる2つのものを指して使われています。

社内で「AIアプリを作りたい」という話が出たとき、どちらを指しているのかを最初に確認してください。①のつもりで話す人と②のつもりで聞く人が同席していると、要件定義が空転します。実際には両方を組み合わせるケース（AIで開発し、AI機能も載せる）が増えており、その場合は費用構造も両方が乗ります。

なぜいま、内製という選択肢が現実的になったのか？

背景には人材の需給があります。経済産業省の「IT人材需給に関する調査」（2019年）は、2030年時点で最大約79万人のIT人材不足を推計しています。経済産業省「DXレポート」（2018年）が警告した「2025年の崖」と合わせて、「外注先を探せば解決する」という前提そのものが成り立ちにくくなっているのが現状です。

ここに、自然言語からアプリを生成できるツール（Lovableなど）が実用域に入ってきました。結果として、これまで「予算が付かないから作らなかった」小さな業務アプリが、内製で成立するようになった——これが構造変化の中身です。

ただし誤解しないでください。大規模基幹システムの置き換えが内製でできるようになったわけではありません。変わったのは、費用対効果が合わずに放置されていた領域の経済性です。

従来の受託開発と何が変わったのか？

「AIで開発が速くなった」という説明は、変化の一部しか捉えていません。実際に変わったのはボトルネックの位置です。作れる人を確保することが難しかった時代から、何を作るべきかを決めることが難しい時代に移りました。この変化は、発注側の準備の仕方そのものを変えます。

3行目が重要です。従来、事業部門が作った試作は「動くけれど捨てるもの」でした。現在の主要ツールは実コードを生成し、GitHubと同期できるため、試作をエンジニアが引き取って本番化する受け渡しが、作り直しなしで成立します。これが進め方を根本から変えます。

AIアプリ開発はどう進めるのか？——7ステップ

STEP1〜2：課題定義とスコープ確定

STEP1：解決する業務課題を1つに絞る
「AIを活用したい」は課題ではありません。「見積作成に1件あたり2時間かかっている」が課題です。効果測定の単位（時間・件数・金額）まで書けない課題は、まだ課題になっていません。

STEP2：作らないものを決める
スコープ確定とは、作るものを決めることではなく作らないものを決めることです。ここを曖昧にしたまま進めた案件は、ほぼ例外なく費用が膨らみます。最初のバージョンには、認証・権限・外部連携を入れないのが定石です。

STEP3〜4：プロトタイプと検証

STEP3：2週間以内に動くものを作る
資料ではなく動くものを作ります。この段階の目的は完成ではなく、「認識のズレを表面化させること」です。画面を見た瞬間に「そうじゃない」が出るのは成功であって失敗ではありません。

STEP4：実際の業務データで検証する
ダミーデータでの検証は意味がありません。実データを入れた瞬間に、想定外の表記ゆれ・欠損・例外パターンが噴出します。ここで出た問題こそが、本番化の要件です。

STEP5〜7：本番化・セキュリティ点検・定着

STEP5：本番運用に必要な要件を足す
認証、権限設計、エラー処理、ログ、バックアップ。ここからエンジニアの関与が必要になります。

STEP6：公開前にセキュリティを点検する
最頻出の事故は、データベースのアクセス制御（行レベルセキュリティ）の設定漏れです。設定していなくてもアプリは正常に動くため、通常のテストでは発見できません。点検手順は公開前チェックリストにまとめています。OWASP Top 10やIPA「安全なウェブサイトの作り方」の観点でのレビューも組み込んでください。

STEP7：使われる状態にする
最も軽視され、最も失敗する工程です。動くアプリを作っても、現場が従来のExcelを使い続ければ投資はゼロになります。「作る」ではなく「切り替える」ことがゴールだと定義し直してください。

費用はどう決まるのか？

費用は3層に分かれる

見積書を1つの数字として見ると判断を誤ります。実際には性質の違う3層で構成されています。

見積もりで抜けやすいのは②と③です。とくに②は「作って終わり」の想定で予算化され、翌年度に予算がなくて止まる——という事故が起きます。AIアプリの場合、推論の呼び出しは使われるほど費用が増えるため、成功するほどコストが上がる構造になります。稟議では必ず運用費を恒久予算として計上してください。

なぜ「相場」を鵜呑みにしてはいけないのか？

「業務アプリ開発の相場は◯◯万円」という情報は多数ありますが、意思決定には使えません。同じ「在庫管理アプリ」でも、要件次第で工数が桁違いになるからです。

IPAの「ソフトウェア開発分析データ集2022」は、5,546プロジェクトの定量データをもとに工数・工期・規模・生産性・信頼性を分析しており、直近6年分1,479件からベンチマークを算出しています。ここから読み取るべきは個別の金額ではなく、「同種のプロジェクトでも工数には大きな幅がある」という事実そのものです。

したがって、相場感は次のように使ってください。

• ×「相場が◯◯万円だから、この見積もりは高い」
• ○「この見積もりは何の要件で工数が積み上がっているのか。その要件は本当に初回から必要か」

内製と外注のコスト比較はどう作るのか？

比較表を作る際、多くの企業が「開発費」だけを並べて内製が安いと結論づけます。これは誤りです。公正な比較には次の項目が必要です。

正しい問いは「どちらが安いか」ではなく、「どの部分を内製し、どの部分を外注するか」です。現実的な切り分けは、要件が固まりにくい探索フェーズを内製、品質保証と継続性が求められる本番運用を外注（または共同）とする形です。

発注先はどう選ぶべきか？

見積書のどこを見るべきか？

金額の大小より、内訳の構造を見てください。確認すべきは12項目です。

危険なサインは何か？

次のいずれかに該当する場合、発注前に立ち止まってください。

• ヒアリングの前に見積もりが出てくる——要件を聞かずに金額を出せるのは、中身を決めていないからです
• 「何でも作れます」と言う——作れるかではなく、作るべきかを一緒に考える相手が必要です
• スコープ外の記載がない——後から追加費用が発生する典型パターンです
• 運用費の説明がない——3層構造の②が抜けています
• セキュリティを「対応済み」の一言で済ませる——何をどう点検するかを説明できない相手は危険です
• 「AIで作るので安く速い」だけを訴求する——安さの根拠が実装工数の削減だけなら、①以外の費用は減りません

良いパートナーの条件は何か？

1つに絞るなら、「要件を削る提案をしてくるか」です。

受注側にとって、要件を削ることは受注金額を下げることを意味します。それでも「この機能は初回から必要ですか」「これは既存ツールの標準機能で足りませんか」と言える相手は、プロジェクトの成功を自社の売上より優先しているということです。この一点は、他のどの評価項目よりも予測力があります。

加えて、社内の合意形成を支援できるかも重要です。IPA「DX白書」が繰り返し指摘するとおり、DXの阻害要因は技術よりも組織側にあります（IPA「DX動向2024」も同様に人材・組織面の課題を指摘しています）。実装だけを請け負う相手より、部門間の調整と定着まで担える相手のほうが、結果的に投資対効果は高くなります。

どのツール・技術を使うのが適切か？

選択肢は大きく3系統に分かれる

ツールの比較を個別製品から始めると、比較軸が製品ごとにばらついて結論が出ません。まず系統に分け、自社の要件がどの系統に当たるかを決めてから、系統内で製品を比べてください。2026年時点では次の3系統に整理できます。

比較検討でよくある誤りは、この3系統を同じ土俵で比べることです。「kintoneとLovableはどちらが安いか」という問いは、「電車とレンタカーはどちらが安いか」と同じ構造をしています。行き先と人数を決めなければ答えは出ません。

既存のライセンスを持っている場合はどう考えるか？

すでにMicrosoft 365やkintoneを全社導入している企業では、まず既存基盤で作れないかを検証するのが原則です。追加コストがゼロに近く、情シスの審査も通っているためです。

それでも新しい選択肢を検討する価値があるのは、次のケースです。既存基盤の制約で作れない画面がある、非エンジニアが自力で完成まで到達できない、外部公開が必要——このいずれかに該当するとき。「新しいから使う」ではなく「既存で詰まったから使う」という順序を守ってください。この順序を守れる企業は、情シスとの関係も良好に保てます。

AI機能を組み込む場合、モデルはどう選ぶか？

アプリ内でAIを呼び出す場合、AnthropicやOpenAIなどのAPIを利用します。選定軸は精度だけではありません。①用途に対する精度、②入出力トークン単価、③応答速度、④データの取り扱い（学習利用の有無）の4点で評価してください。

とくに④は情シス審査の焦点になります。入力データが学習に使われない契約になっているかを、必ず書面で確認してください。個人データを扱う場合は個人情報保護委員会のガイドラインも参照が必要です。

契約形態は請負と準委任のどちらが適切か？

2つの契約形態は何が違うのか？

AIアプリ開発で費用が想定を超える原因の多くは、見積もりの甘さではなく契約形態の選択ミスにあります。要件が固まっていない案件を、成果物の完成を約束する契約で発注すると、要件が動くたびに手続きが必要になります。まず両者の違いを整理します。

AIアプリ開発で失敗が起きやすいのは、要件が固まっていない案件を請負契約で発注したときです。要件が動くたびに変更契約が必要になり、費用も期間も膨らみます。IPAが公開している「情報システム・モデル取引・契約書」でも、工程の性質に応じた契約形態の使い分けが示されています。

実務ではどう組み合わせるべきか？

現実的な構成は「探索フェーズは準委任、本番構築は請負」です。何を作るかが決まっていない段階では準委任で伴走し、スコープが確定した時点で請負に切り替える。この二段構えにすると、双方のリスクが最小になります。

逆に言えば、要件が固まっていないのに一括請負の見積もりを出してくる相手には注意が必要です。金額に不確実性分のバッファが乗っているか、後から変更費用が発生するかのいずれかだからです。

よくある失敗パターンは何か？

ここまでの内容を、実際に起きている失敗の形で整理します。並べると分かるとおり、失敗の大半は着手前と公開後に集中しており、開発中の工程はほとんど出てきません。開発が速くなったぶん、前後の工程の重要性が相対的に上がったということです。

最後の行が、中長期で最も高くつきます。市民開発を統制なしに広げると、数年後には保守されないアプリが積み上がります。DXレポートが警告した既存システムのブラックボックス化と、構造はまったく同じです。

稟議はどう通すべきか？

AIアプリ開発の稟議が止まる理由は、金額の大きさではなく効果の説明が曖昧なことです。次の3点をセットで用意してください。

1. 削減の根拠を実測値で示す——「見積作成が1件2時間×月40件＝月80時間」のように、現状を数値で押さえる。推定ではなく計測する
2. 比較対象を外注費と機会損失に置く——「新しいツールの追加コスト」として提案すると既存ツールとの重複を問われます。外注した場合の費用と期間を並べてください
3. やめたときに何が起きるかを先に開示する——公開済みのものがどうなるか、データとコードは自社に残るか。この非対称性を先に説明することが信頼につながります

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして100社以上のCRM導入・活用を支援し、Lovableの日本公式パートナーとしてAIアプリの内製化支援も行っています。上流の要件整理、社内の合意形成、CRMとの連携設計、定着までを一貫してご支援します。

よくある質問（FAQ）

Q1. AIアプリ開発の費用はいくらですか？

要件次第で大きく変わるため、単一の相場を示すことはできません。費用は①開発費・②運用費・③統制コストの3層で構成され、見積もりで抜けやすいのは②と③です。相場表の数字を基準にするより、「何の要件で工数が積み上がっているか」を確認してください。

Q2. どれくらいの期間で作れますか？

動くプロトタイプは2週間以内が目安です。ただし本番運用に耐える状態にするまでの期間は、認証・権限・既存システム連携の有無で大きく変わります。プロトタイプの速さを本番化の速さと混同しないでください。

Q3. 内製と外注はどちらがよいですか？

二択で考えないでください。要件が固まりにくい探索フェーズは内製、品質保証と継続性が求められる本番運用は外注または共同、という切り分けが現実的です。内製比較では社内担当者の人件費を必ず計上してください。

Q4. 非エンジニアだけで作れますか？

小規模な社内ツールやLPは可能です。ただし本番運用・社外公開・機密データを扱う場合は、権限設計とセキュリティ点検を検証できる人のレビューが必須です。ここを省略した事例が、最も重大な事故につながっています。

Q5. 発注先を選ぶとき、最初に何を見るべきですか？

「要件を削る提案をしてくるか」です。要件を削ることは受注金額を下げることを意味するため、それでも提案できる相手は、自社の売上よりプロジェクトの成功を優先していると判断できます。

Q6. 見積もりが会社によって大きく違うのはなぜですか？

前提としているスコープが違うためです。とくに要件整理の工数、スコープ外の定義、運用費の扱いで差が出ます。金額を比較する前に、3社の「やらないこと」の記載を比較してください。

Q7. 作ったアプリのソースコードは自社のものになりますか？

契約次第です。見積書・契約書で著作権の帰属と利用範囲を必ず確認してください。現在の主要ツールは実コードを生成しGitHubへ同期できるため、技術的には自社保有が可能です。契約上どうなっているかが論点になります。

Q8. AI機能を入れると費用はどう変わりますか？

推論の呼び出し量に応じた継続費用が発生します。モデル、入出力の量、呼び出し頻度で変動し、利用が増えるほど費用も増える構造です。「成功すると赤字になる」設計にならないよう、想定利用量から先に試算してください。

Q9. セキュリティはどこまで自社の責任ですか？

プラットフォームの安全性はベンダー、作ったアプリの権限設計と公開範囲は自社、という責任分界が一般的です。事故の大半は後者で発生します。詳細は公開前セキュリティチェックリストをご覧ください。

Q10. 情報システム部門の承認が下りません。何が原因ですか？

技術的な安全性より「誰が作って、誰が保守し、いつ止めるのか」が説明できていないケースが大半です。公開フロー・棚卸しルール・権限管理の3点を先に文書化すると、審査が速く進みます。

Q11. 小さく始めるなら、何から作るべきですか？

社内限定・読み取り中心のツールです。外部公開を伴わずリスクが低く、効果（作業時間の削減）が数値で測定できるため、次の投資の根拠になります。顧客向けのポータルなど外部公開を伴うものは、運用ルールが固まってからにしてください。

Q12. 既存の基幹システムを置き換えられますか？

現時点では現実的ではありません。変わったのは「費用対効果が合わずに放置されていた小〜中規模の業務アプリ」の経済性であって、大規模基幹システムの置き換えではありません。過大な期待を前提に稟議を組むと、後で信頼を失います。

本記事で引用した公的データは、経済産業省「IT人材需給に関する調査」（2019年）、同「DXレポート」（2018年）、IPA「ソフトウェア開発分析データ集2022」に基づきます。本記事は一般的な進め方の指針であり、個別プロジェクトの費用・期間を保証するものではありません。