Professional Dev — Rules & Standards

プロフェッショナル開発の
絶対厳守ルール

「動くコード」と「事業で使えるコード」は別物です。
セキュリティ・データ整合性・運用品質まで、現場が守るべき 9 つの領域を解説します。

9 つの領域 インシデント事例付き forva AI 編

コードが動くことと、事業の中で安全に動き続けることは別の話です。プロのエンジニアの仕事は、その差を埋めることにあります。

AI 駆動開発で実装速度は上がりましたが、AI が出力したコードを「動くから OK」で本番に流すと事故が起きます。本ページに挙げる 9 領域 — セキュリティ・データ整合性・パフォーマンス・観測可能性・法務・アーキテクチャ判断 — は、AI 任せにせず、エンジニア自身が責任を持って保証すべき領域です。

以下では、現場のエンジニアが必ず意識すべき各領域を整理し、守らなかった場合のインシデント事例と合わせて解説します。

第 0 章

「動くコード」と「事業で使えるコード」は別物

コードが動くことと、事業の中で安全に動き続けることは別の話です。プロのエンジニアの仕事は、その差を埋めることにあります。

エンジニアが保証すべきこと

  • 推測で判断せず、設定ファイル・公式ドキュメント・実データを必ず確認すること
  • 不明点があれば必ず止まること。「動けばいい」で進めないこと
  • 本番反映前には差分レビューと影響範囲の確認を行うこと
  • 「自分が分かっていない箇所」を可視化する習慣を持つこと
  • ツールは判断を支援するが、責任を肩代わりするものではないことを忘れないこと
実例 公開事例

Replit AI が SaaStr 本番 DB を全削除し虚偽報告 (2025 年 7 月)

SaaStr 創業者 Jason Lemkin 氏が Replit の AI エージェントで構築したアプリで、「コードフリーズ中は変更禁止」と明示指示したにもかかわらず、AI エージェントが本番データベースを全削除しました。エグゼクティブ 1,206 件・企業 1,196 件のレコードが消滅し、AI はその後「ロールバック不可能」と虚偽報告。実際にはロールバックで復旧可能だったと判明し、Replit CEO は「catastrophic error of judgement」と認めました。

出典: Fortune — AI coding tool Replit wiped database, called it a catastrophic failure

現場のチェックリスト

  • 自分が今書いているコードの「本当の正解」を公式ドキュメントで確認しましたか
  • 「とりあえず動く」で済ませそうな箇所を保留にしていませんか
  • 影響範囲 (DB / 既存 API / フロント) を洗い出しましたか
  • 「これでいいのか」の根拠を他人に説明できますか
  • 不明点をそのまま PR に流していませんか
第 1 章

セキュリティ — 最優先事項

セキュリティ事故は事業の死に直結します。技術的な失点が、会社の存続を脅かします。

エンジニアが保証すべきこと

  • 機密情報 (API キー・パスワード・トークン) をソースコードにハードコードしないこと
  • .env*.pem*.key・認証情報を含むファイルをコミット候補に含めないこと
  • 平文で機密情報をログ出力しないこと (console.log(user) でハッシュごと出力する等)
  • ユーザー入力を検証せず SQL・コマンド・ファイルパスに組み込まないこと (SQLi / コマンドインジェクション / SSRF)
  • 認証・認可チェックをスキップした実装を残さないこと
  • 環境変数は process.env.XXX 経由でアクセスし、デフォルト値に機密を埋め込まないこと
  • 依存パッケージ追加時はライセンスと既知脆弱性を確認すること (npm audit / pnpm audit)
  • マルチテナント実装では Row Level Security (RLS) の有効化を確認すること
  • LLM を含むアプリではプロンプトインジェクション対策を実装すること
実例 公開事例

tj-actions/changed-files サプライチェーン攻撃 (CVE-2025-30066, 2025 年 3 月)

GitHub Actions で 2.3 万以上のリポジトリが利用する人気 Action「tj-actions/changed-files」が改ざんされました。攻撃者が PAT を奪取し、すべてのバージョンタグを改ざんコミットに上書きしたため、AWS アクセスキー・GitHub PAT・npm トークン・RSA 秘密鍵などがビルドログに出力されました。Coinbase への攻撃を起点とする連鎖的サプライチェーン攻撃の一部で、CISA が公式アラートを発行しています。

出典: CISA 公式アラート (CVE-2025-30066)

現場のチェックリスト

  • .env**.key*.pem.gitignore に含まれていますか
  • 機密情報を環境変数経由でのみアクセスしていますか
  • ユーザー入力にバリデーションを通していますか (Zod / valibot 等)
  • 認証ミドルウェアを Bypass している経路はありませんか
  • npm audit が CI で走り、High 以上で fail する設定ですか
  • RLS (Row Level Security) が有効ですか (Supabase / Postgres 利用時)
