Pockit
Back

Cursor Rules完全ガイド：.cursorrules と Memory Bank で開発効率を10倍にする方法

AIコーディングアシスタントに、プロジェクト構造やコーディング規約、技術スタックを何度も説明した経験はありませんか？あなただけではありません。Cursor、GitHub Copilot、Windsurfなど AI搭載IDEを使う開発者なら誰もが直面する悩みです。

解決策があります。Cursor Rules と Memory Bank—この2つの機能を使いこなせば、毎回忘れてしまうジュニア開発者のようなAIが、プロジェクトを熟知したシニアエンジニアに変わります。

この記事では、基本的な .cursorrules の設定から、開発スタイルを根本から変える高度なMemory Bankアーキテクチャまで、すべて解説します。最後まで読めば、開発時間を半分に減らせる実践的なセットアップが完成しますよ。

コンテキスト問題：なぜAIは毎回忘れるのか？

AIコーディングアシスタントを使ったことがある開発者なら、こんな経験があるはずです：

自分：「ユーザープロフィールのAPIエンドポイントを追加して」
AI：*Express.jsのコードを生成*
自分：「いや、うちはFastifyを使ってるんだ」
AI：「すみません！Fastifyバージョンをお出しします...」
自分：「あと、TypeScript strictモードね」
AI：「承知しました！作り直します...」
自分：「エラーハンドリングはResult型パターンで」
AI：「了解です！修正版をどうぞ...」

このやり取りの繰り返し...ただ面倒なだけではありません—膨大な時間のロスです。2025年のStack Overflow開発者調査によると、開発者はAIとの対話時間の平均**23%**を、すでに伝えたはずの情報を繰り返し説明することに費やしているそうです。

根本原因：AIは記憶できない

LLM（大規模言語モデル）は生まれつき状態を持ちません。新しい会話は常に白紙からスタートし、過去のやり取りを覚えていません。セキュリティや一貫性の面ではメリットですが、実際の開発現場の実情とはかけ離れています。

私たちのコードベースには：

  • 数ヶ月・数年前に決めたアーキテクチャの決定
  • チームごとに異なるコーディング規約
  • すべてのファイルに影響する技術スタックの選択
  • あちこちで繰り返されるビジネスロジックパターン

コンテキストを維持し続けなければ、AIは毎回ゼロから学び直すことになります。

コンテキスト損失のコスト

実際にどれだけロスしているか計算してみましょう。機能を1つ実装するとき：

タスクコンテキストなしコンテキストあり
プロジェクト構造の把握5-10分0分
技術スタックの説明3-5分0分
コードスタイルの修正指示5-8分0分
フレームワーク固有の問題解決10-15分1-2分
機能あたりの総オーバーヘッド23-38分1-2分

週に5機能をリリースするチームなら、開発者1人あたり週3時間以上節約できます。

.cursorrules の基本：AIへの取扱説明書

.cursorrules ファイルは、コンテキスト問題を解決するためにCursorが作った仕組みです。プロジェクトルートに置くシンプルなテキストファイルで、AIに従うべきルールを永続的に伝えます。

.cursorrules とは？

.cursorrules は、すべての会話に自動で付加されるシステムプロンプトと考えてください。AIに以下を事前に伝えます：

  • 自分は誰か（役割、スキルレベル）
  • このプロジェクトは何か
  • どんな技術を使っているか
  • コードをどう書いてほしいか
  • どのパターンを使い、何を避けるべきか

基本セットアップ

.cursorrules ファイルの作成は簡単：

# プロジェクトルートで
touch .cursorrules

最小限の例：

# プロジェクトコンテキスト
Next.js 14のApp Routerを使ったアプリです。
TypeScript strictモードを使用中。
スタイリングはTailwind CSS。

# コードスタイル
- Hooksを使った関数コンポーネントで
- default exportよりnamed export優先
- 公開関数にはJSDocコメント必須

CursorがRulesを処理する仕組み

CursorのAI機能（Cmd+K、Chat、Composer）を使うとき、.cursorrulesの内容は：

  1. プロジェクトを開くと自動的にロード
  2. プロンプトの前にコンテキストとして注入
  3. すべてのAI機能に一貫して適用

つまり、AIが生成するすべてのコードが、言わなくても既に自分の好みを知っている状態になります。

.cursorrules vs 設定の「Rules for AI」

