バイブコーディングとは何か。会社をこの方法で1年回している実録

バイブコーディングの解説記事はもう十分な数があります。用語の定義、メリットとデメリット、ツール一覧。だいたい同じことが書いてあって、読み終わっても「で、これで本当に仕事が回るのか」は分からないままです。

この記事は少し立場が違います。うちの会社は約1年、この方法で実務を回してきました。Webサイト4つの構築と運用、SNSの自動投稿、社内Discordの集計bot、ブログ制作、SEOの内部対策。全部この作り方です。だから、理想論ではなく「動いているものがある側」から書きます。ついでに、あまり気持ちのいい話ではない部分も正直に書きます。

**この記事の結論：**バイブコーディングは「AIが全部やってくれる魔法」ではなく、「作るスピードが上がったぶん、判断の責任が人間に集中する開発スタイル」です。動くものはすぐできます。難しいのはその後、それを仕事で使い続けられるかどうかです。

この記事で分かること：

• バイブコーディングという言葉の意味と由来
• 普通のプログラミングと何が違うのか
• 何ができて、何ができないのか
• 向いている人と、向いていない仕事
• 実際にどう始めるか（最初の1ヶ月の順番）

1. バイブコーディングとは — 言葉の意味と由来

バイブコーディング（Vibe Coding）は、ざっくり言えばAIに自然言語で指示を出して、AIにコードを書かせる開発のやり方です。人間はコードを1行ずつ書くのではなく、「こういうものが欲しい」「ここがおかしいから直して」と伝えて、出てきたものを動かして確かめる。この繰り返しで作っていきます。

言葉としては、AI研究者のAndrej Karpathyが2025年に広めた表現として知られています。「vibe（雰囲気）に身を任せてコードを書く」というニュアンスで、コードの中身を細かく追わずに、動くかどうかで判断していく感覚を指しています。

ここで大事なのは、バイブコーディングは技術の名前ではなく、態度の名前だということです。特定のツールを使えばバイブコーディングになるわけではありません。「コードを読み込んで理解してから進める」のか、「動いたからよしとして次へ進む」のか。その姿勢の違いが呼び名の違いになっています。

だからこの言葉には、最初から少しだけ皮肉が混じっています。褒め言葉としても、批判の言葉としても使われる。そこを踏まえておくと、この後の話が入りやすいと思います。

2. 普通のプログラミングと何が違うのか

比べると輪郭がはっきりします。

ノーコードツールとの違いもよく聞かれます。ノーコードは「用意された部品の範囲でしか作れない代わりに壊れにくい」もので、バイブコーディングは「普通のコードが出てくるので何でも作れる代わりに、普通のコードと同じ壊れ方をする」ものです。自由度と責任がセットで来る、と考えると分かりやすいです。

一番大きな違いは、表の一番下の行だと思っています。従来の開発でつまずくのは「終わらない」ことでした。バイブコーディングでつまずくのは「終わったのに、後から直せない」ことです。詰まる場所が、着手時点から運用時点に移動しました。

従来のプログラミングとバイブコーディングの違いを整理しました。

3. うちが1年やってきたこと — 実際に動いているもの

抽象的な話が続いたので、実物を並べます。以下は全部、この方法で作って、いまも動いているものです。

僕はエンジニアとしてゼロから全部書ける人間ではありません。それでもこれだけのものが動いているのは、バイブコーディングという方法がそれなりに実用段階に来ているからだと思います。

ただし、AIに任せたのは実装であって、「何を作るか」と「これを世に出していいか」の判断は人間に残しています。この線引きをしていない運用は、たぶん半年もたないです。理由は6章で書きます。

あわせて読みたいClaude Codeの使い方 — 会社まるごとAIで回して分かった導入から実運用まで

4. 何ができて、何ができないか

1年やって見えてきた線引きを、そのまま出します。

「できないこと」の列は、技術的に無理という意味ではありません。やらせること自体はできてしまうけれど、事故ったときのコストが釣り合わないという意味です。ここが一番誤解されやすいところで、AIは「これは危ないのでやめましょう」とは基本的に言ってくれません。頼めば作ります。動くものが出てきます。それを見て「じゃあ本番で使おう」と決めるのは人間です。

うちの基準はシンプルで、壊れたときに自分で説明できる範囲かで切っています。社内botが止まっても謝れば済みますが、お客さんのデータを扱う部分は同じ気軽さでは触りません。

5. 向いている人・向いていない仕事

向いている人から。

• **作りたいものが具体的にある人。**バイブコーディングで一番差が出るのは、言語化の解像度です。「便利なツール」では何も出てきませんが、「毎週月曜にこのフォルダのCSVを読んで合計を出してSlackに送る」なら、その日のうちに動きます
• **自分で確かめる習慣がある人。**出てきたものを実際に動かして、期待と違えば言い直す。この往復を面倒がらない人は伸びます
• **小さい失敗を許容できる立場の人。**一人社長、社内の業務改善担当、個人開発者。ここが一番相性がいいです

向いていない仕事のほうも書きます。

• **止まると人に迷惑がかかる基幹の仕組み。**請求、決済、個人情報。ここは「動いたからOK」で進めていい領域ではありません
• **引き継ぎ前提の仕組み。**担当が変わることが決まっているものを、誰も中身を把握していない状態で作るのは、次の人への負債になります
• **すでに複雑になっている既存システムへの改修。**AIは文脈の一部しか見ていないので、局所的には正しいけれど全体では壊れる修正を平気で出してきます

