サイト運営の収益化 検討編

サイト運営について基本的な方針(気になったことを書いていく)の変更はありませんが、 サイトに広告を配置して収益を得る検討をしてみようと思います。 記事については 何か依頼があり面白そうなら書いてみるという程度のスタイルは変えないので、いいことを書いてもらおうと依頼されても製品自体がいまいちならご期待の内容にならないのでその点はよろしくお願いします。 今回の検討は、記事の上下左右に自動で埋め込まれる広告です。 20年くらい前に試行して、月当たり千円程度の収益が上がっていた時期もありますが、サーバシステム更改のタイミングで、広告掲載をやめていました。
 最近はいろいろな広告埋め込みサービスが提供されています。今回は、以前利用していたサービスから変更し、利用数が多そうな「Google AdSense」を試してみます。

収益の推定

手間もいろいろかかるので、その程度の収益になるかを推定してみます。

  • 5年間のトップページアクセス数から推定した結果は次の通り。
    169~254円/月 GPT4予測
    150~400円/月 Grok4予測
  • サーバ統計でのページビュー数より推定
    280~3353円/月 GPT4予測
    850~2550円/月 Grok4予測

かなり幅はあります。
サーバーやドメインの運用費用を賄えるかどうかは微妙な線ですが、少しは回収できそうです。

MIC-NETの推定は置いておいて、他のサイトはどうなのか見てみました。

例1:新潟県

新潟県は自治体で初めてGoogle AdSenseを導入した事例として知られていますが、現在は固定型・変動型のバナー広告をトップページなどで掲載し、財源確保を図っています。

広告導入基本方針: https://www.pref.niigata.lg.jp/sec/ict/1228420866024.html

トップページ(広告表示例): https://www.pref.niigata.lg.jp/

例2: 姫路市(兵庫県)

例3: 岸和田市(大阪府)

  • 公式ウェブサイトにバナー広告を募集し、財政収入の確保と地域産業振興を図っています。月平均アクセス数に基づく掲載。
  • URL: https://www.city.kishiwada.lg.jp/page/3-banner-ad.html

例4: 名古屋市(愛知県)

  • 公式ウェブサイトのトップページおよびサブトップページにバナー広告を募集・掲載。
  • URL: https://www.city.nagoya.jp/shicho/page/0000089829.html

例5: 札幌市(北海道)

  • 公式ホームページにバナー広告とテキスト広告を掲載。サイズ拡大により視認性を高めています。
  • URL: https://www.city.sapporo.jp/city/ad/boshu/index.html

例6: 栃木県

  • ホームページに10枠のバナー広告を募集・掲載。
  • URL: https://www.pref.tochigi.lg.jp/c05/kensei/kouhou/hp/banner.html

これらの事例は、自治体の財政難対策として増加傾向にあり、広告掲載により月数万円から数十万円の収入を得ているケースが多いです。AdSenseに特化した最近の事例は少ないですが、上記のバナー広告が主流です。詳細は各URLで確認してください。

まとめ

その他、企業のサイトについていくつかのサイトについてみてみましたが、広告自体をサイト運営団体が直接受け付け掲載しているケースがほとんどで、AdSenseなどに広告掲載を外部丸投げしているところはほとんどなさそうです。 
 まず、AdSenseを使って広告掲載を試します。 MIC-NETでも、直接受け付ける方法も検討していきます。 ただし、製品サービスを検証したうえで掲載いたします。お勧めできない製品やサービスについては掲載をお断りすることもありますのでよろしくお願いします。

25年ほど前に、mic.or.jpで一時期広告を掲載していました。当時は数千円/月程度の収益で、サイト運営のささやかな支えになっていました。しかし、システム更新のタイミングでユーザー体験を優先し、広告を外してしまいました。最近、サイトの成長とともに「持続可能性」を再考する機会が増え、再び収益化を検討中です。この記事では、私の経験を基に、医療情報学サイトの収益化を「検討編」としてまとめます。広告掲載後には実践結果も公開予定です。


参考

1. サイトの現状と再検討のきっかけ

mic.or.jpは、コンピュータサイエンスやツール紹介を中心にさまざまな気になる事柄の記事を公開・運営してきました。立ち上げから約15年、月間PVは数千〜1万程度で安定していますが、執筆の手間とサーバー維持費の負担が徐々に重くのしかかっています。

これらを踏まえ、収益化を「補助輪」として位置づけ、サイトの質を損なわない形を探ります。医療関連サイトゆえ、広告の選定は特に慎重に—信頼性を守りつつ、運営を楽しく継続したいところです。

2. 収益化のメリット・デメリット分析

収益化の第一歩は、冷静な分析です。私の過去経験と、類似サイトの事例(例: 学術ブログのAdSense導入報告)から、以下のようにまとめます。

メリット:

  • 経済的安定: 数千円からスタートし、PV増加で月1万円超も現実的。サーバー費やドメイン更新をカバー可能。
  • モチベーション向上: 収益が見える化され、執筆意欲が持続。読者も「価値あるコンテンツ」として認識。→役に立つ情報公開を中心に据えますが、収益目的重視のコンテンツにはしない方針

デメリット:

  • ユーザー離脱リスク: 広告過多で「商業的」と見なされ、信頼低下。
  • 初期労力: 申請・最適化で1-2週間かかる。収益ゼロの「沈黙期間」も覚悟。

収益化検討編の記事公開による影響の推測

以下はGrokによる推測情報:
「サイト運営の収益化 検討編」というトピックを公開した場合の収益影響を推測します。私の分析は、Web検索や関連事例(ブログ運営者の収益報告公開の議論など)に基づいています。結論から言うと、公開した方が収益は上がる可能性が高いと推測しますが、条件付きで多少のリスクもあります。以下で詳しく説明します。

1. 全体的な影響のメカニズム

  • トラフィック増加の効果(プラス要因):
    収益化関連の記事は、サイト運営者や初心者ブロガーの間で人気の検索キーワード(例: 「ブログ収益化 方法」「広告掲載 準備」)にヒットしやすいです。公開すれば、Google検索経由の訪問者が増え、PV(ページビュー)が向上します。広告収益(Google AdSenseやアフィリエイト)の多くはPVやクリック率に依存するので、直接的に収益アップにつながります。
    実際の事例として、ブログ運営者が収益化Tipsを公開した結果、月間PVが数倍に跳ね上がり、収益が10万円以上増加した報告が複数あります。 また、アクセス数と収益の相関が強いサイトでは、こうした「メタ記事」(運営Tips)が新規読者を呼び込みやすいです。
  • 信頼性とエンゲージメントの向上(プラス要因):
    専門性が高い読者層(研究者)が「実践的な運営ノウハウ」として信頼し、滞在時間やシェアが増えます。これが間接的に広告クリック率を押し上げます。ブログ収益化のガイド記事を公開した運営者が、読者からの相談やリピート訪問で収益を安定させたケースも見られます。
  • デメリットの可能性(マイナス要因):
    収益化の「検討編」を詳細に公開すると、競合サイトが増えたり、自分の戦略が模倣されるリスクがあります。特に収益報告(数字の公開)を伴う場合、モチベーション低下や税務・プライバシーのトラブルを招くデメリットが指摘されています。 ただし、クエリの「検討編」は具体的な数字公開を避け、戦略の概要に留めれば、このリスクは低いです。

2. 収益変動のシナリオ推測(テーブルで比較)

以下は、公開した場合の収益影響を、短期・長期で推測したものです。前提として、広告準備中なので初期PVは低めと仮定(月間1,000〜5,000PV程度)。

シナリオ短期影響(1〜3ヶ月)長期影響(6ヶ月以上)収益変動推測理由
公開する+10〜30%+20〜50%上がる新規検索流入でPV増。Tips記事自体が広告表示機会を生む。事例: 収益化記事公開で月10万円達成。
公開しない±0%±0%変わらない既存コンテンツ頼みで成長停滞。競合に後れを取る可能性。
公開+数字非公開+15〜40%+30%以上大きく上がるリスク低減しつつ信頼獲得。メンテナンス次第で安定。
  • 上がる確率が高い理由: ブログ/サイト運営の80%以上の事例で、収益化Tips公開がPVを押し上げ、結果として広告収益を増加させています。 特に準備中の広告掲載後([広告掲載後公開]と指定)なら、記事内で広告を自然に紹介でき、コンバージョンも期待できます。
  • 下がる可能性は低い: 炎上リスク(例: 誤情報)がない限り、収益減少は稀。むしろ非公開の方が機会損失になります。

3. 公開時のTips(収益最大化のために)

  • 記事構成: 導入部で自身のサイト(mic.or.jp)の事例を軽く触れ、読者の共感を呼ぶ。SEO対策(キーワード: 「医療サイト 収益化」「広告準備 方法」)を入れて検索上位狙い。
  • 注意点: 数字(収益額)は伏せて「検討編」に留め、デメリット記事のようにトラブル避け。 公開後、Google AnalyticsでPV/クリック率を追跡し、調整を。
  • 追加推奨: X(Twitter)で記事をシェアすると、さらなる流入が見込めます。関連議論では、超特化記事が収益安定に効くとあります。

全体として、公開をおすすめします。収益化準備中のタイミングでこうした記事は「フック」になりやすく、サイトの成長を加速させるはずです。何か具体的な原稿ドラフトが必要なら、追加で相談してください!


以上が、Grokによる分析結果でした。 実際のところはどうなんでしょうか。
表示崩れなど、広告表示に伴う問題があれば、コメントをお願いします。

どう見ても詐欺メール、どう自動破棄処理するのが良い?

スパムメールと、誤判定してしまうケースがあるが、これらのメールは自動処理してみまってもよいだろう、グレーケースとあきらかな詐欺メールは分類して処理するのが良いかもしれない。

以下明らかな、詐欺メールのサンプル


