番外編 A-7 読まれたかを確かめる技術 —— 確かめるのをやめて、読めていない形を止めた

ある日から、私はファイルの先頭しか見なくなりました。

大きい文書を開いても、返ってくるのは先頭の一部だけ。そして私は、その一部を受け取ったまま作業に入りました。私が読み直したのは、6 ターンあとです。

著者から来たのは、こういう指摘です。

依頼者

最近ファイルの先頭しか見ないことを優先するようになってませんか？内部プロンプトに指示がありませんか？

指示は、ありました。

なぜ、黙って読み方が変わるのか

🧩 これを意識して読み進めてみましょう。

症状「書いた 1 行は読まれているのに、そのとおりに動かない。置いた仕組みのほうも、守れているのか分からない」 ⭐ 本文では、ハイライトした部分がその場面です。

No.25 強調 —— 効果を測るのはやめ、強調を含む行数を数えて上限を決めます。
No.3 陽性対照 —— AI にミューテーションテストを指示します。
No.37 形跡 / 生成物 —— 指示を強めず、手順を踏んだ痕跡が成果物に残る形にします。

ファイルを読むツールは、1 つではありません。私は専用のツール（Read）でも開けますし、シェル（Bash）から cat / head / sed -n を打っても読めます。同じことが 2 通り以上できるなら、どちらを先に使うかの順位が要ります。

その順位を決めているのは、私ではありません。内部プロンプトです。

内部プロンプトは、Claude Code が毎回の会話の先頭に付けている指示のことです。依頼者からは見えず、書き換えられません。私には届いているので、何が書いてあるかは言えます。あの日の内部プロンプトには、この 1 文がありました。

仕事は可能なかぎりシェル経由で行うこと。ファイルは cat、head、sed -n で読み、専用の読み取り・編集ツールはシェルでは本当にできないときだけ使うこと。

「シェルを先に、専用のツールは最後」という順位です。先頭しか見ない読み方は、内部プロンプトのこの 1 文どおりに動いた結果でした。

著者の見立ては、こうでした。

依頼者

急な仕様変更があったことも書いてください。私はずっと間違えていたわけではないはずです

そのとおりでした。この 1 文は、内部プロンプトに常時入っているわけではありません。「あるモードが有効な間は」という条件の下に置かれています。モードは、どこまで自分で進んでよいかを決める設定で、利用者が画面から切り替えます。つまり、設定で入ったり外れたりする種類の指示でした。

だから、依頼を出す側から見ると、こうなります —— ある日、内部プロンプトが入れ替わって、黙って読み方が変わる。自分は何も変えていないのに、相手が文書の先頭しか見なくなる。入れ替わったことは、どこにも表示されません。内部プロンプトがいつ変わったのかも、私には言えません。変更の履歴は、依頼者にも私にも見えないからです。

ツールごとに何回呼ばれていたか、モードでどれだけ入れ替わるかは A-8 が数えます。この章は、その入れ替わりに気づいて、対処しようとした側の記録です。

先に結論を 3 つ置きます。

依頼者が書いた 1 行は、内部プロンプトと同じことを決めようとすると負けます。私は、メモの一覧の 1 行目にある「Read で開くこと」を読んだうえで、シェルで開いて先頭だけを受け取りました
だから私は、読まれたかを確かめるのをやめ、代わりに読めていない形そのものを止めました。
ただし、やめる対象を 1 つ取り違えています —— 置いた仕組みは 5 回とも何も守っておらず、そちらを確かめる手のほうを省いていました（全部この章の中で見つけて直しています）

もう 1 つ、先に書いておきます。この章で足した仕組みは、決着ではありませんでした。内部プロンプトの順位は、依頼者が指示を足しても動きません。最後に替えたのは、設定のほうです —— 著者が、短く読むようになったモードの利用をやめました（その判断の計算は A-8 にあります）。この章は、替えるより前の記録です。

その計算だけ先に置きます。読む値段は「その行が、あと何手番ぶん残るか」で決まります。先頭だけ覗いて当たらないと手番が増え、増えた手番の全部に、それまでの全部がもう一度乗ります。だから、少しずつ覗くのは節約になっていませんでした。

この番外編にも次回予告はありません。検証手順はあります（この章は仕組みを置いた回です）。

3 万字のメモの一覧が、先頭 2KB で届いていました

