Blueskyが落ちた。原因は「AIに任せたコード」だった

分散型SNSのBlueskyで、立て続けにサービス障害が発生した。ユーザーの間で即座に広まった批判のキーワードが「バイブコーディング（vibe coding）」だ。

バイブコーディングとは、開発者がAIに対して「こんな感じで作って」と曖昧な指示を出し、生成されたコードを深く理解せずにそのまま使うコーディング手法を指す。「雰囲気（vibe）でコードを書く」という皮肉を込めた呼び名だ。

Blueskyの障害が本当にバイブコーディングが原因だったかは議論がある。しかし、この事件が浮き彫りにした問題は明確だ。AIが生成したコードを、人間が検証せずに本番環境に入れると、システムが壊れる。

これは大企業の話だけではない。むしろ、中小企業こそ危ない。

なぜ中小企業が最も危険なのか

今、中小企業の間で「AIを使ったシステム内製化」が急速に広がっている。背景は明確だ。

• 外注すれば数百万円かかるシステム開発が、AIコーディングツールを使えば数万円で済む
• GitHub Copilot、Cursor、Claude Code——月額数千円で「AIエンジニア」が手に入る
• 「エンジニアを雇えない」中小企業にとって、AIは唯一の開発リソース

この流れ自体は正しい。問題は「品質管理の仕組みがないまま、AIにコードを書かせている」ことだ。

大企業には、コードレビューの文化がある。テスト自動化の仕組みがある。ステージング環境がある。デプロイ前のチェックリストがある。

従業員20人の会社で、社長が「ChatGPTに作ってもらった」システムを本番で動かしている場合、これらの仕組みは何一つない。AIが生成したコードが正しいかどうかを検証する人もいない。動いているから大丈夫——そう思っている間に、データが消えたり、セキュリティホールが空いたりする。

AIコーディングの「品質問題」は具体的に何か

AIが生成するコードの問題点を整理する。

1. 「動くけど壊れやすい」コード
AIは「動くコード」を生成するのは得意だ。しかし「堅牢なコード」を生成するのは苦手だ。エラーハンドリング（異常時の処理）が甘い、エッジケース（想定外の入力）に対応していない、メモリリークを起こす——こうした「普段は動くが、特定の条件で壊れる」コードが量産される。

2. セキュリティの穴
Hacker Newsで指摘されているように、AIが生成するコードにはSQLインジェクションやクロスサイトスクリプティングなどの脆弱性が含まれるケースが報告されている。AIは「機能を実現する」ことを最優先にするため、セキュリティは後回しになりがちだ。

3. 「なぜそう書いたか」が分からない
これが最も厄介だ。人間のエンジニアが書いたコードなら、「なぜこの実装にしたか」を聞ける。AIが書いたコードには、その判断根拠がない。問題が起きたとき、原因の特定に通常の数倍の時間がかかる。

4. 注釈（コメント）の不正確さ
複数の調査で、AIが生成するコードのコメント（注釈）が実際のコードの動作と一致しないケースが報告されている。コメントを信じてコードを修正したら、別の箇所が壊れる——こうした二次障害が起きる。

社内システムを壊さないための3原則

では、中小企業はAIコーディングを使うべきではないのか？　そうではない。使い方の問題だ。以下の3原則を守れば、AIの生産性を享受しつつ、品質崩壊を防げる。

原則1: AIが書いたコードは「下書き」として扱う

AIが生成したコードを、そのまま本番環境に入れない。これが大原則だ。

具体的な運用ルールとして、「AIが生成したプルリクエスト（コードの変更提案）は、必ず人間が確認してからマージ（統合）する」 を徹底する。

「うちにはエンジニアがいない」という場合でも、最低限のチェックは可能だ。

• AIに「このコードにセキュリティ上の問題はないか？」と聞く（別のAIにレビューさせる）
• AIに「このコードのテストコードを書いて」と依頼し、テストを実行する
• 本番投入前に、ステージング環境（テスト用の環境）で最低1週間動かす

AIに書かせて、別のAIにレビューさせる。これだけで、致命的なバグの多くは防げる。

原則2: ガバナンスファイルを作る

「ガバナンスファイル」とは、AIコーディングツールに対して「うちの会社ではこういうルールでコードを書け」と指示するファイルだ。

最近の研究では、50のリポジトリを対象にガバナンスファイルを適用したところ、AIの出力精度が96.4%に達したという結果が出ている。ガバナンスファイルなしの場合と比較して、大幅な改善だ。

中小企業が最低限作るべきガバナンスファイルの内容は以下の通り。

• 使用する言語とフレームワークの指定: 「PythonのFastAPIを使うこと」「フロントエンドはNext.jsを使うこと」
• セキュリティルール: 「ユーザー入力は必ずバリデーションすること」「パスワードは平文で保存しないこと」
• コーディング規約: 「関数名はスネークケースで書くこと」「1関数は50行以内にすること」
• 禁止事項: 「外部APIキーをコードにハードコードしないこと」「本番データベースに直接接続するコードを書かないこと」

このファイルをプロジェクトのルートディレクトリに置くだけで、AIの出力品質は劇的に改善する。作成に1〜2時間。効果は永続的。

原則3: フィードバックループを回す

AIが生成したコードで問題が起きたら、その内容を記録し、ガバナンスファイルに反映する。これを継続的に回す。

具体的には、以下のサイクルを月1回実施する。

1. 過去1ヶ月間でAIが生成したコードに起因するバグ・障害をリストアップ
2. 各バグの原因を分類（セキュリティ、エラーハンドリング、パフォーマンス等）
3. 再発防止のルールをガバナンスファイルに追加
4. 次月のAI出力品質を測定

このサイクルを3ヶ月回せば、AIの出力品質は見違えるほど改善する。なぜなら、AIは「ルールを与えれば従う」性質を持っているからだ。問題は、ルールを与えていないことにある。

「安く作れる」と「安心して使える」は別の話

AIコーディングは、中小企業のシステム開発コストを劇的に下げた。外注で500万円かかっていたものが、50万円で作れるようになった。これは事実だ。

しかし、50万円で作ったシステムが本番で障害を起こし、顧客データが消えたら？　復旧コスト、顧客への補償、信頼の毀損——被害額は500万円では済まない。

「安く作れる」と「安心して使える」は、全く別の話だ。その間を埋めるのが、今回紹介した3原則である。

AIにコードを書かせること自体は止められない。止める必要もない。ただし、AIの出力を「完成品」ではなく「下書き」として扱う文化を、今日から社内に根付かせてほしい。

Blueskyの障害は、他人事ではない。あなたの会社の社内システムで同じことが起きる前に、3原則を導入する。それが、AIの恩恵を受けながら品質を守る、唯一の方法だ。

—