AI駆動型ソフトウェア開発（AI-Driven SDLC）実践ガイド：精度と信頼性を最大化する戦略的アプローチ

これはNotebookLMとGeminiを使って執筆された文書だよ。
状況によって情報は古くなるから注意しようね。

1. イントロダクション：AIコーディングの現状と「Vibe Coding」からの脱却

2026年現在、AIはソフトウェアエンジニアリングの現場における単なる補完ツールから、リポジトリ全体を理解して自律的にタスクを遂行する共同作業者へと進化しました。
これに伴い、開発者の役割はコードを1行ずつ打ち込む「Typist（入力者）」から、AIエージェントを指揮・監視する「Architect（設計者）」や「Orchestrator（オーケストレーター）」へと劇的なパラダイムシフトを遂げています。

しかし、この急速な進化の裏で、自然言語のプロンプトだけで感覚的に開発を進める「Vibe Coding（バイブ・コーディング）」の深刻な副作用が顕在化しています。

METRが経験豊富なオープンソース開発者を対象に実施したランダム化比較試験（RCT）では、非常に示唆に富む結果が報告されました。
開発者は「AIツールを使うことで生産性が24%向上する」と事前に知覚していたにもかかわらず、実際の実務においては19%遅くなっていたのです。
構造化されていないAI利用は、プロフェッショナルな現場に以下のような戦略的負債をもたらします。

• 知覚的生産性の罠：
  短期的なコード生成速度の向上に錯覚し、システム全体の整合性、アーキテクチャの妥当性、長期的な保守性が犠牲になる
• 技術的・セキュリティ負債の爆発的蓄積：
  非決定的（非決定論的）なAIの出力に依存することでシステム内のエントロピーが増大し、リファクタリング、デバッグ、セキュリティパッチに要する時間が指数関数的に増加する
• 運用の断片化とレビュー疲労：
  プロンプトやコード規約が個人の「ノリ（Vibe）」に委ねられることでチーム内の再現性が失われる。さらに、AIによる大量のコード追加によって、レビュー負荷が劇的に増大する「意思決定疲労（Decision Fatigue）」を引き起こす

本ガイドでは、これらのリスクを排除し、AIの圧倒的な生成速度を安全に制御するための戦略的アプローチとして、「仕様駆動開発（Spec-Driven Development: SDD）」および体系的なコンテキスト管理のベストプラクティスを提示します。

2. 構造化されていないAI利用の代償：データが示すセキュリティと品質の真実

AIによるコード生成速度を無批判に追求することは、組織にとって致命的なセキュリティリスクと経済的損失を招きます。Veracodeの「2025 State of Software Security」やCodeRabbitの分析データは、監視なきAI導入の冷酷な現実を浮き彫りにしています。

AI生成コードの脆弱性実態と発生率

最新の調査において、AIが生成したコードの45%に何らかのセキュリティ脆弱性が含まれていることが判明しました 。これは人間が手作業で書いたコードの脆弱性率（約25〜30%）と比較して約1.5倍から1.7倍に相当します。
さらに、 CodeRabbitが470件のプルリクエスト（PR）を対象に行った分析では、AI生成コードは人間のみによるコードと比較して「総問題数で1.7倍」「セキュリティ固有の問題で2.74倍」多くの欠陥を含んでいることが確認されています。

代表的な脆弱性タイプ（CWE）ごとの実態は以下の通りです。

• SQLインジェクション (CWE-89)：
  合格率 80% / 脆弱性発生率 20% AIが生成したコードの5件に1件が、不適切なクエリ構築によりデータベースを不正アクセスの危険にさらす可能性を孕んでいます
• 不適切な暗号化アルゴリズム (CWE-327)：
  合格率 86% / 脆弱性発生率 14% ハードコードされた暗号化キーや、非推奨となった古い暗号化プロトコルの実装が頻出します
• クロスサイトスクリプティング / XSS (CWE-80)：
  合格率 86% / 脆弱性発生率 14% 入力値の適切なサニタイズや出力エンコーディングが省略されやすく、Webアプリケーションをスクリプトインジェクションの脅威にさらします
• ログインジェクション (CWE-117)：
  合格率 88% / 脆弱性発生率 12% ログ出力処理において入力検証が欠落し、攻撃者によるログの改ざんやログポイズニングを許す実装が見られます

