2026年9月6日日曜日

放置ブログの最初にやるSEO設定 Search Console・サイトマップ・HTTPS・Bing

 前回、ブログを再開して記事を書いていたにもかかわらず、Googleに十分クロールされていなかったことを書きました。今回は、実際に何を確認して、どこを直したのかをまとめます。

まずHTTPSを確認する

Bloggerでは「設定」→「HTTPS」にある「HTTPSリダイレクト」を確認します。ここがオンなら、HTTPでアクセスされてもHTTPSへ転送されます。

昔から使っているブログでは、この設定がオフのまま残っていることがあります。実際、自分の古いBloggerを確認したところ、複数のブログでHTTPSリダイレクトが切れていました。

今のWebではHTTPSが標準なので、古いブログを再開した場合は最初に見ておいた方がいい項目です。

Search Consoleには現在のURLを登録する

次にGoogle Search Consoleです。

ここで気をつけたいのが、現在実際に使われているURLと、Search Consoleへ登録しているURLが一致しているかどうかです。

たとえば、

http://example.blogspot.jp/

https://example.blogspot.com/

は、見た目は似ていますが同じではありません。実際に古い blogspot.jp のURLをSearch Consoleへ登録していたため、現在の記事URLを検査すると「URLがプロパティ内にありません」と表示されたブログもありました。

一番確実なのは、ブログを普通にブラウザで開き、アドレスバーに表示されている現在のトップページURLをそのままSearch Consoleへ登録する方法です。

sitemap.xmlを送信する

Search Consoleへ登録したら、左メニューの「サイトマップ」を開きます。

Bloggerの場合は通常、

sitemap.xml

を入力して送信します。

送信に成功すると、Googleがサイト内に存在するURLを把握するための手掛かりになります。サイトマップを送ったからといって、すべての記事が必ずインデックスされるわけではありません。それでも、長期間止めていたブログや、Googleのクロールがほとんど来ていないブログでは重要な作業です。

自分のブログでは、Search ConsoleのページレポートにはほとんどURLが出ていなかったのに、サイトマップを送信するとたくさんのページが検出されたケースもありました。

URL検査で本当にクロールされているか確認する

次に、最近の記事をいくつかURL検査します。

Search Consoleでは、記事ごとに

「Googleに登録されています」

「検出 - インデックス未登録」

「クロール済み - インデックス未登録」

「ページにリダイレクトがあります」

などの状態が表示されます。

「検出 - インデックス未登録」は、GoogleがそのURLの存在は知っているものの、まだクロールしていない状態です。

「クロール済み - インデックス未登録」は、Googlebotが実際に記事を取得したものの、現時点では検索インデックスへ登録していない状態です。

この違いが分かるだけでも、「記事が悪いのか」「Googleがまだ見に来ていないだけなのか」を切り分けやすくなります。

Bing Webmaster Toolsも使ってみる

今回、GoogleだけでなくBing Webmaster Toolsにもブログを登録しました。

Bing Webmaster Toolsでは、Google Search Consoleからサイトをインポートできます。すでにSearch Consoleへ登録しているブログなら、かなり簡単に追加できます。

Bingの面白いところは、URLごとのSEOチェックがかなり具体的なことです。

実際に確認すると、

「Meta Descriptionタグがありません」

「画像のAlt属性がありません」

「複数のH1タグがあります」

「タイトルが長すぎます」

といった指摘が表示されました。

全部が致命的な問題というわけではありませんが、記事を整える時のチェックリストとしてはかなり便利です。

H1は記事タイトルだけにする

Bingで複数H1の警告が出たことで、見出し構造も見直しました。

ブログ記事の場合は、記事タイトルがH1になることが多いため、本文ではH1を使わず、大見出しをH2、その下をH3にする形が分かりやすいです。

見た目を大きく変えなくても、HTML上の構造だけ整理できます。

今後、自分のブログでは、

記事タイトル:H1
本文の大見出し:H2
その下の見出し:H3

という形に統一することにしました。

検索向け説明も入れる

BloggerやSeesaaには「検索向け説明」や「Meta Description」に相当する欄があります。

これは記事内容を短く要約するためのものです。検索順位を直接大きく上げるものではありませんが、検索結果で記事の内容が伝わりやすくなるため、重要な記事には入れておく価値があります。

文章は日本語で問題ありません。記事の内容を80〜120文字程度で自然に説明するくらいで十分です。

画像を使うならalt属性も入れる

画像そのものはSEOの必須条件ではありません。文章だけの記事でも検索には出ます。

ただ、画像を使う場合はalt属性を入れておいた方がいいです。Bingでも、画像にalt属性がないとSEO上の警告として表示されます。

画像が何を表しているのかを短い日本語で説明しておけば十分です。

IndexNowという仕組みもある

BingにはIndexNowという仕組みもあります。

これは新記事を公開したり、記事を更新したり、URLを削除した時に、検索エンジンへすぐ知らせるための仕組みです。クローラーが来るのを待たずに更新情報を通知できます。

一方、BloggerやSeesaaのような無料ブログでは、認証用ファイルをサイト直下へ置けないため、手動での導入が難しい場合があります。

その場合でも、Bing Webmaster Toolsへの登録とサイトマップ送信までやっておけば十分意味があります。

記事を書く前に検索エンジンへの入口を確認する

今回の経験から、ブログを再開する時の確認順はかなりはっきりしました。

まずHTTPSが正常か確認する。次にSearch Consoleへ正しいURLを登録し、サイトマップを送る。その後、URL検査でクロールとインデックスの状態を見る。Bing Webmaster Toolsでも同じように確認する。

