開発者向けプロンプトエンジニアリング完全ガイド【2026年最新】

プロンプトエンジニアリングとは — 開発者にとっての意味と重要性

プロンプトエンジニアリングの定義

プロンプトエンジニアリングとは、AIモデルに対する入力（プロンプト）を設計・最適化する技術のことです。ChatGPTやClaudeなどの大規模言語モデル（LLM）は、与えられたプロンプトの質によって出力が劇的に変わります。同じモデルを使っていても、プロンプトの書き方次第で「使えない回答」と「完璧な回答」の差が生まれるのです。

開発者にとってのプロンプトエンジニアリングは、単に「AIとの会話が上手になる」という話ではありません。それはソフトウェア開発の生産性を根本から変えるスキルです。従来のプログラミングでは、アルゴリズムを理解し、文法を覚え、一行一行コードを書く必要がありました。バイブコーディングでは、「何を作りたいか」を正確に伝える力が、コードを書く力と同等以上に重要になっています。

なぜ開発者にプロンプトスキルが必要なのか

2026年現在、AIコーディングツールは急速に進化しています。Claude CodeのOpusモデルはコンテキストウィンドウが100万トークン（約200万文字）に対応し、Cursorはプロジェクト全体を理解した上でコードを生成できるようになりました。しかし、どれだけモデルが進化しても、「曖昧な指示からは曖昧な出力しか得られない」という原則は変わりません。

IBM社が2026年に公開したプロンプトエンジニアリングガイドでも、「プロンプトの質がAI出力の品質を決定する最大の要因」と明記しています。ShiftBの受講生データでも、プロンプト研修前後で以下の変化が確認されています。

プロンプトエンジニアリングと従来のプログラミングスキルの関係

「プロンプトエンジニアリングがあればプログラミングの知識は不要なのか？」という質問をよく受けますが、答えはNoです。CHI 2026の論文が示す通り、バイブコーディングの成績に対する予測力はCS知識のほうが文章力の約2倍あります。つまり、プログラミングの基礎知識を持った上でプロンプトスキルを磨くことで、最大の効果が得られるのです。

これを僕は「T字型AIスキル」と呼んでいます。横棒がプロンプトエンジニアリング（AIへの指示力）、縦棒がCS基礎知識（アルゴリズム・データ構造・設計パターンなど）。どちらか一方だけでは不十分で、両方を持つことで初めてバイブコーディングの真価を発揮できます。

バイブコーディングで成果が出るプロンプト5大原則

原則1：具体性（Specificity）— 曖昧さを徹底的に排除する

バイブコーディングで最も多い失敗は、指示が曖昧すぎることです。「ログイン機能を作って」は曖昧ですが、「メールアドレスとパスワードでログインする機能を、NextAuth.jsのCredentials Providerを使って実装して。バリデーションはzodで行い、エラーメッセージは日本語で表示して」は具体的です。

具体性を高めるチェックリストを以下にまとめました。

• 技術スタックを明記する（React、Next.js、TypeScript、Tailwind CSS等）
• 使用するライブラリ・フレームワークを指定する（NextAuth.js、Prisma、zod等）
• 入出力の形式を定義する（JSONのスキーマ、UIのレイアウト等）
• 制約条件を伝える（パフォーマンス要件、セキュリティ要件等）
• 既存コードとの関係を示す（どのファイルに追加するか、どのAPIを呼ぶか）

原則2：コンテキスト（Context）— AIが判断に必要な情報を渡す

AIは「あなたが頭の中で考えていること」を読むことはできません。プロジェクトの背景、現在の状態、目的を明確に伝える必要があります。

Claude Codeでは@ファイル名でファイルを参照でき、CursorではComposerの@codebaseでプロジェクト全体のコンテキストを渡せます。これらの機能を使わないのは、地図を持たずに見知らぬ街を歩くようなものです。

特に重要なのは、CLAUDE.mdやcursorrulesなどのプロジェクトルールファイルです。これらに技術スタック、コーディング規約、ディレクトリ構造を書いておくことで、毎回のプロンプトで同じ情報を伝える手間が省けます。ShiftBでは受講生全員に「プロジェクトルールファイルを最初に書く」ことを推奨しており、これだけでプロンプトの文字数が平均40%削減されています。

原則3：段階分割（Decomposition）— 大きなタスクを小さく分ける

