Indigo Works | Blog

NotebookLMにJSTQBシラバスを読み込ませたら、最強の試験対策ツールになった話

Wed, 04 Mar 2026 00:00:00 GMT

はじめに

現在、QAエンジニアとしてのスキルアップも兼ねて、JSTQB Foundation Level（FL）の資格勉強を進めています。

JSTQBの公式シラバスは非常に網羅的で勉強になる反面、テキストのボリュームが多く、ただ読んでいるだけではなかなか頭に入ってこないのが悩みでした。

そこで、話題のGoogleのAIツール 「NotebookLM」 に、公式シラバス（V4.0のPDF）を丸ごと読み込ませて試験対策の教材を作らせてみたところ……結果として、想像を絶するクオリティの学習環境が爆誕しました。

今回は、NotebookLMを使ってどのような試験対策コンテンツを作成したのか、その衝撃的な体験をシェアします。

NotebookLMで生成したものとその感想

NotebookLMにシラバスをアップロードし、学習ガイド機能などを使って以下の4つのコンテンツを生成しました。

1. まるでラジオ番組！男女2人の「音声解説」

個人的に一番感動したのがこの機能です。アップロードしたシラバスの内容をもとに、男女2人のパーソナリティが会話形式で要約してくれるポッドキャストのような音声を自動生成してくれます。

良かった点: 堅苦しい専門用語も、パーソナリティ同士の自然な掛け合いの中で説明されるため、すんなりと頭に入ってきます。散歩中や家事をしながらの「ながら聞き」学習に最適でした。

2. 過去問代わりに使える「クイズ」と「フラッシュカード」

インプットだけでなく、アウトプットの練習用としてクイズとフラッシュカードも生成しました。

良かった点: シラバスの要点を突いた問題が生成され、まさに「過去問もどき」として非常に使いやすい出題形式でした。自分で一から単語帳を作る手間が省け、すぐに知識の定着度テストに移行できるのが大きなメリットです。

3. 要点が視覚化された「スライド」

さらに、シラバスの全体像を把握するためのスライド資料も作成しました。

良かった点: まるで人間がPowerPointでまとめたような、要点が整理されたとてもわかりやすい資料が一瞬で完成しました。試験直前の総復習や、各章の構造を俯瞰したい時に大活躍します。

衝撃だったポイント

今回NotebookLMを使ってみて最も衝撃だったのは、これら総合的にクオリティの高いアウトプットが「瞬時」に生成されたことです。

これまでであれば、シラバスを読み込み、自分でノートにまとめ、単語帳を作り……と数日〜数週間かかっていた「学習の準備作業」が、PDFをドラッグ＆ドロップして数クリックするだけで終わってしまいました。

AIが単なる「検索ツール」から、完全に「優秀な専属チューター」へと進化していることを肌で感じました。

まとめ

JSTQBをはじめ、分厚い公式ドキュメントやシラバスを読み込む必要のある資格試験において、NotebookLMは間違いなくゲームチェンジャーになります。

まだ使ったことがない方は、ぜひ手元のPDFやドキュメントを読み込ませてみてください。学習効率が劇的に跳ね上がるはずです！

『エッセンシャルスクラム』に学び、アジャイル現場へ応用したい話

Sun, 01 Mar 2026 00:00:00 GMT

システム開発を進める中で、「アジャイルにやっているつもりだけど、なんだかうまくいかない」「要件変更に振り回されて疲弊している」と感じる瞬間はありませんか？

スクラム開発のバイブルとも言える Kenneth S. Rubin (著) 『エッセンシャルスクラム』を読み、こちらに要約いたしました。

その中から 「現場のエンジニアが本当に知っておくべきスクラムの要点」 を整理しました。単なるフレームワークの解説にとどまらず、開発のスピードと品質を両立させるためのマインドセットについて紹介します。

1. 要件は「契約」ではなく「対話のプレースホルダー」

従来のウォーターフォール開発では、要件定義書は「絶対に守るべき契約」でした。しかしスクラムでは、要件（ユーザーストーリー）を 「詳細を議論するための予約席（プレースホルダー）」 として扱います。

INVEST原則を意識する: 良いストーリーは、独立しており（Independent）、交渉可能で（Negotiable）、価値があり（Valuable）、見積り可能で（Estimatable）、適切に小さく（Small）、テスト可能（Testable）であるべきです。
完璧な文書より対話を: 見た目が立派な仕様書ほど、質問を封じ込めてしまいます。スクラムでは、ジャストインタイムで要件を分割し、チームとプロダクトオーナーの「対話」を通じて詳細を詰めていきます。

2. 見積もりと計画の真実：「地図より地形を信じよ」

「いつできるのか？」という問いに対し、スクラムは非常に現実的なアプローチをとります。

相対サイズで見積もる: 人間は絶対的な時間を見積もるのは苦手ですが、相対的な比較（AはBの2倍大変そう）は得意です。そのため、時間ではなく「ストーリーポイント」という相対値で見積もり（プランニングポーカー）を行います。
ベロシティの罠: チームが1スプリントで消化できるポイント数（ベロシティ）は、あくまで「現状の把握（体重計）」です。これをチームの評価指標や目標値にしてはいけません。目標にされた瞬間、エンジニアは品質を犠牲にしてポイントを水増しするようになり、システムは確実に崩壊します（グッドハートの法則）。
期日固定とスコープの調整: 期日が動かせないプロジェクトでは、「無理をして全部作る」のではなく、「期日を守るためにスコープ（機能）を削る」という思考の切り替えが不可欠です。

3. スピードを殺す「技術的負債」との戦い

本書の中で最もエンジニアが共感し、かつ恐ろしいのが「技術的負債」についての言及です。

ベロシティの偽装: 納期へのプレッシャーからテストや設計を省き、見かけ上のベロシティを維持することは、後から莫大な「利息（バグ対応や修正困難なコード）」を支払うことになります。
品質担保こそが最速への道: 手動テストの横行は負債の筆頭です。CI/CDの構築や、Playwright等を用いたE2Eテスト自動化といった技術的プラクティスを組み込み、「厳しい完了の定義（DoD）」を死守することが、結果的に開発スピードを高く保つ唯一の道です。
ボーイスカウトのルール: 「来た時よりも美しくして去る」。既存コードを触るついでに数分のリファクタリングを息をするように行うことが、システム寿命を劇的に延ばします。

4. フリーランスや個人開発へのスクラムの応用

チーム開発を前提としたスクラムですが、その原則はフリーランスの案件や、個人プロジェクトを回す上でも強力な武器になります。

ビジョンの策定とスコープクリープの防止: 個人開発では「あれもこれも」と機能を追加したくなります（スコープクリープ）。開発前に「プロダクトビジョン」を明文化しておくことで、「本当に今必要な機能か？」を立ち止まって判断できます。
WIP（仕掛品）の制限とスウォーミング: 複数の機能やプロジェクトを同時に進めるマルチタスクは、コンテキストスイッチによる無駄を生みます。1つのタスクに集中して「完全に完了（Done）」させてから次へ進む（一人スウォーミング）を意識するだけで、デリバリー速度は格段に上がります。
一人レトロスペクティブ（ふりかえり）の価値: 開発に行き詰まった際、実装に没頭する手を止め「なぜこのエラーに時間を溶かしたのか？」を振り返る。そして「次回は実装前に技術検証（スパイク）の時間を取る」といったアクションに繋げることが、継続的な成長を生み出します。

おわりに：スクラムに「終了状態」はない

『エッセンシャルスクラム』の最終章で語られている通り、スクラムを導入して「これで完璧だ」という終了状態（End State）はありません。

誰かが敷いたレールを歩くのではなく、自分たちのチーム（あるいは自分自身）のコンテキストに合わせて、検査と適応のループを回し、自分たち自身の道を切り拓いていくこと。それこそが、真のアジャイル開発の姿です。

Cloudflare PagesにAWS Route 53管理のカスタムドメインを設定する

Sun, 01 Mar 2026 00:00:00 GMT

Cloudflare Pagesで公開しているサイトに、AWS Route 53で管理しているドメインをカスタムドメインとして設定する手順を解説します。今回は your-project.pages.dev で公開しているサイトを www.yourdomain.com で表示できるようにします。

なぜ `yourdomain.com` ではなく `www.yourdomain.com` をメインにするのか

ベストプラクティスは www.yourdomain.com をメインにして、yourdomain.com からリダイレクト する構成です。

理由はDNSの仕様にあります。Cloudflare PagesはCNAMEレコードを使ってドメインを紐付けますが、ルートドメイン（yourdomain.com）にはCNAMEレコードを設定できません（RFC上の制約）。Route 53ではALIASレコードという独自機能で回避できますが、Cloudflare Pages向けの直接ALIASは設定できないため、www サブドメインを使う方がシンプルです。

Step 1: Cloudflare PagesにカスタムドメインのCNAMEを設定する

Cloudflare Dashboard → 対象のPagesプロジェクト → 「Custom domains」 タブを開く
「Set up a custom domain」 をクリック
www.yourdomain.com を入力して進む
Setup Methodの選択画面で 「My DNS provider」→「Begin CNAME setup」 をクリック
- ドメインがCloudflare管理の場合は「Cloudflare DNS」を選ぶと自動設定されますが、今回はRoute 53管理のため「My DNS provider」を選択します
表示されるCNAMEレコードの情報をメモする

Name   : www
Target : your-project.pages.dev

Step 2: AWS Route 53にCNAMEレコードを追加する

AWS Console → Route 53 → yourdomain.com のホストゾーンを開く
「レコードを作成」 をクリック
以下を入力して保存する

項目	値
レコード名	`www`
タイプ	`CNAME`
値	`your-project.pages.dev`
TTL	`300`

Route 53側で「レコードが正常に作成されました」と表示されれば成功です。

Step 3: Cloudflare側でDNS確認を待つ

Cloudflare PagesのCustom domains画面に戻ると、www.yourdomain.com が 「Inactive (Requires DNS setup)」 の状態になっています。

DNS変更が世界中に伝播するまで最大24時間かかりますが、通常は数分〜数時間で反映されます。しばらく待ってからページをリロードすると 「Active・SSL enabled」 に変わります。

![Cloudflare Custom domains Active状態]

SSL証明書も自動で発行されるため、別途設定は不要です。

おまけ：`yourdomain.com`（ルートドメイン）からのリダイレクト設定

yourdomain.com にアクセスした人を www.yourdomain.com にリダイレクトするには、S3の静的ウェブサイトホスティング機能を使います。

S3バケットを作成する

AWS Console → S3 → 「バケットを作成」
バケット名を yourdomain.com（ドメイン名と完全一致） で作成
- リージョン: us-east-1（バージニア北部）
「パブリックアクセスをすべてブロック」のチェックを外す

S3でリダイレクトを設定する

作成したバケット → 「プロパティ」 タブ
「静的ウェブサイトホスティング」 → 「編集」
以下を設定して保存

項目	値
ホスティングタイプ	オブジェクトのリクエストをリダイレクトする
ホスト名	`www.yourdomain.com`
プロトコル	`https`

Route 53にALIASレコードを追加する

Route 53 → yourdomain.com ホストゾーン → 「レコードを作成」
以下を設定して保存

項目	値
レコード名	空欄（ルートドメイン）
タイプ	`A`
エイリアス	オン
トラフィックのルーティング先	S3ウェブサイトエンドポイントへのエイリアス（`us-east-1`）

バケット名がドメイン名と一致していれば、Route 53が自動でS3エンドポイントを候補として表示します。

まとめ

今回の設定をまとめると以下のとおりです。

アクセスURL	動作
`www.yourdomain.com`	Cloudflare Pages のサイトが表示される
`yourdomain.com`	`www.yourdomain.com` へ301リダイレクト

Cloudflare PagesとAWS Route 53を組み合わせた構成でも、CNAMEとS3リダイレクトを使えばスムーズにカスタムドメインを設定できます。

JavaScriptとTypeScriptの歴史の整理：バージョンとモジュールシステムの変遷

Mon, 23 Feb 2026 00:00:00 GMT

エンジニアとしてモダンなWeb開発（Next.jsやAstroなど）を行う上で避けて通れない、JavaScript（JS）とTypeScript（TS）の関係性や歴史的背景を整理します。

1. JavaScriptとTypeScriptの関係

TypeScriptは、JavaScriptをベースに「型」の機能を追加した言語であり、 JavaScriptのスーパーセット（超集合） です。

JavaScript (JS): ブラウザやNode.jsで直接実行できる標準的な言語。
TypeScript (TS): JSの全機能を含みつつ、静的型付けなどの拡張機能を加えたもの。
互換性: 有効なJSコードは、そのまま有効なTSコードとして扱えます。

2. JavaScript (ECMAScript) の歴史と名称の変遷

JavaScriptの規格は ECMAScript (ES) と呼ばれます。その名称とバージョンの付け方には大きな歴史的転換点がありました。

