Claude CodesとGitHub Copilot選択前に必ず知るべき7つの危険信号—バイブコーディング著者Shim Jae-woo・Sun Woong-gyu代表による実戦警告

初めて聞くバイブコーディングという用語、むやみにClaude CodesやGitHub Copilotから始めてはいけません。本記事はAXエデュグループのShim Jae-woo代表とSun Woong-gyu代表が5年間ノーコードおよびAIベースの開発プロジェクト200件以上を進めながら目撃した失敗事例と副作用を中心に執筆します。AIコーディングツールは確かに強力ですが、誤った選択と運営は初期開発時間を30%以上浪費し、技術負債を雪崩のように膨らませます。本記事はその危険を明確に指摘し、いつどのツールを捨てるべきかを示します。

全般的なバイブコーディング原理と概念は1編総合ガイドで扱ったため、ここでは副作用・禁忌事項・してはいけない状況7つに集中します。

AIコーディングツール使用時の最も一般的な誤りは「うちの会社のロジックなら大丈夫だろう」という過信です。金融・医療・政府システムのような規制産業でClaudeやGitHubといったクラウドベースのAIにコードを貼り付ける瞬間、知的財産権侵害と規定違反が同時に発生します。Shim Jae-woo代表の事例を見ると、あるスタートアップが簡便決済システムの暗号化ロジックをCopilotにコピペした後、金融監督庁の監視対象になり、開発納期3ヶ月が6ヶ月に遅れました。

なぜ危険か:

•AIモデル学習データとしてコードが吸収される可能性(公式約款では選択可能だが、デフォルトは学習)

•GDPR・PCI-DSS・HIPAAのような規定で「第三者システム公開」に分類される場合がある

•複合暗号化やトークン管理ロジックはAIが「一般的パターン」としてのみ提示するため、セキュリティ漏洞がそのまま放置される

•後で監視対象追加時、コード履歴追跡不可能

代替案: 自体LLM展開(Ollama・LM Studio)またはセキュリティ隔離されたオンプレミスエディターのみ使用。金融・医療クライアントプロジェクトは最初からAIツール使用を禁止し、手動コードレビューで進めてください。

要点：セキュリティが優先される産業群ではクラウドAIコーディングツールは「選択肢ではなく禁止事項」です。

AIコーディングツールは単一関数や簡単なCRUDロジックはよく作ります。しかし複数のマイクロサービス間の非同期通信、タイムアウト処理、循環依存性が混ざった瞬間、生成されたコードは「見た目は動作するが内部的に爆弾」です。Sun Woong-gyu代表が経験した事例：あるチームがClaudeのNode.jsコードを信頼し、3週間配布後、API応答遅延が300msから2秒に急増しました。原因はAIが生成した並列リクエストロジックが実際には順序実行されており、リトライロジックが無限ループを作っていたことでした。

なぜ危険か:

•AIはAPI応答時間・ネットワークレイテンシ・データベースプール枯渇を「仮定的に」のみ処理

•エラーハンドリングが機械的なため、実際のプロダクション環境の部分障害(Partial Outage)状況で「全体システムダウン」に拡大

•キャッシング戦略、バックプレッシャー(backpressure)、サーキットブレーカーなどの高度なパターンはAIが見落としやすい

•ロードテスト無しにコードを信頼すれば、運用初週にincident殺到

代替案:

AI生成コード「スケルトン(骨組み)99%」と扱い、エラー処理・タイムアウト・ロギングは別途手動作成

配布前に最低1,000 RPS負荷テスト必須

マイクロサービスはチーム経験豊かなエンジニアが最初にアーキテクチャを描き、AIはその枠の中でのみ実装

要点：複雑アーキテクチャではAIコード検証なしの配布は技術負債の始まりです。

