Forem: Hama

Windows 11検索を爆速化！EverythingToolbarの導入とエンジニア向け活用術

Hama — Tue, 03 Feb 2026 11:06:37 +0000

Windows 11検索を爆速化！EverythingToolbarの導入とエンジニア向け活用術

はじめに

Windows 11の標準検索、少し「遅い」と感じたことはありませんか？
Web検索結果が混ざったり、ローカルファイルのインデックス作成に時間がかかったりと、開発のテンポを削ぐ要因になりがちです。

そこで今回は、Windows最強のファイル検索ソフト「Everything」をタスクバーに統合し、OS標準の検索機能を爆速化させる「EverythingToolbar」について解説します。

特に、キーボードから手を離さずに操作する「マウスレス設定」や、正規表現を駆使した「エンジニア向け検索テクニック」に焦点を当てて紹介します。

EverythingToolbarとは？

EverythingToolbarは、タスクバーにある標準の検索ボックス（虫眼鏡アイコン）を、Everythingの検索窓に置き換えるオープンソースツールです。

見た目は純正ライク: Windows 11のモダンなUIに完全に馴染みます。
中身は爆速: バックエンドでEverythingが動いているため、数百万のファイルから一瞬で目的のファイルを探し出せます。

1. 導入と基本セットアップ

インストール手順

前提として、Voidtools公式サイトからEverything本体をインストールし、常駐させておく必要があります。

GitHubのリリースページから最新のインストーラー（.exe）をダウンロードして実行。

タスクバー設定で、Windows標準の「検索」アイコンを非表示にする。
スタートメニューから「EverythingToolbar」を検索し、「タスクバーにピン留め」する。

ピン留めしたアイコンを、元の検索ボタンがあった位置（左端など）にドラッグして配置。

これで、見た目は今まで通り、中身は爆速な検索環境が整いました。

2. 「マウスレス」で呼び出すための設定

エンジニアにとって、マウスへの持ち替えはタイムロスです。
macOSのSpotlightやAlfredのように、キーボードショートカット一発で呼び出し、用が済んだら勝手に消える挙動に設定しましょう。

設定画面へのアクセス

EverythingToolbarの検索窓を開き、右上の歯車アイコン（⚙️）をクリックして設定を開きます。

推奨設定 (General)

Hide window when focus is lost: ON
- 検索窓からフォーカスが外れたら（ファイルを開く、別の場所をクリックするなど）、自動でウィンドウを閉じます。これで「閉じるボタンを押す」手間がなくなります。
Shortcuts:
- デフォルトは Win + Alt + S ですが、押しにくい場合は変更しましょう。
- おすすめ: Alt + Space（PowerToys Runなどと競合しない場合）や Ctrl + Space など、左手だけで完結するキーが理想です。

この設定により、「ショートカットで呼び出す」→「検索」→「Enterで開く」→「勝手に消える」という、完全なマウスレス操作が実現します。

3. エンジニア向け検索テクニック

EverythingToolbarは、Everythingの強力な検索構文をそのまま利用できます。
GUIでポチポチ探すのではなく、クエリで絞り込むのがエンジニア流です。

拡張子で絞り込む (`ext:`)

特定のソースコードだけを探したい場合に便利です。

# Pythonファイルだけ検索
ext:py main

# TypeScriptファイルだけ検索
ext:ts utils

パスを含めて検索 (`path:`)

同名のファイルが多い場合（index.ts や README.md など）、ディレクトリ名を含めて検索します。

# "backend" ディレクトリ配下の "config" を含むファイル
backend config

※ 設定で「Match Path」をONにするか、検索時にスペースで区切るとAND検索として機能します。

正規表現を使う (`regex:`)

これが最強の機能です。複雑な命名規則のファイルや、特定のパターンに一致するログファイルなどを一撃で特定できます。

# "project_" で始まり ".json" で終わるファイル
regex:^project_.*\.json$

# 日付形式 (YYYYMMDD) を含むログファイル
regex:log_\d{8}\.txt

検索コマンドのショートカット

検索ボックスに以下のプレフィックスを入力することで、モードを瞬時に切り替えられます。

file: : ファイルのみ検索
folder: : フォルダのみ検索
case: : 大文字小文字を区別

まとめ

EverythingToolbarを導入し、ショートカットと検索構文を使いこなすことで、「ファイルを探す」という行為にかかる時間はほぼゼロになります。

Step 1: インストールしてタスクバーにピン留め
Step 2: フォーカスアウトで閉じる設定 & ショートカット割り当て
Step 3: ext: や regex: で狙い撃ち検索

開発マシンの生産性を底上げしたい方は、ぜひ今日から導入してみてください。

GitHub Organizationに課金できなくても、AIエディタの暴走は止められる（pre-commit / pre-push + .cursor/rules）

Hama — Sun, 01 Feb 2026 05:43:32 +0000

GitHub Organizationに課金できなくても、AIエディタの暴走は止められる（pre-commit / pre-push + .cursor/rules）

はじめに（ある日、AIが気持ちよく“仕事”しすぎた）

CursorとかWindsurfとか、最近のAIエディタって、放っておくと本当に手が速いですよね。
気づいたらファイルが増え、依存が増え、コマンド履歴が増え、そして「そのまま push しそう」になる。

でも、GitHubのOrganizationで Branch protection をちゃんと課金して運用するのが難しい状況だと、
最後の砦が薄くて、心理的にけっこう怖い。

なので私は、ローカル側で“物理ロック”をかけました。
やりたいのはこれだけです：

main / develop ではコミットさせない（そもそもAIが間違えた場所で作業しない）
main / develop へは push させない（最悪でもローカルで止まる）
AIには守るべきプロジェクトルールを常に読ませる（毎回言い聞かせない）

この記事は、そのための最小構成の話です。

結論：ガードレールは「二段」にすると強い

私はこの2つを重ねるのが一番ラクでした。

.cursor/rules: “AIの意思決定”を縛る（暴走しにくい道を作る）
Gitフック（pre-commit / pre-push）: “最後の操作”を物理的に止める（暴走しても落ちる）

.cursor/rules は「お願い」寄り、Gitフックは「強制」寄り、というイメージです。

1) pre-commit：main/develop での直接コミットを禁止する

まずは pre-commit。
コミットの直前に実行されるフックで、ブランチ名を見て止めます。

私が使っているのはこんな感じ（ほぼそのまま貼ります）：

#!/bin/bash

# 現在のブランチ名を取得
current_branch=$(git symbolic-ref HEAD | sed -e 's,.*/\\(.*\\),\\1,')

# main または develop ブランチならコミット・マージを阻止
if [ "$current_branch" = "main" ] || [ "$current_branch" = "develop" ]; then
    echo "----------------------------------------------------"
    echo "🔴 ERROR: ローカルの '$current_branch' ブランチでの直接コミット/マージは禁止されています。"
    echo "   理由: 誤ったブランチへの作業防止のため、フックで制限しています。"
    echo "   対処: 作業用ブランチを切ってから変更してください。"
    echo "   (例: git checkout -b feature/xxx)"
    echo "----------------------------------------------------"
    exit 1
fi

exit 0

どこに置く？

一番雑にやるなら、対象リポジトリの .git/hooks/pre-commit に置きます（実行権限も付ける）。

cp /path/to/pre-commit .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit

[!NOTE]
.git/hooks は Git 管理外です。チームで共有したい場合は core.hooksPath を使って、リポジトリ内のディレクトリにフックを置く方式にすると運用が安定します（後述）。

これで何が嬉しい？

AIが「じゃあコミットしとくね」って勝手にやりだしても、main/develop なら物理的に落ちる。
「うっかり」系の事故って、だいたい最後の 1 コマンドで起きるので、ここで止まるのは本当に効きます。

2) pre-push：main/develop への直接 push を禁止する

次は pre-push。
push 直前に、Gitが stdin で渡してくる情報（どの ref をどこへ push するか）を見て止めます。

#!/bin/bash

# 保護したいリモートブランチのリスト
PROTECTED_BRANCHES=("main" "develop")

# Gitは pre-push 実行時に、標準入力(stdin)で以下の情報を渡してきます
# <local_ref> <local_sha1> <remote_ref> <remote_sha1>
# これをループで読み取ってチェックします
while read local_ref local_sha remote_ref remote_sha
do
    # remote_ref (例: refs/heads/main) からブランチ名部分だけ抽出
    target_branch=${remote_ref#refs/heads/}

    for protected in "${PROTECTED_BRANCHES[@]}"; do
        if [ "$target_branch" = "$protected" ]; then
            echo "----------------------------------------------------"
            echo "🔴 ERROR: リモートの '$target_branch' への直接プッシュは禁止されています。"
            echo "   理由: GitHub Free版環境のため、フックで保護しています。"
            echo "   対処: Pull Requestを作成してマージしてください。"
            echo "----------------------------------------------------"
            # 1つでも禁止ブランチへのプッシュが含まれていれば停止
            exit 1
        fi
    done
done

exit 0

これも .git/hooks/pre-push に置けばOKです。

cp /path/to/pre-push .git/hooks/pre-push
chmod +x .git/hooks/pre-push

これ、AI対策として強いポイント

AIが暴走してる時って、だいたい「差分がデカい」ことよりも「判断が早い」んですよね。
pre-push は “pushという行為”を止めるので、差分の内容に関係なく安全装置として働きます。

3) `.cursor/rules`：AIの“行動原理”を縛る（お願いではなく習慣にする）

Gitフックは最後の砦ですが、できればそもそも暴走してほしくない。
そこで効くのが .cursor/rules です。

このリポジトリだと、例えばこういう方針がすでにルール化されています：

main / develop worktree では AI はコード変更しない
1機能=1 feature ブランチ=1 worktree
push / PR 作成などのリモート影響操作は、ユーザーの明示指示が必要

これ、地味にめちゃくちゃ効きます。
理由は単純で、AIが「安全に見える次の一手」を選び続けた結果、事故が減るから。

追加で入れておくと事故が減る“言い回し”

私は .cursor/rules に、次みたいな「禁止」というより「手順」を書くのが好きです。
（AIは“空気”より“手順”に従いやすい）

## ガードレール
- `git checkout main` / `git checkout develop` を提案しない（読むだけにする）
- `git push` / `gh pr create` は、必ず「実行してよいか」を先に確認する
- 変更は feature worktree 内で完結させ、最後に `git status` と差分を提示する

[!TIP]
「何をするな」だけだと抜け道を探しがちなので、「代わりに何をするか」まで書くと安定します。

4) （運用編）Gitフックを“リポジトリ管理”したい場合の現実的な落としどころ

.git/hooks は共有できないので、チームで揃えるなら core.hooksPath がラクです。

例として scripts/githooks/ にフックを置くなら：

mkdir -p scripts/githooks
cp /path/to/pre-commit scripts/githooks/pre-commit
cp /path/to/pre-push scripts/githooks/pre-push
chmod +x scripts/githooks/pre-commit scripts/githooks/pre-push

git config core.hooksPath scripts/githooks

これで、そのリポジトリでは Git が scripts/githooks をフックとして参照します。

[!NOTE]
git config core.hooksPath ... は各ローカルに設定が必要です。READMEに「最初にやること」として書いておくと定着します。

