ナスオモリの重さや素材を変えると、底につくまでの時間はどれくらい変わるのでしょうか。 釣り場では、なんとなく「重い方が速い」「タングステンは小さいから沈みやすそう」と考えています。ただ、その差を数字や動きで見比べようとすると、頭の中だけでは整理しにくいです。 そこで、ナスオモリの沈み方を見比べるための小さなWebアプリを作りました。 ナスオモリ沈下シミュレーター 重さ・金属・水深で着底時間を比較 開く アプリ： ナスオモリ沈下シミュレーター 計算根拠： ナスオモリの沈み方をどう計算しているか この記事では、アプリでできることと、釣り場でどう使うとよさそうかをまとめます。 作った理由 最近、ゴロタ浜やサーフで底を探る釣りをすることが増えました。 底の石に当たる感触、根掛かりしにくさ、アタリの出方。こういうものは、シンカーの形や浮力でかなり変わります。フロートシンカーは根掛かりには強いですが、底からの情報は少なくなります。逆に普通のオモリは底の情報が出やすいものの、場所によっては根掛かりが怖いです。 その中で、ふと気になったのが「沈む時間」でした。 同じ1oz前後でも、鉛、タングステン、ブラス、鉄では体積が違います。重くすれば速く沈みますが、体積も大きくなって水の抵抗も増えます。仕掛けやラインまで含めると、さらに単純な話ではなくなります。 もちろん、実際の海では潮流、糸ふけ、エサ、仕掛けの姿勢で結果が変わります。ですから、このアプリは正解を出すためのものではありません。条件を変えたときに、沈み方の傾向を見比べるための道具として作りました。 このアプリでできること アプリでは、4つのナスオモリを同時に並べて沈められます。 それぞれのオモリについて、素材と重さを変えられます。素材は鉛、タングステン、ブラス、鉄です。重さは1gから120gまでの範囲で指定できます。 鉛 タングステン ブラス 鉄 水の条件も変えられます。 水深：1mから100m 水質：真水、海水 水の抵抗：0.10から4.00 画面には、代表オモリの着底時間、終端速度、水の密度、実際に沈む距離が表示されます。アニメーションを止めたり、タイムラインを動かしたりしながら、同じ条件で沈み方の差を見られるようにしました。 たとえば、鉛の10g、14g、21g、28gを並べれば、一般的な号数違いの感覚へ近づきます。素材だけを変えれば、同じ30gでもタングステンの方が小さく、ブラスや鉄の方が大きくなることも見えやすいです。 まずは基本条件で見比べる 最初は、初期値のまま眺めるのが分かりやすいです。 初期状態では、海水、水深5m、水の抵抗2.00で、鉛の10g、14g、21g、28gを並べています。アプリ上の沈下距離は、オモリの見た目サイズを考慮して、水深より少し短くなります。 オモリ 素材 沈下距離の目安 終端速度の目安 着底時間の目安 10g 鉛 4.37m 0.88m/s 5.0秒 14g 鉛 4.30m 0.94m/s 4.7秒 21g 鉛 4.19m 1.00m/s 4.3秒 28g 鉛 4.11m 1.05m/s 4.0秒 このくらいの浅い水深では、違いは数秒単位ではなく小数秒として出ます。釣りをしている最中に正確に感じ分けるのは難しいかもしれませんが、「重さを上げるほど速くなる。ただし倍の重さでも半分の時間にはならない」という傾向は見えます。 もう少し差を見たいときは、水深を20mや50mへ上げると分かりやすいです。水深が深くなるほど、終端速度に近い状態で進む時間が長くなり、素材や抵抗の違いが表に出やすくなります。 同じ30g、水深20m、海水、水の抵抗2.00で素材だけを変えると、おおよそ次のようになります。 素材 終端速度の目安 着底時間の目安 鉛 1.06m/s 18.1秒 タングステン 1.29m/s 14.9秒 ブラス 0.95m/s 20.2秒 鉄 0.92m/s 20.8秒 同じ重さなら、密度が高いタングステンは体積が小さくなり、水の抵抗を受ける面積も小さくなります。そのため、このモデルでは鉛より速く沈みます。ブラスや鉄は鉛より体積が大きくなり、少し遅く沈みます。 ...

