プロダクト開発やサービスデザインにおいて、ユーザーの体験を時系列で可視化する「カスタマージャーニーマップ」。ユーザー理解を深め、チームの目線を合わせるための強力なツールですが、作成する中で以下のような壁にぶつかったことはありませんか？ ユーザーの行動は並べられたけれど、その裏にある『真の感情』や『潜在的な課題（インサイト）』まで踏み込めていない気がする チーム内だけでブレインストーミングをしても、ありきたりな課題や、自分たちの都合の良い解釈ばかりが出てきてしまう こうした膠着状態を、ChatGPT、Gemini、ClaudeなどのAIチャットが助けてくれるかもしれません。 今回は、チャットボットを「壁打ち相手」として活用し、カスタマージャーニーマップのインサイトを深掘りするための具体的なステップと、プロンプトの例をご紹介します。 AIチャットでの壁打ち：インサイトを深掘りする4つのステップ それでは、実際にAIチャットを使ってジャーニーマップをブラッシュアップしていくプロセスを見ていきましょう。 ステップ1：ペルソナと前提条件の「同期」 AIチャットに壁打ちを依頼する前に、まずはリサーチデータやペルソナの情報をインプットします。ここでの情報の具体性が、その後のアウトプットの質を左右します。 【入力プロンプト例】 「あなたの一流のUXリサーチャーとして、私のカスタマージャーニーマップ作成の壁打ち相手になってください。 まずは前提となるペルソナとプロダクトの情報を共有します。内容を理解したら、質問をせずに「前提を理解しました。いつでもディスカッションを始められます」とだけ返答してください。 ■ プロダクト：20代〜30代向けの、資産運用を自動化するスマホアプリ ■ ペルソナ：都内在住の会社員（28歳）、将来への漠然とした不安はあるが、投資の知識はなく『損をするのが怖い』と感じている。平日は仕事が忙しく、スマホを触るのは通勤中と就寝前のみ。」 ステップ2：行動の理由を分析させる 前提を同期したら、ジャーニーマップの特定のフェーズを切り出してAIチャットにぶつけます。ユーザーが特定の行動をとった時の「言語化されていない動機」を掘り下げます。 【入力プロンプト例】 「ペルソナが『アプリをダウンロードしたものの、初期設定（銀行口座の連携）の画面で離脱した』というフェーズについて考えます。 単に『面倒くさいから』という理由以外で、この時ペルソナの脳内で起きている心理的な葛藤や不安、あるいは『私には関係ないかも』と感じてしまうような感情を、認知心理学やUXの観点から5つ洗い出してください。」 AIチャットは、「セキュリティへの不安」「今すぐやらなければいけない強制感への反発」「投資金額の決定に対するコミットメントへの恐怖」など、行動の裏に潜む心理的背景を論理的に言語化してくれます。 ステップ3：ペルソナになりきってもらい「不満」を吐き出させる 次に、AIチャットにペルソナそのものになってもらい、インタビュー形式で壁打ちを行います。客観的な分析ではなく、「主観的な感情」を引き出すアプローチです。 【入力プロンプト例】 「これからは、先ほど共有したペルソナ（28歳会社員）になりきって回答してください。私はインタビュアーです。 「ねぇ、アプリを開いて最初の画面を見たとき、ぶっちゃけどう思った？何が一番モヤモヤした？』」 AIがペルソナを演じることで、「専門用語が多くて、自分が場違いなところにいる気がした」「いきなりお金の話をされて、心の準備が追いつかなかった」といった、人間のチームだけでは見落としがちな生々しい感情のインサイトが浮き彫りになるかと思います。 ステップ4：「悪いシナリオ」と「理想のシナリオ」のギャップを埋める 最後に、ジャーニーマップにおける「悪い体験」をどうやって「良い体験」に変えられるか、具体的な改善アイデアの種を蒔きます。 【入力プロンプト例】 「ペルソナが最も不安に感じる『口座連携』のステップにおいて、他業界（例えばエンタメ、SNS、ゲームなど）で使われている『ユーザーの心理的ハードルを下げるオンボーディングの手法』を参考に、このアプリに転用できるアイデアを3つ提案してください。」 AIチャットと壁打ちする際の3つの注意点 AIチャットは優秀なパートナーですが、過信は禁物です。 実際のユーザーインタビュー（一次情報）を最優先にする AIチャットが出してくれるインサイトは、あくまで「理論上、そうなる可能性が高い仮説」です。AIとの壁打ちで得られたインサイトは、実際のユーザーテストやインタビューデータと照らし合わせて検証してください。 ハルシネーション（誤情報）を前提に、根拠を問う AIチャットがそれらしい回答をしたときは、「なぜそう思うの？その根拠となるペルソナの行動特性はどこにある？」と追加で質問（深掘り）してください。これにより、AIの適当な思いつきを排除し、筋の通ったインサイトを抽出できます。 機密情報の入力には配慮する AIチャットは入力された情報を学習していくことを前提で利用しましょう。未発表のプロダクト名や、個人情報を入力しないようにしたり、学習させない設定や、Google Workspace上のGeminiを利用するなど、対策をしてください。 まとめ：AIとの協働で可能性を拡げる カスタマージャーニーマップの作成において、AIチャットを壁打ち相手にすると、「チームの視野を広げること」ができるでしょう。 一人で、あるいはチームだけで悩んでジャーニーマップが「綺麗だけど浅いもの」になってしまいそうなときは、AIチャットに「ちょっとこのユーザーの気持ちを想像して」と話しかけてみてください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 生成AIを「壁打ち相手」にしてカスタマージャーニーマップのインサイトを掘り下げてみる first appeared on SIOS Tech Lab .

