攻撃を受けた経緯

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

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


-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開発に携わる者として注目していくべき技術だと思います。

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

今回は実際にユーザーに使われるサービスを作りたい方に向けて、大学生の頃から現在まで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円も稼げなかったらどうしようとかやってて思いがちですが、個人的にあまり意識しすぎない方が良いと思ってます。

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

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

まずはやってみよう！

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

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

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

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

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

マイクロサービスにおけるE2Eの問題

マイクロサービス化したアプリケーションにおいていくつものAPIなどが作られるかと思いますが、それぞれのマイクロサービスのモジュールE2Eを実行する際に、関連するマイクロサービスを立ち上げてテストをすることになるかと思います。

その場合、関連するAPIやDBなどを起動する必要があり、重くて時間がかかったり、そのマイクロサービスをテストしている間は他のmicroserviceをテストすることができないなどデメリットが出てきます。

そこで、関連する他のマイクロサービスをwiremockにすることで、作業がシンプルかつ軽くなり素早いテストが実現できます。

ただその場合だと、マイクロサービスの仕様が変わった場合、変更による影響を検知できなくなる可能性があります。つまり、テストで通ったのにいざ本場にデプロイしたら落ちるといったことが起こります。

これまでの話をまとめると、以下のようになります。

関連するマイクロサービスを全て起動してテストする

起動の手間や時間がかかるなどあるが、確実にテストすることができます。

関連するマイクロサービスをWiremockにしてテストする

手間がかからず素早く実行できるが、仕様の変更の影響などによりテストの挙動が担保することができない場合があります。

それぞれのメリット・デメリットがあるなかで一つの解決策としてCDCがあります。

CDC(Consumer Driven Contract testing)とは

CDCとはAPIやマイクロサービスの開発において、サービス間の契約を定義し、各サービスが契約に従って動作することを保証するための手法のことです。

サービス間の契約を明確にし、各サービスが互いに依存していることを考慮することで、サービスの信頼性を向上させることができます。

例えば、A社のあるAPIの口にリクエストしたら、こういったレスポンスを返して欲しい場合、A社にそのAPIの口のinputとoutputのテストを書いてもらい、その挙動を担保してもらうといったイメージかと思います。

先程の例だと、テスト対象のマイクロサービスと関連するマイクロサービスにCDCを結び、関連したマイクロサービスにinputとoutputのテストをしっかり書き、その挙動を担保します。

それぞれのマイクロサービスにCDCを結んでおくことで、モジュールE2Eを実行する際に関連するマイクロサービスをWiremockとすることができます。

図のイメージだとこんな感じです。

それぞれのマイクロサービスにCDCを結ぶ手間はありますが、テストがしやすくなりました。

ここまで書いて思ったのですが、それぞれのマイクロサービスでちゃんとモジュールE2Eを書いていれば、自然とCDCが結べていることになるのかとも思いましたが、CDCを結ぶという観点を持ってテストを書くと書かないとでは意味合いが違うような気もします。

CDCを結ぶことになると、変更をしたマイクロサービスはCDCを結んでいるマイクロサービスとの契約を守る必要があるため、影響範囲に気付くことになるのかなと思いました。

クラスタ(Cluster)

クラスタは、コンテナ化されたアプリケーションを実行するためのノードマシンの集合です。クラスタには少なくとも、1 つのコントロールプレーン(マスターノードとも呼ばれている？)と、1 つ以上のノードと呼ばれるコンピューティングマシンが含まれます。

• コントロールプレーン：どのアプリケーションが実行されているかといった、クラスタの望ましい状態を維持
• ノード：実際にアプリケーションとワークロードを実行

以下のコマンドで、configの設定で指定されている接続先クラスター情報を確認できます。

$ kubectl config get-clusters

NAME
docker-desktop

コンテキスト(Context)

コンテキストはクラスタとユーザの組み合わせです。同一クラスタでも接続ユーザが異なれば、別のコンテキストとして扱われます。

以下のコマンドでコンテキストを取得できます。同じクラスタでもコンテキストが違っています。

$ kubectl config get-contexts

CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* docker-desktop docker-desktop docker-desktop
docker-desktop-2 docker-desktop docker-desktop

名前空間(Namespace)

名前空間とは、クラスタの分離機能のことで、複数のチームやユーザーでクラスターリソースを分割することができます。

名前空間を使うことで、Kubernetes内の環境に名前を付けて利用することができます。他の環境と分離させることができ、ユーザーによって権限を変えることも可能です。

$ kubectl get namespace

NAME STATUS AGE
default Active xxd
kube-node-lease Active xxd
kube-public Active xxd
kube-system Active xxd
sample Active xxd

Pod

