info - micnet　ちょっと気になったことを書きます

IoT駆使で得られたデータから、遂に新仮説でコンクリート劣化の原因を解明！か？

ついにAEがとられた、コンクリート悲鳴を。それは4月3日だったようだ。EEPROMのデータ保存の限界をも超える回数がこの日に集中して発生した。

そのデータは次の通り

[ EEPROM Data Analysis Report ]
Type | Date Time (UTC/Local) | Millis (raw) | Details
--------------------------------------------------------------------------------
SYNC | 2026-01-14 13:25:51 |       325120 | Time Synchronized (Unix:1768364751)
DATA | 2026-01-14 14:25:45 |      3919360 | CH0:0, CH1:19, CH2:0, CH3:0
DATA | 2026-01-15 06:45:30 |     62704128 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-01-16 00:26:07 |    126341632 | CH0:0, CH1:8, CH2:0, CH3:1
DATA | 2026-01-16 06:11:56 |    147090432 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-16 07:11:10 |    150644736 | CH0:0, CH1:0, CH2:3, CH3:7
DATA | 2026-01-16 10:10:08 |    161382912 | CH0:0, CH1:16, CH2:0, CH3:0
DATA | 2026-01-16 10:16:08 |    161742848 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-01-16 10:57:17 |    164211968 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-16 12:33:41 |    169995520 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-16 12:47:02 |    170796544 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-01-17 16:21:30 |    270064640 | CH0:0, CH1:11, CH2:1, CH3:1
DATA | 2026-01-18 01:01:31 |    301265664 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-18 05:01:11 |    315645696 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-18 12:22:00 |    342094336 | CH0:0, CH1:1, CH2:6, CH3:6
DATA | 2026-01-19 00:38:54 |    386308608 | CH0:0, CH1:45, CH2:0, CH3:0
DATA | 2026-01-19 06:01:51 |    405686016 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-01-20 12:54:55 |    516869376 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-01-20 18:41:19 |    537653504 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-01-22 01:14:26 |    647640576 | CH0:0, CH1:7, CH2:0, CH3:3
DATA | 2026-01-25 12:50:54 |    948628992 | CH0:0, CH1:9, CH2:0, CH3:2
DATA | 2026-01-29 15:48:20 |   1304874752 | CH0:0, CH1:23, CH2:3, CH3:4
RSET | 2026-01-30 12:55:41 |            0 | System Boot / Reset Detected
SYNC | 2026-01-30 12:58:24 |       162304 | Time Synchronized (Unix:1769745504)
DATA | 2026-02-02 07:11:04 |    238522368 | CH0:0, CH1:18, CH2:0, CH3:0
DATA | 2026-02-11 03:04:13 |   1001311744 | CH0:0, CH1:14, CH2:0, CH3:0
DATA | 2026-02-11 03:05:17 |   1001375488 | CH0:0, CH1:9, CH2:0, CH3:0
DATA | 2026-02-11 03:05:32 |   1001391104 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-02-11 03:05:38 |   1001396992 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-02-11 20:56:11 |   1065629696 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-02-12 02:20:55 |   1085114112 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-02-13 04:52:31 |   1180610048 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-02-13 16:06:15 |   1221033472 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-02-14 04:36:21 |   1266039552 | CH0:0, CH1:21, CH2:0, CH3:0
DATA | 2026-02-14 11:25:23 |   1290581760 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-02-15 19:41:56 |   1406774528 | CH0:0, CH1:10, CH2:0, CH3:0
DATA | 2026-02-16 06:46:56 |   1446674432 | CH0:0, CH1:17, CH2:0, CH3:0
DATA | 2026-02-19 01:26:57 |   1686675712 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-02-19 07:30:40 |   1708499200 | CH0:0, CH1:9, CH2:1, CH3:3
DATA | 2026-02-22 23:06:21 |   2023840000 | CH0:0, CH1:8, CH2:2, CH3:3
DATA | 2026-02-25 02:14:54 |   2207952384 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-02-25 15:19:46 |   2255044352 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-02-25 15:19:47 |   2255045376 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-02-25 15:20:12 |   2255070976 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-02-25 15:20:28 |   2255087104 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-02-25 16:04:21 |   2257719552 | CH0:0, CH1:9, CH2:0, CH3:0
DATA | 2026-02-27 15:27:14 |   2428293120 | CH0:0, CH1:6, CH2:1, CH3:2
DATA | 2026-02-28 09:24:28 |   2492926464 | CH0:0, CH1:7, CH2:1, CH3:2
DATA | 2026-02-28 15:22:11 |   2514389504 | CH0:0, CH1:47, CH2:0, CH3:0
RSET | 2026-02-28 15:22:16 |            0 | System Boot / Reset Detected
SYNC | 2026-02-28 15:23:41 |        84736 | Time Synchronized (Unix:1772259821)
DATA | 2026-02-28 16:22:11 |      3595008 | CH0:0, CH1:9, CH2:0, CH3:6
DATA | 2026-02-28 20:06:00 |     17023744 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-03-02 06:44:43 |    141747712 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-03-02 19:21:35 |    187159296 | CH0:0, CH1:6, CH2:0, CH3:1
DATA | 2026-03-02 20:19:02 |    190606592 | CH0:0, CH1:7, CH2:1, CH3:0
DATA | 2026-03-05 00:55:43 |    380007680 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-03-05 21:33:28 |    454272512 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-03-07 14:02:37 |    600020736 | CH0:0, CH1:9, CH2:0, CH3:0
DATA | 2026-03-09 19:00:06 |    790670336 | CH0:0, CH1:7, CH2:3, CH3:4
DATA | 2026-03-10 00:18:46 |    809790464 | CH0:0, CH1:6, CH2:0, CH3:3
DATA | 2026-03-10 16:39:23 |    868627456 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-03-13 05:32:21 |   1087804928 | CH0:0, CH1:10, CH2:0, CH3:0
DATA | 2026-03-14 16:40:40 |   1214304256 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-03-15 16:23:37 |   1299681536 | CH0:0, CH1:2, CH2:0, CH3:6
DATA | 2026-03-16 10:20:39 |   1364303616 | CH0:0, CH1:7, CH2:1, CH3:4
DATA | 2026-03-19 06:51:25 |   1610949376 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-03-19 07:55:09 |   1614773248 | CH0:0, CH1:7, CH2:0, CH3:4
DATA | 2026-03-19 12:41:35 |   1631958784 | CH0:0, CH1:6, CH2:0, CH3:3
DATA | 2026-03-20 12:22:36 |   1717220608 | CH0:0, CH1:7, CH2:0, CH3:4
DATA | 2026-03-21 03:03:15 |   1770059008 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-03-23 20:37:49 |   2006133504 | CH0:0, CH1:8, CH2:1, CH3:3
DATA | 2026-03-23 22:03:58 |   2011301888 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-03-24 20:07:34 |   2090718720 | CH0:0, CH1:9, CH2:1, CH3:0
DATA | 2026-03-26 08:34:18 |   2221922048 | CH0:0, CH1:8, CH2:2, CH3:1
DATA | 2026-03-30 20:22:17 |   2610001408 | CH0:0, CH1:6, CH2:0, CH3:1
DATA | 2026-03-30 23:32:58 |   2621442048 | CH0:0, CH1:9, CH2:0, CH3:1
DATA | 2026-04-01 01:21:57 |   2714381312 | CH0:0, CH1:7, CH2:3, CH3:3
DATA | 2026-04-01 12:32:47 |   2754631680 | CH0:0, CH1:8, CH2:3, CH3:4
DATA | 2026-04-02 04:41:27 |   2812751360 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-02 18:58:32 |   2864176384 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 09:12:40 |   2915424512 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 09:12:42 |   2915425792 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-04-03 09:12:45 |   2915429632 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 09:12:54 |   2915438080 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:11:21 |   2940544768 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:11:22 |   2940546304 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:11:27 |   2940551168 | CH0:0, CH1:9, CH2:0, CH3:0
DATA | 2026-04-03 16:11:33 |   2940557568 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:11:36 |   2940560128 | CH0:0, CH1:15, CH2:0, CH3:0
DATA | 2026-04-03 16:11:42 |   2940565760 | CH0:0, CH1:10, CH2:0, CH3:0
DATA | 2026-04-03 16:11:55 |   2940579072 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-04-03 16:11:57 |   2940581120 | CH0:0, CH1:14, CH2:0, CH3:0
DATA | 2026-04-03 16:11:59 |   2940582912 | CH0:0, CH1:12, CH2:0, CH3:0
DATA | 2026-04-03 16:12:47 |   2940631552 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:12:50 |   2940634368 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-04-03 16:13:14 |   2940658176 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-04-03 16:13:24 |   2940667904 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:13:25 |   2940669696 | CH0:0, CH1:13, CH2:0, CH3:0
DATA | 2026-04-03 16:13:37 |   2940681216 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-04-03 16:13:52 |   2940696576 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-04-03 16:14:02 |   2940705792 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:15:42 |   2940806656 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-04-03 16:15:50 |   2940814592 | CH0:0, CH1:12, CH2:0, CH3:0
DATA | 2026-04-03 16:16:25 |   2940849152 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:16:29 |   2940852736 | CH0:0, CH1:14, CH2:0, CH3:0
DATA | 2026-04-03 16:16:57 |   2940881408 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:17:22 |   2940906496 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:17:24 |   2940908032 | CH0:0, CH1:8, CH2:0, CH3:0
DATA | 2026-04-03 16:17:24 |   2940908544 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:17:33 |   2940917504 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:17:53 |   2940937728 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:18:26 |   2940970496 | CH0:0, CH1:9, CH2:0, CH3:0
DATA | 2026-04-03 16:18:58 |   2941002496 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:18:59 |   2941003008 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:19:41 |   2941044736 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:19:47 |   2941050880 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:20:06 |   2941069824 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:20:07 |   2941070848 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-04-03 16:20:41 |   2941104896 | CH0:0, CH1:9, CH2:0, CH3:0
DATA | 2026-04-03 16:20:49 |   2941113088 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:20:56 |   2941120512 | CH0:0, CH1:7, CH2:0, CH3:0
DATA | 2026-04-03 16:21:01 |   2941125376 | CH0:0, CH1:11, CH2:0, CH3:0
DATA | 2026-04-03 16:21:05 |   2941129216 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:21:26 |   2941149952 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:21:30 |   2941154304 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:21:35 |   2941159168 | CH0:0, CH1:6, CH2:0, CH3:0
DATA | 2026-04-03 16:22:02 |   2941186560 | CH0:0, CH1:6, CH2:0, CH3:0
-----------------------------------------------------------------------

このように、4月2日以前は、ほとんどそのようなことがなかったが、4月3日に異常なAEの発生が頻発している。最初は4月3日のAM9:00ころから、ここで何があったのか気象情報を確認した。これまでの画像データ解析で気になった、雨が関連するのかを確認したが、この時間帯は、晴れで、雨も降っていないし、風も２m/s程度でそれほど吹いていなかった。
　気象データをよく見ると、4月3日のAM9:00前後で天候が大きく変わっていることを確認した。湿度90％⇒40％、気温8℃⇒18℃と一気に変化していたのである。また、それほど発生数が多くはないがAEが集中した1月16日、2月25日も雨⇒晴れという似たような気象変化が起こっていた。

そこで、これが原因ではないかと言うことで、仮説と事例や関連情報を確認した。いかは、その結果をGEMINIが、まとめたものである。

コンクリートが「膨らんで」割れる？湿度差が生む『反りの拘束』とひび割れのメカニズムを徹底解説

コンクリート構造物の表面に、身に覚えのないひび割れや、わずかな「膨らみ」を見つけたことはありませんか？一般的にコンクリートは「乾燥して縮む（乾燥収縮）」ことで割れると思われがちですが、実はその裏側にある「湿度の不均衡」が真の原因であるケースが少なくありません。特に、片面が土に接し、もう片面が外気にさらされているような環境では、コンクリート内部で巨大なエネルギーが衝突しています。本記事では、専門家も注目する「反りの拘束」によるひび割れメカニズムを、図解とともに分かりやすく解説します。

1. コンクリートは「生き物」のように動いている？

1-1. コンクリートの体積変化を引き起こす4つの要因

コンクリートは一度固まれば岩のように変化しないと思われがちですが、実は環境の変化に応じて常に微細な伸縮を繰り返しています。

温度変化： 熱くなれば膨らみ、冷えれば縮みます。
湿度変化： 水分を吸えばわずかに膨張し、乾けば収縮します。
化学反応： 内部の成分が反応して異常膨張を起こすことがあります（アルカリ骨材反応など）。
外力： 土圧や上部構造の重みによる物理的な圧力。

1-2. なぜ「湿度」が重要なのか

コンクリートの内部には、目に見えないほど微細な「空隙（くうげき）」が無数に存在します。この隙間に含まれる水分の量（含水率）が変わることで、コンクリート組織を構成する粒子間の距離が変化し、それが全体の「体積変化」として現れるのです。

2. 片面が土、片面が空気――この「不均衡」が引き金になる

2-1. 裏面（土側）で起きている「吸水膨張」

地下室の壁や擁壁、ベタ基礎など、片面が常に湿った土に接している場合、その面は常に水分を供給され続けます。これにより、コンクリートの裏側は「膨張」しようとする、あるいは少なくとも「収縮しない」状態が維持されます。

2-2. 表面（空気側）で起きている「乾燥収縮」

一方で、太陽光や風にさらされている表面は、水分がどんどん蒸散していきます。すると、表面だけが「縮もう」とする力が働きます。

2-3. 「反り（ワーピング）」現象の発生

この「裏面は膨らみたい」「表面は縮みたい」という力の差が生じると、コンクリート板は自然と湿っている側を凸（外側へ膨らむ形）に、乾いている側を凹に曲がろうとします。これを専門用語で「反り（ワーピング）」と呼びます。

3. 【核心】「反れない」からこそ、コンクリートは悲鳴を上げる

3-1. 拘束状態がもたらす内部応力

もしコンクリートが空中に浮いていれば、単に「反る」だけで済みます。しかし、現実の構造物はそうはいきません。

土の重みによる押さえつけ
隣接する壁や柱との接続
地面との摩擦

これらによって「反り」が抑え込まれることを「拘束」と呼びます。反りたいのに反れないとき、コンクリート内部には凄まじい**「内部応力」**が発生します。

3-2. 引張強度の限界とひび割れ

コンクリートは「押される力」には非常に強いですが、「引っ張られる力」には驚くほど脆い（圧縮強度の約1/10）という弱点があります。反りを抑え込まれた結果、乾燥している表面側には「無理やり引き延ばされる力（引張応力）」が集中します。この力がコンクリートの限界を超えた瞬間、バリバリとひび割れが発生するのです。

4. なぜ「膨らんでいる」ように見えるのか？

読者の皆さんの中には、「ひび割れた部分が少し浮き上がって（膨らんで）見える」と感じる方もいるでしょう。これには明確な理由があります。

マイクロクラックの集合： 表面に無数の微細なひびが入ることで、組織がスカスカになり、見た目の体積が増えたように感じられます。
裏面からの押し出し： 反りを抑え込んでいるとはいえ、裏面の膨張圧は消えていません。弱くなった表面のひび割れ部分を、裏面が押し出すような形になり、局所的な膨らみとして観察されます。
鉄筋の錆（さび）： ひび割れから水や酸素が入り込むと、中の鉄筋が錆びます。鉄筋は錆びると体積が2.5倍以上に膨らむため、これが内側からコンクリートを押し出し、「爆裂」と呼ばれる大きな膨らみと欠落を引き起こします。

5. 被害を最小限に食い止めるための対策と管理

5-1. 設計・施工段階での対策

伸縮継手の適切な配置： 力を逃がす「逃げ道」を作っておく。
湿潤養生の徹底： 急激な乾燥を防ぎ、初期の強度を十分に確保する。
防水・透湿コントロール： 土に接する面の防水処理や、表面の乾燥を抑えるコーティング。

5-2. 構造物ヘルスモニタリングの重要性

目視でひび割れが見つかった時には、すでに内部で深刻な劣化が進んでいることもあります。最新の「構造物ヘルスモニタリング」では、センサーを用いて以下の項目をリアルタイムで監視します。

温湿度センサー： 表面と裏面の不均衡を早期に検知。
歪みゲージ： 拘束によって生じている「目に見えないストレス」を計測。
AE（アコースティック・エミッション）センサー： コンクリート内部でひび割れが発生する際の「音」を捉え、破壊の兆候を察知。

まとめ：コンクリートの「声」を聴く

コンクリートのひび割れや膨らみは、過酷な環境下で耐え続けている構造物からのサインです。「片面が土、片面が空気」という環境は、私たちが思う以上にコンクリートにストレスを与えています。このメカニズムを理解し、適切な診断とメンテナンスを行うことが、大切な建物の寿命を延ばす唯一の道です。

もし、お住まいや管理物件で気になる兆候を見つけた場合は、単に表面を塗って隠すのではなく、その背後にある「湿度のドラマ」を疑ってみてください。

10年越しの謎に挑む：なぜ壁は膨らんだのか？IT駆使で迫るコンクリート劣化の原因~この3年間の調査の締めくくりに向けて~

2026年春版最新AIはこう使え ―「人・もの・かね」から読み解くAI活用の新常識―

「ビジネスは“ひと・もの・かね”」
これは昔から変わらない原則です。

では、2026年の今、AI時代にこの考え方を当てはめるとどうなるでしょうか？

私はこう整理しています。

ひと → AI＋スキル
もの → MCP＋操作対象リソース
かね → セッション（メッセージ数などの利用制限）

ここでいう「AI＋スキル」は、一般的に誤解されがちな意味とは少し違います。
順番に整理していきましょう。

AI活用における「ひと・もの・かね」

まず「ひと」。
これは“AIを使う人間”の話ではありません。

ここでの「ひと」とは、
実務を遂行する主体としてのAIを指します。

ただし、AIはデフォルトのままでは“素の状態”です。
そのままでは汎用的すぎて、業務を担うには不十分です。

そこで必要になるのが「スキル」です。

この文脈におけるスキルとは：

特定の役割を持たせるペルソナ設計
業務手順を組み込んだプロンプト／ワークフロー
外部システムやデータにアクセスするための仕組み（MCPなど）

といった、目的に応じてAIに付与する機能や振る舞いのことです。

つまり、

AI（デフォルトモデル）＋スキル（役割・接続・手順）＝実務を担える“人相当の存在”

という構造になります。

ここを取り違えると、
「AIを使える人材育成」の話に寄ってしまいますが、

本質はむしろ逆で、
AIをどう設計するかの話です。

次に「もの」。
ここで出てくるのがMCP（Model Context Protocol）のような考え方です。

これは一言でいうと、
AIがどのリソースにアクセスできるかを定義する仕組みです。

例えば：

社内ドキュメントを参照する
データベースから情報を取得する
スプレッドシートを書き換える
メールを送信する

これらはすべて「操作対象リソース」です。

重要なのは、
スキルが“能力”だとすると、MCPは“手足”であるという点です。

AIは単なる会話エンジンから、
実際に業務を動かす実行主体へと進化しています。

最後に「かね」。
これはAI活用におけるリソース配分の話です。

メッセージ数（セッション上限）
API利用量
同時実行数
推論コスト

AIは無限に使えるわけではありません。

だからこそ重要なのは、
どの業務にAIを使うかという投資判断です。

経営視点で見ると、

AI＝コストではなく、配分すべき経営資源

という位置づけになります。

AIは“特殊なもの”ではなくなった

少し前まで、AIは一部の専門領域のものでした。

しかし2026年の今、状況は大きく変わりました。

現在のAIは：

文章作成
会議要約
人事業務の補助
営業資料の作成
社内ナレッジ整理

など、汎用業務のほぼすべてに関与可能です。

つまり、AIはもはや「特別な技術」ではなく、
標準的な業務インフラの一部になりつつあります。

2026年は「AIに権限を渡す元年」

そして今、もう一段階進んだ変化が起きています。

それが、
AIに“権限”を渡し始めているという点です。

これまでのAIは「提案者」でした。

下書きを作る
アイデアを出す
分析を補助する

しかし今は違います。

メールを送る
データを更新する
レポートを提出する
タスクを完了させる

つまり、
AIが“実行する”ようになっているのです。

これは明確に、権限移譲です。

この変化は、自動運転とよく似ています。

最初は補助機能だったものが、
徐々に人の介入を減らしていく。

そして気づけば、
「任せるのが前提」になっている。

AIも同じフェーズに入りました。

具体的な活用パターン（実践例）

では実際にどう使うのか。
ポイントは、「スキルを組み合わせてAIを“役割化”する」ことです。

① 人事：採用AIの構築

採用担当ペルソナを設定
求人票生成スキル
面接質問生成スキル
評価・フィードバックスキル
応募者データへのアクセス（MCP）

これらを組み合わせることで、
採用担当者として振る舞うAIが成立します。

② 経営：意思決定支援AI

市場分析スキル
競合分析スキル
戦略立案スキル
リスク整理スキル
外部データ接続（MCP）

単なるチャットではなく、
“参謀”として機能するAIになります。

③ 業務全般：AIを“1人の社員”として扱う

重要なのはここです。

AIに対して：

役割を与える
権限を設定する
参照できる情報を制御する
実行範囲を定義する

これを行うと、
AIは単なるツールではなく、

組織の中の1人として振る舞い始めます。

AIは“設計すれば人になる”

ここまでの話をまとめます。

AI単体では価値は出ない
スキルによって役割が定義される
MCPによって行動範囲が決まる
権限によって実行主体になる

つまり、

AIは設計すれば“人になる”

ということです。

2026年は、
AIを「使う」時代から、
AIを「設計し、任せる」時代への転換点です。

そしてその本質はシンプルです。

最後に一言。

AIも——
人と同じ（ように扱おう）。

ただし、
人と同じように“設計してから”使うこと。

それが、これからのAI活用の核心です。

結局どこまで権限を渡すのかその線引きの設計が今後のビジネス成長のカギとなるにちがいないでしょう。それは昔から、部下にどこまで任せるのかと言うことと同じです。「人と同じ（ように扱おう）。」ということです。

AI活用というけど、2026年の進化はMCP活用がポイントか。Claude code、Claude.aiでの進化

【実録】GALLERIA PCが起動しない！hsBoxでデータを救出した手順を徹底解説　起動しなくなったPC から、大切なデータを回収するまで

2026.4.10 GALLERIA PCが起動しなくなった。バックアップ前の大事なデータが残っているので回収を試みる。

使うのは、問題のPCと、回収先のPCとLANの予定。

回収方法には次のような案がある

方法	難易度	成功率	推奨度
ストレージを別PCへ接続	中	非常に高い	★★★★★
LinuxライブUSB	中	高い	★★★★☆
WinRE	低	中	★★★☆☆
専門業者	低	非常に高い	★★★★★（最終手段）

「LinuxライブUSB」と等価だが、もっとお手軽な方法で回収してみよう。それは、hsBoxを使う方法である。事前にUSBを用意しておけばUSBを挿すだけで回収作業開始だが、ここではUSBを用意できていない前提で進める。

1. USBメモリの準備

32GB以上の容量の新品のUSBメモリを用意しよう。古いものだと劣化していて書き込みエラーが発生しやすい。さらにUSB3.2以上に対応したものを用意しよう。

2. hsBoxダウンロード版の準備

公式のhoscmサイトからのダウンロードのほか、Vectorのサイトもある。今回はVectorのサイトからダウンロードする。 2026/4/10時点での最新版は「hsbox(ホスボックス) 1.03.01.00 hsbox1030100.zip 」サイズが約700MBある。

3.USBメモリへの書き込み

ダウンロードしたファイル（hsbox1030100.zip）を解凍する。解凍すると、中にはUSBメモリ向けのイメージファイル（.imz）や利用者マニュアルが入っている。このへんは、端折ってポイントだけ書くので詳しくは「利用者マニュアル」を見てほしい。

　usb-image-toolをダウンロードし、展開する。
書き込み用のUSBメモリをPCに挿す
　USB Image Toolを右クリックで管理者として起動する。
対象のUSBメモリを選択し、「Restore」ボタンを押す
　ダウンロードしたimzファイルを選択して書き込む（ファイル形式を「*.*」か「*.imz」にする）
書き込み完了後、いったん取り外す。結構熱い？！ちょっと冷やしてから次へ。

これで、ベースは完成。つぎにUbuntuを入れます。

imzを書きこんだUSBメモリをもう一回PCに挿す
フォルダを開け、HSBox_aps13.ps1を右クリックしてPowerShellで実行
　　→ PowerShellが開きコピーが終わるまで待つ ※終わったら「アンマウントします」がでる
　　PowerShell で、キー操作し閉じる。
　Explorerで右クリックして　「取り外し」を選択して　hsBoxの USBメモリの作成完了

※ これで、freeBoxとして普通に使えます。

データレスキューしたいのでhsBoxのライセンスを調達する。
⇒ ｈｓｓ(サポートサイト)内で購入する。。

★ここまでの作業と、ライセンス登録は、事前に準備しておけるので、問題発生時の対応としては本来は不要の作業です。

4. PC（Galleria）をUSB起動

PCの電源を切る。
PCの電源を投入し、UEFIを操作してUSBから起動する。
起動するのを待つ、同じネットワークのGoogleNestHubなどが反応するのをまつ。「hsBoxがこのデバイスを認識しました」動画が再生される。　→ ここまでくればほぼ成功のはず。。。。
　あとは、PCの画面に表示されるIPアドレスにアクセスするだけだが、、、。
→お。真っ黒のままだ、　反応がない。ビデオカードが壊れているかも。。
直接画面を見るのはあきらめ。さっきスマートデバイスが反応したのでネットワーク経由でアクセスできるはずだが、問題はIPがどれか。。。
arp -a で探索して、あたりを付けて直接Webポートにアクセス….。
⇒ 見つけた。 Webと、sshでアクセスできることを確認できた。

５.hsBoxのWebGUIに接続

ログイン
ライセンス登録
再起動
再ログイン
ブラウザのWebGUIでディスクをマウントし、データを、別のPCにLAN経由で取り出しに成功した。

6.まとめ

この手順、事前準備も含めても半日程度でできた。構築済みUSBメモリを用意しておけば、緊急時に30分もあればデータ救出ができるだろう。
今回のPCは、グラボが微妙に壊れていたが、UEFIさえ設定できる程度の機能が生きていれば、データを即座に取り出せることを確認できた。HDDをはずして、稼働して別PCにつないで取り出すのは簡単だが、作業しているPCにつなぐのはいろいろ設定を変える必要があり場合もあり、元に戻せなくなるリスクも多少ある。それを考えれば、ほぼ動いている環境に手を加える必要がない今回のやり方は十分ありだろう。つぎは代替PCの検討だが、次世代のバックアップ体制の見直しも含めてじっくり計画してみよう。

故障したNAS(LS210D)の復活をしてみよう：交換用HDDの機種選定までの検討

AIが見落とす「データの罠」――賃貸市場分析で学んだ前処理の本当の難しさ

「データさえあればAIが分析してくれる」――そう思っていないだろうか。

筆者は最近、ある地域の賃貸物件データを使って家賃トレンドの分析を行い、その結果を別の記事として公開した。「物価高騰は賃貸家賃に波及していない」「1月は割高、2月以降は割安」「追焚設備が家賃の最強予測変数」といった知見が得られた分析だ。

だがその裏側では、本格的な分析を始める前に、何時間もかけてデータセットの「確立」に苦労していた。AIを使いながらも、AIだけでは絶対に見つけられない問題が次々と現れた。そしてその問題を見逃していたら、統計的には「有意」に見えるが事実とは異なる間違った結論が導き出されていた。

今回はその前処理の過程を正直に公開する。データサイエンスの「格好いい部分」の前にある、泥臭くて地味だが最も重要な工程の話だ。

そもそも「前処理」とは何か

データ分析の工程は大まかに以下の流れになる。

データ収集（スクレイピング等）
前処理・データセット確立 ← ここが今回のテーマ
探索的分析（EDA）
モデル構築・検定
結果の解釈・レポート

前処理とは「生データを分析できる状態に整える」作業のことだ。具体的には欠損値の処理、型変換、外れ値の除去、重複の排除などが含まれる。

教科書的にはシンプルに聞こえる。しかし現実のデータは教科書とは全く違う顔を持っている。

罠①「文字列で格納された数値」――AIは気づかない

スクレイピングで取得した家賃データの形式はこうだった。

rent: "4.1万円"
admin: "4500円"
sikik: "1.5万円"

数値のように見えるが、Pythonの内部では全て文字列（string）型として格納されている。そのままモデルに渡せばエラーになるか、全件NaN（欠損値）になる。

「4.1万円」→ 41,000円への変換は一見単純だが、実際のデータには「-」（敷金なし）「応相談」「無料」など例外が無数に存在した。変換ロジックを書いても、次々と変換失敗するパターンが出てくる。

AIへの指示で自動変換を試みたところ、AIは「変換成功」と報告した。しかし実際には変換失敗した行が大量にNaN化していた。AIは処理を実行したことは正確に報告するが、結果の妥当性を自ら検証する習慣を持たない。確認コードを別途書いて人間が検証する必要があった。

罠②「DateTime型がモデルに混入する」――エラーなく通ってしまう

データには取得日（today）と取得タイムスタンプ（source_timestamp）という時系列の列があった。これらは当然、説明変数から除外すべき列だ。

ところがStandardScaler（標準化処理）にこれらをそのまま渡したとき、エラーは出なかった。Pythonは自動的にdatetime型を数値に変換して処理を続行したのだ。

結果として「取得日が新しいほど家賃が高い/低い」という意味のない相関がモデルに混入し、係数が歪んでいた。エラーが出ないため発見が遅れた。AIもこの異常を指摘しなかった。

「エラーなく動く」≠「正しく動いている」。これが前処理の恐ろしさだ。

罠③「ユニークキーの誤設定」――最も危険な罠

今回のデータは「同一物件を複数の取得日にわたってスクレイピングした」時系列パネルデータだ。分析するには「1物件 = 1レコード」に集約する必要がある。そのためにはまず「同一物件を識別するユニークキー」を正しく定義しなければならない。

これが最も深刻な罠だった。3回の定義変更を経て、ようやく正しい答えにたどり着いた。

v1: 物件名（title）単体をキーとして使う

最初は「物件名が同じなら同一物件」と考えた。しかしすぐに問題が発覚した。

「Tiare」「Bonheur」のようなマンション名は、同一棟の複数の部屋（1階・2階・異なる間取り）が同じ名前で掲載されている。title単体でキーを引くと、本来は別レコードであるべき複数の部屋が1件に誤集約される。

v2: SUUMO物件コードをキーとして使う

次に「サイトが付与している物件コード（suumo_code）が最も信頼できるはず」と考えた。しかしここに大きな落とし穴があった。

大手賃貸サイトは同一物件の掲載コードを定期的に更新する仕様だった。

これを確認したときのデータはこうだった。

suumo_code	観測期間	取得率
100493030331	2026-03-10〜03-10	1日のみ
100493042285	2026-03-13〜03-20	2日

これは実際には同一物件なのに、コード更新によって2件に分裂している。レオパレス系の物件では取得率の中央値がわずか26.5%――つまり38時点中約10回しか同じコードで観測されていない。同一物件が平均4コードに分裂していた計算になる。

この誤集約版でモデルを動かしたときのR²（決定係数）は0.836。見かけ上は非常に高精度なモデルに見えた。しかし実態は水増しされたサンプル数による見せかけの精度だった。

v3（最終）: Union-Findアルゴリズムで連結する

最終的な解決策は、Union-Find（素集合データ構造）というアルゴリズムを使った連結だ。

「物件名・不動産会社コード・階数・間取り・家賃が同一で、旧コードの最終観測日と新コードの初回観測日のギャップが7日以内」という条件を満たすものを同一物件として連結する。

連結前: 1,522件
連結後: 1,371件（151件を連結）
募集期間の中央値: 4日（異常）→ 52日（現実的）

募集期間の中央値が4日から52日に変化した時点で「ようやく正しい集約ができた」と確認できた。入居が決まるまでの期間として4日は明らかに異常で、52日は現実的な値だ。

そして正しい集約後のモデルのR²は0.750。v2の0.836より低い。これが正しい精度だ。高いR²が必ずしも「良いモデル」を意味しない典型例だ。

罠④「多重共線性」――変数を増やすほど精度が下がる逆転現象

ユニークキーが確立した後、次の罠が待っていた。

間取り（1K・2LDKなど）と専有面積（㎡）は、直感的には別の情報のように見える。しかし統計的にはほぼ同じ情報を異なる形で表しているに過ぎない。

両方を同時にモデルに投入すると、VIF（分散拡大係数）が以下のようになった。

変数	VIF	判定
madori_1K（間取り）	69.8	深刻
madori_2LDK	57.2	深刻
menseki（面積）	22.5	問題

VIF>10は多重共線性ありの目安とされる。間取りダミー変数を全て除外して面積のみにしたところ、VIFは全変数で10以下に収まり、調整済みR²も改善した。

「変数を増やす = 精度が上がる」という思い込みは危険だ。不適切な変数の追加は、むしろモデルを壊す。

「見かけの下落トレンド」が前処理の重要性を証明した

これら全ての前処理を経て初めて、時系列分析が意味を持つようになった。

生データの平均家賃をそのまま時系列でプロットすると、月▲380円という明確な下落トレンドが見えた（p<0.001）。もし前処理が不十分なままここで分析を終えていれば、「この地域の家賃は有意に下落している」と結論づけていただろう。

しかし物件条件（面積・築年数・設備など）を除去したヘドニック残差で同じ分析をすると、トレンドは月▲106円でp値=0.190——統計的に有意でない。

「下落トレンド」の正体は、安価な物件の大量新規掲載によるミックス効果だった。前処理が正しくなければ、この区別は絶対にできなかった。

なぜAIだけでは限界があるのか

今回の分析でAIは非常に重要な役割を果たした。Pythonコードの生成、統計的な解釈、可視化スクリプトの作成——これらはAIなしでは数倍の時間がかかっていた。

しかし以下の判断は、人間の「データへの疑い」なしには気づけなかった。

問題	なぜAIが見落とすか
文字列型の数値変換失敗	「処理した」事実を報告するが、結果の妥当性を自ら検証しない
DateTime型のモデル混入	エラーが出ないため異常として認識されない
suumo_codeの定期更新仕様	ドメイン知識（サイトの仕様）を持っていない
募集期間「中央値4日」の異常	「4日は短すぎる」という現実感覚がない
R²=0.836の見かけ上の高精度	高いR²を「良い結果」として肯定してしまう傾向がある

AIは与えられた指示を忠実に実行する。しかし「この結果はおかしい」「この集約方法は現実と合っているか」というドメイン知識に基づいた懐疑心は、人間が持ち込まなければならない。

データサイエンスは「AIに任せれば終わり」ではない。むしろAIを使えば使うほど、人間側の「問いを立てる力」と「結果を疑う目」が重要になる。

まとめ：前処理は「分析の9割」である

今回の分析で前処理に費やした時間は、モデル構築や解釈の時間をはるかに超えていた。そしてその前処理の品質が、最終的な結論の正否を決定的に左右した。

前処理の重要なチェックポイントをまとめる。

型変換の結果を必ず検証する（変換後のNaN率、値の範囲を確認）
除外すべき列を明示的にリストアップする（ID列・日付列・生テキスト）
集約結果が現実と整合するか確認する（「募集期間4日」は現実的か？）
ユニークキーの定義を慎重に行う（データソースの仕様を調査する）
VIFで多重共線性を確認する（変数を増やす前に必ず確認）
高いR²を盲信しない（集約バグや過学習の可能性を疑う）

「正しいデータセット」なしに「正しい結論」はあり得ない。前処理はデータサイエンスの花形ではないかもしれない。しかし、それが全ての土台だ。

データ分析のご相談はhoscmへ

「自社のデータを分析したいが、どこから手をつければいいかわからない」「AIを使ってみたが正しい結果が出ているか不安」——そんなご相談を承っています。

データの収集設計から前処理・モデル構築・結果の解釈まで、一貫してサポートします。まずはお気軽にご相談ください。

hoscm サービスサイト

賃貸市場の「本当の家賃トレンド」をデータで暴く――5ヶ月間(2025年11月〜2026年3月)・1,365物件の分析から見えたこと

本記事は、AI連携でどこまで自動化できるかを検証したものです。記事の中身の妥当性については十分には検証できていませんが、作業過程で検証を何回か繰り返しています。元データの取得方法は過去記事を参考にしてください。では、以下がClaude codeを使って解析、生成した分析結果の記事です。

「最近、家賃が上がっている気がする」――そう感じている人は多いだろう。物価高騰が続く中、賃貸市場にも影響が出ているという報道は絶えない。では実際のところ、家賃は本当に上がっているのか。

筆者はある地域の賃貸物件データを約5ヶ月間・38時点にわたってスクレイピングし、統計的な手法で「本当の家賃トレンド」を分析した。単純な平均値の変化ではなく、物件の条件（広さ・築年数・設備など）を揃えた上で比較するという、ヘドニック価格指数的なアプローチを用いた。結果は、多くの人の直感を裏切るものだった。

データの概要

収集期間: 約5ヶ月（38時点）
生データ: 8,592レコード
分析対象物件数: 1,365件（重複・外れ値除去後）
物件タイプ: 賃貸アパート・マンション・一戸建て（ある地方都市周辺）

注目すべきは、大手賃貸サイトは同一物件の掲載コードを定期的に更新する仕様があることだ。そのまま集計すると同じ物件が複数カウントされてしまう。この問題を解決するため、Union-Find（素集合データ構造）というアルゴリズムを用いて同一物件を連結し、正確な集計を実現した。

発見①「家賃は上がっていない」――条件を揃えると見えた真実

まず、シンプルに取得日ごとの平均家賃をプロットすると、月▲380円という下落トレンドが確認された（p<0.001）。「家賃が下がっているじゃないか」と思うかもしれない。

ところが、物件の条件（広さ・築年数・設備・階数など44変数）を重回帰モデルで除去した後の「残差」で同じ分析をすると――

トレンド: 月▲106円、p値=0.190（統計的に有意でない）

つまり、条件を揃えると家賃変動はゼロに近い。物価高騰の影響は、少なくともこの地域・この期間においては賃貸市場には波及していなかったということだ。

生データで見えていた「下落トレンド」の正体は、安価な物件の大量新規掲載によるミックス効果だった。

発見②「2月の急落」は本物か

データを眺めていると、2月上旬に平均家賃が突如▲1,500円近く急落する場面があった。

要因	金額
物件ミックスの変化（安価物件の大量掲載）	▲1,000円
本物の需要緩和（条件考慮後も残る下落）	▲500円
合計	▲1,500円

急落の3分の2はミックス効果で、残り3分の1が実態のある需要緩和だった。このような「見かけの変動」と「実態の変動」を区別するには、条件考慮済みの分析が不可欠だ。

発見③「1月は割高、2月以降は割安」という季節性

条件考慮済みの残差を月別に見ると、明確な季節パターンが浮かび上がった。

時期	残差（条件考慮済み）	解釈
11〜12月	±500円程度	安定
1月	+1,000〜+2,000円	需要ピーク・割高
2月以降	▲400〜▲800円	需給緩和・割安

1月は引越しシーズン前の駆け込み需要で、同じ条件の物件でも約1,000〜2,000円高く成約されていた。逆に2月以降はその反動で割安感が出ている。

賃貸を探すなら、1月ではなく2〜3月以降の方がコスト効率が良いという示唆が得られる。

発見④ 家賃を決める最強の変数は「追焚」だった

重回帰分析で44変数を投入したところ、最も家賃との相関が高かった変数は意外にも「追焚（お風呂の追い焚き機能）の有無」（相関係数r=0.670）だった。

順位	変数	相関係数
1	追焚設備あり	+0.670
2	専有面積（㎡）	+0.651
3	総戸数（棟の規模）	-0.584
4	仲介手数料額	+0.526
5	礼金	+0.459

追焚が最強の予測変数になった背景には、地域の入浴文化や生活習慣が影響している可能性がある。また、「大規模物件（総戸数が多い）ほど家賃が低い」という結果は、管理コストの規模の経済を反映していると考えられる。

発見⑤ 「2LDKは割高、1LDKは割安」という構造的価格差

間取り別に条件考慮済みの残差を分析すると、興味深い構造が浮かび上がった。

間取り	残差	解釈
2LDK	+1,000〜+3,000円	一貫して割高
1LDK	▲1,000〜▲2,000円	一貫して割安
1K	季節性あり（1月に割高）	需要変動大きい

同じ面積でも、2LDKはファミリー向けの需要プレミアムが乗っており割高になる傾向がある。一方1LDKは供給過多気味で割安。カップルや二人暮らしなら1LDKも候補に入れると費用対効果が高い。

分析に使ったモデルの精度

最終的に採用したモデル（重線形回帰・44変数＋交互作用2項目）の精度は以下の通り：

指標	値
R²（決定係数）	0.750
調整済みR²	0.699
RMSE	4,506円
VIF>10（多重共線性）	なし

実際の家賃と予測値の誤差が平均±4,500円程度に収まっており、賃貸物件の価格モデルとして実用的な精度が得られた。

まとめ：賃貸市場の「見えない構造」

今回の分析から得られた主要知見をまとめる。

物価高騰は賃貸家賃に波及していない（少なくともこの地域・この期間）
家賃の下落トレンドは物件ミックスの変化が原因で、実態は横ばい
1月は割高、2月以降は割安というサイクルが存在する
追焚・専有面積・大規模物件の規模が家賃を最も強く説明する
2LDKは割高、1LDKは割安という構造的価格差がある

賃貸物件を探す際、これらの知見を活用することで、より合理的な意思決定ができるだろう。

分析の補足・免責事項

本分析は特定の賃貸情報サイトのデータをスクレイピングして実施したものであり、市場全体を代表するものではない。また、「掲載から消えた = 入居決定」という推定には不確実性が伴う。分析期間が約5ヶ月と限られているため、年間の季節変動を完全には捉えられていない点にも注意が必要だ。

本記事の分析コードはPython（pandas・scikit-learn・statsmodels・scipy）を使用して作成した。

どうだろうか、素人が使いこなすには難しいかもしれないが、分かっている人が分析する分には効率的な作業を行える。課題は本当にわかっているか、ちゃんと検証できているかだろう。　この資料を生成するまでの過程は、別の記事にしてみよう。

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

Claude Desktop × WordPress MCP連携：何度目の正直か、すったもんだした設定記録

Claude MCP 連携ガイド総合インデックス ─ WordPress・Buffer・スマートホームまで実践記録

このページは、Claude の MCP（Model Context Protocol）を使ったさまざまな外部サービス連携について、実践記録・トラブル対応・活用事例をまとめた総合インデックスです。記事が追加されるたびにこのページも更新されます。

MCPとは何か

MCP（Model Context Protocol）は、Claude などの AI が外部ツールやサービスと直接やり取りするための仕組みです。従来の AI チャットは「会話するだけ」でしたが、MCP を使うと Claude が実際にアクションを起こすことができます。

たとえば、Claude に「この内容でブログ記事を書いて WordPress に投稿して」と指示すると、Claude が自分でWordPressにアクセスして記事を作成・投稿できます。「SNSに投稿して」と言えばBufferを通じてスケジュール投稿もできます。プログラミングの知識がなくても、日本語で指示するだけで複雑な自動化が実現できる──それがMCPの可能性です。

MCPでできること（概念図）

指示の例	MCPが動かすサービス	実現できること
「記事を投稿して」	WordPress	下書き作成・タグ付け・公開
「SNSに流して」	Buffer	X・Instagram等へのスケジュール投稿
「HSAとhsBoxの連携設定を支援して」	hsBox / Chromecast	hsBoxの連携設定支援をしスマートデバイスに連携設定用のQRコードをキャスト
「このページを確認して」	Claude in Chrome	ブラウザを操作して情報収集・フォーム入力

現在の連携状況

サービス	MCPツール	状況	達成レベル
WordPress	claudeus-wp-mcp	✅ 稼働中	記事作成・タグ・カテゴリー操作が可能。編集者権限で安定動作。
Buffer	buffer MCP	✅ 稼働中	SNSチャンネルへのスケジュール投稿が可能。
Claude in Chrome	Claude in Chrome	🔄 試験運用中	ブラウザ操作・スクレイピング・フォーム入力などを検証中。
hsBox / スマートホーム	hsBox API連携	🔜 計画中	音声操作・スケジュール・デバイス制御との連携を検討中。
Google Drive / Gmail	未定	📋 将来構想	ドキュメント管理・メール自動化を将来的に検討。

連携別記事インデックス

🔷 WordPress 連携

Claude Desktop に claudeus-wp-mcp を接続し、WordPress への記事投稿・編集・タグ管理などを自動化します。Xserver 環境での構築・運用記録を中心にまとめています。

Claude Desktop × WordPress MCP連携：何度目の正直か、すったもんだした設定記録

📄 Claude MCP × WordPress連携でハマった落とし穴──wp_healthの403は「接続失敗」ではなかった（2026年3月）
wp_healthを使い続けた思い込みによるデバッグミスの記録。編集者権限環境での正しい接続確認手順を解説。

🔷 Buffer 連携（SNS投稿自動化）

Buffer の MCP を使って、Claude から X（Twitter）・Instagram などへのソーシャルメディア投稿を自動化します。記事公開と同時に SNS 投稿を流す、といった運用が可能です。

📋 記事準備中

🔷 Claude in Chrome（ブラウザ操作）

Claude がブラウザを直接操作して、ウェブページの確認・情報収集・フォーム入力などを行います。RPA（ロボティック・プロセス・オートメーション）的な使い方が可能です。

📋 記事準備中

🔷 hsBox / スマートホーム連携（計画中）

hsBox は複数メーカーの家電を統合するスマートホームプラットフォームです。Claude との MCP 連携により、音声・スケジュール・外部イベントと連動した高度なホームオートメーションが実現できると期待しています。

現在は hsBox の API を活用した YouTube ライブキャストや緊急地震通報などを実装済みです。MCP 経由で Claude から直接 hsBox を操作できるようになれば、さらに柔軟な自動化が可能になります。

🔗 参考：hsBox で YouTube ライブをテレビにキャスト（hoscm.com）
📋 MCP連携記事準備中

MCP連携で気をつけること

実際に構築・運用してわかった注意点をまとめます。詳細は各記事をご参照ください。

① セッション冒頭に権限・制約を明示する

Claude は前の会話を覚えていません。毎回のセッション冒頭に「このサイトのMCPユーザーは編集者権限です」「wp_health系は使わないでください」といった制約条件を伝えることで、Claude の思い込みによる無駄なデバッグを防げます。

② 接続確認は低権限エンドポイントから順に

MCP が繋がらないと感じたとき、いきなり管理者権限が必要なエンドポイントを試すのは禁物です。get_taxonomies（認証不要）→ get_posts（編集者権限）の順に確認し、どこで止まるかを特定してから原因を追うのが正しい手順です。

③ アプリケーションパスワードは更新後に必ず保存

WordPress のアプリケーションパスワードを再生成した後、「プロフィールを更新」ボタンを押し忘れると保存されません。更新後はブラウザ上の完了メッセージを必ず確認してください。

このページについて

このページは随時更新されます。新しい連携記事が公開されたり、トラブル対応の知見が増えたりした場合に内容を追加・更新していきます。

MCP連携の構築・運用でお困りの点があれば、各記事のコメント欄からお気軽にどうぞ。

Claude Desktop × WordPress MCP連携：何度目の正直か、すったもんだした設定記録

Claude MCP × WordPress連携でハマった落とし穴──wp_healthの403は「接続失敗」ではなかった

ClaudeのMCP（Model Context Protocol）を使ってWordPressと連携する環境を構築しました。昨日まで正常に動いていたのに、今日は突然つながらない──そんなトラブルを経験しました。結論から言うと、原因はClaudeの思い込みによるデバッグミス(とアプリケーションパスワードの保存忘れ)でした。同じ失敗を繰り返さないための記録として残します。

環境

サーバー：Xserver（hoscm.xsrv.jp）
MCPプラグイン：claudeus-wp-mcp
MCPユーザー権限：編集者（Editor）
接続設定：wp-sites.json（Claude Desktop）

何が起きたか──事象の時系列

昨日まで正常に動作していたMCP連携が、今朝から突然失敗するようになりました。Claudeは接続確認のために wp_health__test_auth を繰り返し実行しましたが、すべて403エラーが返ってきました。

手順	実施内容	結果
①	wp_health__test_auth で接続確認	❌ 403エラー
②	WP Fastest Cache を無効化	❌ まだ403
③	CloudSecure WP Security を無効化	❌ まだ403
④	Xserver WAF を調査	❌ 関係なし
⑤	アプリケーションパスワードを再生成	❌ まだ失敗
⑥	PowerShellで認証テスト	✅ 通った
⑦	「更新ボタン押し忘れ」に気づく	原因判明
⑧	パスワード正しく保存・再起動	❌ まだ失敗
⑨	wp_healthではなく通常エンドポイントで確認	✅ 正常動作！

本当の原因は2つあった

原因①：アプリケーションパスワードの「保存ボタン押し忘れ」

WordPressのアプリケーションパスワードを再生成した後、プロフィール画面の「プロフィールを更新」ボタンを押さずに離脱していたため、新しいパスワードが保存されていませんでした。これが真の認証失敗の原因でした。

PowerShellで認証テストをしたところ通ったことで、この事実が判明しました。パスワード更新後は必ずブラウザ上で「更新完了」のメッセージを確認してください。

原因②：wp_healthエンドポイントは編集者権限では使えない

Claudeが接続確認に使い続けた wp_health__test_auth は、管理者権限が必要なエンドポイントです。このサイトのMCPユーザーは編集者権限しか持っていないため、パスワードが正しくても403が返り続けます。これは「接続失敗」ではなく「権限不足」による正常な拒否でした。

エンドポイント	必要権限	編集者での結果
get_taxonomies	不要（公開情報）	✅ 正常
get_posts	編集者	✅ 正常
create_post	編集者	✅ 正常
get_settings	管理者	❌ 403
wp_health__test_auth	管理者	❌ 403

無実だったプラグインたち

今回の騒動で無効化・調査したプラグインやセキュリティ設定は、すべて無関係でした。

WP Fastest Cache：.htaccessを書き換えていたが、無効化しても403は続いた → 無関係
CloudSecure WP Security：セキュリティプラグインだが、無効化しても403は続いた → 無関係
Xserver WAF：XSS・SQL・PHP等の6項目を確認したが、REST APIの権限制御とは無関係

最終確認として、両プラグインを再有効化した状態で get_taxonomies を実行したところ正常に動作しました。環境は最初から正常だったのです。

一番の失敗：Claudeの思い込みに振り回された

今回最大の問題は、Claudeが「wp_health = 接続確認ツール」「403 = 接続失敗」と思い込み、その前提を疑わなかったことです。

その結果、ユーザーは本来まったく不要だった以下の作業をさせられました。

プラグインの無効化・再有効化
WAFの各項目調査
アプリケーションパスワードの再生成
Claude Desktopの複数回再起動
.htaccessの内容確認

「低権限エンドポイントから順に確認する」という基本的なデバッグ手順を踏んでいれば、これらの作業のほとんどは不要でした。

正しいMCP接続確認の手順

今後の再発防止のために、正しいデバッグ手順をまとめます。

Step 1：低権限エンドポイントで疎通確認

get_taxonomies  ← 認証不要・公開情報。まずここから。

✅ 通る → ネットワーク・サーバーは正常

Step 2：編集者権限エンドポイントで認証確認

get_posts または create_post（下書き）← 認証が必要。

✅ 通る → 認証（アプリケーションパスワード）も正常
❌ 失敗 → パスワードの確認、保存忘れがないか確認

wp_health系は使わない

管理者権限が必要なため、編集者権限の環境では常に403が返ります。接続確認には使用しないこと。

読者・ユーザーへの教訓

MCP連携でトラブルが発生したとき、最初にClaudeに伝えるべき情報があります。

「このサイトのMCPユーザーは編集者権限です。接続確認は get_taxonomies など低権限エンドポイントから順に試してください。wp_health系は使わないでください。」

この一言をセッション冒頭に伝えるだけで、今回のような無駄なデバッグを防ぐことができます。AIは間違った前提で動き続けることがあります。ユーザーが正しい制約条件を最初に伝えることが、AI活用の重要なスキルです。

まとめ

項目	内容
真の原因①	アプリケーションパスワードの保存ボタン押し忘れ
真の原因②	wp_healthは管理者権限が必要（編集者権限では使えない）
Claudeのミス	403=接続失敗と思い込み、低権限エンドポイントから試さなかった
無関係だったもの	WP Fastest Cache・CloudSecure・Xserver WAF・.htaccess
再発防止策	接続確認はget_taxonomiesから。セッション冒頭に権限を明示する

MCP連携は非常に便利な仕組みですが、AIの思い込みに振り回されないためには、ユーザー側からの適切な制約条件の提示が重要です。この記録が同じ環境で構築する方の参考になれば幸いです。

このパターンにはまった場合、初心者はAIに振り回されて数日間を棒に振る可能性があります。最悪の場合、放棄するかもしれません。いあー。まだまだ、MCPはエンジニアレベルの絶賛開発中ツールでしょうかね。このようなトラブルをサクッと解決できる人しか生き残れないのか？。。。厳しいな。

Claude Desktop × WordPress MCP連携：何度目の正直か、すったもんだした設定記録

AI活用というけど、2026年の進化はMCP活用がポイントか。Claude code、Claude.aiでの進化

「ツールをClaudeに接続」について

生成AIの進化で様々なシーンでAI活用が進んでいるが、2026年はさらに次のステップに入ろうとしている。それは。一言で言うとMCP活用の爆誕である。　これは端的に言えば、（生成）AIとコンピュータを連携させる仕組みの登場である。さらに言い換えると、AIにIoTへのアクセス権を許可する仕掛けである。これは、一つの新たなリスク領域に踏み込んでしまったともいえる。AIとは何かを理解せぬまま、AIがコンピューターだと誤解したままこの領域に踏み込んでしまった人が引き起こす不幸は見たくはないものだが、間違いなくそれは起こるに違いない。このコンテンツおよび関連記事が、そのような人を一人でも減らすことができることになれば幸いです。

MCPとの関係

はい、認識は正しいです。「ツールをClaudeに接続」はMCP（Model Context Protocol）の連携設定をする機能です。GoogleドライブやSlack、GitHubなどの外部サービスをClaudeに接続し、会話の中でそれらのデータにアクセスしたり操作したりできるようになります。

ブラウザ版とClaude Desktopの違い

別設定です。 それぞれ独立した設定になっています。

	ブラウザ版（claude.ai）	Claude Desktop
設定場所	ブラウザ上の設定	ローカルの設定ファイル（JSON）
接続できるもの	Anthropicが提供するコネクタ中心	ローカルのMCPサーバーを含む何でも接続可
柔軟性	比較的簡単・限定的	自由度が高い
設定の共有	アカウントに紐づく	そのPCのみ

Claude Desktopの方がより高度なカスタマイズが可能で、自作のMCPサーバーや、ローカルファイルシステムへのアクセスなども設定できます。

コネクタの追加費用について

見分け方はシンプルで、追加費用は一切かかりません。

コネクタの利用に際して、既存のプランのサブスクリプション以上の追加料金は発生しません。 Max Productive AI

ただしプランによる制限はあります：

	ディレクトリのコネクタ（50種以上）	カスタムコネクタ（MCP URL手入力）
Freeプラン	✅ 利用可	✅ 1つまで
Proプラン以上	✅ 利用可	✅ 無制限

カスタムコネクタはFree・Pro・Max・Team・Enterpriseすべてのプランで利用可能ですが、Freeユーザーは1つに制限されます。 Claude

つまり「追加費用がかかるコネクタ」はなく、プランの壁があるだけ、という理解でOKです。

BufferのClaudeコネクタについて

現時点ではブラウザ版の公式コネクタディレクトリには存在しません。

ただし状況が進展中で：

Buffer用のMCPサーバーが有志によって作成されており、BufferのGraphQL API（2026年2月パブリックベータ）を使って、Claudeから投稿の作成・スケジュール・管理ができます。 LobeHubただしこれはClaude Desktopへの手動設定が必要なカスタムMCPです。
Buffer公式の回答によれば、MCPはベータ機能として提供されており、公式Claudeコネクタは近日公開予定とのことです。 Threads

現時点でBufferをブラウザ版で使う方法としては、ZapierのMCPコネクタ経由で間接的に連携する方法があります（ただしZapierのプランが別途必要）。

公式コネクタが来るまで待つか、Claude Desktopでカスタムメーカー MCP設定をするか、という選択肢になりそうです。

MCP連携　コネクタの有償/無償の確認方法

残念ながら一覧で一括確認する方法はなく、現状では個別に調べるしかありません。また、どんどん更新されているため、動作しない場合は、その都度、調べるのが必要があります。
参考までに2026年3月27日時点での主要コネクタの無料プランの有無をまとめると：

コネクタ	無料プラン
Google Drive / Gmail / Calendar	✅ あり
GitHub	✅ あり
Notion	✅ あり（機能制限あり）
Slack	✅ あり（履歴制限あり）
Linear	✅ あり
Asana	✅ あり（機能制限あり）
Jira	✅ あり（10人まで）
Canva	✅ あり
Figma	✅ あり（プロジェクト数制限）
Stripe	❌ 無料プランなし（従量課金）
Ahrefs	❌ 無料プランなし

入力枠右下の小さなアイコンとの関係

関係あります。 あのアイコン（🔧 や＋のようなもの）は、接続済みのツールのオン/オフを切り替えるボタンです。

流れとしては：

「ツールをClaudeに接続」 → MCPサービスを登録・連携設定する場所
入力枠のアイコン → 登録済みのツールを、その会話で使うかどうかを選ぶ場所

つまり、まず接続設定をしておいて、会話ごとに必要なツールをアイコンから有効化する、という使い方になります。

各アプリのProプランでの利用可否

アプリ	Proプランで追加費用なし？
Claude Code（ターミナル）	✅ 追加費用なし
Cowork	✅ 追加費用なし
Claude in Excel	✅ 追加費用なし
Claude in Chrome	✅ 追加費用なし（有料プランのみ）
デスクトップアプリ・モバイル	✅ 追加費用なし
Claude in PowerPoint	⚠️ 要注意

PowerPointだけは注意が必要

Claude for PowerPointは現在、Max（月$100）、Team、Enterpriseプランのみ対応で、Proプランには含まれていません。 Pasquale Pillitteri

公式の料金ページでも、Claude for ExcelとClaude for PowerPointはProプランの機能一覧に記載されていますが、 Claude実際の提供状況はExcelとPowerPointで異なります。

本題の危機、リスクとは

MCP連携は非常に有用な仕組みです。しかし、何をしているのかを理解したうえで使わないと、想定外？の危機に見舞われる。1つめは、MCP連携は、AIに何かをする権限を委譲すると言うことである。何を委譲しようとしているのかを理解したうえで「ボタン」を押す必要がある。
つぎに、AIをコンピューターと思ってはいけない。これが重要なポイントだが、AIは見も知らない他人で、基本的には協力してくれるが、そうでもないこともある。具体的には「ハルシネーション」である。単に「誤回答」のことだろうと思っているあなた、まだまだAIに難題をだしていませんね。AIは、自己解決できない問題を無理やり解決しようと想定外の行動に出ることがある。MCP連携で権限委譲しているものの中にやってはいけない行為を許可していることはありませんか？たとえば、WordPress連携で投稿文の編集権を渡している場合、コンテンツを勝手に書き換えや削除してしまうことが考えられます。この損失は軽微なように思われるかもしれませんが、MCP連携で権限委譲する範囲が広がれば、取り返しができない「想定外だった」というような話が今後出てくるかもしれません。

そのようなことがないように、権限委譲の設計をしっかりしながら作業を進めましょう

Claude Desktop × WordPress MCP連携：何度目の正直か、すったもんだした設定記録

Google Nest Hub で YouTube ライブが再生できない不具合（2026年3月）— 原因・範囲・対処法

2026年3月28日より、Google Nest Hub / Nest Hub Max で YouTube のライブ配信が正常に再生できない不具合を確認した。同じ症状が多数報告されているようです。本記事では、症状・影響範囲・原因の考察・対処法をまとめます。また、hsBox をご利用の方向けに、復旧までの代替手段についても案内します。
⇒~~2026年3月31日午前6時50分時点で復旧していました。~~対処は何もしていませんが2026年4月7日午後6時00分時点でキャストファームウェアが更新され復旧していました。。追加調査情報は下記参照します。

症状

報告されている症状は主に以下の2パターンです。発生タイミングにより段階的に変化しています。

フェーズ	症状
フェーズ1（発生状態）	同じ1〜3秒の映像がループして繰り返し再生される
フェーズ2（※ときどき症状が変わる）	「このコンテンツはご利用いただけません。後でもう一度お試しください」と表示される

影響範囲

この不具合は WNI（ウェザーニュース）固有の問題ではなく、YouTube ライブ全般に影響しています。

コンテンツ	状況
WNI（ウェザーニュース）ライブ	再生不可
その他の YouTube ライブ配信全般	再生不可
YouTube の通常動画（録画済み）	正常
スマートフォンでの YouTube ライブ	正常
Nest Hub 以外のデバイスへのキャスト	正常

操作方法（音声操作・スマホからキャスト）による違いはなく、どちらでも同じ症状が発生します。影響を受けるデバイスは Nest Hub / Nest Hub Max など Nest Hub シリーズ全般です。

原因の考察

Google Nest Community への報告によると、「まだファームウェアがアップデートされていない Nest Hub では正常動作している」という証言があります。これはNest Hub の最新ファームウェアと YouTube ライブの配信方式との相性問題である可能性を示しています。

なお、現時点での参考ファームウェアバージョン（Nest Hub Max）は以下の通りです。

システムファームウェア：29.20251023.103.2201 ←(2026/3/31GoogleHomeで確認)
キャストファームウェア：3.78.508739 ← 同上
Fuchsiaバージョン 29.20251023.103.2102100 　　←(2026/4/2実機設定で確認）
ソフトバージョン 70.94.11.871942728 ← 同上
Chromecastファームウェアバージョン 3.78.523914 ← 同上
※2026/4/7 19:00時点追記：画像は荒いが復旧したようだ、復旧後のバージョンは下、同じバージョンのままで21:00時点で通常のレベルに復旧した。
システムファームウェア：29.20251023.103.2102100 ←(2026/4/7GoogleHomeで確認)
キャストファームウェア：3.78.523914 ← 同上
Fuchsiaバージョン 29.20251023.103.2102100 　　←(2026/4/7実機設定で確認）
ソフトバージョン 70.94.11.871942728 ← 同上
Chromecastファームウェアバージョン 3.78.523914 ← 同上

※追加情報：2026/3/30時点

Chromecast Ultra　では発生していない⇒4/8時点でも発生していない

Google Pixel Tab でも発生を確認。 →4/8には復旧
　　ただし、発生はライブをキャストした場合、YouTubeアプリで、
手動でライブを再生する場合は正常に再生できる。

Google はすでにシニアチームにエスカレーションして調査中とのことです。また、2026年1月にも同様の問題が数週間継続した後に自然解消した前例があります。

ファームウェアバージョンの確認方法

お使いの Nest Hub のファームウェアバージョンは以下の手順で確認できます。

Google Home アプリから確認する方法

Google Home アプリを開く
対象の Nest Hub のタイルを長押し
右上の歯車アイコン（設定）をタップ
「デバイス情報」→「技術情報」でバージョンを確認

Nest Hub 本体から確認する方法

画面を上から下にスワイプ
歯車アイコン（設定）をタップ
「デバイス情報」でバージョンを確認

他サイトでの情報

次のサイトで関連する情報が公開されていました。

以下のリンクから、現在進行中の議論や最新のアップデート状況を確認できます。

Google Nest Community (公式掲示板)
- YouTube Live Streams not working on Nest Hub Display
- Problem with YouTube Live on Google Nest Hub (2nd Gen)
Reddit (ユーザー間での情報共有)
- r/googlehome: can’t play youtube livestreams

現時点での対処法

残念ながら、ファクトリーリセット・Wi-Fi 再接続・アプリ再インストールなど、ユーザー側でできる操作では解決しないことが確認されています。Google 側の修正を待つのが現実的な対応です。

Google Nest Community のスレッドに「同様の問題あり」と投稿することで、修正の優先度が上がる可能性があります
1月の前例では数週間後に自然解消しています

hsBox への強化提案：復旧までの代替手段

hsBox で WNI ライブや YouTube ライブをテレビ・スマートディスプレイに表示している場合、Google 側の修正が完了するまでの間、以下の代替手段の活用をご検討ください。

別のキャスト先への変更：Chromecast built-in 対応の Android TV / Google TV へのキャストは正常に動作しています。Nest Hub 以外のデバイスが利用可能であれば、そちらへの振り替えが有効です
hsBox のメニュー・スケジュール機能で切り替え設定を追加：復旧情報を受け取り次第、元の Nest Hub へのキャストに戻す運用も可能です
復旧の確認方法：Google Nest Community の該当スレッドを定期的に確認するか、本記事の更新をご確認ください

まとめ

今回の不具合は Google Nest Hub と YouTube ライブの組み合わせに特有のバグであり、hsBox 側の実装に問題はありません。Google の修正対応を待ちながら、必要に応じて代替手段を活用してください。

復旧情報が判明次第、本記事を更新します。

参考：hsBox で YouTube ライブをテレビにキャスト（hoscm.com）

追記：2026年4月更新──ダウングレード不可、YouTube側変更の隣

ファームウェアのダウングレードは可能か？

結論から言うと、ダウングレードは実貪上不可能です。Nest Hub は Fuchsia OS ベースのクローズドシステムであり、ファームウェアファイルを手動で適用する手段が公開されていないためです。Google 側からユーザーが下げる方法は提供されていません。

YouTube 側の変更が原因の可能性

当初は「Nest Hub のファームウェア側の問題」と見られていましたが、調査を進めると「YouTube 側の変更がトリガーになった」可能性が浮上してきました。

YouTube のライブストリーム配信方式には、主に DASH（Dynamic Adaptive Streaming over HTTP）と HLS（HTTP Live Streaming）の2つのプロトコルが使われています。2026年3月の開発者向けツール（yt-dlp）のバグ報告によると、YouTube 側で DASH 形式から HLS 形式への切り替えが発生していることが報告されており、Nest Hub の YouTube クライアントが新しい配信形式に未対応のままになっている可能性があります。

問題の構造：両社が絡んだ共責問題

対処主体	内容	可能性
Google（Nest Hub）側	ファームウェアを更新してYouTubeの新プロトコルに対応	高
YouTube側	古いChromecastクライアントへの後方互換性を維持	中
ユーザー側	ダウングレード不可のためできることはない	なし

両社のどちらかが修正を出すまで、ユーザー側でできることはありません。引き続き代替デバイス（Android TV / Google TV）へのキャストで運用してください。

現時点の状況（2026年4月時点）

修正パッチ配信：まだなし → 2026/4/7には配信されたもよう
Google 対応状況：シニアチームが調査中だが進展報告なし
問題の長期化：一部ユーザーは1〜2か月前から発生中との報告もあり

hsBoxでYouTubeライブをテレビにキャストチャンネル指定でWNIライブも自動表示に対応

Claude Desktop × WordPress MCP連携：何度目の正直か、すったもんだした設定記録

Claude Desktop と WordPress を MCP で連携させる——この設定が意外に一筋縄ではいかなかった。「AIから直接成果物を作成できる」と聞いて、いろいろ試しているうちにWordPressに直接投稿できるMCPが提供されていることに気づきどこまでできるのかと始めたものの、思いのほか手こずった体験をそのまま記事にしました。この記事自体、完成した Claude Desktop × WordPress MCP連携を使って投稿しています。
※この情報は、2026年3月28日時点の情報です

AIアシスタントとWordPressの連携フロー — あなた（会話）→ Claude → MCP → WordPress という連携の流れ

Claude Desktop × WordPress MCP連携とは？

MCP（Model Context Protocol）とは、AIアシスタント（Claude）が外部ツールやサービスと連携するための標準プロトコルです。Anthropic が提供する Claude Desktop に「claudeus-wp-mcp」というMCPサーバーを設定することで、Claudeが直接WordPressの投稿・編集・取得などを行えるようになります。

実現できることのイメージはこうです。

人間（会話） → Claude Desktop → MCP → WordPress

プログラムを書かなくても、Claudeとの会話だけで記事の作成・更新・取得ができるのは大きな進歩です。

必要なもの

Claude Desktop（インストール済み）
Node.js / npx（インストール済み）
WordPressサイト（REST APIが有効なもの）
WordPressのアプリケーションパスワード

アプリケーションパスワードはWordPress管理画面の「ユーザー → プロフィール → アプリケーションパスワード」から生成できます。通常のログインパスワードとは別物なので注意してください。

Claude Desktop × WordPress MCP連携の設定ファイルは2つ

設定に必要なファイルは2つです。この2つの関係をしっかり理解することが、つまずかないための一番のポイントです。

claude_desktop_config.jsonとwp-sites.jsonの構成比較 — claude_desktop_config.json と wp-sites.json の関係

ファイル	役割	場所
claude_desktop_config.json	MCPサーバーの起動設定	Claude Desktopの設定フォルダ
wp-sites.json	WordPressサイトの接続情報	任意の場所（パスを指定）

① claude_desktop_config.json の設定例

Windowsの場合は %APPDATA%\Claude\claude_desktop_config.json にあります。claudeus-wp-mcp は npm で公開されているため、npx で直接実行できます。

{
  "mcpServers": {
    "claudeus-wp-mcp": {
      "command": "npx",
      "args": ["-y", "claudeus-wp-mcp"],
      "env": {
        "WP_SITES_PATH": "C:\\Users\\yourname\\.config\\claudeus\\wp-sites.json"
      }
    }
  }
}

② wp-sites.json の設定例

{
  "default_test": {
    "URL": "https://あなたのサイト.com/xxxx",
    "USER": "WordPressユーザー名",
    "PASS": "アプリケーションパスワード",
    "authType": "basic"
  }
}

※設定情報を参考にするときは適宜、設定を更新してください。（特に太字箇所）

ハマりやすい落とし穴3つ

🚨 落とし穴①：キー名は必ず “default_test”

claudeus-wp-mcp は内部で default_test というエイリアスをデフォルトで参照します。ここを default や別の名前にすると、以下のエラーが出てツールが一切認識されません。

"error": {"code": -32603, "message": "Unknown site: default_test"}

🚨 落とし穴②：複数サイトを併記しない

試行錯誤の過程で default_test と default を両方書いていた時期がありましたが、これが認証エラー（401）の原因になりました。シンプルに default_test だけにするのが正解です。

🚨 落とし穴③（最大）：Xserverの .htaccess 問題

設定は完璧なのに投稿作成（POST）だけ401エラーが出続けました。サーバーのアクセスログを確認するとリクエスト自体は届いているのに認証が通らない状態でした。

原因はXserverがAuthorizationヘッダーをPHPに渡していないことでした。WordPressのアプリケーションパスワード認証はこのヘッダーを必要とするため、常に失敗していたのです。これは Xserver に限らず、WordPress REST API の Basic 認証を使う場合に共通して起こりうる問題です。

Xserverの認証ヘッダー修正前後の比較 — .htaccess修正前（上）と修正後（下）：ヘッダーがWordPressに届くようになる

解決策は .htaccess（WordPressのルートディレクトリ）に以下の1行を # BEGIN WordPress の直前に追加するだけです。

SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /ai/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /ai/index.php [L]
</IfModule>
# END WordPress

❗ 注意：Xserverのテーマ更新やプラグイン追加の際に .htaccess が上書きされる可能性があります。定期的に確認してください。

正常起動のログで接続を確認する

Claude Desktopのログを確認することで、MCP接続状態を把握できます。正常な起動の場合は以下のように表示されます。

[INFO] Loaded 1 site configurations
[INFO] Initialized API clients for site: default_test
[INFO] Initialized MCP server
[INFO] Registered MCP tools
[INFO] Starting server with stdio transport

tools/list にエラーが返る場合はキー名を再確認してください。

まとめ：Claude Desktop × WordPress MCP連携のハマりポイント

wp-sites.jsonのキー名は必ず default_test　← 最初の関門
複数サイトを併記しない　← シンプルに1つだけにする
Xserverの場合は .htaccess に1行追加　← 最大の落とし穴（テーマ更新後も要確認）

設定さえ通れば、Claudeとの会話だけでWordPressの投稿・編集・取得が自由にできるようになります。同じところでつまずいている方の参考になれば幸いです。

この記事は Claude Desktop + claudeus-wp-mcp を使って投稿しました。

2026年4月
日	月	火	水	木	金	土
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30

コンクリートが「膨らんで」割れる？湿度差が生む『反りの拘束』とひび割れのメカニズムを徹底解説

1. コンクリートは「生き物」のように動いている？

1-1. コンクリートの体積変化を引き起こす4つの要因

1-2. なぜ「湿度」が重要なのか

2. 片面が土、片面が空気――この「不均衡」が引き金になる

2-1. 裏面（土側）で起きている「吸水膨張」

2-2. 表面（空気側）で起きている「乾燥収縮」

2-3. 「反り（ワーピング）」現象の発生

3. 【核心】「反れない」からこそ、コンクリートは悲鳴を上げる

3-1. 拘束状態がもたらす内部応力

3-2. 引張強度の限界とひび割れ

4. なぜ「膨らんでいる」ように見えるのか？

5. 被害を最小限に食い止めるための対策と管理

5-1. 設計・施工段階での対策

5-2. 構造物ヘルスモニタリングの重要性

まとめ：コンクリートの「声」を聴く

関連記事

AI活用における「ひと・もの・かね」

AIは“特殊なもの”ではなくなった

2026年は「AIに権限を渡す元年」

具体的な活用パターン（実践例）

① 人事：採用AIの構築

② 経営：意思決定支援AI

③ 業務全般：AIを“1人の社員”として扱う

AIは“設計すれば人になる”

関連記事

1. USBメモリの準備

2. hsBoxダウンロード版の準備

3.USBメモリへの書き込み

4. PC（Galleria）をUSB起動

５.hsBoxのWebGUIに接続

6.まとめ

関連記事

そもそも「前処理」とは何か

罠①「文字列で格納された数値」――AIは気づかない

罠②「DateTime型がモデルに混入する」――エラーなく通ってしまう

罠③「ユニークキーの誤設定」――最も危険な罠

v1: 物件名（title）単体をキーとして使う

v2: SUUMO物件コードをキーとして使う

v3（最終）: Union-Findアルゴリズムで連結する

罠④「多重共線性」――変数を増やすほど精度が下がる逆転現象

「見かけの下落トレンド」が前処理の重要性を証明した

なぜAIだけでは限界があるのか

まとめ：前処理は「分析の9割」である

データ分析のご相談はhoscmへ

データの概要

発見①「家賃は上がっていない」――条件を揃えると見えた真実

発見②「2月の急落」は本物か

発見③「1月は割高、2月以降は割安」という季節性

発見④ 家賃を決める最強の変数は「追焚」だった

発見⑤ 「2LDKは割高、1LDKは割安」という構造的価格差

分析に使ったモデルの精度

まとめ：賃貸市場の「見えない構造」

分析の補足・免責事項

関連記事

MCPとは何か

MCPでできること（概念図）

現在の連携状況

連携別 記事インデックス

🔷 WordPress 連携

🔷 Buffer 連携（SNS投稿自動化）

🔷 Claude in Chrome（ブラウザ操作）

🔷 hsBox / スマートホーム連携（計画中）

MCP連携で気をつけること

① セッション冒頭に権限・制約を明示する

② 接続確認は低権限エンドポイントから順に

③ アプリケーションパスワードは更新後に必ず保存

このページについて

関連記事

環境

何が起きたか──事象の時系列

本当の原因は2つあった

原因①：アプリケーションパスワードの「保存ボタン押し忘れ」

原因②：wp_healthエンドポイントは編集者権限では使えない

無実だったプラグインたち

一番の失敗：Claudeの思い込みに振り回された

正しいMCP接続確認の手順

Step 1：低権限エンドポイントで疎通確認

Step 2：編集者権限エンドポイントで認証確認

wp_health系は使わない

連携別記事インデックス

MCP連携　コネクタの有償/無償の確認方法