自作アプリに生成AIを頼りすぎる危険性と正しい活用法

1) 学習段階ごとの「AI使用度メーター」

学習段階に応じて、AIをどれくらい使うかの目安。

基礎期（文法～配列）     [■□□□□□□□□□] 10%：用語説明・ヒントのみ
応用期（設計～小規模）   [■■■□□□□□□□□] 30%：調査補助・改善提案
実務期（チーム/作品）    [■■■■■□□□□□□] 50%：設計初稿/雛形/翻訳（要検証）

2) 「危険ゾーン vs 健全ゾーン」対比表（印刷推奨）

観点危険ゾーン（避ける）健全ゾーン（推奨）
実装主要機能を丸投げ生成自作→AIにリファクタ提案を依頼
理解コピペで動けばOK「なぜ動くか」を自分の言葉で説明
検証未検証のまま採用単体テスト/ログで必ず検証
設計仕様をAIに作らせる自分で骨格→AIに代替案/論点出し
記録生成履歴なし「AIへの指示/返答/採否理由」を残す
倫理出典不明/丸パクライセンス確認/出典明記/改変の記録

3) 相談フロー（AIは“補助輪”）

4) 「AI利用申告テンプレ」（ポートフォリオ提出用）

提出時に必ず同梱。信用と再現性が上がります。

# AI利用申告（サンプル）
- 役割：設計レビュー、改善提案、エラーログ要約
- 指示例（プロンプト要約）：
  「Player移動の責務分離の観点で改善提案を」
- 反映内容：
  - Input層とDomain層を分離（PR #12）
  - Update内ロジックの早期return化（PR #14）
- 採否理由：
  - 提案A：可読性向上→採用
  - 提案B：GC増大の懸念→不採用
- 検証：
  - 単体テスト△件、PlayModeテスト△件
  - FPS/アロケーション計測の結果良好

5) 「自走力チェックリスト」（毎週の自己点検用）

  • 目的を1文で言語化した
  • タスクを30–90分粒度に分割した
  • 公式Docsとログを先に確認した
  • 最小再現(MRE)を作った/更新した
  • AIに丸投げせず、仮説→検証→記録を回した
  • 採用/不採用の判断理由を残した
  • README/設計メモを更新した
  • 自分の言葉で説明（5分トーク）できる

6) 演習課題（授業で使える）

課題A：Input層の責務切り出し

  • 要件：Updateから入力判定を分離し、インターフェース経由で攻撃を発火
  • 制約：AI生成コードのコピペ禁止（設計案レビューのみ可）
  • 成果物：クラス図、要約メモ（採否理由）、テスト実行ログ

課題B：AI提案の検証レポート

  • 手順：同じ仕様でAIに3案出させる→自分でベンチ/可読性比較
  • 成果物：採用案・理由・測定表・不採用案の懸念点

7) 評価ルーブリック（AI時代版）

項目SABC
目的/要件定義1文で明確、テスト観点まで明確やや曖昧不明確
設計責務分離と依存の意図が説明可ほぼ説明可一部曖昧説明不可
実装再現性が高い、テスト整備動作安定多少不安定不安定
検証/記録採否理由・ログが充実必要十分簡易ほぼ無し
AIの使い方補助的・検証徹底適切依存気味丸投げ

8) 反・依存ガイド（決めごと）

  • 主要機能の丸投げ生成は禁止
  • 「なぜそう書いたか」を自分の言葉で説明できないコードは採用しない
  • 生成コードは必ずテスト/ログで検証
  • 出典・ライセンス・改変点を記録する

訪問数 5 回, 今日の訪問数 5回

AI,学習

Posted by hidepon