Cursorの設定にも「Rules for AI」がありますが、使い分けが重要です：

機能.cursorrules設定のRules
適用範囲プロジェクト固有全プロジェクト共通
バージョン管理あり（gitにコミット）なし
チーム共有自動手動
用途プロジェクト規約個人の好み

ベストプラクティス：プロジェクト固有のコンテキストは.cursorrulesに、個人のコーディングスタイル（例：「セミコロン必須」「明示的な型付け」）は設定のRulesに。

効果的な.cursorrules ファイルの構成

オープンソースや開発者コミュニティで多数の.cursorrulesファイルを分析した結果、この構成が最も効果的だとわかりました。

おすすめの構成

# 役割と専門性
[AIがどんな役割かを定義]

# プロジェクト概要
[プロジェクトの概要を一言で]

# 技術スタック
[使っている技術の詳細]

# アーキテクチャ
[プロジェクト構造とパターン]

# コードスタイルガイド
[フォーマット、命名、規約]

# よく使うパターン
[例付きの再利用コードパターン]

# やってはいけないこと
[アンチパターン、禁止事項]

# テスト要件
[テストの書き方と構成]

# ドキュメント基準
[コメントとドキュメントの期待値]

セクション別詳細解説

1. 役割と専門性

AIの「ペルソナ」と専門レベルを設定します：

# 役割と専門性

あなたは以下に深い専門知識を持つシニアフルスタック開発者です：
- ReactとNext.jsエコシステム
- TypeScriptと型安全プログラミング
- PostgreSQLとデータベース最適化
- AWSインフラとサーバーレスアーキテクチャ

ソリューションを提供する際は、ユーザーがTypeScript中級レベルで、
高度なパターンには説明が必要かもしれないと想定してください。

なぜ重要か：専門領域を定義することで、AIがより適切な提案をし、正しい用語を使うようになります。

2. プロジェクト概要

AIにプロジェクトのコンテキストを伝えます：

# プロジェクト概要

デジタル製品を販売するECプラットフォームです。

主な機能：
- OAuthプロバイダーによるユーザー認証
- 検索・フィルタリング付き商品カタログ
- ショッピングカートと決済フロー
- 販売者向け商品管理ダッシュボード
- プラットフォーム管理用の管理者パネル

アプリケーションは約5万人のDAUにサービスを提供し、
1日2,000件以上の取引を処理しています。

なぜ重要か：規模と目的がコード判断に影響します。ビジネスコンテキストを理解していれば、AIはより良いトレードオフを選択できます。

3. 技術スタック（最重要セクション）

ここは徹底的に書いてください—コンテキスト損失の大部分がここで発生します：

# 技術スタック

## フロントエンド
- フレームワーク: Next.js 14 (App Router)
- 言語: TypeScript 5.3+ (strictモード)
- スタイリング: Tailwind CSS 3.4 + shadcn/ui
- 状態管理: グローバルはZustand、サーバー状態はReact Query
- フォーム: React Hook Form + Zod

## バックエンド
- ランタイム: Node.js 20 LTS
- API: Next.js API Routes + tRPC（型安全エンドポイント用）
- DB: PostgreSQL 16 + Prisma ORM
- キャッシュ: Redis（セッション、レートリミット）
- キュー: BullMQ（バックグラウンドジョブ）

## インフラ
- ホスティング: Vercel（フロントエンド）+ Railway（DB）
- CDN: Cloudflare（静的アセット）
- モニタリング: Sentry（エラー）、Axiom（ログ）
- CI/CD: GitHub Actions

## 主要な依存関係
- [email protected] - 認証
- stripe@14 - 決済
- resend - トランザクションメール
- uploadthing - ファイルアップロード

💡 ポイント：主要な依存関係のバージョン番号を必ず含めましょう。AIがdeprecatedなAPIを提案するのを防げます。

4. アーキテクチャ

プロジェクト構造をドキュメント化：

# アーキテクチャ

## ディレクトリ構造

src/
├── app/ # Next.js App Routerページ
│ ├── (auth)/ # 認証ルート（グループ化）
│ ├── (dashboard)/ # 保護されたダッシュボードルート
│ ├── api/ # APIルート
│ └── layout.tsx # ルートレイアウト
├── components/
│ ├── ui/ # shadcn/uiコンポーネント（変更禁止）
│ ├── forms/ # フォームコンポーネント
│ └── features/ # 機能別コンポーネント
├── lib/
│ ├── db/ # DBクライアントとクエリ
│ ├── auth/ # 認証ユーティリティ
│ └── utils/ # 共有ユーティリティ
├── server/
│ ├── routers/ # tRPCルーター
│ └── services/ # ビジネスロジック
└── types/ # 共有TypeScript型


