使わないけど捨てられない800GBを、激安HDDに追放してみる 「消せない。でも使わない」
せっかくアカウントを作ったので私の秘密をひとつネタとして公開しましょうか。 意外と知ってる人いないやつだったので。 PCを長く使っていると、こういうデータが増えてくる。 「たぶんもう使わない」 「でも、何かのときに必要になるかもしれない」 「だから消すのもちょっと怖い」 そんなデータが、気がつけば数百GB。 今回、iMacをサーバーとして使うためにデータを整理していたところ、まさにそんなデータが約800GB残っていた。 特別な思い出が詰まっているわけでもない。 毎日使うわけでもない。 むしろ、ここ数年一度も開いていない。 でも、だからといって今すぐ消す理由もない。 こういうデータが一番困る。 SSDに置いておく必要はない そこで考えた。 「使わないなら、高速なストレージに置いておく必要なくない？」 毎日使うデータならSSDでいい。 仕事で使うデータもSSD。 現在進行中のプロジェクトもSSD。 でも、何年も触っていないデータなら、速度なんてほとんど関係ない。 必要になったときだけ取り出せればいい。 だったら、安い大容量HDDに移してしまえばいい。 そこで中古HDD 今回使おうとしているのは、中古のHDD。 購入先：楽天市場 容量：500GB✖️２ 価格：980円✖️ 2 （私が購入したのはこうだった） ※その時々で安い出物があるので そこは探してみてください。 もちろん中古なので、新品と同じような感覚では使わない。 今回の用途はあくまで、 「壊れても困らないように運用するアーカイブ」 という位置付け。 重要なデータの唯一のコピーを中古HDDに置く、という話ではない。 あくまで「普段使わないデータを、安く退避させる」ためのストレージだ。 HDDケースも安いものでいい HDDを入れるケースも、今回の用途なら高価なものは必要ない。 使用するケース：UGREEN2.5inch HDD/SDDケース 価格：1,398円 接続：USB-C CtoAのケーブルは付属 ここでポイントなのが、HDDをケースに入れっぱなしにする必要すらないこと。 普段はHDDを外しておく。 必要になったときだけ、 HDDをケースに入れる PCに接続する 必要なデータを取り出す 作業が終わったらHDDを外す これだけ。 ※リンクもアフェリエイトじゃないし、物も似たようなのなら それでいいんじゃないかと思います。 ただ、ケースは物によって当たり外れがあるみたいなんでUGREENのが良いかとは思います。 つまり、ケースを1個持っておけば、HDDを入れ替えて使える。 「激安バックアップ装置」というより、デジタル物置 考えてみれば、これはNASとはちょっと違う。 NASのように24時間電源を入れておく必要もない。 高速アクセスも必要ない。 複数人で共有する必要もない。 ただ、 「捨てられないデータを置いておく場所」 が欲しいだけ。 言ってしまえば、デジタル物置だ。 家の押し入れに「いつか使うかもしれない物」をしまっておくのと同じ。 違うのは、こっちは800GBあることくらい。 中古HDDを使うなら、ここは確認する 中古HDDを使う以上、最低限のチェックはしておきたい。 購入後には、 SMART情報 使用時間 電源投入回数 不良セクタの有無 読み書きテスト などを確認する。 ここで問題があれば、アーカイブ用途でも使わない。 また、重要なデータを1台のHDDだけに保存しないのも重要。 「バックアップのためのHDDが壊れた」という本末転倒は避けたい。 実際いくらかかった？ 今回の構成は、 HDD：合計1960円 都合１T B ケース：1398円 合計：3358円 800GBをSSDから退避させるために、この金額ならかなり気軽に導入できる。 しかもケースは今後も使い回せる。 次に別のHDDへデータを移したくなったら、HDDだけ交換すればいい。 まとめ 「使わないけど捨てられないデータ」は、PCを長く使っていると必ず増えていく。 でも、そんなデータのために高価なSSDを買い足したり、24時間稼働するNASを用意したりする必要はない。 安いHDDに逃がして、必要なときだけ接続する。 これだけでも、普段使うストレージの空き容量をかなり取り戻せる。 今回の自分の場合は、まず約800GB。 さて、これでSSDの中身を少し整理できた。 そしてたぶん、こういう「捨てられないデータ」はまだまだ出てくる。 次は何GB追放できるだろうか。 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ 少し話が違うんだけど、 あとは、これ、私はprox-mox全体の定時バックアップにも使ってる。 定時のバックアップに速度はいらない。復旧時に遅いってとこまでセットになってしまうけれど。ダメになったらHDD交換すればいいだけ。そこはprox-moxからモニターできてるから 失敗したりエラー吐いたら チェックして交換で良いと思う。中古品の流用なんだけどバックアップの時しか動いてないせいか しばらく壊れそうにもなさそうな・・・・
従業員は、1時間を60分で埋めようとする
うちの店では、作業割当をアプリで管理している。誰がどの時間に何をやるかを組み、実際に何分かかったかを記録する仕組みだ。 そのデータを眺めていて、あるとき気づいたことがあった。 レジ対応の時間が、やたらときれいに埋まっているのだ。 人は、1時間という枠を渡されると、60分ちょうどで埋めようとする。売場の作業が20分で終わったなら、残りの40分をどこかに割り当てないと落ち着かない。そのときに一番使いやすいのが「レジ対応」だった。何分やったのか、誰も確かめられないからだ。 つまり、レジの時間が時間調整に使われていた。しかも、それが常態化していた。 これは責める話ではない 先に書いておくが、私はこれを従業員のせいだとは思わなかった。 レジの時間をどう書くのか、その考え方を明確に伝えていなかったのは、こちらの側だ。基準を示さずに数字だけ集めておいて、集まった数字がおかしいと怒るのは筋が通らない。運用をはっきりさせていなかったのだから、これは経営側の指導力のなさである。 だから責めるのではなく、「それは違うんですよ」と説明することにした。もちろん、一度言って直るものではない。何度も、こういう理由でこう書いてほしいというところまで落とし込んで、根気強く説明した。理解してもらうまでには、それなりに時間がかかった。 客数を基準にしてみた では、レジの時間は何分が正しいのか。 私は、客数を基準にすればいいと考えた。 うちの店では、1人がレジ周りをキープし、もう1人がカウンター外の作業をする。2人が並んでレジに立つのは、呼ばれたときだけ。これを基準の体制にしている。 その前提で、レジ1人がお客さん1人に対応する時間を、平均1分と置いた。 これは測ったわけではない。20年以上店に立ってきた経験から出した数字だ。タバコ1つで終わるお客さんもいれば、カゴいっぱいの買い物にホットスナックをいくつも頼まれて、時間がかかることもある。それを全部ならせば、だいたい1人1分くらいに落ち着くだろう、と。 客数が30人の時間帯なら、レジ作業は合計30分。多少の前後は当然ある。そこまで厳しく言うつもりはない。 ただ、30分が40分になるとしたら、話は別だ。 「10分の差」ではなく「3割増し」 30分が40分。差は10分である。 10分と聞けば、たいしたことがないように思える。しかしこれは、作業時間が3割増えているということだ。 3割増しと言い換えた途端、重さが変わらないだろうか。同じ人数をさばくのに、3割余計に時間がかかっている。それが毎日、毎時間、3店舗ぶん積み上がっていく。 数字は、見せ方でまったく違う顔をする。「10分」で片付けていた頃には、私も何も感じていなかった。 目安を、入力欄のすぐ横に出した そこで、アプリの画面を変えた。 その時間の客数から計算した目安を、入力欄のすぐ横に表示するようにした。 目安: レジ対応 合計78分以内 ／ 入力計 50分 こう出ていれば、書く人が自分で気づく。「今日は客数が78人なのに、自分は50分と書いている」「これは足りていないのか、それとも他の作業で埋まっていたのか」と、自分の頭で考える。 私が横から「その数字はおかしい」と言う必要がなくなった。ここが一番大きかったと思う。 人に指摘されて直すのと、自分で気づいて直すのとでは、その後の続き方がまるで違う。 小学生のサッカー もう1つ、書いておきたいことがある。 納品が来たからといって、2人が揃ってそこに群がる。お客さんが来たら、一斉にダッシュでレジに戻る。私はこれを「小学生のサッカー」と呼んでいる。 ボールのあるところに全員が集まる、あれだ。うちの従業員にも、この言い方で説明している。 一見、みんなよく働いているように見える。しかし店は回っていない。誰がどこを持つのかが決まっていないから、全員が同じ場所で忙しくなり、空いた場所が空いたままになる。 1人がレジをキープし、1人が外の作業をする。必要なときだけ呼ぶ。それだけで、店は静かに回る。 作業時間の話も、結局は同じところに行き着く。誰が何をどれだけ持つのかを、こちらが決めていなかった。 それだけのことだった。 なぜ、ここまでこだわるのか こう書いていると、細かいことにうるさい経営者に見えるかもしれない。そのとおりだと思う。 私は20年以上、店に立ってきた。1日15時間、17時間、18時間。休みが1日もない時期が何年も続いた。連続勤務も当たり前で、1週間で100時間シフトに入ったこともある。 しかも、そのほとんどを一人で回してきた。3店舗、4店舗を、である。 だから効率化には、人一倍うるさい。 きれいな理由ではない。私が楽をしたかったからだ。 私が楽にならなければ、その先に何も進まなかった。従業員のためという言葉が先に来るほど、私は立派ではない。自分が倒れないために、仕組みを作るしかなかった。 今はもう、ほとんど店に立っていない。立たなくても回るようになったからだ。それが、20年かけてやってきたことの答えだと思っている。 自己申告の数字を、そのまま信じない 言いたいことは1つだ。 自己申告で集めた数字は、悪気がなくてもずれる。 日報でも、工数表でも、勤怠でも同じだろうと思う。人は空いた枠を埋めようとするし、自分がどれだけ時間を使ったかを正確には覚えていない。それを責めても何も変わらない。 大事なのは、その数字を別の事実で検算できるようにしておくことだ。うちの場合は、それが客数だった。業種が違えば、別の何かがあるはずだ。 そしてもう1つ。基準を示していなかったのは経営側の責任だと、まず認めることだと思う。 数字がおかしいと感じたら、人を疑う前に、自分が何を明確にしていなかったのかを疑う。私はそこから始めた。
【GoogleAIStudio】金欠個人開発者のための2000円ぽっきりAIチャット導入方法
予算2,000円で作るAIチャットボット ――ドケチフォールバック戦略の実装方法―― こんにちは、T1です🐶 この記事はNoteに投稿した記事をMintor向けにやや技術にフォーカスしてMintor用にリライトしたものです。 Note記事はこちら ⇒ https://note.com/t1_office/n/n645639af6c67 こっちもぜひ見てくださいね～ さて、今回は、私の個人サイトにAI問い合わせボットを実装しました。 私の個人サイトはこちら。ここから実際に動くチャットボットが見られますよ～ https://t1office.net/ 「費用を限界まで抑えながら、できるだけ止まらないボット」を目指して設計したので、その実装詳細を共有しますね！！！ --- 🏗️ システム構成 ブラウザから直接 Gemini API を叩かない理由は APIキーの露出防止 です。 Next.js の API Routes をプロキシにすることで、キーをサーバー側の環境変数にのみ置けます。 --- 💡 設計のポイント：2重ループによる4段階フォールバック 今回の最大の工夫はここです。 「APIキー（FREE/PAID）× モデル」の2重 for ループで、最大4パターンを自動で試みます。 試行順序 | 試行回 | キー | モデル | 典型的な失敗理由 | |--------|------|--------|----------------| | 1回目 | FREE | gemini-3.5-flash | 世界的なリクエスト過多で 429 | | 2回目 | FREE | gemini-3.1-flash-lite | 無料枠 RPM 上限超過で 429 | | 3回目 | PAID | gemini-3.5-flash | ほぼ成功（ここまで来ることは稀） | | 4回目 | PAID | gemini-3.1-flash-lite | ほぼ成功（最終手段） | > ポイント： 429（レート制限） エラーは処理を最後まで待たずに即座に返ってくるため、 > 1段階あたりの追加遅延は +0.5〜1秒程度 です。 > 最悪ケース（3回失敗→4回目成功）でも通常比 +2〜3秒 に収まります。 --- 📡 ReadableStream でリアルタイム進捗を流す フォールバック中にユーザーが「固まった？」と感じないよう、 サーバーから ReadableStream で逐次ステータスを送信しています。 --- 🗜️ トークン最適化：5〜6万 → 約7,000 トークンに削減 AIにサイト情報を答えさせるには、知識をプロンプトに渡す必要があります。 Webサイトの全テキストやnote記事をそのまま渡すと 5〜6万トークン になってしまいます。 採用した戦略：構造化JSONに要約して渡す note記事の全文・作品の詳細ブロックなど「長文」を除外し、 (もともとは入れたかったんですけど) タイトル・概要・URL だけに絞ることで約 7,000トークン まで圧縮。 これが1リクエストあたりのコストを直接削減します。 --- 📊 Discord Webhook で運用診断ログを実現 DBを立てずに質問・回答・コスト診断を記録する方法として Discord Webhook を採用しました。 AIが回答するたびに以下のリッチカードが管理者チャンネルに届きます。 デバイス判定 は User-Agent ヘッダーから取得しています： トークン消費数 は Gemini API のレスポンスに含まれる usageMetadata から取得： これにより「どのモデル（FREE/PAID）が使われたか」「1回あたり何トークン消費したか」が Discordから一目でわかり、コスト監視が楽になっています。 --- 🛡️ コスト爆発を防ぐ2つの安全網 Google AI Studio のプリペイド上限（サーバー側） Google AI Studio に 2,000円だけ前払いチャージしておきます。 これを使い切るとAPIが自動停止するため、物理的にそれ以上の請求は来ません。 （最低入金額が2,000円のため、これが今回の構成の最低必要額になります） LocalStorage レートリミット（クライアント側） > 注意点： LocalStorage はブラウザの「Cookiesとサイトデータを削除」で突破可能です。 > あくまで「善意の一般ユーザー向け」の簡易策で、最終防衛ラインはプリペイド上限です。 --- 📈 実際の運用コスト感 Discordに届いた診断データの実例： 1リクエストあたりの有料消費コストは Gemini 3.5 Flash の場合： 入力: 6,852トークン × $0.00001/token ≒ 約0.001円 出力: 82トークン × $0.00004/token ≒ 約0.0005円 1回答あたり約0.002円。普段の個人サイト規模なら無料枠で十分まかなえており、 有料枠に達することはほぼありません。(理論上は！) --- この記事のまとめ ・2重ループの4段階フォールバックでAPIの無料枠を限界まで使いきり、有料課金を最小化できる！ ・構造化JSONによるトークン削減で、リクエスト単位の費用を低減できる！ ・ReadableStream で進捗ストリーミングすることで、フォールバック中もフリーズと思わせない！ ・Discord Webhookで診断ログをとることで、DBなしでリアルタイムにコスト・品質を監視！ ・プリペイド上限 + LocalStorage制限によって、ある程度の費用爆発防止を実現！ 「月額ウン万円のSaaS契約なし」「実質ほぼ無料運用」で、 それなりに止まらないAIボットが作れました。 同じような構成を試したい方はぜひ参考にしてください！🐶
アイデアをClaudeに"却下"してもらう道具を作った
「天才的ひらめき」のはずがいつも墓標になる人へ つくる人なら、たぶん身に覚えがあると思います。 シャワーを浴びてたら降ってくる「これは天才では？」というアイデア。その瞬間は本気でワクワクするのに、メモアプリを見返すと、過去の“天才的ひらめき”が墓標みたいに並んでいる。ひとつも形になっていない。 僕の問題は、思い付いたアイデアの中から取り組む対象を選ぶのが壊滅的に下手だったことでした。 しかも選び方が日替わり。元気な日は何でも「イケる」、疲れてる日は何でも「どうせ無理」。同じアイデアでも、見る日の気分で評価がコロコロ変わる。 これはもう、ものさしが伸び縮みしているのと同じで、何個アイデアを並べても比べようがない。 --- 作ろうと思ったきっかけ ある時ふと気づいたんです。 事業アイデアって、そもそも低確率でしか当たらない。 だったら、僕がコントロールできるのは「天才的なひらめき」じゃなくて、「気分に左右されず、同じフォームで何度バットを振れるか」 のほうだけだ、と。 ホームランは狙って打てない。でも、打席数とストライクゾーンの厳しさは自分で決められる。 そこで発想を逆にしました。 アイデアを増やす道具じゃなくて、ものさしのほうを固定する道具を作る。 出てきたアイデアを、毎回まったく同じ基準で、自分に都合よく甘やかさずに削っていく装置。 それが business-idea-explorer という Claude スキルです。 無料・オープンソース（MIT）で公開しています。 --- 何を作ったか（技術の話） 中身はシンプルですが、設計の肝がひとつあります。 「創造性はモデルに、規律はスキルに焼き込む」 という役割分担です。 LLMに「いい事業アイデア考えて」と聞くと、毎回それっぽくて毎回違う答えが返ってきます。 発想としては楽しいけど、評価には向かない。 比較するには、入力が違っても通る手順が同じであってほしい。 そこで、評価ロジックそのものを毎回プロンプトで書くのではなく、SKILL.md にワークフロー・評価軸・禁止事項としてハードコードしました。 毎回必ず、次の7フェーズを同じ順番で通します。 評価フロー 前提確認 規模志向 B2B / B2C 当事者性 流通の持ち札 対象を絞る 広い領域 具体的サブ領域へ落とす ペイン収集 「既に金を払ってるのに未解決」のシグナル探索 ランク付け 件数順では並べない 商材アイデア + 競合確認 商材案 競合の厳密確認 事業モデル & 値決め 収益構造 価格設計 最初の100人を集める施策 集客導線 流通戦略 検証設計 GO / NO-GO 判定 次のアクション --- 痛い目で学んだ「中核思想」 このツールには、自分が何度も爆死して学んだ逆張りが入っています。 これがツールの性格です。 「既に金を払ってるのに未解決」な課題を入口にする 人は不満には共感しても、解決のために金を払うとは限らない。 既に何かにお金を払っているという事実は、その課題が十分痛い証拠だ。 だからビタミンではなく、ペインキラーを探す。 --- 声の大きい順に並べない 不満の声が大きい場所は、たいてい解決策が乱立している競争市場。 だからこのツールは、声の大きさではなく「未解決度」と「支払い実績」を重視します。 --- 流通こそ最大の制約 勝敗を分けるのはペインの深さだけではありません。 どれだけ良い解決策でも、最初の顧客に届けられなければ存在しないのと同じです。 だから最初に、 フォロワー 予算 当事者性 業界ネットワーク といった「持ち札」を確認します。 同じアイデアでも、持っている流通によって難易度は大きく変わるからです。 このツールは市場だけを見るのではなく、「その人が本当に戦える場所か」を重視します。 --- 作る前に検証する 僕は「作ること」を前進だと思っていました。 でも実際は、誰も欲しくないものを作る速度が上がるだけでした。 だからこのツールは、まず需要を確かめます。 生の声を集める 5人に話を聞く 前金を試す 手動MVP、などです。 その上で最後は必ず GO / NO-GO を決めます。 コードを書くのは、そのあとです。 --- 使ってみた正直な感想 一番効いたのは、自分のお気に入りアイデアを冷たく却下してくれることでした。 「それ、もう似たサービスたくさんありますよ」 「最初の100人にどう届きます？」 「一段落で書けます？」 「書けないなら今回は見送りでは」 耳が痛い。 でも、半年かけて作ってから 誰も欲しくなかった と気づくより、ずっと安い。 発想ツールというより、 ひらめきに浮かれた自分を正気に戻す装置。 実態は、 「アイデア生成機」ではなく「アイデア却下機」 です。 --- ぜひ使ってみて & ご意見ください 導入はこれだけです。 Claude Desktop（Cowork・コード不要） .skill ファイルをダウンロード 会話にドラッグ 「Save skill」を押す Claude Code（開発者向け） リポジトリ https://github.com/desktop7788/business-idea-explorer あとは、 「○○の領域で事業アイデア探したい」 「このアイデア評価して」 と話しかけるだけで起動します。 --- お願い もし試してくれたら、自分の興味のある領域で1回試してみてください。 そして、 どんなふうに却下されたか どんなアイデアが拾われたか どこが雑だったか 情報源は適切だったか をコメントで教えてほしいです。 それ自体が、このツールを育てる生の声になります。 「ここの判定が雑だった」 みたいなダメ出しが一番ありがたい。 一緒に、ものさしを磨いていけたら嬉しいです。
話しかけるだけで、見積・請求業務が終わる。
「請求書を作る」ために、毎回アプリを開いて、顧客を選んで、品目を入力して……その作業、まるごと消えます。GooodBilling は、普段使っているチャットに話しかけるだけ。 「未回収の請求書ある？」→ 金額と延滞日数つきで即答 「A社に保守料5万円で請求書を作って」→ 数秒で適格請求書(インボイス)対応の1枚が完成 内容を確認して「はい送って」で送付まで。勝手には送らないので安心。 「Fre◯e」や「らくら◯明細」と何が違うの？ AIネイティブ設計 — 後付けのAI機能ではなく、最初から話しかけて操作するために設計。 美しい出力 — 請求書は取引の最後に渡すブランドドキュメント。受け取る相手の信頼まで設計に含める。 機能厳選 — 使わない会計機能は載せない。請求まわりの業務だけを、軽く確実に。 会計ソフトの"機能比べ"から降りて、「事務作業そのものを無くして」AI時代のバックオフィスを、GooodBilling で。 主な機能 適格請求書（インボイス）対応 LINE / Slack / ChatGPT / Claude 連携 見積・請求・入金消込・レポート リンク https://gooodbilling.com https://youtube.com/shorts/rHzZgSRZNFY?feature=share
今あえてBloggerを選ぶ理由とは？ — 非エンジニアでもここまでできる、Bloggerという選択肢
WordPressでもはてなでもない。Googleが2003年から運営し続ける"最古"のブログサービス、Blogger。日本国内での利用者は決して多くないが、エンジニアの視点から見ると、あえて選ぶ理由が実はいくつもある。 本記事では、Bloggerを実際に自作テンプレートで運用している立場から、メリット・デメリットを客観的に整理する。さらに、Bloggerでは珍しいSPA構成・外部スクリプト非依存・動的ページレンダリングという設計思想についても紹介する。 --- 主要ブログサービスとの比較 | 項目 | Blogger | WordPress（セルフホスト） | はてなブログ | note | | ------------ | -------- | ----------------- | ---------- | ---- | | 月額費用 | 無料 | サーバー代 500〜2,000円〜 | 無料 / 600円〜 | 無料あり | | 独自ドメイン | 無料枠で可 | 別途取得が必要 | 有料プランのみ | 非対応 | | AdSense申請 | 独自ドメイン不要 | 独自ドメイン推奨 | 独自ドメイン推奨 | 非対応 | | テンプレートカスタマイズ | XMLを完全制御 | PHPテーマを完全制御 | デザインCSS | 不可 | | サーバー管理 | 不要 | 必要 | 不要 | 不要 | | セキュリティ管理 | 不要 | プラグイン更新等が必要 | 不要 | 不要 | | コミュニティ | ほぼなし | エコシステムが充実 | 国内充実 | 充実 | WordPress（セルフホスト）と比べると、カスタマイズ自由度は同等でありながら、維持コストとサーバー管理の手間がゼロという点がBloggerの最大の差別化ポイントになる。 --- Bloggerのいいところ 完全無料で広告なし 利用料がかからないのはもちろん、サービス側が強制的に広告を挿入してくることもない。AdSenseを導入すれば、収益はすべて自分のものになる。 サーバー管理が不要 レンタルサーバーの契約・更新・バックアップ・WordPress本体やプラグインのアップデート、こういった維持管理作業が一切発生しない。記事を書くことだけに集中できる。 独自ドメインなしでもAdSense申請できる 多くのブログサービスでは独自ドメインが事実上必須だが、Bloggerは blogspot.com サブドメインのままでもAdSense審査に通る実績がある。もちろん独自ドメインの設定も無料で可能。 Google製サービスとの親和性が高い Analytics、Search Console、AdSense、Google Photosとシームレスに連携できる。特にGoogle Photosの画像ホスティングは、URLパラメータだけでリサイズ・WebP変換が可能な実質CDNとして活用できる。 カスタマイズ範囲が広い XMLテンプレートを直接編集でき、HTML/CSS/JavaScript を自由に記述できる。テーマ構造の制約を受けるWordPressテーマと違い、ページの構造から描画ロジックまで完全にコントロールできる。 プラグイン依存ゼロ WordPressはプラグインの更新漏れがセキュリティリスクに直結するが、Bloggerにはそもそもプラグインという概念がない。自分が書いたコードだけが動く、という安心感がある。 --- Bloggerのよくないところ 日本国内の情報が極端に少ない 国内利用者が少ないため、日本語の有益な記事がほとんど見つからない。英語の公式ドキュメントとStack Overflowが主な情報源になる。 コミュニティがない はてなブログのような読者登録・ブックマーク文化、noteのようなフォロワー経由の流入は期待できない。流入はほぼSEOとSNS経由になる。 XMLベース構造の学習コストが高い テンプレートはXMLで記述され、Blogger固有のウィジェットタグ・条件分岐・データタグが存在する。この仕様を理解しないままカスタマイズしようとすると、意図しない挙動に悩まされる。 CSS/JS/HTMLがテンプレート1ファイルに集約される 構造・スタイル・スクリプトがすべて1つのXMLファイルに収まるため、規模が大きくなると冗長になりがちだ。ただし逆に言えば、外部依存ゼロの自己完結型テンプレートとして設計できるという利点でもある。 エディタのリッチテキストがHTMLを汚染しやすい 投稿エディタを「作成」モードで使うと、不要なspanタグやstyleが挿入されてHTMLが汚れる。HTMLモードで直接記述する習慣が必要になる。 --- 自作テンプレートの設計思想 — Bloggerの限界を破る ここからは、実際に運用している自作テンプレートの設計について紹介する。 このテンプレートの核となる思想は 「外部ライブラリに依存しない、完全自作のSPA構成」 だ。通常のBloggerテンプレートはページ遷移のたびにフルリロードが発生するが、History APIとBlogger JSON Feedを組み合わせることでDOM差分更新による動的ページレンダリングを実現している。 アーキテクチャの概要 | 項目 | 採用方針 | | ------- | -------------------------------- | | ページ遷移 | SPA（History API + DOM更新） | | 外部ライブラリ | 不使用（jQuery等に非依存） | | データ取得 | Blogger JSON Feed API | | 画像配信 | GoogleホストのURLパラメータ書き換えで最適化 | | アクセス解析 | Google Apps Script (GAS) に独自ログ送信 | 実装例① インフィード関連記事 外部ライブラリを一切使わず、Blogger標準のJSON-in-script feedからランダム関連記事を動的挿入している。 実装例② アクセスログをGASに送信して独自スコアリング 滞在時間とスクロール率を掛け合わせた独自のエンゲージメントスコアを算出し、Google Apps Script経由でSpreadsheetに蓄積している。外部アクセス解析ツール不要でページ価値を定量評価できる。 実装例③ 画像の自動最適化 Bloggerの画像URLパターンを正規表現で書き換えて、表示コンテキストに応じたサイズ配信を実現。WebP変換もURLパラメータ一つで対応できる。 --- こんな人に向いている Bloggerが合う人 HTML/CSS/JSの基礎知識があり、テンプレートを自作したいエンジニア 維持コストゼロで長期運用したい個人ブロガー AdSenseでの収益化をすぐに始めたい人 Google Workspaceエコシステムに統合したい人 プラグイン依存のないシンプルな構成を好む人 Bloggerが合わない人 読者コミュニティ形成を重視する人（はてな・noteが適切） プラグインで機能を拡張したい人（WordPressが適切） GUIだけでカスタマイズを完結させたい人 --- まとめ Bloggerは「枯れたプラットフォーム」だ。しかしそれは欠点ではなく、仕様が安定していて予測可能であることを意味する。XMLの学習コストを払い切れば、コストゼロで自由度の高いブログ基盤として十分機能する。 WordPressのセルフホストと比べると、カスタマイズの自由度は同等でありながら、サーバー管理・セキュリティ対応・維持費という三つの負担がまるごとなくなる。 「日本語情報が少ない」という欠点すら、英語ドキュメントとソースコードを読む習慣があるエンジニアにとっては差別化のチャンスになる。コストを抑えつつ技術的に攻めたい個人エンジニアにとって、Bloggerは2026年現在も十分に有力な選択肢だ。
β版リリースへのお祝い
Mintorさん、β版リリースおめでとうございます。 ここまで形にされたことを尊敬しています。 一点だけ たぶん。 ユーザーの声はすべてを真に受けなくて大丈夫です。 私を含めユーザーになってしまいます。 noteのクリエーターとクリエーターの関係が、 リリースした瞬間から「提供者とユーザー」になってしまいます。 初期は意見が散らばりやすいので、 課題と好みを分けると運営が安定します。 そういう私のお節介なところ 今後も気づいた点をお伝えしてしまうかもしれません。 なので、最終的にはご自身の方向性を大切にしてください。 応援しています。 この記事は数日後に消します。 むみま
svelteいいぞぉ
React全盛の個人開発で、あえてSvelteKitを選ぶ理由 個人開発のフレームワークといえば、いまは React（Next.js） が王道です。 それでも僕は、作ってきたプロダクトを全部 SvelteKit で作っています。 半デジ半農のスキマ時間で開発を続けるなかで、推せる理由は2つ。楽に始められることと、Cloudflareに載せればサーバー代がほぼ$0で済むことです。 ちなみに作ってきたのは、求人アグリゲーター（Chiinavi）、焙煎ログPWA（IriLog）、音声SNS（vovovo）、ブラウザゲーム（薪割りゲーム）。ジャンルはバラバラですが、土台はどれもSvelteKitです。 推しポイント1：とにかく楽に始められる Reactは「画面を描くライブラリ」で、ルーティングも状態管理もサーバー処理も自分で組み合わせます。SvelteKitはそれらを最初から内包した「全部入り」。npx sv create 一発で、書き始められる状態がそろいます。 書き味もHTMLに近く、CSSはコンポーネント単位でスコープが効く。そしてSvelte 5では状態が「ただの変数」で、let count = $state(0) と書いて count++ すれば画面が変わる。Reactの useState / useEffect と依存配列でハマる、あの個人開発あるあるが起きにくい。 書くコードが減ればバグも減る。朝30分でも、思い出しコストが低いからすぐ手が動きます。続けられることが最優先の個人開発で、これは効きます。 推しポイント2：Cloudflareで、サーバー代がほぼ$0 SvelteKitは公式の adapter-cloudflare でWorkers / Pagesにそのまま乗ります。そしてCloudflareの無料枠が、個人開発には過剰なくらい太い（2026年時点）。 Workers：1日10万リクエスト Pages：転送量が実質無制限 D1（SQLite DB）：5GB、1日あたり読み取り500万行・書き込み10万行 R2：10GB、しかも転送量(egress)課金ゼロ 僕のプロダクトはホスティングもDBもストレージも全部Cloudflareですが、月の請求は今のところ $0。Next.jsは事実上Vercel前提で、無料枠は商用制限があり規模で課金が跳ねやすい。SvelteKitは最初からCloudflareと素直に噛むぶん、財布にやさしいインフラとそのままつながります。 正直なトレードオフ（Reactが勝つところ） エコシステムはReactが圧倒的。使いたいUIライブラリが見つかりやすい。 AIアシスタントもReactの方が強い。Svelte 5のrunesは新しく、生成コードに古い書き方が混ざることがある。 日本語情報・求人もReactが多い。ただ公式ドキュメントの出来は良いです。 まとめ SvelteKitの価値は「速い・軽い」より、一人で、安く、作り続けられること。一発で始められて、Cloudflareに載せれば毎月$0。ジャンルの違う4プロダクトを同じ道具で回せている事実が、僕にとっての証拠です。Reactで消耗しているなら、次の一作の土台に試してみてください。
Blogger向けテンプレート「M-StruX」では配色設定サンプルを用意しています
M-StruXでは基本的なカラー設定をカスタムプロパティで管理しています。 手軽に配色を変更できるように M-StruX公式サイト で配色サンプル+カスタムプロパティのコードを公開しています。 現在 14パターン の配色を用意しており、随時追加していく予定です。 [Sage Denim] [Ash Rose]
Wanko-note（わんこのて）が進化！GIFアニメからも画像を一発抽出可能に！
GIFアニメから「最高の1コマ」を。 Wanko-noteに待望の新機能が追加！ note専用の画像最適化ツール「Wanko-note（わんこの手）」がさらに便利になりました。 今回のアップデートでは、「GIFフレーム抽出機能」を新たに搭載しました。 GIFアニメの「ここ！」を逃さない 動画の切り抜きやゲーム画面の録画など、アニメーションGIFの「一番いいシーン」をnoteの見出し画像にしたいと思ったことはありませんか？ 新しくなったWanko-noteなら、GIFファイルをドロップするだけで全フレームを瞬時に解析。専用のスライダーを動かすだけで、まるで動画編集ソフトのように自由自在にフレームを選択できます。 抽出からnoteサイズへの変換までをシームレスに フレームを選んだ後は、これまでの機能がそのまま使えます。 1.91:1の黄金比変換: 1920x1006の高解像度で出力。 精密なトリミング: 矢印ボタンと数値入力でミリ単位の調整が可能。 リッチなぼかし背景: 余白を自然なぼかし画像で埋めて、プロのような仕上がりに。 創作の「本質」に集中するために GIFのコマ送りをスクリーンショットで撮り、別のソフトで開き、手動でリサイズし、保存してアップロードする……。そんな面倒な工程はもう必要ありません。 「ドロップ ➔ 選ぶ ➔ コピー ➔ noteに貼り付け」 この驚くほど軽やかな体験を、ぜひ新しいWanko-noteで体験してください。
AIで動くおもちゃの作り方
※ かなえさんアドバイスで記事にしました。 AIでコードは書けるようになりましたが、その先に何をすればよいかがわからない人がいます。 なので、AIで制御できる何かを作ろうと思いましたが、大体高いし、なんか愛情が持てない。 おもちゃなら安いし、これをコントロール出来たら楽しいかと思って、「のんきちゃん」という犬のおもちゃと 有線ラジコンキットとスマホを組み合わせたものを作りました。 これをイベントで展示したら「これ、どうやってつくるんですか？」と何人かに聞かれてそこで「ああ、何かを動かしたい人は私以外にもいる！」ということがわかりました。 そこでこの作り方を教えるワークショップのためのドキュメントを作成中です。 実際のワークショップもやるつもりなので興味がある方は連絡いただければ、次回開催の予定などをお知らせします。 掲載しているURLにはクローラーよけのパスワードをかけているので、ご覧になりたい方はXでDMをいただければ個別にお知らせします。
Mintor開設！初回からStripe（スプライト）初期設定の「罠」に詰まった話
みなさん、こんにちは。 Mintorのβ版、開設おめでとうございます！ 開発者同士をつなぐ新しいプラットフォームということで、これから楽しみに活用していきたいと思います。 普段はnoteをメインに執筆しているのですが、今回はMintorの初回記事として、さっそく私が「初期設定（決済連携）で派手に詰まったポイント」を共有します。 これから登録する新人さんや、同じように困っている方の参考になれば幸いです。 何に詰まったのか？：Stripe（スプライト）の連携問題 Mintorの初期設定を進める中で、決済まわりの設定として「Stripe（スプライト）」の連携を求められます。 実は、私はすでにStripeの既存アカウント（ID）を持っています。 そのため、「既存アカウントをサクッと紐付けたいだけ」だったのですが、ここで迷子になってしまいました。 迷子になった3つの理由 全体像（フロー）が見えない：次に何が起こるのかのロードマップが見えない。 ドキュメントが見つからない：ヘルプや仕様が書かれたページがパッと見つからない。 「次へ」を押すと新規取得画面っぽいフェーズになる：既存ユーザー用のログイン導線が見当たらず、「次へ」「次へ」と進む一本道しか用意されていないように見える。 既存アカウントを持っている人のための「直接設定画面」や「既存アカウントでログイン」というボタンが手前にないため、「このまま新規作成のフローに進んでいいのだろうか…？」と手が止まってしまっている状態です。 開発者プラットフォームにこの「詰まり」を投げる理由 UI/UXの観点から見ても、最初のオンボーディング（登録導線）でユーザーが迷子になるのはよくあることです。私自身がまさに今リアルタイムで詰まっているので、ここを通過した先輩エンジニアの方や、運営の方に届くといいなと思い、あえて初回の記事としてこの「困りごと」を公開してみました。 もし、「そこは『次へ』で進んだ後に、Stripe側で既存ログインできるよ！」とか「ここにドキュメントあるよ！」という情報をご存知の方がいれば、ぜひコメントなどで教えていただけると助かります！ これからMintorを始めるみなさん、どうぞよろしくお願いします。
Stripe決済の練習用プラグインを体験してみる
例えば、何かを開発したくなるとき。 私なら一番不安がある部分に焦点をあてます。 チャンクダウンできないものか？とひたすら壁打ちします。 つまり、小さなテーマを探しては、バラバラに分解します。 そして、もっとも「できそうもない」部分を プロトタイプを作って！ とLLMにやってもらいます。 そんなとき、「Stripe決済の練習用プラグインを体験してみる」 これは効き目があり過ぎます。 WordPressのプラグインは、中級者の技術が必要です。 でも、いまならCopilotがあります。 私はLLMが無い時代からやってましたので中身も解ります。 相当丁寧にやってくれます。 どんな言語でも、OKなので「動くやつ」と頼むのです。 WordPressの場合は、PHPです。ちょっとだけ敷居があります。 もっと、簡単なやつかでも、OKです。 大体がPythonでやれます。 まとめ どんな言語、どんなデータベース。 そんな追求は不要です。 なんなら、全部Scratchで作れます。
親子で楽しむ絵合わせゲーム「ピクマ α版」リリースしました！
はじめまして。 ジョブホッパー宮崎と申します。 この度、初めての個人Webサービスを開発してα版をリリースしました。 リリースしたα版の「ピクマ」というサービスについてざっくりと内容をまとめた記事を書きましたので、もしよろしければご覧いただけますと嬉しいです。 ▼記事詳細は下記URL https://note.com/jhpw/n/n045707eb4e17 引き続き、よろしくお願い致します。
Reactに疲れたあなたへ。HTMX × FastAPIなら個人開発はもっと楽しくなる
Reactに疲れたあなたへ。HTMX × FastAPIなら個人開発はもっと楽しくなる 「個人開発でサービスを作りたいのに、フロントエンドとバックエンドの連携で心が折れた」 「ローカルでは動くのに、デプロイの設定が複雑すぎて本番公開できない」 もしあなたが今、ReactやNext.jsの複雑さに疲弊しているなら、HTMXとFastAPIという選択肢が、その悩みを解決する特効薬になるかもしれません。 今回は、なぜこの組み合わせが「個人開発における最強の解」なのか、その理由を解説します。 なぜReact（SPA）開発は「沼」なのか？ Reactでの開発が難しい最大の理由は、「実質2つのアプリを作る必要があるから」です。 フロントエンド（JS）とバックエンド（API）は完全に別物。それぞれで状態管理を行い、JSONで通信し、型定義を合わせる作業は、一人でやるにはあまりに負荷が高いのです。「APIの仕様を変えたら画面が真っ白になった」という経験は、誰にでもあるはずです。 HTMX × FastAPI という「原点回帰」 HTMXとFastAPIの組み合わせは、この複雑さを根底から覆します。アプローチは極めてシンプルです。 「サーバー（FastAPI）が完成品のHTMLを返し、ブラウザ（HTMX）はそれを表示するだけ」 JSONをこねくり回す必要も、複雑なJavaScriptの状態管理も必要ありません。HTMLの属にhx-postと書くだけで、モダンな非同期通信が実現できます。 メリット①：圧倒的な「エラーの少なさ」 このスタックの最大の利点は、開発がPython（サーバーサイド）だけで完結することです。 脳の切り替え不要: 「今はJS、次はPython」という頭の切り替えがなくなります。バリデーションもDB操作も、全て使い慣れたPythonファイル内で行えます。 通信エラーの激減: サーバーから返ってくるのは「HTMLそのもの」です。JSONのパースミスや、フロントとバックの型の不一致によるバグは物理的に発生しません。 メリット②：デプロイの悩みから解放 初心者が最も挫折する「デプロイ」も、驚くほど簡単になります。 React構成では、フロントとバックを別の場所にデプロイし、CORS（ドメイン間の通信許可）の設定や認証トークンの管理に頭を悩ませる必要があります。 しかし、HTMX × FastAPIなら、FastAPIのサーバーを1つ立ち上げるだけです。 ビルド不要: npm run buildで謎のエラーが出る恐怖とは無縁です。 CORS設定不要: HTMLもAPIも同じサーバーから配信されるため、複雑なセキュリティ設定に悩む必要がありません。 PaaS連携も一瞬: RenderやFly.ioなどに、Pythonコードを置くだけで本番環境が完成します。 実装スピードの違い 例えば「Todoリストへの追加機能」を作る場合： React: API作成、fetch処理の実装、Loading/Error状態の管理、再レンダリング制御…と多くの手順が必要です。 HTMX: PythonでDBに保存してHTML（<li>タグ）を返す処理を書き、HTML側にhx-postと書く。これだけで完了です。JavaScriptは0行です。 結論：まずは「完成」させよう 個人開発で最も大切なのは、技術的な高尚さではなく、「サービスを完成させて世に出すこと」です。 環境構築やエラー解決に時間を吸い取られ、アイデアを形にできないまま終わるのはあまりに勿体無い。Pythonが書けるなら、まずはFastAPIとHTMXを試してみてください。そのシンプルさと「爆速で動くモノができる」快感に、きっと驚くはずです。