1. はじめに：ふと気づいた「同期の多重設定」問題

自宅の Synology NAS（DS725+）と Mac を中心に、ファイル管理の環境をずっと使ってきました。OneDrive も使いつつ Synology Drive Client もインストールしていて、「バックアップはできているだろう」と思っていたのですが、ある日ふと構成を整理しようとダイアグラムを描いてみると、接続が5本もありました。

Mac Mini と MacBook Air のそれぞれに OneDrive アプリと Synology Drive Client が入っていて、さらに DSM の CloudSync で OneDrive と Synology Drive が双方向に同期されていたのです。

この記事では、5接続の構成を3接続にシンプル化し、OneDrive を中心にした3層バックアップ体制を整えた手順をまとめます。

2. 現在の構成の問題点：5接続が生む複雑さと競合リスク

整理前の構成は次の通りでした。図にしてみると接続が5本あることが一目で分かります。

• Mac Mini OneDrive（OneDrive アプリ・双方向）
• Mac Mini Synology Drive（Synology Drive Client・双方向）
• MacBook Air OneDrive（OneDrive アプリ・双方向）
• MacBook Air Synology Drive（Synology Drive Client・双方向）
• OneDrive Synology Drive（DSM CloudSync・双方向）

問題は2点ありました。

同期の競合リスク

同じファイルが OneDrive と Synology Drive の両方から同時に更新されようとした場合、どちらが正しいバージョンなのかシステムが判断できなくなります。ファイルが二重化したり、意図しないバージョンで上書きされるリスクがありました。

管理の複雑さ

各 Mac に Synology Drive Client を追加でインストールしていることで、トラブルが起きた際の原因特定が難しくなっていました。「どちらのアプリが動かしているのか」が曖昧になりがちなのも問題でした。

3. 整理後の設計方針：OneDriveをハブにした3層構造

整理後のコンセプトはシンプルです。OneDrive を唯一の同期ハブとし、NAS はその受け皿として位置づけることにしました。接続は3本に絞っています。

• Mac Mini OneDrive（OneDrive アプリ・双方向）
• MacBook Air OneDrive（OneDrive アプリ・双方向）
• OneDrive → Synology Drive（DSM CloudSync・片方向のみ）

Synology Drive Client は両 Mac からアンインストールし、NAS は「OneDrive のデータを受け取る専用機」として運用します。これにより同期の競合はゼロになりました。

さらに CloudSync で NAS に降りてきたデータを Hyper Backup が毎日バックアップすることで、3層の保護体制が完成します。

4. CloudSync の設定ポイント：片方向・スケジュール・削除の扱い

DSM の CloudSync で Microsoft OneDrive タスクを設定する際、3つのポイントを押さえました。

同期方向は「遠隔での変更のみダウン」

最重要の設定です。「遠隔での変更のみダウン」を選ぶことで、OneDrive 側の変更だけが NAS に反映され、NAS 側の変更が OneDrive に逆流することはありません。双方向のままにしておくと、NAS を直接操作した際に意図しない変更が OneDrive に上書きされる危険があります。

スケジュールは 03:00 実行

常時同期は NAS の CPU・ネットワーク負荷を増やし続けます。バックアップ用途であれば1日1回で十分です。深夜3時に設定することで、日中の作業や WordPress の公開処理への影響をゼロにしました。

「削除しない」チェックは外してミラー運用

OneDrive でファイルを削除した場合、NAS 側も同様に削除するミラー設定にしました。NAS が肥大化せずシンプルな運用になります。OneDrive には30日間のごみ箱機能があり、Hyper Backup でも世代管理しているため、誤削除への対応は別途確保されています。

5. Hyper Backup の設定ポイント：Smart Recycle で最大4年分を自動管理

Hyper Backup は NAS のデータを外付けHDDへ世代管理付きでバックアップするツールです。CloudSync が NAS にデータを降ろした後に動くよう、スケジュールを 04:30 に設定しました。

実行順序が重要

CloudSync（03:00）→ Hyper Backup（04:30）の順にすることが大切です。逆の順序では、Hyper Backup が「CloudSync 実行前の古いデータ」をバックアップしてしまい、常に1日遅れの内容しか保存されません。

Smart Recycle とは

単純に古いバージョンから削除するのではなく、時間軸に応じて保持密度を自動調整するポリシーです。最大256バージョンを設定した場合、直近1ヶ月は毎日・それ以降は週次・月次と間引きながら、最大4年ほど遡れる状態を自動で維持してくれます。手動での管理が不要なのが大きなメリットです。

6. 完成した保管体制：クラウド・NAS・外付けHDDの3層保護

今回の整理で完成した保管体制をまとめます。

Synology Drive Client を削除したことで接続は5本から3本へ、同期の競合リスクはゼロになりました。それでいて OneDrive の30日ごみ箱、NAS のミラー、外付けHDD の世代管理という3層で、万が一の場合にも対応できる体制が整いました。

NAS を持っていて「なんとなく同期を設定している」という方は、一度構成を図に描いて整理してみることをおすすめします。意外と複雑になっていることに気づくかもしれません。

はじめに

Synology NASでMicrosoft OneDriveへのCloud Syncを設定して使っていたところ、「現在 1 個のファイルを同期しています。」という表示が何日経っても消えない問題に遭遇しました。

ログにエラーは出ておらず、実際に何かが転送されている様子もありません。それでもカウンターだけは「1個」を表示し続けるという、やや不思議な状況です。この記事では、試みたトラブルシュートの手順と結果をそのまま記録しています。

結論を先にお伝えすると、5つの対処をすべて試しましたが、表示を解消することはできませんでした。

環境と構成

試したこと① タスクの一時停止・再開

まず最初に試みたのが、Cloud Syncの概要画面にある「管理」ボタンから「同期を一時停止」を選択し、数秒後に「同期を再開」する方法です。

カウンターの内部状態がリセットされることを期待しましたが、再開後も「1個」の表示はそのまま残りました。

試したこと② フィルタ設定と整合性チェック無効化

macOSが自動生成するシステムファイル .DS_Store がCloud Syncの処理に影響している可能性を考え、タスク設定の「ファイルフィルタ」に .ds_store を追加して同期対象から除外しました。