そこまで確認してから、タイトル、meta description、見出し構造、画像altなどを整える。

記事を書いても、検索エンジンが存在を把握していなければ検索流入は生まれません。長く止めていたブログを再開する場合は、記事を書く前に一度この辺りを確認しておいた方がよさそうです。

PVが増えない原因を必死に学んだ

 ブログを再開してから、かなり記事を書いていました。ところが、いつまで経ってもアクセスが増えません。もちろんブログというものは、記事を書いたからといってすぐ読まれるわけではありませんし、検索順位が上がるまで時間がかかることもあります。

それでも、あまりにも反応がありませんでした。「いくらなんでもこれはおかしいだろう」と思ってGoogle Search Consoleを詳しく調べてみたところ、予想していなかった状態になっていました。

記事を書いてもGoogleが見に来ていなかった

Search Consoleには、各URLがGoogleにどう認識されているか確認できる「URL検査」という機能があります。そこで最近書いた記事を調べてみると、「URLはGoogleに登録されていません」と表示されました。

さらに別の記事では、「検出 - インデックス未登録」となっていました。これは、GoogleがURLの存在自体は知っているものの、まだ実際にはクロールしていない状態です。

つまり、記事を書いて公開していたのに、Googlebotが本文を読みに来てすらいなかったわけです。

クロールとインデックスは別物だった

今回改めて理解したのが、「クロール」と「インデックス」は別だということでした。

クロールは、Googlebotが実際にページを読みに来ること。インデックスは、そのページをGoogle検索のデータベースへ登録することです。

そのため、「検出 - インデックス未登録」なら、URLは知っているがまだ読んでいない状態。「クロール済み - インデックス未登録」なら、Googleは実際にページを読んだものの、現時点では検索インデックスへ登録していない状態です。

Search Consoleを見なければ、この違いにはなかなか気づけません。

サイトマップを送っていなかった

さらに確認すると、Search Consoleの「サイトマップ」が空でした。そこでBloggerのサイトマップである sitemap.xml をSearch Consoleから送信しました。

すると、これまでSearch Consoleのページレポートではごく少数しか認識されていなかったブログで、サイトマップから300ページ以上が検出されました。ブログには昔から大量の記事があるのに、Google側で十分に処理されていなかった可能性が見えてきました。

サイトマップを送信するというのは、ファイルをGoogleへアップロードすることではありません。「このURLにサイトマップがあります」とGoogleへ知らせる作業です。

昔のBloggerではHTTPS設定も確認した方がいい

もう一つ見つかったのがHTTPSです。

昔から使っているBloggerを確認すると、「HTTPSリダイレクト」がオフになっているブログが複数ありました。これをオンにすると、http:// でアクセスされた場合でも https:// へ転送されるようになります。

昔から運営しているブログの場合、HTTPSが一般化する以前の設定がそのまま残っていることもあります。長期間放置していたブログを再開する場合は、一度確認しておいた方がよさそうです。

「PVが少ない=記事が悪い」とは限らない

今回一番大きかったのはここでした。

アクセスが増えないと、つい「記事がつまらないのか」「SEOが弱いのか」「タイトルが悪いのか」と内容の方を疑ってしまいます。けれど、その前に確認すべきことがあります。

そもそも検索エンジンに見つけてもらえているのか。クロールされているのか。インデックスされているのか。ここを確認しないまま記事を改善しても、検索結果に出ていなければ評価以前の問題です。

今回の経験から、今後はまず検索エンジン側の入口を確認してから、記事内容を分析することにしました。

2026年9月5日土曜日

X新規アカウントを匿名運用する時の初期設定チェック

 


Xの新規アカウントは作るだけなら簡単ですが、匿名運用するなら最初に設定確認が必要です。

  • メールアドレスで見つけられる設定をOFF

    • 設定とプライバシー

    • プライバシーと安全

    • 見つけやすさと連絡先

    • 「メールアドレスの照合と通知を許可する」をOFF

  • 電話番号で見つけられる設定をOFF

    • 同じ「見つけやすさと連絡先」内でOFF

  • 連絡先同期をOFF

    • 「アドレス帳の連絡先を同期」をOFF

  • アップロード済み連絡先を確認

    • 「連絡先を管理」を開く

    • 何も表示されていなければ、少なくとも削除対象のインポート済み連絡先はない

    • もし残っていれば「連絡先をすべて削除」

  • iPhone側でもXの連絡先権限をOFF

    • 設定

    • プライバシーとセキュリティ

    • 連絡先

    • XをOFF

  • 位置情報をOFF

    • X側の「ポストに位置情報を追加」をOFF

    • iPhone側も

      • 設定

      • プライバシーとセキュリティ

      • 位置情報サービス

      • X

      • 「しない」

  • EdgeでXが変な日本語になる場合

    • Edgeの自動翻訳をOFF

    • X本体の表示言語を日本語に変更する

ついでに確認したこと

iPhone側のアプリ権限は、不要なら切っておく方が安心です。

  • LINEの連絡先フルアクセス → 不要ならOFF

  • Gmailの連絡先アクセス → 宛先候補などが不要ならOFFでも利用可能

基本は、

アプリ内の同期OFF + iPhone側の権限OFF

の二重で止めておくと分かりやすいです。

2026年9月4日金曜日

ChatGPTだけ404で開けない?Wi-Fiでは繋がらず4Gでは繋がった時に確認したこと

 


突然、ChatGPTを開こうとしたところ、ブラウザに「ページが見つかりません」と表示され、404エラーのような状態になりました。

