今日のアジェンダ

1. エラーをAIと一緒に読んで直す
2. 状況を具体的に伝えて、AIに的確に頼む
3. 変更を記録して、いつでも戻れるようにする
4. GitHub Desktop と Codex で開発の土台を作る

前回の続きから

前回は、Codex.app に頼んで、自然言語の指示からプロダクトの形を作り始めた

今後、成果物のサイズがおおきくなると、エラー や 思ったとおりに動かない 状態に直面するかも

エラーは失敗ではない

プロのエンジニアでも、コードは一度では完成しない。エラーは開発の 通常運転

• エラーは「どこがおかしいか」をコンピュータが示す メッセージ
• エラー文には、原因を特定する 手がかり が含まれている
• AIが書いたコードでも、一度で完璧に動くとは限らない
• 重要なのは、メッセージを 読んで対応する こと

デバッグ (debug) とは、バグ (bug、不具合) を取り除く作業のこと

エラーが出たら、まずやること

当てずっぽうで直す前に、まず情報を集める

1. エラー文をコピーする：表示された文をまるごと選ぶ
2. どの操作で出たか確認する：直前に何をしたかを思い出す
3. Codexに渡す：エラー文と操作内容を貼り付ける
4. 説明を読む：原因と直し方を理解する

エラーは、AIと一緒に読む

長い英語のエラーも、まるごとCodexに渡せば「日本語の説明」に変わる

Uncaught TypeError: Cannot read properties of null (reading 'value')
    at submitForm (app.js:42)

渡し方で、AIの答えが変わる

AIは その場の画面を見ていない。あなたが伝えた情報がすべて

エラーを直すコツは、状況を 具体的に伝える こと。エラー文やスクリーンショットも渡すと良い

AIにエラーを相談するときの言い方

そのまま使える、依頼のテンプレート

このエラーが出ました。
〔エラー文やスクリーンショットを貼る〕

〔ボタンを押したとき〕に起きます。
本当は〔こう動いてほしい〕です。

原因を特定して、修正してください。

Codex.app なら、ファイルを開いた状態で頼むと、画面を見ながら一緒に直してくれる

直っても、「なぜ」を聞いておく

AIの修正を、そのまま受け取るだけで終わらない

• 直ったら「なぜ直ったのか を説明して」と聞く
• 同じエラーに次に出会ったとき、自分で気づけるようになる
• コピペで動いても、何が起きたかを分かってから 次へ進む

それでも直らないときは

同じエラーが何度も直らないときの選択肢

• 一度戻す：動いていた状態に戻して、やり直す (このあとのGit)
• 範囲を狭める：どこまでは正常かを、Codexと一緒に確認する
• 人に聞く：チームメンバーや教員に、画面を見せて相談する
• 別のAIに聞く：同じ状況を、別のAIにも説明してみる

戻せる状態を用意しておくと、修正を試しやすい。講義の後半はそのためのGit

なぜ「記録」が必要か

ファイルを上書き保存で進めていくと、こうなりがち

これを解決するのが バージョン管理 (Git)

Git とは

Git：(平たく言えば) 変更の節目を セーブポイント として残せるしくみ

• 「ここまで動いた」という時点を、いつでも保存できる
• おかしくなったら、保存した時点に 戻せる
• いつ・何を変えたかが、あとから たどれる
• チームの変更を まとめて 共有できる

セットアップの流れ

gitコマンドは打たない。GitHub Desktop（土台・履歴の確認・復元）と Codex（操作を言葉で依頼）を使い分ける

1. GitHubアカウント を作る (https://github.com)
2. GitHub Desktop をインストールする (https://desktop.github.com)
3. GitHub Desktop に サインイン する → Gitと認証がまとめて入る
4. 前回の プロジェクトフォルダを開く (Add → 既存フォルダを選ぶ)

これで、Codexがgitを動かせる状態になる

記録する：コミット

区切りのいいところで、その時点を保存する

• Codexに「ここまでをgit commitして」と頼む
• どんな変更かを 一言メッセージ にする (例:「入力フォームを追加」)
• GitHub Desktop を見ると、変わった場所が色 で分かる

共有する：プッシュ

記録を、クラウド (GitHub) に上げてチームと共有する

• Codexに「git pushして」と頼む
  • Codexの権限設定によってはエラーが出るかも
• PCが壊れても、コードは クラウドに残る。チームと同じプロジェクトを共有できる

取り込む：プル

チームメンバーの作業を、自分の手元に取り込む

• 作業を始める前に、Codexに「git pullして」と頼む
• 最新の状態にしてから、自分の変更を始める
• これを忘れると、古い状態を変えてしまい 競合の原因 になる
• GitHub Desktop でも、最新を取り込める (Pull)

始めるときpull、区切りでcommit、終わりにpush がチームのリズム

戻る：履歴から復元する

Codexに「git logで履歴を見せて」と頼むと、記録の一覧が出る

a1b2c3d 入力フォームを追加      ← 今ここ
e4f5g6h ボタンの色を修正
i7j8k9l 最初のページを作成      ← ここまで戻したい

• 動いていた時点のコミットを 見つける
• 「このコミットに戻して」とCodexに頼む
• GitHub Desktop の履歴からも、同じ操作ができる

チームで作る：競合への対処

同じファイルを2人が同時に変えると、競合 (ぶつかり) が起きることがある

今日のまとめ

次回：第7回 ユーザーテスト・プレゼン

開発中のプロダクトを他チームのメンバーに実際に使ってもらうユーザーテストを実施する。操作中の振る舞いを観察・記録し、得られたフィードバックを分類して改善の優先順位を決める。最終プレゼンテーションに向けて、発表構成 (課題→解決策→デモ→振り返り) の組み立て方とスライドデザインのポイントを解説する。

a日程：7/7 (火)　b日程：7/14 (火)