あわせて、「高度な整合性チェックを有効にする」のチェックをOFFにし、処理負荷を下げる設定にも変更しました。

しかしいずれも効果はなく、「1個」の表示は変わりませんでした。

試したこと③ タスク削除と再作成

「管理」メニューの「リンク解除」でタスクをいったん完全に削除し、OneDriveへの接続からやり直してタスクを新規作成しました。

初回スキャン中は「1個」が表示されましたが、これは初回スキャンの仕様上の動作とみられます。問題はスキャン完了後で、それ以降も「1個」は表示され続けました。

試したこと④ パッケージの完全再起動

DSMのパッケージセンターからCloud Syncを「停止」して完全に終了させ、数秒後に「実行」で起動し直しました。アプリケーションレベルの一時停止ではなく、パッケージプロセスそのものをリセットすることで内部状態がクリアされることを期待した操作です。

ところが起動後もすぐに「1個」の表示が戻り、効果は見られませんでした。パッケージを再起動しても、内部のカウンター状態はそのまま保持されていることがわかりました。

試したこと⑤ 同期方向を双方向→一方通行に変更

タスク設定の「同期方向」を「双方向」から「ローカルでの変更のみアップロード（NAS→OneDrive一方通行）」に変更しました。これはこのCloud Syncタスクの元々の設計に戻す操作でもありました。

設定変更後、Cloud Syncのログに35件の画像ファイル（IMG_2026…）のアップロードが記録されました。双方向モードでは何らかの理由でアップロードが滞留していた可能性があります。これはこれで発見でした。

ただし、35件のアップロードがすべて完了したあとも、「1個」の表示は残りました。

結論

5つの対処をすべて試みましたが、「1個のファイルを同期中」という表示を消すことはできませんでした。

一方で、ログにエラーは一切記録されておらず、新規ファイルをNASに追加した際にはOneDriveへ正常に反映されることも確認しています。つまり実際の同期機能そのものは正常に動作しているとみられます。

状況を整理すると、表示カウンターの内部状態と実際の同期処理との間に何らかの乖離が生じている可能性が考えられます。Cloud Sync 2.7.2に関連した挙動の可能性はありますが、現時点では原因を特定するには至っていません。今後のバージョンアップによる改善を待つこととしました。

まとめと教訓

今回のトラブルシュートを通じて、いくつかの気づきがありました。

「1個同期中」はエラーとは限らない
ログにエラーが出ておらず、実際の同期が機能している場合、表示カウンターの問題である可能性があります。焦らずログを確認することが大切です。

双方向モードではアップロードが滞留するケースがあるかもしれない
今回の経験では、双方向モードから一方通行に切り替えたタイミングで35件の未アップロードファイルが処理されました。バックアップ目的であれば一方通行（NAS→クラウド）のほうがシンプルで安定している場合もあるかもしれません。

解決しないこともある
トラブルシュートは必ずしも解決に至るわけではありません。今回のように「実害はないが表示が気になる」という状況では、バージョンアップを待つという判断も現実的な選択肢のひとつです。

2台持ちの「気づかない問題」

会社から支給されたスマホを持つ方にとって、2台持ちは日常のことです。

しかし会社をでた後はモバイルSuicaなど使用のため私有のスマホをメインとし、社給のスマホはかばんの中に。このとき着信があっても気付かないことがあります。

重要な連絡を見逃してしまうリスクが、2台持ち運用の現実的な課題です。

この問題を、iPhoneに標準搭載されているショートカットアプリとMMIコードを組み合わせることで、ワンタッチで解決できます。

解決策：着信転送をワンタッチで切り替える

社給スマホにかかってきた電話を、自分のiPhoneに自動的に転送する設定です。ポイントは次の2点です。

• 社給スマホ側でMMIコードを発信するだけで転送が開始・解除できる
• ショートカットアプリを使えばその操作をホーム画面のワンタップで行える

キャリアへの申し込みや月額オプションは不要です。社給スマホがau・ドコモ・ソフトバンク回線であれば、同じ手順で利用できます。

MMIコードとは何か

MMI（Man-Machine Interface）コードとは、スマートフォンの電話アプリからキャリアネットワークに直接命令を送るための特殊な文字列です。

国際標準規格である3GPP TS 22.030で定められており、日本国内のキャリアを問わず、GSM/LTE/5G対応端末であれば共通して動作します。

コードの構造は以下のようになっています。

操作記号には次の種類があります。

サービスコード 21 は「無条件転送（CFU）」、61 は「無応答時転送（CFNRy）」を意味します。

**21と**61の使い分け

転送の動作が異なるため、場面に応じて使い分けることができます。

解除コードはそれぞれ ##21#・##61# です。設定と解除のサービスコードは必ず揃える必要があります。

なお、すべての転送設定をまとめて解除したい場合は ##002# を発信すると一括消去できます。

ショートカットアプリでワンタッチ化する手順

iPhoneのショートカットアプリを使い、MMIコードを1タップで発信できるようにします。作成するショートカットは計4つです。

使用するURLの形式

「転送先番号」にはハイフンなしで自分のiPhoneの番号を入力します（例：tel:**21*09012345678%23）。

ショートカットの作成手順（4つ共通）

1. ショートカットアプリを開き、右上の 「＋」 をタップ
2. 「アクションを追加」 → 検索欄に 「URL」 と入力 → 「URLを開く」 を選択
3. URLフィールドに上記の表のURLを入力
4. 右上の 「…」 → 「名前を変更」 で名前をつける

名前の例として 全転送ON・ 全転送OFF・ 無応答転送ON・ 無応答転送OFF のように絵文字をつけると視認性が上がります。

動作確認

ショートカットをタップした後、画面上部にチェックマークが表示されPhoneアプリが起動し、ネットワークから設定完了の応答が返ってくれば成功です。

無応答転送の呼び出し時間について

auの無応答転送（**61）の呼び出し時間は、初期設定で24秒です。5秒〜55秒の範囲で変更することができます。

変更したい場合は特番 1418XX（XXが秒数）に発信します。

