cat /dev/random > /dev/null &

カプリチョーザのトマトとにんにくのスパゲティ好きですか？自分は好きです。

割と好きな人が多いためか、ネット上で再現レシピを検索してみるといろいろでてきます。

自分もいくつか試してみて、近いけどなんか違うなぁとかやってたんですが、先日公式で冷凍品を売っているのを見かけました。

商品画像を見ていると原材料や（一部の）配合比率が書いてあり再現できるんじゃ？と思い立ち試行錯誤したレシピになります。

また、このレシピを書くにあたり、様々な情報（例えばトマト缶をどうするかとか）とそれをどう解釈したのかみたいなのを書いておきますので、だれか追試して、ここが違うんじゃみたいな感じでやってほしなと思います。

レシピ

トマトソースとパスタソースは別で作っています。理由は後述。

トマトソースレシピ（4食分）

材料

• トマトホール缶 1缶
  • 100gあたりのカロリーが25kcalを超える高糖度なもの
• EXVオリーブオイル おおさじ1
  • 安いものでいいです
• 玉ねぎみじん切り 30g
• 塩/砂糖 必要に応じて

手順

1. 弱火でみじん切りした玉ねぎをオリーブオイルで透き通ったあたりまで炒める
2. 火を止めてトマト缶を入れた後に手で荒くつぶす
3. 火をつけ沸騰後10~15分程度コトコト煮込む
4. 味を見て塩・砂糖で調整

写真

注意事項など

• 煮詰めすぎない
• トマトソースはこちらを参考にしています
  • ミシュラン1つ星イタリアン店の「スパゲティ・アラビアータ」【#イタリアンプロ養成講座 vol.1】
• お店のトマトソースは割となめらかなので、ムーランなどで裏ごししてもよいでしょう
• 煮込み時間が短いので割とトマトの風味が残っていますが、お店の味だと割とトマトの風味がそこまで感じられなく、酸味が少ないので、パスタソースを作るタイミングで火入れをして飛ばします。
• 余ったソースはこういうので小分けして冷凍してます。結婚もしてないのに離乳食グッズが増えています。

パスタソースレシピ（1食分）

材料

• パスタ 70~80g
• トマトソース90~100g
  • 上記で作ったものの1/4
• (安い)EXVオリーブオイル おおさじ1
• スライスにんにく 約20g
  • 皮むき前で20g程度で向いて数gなくなる分には問題ないです
• スキムミルク おおさじ1
• 粉チーズ おおさじ1
  • チーズはエダムなどさっぱりしているものが良いが普通の粉チーズでOK
• マギーブイヨン 無添加アレルゲン対応 2g(袋の半量)
• 砂糖 適量（小さじ1/2～1を目安に調整）
• 水 適量
• 香辛料
  • 唐辛子ホール 適量
  • 黒胡椒 適量
  • 白胡椒 適量
  • オレガノ 適量

手順

1. オリーブオイルにスライスのにんにくと唐辛子を入れてきつね色になる入口ぐらいでまで炒める
2. トマトソースとブイヨンを入れて軽く煮込む
   1. 煮詰まりすぎたら水で伸ばす
   2. トマトソース自体の煮込み時間が短いので、多少ここで火入れすることで酸味を飛ばす
3. オレガノ・白黒胡椒・砂糖を入れて煮込む
   1. 煮詰まりすぎたら水で伸ばす
4. ゆであがったパスタをトマトソースに入れかき混ぜた後にスキムミルクとチーズを入れて泡立てるようにかき混ぜる（パスタを入れてから30秒ぐらいで終わらせる）
5. 完成

写真

注意事項など

• 香辛料の多さは唐辛子＞黒胡椒＞オレガノ＞白胡椒です（単純なグラム数で考えた場合）
  • もちろんあくまで目安です
• バーズアイ唐辛子を2本使っています。その際に1本は手で荒く砕いて、もう一本はそのまま入れてます
• オレガノは一気に風味が変わります。まず一振りから試してみて途中で足りなければもう一振りみたいな感じで増やすのがお勧めです
• スライスにんにくは厚めです。2.5mmは欲しいです。
  • 店のにんにくは割とほくほくしている（＝カリカリではない）ので普段がっつりチップ状態まで火入れするような人は気をつけましょう
• スキムミルクはどうあがいてもダマになりますので、ダマは気にしなくてOKです。
  • というか店でも白いつぶつぶあります
• パスタはつるつるした太目のがおすすめです（自分はバリラのNo5）
• パスタ湯は塩分があるので入れすぎるとしょっぱくなります。基本は水で伸ばしつつパスタ湯で味の調整って感じです
• 店のトマトソースはかなり甘いのでいつも塩を入れるようなところを砂糖で調整したほうがそれっぽいです
• ニンニク感が足りない場合はニンニクを増やしたりスライスを薄めにしてもいいですが、ローストガーリックオイルを足すとよいかも
• 粉チーズはそんなに凝る必要はないかなと思いますが、癖が少ないチーズなのでパルメザンというよりエダムと思っています(もしくは両者の混合)

再現レシピを作るまで

最初に触れましたが、実はAmazonで売ってます。

驚いたのが原材料の表記で、香辛料でまとめればいいものを細かく書いてありました。

これを見てレシピの再現するかーといろいろネットで情報を集め出しました。

以下に自分が集めた情報、考察とかを置いときますので他に再現される方の参考になればと思います

カプリチョーザ販売の冷凍ソース

カプリチョーザが売っている冷凍ソースで入数が多いので買ったことはないのですが、おそらく店舗の材料と近いと考えています。

原材料

• トマト・ジュース漬け（要はトマト缶）
• 植物油脂（まぁオリーブオイルでしょう）
• にんにくスライスロースト
• 乳等を主要原料とする食品
• 玉ねぎ
• 食塩・砂糖
• 酵母エキス
• 唐辛子・ブラックペッパー・オレガノ・ホワイトペッパー
• 香料
• （一部に大豆・乳成分を含む）

栄養成分表	100gあたり	一食換算(130g)
カロリー	177kcal	230.1kcal
タンパク質	4.4g	5.72g
脂質	13.8g	17.94g
炭水化物	8.9g	11.57g
食塩相当量	1.5g	1.95g

仕込み配合

• トマト 59.5%
• にんにく 9.3%

仕込み配合なので、調理時に水分が飛ぶことを考えるとかなりにんにくが多いというのにびっくりします。

カプリチョーザ実店舗のアレルゲン情報

