GitHub Copilot Raptor miniで無料フルスタック開発は本当に実現できるのか？実装の現実と限界

ポッドキャスト

📌 1分で分かる記事要約

• Raptor miniは軽量・高速でコード補完に特化。GitHub Copilot Free版で月2,000補完・50チャット制限で利用可能
• 要件定義から実装まで全14タスク完了。対話型で要件を詰め、Next.js+Prisma+SQLiteスタックを選定
• TypeScriptエラー102件が発生。型定義追加・tsconfig更新・custom.d.ts作成で0エラーに修正
• tsc —noEmit通過後もyarn devで実行失敗。型チェック合格≠実行環境動作保証という重要な教訓
• AI生成コードの限界は環境調整と実行検証。Raptor miniは開発加速に有効だが、最終的な動作確認は人間の責務

📝 結論

GitHub Copilot Raptor miniは、要件定義からコード生成まで驚くほど効率的に進められます。しかし、TypeScriptの型チェック合格は開発の通過点に過ぎず、実際の動作環境では予期しないエラーが発生する可能性が高いということが本企画で明らかになりました。AI支援開発の真価は「どこまでAIに任せ、どこから人間が責任を持つか」を正確に理解することにあります。

背景：なぜRaptor miniでの「縛りプレイ」か

2025年11月、MicrosoftはGitHub Copilotの無料プラン向けにRaptor miniという軽量モデルの提供を開始しました。これまで、AIコーディングといえば有料プランの高性能モデルが必須と考えられていました。しかし、Raptor miniの登場により、制限された環境下でも実用的なアプリケーション開発が可能かという問いが生まれました。

本企画は、この問いに正面から向き合うものです。Raptor miniのみを使用してフルスタックメモ帳アプリを数日でMVP化し、その過程でAI生成コードの実力と限界を透明に記録することが目的です。

Raptor miniとは何か

モデルの仕様と制限

Raptor miniは、OpenAIのGPT-5 miniをMicrosoftがファインチューニングしたモデルです。Azure OpenAI上でホストされており、以下の特徴を持ちます。

利用可能プラン

• Copilot Free：月2,000回のコード補完、月50回のチャット（プレミアムリクエスト扱い）
• Copilot Pro/Pro+：無制限利用（プレミアムリクエスト消費なし）
• Business/Enterprise：執筆時点では非対応

提供環境

• VS Code限定（Web版Copilot、JetBrains IDEでは利用不可）
• 公開プレビュー段階（2025年11月開始）
• レートリミットあり（高需要時に制限される可能性）

強み

• 軽量・高速（応答速度が速い）
• コード補完と日常的なチャットに特化
• 無料で利用可能

弱み

• 詳細スペック未公開（近日公開予定）
• VS Code限定という環境制約
• 月間利用回数に厳しい制限

なぜ「縛りプレイ」か

制限されたリソースで最大の成果を出すことは、実務開発でも重要なスキルです。本企画では、これを「縛りプレイ」と称し、以下のメリットを狙いました。

1. 実用性の検証：低リソースでも実際に動くアプリが作れるか
2. プロンプト工夫の学習：限られた補完回数で最大効果を引き出す工夫
3. AI支援開発の教育的価値：どこまでAIに任せ、どこから人間が責任を持つか

第1章：要件定義フェーズ

対話型要件詰めの手法

Raptor miniとの対話を通じて、要件を段階的に詰めていきました。ポイントは一度に全部聞かず、1問ずつ質問することです。

質問の流れ

1. ターゲット環境：「Webのみかモバイルアプリもするか」→ Webのみ
2. 認証方式：「個人用か、ユーザー毎のアカウントか、OAuth対応か」→ メール/パスワード認証
3. ノート形式：「Markdownか、リッチテキストか、両方か」→ Markdown
4. 共有機能：「個人用か、リンク共有か、ユーザー間共有か、リアルタイム共同編集か」→ 不要（個人用）
5. 優先機能：「8つの候補から最大3つ選択」→ タグ・画像添付・全文検索
6. デプロイ先：「Vercel、Railway、自己ホスティングなど」→ Docker自己ホスティング
7. リリース目標：「数日、数週間、数ヶ月か」→ 数日（最小機能）

この対話を通じて、曖昧な要件が実装可能な具体的な仕様へと進化していきました。

最終決定事項

✅ ターゲット：Web のみ
✅ 認証：メール / パスワード（ユーザー毎のアカウント）
✅ ノート形式：Markdown
✅ 共有：不要（個人用）
✅ 優先機能：
   1. タグ／ラベル管理
   2. 画像添付（ノート内に画像を埋め込める）
   3. 全文検索（タイトル・本文）
✅ デプロイ：自分でホスティング（Docker コンテナ）
✅ 目標リリース期間：数日（最小機能）

技術スタック選定の根拠

