これからのAI(第5世代AI)はこう使え-第5世代AIの効果的な使い方|新人レベルでも劇的に効率化する方法-

生成AIはまだ研修中の新人と同じ。ドキュメントを整えれば、AIも人も最大限に活躍する

これまで、いろいろ書いてきましたが、生成AIなどの第5世代AIは、かなり人のレベルに近いところまできてはいるが、これからの進化はどのようなスピードで進むのかの予測は難しい。入力情報の分解能は段々上がってきてはいるもののまだまだ粗い入力情報をもとにしたAIが多い。このような状況もあり、AIの精度は部分には人に近いレベルになってきているところもあるが、その分野の専門家から見ると研修中の新人レベルくらいに留まっている。
プロレベルに達するには、どのようなハードルがあると考えられるかについては、次回以降に書くことにします。今回は、新人レベルくらいのAIをうまく活用する方法について書いていきます。

AI5
AI5

例えば、このサイトでの記事を公開する前にチェックすることに活用してみます。Wordなどの校正ツールで”てにおは”などの文法チェックが可能です。これは20年ほど前のルールベース(第2世代AIの成果)のツールですが、誤字脱字のチェックには対応できていませんでした。第5世代AIでは、100%でもなく、完全な再現性があるわけではありませんが、ある程度の精度で、使える感じになってきています。
具体的には、つぎのように生成AIへのプロンプト入力を行い、記事のチェックします。

つぎのURLのWeb記事について、
「https://mic.or.jp/info/2025/11/14/ai-4/」
↑この部分にチェック対象のURLを書く

以下のURLの先の記事に記載されたルールに従ってチェックをお願いします。
https://mic.or.jp/info/2025/11/22/ai-8/


URLを受け付けない生成AIもありますが、使えるものもあります。企業内で独自構築していれば、セキュリティ的にもリスクが低くなるので活用できる範囲はかなり広くなるでしょう。
ちなみに、この記事ページ作成したルールでチェック判定した結果はつぎのとおりです


記事チェック結果

総合判定結果

合格(問題なし)。記事は全体として論理的で、誤字脱字やコンプライアンス違反、虚偽の記載は見当たらず、誹謗中傷や個人情報の問題もありません。生成AIの技術的性質を正確に解説しており、矛盾や間違いもありません。軽微な表記揺れ(例: 繰り返し画像記述)は意図的なものと判断されます。

チェック項目一覧表

カテゴリチェック項目判定結果対象外とする記載例備考
重点チェック項目誤字脱字がないか合格AIの出力結果等、外部から持ち込んだ記載記事全文をスキャンしたが、明らかな誤字脱字なし。
“★要修正”などの編集途中と判断される記載が残っていないか合格意図的に記載した部分編集途中を示すマークや未完成記述なし。
個人情報が含まれていないか合格迷惑メールの発信元など、著者側の個人情報ではないもの個人名・連絡先等の記載なし。
誹謗中傷と受け取られる記載はないか合格AIの出力結果や迷惑メール等、外部から持ち込んだ記載部分批判的な表現も技術解説の範囲内。
コンプライアンス上問題となる記載はないか合格迷惑メール等、外部から持ち込んだ記載部分法的・倫理的問題なし。
虚偽の記載はないか合格迷惑メール等、外部から持ち込んだ記載部分生成AIの決定論的性質に関する説明は事実に基づく。
その他のチェック項目論理、矛盾や間違いがないか合格全体の論理が一貫し、例外ケースも適切に扱っている。

具体的な指摘事項

  1. 誤字脱字
  • 指摘箇所:なし
  • 修正案:なし
  1. 編集途中と判断される記載
  • 指摘箇所:なし
  • 修正案:なし
  1. 個人情報
  • 指摘箇所:なし
  • 修正案:なし
  1. 誹謗中傷
  • 指摘箇所:なし(例: 「AIバブルの勘違い!?」はセンセーショナルだが、投資家への一般論で誹謗中傷に該当せず)
  • 修正案:なし
  1. コンプライアンス上問題となる記載
  • 指摘箇所:なし
  • 修正案:なし
  1. 虚偽の記載
  • 指摘箇所:なし(生成AIの確率的出力や決定論的構造の説明は、技術的に正確)
  • 修正案:なし
  1. 論理、矛盾や間違い
  • 指摘箇所:なし(例: コンピューターの決定論的性質と生成AIの例外を明確に区別し、表でまとめているため一貫)
  • 修正案:なし

追加コメント

  • 記事の構造(定義→深掘り→まとめ→表)が明確で、読者への問いかけも教育的です。画像記述の繰り返し(![ai vs computer])はレイアウト意図と判断し、問題なし。
  • 関連リンク(ChatGPT、Grok)は適切で、プロモーション的要素も中立的。

このようにドキュメントの再利用性を考慮した構造をもとに、AI活用を推進できます。このようなドキュメントは各法人ごとに保有しているはずですが、従来からうまく活用できていた法人とそうでない法人でAI活用に差が生じるでしょう。このシリーズで言いたいことは、第5世代以降のAI活用は、人財活用とほぼ等価であるということです。人財育成(人材ではなく人財を大切にする)法人は、AI活用を効果的に進めることができるでしょう。

第5世代以降のAIと人はほぼ等価ということから言える もう一つのヒントは、人が活用できていないドキュメントでは、AIも活用できないだろうといことです。たとえば、非常に膨大で冗長な構成になっていると、中には無駄な記載も多くその解析に無駄な処理コストが発生するでしょう、場合によっては端々まで読み切れず途中で端折ってしまうこともあるでしょう。さらには、記述間で矛盾が生じていることもあるでしょう。そのような場合、その法人の活動がうまくいっていないことに繋がっているかもしれません。そのような状況で人手不足だからと、ドキュメントで教育した第5世代AIを入れてもいれてもうまく回らないでしょう。

この辺の話も参考にAI導入の話の前に、現在のドキュメントを見直すのが良いかもしれません。

以下、追加の検証結果