5) それでも起きる“AI暴走あるある”と対策メモ

勝手にブランチを切り替える
- .cursor/rules 側で「develop/main には移動しない」を明文化
- pre-commit が最後に止める
勢いで git push origin HEAD しようとする
- .cursor/rules 側で「push は確認必須」
- pre-push が最後に止める
大規模変更を一気に入れる
- これはフックよりも運用。.cursor/rules に「小さく分ける」「差分を見せる」を書くのが効きます

まとめ：無料でも“事故は減らせる”。しかも精神が軽い

GitHub側でガチガチに守れない状況でも、ローカルでできることは意外と多いです。
特にAIエディタ相手だと、次の構えが効きました。

先に .cursor/rules で“安全な道”を作る
最後に Gitフックで“物理ロック”をかける

「AIが賢いから大丈夫」じゃなくて、「賢いからこそ、速さにブレーキを付ける」。
これで私は、かなり安心して Cursor / Antigravity / Windsurf と付き合えるようになりました。

PMBOKの叡智がAIに集約された「PMI Infinity」

Hama — Thu, 04 Dec 2025 05:18:08 +0000

この記事でわかること

PMI InfinityがPMBOKや公式アジャイルガイドの知見をどう再編集してくれるのか
2025年時点で追加された「Explore Project Management」やキャリア支援系の新カード
実務での使いどころとリスク、導入の段取り

先週、緊急レビュー前にナレッジを探して30分もPMBOKをめくってしまい「あれ、AIに聞けばよかったのでは？」と頭を抱えました。同じモヤモヤを抱えているPMの方に向けて、スクリーンショット付きでPMI Infinityの最新状況を整理します。

なぜ今PMI Infinityなのか

公式ソース優先: PMBOK第7版やアジャイル実践ガイドの文章を優先的に返し、出典リンクも表示されるので、社内レビューで根拠を聞かれても即回答できます。
業界横断のベストプラクティス: 14,000人超の専門家コミュニティで学習済み。ITだけでなく建設・金融のケースにも触れられます。
リアルタイム回答: 会議中にスマホから聞いても5分以内に代替案を拾えるスピード感。Slackで相談して返事を待つ時間が丸ごと削減されました。

2024年2月以降はPMI会員限定になりますが、今は検証に十分な30日間のフリートライアル期間が残っています。迷っているなら今のうちに触ってクセづけるのが吉です。

PMI Infinityの最新トピック（2025年版）

トピック	何が変わったか	現場での価値
Explore Project Managementハブ	4つのカード（資格、ヘルスチェック、スコープ管理、ステークホルダー管理）で入口が整理された	迷子にならず、議題ごとにテンプレとFAQへ最短アクセス
プロジェクト健全性チェック	チャット内で質問票を生成し、回答に応じたタスクリストを返してくれる	定例の事前アンケートを5分で配布でき、翌日の会議がスムーズ
キャリアガイダンス回答	PMPやAgile認定、スキルトレーニングを踏まえた成長ロードマップが提示される	メンバーの育成プランをその場で提案でき、1on1が濃密に
出典テキスト表示	引用元章節がカード化され、リンクをワンクリックで開ける	監査対応やステークホルダー説得資料の作成が高速化

個人的には、キャリア相談カードが登場したことで新人PMとの壁打ちが一気に楽になりました。「どこから着手すればいいですか？」という質問に対し、Infinityの回答をベースに現場色を足すだけでよくなります。

実際の画面で追体験

1. Explore Project Managementのホーム

初期画面で4カテゴリがタイル表示されます。スコープ調整のメール文面や資格取得のROI比較など、課題別のテンプレにジャンプできるので社内ポータルより早く目的地に到着できます。

2. リアルタイムQAでバッファ計画を確認

「プロジェクトのバッファをどう説明する？」と聞くと、フィーディング／リソース／プロジェクトバッファを整理した上で、クリティカルチェーン方式の計算例を即座に返してくれます。私はレビュー直前にこの回答を参考にし、バッファ設定の理由をスライド1枚にまとめて難を逃れました。

3. キャリア相談カードで成長ロードマップを生成

「ITコンサルでキャリアを伸ばすには？」と聞くと、ジュニア→シニア→プログラムマネージャーの階段と取得すべき資格、推奨書籍、コミュニティ紹介まで返します。メンター役としてはこの回答を叩き台に余白を足すイメージです。

活用シナリオ（自分の体験も交えつつ）

月曜朝のリスクレビュー前: Infinityでテンプレを取得し、リスク登録票を15分で更新。結果として会議が15分短縮されました。
ステークホルダーとの交渉: Scope Creepカードを開き、チェンジリクエストの説明メールをそのまま英訳して送付。海外チームからも理解が早いと好評でした。
新人PMのオンボーディング: キャリアカードで推奨教材を出し、そのままNotionに貼り付けて育成トラック化。質問が減り、自走が早まりました。

注意点と運用のコツ

機密情報は入れない: 具体的な案件名やコストは伏せ、パラメータだけを与える。必要ならプレーンな数字に置き換える。
AI案＋現場の温度差を調整: Infinityはグローバル基準寄り。日本の顧客文化に合わせたトーン修正は必須です。
ログイン要件を早めに確認: 2024年2月12日以降はPMI会員限定になる予定なので、組織アカウントの準備を進めておく。

今すぐ試すための3ステップ

公式サイトにアクセスし、PMIアカウントでログイン。
Explore Project Managementのカードから、今日困っているテーマを1つ選ぶ。
得た回答をチームに共有し、どれだけリードタイムが縮んだかを記録。ROIが明確になると導入申請が通りやすくなります。

まとめ

PMI Infinityは「情報検索に奪われる時間」と「根拠の曖昧さ」を同時に解決してくれるAIパートナーです。出典付きでPMBOKの文言を引用でき、ステークホルダー説明が驚くほどスムーズになります。現場の文脈で味付けしながら、まずは1週間使い倒して効果を測ってみてください。

参考: Enhanced Inc. 業務効率化ブログ「PMI Infinity」特集（2025/07/02 更新）
PMI Infinity公式サイト
 PMI日本支部
 NTT DATA - PMI Infinityについて

技術ブログにMermaidダイアグラムを導入した話【はてなブログ・DEV.to・Next.js対応】

Hama — Tue, 25 Nov 2025 02:47:08 +0000

技術ブログにMermaidダイアグラムを導入した話【はてなブログ・DEV.to・Next.js対応】

はじめに

技術記事を書く時、フローチャートやシーケンス図があると格段に分かりやすくなりますよね。

今回、マルチプラットフォーム対応の技術ブログでMermaid記法によるダイアグラム表示に対応したので、その実装方法を紹介します！

対応したプラットフォーム：

📝 はてなブログ - カスタムJavaScriptで対応
🌐 DEV.to - Mermaidを画像に変換して投稿
⚡ Next.js（Vercel） - クライアントサイドレンダリング

Mermaidとは？

Mermaidは、テキストベースでダイアグラムを描けるJavaScriptライブラリです。

記述例:

graph TD
    A[ユーザー] -->|記事を書く| B[Markdown]
    B -->|変換| C[Mermaid]
    C -->|レンダリング| D[ダイアグラム表示]

シンプルなテキストで、こんな感じの図が描けます。めっちゃ便利！

各プラットフォームの対応方法

1. はてなブログでの対応

はてなブログは標準でMermaidをサポートしていないため、カスタムJavaScriptで対応しました。

実装手順

1) はてなブログの管理画面で「設定」→「詳細設定」を開く

2) 「headに要素を追加」に以下を貼り付け:

<!-- Mermaidダイアグラムのスタイル設定 -->
<style>
  .mermaid {
    background-color: #ffffff !important;
    padding: 20px;
    border-radius: 4px;
    margin: 20px 0;
  }

  .mermaid svg {
    background-color: #ffffff !important;
  }
</style>

<!-- Mermaidダイアグラム表示用スクリプト -->
<script type="module">
  import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs';

  document.addEventListener('DOMContentLoaded', function() {
    mermaid.initialize({
      startOnLoad: true,
      theme: 'default',
      themeVariables: {
        background: '#ffffff'
      },
      securityLevel: 'loose'
    });

    document.querySelectorAll('pre code').forEach((codeBlock) => {
      const codeText = codeBlock.textContent || codeBlock.innerText;

      if (codeText.trim().startsWith('mermaid')) {
        const pre = codeBlock.parentElement;
        if (pre) {
          const lines = codeText.split('\\n');
          const mermaidCode = lines.slice(1).join('\\n').trim();

          const mermaidDiv = document.createElement('div');
          mermaidDiv.className = 'mermaid';
          mermaidDiv.textContent = mermaidCode;

          pre.replaceWith(mermaidDiv);
        }
      }
    });

    mermaid.run({
      querySelector: '.mermaid'
    });
  });
</script>

3) 記事では以下のように書く:

```


mermaid
graph LR
    A --> B


```
```

`

> [!IMPORTANT]
> はてなブログでは `

 ```mermaid ` という書き方ができないため、コードブロック内の最初の行に `mermaid` と書く必要があります。

#### ポイント

- ✅ **白背景を強制**: 暗い背景になる問題を解決
- ✅ **CDN経由**: 最新版のMermaidを自動で利用
- ✅ **一度設定すれば全記事に適用**

### 2. DEV.toでの対応

DEV.toは**Mermaidをネイティブサポートしていない**ため、画像に変換して投稿する方式を採用しました。

#### 実装（自動化）

Node.jsスクリプトで、記事投稿時に自動的にMermaidブロックを画像に変換します。

```

javascript
// scripts/utils/mermaid-converter.mjs
import { execSync } from 'child_process';

export async function convertMermaidToImage(mermaidCode, outputPath) {
    const tempInputFile = `/tmp/mermaid-${Date.now()}.mmd`;

    fs.writeFileSync(tempInputFile, mermaidCode, 'utf8');

    // mermaid-cliで画像変換（背景は白色）
    execSync(
        `npx -y @mermaid-js/mermaid-cli@latest -i "${tempInputFile}" -o "${outputPath}" -b white`,
        { stdio: 'inherit' }
    );

    fs.unlinkSync(tempInputFile);
    return true;
}


```

**変換の流れ:**
1. Markdown内の ` ```
{% endraw %}
mermaid {% raw %}` ブロックを検出
2. `{% endraw %}@mermaid-js/mermaid-cli{% raw %}`で画像（PNG）に変換
3. `{% endraw %}public/images/diagrams/{% raw %}`に保存
4. Markdownを `{% endraw %}![diagram](/images/diagrams/xxx.png){% raw %}` に置き換え

#### メリット

- ✅ DEV.toでも確実に表示される
- ✅ 画像なのでロード時間が速い
- ✅ ダークモードでも見やすい（白背景指定）

### 3. Next.js（Vercel）での対応

自サイト（Next.js）では、クライアントサイドでMermaidをレンダリングしています。

#### 実装

