2026年1月アーカイブ

目次

• 1. はじめに
• 2. Cursorの概要
• 3. 言語モデルの選択
• 4. 4つのモード
• 　4-1. Agentモード
• 　4-2. Askモード
• 　4-3. Planモード
• 　4-4. Debugモード
• 5. Rulesの設定
• 　5-1. プロジェクトルール
• 　5-2. ユーザールール
• 6. コードレビューでの活用
• 　6-1. レビュー用のプロジェクトルールを作成する
• 　6-2. レビュー対象の差分ファイルを作成する
• 　6-3. レビューしてもらう
• 7. おわりに

1. はじめに

生成AIを活用したコードエディタが急速に広まりつつある昨今、Cursorはその代表的な存在のひとつです。

私自身、とあるプロジェクトでCursorを使うことになったものの、使い始めて数日は正直なんとなくで使っていたところがありました。

そこで本記事では、

　・これからCursorを使ってみようとしている方
　・とりあえず使い始めたものの、手探りで使っている方

に向けて、実際の画面や設定例を交えながら、使ってみて「もっと早く知っておけばよかった」と感じたポイントをまとめてみました。

2. Cursorの概要

Cursorは、VSCodeをベースに生成AIを統合したコードエディタです。
既にVSCodeを使っている方であればCursorへの機能的・心理的な移行はスムーズかと思います。

コード補完や生成だけでなく、既存のプロジェクト全体を前提にした質問応答や、設計・実装の補助までをエディタ上で完結できる点が特徴です。

ChatGPTを別タブで使うのとは異なり、現在のコードやファイル構成を文脈として扱えるため、より実践的なやり取りが可能になります。

3. 言語モデルの選択

CursorではGPT系やGemini系など含めて様々な言語モデルを選択できますが、モデルごとに料金や得意な作業が異なります。

下の表では、2025年12月時点での代表的なモデルとその特徴について、入力単価が安い順に整理しています。
特徴についてはCursorに聞いてまとめてもらいました。

現状、公式ドキュメントにモデルごとの具体的な利用シーンが詳しく載っているわけではなく、実際には試しながら把握していく部分も多い印象です。

また、実際の開発では「これは軽い作業だからこのモデル」「次は設計だからこのモデル」とモデルを毎回切り替えるのは、思った以上に判断コストがかかります。

そのため、モデル選択にこだわりがない場合は、少なくとも最初はデフォルトのAutoを使うのが無難だと感じました。

Autoは、Cursorがタスク内容に応じて適切なモデルを自動で選択してくれるため、モデルの違いを意識せずに作業を進めることができます。

ただし、稀に「急に変なこと言い出したな」と感じる場面もあるため、その場合は明示的にモデルを選択する必要があるかと思います。

4. 4つのモード（Agent/Ask/Plan/Debug）

Cursorには、作業内容ごとに使い分けられるAgent / Ask / Plan / Debugの4つのモードが用意されています。
デフォルトではAgentモードで動作します。

言語モデルはデフォルトのAutoのままでも大きな問題は起きにくい一方で、モードについてはそれぞれの特徴を理解した上で使い分ける必要があると思っています。

4-1. Agentモード

Agentモードは、エディタ上でのコード作成やコマンド実行などの作業をCursorに任せたいときに使います。

新機能の実装やRspecのテスト作成など、実際に手を動かす開発作業をまとめて進められます。

一方で、Agentモードは「最終的にコードを直す」前提で動く傾向があります。

例えば「このエラーの原因は？」と単に質問しただけのつもりでも、原因が確定していない段階でもコードの修正まで進めてしまうことがあります。

そのため、考えを整理したいだけの場面や、まずは状況を理解したい段階では、後述する別のモードを選んだほうが快適でしょう。

4-2. Askモード

Askモードはその名の通り、質問や相談をしたいときに使います。

途中から入ったプロジェクトの既存コードの流れを理解したい場合や、この処理が何を意図して書かれているのかを確認したい場面などで有効です。

私の場合は費用を抑えるため、一般的な構文や言語仕様のようにプロジェクトの文脈が不要な内容はChatGPTで確認し、 文脈を踏まえた回答が必要な場合はAskモードを使うようにしています。

4-3. Planモード

Planモードは、実装に入る前に方針を整理・具体化したいときに使います。

こちらから要件や目的を伝えると、Cursorから前提条件や確認事項が提示されます。

それらのやり取りを踏まえて、実装方針や作業手順をMarkdown形式のドキュメントとしてまとめてくれます。

「何を作るか」「どこを直すか」などを文章として可視化できるため、少し規模のある改修や新機能を考える場面で役立ちます。

また、作成された計画ファイルは、後述するコードレビューでも活用できます。

