AIでアプリ開発は自分でできる？非エンジニア経営者が業務アプリを作った実例

「自社専用のちょっとしたシステムがあれば便利なのに」

中小企業を経営していると、そう感じる場面は少なくありません。

Excelで何とか管理している業務、毎回同じ内容を確認しているチェック作業、入力された情報をもとに担当者が判断している診断業務、手作業で作成している報告書などです。

以前であれば、こうした仕組みをシステム化しようと思えば、まず開発会社へ相談するのが一般的でした。

ところが、ChatGPTやGemini、Claudeなどの生成AIが登場し、状況は大きく変わり始めています。

私はプログラマーではありません。

本格的なプログラミングを学んだ経験もありません。

それでもAIと対話を繰り返しながら、「入力→診断→結果表示→PDF生成→自社ドメインからメール送信→顧客データ保存→管理者画面」までをつなげた自社用の診断アプリを、一人で構築することができました。

しかし、ここで最初に伝えておきたいことがあります。

AIに「こんなアプリを作って」と頼めば、あとは勝手に完成するわけではありません。

AIは「修正しました」と言っているのに本番画面が変わらない
アプリを再デプロイしたら保存していたデータが消える
PDFを生成したら日本語が文字化けする
画面には「送信済み」と表示されるのに、実際にはメール送信機能そのものが実装されていない

これらを経験して分かったのは、AI時代のアプリ開発で最も重要なのは、「自分ですべてのコードを書ける能力」ではないということです。

重要なのは、本当に期待どおり動いているのかを、自分で確認できる能力です。

この記事では、プログラミング未経験の中小企業経営者がAIを使って業務アプリを作った実例をもとに、AIアプリ開発で何ができるのか、どこで失敗しやすいのか、そして中小企業はどこから始めればよいのかを具体的に解説します。

結論｜AIを使えば非エンジニアでも業務アプリは試作できる

結論から言えば、AIを活用することで、プログラミング未経験者でも小規模な業務アプリを試作できる可能性は大きく高まりました。

以前は、Webアプリを作るためには少なくとも、

プログラミング言語
データベース
Webサーバー
セキュリティ
クラウド
メール送信
PDF生成

などの知識をある程度理解する必要がありました。

現在は、分からないことがあれば、その場でAIに質問できます。

「このエラーは何が原因なのか」

「この処理を実現するには何が必要なのか」

「どのファイルを修正すればよいのか」

「このコードをどこへ追加すればよいのか」

こうした質問を繰り返しながら、一つずつ前へ進めることができます。

コードを書けることとアプリを作れることは同じではない

AI時代になると、「アプリを作る能力」の意味も変わってきます。

従来は、アプリを作る人とはコードを書ける人でした。

しかし現在は、自分で一からコードを書けなくても、

どのような業務を実現したいのか
誰が使うのか
何を入力するのか
どのように判断するのか
何を表示するのか
何を保存するのか
最終的に何ができれば正常なのか

をAIに説明できれば、開発を進められる場面が増えています。

つまり、必要なのは必ずしも「プログラミング能力だけ」ではありません。

業務を分解し、言葉にし、AIへ伝え、結果を確認する力が非常に重要になります。

ただし「AIに丸投げすれば完成」ではない

一方で、AIを過信するのは危険です。

AIがコードを書いたからといって、そのコードが必ず正しいとは限りません。

AIが、「修正しました」「実装しました」「これで完成です」と言ったとしても、それは実際の業務アプリが正常に動いたことを保証する言葉ではありません。

AIはプログラムを提案したり、ファイルを修正したりするところまではできます。

しかし最終的に、「本当にメールが届いたか」「データは保存されたか」「PDFは正常に開けたか」を判断するのは人間です。

ここを理解せずにAIへ丸投げすると、「見た目だけ完成したアプリ」ができる危険があります。

実際に一人で作ったのは「診断から顧客管理までつながる業務アプリ」

入力から診断結果、PDF、メール、顧客データ保存へ進む業務アプリの流れ — 今回の実例では、入力フォームだけではなく、診断、結果表示、PDF生成、メール、データ保存、管理まで一連の業務としてつなげています。

今回私が作ったのは、単純な入力フォームではありません。

利用者が情報を入力すると、その内容をもとに診断を行い、結果を画面へ表示します。

さらに、その結果をPDFとして生成し、自社ドメインのメールアドレスから利用者へ送信します。

