今回の解除対象は「昼間飛行」の限定です。

講習を受け、修了審査にも無事合格。

これであとはオンラインで限定変更の手続きをすれば終わり。

そう思っていました。

ところが、実際に手続きを始めてみると、なかなか終わりません。

DIPSで申請しようとしたら、選択肢が出てこない

講習修了後、「無人航空機講習修了証明書」が発行されました。

そこで国土交通省の「DIPS2.0」にログインし、「技能証明書の限定変更」へ進みます。

ところが、途中にある、

「技能証明合格証明書番号」

のリストボックスに、何も表示されません。えっ？って思いました。

証明書は持っている。

講習にも合格している。

なぜ選べないのか。。。

マニュアルを確認し、講習機関から届いていた案内を改めて読み直してもすぐにわかりません。

イライラしながら試行錯誤してようやく判明。

私が持っていたのは、登録講習機関が発行する「講習修了証明書」。

DIPSが求めているのは、それとは別の「技能証明合格証明書」だったのです。

ちゃんと全部読め。と言われそうなところですね。読んでるんですけどね。

次は別のシステムへ

「技能証明合格証明書」を取得するためには、DIPSではなく、日本海事協会（ClassNK）の「無人航空機操縦士試験申込システム」で手続きをする必要があります。

つまり、

登録講習機関で講習・修了審査
↓
講習修了証明書を取得
↓
ClassNKで試験合格証明書の発行を申し込む
↓
技能証明合格証明書が発行される
↓
DIPS2.0に戻る
↓
技能証明の限定変更を申請する

という流れです。（ここでは健康診断は省略しています）

しかも、すでに技能証明を持っている私の場合、ClassNKでは通常の「試験合格証明書発行申込み」ではなく、「試験合格証明書発行申込み＜2回目＞」から手続きを行いました。

さらに申請画面を進めていくと、下のほうに、「管理者側のフォームです」

という、利用者としてはどう扱えばよいのか迷う表示まで出てきます。

最終的には申込みが完了しましたが、結果が確認できるようになるまでには、申込みから7営業日程度かかるとのこと。

その後、再びDIPS2.0に戻って限定変更申請を行います。

正直、「長い……」なあという感想です。

それぞれのシステムはデジタル化されている

ここで少し考えてみました。

今回利用した仕組みは、どれもデジタル化されています。

紙の申請書を持って役所の窓口を回ったわけではありません。

講習の情報も電子化されている。

ClassNKへの申込みもWebです。

国土交通省への申請もWebシステム（DIPS2.0）です。

つまり、

それぞれはデジタル化されている。

それなのに、利用者としてはあまり便利になった感じがしない。むしろ意味不明な流れ。

なぜでしょうか。

「部分最適」と「全体最適」の違い

理由の一つは、それぞれの業務が別々にデジタル化されていることにあるように思います。

今回の制度には、

• 登録講習機関
• 指定試験機関
• 国土交通省

という、それぞれ異なる役割があります。

講習を行う組織、国家資格として合格を確認する組織、技能証明を交付する行政機関。

責任を分けること自体には意味があります。

しかし、

組織が分かれていることと、利用者の手続きまで分断されていることは別問題です。

利用者からすると、やりたいことは非常にシンプルです。

「昼間飛行の限定を解除したい」

ただそれだけです。

ところがシステムを利用すると、

「ここまでは講習機関」

「ここからは指定試験機関」

「最後はDIPS」

という制度側の事情を理解しながら、自分でシステム間を移動しなければなりません。

これは行政システムだけの問題ではありません。

企業のDXでも、よく似たことが起きています。

社内DXでも同じことが起きる

例えば、

営業部には営業管理システム。

経理部には会計システム。

総務部にはワークフローシステム。

それぞれを導入したとします。

営業部では業務が効率化された。

経理部でもペーパーレスになった。

総務部でも電子承認ができるようになった。

一見すると、DXが進んでいるように見えます。

しかし実際の利用者が、

営業システムに入力
↓
PDFを出力
↓
経理システムに添付
↓
受付番号をコピー
↓
ワークフローシステムにもう一度入力

という作業をしていたらどうでしょう。

全部デジタルなのに、全体としてはあまり便利ではありません

これは「デジタル化」と「DX」の違いを考えるうえで、非常に分かりやすい例だと思います。

組織図ではなく「利用者の目的」から考える

システムを作る側は、どうしても組織単位、業務単位で考えます。

営業部のシステム。

経理部のシステム。

総務部のシステム。

しかし利用者は、組織図に沿って仕事をしているわけではありません。

利用者には、

「見積書を作りたい」

「商品を発注したい」

「休暇を申請したい」

といった「目的」があります。

今回のドローンの手続きも同じです。

利用者（私）の目的は、

「昼間飛行の限定を解除したい」

です。

その裏側で、

講習機関 → 指定試験機関 → 国土交通省

と処理が流れること自体は問題ありません。

利用者から見れば一つの入口で申請し、その裏側で必要なデータが連携される。

そんな仕組みであれば、制度上の責任分担を維持しながら、利用者の負担を大きく減らせるはずです。

DXで見るべきなのは「一連の体験」

今回の手続きを経験して、改めて感じたことがあります。

DXを考えるとき、

「システムを導入したか」

だけを見てはいけないということです。

そのシステムを使う人が、

目的を達成するまでに何をしなければならないのか。

ここまで見なければ、本当に業務が変わったかどうかは分かりません。

紙だった申請書をWebフォームにする。

ハンコを電子承認にする。

ExcelをWebシステムにする。

もちろん、それだけでも一定の効果はあります。

しかし、それぞれを個別にデジタル化した結果、利用者が複数のシステムを行ったり来たりしているのであれば、それはまだ途中なのだと思います。

DXで見るべきなのは、一つひとつのシステムではなく、利用者が目的を達成するまでの「一連の体験」です。

今回のドローン資格の手続きは、そのことを身をもって考える機会になりました。

システムを作るとき、業務改善をするとき、

「この部署の仕事をどうデジタル化するか」

だけではなく、

「利用者は、最初から最後までどう動くのか」

を一度通して見てみる。

それだけでも、見えてくる課題はかなり変わるのではないでしょうか。

会社を知ってもらう、商品やサービスを説明する。

料金を確認してもらう、問い合わせにつなげる。

検索エンジン対策、いわゆるSEOも、その先にいる「人に見つけてもらう」ための取り組みでした。

ところが、生成AIが普及したことで、この関係が少し変わり始めています。

ホームページを読むのは、もう人間だけではありません。

ホームページを見る前に、AIに聞く