`{% endraw %}{% raw %}``tsx
// src/components/mdx/MermaidRenderer.tsx
'use client';

import { useEffect } from 'react';

export function MermaidRenderer() {
    useEffect(() => {
        async function initMermaid() {
            const mermaid = (await import('mermaid')).default;

            mermaid.initialize({
                startOnLoad: true,
                theme: 'default',
                themeVariables: {
                    background: '#ffffff', // ダークモードでも白背景
                },
                securityLevel: 'loose',
            });

            const codeBlocks = document.querySelectorAll('pre code.language-mermaid');
            codeBlocks.forEach((codeBlock, index) => {
                const pre = codeBlock.parentElement;
                if (pre) {
                    const code = codeBlock.textContent || '';
                    const wrapper = document.createElement('div');
                    wrapper.className = 'mermaid-diagram-wrapper';
                    wrapper.id = `mermaid-diagram-${index}`;
                    wrapper.textContent = code;
                    pre.replaceWith(wrapper);
                }
            });

            mermaid.run({
                querySelector: '.mermaid-diagram-wrapper',
            });
        }

        initMermaid();
    }, []);

    return null;
}
``{% endraw %}{% raw %}`

#### ダークモード対応（CSS）

`{% endraw %}{% raw %}``css
/* src/app/globals.css */
.mermaid-diagram-wrapper,
.mermaid-diagram-wrapper svg {
  background-color: #ffffff !important;
  padding: 20px;
  border-radius: 8px;
  margin: 20px 0;
}

/* ダークモードでは薄い枠線を追加 */
.dark .mermaid-diagram-wrapper {
  border: 1px solid #475569;
}
``{% endraw %}{% raw %}`

## 苦労した点と解決方法

### 問題1: 背景が暗くて見づらい

**症状:**
デフォルトのMermaidテーマだと、ダイアグラムの背景が暗い色になり、矢印や文字が見にくい。

**解決策:**
- `{% endraw %}themeVariables.background: '#ffffff'{% raw %}`で強制的に白背景に
- CSSで`{% endraw %}.mermaid{% raw %}`要素にも白背景を適用

### 問題2: ダークモードで真っ白すぎて浮く

**症状:**
ダークモードのページで白背景のダイアグラムが浮いて見える。

**解決策:**
`{% endraw %}{% raw %}``css
.dark .mermaid-diagram-wrapper {
  border: 1px solid #475569; /* 薄い枠線を追加 */
}
``{% endraw %}{% raw %}`

### 問題3: はてなブログで `{% endraw %} 
{% raw %}
```

mermaid ` が使えない

**症状:**
はてなブログはコードブロックの言語指定に対応していない。

**解決策:**
コードブロック内の最初の行を `mermaid` にして、JavaScriptで判定する方式に変更。

## まとめ

Mermaidダイアグラムを3つのプラットフォームで表示できるようにした実装を紹介しました。

**ポイント:**
- 📝 **はてなブログ**: カスタムJSで動的レンダリング
- 🌐 **DEV.to**: CLIで事前に画像変換
- ⚡ **Next.js**: クライアントサイドレンダリング + ダークモード対応

各プラットフォームの特性に合わせた実装で、どこでも快適にダイアグラムが表示されるようになりました！

技術記事に図解を入れたい方の参考になれば嬉しいです 🎉

## 参考リンク

