vibe Codingは本当に実用的なのか？企業内で活用するために最低限守るべきこととIT部門の役割【AI時代の実務設計シリーズ】

現場ではすでに使われ始めている

最近、「vibe codingを社内で使いたいんですが、どこから手をつければいいですか」という問い合わせが、ここ半年でかなりの頻度で来るようになった。相談してくるのは、情報システム部門の担当者だったり、DX推進チームのリーダーだったり、あるいは現場のエンジニアを抱えた事業部門のマネージャーだったりする。立場はさまざまだが、悩みの構造はほぼ同じだ。

「現場がすでに使い始めている。止める気はないが、このままでいいのかどうかわからない」

そういう状態。禁止するほどでもないが、放置するには不安がある。でも何をどう整備すればいいのか、指針がない。その"宙ぶらりん感"をどうにかしたい、という相談をいただくことが多くなっている。

vibe codingとは、自然言語でAIに指示を出しながらコードを生成・修正していく開発スタイルのことだ。Antigravity、Cursor、Claude Code、GitHub Copilot、Replit、Boltといったツールが代表格で、一行一行コードをタイプするのではなく、「こういうものを作りたい」という意図をAIと対話しながら形にしていく。

スピードは本物だ。エンジニアでなくとも、適切にAIに用件を伝えれば、簡単なCRUDアプリなら数時間で動くものが出来上がる。社内ツールの試作なら、要件定義の翌日にはデモができる。この体験は、使ったことがある人ならきっと驚くような「すごい」体験だと思っただろう。

ただ、そこで立ち止まって考えないといけない。「すごい」と「安全に業務で使える」はまったく別の話なのだ。

コードが速く生まれることの、意外な落とし穴

vibe codingで最初に気になるのはスピードだが、企業で問題になるのは多くの場合、その後のことだ。

AIが生成するコードは、それっぽく動く。動作テストを通ることもある。見た目もとりあえずは綺麗にできている。でも「なぜこの実装になっているのか」を開発者本人が説明できないケースが頻発する。コードレビューで「ここの意図は？」と聞かれて、「AIが書いたので…」と答えるエンジニアが出てくる。これは笑い話ではなく、実際に起きていることだ。

問題はそれだけじゃない。AIは補完的に外部ライブラリを引っ張ってくることがある。セキュリティパッチが当たっていない古いバージョンを、何の気なしに使ってくることもある。依存関係が気づかないうちに膨らんでいく。「動いているからいい」ではすまされない状況が、静かに積み上がっていく。

速さは武器だが、速さゆえのリスクがある。これをどう飼いならすか、というのがvibe coding実用化の本題と言える。

エンジニアが不要？そんなことはない。
ただエンジニアの仕事が「書く」から「決める」に変わっていく。

vibe codingが普及すると、エンジニアの役割は根本的にシフトする。

コードを書くことよりも、何を作るかを正確に言語化すること。どの処理をAIに委ねて、どこは自分で書くかを判断すること。AIが出してきたコードの品質を評価する目を持つこと。この三つが、これからのエンジニアに求められる核心になってくる。

直感で手を動かすのではなく、再現可能なプロセスとして開発を設計する能力。これが問われるようになる。ベテランエンジニアにとっては、ある意味で腕の見せどころが変わる感覚かもしれない。「いいコードを速く書ける人」よりも「何が必要かを正確に定義できる人」のほうが、AIを使った開発では強くなる。

面白いのは、この変化がエンジニアリングをより「ビジネスに近いもの」にしていくことだ。要件の解像度を上げる能力、制約条件を整理する能力、リスクを可視化する能力。これらは本来、ビジネスサイドが持っていた武器に近い。

セキュリティ：AIが速いからこそ、境界線を先に引く

企業でvibe codingを使うとき、最も真剣に向き合わなければいけないのがセキュリティだ。

AIはコードを書く速度を何倍にも引き上げるが、セキュリティの問題を自動的に解決してくれるわけではない。むしろ速度が上がるぶん、脆弱性が混入するスピードも上がると考えるべきだ。

実際に注意すべきポイントはいくつかある。

まず、AIへの入力に何を渡すか、という問題。プロンプトに本番DBの接続情報を書いてしまうとか、顧客データをサンプルとして貼り付けてしまうとか。無意識にやりがちなことが、実は深刻なリスクになる。開発環境とデータのルールを明文化しておかないと、誰かが気づかないうちに越えてはいけない線を踏み越える。

次に、API境界の設計。vibe codingで作ったコードが外部サービスや社内システムと連携するとき、どのAPIをどの権限で叩くかを厳密に設計しておく必要がある。AIが「便利だから」という理由で広めの権限を使うコードを書いてくることは珍しくない。これをそのまま通してしまうと、後から権限設計を直すコストが跳ね上がる。

ガバナンスの話もある。誰がvibe codingツールを使っていいのか、どのツールを使っていいのか、生成されたコードはどういうレビューフローを経るのか。ここがグレーゾーンのままだと、統制が効かなくなる。「とりあえず試してみた」コードが知らないうちに本番に近いところで動いている、という事態は笑えない。