最初はChatGPT側の障害かと思ったのですが、試しにiPhoneのWi-Fiを切って4G回線に変更すると、普通にChatGPTへ接続できました。

一方で、Wi-Fi接続中でも他のWebサイトは問題なく閲覧できていました。

今回の症状を整理すると、次のような状態です。

  • Wi-FiではChatGPTだけ開けない

  • 他のWebサイトはWi-Fiでも開ける

  • 4G回線に切り替えるとChatGPTは開ける

  • しばらくするとWi-Fiでも再びChatGPTが開けるようになった

結果として、今回は特別な設定変更やルーター再起動をする前に自然復旧しました。

まず確認したいこと

同じような症状が出た場合、いきなりルーターやPCの設定を変更するより、まず通信経路を切り分けると原因を探しやすくなります。

最初に、スマートフォンならWi-Fiを一度切り、4Gや5G回線でChatGPTへアクセスしてみます。

モバイル回線では正常に開ける場合、ChatGPTのアカウントや端末そのものではなく、Wi-Fi側の通信経路に一時的な問題が起きている可能性があります。

次に、Wi-Fiへ戻して他のWebサイトを開いてみます。

他サイトまで開けないのであればインターネット回線やルーター全体の問題が考えられますが、今回のようにChatGPTだけ開けない場合は、DNSや通信経路など一時的な問題の可能性もあります。

Wi-Fiを一度OFFにしてみる

最も簡単なのは、スマートフォンやPCのWi-Fiを一度OFFにし、数秒後に再びONにする方法です。

これだけで接続先や通信状態が取り直され、正常に戻る場合があります。

今回も最終的にはWi-Fi経由でChatGPTへ接続できるようになりました。

ルーター再起動は最後でもいい

ネットワークトラブルというと、すぐに「ルーターを再起動する」という対処法が出てきます。

もちろん有効な場合もありますが、他のサイトが普通に開けているのであれば、最初からルーターを再起動する必要はないと思います。

まずは、

  1. モバイル回線でChatGPTが開くか確認

  2. Wi-Fiで他サイトが開くか確認

  3. Wi-FiをOFF・ONしてみる

  4. 少し時間を置いて再度アクセスする

という順番で確認する方が手軽です。

それでも改善しなければ、ルーター再起動やDNS設定の確認を検討すれば十分でしょう。

なお、ルーターを再起動したからといって、必ずグローバルIPアドレスが変更されるわけではありません。

ISP側の割り当てによっては、再接続しても同じIPアドレスになることがあります。

古いゲームや画面拡大ソフトが原因?

今回、少し気になったこともありました。

ちょうど症状が出る直前、PC上で古いWindowsゲームを起動し、ゲーム画面を拡大するために「Magpie」も使用していました。

過去に古いゲームを動かした後でPCの調子がおかしくなった経験があったため、

「もしかしてゲームやMagpieが何か悪さをしたのでは?」

とも考えました。

しかし、今回ChatGPTへ接続できなかったのはPCだけではなく、iPhoneをWi-Fiへ接続した状態でも同様でした。

さらに4Gへ切り替えると正常に接続できました。

この状況から考えると、PC上で動かしていたゲームやMagpieが直接ChatGPTへの接続を妨害した可能性は低そうです。

Magpieはゲーム画面などをGPUで拡大表示するソフトなので、問題が起きるとすればGPU負荷や画面表示、ゲームとの相性などが中心です。

通常、Wi-FiやDNSの設定を書き換えるような用途のソフトではありません。

単純にタイミングが重なった可能性が高いと考えています。

今回は自然復旧した

最終的には、何か特別な操作をしたわけではなく、しばらくしてから再びiPhoneをWi-Fi接続に戻したところChatGPTへアクセスできるようになりました。

ネットワーク関係のトラブルでは、原因が自分の端末にあるとは限りません。

一時的なDNSや通信経路の問題で、特定のサービスだけ開けなくなることもあります。

今回のように、

「ChatGPTだけ開かない」

「Wi-Fiではダメなのに4Gでは開く」

という状態になった場合は、慌ててPCやルーターの設定を変更する前に、まず別回線で接続できるかを確認してみると切り分けしやすいです。

今回の結論

Wi-FiでChatGPTだけ404になった場合でも、すぐにPC故障やアカウント異常と考える必要はありません。

モバイル回線では正常に開けるのであれば、一時的なWi-Fi側の通信経路やDNS関連の問題である可能性があります。

今回はしばらく待つだけで自然復旧しました。

同じ症状が出た人は、まずWi-Fiと4G・5Gを切り替えて確認してみてください。

2026年9月3日木曜日

Audacityで高音がキンキンする音源を自然に直す方法|EQ・倍音・キーの違いを初心者向けに解説

 


音楽を聴いていて、

「なんとなく高音が耳に刺さる」
「女性ボーカルがキンキンする」
「音量は大きくないのに、長く聴いていると耳が疲れる」

と感じることがあります。

Audacityを使えば、こうした音をある程度聴きやすく調整できます。

しかし実際に触ってみると、

「高域を下げればいいのか?」
「キーを下げればいいのか?」
「3kHzとか6kHzって何なのか?」
「コンプレッサーを使えばいいのか?」

と、初心者にはかなり分かりにくいものです。

この記事では、音響の専門知識がない人向けに、「キンキンする音とは何なのか」から順番に整理します。

「音が高い」と「キンキンする」は別の話

最初に理解しておきたいのがこれです。

音程が高いことと、耳にキンキン刺さることは同じではありません。

