バイブコーディングで作った社内ツール、業務に載せてよいか

バイブコーディングとは、AIに自然な言葉で指示を出し、雰囲気（vibe）を伝えるようにコードを書かせる開発手法です。プログラミングを知らない社員でも社内ツールを作れるようになりました。ただし「作れる」と「業務に載せてよい」は別の問題です。この記事では、その判断基準を会社としてどう決めるかを解説します。

僕はAIVESTという会社を経営しながら、自社の業務ツールをAIで多数内製し、毎日の業務に載せて運用しています。同時に「外に出すもの、出さないもの」の線引きを明文のルールとして運用してきました。一律禁止でも放置でもない、その中間の作り方を実物つきで書きます。

バイブコーディングとは？非エンジニアが社内ツールを作れる時代

言葉の意味と由来

バイブコーディングは、人間が「こういうものを作って」と言葉で伝え、コードはAIに書かせ、人間は出てきたものが期待どおりかを確かめる、という開発スタイルです。コードの中身を読まずに、対話の雰囲気（バイブ）でソフトウェアを組み上げていくことからこう呼ばれます。

言葉の由来は、OpenAIの創業メンバーだったAndrej Karpathy氏が2025年2月に投稿した「コードの存在すら忘れて、完全にバイブに身を委ねる」という表現です。その後この言葉は一般にも広がり、2025年11月には英コリンズ辞典の「ワード・オブ・ザ・イヤー2025」に選ばれました。新語としてはかなりの速度で市民権を得た言葉です。

「作れない」が理由にならなくなった

これが会社にとって何を意味するか。社内ツールの内製を止めていた「作れる人がいない」という理由が、消えたということです。

見積もりの計算、日報の集計、問い合わせの振り分け。今までは外注するか諦めるかだった小さな業務ツールを、現場の非エンジニア社員が半日で形にしてしまう。僕自身も、ブログ運用の自動化、SNS情報収集の仕組み、会議記録の整理など、自社の業務ツールをAIとの対話で内製して毎日回しています。エンジニアの採用も外注もしていません。

だからこそ、会社の論点は「作れるか」から「業務に載せてよいか」に移りました。ここを決めていない会社は、全面禁止か、知らないうちに現場で増殖するかの二択になります。

なぜ「作れる」と「業務に載せてよい」は別問題なのか

経営者と実務者が同時に鳴らしたブレーキ

2026年8月、X上でこのテーマの議論が目立ちました。ビジネスチャットChatworkを運営するkubellの山本正喜CEOは、非エンジニアがAIで作った社内アプリを外部のホスティングサービスで公開することの危険性について注意喚起する投稿をしています。また、開発の現場でレビューを担う実務者からは「非エンジニアが作ったものをレビューすると、ほぼ確実に危険な設定が見つかる」という趣旨の指摘が、経営者のなかじ氏からは「既製のツールで足りるものを作ってしまう車輪の再発明」への言及がありました（いずれも文末の出典参照）。

注目すべきは、作れるようになったことを喜ぶ声ではなく、「作った後の統制」を語る声が、経営側とレビュー実務側の両方から同じ週に出てきたことです。ブームが業務に入り始めた合図だと僕は受け取っています。

リスクはコードの中ではなく「置き場所と接続」に集まる

僕の実感では、バイブコーディングで作ったツールの危うさは、コードの書き方そのものより周辺に集まります。誰でも開けるURLに業務データを置いていないか。パスワードやAPIキー（外部サービスに接続するための鍵）をファイルに直書きしていないか。外部サービスへ勝手にデータを送っていないか。そして、作った本人にしか直せない属人化が起きていないか。

個人の学習や試作は自由でいいんです。しかし、業務データが入った瞬間、他の社員が使い始めた瞬間に、それは「会社のシステム」になります。この境界線を越える条件を決めていないことが、禁止か放置かの二択を生む本当の原因です。

会社が最初に決める統制は5つ。作る・公開する・やめるの線引き

僕が自社で運用している決めごとを、どの会社でも使える形に一般化すると5つになります。検索上位の解説記事はメリットとデメリットの整理までで、この「何を決めればよいか」にはほとんど踏み込んでいません。

5つとも高度な技術ではなく、ただの「決めごと」です。エンジニアがいない会社でも今日決められます。逆に言えば、決めていないことは技術力では補えません。

僕の会社で運用している線引きの実物