組織犯罪対策部:あなたはマネーロンダリングの疑いがあります。保釈金として150万を下記の口座にお振り込みください。捜査終了後、保釈金は返金されます。2025年10月31日までに送金しない場合は資産は凍結され、あなたは逮捕されます。

三菱UFJ銀行 (金融機関コード0005)
恵比寿支店(支店コード136)
普通 2041699
名義 TS 合同会社
ティーエスゴウドウガイシャ

〒100-8974 東京都千代田区霞が関2丁目1番2号
電話番号 03-3581-0141(代表)


X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <iwashita_manami@e-nepia.com>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on **.xserver.jp
X-Spam-Flag: YES
X-Spam-Level: **************************************************
X-Spam-Status: Yes, score=52.2 required=30.0 tests=CMCL_1,FSL_HELO_NON_FQDN_1,
HELO_NO_DOMAIN,RDNS_NONE,SPF_SOFTFAIL,TVD_SPACE_RATIO_MINFP autolearn=no
autolearn_force=no version=3.4.0
X-Spam-Report:
* 0.0 FSL_HELO_NON_FQDN_1 No description available.
* 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
* 50 CMCL_1 Cloudmark Authority detected spam
* 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
* 0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly
* 0.0 TVD_SPACE_RATIO_MINFP Space ratio (vertical text obfuscation?)
X-Spam-CMAuthority: v=2.4 cv=UZQDS7SN c=1 sm=1 tr=0 ts=69025ac7
p=feqnlMpVuKP_xuHrwg4A:9 a=0FI5FzLfUpbmheKzllYW6Q==:17 a=IkcTkHD0fZMA:10
a=x6icFKpwvdMA:10 a=5KLPUuaC_9wA:10 a=M51BFTxLslgA:10 a=QEXdDO2ut3YA:10
a=Mfv3uX3kbRkA:10
Delivered-To: ***@***.or.jp
X-Virus-Status: scanned (With Secure/Atlant/virusgw12107.xserver.jp/)
Received: from qjbgdilxanftbstfbmypojfne (unknown [116.208.97.48])
by ***.xserver.jp (Postfix) with ESMTPS id 08D85280D824FF
for <**@**.or.jp>; Thu, 30 Oct 2025 03:19:47 +0900 (JST)
Authentication-Results: ****.xserver.jp;
dkim=none;
spf=softfail (****.xserver.jp: 116.208.97.48 is neither permitted nor denied by domain of iwashita_manami@e-nepia.com) smtp.mailfrom=iwashita_manami@e-nepia.com;
dmarc=fail reason="No valid SPF, No valid DKIM" header.from=e-nepia.com (policy=none)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=***.or.jp;
s=default; t=1761761990;
h=from:from:sender:reply-to:subject:subject:date:date:
message-id:message-id:to:to:cc:mime-version:mime-version:
content-type:content-type:
content-transfer-encoding:content-transfer-encoding:in-reply-to:
references; bh=nTl06k+7cmfY6AQy1kTdVmH5deI5cl/IWBO0FE/8tIQ=;
b=Pi5TvKEgEfIRkjKLRatfN1kP2V2M9Ms3PoWWJR1c7us+sedef+I2DW7chT6mpT1j70MyCf
2o0rm8LslrqWEiIh4SPYRxnGRmQGCBroCZGDrfcuKFVD/NgzY4VfP3tanz8+b51aqliKZj
k9pIZTAabz38tBmH3epRH3FeBIWSwCBZf0bZT5bobJTvbDOCJvQmoz/6xLn6udxZslvssz
ox3rVC6lm1Bqd866eLHO2xjvJlcMpO1xbPjljbfODOYD/hk05PW77VMd6XdvzMonlIoAtG
moZuB7iFmlAkYUUs8aRSkMGZFU7dLwXQQlEzO0vtY0hWJIG4DaxAe1ghSYnX7Q==
ARC-Authentication-Results: i=1;
****.xserver.jp;
dkim=none;
spf=softfail (***.xserver.jp: 116.208.97.48 is neither permitted nor denied by domain of iwashita_manami@e-nepia.com) smtp.mailfrom=iwashita_manami@e-nepia.com;
dmarc=fail reason="No valid SPF, No valid DKIM" header.from=e-nepia.com (policy=none)
ARC-Seal: i=1; s=default; d=***.or.jp; t=1761761990; a=rsa-sha256;
cv=none;
b=kalrckxcno2eldITQxlaTxFC6yejHUAK+XC67U4VQbiG3lW4PVTcwhFm8z8s2FCeY62OQl
kYLJ5PTfGn2Z4fSQ+e3qbffTS0kQeC/SeaodSy2Ux29l3VALyDV/hLDtyPbZTtP5eDihGU
sYAUuKppEhdOc2W9EeinimPhS9h/OVclQlPSHB9VQo8jzwbzwuMSU5KfoyA1uO0wrq2SYM
a6Zu2XwgsBjozu9qbVknRsYNBpl5hPykoPBG+SxPAUZ3levk6JBHHeDRhgmxQDPTC5P+Pk
+0yoBkcZ3uu02XGhAEHu4NSUu3Jokw5X922s7f0ufukr+18u16go8BgQSdVsEg==
Message-ID: <lrrhz5s26p.s54pk7.5710.8frl-545754632@qjbgdilxanftbstfbmypojfne>
From: =?utf-8?B?6K2m5a+f5Y6F?= <iwashita_manami@e-nepia.com>
To: =?utf-8?B?U2FtIEVsaXNhYmV0?= <***@**.or.jp>
Subject: [SPAM] =?utf-8?B?6YeN6KaB44Gq44GK55+l44KJ44Gb?=
Date: Wed, 29 Oct 2025 19:19:42 +0100
X-Priority: 3
X-Mailer: LTPGGSAOIBADJ WTSQNJGDOCNBQPA 880.24276.55564
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
XSRV-Filter: ***@**.or.jp
X-Spam-Prev-Subject: =?utf-8?B?6YeN6KaB44Gq44GK55+l44KJ44Gb?=
XSRV-Filter: .Junk

57WE57mU54qv572q5a++562W6YOo77ya44GC44Gq44Gf44Gv44Oe44ON44O844Ot44Oz44OA44Oq
44Oz44Kw44Gu55aR44GE44GM44GC44KK44G+44GZ44CC5L+d6YeI6YeR44Go44GX44GmMTUw5LiH
44KS5LiL6KiY44Gu5Y+j5bqn44Gr44GK5oyv44KK6L6844G/44GP44Gg44GV44GE44CC5o2c5p+7
57WC5LqG5b6M44CB5L+d6YeI6YeR44Gv6L+U6YeR44GV44KM44G+44GZ44CCMjAyNeW5tDEw5pyI
MzHml6Xjgb7jgafjgavpgIHph5HjgZfjgarjgYTloLTlkIjjga/os4fnlKPjga/lh43ntZDjgZXj
gozjgIHjgYLjgarjgZ/jga/pgK7mjZXjgZXjgozjgb7jgZnjgIINCg0K5LiJ6I+xVUZK6YqA6KGM
IO+8iOmHkeiejeapn+mWouOCs+ODvOODiTAwMDUpDQrmgbXmr5Tlr7/mlK/lupco5pSv5bqX44Kz
44O844OJMTM2KQ0K5pmu6YCaIDIwNDE2OTkNCuWQjee+qSAgVFMg5ZCI5ZCM5Lya56S+DQogIOOD
huOCo+ODvOOCqOOCueOCtOOCpuODieOCpuOCrOOCpOOCt+ODow0KDQrjgJIxMDAtODk3NCDmnbHk
uqzpg73ljYPku6PnlLDljLrpnJ7jgYzplqIy5LiB55uuMeeVqjLlj7cNCumbu+ipseeVquWPt+OA
gDAzLTM1ODEtMDE0Me+8iOS7o+ihqO+8iQ==


マイナポイント再手続きのご案内





*** 様


マイナポイント第2弾の登録情報に不備があったため、ポイント付与が行えませんでした。
以下より内容を確認し、再手続きをお願いいたします。


期限:2025年11月01日(土)



手続きに進む



総務省

最近増えている謎メール dmarc25? 実質スパム → 破棄に設定変更

最近、まとめて何通も送られてくる謎メールを解析してみた。 サンプルのメッセージソースは下に張り付けました。

GPTの解析結果はつぎ。

とても良い観察です。
この2通目(noreply-dmarc-support@google.com からのもの)は、
先ほどの「dmarc25.jp」メールとはまったく性質が異なります


✅ 結論から言うと

こちらは本物のGoogleから送信されたDMARC集計レポートメールです。
偽装スパムではありません。安全です。
ただし、開封や解析は不要で、そのまま削除して問題ありません。


🔍 技術解析(要点)

項目評価
Return-Path<noreply-dmarc-support@google.com>Google公式ドメイン
送信サーバーmail-qv1-f73.google.com [209.85.219.73]正規のGoogleメールサーバー
SPFpassGoogleのサーバーが正しく認証
DKIMpass (header.d=google.com)Google公式署名あり
DMARCpass (policy=reject)Googleのポリシーが適用済み
件名/本文構成DMARCレポート(XML添付)形式DMARC集計通知として正常
スパムスコアscore=-13.5(極めて低い)SpamAssassinが「安全」と判定

📄 どういうメールか?

あなたのドメインを名乗るメールが世界中でどう扱われたかを、
Gmailが自動でまとめて送信してくれる「DMARC Aggregate Report(集計レポート)」です。

送信元:
noreply-dmarc-support@google.com

添付ファイル名は通常:

google.com!***.***!<日付範囲>!<識別ID>.xml.gz

中には XML 形式で次のようなデータが入っています:

<feedback>
  <report_metadata>
    <org_name>Google Inc.</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>...</report_id>
  </report_metadata>
  <policy_published>
    <domain>***.***</domain>
    <p>none</p>
  </policy_published>
  ...
</feedback>

🚫 「dmarc25.jp」との違い

比較項目Google(今回)dmarc25.jp(前回)
ドメインgoogle.comdmarc25.jp(偽装)
送信元IP209.85.xxx(Google公式)59.106.xxx(GMO共用)
DKIM署名header.d=google.comheader.d=dmarc25.jp
SPF結果passpass(だが独自ドメイン)
内容正規のDMARCレポートDMARCレポート風スパム
対応放置・削除OK受信拒否推奨

💡 今後のおすすめ運用

もしあなたのドメインで
DMARCを設定済みであれば、世界中の主要メールサーバー(Google、Microsoft、Yahoo!など)が
定期的にレポート(XML.gz)を送ってきます。

これらは通常:

  • 安全(ただし開かなくてよい)
  • 内容は認証統計(なりすまし対策用)
  • 保存・放置しても問題なし

必要な場合のみ解析する

もし「自社ドメインのなりすまし状況を把握したい」場合、
以下のような無料ツールでレポートをまとめて可視化できます:


✳️ まとめ

種類ドメイン正体対応
@google.comGoogle正規サーバー正規DMARCレポート放置・削除OK
@dmarc25.jp偽装(docomo風)DMARCレポート風スパム受信拒否・開封禁止

以下は「偽DMARCレポート」と「正規レポート」の処置方法案


処置方針まとめ

レポート種別特徴推奨処置コメント
偽DMARCレポート差出人偽装、怪しい添付・リンクの可能性拒否 or 破棄SPF/DKIM fail、差出元不明なIPが多い場合は偽と判断可
正規DMARCレポート正規送信サーバーから、XML形式で集計破棄(中身を見ない場合)受信が煩雑な場合は破棄でOK
正規DMARCレポート正規送信サーバーから解析(中身を見る場合)偽装メール検出、送信経路確認、DMARC強化判断、監査目的で利用可能

正規レポートを解析するケース

自ドメインの偽装・スプーフィングの有無確認
  • 外部IPから SPF/DKIM fail があれば偽装メールあり
  • 対応策:SPF/DKIM/DMARC強化、受信者への注意喚起
メール送信経路の確認
  • 自社送信サーバーの SPF/DKIM/MX 設定が正しいか確認
DMARCポリシー強化の判断材料
  • p=nonep=quarantinep=reject の段階的運用
  • p=reject で偽装メールは受信者サーバーで自動的に破棄される
セキュリティ監査・リスク管理
  • 偽装メールの監視、ドメイン悪用の傾向把握

運用上の具体例

  • 偽DMARCレポート:メールサーバーで「SPF/DKIM fail」「差出元不明IP」の場合、自動破棄
  • 正規DMARCレポート:受信は継続
  • 中身を見ない場合:迷惑メール振り分けで破棄
  • 中身を解析する場合:XMLを専用ツール(dmarcianなど)に取り込み、送信状況を監視

まったく別観点からの対処案

このメールは、DMARCレポートは 送信されるメール自体ではなく、受信側サーバーが作成する通知 です。よって 通常の個人宛メールのように偶然届くものではなく、ドメイン管理者宛に体系的に届くもの です。もしレポートを受け取りたくない場合は、DMARC TXTレコードから rua / ruf を削除する(rua/rufフィールドを空にする)ことで送信先をなくせます。

⇒当ドメインでは、 ”DMARCポリシー設定は不正「メールを配送しない」”、 ”通知を停止”、に設定変更しました。 まずはこれで、検証してみます。


dmarc25 からのほぼスパム

X-Mozilla-Status: 0001
X-Mozilla-Status2: 10000000
X-Mozilla-Keys:
Return-Path: <docomoreport-bounceback@dmarc25.jp>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ***
****.xserver.jp
X-Spam-Level:
X-Spam-Status: No, score=0.9 required=30.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,SPF_HELO_NONE,SPF_PASS,TVD_SPACE_RATIO,URIBL_BLOCKED,
URIBL_DBL_BLOCKED_OPENDNS,URIBL_ZEN_BLOCKED_OPENDNS,X_NONJAPANESE_SUBJECT
autolearn=no autolearn_force=no version=3.4.0
X-Spam-CMAuthority: v=2.4 cv=UZQDS7SN c=1 sm=1 tr=0 ts=6901a979
a=4nyRffA/pZpJxf3jz/ccCw==:17 a=x6icFKpwvdMA:10 a=z2Y1GidkDKYA:10
a=tclcd6dtLQvEqt9_mmAA:9 a=CjuIK1q_8ugA:10 a=4Hp3Za8rNZdGw2VEeB8A:9
a=49ladYHvHUoA:10
Delivered-To: **@****.or.jp
X-Virus-Status: scanned (With Secure/Atlant/virusgw12107.xserver.jp/)
Received: from mta01d.dmarc25.jp (mta01d.dmarc25.jp [59.106.216.209])
by ***.xserver.jp (Postfix) with ESMTPS id 457AD281968215
for <**@***.or.jp>; Wed, 29 Oct 2025 14:43:21 +0900 (JST)
Authentication-Results: ****.xserver.jp;
dkim=pass header.d=dmarc25.jp header.s=mta202206r header.b=goEzNkAQ;
spf=pass (***.xserver.jp: domain of docomoreport-bounceback@dmarc25.jp designates 59.106.216.209 as permitted sender) smtp.mailfrom=docomoreport-bounceback@dmarc25.jp;
dmarc=pass (policy=reject) header.from=dmarc25.jp
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=****.or.jp;
s=default; t=1761716601;
h=from:from:sender:reply-to:subject:subject:date:date:
message-id:message-id:to:to:cc:mime-version:mime-version:
content-type:content-type:content-transfer-encoding:in-reply-to:
references:dkim-signature; bh=HYzQ8SKPW/mTSd0zhR4TrhYT01Ep9m0fGtwaDt5UigYc=;
b=nzJ4bQYZ5DF3X4MEkTlUVZbwka6l8ss6H0mpAWFXXVG5hK7jJALJLMNkY9Bwe9ICdOH8jiO
fe0RawqZYSbzp4bl8MGc3QHBHuCucjiNqOPCxOC8x+u/kHvk/ZP3pOfZj8OQzjOefZStkD
2MngfNdrn1pbMGOcDk/7ShmVs185ca87soFPhoNKX1gGdgUFi89GHVjxHt2GAdNi2NxcuF
LdMFdMQWDCxJjaKDNPjGPBHe8Z0ccJ6Y69PKQZQuSBtICykOAN/sFs4bSHv3X62iPxHkL
w8PbHQNUal1lhfQqF6bmRSpZmP895I3HGrHFgt3Ah67RAEOVy+ycQSDT3HJm5w==
ARC-Authentication-Results: i=1;
***.xserver.jp;
dkim=pass header.d=dmarc25.jp header.s=mta202206r header.b=goEzNkAQ;
spf=pass (***.xserver.jp: domain of docomoreport-bounceback@dmarc25.jp designates 59.106.216.209 as permitted sender) smtp.mailfrom=docomoreport-bounceback@dmarc25.jp;
dmarc=pass (policy=reject) header.from=dmarc25.jp
ARC-Seal: i=1; s=default; d=**.or.jp; t=1761716601; a=rsa-sha256;
cv=none;
b=KHep4fsgpeT1mhiFdziq/LgRb39yMdlYqoIuK8evM2vbafKp4rVAVO2P9Ey81khMzF/Z4r
crd7YKwrIlvBUyp1XRE6nB76hDQCRbDgNOsZ1+KBNM85SN5PUMA+9qeTAJwx8wd9Sa43sQ
nv6aAssOakDL/4S2e0IsUsYb9Tur/At0oK7kaJbnQX+Yd/1wFZmkjiRfuT1YUHdrShYu8W
sOCIt15QbELfWumXp1pVbuVRBe4dXprMgan6eTe40VO7fjiI1d1pWRInuZ0WWXgWhnmhJ5
aO8L9L1Z89aGWAg13w8Txyb/BHyzZ7jTBzn9S8pgswKLm5f45xe3vy9VbNphqg==
Received: from [153.125.224.196] (unknown [172.16.0.99])
by dmarc25docomomta-01.dmarc25.jp (Postfix) with ESMTPSA id 0CB56A3808
for <***@**.or.jp>; Wed, 29 Oct 2025 14:43:21 +0900 (JST)
DKIM-Filter: OpenDKIM Filter v2.11.0 dmarc25docomomta-01.dmarc25.jp 0CB56A3808
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmarc25.jp;
s=mta202206r; t=1761716601;
bh=HYzQ8SKPW/mTSd0zhR4TrhYT1Ep9m0fGtwaDt5UigYc=;
h=Subject:From:Date:To:From;
b=goEzNkAQSdNEHFDF/aEqbsVYzSORdKoSo/d/3Lw52R7VhzSWm7Ahd/6vIs1jZLlG
QYmoT7MjAoWtqlIl9xTIJ2z4GI86LvS3uiF+GTbVn3aHTrcPLbP55UZHaLkoLilBxP
V6y5RnKXLBP8RPz56Ch0m0RFUxKoNn7EPRGrphRn7lJbyUXf1/Lwt0ADB2QKOjGva5
5gKAz2hLBB22lU8lOr7hhxvj5xyLr+x/R79IMNvOfnfkctau4xK7Ej4az7OQ5G0iyG
jseEZ7jhZkeEbVyFJBpitFgQ2fdY8Tc+MpM4Su2dNTLD+rGt272FQoL81es+ArG0+f
lAF0H6nv+XpHQ==
Content-Type: multipart/mixed; boundary="===============0657281041604779379=="
MIME-Version: 1.0
Subject: Report Domain: ***.or.jp
Submitter: docomo.ne.jp
Report-ID: <0579b07583e429af1ed1a5fe567b58c8>
From: "docomo.ne.jp by DMARC/25" <reporting@dmarc25.jp>
Date: Wed, 29 Oct 2025 05:43:21 -0000
To: ***@**.or.jp
TLS-Required: No
Message-ID:
<0579b07583e429af1ed1a5fe567b58c8.d074edf066b753a93afbc05bd4df0c91e7b0b70d.dcmdb-11@docomomta.dmarc25.jp>
X-Dmarc25-Report-Info: d074edf066b753a93afbc05bd4df0c91e7b0b70d
X-Dmarc25-BounceBack-Forward-To: docomoreport-bounceback@dmarc25.jp
XSRV-Filter: ***@**.or.jp