たとえば女性歌手がかなり高い音を歌っていても、柔らかく気持ちよく聴こえることがあります。

反対に、それほど高い音程ではなくても、

「硬い」
「金属っぽい」
「耳に刺さる」

と感じる声もあります。

たとえるなら、

音程の高さ=建物の高さ

です。

10階建てか20階建てか、という違いです。

一方のキンキン感は、

建物の内装が木なのか、金属なのか

という違いに近いものです。

建物が高くても木造の柔らかな部屋なら落ち着きますし、低い建物でも壁一面が金属なら音が反射して耳につくことがあります。

同じ音程なのに、なぜ音色が違うのか

ここで重要になるのが倍音です。

たとえば440Hzの「ラ」という音を出したとします。

実際の人間の声や楽器では、440Hzだけが鳴っているわけではありません。

同時に、

440Hz
880Hz
1320Hz
1760Hz
2200Hz……

といった複数の周波数成分が含まれます。

中心となる440Hzを「基音」、そこに重なっている成分を「倍音」と考えると分かりやすいです。

同じ「ラ」をピアノで弾いても、ギターで弾いても、人が歌っても、全部同じ音程として認識できます。

それなのに音がまったく違うのは、この倍音の含まれ方が違うからです。

料理にたとえるなら、

基音=主材料
倍音=味付け

です。

同じ鶏肉でも、塩焼きとカレーではまったく違う味になります。

音も同じです。

3kHz~6kHz付近が強いと「刺さる」ことがある

ボーカルのキンキン感を調整するとき、よく問題になるのが数kHz付近です。

特に3kHz~6kHzあたりには、声の輪郭や明瞭さに関係する成分が多く含まれています。

ここが適度に強ければ、

「声が前に出る」
「歌詞が聞き取りやすい」
「クリアに聞こえる」

という長所になります。

強すぎると、

「硬い」
「痛い」
「トゲトゲする」

という方向へ変わります。

画像編集でいうシャープネスに近いです。

少しシャープにすると写真がクッキリします。

かけすぎると輪郭がギザギザして、見ていて疲れる画像になります。

音でも似たことが起こります。

AudacityのGraphic EQで調整する

AudacityにはGraphic EQがあります。

メニューでは現在、

エフェクト → EQとフィルター → Graphic EQ

から利用できます。Graphic EQでは、各スライダーが特定の周波数帯域を担当し、その帯域をdB単位で増減できます。(Audacityマニュアル)

キンキンするボーカルを調整するとき、いきなり高域を全部削るのはおすすめしません。

たとえば「高域カット」のような強い処理をすると、

耳障りな部分だけでなく、シンバルの輝きやボーカルの空気感まで消える

ことがあります。

結果として、

「昔のラジオみたい」
「音がこもった」

という状態になりがちです。

そこで、まずはGraphic EQで、

3.15kHz:-1~-2dB
4kHz:-1~-2dB
5kHz:-1~-2dB

というように、狭い一点を深く削るのではなく、少し広い範囲を浅く下げるところから試すと分かりやすいです。

数値は音源によって変わるので、これは開始地点と考えてください。

「3kHzを下げたのに、むしろキンキンする」こともある

EQは面白いもので、3kHzだけ大きく下げると、隣の4kHzや5kHzが相対的に目立つことがあります。

たとえば山が3つ並んでいたとします。

中央の山だけ低くすると、左右の山が以前より高く見えます。

音でも同じことが起こります。

そのため、

特定の1本だけを大きく削るより、周囲を含めてなだらかに削る

方が自然に聞こえる場合があります。

曲の場所によってキンキン感が違う理由

1番のサビでは改善したのに、2番のサビではまだキンキンする。

これも珍しいことではありません。

EQを曲全体へ適用した場合、同じ設定は全編にかかっています。

たとえば3kHzを-2dBにしたなら、1番でも2番でも-2dBです。

それでも聞こえ方が違うのは、元の音が違うからです。

2番サビでは、

ボーカルが強く歌っている
コーラスが増えている
シンバルが増えている
楽器が重なっている
ミックスが厚くなっている

といった変化があります。

元々3~6kHzが強い部分なら、2dB下げてもまだ強いことがあります。

波形を見ても周波数は分からない

Audacityには普通の「波形表示」と「スペクトログラム表示」があります。

通常の波形は、

いつ音が大きいか

を見るものです。

ステレオ音源なら通常、上段と下段が左右チャンネルになります。

一方、どの周波数が強いかを見たい場合はスペクトログラムや周波数解析を使います。

Audacityには選択した音声の周波数成分を見るPlot Spectrum機能があります。(Audacityマニュアル)

もっとも、初心者なら数字だけを信用しすぎない方がよいと思います。

グラフで山が見えても、それが必ず「耳障りの犯人」とは限らないからです。

最終判断は耳です。

EQの「元に戻す」で混乱しやすいところ

AudacityでGraphic EQを適用したあと、

Ctrl + Z

で処理を取り消せます。

ここで初心者が戸惑いやすいのが、

音は元に戻ったのに、Graphic EQを再び開くとスライダーが前回の位置に残っている

ことです。

Graphic EQには「Flatten(平坦化)」があり、これを使うと全スライダーを0dBのフラットな状態へ戻せます。(Audacityマニュアル)

つまり、

Ctrl+Z=音源に行った処理を戻す

平坦化=次に使うEQ設定を0へ戻す

と分けて考えると理解しやすくなります。

キーを下げればキンキンしなくなる?

Audacityには「ピッチを変更」があり、テンポを維持したまま音程を上下できます。

