【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を試してみてください。そのシンプルさと「爆速で動くモノができる」快感に、きっと驚くはずです。