Podは、1つまたは複数のコンテナのグループです。ストレージやネットワークの共有リソースを持ち、コンテナの実行方法に関する仕様を持っています。

Podとは、Kubernetesで実行できるアプリケーションの最小単位です。

$ kubectl get pod

NAME READY STATUS RESTARTS AGE
sample-78d9c99bd4-kdbwx 1/1 Running 0 xxd
sample-78d9c99bd4-m7mk2 1/1 Running 0 xxd

Service

Serviceとは、Podとの通信を容易に行うためにエンドポイントの提供を行ってくれる機能です。

通常、NodeのIPアドレスは一定ではないため、通信するにはその都度IPアドレスを指定する必要があります。

Serviceという機能があることで、通信するためのDNSラベルが発行され、アプリケーションが他のPodとの通信が簡単にできるようになります。

$ kubectl get service

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
sample-service NodePort 10.102.100.87 <none> 80:31512/TCP xxd

Deployment

DeploymentはPodやReplicaSetの宣言的なアップデート機能を提供します。

Kubernetesでは、Podを単独で起動することはほとんどなく、大抵の場合は、ReplicaSetやJobなどの管理用オブジェクトを通してPodを利用します。

ReplicaSetは、複数のPodのレプリカをセットで作成する機能で、DeploymentはさらにそのReplicaSetを管理します。

ローリングアップデート

Deploymentは、作成したPodの仕様が変更されると、自動的にReplicaSetを再作成します。

Deploymentのアップデート方法は、デフォルトでローリングアップデートとなっており、新しいReplicaSetを生成し、順に古いPodを新しいPodに入れ替えていきます。

そのため、ダウンタイムが発生しないというメリットがある代わりに、切り替えに多少時間がかかるというデメリットがあります。

上の図の例だと、下の新しいReplica Setが作成され、上の古いReplica Setで作成されたPodが、新しいReplica Setで作成されたPodに徐々に切り替わっていく感じです。

$ kubectl get deployment

NAME READY UP-TO-DATE AVAILABLE AGE
sample 2/2 2 2 xxd

参考記事

https://kubernetes.io/ja/docs/concepts/overview/components/

https://udemy.benesse.co.jp/development/system/kubernetes.html

https://kubernetes.io/ja/docs/concepts/workloads/pods/

TypeScriptの型システム

型は、コードの品質と読みやすさを高めることができます。

また、型はリファクタリングをする際の開発スピードを高め、型があることによって、コードを書いている時点でエラーに気づくことができます。開発中に早い段階でエラーに気づけるのは大きなメリットです。

暗黙的な型推論

型推論とは、TypeScriptがソースコードを解析し、そのコードの流れから変数や関数などの型を推測してくれる仕組みのことです。

TypeScriptは型を推論することによって、不明確なコードに対しエラーを表示してくれます。

明示的な型指定

TypeScriptは型を推論しますが、型推論の結果が正しくない場合や正確でない場合は、開発者が、明示的にコード上で、型を指定する(型アノテーションを書く)ことができます。

型アノテーションを書くことによって、開発者にとってのドキュメントにもなります。

TypeScriptの型の深堀り

型エイリアス

指定した型に別名を設定することができます。エイリアスという名の通り、新しい型というよりかは既にある型に別の名前をつけているといった感じです。

type 新型名 = 型名

type name = string
type age = number

type person = [name, age]

const taro: person = ['taro', 20]

リテラル型

リテラルというのは直接ソースコードに書かれる値のことです。以下のようにokだけしか値がない型が作れます。

type ok = ‘ok’

条件型(Conditional Types)

複数の型を許容する新しい型エイリアスが作成できます。

type 型名 = 型1 | 型2 | …

リテラル型と条件型を組み合わせることで、複数の値のいずれかを許容するenumのような働きをする型が作れます。

type msg = ‘hello’ | ‘bye’

ユーティリティ型

変数のさまざまな性質を付加する特殊な型が用意されており、これらをユーティリティ型といいます。以下のようなユーティリティ型があります。

Partial<T>

• Partial<T>はTの全てのプロパティをOptional(任意)のプロパティにしてくれる

Required<T>

• Required<T>はTの全てのプロパティを必須のプロパティにしてくれる

Readonly<T>

• Readonly<T>はTの全てのプロパティをreadonlyのプロパティにしてくれる

他のユーティリティ型などは以下を参照してください。

https://qiita.com/k-penguin-sato/items/e2791d7a57e96f6144e5

総称型(ジェネリクス)

総称型は値の型を特定せずに使用するための仕組みです。

<T>というのが、ここで使われている総称型の指定です。総称型は<>の中に抽象的な型を表す名前を指定します。このTは別にTでなくても良いが、TypeScriptではTから始まるアルファベットを使う習慣があるそうです。