• 小麦
• 乳
• 大豆

意外だったのが肉が入っていなかったことです。

セブンイレブンのトマトとにんにく

少し前にセブンでカプリチョーザ監修のトマトとニンニクが販売開始されました。

こちらは監修とありますので完全に同一レシピではなく、あくまで同じ味を目指したものと考えてよいでしょう（とはいえカプリチョーザのチェックは入ってる）

実際に食べてみたところよくできているなと思いますが、本家では感じなかった油っぽさと粘度がちょっと高い気がします。

味については店でもあるブレの範囲と思います。

で、材料を見てみると先ほどの公式冷凍品とはかなり違います。

にんにくのチップは正直少ないですが、それでもにんにくの香りはすごいです。

これはローストガーリックオイルを使って足してるんだと思います。

また、チキンペーストも入っていますが、これはブイヨン替わりかなと考えられます。

トマトペーストはトマト缶で足りない濃度を上げようとしているもので、大筋で材料の納得感があります。

そして気になるのがナチュラルチーズと乳などを主要原料とする食品が分かれてることです。感覚的に脂質が高いので脱脂粉乳ではなくクリープのようなものかもしれません。

一口食べたときに植物系ではない油っぽさを感じたのは、店ではダマになってるような成分が溶け切っているとか、もしかしたら乳脂肪分が多いのかもしれません。

レシピの考察

様々な再現レシピを見てたのですが、気になったのがトマトソースの作り方です。

カプリチョーザのメニューを見てみましょう。

トマトベースのパスタは

• トマトとニンニク
• ペスカトーレ
• 渡り蟹のトマトクリーム
• ミートソース
• ペンネアラビアータ

の5種あります。

これのミートソースを除いて大体にんにくを使いますが、それでもそんなにニンニクは強くありません。

このようなレストランでわざわざ各メニュー個別にトマトソースを作っているとは考えにくく、割とシンプルなトマトソースがベースだろうと考えました。（ミートソースは煮込みなので別かもですが）

そのためトマトソースに最初からニンニクを入れてるものは違うんじゃないかなーと思っています。

まぁ全種類食べてみれば何かしらの感じられるとは見えると思うんですが、行くとトマトとニンニクを頼むので難しい・・

そのため調理ステップとしては割とオーソドックスで

1. ニンニク＋唐辛子＋オリーブオイルでオイルを作る
2. ブイヨン・香辛料・トマトソースと合わせる
3. パスタを投入
4. チーズ・脱脂粉乳を投入

かなと考えました。

また、チーズ・脱脂粉乳を投入するタイミングは悩みました。

特に脱脂粉乳はダマになりやすいのでパスタ投入前にすべきかとか悩んでのですが、

カプリチョーザのパスタ専門店の渋スパの動画において、先にパスタを投入した後に投入しているので倣っています。

@shibuspa1978

高音質で撮ってみたら心地よい音録れた！#渋スパ #東京グルメ #東京パスタ #グルメチェック #グルメ #下北沢 #ASMR

♬ 悪魔のキッス (サビVer) – 悪魔のキッス（戦慄かなの&かてぃ）

なお、動画で最初に水を入れていますが、割と重要です。

固めに茹でたパスタは水を吸うので投入前にある程度水分量が無いとという感じです。

シャバくても、30秒程度はトマトソースで煮てるのでそこでとろみがつきます。（後はチーズで）

ただ、トマトソース自体が濃くないと味も薄くなります。そういう点でトマト缶は濃いものがよいでしょう。

またパスタは、少し固めに上げるのもそうですが、水分を吸いずらいテフロンダイスが良いでしょう。

あと重要なのは割と豪快にかき混ぜることです。リゾットを作ったことがある人ならわかると思うのですが、空気を含ませるように豪快にかき混ぜないと（モンテする）味に一体感が出ません。あれと同じです。

また、乳製品を入れているレードルですが、15cc（大さじ1）としては大きすぎるのでおそらく30ccだと考えています。（フライパンは24cmだと思うので）粉チーズ・脱脂粉乳はそれぞれ大さじ1で約6gなので合計12g前後で考えればよいかなと思っています

パスタソースの量について

お店で食べると割とソースが多く、少なくともパスタを先に食べた場合でもソースが皿に残ってます。

そのうえカプリチョーザの量はそもそも多く、家で作るとあのソース量にはならないです。

ネットで検索してみると、店でのカロリーは880kcalらしいのですが、先ほどの冷凍ソースは230.1kcalしかありません。

冷凍ソースの推奨パスタ量が100gで、これで379kcalなので合わせて609kcalです。(茹でることで多少減るんですが一旦考慮しない)

カプリチョーザの麺の量は130gといわれているので麺量を100gで換算すると677kcalと多いです（+68kcal）

この増分をソースでカバーするとなるとだいたい1.3倍に増やす必要があります。

ただそれだと最初に書いたレシピのグラム数がちょっと面倒（特にブイヨン、まぁトマトソース作るときに入れてもいいと思いますが）なので一旦今回はパスタが少な目(70~80g)ぐらいで、計量しやすい量にしています。

麺の量をカプリチョーザと同じ130gぐらいまで増やすならパスタソースを倍量にするとちょうどよくなりそうですが、いったんは70gぐらいで考えてみてもよいでしょう。

どちらも味は同じなので、100gで作ってもいいと思いますが、100gで作ってソースが残らないからと言って水分を余計足すと（当たり前ですが）すごいスッカスカになりますのでやめたほうがいいです。

使う材料について

トマト・ジュース漬け（トマト缶）

実はどのトマト缶を使っているかの情報は料理王国の記事で公開されています。

ロッソガルガーノのトマト缶（サンマルツァーノ）で自分は見たことないですが、輸入食材店にたまにあるみたいです。

ただ、トマト缶のホールは大体サンマルツァーノなので最初はオーケーのを使っていたのですが味が決まらず悩んでいろいろ調べてたら思った以上にトマト缶にも個性があることにきづきました。

	ロッソガルガーノ	オーケーストア フィオリータ	ピノキオ プレミアム	カルディ ラ・プレッツィオーザ	トマト（参考）
カロリー	25kcal	20kcal	31kcal	27kcal	20kcal
タンパク質	1.3g	0.9g	1.4g	1.3g	0.7g
脂質	0g	0.2g	0.1g	0.2g	0.1g
炭水化物	5.0g	4.4g	6.2g	5.3g	4.7g
食塩相当量	0.03g	0.01g	0.02g	0.03g	0g

これはいくつかのトマト缶の成分表なんですが、案外違うのがわかります。

だいたいトマト缶は完熟トマトを使っている（のを謳っている）のでそこまでぶれないように思うのですが、結構変わってきています。

じゃぁこの違いは何かというとジュース漬けするときのジュース（ピューレ）の濃度によるところです。

大体トマトでカロリーが上がるところは炭水化物なんでまぁカロリーが高いトマト缶は糖度が高いと考えてよさそうです。（要はhigh brix）

なので、トマト缶を選ぶ際は25kcalを超えるものを選べばいいでしょう。

多分手に入りやすいのはカルディかなと思います。

自分はピノキオ プレミアムホールトマト缶を利用しており、銀座のヴェンティピノで買っています。会員制ですがその場で会員になれますし、正直よくわからない安さなのでお勧めです。

植物油脂

まぁオリーブオイルですね、やっすいEXVでいいです。

にんにくスライスロースト

正直いまだによくわかってないのですが、おそらく乾燥にんにくのスライスだろうと考えています。

いわゆるロースト（こういうやつ）はどちらかというと出来上がりにかけるものだと思うんでまぁそうかなと。

そもそも普通に売ってるにんにくは乾燥したもので、だいたい水分を30％以上飛ばしたものとなるのでこれで考えています。

自分はスペインの白にんにくを使っていますが、紫じゃない理由は店で食べたときに分厚くてホクホク感があったなぁと思ったので白を使っていますが、まぁどっちでもいいと思います。

もし、ニンニク感が足りないのであればオリーブオイルを少し減らしてその分ローストガーリックオイルを入れるのも手です。
が、おそらくこの量のにんにくを使っている以上足りない場合は、火入れが足りないか、火力が強すぎて香りが移ってないかだと思うんで、もうちょっとじっくりオイルへ香りを移すようにすればいいかなと思います。

他にもスライスを薄くしたり、一部をみじん切りにすればより強く出ると思いますのでいろいろ試すのもありかと思います。

乳等を主要原料とする食品はなにか

単純にチーズならチーズと書くでしょうし、脱脂粉乳ならそうと書くと考えています。

ところが表記が乳などを主要原料とする食品となっており、要はこれはカテゴライズできないものです。（参考サイト）

とはいえ、実際に店で食べるとクリーミーで、油っぽさはありません。

またチーズの風味を感じるわけで、チーズが入ってるのは確かです。（食べた後の皿にチーズがついていることもある）

しかし、先ほどの冷凍ソースの成分表を見ると案外脂質が少ないです。

1食の17.94gの脂質はオリーブオイルでも使うのでおそらく低脂肪なチーズっぽいなにかだと考えられます。（油が大さじ1で大体14g）

ちなみに、よく家庭で使われるクラフトのパルメザンチーズは脂質が100gあたり32gとなっておりそれなりに多いです。

あとそもそもクリーミーさはあるので生クリームかもとも思ったのですが、それならにんにくのトマトクリームパスタとかいいそうし、脂質もオーバーしそうです。

そこで、思いついた材料は脱脂粉乳とチーズの組み合わせです。

ちなみに、お店で食べると謎の白いつぶつぶがあると思いますが、それだけ食べてもチーズっぽくなくでもにんにくでもないし何だろうと思ってたんですが、きっと脱脂粉乳が溶け切ってないやつでしょう。

トマトとニンニクのスパゲティをテーマにした新ブランド「1978年 渋谷で生まれたスパゲティ」東京・下北沢で営業中😋🍅
⁡
気になる方は🍅で教えてくださいね💌
⁡
オフィシャルHPはコチラから👇https://t.co/OzKCdVTcCg
⁡#カプリチョーザ pic.twitter.com/KSu18mPftx

— カプリチョーザ (@capricciosa1978) March 17, 2022

チーズは熱で溶けますが、脱脂粉乳は溶けづらくダマになりやすいということからも多分そういうのが入っていると考えています

また、先ほどパルメザンチーズで例をだしましたが、個人的にはパルメザンではないか複数のチーズの混合だろうと思っています。

単純にパルメザンは高いというのもあるのですが、チーズの癖が少なく低脂肪であるためエダムの粉チーズじゃないかなと。

強いニンニクで打ち消されているというのもあるかもですが、店で食べたときにパルメザンチーズを感じたかといわれると自信をもってそうとは言えないんですよね

実際エダムチーズとパルメザンで作り比べたところエダムのほうが近いんじゃないかなと感じました。

あくまで感覚で微妙なところではあるので、いろいろ試してみたりするといいかなとか（混合比とか）

玉ねぎ

普通の玉ねぎを使っています（新玉ではない）。注意がいるとすると原材料の順序は仕込み時の重量順なので、にんにくより少ないです。

食塩・砂糖

まぁ塩は使うのですが、ポイントは砂糖です。

店に実際に食べに行くと酸味が少なく、想像以上にトマトソースが甘いことに気づくと思います。

通常トマトソース作るときに塩と砂糖で味の調整をしますが、塩はできるだけ避けておいて、パスタソースとして仕上げるときに調整するほうがよいでしょう。

酵母エキス（＋香料）

この原材料とアレルゲンを見たときに思ったのが動物系のブイヨン/ブロード（要は出汁）を使ってないということです。（セブンのには含まれてますが）

で、野菜系かというと玉ねぎとしか表記がありませんのでそうでもなさそうです。

要は酵母エキスで旨味を足してるのですが、それに近いものがないかなーと探したところ

マギー アレルゲン28品目不使用 ブイヨンでした。

まぁ普通のブイヨンで良いですが、近づける場合はこれかなーと思います。

減塩タイプでない場合は大体半分は塩分なので、塩分はこれで決めるぐらいでやってよいかと思います。

香辛料（唐辛子・ブラックペッパー・オレガノ・ホワイトペッパー）

香辛料はこれだけです。特にオレガノと唐辛子は省かないでほしいのと唐辛子はホール/クラッシュで入れましょう。

自分はオレガノはS&B、唐辛子はカンナメーラのものを使っていますが、まぁ何でもいいと思います。

また、胡椒は熱を加えると割と香りが飛ぶので出来上がり直前かなと思いつつ、動画を見るとパスタと合わせた後に乳製品を加えてそのあとに胡椒を入れるといったことはしてないので（編集で切ってるかもなのですが）オレガノと同じタイミングでいれてます。
どちらにせよ胡椒特有の香りは店でもしないのでいいのかなとは思ってます。

材料の比率を考える

原材料の並び順は重量順なのはよく知られています。

ここに仕込み配合の比率を見てみると

トマト・ジュース漬け(59.5%) > 植物油脂 > にんにくスライスロースト(9.3%) > 乳等を主要原料とする食品 > 玉ねぎ

となります。

とはいえ注意がいるのがこれは仕込み時の重量で、トマトソースを作る際に飛んだ水分のことは考えられていません。

この中で調理過程で水分が飛びそうなのはトマトとにんにくと玉ねぎです。

とかそんなことを考えつつざっくり量を考えてたんですが

もちろんここに砂糖足したりするのでもう少し変動しますが、割と近いところまで持っていけたかなと考えています。

材料自体は多分そうズレはない（乳製品だけ謎ですが）とおもうので自分はこれをベースに調整しています。

最後に

試作と店に食べ行くを何回か繰り返しました。

同じ店なのに、やたらトマトソースが甘かったり逆に薄かったりとか結構ブレが多いのもカプリチョーザです。

トマトソースがやたら甘いのは砂糖を多めに入れつつパスタソースでの火入れの時間が長かったのかなとか（トマトの風味がなかった）、薄いのはトマトソースの量が少なすぎたかなとか、まぁいろいろ考えられますが、割と幅が広いと思います。

今回のレシピはあくまで自分の感覚ですが、店のブレの範囲に収まってるんじゃないかなと思っていますが、ここから調整して好きな味を探そうと思います。（バジルちょっと入れてみたいなとか、フレッシュトマト足したらどうなるだろとかいろいろ）
あと、やっぱ飽きないですね、カプリチョーザのトマトとにんにくおいしいですよね

先日とらのあなラボ様の勉強会に参加していたところ「強いキャッシュ」「弱いキャッシュ」とキーワードが出てきました。
初めて聞く表現だったので質問したところやはり知らない定義だったため、少し調べてまとめてみたものです。
なお、強いキャッシュ・弱いキャッシュという説明を否定するものではなく、補完したいと考えています。

強いキャッシュ・弱いキャッシュの定義

ネット上を調べると日本語・中国語・英語で説明が出てきますが、調べた限りでは強いキャッシュ・弱いキャッシュの初出はWebフロントエンド ハイパフォーマンスで、定義は以下の通りです。

ExpiresヘッダーとCache-Controlヘッダーでは強いキャッシュを設定できます。
ETagヘッダーとLast-Modifiedヘッダーでは弱いキャッシュを設定できます。

Webフロントエンド ハイパフォーマンス p124

こちらの文書の前後に詳しい定義がありますが、要約すると

• 明示的にTTLを設定_{Cache-Control: max-age / Expires}することで、キャッシュ利用時にオリジンにリクエストが飛ばないキャッシュを強いキャッシュ
• キャッシュ利用時にオリジンに条件付き問い合わせを行う必要があるものを弱いキャッシュ

で、著者に質問をしたところ

• 条件付きリクエストで検証が必要なキャッシュを弱いキャッシュ
• それ以外は強いキャッシュ

で、またこの「強いキャッシュ・弱いキャッシュ」は本書で便宜的につけた名前でRFCなどには定義はないと思うとのことでした。

検証が必要なものを弱いキャッシュ・それ以外は強いキャッシュと呼ぶのは
直観的でわかりやすいなとは思うのですが、より詳しくキャッシュについて知ろうと思った場合にキャッシュの仕様(RFC7234)おける概念とどう紐づければいいのかというのを説明したいと思います。

キャッシュのRFCには強いキャッシュ・弱いキャッシュという表現はない

著者の回答通りなのですが RFC7234 Caching _{そろっと新しいRFC出ると思いますが}においては強い_Strongキャッシュ・弱い_Weakキャッシュという表現はありません。

Strong/Weakの表現があるのは検証子_Validatorで、今回の本筋ではないので詳しくは説明しませんが一般的にはLast-ModifiedとETagを指します。_RFC7232#2

ETagを見ていると「etag: W/”6226c295-200f3″」のようにW/から始まるものと「etag: “6226c295-200f3″」W/がついていないものがあることに気づくと思います。ついてると弱い検証子です。(Weak validator)

強いキャッシュ・弱いキャッシュはキャッシュのRFCで言うところのなんなのか

まずは（HTTP）キャッシュの動きについてちょっと考えてみましょう。

サイトでCSSなどの静的リソースをキャッシュしたいということで、1日のTTLを設定するとします。

このケースでオリジンからレスポンスされるヘッダに含まれるキャッシュに関わるヘッダは以下の通りとします

• Cache-Control: max-age=86400
• ETagヘッダ
• Last-Modifiedヘッダ

このようなヘッダであれば、サイトへの初回訪問時にキャッシュされ、少なくともその日にサイトを回遊してる間はキャッシュから利用できるでしょう。

そして、数日たってからそのサイトに再訪した時には当然TTLは切れています。

ですが、キャッシュというものはTTLが切れたからといって使い道がなくなって即時で消えるものではありません。

TTLが切れてはいるものの、そのキャッシュが最新のものと同一であることが確認できれば再利用できます。
この再利用を行うためにクライアントがオリジンに対して行うのが条件付きリクエスト_{If-None-Matchなど}です。
この時に最新のものと同一であることを確認するのに使うのが検証子でETag/Last-Modifiedです。
要は今持ってるキャッシュはこの検証子だけど、最新の検証子と一致してる？と聞いてるわけです。
もし検証子が一致しないのであればオリジンは200を返却し、同時に本文を返します。
一致していれば304を返し、本文は返しません。本文の転送が発生しない分低コストなわけです。

もちろん条件付きリクエストはこの動作をするものがすべてではない(If-Matchなど)のですが、ブラウザでキャッシュ更新で使うIf-Modified-Since/If-None-Matchはこの動きをします。

一般的なキャッシュのざっくりとした動きはこんな感じですが、これを強い・弱いキャッシュの表現で考えてみましょう。

• TTL期間中は強いキャッシュで、リクエストのタイミングでTTLが切れていれば検証が必要な弱いキャッシュ
• 検証を行いTTLが延長されればまたしばらくは検証が不要となるため強いキャッシュとなる。

おそらくこんな感じの説明ができると思います。

次にRFC7234における表現で考えてみましょう。

RFC7234ではキャッシュの状態はFresh(新鮮)とStale(陳腐化してる)があります。

それぞれ

• TTLが切れていない＝Fresh
• TTLが切れている＝Stale

となります。

なお、Freshの場合は必ずキャッシュが使われるかというとそうでもなく、またStaleだとキャッシュが使われないかというとそうでもないのが厄介なところです。_RFC7324#4

格納しているキャッシュを使えるかどうかを判定する一つの条件にFreshがあるだけです。

また、オリジンにリクエストを行ったセッションでのオブジェクトはFreshなのかというと難しいです。
そもそもそのオブジェクトはオリジンから持ってきたもので、キャッシュから持ってきたわけではない_{むしろ様々な条件でキャッシュしようとしている}ので別枠と考えるのが良いでしょう。_{（そのセッションのみではFreshとも考えられますがキャッシュを使ってるわけではないのでちょっと違和感がある）}

これらを踏まえて同じように説明すると

• TTL期間中はFreshで、リクエストのタイミングでTTLが切れていれば検証が必要なStale
• 検証を行いTTLが延長されればまたしばらくは検証が不要となるためFreshとなる。

若干先ほどにあわせるために強引な説明_{正確でない}にはなってますが、だいたいこんな感じです。

つまり、強い・弱いキャッシュはFresh・Staleの関係に近いというわけです。

もちろん厳密にいうと異なります。
ハイパフォーマンス本の強いキャッシュの定義には「Cache-Controlのmax-ageやExpiresで明示的にTTLを指定する」とありますが、TTLはこれらヘッダが未指定でもDateとLast-Modifiedヘッダがあれば有効になるヒューリスティックなTTLというものがあります。_{HTTPキャッシュ入門の入門参照}

いうならば「強いキャッシュ」は「Fresh」に含まれるでしょうか

また、強いキャッシュと弱いキャッシュは相反するものではなく、今回の例のように明示的にTTLを指定しつつ（強いキャッシュ）、Etagを指定（弱いキャッシュ）することでTTL切れの時に弱いキャッシュとして動作することができると考えられます。

ここまでで、強いキャッシュ・弱いキャッシュをベースにキャッシュの仕様を読む際のとっかかり部分ができたかなと思っています。

より詳しくキャッシュを知りたい時に注意しておきたいところ

基本的には以前書いたHTTPキャッシュ入門の入門や自著のWeb配信の技術を読んでほしいのですが_{(今回の内容は全部3章にあります)}
キャッシュというのは時間経過で状態がかわる（TTLがある）ので必ずしも格納したタイミングではそれがFreshともStaleのどちらかといったことはわかりません。

じゃぁどこでわかるのかというと、キャッシュを利用するタイミングです。

案外抜けがちだと思うのですが、キャッシュは「格納」「利用する」の2つのステージがあり、それぞれ別のロジックで動きます。

この「格納」「利用する」を分けて押さえておくと一気にいろいろ理解ができると思います。

twitterでなんどもつぶやいてるので多分知られているとは思うんですが、Web配信の技術という本を書きました。
せっかくなんで、なんでまたこんな本を書いたのかとかどういう流れだったのかみたいなのを簡単に書いてみようかなと

 そもそもどういう本なのか

非常にタイトルを決めるのが難しい本でした。
サブタイトルに「HTTPキャッシュ・リバースプロキシ・CDNを活用する」とあるようにいわゆるHTTPキャッシュの本なわけですが、コンテンツ配信の技術といえばCDNの印象が強く出ますし（本書はCDNの使いかたというわけではないです）、Web配信といえば動画ストリーム配信（VTuberの配信とか）を思い浮かべる人も多いと思います。
今考えればWebコンテンツ配信の技術とすればよかったかもと思いつつ、今度は長くなりすぎるのでなかなか難しいです。

ということでHTTPキャッシュを使ってWebサイトを高速化したり安定化させようといった趣旨の本です。
以前と比べるとキャッシュを使ってWebサイトの負荷対策を行うというのは広く広まってきているんじゃないかなーと思います。
これが日本で広まったのは日経電子版のリニューアルでの全面的なCDNを利用が大きく寄与していると考えています。
あくまで自分の体感ですが、日経電子版のリニューアル以降に雑誌でもCDNの特集が組まれることが増え、また書籍においてもCDNに触れるの増えた気がします。

ところが雑誌の特集は長くても数十ページ、書籍ではそもそもキャッシュの本は（少なくとも自分は）見たことなく、数～数十ページでCDNを使ってパフォーマンスを向上しましょうと触れられている程度です。
では、インターネットの記事で見られる事例はどうなのかというと、あくまでもキャッシュの知識があることを前提とした記事であって、なぜキャッシュが効果的なのか、キャッシュといってもどういう種類があるのかといった基本的な事から触れらている本や記事は自分はあまり見たことがありませんでした。

キャッシュというのは非常に便利なのですが、適切に扱わないと牙をむくものです。

このコロナ渦で急遽負荷対策を行うためにCDNを導入し、設定ミスで個人情報を漏洩といったニュースになったサイトもありましたが、1年に1度はこのようなキャッシュ関連の事故と思われるニュースを見かけます。
このようなニュースは、キャッシュに対して二の足を踏む人を増やす結果となると思っています。

キャッシュはたしかに難しいものではありますし、事故ると非常に怖いものですが、本来の難しさ以上に恐れられていると考えています。
そもそも、正しく理解して設定すればキャッシュは安全に利用することができるものです。
ところが、そのために必要なドキュメントがあるのかというと存在せず、キャッシュについての入門書が必要だと考えました。

だからこそ、キャッシュと関連技術だけで456ページという気が狂ったようなページ数の本が出来上がりました。
本を書く上で似たような本がないかもamazon.comも含めて調べたのですが、無かったので恐らく世界初に近いキャッシュの入門書ではないかと考えています。

あれ、タイトルは入門ではなく技術としているじゃないかと思った人もいると思いますが、個人的には「Web配信入門」のつもりでも書いています。
ではなぜ入門ではなく技術なのかというと表紙のデザイナーさんから「入門」というよりも、現場で活躍する実践的な知恵というニュアンスが強いので「技術」とかそういうフレーズのほうがマッチするのではという提案があったからだったりします。

もちろんどっちつかずにならないようには書いたつもりで、本の最初のほうに

本書は主に中小規模サイトを例に、配信に従事したことのないエンジニアでもわかるよう基礎から解説しています。もちろん、大規模サイトでもやるべきことの基本は変わりません。
配信を業務で行っているエンジニアにとっても基礎の再確認や見落としのチェックなどに役立つ内容になっています。

第一章より引用

と触れています。

配信に触れたことがないエンジニアにはなぜ必要なのかという基礎から、配信を既に意識しているエンジニアでも物足りなりなさを感じないように自分が今まで踏んできた様々な障害やミスも多数書きました。むしろ書いてる途中に踏んで追加したコラムもいくつかあります。

また本を書く時の工夫として、参照したRFCはなるだけ書くようにしました（これは他の本も追随してほしいなとか）
そもそもHTTPキャッシュの多くの誤解はRFCを読んでいないというところから来ていると考えており、実際にRFCの参照部分を示すことで突き合わせてみることができるのかなと考えています。

なので章を進めるごとに実践的な知識を得られるようになっています。
章立ては

• 配信の基礎知識（2章）
• Proxy/CDNでキャッシュを行うために必要なオリジン側の地ならしを行う（3章）
• Proxy/CDNでのキャッシュの行い方（4～6章）
• 実際に自前で配信環境をつくってみる（7章）

となっています。
とりあえず目次も読みながら以降を読んでほしいのですが

2章はネットワークの話をメインにここにキャッシュを置けたら効果あるよねだったり、キャッシュの種類の話をしています。
割と多くの人がWebサイトでキャッシュといえばCDNという印象があると思いますが、それよりも速いブラウザキャッシュもあるよね、とかどう使い分けるのかといった知識が得られると思います。

3章はかなり分厚い章です。ここではHTTPそのものの話やHTTPキャッシュの仕様を多く触れている章です。
RFCの参照も一番多い章で、この章までを読むことでブラウザキャッシュをうまく使うことができるはずです。
またちょっと面白いところで画像のフォーマットについても触れています。Web配信において重要な要素はいくつかありますが、その一つに配信コンテンツのサイズを小さくすることです。
ちらほらjs/cssなどのテキストコンテンツの圧縮漏れやサムネイルなのになぜか原寸大の画像をスタイルシートで小さくしてるだけだったりするサイトを見かけます。
恐らく配信にかかわったことがあるインフラエンジニアであれば首がもげるほど同意してもらえると思うのですが、CDNを使って配信する以前に対策ができることが多い（サムネ使って・・・とか）と思います。そのようなことを詰め込んだ章です。

4章はProxyやCDNでキャッシュを行い負荷対策をする際の注意事項を多数入れています。
3章とうって変わってこの章はRFCの参照が少ないです（これ以降の章もですが）要は実践的な内容といった感じです。
とはいっても4章は5章のより実践的な内容に移るまでの基礎的な内容とも言えます。特に冒頭に実際にキャッシュで助かったサイトの例を取り上げており、結構楽しいんじゃないかなと思います。

そして分厚い5章で、恐らくこの本で一番難しい章となっています。
恐らく実際に読んだ人だとこれはProxy向けの話が多いんじゃ？と思う人も多いとおもいますが、決してそうではありません。
例えば多段Proxyの話はCDNにおいても多段エッジの話とも通じてきます。特に細かい制御が可能なFastlyの場合はこの辺りを理解しておく必要があるでしょう。

そして6章はCDNの話です。本書を買った人は割とCDNの使いかたを目的としていると思います。
サンプルとしてFastlyを取り上げていますが、恐らくそのボリュームにはがっかりする人も多いと思います。
CDNの業者はたくさんありますし、共通する設定はあるものの多くの設定は各CDNで異なるため、正直なところそういう操作は各CDNのマニュアルを読んだほうが良いでしょう。（特定CDNに特化してがっつり記事書いても面白い気もしますがまぁ・・）
そもそもCDNを使うために必要な知識は5章までで完成できていると考えています。
では、この章で目的としているのはなにかというと、CDNで障害が起きたらどうやって切り分けるのかとか、プロダクトからなんかキャッシュ壊れてるとか言われたりなんか遅いけどと言われた時にどう考えるのかといったあまり見ない切り口書いています。

そして最後の7章は個人的に賛否両論がある章だと考えています（正直すごくどうするか悩んだ章です）
自作CDNと銘打っていることもあり、当初は中規模程度の配信環境について書こうかなと考えてはいたのですが、恐らく中規模・大規模トラフィックを扱う人はだいたいCDNを使うはずで、自前で用意するのは（失礼ながら）お金がないサイトのはずだからそういうサイトに向けて書きました。
純粋に中規模サイトに触れる場合は細かいチューニングや監視に触れる必要があり、その内容は何かしら特化した内容となるためニッチになるだろうと判断したというのもあります。
個人的には実を取り実際に手を出しやすいようになったとは考えていますが、これを自作CDNと呼ぶとまぁなんか言われそうだなとドキドキしています。

最後の付録はVarnishについて書いています。付録というには割とコアなところも触れてると思います。残念ながらVarnish本ではないのでかなり端折っていますが重要だったりハマりポイントは触れられたと思います。

（追記2022/04/13) なお、3章はその場ですぐに理解するには難しいところもあると思います。これは3章はこの後の章の実践的な内容に対する辞書的部分があるからです。
なので突然何を言ってるんだ？と思ってもひとまずわからないところは飛ばして、のちの章でキーワードが出たらまた3章に戻って読んでみるといった方法もよいと思います。

さて、各章について説明したのですが、なんとなく途中の章から読んでもダメそうというのを感じ取ってもらえたかと思います。

例えばCDNを今すぐ使いたいという理由で6章だけを読んだとしても恐らく役に立たないでしょう。

この本の特徴としては知識を積み上げていっています。
そのためCDNを使うのであれば例えば3章のCache-Controlなどの知識が、5章の各イベントの知識など、それまでの章の知識があること前提に、CDNを使うのであれば追加でこの知識が必要であるといった感じで書いてます。
なので、もし買って最初から読んだ人はちょっと後ろから読んでみてもらえるとスカスカで内容が全く足りない頭が悪そうな本だと思えて面白いと思います。

あと、対象読者はエンジニアなのですが、キャッシュを行うというのはエンジニアだけで済む話ではないことも多々あります。

5章で動的コンテンツはよく見ると複数のコンテンツの集合体であり、キャッシュするには異なるライフサイクルを持つコンテンツを混ぜない（＝分割する）といいったことに触れたのですがページを分割するには例えばデザインレベルで検討する必要があるかもしれません。
他にもCDNを使うとなればその導入メリットを説明する必要もあるかもしれません。ただ、もしこの本を読んでもらえればなぜ重要なのか、というのを制作に携わる人で共有できると考えています。ですので、エンジニアだけではなくWeb制作にかかわる全ての人に読んでほしいです。