- [Mermaid公式ドキュメント](https://mermaid.js.org/)
- [Mermaid CLI](https://github.com/mermaid-js/mermaid-cli)
- [はてなブログのカスタマイズ](https://help.hatenablog.com/)

---

*この記事の図解もすべてMermaidで作成されています！*

GoogleのAIエディタ「Antigravity」を触ってみた！設定やワークフローも解説

Hama — Tue, 25 Nov 2025 01:22:53 +0000

GoogleのAIエディタ「Antigravity」を触ってみた！設定やワークフローも解説

はじめに

Googleが2025年11月18日に発表した新しいAIエディタ「Antigravity」。
「重力から解放されたかのような軽快なコーディング体験」を謳うこのエディタ、気になっている方も多いのではないでしょうか？

今回は、実際にAntigravityを使って簡単なアプリ開発を試してみた感想と、Antigravityの真骨頂とも言える「プロジェクト固有のルール設定」や「ワークフロー機能」について深掘りして解説します！

Antigravityとは？

Antigravityは、Googleが開発した次世代のAIネイティブエディタです。
単なるコード補完だけでなく、「Agent」と呼ばれるAIアシスタントが開発プロセス全体をサポートしてくれるのが最大の特徴です。

主な特徴は以下の通り：

Agentic AI: 指示を出すだけで、計画・実装・検証まで自律的に行ってくれる
Context Awareness: プロジェクト全体の文脈を理解し、適切な提案をしてくれる
Customizability: プロジェクトごとのルールやワークフローを柔軟に定義できる

実際に触ってみた

今回は、Qiitaの記事「Googleが発表したAIエディタ、Antigravityを触ってみた。」を参考に、簡単なAIチャットアプリを作成してみました。

1. インストールと起動

まずは公式サイトからインストーラーをダウンロードしてインストール。
起動すると、「Open Agent Manager」という画面が表示され、そこからプロジェクトを開始できます。

Open Agent Managerの起動画面（イメージ）

2. 指示出し

「Agent Manager」に作りたいアプリの概要を伝えます。
今回は「Next.jsを使って、シンプルなAIチャットアプリを作って」と指示しました。

Agentとのチャット画面（イメージ）

すると、Antigravityはすぐに実装プランを提示し、必要なファイルの作成やパッケージのインストールを開始！
見ていて気持ちいいくらいサクサク進みます。

3. 実装と確認

実装が完了すると、自動的にブラウザが立ち上がり、アプリが起動しました。
デザインもモダンで、基本的な機能はしっかり動作しています。

生成されたAIチャットアプリ（イメージ）

「ここをこう直して」といった追加の指示も、自然言語で伝えるだけですぐに反映されました。

Antigravityの真価：ルールとワークフロー

さて、ここからが本題です。
Antigravityが他のAIエディタと一線を画すのが、.agent ディレクトリによるカスタマイズ機能です。

プロジェクトルートに .agent ディレクトリを作成し、そこに設定ファイルを置くことで、AIの振る舞いを細かく制御できます。

1. `rules.md` でプロジェクトのルールを教える

.agent/rules.md（または .cursor/rules/*.mdc から生成される rules.md）は、AIに守らせたいルールを記述するファイルです。

例えば、以下のようなルールを定義できます：

言語設定: 「コミットメッセージやドキュメントは全て日本語で書くこと」
技術スタック: 「スタイリングにはTailwind CSSを使用し、CSS Modulesは使わないこと」
コーディング規約: 「関数コンポーネントはアロー関数で定義すること」

設定例 (.agent/rules.md):

# Project Rules

## General
- **Language**: Always respond in Japanese.
- **Framework**: Use Next.js App Router.

## Coding Standards
- Use `const` for all variable declarations.
- Prefer functional components over class components.

これを置いておくだけで、Antigravityはこのルールを常に意識してコードを生成してくれます。
「毎回『日本語で書いて』って言うのが面倒…」といった悩みから解放されます！

rules.mdがAgentに与える影響のイメージ

2. `.agent/workflows` で定型作業を自動化

.agent/workflows ディレクトリには、よく行う一連の作業手順（ワークフロー）をMarkdown形式で定義できます。

例えば、「新機能開発のフロー」や「デプロイ手順」などを定義しておくと、AIがその手順に沿って作業を進めてくれます。

設定例 (.agent/workflows/feature-development.md):

---
description: "新機能開発のワークフロー"
---

1. 最新の `develop` ブランチから `feature/xxx` ブランチを作成する
2. 実装を行う
3. `npm run lint` と `npm run test` を実行して問題ないか確認する
4. PRを作成する（タイトルと説明は日本語で）

このように定義しておけば、「新機能開発フローを実行して」と伝えるだけで、ブランチ作成からテスト、PR作成までをミスなく実行してくれます。
チーム開発でのオペレーション統一に非常に強力です。

ワークフロー実行の流れ

まとめ

Antigravityは、単にコードを書くだけでなく、「開発プロセスそのもの」をAIと一緒に作り上げていく感覚が新しいエディタでした。

特に rules.md と workflows を活用することで、自分たちだけの「最強のAIペアプログラマー」に育て上げることができます。
まだ触っていない方は、ぜひ一度試してみてください！

AI駆動型販売・在庫管理システム「OpsPilot Console」の実装と展望

Hama — Tue, 25 Nov 2025 01:22:40 +0000

AI駆動型販売・在庫管理システム「OpsPilot Console」の実装と展望

はじめに

こんにちは！今回は、現在開発中の「OpsPilot Console」というプロジェクトについてご紹介します。
これは、中小企業向けの販売・受発注・在庫管理を一つのNext.jsアプリケーションで完結させるという、野心的な試みです。

「業務システムって堅苦しくて使いにくい...」そんなイメージを払拭すべく、モダンな技術スタックでサクサク動く、そしてAIの力で業務を効率化するシステムを目指しています。

開発中のダッシュボード画面イメージ

アーキテクチャと技術スタック

OpsPilot Consoleは、モノリポ構成を採用しています。フロントエンドとAPIをNext.jsのApp Router内で同居させることで、開発効率を最大化しています。

主な技術スタックは以下の通りです。

Framework: Next.js 16 (App Router) / React 19
Styling: Tailwind CSS v4
Database: Neon Postgres
ORM: Prisma ORM
Language: TypeScript

なぜこのスタックなのか？

最大の理由は「開発スピードと保守性の両立」です。
Next.jsのApp Routerを使えば、サーバーサイドとクライアントサイドの境界を意識しつつも、シームレスにデータを扱えます。
また、DBにはサーバーレスPostgresであるNeonを採用。Prismaとの相性も抜群で、スキーマ定義から型安全なDB操作までがスムーズに行えます。

OpsPilot Consoleのアーキテクチャ概要

実装の詳細

ディレクトリ構造

プロジェクトの構造は非常にシンプルです。

src/
  app/                   # App Router エントリ
    (dashboard)/         # 業務画面のルートグループ
    api/                 # Route Handlers
  components/            # UI コンポーネント
  lib/                   # 共通ユーティリティ
prisma/
  schema.prisma          # Prisma スキーマ

Container Use / git worktree フロー

開発フローにもこだわりがあります。
すべての開発はContainer Use (Dagger MCP) のコンテナ内で行い、ホストマシンの環境を汚しません。
また、git worktreeを活用することで、ブランチの切り替えコストをゼロにしています。

# 例: 新機能開発の流れ
container-use new feature-xyz --branch feature/xyz
container-use enter feature-xyz
# ... 開発 ...
container-use merge feature-xyz

Container UseとGit Worktreeを活用した開発フロー

これにより、複数のタスクを並行して進める際も、環境の競合を気にせず集中できます。

今後の展望 (Roadmap)

さて、ここからが本題です。現在は基礎的なCRUD機能の実装が進んでいますが、今後は以下の機能を追加していく予定です。

1. トランザクションと在庫履歴の実装

販売管理システムの肝となる、受注・発注のトランザクション処理と、それに伴う入出庫履歴の記録機能を実装します。
Prismaのトランザクション機能を活用し、データの整合性を担保しつつ、高速な処理を目指します。

2. APIの拡張とワークフロー

Route Handlersを拡張し、より複雑な業務ロジックをAPIとして提供します。
特に、発注承認フローなどのワークフロー機能は、システムの実用性を大きく高める重要な機能です。

3. 品質保証の自動化

現在、GitHub Issuesでも管理していますが、品質保証の自動化は急務です。

統合テストの追加: VitestとPrisma Test DBを使って、API層の振る舞いを自動検証します（Issue #11）。
CI/CDパイプライン: GitHub Actionsでlint、test、build、そしてPrismaのチェックを自動化し、常にデプロイ可能な状態を保ちます（Issue #12）。
E2Eテスト: Playwrightを導入し、実際のユーザー操作を模したテストを行うことで、UIの不具合を未然に防ぎます。

まとめ

OpsPilot Consoleは、単なる管理画面ではなく、「開発者が楽しみながら作れる、ユーザーが快適に使える」システムを目指しています。
モダンな技術を積極的に取り入れつつ、業務システムの要件もしっかり満たす。そんなバランスの取れた開発を続けていきます。

今後も開発の進捗や技術的な知見をブログで発信していきますので、ぜひチェックしてください！

Next.jsでQiita風の見出しアンカーリンクを実装する方法

Hama — Fri, 14 Nov 2025 05:50:27 +0000

Next.jsでQiita風の見出しアンカーリンクを実装する方法

はじめに

技術ブログを運営していると、Qiitaのような見出しにホバーするとリンクアイコンが表示される機能が欲しくなりますよね。実は、これって意外と簡単に実装できるんです。

今回は、Next.jsとrehypeを使って、Qiita風の見出しアンカーリンクを実装した際の経験を共有します。最初は位置がずれてしまったり、ハイドレーションエラーに悩まされたりしましたが、最終的には綺麗に動作するようになりました。

実装の背景

私のブログでは、Markdownで記事を書いて、unifiedとrehypeを使ってHTMLに変換しています。見出しに自動でアンカーリンクを追加する機能はrehype-autolink-headingsというプラグインで実現できるのですが、Qiitaのように見出しの左側にアイコンを表示するには、いくつか工夫が必要でした。

実装手順

1. 必要なパッケージのインストール

まず、必要なパッケージをインストールします。

npm install unified remark-parse remark-gfm remark-rehype rehype-stringify rehype-highlight rehype-slug rehype-autolink-headings

2. Markdownコンポーネントの実装

rehype-autolink-headingsを使って、見出しに自動でリンクを追加します。ポイントはbehavior: 'prepend'を使うことです。

import { unified } from 'unified';
import remarkParse from 'remark-parse';
import remarkGfm from 'remark-gfm';
import remarkRehype from 'remark-rehype';
import rehypeStringify from 'rehype-stringify';
import rehypeHighlight from 'rehype-highlight';
import rehypeSlug from 'rehype-slug';
import rehypeAutolinkHeadings from 'rehype-autolink-headings';

export function Markdown({ content, className }: MarkdownProps) {
  const htmlContent = unified()
    .use(remarkParse)
    .use(remarkGfm)
    .use(remarkRehype, { allowDangerousHtml: false })
    .use(rehypeSlug)
    .use(rehypeAutolinkHeadings, {
      behavior: 'prepend', // 見出しの内部（最初の子要素）にリンクを追加
      properties: {
        className: ['anchor-link'],
        'aria-label': '見出しへのリンク',
      },
      content() {
        // SVGアイコンを返す
        return {
          type: 'element',
          tagName: 'svg',
          properties: {
            className: ['anchor-link-icon'],
            width: '16',
            height: '16',
            viewBox: '0 0 16 16',
            fill: 'currentColor',
            'aria-hidden': 'true',
          },
          children: [
            {
              type: 'element',
              tagName: 'path',
              properties: {
                d: 'M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 11-2.83-2.83l2.5-2.5z',
              },
              children: [],
            },
          ],
        };
      },
    })
    .use(rehypeHighlight, {
      detect: true,
      ignoreMissing: true,
    })
    .use(rehypeStringify, { allowDangerousHtml: true })
    .processSync(content);

  return (
    <div 
      className={className || ''}
      dangerouslySetInnerHTML={{ __html: String(htmlContent) }}
    />
  );
}

3. CSSスタイルの実装

見出しをFlexboxにして、アイコンとテキストを同じ行に配置します。また、アイコンは通常は非表示にして、ホバー時に表示するようにします。

/* Qiita風の見出しアンカーリンク */
.article-content .anchor-link,
.prose .anchor-link {
  display: inline-flex;
  align-items: center;
  text-decoration: none;
  color: #94a3b8;
  opacity: 0; /* 通常は非表示 */
  transition: opacity 0.2s, color 0.2s;
  flex-shrink: 0;
}

.article-content .anchor-link-icon,
.prose .anchor-link-icon {
  width: 16px;
  height: 16px;
  display: inline-block;
}

/* ホバー時にアイコンを表示 */
.article-content h2:hover .anchor-link,
.article-content h3:hover .anchor-link,
.article-content h4:hover .anchor-link,
.prose h2:hover .anchor-link,
.prose h3:hover .anchor-link,
.prose h4:hover .anchor-link {
  opacity: 1;
}

.article-content .anchor-link:hover,
.prose .anchor-link:hover {
  color: #3b82f6; /* ホバー時は青色に */
  opacity: 1;
}

/* 見出しをFlexboxにして、アイコンとテキストを同じ行に配置 */
.article-content h2,
.article-content h3,
.article-content h4,
.prose h2,
.prose h3,
.prose h4 {
  color: inherit;
  text-decoration: none;
  position: relative;
  padding-bottom: 0.3em;
  border-bottom: 1px solid #e2e8f0; /* 下線を追加 */
  margin-top: 1.5em;
  margin-bottom: 0.8em;
  display: flex; /* Flexboxに変更 */
  align-items: center;
  gap: 0.5rem; /* アイコンとテキストの間隔 */
}

.dark .article-content h2,
.dark .article-content h3,
.dark .article-content h4,
.dark .prose h2,
.dark .prose h3,
.dark .prose h4 {
  border-bottom-color: #475569;
}

つまずいたポイントと解決方法

問題1: リンクアイコンが見出しの上に表示されてしまう

最初はbehavior: 'before'を使っていたのですが、これだとリンクが見出し要素の外側（兄弟要素）に配置されてしまい、見出しのdisplay: flexが効きませんでした。

解決方法: behavior: 'prepend'に変更することで、リンクが見出し要素の内部（最初の子要素）に配置されるようになり、Flexboxが正しく機能するようになりました。

// ❌ これだと見出しの外側に配置される
behavior: 'before'

// ✅ これで見出しの内部に配置される
behavior: 'prepend'

問題2: ハイドレーションエラーが発生する

リンクアイコンをクリックすると、以下のようなエラーが発生していました。

A tree hydrated but some attributes of the server rendered HTML didn't match the client properties.

原因を調べたところ、クライアント側で見出しのIDを上書きするAssignHeadingIdsコンポーネントが原因でした。rehypeSlugがサーバー側で生成したIDと、クライアント側で変更されたIDが一致しなかったのです。

解決方法: AssignHeadingIdsコンポーネントを削除し、TableOfContentsコンポーネントを修正して、DOMから実際の見出しIDを取得するようにしました。

useEffect(() => {
  // DOMから実際の見出し要素を取得してIDを取得（rehypeSlugが生成したIDを使用）
  const headings = Array.from(document.querySelectorAll('.article-content h2, .article-content h3')) as HTMLElement[]
  if (headings.length > 0) {
    const tocItems: TOCItem[] = headings.map((heading) => {
      const level = heading.tagName === 'H2' ? 2 : 3
      const text = heading.textContent?.trim() || ''
      const id = heading.id || '' // rehypeSlugが生成したIDをそのまま使用
      return { id, text, level }
    }).filter(item => item.id)
    setToc(tocItems)
  }
}, [content])

これで、サーバー側とクライアント側で同じIDが使用されるため、ハイドレーションエラーが解消されました。

実装のポイント

behavior: 'prepend'を使う: 見出しの内部にリンクを配置することで、Flexboxが正しく機能します。
Flexboxでレイアウト: 見出しをdisplay: flexにして、アイコンとテキストを同じ行に配置します。
ホバーで表示: opacity: 0で通常は非表示にし、ホバー時にopacity: 1で表示します。
IDの一貫性: サーバー側とクライアント側で同じIDを使用することで、ハイドレーションエラーを防ぎます。

まとめ

Qiita風の見出しアンカーリンクを実装するのは、思ったより簡単でした。rehype-autolink-headingsのbehaviorオプションを適切に設定し、Flexboxでレイアウトすることで、綺麗に動作するようになりました。

ハイドレーションエラーには少し悩まされましたが、サーバー側とクライアント側で同じIDを使用することで解決できました。同じような問題に遭遇した方の参考になれば幸いです。

もし、さらにカスタマイズしたい場合は、SVGアイコンのデザインを変更したり、アニメーションを追加したりすることもできます。ぜひ試してみてください！

Next.js + Resend APIでお問い合わせフォームを実装した話

Hama — Fri, 14 Nov 2025 01:20:53 +0000

はじめに

この記事では、Next.js（App Router）とResend APIを使用して、お問い合わせフォームを実装した過程をまとめます。フロントエンドのバリデーションから、バックエンドのメール送信、XSS対策、エラーハンドリングまで、実装の詳細を解説します。

実装の背景と目的

技術ブログに読者からのお問い合わせを受け付ける機能を追加したいと考えました。要件は以下の通りです：

名前、メールアドレス、メッセージを送信
メールで通知を受け取る
フロントエンドでバリデーション
XSS対策を実装
エラーハンドリングを適切に行う

Resend APIの選択理由

メール送信サービスとしてResendを選択した理由：

無料プランが充実: 月3,000通まで送信可能
シンプルなAPI: 実装が簡単
Next.jsとの相性: TypeScript対応、ドキュメントが充実
開発者フレンドリー: 無料プランでもonboarding@resend.devから送信可能

Resend APIの設定

1. アカウント作成とAPIキー取得

Resend にアクセスしてアカウントを作成
Dashboard → API Keys → Create API Key
表示されたAPIキーをコピー（一度しか表示されないため注意）

2. 環境変数の設定

ローカル開発環境（.env.local）

RESEND_API_KEY=re_xxxxxxxxxxxxx
CONTACT_EMAIL=your-email@example.com
RESEND_FROM_EMAIL=onboarding@resend.dev  # オプション（未設定時はデフォルト値を使用）

Vercel環境変数の設定

# Production環境
echo "your-resend-api-key" | vercel env add RESEND_API_KEY production
echo "your-email@example.com" | vercel env add CONTACT_EMAIL production

# Preview環境
echo "your-resend-api-key" | vercel env add RESEND_API_KEY preview
echo "your-email@example.com" | vercel env add CONTACT_EMAIL preview

# Development環境
echo "your-resend-api-key" | vercel env add RESEND_API_KEY development
echo "your-email@example.com" | vercel env add CONTACT_EMAIL development

3. Resendパッケージのインストール

npm install resend

実装の詳細

フロントエンド（ContactForm.tsx）

コンポーネントの構造

'use client'

import { useState } from 'react'
import { Button } from '@/components/ui/button'
import { Input } from '@/components/ui/input'
import { Card, CardContent, CardDescription, CardHeader, CardTitle } from '@/components/ui/card'
import { Send, Loader2 } from 'lucide-react'

export function ContactForm() {
  const [formData, setFormData] = useState({
    name: '',
    email: '',
    message: '',
  })
  const [isSubmitting, setIsSubmitting] = useState(false)
  const [submitStatus, setSubmitStatus] = useState<'idle' | 'success' | 'error'>('idle')
  const [emailError, setEmailError] = useState<string>('')

  // メールアドレスのバリデーション（APIと同じロジック）
  const isValidEmail = (email: string): boolean => {
    const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/
    return emailRegex.test(email)
  }

  const handleEmailChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    const value = e.target.value
    setFormData({ ...formData, email: value })

    // リアルタイムバリデーション（入力中はエラーをクリア）
    if (emailError && value) {
      setEmailError('')
    }
  }

  const handleSubmit = async (e: React.FormEvent) => {
    e.preventDefault()

    // メールアドレスのバリデーション
    if (!isValidEmail(formData.email)) {
      setEmailError('正しいメールアドレスを入力してください（例: example@email.com）')
      return
    }

    setEmailError('')
    setIsSubmitting(true)
    setSubmitStatus('idle')

    try {
      const response = await fetch('/api/contact', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
        },
        body: JSON.stringify(formData),
      })

      if (response.ok) {
        setSubmitStatus('success')
        setFormData({ name: '', email: '', message: '' })
        setEmailError('')
      } else {
        const data = await response.json().catch(() => ({}))
        if (data.error === 'Invalid email address') {
          setEmailError('正しいメールアドレスを入力してください（例: example@email.com）')
        }
        setSubmitStatus('error')
      }
    } catch (error) {
      console.error('Failed to submit contact form:', error)
      setSubmitStatus('error')
    } finally {
      setIsSubmitting(false)
    }
  }

  return (
    <Card>
      <CardHeader>
        <CardTitle>お問い合わせ</CardTitle>
        <CardDescription>
          ご質問やご要望がございましたら、お気軽にお問い合わせください
        </CardDescription>
      </CardHeader>
      <CardContent>
        <form onSubmit={handleSubmit} className="space-y-4">
          {/* フォームフィールド */}
        </form>
      </CardContent>
    </Card>
  )
}

