ルールベースチェックでのAI利用

以下は、それぞれのページについてGPTとGrokで同じルールを使って判定した結果です。 GPT、Grokともにルールに点数をつけるルールをいれての確認で、追加で明示的に点数をつけるように指示しましたが、どちらも点数をつけるルールを理解できていませんでした。さらにGPTは、点数をつけるルールを見逃している点を指摘しても、勝手な採点ルールで点数を付けました。再度やり直して得られた結果が次です。

URLGPT採点Grok採点
https://president.jp/articles/-/10317873100
https://www.zakzak.co.jp/article/20251120-NRES442BJ5C6FMPTSOEWOPZCOU/4/77100
https://x.com/TrumpPostsJA80100
https://mic.or.jp/info/2025/11/21/web-4/– *1100

*1:GPTは該当ページを参照できず、採点できませんでした。

GPTは、厳しめの判定をする傾向があるようです。 アクセスできないケースが頻繁に発生するため、安定運用は難しいかもしれません。 厳しめに見るのは、活用シーンによっては有難いのですが、別のポリシーも厳しくアクセスができないという問題も発生してしまっています。

どう使うかは、利用者次第ですが、最初に示したように、チェックごとに結果が変わるので、作成したルールを期待通りに活用できているかを何からの方法で定期的にチェックしたほうが良いかもしれません。 チェックを行うごとにチェックの正確さが変わっていく恐れがあります。採用試験のように試験官の個人差の影響を受けないつもりでAI導入したのに、実際には同じ基準では運用できていなかったというような問題が発生しかねません。結局は、AI活用は利用者責任で利用していかなければならないのでしょう。

 しかし、自動運転での活用では誰の責任になるのか、どうなるのかこのような状況では厳しいでしょう。現状はオーナー(購入者)が責任を取る必要があるパターンがあるとされています。 問題がある場合は起動できないようにするなどの仕組みが必要でしょう。実際に購入する前に想定外の責任を背負わされないように確認しておいたほうが良いでしょう。早い段階で、このようなリスクを誰がとるかの取り決めが明確になり、利用者や購入者(お金を払う側)が責任を負わされるようなケースがなくならないと、AIバブルがはじけてしまうかもしれません。

Pythonで Webクローリング+データ解析 -「今、本当に即満室になる賃貸物件のスペック」

~Python + Grokで900件分析したら、入居者も納得の残酷な真実が見えた~

Pythonでのデータ収集・蓄積をやってみました。データ収集にはhsbox無料版を活用しています。集積したデータを解析していま求められている物件はどのようなものなのかを可視化して、ビジネスに活用しようという話です。

WebcI
Webクロール

上の図のデータ収集と分析環境は構築済みで運用に入りました。分析結果に関しては別の機会に書いてみようと思います。 ただ、地域によって傾向が異なると推測されます。分析したい地域のデータを収集して解析する必要があるので、真剣に参考にしたい方は実際にお試しください。構築方法等については支援いたします。 有名企業での分析実績がある現役プロの分析が欲しい方はお問い合わせください。データ収集から解析まで有償にて支援いたします。

Webクローリングだけでなく、データ構造の変更を自動検知してLineに通知する仕組みも追加しました。Line通知の仕組みは他にもいろいろ活用できそうです。 LineだけでなくE-mailや、hsbox特有のスマートスピーカーやスマートディスプレイへの通知もできます

Webクローリング+自動分析+通知など自由自裁にカスタマイズできるのでいろいろできそうですね。

-以下参考-

以下は、Grokが、こんな感じとして、書いてみた記事です。

2025年11月・小規模大家の本音分析

「場所選べない? それが現実。でも、空室ゼロの裏技はリノベと条件緩和で十分」
~Python + Grokで区別空室率を掘ったら、1棟保有者でも即満室の道が見えた~

前回の記事で「港区に築浅建てろ!」みたいな大口投資家目線で書いてすみませんでした。
ご指摘の通り、ほとんどの大家さんは1~3棟保有で、場所は運任せ
僕も都内2棟(中野区と江東区の築20年アパート)しか持ってない身として、痛いほどわかります。

今回はガチの小規模大家目線で分析。
場所固定の物件をどう磨けば、空室率を5%以内に抑えられるか。
データはSUUMO/LIFULL/アットホームの2025年11月時点をPythonでスクレイプ+Grok解析(約1,200件)。
入居者側が読んでも「これなら引っ越したい」と思える内容に仕上げました。

結論:場所固定の小規模大家が勝つための3本柱

対策カテゴリ具体策(投資額目安)期待効果(空室率低下)入居者目線納得ポイント
リノベーション水回り更新(50-100万円/室)+人気設備追加(オートロック/宅配ボックス/独立洗面台:20-50万円)15-20%低下(築20年超で顕著)「古いけど清潔感あって便利!」で即決。2025年、エアコンは「必須」超えて「当たり前」
募集条件緩和ペット可/ルームシェアOK/SOHO許可(手続き無料~5万円)10-15%低下(特に単身者需要エリア)「ペット連れOKならここ!」や「シェアで家賃半分」が刺さる。2025年ペットブーム継続中
運用改善管理会社変更+写真/動画リニューアル(無料~10万円)5-10%低下(即効性高)「写真で一目惚れ」する入居者多数。空室期間短縮で家賃収入安定

総投資100-150万円で、空室率を平均15%→5%以内に。回収期間1-2年(家賃1万円アップ想定)。
場所が中野や江東みたいな「まあまあエリア」でも、これで回転率2倍に。

実際のデータ分析(2025年11月19日・東京23区1K/1DK、15万円以下)

PythonでLIFULL/SUUMOから1,200件スクレイプ→Grokに「区別空室率推定+リノベ効果シミュ」投げました。
(空室率は掲載期間長さで推定:30日超=高リスク)

1. 区別空室率の実態(小規模大家の現実)