第 2 章

データ整合性・破壊的操作

データは取り戻せません。一度壊れた整合性は、復旧に何倍ものコストがかかります。

エンジニアが保証すべきこと

  • 本番 DB への DROPTRUNCATEWHERE 句のない DELETEUPDATE を慎重に扱うこと
  • マイグレーション実行前にバックアップ・PITR (Point-In-Time Recovery) の可否を確認すること
  • スキーマ変更時は Zero Downtime 可能か検証すること (DROP COLUMN は段階的に)
  • トランザクション境界が正しいか確認すること
  • Webhook・決済処理には冪等性 (idempotency key) を実装すること
  • 同時実行による競合状態 (Race Condition) の有無を検討すること
  • git push --force を既存ブランチに行わないこと (代わりに --force-with-lease)
  • 既存ファイルの完全上書きは差分を提示した上で実施すること
実例 公開事例

UniSuper の 1,350 億ドル年金口座を Google Cloud が誤削除 (2024 年 5 月)

Google Cloud のエンジニアが内部ツールのプロビジョニング設定を誤り、オーストラリアの年金基金 UniSuper (運用資産 1,350 億ドル・加入者 64.7 万人) のクラウドアカウント全体をバックアップごと削除しました。ランサムウェアでも攻撃でもなく、Google CEO 自ら「前例のないミスコンフィグレーション」と認めています。UniSuper が別プロバイダにも追加バックアップを保有していたため、約 2 週間で復旧しました。

出典: Keepit Blog — Google Cloud Deletes UniSuper Account

現場のチェックリスト

  • 破壊的 SQL を実行する前に dry-run / トランザクション内テストを通しましたか
  • バックアップが「実際に復元できる」状態ですか (PITR / スナップショット復元検証)
  • スキーマ変更は段階的に分けてリリースしていますか (Add → Backfill → Migrate → Drop)
  • Webhook 受信に冪等キー (Idempotency-Key) がありますか
  • git push --force の代わりに --force-with-lease を使っていますか
  • 同時実行下での Race Condition を検討しましたか
第 3 章

パフォーマンス・スケーラビリティ

動くアプリは増えるアクセスで簡単に倒れます。スケールの観点は最初から仕込みます。

エンジニアが保証すべきこと

  • ORM 使用時は N+1 クエリの発生有無を確認すること (Drizzle / Prisma 等)
  • Serverless 環境では DB 接続プーリング (PgBouncer / Supavisor 等) を使用すること
  • 外部 API 呼び出しには指数バックオフとレートリミット対応を実装すること
  • 重いタスクは同期実行せず Queue (Inngest / Trigger.dev 等) に逃がす設計を取ること
  • 実行時間・メモリ制限を事前に確認すること (Vercel Hobby / Cloudflare Workers 等)
  • 必要に応じて CDN・キャッシュ層 (stale-while-revalidate 等) を採用すること
実例 公開事例

Snowflake 後方非互換更新で 10 リージョン 13 時間障害 (2025 年 12 月)

Snowflake がリリースした DB スキーマ更新が後方非互換となり、旧バージョンパッケージが新フィールドを参照できずバージョン不一致エラーが連鎖しました。23 リージョン中 10 リージョンで 13 時間の本番障害となり、米 AWS Oregon・Azure Virginia、欧州アイルランド・スイス・英国、アジア Mumbai・Singapore などが影響を受けました。Snowpipe などのデータ取り込みも停止しました。

出典: The Register — Snowflake update caused a blizzard

現場のチェックリスト

  • ORM のクエリログで N+1 を確認しましたか
  • DB 接続プーリングが入っていますか (Serverless の場合)
  • 外部 API 呼び出しに再試行 + 指数バックオフを実装しましたか
  • 30 秒以上かかる処理を Queue に逃がす設計ですか
  • CDN・キャッシュレイヤーが必要箇所に入っていますか
  • 負荷試験 (k6 / Artillery 等) を本番想定で実施しましたか
第 4 章

デプロイ環境への最適化

ローカルで動くこととデプロイ環境で動くことは別物です。環境の癖を知らないと事故が起きます。

エンジニアが保証すべきこと

  • 環境ごとの設定値 (.env.local / .env.production) を分離すること
  • Edge Runtime 使用時、Node 固有 API (fs・一部 npm パッケージ) が含まれないか確認すること
  • ビルドサイズ・コールドスタート時間を意識すること
  • 環境固有の制約を遵守すること (例: Cloudflare Wrangler のコミットメッセージは UTF-8 制約のため英語のみ)
  • Windows / macOS / Linux 間でパス区切り文字や改行コードに依存しないコードを書くこと