診断データはデータベースへ保存され、管理者側から過去の診断履歴を確認できる仕組みにしました。

全体の流れは次のようになります。

入力	診断	結果表示	PDF生成	メール送信	顧客データ保存	管理者画面

この一連の流れを作っていく過程で、AIアプリ開発の面白さと難しさの両方を経験しました。

単なる診断ページではなく業務システムまで作った

最初の画面を作るだけであれば、現在のAIはかなり強力です。

「質問項目を並べてください」「ボタンを押したら結果を表示してください」と指示すれば、それらしい画面を作ることはできます。

しかし、実務で使うにはその先が必要です。

診断結果を利用者が保存できなければ不便です。そこでPDFを生成します。

PDFを生成するだけでは利用者へ届きません。そこでメール送信が必要になります。

あとから顧客へフォローしたいなら、診断履歴を保存する必要があります。

担当者が履歴を確認するなら、管理者画面も必要です。

このように実際の業務アプリでは、一つの画面を作って終わりではなく、前後の業務までつながって初めて価値が生まれます。

AIアプリ開発で使ったツールと、それぞれの役割

今回の開発では、一つのAIだけですべてを行ったわけではありません。

Google AI Studio、Claude Code、ChatGPT、Gemini、GitHub、Cloud Run、Firestore、Secret Managerなどを組み合わせました。

重要なのは、これらの名前をすべて覚えることではありません。

「アプリを作るには、いくつかの役割が必要になる」と理解することです。

ChatGPT・Gemini・Google AI Studioで仕様や画面を考える

最初の段階では、「何を作りたいのか」をAIと対話しながら整理していきます。

例えば、「利用者が10個の質問に答えると、回答内容によって3タイプに分類したい」「診断後に結果を表示したい」「結果をPDFにしたい」「管理者が履歴を見られるようにしたい」というように、やりたいことを一つずつ伝えます。

最初から完璧な仕様書を書く必要はありません。

むしろ、「こうしたい」「ここが違う」「この場合はどうすればよいか」という対話を繰り返すことで、要件そのものが明確になります。

これはAIを使った開発の大きな利点です。

Claude Codeで実際のファイルを修正する

チャット型AIにコードを書いてもらうだけでは、次第に作業が複雑になります。

コードをコピーして、自分で適切なファイルへ貼り付ける必要が出てくるからです。

複数のファイルが関係し始めると、「どこへ何を入れるのか」が分からなくなります。

そこで、実際のプロジェクト内のファイルをAIに見てもらいながら修正できる環境が役立ちます。

ここで大きく変わるのは、AIとの会話が「コードを教えてもらう」段階から、「実際の開発作業を一緒に進める」段階へ移ることです。

GitHubでプログラムを管理する

GitHubは、プログラムのファイルや変更履歴を管理する場所として使いました。

非エンジニアにとって最初は難しく見えるサービスですが、考え方自体はそれほど複雑ではありません。

「今のプログラムを保存しておく場所」「変更前の状態を残しておける場所」と考えると分かりやすいでしょう。

AIを使った開発では、修正を繰り返します。

昨日まで動いていたものが、今日の修正で動かなくなることもあります。

そのため、「どこを変更したのか」を管理できる仕組みは非常に重要です。

Cloud RunでWeb上に公開する

自分のパソコン上で動くだけでは、顧客に使ってもらうことはできません。

Webブラウザからアクセスして利用できるようにするには、アプリをインターネット上で動かす環境が必要です。

今回、その公開環境としてCloud Runを利用しました。

ここで重要なのが、「自分のパソコンで動いている状態」と「本番環境で動いている状態」は別だということです。

この違いを理解していなかったことで、後ほど説明する「AIは修正したと言うのに本番画面が変わらない」という問題が起こりました。

Firestoreで顧客・診断データを保存する

診断アプリでは、利用者が入力した情報や診断結果を後から確認できる必要があります。

そのためには、データを保存する場所が必要です。

今回、その役割としてFirestoreを利用しました。

ここで初めて、アプリ本体と顧客データは別に考えなければならない、ということを強く理解しました。

プログラムを更新しても、顧客データまで消えてはいけません。

この考え方は、実務でアプリを運用するうえで非常に重要です。

Secret Managerで重要な認証情報を管理する

外部サービスと接続したり、メールを送ったりする場合、パスワードや認証情報などの秘密情報が必要になることがあります。