3層アーキテクチャという考え方

では、こういったリスクをどう構造的に管理するか。そこで有効になるのが、3層のアーキテクチャという整理軸だ。

簡単に言うと、コードを三種類に分けて考える。

コア層は、ビジネスロジックの中枢。顧客データの管理、決済処理、認証認可といった、会社の根幹に関わる部分だ。ここは人間が責任を持って書き、レビューし、管理する。AIに任せる割合を最小限に抑える。触るときは慎重に、変更の影響範囲を常に意識する。

API層は、コア層と外部をつなぐ境界線。何を外に見せて、何を隠すか。どの処理を外部から呼べるようにするか。この設計がセキュリティの最前線になる。ここをきちんと設計しておくと、外側で何が起きても内側が守られる構造になる。API境界が曖昧だと、vibe codingで作ったコードがどこまで侵食してくるかわからなくなる。

使い捨て層は、AIが得意とするところだ。社内ツール、プロトタイプ、データ変換スクリプト、一時的なダッシュボード。ビジネスロジックに直接触れない、比較的リスクの低いコード群。ここはvibe codingを積極的に使っていい。速く作って、動きを確認して、必要があれば捨てて作り直す。

この三層を意識すると、「どこまでAIに任せていいか」の判断軸が生まれる。全部をAIに任せようとするから話がこじれる。任せていい場所と、人間が守らないといけない場所を分けることで、スピードとセキュリティを両立できる。そしてこのやり方であれば、社内の全ての人間が「vibe coding」を活用できる素地ができる。

IT部門がやるべきことは、禁止ではなく設計だ

企業でvibe codingを導入しようとすると、IT部門は二つの方向に引っ張られる。「リスクがあるから禁止」か、「現場が使いたいから黙認」か。どちらも正解じゃない。

禁止は現実的ではない。すでに使っている人がいるし、使いたい人はどんな規制があっても個人端末で使い始める。「シャドーAI」というものだ。そして黙認はもっとまずい。問題が起きたとき、誰も全体像を把握していないという状況になる。

IT部門の本来の役割は、安全に使える環境を丸ごと設計することだ。具体的に何をするべきか、順番に整理してみる。

① ツールの承認と棚卸し

まず「何を使っていいか」を明示する。Cursor、Claude Code、GitHub Copilot、それぞれのツールがどんなデータを外部に送るのか、利用規約の観点で問題がないかを確認したうえで、承認リストを作る。ここで大事なのは「禁止リスト」ではなく「承認リスト」を作ることだ。何がOKかを示すことで、グレーゾーンをなくす。

あわせて、すでに現場で使われているツールの棚卸しを先にやるのが現実的だ。「禁止します」と言う前に「今何を使っていますか」を聞く。実態を把握しないまま規制を作っても、守られない。

② 入力データのルール化

次に、AIツールに何を渡していいかのルールを作る。これが意外と抜けていることが多い。

明文化すべき内容は大きく三つある。本番環境の認証情報（APIキー、DBパスワードなど）は絶対に入力しない。個人情報・顧客情報を含むデータはマスキングなしに渡さない。社外秘扱いの仕様書や設計書をそのままプロンプトに貼らない。この三点を全社共通のルールとして周知するだけで、リスクの大半は下げられる。

③ コードレビューフローの再設計

vibe codingで生成されたコードには、通常の開発フローとは異なるレビュー視点が必要だ。

通常のコードレビューは「実装の意図を確認する」ことが中心だが、AI生成コードは「なぜこの実装になったか」を書いた本人が説明できないケースがある。だからレビュアー側が能動的に読みに行く姿勢が必要になる。

具体的なチェックポイントとしては、不必要な外部ライブラリが使われていないか。権限スコープが必要最小限になっているか。ハードコードされた認証情報が混入していないか。エラーハンドリングが適切か。この四点を最低限のチェックリストとして整備しておくといい。

レビューフローそのものも見直す必要がある。AI生成コードがそのままPRに乗ってくる場合、レビュアーの負荷は上がる。AIによるレビュー、ペアレビューの導入や、CIでの静的解析の強化など、人間のレビューを補助する仕組みをセットで考えることを推奨する。

④ 環境分離の徹底

vibe codingが特に危険になるのは、開発環境と本番環境の境界が曖昧なときだ。

「ちょっと試してみただけ」のコードが、気づいたら本番に近いところで動いている。こういう事態は、環境分離が甘い組織でよく起きる。開発・ステージング・本番の三環境を明確に分離し、それぞれへのアクセス権限を別管理にする。vibe codingツールからは本番環境に直接アクセスできない構成を標準にする。

これはvibe coding固有の話ではないが、スピードが上がるぶん、誤って本番を触るリスクも上がる。環境分離の徹底は、AI時代の開発においてより重要になっている。

⑤ デプロイの承認フローを明確にする

生成されたコードがどういう経路で本番に届くかを、フローとして明文化する。