例えば、旅行先でキャンプ場を探しているとします。

以前なら、「〇〇県 キャンプ場 ペット可」

などと検索して、いくつかのホームページを開いていました。

料金を見る。

設備を見る。

ペットのルールを確認する。

アクセスを調べる。

それぞれのホームページを見比べながら、自分の条件に合う場所を探します。

ところが生成AIを使えば、

「犬と一緒に泊まれて、車を横付けできて、近くに温泉があるキャンプ場を探して」

と、そのまま聞くことができます。

さらに、

「初心者でも利用しやすいところは？」

「焚き火ができるところに絞って」

と続けることもできます。

利用者自身がホームページを一つずつ調べるのではなく、AIに調べてもらう。

そんな情報の探し方ができるようになりました。

AIが間に入る

これまでの情報の流れを単純化すると、

人 → 検索 → ホームページ

でした。

ところが今後は、

人 → AI → ホームページなどの情報 → AI → 人

という経路も増えていくでしょう。

AIが人の代わりに情報を探し、整理して、説明する。

つまり企業側から見ると、

ホームページを最初に読む相手が、人間とは限らなくなった

ということです。

これはホームページの役割を考える上で、結構大きな変化だと思います。

AIは「雰囲気」だけでは判断できない

ホームページでは、写真やデザインも重要です。

きれいな風景。

楽しそうな利用者。

おしゃれな施設。

こうしたものを見て、

「ここ、良さそうだな」

と人は感じます。

しかし、AIが利用条件を調べる場合には、それだけでは足りません。

チェックインは何時なのか。

料金はいくらなのか。

ペットは利用できるのか。

どのサイトなら利用できるのか。

車は横付けできるのか。

焚き火はできるのか。

こうした情報が、言葉としてきちんと存在する必要があります。

写真を見れば何となく分かる。

常連なら知っている。

電話で聞いてもらえば分かる。

それだけでは、AIは正確に情報を扱えません。

「詳しくはお問い合わせください」の先

「詳しくはお問い合わせください」

という表現もよく見かけます。

もちろん、個別の判断が必要な内容であれば、それで問題ありません。

しかし、本来公開できる情報まで掲載されていなかったらどうでしょう。

これまでは、

ホームページに書いていない
↓
電話やメールで聞いてもらう

という流れが期待できました。

ところがAIを通じて比較される場面では、

情報が見つからない
↓
条件を満たしているか分からない
↓
別の候補が提示される

ということも考えられます。

「問い合わせてもらえば分かる」では、その問い合わせまでたどり着かない可能性があります。

だからといって、何でもホームページに掲載すればよいという話ではありません。

重要なのは、

公開できる情報を、きちんと公開できているか。

ということです。

SEOからAI対策へ、ではない

ここで、

「これからはSEOではなくAI対策だ」

という話にしたくなるところですが、私は少し違うと思っています。

検索エンジンもAIも、そして何より人間も、必要としているものには共通点があります。

正確な情報。

具体的な情報。

整理された情報。

最新の情報。

分かりやすい情報。

結局のところ、

自社について、きちんと説明できているか。

という基本に戻ってきます。

AIに読んでもらうためだけに、不自然な文章を大量に作る必要はありません。

人が読んでも理解でき、AIが参照しても意味を取り違えにくい情報を整える。

その方が意味があって、本質的です。

ホームページは「企業の公式情報源」になる

ここまで考えると、ホームページの見方も少し変わってきます。

これまでは、

ホームページ＝人に見てもらうメディア

という性格が強かったと思います。

これからは、それに加えて、

ホームページ＝自社についての公式情報を置いておく場所

という役割が、より重要になるのではないでしょうか。

人が読む。

検索エンジンが読む。

自社のAIチャットが読む。

外部の生成AIが参照する。

今後はAIエージェントが情報を確認する場面も増えてきます。

誰が読む場合でも、参照する元の情報が正確でなければ、正確には伝わりません。

生成AIの性能がどれだけ高くなっても、

元になる情報が存在しなければ、AIにも伝えられない。

これは変わりません。

AIに読ませてみると、自社の情報が見えてくる

これまでこのシリーズでは、実際にホームページの情報をAIに読ませることを考えてきました。

すると、

「この質問には答えられない」

「情報はあるけれど、複数のページに分散している」

「ページによって説明が違う」

「古い情報が残っている」

といったことが見えてきます。

これはAIのためだけの問題ではありません。

人間にとっても同じです。

AIに読ませることが、

自社は何を伝えていて、何を伝えられていないのか

を確認する機会にもなります。

では、誰のために書くのか？

AI時代のホームページは、

人のために書くのか。

検索エンジンのために書くのか。

AIのために書くのか。

どれか一つを選ぶ必要はないと思います。

相手に合わせて情報を小手先で最適化するよりも、

自社について必要な情報を、正確に、分かりやすく、整理して公開する。

まずはそこではないでしょうか。

人が読んでも分かる。

検索しても見つかる。

AIが参照しても意味が分かる。

そんな状態を作っておく。

これからのホームページは、「見てもらうための場所」だけではなく、

自社を正しく知ってもらうための情報資産

になっていくのかもしれません。

AI時代だからこそ、

「ホームページをどう見せるか」だけではなく、

「自社について、何を、どう伝えておくのか」

を改めて考える必要がありそうです。

お客様は知りたい。

でも、ホームページには書いていない。

AIが答えられなかった質問を調べることで、そんな情報の抜けを見つけることができます。

ところが、実際にホームページの情報をAIに読ませてみると、もう一つ別の問題が見えてきます。

情報は、ちゃんと書いてある。

それなのに、うまく答えられない。

なぜでしょうか。

「ちゃんと書いてあります」

例えば、キャンプ場のホームページにAIチャットを設置したとします。

利用者から、

「犬と一緒にキャンプできますか？」

と質問がありました。

ホームページには、

「ペット同伴可」

と書いてあります。

ですから、

「はい、ペットと一緒に利用できます」

と答えることはできそうです。

ところが、もう少し詳しくホームページを見ていくと、

施設紹介ページには、

「ペット同伴可」

利用規約には、

「ペット同伴で利用できるのは指定されたサイトのみ」

FAQには、

「場内では必ずリードを着用してください」

と書かれていたとします。

情報はあります。

しかも、どれも間違っているわけではありません。

問題は、

情報がバラバラに存在していることです。

人間なら「なんとなく」読める

人間がホームページを見る場合は、それでも理解できることがあります。

施設紹介を読む。

「ペットOKなんだ」

FAQを見る。

「リードが必要なのね」

