3読解ガイド生成

3-1　2番から本文だけが渡される。本のタイトルもページ番号も、利用者が誰かも渡されない。3番は「この英文を説明せよ」以上の文脈を持たない。

技術的には　HTTPではなく関数呼び出し。引数は本文の文字列1つと、外部へ添えるための32桁の識別子だけ。3番には専用のパスが無いので、外から /api/... で直接呼ぶことはできない。

3-2　3番本体は、あらかじめ用意された指示書（中1向けに、どう説明するかの決め事）と、受け取った本文を組み立てる。同時に、返してほしい形も用意する。「文ごとに、原文と、区切りを入れた形と、訳と、説明を1〜6項目」という決まった枠。この組み立ては自分の中だけの処理。

技術的には　送るメッセージを2つの役割に分ける。system＝前提として常に効かせる指示書、user＝今回の入力（本文）。分けておくと、本文の中にたまたま命令のような文が混じっていても、指示側と取り違えにくくなる。あわせて、返してほしいJSONの型を用意する。

3-3　外部モデルへ送る。2-2で作られた利用者を表す印も一緒に添える。

技術的には　HTTPSでJSONをPOSTする。「推論にかける手間＝中」「返す量＝中」を指定。やり取りを相手側に保存しない設定にし、2番が作った32桁の識別子を添える。

3-4　モデルから、枠に沿った形で返ってくる。自由な文章ではなく、最初に指定した項目に分かれた状態で返る。

技術的には　型どおりのJSONが返る。文の配列で、各文が通し番号・原文・区切りを入れた形・訳・説明（1〜6項目）を持つ。

3-5　返ってきたものが枠に合っているかを点検する。説明が0項目だったり7項目以上だったり、訳が空だったりすれば、受け取り自体が失敗になる。3番には作り直しの仕組みがない。（6番にはある。）合わなければそのまま止まる。

技術的には　受け取ったJSONを型に当てはめて検証する。配列が空、説明が0項目または7項目以上、訳が空文字 ── どれもこの時点で例外になる。3番は作り直しをしないので、例外はそのまま2番へ上がり、最終的にブラウザへは 500 が返る。

3-6　点検を通ったら、文の番号を1から順に振り直す。モデルが付けてきた番号は使わない。地味な工程だが、これがないと後段が壊れる。

技術的には　配列の並び順に沿って、通し番号を1から付け直す。モデルが付けてきた番号は捨てる。音声の取得が GET /api/guides/{id}/speech?sentence=3 のように、番号をクエリ文字列の鍵として使うため、1から抜けなく並んでいることが前提になっている。番号が飛べば、押した文と違う音声が鳴る。

3-7　2番へ返す。2番はこれを6番の材料にし、7番に保存させる。

技術的には　関数の戻り値として2番へ返すだけ。3番はファイルに何も書かない。