複数の総称型を指定したい場合は<T, U, V…>という具合でカンマ区切りで記述します。

function 関数 <T> (引数) : 戻り値

ジェネリクスでUnitテストで使うmockを作ると以下のように書けそうです。

function mock<T>(): T {
  return ({} as unknown) as T
}

TypeScriptのクラスの深堀り

インターフェース

インターフェースはオブジェクト構造を記述するための仕組みです。インターフェースではオブジェクトに用意するプロパティやメソッドを用意できます。

ただあくまでインターフェースは構造の定義をするもので、そのまま使ってオブジェクトを作ることはできません。

interface 名前 {
  プロパティ: 型
  メソッド(引数): 型
  …
}

インターフェースの実装

用意されたインターフェースは、クラスに指定することで利用されます。クラス名の後にimplementsというキーワードを付けます。

このようにimplementsするとそのクラスでは組み込まれたインターフェースに用意されているプロパティやメソッドを全て用意しなければならないです。

つまりインターフェースはクラスにプロパティやメソッドの実装を保証するものです。

class 名前 implementes インターフェース

クリーンアーキテクチャで考えると、Portレイヤーにインターフェースを定義し、Gatewayレイヤーで実装する感じになりそうです。

interface SamplePort {
  find(): Promise<number>
}

export class SampleGateway implements SamplePort {
  async find(): Promise<number> {
    …
  }

}

インターフェースの継承

インターフェースを定義するときに「extends インターフェース」と指定することで、既にあるインターフェースを継承した新たなインターフェースを作成できます。

継承して作られたインターフェースはimplementesする際に継承もとのインターフェースに用意されているプロパティやメソッドまで含めて全て実装する必要があります。

抽象クラス

インターフェースと似たような働きをするものに抽象クラスがあります。抽象クラスは具体的な処理を持たない抽象的な存在としてのクラスです。

クラス定義の冒頭にabstractを付けることで抽象クラスになります。またメソッドもabstractをつけることで抽象メソッドになります。

abstract class クラス名 {
  abstract メソッド(): 型
  …
}

抽象クラスとインターフェースの違い

抽象クラスとインターフェースはかなり似ています。ほぼimplementesするかextendsするかの違いですが、それでも以下のような違いがあります。

他にクラスを継承する必要があるか

もし他のクラスを継承するのであれば、抽象クラスは使えません。extendsで継承できるのは1つのクラスのみであるため、抽象クラスと他のクラスを同時に継承できません。

プロパティを義務付けるか

抽象クラスは基本的にメソッドを定義するものです。抽象プロパティはないため実装クラスに必ずプロパティを用意させたければインターフェースを使う必要があります。

静的メンバー

基本的にプロパティやメソッドはインスタンスを作成して利用するという共通点があります。クラスは基本的にインスタンスを作って利用するものであるため当然とも言えます。

ただ場合によってはインスタンスが必要ないクラスもあります。こうした場合クラスのプロパティやメソッドを静的メンバーとして用意することで、クラスから直接使えるようにできます。

この静的メンバーは「static」というキーワードを使って作成します。

static プロパティ: 型
static メソッド(引数): 型

パラメータプロパティ

読み取りのみのプロパティを扱う場合、パラメータプロパティと呼ばれる機能を使う方法があります。

パラメータプロパティはコンストラクタの引数をそのままプロパティとして扱えるようにする機能です。コンストラクタにreadonlyを指定したプロパティを用意するとそれは「変更不可のプロパティ」として使えるようになります。

class People {
  constructor(
    readonly name: string
  ) {}
}

Vue.jsの特徴 Progressive Framework

Vue.jsの特徴として、Progressive Frameworkという概念に基づいて開発されています。

ビルドシステムを利用せずにVue.js単体で使うことやVuexやvue-routerを使って動的なWebアプリケーションの構築もできます。

Declative Rendering 宣言的なDOMレンダリングに関する領域

テンプレートにレンダリングする対象を宣言的に記載することでDOMレンダリングやユーザによる入力データの同期が可能になります。Vue.jsでは本体自体でこの領域をサポートしているため、LPのようなシンプルなWebサイトはじめ、小規模的なものはこの領域で解決できます。

Component System UIをモジュール化して再利用する必要がある領域

Vue.js本体自体にコンポーネント化する機能があるため、それによって開発効率を向上させることが可能になります。

Client-side Routing WebサイトがSPAとして必要とされるWebアプリケーションの領域

Vue.jsが提供しているルーティングライブラリのvue-routerを利用することで、これまでに作成したコンポーネントでSPAに対応することが可能になります。

Large-scale State Management コンポーネント間で状態の共有方法が必要となる領域

Vue.jsが提供している状態管理ライブラリのVuexを利用することで、既存のコンポーネントを拡張する形で状態を集中管理することが可能になります。