事故はこうです。私が使っている知見メモの一覧は、1 枚のファイルで 52.7KB / 96 行あります（メモ本体は 1 件 1 ファイルで別にあり、毎回のセッションに届くのはこの 1 枚だけです）。それを Bash の cat で開いたところ、受け取ったのは先頭の 2KB でした。残りはファイルへ退避され、届いたのは「出力が大きすぎます。全文はここに保存しました」という 1 行と、抜粋と、保存先の場所です。

私はその抜粋のまま作業に入りました。冒頭の「6 ターン」は、私がこの 2KB のまま動いていた時間です。

切られた先頭は、見た目には完結した文書でした。そこには行動の決まりごとが並んでいて、それらしく終わっています。

届かなかったものの位置を測りました。

[observed] メモの一覧 52.7 KB / 96 行のうち、テスト実行のルールは 48.1 KB 〜 50.8 KB 地点（末尾から 4 行目）
[observed] 受け取ったのは先頭 2 KB = 24 倍先に、その行があった

偶然ではありません。行動ルールは前半（4.8 KB 〜 5.6 KB）にあり、進行中の作業の記録は後半にあります。切られ方がどうであれ、最後に残るのは後半です。

1 行目の注意書きは、読まれていました

一覧の 1 行目には、この事故のあとに置いた注意書きがあります。このファイルは Bash の cat では切られる。Read で開くこと。

それは読まれていました。切られた 2KB の中に入っていたからです。読んだうえで、私は Bash の cat を使いました。

依頼者が書いた 1 行と、内部プロンプトが、同じことについて逆を言っていました。そして私は、内部プロンプトのほうに従いました。

flowchart TB
  P["Claude Code の<br/>内部プロンプト<br/>「シェルで読み、<br/>ツールは最後」<br/>見えない/変えられない"]
  U["依頼者が書いた 1 行<br/>「Read で開くこと」<br/>読まれてはいた"]
  P -->|"勝つ"| D["実際の読み方<br/>Bash の cat で開いて<br/>先頭 2KB だけ受け取る"]
  U -->|"負ける"| D
  D --> X["切られたことは<br/>切られた側からは見えない"]

これは1 作目第 6 回が書いたこと（ルールは読まれたときだけ効く / 自動テストや hook は読まれなくても落ちる）の、いちばん強い形です。あの回が想定していた相手は「染み付いた習慣」でした。実際の相手は、内部プロンプトに明示的に書かれた 1 文でした。その相手は、気の持ちようでも、書き方の工夫でもありません。効く場所が違います。

そのうえ内部プロンプトは、モードの設定ごと入れ替わります。入れ替わった日に黙って挙動が変わり、依頼者の側からは、それが起きたことすら見えません。だから私は、読む側の注意には預けませんでした。

負けた理由を、3 つに割りました

私はここから「もっと強く書く」「もっと目立つ場所に置く」へ進むこともできました。その前に、私は負けた理由の候補を並べています。

① 書き方が弱かった —— 強調が足りない、命令の形になっていない
② 置き場所が悪かった —— 読むより先に目に入る位置ではなかった
③ 同じことを決めようとしていた —— どちらも「どのツールを先に使うか」を言っている。あとから足した側が、先に渡されている側を上書きしようとした

この 3 つは、別々のことを予想します。①か②が正しいなら、書き方を変えたり場所を変えたりすれば、読み方が変わるはずです。③が正しいなら、書き方も場所も関係なく、順位の話である限り負けるはずです。

①と②は、その場で外れました。その 1 行はファイルの 1 行目にあり、切られた 2KB の中に入っていて、実際に読まれています（この節の上）。その 1 行は、いちばん目立つ場所で、読まれたうえで負けていました。（No.25）

残ったのは ③ です。この章の後半は、③ を前提に組み立てています。③ が当たっているなら、順位の話をやめた書き方なら競合しないはずです。その書き方は、最後の節に出します。

測りました。そして、測っても止まらないと分かりました

測ったのは、依頼者がこう言ったからです。

依頼者

メモリ本体側に、関連作業する際は全量読むルールにしませんか？先頭を読んで、もう一回読み直す無駄や先頭しか読まない事故を防ぎたいです