## 主要パターン
- components/features/内で機能ベースの組織化
- DBクエリはすべてlib/db/経由
- ビジネスロジックはAPIルートではなくserver/services/に
- 共有型はtypes/で一度定義し、どこからでもインポート

5. コードスタイルガイド

フォーマット設定を明確に定義：

# コードスタイルガイド

## フォーマット（ESLint + Prettierで強制）
- 2スペースインデント
- シングルクォート
- セミコロンなし
- 80文字行制限
- 複数行構造でトレーリングカンマ

## 命名規則
- コンポーネント: PascalCase (UserProfile.tsx)
- Hooks: 'use'プレフィックス付きcamelCase (useAuth.ts)
- ユーティリティ: camelCase (formatCurrency.ts)
- 型: 説明的サフィックス付きPascalCase (UserCreateInput)
- 定数: SCREAMING_SNAKE_CASE

## コンポーネント構成
Reactコンポーネントは常にこの順序で構成：
1. 型定義
2. コンポーネント関数
3. Hooks（順序: state, refs, effects）
4. イベントハンドラー
5. レンダーヘルパー
6. return文

## インポート順序
1. React と Next.js
2. サードパーティライブラリ
3. 内部エイリアス (@/components, @/lib)
4. 相対インポート
5. スタイル

6. よく使うパターン

繰り返し使うパターンのコード例を提供：

# よく使うパターン

## APIルートパターン
```typescript
// app/api/users/route.ts
import { NextRequest, NextResponse } from 'next/server'
import { z } from 'zod'
import { getServerSession } from '@/lib/auth'
import { prisma } from '@/lib/db'

const createUserSchema = z.object({
  name: z.string().min(2),
  email: z.string().email(),
})

export async function POST(req: NextRequest) {
  try {
    const session = await getServerSession()
    if (!session) {
      return NextResponse.json(
        { error: 'Unauthorized' },
        { status: 401 }
      )
    }

    const body = await req.json()
    const data = createUserSchema.parse(body)
    
    const user = await prisma.user.create({ data })
    
    return NextResponse.json(user, { status: 201 })
  } catch (error) {
    if (error instanceof z.ZodError) {
      return NextResponse.json(
        { error: 'Validation failed', details: error.errors },
        { status: 400 }
      )
    }
    throw error
  }
}

カスタムHookパターン

// hooks/useAsync.ts
export function useAsync<T>(asyncFn: () => Promise<T>) {
  const [state, setState] = useState<{
    data: T | null
    error: Error | null
    loading: boolean
  }>({
    data: null,
    error: null,
    loading: true,
  })

  useEffect(() => {
    asyncFn()
      .then(data => setState({ data, error: null, loading: false }))
      .catch(error => setState({ data: null, error, loading: false }))
  }, [asyncFn])

  return state
}

#### 7. やってはいけないこと

アンチパターンを明示的にリスト化：

```markdown
# やってはいけないこと

## 絶対NG
- ❌ `any`型を使う（`unknown`を使って型を絞る）
- ❌ 理由なくESLintルールを無効化
- ❌ `var`を使う（`const`か`let`で）
- ❌ 状態を直接変更
- ❌ 動的リストでindexをkeyにする
- ❌ localStorageに機密データを保存
- ❌ APIルートで同期ファイル操作

## レガシーパターン（古いコードにのみ存在）
- `getServerSideProps` → Server Components使用
- `pages/`ディレクトリ → App Routerに移行済み
- `styled-components` → Tailwind CSS使用
- `moment.js` → `date-fns`またはネイティブIntl API

## パフォーマンス・アンチパターン
- データフェッチに`useEffect`使用禁止（React Query使用）
- レンダー内でオブジェクト/配列生成禁止（useMemo使用）
- サーバーフェッチが可能なのにクライアントでフェッチしない

Memory Bank：AIに長期記憶を与える

.cursorrulesが静的なコンテキストを提供するのに対し、Memory Bankはプロジェクトと共に進化する動的な知識ベースを作ります。

