<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>commte の記事フィード</title>
        <link>http://izanami.dev/organizations/commte</link>
        <description>commte に関連する記事のRSSフィードです</description>
        <lastBuildDate>Thu, 16 Apr 2026 05:35:10 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>izanami RSS Feed</generator>
        <language>ja</language>
        <image>
            <title>commte の記事フィード</title>
            <url>http://izanami.dev/favicon.ico</url>
            <link>http://izanami.dev/organizations/commte</link>
        </image>
        <copyright>All rights reserved 2026</copyright>
        <item>
            <title><![CDATA[Kiro + React Native + Expo で iOSアプリを作る]]></title>
            <link>http://izanami.dev/post/3a8a1e6f-b120-43c2-817a-cc9fcc8b74e9</link>
            <guid>http://izanami.dev/post/3a8a1e6f-b120-43c2-817a-cc9fcc8b74e9</guid><dc:creator>commte</dc:creator>
            <pubDate>Thu, 30 Oct 2025 11:04:43 GMT</pubDate>
            <description><![CDATA[この記事では、Kiro + React Native + Expo + Claude API を使用して、AI 機能付きのタスク管理アプリ「Task」を開発する過程を紹介します。第 1 回では、プロジ]]></description>
            <content:encoded><![CDATA[この記事では、Kiro + React Native + Expo + Claude API を使用して、AI 機能付きのタスク管理アプリ「Task」を開発する過程を紹介します。第 1 回では、プロジェクトのセットアップから基本的なナビゲーション構造の構築までを解説します。

作成するアプリの概要

「Task」は以下の機能を持つタスク管理アプリです：

- ✅ タスクの作成・編集・削除
- ✅ タスクの完了管理
- ✅ 期限設定と視覚的な期限表示
- 🤖 Claude AI によるタスク整理・優先度付け
- 🤖 自然言語でのタスク入力
- 💾 ローカルストレージでのデータ永続化
- 🌙 ダークモード対応
- 📱 レスポンシブデザイン

技術スタック

- フロントエンド: React Native + Expo
- 言語: TypeScript
- 状態管理: React Context API + useReducer
- ローカルストレージ: AsyncStorage
- AI 統合: Claude API (Anthropic)
- ナビゲーション: React Navigation v6
- 日付処理: date-fns
- HTTP クライアント: axios

前提条件

開発を始める前に、以下がインストールされていることを確認してください：

- Node.js (v20.11.0 以上)
- npm または yarn
- 任意のコードエディタ（VS Code 推奨）

ステップ 1: 要件定義と設計

1.1 要件定義書の作成

まず、アプリの要件を明確にするため、要件定義書を作成します。



設計書

アーキテクチャ

アプリケーション構造



主要インターフェース



ステップ 2: プロジェクトの初期化

2.1 Expo プロジェクトの作成

新しいディレクトリを作成し、Expo プロジェクトを初期化します：



2.2 package.json の設定

プロジェクト名と必要な依存関係を追加します：



2.3 依存関係のインストール



ステップ 3: プロジェクト構造の構築

3.1 型定義の作成

TypeScript の型安全性を活用するため、型定義ファイルを作成します：

src/types/Task.ts



src/types/ApiResponse.ts



3.2 ユーティリティ関数の作成

src/utils/constants.ts



src/utils/dateUtils.ts



src/utils/validation.ts



ステップ 4: ナビゲーション構造の構築

4.1 ナビゲーターの作成

src/navigation/AppNavigator.tsx



4.2 画面コンポーネントの作成

各画面のプレースホルダーを作成します：

src/screens/TaskListScreen.tsx



同様に、、、も作成します。

4.3 App.tsx の更新

メインの App.tsx ファイルを更新して、新しいナビゲーション構造を使用します：



ステップ 5: 動作確認

5.1 Expo CLI のインストール



5.2 開発サーバーの起動



5.3 ブラウザでの確認

ブラウザが自動的に開き、以下のような画面が表示されます：

- ヘッダー: 青色の背景に「Task」というタイトル
- メイン画面: 「タスクリスト画面」と「実装予定」のプレースホルダーテキスト

完成したプロジェクト構造



まとめ

第 1 回では、以下を完了しました：

✅ 要件定義と設計: アプリの機能要件と技術アーキテクチャの定義
✅ プロジェクトセットアップ: Expo + TypeScript プロジェクトの初期化
✅ 型定義: TypeScript による型安全な開発環境の構築
✅ ユーティリティ関数: 日付処理、バリデーション、定数の実装
✅ ナビゲーション構造: React Navigation v6 による画面遷移の実装
✅ 動作確認: ブラウザでの基本動作確認

次回予告

第 2 回では、実際のタスク管理機能を実装していきます：

- ローカルストレージサービスの実装
- タスクの状態管理（Context API + useReducer）
- タスクの CRUD 操作
- UI コンポーネントの作成

お楽しみに！

参考リンク

- [Expo 公式ドキュメント](https://docs.expo.dev/)
- [React Navigation 公式ドキュメント](https://reactnavigation.org/)
- [TypeScript 公式ドキュメント](https://www.typescriptlang.org/)
- [date-fns 公式ドキュメント](https://date-fns.org/)
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Claude Code + Playwright MCP で実現する、手動テストの自動化]]></title>
            <link>http://izanami.dev/post/0b13ae65-d420-47cd-b8a0-d4ef9d301508</link>
            <guid>http://izanami.dev/post/0b13ae65-d420-47cd-b8a0-d4ef9d301508</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 02 Jun 2025 12:21:42 GMT</pubDate>
            <description><![CDATA[Claude Code + Playwright MCP の組み合わせによって、これまで人間が行っていた手動のブラウザ操作が、LLM（大規模言語モデル）によって自動化できるようになった。この記事では、]]></description>
            <content:encoded><![CDATA[Claude Code + Playwright MCP の組み合わせによって、これまで人間が行っていた手動のブラウザ操作が、LLM（大規模言語モデル）によって自動化できるようになった。この記事では、仕組み・設定・使い方・できること・従来との差などを解説

Claude Code で、手動テストを走らせた結果

![なんと、コンソールログ消し忘れまで知らせてくれた 笑](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/f5dd8365-e4d4-4936-8000-31962cb0b09b.png)

はじめに：何が変わったのか？

従来、Playwright を使った自動テストには、明示的なコード（TypeScriptやPythonなど）によるシナリオ記述が必要でした。しかし Claude Code と MCP を組み合わせることで、「自然言語でテスト指示」＋「自動ブラウザ操作」が可能になりました。

つまり、テストコードを書くことなく、以下のようなことができるようになります。

 指定したURLにアクセス
 ログインフォームに入力
 レスポンシブ状態の確認
 コンソールエラーの検出
 ドロップダウンやボタン操作

しかもこれらを「手動テストして」と一言伝えるだけで済むのです。


MCPとは何か？

MCP（Model Context Protocol）は、LLMと外部ツール（PlaywrightやChromeなど）をつなぐためのプロトコルです。

Playwright MCP はその一種で、以下の特徴があります

| 特徴        | 内容                                         |
| --------- | ------------------------------------------ |
| 軽量・高速     | スクリーンショット不要、アクセシビリティスナップショットを使用            |
| LLMフレンドリー | DOM構造ベースで操作、視覚モデル不要                        |
| 決定論的      | 画面サイズやUI変更に強い                              |
| 柔軟性       | Chrome / Firefox / WebKit に対応、端末エミュレーション可能 |

---

設定方法

最も簡単な  設定は以下の通りです。



Claude Code や Cursor ではこの設定ファイルを認識し、自動で MCP サーバーを起動します。

---

どこまでできる？（代表的な操作一覧）

| 操作名                                | 内容                 | 自動化対象 |
| ---------------------------------- | ------------------ | ----- |
|                     | ボタン・リンククリック        | ✅     |
|                      | 入力フォームへのテキスト入力     | ✅     |
|             | セレクトボックスの選択        | ✅     |
|                  | アクセシビリティスナップショット取得 | ✅     |
|          | コンソールログ取得          | ✅     |
|                    | ビューポートサイズ変更        | ✅     |
|               | ファイルアップロード         | ✅     |
|  | テストコードの生成（参考用）     | ✅     |

これらは Claude に「このURLで手動テストして」と言うだけで実行されます。

---

自動テストとの違い

| 項目     | Playwright Test | Claude + MCP       |
| ------ | --------------- | ------------------ |
| 操作対象   | 事前に定義したコード      | 自然言語で都度指示          |
| ユースケース | 継続的テスト          | 一時的な動作確認、非エンジニアのQA |
| 保守性    | 高い（再利用性あり）      | 低いが柔軟で即席対応向き       |
| 導入コスト  | やや高い（テスト実装が必要）  | 低い（設定と指示だけ）        |

---

よく使うオプション一覧



---

まとめ

Claude Code + Playwright MCP により、Webの手動テストはまったく新しいフェーズに入りました。

 コード不要でテスト操作が可能
 コンソールやネットワークまで確認できる
 モバイル環境での再現も簡単
 短期的な動作チェックや QA に最適

テストコードを書くほどでもないけど確認したい。そのニーズを Claude が自然言語で満たしてくれるのはまさに「革命」です。

これからの手動テストは、「書く」ではなく「伝える」時代です。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Cursor + Claude Max の課金・性能差]]></title>
            <link>http://izanami.dev/post/51496cb6-6497-414c-917b-b846a4bacffd</link>
            <guid>http://izanami.dev/post/51496cb6-6497-414c-917b-b846a4bacffd</guid><dc:creator>commte</dc:creator>
            <pubDate>Wed, 28 May 2025 11:58:49 GMT</pubDate>
            <description><![CDATA[Cursor の Max Mode と Claude モデル：課金と性能差について詳しく調べてみた（2025 年 5 月版）

分かりにくい「Cursor + Claude Max」の課金・性能差・使]]></description>
            <content:encoded><![CDATA[Cursor の Max Mode と Claude モデル：課金と性能差について詳しく調べてみた（2025 年 5 月版）

分かりにくい「Cursor + Claude Max」の課金・性能差・使い所・費用対効果を整理してみました。自分なりの解釈を元に、Deep Research でブラッシュアップした内容をまとめてみました。

Cursor の Max Mode と Claude モデルの関係について、特に課金体系と性能差に焦点を当てています。

参考文献ソース

- [Pricing | Cursor - The AI Code Editor](https://www.cursor.com/pricing)
- [A Complete Guide to Cursor's New Pricing: Subscriptions and Request Quotas](https://apidog.com/blog/cursor-pricing-guide)
- [How to Use Claude 3.7 Sonnet Max Mode in Cursor AI IDE](https://apidog.com/blog/how-to-use-claude-3-7-sonnet-max-mode-in-cursor-ai-ide/)
- [Introducing Claude 4 - Anthropic](https://www.anthropic.com/news/claude-4)
- [Claude 4 Sonnet & Opus now in Cursor - Cursor Forum](https://forum.cursor.com/t/claude-4-sonnet-opus-now-in-cursor/95241)
- [Confusion About New Cursor Pricing - Cursor Forum](https://forum.cursor.com/t/confusion-about-new-cursor-pricing/93319)
- [Using Claude Code with your Max Plan | Anthropic Help Center](https://support.anthropic.com/en/articles/11145838-using-claude-code-with-your-max-plan)
- [Max models and requests vs pricing : r/cursor](https://www.reddit.com/r/cursor/comments/1k53s8b/maxmodelsandrequestsvspricing/)
- [Best AI Models for Cursor - SourceForge](https://sourceforge.net/software/ai-models/integrates-with-cursor/)
- [Pricing - Anthropic API](https://docs.anthropic.com/en/docs/about-claude/pricing)
- [Pricing - Anthropic](https://www.anthropic.com/pricing)
- [Max Plan - Anthropic](https://www.anthropic.com/news/max-plan)
- [Cursor – Max Mode](https://docs.cursor.com/context/max-mode)
- [Cursor – Custom API Keys](https://docs.cursor.com/settings/api-keys)

分かったこと

課金について: Cursor の Max Mode は、通常の固定リクエスト制と違って、トークンベースの従量課金になってます。

Anthropic の Max プランに入っていても、Cursor の Max Mode を使う時は Cursor 経由（API 代に 20%上乗せ）かカスタム API キー使って Anthropic 直接払いのどちらかです。

Anthropic の Max プランって基本的に Claude.ai 向けのサブスクで、Cursor みたいなサードパーティアプリでの API 利用には直接適用されません。

性能について: Max Mode って、Claude Sonnet の出力品質そのものを変えるわけじゃないんです。

主な効果は、コンテキストウィンドウとツール呼び出しの制限を大幅に広げることで、もっと複雑なタスクやエージェント的な作業ができるようになることです。

あと、Claude Opus は Max Mode でしか使えません。

コスパについて: 普通の作業で広いコンテキストや高度なツールが要らないなら、予測しやすい固定制の通常モード（Sonnet + Max Mode OFF）が一番コスパいいです。

Max Mode は、その強化された計算パワーとコンテキストが絶対必要な、価値の高い複雑な問題用に作られてます。

1. Cursor の Max Mode って何？

Cursor AI は、AI 搭載の革新的なコードエディターです。

開発者のコーディング、ドキュメント作成、クリエイティブライティングを効率化するために作られました。

リアルタイムの提案や高品質なコンテンツ生成で生産性アップを狙ってます。

普段のコーディングから複雑なプロジェクトまで、幅広くサポートしてくれるプラットフォームです。

Max Mode は、Cursor の高度な AI 機能のコア部分で、「Cursor の高度な AI モデルの全機能」にアクセスできます。

特に「追加の処理能力とより深い分析」が必要な場面のために設計されてます。

Max Mode の登場は、Cursor が複雑な開発ワークフロー向けに、もっと強力なツールを提供しようとする継続的な取り組みの現れです。

過去の課金体系でユーザーから不満が出たのを受けて、Max Mode はより高度なニーズに応えるための進化として位置づけられてます。

Max Mode は「コストを惜しまない」機能として位置づけられていて、他の標準モデルにはないインテリジェンスと機能を提供してくれます。

特に「モデルが最も考えて推論する必要がある超難しい問題」にめちゃくちゃ効果的とされてます。

大規模なコードベースの理解、複雑な問題のデバッグ、アーキテクチャ設計、大規模なコードリファクタリングなど、高度なプログラミングタスクに特化して作られてます。

Cursor の Max Mode は、製品の差別化と上級ユーザーから収益を上げるっていう戦略的な狙いがあります。

Cursor は無料の Hobby プランに加えて、有料の Pro と Business プランを提供してます。

通常モードは固定リクエスト制なのに対し、Max Mode はトークンベースの課金に 20%マージンを乗っけてます。

この 2 つのモード戦略は、Cursor が色んなユーザー層に対応しようとしてることを表してます。

普通の作業で予測しやすいコストを求めるユーザー（通常モード）と、複雑で価値の高いタスクのために強化された機能とパフォーマンスにお金を払ってもいいユーザー（Max Mode）ですね。

Anthropic の API コストに 20%マージンを上乗せしてるのは、Cursor が付加価値機能（コンテキスト管理やツールオーケストレーションなど）で稼ごうとしてるからです。

このモデルのおかげで、Cursor は大規模言語モデルの運用にかかる莫大なコストを継続的にカバーしながら、高度な機能を提供して、ヘビーユーザーへのサービス品質を保つことができます。

これは、AI のやり取りの複雑さとリソースの使用量に応じてスケールするビジネスモデルってことですね。

2. 課金の仕組みを詳しく見てみよう

2.1. 通常モード（Max Mode OFF）について

通常モードは、メッセージ/モデルごとの固定コストで動いてます。

標準的な「リクエスト」は 1 回あたり 0.04 ドルの設定です。

Cursor のサブスクプランは利用レベルに応じて複数の階層があります。

Hobby プラン（無料）は月間 50 リクエスト。

Pro プラン（月額 20 ドル）は月間 500 回の高速リクエストで、それを使い切った後は無制限の「低速リクエスト」が使えます。

Business プラン（ユーザーあたり月額 40 ドル）は、ユーザーごとに月間 500 回の高速リクエストです。

通常モードの課金は「めちゃくちゃ予測しやすい」とされてて、日常のコーディング作業やコスト予測が大事な簡単な質問に向いてます。

このモードでは、Claude 3.5 Sonnet や Claude 4 Sonnet などのモデルが使えます。

2.2. Max Mode（ON）- トークンベースの課金について

ユーザーの認識通り、Cursor の Max Mode は常に従量課金制です。

Max Mode はトークンベースの課金システムで動いてます。

Cursor は、モデルプロバイダーの API 料金に 20%マージンを上乗せして課金します。

このマージンは、入力メッセージ、添付されたコードファイル、フォルダ、ツール呼び出し、モデルに提供される他のすべてのコンテキストを含む、全てのトークンに適用されます。

コストは、処理された入力と出力トークンの総量によって変わります。

例えば、135,000 入力トークンと 82,000 出力トークンを含む複雑なプロンプトの場合、1 回のやり取りで約 4 リクエスト分のコストがかかることがあります。

Max Mode でのツール呼び出しは、個別のリクエストとして課金されるか、トークン使用量に加算されます。

例えば、Claude 3.7 Max Mode のプロンプトは 1 リクエストあたり 0.05 ドルに加えて、1 ツール呼び出しあたり 0.05 ドルかかります。

エージェントモードでのツール呼び出しは、最初のプロンプトリクエストに加えて、個別のリクエストとしてカウントされます。

トークンベースの性質上、Max Mode のコストは予測しくいで、「大量のコンテキストを送ったら高額になっちゃう可能性がある」と言われてます。

長い会話やたくさんのツール呼び出しが必要なタスクは、コストがかなり跳ね上がることがあります。

あと、Max Mode には「低速リクエスト」って概念がありません。

ユーザーが「高速リクエスト」（月間割り当て）を使い切った場合、Max Mode を継続して使うには従量課金を有効にする必要があります。

Cursor の通常モードが「リクエスト」って抽象化された単位（1 リクエストあたり 0.04 ドル）で課金されるのに対し、Max Mode は LLM プロバイダーからの生のトークンベースコストに Cursor マージンを乗せた形で課金されます。

この抽象化単位から生トークン価格への変更は、コストの大きなブレや、固定コストに慣れたユーザーさんにとっては思ってたより高い請求になっちゃう可能性があります。

通常モードの固定コスト「リクエスト」システムは、ユーザーエクスペリエンスと予算のシンプルさを重視してます。

一方、トークンベースの Max Mode は、生の処理能力と柔軟性を重視してて、複雑な AI のやり取りの実際の計算コストを反映してます。

Max Mode のコスト予測が難しいのは、トークンベースの性質と、AI のやり取りの長さや複雑さがバラバラだからです。

表 1：Cursor モードの比較：通常モード vs. Max Mode（2025 年 5 月現在）

| 比較項目               | 通常モード（Max Mode OFF）                                                | Max Mode（ON）                                                                                                                                                                                   |
| ---------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 課金方法               | メッセージ/モデルごとの固定リクエスト（例: 1 リクエストあたり 0.04 ドル） | トークンベース（入力/出力トークン + ツール呼び出し）                                                                                                                                             |
| コスト計算             | 標準プロンプト（例: Claude 3.5 Sonnet）で 1 リクエスト                    | モデルプロバイダー API 料金 + Cursor マージン 20%。総トークン数（入力、出力、コンテキスト、ツール呼び出し）で変動。例: 135k 入力 + 82k 出力 = 約 4 リクエスト。ツール呼び出しは 1 回 0.05 ドル。 |
| コスト予測しやすさ     | 高い；予算立てやすい                                                      | 低い；コンテキストサイズ、プロンプトの複雑さ、ツール呼び出し回数でかなり変わる。「Cursor のリクエストをあっという間に消費する」ことあり。                                                        |
| コンテキストウィンドウ | Cursor が最適化（例: 一部モデルで 10k-120k トークン）                     | かなり拡大；モデルのフルコンテキストウィンドウを使用（例: Claude 3.7 で最大 200k、一部モデルで最大 1M+トークン）。最大限のコンテキスト処理に最適化。                                             |
| ツール呼び出し制限     | 標準的                                                                    | 再プロンプトなしで最大 200 回のツール呼び出し。ツール使用にめちゃ強い。                                                                                                                          |
| 使えるモデル           | Claude 3.5 Sonnet、Claude 4 Sonnet                                        | Claude 4 Opus（Max Mode 限定）。Claude 3.7 Sonnet、Claude 4 Sonnet も強化されたコンテキスト/ツールで使用可能。                                                                                   |
| 低速リクエスト         | 高速リクエストを使い切ったら使える（Pro プラン）                          | 使えない；高速リクエストがなくなったら従量課金を有効にする必要あり。                                                                                                                             |
| 適してる使い方         | 日常のコーディング、簡単な質問、予測しやすいコスト、軽いやり取り。        | 複雑な推論、難しいバグのデバッグ、たくさんツール呼び出しが必要なエージェントタスク、大規模コードベースの理解、アーキテクチャ設計、大規模コードリファクタリング。「コスト惜しまない」場合。       |
| ユーザー体験           | シンプルな課金、予期せぬ高コストのリスク低い。                            | もっと強力だけど、注意深いコスト監視が必要。変動コストのため、一部ユーザーにとっては「マジで博打」。                                                                                       |

2.3. カスタム Anthropic API キーを使った場合の影響

Cursor は、Anthropic などの様々な LLM プロバイダーのカスタム API キーを設定できます。カスタム API キーを使う場合、Cursor は LLM プロバイダーへの呼び出しにそのキーを使います。つまり、ユーザーが「自己負担」で Anthropic に直接利用料を払うことになります。これで、特定のモデルに関しては Cursor の内部リクエストシステムを通した課金をスキップできます。

カスタム Anthropic API キーを使う場合、課金は Anthropic の API を通した完全な従量課金制になります。Anthropic の API 料金はトークンベースで設定されてます。

ユーザーの質問に「Claude Max を契約していても」ってありますが、Anthropic の「Max プラン」は、基本的に Claude.ai のウェブ、デスクトップ、モバイルアプリでの利用を対象としたサブスクプラン（Pro プランの 5 倍利用で月 100 ドル、20 倍利用で月 200 ドル）です。

これは Anthropic の直接プラットフォーム内での「利用量アップ」や「より高い出力制限」を提供してくれます。

大事なのは、Anthropic の Max プランに入ってても、Cursor の課金システムで「無制限に使える」わけじゃないってことです。Cursor の組み込み Max Mode を使う場合、ユーザーは Cursor に（トークンベース+20%マージンで）支払います。

一方、Cursor で自分の Anthropic API キーを使う場合、ユーザーは Anthropic の API トークン料金で直接 Anthropic に払います。これは、Anthropic のサブスクプランが提供するウェブ/アプリインターフェースの利用量とは別ものです。

Anthropic の API 利用は常にトークンベースです。例えば、Claude Code では、Max プランの割り当てと API クレジットの使用を切り替えられて、API 利用は「Max プランの料金とは違う標準 API 料金で請求される」ときちんと書いてあります。

カスタム API キーにはいくつか制限があります。例えば、Tab Completion みたいな一部の Cursor 機能は特別なモデルが必要なので、カスタム API キーでは使えません。

ユーザーは、Anthropic の「Max プラン」サブスクを結んでいれば、Cursor みたいなサードパーティアプリで Claude モデルを使う時に「無制限」や大幅割引で使えると誤解しちゃうかもしれません。でも、調査した結果、Anthropic のサブスクプランは基本的に彼らの直接プラットフォーム（Claude.ai）での利用を対象としてることが明らかになりました。Cursor の Max Mode（Cursor が課金）やカスタム Anthropic API キー（Anthropic が直接課金）を使う場合、課金は従量課金制のトークンコストに戻ります。

これは、マルチプラットフォーム AI エコシステムにおける一般的な混乱点を示しています。ユーザーは、モデルプロバイダーの直接サービス（例: Anthropic の Max プラン）を購読しても、サードパーティの統合にその特典が自動的に付与されるわけではないことを理解する必要があります。各プラットフォーム（Cursor、Anthropic API）には独自の課金ロジックが存在します。このため、IDE と LLM プロバイダーの両方の課金ドキュメントを慎重に確認することが不可欠です。

表 2：Anthropic API モデル料金（トークンベースコストの参考）

| モデル            | 入力トークン（100 万トークンあたり） | 出力トークン（100 万トークンあたり） |
| ----------------- | ------------------------------------ | ------------------------------------ |
| Claude Opus 4     | $15                                  | $75                                  |
| Claude Sonnet 4   | $3                                   | $15                                  |
| Claude Sonnet 3.7 | $3                                   | $15                                  |
| Claude Sonnet 3.5 | $3                                   | $15                                  |
| Claude Haiku 3.5  | $0.80                                | $4                                   |

注：料金は基本の入力/出力トークンに対するものです。キャッシュされたトークン、バッチ処理、およびサーバーサイドのツール使用には追加料金が適用される場合があります。

3. 性能とモデル機能

3.1. Claude Sonnet の品質：Max Mode ON/OFF による出力品質

ユーザーの「Max Mode ON/OFF による Claude 4 Sonnet の出力品質差はない」という認識は、モデルの固有の能力という点では概ね正確です。Max Mode は、Claude 3.5/4 Sonnet のようなモデルの核となる品質や固有の能力ではなく、主にコンテキストウィンドウとツール呼び出しの制限に影響を与えます。モデル自体の基本的な品質を変えるものではありません。

Sonnet の本来の「知性」は同じままですが、Max Mode はより大きな操作範囲へのアクセスを提供します。これは、Sonnet が単一のインタラクション内でより広範なコンテキストを活用し、より多くのツール呼び出しを実行できることを意味し、モデルがより関連性の高い情報とアクションを利用できるため、複雑なタスクにおいてより良い結果につながる可能性があります。

Claude 4 Sonnet 自体が「Claude Sonnet 3.7 の重要なアップグレード」であり、「優れたコーディングと推論能力」を提供し、「指示により正確に応答する」という点も重要です。これは、Max Mode とは独立した、モデルの核となる能力の改善です。

3.2. Claude Opus の利用可能性

Max Mode を有効にすることで Claude 4 Opus を選択できるようになるというユーザーの理解は正しいです。Claude 4 Opus は Cursor 内で「Max Mode でのみ利用可能」です。Claude 4 Opus は、「複雑なタスクに最もインテリジェントなモデル」であり、「複雑で長時間実行されるタスクやエージェントワークフローにおいて持続的なパフォーマンスを発揮する、世界最高のコーディングモデル」と評されています。200K のコンテキストウィンドウを提供し、ローカルファイルへのアクセスが許可された場合、メモリ能力において以前のモデルを劇的に上回ります。

3.3. コンテキストウィンドウとツール機能

通常モードと Max Mode の主な違いは、「Max Mode が可能な限り多くのコンテキストを処理するように最適化されている」というコンテキストの振る舞いです。これは「より大きなコンテキストウィンドウ」を意味し、Claude 3.7 のようなモデルでは最大 200,000 トークン、一部のモデルでは最大 100 万トークン以上まで可能になります。これは、大規模なコードベースの理解、複雑な問題のデバッグ、アーキテクチャの設計にとって非常に重要です。

Max Mode は「非常に高いツール呼び出し制限」を提供し、「（継続を求めずに）最大 200 回のツール呼び出し」を可能にします。これにより、AI のエージェント機能が強化され、ウェブ検索、コード実行、コードベースのセマンティック検索など、より複雑な多段階ワークフローを実行できるようになります。

Max Mode は、モデルが「最も思考し、推論する必要がある」状況のために設計されています。拡張されたコンテキストとツールアクセスは、この強化された推論能力に直接貢献し、AI がニュアンス、ユーモア、複雑な指示をよりよく理解することを可能にします。

Max Mode は、Sonnet の核となるアルゴリズムを魔法のように「賢く」するわけではありません。むしろ、Max Mode は、より複雑な問題に対して Sonnet がその潜在能力を最大限に発揮できるように、リソース（より大きなコンテキストウィンドウ、より多くのツール呼び出し）を提供します。これは、非常に熟練したシェフにより多くの食材とより良い道具を与えることに似ています。彼らの固有のスキルは変わりませんが、より手の込んだ料理を作る能力は向上します。

Opus の場合、Max Mode はその優れた機能を利用可能にするゲートキーパーとしての役割を果たします。したがって、コードベースの深い理解や複雑な多段階操作を必要とするタスクでは、Max Mode は単なる「あれば便利」なものではなく、Claude モデル、特に Opus の完全な問題解決能力を解き放つための「必須」の機能となります。

Max Mode の価値提案は、開発タスクの複雑さと範囲に結びついています。Claude 4 Sonnet や Opus のような新しいモデルの迅速な導入（2025 年 5 月）と、その機能（例: コーディング能力の向上、メモリ、ツール使用）の継続的な更新は、AI 搭載 IDE の急速な進化を示しています。Cursor がこれらのモデルを迅速に統合していることは、最先端を維持しようとするコミットメントを示しています。これは、AI IDE が最新の最も強力なモデルを統合し続け、特にエージェントワークフローにおいて、それらの潜在能力を最大限に活用するための「Max Mode」のような機能が標準的なメカニズムになるという継続的なトレンドを示唆しています。ユーザーは、継続的な更新と最適な利用戦略の潜在的な変化を予測する必要があります。

4. 費用対効果分析と戦略的利用の推奨事項

4.1. 費用対効果を考慮した通常モード（Sonnet + Max Mode OFF）の利用時期

ユーザーの「必要がなければ Sonnet + Max Mode OFF の方がコスパ良く使える」という主張は強く支持されています。通常モードは、1 リクエストあたり固定料金で予測可能なコストを提供します。このモードは、「標準的なコード編集」、「日常的なコーディング、予測可能なコスト」、「軽量な対話」、および「簡単な質問」に最も適しています。通常モードの Cursor エージェントは、「依然として最も費用対効果の高いソリューションであり、Cursor が処理するプロンプトの 90%以上で十分」であるとされています。Pro プランのユーザーは、月間 500 回の高速リクエストと、その後無制限の低速リクエストを利用できます。これにより、日常業務に十分な割り当てが提供されます。

4.2. Max Mode（Opus または強化された Sonnet 機能）が正当化される場合

Max Mode は、「モデルが最も思考し、推論する必要がある最も困難な問題」のために設計されています。これには、「複雑な推論、困難なバグのデバッグ、複数のツール呼び出しを必要とするエージェントタスク、および大規模なコードベースでの作業」が含まれます。大規模なコンテキストウィンドウ（例: 大規模なコードベースの理解、重要なコードのリファクタリング）や広範なツール使用（例: ウェブ検索、コード実行、セマンティック検索）を必要とするタスクの場合、Max Mode は不可欠です。Claude Opus 4 の優れた知能とパフォーマンスが重要なタスクに必要とされる場合、Cursor 内でそれにアクセスする唯一の方法は Max Mode です。

4.3. Max Mode でのコスト管理のヒント

Max Mode はトークンベースであり、特にツール呼び出しを伴う場合、高額になる可能性があるため、ユーザーは「コストを効果的に管理するために、どれだけのツール呼び出しをトリガーしているかに注意を払う」必要があります。Max Mode は拡張されたコンテキストウィンドウを持っていますが、「明確な指示と関連するコンテキストを提供することで、結果が劇的に改善され」、不要なトークン使用を削減できます。チャットで@シンボルを使用して特定のファイル、フォルダ、またはドキュメントを参照することで、関連するコンテキストのみが提供されるようにします。

チャットがコンテキスト制限に達した場合、パフォーマンスの低下やモデルが過剰なコンテキストに苦しむことによる潜在的なハルシネーションを避けるために、新しいチャットを開始することが推奨されます。ユーザーは、新しいダッシュボードで各モデル呼び出しが消費したリクエスト/トークン数を確認できます。これを定期的に監視することで、コスト管理に役立ちます。

非常に高い利用量を持つユーザーの場合、カスタム Anthropic API キーを設定することで、課金をより直接的に管理し、異なるレート制限を享受できる可能性があります。これは、Anthropic に直接支払うことになるためです。ただし、これには Anthropic 自身の API 課金を管理し、その料金体系を理解する必要があります。

あるユーザーは、MAX モデルの使用を「真の博打」と表現しています。これは、1 ツール呼び出しあたり 0.05 ドルのコストと、放置すればコストが急増する可能性を指摘しています。この生々しい表現は、特に多くのツール呼び出しや広範なコンテキストを伴う複雑なエージェントタスクにおいて、管理されていない Max Mode の使用に関連する重大な財務リスクを強調しています。

このことは、高度な AI 機能、特に Max Mode を使用する際に、コスト監視、プロンプトエンジニアリング、戦略的なタスク割り当てが極めて重要であることを示しています。開発者は、技術的に熟練しているだけでなく、AI 支出を最適化するために経済的な意識も持つ必要があります。Cursor のダッシュボード機能は、この可視性を提供する上で不可欠です。

通常モードの予測可能な固定コストと Max Mode の変動するトークンベースコストの明確な区別は、根本的なトレードオフを提示します。ユーザーは、Max Mode の強化されたパフォーマンス、コンテキスト、およびモデルアクセスが、コストの変動性と潜在的な高額支出に見合うかどうかを判断する必要があります。このトレードオフは、大規模言語モデルの性質に固有のものです。より深い推論とより大きなコンテキストウィンドウは、本質的に多くの計算リソースを消費し、結果として高額で予測しにくいコストにつながります。Cursor の課金構造は、この根本的な現実を反映しており、ユーザーがコスト管理と AI の能力のバランスを選択できるようにしています。

5. 結論

Cursor の Max Mode における Claude モデルとの課金と性能差に関するユーザーの初期の要約（2025 年 5 月時点）は概ね正確であり、強固な基盤となっています。しかし、より深い分析を行うと、最適な利用とコスト管理のために不可欠な重要なニュアンスが明らかになります。

主要なポイント

課金は複雑: Cursor の Max Mode は確かに常に従量課金制（トークンベース）であり、Anthropic の Max プランを契約していても、Cursor の課金システム内で「無制限」に利用できるわけではありません。ユーザーは Cursor に（20%のマージンを加えて）支払うか、カスタム API キーを介して Anthropic に直接支払うかのいずれかであり、どちらもトークンベースです。

性能はコンテキストに依存: Max Mode は Claude Sonnet の固有の品質を向上させるものではありませんが、コンテキストウィンドウとツール呼び出しの制限を拡張することで、その運用能力を大幅に強化します。より強力なモデルである Claude Opus は、Max Mode でのみ利用可能です。

戦略的な利用が最重要: 予測可能なコストでルーチンタスクを実行するには、通常モードが最も費用対効果が高いです。Max Mode は強力ですが、潜在的に高額なツールであり、その拡張された機能と Opus へのアクセスが大きな価値を提供する、複雑でコンテキスト集約的な、またはエージェント的なタスクのために予約されるべきです。

監視と最適化: Max Mode のコストは変動するため、利用状況の継続的な監視と戦略的なプロンプトエンジニアリングが効果的なコスト管理のために不可欠です。

これらの違いを理解することで、ユーザーは情報に基づいた意思決定を行い、Cursor の AI 機能を効率的に活用しながら、急速に進化する AI 環境における支出を最適化することができます。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[個人開発の方々、Figma MCP + Cursor の連携方法]]></title>
            <link>http://izanami.dev/post/983f0322-8bdd-4258-825e-11e06480205b</link>
            <guid>http://izanami.dev/post/983f0322-8bdd-4258-825e-11e06480205b</guid><dc:creator>commte</dc:creator>
            <pubDate>Fri, 23 May 2025 09:01:21 GMT</pubDate>
            <description><![CDATA[Cursor はコード生成に強い AI エディタですが、Figma の設計データと連携させると、UI 実装の速度が一気に跳ね上がります。Figma MCP を使って ファイルと Cursor を連携し]]></description>
            <content:encoded><![CDATA[Cursor はコード生成に強い AI エディタですが、Figma の設計データと連携させると、UI 実装の速度が一気に跳ね上がります。Figma MCP を使って ファイルと Cursor を連携し、自動で実装補助させるためのセットアップ方法を詳しく解説

対象者

- フロント実装だるい方
- 画像エクスポート、ポチポチやりたくない方
- レスポンシブ対応面倒な方

実際に、私はこれでLPを４時間（デザイン３時間、ノーコーディング実装１時間）で作れました。レスポンシブ対応もSP版デザインのリンク貼るだけ。簡単なコーポレートサイトなら片手間で１日でできそうですねえ…

っっってか、営業できればLP+HP受託高速でまわせるやーん！！！

効率的な魚の釣り方伝授してるワイ、偉いよね？こういう情報ばっかりXの（@commte）で発信してるからフォローしとくんやで

ちなみに、HP/LP制作は10〜30万（〜10日）、Webアプリ or SaaS（〜３ヶ月）開発は 〜200万くらいでやれますので、こちらから問い合わせくださいね。

https://www.commte.co.jp/contact

セキュリティ対策やランニングコストが安い技術スタックで構築できるので、サーバーやヘッドレスCMSの月額料金が高いなぁと悩んでる方もご相談ください！

稼働中の案件を優先しますが、今年は後35プロジェクトなら無理なく対応できそうです。

なぜ Figma + Cursor が便利なのか？

 画像を自動でダウンロードしてくれて、public フォルダに格納してくれる
 部分的な要素のリンクも貼れるから、少しづつ実装できる
 Figma のデザインリンクを貼るだけで UI 実装の元になる情報を AI に渡せる
 スクショを貼るより構造情報が伝わるため、生成されるコードの正確性が高い
  に設定しておけば、毎回手動でデータを渡さずに済む
 対応している "Framelink Figma MCP" サーバーは、レイアウトとスタイルの重要情報だけを抽出して送ってくれるので、ノイズが少ない

セットアップ手順

1. Figma アクセストークンの発行

Figma にログイン → プロジェクトに移動 → 左上の Figma アイコン

![左上の Figma アイコン](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/b34fa8d7-d53b-4aa3-965d-c648a5c53eff.png)

アカウント設定 → セキュリティ → "個人アクセストークン"。"新しいトークンを生成" をクリックし、任意の名前で作成

![アカウント設定 → セキュリティ](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/272f1323-8e0d-4b32-bdd5-c639dfd5d335.png)

後は、API トークン（個人アクセストークン）を Cursor の mcp.json に貼り付けるだけ

.gitignore で .cursor 以下を除外する



:::warning
⚠️ 個人アクセストークンは自分の Figma アカウントへのアクセス権です。第三者に渡すとファイルが見られてしまう可能性があるので、必ず  で管理 or 環境変数で扱いましょう
:::

2.  を作成

以下の内容で  をプロジェクトルートに作成します。



Mac / Linux の場合はこれでOKです。Windows の場合は以下に書き換えてください。



https://github.com/GLips/Figma-Context-MCP

確認

![Cursor Settings](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/fbddb40c-0762-42ae-b75d-c67ace1b3aeb.png)

Cursor の 右上のアイコン⚙️から MCP → MCP Servers が緑色になっていたら連携完了。

実際の使い方

![選択範囲へのリンクをコピー](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/64e559a2-fd2a-431e-be50-808911f25736.png)

1. Figma 上で要素を選択 → 右クリック → 「選択範囲へのリンクをコピー」
2. Cursor のチャットにそのリンクを貼る
3. 「このデザインを Tailwind で実装して」と指示すれば、自動でマークアップが生成されます

![レスポンシブ対応もこんな感じで一発](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/3c6f81ce-7d37-49e4-b7cb-be0d80668d21.png)

![設定で、MCPはオートにしておくと楽よ](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/7959f809-98c7-44d3-9654-60a25fd4e59c.png)

注意点

 Figma の画像は public 状態に自動で設定されます（非公開にはならない）
 Figma の画像は軽量化されてない
 レイアウトが複雑な場合、ずれることがあるので、補足プロンプトを同時に出す必要がある
 出力されたコードは全体の一部なので、意図に応じて調整は必要です
  を GitHub に push しないように注意（トークン漏洩リスク）

まとめ

Figma + Cursor の連携は、UI 実装を高速化する強力なワークフローです。

とくに個人開発や MVP 構築時には "デザイン → 実装" の手戻りを防げるため、設定しておいて損はありません。]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[個人開発でドメイン取るなら Cloudflare Registrar にしておけ]]></title>
            <link>http://izanami.dev/post/c61ac13b-56a5-4f21-af36-c0a04883e6cc</link>
            <guid>http://izanami.dev/post/c61ac13b-56a5-4f21-af36-c0a04883e6cc</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 21 Apr 2025 14:28:20 GMT</pubDate>
            <description><![CDATA[結論

スタートアップや個人開発で選ぶなら、Cloudflare Registrar でいいかなという感じ。Images や D1 使う人には神UI。モダンだし通っぽくて名前の響きも美しい。

Ver]]></description>
            <content:encoded><![CDATA[結論

スタートアップや個人開発で選ぶなら、Cloudflare Registrar でいいかなという感じ。Images や D1 使う人には神UI。モダンだし通っぽくて名前の響きも美しい。

Vercel 使ってるなら、Vercel Domains もおすすめ。ドメイン購入〜DNS設定までが爆速で完結。これもモダン力高い。

SIer・SES、受託だったら Route 53。AWSサービスとネイティブ統合できる。信頼性・法人対応力の高さが強み。手練れ、只者ではない感がある。

そして、お名前.com, ムームードメイン… ｲｲﾄｵﾓｲﾏｽ

:::success
法人登記とか請求書払いが必要なら、日本のレジストラも全然アリ
:::

Cloudflare Registrar と日本レジストラの比較

Cloudflare Registrar の素晴らしいところを、AI にピックアップしてもらいましたー！あれ？これなんか既視感があるような…

- 意味不明なステルス上乗せ請求がない  
- 初年度だけ安くして、2年目に高額請求とかない  
- 知らぬ間に有料オプションが勝手についてることもない  
- Whois代行が突然有料化したりしない  
- 解約やDNS変更の導線がUXトラップになってない  
- 自動更新のON/OFFがちゃんとユーザー主導  
- メール通知が「気づかせない設計」になってない  
- UIがシンプル。余計なバナーや勧誘が一切ない  
- 「DNSは自社のを使え」みたいな縛りがない  → DNS の自由設定について曖昧な表現でした。ご指摘を受けて修正します。Cloudflare Registrar は基本的に Cloudflare DNS を利用する前提となっています。
- あくまで“ドメインの管理者”として中立で透明な立場を守ってる

おわかりでしょうか？

Cloudflare Registrar の素晴らしいところは「ユーザーを騙すような設計をしない」というところです。

中立。正直。オープン。

私達ユーザーが必要としているのは、安さでもサポートでもなく、透明性。私達日本人は、透明性に敏感です。嘘や隠蔽にうんざりしています。

Cloudflare Registrar であっても、原価が値上げされた場合は値上げされる。それはどのレジストラも同じです。しかし、意味不明なステルス上乗せ請求がないし知らぬ間に有料オプションが付いているなんてこともない。誠実で素晴らしいと思います。

:::discovery
もっと Cloudflare Registrar が安いイメージだったのだが、ここ最近の円安（ドル高）の影響で差が縮まってしまった
:::

| ドメイン | レジストラ名         | 新規取得費用              | 更新費用（差額）          |
| -------- | -------------------- | ------------------------- | ------------------------- |
| .dev     | Cloudflare Registrar | 約 1,527 円（$10.18） | 約 1,527 円（±0 円）  |
|          | ムームードメイン     | 3,245 円                  | 3,245 円（+1,718 円） |
| .com     | Cloudflare Registrar | 約 1,566 円（$10.44） | 約 1,566 円（±0 円）  |
|          | ムームードメイン     | 999 円                    | 1,728 円（+162 円）   |
| .net     | Cloudflare Registrar | 約 1,776 円（$11.84） | 約 1,776 円（±0 円）  |
|          | ムームードメイン     | 1,848 円                  | 1,848 円（+72 円）    |

:::warning
※価格は為替レートやキャンペーンにより変動する可能性があります。
:::

Cloudflare Registrar の価格が変わらない理由

Cloudflare Registrar が安定してる理由は、中間マージンや手数料を一切取らない「原価提供」モデルにある。

通常のレジストラは登録料に加え、数百円〜数千円の上乗せがあるのに対し、Cloudflare はレジストリ（.com などの管理元）と ICANN に支払う実費のみで提供してるというわけです。

Cloudflare Registrar にするメリット

- 「10 年使っても価格が変わらない」
- 「余計なメールもオプションもこない」
- 「ドメイン操作が速くて直感的」

また、更新時も追加料金ゼロで、広告や不要なオプションの押し売りもなし。利益を目的にせず、Cloudflare DNS との連携によるシンプルで安全な運用を重視してるから、価格が圧倒的に安いのですよ。

Cloudflare Registrar にドメインを移管する手順

レジストラによって違うと思うが、概ねこんな感じ

Cloudflare にログインし、対象ドメインを追加（DNS 設定）
   → DNS レコードを事前に Cloudflare 側にコピーしておきます。

:::info
※ ご指摘をいただきました。移管元で whois 情報を「代理公開」にしている場合、移管時に一時的に解除しないと Cloudflare 側で所有者情報を正しく取得できないことがあります。代理公開を解除し、登録者情報を確認できる状態にしてから進めるのがおすすめです。
:::

現在のレジストラでドメインロックを解除
   → 「移管ロック解除」や「レジストラロック解除」と記載されていることが多いです。

Auth Code（認証コード）を取得
   → 現在のレジストラの管理画面から取得できます。

Auth Code（認証コード）を取得 → 現在のレジストラの管理画面から取得します。また、多くのレジストラでは whois 代理公開（proxy）を有効にしていると、移管時に一時的な解除が必要となる場合があります。

Cloudflare Registrar の画面から移管申請を開始
   → 対象ドメインを選び、Auth Code を入力して申請します。

登録者情報を確認・入力し、1 年分の更新費用を支払う
   → Cloudflare は原価で提供、追加料金はかかりません。

旧レジストラ側で承認操作（メールや管理画面）
   → 承認メールが届く場合は確認を。何もしなくても数日で進むこともあります。

移管完了（通常は数時間〜数日）
   → Cloudflare 管理下に入り、以後は更新も原価で行えます。

:::success
アドバイスをいただきました。なお、Cloudflare Registrar は whois redaction に対応しており、移管後は代理公開とほぼ同等の情報保護が行われる仕様になっています。
:::


特徴とサービス内容の比較

| 項目           | Cloudflare Registrar            | 日本のレジストラ                           |
| -------------- | ------------------------------- | ------------------------------------------ |
| ドメイン価格   | 原価（レジストリ + ICANN 料）   | 上乗せ料金あり（手数料含む）               |
| 更新料         | 追加手数料なし                  | 自動更新時に高め設定が多い                 |
| セキュリティ   | DNSSEC 対応・ハイジャック防止   | 対応状況はレジストラにより異なる           |
| 対応 TLD 数    | 200 以上対応（.com, .dev など） | TLD 制限あり（.co.jp など日本向け中心）    |
| UI・日本語対応 | 英語 UI のみ                    | 日本語対応あり                             |
| DNS 管理       | Cloudflare DNS 必須             | 任意（自由な DNS 設定可能）                |
| 価格の透明性   | 明瞭・手数料ゼロ                | 不明瞭なことも（割引後に自動更新高額など） |

各レジストラの特徴

Cloudflare Registrar

- 向いている層：個人開発、スタートアップ、toC SaaS向け
- 価格の透明性：中間マージンなしの卸価格で提供
- セキュリティ：DNSSEC や 2 段階認証など高度なセキュリティ機能を標準装備
- 対象ドメイン：.com、.net、.org など主要な gTLD に対応。jp ドメインは未対応
- UI/UX：シンプルで直感的な管理画面

Route 53（AWS）

- 向いている層：受託開発会社 / SE系法人案件
- AWS統合：EC2、S3、CloudFront など AWSサービスとネイティブに連携可能
- 高信頼DNS：高可用性のルートサーバーで構成、エンタープライズでも採用例多数
- 管理画面：AWSコンソール上で一元管理可能。逆に言えば「AWSに慣れてないとつらい」
- 対応ドメイン：主要な gTLD/.jp など幅広く対応。料金はやや高めだが信頼重視の法人に◯
- 注意点：個人用途にはややオーバースペックか

お名前.com

- 向いている層：ドメイン管理初心者
- 国内最大手：豊富なドメイン種類と高い知名度
- 初年度無料：.com ドメインは初年度 0 円で取得可能
- サポート体制：24 時間 365 日の電話サポートを提供
- ドメイン自動更新：デフォルトでON

ムームードメイン

- 向いている層：Web制作会社 / フリーランスデザイナー
- 初心者向け：分かりやすい管理画面と親しみやすいデザイン
- 連携サービス：ロリポップ！など GMO ペパボの他サービスとスムーズに連携
- Whois 代行：無料で Whois 情報公開代行サービスを提供
- 価格：取得費用は安価だが、更新費用はやや高め

総合評価

| 項目                 | Cloudflare Registrar      | ムームードメイン          |
| -------------------- | ------------------------- | ------------------------- |
| 価格の安さ           | ◎（更新費用も原価）       | ○（新規は安いが更新高め） |
| ドメイン種類         | △（gTLD 中心  なし）  | ◎（.jp や .co.jp に対応） |
| 管理画面の使いやすさ | ◎（シンプルで広告なし）   | ○（日本語 UI、やや煩雑）  |
| サポート体制         | △（英語対応のみ）         | ◎（日本語サポートあり）   |
| セキュリティ機能     | ◎（DNSSEC・2FA など充実） | ○（基本的な保護あり）     |

終わりに

Cloudflare Registrar は、価格の透明性と高度なセキュリティ機能を求めるユーザーに最適。ただし、jp ドメインには対応していないため、国内向けのサービス展開には注意が必要

お名前.com は、多彩なドメイン種類とサポート体制が魅力ですが、操作性や不要なオプションには注意が必要

ムームードメインは初心者に扱いやすく、他サービスとの連携も魅力。更新費用がやや高めな点は考慮する

参考

こちらのリンクは、レジストラの更新費用が掲載されてるページ

https://muumuu-domain.com/domain/price

https://www.onamae.com/service/d-renew/

https://cfdomainpricing.com/

自分のニーズや技術レベルに応じて、最適なレジストラを選んでいくことが、賢いドメイン管理への第一歩]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[GitHub でブランチを完全に削除する方法]]></title>
            <link>http://izanami.dev/post/ee11a042-393d-4b69-926c-b311d79dace9</link>
            <guid>http://izanami.dev/post/ee11a042-393d-4b69-926c-b311d79dace9</guid><dc:creator>commte</dc:creator>
            <pubDate>Thu, 27 Mar 2025 09:30:02 GMT</pubDate>
            <description><![CDATA[GitHub を使っていると、使い終わったブランチや一時的に作ったブランチがリポジトリに残り続けてしまい、ブランチ一覧が散らかってしまうことがあります。定期的に不要なブランチを削除することで、チーム全]]></description>
            <content:encoded><![CDATA[GitHub を使っていると、使い終わったブランチや一時的に作ったブランチがリポジトリに残り続けてしまい、ブランチ一覧が散らかってしまうことがあります。定期的に不要なブランチを削除することで、チーム全体の作業効率を高め、意図しないブランチへの push などのミスも防げます。

:::success
本記事では、GitHub 上でブランチを完全に削除する方法から、ローカル環境の整理、リモート追跡ブランチの同期まで、ブランチ削除に関する一連の手順をわかりやすく解説します。
:::

GitHub（リモート）で削除

1. main ブランチにマージ済みであることを確認
2. GitHub 上部メニューから Code &gt; main を選択
3. View all branches をクリック
4. 「Your branches」から不要なブランチの 🗑️ を押す

削除後は、他のメンバーがまだそのブランチを使っていないか、影響がないかを念のため確認しておくと安全です。共同作業をしているプロジェクトの場合は、削除の前に Slack や Issue などで一言共有しておくと安心です。

ローカルブランチ削除

ローカルブランチは、すでにリモートにマージされていて不要になったタイミングで削除すると良いです。以下のコマンドで安全に削除できます。



 オプションは強制削除ですが、もし安全のため確認付きで削除したい場合は  を使います（未マージの場合は削除されません）。



リモート追跡ブランチを同期（キャッシュ削除）



リモートで削除されたブランチ情報が、ローカルには「追跡ブランチ」として残ってしまうことがあります。 を実行することで、存在しなくなったリモートブランチの情報がローカルからも削除され、より正確な状態になります。

これはあくまで「追跡情報（キャッシュ）」の削除であり、ローカルの実ブランチそのものは削除されません。実ブランチの削除は前述の  で行ってください。

確認



ブランチ削除時の注意点

削除前に必ず、必要な変更がすべて main や他のブランチにマージ済みであることを確認しましょう。

誤って削除した場合は、GitHub の UI から復元できる場合もありますが、基本的にはログなどからブランチを再作成する必要があります。

チームで作業している場合は、勝手に他人のブランチを削除しないように気をつけましょう。

GitHub やローカルでのブランチ削除を正しく行うことで、開発環境をすっきり保つことができます。特にチーム開発では、使い終わったブランチの放置は後から混乱を招く原因になりがちです。今回紹介した手順を参考に、定期的なブランチの整理を心がけましょう。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Astro で、JavaScript が動作しないときは is:inline を使う]]></title>
            <link>http://izanami.dev/post/f0568376-38db-488b-9318-ed9dd6053691</link>
            <guid>http://izanami.dev/post/f0568376-38db-488b-9318-ed9dd6053691</guid><dc:creator>commte</dc:creator>
            <pubDate>Thu, 13 Mar 2025 17:44:57 GMT</pubDate>
            <description><![CDATA[Astro でビルドしたが、スクリプトが動かないとき、ターミナルを見ると以下のような警告が出ることがある。

xxxx

まずは、Astro でのクライアントサイドスクリプトの処理方法を確認する。

]]></description>
            <content:encoded><![CDATA[Astro でビルドしたが、スクリプトが動かないとき、ターミナルを見ると以下のような警告が出ることがある。

xxxx

まずは、Astro でのクライアントサイドスクリプトの処理方法を確認する。

属性

Astro では、クライアントサイドの JavaScript を正しく動作させるために、スクリプトに特別な属性を追加する必要がある場合がある。

それは、 属性である。

Astro では、UI フレームワーク（React、Svelte、Vue など）を使用せずに、標準の HTML script タグを使用して Astro コンポーネントにインタラクティビティを追加できます。これにより、JavaScript をブラウザで実行し、Astro コンポーネントに機能を追加することができます。

https://docs.astro.build/en/guides/client-side-scripts/

デフォルトでは、Astro は script タグを処理してバンドルし、npm モジュールのインポート、TypeScript の記述などをサポートしている。

しかし、is:inline ディレクティブを追加することで、Astro がスクリプトを処理しないようにすることができる。

この場合、スクリプトはそのまま HTML にレンダリングされ、ローカルインポートは解決されず、動作しなくなる。また、コンポーネント内にある場合、コンポーネントが使用されるたびにスクリプトが繰り返される。

Astro がスクリプトを処理しないようにするには、is:inline ディレクティブを追加する。



CDN からのスクリプト読み込み

しかし、Astro では、is:inline スクリプト内でのインポートは通常の ES モジュールインポートとして処理されず、クライアントサイドでエラーになることがある。そんなケースでは、cdn を直接読み込ませてもよい。



スクリプトの順序を修正

それでもなお、is:inline 属性が HTML に反映されないことがある。これは Astro のビルドプロセスの仕様で、is:inline 属性はビルド時に処理されるだけで、最終的な HTML には含まれない。

このようなケースでは、スクリプトの順序を修正し、Swiper のライブラリが先に読み込まれるようにする。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Supabase ビューの使い方]]></title>
            <link>http://izanami.dev/post/70cfdeab-7d18-4ad7-bdbd-38a901ae8ad6</link>
            <guid>http://izanami.dev/post/70cfdeab-7d18-4ad7-bdbd-38a901ae8ad6</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 03 Feb 2025 09:43:19 GMT</pubDate>
            <description><![CDATA[データベース設計において、セキュリティと使いやすさの両立は常に課題となっています。そんな中、Supabase のビュー機能は、この課題を解決する強力なツールとして注目を集めています。では、具体的にどの]]></description>
            <content:encoded><![CDATA[データベース設計において、セキュリティと使いやすさの両立は常に課題となっています。そんな中、Supabase のビュー機能は、この課題を解決する強力なツールとして注目を集めています。では、具体的にどのような場面でビューが活躍するのでしょうか？

ビューを使うべき場面

最もよくあるケースは、ユーザーに見せたくないデータを含むテーブルがある場合です。例えば、ユーザーテーブルには機密性の高い情報が含まれているため、直接アクセスさせたくありません。このような状況で、ビューが重要な役割を果たすのです。

以下は、機密情報を含むユーザーテーブルの例です：



ビューの基本的な作り方

ビューの作成は、想像以上にシンプルです。基本的な SQL の知識があれば、誰でも作成することができます。ただし、セキュリティを確保するためには、いくつかの重要なポイントを押さえる必要があります。



セキュリティを考慮したビューの実装

セキュリティを確保するために、特に注意が必要なのが SECURITY DEFINER の使用です。この機能を使うことで、ビューを通じてのみデータにアクセスできるようになり、より安全なデータ管理が可能になります。



パフォーマンスの最適化

セキュリティが確保できたら、次は性能面での最適化を考えましょう。特に大量のデータを扱う場合、適切な設計を行わないとパフォーマンスに影響が出る可能性があります。



実装時の注意点

ビューを実装する際は、以下の点に特に注意を払う必要があります：

- アクセス権限の適切な設定
- パフォーマンスへの影響の考慮
- メンテナンス性の確保

これらの点を意識することで、より堅牢なシステムを構築することができます。



まとめ

Supabase のビューは、セキュリティと利便性を両立させる強力なツールです。適切に実装することで、安全かつ効率的なデータアクセスが実現できます。より詳細な実装例やベストプラクティスについては、Supabase の公式ドキュメントを参照することをお勧めします。

参考リンク

- [Supabase Database Documentation](https://supabase.com/docs)
- [Database Views Best Practices](https://supabase.com/docs/guides/database)
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[エンジニアのための Cursor Agent プロンプトガイド]]></title>
            <link>http://izanami.dev/post/15f00bf3-9612-48aa-a310-a630d4cdb63e</link>
            <guid>http://izanami.dev/post/15f00bf3-9612-48aa-a310-a630d4cdb63e</guid><dc:creator>commte</dc:creator>
            <pubDate>Sun, 26 Jan 2025 12:54:39 GMT</pubDate>
            <description><![CDATA[エンジニアのための Cursor Agent プロンプトガイド。効率的なコード生成、リファクタリング、バグ修正のためのプロンプトパターンを解説。

基本的な使い方

Cursor Agent は  で]]></description>
            <content:encoded><![CDATA[エンジニアのための Cursor Agent プロンプトガイド。効率的なコード生成、リファクタリング、バグ修正のためのプロンプトパターンを解説。

基本的な使い方

Cursor Agent は  で起動し、自然言語で指示を出すことができます。以下のプロンプトパターンを活用することで、より精度の高い結果が得られます。

:::info
これらのプロンプトパターンは、プロジェクトや状況に応じてカスタマイズしてください。また、機密情報や個人情報を含めないよう注意が必要です。
:::

コード生成プロンプト



リファクタリングプロンプト



バグ修正プロンプト



テスト生成プロンプト



コードレビュープロンプト



ドキュメント生成プロンプト



プロジェクト分析プロンプト



Tips & Tricks

コンテキストの提供

- 関連するコードやドキュメントへの参照を含める
- プロジェクトの制約条件を明確に伝える
- 使用している技術スタックを明示する

段階的な指示

- 複雑な要求は小さなステップに分割する
- 各ステップの結果を確認しながら進める
- 必要に応じて追加の詳細を提供する

フィードバックの活用

- 生成された結果に対してフィードバックを与える
- より具体的な制約や要件を追加する
- 良い結果が得られたプロンプトを記録する
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Cursor のインストールとセットアップ方法]]></title>
            <link>http://izanami.dev/post/ae129d74-aa85-405c-86a9-bd1771a3fd7a</link>
            <guid>http://izanami.dev/post/ae129d74-aa85-405c-86a9-bd1771a3fd7a</guid><dc:creator>commte</dc:creator>
            <pubDate>Sun, 26 Jan 2025 10:19:05 GMT</pubDate>
            <description><![CDATA[Cursor は、AI を活用した開発者向けのコードエディタで、コード補完、リファクタリング、バグ検出、ドキュメント生成などをサポートする頼もしいエディター君です。

VSCode などからの設定イン]]></description>
            <content:encoded><![CDATA[Cursor は、AI を活用した開発者向けのコードエディタで、コード補完、リファクタリング、バグ検出、ドキュメント生成などをサポートする頼もしいエディター君です。

VSCode などからの設定インポートや SSH 接続に対応し、高いカスタマイズ性と柔軟性を提供します。リアルタイムのコラボレーション機能も備え、効率的な開発環境を実現します。ソフトウェアエンジニアやデータサイエンティストに最適な次世代型エディタなんですね。

最初はHobbyプランでいいかと思いますが、料金について補足しておきます。

:::info
Hobbyプランは無料で、2000回の補完と50回のスロープレミアムリクエストが含まれます。
Proプランは月額20ドルで、無制限の補完、月500回の高速リクエスト、毎日10回の特別機能が利用可能です。
:::

ソフトウェアエンジニアである私は、早速インストールして使ってみました。結局開発体験が素晴らしかったので、翌日には PRO 版にしました😅

![PRO版契約！！一変の悔い無し](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/ff9c1cc0-3859-4464-b115-49a6650f41ec.png)

公式サイトからダウンロード

Cursor は、こちらからダウンロードします。

https://www.cursor.com/

セットアップ

インストールすると最初に以下の画面が表示されます。全部英語なので分かりやすいように日本語で解説します。

開発者向けエディタまたは AI 支援ツールのセットアップ中に見られる典型的なオプションを含んでいて、キーバインド、言語設定、コードベース機能、ターミナルコマンドのインストールといった操作が可能です。

![セットアップ](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/978fec24-a633-45c0-b9d7-d5c2dafd6e20.png)

Keyboard

エディタのキーバインドを設定するセクションです。

選択可能なオプション

- Vim
- Emacs
- Atom
- Sublime
- JetBrains
- Default (VS Code)

最初の選択肢は「Default (VS Code)」になっています。

Language for AI

AI が使用する言語を指定できます。ここで最初に戸惑うと思うのですが、「日本語」と記入すればよいです。

記入例として、「Svenska（スウェーデン語）」、「中文（中国語）」、「हिंदी（ヒンディー語）」といった例が表示されています。

任意の言語を選択することで、AI がその言語を使用して応答や解析を行います。

Codebase-wide

コードベース全体の質問に対するエンベディングを計算する機能です。

Enabled（有効化）: デフォルトでこの機能は有効になっていました。

Add Terminal Command

ターミナルからコマンドを使用してエディタを起動できる機能を追加します。

Install "code" command

ターミナルから  コマンドでエディタを起動可能にします。私は有効にしました。

Install "cursor" command

ターミナルから  コマンドでエディタを起動可能にします。

Continue 設定内容を保存して次に進みましょう。

Autocomplete Preferences

![Autocomplete Preferences](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/e809f2ab-d045-4475-8f79-84638c751154.png)

この画面では、自動補完の設定を選択できます。

GH Copilot をインポートすることで、Cursor Tab を上書きできます。GH Copilot は、より強力な補完機能を持ち、以下の特徴を提供します。

- ミッドライン補完
- 完全な差分提案

選択肢

Switch to GH Copilot

GH Copilot に切り替えます。そのままですね。

Continue with Default

現在のデフォルト設定のまま進みます。

VS Code Extensions

![VS Code Extensions](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/8d6967dc-ce2e-4071-ab38-9a35076c44a0.png)

この画面では、VS Code から拡張機能や設定、キーバインドをインポートするオプションを選択できます。これにより、Cursor の試用を簡単に開始できます。

VS Code で利用している以下を即座にインポート可能です。

- 拡張機能
- 設定
- キーバインド

Data Preferences

![Data Preferences](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/3e89d6e1-3823-48e3-a04a-2fe58f6ed18c.png)

この画面では、データの取り扱いに関する設定を選択できます。

Help Improve Cursor

Cursor の改善に協力するために、使用データを収集するオプションを提供しています。

収集されるデータ

- チャットでの質問
- コードスニペット
- 編集内容
- エディタのアクション

設定は後から変更することも可能です。

Privacy Mode

プライバシーモードを有効にすると、質問やコードが Cursor または第三者によって保存されることはありません。この設定により、より高いプライバシー保護が可能になります。

You're all set

![You're all set!](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/edf4c04d-a827-408b-bbc2-6d22946f3b24.png)

この画面では、ログインまたはサインアップを求めています。AI 機能を利用するためにはログインが必要です。

Log In

既存のアカウントでログインします。

Sign Up

新しいアカウントを作成します。

Skip for now

一時的にログインせずに進むオプションです。ただし、ログインなしでは一部の AI 機能が制限される可能性があります。

注意事項

バックエンドの悪用を防ぐため、ログインを推奨しています。

Sign in

![ワイは Google を選択した](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/5c2cef7e-1fb1-430d-8a98-689a3c4a847c.png)

この画面では、サービスにログインするための選択肢が提供されています。

Email

ログインにメールアドレスを使用します。

Your email address

メールアドレスを入力するフィールドです。

Continue

入力したメールアドレスでログインを続行します。

その他のログイン方法

Continue with Google

Google アカウントを使用してログインします。

Continue with GitHub

GitHub アカウントを使用してログインします。

Sign up

アカウントを持っていない場合、サインアップリンクをクリックして新しいアカウントを作成します。

初期画面

![初期画面](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/f4945443-e7f3-4d39-911f-c3b8bca0ceeb.png)

この画面では、作業を開始するための選択肢が提供されています。

Open a folder

ローカルのフォルダを開いてプロジェクトを開始するオプションです。クリックすると、フォルダ選択ダイアログが表示されます。

Open with SSH

リモートサーバーに SSH 接続を使用してプロジェクトを開くオプションです。リモート環境での作業を行いたい場合に選択します。

Composer タブ

![Composer](https://api.izanami.dev/storage/v1/object/public/pictures/eyecatch/693de456-fddd-4a72-af58-9c9b6d35763e/94e185d7-d8bb-454f-9c6c-45bc0fc7eb17.png)

この画面では、コード編集や AI を利用したサポートが可能な Composer タブが表示されています。

編集対象ファイル

README.md

現在編集しているファイル名がタブに表示されています。ファイルの切り替えや新規ファイルの作成が可能です。

操作ガイド

ショートカット

- Edit code (⌘I): コード編集モードを開始します。
- @ to mention: メンションを挿入します。
- ⬆⬇ to select: 項目を選択する際に使用します。

AI モデル

モデル選択

最初に選択されている AI モデルはです。必要に応じてモデルを切り替えたり追加機能を利用できます。

操作モード

normal / agent

現在のモードはで、必要に応じてモードに切り替えることが可能です。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Next.js 15 ことはじめ]]></title>
            <link>http://izanami.dev/post/aaaaf24e-df0f-40ef-a6d6-3219cff2ea83</link>
            <guid>http://izanami.dev/post/aaaaf24e-df0f-40ef-a6d6-3219cff2ea83</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 06 Jan 2025 09:41:01 GMT</pubDate>
            <description><![CDATA[https://nextjs.org/

インストール



以下が表示される。基本的には全部 Enter で OKだが、「Would you like to customize the import]]></description>
            <content:encoded><![CDATA[https://nextjs.org/

インストール



以下が表示される。基本的には全部 Enter で OKだが、「Would you like to customize the import alias」のところを、Yes にしておくとエイリアスが使いやすくなる。

src/

tsconfig.json

 と  を追加。



Tailwind CSS

レスポンシブで便利になるので  の設定をする。レスポンシブ用に  も追加しておく。



TOP

トップページの作成。



Header

public フォルダに  を配置して以下を作成する。その後  コンポーネントを作成する。



Footer

同じように  を作成する。



global.css

 を以下に変更する。



style.scss

ターミナルを分割して開いて、以下を実行する。



src/app/css フォルダ以下に  を作成する。サイト全体で使うスタイルや、Tailwind で対応したくないスタイルを記述するときに使う。



layout.tsx

次に  を追加する。

 を指定することで、コンテンツが無くても、フッターが画面下部に固定される。

antialiased

favicon

 ディレクトリに以下の 3 つのファビコンファイルを入れる。

- favicon.ico
- icon.ico
- apple-icon.png

これらのアイコンファイルを  ディレクトリ内に置くだけで、Next.js が自動的に  タグに適切なメタデータを生成してくれる。

その後、ターミナルで  を叩き、 にアクセスすると画面が表示されるはず。]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Next.js : Element type is invalid エラーについて]]></title>
            <link>http://izanami.dev/post/0c5d45af-0c1e-473b-9aae-5a0b7153518d</link>
            <guid>http://izanami.dev/post/0c5d45af-0c1e-473b-9aae-5a0b7153518d</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 23 Dec 2024 16:32:34 GMT</pubDate>
            <description><![CDATA[Element type is invalid エラーについて



意訳すると以下。



しかし、エクスポートの問題でない場合、サーバーコンポーネントとクライアントコンポーネントの混在が影響してい]]></description>
            <content:encoded><![CDATA[Element type is invalid エラーについて



意訳すると以下。



しかし、エクスポートの問題でない場合、サーバーコンポーネントとクライアントコンポーネントの混在が影響している可能性がある。


Next.js では、デフォルトで  が指定されていないコンポーネントはサーバーコンポーネントとして扱われます。サーバーコンポーネントでは以下が利用できない。

- DOM 操作
- ブラウザ固有の API（例: , ）

そのため、クライアント専用ロジックや依存関係がエラーを引き起こした可能性がある。

解決方法

 を使い動的インポートし、 を指定することで、クライアントコンポーネントとして強制的に動作させる。

例。


]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[ Next.js 14 or 15 : force-dynamic の使い所]]></title>
            <link>http://izanami.dev/post/5531e966-25ba-42fa-aaf8-0cd01544d635</link>
            <guid>http://izanami.dev/post/5531e966-25ba-42fa-aaf8-0cd01544d635</guid><dc:creator>commte</dc:creator>
            <pubDate>Sat, 23 Nov 2024 16:54:19 GMT</pubDate>
            <description><![CDATA[ の使い所

Next.js 〜14 系で使う。

特徴

- ページを動的レンダリング（SSR: Server-Side Rendering）に強制
- キャッシュを無効化し、リクエストごとに新しい]]></description>
            <content:encoded><![CDATA[ の使い所

Next.js 〜14 系で使う。

特徴

- ページを動的レンダリング（SSR: Server-Side Rendering）に強制
- キャッシュを無効化し、リクエストごとに新しいデータを取得
- この設定を使うと、すべてのリクエストをサーバーで処理

メリットとデメリット

 を設定すると、SEO 強化と CSP ヘッダーを動的に設定するという利点がある。しかし、パフォーマンスの低下というデメリットもあるため、トラフィック量やサーバーリソースに応じて最適な設定を検討する必要がある。

 に これを設定すると、そのレイアウトが適用されるすべてのページがサーバーサイドレンダリング（SSR）になる。つまり、全ページが動的にサーバーでレンダリングされ、各リクエストごとに最新のHTMLが生成される。



- ページのキャッシュを無効に
- サーバーサイドレンダリング（SSR）を強制し、リクエストごとに新しいデータを取得

結論

-  を設定している場合、 を書く必要はない
-  が優先されるため、 の設定は無視される
- Next.js 15 では、 を使う必要がほとんどない

Next.js 15 のキャッシュ仕様の変更

Next.js 15 では、 を使う必要がほとんどなくなった。

Next.js 15 でデフォルトでキャッシュが無効になっている理由は以下。

 が暗黙的に設定されているわけではなくて、以下のような設計変更によるもの。

非同期 API の強化によるデフォルトキャッシュの変更

- Next.js 15 では、非同期 API（params, searchParams など）が Promise 化
- これにより、リクエストごとにデータを取得する動的な挙動がデフォルトになった

非同期関数 (async) が自動的に動的レンダリングに切り替わる。例えば、ページやコンポーネント内で非同期データを取得する場合、明示的に  を指定しなくても動的レンダリングが適用される。



fetch のキャッシュ動作の変更

- Next.js 14 以前: fetch のデフォルトはキャッシュが有効（force-cache）
- Next.js 15: fetch のデフォルトはキャッシュ無効（no-store）

新しい開発者体験の設計

- Next.js 15 では、「データの鮮度を明示的に管理する」という方向性に変更された
- 開発者がキャッシュを利用する場合、明示的に  や  を指定する必要がある

完全に動的なページ

例 : 最新の投稿一覧やユーザーごとのダッシュボード。ルートの  に以下を記述する。



設定例



ある程度キャッシュしたいページ

例: トップページや頻繁に更新されない情報。



部分的にキャッシュを使いたい場合



静的でよいページ

例: プライバシーポリシーや利用規約のような固定ページ。



なぜ dynamic = "force-dynamic" を選ぶのか？

- 投稿型サービスの場合リアルタイム性が重要なため、動的レンダリングが必要。
- 常に最新のデータを取得できる。
- キャッシュが無効化されることで、投稿や更新が即時反映される。

注意点

- サーバー負荷: 動的レンダリングは、トラフィックが増加すると負荷が高くなる。
- データベース負荷: リクエストごとにデータを取得するため、効率的なクエリ設計が重要。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Framer Motion で、ハンバーガーメニューを実装する]]></title>
            <link>http://izanami.dev/post/595b2538-7b4e-4fc3-bf56-abef07a372c6</link>
            <guid>http://izanami.dev/post/595b2538-7b4e-4fc3-bf56-abef07a372c6</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 18 Nov 2024 12:22:27 GMT</pubDate>
            <description><![CDATA[Framer Motion とは

Framer Motion は、React アプリケーションにアニメーションを簡単に追加できるライブラリです。軽量で柔軟性が高く、エンジニアにとって自然なアニメーシ]]></description>
            <content:encoded><![CDATA[Framer Motion とは

Framer Motion は、React アプリケーションにアニメーションを簡単に追加できるライブラリです。軽量で柔軟性が高く、エンジニアにとって自然なアニメーションを簡単に実装するためのツールを提供してくれます。アニメーションの設定も直感的で、コードもシンプルに保つことができます。

ハンバーガーメニューをクリックしてみてください。

https://codesandbox.io/p/sandbox/6zdv3h

メニュー以外をクリックしたときも、メニューが閉じるようにしています。ハンバーガーメニューの動きは、 を指定してバネのような動きを取り入れています。とても滑らかですね。

実装環境

- React
- Framer Motion

Framer Motion

https://motion.dev/

インストール

まずは Framer Motion をインストールします。



実装コード

以下は Framer Motion を使ったハンバーガーメニューの実装コードです。



以下は、CSS です。



transition type の設定

Framer Motion では、アニメーションのタイプを簡単に指定できます。今回のコードでは  と  の 2 種類のアニメーションタイプを使っています。

:

- バネのように自然な動きでアニメーションします。 や  の設定によって、どれだけ弾力があるかを調整できます。
- ハンバーガーアイコンの開閉部分に使用し、滑らかな感触を出しています。

:

- 一定速度でアニメーションを行います。 で動きの速さを設定でき、 などのイージングで滑らかさも調整可能です。
- メニューのスライドイン・スライドアウトに使用し、確実にスムーズな動作を保証します。

 は物理的な動きをシミュレートするので、インタラクティブな要素（例えばボタンのクリック）に適しており、 は指定した時間内にアニメーションを完了させるので、ページ全体やメニューのトランジションに向いています。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[ChunkLoadError: Loading chunk app/layout failed. の解決方法]]></title>
            <link>http://izanami.dev/post/6daf48ba-5eff-4254-8a83-0c5f0084a128</link>
            <guid>http://izanami.dev/post/6daf48ba-5eff-4254-8a83-0c5f0084a128</guid><dc:creator>commte</dc:creator>
            <pubDate>Thu, 14 Nov 2024 18:08:24 GMT</pubDate>
            <description><![CDATA[Next.js のローカル立ち上げ時に、以下のエラーが出ることがあります。



そもそも、これ何やねん？

「ChunkLoadError」は、Next.js でコードの分割（chunking）やキ]]></description>
            <content:encoded><![CDATA[Next.js のローカル立ち上げ時に、以下のエラーが出ることがあります。



そもそも、これ何やねん？

「ChunkLoadError」は、Next.js でコードの分割（chunking）やキャッシュが関係するエラーです。特に、古いキャッシュが邪魔をして、新しいコードのロードに失敗すると発生します。これは、ブラウザやビルドのキャッシュが不整合を起こした場合に起こりやすいエラーです。

.next ディレクトリを削除して、 npm run dev

.next ディレクトリには Next.js のビルドキャッシュが保存されています。このディレクトリを削除することで、Next.js は新しいキャッシュを生成します。これにより、古いキャッシュが原因のエラーが解消されることがよくあります。



このエラーは、ローカルでのコードの変更や依存関係のアップデートにより、キャッシュが古い情報を保持してしまったときに発生しやすいです。また、特定のライブラリや依存関係が不安定な場合にも引き起こされることがあります。

キャッシュをクリアしても解決しない場合

上記の方法でもエラーが解消されない場合は、以下のような追加の対策も検討してみてください。

依存パッケージの再インストール

一部の依存関係が壊れている可能性があるため、nodemodules ディレクトリを削除し、再インストールします。



Next.js の「ChunkLoadError」は開発中に突然出てくる厄介なエラーですが、冷静にキャッシュを削除したり依存関係をリセットすることで、解決できることが多いです。このエラーが出たら、まずは .next ディレクトリを削除して、npm run dev を試してみてください。それでもダメなら、パッケージの再インストールやブラウザキャッシュのクリアを試すと良いでしょう。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[使ってないパッケージを確認する depcheck]]></title>
            <link>http://izanami.dev/post/c3bf300f-72cb-4fd2-a47a-02f00d083ace</link>
            <guid>http://izanami.dev/post/c3bf300f-72cb-4fd2-a47a-02f00d083ace</guid><dc:creator>commte</dc:creator>
            <pubDate>Thu, 14 Nov 2024 17:45:58 GMT</pubDate>
            <description><![CDATA[あるパッケージをインストールしたものの、実際にそのパッケージを使ってコードを書いていないケースはよくあるかと思います。

インストール

まずは、depcheck をグローバルにインストールしましょう]]></description>
            <content:encoded><![CDATA[あるパッケージをインストールしたものの、実際にそのパッケージを使ってコードを書いていないケースはよくあるかと思います。

インストール

まずは、depcheck をグローバルにインストールしましょう。



ドキュメントはこちら

https://www.npmjs.com/package/depcheck

使ってないパッケージを確認する

 を使って、プロジェクトで使用されていないパッケージを確認します。以下のコマンドを実行するだけです。



実行すると、例えば以下のような結果が表示されます。



Unused dependencies は、プロジェクトのコード内で 使用されていない依存パッケージ を指します。具体的には、プロジェクトにインストールされている依存関係（package.json の dependencies や devDependencies に記載されたパッケージ）で、実際にコード内で インポートや使用が確認できないもの を指しています。

削除する場合

これらのパッケージを削除する場合は、上述したケースだと以下のようにアンインストールできます。



注意点

depcheck の結果として表示されたこれらのパッケージは、プロジェクト内で直接使用されていない可能性が高いことを示しています。ただし、削除する前に以下の点を確認すると安全です。

間接的な使用の確認

他のパッケージが内部で依存しているケースもあります。プロジェクト内で直接インポートや  していなくても、これらのパッケージが一部のモジュールの内部で使用されている可能性があります。

環境依存のスクリプトや設定の確認

ビルドスクリプトやテスト環境など、特定の環境でのみ使用される場合は、 では未使用として検出されることがあります。設定ファイルやスクリプトに依存関係が書かれていないかを確認してください。

まとめ

 は、使われていないパッケージを素早く見つけるのに便利なツールです。しかし、削除する前には、そのパッケージが間接的に使用されていないか慎重に確認することが大切です。依存関係を整理して、プロジェクトをスリムに！
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Next.js で正しく favicon を設定する]]></title>
            <link>http://izanami.dev/post/8e61d789-f498-4a65-b6e6-7e63c3392f9e</link>
            <guid>http://izanami.dev/post/8e61d789-f498-4a65-b6e6-7e63c3392f9e</guid><dc:creator>commte</dc:creator>
            <pubDate>Tue, 12 Nov 2024 16:00:18 GMT</pubDate>
            <description><![CDATA[最近、自分の Next.js プロジェクトでも 意外と favicon の設定に手間取りました。特に何も考えずに  フォルダに置いた  が原因でエラーが出ていたんですが、その対処方法をここに書いておき]]></description>
            <content:encoded><![CDATA[最近、自分の Next.js プロジェクトでも 意外と favicon の設定に手間取りました。特に何も考えずに  フォルダに置いた  が原因でエラーが出ていたんですが、その対処方法をここに書いておきます。これが同じように悩んでいる方の助けになればと思います。

favicon の設定

以下のようなエラーが出る場合があります。



これを防ぐには、 ディレクトリに以下の 3 つのファイルを入れます。

- favicon.ico
- icon.ico
- apple-icon.png

これらのアイコンファイルを  ディレクトリ内に置くだけで、Next.js が自動的に  タグに適切なメタデータを生成してくれます。
また、同時に  フォルダに配置している  を削除することを忘れないでください。これを残したままにすると、上記のエラーが発生する原因になります。

[参考：Delba Oliveira's tweet on handling favicons](https://x.com/delbaoliveira/status/1813589485235421489)

>  フォルダに  ファイルをドロップすると、Next.js が自動的に  タグ内に正しいメタデータを生成してくれます。

例えば、以下のようなコードが自動的に生成されます。



これで、ブラウザが正しくアイコンを読み込んでくれるようになります。

Next.js における favicon 設定のベストプラクティス

favicon の設定について、いくつかのベストプラクティス。

適切なファイル形式とサイズを使用する

favicon は一般的に  ファイル形式が使用されますが、その他に  などもサポートされています。16x16、32x32 などのサイズを用意することで、様々なデバイスに対応できます。

複数のアイコンを用意する

デバイスによって使用されるアイコンが異なるため、 や  など複数のバリエーションを用意しておくと、iOS や Android などのモバイル端末にも対応できます。

コードでのカスタマイズ

自動的に生成されるコードに加えて、独自に  タグを追加することで、特定のプラットフォームに向けたアイコンをカスタマイズできます。例えば、以下のように  を追加することができます。

 

おわりに

favicon の設定は小さなことのように思えますが、プロジェクト全体の完成度を高める重要なポイントです。この手順を踏むことで、よりスムーズに favicon を反映させることができます。もし同じようなエラーに直面している方がいたら、この記事が少しでも助けになると嬉しいです。

参考

https://stackoverflow.com/questions/62116093/why-do-i-keep-getting-a-500internal-server-error-get-http-localhost3000-fav
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Next.js の Image コンポーネントでローカル画像を表示する]]></title>
            <link>http://izanami.dev/post/f160a70e-535c-4809-ba24-bba307c12d9a</link>
            <guid>http://izanami.dev/post/f160a70e-535c-4809-ba24-bba307c12d9a</guid><dc:creator>commte</dc:creator>
            <pubDate>Mon, 11 Nov 2024 15:16:12 GMT</pubDate>
            <description><![CDATA[Image コンポーネントでローカル画像を扱う利点

Next.js の  コンポーネントを使うと、こんなメリットがあります。

- 自動最適化: 画像はビルド時に自動で最適化されるので、無駄なデータ]]></description>
            <content:encoded><![CDATA[Image コンポーネントでローカル画像を扱う利点

Next.js の  コンポーネントを使うと、こんなメリットがあります。

- 自動最適化: 画像はビルド時に自動で最適化されるので、無駄なデータを削ぎ落として、ページの読み込み速度がアップします。
- 自動幅と高さの設定: インポートされた画像から幅と高さを自動で計算してくれるから、累積レイアウトシフト（CLS）を防いで、ページがガタガタしない。
- レスポンシブ対応: デフォルトでデバイスに合わせて最適な画像を表示してくれるので、いろんな画面サイズにピッタリ合った画像が自動的に選ばれます。

画像のインポート

画像をインポートするだけで、 や  の指定は不要です。Next.js がインポートした画像の情報を使って、自動で設定してくれます。

公式サイトの一部を意訳すると、こんな感じです。

> Next.js はインポートされたファイルに基づいて画像の実際の幅と高さを自動で決定します。この情報を使って画像の比率を保持し、読み込み中の累積的なレイアウトシフト（CLS）を防ぎます。

例えば、以下のように静的な画像をインポートする場合、 コンポーネントを使うと、幅や高さを指定しなくても画像を簡単に表示できます。



Dynamic Import の注意点

> 警告: 動的な  または  はサポートされていません。インポートはビルド時に解析できるように静的である必要があります。

これは、Next.js がビルド時に画像ファイルを解析し、その情報を使って最適化するためです。だから、動的に画像をインポートすることはできず、すべての画像は静的にインポートする必要があります。

 プロパティの使用

 プロパティを使うと、ファーストビューで表示されるような重要な画像を優先的に読み込むことができます。これでユーザーが最初に見るコンテンツの読み込みが早くなり、より良い体験を提供できます。



-  プロパティ: ファーストビューに表示する重要な画像には、これを設定することで、優先的に画像を読み込ませます。

レスポンシブ画像の実装

Next.js の  コンポーネントは、レスポンシブ画像にも対応しています。例えば、 プロパティを使うことで、親要素のサイズに基づいて画像を調整できます。



- : 画像が親要素の大きさにフィットするように調整されます。
- : 画像を親要素に合わせてトリミングし、全体をカバーするように表示します。

まとめ

Next.js の  コンポーネントを使えば、画像の最適化、自動での幅・高さの設定、レスポンシブ対応など、便利な機能が盛りだくさん。ローカル画像を静的にインポートするだけで、ページのパフォーマンスを大幅に向上させ、ユーザーにとっても快適な体験を提供できます。 や  プロパティを活用して、もっと効率的に画像を管理してみましょう！

]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[Next.js でスケルトンスクリーンを実装する方法]]></title>
            <link>http://izanami.dev/post/034ae8bb-8e36-457d-a570-1466f034fd41</link>
            <guid>http://izanami.dev/post/034ae8bb-8e36-457d-a570-1466f034fd41</guid><dc:creator>commte</dc:creator>
            <pubDate>Sun, 10 Nov 2024 11:17:24 GMT</pubDate>
            <description><![CDATA[スケルトンスクリーンとは？

スケルトンスクリーンとは、ページやコンテンツが読み込まれる際に表示されるプレースホルダーのことです。ローディング中に画面が空白のままになるのを防ぎ、ユーザーに視覚的なフィ]]></description>
            <content:encoded><![CDATA[スケルトンスクリーンとは？

スケルトンスクリーンとは、ページやコンテンツが読み込まれる際に表示されるプレースホルダーのことです。ローディング中に画面が空白のままになるのを防ぎ、ユーザーに視覚的なフィードバックを提供します。

これにより、ページの読み込みが完了するまでの待ち時間を短く感じさせ、UXを向上させる効果があります。特に、API からデータを取得して動的にコンテンツを表示する場合など、遅延が発生するページで有効です。

インストール方法

スケルトンスクリーンを実装するためには、 というライブラリを利用します。このライブラリは、カスタマイズ可能なローディングアニメーションを提供し、柔軟にスケルトンを作成できます。

以下のコマンドを使用して  をインストールします。



または、yarn を使用している場合は以下のコマンドです。



これで、スケルトンスクリーンの作成に必要な準備が整いました。

実装方法

次に、 を使用してスケルトンスクリーンを実装します。以下は、サイドバーのローディング状態を表示するコンポーネントの例です。



実装の詳細

| オプション          | 説明                                                                                                                                    |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
|          | 異なるローダー同士のキーの競合を避け、正しくスケルトンスクリーンが描画されるようにしています。                                          |
|              | アニメーションの速度を指定します。値が大きいほどゆっくりとしたアニメーションになります。デフォルトは  です。                         |
|              | スケルトンスクリーンのスタイルを指定します。ここでは、 を設定してコンテナ内でのスケルトンの幅を最大化しています。          |
|            | スケルトンの描画範囲を指定します。このプロパティは、スケルトンのデザインを適切にスケーリングするために重要です。                        |
|          | コンポーネントの一意性を保証するために使用されるキーです。これにより、複数の  が同一ページ内にある場合の競合を防ぎます。 |
|  | 前景色の不透明度を指定します。値を変更することで、スケルトンのコントラストを調整することができます。                                    |
|  | 背景色の不透明度を設定します。これにより、スケルトンの視覚的な濃さを変更できます。                                                      |
|           | アニメーションの繰り返し間隔を指定します。これにより、アニメーションのループ間隔を制御できます。                                        |

まとめ

スケルトンスクリーンは、ユーザーに対するフィードバックを充実させるための重要な要素です。特に、非同期処理が多く含まれるウェブアプリケーションにおいて、ローディング時の不安感を軽減し、スムーズなユーザー体験を提供する役割を果たします。 を使用することで、簡単にカスタマイズ可能なスケルトンを実装できるため、開発効率も向上します。
]]></content:encoded>
        </item>
        <item>
            <title><![CDATA[HeadlessUI でダイアログを開いているときの overflow 問題]]></title>
            <link>http://izanami.dev/post/15f20e13-c2e6-4ab1-a0a5-2899630fa427</link>
            <guid>http://izanami.dev/post/15f20e13-c2e6-4ab1-a0a5-2899630fa427</guid><dc:creator>commte</dc:creator>
            <pubDate>Sun, 10 Nov 2024 10:34:49 GMT</pubDate>
            <description><![CDATA[問題の原因と対策

ダイアログを開いた際に、 要素に  が設定されるため、スクロールが無効化され、 要素の位置固定が機能しなくなります。以下の方法で、この問題を解決できます。

解決策 1:  を使用]]></description>
            <content:encoded><![CDATA[問題の原因と対策

ダイアログを開いた際に、 要素に  が設定されるため、スクロールが無効化され、 要素の位置固定が機能しなくなります。以下の方法で、この問題を解決できます。

解決策 1:  を使用して  を調整する

 フックを使用して、ダイアログが開かれた際に  の  スタイルを調整することで問題を解決できます。



このコードにより、ダイアログが開いている間に  の  を  に設定し、ダイアログが閉じたときに元に戻すことができます。

解決策 2:  にカスタムクラスを追加する

 コンポーネントに  クラスを追加し、 要素のスタイルを CSS で調整する方法も有効です。



そして、以下のような CSS を追加します。



これにより、 クラスを持つ要素が存在する場合に、 の  が強制的に  になります。この方法で、 要素が正しく動作するようになります。

注意点

 要素の  を手動で変更する際には、ユーザーのスクロール体験やページ全体のレイアウトに影響を与える可能性があるため、慎重に実装することが重要です。また、 を  に設定することで、ページ全体がスクロール可能になり、意図しない動作を引き起こす可能性があるため、必要に応じて条件分岐や追加のスタイル設定を行ってください。
]]></content:encoded>
        </item>
    </channel>
</rss>