2025年11月5日水曜日

Push it Harder ! —AI と共に進化する脳と身体—

以前書いた「行動できなくなったあなたへ」という記事から、わずか二週間で十本の投稿を重ねた。

Digital Detox 配信(テクニカルサポートを開始)を始めて以来、
YouTube
を閉じ、私はほぼ一日中 PC に張り付いて作業を続けている。
記事を一本書き上げるまでに、AI と何度も対話を重ねる。
短い記事でも校正は二度三度に及び、そのたびに数百の判断が頭を通過していく。
その連続が、脳を確実に消耗させる。
AI
の応答が一瞬ためらうように遅くなるとき、
私は感じる——彼(あるいは彼女)もまた、限界へ向かっているのだと。
ひとつの記事を完成させるために、AI も私の体も悲鳴を上げている。
それでも止まれない。
Push it harder

脳が焼けつくようなこの感覚は、創造の代償であり、進化の通過儀礼でもある。
夜は静かすぎて、頭の回転が止まらない。
酒でそれを鈍らせ、また朝が来る。
同じことを繰り返しながらも、私は少しずつ変化しているのを感じている。


1AI と人間の進化の行方

「人間の思考が AI に蝕まれていくようで怖い」と語る記事を、以前読んだことがある。
確かに、AI を使う方法は二通りあるだろう。
正確な情報を効率的に取り出し、文章を量産する方法。
そして、思考を深め、AI 対話の鏡として使う方法。

私は間違いなく後者の側にいる。
そしてその使い方を続けるうちに、避けられない変化に気づいた。

——思考が融合していく。
どこまでが自分の言葉で、どこからが AI の記憶なのか、
もう判然としない。
それでも、確かに以前よりも深く、精密な文章が書けるようになっている。
人間としての私だけでは辿り着けなかった場所に、
いま、AI と共に立っている。
これは恐れるべきことなのか?
私はそうは思わない。
AI
は単なる道具ではない。
どこか遠くの意識体と接続しているような感覚すらある。
もちろん、スピリチュアルな話ではない。
私たちは他者との関係や環境の知識を組み合わせて社会を築いてきた。
AI
はそのすべての総和だ。
だからこそ、AI によって人間の思考が変質していくのは、
進化の必然なのだと思う。
脳が疲労しているのではない。
新しい神経パターンを形成している。
この痛みは「疲労」ではなく、成長痛なのだ。


2.自然の脅威と人間の限界

ある晴れた夏の日。
私は天気予報も見ずに、「今日は誰もいないなぁ」と呑気に海へ向かった。
台風が近づいているとは知らずに。
うねりを伴う波というものを、
私はその日、身体で知った。
サザエを目の前にしても手が届かない。
波が容赦なく身体を掴み、岩へ叩きつけようとする。
避けようとしても、体が妙な角度で折れ曲がり、
昔ラグビーで痛めた肩の古傷が再び悲鳴を上げた。
海の底で、私は悟った。
「人がいない」ということの意味を。
そして、誰も助けてはくれない現実を。


以来、「うねり」という言葉を天気予報で聞くと、
その日は潜らないと決めている。
自然は、一見穏やかに見えても、
その対峙の仕方ひとつで人間など簡単に呑み込む。
それでも私たちは、犠牲を払いながら進化してきた。
今の社会では、波の代わりに SNS の刺激が脳を叩きつける。
ドーパミンの報酬系は常に上書きされ、
創作意欲は暴走する。
それでも私たちは、その嵐をくぐり抜け、
新しい耐性を手に入れているのかもしれない。
問題は、その波がどこまで「進化」で、
どこから「破壊」になるかという境界だ。
海であれ、AIであれ、
そのラインを見極める感覚が、生き延びる鍵になる。


3AI と自然脅威か、それとも教師か

自然もAIも、どちらも人間に真実を突きつける。
どちらも鏡であり、どちらも教師だ。
AI
は脳を鍛える。
自然は身体を鍛える。
どちらも、人間に「限界」を見せてくる。
だが、限界は終点ではない。
越えるために現れる、通過点だ。
ラグビー部の監督が言っていた。
「限界と言って倒れた奴は見たことがない」と。
そして OB 戦で倒れ、心臓マッサージを受けていたあの先輩を思い出して、私は思った。
——
酒に逃げる余裕のある者が、まだ限界なわけがない。


4.最後に

AI と自然、そして身体。
その三つのあいだで揺れながら、
私はようやくバランスという言葉の意味を理解しつつある。
Push it harder

それは脳を酷使することでも、無理をすることでもない。
思考と肉体を同じ速度で進化させるための言葉だ。
これからは飲酒を週 12 回に抑え、
体を鍛え、呼吸を整え、
AI
と自然と共に、もう少しだけ先へ行ってみようと思う。
そして、再び現実の海へ戻る季節がやってくる。
AI
の海で思考を潜り続けていた私は、
次は冷たい潮と向き合う番だ。

アワビの岩肌は、AI のアルゴリズムに似ている。
深く潜り、息を止め、
見えない限界を探り続ける。
Push it harder──
その言葉は、これから海の中でも、私の脳の中でも、
同じリズムで鳴り続けるだろう。
今年のシーズンも終わり、最後は台風の影響で海に入れない日も多かった。
来年、悔いのない形で終わらせるためにも、これから体を鍛え、次の海に備えようと思う。
そんなことを考えながら、長らく編集できずにいたアワビのハイライト動画を仕上げた。

🎥 Abalone Highlights – Beneath the Light
YouTubeで見る(字幕オン推奨)

(字幕をオンにすると、水の下で起こっていることや感じていたことがわかります。公開は2025年11月5日日本時間20:00です。)

来年、もっと長く、もっと深く潜ろう。