「ECサイトを作って」というプロンプトは、AIにとっても人間にとっても曖昧で巨大すぎます。バイブコーディングで成果を出している開発者は、例外なくタスクを小さく分割しています。

目安として、1つのプロンプトで依頼するタスクは「1機能」か「1ファイル」に留めましょう。具体的には以下のような分割が効果的です。

原則4：例示（Examples）— 期待する出力を見せる

AIに「こういう形式で出力してほしい」と言葉で説明するよりも、具体的な例を1つ見せるほうが圧倒的に効果的です。これはFew-shotプロンプティングと呼ばれるテクニックで、プロンプトエンジニアリングの中でも最も効果が高い手法の一つです。

たとえば、APIエンドポイントを作成する際に「RESTfulなAPIを作って」と言うだけでなく、既存のエンドポイントのコードを見せて「これと同じパターンで新しいエンドポイントを作って」と伝えるほうが、プロジェクトの規約に沿ったコードが生成されます。

原則5：反復改善（Iteration）— 一発で完璧を求めない

プロンプトエンジニアリングの初心者が陥りがちなのが、「一発で完璧なコードを出させよう」とする思考です。しかし現実のバイブコーディングは、対話的な反復プロセスです。

まず大枠を生成させ、次に細部を修正し、最後にエッジケースを処理する——この3段階アプローチが最も効率的です。ShiftBの受講生データでは、1回の巨大プロンプトで全部やろうとした場合の成功率は8%ですが、3回に分けて段階的に指示した場合の成功率は62%に跳ね上がります。

CRISP法 — 構造化プロンプトのフレームワーク

CRISPとは何か

CRISP法は、効果的なプロンプトを構造化するためのフレームワークです。Context（文脈）・Role（役割）・Instructions（指示）・Specifications（仕様）・Polish（仕上げ）の5つの要素で構成されています。このフレームワークを使うことで、漏れのない高品質なプロンプトを一貫して作成できます。

C — Context（文脈）：プロジェクトの背景を伝える

最初に、プロジェクトの技術環境と現在の状態を伝えます。

【Context例】
Next.js 15（App Router）+ TypeScript + Tailwind CSS + Supabase のプロジェクトです。
現在、ユーザー認証機能は実装済みで、ダッシュボードページを開発中です。
ディレクトリ構成は app/(dashboard)/layout.tsx にレイアウトがあり、
各ページは app/(dashboard)/[機能名]/page.tsx に配置しています。

R — Role（役割）：AIに期待する専門性を定義する

AIにどんな専門家として振る舞ってほしいかを伝えます。役割を指定することで、AIの回答のトーンや深さが変わります。

【Role例】
あなたはNext.jsとSupabaseに精通したシニアフルスタックエンジニアです。
セキュリティとパフォーマンスを重視し、型安全なコードを書きます。
日本語のユーザー向けサービスを開発しています。

I — Instructions（指示）：具体的にやってほしいことを伝える

何を作るのか、どう動作するのかを明確に指示します。ここが最も重要な部分です。

【Instructions例】
ダッシュボードにタスク管理機能を追加してください。
- タスクのCRUD操作（作成・読取・更新・削除）ができる
- タスクにはタイトル、説明、期限、ステータス（未着手/進行中/完了）がある
- ドラッグ&ドロップでステータスを変更できるカンバンUI
- リアルタイムで他のユーザーの変更が反映される

S — Specifications（仕様）：技術的な制約を定義する

使用するライブラリ、パフォーマンス要件、コーディング規約などの技術的制約を伝えます。

【Specifications例】
- ドラッグ&ドロップは @dnd-kit/core を使用
- Supabase Realtime で変更を購読
- Server Actions でデータ変更を行う
- コンポーネントは "use client" を最小限に
- Tailwind CSS の gap-10 形式を使用（gap-[40px] はNG）
- 型定義は Supabase CLI で生成した types を使用

P — Polish（仕上げ）：追加の品質基準を指定する

エラーハンドリング、アクセシビリティ、レスポンシブ対応など、品質に関わる要件を最後に追加します。

【Polish例】
- ローディング状態をスケルトンUIで表示
- エラー時はトースト通知で日本語メッセージを表示
- キーボードでも操作可能にする（アクセシビリティ）
- モバイルではカンバンではなくリスト表示に切り替え

CRISP法の効果 — 構造化の有無で出力はこう変わる