予約するときに利用規約を見る。

「利用できるサイトは決まっているのか」

複数のページを読みながら、頭の中で情報をつなぎ合わせます。

しかし、本当にこれで「分かりやすいホームページ」と言えるでしょうか。

初めて利用する人が、すべてのページを読んでくれるとは限りません。

「ペット同伴可」だけを見て予約し、後になって、

「このサイトではペットと泊まれないんですか？」

となる可能性もあります。

つまり、

「ホームページに書いてある」ことと、「利用者に伝わっている」ことは同じではありません。

AIに読ませると、情報の「散らかり」が見えてくる

AIにホームページを読ませて質問してみると、こうした問題が見えやすくなります。

同じことについて、複数のページに違う表現で書かれている。

重要な条件だけが別ページに書かれている。

FAQと利用規約で表現が違う。

古いお知らせに以前のルールが残っている。

サービスの名称がページによって違う。

人間が読めば「たぶんこういう意味だろう」と補える場合でも、情報として見ると整理されていないことがあります。

AIに質問してみることで、

「情報はある。でも、情報の置き方が分かりにくい」

という問題が見えてきます。

情報が矛盾していたら、どちらを信じる？

さらに困るのが、情報の不一致です。

例えば、

施設案内には、

「チェックイン 13:00〜」

と書いてある。

FAQには、

「チェックイン 14:00〜」

と書いてある。

どちらが正しいのでしょうか。

人間なら、

「どちらかが古いのかな？」

と思うでしょう。

AIも同じように迷います。

もちろん、AIがどちらかを選んで回答することはできます。

しかし、それでは困ります。

本来の問題はAIではなく、

ホームページの中に異なる情報が存在していること

だからです。

AIの回答を修正するより、元になっているホームページを修正した方がよいでしょう。

古い情報も意外と残っている

ホームページを長く運用していると、情報は少しずつ増えていきます。

サービスページ。

FAQ。

ブログ。

過去のお知らせ。

キャンペーン。

PDF。

そのときは正しかった情報でも、数年後には変わっていることがあります。

料金が変わった。

営業時間が変わった。

ルールが変わった。

サービス名が変わった。

新しいページは修正した。

しかし、3年前のお知らせには古い情報が残っている。

人間なら掲載日を見て、

「これは古い記事だから」

と判断できるかもしれません。

しかし、ホームページ全体を「企業が公開している情報」として見ると、

新しい情報と古い情報が同時に存在している

状態です。

AIに情報を利用させるようになると、こうした情報管理の問題も無視できなくなります。

AIのためにホームページを直す？

ここまで読むと、

「では、AIが読みやすいようにホームページを作り直さなければならないのか」

と思うかもしれません。

私は、少し違うと考えています。

例えば、

重要な条件を一か所にまとめる。

同じものは同じ名称で表現する。

例外条件を明確にする。

古い情報を整理する。

FAQを充実させる。

料金や営業時間を分かりやすくする。

これらはAIのためだけに必要なことでしょうか。

違います。

人間にとっても、その方が分かりやすい。

AIに読ませたことで、これまで気づかなかったホームページの分かりにくさが見えてきただけです。

「情報量」より「情報設計」

ホームページを充実させようとすると、情報を増やすことを考えがちです。

新しいページを作る。

FAQを増やす。

ブログを書く。

詳しい説明を追加する。

もちろん、それも必要です。

しかし、情報が増えれば増えるほど、

どこに何を書くのか。

同じ情報をどう管理するのか。

何を最新情報とするのか。

どのページを見れば正しい情報が分かるのか。

といった「情報設計」が重要になります。

単に情報が多ければよいわけではありません。

必要な情報が、必要な形で整理されていること。

AIにホームページを利用させるようになると、その重要性がより分かりやすくなります。

AIをホームページの「点検役」にする

前回は、AIチャットを「お客様が何を知りたいのかを知るセンサー」として使えるのではないか、という話をしました。

もう一つ、

ホームページの情報を点検する仕組み

として考えることもできます。

いろいろな質問をしてみる。

回答できなければ、情報が不足していないか確認する。

回答が曖昧なら、情報が分散していないか確認する。

回答がおかしければ、古い情報や矛盾した情報がないか確認する。

そして、元のホームページを改善する。

AIの回答だけを直すのではありません。

AIが参照している情報そのものを良くしていく。

この考え方が重要だと思います。

「書いてある」から「伝わる」へ

これまでホームページを作る側は、

「その情報ならホームページに書いてあります」

と言うことがありました。

確かに書いてある。

でも、見つからない。

意味が分からない。

条件が別の場所にある。

どれが最新なのか分からない。

それでは、利用者にとって「伝わっている」とは言えません。

AIにホームページを読ませてみると、この違いが意外とはっきり見えてきます。

大切なのは、

「書いてあるか」ではなく、「必要な人に正しく伝わる状態になっているか」。

AI時代のホームページでは、情報量を増やすだけでなく、企業が持つ情報そのものを整理していくことが、これまで以上に重要になるのかもしれません。

そして、ここからもう一つ疑問が生まれます。

これまでホームページは、基本的に「人に読んでもらう」ことを前提に作られてきました。

しかし今後、ホームページの情報を読むのは、人間だけなのでしょうか。

次回は、

「AI時代、ホームページは誰のために書くのか？」

について考えてみたいと思います。

ホームページの中から情報を探すのではなく、知りたいことをそのままAIに質問する。

問い合わせ対応に使ったり、社内から情報を探したりすることもできます。

今回は、その仕組みを使っていて気づいた、もう一つの使い方について紹介します。

注目するのは、

AIが「答えられなかった質問」です。

AIなら、できるだけ多くの質問に答えてほしい

ホームページにAIチャットを設置すると、当然ながら、できるだけ多くの質問に答えられるようにしたくなります。

利用者が質問する。

AIが適切に回答する。

問題が解決する。

これが理想です。

逆に、

「その情報は確認できませんでした」

「ホームページ内に該当する情報がありません」

という回答が返ってくると、

「AIがうまく答えられなかった」

と考えてしまいます。

もちろん、AI側の仕組みを改善すべきケースもあります。

しかし、すべてがAIの問題とは限りません。

そもそも、情報がないのでは？

例えば、キャンプ場のホームページにAIチャットを設置したとします。

利用者から、

「雨の日でも焚き火はできますか？」

という質問がありました。

AIはホームページを探します。

しかし、その情報がどこにも書かれていない。

この場合、AIは明確に回答できません。

では、これはAIチャットの失敗でしょうか。

少し見方を変えると、

お客様が知りたい情報が、ホームページに掲載されていない