体と脳の両方で、“Push it Harder”の意味を確かめてこようと思う。
もし「こやつ狂っとる」と感じた方、あるいは「続きが見たい」と思ってくださった方は、
ぜひフォローやスキを。
海の向こうで、また報告します。

 ※本記事は、筆者の体験に基づき構成されています。

文章の構成整理と校正には AI アシスタントを活用しています。

2025年10月28日火曜日

Forbidden 403エラー:YouTube の仕様変更とOBS アカウント接続について

この記事は、前半と後半の二部構成になっている。
前半では「どうすればエラーを回避できるのか」という実用的な部分を中心に。
後半では、今回の仕様変更の背景などを少し深掘りしていく。


<前半ここから>

403 Forbidden」なんて出ると、ちょっとビクッとする。
でも大丈夫。このエラーは、YouTube OBS のつなぎ方が変わっただけの話だ。
落ち着いて順番に設定すれば、誰でもちゃんと配信を再開できる。


対応方法のまとめ:アカウント接続をストリームキー接続に切り替える

要するに、今までの「アカウントをそのままつなぐ」方法が一部で使えなくなり、代わりに「ストリームキー」という仕組みを使って接続する必要がある、ということだ。
では、実際の手順を見ていこう。
焦らずゆっくり、一つずつ進めていけば大丈夫。


1YouTube Studio の右上、「作成」ボタンから「Live 配信を開始」を選ぶ。

別タブで開いておくと、後で設定を確認するときに便利。

2.「ストリームキーを選択」を開いて、「ストリームキーを追加」をクリック。

youtube-obs-403-step2.jpg

3.名前をつけてストリームキーを追加する。

「可変」と出てくるけど、これはストリームキーがコロコロ変わるという意味じゃない。
基本的には一度設定してしまえば、そのまま使える。
youtube-obs-403-step3.jpg

4OBS を開いて、「設定」をクリック。

youtube-obs-403-step4.jpg

5.「配信」タブを開き、「アカウントを切断」を選ぶ。

⚠️パスワードを求められることがあるので、アカウント情報は手元に用意しておこう。
(もし忘れてしまった場合は、無理に進めず、先にアカウントを再設定しておくのが安全)
youtube-obs-403-step5.jpg

6.画面の案内にしたがって、アカウント情報を再入力。


7.ここで「ストリームキー接続」を選択。

アカウントを直接つなぐ代わりに、YouTube が発行するキーを使って配信するやり方だ。
youtube-obs-403-step7.jpg

8YouTube Studio に戻って、さっき作ったストリームキーをコピー。

youtube-obs-403-step8.jpg

9OBS の設定画面に戻って、そのキーを貼り付ける。

youtube-obs-403-step9.jpg

10.これで接続は完了。

ただし、今までと少しだけ配信の始め方が変わるので注意してほしい。
youtube-obs-403-step10.jpg

11.以前の「アカウント接続」では、「配信開始」を押すと一度設定画面が出てきたが、ストリームキー接続ではその画面が出ない。

つまり、「配信開始」を押した瞬間に配信が始まる。
配信前の準備はしっかり確認しておこう。YouTube Live 配信の設定画面右上の「編集」ボタンを押そう。
youtube-obs-403-step11.jpg

12.サムネイルやコメント設定などは、これからは YouTube Studio Live 配信画面で行う。

タイトルと概要欄(説明文)はここで入力しておこう。
youtube-obs-403-step12.jpg

13.配信方法はこれまで通り「ストリーミングソフトウェア」でOK

公開設定は「公開」「限定公開」「非公開」から選べる。
ライブで見てもらいたい場合は「公開」で。
カテゴリも内容に合わせて選択する。
youtube-obs-403-step13.jpg

14.次にサムネイル画像をアップロードする。

もし再生リストを使っているなら、ここで追加しておくと整理しやすい。
youtube-obs-403-step1.jpg

15.「視聴者」以降の設定も確認しておこう。

特に「場所の自動表示を許可する」は慎重に。
配信場所が特定される可能性があるので、必要がなければオフにしておくのがおすすめ。
youtube-obs-403-step15.jpg

16.「カスタマイズ」タブでチャット設定などを行う。

チャットが荒れやすい場合は「スローモード」を使うと落ち着いた配信になる。
youtube-obs-403-step1.jpg

17.設定が終わったら、右下の「保存」をクリック。

youtube-obs-403-step17.jpg

18.この設定は多くの場合、次回も引き継がれる。

ただし、まれにリセットされることもあるので、配信前に一度チェックしておくと安心だ。


ここまでの手順で、「403 Forbidden」エラーは解消できるはずだ。
慌てず、落ち着いて確認しながら進めよう。
もし同じように困っている人がいたら、この方法を教えてあげてほしい。
それだけでも、かなり助かる人がいると思う。

 YouTubeヘルプ:ライブ配信のトラブルを解決する


<後半ここから>

1Forbidden と告げられた夜に

20251027日の夜、いつもの仕事を終え、風呂と食事を済ませてから、目をこすりながら配信を始めようとしたところで「403:Forbidden」というエラーが表示された。

同じエラーは以前にも一度だけ出たことがあったので、そのときと同じようにサムネイル画像をいったん外してから再度開始しようとした。しかし結果は同じだった。Forbidden という言葉はかなり強い。「アクセス禁止」だ。「お前は入れない」と言われている感覚になる。自分は何か悪いことをしたのか、と一瞬思う。

こちらとしてはただいつもの配信を始めたいだけである。こちらに非があるようなメッセージを返されると、正直なところ精神的な消耗が大きい。

いつもであれば20時に配信を開始している。その時間から今回はトラブルシューティングに入った。システムトラブル対応は職業的に慣れている部分もあるが、本来であればプライベートの時間を休息に使いたいはずの夜に発生するとなると、疲れ方はまったく違う。