準備中のサイトを、URLでは共有したい。でも、検索や一般ユーザーにはまだ見せたくない。 Hugoで作っているサイトの公開前チェック、WordPressのリニューアル確認、ローカルで動かしている検証アプリの共有では、この状態がよくあります。自分だけで見るならlocalhostで足りますが、確認相手に見てもらうには外から開けるURLが必要です。 そこで使いやすいのが、Cloudflare Zero TrustのAccessです。 この記事では、preview.araisun.comのような確認用ホスト名にCloudflare Accessをかけ、許可したメールアドレスだけOne-time PINで通す流れを整理します。Cloudflare Tunnelは「previewを外へ出す道」として短く扱い、Tunnel自体の作り方はローカルで立ち上げたサーバーをSSL経由で外部URL公開できるCloudflare Tunnel に任せます。 主役は、Cloudflare Accessのapplication、policy、One-time PIN、動作確認です。 先に結論 Cloudflare配下のドメインで準備中サイトを共有するなら、Basic認証だけでなくCloudflare Accessも候補になります。 Accessを使うと、originへリクエストを通す前にCloudflare側で認証できます。確認してほしい人のメールアドレスをAccess policyに入れ、その人だけOne-time PINでログインできるようにします。共有するのは共通パスワードではなくURLとメール認証の案内です。 今回の例では、preview.araisun.comを準備中サイトの確認用URLにします。Access applicationでこのホスト名を保護し、policyで許可メールを指定し、許可メール、未許可メール、別ブラウザ、スマホ回線、Access logsを順番に確認します。 Tunnelを使う場合でも、この記事ではTunnelの細かい手順には入りません。Tunnelは公開URLへつなぐ道、Accessはその手前で誰を通すかを決める関門、と分けて考えます。 Cloudflare Accessで守れるもの Cloudflare Accessは、Cloudflareを通るリクエストの前段に認証レイヤーを置く機能です。self-hosted applicationとしてpreview.araisun.comのような公開ホスト名を登録し、Access policyに一致したユーザーだけをoriginへ通します。 準備中サイトで使うなら、守る対象は次のような入口です。 preview.araisun.comのホスト名全体 /adminのような特定path stagingやpreview用のサブドメイン この記事では、準備中サイト全体を見せるか見せないかを制御したいので、preview.araisun.com全体を保護対象にします。/adminだけを守る設定にはしません。 Access applicationは、作っただけで全員を通すものではありません。基本は「許可条件に一致した人だけ通す」という考え方です。だから、applicationを作ったあとに、誰を通すかをAccess policyで決めるところが重要になります。 ただし、Accessが守れるのはCloudflare経由の入口です。VPSやnginxのorigin IP、別ホスト名、直アクセス用の経路が残っている場合は、そこから迂回される可能性があります。この点は後半で分けて確認します。 Basic認証とAccessの使い分け Basic認証は、origin側でIDとパスワードを確認する方法です。nginxやApacheで設定でき、Cloudflareを使わない環境でも動きます。短期間の簡単な保護や、自分だけが見るページなら今でも選択肢になります。 一方で、確認相手へ見せる運用になると、Basic認証には少し面倒なところがあります。 IDとパスワードを相手へ送る必要がある 複数人へ同じパスワードを共有しがち 確認が終わった人だけ外す運用がやりにくい ブラウザ標準の認証ダイアログが確認用として少し硬い Cloudflare Accessなら、確認してほしい人のメールアドレスをpolicyに追加します。確認が終わったら、そのメールアドレスを外します。共通パスワードを配って後から変更するよりも、人単位の出し入れがしやすくなります。 もちろん、AccessがBasic認証を常に置き換えるわけではありません。Cloudflareを使っていない環境、サーバー内だけで完結したい環境、単純な一時保護ならBasic認証の方が早いこともあります。 すでにCloudflareをCDN / proxyとして使っていて、メールアドレス単位で少人数に見せたい。そういう準備中サイトでは、Accessの方が自然に扱える場面があります。 Tunnelは道、Accessは認証の関門 Cloudflare TunnelとCloudflare Accessは、役割を分けて考えると混乱しにくくなります。 Cloudflare Tunnelは、ローカルサーバーやprivateなoriginをCloudflareへつなぐ道です。たとえばローカルでHugo previewを動かしているなら、Tunnel側では次のような対応を作ります。 preview.araisun.com -> http://localhost:1313 この設定を作ると、preview.araisun.comからローカルのHugo previewへ届く道ができます。Tunnelの作成、public hostname、DNS、cloudflaredの常駐化などはCloudflare Tunnelの記事 で扱っているので、ここでは広げません。 Accessは、その道の手前に置く認証の関門です。preview.araisun.comに来た人をCloudflare側で止め、メールアドレスとOne-time PINで確認します。許可した人だけをTunnelの先へ通し、Hugo previewを見せます。 ...

