よくあるつまずきQ&A
情報この章の要点
「Mac/Windowsどちらでもいい？」「費用は？」「会社PCで試していい？」など、自作アプリ開発でつまずきやすい12の疑問に、そのままAIに投げられる依頼文例つきで答えます。自分が書いていないコードを動かす不安の解消法、エラーが直らない時の脱出ルート、公開後に定期確認すべき点、挫折しない完成基準まで扱います。
Q. Mac・Windowsどちらでも自作アプリは作れますか？
基本的にはどちらでも問題ありません。AIコーディングエージェント（Claude Code等）は、Mac・Windowsのどちらにも対応しています。
多少の違いはターミナル（文字で指示を打ち込む画面）の操作感やインストール手順にありますが、いずれも公式の導入手順に沿って進めれば迷うことはありません。細かい違いに悩むより、まずは自分が普段使っているパソコンでそのまま始めてしまってかまいません。わからないことがあれば、その都度AIに聞いてみましょう。
Q. 何を最初にインストールすればいいですか？
いきなり全部揃えようとしないでください。開発環境とデプロイで紹介している通り、最初の一歩は「GAS＋スプレッドシート」がおすすめです。
GAS（Google Apps Script）はブラウザ上で完結するため、パソコンに何かをインストールする必要がありません。 Googleアカウントさえあれば、その日のうちに最初の自動化を試せます。
AIコーディングエージェントを使った本格的な開発（開発環境とデプロイの「ローカル実行」以降）に進みたくなったら、そのときに必要なツールをAIに聞きながら1つずつ入れていけば十分です。「まず何が要るか一覧で教えて」とAI自身に尋ねるのも良い方法です。
Q. 費用はどれくらいかかりますか？
「無料でどこまでできるか」を意識して段階を踏めば、費用を心配しすぎる必要はありません。
- AIコーディングエージェントの多くは、無料の範囲でも基本的な機能を試せます
- GASの段階は完全に無料です
- デプロイ先（Vercel・Netlifyなど）も、個人利用の小規模なアプリであれば無料枠で足りることが多いです
費用が発生しやすいのは、外部サービスと連携する部分や、常時稼働させる自動化の部分です。ここは「本当に必要になってから検討する」で十分間に合います。無料の範囲で1つ動くものを作ってみて、そこから先を考えても遅くありません。
Q. 会社のPCで試しても大丈夫ですか？
個人の学習目的であっても、会社のPCを使う場合は、まず自社のセキュリティポリシー（会社が定めている情報の取り扱いルール）を確認してください。インストールできるソフトに制限がかかっていたり、外部サービスへのアクセスが制限されていたりすることがあります。
個人のPCで試せる環境があるなら、まずはそちらで慣れてから、会社での利用について改めて相談するほうが安全です。情報システム部門がある会社なら、本格的に使い始める前に一声かけておくと、後々のトラブルを避けられます。組織として本格的に導入する話になったら、権限を最小に絞るで扱っている考え方が参考になります。
Q. 自分が書いたわけじゃないコードを動かすのは怖くありませんか？
プログラミングは怖くないでも触れた通り、変更履歴を戻せる仕組み（Git/GitHub）があるおかげで、「壊れても取り返しがつく」状態を作れます。まずはこの安心材料を思い出してください。
そのうえで、動かす前にAIにコードの説明をさせるという一手間を挟むと、不安はさらに減ります。「危ない操作がないか」だけでなく、次の4点を合わせて確認すると、検収の抜けが減ります。
| 確認すること | 見るポイント |
|---|---|
| 危険な操作 | 外部への送信・ファイルの削除や上書きが含まれていないか |
| 想定外の入力 | 空欄・異常な数値・想定外の文字列を渡したときに、エラーで止まらず変な動きをしないか |
| 外部ライブラリ | 使っているライブラリが有名・更新が続いているものか（聞いたことのないライブラリは要注意） |
| 重要な数字・ロジック | 金額計算や件数集計など、結果が業務に直結する部分は、AIの説明だけで終わらせず自分でも1件手計算して照合したか |
例コードレビューを頼む依頼文
「このコードが何をしているか、プログラミング初心者にもわかるように説明してください。①外部にデータを送信している箇所、②ファイルを削除・上書きしている箇所、③使っている外部ライブラリの名前と、それぞれの一般的な信頼度、④空欄や異常な値を渡したときにどう動くか、の4点を必ず教えてください。」
自分で1行ずつ読み解けなくても、この4点をAIに確認させるだけで、安心して一歩を踏み出せます。金額や件数など、結果が仕事に直結する部分だけは、AIの説明を鵜呑みにせず、自分の手でも一度検算してください（スプレッドシートの「検算するまでが制作」と同じ考え方です）。
Q. 作ったアプリを誰かに見られたり、勝手に使われたりしませんか？
ローカル環境（自分のパソコンの中だけで動かしている状態）にとどまっている間は、他の人がアクセスすることはありません。開発環境とデプロイの「ローカル実行」の段階では、外部から見られる心配は基本的に不要です。
不安が出てくるのは「デプロイ」以降、つまり外部に公開する段階です。公開範囲を「自分だけ」に絞る設定や、アクセスにパスワードを求める設定など、公開先のサービスにはたいてい制限機能が用意されています。「誰でも見られる状態」と「自分だけが見られる状態」のどちらにするか、公開する前に必ず確認する習慣をつけてください。
Q. どのくらいの時間で1つ作れるようになりますか？
個人差はありますが、目安としては最初の1つは数時間から数日、慣れれば数十分という感覚です。時間がかかるかどうかは、機能の複雑さと、要件をどれだけ具体的に言葉にできているかで大きく変わります。
大事なのは、業務アプリ（バイブコーディング）総論で触れているYAGNI（今すぐ要らない機能は作らない、という考え方）です。完璧を目指さず、まず動くものを1つ見ることを目標にしてください。機能を盛り込むほど時間がかかるのは当然なので、最初は小さく作ることが、結果的に一番の近道になります。
Q. 作ったアプリのメンテナンスは、自分にできますか？
保守も含めて、AIと一緒に進める前提で考えて大丈夫です。業務アプリ（バイブコーディング）総論でも触れている通り、自作したアプリは「作って終わり」ではなく、仕様変更やAI本体の進化に合わせて手を入れ続けるものです。
不具合が出たときの直し方は、本章の「エラーメッセージが出たときの対処」と同じです。「ここがうまく動かなくなりました」と状況を伝えれば、AIが原因を探して直してくれます。自分一人でコードを1行ずつ読み解いて保守する必要はありません。
Q. 公開したあと、何を定期的に確認すればいいですか？
「作って公開して終わり」にすると、数か月後には誰も触れない古いアプリになりがちです。デプロイ後は、次の4点を定期的に（月1回が目安です）確認する習慣をつけてください。
| 確認すること | 見るポイント |
|---|---|
| 動いているか | 実際にアクセスして、主要な機能が今も正常に動くか自分の目で触って確かめる |
| エラーが出ていないか | デプロイ先（Vercel等）の管理画面でエラーログを確認する |
| 外部サービスの仕様変更 | 連携しているAPI・外部サービスの仕様変更で、突然動かなくなっていないか |
| 依存パッケージの古さ | 使っているライブラリに重大な脆弱性の指摘がないか（「このプロジェクトで使っているライブラリに、セキュリティ上の問題が報告されているものはないか確認してください」とAIに聞くだけでも一次チェックになります） |
ヒント💡 自分がいなくなっても困らない準備
個人で作ったアプリほど、「作った本人しか直せない」状態になりがちです。誰かに引き継ぐ可能性が少しでもあるなら、「①何のためのアプリか、②どこにコードがあるか、③困ったときに誰（何）に聞けばいいか」の3行だけでも、README（プロジェクトの説明書きファイル）として残しておいてください。AIに「このプロジェクトの引き継ぎ書を、非エンジニアにもわかるように3行でまとめて」と頼めば、たたき台はすぐ作れます。
保守や引き継ぎも、業務アプリ（バイブコーディング）総論で触れた「作って終わりではなく、育て続けるもの」という前提の一部です。
Q. 途中で挫折しそうです。どこまでやれば「できた」と言えますか？
業務アプリ（バイブコーディング）総論の「まず動くものを見たい、それで十分です」という考え方を、もう一度思い出してください。
完成の基準は、思っているよりずっと低くて構いません。次のどれかに当てはまれば、それは十分「できた」です。
- 一部の作業だけでも、手作業よりラクになった
- 動くところまでは確認できた（見た目が粗くても構いません）
- エラーに1回でも自力で対処できた
完璧な完成品を目指すから挫折するのです。 小さな「できた」を積み重ねる感覚に切り替えるだけで、続けやすさは大きく変わります。
Q. エラーメッセージが出たときは、どう対処すればいいですか？
見慣れない英語のエラー画面が出ても、自分で読み解こうとする必要はありません。エラーメッセージを丸ごとコピーして、AIにそのまま貼り付けるのが一番の近道です。
例エラー時の指示
「このエラーが出ました。直してください。 [エラーメッセージを貼り付け]」
これだけでAIが原因を特定してくれます。もし1回で直らない場合は、①何を作っているか（状況）、②直前に何をしたか（やったこと）、③本来どうなってほしかったか（期待した結果） を追加で伝えると、解決のスピードが上がります。 エラーは失敗ではなく、直すための「ヒント」です。
Q. 何度直してもエラーが解消されない（ループする）時はどうすればいいですか？
同じエラーが何度も続くときは、以下の「脱出ルート」を試してください。
- 別のアプローチを聞く：「別のやり方はありますか？」とAIに聞いてみる
- 前の状態に戻す：うまく動いていた時点まで巻き戻す（セーブポイントの作り方は GitとGitHub 参照）
- 要件を小さくする：機能を一度に盛り込もうとせず、まずはシンプルな状態で動かす
逆にやってはいけないのは、「原因がわからないまま闇雲にコードを書き換えること」と「バックアップを取らずに大改造すること」、そして「新しいチャット（会話）で最初からやり直すこと」です。文脈が失われて同じやり取りがループしてしまいます。
AIへの具体的な依頼文例集
ここでは、よくある疑問や困りごとに対して、AIにそのまま使える具体的な依頼文例をまとめています。状況に合わせて〔 〕内の情報を書き換え、AIに活用してください。
例インストールで迷ったとき
「Macを使っていて、これからAIコーディングエージェントで簡単なアプリを作り始めたいです。最初にインストールすべきものを、初心者向けに手順で教えてください。」
例費用感を確認したいとき
「これから紹介する用途で自作アプリを作った場合、無料の範囲で収まりそうか、費用が発生しそうな箇所があるとすればどこか教えてください。用途：〔例：週次の売上データをスプレッドシートで自動集計したい〕」
例動かす前の安全確認をしたいとき
「このコードを実行する前に、外部への送信・ファイルの削除や上書きなど、注意すべき操作が含まれていないか確認してください。〔コードを貼る〕」
例公開範囲を確認したいとき
「このアプリをデプロイする前に、公開範囲を『自分だけ』に絞る方法はありますか。第三者に見られたくありません。」
例保守を頼みたいとき
「このアプリの、以前作った部分が最近エラーを出すようになりました。原因を調べて、直してもらえますか。」
例「できた」の基準に迷ったとき
「今の状態は、最初に決めた〔やりたいこと〕に対してどこまで近づいていますか。完璧でなくてもいいので、今日はここまでで一区切りにしたいです。次に手を付けるべき最優先の1点だけ教えてください。」
いずれも、専門知識がなくてもそのまま貼り付けて使える文面です。迷ったときは、まずこの中から近いものを探し、自分の状況に合わせて〔 〕の部分だけ書き換えて使ってみてください。