※Planモードについてはコチラの記事でも詳しく紹介されているので是非ご覧ください。
Cursor Planモードのススメ：なぜ"いきなり書かせる"と事故るのか

4-4. Debugモード

Debugモードは、バグの原因特定から修正・検証までを進めたいときに使います。

バグの状況を伝えると、複数の仮説を立てたうえでログ出力の追加などのコード修正を行い、バグ再現のための画面操作やコマンド実行の手順を示してくれます。

その実行結果をもとに原因を絞り込み、修正案の提示や再修正を進めていく流れになります。

このモードは2025年12月にリリースされた比較的新しいもので、まだあまり試せてはいませんが、デバッグの進め方そのものを支援してくれる点が特徴的だと感じています。

5. Rulesの設定

Cursorには、振る舞いをあらかじめ調整できる「Rules」という仕組みがあり、プロジェクト固有の前提や自分の作業スタイルを共有した状態でCursorとやり取りできます。

Rulesには主にプロジェクトルールとユーザールールの2つがあり、いずれもCursor SettingsのRules and Commandsから設定できます。

5-1. プロジェクトルール

プロジェクトルールは、特定のプロジェクトごとに適用されるルールで、開発環境や作業前提などをCursorに伝えることができます。

例えば、RSpecをDocker Compose経由で実行する場合は以下のようなルールを設定できます。

--- alwaysApply: true --- RSpecのテストを実行する際は、必ず以下の形式で実行すること： - 'docker-compose exec web bundle exec rspec [テストファイルパス]' - 直接 'bundle exec rspec' を実行しないこと 例： - 全テスト: 'docker-compose exec web bundle exec rspec' - 特定ファイル: 'docker-compose exec web bundle exec rspec spec/models/user_spec.rb' - 特定行: 'docker-compose exec web bundle exec rspec spec/models/user_spec.rb:10'

このルールにより、CursorはRSpecを正しいコマンドで実行できるようになります。

ルールがない場合はデフォルトでbundle exec rspecなどを実行して失敗するため、毎回正しいコマンドを指示する必要があります。
（これが結構ストレスでした。。）

なお、alwaysApplyはルールの適用方法（Rules Type）の一つで、すべてのチャットセッションに自動的に適用されることを表しています。
適用方法は「そのルールをどのタイミングで適用するか」を指定するもので、全部で4つあります。

5-2. ユーザールール

ユーザールールは、すべてのプロジェクトに適用されるルールで、会話スタイルや個人の開発スタイルをCursorに伝えることができます。

例えば、私の環境では以下のようなルールがあらかじめ設定されていました。
（Cursorを日本語対応させた際に自動で追加されたのかもしれません。）

Always respond in Japanese

このように、ユーザールールはプロジェクトルールとは異なり1~2文程度で簡潔に記載するのが良いようです。

6. コードレビューでの活用

Cursorは実装や修正だけでなく、コードレビュー用途でもかなり使えます。

今のところ、以下のような手順でレビューしてもらっています。

6-1. レビュー用のプロジェクトルールを作成する

例えばこのようなルールを作成します。

--- alwaysApply: true --- # コードレビュールール コードレビューを行う際は、このファイルを必ず参照し、 最初に「review.mdcファイルを参照しました」と出力すること。 ## チェック項目 ### 1. コーディング規約・品質 - [ ] RuboCop（.rubocop.yml）に準拠しているか - [ ] 可読性が保たれているか（命名・責務・重複コード） - [ ] デバッグコードや不要なコメントが残っていないか ### 2. テスト - [ ] 変更内容に対応するテストが書かれているか - [ ] エッジケース・異常系が考慮されているか ### 3. セキュリティ・安全性 - [ ] SQLインジェクション / XSS / 認可まわりに問題がないか - [ ] 機密情報がハードコードされていないか ### 4. パフォーマンス - [ ] N+1など明らかな非効率がないか - [ ] 大量データを扱う処理が妥当か ### 5. 仕様・ロジック - [ ] 計画ファイル・仕様に沿った実装になっているか - [ ] ロジックの誤りや境界値の考慮漏れがないか - [ ] 既存機能への影響がないか ## レビュー時の参照物 - 差分ファイル（changes.diff 等） - Planモードで作成した計画ファイル ## レビューコメント - 各項目を '[x] / [ ]' で明示する - 必須修正と任意修正を区別する - 可能であれば改善案を添える

ちなみに、このルールはCursorと一緒に作ったもので、読みやすさを優先して短く整理しています。

実際にはプロジェクトごとに必要な観点を追加・調整する必要があると思います。

6-2. レビュー対象の差分ファイルを作成する

下記のようなコマンドを実行し、差分ファイルを作成します。