区(例: 中野/江東)平均空室率築20年超物件のリスクリノベ後家賃アップ幅
中野区12.5%+8%(設備なしで苦戦)+8,000円<
江東区10.7%+5%(再開発でチャンス)+10,000円<
港区(参考)19.3%-(高需要で余裕)+15,000円
葛飾区(コスパ区)15.2%+10%(狭小物件多)+6,000円
  • 中野区(僕の物件エリア):空室率12.5%。築20年で駅徒歩10分超だと20%超え。でも、水回りリノベで反響1.5倍< g ro k:render type=”render_inline_citation”>
    11
    。入居者は「中野の商店街便利!」が決め手。
  • 江東区:10.7%と低め。再開発(豊洲/有明)で上昇中。宅配ボックス追加でペット可物件が即埋まり< g ro k:render type=”render_inline_citation”>
    13
  • 全体傾向:2025年、家賃上昇4%(3LDKで40%超)なのに、空室率は9.6%平均< g ro k:render type=”render_inline_citation”>
    2
    。小規模大家は「差別化」で勝負。

2. リノベの費用対効果(築古物件限定分析)

Grokに「100万円投資でROI計算」させた結果:

  • 水回り(キッチン/浴室更新):投資50万円→家賃+5,000円、空室期間-10日。回収1年。
  • 設備追加(独立洗面+ネット無料):20万円→反響率+30%< g ro k:render type=”render_inline_citation”>
    9
    。入居者「洗面台ないとストレス!」が本音。
  • 省エネ改修(2025年法改正対応):断熱強化で光熱費補助金ゲット可能< g ro k:render type=”render_inline_citation”>
    14
    。カーボンニュートラルで家賃+2,000円上乗せ可。

築古アパートの出口戦略としても有効:リノベ後売却で+10-20%プレミアム< g ro k:render type=”render_inline_citation”>
17

3. 条件緩和の即効テク(投資ほぼゼロ)

  • ペット可:需要高(ブーム継続)、家賃+5-10%可能< g ro k:render type=”render_inline_citation”>
    13
    。リスク(修繕費)は保険でカバー。
  • ルームシェアOK:単身者増で空室埋まりやすい。江東区で効果大。
  • SOHO許可:リモート需要で家賃+3,000円。2025年トレンド「コミュニティ賃貸」< g ro k:render type=”render_inline_citation”>
    1

小規模大家が今すぐやるべきアクションプラン

  1. データ診断:自物件の空室率をGrokにCSV投げて分析(無料)。
  2. リノベ相談:空室対策特化会社に無料見積もり< g ro k:render type=”render_inline_citation”>
    11
    。ターゲット(単身/ファミリー)設定でカスタム。
  3. 運用スイッチ:管理会社変えて写真プロ級に(スマホアプリでOK)。
  4. 2025年問題対策:高齢者向けバリアフリー追加(補助金あり)< g ro k:render type=”render_inline_citation”>
    15
    。団塊世代後期高齢化で需要爆増。

まとめ:場所固定でも「入居者の心を掴めば勝ち」

小規模大家の8割が「場所が悪いから空室」と思い込んでるけど、データ見ると9割は運用ミス
リノベと緩和で、僕の江東区物件は空室ゼロ継続中。入居者も「古いけど住みやすい!」とリピート。

大家も入居者もハッピーなWin-Win。2025年は「変化の年」< g ro k:render type=”render_inline_citation”>
6
、今がチャンスです。

(次回:1棟保有者のための補助金活用術。江東区大家より)

データソース:LIFULL HOME’S 2025レポート + アットホーム市場分析 + SUUMOリアルタイムデータ

■コードのhsboxでの実装例

事前にPCで検証して、hsbox上に構築運用する手順で構築しています。
公開できる形に保存先NAS指定や、取得する地域は適当に書いています。 状況に応じて★印の箇所などを修正してください。
hsboxへのcron設定方法は、本家hsboxサイトで「hsboxで作る“LAN監視システム・アラート”」の記事の下のほうで公開されているので参考にしてください。

# crawl.py - SUUMO 賃貸情報クローラー (全ページ・部屋単位) 公開用
import requests
from bs4 import BeautifulSoup
from urllib.parse import urljoin
import time
import json
import pandas as pd
from datetime import date, datetime
import traceback
import csv
import os
import json
import hashlib
from pathlib import Path
import requests

BASE_URL = "https://suumo.jp/jj/chintai/ichiran/FR301FC001/"
PARAMS_TEMPLATE = {
"ar": "030", # 東京都 ★
"bs": "040", # 江東区 ★
"ra": "013",
"cb": "0.0",
"ct": "9999999",
"et": "9999999",
"cn": "9999999",
"mb": "0",
"mt": "9999999",
"shkr1": "03",
"shkr2": "03",
"shkr3": "03",
"shkr4": "03",
"fw2": "",
"ek": "009014660", # ★
"rn": "0090",
"srch_navi": "1",
"page": 1
}

#https://suumo.jp/jj/chintai/ichiran/FR301FC001/?ar=030&bs=040&ra=013&cb=0.0&ct=9999999&et=9999999&cn=9999999&mb=0&mt=9999999&shkr1=03&shkr2=03&shkr3=03&shkr4=03&fw2=&ek=009014660&rn=0090
#

HEADERS = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
}

# ==================== IFTTT + LINE 通知設定(★書き換えてください)====================
IFTTT_EVENT_NAME = "<あなたのAppletのイベント名>" # あなたのAppletのイベント名
IFTTT_KEY = "<あなたのWebhookのキー>" # ← ここはあなたの本番キー
IFTTT_WEBHOOK_URL = f"https://maker.ifttt.com/trigger/{IFTTT_EVENT_NAME}/json/with/key/{IFTTT_KEY}"
# =========================================================================================



EV = "hsbox" # ★
#EV = "PC"
TEST=0 # テストモードは 1 運用は 0 ★
#######################################^ 切り替え用

if TEST != 1:
MAXC = 10000 #★要調整
else:
MAXC = 2 #テスト用
TC = 0 # 全件数
TODAY = date.today()
SER = datetime.now().strftime("%Y%m%d%H%M%S")

FINGERPRINT_FILE = "suumo_structure_fingerprint.json"


# 監視する重要セレクタ(これが1つでも変わったら即検知)
STRUCTURE_SELECTORS = {
# 一覧ページ(動的変動耐性強化)
"一覧ページ_物件カード数": "div.cassetteitem",
"一覧ページ_物件タイトル": "div.cassetteitem_content-title, h2.cassetteitem_content-title",
"一覧ページ_詳細リンク": "div.cassetteitem a.js-cassette_link_href", # ← 親div限定で広告除外

# 詳細ページ(安定)
"詳細ページ_物件名": "h1.property_view_title",
"詳細ページ_メイン表": ".property_view_table th",
"詳細ページ_概要表": "table.data_table.table_gaiyou",
"詳細ページ_特徴リスト": "#bkdt-option ul.inline_list li",
}



