Planモードに性能差はあるのか？
最近のAIエージェントは「Planモード（計画モード）」を搭載することが増えてきました。
しかし疑問が湧きます。
Planモードって本当に違いがあるのか？
どのAIも似たようなものでは？
そこで今回は、同一プロンプトを使って
GitHub Copilot(Chatgpt5.2)
Claude Code（Web版）
のPlanモードを比較してみました。
Claude CodeにおいてのPlanモード
直接コーディングさせると間違ったコードを生成する可能性があり、それを少なくするためにPlanモードが実装されました。
実装時期
2025年6月にClude Code planモードが実装されました。
性能について
推奨されるワークフローには4つのフェーズがあります。
探索
Plan Mode に入ります。Claude はファイルを読み取り、変更を加えずに質問に答えます。
計画
Claude に詳細な実装計画を作成するよう依頼します。
実装
Normal Mode に戻り、Claude にコーディングさせ、計画に対して検証します。
コミット
Claude に説明的なメッセージでコミットし、PR を作成するよう依頼します。
以上の4つのフェーズで実行するとよいです
コンテキストウィンドウ
コンテキストウィンドウはAIを扱う上で非常に大事です。
Claude Codeを使う上で最も重要な概念がコンテキストウィンドウです。
コンテキストウィンドウとはなにか
コンテキストウィンドウとはClaudeが「覚えていられる」情報の量
これは使うAIによって変わる
コンテキストが増えるほど処理速度は遅くなり、回答の品質も低下する
CopilotとClaude Codeのplanモードの比較
ここからはCopilotとClaude CodeでPlanモードの回答がどのように違うのか検証していこうと思います。
Copilotのプランモードにつきましてこちらの記事を見てください
https://qiita.com/kazutoyamaura/items/a2005dfe6efcb14e4c91
使用プロンプト
あなたはシニアフロントエンドエンジニア兼プロジェクトマネージャーです。
これから「シンプル計算ゲーム（暗算チャレンジ）」を実装します。
まずはコードを書かず、設計のみを行ってください。
# 🎯 目的
ブラウザ上で動作するシンプルな暗算チャレンジゲームを作る。
# 🧩 必須機能
- ランダムな足し算問題を1問表示する
- ユーザーが回答を入力できる
- 正解 / 不正解を判定する
- スコアを表示する
- 「次の問題」ボタンで新しい問題を出す
- リセット機能
# ⚙ 技術制約
- HTML / CSS / Vanilla JavaScriptのみ
- フレームワーク禁止
- 外部ライブラリ禁止
- ローカルで完結（APIなし）
# 🧠 設計で必ず整理すること
1. 画面構成（必要なUI要素一覧）
2. アプリの状態（state）の定義
3. 状態遷移の整理
4. 問題生成ロジックの設計
5. イベント設計（どの操作で何が起きるか）
6. 関数分割方針
7. 将来的に拡張しやすくするための設計ポイント
# 📏 タスク粒度
- 1タスクは15〜45分程度の粒度
- 実装順に並べる
- 各タスクに「目的」と「完了条件」を明記する
# 📋 出力形式
- チェックリスト形式
- セクションごとに整理
- 必要なら簡単な図や状態遷移のテキスト表現も含める
コードはまだ出力しないでください。
このプロンプトをplanモードで実行していこうと思います。
Copilot(ChatGpt5.2)側
まず出題する問題の難易度を決めたいと言ってきました
今回は全部1番を選択しました。
次の出力
# 📌 Plan内容のフェーズ整理（見やすい版）
---
# 🧱 フェーズ0：土台の配線（まずは動く器を作る）
## 🎯 目的
画面とJS/CSSの読み込みを安定させる
## ✅ 完了条件
- ブラウザでエラーが出ない
- UI枠が表示される
- JSが正しく読み込まれる
---
## 📝 タスク一覧
### ☐ タスク1：HTMLの土台作成
**目的**
必要なUI要素を最小構成で配置
**完了条件**
- 問題表示
- 入力欄
- スコア表示
- 「次の問題」ボタン
- 「リセット」ボタン
- メッセージ領域
がすべて存在している
---
### ☐ タスク2：CSSの最低限レイアウト
**目的**
縦並び・余白・読みやすさを確保
**完了条件**
- レイアウトが崩れない
- 入力とボタンが操作しやすい
---
### ☐ タスク3：JS/CSS読み込み確認
**目的**
ローカルで確実に動く状態を作る
**完了条件**
- `main.js` が正しく読み込まれている
- DOM未生成エラーが出ない
---
---
# 🧠 フェーズ1：コアロジック（ゲームの中身）
## 🎯 目的
UI抜きでも動くロジックを固める
## ✅ 完了条件
- state管理が破綻しない
- 判定が正しく動く
- 異常入力でもクラッシュしない
---
## 📝 タスク一覧
### ☐ タスク4：state初期化
**目的**
ゲームの初期状態を定義
**完了条件**
- スコア0
- 状態は `"idle"`
- 問題生成可能な状態
---
### ☐ タスク5：問題生成ロジック
**目的**
1桁+1桁の問題を生成
**完了条件**
- 0〜9の整数が生成される
- `answer = a + b` が保持される
---
### ☐ タスク6：入力バリデーション＆判定
**目的**
正誤を安全に判定
**完了条件**
- `invalid`
- `correct`
- `wrong`
を区別できる
---
---
# 🖥 フェーズ2：表示（render設計）
## 🎯 目的
stateを唯一の情報源にする
## ✅ 完了条件
- stateと画面が常に一致する
---
## 📝 タスク一覧
### ☐ タスク7：DOM参照の整理
**目的**
セレクタ散乱を防ぐ
**完了条件**
- 参照が1箇所にまとまる
---
### ☐ タスク8：render実装
**目的**
stateから画面を更新
**完了条件**
- 問題表示が正しい
- スコアが正しい
- メッセージが反映される
---
---
# 🔗 フェーズ3：操作（イベント統合）
## 🎯 目的
ユーザー操作をstate更新に接続
## ✅ 完了条件
- すべての操作が仕様通り動く
---
## 📝 タスク一覧
### ☐ タスク9：Enterキーで判定
**完了条件**
- 正解 → スコア+1
- invalid → エラー表示
- renderが走る
---
### ☐ タスク10：「次の問題」ボタン
**完了条件**
- 新問題生成
- 入力欄クリア
- メッセージ初期化
---
### ☐ タスク11：「リセット」ボタン
**完了条件**
- スコア0
- 問題再生成
- UI初期化
---
---
# 🚀 フェーズ4：仕上げ（品質担保）
## 🎯 目的
開いた瞬間から遊べる状態にする
## ✅ 完了条件
- 初回ロードで問題表示
- すべての操作が正常動作
- 手動テストで要件を満たす
---
## 📝 タスク一覧
### ☐ タスク12：init実装
**完了条件**
- リロード直後にプレイ可能
---
### ☐ タスク13：手動テストチェックリスト
**確認項目**
- 初期表示で問題がある
- Enterで判定
- 正解でスコア+1
- 次の問題で更新
- リセットで全初期化
- 未入力でエラー表示
---
# 🗂 全体構造（俯瞰図）
次にエージェントモードに切り替えてフェーズ0から作業するよう指示をだします。
プロンプト
フェーズ0から作業お願いします。
各フェーズ終了ごとに次のフェーズへ進むかどうか確認をお願いします。
こうすることでAgentが生成したコードが追いやすいのと問題に気づきやすくなるという利点があります。
フェーズ0で作成された画面
問題がなければ次へ進むよう指示します。
途中でなぜこのコードなのかわからに時は次のフェーズに進まず理解するまでaskモードに切り替えて質問をしてください。
全てのフェーズでの作業が完了して
今回Copilotで作成したものはこちらになります。
Claude Code側
今回はWeb版を使用していこうと思います。
使用プロンプトはさきほどと同じものを使います。
出力結果
１：画面構成
┌─────────────────────────────┐
│ タイトル │
├─────────────────────────────┤
│ スコア表示エリア │
│ 正解数: 0 / 出題数: 0 │
├─────────────────────────────┤
│ 問題表示エリア │
│ 12 + 34 = ? │
├─────────────────────────────┤
│ 回答入力フォーム │
│ [入力欄] [回答するボタン] │
├─────────────────────────────┤
│ フィードバックエリア │
│ 「正解！」or「不正解…」 │
├─────────────────────────────┤
│ [次の問題ボタン] [リセット] │
└─────────────────────────────┘
state = {
currentQuestion: { num1, num2, operator, answer }, // 現在の問題
score: { correct: 0, total: 0 }, // スコア
phase: 'waiting' | 'answered', // 現在のフェーズ
lastResult: 'correct' | 'incorrect' | null, // 直近の判定結果
}
3. 状態遷移
[初期化]
→ phase: 'waiting'（問題表示、入力欄クリア）
↓ ユーザーが回答送信
→ phase: 'answered'（正誤判定、フィードバック表示、スコア更新）
↓ 「次の問題」クリック
→ phase: 'waiting'（新問題生成）
↓ 「リセット」クリック
→ phase: 'waiting'（state完全初期化）
4. 問題生成ロジック方針
- 演算子は現在は
+のみ（拡張を見越してoperatorを持つ） - 数値範囲は
configオブジェクトで一元管理（初期値: 1〜99） - 答えが負にならないよう
num1 >= num2を保証（引き算追加時の備え）
5. イベント設計
| 操作 | トリガー | 処理 |
|---|---|---|
| ページロード | DOMContentLoaded |
初期化・第1問生成 |
| 回答送信 | 「回答する」ボタン click / Enter キー | 判定・スコア更新・フィードバック表示 |
| 次の問題 | 「次の問題」ボタン click | 新問題生成・入力クリア・フィードバック非表示 |
| リセット | 「リセット」ボタン click | state初期化・UI全リセット |
6. 関数分割方針
generateQuestion() → 問題オブジェクトを生成して返す
renderQuestion() → 問題をDOMに反映
checkAnswer(input) → 正誤を返す（boolean）
updateScore(isCorrect) → stateのscoreを更新
renderScore() → スコアをDOMに反映
showFeedback(result) → フィードバックをDOMに反映
nextQuestion() → 問題生成→描画→UI切替を統括
resetGame() → stateを初期値に戻し全UI再描画
initGame() → 起動時の初期処理
細かいセクション分類とフェーズ
Section 2: CSSスタイリング
Task 2-1: レイアウト・基本スタイル
目的: ゲームとして視認性の高いレイアウトを作る
作業: 中央寄せレイアウト、フォントサイズ設定、カード型UIの枠組み
完了条件: 画面中央にカードが表示され、各要素が縦に整列している
Task 2-2: フィードバック・状態の色分けスタイル
目的: 正解・不正解を視覚的に区別できるようにする
作業: .correct（緑）/ .incorrect（赤）クラスのスタイル定義。ボタンのhoverスタイル
完了条件: クラスを手動で付け外しして色の変化が確認できる
⚙️ Section 3: JavaScriptコアロジック
Task 3-1: config・state定義 & DOM参照の取得
目的: アプリの設計図となるデータ構造を定義する
作業: config（数値範囲・演算子リスト）と state オブジェクトを定義。全DOM要素の参照を変数に格納
完了条件: コンソールで config と state が正しく出力される。DOM参照が null でない
Task 3-2: 問題生成関数 generateQuestion()
目的: ランダムな足し算問題を生成できるようにする
作業: config の範囲に基づきランダムな2数を生成し、問題オブジェクトを返す
完了条件: 関数を複数回呼んでコンソールで確認し、毎回異なる問題が生成される
Task 3-3: 問題・スコア描画関数 renderQuestion() / renderScore()
目的: stateの内容をDOMに反映できるようにする
作業: 問題文字列の組み立てとDOM反映、スコア表示の更新
完了条件: state を手動で書き換えて関数を呼ぶと画面が更新される
Task 3-4: 回答判定関数 checkAnswer() & スコア更新 updateScore()
目的: ユーザーの回答を正誤判定しスコアに反映する
作業: 入力値と state.currentQuestion.answer を比較して boolean を返す。score を更新
完了条件: 正解・不正解それぞれをコンソールで確認できる
Task 3-5: フィードバック表示関数 showFeedback()
目的: 判定結果をユーザーにわかりやすく伝える
作業: 正解・不正解に応じたテキストと .correct / .incorrect クラスの付け替え
完了条件: 引数を変えて呼んだとき、メッセージと色が切り替わる
🔗 Section 4: イベント統合
Task 4-1: 回答送信イベントの実装
目的: 「回答する」ボタンとEnterキーで判定フローが動くようにする
作業: クリックイベントとキーダウンイベントを登録。phase が 'waiting' のときのみ判定を実行。phase を 'answered' に更新し「次の問題」ボタンを活性化
完了条件: 回答送信でフィードバックとスコアが更新される。二重送信が防がれている
Task 4-2: 「次の問題」ボタンのイベント実装
目的: 新しい問題へ自然に遷移できるようにする
作業: nextQuestion() を実装（問題生成→描画→入力クリア→フィードバック非表示→phaseをwaitingに）
完了条件: ボタンを押すたびに新しい問題が表示され、入力欄とフィードバックがリセットされる
Task 4-3: リセットボタンのイベント実装
目的: ゲームを最初の状態に戻せるようにする
作業: resetGame() を実装（stateを初期値に戻し全UI再描画）
完了条件: リセットを押すとスコアが0になり新問題が表示される
Task 4-4: initGame() の実装とページロード連携
目的: ページを開いた瞬間からゲームが開始できる状態にする
作業: DOMContentLoaded で initGame() を呼び出し。初期問題生成・描画をまとめる
完了条件: ページをリロードするたびに新しい問題が即表示される
🧪 Section 5: 動作確認・仕上げ
Task 5-1: エッジケース対応
目的: 入力ミスや異常操作でクラッシュしないようにする
作業: 空欄送信・数値以外の入力・連打対応の確認と修正
完了条件: 空欄送信時はアラートまたはインラインメッセージが表示される。数値以外は無視される
Task 5-2: UX微調整
目的: プレイ体験を自然にする
作業: 問題表示後に入力欄へ自動フォーカス。回答後に「次の問題」ボタンへフォーカス移動
完了条件: マウスを使わずキーボードだけでゲームが一通りプレイできる
📦 合計タスク数: 12タスク（推定合計: 3〜5時間）
Claude Codeのほうが細かくプランを設計してくれているように感じます。
Claude Codeも同じようにフェーズ分けしてもらいます。
フェーズ分類
Phase 1 — 基盤構築（静的な土台を作る）
コードを書き始める前に「見える形」にする段階
Task内容Task 1-1基本HTMLマークアップTask 2-1レイアウト・基本スタイルTask 2-2フィードバック・状態の色分けスタイル
ゴール: ブラウザで開いたとき、ゲームの全UI要素が静的に揃って見える状態
Phase 2 — コアロジック（動かすための頭脳を作る）
UIとは切り離してJSのデータと計算だけに集中する段階
Task内容Task 3-1config・state定義 & DOM参照の取得Task 3-2問題生成関数 generateQuestion()Task 3-3問題・スコア描画関数 renderQuestion() / renderScore()Task 3-4回答判定関数 checkAnswer() & スコア更新 updateScore()Task 3-5フィードバック表示関数 showFeedback()
ゴール: 各関数をコンソールから呼べば正しく動く状態（イベント未接続でよい）
Phase 3 — 統合（ロジックとUIをつなぐ）
Phase 1とPhase 2を結びつけて「遊べる状態」にする段階
Task内容Task 4-1回答送信イベントの実装Task 4-2「次の問題」ボタンのイベント実装Task 4-3リセットボタンのイベント実装Task 4-4initGame() の実装とページロード連携
ゴール: ゲームとして一通り動作する状態
Phase 4 — 品質担保（壊れない・使いやすくする）
動くだけでなく「ちゃんと動く」を保証する段階
Task内容Task 5-1エッジケース対応Task 5-2UX微調整
ゴール: 異常操作で壊れず、キーボードだけで快適にプレイできる状態
フェーズ全体像
Phase 1 Phase 2 Phase 3 Phase 4
[基盤構築] → [コアロジック] → [統合] → [品質担保]
HTML/CSS JS関数単体 イベント接続 堅牢化・UX
(3タスク) (5タスク) (4タスク) (2タスク)
実装
フェーズ１から作業お願いしますと指示を出すと
まずはスキルファイルを確認してから実装します。Reading frontend design skillReading frontend design skill完了Phase 1の実装を行います。HTML・CSSの構築に集中します。
🎨 デザイン方針: レトロなアーケードゲーム風 × モダンなクリーンUI。黒板グリーン × チョーク白のカラーパレットで、数字が「黒板に書かれた問題」のような雰囲気を演出します。3個のファイルを作成しました, ファイルを読み取りましたCreating index.html for Phase 1index.htmlCreating style.css for Phase 1style.cssCreating empty main.js placeholdermain.jsPresented 3 files完了Phase 1 完了 ✅
デザインコンセプト: 黒板（チョークボード）テーマ。深いグリーン背景に手書き感のある「Caveat」フォントを採用し、学校の黒板に問題が書かれているような雰囲気を演出しました。
実装したUI要素
Task 1-1（HTML） — 全要素を設計通りに配置し、id・aria属性を完備
スコアエリア（正解数・出題数・正答率）
問題カード（問題番号バッジ・数式表示）
回答フォーム（数値入力欄・回答ボタン）
フィードバックエリア（aria-liveでスクリーンリーダー対応）
アクションボタン群（次の問題・リセット）
Task 2-1（レイアウト） — 中央寄せ、カード型レイアウト、グリッド背景でノート罫線の質感
Task 2-2（色分けスタイル） — 以下のクラスを定義済み
.feedback-area.correct → グリーン系
.feedback-area.incorrect → レッド系
.score-value.bump → ゴールドでスコア更新アニメーション用
Phase 2（コアロジック）に進む準備ができています。
このように応答が返ってくるのでフェーズ毎に小さく進めていき問題がなければ次へ進みます。
最後のフェーズが終了して完成したのがこちら
ここまで指示していないにも関わらず、ClaudeはUIをかなり作り込んできました。
まとめ(Copilot側)
・指示に忠実
・与えた制約を逸脱せず、余計なことをしない。
・設計に影響する要素（難易度・スコア定義など）を事前に確認してくる。
まとめ(Claude側)
・UI / ロジック / UX / テスト まで自然に分解してくれる。
・実装順が整理されていて作業しやすい。
・デザイン・アクセシビリティ・演出まで踏み込んでくる。
・指示していないUI強化や装飾を加えることがある。
総まとめ
性能差というより「思考スタイルの差」がある。
プロンプトでどこまで細かく指示をだすかが重要だと思いました。