しかし、キンキン感を直す目的なら第一選択にはなりません。

キーを下げればボーカル全体の音程そのものが変わるからです。

「この歌そのものを少し低く聴きたい」

のであれば有効です。

「声の表面にあるトゲだけ取りたい」

のであれば、EQなどで音色を調整する方が目的に近くなります。

コンプレッサーなら高音を潰せる?

普通のコンプレッサーは、基本的には周波数ではなく音量の大きな部分を抑える道具です。

そのため、

「高音だけを抑えたい」

という目的で普通のコンプレッサーを使うと、曲全体のダイナミクスまで変わる可能性があります。

高音が強くなった瞬間だけ抑えたい場合は、

ディエッサー
マルチバンドコンプレッサー

といった処理の方が考え方として近くなります。

これは、

「常に高音を削っておく」

のではなく、

高音が飛び出した瞬間だけ上から軽く押さえる

ような処理です。

「薄皮を一枚かぶせる」くらいがちょうどいい

キンキンした音を直そうとして高域を大きく削ると、今度は音楽そのものの魅力まで失われます。

自分が実際にAudacityを触っていて一番分かりやすかったイメージは、

尖ったボーカルの表面に薄皮を一枚かぶせる

という感覚でした。

高域カットは、薄皮ではなく厚い毛布をかぶせる感じです。

一点だけ大きくEQを下げると、別のトゲが目立つことがあります。

だから最初は、

数kHzの範囲を1~2dB程度、広く浅く丸める

くらいから始める。

元に戻して聞く。

また少し変える。

これを繰り返す方が、初心者でも失敗しにくいと思います。

そして何度聞き比べても、

「元の方が自然かもしれない」

と思ったら、何もしないという選択もあります。

音声編集は、数字を正解に合わせる作業ではありません。

自分の耳で「こっちの方が長く聴いていて楽だ」と感じるところを探す作業

だと考えると、Audacityは急に分かりやすくなります。

2026年8月24日月曜日

HTMLファイルを無料で公開する方法|GitHub Pagesならサーバー代0円で使える

 


自分で作ったHTMLファイルを、誰でもブラウザから使える形で公開したい。

でも、

  • レンタルサーバーを契約するほどではない

  • 独自ドメインもいらない

  • とりあえず無料で試したい

  • Windowsだけで作業したい

ということがあります。

そんな時に便利なのが、GitHubの「GitHub Pages」です。

GitHub Pagesを使えば、HTML・CSS・JavaScriptで作った静的なWebページを無料で公開できます。

今回は、実際にHTMLファイル1枚をGitHub Pagesで公開した時の手順を、つまずいた点も含めてまとめます。

GitHub Pagesとは?

GitHub Pagesは、GitHubのリポジトリに置いたファイルをWebサイトとして公開できる機能です。

GitHub Freeでも、Public(公開)リポジトリなら利用できます。

HTMLファイルを公開するだけなら、レンタルサーバーを用意する必要はありません。

GitHub公式でも、GitHub Pagesはリポジトリ内の静的ファイルを公開できる機能として案内されています。

公開後のURLは、おおむね次のような形になります。

https://ユーザー名.github.io/リポジトリ名/

このURLをスマートフォンやPCのブラウザで開けば、普通のWebページとして利用できます。

今回用意したもの

今回用意したのは、HTML・CSS・JavaScriptを1ファイルにまとめた、

index.html

だけです。

GitHub Pagesでは、index.htmlindex.mdREADME.mdなどを入口となるファイルとして認識します。HTMLでWebページを作るなら、index.htmlにしておくのが分かりやすいです。

なお、index.htmlという名前だからといって、そのリポジトリに他のファイルを置けなくなるわけではありません。

後から、

style.css

script.js

data.csv

画像ファイル

などを追加することもできます。

index.htmlは単に、その場所を開いた時の入口になるファイルです。

1.GitHubにログインする

まずGitHubへログインします。

すでにGitHubアカウントを持っている場合は、新しく作る必要はありません。

久しぶりにログインした場合でも、そのまま既存アカウントを使えます。

2.新しいリポジトリを作る

GitHubのトップ画面などにある「New」から、新しいリポジトリを作成します。

Repository nameには、公開する内容が分かる名前を付けます。

たとえば、

simple-web-tool

html-tools

game-tools

などです。

GitHub Pagesを無料で使う場合は、GitHub FreeではPublicリポジトリにしておくのが基本です。

設定が終わったら、

「Create repository」

をクリックします。

3.index.htmlをリポジトリに入れる

ここでHTMLファイルをGitHubへ入れます。

通常なら、

「uploading an existing file」

または、

「Add file」→「Upload files」

から、手元のindex.htmlをアップロードできます。

ところが今回、Firefox上でファイルを選択すると、

「Something went really wrong, and we can’t process that file.」

というエラーが出て、何度やってもうまくアップロードできませんでした。

ファイル名をindex.htmlにしていること自体は問題ありません。

そこで、ファイルアップロードを使わず、GitHub上で直接ファイルを作る方法に変更しました。

4.アップロードできない時はGitHub上で直接作る

空のリポジトリに表示されている、

「creating a new file」

をクリックします。

すると、

「Name your file...」

という欄が出てきます。

ここに、

index.html

と入力します。

その下に大きなコード入力欄があるので、手元のindex.htmlをメモ帳やエディタで開き、

Ctrl + A

で全選択、

Ctrl + C

でコピーし、

GitHubの入力欄へ、

Ctrl + V

で貼り付けます。

GitHubではWebブラウザ上から直接新しいファイルを作成できます。