なお、iOS 18以降では「ライブ留守番電話」がデフォルトでオンになっています。**61を確実に動作させるには、「設定」→「電話」→「ライブ留守番電話」をオフにしておくことをおすすめします。

%23と書く理由：URLエンコードとは

MMIコードの末尾には # が必要ですが、ショートカットのURLフィールドに # をそのまま入力することができません。

URLの仕様では # は「ページ内アンカー（フラグメント識別子）」の区切り文字として予約されており、それ以降の文字列は破棄されてしまうためです。

この問題を解決するのがURLエンコードです。RFC 3986（URLの国際標準仕様）では、特殊文字をASCIIコードの16進数で %XX の形式に変換して表現します。# のASCIIコードは16進数で 23 なので %23 となります。

これにより「URLの区切り文字としての#」ではなく「文字としての#」をPhoneアプリに正確に届けることができます。

ホーム画面に追加してさらに便利に

作成したショートカットはホーム画面にアイコンとして追加できます。

1. ショートカットアプリで対象のショートカットを 長押し
2. 「詳細」 をタップ
3. 右上の 「…」 → 「ホーム画面に追加」
4. アイコン名・アイコン画像を確認して 「追加」

iPhone 15以降をお使いの場合は、アクションボタンにショートカットを割り当てることも可能です。「設定」→「アクションボタン」→「ショートカット」から設定できます。

まとめ：1台で2台分をカバーする運用

MMIコードとiPhoneショートカットの組み合わせで実現できることを整理します。

• 社給スマホにかかってきた電話を自分のiPhoneへワンタップで転送できる
• **21（無条件転送）と **61（無応答時転送）を状況で使い分けられる
• キャリアへの申し込みや月額費用は不要
• SMSは転送されず元の端末に届くため、重要なメッセージの取りこぼしもない

かばんの中の社給スマホを気にしながら過ごすストレスから解放される、シンプルで実用的な運用方法です。設定・解除がワンタップでできるため、必要なときだけ転送をオンにする使い方も手軽に実現できます。

はじめに：ClaudianとBRATとは

Obsidianは、Markdownベースのノートアプリとして多くのユーザーに使われています。その大きな魅力のひとつが、コミュニティプラグインによる拡張性です。

Claudianは、ObsidianとAnthropicのAI「Claude」を連携させるプラグインです。ノートを開いたままClaude AIと対話したり、文章の添削・要約・アイデア出しなどをObsidian内で完結させることができます。

一方、BRAT（Beta Reviewers Auto-update Tool）は、Obsidianの公式コミュニティプラグインに登録される前のベータ版プラグインを、GitHubリポジトリから直接インストール・管理するためのツールです。正式リリース前の新機能をいち早く試したいユーザーに重宝されています。

BRAT経由でClaudianを使っていた背景

ClaudianはもともとObsidianの公式コミュニティプラグインには登録されておらず、GitHubで開発・公開されていました。そのため、当初はBRATを使ってGitHubリポジトリ（YishenTu/claudian）からインストールするしか方法がありませんでした。

BRATを使うと、Obsidian起動時に自動アップデートが走り、最新のベータ版を常に利用できる状態になります。利便性は高いものの、「あくまでもテスト扱い」という位置づけでした。

ClaudianがObsidian公式コミュニティプラグインに正式登録された

ある日、Obsidianのコミュニティプラグイン一覧を確認すると、ClaudianがBRATなしでインストールできる公式プラグインとして登録されていることに気づきました。

公式登録されたことで、以下のメリットが生まれました。

• Obsidianの「コミュニティプラグインを閲覧」から直接インストール可能になった
• Obsidian公式のアップデート機構で更新管理ができるようになった
• BRATへの依存が不要になった

これを機に、BRAT管理のテスト版から公式版への移行を行いました。

テスト版（BRAT管理版）Claudianの削除手順

まず、BRATの管理リストからClaudianを外し、その後コミュニティプラグインからアンインストールします。

① BRATのリストからClaudianを削除

設定 → コミュニティプラグイン → BRAT を開きます。「Beta plugin list」に表示されているClaudian（YishenTu/claudian）の右端にある赤い「×」ボタンをクリックします。

この操作はBRATの管理リストから外すだけで、プラグイン本体は削除されません。次の手順でアンインストールが必要です。

② コミュニティプラグインからClaudianをアンインストール

設定 → コミュニティプラグイン → Claudian を選択し、「アンインストール」をクリックします。これでプラグイン本体が削除されました。

BRATの削除

ClaudianがBRATで管理していた唯一のプラグインだったため、移行後はBRAT自体も不要になりました。

設定 → コミュニティプラグイン → BRAT を選択し、「アンインストール」をクリックして削除しました。

今後ベータ版プラグインを試したくなった場合は、コミュニティプラグインから再インストールも簡単にできます。必要なときだけ入れておけば十分です。

公式版Claudianのインストールと動作確認

設定 → コミュニティプラグイン → 「閲覧」から 「Claudian」 を検索し、インストール・有効化します。

インストール後、Claudianの設定画面でAnthropicのAPIキーを入力すれば、すぐに使い始めることができます。

実際に動作確認を行い、Obsidian内でClaude AIとの対話が問題なく機能していることを確認できました。設定も引き継がれており、移行はスムーズに完了しました。

まとめ

ObsidianとClaude AIを連携させるClaudianが公式コミュニティプラグインとして正式登録されました。これにより、BRATを経由せずに直接インストール・管理できるようになっています。

もしまだBRAT経由でClaudianを使っている方は、ぜひ今回の手順を参考に公式版への移行をご検討ください。管理がシンプルになり、アップデートも自動で処理されます。

Obsidianはプラグインのエコシステムが充実しており、今後もさまざまなAI連携ツールが登場してくることが予想されます。引き続きアップデートを追っていきたいと思います。

梅雨入り前の5月下旬に神戸に行ってきました。

有馬温泉からは新神戸に戻り帰宅しました。
1泊2日でしたが､下調べした甲斐もあり迷わず回ることができました。
洋食屋さんが多く感じたのはやはり土地柄でしょうか。

1. きっかけ：通勤経路が変わった

長年、JR沿線を中心とした通勤経路を使っていましたが、このたび経路を変更しました。新しい通勤ルートは東京メトロで、JR線をまったく経由しません。