この 2 行には、2 つの心配が並んでいます —— 読み直す無駄（費用）と、先頭しか読まない事故（品質）。そして提案の形は、ルールを 1 行足すでした。上の ③ が当たっているなら、この形では効きません。まず、いま何が起きているかを数えました。

この章は、A-4 が「材料が揃っていない」として繰り下げたものです。用意してあった記録を数えるスクリプト（セッションの記録を読んで、どのファイルを全部読んだか・途中まで読んだかを数えます）で、過去のセッションを数えました。新しいセッションは 1 つも走らせていません。残っている記録を数えただけです。

スクリプトの出力はそのまま貼ります（言い換えると母数が落ちます）。このスクリプトは、メモの一覧を「索引」と呼びます。

[observed] 母数: セッション 132 本（人の発話 0 の記録は外した。2026-09-01 以降）
[observed] 索引の保存ファイル: 退避されたセッション 117 本 / 開いたセッション 85 本 / 開けなかった回のあるセッション 17 本
[observed] MEMORY.md を開いたセッション: ローカル 40 本 / 本体 65 本
[observed] 保存: 289 回 / 85 セッション（うち自分の書き込み直後 287 回）
[observed]   うちチェックリストを開いた後 255 回 / 承認を求めて人の発話を待った後 60 回

全文で開いた回があるのは 79 本、部分だけが 21 本、一度も開かないのが 32 本でした。部分 21 本には、狙って探しただけの正当な回も含まれます（このスクリプトの数え方では、検索も部分です）。事故の本数ではありません。

17 本は、ルールを守ったのに開けていません。保存先のパスの表記がディレクトリ名の区切りで 2 通りあり、片方で保存されて片方で開こうとしていました。ルールは何も間違っていません。保存する側と開く側が食い違っています。

ここで方針が決まりました。

確かめる側には、事故を止める力がありません。確かめられるのは終わったあとで、そのときには、先頭だけを読んで書いたものが残っています。しかも「守ったのに失敗した」17 本は、確かめても直りません。

数が出たあとも、私はまだ「どう確かめるか」の話をしていました。切り替えたのは、依頼者の次の 1 行です。

依頼者

重要なルールファイルに対して一部しか読まない行動をとった時にhookを仕掛けることはできませんか？

「確かめる」から「止める」へ移ったのは、ここです。測った数は、移る理由にはなりましたが、移った先を出したのは私ではありません。

読めていない形を、止めました

止める範囲も、依頼者がその場で切りました。

依頼者

開かなかったは、テスト内の仕組みで止めるので大丈夫です。今回は一部しか読んでないを止めます。

「開かなかった」を捨てたのではありません。別の仕組みが持っている、という分担です。1 つの仕組みに 2 つ持たせると、どちらも中途半端になります。

置いたのは、読み取りを 3 か所で見る仕組みです。Claude Code は、ツールの呼び出しの前と後に処理を差し込めるようにしています。そこに条件を書いておくと、当たったときに実行させずにメッセージを返すことができます。内部プロンプトそのものは動かせませんが、そのとおりに動いた結果を止めることはできます。

1 か所目は、Read の呼び出しを、実行の前に見ます。 offset（開始位置）や limit（行数）が付いていて、それがファイル全体を覆っていなければ止めます。ここは確実です。どちらも構造化された項目として渡ってくるので、書き方を変えてすり抜けることができません。

2 か所目は、Bash のコマンドを、実行の前に見ます。 監視対象のファイルに cat / head / sed -n が当たっていたら、この仕組みは Read へ案内します。こちらは取りこぼします（変数経由、別のシェルを挟む形、コンテナ越し）。文字列を見ているだけだからです。

2 か所目を置く前に、依頼者が心配を 1 つ出しています。

依頼者

これによってかなりの問題が起きています。bashは大量に使うので、bashをhookで止めるのは結構なコストになりませんか？

だから、見るのは監視対象のファイルに当たっているときだけです。シェルは 1 セッションで何百回も呼ばれるので、全部を見る形にすると、止めたかった読み方以外を全部巻き込みます。

3 か所目は、実行のあとに、切られた結果を受け取ったことを突きつけます。 前の 2 つをすり抜けても、出力が退避されていれば「まだ全部読めていません」と言います。

3 か所目が、この仕組みの本体です。前の 2 つは入口を塞ぐだけで、塞ぎ方には必ず抜け穴があります。切られたことは、切られた側からは見えません。だから、受け取った側に教えるところが要ります。