文脈盲目性（Context Blindness）と技術スタック別の傾向

AIがセキュアでないコードを生成する根源的な理由は、モデルの「文脈盲目性」にあります。
AIは局所的な統計的尤度に基づいてコードを出力するため、システム全体のアーキテクチャ、認証レイヤーの構造、あるいはデータ分類のルールといった手続き間分析（インタープロシージャル分析）を伴う文脈を把握できません。

プログラミング言語によってもセキュリティパス率には大きな開きが存在します。

• Java (合格率 29%)：
  サーバーサイドとしての歴史が長く、学習データに古い設計パターンが多く含まれることや、Spring Security等の複雑なエンタープライズフレームワークの依存関係をAIが誤認しやすいことが主因です
• Python (合格率 62%)：
  データサイエンスや科学計算等のクリーンな学習データが多く、標準的なセキュリティパターンがシンプルであるため比較的良好な結果を示します
• JavaScript / TypeScript (合格率 57%)：
  クライアントサイドとNode.jsの両方で利用されるため、XSSやDOM操作、サーバーサイドのインジェクションなど多面的なリスクにさらされます
• C# (合格率 55%〜65%)：
  .NETフレームワークが提供する強力なガードレールの影響により、最新モデルでは合格率が向上する傾向にあります

ここで特筆すべきは、モデルの「規模（パラメータ数）」よりも「推論アーキテクチャ」がセキュリティ品質に決定的な影響を与えるという点です。

単一のフォワードパスでコードを生成する標準モデルに対し、出力前に内部推論（内部コードレビューのような自己検証）を行うGPT-5等の推論（Reasoning）モデルは70%〜72%と高いセキュリティパス率を記録しました（非推論モデルは52%）。

経済的インパクト：セキュリティ負債の増大

技術的負債が開発速度を鈍化させるのに対し、セキュリティ負債はシステムを攻撃にさらし、組織の存立を脅かします。
この負債の解消コストは、開発フェーズが後ろに倒れるほど幾元級数的に跳ね上がります。

• 開発段階（コード執筆中）の修正: 1件あたり 約 $50
• デプロイ後（本番環境導入後）の修正: 1件あたり $500 〜 $5,000
• セキュリティ侵害・漏洩発生後の対応: 1件あたり $50,000 以上

AIによって月間10,000件以上の新規脆弱性がコードベースに混入している実態を鑑みると、人間の監視や自動化された監査なしにAIを運用することは、致命的な経済的リスクを積み上げる行為に他なりません 。

3. 仕様駆動開発（Spec-Driven Development）：希望通りの結果を得るための核心

「コードは副産物であり、仕様書こそが真実のソース（Single Source of Truth）である」 ――このアプローチこそが、AI駆動型ソフトウェアエンジニアリングを制御する核心となります。

AIエージェントにコードを生成させる前に、人間とAIが協力して構造化された仕様を定義し、その仕様書をコンパイルするように実装を導く手法が「仕様駆動開発（Spec-Driven Development: SDD）」です。

SDDの核心原則とVibe Codingとの対比

Vibe Codingが自然言語による場当たり的なプロンプトと反復によってコードを生成するのに対し、SDDはOpenAPI、AsyncAPI、JSON Schema、Markdown等のフォーマルで機械可読な仕様書を先に作成します。

この仕様書がGitリポジトリ上で一元管理され、コード生成、テスト作成、ドキュメント生成、さらにはAIエージェントの推論の絶対的な基準となります 。これにより、AIが勝手にアーキテクチャや依存関係を捏造するハルシネーションを抑止し、人間が設計意図を完全にコントロールすることが可能になります。

習熟の3段階（Thoughtworks定義）

ThoughtworksのBirgitta Böckelerは、SDDの成熟度を以下の3つの段階（ラダー）として定義しています。

• レベル1：Spec-first（仕様最優先）
  開発の起点として綿密な仕様書を記述し、それをAIエージェントに与えてコードを実装させる段階
  機能実装が完了した後、その仕様書は必ずしも保守され続けるとは限りません
• レベル2：Spec-anchored（仕様固定）
  機能実装後も仕様書を永続的なドキュメントとしてリポジトリに保持する段階
  仕様変更や機能追加が発生した際は、まず仕様書を更新し、その差分に基づいてAIに実装を修正させることで、コードと仕様の乖離（ドリフト）を防ぎます