これまでモバイルSuicaにJRの通勤定期券とバス定期券をまとめて入れて使っていましたが、東京メトロだけの区間はSuica使用不可､PASMO必要と分かり乗り換えすることになりました。

2. PASMOをウォレットに追加した

モバイルPASMOはiPhoneのウォレットアプリに追加できます。SuicaとPASMOは同時に2枚共存させることが可能で、Suicaを削除しなくてもそのまま追加できます。

PASMOアプリをApp Storeからインストールし、東京メトロの通勤定期券を新規購入しました。操作の流れはモバイルSuicaとほぼ同じ感覚で、特に迷うことなく完了しました。

なお、iPhoneのエクスプレスカード（改札でタッチするだけで反応する設定）に登録できるのは交通系ICカード1枚だけです。毎日使う東京メトロに対応するPASMOをエクスプレスカードに設定しました。

3. JR定期を解約したら戻りが少ない理由

JRの6ヶ月定期を5ヶ月使用したところで解約しました。「残り1ヶ月分は戻ってくるはず」と思っていたのですが、実際に戻ってきた金額は想像より大幅に少なく、少し驚きました。

定期券の払い戻し計算はこのような仕組みになっています。

ここに落とし穴があります。6ヶ月定期は割引率が高いため購入額が安く抑えられていますが、払い戻しの計算では割引前の1ヶ月定期運賃×経過月数を差し引く仕組みになっています。5ヶ月分の1ヶ月定期運賃を積み上げると、6ヶ月定期の購入額とほぼ同額になってしまうのです。長期定期を途中解約すると損になりやすいのはこのためです。

4. バス定期の解約でさらに衝撃：戻りがほぼゼロのなぜ

JR定期の解約が済んだあと、SuicaにはバスのIC定期券（6ヶ月定期）がまだ残っていました。残り約1ヶ月。「こちらも解約して少しでも戻そう」とバス事業者の窓口で問い合わせすると、払い戻し金額がほぼゼロなので使い切ったほうがお得とアドバイス頂きました。

バス定期の払い戻し計算もJRと同様のためです。

手間と金額を天秤にかけた結果、残り1ヶ月のバス定期は解約せず、そのまま使い切ることにしました。

5. 1ヶ月の現実的な乗り切り方（都度認証タッチ）

エクスプレスカードはPASMO（東京メトロ用）に設定してあります。バスに乗るときはSuicaでタッチしたいのですが、エクスプレスカードではないため乗車のたびにFace IDの認証が必要になります。

バス乗車時の手順はこのようになりました。

1. バスが来たらiPhoneを取り出す
2. サイドボタンをダブルクリック（Face IDで認証）
3. ウォレット画面でSuicaを選択してタッチ

慣れれば数秒の手間ではありますが、毎朝のことなので煩わしさがあります。

6. Suica完全解約でチャージ残高を回収

バス定期の有効期限が切れたあと、いよいよSuicaの完全解約を行いました。

両方ともSuicaアプリから手続きが完結します。手続き自体は数分で完了しました。

今回の一連の経緯を振り返ると、定期券の長期購入は解約時の損が大きいという事実を改めて実感しました。モバイルSuicaとPASMOの仕組みの違いとあわせて、参考になれば幸いです。

中国で始まった「幽霊店」排除の動き

2025年7月、北京のある消費者が購入したケーキに生花が飾られているのを見て食品衛生上の問題を疑い、当局に通報しました。調査の結果、そのケーキ業者は380もの店舗を持つと称しながら実態は1店舗もなく、営業許可証も偽造だったことが発覚しました。

調査が全国に拡大すると、同様の問題が次々と浮かび上がりました。注文を受けた幽霊店が代行サービスに製造を発注し、最低価格で入札した別の業者が下請けするという多重構造も明らかになりました。最終的に幽霊店は6万7,000店超に上り、違法なケーキの注文は360万件にも達したとされています。

これを受け、中国の規制当局である国家市場監督管理総局は2026年6月1日に新たな規定を施行しました。出前アプリを運営する各社に対し、出店業者の営業許可の定期確認を義務付け、実店舗がない業者にはアプリ上で「店内飲食なし」と明示するよう求める内容です。

この中国の動きをきっかけに、日本のフードデリバリーアプリに並ぶ「ゴーストレストラン」と呼ばれる店舗の実態について調べてみました。

ゴーストレストランとは何か

ゴーストレストランとは、実店舗を持たずデリバリー専業で営業する飲食店のことです。「バーチャルレストラン」「クラウドキッチン」とも呼ばれます。客席も看板も持たず、注文はすべてフードデリバリーアプリ経由で受け付け、調理した料理を届けるビジネスモデルです。

調理場所はさまざまです。マンションや一戸建ての一室を保健所の基準に合わせて整備した自前のキッチン、既存の飲食店のキッチンを空き時間に間借りする形態、複数の事業者が共同利用するシェアキッチン（クラウドキッチン）などがあります。いずれも実店舗の内装工事や客席設備が不要なぶん、開業コストを大幅に抑えられることがゴーストレストランが広がった背景のひとつです。

また、1つのキッチンから複数のブランドを同時出店できる点も特徴です。「〇〇ラーメン専門店」「△△唐揚げ専門店」「□□海鮮丼専門店」が、実は同じキッチンの同じ調理スタッフによって作られているケースも珍しくありません。現在の日本では、1拠点あたりの出店ブランド数に上限規定はありません。

日本の法律上の位置づけ

まず結論から言うと、ゴーストレストラン自体は違法ではありません。2021年6月の食品衛生法改正により営業許可制度が見直され、実店舗がなくデリバリー専業であっても、通常の飲食店と同様に「飲食店営業許可」の取得と「食品衛生責任者」の選任が必要とされています。

なお「飲食店営業許可」は、ラーメンや海鮮丼といった料理の品目ごとに取得するものではなく、施設（キッチン）単位で取得するものです。1つの許可があれば、そのキッチンでさまざまな料理を提供することができます。

ただし、以下のような業態は飲食店営業許可とは別の許可が必要です。

