攻撃を受けた経緯

ある日、サーバーのログを確認していたところ、不審なリクエストを発見しました。

お問い合わせフォームの「姓」フィールドに、以下のような文字列が入力されていたのです。


-1" OR 5*5=25 --


これはSQLインジェクション攻撃と呼ばれるもので、データベースを不正に操作しようとする攻撃手法です。

SQLインジェクションとは

SQLインジェクションは、入力フィールドに悪意のあるSQL文を注入して、データベースを操作しようとする攻撃です。

例えば、ログイン処理で以下のようなSQLを使っていたとします。

sql
SELECT * FROM users WHERE name = '入力値'


ここに ' OR '1'='1 のような文字列を入力されると、

sql
SELECT * FROM users WHERE name = '' OR '1'='1'


となり、条件が常にTRUEになってしまいます。これにより、認証をバイパスされたり、データを不正に取得されたりする可能性があります。

今回の攻撃で使われた -1" OR 5*5=25 -- も同様の原理で、5*5=25 は常にTRUEになるため、データベースの挙動を変えようとしていたものと思われます。

攻撃者の情報を分析してみた

ログに残っていた情報から、攻撃者について分析してみました。

| 項目 | 内容 |
|——|——|
| IPアドレス | VPNプロバイダーの帯域 |
| ブラウザ | Chrome（Windows） |
| メールアドレス | sample@email.tst（明らかにダミー） |
| 入力パターン | 最小限の値 + 攻撃コード |

攻撃の特徴から分かったこと

いくつかの特徴から、この攻撃について考察してみました。

1. 汎用的なペイロードが使われていた

使われていた攻撃コードは非常に一般的なもので、特定のサービスを狙ったものではありませんでした。サイトのDB構造を知っているような痕跡もなく、「とりあえず試してみた」という印象です。

2. 入力が機械的だった

名前欄に「e」、メールに「sample@email.tst」など、明らかに自動化ツールで生成したような値が使われていました。SQLMap等の脆弱性スキャンツールの特徴に似ています。

3. VPN経由でアクセスしていた

IPアドレスを調べると、VPNプロバイダーがよく使用する帯域でした。身元を隠しながら多くのサイトをスキャンする際の典型的な手法です。

結論：無差別スキャンの可能性が高い

これらの特徴から、特定のサービスを狙った標的型攻撃ではなく、脆弱なサイトを探すボットによる無差別スキャンだったと判断しました。

個人開発の小規模なサービスでも、こういった攻撃は普通に来るんだなと実感しました。

実施した対策

今回の攻撃を受けて、以下の対策を実施しました。

1. IPブラックリストの実装

攻撃元のIPアドレスを即座にブロックする仕組みを追加しました。

typescript
// IPブラックリスト
const IP_BLACKLIST: Set<string> = new Set([
'178.16.55.xxx', // 攻撃元IP
])

if (IP_BLACKLIST.has(ip)) {
console.log([BLOCKED] Blacklisted IP: ${ip})
throw createError({
statusCode: 403,
message: 'Access denied'
})
}
}


シンプルな実装ですが、同じIPからの継続的な攻撃には効果的です。

2. 既存の対策が機能しているか確認

改めて既存のセキュリティ対策を確認しました。

| 対策 | 状態 | 説明 |
|——|——|——|
| パラメータ化クエリ | | ORMを使用しており、SQLインジェクション対策済み |
| レート制限 | | 1分間に数回までに制限 |
| reCAPTCHA v3 | | ボット判定を実施 |
| 入力長制限 | | 追加で実装 |

重要なのは、パラメータ化クエリを使用していたため、今回の攻撃は実際には成功していなかったという点です。

Supabaseのクライアントライブラリを使っていたので、入力値は自動的にエスケープされており、SQLインジェクションは成立しませんでした。

typescript
// Supabaseはパラメータ化クエリを使用するため安全
const { error } = await client
.from('inquiries')
.insert({
last_name, // 値は安全にエスケープされる
email,
message,
})


3. 入力値の長さ制限を追加

説明欄などに大量のテキストを送りつけられるのを防ぐため、文字数制限を追加しました。

typescript
const MAX_DESCRIPTION_LENGTH = 1000

if (description && description.length > MAX_DESCRIPTION_LENGTH) {
throw createError({
statusCode: 400,
message: 説明は${MAX_DESCRIPTION_LENGTH}文字以内で入力してください
})
}


reCAPTCHA v3がボットを検出できる仕組み

せっかくなので、reCAPTCHA v3がどうやってボットを検出しているのかも調べてみました。

v3は「私はロボットではありません」のチェックボックスがなく、ユーザーの**行動パターン**を分析してスコア（0.0〜1.0）を算出します。

| 分析要素 | 人間の特徴 | ボットの特徴 |
|———-|————|————–|
| マウスの動き | 曲線的、不規則 | 直線的、または動きなし |
| キー入力 | タイミングにばらつき | 均一で高速 |
| ページ滞在時間 | 入力に時間がかかる | 瞬時に送信 |
| スクロール | 自然な速度変化 | 一定または無し |

スコアが閾値（例: 0.5）を下回ると、ボットと判定されてブロックされます。自動化ツールはこういった「人間らしさ」を再現するのが難しいようです。

多層防御の考え方

今回の経験で改めて実感したのは、多層防御の重要性です。

一つの対策に頼るのではなく、複数の防御層を設けることで、どれか一つが突破されても他の層で防げるようになります。


[攻撃]
→ IPブラックリスト（既知の攻撃元をブロック）
→ レート制限（大量リクエストを防止）
→ reCAPTCHA（ボットを検出）
→ 入力検証（不正な値を拒否）
→ パラメータ化クエリ（SQLインジェクションを無効化）


今回は最後の砦である「パラメータ化クエリ」で攻撃が無効化されていましたが、他の層も機能していたことで、より安心できる状態でした。

学んだこと

今回の攻撃を通じて、いくつかのことを学びました。

1. 基本的な対策が重要

ORMやクエリビルダーを正しく使っていれば、SQLインジェクションは基本的に防げます。フレームワークの機能をちゃんと使うことが大切だなと思いました。

2. ログは必ず残す

攻撃を検知できたのは、リクエストのログを残していたからです。以下の情報は記録しておくと、分析に役立ちます。

– IPアドレス
– User-Agent
– リクエスト内容（個人情報の取り扱いには注意）
– タイムスタンプ

3. 小規模サービスでも攻撃は来る

「うちは小さいから大丈夫」は通用しないんだなと実感しました。ボットは無差別にスキャンしているので、サービスの規模は関係ありません。

4. 定期的なログ確認の習慣

普段からログを確認する習慣をつけておくと、異常に気づきやすくなります。今回も定期的なログ確認で発見できました。

まとめ

今回の攻撃は、おそらく脆弱なサイトを探す自動スキャンでした。幸い対策済みだったため実害はありませんでしたが、個人開発でも普通に攻撃が来るんだなという良い経験になりました。