Memory Bankとは？

Memory Bankは、AIの「外部脳」として機能する構造化されたドキュメントシステムです。以下を保存します：

  • あまり変わらないプロジェクトコンテキスト
  • 進行中の作業の進捗履歴
  • アーキテクチャ決定とその理由
  • 複雑なシステムの技術仕様

Memory Bank のアーキテクチャ

推奨構造：

.cursor/
└── memory/
    ├── projectbrief.md      # ハイレベルプロジェクト概要
    ├── productContext.md    # ビジネスロジックと要件
    ├── systemPatterns.md    # アーキテクチャとデザインパターン
    ├── techContext.md       # 詳細な技術仕様
    ├── activeContext.md     # 現在のフォーカスと最近の作業
    └── progress.md          # 継続的なタスク追跡

Memory Bankのセットアップ

ステップ1：ディレクトリ構造を作成

mkdir -p .cursor/memory

ステップ2：Cursorが使用するよう設定

.cursorrulesに以下を追加：

# Memory Bank連携

作業開始前に関連するMemory Bankファイルを読んで：
- .cursor/memory/projectbrief.md - プロジェクト概要
- .cursor/memory/techContext.md - 技術的な決定
- .cursor/memory/activeContext.md - 現在の作業コンテキスト

重要な作業が終わったら更新して：
- .cursor/memory/progress.md - 完了したものを追加
- .cursor/memory/activeContext.md - 現在のフォーカスを更新

ステップ3：ファイルを作成

各ファイルのテンプレート：

projectbrief.md

# プロジェクトブリーフ：[プロジェクト名]

## ビジョン
[成功したらどんな姿か、1段落で]

## コア機能
1. [機能1]: [概要]
2. [機能2]: [概要]
3. [機能3]: [概要]

## ターゲットユーザー
- メイン: [ユーザータイプとニーズ]
- サブ: [ユーザータイプとニーズ]

## 主要指標
- [指標1]: [目標値]
- [指標2]: [目標値]

techContext.md

# 技術コンテキスト

## アーキテクチャ決定記録

### 決定：[タイトル]
- **日付**: YYYY-MM-DD
- **ステータス**: 承認済み
- **背景**: [なぜこの決定が必要だったか？]
- **決定**: [何を決めたか？]
- **影響**: [どんな結果になるか？]

## システム境界
[コンポーネント間の相互作用を図または説明で]

## データフロー
[データがシステムをどう流れるかの説明]

activeContext.md

# アクティブコンテキスト

## 現在のフォーカス
[今何に取り組んでいるか？]

## 最近の完了
- [日付]: [完了した内容]
- [日付]: [完了した内容]

## ブロッカー
- [ブロッカー1]: [ステータス/計画]

## 次のステップ
1. [次のタスク]
2. [その次のタスク]

Memory Bankワークフロー

「Plan and Act」パターン

このワークフローは、AIが常に最新のコンテキストで作業することを保証します：

# .cursorrules内

## ワークフロー：Plan and Act

タスクを受けたら：
1. 関連するMemory Bankファイルを読む
2. 既存のコンテキストに基づいてアプローチを計画
3. 文書化されたパターンと矛盾があれば確認を求める
4. 承認された計画に従って実行
5. 新しく学んだことでMemory Bankを更新

コマンド：
- "mem:init" - 新プロジェクト用Memory Bankを初期化
- "mem:update" - 作業後にMemory Bankを更新
- "mem:status" - 現在のMemory Bank状態を表示

Memory Bankを最新に保つ

主な課題はドキュメントを最新に保つことです。戦略をいくつか：

トリガーベース更新：重要なイベント後に更新

以下を完了したらMemory Bankを更新：
- 新機能の実装
- アーキテクチャの変更
- 依存関係の更新
- システム問題のバグ修正

セッション終了ルーティン：終了前に必ず更新

各コーディングセッションの終わりに実行：
「今日の進捗でMemory Bankを更新して」

実践的なパターンと事例

パターン1：マルチパッケージモノレポ

複雑なモノレポでは、パッケージごとにルールを作成：

project/
├── .cursorrules              # ルートルール（共有）
├── packages/
│   ├── web/
│   │   └── .cursorrules     # Web専用ルール
│   ├── api/
│   │   └── .cursorrules     # API専用ルール
│   └── shared/
│       └── .cursorrules     # 共有パッケージルール

