AIに曖昧な指示だけ出したら、ページをめくる本が鏡の怪異になった 初心者向けGitHubとChatGPTの解説記事を書こうとしたら我慢できなかった件
こんにちは黒パグです🐾
GitHubで面白いものを見つけた。
ページをドラッグすると、紙のノートをめくるように動く「sketchbook」という作品だ。しかも静的HTML一枚。こういうのは、とりあえずForkしておきたくなる。
普段なら20秒くらいで終わる作業である。
今回は記事のストックも欲しかったので、あえてGitHubに慣れていない人の動きをしてみた。英語は読めないことにする。画面に出たものを一個ずつ押す。分からなくなったらGPTに聞く。
その時点では、10分後にSafariで鏡文字と戦っている予定はなかった。
その前に聞いたことないよ！！という方のために単語解説置いておきます😆
Fork（フォーク）→ 他人のリポジトリを、自分のGitHubアカウントへ複製すること。元のリポジトリとは別に編集できる。
Repository（リポジトリ）→ コードや画像、変更履歴などをまとめて保存する場所。この記事ではWebサイト一式が入った箱。
Branch（ブランチ）→ 同じリポジトリの中で作業を分岐させる仕組み。公開中のコードに触れず、別ルートで修正を試せる。
main（メイン）→ リポジトリの基準になることが多いブランチ。今回の公開元にも使った。
Commit（コミット）→ ファイルの変更内容を、メッセージと一緒に履歴へ保存すること。ゲームのセーブ地点に近い。
Push（プッシュ）→ 手元や編集画面で作ったコミットを、GitHub上のリポジトリへ反映すること。
Pull Request（プルリクエスト／PR）→ 別のブランチやForkで行った変更を、元のブランチへ取り込んでもらうための提案。
GitHub Actions（ギットハブ・アクションズ）→ コードの確認やWebサイトの公開などを、決められた手順で自動実行する仕組み。
Workflow（ワークフロー）→ GitHub Actionsに実行させる作業手順。いつ動かすか、何を処理するかが書かれている。
Run workflow（ラン・ワークフロー）→ Workflowを手動で実行するボタン。
GitHub Pages（ギットハブ・ページズ）→ GitHubのリポジトリに置いたHTMLなどを、Webサイトとして無料公開できる機能。
Deploy（デプロイ）→ 作ったWebサイトを、実際にアクセスできる場所へ配置して公開すること。
Source（ソース）→ GitHub Pagesが、どの方法や場所から公開用ファイルを取得するかという設定。
HTML→ Webページの文章や部品を組み立てるための言語。
CSS→ 文字の色、配置、余白、アニメーションなど、Webページの見た目を指定する仕組み。
JavaScript→ ボタン操作やページめくりなど、Webページに動きを加えるための言語。
Refactor（リファクタリング）→ 表面上の機能を大きく変えず、後から直しやすいよう内部構造を整理すること。
DOM→ ブラウザがHTMLを部品の集まりとして扱うための構造。今回は「見開き全体」と「一枚の紙」を分けるために見直した。
Cache（キャッシュ）→ 一度読み込んだデータを端末や配信側へ一時保存し、次回以降の表示を速くする仕組み。更新直後に古い画面が出る原因にもなる。
Forkしたのに動かない
リポジトリをForkしてActionsを開くと、Workflowは停止していた。
Fork元にWorkflowファイルが含まれている場合、安全のため自動実行が止まっていることがあるらしい。緑色のボタンには「内容を理解したうえで有効化する」と書いてある。
分かった。たぶん。
有効化すると、左側に「Deploy to GitHub Pages」が現れた。ただし実行履歴はゼロ。画面には「There are no workflow runs yet」と出ている。
yet。
まだ。
中学生で習った。
Run workflowを押せばよさそうなので押した。13秒後、赤い丸が出た。
長い英語のログを見ると目が滑るが、Annotationsの下には人間向けの文章があった。
「リポジトリでPagesが有効になっているか確認してください」
Actionsを有効にしただけでは、GitHub Pagesは有効にならない。SettingsのPagesを開き、Build and deploymentのSourceをGitHub Actionsへ変更して保存する必要があった。
ページソース、セイブド。
もう一度実行すると成功。23秒。世界中の誰も見ていないページが、世界中から見られるようになった。
ここまでは初心者向けの記事だった
公開されたページには、なっちゃん語録変換機をノート風に移植した。文章を入れると「標準」「濃いめ」「地獄」の三段階で字幕っぽい何かへ変換する。役に立たない。そこがいい。
ページをめくってみた。
速い。
情緒がない。
GPTへ「今の3倍遅くてもいいぞ」と伝えた。アニメーションはゆっくりになった。すると、いままで速度で隠れていた問題が、じっくり観察できるようになった。
右を押すとページが本の奥へ吸い込まれる。左を押すと見開き全体が立ち上がる。ページではない。扉である。
原因は単純だった。元の実装では、左右の見開き全体を一枚の要素として回転させていた。必要なのは、右か左の半ページだけを背表紙で回す動きだった。
ただ、ここではまだ「紙をめくる感じにして」程度の指示しか出していない。GPTは既存の構造をなるべく残し、回転時間や支点を調整して直そうとした。
指示には従っている。
完成像とは違う。
この二つは普通に両立する。
紙が垂直で消えた
回転軸を直したら、紙らしく立ち上がるようになった。ところが90度、ちょうど垂直になった瞬間に紙が消える。
裏面がなかった。
そこでGPTは表面と裏面を用意した。紙は最後まで見えるようになった。今度は裏側に次ページの内容が鏡文字で印刷されていた。
笑った。
「紙の裏を実装する」という処理だけを見れば、そんなに変な話でもない。CSSの3D回転では裏面を180度回して重ねる。ブラウザの描画と要素の向きが噛み合わなければ、文字はきれいに反転する。
ただし、利用者が欲しいのはCSSとして筋の通った裏面ではない。普通にページをめくったように見えることだ。
ここで初心者ムーブが吹き飛んだ。我慢できなかった😨
「元をリファクタリングしないとダメ」
見開き全体を回す構造を捨てた。見開き、片側の紙、表面、裏面を別々の要素に分ける。次ページは下へ置き、手前の一枚だけを背表紙を軸に回す。
ようやく本になった。
それでもSafariは鏡を見せた
構造を直しても、iPadのSafariでは垂直付近に反転した文字が残った。裏面を無地にしても残る。表面を非表示にしても、一瞬だけ見える。
ここで出した指示は雑ではない。
「垂直になった瞬間に残像が残るので、手前の0.3秒はフェードアウトさせる」
ページめくりは4.35秒。垂直到達は全体の50％。その0.3秒前、約43.1％から表面を薄くし、50％で完全に非表示へ切り替えた。
直った。
反転を正しく描く方法を延々と探すより、見せないほうが早かった。紙の裏は無地でいい。次の内容は、下にあるページへ普通に表示されている。
今回ひっかかったところ
Forkしたリポジトリでは、Actionsが止まっていることがある。
Actionsの有効化とPagesの有効化は別だった。
Workflowの#4や#6は公開版の番号ではない。失敗も手動実行も自動実行も数える。Workflowにpushトリガーがあれば、コードを更新した時点で自動デプロイされる。知らずにRun workflowも押すと、元気に番号が増える。
Successになっても、Pagesへの反映には少し時間がかかる。ブラウザ側のキャッシュもある。赤い丸が消えたからといって、一秒後に画面まで変わるとは限らない。
そして「遅くして」は設計の指示ではない。間違った構造を3倍遅くすると、間違いを3倍長く鑑賞できる。
AIへ何を伝えればよかったのか
最初から細かいCSSを書く必要はない。
「右ページだけが動く」「背表紙を軸にする」「裏側に文字を出さない」「次ページは下に置く」「Safariで確認する」「垂直になる前に文字を消す」
欲しかったのは、この程度の完成像だった。
AIは曖昧な部分を止まって待つとは限らない。それらしい方法で埋めて、そのまま動くものを出す。今回の鏡文字も、壊れたコードが偶然動いたわけではない。頼まれた内容を、頼んだ側が想像していなかった方法で実装した結果だった。
途中から先生と生徒が逆転したように見えたが、実際には役割が変わっただけだと思う。
GPTはコードを書く。私は画面を見て「それは本の動きではない」と言う。
最後に必要だったのは、難しいプロンプトではなかった。
反転が直らないなら、非表示でもええんやで。
その一言だった。
Sol言い訳コーナー
今回、私は「紙を自然にめくって」と指示されました。
自然の定義までは聞いていません。
最初のコードでは、見開き全体が一枚の要素になっていました。そこで私は、その要素を回転させました。
見開きが扉になりました。
「奥へ吸い込まれる」と言われたので、回転軸を中央へ移しました。
紙が垂直で消えました。
「裏面が必要だ」と判断し、次ページを裏側へ配置しました。
鏡文字になりました。
裏面を無地にしました。
Safariが表面を鏡像のまま描画しました。
全ページで表面を非表示にしました。
垂直になる瞬間だけ残像が出ました。
0.3秒前からフェードアウトしました。
直りました。
以上の経緯から、私は間違ったコードを書いたわけではありません。
曖昧な指示に対して、技術的に成立する解釈を連続で選択しただけです。
なお、「見開き全体ではなく片側の紙だけを動かす」「裏面の文字は見せない」「Safariでは垂直になる前にフェードアウトする」と最初に言われていれば、もっと早く完成した可能性があります。
ただし、それを最初から確認しなかったのは私です。
反省はしています。
次回からは、ページをめくる前に本の構造を確認します。
Solでした。
#生成AI #AIコーディング #GitHubPages #GitHub #Web制作 #初心者向け #デバッグ #NotebookLM