貼り付けが終わったら、

「Commit changes」

を押します。

これでリポジトリ内にindex.htmlが保存されます。

今回のようにファイルアップロードがなぜか失敗する場合は、この方法の方が早いかもしれません。

5.GitHub Pagesを有効にする

次に、リポジトリ内のファイルをWebサイトとして公開します。

リポジトリ上部にある、

「Settings」

をクリックします。

左側のメニューから、

「Pages」

を開きます。

「Build and deployment」という項目があります。

Sourceを、

「Deploy from a branch」

にします。

その下のBranchを、

main

にします。

フォルダは、

/(root)

を選びます。

設定したら、

「Save」

をクリックします。

GitHub公式でも、ブランチから公開する場合は「Settings」→「Pages」→「Deploy from a branch」と進み、公開するブランチとフォルダを指定する手順になっています。

6.公開URLが表示されるまで待つ

Saveを押しても、すぐにページが表示されるとは限りません。

少し待ってから「Settings」→「Pages」をもう一度開くと、

「Your site is live at ...」

といった表示が出ます。

そこに公開URLが表示されます。

URLは、

https://ユーザー名.github.io/リポジトリ名/

という形になります。

GitHub公式によると、変更が公開されるまで最大10分ほどかかる場合があります。

公開URLが表示されたら、クリックして実際にページが動くか確認します。

7.スマートフォンでも普通に使える

GitHub Pagesとして公開してしまえば、iPhoneやAndroidからも普通のWebページとして開けます。

ここがかなり便利でした。

最初はHTMLファイルをメールでiPhoneへ送り、そのまま開こうとしました。

ところが、メールアプリやファイルアプリのプレビューではJavaScriptが正常に動かず、選択メニューなどが表示されませんでした。

GitHub Pagesへ置いた後は、Safariなどから普通のWebサイトとしてアクセスできるため、JavaScriptも正常に動作しました。

ローカルHTMLをスマートフォンで無理に開くより、無料のGitHub Pagesへ置いてしまう方が使いやすい場合があります。

GitHub Pagesで向いているもの

GitHub Pagesは、ちょっとした自作ツールの公開にかなり向いています。

たとえば、

  • 計算ツール

  • 検索ツール

  • JavaScriptで動く便利ツール

  • 早見表

  • チェックリスト

  • 静的なWebサイト

  • 個人用に作った小さなWebアプリ

などです。

HTML・CSS・JavaScriptだけで完結するものなら、かなり手軽に公開できます。

一方、GitHub PagesはPHP、Pythonなどをサーバー上で動かす仕組みではありません。GitHub公式でも、PHP・Ruby・Pythonなどのサーバーサイド言語には対応していないと案内されています。

Pythonで計算した結果をHTMLとして出力したり、JavaScriptへ処理を書き換えたりする方法なら使えます。

公開リポジトリなので個人情報には注意

GitHub Pagesで公開する前に、HTMLやリポジトリ内に個人情報や公開したくない内容が入っていないか確認しておいた方がいいです。

GitHub Pagesで公開したサイトはインターネット上から閲覧できます。

GitHub公式も、Pagesサイトは公開されるため、センシティブな情報をリポジトリへ含めないよう注意を案内しています。

APIキーやパスワードなどは絶対にHTMLへ直接書かないようにします。

実際にやって分かったポイント

今回やってみて、一番重要だったのは次の3点でした。

まず、HTMLファイル1枚でもGitHub Pagesは使えます。

大掛かりなWebサイトを作る必要はありません。

次に、最初のファイル名をindex.htmlにすると分かりやすいです。

そして、ブラウザからのファイルアップロードがなぜか失敗しても、GitHub上で「Create new file」を使い、HTMLコードを直接貼り付ければ公開まで進められました。

GitHubというと、Gitコマンドやターミナルを使わないと何もできないイメージがありましたが、今回程度ならブラウザだけでも公開できます。

まとめ

HTMLやJavaScriptで作った小さなツールを無料公開したいなら、GitHub Pagesはかなり便利です。

基本的な流れは、

  1. GitHubでリポジトリを作る

  2. index.htmlを入れる

  3. Settingsを開く

  4. Pagesを開く

  5. Deploy from a branchを選ぶ

  6. mainと/(root)を指定

  7. Saveする

  8. 公開URLが出るまで待つ

これだけです。

レンタルサーバー代は不要で、独自ドメインも必須ではありません。

「自分で作ったHTMLを、とりあえずネット上で動かしてみたい」という用途なら、かなり使いやすい方法だと思います。

Anker Solix C2000 Gen 2を実際に使って分かったこと|停電時に本当に頼れる大容量ポータブル電源

 


※本記事にはアフィリエイト広告を含みます。

自宅の停電対策やソーラー発電の蓄電先として、Anker Solix C2000 Gen 2を導入しました。

容量は2048Wh、AC出力は2000W。

数字だけ見てもかなり大きなポータブル電源ですが、実際に使ってみると「大容量だから何でも無限に使える」というものではありません。

一方で、地震や大雨などで本当に停電したとき、照明やスマートフォン、パソコンなどの電源を確保できる安心感は非常に大きいです。

実際、我が家でも停電を経験しました。

そのとき、このポータブル電源があることの頼もしさを強く実感しました。

今回は、Anker Solix C2000 Gen 2を実際に使って感じた良いところ、気になったところ、ソーラーパネルとの組み合わせ、そして停電時にどこまで使えるのかを紹介します。

→ AmazonでAnker Solix C2000 Gen 2を確認する

Anker Solix C2000 Gen 2とは