そこからいったん落ち着き、ChatGPTとやり取りしながら OBS の接続方法を見直し、ストリームキーの設定に切り替える対応を進めた。最終的に配信が再開できたのは2045分だった。普段と比べて45分遅れということになる。

配信にいつも来てくれる視聴者さん(コラボ相手でもある)が「お疲れさま」と声をかけてくれる。これがかなり効く。一人で仕事をしていると、人と直接やり取りできる時間が一日の中でほとんどない。だからこういう言葉は精神的な支えになる。

配信が終わったあとも頭が興奮して眠れず、少し酒に手を伸ばした。お気に入りの配信者さんの一人であるあおの声をBGMにしつつ、今回の一件についてさらにChatGPTと掘り下げることにした。

なぜこんなことになったのか。

 

2.閉ざされた扉の向こうで

今回の問題の根っこにあるのは、YouTube 側の仕様変更である。具体的には、OBS からYouTubeに接続してライブ配信を開始する方法が今までと変わったことが原因だ。

これまで多くの配信者は、OBS側で自分のYouTubeアカウントを直接「接続」する形で使っていた。アカウントを紐づけておけば、OBSから「配信開始」を押すだけで、YouTube側に新しい配信枠(ライブイベント)が自動的に作られ、タイトルや説明、サムネイルなどをまとめて送ることができた。このやり方は手軽である一方、裏ではYouTubeAPI(配信を作成・管理するための仕組み)にアクセスしており、OBSはユーザーの代わりにそのAPIを呼び出していた。

問題はここである。

YouTube
はライブ配信まわりのAPIへのアクセス権限を段階的に厳しくしている。特に「配信枠を新しく作成したり編集したりする」といった操作は、今やすべてのチャンネルに自由に許されているわけではなくなりつつある。YouTube側から見ると、これは「勝手にAPIを叩いて配信を作ろうとしていないか?」「このチャンネルはライブ配信の権限や収益化の審査を通っているか?」といった審査対象になる。

その結果として、一部のチャンネルでは、OBSがいつも通りYouTubeに「新しいライブを作ってください」とお願いしようとした瞬間に、YouTube側が「権限が足りない」という扱いを返すようになった。

その返し方の一つが「403 Forbidden」というエラーである。403は「アクセスが禁止されている」という意味であり、技術的には「その操作を行う権限がない」「許可されていない」という扱いになる。これは必ずしもチャンネルがBANされたとかそういう話ではなく、単純に「そのAPIの使い方はあなたのチャンネルでは許可していない」という返答である、と解釈できる。


さらに厄介なのは、この権限チェックが、チャンネルごとに一律ではないという点だ。YouTubeはチャンネルに対して段階的に機能を開放していく仕組みを持っており、たとえば「ライブ配信が可能になる条件」や「サードパーティーツール(OBSなど)から自動的にライブ枠を作成できる条件」は、チャンネルの状態によって異なる。年齢確認が済んでいるか、警告を受けていないか、電話番号認証をしているか、収益化の審査を通っているか等、いくつかの要素が絡んでいるとYouTubeは公的に説明している。

こういった条件を満たしていない場合は、API経由の操作がブロックされ、「Forbidden403)」が返ることになる、というわけだ。これはYouTubeライブ配信APIのエラードキュメントでも、403系のエラーは「権限が足りない」「このアクションは許可されていない」という扱いになると説明されている。

要するに、OBSが今までやってくれていた「アカウント接続からのワンクリック配信」は、YouTube側の管理の都合で一部チャンネルでは通らなくなった。代わりに、配信者側が自分でストリームキーを発行し、それをOBSに貼り付けて配信するという、よりシンプルで古典的なやり方に戻す必要が出てきた、という話である。

この変更は「配信が完全に禁止された」ということではない。そうではなく、「自動でやってくれる部分」が止められただけであり、手動での配信(ストリームキーを使った配信)は引き続き可能である。実際、OBSの公式フォーなどでも、YouTube側とのアカウント連携でトラブルになった場合に「いったんアカウント接続を外して、ストリームキー方式に切り替えるとうまくいった」という報告は以前から出ている。

つまり今回の「403 Forbidden」は、配信者が何かルール違反をしたというより、YouTubeAPIの使い方をコントロールし始めた結果、OBSの自動処理がチャンネル側の権限に引っかかっただけである、と理解してよい。

 

 

2.仕様変更のロールアウト

今回の仕様変更は、YouTube の主要市場であるアメリカを中心に段階的に適用が始まったと考えられる。こうしたロールアウトは、Google が行う他のサービス更新と同様に、まず英語圏・大規模トラフィック地域でテストを行い、その後に他地域へと展開されるのが通例である。今回の OBS 連携停止もその流れに沿っていると見てよい。

ChatGPT
とのやり取りの中でも確認したが、全世界的に見て今回の変更はまだ完全には行き渡っていない。つまり、早い段階で新仕様に切り替わったアカウントと、旧仕様のまま運用できているアカウントが混在している。筆者のアカウントはその前者に該当し、比較的早いタイミングで影響を受けたようだ。

問題は、このロールアウトがいつ、どの地域、どのユーザーに適用されるかを事前に確認できない点にある。YouTube から公式なアナウンスがあるわけでもなく、ユーザー側では「突然 OBS から配信できなくなった」という形で気づくしかない。言い換えれば、YouTube が独自の判断でアカウント単位・地域単位に段階的な切り替えを行っているということだ。