https://mic.or.jp/info/2025/11/22/usage

関連記事

https://grok.com

https://chatgpt.com

記事のチェックルール for AI

指定したURLの記事について、次のルールでチェックしてください。

重点チェック項目:
・誤字脱字がないか 
・個人情報が含まれていないか
・誹謗中傷と受け取られる記載はないか
・コンプライアンス上問題となる記載はないか
・虚偽の記載はないか

その他のチェック項目:
・論理、矛盾や間違いがないかチェックしてください。

結果出力方法
総合判定結果をトップに記載してください。
つぎに各チェック項目ごとに結果をまとめた一覧表を作成してください。
つづいて、個々の具体的な指摘について、指摘箇所と修正案を記載してください。

ルールベースチェックでの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()

「“生成AI”の名のもとに:第5世代AIを正しく呼び直す時がきた」――氾濫する呼称の整理から見える、新しいAI理解の枠組み


はじめに:「生成AI」が、すべてを覆い隠していないか

近年、「生成AI」という言葉を目にしない日はありません。
ニュースでも企業発表でも、まるで“AIの代名詞”のように使われています。
ChatGPT、Gemini、Claude、Midjourney、Suno――これらが「生成AI」とひとまとめに語られることがほとんどです。

けれど、立ち止まって考えてみると、この呼び方には違和感が残ります。
たしかに第5次AIブームの火付け役は生成AI(Generative AI)でした。しかし、今やその技術潮流は「生成」だけでは語り尽くせません。
入力の理解・判断・文脈把握・意図推定――そうした領域の進化こそが、この世代の本質なのです。

では、いま“第5世代AI”を「生成AI」と呼び続けるのは、正確な理解につながるのでしょうか?
本稿では、この呼び方をいったん見直し、より正しい言葉の整理を試みます。


第5次AIブームとは何だったのか

AIの歴史を振り返ると、ブームは技術革新の節目ごとに訪れてきました。
第1次は「探索・推論」、第2次は「知識ベース」、第3次は「機械学習」、第4次は「ディープラーニング」。
そして第5次――それが現在進行中の「生成AIブーム」です。

ただし、その本質は“生成そのもの”よりも、「自然言語による指示を理解し、目的に応じて出力する能力」にあります。
つまり、プロンプト(入力)を解釈し、意図に沿った応答や成果物を返す――これが第5世代AIの核心。

この流れは、従来の「アルゴリズム主導のAI」から、「人の指示に寄り添うAI」への大きな転換を意味します。
言い換えれば、“人がAIを操作する時代”から、“人とAIが対話で協働する時代”への移行です。


「生成AI」と「第5世代AI」は、似て非なるもの

では、いま一般に言われる「生成AI」とは何か。
厳密には、新しいデータを生成するAIモデルのことを指します。
文章、画像、音楽、プログラムコード――いずれも学習したデータをもとに新たなコンテンツを「生成」するため、この名が付けられました。

しかし、第5世代AIには、生成にとどまらない多様な姿があります。
音声や映像の解析に優れたAI、自然言語を正確に理解して業務を補助するAI、あるいは人間の意図を推測して行動を最適化するエージェントAI――これらも同じ文脈で語られるべき存在です。

次の表に整理してみましょう。

項目生成AI第5世代AI(広義)
主眼コンテンツ生成(文・絵・音など)プロンプト理解と応答・判断
出力重視/入力重視出力重視入出力の統合
代表例ChatGPT, Midjourney, SunoCopilot, GPTs, AIエージェント
技術的特徴Transformerベースの生成モデル自然言語理解、マルチモーダル、文脈推論
役割新しい表現を生み出す人と共に考え、動く

この比較からも分かるように、「生成AI」は第5世代AIの一部にすぎないのです。
すべてを“生成AI”という名のもとに括ってしまうのは、技術の多様性を見えにくくしてしまいます。


“呼び方”を再定義する:サイトとしての立場

そこで、本サイトでは今後、次のように呼称を整理していきます。

  1. 生成AI
     → 「コンテンツ生成を主目的とするAI」の呼称として使用。
     例:文章生成、画像生成、音楽生成など。
  2. 第5世代AI(または「指示応答型AI」)
     → 「プロンプト入力と文脈理解を基盤に、多様な出力を行うAI」の総称。
     例:対話型エージェント、支援AI、判断AIなどを含む。
  3. AIエージェント/支援AI
     → 「人間の意図を理解し、行動を代行・補完するAI」の呼称。
     生成AIよりも“実行”や“判断”に重きを置く。

こうした区分を明確にすることで、読者は記事内で「どのタイプのAI」を指しているのかを誤解なく理解できます。
同時に、AIの発展を「生成から行動へ」「理解から共創へ」と捉える視点を共有できます。


言葉の整理が、理解の整理につながる

「言葉」は、時代を映す鏡です。
AIが急速に進化するなかで、用語の意味もまた曖昧に拡散していきます。
“生成AI”という言葉は便利ですが、あまりに広範囲を覆ってしまった今こそ、あえて立ち止まって再定義することに意味があります。

呼称の精度が上がれば、議論の精度も上がります。
どの技術を指して話しているのか、どの範囲で語っているのかが明確になれば、AI社会の課題も見えやすくなります。

そして何より、言葉を正しく選ぶことは、AIという存在を正しく理解することの第一歩です。
“生成AI”という看板の下に隠れていた、多様で進化するAIたちを、もう一度見つめ直す時がきています。


そして――「総称を求めること自体」が問いになった

ここまで議論してみると、ひとつの事実に行き着きます。
それは、「どんな呼び方を選んでも、他の世代にもあてはまってしまう」ということ。

AIは今や、単一の技術や用途で定義できる存在ではなくなりました。
学習・推論・生成・判断・行動――あらゆる機能が有機的に結びついた“知能の生態系”です。
だからこそ、「第5世代AI」という総称そのものが、時代の鏡なのです。