Webサービスを運営している方は、ぜひ以下の点を確認してみてください。

– SQLインジェクション対策ができているか（パラメータ化クエリの使用）
– ログを確認する習慣があるか
– 多層防御を意識した設計になっているか

何かの参考になれば幸いです。

Row Level Security（RLS）は、データベースの各行に対してアクセス権限を細かく制御する仕組みです。

簡単に言うと、「誰がどのデータを見たり編集したりできるか」をデータベースレベルで決められる機能です。

例えば、SNSアプリを作る場合を想像してください。ユーザーAの投稿はユーザーAだけが編集できて、他のユーザーは閲覧のみ可能にしたいですよね。RLSを使えば、そのようなルールをデータベース側で自動的に適用できるのです。

従来の方法との違い

従来のアプローチの問題点

これまでのWebアプリケーション開発では、セキュリティ制御をアプリケーションのコード内で行うのが一般的でした。しかし、この方法には以下のような問題がありました。

1. ヒューマンエラーのリスク

開発者がセキュリティチェックを書き忘れると、他のユーザーのデータが見えてしまう可能性があります。特に大規模なアプリケーションでは、すべてのエンドポイントで完璧なセキュリティを実装するのは困難です。

2. 開発・保守の負担

新しい機能を追加するたびに「このユーザーはこのデータにアクセスできるのか？」を毎回考える必要があり、コードも複雑になりがちです。

3. 一貫性の欠如

チーム開発では、開発者によってセキュリティの実装方法が異なる場合があり、アプリケーション全体で一貫したセキュリティポリシーを維持するのが難しくなります。

RLSの利点

RLSを使用することで、これらの問題を根本的に解決できます。

データベースレベルでの保護：アプリケーションコードにバグがあっても、データベース側でアクセスを制限するため、データ漏洩のリスクが大幅に減少します。

開発効率の向上：一度ポリシーを設定すれば、アプリケーション側でいちいちセキュリティチェックを書く必要がなくなります。

自動適用：Supabaseクライアントを通じてデータにアクセスする際、RLSポリシーが自動的に適用されるため、開発者が意識しなくても適切なアクセス制御が行われます。

RLSの仕組み

RLSは「ポリシー」という仕組みで動作します。ポリシーとは、「特定の条件を満たした場合のみ、データへのアクセスを許可する」というルールのことです。

ポリシーの基本構造

ポリシーを作成する際は、以下の要素を定義します。

• 対象テーブル：どのテーブルに適用するか
• 操作種類：SELECT（読み取り）、INSERT（作成）、UPDATE（更新）、DELETE（削除）のどの操作に適用するか
• 条件：どのような条件の時にアクセスを許可するか

例えば「ユーザーは自分が作成した投稿のみ編集できる」というルールを作りたい場合、「投稿テーブルのUPDATE操作において、現在ログインしているユーザーのIDと投稿の作成者IDが一致する場合のみ許可する」というポリシーを定義します。

実際の活用例

ブログアプリケーションでの活用

ブログアプリケーションを例に、RLSの実際の活用方法を説明します。

まず、ユーザーテーブルと投稿テーブルがあるとします。投稿テーブルには、タイトル、内容、作成者ID、公開フラグが含まれています。

このようなアプリケーションでは、以下のようなアクセス制御が必要になるでしょう。

閲覧に関するルール

• すべてのユーザーが公開済みの投稿を見ることができる
• 作成者は自分の投稿（下書き含む）をすべて見ることができる
• 他のユーザーの下書きは見ることができない

編集に関するルール

ユーザーは自分の投稿のみ作成・編集・削除できる

他のユーザーの投稿は編集できない

これらのルールをRLSで実現することで、アプリケーション側で複雑なセキュリティロジックを書く必要がなくなります。

-- 例：誰でも公開された投稿を閲覧可能
CREATE POLICY "Anyone can view published posts" ON posts
FOR SELECT USING (is_published = true);

-- 例：ユーザーは自分の投稿のみ編集可能
CREATE POLICY "Users can update own posts" ON posts
FOR UPDATE USING (auth.uid() = user_id);

組織やチーム単位でのアクセス制御

個人ユーザーだけでなく、組織やチーム単位でのアクセス制御も可能です。

例えば、プロジェクト管理ツールを作る場合を考えてみましょう。このツールでは

• 同じ組織のメンバーは組織内のプロジェクトを閲覧できる
• プロジェクトの作成は組織の管理者のみが可能
• プロジェクトの削除は組織のオーナーのみが可能

といったルールが必要になります。

RLSを使えば、これらの複雑なアクセス制御もデータベースレベルで実現できます。ユーザーと組織の関係、ユーザーの役割（メンバー、管理者、オーナー）などの情報を基に、適切なポリシーを設定することで、安全で柔軟なアクセス制御システムを構築できます。

パフォーマンスとベストプラクティス

パフォーマンスへの配慮

RLSを使用する際は、パフォーマンスも考慮する必要があります。ポリシーの条件が複雑になると、データベースの処理が重くなる可能性があります。

インデックスの活用

ポリシーで使用する条件に対して適切なインデックスを設定することで、パフォーマンスの向上が期待できます。例えば、ユーザーIDで絞り込む条件が多い場合は、user_idカラムにインデックスを設定します。

効率的なポリシー設計

よく使用される条件を先に評価するようにポリシーを設計することで、不要な処理を減らすことができます。

開発時のベストプラクティス

明確な命名規則

ポリシーには分かりやすい名前を付けることが重要です。「users_select_own_posts」のように、誰が何に対してどの操作を行えるかが名前から分かるようにしましょう。

段階的な実装

すべてのテーブルに一度にRLSを適用するのではなく、重要なテーブルから段階的に導入することをお勧めします。これにより、問題が発生した際の影響範囲を限定できます。

十分なテスト

RLSポリシーは、異なる権限を持つユーザーでテストすることが重要です。管理者、一般ユーザー、ゲストユーザーなど、さまざまな立場からアクセスを試して、期待通りの動作をするか確認しましょう。

まとめ

SupabaseのRLSは、アプリケーションのセキュリティを根本的に向上させる強力な機能です。従来のアプリケーションレベルでのセキュリティ制御と比較して、より安全で保守性の高いシステムを構築できます。

適切に設計・実装されたRLSポリシーは、開発者の負担を軽減し、データ漏洩のリスクを最小限に抑えます。また、複雑な組織構造やロールベースのアクセス制御にも対応できる柔軟性を持っています。

RLSを活用して、ユーザーが安心して使える、セキュアなアプリケーションを構築していきましょう。

今回は具体的な事例を通して、現在のClaude AI活用の実態を整理してみます。

Claude 4で何が変わったのか