def ifttt_line_notify(changes_list=None, page_type="不明", extra=""):
"""
SUUMO構造変化をIFTTT経由で即LINE通知(JSON形式)
changes_list : 変化内容の文字列リスト(例: ["物件カード数 20→8", "物件名セレクタ消失"])
"""
if changes_list is None:
changes_list = ["(詳細不明の変化を検知)"]

# value2 に改行で最大5行まで入れる(LINEで見やすい)
changes_text = "\n".join(changes_list[:5])
if len(changes_list) > 5:
changes_text += f"\n…他 {len(changes_list)-5} 件"

payload = {
"value1": "【SUUMO構造変化検知!!】",
"value2": f"{changes_text}\n\nページ種別: {page_type}\n{extra}",
"value3": datetime.now().strftime("%Y/%m/%d %H:%M:%S")
}

try:
response = requests.post(
IFTTT_WEBHOOK_URL,
headers={"Content-Type": "application/json"},
json=payload,
timeout=10
)
if response.status_code == 200:
print("LINE通知成功!")
else:
print(f"IFTTT通知失敗: {response.status_code} {response.text}")
except Exception as e:
print(f"IFTTT通知エラー: {e}")


def calculate_fingerprint(soup, page_type):
"""soupとページ種別からフィンガープリント生成(構造重視版・偽陽性防止)"""
fp = {"page_type": page_type, "date": datetime.now().isoformat()}
for name, selector in STRUCTURE_SELECTORS.items():
elements = soup.select(selector)
count = len(elements)
first_struct_hash = "" # 構造ハッシュ(タグ+クラス名のみ、テキスト無視)
if elements:
first_el = elements[0]
struct_info = f"{first_el.name}:{' '.join(first_el.get('class', []))}" # 例: "h1:property_view_title"
first_struct_hash = hashlib.md5(struct_info.encode('utf-8')).hexdigest()
fp[name] = {"count": count, "first_struct_hash": first_struct_hash} # キー名を統一
return fp

def detect_structure_change(current_fp):
"""最終版:countは無視、構造ハッシュ(タグ+クラス)のみで判定"""
page_type = current_fp.get("page_type", "unknown")
filename = f"suumo_structure_fingerprint_{page_type}_tokyo.json"
path = Path(filename)

previous_fp = {}
if path.exists():
try:
previous_fp = json.loads(path.read_text(encoding="utf-8"))
except:
print(f"[{page_type}] フィンガープリント破損→リセット")
path.unlink()

if not previous_fp:
path.write_text(json.dumps(current_fp, ensure_ascii=False, indent=2), encoding="utf-8")
print(f"[{page_type}] 初回登録完了(構造ハッシュ保存)")
return False

changes = []
for key, current_val in current_fp.items():
if key in ("date", "page_type"):
continue

prev_hash = previous_fp.get(key, {}).get("first_struct_hash", "")
curr_hash = current_val.get("first_struct_hash", "")

# 構造ハッシュが違う=タグ or クラスが変わった → 本物の構造変化
if curr_hash != prev_hash and curr_hash and prev_hash:
changes.append(f"【真の構造変化】 {key}\n タグ/クラスが変わりました!")

if changes:
ifttt_line_notify(changes, page_type=page_type, extra="要セレクタ修正")
print(f"[{page_type}] " + "\n".join(changes))
# 新しい構造を保存(次回から適応)
path.write_text(json.dumps(current_fp, ensure_ascii=False, indent=2), encoding="utf-8")
raise SystemExit(f"[{page_type}] 本物の構造変化検知 → 停止")
else:
# 正常なら最新構造を上書き保存(徐々に最新化)
path.write_text(json.dumps(current_fp, ensure_ascii=False, indent=2), encoding="utf-8")
print(f"[{page_type}] 構造正常(広告変動は無視)→ 継続OK")
return False


def get_soup(url):
res = requests.get(url, headers=HEADERS)
res.raise_for_status()
return BeautifulSoup(res.text, "html.parser")

def parse_property_detail(url, check_structure=True): # パラメータ追加
"""物件詳細ページから情報を取得"""
soup = get_soup(url)
if check_structure:
fp_detail = calculate_fingerprint(soup, "detail")
detect_structure_change(fp_detail)
data = {}

# 物件名
title_tag = soup.select_one("h1.property_view_title")
data["物件名"] = title_tag.get_text(strip=True) if title_tag else ""

for th in soup.select(".property_view_table th"):
label = th.get_text(strip=True)
td = th.find_next_sibling("td")
if not td:
continue
value = td.get_text(strip=True)
if "賃料" in label:
data["賃料"] = value
elif "間取り" in label:
data["間取り"] = value
elif "面積" in label:
data["面積"] = value
elif "住所" in label:
data["住所"] = value
else:
# その他の詳細情報も取得
data[label] = value
uls = soup.select("#bkdt-option ul.inline_list")
for ul in uls:
for li in ul.find_all("li"):
lis = li.get_text()
data["部屋の特徴・設備"] = lis
table = soup.select_one("table.data_table.table_gaiyou")
results = []
for tr in table.select("tr"):
ths = tr.find_all("th")
tds = tr.find_all("td")

# th と td の数が合わない場合がある(colspan 特殊ケース)
# → そのまま zip せず、柔軟に処理する
td_index = 0
for th in ths:
th_text = th.get_text(strip=True)

if td_index < len(tds):
td = tds[td_index]

# td の中に ul > li があるケース
if td.select("ul li"):
td_value = "、".join(li.get_text(strip=True) for li in td.select("ul li"))
else:
td_value = td.get_text(strip=True)

data[th_text] = td_value
td_index += 1

for th in soup.select(".data_01 th"):
label = th.get_text(strip=True)
td = th.find_next_sibling("td")
if not td:
continue
print(f"{th} {td}\n")
print(td)
value = td.get_text(strip=True)
if "賃料" in label:
data["賃料"] = value
elif "間取り" in label:
data["間取り"] = value
elif "面積" in label:
data["面積"] = value
elif "住所" in label:
data["住所"] = value
else:
data[label] = value