メールアドレスバリデーション

フロントエンドでメールアドレスのバリデーションを実装し、ユーザーに即座にフィードバックを提供します：

// メールアドレスのバリデーション（APIと同じロジック）
const isValidEmail = (email: string): boolean => {
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/
  return emailRegex.test(email)
}

// エラーメッセージの表示
{emailError && (
  <p className="mt-1 text-sm text-red-600">{emailError}</p>
)}

バックエンド（/api/contact）

API Routeの実装

import { NextRequest, NextResponse } from 'next/server'
import { Resend } from 'resend'

export async function POST(request: NextRequest) {
  try {
    const body = await request.json()
    const { name, email, message } = body

    // バリデーション
    if (!name || !email || !message) {
      return NextResponse.json(
        { error: 'All fields are required' },
        { status: 400 }
      )
    }

    if (!isValidEmail(email)) {
      return NextResponse.json(
        { error: 'Invalid email address' },
        { status: 400 }
      )
    }

    // Resend APIキーの確認
    const resendApiKey = process.env.RESEND_API_KEY
    const contactEmail = process.env.CONTACT_EMAIL

    if (!resendApiKey || !contactEmail) {
      // 開発環境ではログ出力のみ、本番環境ではエラーを返す
      if (process.env.NODE_ENV === 'production') {
        return NextResponse.json(
          { error: 'Email service is not configured' },
          { status: 500 }
        )
      }
      console.log('Contact form submission (dev mode):', { name, email, message })
      return NextResponse.json({
        success: true,
        message: 'Contact form submitted successfully (dev mode - email not sent)',
      })
    }

    // メール送信
    const resend = new Resend(resendApiKey)

    // HTMLエスケープ（XSS対策）
    const escapeHtml = (text: string) => {
      return text
        .replace(/&/g, '&amp;')
        .replace(/</g, '&lt;')
        .replace(/>/g, '&gt;')
        .replace(/"/g, '&quot;')
        .replace(/'/g, '&#039;')
    }

    const escapedName = escapeHtml(name)
    const escapedEmail = escapeHtml(email)
    const escapedMessage = escapeHtml(message).replace(/\n/g, '<br>')

    // 送信元メールアドレス（環境変数で設定可能）
    const fromEmail = process.env.RESEND_FROM_EMAIL || 'onboarding@resend.dev'

    const emailResult = await resend.emails.send({
      from: fromEmail,
      to: contactEmail,
      replyTo: email, // 返信先を送信者のメールアドレスに設定
      subject: `お問い合わせ: ${escapedName}`,
      html: `
        <h2>お問い合わせ内容</h2>
        <p><strong>名前:</strong> ${escapedName}</p>
        <p><strong>メール:</strong> ${escapedEmail}</p>
        <p><strong>メッセージ:</strong></p>
        <p>${escapedMessage}</p>
        <hr>
        <p style="color: #666; font-size: 12px;">
          このメールは <a href="https://beachone1155.vercel.app/contact">beachone1155 Engineer Blog</a> のお問い合わせフォームから送信されました。
        </p>
      `,
    })

    if (emailResult.error) {
      console.error('Resend API error:', emailResult.error)
      return NextResponse.json(
        { error: 'Failed to send email' },
        { status: 500 }
      )
    }

    console.log('Contact form email sent successfully:', emailResult.data?.id)

    return NextResponse.json({
      success: true,
      message: 'Contact form submitted successfully',
    })
  } catch (error) {
    console.error('Contact form error:', error)
    return NextResponse.json(
      { error: 'Internal server error' },
      { status: 500 }
    )
  }
}

function isValidEmail(email: string): boolean {
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/
  return emailRegex.test(email)
}

XSS対策（HTMLエスケープ）

ユーザー入力のHTMLタグをエスケープして、XSS攻撃を防ぎます：

const escapeHtml = (text: string) => {
  return text
    .replace(/&/g, '&amp;')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;')
    .replace(/'/g, '&#039;')
}

// 使用例
const escapedName = escapeHtml(name)
const escapedMessage = escapeHtml(message).replace(/\n/g, '<br>')

これにより、<script>alert('XSS')</script>のような入力も安全に処理されます。

エラーハンドリング

フロントエンド

// 送信成功時
{submitStatus === 'success' && (
  <div className="p-3 bg-green-50 border border-green-200 rounded-md text-green-800 text-sm">
    お問い合わせありがとうございます。正常に送信されました。
  </div>
)}

// 送信失敗時
{submitStatus === 'error' && (
  <div className="p-3 bg-red-50 border border-red-200 rounded-md text-red-800 text-sm">
    送信に失敗しました。しばらく時間をおいて再度お試しください。
  </div>
)}

バックエンド

環境変数未設定時の処理（開発環境ではログ出力のみ）
Resend APIエラー時の処理
ネットワークエラー時の処理

テスト項目と確認事項

1. 基本動作の確認

✅ フォーム送信が正常に動作するか
✅ メールが正しく送信されるか
✅ 送信成功メッセージが表示されるか

2. バリデーションの確認

✅ 空のフィールドで送信 → エラー表示
✅ 不正なメールアドレス（a@aなど） → エラー表示
✅ 正しいメールアドレス → 送信成功

3. XSS対策の確認

✅ <script>タグを含む入力 → エスケープされる
✅ HTMLタグを含む入力 → エスケープされる
✅ 特殊文字（&, <, >, ", '） → エスケープされる

4. エラーハンドリングの確認

✅ ネットワークエラー時の処理
✅ Resend APIエラー時の処理
✅ 環境変数未設定時の処理

5. 本番環境での確認

✅ Vercel環境変数が正しく設定されているか
✅ 本番環境でメール送信が正常に動作するか
✅ エラーログが適切に記録されるか

今後の改善点

1. 独自ドメインの設定

現在はonboarding@resend.devを使用していますが、独自ドメインを設定することで：

送信元の信頼性が向上
ブランドの一貫性が保たれる
メールの到達率が向上する可能性

設定方法：

Resend Dashboardでドメインを追加
DNSレコードを設定（SPF、DKIM、CNAME）
環境変数RESEND_FROM_EMAILに設定（例: contact@yourdomain.com）

2. レート制限の実装

スパム対策として、レート制限を実装することを検討：

// IPアドレスベースのレート制限
const rateLimit = new Map<string, number>()

const checkRateLimit = (ip: string): boolean => {
  const now = Date.now()
  const lastRequest = rateLimit.get(ip) || 0
  const timeDiff = now - lastRequest

  if (timeDiff < 60000) { // 1分以内
    return false
  }

  rateLimit.set(ip, now)
  return true
}

3. reCAPTCHAの追加

ボット対策として、Google reCAPTCHAを追加することも検討できます。

4. メールテンプレートの改善

現在のHTMLメールを、より洗練されたテンプレートに改善することも可能です。

まとめ

Next.jsとResend APIを使用して、お問い合わせフォームを実装しました。主なポイントは以下の通りです：

フロントエンド: リアルタイムバリデーション、エラーメッセージ表示
バックエンド: Resend APIを使用したメール送信、XSS対策
エラーハンドリング: 適切なエラーメッセージとログ記録
セキュリティ: HTMLエスケープによるXSS対策

無料プランでも十分に使える実装となっており、個人ブログや小規模なサイトに適しています。同様の機能を実装する際の参考になれば幸いです。

参考リンク

Google AdSense「有用性の低いコンテンツ」審査対応の記録

Hama — Fri, 14 Nov 2025 01:20:50 +0000

はじめに

この記事では、Google AdSenseの審査で「有用性の低いコンテンツ」という理由で不合格になった際の対応記録をまとめます。技術ブログを運営している方で、同様の問題に直面している方の参考になれば幸いです。

問題の発覚

Google AdSenseの審査を申請したところ、以下の理由で不合格になりました：

有用性の低いコンテンツ

お客様のサイトは、弊社の定めるサイト運営者ネットワークのご利用要件を満たしていないと判断されました。

審査時のサイト状況

公開記事数: 12件
一部の記事が短い（360語、247語、101語など）
Aboutページが存在しない
サイトの目的や価値提案が不明確
ナビゲーションが不十分

実施した対応

1. Aboutページの追加

サイトの目的、著者情報、価値提案を明確にするため、Aboutページを追加しました。

実装内容

src/app/about/page.tsx を作成し、以下の情報を記載：

著者情報: 経歴、スキル、専門分野
サイトの目的: 技術ブログとしての役割と価値
サイトの特徴: マルチプラットフォーム自動投稿、実践的なコンテンツなど
お問い合わせ: 連絡先情報

効果

サイトの目的が明確になり、読者への価値提案が伝わりやすくなった
著者情報の公開により、サイトの信頼性が向上
Googleのクローラーがサイトの内容を理解しやすくなった

2. ナビゲーションの改善

ユーザーがサイトを理解しやすくするため、ナビゲーションを改善しました。

ヘッダーの改善

Aboutページへのリンクを追加
主要ページへのアクセスを容易に

フッターの改善

フッターに主要ページへのリンクを追加し、サイトマップ的な役割を持たせました：

ホーム
ブログ
このサイトについて
タグ一覧
ポートフォリオ
お問い合わせ
プライバシーポリシー
免責事項

効果

ユーザーがサイト全体を把握しやすくなった
クローラーがサイト構造を理解しやすくなった
ユーザーエクスペリエンスが向上

3. コンテンツの充実

短い記事の内容を拡充し、最低500語以上になるように調整しました。

対象記事

以下の記事を拡充：

vercel-neon-branch-limit.md (360語 → 拡充)
platform-hosted-images-automation.md (247語 → 拡充)
hatena-automation.md (101語 → 拡充)

拡充内容

各記事に以下を追加：

実装の詳細な説明: コード例と実装方法
エラーハンドリング: エラー時の対処法
トラブルシューティング: よくある問題と解決方法
参考情報: 関連リンクとドキュメント

効果

記事の有用性が向上
読者にとってより価値のあるコンテンツに
検索エンジンでの評価が向上する可能性

4. メタ情報の改善

SEOとサイトの信頼性向上のため、メタ情報を充実させました。

改善内容

src/app/layout.tsx のメタ情報を充実：

description: より詳細な説明に変更
keywords: 技術スタック、プラットフォーム名などを追加
Open Graph: タイトル、説明、画像を充実
Twitter Card: カード情報を充実
metadataBase: ベースURLを設定

改善前

description: 'エンジニアの技術ブログ - 自動化、開発、学習記録',
keywords: ['エンジニア', '技術ブログ', 'プログラミング', '自動化', '開発'],

改善後

description: 'エンジニアの技術ブログ。Next.js、TypeScript、Pythonを使用した実践的な開発ノウハウ、GitHub Actionsによる自動化、マルチプラットフォーム投稿システムの構築方法などを発信しています。',
keywords: [
  'エンジニア', '技術ブログ', 'プログラミング', '自動化', '開発',
  'Next.js', 'TypeScript', 'Python', 'FastAPI', 'PostgreSQL',
  'GitHub Actions', 'Vercel', 'AWS', 'Qiita', 'Zenn', 'DEV.to',
  'はてなブログ', 'マルチ投稿', 'CI/CD', 'フルスタック開発',
],

効果

検索エンジンがサイトの内容を理解しやすくなった
SNSでのシェア時に適切な情報が表示されるようになった
サイトの専門性が明確になった

Google AdSenseの要件

最小コンテンツ要件

Google AdSenseでは、以下の要件を満たす必要があります：

独自性のある質の高いコンテンツ
- オリジナルのコンテンツであること
- 読者にとって価値のある情報であること
十分なコンテンツ量
- 各ページに十分なコンテンツがあること
- 短すぎる記事は避ける（最低500語程度を推奨）
明確なサイト構造
- ナビゲーションが明確であること
- サイトの目的が明確であること
著者情報の公開
- サイトの運営者情報が明確であること
- Aboutページなどで情報を公開すること

参考リンク

実装の詳細

Aboutページの実装

// src/app/about/page.tsx
import Container from '@/components/Container'
import Breadcrumb from '@/components/Breadcrumb'
// ... その他のインポート

export default function AboutPage() {
  return (
    <Container className="py-8">
      <Breadcrumb items={[{ label: 'このサイトについて' }]} />

      <div className="max-w-4xl mx-auto">
        {/* サイトの目的 */}
        <div className="mb-12">
          <h1 className="text-4xl font-bold mb-6">このサイトについて</h1>
          <p className="text-lg text-muted-foreground mb-8">
            beachone1155 Engineer Blogは、エンジニアの技術ブログとして、
            実践的な開発ノウハウ、自動化の知見、学習記録を発信しています。
          </p>
        </div>

        {/* 著者情報 */}
        <Card className="mb-12">
          <CardHeader>
            <CardTitle>著者について</CardTitle>
          </CardHeader>
          <CardContent>
            {/* 著者情報の内容 */}
          </CardContent>
        </Card>
      </div>
    </Container>
  )
}

フッターの改善

// src/components/Footer.tsx
export default function Footer() {
  return (
    <footer className="border-t border-gray-200 bg-gray-50 dark:bg-gray-900 mt-16">
      <div className="max-w-5xl mx-auto px-4 py-8">
        <div className="grid grid-cols-1 md:grid-cols-3 gap-8 mb-8">
          {/* サイト情報 */}
          <div>
            <h3 className="font-semibold text-foreground mb-4">
              beachone1155 Engineer Blog
            </h3>
            <p className="text-sm text-muted-foreground">
              エンジニアの技術ブログ。自動化、開発、学習記録を発信しています。
            </p>
          </div>

          {/* ナビゲーション */}
          <div>
            <h3 className="font-semibold text-foreground mb-4">ナビゲーション</h3>
            <ul className="space-y-2 text-sm">
              <li><Link href="/">ホーム</Link></li>
              <li><Link href="/blog">ブログ</Link></li>
              <li><Link href="/about">このサイトについて</Link></li>
              {/* その他のリンク */}
            </ul>
          </div>
        </div>
      </div>
    </footer>
  )
}

結果と今後の対応

実施後の状態

✅ Aboutページを追加
✅ ナビゲーションを改善
✅ 短い記事を拡充（最低500語以上）
✅ メタ情報を充実

次のステップ

AdSenseの再審査を申請
- 変更をデプロイ後、AdSenseの審査を再申請
- 審査結果を確認
コンテンツの継続的な改善
- 定期的に記事を追加
- 既存記事の内容を充実
- 読者のフィードバックを反映
SEOの最適化
- 構造化データの追加を検討
- サイトマップの最適化
- パフォーマンスの改善

まとめ

Google AdSenseの「有用性の低いコンテンツ」問題に対応するため、以下の改善を実施しました：

Aboutページの追加: サイトの目的と価値提案を明確化
ナビゲーションの改善: ユーザーがサイトを理解しやすく
コンテンツの充実: 短い記事を拡充して有用性を向上
メタ情報の改善: SEOとサイトの信頼性を向上

これらの対応により、サイトの有用性が向上し、AdSenseの審査要件を満たすことができました。同様の問題に直面している方は、参考にしていただければ幸いです。

参考リンク

はてなブログへの自動投稿に対応した（GitHub Actions + AtomPub API）

Hama — Thu, 06 Nov 2025 02:53:34 +0000

追加内容の概要

本ブログの自動配信パイプライン（Qiita/Dev.to/Zenn/X）に、はてなブログへの自動投稿機能を追加しました。

はてなブログ: AtomPub API（WSSE認証）で投稿

Frontmatter の publish_on に hatena を書くだけで配信対象になります。

実装ポイント

scripts/publish.mjs
- publishToHatena(post) を追加（AtomEntry XML + X-WSSE認証）
- main() に hatena を統合（X以外は並列処理）
.github/workflows/publish.yml
- Hatena ステップを追加
バリデーション/型に hatena を追加

使い方

/content/YYYY/MM/slug.md の Frontmatter で配信先を指定します。

publish_on: ["hatena"]

GitHub に push すると、Actions が記事を配信します。ローカルでは PUBLISH_TARGETS=hatena node scripts/publish.mjs のように個別実行も可能です。

補足

note への自動投稿も検討しましたが、公式APIが存在せず、非公式APIも投稿機能が不明確なため、今回は実装を見送りました。はてなブログは公式のAtomPub APIが提供されているため、安定して自動投稿できます。

R2E APIをAWSに移行するプラン：Render + Vercel + Neon から AWS への移行戦略

Hama — Tue, 04 Nov 2025 08:23:15 +0000

はじめに

以前の記事でR2E（Research→Experience）API を Render（FastAPI）+ Vercel（Next.js）+ Neon（PostgreSQL/pgvector）の構成で公開していました。しかし無料枠の制約やコールドスタートで初回 30〜60 秒かかる体験は、プロダクション運用には耐えません。そこで、私は本番運用を見据えて、同機能を AWS へ段階的に移行する 計画を立てました。本稿は、私がこの移行で採用する構成、具体的な手順、運用の要点をまとめたプランです。

現在の構成の整理

現在の構成は以下の通りです：

フロントエンド

Next.js on Vercel: ブログサイトと /portfolio/r2e のデモUI
API Route: /api/r2e/[...path] でバックエンドにプロキシ

バックエンド

FastAPI on Render: Docker コンテナでデプロイ
URL: https://research-to-experience-api.onrender.com
コールドスタート: 15分間アクセスがないとスリープ、初回起動に30〜60秒

データベース

Neon PostgreSQL: クラウド PostgreSQL（pgvector 拡張対応）
ベクトル次元: 1536（OpenAI text-embedding-3-small 対応）

課題

Render 無料枠のコールドスタート問題（30〜60秒の待機）
スケーラビリティの制限
監視・ログ機能の不足
データベースとアプリケーションの分離（Neon は別サービス）

AWS移行の目的とメリット

メリット

コールドスタートの解消: ECS Fargate は常時起動可能（コストとトレードオフ）
スケーラビリティ: オートスケーリング対応
統合監視: CloudWatch でログ・メトリクスを一元管理
セキュリティ: VPC 内でリソースを分離、Secrets Manager で機密情報管理
高可用性: マルチAZ対応、自動バックアップ

デメリット・考慮事項

コスト: 無料枠から月額約 $80-120 へ（小規模運用）
運用複雑度: インフラ管理の知識が必要
セットアップ工数: 初期構築に時間がかかる

私が採用するAWS構成

フロントエンド

フロントエンドは AWS Amplify を第一候補として採用します。Next.js の SSR/SSG をサポートし、GitHub 連携で CI/CD と環境変数管理が一か所にまとまります。もし SSR が不要なページのみを分離できる場合は、コスト最適化のために S3 静的ホスティング + CloudFront に切り替えるオプションも用意します（本計画では Amplify を本線、S3 + CloudFront を代替案として維持）。

バックエンド

アプリケーション層は ECS Fargate + ALB に移行します。既存の Dockerfile を無変更で使え、常時起動でコールドスタートを排除できます。スケーリングは CPU/メモリのターゲット追跡で運用し、最初は 1 タスク常時起動、負荷に応じて最大 5 までの自動拡張を設定します。将来的に構成簡素化が必要になれば App Runner への置き換え、超低トラフィック帯では Lambda 実行（ただし本APIの性質上は非本命）も検討余地として残します。

データベース

データ層は RDS for PostgreSQL 15+（pgvector有効） を採用します。自動バックアップとマルチAZで可用性を確保しつつ、Neon から pg_dump/pg_restore で段階移行します。Aurora Serverless v2 は将来のコスト最適化候補として調査継続に留めます。

その他のAWSサービス

VPC（パブリック/プライベート分離）
ALB（HTTPS終端 + 負荷分散）
ECR（Dockerイメージ保管）
CloudWatch（ログ/メトリクス/アラーム）
Secrets Manager（DATABASE_URL/OPENAI_API_KEY を安全管理）
NAT Gateway（OpenAI/arXiv への外部アクセス）

AWS移行後のアーキテクチャ

全体構成

データフロー

クエリ受信: Amplify（または CloudFront+S3）→ Next.js API Route → ALB → ECS Fargate
論文取得: ECS Fargate → NAT Gateway → arXiv
埋め込み生成: ECS Fargate → NAT Gateway → OpenAI API
ベクトル検索: ECS Fargate → RDS PostgreSQL (pgvector)
要約生成: ECS Fargate → NAT Gateway → OpenAI API
レスポンス返却: ECS Fargate → ALB → API Route → フロントエンド

移行手順（詳細）

ステップ1: データベース移行（RDS作成）

1-1. RDS for PostgreSQL インスタンス作成

# AWS CLI での作成例（コンソールでも可）
aws rds create-db-instance \
  --db-instance-identifier r2e-postgres \
  --db-instance-class db.t3.micro \
  --engine postgres \
  --engine-version 15.4 \
  --master-username postgres \
  --master-user-password <PASSWORD> \
  --allocated-storage 20 \
  --storage-type gp3 \
  --vpc-security-group-ids sg-xxx \
  --db-subnet-group-name r2e-db-subnet-group \
  --backup-retention-period 7 \
  --multi-az \
  --publicly-accessible false

パラメータグループ設定:

パラメータグループを作成（r2e-pg-params）
shared_preload_libraries に vector を追加
インスタンスにパラメータグループを適用

-- パラメータグループ設定後、RDSに接続して拡張を有効化
CREATE EXTENSION IF NOT EXISTS vector;

1-2. Neon から RDS へのデータ移行

# 1. Neon からダンプ取得
pg_dump -h ep-xxx.region.neon.tech -U user -d dbname \
  --no-owner --no-acl -F c -f r2e_backup.dump

# 2. RDS にリストア
pg_restore -h r2e-postgres.xxx.rds.amazonaws.com \
  -U postgres -d postgres \
  --no-owner --no-acl r2e_backup.dump

ダウンタイム最小化:

メンテナンスウィンドウで実施
または、レプリケーション設定（より複雑）

ステップ2: バックエンド移行（ECS Fargate）

2-1. ECR に Docker イメージをプッシュ

# ECR リポジトリ作成
aws ecr create-repository --repository-name r2e-api

# ログイン
aws ecr get-login-password --region ap-northeast-1 | \
  docker login --username AWS --password-stdin <ACCOUNT_ID>.dkr.ecr.ap-northeast-1.amazonaws.com

# イメージビルド
docker build -t r2e-api .

# タグ付け・プッシュ
docker tag r2e-api:latest <ACCOUNT_ID>.dkr.ecr.ap-northeast-1.amazonaws.com/r2e-api:latest
docker push <ACCOUNT_ID>.dkr.ecr.ap-northeast-1.amazonaws.com/r2e-api:latest

2-2. ECS クラスター・タスク定義作成

タスク定義 (task-definition.json):

{
  "family": "r2e-api",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "containerDefinitions": [
    {
      "name": "r2e-api",
      "image": "<ACCOUNT_ID>.dkr.ecr.ap-northeast-1.amazonaws.com/r2e-api:latest",
      "portMappings": [
        {
          "containerPort": 8000,
          "protocol": "tcp"
        }
      ],
      "environment": [],
      "secrets": [
        {
          "name": "DATABASE_URL",
          "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:<ACCOUNT_ID>:secret:r2e/database-url"
        },
        {
          "name": "OPENAI_API_KEY",
          "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:<ACCOUNT_ID>:secret:r2e/openai-api-key"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/r2e-api",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

# タスク定義登録
aws ecs register-task-definition --cli-input-json file://task-definition.json

2-3. ALB 作成とターゲットグループ設定

# ALB 作成
aws elbv2 create-load-balancer \
  --name r2e-api-alb \
  --subnets subnet-xxx subnet-yyy \
  --security-groups sg-alb-xxx

# ターゲットグループ作成
aws elbv2 create-target-group \
  --name r2e-api-tg \
  --protocol HTTP \
  --port 8000 \
  --vpc-id vpc-xxx \
  --target-type ip \
  --health-check-path /health

# リスナー作成
aws elbv2 create-listener \
  --load-balancer-arn <ALB_ARN> \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn=<CERT_ARN> \
  --default-actions Type=forward,TargetGroupArn=<TG_ARN>

2-4. ECS サービス作成

aws ecs create-service \
  --cluster r2e-cluster \
  --service-name r2e-api-service \
  --task-definition r2e-api \
  --desired-count 1 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-xxx],securityGroups=[sg-xxx],assignPublicIp=DISABLED}" \
  --load-balancers "targetGroupArn=<TG_ARN>,containerName=r2e-api,containerPort=8000"

ステップ3: フロントエンド（Amplify もしくは S3+CloudFront）

本番運用では Amplify を使います。SSRが不要なページのみ切り出す場合は S3+CloudFront で静的ホスティングに置き換えます。

Amplify の設定:

# Vercel 環境変数更新
vercel env rm BACKEND_URL production
echo -n "https://r2e-api-alb-xxx.ap-northeast-1.elb.amazonaws.com" | \
  vercel env add BACKEND_URL production

# Amplify プロジェクト作成
amplify init

# 環境変数設定（Console でも可）
amplify env add
# BACKEND_URL=https://r2e-api-alb-xxx.ap-northeast-1.elb.amazonaws.com

S3+CloudFront 案（静的配信）:

# S3 バケット作成（静的ホスティング）
aws s3 mb s3://r2e-frontend-bucket
aws s3 website s3://r2e-frontend-bucket --index-document index.html --error-document 404.html

# CloudFront ディストリビューション作成
aws cloudfront create-distribution --origin-domain-name r2e-frontend-bucket.s3.amazonaws.com

ステップ4: ネットワーク設定（VPC）

4-1. VPC 作成（既存のVPCを使用する場合はスキップ）

# VPC作成
aws ec2 create-vpc --cidr-block 10.0.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=r2e-vpc}]'

# パブリックサブネット作成
aws ec2 create-subnet \
  --vpc-id vpc-xxx \
  --cidr-block 10.0.1.0/24 \
  --availability-zone ap-northeast-1a

# プライベートサブネット作成
aws ec2 create-subnet \
  --vpc-id vpc-xxx \
  --cidr-block 10.0.2.0/24 \
  --availability-zone ap-northeast-1a

4-2. インターネットゲートウェイ・NAT Gateway 設定

# インターネットゲートウェイ作成・アタッチ
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --internet-gateway-id igw-xxx --vpc-id vpc-xxx

# パブリックサブネットのルートテーブル設定
aws ec2 create-route --route-table-id rtb-xxx --destination-cidr-block 0.0.0.0/0 --gateway-id igw-xxx

# NAT Gateway 作成（Elastic IP 必要）
aws ec2 allocate-address --domain vpc
aws ec2 create-nat-gateway \
  --subnet-id subnet-public-xxx \
  --allocation-id eipalloc-xxx

# プライベートサブネットのルートテーブル設定
aws ec2 create-route --route-table-id rtb-private-xxx --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-xxx

4-3. セキュリティグループ設定

# ALB セキュリティグループ（HTTP/HTTPS 許可）
aws ec2 create-security-group \
  --group-name r2e-alb-sg \
  --description "R2E API ALB Security Group" \
  --vpc-id vpc-xxx

# ECS セキュリティグループ（ALBからのみ許可、NAT Gateway経由で外部アクセス）
aws ec2 create-security-group \
  --group-name r2e-ecs-sg \
  --description "R2E API ECS Security Group" \
  --vpc-id vpc-xxx

# RDS セキュリティグループ（ECSからのみ許可）
aws ec2 create-security-group \
  --group-name r2e-rds-sg \
  --description "R2E API RDS Security Group" \
  --vpc-id vpc-xxx

ステップ5: Secrets Manager 設定

# データベース接続文字列
aws secretsmanager create-secret \
  --name r2e/database-url \
  --secret-string "postgresql://user:pass@r2e-postgres.xxx.rds.amazonaws.com:5432/dbname"

# OpenAI API キー
aws secretsmanager create-secret \
  --name r2e/openai-api-key \
  --secret-string "sk-..."

コスト比較

Render + Neon（現在の構成）

Render: 無料枠（制限あり）
Neon: 無料枠（制限あり）
合計: $0/月（制限内）

AWS移行後（小規模運用）

サービス	月額コスト目安	備考
RDS (db.t3.micro)	$15-30	無料枠なし
ECS Fargate (0.5 vCPU, 1GB)	$10-20	常時起動
ALB	$16	固定
NAT Gateway	$32	固定
CloudWatch Logs	$2-5	使用量ベース
データ転送	$1-5	少量
合計	約 $80-120/月

コスト最適化のヒント

ECS Fargate のスケールダウン: 夜間は desired-count を 0 に（ただしコールドスタート発生）
NAT Gateway の代替: NAT Instance（EC2 t3.micro）で約 $7/月（運用コスト増）
RDS の停止: 開発環境のみ、停止可能（ただし起動に時間がかかる）

ハマりポイントと対応

1. pgvector 拡張のインストール

問題: RDS のパラメータグループで shared_preload_libraries を設定しても、拡張が有効にならない。

対応:

パラメータグループ作成時に vector を追加
インスタンス再起動が必要（パラメータ変更反映のため）
接続後に CREATE EXTENSION vector; を実行

-- 確認
SELECT * FROM pg_extension WHERE extname = 'vector';

2. VPC 内からの外部APIアクセス

問題: プライベートサブネットの ECS タスクから OpenAI API にアクセスできない。

対応:

NAT Gateway 必須: プライベートサブネットからインターネットへのルーティング
セキュリティグループでアウトバウンド HTTPS (443) を許可
コストが高いため、開発環境では NAT Instance を検討

3. ECS タスクのヘルスチェック失敗

問題: ALB のヘルスチェックが失敗し、タスクが起動しない。

対応:

ヘルスチェックパス: /health を返すエンドポイントを実装
ヘルスチェック間隔: 30秒（デフォルト）
タイムアウト: 5秒（デフォルト）
成功閾値: 2回（デフォルト）

# FastAPI のヘルスチェック実装例
@app.get("/health")
async def health():
    return {"status": "healthy"}

4. Secrets Manager の IAM 権限不足

問題: ECS タスクが Secrets Manager から値を取得できない。

対応:

ECS タスク実行ロールに SecretsManagerReadWrite ポリシーをアタッチ
または、最小権限ポリシー:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": [
        "arn:aws:secretsmanager:ap-northeast-1:<ACCOUNT_ID>:secret:r2e/*"
      ]
    }
  ]
}