ES2015 (ES6) 以前：黎明期から停滞期

1995年: Netscape社で誕生。わずか10日間で開発されました。
ES3 (1999年): 長らく標準として使われたバージョン。
ES5 (2009年): 約10年の沈黙を破って登場。forEach や JSON サポートなど、現代的なJSの基礎が作られました。

大転換期：ES2015 (ES6) と名称の変更

2015年、JS史上最大のアップデートが行われ、class 構文や import/export など、大規模開発に耐えうる機能が多数導入されました。

名称の変更: 従来は「ES6」のようにバージョン番号で呼ばれていましたが、この年から 「毎年アップデートを行う」という方針に切り替わり、名称も「ES2015」のように年号を冠する形式 になりました。
現在: 以降はES2016、ES2017……と毎年小規模なアップデートが繰り返され、現在はES2024まで進化しています。

3. TypeScriptの誕生と進化

2012年: Microsoftが誕生させる。JSが大規模開発に使われる際のエラーを防ぐことが目的でした。
TS 2.0 (2016年): strictNullChecks が導入され、型安全性が飛躍的に向上しました。
TS 5.0 (2023年〜): 現在の主流バージョン。コンパイルの高速化などが進んでいます。

4. CommonJS (CJS) と ES Modules (ESM) の詳細

モジュールシステム（ファイルを分割して読み書きする仕組み）には、歴史的な経緯から2つの主要な形式があります。現在、これらは混在した状況にあり、違いを正しく理解することが重要です。

比較表

項目	CommonJS (CJS)	ES Modules (ESM)
キーワード	`require()`, `module.exports`	`import`, `export`
標準の場	Node.js（歴史的・サーバーサイド）	ブラウザ・JS標準規格（モダン）
読み込みタイミング	実行時 (Runtime)	静的解析時 (Static)
トップレベル await	不可	可能
拡張子	`.js` (デフォルト) / `.cjs`	`.js` (デフォルト) / `.mjs`

技術的な大きな違い

静的解析 vs 動的実行:
- ESMはプログラムの実行前にインポートの依存関係を解決します。これにより、使われていないコードを削ぎ落とす Tree-shaking が可能になり、ビルド後のファイルサイズを軽量化できます。
- CJSはコードの実行中に require() を通じて動的に読み込むため、条件分岐（if 文）の中でインポートするような書き方が可能です。
互換性の問題:
- 現在のNode.js環境では両方の形式をサポートしていますが、ESMからCJSを呼ぶのは比較的容易な一方、CJSからESMを呼ぶ場合には制約（非同期的な扱いや import() 関数の利用など）が生じることがあります。
モダン環境での立ち位置:
- Next.js 16系 など、現代的なフロントエンドフレームワークでは ESMが標準 です。

Astro + Starlightブログにおけるタグ管理のベストプラクティス（Zodを使った表記揺れの防止）

Sun, 22 Feb 2026 00:00:00 GMT

はじめに

AstroとStarlight（starlight-blog）を使って技術ブログを運用していると、記事が増えるにつれて気になってくるのが**「タグの表記揺れ」**です。

例えば、記事のフロントマターで以下のようにタグを指定していくと…

# 記事A
tags: [Git, Next.js, UI/UX]

# 記事B
tags: [git, nextjs, ui-ux]

サイト上では「Git」と「git」が別のタグとして扱われてしまい、タグ一覧ページが分散してしまいます。毎回「大文字だっけ？記号は入れるんだっけ？」と過去の記事を確認しながら入力するのはミスが起きやすく、執筆体験もよくありません。

そこで今回は、Zodの transform 機能を活用して、システム側でタグの表記を自動的に正規化・統一するベストプラクティスをご紹介します。

Zodとは？なぜAstroで使われるのか

今回の解決策の鍵となるのが Zod です。

Zodは、TypeScriptファーストのスキーマ宣言およびバリデーション（データ検証）ライブラリです。「このデータは文字列の配列であるべき」「この項目は必須である」といったルール（スキーマ）を定義し、実際のデータがそのルールに従っているかをチェックしてくれます。

Astro（およびStarlight）の Content Collections という機能では、MarkdownやMDXのフロントマター（記事先頭のメタデータ）の型を厳格に管理するために、このZodが標準で組み込まれています。

Zodが特に優れているのは、単に「データが正しいか弾く（バリデーション）」だけでなく、「データを別の望ましい形に変換する（トランスフォーム）」 機能を持っている点です。今回はこの機能を活用します。

解決策：Zodスキーマと辞書（Map）を使った自動変換

アプローチは非常にシンプルです。 src/content.config.ts に「タグの辞書」を用意し、記事がビルドされる際にZodの機能を使って**「入力されたタグ（スラッグ）」を「正式名称」に自動変換**する処理を挟み込みます。

1. `src/content.config.ts` の実装

以下のコードを src/content.config.ts に記述します。

src/content.config.ts

import { defineCollection, z } from 'astro:content';
import { docsLoader } from '@astrojs/starlight/loaders';
import { docsSchema } from '@astrojs/starlight/schema';
import { blogSchema } from 'starlight-blog/schema';

// ▼ 1. タグの正式名称を管理する辞書（キーはすべて小文字で定義します）
const TAG_MAP: Record<string, string> = {
  'git': 'Git',
  'github': 'GitHub',
  'nextjs': 'Next.js',
  'next.js': 'Next.js', // 記号入りの表記揺れ対策
  'react': 'React',
  'typescript': 'TypeScript',
  'javascript': 'JavaScript',
  'astro': 'Astro',
  'starlight': 'Starlight',
  'ui-ux': 'UI/UX',
  'jstqb': 'JSTQB',
  'claude-code': 'Claude Code',
  'playwright': 'Playwright',
  'ai': 'AI',
};

export const collections = {
  docs: defineCollection({
    loader: docsLoader(),
    schema: docsSchema({
      // docsSchema の extend を使って blogSchema を統合し、さらにタグを変換します
      extend: (context) => {
        // starlight-blog のベーススキーマを読み込む
        const baseSchema = blogSchema(context);

        // ▼ 2. そのスキーマの `tags` フィールドの動作を上書き（拡張）する
        return baseSchema.extend({
          tags: z.array(z.string())
            .optional()
            .transform((tags) => {
              if (!tags) return undefined;

              return tags.map((tag) => {
                // 入力されたタグを小文字化してキーにする
                const key = tag.toLowerCase();
                // 辞書にあれば正式名称を、なければ入力された文字をそのまま返す
                return TAG_MAP[key] || tag;
              });
            }),
        });
      },
    }),
  }),
};

2. コードの解説（Zodの動き）

注目すべきは tags: z.array(z.string()).optional().transform(...) の部分です。

z.array(z.string()).optional(): まず、入力されたフロントマターの tags が「文字列の配列」であること（または未定義であること）を検証します。
.transform(...): 検証を通過した安全な配列データを受け取り、中のタグを一つずつループ（map）して変換します。
フォールバック処理: return TAG_MAP[key] || tag; とすることで、「辞書に登録されていないタグは、入力された文字をそのまま使う」という柔軟な仕様にしています。

運用ルール：タグは「小文字・ケバブケース」で書く

この仕組みを導入したら、今後の記事執筆時のルールはたった1つです。

「タグは小文字・ケバブケース（スラッグ）で入力する」

---
title: Next.jsとStarlightの連携について
date: 2026-02-22
slug: blog/nextjs-starlight-integration
tags: [nextjs, starlight, ui-ux]
---

このようにID感覚で機械的に入力するだけで、サイトに表示される際にはZodの変換処理が走り、Next.js, Starlight, UI/UX という美しい正式名称になります。執筆時に大文字小文字を気にする必要はもうありません。

辞書にない「マイナーなタグ」はどうなる？

すべてのタグを事前に辞書登録するのは面倒です。しかし今回の実装では「辞書になければそのまま返す」仕組みにしているため、辞書に登録していないタグは、フロントマターに書いた通りの大文字・小文字でそのまま表示されます。

---
tags: [Docker, VS Code, ベランダ菜園]
---

（※これらは辞書にないため、そのまま Docker, VS Code, ベランダ菜園 と表示されます）

つまり、以下のようなハイブリッドな運用が可能です。

基本ルール: 頻繁に使う主要な技術タグは [git, nextjs] のように小文字スラッグで書き、辞書で綺麗に統一する。
特例ルール: 今回しか使わないような単語は、辞書を更新せず、表示したい文字のまま [Docker] と直接書いてしまう。

まとめ

Astro（Starlight）のContent CollectionsとZodを組み合わせることで、「執筆時はシンプルにID指定」「表示時は綺麗に整形された名称」 というモダンなタグ管理が実現できます。

Zodは単なる型チェックツールではなく、データ変換のパイプラインとしても非常に優秀です。表記揺れによるタグの分散を防ぎつつ、新しいタグも気軽に追加できる柔軟性を備えたおすすめの構成ですので、ぜひ試してみてください！

WSL2環境でペット専用LoRAを訓練してStability Matrixで画像生成するまでのまとめ

Sun, 15 Feb 2026 00:00:00 GMT

はじめに

この記事では、ペット（うさぎ）のクッキーの写真から専用のLoRAモデルを訓練し、Stability Matrixで画像生成するまでの全工程を解説します。

WSL2環境でのセットアップから、実際の訓練、そして画像生成まで、実際に遭遇したトラブルシューティングも含めて詳しく記録しています。

LoRA（ローラ）とは？

AIに追加学習させるための「軽量化技術」のことです。

元の巨大なAIモデル（数GB）をまるごと再学習させるのではなく、覚えさせたい特徴（今回ならペットのクッキー）だけの「差分データ」を作ります。これにより、短時間（数分）かつ低スペックなPCでも学習が可能になり、出来上がるファイルサイズも非常に小さくなるのが特徴です。

プロジェクト概要

目標

うさぎ（クッキー）専用のLoRAモデルを作成
Stable Diffusionでクッキーの画像を生成できるようにする
最終的にWebサイトでアニメーション化

使用技術スタック

OS: WSL2 (Ubuntu 20.04)
Python: 3.10.13 (pyenv管理)
訓練フレームワーク: Kohya SS GUI
ベースモデル: Realistic Vision V6.0 B1
GPU: NVIDIA GeForce RTX 4060 Ti (8GB VRAM)
画像生成: Stability Matrix + Stable Diffusion WebUI

1. 環境構築

1.1 Python環境のセットアップ

WSL2環境では、システムのPythonではなくpyenvで管理することを推奨します。

# pyenvのインストール
curl https://pyenv.run | bash

# .bashrcに設定を追加
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc
source ~/.bashrc

# 依存パッケージのインストール
sudo apt update
sudo apt install -y build-essential libssl-dev zlib1g-dev \
libbz2-dev libreadline-dev libsqlite3-dev curl \
libncursesw5-dev xz-utils tk-dev libxml2-dev \
libxmlsec1-dev libffi-dev liblzma-dev

# Python 3.10.13のインストール
pyenv install 3.10.13

重要ポイント: Python 3.12ではなく3.10系を使用してください。PyTorchや依存パッケージの互換性の問題を避けるためです。

1.2 Kohya SS GUIのインストール

# プロジェクトディレクトリ作成
mkdir -p ~/ml_projects
cd ~/ml_projects

# Kohya SSをクローン
git clone https://github.com/bmaltais/kohya_ss.git
cd kohya_ss

# Python 3.10を使用
pyenv local 3.10.13

# セットアップ実行
./setup.sh

# GUI起動
./gui.sh --headless

ブラウザで http://localhost:7860 にアクセスしてGUIが表示されればOKです。

2. 訓練データの準備

2.1 写真の収集

必要な写真枚数: 15〜30枚（推奨: 20〜25枚）

撮影のポイント:

様々な角度（正面、側面、後ろ、斜め）
様々なポーズ（座る、立つ、食べる、毛づくろい）
明るい場所で撮影
ピントをしっかり合わせる
背景はシンプルに

今回はペットカメラの映像から53枚の画像を抽出しました。

2.2 画像の前処理

ペットカメラの画像から、背景やうさぎ以外の物体を取り除き、訓練向きの画像にするよう画像を処理します：

#!/usr/bin/env python3
import os
from pathlib import Path
from PIL import Image
from rembg import remove
import numpy as np

# パス設定
input_dir = Path("training_data/cookie/img/20_cookie_rabbit")
output_dir = Path("training_data/cookie/processed")
output_dir.mkdir(parents=True, exist_ok=True)

# 画像ファイルを取得
image_files = sorted(input_dir.glob("*.jpg"))
print(f"Found {len(image_files)} images")