Playwrightを触ってみて、これはかなり使えるのではないかと思いました。 UIテストの道具として便利なのはもちろんですが、AIにコードを書かせる機会が増えるほど、意図していない場所が壊れていないかを機械的に確認する仕組みが欲しくなります。 特に個人開発では、リリース前に毎回ブラウザを開いて、 トップページが開くか フォームを送信できるか 検索やフィルタが動くか 登録、編集、削除の主要な流れが壊れていないか AIに直してもらった場所以外が壊れていないか といった確認を手でやりがちです。最初は数分でも、画面や機能が増えると抜け漏れが出ます。 Playwrightは、この「毎回ブラウザでやっている確認」をコードにして、同じ条件で繰り返し実行できるE2Eテストの道具です。スクリーンショットや動画も残せるので、テストだけでなく、YouTubeや記事用に動作説明の素材を作る用途にも使えそうです。 この記事では、React + Viteで作った問い合わせフォーム を例に、Playwrightを入れてフォーム操作を自動確認するところまでを書きます。 全体像は、手動確認をテストコードに置き換え、ブラウザで自動実行し、失敗時はレポートやtraceで原因を追う流れです。 Playwrightとは Playwrightは、ブラウザを自動操作してWebアプリの動きを確認できるE2Eテストフレームワークです。 E2EはEnd to Endの略で、ユーザーが実際に画面を開いて操作する流れに近い形でテストします。たとえば、次のような操作をコードで書けます。 ページを開く 入力欄に文字を入れる ボタンを押す 検索結果が表示されることを確認する フォーム送信後のメッセージを確認する 単体テストが関数や部品単位の確認に向いているのに対して、Playwrightは「画面上で主要な操作が最後まで通るか」を確認する用途に向いています。 PlaywrightはChromium、Firefox、WebKitを扱えます。ただし、初めて導入する段階では、いきなり全ブラウザを対象にしなくても大丈夫です。まずはChromiumだけで、リリース前に毎回手で確認している重要な操作を1つ自動化するところから始めると進めやすいです。 触って便利だと感じたところ まだ深く使い込んでいるわけではありませんが、触ってすぐ便利だと感じたのは次のあたりです。 クリックや入力の前に、要素が操作可能になるまで待ってくれる expect を使って画面上の見出し、ボタン、メッセージを確認できる 失敗時のスクリーンショット、動画、trace、HTMLレポートを残せる UI Modeで、ブラウザの動きを見ながらテストを書ける 開発サーバーの起動を webServer でまとめられる Chromium、Firefox、WebKitを同じテストで確認できる AIにコードを直してもらったあと、「指示した箇所は直ったが、別のフォームが壊れた」ということは普通に起きます。Playwrightで主要フローだけでも自動確認しておけば、その手戻りに気づきやすくなります。 最初はフォーム送信だけでもよい Playwrightを入れると、つい全画面を自動化したくなります。ただ、最初から広げるとテストを書くこと自体が重くなります。 まずは、今回の問い合わせフォームのように、壊れると困る操作を1つだけ選ぶくらいでよさそうです。 ページが開ける フォームへ入力できる 送信後の結果が表示される これだけでも、リリース前に毎回手で確認していた作業を1つ減らせます。慣れてきたら、検索、登録、編集などに広げれば十分だと思います。 React + ViteフォームにPlaywrightを入れる 今回は、React + Viteで作った小さな問い合わせフォームを例にします。 以降のコマンドは、React + Viteフォームアプリのプロジェクト直下で実行する前提です。 まず、Playwright Testを開発依存として追加します。 npm install -D @playwright/test 初回はブラウザも入れます。まずはChromiumだけで十分です。 npx playwright install chromium 新規プロジェクトでひな形ごと作りたい場合は、公式の npm init playwright@latest から始めてもよいです。この記事では、既存のReact + Viteアプリへ手で追加する流れにします。 ...

