インタラクティブな図で変化する状態を知る

静止画だけでは見えない関係

前の章では、実装の細部に入る前に、変更の目的や直感を示すことが大切だと説明しました。この章では、その直感をさらに分かりやすくする方法として、**インタラクティブな図（interactive figure）**を扱います。

静止画は、ある一時点の状態を見せます。しかし、システムの理解には、「操作すると何が変わるか」を見ることが必要な場合があります。そのとき、学習者が図を操作できるようにすると、隠れていた関係が見えるようになります。

大切なのは、動くものを置くこと自体ではありません。操作によって、説明したい仕組みが見えることです。珍しさや楽しさだけを目的にした動きは、理解を助けるとは限りません。

岩をドラッグして状態を確かめる

話者は、二つの岩があるシミュレーションを例にします。学習者は岩をドラッグして動かせます。すると、岩の座標（位置を表す数値）が表示され、Zレイヤー（前後の描画順を表す層）も変化します。その結果、どちらの岩が手前に見えるか、どちらが後ろに見えるかという関係も変わります。

ここで起きている流れは、次のように整理できます。

1. 学習者が岩をドラッグします。
2. 岩の位置に関係する座標が変わります。
3. Zレイヤーの値や順序が変わります。
4. 画面上の岩の前後関係が変わります。

この流れによって、座標やレイヤーが単なる説明文の言葉ではなく、画面の変化と結び付きます。つまり、学習者は「位置を変えると、描画の前後関係も変わる」という関係を、自分の操作を通して確かめられます。

図1　岩を動かすと、座標や深さの情報と、手前・後ろの関係が変化するシミュレーションです。

この画像は、二つの岩を持つシミュレーションと、座標・深さのデータを示しています。近くの時点の画面では、岩を動かすことにより表示値と前後の配置が変わります。したがって、この図は「操作が内部の状態と見た目の結果を結び付ける」という説明を支えます。シミュレーションの正確な座標モデルや、Zレイヤーの実装方法までは、この資料だけでは確認できません。動画の該当箇所（09:01）

操作できる説明を共有ページに置く

話者は、このようなシミュレーションをNotionのページに置く例も示します。エージェントは、共有ページのHTMLブロックに、インタラクティブなシミュレーションを入れられます。これにより、説明を読む人はページから離れずに操作できます。また、共有ページなら、チームの人が同じ説明を見て、コメントを付けながら理解を深められます。

ここでも、HTMLブロックを使うことが目的なのではありません。共有された説明の中に、必要なときだけ操作できる学習用の図を置くことが目的です。エージェントがコードを書くだけでなく、人がコードや仕組みを理解するための道具も作れる、という考え方です。

図2　Notionのようなページに、二つの岩の位置と前後関係を調べるシミュレーションを置いた例です。

この画面には、二つの岩と、位置・深さに関する表、そして手前か後ろかを示す情報が見えます。停止中の画面でも、説明文だけでなく、状態を確かめるための操作画面が共有ページに埋め込まれていることが分かります。画面の細かなUIや、実装の詳細は、ここからは断定できません。動画の該当箇所（09:11）

役に立つインタラクティブさ、頼りすぎるインタラクティブさ

補足すると、インタラクティブな図は、常に静止画より優れているわけではありません。変化を見せる必要がない内容まで操作式にすると、学習者は操作に気を取られます。説明が不十分なまま動く図だけを渡せば、理解の代わりに試行錯誤へ頼ることにもなります。話者も、インタラクティブさが雑なものになったり、理解の不足を隠す松葉づえ（crutch）になったりする可能性を認めています。

一方で、静止画では分からない仕組みを、操作と結果の対応によって見せられるなら、インタラクティブな図は有効です。判断の基準は「動くかどうか」ではなく、「その操作が、理解したい関係を見えるようにするか」です。

この考え方は、直感を先に示すという前章の原則につながります。岩を動かして状態の変化を見れば、細かなコードを読む前に、システムがどのように振る舞うかの感覚を作れます。そして後の章で扱うマイクロワールドは、この考え方をさらに広げ、学習者が小さな環境の中でシステムを体験できるようにします。