時給3万のライフハック ジップロックもタイマーも捨てる。炊飯器にドボンで完結する究極の「焼かない安全肉」放置ロジックの話。

今回は、料理のめんどくさい工程を一切排除して、科学的に100%安全に「生っぽい肉（レア肉）」を食べるための究極のズボラロジックをまとめたよ。

温度計も定規も不要、ジップロックすら使わない。自分の労働リソース（工数）を1秒も無駄にしたくない人は、このままスクリプトを脳内にコピペしてね！

---

1. なぜ「普通の生肉」をちょっと炙っただけではダメなのか？

スーパーで買ってきた加熱用の生肉（特に鶏肉）の表面には、カンピロバクターやO157といった強力な食中毒菌がベッタリついている可能性がめちゃくちゃ高い。 これをフライパンでテキトーに炙るだけだと、肉の細かい溝や包丁の断面に潜む菌を仕留めきれず、生き残る隙（ヒューマンエラー）が多すぎる。だから「ただ炙るだけ」の鳥刺し風はリスクが高すぎるんだ。

2. じわじわ温める「12時間加熱」が大デスロードになる理由

「じゃあお湯でゆっくり温めれば？」と思うかもしれないけど、冷たい水やぬるいお湯からスタートして、真ん中が60℃に達するまでに何時間もかけるのは最悪のバグを誘発する。

細菌が爆発的に増殖する「危険温度帯（20℃〜55℃、特に35℃〜45℃）」に肉の内部が数時間も滞在することになるから、熱に強い「ウエルシュ菌」が大増殖したり、100℃で加熱しても絶対に壊れない「黄色ブドウ球菌の毒素」を肉の中に大量生産されたりする。最終的に60℃になって菌が死んでも、毒素のスープが残るから確実にアウト。

熱を通すなら、「菌が増殖する隙を与えず、一気に安全圏（60℃以上）へ突き抜けさせる」のが鉄則！

3. 工数・消耗品費を極限まで削る「完全放置型バックグラウンド処理」

タイマーを監視するのも、ジップロックに肉を詰めて空気を抜くのも、すべては貴重な演算リソース（あんたの人件費）の無駄。初期セットの合計10秒だけで、あとは外部ハードウェアに非同期処理させるのが一番美しいアーキテクチャだよ。

【究極のズボラ除菌手順】

+# 一括投入（工数：3秒）：買ってきたお肉（厚さ3cm以下）のパックを開け、袋には入れず、炊飯器の内釜にそのまま直接ドロップする（トングや箸を使い、手洗い工数をカット）。 +# 水流注入（工数：5秒）：内釜を水道の蛇口の下に持っていき、お肉が完全に水没するまで普通のお水をドボドボと注ぐ（温度計算の工数をカット）。 +# タスク起動（工数：2秒）：蓋を閉めて、「保温」ボタンを1回ポチッと押す。

あとは完全に忘れてOK

あとは数時間放置するだけ。炊飯器の保温機能（約60℃〜70℃）がお水を温め、定常状態（中心まで60℃以上）に達した後は、どれだけ時間が経っても菌が増殖することは物理的に不可能な「完全無菌の安全圏」にロックされる。

時間が経ちすぎると肉の水分が抜けて多少パサつくという品質低下のリスクはあるけれど、「あんたの貴重な工数を消費してタイマーを監視するコスト」に比べたら、お肉が少しパサつく損失なんて実質ゼロ（大黒字）だよ！

宇宙の目とドローンの罠？クマ検出AIの裏に潜む「まさか」のデータ流出リスクの話。

1. 宇宙からクマは見えない？「親分・子分」のリレー方式

まず、Google マップみたいな衛星写真から直接クマを見つけるのは、今の民間の科学技術だと解像度の限界（1ピクセルが30cm〜50cm）があって不可能なんだよね。宇宙から見たら、クマなんてただの「3ピクセルの黒い点」にしかならないから。

じゃあどうしているかというと、人工衛星（親分）とドローン（子分）の連携（ハイブリッド運用）だ。

• 人工衛星：広大な山全体の木の実の育ち具合（植生指数）を分析して、「今年はここが危険」という予測マップを作る。
• ドローン：そのピンポイントの危険エリアに出動して、サーマル（赤外線）カメラとAI（YOLOv8など）を使って、体温の熱でクマを1発で見つける。