こんにちは！DevRelの重田（ @Shige0096 ）です。 メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 7/13(月)〜8/21(金)まで毎日異なるメンバーが技術やエンジニアリング、個人開発など幅広いテーマでテックブログを公開していきます！ 本記事にて毎日ブログを追記更新していくので、ぜひお楽しみください✨ ※土日祝を除く 👇よろしければ昨年の記事もぜひチェックしてみてください！ MEDLEY Summer Tech Blog Relay | MEDLEY Developer Portal こんにちは！メドレーでDevRelをしている重田です。 今年も暑い日が続いていますがいかがお過ごしですか？ メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 8/2... developer.medley.jp 🌻 ブログリレーカレンダー 🗓️第1週(7/13~7/17) Day1：（仮）🍄（玉井） Day2：Fivetranについて（本多） Day3：TBD（森川） Day4：BigQueryのコスト削減周り（林田） Day5：TBD（宋） 🗓️第2週(7/21~7/24) Day6：FY25 CLINICS大規模障害対応で認証基盤の刷新をした時に得た学びについて（山田） Day7：ローカルLLMの個人での活用について（斎藤） Day8：自作ハーネスとローカルLLMをゴリゴリ（福島） Day9：TBD（稲村） 🗓️第3週(7/27~7/31) Day10：Rubyで組み込み・ゲーム・AIのどれか！（藤原） Day11：TBD（平林） Day12：TBD（高橋） Day13：(仮) AI API 叩くとき考えること（山下） Day14：Jetson Orin Nano Super によるローカルMLLM活用について（山本） 🗓️第4週(8/3~8/7) Day15：Maestro E2E（菅原） Day16：TBD（奥澤） Day17：TBD（佐藤） Day18：TBD（牧） Day19：TBD（久保） 🗓️第5週(8/10~8/14) Day20：TBD（柏木） Day21：TBD（山本） Day22：TBD（村上） Day23：TBD（竹本） 🗓️第6週(8/17~8/21) Day24：TBD（山河） Day25：TBD（亀澤） Day26：TBD（清水） Day27：メドレーにおける0→1開発のリアルな話（エージェント業務システム）（德永） Day28：TBD（倉林） 🍉 We’re hiring! メドレーでは、「医療ヘルスケアの未来をつくる」仲間を大募集しています！ 少しでも興味をお持ちいただけましたら、ぜひ、カジュアル面談にお越しください🙌 ご応募お待ちしております！！ メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp

オンプレミスの HPC 環境からの移行を進める研究チームは、クラウドへのデプロイの複雑さに悩まされることがよくあります。従来のアプローチでは、AWS のネットワーク、ストレージアーキテクチャ、Slurm の構成管理に関する深い専門知識が必要でした。一般的な手動デプロイでは、インフラのプロビジョニング、ネットワークトポロジの設計、スケジューラの構成、パフォーマンスチューニングに数週間を要します。プラットフォームエンジニアリングのリソースが限られている研究チームは、計算能力に対する差し迫ったニーズと、デプロイの技術的な障壁との間で板挟みになってしまいます。 本記事では、業界のベストプラクティスを組み込んだ AWS PCS クラスターを、Kiro CLI を使って自動的にデプロイ・構成する方法をご紹介します。インフラのプロビジョニング、モニタリングのセットアップ、コスト最適化を担いながら、研究チームが特定のワークロードに必要とする柔軟性を維持する「カスタムエージェント」の作成手順を順を追って解説します。 クラウドにおける HPC クラウドベースの HPC は、柔軟なコンピューティングアクセス、幅広いリソースの可用性、そして価値あるインフラの抽象化により、標準的な手法となっています。本記事では、AWS Parallel Computing Service (PCS) と Kiro CLI を活用して、このアプローチを実演します。 AWS PCS : AWS PCS は、自動構成・スケーリング・メンテナンスを備えたマネージドな Slurm スケジューラを提供することで、HPC のデプロイを簡素化します。本サービスはクラスターのライフサイクル管理を担う一方で、コンピューティングリソースとジョブスケジューリングポリシーに対するコントロールはお客様が維持できます。PCS は、共有ストレージ向けの Amazon Elastic File System やモニタリング向けの Amazon CloudWatch といった AWS サービスとネイティブに統合され、HPC のデプロイで通常必要となる統合作業を削減します。 Kiro CLI : Kiro CLI は、特定のユースケースに合わせた専門的なガイダンスを備えた カスタムエージェント を定義することで、非常に強力なものになります。ドメインの専門知識をエージェント定義に直接エンコードすることで、組織のベストプラクティスや要件を理解した専用の自動化を構築できます。例えば本記事では、HPC ワークロード向けの AWS Parallel Computing Service のベストプラクティス（最適なインスタンスの選択、ネットワーク構成、ストレージの最適化など）を組み込んだ PCS デプロイエージェントを作成します。このエージェントは確立されたデプロイパターンを活用することで、複雑なクラスターのプロビジョニングを効率化し、デプロイ時間と構成ミスのリスクの両方を削減します。汎用的な自動化とは異なり、このアプローチは実証済みの方法論を特定のインフラのニーズに適応させる、インテリジェントでコンテキストを理解した支援を提供します。 はじめに 自動化された PCS デプロイのアプローチを実装する前に、3 つの前提条件が必要です。 インストールガイド に従って Kiro CLI をインストールする pcs-kiro デモリポジトリ からデモコードをダウンロードする ローカルの AWS 認証情報があることを確認する。 aws sts get-caller-identity を実行して確認できます （オプション） MCP 構成ガイド に従って AWS Knowledge MCP Server を構成する エージェントを使う まず、エージェントを初期化します。Kiro で TODO リスト設定を有効にしておくとよいでしょう。これによりエージェントのより詳細なプランニングが可能になり、クラスターの作成を進める際にタスクのリストを作成し、ステップごとに処理を進めるようになります。 kiro settings chat.enableTodoList true 対話型の PCS デプロイエージェントを起動します。 kiro chat --agent pcs-interactive-agent ディスカバリーフェーズ ここで、エージェントにクラスターの作成を手伝ってもらいます。 User: I am new to PCS. Help me create my first cluster with best practices. （訳: PCS は初めてです。ベストプラクティスに沿って最初のクラスターを作成するのを手伝ってください。） エージェントはまずアクティブな AWS 認証情報を確認し、詳細が不明な場合はいくつかのディスカバリーのための質問を返します。また、既存の環境を調査し、ベストプラクティスに基づいた推奨事項を提示します。これは、既存の VPC やその他の AWS リソースをエージェントに使ってもらいたい場合に役立ちます。 ここで詳細を調整・指定でき、エージェントは最終的なサマリーを作成して、お客様の AWS アカウント内でインフラの作成を開始します。 インフラの作成 以下はインフラ作成プロセスの抜粋です。環境や要件によって、この出力は変わる可能性があります。 Agent: VPC Created:vpc-█████████████████ (10.3.0.0/16) - Public Subnet:subnet-████████████ (10.3.0.0/20) - ログインノード用 - Private Subnet:subnet-████████████ (10.3.32.0/20) - コンピュートノード用 - Internet Gateway:igw-████████████ - NAT Gateway:nat-████████████ (52.38.92.80) - Route Tables:Public (rtb-████████████), Private (rtb-01484185571aabba1) Security Groups Created: - Cluster SG:sg-████████████ (Slurm ポート 6817-6818) - SSH SG:sg-████████████ (SSH ポート 22) IAM Role Created:AWSPCS-scientific-cluster-role - Instance Profile:AWSPCS-scientific-cluster - Policies:AmazonSSMManagedInstanceCore + PCS registration Cluster Created:pcs_xfzpdypb7z (scientific-cluster) - Status:CREATING → エンドポイント取得中 - Size:SMALL (最大 100 ノード、1000 ジョブ) - Slurm Version:24.11 - Controller Endpoint:10.3.45.99:6817 Launch Templates Created: - Compute:lt-████████████ (c6i.xlarge) - Login:lt-████████████ (c6i.xlarge + SSH key) Compute Node Groups Created: - Login Group:pcs_ndgfaikhwl (パブリックサブネット内に 1 台の c6i.xlarge) - Compute Group:pcs_████████████ (プライベートサブネット内に 0〜10 台の c6i.xlarge) - AMI Used:ami-████████████ (Slurm 24.11) - Status:CREATING (3〜5 分かかります) Queue Created:pcs_bogst8bszr (scientific) - Status:CREATING → ACTIVE - Targets:コンピュートノードグループ (pcs_dficwpzin2) - Purpose:科学計算ワークロード インフラの作成が完了すると、エージェントは詳細を提示します。AWS リソースのデプロイが失敗する場合もあります。エージェントに与えられた指示には、そうした問題のトラブルシューティングを行い、処理を続行する前に修正するように記載されています。また、エージェントは /generated ディレクトリにクラスターのサマリーとドキュメントを作成し、何がどのように構築・構成されたかを正確に示します。 完了すると、エージェントはクラスターへの接続方法とテスト方法を示し、コストの見積もりも提示します。 このわずかなやり取りの中で、完全に機能するネットワーク、コントローラー、キュー、コンピュートノードとログインノード、適切なテンプレートとロールを備えた、相応に複雑なアーキテクチャを作成しました。これらすべてを、一般的なニーズとユースケースを定義するだけで実現できたのです。 図 1: Virtual Private Cloud (VPC) 内での AWS Parallel Computing Service (PCS) クラスターのデプロイを示すアーキテクチャ図。 この図では、VPC の外側に配置された PCS コントローラーが PCS キューに接続されています。VPC の内側には 2 つのサブネットがあります。パブリックサブネットには、静的な起動テンプレートを使用する 1 台の c6i.xlarge インスタンスを含むログインノードグループがあり、プライベートサブネットには、動的な起動テンプレートを使用する c6i.xlarge インスタンス（0〜10 台のキャパシティ）を含むコンピュートノードグループがあります。両方のノードグループにはロールの割り当てが含まれ、コンピュートインスタンスや起動テンプレートのシンボルなどの AWS サービスアイコンで表現されています。 これらすべてのプロセスは、ユーザーとのいくつかのやり取りを含めて約 30 分で完了し、すぐにログインしてジョブの実行を開始できます。このアーキテクチャは、共有ストレージや追加のコンピュートノードグループ・キューなどを含むように拡張できます。 推奨されるベストプラクティス エージェントへの指示は、直接的・具体的・明示的に行う 例えば、本記事のアーキテクチャではファイルシステムを要求しませんでしたが、FSx for Lustre 分散ファイルシステムのセットアップを併せて依頼することも簡単にできる可能性があります デプロイをモニタリングし、混乱しているようであればコマンドをキャンセルする 時折の失敗は許容する — エージェントは回復する傾向があります 特定のユースケースに合わせてエージェントの構成をカスタマイズする ワークロードのコンテキストと要件を包括的に提供する 既知の制限事項 エージェントは詳細を見失うことがある — 必要に応じて指示を再度伝えてください 手動での検証が必要 — 結果が要件に合致しているか確認してください まとめ AWS Parallel Computing Service (PCS) は、Slurm クラスターを大規模に運用する際の運用の複雑さを取り除く、フルマネージドな HPC サービスを研究チームに提供します。Kiro CLI のマルチエージェントアーキテクチャと組み合わせることで、チームは本番環境対応の HPC 環境を数週間ではなく数時間でデプロイできるようになります。このアプローチは、基盤となるインフラの管理にかかるオーバーヘッドなしに計算能力を必要とする研究組織にとって、特に価値があります。 それでは、よい構築を！（Happy Building!） 著者について Markus Adhiwiyogo Markus Adhiwiyogo は、Amazon EC2 インスタンスを担当するシニアプロダクトマーケティングマネージャーであり、AWS Graviton、AWS Inferentia、AWS Trainium を含む AWS カスタムシリコンに注力しています。 Kyle Bush Kyle Bush は、AWS のヘルスケア・ライフサイエンスチームでグローバルなヘルスケア ISV を支援するシニアソリューションアーキテクトです。Kyle は、お客様が最新のテクノロジーを活用してデジタルトランスフォーメーションを推進し、ヘルスケアの提供と成果を近代化できるよう支援することに情熱を注いでいます。 Charunethran Panchalam Govindarajan Charunethran Panchalam Govindarajan は、AWS のシニアプロダクトマーケティングマネージャーであり、ハイパフォーマンスコンピューティングと量子テクノロジーに注力しています。彼は幅広いテクノロジー領域で活躍してきましたが、特に R&D と製品開発の交差点に関心を持っています。Charunethran はスタンフォード大学で電気工学の修士号を取得しています。仕事以外では、スケッチや哲学的な会話を楽しんでいます。 Kareem Abdol-Hamid Kareem は、スタートアップ向けのシニアアクセラレーテッドコンピュートスペシャリストです。アクセラレーテッドコンピュートのスペシャリストとして、Kareem は生成 AI、ハイパフォーマンスコンピューティング、超大規模ワークロードに関する新たな課題に日々取り組んでいます。余暇にはピアノを演奏し、ビデオゲーム『ストリートファイター』で腕を競っています。 翻訳はソリューションアーキテクトの 山田航司 が担当しました。原文は こちら です。