for idx, img_path in enumerate(image_files, 1):
    print(f"Processing {idx}/{len(image_files)}: {img_path.name}")

    try:
        # 画像を読み込み
        img = Image.open(img_path)

        # 背景除去
        img_no_bg = remove(img)

        # クロッピング（被写体を中心に）
        img_array = np.array(img_no_bg)
        alpha = img_array[:, :, 3]
        coords = np.column_stack(np.where(alpha > 0))

        if len(coords) == 0:
            continue

        y_min, x_min = coords.min(axis=0)
        y_max, x_max = coords.max(axis=0)

        # 余白追加
        height = y_max - y_min
        width = x_max - x_min
        margin = int(max(height, width) * 0.1)

        y_min = max(0, y_min - margin)
        y_max = min(img_array.shape[0], y_max + margin)
        x_min = max(0, x_min - margin)
        x_max = min(img_array.shape[1], x_max + margin)

        cropped = img_no_bg.crop((x_min, y_min, x_max, y_max))

        # 512x512にリサイズ
        size = max(cropped.size)
        square_img = Image.new('RGBA', (size, size), (255, 255, 255, 0))
        paste_x = (size - cropped.size[0]) // 2
        paste_y = (size - cropped.size[1]) // 2
        square_img.paste(cropped, (paste_x, paste_y))

        final_img = square_img.resize((512, 512), Image.Resampling.LANCZOS)

        # 白背景に変換
        white_bg = Image.new('RGB', (512, 512), (255, 255, 255))
        white_bg.paste(final_img, (0, 0), final_img)

        # 保存
        output_path = output_dir / f"cookie_{idx:03d}.jpg"
        white_bg.save(output_path, 'JPEG', quality=95)

    except Exception as e:
        print(f"Error: {e}")
        continue

print(f"Processing complete!")

2.3 ディレクトリ構造

訓練用のディレクトリ構造は以下の通り：

~/ml_projects/
├── kohya_ss/                    # 訓練ツール
├── models/                      # ベースモデル
│   └── realisticVisionV60B1_v51HyperVAE.safetensors
└── training_data/
    └── cookie_final/
        └── img/
            └── 20_cookie_rabbit/  # 20は繰り返し回数
                ├── cookie_001.jpg
                ├── cookie_002.jpg
                └── ...

重要: フォルダ名は {繰り返し回数}_{トリガーワード} の形式にします。

3. LoRA訓練の実行

3.1 Kohya SS GUIでの設定

LoRAタブで以下のパラメータを設定：

Model設定

Pretrained model: /path/to/realisticVisionV60B1_v51HyperVAE.safetensors
Image folder: /path/to/training_data/cookie_final/img
Output folder: /path/to/outputs/cookie_lora
Save as: safetensors
Save precision: fp16

Parameters - Basic

Train batch size: 1
Epoch: 10
Save every N epochs: 2
Learning rate: 0.0001 (1e-4)
LR Scheduler: cosine
Optimizer: AdamW8bit
Max resolution: 512,512

Parameters - Advanced

Network Rank (Dimension): 32
Network Alpha: 16
CrossAttention: xformers

3.2 訓練の実行

# Kohya SS GUIで"Start training"をクリック
# または、コマンドラインから：

cd ~/ml_projects/kohya_ss
source venv/bin/activate

accelerate launch --mixed_precision fp16 \
  sd-scripts/train_network.py \
  --config_file outputs/cookie_lora/config.toml

3.3 訓練結果

Training Details:
- Images: 53 (with 20 repeats = 1060 steps)
- Epochs: 10
- Total steps: 1600
- GPU: RTX 4060 Ti
- Training time: 4分52秒
- Final loss: 0.0375

非常に高速に訓練が完了しました。RTX 4060 Tiの性能が素晴らしいです。

4. トラブルシューティング

4.1 NumPy互換性エラー

エラー内容:

A module that was compiled using NumPy 1.x cannot be run in NumPy 2.2.6
AttributeError: _ARRAY_API not found

解決方法:

cd ~/ml_projects/kohya_ss
source venv/bin/activate
pip install "numpy<2" --break-system-packages

NumPy 2.xとNumPy 1.xの互換性問題です。TensorFlowなどの依存パッケージがNumPy 1.xでコンパイルされているため、ダウングレードが必要です。

※ このオプションは本来推奨されません。（仮想環境外への影響がある）今回は仮想環境内での実行を前提としているため使用しましたが、本来は注意が必要です

4.2 Stable Diffusion WebUIのインストールエラー

WSL2環境でStable Diffusion WebUIのインストールに失敗しました：

エラー内容:

ModuleNotFoundError: No module named 'pkg_resources'
ERROR: Failed to build CLIP

試した解決策:

setuptoolsの再インストール
仮想環境の再作成
CLIPの手動インストール

など、様々な方法を試しました。ここでかなり時間を溶かしましたが、結局、WSL2環境で解決できませんでした。

最終的な解決: WSL2でのローカルインストールを諦め、Windows側でStability Matrixを使用することに決定しました。

5. 画像生成のセットアップ

5.1 Stability Matrixの使用

最終的にWindows 11でStability Matrixを使用しました：

Stability Matrixをダウンロード・インストール
LoRAファイルとベースモデルを配置

# WSL2からWindowsへファイルコピー
cp ~/ml_projects/outputs/cookie_lora/cookie_lora.safetensors \
   /mnt/d/[your-path-to-stability-matrix]/Data/Models/Lora/

cp ~/ml_projects/models/realisticVisionV60B1_v51HyperVAE.safetensors \
   /mnt/d/[your-path-to-stability-matrix]/Data/Models/StableDiffusion/

5.2 画像生成

プロンプト例:

Positive:
rabbit, cookie_lora, (white and brown patches), cute rabbit,
fluffy fur, photorealistic, detailed fur texture,
<lora:cookie_lora:0.8>

Negative:
blurry, low quality, distorted, deformed, ugly, bad anatomy

パラメータ:

Sampling method: DPM++ 2M SDE
Sampling steps: 20
Width: 512
Height: 512
CFG Scale: 4
LoRA weight: 0.8

技術的な学び

pyenvの重要性

WSL2環境では、システムのPythonではなくpyenvで管理することが非常に重要です。特に：

複数のプロジェクトで異なるPythonバージョンを使い分けられる
システムのパッケージマネージャーと競合しない
プロジェクトごとに独立した環境を維持できる

NumPyバージョン管理

機械学習プロジェクトでは、NumPyのバージョンに特に注意が必要です：

TensorFlow、PyTorchなどはNumPy 1.xでビルドされていることが多い
NumPy 2.xとの互換性問題は頻繁に発生する
numpy<2を明示的に指定することを推奨

WSL2 vs Windows Native

今回の経験から：

訓練: WSL2が最適（Linuxネイティブ、GPUサポート良好）
画像生成: Windowsネイティブツール（Stability Matrix）の方が簡単
ハイブリッドアプローチが実用的

LoRA訓練のベストプラクティス

データ品質:
- 様々な角度・ポーズの画像を用意
- 背景除去で訓練対象を明確化
- 512x512への統一リサイズ
パラメータ調整:
- Network Rank: 32（標準）
- Learning Rate: 1e-4（安定）
- Epochs: 10（過学習を避ける）
繰り返し回数:
- 画像枚数が少ない場合は繰り返しを増やす
- 今回: 53枚 × 20回 = 1060 steps

まとめ

WSL2環境でペット専用のLoRAモデルを訓練し、Stable Diffusionで画像生成するまでの全工程を実施しました。

成功のポイント:

pyenvでPython環境を適切に管理
NumPyバージョンの互換性に注意
Kohya SS GUIで効率的な訓練
Stability Matrixで簡単な画像生成環境構築

訓練結果:

訓練時間: わずか4分52秒
生成画像の品質: ペットの特徴をよく捉えている
LoRAファイルサイズ: 26MB

今後の展開:

生成した画像をWebサイトでアニメーション化
様々なポーズ・表情のバリエーション生成

この記事が、ペット専用AIモデルを作成したい方の参考になれば幸いです。

参考リンク

成果物

実際にこのプロセスを経て生成されたクッキー（のAI分身）がこちらです。

クッキーが5匹！？

これは「1rabbit」というプロンプトに対して、解像度（896x1152）が広すぎたために「スペース余ってるし、もう何匹か置いとくか！」とAIが気を利かせた結果のようです。

画像サイズを512x512にして再度生成しました。

クッキーが2匹。物理法則が怪しげです。

こちらもクッキーがまだ2匹。親子・・・？

クッキーの毛の質感や模様がリアルに再現されているのはGoodですが、物理法則が少し怪しげです。かわいさも足りないです。

学習データ用の画像に「毛づくろい中の変なポーズ」が多く含みすぎていた可能性が大です。もう少しバリエーション豊かにする必要がありそうです。

もっと調整して、クッキーのかわいさが引き立つような画像を生成しようと思います！

Stripeアカウント閉鎖からGitHub Sponsors成功まで：AI画像サービスの決済問題解決記録

Fri, 13 Feb 2026 00:00:00 GMT

はじめに

AI生成画像を無料で提供する「Free Images」を運営していたある日、Stripeから一通のメールが届きました。

「カードネットワークパートナーの制限により貴社アカウントのサポート継続が困難となりました」

この記事は、突然の決済手段喪失から、GitHub Sponsorsで支援を受け付けられるようになるまでの2日間の記録です。同じような問題に直面している方、特にAI関連サービスを運営している方の参考になれば幸いです。

1：突然のアカウント閉鎖通知

運営していたサービス

Free Images は、AI生成画像を無料で提供するWebサービスです。誰でも自由にダウンロードして使える画像を提供し、運営費用をまかなうためにStripeの支援リンクを設置していました。

ビジネスモデル：

画像配布：完全無料
運営費：任意の支援（Stripe Payment Links）

届いた通知メール

2026年2月13日、Stripeから以下のメールが届きました：

お客様のビジネス「Free Images」(Stripe アカウント ID: xxx) に関する追加情報をご提供いただきました。

審査が無事に完了しましたので、Stripe で決済処理を継続していただけます。

（数時間後）

誠に心苦しいのですが、貴社のビジネスについて再度確認させていただきました結果、カードネットワークパートナーの制限により貴社アカウントのサポート継続が困難となりました。

本決定は最終的なものであり、詳細情報の提供や再審査も叶いませんことをご理解賜りたく存じます。

一度は承認されたものの、数時間後に覆される。しかも「最終的な決定」「再審査不可」という強い表現。これは想定外の事態でした。

2：「カードネットワーク制限」という壁

Stripeレベルではなかった

最初は「Stripeに何か説明すれば解決するだろう」と考えていました。しかし、問題はもっと深刻でした。

決済の階層構造：

お客様
  ↓
Stripe（決済代行業者）
  ↓
Visa/Mastercard（カードネットワーク）← ★ここが拒否した
  ↓
カード発行会社
  ↓
銀行口座

Stripeではなく、その上のレイヤーであるVisa/Mastercardなどのカードネットワークが制限をかけていたのです。

なぜAI画像生成が拒否されたのか

推測される理由：

新しい技術への警戒
- AI画像生成は2022年頃から急速に普及した新しい分野
- カード会社のリスク評価基準が未整備
「画像サイト」への警戒
- 過去に成人向けコンテンツなどの問題サイトが多数存在
- 「画像」というキーワードだけで自動的に高リスクカテゴリに分類された可能性
著作権リスク
- AI生成コンテンツの著作権は法的にグレーゾーン
- 訴訟リスクを避けたいカード会社の判断
ビジネスモデルの不透明性
- 「無料配布 + 任意の支援」は対価が不明確
- マネーロンダリングリスクと判断された可能性

連鎖的な影響

さらに悪いことに、同じA銀行口座に紐付けていた別のアカウント「Indigo Works」も審査保留状態になりました。

影響範囲：

❌ Free Images（閉鎖）
⚠️ Indigo Works（審査中・一時停止）

3：代替手段の模索

試した方法：GitHub Sponsorsに直接申請

GitHub Sponsorsなら、「オープンソース開発者への支援」という明確な文脈があるので通るかもしれないと考えました。

「変えられない情報（名前、住所、生年月日）はそのままに、変えられる情報を変える」という戦略に切り替えました。

変更した要素：

✅ 銀行口座：A銀行 → B銀行
⚠️ 電話番号：変更なし
⚠️ メールアドレス：変更なし（indigo165e83@gmail.com）
⚠️ 名前、住所、生年月日：変更不可（虚偽申告になる）

成功

すべてのStripe Connectアカウントを削除してから24時間待ち、新しい銀行口座で再申請しました。

結果：成功！

GitHub Sponsorsのダッシュボードに緑色のメッセージが表示されました：

🎉 Your GitHub Sponsors profile was approved and is now public!

なんとか成功しました。

4：成功の要因分析

なぜ通ったのか？

仮説1：銀行口座が重要な照合要素

B銀行は過去の問題アカウントと紐付いていない「クリーンな」口座でした。Stripeのリスク評価において、銀行口座情報の重要度が想像以上に高かった可能性があります。

仮説2：GitHub経由の信頼性

通常のStripe申請とGitHub Sponsorsでは、審査フローが異なります：