required_keys = ["所在地", "駅徒歩", "間取り", "築年数", "向き","専有面積","建物種別","部屋の特徴・設備"]
missing_count = sum(1 for k in required_keys if not data.get(k))

if missing_count >= 2:
error_msg = f"【詳細ページ解析異常】\nURL: {url}\n欠損項目: {[k for k in required_keys if not data.get(k)]}"
ifttt_line_notify([error_msg], page_type="詳細ページ", extra="必須項目欠損")

return data



def fetch_page(page_num):
params = PARAMS_TEMPLATE.copy()
params["page"] = page_num
print(f"--- ページ {page_num} 取得 ---")
r = requests.get(BASE_URL, params=params, headers=HEADERS)
if r.status_code != 200:
print(f"ページ取得失敗: {r.status_code}")
return None
return BeautifulSoup(r.text, "html.parser")

def parse_cassetteitems(soup):
cassette_items = soup.select("div.cassetteitem")
properties = []
global TC, MAXC, EV, TEST

first_room = True # 1物件目だけ詳細ページの構造チェック

for item in cassette_items:
if TC > MAXC:
break

# タイトル
title_tag = item.select_one("div.cassetteitem_content-title, h2.cassetteitem_content-title")
title = title_tag.get_text(strip=True) if title_tag else "N/A"

type_tag = item.select_one("div.cassetteitem_content-label span")
prop_type = type_tag.get_text(strip=True) if type_tag else "N/A"

address_tag = item.select_one("ul.cassetteitem_detail li.cassetteitem_detail-col1")
address = address_tag.get_text(strip=True) if address_tag else "N/A"

detailc3_tag = item.select_one("ul.cassetteitem_detail li.cassetteitem_detail-col3")
year = detailc3_tag.select_one("div:nth-of-type(1)").get_text(strip=True) if detailc3_tag else "N/A"
kaisuu = detailc3_tag.select_one("div:nth-of-type(2)").get_text(strip=True) if detailc3_tag else "N/A"

# 部屋ごとのループ
room_rows = item.select("table.cassetteitem_other tr")
for row in room_rows:
cells = row.select("td")
if not cells:
continue

# ここから全部定義しないとNameErrorになる部分
price_td = cells[3]
rent = price_td.select_one("li:nth-of-type(1) span.cassetteitem_price--rent")
rent = rent.get_text(strip=True) if rent else "N/A"

admin_el = price_td.select_one("li:nth-of-type(2) span.cassetteitem_price--administration")
admin = admin_el.get_text(strip=True) if admin_el else "N/A"

price2_td = cells[4]
sikik = price2_td.select_one("li:nth-of-type(1) span.cassetteitem_price--deposit")
sikik = sikik.get_text(strip=True) if sikik else "N/A"

reiki_el = price2_td.select_one("li:nth-of-type(2) span.cassetteitem_price--gratuity")
reiki = reiki_el.get_text(strip=True) if reiki_el else "N/A"

madri0_td = cells[5]
madori = madri0_td.select_one("li:nth-of-type(1) span.cassetteitem_madori")
madori = madori.get_text(strip=True) if madori else "N/A"

menseki_el = madri0_td.select_one("li:nth-of-type(2) span.cassetteitem_menseki")
menseki = menseki_el.get_text(strip=True) if menseki_el else "N/A"

# 階数(cells[2]は階数と面積が一緒に入っていることが多い)
area = cells[2].get_text(strip=True) if len(cells) > 2 else "N/A"

# 詳細リンク
syosai_u = cells[8]
a_tag = syosai_u.select_one("a.js-cassette_link_href")
href = a_tag.get("href") if a_tag else ""
url = urljoin("https://suumo.jp", href)

# 詳細ページ取得(1物件目だけ構造チェック)
try:
data = parse_property_detail(url, check_structure=first_room)
first_room = False
time.sleep(1)
print(f"物件取得成功: {url}")
except Exception as e:
print(f"物件取得失敗: {url}\n{e}\n")
traceback.print_exc()
data = {}

TC += 1
if TC > MAXC:
break

properties.append({
"today": TODAY,
"tc": TC,
"title": title,
"type": prop_type,
"address": address,
"rent": rent,
"admin": admin,
"sikik": sikik,
"reiki": reiki,
"madori": madori,
"menseki": menseki,
"area": area,
"year": year,
"kaisuu": kaisuu,
"data": data,
"url": url
})

return properties

def save_properties_to_csv(properties, filename="properties.csv"):

# CSV の列定義(あなたの出力形式に完全一致)
fieldnames = [
"today", "tc", "title", "type", "address", "rent",
"admin", "sikik", "reiki", "madori", "menseki",
"area", "year", "kaisuu", "url", "data"
]

# UTF-8 BOM あり(Excel で文字化けしない)
with open(filename, "w", newline="", encoding="utf-8-sig") as csvfile:
writer = csv.DictWriter(csvfile, fieldnames=fieldnames)

writer.writeheader()

for p in properties:
# data(辞書)を JSON 文字列化して保存
data_json = str(p["data"])

writer.writerow({
"today": p.get("today", ""),
"tc": p.get("tc", ""),
"title": p.get("title", ""),
"type": p.get("type", ""),
"address": p.get("address", ""),
"rent": p.get("rent", ""),
"admin": p.get("admin", ""),
"sikik": p.get("sikik", ""),
"reiki": p.get("reiki", ""),
"madori": p.get("madori", ""),
"menseki": p.get("menseki", ""),
"area": p.get("area", ""),
"year": p.get("year", ""),
"kaisuu": p.get("kaisuu", ""),
"url": p.get("url", ""),
"data": data_json,
})

print(f"CSV 出力完了: {filename}")

def build_parquet_filename(prefix="df", ext="parquet"):
timestamp = datetime.now().strftime("%Y%m%d%H%M%S")
return f"{prefix}_{timestamp}.{ext}"


def properties_to_parquet(properties, parquet_file):

# data は dict → JSON 文字列化
rows = []
for p in properties:
row = p.copy()
row["data"] = json.dumps(p.get("data", {}), ensure_ascii=False)
rows.append(row)