こうした情報をプログラム内へそのまま書いてしまうと、安全性の問題が生じます。

そこで、秘密情報をプログラムとは別の場所で管理する考え方が必要になります。

非エンジニアがAIでアプリを作る場合でも、「動けばよい」だけでなく、こうした安全面を無視しないことが重要です。

実際には「入力画面を作る」より、その先が難しかった

AIにアプリを作ってもらうと、最初はかなり感動します。

少し指示を出しただけで、入力フォーム、ボタン、診断結果、色分け、画面レイアウトなどが表示されるからです。

ここで「もうほとんど完成した」と感じてしまいます。

しかし、実際にはそこからが本番でした。

画面が表示できても業務アプリは完成ではない

例えば、診断結果が正しく表示されても、それだけでは業務で使えません。

利用者があとから結果を見たいならPDFが必要かもしれません。

メールで結果を届けたいなら送信処理が必要です。

顧客データを残すならデータベースが必要です。

誰でも管理画面を見られては困るのであれば、管理者だけが利用できる仕組みも必要です。

このように、実務で使えるアプリにするには、「画面上で見える機能」以外の部分が非常に重要です。

裏側で動く処理は画面から見えない

特に厄介なのは、次のような処理は、画面を見ただけでは正常かどうか判断できないことです。

データ保存
PDF生成
メール送信
認証
外部サービスとの接続

画面上に、「保存しました」「送信しました」と表示させるだけなら簡単です。

しかし、本当に保存されているかはデータベースを確認しなければ分かりません。

本当にメールを送信したかは、実際の受信箱を確認しなければ分かりません。

この違いを理解することが、AIアプリ開発では非常に重要です。

失敗例1｜AIは「修正した」と言うのに本番画面が変わらない

開発中、何度も経験したのが、「AIは修正したと言っているのに、画面が変わらない」という問題でした。

こちらが不具合を伝えると、AIはコードを修正します。そして、「修正しました」と回答します。

ところが、ブラウザで本番画面を見ても何も変わっていません。

最初は、「AIの修正が間違っていたのではないか」と思いました。

しかし原因がコードそのものではないケースもあります。

コード修正と本番反映は別工程

AIが修正しているのは、手元にあるプログラムです。

一方、顧客が実際に見ているのは、本番環境に公開されているプログラムです。

つまり、コードを直すことと、直したコードを本番へ反映することは別です。

ここを理解していないと、AIとの会話では完成しているのに、実際のサービスでは何も直っていないという状況が起こります。

どのコードが今公開されているのか確認する

AIアプリ開発では、自分のパソコン上のコード、GitHubに保存されているコード、本番環境で現在動いているコードが完全に同じとは限りません。

どこか一つだけ古い状態のままということもあります。

そのため、「コードを修正したか」だけではなく、「その修正が本番まで届いているか」まで確認する必要があります。

「直したか」ではなく「本番で直ったか」を確認する

この失敗から学んだことは非常に単純です。

AIが「修正しました」と言ったことを完成条件にしてはいけません。

完成条件は、実際の本番環境を操作して、問題が解消していることです。

AIの発言ではなく、実際の結果を見る必要があります。

失敗例2｜再デプロイしたら保存していたデータが消えた

さらに大きな問題だったのが、アプリを更新した際に保存していたデータが消えたことです。

開発中は何度もアプリを変更します。

そのたびに新しいバージョンを本番へ反映します。

ところが、アプリの構成によっては、アプリ内部に保存していたデータが更新によって消える場合があります。

アプリ本体と永続データは分けて考える

これは「建物」と「保管庫」で考えると分かりやすいでしょう。

アプリ本体が建物だとします。開発中は、この建物を何度も建て替えます。

もし顧客情報を建物の中へ置いたまま建て替えてしまえば、データも一緒に消える可能性があります。

そこで、建物とは別に「消えてはいけないものを保管する場所」が必要になります。

この役割を担うのがデータベースです。

更新して消えてはいけないものを最初に決める

業務アプリを作るときは、早い段階で、「これはアプリを更新しても残り続けなければならない」というデータを整理する必要があります。

顧客情報
診断履歴
問い合わせ履歴
管理者が登録した情報
過去の報告内容

こうしたデータをどこへ保存するかを曖昧にしたまま開発を進めると、後から大きな問題になります。

失敗例3｜PDFを作ったら日本語が文字化けした

次に発生したのが、PDFの日本語文字化けです。