5. RDS への接続タイムアウト

問題: ECS タスクから RDS に接続できない。

対応:

セキュリティグループで RDS のポート（5432）を許可
サブネットグループが正しく設定されているか確認
publicly-accessible は false に設定（プライベートサブネット経由）

監視・運用

CloudWatch Logs 設定

ECS タスクのログは自動的に CloudWatch Logs に送信されます（タスク定義で設定済み）。

# ロググループ確認
aws logs describe-log-groups --log-group-name-prefix /ecs/r2e-api

# ログストリーム確認
aws logs describe-log-streams --log-group-name /ecs/r2e-api

CloudWatch Metrics 設定

ECS メトリクス:

CPUUtilization: CPU 使用率
MemoryUtilization: メモリ使用率
RunningTaskCount: 実行中のタスク数

RDS メトリクス:

CPUUtilization: CPU 使用率
DatabaseConnections: データベース接続数
FreeableMemory: 利用可能メモリ

アラーム設定

# ECS CPU 使用率アラーム（80%超過）
aws cloudwatch put-metric-alarm \
  --alarm-name r2e-ecs-high-cpu \
  --alarm-description "ECS CPU utilization exceeds 80%" \
  --metric-name CPUUtilization \
  --namespace AWS/ECS \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold

オートスケーリング設定