2025年5月にリリースされたClaude 4は、従来のバージョンから大きく進化しています。特に注目すべきは並列でのツール使用と、推論中にリアルタイムでWeb検索ができるようになった点です。

これまでのAIチャットツールは「聞かれたことに答える」だけでしたが、Claude 4は「考えながら必要な情報を取りに行く」ということができるようになりました。開発中に「このライブラリの最新の使い方がわからない」となった時、自分で調べて最新情報を踏まえた回答をしてくれるのは、かなり実用的です。

Web検索機能

3月に追加されたWeb検索機能も地味に便利です。従来は「GPTに聞く→Googleで調べる→また戻ってGPTに聞く」みたいな往復が必要でしたが、Claudeは一つの会話の中で最新情報を調べて回答してくれます。

ただし、検索結果をそのまま返すのではなく、Claudeが解釈して会話形式で返してくれるのが特徴的です。情報の信頼性については相変わらず注意が必要ですが、開発中のちょっとした調べ物には重宝しそうです。

Claude Artifacts

個人的に面白いと思ったのがArtifacts機能です。15行以上のコードや構造化されたコンテンツを独立して管理し、リアルタイムでプレビューできます。

従来だとVSCodeで作って、ローカルサーバー立てて、ブラウザで確認して…という手順が必要でしたが、すべてClaude上で完結できるのは確かに便利です。

何より、「ちょっとしたツールが欲しい」と思った時のハードルが劇的に下がります。社内の小さな業務効率化ツールとかには、かなり使えそうな印象です。

Claude Codeという新しいアプローチ

Claude Codeはターミナルベースで動作し、プロジェクト全体のコンテキストを理解してくれるという点が新しいです。従来のAIコーディングツールは「このファイルの中でこの機能を実装して」みたいな局所的な支援でしたが、Claude Codeはプロジェクト全体を見渡した提案ができるようです。

事例ではダッシュボードを数時間で作り上げていて、リアルタイム統計表示、ドキュメント管理、WebSocket対応、レスポンシブデザイン、ダークモード対応まで含んでいます。従来なら数週間かかる作業を数時間でやってのけるのは、確かにインパクトがあります。

ただ、こういう「すごく早い」系の事例を見る時は、要件定義や設計の時間が含まれているのか、品質はどの程度なのか、という点は気になります。

現在の制限事項

調べてみると、現在のClaude Artifactsにはいくつかの制限があります：

– 外部APIとの連携ができない
– 永続的なストレージがない
– テキストベースの完了APIのみ

つまり、実際のWebサービスで必要な「データベースとの連携」「外部サービスとの認証」「ファイルアップロード」みたいな機能は、まだ自分で実装する必要があります。現状は「プロトタイプやモックアップの作成」「簡単なツールの開発」あたりが現実的な用途でしょう。

コスト面

開発速度の向上は確実にコストメリットがあります。特にプロトタイプ作成やMVP開発では、大幅な時間短縮が期待できます。

一方で、生成されたコードのレビューや品質向上に追加工数がかかることも考慮する必要があります。結果的には「初期開発は早くなるが、品質担保に別の時間がかかる」という構造になりそうです。

スキルセットの変化

Claude AIが普及すると、開発者に求められるスキルも変わってきそうです。純粋な「コードを書く能力」よりも、「問題を整理する能力」「AI生成コードの品質を評価する能力」「プロダクト全体を設計する能力」の重要性が高まりそうです。

特に、プロンプトエンジニアリングのスキルは今後重要になるでしょう。AIに適切な指示を出して、期待する結果を得る技術は、従来のプログラミングスキルとは異なる新しい能力です。

開発プロセスの変化

従来の「要件定義→設計→実装→テスト」という流れが、「アイデア→プロトタイプ→反復改善→本格実装」という形に変わる可能性があります。

特に初期段階でのアイデア検証が格段に早くなるため、より多くの選択肢を試行錯誤できるようになります。これは、プロダクト開発全体にとってプラスの変化だと思います。

新しい役割の出現

AIとペアプログラミングをする新しい働き方や、AI生成コードの品質を担保する専門職みたいな役割が生まれるかもしれません。また、技術的な実装よりもビジネス価値の創出により重点を置いた開発者の役割も増えそうです。

まとめ

Claude AIを使ったWebアプリ開発は、確実に実用的なレベルに達していると感じました。特にプロトタイプ作成や小規模ツール開発では、大幅な効率化が期待できます。

一方で、本格的なプロダクション環境で使うには、まだ課題も多く残っています。セキュリティ、パフォーマンス、保守性といった観点では、引き続き人間の開発者の役割が重要です。

重要なのは、AIを「開発者の代替」として見るのではなく、「開発プロセスを加速するツール」として捉えることだと思います。適切に活用すれば、より創造的で価値の高い仕事に集中できるようになるはずです。

今後もClaude AIの進化は続くでしょうし、開発現場での活用事例も増えてくると思います。早めにキャッチアップして、自分なりの活用方法を見つけていくことが大切になりそうです。

「URLを投げるだけで中身をAIが理解してくれる」という魔法のような機能に見えましたが、実際に実装してみると様々な課題に直面しました。最終的に安定したシステムを構築するまでの試行錯誤をまとめます。

URL Context機能とは

従来のWebスクレイピングでは、HTMLを取得してパースし、CSSセレクターやXPathで特定の要素を抽出する必要がありました。

// 従来のスクレイピング
const response = await fetch(url);
const html = await response.text();
const $ = cheerio.load(html);
const title = $('.page-title').text();
const content = $('.main-content').text();
// ... 各要素を個別に抽出

URL Context機能を使えば、これらの作業をAIに丸投げできます。

// URL Context使用
const response = await fetch('https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash-preview-05-20:generateContent', {
  body: JSON.stringify({
    contents: [{
      parts: [{ text: `${url}から情報をJSON形式で抽出して` }]
    }],
    tools: [{ "url_context": {} }]  // これが重要
  })
});

最初の実装と失敗

当初、以下のようなシンプルな実装から始めました。

export async function POST(request: NextRequest) {
    const { url } = await request.json();
    
    const response = await fetch(geminiApiUrl, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
            contents: [{
                parts: [{ text: `${url}の情報を抽出して` }]
            }]
        })
    });
}

発生した問題

間違った情報が返ってくる

• 入力: とあるWebサイトのページURL
• 出力: 全く関係ない別のサイトの情報

動作が不安定

• 同じURLでも結果が変わる
• 明らかに学習データから推測した内容

URL Context機能が動作していなかった

最大の原因はtools設定の不備でした。URL Context機能を使うには明示的に指定する必要があります。

// 間違った実装
body: JSON.stringify({
    contents: [{ parts: [{ text: `URL: ${url}` }] }]
    // tools設定なし → 通常のテキスト生成として処理される
})

// 正しい実装
body: JSON.stringify({
    contents: [{ parts: [{ text: `URL: ${url}` }] }],
    tools: [{ "url_context": {} }],                    // 重要！
    model: "gemini-2.5-flash-preview-05-20"           // 対応モデル
})