• レベル3：Spec-as-source（仕様＝ソースコード）
  人間が直接編集する唯一の成果物が「仕様書」となる究極の到達点
  ソースコードは仕様書からコンパイル（生成）される出力物として扱われ、人間がコードを直接手動で修正することは原則として行いません

SDDを導入することで初期設計のオーバーヘッドは発生しますが、仕様、テスト、モックサーバーが単一のソースから派生するため、リファクタリングや仕様変更を伴うその後の開発フェーズの速度と品質は劇的に向上します。

4. コンテキスト管理の最適化：.cursorrulesとAGENTS.mdによる執行

明確に定義された仕様（What）をAIエージェントに正しく実装させるためには、チームの規約、アーキテクチャ方針、セキュリティ基準（How）をAIに強制する「執行メカニズム（Enforcement Mechanisms）」が必要です。これを担うのが、プロジェクト内に配置するコンテキスト管理ファイルです。

現在、開発環境やツールごとに複数の設定ファイル形式が共存していますが、それぞれ役割と適用スコープが明確に異なります。

主要コンテキスト設定ファイルの役割と特徴

• AGENTS.md（Linux Foundation主導の業界標準）
  Linux FoundationのAgentic AI Foundationが管理するオープン標準フォーマットです
  特定のツールに依存せず、Codex CLI、Cursor、Claude Code（フォールバック時）、Continue.devなど、準拠するあらゆるAIエージェントが読み込む「プロジェクト全体のエージェント向けREADME」として機能します
  プロジェクトの概要、使用するパッケージマネージャー、ビルド／テストコマンドなど、普遍的なルールを一元管理します
• AGENTS.override.md（ローカル専用オーバーライド）
  Codex CLIなどでサポートされているローカル環境専用のルールファイルです
  Gitリポジトリにはコミット（追跡）させず、個人の開発環境固有のパス設定、個人的なワークフローの調整、あるいは一時的な実験フラグなどを記載するために使用します