--===============0657281041604779379==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit


--===============0657281041604779379==
Content-Type: application/gzip
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="docomo.ne.jp!**.or.jp!1761609600!1761695999!079b07583e429af1ed1a5fe567b58c8.xml.gz"

H4sICHmpAWkC/2RvY29tby5uZS5qcCFtaWMub3IuanAhMTc2MTYwOTYwMCExNzYxNjk1OTk5ITA1
NzliMDc1ODNlNDI5YWYxZWQxYTVmZTU2N2I1OGM4LnhtbAB8Utty4yAM/ZVO3tfY6fo2o9L9Ew8G
kbA1lwLubv++smmyyWRmnxBH0tE5Anj9a5enD4zJePdyaKr68IROemXc6eWwZv1jOLxy0IhqFvKN
Q8TgY54sZqFEFhx8PE1OWOTKS2995bD6HYBdYUArzMJLH7H+UlZEeWz3qpK7kBrF67Yf57pvh2f8
eRyFblA1otXYdv3cDnIA9q8WSABOUbgTTZnxZBxv+q7p6rGra2AFAXSqwGM7jiONpDuw21b24Cn4xcjPKazzYtIZqUGoN25BFYCUJ6UO26NrHzcrXwjIFLQe+F2QuDvq6A55ByBBQJk5s0mbwsg3efp
SomH4RGlj9vp/1CLX6PEyQSi6aqmea6Ox6Eae+q+ZkD61dEcYCW4GMIPsazkfNudScEnk+nZ7yTc
4rB71fREhO+2N0/lvrtjj7xsF2kUEp829K84nFEojJOO3t4u7BYGdtch1nyeIqZ1yakM/c/CSx1P
Xuci7Ru4aLwnY5dlsuuf/gIAAP//AwCg03oZBAMAAA==

--===============0657281041604779379==--

類似の、googleからのもの。

X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <noreply-dmarc-support@google.com>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ***.xserver.jp
X-Spam-Level:
X-Spam-Status: No, score=-13.5 required=30.0 tests=DATE_IN_PAST_06_12,
DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,ENV_AND_HDR_SPF_MATCH,
SPF_HELO_NONE,SPF_PASS,TVD_SPACE_RATIO,URIBL_BLOCKED,
URIBL_DBL_BLOCKED_OPENDNS,URIBL_ZEN_BLOCKED_OPENDNS,USER_IN_DEF_DKIM_WL,
USER_IN_DEF_SPF_WL,X_NONJAPANESE_SUBJECT autolearn=no autolearn_force=no
version=3.4.0
X-Spam-CMAuthority: v=2.4 cv=UZQDS7SN c=1 sm=1 tr=0 ts=68f0d3d6
a=Fqz2ctiUAAAA:8 a=1XWaLZrsAAAA:8 a=x6icFKpwvdMA:10 a=3vObA125-ToA:10
a=flsTg8gXeVLoRtu52pQA:9 a=IKIoO-ieCDEA:10 a=wDOl-8IaFK0A:10
a=Yy2xoct6d_2ZlxTvqP-Z:22 a=2GJp8AGDeS-V4P2SbgYv:22
Delivered-To: **@***.com
X-Virus-Status: scanned (With Secure/Atlant/virusgw12107.xserver.jp/)
Received: from mail-qv1-f73.google.com (mail-qv1-f73.google.com [209.85.219.73])
by ***.xserver.jp (Postfix) with ESMTPS id F33BE2811D7AFD
for <***@***.com>; Thu, 16 Oct 2025 20:15:33 +0900 (JST)
Authentication-Results: ***.xserver.jp;
dkim=pass header.d=google.com header.s=20230601 header.b=YRAEr3n5;
spf=pass (****.xserver.jp: domain of noreply-dmarc-support@google.com designates 209.85.219.73 as permitted sender) smtp.mailfrom=noreply-dmarc-support@google.com;
dmarc=pass (policy=reject) header.from=google.com
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=**.com;
s=default; t=1760613334;
h=from:from:sender:reply-to:subject:subject:date:date:
message-id:message-id:to:to:cc:mime-version:mime-version:
content-type:content-type:
content-transfer-encoding:content-transfer-encoding:in-reply-to:
references:dkim-signature; bh=JQF0fljcxSuoRS124ENe3cCdw4WeLzoayaVg3d1sVu8=;
b=EgDtYvv5nZU2cpPezn5cfHsnBhIFJLX1csaOBAfa0LwSi3Os2Biaoxx3Mkme4kKO6qTboV
7AGSE/6wSUf/NDQSoTAyK2/2WK8d4mF628fVJ+2bfNnDvqdVoRHQKXEA+lCOEPpY+c3/Ul
bXM8diD9TT

太陽光発電の軌跡:個人導入のリアル ~運用実績から見る2025年の投資回収と総所有コスト~


太陽光発電を検討中のあなたは、きっとこんな疑問をお持ちではないでしょうか。

「投じたお金、いつ元が取れるの?」
「メンテナンスや廃棄まで考えたら、本当に得になるの?」

当サイトでは、2013年に太陽光発電を導入して以来、実際の運用データを10年以上にわたり公開してきました。
その結果、導入当初のROI(Return on Investment:投資回収期間)は、計算通り約6年で達成しました。
しかし2023年にFIT(固定価格買取制度)が終了し、売電価格が約7分の1(=15%)に低下したことで、改めてROIの意味を見つめ直す必要が生まれました。

ROIは「どの提案を選べば最短で投資を回収できるか」を測るための指標です。
一方で、TOC(Total Cost of Ownership:総所有コスト)は、初期投資だけでなく、メンテナンス費用や廃棄コストまでを含めた“本当のコスト”を示します。

当サイトの実績では、ROI上は6年で回収を達成していましたが、TOCを考慮すると実質7年。
つまり、これから導入するなら、卒FIT後の運用シナリオまで見越した試算が欠かせません。


1. 当サイトの実績が示すROI(投資回収期間)の信頼性

太陽光発電の普及は、1954年のシリコン太陽電池の発明から始まり、2012年のFIT制度導入で一気に一般家庭に広がりました。
発電コストは2010年の1Wあたり約4ドルから、2025年には0.3ドル未満にまで低下。これがROI(投資回収期間)を劇的に短縮させた要因です。
現在、世界の累積導入量は2TWを突破し、家庭用のROIは平均8年前後とされています。

当サイトの実例(2013年導入)

  • 導入内容:4.4kW+5.5kWシステム(計約10kW)
  • 初期投資:約200万円
  • 年間発電量:約8,000kWh
  • ROI:6年(FIT単価42円/kWh+自家消費分)

導入から3か月後にパワコン故障が発生しましたが、アラートメールによる早期検知で迅速に対応でき、運用体制の重要性を実感しました。

運用解析・異常検知

夜間消費電力の変動を解析し、AIによる異常検知(例:浄化槽ブロワーの故障)を実現。
30%以下の発電低下を自動通知する仕組みを構築し、メンテナンスコストを削減。
これがTOC(総所有コスト)最適化の第一歩となりました。

経年劣化と長期視点

10年後の発電量は設置当初の84〜86%。
メーカー保証(10年・81%未満で交換)内で維持できており、定期点検と早期対応の重要性を再確認。
劣化率を年0.5〜0.8%で見積もることで、ROIの延長を防ぐことができます。

故障対策とFIT終了後の変化

FIT終了後(2023年)は売電価格が42円→8円/kWhへ低下。
それでも自家消費を中心にした運用でROI約6年を維持。
ただし、TOC(運用・廃棄費用含む)を加味すれば実質7年となります。

記事URLテーマROI / TOC のポイント
2019/04/24導入実績ROI6年達成、最短提案の選択
2019/08/21経年劣化劣化0.5%/年を想定しROI延長を防ぐ
2019/11/20故障AIメンテ自動化でTOC削減

2. 現在の導入判断:ROIとTOCを自宅で試算する

2025年の家庭用太陽光は、ROI8〜10年が標準。
補助金(最大36万円/kW)により、設置費用は4kWで約120万円まで低下。
FIT単価は16円/kWh、自家消費率70%を想定すれば、投資回収の現実味が見えてきます。

シミュレーション例(4kW家庭)

項目内容
初期投資120万円(補助後)
年間発電量約4,500kWh
自家消費(70%)3,150kWh × 31円 = 約9.8万円節約
売電(30%)1,350kWh × 16円 = 約2.2万円収入
年間合計利益約12万円
ROI約10年(=120万 ÷ 12万)

TOCを考慮すると、メンテ25万円+廃棄15万円で総追加40万円。
25年間での累積利益300万円に対して、ネット利益は約260万円。
実質ROIは約11年となります。

卒FIT後(2035年以降)は売電価格が8円に下がるため、年利益は約9.8万円へ。
ただしV2H(EV充電併用)を導入すれば、エネルギーロスが減りROIを10年程度に短縮可能です。

