title: ローカルGPUで爆速日本語音声入力を自作した話
categories: AI, 自作PC
tags: 音声入力, Whisper, kotoba-whisper, Rust, GPU, 自作

---

ローカルGPUで爆速日本語音声入力を自作した話

きっかけ：「Windowsキー + H」で音声入力できるOSが欲しかった

Windowsには標準で「Windowsキー + H」で音声入力を起動できる機能があります。あれ、便利ですよね。
Linux（Ubuntu）に乗り換えてから、あれと同等のことができないのがずっと気になっていました。

そこで作ったのが、今回紹介する 自前の音声入力デーモン です。

---

システムの全体像

構成はシンプルです。

[Windowsキー + H] を押す
        ↓
arecord でマイク録音開始（キーを押している間）
        ↓
キーを離す → 録音停止
        ↓
RTX 3060（ローカルGPU）で kotoba-whisper 推論
        ↓
認識したテキストをクリップボードへ
        ↓
Ctrl+V で自動貼り付け（どのアプリにも）

キーボードを叩くのではなく、話しかけてそのままテキストが入力される 感覚です。

---

技術選定のポイント

言語：Rust

常駐デーモンとして24時間起動しておくので、メモリ効率とパフォーマンスを重視してRustを採用しました。evdev でキーボードイベントを直接捕捉し、uinput で仮想キーボードを生成してCtrl+Vを再現しています。

音声認識モデル：kotoba-whisper-v2.0

当初はOpenAIのWhisper largeモデル（ggml-large-v3-turbo.bin）を使っていましたが、kotoba-whisper に乗り換えました。

kotoba-whisperはWhisper large-v3を日本語データで追加学習したモデルで、特に：
– 口語・話し言葉の認識精度が向上
– 固有名詞（地名・人名）の誤認識が減少
– 速度はほぼ同等

という特徴があります。Whisperをすでに使っている方はモデルファイルを差し替えるだけで試せます。

GPU指定：UUIDで確実に RTX 3060 を使う

私のPCはGTX 1650（映像出力専用）とRTX 3060（AI処理専用）のデュアルGPU構成です（この構成については別の記事で紹介しています）。

CUDA_VISIBLE_DEVICES=1 のようなインデックス指定は sudo 環境だと環境変数が引き継がれず、小さい方のGPUが使われてしまうことがありました。

そこで GPU UUID で直接指定する方法に変更しました：

unsafe {
    std::env::set_var(
        "CUDA_VISIBLE_DEVICES",
        "GPU-5e9ee7b1-5492-7b5f-3397-d82eceb2293b" // RTX 3060のUUID
    );
}

UUIDは nvidia-smi -L で確認できます。これで確実にRTX 3060が選ばれるようになりました。

---

こだわりポイント：Obsidianの単語帳でWhisperをカスタマイズ

Whisperには initial_prompt という機能があります。これは「こういう単語が出てくるよ」という文脈ヒントを事前に渡すことで、固有名詞の認識精度を大幅に上げられる機能です。

最初は「前回認識したテキストを渡せばいいのでは？」と考えたのですが、誤認識した内容がそのまま次の認識のコンテキストとして渡されてしまうという欠点があります。

そこで採用したのが、Obsidianの手帳から固有名詞リストを専用ファイルとして管理する方式です。

voice-typer-vocab.md というファイルを手帳に作り、よく使う単語を自分でメンテしていきます。
以下は例です：

## 人名
（よく会話に登場する知人や同僚の名前など）

## 地名
（よく行く場所や地元の地名など）

## プロジェクト
ゴンラス
Obsidian
Raspberry Pi

## 技術用語
kotoba-whisper
VOICEVOX
RAG
MCP

このファイルをvoice-typerが60秒ごとに自動リロードするため、Obsidianで単語を追加するだけで次の認識から反映されます。

---

使ってみた感想

率直に言って、思ったより精度が高い です。