また、URL Context機能は新しい機能のため、対応モデルが限定されていました。

原因分析

Webページが膨大だったのが大きな要因でした。

元のHTML: 208,922文字
↓
Gemini内部処理: 6,377トークン
↓
制限オーバー: 4,096トークン制限を超過

一般的なWebサイトには以下の要素が大量に含まれていました。

• JavaScript（数万行）
• CSS（複雑なスタイル定義）
• 広告・関連コンテンツ・ナビゲーション
• アナリティクス用のdata属性

解決策：ハイブリッドアプローチ

最終的に、従来のスクレイピング + AI分析のハイブリッドアプローチを採用しました。

実装フロー

1. 自前でHTMLを取得
2. 不要要素を徹底的に削除
3. プレーンテキスト化
4. Geminiで構造化データに変換

HTML軽量化の実装

async function preprocessHTML(url) {
    // 1. HTMLを取得
    const response = await fetch(url, {
        headers: {
            'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'
        }
    });
    const html = await response.text();
    
    // 2. 不要要素を削除
    let cleanHtml = html
        .replace(/<script[^>]*>[\s\S]*?<\/script>/gi, '') // JavaScript
        .replace(/<style[^>]*>[\s\S]*?<\/style>/gi, '')   // CSS
        .replace(/<!--[\s\S]*?-->/g, '')                  // コメント
        .replace(/class="[^"]*"/gi, '')                   // class属性
        .replace(/id="[^"]*"/gi, '')                      // id属性
        .replace(/style="[^"]*"/gi, '')                   // style属性
        .replace(/data-[^=]*="[^"]*"/gi, '');             // data属性
    
    // 3. HTMLタグを完全除去
    cleanHtml = cleanHtml
        .replace(/<[^>]+>/g, ' ')                         // 全タグ削除
        .replace(/\s+/g, ' ')                             // 空白正規化
        .trim();
    
    // 4. 文字数制限
    return cleanHtml.substring(0, 8000);
}

Gemini APIへの送信

const response = await fetch(geminiApiUrl, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
        contents: [{
            parts: [{
                text: `以下のWebページテキストから必要な情報をJSON形式で抽出：

${preprocessedText}

出力形式:
{
  "title": "タイトル",
  "category": "カテゴリ",
  "description": "説明",
  "details": "詳細情報"
}`
            }]
        }],
        // URL Contextは使わない（前処理済みテキストのため）
        generationConfig: {
            temperature: 0.1,
            maxOutputTokens: 4096
        }
    })
});

学んだこと

「URLを渡すだけ」という説明に惑わされ、tools設定を見落としており、公式ドキュメントをよく読むべきでした。

また、基本的にWebページは非常に重く、軽量化なしではAI APIの制限にすぐ引っかかるので考慮する必要がありそうです。

「AIですべて解決」ではなく、現状は従来技術と組み合わせることで、より確実で効率的なシステムを作ることを目指すのが良さそうです。

現在、一部の項目で「N/A」が出力される場合があり、サイト構造の分析と、より適切な文字数制限の設定が今後必要になりそうです。

MCPって何？

Model Context Protocol（MCP）は、簡単に言うとAIモデルと外部ツールが連携するときの標準的なルールを定めたものです。

今まで、GPTやClaude等のAIモデルにWebスクレイピングやデータベース操作などの機能を追加しようとすると、それぞれ独自の方法で実装する必要がありましたが、MCPはこの問題を解決します。

要するにAIと外部ツールが話し合うための「共通言語」のようなものだと思います。

今まで、AIに「Webで検索して」とか「データベースから情報を取得して」とお願いするとき、それぞれ別々の方法で実装する必要がありましたが、MCPであれば一度覚えた方法でいろんなツールとAIを連携させることができるようになります。

技術的にはどういう仕組みなのか

MCPは、WebSocketやgRPCなどの通信プロトコルの上で動く、メッセージベースのシステムのようです。JSON形式でメッセージをやり取りして、AIとツールが情報を交換します。

特に重要だと思うのは「コンテキスト」の管理です。普通のAPIだと、一回一回のリクエストは独立していますが、MCPでは会話の流れやこれまでの処理結果を適切に管理してくれるようです。

これにより、AIが複数のツールを連続して使ったり、前回の結果を踏まえて次の行動を決めたりすることができるのではないでしょうか。

実際の開発現場でどう使えそうか

現在のAI開発で困っていることを考えると、MCPの恩恵は大きそうです。

チャットボット開発での活用

例えば、顧客サポートのチャットボットを作る場合

• CRMシステムから顧客情報を取得
• 注文履歴をデータベースから検索
• 在庫確認システムで商品状況をチェック
• メール送信システムで返答を送信

これらを全て統一的な方法で連携できれば、開発がかなり楽になります。

開発者向けAIアシスタント

コーディング支援AIの場合

• GitHubから最新のコードを取得
• 静的解析ツールでコード品質をチェック
• テスト実行環境でコードを実行
• ドキュメントを自動生成

これらのツールを組み合わせたワークフローが、MCPで簡潔に記述できるかもしれません。

実装の難しさと課題

MCPを実際に使う際の課題もあるかと思います。

学習コスト

新しいプロトコルを覚える必要があります。特に、コンテキスト管理やメッセージ形式など、従来のAPI開発とは異なる概念を理解する必要があります。

デバッグの困難さ

AIとツールの連携が複雑になると、どこで問題が発生しているかを特定するのが難しくなりそうです。適切なログ機能やデバッグツールが重要になるでしょう。

パフォーマンスの懸念

抽象化レイヤーが増えることで、多少のオーバーヘッドは必要になりそうです。高負荷なシステムでは、この影響を考慮する必要がありそうです。

まとめ

Model Context Protocolは、AI開発における「配管工事」の部分を大幅に簡略化してくれそうです。標準化により、AI開発者はより創造的で付加価値の高い部分に時間を使えるようになるでしょう。

まだ新しい技術なので、全てが確定しているわけではありませんが、AI開発に携わる者として注目していくべき技術だと思います。

実際のプロジェクトで使えるレベルになるまでには、もう少し時間がかかるかもしれませんが、早めにキャッチアップしておけば、将来的に大きなアドバンテージを得られるかもしれないです。

チームの一員として関わる中で、このギャップが将来的な問題につながる可能性を感じ、アジャイル開発手法への段階的な移行を内部で提案してみた内容をまとめました。

課題感

新しいプロジェクトに参加してすぐに感じたのは、以下のような課題でした。

1. 曖昧なタスク定義: 作業内容がざっくりと定義されているため、正確な工数見積もりができない
2. 頻繁な要件変更: 週次ミーティングでクライアントから次々と新しい要望が出てくる
3. 優先順位の不明確さ: 何を先に実装すべきかの基準がない
4. プロジェクト全体の見通しの不透明さ: 「いつまでに何ができるのか」がわからない