ネストされた.cursorrulesはルートを参照可能：

# packages/api/.cursorrules

ルートの.cursorrules を継承。

## API固有のコンテキスト
このパッケージはExpress.js APIサーバーを含みます。

## 追加の依存関係
- [email protected]
- passport（OAuth用）
- jest（テスト用）

## APIパターン
[API固有のパターン...]

パターン2：TDD連携

# TDDワークフロー

新機能を実装するとき：
1. 失敗するテストを先に書く
2. パスする最小限のコードを実装
3. テストをグリーンに保ちながらリファクタリング

## テストファイル規則
- 単体テスト：ソースファイルの隣に`*.test.ts`
- 統合テスト：`__tests__/integration/`
- E2Eテスト：`e2e/`

## テストパターン
```typescript
describe('UserService', () => {
  describe('createUser', () => {
    it('有効な入力でユーザーを作成すべき', async () => {
      // Arrange
      const input = { name: 'Test', email: '[email protected]' }
      
      // Act
      const result = await userService.createUser(input)
      
      // Assert
      expect(result.id).toBeDefined()
      expect(result.name).toBe(input.name)
    })

    it('重複メールでエラーを投げるべき', async () => {
      // ...
    })
  })
})

### パターン3：AIセーフティガードレール

AIが危険な変更をするのを防ぐ：

```markdown
# セーフティガードレール

## 保護されたファイル（明示的な許可なしに変更禁止）
- `.env*` ファイル
- `prisma/migrations/`（prisma migrate使用）
- `package-lock.json`（npmコマンドで）
- `.github/workflows/`（CI設定）

## 危険な操作（必ず先に確認）
- DBスキーマ変更
- ファイル/ディレクトリ削除
- 認証ロジックの変更
- APIレスポンス形式の変更（breaking change）

## セキュリティ必須
- 機密データをログに出さない（パスワード、トークン、PII）
- DBクエリ前にユーザー入力を必ず検証
- パラメータ化されたクエリを使用（Prismaが対応）
- 外部入力はZodで検証

パターン4：ドメイン固有言語

ドメイン特有の用語があるプロジェクト向け：

# ドメイン用語集

## ビジネス用語
- **Workspace**: マルチテナントシステムのテナント
- **Member**: Workspaceに所属するユーザー
- **Asset**: ユーザーがアップロードしたファイル
- **Collection**: Assetのまとまり

## 技術用語
- **Hydration**: サーバー→クライアント状態転送
- **Stale-while-revalidate**: キャッシング戦略
- **Optimistic update**: API確認前のUI更新

コードを書くときはこれらの用語を一貫して使用。
変数名はドメイン言語を反映する：
- ✅ `workspace`, `member`, `asset`
- ❌ `tenant`, `user`, `file`

よくある失敗と回避方法

失敗1：情報過多

問題：1万語の.cursorrulesファイルがコンテキストウィンドウを圧迫。

解決：核心だけ入れて外部ドキュメントを参照：

# すべてを含める代わりに...

API詳細ドキュメント：docs/api/README.md 参照
コンポーネントライブラリ：docs/components/README.md 参照

# .cursorrules には重要なコンテキストだけ

失敗2：古くなったルール

問題：.cursorrulesには「React 17使用」と書いてあるが、React 19にアップグレード済み。

解決：検証ステップを追加：

# ルール管理

最終更新：2026-01-06

このルールを信頼する前に確認：
- package.jsonで現在のバージョンをチェック
- 最近のコミットでパターン変更がないか確認
- 不明な場合はチームに確認

失敗3：ルールが厳しすぎる

問題：ルールが具体的すぎてAIがエッジケースを処理できない。

解決：ルールではなく原則を提供：

# 基本原則

1. **賢さより読みやすさ**：退屈で明確なコード優先
2. **暗黙より明示**：すべてに型をつけ、名前は明確に
3. **継承より合成**：小さく集中した関数で
4. **早期に失敗**：早めに検証、早めにエラー

ルールがカバーしない状況では、これらの原則を適用。

失敗4：チームダイナミクスの無視

問題：1人の開発者が作ったルールがチームの合意を反映していない。

解決：.cursorrulesを共有ドキュメントに：

# ルールへの貢献

このファイルはバージョン管理され、チーム全体で共有されています。

変更を提案する場合：
1. 変更を含むPRを作成
2. PR説明にコンテキストを追加
3. 最低1人のチームメンバーから承認を得る

最終チームレビュー：2026-01-01

AIコーディングの未来

ここまで解説した.cursorrulesとMemory Bankのパターンは始まりに過ぎません。AIコーディングアシスタントが進化するにつれ、こんなトレンドが見えてきています：

トレンド1：エージェンティックワークフロー

次世代のAIアシスタントはプロンプトへの応答だけでなく、能動的に：

  • 問題を検知して修正を提案
  • テストを実行して失敗したら自動で改善
  • ドキュメント付きのPRを自動生成
  • 本番環境をモニタリングして最適化を提案

.cursorrulesは、自律的行動の境界を定義する「エージェントポリシー」を含むよう進化するでしょう。

トレンド2：マルチモデルオーケストレーション

異なるAIモデルは異なるタスクに優れています。将来のセットアップはこうなるかも：

  • アーキテクチャ決定：GPT-4
  • コード生成：Claude
  • ドキュメント：Gemini
  • 機密コード：ローカルモデル

ルールにはモデル固有の指示が含まれるようになるでしょう。

トレンド3：継続学習するコンテキスト

静的な.cursorrulesの代わりに、AIシステムが以下から学習：

  • コードレビューのコメント
  • リファクタリングパターン
  • テスティングの好み
  • デバッグアプローチ

Memory Bankはより自動化され、AIが自身の知識ベースを積極的に管理するようになるでしょう。

未来に備える

先を行くために：

  1. 今すぐ始める：今日.cursorrulesとMemory Bankをセットアップ
  2. 継続的に改善：AIの行動を観察しながらルールを調整
  3. 決定を記録：時間が経っても価値ある知識ベースを構築
  4. 学びを共有：コミュニティのベストプラクティスに貢献

まとめ

AIアシスタントと苦戦する開発者と、10倍の生産性を発揮する開発者の違いはたった1つ：コンテキスト管理です。

.cursorrulesとMemory Bankをマスターすれば、状態を持たないツールだったAIを、頼れるシニア同僚に変えられます。セットアップに数時間投資すれば、これからのすべての作業で利子がつきますよ。

クイックスタートチェックリスト

  • プロジェクトルートに.cursorrulesを作成
  • バージョン付きで技術スタックを追加
  • 例付きで主要パターンを文書化
  • Memory Bank用に.cursor/memory/をセットアップ
  • 更新ワークフローを決める
  • バージョン管理にコミット
  • チームと共有

ソフトウェア開発の未来は人間とAIのコラボレーションです。成功する開発者は、AIパートナーと効果的にコミュニケーションできる人—そしてそのコミュニケーションは、しっかり作り込んだ.cursorrulesファイルから始まります。

プロジェクトでCursor Rules導入について質問がありますか？チームでうまくいくパターンを見つけましたか？開発者コミュニティではこのようなノウハウを活発に共有し、改善しています。基本から始めて、経験しながら改良し、学んだことをまた共有してください。

cursorai-codingdeveloper-toolsproductivityprompt-engineeringllm

関連ツールを見る

Pockitの無料開発者ツールを試してみましょう

PDFロック解除
文書のアクセス権を取り戻しましょう。ファイルをアップロードすることなく、ブラウザ内で安全にPDFのパスワードを解除します。
使ってみる
PDF パスワード設定・保護
大切な文書を保護しましょう。パスワードでPDFをロックし、権限のないユーザーの閲覧を防ぎます。すべての処理はブラウザ内で完結します。
使ってみる
コード整形・圧縮
1行にギュッと詰まった圧縮コードを読みやすく整形したり、本番用にサイズを小さくしたり。JS、CSS、HTML対応。ブラウザで完結するからコードは外に出ません。
使ってみる
テキスト比較 (Diff)
変更点を逃さずチェック。2つのテキストを並べて比較し、追加・削除された部分を色分けして表示します。
使ってみる
画像トリミング
画像構図を完璧に整えましょう。SNSやプロフィール用に比率を選んで切り抜けます。編集はブラウザ内で完結します。
使ってみる
画像サイズ変更
画像のサイズを変更したいですか？パーセント指定、ピクセル指定、InstagramやYouTube用プリセットで簡単リサイズ。複数画像の一括処理も可能。サーバーへのアップロード不要で100%安全です。
使ってみる