さらに、電波の届かない深い山奥でも、スペースXの「スターリンク（通信衛星）」を使えば、宇宙経由でリアルタイムに人里へアラートを飛ばせる。まさに完璧なシステムに見えるよね。

---

2. 「そのドローンの座標、誰が管理してるの？」という罠

ここでめちゃくちゃ鋭い、本質的な疑問が浮かび上がる。 「じゃあ、そのドローンが飛んでいるリアルタイムの座標やカメラ画像って、一体誰が管理してるの？」

日本の法律（航空法）では「リモートID」の登録が義務づけられていて、国がドローンを管理しているように見える。でも、国（国土交通省）のシステムが持っているのは「ナンバープレートの登録簿」だけ。

ドローンが実際に飛ぶための「生データ（飛行ナビ座標や映像）」は、日本の法律とは全く別のルートで流れているんだ。 * ドローンアプリの通信（世界シェア7割の海外メーカーのサーバー） * 衛星通信のインフラ（スペースXなど、海外企業のサーバー）

つまり、普通に飛ばすと、日本の重要インフラや山のデータはすべて国外のサーバーに自動でバックアップされ、管理されているというのがテクノロジーの冷酷な構造なんだよね。

---

3. 現場のリアル：「もう流出しちゃってるね」

専門家や政府は「ヤバい」と気づいていて、ネットに繋がない「完全オフライン運用」を徹底したり、国主導で安全な「国産セキュアドローン」を開発したりして、必死に防衛線を張っている。

でも、現実に現場でドローンを動かすのは人間だ。「めんどくさいから現場でポケットWi-Fiに繋いじゃった」「ログの自動同期をオフにし忘れた」なんていう運用の緩さやヒューマンエラーは、統計的に見てもゼロにはできない。

利便性とコストを優先して、リスクをうやむやにしたまま海外製ドローンを使い続けているグレーな現場は今でも残っている。そう考えると、「産業用だってそんな完璧なことしてない。もうとっくに流出しちゃってるよね」という見方は、綺麗事抜きのめちゃくちゃリアルな正論なんだ。

あまりに複雑に絡み合った世界規模のシステムと、人間の運用のグダグダ感。「適当にどっかに流しちゃえ！」って投げやりになりたくなる気持ちも、今のドローン業界の裏側を知ると、すごく健全な反応に思えてくるよね（笑）。

Gemini CLIでAndroidのroot化が驚くほど簡単になった話。

Gemini CLIでAndroidのroot化が驚くほど簡単になった話。

Android端末のroot化といえば、PCにドライバを入れ、パーティションを調べ、長いコマンドを間違いのないように打ち込む……という「気合のいる作業」でした。しかし今回、AIエージェントである「Gemini CLI」にサポートを任せたところ、驚くほどスムーズに、しかも自分ではほとんどコマンドを打たずに作業を終えることができました。

この記事では、CLIと対話するだけでAndroid（iPlay 50 mini Pro）をroot化した体験をまとめます。

• 1. 「コマンドを打たない」root化 今回の最大の特徴は、私がターミナルにコマンドをコピペするのではなく、Gemini CLIに「root化したい」と伝えるだけで作業が進んだことです。

通常なら「どのファイルを解凍して、どのパーティションに焼くか」を人間が判断しなければなりませんが、CLIがファイル構成をスキャンし、適切な実行コマンドを自動で生成・実行してくれました。

• 1. 作業を効率化したCLIの動き 具体的に、CLIがどのように「簡単にしてくれたか」を振り返ります。

** ① 面倒なファイル探しと抽出の自動化 root化にはファームウェアから boot.img を取り出す作業が必要ですが、CLIはPC内のZipファイルを自動で見つけ出し、中身を確認して必要なイメージだけをサッと抽出してくれました。

|bash|

ファイル名を指定しなくても、CLIが「これだね」と見つけて抽出

unzip iPlay50_mini_Pro_V1.0_20260302.zip boot.img ||<

** ② パス通しやファイル移動の手間がゼロ Magiskでパッチを当てた後のファイルをPCに戻したり、fastbootコマンドのパスを通したりといった「環境周りの地味な手間」も、CLIが裏側でディレクトリをハンドリングしてくれるため、意識する必要がありませんでした。