置き場所の規約は、事故から生まれた

僕の会社の配置規約は、きれいな設計から生まれたものではありません。2026年6月、社内向けのダッシュボードや仕様書ページを案件ごとに別プロジェクトとして量産し続けた結果、使っていたクラウドホスティングの無料枠上限である100プロジェクトに到達し、新しいデプロイが一切できなくなりました。しかも100個のうち97個は元ファイルの所在が分からず、整理も作り直しもできない状態でした。

枠を使い切った日は、さすがに青ざめました。片付けは事故の後では遅いんですよね。

それ以来、社内向けの仕様書・ダッシュボード類は内部ハブ1か所に集約し、外部に公開するURL（LPや顧客への提出物）は専用ドメインで分離する、という配置規約を明文化しました。内部のものは増えても置き場が1つ、外部に出るものは出る理由と置き場がセットで決まる。散らかってから片付けるのではなく、置き場所を最初に決める方式です。

機械ゲートが先、人間レビューが後

公開系の操作には二段のゲートを敷いています。例えばこのブログの記事は、構造や必須要素を検査するスクリプトに合格しないと投稿の操作自体に進めません。合格して公開された後も、24時間以内に僕自身がレビューする運用とセットです。SNSへの投稿は自動化の仕組みを作り込んでいますが、最後の公開ボタンだけは自動化せず、人間が押すと決めています。

機械が先に落とし、人間が最後に見る。この順番を逆にしない。というのが僕の運用原則です。人間が先に見ると、疲れている日の見落としがそのまま事故になります。

あわせて「作らない判断」も仕組み化しています。新しい自動化ツールを作る前に、①その作業は週1回以上繰り返すか、②機械が合否を判定できるか、③暴走時に止まる上限があるか、④人間が確認する場所はどこか、の4条件を確認し、1つでも答えられなければ作らずに手作業で済ませます。

凍結ノード。AIに書き換えさせない領域の明文化

もう1つ、上位の解説記事に見当たらない運用が「凍結ノード」です。検査スクリプト、合格基準、NGワード集といった「判定する側」のファイルは、AIの自動改善の対象から明示的に外し、変更できるのは人間だけと明文化しています。AIに運用を任せるほど、AIが自分の採点基準を書き換えられない構造が効いてきます。同じ発想で「社外に公開しない領域」も明文化していて、例えば秘密情報の管理方法そのものは、社外向けの記事に書かないというルールを文書で持っています。

一律禁止にしないために。線引きの次にやること

ルールは「使う側」と「作る側」の二層で持つ

この記事で扱ったのは「作る側」の統制です。その手前には、社員が生成AIを日常業務で使うための利用ルールという層があります。まだ整備していない会社は、先にこちらからです。

関連記事ChatGPT社内ルールの作り方。生成AIガイドライン雛形つきChatGPT社内ルール（生成AIガイドライン）に入れる7項目・作成5ステップ・そのまま使える雛形全文に加え、経産省・総務省・JDLAなど公的ガイドラインの使い分けを、AI顧問の実務目線で解説します。→

作る側の統制を深めるなら、AIにどこまでの権限を渡すかの設計をAI自動化の権限とリスク設計で、事故が起きたときの直し方をAI運用の再発防止の仕組みで書いています。

内製・外注・教育を使い分ける

すべてを内製する必要はありません。失敗したときの影響が大きいもの、自社に運用の手が足りないものは、内製と外注の判断基準で書いたとおり外部に頼む選択肢があります。何から作らせるか迷う場合は生成AIの社内活用事例が参考になりますし、作る社員の底上げにはAI研修の選び方ガイドをどうぞ。

最後に強調しておきたいのは、一律禁止はいちばん安全に見えて、実はいちばん統制が効かない選択だということです。禁止された現場は、見えない場所で個人アカウントのAIを使って作ります。線引きを公開して、明るい場所で作らせる。これが僕の結論です。

バイブコーディングのよくある質問

出典

本記事の「統制5つ」の分類と運用の実物は僕の自社運用にもとづくものです。作った後の統制を巡るX上の議論と、言葉の由来については以下を下敷きにしました。

• 山本正喜氏（kubell CEO）のポスト

• なかじ氏のポスト

• やぎ氏のポスト

• コリンズ英語辞典「Word of the Year 2025」（2025年11月発表）および Andrej Karpathy氏の2025年2月の投稿