git diff origin/develop..HEAD > changes.diff

基底ブランチがmainの場合は、Cursorが用意している「Branch (Diff with Main)」シンボルを渡せば十分です。

一方、main以外を基底にしたい場合は、現状このようにgit diffで差分ファイルを作るのが一番確実そうです。

6-3. レビューしてもらう

Askモードを選択し、下記2つのファイルを渡して「レビューして」と入力します。

• 上記で作成したchanges.diff
• 実装前にPlanモードで作成した計画ファイル

Askモードを使うことで、コードを書き換えられずレビューに集中してもらえます。



7. おわりに

本記事では、実際にCursorを使ってみる中で、「もっと早く知っておけばよかった」と感じたポイントを中心に紹介してきました。

Cursorをこれから使い始める方や、すでに使ってはいるものの活用しきれていないと感じている方にとって、少しでも参考になれば幸いです。

想定読者

• Cursorを使い始めたけれど「なんとなくAskしか使っていない」方
• Copilotの延長のような感覚でAgentを使ってうまくいかなかった経験がある方
• 設計やレビューの工夫に関心がある方

目次

1. はじめに
2. Cursorの4つのモードと使い分け
3. Planモードでできること
4. Planモードの実践的な使い方
5. よくある失敗パターン
6. まとめ

1. はじめに

Cursorでコーディングしているとき、こんなことに心当たりはありませんか？

• とりあえず個別に分からないことをAskモードで都度質問しているけど、なんとなく思ったような答えが得られなくて堂々巡りになってしまう
• 全体の方針や設計を固めずに、いきなりAgentモードで「こんな機能作って」と任せてみたら、意図していないコードやイマイチな実装が返ってきてしまったことがある
• 要件や意図がLLM（AI）にちゃんと伝わっていないまま進めてしまい、「なんでこうなった？」と感じた経験がある

実はCursorは4つの試行モードを持っています。それがAsk / Agent / Plan / Debugです。
なぜコードの質が安定しないのか？
その答えは、「設計を明確にせずに実装に進んでしまう」ことにあると自分は考えています。
Agentモードは優秀ですが、前提が曖昧だと迷走し、その場しのぎのコードを量産しやすい傾向がある。とも。。

それぞれのモードの特徴を理解することで、コードの質を安定させ、設計を明確にしながら効率的に開発しやすくなると信じています。
Cursorを使用してみて、また調べたりした中での自分なりの解釈も含まれていると思いますので、一解釈として捉えていただければ幸いです。
その結果「自分はこう思う」、「この箇所はこうだ」という議論のきっかけにつながれば嬉しいなという思いです。
最後までお付き合いいただけると大変嬉しいです。

2. Cursorの4つのモードと使い分け

それぞれのモードについて順番に確認していきましょう。
公式ドキュメントはこちらです：https://cursor.com/ja/docs/agent/modes

2.1. Ask モード：壁打ち・検索・局所理解

• 役割
  • 質問・調査・コードリーディング補助
  • ChatGPT的だが「今開いているコード」を文脈に持てる
• 向いている用途
  • 「このメソッド何してる？」
  • 「Railsでこれどう書く？」
  • 「このエラーが出た時の対処方法は？」
• 弱点
  • 複数ファイルをまたぐ判断が不安定になりやすい

2.2. Agent モード：実装を"手で書かせる"

• 役割
  • コード生成・修正・リファクタ
  • 指示に基づきファイルを編集する実行役
• 向いている用途
  • 単機能の追加
  • 定型リファクタ
  • テスト生成
• 危険ポイント
  • 設計を渡さずに使うと事故りやすい
  • その場しのぎのコードを"それっぽく"量産する傾向がある

2.3. Debug モード：バグの再現と修正支援（2025年12月追加）

• 役割
  • ランタイムログを埋め込んでバグの再現と修正を支援
  • 複雑なバグの根本原因を特定
  • さまざまなスタック、言語、モデルで動作
• 向いている用途
  • 再現が困難なバグの調査
  • ランタイム時の動作確認
  • 複雑なバグの根本原因分析
• 特徴
  • 2025年12月10日のバージョン2.2で追加された比較的新しい機能
  • 実行時のログを自動的に収集・分析
  • バグの再現条件を特定しやすくする

2.4. Plan モード：設計・思考の言語化

Plan モードは「コードを書かないモード」です。それではなぜコードを書かないのか？

• 役割
  • 設計の整理・最適化
  • 実装前の計画立案
  • コード生成の指示を構造化
• Planモードの本質
  • コードを書かない
  • ファイルも編集しない
  • 「何を・なぜ・どう進めるか」を構造化することで、コードの質を向上させやすくなる