一言でまとめると、バイブコーディングが向くのは「壊れても取り返しがつく領域」です。逆に言えば、その領域だけでも会社の中には意外なほど仕事が転がっています。うちが1年で作ったものは、ほとんどが「壊れても取り返しがつく」側でした。

分かれ目は「壊れても取り返しがつくか」です。

6. 正直に言っておきたい危うさ

ここを飛ばして紹介するのはフェアではないので、はっきり書きます。

一番怖いのは、自分が読めないコードが会社の中で動いている状態です。作った直後は「動いてるからいいか」で済みます。問題は3ヶ月後で、何かがおかしくなったとき、どこを直せばいいのか分からない。AIに「直して」と言っても、そもそも何が正しい状態なのかを説明できないので、直しようがありません。うちも一度、自動投稿の仕組みが静かに止まっていたのに数日気づかなかったことがあります。動かなくなったこと自体より、原因を追える人が自分しかいなかったことのほうが問題でした。

もうひとつは、品質とセキュリティです。AIが書いたコードは、それらしい形をしています。でも「それらしい」と「安全」は別です。設定ファイルに秘密の鍵が直書きされている、誰でもアクセスできる状態で公開されている。こういうものは、動作確認では絶対に見つかりません。動いてしまうからです。

**注意：**AIが書いたものを本番で動かして事故が起きたとき、責任を取るのはAIではなく、それを動かすと決めた人間です。ここは技術の話ではなく、単純に会社の話です。任せる範囲を広げるほど、確認の仕組みを先に作っておく必要があります。

うちで決めているのは、次の3つだけです。難しいことはしていません。

1. 取り返しのつかない操作は、最初から実行できないように設定でブロックする（一括削除や強制上書きの類）
2. 変更は必ず差分を見てから確定する。「直しました」を信用しない
3. **秘密の情報はコードに書かない。**専用の保管場所に置いて、そこから読む形にする

この3つを最初にやっておけば、あとは多少荒っぽく進めても致命傷にはなりにくいです。逆に、これをやらずにスピードだけ出すと、速く進んだぶんだけ深く沈みます。

7. 実際にどう始めるか — 最初の1ヶ月の順番

いきなり業務システムを作ろうとして挫折する人が多いので、うちが人に勧めている順番を書いておきます。

1. **1週目：既存のものを読ませる。**手元のフォルダやファイルの中身を説明させるところから。作らせるより先に、AIがどこまで文脈を理解できるかの感覚を掴みます
2. **2週目：自分だけが使う小物を1つ作る。**ファイル名の一括変換、CSVの集計、スクリーンショットのリサイズ。壊れても誰も困らないものを選びます
3. **3週目：毎日やっている手作業を1つ自動化する。**ここで初めて「時間が浮く」実感が来ます。同時に、動かなかったときにどう調べるかも学びます
4. **4週目：人に見せるものを1つ作る。**小さなWebページで十分です。ここで初めて品質と見た目の話が出てきて、確認の必要性が体で分かります

指示の出し方のコツは1つだけです。新しく入った人に頼むときと同じ丁寧さで頼む。「いい感じにして」では、人間でもAIでも期待とズレたものが返ってきます。何のために、どこを、どういう条件で、を渡す。それだけで結果がかなり変わります。

もうひとつ有効なのが、実装の前に計画だけ出させることです。「まだ触らないで、手順だけ説明して」と伝えて、内容を確認してから進める。この一手間で、意図しない大改造をされる事故はほとんど防げます。

最初の1ヶ月をこの順番で進めると挫折しにくいです。

よくある質問

プログラミングの知識がなくても本当にできますか

小さいものなら、できます。うちで動いているものの多くは、僕がゼロから書けるレベルを超えています。ただし「知識ゼロで無限に作れる」という話ではありません。動かなかったときに何が起きているかを推測する力は、やっているうちに必要になります。まったくの初心者なら、まずは壊れても困らないものから始めて、うまくいかなかった経験を数回積むのが結局は近道です。

バイブコーディングで作ったものは仕事で使えますか

使えます。うちが現に使っています。ただし条件があって、壊れたときに自分で気づける仕組みと、直せる人がいることです。これがない状態で本番に載せるのは、中身を知らない機械を工場に置くのと同じです。まずは社内向けの、止まっても謝れば済むものから本番投入していくのが安全だと思います。

エンジニアはもう要らなくなりますか

僕はそう思っていません。1年やって強く感じたのは、作る速度が上がるほど「これは作っていいものか」「この設計で将来困らないか」を判断できる人の価値が上がる、ということです。手を動かす部分が速くなったぶん、判断の比重が増えました。少なくともうちでは、技術が分かる人に相談する回数は、始める前より増えています。

まとめ

バイブコーディングを1年やってみて、いま思っていることを3つにまとめます。

• **作れるものは本当に増える。**うちはこの方法でサイト4つとSNS自動投稿、社内botを回しています。誇張ではなく、少人数の会社でできることの範囲が変わりました
• **速いのは最初だけ。**難しいのは作ることではなく、作ったものを保ち続けることです
• **判断は人間に残る。**むしろ、作る手間が減ったぶん、判断の重さだけが手元に残ります

煽るような書き方はしたくないので率直に言うと、これは「誰でもエンジニアになれる技術」ではありません。「作れる範囲が少し広がった道具」です。ただ、その"少し"が、うちのような小さい会社にとってはかなり大きい差になりました。

自社の業務をこういう形で回せるか相談したい方は、お問い合わせからどうぞ。うちが実際にやってきた範囲のことなら、できること・できないことを具体的にお答えします。売り込みはしません。