Reactと合わせてよく見かける、Viteって何だろう。Next.jsとは何が違うんだろう。 そんなところで少し疑問に思ったので、さらっと学習してみました。 AIによって生成されたアーキテクチャやソースコードで意味が分からないままだと、あとで自分で直したいときに困ったことになります。 AIに改修を任せる場合でも、レビューは必要ですから、最低限の知識は入れておきたいですよね。 さて今回は、React + Viteで小さな問い合わせフォームを作りながら、React、Vite、Next.jsの役割を整理してみました。 まずReact、Vite、Next.jsの役割を整理 最初に混乱しやすいのは、React、Vite、Next.jsがどの部分を扱っているのかよく分からないこと。 実際には、担当している範囲が違います。 ざっくり分けると、次のようになります。 名前 役割 この記事での見方 React UIを作るライブラリ 画面をコンポーネントとして作る Vite 開発サーバーとビルドの道具 Reactアプリを快適に開発し、公開用ファイルへまとめる Next.js Reactベースのフレームワーク ルーティング、SSR / SSG、サーバー側処理なども含めてアプリを作る なるほど、Next.jsはReactを元に増強したフレームワークなのですね。一方でViteはビルドなどやりやすいようにしてくれる、開発支援ツールといったところでしょうか？ もちろんReactは、画面を部品として組み立てるためのライブラリです。コンポーネント、JSX、state、イベント処理といった考え方が中心になります。 Viteは、Reactアプリを開発するときの開発サーバーや、本番公開用のビルドを担当する道具です。ちなみに Vite は「ヴィート」と読みます。保存した変更を素早くブラウザに反映するHMR (ホット・モジュール・リプレイスメント)も、Viteのありがたさを感じやすい部分です。とはいえ、今時この手のツールは当たり前すぎて、あまり意識していなかったようです。 Next.jsは、Reactを土台にしたフレームワークです。ファイルベースのルーティング、SSR、SSG、Route Handlersなど、アプリ全体を作るための機能をまとめて持っています。SSR、つまりサーバーサイドレンダリングですが、ここら辺が Next.js の魅力といったところでしょうか。 さて今回は、学習用に小さなフォームアプリをReact + Viteで作ってみます。SPA（シングルページアプリケーション）ですが、ペラ１のめちゃ簡単なUIのみで、メールサーバーも何もないのであしからず。 React + Viteプロジェクトを作る それではプロジェクトを作成して実装していきましょう。 Vite公式のGetting Startedでは、npm create vite@latest からプロジェクトを作れます。 Vite 8系ではNode.js 20.19+ または 22.12+ が必要です。古いNode.jsを使っている場合は、先に更新しておきます。 まずはNode.jsのバージョンを確認します。 node -v 次に、Reactテンプレートでプロジェクトを作ります。 npm create vite@latest react-vite-form-app -- --template react cd react-vite-form-app npm install npm run dev 対話形式で進める場合は、次のように選びます。 ...

AIコーディングエージェントに複数の作業を同時に任せたい場面があります。 たとえば、片方ではUIを直し、もう片方ではテストを直す。あるいは、A案とB案を別々に試す。こういうとき、同じ作業ディレクトリで同時に編集させると、未コミット変更やブランチ切り替え、同じファイルの編集が絡んでかなり危なっかしくなります。 そこで使えるのが git worktree です。 この記事では、1つのローカルリポジトリから複数の作業ディレクトリを作り、feature/new-feature-a と feature/new-feature-b を別々に進める流れを、実際のコマンドと結果で確認します。 git worktree とは git worktree は、1つのGitリポジトリに複数の作業ディレクトリを紐づける機能です。 普通は1つのリポジトリに1つの作業ディレクトリがあり、その中で git switch や git checkout を使ってブランチを切り替えます。 一方、git worktree を使うと、ブランチごとに作業ディレクトリそのものを分けられます。 /tmp/worktree-demo は main /tmp/worktree-demo-a は feature/new-feature-a /tmp/worktree-demo-b は feature/new-feature-b というように、別々の場所で別々のブランチを同時に開けます。 git checkout との違い git checkout や git switch は、今いる作業ディレクトリの中身を別ブランチへ切り替える操作です。 作業途中の変更があると、切り替え時に止められたり、stashやコミットが必要になったりします。 git worktree は、ブランチを切り替えるのではなく、作業ディレクトリを増やします。なので、main の作業場所を残したまま、A用、B用の作業場所を別に用意できます。 AIエージェントに並列で頼む場合は、この差がかなり大きいです。 検証用リポジトリを作る 今回はブログ本体のリポジトリではなく、/tmp に捨てリポジトリを作って試します。 cd /tmp mkdir worktree-demo cd worktree-demo git init -b main printf '# worktree demo\n' > README.md git add README.md git -c user.name='Demo User' -c user.email='[email protected]' commit -m 'initial commit' ここまでで main ブランチに最初のコミットが1つある状態になります。 ...