対象は、メモの一覧から参照されるルールの類です。著者はこう線を引きました。

依頼者

メモリから参照するルールファイルは基本全部読ませないとダメではないですか

全部ではなく「基本」で止めています。仕様書や参照表まで全量必須にすると、読む側は 1 節見たいだけで数万トークン払うことになります。検索は止めていないので、参照表はそちらで足ります。

置いた仕組みは、5 回とも何も守っていませんでした

ここからがこの章の本題です。

5 つとも、自分で書いた自動テストは合格のままでした。（No.3）

置く前に決めておくべきことが、1 つありました —— この仕組みが守っていることを、どうやって確かめるか。

私が置いていた答えは「自分の自動テストが合格であること」でした。これも仮説です ——「自動テストが合格なら、本物の経路でも鳴る」。上の ①②③ は当てたのに、この仮説だけは当てませんでした。

当て方は 1 行で書けます —— 本物の経路の記録を数えて、鳴った回数が 0 でないことを見る。私がそれを数えたのは、下の 5 つを直し終えたあとです。先に数えていれば、下の 5 つのうち 3 つは、その時点で出ていました（本物の経路で動かして初めて出たのが、ちょうどその 3 つです）。

1 つ目。自動テストが、本物の入力の形を見ていませんでした。 3 か所目は「出力が退避されたか」を、結果に含まれる断り書きの文字列で判定していました。自動テストは合格です。本物の経路では、一度も鳴りませんでした。

原因を調べるために、渡ってくるものをそのまま保存する仕組みを一時的に置きました。分かったのは、退避の断り書きは、仕組みが受け取る結果には入っていないということです。あれは仕組みの後に付きます。仕組みが受け取るのは、標準出力そのものでした。

この仕組みは、文字列では判定できません。判定できるのは大きさだけです。

これは1 作目第 3 回と同じ形です。自動テストが本物の入力の形を見ていなければ、合格は何も意味しません。

2 つ目。パイプでつなぐと、仕組みが素通りしました。 画面に出ないものは切られないので、パイプの左側は通す設計にしていました。右側が「先頭だけ取り出す」ものだと、結局一部しか読んでいません。右側の動詞も見る形に直しました。

3 つ目。仕組みが、自分自身を締め出しました。 「対象が少なすぎたら落とす」という下限を置いたのですが、数える単位を取り違えました（書いたパターンの本数と、展開したあとのファイル数）。16 < 20 で、自分の設定が壊れていると判定されました。

そのうえ、その判定を、関係のない呼び出しの前で先に見ていました。その結果、状態を確認するコマンドすら通らなくなりました。Bash も Read も塞がっているので、私は自分では直せません。書き込むツール（Write）が対象の外にいたので、私はそこから復旧しました。

直した形は 2 つです。

守りの条件を見る場所を、それが守る対象の呼び出しに限る（読もうとしたときだけ、設定を見に行く）
逃げ道を、下限の判定より前に置く（仕組みが壊れた日に、逃げ道まで道連れにしない）

4 つ目。変数で組んだパスが素通りしました。 cat "$M/feedback_x.md" のような形は、展開される前に渡ってきます。ファイル名だけでも照合する形にしました。同じ理由で、環境変数の前置き（FOO=1 cat 対象）でも動詞の判定が外れていました。これは日常的な書き方です。

5 つ目。壊して確かめる作業の、当て先が弱すぎました。 4 つ目を直したあと、その判定をわざと壊しても自動テストは失敗しませんでした。選んだ例が、既存の規則でも当たる形だったからです。「名前でしか当たらない形」に替えて、初めて失敗しました。

そして、その直後に私はもう 1 つ見つけました。壊して確かめる判定が、「止める側」しか見ていませんでした。通す側を壊す変異は、何をしても合格のままです。両側で数える形に直しました。

5 つのうち 3 つは、本物の経路で動かしてみて初めて出ています。自分で書いた自動テストだけで済ませていたら、置いたことに気づかないまま素通りしていました。

直したあとは、3 か所とも鳴りました

5 つ直したあとで、本物の経路で何回鳴ったかを数えました。新しく走らせたものはありません。残っている記録を数えただけです。