シナリオ初期費用年利益ROI(年)TOC追加実質ROI(年)
当サイト(2013年)200万円33万円640万円7
2025年(FIT中)120万円12万円1040万円11
卒FIT後(V2Hなし)120万円9.8万円1240万円13
卒FIT後(V2Hあり)120万円11.8万円1040万円11

ポイント:ROIは「早い回収」、TOCは「持続可能な回収」。
どちらも考慮してこそ、真にお得な投資判断が可能です。


3. これからの展望:ペロブスカイトと再利用でTOCを最小化

新技術「ペロブスカイト」でROI短縮へ

2025年時点で実用化が進むペロブスカイト太陽電池は、軽量・高効率(18〜30%)で注目されています。
2030年以降には住宅向けタンデム型が普及し、ROIはさらに短縮される見通しです。
導入を急がず、補助金制度を活用して技術成熟を待つのも賢明な選択です。

廃棄から再利用へ ― TOCの最大課題を克服

廃棄費用(約15万円)はTOCを押し上げる要因でしたが、2025年からはリサイクル義務化により、
メーカー負担による95%回収目標が設定されました。

TOCを抑える具体策:

  • リユース買取の活用:状態の良いパネルを無料回収する業者が登場。廃棄コストゼロでROIを1年短縮。
  • 積立制度の活用:10kW以上で廃棄積立義務化(年5,000円程度)。住宅にも推奨。
  • AI診断の導入:劣化0.5%/年を自動監視し、交換タイミングを最適化。

これらを組み合わせれば、TOCの「廃棄部分」を半減し、持続的ROIが実現します。


結論:ROIとTOCを味方につけ、賢く始める太陽光発電

当サイトの実績(ROI6年・TOC7年)は、実際に数字で回収が可能であることを示しました。
2025年の現在、補助金や技術革新によりROI10年前後が現実的なライン。
卒FIT後もV2Hや再利用によって持続的にコストを抑えられます。

ROIは「どれだけ早く投資を回収できるか」、
TOCは「どれだけ長く安心して使い続けられるか」。

この2つを理解して選ぶことが、これからの太陽光発電の“本当の価値”です。
ぜひ、経産省などのシミュレーションツールを使って、ご自宅のROIを試算してみてください。

あなたの家にも、確かな投資回収の太陽が昇りますように。
コメント欄で、あなたのROI体験もぜひ教えてください。


参考資料

  • 当サイト「太陽光発電シリーズ(2019)」
  • 経済産業省 FIT制度データ
  • IEA “Renewables 2025” / IRENA Global PV Report 2025

AI活用のカギ、コミュニケーションのカギは「言葉の統一」── AIの迷宮から、私たちの社会へ


AIとの「言葉のズレ」から見えるもの

先日、CP/M‑86(1980年代の16ビットPC向けオペレーティングシステム)をテーマに、生成AIによる「アキネータ風ゲーム」の挑戦記事が公開されました。 (mic.or.jp) この試みでは、「それは手に持てるものか?」「電子機器か?」などと質問を重ねる中で、AIは物理的な装置・電子機器を前提とした推理路線に偏り、最終的には「レトロ電卓」や「ポケットコンピューター」をイメージしてしまいました。実際の答えは、発売当時、箱売りしていたソフトウェアであるCP/M-86。質問・回答者双方の“手に持てる”かどうかの言葉の前提が揃っていなかったため、見事に堂々巡りに陥ったのです。 (mic.or.jp)
このエピソードは単なる遊び話ではなく、私たちがAIと向き合ううえで、また人と人との関係性を構築するうえで、極めて本質的な「言葉と定義のズレ」という課題を浮き彫りにしています。言葉の定義・共通認識(コモンセンス)が共有されていなければ、知能も協働も成立しえない──この視点を、あらためて本稿では考えてみたいと思います。

本質:言葉の定義が揃わないと、知能も協働も成立しない

私たちが日常的に使う「言葉」。例えば「手に持てる」「電子機器」「装置」「デバイス」「ソフトウェア」といった語は、ほとんど無意識のうちに前提を共有しているように思えます。しかし、AIへの問いかけで起きたように、前提が少しずれるだけで認識の歪みが生まれ、議論も推理も迷走してしまうのです。
AIモデルは人間のように「意味」を直感的に捉えているわけではありません。むしろ、入力に対して統計的・確率的に最も妥当と思われる応答を返す仕組みです。従って、質問・回答双方の前提が揃っていないと、「言葉の定義」が異なったまま会話(あるいは推理)が進んでしまう。結果として、思考や協働に齟齬が生まれます。

興味深いのは、この構造がAIとの間だけで起こるものではなく、私たちの組織・チーム・社会構造の中でも頻繁に発生しているという点です。言葉が曖昧、もしくは定義が人によって異なるまま使われていれば、意思疎通は困難となり、「共有できたはずの目的」がズレてしまいます。
つまり、AIとのやり取りで検出された「言葉のズレ」は、我々人間が社会的な協働をする際にも本質的に起こっているのです。

現実の3つのシーンで起こる「言葉の非統一」問題

それでは、この「言葉の定義・統一」がどのような日常のシーンで現れうるか、具体的に3つ挙げて考えてみます。

ビジネスコミュニケーション

社内で「プロジェクトを進める」「納期を守る」「仮説を立てる」といった言葉を用いた場面を想像してください。ある開発チームでは「納期=完成報告日」「完成=ユーザー検証を終えた状態」と定義されていた一方、別の部門では「完成=機能実装+内部テスト完了」という解釈だったとします。そのギャップが、表面上は「同じ言葉」を使っていても、成果や報告のタイミングで“思ったもの”が揃わなかったという状況を生みます。「プロジェクトを進める」と言った時に、A側は“仕様決定”を想定し、B側は“リリース準備”を想定していた…というズレです。
このような状況を象徴的に描いたのが、まさに旧約聖書にある バベルの塔 の物語です。人々が“言葉”で話しながらも、その意味が統一されていなかったため、建設は途中で崩壊しました。言葉の定義が一致していないと、協働の基盤そのものが揺らぐというメタファーとして、ビジネスの現場でも非常に示唆的です。

教育・学習

教師が「理解しましたか?」「この概念を暗記してください」と言ったとき、学生と教師とでは「理解」「暗記」の定義が食い違っていることがあります。教師側では「自分の言葉で説明できる状態」、学生側では「テストで点が取れる状態」を指すと捉えている、というケースが典型です。ここでも、言葉の定義がそろっていなければ教育成果は予期せぬズレを起こします。
たとえば、「演習問題を通して“理解”してください」と言っても、教師が想定する“理解”は「応用できる」ことであり、学生がイメージしている“理解”が「丸暗記できる」ことであれば、演習を終えた段階で教師は「理解できた」と評価しても、学生側は「覚えきれていない」と感じている可能性があります。つまり、コミュニケーションが通じていると思っていても、定義が異なっていればすれ違いが起こるのです。

AI開発・活用

先述のCP/M-86の事例に戻ると、AIと人間の間にある“手に持てる”“電子機器”という前提が異なったため、AIはソフトウェアであるCP/M-86を“物理的な装置”と誤認しました。(mic.or.jp) これは、AIモデルが提示された質問の「前提」を人間が想定するそれとは別のものとして受け止めていたということを意味します。
AI活用において「モデル側が何を前提としているか」「人間側が何を前提としているか」を明確にしなければ、プロンプト設計・仕様定義・実装ともにミスが発生しやすくなります。例えば、「ユーザーが“保存”したいもの」と言ったとき、モデル側では“クラウド上”を前提していて、人間側は“ローカルファイル”を想定していた…というズレが出れば、期待する出力は得られません。
このように、AIとのインタラクションもまた、言葉の解像度と定義の一致を前提としなければ、協働は成立しないのです。

どうすればよいか:共通言語を意識的に整備する

では、言葉の統一をどう進めていけば良いのでしょうか。以下に具体的なアプローチを示します。

  1. 言葉の定義を共有する文化を作る
     – プロジェクト開始時やチーム合流時、重要用語(例:納期、完成、仕様、理解)の意味を全員で確認・記録する。
     – 曖昧な言い回しを避け、具体的な定義(「納期=社外リリース日/機能完了+検証完了」など)を文書化する。
  2. 曖昧な表現を避け、概念を言語化・記録する
     – 文書や会議録には、「この言葉では〜を指す」という注釈を付ける。
     – 共有辞書・用語集をチーム内部で整備し、更新履歴も記録する。
  3. AIとのやり取りでも、定義を共通化する
     – プロンプト設計時、「ここでの“保存”とは、クラウド上の永続ストレージを指す」といった説明を加える。
     – モデルの応答が意図とずれていた場合、「この言葉では〜を意味していた」という前提を明示して再設計する。
  4. 定期的に「言葉のズレをチェック」する機会を設ける
     – チームレビューやAI活用レビューの場で、言葉の定義が変化していないかを確認。
     – 新しい概念・技術が入り込んだときには、その都度用語を再整理する。

このように、言葉の統一をただ目指すのではなく、むしろ「言葉を明文化し、共有・検証・更新するプロセス」を組織やプロジェクトに組み込むことが重要です。

このサイトの役割:共通言語の基盤づくり

このサイトでは、以下の三つの提供価値を掲げています。

  1. 読者との共通言語の整備
     – 本サイトでは、「用語辞典」ページを設け、重要なキーワードや概念を定義付きで整理します。例えば「仕様」「設計」「実装」「検証」「完成」「理解」など、コミュニケーションで曖昧になりがちな言葉を明文化します。
  2. AI活用精度の向上支援
     – 「AI活用ガイド」では、プロンプト設計時の言葉の定義(前提条件)を明示するテンプレートを提供し、AIと人間の前提ギャップを埋めるための技術的・運用的アドバイスを紹介します。
  3. ソフトウェア開発における品質・効率の向上支援
     – 開発現場では、言葉のズレが品質低下や手戻り、遅延を招きがちです。本サイトでは「用語統一から始める開発プロセス改善」のためのチェックリストやワークショップ素材を提供し、言葉の統一が成果に直結することを読者に提示します。

