作る前に、作るべきか判断する
この章は、AIをコーディングパートナーにして自分専用のソフトウェアを開発する『バイブコーディング』（細かい仕様書ではなく、AIとの対話で"感覚（vibe）"を伝えながら形にする開発手法）について解説します。AIでつくるの中でも最も難易度が高く、最後に開く位置づけです。
スライド・画像・動画・文書などの制作は、チャット製品の機能（AI基礎の範囲）でもかなりのことができます。この章が扱うのはその先——既製ツールにない、自分専用のアプリや自動化を組みたくなったときの話です。『作れる』ことと『作るべき』ことは別であり、本当に作る必要があるのかを見極めることがこの章の核心です。
なぜ「つくる」体験が効くのか
体系の多くは、「まずデータ・ナレッジを整えてから」と語りたくなります。ですが、これは遠回りになりやすいのです。
実際に手が動くのは、目の前の面倒な業務を、AIと一緒にコードを書いて自動化してみることからです。技術が手に届く範囲に降りてきた今、非エンジニアでも自分専用のツールが作れるようになりました。
1. なぜ今、非エンジニアでも「作れる」のか
Claude Code（AIと会話しながらコードを書けるツール）のようなAIコーディングエージェントが登場し、「動くソフトウェアを書く」ことの敷居が大きく下がりました。
プロンプト（AIへの指示文のこと）で要件を伝え、AIが実装し、動かして確かめ、直す。このサイクルを回せれば、プログラミング経験がなくても自分専用の業務ツールを組み立てられます。
「作れるかどうか」は、もう差別化になりません。 誰でも作れる時代だからこそ、何を作り・何を作らないかを判断する力のほうが価値を持ちます。
2. 作らない選択がデフォルト
AIの進化で「作れる」範囲が広がったからといって、何でも自作するのが最善とは限りません。既存のAIチャットやSaaS（ネット経由で利用できるソフトウェアサービス）で要件が満たせるなら、無理に自作しないのが賢明な選択です。
メモ✏️ 用語メモ：YAGNI
"You Aren't Gonna Need It"（それは多分要らない）の略です。ソフトウェア開発の世界で昔からある考え方で、「今すぐ必要でない機能は作るな」という戒めを表します。本章ではこれを「作らないがデフォルト」という判断軸として使います。
これは「足りなければ作る」の裏返しで、「足りているなら作るな」という戒めでもあります。
自作には目に見えないコストがついて回ります。保守し続けなければ動かなくなりますし、仕様変更のたびに手を入れる必要も出てきます。
何より、AIの世界は陳腐化が早いものです。今日苦労して組んだ仕組みが、半年後にはAI本体の標準機能に飲み込まれていることも普通に起きます。既製ツールなら、この荷物を全部メーカーが持ってくれます。
迷ったら既製で済ませる、が出発点です。
3. 作るべきか否か——4つの閾値
デフォルトが「作らない」なら、何が作る判断を後押しするのでしょうか。境目は、次の4つに集約されます。
| 閾値 | 内容 |
|---|---|
| ①既製ツールの限界 | 「あと一歩、ここだけ自分の業務に合わせたい」が既製の設定では届かない。その一歩が業務の核心に関わるとき |
| ②反復頻度 | 一度きりなら手でやればいい。毎週・毎日繰り返すなら、その手間の総和が自作コストを超えていく |
| ③データ主権・機密 | クライアントの情報や自社の判断基準を、外部サービスに丸ごと預けたくない場面。手元で完結させる必要があるとき |
| ④長期コスト | 月額課金の積み上げと、作って保守する手間。時間軸を長くとって試算し、自作が下回るなら検討に値する |
つまり、これら4つの閾値のいずれにも当てはまらない場合、無理に自作するメリットは少ないと言えます。「作れるから」という動機だけで開発を進めるのは、最もリスクが高いアプローチです。
ヒント💡 候補が複数あるときの選び方
「何を作るか」の候補が複数あって迷うなら、どの業務から始めるかの頻度×負荷×リスクで選ぶロジックがそのまま使えます。あちらは組織の業務選定として書いていますが、個人の1本目のアプリ選びにも同じ考え方が効きます。
4. 価値あるツールの作り方
- 要件を言葉にする：何に困っていて、何ができれば十分かを言葉にします。完璧な仕様書は要りません。まず動くものを見たい、それで十分です
- AIに実装させ、動かして確かめる：一度で完成を求めません。小さく動くものを出し、触って直していきます。これはプロンプトのコツ（生成AI編総論）の延長でもあります
- 繰り返し使う中で育てる：実際に使いながら「ここが使いづらい」「もっとこうしたい」といった改善点を見つけ、都度修正・改善を重ねていきます。最初から完璧を目指さず、小さく育てていくのが成功の秘訣です。
- 土台と自分の工夫を分けて考える：Claude等のプラットフォーム（借りている土台）と、自分がその上に組んだ業務の工夫（プロンプトやツールの使い方）は別物です。土台は日々進化していきますが、自分の工夫はその上に乗っているだけ、と捉えておくと後々ラクになります
5. 継続的な価値を保つために
- 一度作ったら終わりではありません。仕様変更・AI本体の進化に合わせて、手を入れ続ける前提を持ちましょう
- 今日作り上げた仕組みも、いずれは陳腐化し、役目を終える時が来るかもしれません。その際に躊躇なく「捨てる」判断ができるよう、過度な作り込みは避け、常に身軽さを保つことを意識しましょう。
- 「何がしたいか」はAIの世界が変わっても使い続けられますが、「今使っているツールでどう実装したか」はそのツールが変わると古くなります。この2つを頭の片隅で分けておくと、乗り換えが必要になったときに慌てません
6. 開発を始める前に
- これは本当に自作が要るでしょうか。既製ツールの組み合わせで足りないか、確認してみましょう
- 上の4つの閾値（限界・反復・主権・コスト）のどれかに、はっきり当てはまっているでしょうか
- 作ったあと、保守し続けられるでしょうか。古くなったとき、気持ちよく捨てられるでしょうか
例依頼文の実例（作るべきか一緒に判断してもらう）
「私は〔業種・立場〕をしていて、〔今困っている作業〕に毎回〔頻度・時間〕かかっています。今は〔使っている既製ツール・やり方〕で対応していますが、〔足りない点〕があります。この作業を自分専用のツールとして作るべきか、それとも既製のやり方のまま続けるべきか、次の4つの観点から一緒に判断してください。①既製ツールの限界はどこにあるか ②この作業はどのくらいの頻度で発生するか ③顧客情報や自社の判断基準を外部に預けたくない要素はあるか ④長期的に見て自作と既製、どちらのコストが低いか。」
この依頼文を投げると、AIが4つの観点それぞれについて質問を返してくることもあります。1回で結論が出なくてもかまいません。やり取りしながら「作る/作らない」の判断材料を一緒に揃えていく、という使い方が実務的です。
バイブコーディングを深掘りする各章
| 章 | 中身 |
|---|---|
| プログラミングは怖くない | 「自分には無理」と思ってしまう理由／ターミナルとエラーの実態／壊れても大丈夫な理由／最初の成功体験の作り方 |
| 開発環境とデプロイ | 開発環境の5段階（Canvas→GAS＋スプレッドシート→ローカルWebアプリ→デプロイ→DB連携）／API連携／GitHubの要否 |
| GitとGitHub | Git・GitHubとは何か／なぜAIと作るときほど必要か／セーブポイントを作る習慣／コマンドを覚えなくていい理由 |
| よくあるつまずきQ&A | OS・インストール・費用・会社PCでの利用・安全性・完成の基準・エラー対応などの初歩的な疑問 |
| 事例集 | GAS、Chrome拡張機能、ダッシュボード、チャットボット、Discord botのユースケースと開発時の注意点 |
バイブコーディング学習ロードマップ
プログラミングに不安があるなら、プログラミングは怖くないから読んでみてください。コード・ターミナル・エラーへの心理的な壁を、手を動かす前に取り除けます。
作る判断をしたら、開発環境とデプロイでどの環境から始めるかを選びます。手を動かす前に、GitとGitHubで「いつでも前に戻せる」安心材料を持っておいてください。エラー時の対処や、環境構築・費用・安全性についての疑問が浮かんだら よくあるつまずきQ&A を参照してください。また、具体的にどんなものが作れるか実例やユースケースを見たいときは 事例集 を参考にしてください。
次なるステップ：仕組み化とコンテキスト
1つの独自アプリが「思ったより楽になった」と感じたら、次の欲求は2方向に分かれます。
アプリの中でAIをもっと自律的に動かしたいならAIエージェント（スキル・エージェント化）へ進んでください。もっと自分の状況を分かった上で答えてほしいならコンテキスト（データ・ナレッジ・メモリ）へ進んでください。
法人向け展開：組織でのAI活用へ
個人の1業務向けアプリが育ってきたら、法人としてどの業務から着手するかを選ぶ段階に進みます。
これは組織活用に収録しています。どの業務から始めるか（組織活用総論）を参照してください。