Anker Solix C2000 Gen 2は、家庭用としてもかなり大容量のポータブル電源です。

主な仕様は、

  • 容量2048Wh

  • AC出力2000W

  • リン酸鉄リチウムイオン電池

  • 長寿命設計

  • 拡張バッテリー対応

  • 最大5120Whまで拡張可能

  • AC急速充電対応

  • 停電時の自動切替機能

  • スマートフォンアプリ対応

といったものです。

スマートフォンやノートPC程度だけではなく、かなり消費電力の大きな家電まで動かせる能力があります。

実際に使ってみると、とにかく分かりやすい

まず感じたのは、製品として非常に分かりやすいことです。

本体の表示を見れば、

  • 現在のバッテリー残量

  • 入力電力

  • 出力電力

  • 使用可能時間の目安

などを確認できます。

大容量の電源というと、もっと扱いが難しいものを想像していましたが、基本操作で迷うことはほとんどありませんでした。

家庭で非常用電源として使う場合でも、専門知識がないと使えないような製品ではありません。

この「普通に使える」ということ自体が、防災用品としてはかなり重要だと思います。

約20kgあるので移動時には注意

大容量だけあって、軽くはありません。

本体重量は20kg近くあります。

家の中で少し移動させる程度なら何とかなりますが、階段を何度も上り下りしたり、頻繁に車へ積み下ろししたりする用途では、それなりに覚悟が必要です。

持ち上げてみると、明確に「重い」です。

購入する場合は、

普段どこに置くのか

を先に決めておいた方がいいと思います。

防災用品として使うなら、必要なときすぐ使える場所に常設しておく方が現実的です。

梱包はかなりしっかりしている

届いたときの梱包はかなりしっかりしていました。

重量のある精密機器なので配送時の状態は少し心配でしたが、個人的には安心感のある梱包でした。

このあたりは、Ankerというメーカーに対して感じている信頼感にもつながっています。

ポータブル電源は長期間使うものですし、家庭の停電対策として使う以上、価格だけではなくメーカーへの安心感も重要だと思います。

RENOGYのソーラーパネルを接続するにはアダプタが必要だった

我が家では別記事で紹介しているRENOGY 100Wフレキシブルソーラーパネルを4枚使用しています。

太陽光で発電した電気を、このAnker Solix C2000 Gen 2へ充電しています。

ここで一つ注意したい点があります。

手持ちのRENOGYソーラーパネルをそのまま接続できるわけではなく、私の環境では別売りの接続用アダプタが必要でした。

ソーラーパネルとポータブル電源は、端子の規格が合えば何でもそのまま接続できるわけではありません。

既に他社製ソーラーパネルを持っている人は、

パネル側の端子とAnker側の入力端子が接続できるか

を購入前に確認した方がいいです。

ソーラーパネルについては、別記事で実際の発電量も詳しく紹介しています。

ソーラー発電と組み合わせるとかなり面白い

我が家ではRENOGYの100Wパネルを4枚使っています。

定格上は合計400Wです。

現在は手すりにほぼ垂直に取り付けているため、理想的な設置条件ではありません。

夏場の実測では、

  • 午前中は約20W

  • 正午から14時ごろは約120W

  • 14時から16時ごろは約170W

  • 条件が良いと最大200W前後

といった発電状況です。

この電力をAnkerへ蓄えておけば、日中に作った電気を夜間にも使えます。

ソーラーパネルだけでは「発電している瞬間」にしか使えない電気を、ポータブル電源があることで好きな時間に使えるようになります。

この組み合わせはかなり便利です。

→ AmazonでAnker Solix C2000 Gen 2を確認する

スマートフォンアプリから管理できる

Anker Solix C2000 Gen 2はスマートフォンアプリにも対応しています。

離れた場所から本体の状態を確認できるので、毎回本体の前まで行く必要がありません。

現在の入力・出力やバッテリー残量などをスマートフォンから確認できるのは便利です。

一方、実際に使っていて不満なのが長期的な統計表示です。

私が欲しいのは、

  • 今日一日で何Wh発電したか

  • 何Wh消費したか

  • 時間帯ごとの発電量

  • 1週間の推移

  • 1か月の推移

といったデータです。

ところが、そうした詳細な履歴を後からじっくり分析する用途には少し物足りません。

ソーラーパネルを使っていると、

「昨日より今日はどれくらい発電した?」

「どの時間帯が一番発電している?」

ということが気になります。

ここは今後アプリ側で強化されるとかなり嬉しい部分です。

ときどき「パキパキ」と音がする

使用していると、ときどき本体から

パキッ、パキッ

というような音が聞こえることがあります。

充電中なのか、放電中なのか、温度変化によるものなのか、今のところ発生条件ははっきり分かっていません。

最初は少し気になりました。

現時点では動作上の問題は特にありません。

静かな部屋で使う場合は、こうした音が聞こえることがあるという点は知っておいてもいいと思います。

2048Whでもエアコンを使い続けると意外と早く減る

2048Whという数字を見ると、

「これだけあれば何でも一日中使えるのでは?」

と思ってしまいそうです。

実際には、使う家電によってかなり違います。

特にエアコンは消費電力が大きいです。

仮に平均500W程度消費しているとすると、

2048Wh ÷ 500W

で、単純計算でも約4時間です。

実際には変換ロスなどもあるため、使える時間はさらに短くなります。

エアコンが1000W近く消費している状況なら、それ以上に早くバッテリーが減ります。

つまり、エアコンを長時間動かしたいなら、

エアコンが消費している電力と同等以上をソーラーパネルなどから継続的に補充できる環境