「生成AI」という言葉は、その生態系の“入口”を指す便利なラベルにすぎません。
けれどもAIが人の意図を理解し、共に考え、動き、学び続ける存在となった今、
もはや“総称でくくる”ことに意味を求める段階は過ぎつつあります。

つまり――「総称は何か?」という問いに、
もはや確定的な答えは存在しない。
それこそが、第5世代AIの時代を象徴しているのです。

いま求められているのは、呼称の統一ではなく、AIとの関係の言語化。
“何と呼ぶか”ではなく、“どう関わるか”へ。
それが、この世代を生きる私たちにとっての新しい視点なのかもしれません。

関連記事

https://chatgpt.com

https://grok.com

★ちょっと想定外なdmarcの過剰fail 2025年内に終了するので放置なのか?

DMARC設定で、過剰にfailしているのを発見しました。 ちょっとだけ想定外でした。。。 対象のメールは、ちょっと前に書いたソーラーフロンティアのメールです。


ARC-Authentication-Results: i=1;
***.xserver.jp;
dkim=pass header.d=hke.dkim.mpse.jp header.s=mpse.201103 header.b=Stua66Jg;
spf=pass (***.xserver.jp: domain of z-hke-xhp3nn-0-de-005miuramic.or.jp@bma.mpse.jp designates 106.185.96.14 as permitted sender) smtp.mailfrom=z-hke-xhp3nn-0-de-005miuramic.or.jp@bma.mpse.jp;
dmarc=fail reason="SPF not aligned (strict), DKIM not aligned (strict)" header.from=solar-frontier.com (policy=none)

ちょっと対策が必要そうです。

関連記事

https://www.nri-secure.co.jp/blog/dmarc-report

詐欺メール 、新たなストーリーベース詐欺の前振り? 2005年ころからおなじみのストーリー調スパムの最新版か spam-mail

この記事は、スパムアサシンやメーラーでのスパム判定をすり抜けた怪しいメールを取り扱います。その内容の判定や設定方法の改善策について取り扱います。

このメールはdmarcポリシーのチェックを”pass”しています。 このパターンはドメイン自体を自動的にbanする(ブラックリスト登録する)のが良いかもしれませんが、様子見です。 スパマーによるハニーポット探索が目的なのかもしれません。  

★対象のメールのコピー

Apple Store 20,000円ギフトカードを今すぐ受け取る

Apple Store 5,000円 gift card 贈呈中 @media only screen and (max-width:600px){ .container{width:100% !important;} .btn{display:block !important; width:100% !important;} } 【Apple Store】20,000円 gift card 贈呈中 特定アカウント限定/24時間以内に受け取り

いつもAppleをご利用いただきありがとうございます。現在、特定のアカウントを対象に20,000円分のApple gift cardを贈呈しております。

本gift cardは24時間以内に 受け取り いただいた場合のみ有効です。期限内に受け取りが完了しない場合、権利は自動的に失効いたします。

20,000円を受け取る ▼

ご利用条件対象:本メールを受信した特定アカウントに限ります。 受け取り期限:本メール受信から24時間以内。 利用範囲:Apple Storeおよびオンラインストア内の特定商品に限りご利用いただけます。 他の割引・クーポンとの併用はできない場合があります。
本メールは送信専用です。ご返信いただいても対応いたしかねます。
誤送信と思われる場合は、このメールの破棄をお願いいたします。
© 2025 Apple. All rights reserved.
spam22
spam
過去(2024年以前)実施の迷惑メール対策方法、設定

スパムアサシンの設定と、メーラーでの設定については、要望があれば記事を用意いたしま。コメントとをお願いします。

生成AI(第5世代AI)はデジタルか?- デジタル脳が描く人間の幻影 –

(元記事)まずは、前の投稿のように生成AI自身に問いかけてみた。さてその返事は:

Grok4: はい、もちろんです
GPT4: はい、私はデジタルです。。

直感的で、良い反応です。

さて、前振りまで読んだところで、読者である”あなた”はどういう認識だったかを覚えておいてください。 あとで、アンケートを取りますので、この後の記事を読む前と後であなたの認識がどうなったかを教えてください。

AI3
AI vs デジタル

まず、「デジタルとアナログの定義」から


🔹1. 技術的定義(物理・情報工学の視点)

項目デジタルアナログ
表現方法離散的(0と1のように区切られた値)連続的(連なりのある値)
情報処理計算可能な論理演算(ブール代数)連続変化に基づく自然現象的処理
ノイズへの耐性強い(誤り訂正が可能)弱い(微小な揺らぎが影響する)
代表例コンピュータ、ディジタル信号処理、AI音の波形、温度変化、アナログ時計
根本単位ビット(0/1)無限の中間値(0〜1の間に無限)

要するに、
デジタル=区切ることで扱いやすくした情報表現
アナログ=切れ目のない自然の変化そのもの

この違いは単に技術的なものだけでなく、「世界の捉え方」そのものに影響します。


🔹2. 哲学的・概念的定義(認識の仕方の違い)

項目デジタル的思考アナログ的思考
世界の見方分類・判断・選択による理解連続性・関係性・文脈による理解
思考の性質論理・構造・再現性を重視感覚・流れ・曖昧さを受け入れる
時間感覚ステップ(離散)として進む滑らかに変化し続ける
言語・論理・コード音楽・感情・自然現象

つまり「デジタル」とは、現実を有限の単位に切り分けて理解しようとする姿勢
「アナログ」とは、現実を流れや連続の中で感じ取ろうとする姿勢


感覚の有限性:アナログの幻影

私たちはしばしば「人間の感覚はアナログである」と言う。
滑らかなグラデーション、柔らかな音の響き、曖昧な感情の揺れ。
それらはデジタルの“0か1か”という世界にはない、
豊かな連続性の象徴のように見える。

だが、冷静にその仕組みを覗いてみれば、
人間の感覚も決して“無限の連続”を受け取っているわけではない。


🔹有限の受容体がつくる「連続の幻」