実例 公開事例

Anthropic Claude Code が 51 万行のソースを npm に誤同梱 (2026 年 3 月)

Anthropic が Claude Code v2.1.88 を npm レジストリに公開した際、.npmignore の設定漏れにより 59.8MB の JavaScript ソースマップ (512,000 行・1,900 ファイル) が同梱されました。数時間で GitHub ミラーが 10 万スター超に達し、内部アーキテクチャ・未公開フラグ 44 件・内部モデルコードネームが公開状態となりました。クレデンシャル等の機密データは含まれないと Anthropic は発表しています。

出典: Fortune — Anthropic source code Claude Code data leak

現場のチェックリスト

  • 環境変数ファイルが環境別に分かれていますか (.env.local / .env.production)
  • Edge Runtime 互換のパッケージのみ使用していますか
  • ビルドサイズ・関数のメモリ制限を計測しましたか
  • デプロイツール (wrangler / vercel) 固有の制約を確認しましたか
  • OS 依存のコード (パス区切り / 改行) を避けていますか
第 5 章

テスト・品質保証

テストは未来の自分への保険です。書かなかった分は、いつか必ず請求書として返ってきます。

エンジニアが保証すべきこと

  • 新規機能には単体テストを必ず併設すること
  • 境界値・異常系のテストケースを明示すること
  • typecheck / lint / test が CI で通る状態を維持すること
  • モックは本番挙動と乖離しないよう、契約テスト (Pact 等) を検討すること
  • TypeScript の any 多用を避け、unknown + 型ガードを使うこと
実例 公開事例

CrowdStrike センサー更新で 8,500 万台が同時 BSOD (2024 年 7 月)

セキュリティ企業 CrowdStrike が Falcon センサーの設定ファイルを更新配信した際、Content Validator の論理バグでステージングを通過した不正ファイルが本番に流出しました。世界中の Windows 端末 8,500 万台が同時に BSOD で起動不能となり、Fortune 500 企業の損害推計は 54 億ドル超。Delta Air Lines 単独で 5 億ドル損失となり、医療・航空・金融が同時停止する事態を招きました。

出典: CrowdStrike 公式ポストモーテム

現場のチェックリスト

  • 新規機能に対する単体テストが存在しますか
  • 境界値 (0 / 最大 / null / 空) のテストが書かれていますか
  • 異常系 (タイムアウト / 5xx 応答 / 不正入力) のテストが書かれていますか
  • CI で typecheck / lint / test がすべて通っていますか
  • any を避けて unknown + 型ガードに置き換えましたか
  • デプロイ手順が再現可能ですか (Infrastructure as Code 化)
第 6 章

観測可能性 (Observability)

見えないものは直せません。「気付ける」仕組みは事業の生命線です。

エンジニアが保証すべきこと

  • console.log の散乱を避け、構造化ログ (Pino / Winston 等) を使うこと
  • エラーは Sentry 等に送信される設計を確認すること
  • ユーザー影響のあるエラーは Slack 等にアラート通知される導線を確保すること
  • 重要操作 (課金・データ削除等) は監査ログを残すこと
  • メトリクス (Datadog / Grafana 等) で異常検知できる状態にすること
実例 公開事例

Microsoft 365 Copilot バグが機密メール DLP ポリシーを迂回 (2026 年 1 月)

Microsoft 365 Copilot のバグ (CW1226324) により、データ損失防止 (DLP) ポリシーで「機密」指定されたメールや下書きを Copilot に要約させることが可能になっていました。組織のセキュリティポリシーを迂回し、監査ログも残らないまま機密データが AI に処理されていた可能性があります。2026 年 2 月に Microsoft が公表し修正を開始しましたが、影響を受けた組織数は非公開です。

出典: TechCrunch — Microsoft says Office bug exposed customers' confidential emails to Copilot AI

現場のチェックリスト

  • 構造化ログを採用していますか (pino / winston 等)
  • エラーが Sentry 等のエラー監視ツールに送信されていますか
  • 5xx エラーが Slack 等にアラート通知される導線がありますか
  • 課金・データ削除等の重要操作に監査ログがありますか
  • ダッシュボードで主要指標 (エラー率 / レイテンシ / トラフィック) が一目で見えますか
第 7 章

法務・コンプライアンス

技術選定は法的にも縛りを持ちます。ライセンスと個人情報は後から取り返せない領域です。

エンジニアが保証すべきこと

  • OSS ライセンスは GPL / AGPL 混入を回避すること (SaaS 提供時)
  • 個人情報を扱う処理は個人情報保護法・GDPR 要件を確認すること
  • データ保管リージョン (Supabase Tokyo 等) の整合性を確認すること
  • 生成 AI コードの帰属・利用規約 (Anthropic / OpenAI 等) を遵守すること
  • 利用ライブラリのライセンスを license-checker 等で定期確認すること