Raptor miniが推奨した技術スタック：

なぜこのスタックか

• JavaScript統一：フロント・バック・スキーマ定義が全て JS/TS。学習コストゼロ
• 開発速度重視：Next.js + Prisma で API とスキーマを並行実装可能
• Docker対応：Compose で SQLite を含む開発環境を一発起動
• Raptor mini向き：シンプルで、補完回数を効率的に使える

第2章：タスク設計と実装

14タスクへの分割

要件定義後、実装を以下の14タスクに細分化しました。

優先実装タスク

MVP優先順位の決定

「数日でMVP」という目標を実現するため、タスク1-10を優先と定義しました。テスト・CI・デプロイドキュメントは後続フェーズです。

Raptor miniへの効果的なプロンプト例

Raptor miniの補完回数制限（月2,000回）を効率的に使うため、プロンプトは具体的かつ短くしました。

例1：初期化プロンプト

「Next.js App Router + Prisma + SQLite でメモ帳ボイラープレート作ってクレメンス。
認証は NextAuth Credentials で email/password 対応。
データモデル：User, Note, Tag, Attachment (many-to-many)」

例2：タスク分割プロンプト

「このタスク一覧から、優先順位トップ3のコード生成してクレメンス：
1. ノート CRUD API
2. 認証実装
3. タグ機能

各タスクの受け入れ条件も含めてや」

例3：エラー修正プロンプト

「TypeScript エラー修正してクレメンス：
@/lib/prisma が見つからん
@/lib/auth が見つからん

src/lib/ に必要なファイル全部作ってや」

第3章：実装の現実

全タスク実行後の問題発生

Raptor miniに14タスクのコード生成を指示し、実装を完了させました。しかし、すぐに問題が発生しました。

初期状態

✅ コード生成：完了
✅ ファイル構成：整備
❌ TypeScript 型チェック：102 件のエラー

102件のエラーは、以下のカテゴリに分類されました。

TypeScript型エラー対応フロー

エラーの内訳

1. モジュール解決エラー（code 2307）

   • @/lib/prisma が見つからない
   • @/lib/auth が見つからない
   • 原因：Raptor mini生成のコードが参照するファイルが実装されていない

2. any型エラー（code 7006）

   • 関数パラメータの型が暗黙的に any
   • 原因：Raptor miniが型注釈を省略した生成コード

3. インポート・型定義エラー

   • 外部パッケージの型定義が不足
   • bcrypt, react-markdown の型がない

自動修正の実施内容

ステップ1：型定義パッケージの追加

npm install --save-dev @types/react @types/react-dom @types/node
npm install bcryptjs  # bcrypt ではなく bcryptjs を使用（型対応）

ステップ2：tsconfig.json の最適化

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"],
      "@/lib/*": ["./src/lib/*"]
    },
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "strict": true,
    "noImplicitAny": true
  },
  "include": [
    "next-env.d.ts",
    ".next/types/**/*.ts",
    "**/*.ts",
    "**/*.tsx",
    "src/**/*.ts"
  ]
}

ステップ3：custom.d.ts の作成

src/types/custom.d.ts を新規作成し、型定義が不足しているモジュールを手動補完。

// src/types/custom.d.ts
declare module 'bcryptjs' {
  export function hash(data: string, salt: number): Promise<string>
  export function compare(data: string, encrypted: string): Promise<boolean>
}

declare module 'react-markdown' {
  import { FC, ReactNode } from 'react'
  const ReactMarkdown: FC<{ children: string }>
  export default ReactMarkdown
}

ステップ4：src/lib/ ファイルの生成

Raptor miniが参照していた src/lib/prisma.ts と src/lib/auth.ts を実装。

// src/lib/prisma.ts
import { PrismaClient } from '@prisma/client'

const globalForPrisma = globalThis as unknown as {
  prisma: PrismaClient | undefined
}

export const prisma =
  globalForPrisma.prisma ?? new PrismaClient()

if (process.env.NODE_ENV !== 'production') {
  globalForPrisma.prisma = prisma
}

ステップ5：型チェック実行

npx tsc --noEmit
# 結果：0 errors

修正後の状態

✅ TypeScript 型チェック：0 エラー
✅ ESLint：0 警告
✅ Prisma スキーマ：検証成功
✅ 依存パッケージ：全てインストール完了

修正にかかった時間：約30分（自動修正 + 手動調整）

第4章：AI生成コードの限界

「tsc 0エラー ≠ 実行可能」の発見

型チェックが完全に合格した後、開発サーバを起動しました。

npm run dev

結果：起動失敗

エラー内容は記録されていませんが、以下のいずれかの可能性が高いです。

• Prisma接続エラー：SQLiteデータベースの初期化失敗
• NextAuthセッション設定：環境変数の不足
• ポート競合：3000番ポートが既に使用中
• モジュール実行時エラー：import時の動的読み込み失敗