診断結果を画面上に表示できたため、「これをそのままPDFにすれば完成だろう」と考えました。

ところが、実際に生成されたPDFを開くと、日本語が正常に表示されませんでした。

ブラウザ表示とPDF生成は別物

ブラウザで日本語が表示されているからといって、PDFでも同じように表示されるとは限りません。

PDFを生成する仕組みでは、使用するフォントや生成方法などによって、日本語を正しく扱えないケースがあります。

非エンジニアの場合、最初からこのような問題を予測するのは難しいでしょう。

私自身も、実際にPDFを生成して初めて問題に気づきました。

完成確認は必ず実際のPDFまで開いて行う

ここでも重要なのは、「PDF生成機能を実装した」ことを完成条件にしないことです。

診断を実行する
PDFを生成する
PDFをダウンロードする
ファイルを開く
日本語が正常に表示されているか確認する
内容が診断結果と一致しているか確認する

ところまで行う必要があります。成果物そのものを確認しなければ、本当に完成したかは分かりません。

失敗例4｜画面には「送信済み」と出るのにメールが送られていなかった

画面ではメール送信済みでも実際にはメールが届いていないトラブル例 — 実際の開発では、画面上に送信済みと表示されても、メール送信処理そのものが実装されていないケースがありました。

今回の開発で最も象徴的だった失敗が、メール送信です。

診断を完了すると、画面上には、「送信しました」という趣旨の表示が出ていました。

そのため、当然メール送信処理も完成していると思っていました。

しかし、実際のメール受信箱を確認しても何も届きません。何度やっても届きません。

詳しく調べると、驚くことが分かりました。

「送信済み表示」と「メール送信処理」は別物だった

画面上に送信完了と表示する処理はあるのに、実際にメールを送信する処理そのものが実装されていなかったのです。

画面に文字を表示することと、実際にメールサーバーへデータを送り、相手へメールを届けることはまったく別の処理です。

しかし利用者から見れば、画面に「送信しました」と出れば、当然送信されたと思います。

このケースは、AIアプリ開発で非常に重要な教訓になりました。

見た目が完成していることと、裏側の処理が完成していることは同じではありません。

AIの回答ではなく実際の受信箱で確認する

メール機能の完成条件は、「メール送信コードが書かれている」ことではありません。

「送信ボタンを押した」ことでもありません。

「画面に送信済みと表示された」ことでもありません。

完成条件は、指定したメールアドレスの受信箱へ、本当に正しい内容のメールが届いたことです。

この考え方はメールだけではありません。

データ保存なら、保存先を見る。PDFなら、実際のファイルを開く。診断なら、期待した回答を入力して結果を確認する。

AIアプリ開発では、最後の成果まで確認する必要があります。

AI時代のアプリ開発で重要なのは「確認する能力」

AIの回答ではなくPDFやメールなど実際の成果を確認するイメージ — AIが「修正しました」「完成しました」と回答しても、それだけでは完成とは判断できません。実際の成果物と業務結果まで確認することが重要です。

今回の経験を通して、最も重要だと感じたことがあります。

AI時代に必要なのは、自分で全部作れる能力ではなく、本当にできているかを確認する能力です。

AIが「できました」と言っても完成とは限らない

生成AIは非常に優秀です。

しかし、人間のように実際の業務結果をすべて確認したうえで話しているとは限りません。

コードを書いたことをもって、「完成しました」と判断する場合もあります。

ファイルを修正したことをもって、「対応しました」と回答する場合もあります。

しかし業務で求めているのはコードではありません。

求めているのは、「仕事が正しく完了すること」です。

確認すべきなのはコードではなく期待した結果

非エンジニアがAI開発をするとき、「すべてのコードを読めるようにならなければならない」と考える必要はありません。

もちろん、ある程度理解できるほど安全性は高まります。

しかし、それ以上に重要なのは、正常な結果とは何かを自分で定義できることです。

例えば今回の診断アプリなら、次の状態が正常です。

入力した情報が正しく反映される
想定した診断結果が出る
PDFが正常に生成される
日本語が読める
メールが本当に届く
顧客データが保存される
再デプロイしてもデータが残る
管理者画面で履歴を確認できる

これを一つずつ確認すれば、コードをすべて理解していなくても大きな問題を発見できます。

自社業務を知っている経営者だから判断できることもある

ここは中小企業経営者にとって大きな強みです。

