100万ウォンの失敗、AIに絶対任せてはいけないこと

AIに任せられることと任せられないことの境界が、あなたの差別化です。

100万ウォンの失敗の始まり

昨年、ある創業者がClaude Cursorで決済機能を3時間で実装しました。「ついに完成した」という喜びも束の間、最初のユーザーが決済を完了した瞬間に問題が爆発します。決済応答を処理するコードにAPIキーがハードコードされていたのです。GitHubにコミットされた瞬間、誰かがすでにそのキーを見つけてAPIを好き勝手に呼び出していました。1か月後の請求書は100万ウォンを超えました。

これは他人事ではありません。AIツールが「とても便利」な状態でセキュリティの境界がぼやけるのは自然なこと。問題はAIが便利なことではなく、どこからAIに任せてはいけないかを分かっていない状態で起きます。

委任の境界線、外部依存 vs 内部コア

すべてのコードが同じ重さではありません。あるコードはAIに生成させても大丈夫、あるコードは必ずあなたが自分で見直すべきです。

AIに安全に任せられる領域

「繰り返し可能で、検証可能で、外部に依存しないもの」

• データフォーマット変換(JSON → CSV)
• UIコンポーネントの基本構造(ボタン、カードレイアウト)
• アルゴリズム実装(ソート、フィルタ)
• ドキュメント生成(APIドキュメント、テストケース)

AIに絶対任せてはいけない領域

「委任の結果が直接損失につながるもの」

• セキュリティ関連すべて(認証、暗号化、APIキー管理)
• 決済と金融取引(PG連携、為替計算、取引記録)
• 個人情報の処理(ユーザーデータの保存、照会、削除)
• ドメインのコアロジック(あなたのビジネスの競争力)
• 法的遵守事項(約款、個人情報処理方針、コンプライアンス)

境界をはっきりさせると2つの利点があります。第一に、AIがやることが明確になり、プロンプトの精度が上がる。第二に、何か起きたときに責任の所在が明確になる。「AIが間違って作りました」は通用しません。

セキュリティの境界、AIが作ったコードはなぜ破られるか

AI生成コードでもっとも頻発するセキュリティ脆弱性はAPIキーと認証トークンの漏洩です。Trend Microの研究によれば、ChatGPT生成コードの相当数がハードコードされたAPIキーを含んでいました。「決済APIを繋いで」と頼むと、AIはもっとも簡単な方法、つまりソースに直接入れる方法を提示することが多い。

「開発環境でテストするだけだから大丈夫」がいちばん危険です。一度コミットされたコードはGitHub履歴に永遠に残ります。

2023年のGoogle APIキー事件もありました。開発者たちが公式ガイドに従ってAPIキーを設定したのに、Googleがシステムを変えてキーがGemini認証トークンとして機能するようにしてしまった。結果は? 数億ウォン台の無断課金。

韓国の状況はもっと複雑。PG(決済代行)連携時、各社のセキュリティポリシーがすべて異なります。Toss Payments、NHN KCP、NICE Payments等の決済APIはドキュメントはあるけれど、正確なセキュリティガイドは電話相談でしか得られない場合が多い。AIに「決済機能を作って」と頼むと、一般的なパターンに従うだけで、それがあなたのPGの規約違反になる可能性もあります。

決済とセキュリティは「だいたい動く」レベルでは絶対NG。1%のミスが100万ウォンの損失に直結します。必ず専門家(PG技術チームか決済の専門エンジニア)と一緒にレビューし、そのあとでAIの助けを借りてください。

ドメインコア、あなたのunfair advantageはここから

「AIが作れないものは何?」と多くの人が聞きます。答えはシンプル。あなたのドメインのコアロジックです。

たとえばあなたのアプリが「肌タイプ別コスメ推薦」なら、コアロジックは「ユーザー入力を肌タイプに正確に分類するアルゴリズム」。AIは一般的な分類アルゴリズムを作れますが、「敏感肌で反応性が高い人」のような微妙な境界ケースまで正確に判断するには、あなたが直接、肌の専門家と相談してルールを定義する必要があります。

EC例:

• AIにできること: 商品リストUI、検索フィルタ、レビュー表示形式
• AIにやらせてはいけないこと: 手数料計算ロジック、返金ポリシー判断、在庫管理ルール

なぜ? そのルールがあなたの競争力でありビジネスモデルだから。AIは「一般的な」ECロジックは作れますが、「あなたの」ECロジックは作れません。

自分でビジネスロジックを理解していないと、最初のユーザーに会った瞬間に問題が爆発します。初期10人のフィードバックがいちばん貴重なのに、「なぜこう作ったか」を説明できないと対応速度が落ちます。

デザインの目、一貫性は人が守る

UIコンポーネント1つ1つはAIが完璧に作れます。でもそれらを束ねたときの一貫性はAIには保証できません。

デザインシステムは「一貫した体験を作るルールの集合」。Figmaで定義したフォントサイズ、色、余白、角丸を、すべての画面で正確に実装する必要があります。

• ボタン基本高さ44px → すべてのボタンが44px
• ヘッダーフォントPretendard 16px Bold → すべてのヘッダーが同じ規格
• 余白は8px単位 → 12px余白はNG

AIが生成したコンポーネント10個は、個々には論理的に正しくても、並べると調和しない可能性が高い。AIは「前に作ったボタン」を完璧には覚えていないからです。

実戦デザイン一貫性の4段階

1. Figmaでコンポーネントライブラリを先に作る
2. AIに「このFigmaファイルのコンポーネントを基に」と指示
3. 実装されたコードを原本デザインと並べて比較(DevToolsで色や余白を測る)
4. 不一致部分を明示的に修正指示

委任禁止チェックリスト

まとめ

この記事の核心は「境界を引く」こと。AIができないのではなく、やらせてはいけないことを明確にすることが本当の優位です。あなたのアプリが「速く作られた平凡なアプリ」になるか、「遅いけれど差別化されたアプリ」になるかは、この境界をどう引いたかで決まります。

次の記事ではリリース直前の最後の関所を扱います。作ったものより、抜け落としたものがもっと多く事業を潰す理由と、それを避けるためのリリース前チェックリストです。

参考資料

1. Security Vulnerabilities of ChatGPT-Generated Code — Trend Micro(2023)
2. 生成AI開発・活用のための個人情報処理ガイドライン — 韓国個人情報保護委員会(2025)
3. AIエージェントのセキュリティ脆弱性、ハードコードAPIキー問題 — MegaZone Soft
4. Codex Command Injection Vulnerability — OpenAI Security Blog(2026)
5. Toss Payments MCP公式ガイドおよび開発者コミュニティ事例(2026)

前の記事:エンジニア向けAIビルドコース
次の記事:作ったものより抜けたほうが高くつく、リリース前チェックリスト

キム・ミンチュル、Freeive CEO、フェイルスクール