作成したプラグインはシンプルなもので、ノート内の「やるべきこと」（アクションアイテム）を簡単にマークし、自動で一覧化する機能だ。筆者は普段、アクションアイテムを「//」という記号を用いてマークしているが、後からそれらを探し出すのが手間だった。そこで、「//」から始まる行を自動検出し、それらをページ冒頭の「Action Items」セクションリストアップしてくれる機能を実装したいと考えた。

　AIチャットbot「Claude」と「ChatGPT」で生成したソースコードは、確かに目的通りに機能した。しかし、動作を確認するうちに、ソースコードに不自然なスロットリング（間引き）処理が入っていることに気付いた。その理由をAIモデルに尋ねたところ、次のような回答が返ってきた。「文書全体をスキャンして『//』が含まれている行を検出する必要があるため、CPU負荷を考慮して、150ミリ秒ごとに1回だけ処理を実行するようスロットリングしています」

　この回答には驚かされた。単に行頭が「//」かどうかを判断するために、文書全体を150ミリ秒ごとにスキャンするのは、明らかに非効率的だ。仮に30分間の会議ノートを開いている場合、1万回以上も同じノートをスキャンする計算になる。

　筆者が「行頭の2文字を確認し、空白は無視すれば済むのではないか」と指摘すると、AIはその提案を受け入れ、該当部分を修正。結果として、より軽量かつ効率的なプラグインが完成した。

　ここで重要なのは、もし人間側がこの非効率な処理に気付かなければ、そのまま運用されていたという点だ。こうした無駄の積み重ねは、確実にシステムリソースの浪費につながる。筆者がこれまでAIコーディングツールを活用してきたのは、いずれも比較的小規模なプロジェクトばかりだが、非効率な処理は頻出していた。規模が大きくなるほど、その影響はさらに顕在化しやすい。

　結論、AIコーディングツールはまだそのまま使える段階には達していない。スキルを備えた人間が適切に管理しないと、ソースコードの質の低下やリソースの無駄遣い、セキュリティリスクさえも引き起こしかねない。

バイブコーディングの気になる「安全性」

　AIコーディングツールは、あくまで「ユーザーが求める機能を実現すること」を目的としたツールだ。セキュリティや性能面への配慮は、基本的に後回しにされる。

　筆者はセキュリティ専門家ではないが、実際にAIモデルが生成したソースコードを確認すると、レースコンディション（同時処理の競合）への対処など、安全性に関わる部分の記載が甘いケースが見受けられた。多くの場合、根本的な設計改善ではなく、その場しのぎのパッチ（修正プログラム）だけで済ませているようだ。

　この問題は、プロンプトの工夫や、セキュアコーディングに特化したドメイン固有言語（DSL）の導入で軽減できる可能性もある。しかし実際には、「GitHub Copilot」「Cursor」などのAIコーディングツールであっても、非効率かつ脆弱（ぜいじゃく）なソースコードが出力されるのが実情だ。

　特に、異なるデータソース間で情報をやりとりするような場面では、その安全性をユーザー自身が見極められるかが問われる。

　現時点では、AIコーディングツールの利用には「人間によるコードレビューと管理」が不可欠だ。単に動作を確認するだけでなく、安全性、効率性、実用性を総合的に判断することが求められる。

　バイブコーディングは誰でもすぐに実践できるため、エンドユーザーによる活用がIT部門やセキュリティチームの想定を超えて広がる可能性がある。現時点ではまだ大規模に広がっているわけではないが、今後生成AIの導入が進む中で、状況は急速に変化し得る。

　特に注意が必要なのは、これらの活動が「IT部門の監視の外」で起こる点だ。社内で承認されていないAIツールが業務で使用されているケースは少なくない。

　仮にそれがセキュリティインシデントに直結しないとしても、インフラへの負荷増大といった形で問題が顕在化する可能性はある。筆者のObsidian向けプラグインのように、軽微な処理であっても非効率な設計のまま多数の環境に展開されれば、累積的にインフラ全体の処理能力に影響を及ぼすリスクがある。

　AI活用が日常になりつつある今、バイブコーディングの普及を前提とするなら、IT担当者やセキュリティ担当者は次のような問いに真剣に向き合う必要がある。

• ユーザーによる生成AI活用をどうガイドし、支援するか
• リスクを最小化しつつ、イノベーションを促進するにはどうすべきか
• バイブコーディングで生成したソースコードをどう特定し、評価するか
• どのタイミングで介入すべきか、その判断基準は何か