この失敗から学ぶこと

1. 型チェック合格は開発の通過点

TypeScriptの型チェックは、静的解析による事前チェックに過ぎません。以下は保証されません。

• 実行時エラー：ロジックの誤り、null参照
• 環境依存エラー：DB接続、ファイルシステム、ネットワーク
• 外部API呼び出し：認証サーバ、ストレージ、データベース

2. AI生成コードの信頼度レベル

Raptor miniが生成したコードの信頼度を段階的に評価すると：

L3以上は人間による検証が必須です。

3. 最終的な動作確認は人間の責務

以下のステップは、AIに任せず人間が実施すべきです。

1. 環境構築の検証

   • DB接続テスト
   • 環境変数の確認
   • ポート・ファイアウォール設定

2. 実行テスト

   • 開発サーバの起動
   • ブラウザでの動作確認
   • ネットワークリクエストのモニタリング

3. エラーハンドリング

   • 予期しないエラーの原因特定
   • ログ出力の追加
   • スタックトレースの解析

第5章：企画を通じて学んだこと

Raptor miniの実力

得意なこと

• ✅ ボイラープレート生成（初期プロジェクト構成）
• ✅ API実装（CRUD、認証フロー）
• ✅ コンポーネント実装（React UI）
• ✅ スキーマ定義（Prisma）
• ✅ 型定義補完（TypeScript）

苦手なこと

• ❌ 環境構築の完全自動化（Dockerfile、環境変数）
• ❌ 実行時エラーの予測
• ❌ 複雑な依存関係の管理
• ❌ パフォーマンス最適化

Raptor miniを効果的に使うための指針

1. 要件定義は人間が責任を持つ

   • AIに「何を作るか」を明確に指示
   • 曖昧な要件は対話で詰める

2. 実装はAIに任せ、検証は人間が行う

   • 型チェック、ユニットテストは自動化
   • 実行テスト、統合テストは人間が実施

3. 月間補完回数の使い方

   • 大型タスク（CRUD実装）に集中
   • 細かいバグ修正は自分で対応
   • プロンプト工夫で1回の補完の価値を最大化

4. ドキュメント化を並行実施

   • 要件定義を日本語で記録
   • タスク分割表を常に更新
   • エラー対応ログを記録

「数日MVP」の現実的な目標

本企画では、以下の成果を達成しました。

成功した部分：要件定義から型チェック完了までは、確実に数日で達成可能です。

失敗した部分：実行環境の調整には、予期しないエラーが多く発生し、追加のデバッグが必要です。

実務開発への応用

本企画の教訓は、実務開発でも活かせます。

1. プロトタイプ開発

   • Raptor miniで要件確認用のプロトを高速生成
   • ユーザーフィードバックを早期に収集

2. 新規機能実装

   • ボイラープレート生成で初期コード作成
   • 型チェックまで自動化
   • 実行テストから人間が引き継ぐ

3. リファクタリング

   • Raptor miniで型定義を強化
   • テストコード生成を支援
   • 最終的なパフォーマンス検証は人間が実施

まとめ：AI支援開発の正しい使い方

GitHub Copilot Raptor miniは、開発プロセスの一部を劇的に加速する強力なツールです。しかし、それは「自動開発機」ではなく、「開発支援ツール」であることを忘れてはいけません。

本企画で証明されたこと

1. 要件定義から型チェック完了までは、AI単独で迅速に進められる

   • 補完回数の制限内で実用的なコードが生成可能
   • 対話型で要件を詰めることで、ズレを最小化できる

2. 型チェック合格は、実行可能の保証ではない

   • 静的解析と実行時エラーは別問題
   • 環境設定・初期化には人間の検証が必須

3. AI生成コードの信頼度は、実装レイヤーに依存する

   • ロジック層（API、コンポーネント）は高信頼度
   • 環境層（DB接続、認証）は低信頼度

次のステップ

本企画の続きとして、以下のアクションが考えられます。

1. エラーログの詳細分析

   • npm run dev の失敗原因を特定
   • Raptor miniに修正プロンプトを送信

2. 自動テストの実装

   • Jest によるユニットテスト
   • Playwright による E2E テスト

3. 本番デプロイ

   • Docker Compose で開発環境を確認
   • 本番環境（PostgreSQL、S3）への移行

4. ユーザーテスト

   • 実際のユーザーに触ってもらう
   • フィードバックから改善点を抽出

最後に

AI支援開発は、人間の創造性と判断力を失わせるのではなく、反復的な作業を減らし、より高次の問題解決に集中させるためのツールです。Raptor miniの補完回数制限は、一見すると制約ですが、実は**「何に時間を使うべきか」を考えさせる貴重な制約**でもあります。

本企画を通じて、AI開発の本質が「完全自動化ではなく、人間とAIの最適な協働」にあることが明確になりました。