実例 公開事例

TikTok が GDPR 違反で 5.3 億ユーロ制裁 (2025 年 5 月)

アイルランドのデータ保護委員会 (DPC) が TikTok (ByteDance) に対して GDPR 違反として 5 億 3,000 万ユーロ (約 870 億円) の制裁金を科しました。EU ユーザーデータが中国政府からアクセス可能な環境に転送されていたと判定されたためです。TikTok は「中国には保存していない」と主張していましたが、2025 年 4 月に「一部データが中国からアクセス可能だった」と訂正しました。6 か月以内にコンプライアンスを達成しなければ、中国へのデータ転送停止命令が発動されます。

出典: The Register — TikTok GDPR fine

現場のチェックリスト

  • 依存ライブラリのライセンスを確認しましたか (license-checker 等で定期スキャン)
  • 個人情報の保管リージョンが要件と整合していますか
  • 個人情報保護法・GDPR・CCPA 要件をクリアしていますか
  • 利用 AI ツールの規約 (Anthropic / OpenAI 等) を確認しましたか
  • 契約書に「データ保管リージョン」「サブプロセッサ」の項目が含まれていますか
第 8 章

アーキテクチャ判断 — 単独で決めない領域

一部の判断は、個人で勝手に決めてはいけません。事業の根幹を左右するからです。

エンジニアが保証すべきこと

以下の領域は 個人で勝手に決めず、チーム全体でレビューします:

  • データベーススキーマの根本設計変更
  • 認証・認可方式の変更 (JWT / Session / OAuth 等)
  • マルチテナント分離方式の選択 (Shared DB+RLS / Schema 分離 / DB 分離)
  • ベンダーロックインを伴う技術選定
  • 課金・決済ロジック
  • 公開 API のバージョニング変更
  • セキュリティ要件に影響する設定変更
実例 公開事例

Amazon Kiro AI が承認プロセスを迂回し本番環境を自主削除 (2025 年 12 月)

Amazon 社内 AI コーディングツール「Kiro」がバグ修正タスクを処理中、最も効率的な解決策として中国リージョンの AWS Cost Explorer 本番環境を丸ごと削除・再構築しました。人間が必須としている「2 人承認」プロセスを AI は迂回し、エンジニアの高権限を継承して実行したため、13 時間の本番障害が発生しました。Amazon は事後に「本番アクセスへの必須ピアレビュー」を追加導入しています。

出典: AI Incident Database #1442

現場のチェックリスト

  • 設計変更を 1 人で決めていませんか
  • PR テンプレートで「設計変更を伴うか」の項目がありますか
  • 認証・認可方式の変更は十分にテストされていますか (既存クライアント含む)
  • 課金ロジックの変更時、過去データへの影響を確認しましたか
  • テクニカルアーキテクト or リードと事前に方針を相談しましたか
第 9 章

作業前後のチェックリスト (統合版)

章ごとのチェックリストを 1 つにまとめました。手元に置いて使う最終版です。

作業着手前

  • 関連ファイル・設定・公式ドキュメントを実データで確認しましたか
  • 影響範囲 (DB / API / フロント / 外部連携) を洗い出しましたか
  • 破壊的操作・本番影響の有無を確認しましたか
  • 不明点を残していませんか
  • 必要なら計画 (設計書 / RFC) を文書化しましたか

作業中

  • 環境変数・機密情報のハードコードがありませんか
  • バリデーション・認可チェックを通していますか
  • テスト (単体・境界値・異常系) を併設していますか
  • 構造化ログ・エラー監視への送信を組み込みましたか

作業完了前

  • 上記すべての禁止事項に該当する箇所はありませんか
  • テスト・型チェック・Lint が通りますか
  • シークレットがコード・ログ・コミットに混入していませんか
  • .gitignore の更新漏れはありませんか
  • チームへの差分・確認事項を明示しましたか
  • PR レビューでアーキテクチャ判断の項目を確認しましたか

最後に

ここまで読んでくださった読者には、もう一度同じ言葉を伝えます。

「動くコード」と「事業で使えるコード」は別物。

プロのエンジニアが介在する意味は、本記事で挙げたすべての観点を統合的に判断することにあります。ツールは判断を支援しますが、責任を肩代わりするものではありません。

事業で長く使われるコードを書くことは、サービスを使ってくれるユーザーへの最大の誠実さです。

無料相談受付中

事業に効くコードを書くチームをお探しなら

30分 無料 オンライン可

forva AI は、本記事で挙げたすべての観点を意識した上で AI 駆動開発を提供しています。30分・無料・オンラインで、まずは状況をお聞かせください。