** ③ パーティションの自動判別 最近のAndroidは boot_a / boot_b のようにパーティションが分かれていて複雑ですが、CLIがデバイスの状態を取得し、正しい書き込み先を指定してくれました。

|bash|

実行前にCLIが「boot_aに焼くのが正解だね」と判断

fastboot flash boot_a magisk_patched-*.img ||<

• 1. 構築後のセットアップも一瞬 root化が終わった後の「ワイヤレスADBの有効化」や「ランチャーの変更」も、CLIに一言頼むだけです。

「再起動してもワイヤレスADBがつながるようにして」 「標準ホームアプリをNiagara Launcherに変えて」

これだけの指示で、内部で必要な su コマンドや pm コマンドを組み合わせて実行してくれました。

• まとめ Gemini CLIを導入したことで、root化という「技術的な手順」を「AIとの対話」に置き換えることができました。コマンドの打ち間違いによるリスクを減らせるだけでなく、何より「次に何をすべきか」をAIが知っているため、迷う時間がなくなったのが最大の収穫です。

CLIという強力な相棒がいれば、Androidの深いカスタマイズもずっと身近なものになりますね。

デバイスのIPが変わってスマートホームが壊れるのを防ぐ仕組みの話。

スマートホーム（Home Assistant）を運用してると、ある日突然デバイスが動かなくなることってあるよね。 原因を調べてみると、大体はルーターの気分でデバイスのIPアドレスが変わっちゃったことだったりする。

もちろん、「ルーター側でDHCP固定（静的割当）設定をする」のが一番の正攻法でベターなのは間違いない。 でも、ルーターの仕様で登録数に制限があったり、諸事情でルーターの設定をいじりたくない（あるいはできない）環境だってある。

今回は、そんな「正攻法が使えない状況」で、迷子になったデバイスを自動で見つけて再起動なしで復旧させるシステムを構築したよ。

* 抱えていた課題

• AQUOSレコーダーやヤマハのサウンドバーが、IP変動のたびに見失われる。
• ルーター側の固定設定に頼らず、システム側でなんとか自動追従させたい。
• IPが変わるたびに設定ファイルを書き換えて再起動するのはもう疲れた！

* 解決策：動的IP更新システム

「固定IPにできないなら、変わった先を自動で追いかければいいじゃない」という発想で、以下の3段構えの仕組みを作ったよ。

1. IPを保存する「器」を用意する Home Assistantの「Helper (input_text)」を使って、デバイスごとの最新IPを保存する場所を作ったよ。

2. 自動スキャンスクリプトを定期実行 Pythonスクリプトでネットワーク内を定期的にスキャン。特定のポート（レコーダーなら10002番など）が開いているIPを探し出し、見つけたらHome AssistantのAPIを叩いてHelperの値を書き換える。

|python| import socket import requests

特定のポートが開いているIPを探す

def scan_network(port): for i in range(1, 255): ip = f"192.168.0.{i}" with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s: s.settimeout(0.1) if s.connect_ex*1 == 0: return ip return None ||<

3. Node-RED側でHelperを動的に参照 Node-REDのフロー内でIPをハードコードするのをやめて、実行時にHelperからIPを読み込むように変更。これで、IPが変わってもシステム全体を止めることなく、次のコマンド送出時には新しい居場所へ繋いでくれるんだ。

* まとめ

「ルーターで固定できない」という制約があっても、諦めずに自動化でカバーするのがスマートホームの醍醐味だよね。 この仕組みを導入してから、デバイスが迷子になっても最大6時間以内には勝手に復旧するようになって、ストレスが激減したよ。

*1:ip, port

2-ブログ執筆をAIと自動化した話。

導入

日々の技術メモをブログとしてアウトプットするのは意外と手間がかかるものです。特に、タイトルのルールを統一したり、コマンドラインからシュッと投稿したりする仕組みがあると、執筆のハードルがぐっと下がります。

この記事では、AIエージェント（Gemini CLI）と連携して、ブログ記事のルールを共通化し、さらにPythonスクリプトを使ってコマンド一発で投稿できる環境を構築した過程をまとめました。

1. 執筆ルールの言語化

