よくある質問 (FAQ) — プロクター向けリファレンス¶

このドキュメントは、ワークショップ中に参加者からよく寄せられる質問に対して、プロクターがすぐに答えられるよう用意したリファレンスです。一貫した、的確なサポートを提供するために活用してください。

GitHub Copilot に関する質問¶

Q: 「Copilot が何も提案してくれません」¶

まず確認すること: - VS Code で Copilot が有効になっているか？（ステータスバーの Copilot アイコンを確認） - ファイルは保存済みか？Copilot はファイルが保存されている状態でより良く動作する - コンテキストは十分か？関連ファイルを開くか、#file: 参照を使ってみる

トラブルシューティング手順: 1. Copilot がアクティブか確認する（アイコンにエラー表示がないこと） 2. モデル選択を確認する — 別のモデルに切り替えてみる 3. VS Code ウィンドウをリロードする（Ctrl+Shift+P → 「Reload Window」） 4. インターネット接続を確認する 5. GitHub アカウントからサインアウトして再度サインインする

参加者への回答例: 「一緒に確認してみましょう。ステータスバーに Copilot アイコンが表示されていますか？ファイルが保存されているか確認し、プロンプトに #file: 参照でコンテキストを追加してみましょう。」

Q: 「他のモデルは使えますか？どれが一番いいですか？」¶

回答: 「はい、使えます！GitHub Copilot は複数のモデルをサポートしています。このワークショップは GPT-4o-mini でテストしていますが、Claude や Gemini など他のモデルも自由に試してみてください。モデルによって提案の内容が変わります。絶対的に「最良」のモデルはありませんが、複雑なタスクには GPT-4o が精度が高く、速度を優先するなら GPT-4o-mini が向いています。」

切り替え方法: - Copilot Chat でモデル名をクリックする - 利用可能なモデルから選択する - 提案が有用でない場合は別のモデルを試す

Q: 「Agent モードを使うのはズルじゃないですか？自分でコードを書くべきでは？」¶

回答: 「良い質問です！Agent モードはズルではありません。シニアエンジニアとペアプログラミングするようなものです。学習はここで起きます：

何を依頼するか考えること
生成されたコードを検証すること
うまく動かないときにデバッグすること
いつ信頼してよくて、いつ確認すべきかを判断すること

AI とのペアプログラミングだと考えてください。重要な判断はすべて自分が行っており、後で活かせるパターンを学んでいます。」

Q: 「Copilot の提案が指示書と合っていません。どうすればいいですか？」¶

回答: 「これは素晴らしい学習の機会です！

まず検証する: Copilot の出力と期待される動作を比べる
プロンプトを洗練する: 何が欲しいかをより具体的に伝える
繰り返す: Copilot にフィードバックを与えて調整してもらう
検証を使う: テストを実行して正確性を確認する

AI の提案は常に完璧ではありません。提案をいつ受け入れ、いつ修正し、いつ却下するかを判断する力も大切なスキルです。」

テストに関する質問¶

Q: 「Copilot の言ったとおりにやったのにテストが失敗します」¶

トラブルシューティングガイド:

アプリが起動しているか確認する:
Python テストはアプリが起動している状態でないと実行できない
確認: curl http://localhost:8000 でレスポンスが返ることを確認する
ポートを確認する:
Python アプリはポート 8000 で起動する
テストの互換性のため、C# アプリもポート 8000 で起動する必要がある
C# アプリ起動時は --urls "http://localhost:8000" を指定する
BASE_URL 環境変数を確認する:
Windows: $env:BASE_URL="http://localhost:8000"
Linux/Mac: export BASE_URL="http://localhost:8000"
テスト出力を確認する:
具体的にどのアサーションが失敗しているか確認する
期待値と実際の値を比べる
具体的なエラーメッセージについて Copilot に質問する

参加者への回答例: 「一緒にデバッグしてみましょう。まず、アプリは起動していますか？テスト出力を見て、具体的に何が失敗しているか確認してみましょう。」

Q: 「xUnit や NUnit を使ってもいいですか？」¶

回答: 「はい、xUnit や NUnit を使っても構いません！ただし、移行の検証には Python テストを必ず動作させ続ける必要があります。Python テストが API の互換性を検証するためです。C# テスト（MSTest・xUnit・NUnit のいずれでも）はオプションの追加要素です。Python テストが「正しさの基準」となります。」

Q: 「すべてのエンドポイントにテストを書く必要がありますか？」¶

回答: 「Python テストはすでに HTTP リクエストを通じてすべてのエンドポイントをテストしています。このワークショップでは：

必須: Python テストを通過させ続ける（C# 移行の検証に使う）
任意: C# ユニットテストを追加する（グッドプラクティスだが完了要件ではない）

早く終わった場合は、C# テストの追加は素晴らしいチャレンジになります！」

環境・セットアップに関する質問¶

Q: 「Codespaces とローカル開発、どちらがいいですか？」¶

回答: 「このワークショップでは GitHub Codespaces を推奨しています：

✅ セットアップ不要 — すべて事前設定済み
✅ 全員が同じ環境を使える
✅ ブラウザがあればどのデバイスでも利用可能
✅ インストール不要

Python 3.12 と .NET 10 SDK がすでにインストールされて動作している場合は、ローカル開発でも問題ありません。」

Q: 「Codespace が遅い・固まっています。どうすればいいですか？」¶

すぐにできる対処法:

ページをリロードする — 一時的な問題はこれで解決することが多い
Codespace を停止して再起動する — GitHub Codespaces ページから
新しい Codespace を作成する — 最後の手段だが確実

予防のヒント: - 使っていないブラウザタブを閉じる - 不要なプロセスは停止する - サーバーを止めるときは Ctrl+C を使う

参加者への回答例: 「まずブラウザページをリロードしてみましょう。それでも改善しない場合は Codespace を再起動しましょう。」

Q: 「ポート 8000 が使用中です。どうすればいいですか？」¶

解決方法:

プロセスを見つけて終了する:

Windows PowerShell:

# プロセスを確認
Get-NetTCPConnection -LocalPort 8000

# プロセスを終了（PID を置き換える）
Stop-Process -Id <PID> -Force

Linux/Mac:

# プロセスを確認
lsof -i :8000

# プロセスを終了
kill -9 <PID>

または別のポートを使う:

# Python
uvicorn main:app --port 8001

# C#
dotnet run --urls "http://localhost:8001"

参加者への回答例: 「ポート 8000 を使っているプロセスを特定して停止しましょう。または別のポートを使うこともできます。その場合はテスト用の BASE_URL 環境変数も更新してください。」

コード移行に関する質問¶

Q: 「どの Copilot モードを使えばいいかわかりません」¶

クイック判断ガイド:

タスク	モード	理由
「このコードは何をしていますか？」	Ask	学習のみ、変更なし
「C# プロジェクトの雛形を作成してください」	Agent	コマンド実行を含む複数ステップのタスク
「移行の計画を立ててください」	Plan	実装前に方針を整理する

参加者への回答例: 「質問には Ask、変更や複数ステップのタスクには Agent、まず方針を整理したい場合は Plan を使いましょう。」