React・Vueなどの現代フロントエンドは状態管理が数百個のコンポーネントを接続します。GitHub Copilotが「良く見える」コンポーネントコードを生成しても、実際には状態フローを無視していることが多いです。Shim Jae-woo代表の事例：あるチームがCopilotが作った検索フィルターコンポーネントをRedux storeと接続せず、ローカルstateのみ使用しました。結果的に親コンポーネントと状態が不一致となり「ユーザーが検索すると一覧更新されない」バグがプロダクションで1週間放置されました。

なぜ危険か:

•AIは「このコンポーネントの状態フロー」を你の全体storeの構造とマッチングしない

•useSelector・useDispatchなどを見落とし、ローカルuseStateのみ生成する傾向

•コンポーネントリレンダリング最適化(memo・useCallback)を省略するため、性能低下

•実際のAPI連携タイミング(いつdispatchを投げるか)判断をAIができない

•QAが「これはコンポーネント単位テストでは捕捉できない」統合バグを見落としやすい

代替案:

状態管理構造をまずチームが定義(store slice・action・selector一覧)

AIに「このアクションをdispatchしてこのselectorで読め」という明示的指示

統合テスト(Cypress・Playwright)で「状態変化」まで検証

Copilotが生成したコンポーネントはコードレビューで「state flow」を別チェックリストで

要点：状態管理なしのCopilotコンポーネントは「アリバイコード」です。

「うちの既存Spring Bootシステムにおける、Copilotが作ったNode.jsマイクロサービスがあれば良い」という考えは非常に危険です。Sun Woong-gyu代表が見た事例：あるチームがJavaレガシーとAIが生成したPython FastAPIを接続しようとし、データ型変換(Java Long vs Python int)、タイムゾーン処理、トランザクション分離レベルが完全に異なり、結果的に「同期解除」データ破損が発生しました。

なぜ危険か:

•AIは「2つのシステムの既存の契約(contract)」を知らないため、互換性層をまったく作らない

•データシリアル化形式(XML vs JSON)、日付形式、null処理ルールが異なってもAIは「動作するコード」のみ作るだけ

•バージョン管理、マイグレーション戦略(blue-green、canary)のような運用上の配慮はAIコードに無い

•レガシーデータベースview・stored procedureの依存性をAIが見落とす

•後で「なぜこう接続したの？」と聞くと記録が残らない

代替案:

レガシーと新規の間に「アダプター/ブリッジ」層をまず構築(AIの役割ではない)

API契約(OpenAPI/Swagger)を明確に定義してから、AIはそのspec内でのみ実装

統合テストケース(既存データ1,000件+新規ロジック検証)を先に作成

データマイグレーションはAI生成コードより手動検証の比重を70%以上で

要点：レガシーとAIコードの結合は「隔離」が先、統合は後です。

最も静かで危険な副作用です。AIが生成したコードは「見た目は動作するが例外処理が50%」の場合が多いです。Shim Jae-woo代表の経験：あるチームがCopilotでファイルアップロード関数を作成しましたが、メモリリーク(Streamをcloseしない)、同時アクセス処理なし、大容量ファイルの場合タイムアウト処理なしが混在していました。テスト環境では問題が見えず、プロダクションで2週間後にサーバーメモリが80%を占有して障害が起きました。

なぜ危険か:

•AIは「happy path(正常経路)」のみ生成する傾向

•メモリ・リソースリーク、同時性バグはテストでも容易に捕捉されない

•コードレビューが形式的(「Copilotコードは信頼できる」という誤解)なら技術負債暴走

•6ヶ月後「誰がこんな風に書いた？」という質問の時、責任追跡不可能

•ジュニア開発者はAIコードを「最高の例」と考え、同じ間違いを繰り返す

代替案:

AI生成コードは原則として「レビュー時間2倍」を計上

チェックリスト：エラー処理・メモリ管理・同時性・タイムアウト・ロギング必須確認

コード静的分析ツール(SonarQube・ESLint)の強制実行

「AIが作ったからOK」は禁止、手動作成と同等基準を適用

ジュニア教育：「AIコードは0.7の完成度、残りの0.3を君たちが埋める必要がある」

要点：AIコード検証なし＝技術負債を「自動で積み上げる機械」です。