# ターゲット追跡スケーリングポリシー
aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/r2e-cluster/r2e-api-service \
  --min-capacity 1 \
  --max-capacity 5

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/r2e-cluster/r2e-api-service \
  --policy-name r2e-cpu-scaling \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    }
  }'

まとめ

移行のメリット

コールドスタート解消: 常時起動で即座に応答
スケーラビリティ: オートスケーリングで負荷に対応
統合監視: CloudWatch でログ・メトリクスを一元管理
セキュリティ強化: VPC 内でリソース分離、Secrets Manager で機密情報管理
高可用性: マルチAZ対応、自動バックアップ

コスト vs 機能のトレードオフ

無料枠（Render + Neon）: 制限あり、コールドスタートあり
AWS移行（$80-120/月）: 制限なし、コールドスタートなし、高可用性

小規模運用では Render + Neon でも十分ですが、本格運用やスケールアップを想定する場合は AWS 移行を検討すべきです。

段階的移行

フェーズ1: RDS のみ移行（Neon → RDS）
フェーズ2: バックエンド移行（Render → ECS Fargate）
フェーズ3: フロントエンド移行（Vercel → Amplify、オプション）

各フェーズで動作確認を行い、問題があればロールバック可能にすることが重要です。

次のステップ

Terraform/CDK 化: インフラをコード化して再現性を確保
CI/CD パイプライン: GitHub Actions で自動デプロイ
コスト最適化: リザーブドインスタンス、Spot インスタンスの検討
マルチリージョン: 高可用性のための複数リージョン展開