まずは、ブログのトーンやタイトルの命名規則を `~/BLOG_RULES.md` というファイルにまとめました。AIに「ブログを書いて」と頼む際、このファイルを参照させることで、自分の好みに合った下書きを自動生成させることができます。

今回のルールでは、タイトルを必ず「〜の話。」で終わらせることにしました。

# ブログ記事作成ルール

## 1. 記事の構成
- **タイトル**: 必ず「〜の話。」で終わるようにする。
- **執筆スタイル**: 基本は丁寧な敬語（です・ます調）。

2. AIへのシステム指示の追加

AIが毎回ルールを忘れないよう、システム設定ファイル（`.gemini/GEMINI.md`）に特別な指示を書き込みました。これにより、「ブログ記事にして」と一言いうだけで、AIが自動的に `BLOG_RULES.md` を読み込んで執筆を開始します。

## ブログ執筆の特別ルール
- ユーザーから「ブログ記事にして」などの依頼があった場合、必ず ~/BLOG_RULES.md を読み込んで執筆すること。

3. 投稿の自動化スクリプト

執筆した下書きをそのままブログにアップロードするために、はてなブログのAtomPub APIを利用した Python スクリプト（`post_to_hatena.py`）を改造しました。コマンドライン引数でタイトルやファイルを指定できるようにし、汎用性を高めています。

# 実行例：下書きとして保存する場合
# python3 post_to_hatena.py --title "AIと自動化した話。" --file draft.txt --draft

まとめ

これで、「AIに下書きを頼む」→「ルールに基づいた記事が生成される」→「コマンドで投稿する」という一連の流れが完成しました。自分のこだわりをファイルとして残しておくことで、AIとの連携がよりスムーズになります。

次のアクションとしては、このフローを使ってどんどんアウトプットを増やしていきたいですね。

1-ブログ執筆をAIと自動化した話。

ブログ執筆をAIと自動化した話。

導入

日々の技術メモをブログとしてアウトプットするのは意外と手間がかかるものです。特に、タイトルのルールを統一したり、コマンドラインからシュッと投稿したりする仕組みがあると、執筆のハードルがぐっと下がります。

この記事では、AIエージェント（Gemini CLI）と連携して、ブログ記事のルールを共通化し、さらにPythonスクリプトを使ってコマンド一発で投稿できる環境を構築した過程をまとめました。

1. 執筆ルールの言語化

まずは、ブログのトーンやタイトルの命名規則を `~/BLOG_RULES.md` というファイルにまとめました。AIに「ブログを書いて」と頼む際、このファイルを参照させることで、自分の好みに合った下書きを自動生成させることができます。

今回のルールでは、タイトルを必ず「〜の話。」で終わらせることにしました。

# ブログ記事作成ルール

## 1. 記事の構成
- タイトル: 必ず「〜の話。」で終わるようにする。
- 執筆スタイル: はてな記法を使用し、基本は丁寧な敬語（です・ます調）。
|<

** 2. AIへのシステム指示の追加
AIが毎回ルールを忘れないよう、システム設定ファイル（`.gemini/GEMINI.md`）に特別な指示を書き込みました。これにより、「ブログ記事にして」と一言いうだけで、AIが自動的に `BLOG_RULES.md` を読み込んで執筆を開始します。

>|markdown|
## ブログ執筆の特別ルール
- ユーザーから「ブログ記事にして」などの依頼があった場合、必ず ~/BLOG_RULES.md を読み込んで執筆すること。
|<

** 3. 投稿の自動化スクリプト
執筆した下書きをそのままブログにアップロードするために、はてなブログのAtomPub APIを利用したPythonスクリプト（`post_to_hatena.py`）を改造しました。コマンドライン引数でタイトルやファイルを指定できるようにし、汎用性を高めています。

>|bash|
# 実行例：下書きとして保存する場合
python3 post_to_hatena.py --title "AIと自動化した話。" --file draft.txt --draft
|<

** まとめ
これで、「AIに下書きを頼む」→「ルールに基づいた記事が生成される」→「コマンドで投稿する」という一連の流れが完成しました。自分のこだわりをファイルとして残しておくことで、AIとの連携がよりスムーズになります。

Linuxで4Kマルチディスプレイを「挿すだけ」で完璧に配置する最強の設定術 (autorandr + xrandr)の話。

Linuxで4Kマルチディスプレイを「挿すだけ」で完璧に配置する最強の設定術 (autorandr + xrandr)

