🤫

「いい感じに作って」→ 大炎上。AIへの丸投げで痛い目を見た話

に公開
AI
Cursor
LLM
Claude Code
Kiro
idea

あれ？AIに聞いても、なんかイマイチな答えしか返ってこない...

こんにちは。今月のAIツール課金額が3万円を超えてしまい、妻に怒られているエンジニアです。

Cursor、Claude Code、Windsurf、Kiro...次々と新しいAIツールが登場して、「これで開発効率10倍だ！」なんて思っていませんか？

でも現実は...

  • 「ログイン機能作って」→ なぜか10個のファイルが生成される
  • 「いい感じにリファクタリングして」→ 動かなくなる
  • 「エラー直して」→ 別のエラーが3つ増える

そんな経験、ありますよね？（私は週3であります）

衝撃の事実：AIの失敗、9割は「任せ方」が原因だった

最初は「Claude Code使えねー」とか「やっぱりCursorの方が...」とか思ってました。

でも、ある日気づいたんです。

うまくいかない時の私の指示：

「ユーザー管理機能を実装して」
「なんかバグってるから直して」  
「もっと高速化して」

これ、新人エンジニアに同じ指示出したら、どうなりますか？

そう、カオスになりますよね。

AIを「できる新人」だと思ったら、すべてが変わった

AIの本当の姿

私は今、AIをこう捉えています：

「超優秀で、素直で、24時間働いてくれる新人エンジニア」

でも、この新人には特徴があります：

長所：

  • ⚡ 実行スピードが異常に速い（1分で100ファイル生成とか）
  • 😊 絶対に不機嫌にならない（深夜3時でも文句言わない）
  • 💪 諦めを知らない（エラー100個でも挑戦し続ける）

だからこその落とし穴：

  • 曖昧な指示でも「わかりました！」と突っ走る
  • 明らかにおかしな方向でも止まらない
  • 「これでいいですか？」と確認してこない

人間なら「すみません、ちょっとよくわからないです...」って言ってくれるのに！

図書館で見つけた、意外な解決策

煮詰まった私は、図書館へ。

プログラミングコーナーではなく、ビジネス書コーナーへ向かいました。

  • 『新人教育の基本』
  • 『任せ方の教科書』
  • 『マネジメントの原則』

パラパラめくって、衝撃を受けました。

「これ、全部AIにも当てはまるじゃん...」

📚 マネジメント本で見つけた「基本中の基本」

どの本にも共通して書かれていた原則がこれ：

  • ✅ 任せる範囲を明確化する
  • ✅ 作業はWhy→How→Whatの順番で伝える
  • ✅ 必ず予定を立ててから作業を行う
  • ✅ 一度に大きなタスクはせず、小さい粒度で行う
  • ✅ できなかったことは必ず報告させる
  • ✅ 膨大な情報を与えすぎない
  • ✅ 知識のない作業を無理にやらせない
  • ✅ わからないことはそのまま実施せず、調べてから実施する
  • ✅ 作業指示はできるだけ分かりやすく

「...あれ？これ新入社員研修で習ったやつじゃん」

そう、社会人1年目で学ぶような基礎の基礎。
でも私、AIに対してはこれ全部無視してました。

不機嫌にならないし、文句も言わないから、つい雑な指示を出してたんです。

実際に試して効果があった「5つの定石」

1. 🎯 範囲を明確化する

Before（失敗例）：

「ユーザー認証機能を作って」

→ 結果：なぜかメール送信、SMS認証、顔認証まで実装される地獄

After（成功例）：

「ユーザー認証機能を実装。
- 対象：メールアドレスとパスワードのみ
- DBは触らない（モックで対応）
- 外部ライブラリは使わない」

→ 結果：期待通りのシンプルな実装

2. 📝 Why→How→What の順番で伝える

これ、めちゃくちゃ効きます。

ダメな例：

「Reactでフォーム作って」（What only）

良い例：

Why: ユーザーフィードバックを収集したい
How: シンプルで使いやすいUIで、バリデーション付き
What: お問い合わせフォームコンポーネント

AIも「なぜ作るのか」がわかると、より適切な提案をしてくれるんです。

3. 🔪 タスクを小さく刻む

私の失敗談：
「ECサイトのバックエンド全部作って」
→ 3時間後、意味不明な巨大システムが爆誕

学んだこと：

  • まず「商品一覧APIのみ」
  • 次に「商品詳細API」
  • その次に「カート機能」

1〜2時間で確認できる粒度が黄金律です。

4. 🔄 中間報告をもらう

魔法の質問たち：

  • 「ここまでの理解を3行でまとめて」
  • 「不明な点を3つ挙げて」
  • 「次に何をする予定？」

これだけで、明後日の方向に進むのを防げます。

5. ✅ 完成の定義を決める

受け入れ基準（AC）の例：

## 完成の定義
- [ ] エラー時の処理が実装されている
- [ ] TypeScriptの型定義がある
- [ ] コメントが日本語で書かれている
- [ ] console.logが残っていない

これがないと、AIは「動けばOK」と判断しがちです。

3分で効く「軌道修正の質問集」

作業中に「なんか違う...」と感じたら、この質問を投げてみてください：

状況 魔法の質問 効果
複雑になりすぎた時 「最小構成（MVP）で作り直すとしたら？」 シンプルな本質が見える
迷走し始めた時 「現在の目的を1文で言うと？」 原点回帰できる
エラー地獄の時 「最も重要なエラーを1つだけ選ぶなら？」 優先順位が明確になる
仕様が曖昧な時 「具体例を3つ挙げて」 認識のズレが見える