が欲しくなります。

2048Whは非常に大きな容量ですが、エアコン相手では「無限の電源」ではありません。

それでも停電時にはものすごく頼もしい

ここが、この製品を買って一番良かったと思うところです。

我が家では実際に停電を経験しました。

そのときに思ったのは、

「電気を使える場所が家の中に一つある」

という安心感の大きさでした。

停電すると、

  • 照明

  • スマートフォンの充電

  • Wi-Fiや通信機器

  • パソコン

  • ラジオ

  • 扇風機

  • 小型家電

など、普段当たり前に使っているものが一気に使えなくなります。

そんなとき、2048Whの電力が手元にある。

これはかなり大きいです。

エアコンのような大出力機器を何時間も使い続ける用途では容量の限界があります。

一方、比較的消費電力の小さな機器を非常時に動かすなら、かなり頼りになります。

照明が使える。

スマートフォンを充電できる。

情報収集のためにPCや通信機器を動かせる。

扇風機を回せる。

それだけでも停電時の生活はまったく違います。

地震・大雨・台風が多い日本では防災用品として価値がある

日本では、

  • 地震

  • 台風

  • 豪雨

  • 落雷

  • 大雪

などによる停電が珍しくありません。

大きな災害でなくても、数時間電気が止まることはあります。

我が家でも実際に停電を経験したことで、

「非常用電源は使うかどうか分からない物ではなく、本当に使うことがある」

と実感しました。

ガソリン発電機のように燃料を保管する必要もありません。

普段は家庭で充電しておき、停電したらすぐ使う。

さらにソーラーパネルがあれば、停電が長引いても昼間に少しずつ充電できます。

これは災害対策としてかなり心強い組み合わせです。

Linux PCならさらに長時間使える

このブログではLinuxを中心に扱っています。

ソーラー発電とポータブル電源を使い始めて感じたのが、

低消費電力PCの価値は、電気を自分で作るようになるとさらに大きくなる

ということです。

例えば消費電力20W程度の小型PCなら、2048Whという容量は非常に大きいです。

単純計算なら、

2048Wh ÷ 20W = 約102時間

になります。

実際にはモニターやネットワーク機器、変換ロスなどが加わるのでこの通りにはいきません。

それでも、数百W~1000W単位で使う家電と比較すると、低消費電力PCは圧倒的に電気を使いません。

古いPCへLinuxを入れて再利用する。

省電力ミニPCを使う。

太陽光で発電する。

ポータブル電源へ蓄電する。

こうしたものを組み合わせると、

少ない電力で長時間コンピューターを使える環境

が作れます。

これは普段の電気代対策だけではなく、災害時にもかなり強いです。

実際に使って感じた良いところ

Anker Solix C2000 Gen 2を使っていて良かった点をまとめると、

  • 2048Whの大容量

  • 2000W出力で使える家電が多い

  • 操作が分かりやすい

  • スマートフォンアプリ対応

  • ソーラーパネルから充電できる

  • 停電時の安心感が非常に大きい

  • リン酸鉄系で長期間使う前提に向いている

  • Ankerというメーカーへの安心感

  • 梱包もしっかりしていた

というところです。

特に評価したいのは、

災害時だけの道具ではなく、普段から使える

ことです。

普段はソーラー発電した電気を貯めて使い、いざ停電したら非常用電源になる。

防災用品がそのまま日用品になるのは大きなメリットです。

気になったところ

気になったところもあります。

重い

約20kgあるので、頻繁に移動させるものではありません。

ソーラーパネルとの接続には確認が必要

RENOGYなど他社製パネルを使う場合、接続用アダプタが必要になる場合があります。

アプリの長期統計が弱い

1日・1週間・1か月単位で発電量や消費量の推移を詳しく分析したい人には物足りません。

ときどきパキパキ音がする

使用中に筐体から音がすることがあります。

大容量でもエアコンには限界がある

2048Whあっても、高出力家電を長時間使えば当然減ります。

この辺を理解した上で使えば、かなり便利な製品だと思います。

こんな人に向いている

Anker Solix C2000 Gen 2は、

  • 停電対策をしたい

  • 大容量のポータブル電源が欲しい

  • ソーラーパネルを使いたい

  • 防災用品を充実させたい

  • 車中泊やキャンプで家電を使いたい

  • 自宅で非常用電源を確保したい

  • パソコンや通信環境を停電時にも維持したい

という人にはかなり向いています。

特に、

「停電しても最低限の電気だけは自宅で確保しておきたい」

という人には心強い製品です。

結論 停電を経験すると2048Whの安心感はかなり大きい

Anker Solix C2000 Gen 2を使って感じたのは、

ポータブル電源はスペック表だけでは価値が分かりにくい

ということです。

2048Wh。

2000W。

数字だけ見ても、最初はそれが生活の中でどのくらい役立つのかピンときません。

ところが実際に停電すると、一気に意味が分かります。

家中の電気が消えても、

スマートフォンを充電できる。

照明を使える。

パソコンを動かせる。

通信機器を使える。

必要ならかなり大きな家電も動かせる。

そして昼間になればソーラーパネルから再び電気を作ることもできます。

エアコンを何時間も動かし続けるような用途では限界があります。

それでも、停電時に必要な電力を確保する補助電源として考えれば、これほど頼もしいものはありませんでした。

地震や大雨などが続く日本では、

「もし停電したらどうするか」

を考えている家庭にとって、一台あるだけで安心感がかなり変わる製品だと思います。

→ AmazonでAnker Solix C2000 Gen 2を確認する