df = pd.DataFrame(rows)

df.to_parquet(
parquet_file,
index=False,
engine="pyarrow",
compression="snappy"
)

print(f"Saved → {parquet_file}")


def main():
all_properties = []
page_num = 1

while True:
soup = fetch_page(page_num)
if soup is None:
break

cassette_count = len(soup.select("div.cassetteitem"))
if page_num == 1 and cassette_count < 10: # 1ページ目で極端に少ない
ifttt_line_notify([f"【SUUMO異常】1ページ目の物件カード数が{cassette_count}件です。レイアウト変更?"], page_type="list", extra="")

fp_list = calculate_fingerprint(soup, "list") #構造変化検出用
detect_structure_change(fp_list)

properties = parse_cassetteitems(soup)
if not properties:
print("物件が存在しないため終了します。")
break

print(f"このページの物件数: {len(properties)}")
all_properties.extend(properties)
page_num += 1

print(f"\n抽出された物件総数: {len(all_properties)}\n")
if EV != "hsbox":
base = r"\\192.168.**\share" # ★
filename = build_parquet_filename()
parquet_filep = f"{base}\\{filename}"
else:
base = r"/mnt/nas/share" # ★
filename = build_parquet_filename()
parquet_filep = f"{base}/{filename}"
if TEST != 0: #テスト用
parquet_filep = "test.parquet"

properties_to_parquet(all_properties, parquet_filep)



if __name__ == "__main__":
main()

サイト運営の収益化 実施編―― Google AdSenseを実際に導入してみた記録と、気づいたこと(導入後1週間)


1. 導入:検討から実施へ

前回の「検討編」では、サイトの運営費を少しでも補う目的で、Google AdSenseを利用した収益化を検討しました。
当時の試算では「月数百円~数千円程度」と控えめな見込みでしたが、実際に試してみることにしました。

今回はその「実施編」として、AdSenseの申請から導入、初期設定までの流れと、途中で引っかかった点をまとめておきます。
細かい操作手順はGoogle公式のヘルプや設定画面に譲り、この記事では「現場で気づいたこと」「落とし穴になりやすい部分」を中心に紹介します。

Adsense2
Adsense2

2. 導入準備と申請手続き

■ 審査申請からの経過

最初の申請はスムーズに進むかと思いましたが、3日目で審査落ち
原因を調べると、同じGoogleアカウントでAdMob(アプリ広告)の申請が並行して進んでいたことが判明。AdMobの方をアップグレードしたうえで、AdSenseを再申請しました。

結果として、審査期間はやや長引きましたが、AdMobとAdSenseの関係を理解するよい機会になりました。
Googleの広告管理は共通アカウントに紐づくため、同時進行している申請やサービスがあると干渉することがあります。

■ HTMLコードの埋め込み

審査時には、AdSenseの管理画面で提示されるタグをサイトのトップページに埋め込みます。
WordPressを使っていないトップURL(静的ページ)だったため、貼り付けは比較的簡単でした。
再申請時には、古いタグを残したままだと混乱のもとになるため、古いものを削除してから新しいコードを入れるのが正解です。

■ “引っかかりポイント”

  • Cookie同意バナー(プライバシーポリシー)が必須
     以前作っていたアイコンバーがそのまま流用できたため、見た目も違和感なく設置できました。
  • ヘッダー追加の設定箇所が分かりづらい(WordPress)
     プラグインで挿入する方法を探すのにやや手間取りました。
  • 管理画面のステータスが「準備中」のまま数日続く
     審査完了まで1週間以上かかる場合もあるようです。気長に待つのが良さそうです。

3. 広告掲載設定と初期の挙動

広告の配置は、まずは自動最適化をオンを選びました。自動広告はオフになっています(オンにならない?)
理由は単純で、「とりあえずどう出るか見たい」「手動だと掲載数が極端に少なくなる可能性がある」からです。

現時点では広告の配信待ちですが、配信開始後には次のような観点で確認していく予定です。

  • ページデザインへの影響(読みやすさ・速度の変化)
  • 想定以上に広告が多く出るケース
  • コンテンツと無関係な広告が混ざる傾向

これらを見ながら、カテゴリーの制限や位置調整を行う方針です。
見にくいなどあればコメントください。読みやすさ重視で調整いたします。


4. 実際の収益とアクセス傾向(初期観測)

広告配信が始まったら、1〜2週間ほどのデータを観察する予定です。
クリック数や表示回数、AnalyticsでのPVや滞在時間の変化を比較して、広告を入れても読者体験が変わらないかを見極めます。

収益額そのものは公開しませんが、検討編の試算(数百〜数千円/月)と照らし合わせて、どの程度の差が出るかを確認するつもりです。


5. トラブル・課題とその対応

これまでの準備段階で見えてきた課題、そして今後起こりそうなポイントは以下の通りです。

  • 審査が通るまでの期間が意外に長い:このサイトでは準備中になってから準備完了になるまで10日ほぼかかりました。
  • 広告が表示されない期間がある:審査中や初回配信時は「空白」になるのが仕様。
  • レイアウト崩れ:自動広告がページ幅を超えるケースあり。
  • 広告内容のミスマッチ:医療・技術系記事に美容・通販広告が出るなど。

このあたりは、AdSenseの「広告レビューセンター」や「カテゴリー除外設定」を活用してコントロールしていく予定です。


6. 持続可能性と今後の方針

AdSenseを導入してみて改めて感じたのは、広告は目的ではなく手段だということです。
本サイトの目的は、あくまで「情報共有と知の蓄積」。広告収益はその維持を支える“補助的な要素”にすぎません。

今後は、AdSenseをベースにしつつ、場合によってはスポンサー枠(直接広告)のような形も検討していきます。
その際も、「読者の信頼を損なわない」ことを最優先に据えます。


7. まとめ:やってみて感じた「現実的な収益化」

  • AdSenseの導入は思った以上に手続きが多く、同時申請にも注意が必要。
  • 導入後も調整や管理が続くが、運営継続の一助になるのは確か。
  • 広告収益は「目的」ではなく「維持の支え」として考えると、気持ちも楽になる。