「ゴーストレストランは違法ではない」と言い切れない面があるとすれば、主に以下の2点です。

① 「専門店」表示と景品表示法の問題

実態が1つのキッチンであるにもかかわらず、「〇〇専門店」というブランド名をアプリ上に複数並べることで、消費者に専門店ならではの品質を期待させるケースがあります。景品表示法に詳しい弁護士の中には、実態が専門店と名乗るにふさわしいものとかけ離れていれば「優良誤認」に抵触する可能性があると指摘する声もあります。

② 無許可営業のリスク

自前のキッチンやシェアキッチンを利用する場合でも、調理を行う事業者自身が飲食店営業許可を取得していなければ食品衛生法違反となります。施設側の許可を借りているだけで営業するケースが一部で発生しており、保健所への通報で発覚する例もあるとされています。

③ 衛生管理の不透明性

実店舗がないため、消費者がキッチンの衛生状態を確認する手段がほとんどありません。保健所の立ち入り検査も、通常の飲食店と同様の頻度では行き届いていない現状があります。

フードデリバリー各社は許可を確認しているのか

フードデリバリーA社では、出店登録の際には飲食店営業許可証のスキャンデータの提出が求められ、登録する店舗の住所と許可証の住所が一致していることも条件とされています。菓子を販売する場合は菓子製造業許可証、アルコールを扱う場合は酒類小売業免許の提出も必要とされています。

制度上は書類による確認の仕組みがある、ということです。

しかし問題は提出書類が本物かどうかの実地確認がない点です。許可証の画像をデータで送付するだけで登録が完了するため、書類の真正性を現地で確認する仕組みは整っていません。中国で発覚したのと同じ構造の課題が、日本にも存在していると言えます。

また、登録後に許可が失効・取り消しになった場合に、プラットフォーム側が自動的に検知する仕組みについても、現時点では公式に確認できません。

日本での食中毒リスクと表に出にくい構造的理由

「ゴーストレストランが原因と明示された食中毒事例」は、現時点で日本では公式に公表されていません。しかしこれは「問題がない」ことを意味しません。

理由は統計上の区分にあります。保健所の食中毒記録は「発生場所：飲食店」「原因物質：○○菌」という形式で記録されるため、デリバリー専業かどうかは区別されません。ゴーストレストランが原因であっても、通常の飲食店事例として処理されます。

東京都保健医療局が公開しているテイクアウト・宅配での食中毒事例を見ると、デリバリーに特有のリスクが浮かび上がります。

これらはいずれも、スペース不足・少人数調理・温度管理の不徹底といった条件が重なって起きています。ゴーストレストランの運営環境と共通する要因が多く含まれており、参考となる事例です。

また食中毒が発生した場合、調理側・配達側・プラットフォーム側に責任が分散しやすく、消費者が被害を訴えにくい構造があることも課題のひとつです。

日本と中国の規制比較

今回の中国の規制強化と日本の現状を比較すると、制度上の差が見えてきます。

項目	日本	中国（2026年6月以降）
営業許可の必要性	必要	必要
プラットフォームの審査	書類提出のみ	定期確認義務化
抜き打ち検査	規定なし	義務化
「実店舗なし」の表示義務	規定なし	アプリ上に明示義務
プラットフォームへの罰則	規定なし	制裁実績あり
配達員による通報制度	規定なし	報酬付き通報制度あり

中国では、プラットフォーム企業が出店業者への審査を十分に行ってこなかった背景として「事業規模の拡大優先」が指摘されています。プラットフォームの自主的な対応には限界があることから、法律による義務付けに踏み込んだ形です。

日本でも法整備は必要か

現状を整理すると、日本では「許可を取って営業する」という最低限の枠組みは存在しています。一方で、許可の実地確認・定期更新確認・プラットフォームへの義務付けといった仕組みは整っていません。

① 書類審査だけでは不正を防ぎにくい

登録時に許可証の画像を提出する仕組みはあっても、その後の継続的な確認は行われていません。中国が制度化したような「プラットフォームへの定期確認義務」は、日本でも検討に値する対策のひとつです。

② 消費者が判断できる情報が不足している

アプリ上では店舗名とメニューだけが並び、実店舗があるのか、何種類のブランドを同一キッチンで運営しているのかがわかりません。中国が義務化した「店内飲食なし」の表示のような最低限の実態開示ルールを設けることは、消費者保護の観点から検討に値します。

③ フードデリバリー市場は今後も続く

コロナ禍で急拡大したフードデリバリーは、日常的なサービスとして定着しつつあります。市場が大きくなるほど悪質な事業者が紛れ込むリスクも高まるとされており、問題が顕在化してから規制するよりも、予防的な制度整備を検討する段階にきているともいえます。

一方で、過度な規制は低資金で起業できるゴーストレストランのメリットを損なうリスクもあります。真面目に営業している事業者の参入を妨げないバランスが重要です。規制の目的はあくまで「悪質業者の排除と消費者保護」であるべきです。

おわりに：利用者として今できる自衛策

法整備の議論が進むまでの間、利用者として確認できることをまとめます。

ゴーストレストランのすべてが問題のある業者というわけではありません。許可をきちんと取得し、衛生管理を徹底して営業している事業者が多数です。ただし中国の事例が示すように、確認の網の目が粗いところには問題が生じやすい面があります。

日本でも中国の規制強化を参考にしながら、プラットフォーム企業・行政・消費者それぞれの立場で食の安全を考えていくことが求められているように感じます。

1. はじめに ── なぜ今、山火事を知るべきか

2026年、米国全土で発生した山火事の焼失面積が過去約10年で最大規模に達しました。カリフォルニア州などの「山火事多発地帯」だけでなく、東部の人口密集地でも大規模な火災が広がり、世界中に衝撃を与えました。

一方、日本でも2025年に岩手県大船渡市で平成以降最大規模の山林火災が発生しています。「日本は雨が多いから大丈夫」という感覚は、もはや通用しなくなっています。

この記事では、山火事が発生するメカニズムを「燃焼の三角形」から整理し、米国の最新事例と日本への影響を分かりやすく解説します。

2. 山火事が起きる仕組み「燃焼の三角形」

