Git講座を「左に図、右に解説」のスクロールテリングに作り替え、簿記講座の全20章へ広げた記録
Git講座を「左に図、右に解説」のスクロールテリングに作り替え、簿記講座の全20章へ広げた記録
午前の時点で、Git講座の checkout の回は「次へ」ボタンで進む作りのままだった。 ほかのレッスンと見た目がそろわず、講座一覧にも載っていなかった。 昼前には、左にターミナルが固定され、右の説明をスクロールすると左でコマンドが1文字ずつ打たれる画面に変わっていた。 その画面を見て、「こういうレイアウトは何というパターンなのか」と聞いた。 同じ形でやりたい解説が、ほかにもあったからだ。
前日に作った画面再現と音声の話は、Git の checkout や reset --hard を画面再現で見せる動画教材づくりに書いた。
ミラーカラム版にそろえ、余白と表を詰める
最初に頼んだのは、Git講座をミラーカラム版にして、ほかの講座とトーン＆マナーを合わせることだった。 「次へ」ボタンは残してよいが、ミラーカラム版の矢印キーでも切り替えられるようにしてほしい、とも伝えた。 既存のミラーカラム講座と同じ共通の枠に載せてもらい、講座一覧では「コーディング」に入れた。 本番ではまだ公開していなかったので、一覧には「ドラフト」扱いで載った。
開いてみると、見出しの上がかなり空いていた。 本文エリア上の余白（40px）と、区間の先頭の見出しの上マージン（64px）が重なっていたためである。 Git講座のページだけ両方を詰めてもらい、見出しの上は116pxから28pxになった。 画面再現が「次へ」ボタンまで1画面に収まった。
表にも注文を付けた。 横スクロールバーを出さず、中央に寄せて本文の max-width をはみ出してよい。 スクロールさせるのは、閲覧環境の幅が上限に達したときだけでよい。 Claude Code に全8回の表31個を調べてもらい、PC幅ではどれも横スクロールバーが出なくなった。 表は本文幅（760px）の外まで広がり、いちばん広い表は1381pxだった。
スクロールに合わせて左のターミナルが動く2列へ
続けて、画面再現をスクロール連動の作りに直してもらった。 左にターミナルと「中で起きていること」の図を固定し、右の説明を読み進めると、左でコマンドが1文字ずつ打たれてから出力と図が変わる。 右の目次の列は消し、その幅を2列に回した。
一つ不具合が出た。 矢印キーを押したあと、スクロール位置が約24px手前で止まり、1ステップ前へ引き戻されていた。 直したあとは←→キーが両方向で効き、最後のステップで→を押すと次の区間へ移るようになった。
動く画面を見て、「控えめに言って最高ですね」と口に出た。
このレイアウトの名前
Claude Code の答えは「スクロールテリング（scrollytelling）」だった。 その中でも、図を画面に固定して横の説明だけをスクロールさせる形は、「スティッキー・グラフィック（sticky graphic）」や「サイドバイサイド型」と呼ばれる。 英語なら "sticky side-by-side scrollytelling" で通じ、説明の1つ1つを「ステップ」、固定される側を「グラフィック」または「ステージ」と呼ぶ。
名前が分かったので、作り方を非公開の記事にまとめてもらった。 ほかの解説でこの形を使うときの下敷きにするためである。
左のステージが画面の下で切れる
左のステージは、最初は上半分をターミナル、下半分を「中で起きていること」に分け、全体を広げる形にしてもらった。 ターミナルは高さ465pxになり、中でスクロールしなくなった。 下半分に空きが出たので、ターミナルに高さを多めに回した（約57:43）。 ところが、図が縦に長い stash の後半のステップでは、下半分が最大で約150pxはみ出した。 比率で分けるのをやめ、下半分は図の自然な高さにして、残りをターミナルで埋める形に変えてもらった。
そのあと、自分のブラウザで左のステージの下のパネルが切れているのを見つけて伝えた。 Claude Code の手元のタブでは収まっていたので、窓の大きさや表示のタイミングによらず収まる作りに直すことにした。 ステージを枠に合わせて縮める計算を入れ、1440×900 の窓で全8回の全ステップを確かめてもらった。
この確認は一度では通らなかった。 最初の失敗は、確認スクリプトの待ち時間が短すぎただけだった。 次に、縮めるときの丸めで5pxはみ出す場面が1つ見つかり、計算に小さな余裕を足した。 高さ900pxの窓では、いちばん縮む場面が0.55倍になり、切れはしないものの読みにくかった。 自分の画面の高さ（1214px）では、0.93〜1.00倍でほぼ原寸に収まっていた。 Codex の指摘を実際のページで確かめて直すと、その場面は0.72〜0.76倍になった。 それでもステップ7が数pxはみ出したので、縮めたあとにまだはみ出していれば、はみ出した分だけ縮める2段目の処理を足してもらった。
ドラフトを外して公開し、音声の操作を付ける
ここまで見て、「素晴らしすぎるコンテンツ」だと思えた。 まだ第1部しかないが、途中でもいいので自分のウェブ上で確かめたかった。 ドラフトを外して公開扱いにしてもらった。
タブレットで左右がちゃんと出るのかも気になった。 iPad の横向きと縦向きのどちらでも、左右2列で出るようにしてもらった。 幅390pxのスマホは640px未満なので、これまでどおり縦に積む。
公開後、ほかの講座の試作で入れていた音声の操作を、Git講座にも付けてもらった。 前へ／次へが並ぶ帯の左に、読み上げのオンとオフ、速さ（1×／1.25×／1.5×／2×）、「自動で進む」を並べている。 読み上げが終わると次のステップへ進む。 音声の再生に失敗したときは、説明の文字数から決めた待ち時間で進む（約70字のステップで10.4秒だった）。
簿記講座へ持ち出す
Git講座の作りを見て、簿記の基礎講座にも使えると考えた。 自分の書籍を元にした講座なので、左に図を置き、右にその説明を置けば、この形に乗るはずだと思った。 まず第1章だけ、ミラーカラム版とは別に「ストーリーテリング版」を作ってもらった。
見ながら2点を直してもらった。 1点目として、タイトルを本文から外し、前へ／次へのボタンが並ぶ帯の左に移した。 あわせて、左の図の枠が画面の下で切れないようにした。 2点目はマゼンタの強調が始まる位置である。 1番目の説明だけが画面のいちばん上で光っていたので、2番目の要素があるあたりの真ん中から必ず始めるよう頼んだ。 画面の上から40%の位置で光るようになった。
第1章を見て、全部この形で見たくなった。 ただ、その前にここまでの内容を実装計画にまとめてもらった。 実装はサブエージェントにさせ、Claude Code にはメインエージェントとして全体を管理させた。 計画書が Codex のレビューを通ったあと、実装担当2体を並行で動かし、全20章の巡回検証は3体目に任せた。 単体テスト15件が通り、全20章が200を返す状態でコミットした。
まとめの章には、縦に長い図が1枚ある。 これを矢印キーで説明と一緒に1、2と送れないか、座標でうまく区切れないかと聞いた。 →キーで1ステップずつ図の位置が進むようになった。 あわせて伝えた件では、白い背景に白い矢印と白い箱を描いた図が見えなくなっていた（同じ作りの図はほかに747枚あった）。 図の背後に薄いグレーを敷いて、見えるようにしてもらった。
3列目の件は、1回では済まなかった。 ページの下の節を3列目に出す設定をストーリー版から外すと、右側の幅が748pxになり、2列表示の閾値（880px）を下回って縦積みに戻ってしまった。 閾値を700pxまで下げてもらい、2列を保った。 最後に、トピック列の緑の下線が→キーで進めた分だけ伸びるようにしてもらった（20→40→60→80→100%）。
まとめは左に、右は左に沿った画面を
同じ日の朝には、Excel講座の動画を分割画面（左にマインドマップ、右に画面）へ移す作業も進めていた（前日の経緯は計算モジュールの動画化）。 あるまとめの区間で、右に「このセクションのまとめ」の表が出ていた。 章立てのパターンでは、まとめはマインドマップ上で左に出しているべきものなので、右に出す必要はないと伝えた。 出すならマインドマップのほうを細かく分け、右は Excel だけにしてほしい。 表をなくすと、2分20秒のあいだ右はずっと Excel の画面になった。
あとで言い足したのは、右を Excel に限るという意味ではない、という点である。 以前「Excel で」と言ったのは、Excel で見せられる論点をわざわざ箇条書きにしていたからだった。 右には左のまとめに沿った画面を出せばよい。 フォルダの話ならエクスプローラーの画面を出す。 命名ルールのまとめでは、右にエクスプローラーの画を出し、最後の拍で命名ルールの表に替えた。
Git講座では左が画面、右が説明だったが、Excel講座の動画では左がまとめ、右が画面になる。
同じ講座では、ゲシュタルトの法則の図も作り直してもらった。 元の動画10本を SVG で作り直し、まとまりの強さの順に並べた比較ページを見て、「動画にしてみることで、要するにそれが上書きされるってことがよくわかる」と感じた。 そこで、章3の頭に新しい区間として組み込んでもらった。
Windows と Mac の分業
音声の合成とデプロイは、この日も Mac 側のセッション（tmux の claude2）に回した。
- 朝の時点で、頼んであった Git講座の音声合成が Mac で35本終わっていた。Windows への送り返し（音声259件と manifest 35件の計294件）は、Mac 側が本人の OK を待って止まっていた。OK を出すと294件がそろって届いた
- git status の回に書いたフィードバックから、1-0「Git は何をするものか」を独立した回として作ってもらい、その合成も Mac に頼んだ
- 昼過ぎ、Windows で別の作業をするとメモリが一杯になりそうだったので、GitHub に push して Mac にデプロイを頼んだ
- Mac からのデプロイは成功したが、バンドルの余裕が前回の約1,300 KiB から898 KiB に減っていた
- 調べると、Mac のビルドには
public/の静的ファイル一覧（6,226件、259 KiB）が埋め込まれ、Windows のビルドには無かった。今回入ったコードが原因ではなかったので、開発用メモに残した - 簿記講座の読み上げは、全20章分（1,525クリップ）の合成を Mac に頼んだ。明日 Mac で pull して確かめるタスクを、Google タスクに期日 2026-10-13 で登録した
学び
- Git講座で作った形は、簿記講座では「左に図、右に説明」と言い換えるだけで頼めた。ターミナルが図に替わっても、Git講座と同じ作りで組めた
- 画面に収まるよう縮める処理は、丸めの余裕、Codex の指摘、縮めたあとの残りと3回手を入れて、ようやく切れなくなった。確認スクリプトの待ち時間が短いだけの失敗も混じっていた
振り返り
午前の時点で、Git講座の checkout の回は「次へ」ボタンで進んでいた。 午後には、簿記講座の全20章が左に図、右に説明の形で動いていた。 残っているのは、簿記講座の読み上げ音声である。 16:20 の時点で、Mac からの合成の完了報告はまだ届いていなかった。