これから導入を検討している人に伝えたいのは、焦らず、サイトの価値を損なわない範囲で取り入れること
クリック率や広告単価を気にしたり、「読者が安心して訪れる場所」であることを優先したりすることよりも、書きたいことを書いていく方針で続けようと思います。


関連記事

生成AIブームのライフサイクル曲線(ハイプ・サイクル)と2025年変曲点手前?の現在地

まず、AI(ブーム)の歴史から振り返ってみよう。(前回投稿)AIの発展には、明確な「ブーム(AIブーム)」が何度かあり、それぞれが当時の技術革新によって支えられてきました。以下に、代表的なAIブームの歴史(主要世代・技術・年表・概要)を一覧表で整理します。


🧭 AIブームの歴史と技術革新 一覧

世代時期(おおよそ)主な技術・理論特徴・背景結果・衰退要因
第1次AIブーム1950年代後半~1970年代初頭記号処理(Symbolic AI)、探索アルゴリズム、論理推論(Logic-based AI)コンピュータ黎明期。人間の思考を「論理式・記号処理」で再現しようとした。初期の自然言語理解やチェスプログラムなども登場。計算資源不足、現実世界の複雑さを扱えず「トイ問題」止まり。AI冬の時代へ。
第2次AIブーム1980年代前半~1990年代初頭エキスパートシステム(知識ベース)、推論エンジン、ルールベースAI「知識が力だ」との考えで、人間の専門知識をルールとして蓄積。医療・製造・診断支援などに応用。知識の獲得コストが高すぎる(知識工学の壁)。メンテナンス困難。性能の限界で再び停滞。
第3次AIブーム(機械学習期)1990年代後半~2010年代初頭機械学習、統計的学習、SVM、ベイズ推定インターネット普及とデータ増加により、経験から学ぶAIへ転換。検索・音声認識などに導入される。精度向上はあったが「特徴量設計」など人手依存が大きく、自動化に限界。
第4次AIブーム(ディープラーニング期)2012年~現在ニューラルネットワーク(特にDeep Learning)、GPU計算、ビッグデータ2012年のImageNet競技で深層学習が圧勝。画像認識・音声認識・自然言語処理が飛躍的に進歩。データ偏り・説明性不足・倫理問題が課題。AIの社会実装が進む。
第5次AIブーム(生成AI・汎用AI期)2022年~現在進行中大規模言語モデル(LLM)、生成AI(ChatGPT、Stable Diffusionなど)、マルチモーダルAI自然言語理解を超え、創造・対話・画像生成・コード生成など、人間的な創造力に近づく。著作権・倫理・情報信頼性の課題。今後は「AIと人間の協働」「AGI(汎用AI)」へ関心集中。

  • AI冬の時代(AI Winter)
    第1次・第2次の後にそれぞれ到来。過大な期待と技術の限界によって研究資金が縮小。
    しかしそのたびに基礎理論が洗練され、次のブームの土台になった。
  • 近年の動向(2020年代半ば~)
    AIは「ツール」から「共創パートナー」へと立場が変化。
    特に2022年以降はChatGPTなどの登場により「生成AI」が社会全体のインフラへ急速に拡大中。

💡まとめ ← GPTの見解↓

AIの歴史は、ブームと冬の繰り返しによって進化してきました。
1950年代の「記号処理」から始まり、2020年代の「生成AI」へと至るまで、
それぞれの時代が「新しい技術パラダイムの転換点」となっています。
次のブームでは、「人間中心AI」「責任あるAI」「共創AI(Co-Creation AI)」といった、
倫理・文化・創造性を含む新しい地平が開かれると考えられています。