• .cursor/rules/*.mdc（Cursor専用の動的ルール）
  Cursorが採用するMDC（Markdown+）形式のルールファイルです
  プロジェクトの規約を細分化して .cursor/rules/ ディレクトリに配置し、それぞれのルールに対して「Always On（常時適用）」、「Auto Attached（ファイル生成・編集時に自動添付）」、「Model Decision（AIが関連性を判断して動的に読み込み）」という適用スコープを設定できます
• CLAUDE.md（Claude Code専用ルール）
  Claude Codeがセッション開始時に優先的に読み込む設定ファイルです
  Bashコマンドの実行ルール、プロジェクトの構造、コードスタイル、ワークフローの制約などを定義します
  他のエージェントも利用するプロジェクトでは、AGENTS.md を共通の真実のソースとし、CLAUDE.md からシンボリックリンクまたはインポートで参照する構成が推奨されます
• Windsurf rules（.windsurfrules / .windsurf/rules/*.md）
  Cognition（旧Codeium）のWindsurfが読み込む規約ファイルです
  AIモデルがコード生成やCascadeエージェントを実行する際のコンテキストとして機能します

インストラクション・バジェット（指示予算）と階層的発見プロセス

設定ファイルを運用する上で避けて通れない制約が「インストラクション・バジェット（指示予算）」です。
最新の研究によれば、フロンティアレベルのLLMであっても、一度のセッションで確実に遵守できる独立した指示の数はおおよそ150〜200個程度が上限とされています。

ルールファイルが肥大化してこの予算を超えると、モデルの注意力が分散し、重要な指示をランダムに無視する「インストラクション・ドリフト」や性能低下を引き起こします。この問題を解決するのが「段階的開示（Progressive Disclosure）」と「階層的発見プロセス」です 。

• 段階的開示（Progressive Disclosure）の徹底
  ルートディレクトリのファイル（AGENTS.md や CLAUDE.md）には、300行以内（または6KB程度）の極めて重要な最小限の指示のみを記述します
  詳細な言語規約、テスト実装定石、デプロイ手順などは docs/TYPESCRIPT.md や docs/TESTING.md のような別ファイルに分割し、必要に応じてトリガー条件やエージェントスキルを通じて動的に読み込ませます
• 階層的発見プロセス（Hierarchical Discovery）
  Codex CLIやClaude Codeは、プロジェクトのルートディレクトリからカレントディレクトリに向かって階層的に設定ファイルを探索・マージします（より近いディレクトリのルールが優先されます）
  フロントエンドのディレクトリにはReact固有のアンチパターン禁止ルールを、バックエンドにはAPIバリデーション方針を記述したファイルを配置することで、トークン消費を最小限に抑えながら極めて高い精度でAIを制御できます

5. エージェント機能を最大限に引き出す実践的ワークフロー

AIエージェントは単なるチャットボットではありません。ツールを呼び出し、環境を操作し、自律的にコードを書き換える強力なエンジンです。この馬力を完全にコントロールするための実践的ワークフローを解説します。

Plan Modeによる事前計画の徹底

大規模な機能追加や、10ファイル以上にまたがる複雑なリファクタリングを行う際、いきなりエージェントにコードを書かせることは失敗の元です 。実装の前に、必ず「Plan Mode（計画モード）」を起動してください 。

1. 探索と調査：
   エージェントがコードベース全体をセマンティック検索し、関連ファイルと依存関係を洗い出します
2. 計画案の作成：
   AIがMarkdown形式で実装ステップ、変更対象ファイル、影響範囲をリストアップした「計画書」を作成します
3. 人間による介入と承認：
   開発者はこの計画書をレビューし、「このファイルは変更不要」「この処理は既存のミドルウェアを再利用して」といった指示をインラインで直接編集・修正します
4. 自律実行：
   計画が完全に合意に達した段階で承認を出し、エージェントにステップバイステップで実装を遂行させます

この「実行前の合意形成」により、AIによる意図しないコードの破壊や手戻りを劇的に削減できます。

MCP（Model Context Protocol）を活用した動的コンテキストの統合

MCP（Model Context Protocol）は、AIエージェントをIDEの外にあるデータソースや外部ツールと安全に直結する標準プロトコルです。MCPサーバーを統合することで、AIは「推測」ではなく「ライブデータ」に基づいてコードを記述します。

• Figma MCP & Code Connect：
  Figma上のライブデザインデータを直接読み取り、フォント、余白、オートレイアウトを正確に把握します 。さらに「Code Connect」技術により、Figmaのデザインコンポーネントをリポジトリ内の実在するReactコンポーネント（<Button> 等）と1対1でマッピングし、勝手なHTMLタグの生成を防ぎます
• データベース／スキーマ監視：
  データベースのスキーマや移行ファイルをリアルタイムに読み込ませることで、存在しないテーブルやカラムを使った誤ったSQLクエリの生成を防止します
• イシュー／トラッカー連携 (GitHub / Jira / Linear)：
  チケットの要件や受け入れ基準を直接コンテキストとして読み込み、PRD（製品要件定義書）と実装の整合性を自動的に保ちます
• 可観測性ツール連携 (Sentry / Chrome DevTools)：
  本番環境のエラーログ、スタックトレース、ブラウザのランタイムデータ（DOM、コンソール、ネットワーク）をAIに直接伝達し、デバッグの精度を飛躍的に高めます

Git Worktreeとマルチエージェント・オーケストレーション

2026年のエンジニアリングにおいて、単一のAIモデルにすべてのタスクを委ねる時代は終焉を迎えました 。現在は、特定の専門性を持った複数のエージェントを連携させる「マルチエージェント・システム」と「Git Worktree」を活用した並列開発が標準化しています 。

1. Git Worktreeによる環境隔離：Git Worktree機能を使用し、ローカルリポジトリ内に独立した作業ツリーを複数作成します
   これにより、エージェント同士の変更が競合することなく、並列にタスクを遂行できます
2. 専門分化型エージェントの分業:

• 知覚／設計エージェント: Figmaや仕様書を読み取り、コンポーネント設計とUIの構造を抽出
• 実行／実装エージェント: Claude 3.5 SonnetやGPT-5.6 Solなどの強力なモデルが、独立したWorktree上で並列に実装と単体テストの作成を開始
• 監査／検証エージェント: 推論能力や静的解析に特化したエージェントが、実装されたコードのアクセシビリティ（WCAG AA準拠）、型チェック、セキュリティ、パフォーマンス監査を非同期で並列実行

開発者はこれらの専門エージェントからのフィードバックをオーケストレイトし、最終的な統合を決定する最高指揮官として機能します。

6. 品質保証とガバナンス：AI生成コードの信頼性を維持する多層防御戦略

前述の通り、AIが生成したコードの45%が脆弱性を孕んでいる現実において 、「動くから良し」とするレビューは絶対に許されません。AI生成コードの信頼性を保証するためには、自動化されたテストとエージェント監視を組み合わせた「多層防御（Defense in Depth）」を敷く必要があります。

戦略的TDD（テスト駆動開発）の強制

AI開発において、テストは単なる検証ツールではなく、AIの自律的な反復フェーズを正しく導く「証明書」でありガードレールです。以下のTDDサイクルをエージェントに強制してください。

1. テスト先行作成：
   実装コードを書かせる前に、仕様に基づいて受け入れ基準や入力／出力の期待値を網羅した単体・結合テストを作成させる（未実装機能に対するモックの捏造を禁止する）
2. 失敗の確認（Red）：
   テストを実行させ、意図通りにテストが失敗することを確認する
3. 最小限の実装（Green）：
   テストをパスするためだけの最小限の実装コードを書かせる
4. 自律的リトライ：
   エラーやテストの失敗が発生した場合、AI自身にログとスタックトレースを読み込ませ、テストが全てグリーンになるまで自律的に修正サイクルを回させる

自動化されたコード監査と「AIバグパターン」の特定

人間がすべての差分を1行ずつ確認することは不可能です。PRが作成された直後、あるいはコード生成のリアルタイムループ内に以下の監査レイヤーを組み込みます。

• 静的解析・リンターの最優先実行：
  Prettier、ESLint、型チェック、SAST（静的アプリケーションセキュリティテスト）を即時実行させ、構文ミスや基本的な脆弱性は人間に届く前にAI自身に修正させます
• レビュー専用エージェント（LLM-as-a-Judge）の導入：
  実装を行ったモデルとは別のモデル（またはレビュー専用ペルソナ）を割り当て、セキュリティ、パフォーマンス、保守性の観点からコードを評価させます
• 「AI特有のバグパターン」への集中監査：
  人間のレビューやエージェントによる監査の際は、特にAIが陥りやすい以下の5つのアンチパターンに焦点を絞ります
• Happy Path Bias（ハッピーパス・バイアス）：正常系には完璧に対応するが、タイムアウト、ネットワーク断、null/undefined例外などの異常系処理が「空の catch ブロック」等で放置されている実装
• Plausible but Wrong Logic（もっともらしいが誤った論理）:
  一見綺麗で正しく見えるが、日付フォーマット（米国式 vs ISO 8601）やタイムゾーンの扱いなど、プロジェクト固有の暗黙の前提やドメインルールを無視した実装
• God Component Syndrome（神コンポーネント症候群）：
  状態管理、UIレンダリング、データフェッチ、バリデーションなど、全ての責任を1つの巨大なコンポーネントや関数に詰め込み、再利用性と保守性を著しく低下させる実装
• Mock-Driven Tests（実装の鏡合わせテスト）：
  実装内容の戻り値をそのままテストの期待値にコピーした無意味なテストや、モックを多用しすぎて「モックライブラリが動くことしか証明していない」テスト
• Hallucinated Imports & Dependency Sprawl（実在しないインポートと依存関係の乱用）: 
  存在しないパッケージや存在しない関数を自信満々にインポートするエラーや、標準機能で数行で書ける処理のために巨大な外部ライブラリを勝手に追加する行為

7. 結論：AIとの共進化に向けたマインドセットの転換

2026年のソフトウェア開発における最大の真実は、「AIエージェントの導入によって、エンジニアリングの規約やアーキテクチャの重要性が薄れたのではなく、かつてないほどその重要性が高まった」ということです。

暗黙の了解や「後で綺麗にしよう」という感覚的な技術負債は、AIがそれを学習し、次の生成で増幅・拡散させることで、瞬く間に組織を蝕む致命的な負債へと変わります。

開発者に求められるのは、AIの速度を恐れることでも、無批判に依存することでもありません 。自らが「仕様の記述者（Spec Writer）」および「コンテキストの設計者（Context Architect）」となり、AIという猛烈な馬力を備えたエンジンを、構造化された仕様と堅牢なアーキテクチャというハンドルで正しく導く姿勢です。

今すぐ実践すべき3つのアクション指針

• 第一に、「AGENTS.md」と「.cursorrules」を監査・精ぎぎらせよ。
  リポジトリの設定ファイルから、リンターで代替できるスタイルルールや曖昧な指示を容赦なく削除し、300行以内の「本質的な指示」と「過去の失敗事例（Gotchas）」に絞り込んでください。階層的発見と段階的開示を活用し、AIのインストラクション・バジェットを最大化することです。
• 第二に、「Plan Mode」と「仕様書ファースト」を開発の標準プロトコルにせよ。
  10ファイル以上にまたがる変更や新規機能開発において、コードをいきなり生成させる行為を禁じてください。AIと対話し、自然言語やMarkdownで明確な「仕様」と「計画」を合意してから実装させる仕様駆動開発（SDD）へのシフトが、手戻りとバグを根絶する唯一の解です。
• 第三に、「信頼、しかし検証（Trust, but Verify）」を多層防御で自動化せよ。
  AIが生成するコードの45%に脆弱性が含まれている事実を前提とし、TDDによるテスト先行作成、静的解析、レビューエージェントの監査をCI/CDとIDEに組み込んでください。人間は「ハッピーパス」の確認ではなく、「AI特有のバグパターン」とアーキテクチャの妥当性評価に集中することです。

AIエージェントと共に最高のプロダクトを創造する「100xエンジニア」とは、コードを速く打つ人間ではありません。
明確なビジョンと堅牢な仕様を描き、AIという強大なパートナーを安全かつ確実にオーケストレイトできるプロフェッショナルなのだと言えます。

参考文献・引用データソース

本ガイドの記載データ、アーキテクチャ分析、およびベストプラクティスは、以下の一次情報およびデータソースに基づいています。

1. Veracode (2025): 2025 State of Software Security / GenAI Code Security Report

• AI生成コードの脆弱性発生率（45%）、人間によるコードとの比較、言語別（Java, Python等）およびCWE別セキュリティパス率の分析 。

2. CodeRabbit & Apiiro (2025-2026): AI-Generated Pull Request Analysis

• AI生成PRの総問題数（1.7倍）、セキュリティ課題（2.74倍）、レビュー負荷および月間10,000件超の新規セキュリティ検出データの報告 。

3. METR (2025): Randomized Controlled Trial (RCT) on AI Coding Tools

• 経験豊富なオープンソース開発者における知覚的生産性（24%向上）と実際の作業時間（19%遅延）の乖離分析 。

4. Thoughtworks / Birgitta Böckeler (2025): Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl

• 仕様駆動開発（SDD）の3段階ラダー（Spec-first, Spec-anchored, Spec-as-source）および適用領域の提唱 。

5. Anthropic & Agentic AI Foundation (Linux Foundation, 2025-2026): Agent Skills Standard & AGENTS.md Complete Guide

• インストラクション・バジェット（150〜200個の上限）、段階的開示、階層的発見プロセス、設定ファイルの最適解分析 。

6. OpenAI / Sean Grove (2025): "The New Code" at AI Engineer World's Fair

• プロンプトの使い捨てと仕様書（Model Spec等）を真実のソースとするコンパイル型開発の提唱 。

7. Cursor / Anysphere (2025-2026): Cursor Developer Habits Report & Best Practices

• Plan Mode、Composer、.cursorrules の運用、およびメガPR（1,000行以上）やエージェントの深層推論データ 。

8. LogRocket & FreeCodeCamp (2026): AI-Ready Frontend Architecture & React Refactoring Case Studies

• Use-case層やミドルウェアによる関心の分離、TanStack Query等の活用、神コンポーネントやState Soup回避の定石 。

9. Figma & Builder.io (2025-2026): Figma Dev Mode MCP Server & Visual Copilot Guide

• Model Context Protocol (MCP) を介したライブデザインコンテキストのIDE統合、Code Connectの実装、デザインシステム検証手法 。

10. Nimbalyst & DEV Community (2026): The Bugs AI Writes: 5 Patterns & 14 Anti-patterns to Watch For

• Happy Path Bias、Plausible but Wrong Logic、モック依存テストなど、AIエージェント固有のバグ分類とコードレビュー定石 。