CRISP法を使った場合と使わない場合で、AIの出力にどれほどの差が出るかを比較しました。ShiftBの受講生30名に同じ機能を実装してもらい、半数にはCRISP法を使ったプロンプトを、残りの半数には自由形式のプロンプトを書いてもらった結果が以下です。

良いプロンプト vs 悪いプロンプト — Before/After事例集

事例1：コンポーネント作成

悪いプロンプト

ユーザープロフィールカードを作って。

この指示では、デザイン、表示する情報、レイアウト、使用技術のすべてが曖昧です。AIは「どんなプロフィールカードか」を推測するしかなく、求めていたものとは全く違うコンポーネントが返ってくる可能性が高いです。

良いプロンプト

ユーザープロフィールカードコンポーネントを作成してください。

【表示情報】
- アバター画像（Next.js Image、80x80px、丸型）
- ユーザー名（太字、18px）
- 自己紹介文（最大100文字、超過時は「...」で省略）
- フォロワー数・フォロー数（横並び）
- 「プロフィール編集」ボタン（自分のプロフィールの場合のみ表示）

【技術要件】
- TypeScript + Tailwind CSS
- Props: { user: User; isOwnProfile: boolean }
- User型は @/types/user からインポート
- レスポンシブ：モバイルで縦並び、デスクトップで横並び

表示情報・技術要件・条件分岐が明確に定義されています。このレベルのプロンプトなら、1回で使えるコンポーネントが返ってくる確率は70%以上です。

事例2：API実装

悪いプロンプト

商品検索APIを作って。

良いプロンプト

商品検索のServer Actionを作成してください。

【機能要件】
- キーワード検索（タイトルと説明文の部分一致）
- カテゴリフィルター（複数選択可能）
- 価格帯フィルター（min/max）
- ソート（新着順、価格昇順、価格降順、人気順）
- ページネーション（1ページ20件、カーソルベース）

【技術要件】
- app/actions/products.ts に Server Action として実装
- Supabase の products テーブルからデータ取得
- 入力バリデーションは zod で実施
- 戻り値の型: { products: Product[]; nextCursor: string | null; total: number }

【パフォーマンス要件】
- インデックスを活用し、100万件のデータでも200ms以内にレスポンス
- 必要なカラムのみSELECT（*は使わない）

事例3：バグ修正

悪いプロンプト

ログインが動かない。直して。

良いプロンプト

ログインフォーム送信後にリダイレクトされない問題を修正してください。

【現象】
- メールアドレスとパスワードを入力して送信ボタンを押す
- APIは200を返している（ネットワークタブで確認済み）
- しかし /dashboard にリダイレクトされず、ログイン画面に留まる

【再現手順】
1. /login にアクセス
2. test@example.com / password123 でログイン
3. 送信ボタンを押す → 画面が変わらない

【関連ファイル】
- app/(auth)/login/page.tsx（ログインフォーム）
- app/actions/auth.ts（ログインServer Action）
- middleware.ts（認証ミドルウェア）

【仮説】
middleware.ts でセッションCookieの読み取りに失敗している可能性あり

バグ修正のプロンプトでは、「何が起きているか」「何が期待通りか」「どこまで調査したか」の3点を伝えることが鍵です。仮説まで添えることで、AIが無駄な調査をスキップして核心に迫れます。

事例4：リファクタリング

悪いプロンプト

このコードをきれいにして。

良いプロンプト

app/components/Dashboard.tsx をリファクタリングしてください。

【現状の問題】
- 1ファイル450行で肥大化している
- データ取得・ビジネスロジック・UIが混在している
- 同じフィルタリングロジックが3箇所にコピペされている

【リファクタリング方針】
- カスタムフック useDashboardData にデータ取得を分離
- フィルタリングロジックは utils/filters.ts に共通化
- UIは Header / Sidebar / MainContent の3コンポーネントに分割
- 既存の動作・型・テストは壊さないこと

事例5：テスト作成

悪いプロンプト

テストを書いて。

良いプロンプト

app/actions/products.ts の searchProducts 関数のテストを書いてください。

【テストフレームワーク】Vitest + @testing-library/react

【テストケース】
1. キーワード検索：「React」で検索 → タイトルに「React」を含む商品のみ返る
2. カテゴリフィルター：複数カテゴリ指定 → 該当カテゴリの商品のみ返る
3. 価格帯フィルター：min=1000, max=5000 → 範囲内の商品のみ返る
4. ページネーション：20件以上ある場合 → nextCursor が返る
5. 空の検索結果：存在しないキーワード → 空配列と total=0 が返る
6. バリデーションエラー：不正な入力 → エラーが返る