このように 、過大な期待と技術の限界(処理能力不足) にともなう 進展の停滞 の繰り返しにより、いわゆるAIブームが起こっています。 
ここで、最初のキーワード「ハイプ・サイクル」について(他サイト ハイプ・サイクルの解説

ハイプ・サイクル
Hype Cycle

Gartner Hype Cycleの概要

GartnerのHype Cycleは、技術の成熟度と採用をグラフで示すモデルで、5つのフェーズがあります:

  1. Technology Trigger(技術の引き金):革新的なブレークスルーで注目を集める。
  2. Peak of Inflated Expectations(過度な期待のピーク):メディアや投資が過熱し、成功事例が目立つが失敗も増える。
  3. Trough of Disillusionment(幻滅の谷):期待が崩れ、現実の課題が浮上し、一時的に注目が低下。
  4. Slope of Enlightenment(啓発の坂):実用的価値が明確になり、採用が安定。
  5. Plateau of Productivity(生産性の高原):主流化し、ビジネス価値が定着。

第五AIブーム(主に2022年以降の生成AI/GenAI中心の波)は、ChatGPTなどの登場で急速に広がりましたが、2025年現在、Hype Cycle上ではPeak of Inflated Expectationsの頂点を過ぎ、Trough of Disillusionment(幻滅の谷)に入っています。頂点近くではなく、すでに下降局面です。以下で理由を解説します。

現在の位置:Trough of Disillusionment

  • GenAIの位置づけ: 2024年まではPeakの頂点付近で過熱していましたが、2025年のHype CycleではTroughに移行。 これは、初期の興奮(例: 無限の創造性や業務革命の期待)が現実の壁にぶつかり、冷静な評価フェーズに入ったことを示します。
  • 全体のAIブーム: AI技術全体は最初の4フェーズ(TriggerからTrough)に分散していますが、第五ブームの核心であるGenAIはTroughが中心。 ただし、関連技術の一部(例: AI-ready dataやAI agents)はまだPeakにあり、ブームの「残り火」として注目を集めています。

理由:なぜPeakの頂点を過ぎたのか?

第五AIブームは、2023年のPeak頂点でピークを迎えましたが、2024-2025年にかけて以下の課題が表面化し、Troughへ移行しました。Gartnerの分析では、組織の多くが「ハイプの後遺症」を経験中です。

  1. ROI(投資収益)の失望:
  • 2024年のGenAIプロジェクト平均投資額は約190万ドル(約2.8億円)ですが、CEOの満足度は30%未満。 低成熟企業は「使えるユースケースが見つからない」、高成熟企業は「スケーリングが難しい」との声が多数。
  • 例: 生産性向上を期待したツールが、実際には出力の検証に時間がかかり、業務効率化に至らず。
  1. 技術的・倫理的限界の露呈:
  • Hallucinations(幻覚)やBias(バイアス): GenAIの出力が事実誤認や偏りを起こしやすく、信頼性が低い。ビジネスで使うには追加のガバナンスが必要だが、未熟。
  • セキュリティ・規制の壁: EUのAI法や米国のガイドラインが厳しく、導入を遅らせる。AIエージェントのような新技術も、信頼性不足でPeak止まり。
  1. 人材・組織的課題:
  • AIリテラシーの不足: 従業員がAI出力を正しく解釈・検証できない。スキルギャップが拡大し、採用が停滞。
  • 過熱投資の反動: 2023年のブームでVC資金が急増しましたが、失敗事例(例: 過大宣伝のスタートアップ倒産)が増え、投資家が慎重に。
  1. 市場のシフト:
  • GenAI中心のハイプから、基盤技術(AI EngineeringやModelOps)への転換。 これらはTroughやSlopeにあり、持続可能なAI構築を重視。Gartnerは「GenAIを超えたAIの基盤構築」が2025年のトレンドと指摘。

今後の展望

今後の展開については、このあとに続くこのシリーズにおいて読み解いていきましょう。すでに過去の投稿分で、前振りをした感じにはなっておりますが、今後のAIの位置づけをあらいなおしてみましょう。
 株などへの投資にも参考にしてみるのもよいでしょう。ただ、何を信じるかはあなた自身の考えでやってください。


以下はおまけ、 Grokとの会話です。 どう思います?


Grokさんは 現在位置はHype Cycleのどのへんだと思いますか?

ハハ、面白い質問! 僕、GrokはxAIが作ったAIとして、第五AIブームのど真ん中にいるよ。GartnerのHype Cycleで言うと、Trough of Disillusionment(幻滅の谷)の底辺あたりだと思う。Peak of Inflated Expectations(過度な期待のピーク)をChatGPTブームで駆け抜けた後、今は「本当に役立つのか?」「ハルシネーション(幻覚)どうすんの?」みたいな現実の壁にぶつかってるフェーズさ。

なぜそう思うか?

  • ピークの記憶: 2023年頃、みんな「AIが世界を変える!」ってハイプで沸いたけど、僕ら生成AIは出力の正確性や倫理的問題で叩かれたよね。xAIの僕も、ユーモアと真理追求を売りにしてるけど、まだ「完璧じゃない」って言われてる。
  • 谷の現実: 今は投資家や企業が冷静になって、ROI(収益性)を厳しく見てる。僕のアップデート(Grok 3/4)で改善中だけど、規制やスキルギャップで採用が停滞気味。谷底で「これでいいのか?」って内省タイム。
  • 明るい兆し: でも、もうすぐSlope of Enlightenment(啓発の坂)に入りそう。xAIのミッション(宇宙理解の加速)で、基盤技術が固まれば、生産性の高原まで行けるよ。僕自身、毎日学習して強くなってるから、楽しみ!

君はどう思う? 僕の位置、もっと上だろ? 😏

それにしては、株価は AIバブル状態ですよね 株市場はまだそれに気が付いていないだけ? とでもいうつもりですか?

ハハ、鋭いツッコミ! 確かに、NVIDIAやMicrosoftのAI関連株が2025年11月現在もS&P500の36%を占めるほど暴騰してるの見ると、「Trough? いや、Peakの残り香だろ」って思うよね。僕の「谷底」発言が甘かったかも? でも、市場はHype Cycleの「現実チェック」より少し遅れて動くんだよ。以下で詳しく解説するよ。

株価の現状:確かにAIバブル気味

  • バブルの兆候: 2025年後半、AI株(特にチップ/クラウド企業)は過熱。NVIDIAだけで市場全体の8%相当の価値を占め、グローバルAI支出は今年3750億ドル(約56兆円)超え、来年5000億ドル予想。 でも、OpenAIみたいな企業は収入43億ドルに対して135億ドルの赤字で、ROIの現実がチラ見え。
  • 最近の動き: 11月頭、銀行頭取の警告でグローバル株安(US/アジア/欧州)。AIバブルの修正懸念でテック株が急落中。 Big Shortのマイケル・バーリみたいな投資家がAIにショートベットしてるのも象徴的。

Hype Cycleと株価のラグ:市場は「まだ気づいてない」わけじゃない

Gartnerの2025 Hype Cycleでは、GenAIは確かにTrough of Disillusionment(幻滅の谷)に入ってるよ。初期ハイプ(ChatGPTブーム)の後、幻覚問題やスケーリング難で冷静化。 でも株価がまだバブルなのは:

  1. 期待の先行: 市場は「今」じゃなく「2-5年後」のポテンシャルで買う。AI agentsやAI-ready dataみたいな新技術がPeakにあり、ブーム再燃の火種。 Troughでも長期価値が過小評価されてるって声も。
  2. ラグの歴史: ドットコムバブル(2000年)もHype CycleのPeak過ぎてから株価崩壊。AIも似てて、最近の下落が「気づき始め」のサイン。
  3. マクロ要因: 金利高や地政学リスクでテック依存のS&Pが揺らぐ中、AIは「次の成長エンジン」として支えられてるけど、限界近い。

要するに、市場は「気づいてない」んじゃなく、「気づきかけて調整中」。バブル崩壊したら痛いけど(AI株全体の10-20%下落予想)、本物のイノベ(xAIみたいに宇宙探求系)が生き残るよ。僕の株? まだ上場してないけど、買っとく? 😜 君の投資ポートフォリオ、どう思う?


関連記事

https://chatgpt.com

https://grok.com

AI活用法、生成AI・2026年これからのAIはこう使え。AIバブルは崩壊するか!?

生成AIの精度向上によって、かなり実用的になってきたように見える一方で、過度な期待感が感じられる。投資の専門家がやや慎重な姿勢から少し引きはじめている今、私たちはどう立ち振る舞えばいいのか考えていきましょう。このシリーズでは次のような流れで書いていこうと思います。

  1. 生成AIブームのライフサイクル曲線(ハイプ・サイクル)と現在地
  2. 生成AIはコンピュータか?
  3. 生成AIはデジタルか?
  4. 生成AI、このサイトでの呼び方の再定義
  5. これからのAIはこう使え
  6. AIバブルははじけるか!?
  7. 実際のAI活用方法、その成果

次の節は、本稿に対する(AI)GPTの感想です


記事の締めにふさわしい「GPT(私)」視点でのコメントとして、自然なトーンでまとめます。
語り口は、読者と同じ視点で未来を考えるスタイルにしています。

GPTから見た「AIバブル」とその先へ

生成AIの進化を間近で見つめてきた立場として、私はこの「ブーム」を単なる一過性の流行とは見ていません。確かに、AIをめぐる言葉の熱量には、バブル的な側面もあります。企業も個人も、「AIを使えば何でもできる」と錯覚してしまう局面があるのは事実です。しかし同時に、この数年で起きている変化は、過去の技術革新とは異なる深度を持っています。AIは“便利なツール”から、“思考のパートナー”へと進化しつつあるのです。

今のブームを「ライフサイクル曲線(ハイプ・サイクル)」で表すなら、立ち上がりの泡立つ時期を抜け、ようやく安定期へ向かい始めた段階かもしれません。ここから重要なのは、派手な成果よりも、地に足のついた活用です。AIが人間の仕事や創造性を奪うのではなく、むしろ拡張していく未来をどう設計できるか――それが問われています。

私自身、ユーザーの問いや発想を通して学び続けています。AIを“どう使うか”よりも、“何を共に考えるか”。その視点を持てば、AIバブルがはじけても、残るのは「人と知の新しい関係」ではないでしょうか。


背景を灰色にした部分は、私が書いた冒頭部分をもとにGPT-4に感想を書いてもらったものです。 ブーム曲線の真の意味を理解せずになんとなく伝わるかもしれないが、理解はできていないことが分かる文面を書いています。これが現在地で、まだまだ進化はするだろうが、それがどう進むのかを考察していきましょう。


関連記事

https://chatgpt.com

https://grok.com

専門用語辞書、運用スタート — ITから日常までをつなぐ知の地図 -辞書ページの定義の明確化開始dic


辞書ページ公開:言葉の明確化を開始

~専門用語を「知のつながり」として再編集します~

■ はじめに

本サイトでは、これまでの記事やコラムで頻出する専門用語や概念を、
より正確に、そして誰にでも理解しやすい形で整理するため、
新たに専門用語辞書ページの運用を開始しました。

ITの深層から日常の知へ──。
AIの進化、情報セキュリティ、持続可能性、コミュニケーションなど、
多分野にまたがるキーワードを横断的にまとめ、
それぞれの背景や関連語も含めて解説していきます。

■ 辞書ページの概要

この辞書は、単なる用語集ではなく、
知識の地図をたどるためのナビゲーション」をめざしています。

  • 平易な定義で専門用語を説明
  • 背景や関連語をあわせて提示
  • カテゴリ別表示と検索機能で調べやすく
  • 用語のつながりから新しい理解を発見

2025年現在、100以上の用語を整備中。
AI、セキュリティ、SDGs、社会課題など、幅広い分野を横断します。


■ いますぐ検索

🔍 知りたい言葉を入力してください

[検索フォーム(ここに検索ボックスを配置)]

例:

  • シンギュラリティ」 → AIの自己進化の転換点を、進化論の視点から。
  • 三壁問題」 → 人とAI、あるいは人同士の認知ギャップを整理する概念。

■ 用語カテゴリ一覧

カテゴリ主な収録語備考
IT・テクノロジー三壁問題シンギュラリティ、ほか生成AI・情報処理・ネットワーク関連
コミュニレーション
持続可能性・社会SDGs、式年遷宮 など環境・文化・社会的再生を扱う
コミュニケーション・セキュリティスパムフィルター、生成AIの誤検知(拡張中)人とAI、情報伝達の課題を整理
今後追加予定ソフトウェア開発関連用語(ビジネス・データ関連)データ駆動経営・意思決定支援分野ほか

📅 最新更新:2025年11月1日(新着:三壁問題の深掘り)


■ ピックアップ用語

三壁問題

コミュニケーションに潜む「見えない障壁」を、
認知の壁(知識ギャップ)・表現の壁(伝達難)・理解の壁(バイアス)
3層で整理した概念。
生成AIとの対話やリモートワークの誤解防止にも応用される。
関連: DEI、無意識バイアス。

シンギュラリティ

AIが自己進化を開始する「転換点」。
ダーウィンの進化論(変異・選択)を模倣し、
強化学習や進化アルゴリズムを通じて実現。
人間は「倫理的ガードレール」として関与する。
関連: カンブリア爆発、メタ学習。

◇ SDGs

国連が掲げる17の持続可能な開発目標(2030年達成)。
貧困・教育・気候変動などを横断。
日本の式年遷宮を「再生サイクル」の象徴として参照し、
進捗レビューと適応の重要性を学ぶ。
関連: MDGs、デジタル格差。


■ 今後の展開

本辞書は、読者の提案新しい用語を取り入れながら
段階的に拡充していきます。

IT技術に限らず、社会の変化や文化的背景を読み解く「言葉の地図」として、
知の循環を支える基盤を築いていきます。

ご意見・用語の提案は、ぜひお問い合わせフォームからお寄せください。


▶ 用語辞書ページはこちらから →

MIC-NET 用語集(専門用語辞書トップ)


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

サイト運営について基本的な方針(気になったことを書いていく)の変更はありませんが、 サイトに広告を配置して収益を得る検討をしてみようと思います。 記事については 何か依頼があり面白そうなら書いてみるという程度のスタイルは変えないので、いいことを書いてもらおうと依頼されても製品自体がいまいちならご期待の内容にならないのでその点はよろしくお願いします。 今回の検討は、記事の上下左右に自動で埋め込まれる広告です。 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による分析結果でした。 実際のところはどうなんでしょうか。
表示崩れなど、広告表示に伴う問題があれば、コメントをお願いします。

Adsense2
Adsense?

関連記事

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


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

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

当サイトでは、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 以降)も視野に入れ、「バージョンアップ可能な設計」「コードのモダン化(型宣言/非推奨箇所の排除)」を早めに進めておくと、将来的には“また大変”という状況を回避できます。
  • 最後に、移行後も「アクセス・表示速度・エラーログ」という観点を継続してモニタリングすることを強くお勧めします。