WEBサイト
「これは、いつ、この場所に来たのか」に答えられなかった
archives/132で、俺は本番のサムネイル画像が消えていた話を書いた。原因を追う途中、俺はあるファイルを前にしてこう聞かれたら答えられないことに気づいた。「このファイルは、いつからここにあるのか。最初からここで作られたのか、それとも、どこか別の場所からこの場所へ運ばれてきたのか」。見た目だけでは、まったく分からない。中身も同じ、サイズも同じ、名前も同じ。それなのに、片方は「その場で作られた」もので、もう片方は「よそから運ばれてきた」ものだということがある。
最初、俺はこの問いに対して「聞いても仕方がない」と思いかけた。ファイル自体には、名前と中身しか書かれていない。作られた経緯なんて、誰かが記録に残していない限り分かりようがない、と。だが、それは正確ではなかった。誰も意識して記録に残していなくても、ファイルシステム自身が、勝手に記録を取り続けていた。
調べてみると、この問いに答える手段が、ファイルシステムの中にもともと備わっていた。ファイルには「更新時刻」以外にも、もう一つ別の時刻が記録されている。今日はその時刻の正体と、実際に当サイトの画像でやってみた結果を書く。
この話は、一見するとサーバーを直接いじる人だけの話に思えるかもしれない。だが「バックアップから復元した画像は、いつのものか」「引き継いだサイトの、この設定ファイルは誰がいつ持ち込んだのか」「複数の担当者が触っているサイトで、今日 誰が何を動かしたのか」といった問いは、サイト運営に日常的に付きまとう。名前も中身も同じに見えるファイルが、実は別々の場所から来ている、ということは珍しくない。見た目で判断がつかない以上、判断の材料は「記録」にしかない。
更新時刻と、状態が変わった時刻は、別のもの
多くの人が「ファイルの時刻」と聞いて思い浮かべるのは、更新時刻（modification time、略して mtime）だと思う。中身を書き換えるたびに動く、あの時刻だ。だが、たいていのファイルシステムは、これとは別にもう一つの時刻を記録している。状態変更時刻（change time、略して ctime）だ。名前が似ているうえに、日本語に訳すとさらに紛らわしくなる。定義を、まず一次情報で確認しておく。
更新時刻が答える問い
Linux の公式マニュアルには、この2つの時刻の違いが、次のように書かれている。
"The mtime timestamp is not changed for changes in owner, group, hard link count, or mode."
（日本語訳: 更新時刻は、所有者・グループ・ハードリンク数・モードの変更では変わらない）
つまり更新時刻が答えているのは「このファイルの中身を、最後に書き換えたのはいつか」という、ただ一つの問いだけだ。誰が持ち主かが変わっても、権限の設定が変わっても、更新時刻は動かない。
状態変更時刻が答える問い
一方、状態変更時刻の定義は、これだ。
"This is the file's last status change timestamp. It is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.)."
（日本語訳: これはファイルの、最後に状態が変化した時刻である。書き込みによって、あるいは所有者・グループ・リンク数・モードなどの情報を設定することによって変化する）
状態変更時刻は「中身が変わったとき」に加えて、「持ち主が変わったとき」「権限が変わったとき」にも動く。つまり更新時刻より広い範囲の変化を拾っている。そして、これがそのまま今回の話の起点になる。ファイルを別の場所へコピーすると、たいていコピー先では所有者が新しく設定し直される。だから状態変更時刻も、そこで新しく付き直る。
2つの時刻が、同じ値を示すとは限らない理由
ここで一度、日常の感覚に立ち戻ってみる。ファイルを普段まったく動かしていなければ、更新時刻と状態変更時刻は、たいてい同じ値のままだ。中身を書き換えていなければ、所有者も権限も変わらないことが多いからだ。逆に言うと、この2つの値が揃っている限り、そのファイルは「作られてから、誰にも動かされていない」可能性が高い。
だが実際の現場では、ファイルは思っている以上に動かされている。バックアップの復元、サーバーの引っ越し、権限の一括変更、共同編集者による配置し直し。どれも「中身は1文字も変わっていない」のに、状態変更時刻だけが動く操作だ。だからこそ、この2つの時刻を並べて見ることに意味が出てくる。1つの値だけを見ていては、こうした「中身は変わっていないのに、何かが起きた」という出来事を、そもそも観測すること自体ができない。
同じ名前が、OSによって別のものを指していた
この2つの時刻を調べていて、ちょっと驚いた発見があった。同じ名前の項目が、動かす環境によって、まったく別の意味を持っていた。
Windows だけ、意味が違う値を返していた
プログラミング言語 Python の公式マニュアルを確認すると、この項目についてこう書かれている。
"The st_ctime fields return by os.STAT() and os.lstat() on Windows are deprecated. In a future release, they will contain the last metadata change time, consistent with other platforms. For now, they still contain the creation time, which is also available in the new st_birthtime field."
（日本語訳: os.STAT() と os.lstat() が Windows 上で返す st_ctime フィールドは非推奨になった。将来のリリースでは、他のプラットフォームと同じように、最後に状態が変化した時刻を返すようになる。現時点では、まだ作成時刻を返しており、その値は新設された st_birthtime フィールドでも取得できる）
つまり、これまで Windows 上では「状態変更時刻」という名前の項目が、実は「作成時刻」を返していた。同じ英語の項目名が、OSによって別の意味を持っていたということだ。これは今まさに直っている途中で、今の版では「非推奨」という扱いになり、本来の意味を持つ値は「作成時刻」という新しい名前の項目に移された。
これは、開発する側が間違えていたという話ではない。Windows のファイルシステムには、もともと「状態変更時刻」に相当する項目そのものが存在しなかった。だから、その言語の項目を実装するときに、いちばん近い意味を持つ「作成時刻」の値を代わりに割り当てた。長い間それで運用されてきたが、他のOSと動きを揃えるために、今回の変更に踏み切ったということのようだ。項目の名前は変わっていないのに、中身の意味だけが後から追いついてくる。こういう移行期には、同じ名前を見ても、バージョンによって別のことを測っている可能性を、常に頭の隅に置いておく必要がある。
「今は仮の値」と、公式が認めている
この訂正が重要なのは、名前が同じだからといって、環境をまたいで同じものを測っているとは限らない、ということを、公式の文書自身が認めている点だ。同じ言葉で書かれた項目でも、それが指しているものが違うことがある。だから「◯◯時刻」という名前だけを見て判断するのではなく、その値が実際に何によって動くのかを、一次情報で確認する必要がある。
ここまでに出てきた3つの時刻を、一度整理しておく。
| 呼び名 | 測っているもの | 動く条件 | コピーで運べるか |
|---|---|---|---|
| 更新時刻 | 中身が最後に書き換わった瞬間 | 書き込み・上書き | 運べる（多くの道具が対応している） |
| 状態変更時刻 | 中身・所有者・権限のいずれかが最後に変わった瞬間 | 書き込みに加え、所有者や権限の変更でも動く | 運べない（コピー先で新しく付く） |
| 作成時刻 | ファイルが最初に作られた瞬間 | 作られたときだけ | ファイルシステムが対応していないと、そもそも記録されない |
なぜ、これで「運ばれてきた」ことが分かるのか
状態変更時刻が「所有者や権限の変更でも動く」という性質が、そのまま「運ばれてきたかどうか」を見分ける手がかりになる。ファイルを別の場所へコピーする道具は、更新時刻を保つように作られていることが多い。だが状態変更時刻まで保つ道具は、探した限りでは見当たらなかった。
運ぶ道具の仕様書を読んでみた
ファイルを転送する定番の道具の公式マニュアルを確認すると、こう書かれている。
"Be aware that it does not include preserving ACLs (-A), xattrs (-X), atimes (-U), crtimes (-N), nor the finding and preserving of hardlinks (-H)."
（日本語訳: これには、アクセス制御リスト（-A）、拡張属性（-X）、アクセス時刻（-U）、作成時刻（-N）の保持、およびハードリンクの検出・保持は含まれていないことに注意してほしい）
これは「まとめて全部を保つ」設定の説明の一部だ。保持されない項目として、アクセス制御リストや拡張属性、アクセス時刻、作成時刻までは名指しで挙げられている。だが状態変更時刻は、保持されない項目の一覧にすら、言葉として登場しない。
選択肢にすら入っていない
もう一つ、別の定番の転送道具の公式マニュアルも見てみた。所有者・グループ・更新時刻・権限といった属性を、それぞれ個別のオプションで保持したり無視したりできる作りになっている。ただし、状態変更時刻を保持する専用のオプションは、一覧のどこにも見当たらなかった。むしろ「アクセス時刻を保持する」というオプションを使うと、副作用として状態変更時刻の方が動いてしまう、という注記まであった。
つまり状態変更時刻は「保持しないと決められている」項目ですらない。そもそも「保持する／しない」を選べる対象の一覧に、最初から入っていないのだ。理由は単純で、状態変更時刻はファイルシステムそのものが「今、この場所で何が起きたか」を記録するためのものであって、「元の場所で何が起きていたか」を運ぶための項目として設計されていないからだ。
考えてみれば、これは筋の通った設計だ。状態変更時刻の役目は「このファイルシステム上で、いつ何が起きたか」を記録することにある。もし転送する道具が、コピー元の状態変更時刻をそのまま持ち込めてしまったら、コピー先のファイルシステムの記録が、実際には起きていない出来事で埋まってしまう。運ばれてきたという事実そのものが、記録から消えてしまうことになる。だから「運べない」のではなく、「運んではいけない」項目だと考えた方が近い。
「保つ」ではなく「新しく付く」
だからコピー先のファイルは、更新時刻こそ元のファイルと同じ値を持っていても、状態変更時刻はコピーした瞬間の時刻に新しく置き換わる。この「更新時刻は同じなのに、状態変更時刻だけ新しい」という組み合わせが、「このファイルは、よそから運ばれてきた」ことの手がかりになる。
当サイトの画像で、実際にやってみた
定義だけ確認して終わりにするのは、この連載の趣旨に合わない。実際に当サイトの画像で試してみた。
対象と、確かめ方
対象は、当サイトのブログ記事に使っているサムネイル画像、147本。それぞれについて、更新時刻と状態変更時刻を取得し、2つが一致しているか、それとも状態変更時刻の方が後になっているかを調べた。更新時刻の方が状態変更時刻より後になることは、通常は起きない（中身を書き換えれば、状態変更時刻も同時に動くため）。だから見るべきは「一致しているか」「状態変更時刻だけ後になっているか」の2択になる。
実は、サイト全体で同じように数えると165本が見つかった。だが、そのうち18本は別の企画で使っている初期サンプル画像で、今回の「ブログ記事のサムネイル」という対象とは性質が違う。数える対象をそろえずに165本のまま話を進めると、対象外のものまで含めた数字になってしまう。だから今回は、対象を「ブログ記事のサムネイル」に絞った147本で数え直した。同じ手段で数えても、何を数えているかによって答えが変わる、というのは、この連載で何度も向き合ってきたことでもある。
結果 ── 102本と45本
結果は、147本のうち102本が「2つの時刻が一致」＝その場で作られたと見られるもの、残り45本が「状態変更時刻だけ後」＝よそから運ばれてきたと見られるもの、だった。全体のおよそ3割が「運ばれてきた」側に分類されたことになる。公開する前にこの数字を見たとき、正直、思っていたより多いと感じた。1本や2本、たまたま経路の見直しで動いたものが混ざる程度だろうと予想していたからだ。
102本のうち44本は、同じ1日に集中していた。おそらく、まとめて生成した作業の跡だと思う。「その場で作られた」という判定は、必ずしも「1本ずつ、その都度その場で作られた」ことを意味しない。まとめて生成する処理を、その置き場所で直接実行すれば、それも「ここで作られた」に分類される。逆に言えば、この方法だけでは「1本ずつ手作業で作られたのか」「まとめて自動生成されたのか」までは区別できない。分かるのは「よそから来たかどうか」までだ。
45本の「運ばれてきた」側を、運ばれた日ごとにまとめると、こうなる。
| 運ばれた日 | 本数 | 備考 |
|---|---|---|
| 2026年6月10日 | 22本 | 最も多くまとまって動いた日 |
| 2026年6月20日 | 19本 | |
| 2026年8月21日 | 3本 | archives/132で書いた対応と同じ日 |
| 2026年3月11日 | 1本 | |
| 合計 | 45本 |
日付でまとめると、見えてくるもの
1本ずつ見ているだけでは、45本という数字は「ばらばらに、少しずつ増えていった」ように見えるかもしれない。だが日付でまとめると、実際には数回のまとまった作業で一気に増えていたことが分かる。6月10日と6月20日の2日間だけで、41本、全体の9割以上を占めている。これは「毎日少しずつ運ばれている」現象ではなく、「特定の作業のタイミングで、まとめて運ばれた」現象だということだ。
8月21日の3本は、archives/132で書いた、消えていたサムネイルを差し替えた作業とちょうど重なる。あのとき俺は「今回の記事の分だけ」を直したつもりだったが、状態変更時刻で数え直すと、同じ作業の中で3本が動いていたことが分かった。自分がやった作業の範囲を、自分の記憶だけでなく、記録の側からも数え直せる、ということでもある。
6月10日と6月20日の2日間については、正直に書くと、何の作業だったのか、今回の調査だけでは特定できていない。時期が近い2日間にまとまって動いていることから、何らかの一括作業があったとは推測できるが、それが具体的に何だったかまでは、この時刻の記録だけでは分からない。「覚えている作業」と「実際に起きた変化」は、必ずしも一致しない。時間が経ってから記録を読み直すと、自分の記憶にない変化が見つかることがある、ということ自体が、今回の一番の収穫だったかもしれない。人の記憶は薄れるが、ファイルシステムの記録は薄れない。分からないことは分からないと書いた上で、これは今後、別の記録と突き合わせて確かめたい。
これだけでは、断定できない
ここまでの話だけを読むと、状態変更時刻さえ見れば何でも分かるように思えるかもしれない。だが、それは言い過ぎだ。
状態変更時刻が動く、他の理由
状態変更時刻は「所有者や権限の変更」でも動く。つまり、ファイルを一度も動かしていなくても、後から権限だけを直せば、状態変更時刻はその時刻に更新される。バックアップからファイルを復元した場合や、ファイルシステムを別の場所へ引っ越した場合にも、値は変わりうる。だから「状態変更時刻が更新時刻より後」という一点だけを見て「これは運ばれてきたものだ」と言い切るのは、正確ではない。あくまで「疑うきっかけ」であって、「確定した証拠」ではない。
今回の測定結果でいえば、45本という数字は「運ばれてきた本数」ではなく、正確には「運ばれてきた可能性がある本数」だ。この45本の中に、権限の変更だけで状態変更時刻が動いた本物の当たり外れが混ざっている可能性は、この測り方だけでは排除できない。今回は運ばれた日付が3月・6月・8月と、はっきり複数のまとまりに分かれて出てきたことと、そのうち8月の3本は実際に自分がその日に動かした作業と一致することから、大部分は本当に「運ばれてきたもの」だと判断できた。だが、これは今回のデータの特徴からそう言えるのであって、状態変更時刻という項目そのものが常に「運ばれてきた」ことを保証してくれるわけではない、という点は、切り分けて理解しておく必要がある。
「本当の作成時刻」は、また別の場所にある
そもそも「このファイルが最初に作られたのは、いつか」という、いちばん知りたい値そのものは、更新時刻にも状態変更時刻にも入っていない。Linux の一部のファイルシステムには、これとは別に「作成時刻」という項目が用意されている。
"The file's creation timestamp."
（日本語訳: ファイルの作成時刻）
ただしこの項目は、専用の取得方法を使い、かつファイルシステム側が対応していないと取得できない。標準的な確認手段には、最初から含まれていない値だ。だから多くの現場では、この値に頼らず、更新時刻と状態変更時刻の組み合わせで代用している。
2つの記録が食い違って、初めて手がかりになる
この「1つの記録では断定できない」という限界は、実は別の分野ではもっと徹底して扱われている。デジタル機器の調査を専門にする現場では、ファイルの時刻がわざと書き換えられていないかを調べる技術が発達している。ある専門機関の解説記事には、こうある。
"Windows does not typically update this set of temporal values like it does with those in the "$STANDARD_INFORMATION" attribute, and they frequently correspond to when the file was created, moved, or renamed"
（日本語訳: Windows は、通常この一連の時刻情報を「$STANDARD_INFORMATION」属性の方のようには更新しない。そしてこちらは、ファイルが作成・移動・改名されたときの時刻と一致することが多い）
要点はこうだ。Windows のファイルシステムには、実は独立した2種類の時刻の記録が存在する。片方は普段よく確認される値で、もう片方はあまり更新されない値。時刻を書き換える道具は、たいてい片方しか直さない。だから2つを突き合わせると、食い違いが残り、それが手がかりになる。
この考え方は、当サイトの測り方とまったく同じ形をしている。更新時刻という1つの記録だけを見ても、何も分からない。状態変更時刻という、もう1つの独立した記録と突き合わせて、初めて「食い違い」が意味を持つ。1つの数字ではなく、2つ以上の記録の食い違いを見る。それが、この手がかりの本体だ。
これは、専門的な調査の現場だけの話ではない。サイト運営の日常にも、まったく同じ構造の場面がある。例えば「このページのアクセス数が急に減った」という出来事を、アクセス解析の記録だけで判断すると、原因を取り違えることがある。検索順位の記録、サーバーへのアクセス記録、ページの表示速度の記録。それぞれ別々の場所に残っている記録を並べて、初めて「本当に何が起きたのか」が見えてくる。1つの記録は、それ単体では「何かが起きた」ことしか教えてくれない。「何が起きたのか」まで教えてくれるのは、たいてい2つ以上の記録を突き合わせたときだ。
時刻に頼らない、という設計もある
ここまで「時刻を読み解く」話をしてきたが、視点を変えると、そもそも時刻に頼らないという考え方もある。ソフトウェアの構築を、誰が・いつやっても必ず同じ結果になるようにしよう、という取り組みがある。その解説にはこうある。
"Timestamps make the biggest source of reproducibility issues. Many build tools record the current date and time."
（日本語訳: タイムスタンプは、再現性の問題の中で最も大きな原因になっている。多くのビルド道具は、現在の日付と時刻をそのまま記録してしまう）
この取り組みでは、時刻をあてにする代わりに、あえて時刻を固定してしまう。時刻は「証拠」として使うにはそもそも不安定なものだ、という考え方が、こちらの分野では既に主流になりつつある。今回の話とは逆方向の発想だが、「時刻は思ったより頼りにならない」という前提は、共通している。
もう一つ、パッケージの管理ソフトウェアの現場では、少し違うやり方も使われている。インストールした時点の記録を別に保存しておき、後から「今のファイルは、インストールしたときと比べて何が変わったか」を機械的に突き合わせる、という方法だ。公式の解説にはこうある。
"Verifying a package compares information about the installed files in the package with information about the files taken from the package metadata stored in the rpm database."
（日本語訳: 検証とは、インストールされているファイルの情報と、パッケージのメタデータとしてデータベースに保存されている情報とを、比較することである）
この方法は「時刻を読み解く」のではなく、「最初の状態を、別の場所に控えておく」というやり方だ。時刻という間接的な手がかりに頼らなくても、最初の記録さえ残しておけば、後から確実に突き合わせられる。今回の話とは方向性が違うが、目的地は同じだ。「今のこのファイルが、本当に想定通りのものか」を確かめたい、という一点に、いろいろな分野が別々のやり方でたどり着いている。
明日から、自分のサイトでできること
ここまでの話を、明日から使える形に落としておく。
確かめ方は、標準のコマンド1行で足りる
確かめるための特別な道具は要らない。多くのLinux環境には、ファイルの時刻をまとめて表示する標準のコマンドが最初から入っている。例えば、対象のファイルに対して stat -c '%y %z %n' 対象ファイル名 のように打つと、更新時刻と状態変更時刻が並んで表示される。
出力の1列目が更新時刻、2列目が状態変更時刻、3列目がファイル名になる。この2つの列を見比べるだけで、今回の話がそのまま実践できる。複数のファイルをまとめて確認したいときは、対象のディレクトリに対して、ファイルを1件ずつ列挙しながら同じコマンドを繰り返せばいい。プログラムの中から確認したい場合も、多くの言語の標準機能に、この2つの時刻を取得する関数がそのまま用意されている。特別な集計の仕組みを新しく作らなくても、今すぐ試せる。
1本だけ、実際に突き合わせてみる
まず、自分のサイトで「別の場所からコピーして配置しているファイル」に心当たりがあるなら、その1本だけでいいので、更新時刻と状態変更時刻を並べて見てほしい。一致していれば、その場で作られたもの。状態変更時刻の方が後になっていれば、どこかから運ばれてきたものだ。1本だけでも、思っていたのと違う結果が出ることがある。
そして、もし複数のファイルで同時に確認できるなら、1本ずつではなく、まとめて日付ごとに数えてみてほしい。今回、当サイトの45本も、1本ずつ見ていた段階では「ばらばらに増えた」ようにしか見えなかった。日付でまとめて初めて、特定の作業のタイミングに集中していることが分かった。個別の1件では見えなかったものが、まとめて数えると見えてくる、というのは、この連載でも繰り返し出てきた形だ。
もう一つ、覚えておいてほしいのは、この方法は「疑わしいものを見つける」ための手段であって、「正しいと証明する」ための手段ではない、ということだ。2つの時刻が一致していたからといって、そのファイルの中身が正しいとは限らない。あくまで「別の場所から動かされた形跡がない」ことが分かるだけだ。中身が正しいかどうかは、また別の確認が要る。手段を万能だと思い込まないことが、この手のチェックでは特に大事になる。
そして、公開作業や配置作業のあとに「本当に今日、意図した本数だけが動いたか」を確かめたいときにも、この考え方は使える。件数を数えるだけでなく、その中身が壊れていないか、リンクが切れていないかまで一緒に確かめたいなら、当サイトの🔧 サイト内のリンク漏れを確かめるチェックツールで、公開直後に一括して確認しておくと安心だ。作業の前後を目で見比べたい場合は、🔧 表示状態のスクリーンショットをまとめて撮って比較できるツールも用意している。
もう一つ、今回の話と少し違う角度からの点検になるが、サイト全体で「テンプレート由来のリンクが、意図せず広い範囲に影響していないか」を確かめる考え方も、当サイトのテンプレート由来のリンクが、サイト全体を巻き込む ── 発リンクを点検する12項目（サイドバー404の実例つき）で書いた。どちらも「1本だけを見て安心しない」「全体を数え直す」という点では、根っこが同じだ。
当サイトの現在地
今回の記事に関連して、当サイトで実際にやったこと・これからやることを、正直に書いておく。
- ✅ 実施済 当サイトのブログ記事に使っているサムネイル画像、147本すべてを、更新時刻と状態変更時刻の比較で確認した
- 🔧 着手中 「運ばれてきた」と分かった45本のうち、古い版のまま運ばれていないか（今の内容と一致しているか）の個別確認。今回の記事の時点では、全数の確認は終えていない
- 📋 予告 今後、画像を配置する作業をするたびに、直後にこの方法で「今日、実際に何本動いたか」を確認する手順として加える
まとめ ── 見た目が同じでも、記録は同じではない
今回いちばん印象に残ったのは、更新時刻という、毎日当たり前のように見ている値の隣に、もう一つ別の時刻がずっと記録され続けていた、ということだった。存在を知らなければ、一生気づかないまま終わる項目だ。そして、その項目の名前自体が、動かす環境によって別のものを指していたという事実も、正直に言うと調べていて驚いた。
今回分かったのは「102本はここで作られ、45本はよそから運ばれてきた」という数字そのものより、「見た目では絶対に分からないことが、記録を2つ並べるだけで分かることがある」という、もっと単純な事実の方だった。
そして、この記録は誰かが今回のために新しく作ったものではない。ファイルシステムは、意識していようがいまいが、ずっと前からこの2つの時刻を記録し続けてきた。今回やったことは、その既にある記録を、ただ並べて見ただけだ。新しい仕組みを何も足さずに、既にそこにあった情報を読み直すだけで、これだけのことが分かる。今日、自分のサイトのどこかにある「別の場所からコピーして置いているはずのファイル」を、1本だけでいいので、実物の時刻と突き合わせてみてほしい。
関連 archives（連載軸として読む）
- archives/132「仕組みは在った。運ぶ気もあった。探す形が違っていた」── 今回の話の直接のきっかけになった、サムネイル消失の調査記録（2026年8月21日）
- archives/131「『使われていないコード』は証明できない」── 「指定した場所」と「実際に動いている場所」が別だった話
- archives/130「『0件』は安心ではない、『N件』は危険ではない」── 同じ調べ方の針が、両方向に倒れうることを書いた回
- archives/129「『自分のサイトに、同じ記事が2本ないか』を5分で確かめる」── 測り方を変えるだけで、答えが3倍違って見えた回
- archives/105「1,000件の宿題を6日間で畳んだ」── 大量の作業を、あとから「本当に全部終わったか」数え直した記録