つまり、このサイトは「言葉をちゃんと揃えることが、知能(AI)とも、人と人とも、協働を成立させる鍵である」という考えに基づいて、用語の整備・AIとの連携・ソフトウェア開発の三軸で、実践的な支援を行っていきます。

言葉の統一こそ、未来の知能と協働の鍵

言葉を丁寧に扱うことは、実は思考と社会の基盤を整えることです。AIとの対話であれ、チーム内の協働であれ、定義のズレがある言葉を使い続ける限り、私たちは見えない迷路(AIがたどり着けなかった“堂々巡り”と同じような迷路)をさまようことになります。
今回取り上げたCP/M-86の事例は、AIとのやりとりにおける“言葉のズレ“を象徴的に提示してくれました。そして、この同じ課題が私たち人間同士のコミュニケーション構造にも根ざしているのです。
「言葉の統一」は、単なるスローガンではなく、未来の知能と協働を成立させるための実践的な基盤です。ぜひ、今この瞬間から“定義を揃える”という小さな習慣を、あなたのチーム・あなたのプロジェクトに取り入れてみてください。そこから、新たな知能と協働の地平が開けるはずです。


WordPressの推奨環境がPHP8に! 互換性エラーを防ぐためのチェックリストと実践的移行ノウハウ

最近、Webサイト構築の定番である WordPress が、推奨する PHP のバージョンを上げつつあります。これを受けて「PHP 7 から PHP 8 に切り替えよう」と検討された方も多いと思います。
ただし、安易に「バージョン切り替え=完了」ではなく、実装しているプラグインやテーマ、カスタマイズ部分によっては、PHP 8 への切り替えでエラーが出たり画面が崩れたりするケースがあります。
本記事では「私が実際に PHP 8 へアップグレードしようとしたら、実装の一部が対応しておらず調査・対策した」経験を元に、ノウハウを整理しました。たとえ実績の少ない開発でも、手順を整えておけば安心です。


1.主な作業の流れ

No.工程名主な目的・内容チェックポイント
2作業方針の確認作業範囲と進め方を明確化。対象環境や切替手順を決定。ステージング環境/バックアップの準備
3PHP7と8の差分確認主な仕様変更・互換性リスクを整理。影響範囲を洗い出す/公式移行ガイド参照
4チェック方法の確立テスト観点・確認手順を定義。どのツール・方法で検証するか決定
5チェックの実施実装・テーマ・プラグインを実際に検証。エラーログ・動作確認・機能テスト
6対処の実施問題箇所を修正・更新。プラグイン更新・コード修正・代替策検討
6最終確認全体の再確認と安定性テスト。表示・機能・ログ・速度の最終チェック

以下では、この流れに沿って各ステップを詳しく解説していきます。

2.作業方針:まず確認すべきこと

最初に、「どこを対象に、どのように切り替えるか」を決めることが非常に重要です。以下のような観点で作業方針を固めましょう。

  • 作業範囲の特定:運営中のサイト全体を対象にするか、一部(テスト環境・ステージング)から行うか。
  • 切り替え手法の確立:レンタルサーバーなどでは GUI で PHP バージョン切替が可能な場合もあります。ただし、GUI切替後も実行時のバージョンが想定と異なることがあるため、必ず確認手順を設けます。
  • リスク把握とバックアップ準備:テーマ/プラグイン/カスタムコードが PHP 8 に未対応の可能性あり。何かあったときに戻せるよう、バックアップ体制を整えておきます。
  • ステージング環境の活用:本番サイトを直接切り替えるのではなく、テスト環境で確認した上で本番移行するのが安全です。
  • スケジュールと役割分担:誰が何をいつまでに確認・対処するか明確にします。

このように「方針を整える作業」が、後工程での混乱を防ぎます。


3.バージョン差分の理解:PHP 7 ⇒ PHP 8

PHP 8 へ切り替える前に、PHP 7 と PHP 8 の違いを把握することが不可欠です。主な変更点を整理します。

3-1. 新機能/言語仕様の改善

例えば以下のような改善があります:

  • 名前付き引数(Named Arguments)やコンストラクタプロパティプロモーションなど、コード記述効率が向上。 (Liquid Web)
  • nullsafe 演算子(?->)など、ネストオブジェクトアクセスの安全性向上。 (bounteous.com)
  • ユニオン型(Union Types)など、型宣言の拡張により、より堅牢なコード設計が可能に。 (Lets Go Dev)
  • JIT(Just-In-Time コンパイラ)導入など、実行性能改善の下地あり。 (bounteous.com)

これらは “メリット” であり、将来的な保守性・性能に寄与します。

3-2. 互換性・注意すべき変更(リスク)

ただし、PHP 8 には互換性を壊す変更もあります。以下、代表的なものです:

  • 文字列と数値の比較挙動が変わっています。例えば、PHP 8 では “文字列” → 数値変換ではなく、数値 → 文字列に変換され比較されるケースがあります。 (Medium)
  • リソース型がオブジェクト型に返る関数が増え、「is_resource()」でのチェックが通らなくなる場合があります。 (Medium)
  • エラー/例外の扱いが厳しくなっています。例えば、ゼロでの除算が例外を投げるようになったり。 (Medium)
  • 多くの拡張機能や関数が非推奨または削除されています。切り替え前に公式マニュアルの “Migration” ガイドを参照すべきです。 (php.net)
  • プラグインやテーマ、それにカスタム実装が PHP 8 を想定していない可能性あり。例えば、引数の型や戻り値型、メソッドシグネチャが変わる場合があります。

このように、ただボタンを押して切り替えるだけでは “事故” が起こる可能性があります。


4.チェック/確認方法:実務的手順

では、実際にどのように確認を進めればよいか。「効率的にチェックをするための流れ」を整理します。

4-1. 確認観点の整理

事前に「チェックすべき観点」を整理しておくと作業がスムーズです。例えば:

  • 使用しているプラグイン・テーマ・ライブラリが PHP 8 に対応しているか/推奨バージョンは?
  • カスタムコード(functions.php や独自プラグイン等)が非推奨関数・構文を使っていないか?
  • データベース接続や PDO/mysqli などのドライバが新バージョンで問題ないか?
  • エラーログに “Deprecated” や “Fatal” が出ていないか?切替前に確認を。
  • GUIで切り替えた後、本当に PHP 8 で動いているか?(CLI や phpinfo() で確認)
  • ステージング環境でフロント画面・管理画面・投稿・メディアアップロード・キャッシュクリアなど主要機能が正常か?
  • 外部 API や Webhook連携、カスタムフィールド、テーマ内カスタマイズが影響を受けていないか?

4-2. 確認手順の確立

実践として以下手順を推奨します:

  1. ステージング環境を用意。現行 PHP 7 で動作確認済みの状態にしておく。
  2. バックアップ取得(ファイル・データベースとも)。
  3. GUI 等で PHP バージョンを PHP 8 に切り替え(レンタルサーバー等で可能な場合)。
  4. phpinfo() あるいは php -v(SSH 利用可なら)で切り替わっているか確認。GUIと実際のバージョンが異なるケースありです。
  5. ログを確認:エラー/警告が出ていないか、特にdeprecated・fatal。
  6. フロントエンドと管理画面を隅々まで操作:投稿作成/編集、メディアアップ、プラグイン設定、キャッシュクリア等。
  7. プラグイン・テーマを一つずつ無効化→有効化テストも有効。
  8. 必要であれば自動テスト・ユニットテスト・UIテストがあれば実行。
  9. 問題があれば該当コードを保護しつつ、本番移行日を調整。

この「チェックの実施」を丁寧にやることで、不慮のサイトダウンや画面崩れを防げます。

問題個所の抽出用シェルプログラムサンプル

以下は、sshでログインして、チェックしたいディレクトリ(サブディレクトリ含む)で、実行することで、問題個所抽出するコード(サンプル)です。環境に合わせてバージョン設定などの調整が必要です。

$>  PHP_BIN="/usr/bin/php8.1" find . -name "*.php" -type f -print0 | while IFS= read -r -d '' f; do head -c3 "$f" | grep -q $'\xEF\xBB\xBF' && { echo "BOM除去: $f"; sed -i '' '1s/^\xEF\xBB\xBF//' "$f" 2>/dev/null || sed -i '1s/^\xEF\xBB\xBF//' "$f"; }; "$PHP_BIN" -l "$f" 2>&1 | grep -v "No syntax errors" | grep . && { echo "構文エラー: $f"; echo; }; done; echo "チェック完了(PHP 8.1: $(/usr/bin/php8.1 -r 'echo PHP_VERSION;'))"
チェック完了(PHP 8.1: 8.1.32)

5.対処:問題が見つかったときの対応方針

チェックの結果、何らかの問題(エラー、崩れ、警告)が出た場合の “対応” を以下のように整理します。

5-1. プラグイン/テーマの対応

  • 利用中のプラグイン・テーマが PHP 8 非対応であれば、アップデート可能かを確認。開発者がサポートを打ち切っている場合は代替を検討。
  • テーマ・プラグインの開発版・互換版が提供されていれば、それに切替。
  • カスタマイズが多いテーマ(子テーマ含む)は、PHP 8 対応コードが含まれているか、開発元に確認。

5-2. カスタムコードの修正

  • 非推奨関数・構文を使っている場合:公式マニュアルの “Backward Incompatible Changes” を参照。 (php.net)
  • 例:文字列⇔数値比較の挙動変化、リソース → オブジェクト返却、除算ゼロの例外化など。 (Medium)
  • 型宣言や戻り値の型が厳しくなったため、関数の引数・戻り値を見直す。
  • 自動変換ツール・リファクタリング支援ツール(例:Rector)を活用するという事例もあります。 (Reddit)