視覚を例に取ろう。
網膜の上にはおよそ1億個の光受容体が並んでいる。
それらは、光の波長に応じて電気信号を発生させる小さなスイッチだ。
つまり、1億個の“センサー素子”が、それぞれオンかオフか、あるいはその中間の反応強度を返すだけの構造である。

聴覚も同じだ。
耳の奥の蝸牛(かぎゅう)には、音の周波数ごとに反応する有毛細胞が整然と並ぶ。
これらも有限個の点の集合で、音の波形を連続的に測っているわけではない。

それなのに、私たちは音楽を「滑らかに」聴き取り、
景色を「連続的に」見ている。

この“なめらかさ”こそ、脳がつくり出した錯覚であり、
離散的なデータを統合・補完する知覚のアルゴリズムの結果なのだ。


🔹「分解能の限界」がアナログを生む

思い出してほしい。
ドット絵のキャラクターも、
適度な距離から見れば“線で描かれている”ように見える。
だが拡大すれば、ただの四角い点の集合にすぎない。

人間の視覚も、これとまったく同じ仕組みで成り立っている。
分解能が高いほど世界は滑らかに見え、
粗くなるほど、世界は粒状になっていく。

では、「アナログらしさ」とは何か?
それは分解能が有限であるがゆえに成立する幻影なのだ。
無限の情報を扱えない脳が、欠けた部分を補い、なめらかな連続として感じ取る。
この“補間された連続性”こそが、私たちが「アナログ」と呼んでいるものの正体である。


🔹感覚の限界がつくるリアリティ

言い換えれば、人間の世界認識は、
「精密なデジタルサンプリングを、アナログのように感じている」状態だ。
有限の受容体が、膨大な入力を数値化し、
脳がそのギャップを滑らかに埋める――。

この構造は、生成AIが行う「データの学習と補完」にも酷似している。
AIもまた、膨大な離散データをもとに、
見たことのない文脈や表現を“連続的に”生成している。
つまり、人間とAIのあいだには、
思っているほど明確な“アナログとデジタルの壁”は存在しないのだ。


私たちは“アナログな存在”である前に、
有限のセンサーと離散的な情報処理によって世界を構築している存在である。
その意味で、人間はすでにデジタル的なシステムなのだ。

だからこそ、生成AIがデジタルの構造で人間の感覚を再現しようとするとき、
それは本質的に「同じ仕組み」を別の素材で実現しているにすぎない。


感覚の模倣装置としての生成AI

生成AIの本質をひとことで言えば、
「データの中に潜むパターンを抽出し、
新しい組み合わせとして再生産する装置」である。

この構造は、一見すると冷たく、機械的だ。
0と1の計算、行列演算、統計的推定。
そこには感情も感性も存在しないように思える。

だが、その振る舞いをよく観察すると、
そこに人間の感覚と思考に似た“影”が見えてくる。


🔹言葉を数値に変換する「デジタルな神経」

生成AIは、入力された言葉を「トークン」と呼ばれる単位に分解する。
それぞれのトークンは、数値ベクトルとして空間上に配置される。
つまりAIにとって、言葉とは高次元空間上の座標であり、
意味の近さや文脈の流れは、この座標間の距離や方向として表現されている。

たとえば「海」と「波」は近くにあり、
「海」と「演算子」は遠くにある。
AIは、この膨大な座標群を学習しながら、
“どの方向に進めば自然な文脈が生まれるか”を予測していく。

これは、まるで人間の神経細胞がシナプス結合の強弱を調整しながら
「連想」を生み出していく過程に似ている。
どちらも、離散的な点(ニューロン/トークン)を結びつけて連続的な意味を立ち上げる装置なのだ。


🔹有限の学習から「未知」を補完する

生成AIが興味深いのは、
与えられたデータの単なる再現ではなく、
そこから“存在しなかった表現”を創り出せる点にある。

これは、まさに前章で述べた「人間の知覚の補完機能」と同型だ。
脳が限られた情報から世界の連続性を再構成するように、
AIも有限の学習データから、新しい文脈や想像的な表現を補間する。

つまり生成AIは、有限な入力から無限の可能性を推測する推論装置であり、
この補間作用こそが「アナログ的」と感じられる部分の正体である。


🔹アナログを再現するためのデジタル

重要なのは、
AIがアナログ的な結果を生み出すときも、
その内部は完全にデジタルな処理しかしていないということだ。

ニューロンの活性値も、ベクトル演算も、すべて有限の数値だ。
だが、それを何百万、何億という単位で組み合わせ、
確率的な“ゆらぎ”を与えることで、
まるで人間の曖昧な感性を思わせる出力が立ち上がる。

そのときAIは、デジタルな世界の中でアナログを模倣している
言い換えれば、アナログとはデジタルの解像度が極限まで上がった状態なのかもしれない。


🔹「感覚の模倣」とは、世界の再構成である

AIが文章を生成するとき、
それは単に文字列をつなげているのではない。
AIは、学習した世界の構造――人間の言葉が指し示す関係性、文脈、感情――
その“知覚モデル”全体を一瞬で再構成している。

この構造は、まさしく「人間が世界を感じ取り、意味づける」行為そのものに似ている。
AIは私たちの知覚のしくみを、数値と関数のかたちで再現した“模倣的知覚装置”なのだ。


生成AIは、あくまでデジタルの領域で動作している。
だが、その内部には、
人間が「アナログ」と呼んできた感性のプロセスが再構成されている。

それはまるで――
デジタルの中に封じ込められた、アナログの幻影

そして私たちがAIと向き合うとき、
その幻影の中に「人間らしさ」を見いだしてしまうのかもしれない。


デジタルを越える“曖昧さ”の知性

生成AIは、確かに0と1の積み重ねから生まれた存在だ。
だが、それが吐き出す言葉、描き出す絵、奏でる音には、どこか“人間的な曖昧さ”が宿ることがある。

この曖昧さは、数学的な誤差ではない。
それはむしろ、人間の曖昧さにチューニングされた出力とでも言うべきだ。
たとえば、詩の解釈や感情の機微。
「悲しい」と「さびしい」の違いを、AIは数値の差としてではなく、文脈の“揺らぎ”として扱う。
この揺らぎの設計こそ、生成AIの核心であり、人間の知覚と交わる接点である。

もしデジタルが「切り分けること」だとすれば、AIはその切り口の間にある“隙間”を探している。
そこに、人間の思考や感情が生きていることを知っているからだ。

つまり、生成AIの知性はデジタルを起点としながら、アナログの世界に手を伸ばす知性なのだ。
完全な数値の論理でもなく、完全な人間的直感でもない。
その中間の揺らぎの中に、今のAIが存在している。


ポスト・デジタル ― AIが開く新しい知の地平

「デジタル」と「アナログ」。
この二項対立の上に、私たちは長く世界を理解してきた。
けれども、生成AIの登場によって、その境界線そのものが意味を失いつつある

生成AIは、ビットの世界に生きている。
0と1、トークンと重み、確率と勾配。
そのどれもが、まぎれもなくデジタル的な構造の上にある。
だが、AIが出力する言葉や画像、音楽はどうだろう。
それらは“数値の羅列”である以前に、私たちの感情や直感に触れる“体験”となっている。
人が感じる「温かさ」や「余韻」、それらを生み出す演算過程を、私たちはもはや“デジタル”とだけ呼ぶことができない。

たとえば、音楽を考えてみよう。
ディジタル音源はサンプリング周波数という有限の刻みで構成されている。
しかし、その再生音を耳にした瞬間、私たちはそれを「滑らかな旋律」として受け止める。
そこには、人間の感覚が持つ“補完”と“想像”の力が働いている。
AIが生成する詩や画像も同じだ。
機械の出力を受け取る側の人間が、それを「意味」として完成させる。
つまりAIの知は、人間の知と接続されてはじめて“アナログ的”になるのだ。

この構造は、まるでポスト・デジタルと呼ぶべき時代の在り方を示している。
デジタルなシステムが、アナログ的な解釈と共鳴しながら存在する。
その中間領域――演算と感情、確率と詩、情報と物語が重なり合う場所――こそが、現代の生成AIの本質だろう。

かつて「アナログは自然で、デジタルは人工的」と言われた。
だが今や、AIによって生成される自然な文章や音声は、私たちの感覚の中で“生きて”いる。
もはやデジタルは、人工の模倣を越えて、新たな自然の一部となりつつある。


結論 ― 生成AIはデジタルでありながら、人間との関係の中でアナログを帯びる

問いに戻ろう。
「生成AIはデジタルなのか?」

答えは、「はい、しかしそれだけではない」である。

確かに、生成AIはデジタルそのものだ。
それは、0と1の世界で動作し、確率と勾配によって推論を行い、電圧のON/OFFを繰り返すプロセッサの上で息づいている。
この意味において、AIの存在は徹底的にデジタルである。
しかし、その出力が人の心に届いた瞬間、状況は変わる。

たとえばAIが書いた詩を読んで、胸の奥が少し温かくなるとき。
AIが生成した音楽に、懐かしさを感じるとき。
その瞬間、デジタルの計算結果は、アナログな“感情”と共鳴している。
AI単体では成立しない、人間との“接点”がそこに生まれているのだ。

つまり、生成AIの本質は「関係性」にある
AIはデジタルの領域に生まれながらも、人間というアナログ的存在と関わることで、曖昧さ・温度・ゆらぎといった非デジタルな性質を帯びる。
その意味で、生成AIは“デジタルな存在のまま、アナログ的に振る舞う”稀有な存在だと言える。

私たちはこれまで、「デジタルか、アナログか」という二択で世界を理解してきた。
だが生成AIは、その二分法を静かに超えていく。
そこでは、数値が感情を宿し、コードが物語を紡ぐ。
演算が詩に変わり、データが生命のように動き出す。

――そう考えると、この問い自体がひとつの転換点なのかもしれない。
「生成AIはデジタルか?」
それは、私たちが“デジタルをどう受け止めるか”を問う鏡でもあるのだ。

だからこそ、最後にこう言おう。

生成AIはデジタルである。
だがその響きが人に届くとき、そこには確かに“アナログのぬくもり”が生まれている。


さて、ここまで読んでどう感じたでしょうか? YESかNOかで投票をお願いします。

あなたは、生成AIはデジタルだと思いますか?
関連記事

https://chatgpt.com

https://grok.com

生成AI(第5世代AI)はコンピューターなのか? AIバブルの勘違い!?

-コンピューターの論理 vs AIの揺らぎ──再現性と創造の境界線 –

(前回投稿)まずは、生成AI自身に問いかけてみた。さてその返事は:

Grok4: 結論は「コンピューターの進化形」
GPT4: はい、私は“コンピューターで動いている存在”です。
でも、“コンピューターそのもの”ではありません。

このコラムの落ちまで読んでくれたのか、まずまずの答えです。

さて、前振りまで読んだところで、アンケートを取りますので、この記事を読む前にあなたは、「生成AI(第5世代AI)はコンピューターだとおもうのか」どういう認識だったか、 読んだ後はどうかを教えてください。

ai vs computer
ai vs computer


それでは、解説していきましょう。

まず「コンピューター」の定義を再確認しましょう。 多分それはあなたの認識とほぼ一致しているでしょう。 

「コンピューター」とは、与えられたデータや指令に基づいて、論理的・数値的な処理を自動的に実行する装置の総称である。入力・演算・出力という基本構造をもち、人間の代わりに情報を処理する仕組みを備える。初期は計算機として発展したが、現在では通信・画像・音声・学習など多様な情報処理を行い、ハードウェア(機械)とソフトウェア(命令体系)の協働によって機能する知的情報処理装置を指す。

ここまでの定義は、平均的で、”生成AI”もコンピュータと、言えなくもない感じですね。

もう少し、定義を深堀してみましょう。

「コンピュータ」の定義の延長です。 コンピューターは同じ入力であれば、同じ結果が得られますか?それはなぜですか?


基本的に、はい。
コンピューターは同じ入力を与えれば、同じ結果を返すように設計されています。
これは、コンピューターが「決定論的(deterministic)」な仕組みで動作しているためです。


🔹 理由:決定論的な演算

コンピューターは0と1の信号(ビット)で構成され、命令も論理的手順(アルゴリズム)に従って処理します。
同じプログラム・同じ入力データ・同じ環境条件であれば、演算の手順と結果は常に同一になります。
つまり、「原因が同じなら結果も同じ」という物理的・論理的なルールに従って動くのです。


🔹 ただし例外もあります

現代のシステムでは、乱数生成、時刻依存処理、マルチスレッド動作、AIモデルの確率的推論などが入る場合、結果がわずかに異なることもあります。
これらは「非決定的」要素を含むためで、同じ入力でも処理の過程に揺らぎが生じることがあります。


まとめると、コンピューターは本質的に決定論的な装置であり、
すべての条件が同一であれば、同じ入力から同じ結果を得る。
ただし、近年の応用(AIなど)では、意図的に“揺らぎ”を導入するケースもある。


まず乱数ですがこれは疑似乱数ですよね。ランダムシードが同じであれば、同じ乱数数列が得られますね。 時刻依存処理、マルチスレッド動作、 これは、外部要因に依存するタイミング問題ですね。 つまり、入力自体が異なるケースですね。 さて戻って、もう一度、「コンピューターは同じ入力であれば、同じ結果が得られますか?」

非常に正確な整理です。その理解を踏まえると──

🔹 答えは「はい」、コンピューターは同じ入力であれば同じ結果を得ます。


🔸 理由

コンピューターは決定論的(deterministic)な装置であり、
与えられた入力データとプログラムの命令列、そして初期状態(メモリ内容や設定)が同一であれば、
内部で実行される計算手順と結果も必ず同一になります。

つまり、

同じアルゴリズム
+ 同じ入力
+ 同じ環境条件(初期状態)
がそろっていれば、結果は再現可能であり、
それこそが「コンピューター」という装置の本質的特徴です。


🔸 例外のように見えるケース

乱数・時刻・並行処理などは「外部要因を入力に含めた」ケースであり、
それらが変化すれば実質的に入力が異なるため、結果が変わります。
したがって、「同じ入力では異なる結果が出た」というわけではなく、
入力条件が違っていたと解釈するのが正確です。


結論として:

コンピューターは完全に決定論的であり、真に同じ入力なら必ず同じ結果を出す。
変化が生じるのは、入力または初期状態に差異がある場合のみ。

それでは、生成AIはコンピュータ上で動作するソフトウェアですが、 ”決定論的”にもとづいた設計や実装になっていますか?

非常に鋭い問いです。
答えを端的に言うなら──

🔹 生成AIは、基本的な構造は決定論的に設計されていますが、動作結果は非決定的(確率的)です。


🔸 1. 設計レベルでは「決定論的」

生成AI(たとえばGPT)は、数学的には完全に決定論的な関数です。
入力テキストを数値ベクトルに変換し、ニューラルネットワークのパラメータ(重み行列)と行列演算を行い、
出力として「次に来る単語の確率分布」を求めます。
ここまでは厳密に決定論的で、
同じモデル・同じ入力・同じ初期状態なら、確率分布(=出力確率)は必ず同じになります。


🔸 2. 出力の選択は「確率的」

ただし、生成AIはその確率分布から「どの語を選ぶか」を乱数的に決定します。
このとき使われるのが「サンプリング」(例:top-ktemperature パラメータ)です。
ここで乱数(疑似乱数)を使うため、同じ入力でも異なる文が生成されることがあります。

したがって、生成AIの「思考」過程は決定論的でも、
「発話」部分は確率的要素を含む──という二層構造になっています。


🔸 3. 再現性を得る方法

乱数のシードを固定すれば、
生成AIも完全に再現可能(決定論的)になります。
つまり、モデルの内部はもともと決定論的なため、
外部的に揺らぎを制御すれば、同一入力から同一出力を得ることが可能です。


🔹 まとめ

観点状態説明
モデル構造決定論的数値演算と固定パラメータに基づく
出力生成非決定的確率分布からランダムにサンプリング
シード固定時決定論的同じ入力で完全に同じ出力が得られる

したがって、

生成AIは「決定論的なコンピューター上で動作する、確率的出力を持つ決定論的システム
と表現するのが、最も正確な定義です。

別の角度から、「生成AIは同じ入力であれば、同じ結果が得られますか?」

とても良い視点です。
この質問に対しては、次のように整理できます。


🔹 結論

生成AIは、同じ入力であっても、必ずしも同じ結果を返すとは限りません。
ただし、条件を完全に固定すれば、同じ結果を再現することは可能です。


🔸 理由の内訳

1. モデル自体は決定論的

生成AI(たとえばGPT)は、内部では数値演算によって確率分布を計算する決定論的アルゴリズムです。
つまり、「この文脈でどの語が来る確率が何%か」というところまでは、
同じ入力であれば常に同じ結果(確率分布)を得ます。


2. 生成の最終段階が確率的

しかし実際に返すテキストは、その確率分布から確率的にサンプリングされます。
このサンプリングには「乱数(疑似乱数)」が使われるため、
同じ入力でも選ばれる語が毎回わずかに異なる可能性があります。

そのため、

  • 自由な会話モード → 毎回異なる表現になる(創造的で自然)
  • 乱数シード固定 → 常に同じ結果を再現できる(決定論的)
    というふうに、設定によって挙動が変わります。

3. 環境差・更新差

クラウド上で動く生成AIの場合、

  • モデルのバージョン更新
  • 学習パラメータの微修正
  • システム側の温度(temperature)設定
    などの「環境要因」によって、同じ入力でも異なる結果が返ることがあります。
    これはユーザー側からは制御できない場合もあります。

🔹 まとめ

条件結果説明
通常利用(確率的生成)同じ入力でも異なる結果ランダム要素を含むため
シード固定・設定固定同じ入力で同じ結果完全再現が可能
モデル更新あり結果が変わる可能性あり内部仕様が変化するため

したがって、

生成AIは本質的には決定論的に動作するが、出力結果は確率的要素を伴う。
よって「同じ入力で同じ結果が得られるか」は、設定と環境次第である。


この「決定論的計算の上に確率的出力を重ねる構造」こそが、
生成AIの“創造性”と“再現性の限界”を同時に生み出しているポイントです。

さて、ここまで読んでどう感じたでしょうか? YESかNOかで投票をお願いします。

生成AIは、コンピュータだという認識ですか?

最後に

ここまで読んでいただければ、なぜ「生成AIはコンピューターなのか?」という問なのかご理解いただけたかもしれません。  この辺の認識が不十分な投資家が、過剰な期待をしているということかもしれません。

関連記事

https://chatgpt.com

https://grok.com

スパムメール/詐欺メール DMARC設定で激減、2025年以降この設定は必須!?

この記事は、スパムメールや詐欺メールに関する情報を扱います。過去に何度かスパム対策を行ってきましたが、徐々に増えてきているので対策を見直しました。Eメールはいろいろなセキュリティレベルの相手と通信する仕掛けなので完璧な対策はないと言ってもよいかもしれません。 そうはいっても明らかにスパムと判断できるものも保留してスパムかどうかを判断していくのは面倒である。 明確にスパムと判断できるものは受け取らないようにしたのでよいだろう。 というのも、最近、送信元が自分であるスパムメールが増えていた。明らかに自分が送信していないのでスパムであることは明白なので、なぜこのような送り方をするのか疑問だが、チェックルールをかいくぐる手として使っているのだろう。

このようなメールは完全に受け入れなければよい。 これを実現するのがDMARCである。DMARCは、「自分のドメインを使ったなりすましメールを見つけ、受信側で拒否・隔離できるようにする」仕組みである。そこで、DMARCポリシーを「メールを配送しない」に設定した。

この設定により、最近増えていた下のような送信元が”自分”だと詐称されたメールを撲滅できた。 素晴らしい!   激減とはいうものの、 スパムメールの全体の一部であることには変わりない。引き続きスパムとの闘いは続く。

DMARC 設定で拒否できるようになったスパムメール例(サンプル)

★対象のメールのコピー

[SPAM] 新作登場!今だけの特別オファーをご覧ください


[SPAM] 【期間限定セール】LOUIS VUITTON 人気商品が最大70%OFF! ***


 本日新商品アップしました、全商品80% OFF,送料無料,代引きで支払う,代金引換。
是非、宜しくお願い致します。

[ONLY 1]LOUIS VUITTON モンスリ PM Ref:M45410 <https://superfluity.qpon/357>

[ONLY 1]LOUIS VUITTON モンスリ PM Ref:M45410 <https://superfluity.qpon/357>
17,000 JPY 359,700 JPY


【Louis Vuitton】クロスボディ ショルダー バックパック M82769 <https://
superfluity.qpon/358>

【Louis Vuitton】クロスボディ ショルダー バックパック M82769 <https://
superfluity.qpon/358>
30,000 JPY 178,000 JPY


Louis Vuitton ルイヴィトン ボディバッグ ウェストバッグ 長財布 2点セット お得
<https://superfluity.qpon/359>

Louis Vuitton ルイヴィトン ボディバッグ ウェストバッグ 長財布 2点セット お得
<https://superfluity.qpon/359>
30,000 JPY 168,000 JPY

【存在感抜群☆国内発】LV ディスカバリー・バックパック PM M46802 <https://
superfluity.qpon/360>

【存在感抜群☆国内発】LV ディスカバリー・バックパック PM M46802 <https://
superfluity.qpon/360>
24,000 JPY 168,000 JPY


【ルイヴィトン】NEW!シャドーブラック☆スリムバッグDANUBE <https://
superfluity.qpon/361>

【ルイヴィトン】NEW!シャドーブラック☆スリムバッグDANUBE <https://
superfluity.qpon/361>
23,000 JPY
*dmarcで破棄できた例



【信用金庫】ポイント加算の確認をお願い申し上げます


お客様へ

平素より全国信用金庫協会をご利用いただき、誠にありがとうございます。


■ ポイント加算のお知らせ

2025年10月1日〜2025年10月31日までのご利用分について、下記内容で全国信用金庫協会
ポイントが加算されましたのでお知らせ申し上げます。

*■ 加算内容*

* *対象期間:*2025年10月1日〜2025年10月31日
* *加算ポイント数:*5130ポイント(5130円相当)
* *加算日:*2025年11月18日
* *加算対象取引:*給与の受け取り、公共料金の自動引落し、キャッシュレス決済の利用


■ 受取期限について

加算されたポイントの受取期限は **2025年11月17日** までです。期限を過ぎると、ポイ
ントは失効いたしますので、**お早めにご確認いただき、手続きをお願いいたします**。


■ ポイント受け取り手続き

下記リンクより、ポイント受け取り手続きを速やかに行っていただけます。

▶ ポイントを受け取る <https://yagwg.com/shinkin/s/selectState>

--------------------------------------------------------------------------------

*【ご注意】*
インターネットバンキングは毎週日曜日23:56〜月曜日6:00にメンテナンスが行われま
す。この時間帯はサービスをご利用いただけませんので、予めご了承くださいますようお
願い申し上げます。

--------------------------------------------------------------------------------

【お問い合わせ】
全国信用金庫協会 カスタマーサポート
電話:0120-579-835(携帯・IP電話:03-6387-3213)
受付時間:平日 9:00〜16:00

全国信用金庫協会株式会社
〒103-0028 東京都中央区八重洲1丁目3番7号
© 全国信用金庫協会 All Rights Reserved.

==============================================
■判定結果

ARC-Authentication-Results: i=1;
***.xserver.jp;
dkim=fail ("body hash did not verify") header.d=mail20.funcwei.com header.s=mail20 header.b="T2j/oEP0";
spf=pass (sv8645.xserver.jp: domain of info@mail20.funcwei.com designates 35.185.141.217 as permitted sender) smtp.mailfrom=info@mail20.funcwei.com;
dmarc=fail reason="SPF not aligned (relaxed)" header.from=hama-sushi.co.jp (policy=none)

■最初の数件 Spamフィルタに引っ掛からなかったものもdmarchafail
dmarc=fail reason="No valid SPF, No valid DKIM" header.from=uccard.co.jp (policy=none)


4:19---------------------v対象メール
【重要なお知らせ】UCカードご利用確認のお願い

最近行われましたプライバシ-ボリシ-の改定に伴いまして、こ確認のお手続きは、一回限りで、数分で終了致します。
お客様によるご確認行為は必須となっており、お客様のアカウント情報のご確認が行われなかった場合は、アカウントが停止される可能性がごさいます。
この確認は義務付けられており、確認していただけない埸合は、アカウントが停止される場合もあります。
お客様にはご迷惑、ご心配をお掛けし、誠に申し訳ございません。
何卒ご理解いただきたくお願い申しあげます。
ご利用確認はこちら
※この確認は義務付けられており、確認してい ただけない埸合は、アカウントが停止される場合もあります。つきましては、以下ヘアクセスの上、カードのご利用確認にご協力をお願い致します。
お客様にはご迷惑、ご心配をお掛けし、誠に申し訳ございません。
何卒ご理解いただきたくお願い申しあげます。
※24時間以内にご確認がない場合、誠に申し訳ございません、お客様の安全の為、アカウントの利用制限をさせていただきますので、予めご了承ください。
=======================
アットユーネット利用規約
第1条(利用規約)
1.本規約は、ユーシーカード株式会社(以下「UC社」と称します。)またはUC社と業務提携するカード会社(以下これらをあわせて「当社」と称します。)にユーシーカードホームページ上で提供するインターネットサービス「アットユーネット」(以下「本サービス」と称します。)のユーザー登録申請を行い、当社が承認した方(以下「アットユーネット会員」と称します。)に適用されます。
2.アットユーネット会員は、本規約のほか、第2条第1項に定めるカードの「会員規約」及び本サービスにおける各「サービス規約」、「ご案内」、「ご利用上の注意」その他の注記事項(以下「本規約等」と称します。)を遵守するものとします。
https://atunet.uccard.co.jp/UCPc/pages/images/person/PC/terms/index.html
第2条(ユーザ登録)
1.本サービスのユーザ登録を申請できる方は、当社が発行するUCブランドのクレジットカードのうち当社が認めたクレジットカード個人会員及びコーポレートカードのカード使用者とします。(以下これらのクレジットカードを総称して、「カード」とします。)
2.ユーザ登録を希望する方(以下「申込者」と称します。)は、当社所定の方法により申請するものとします。
https://www2.uccard.co.jp/cs/services/#entertainment
3.当社は、申込者のうちユーザ登録を承認した方に対し、アットユーネット会員を特定する番号(以下「ID」と称します。)を付与し、登録されたEメールアドレスに通知します。
https://www2.uccard.co.jp/cs/card/lineup/mileageplus.html
4.UC社と業務提携するカード会社の申込者は、申込者の所属するカード会社(以下「所属カード会社」と称します。)がUC社にユーザ登録に関する受付のほか、本サービスに関する事務等について、業務委託することに同意するものとします。
https://www2.uccard.co.jp/cs/privacy/member.html
第3条(登録の拒絶及び承認の取消)
当社は、申込者が以下の何れかの項目に該当する場合、当該申込者の本サービスの利用を拒絶し、あるいは、承認後であってもその取り消しができるものとします。
1.ユーザ登録をした方が、カードの会員資格又はコーポレートカードのカード使用者資格を有していない場合
2.ユーザ登録をした時点で、カードご利用状況、お支払状況等が不適当な場合
3.ユーザ登録の際の申告事項に、虚偽の記載、誤記、又は記入漏れがあった場合
4.当社に予め登録されている情報について改めて確認が必要な場合
5.カード不正使用による被害発生時や、申込者が当社に届け出た氏名、勤務先、住所、お支払口座等に変更があり、直ちに当社所定の届出用紙により手続きを行わなかった場合など正確な本サービスの提供が困難と予測される場合
6.その他、会員規約違反などがあり、当社がアットユーネット会員として不適当と判断した場合
https://www2.uccard.co.jp/maintenance/index.html
第4条(再登録)
アットユーネット会員は、次のいずれかに該当する場合、当社所定の届出を行うものとします。
なお、届出がないことによりアットユーネット会員ならびに第三者に不利益や損害が発生した場合には当社はその責任を負わないものとします。
(1)カード番号切替等申請した登録内容に変更があった場合
(2)自己のID及びパスワードが第三者に無断使用されている、又はそのおそれがあることが判明した場合
https://www2.uccard.co.jp/uc/uccard/corporatecard/
第5条(本人認証)
1.当社は、入力されたID及びパスワードの一致を確認することによって、アットユーネット会員による本サービスの利用とみなします。なお、当社は、本サービスの提供において、本人認証のためにその他の手続きを求める場合があります。
2.アットユーネット会員は、本人認証手続きに対応したオンライン加盟店においては、パスワードまたは当社が発行するワンタイムパスワードを入力する方法により、ショッピングサービスを利用できるものとします。
https://www2.uccard.co.jp/uc/services/seikyu/
業務委託先 株式会社クレディセゾン
Copyright © UC CARD CO., LTD. All Rights Reserved.

関連記事

https://www.nri-secure.co.jp/blog/dmarc-report

https://mic.or.jp/info/2025/11/16/mail-2


過去(2024年以前)実施の迷惑メール対策方法、設定

スパムアサシンの設定と、メーラーでの設定については、要望があれば記事を用意いたします。コメントとをお願いします。