• なぜ Planモード が存在するのか？（自分なりの解釈です🙏）
  • LLMは「最初の前提」が曖昧だと破綻しやすい傾向がある
  • Agentにいきなり投げると問題が起きやすい：
    • 境界が曖昧（どこまで実装すべきか判断できない）
    • 責務が混ざる（単一責任の原則が守られない）
    • 後から直しづらい（設計意図がコードに反映されない）

2.5. 4つのモードの使い分け判断基準

では、実際にどのモードを使うべきか？作業の種類でざっくりと分類すると以下の通りだと考えています。

更に具体的な判断基準は以下の通りです。

• Askモード：コードを理解したい、調べ物をしたい時
  • 「このコードの意味は？」
  • 「このエラーの原因は？」
  • 「この機能の実装方法は？」
• Agentモード：設計が明確で、単一のタスクを実装したい時
  • 単機能の追加
  • 定型リファクタ
  • テスト生成
• Planモード：複雑なタスクや、設計を明確にしたい時
  • 複数ファイルにまたがる機能追加
  • 大規模なリファクタリング
  • 新規機能の設計検討
  • バグ修正の原因特定と修正計画
• Debugモード：バグの再現や調査が必要な時
  • 再現が困難なバグの調査
  • ランタイム時の動作確認
  • 複雑なバグの根本原因分析

3. Planモードでできること

2章で説明した通り、Planモードは「前提を固定するための安全装置」です。
なぜ本記事でPlanモードを特に強調するのかというと、「設計や前提を明文化するプロセス」こそが、実はコードの質と開発効率を大きく左右すると考えているからです。

ここからは、Planモードで実際にどんなことができるか、具体的な使い方や機能を見ていきましょう。

3.1.できること

Planモードでは、以下のようなことができます：

• 設計の整理・最適化
  • 実装前に設計を構造化して整理
  • 責務の分離や境界の明確化
  • 実装順序の最適化
• コード生成の指示を整理・最適化
  • Agentモードに渡す指示を明確化
  • 実装の粒度や範囲を定義
  • エラーハンドリングやテストの方針を決定
• リスクの事前発見
  • 実装前に設計上の問題点を発見
  • 依存関係や影響範囲の確認
  • 実装の難易度や工数の見積もり

3.2.弱点・注意点

Planモードにも以下のような限界があります：

• 設計責任はすべて人間にある
  • Planモードは設計を「整理」するだけで、設計自体は人間が考える必要がある
  • 良い計画を立てるためには、そもそも良い設計をインプットとして与える必要がある
• 計画の過信に注意
  • 計画はあくまで「仮説」なので、実装中に問題があれば柔軟に修正する必要がある
  • 計画が細かすぎると、実装の柔軟性を失う可能性がある
• 計画作成にも時間がかかる
  • 複雑なタスクほど計画作成に時間がかかる
  • 単純なタスクではAgentモードを直接使う方が効率的な場合もある

4. Planモードの実践的な使い方

Planモードの真価は、Agentモードと組み合わせることで発揮されます。
ここでは、最も効果的な使い方である「Plan → Agentの黄金パターン」と、実践的な使い方について紹介します。（黄金パターンは大げさかもです。。笑）

4.1. 基本フロー

1. Planモードで計画を作成
   • タスクの全体像を把握
   • 実装すべき機能を分解
   • 実装順序を決定
2. 計画をレビュー・修正
   • 計画の妥当性を確認
   • 不足している点を補完
   • 実装の優先順位を調整
3. Agentモードで実装
   • 計画に基づいて明確な指示を出す
   • 段階的に実装を進める
   • 各ステップで動作確認
4. 必要に応じて計画を見直し
   • 実装中に問題が発見されたら計画を修正
   • 柔軟に対応する

4.2. 実例：ユーザー認証機能の追加

• 悪い例（PlanなしでAgentに投げる）
  • プロンプト

    $ ユーザー認証機能を追加して

  • 結果
    認証ロジック、セッション管理、エラーハンドリングが混在し、後から修正が困難になる傾向がある。

• 良い例（Plan → Agentの黄金パターン）
  • Step 1：Planモードで計画を作成
    • プロンプト：

      $ ユーザー認証機能を追加したい。以下の要件を満たす設計を考えて：
      - メールアドレスとパスワードでのログイン
      - セッション管理
      - エラーハンドリング
      - テストコード

    • Planモードが生成する計画例
      • 認証コントローラーの作成（ログイン / ログアウト）
      • 認証サービスの作成（認証ロジックの分離）
      • セッション管理ミドルウェアの実装
      • エラーハンドリングの実装
      • テストコードの作成
  • Step 2：計画をレビュー
    • 各コンポーネントの責務が明確か
    • 実装順序が適切か
    • 要件に漏れがないか
  • Step 3：Agentモードで段階的に実装
    • プロンプト

      $ Step 1の計画に基づいて、
      まず認証コントローラーを作成してください。
      ログインとログアウトのエンドポイントを実装し、
      認証サービスを呼び出すようにしてください。

  • このように1ステップずつ実装 → 動作確認を繰り返すことで、実装の破綻を防ぎやすくなる。