Hugo のような静的サイトは、HTML を配信するだけならとても軽いのですが、 POST /api/... のような 小さい受付口 を足したくなることがあります。 例えば次のような用途です。 記事末尾の軽いリアクション お問い合わせの簡易受付 Slack への通知トリガー ちょっとした webhook の受け口 このとき、サイト全体を動的構成へ寄せるほどではないが、POST /api/... だけは欲しい、という場面があります。 そういう用途にちょうどよいのが Cloudflare Worker です。 今回は、Hugo サイトに軽いリアクション導線を追加した実例をもとに、 Cloudflare Worker + D1 + Slack でサーバーレスな受付口を作る方法 を、実際のファイルと設定をそのまま出しながらまとめます。 Cloudflare Worker と D1 は何をするものか まず役割を分けておきます。 Cloudflare Worker Cloudflare Worker は、Cloudflare のエッジ上で動くサーバーレス実行環境です。 ざっくり言うと、Cloudflare 側に小さな API を置ける仕組み です。 今回の用途では、POST /api/like を Worker で受けます。 Cloudflare D1 Cloudflare D1 は、Cloudflare が提供している SQL データベースです。 SQLite に近い感覚で使え、Worker から直接読み書きできます。 今回の用途では、次のようなイベント記録を保存します。 どの記事に対するリアクションか 同じ visitor がすでに送っていないか いつ送られたか Slack Incoming Webhook 通知先です。 新しいイベントがあったときだけ Slack に飛ばします。 ...

日本の地震情報を、地図と時間軸で視覚的に見られる Web アプリ Quake Radar を公開しました。 Quake Radar 日本の地震情報を地図と時間軸で確認 開く このアプリでできることを先にまとめると、次の3つです。 最近の地震を、地図と時間軸でまとめて見る 東日本大震災や熊本地震の流れを、一覧ではなく分布で見直す 文字の羅列だけでは掴みにくい揺れの連続性を、視覚的に追う 「とりあえず今どこで揺れが続いているのか見たい」ときや、過去の大地震を地図ベースで見直したいときの入口 として作っています。 地震情報は普段から文字や一覧で目にすることが多いですが、実際に地図上へ並べて、時間の流れと一緒に見てみると、見え方がかなり変わります。 どこで揺れが続いているのか、どのくらいの規模の地震がどの順番で起きたのか、一覧だけでは掴みにくい流れが少し直感的に見えてきます。 もともと私は、CLI で地震情報を確認するための簡単な仕組み を手元で使っていました。 ただ、数字や地名を追うだけでは分かりにくい場面もあり、地図やタイムラインで見られた方が理解しやすいのではないかと思い、この形にしてみました。 Quake Radar でできること Quake Radar では、最近の地震を地図上にプロットして、時間軸に沿って再生できます。 色は最大震度、円の大きさはマグニチュードに対応していて、地震の規模や揺れの強さがひと目で分かるようにしています。 また、最新の地震情報だけでなく、東日本大震災や熊本地震のような過去の大きな地震も、当時の流れをたどれる形で表示できます。 現時点では、東日本大震災と熊本地震を切り替えて表示できます。 文字だけで読んでいた時には見えにくかった流れも、地図と時間軸に載せるとかなり掴みやすくなります。 同じ地域で続いている地震、少し時間を空けて起きる大きな揺れ、広い範囲での分布などが、一覧よりも掴みやすくなります。 過去の大地震を見直すと印象が変わる 特に東日本大震災のデータを見ていると、本震だけを単独で捉えるのではなく、その前に大きめの地震があり、その後に本震へつながっていく流れが視覚的に残ります。 普段のニュースやテキスト中心の情報では、どうしても「大きな地震が起きた」という一点で記憶されがちですが、時系列で並べてみると、災害の見え方が少し変わります。 熊本地震のように、比較的限られた地域で強い揺れが連続するケースも、一覧ではなく地図で見ると特徴がかなり掴みやすくなります。 同じ「大きな地震」でも、揺れの広がり方や続き方に違いが見えてきます。 もちろん、過去のデータを見たからといって将来を予測できるわけではありません。 ただ、災害を単なる過去の出来事として忘れてしまわず、改めて備えを考えるきっかけにはなるのではないかと思っています。 このアプリを公開した理由 最初は、手元の地震情報を少し見やすくしたいという延長で作り始めたものでした。 ただ、実際に形になってくると、単なる自分用のツールとして閉じておくより、公開しておいた方が少しでも役に立つかもしれないと思うようになりました。 災害は、意識していないと日常の中ですぐ遠のいてしまいます。 大きな地震の記憶も、時間が経つとどうしても薄れていきます。 Quake Radar が、日々の地震活動を見たり、過去の大きな災害を見直したりする小さなきっかけになればと思っています。 データについて Quake Radar は、気象庁などの公開データをもとに再表示しているアプリです。 最近の地震は API 経由で取得し、過去の大きな地震については表示用に整理したデータを使っています。 公式発表そのものではないため、実際の避難判断や安全確保の判断は、必ず気象庁などの公式情報を優先してください。 関連記事 CLI で地震情報を確認するための簡単な仕組み おわりに 災害への備えは、何か大きな出来事があった直後だけ意識して、しばらくすると薄れてしまいがちです。 Quake Radar は、そんな時に少し立ち止まって地震の流れを見直し、災害を忘れないためのきっかけになればと思って公開しました。 もしよければ、実際に触ってみてください。 https://quake.apppppp.com/