5人の開発者が各自異なるプロンプトでGitHub Copilotを使うと、同じプロジェクトなのにコードスタイルが5種類に分かれます。Sun Woong-gyu代表の事例：あるチームのNode.jsプロジェクトで、関数命名がcamelCase・snake_case・PascalCaseが混在し、エラーハンドリング方式が(try-catch)・(async-await)・(Promise.catch())で縦横無尽でした。結果として新人が入社したときに「このコードは誰が書いたの？」という質問を繰り返し、リファクタリングに2週間を要しました。

なぜ危険か:

•AIが「プロジェクトスタイルガイド」を知らなければ、各プロンプト作成者の習慣で生成

•コード保守コスト急増(一貫性がない＝認知負荷が高い)

•Pull Requestレビューが「スタイル指摘」コメントで埋まる

•オンボーディング時間増加＋バグ再現困難

•自動ポーマッティング(Prettier・Black)設定があっても、AIはロジック部分でスタイルを無視する傾向

代替案:

チームコーディング標準を文書化(関数命名・エラー処理・ロギング形式・コメントスタイル)

Copilot使用前にチームが作成した「良い例」コードを提供

プロンプトテンプレートの標準化：「うちのチームはasync/awaitを使うからPromise.catch()は使うな」

Linter・ポーマッターをCI/CDに強制(pre-commit hook)

AI生成コードもlinter通過後のみmerge許可

要点：AI無しの一貫したコードスタイルがAI生成コードを良くします。

最後の危険は隠れたコストです。「Copilot月10ドル+Claude API月50ドル=月60ドル」で計算すると安く見えます。しかしShim Jae-woo代表の分析によると、AIが生成した「検証されていないコード」による実際のコストは以下の通りです：

•コードレビュー時間2倍：開発者給与基準で月400時間(2名フルタイム)

•技術負債リファクタリング：6ヶ月毎に1週間の全社リファクタリング(チーム5名×40時間=200時間)

•バグ修正時間：AIコードのバグは一般的な手動コードより見つけにくいため平均2倍の時間

•新入社員教育：「AIコードをどう読んで理解するか」教育、週4時間

AXエデュグループの実際のプロジェクト事例では、Copilotを導入したチームは「最初の3ヶ月は速かったが、6ヶ月後の保守コストが手動コーディングチームの1.3倍」でした。投資回収期間：約12ヶ月。

なぜ危険か:

•AIツールコストは「見えるコスト」、技術負債整理は「隠れたコスト」

•「速く作った」という誤解で予算計上失敗

•スタートアップの場合、MVP展開は速くても「その後の拡張」が遅い

•チームが小さいほどレビュー負担が大きいため、実際の効率は逆効果

代替案:

AIツールは「3ヶ月POC(概念実証)」として最初に開始

POC後「コード検証コスト+保守時間」を実際に測定

6ヶ月累積コストが手動コーディングチーム以上なら中断

AIは「スケルトン生成」のみに使用し、コア ロジック・検証・最適化はシニアエンジニア

予算計上時「AIツール費×3倍」をレビュー・負債整理コストとして予約

要点：AIツールの本当のコストは後から現れます。

| 状況 | Claude Code危険度 | GitHub Copilot危険度 | 推奨事項 |
|------|------------------|------------------|--------|
| 金融・医療・政府規制システム | ⚠️⚠️⚠️ 極高危険 | ⚠️⚠️⚠️ 極高危険 | AIツール使用禁止、オンプレミス隔離環境のみ |
| マイクロサービス非同期通信 | ⚠️⚠️ 高危険 | ⚠️⚠️ 高危険 | アーキテクチャを先に定義、負荷テスト必須 |
| 状態管理複雑フロントエンド | ⚠️⚠️ 高危険 | ⚠️⚠️ 高危険 | store構造を先に設計、統合テスト強制 |
| レガシー+新規システム混合 | ⚠️⚠️⚠️ 極高危険 | ⚠️⚠️⚠️ 極高危険 | API契約を先に、隔離層を手動作成 |
| コードレビュー文化が弱いチーム | ⚠️⚠️ 高危険 | ⚠️⚠️ 高危険 | レビュー基準強化、チェックリスト義務化 |
| チームコーディング標準未定義 | ⚠️ 中危険 | ⚠️ 中危険 | スタイルガイドを先に、テンプレート提供 |
| MVP展開後の長期保守 | ⚠️⚠️ 高危険 | ⚠️⚠️ 高危険 | 保守コスト3倍を予算化、6ヶ月再評価 |