Windows標準の音声入力（Win+H）と比べても、誤変換や文脈の勘違いが少なく、精度は格段に高いと感じました。
また、以前はWhisperのミディアムモデル（Medium）も試したことがありましたが、それと比較しても今回の kotoba-whisper-v2.0 は段違いに精度が高く、体感できるレベルで実用性が向上しています。

普通の日本語は9割以上の確率で正確に認識されますし、固有名詞もvocabファイルに登録しておけば、かなり正確に拾ってくれます。

圧倒的なレスポンス速度

精度だけでなく、速度も申し分ありません。
プログラム内に精密なタイマーを仕込んで計測したところ、RTX 3060を使った推論では、約13秒ほど喋った長めの音声データでも、キーを離してからわずか「0.6秒」で瞬時に文字に変換されてペーストされました。
クラウドのAPIを経由しないため、ネットワークの遅延もなくまさに「爆速」です。

何よりキーボードに触れなくてもテキストが打てるというのは、長文を書くときや両手がふさがっているときに非常に助かります。

Localで完結しているので、APIコストはゼロです。RTX 3060があれば同様の環境が作れます。

---

まとめ

項目	内容
キーバインド	Windowsキー（Meta）+ H
音声認識モデル	kotoba-whisper-v2.0 (日本語特化)
推論デバイス	RTX 3060 (VRAM 12GB)
プログラム言語	Rust
辞書管理	Obsidian vault内の voice-typer-vocab.md
APIコスト	ゼロ（完全ローカル）

Linuxで音声入力に困っている方、ぜひ試してみてください。

きっかけ：父が話さなくなった

父が脳梗塞で倒れました。

幸い命に別状はなかったものの、後遺症として言語障害と記憶障害が残りました。ゆっくり話せばこちらの言っていることは理解できるのですが、自分から話そうとすると言葉がうまく出てこない。そのことが歯がゆく、次第に人前で話すこと自体を避けるようになりました。

話さなければさらに話せなくなる。この悪循環をなんとかしたい。そんな思いから、あるアプリを作り始めました。

市販の「シニア向けスマホ」では足りなかった

まず考えたのが、いわゆる「シニア向けスマホ」や「かんたんスマホ」です。しかし、これらは「ボタンや文字が大きい」というだけの汎用品であり、父が抱える具体的な問題には対応できませんでした。

父の問題は、大きく分けて以下の3つでした。

1. 話し相手がいない: 人前で話すのを避けるようになり、会話の機会が激減している
2. 外出先で迷子になる: 記憶障害により、外を歩いていると帰り道がわからなくなる
3. スマホの設定を壊す: あちこち触ってしまい、Wi-Fiが切れたり、機内モードになったり、音量がおかしくなる

これらを解決するアプリは、探しても見つかりませんでした。なければ作るしかない。そう決めて、AI（Gemini）と一緒に開発を始めました。

「お手伝いさん」という名前

アプリの名前は「お手伝いさん」にしました。

80歳の父にとって、「ランチャー」や「サポートバディ」といったカタカナ英語は意味不明です。また、「介護」や「老人」といった言葉も避けたかった。純粋な日本語で、優しく、それでいて意味がすぐわかる名前。「お手伝いさん」がぴったりでした。

アイコンは、優しい顔をしたロボット。「これが助けてくれるんだな」と直感的にわかるデザインにしました。

5つの機能：すべて父の困りごとから生まれた

① 「会話」ボタン：AIが話し相手になる

これが一番の核心機能です。

ボタンを押すとGoogleのAIアプリ「Gemini」が起動します。Geminiは音声で会話ができるので、父はキーボードを打つ必要がありません。

AI相手なら、こんな心配がありません。

• 話し方がおかしくても、笑われない
• 同じことを何度聞いても、嫌な顔をされない
• 急かされない。自分のペースでゆっくり話せる
• 時間や場所を選ばない。いつでもどこでも練習できる

父が再び「話す楽しさ」を取り戻すための、気兼ねのないリハビリパートナーです。

② 「家へ」ボタン：迷子を防ぐ

外出先で「ここどこだ？」となった時、このボタンを押すだけ。