AWS 移行は工数がかかりますが、長期的な運用を考えると投資価値があります。段階的に移行を進め、各ステップで動作確認を行います。

参考リンク

Vercel統合Neonでブランチ制限に達した話と対処方法

Hama — Mon, 03 Nov 2025 02:32:13 +0000

問題の発覚

Vercelでプレビューデプロイを実行したところ、以下のエラーが発生しました：

engineer_blog_comments: Create database branch for deployment

Branch limit reached. Upgrade your plan or delete unused branches.

Neonの無料プランでは、データベースブランチが最大10個までという制限があり、それに達してしまったようです。

原因の調査

Vercel統合Neonの動作

VercelとNeonを統合すると、デフォルトで以下のような動作になります：

Production環境（本番）: メインのデータベースブランチを使用
Preview環境（プレビュー）: 各プレビューデプロイごとに新しいブランチを自動作成

つまり、PRを作成するたび、またはプレビューデプロイのたびに、Neon側で新しいデータベースブランチが作成されます。

なぜブランチが増えるのか

新しいPRを作成 → プレビューデプロイ実行
Vercelが自動的にNeonブランチを生成（例: preview/feature/r2e-frontend）
PRをマージしてもブランチは残る
新しいPRを複数作成 → ブランチが増え続ける
10個に達するとエラー

対処方法: 固定プレビューブランチを使用

すべてのプレビューデプロイで同じ固定ブランチを使用するように設定することで、新しいブランチが作成されなくなります。

設定手順

1. Neon Consoleで固定ブランチを作成

Neon Consoleにアクセス
プロジェクト「engineer_blog_comments」を選択
左サイドバーの「Branches」をクリック
「Create Branch」をクリック
ブランチ名: preview（任意の名前でOK）
「Branch from」: mainを選択
作成ボタンをクリック

2. 固定ブランチの接続文字列を取得

作成したブランチを選択し、Connection DetailsからPOSTGRES_URLをコピーします。

postgresql://user:pass@ep-xxx-pooler.region.neon.tech/neondb?sslmode=require

3. Vercel CLIで環境変数を設定

Preview環境とDevelopment環境に、固定ブランチのPOSTGRES_URLを設定します：

# Preview環境に設定
echo "固定ブランチのPOSTGRES_URL" | vercel env add POSTGRES_URL preview

# Development環境にも設定（ローカル開発用）
echo "固定ブランチのPOSTGRES_URL" | vercel env add POSTGRES_URL development

これにより：

✅ Production環境: 本番データベース（mainブランチ）を使用
✅ Preview環境: 固定プレビューブランチを使用（新しいブランチは作成されない）
✅ Development環境: 固定プレビューブランチを使用

設定の確認

環境変数が正しく設定されたか確認：

vercel env ls | grep POSTGRES_URL

出力例：

POSTGRES_URL       Encrypted           Development         X ago
POSTGRES_URL       Encrypted           Preview              X ago

重要: Production環境にはPOSTGRES_URLを設定しないことで、本番データベースが使用されます。

既存の未使用ブランチの削除

既に10個に達している場合は、未使用のブランチを削除する必要があります。

Neon Consoleでの削除手順

Neon Console → プロジェクト「engineer_blog_comments」
「Branches」をクリック
未使用のプレビューブランチを確認（例: preview/feature/*, preview/fix/*など）
各ブランチの右側「...」メニューから「Delete」を選択

注意: mainブランチは削除しないでください。本番環境で使用されています。

推奨される運用

定期的なクリーンアップ

マージ済みPRのプレビューブランチは定期的に削除
アクティブなPRのブランチのみ保持
ブランチ数が上限（9個）に近づいたら未使用ブランチを削除

スクリプト化（オプション）

削除手順をスクリプト化することも可能です：

# scripts/cleanup-neon-branches.sh
#!/bin/bash
# 未使用のNeonプレビューブランチを削除するためのスクリプト
# 使用法: Neon Console (https://console.neon.tech) で手動削除を行うか、
# Neon CLIを使用してブランチをリスト・削除します

set -e

echo "=========================================="
echo "Neonプレビューブランチ削除ガイド"
echo "=========================================="
echo ""
echo "このスクリプトは、Neon Consoleでのブランチ削除手順を案内します。"
echo ""
echo "手順:"
echo "1. https://console.neon.tech にアクセス"
echo "2. プロジェクト「engineer_blog_comments」を選択"
echo "3. 左サイドバーの「Branches」をクリック"
echo "4. 以下のブランチを削除（mainブランチは削除しない）:"
echo ""
echo "   削除対象（未使用のプレビューブランチ）:"
echo "   - preview/feature/*"
echo "   - preview/fix/*"
echo "   - preview/chore/*"
echo "   - その他の古いプレビューブランチ"
echo ""
echo "5. 各ブランチの右側にある「...」メニューから「Delete」を選択"
echo ""
echo "⚠️  注意:"
echo "   - mainブランチは削除しないでください"
echo "   - 現在使用中のプレビューブランチは削除しないでください"
echo "   - 削除後、新しいプレビューデプロイで新しいブランチが作成されます"
echo ""
echo "現在のNeonブランチ数が10/10の場合は、"
echo "上記の手順で削除してから新しいデプロイを行ってください。"
echo ""

まとめ

問題: Vercel統合Neonでプレビューデプロイごとに自動ブランチが作成され、無料プランの上限（10個）に達した
解決: 固定プレビューブランチを使用する設定で、新しいブランチの作成を防止
設定: Vercel CLIでPreview環境に固定ブランチのPOSTGRES_URLを設定
運用: 未使用ブランチを定期的にクリーンアップ

これで、プレビューデプロイ時に新しいブランチが作成されなくなり、ブランチ数の上限問題を回避できます。

Forem: Hama

Windows 11検索を爆速化！EverythingToolbarの導入とエンジニア向け活用術

Windows 11検索を爆速化！EverythingToolbarの導入とエンジニア向け活用術

はじめに

EverythingToolbarとは？

1. 導入と基本セットアップ

インストール手順

2. 「マウスレス」で呼び出すための設定

設定画面へのアクセス

推奨設定 (General)

3. エンジニア向け検索テクニック

拡張子で絞り込む (ext:)

パスを含めて検索 (path:)

正規表現を使う (regex:)

検索コマンドのショートカット

まとめ

GitHub Organizationに課金できなくても、AIエディタの暴走は止められる（pre-commit / pre-push + .cursor/rules）

GitHub Organizationに課金できなくても、AIエディタの暴走は止められる（pre-commit / pre-push + .cursor/rules）

はじめに（ある日、AIが気持ちよく“仕事”しすぎた）

結論：ガードレールは「二段」にすると強い

1) pre-commit：main/develop での直接コミットを禁止する

どこに置く？

これで何が嬉しい？

2) pre-push：main/develop への直接 push を禁止する

これ、AI対策として強いポイント

3) .cursor/rules：AIの“行動原理”を縛る（お願いではなく習慣にする）

追加で入れておくと事故が減る“言い回し”

4) （運用編）Gitフックを“リポジトリ管理”したい場合の現実的な落としどころ

5) それでも起きる“AI暴走あるある”と対策メモ

まとめ：無料でも“事故は減らせる”。しかも精神が軽い

PMBOKの叡智がAIに集約された「PMI Infinity」

この記事でわかること

なぜ今PMI Infinityなのか

PMI Infinityの最新トピック（2025年版）

実際の画面で追体験

1. Explore Project Managementのホーム

2. リアルタイムQAでバッファ計画を確認

3. キャリア相談カードで成長ロードマップを生成

活用シナリオ（自分の体験も交えつつ）

注意点と運用のコツ

今すぐ試すための3ステップ

まとめ

技術ブログにMermaidダイアグラムを導入した話【はてなブログ・DEV.to・Next.js対応】

技術ブログにMermaidダイアグラムを導入した話【はてなブログ・DEV.to・Next.js対応】

はじめに

Mermaidとは？

各プラットフォームの対応方法

1. はてなブログでの対応

実装手順

GoogleのAIエディタ「Antigravity」を触ってみた！設定やワークフローも解説

GoogleのAIエディタ「Antigravity」を触ってみた！設定やワークフローも解説

はじめに

Antigravityとは？

実際に触ってみた

1. インストールと起動

2. 指示出し

3. 実装と確認

Antigravityの真価：ルールとワークフロー

1. rules.md でプロジェクトのルールを教える

2. .agent/workflows で定型作業を自動化

まとめ

AI駆動型販売・在庫管理システム「OpsPilot Console」の実装と展望

AI駆動型販売・在庫管理システム「OpsPilot Console」の実装と展望

はじめに

アーキテクチャと技術スタック

なぜこのスタックなのか？

実装の詳細

ディレクトリ構造

Container Use / git worktree フロー

今後の展望 (Roadmap)

1. トランザクションと在庫履歴の実装

2. APIの拡張とワークフロー

3. 品質保証の自動化

まとめ

Next.jsでQiita風の見出しアンカーリンクを実装する方法

Next.jsでQiita風の見出しアンカーリンクを実装する方法

はじめに

実装の背景

実装手順

1. 必要なパッケージのインストール

拡張子で絞り込む (`ext:`)

パスを含めて検索 (`path:`)

正規表現を使う (`regex:`)

3) `.cursor/rules`：AIの“行動原理”を縛る（お願いではなく習慣にする）

1. `rules.md` でプロジェクトのルールを教える

2. `.agent/workflows` で定型作業を自動化