はじめに Note この記事は、/mobile-share-ios-android/ の更新版です。 最新の各国比較や世界全体の傾向を知りたい方は、この 2026 年版を読めば大丈夫です。 一方で、2023 年時点の各国グラフや当時の見え方をそのまま確認したい場合は、旧版記事も参考になります。 こんな疑問にお答えします。 2026年の日本で、iPhone と Android はどちらが多いのか 2023年版から見て、どの国で iPhone 比率が大きく変わったのか 世界全体では iPhone が伸びているのか、それとも Android が強いままなのか この記事では、StatCounter Global Stats のモバイル OS データをもとに、世界30カ国の iPhone と Android のシェア比を比較します。 2026年4月17日に確認した時点で、StatCounter 上で取得できる最新月は 2026年3月 でした。 なお、2023 年版からの変化が分かるように、前回記事と比較しながら読める構成にしています。 世界30カ国のiPhoneとAndroidのシェア率を比較【2023年最新版】 なお、本記事では iOS を実質的に iPhone ユーザー、Android を Android ユーザー とみなして比較しています。 3秒でわかる要点 世界全体の変化 ...

はじめに 前回の記事では ソーラー焼き芋 をご紹介しましたが、今回は続いてソーラーじゃがバターを試してみました。 小ぶりのじゃがいもをよく洗い、天気の良い日にソーラークッカーへセットして1時間半ほど放置します。焼き上がったじゃがいもを半分に割ってバターをのせれば完成です。お好みで塩を振っても美味しくいただけます。 春に出回る小ぶりの新じゃがを使うと、火の通りもよく作りやすいと思います。 作り方 小ぶりのじゃがいもをよく洗う 天気の良い日にソーラークッカーへ入れる 1時間半ほど放置する じゃがいもを半分に割り、バターをのせる お好みで塩を振って完成 調理の様子 調理の様子はショート動画でも公開しています。 https://youtube.com/shorts/TYaEiIakwM8?feature=share 使ってみた感想 焼き芋と同じく、電気もガスも使わず、太陽光だけでここまで調理できるのはやはり面白いです。じゃがいもはさつまいもよりもあっさりしているぶん、バターとの相性が良く、シンプルながら満足感のある仕上がりでした。 一方で、このソーラークッカー自体には気になる点もあります。アイデアはとても面白いのですが、金属部分のバリがやや粗く、使っているうちにガラス管を傷つけそうな印象がありました。分解自体は簡単なので、アウトドア道具いじりが好きな方ならバリ取りなどの調整はできると思います。 また、ガラス管がむき出しに近い構造のため、乱暴に扱うと壊れやすそうです。災害時にも使えそうな発想の道具ではありますが、インフラが壊れるような大きな地震では、本体のガラスも無事では済まない気がします。そういう意味では、実用品としては面白い半面、やや繊細な道具という印象です。 取り扱いの注意 中の金属部分は火傷するほど熱くなります。取り出す際は、焚き火などで使う革手袋を着用した方が安全です。 また、海外配送では破損リスクもあるようです。実際に同じような商品をもう一度注文した際には、配送中に割れて届いたものもありました。試してみたい方は、そのあたりも踏まえて自己責任で選ぶのがよさそうです。 関連アイテム 今回のような調理を試すなら、まずはソーラークッカー本体が必要になります。取り扱いには十分注意しつつ、晴れた日の遊び道具としてはなかなか面白いです。 ソーラークッカー 革手袋