Googleマップのナビが起動し、現在地から自宅までの徒歩ルートを一発で案内してくれます。検索したり住所を入力したりする必要は一切ありません。

技術的には、GoogleマップのナビゲーションAPI（google.navigation）を直接呼び出すことで、「自宅」を正確に認識させています。単純な「自宅」検索だと、全然関係ない場所に案内されることがあり、ここは苦労したポイントでした。

③ 「迎えにきて」ボタン：SOSの現在地送信

ボタンを押すと、スマホのGPSから現在地の緯度・経度を取得し、GoogleマップのURL付きで家族にSMSを送信します。

送られるメッセージはこんな内容です。

今ここにいます。迎えに来てください。
https://maps.google.com/?q=35.xxxx,139.xxxx

受け取った家族がリンクをタップすれば、地図上で父がどこにいるかをすぐに確認できます。「迷子になったかもしれない」という不安に対する、家族の側の安心材料でもあります。

④ 「電話」ボタン：家族にワンタップ発信

ボタンを押すと、事前に登録した最大3名の家族がリストで表示されます。名前をタップすれば、そのまま電話がかかります。

電話帳から探す必要はありません。「電話」→「名前を選ぶ」。たった2ステップです。

⑤ 「掃除」ボタン：壊れた設定を一発修復

高齢者がスマホを使うと、こんなことがよく起きます。

• 「音が出なくなった」（マナーモードや音量が変わっている）
• 「ネットにつながらない」（機内モードがオンになっている）
• 「電話がかかってこない」（Wi-Fiが切れている）

おそらく本人はいつ触ったかも覚えていません。そんなとき、「掃除」ボタンを押すだけで、以下を自動で行います。

• 音量を30%に設定
• マナーモード（バイブ）に切り替え
• 機内モードやWi-Fiの状態をチェックし、問題があれば設定画面を開いて対処を促す

原因がわからなくても、とりあえず押せば直る。それが重要でした。

工夫したポイント

ホーム画面ごと置き換える（ランチャー化）

このアプリは、スマホの「ホーム画面」そのものを置き換えます。つまり、スマホを開いたら常にこの「お手伝いさん」の画面が表示されます。

これにより、余計なアプリを開いたり、設定をいじったりする余地がなくなります。「やれることを減らす」ことが、安全につながるのです。

「迷子にならない」フローティングボタン

Geminiで会話を始めたとき、「どうやって元の画面に戻るの？」となるのは目に見えていました。

そこで、どのアプリを開いていても画面の端に常に浮かぶ「フローティングボタン」を実装しました。アイコンは「お手伝いさん」のロボットの顔で、タップすれば一発でホームに戻れます。

ホーム画面（お手伝いさん）が表示されているときは自動的に非表示になり、別のアプリに移動すると自動的に再表示されます。邪魔にならず、必要なときにだけ現れる設計です。

レスポンシブ対応（画面サイズへの自動適応）

スマホは機種によって画面の大きさがバラバラです。あるスマホではちょうどよくても、別のスマホではボタンがはみ出したり、小さすぎたりします。

そのため、アイコンや文字のサイズは固定値ではなく、「画面の幅の○%」という割合で指定しています。どんなスマホでも同じバランスで表示されます。

画面の回転をロック

スマホを傾けると画面が回転して、何が何だかわからなくなる…というのも高齢者あるあるです。「お手伝いさん」は常に縦画面に固定しており、どんなに傾けても回転しません。

開発の裏側：AIと一緒に作った

実は、このアプリのKotlinコードはほぼ全て、AI（Gemini）との対話の中で書き上げました。

「こんな機能が欲しい」と日本語で伝えるだけで、AIがコードを書き、ビルドし、APKファイルを生成してくれます。実際に使ってみて「アイコンが小さい」「家への案内がおかしい」とフィードバックすれば、数分で修正された版が出てきます。

プログラミングの知識がなくても、「こんなことに困っている」という想いさえあれば、AIがそれを形にしてくれる時代が来ています。

今後の展望：Google Playへの公開も視野に