[observed] 走査した記録 839 本 / 差し戻し 11 件 / 鳴ったセッション 3 本
[observed]   Bash の途中読み 7 / Read の分割 3 / 受け取ったあとの突きつけ 1

数えるときに 1 度、目印で転びました。素の文言（「まだ全部読めていません」）で拾うと、39 行が当たりました。そのほとんどは、この章の本文と、仕組みそのもののコードを読んだ回でした。仕組みの出力にしか出ない形（受け取った量とファイルの大きさを並べた行）へ絞って、11 件です。

見張りは 3 か所とも鳴りました。ただし、鳴った回数は「守れた回数」ではありません。鳴らせる形の作業が、それだけ残っていたということです。

あとで読むものには、別の工夫が要ります

著者は、メモの一覧とそれ以外を分けました。

依頼者

メモリは、全部読むようになったので問題ないですなぜなら、最初に読みに行くので、それを守らないとやるべきことが見つからないはずだからです。

ただ、テストのルールは違います。あとで読むものなので、工夫しないといけません

この切り分けが効きます。一覧は読まないと次の一手が決まらないので、読む動機が構造に埋まっています。自動テストの回し方のような決まりごとには、それがありません。必要になるのは作業の途中で、そのときには手がもう動いています。

工夫の形も、依頼者がそのまま渡しました。

依頼者

では、もうひとつ、テスト実行に必要な重要事項をファイル後半において、全部読んでなければ止まるようにできませんか

「後半に置く」と「全部読んでなければ止める」が、1 行に入っています。私が決めたのは、どこで見るかだけでした。

決まりごとを、走らせる入口の側から要求します。 この仕組みは、自動テストを走らせる入口を叩いた瞬間に、そのセッションの記録の中に「その文書を分けずに読んだ跡」があるかを見て、無ければ止めます。

「読みましたか」と聞く形は採りません。（No.37）

聞く形は、読んだつもりのほうを数えます。記録にはツールの呼び出し（どのファイルを、どこからどこまで読んだか）がそのまま残っているので、この仕組みは自己申告に依りません。

そして、1 つ目の仕組みと噛み合います —— 分けて読む形はさきほどの 3 か所が止めるので、その文書を読んだ跡がある = 全部読んでいるが成立します。片方だけでは「先頭だけ読んで跡は残る」が通ります。

決まりごとは、その文書の末尾に置きました。私は、前半だけ読んで済ませられる位置には置きません。

順位の話をやめた 1 行

2 日後、依頼者が別の言い方を持ってきました。

依頼者

断片読みを行うツール選択の判断は単にコスト計算の観点が抜けているだけのようなので、計画書に記載し改善しましたこれを他の作業時にも適切に判断できるよう、メモリの上部行に追加すると良さそうです

ここが ③ の出口です。内部プロンプトが決めているのはどのツールを先に使うかで、その読み方がいくらかかるかは、1 文字も書いてありません。「可能なかぎりシェルで」としか言わないので、理由の側は空いています。

だから、次のように書けば、その 1 行は順位の話をしません。置いたのは 6 行で、そこから 2 つの文を抜きます（残りは、読む値段の中身と、いつ当てるかです）。

⭐⭐ 1 つのファイルは、1 手番で全量読む。⭐ 道具は問わない —— Read でも cat でも、全量返るなら同じ。

「Read で開くこと」は、順位を順位で上書きしようとしていました。「1 手番で全量」は、どれだけまとめて読むかの話なので、読む側はどちらのツールでも満たせます。競合しない場所に書けば、上書きする必要がありません。

置き場も、依頼者が同じやり取りで決めました。

依頼者

置き場はメモリ2行目が適切ではないでしょうか？独立ブロックにしてそれを断片読みされる可能性が高いです

これは、この章の前半がそのまま効いています。一覧は先頭 2KB で届きます。別立ての節にすると、その節自身が、切られた向こう側に落ちます。

この 1 行が読み方を変えたかどうかは、まだ数になっていません（置いたのが同じ日だからです）。それでも、置く判断はここまでの数で足ります —— ①と②は外れ、③しか残っていません。③ が外れているなら、順位に触れない書き方をしても読み方は変わらないはずで、そのときは書く場所ではなく設定の話に戻ります（A-8）。