通常のStripe：

個人/企業 → Stripe → カードネットワーク

GitHub Sponsors：

個人 → GitHub → Stripe Connect → カードネットワーク
       ★GitHubの信頼性が加味される

GitHubというプラットフォームの信頼性が、審査にプラスに働いた可能性があります。

仮説3：ビジネスモデルの違い

要素	Free Images（拒否）	GitHub Sponsors（承認）
プラットフォーム	独自サイト	GitHub
カテゴリ	「画像サイト」	「開発者支援」
ビジネスモデル	無料配布 + 支援	オープンソース支援
信頼性	不明	GitHubが保証

「AI画像サイト」より「オープンソース開発者への支援」の方が、カードネットワークにとって受け入れやすいビジネスモデルだったと推測されます。

5：GitHub Sponsorsの設定

プロフィール作成

承認後、以下の設定を行いました：

自己紹介文：

I’m creating and maintaining Free Images, a project that provides free AI-generated images for designers, developers, and creators worldwide.

Your support helps me cover server costs, create more free content, and develop new features.

支援ティア設定：

$1/月 - コーヒー1杯分の支援 ☕
$5/月 - コンテンツ作成の支援 🎨
$3 - 1回限りの支援 🙏

リポジトリへの統合

GitHub Sponsorsボタンをリポジトリに表示するため、.github/FUNDING.ymlファイルを作成：

github: indigo165e83

これだけで、リポジトリに「Sponsor」ボタンが自動的に表示されます。

詳細はGitHub Sponsors公式ドキュメントを参照してください。

サイトへのリンク追加

Free ImagesとIndigo Worksの両サイトに、GitHub Sponsorsへのリンクを追加しました。

実装例はこちらのリポジトリで公開しています。

学んだ教訓

1. 単一の決済手段に依存しない

今回の経験から、複数の決済手段を用意することの重要性を痛感しました。

推奨されるアーキテクチャ：

メイン：GitHub Sponsors
サブ：Ko-fi（PayPal専用モード）
バックアップ：PayPal直接、銀行振込

2. 新しい技術はリスク評価が厳しい

AI関連サービスは、カード会社の既存リスク評価基準に該当しません。そのため、より慎重に扱われる傾向があります。

対策：

利用規約で著作権侵害を禁止
コンテンツモデレーションを実装
特定商取引法に基づく表記を整備
プラットフォームの信頼性を借りる（GitHubなど）

3. 「ブラックリスト」ではなく「制限対象」

Stripeからの拒否は、「犯罪者」や「詐欺師」のようなブラックリストではありません。

正確には：

❌ ブラックリスト（永久的・全サービスで拒否）
✅ 制限対象（特定のビジネスモデルが基準に合わない）

時間と条件次第で、将来的にStripeを使える可能性もあります。

最終的なアーキテクチャ

現在のFree Imagesの支援受付体制：

メイン：GitHub Sponsors

プラットフォーム：GitHub
決済処理：Stripe Connect
銀行口座：B銀行
手数料：0%（GitHubが負担）

将来の拡張：

Ko-fi（PayPal専用モード）
PayPal直接寄付ボタン

プライバシーについて

GitHub Sponsorsで支援を受ける際、個人情報は保護されます。

支援者に見える情報：

✅ GitHubユーザー名（indigo165e83）
✅ プロフィール画像
✅ 自己紹介文

支援者に見えない情報：

❌ 本名
❌ 住所
❌ 電話番号
❌ 銀行口座
❌ メールアドレス（デフォルト設定）

詳細はGitHub Sponsorsのプライバシー設定を確認してください。

まとめ

重要なポイント

カードネットワーク制限はStripeレベルより深刻
- Visa/Mastercardが直接拒否している
- 再審査はほぼ不可能
AI関連サービスはリスク評価が厳しい
- 新しい技術への警戒
- 著作権の不透明性
- 既存カテゴリに該当しない
複数の決済手段を用意すべき
- 単一障害点を避ける
- フォールバック戦略が重要
GitHub Sponsorsは有力な選択肢
- オープンソース開発者への支援という明確な文脈
- GitHubの信頼性が審査にプラスに働く
- 手数料0%
諦めずに試行錯誤する価値がある
- 同じサービスでもアプローチを変えれば成功する可能性
- 銀行口座を変える、プラットフォームを変えるなど

現在の状況

GitHub Sponsorsで無事に支援を受け付けられるようになり、Free Imagesプロジェクトを継続できています。

GitHub Sponsorsプロフィール： https://github.com/sponsors/indigo165e83

プロジェクト：

Free Images - AI生成画像の無料配布
Indigo Works - ポートフォリオ、技術ブログなどのサイト

さいごに

この記事が、同じような問題に直面している方の助けになれば幸いです。

AI関連サービスを運営している方、決済手段の選択に悩んでいる方、突然アカウントを閉鎖された方。諦めずに、別のアプローチを試してみてください。

質問やフィードバックは、GitHub IssuesまたはGitHub Sponsors経由でお待ちしています。

関連リンク：

BigQueryでテーブルを結合する：JOIN構文の完全ガイド

Thu, 12 Feb 2026 00:00:00 GMT

BigQueryでデータ分析を行う際、複数のテーブルを結合して情報を統合することは日常的な作業です。今回は、JOIN構文の基本から実践的な使い分けまで、わかりやすく解説します。

BigQueryのテーブル参照の基本

まず、BigQueryでテーブルを参照する基本的な構文を確認しておきましょう。

SELECT カラム名
FROM プロジェクトID.データセット名.テーブル名