これらは「ウォーターフォール的アジャイル」とも呼べる状況の典型的な特徴です。

名目上はアジャイルを採用しているものの、実態はウォーターフォールに近い進め方をしており、アジャイルの利点を十分に活かせていない状態でした。

予想されるリスク

このまま進めた場合、以下のようなリスクが予想されました。

1. スケジュール管理の難しさ

タスクが明確に定義されていないため、今後の工数見積もりが困難になり、納期に間に合わない恐れがあります。

2. 要件変更への対応の限界

週次定例でクライアントから新たな要望や改善点が出され続け、それらを既存の計画にどう組み込むかの仕組みがないため、混乱が生じる可能性があります。

3. チームの疲弊

優先度が明確でないまま、次々と要件が追加されると、チームは常に「潜在的な納期遅れ」のプレッシャーにさらされ、疲弊してしまいます。

4. プロジェクトの失敗リスク

このままあいまいな状態で進めると、納期や品質に影響が出る可能性が高くなります。

アジャイル開発手法の導入プラン

これらの課題を解決するため、以下のようなアジャイル開発導入計画を立てました。

1. カンバンボードの実装

• タスクの可視化を進め、「今何が進行中で、何が待機中か」を明確にする
• ボトルネックを早期に発見できるようにする

2. ユーザーストーリーの整備

• 曖昧な要件を明確なユーザーストーリーとして再定義する
• 各ストーリーにポイント（難易度・工数の指標）を付与し、定量的な管理を可能にする

3. スプリント計画の導入

• チームの消化可能なポイント数（ベロシティ）を把握し、現実的な計画を立てる
• 2週間単位のスプリントを設定し、その期間内で達成可能な目標を設定する

期待される効果

アジャイル開発を正しく導入することで、以下のような効果が期待できます。

1. クライアントとのコミュニケーション改善

• 「今週は○○ポイントまで消化可能であり、これらの機能を実装できます」と具体的に説明できるようになる
• 追加要望があった場合、「この要望を優先すると、他のこの機能は次スプリントに持ち越しになります」と明確に提示できる
• プロジェクトの状況が「見える化」されることで、より焦点を絞った建設的な対話が可能になる

2. プロジェクト管理の透明性向上

• 進捗状況が可視化され、問題の早期発見が可能になる
• 変更による影響範囲を定量的に評価できるようになる

3. チームの持続可能な開発ペース確立

• 達成可能な目標設定により、チームは無理なく効率的に開発を進められる
• 過剰な負荷を防止し、品質を維持できる

4. リスクの低減と早期対応

• 技術的な課題や実現可能性の問題を早期に発見できるため、プロジェクト後半での大きな問題発生を防止できる
• 問題が発生しても影響範囲が限定的で、素早い対応が可能になる

クライアントとの共有ポイント

アジャイル開発への移行を成功させるためには、クライアントの理解と協力が不可欠です。以下の点をクライアントと早期に共有することにしました。

1. 優先度の明確化

• 機能の優先順位を一緒に決定することの重要性を説明する
• 「すべてが最優先」は不可能であり、限られたリソースで最大の価値を生み出すための選択が必要であることを理解してもらう

2. 変更管理プロセスの確立

• 新たな要望はプロダクトバックログに追加し、優先度に応じて取り込むプロセスを確立する
• 変更が及ぼす影響を可視化し、適切な意思決定を促す

3. 定例会議の活用方法

• スプリントレビューでは、完成した機能のデモを行い、フィードバックを得る
• スプリント計画では、次のスプリントで取り組む内容を明確にする

4. 追加要望と工数の関係

• 追加要望には追加の工数が必要であり、既存タスクとの優先度調整が必要なことを理解してもらう
• 「スコープ・時間・品質」のトレードオフ関係を明確に伝える

実施に向けた具体的なステップ

アジャイル移行の第一歩として、以下のようなステップで進める計画を立てました。

1. 現状のプロジェクト要件をユーザーストーリーとして整理

• 既存の要件をユーザーストーリー形式に書き換える
• 各ストーリーにポイントを割り当てる

2. プロダクトバックログの作成

• すべてのユーザーストーリーを優先順位順に並べたバックログを作成する
• クライアントと一緒にレビューし、優先順位を合意する

3. 初回スプリント計画

• 2週間のスプリントで取り組むストーリーを選定する
• チームのベロシティを保守的に見積もり、無理のない計画を立てる

4. カンバンボードの運用開始

• Notion等のツールを活用し、タスクの進捗を可視化する
• 日次のスタンドアップミーティングを短時間で実施し、進捗を共有する

5. 定例での振り返りと改善

• スプリントごとに振り返りを行い、プロセスの改善点を見つける
• 実績ベロシティを計測し、次回スプリントの計画に反映する

まとめ

アジャイル開発への移行は一朝一夕にはいきません。特に「アジャイルと言いながらウォーターフォール」の状態からの脱却は、チームだけでなくクライアントの考え方の変化も必要とします。

重要なのは、すべてを一度に変えようとするのではなく、小さな成功体験を積み重ねていくことです。

今回のケースでは、まずはユーザーストーリーの整備とカンバンボードの導入から始め、チームとクライアントの双方に「見える化」のメリットを実感してもらうことから始めました。

アジャイル開発の本質は、不確実性を前提とした上で、効率的にプロジェクトを進めていく柔軟性にあると思います。プロジェクトの成功確率を高め、クライアントとの良好な関係構築にもつながると考えています。

宣言的なアプローチの<Refresh>コンポーネントと、命令的なアプローチのrefresh()関数です。

一見似ているように見えるこの2つの更新方法ですが、実際どのような違いがありのかまとめてみました。

2つの更新方法

まず、それぞれの基本的な使い方を見てみましょう：

// 方法1: Refreshコンポーネントを使用
import { Refresh } from "@lazarv/react-server/navigation";

function RefreshButtonUsingComponent() {
  return (
    <div>
      <Refresh>更新する</Refresh>
    </div>
  );
}

// 方法2: refresh関数を使用
import { useClient } from "@lazarv/react-server/client";
import { startTransition } from "react";

function RefreshButtonUsingFunction() {
  const { refresh } = useClient();
  
  return (
    <div>
      <button onClick={() => startTransition(async () => refresh())}>
        更新する
      </button>
    </div>
  );
}

一見すると似たような機能に見えますが、実際には重要な違いがあります。

1. コンポーネント vs 関数

最も明確な違いは、一方がReactコンポーネントであり、もう一方が関数であるという点です。

• <Refresh>：ユーザーインターフェースを構成するReactコンポーネント。宣言的なアプローチ
• refresh()：プログラムから呼び出す関数。命令的なアプローチ

2. 使用方法と柔軟性

