夜中のリモコン格闘からの解放

夏の夜や冬の就寝時、「27度だと寒すぎるけど、28度だと蒸し暑い…」と夜中に汗だくで目を覚まし、暗闇の中でリモコンを操作した経験はありませんか？

スマートホームが普及し、「室温が28度を超えたら冷房をオンにする」といった単純な自動化は簡単にできるようになりました。しかし、人間の「快適さ」は室温だけでなく、外気温や湿度、そして日々の体調や癖によって微妙に変化します。単純なしきい値制御では、結局「なんか違う」と人間が夜中に微調整することになってしまいます。

そこで今回は、Wifi対応のエアコン機器をRaspberry Piから直接制御し、日々の「暑かった・寒かった」というフィードバックを学習して「夜中のリモコン操作をRaspberry Piに肩代わりさせる」完全自律型スマート空調システムを作ってみました。

---

自律型スマート空調の仕組みと「朝の通勤フィードバック」

このシステムは、単なるリモコンの代わりではありません。日々のデータを蓄積し、強化学習的なアプローチで設定温度を自分専用に最適化していくのが特徴です。

1. 5分ごとの徹底的なデータロギング

Raspberry Pi上で常駐プログラムを動かし、Wifi経由でエアコンから「室外温度」「室内温度」「現在の設定温度」「運転モード」などの情報を5分間隔で取得し、12時間分のログとして記録し続けます。

2. 「状態」ごとの最適解を記録するグリッド

「外気温28度・室温26度」といった特定の状態のペアごとに、最適な設定温度を記録する「学習グリッド」を用意します。システムは現在の状態に一致するグリッドがあれば、過去の学習に基づいた最適な設定温度へ、人間が寝ている間にこっそりと自動調整してくれます。

3. 朝の通勤電車で行う「チャット問診」と学習（ここがキモ！）

毎朝、ユーザーが起床して通勤電車に乗っている時間帯に、チャットアプリ（Discordなど）経由でシステムが尋ねてきます。
「昨晩のエアコンはいかがでしたか？（1.快適 / 2.少し暑かった / 3.寒かった / 4.蒸し暑かった）」

スマホから例えば「2.少し暑かった」と返信すると、システムは昨晩の12時間のログを自動で遡ります。そして「外気温が一番高く、環境が過酷だった時間帯」を特定し、その瞬間のグリッドの目標設定温度を -0.5度だけ局所的に更新します。

4. 湿度戻り（ジメジメ）の自動回避

さらに、室温が下がって冷房が送風状態になることで発生する「ジメジメ感」も計算します。設定温度と室温のギャップ×時間を積分し、一定の閾値を超えたら自動で「除湿モード」へ切り替えるロジックも搭載。チャットで「蒸し暑かった」と回答すれば、この切り替えタイミング（閾値）も自動で早まるように学習します。

---

まとめ：人間に寄り添う真のスマートホーム

全体を一律に0.5度下げるのではなく、「外気温が〇〇度で室温が〇〇度の時だけ少し温度を下げる」というピンポイントな調整を、通勤電車のチャットを通じて繰り返すことで、数週間もすれば夜中に一切リモコンに触らなくても朝まで爆睡できる相棒が完成します。

さらに、この制御システムへの命令やログの追記はすべて、内部のローカルAPIを経由して行われるため、複数のプログラムが干渉し合わないクリーンな設計（疎結合）になっています。

毎晩リモコンと格闘する時代は終わりです。人間は朝の通勤電車で「感想」を伝えるだけ。あとはRaspberry Piが夜通し頑張って最適な空間をキープしてくれる、そんな自律型スマートホームを楽しんでいきたいと思います！

今回は、フォルクスワーゲン T-CROSSのバッテリーを標準の「LN1」サイズから、ワンサイズ大きい「LN2」へ交換（アップグレード）した際の手順と注意点をご紹介します。

導入：なぜLN2へ変更したのか

T-CROSSに標準搭載されているバッテリー（LN1サイズ）は少し容量に不安があったため、今回はより大容量で安定した電力を供給できるVARTA AGM A8（LN2サイズ）に変更することにしました。

サイズが変わることで物理的に収まるか不安がありましたが、いくつかの工夫で無事に搭載できました。

本題：バッテリーの交換手順と工夫