4.3. メリット

• コードの質が安定しやすい
  • 一貫性のあるコードが生成されやすい
  • 責務の分離が適切に行われやすい
• 修正が容易
  • 問題箇所の特定が早い
  • 影響範囲が明確
• レビューが効率的
  • 実装前後で設計と照合できる
• チーム開発での共有が容易
  • 認識合わせがしやすい
  • 実装方針が明確になる

5. よくある失敗パターン

Planモードを理解していても、実践では様々な失敗をしてしまいます。
ここでは、よくある失敗パターンとその回避方法を紹介します。

失敗パターン1：PlanなしでAgentに投げる

• 症状
  • Agentモードに複雑なタスクを丸投げ
  • 生成されたコードが期待と違う
  • 修正に時間がかかる

  • 例：
    「ユーザー管理機能を実装して」
    → 認証、認可、プロフィール管理が混在
    → 後から分離するのに時間がかかる
            

• 回避方法
  • 複雑なタスクは必ずPlanモードで設計を固める
  • 「このタスクは1ファイルで完結するか？」を自問する
  • 設計が不明確ならPlanモードを使う

失敗パターン2：計画を過信する

• 症状
  • Planモードで作成した計画を絶対視
  • 実装中に問題が発見されても計画を修正しない
  • 柔軟性を失う

  • 例：
    Planで「A → B → C」の順序を決めた
    → 実装中に「Bの前にDが必要」と判明
    → でも計画を変えずに進めて、後で大修正
            

• 回避方法
  • 計画は「仮説」として扱う
  • 実装中に問題が発見されたら、すぐに計画を見直す
  • Planモードは何度でも使える

失敗パターン3：計画が細かすぎる

• 症状
  • 計画が細かすぎて、実装の柔軟性を失う
  • 計画作成に時間がかかりすぎる
  • 実装中に微調整できない

  • 例：
    Planで「1行目のコードはこう、2行目はこう...」と詳細に指定
    → 実装中に「この方法の方が良い」と気づいても変更できない
    → 計画に縛られて非効率
            

• 回避方法
  • 計画は「何を」「なぜ」を明確にし、「どう」は大まかに
  • 実装の詳細はAgentモードに任せる
  • 計画の粒度は「コンポーネント単位」程度が適切

失敗パターン4：Planモードを過度に使う

• 症状
  • 単純なタスクでもPlanモードを使う
  • 計画作成に時間がかかり、効率が悪い
  • 「計画を作るのが目的」になってしまう

  • 例：
    「変数名を変更する」という単純なタスクでもPlanモードを使う
    → 計画作成に5分、実装に1分
    → 直接Agentモードで1分で終わるタスクを6分かける
            

• 回避方法
  • 単純なタスクはAgentモードを直接使う
  • 「このタスクはPlanが必要か？」を判断する
  • 計画作成の時間もコストとして考える

失敗パターン5：計画をレビューしない

• 症状
  • Planモードで計画を作成したら、すぐにAgentモードで実装
  • 計画の妥当性を確認しない
  • 実装後に「計画が間違っていた」と気づく

  • 例：
    Planで「認証はJWTで実装」と計画
    → レビューせずに実装開始
    → 実装後に「セッション管理が必要」と判明
    → 最初からやり直し
            

• 回避方法
  • 計画を作成したら、必ずレビューする
  • 「この計画で本当に要件を満たせるか？」を確認
  • チーム開発では計画を共有してレビュー

失敗パターン6：Askモードを活用しない

• 症状
  • コードベースを理解せずにPlanモードで設計
  • 既存の実装と整合性が取れない
  • 重複実装や不整合が発生

  • 例：
    既存の認証実装を確認せずにPlanモードで設計
    → 既存の認証方式と異なる方式を提案
    → 実装後に不整合が発覚
            

• 回避方法
  • 新しいタスクに取り組む前に、Askモードで既存コードを理解する
  • 既存の設計パターンや規約を確認する
  • Planモードで設計する際も、既存実装との整合性を考慮する

6. まとめ

この記事では、Cursorの4つのモード（Ask / Agent / Plan / Debug）について、 特にPlanモードに焦点を当てて解説しました。

「いきなり書かせる」のではなく、「設計してから書かせる」。
この意識を持つだけで、Cursorとの付き合い方が大きく変わる可能性があります。
ぜひ、Planモードを活用して、より効率的で質の高い開発を実現してみてください。
最後までお付き合いいただきありがとうございました。