// Refreshコンポーネント - シンプルに使える
<Refresh>クリックして更新</Refresh>

// refresh関数 - より多くのコントロールが可能
const { refresh } = useClient();

// 条件付き更新
const conditionalRefresh = () => {
  if (hasChanges) {
    startTransition(async () => refresh());
  }
};

// 特定のアウトレットのみ更新
const refreshDashboard = () => {
  startTransition(async () => refresh("dashboardOutlet"));
};

// 他の処理と組み合わせる
const saveAndRefresh = async () => {
  await saveData();
  startTransition(async () => refresh());
  showNotification("保存しました");
};

refresh()関数は柔軟性が高く、より複雑なシナリオに対応できます。

3. トランジションの扱い

<Refresh>コンポーネントは内部でReactのトランジションを自動的に処理しますが、refresh()関数を使用する場合は、通常自分でstartTransitionを使ってトランジションを開始する必要があります。

// Refreshコンポーネント - トランジションは内部で処理される
<Refresh>更新</Refresh>

// refresh関数 - 自分でトランジションを開始する
<button onClick={() => startTransition(async () => refresh())}>
  更新
</button>

これにより、refresh()関数を使用する場合、トランジションのタイミングをより細かく制御できます。

ユースケース：どちらを選ぶべき？

それぞれの方法が適している状況を考えてみます。

<Refresh>コンポーネントが適している場合

• シンプルな「更新ボタン」が欲しい場合
• マークアップが中心で、複雑なロジックが不要な場合
• React Serverのデフォルトの動作で十分な場合
• JSXの中で直感的に使いたい場合

function SimplePage() {
  return (
    <div className="page-container">
      <header>
        <h1>マイダッシュボード</h1>
        <Refresh>更新</Refresh>
      </header>
      <main>
        {/* ページコンテンツ */}
      </main>
    </div>
  );
}

refresh()関数が適している場合

• 他のロジックと組み合わせる必要がある場合
• 条件付きで更新したい場合
• 特定のアウトレットだけを更新したい場合
• カスタムUIと組み合わせたい場合
• プログラムで更新のタイミングを制御したい場合

function ComplexDashboard() {
  const { refresh } = useClient();
  const [isLoading, setIsLoading] = useState(false);
  
  const handleRefresh = async () => {
    setIsLoading(true);
    // 先にバックエンドAPIからデータを取得
    await fetchLatestData();
    // その後ページを更新
    startTransition(async () => {
      await refresh();
      setIsLoading(false);
    });
    // 分析データを送信
    trackEvent("dashboard_refreshed");
  };
  
  return (
    <div className="dashboard">
      <button 
        onClick={handleRefresh}
        disabled={isLoading}
        className={isLoading ? "btn-loading" : "btn-normal"}
      >
        {isLoading ? "更新中..." : "最新データに更新"}
      </button>
      {/* ダッシュボードコンテンツ */}
    </div>
  );
}

まとめ

React Serverにおける2つの更新方法は、同じ機能をベースとしながらも、異なるユースケースに合わせて最適化されています。

• <Refresh>コンポーネント：シンプルさと宣言的なアプローチを重視
• refresh()関数：柔軟性と制御性を重視

より高度なパフォーマンス最適化やユーザーエクスペリエンス向上のためには、refresh()関数とstartTransitionを組み合わせた方法が多くの場合に適していそうです。

しかし、シンプルなUI要素としては<Refresh>コンポーネントの直感的に使いやすいです。

今回は実際にユーザーに使われるサービスを作りたい方に向けて、大学生の頃から現在まで10個以上の個人開発のサービスを作ってきた経験から得た知見をお伝えします。

なお、単純に技術力向上が目的の場合は、この記事で紹介する「集客」や「マネタイズ」といった観点は気にする必要はありません。

まずは自分の目的を明確にすることから始めましょう！

個人開発の目的を明確にする

個人開発には大きく分けて3つの目的があります。

1. 技術的な学習

• 新しい言語やフレームワークの習得
• アーキテクチャの理解
• 技術的チャレンジ

→ この場合は以降で説明する「ユーザー獲得」や「マネタイズ」は気にする必要なし

2. ポートフォリオ作成

• 転職や就職の際のアピール
• 技術力の可視化
• コーディングスキルの証明

→ この場合も「収益化」よりも「技術の見せ方」を重視

3. サービス運営・収益化

• 実際のユーザーに使ってもらう
• 継続的な収益の獲得
• サービス運営の経験を得る

→ この場合は以降で説明する内容が重要

サービス運営から得られる学び

実際にユーザーに使われるサービスを作ると、会社員エンジニアとして働いているだけでは得られない多くの学びがあります。

これらの経験は、エンジニアとしての視野を大きく広げてくれます。

1. 収益の仕組みの理解

広告収入の仕組みについて、実際に運用してみて初めて細かい部分が見えてきました。

• インプレッション単価は季節や時間帯でかなり変動する
• クリック単価は業界によって大きく違う（金融系は高め、エンタメ系は低めなど）
• 成果報酬型広告は条件が合えば収益性が高い
• 純広告は安定収入になるけど、営業力が必要
• 動画配信型広告など新しい媒体が出てくる

正直、これらは実際にやってみないと分からないことばかりでした。

2. 運用コストの現実

サービスの運用には意外と多くのコストがかかることを、実際に運営してみて初めて実感します。

特に自分の場合、最初は「無料枠でなんとかなるだろう」と思っていたのですが、ユーザーが増えるにつれて様々なコストが発生してきました。

サーバー費用はアクセス数と比例して増加し、最初は無料枠で収まっていても、徐々にコストが発生してきました。

他にもドメイン代、データベースやストレージなどの費用が発生します。

急なアクセス増に対応するための余裕を持たせる必要がある場合は、それに伴うコストも考慮が必要です。例えば、SNSで拡散された時の一時的なアクセス増にも耐えられる設計が必要です。

3. ユーザー対応の重要性

サービスを運営する上で、ユーザーとの関係構築は重要です。

サービスを運営していくと問い合わせが発生してきます。ユーザーからのバグ報告はしっかりと受け止め、迅速に対応する必要があります。

お問い合わせに対して真摯に対応していくことでユーザー価値を届けることの大切さを学ぶことができます。

また、同じような質問が多いため、FAQ作成など効率化が必要になります。

機能要望について全ての要望に応えることはできませんが、優先順位をつけて計画的に対応することが重要です。

アイデアの見つけ方

自分の経験から言えば、最も取っ掛かりやすいのは自分自身が本当に必要としているものです。

自分が実際に困っている問題など、毎日の生活や仕事で「これ、面倒だな」と感じることをメモしておくと良いです。また、同僚や友人の愚痴や相談の中にも、サービスのタネは隠れています。

他にもよく使うサービスの「ここが使いづらい」という点も、新しいサービスのヒントになります。