【注意点】
- Supabase クライアントはモックする（createClient をvi.mockする）
- テストデータは最低10件用意する

ツール別プロンプト術 — Claude Code・Cursor・Copilotの使い分け

Claude Code — ターミナルベースのエージェント型開発

Claude Codeは、ターミナル上で動作するエージェント型のAIコーディングツールです。プロジェクトのファイルシステム全体にアクセスし、ファイルの読み書き、コマンド実行、git操作まで自律的に行えるのが最大の特徴です。

Claude Codeでのプロンプトのコツ：

• CLAUDE.mdを充実させる：技術スタック、ディレクトリ構造、コーディング規約を書いておくと、毎回のプロンプトが大幅に短くなる
• ゴール志向で書く：「〜を実装して」ではなく「ユーザーが〜できるようにして」と書くと、エッジケースまで考慮した実装になる
• テストを一緒に依頼する：「実装とテストを同時に作成して」と指示することで、テスト可能な設計のコードが生成される
• コミットも任せる：「実装が完了したら、変更内容を要約してgit commitして」と書くことで、適切なコミットメッセージとともにコミットされる

【Claude Codeプロンプト例】
ユーザーがプロフィール画像をアップロードできる機能を追加して。
- Supabase Storageにアップロード
- 画像は最大5MB、jpg/png/webp対応
- アップロード前にクライアント側でリサイズ（最大800x800px）
- 進捗バーを表示
- 完了したらプロフィールページに反映
実装後にテストも書いて、問題なければコミットしてください。

Cursor — エディタ統合型のAIコーディング

CursorはVS Codeベースのエディタで、コードを編集しながらAIと対話できます。今開いているファイルのコンテキストが自動的に渡されるのが強みです。

Cursorでのプロンプトのコツ：

• @ファイル参照を活用する：@app/types/user.tsのように関連ファイルを明示的に参照する
• Tab補完を活かす：コメントで意図を書いてからTab補完すると、コンテキストに沿ったコードが生成される
• Composer（マルチファイル編集）を使い分ける：複数ファイルにまたがる変更はComposer、単一ファイルの変更はInline Chatが効率的
• .cursorrulesを設定する：プロジェクトのコーディング規約をルールファイルに書いておく

GitHub Copilot — インライン補完型のペアプログラマー

GitHub Copilotは、コードを書いている途中で次のコードを予測・補完するインライン補完が中心のツールです。

Copilotでのプロンプトのコツ：

• コメントを「指示書」として書く：関数の直前に詳細なコメントを書くと、それに沿ったコードが生成される
• 関数名・変数名で意図を伝える：calculateTotalPriceWithTaxのような名前から、AIは処理内容を推測する
• 型定義を先に書く：TypeScriptの型を先に定義してから実装を書くと、型に沿ったコードが補完される

ツール比較 — プロンプトスタイルの違い

ShiftBでは、Claude Codeをメインのエージェントとして使い、Cursorで細かい調整を行うというワークフローを推奨しています。大きな機能開発はClaude Codeに任せ、UIの微調整やデバッグはCursorで、というように使い分けることで最大の効率が得られます。

仕様書エンジニアリング — 2026年の最新トレンド

仕様書エンジニアリングとは

2026年のバイブコーディング界隈で最も注目されているのが、仕様書エンジニアリング（Specification Engineering）という考え方です。これは、AIにコードを書かせる前に構造化された仕様書を作成し、それをプロンプトとして渡すアプローチです。

従来のバイブコーディングが「会話しながら少しずつ作る」スタイルだったのに対し、仕様書エンジニアリングは「まず設計を固めてからAIに一気に作らせる」スタイルです。これにより、やり直しの回数が大幅に減り、大規模な機能でも一貫性のあるコードが生成されます。

仕様書テンプレート — ShiftBで使っている実際のフォーマット

ShiftBでは以下のMarkdownテンプレートを使って仕様書を作成し、Claude CodeやCursorに渡しています。

# 機能仕様書: [機能名]

## 1. 概要
### 目的
この機能が解決するユーザーの課題を1-2文で記述

### ターゲットユーザー
どんなユーザーが、どんな状況で使うか

## 2. 機能要件
### 必須要件（Must Have）
- [ ] 要件1
- [ ] 要件2