Build System コンポーネント管理やプロジェクト構成などの領域

Vue.jsが提供しているvue-cliやvue-loaderなどを利用することで、プロジェクトの環境構築や構成管理の手間が省略かされ、継続的な開発を持続できるようになります。

参考：

第1回　プログレッシブフレームワーク Vue.js | gihyo.jp

Vue.js（ビュージェイエス）は、インタラクティブなUIを構築するためのJav…

gihyo.jp

Vue.js Progressive Framework #Vue.js - Qiita

Vue.js の作者Evan氏によるVue.jsの紹介スライドで触れられていた「…

qiita.com

ライフサイクル

ライフサイクルフック

Vueのインスタンスは、インスタンスを生成時やDOM要素へのマウント時、データ更新時など、ある特定のタイミングでユーザが処理を行えるようにいくつかのライフサイクルフックが実行されます。

beforeCreate

インスタンスの初期化時に実行されます。dataなどのプロパティは生成前のためアクセスできません。

created

インスタンスの初期化後に実行されます。この時点でプロパティへのアクセスが可能になります。

beforeMount

マウント前に実行されます。この時点ではDOM要素にはアクセスできません。

mounted

マウント後に実行されます。この時点でDOM要素へのアクセスが可能になります。

beforeUpdate

DOM更新前に実行されます。

update

DOM更新後に実行されます。

beforeDestroy

インスタンスの破棄の前に実行されます。この時点ではプロパティへのアクセスは可能です。

destroyed

インスタンスが破棄された後に実行されます。この時点からプロパティへのアクセスはできません。

ライフサイクルフックの動きを確認する

実際にいくつかのライフサイクルフックを使って動きを確認してみました。

beforeCreate

インスタンス初期化時に実行されます。このタイミングでは、インスタンスは初期化前ですので、msgは呼ばれません。

<script>
export default {
  name: 'HelloWorld',
  data () {
    return {
      msg: 'Welcome to Your Vue.js App'
    }
  },
  beforeCreate () {
    console.log('beforeCreate：' + this.msg)
  }
}
</script>

// beforeCreate：undefined

created

インスタンス生成後に実行されるため、msgが呼び出されます。

<script>
export default {
  name: 'HelloWorld',
  data () {
    return {
      msg: 'Welcome to Your Vue.js App'
    }
  },
  created () {
    console.log('created：' + this.msg)
  }
}
</script>

// created：Welcome to Your Vue.js App

beforeMount

インスタンスが作成された後、elementへのマウントされる前で実行されます。

そのためmsgは更新されず、「Welcome to Your Vue.js App」と表示されます。

...

  <h1>{{ msg }}</h1>

...

<script>
export default {
  name: 'HelloWorld',
  data () {
    return {
      msg: 'Welcome to Your Vue.js App'
    }
  },
  beforeMount () {
    this.msg = 'Update Your Vue.js App'
  }
}
</script>

// Welcome to Your Vue.js App

mounted

elementへのマウントがされた後に実行されるため、msgが更新され「Update Your Vue.js App」と表示されます。

createdとの違いとしてmountedは、elementへのマウントが行われた後処理されます。また、mountedはSSRの場合は使えないので注意が必要です

...


  <h1>{{ msg }}</h1>

...

<script>
export default {
  name: 'HelloWorld',
  data () {
    return {
      msg: 'Welcome to Your Vue.js App'
    }
  },
  mounted () {
    this.msg = 'Update Your Vue.js App'
  }
}
</script>

// Update Your Vue.js App

参考：

Vue インスタンス — Vue.js

Vue.js - The Progressive JavaScript Fram…

jp.vuejs.org

Understanding the Vue.js Lifecycle Hooks

Each Vue instance has many lifecycle hoo…

vueschool.io

Vuex

VuexとはVue.js アプリケーションのための 状態管理パターン + ライブラリです。

Vuexを使うことで、複雑に構成されたコンポーネントでのデータ管理の難しさを解決することができます。

Vuexという一つの入れ物にデータを入れることで、どのコンポーネントからでもVuex内に保持するデータへのアクセスが可能になります。

Actions

API等と非同期通信を行い、データを取得します。取得後はデータをコミットし、Mutationsを呼び出します。

Mutations

Actionsやコンポーネントからデータがコミットされた時に呼び出されます。唯一State内のデータを変更することが出来ます。

State

各コンポーネントで使用するデータはここに集約します。

Vuexの使いどころ

Vuexの使いどころについては以下の記事がとても参考になりました。

そもそもVuexを使うべきか、使うとしてもOrganismレベル以上のコンポーネントからのみStoreの参照、変更を許可するなど、どういったルールで運用すべきかを考慮することが大切です。

参考：