山火事が発生・拡大するには、燃料・酸素（風）・熱（点火源）の3要素が同時にそろう必要があります。これを「燃焼の三角形」と呼びます。

酷暑と干ばつはこの三角形のすべてを最大化します。燃料は乾燥して着火しやすくなり、高温の空気は風をより乾かし、少しの火種でも一気に燃え広がります。

3. 酷暑・干ばつがどう燃料を増やすか

干ばつと山火事の関係は、単純に「乾燥して燃えやすくなる」だけではありません。以下のような複合的なメカニズムが働きます。

① 植物が枯れて「枯れ燃料」が蓄積する

長期の干ばつで樹木や草が水分を失い、立ち枯れや落葉が増えます。これが地表を覆い、火口（ほくち）状態の燃料層を形成します。土壌水分がゼロに近づくと、地表全体が燃えやすい状態になります。

② 雨→植物成長→乾燥という「逆説的な燃料増加」

エルニーニョ現象などで冬に雨が多く降ると、春に植物が大量に成長します。しかしその後に乾燥期が来ると、今度はその大量の植物が枯れて燃料となります。「雨が多かった翌年ほど山火事が大きくなる」という逆説的なリスクがあります。

③ 延焼スピードの加速

湿度が低くなると、消火活動の効果が著しく下がります。散水しても蒸発が速く、火勢を抑えにくくなるためです。また、斜面では炎が上方向に向かって猛スピードで燃え広がります。

4. 点火源の種類（自然・人為）

「燃える条件」がそろっていても、最初の火種がなければ山火事は起きません。点火源は大きく自然起因と人為起因に分かれます。

自然起因

• 落雷：米国の山火事の約10〜15%は落雷が原因です。雨を伴わない「乾燥雷」が特に危険で、広大な山林に直接着火します。
• 火山活動：限定的な地域のみに影響します。

人為起因（全体の約85〜90%）

• 送電線・電力設備のスパーク（カリフォルニア大規模火災の主因のひとつ）
• たき火・キャンプファイヤーの不始末
• 農業焼却（野焼き）の延焼
• タバコのポイ捨て
• 花火・信号弾
• 車両の排気・スパーク（乾燥した草地での走行）
• 放火

山火事の大部分は人間の行動がきっかけです。「燃える条件」が気候変動で整いやすくなった今、日常の火の取り扱いがより重要になっています。

5. 2026年 米国で過去10年最大の山火事

2026年、米国全体で約190万エーカー（約7,700平方キロメートル）が焼失しました。これは10年平均を約80%上回る数字で、2017年以降の年初〜同時期比較で最大です。

特に注目すべきは、被害が西部だけでなく東部の人口密集地にも広がったことです。ジョージア州では過去1か月で700件以上の山火事により約6万700エーカーが焼失し、2017年以降の年間焼失面積を超えました。フロリダ州でも2026年に約7万7,000エーカーが焼失しています。

背景には複合的な要因があります。

• 米国の60%以上が干ばつ状態（5月初旬時点）
• 西部の積雪量が記録的に少なく、春の融雪水が不足
• エルニーニョ現象の接近と地球温暖化の重複

フロリダ大学の研究者は「東部全体で火災が増加し、大規模な山火事が増えている。連邦政府の消火リソースは限られており、東部がこれに大きな負担をかけ始めたら厳しい状況になる」と警告しています。

6. 「多雨の日本は安全」は過去の話

「日本は年間降水量が多いから山火事は少ない」というイメージは、残念ながら過去のものになりつつあります。

2025年2〜3月、日本各地で大規模な山林火災が相次ぎました。岩手県大船渡市では約2,900ヘクタールが焼失し、1名が死亡、210棟が被害を受けた平成以降最大規模の火災となりました。岡山市・玉野市の金甲山では約559ヘクタール、愛媛県今治市では約442ヘクタールが焼失しています。

「多雨」でも山火事が起きる理由

日本の降水は「冬〜春」に極端に少ないという構造があります。年間を通じた雨量は多くても、2〜5月は降水量が著しく少なく、空気が乾燥します。山火事の約6割がこの時期に集中するのはそのためです。

大船渡市の事例では、2025年2月の降水量がわずか2.5mmと平年比93.9%減という異常な少雨が続きました。さらに西風が奥羽山脈にぶつかって水分を落とし、乾いた空気が太平洋側に流れ込む「フェーン現象」も重なりました。

また、気候変動による「乾燥と豪雨の二極化」も見逃せません。温暖化で大気中の水蒸気量が増えると、降る時は豪雨、降らない時は極端な乾燥という「ムラのある降水パターン」になります。トータルの年間雨量が多くても、「乾燥している時期の乾き方」はむしろ激しくなるのです。

7. 日本の山火事の特徴と点火源

日本の山火事には、米国とは異なるいくつかの特徴があります。

点火源はほぼ人為的

米国では落雷による自然発火が一定数ありますが、日本ではほぼ全件が人為的原因です。たき火が約30%と最多で、次いで野焼き（火入れ）が約17%、放火が約10%、タバコが約6%となっています。

スギ・アカマツが延焼を加速する

日本の人工林はスギやアカマツが中心です。これらは油脂成分を多く含み、乾燥すると非常に燃えやすい性質があります。大船渡市の火災では「火山が噴火しているようだった」と表現されるほどの火勢となり、「樹冠火（じゅかんか）」と呼ばれる、木の上部まで燃え広がる激しい燃焼が起きました。

消火活動の難しさ

山間部は消防車が入りにくく、ヘリによる空中消火も風の影響を受けやすい状況です。大規模火災になると、人手と機材の限界から、まとまった雨が降るまで鎮圧できないケースも出てきます。

8. 気候変動で変わるリスク ── 件数は減っても規模は拡大

林野庁のデータによると、昭和時代には年間5,000件以上あった林野火災は、近年は年間約1,300件まで減少しています。しかし、焼失面積は増加傾向にあります。

これは何を意味するでしょうか。「件数が減っているなら安全になっているのでは？」と思うかもしれませんが、実態は逆です。1件あたりの規模が大きくなっているということは、ひとたび火がついたときの被害が桁違いに深刻になっているということです。