ことが分かったとも言えます。

これは、AIの回答精度とは別の問題です。

「問い合わせ」はニーズそのもの

ホームページを作る側は、

「お客様が知りたいであろう情報」

を考えて掲載します。

営業時間。

料金。

サービス内容。

アクセス。

よくある質問。

しかし、作る側が想定していることと、実際に利用者が知りたいことが同じとは限りません。

例えばキャンプ場なら、

「雨でも焚き火できますか？」

「夜は何時まで車を出入りできますか？」

「テントサイトからトイレまでどのくらいですか？」

「近くで薪を買えますか？」

「小さな子どもでも使えるシャワーですか？」

運営側にとっては当たり前すぎて、ホームページに書いていないこともあります。

しかし、初めて利用する人にとっては重要な情報です。

AIチャットに入力された質問は、

利用者が実際に知りたいと思った情報

そのものです。

ここに価値があります。

回答できなかった質問を集めてみる

そこで、AIが答えた内容だけではなく、

答えられなかった質問を確認する

ようにします。

すると、

同じ質問が何度も出ている。

似たような質問が多い。

特定のサービスについて質問が集中している。

といったことが見えてくるかもしれません。

例えば、

「ペットと利用できますか？」

という質問には回答できる。

しかし、

「ペットは何匹までですか？」

には答えられない。

さらに、

「大型犬でも利用できますか？」

「ドッグフリーサイト以外にも犬を連れて行けますか？」

といった質問も出てくる。

そうすると、

「ペット可」

という情報だけでは、利用者にとって十分ではないことが分かります。

ホームページを改善する

そこで、回答できなかった質問をもとにホームページを見直します。

FAQを追加する。

利用案内を詳しくする。

サービス説明を書き直す。

必要であれば、新しいページを作る。

すると、

利用者が知りたい情報が増える。

ホームページ自体が分かりやすくなる。

そして、その情報を参照するAIも答えられるようになる。

つまり、

質問される
↓
AIが回答する
↓
回答できなかった質問を確認する
↓
不足している情報を追加する
↓
ホームページが改善される
↓
AIが回答できる範囲も広がる

という循環が生まれます。

「回答率100％」を目指す必要はない

ただし、AIがすべての質問に答えられるようにする必要はありません。

むしろ、それは危険です。

ホームページに情報がない。

個別の確認が必要。

担当者の判断が必要。

そのような質問について、AIが無理に回答するべきではありません。

例えば、

「明日の朝7時にチェックインできますか？」

という質問。

通常のチェックイン時間についてはホームページに書いてあっても、例外対応が可能かどうかは担当者に確認しなければ分からないかもしれません。

その場合は、

「ホームページ上では確認できません。施設へお問い合わせください」

と案内する方が適切です。

大切なのは、

何でも答えるAIを作ることではなく、答えてよいことと、答えてはいけないことを分けること

です。

「答えられない」は失敗ではない

AIチャットを評価するとき、

「何件の質問に答えられたか」

だけを見ると、回答できなかった質問は失敗に見えます。

しかし、

「なぜ答えられなかったのか」

まで見ると、意味が変わります。

AIの仕組みに問題があるのか。

ホームページの書き方が分かりにくいのか。

必要な情報そのものが掲載されていないのか。

そもそもAIが答えるべき質問ではないのか。

原因によって、対応はまったく違います。

つまり、

「答えられなかった」という結果そのものが、改善のための情報になります。

AIチャットを「センサー」として考える

こう考えると、ホームページに設置するAIチャットの役割も少し変わります。

問い合わせに答える。

情報を探す。

それだけではありません。

利用者が何を知りたいのか。

どんな言葉で質問するのか。

どこで困っているのか。

自社が何を伝えられていないのか。

それを知るための、

「センサー」

として使うこともできます。

これまでのホームページは、企業から利用者へ情報を発信するものが中心でした。

AIチャットを置くことで、

利用者から企業へ、

「私はこれを知りたい」

という情報も戻ってきます。

その声を使って、またホームページを改善する。

AIを問い合わせ対応の省力化だけに使うのではなく、

お客様を知るための仕組みとして使う。

そんな使い方もできるのではないでしょうか。

会社概要、商品・サービス、営業時間、アクセス、よくある質問、過去のお知らせ。

企業のホームページには、実はかなり多くの情報が蓄積されています。

そこで、ホームページ上で公開されている情報をAIが参照し、質問に答えられる仕組みを試してみました。いわゆるAIチャットですね。

今回は技術的な作り方ではなく、実際に何ができるのかを紹介します。

ホームページには情報がある。でも、探すのは大変

企業のホームページには、さまざまな情報があります。

しかし、情報量が増えてくると「どこに書いてあるのか分からない」という問題が起きます。

例えばキャンプ場なら、

「チェックインは何時からですか？」

「車はサイトに横付けできますか？」

「焚き火はできますか？」

「ペットと一緒に泊まれますか？」

「近くに温泉はありますか？」

といった質問があります。

答えはホームページに書いてある。

でも、どのページにあるのか分からない。

利用案内、FAQ、施設紹介など、複数のページに情報が分かれていることもあります。

サイト内検索を使っても、適切なキーワードを入れなければ、目的の情報がうまく見つからないことがあります。

そこで、ホームページの情報をAIから利用できるようにします。

「検索する」から「質問する」へ

例えば、

「犬と一緒にキャンプしたいのですが、利用できますか？」

と質問します。

AIはホームページに掲載されている情報を参照して、関連する内容を探します。

そして、その情報をもとに回答します。

利用者は、

メニューからページを探す。

ページを開く。

文章を読む。

別のページも確認する。

といった操作をする必要がありません。

知りたいことを、そのまま質問できます。

例えば、

「ペットOKで、車を横付けできるサイトはありますか？」

といった複数の条件を含む質問も考えられます。

従来のサイト内検索では、「ペット」「車」「横付け」といったキーワードで検索し、それぞれの情報を自分で確認する必要があります。

AIを利用すると、ホームページ内の情報を横断して探し、質問に合わせて整理することができます。

つまり、

「情報を検索する」から「情報について質問する」へ。

ホームページの使い方そのものを変えることができます。

お問い合わせ対応にも使える

この仕組みは、お問い合わせ対応にも利用できます。

サービス業では、ホームページに掲載している内容について、同じような問い合わせが繰り返し入ることがあります。

キャンプ場なら、

営業時間や利用料金。

チェックイン・チェックアウト。

予約やキャンセル方法。

設備やレンタル品。

ペットの同伴。

焚き火やゴミのルール。