5-3. 最速リカバリ手段も用意

  • 本番移行中に不具合が出そうな箇所があれば、切り戻し可能な状態(バックアップ/リカバリ手順)を確保。
  • 本番移行直後はアクセス数が少ない時間帯を選ぶのも有効。

5-4. 独自実装コードの修正

5-2.項と同じですが、ここでは実際に検出した事例を紹介しつつ、もう少し深堀してみましょう。
このページではつぎの1つだけを書きます、そのほかの詳細は別ページにまとめますので参考にしてください。

PHP 8 では、PDO::prepare() 後に execute() する前に beginTransaction() を呼び出すと、
PDOException: There is no active transaction が発生し、commit() 前に例外でスクリプトが終了 します。

この問題は4-2.項に書いた構文チェック(PHP -l *.php) の方法では検出できません。 php実行で動きが変わったことで検出はできますが、事後検出となってしまいます。エラーログでも検出できますが、例外catchして捨ててしまっていると情報が得られません。 このようなものもまとめて検出する仕掛けも用意したほうが良いでしょう。





6.最終確認と移行後のフォローアップ

移行が完了したら、以下の「最終確認」と「フォローアップ体制」を整えておきましょう。

  • フロント・管理画面ともに主要な操作をもう一度全体的に確認。
  • エラーログ・サーバーログを監視し、想定外の警告/エラーが出ていないか。
  • アクセス数の急変やページ表示速度の変化がないか、モニタリング。
  • プラグイン・テーマの更新状況を定期的にチェック。PHP 8 対応が正式にされていないものがあれば優先的に対応。
  • 将来バージョン(PHP 8.x → 8.y/9 が出た場合)にも備えた“アップグレード体制”をあらかじめ整えておく。

7.まとめ&今後の視点

  • PHP 8 には多くのメリット(性能向上、モダンな構文、型安全性向上など)があり、可能であれば早めの移行がおすすめです。 (bounteous.com)
  • ただし、「すぐに切り替え=安心」ではなく、既存実装・プラグイン・テーマ・カスタムコードが PHP 8 に対応しているかを丁寧に確認・修正する必要があります。
  • 本記事で紹介した「作業方針→差分理解→チェック手順→対処→最終確認」の流れを実践すれば、移行時のリスクを大きく下げることができます。
  • 今後、PHP 自体のバージョンアップ(例えば PHP 8.1/8.2 以降)も視野に入れ、「バージョンアップ可能な設計」「コードのモダン化(型宣言/非推奨箇所の排除)」を早めに進めておくと、将来的には“また大変”という状況を回避できます。
  • 最後に、移行後も「アクセス・表示速度・エラーログ」という観点を継続してモニタリングすることを強くお勧めします。

難解になってきた、スパム(詐欺)メールの読み解き。

以下、 いっぱい来ている詐欺メール(怪しいメール)のうち、ひとつを生成AIに判別してもらいました。
プロンプトは次のように入れました。「***」は伏字にしています。

メールの調査依頼 怪しいメールが来ました。調査をお願いします 文面は以下の通りです
--------------------------------------------
社長からの指示で発注書を送付いたします。 ご確認よろしくお願いいたします。https://***.zh-oulu.com/article/ppt

GPT4、 Grok4ともに「そのメールは 非常に高い確率でフィッシング(詐欺)メール です。」の判定です。

これのメールについては正解(True Positive)に違いないのでしょうが、問題はFalse Positive (スパムメールと誤判定してしまう)こともありました。 具体的には税務署からの物理郵送物でした。 GPT4は、 それは詐欺メールだと判定してしまいました。 税金支払わなかったたら追徴課税が来てしまいします。まるで、詐欺メールのように、恐ろしい。。。 税務署にはGPTに聞いても詐欺メールと判定されないように努力してほしい。  しかし、 どういう判定基準なのかは、税務署など正式な役所の人よりも、詐欺側のほうが研究して、改善?して攻撃してくるので恐ろしい。
 20年以上前から電子署名などの仕組みはあるが、うまく活用できていない。 証明書のお値段が年間何万円もかかるのも、広まらない理由でもあるが、もう一つは1通ごとに証明書を計算しないといけないので配信処理のCPUコストが高くなってしまうこともあるだろう。 なかなか難しい。 ただ、スパムフィルターも通り抜けている。。。
参考になるのは「https://ymg.nagoya/spam-mail-3057/」同じ攻撃を受けている人の投稿の存在。 この情報があれば、確実に詐欺と判断できますね。


以下、今回のメールのGrokの読み解き

調査結果の概要

ご提供いただいたメールの内容を調査しました。このメールは、典型的なフィッシング詐欺の特徴を強く示しており、絶対にリンクをクリックしたり、情報を入力したりしないよう強くおすすめします。以下に詳細をまとめます。

メールの特徴と危険性

  • 内容の不自然さ: 「社長からの指示で発注書を送付いたします」という文言は、ビジネスメールとして一見普通ですが、送信元が不明瞭で、具体的な会社名や詳細が欠如しています。こうした曖昧な表現は、受信者を油断させてリンクをクリックさせるための典型的な手口です。
  • リンクのURL: https://www.zh-oulu.com/article/ppt
  • このドメイン(zh-oulu.com)は、フィンランドのオウル大学(University of Oulu)と関連づけられた偽装名ですが、実際には正規の大学サイトではありません。類似ドメイン(例: web-zh-oulu.com)は、信頼性評価サイトで極めて低いスコアを付けられており、詐欺サイトの可能性が高いと判定されています。
  • ページの内容を直接確認したところ、ほとんど有用な情報がなく(「Insufficient relevant content」)、これはフィッシングサイトの典型的な兆候です。こうしたページは、アクセス後にリダイレクトやスクリプトを実行し、個人情報を盗むためのトラップを仕掛けています。
  • 特に、このURLは携帯電話番号の奪取を狙った不正サイトとして、X(旧Twitter)上で明確に警告が出されています。ページに表示されるフォームなどで番号を入力させるよう誘導する可能性が高いです。

なぜフィッシング詐欺か?

  • 類似事例の多さ: オウル大学関連のドメインを悪用したフィッシング攻撃は過去に複数報告されており、大学側もスパムやフィッシングの注意喚起を繰り返しています。 これは、信頼できる機関の名前を借りて信用を偽装する手口です。
  • 一般的なリスク: クリックすると、マルウェア感染、個人情報(電話番号、メールアドレス、パスワード)の盗用、またはさらなる詐欺メールの連鎖を引き起こす可能性があります。FTC(米連邦取引委員会)も、こうした「発注書」や「確認依頼」を装ったメールをフィッシングの典型例として警告しています。