プログラマーはシステムに詳しくても、自社の業務を自分ほど詳しく知っているとは限りません。

「この診断結果では現場では使えない」「この情報は必ず保存しなければならない」「このメール内容では顧客が理解できない」「この順番ではスタッフが操作しづらい」といった判断は、その業務を知っている人だからできます。

AIがコードを書く時代になるほど、業務を理解していることそのものの価値が高まるとも考えられます。

自分でAIアプリ開発を始めるなら小さな業務から

では、中小企業がAIを使ってアプリ開発を試すなら、何から始めればよいのでしょうか。

おすすめは、失敗しても会社全体が止まらない、小さな業務から始めることです。

基幹システムから始めない

最初から会社全体の重要業務を動かすシステムを作るのはおすすめできません。

会計の中心部分
受発注の基幹部分
大規模な顧客データベース
全社員の勤怠管理
決済の中心処理

これらは止まった場合の影響が大きく、データやセキュリティについても慎重な設計が必要です。

まずは、業務の一部分を切り出して試します。

AIアプリを作る前に紙へ書き出したい7項目

AIへいきなり、「アプリを作ってください」と依頼するより、先に業務を整理しておいた方が開発しやすくなります。

最低限、次の7項目を書き出してみてください。

1．誰が使うか

顧客が使うのか、社員が使うのか、管理者だけが使うのかを決めます。

2．何を入力するか

氏名、選択肢、数値、文章など、必要な入力項目を整理します。

3．何を処理するか

入力後に何を判断・計算・生成するのかを決めます。

4．何を表示するか

最終的に利用者へ見せたい結果を整理します。

5．何を保存するか

入力情報、結果、日時など、後から必要になる情報を決めます。

6．誰へ何を送るか

メール送信や通知が必要なら、送信対象と内容を決めます。

7．何をもって「正常」と判断するか

ここが最も重要です。例えば、「メール送信完了画面が出る」ではなく、「指定したメールアドレスへメールが届く」と定義します。正常状態を具体的にするほど、AIとの開発は進めやすくなります。

「できた」を判断するための動作確認チェックリスト

AIでアプリを作る場合は、最後に必ず動作確認を行いましょう。

入力確認

必須項目を空欄にした場合はどうなるか
想定外の文字や数字を入力した場合はどうなるか
スマートフォンでも入力できるか
入力内容は正しく次の処理へ渡っているか

計算・診断結果確認

想定した入力で期待どおりの結果になるか
境界となる条件で結果が正しいか
表示内容と内部計算にズレがないか

PDF確認

実際にPDFを生成できるか
PDFを開けるか
日本語が文字化けしていないか
レイアウトが崩れていないか
診断結果とPDF内容が一致しているか

メール実送信確認

実際にメールが届くか
送信元が想定したアドレスになっているか
件名は正しいか
本文は正しいか
PDFなどを添付する場合は添付されているか

データ保存確認

入力した顧客情報が保存されているか
診断結果が保存されているか
同じ顧客を複数登録した場合はどうなるか
不要な情報まで保存していないか

再デプロイ後確認

アプリ更新後も過去データが残っているか
以前動いていた機能が壊れていないか
本番環境に最新修正が反映されているか

管理者画面確認

過去データを正しく確認できるか
一般利用者が管理者画面へ入れないか
必要な情報だけが表示されているか

このチェックリストを見ると分かるように、「AIがコードを書けたか」という確認項目はありません。

必要なのは、業務として正しく動いたか、です。

自分で作った試作品は、開発会社へ相談するときにも役立つ

AIを使って試作品を作ることには、もう一つ大きな価値があります。

それは、最終的に専門の開発会社へ依頼する場合でも、相談しやすくなることです。

言葉だけで説明するより「これです」が強い

開発会社へ、「診断システムを作りたいです」と伝えるだけでは、双方のイメージが一致するとは限りません。

しかし、「今、自分でここまで作ってあります」と実際に動く試作品を見せれば、次の内容を具体的に共有できます。

入力項目
画面の流れ
診断内容
PDF
管理画面
必要なデータ

完成度が低くても構いません。

言葉だけの説明より、はるかに意思疎通しやすくなります。

試作品を作ることで自分自身の要求も明確になる

実際にアプリを動かしてみると、作る前には気づかなかったことが見えてきます。