周辺施設やアクセス。

などです。

こうした質問にAIが回答できれば、人が対応する問い合わせを減らせる可能性があります。

もちろん、すべてをAIに任せる必要はありません。

ホームページに掲載されている一般的な質問はAI。

個別の確認や判断が必要な問い合わせは担当者。

という使い分けもできます。

キャンプ場に限らず、宿泊施設、観光施設、店舗、スクールなど、問い合わせの多いサービス業では同じような使い方が考えられます。

社内でも使える

少し面白いのは、同じ仕組みを社内でも利用できることです。

例えば、新しく入ったスタッフが、

「ペット利用のルールはどうなっていたかな？」

「キャンセル料は何日前から発生するんだろう？」

と思ったとき。

ホームページを探す代わりに、AIへ質問できます。

ホームページはお客様向けに作られたものですが、別の見方をすると、

会社が公式に公開している情報をまとめたデータベース

でもあります。

AIを使うことで、その情報をお客様だけではなく、社内からも利用しやすくなります。

AIに読ませると、別のことも見えてくる

実際に試してみて面白かったのは、AIが答えられることだけではありませんでした。

むしろ、

AIが答えられなかった質問

です。

例えば、

「雨の場合でも焚き火はできますか？」

と利用者が質問したとします。

しかし、ホームページのどこにもそのルールが書かれていない。

当然、ホームページの情報だけを参照しているAIも、明確には答えられません。

これはAIの問題でしょうか。

もちろん、AI側の問題である可能性もあります。

しかし、別の可能性もあります。

そもそもホームページに、その情報が掲載されていない。

ということです。

お客様は知りたい。

でも、企業側はその情報を発信していない。

これまで気づかなかった「情報の不足」が、AIとのやり取りから見えてきます。

「答えられなかった質問」に価値がある

ここは、AIチャットを導入してみて特に面白いところです。

一般的には、

AIが回答できた
＝成功

AIが回答できなかった
＝失敗

と考えがちです。

しかし、少し見方を変えることができます。

AIが答えられなかったということは、

「お客様が知りたいのに、自社が十分に発信できていない情報」

を見つけた可能性があります。

同じような質問が何度も出てくるのであれば、その情報をホームページに追加する。

FAQに掲載する。

施設案内を詳しくする。

分かりにくい説明を書き直す。

すると、

質問される
↓
AIが回答する
↓
回答できなかった質問を確認する
↓
ホームページを改善する
↓
AIが回答できる範囲も広がる

という循環を作ることができます。

AIチャットは、単なる問い合わせ対応ツールではありません。

「お客様が知りたいこと」を知るための仕組み

として使うこともできます。

ホームページそのものが改善される

ここで重要なのは、AIの回答精度だけを改善するわけではないということです。

AIが答えられなかった質問をもとにホームページを改善すれば、人間が普通にホームページを見たときにも情報を見つけやすくなります。

つまり、

AIのためにホームページを改善する。

というより、

AIとのやり取りを通じて、お客様にとって不足している情報を発見する。

という考え方です。

結果として、

ホームページを見る人にとっても分かりやすくなる。

AIも回答しやすくなる。

問い合わせ対応も減る。

という効果が期待できます。

公開情報は「AIが使える情報資産」になる

ホームページは、これまで基本的に「人が読むもの」でした。

しかし生成AIが普及すると、その位置づけも少し変わってくるように思います。

ホームページに掲載された情報をAIが参照する。

AIが必要な情報を探す。

AIが整理する。

そして、人がAIを通じてその情報を利用する。

そう考えると、企業がこれまで蓄積してきたホームページの情報は、

AIが利用できる情報資産

として見ることもできます。

新しい情報を一から作らなくても、すでに公開している情報の使い方を変えるだけで、新しい活用方法が生まれます。

まずは「今ある情報」から

AI活用というと、大規模なシステムや大量のデータが必要なイメージがあります。

しかし、企業にはすでに使える情報があります。

その一つがホームページです。

会社概要。

サービスや商品。

利用方法。

FAQ。

お知らせ。

ブログ。

採用情報。

まずは、こうした「すでに持っている情報」をAIから使えるようにしてみる。

そこから始めてもよいのではないでしょうか。

ホームページを、

「見てもらう場所」から「AIを通じて活用する情報資産」へ。

生成AIによって、ホームページの新しい使い方が見えてきています。

最終的には、単純なテキストだけでなく、

• QRコード
• 日本語
• 罫線付きの表
• フォントサイズの自動調整

まで印刷できました。

今回はそのセットアップ手順をまとめます。

構成

今回使用した構成は以下です。

• Raspberry Pi
• 58mm Thermal Receipt Printer MJ-5890K
• USB接続
• Python 3
• python-escpos
• Pillow
• qrcode

最終的な印刷の流れは、

Raspberry Pi
    ↓
Python
    ↓
Pillow / qrcode
    ↓
レシート画像を生成
    ↓
python-escpos
    ↓
/dev/usb/lp0
    ↓
MJ-5890K

という構成にしました。

日本語や表などは、プリンタへ文字として送るのではなく、レシート全体を画像として生成して印刷します。

この方法なら、プリンタ側の日本語フォントや文字コードへの依存をかなり減らせます。

Raspberry PiにUSB接続

まずMJ-5890KをRaspberry PiにUSB接続します。

認識状態を確認します。

lsusb

今回の環境では以下のように認識されました。

Bus 001 Device 004: ID 0416:5011 Winbond Electronics Corp. Virtual Com Port

VID/PIDは、

VID: 0416
PID: 5011

です。

ここで「Virtual Com Port」と表示されたので、最初はシリアルデバイスかと思いました。

しかし、

ls -l /dev/ttyUSB* /dev/ttyACM*

を確認してもデバイスがありません。

そこでカーネルの認識状態を確認しました。

sudo dmesg | grep -Ei '0416|5011|Winbond|usblp|ttyUSB|ttyACM'

結果は、

usb 1-1.3: New USB device found, idVendor=0416, idProduct=5011
usblp 1-1.3:1.0: usblp0: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x0416 pid 0x5011
usbcore: registered new interface driver usblp

となっていました。

つまりシリアルポートではなく、LinuxのUSBプリンタとして認識されています。

デバイスは、

/dev/usb/lp0

です。

lsusbに表示される製品名だけでは判断せず、dmesgまで確認するのがポイントでした。

まずは直接印刷してみる

Pythonを使う前に、Linuxから直接データを送って印刷できるか確認します。

printf '\x1b\x40Hello Raspberry Pi!\nTest Print\n\n\n' | sudo tee /dev/usb/lp0 > /dev/null