アイデアが思いついたら、実際に需要があるか確認します。XなどのSNS検索で「〜できない」「〜めんどくさい」などのネガティブなキーワードで検索すると、潜在的なニーズが見つかります。

アイデアの検証ステップ

アイデアが固まったら、本格的な開発に入る前に必ず検証を行います。ここでの検証が甘いと、後々大きな手戻りの原因となります。

1. 競合分析

競合サービスの機能を一覧表にまとめ、どの機能が本当に必要とされているのかを見極めます。

例えば、私の場合は競合を全てスプレッドシートにまとめ、本当に使われている機能を洗い出しました。

差別化ポイントとして「より良い」ではなく「異なる」アプローチを見つけることが重要です。例えば、競合が機能の豊富さを売りにしているなら、あえてシンプルさを極めるという選択肢もあります。

2. ユーザーヒアリング

実際のユーザーの声を聞くことで、思い込みに気づくことができます。

知人や同僚など最初は身近な人に協力してもらいましょう。「このサービスがあったら使う？」ではなく、「現在どうやってこの問題を解決しているか」を聞くのがポイントです。

サブスクや買い切りなどの場合は「いくらなら払えるか」を具体的に聞きます。この時、「月額いくら？」ではなく「この問題を解決するためにいくらまでなら払えるか」という聞き方をすると、より正確な答えが得られます。

また「いつ」「どこで」「どんな時に」使うのかを具体的にイメージしてもらいます。これにより、見落としていた機能要件が見つかることもあります。

MVP（最小機能）の設計

ここからが実際の開発フェーズです。MVPは「必要最小限の機能を持つ製品」という意味ですが、重要なのは「最小限」であることです。

例として、以下の3つの質問全てに「YES」と答えられる機能のみを実装します。

1. 必要最低限の機能か？

「あったら便利」と「なければ困る」は明確に区別します。

例えばタスク管理アプリなら、タスクの追加・編集・削除は必須ですが、タグ付けは必ずしも最初から必要ではないです。

なくても代替可能な機能は後回し、例えば、カレンダー連携は便利ですが、最初は手動で日付を入力してもらうことで代替できます。

ヒアリングで得た情報をもとに、ユーザーが本当に必要な機能を見極めます。

2. 2週間以内に実装可能か？

開発期間が長くなると、モチベーション維持が難しくなります。

未経験の技術を使う場合は、学習時間も含めて見積もります。機能ごとに必要な作業を細かく分解し、現実的な工数を見積もります。

特に外部サービスとの連携や、初めて使う技術については、予期せぬ問題が発生する可能性を考慮します。

3. 検証可能な価値を提供できるか？

特に最初はユーザーからフィードバックが得られる機能を考慮します。

ユーザーの課題をどの程度解決できるのか、具体的に説明できる必要があります。

また、ユーザーの行動や反応を測定できる機能であることが重要です。この辺りはGoogle AnalyticsやSearch Console、Clarityなどを導入すると良いかと思います。

フィードバックをもとに、どのように改善できるかが具体的にイメージできるとなお良いです。

運用コストを考える

個人開発では、運用コストの管理が特に重要です。

最初は無料枠の範囲内で始められるサービスを選ぶと良いと思います。例えば、Vercel + Supabase、Firebase、Herokuなど。

また自動化できる部分は最大限自動化し、運用の手間を減らします。

マネタイズプランの検討

個人開発でのサービス運営でよく見かける失敗の一つが、マネタイズプランを後回しにすることです。なぜなら運用コストが発生すると赤字になり続けるので、サービス運営をすることが困難になるからです。

最低でも運営コストを稼げるくらいのマネタイズを考えておくと良いでしょう。

個人開発の開始前から以下の点を検討しておく必要があります。

1. 収益モデルの選択

サービスの性質に合わせて、適切な収益モデルを選択します。例えば以下などがあります。

広告収入

• メリット：ユーザーの金銭的負担がなく、導入が容易
• デメリット：安定した収益を得るには大量のPVが必要
• 具体例：月間10万PVで1-2万円程度の収入が目安
• 向いているサービス：情報提供系、メディア系

サブスクリプション（月額課金）

• メリット：安定した収益が見込める、売上予測がしやすい
• デメリット：継続的な価値提供が必要、解約率の管理が重要
• 具体例：月額500円×継続ユーザー100人で月5万円の収入
• 向いているサービス：ツール系、サービス系

プラットフォーム手数料

• メリット：取引規模に応じて収益が増加、ユーザー同士の取引から収益化
• デメリット：両面市場の運営が必要、初期の流動性確保が課題
• 具体例：取引額の3-15%程度を手数料として徴収
• 向いているサービス：マッチングサービス、マーケットプレイス
• 補足：出品手数料、決済手数料、プレミアム掲載料など複数の収益源を組み合わせることも

ライセンス販売

• メリット：一度の開発で複数回販売可能
• デメリット：継続的なアップデートやサポートが必要
• 具体例：永続ライセンスを1-5万円で販売
• 向いているサービス：デスクトップアプリ、専門的なツール

フリーミアム

• メリット：導入障壁が低く、優良ユーザーの囲い込みが可能
• デメリット：無料ユーザーのコスト負担、機能分けの難しさ
• 具体例：基本機能は無料、高度な機能は月額課金
• 向いているサービス：SaaS、モバイルアプリ
• 補足：無料プランと有料プランの機能差を明確に

アフィリエイト/紹介料

• メリット：初期投資が少なく、成果に応じた収益
• デメリット：提携先の選定や関係維持が重要
• 具体例：商品紹介による成果報酬、ユーザー紹介料
• 向いているサービス：情報メディア、比較サイト
• 補足：主要な収益源として、または副収入として活用可能

個人開発の場合、最初は1つのモデルからスタートして、サービスの成長に合わせて他のモデルを追加していくのがおすすめです。

例えば、最初は広告収入からスタートし、ユーザーが増えてきたらプレミアム機能を追加してサブスクリプションを導入する、といった具合です。

個人開発では、全てを完璧にする必要はないです。まずは最小限の体制を整え、サービスの成長に合わせて徐々に改善していきましょう。

特に初期は、自動化できる部分は積極的に自動化し、人的リソースはサービスの改善や新機能の開発に集中することをおすすめします。

結果はそんな重要じゃない

色々書きましたが、これらをやるのはぶっちゃけめんどくさいです。ここまでしてユーザーが集まらなかったらとか1円も稼げなかったらどうしようとかやってて思いがちですが、個人的にあまり意識しすぎない方が良いと思ってます。

これらに挑戦したこと自体に価値があり、それぞれ実践してアウトプットすることで確実に自分の経験となり、キャリアップや想定外のところで活きてきます。

つまり、やること自体、自分にプラスになっていると意識すると良いと思ってます。結果的にダメでも学びや気づきがあるので、過程を楽しむと良いと思います。

まずはやってみよう！