バッテリー交換は以下の手順で慎重に行いました。

1. 取り外しの基本ルール

バッテリーを外す際は、必ずマイナス端子から外し、次にプラス端子を外します。ショートを防ぐための鉄則です。
（※取り付ける際は逆順のプラス→マイナスになります）
車のメモリー飛びを最小限に防ぐため、端子を外したあとは素早く新しいバッテリーへ交換しました。

2. サイズ違い（LN2）への対応

LN2はLN1よりも横幅が長いため、そのままでは固定金具がうまくはまりません。
今回は、バッテリーを固定する金具の位置を「一段下」にずらして固定することで、無事にしっかりと固定することができました。

3. バッテリーカバーの妥協点

バッテリーを覆う保護カバーもLN1用のため、そのままでは全体を被せることができません。
これについては、熱の影響を最も受けやすいエンジン側のみを保護するようにカバーを配置し、妥協点としています。

交換後の状態：警告灯はついたか？

輸入車のバッテリー交換で一番心配になるのが、交換直後に点灯する「各種エラー警告灯」です。
しかし、今回の素早い交換作業が功を奏したのか、心配していた警告灯は一切点灯しませんでした。交換後もエンジンはスムーズにかかり、今のところ非常に安定して稼働しています。

まとめ

T-CROSSのバッテリーをLN1からLN2へアップグレードする作業は、固定位置の調整とカバーの工夫さえすればDIYでも十分に可能です。

• 端子の外し方は「マイナスから」
• 固定金具は一段下にずらす
• カバーはエンジン側を優先して保護

これらのポイントを押さえて、安全に作業を行ってください。（※DIYでの作業は自己責任となりますので、不安な方は専門店にご相談ください）

前回、Obsidianのデータを独立したRAGとしてMCP化し、あらゆるAIから横断検索できる「最強のマルチAI手帳」について解説しました。
今回は、そのアーキテクチャの次なる進化である「OKF（Open Knowledge Format）への対応」と「Graph RAG化」について深掘りします。

なぜ従来のRAGは「平面的」なのか？

一般的なRAGシステムでは、Markdownなどのテキストファイルを適当な長さ（チャンク）に分割してベクトル化し、AIに渡します。
しかし、これには大きな欠陥があります。AIは「検索にヒットしたテキストの断片」を受け取るだけで、「そのノートがどのプロジェクトに属しているのか」「どんな他のタスクと関連しているのか」といった『文脈の繋がり』を理解できないのです。

Google提唱の「OKF」を取り入れた解決策

そこで今回、Googleが提唱する「OKF（Open Knowledge Format）」の概念をObsidianの運用ルールに導入しました。
これは、情報を単なるテキストの羅列ではなく、「YAMLの構造化データ（メタデータ）」＋「Markdown本文」として扱うアプローチです。

具体的には、Obsidianのノートの先頭にプロパティ（YAML）を持たせ、明示的にエッジ（関係性）を記述します。

---
parent: "[[AIエージェント開発プロジェクト]]"
type: "task"
---

Graph RAGがAIに伝える「立体的な知識」

裏側で動いている自作のインポーター（Watcher）を改修し、このYAMLフロントマターから parent や related といったプロパティを抽出し、意味付きのエッジ（関係性の型） としてSQLite（Graph DB）に記録するようにしました。

そして、MCPサーバー経由でAIが検索を行った際、単にヒットしたテキストを返すだけでなく、以下のような「ナレッジグラフ構造（トポロジー）」を文字列の先頭にマッピングしてAIに渡します。

【ナレッジグラフ構造 (Knowledge Graph Topology)】
[現在のタスク] --(parent)--> [AIエージェント開発プロジェクト]
[現在のタスク] --(link)--> [関連技術メモ]

【コンテンツ詳細 (Content)】
...（ノート本文）...

AIが文脈を「理解」し始めた

この改修を行った結果、MCPを利用するAIエージェント（GonrasやAntigravity等）の推論能力が劇的に向上しました。
キーワードのマッチングだけでなく、「このタスクはあのプロジェクトの子タスクだから、全体のスケジュールに関わるな」といった、手帳内の立体的なつながり（Graph Topology）を認識した上で回答してくれるようになったのです。