現在は父専用のオーダーメイドアプリですが、同じような悩みを持つご家族はたくさんいらっしゃると思います。

今後、以下のような汎用化を行い、Google Playでの公開も視野に入れています。

• 家族が自由に連絡先や自宅住所を登録できる「設定画面」の追加
• 起動するAIアプリをGemini以外（ChatGPT等）からも選べるようにする
• Googleの審査基準への対応（プライバシーポリシー等）

ちなみにGoogle Playの開発者登録料は25ドル（約3,500円）の初回買い切りのみです。Appleの年願約1万円と比べると、個人開発者にはかなり優しいです。

まとめ：「困っている」から生まれたアプリ

「お手伝いさん」は、単なる便利アプリではありません。

父が再び話せるようになるための、安心して外出できるための、そして家族が少しでも肍を撫で下ろすための、「想い」から生まれたツールです。

テクノロジーやAIがどんなに進化しても、大切なのは「目の前の人の困りごとを解決する」というシンプルな動機だと、改めて実感しています。

同じような状況で悩んでいる方の参考になれば幸いです。

title: ロマン全振り！MicroATXに強引にDual GPUを詰め込んだ話
categories: 自作PC
tags: 自作PC, LLM, VRAM, GPU

---

ロマン全振り！MicroATXに強引にDual GPUを詰め込んだ話

導入：12GBをフルに使って巨大なLLMを動かしたい！

自作PCの醍醐味といえば、限られたスペースにいかに自分の理想（ロマン）を詰め込むかですよね。
最近、私はローカル環境でAI（LLM）を動かすことにハマっています。現在動かしているのは Qwen3 (14B) などのパラメータ数の大きなモデル。これらを快適に動かすには大量のVRAMが必要になります。

私のメインGPUは12GBのVRAMを持つ RTX 3060。しかし、ブラウザを開いたりモニターへ映像を出力したりするだけでもVRAMは消費されてしまい、LLMに割り当てられる容量が減ってしまうのが悩みでした。

本題：16GBの夢と、辿り着いた「完全な役割分担」

「12GBの3060と4GBの1650を合わせれば、16GBのVRAMになってもっと巨大なモデルが動くかも？」と考える方もいるかもしれません。実は私も少し試してみたのですが、やはりスペック差が大きすぎて1650側が足を引っ張ってしまい、生成速度が落ちて実用的ではありませんでした。薄々予想はしていましたが、案の定という結果です。

そこで辿り着いたのが、「完全な役割分担」という最適解でした。
「GTX 1650にはモニターの映像出力だけを任せる。そして、RTX 3060は映像出力を一切せず、12GBのVRAMを『すべてLLMの計算専用』としてフルに使い切る！」 という、ロマンあふれる贅沢な使い方です。

ケースのフロントUSBを「生贄」に捧げる

しかし、愛機はコンパクトさが売りの MicroATX マザーボード＆ケース。
上段の1スロット目（メイン）に巨大なRTX 3060を鎮座させ、2枚目のスロット（下段）にサブのGTX 1650を挿そうとすると、マザーボード下部の極太なフロントパネル用USB 3.0ケーブルと完全に干渉してしまいます。

そこで私が下した決断は、「フロントのUSBポート、使えなくてもいいや」という割り切りでした。
思い切ってケース前面のUSB接続ケーブルを引っこ抜き、フロントポートを沈黙させることで、下段のGTX 1650がギリギリ収まる物理的なクリアランスを確保したのです。

まとめ：ロマンのためなら利便性も捨てられる

MicroATXケースでのDual GPU（RTX 3060 + GTX 1650）構成。映像出力を1650に任せることで、RTX 3060の12GBをフル活用し、Qwen3 14Bクラスの巨大LLMをサクサク動かせる最高のローカルAI環境が完成しました。

フロントUSBポートを失うという「引き算の美学」が必要でしたが、不可能なはずの構成を実現できたときの達成感は格別です。もしあなたもVRAM不足に悩んでいるなら、何かを犠牲にしてでもDual GPUのロマンを追求してみてはいかがでしょうか？

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

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