世界全体でも、過去20年間で森林火災の焼失面積は2倍以上に増加しています（世界資源研究所・WRI調べ）。2020〜2022年の年間平均焼失面積は831万ヘクタールと、2001〜2003年の約2倍に達しています。

9. まとめ

山火事は「乾燥した海外の話」ではなくなっています。日本でも毎年1,300件以上が発生し、2025年には平成以降最大規模の林野火災が起きました。

気候変動による「乾燥と豪雨の二極化」は、多雨な日本でも冬〜春の乾燥期をより危険にしています。年間の総雨量が多くても、乾く時期の乾き方は激しくなっており、「日本は安全」という感覚は見直す必要があります。

私たちにできることは、まず火の取り扱いへの意識を高めることです。たき火や野焼きの不始末が全体の約半数を占める日本では、一人ひとりの行動が最大の予防策になります。乾燥注意報や強風注意報が出ている日には、屋外での火の使用を控えることが重要です。

山火事は「ある日突然、広大な森が消える」災害です。気候変動の現実を知り、備えることが今まさに求められています。

神戸の南京町を歩いていたとき、地元の方から少し引っかかる話を聞きました。修学旅行生がたくさん来るようになり、その層に合わせたところ、イートインよりテイクアウト中心の店が流行るようになったそうです。売れるのは伝統的な中華ではなく流行りの「映える」商品ばかりで、昔ながらの店は減り、高単価でコースを頼むお客さんは来なくなってしまった。街は夜8時には静かになり、かつての活気が薄れてしまった——という話でした。来客の多い層に丁寧に合わせたはずなのに、街そのものはむしろ痩せてしまったわけです。この逆説は南京町だけの話なのでしょうか。それとも、ほかの街でも起きているのでしょうか。調べてみると、まったく同じ構造が各地で進行していました。

1. 神戸・南京町で聞いた話

話を整理すると、こういう流れになります。南京町には修学旅行生が多く訪れます。学生さんは単価が低く、座って食べる時間も予算もありません。そこで店側は、片手で食べられて写真も撮れるテイクアウト商品に寄せていきます。すると売れ筋は伝統料理ではなく、今どきの流行スイーツや「映える」軽食に置き換わっていきます。その結果、円卓を構えてコースを出すような店は割に合わなくなり、姿を消していきました。高単価のお客さんが来なくなれば夜の需要も細り、街は早い時間に閉まってしまいます。来客のボリュームゾーンに最適化したつもりが、街全体の単価と滞在時間が下がってしまったのです。

直感的には「お客さんに合わせる」のは正しい経営判断に思えます。実際、それぞれの店は合理的に動いています。それなのに、街全体としては悪い方向へ進んでしまう。なぜ合理的な選択の積み重ねが、全体の劣化を生んでしまうのでしょうか。この問いを軸に、まずは南京町の現状を確認し、その先を行く横浜中華街と比べながら、なぜこうなってしまうのかを掘り下げていきたいと思います。

2. 南京町で実際に何が起きているか

南京町の食べ歩き商品は、人気どころがおおむね1,000円以下に収まっています。豚まん、角煮バーガー、ごま団子、台湾系のからあげ、パンダをかたどったスイーツ——そして店ごとに扱う品がかなり被っています。差別化が効きにくく、価格と話題性の競争になりやすい構造です。地元の方からは「食事なら南京町以外のほうがおいしいものが食べられる」という声すら聞かれるそうです。観光地としてのにぎわいと、食の実質的な評価が乖離し始めているサインだと言えます。

混雑とマナーの問題から、2026年には歩きながらの飲食を厳しく制限し、買った店の前や指定エリアで立ち止まって食べる方向へとルールが強化されました。これ自体は導線整理として妥当ですが、裏を返せば「食べ歩き観光地」化がそれだけ進んだということでもあります。

構造を経済の言葉で言い換えてみます。かつての中華街は「高単価・低回転」の会食経済で回っていました。北京ダックやコース、宴会・接待・家族のハレの日の食事が、大箱の店と熟練の料理人を支えていたのです。いまの主役は「低単価・高回転」の食べ歩き経済です。問題は、狭い間口で500円の品を高回転で売る屋台型のほうが、円卓を並べてコースを出す業態より坪あたりの短期収益が高いという点にあります。すると家賃が食べ歩き業態を基準に上がり、高単価店が割に合わなくなって退出していきます。この入れ替わりが街全体で進んでいくのです。

そして見落とされがちなのが、その高単価店こそが「わざわざ中華街まで行く理由」、つまりブランドを作っていたという点です。食べ歩きだけなら屋台フェスでも代替できてしまいます。看板となる本格店が消えれば、街の格そのものが薄れていきます。

3. 横浜中華街——”数年先”を行く警告

同じ力学がもっとも進んでいるのが横浜です。ここを見ると、南京町の数年先が読めてきます。約220店のうち50店ほどが食べ放題という構成になる一方で、街の看板だった老舗が相次いで倒れました。1884年創業で日本に現存する最古級とされた聘珍樓が2025年に自己破産し、1952年創業の上海料理・揚州飯店も同じ年に自己破産しています。40年以上親しまれた龍鳳酒家も、店主の高齢化と後継者不在を理由に2025年に店を閉じました。報道はこれを「会食需要の低下による老舗の閉店」と総括しています。南京町で起きていることの“完成形”が、すでに横浜には現れているのです。

横浜にはもう一つ示唆があります。伝統と信用を重んじ街のルールを作ってきた組合中心の店々と、一部の店との分断です。「安さ全振り」が街のブランドそのものを毀損してしまうという、南京町の話の実証例だと言えます。

4. 共通する”型”を抜き出す

南京町と横浜、二つの中華街で起きていることを抜き出してみると、共通の道筋が見えてきます。そしてこれは、中華街だけの話でもありません。客層が大きく変わった観光市場や温泉街など、各地の街で同じ筋書きが繰り返されてきました。整理すると、次の5段階の連鎖です。