単なる「AI×Obsidian」の連携から一歩進み、自分自身の脳内のリンク構造をそのままAIにインストールする。これこそが、次世代のパーソナルAIの最適解だと確信しています。

これまでの経緯

以前、運転中に突然のEPC警告灯点灯とエンジンの不調に見舞われました。原因は2番シリンダの着火不良（エラーコード：P302）であり、その際は該当するイグニッションコイルを交換することで事象は改善しました。

しかし、現在の走行距離は 約6.5万キロ。
他にも劣化している部品がある可能性が高いため、今回は予防保全も兼ねてさらなるリフレッシュを行いました。

プラグともう1気筒のイグニッションコイルを交換

前回のトラブルを踏まえ、今回は以下の部品を新品に交換しました。

• スパークプラグ（全気筒）
• もう1気筒分のイグニッションコイル

交換時の様子がこちらの写真です。

交換後の変化：すこぶる調子が良くなった！

交換を終えて走り出してみると、その違いは歴然でした。
エンジンのふけ上がりが非常にスムーズになり、すこぶる調子が良くなりました！ 振動も減り、新車時に近いフィーリングを取り戻したような感覚です。

どちらが効いたのか？

正直なところ、今回同時に交換を行ったため、「スパークプラグが良かったのか」「追加で替えたイグニッションコイルが良かったのか」、どちらが直接的に効いているのかを切り分けることはできません。

しかし、結果としてこのリフレッシュ作業は非常に有益でした。

まとめ：6.5万キロでの点火系リフレッシュはおすすめ

T-CROSSに限らずですが、走行距離が 6.5万キロ という節目を迎えた車両であれば、点火系（プラグやコイル）には相応の負担が蓄積しています。

もし「最近エンジンの振動が増えた」「少しもたつく感じがある」といった小さな不調を感じているのであれば、スパークプラグとイグニッションコイルの交換を試してみる価値は大いにあります。
その効果をはっきりと体感できるはずですので、リフレッシュの参考にしてみてください！

最近、「Obsidian（ローカルMarkdownメモ）をAIと組み合わせる」というアプローチが世間で流行っています。しかし、私が今回最もこだわり、そして到達した結論は単なる連携ではありません。
それは、「Obsidianの情報をRAG（検索拡張生成）システムとして独立させ、さらにそれをMCP（Model Context Protocol）化する」という設計です。

このアーキテクチャにより、私のObsidianは単なるメモ帳から、あらゆるAI（市販のAIツールや自作のAIエージェント）から共通して参照できる「My手帳（汎用ナレッジベース）」へと進化しました。

構成図（アーキテクチャ）