実際に使っているプロンプトテンプレート

私が毎日使っている、Claude Code用のカスタムコマンドです：

## ts:backend : TypeScriptバックエンド実装コマンド

### Why（なぜ必要か）

TypeScriptバックエンド開発では、型安全性とセキュリティが最重要です。このコマンドは保守性の高いコードを段階的に生成します。

### How（どのように進めるか）

**作業範囲の明確化**:
- 基本的なクラス構造とインターフェース定義
- 型安全性の確保
- セキュリティガードレールの適用
- エラーハンドリングの実装

**段階的アプローチ**:
1. 要件分析と設計
2. インターフェース定義
3. 基本実装
4. セキュリティ強化
5. テストと検証

### What（何をするか）

#### 使い方

# 基本的な実装
/ts:backend "ユーザー認証サービスクラスを作成"

# 厳格な型チェック付き実装
/ts:backend --strict "API クライアントクラスを実装"

# セキュリティ重視の実装
/ts:backend --security "ユーザー入力を受け取るAPIエンドポイント"

#### 作業計画

**Step 1: 要件分析**
- 実装対象の明確化
- 必要なインターフェースの特定
- セキュリティ要件の確認

**Step 2: 基本設計**
- クラス構造の設計
- 型定義の作成
- エラーハンドリング方針の決定

**Step 3: 実装**
- インターフェース定義
- メソッド実装
- バリデーション追加

**Step 4: セキュリティ強化**
- 入力検証の実装
- 禁止APIの回避
- ログ出力の追加

**Step 5: 最終確認**
- 型安全性の確認
- セキュリティチェック
- コード品質の検証

### 実装ルール

#### 命名規則

| 対象 | 規則 | 例 |
|------|------|-----|
| 変数 / 関数 | `camelCase` | `orderBook`, `getMovingAverage()` |
| クラス / インターフェース / Enum | `PascalCase` | `TradeService`, `IOrder`, `OrderSide` |
| 定数 | `SCREAMING_SNAKE_CASE` | `API_TIMEOUT_MS = 30_000` |
| 型パラメータ | `T` + PascalCase | `type Nullable<TValue>` |
| ファイル名 | `camelCase.ts` | `userService.ts`, `authController.ts` |

#### 型安全性

- **strict mode**: `strict: true` 必須
- **any禁止**: `any`、`implicit any` は禁止
- **型ガード**: 避けられない場合は `unknown` と型ガードを使用
- **公開API**: 必ず型注釈を付与

#### セキュリティガードレール

**禁止API**:
- `eval`, `Function` コンストラクタ
- `setTimeout`/`setInterval` の文字列実行
- `child_process.*`
- `fs.readFileSync` (非同期版を使用)
- `JSON.parse` (バリデーション付きで使用)

**入力検証**:
- 外部入力は必ずバリデーション
- SQL Injection 対策
- XSS 対策（レスポンス生成時）

### 基本テンプレート

#### サービスクラス

 省略

### エラーハンドリング

 省略


### 注意事項

- **型安全性**: 必ずstrict modeで実装
- **セキュリティ**: 禁止APIは使用しない
- **エラーハンドリング**: 例外は適切にハンドリング
- **ログ**: `console.log` ではなく `pino` を使用
- **バリデーション**: 外部入力は必ずバリデーション

### 作業報告

実装中に問題が発生した場合は、以下の情報を含めて報告してください：
- 発生した問題の詳細
- 試行した解決策
- 必要な追加情報

失敗から学んだ「やってはいけない」リスト

❌ これをやると地獄を見ます

  1. 「いい感じに」「適当に」「よしなに」
    → AIは「最大限に」と解釈します

  2. 一度に10個以上の要求
    → 必ず何か忘れられます

  3. 「最新のベストプラクティスで」
    → 意味不明な最新技術の実験場になります

  4. エラーメッセージだけ投げる
    → 見当違いの修正が始まります

まとめ：AIとの付き合い方が変わると、開発が楽しくなる

3ヶ月前の私：

  • 「AIツール使えない」と愚痴る日々
  • 手戻りばかりでストレス MAX
  • 「結局自分で書いた方が速い」症候群

今の私：

  • AIとペアプロしている感覚
  • 期待通りの出力が8割（たまに驚きの提案も）
  • 開発速度は本当に3倍になった

変わったのはツールじゃない。任せ方だけ。

今日から始められる第一歩

まずは次の開発で、この質問から始めてみてください：

「これから○○を実装したいんだけど、まず何から始めるべきだと思う？」

AIも人間と同じ。ちゃんとコミュニケーションを取れば、期待以上の仕事をしてくれます。

最後まで読んでいただき、ありがとうございました！

この記事が役に立ったら、ぜひあなたの「AIあるある失敗談」も教えてください。
みんなで学んで、みんなで成長していきましょう🚀

P.S. 妻への言い訳：「これは自己投資だから...」（効果はありませんでした）

📝 著者について

普段は真面目にブロックチェーン周りの記事を書いています。

https://x.com/naizo_eth
https://zenn.dev/naizo01

現在、HivefiというLLMを使ったシステムトレード戦略ハブを開発中。
https://x.com/Hivefi_X

AIとの格闘の日々から学んだことを、これからも共有していきます！

Discussion