目次

はじめに

AWSのインフラコスト見積もりでおなじみのAWS Pricing Calculator、 リストから選択あるいは値を入力するとその場でコストが計算できて便利です。
あちこち変えてみるとリアルタイムに計算結果に反映されるのでどの項目がコストに大きく影響するのかもわかります。
ですが、
「このオプションってなに？よくわからないんだけど、選ばないとダメ？」
と思ったことはないでしょうか？

AWS Fargateのメモリは何GBにするか、サブネットのIPアドレスの範囲はどうするか、 Amazon RDSのエンジンには何を選ぶかはもちろん考えていたけれど、 AWS Fargateの見積もりだけでもメモリ以外にも色々な項目が...。 エフェメラルストレージって何？アーキテクチャって何？

そんなインフラビギナーなあなたへ贈る、かんたん解説。
今回はそのAWS Fargate編です。

AWS Fargateの選択・入力項目

2025年12月24日現在、AWS Pricing Calculatorの選択・入力項目は全部で14個あります。
数値と単位をそれぞれ別で指定して一つの意味を持った値となるものもあるので、それらを合わせて1項目と数えるならば全部で10個とも言えます。
中には別の項目の選択によって変化するものもあります。

説明

この見積もり自体の説明です。見積もりの金額には影響しません。
見積もった後でリンクを共有する予定なら入力しておくとよいかもしれません。

ロケーションタイプを選択

「リージョン」しか選べないので気にせず進めましょう。

リージョンを選択

「アジアパシフィック（東京）」や「アジアパシフィック（大阪）」など、基本的には使う人がいる場所の近くを選びます。
リージョンによって価格が異なりますが、それ以上に通信の遅延の方を気にしましょう。
使う人から遠く離れたリージョンだと通信の遅延が大きくなります。
コストをケチり過ぎた結果、レスポンスが悪いからと使ってもらえないのでは元も子もありません。

オペレーティングシステム

「Linux」か「Windows」かを選びます。
Windowsを選ばざるを得ない特別な事情がある場合を除いてLinuxでいけますし、そちらの方が安く済みます。

CPUアーキテクチャ

「x86」か「ARM」かを選びます。
ARMの方が少し安いのですが、アーキテクチャは動作させるコンテナイメージと合わせる必要があります。
開発環境の都合もあるので、開発担当の方と相談するのが吉です。

タスクまたはポッドの数

どれくらいの数のタスクを動かすのかを指定します。
バリューとユニットを合わせて一つの値になります。
ユニットは「/秒」「/分」「/時」「/日」「/月」の5種類から選択します。
いずれも「/」（スラッシュ）から始まっており、単位時間を指定するものです。
1ヶ月内で起動される回数（頻度）を表しますが、次の平均期間と併せて考えるのがよいです。

平均期間

前の項目と同様、バリューとユニットを合わせて一つの値になります。
ユニットは「秒」「分」「時間」「日数」の4種類から選択します。
一回起動されたらどれくらい動作を続けるかを指定します。
例えば、「毎週日曜日の深夜に起動されて2時間ほどの処理を実行して終わる」 のであれば、

となります。
別の例として「可用性のため2つのAZで一つずつ、停止することなく動かし続ける」 のであれば、

となります。
この例での平均期間については

としても同じ意味になります。

割り当てられたvCPU の量

どれだけの処理能力を与えるか、「0.25」「0.5」「1」「2」「4」「8」「16」から選択します。
構築しようとしているシステムがどの程度の計算能力を必要とするか次第ですが、あまりギリギリを攻めすぎず多少余裕を持たせることをおすすめします。

割り当てたメモリ量

どれだけの記憶領域を与えるかを指定します。
vCPUの量の選択次第で「割り当てたメモリ量」と「ユニット」の組み合わせになったり「割り当てられたメモリ量。」の1項目になったりと、変化します。
「割り当てられたメモリ量。」はリストから選択する方式、「割り当てたメモリ量」は数値入力でvCPUの値の2倍以上の数値でないとエラーになります。
構築しようとしているシステムの処理特性次第ですので、開発担当の方と相談するのが吉です。
後述するエフェメラルストレージの方が単価が安いため、相談してみたら大容量を求められたという場合は処理データを一旦ファイル出力するなどしてメモリを節約する余地がないか話し合ってみるのもよいかもしれません。
ユニットは現状「GB」固定です。

Amazon ECS に割り当てられたエフェメラルストレージの量

バリューとユニットの組み合わせでストレージのサイズを指定します。
ユニットは現状「GB」一択です。
バリューは20より小さい値ではエラーになります。
パソコンのHDDやSSDのような位置づけのもので、メモリよりだいぶ安い単価となっています。