graph TD
    subgraph Obsidian_Vault [Obsidian Vault]
        NOTES[" My手帳 (Obsidian)
日々の記録・アイデア"]
    end

    subgraph Unified_RAG_MCP [Unified RAG MCP - Raspberry Pi]
        WATCHER[" Watcher
(3分待機で自動ベクトル化)"]
        VECTOR_DB[(" SQLite Vector DB
(Gemini Embeddings)")]
        MCP_SERVER[" MCP Server
(RAG検索APIを提供)"]

        NOTES -.->|ファイル更新検知| WATCHER
        WATCHER -->|見出しベースで高速チャンク化| VECTOR_DB
        VECTOR_DB <-->|検索リクエスト| MCP_SERVER
    end

    subgraph AI_Clients [AI Clients - マルチアクセス]
        ANTIGRAVITY[" Antigravity
(最先端のMCP対応AI)"]
        GONRAS[" Gonras
(日々の対話をこなす独自AI)"]

        ANTIGRAVITY <-->|ツールとしてRAGを呼び出し| MCP_SERVER
        GONRAS <-->|ツールとしてRAGを呼び出し| MCP_SERVER
    end

一般的なObsidian×AIの限界

よくある構成は、Obsidianのプラグインを使ってChatGPTを呼び出したり、特定のAIアプリにObsidianのフォルダを読み込ませたりするアプローチです。
しかしこれでは、「その特定のAI」からしか手帳を使えません。また、巨大な手帳データを毎回AIに読ませるのは非効率であり、すぐにコンテキスト（記憶枠）の限界に達してしまいます。

私がこだわった「RAGのMCP化」というブレイクスルー

そこで私は、Obsidianのデータを外部のRAG（ベクトルデータベース）として独立させました。
さらに、そのRAGシステムを話題のMCP（Model Context Protocol）サーバーとして包み込みました。これが最大のポイントです。

これにより、以下のような「マルチAIアクセス」が可能になりました。

1. 独自AIエージェント（Gonras）からの利用
   私が自作したAIエージェント「Gonras」は、私と会話する中で「あ、これは手帳に書いてあったな」と思えば、MCP経由でRAGを検索し、文脈を踏まえた返答をしてくれます。
2. 最先端AIツール（Antigravity等）からの利用
   GeminiやClaudeなどの最先端モデルを搭載したMCP対応ツールも、この「My手帳MCP」を接続するだけで、初対面なのに私の個人的な知識や背景（サーバーの設定から自転車の趣味まで！）をすべて理解したアシスタントに早変わりします。

究極の「My手帳」エコシステムの完成

• 人間はただObsidianにメモを書くだけ。
• 裏側（Watcher）がそれを自動で高速にチャンク化（意味段落に分割）し、ベクトルDBを更新。
• MCPを通じて、どんなAIエージェントも瞬時にその知識を引き出せる。

AIの進化は日進月歩で、明日にはもっと賢い新しいAIモデルが登場するでしょう。
しかし、この「RAGのMCP化」というアーキテクチャを組んでおけば、AIモデルがどれだけ変わろうと、「自分の脳（Obsidian）」をプラグのように新しいAIへ挿し込むだけで済みます。

これこそが、情報過多の時代を生き抜くための、真にポータブルで無敵な「My手帳」の姿です。

スマートフォンで写真を撮る機会が増えると、すぐに直面するのが「クラウドストレージ（iCloudなど）の容量不足」という問題です。毎月のサブスクリプション費用を節約しつつ、安全に大量の写真を保管するために、私は自宅のRaspberry Pi（ラズパイ）を活用した「自分だけの写真バックアップ環境」を構築しました。

この記事では、専門知識がない方にもわかりやすく、どのような仕組みでiPhoneから写真をローカルサーバーへ保存しているのか、具体的な構成やメリットをご紹介します。

なぜ自宅に写真保管庫を作るのか？

• 月額費用がゼロ: iCloudなどのクラウドサービスは、一定の容量を超えると毎月課金が必要になります。自宅にストレージ（HDDやSSD）を用意すれば、初期費用のみでテラバイト級の保存領域が手に入ります。
• データの手元管理: 外部サービスに依存せず、大切な思い出の写真を自分自身の管理下で安全に保管できます。
• プライバシーの保護: 写真データが意図せずクラウドのAI学習に利用されたり、流出したりするリスクを軽減できます。

構築した仕組みの全体像

graph LR
    iPhone[iPhone - Nextcloud App] -- Wi-Fi --> RPi[Raspberry Pi]
    subgraph RaspberryPiSystem
        RPi --> Storage[(External HDD)]
        RPi --> PhotoPrism[PhotoPrism - AI Gallery]
        PhotoPrism -.-> Storage
    end

    style iPhone fill:#dbeafe,stroke:#3b82f6,stroke-width:2px,color:#1e293b
    style RPi fill:#dcfce7,stroke:#22c55e,stroke-width:2px,color:#1e293b
    style Storage fill:#fef3c7,stroke:#f59e0b,stroke-width:2px,color:#1e293b
    style PhotoPrism fill:#f3e8ff,stroke:#a855f7,stroke-width:2px,color:#1e293b

私の環境では、Raspberry Pi という小型の省電力コンピューターを自宅のサーバーとして24時間稼働させ、そこに大容量のストレージを接続しています。
iPhoneからの写真転送は以下の流れで行われます。

1. アプリを使った自動アップロード

iPhoneには、「Nextcloud」や「PhotoSync」などのアプリをインストールしています。このアプリは、Wi-Fi環境に入ったタイミングで、新しく撮影された写真や動画を自動的に自宅のRaspberry Piに転送してくれます。

2. Raspberry Piでの安全な受信と保存

Raspberry Pi上では、Nextcloudサーバー（または同様のファイル共有システム）が稼働しており、iPhoneから送られてきた写真を受け取ります。受け取ったデータは、外付けの大容量ドライブに保存されます。

3. PhotoPrismを活用した美しい写真ギャラリー

単にファイルを保存するだけでは、あとから写真を見返すのが大変です。そこで私は、PhotoPrismというAI搭載の写真管理アプリをRaspberry Pi上で動かしています。
PhotoPrismは、保存された写真を自動的に解析し、被写体や場所ごとにアルバムを作成してくれます。iPhoneの「写真」アプリのように、美しく快適に過去の写真を楽しむことができます。

初心者でもできる？構築のポイント

このような仕組みを作るには、少しだけサーバーの知識が必要ですが、最近は非常に簡単になっています。

1. Dockerの活用: サーバーソフトを直接インストールするのではなく、「Docker（ドッカー）」という仕組みを使います。これを使えば、難しい設定を省いて、ブロックを組み立てるようにNextcloudやPhotoPrismを立ち上げることができます。
2. バックアップの二重化: 自宅サーバーはHDDが壊れるリスクがあります。大切な写真を守るため、Raspberry Piに繋いだ別のHDDへ定期的にコピー（バックアップ）する仕組みも用意しておくと完璧です。

まとめ

iPhoneの写真容量問題は、Raspberry Piを活用することでスマートに解決できます。最初は設定に少し手間がかかりますが、一度仕組みを作ってしまえば、あとは全自動で写真が自宅に溜まっていき、月額料金もかかりません。
「自分だけのクラウド」を作る楽しさもあるので、容量不足でお悩みの方はぜひ挑戦してみてください！

起きた事象

運転中に突然、エンジンのふけが悪くなり警告灯が付いた。６年目、６万キロを走っているのでいろいろと問題は出るので、淡々とOBDⅡを接続しエラーコードを確認。

エラーコード：P302

二番のシリンダの着火不良とのこと。エアフィルターを外し、イグニッションコイルを外し、プラグを確認。割と汚れているので、インジェクションクリーナーとパーツクリーナで洗浄し、一時的に復活した。

くみ上げる際にイグニションコイルを２番と３番のシリンダで交換をし、再発時に2番で問題がおきたら、プラグの問題であるかを切り分けようとくみ上げた。

症状の再発

４日後、事象が再発した。エラーコードは P302 と P300。

一時的に、P0300, P0302, P0303 のエラーも出た。

エラーコードには出なかったが、ブースト圧力モニターユニットの結果も不合格となった。
ディーラに聞いてみたところ二次災害的なものではないかとのこと。これも気になるのでしばらくは様子見とする。

ディーラーでの対応

P300 は P302 の影響を受けている可能性がありそうだったため、プラグ交換が必要と判断しディーラーで交換をお願いした。
新品のプラグに交換しても P302 が消えないとのこと。イグニッションコイルを交換したことは伝えた上でのディーラーの見解は、現時点では2番（旧３番）のイグニッションコイル不良とのこと。

２番のコイルを交換して、無事に事象は改善された。（約2.5万 ※部品代約1.8万）

壊れたイグニッションコイルは以下の型番のコイルだった。

04E.905.110.M

ネットを見てみるとわりと５万キロ以下で故障することが多い製品とのことだった。
ちなみに交換された部品は 04C.905.110.N。

04E と 04C の違いは色んな説が見つかったが、少なくともBOSCHでは区別をしていないものだった。
語尾の M と N は世代を指すものらしく、N の方があたらしいものとのこと。

今回は、よくわからないが2番シリンダのイグニションコイル（旧３番シリンダで使用）の交換で直ったが、これはもともと３番についていたコイル。そのため、点火プラグで問題がおきるか、または別箇所で問題がおきるとみている。別箇所の場合、ディーラーに世話になるため、今回はディーラーで修理してもらうことにした。

---

その後事象

警告灯やエラーコードはでないものの、発進時に1気筒の調子が悪い。ちょっとだけがたつくため、３番にあるイグニッションコイルを、互換品と言われている以下のBosch製のものに交換。

• BOSCH(ボッシュ) 車用イグニッションコイル フォルクスワーゲンアップ/ゴルフ VII/ポロ等
• サイズ: 22×40×72mm
• 型番: 0986221057
• 価格: 約８千円とお手頃

これで２、３番が新しいイグニッションコイルとなりかなり安定した。
今のところ他に不具合はないが、念のため1番用のイグニッションコイルを買っておこうかなと。