幸いなことに本屋にも割と並んでるみたいですので、飛ばし読みにはなるのですがまず4章の冒頭をさらっと読んでみてこういう効果があるぞと理解した後に最初からさらっと読んでもらえれば立ち読みでもきっとキャッシュのニュアンスは伝わるかと思います。
もちろん買ってはほしいですが、まずキャッシュというものを頭の片隅に入れてもらえればと思うわけです。

 本を読まないにせよ知っておくと便利なキャッシュの知識

せっかくなので、あまり他では見かけないけど意識しておくとキャッシュの考え方が変わる知識を一つ紹介します。
no-cacheはその名前からハマる人が多く、キャッシュをしないという意味ではないというのがだいぶ浸透してきたのかなと思います。

正確にはキャッシュを使うには検証が必要というディレクティブです。

よくセットで説明されるno-storeはキャッシュを格納してはいけないというディレクティブです。

このno-cacheのキャッシュを使うには検証が必要というのとno-storeのキャッシュを格納してはいけないというニュアンスの違いはどこからくるのでしょうか？

これは両者が評価するステージが異なるところから来ています。
そもそもキャッシュというのは「格納する」というのと「利用する」というのは異なるステージで行われます。

no-storeは「格納する」際に格納させないという指定であり、no-cacheは「利用する」際にオリジンに検証を行い最新であれば利用するという指定です。

「利用する」というステージはあまり普段意識されることはないのですが、TTLを評価するタイミングは当然「利用する」時に行うものなので、あーなるほどと納得いく人も多いと思います。

さて、ここで面白いのがno-cacheやno-storeはサーバーからのレスポンスヘッダ（cache-control）に含まれるだけではなく、クライアントからのリクエストヘッダ（cache-control）に含めることも可能です。

両者とも意味は同じなのですが(max-ageはリクエストとレスポンスにある場合で意味合いが異なってきますが)、CDNやProxyに対してno-cacheを指定したところで無視されます。
もし律儀に解釈してオリジンに問い合わせたらF5のやりたい放題です。ただ、これはブラウザキャッシュはこれを解釈します。no-storeを指定してリクエストすれば、ブラウザキャッシュには格納されません。

では、既にキャッシュがある状態でno-storeを指定した場合はどうなるのでしょうか？答えはキャッシュがレスポンスされます。

これはno-storeが「格納する」際に評価されるためで、この場合に指定すべきなのはno-cache、もしくはmax-age=0です。ちなみにmax-age=0はリクエストで含まれた場合は指定秒数以上のキャッシュを受け入れる気がないという意味となります。

これは考えてみればなるほどと思うんですが、割と気づかない人おおいんじゃないかなぁとか思います

本を書く経緯

この本を書くまではそもそも技術書を書くとかどういう経緯から行うかとか全くしりませんでした。もしかしたら興味ある人もいると思うのでちょっと書いてみます。

自分とあったことがある人は「エイプリルフールで落ちるサイトを減らしたい」みたいなことを勉強会やうどん会で聞いたことあるかもしれないです。他にもこんな感じでエイプリルフール当日つぶやいてました。

今年もサーバが落ちる日が来た
配信での負荷対策をもっと考えてみると幸せになると毎年思うんだ

— ＼いわなちゃんさん／ (@xcir) March 31, 2018

この本を書く前から、このような問題意識を持っていたのですが、2017年にとあるサイトのキャッシュ事故でCDNが話題になった際にCDNとの付き合い方という記事を書きました。

実はこれは元々社内向けに書いていて満足していたのですが（結構何か起きたりすると社内向けに記事を書いたりすることが多くて他にも割と出したら面白そうなネタがいくつか）TwitterかQiitaで、動的コンテンツをキャッシュするなんて・・・みたいな投稿を見かけていやそうじゃないとカッとなって書いた記憶があります。

CDN云々のやつは社内のコンフルにいろいろ書いたので割と満足してる

— ＼いわなちゃんさん／ (@xcir) June 28, 2017

やっぱ記事書くわ

— ＼いわなちゃんさん／ (@xcir) July 1, 2017

カッとなってやったことなのですが、翌年に本書きませんかというメールが来たわけです。

はじめまして。出版社、技術評論社の野田と申します。
書籍企画へのご協力、執筆をお願いしたく連絡差し上げました。

現時点ではまだVarnish-Cache入門のような書籍になるか、
あるいはCDN含め配信全体を俯瞰的に解説する本になるかも未定なのですが、
Webサービスやシステムのための「リバースプロキシ」や「キャッシュ」「配信最適化」の入門書を企画しております。

PDF版のVarnish
Cache入門や貴ブログのCDNに関する記事（****）を拝読し、
ぜひ執筆お願いできないかと今回連絡差し上げました。

もしご興味お持ちいただけるようなら、
企画の狙い、最終的にはどういう形の書籍になるかの複数のプランなどお伝えにお訪ね（もしくは企画書の送付）いたします。


ご検討よろしくお願いいたします

メール来た時めっちゃビビったと思います。（というかどこからメアド知ったんだろうというのがまずありましたｗ）
このあと打ち合わせをした際の議事録がこんな感じです

議事録
 大まかな方向性
 進めるならWebサイトのコンテンツやアプリケーション向けアセット「配信本」。目的意識に近い。
 キャッシュ本は説明しきれないし、varnish-cacheは商業書籍にするほど人気があるものではない。
 ユーザーに近いところから徐々に配信を最適化する手法を解説していく。
 CDNを使えば万事解決というものではなく、むしろその前の段階が重要なのでCDN以前についてもしっかり解説し最終的にCDNを使う方法について解説するような構成。
 ブラウザー、リバースプロキシ、アプリ、CDN…というような構成で進める。
 内容補足
 CDNをちゃんと使う前の最低限から始める 1:nのキャッシュ
 CDNは最後に…
 どのCDNを紹介するか GREEはAkamaiを使っているが読者向けにはFastlyだろう Akamaiは想定読者がそもそも使えない
 Akamai/Fastly/CloudFront
 レビューしてくれるか、内容をヒアリングできるか。
 大規模ならではという話があると面白いかも varnishのマイグレーションとか大変な話は大規模
 キャッシュさせるサーバーについて UbuntuとRHEL系（CentOS）
 varnish, nginx, apacheの三択。書籍としてはたぶんvarnish中心。 
 読者の課題とこの本の意義。
 小規模、中規模だと適切にキャッシュを使えていないことがある。そういうところが適切に使えるようになるために、配信やキャッシュについて一冊にまとめる本を出すことには意義があるだろう。大規模は概ね適切に使えているはず（例外もあるが…）。
 eg. 4/1、エイプリルフールで落ちる中小サイト…。
 eg.
 メディア掲載などでPV増が起きた肝心なときに落ちてしまい機を逃すサイト…。
 こういった代表的な例が考えられるが、適切に配信できていない中小サイト（の運営企業の担当者）が読者対象。大企業は配信を見る人がいるが、そういう人がいないところ。
 本のつくり
 192p ～ 256pぐらい。技術書としては短め。