無事、

Hello Raspberry Pi!
Test Print

と印刷されました。

これで、

Raspberry Pi → /dev/usb/lp0 → MJ-5890K

の経路が正常に動いていることが確認できます。

Python環境を作る

今回はシステムのPython環境を直接変更せず、venvを使用しました。

mkdir -p ~/thermal-print
cd ~/thermal-print

python3 -m venv .venv
source .venv/bin/activate

必要なライブラリをインストールします。

pip install "qrcode[pil]" python-escpos

Pythonから印刷するとPermission denied

Pythonから/dev/usb/lp0を開こうとすると、

PermissionError: [Errno 13] Permission denied: '/dev/usb/lp0'

となりました。

デバイスの権限を確認します。

ls -l /dev/usb/lp0

今回の環境では、

crw-rw---- 1 root lp 180, 0 ... /dev/usb/lp0

となっていました。

そこで、実行ユーザーをlpグループへ追加します。

sudo usermod -aG lp $USER

確認します。

getent group lp

グループ追加後は、一度ログアウトしてログインし直します。

groups

でlpが含まれていれば、sudoを使わずにPythonからプリンタへアクセスできます。

QRコードを印刷する

まずQRコードだけ印刷してみます。

今回は「なっぷ」のURLをQRコードにしました。

import qrcode
from escpos.printer import File

URL = "https://www.nap-camp.com"
PRINTER = "/dev/usb/lp0"

qr = qrcode.QRCode(
    version=None,
    error_correction=qrcode.constants.ERROR_CORRECT_M,
    box_size=8,
    border=4,
)

qr.add_data(URL)
qr.make(fit=True)

img = qr.make_image(
    fill_color="black",
    back_color="white"
)

img.save("/tmp/qr.png")

printer = File(PRINTER)

printer.set(align="center")
printer.image("/tmp/qr.png")
printer.text("\n\n\n")

printer.close()

実行します。

python3 print_qr.py

QRコードも問題なく印刷でき、スマートフォンから読み取ることができました。

日本語を印刷する

次は日本語です。

プリンタ側の日本語フォントや文字コードに依存する方法ではなく、Pillowで日本語を画像化して印刷することにしました。

日本語フォントとしてNoto Sans CJKをインストールします。

sudo apt update
sudo apt install -y fonts-noto-cjk
fc-cache -fv

フォントの場所を確認します。

fc-match "Noto Sans CJK JP" -f '%{file}\n'

今回使用したフォントは、

/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc
/usr/share/fonts/opentype/noto/NotoSansCJK-Bold.ttc

です。

Pillowからこのフォントを指定すれば、日本語を画像として描画できます。

58mm幅のレシートを画像として作る

今回のプリンタでは、レシート画像を384px幅で作成しました。

WIDTH = 384

例えば、

       キャンプ場検索

        [QRコード]

   QRコードを読み取って
   キャンプ場を検索できます

      www.nap-camp.com

というレイアウト全体をPillowで1枚の画像として生成します。

その画像を、

printer.image("/tmp/receipt.png")

で印刷します。

この方式にすると、HTML/CSSで画面を作るのに近い感覚でレシートのレイアウトを組めます。

表形式も印刷できる

Pillowで罫線を描画すれば表も作れます。

今回は4列×5行、

┌──────┬────────┬──────┬────────┐
│ A    │ 値A    │ F    │ 値F    │
├──────┼────────┼──────┼────────┤
│ B    │ 値B    │ G    │ 値G    │
├──────┼────────┼──────┼────────┤
│ C    │ 値C    │ H    │ 値H    │
├──────┼────────┼──────┼────────┤
│ D    │ 値D    │ I    │ 値I    │
├──────┼────────┼──────┼────────┤
│ E    │ 値E    │ J    │ 値J    │
└──────┴────────┴──────┴────────┘

という形式を作りました。

構造としては、

ヘッダ | 値 | ヘッダ | 値

です。

384pxの幅に対して、

col_widths = [
    72,     # ヘッダ
    104,    # 値
    72,     # ヘッダ
    104     # 値
]

としました。

長い文字は自動的にフォントを小さくする

表形式では、データによって文字数が変わります。

そこでセル幅を超える場合は、自動的にフォントサイズを小さくするようにしました。

def fit_font(draw, text, font_path, max_width,
             start_size=20, min_size=10):

    text = str(text)

    for size in range(start_size, min_size - 1, -1):

        font = ImageFont.truetype(
            font_path,
            size
        )

        bbox = draw.textbbox(
            (0, 0),
            text,
            font=font
        )

        text_width = bbox[2] - bbox[0]

        if text_width <= max_width:
            return font

    return ImageFont.truetype(
        font_path,
        min_size
    )

例えば、

12,345円

なら大きな文字のまま表示し、

ABC-123456789

のような長い文字列なら、セルに収まるまでフォントサイズを小さくします。

ここまででできたこと

今回の検証では、以下まで確認できました。

• Raspberry PiからMJ-5890KをUSB認識
• /dev/usb/lp0への直接印刷
• Pythonからの印刷
• sudoなしでの印刷
• QRコード印刷
• 日本語印刷
• QRコード＋日本語のレイアウト
• 4列×5行の表
• 長い文字列のフォントサイズ自動調整

安価な58mmサーマルプリンタですが、Pythonと組み合わせるとかなり自由度の高い出力ができそうです。

特に、プリンタの文字コードやフォント機能に依存せず、Pillowで「レシート全体を画像として作る」という方法は扱いやすいと感じました。

今後は、Webシステムやkintoneなどのデータと連携して、Raspberry Piを小型のレシート印刷端末として使うところまで試してみたいと思います。

私は、そのようには考えていません。

kintoneは非常に優れたツールですが、どんな組織にも適合する万能なシステムではありません。

導入することが目的ではなく、導入した後にどのように活用し、改善を続けられるかが重要です。

仕事は常に変化している

仕事は、お客様の要望や法改正、働く人、技術の進歩などによって、少しずつ変化していきます。

10年前と全く同じ仕事を、全く同じやり方で続けている会社は、ほとんどないでしょう。

だからこそ、「今のやり方を続ける」だけではなく、その変化に合わせて仕事を見直し、少しずつ改善していくことが大切だと考えています。

業務改善は特別な仕事ではない

「業務改善」と聞くと、何か大掛かりなプロジェクトを想像する方もいます。

しかし、私が考える業務改善はもっと身近なものです。

• この入力は不要ではないか
• このボタンを追加すると使いやすいのではないか
• この帳票はもっと見やすくならないか
• この情報を共有すれば問い合わせが減るのではないか