はじめに ソーラークッカーで焼き芋を作ってみました。 天気の良い日に日なたへ置き、小ぶりのさつまいもを洗ってセットしたら、あとは待つだけです。 ソーラークッカー 2時間後に取り出してみると、中までしっかり火が通りホクホクに焼けました。 調理の様子 調理の様子はショート動画でも公開しています。 https://youtube.com/shorts/49_NL0G5kFw?feature=share 焼き時間について 実際には、2時間も待たなくても十分ふかふかに焼き上がっていたのではないかと思います。 ただ、石焼き芋も焼き石の上で長時間保温されていることを考えると、多少加熱時間が長くなっても問題になりにくいのが、さつまいもの良いところですね。 ソーラークッカーの第一印象 この ソーラークッカー は、注文してから1か月ほど待って海外（中国）から届きました。 Amazon の写真ではメスティンが入るサイズに見えたのですが、実物は直径5cmほどの細いチューブ型で、思っていたより調理の幅は狭めです。 少し期待外れではありましたが、せっかくなのでしばらく使ってみることにしました。 中はガラス製の真空管のような構造になっていて、太陽光を取り込みつつ、温めた熱を逃がしにくい、いわば魔法瓶のような仕組みです。 ただし、ガラスは今にも割れそうなくらい薄く、取り扱いにはかなり注意が必要です。 実際、似たようなソーラークッカーをもう一つ注文したのですが、片方は配送中に割れていました。 梱包もかなり簡素だったので、海外発送の商品は相応のリスクがある前提で購入したほうが良さそうです。 しかも、決して安い商品ではありません。 この手のソーラークッカーを日本のどこかの会社が作ってくれたら面白いのですが。石油危機の昨今、案外バズる商品かもしれません。 実際に使ってみた感想 冬の寒い日でも、調理への期待は十分持てそうです。 太陽光に1時間ほど当ててから中のチューブを引き抜いて触ってみると、火傷しそうなくらい熱くなっていました。 初めてのソーラークッカーということもあり、その威力にはかなり驚かされました。 他の料理にも応用できそう ところで、焼き芋以外に何を調理したら面白いだろうかと考えてみました。 今回は「石焼き芋」を「ソーラー焼き芋」に置き換えたわけですから、同じように「石焼き」が付く料理を参考にすれば、いろいろなアイデアが広がりそうです。 元の名前 置き換え後 石焼きいも ソーラー焼きいも 石焼きビビンバ ソーラー焼きビビンバ 石焼きそば ソーラー焼きそば 石焼きチャーハン ソーラー焼きチャーハン 石焼きカレー ソーラー焼きカレー 石焼き麻婆豆腐 ソーラー焼き麻婆豆腐 石焼き親子丼 ソーラー焼き親子丼 石焼き牛カルビ丼 ソーラー焼き牛カルビ丼 石焼き海鮮丼 ソーラー焼き海鮮丼 石焼きうどん ソーラー焼きうどん 石焼きラーメン ソーラー焼きラーメン 石焼きホルモン ソーラー焼きホルモン 石焼きハンバーグ ソーラー焼きハンバーグ 石焼きチーズリゾット ソーラー焼きチーズリゾット 石焼きオムライス ソーラー焼きオムライス 石焼きナポリタン ソーラー焼きナポリタン 石焼き豚キムチ丼 ソーラー焼き豚キムチ丼 石焼きタコライス ソーラー焼きタコライス 石焼きドリア ソーラー焼きドリア 石焼きガーリックライス ソーラー焼きガーリックライス たとえば「ソーラー焼きビビンバ」を考えると、次のような構成になりそうです。 ...