Q1：スタートアップなのにCopilot無しでMVP開発が可能ですか？

A：可能です。むしろ推奨します。シニア1名+ジュニア2名のチームなら、Copilot無しで「明確な要件」と「コードレビュー体系」中心で進むのが6ヶ月累積コストで有利です。バイブコーディングは「AI無しで速く」ではなく「明確な設計後に正確に」を意味します。釜山のあるフィンテックチームはCopilotを3ヶ月使ってから止め、代わりにアーキテクチャ文書化と自動テストに投資したら、デプロイ速度が2倍になりました。

Q2：うちのチームが既にCopilotを使っているのですが、今からでも危険を減らせますか？

A：はい、可能です。まず過去3ヶ月間に生成されたAIコードを対象に「セキュリティ・エラー処理・性能」3つの項目だけを特別に再検討してください。その次からは上記で言及したチェックリスト(コードレビュー2倍時間、静的分析、統合テスト)を強制すれば大丈夫です。AXエデュグループがソウル市中区で進めた複数のチーム相談の結果、検証プロセスを整備した後「Copilotの実際の効率が60%まで回復」されました。

Q3：ノーコード(no-code)ツールとAIコーディングは違いますか？どちらも避けるべきですか？

A：全く異なります。ノーコードは「コード自体を書かない」こと(Zapier・Airtable・Bubbleなどのビジュアルビルダー)で、バイブコーディングは「AIがコードを助ける」ことです。ノーコードは非常にシンプルな自動化・データ管理に強いですが、複雑ロジック・性能最適化・セキュリティカスタマイズが不可能です。一方AIコーディングは複雑ロジックも可能ですが、検証責任が開発者にあります。両者を混用するとさらに危険です。MVP開発が目標なら「ノーコードでプロトタイプ」→「検証後AIコーディング転換」の順序が良いです。

Q4：Claude CodesとGitHub Copilotのうち、どちらがより危険ですか？

A：危険の種類が異なります。Copilotは「既存コードと衝突する部分」(つまり、チームのスタイル・ライブラリとマッチしないコード)がより多いです。Claudeは「長文説明を基に」より洗練されたロジックを作りますが、検証無しで「洗練されて見えるバグ」を提示する危険が高いです。セキュリティ観点ではClaudeは「オンラインAPI呼び出し」なのでデータ曝露危険が高く、Copilotは「ローカルコード文脈」をより多く見るので衝突が少ないですが、既存の習慣を繰り返する傾向があります。結論：金融・医療は「両方禁止」、一般システムは「Copilot+強化されたレビュー」、MVP プロトタイピングは「Claudeで構造のみ取得し手動作成」が最適です。

Q5：バイブコーディングが何か正確に理解できましたが、うちのチームがClaudeやCopilot無しでできますか？

A：もちろんです。実際「バイブコーディング」はAIツール自体ではなく「明確な設計→自動化された検証→速いフィードバック」サイクルです。AIツールはそのサイクルを「ちょっと」速くするだけです。AI無しでもバイブコーディングはできますし、むしろAIのせいでバイブコーディングを台無しにする場合も多いです。重要なのは「ツール」ではなく「プロセスと検証文化」です。AXエデュグループのShim Jae-woo・Sun Woong-gyu代表も「バイブコーディングの成功はAIツール選択ではなく、チームのアーキテクチャ設計力とレビュー基準にかかっている」と強調しています。

Claude CodesとGitHub Copilotは確かに強力なツールです。しかしセキュリティ・ア