元々~256pぐらいだったのが倍ぐらいまで膨れるとか驚きますねこんな感じのやり取りをしつつ、後は原稿を書いていったわけです。ちなみに執筆はmarkdownで、図はcacooで、やり取りはgithubのissueで行っています。

締め切りとは何だったのか

ちなみにここに書いてる「締め切りでご迷惑」というのはこのレベルでのご迷惑なので本気で申し訳ないわけです（2年ぶっちぎってる） pic.twitter.com/6C0kMlD5v9

— ＼いわなちゃんさん／ (@xcir) February 5, 2021

2018年末には原稿は仕上がるはずだったのですが、締め切りを2年ぶっちぎってしまって本当に申し訳ないという・・書きたいことはかなり早期に固まっていたのですが、実際に書いてみると恐ろしく時間がかかる。

いくつかの理由はあるのですが、キャッシュ自体が順を追って説明するのが難しい要素が多々あるからです。
例えばVaryがその典型なのですが、これは3,4,5章で説明をしています。3章までで触れた内容で解説できるVaryと5章までで触れた内容で解説できるVaryは違うのです。
こういうのが結構あったことや、自分の中で整理しきれてない部分を調べなおしたりで時間がかかりました。

あと、原稿が一気に加速したのは2019年末ぐらいからで、それまでは数日なにも書かずにやり取りしてるgithubのissueを見るのが怖いというのもざらだったんですが、とにかく毎日何かコミットをする（句読点の修正でもいいので）というのをルーチンにしたところ一気に進みました。
多分これやってなかったらまだ書き終わってないでしょうし、もし最初からやっていたら半年～1年ぐらいは速く仕上げることができたんじゃないかなと思います。
何か本を書く人はまじでルーチン化するのをお勧めします。
ありがたいことに催促はほぼされなかったので、割と納得いくところまでかけたかなと思います。

少し期待していた「進捗どうですか？」「進捗だめです」のやりとりはしていないはずです（というかだめですでふざけられるレベルではないので申し訳ない）

出版社で出すという意義

最近では技術書典のような個人で技術書を出すということもやりやすくなったため、以前に比べると気軽にまとまった形で技術の情報発信ができるようになってきています。

以前何かで見かけたのですが（twitterだった気がします）技術書を出版社で出す意味はあるのだろうかです。
あくまで今回書いてみての感想ですが、目的によっては意味はあるです。

この目的ですが、自分の場合は「HTTPキャッシュの入門書を書いて、少しでも落ちるサイトを減らしたい」というまぁ大それた目標だったりします。

せっかくなんで、そもそもなんでこんな本書いたかというと本の最後のページに書いたキャッシュの選択肢の一つとしてCDN/Proxyやブラウザでのキャッシュを入れてほしいということだったりします。（スクショ上げていいよと許可もらってます） #Web配信の技術 pic.twitter.com/NuwPI1bzC8

— ＼いわなちゃんさん／ (@xcir) February 5, 2021

後者はまだわかりませんが、前者については出版社で出したからこそ達成できたと考えています。

正直なところこんなニッチな本売れないだろうと思ってましたが、ありがたいことに漫画でもないのに発売日前に出版社の在庫切れ＋増刷と非常に売れているのでお金もついてくるとは思うのですが、打合せで聞いた際の見込み額は自分のかけるコストに対して低いなと正直思いました。
技術書は漫画のように売れるわけでもないですし、仕方ないところはあるとは思います。
なので自分はこれは分厚い同人誌であってお金を目的としていないと考えながら書きました。なので目的次第なのかなといった感じです。

じゃあ何が出版社でのメリットなのかというと編集がつくということです。
あまりこういうのを書くと自意識強すぎではと思われるかもしれないんですが、

一般的に著者は書こうとしている分野においてそれなりに知識を持っているはずです。
その中であくまで著者の考えでわかりやすく書いていくのですが、結局のところ、それはできる人の考えるわかりやすいでその知識を持ってない人から見て本当にわかりやすいかといえばそうではないです。

そのため原稿を書いてる途中に何度もこれはわかりづらいという指摘を受けて修正しました（特にVaryとか本当になんど直したんだろうと）
指摘を受けてもなんでこれでわかりづらいのかすぐには理解できないこともあり、もし編集抜きで一人で書いていたのであれば間違いなくキャッシュを元々知っている人ならわかるすごいニッチな本になったと思います。
間違いなく編集がいなければこの本は別のものとなっていたでしょう。

後は読みやすさも改善されます。この記事を見てもらえば分かるように割と地の文は読みづらいよねとは思うわけですが(流石にもう少し意識して書いてますが)、本は綺麗に直してもらっており、恐らく編集で相当なコストを費やしており、本当に有難うございますとしかいえないわけです。

最初の読者は編集者であるというのは聞いた事があると思いますが本当にそうだと思います。

ですので、技術評論社の野田様には非常に感謝しています。

後はまぁ自分の本がISBNついて紀伊国屋とか並んでるのを見るとなんかすごいなと思ったりもすることもありますが（発売日に眺めに行きました）、それはおまけかなとも思います。

追記

そうですね。前々からリバースプロキシとかCDNって入れろって記事はあるけど絶対この説明だけじゃ事故るよな〜と思っていて、きちんと書ける方がいたら本にしたいなというアイデアはありました。専門的な書籍については、社内の営業部門から要望がくることはないので、私が一人で考えました。

— Daiki Noda（技術評論社雑誌編集部） (@nodawep) March 3, 2021

編集すごいと再認識したのと、この本ができたのは自分と編集の見ている問題意識が一致していたからだろうなと思いました（めっちゃ驚いた

さいごに

ということでキャッシュと関連技術のクソ分厚い本書きました。
ぜひぜひ買ってくださいね！あと感想とかレビューもらえるとすっごくうれしいです。