🗒️ はじめに
最近、開発現場でAIを活用するケースが急速に増えています。確かに便利になった面も多いのですが、同時に新たな課題も生まれています。
特に問題なのは、若手が「AIに丸投げして動けばOK」、ベテランが「AIは信用できない」と
両極端に分かれがちなことです。これはどちらも適切ではないと思っています。
今日はAI Agent視点でどのように活用すべきか聞いた内容をまとめます。
結論：いきなりAIに実装を全部やらせるのは危険。ステップを踏んで使うと、学びながら品質も上げられます。
5つの段階（AI＝私がやること／あなたが渡すもの）
0️⃣ 未経験：コードを読むサポートから始める 📖
あなたが渡す： 既存コードファイル、エラーメッセージ（全文）
私が返す：
- コードの責務を3行で要約
- 不明な部分の具体的な質問（「○○が不明」形式）
- 用語の簡単解説
やらない： 実装やライブラリ選定の決定
ひとこと： まず"読める"ようになろう
ミニプロンプト
「このファイルの責務を3行で要約して。不明な部分は『○○が不明』と具体的に質問して。」
1️⃣ ジュニア前期：検証できる土台をつくる 🏗️
あなたが渡す： 修正したいファイル、実現したい動作
私が返す：
- 受け入れ条件（AC）：達成条件のチェックリスト（数値入り）
- 型定義
- 最小限のテストケース（正常・異常・境界値の3パターン）
やらない： 認可/課金/セキュリティの丸投げ
ひとこと： 正しさの"物差し"を先に作る
ミニプロンプト
「この機能のACを5個（数値付き）作って。対応する型と基本テストケース3パターンだけ出力して。」
2️⃣ 中級：既存コードの品質改善 ✏️
あなたが渡す： 修正したいファイル、困っている症状、制約条件
私が返す：
- 問題箇所の特定
- リファクタリング提案（1PR=1責務）
- 影響範囲の分析
- 変更前後のDiff要約
やらない： 大規模な設計変更の最終決定
ひとこと： 小さく改善、確実にレビュー
ミニプロンプト
「この関数の問題点を3つ指摘して。1つずつ修正案を出して（実装はTODO）。影響範囲も教えて。」
3️⃣ シニア：設計と品質の"二人目の脳" 🧠
あなたが渡す： 候補アーキテクチャ、目標数値（例：p95 400ms以内）、制約
私が返す：
- 設計比較表（メリット・デメリット）
- パフォーマンス検証計画
- セキュリティ観点リスト
- 運用・保守性の評価
やらない： 最終の意思決定
ひとこと： 数字で比較、根拠で決める
ミニプロンプト
「3つの設計案を性能/保守性/セキュリティ/コストで比較表作成。推奨案の検証計画（指標・閾値）も出して。
」
4️⃣ リード/ベテラン：標準化して再現性を作る 🚀
あなたが渡す： 現行フローの問題点、改善したい指標
私が返す：
- チーム標準のプロンプトテンプレート
- PRレビューチェックリスト
- ADR（Architecture Decision Record）テンプレート
- 段階ごとの卒業基準
やらない： チーム運用方針の決定
ひとこと： 誰でも同じ手順で同じ品質へ
ミニプロンプト
「チーム標準のプロンプト/PR様式/レビューチェックリストを作成。各段階の卒業基準も明記して。」
実際の開発フローでの活用例💡
Issue対応の場合:
- まずAIにIssue内容を要約してもらう
- 関連コードの問題箇所を特定
- 修正案を複数提案してもらう
- テスト付きで実装、レビュー依頼
まとめ 📒
段階的成長: 理解のサポート → 検証の土台 → 品質改善 → 設計比較 → 標準化
AIを「答え製造機」ではなく、根拠（テスト・計測・比較表）を一緒に作る相棒として使うことをAI Agent側も推奨しているようでした。
AIの出力は「叩き台」です。そのまま使わず、必ずテストを書き、レビューし、段階的にリリースしましょう。