「この入力項目はいらなかった」「ここに説明文が必要だった」「管理画面ではこの順番で見たい」「PDFよりメール本文で十分だった」といったことです。

つまり試作品は、開発会社へ見せるためだけのものではありません。

自分自身が、本当に必要なシステムを理解するための道具でもあります。

自分で最後まで完成させることだけがゴールではない

AIでアプリを作るというと、「全部自分で完成させなければ意味がない」と思うかもしれません。

しかし、その必要はありません。

自分で作れるところまで作り、「この先は専門家に任せた方がよい」と判断するのも立派な活用方法です。

むしろ、何も分からない状態で相談するより、試作品を通して業務要件を理解した状態で相談した方が、話は具体的になります。

よくある質問

プログラミングを全く知らなくてもAIでアプリを作れますか？

小規模な試作品であれば、以前より取り組みやすくなっています。ただし、AIへ指示するだけですべて完成するわけではありません。入力、処理、出力、保存、動作確認などを一つずつ整理しながら進める必要があります。特に、本番運用する場合はデータ管理、認証、セキュリティなども考える必要があります。

ChatGPTだけでもアプリ開発できますか？

仕様整理、コード作成、エラー原因の調査など、多くの場面で活用できます。ただし、実際のファイル管理、本番公開、データベース、秘密情報管理などを含めたアプリでは、複数のサービスや開発環境を組み合わせる場合があります。一つのAIだけですべて完結させることを目的にするより、必要な役割ごとに適切な仕組みを使う方が現実的です。

AIが「完成しました」と言ったら信用してよいですか？

そのまま信用するのではなく、必ず実際に動かして確認することをおすすめします。例えばメール送信なら、実際の受信箱で確認します。PDFなら生成したファイルを開きます。データ保存なら保存先を確認します。「AIが完成と言ったか」ではなく、「期待した業務結果が得られたか」で判断してください。

最初にどんな業務をアプリ化するのがおすすめですか？

入力と出力が明確で、失敗しても会社全体へ大きな影響が出ない業務がおすすめです。例えば、診断ツール、社内チェックシート、見積もり支援、報告書作成などです。いきなり基幹システムから始めるより、小さな業務でAI開発の進め方を経験する方が安全です。

途中から開発会社へ相談してもよいですか？

問題ありません。むしろ、自分で試作したアプリがあることで、開発会社へ完成イメージを伝えやすくなります。自分ですべてを完成させることが目的ではなく、「何が必要なのかを理解する」ための試作としてAIを使う考え方も有効です。

まとめ｜AI時代は「全部作れる人」より「本当にできたか確認できる人」が強い

生成AIの進化によって、プログラミング未経験者でも業務アプリを作れる可能性は大きく広がりました。

実際、私は非エンジニアでありながら、入力、診断、結果表示、PDF生成、メール送信、顧客データ保存、管理者画面までつながる診断アプリを、AIを使いながら構築しました。

一方で、次のような失敗も経験しました。

修正したコードが本番へ反映されない
再デプロイでデータが消える
PDFの日本語が文字化けする
画面上は送信済みなのに、メール送信機能自体が実装されていない

この経験から強く感じるのは、AI時代に重要なのは、自分ですべてのコードを書けることではない、ということです。

これから重要になるのは、次の能力です。

自社業務を理解する
やりたいことを言語化する
AIへ具体的に伝える
小さく試作する
実際に動かして確認する
問題があれば原因を切り分ける

特に大切なのは、「本当にできているかを確認する力」です。

AIが「完成しました」と言っても、本当に完成しているとは限りません。

メールなら受信箱を見る。PDFなら開く。データなら保存先を見る。画面修正なら本番環境を見る。

この確認を積み重ねることで、非エンジニアでもAIを実務に使える可能性は大きく広がります。

中小企業が最初に挑戦するなら、大規模な基幹システムではなく、診断ツールや社内チェックシート、見積もり支援、報告書自動作成など、小さな業務から始めるのがおすすめです。

そして、途中で専門的な対応が必要になった場合は、そこで開発会社へ相談しても構いません。

自分で作った動く試作品があれば、「こういうものが欲しい」ではなく、「ここまで作ったので、これを業務で安全に使える形にしたい」という具体的な相談ができます。

AIでアプリを作る価値は、自分一人ですべて完成させられることだけではありません。

自社の業務を自分で形にし、試し、確認し、次の改善につなげられること。

そこに、AI時代の新しいアプリ開発の可能性があります。