通常、テーブル名全体をバッククォート（`）で囲む必要はありません。カラム名やテーブル名に予約語や特殊文字が含まれる場合のみ、個別の要素をバッククォートで囲みます。

実践：2つのテーブルを結合する

以下のような2つのテーブルがあるとします。

-- テーブル1: publishers（出版社情報）
SELECT id, name, country
FROM my-project.analytics.publishers

-- テーブル2: contracts（契約情報）
SELECT id, fee_rate, publisher_id
FROM my-project.analytics.contracts

これらを publisher_id で結合して、「どの出版社がどの手数料率で契約しているか」を一覧化したいとします。

INNER JOIN：両方に存在するデータのみ取得

最も基本的な結合方法です。両方のテーブルに存在するレコードのみを取得します。

SELECT
  p.id AS publisher_id,
  p.name AS publisher_name,
  p.country,
  c.id AS contract_id,
  c.fee_rate
FROM
  my-project.analytics.publishers AS p
INNER JOIN
  my-project.analytics.contracts AS c
ON
  p.id = c.publisher_id
LIMIT 1000

構文の解説

要素	説明
`AS p`, `AS c`	テーブルにエイリアス（別名）を付けることで、クエリを読みやすくする
`INNER JOIN`	両方のテーブルに存在するレコードのみを取得
`ON p.id = c.publisher_id`	結合条件。publishers の id と contracts の publisher_id が一致するレコードを紐付ける

結果イメージ

publisher_id	publisher_name	country	contract_id	fee_rate
1	Publisher A	Japan	101	0.15
2	Publisher B	USA	102	0.20

この例では、契約情報（contracts）が存在する出版社のみが結果に含まれます。

結合方法の使い分け

データの要件に応じて、異なる結合方法を選択できます。

LEFT JOIN：左側のテーブルを全て保持

SELECT
  p.id AS publisher_id,
  p.name AS publisher_name,
  p.country,
  c.id AS contract_id,
  c.fee_rate
FROM
  my-project.analytics.publishers AS p
LEFT JOIN
  my-project.analytics.contracts AS c
ON
  p.id = c.publisher_id
LIMIT 1000

用途: 「全ての出版社と、契約がある場合はその情報も表示したい」場合に使用。契約がない出版社も結果に含まれ、contract_id と fee_rate は NULL になります。

結果イメージ

publisher_id	publisher_name	country	contract_id	fee_rate
1	Publisher A	Japan	101	0.15
2	Publisher B	USA	102	0.20
3	Publisher C	UK	NULL	NULL

RIGHT JOIN：右側のテーブルを全て保持

SELECT
  p.id AS publisher_id,
  p.name AS publisher_name,
  p.country,
  c.id AS contract_id,
  c.fee_rate
FROM
  my-project.analytics.publishers AS p
RIGHT JOIN
  my-project.analytics.contracts AS c
ON
  p.id = c.publisher_id
LIMIT 1000

用途: 「全ての契約と、対応する出版社情報を表示したい」場合に使用。出版社情報が見つからない契約も結果に含まれます（データ不整合の検出に便利）。

FULL OUTER JOIN：両方のテーブルを全て保持

SELECT
  p.id AS publisher_id,
  p.name AS publisher_name,
  p.country,
  c.id AS contract_id,
  c.fee_rate
FROM
  my-project.analytics.publishers AS p
FULL OUTER JOIN
  my-project.analytics.contracts AS c
ON
  p.id = c.publisher_id
LIMIT 1000

用途: 「出版社と契約の全データを取得し、対応関係がないものも確認したい」場合に使用。マスタデータとトランザクションデータの整合性チェックに有効です。

実務でのTips

1. エイリアスは必ず使う

テーブル名が長い場合、エイリアスを使わないとクエリが読みにくくなります。

-- ❌ 読みにくい
SELECT
  my-project.analytics.publishers.id,
  my-project.analytics.contracts.fee_rate
FROM my-project.analytics.publishers
INNER JOIN my-project.analytics.contracts
ON my-project.analytics.publishers.id = my-project.analytics.contracts.publisher_id

-- ✅ 読みやすい
SELECT p.id, c.fee_rate
FROM my-project.analytics.publishers AS p
INNER JOIN my-project.analytics.contracts AS c
ON p.id = c.publisher_id

2. 結合キーにインデックスがあるか確認

BigQueryでは、結合キーに使用するカラムが適切にパーティション分割されているか、クラスタ化されているかで、クエリのパフォーマンスが大きく変わります。

3. NULL値の扱いに注意

LEFT JOINやFULL OUTER JOINを使う場合、NULL値が発生します。集計関数（COUNT、SUMなど）を使う際は、NULL値の扱いに注意しましょう。

-- NULL を 0 として扱う例
SELECT
  p.name,
  IFNULL(c.fee_rate, 0) AS fee_rate
FROM my-project.analytics.publishers AS p
LEFT JOIN my-project.analytics.contracts AS c
ON p.id = c.publisher_id

まとめ

BigQueryでのテーブル結合において、以下の点を押さえておきましょう。

JOIN の種類を理解する: INNER、LEFT、RIGHT、FULL OUTER の違いと使い分け
エイリアスを活用する: クエリの可読性を高める
結合条件を明確にする: ON句で正確な結合キーを指定
NULL値の扱いに注意: 特にOUTER JOINを使う場合

結合タイプ	取得されるレコード	よくある用途
INNER JOIN	両方のテーブルに存在するレコードのみ	確実に紐付くデータのみ取得
LEFT JOIN	左側の全レコード + 右側の一致するレコード	マスタデータを全て表示
RIGHT JOIN	右側の全レコード + 左側の一致するレコード	トランザクションデータを全て表示
FULL OUTER JOIN	両方のテーブルの全レコード	データの整合性チェック

適切なJOINを選択することで、効率的で正確なデータ分析が可能になります。実務でのデータ要件に応じて、最適な結合方法を選びましょう。

Claude Codeで「UIがダサい」と伝えたら、驚くほどオシャレになった話

Thu, 12 Feb 2026 00:00:00 GMT

はじめに

バイブコーディング（Vibe Coding） という言葉をご存知でしょうか。これは、具体的な技術仕様ではなく「雰囲気」や「感覚」といった抽象的な指示でコードを生成・修正するAI開発の新しいスタイルです。

「AIに開発を任せる」ってどんな感じなのか興味があったのですが、Claude Codeを使って実際に体験したことは、想像を遥かに超えるものでした。

今回は、簡単なホワイトボードアプリのUIを改善してもらった体験を通じて、たった一言の「バイブ」でどこまでできるのかを検証してみました。

試したこと：バイブコーディングの実践

私がClaude Codeに伝えたのは、たったこれだけです。

「UIがダサいので、かっこよくしてください」

具体的なデザイン指示も、色の指定も、レイアウトの要望も何もありません。ただ「ダサい」から「かっこよく」してほしい、 それだけです。

これこそが、まさにバイブコーディングです。技術的な詳細ではなく、「こんな雰囲気にしたい」という感覚的な要求だけを伝える。従来の開発では考えられなかったアプローチです。

正直、こんな曖昧な指示で何かが変わるとは思っていませんでした。せいぜい色が少し変わる程度だろう、と。

Before：機能はあるけど…

修正前のホワイトボードアプリは、こんな感じでした。

修正前：シンプルだけど… あまりにもシンプルすぎる起動画面

修正前：グレー背景に黒ボタン。機能的だけど、確かに「ダサい」かも

機能としては問題ありません。描画もできるし、色も選べます。でも、デザインという観点では…確かに「ダサい」と言わざるを得ません。

背景はただのグレー
UIパーツは最小限
「Welcome my site」というテキストが寂しげ
全体的に無機質で冷たい印象

After：驚きの変貌

そして、Claude Codeが修正した結果がこちらです。

修正後：グラデーション背景にパープルのアクセントカラーが映える

修正後：ツールバーが洗練され、全体的にモダンな印象に

正直、驚きました。

背景が美しいグラデーションに
アイコンがモダンなデザインに刷新
パープル系の統一されたカラースキーム
適切な余白とバランス
「Draw freely」という洗練されたコピー
ボタンに矢印アイコンが追加され、UIとしての誘導性が向上

何が起きたのか：Claude Codeの思考プロセス

たった一言「かっこよくして」という指示から、Claude Codeは以下のような判断をしたと考えられます。

現状分析：既存のUIを解析し、改善点を特定
デザイントレンド理解：モダンなUIデザインの原則を適用
配色の選択：パープル系という現代的で親しみやすい色を選定
視覚的階層の構築：グラデーション、シャドウ、適切なコントラストで視認性向上
ユーザー体験の最適化：コピーの改善、アイコンの追加など細部にも配慮

これらすべてを、具体的な指示なしに自律的に実行したのです。

なぜこれが凄いのか

1. 抽象的な要求の理解

「ダサい」「かっこいい」という極めて主観的で曖昧な表現を、Claude Codeは適切に解釈しました。これは単なるキーワードマッチングではなく、デザインの良し悪しを理解している証拠です。

2. 総合的なUIセンス

色を変えるだけではなく、以下の要素を総合的に改善しています。

タイポグラフィ
レイアウト
配色
アイコンデザイン
ユーザーガイダンス（コピーライティング）

これは、デザインシステム全体を理解していないとできません。

3. コンテキストの把握

「ホワイトボードアプリ」というコンテキストを理解し、そのツールに適したデザインを提案しています。例えば、クリエイティブなツールにふさわしい柔らかさと親しみやすさを表現しています。

バイブコーディングが開く新しい開発体験

この体験を通じて感じたのは、AI開発ツールが「指示の実行者」から「デザインパートナー」へと進化しているということです。

バイブコーディングの革新性

従来の開発では、デザイナーが詳細なモックアップを作り、それを開発者が実装するという分業が一般的でした。しかしバイブコーディングでは、以下のような新しいワークフローが可能になります。

感覚的な要望を伝える：「ダサい」「かっこいい」「モダンに」など
AIが解釈・提案する：デザインの方向性を自律的に決定
即座に実装される：コードレベルでの実現まで一気通貫

この「曖昧さを許容する開発」は、特に以下のような場面で威力を発揮するでしょう。

プロトタイピング段階：アイデアを素早く形にしたい時
個人開発：デザインリソースが限られている時
UI改善の試行錯誤：複数のデザイン案を短時間で比較したい時
非デザイナーの開発者：デザインスキルがなくても良質なUIを実現したい時

開発の民主化

バイブコーディングは、開発における**「専門知識の壁」を下げる**重要な役割を果たします。CSSの詳細なプロパティを知らなくても、色彩理論を学んでいなくても、「こんな感じにしたい」という思いさえあれば、AIが形にしてくれるのです。

まとめ：バイブコーディングが示す開発の未来

「UIがダサいので、かっこよくしてください」

このたった一言から、予想を遥かに超える改善が実現しました。

Claude Codeとバイブコーディングは、開発における新しい可能性を示しています。それは単なる「効率化」ではなく、開発そのものの在り方を変えるイノベーションです。

技術仕様書ではなく「雰囲気」で開発できる
専門知識がなくても、思い描いたものを形にできる
AIは手伝うのではなく、共に創り上げるパートナーになる

もちろん、すべてのケースでこのように完璧な結果が得られるわけではないでしょう。しかし、少なくとも「AIには創造的な仕事は無理」という思い込みは、もう過去のものになりつつあるのかもしれません。

バイブコーディングは、まだ始まったばかりの新しい開発手法です。あなたも、ぜひ一度試してみてください。きっと、新しい開発体験が待っているはずです。

同時に、エンジニアの役割も変わっていくだろうとなと感じました。AIがコードを書き、デザインを提案する時代において、私たち人間は 「ビジョンを伝える力」 や 「AIと協働するスキル」 が求められるようになるでしょう。

使用したツール

Claude Code by Anthropic

プロジェクト

ホワイトボードアプリ（個人開発のシンプルなWebアプリ）

所要時間

指示から完成まで：数分

Next.js 16 アップデート：脆弱性 0 への道とビルドエラーの回避

Thu, 12 Feb 2026 00:00:00 GMT

Next.js の公式チュートリアルをベースにしたダッシュボードアプリにおいて、セキュリティ脆弱性の解消をきっかけに Next.js 16 へのアップデートを敢行しました。

最新の React 19 や Next.js 16 では、これまでの書き方が通用しない「破壊的変更」や、ビルド時の挙動の変化がいくつかあります。フリーランスエンジニアとして、実務でも遭遇しそうなこれらのトラブルをどう解決したか、その全記録を共有します。

1. 脆弱性 0 件へ：パッケージの強制アップデート

まず着手したのは、pnpm audit で指摘された 16 件の脆弱性対応です。

古いチュートリアルコードでは依存ライブラリが固定されていることが多く、単純な pnpm update では解消しきれない場合があります。今回は package.json の pnpm.overrides を活用し、安全なバージョンを強制的に指定することで、脆弱性を 0 件まで抑え込みました。

2. React 19 の洗礼：Server Actions の型定義

Next.js 16（React 19）に上げた直後、TypeScript のビルドエラーが発生しました。

発生したエラー

./app/ui/invoices/edit-form.tsx などの form action 属性において、以下の型不一致が起きました。

Type Promise<{ message: string; }> is not assignable to type void | Promise<void>.

原因と対策

React 19 から、form action に渡す関数は戻り値が void または Promise<void> であることが厳格に求められるようになりました。従来のコードでオブジェクト（メッセージなど）を返している場合、エラーになります。

これを解決するために、以下のようにラッパー関数で囲む修正を行いました。

// 修正前
<form action={updateInvoiceWithId}>

// 修正後（ラッパーで囲んで戻り値を無視させる）
<form action={async (formData) => { await updateInvoiceWithId(formData); }}>

3. ビルドの壁：Neon DB 接続エラーと PPR

一番苦労したのが、pnpm run build 時のデータベース接続エラーです。

症状

ビルド中に Neon DB へ接続しようとして HANGING_PROMISE_REJECTION が発生。WSL2（GALLERIA）のローカル環境から外部 DB への接続が、プリレンダリング工程でタイムアウトしてしまうのが原因でした。

解決策：force-dynamic の活用

Next.js 16 の cacheComponents (Partial Prerendering) を有効にしていると、ビルド時に DB を叩きに行こうとします。今回はビルドを確実に成功させるため、一旦 app/layout.tsx に以下の設定を投入しました。

export const dynamic = 'force-dynamic';

これにより、「ビルド時に静的にページを作る」のをやめ、「リクエスト時に動的に生成する」挙動に強制変更。ビルド時のネットワーク起因によるエラーを完全に回避できました。

※注意：cacheComponents が有効だと dynamic = 'force-dynamic' はエラーになるため、ビルドを優先する場合は next.config.mjs で一旦 PPR をオフにする調整も必要です。

まとめ

今回のアップデートを通じて、以下の 3 点が重要だと再認識しました。

脆弱性対応は定期的に: overrides を駆使してでも環境を清潔に保つ。
型定義の変化に敏感に: React 19 の form action などの仕様変更を把握する。
環境差分を考慮する: ローカル（WSL2）とデプロイ先（Vercel）でビルド時の挙動が異なる場合、force-dynamic などのフラグを戦略的に使う。

次は、Vercel 上で本来のパフォーマンスを発揮させるための「PPR 戻し」に挑戦する予定です。

個人開発アプリにStripeで寄付機能を導入する方法と注意点

Tue, 10 Feb 2026 00:00:00 GMT

現在開発中のフリー素材サイト「Free Images」に、「寄付（Donate）」機能を導入することにしました。

「決済機能なんて実装が大変そう…」と身構えていたのですが、Stripe を使えばコードをほとんど書かずに導入できることが判明。

しかし、いざ設定を始めると 「管理画面のどこで名前を変えるの？」「複数のアプリはどう管理する？」 といった、コード以外の部分で意外と躓きました。

今回は、初めてStripeを触るエンジニアに向けて、最短で安全に寄付機能をリリースするための手順と、私がハマった落とし穴をシェアします。

1. 実装手段：最初は「Payment Links」一択

Next.jsなどのフレームワークを使っていると、つい「APIを叩いて…」と考えがちですが、単発の寄付やシンプルな決済なら、Stripeが提供する 「Payment Links（支払いリンク）」 機能を使うのが最も手軽です。

なぜPayment Linksなのか？

実装工数がほぼゼロ: 管理画面でリンクを作るだけ。
セキュリティ: カード情報入力はStripeのドメイン上で行われるため、自サイトで機密情報を扱うリスクがない。
ノーコード: サイトのフッターなどに <a> タグでリンクを貼るだけで完了。

今回は、まずこの機能を使って「寄付ページ」のURLを発行しました。

2. 【最大の罠】名前が変わらない問題

意気揚々とリンクを作成し、プレビュー画面を見たときに違和感を覚えました。 「左上の店名が、変えたい名前に変わっていない…」

Stripeのダッシュボードには「名前」を設定する場所が複数あり、それぞれ役割が全く異なります。ここを混同すると、「自分には正しい名前が見えているのに、お客様には変な名前が表示される」という事故が起きます。

混乱しやすい2つの名前

項目名	役割	誰に見える？	設定場所の探し方
アカウント名	管理用ラベル	自分だけ	設定 > アカウントの詳細
公開ビジネス名称	正式名称	お客様	設定 > 公開情報

私は最初、「アカウント名」だけを一生懸命変更して「プレビューが変わらない！」と悩んでいました。 お客様に見える名前（決済ページや領収書メール）を変えたい場合は、「公開ビジネス名称」を変更する必要があります。

3. 複数サービス運用時の「アカウント」戦略

私は「Free Images」以外にも、「4Testing（ツール系）」や「Indigo Works（ポートフォリオ）」など、性質の異なる複数のサイトを持っています。

ふと、「これら全ての決済を1つのStripeアカウントで管理していいのか？」という疑問が湧きました。結論から言うと、サービスごとにStripeアカウント（プロファイル）を分けるのが鉄則です。

理由：クレジットカードの利用明細（重要！）

もし全サービスを「Indigo Works」という1つのアカウントでまとめてしまうと、お客様のカード明細には常に「INDIGO WORKS」と記載されます。

「画像サイト(Free Images)」で寄付した人 → 明細：INDIGO WORKS
ユーザーの心理: 「えっ、INDIGO WORKSって何？不正利用かも？」

これでは、覚えのない請求として**チャージバック（返金要求）**されるリスクが高まります。

解決策：アカウントの「新規作成」を活用する

Stripeは、1つのメールアドレス（ログインID）で、**複数のアカウント（プロファイル）**を簡単に作成・切り替えできます。追加料金もかかりません。

【おすすめの運用構成】

ダッシュボード左上の名前をクリック
「＋新規アカウント」を選択
サービス名（例：Free Images）を入力して作成

これだけで、**「Free Images専用の環境」**が手に入ります。あとは、それぞれの「公開ビジネス名称（明細書表記）」を正しく設定すれば完璧です。

アカウント名（管理用）	公開ビジネス名称（明細表記）	対象サービス
Free Images	FREE IMAGES	画像素材サイト
4Testing	4TESTING	テストツール

まとめ

Stripeの導入は技術的には簡単ですが、管理画面の設定には少しコツが必要です。

実装: まずは「Payment Links」で小さく始める。
設定: お客様に見せたい名前は「公開情報」で設定する。
運用: サービスごとに「新規アカウント」を作成し、明細表記を分ける。

これで、ユーザーにとっても怪しくない、クリーンな寄付・決済環境が整いました。個人開発アプリの収益化を考えている方は、ぜひ「アカウントの分け方」から設計してみてください。

JSTQB Foundation Level シラバスの概要とマインドマップ化

Sun, 08 Feb 2026 00:00:00 GMT

最近、初心に帰って、JSTQB Foundation Level の資格を取得しようと思っています。

とりあえず、シラバス（V4.0）を読み込んで、マインドマップ化しました。

JSTQB Foundation Level (Syllabus V4.0)： https://jstqb.jp/syllabus.html#syllabus_corefoundation

JSTQB Foundation Level (Syllabus V4.0) 概要

1. テストの基礎

テストとは何か？
- 典型的なテスト目的
- テストとデバッグの違い
なぜテストが必要か？
- 品質保証 (QA) と品質管理 (QC)
- エラー・欠陥・故障・根本原因
テストの7原則
テストプロセスと役割
- テスト活動とタスク
- テストウェア
- トレーサビリティ
必要不可欠なスキルとよい実践例
- チーム全体アプローチ
- テストの独立性

2. SDLC全体を通してのテスト

開発モデルの影響
- DevOpsとテスト
- シフトレフトアプローチ
テストレベル
- コンポーネントテスト
- 統合テスト (コンポーネント統合 / システム統合)
- システムテスト
- 受け入れテスト
テストタイプ
- 機能テスト
- 非機能テスト
- ホワイトボックステスト
メンテナンステスト
- 確認テストとリグレッションテスト

3. 静的テスト

静的テストの基本
- 静的テストと動的テストの違い
レビュープロセス
- レビュー種別 (非形式的 / ウォークスルー / テクニカルレビュー / インスペクション)
- レビューの成功要因

4. テスト分析と設計

ブラックボックステスト技法
- 同値分割法
- 境界値分析 (2値 / 3値)
- デシジョンテーブルテスト
- 状態遷移テスト
ホワイトボックステスト技法
- ステートメントテスト
- ブランチテスト
経験ベースのテスト技法
- エラー推測
- 探索的テスト
- チェックリストベースドテスト
コラボレーションベースのアプローチ
- ATDD (受け入れテスト駆動開発)
- ユーザーストーリーと受け入れ基準

5. テストマネジメント

計画と見積り
- 開始基準と終了基準
- 見積り技法 (3点見積り / プランニングポーカー等)
- テストピラミッド
- テストの四象限
リスクマネジメント
- プロジェクトリスクとプロダクトリスク
- リスク分析とコントロール
モニタリングとコントロール
構成管理と欠陥マネジメント

6. テストツール

ツールの分類と支援
テスト自動化の利点とリスク

マインドマップ

mindmap
  root((JSTQB FL<br/>Syllabus V4.0))
    1. テストの基礎
      テストとは何か
        テストとデバッグの違い
      なぜテストが必要か
        QAとQC
        エラー・欠陥・故障
      テストの7原則
      プロセスと役割
        テストウェア
        トレーサビリティ
      スキルと独立性
        チーム全体アプローチ
    2. SDLCにおけるテスト
      開発モデルの影響
        DevOps
        シフトレフト
      テストレベル
        コンポーネントテスト
        統合テスト
        システムテスト
        受け入れテスト
      テストタイプ
        機能 / 非機能
        ホワイトボックス
      メンテナンステスト
        確認 / リグレッション
    3. 静的テスト
      静的テストの基本
        動的テストとの違い
      レビュープロセス
        レビュー種別
        成功要因
    4. テスト分析と設計
      ブラックボックス技法
        同値分割法
        境界値分析
        デシジョンテーブル
        状態遷移テスト
      ホワイトボックス技法
        ステートメント
        ブランチ
      経験ベース技法
        エラー推測
        探索的テスト
      コラボレーション
        ATDD
        ユーザーストーリー
    5. テストマネジメント
      計画と見積り
        開始・終了基準
        テストピラミッド
        テストの四象限
      リスクマネジメント
        プロジェクトリスク
        プロダクトリスク
      モニタリングとコントロール
      構成管理・欠陥管理
    6. テストツール
      ツールの分類
      自動化の利益とリスク

Next.js認証の深堀り：JWTという『透明な証明書』をどう扱うか？

Sat, 07 Feb 2026 00:00:00 GMT

Next.js（App Router）での認証実装。ライブラリが優秀すぎて「なぜか動く」状態になりがちですが、一歩踏み込んで JWT（JSON Web Token ジョット） の仕組みを理解すると、デバッグの質が劇的に変わります。

今回は、Auth.js（NextAuth）を例に、JWTの正体と現場で使えるTipsをまとめました。

認証は「パスポート」と「搭乗券」のリレー

Webサイトの認証フローは、空港のプロセスに例えると非常にクリアになります。

ログイン（認証）: ID/PWを提示して本人確認をする（パスポート提示）。
トークン発行: サーバーが「この人は本人です」という証明書を発行する（搭乗券の発行）。
アクセス（認可）: 以降、ブラウザがその証明書を自動で提示する。

この「搭乗券」の役割を果たすのが JWT です。

JWT（JSON Web Token）とは？

現在、Next.jsなどのモダンな開発で最も使われているトークンの形式が JWT です。

最大の特徴は、 「サーバーがいちいちデータベースを見に行かなくても、その中身を見ただけで正当性がわかる」 という点にあります。

JWTを分解すると、ドット（.）で区切られた3つのパーツでできています。

パーツ名	例え	内容
ヘッダー	封筒の種類	「これはJWTです」「暗号化の種類はこれです」という情報。
ペイロード	証明書の本文	「ユーザーID：123」「有効期限：2026/02/07」などの実データ。
署名 (Signature)	偽造防止のハンコ	サーバーだけが知る「秘密の鍵」で押された電子印鑑。

追記： JSON Web Token（JWT）デバッガーで実際のJWTを貼り付けると、各パーツの中身を簡単に確認できます。

JWTは「透明なガラスケース」

JWTについて最も誤解されやすいのは、 「中身は暗号化されていない」 という点です。

JWTはドット（.）で区切られた3つのパートで構成されていますが、本文（ペイロード）は単にBase64で変換されているだけ。誰でも中身を読めてしまいます。

❌ NG例：機密情報を入れてしまう

{
  "userId": "123",
  "password": "hashed_password_abc", // 絶対にダメ！
  "address": "東京都..." // 個人情報も避けるべき
}

✅ OK例：識別子と期限に留める

{
  "sub": "user_8k92jL0s", // ユーザーID
  "role": "ADMIN",       // 権限
  "exp": 1709859015      // 有効期限
}

「中身は見えてもいいが、署名（ハンコ）があるから書き換えはできない」。これがJWTの鉄則です。

現場で使える「デバッグとテスト」の実践

1. ターミナルでJWTを覗き見る

Auth.jsのデフォルトではCookieが暗号化されているため、ブラウザのデベロッパーツールから直接中身を読むのは困難です。

そんな時は auth.ts の jwt コールバックにログを仕込むのが最速です。

auth.ts

callbacks: {
  async jwt({ token, user }) {
    if (user) {
      token.role = user.role;
    }
    console.log("DEBUG [JWT]:", token); // サーバー側のログで規約通りの sub や exp を確認
    return token;
  },
}

2. 安全なテストログインの実装

開発中、いちいちGoogleログインをするのは手間ですよね。かといってコードにパスワードを直書きするのは論外です。

以下のように環境変数と NODE_ENV を組み合わせるのが「エンジニアの作法」です。

Credentials({
  authorize: async (credentials) => {
    if (process.env.NODE_ENV === "production") return null; // 本番では絶対動作させない

    if (
      credentials.email === process.env.TEST_ADMIN_EMAIL &&
      credentials.password === process.env.TEST_ADMIN_PASSWORD
    ) {
      return { id: "test-id", role: "ADMIN" };
    }
    return null;
  },
})

補足：規約を知る

JWTには RFC 7519 という国際規格があります。

特に、JWTの中身（ペイロード）に入れる項目には、規約で決められた 「予約済みクレーム（Reserved Claims）」 という特別な名前があります。

規約では、項目の名前を3文字に省略することが推奨されています。これは、データ量を少しでも小さくして通信速度を上げるためです。

よく使われる予約済みクレーム

項目名	正称	意味
`iss`	Issuer	発行者（誰がこのトークンを作ったか。例：Googleなど）
`sub`	Subject	一意識別子（誰のためのトークンか。通常はユーザーID）
`aud`	Audience	対象者（誰がこのトークンを使う予定か。例：自分のアプリのURL）
`exp`	Expiration Time	有効期限（これ以降は無効。UNIXタイムスタンプで記述）
`iat`	Issued At	発行時刻（いつ作られたか）
`jti`	JWT ID	トークン独自のID（再利用攻撃を防ぐためのシリアル番号）

なぜユーザーIDが id ではなく sub なのか、なぜ期限が exp なのか。これらの「3文字の規約」を知っておくと、Auth.jsから別のライブラリ（Better Authなど）へ移行した際や、Supabase等のBaaSを使う際も、共通の知識として活用できます。

「なんとなく動く認証」から「仕組みを理解した堅牢な認証」へ。皆さんのNext.js開発の一助になれば幸いです。

Playwright × NextAuth v5：ログインのテストを自動化する方法

Fri, 06 Feb 2026 00:00:00 GMT

Next.js + NextAuth (v5) で構築された、AI画像ストックサイト「free-images」というサービスに E2E テスト（Playwright）を導入しました。

初期段階では「Googleログインしかないから、テストが難しいな」くらいに考えていたのですが、実際は認証基盤のアーキテクチャ変更にまで発展する大工事となりました。

この記事では、直面したエラーとその解決策、そして最終的に完成した「テスト用裏口実装」のコードを共有します。

直面した2つの壁

1. Google認証の壁

Playwright で Google ログイン画面を操作しようとすると、Bot検知や二要素認証（2FA）に阻まれます。 CI/CD で安定して回すためには、外部プロバイダ（Google）に依存しないログイン方法が必要でした。

2. NextAuth の「DBセッション」の制約

「じゃあ、テスト用にメール/パスワード認証（Credentials）を追加しよう」と考えましたが、NextAuth には以下の制約がありました。

“Credentials 認証を使うなら、DBセッション（Adapter）は使えない。JWT を使いなさい。”

これにより、既存のデータベースセッション方式を捨て、JWT（JSON Web Token）方式へ移行する決断を迫られました。

解決策：テスト用「裏口」の実装

最終的に実装した auth.ts がこちらです。ポイントは、本番環境以外（開発・テスト）でのみ有効になる Credentials プロバイダー を追加したことです。

// auth.ts (完成版)
import NextAuth from "next-auth"
import Google from "next-auth/providers/google"
import Credentials from "next-auth/providers/credentials"
import { PrismaAdapter } from "@auth/prisma-adapter"
import { prisma } from "@/lib/prisma"

export const { handlers, auth, signIn, signOut } = NextAuth({
  adapter: PrismaAdapter(prisma),

  // Credentialsを使うために必須の設定
  session: { strategy: "jwt" },

  providers: [
    Google({
      clientId: process.env.AUTH_GOOGLE_ID,
      clientSecret: process.env.AUTH_GOOGLE_SECRET,
    }),

    // ▼ テスト用裏口プロバイダー
    Credentials({
      id: "test-login",
      name: "Test Login",
      credentials: {
        email: { label: "Email", type: "email" },
        password: { label: "Password", type: "password" },
      },
      authorize: async (credentials) => {
        // 【重要】本番環境(production)でのみ無効化する
        // ※ ここを "if (NODE_ENV !== 'test')" にすると、
        // npm run dev (development) で動かした時にログインできずハマります！
        if (process.env.NODE_ENV === "production") {
          return null;
        }

        // 特定のアカウントのみ管理者として許可
        if (
          credentials.email === "admin@example.com" &&
          credentials.password === "test-password"
        ) {
          return {
            id: "test-admin-id",
            role: "ADMIN", // ここで権限付与
            email: "admin@example.com",
          }
        }
        return null;
      },
    }),
  ],
  // ... callbacks省略
})

ハマりポイント：NODE_ENV の落とし穴

実装中に一番時間を溶かしたのが、環境変数の扱いです。

当初、ガード条件を以下のように書いていました。

// ❌ 失敗したコード
if (process.env.NODE_ENV !== "test") {
  return null;
}

Playwright は NODE_ENV=test で実行されるのでこれで良さそうに見えます。しかし、Next.js のサーバー自体は pnpm dev で起動しており、この時の環境変数は development です。

結果、テストランナー(test)はログインしようとするが、サーバー(development)がそれを拒否する という状況になり、永遠に Sign in failed エラーが出続けました。

教訓

ガード条件は 「テスト環境のみ許可」 ではなく、 「本番環境のみ拒否 (process.env.NODE_ENV === "production")」 とするのが安全かつ確実です。

まとめ

今回の対応で、以下の成果が得られました。

1.Google依存の排除: 外部要因でテストが落ちることがなくなった。

2.高速化: ログイン処理が一瞬で終わるようになった。

3.JWTへの移行: DBアクセスが減り、本番のパフォーマンスも向上した（副次的効果）。

「テストのために本番コードを弄るのは負け」という考え方もありますが、「テスト容易性（Testability）の高いアーキテクチャを選ぶ」ことも、必要だと実感しました。

Vercel × Route53 × Astro で「wwwあり」を正解にする理由

Fri, 06 Feb 2026 00:00:00 GMT

「ドメインは短い方がクールだ」

そう思って、個人開発のサイトではこれまで https://example.com のような「wwwなし（ネイキッドドメイン）」を好んで使っていました。しかし、このブログ（Astro Starlight + Vercel）を構築し、Google AdSenseやSearch Consoleの設定を進める中で、その認識を改めることになりました。

今回は、Vercel環境においてなぜ「wwwあり」が推奨されるのか、そしてAstroの設定でハマりやすいサイトマップの罠について共有します。

Vercelからの「提案」

AWS Route53 で取得したドメインを Vercel に接続したときのことです。 Vercelのダッシュボードには、親切にも次のような推奨設定が表示されていました。

www.indigo165e83.com -> Primary
indigo165e83.com -> Redirect to www...

「え、逆じゃない？短い方をメインにしたいんだけど」と最初は思いました。しかし、Vercelの公式ドキュメントやアーキテクチャを調べていくと、これには明確な技術的理由があることがわかったのです。

Anycast IP と CNAME の違い

結論から言うと、Vercel（というか多くのCDN）においては、サブドメイン（www）の方がパフォーマンスと耐障害性に優れています。

wwwあり（CNAMEレコード）

www を使う場合、DNSレコードは CNAME で設定し、値は cname.vercel-dns.com になります。これにより、Vercel側がトラフィックを動的に制御し、ユーザーから最も近いエッジサーバーへ最適にルーティングしてくれます。

wwwなし（Aレコード）

一方、ネイキッドドメインを使う場合、DNSの仕様上 CNAME が使えない（ことが多い）ため、Aレコード で固定IPを指定する必要があります。 Vercelの場合、ここで指定するのが 76.76.21.21 という Anycast IP です。

これも十分に高速なのですが、固定IPである以上、CNAMEを用いた柔軟なトラフィック制御に比べると、Vercelの持てるポテンシャルを100%引き出しにくいという側面があります。

「見た目のシンプルさ」を取るか、「インフラ的な最適解」を取るかのトレードオフですが、私は後者（wwwあり）を選びました。

Astro設定ファイルの落とし穴

DNSの設定（AWS Route53）とVercelのリダイレクト設定を完了し、「これで完璧だ」と思っていました。しかし、Google Search Console にサイトマップを送信したところ、**「インデックス登録されない」「AdSenseの審査が進まない」**という問題が発生しました。

原因は、私のローカルのコード、astro.config.mjs にありました。

// 修正前の astro.config.mjs（NG）
export default defineConfig({
  site: 'https://indigo165e83.com', // wwwがない！
  // ...
});

Webサーバー（Vercel）側では「wwwありが正義（Primary）」として動いているのに、Astroが自動生成する sitemap-index.xml の中身は、設定ファイルに従って https://indigo165e83.com/… （wwwなし）のURLをリストアップしていたのです。

Googleロボットがサイトマップを見る（wwwなしのURLが書いてある）そのURLにアクセスするVercelが「wwwあり」にリダイレクトするGoogleロボット「おっと、リダイレクトされた。正規URLがどっちかわからないぞ」これが評価を下げる要因になっていました。

正しい設定のまとめ

この問題を解決するために行った設定は以下の3点です。これでサイトマップ、実アクセス、DNSの全てが「wwwあり」で一本化されました。

AWS Route 53 の設定ルートドメインへのアクセスも取りこぼさないよう、Aレコードも正しく設定します。レコード名タイプ値備考wwwCNAMEcname.vercel-dns.comメインの経路(空欄)A76.76.21.21Anycast IP (リダイレクト用)
Vercel の設定Domains設定画面で www.indigo165e83.com を Primary に設定。
Astro の設定（忘れがち！）astro.config.mjs の site プロパティを、実際に運用するURLと完全に一致させます。

// 修正後の astro.config.mjs（OK）
export default defineConfig({
  site: 'https://www.indigo165e83.com', // wwwをつける
  integrations: [sitemap(), ...],
});

まとめ

「たかがwww、されどwww」。

モダンなホスティング環境では、DNSの設定ひとつでパフォーマンスが変わりますし、SSGフレームワーク（Astro）側との整合性もSEOに直結します。

もしVercel × Astroで構築していて「インデックス登録が遅いな？」と感じたら、一度 astro.config.mjs と DNS設定の整合性を確認してみることをおすすめします。

認証の基礎知識：Cookie、セッション、JWTなど

Thu, 05 Feb 2026 00:00:00 GMT

Webアプリケーションを開発する上で、避けて通れないのが**「認証 (Authentication)」**です。

特に Next.js + NextAuth (Auth.js) のようなモダンな構成を採用する場合、裏側で何が起きているのかを理解していないと、「ログインできない」「テストが通らない」「意図しないログアウトが起きる」といったトラブルに対処できません。

この記事では、認証周りの重要キーワードを、イメージしやすいように整理しました。

1. 認証と認可の基本コンポーネント

まずは、認証情報の「入れ物」と「中身」についてです。

役割：ブラウザ側の「保存容器」

サーバーから送られてくる小さなテキストデータです。ブラウザの中に保存されます。認証においては、ログイン後にサーバーから発行された「会員証（セッションIDやトークン）」を保存しておく場所として使われます。

HttpOnly属性: JavaScriptからのアクセスを禁止する（XSS対策）。
Secure属性: HTTPS通信時のみ送信する（盗聴対策）。

Session (セッション)

役割：サーバー側の「滞在状態」

「このユーザーは現在ログイン中である」という状態そのものを指します。 Webサーバー（HTTP）は本来ステートレス（記憶喪失）なため、リクエストごとに「これはさっきのユーザーだ」と識別する仕組みが必要です。これを実現するのがセッションです。

2. セッション管理の2つの方式

NextAuthなどのライブラリを使う際、最も重要なアーキテクチャの選択がここにあります。

データベースセッション (Adapter利用)

＝サーバーサイドセッション

仕組み: セッションIDだけをCookie（ユーザー）に渡し、実データ（誰が、いつまで有効か）はデータベースの Session テーブルに保存します。
メリット: サーバー側から特定のユーザーを強制ログアウト（DBレコード削除）させることができます。セキュリティが高いです。
デメリット: ページ遷移のたびにDBアクセスが発生するため、パフォーマンスに影響が出る場合があります。

JWT (JSON Web Token)

＝クライアントサイドセッション

仕組み: ユーザー情報（ID、権限、有効期限など）をJSON形式で記述し、改ざん防止の署名を付けて暗号化した文字列（トークン）をCookieに保存します。
メリット: サーバー（DB）を見に行かなくても、トークンの中身だけで認証検証ができるため高速です。スケーラビリティに優れます。
デメリット: 一度発行したトークンは有効期限まで使い続けられるため、サーバー側からの即時無効化（強制ログアウト）が困難です。

3. 認証の入り口（プロバイダー）

ユーザーがどうやって本人確認を行うかの方式です。

Credentials 認証

＝メールアドレス / パスワード認証

昔ながらの ID/Password を入力する方式です。アプリ開発者が独自に認証ロジック（DBと照合するなど）を実装する必要があります。

自動テスト（Playwright等）での利用: Google等の外部認証はBot検知が厳しいため、E2Eテストのためだけにこの「Credentials認証」を裏口として実装し、テスト環境でのみ有効化する手法がよく取られます。

外部IDプロバイダ認証 (OIDC / OAuth 2.0)

＝ソーシャルログイン (Google, GitHubなど)

「認証（本人確認）」をGoogleなどの信頼できる第三者に任せる方式です。アプリ側はパスワードを管理しません。

OAuth 2.0: 「認可（データへのアクセス権）」のための仕様。
OIDC (OpenID Connect): OAuth 2.0を拡張して「認証（ID確認）」を行えるようにした仕様。

ユーザーは「Googleのパスポート」を見せて入国するイメージです。セキュリティリスクを外部にオフロードできるため、現代の主流となっています。

4. NextAuth内部のデータフロー

実装時によく混乱するキーワードです。

Token (トークン)

役割：データの運び屋

JWT方式において、暗号化されたデータの塊そのものです。ログイン時にDBから取得した情報（User IDやRole）は、一度この「トークン」の中に書き込まれます。

Callbacks (コールバック)

役割：データ加工のフックポイント

NextAuthが認証処理を行う途中で、開発者がデータを操作できる関数です。

jwt コールバック: ログイン成功直後や、トークン更新時に呼ばれます。「DBから取得した role 情報を、JWTトークンの中に書き込む」といった処理はここに書きます。
session コールバック: フロントエンドで useSession() 等を使った時に呼ばれます。「JWTトークンの中から role 情報を取り出して、ブラウザで使えるようにする」処理を書きます。

// NextAuthの設定例（イメージ）
callbacks: {
  // 1. DBの情報をトークン(荷台)に載せる
  async jwt({ token, user }) {
    if (user) token.role = user.role;
    return token;
  },
  // 2. トークン(荷台)から取り出してアプリで使う
  async session({ session, token }) {
    session.user.role = token.role;
    return session;
  }
}

まとめ

認証基盤を選定・実装する際は、以下のトレードオフを理解しておくことが重要です。

特徴	データベースセッション	JWT (JSON Web Token)
状態の場所	サーバー (DB)	クライアント (Cookie)
パフォーマンス	DBアクセスが必要	高速 (計算のみ)
強制ログアウト	容易 (レコード削除)	困難 (期限切れ待ち)
Credentials利用	原則不可 (NextAuth)	必須

Playwright トラブルシューティング - Firefoxだけが動かない

Wed, 04 Feb 2026 00:00:00 GMT

現在開発中のAI画像ストックサイト『free-images』に、品質担保のためE2Eテストツールである Playwright を導入することにしました。

「モダンなツールだし、サクッと導入できるだろう」と高を括っていたのですが、Firefox環境でのみテストが落ちる という泥沼にハマりました。今回はそのトラブルシューティングの記録を残しておきます。WSL環境で開発している方の参考になれば幸いです。

最初のつまずき：謎の Syntax Error

まずは公式ドキュメント通りにテストコード (tests/home.spec.ts) を書き、実行してみました。

import { test, expect } from '@playwright/test';

test.describe('トップページ（ゲスト表示）のテスト', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('/ja');
  });
  // ...各テストケース
});

しかし、実行すると即座にエラー。

Error: Playwright Test did not expect test.describe() to be called here.

構文は合っているはずなのに、「ここで describe を呼ぶな」と怒られます。

よくよくエラーログを見ると、「You have two different versions of @playwright/test」という不穏なメッセージが。

原因：npmとpnpmの混ぜるな危険

pnpm-lock.yaml があるのに、手癖で npm install などを実行してしまったため、package-lock.json も生成されていたのです。

これにより、node_modules 内でバージョンの競合が起き、Playwrightが正しく動作していませんでした。

解決策：

環境をクリーンにして、パッケージマネージャーを pnpm に統一しました。

rm package-lock.json  # 不要なロックファイルを削除
rm -rf node_modules   # 既存のモジュールを全削除
pnpm store prune      # ストアの整合性を確認
pnpm install          # 再インストール

これで構文エラーは解消。Chrome (Chromium) でのテストはパスするようになりました。「よし、これで完了！」と思った矢先、本当の敵が現れます。

Firefoxだけが起動しない

クロスブラウザテストのため、Firefoxを含めて実行すると…

npx playwright test tests/home.spec.ts --project=firefox --headed

Chromeは通るのに、Firefoxだけが全滅です。

エラー内容

Error: browserType.launch: ENOENT: no such file or directory, stat '/home/indigo/.cache/ms-playwright/firefox-1495/firefox/lock'

ENOENT (Error NO ENTry)、つまり「ファイルがない」と言っています。パスを見ると ~/.cache/ms-playwright/… という、Playwrightがブラウザのバイナリを管理しているディレクトリを指していました。

なぜ消えた？ node_modules を再インストールした際、テストランナー自体は入りましたが、ブラウザ本体（Firefoxバイナリ）のリンクや実体がおかしくなっていたようです。また、WSL (Ubuntu) 環境特有のライブラリ不足も疑われました。

解決策：キャッシュの完全削除と再インストール

中途半端に修復しようとせず、Playwrightのブラウザキャッシュを一度「無」にしてから入れ直すのが最短ルートでした。

キャッシュフォルダを爆破する壊れている可能性のある既存のブラウザデータを手動で削除します。

rm -rf ~/.cache/ms-playwright

ブラウザと依存関係の再インストールただ install するだけでなく、install-deps も実行するのがポイントです。特にWSL環境では、Firefoxを動かすためのシステムライブラリ（GTKやdbus関連など）が不足していることがよくあります。

# ブラウザバイナリのダウンロード
npx playwright install

# システム依存ライブラリのインストール（sudo権限が必要になる場合あり）
npx playwright install-deps

これを実行すると、Ubuntu側で必要なパッケージ（libgtk-3-0 や libdbus-glib-1-2 など）も自動でチェックしてインストールしてくれます。

テスト成功再度Firefoxでテストを実行。

npx playwright test tests/home.spec.ts --project=firefox

無事、キツネのアイコンとともにブラウザが立ち上がり、テストがオールグリーンになりました！

まとめ

今回の教訓は以下の3点です。

ロックファイルは一つに絞る: npm と pnpm を混在させると、特にバイナリを扱うライブラリ（PlaywrightやPrismaなど）で整合性が壊れやすい。
Playwrightのブラウザは node_modules 外にある: npm install し直しただけではブラウザ本体は直らない。~/.cache/ms-playwright を疑うべし。
WSLユーザーは install-deps を忘れずに: Linux環境ではブラウザを動かすためのOSレベルの依存関係が必須。

E2Eテストは環境構築でハマりがちですが、一度整えば「寝ている間にバグを見つけてくれる」頼もしい相棒になります。めげずに整備していきましょう。

生成画像プロンプトを洗練

Tue, 03 Feb 2026 00:00:00 GMT

「赤い布の画像を作って」 AIにそう頼めば、確かに赤い布の画像は出てきます。しかし、それは果たしてストックフォトサイトで「売れる素材」と言えるでしょうか？

現在開発中の画像ストックサイト『free-images』では、単なる自動生成を超え、デザイナーが「これこそ探していた質感だ」と唸るクオリティを目指しています。今回は、Google Gemini APIを駆使したプロンプト改善の旅についてお話しします。

「名もなき色」に命を吹き込む

ストックフォトの世界では、「赤」や「青」といった単純な色名だけでは不十分です。例えば、Webデザインの背景として求められるのは、その色が持つ「空気感」や「深み」です。

そこで、Geminiに与える色指定を40種類以上の詳細なフレーズへとアップデートしました。

改善のビフォー・アフター

Before: Vivid Crimson Red
After: Vivid Crimson Red – with intense saturation and a smooth, velvety light falloff （鮮烈なクリムゾンレッド－強い彩度と、滑らかでベルベットのような光の減衰）

この「ベルベットのような光の減衰」という一言があるだけで、AIは布の表面で光がどのように散らばり、影がどう落ちるかを計算し始めます。ただの赤い平面が、触れられそうなほどの 質感（テクスチャ） へと昇華されます。

ニッチを攻める：メタリックの魔力

サイトの差別化として注力したのが、ゴールド、シルバー、ブロンズといったメタリック素材です。金属の質感は、ライティングの指示一つで「安っぽいCG」にも「重厚な写真」にもなります。

今回、プロンプトに組み込んだのは以下のような「物理現象」への言及です。

Hammered Raw Silver: 多方向からの光を捉える「打ち出し加工」の凹凸。
Molten Liquid Bronze: 深い琥珀色の反射を伴う、流動的で粘り気のある表面。

これらに Specular highlights（鏡面反射） や Micro-crystalline detail（微結晶のディテール） といった専門的なキーワードを掛け合わせることで、PCの計算リソースをフルに活かした、圧倒的なリアリティを実現しました。

デザイナーの視点をAIに教え込む

プロンプトの改善は、AIを「画材」から「熟練のフォトグラファー」へ育てる作業に似ています。

単に綺麗なものを作らせるのではなく、「Minimalist composition（ミニマルな構図）」や「Top-down flat lay（真上からの俯瞰）」といった、商用利用で需要の高いアングルをランダムに選択させるロジックを組み込みました。

これにより、寝ている間に実行される「仮想カメラマン」たちは、常にストックフォトとして使い勝手の良い画像を量産してくれるようになったのです。

終わりに：言葉が画像を作る

今回の改善を通じて感じたのは、「AI画像生成の限界は、人間の想像力と語彙力の限界である」ということです。

プロンプトエンジニアリングは、単なる技術的な作業ではなく、言葉の力で視覚的なリアリティを創り出すクリエイティブな挑戦です。

povo2.0で構築する安価なSMS認証基盤

Mon, 02 Feb 2026 00:00:00 GMT

開発やサービス検証を行っていると、「商用環境とテスト環境でアカウントを分けたい」「検証用にクリーンな電話番号がもう一つ欲しい」という場面に多々遭遇します。

しかし、そのためだけに月額数千円のキャリア契約を追加するのはコストが見合いません。今回は、Androidスマホとpovo2.0を組み合わせ、年間数百円で「死なない認証用番号」を維持する方法をまとめました。

1. なぜ「物理的な電話番号」が必要なのか

最近のWebサービス（Amazon、Google、SNS各社）は、Bot対策として050番号（IP電話）によるSMS認証をブロックする傾向が強まっています。

IP電話の限界: 多くの主要サービスで「この番号は登録できません」と弾かれる。
アカウントの独立性: メインの番号を使い回すと、テストアカウントで問題が起きた際にメインアカウントまで芋づる式に制限を受けるリスクがある。

確実な検証環境を構築するには、070/080/090から始まる「本物の回線」が不可欠です。

2. 最適解としての「povo2.0 × eSIM」

エンジニアにとって、povo2.0は「予備回線」としてこれ以上ないスペックを持っています。

基本料0円: 使わない月は維持費が発生しません。
eSIMによる即時発行: 物理カードの到着を待たず、数時間で検証を開始できます。
Androidとの相性: 物理SIM（メイン）とeSIM（povo）を同時に有効化し、1台の端末で2つのSMSをリアルタイムに待ち受け可能です。

3. 実践：テストアカウント運用のためのTips

招待・連携のエラーを回避する

複数のアカウントを1つのブラウザで管理すると、セッションやキャッシュが干渉し、認証エラーや招待リンクの無効化を招きます。

対策: 必ずシークレットウィンドウを使用するか、ブラウザの「プロファイル」を完全に分けて運用することを推奨します。

番号を「年間440円」で延命するスキーム

povo2.0は180日間トッピング未購入だと利用停止になりますが、以下の運用でコストを最小化できます。

smash.使い放題パック（220円/24時間） を半年に1回購入。
もしくは、外出先でデバッグ作業が必要な日に データ使い放題（330円/24時間） を購入。

これにより、月額換算約37円という圧倒的低コストで、いつでもSMS認証が可能な状態をキープできます。

4. まとめ

「とりあえず番号が必要」という時のために、eSIMスロットを一つpovoに割り当てておくのは、非常に有効な手段です。

環境分離: プライベートとテスト環境の完全な隔離。
リスクヘッジ: メイン番号のクリーンな状態を維持。

30秒周期で画面が収縮する謎の挙動を追う。

Sun, 01 Feb 2026 00:00:00 GMT

作業中に突然発生し始めた「約30秒周期で画面が一瞬収縮する」という謎の挙動。作業に集中できないだけでなく、ハードの故障も疑われるこの問題に対し、イベントログの解析から物理的な環境要因の特定までの記録をまとめました。

予兆：30秒ごとの「異変」

ある日、私のデスクトップ環境（GALLERIA / RTX 4060 Ti）で、画面が約30秒おきに数ミリ収縮し、また戻るという現象が起き始めました。

「30秒」というあまりに正確な周期は、ハードウェアの寿命というより、何らかのソフトウェア的な「タイムアウトとリトライ」を強く示唆していました。

迷走：Intel系サービスの負の連鎖

まず真っ先に確認したのは**イベントビューアー（システムログ）**です。案の定、そこには犯人らしきログが並んでいました。

Intel(R) SUR QC Software Asset Manager: 「接続を待機中にタイムアウト (30000 ミリ秒) になりました」
Energy Server Service queencreek: クラッシュの繰り返し

これらはIntelの利用状況レポート用プログラムですが、これが30秒（30,000ms）ごとに起動に失敗し、GPUの描写に干渉していたのです。

以下の対策を講じました。

Intel(R) Computing Improvement Program のアンインストール
関連するIntelサービスの無効化
デバイスマネージャーでの「HID カスタムセンサー」の無効化

これで解決かと思いきや……症状は再発しました。

突破口：マルチモニターの死角

ソフトウェア的な要因をほぼ潰しても治らない。ここで、物理環境に目を向けました。私の作業環境はマルチモニターですが、そのうち1枚は、TCL製のGoogle TVです。

ふと気づき、ある実験をしました。

TVがONの時: 症状は出ない。
TVがOFFの時: 30秒周期で画面が収縮する。

真犯人は「TVの待機信号」でした。 Google TVがOFF（待機状態）の際、約30秒周期で「生存確認（ハンドシェイク）」をPCに送っており、それを受けるたびにWindowsが「モニター構成が変わった」と誤認して画面全体を再計算（リセット）していたのです。

解決：HDMI CECの封印と最適化

最終的に、以下の設定を行うことで、画面は完全に安定しました。

1. TV側（TCL）の設定

T-Link（HDMI CEC）をオフ: HDMI経由の制御信号を遮断。
クイックスタートをオフ: 待機中の余計なスキャンを防止。

2. Windows 11の設定

「モニターの接続に基づいてウィンドウの位置を記憶する」をオフ: 切断検知時の描写リセットを抑制。

まとめ

「30秒周期」という規則正しいエラーは、ソフトウェアの再試行、あるいは外部機器のポーリングを疑うのが鉄則です。今回は「Intelのテレメトリサービス」と「スマートTVの待機信号」という二重の罠でしたが、ログと物理現象を紐付けることで解決できました。

同じようなマルチモニター環境で「画面が一瞬ガタつく」方は、一度モニター（特にTV）の省電力設定を疑ってみることをお勧めします。

Indigo Works | Blog

NotebookLMにJSTQBシラバスを読み込ませたら、最強の試験対策ツールになった話

はじめに

NotebookLMで生成したものとその感想

1. まるでラジオ番組！男女2人の「音声解説」

2. 過去問代わりに使える「クイズ」と「フラッシュカード」

3. 要点が視覚化された「スライド」

衝撃だったポイント

まとめ

『エッセンシャル スクラム』に学び、アジャイル現場へ応用したい話

1. 要件は「契約」ではなく「対話のプレースホルダー」

2. 見積もりと計画の真実：「地図より地形を信じよ」

3. スピードを殺す「技術的負債」との戦い

4. フリーランスや個人開発へのスクラムの応用

おわりに：スクラムに「終了状態」はない

Cloudflare PagesにAWS Route 53管理のカスタムドメインを設定する

なぜ yourdomain.com ではなく www.yourdomain.com をメインにするのか

Step 1: Cloudflare PagesにカスタムドメインのCNAMEを設定する

Step 2: AWS Route 53にCNAMEレコードを追加する

Step 3: Cloudflare側でDNS確認を待つ

おまけ：yourdomain.com（ルートドメイン）からのリダイレクト設定

S3バケットを作成する

S3でリダイレクトを設定する

Route 53にALIASレコードを追加する

まとめ

JavaScriptとTypeScriptの歴史の整理：バージョンとモジュールシステムの変遷

1. JavaScriptとTypeScriptの関係

2. JavaScript (ECMAScript) の歴史と名称の変遷

ES2015 (ES6) 以前：黎明期から停滞期

大転換期：ES2015 (ES6) と名称の変更

3. TypeScriptの誕生と進化

4. CommonJS (CJS) と ES Modules (ESM) の詳細

比較表

技術的な大きな違い

Astro + Starlightブログにおけるタグ管理のベストプラクティス（Zodを使った表記揺れの防止）

はじめに

Zodとは？なぜAstroで使われるのか

解決策：Zodスキーマと辞書（Map）を使った自動変換

1. src/content.config.ts の実装

2. コードの解説（Zodの動き）

運用ルール：タグは「小文字・ケバブケース」で書く

辞書にない「マイナーなタグ」はどうなる？

まとめ

WSL2環境でペット専用LoRAを訓練してStability Matrixで画像生成するまでのまとめ

はじめに

LoRA（ローラ）とは？

目次

プロジェクト概要

目標

使用技術スタック

1. 環境構築

1.1 Python環境のセットアップ

1.2 Kohya SS GUIのインストール

2. 訓練データの準備

2.1 写真の収集

2.2 画像の前処理

2.3 ディレクトリ構造

3. LoRA訓練の実行

3.1 Kohya SS GUIでの設定

Model設定

Parameters - Basic

Parameters - Advanced

3.2 訓練の実行

3.3 訓練結果

4. トラブルシューティング

4.1 NumPy互換性エラー

4.2 Stable Diffusion WebUIのインストールエラー

5. 画像生成のセットアップ

5.1 Stability Matrixの使用

5.2 画像生成

技術的な学び

pyenvの重要性

NumPyバージョン管理

WSL2 vs Windows Native

LoRA訓練のベストプラクティス

まとめ

参考リンク

成果物

Stripeアカウント閉鎖からGitHub Sponsors成功まで：AI画像サービスの決済問題解決記録

はじめに

『エッセンシャルスクラム』に学び、アジャイル現場へ応用したい話

なぜ `yourdomain.com` ではなく `www.yourdomain.com` をメインにするのか

おまけ：`yourdomain.com`（ルートドメイン）からのリダイレクト設定

1. `src/content.config.ts` の実装