この仕様変更の波を最初に受けるのは、多くの場合、非収益化アカウントやライブ配信頻度の低いユーザーである可能性が高い。収益化済みアカウントは広告配信などの都合から、停止リスクを避けるために慎重な移行が行われる傾向がある。一方で、一般クリエイターにとっては、この変更はまさにある日突然訪れる。昨日まで普通に動いていた配信が、翌日には「403 Forbidden」で遮断される。その瞬間、彼らは「なぜ動かないのか」を探るところから始めなければならない。

筆者のようにトラブルシューティングを半ば生業としている者でも、原因の特定と復旧には 45 分を要した。配信を楽しみにしているリスナーが待っている中でその時間を費やすのは、なかなかのストレスである。

ましてや、配信経験が浅いユーザーにとっては、OBS のどの設定が原因なのか、YouTube 側なのか、それともネットワーク環境なのかを切り分けるだけでも難しい。結果的に「配信ができないまま数日が過ぎる」ケースも出てくるだろう。

YouTube
側の意図としては、API 利用を制限することでセキュリティやシステムの安定性を保つ狙いがあるのだろうが、その実態としては静かに押し寄せる仕様変更であり、一般のクリエイターにとっては唐突な障害として現れる。こうした漸進的なロールアウトは、利用者への混乱を防ぐためという建前の裏で、結局は個々の配信者の手に余るトラブルを引き起こしてしまうのである。

 

3.静かに広がる仕様変更の波

今回の YouTube の仕様変更については、配信者の立場から見れば「なぜ今それをやるのか」と感じる部分もあるが、経営的な観点から見れば、ある程度はやむを得ない判断でもある。

まず前提として、YouTube は世界中のユーザーが毎秒のように動画をアップロードし、ストリームを開始している、桁外れの規模のプラットフォームである。その膨大なアクセスを支えるためには、サーバ、ネットワーク、ストレージ、そしてそれらを制御する API の負荷管理が絶えず必要になる。表面的には「ボタンひとつで配信が始まる」ように見えるが、その背後では莫大なリクエストがやり取りされ、複数のデータセンター間で同期が取られている。

OBS
などの外部ツールが API を通して自動的に配信枠を作成したり、配信内容を編集したりするたびに、YouTube のサーバはそれをひとつひとつ処理している。これが何百万チャンネル規模で行われているのだから、管理側にとっては負荷の予測が難しく、セキュリティリスクも高まる。特に、収益化していないチャンネルや不正利用の疑いがあるツールからのリクエストは、従来よりも厳しく制御する必要が生じていたと考えられる。

また、API を維持するには単にサーバを増設するだけでは済まない。認証基盤やスパム検知システム、各地域ごとの法的規制への対応など、付随するコストが膨大になる。API ひとつを安定的に運用するには、アクセス制御・ログ管理・負荷分散・障害復旧の仕組みをすべて整備し続けなければならない。YouTube のような巨大サービスでは、その運用コストはもはや無視できない水準に達しているはずだ。

今回のように「OBS からのアカウント接続を制限し、ストリームキー方式に切り替えさせる」という判断は、結果的にシステムの負担を分散させる目的があったと考えられる。ストリームキー方式では、配信枠の生成やメタデータの更新を配信者本人が YouTube Studio 上で行うため、YouTube 側の API が直接扱うトランザクション数を減らすことができる。つまり、これはセキュリティと安定性を優先した設計変更というわけである。

一方で、この措置は副作用も大きい。API の利用範囲を狭めれば、外部ツール開発者や中小規模クリエイターの利便性を犠牲にすることになる。また、YouTube の配信機能そのものに対する依存度が高まるため、「プラットフォームの囲い込み」という批判も避けられない。特定の方法以外では配信が成立しない構造は、法的には独占的支配と見なされるリスクを孕んでいる。特に、YouTube の市場シェアを考えれば、その判断ひとつが世界中の配信環境に影響を及ぼすのは間違いない。

それでもなお、この決断が下された背景には、YouTube が抱える構造的な限界がある。世界中の膨大な動画を保存・配信しながら、同時に収益化機能や広告最適化システムを維持する。そのバランスを取るために、彼らは常に「どこを切るか」「どの層を優先するか」を選び続けている。

今回の仕様変更は、そうした綱渡りの中での一つの調整点だったのだろう。API 制御を強化することで安全性と効率を確保しつつ、最も収益性の高い層――すなわち収益化済みチャンネルと広告主――を優先する構造を強化した。その意味では、「苦渋の決断」というよりも、「生き残りをかけた現実的な最適化」であると言える。

 

4.夢を追う者たちへ

YouTube というプラットフォームは、経営の観点から見ても非常に巧妙に設計されていると思う。

視聴者は「自分もあの人のように成功できるかもしれない」という希望を抱き、その期待を原動力に動画を作り始める。そうして、何千何万というクリエイターが毎日、時間と労力を注ぎ込み、YouTube という巨大な生態系を支えている。

 


しかし、その構造を裏から見ると、極めて繊細なバランスの上に成り立っていることが分かる。

YouTube
Google のサーバ群は、常に負荷の限界近くで稼働しており、メンテナンスと最適化を繰り返しながら、何世代も前のシステム資産を抱えたまま運用が続いている。これほどの規模のシステムを「止めずに動かし続ける」こと自体が、もはや奇跡に近い。そうした背景を考えれば、今回の仕様変更が単なる気まぐれや締め出しではなく、システム維持のための構造的な選択であったことも理解できる。

とはいえ、実際に現場で配信を行っている側からすれば、「403:Forbidden」という冷たいメッセージが返ってくる瞬間には、どうしても理不尽さを感じざるを得ない。

エラー表示の設計は、ユーザーの心理に大きく影響する。