推奨アクション

  1. リンクを無視: 絶対にクリックせず、URLをコピーしてブラウザのアドレスバーに直接貼り付けないでください。メール全体を削除するか、迷惑メールフォルダに移動。
  2. 送信元を確認: メールヘッダーをチェックし、送信元ドメインが本物の会社(例: @yourcompany.com)と一致するか確認。疑わしい場合は、直接会社に電話で問い合わせを。
  3. 報告する:
  • Gmail/Outlookなどのメールクライアントで「スパム報告」。
  • 日本国内の場合、警察のサイバー犯罪相談窓口(#9110)やIPA(情報処理推進機構)のフィッシング報告フォームへ。
  • 国際的に、PhishTank(https://phishtank.org/)にURLを登録。
  1. 予防策:
  • 2段階認証を有効化。
  • アンチウイルスソフトでメールをスキャン。
  • 疑わしいメールは常に上司やIT部門に相談。

このようなメールは増加傾向にあり、2024-2025年でも同様の事例がRedditなどで報告されています。 追加の詳細が必要でしたら、メールのヘッダー情報などを共有いただければ、さらに深掘りします。ご注意ください!


ぐるぐるnest hub その1 インターネット未接続となる問題  徹底調査で解決 

「WiFiに繋がらない」、「インターネット未接続となる」などで検索すると多数の記事が見つかり、そこには「使用デバイスの不具合」、「無線LANルーターに不具合」などの記載があり、その対処は「スマートフォンの機内モードのONとOFFを切り替える」とか「スマートフォンのネットワーク設定をリセット・再設定」とか書いている。その対処で動くようになることがあるかもしれないが、原因が特定できておらず、再発する可能性が高い。つまり解決したことにはならないことが多々あるに違いない。

  ここでは、ほかのサイトに書かれていない(稀な?)パターンの調査&解析とその解決までの記録である。 タイトルを「ぐるぐるnest 」としたが”その1”ではnestの話を書こうとしていたところ発生した別パターンのトラブルについて書く。

症状:

AndroidスマホをWiFiにつないで使用していた。ある時点までは問題なくWiFiを利用できていたが、部屋を移動して別の無線LANを使用して元の部屋に戻ってきWiFi接続を切り替えるとWiFi(無線LAN)には接続できているが「インターネット接続なし」となりネット利用できなくなる。
 同じ無線LANに接続してほかのIoT機器(Google home、SiwtchBotHubやNature Remo)はインターネットに接続できている。

 この状態で、他のサイトの記事を参考に対処するなら、Androidスマホの再起動や、WiFiオンオフの設定や無線LANの再起動だろう。 いずれの対処も効果なく症状に変化はなかった。過去には似たような症状のときに、無線LAN再起動することで復旧したことはあったが、今回はそのパターンではなさそう。
「原因特定なくして解決なし」ということで原因調査を開始した。

解析編:

まず大まかな切り分けから。
 よくあるサイトの対処手順を参考に切り分けてみる。
1. まずスマートフォンそのものが壊れていないかを確認
  他の無線LANにつないで使う分には問題なく使える
→ 「 スマートフォン そのものの故障」ではない
2.「スマートフォンの機内モードのONとOFFを切り替える
  OFFにするとつながらない。ONに戻しても「インターネット接続なし」の状態に変化はない。 →「機内モード」の問題ではない
3.「スマートフォンのwi-fiのONとOFFを切り替える
OFFにするとつながらない。ONに戻しても「インターネット接続なし」 の状態に 変化はない。 →「WiFi ON/OFF」の問題ではない
4. 「スマートフォンのネットワーク設定をリセット・再設定
 無線LANに接続できているので、スマートフォン側の設定の可能性は極めて低い。もし、設定の問題だとしてもいきなり再設定ではなく設定が妥当か確認する作業が必要だろう。 ということで、後で確認する。
5.「スマートフォンを再起動
スマートフォンが異常な状態になっているなら、これで復旧するかもしれない。
 再起動しても 「インターネット接続なし」 の状態に 変化はない。 →  一時的な異常な状態という問題ではない。

 ということで、よくあるWiFi接続問題を取り扱うサイトには書かれていない何らかの問題が発生していると推測された。

戻って、スマートフォンのネットワーク設定を詳細確認してみた。 設定詳細を開くと、スマートフォンに払いだされたIPとゲートウェイIPは目を疑うものだった。いや、これではインターネットにつながるはずがない。これで、無線LANに接続できているのにインターネットに接続できない直接的な原因は理解できた。
 なぜそうなったかの調査と根本対策は。ここから始まる。
とりあえず復旧させてみよう。”プライバシー….” という項目を長押しするとMACアドレスをランダムにするかデバイス固有のものにするか切り替えることができる。これを使ってIPアドレスをDHCPに再払い出しを要求してみる。 とりあえずIPアドレスは想定通りのものに変わりインターネット接続は復旧した。
 →これで、 「インターネット接続なし」 の直接の原因は”割り振られたIPアドレスにある”ことが確認できた。

 問題の「目を疑ったIPアドレスとゲートウェイIP」は、遠く離れた場所に最近追加した無線LANの無線LAN側のDHCP設定で指定したものだった。
 ここまでの状況を図で整理すると次のようになる。


この挙動は、かなりありえないことが起きていそうなことが理解できるだろう。ただ、事実起きているのだから、この事象発生には何か原因があるのは間違いない。こういう問題は、”ありえない”と最初から起こりそうにないことを除外してしまうと永遠に解決できなくなる。切り分け調査を一歩一歩進めるのが解決への近道である。

 さて切り分けをどうするかを考えようとしていた矢先、「インターネット接続なし」問題が再発した。 今度は、  ”プライバシー….”を使ってIP再払い出しを試みるも復旧しなかった。なおかつ、IP再払い出し要求をするたびに確かにIPが変わっている。そのIPは無線LAN③用のものだ。無線LAN③からIPが払い出されているのは間違いなさそうだ。では、どのような経路で払い出されているのだろう。WiFi接続の認証後、IP払い出し要求するときに無線LAN③からの電波を受け取っているのだとしたら、… 
 無線LAN③の電源を切ることで解決できそうだ。しかし、必要だから無線LAN3を用意したわけで、いつも電源を切っておくわけにはいかない。そこで、まず電源は切らずに無線LAN③のWAN側のケーブルを抜線してみる。

暫定対処

無線LAN③のWAN側のケーブルを抜線して 、スマホで「 IP再払い出し要求 」をすると正しいIPが払い出されて、インターネット接続に成功した。
 これで、このトラブルのメカニズムを理解できた。
ここまでの文面で分かる人は理解できたかもしれない。少し難解なところもあるので、再度整理しておこう。

トラブル原因と仕組み

仕組みは上の図の通りである。 問題は、無線LAN③のDHCP動作である。DHCPはLAN側設定であって、WAN側に流れるものではない。 無線LAN①に接続した機器は通常ブロードバンドルータが払い出したIPを利用する。これにより、IPは192.168.1.xxx、ゲートウェイIPは192.168.1.254となる。しかし問題発生時はIPが192.168.80.xxx、ゲートウェイIPが192.168.80.1となっていた。
 192.168.1.xxとなるか、192.168.80.xxとなるかは、どちらのDHCPからの応答が早いかなど運しだいという状況だったわけだ。スマホ以外のIoT機器に問題がなかったのはたまたまといってよいだろう。いつかは同じ状態に陥っていたかもしれない。また、IoT機器は設計上リトライ回数を増やすなどが我慢強い復旧策を実装しているのが効いているかもしれない。
 いずれにしても、根本原因は判明した。

根本対策

問題原因は分かり、無線LAN③のWANケーブルを抜くことで解決したが、192.168.80.x系のIoT機器が使えない状態なので、いつまでもこの状態にしとくわけにもいかない。
 
 無線LAN③の設定を見直してみる。 そもそも192.168.80.x系の通信がWAN側に漏れるのを防ぐべきで、基本的にはガードできているようだ。 だが、実際にDHCPのUDPパケットはWAN側から無線LAN③に到達して、それに対する応答をしている。 無線LAN③のWAN側パケットフィルタを見るとデフォルトで多数の設定が組み込まれているがDHCPパケットの破棄設定はなかった。

  そこで、DHCPパケットをフィルタリングすることとした。根本対策は、「ネットワーク構成変更jする際は、境界を越えてDHCPパケットが流れないように設定を確認する、また設定を行う」とする。
 ※ネットワーク機器メーカは妥当になるように製品開発を行う際は十分に検討・検証してほしい。

最後に

トラブルの対処法は、小手先の対処では再発する。根本原因を調査して根本対策しましょう。
  ちょっと、長くなりました。 タイトルの「ぐるぐるnest」は次の機会に書きます。このネタも今回と同じくらい長くなる予感がします。。。

Google home ,nestに プログラミングなしでプッシュ通知をやってみる(hsbox使用)

以前、「雨が降りだしたら自動で排水」という記事を書きました。今回は、これを拡張して、”排水”の前に、「雨が降り出しました」と音声でプッシュ通知することにトライします。もう一つポイントは”プログラミングしない”ということです。hsboxを使用し、設定だけで実現します。

※hsbox無料版がリリースされました2022/1/24追記

システム構成:
    IFTTTで 「Weather Underground」 のトリガを使用。
※このイベントの精度を向上できるほかの方法がないか後日検討

IFTTTの 「Webhooks」で、hsboxのAPIを操作。

hsboxのメニューのコマンドでスマートデバイスでの
「文字列読み上げ」を実行

  Google home や Google Nestなどのスマートスピーカー、
スマートディスプレイ、 Chromecastを備えたテレビで
音声によるプッシュ通知

ここでは、hsboxのスマートサービス連携機能クイックスタートガイドの設定が完了している前提で書きます。 つまり、すでに「メニュー ゼロ」の 発話でhsboxのトップメニューが、ChromecastをつないだテレビやGoogle Nestに表示される状態ということです。
 
前提条件はここまでです。 以下は、プッシュ通知の設定方法です。

■プッシュ通知の設定する

まず、通知するためのイベントを設定します。
以前に作成したレシピに追加します。

以前「雨が降りだしたら自動で排水」レシピを作成したときは、まだ1つのレシピに1つのサービスしか実行できず、複数実行したいときはすこし技が必要でした。
現在は、下のように「+」を押すと実行するサービスを追加できます。
  降雨イペントの作り方は、以前に作成したレシピを参照してください。

複数のスマートデバイスへのプッシュ通知は、複数サービスを書くことで実現できます。

■通知サービスの設定

Webhooksの設定でつぎのようにURLを設定します。
自ドメインはグローバルIPアドレスでも可能ですが、通常は動的にIPアドレスが変わるのでDDNSを利用して取得したドメイン名を利用してください。
ポート番号は、ルータで指定したポート番号を指定してください。ルータで家庭内LANのIP、ポートに変換する良いでしょう。変換先はhsboxのIPとポート番号を指定してください。hsboxのIPは、ルータでのIP払い出しを固定化するか、hsboxの固定IP追加機能を使用して動的に変わらないようにするとよいでしょう。hsboxのポート番号は、hsboxの仮想サーバ機能のポート番号指定で任意のポート番号を指定してください。

上記の①から③についての設定について説明します。
①hsboxのboxapiキーです。
hsboxの「スマートサービス連携」で指定したキーを設定します。
②プッシュ通知を設定したメニューの番号です。
  「雨が降りだしました」 は、デフォルトで 333番に登録されているのでこれを指定します。 メニューに任意の通知メッセージを設定できるのでそれを使うこともできます。また、動的にメッセージを変えることも可能です。
③プッシュ通知を実行するターゲットのスマートデバイスコードです。
   「スマートサービス連携」の「グループ」設定に登録したスマートデバイスのコードを設定します。 tgtは指定しない方法もあります。指定しない場合は、hsboxに設定されているカレントグループにプッシュ通知されます。

POSTで設定する場合は、上のようにBodyを設定します。 GETでURLのみで指定することも可能です。

以上で、プッシュ通知をプログラミングなしで実現できました。
他にも工夫次でいろいろできそうです。

WordPress5.4.2セキュリティ修正リリース   5.2.7も自動適用

 2020/6/10にWordPress5.4.2がリリースされた。これにはセキュリティ修正が含まれている。 修正 https://core.trac.wordpress.org/query?milestone=5.4.2&group=component&col=id&col=summary&col=milestone&col=owner&col=type&col=status&col=priority&order=priority

 このリリースにはセキュリティ修正のほかに強化も含んでいる。5.4系を使っているなら上げるほうがよいだろう。 5.2系は 5.2.7でとりあえずよいのか…。 5.2.6、5.2.7の修正内容は見えない感じです。

パッチはリリースしているのに、修正内容が分からないのはいまいちです..