そんな小さな改善を積み重ねることも、立派な仕事の一つです。

改善は通常業務とは別の活動ではなく、日々の仕事の延長線上にあるものだと考えています。

kintoneが活きる理由

kintoneは、現場が

使う → 気づく → 改善する

というサイクルを繰り返すことで、本来の価値を発揮するツールです。

実際に kintone Hive の発表を聞いていると、現場の皆さんが自分たちの業務をより良くするために試行錯誤を重ね、その結果として大きな成果につなげている事例が数多く紹介されています。

私は、その発表を聞くたびにワクワクします。

なぜなら、システムを導入したことが成果なのではなく、改善を続ける文化が成果を生み出していることが伝わってくるからです。

kintone hive（キントーンハイブ） 公式ポータルサイト

「kintone hive」とは、日頃から業務の中でkintoneを活用しているユーザーが一堂に会し、kintoneによる業務改善プロジェクト成功の秘訣や活用のコツをそれぞれの視点で解説、貴重なノウハウやアイディアを交換するリアルイベントで（続きを読む）

kintone.cybozu.co.jp

kintoneが活きにくい組織もある

一方で、次のような考え方の組織では、kintoneの強みを十分に活かすことは難しいと感じています。

• 業務改善は仕事ではない
• 改善は通常業務とは別
• 自分たちは業務を変える必要はない

このような環境では、「使う → 気づく → 改善する」というサイクルが回りません。

その結果、せっかく導入したkintoneも、「最初に作ったアプリを使い続けるだけ」のシステムになってしまいます。

もちろん、それが悪いという話ではありません。

そのような組織であれば、無理にkintoneを導入するよりも、要件が固まった既存の製品やサービスを導入した方が、結果として幸せになれるケースも多いと思います。

これは組織の良し悪しではなく、組織文化とツールの相性の問題です。

私がご支援したい組織

私は、「どんな組織でも支援したい」とは考えていません。

改善を通じて少しずつ前へ進もうとする組織。

現場の声を大切にしながら、より良い仕事のやり方を一緒に考えようとする組織。

そして、

• 決断が早い
• まずは小さく試してみる
• 結果を見ながら改善を重ねる

そんな組織とは、とても相性が良いと感じています。

DXや業務改善には、「まずやってみる」という姿勢が欠かせません。

完璧な計画を立ててから動くよりも、小さく始めて、現場の声を聞きながら改善を積み重ねる方が、結果として大きな成果につながることを何度も見てきました。

もちろん、慎重に検討することも大切です。

しかし、提案を何か月も、あるいは何年も検討したまま動けない状況では、私も十分な価値をご提供することは難しいと考えています。

だからこそ私は、現場の皆さんと一緒に考え、一緒に改善を積み重ね、その積み重ねが会社の成長につながる。

そんな組織を、これからも応援していきたいと思っています。

最後に

システムは、導入することがゴールではありません。

本当の目的は、仕事をより良くすることです。

私は、システムを導入すること以上に、改善が続く組織づくりをご支援したいと考えています。

もし皆様の組織でも、「もっと現場が改善しやすい仕組みを作りたい」「kintoneを導入したい」ではなく、「改善が続く組織を作りたい」という思いがありましたら、以下のフォームよりお気軽にご相談ください。

テクノロジーの世界では、いま「複雑化」と「単純化」が同時に進行している。
メーカーは“簡単に使える”ことを掲げ、設定や操作をどんどん削っていく。
ところが、その単純化が、かえってユーザー体験を複雑にしてしまう場面がある。

たとえば iOS。バージョンアップによっては、従来あった細かい設定項目が統合・縮小され、
一部は完全にユーザーの視界から消えてしまう。

Apple にとっては「一般ユーザーには不要」な調整かもしれない。
だが、必要な時に“どこにも見当たらない設定”を探す側にとっては、状況は真逆だ。

追い打ちをかけるのが、Web 上に残り続ける古い情報である。
検索すれば「iOS 15 以降は…」といった記事が山ほど見つかるが、
その多くは最新仕様に合わせて更新されていない。
説明されたメニューが、そもそも現行 iOS には存在しないことも珍しくない。
ユーザーは右往左往し、辿り着いた設定画面はすでに廃止――。
まるで地図の更新が止まった街を歩いているような感覚だ。

さらに、この状況はユーザーサポートにも負担を与える。
案内に使われている社内資料やFAQが古ければ、問い合わせは増加する一方。
ユーザーもサポートも同じ “古い地図” を手に迷子になる構図が生まれてしまう。

単純化は、必ずしも悪ではない。
不要な選択肢を減らし、間違えようのない UI を整えれば、
多くの人にとって扱いやすいデバイスになる。
しかしその裏で、細かな制御を求めるユーザーの選択肢は着実に減っていく。
自動化が進むほど、トラブル時の「手動で何とかする」余地も狭まる。

いま問われるべきは、ただ設定を減らしたり隠したりすることではなく、
“必要な時に、必要な情報へ確実にアクセスできる仕組み” をどう確保するかだろう。

技術が進化するほど、表面は滑らかになる。
しかし、その滑らかさの裏で進む複雑さを見逃してはいけない。
単純化の時代にこそ、ユーザーはより賢く、メーカーはより透明であるべきだ。

Macのストレージを確認したら「システムデータ」が数百GBに膨れ上がっている──そんな経験ありませんか？
今回は実際に私のMacBook Pro（M1 Pro, macOS Sonoma）で「システムデータが増え続ける」現象に対して、いろいろ切り分けた結果です。

症状：ストレージの「システムデータ」が増え続ける

仕事中、なんだかアプリの動作が変になって来て、おかしいなあと思い調べてみたところ、以下の状況になっていました。

• Macの「ストレージ」表示で「システムデータ」が数百GB以上存在
• 空き容量がほとんど無い状態まで圧迫
• キャッシュ削除や再起動をしても効果は一時的
• iCloudドライブをオフにすると、キャッシュ領域は削除される
• iCloudドライブをオンにすると、時間とともに徐々に増加する
• iCloudドライブは同期のみ。最適化はオンにしていない
• Appleサポートも適切な回答を得られず

ひどい状況です。残り1Gくらい。それでも動作するmacOS。

単純な話でした。

「Macストレージを最適化」をオンにするだけです。

macOS「Macストレージを最適化」の正しい理解

今回の「システムデータ肥大化」問題を掘り下げていく中で、

実はもうひとつ見逃せない要因がありました。

それが 「Macストレージを最適化」設定の誤解 です。