この記事に書いたことは、あくまでも私の経験からの「こうじゃないかな」という考えで、人によって正解は違うと思います。
正直、最初から全部完璧にやろうとする必要はありません。

この記事に書いてあることを頭の片隅に置きつつ、まずは自分で何かアクションを起こしてみることをおすすめします。

例えば、気になる技術でとりあえず何か作ってみる、小さなツールでもいいので公開してみる、広告を入れてみて収益の仕組みを体験するなど実際に動いてみると、必ず何かしらの気づきがあります。

私も最初は全然うまくいきませんでしたが、少しずつ試行錯誤する中で、だんだんコツが掴めてきました。

大事なのは、完璧を目指すことではなく、実際に動いて学びを得ること。この記事が、皆さんの最初の一歩を踏み出すきっかけになれば嬉しいです！

目的

• カードコンポーネントの画面表示を検知
• GTM経由でGA4にイベントを送信
• 表示データの分析

実装フロー

1. Vueコンポーネントで要素の表示を検知
2. dataLayerにイベントをプッシュ
3. GTMでイベントを捕捉
4. GA4にデータを送信

Vueコンポーネントの実装

import { ref, onMounted } from 'vue'

interface Props {
  items: Array<{
    id: string
    title: string
  }>
}

const props = defineProps<Props>()
const itemRefs = ref<any[]>([])

onMounted(() => {
  itemRefs.value.forEach((elementRef, index) => {
    if (!elementRef) return

    const observer = new IntersectionObserver((entries) => {
      if (entries[0].isIntersecting) {
        const item = props.items[index]
        // dataLayerにイベントをプッシュ
        window.dataLayer?.push({
          event: 'item_view',
          item_id: item.id,
          item_title: item.title,
          eventModel: {
            send_to: 'G-XXXXXXXX'
          }
        })
        observer.disconnect()
      }
    })

    observer.observe(elementRef.$el || elementRef)
  })
})
</script>

<template>
  <div>
    <div
      v-for="(item, index) in items"
      :key="item.id"
      :ref="el => itemRefs[index] = el"
    >
      <!-- カードの内容 -->
    </div>
  </div>
</template>

ref配列の使用

itemRefs配列を使って、複数のカードコンポーネントへの参照を管理しています。Vue3のref属性の動的な割り当てを活用しています。

Intersection Observer APIの設定

各カードごとに個別のObserverを作成しています。一度表示を検知したらdisconnect()で監視を停止し、重複計測を防止します。

dataLayerへのデータ送信

カードのIDとタイトルを送信し、eventModelを使って送信先のGA4を指定しています。

GTMの設定

続いて、Google Tag Managerの設定手順です。

1. 変数の設定

まずは、dataLayerから送信されたデータを受け取るための変数を設定します。

GTMの変数設定で以下の2つを作成します。

【Item ID変数の設定】
- 変数名: Item ID
- 種類: データレイヤー変数
- データレイヤー変数名: item_id

【Item Title変数の設定】
- 変数名: Item Title
- 種類: データレイヤー変数
- データレイヤー変数名: item_title

これらの変数は、後ほどGA4にデータを送信する際のパラメータとして使用します。

2. トリガーの設定

次に、イベントを検知するためのトリガーを設定します。

【トリガーの設定】
- トリガー名: Item View
- トリガータイプ: カスタムイベント
- イベント名: item_view

このトリガーは、dataLayerにプッシュされたitem_viewイベントを検知します。

3. タグの設定

最後に、GA4にデータを送信するためのタグを設定します。

【タグの設定】
- タグ名: GA4 - Item View
- タグタイプ: Google タグ
- 測定ID: G-XXXXXXXX

イベントパラメータ:
- item_id: {{Item ID}}
- item_title: {{Item Title}}

GA4での設定と分析

カスタムディメンションの設定

GA4でデータを分析するために、まずカスタムディメンションを設定する必要があります。

管理画面から以下のディメンションを作成します。

1. Item ID（イベントスコープ）
2. Item Title（イベントスコープ）

レポートの作成

探索レポートを使って、以下のように分析が可能です。

• ディメンション：Item Title
• 指標：イベントカウント
• フィルター：イベント名 = item_view

これにより、各カードの表示回数を確認できます。

デバッグのポイント

1. GTMのプレビューモード

GTMのプレビューモードでは以下を確認します。

• dataLayerにイベントが正しく送信されているか
• 変数が期待通りの値を取得できているか
• タグが正しいタイミングで発火しているか

2. GA4のデバッグビュー

GA4のデバッグビューでは

• イベントが正しく送信されているか
• パラメータが正しく設定されているか

を確認できます。

よくあるトラブルと解決方法

イベントが発火しない

• dataLayerの実装を確認
• コンソールでエラーがないか確認

パラメータが取得できない

• GTMの変数名が正しいか確認
• dataLayerの構造を確認

GA4にデータが反映されない

• 測定IDが正しいか確認
• 最大48時間の遅延を考慮

→ 実際に24時間くらいデータが反映されず、実装が間違っているのかと見直していましたが時間が経てば反映されてました

参考リンク

Google Analytics for developers  |  Google for Developers

developers.google.com

デベロッパー向け Google アナリティクス  |  Google Analytics  |  Google for Developers

developers.google.com

ECS Execを使用してコンテナに直接アクセスする方法を解説します。

ECS Execとは

ECS Execは、AWS ECSの実行中のコンテナに直接SSHのような形でアクセスできる機能です。この機能により、以下のようなことが可能になります。

• コンテナ内でのコマンド実行
• ログファイルの直接確認
• プロセスの状態確認
• ファイルシステムの調査

前提条件

• AWS CLIがインストールされていること
• AWSプロファイルが設定されていること
• 対象のECSタスクでECS Execが有効になっていること
• 適切なIAM権限が付与されていること

手順

1. AWS認証情報の設定

開発環境用のプロファイルを設定します：

$ export AWS_PROFILE=${profile}

2. 必要な情報の確認

ECS Execを使用するために必要な情報は以下の3つです：

1. クラスター名
2. タスクID
3. コンテナ名

これらの情報は、AWS Management ConsoleのECSダッシュボードから確認できます。

https://ap-northeast-1.console.aws.amazon.com/ecs/v2/clusters/[クラスター名]/services

3. ECS Execの実行

以下のコマンドを使用してコンテナにアクセスします：

aws ecs execute-command \
--region ap-northeast-1 \
--cluster [クラスター名] \
--task [タスクID] \
--container [コンテナ名] \
--interactive \
--command "/bin/sh"

4. シェルの変更

コンテナに接続後、より使いやすいbashシェルに切り替えます。

bash

接続エラーが発生する場合

An error occurred (InvalidParameterException) when calling the ExecuteCommand operation:
The execute command failed because execute command was not enabled on the task.

• タスク定義でECS Execが有効になっているか確認
• IAM権限が適切に設定されているか確認