経営会議で「AIアプリを作れ」という号令が出ました。持ち帰って企画を書こうとした担当者が、最初の1行で止まります。AIアプリとは、そもそも何を指すのか。社内で3人に聞けば3通りの答えが返ってくるからです。
ある人はChatGPTのような対話型サービスを想像し、別の人は自社の業務システムにAI機能を足すことを考え、また別の人は「AIに作らせたアプリ」だと解釈している。この定義のずれを放置したまま予算を確保すると、完成したものが誰の期待にも一致しません。
この記事では、AIアプリという言葉が指す2つの異なる対象を切り分け、それぞれの仕組みと作り方を整理します。
混乱の原因は、この言葉が構造の異なる2つの意味で使われていることにあります。どちらを指しているかで、必要な技術も予算の桁も変わります。
ひとつめは、アプリの中でAIが動くものです。問い合わせに自動で答えるチャット、長文の議事録を要約する機能、入力された内容を分類して振り分ける処理などが該当します。利用者が使うたびにAIが呼び出される構造です。
この意味で使うなら、論点は「どのAIモデルを、どの業務のどこで呼ぶか」になります。そして呼ぶたびに費用が発生するため、利用量の見積もりが企画の中心になります。
もうひとつは、開発の過程でAIを使うものです。自然言語で「こういう画面が欲しい」と指示すると、AIがコードを生成します。完成したアプリ自体はAIを使わない、ただの業務アプリということもあります。
この意味で使うなら、論点は開発の速度とコストです。Collins Dictionaryが2025年のWord of the Yearに選んだ「vibe coding」は、まさにこちらを指す言葉です。IBMやGoogle Cloudの解説でも、2025年2月にAndrej Karpathy氏が提唱した用語として整理されています。
実務では、この2つは重なります。AIで作ったアプリにAI機能を組み込む、という組み合わせが最も多いためです。学術的な整理でも、この開発手法は人が選択的・戦略的な監督を維持することを条件として位置づけられています。企画書では「AIで作る」のか「AIが動く」のか、あるいは両方なのかを最初に明記してください。それだけで議論の空転が減ります。
仕組みを理解しておくと、費用とリスクの見積もりが具体的になります。難しい話ではありません。
利用者がアプリで何かを操作すると、アプリはそのデータをAIモデルに送り、返ってきた結果を画面に表示します。モデルは自社で持つのではなく、外部の事業者が提供するものを呼び出すのが一般的です。つまりアプリとAIの間には、必ず通信とAPIの呼び出しがあります。
ここから3つの実務的な帰結が出ます。第一に、呼び出すたびに費用が発生します。第二に、送ったデータが外部に渡るため、何を送ってよいかの判断が必要です。第三に、モデル側の障害や仕様変更の影響を受けます。企画段階でこの3点に触れていない資料は、情報システム部門の審査で必ず差し戻されます。
ツールによっては、この呼び出し部分が最初から用意されています。たとえばLovableの公式ドキュメントによれば、組み込みのAIコネクタを使うことで、APIキーの取得や事業者ごとのセットアップなしに、チャットボット、要約、画像生成といった機能をアプリに追加できるとされています。
抽象的な事例集より、自社に当てはめやすい型で整理したほうが実用的です。多くの企業で最初に着手されるのは、次の4類型のいずれかです。
いずれも共通しているのは、既存の業務がすでに存在し、そこにかかっている時間が測れることです。ゼロから新しい業務を作るより、成果を数値で示しやすくなります。
| 類型 | 具体例 | 効果の測り方 |
|---|---|---|
| 要約・整形 | 議事録の要約、問い合わせ内容の分類、報告書の下書き生成 | 1件あたりの処理時間×月間件数 |
| 検索・参照 | 社内規程やマニュアルへの自然言語での問い合わせ | 問い合わせ対応の削減件数 |
| 入力支援 | 紙・PDFからの転記、選択肢の自動提案 | 入力ミスの発生率と手戻り件数 |
| 下書き生成 | 提案書・メール文面・商品説明文の初稿作成 | 初稿作成までのリードタイム |
この表で最も見落とされるのが、右列です。効果の測り方を先に決めていないと、導入後に「便利になった気がする」で終わります。着手前に現状の数値を測っておくことが、次の予算を取る唯一の材料になります。
作り方には大きく3つの経路があります。優劣ではなく、対象業務の性質で選び分けるものです。
第一が、外部の開発会社に発注する方法です。要件が固まっていて、規模が大きく、可用性の要求が高い場合に適します。一方で、要件が固まる前に発注すると、仕様変更のたびに費用が増えます。
第二が、既製のSaaSを導入する方法です。汎用的な業務であれば最も速く、保守も不要です。ただし自社固有の業務プロセスには合わないことが多く、「使われないツール」になるリスクがあります。
第三が、内製する方法です。自然言語でアプリを生成するツールを使う経路です。ここ数年で現実味が増したのは、この選択肢です。自然言語でアプリを生成できるツールが実用水準に達し、非エンジニアでも部門内の業務アプリなら作れるようになったためです。
日本企業にとって内製の重要度が上がっている背景には、人材の需給があります。経済産業省の「IT人材需給に関する調査」では、IT需要の伸び方によっては2030年に最大で約79万人のIT人材が不足すると試算されており、関連する経済産業省の資料でも継続的な論点として扱われています。外注で埋めようにも、外注先も同じ市場から人を採っています。
ここでは第三の経路を具体化します。手順そのものは4段階で、難しいのは工程ではなく最初の言語化です。
第一段階は、対象業務と保持するデータの定義です。誰のどの業務を、どう変えるのか。そしてアプリが持つ項目とその選択肢は何か。公式のプロンプト・ベストプラクティスが「曖昧なアイデアは曖昧な出力を生む」と述べるとおり、ここの粗さがそのまま成果物の粗さになります。
第二段階が生成です。画面構成、データ構造、制約（配色・UI言語・変更してよい範囲）を指示します。第三段階が反復で、1メッセージ1変更に絞るのが原則です。大きな判断は、コードを書かずに計画を提示させるPlan modeで先に固めます。
第四段階が公開前の点検です。ここは自動化に任せきれません。認証していない訪問者に何が見えるか、他人のデータが見えないか、管理者専用の操作が一般利用者に開いていないか。公開時に自動実行される検査は設定や依存関係の問題を拾いますが、「誰に見せてよいか」という業務判断は人が行います。
「AIを組み込む」と書いたとき、実際に何が呼ばれるのかを説明できないと、情報システム部門の審査で止まります。モデルの提供元と種類は、データの送り先そのものだからです。
Lovableの公式ドキュメントによれば、アプリのAI機能ではOpenAIのGPT-5.6系のモデルが利用でき、チャットとテキストの用途では、難度の高い推論やコーディング向けのGPT-5.6 Solと、高速・大量処理向けのGPT-5.6 Lunaが選べます。音声機能にはGoogleのGeminiの音声合成モデルが利用できるとされています。
実務上の意味は2つあります。ひとつは、用途に応じてモデルを選ぶことでコストと速度のバランスを取れること。すべてを最上位モデルで処理する必要はありません。もうひとつは、送信先が特定の事業者になるため、そのことを社内の規程と突き合わせる必要があることです。
また、APIキーの取得や事業者ごとのセットアップが不要な構成になっている点も、実務では効きます。鍵の管理をアプリ側で行わずに済むため、鍵をフロントエンドに置いてしまうという典型的な事故を構造的に避けられます。他の外部サービスとの接続についても、鍵をどこに置くかは同じ観点で確認してください。
技術的な実現性で否決される企画は、実はそれほど多くありません。止まる理由は別のところにあります。
最も多いのが、対象業務が特定されていないことです。「営業を効率化する」ではなく「見積書の作成に月40時間かかっているので、下書き生成で半減させる」まで具体化されているか。前者は反論しようがなく、同時に承認もできません。
次が、効果の測り方が書かれていないことです。導入後に何がどれだけ変わったら成功なのか。現状の数値を測っていなければ、そもそも比較できません。着手前の実測が、実は企画書で最も重要な材料です。
三つめが、データの扱いに触れていないことです。何を送るのか、それは学習に使われるのか、誰が見られるのか。この3点に一次情報で答えられない企画は、情報システム部門で必ず差し戻されます。逆にいえば、この3点を先に押さえておけば審査は速く進みます。セキュリティに関する公開情報やトラストセンターを根拠資料として添えてください。
企画書で最も突っ込まれるのがここです。定額ではないため、構造を説明できないと予算が承認されません。
費用は大きく2つに分かれます。アプリを作るためのコストと、アプリが動き続けるためのコストです。後者はさらに、ホスティングやデータベースの稼働分と、AI機能の呼び出し分に分かれます。
Lovableの場合、この3つはBuild usage、Cloud usage、AI gateway usageとして区別され、いずれもクレジットを消費します。AI gateway usageは、公開済みアプリのAI機能がモデルを呼び出したときに計測され、アプリの構築を支援するエージェントの消費とは別勘定です。
監視の手段も用意されています。公式ドキュメントによれば、Cloud内のAIダッシュボードでプロジェクト単位にAI機能を監視・デバッグでき、個々のリクエストのステータス、実行時間、使用モデル、トークン使用量、コストを確認できます。プロジェクト単位の利用状況と合わせて見れば、企画時の見積もりを実測で更新していけます。
実務的な進め方は単純です。試験導入で1機能を作り、想定利用者と同じ立場の人に1週間使ってもらい、そのAI呼び出しコストを記録する。この実測値に利用者数を掛けるほうが、どんな見積もり式より説得力があります。
技術より先に決めるべき論点が3つあります。ここを空欄にしたまま進めると、完成後に情報システム部門で止まります。
第一が、AIに送ってよいデータの範囲です。顧客の個人情報、契約条件、未公開の経営情報。何を送ってよく、何を送ってはいけないかを業務側で定義してください。ツールによっては、入力したデータがモデルの学習に使われるかどうかがプランで異なります。Lovableの公式ドキュメントによれば、2026年9月9日以降、FreeプランとProプランの顧客データは学習に利用される可能性があり個別にオプトアウトでき、BusinessプランとEnterpriseプランのワークスペースデータは契約にもとづき既定で学習対象外です。
第二が、権限設計です。誰がどのデータを見られるか。AI機能があると、通常の画面では見えないはずのデータが要約や検索の結果として漏れることがあります。データそのものだけでなく、AIの出力経路も権限の対象だと考えてください。
第三が、保守の担い手です。作った人が異動した後、誰が面倒を見るのか。これを決めずに配ると、半年後には誰も中身を説明できないアプリが業務に組み込まれた状態になります。
企画書には両面を書いてください。片側だけの資料は、反対意見に一撃で崩されます。
| 観点 | メリット | デメリット・留意点 |
|---|---|---|
| 速度 | 要件確定と並行して動くものを出せる | 速いぶん、検討不足のまま本番化しやすい |
| 費用 | 小規模な社内ツールの外注費と待ち時間を圧縮できる | 従量課金のため、利用量に応じて変動する |
| 業務適合 | 業務を知る人が直接形にできる | 属人化しやすく、保守設計が必須 |
| データ | 自社のデータ資産を活かせる | 送信範囲と学習利用の可否を先に決める必要がある |
| 品質 | 実物を見ながら改善できる | 権限設計など、見た目に現れない欠陥を見落としやすい |
この表で最も過小評価されるのが最下段です。画面が正しく表示されることは、権限設計が正しいことを何ら保証しません。公開前の確認を工程として組み込んでください。
SaaSは提供事業者が定義した機能を使うもの、AIアプリ（内製）は自社の業務に合わせて作るものです。汎用業務ならSaaS、自社固有の業務ならアプリ、という切り分けが実務的です。
部門内で完結する業務アプリであれば作れます。ただし公開前の権限確認は別のスキルであり、確認できる人が組織内に必要です。作る人と点検する人を分けてください。
紙やExcelで回っていて、扱うデータの機微性が低く、かかっている時間を測れる業務です。申請書の入力、点検記録、簡易な集計ダッシュボードが典型です。
その指摘は正当です。Lovableの利用規約にも、AIの出力には誤りや不正確さが含まれる可能性があり、独立した検証なしに依拠すべきでないと明記されています。用途を「人が確認する前提の下書き生成」に限定すれば、この懸念の大半は解消します。
金額ではなく工数で示すのが確実です。対象業務に月何時間かかっていたかを事前に測り、導入後の実測と比較してください。IPAが2026年7月に公表した国内企業のDX・AI活用動向でも、AI導入は広がる一方で価値創出への発展が課題とされています。
技術的には可能ですが、審査の水準が変わります。外部公開するものは権限設計のレビューを必須にし、公開の承認者を明示してください。認証していない訪問者に何が見えるかの確認は必ず人が行います。
ID管理（SSO・自動プロビジョニング）、安全性の点検、そして棚卸しの3点です。個人アカウントのまま人数だけ増やすと、把握できないアプリが増えます。組織向けの統制機能を前提に設計してください。
AIアプリという言葉は、AIを機能として組み込んだアプリと、AIを使って作られたアプリの2つを指します。企画書の最初に、どちらを指すのか（あるいは両方か）を明記するだけで、社内の議論は噛み合い始めます。
作り方は外注・既製SaaS・内製の3経路で、対象業務の性質で選び分けます。内製の手順は、業務とデータの定義、生成、1メッセージ1変更での反復、公開前の点検の4段階です。費用は作るコストと動かし続けるコストに分かれ、AI機能の呼び出しは後者として利用量に比例します。
そして技術より先に決めるべきは、AIに送ってよいデータの範囲、権限設計、保守の担い手の3点です。この3つを空欄にしたまま作り始めることが、最も高くつく進め方になります。
自然言語でのアプリ開発の全体像はLovableとは？できること・料金・使い方を日本公式パートナーが徹底解説を、内製の進め方や体制設計のご相談は株式会社100の問い合わせ窓口をご利用ください。