素人がAIに作らせたコード、プロが見ると何点？ エンジニアレビューで分かる危険性：バイブコーディングやってみた
バイブコーディングの登場で、コードが書けない人でも自分が欲しいツールを手に入れられるようになった。素人が生成AIに作らせたコードを開発エンジニアに採点してもらい、バイブコーディングが現実的にビジネスに適用できるのかをチェックした。
「バイブコーディング」という言葉を聞いたことがあるでしょうか。いわゆるIT流行語の一つで、ざっくり言えば「生成AIにコーディングさせる開発手法」です。人間がキーボードを打って直接コードを入力するのではなく、「Claude Code」のような生成AIツールにコードを出力させることを指します。
Googleの資料「vibe コーディングとは」では「AI を使用して自然言語プロンプトから機能コードを生成する新しいソフトウェア開発手法」「開発が加速され、特にプログラミング経験が限られている人にとっては、アプリの構築がより身近なものに」と説明されています。
バイブコーディングの登場で、コードが書けない人でも自分が欲しいツールを手に入れられるようになりました。今回は、プログラミングを学んだことがない“素人”の筆者が、生成AIに作らせたコードを、当社の開発エンジニア（仮名：Eさん）に辛口採点してもらい、バイブコーディングが現実的にビジネスに適用できるのかをチェックしていきます。
およそ目的の業務を自動化できましたし、私としてはかなり頑張ったつもりですが、プロの評価は散々なものでした。気づかないところで危ない部分もあったようです。皆さんがハマるかもしれない素人バイブコーディングの危ないところを見ていきます。
「32点」素人バイブコーディングのどこが問題だったのか
筆者は「Google スプレッドシート」用のスクリプトやChrome拡張を生成AIに作らせて使っているのですが、あるときふと思ったことがあります。「こうやって勝手に作ったツールって、情報システム部門（情シス）やITエンジニアから見ると厄介なのではないか」と。
素人が生成AIに作らせたコードは安全ではない可能性があります。脆弱（ぜいじゃく）性について考慮されておらず無限ループ処理が発生したり、不用意にネットワークに接続して機密情報が外部から見えるようになっていたり、社内DBを消し飛ばすような処理が混ざっていたりと、危険が潜んでいるかもしれません。しかもその危険性を、バイブコーディングした本人が気付けない可能性は十分にあります。
しかし、これを危険視して、社内ルールとして「バイブコーディングでツールを作った場合、使用する前に情シスにチェックを申請し、安全性が確認すること」なんて定められては、情シスが素人作の謎のコードをいくつも見て修正して回ることになってしまいます。現実的にそんな時間があるでしょうか。
素人たる筆者が作ったコードの概要
そこで、今回は筆者がバイブコーディングで作成し、実際に使っているGoogle スプレッドシート用スクリプトを開発エンジニアのEさんに見てもらうことにしました。
このツールはキーマンズネットが会員向けに配信しているメールマガジンの作成を補助するものです。スプレッドシート上でテンプレートを選択し、必要情報を入力すれば、メールマガジンの本文を作成できます。業務効率化と品質の安定を狙ったもので、やっていることはほとんど文字列の操作だけです。
当メディア会員の方々はお分かりかと思いますが、キーマンズネットのメールマガジンのメインコンテンツは掲載記事の紹介なので、作成時にも記事情報を入力します。これ自体は単純作業なので自動化できます。その分、どの記事を選定するかやコラムの執筆に時間をかけた方がリッチなコンテンツにできます。
社内の記事データベースに接続するのは怖かったので、タイトルや要約文などの記事情報はURLからスクレイピングで取得するようにしています。少しお行儀が悪いですね。
結果的に、スプレッドシートで掲載する記事のURLやコラム、告知テキストなどを入力してボタンを押すと、メールマガジン本文ができるツールができました。バイブコーディングにはGeminiを使っており、ツールの仕様は筆者が決めました。
コード30点、動くので2点加点
Eさんは「セキュリティ、通信の礼儀」「変更容易性」「速度、パフォーマンス」「テスト観点」の4つの視点でチェックしてくれました。
セキュリティ、通信の礼儀というのは、セキュリティ上問題がないか、問題がないとして礼儀がなっているかという観点です。スクレイピングはそれだけで違法になるわけではありませんが、常に問題ない行為とは言えません。特定のWebサイトに大量のリクエストを送ることで負荷をかけることがあれば責任を追及される可能性もあります。
筆者のツールについて、Eさんの評価は「△」でした。
- URLの入力次第だが、同サイトに1万件ぐらいスクレイピングを実行する場合、無策だと危険。スクレイピングが走るなら、waitするのが礼儀
- 「そんな使い方しない」のであれば、まあOKな気がする……
- 後ろの行でitmediaドメインに限定したアクセスであることは確認できた。ITエンジニアが「何故それをやりたいの？」と聞く理由の一端がこういう疑問を解消するため
一応、対策はあるのですが、リクエストの爆発を完ぺきに防げるものではありませんでした。指摘を受けて、制限を追加しました。
変更容易性というのは、仕様や環境、やりたいことが変わったときに修正できるかという観点です。Eさんの評価は「△」でした。
- ネストが深い（入れ子構造のコードが多い）ので分割してほしい。プロダクトコードなら、セキュリティ云々以前に見た瞬間に突き返します
- 毎行丁寧に ログを出力させているけど、動かすのにこんなの要らないのでは？ デバッグが終わったら消しましょう
- 複雑な処理で何をしているのか分かりづらいので、コードコメントで説明はほしい
変更容易性が低いというのは、“なぜ動くのかわからないExcelマクロ”と同じ問題です。その人が異動したり退職したりすると、動かなくなったときに改修できなくなりますが、これは変更容易性が低いか、資料を読める人がいない（資料がない）かのどちらかだといえるでしょう。
速度、パフォーマンスは、そのツールが十分な速度で軽快に動くかどうかという観点です。今回はシンプルな機能のGASであるため評価なしになりました。
テスト観点とは、コードが正しく動作するかを確認するためのテストを考えることです。Eさんの評価は「分からない」でした。
- コードは書いたとおりにした動かないので、テストは要件から書き起こすのが吉
- 変数の中身が分からない部分もあるので、ロジックがあってそうか、というところがパッと見ではわからない。 これは誰もメンテナンス出来ないサインなので、個人の使い捨てでなければ危険な兆候
実際、このツールが動くことは事実として確認していますが、テストは実施していませんし、正しく動作していないがあきらめている箇所（日付の計算が違う）があります。
プロの総評 使用の責任は使用者
以上を踏まえてコードに点数をつけるなら何点か聞いたところ、コードが30点で、最低限動作するので2点加点して32点とのことでした。総評は以下の通りです。
- 使い捨てのコードなら、バイブコーディングでこれだけのことができてるのは個人的には 良いんじゃないかと思う
- ただし変更が辛そう。今なら「リファクタリングして」でいいところまでやってくれるかも
- ソフトウェアテストの知識はバイブコーディングするにしても欲しい。出てきたコードを使用する責任は人間が負うしかない
- Webの海を泳ぐなら、セキュリティ上やってはいけないことがないかを確認する方がよさそう
バイブコーディングする上で最も重要といっていい観点の一つは、コードを作ったのが生成AIであっても、それを使うなら責任を負うのは使用者であるという点です。バイブコーディングで作ったプログラムを使ったところ、個人情報流出が発生した場合を考えてみましょう。このとき「情報が流出したのは生成AIが問題のあるコードを出力したせいです。私は悪くありません」という言い訳は通用しません。
出来上がったコードを誰が使うのかでも責任の重さは変わります。自分が個人で使うのか、部署や社内全体で共有するのか、社外に広く公開するのかで、問題発生時の影響範囲は全く違います。
単一のスプレッドシートで動作するだけならまだしも、社内の他のシステムに接続したり、外部との通信があったりすると、それが重大なインシデントにつながる恐れもあります。入力フォームがあるWebページを作って公開すると、クロスサイトスクリプティングやSQLインジェクションが発生する恐れもあります。
そして、本当に素人であればこれらのリスクに気付くことも難しいのではないでしょうか。スクレイピングを知らない人が「スクレイピングするなら対象に負荷がかからないように配慮しないといけないよね」なんて思うことはあり得ないはずです。
じゃあバイブコーディングはやらない方がいいのか
では、バイブコーディングはやらない方がいいのかというと、切り捨てるにはもったいないものです。事業部門が欲しいツールをすぐに手に入れられるというのは魅力的です。
事業部門側ができることの一つは、生成AIに常にリスクをチェックさせることです。「今生成されたコードについて、セキュリティや利用上の懸念点についてコメントしてください」のように、レビューも生成させるだけでもかなり違ってきます。「リファクタリング（コードを整理）して」という指示も有効になることがあります。
情シス、技術部門側でできることもあるといいます。
「安全領域やサンドボックス領域とそれ以外を物理的に区切って、安全領域内では自分の責任で自由にやってもらえるようにするのがいいんじゃないかなと思います」（Eさん）
ある程度何をやっても問題ない場所を作って、そこでバイブコーディングをさせれば、影響範囲を制限できます。また、バイブコーディングをするならここでやるべしと定めることで、管理者がどんなツールが作られているのかを俯瞰的に把握できるメリットもあります。
こういった仕組みをプラットフォームとして完成させたものが、「kintone」などのノーコードプラットフォームだと考えることもできるでしょう。
バイブコーディングにおけるリスクを理解した上で、それを制御できるよう環境を整えて、その効果を最大限享受できるようにしましょう。
Copyright © ITmedia, Inc. All Rights Reserved.