🔍 一見すると逆に読める説明文

「システム設定 → Apple ID → iCloud Drive」にある

「Macストレージを最適化」 の説明にはこう書かれています：

十分な空き領域があるときは、iCloud Driveの内容がすべてこのMacに保存されます。

空き領域が足りなくなると、古い書類はiCloudにのみ保存されます。

この説明、ぱっと見では「最適化をオンにするとローカルに全部保存される」とも読めてしまいます。

実際、私も最初そう解釈していました。

しかし動作を実際に観察すると、実際はその逆 でした。

✅ 「オン」と「オフ」でこう変わる

つまり、「Macストレージを最適化」はオンにすべき設定 です。

オフのままだと、~/Library/Mobile Documents 以下に

iCloud Driveの全ファイルがローカルコピーとして保存されてしまい、

「システムデータ」の一部として膨張します。

📦 どうして「システムデータ」に分類されるのか？

macOSは iCloud Drive のキャッシュやローカルコピーを「ユーザーデータ」ではなく、

システム管理領域として扱うことがあります。

これが Finder では「iCloud Drive」に見えても、

ストレージ情報では「システムデータ」として表示される理由です。

⚙️ 最適な設定方法

1. システム設定 → Apple ID → iCloud Drive を開く
2. 「このMacを同期」をオン（iCloud Driveを使うなら必要）
3. 「Macストレージを最適化」をオンにする ✅

これで、macOSが自動的に不要なiCloudキャッシュを整理してくれるようになります。

「セーフモードで削除→再インストールしても再発する」ようなケースでも、

この設定をオンにしておくことで再肥大を防げます。

⏱️ 効果が現れるまで少し時間がかかる理由

「Macストレージを最適化」をオンにしても、すぐに容量が減るわけではありません。

バックグラウンドで cloudd や bird といったプロセスが、古いキャッシュを安全に削除していくため、数時間〜数日かけて段階的に空き容量が回復 します。

🧭 まとめ

• 「Macストレージを最適化」＝ 不要なiCloudキャッシュを削除してローカルを軽く保つ機能
• オフにすると iCloud 全データをローカルに保持 → 「システムデータ」爆増
• macOS の説明文は少し紛らわしいが、オンが正解

とりあえず１週間くらいは様子をみたいと思います。

Macのストレージを確認したら「システムデータ」が数百GBに膨れ上がっている──そんな経験ありませんか？
今回は実際に私のMacBook Pro（M1 Pro, macOS Sonoma）で「システムデータが増え続ける」現象に対して、セーフモードで解決しようとした一連の手順を共有します。

⚠️ 注意：この記事は筆者の自己検証ログです。
システム領域を直接操作するため、実行にはリスクがあります。
失敗して「Macが起動しなくなった」などのトラブルになっても筆者は責任を負いません。
興味のある方は自己責任でどうぞ。

追記：2025/11/11

２日くらいで元に戻ってしまいました。やはり、iCloudドライブのキャッシュ増加です。この問題は長引きそうです。仕事になりません。。。

症状：ストレージの「システムデータ」が増え続ける

仕事中、なんだかアプリの動作が変になって来て、おかしいなあと思い調べてみたところ、以下の状況になっていました。

• Macの「ストレージ」表示で「システムデータ」が数百GB以上存在
• 空き容量がほとんど無い状態まで圧迫
• キャッシュ削除や再起動をしても効果は一時的
• iCloudドライブをオフにすると、キャッシュ領域は削除される
• iCloudドライブをオンにすると、時間とともに徐々に増加する
• iCloudドライブは同期のみ。最適化はオンにしていない

ひどい状況です。残り1Gくらい。それでも動作するmacOS。

Appleサポートに電話

どうしようも無いので、Appleサポートに問い合わせました。

リモートから確認してもらいましたが、iCloudキャッシュの削除を案内されました。

既に事象の切り分けは出来ており、iCloudキャッシュを削除しても増加を続ける状況であることは分かっていたので、Appleサポートの手順はもちろん意味はありませんでした。

どうも自分の伝え方が悪かったようです。

調査：どの領域が肥大化しているのかを特定する

仕方ないので、自分で進めることにします。まずはどの領域が増えているのかを確認しました。

sudo du -hxd1 /System/Volumes/Data | sort -h

結果例：

111G	/System/Volumes/Data/.DocumentRevisions-V100
310G	/System/Volumes/Data/Users
 29G	/System/Volumes/Data/Library
 ...
516G	/System/Volumes/Data

/System/Volumes/Data/.DocumentRevisions-V100 が 111 GB に肥大していました。通常このフォルダは数MB〜数百MB程度のようです。

📦 .DocumentRevisions-V100とは？

macOS の 自動保存・バージョン管理機能 が使う隠しフォルダで、アプリが「過去のバージョン」を保持するようです。

長年使っていると、古いバージョンがゴミのように溜まり数百GBに膨張することも。しかも通常モードではプロセスがロックしており、削除してもすぐには解放されません。

解決：セーフモードでキャッシュと履歴を安全に削除

通常モードではいろいろ無理があるのかなと思い、セーフモードで起動しました。

セーフモードへの入れ方はIntem MacとシリコンMacで異なるので調べてください。

自分のmacbookはM1 Proですが、shiftを押しながら電源を押す。が正解でした。

1. Macをセーフモードで起動
   1. まずシャットダウンで電源を切ります。
   2. 電源ボタンを長押し → 「オプション」画面で「Shiftキーを押しながら起動」
2. 不要キャッシュを削除

   rm -rf ~/Library/Caches/*
   rm -rf /Library/Caches/*
   rm -rf ~/Library/Application\ Support/CloudDocs/*
   

3. Spotlightインデックスを停止

   sudo mdutil -a -i off
   sudo rm -rf /.Spotlight-V100
   

4. .DocumentRevisions-V100 を削除

   sudo rm -rf /System/Volumes/Data/.DocumentRevisions-V100
   

5. 再起動（通常モード）
   macOSが自動で新しい .DocumentRevisions-V100 を生成します。
6. Spotlightインデックスを再構築

   sudo mdutil -a -i on
   

結果：容量が回復

Spotlight再構築後、ストレージ表示も正確になり、システムデータ肥大化が完全に解消されました。しばらく放置しても増え続ける状況になっていません。

まとめ

「システムデータが増え続ける」現象として、.DocumentRevisions-V100 の肥大化とSpotlight／スナップショットの整合性崩れの可能性を疑い対処を行いました。
まずはセーフモードで起動し、キャッシュなどを削除後、.DocumentRevisions-V100への対処という方法が効果がありそうです。