感覚的開発者の『いい感じ』検証責任

Karpathyのバイブコーディングでの『感覚的開発者』の責任と『いい感じ』の検証

『感覚的開発者』の雰囲気責任原則

「いい感じ！」で生まれたコードの最終責任は常に感覚的開発者にあります。
AIパートナーは「いい感じ」の協働相手ですが、その出力を「なんとなくいい感じ」で受け入れることは危険です。

なぜ『いい感じ』の検証が必要なのか

1. AIパートナーの「なんかうまくいかない」を理解する

AIパートナーが「なんかおかしい」と感じる問題：

  • 「なんか古い情報」に基づく実装
  • 「こんなケースもありそう」の見落とし
  • 「なんか危ない感じ」のセキュリティ脆弱性
  • 「なんか重い感じ」のパフォーマンス非効率性
  • 「こんなつもりじゃなかった」ビジネスロジックの誤解

2. 『いい感じ』検証のレベル

レベル1: 「なんかおかしい」構文レベルの直観的検証

# AIパートナーが「いい感じに作った」コード def calculate_average(numbers): return sum(numbers) / len(numbers) # 感覚的開発者の「なんかおかしい」直観ポイント # - 「エラーでこんだらどうしよう？」が不足 # - 「空っぽのリストでなんかエラーになりそう」

レベル2: 「いい感じに改善したい」ロジックレベルの感覚的検証

# 感覚的開発者が「いい感じに改善した」版 def calculate_average(numbers): if not numbers: return 0 # または「いい感じのデフォルト値」 return sum(numbers) / len(numbers)

レベル3: 「いい感じのビジネスロジック」雰囲気的検証

# 感覚的開発者が「いい感じのビジネスロジック」にしたさらなる改善 def calculate_average(numbers, decimal_places=2): """ 数値リストの平均を「いい感じに」計算 Args: numbers: 数値のリスト decimal_places: 「いい感じの小数点以下の桁数」 Returns: float: 平均値（「いい感じの桁数」で丸め） Raises: ValueError: 「なんかおかしい入力」の場合 """ if not isinstance(numbers, (list, tuple)): raise ValueError("「いい感じの配列」である必要があります") if not numbers: raise ValueError("「空っぽの配列」では平均を計算できません") try: total = sum(numbers) average = total / len(numbers) return round(average, decimal_places) except TypeError: raise ValueError("「すべての要素が数値」である必要があります")

3. 『いい感じ』の雰囲気的チェックリスト

「なんかおかしい」基本的検証項目

  • 「いい感じに動いてる？」
  • 「エラーの時いい感じに処理されてる？」
  • 「こんなケースもありそうだけど大丈夫？」
  • 「変数名・関数名がいい感じ？」
  • 「コメントが正確でいい感じ？」

「なんか危ない感じ」セキュリティの雰囲気的検証項目

  • 「入力値をちゃんとチェックしてる？」
  • 「なんかSQLインジェクションできそうじゃない？」
  • 「認証・認可がいい感じ？」
  • 「機密情報がいい感じに扱われてる？」
  • 「依存関係になんか危ないものはない？」

「なんか重い感じ」パフォーマンスの雰囲気的検証項目

  • 「計算量はいい感じ？（O(n²)よりいい方法はない？）」
  • 「メモリ使用量がいい感じ？」
  • 「不要なAPI呼び出しはない？」
  • 「キャッシュをいい感じに活用してる？」
  • 「並列処理でもっと速くできない？」

4. 『感覚的開発者』の責任ある雰囲気開発プラクティス

『感覚的開発者』が絶対にやってはいけないこと

  • AIパートナーの出力を「なんとなくいい感じ」で本番環境へデプロイ
  • 「なんか危ない感じ」のセキュリティ関連コードを「なんとなくいい感じ」で使用
  • 「なんかよくわからない」コードをそのまま使用
  • 「いい感じのテスト」なしでのリリース

『感覚的開発者』の推奨される雰囲気開発フロー

1. 「こんな感じにしたい」意図伝達 └─ AIパートナーと「いい感じの対話」で意図を明確化 2. 「いい感じの初期実装」 └─ AIパートナーに「いい感じのコード生成」を依頼 3. 「なんかおかしい」直観的レビュー ├─ 「なんかおかしい」構文チェック ├─ 「いい感じに動く？」ロジック検証 └─ 「こんなつもりだった？」ビジネス要件との整合性確認 4. 「いい感じのテスト」作成 ├─ 「基本的なテスト」 ├─ 「ちゃんと統合される？」テスト └─ 「こんなケースもありそう」テスト 5. 「もっといい感じに」リファクタリング └─ AIパートナーと「いい感じに改善」して協力 6. 「いい感じのドキュメント」化 └─ AIパートナーに「いい感じの文書化」支援を求める 7. 「いい感じ！リリースしよう」最終レビュー └─ チーム全体での「いい感じ！」レビュー

5. 実践的な検証例

例：ユーザー認証機能の検証

# AIが生成した認証コード def authenticate_user(username, password): user = database.get_user(username) if user and user.password == password: return create_session(user) return None # 問題点の特定 # 1. パスワードが平文で保存されている # 2. タイミング攻撃に脆弱 # 3. ブルートフォース対策なし # 4. ログ記録なし

検証後の改善版

import bcrypt import time from datetime import datetime, timedelta class AuthenticationService: def __init__(self): self.failed_attempts = {} self.lockout_duration = timedelta(minutes=15) self.max_attempts = 5 def authenticate_user(self, username, password): # ブルートフォース対策 if self._is_locked_out(username): self._log_attempt(username, False, "Account locked") return None # タイミング攻撃対策 start_time = time.time() try: user = self._get_user_secure(username) if user and self._verify_password(password, user.password_hash): self._reset_failed_attempts(username) self._log_attempt(username, True) return self._create_secure_session(user) else: self._record_failed_attempt(username) self._log_attempt(username, False) except Exception as e: self._log_error(f"Authentication error: {str(e)}") # 一定時間を確保（タイミング攻撃対策） elapsed = time.time() - start_time if elapsed < 0.5: time.sleep(0.5 - elapsed) return None def _verify_password(self, password, password_hash): return bcrypt.checkpw( password.encode('utf-8'), password_hash.encode('utf-8') )

6. 継続的な学習と改善

検証スキルを高める方法