ここで冒頭の問いに戻ります。なぜ各店が合理的に動くほど、全体は悪くなってしまうのでしょうか。その答えは「共有地の悲劇」にあります。街やブランドの評判は、誰のものでもない共有資産です。各店が安い流行品で短期収益を最大化することは、その共有資産にタダ乗りする行為に等しいのです。誰も悪意がないまま、皆が少しずつ資産を消費し、最後には枯れてしまいます。一人ひとりが賢く振る舞っても、調整役がいなければ全体は守れません。

この罠を理解している側の行動も見ておきたいと思います。観光地に限らず、ブランドが売上を取りにいって値引きを広げると、短期の数量は稼げても「いつか安く買える」という学習が起き、定価の説得力＝ブランド価値が溶けていきます。そのため一部の高級ブランドは逆を行きます。象徴的なのがバーバリーで、2018年にはブランド保護のため多額の売れ残り品を焼却・破壊処分していたことを公表しました（強い批判は浴びましたが、「値引きしてでも捌く」ことを拒んだ判断でした）。安く売り切る誘惑に勝てるか——中華街の老舗が食べ歩きに転換するか踏みとどまるかと、本質は同じ問いなのです。

5. コロナは原因か、加速装置か

ここで一つの疑問が湧いてきます。これらの衰退は、コロナによる客足減少がなければ起きなかったのでしょうか。それとも、コロナがなくてもいずれこうなったのでしょうか。結論から言えば、コロナは「引き金（加速装置）」であって「原因」ではない、というのが私の見立てです。

衰退を生んだ要因は、どれもコロナより前から動き始めています。団体・社員旅行の縮小はバブル崩壊後の1990年代から進んでいました。これはコロナの約30年前です。高単価のコースや宴会を支える「会食する習慣」自体も、若者に限らずそれ以前の世代でも職場の飲み会に否定的な層が少なくないなど、コロナ前から細っていました。観光地の食べ歩き化を後押ししたインバウンドブームも2010年代の話で、コロナ前のことです。さらに、老舗の後継者不在や経営者の高齢化は、感染症とは無関係の人口動態の問題です。

ではコロナは何をしたのでしょうか。役割は三つに整理できます。第一に、会食需要を一瞬で蒸発させ、瀬戸際だった高単価店を数年早く退場させました。本来なら10年かけてじわじわ進んだはずの淘汰が、横浜の老舗倒産のように一時期に集中して表面化しました。第二に、テイクアウトや食べ歩きへの転換を一気に正当化・常態化させました。第三に、飲み会離れを不可逆にし、戻るはずだった需要が戻らなくなりました。要するにコロナは、緩やかな下り坂を崖に変えてしまったのです。方向は同じで、速度と落差だけが激変しました。

「引き金」と「原因」を分ける判定はシンプルです。①その現象はコロナ前から始まっていたか（→始まっていました）。②コロナを取り除けば防げたか（→防げません、遅らせるだけです）。この二つを満たすとき、それは原因ではなく加速要因だと言えます。中華街の件は、まさにこれに当てはまります。ただし補足すれば、コロナは破壊だけでなく再生のトリガーにもなり得ます。危機が「安いセグメントを追わない」という決断を、かえって後押しすることもあるからです。

6. では、街はどうあるべきか

鍵は「安い層を追わない」ことではなく、回遊と時間帯で棲み分ける設計にあると思います。第一に、食べ歩きゾーンと着席・会食ゾーンを物理的・時間的に分け、導線を整理すること。各地で進む歩き食べの制限は、その第一歩と位置づけられます。第二に、夜の滞在価値——予約制のコース、飲茶、酒の出る業態——を意図的に守り、賃料や組合のルールで高単価店の退出を食い止めること。

お客さんに合わせること自体は、間違いではありません。ただ「どのお客さんに、どう合わせるか」を街全体で設計しなければ、合わせたつもりが、いつのまにか街を痩せさせてしまいます。神戸で聞いたあの違和感の正体は、たぶんそこにあったのだと思います。

きっかけ：写真アプリで気圧が見えない

OM SystemのTG-7はアウトドア向けカメラらしく、気圧・高度・気温・方角といった環境センサーのデータも撮影時に記録してくれます。カメラの情報画面では確認できるのに、OI.ShareアプリでiPhoneに取り込み、さらにMacの写真アプリに転送すると、これらのデータが表示されなくなってしまいます。

「転送中にデータが消えてしまったのか？」と心配になりますが、結論から言うとデータは消えていません。写真アプリが表示できないだけです。

実はデータは消えていなかった

気圧や方角などの情報は、カメラメーカー独自の「MakerNotes」と呼ばれるEXIFフィールドに記録されています。Macの写真アプリは標準的なEXIF情報しか表示しないため、MakerNotesの内容は見えません。

OI.Share経由でiPhoneカメラロールを通した写真でも、USB-Cケーブルで直接Macに取り込んだ写真でも、exiftoolというコマンドラインツールを使えばすべてのデータを確認できます。

exiftoolのインストール

まずHomebrewでexiftoolをインストールします。Homebrewが未導入の場合は先にインストールしてください。

brew install exiftool

インストールが完了すると以下のように表示されます。

🍺  /opt/homebrew/Cellar/exiftool/13.55: 1,276 files, 57MB

exiftoolで確認する方法

ターミナルを開き、以下のコマンドを実行します。ファイル名は確認したい写真のものに変更してください。

exiftool ~/Downloads/ファイル名.JPG

特定のキーワードだけ抽出したい場合はgrepと組み合わせます。

exiftool ~/Downloads/ファイル名.JPG | grep -i "pressure"

実際の出力例はこちらです。

Manometer Pressure  : 100 kPa
Manometer Reading   : 62.1 m, 203.7 ft
Pressure            : 1000
GPS Img Direction   : 47
GPS Img Direction Ref : Magnetic North
Ambient Temperature : 20.6 C

TG-7が記録しているデータ項目

exiftoolで確認できるTG-7の主なデータ項目をまとめました。

まとめ

OI.Share経由でiPhoneカメラロールを通しても、TG-7が記録した気圧・方角などの環境センサーデータは消えません。Macの写真アプリに表示されないのは、アプリ側がMakerNotesを表示しない仕様のためです。

exiftoolを使えばターミナルからすべてのメタデータを確認できます。アウトドアや登山での撮影記録として活用してみてください。