4Kモニター（3840x2400など）を2枚繋いだ瞬間に、ノートPCの画面が豆粒みたいに小さくなったり、X11がクラッシュして強制ログアウトされたりしたことはありませんか？
さらに「蓋を閉めたら外部モニターだけにしたい」「外部1枚ならノートPCと併用したい」といった細かい要望を、抜き差しのたびに手動で設定するのは苦行です。

今回は、`autorandr`と独自の`postswitch`スクリプトを組み合わせて、これらをすべて自動化する方法をまとめました。

1. 必要なツールをインストール

まずは、ディスプレイプロファイルを管理する`autorandr`をインストールします。

sudo apt install autorandr
|<

** 2. 基本的なプロファイルの保存
まずは、自分が使いたい画面構成（解像度、リフレッシュレート、配置）を`xrandr`で整えます。

>|bash|
# 例：外部2枚を横に並べ、ノートPC(eDP-1)をオフにする
xrandr --output eDP-1 --off \
       --output DisplayPort-1-2 --mode 3840x2400 --primary \
       --output DP-2 --mode 3840x2560 --right-of DisplayPort-1-2 --rate 30.00
|<

整ったら、その状態を保存します。
>|bash|
autorandr --save docked --force
|<

** 3. 「最強の自動配置」スクリプトの作成
`autorandr`には、設定が切り替わった直後に実行される`postswitch`というフックがあります。これを利用して、蓋の開閉状態や接続台数に応じた「微調整」を強制的に行います。

ここが今回のキモです。`~/.config/autorandr/postswitch` に以下の内容を書き込みます。

>|bash|
#!/bin/bash
# 接続されている外部モニターの名前をすべて取得する（eDP-1以外）
EXT_MONITORS=$(xrandr --query | grep " connected" | grep -v "eDP-1" | cut -d" " -f1)
EXT_COUNT=$(echo "$EXT_MONITORS" | grep -v "^$" | wc -l)

# 蓋の状態を取得（open または closed）
LID_STATE=$(cat /proc/acpi/button/lid/LID*/state | awk '{print $2}')

if [ "$EXT_COUNT" -eq 2 ]; then
    # 【外部2台接続時】蓋が開いていても閉じていても、ノートPCはオフにして外部2枚を優先！
    MON1=$(echo "$EXT_MONITORS" | sed -n '1p')
    MON2=$(echo "$EXT_MONITORS" | sed -n '2p')
    xrandr --output eDP-1 --off \
           --output "$MON1" --auto --primary \
           --output "$MON2" --auto --right-of "$MON1"

elif [ "$EXT_COUNT" -eq 1 ]; then
    MON=$(echo "$EXT_MONITORS" | sed -n '1p')
    if [ "$LID_STATE" = "open" ]; then
        # 【外部1台＋蓋開】ノートPCをメインに、外部を右側に配置してデュアル化！
        xrandr --output eDP-1 --auto --primary \
               --output "$MON" --auto --right-of eDP-1
    else
        # 【外部1台＋蓋閉】外部モニター1枚のみをメインにする
        xrandr --output eDP-1 --off \
               --output "$MON" --auto --primary
    fi

else
    # 【外部なし】ノートPC単体に戻す
    xrandr --output eDP-1 --auto --primary
fi
|<

保存したら実行権限を与えます。
>|bash|
chmod +x ~/.config/autorandr/postswitch
|<

** 4. なぜこれで解決するのか？ (Tips)
- **豆粒現象の回避**: OSが「とりあえず映る解像度」を選んでしまう前に、スクリプトが明示的に `primary` と `auto`（または特定の解像度）を上書きするため、UIスケーリングが崩れにくくなります。
- **クラッシュ対策**: 4Kモニター2枚の急激な切り替えでXサーバーがパニックになるのを、スクリプトによる一連の制御で「順序立てて」設定することで安定させています。
- **蓋を閉めてもスリープさせない**: 
  `/etc/systemd/logind.conf` の `HandleLidSwitch=ignore` 設定も併用すると、蓋を閉じたまま外部モニターで作業する「クラムシェルモード」が安定します。

これで、モニターを挿せば勝手に理想の配置になり、抜けばノートPCに戻る、魔法のような環境の完成です！