最低限必要なのは、コードレビューの承認者が誰かを決めること。本番デプロイのトリガーを誰が引けるかを制限すること。そしてデプロイ履歴とロールバック手順を整備しておくこと。この三点だ。

vibe codingはプロトタイプを爆速で作れるが、それが「そのまま本番でいいか」の判断は人間がしなければいけない。この判断のゲートをシステム的に設けることで、スピードと安全性を両立できる。

⑥ 教育：ルールより「なぜか」を伝える

ルールを作るだけでは足りない。vibe codingを使うエンジニアが「AIが書いたコードの何を確認すべきか」を理解していなければ、どれだけ規則を整備しても形骸化する。

教育で伝えるべきは、手順ではなく背景だ。なぜ入力データにルールが必要なのか。なぜAPI境界の設計が重要なのか。なぜ3層を分けて考えるのか。この「なぜ」を理解している人間が現場にいると、ルールが書かれていない場面でも適切な判断ができるようになる。

ツールの使い方を教えるより、AIとの付き合い方を組織として学ぶほうが、長期的には価値が高い。

⑦ CLAUDE.mdとSkillsの社内標準テンプレートを整備する

これが、2025年後半から急速に注目されている実務的な取り組みだ。そしていちばん後回しにされやすい。

Claude Codeには、CLAUDE.mdというプロジェクト設定ファイルが存在する。これはセッション開始時にClaude Codeが自動的に読み込む特殊なファイルで、bashコマンド、コードスタイル、ワークフローのルールなどを記述しておくことで、コードだけからは推測できない文脈をAIに渡し続けることができる。

ポイントは「毎回プロンプトで説明しなくていい」という点だ。チームのコーディング規約、使っているフレームワーク、テストの書き方、PRのフォーマット。こういった「うちのチームのやり方」をCLAUDE.mdに書いておくと、AIが最初から文脈を持った状態でコードを書いてくれる。

ただし、書きすぎは逆効果になる。Claude Codeのシステムプロンプトにはすでに約50の個別指示が含まれており、それはモデルが確実に従える指示の約3分の1に相当する。つまりCLAUDE.mdの内容は、すべてのタスクに普遍的に適用されるものだけに絞り込むべきで、内容が多すぎると重要なルールが埋もれてしまう。コードスタイルのような細かい規約はlinterに任せ、CLAUDE.mdにはアーキテクチャ上の判断軸や、チーム固有のワークフローだけを残すのが現実的だ。

もう一つ整備したいのが、Skillsと呼ばれるモジュール型の拡張機能だ。SkillsはSKILL.mdというmarkdownファイルを核として、Claude Codeの文脈に動的にロードされる仕組みで、フロントマター（frontmatter）部分でそのSkillをいつ使うかを定義し、本文でClaudeへの具体的な指示を記述する。Toolsが処理を実行してその結果を返すのに対して、Skillsは問題を解くための準備をClaude自身に対して行う点が異なる。

企業での活用シーンで言えば、たとえばこういうSkillが考えられる。

「セキュリティレビュー用Skill」——認証情報のハードコードがないか、外部ライブラリのバージョンが安全かを確認するチェックリストをClaudeに持たせる。「デプロイ前確認Skill」——本番反映前に必ず走らせる検証ステップをAIに手順として持たせる。「社内APIガイドラインSkill」——自社のAPI設計方針をClaude Codeが参照できる形でパッケージ化する。

SkillのSKILL.md内のdescriptionフィールドの書き方次第で、Claudeがそのスキルを適切なタイミングで呼び出す精度が大きく変わる。最適化されたdescriptionを書くことで、Skillの発動精度が20〜50%から、具体的な使用例を加えることで最大90%まで向上するという報告もある。

IT部門がやるべきことは、CLAUDE.mdとSkillsの社内標準テンプレートを作って配布することだ。個々のエンジニアが各自で設定するのではなく、チーム・プロジェクト共通の基盤として管理する。バージョン管理もGit上でやっておくと、「このルールはいつ・なぜ追加されたか」が追跡できて、後から修正しやすくなる。

これは一見地味な作業だ。でも、AIへの指示の質がアウトプットの質を直接左右する以上、「組織として何をAIに教えておくか」を設計することは、もはやIT部門の本質的な仕事になってきていると思っている。

まとめ

生産性が上がるかどうかは、ツールそのものよりも運用設計によって決まる。vibe codingに限らずそれは真実だが、AIを絡めた開発においては特に、その差が如実に出る。

冒頭に書いた「宙ぶらりん感」を抱えている組織は多い。でもやることは意外とシンプルで、ツールを承認して、データのルールを作って、レビューフローを整えて、環境を分けて、CLAUDE.mdとSkillsを整備して、人に教える。順番に手を打てば、必ず着地できる。

優れたエンジニアやディレクター、経営者がAIを使えるようになるのは当たり前で、むしろ真の価値を発揮するには、事業部全体、社内全体で使える状態になってからだと私は考える。ゆえにできる限り安全に、そして「新しい開発」に取り組みやすい環境を作っていけるかが、これからのIT部門の重要な仕事になると感じている。