日記のエントリを読むと、リモート画像は再度読み込まれるのか？
通常、画像のURLが含まれる日記のエントリは、アプリやブラウザが表示する際にその画像をリクエストすることがあります。しかし、それは毎回リモートサーバーから画像がダウンロードされることを意味するわけではありません。有効なブラウザキャッシュから提供される場合もあれば、アプリが別の方法で画像を処理している場合もあります。現実的な最初の確認事項は、そのエントリがWebのURLを指しているのか、それとも日記と一緒に保存された画像を指しているのかという点です。オフラインテストはある程度の手がかりにはなりますが、ネットワークリクエストが一切発生しなかったことを証明できるわけではありません。
Markdownにおける画像リンクは何を意味するのか？
標準的なMarkdownでは、`` のような画像構文は、画像のURLによってその画像を指定します。[CommonMarkの画像チュートリアル](https://commonmark.org/help/tutorial/08-images.html)では、完全なWebのURLが有効な画像の指定先として明示されています。この構文自体は、画像が日記内にコピーされたことやローカルに保存されたことを示すものではありません。
リーダーがそのエントリを表示するとき、ソフトウェアはそのURLを画像のソースとしてレンダリングする場合があります。Webページでは、ブラウザの `<img>` 要素がドキュメント内に画像を埋め込み、その `src` 属性が表示するリソースを指定します（[MDNの `<img>` リファレンス](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img)に記載されている通りです）。リクエストがリモートサーバーに到達するかどうかは、キャッシングや特定のアプリ、ブラウザ、ネットワーク経路によって異なります。
閲覧するたびにブラウザはサーバーと通信するのか？
すべての画像を毎回新たに取得しなければならないという決まったルールはありません。ブラウザはリクエストを行う際に自身のHTTPキャッシュを確認します。一致する有効なキャッシュされたレスポンスが存在する場合、ブラウザはその画像についてオリジンサーバーに接続することなく、キャッシュを利用できます。[web.devのHTTPキャッシュガイド](https://web.dev/articles/http-cache)では、鮮度（freshness）はレスポンスのキャッシング情報に依存し、キャッシュされたレスポンスは鮮度が保たれている間は再利用できると説明されています。
キャッシュされたレスポンスが古くなっている（stale）場合や検証が必要な場合、ブラウザは保存されているコピーがまだ最新であるかを確認するためにサーバーに問い合わせることがあります。サーバーはそのコピーが有効なままであることを確認できるため、このチェックが行われたからといって画像全体が再度ダウンロードされたとは限りません。[MDNのHTTPキャッシュガイド](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching)では、鮮度、検証、およびレスポンスをキャッシュすべきではないケースについて解説されています。キャッシュの消去、有効期限切れ、URLの変更、アプリの動作、またはキャッシュ設定のすべてが、その後の閲覧時の動作を変える可能性があります。
したがって、慎重を期した答えとしては次のようになります。リモート画像の表示はネットワークリクエストにつながる可能性がありますが、表示するたびに画像のバイトデータが転送されたり、閲覧ごとにオリジンにアクセスしたりするとは限りません。キャッシュされた表示と新たに取得した表示は、画面上ではまったく同一に見えることがあります。
URLと保存された添付ファイルはどのように見分けるのか？
画像の参照先、またはアプリが提供している場合は添付ファイル情報を確認してください。`https://` や `http://` で始まる指定先は、リモートのWebアドレスを指しています。相対パスやアプリ固有の添付ファイル名の場合は、さらに確認が必要です。Webページでは、相対パスが別のWebアドレスに解決されることもあり、ファイルがお使いのデバイス上にローカルに存在することを証明するものではありません。指定先を決定するのは日記アプリの保存ルールとレンダリングルールです。Markdown単体では、一見ローカルに見える参照先がポータブルであることや、ファイルがエントリの内部に保存されていることを保証するものではありません。
役立つ見分け方は、「何が利用可能な状態で残り続ける必要があるか」という点です。リモートURLはリモートリソースが存在し続け、アクセス可能であることに依存します。一方、ローカル添付ファイルはアプリが想定する場所に該当するファイルが存在することに依存します。日記の写真ファイルを保護するには、アプリ自身のエクスポートまたはバックアップ手順に従ってください。この記事の焦点はリモート読み込みという独立した疑問であり、特定のアプリの保存形式を保証するものではありません。
オフラインでの比較から何が分かるのか？
無害な確認方法として、使い捨てのテスト用エントリで機密性のない画像URLを使用してみてください。オンラインの状態で閲覧し、その後デバイスをネットワークから切断してエントリを再度開きます。オフラインでも画像が表示される場合、それはキャッシュされたコピーまたは別のローカルコピーが利用可能であることと整合します。表示されない場合、アプリはその時点でリモートリソースを必要としている可能性がありますが、その結果だけでは正確な理由は特定できません。
この比較では、通常のオンライン閲覧時にネットワークリクエストが一切発生していないことを証明することはできません。ブラウザが切断前にリクエストを行っていたり、Service Workerやアプリケーションキャッシュを確認していたり、あるいはすでにローカルに保存されている画像を表示していた可能性があります。同様に、オフラインで画像が表示されたとしても、そのエントリのMarkdownに添付ファイルが含まれていることの証明にはなりません。アプリがリモートレスポンスをキャッシュしただけの可能性もあります。ブラウザベースの日記の場合は、オンラインの状態でブラウザのネットワーク開発者ツールを使用してリクエストの動作を観察し、画像リクエストとそのキャッシュ状態を調べてみてください。ただし、その結果はそのテスト環境における挙動を示すものであり、今後のすべての閲覧やあらゆるデバイスに当てはまるわけではありません。
実践的なチェックリスト
意図通りに表示される必要があるエントリについては、画像の参照先を確認し、ローカルにあるべきものであれば対応するローカル添付ファイルが存在するかを確認してください。リモートURLである場合は、利用可能性や更新の挙動がホストとキャッシュに依存することを前提にしてください。オンライン時のネットワークパネルを使ってリクエストを観察し、限定的な比較としてオフラインでの再読み込みを行ってください。それぞれ得られた結果は、テストしたアプリ、ブラウザ、キャッシュ状態に関する証拠として扱い、普遍的な保証とは見なさないようにしましょう。