### あると嬉しい（Nice to Have）
- [ ] 要件3

## 3. 技術仕様
### 使用技術
- フレームワーク: Next.js 15 (App Router)
- DB: Supabase (PostgreSQL)
- 認証: NextAuth.js

### データモデル
テーブル名: tasks
| カラム | 型 | 説明 |
|--------|------|------|
| id | uuid | 主キー |
| title | text | タスク名 |
| status | enum | 未着手/進行中/完了 |

### API設計
- POST /api/tasks - タスク作成
- GET /api/tasks - タスク一覧
- PATCH /api/tasks/:id - タスク更新
- DELETE /api/tasks/:id - タスク削除

## 4. UI仕様
### 画面構成
- 一覧画面: カンバン形式、3カラム
- 詳細モーダル: タスクをクリックで開く

### レスポンシブ対応
- モバイル: カラムを縦積み
- タブレット以上: 3カラム横並び

## 5. 制約・注意点
- 1ユーザーあたりのタスク上限: 1000件
- タイトルの最大文字数: 100文字

仕様書エンジニアリングの効果データ

ShiftBの受講生20名に、仕様書ありとなしの両パターンで同規模の機能（タスク管理機能）を実装してもらった比較実験の結果です。

特筆すべきはバグの数が75%減少している点です。仕様書でデータモデルやAPIの設計を事前に固めることで、AIが「推測」する部分が減り、一貫性のあるコードが生成されるためです。

仕様書エンジニアリングを始める3ステップ

いきなり完璧な仕様書を書く必要はありません。以下の3ステップで段階的に導入できます。

1. ステップ1（5分）：機能の概要と必須要件をMarkdownの箇条書きで書く
2. ステップ2（10分）：データモデル（テーブル定義）とAPI設計を追加する
3. ステップ3（5分）：制約条件とUI仕様を補足する

合計約20分の投資で、開発時間が67%削減されるなら、費用対効果は抜群です。

ShiftB受講生のプロンプト改善で開発速度が3倍になった事例

改善前：典型的な初心者プロンプト

ShiftBの受講生Aさん（プログラミング歴3ヶ月）は、バイブコーディングを始めた当初、以下のようなプロンプトを書いていました。

ブログアプリを作りたい。
記事の投稿と表示ができるようにして。
Next.jsで。

この3行のプロンプトでは、Claude Codeが生成したコードの採用率はわずか15%。ほとんどのコードを修正するか、書き直す必要がありました。1つの機能の実装に平均1時間以上かかっていました。

改善のプロセス — 3週間のプロンプト研修

ShiftBのプロンプト研修では、以下のカリキュラムで段階的にスキルを磨いていきます。

1. Week 1 — 5大原則の理解と実践：毎日1つの原則を意識してプロンプトを書く。ペアレビューでフィードバックを受ける
2. Week 2 — CRISP法の実践：実際の開発タスクをCRISP法で構造化して書く。テンプレートを使ってパターン化する
3. Week 3 — 仕様書エンジニアリング：中規模の機能を仕様書から作成し、AIに実装させる

改善後：構造化されたプロンプト

3週間の研修後、Aさんのプロンプトは以下のように変化しました。

ブログ記事の投稿機能を実装してください。

【Context】
Next.js 15 (App Router) + TypeScript + Supabase のブログアプリです。
認証は NextAuth.js で実装済み。ログイン中のユーザーのみ投稿可能。
既存の記事一覧ページ（app/articles/page.tsx）は実装済みです。

【機能要件】
- 記事の新規作成フォーム（タイトル・本文・カテゴリ・公開/下書き）
- 本文はMarkdownエディタ（@uiw/react-md-editor を使用）
- プレビュー機能（リアルタイムでMarkdownをレンダリング）
- 下書き保存と公開の2つの保存ボタン

【技術要件】
- Server Action で保存処理を実装（app/actions/articles.ts）
- zodで入力バリデーション（タイトル: 1-100文字、本文: 1-10000文字）
- 保存成功後は記事詳細ページにリダイレクト
- エラー時はフォーム上部にエラーメッセージを表示

改善効果の数値

1機能あたりの実装時間が65分から20分に短縮——つまり約3.3倍速になりました。「プロンプトの書き方を変えただけ」で、使っているAIツールもプランも同じです。この結果は、プロンプトエンジニアリングがバイブコーディングの成否を決定づけることを如実に示しています。