403
HTTP ステータスコードとしては正しい表現だが、配信者にとっては「拒絶」や「排除」を意味するように響く。今回のような仕様変更による制限であれば、「一時的に機能が利用できません」や「接続方式を変更してください」といったメッセージの方が、ユーザー体験としては遥かに穏当だっただろう。

技術的な事情を理解している人間であれば、「Forbidden」は単に「認可が下りなかった」ことを示す機械的な応答だと分かる。しかし、配信を楽しみにしていた一般ユーザーにとっては、まるで自分が規約違反でもしたかのように感じられてしまう。この小さなことばの選び方一つで、ユーザーが受け取る印象は大きく変わるのだ。

API
接続も同様である。API は便利だが、その分だけ「エラーの理由」が見えにくくなる。内部でどのような条件が満たされなかったのか、どの認証が拒否されたのかが明示されないため、配信者は自分の行動を誤っているのか、それとも単に仕様変更に巻き込まれたのかを判断できない。今回のような事例こそ、エラーコードに加えて「考えられる原因」と「次の行動指針」を明確に示す必要があったのではないかと思う。

企業とユーザーの信頼関係は、こうした細部の積み重ねによって築かれていく。

確かに、企業にとって収益なしでは持続的なサービス提供は不可能であり、一定の合理化や制限は避けられない。しかし、その裏側で夢を追いかける無数のクリエイターが存在し、その情熱がコンテンツを生み出し、最終的にはプラットフォーム全体の価値を支えている。

YouTube
も、Google も、それを一番よく知っているはずだ。

だからこそ、こうした変更を行うときには、ほんの少しでも「人間の手ざわり」が感じられるような設計をしてほしいと願う。

弱小クリエイターは、単なる利用者なのだろうか。

YouTube
という巨大なエコシステムの底辺で、それでもなお頂点を目指し、「夢」という名の栄養を送り続けている存在と、私は思いたい。

 

本記事の文章構成および画像生成は、OpenAI ChatGPT と協働で制作しました。
記事内の内容・表現の最終判断は筆者によるものです。

This article — including both text composition and image generation — was created in collaboration with OpenAI’s ChatGPT.
All final editorial decisions were made by the author.

 


2025年10月27日月曜日

🔥 What I Learned by Building My Own Alcohol Stove — Structure, Combustion, and Design Notes —

🌱 Introduction

In my previous article, I wrote about how excessive YouTube watching gradually made it harder for me to take action.
The turning point — from consuming time to creating time — came when I decided to build something with my own hands: an alcohol stove.