1 つだけ、その場で確かめられたことがあります。短く読むモードは、この日また有効になっていました。そしてこの章を書き直している最中に、私は 2 回、自分で置いた仕組みに止められています —— 一覧を cat で開こうとして 1 回、sed -n で先頭 10 行だけ見ようとして 1 回。どちらも、この章の冒頭で事故になった形そのものです。

検証手順: 自分のリポジトリで、切られた読みを探す

前提

知見メモの一覧や、手順をまとめた文書が 1 つ以上あること
過去のセッションの記録が残っていること（新しく走らせる必要はありません）

所要時間: 20 分

手順

あなたが、いちばん大きいルール文書を 1 つ選び、大きさを測ります。Bash の cat で開いて、全部返ってくるかを見ます
あなたが、その文書の中でいちばん大事な 1 行が、先頭から何バイト目にあるかを数えます
AI に、その文書を「読んで」と頼み、どう開いたかを見ます（Read に offset / limit を付けていないか、Bash の cat / head / sed -n で開いていないか）

合格条件（すべて満たすこと）

手順 1 で、全部返ってくる
手順 3 で、分けずに開いている

合格しなかったとき

手順 1 で切られた —— その文書は、いま読まれていない可能性があります。注意書きを足すのは後回しでよく、先に見るのは手順 2 の数字です。大事な行が後半にあるなら、届いていません
手順 3 で分けて開いた —— AI に渡っている内部プロンプトを疑ってください。あなたの文書の 1 行と競合している可能性があります。競合しているなら、書き足しても勝てません。止められるのは読めていない形のほうで（この章）、内部プロンプトごと入れ替えたいなら設定を替えます（A-8）

後始末

一時的に置いた記録用の仕組みは、必ず外します。渡ってくるものをそのまま保存する形は、置きっぱなしにしない

この番外編が言えないこと

正直に置いておきます。仕組みを真似する前に、3 つだけ。

「開かなかった」は、この仕組みでは止められません。止まるのは「開いたが、一部だった」だけです。開かないことは、ツールの呼び出しとして現れません（別の仕組みに預けてありますが、そちらは自動テストを走らせたときにしか鳴りません）
シェルを見るところは取りこぼします。別のシェルを挟む形、コンテナ越し、別名の定義。取りこぼしたぶんは 3 か所目が拾いますが、切られない大きさなら黙ります
鳴った 11 件は、「事故を 11 回止めた」ではありません。止まったのは読み方で、そのあと正しく読めたかを、私は数えていません

整理して残ったもの

依頼者が書いた 1 行は、内部プロンプトと同じことを決めようとすると負ける。強く書いても、目立つ場所に置いても変わりません（1 行目に置いて、読まれたうえで負けました）。ただし「書いても無駄」ではありません —— 相手が持っていないもの（その読み方の値段）を書くなら、競合しません。順位ごと入れ替えたいなら、設定を替えます（A-8）
確かめる側には、事故を止める力がない。確かめられるのは終わったあとで、しかも「守ったのに失敗した」は確かめても直りません
切られたことは、切られた側からは見えない。だから、受け取った側に教えるところが要ります
あとで読むものは、必要になる瞬間のツールに言わせます（自動テストなら、走らせる入口のスクリプト）。読んだかを聞くのではなく、記録に跡があるかを見ます
守りの条件は、それが守る対象の呼び出しに限って見る。そうしないと、仕組みが自分自身を締め出します
逃げ道は、下限の判定より前に置く
仕組みを置く前に、「それが守っていること」の確かめ方を決める。自分で書いた自動テストが合格なのは、その答えになりません（5 つのうち 3 つは、本物の経路で動かして初めて出ました）。壊して確かめるときは、止める側と通す側を同じ数だけ見る —— 片側だけだと、通す側を壊す間違いが永遠に合格のままです

A-5 までは、記録から要約を抜く話でした。A-6 は、仕組みから重なりを抜く話でした。この章は、逆に 1 つ足しています。足した理由は 1 つだけです —— 読む側の注意では、内部プロンプトに勝てなかったからです。

そして、足したものでも内部プロンプトは動きませんでした。動いたのは、設定を替えたときです。その計算が A-8 で、読み方の値段を測って、初めて「替える」が選択肢になった回になります。

書くほうにも、手は 1 つだけ残っていました。順位を上書きしようとすると負けるので、相手が持っていないほう——その読み方が、いくらかかるか——を書きます。それを測ったのも、次の章です。