受講生142名の集計データ

Aさんの事例は特殊なケースではありません。ShiftBの受講生142名全体のデータでも同様の傾向が確認されています。

• プロンプト研修を受けた受講生の92%が「開発速度が向上した」と回答
• 開発速度の向上幅は平均2.8倍（最低1.5倍、最高5.2倍）
• プロダクトのリリース率（完成・公開まで到達した割合）は研修前58%→研修後77%に向上
• 「バイブコーディングを続けたい」と回答した割合は研修前67%→研修後96%に上昇

よくある質問（FAQ）

Q1. プログラミング未経験でもプロンプトエンジニアリングは学べますか？

はい、学べます。ただし、プログラミングの基礎知識があるほうがプロンプトの精度は格段に上がります。CHI 2026の研究でも、CS知識がバイブコーディングの成績に最も大きな影響を与えることが示されています。ShiftBでは、プログラミング基礎（HTML/CSS/JavaScript/React）を学びながら、並行してプロンプトスキルも磨くカリキュラムを採用しています。「プログラミングの勉強は不要でプロンプトだけ学べばいい」という主張は、2026年の研究データに基づけば誤りです。

Q2. CRISP法は毎回のプロンプトで全要素を書く必要がありますか？

いいえ、毎回すべてを書く必要はありません。CLAUDE.mdや.cursorrulesにContext（文脈）とSpecifications（仕様）の共通部分を書いておけば、毎回のプロンプトではInstructions（指示）だけで済むことが多いです。初めてのタスクや複雑な機能では全要素を書き、日常的な小さなタスクではInstructionsだけ、というように柔軟に使い分けてください。

Q3. Claude CodeとCursorで同じプロンプトを使っても結果は同じですか？

同じプロンプトでも、ツールによって結果は異なります。Claude Codeはプロジェクト全体のファイルシステムにアクセスできるため、関連ファイルを自動的に参照して一貫性のあるコードを生成します。一方、Cursorは開いているファイルと明示的に参照したファイルのコンテキストで動作するため、関連ファイルを@参照で明示的に渡す必要があります。ツールの特性に合わせてプロンプトを調整することが重要です。

Q4. 英語と日本語、どちらでプロンプトを書くべきですか？

2026年現在、日本語でも十分に高品質な出力が得られます。特にClaude（Anthropic社）は日本語への対応が優れており、日本語のプロンプトでも英語とほぼ同等の品質でコードを生成します。ただし、変数名やコメントなどのコード内の文字列は英語で指示したほうが自然なコードになります。プロンプト自体は母国語（日本語）で書き、コード内の名前は英語で指定するのがベストプラクティスです。

Q5. プロンプトが長すぎるとAIの性能が落ちることはありますか？

プロンプト自体の長さは、適切に構造化されていれば問題ありません。むしろ、必要な情報が不足した短いプロンプトのほうが結果が悪くなります。ただし、Claude CodeのOpusモデルでもコンテキストウィンドウには上限（100万トークン）があるため、会話が非常に長くなると古い情報が失われることがあります。長時間のセッションでは、途中でCRISP法のContext部分を再度伝え直すことで、コンテキストの喪失を防げます。

Q6. 仕様書エンジニアリングは小さな機能でも効果がありますか？

小さな機能には不要です。仕様書エンジニアリングが効果を発揮するのは、実装に30分以上かかる規模の機能です。ボタンの色を変える、テキストを修正する、といった小さなタスクでは、シンプルな1行プロンプトで十分です。仕様書を書く時間が実装時間を上回るなら、それは過剰な設計です。目安として「3つ以上のファイルを変更する必要がある機能」で仕様書を書くようにしましょう。

Q7. AIが間違ったコードを生成した場合、どうフィードバックすればいいですか？

「何が違うのか」を具体的に伝えてください。「違う」「やり直して」だけでは、AIは何を修正すべきかわかりません。効果的なフィードバックの例は以下のとおりです。

【悪いフィードバック】
これじゃない。もう一回やって。

【良いフィードバック】
このコンポーネントに2つの問題があります：
1. ボタンのonClickハンドラで、非同期処理のawaitが抜けている
   → handleSubmit を async にして、saveTask() に await を付けてください
2. エラー時のtry-catchが無い
   → try-catchで囲んで、catch内でsetError(e.message)してください
それ以外の部分はOKなので、上記2点だけ修正してください。