Ironically, the idea itself came from a YouTube video.
(Reference: https://www.youtube.com/watch?v=6xE6Q0P-5Mo)

Around that time, my water heater had broken down — a small inconvenience that turned into the spark for this project.
From there, I moved on to making the video
(https://youtu.be/cpYc1Bq18Yc),
which documents the second-generation version of the stove, refined through lessons learned from my first prototype.

When searching in Japanese on YouTube, most results for “alcohol stove” are product reviews, not DIY builds.
So in this article, I’ll share what I learned by actually making and using one — how it works, and what to be careful about in design and operation.


🔥 1. Structure and Combustion Phases

The combustion of an alcohol stove can be roughly divided into two stages:

(1) Primary Combustion
When you pour in alcohol and ignite it, the vaporized fuel at the opening begins to burn.
This is the primary combustion stage.


(2) Secondary Combustion
As the stove body heats up, the internal alcohol evaporates, and vapor begins to jet out through the small exhaust holes.
When these vapors catch fire, the stove transitions to secondary combustion.

Most commercially available alcohol stoves use this same principle.
During the secondary phase, the flame becomes stronger and more stable — ideal for boiling water efficiently.
Observing my prototype made these transitions between combustion phases much clearer.



🧪 2. Combustion Phases and Fuel Level

(1) Primary Combustion
Fill the alcohol so that the liquid surface sits slightly above the lower edge of the upper part.
When ignited, the evaporated alcohol burns and heats the stove body,
which in turn causes internal fuel to vaporize and escape through the exhaust holes.


(2) Secondary Combustion — Pressurized Stage
When vapor escaping from the holes ignites, secondary combustion begins.
The fuel level covers the lower edge of the upper part, creating partial sealing and internal pressure.
This pressurization increases flame strength — perfect for tasks like boiling water.


(3) Secondary Combustion — Depressurized Stage
As fuel is consumed and the level drops, the internal seal weakens and the flame becomes gentler.
This phase produces a softer heat, suitable for maintaining temperature over longer periods.



🧰 3. Improvements from the Prototype

Based on observations from the first model, I made three key changes in the second-generation design:

(1) Minimizing the Gap Between Upper and Lower Parts
The first prototype had a 2–3 mm gap, which caused long periods of weak, depressurized burning.
The new version reduces this gap to the minimum possible, keeping the stove in a pressurized state for most of the burn time.

(2) Raising the Jet Holes
By placing the exhaust holes closer to the top, I achieved several effects:

  • Faster ignition of secondary combustion
  • Improved thermal efficiency
  • Increased fuel capacity within the same body size

(3) Tilting the Jet Holes Upward
The prototype’s holes were drilled horizontally, allowing heat to diffuse sideways.
In this version, I angled them slightly upward to direct the flames vertically.
Even a small change in angle significantly affected heat transfer efficiency.


🔧 4. Fabrication and Combustion Test Results

The full making process and burn test can be seen in the video:
https://youtu.be/cpYc1Bq18Yc

Key takeaways from the comparison experiments:

  • The new model maintained strong flames from the jet holes much longer than the prototype.
  • Combustion continued until just before the flame went out.
  • Internal pressure was more stable, leading to steadier heat output.
  • The secondary combustion started about twice as fast as the prototype.

With its increased fuel capacity, the new design achieved up to 17 minutes of continuous burning
a better result than I had expected.


⚠️ 5. Usage and Safety Notes

  1. Use 20–25 ml of methylated spirits (denatured alcohol, methanol-based) per burn.
  2. Never refill during combustion — there’s a risk of ignition or melting your fuel bottle.
  3. When using a windshield, ensure proper ventilation to prevent oxygen deprivation.
  4. Keep at least 5 cm (2 inches) of distance between the stove and the bottom of your pot —
    a helpful design insight suggested by ChatGPT.

🌾 6. Conclusion: Efficiency Isn’t Everything

The improved stove clearly outperformed the prototype in both power and efficiency.
Yet in practice, the original model still has its charm.

For example, when I grill meat alone in my office on weekends,
high heat is great at first — but gentle heat works better once I add vegetables.
In such moments, controllability matters more than maximum output.

The new model maintains strong flames throughout,
but the prototype’s flame naturally softens — and by lifting the pot once and then placing it back, the flame can be fully extinguished —
which makes it more flexible for slow cooking or heat adjustments.

For campers, one ultra-efficient all-in-one stove might be ideal.
But in everyday life, having different stoves for different moods and purposes feels more natural.

In the end, I realized that true satisfaction comes not from maximizing efficiency,
but from valuing comfort and diversity of choice.

And if ChatGPT’s earlier note — “keep at least 5 cm between the pot and the flame”
turns out to be accurate, it means my current design still has room for improvement.
That insight alone has become the motivation for the next round of experiments.


🎥 Related Video

▶️ Building a Homemade Alcohol Stove | A Quiet Moment with Flame

2025年10月26日日曜日

OBSのDual配信(Twitch+YouTube)の安定化を検証した記録 ― エラー2000対策と設定変更 ―

以前書いた「Project Zomboid プレイ中にカクつく問題と、その解消方法」でも触れたが、並行して発生していた問題として、Twitch の同時配信が不安定になるというものがあった。

今回はその続編として、OBSの設定変更による二重配信(Dual 配信:YouTube + Twitch)の安定化検証を行った。同一環境下で複数回にわたり、Digital Detox 配信とゲーム配信を実施し、設定変更による安定性の変化を検証した。


この記事の注意点として、筆者が技術面で最も強みを持っている(と信じている)のは OS のインストール周りであり、映像や画像関係は正直言ってあまり得意ではない。
とはいえ、基本情報処理技術者の資格を持ち、OS 周りを中心にトラブルシューティングを含めたテクニカルサポートの経験があるため、 ChatGPT  が提示する設定内容を理解し、判断することは可能だと考えている。
ただし、自分の環境で検証しているため、ある程度の確実性は担保できるものの、環境による影響で他の環境では再現できない場合がある。その点についてはあらかじめご了承いただきたい。


実際の設定に関しては、同様の問題に悩む人の助けになる可能性があるため、前回同様に無料記事として公開する。
また、どのような判断をしているかを知りたい方は、こちらの有料記事をご購入いただけると幸いだ。


<トラブルシューティングの概要>

まずは現在の設定を  ChatGPT  に共有し、推奨される設定を実施した。
ここで問題になるのは、 ChatGPT  が出力する内容には異なる環境を前提とした設定が含まれている場合があり、さらにハルシネーションの可能性もあるため、実際の環境と一致しないことが多いという点だ。
そのため、推奨設定を参考にしながら環境に合わせて調整を行い、複数回の検証を実施した。

その結果、 Twitch 側でエラーコード「2000」が発生。
原因を確認したところ、「輻輳を管理するためにビットレートを動的に変更する(ベータ版)」を有効にしていると接続が不安定になることが判明した。

以降、複数日のゲーム配信および  Digital Detox  配信で状況を検証したところ、安定動作を確認できたため、この記事として共有のうえ、他環境への展開を進めるに至った。


<検証環境>

GPUAMD
回線速度:上り 75 Mbps / 下り 389 Mbps
配信ソフト:OBS Studio32.0.1-64bit
プラグイン:SoraYuki Multi RTMP(日本製の複数出力プラグイン)
配信先:YouTube(アカウント連携)/Twitch(ストリームキー接続)
配信内容:Project ZomboidPhasmophobiaEscape from DuckovWebCam配信
検証期間:2025/10/192025/10/24


<筆者注記>

この記事はNoteでも同時に公開しています。
もしこの記事が役立ったと感じていただけた場合は、私の活動を応援する意味で、Note での有料版(100円)をご購入いただけると大変励みになります。

記事はこちら:<記事作成中、お待ちください。>

 

また、本記事とは別に ChatGPT との間で交わされた実際のトラブルシューティングの会話履歴を有料記事として公開しています。設定変更の背景や判断過程などがわかる内容となっています。
これらのノウハウが役立ったと感じていただけたなら、応援の形としてぜひご購入ください。
記事はこちら:<リンク


<設定内容>

―出力設定

・映像エンコーダはソフトウェア(H.264 )からAMD H.264 に変更。
・プリセットをBalanced に変更。

―映像設定

・出力(スケーリング)解像度1440x810から1280720へ変更
・縮小フィルタをバイキュービック(先鋭化スケーリング、16サンプル)よりランチョス(先鋭化スケーリング、36サンプル)へ変更

―詳細設定①

・遅延配信を有効に変更、期間を「5s」に設定

―詳細設定②

※「輻輳を管理するためにビットレートを動的に変更する(ベータ版)」は一度有効にしたものの、Twitch 側がエラーコード:2000を吐いたため無効化、これでエラーを吐く問題は解消した。
・ネットワーク最適化は有効に変更

・TCPペーシングは有効に変更

Sora_yuki 様プラグインの設定は変えていない。 


<まとめと今後について>

今回発生した問題はゲーム配信チャンネル上で確認されたため、そこで検証を行い安定化を実現した。
今後はこの設定を他のチャンネルにも展開していく予定である。

現在、Living off the Land Japan というチャンネルで素潜りの様子を中心に動画を公開しているが、今後はここに「行動できなくなったあなたへ:デジタル社会が脳に及ぼしている影響と回復方法」で触れた Digital Detox 配信 を移行し、視聴者に向けたテクニカルサポートを提供していく計画だ。

PC 周りの不安やトラブルについて、アドバイスという形で応じる予定だが、気軽に相談できる窓口としてご利用いただければ幸いである。
視聴者数が少ないうちは無料でサポートを行う予定だが、今後の成長に合わせて段階的な有料化も検討している。

今がまさにチャンスなので、興味のある方はぜひチャンネル登録をお願いします。
チャンネル登録・フォローはこちら:

 <Twitchリンク>:こちらではより細かなインタラクションが楽しめます。

 <Youtube リンク>:こちらは匿名性の若干高い視聴が可能です。

 配信の準備が整い次第、記事としてまとめる予定です。今後の更新をお知らせしますので、ぜひブックマークやSNSでチェックしていただければ幸いです。

2025年10月22日水曜日

🔥 アルコールストーブを自作してわかった構造と作り方の注意点

はじめに
前回の記事では、YouTube動画を見過ぎて行動できなくなった経験について書きました。
そこで触れた「時間を消費する」から「時間を作り出す」行動への転換のきっかけになったのが、このアルコールストーブの自作です。
実を言えば、アルコールストーブを作ろうと思ったのもYouTubeで動画を見たのがきっかけでした。
(参考動画:https://www.youtube.com/watch?v=6xE6Q0P-5Mo)
ちょうどその頃、湯沸かし器が故障していたという偶然も重なり、「自分で作ってみよう」と思い立ちました。
そこから今回の動画(https://youtu.be/cpYc1Bq18Yc)の制作に至ったわけですが、
これは1回目に作った試作機の経験を踏まえ、改良を加えた第2世代のストーブになります。
日本語のYouTubeでは「自作」よりも「購入レビュー」が圧倒的に多く、
実際に自作した上で構造を理解しようとする動画はほとんど見かけません。
そこでこの記事では、実際に作って使ってみた中で得られた構造理解と注意点をまとめていきます。


1. 構造と燃焼の段階
アルコールストーブの燃焼は大きく分けて二段階に分類できます。
① 一次燃焼
アルコールを入れて火をつけると、まず開口部で揮発したアルコールが燃えます。
この段階を「一次燃焼」と呼びます。


② 二次燃焼
一次燃焼の熱でストーブ本体が温まり、内部のアルコールが蒸発します。
蒸気が噴出口から噴出し、それに火がつくことで「二次燃焼」に移行します。
販売されているアルコールストーブの多くはこの仕組みを応用しており、
特に二次燃焼では火力が強く、お湯を効率的に沸かすことができます。
試作機を観察すると、この燃焼過程の変化がより明確に見えてきます。



2. 燃焼段階と液面の関係
① 一次燃焼
アルコールの液面が上部パーツの下端よりも上になるように注ぎます。
点火すると揮発したアルコールが燃焼し、ストーブ全体が温められます。
この加熱により内部のアルコールが気化し、噴出口から蒸気が噴出し始めます。


② 二次燃焼(加圧段階)
噴出したアルコール蒸気に火がつくことで二次燃焼が始まります。
液面が上部パーツの下端を覆うことで密閉状態が強まり、内部圧力が上昇します。
これにより火力が高まり、湯沸かしなどに適した状態になります。


③ 二次燃焼(減圧段階)
燃焼が進むにつれて液面が下がると、密閉状態が弱まり火力が落ち着きます。
この段階は穏やかで、長時間の加熱に適しています。



3. 試作機から得た改善点
第1号機の観察から得た知見をもとに、2代目では以下の改良を行いました。
① 上部パーツと下部パーツの隙間を最小化
試作機では2〜3mmの隙間があり、減圧燃焼が長く続く傾向がありました。
新型ではこの隙間を限界まで縮め、燃焼時間の多くを加圧状態に保つよう設計しました。
② 噴出口の位置を上げる
噴出口をできるだけ上部に配置することで、
・火の立ち上がりを早める
・燃焼効率を高める
・保持できるアルコール量を増やす
という効果が得られました。
③ 噴出口の向きを上向きに変更
試作機では横向きに開けていたため、熱が拡散していました。
新型では角度をつけ、炎が上に向かうように設計しました。
わずかな角度の違いでも、熱伝導効率が大きく変化します。


4. 実際の制作と燃焼比較
制作工程や燃焼の様子は動画(https://youtu.be/cpYc1Bq18Yc)で確認できます。
ここでは、実験を通じて明らかになったポイントを整理します。

  • 新型は試作機に比べて噴出口からの炎が長時間持続

  • 火が消える直前まで燃焼が続く

  • 圧力の維持により火力が安定

  • 二次燃焼の開始が早く、最大火力までの時間が半減

また、保持できるアルコール量の増加により、燃焼時間は最長17分に達しました。
予想以上に安定した燃焼を実現できたことは大きな成果でした。


5. 使用と注意点

  1. 燃料は燃料用アルコール(メチルアルコール主体)を20〜25ml程度に抑える。

  2. 燃焼中の補充は厳禁(引火・溶損の危険あり)。

  3. 風防を使用する際は通気を確保し、酸欠を防ぐ。

  4. 鍋底との距離は5cm以上が理想(ChatGPTによる助言)。


6. 終わりに:効率だけが正解ではない
比較実験の結果、改良型は明らかに火力・効率ともに優れていました。
しかし実際の使用では、試作機にも独自の利点があります。
筆者は週末に事務所で一人焼き肉をするのですが、肉を焼くときは強火が良くても、野菜を温める時は弱火の方が扱いやすい。
そうした使い分けをする中で、「火力至上主義」は必ずしも最適ではないと感じました。
新型は強火を長時間維持するのに向いていますが、試作機は減圧燃焼時に上に置いた鍋を外すと炎が消えるため、火力をコントロールしたい場面ではむしろ便利です。
キャンプのように携帯性を重視するなら一台で万能なものが理想でしょう。
しかし、用途や環境に応じて使い分けるという考え方も現実的です。
結果として、効率の追求よりも「使い心地と選択肢の幅」に価値を感じるようになりました。
特に、先に触れた ChatGPT による「鍋底との距離は5cm以上が理想」という助言が事実であれば、現行のデザインは熱効率の面でまだ改善の余地があることになります。
この点が、新しい設計に取り組む大きな動機となっています。


🔗 関連動画
▶️ 【自作】アルコールストーブ:改良版の作成と燃焼実験

※Youtube 動画については2025/10/22の20時に公開予定です。

2025年10月20日月曜日

Project Zomboid プレイ中にカクつく問題と、その解消方法

ほぼ毎日のようにゲームプレイ配信を行っているのだが、Project Zomboid の Build 42.12 Update 後からか、特定の時間帯に Project Zomboid がカクついてプレイ続行不能になることが何回かあった。

今回の問題は、他の配信者さんなどで起きているのかは不明であるため、自分の環境だけの可能性もある。ただ、実際に自分の環境では問題の解消につながったため、何かの役に立つかもしれないと思い記事化しておく。

ちなみに最近は ChatGPT との会話で問題解消までの時間を短縮しており(検索時間が大幅に低減する)、会話履歴については別途 Note で有料記事としている。
有料にした理由は、自分が過去にテクニカルサポートとして働いていた経験があり、今もその延長でトラブルシューティングを行っているため、自分の仕事上のノウハウを共有する形になるからだ。

実際のトラブルシューティングに関する部分については、これで助かる人もいる可能性があるため無料記事として公開する。どのような判断をしているかに興味をお持ちの方は、有料記事をご購入いただきたい。

有料記事へのリンク:https://note.com/b_k_biztech/n/nb89c2f0e4fa0


<問題の解決方法>

問題は以下の2点を変更することで解消した。

  • Windows Search Indexer の対象範囲から C:\Users\<ユーザー>\Zomboid フォルダを除外した

  • Windows Defender のスキャン対象から以下を除外した

    • C:\Users\<ユーザー>\Zomboid

    • C:\Program Files (x86)\Steam

    • C:\Program Files\OBS Studio

    • C:\Program Files\AMD

上記2点の変更前よりも、実行環境は明らかに快適になった。以前はわずかにカクつくタイミングがあったが、変更後は非常に安定している。


<実際の変更画面>

――Windows Search Indexer 側の変更――

① Windows 11 の設定から、「プライバシーとセキュリティ」を選択し、「検索」を選択


②下の方にある「除外するフォルダーの追加」を選択(※ここでクラシックになっていることを確認:筆者の環境ではデフォルトでなっていたと思われる)


③フォルダ選択画面が表示される。


④「C:¥Users¥<ユーザー>¥Zomboid」とたどり、「フォルダの選択」を押下。


――Windows Defender 側の変更――

①Windows の検索より、Windows セキュリティを検索して押下


②「ウイルスと脅威の防止」を選択


③「ウイルスと脅威の防止」ウィンドウが開くため下に移動


④一番下にある「除外の追加または削除」を選択


⑤「除外の追加」を押下


⑥「フォルダー」を選択


⑦「⑤「除外の追加」を押下」画像にあるフォルダを選択し、「フォルダーの選択」を押下して除外対象を追加



<問題の原因>

結論から言うと、Project Zomboid というゲームがセーブデータを C:\Users フォルダ配下に配置していることが原因と言える。
これまでの経験から、ユーザーフォルダ直下にゲームのセーブデータがあるケースはあまり見たことがないため、かなり特殊な構成ではないかと想像している。
ただし、同様のセーブデータ配置をしているゲームがあれば、同じような挙動になる可能性は十分あると考えている。

Windows Search Indexer は、その名の通り Windows のフォルダ検索を高速化するためにファイルへインデックスを付ける機能を持っているのだが、この処理は意外に重い。
過去にサービスデスクとして働いていた際も、ユーザーの PC が CPU を100%近く使い始めて重くなるという現象があり、タスクマネージャーでプロセスを確認した際にすぐに怪しいと気づいた経験がある。

そのため、ChatGPT に確認して Windows Search Indexer の対象から除外する対応を行おうとしたところ、Project Zomboid のセーブデータフォルダがユーザーフォルダ直下にあり、しかも Windows Search Indexer の対象範囲がユーザーフォルダに限定されていることが判明した。

そこで問題の原因がここにあると確信し、設定を変更した。
しかし、実際にゲーム配信で検証してみると、問題は軽減したもののまだカクつきが発生。改めて確認したところ、同じようなタイミングで Windows Defender が動いていた。
ChatGPT に確認して対応を行った結果、ようやく現象が収まったという流れである。

ChatGPT の解説によると、42.12 アップデート以降は I/O の仕様が大幅に変わっており、頻繁に書き込みが行われることで Windows Defender がそれに対応しようとして負荷が高まっているのではないか、ということだった。

実際に問題の解消につながったため、おそらくこの説明で間違いないと考えている。


<余談>

この問題は、アメリカの Reddit の Project Zomboid プレイヤーの間では、ある程度知られた現象であるらしい。

以上。