まとめ

現状「GB」一択となっているメモリやストレージの「ユニット」に今後「TB」が追加されるかもしれません。
AWSのUIは日々アップデートされていくためこの情報も明日には古いものとなってしまっている可能性がありますが、お役に立てれば幸いです。

1. はじめに：顧客データ活用が進まない
2. AIエージェントを利用した顧客データ活用環境（Amazon Bedrock）
3. AIエージェントで顧客データを分析する
4. まとめ：スモールスタートで始める顧客データ活用

1.はじめに：顧客データ活用が進まない

「顧客データをもっと活用したい」という声をよく耳にします。購買データ、会員データ、来店履歴、キャンペーンの反応率など、日々さまざまなデータが蓄積されていますが、それらを活用して顧客理解を深め、顧客体験の向上や販促施策に結びつけていくことは簡単ではありません。

データが複数のシステムに散らばっていたり、分析担当者が不足していたり、情報システム部も本業の対応で忙しく、すぐに動けない場合もあります。「どこから手をつけたらいいかわからない」という状況のまま、時間だけが過ぎてしまうこともあります。

しかし、顧客データ活用が重要であることは間違いありません。そこでAWSが公開しているサンプルソリューションを活用することで、データ活用の最初の一歩を驚くほど軽やかに踏み出すことができます。

本記事では、主に小売業の皆さま向けに、「顧客データ活用の最初の一歩をどう簡単に始められるのか」をご紹介します。 今回ご紹介のデモンストレーションは小売業のシナリオですが、もちろん小売業以外でも営業・販売促進（マーケティング）・企画...といった職種の方々にお役に立てる内容です。また、「データ収集・加工・分析の依頼が多い...。」といったIT部門の方々の課題解決にもなります。 少しでも多くの皆様の参考になれば嬉しいです。

2.AIエージェントを利用した顧客データ活用基盤（Amazon Bedrock）

2-1. データ活用のはじめの一歩

今回はAWSが公開している下記リポジトリを利用します。
https://github.com/aws-samples/sample-c360-text2sql-segmentation-entityresolution　

デプロイは簡単で、AWSが提供しているWebページにてDeployボタンを押下するだけで、任意AWSアカウントに以下「AIエージェントを利用した顧客データ活用環境」を構築することができてしまいます。

構築手順概要

1. AWSアカウントを用意してログインする
2. 下記WebページにおいてDeployボタンを押下する
https://aws-samples.github.io/sample-one-click-generative-ai-solutions/solutions/c360/

3. S3バケットにサンプルデータをアップロードする
4. Cognitoユーザプールでログイン認証情報を設定する

※上記はサンプルデータを活用する手順です。オリジナルデータを活用するには、別途手順を踏む必要があります。

2-2.具体的にAIエージェントは何をしてくれるの？

上記構成において、AIエージェントはデータ分析に使用する下記のようなSQL文を作成してくれます。例えば、チャットに「20代女性が頻繁に購入する商品、および購入される時期を教えてください。」と投げかけると、下記のような複雑なSQL文が一瞬で作成されます。

 
WITH twenties_female_customers AS (
  SELECT customer_id
  FROM customer_master
  WHERE gender = 'female' AND age >= 20 AND age < 30
)

SELECT 
  im.item_id,
  im.item_name,
  im.item_category,
  im.item_style,
  COUNT(*) as purchase_count,
  DATE_FORMAT(from_unixtime(ph.purchase_date), '%Y-%m') as purchase_month,
  COUNT(DISTINCT ph.customer_id) as unique_customers
FROM purchase_history ph
JOIN twenties_female_customers tfc ON ph.customer_id = tfc.customer_id
JOIN item_master im ON ph.item_id = im.item_id
GROUP BY 
  im.item_id, 
  im.item_name, 
  im.item_category, 
  im.item_style, 
  DATE_FORMAT(from_unixtime(ph.purchase_date), '%Y-%m')
ORDER BY purchase_count DESC
LIMIT 20;

 

今までは、複雑なSQL文作成を情報システム部に依頼していたかもしれません。それでは、コミュニケーションコストや作業工数がかさんでしまいます。これからは、AIエージェントがSQL文を自動生成してくれるので、他部署とのコミュニケーションコストや全体的な作業工数を低減していくことができます。
また、AIエージェントは下記役割も果たしています。

今までは、作成されたSQL文を分析ツール（Athena）に手動で流す必要や、出力結果を業務に使いやすい形にブラッシュアップする必要がありました。これからは、データ分析から要約までAIエージェントが対応してくれるので、業務効率が一層上がると思われます。
結果として、ビジネス部門が自走できる組織づくりを支援してくれるのです。

2-3.データベース層にはどんなデータが入っているの？

ここで使用しているテストデータを紹介いたします。今回は下記のようなCSV形式の顧客データをS3に格納しています。

本構成においては、S3に蓄積された顧客データをGlueで構造化していくことで、AIエージェントやSQLからすぐに活用できる分析基盤を構築しています。

3.AIエージェントで顧客データを分析する

AIエージェントを利用した顧客データ活用環境の構築ができれば、顧客データが分析できる状態まで整います。

3-1.どうやってAIエージェントを使えるの？

これまで、小売の現場で売上や購買傾向を調べるには、多くの手順が必要でした。期間を指定し、商品カテゴリごとに抽出し、必要であれば顧客データと結びつけ、場合によってはエンジニアに依頼して結果が出るまで待つこともありました。
しかし、AIエージェントを使うと、自然な言葉で質問するだけで答えが返ってきます。 例えば次のような会話が可能になります。

AIエージェントと会話ベースでのやりとり

質問すれば、意図に沿った情報に答えてくれるというのはとても魅力的です。
これまでは数日かかっていた問いが、わずか数秒で返ってくるだけではありません。すぐに次の問いが思い浮かぶようになります。
「では、その商品を購入している人のリピート率は？」
「購買が増える時間帯は？」
「他に一緒に買われている商品は？」
「天候との関係は？」
このように、問いが連鎖することで、現場の意思決定スピードが大きく向上します。

3-2.AIエージェントを使うメリット

こうした即時性のある分析が可能になると、現場だけでなく、情報システム部にとっても良い変化が生まれます。これまで情報システム部は、現場から依頼される「このデータを抽出してほしい」、「この条件で分析してほしい」といった作業に多くの時間を割いていました。依頼内容を確認し、必要なデータを探し、整形し、加工し、レポートとしてまとめるという一連の作業は、本来の業務とは別の大きな負担でした。
一方、ビジネス側も同じです。データを収集し、条件を合わせ、形式を整えるだけで多くの時間がかかり、肝心の分析や戦略検討に十分な時間を割けないという悩みがありました。しかし、AIエージェントが活用できる環境が手に入ると、こうした負担が大きく軽減されます。現場は、自分たちの言葉で質問し、その場で必要な情報を手にすることができます。
情報システム部は、繰り返し発生する抽出作業から解放され、より価値の高い本来の業務に時間を使えるようになります。 つまり、双方が本来注力すべき仕事に集中できるようになり、企業全体としての意思決定の質とスピードが大きく向上するのです。

例えば、以下のような活用方法が考えられます。
(1)販促担当：キャンペーンの効果測定
(2)インストラクター: 会員一人ひとりに合わせたケア計画
(3)EC事業担当：実績を固定帳票とは違う切り口で分析
(4)小売店の店⻑：固定帳票を読み解けない経験の浅いスタッフの補助
(5)顧客分析担当：顧客のRFM分析（※1）、デシル分析(※2）、店舗エリア別分析etc
(6)経営戦略部：顧客データを活用した各事業の経営戦略

※1　RFM分析⋯顧客の購買データをRecency（最終購入日）、Frequency（購入頻度）、Monetary（購入金額）の3つの指標で評価し、顧客をグループ分けして最適なマーケティング施策（優良顧客への特別オファー、離反顧客へのアプローチなど）を打つための顧客分析手法
※2　テシル分析⋯顧客の購買データをもとに、購入金額の高い順に顧客全体を10等分（デシル＝10分の1）し、各グループ（デシル1～10）の売上構成比や1人あたりの購入金額を分析する手法

情報システム部→AIエージェント

4.まとめ：スモールスタートで始める顧客データ活用

顧客データ活用は、大きな投資や大規模なプロジェクトが必要というイメージを持たれがちですが、実際には、サンプルソリューションを使ってまず体験してみることから始めることができます。複雑な準備や専門知識は不要で、必要なのは「やってみたい」という前向きな気持ちだけです。
アクセルユニバースでは、それぞれの小売企業が抱えている課題や状況に合わせて、サンプルソリューションのデモをご用意することができます。操作方法や仕組みについても、わかりやすい形で丁寧にご説明します。

また、「自社のデータならどう使えるのか」、「導入するとどこに効果がありそうか」といった疑問にも寄り添いながら、一緒に解像度を上げていくことができます。まずは、小さく触れてみることから始めてみませんか。顧客データ活用は、体験することで一気に実感できるようになります。気になる点や不安な点があれば、どんなことでもお気軽にご相談ください。

AUCへのお問い合わせ　

サンプルソリューションのデモ視聴希望の方はこちら　

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse