顧客が本来受けるべきセルフサービス体験と、その作り方 Mateo Jackson は AnyCompany Internet で顧客体験 (CX) を統括しています。この 2 四半期、彼のチームは同じ光景を見続けてきました。顧客が状況を説明しても対応できないボットがいて、次のボットに同じ説明を繰り返し、最後は保留のまま待たされた末に、何も知らない担当者と一からやり直す。カスタマーエフォートスコアは悪化し、応対時間は伸び、そして二度目の問い合わせをした顧客は離脱していきます。 Mateo は理想の姿を分かっています。通信障害、請求への異議、機器の交換といったケースを AnyCompany がどう扱うべきか、その方針と応対スクリプト、エスカレーションのルールを何年もかけて書いてきました。ツールが追いついてくれれば世界水準のセルフサービスになると信じて投資してきたのです。ただ、その蓄積を会話型 AI の体験に落とし込む手段が、半年以上の開発プロジェクトを立ち上げる以外に存在しませんでした。 それが今月変わりました。障害対応の手順書はすでに文書化されていて、システム連携も整っていたため、Mateo は火曜日に最初のエージェンティックなセルフサービス体験を構築し、水曜日に数百件の模擬通話でテストし、木曜日には初版を本番稼働させました。彼が実現した体験を紹介します。 朝 6 時 40 分、嵐で町の北側の光ファイバーが切断されました。7 時 15 分には問い合わせが入り始めます。Sofía もその 1 人でした。応答した音声は彼女を名前で呼び、アカウント番号の下 4 桁を確認し、日頃の利用に感謝を伝えます。彼女の通りでは障害が確認済みで、作業員が現場に入っており、復旧見込みは 11 時 30 分です。音声は前夜から残っている別件の問い合わせにも自ら触れ、それがまだ未解決で今回とは別の案件であることを伝えます。さらに、モデムのランプが点灯しているのか点滅しているのかを尋ねます。それによって次の対応が変わるからです。クレジットが適用され、金額と適用条件が途切れずに読み上げられます。彼女のモデムは 3 世代前のものなので、交換の対象になります。通話を続けたまま、スマートフォンに通知が届きます。3 つのルーターの選択肢が並び、それぞれの横に月額料金が表示されます。彼女は真ん中を選びます。音声はその製品名を読み上げて確認し、当日出荷になると伝えます。3 月分の請求について異議を申し立てると、規定により担当者への転送が必要です。電話を取った担当者の画面には、通信障害の状況、クレジット、彼女が選んだルーター、3 月の請求の件がすべて表示されています。Sofía は同じ説明を一度も繰り返していません。最初から最後まで、3 分と少しでした。 この会話体験を構築したのは 2 人です。Nikki Wolf は AnyCompany の Amazon Connect Customer インスタンスの管理者で、システム連携、モデルと権限の設定、会話が動く基盤を担当しています。Mateo は Sofía が耳にする内容そのものを担当しています。どちらも相手の作業を待つ必要はありませんでした。 デモは簡単だ Sofía の通話のように聞こえるものをデモとして作るなら、半日で足ります。プロンプトをいくつか書き、ドキュメントサイトを参照させ、声を選べば、よくある質問にはそれらしく答えてくれます。しかし同時に、それは本番稼働することのないバージョンでもあります。 先ほどの通話をもう一度確認してみてください。重要だった判断のほぼすべては、モデルが決めるべきものではありませんでした。 Sofía には未解決の問い合わせがすでにあった。AI は 2 件目を新規に開始するのか、既存の 1 件を引き継ぐべきか。 彼女はクレジットの対象だったが、先月も受け取っている。それは認められるのか、認められるならいくらまでか。 彼女はまだ本人確認を済ませていなかった。確認前に AI はどこまで話してよいのか。 クレジットの適用条件は途中で区切らず全文を読み上げなければならない。AI が要約して伝えることは許されるのか。 彼女は開始 3 語で担当者を呼ぶよう頼むこともできた。AI はもう一度自力で対応を試みるべきか、即座に転送すべきか。 これらには AnyCompany としての正解があり、Mateo は何年もかけてその答えに辿り着きました。「モデルに任せる」が答えになるものは 1 つもありません。一方でモデルが担う部分、つまり Sofía の苛立ちを読み取ること、通話が切断されたことに彼女が言及したときにトーンを合わせること、4 つの異なるシステムを横断しながら自然な会話を保つことも、同じくらい重要です。しかもそれらは、厳密さと共存した状態で自然に感じられなければなりません。デモが省略するのはまさにこの部分であり、会話型 AI のプロジェクトが止まるのは技術的な理由よりも構造的な理由によります。会話は 1 つのシステムに、業務ルールは別のシステムに、実行結果はさらに別のシステムにあり、実行経路の全体を 1 つのトレースで見られる人がいません。変更のたびに、業務側の要求を各ツールが受け付ける形に誰かが翻訳する必要があります。そうして数週間が過ぎます。出てくるのは可もなく不可もない体験か、あるいは何も出てきません。 Amazon Connect Customer のエージェンティックなセルフサービスの新機能 ここから Amazon Connect Customer で何ができるようになったかを説明します。会話、業務ルール、実行結果が 1 か所にまとまり、答えを知っている人がそれを所有します。 agentic CX designer が一般提供を開始しました。ノーコードのビジュアルキャンバス上で会話を構築できます。柔軟さが求められる部分 (意図の理解、会話の進行、ナレッジの検索など) は、エージェンティック AI が担い、正確さが求められる部分 (本人確認、クレジットの適用可否、法令・規約上の説明など) は、決定論的なルールベースのステップによって厳密に管理されます。エージェンティックなステップと決定論的なステップは同じキャンバス上に並び、AI が推論する箇所とポリシーが適用される箇所を目で確認できます。 Live Sync は、音声での会話とデジタルの画面表示をリアルタイムで同期させる、初の完全統合型エンタープライズ CX テクノロジーです。チャネルを切り替える必要はありません。顧客は通話を続けたまま選択肢を確認し、操作できます。 Touchpoint はデジタルチャネルで顧客が目にする画面を描画します。Amazon Connect Customer 向けの組み込み型クライアント SDK で、自社の Web サイトやモバイルアプリに埋め込みます。同一の会話の中で Web チャット、アプリ内音声、Live Sync のマルチモーダル機能を提供し、顧客が画面で操作した内容をフローに返します。 agentic voice は会話に声を与えます。50 を超える言語と 100 種類以上の音声に対応します。1 つの音声がその場面に応じて口調を変え、人間と同じように割り込みを処理し、顧客が言語を切り替えれば会話の途中でも追随します。別途の調達や個別のシステム連携は必要ありません。 この後は、Mateo がこの体験をどう構築したのか、そして顧客が使い始めた後に何に注目すべきなのかを解説します。 構築する 障害対応のプロセスはすでに文書化されています。障害をどう確認するか、どういう場合にサービスクレジットを適用するか、機器がどの条件で交換対象になるかが書かれています。構築はその文書から始まります。初版を立ち上げるためのラベル付き学習データも、学習させるインテントモデルも必要ありません。 ペルソナから始める Mateo はペルソナから着手します。アシスタントがどう聞こえるべきか、最初に何をすべきか、何を提示してよいか、そしてどの時点で対応を止めて人につなぐべきか。これはプロンプトの設計であり、その中身は新しくチームに加わったメンバーに渡す指示書とよく似ています。 次にモデルを選びます。キャンバス上のエージェンティックなステップごとに、Mateo はドロップダウンからモデルを選び、そのタスクに合わせて調整します。速く自然な会話が必要なステップには応答速度重視のモデルを、複数のツールをまたいで推論し複数ターンにわたる解決策を組み立てるステップには思考の深さに向いたモデルを割り当てます。同じフローの中でも部分ごとに異なるモデルを使えるので、会話のその瞬間に本当に必要な性質に合わせられます。 Amazon Connect Customer はモデル単位やトークン単位の課金ではありません ( 料金ページ を参照してください)。したがって考えるべきことは、どのモデルが Sofía にとって最良の体験になるかだけです。 エージェンティックな推論と決定論的な制御を組み合わせる 続いて Mateo は、解釈の余地を残せない部分に取りかかります。顧客がクレジットの対象になるか、なるとしていくらかは、判断ではありません。それはルールであり、所有者が決まっており、その所有者はモデルではありません。 そこで彼は、会話と判断を別の方式で扱うことにします。 エージェンティックなノード (Generative Journey) は会話の文脈をもとに推論し、許可されたツール群の中から選択して、動的に応答を生成します。Sofía の通話では、Generative Journey ノードが彼女の話を聞き、必要としているものを解釈し、モデムについて確認の質問をし、障害の状況を説明します。彼女の口調やアカウントの個別事情にも自然に合わせます。 決定論的なノードは、明示的な検証ルールを持つスロットを使います。agentic CX designer には日付、メールアドレス、電話番号、英数字文字列といった値に対応する組み込みスロットタイプが用意されています。値の範囲が限られる場合は、はい/いいえ、料金プランの区分、有効な PIN の短いリストなど、独自のスロットタイプも作成できます。各スロットは正規表現による検証、リトライ回数の設定、検証に失敗した場合のエスカレーション経路を明示的に指定できます。Sofía のクレジットについては、決定論的なノードが彼女のアカウントを適用条件に照らして確認し、正確な金額を返します。曖昧さはなく、通話ごとのばらつきもありません。 2 種類のノードはキャンバス上で隣り合って配置されます。両者の接続は視覚的に確認でき、キャンバスは両者をまたいで会話の状態を完全に保持します。収集したスロット、設定した変数、呼び出したツール、そして顧客が手続きのどこまで進んでいるかです。この状態は会話がエスカレーションしても引き継がれ、文脈が担当者や別の AI エージェントに一緒に渡ります。 薬剤師を思い浮かべてください。あなたは薬剤師に話を聞いてもらい、他に何を服用しているか尋ねてほしいし、声から鼻づまりに気づいてほしいと思うでしょう。一方で用量をその場の思いつきで決めてほしいとは思わないはずです。それが決定論的な制御とエージェンティック AI を組み合わせるということです。各ステップで AI にどこまで判断させるかを選べて、同じワークフローの中でいつでも変更できます。 ナレッジ: アシスタントが知っていること Sofía がインターネットが使えない理由を尋ねたとき、アシスタントは AnyCompany の障害対応手順に基づいて答えます。モデルの学習データからではありません。ナレッジはワークスペース内に置かれ、よくある質問には Q&A エントリ、参照量の多い資料には文書のアップロードという形で管理します。アシスタントは実行時にこの承認済みのコンテンツから情報を取得します。 アクション: 実際に処理を行うシステムにつなぐ アシスタントは Sofía のアカウントを照会し、ネットワーク運用システムから障害の状況を確認し、サービスクレジットを登録する必要があります。ここで Nikki の担当範囲になります。 agentic CX designer のデータリクエストノードが外部システムを呼び出します。一般提供の時点で 2 つの連携方式が使えます。 REST データリクエストは、アクセス可能なエンドポイントを持つ任意の API を GET / POST / PUT / DELETE で呼び出します。Nikki はアカウント照会、障害状況の確認、クレジットの登録という 3 つを設定します。それぞれについてエンドポイント、認証、リクエストのペイロード、レスポンスのマッピングを定義します。呼び出しが失敗したときの挙動、つまりリトライするのか、代替経路に進むのか、エスカレーションするのかも定義します。 MCP 経由の呼び出し (MCP egress) では、リモートの Model Context Protocol エンドポイントが公開しているツールを呼び出します。すでに AgentCore Gateway でツールを公開しているなら、管理者がワークスペースの設定で MCP エンドポイントを一度登録するだけです。Lambda のラッパーも、間に挟む API Gateway も不要で、designer が MCP プロトコルで直接ツールを呼び出します。 いずれの方式でも、API キーやトークンといった秘密情報はワークスペースに保存し、ノードごとに直接書き込むのではなく、データリクエストのヘッダーから参照します。 この役割分担が重要です。Mateo は会話の 1 ステップとしてデータリクエストを配置するだけです。何を渡し (アカウント ID)、何が返ってくるか (クレジット額、障害状況) は見えますが、エンドポイントの URL や認証の設定を知る必要はありません。Nikki は会話の設計に手を触れずに、認証情報をローテーションし、エンドポイントを変更し、レスポンスのマッピングを直せます。一度設定すれば、複数のフローやアプリケーションで再利用できます。 音声を設定する Mateo が構築している体験は音声で顧客に提供されるため、彼は Connect Customer のフロー内で「音声の設定」(Set Voice) ブロックを使って音声ペルソナを設定します。designer は会話を組み立て、Connect Customer はどの音声を使い、どう聞こえるかを制御します。 agentic voice は話者交代をリアルタイムで処理し、顧客が訂正のために割り込んでいるのか、考えながら声に出しているだけなのかを見分けます。音声は会話の展開に応じて感情を調整し、悪い知らせを伝えるときは穏やかに、解決を確認するときは明るくなります。顧客が文の途中で言語を切り替えても、音声は間を置かずに追随し、50 を超える対応言語と 100 種類以上の音声から使い分けます。 この役割分担によって、応答速度の調整、割り込みの挙動、フェイルオーバーといった音声配信の側面は基盤の所有者が持ち、会話のロジックは CX の所有者が持つ形になります。デプロイのサイクルも権限も別です。 聞かせるだけでなく、見せる — Live Sync 聞くよりも見るほうが分かりやすいものがあります。Sofía はルーターの交換対象で、月額料金の異なる 3 機種が候補にあります。3 つの選択肢を、しかも 2 度読み上げるのは、顧客を離脱させる典型的なやり方です。 Live Sync を使うと、アシスタントが通知を送り、3 つの選択肢が Sofía のスマートフォンに表示されます。通話は続いたままです。彼女が 1 つをタップすると、会話はそのまま進み、選んだ内容が会話に反映されます。別のアプリも、「一度切って Web サイトをご覧ください」も必要ありません。音声と画面をまたいだ 1 つの連続した体験になります。 Touchpoint が画面側を描画します。Web サイトやモバイルアプリに埋め込むクライアント SDK で、同一の会話セッション内に Live Sync のマルチモーダルなカードを表示し、タップやフォームの送信といった顧客の操作をフローに返します。 文脈ごと引き継ぎ、やり直させない 人につなぐこと、あるいは別の AI エージェントにつなぐことが正しい答えである場合もあります。そのとき、会話がそれまでに確定させた内容はすべて一緒に渡ります。アカウント、確認済みの障害、クレジット、顧客が選んだルーターです。収集済みのスロット、変数、ツールの実行結果を含むキャンバスの状態が、引き継ぎ先に渡ります。顧客に一からやり直させることはありません。 キャンバスは形になりました。次に Mateo が確かめるべきなのは、正しく動くかどうかです。 テストする テストは 2 つの層で行い、互いを補完します。 設計しながらキャンバス上でテストする designer には 4 つのテストモードがあります。会話全体を通すアプリケーションテスト、単一フローを試すフローテスト、発話とフローの対応を確かめるルーティングテスト、そして回帰テストとして保存しておくフローロジックのテストです。4 つはいずれもターンごとのデバッガー上で動き、会話が通過した各ノードについて次の内容を確認できます。入力と出力、蓄積されていくスロットと変数の値、Generative Journey / Generative Text / Transform ノードの推論内容 (モデルが何を検討し、どのツールを選び、なぜそうしたか)、ガードレールの判定 (何が評価され、何が通過し、何が遮断されたか)、ナレッジの検索結果 (どの Q&A エントリや文書の断片が取得されたか)、そしてデータリクエストの結果 (呼び出しのペイロード、レスポンス、発動したエラー処理) です。 変更は再デプロイなしでテストチャットに即座に反映されます。フローを保存し、テストを実行し、結果を見る、という流れです。クレジットが 30 ドルではなく 15 ドルで返ってきたとき、モデルが Sofía の意図を読み違えたのか、データリクエストがアカウントシステムから誤った値を取得したのかが分かります。バグの種類が違えば、直すべき担当者も違います。 まずは決定論的なステップと会話の出口をテストしてください。クレジットの金額、規約上の説明、エスカレーションの発動条件です。間違っていたときに損失が出るのはここです。ガードレールの判定結果はターン単位で確認できるため、プロンプトインジェクションの試行や方針違反が、実際のトラフィックが体験に届く前に捕捉されていることを確かめられます。CI/CD パイプラインを運用しているチームであれば、このテスト機構をデプロイの承認ゲートの前段で会話ロジックの検証に使えます。 トラフィックを流す前に、コンタクト全体の経路をテストする designer がテストするのは会話です。Amazon Connect Customer のテストとシミュレーション機能は、コンタクト全体の経路をテストします。通話を振り分ける Connect Customer のフロー、「音声の設定」ブロック、Agentic CX ブロックの呼び出し、そしてエスカレーション先のキューの設定までが対象です。テストは自然な文章で記述し、実際には呼び出したくない外部システムはモックに置き換え、変更のたびに再実行されるようスケジュールできます。意味的な一致で判定するため、プロンプトの言い換えによって、本来通るべきテストが落ちることはありません。 テストとシミュレーション機能は、複数の会話をまたぐエンドツーエンドのテストケースに対応します。コンタクト属性の検証、Lambda や Agentic CX の挙動の上書き、キューや営業時間の上書き、顧客としてのテキスト入力や DTMF 入力の送信ができます。2 つの機能を併用してください。設計時の会話ロジックの検証には designer のキャンバスを、デプロイ後の組み上がった体験の検証には Connect Customer のシミュレーションを使います。 公開、デプロイ、そして変更 テストが通ったら、Mateo はビルドを作成します。ビルドはその時点のすべてのフロー、アプリケーションの設定、ガードレールの割り当てを固定した、変更不可のスナップショットです。2 つのビルドを比較すると、変更されたノード、更新されたガードレールの割り当て、新たに追加された連携といった差分が分かります。管理者は、レビュー済みのビルドだけが本番に到達するよう担保できます。 ビルドをデプロイすると本番稼働します。以前のビルドは保持されるため、本番で問題が起きた場合のロールバックは 1 操作で済みます。 Connect Customer のフローは Agentic CX ブロックを通じて designer のアプリケーションを呼び出します。このブロックをつなげば、同一のビルドが音声、チャット、SMS を担います。どのチャネルになるかは Connect Customer フローのチャネル設定で決まります。電話をかけた顧客は agentic voice を通して同じ内容を聞き、チャットで入力した顧客も同じロジック、同じ決定論的なガードレール、同じ結果を得ます。1 つのビルドで、サポート対象のすべてのチャネルに対応できます。 最適化する いま、実際の顧客が既に利用しています。分析オーバーレイは、Mateo が構築したフロー上にトラフィックと離脱率を直接表示します。つまり、同じキャンバスに数値が表示されるということです。もし発信者の 3 分の 1 が同じステップで離脱していれば、どのステップかが分かり、その場で開けます。このフィードバックの循環によって、初版が良い版になるまでの時間が数か月ではなく同じ週の中に収まります。 ガードレールはターンごとに評価され、記録されます。顧客のプロンプトが方針の境界を押している状況を検知できます。モデルの出力が決定論的なノードと矛盾した場合 (業務ルールと一致しないクレジット額など)、決定論的なノードの結果が優先されます。権限を持つのはモデルではなくフローです。 会話分析では、個々のコンタクトを 1 回のやり取りとその背後にある推論の単位まで掘り下げて把握できます。モデルがなぜその経路を選んだのか、どのナレッジを取得したのか、どこで引き継いだのかを追跡できます。パフォーマンス評価は自社の品質基準に照らしてコンタクトを採点し、人手の抜き取り確認ではなく一貫した基準で評価します。ガードレールの評価結果と監査ログはコンプライアンス関連のツールに書き出せます。すべての書き込みと削除の操作は、実行者、時刻、対象リソースとともに記録されます。 翌週に起きたこと 翌週の月曜日、Mateo が分析オーバーレイを開くと、発信者の 28% がクレジットの説明のステップで離脱していることが分かりました。いくつかの会話を聞いてみると、顧客は「利用規約」という言葉を聞いて、担当者につながるまで待たされると受け取っていたのです。 彼はそのノードのプロンプトを書き直します。「これから利用規約を読み上げます」ではなく、「お客様のクレジットの詳細をご案内します。15 秒ほどで終わります」と言わせるようにしました。保存し、キャンバス上でテストし、新しいビルドを作成して、昼までにデプロイします。 水曜日には、そのステップの離脱率が 9% まで下がっていました。体験そのものは、2 週間前の火曜日に彼が構築したものと同じです。ただ良くなったのです。顧客にいちばん近い人が、端から端まで所有しているからです。 始めましょう 障害を確認する手順、サービスクレジットの適用方針、機器が交換対象になる条件といったプロセスがすでに文書になっているなら、いちばん時間のかかる部分はもう手元にあります。 体験を所有している方は、 Amazon Connect Customer のコンソール を開き、agentic CX designer で最初のアプリケーションを作成してください。セットアップの手順は 管理者ガイド で確認できます。順を追って学びたい場合は AWS Skill Builder のコースも用意されています。 プラットフォームを所有している方は、同じ 管理者ガイド で連携のパターン、REST と MCP の設定、ワークスペースの管理、ビルドとデプロイのパイプラインを確認できます。 Web の体験を追加する場合は、 Touchpoint のクライアント SDK を導入して、自社の Web サイトやモバイルアプリでチャット、音声、Live Sync を提供してください。 チームで評価する場合は、 ガイド付きワークショップをリクエスト してください。アーキテクチャの解説と、自社のユースケースに沿ったハンズオンでの構築を体験できます。 著者について Alex Schrameyer (he/him) は Amazon Web Services (AWS) の Worldwide Solutions Architect Lead for Agentic Experience で、シカゴ近郊を拠点としています。優れた応対担当者の体験こそが優れたカスタマーサービスの基礎であると考え、人間の担当者と AI エージェントの双方が滞りのない顧客体験を提供できるようにするソリューションの設計に取り組んでいます。世界各地を旅するのが好きで、地元の野球場やテーマパークで見かけることがあるかもしれません。 本記事は 2026 年 9 月 2 日に公開された「 Blend structured business logic with agentic AI to deliver delightful conversational experiences 」を翻訳したものです。この記事はソリューションアーキテクトの夏堀京司が翻訳しました。

はじめに この記事は、BASEテックブログ夏のブログリレー11日目の記事です。 BASE Dept. Product Divにてバックエンドエンジニアをしている オリバ です。 ショップオーナーの発送領域を担当しており、バックエンドを中心に、フロントエンドやNew Relicなども触っています。 2026年5月、担当する「送り状一括印刷 App」の一部機能をリリースしました。しかし、リリース後に分かったのは、想定していた使われ方をされていないということでした。機能自体は動いていますが、開発チームが想定していた操作と、ショップオーナーの実際の操作が違っていました。 Appの概要や使い方は以下をご覧ください。 送り状一括印刷 App（BASE Apps） apps.thebase.com 発送作業の時間を大幅削減！「送り状一括印刷 App」の使い方解説（BASE U） baseu.jp 本記事では、顧客の声を開発の意思決定に組み込むために実践した3つの取り組みと、その効果について共有します。 顧客中心主義とは 私は仕事の中で「顧客中心主義」という考え方を心掛けています。『みんなでアジャイル』で知った言葉です。 この本では、組織全体でアジャイルを実践するための原則として、次の3つが紹介されています。 「顧客から始める」「早期から頻繁にコラボレーションする」「不確実性を計画する」 引用：みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた｜O'Reilly Japan www.oreilly.co.jp もともと私はDDDやクリーンアーキテクチャが好きで、設計に関心がありました。これらは変更容易性を高めるための手段でもあり、いわばHOWにあたります。ただ、HOWをいくら磨いても、何を作るかというWHATとなぜ作るのかというWHYが定まっていなければ成果にはつながりません。自分にはこのWHATが足りていないと感じ、顧客中心主義を実践しようと思いました。 とはいえ、言葉として知っていることと、日々の開発で実践できているかは別です。 なぜ顧客の声を聞きに行ったのか 以下の3点が理由です。 1. 開発チームだけではユースケースの想像に限界がある 新機能の開発時、その機能が使われるユースケースを開発チームだけで想像していました。しかし、ショップオーナーが発送作業の際にどの画面を見て、何を基準に判断しているのかは把握できていませんでした。 2. チームが向かう方向を決めるきっかけにしたかった 私は送り状一括印刷App開発のPJMを務めており、チームが向かっていく方向づけも担っています。「この機能を今すぐ開発すべきなのか、本来の趣旨から外れているから後に回すべきか」といった判断を、顧客の実態をもとに行いたいと考えました。 3. AIの導入で実装スピードが上がり、PDCAを回したかった 開発にAIを導入したことで、実装スピードが上がりました。ただし、作るスピードが上がっても、何を作るかの精度が上がらなければ効果は限定的です。リリース後の反応を早く拾い、次の改善につなげるサイクルを回したいと考えました。 実践① ユーザーインタビューに同席する PdM・デザイナーが実施するショップオーナーへのユーザーインタビューに、3〜4回同席しました。聞くだけではなく、私からもいくつか質問をしています。 想定していた動線と実際の動線が異なっていた 送り状一括印刷 Appでは、お届け先住所の初期値に購入者がカートで入力した住所情報が、送り主情報の初期値にAppの設定画面で登録した住所情報が設定されます。個別に変更したい場合は、注文画面の送り状印刷アイコンからモーダルを開いて変更できます。 しかしインタビューでは、このモーダルの存在に気づいてもらえておらず、「お届け先住所と送り主情報の初期値は変更できない」と認知されていることが分かりました。 注文画面の送り状印刷アイコン（2026年9月時点） 送り状印刷アイコンから開く「送り状内容」モーダル（2026年9月時点） 発送通知の失敗が把握しづらく、独自運用で補われていた 発送通知に失敗しても、ショップ側で後から把握しづらい状態になっていました。そのため、注文メモなどを使った独自運用で補っているケースがありました。 エラーの有無だけでなく、対象の注文・失敗理由・次に取るべき行動を後から確認できる必要があると考えています。 注文画面が発送判断の中心的な画面になっている インタビューを通じて、注文画面がショップの梱包・発送を判断するための中心的な作業画面になっていることが分かりました。メンバーシップ特典など、発送判断に必要な情報は注文画面上で確認・検索できるとよいと考えています。 発送判断の中心となる注文画面（2026年9月時点） 細かな改善でも現場の制約を解消できる 問い合わせで挙がっていた要望をもとに、送り状一括印刷 Appで印刷位置を指定できるようにしました。その後のユーザーインタビューでは、この改善についてショップオーナーから感謝の声をいただきました。大きな機能追加ではなくても、現場の制約を解消する改善には実用的な価値があると感じました。 同席して分かったこと 開発者には自明なアイコンや操作でも、初めて使うショップには意図が伝わらない場合がある UIだけでなく、ツールチップや画像付きヘルプなども含めて使い方を伝える必要がある ショップオーナーの利用実態や反応を直接知ることが、開発の目的と価値の再認識につながる 実践② 問い合わせ内容を定期的に確認する BASEのショップ管理画面には問い合わせフォームがあります。このショップオーナーから寄せられた問い合わせを、定期的に確認するようにしました。 開発中・リリース直後の機能は週に数回確認する 開発中の機能やリリースしたばかりの機能については、週に数回確認しています。ユーザーインタビューと違って日程調整が不要なため、リリース直後の反応をすぐに拾えます。 SLI/SLO振り返り会のアジェンダに組み込む 個人が気の向いたときに見るだけでは、見る人と見ない人が分かれ、チームの判断材料になりません。そこで、Order Sectionで月1回実施しているサービスレベル（SLI/SLO）振り返り会のアジェンダに、顧客の声を確認する時間を組み込みました。 SLI/SLOの数値は、システムがどれだけ安定して動いているかを示します。しかし、その数値が顧客にとって十分かどうかは、数値だけでは分かりません。同じ場で顧客の声を扱うことで、指標と実態を突き合わせて話せることを狙っています。 見つけた声はSlackでチームに共有する 送り状一括印刷 Appについては、PdMと私が問い合わせ内容を見て、気になった声をSlackでチームメンバーに共有しています。現状はこの形で回っており、メンバー全員がDBを見に行く状態にはなっていません。 実践して分かったこと 送り状一括印刷 Appにおいて、想定した使い方がされていないことをすぐに認知でき、改修からリリースまでのサイクルを短く回せた。アジャイルの利点が出た部分だと感じている SLI/SLOのエラーバジェットの数値が安定していても、ショップオーナーの希望を満たせているとは限らないことが分かった 実践③ CXチームにヒアリングする CXチームは、ショップオーナーと継続的にコミュニケーションを取りながら、ショップ運営の課題解決や「BASE」の活用を支援するチームです。このCXチームにMTGの時間をもらい、ヒアリングをしました。 非機能要件の課題を見つける目的で声をかけた CXチームが担当するショップオーナーの中には、規模の大きいショップも多く含まれます。注文・発送領域のパフォーマンスなど、非機能要件の課題を見つけられるのではないかと考え、声をかけました。 実践①のユーザーインタビューや、実践②の問い合わせ内容で拾えるのは、使い方や機能に関する内容が中心です。一方で、表示速度のような非機能要件の話は、問い合わせとして上がってこないこともあります。 開発チームからは見えていなかった課題を把握できた ヒアリングを通じて、開発チームからは見えていなかった非機能要件の課題を把握できました。具体的な内容はここでは割愛しますが、実践②で書いたとおり、SLI/SLOを見ているだけでは気づけない内容でした。 単発のMTGから継続的なやり取りへ ヒアリングのMTG自体は一度だけですが、その後もCXチームとのやり取りは続いています。 実践して分かったこと 非機能要件の課題は、ショップオーナーと日常的に接しているチームのほうが実態を把握している場合がある エンジニアから他部署に声をかけることで、一度のヒアリングだけでなく継続的な相談先ができる 何が変わったか 改善タスクの起票数が増えた Order Sectionには複数チームがあり、私が所属するチームでは、注文画面や発送領域に関する改善タスクの起票数は、以下のように変化しました。 2〜6月：月2〜4件 7月以降：月7〜8件 7月ごろにユーザーインタビューを実施し、そこで得た内容をもとに課題の洗い出しから起票、実装、リリースまでを行いました。顧客の声を聞くことで、これまで見えていなかった課題が可視化され、タスクとして起票できるようになったことが大きいと考えています。 エンジニアから提案してタスク化する場面が増えた これまでは、Bizチームや顧客問い合わせの多さを鑑みて、別部署から依頼された案件をタスク化していくことが多かったです。顧客の声を直接知るようになってからは、エンジニアからPdMやデザイナーに提案し、タスク化して改善につなげる場面が増えました。 職種を越境して、主体的に改善タスクを推進できるようになったことが、今回の一番大きな変化だと感じています。顧客の声が、何を作るかを決める際の材料として開発の意思決定に入るようになった、とも言えます。 うまくいかなかったこと 課題が可視化され、AIによって実装も速くなっていたため、タスクを並列で進めようとしてしまいました。結果、自身が疲弊しました。 顧客の声を聞くと、改善すべきことは確実に増えます。実装スピードが上がったことで、「やれるはず」と思ってしまったのも原因だと考えています。声を集める仕組みだけでなく、集まったものを絞る側の判断も必要だと感じています。 これからやりたいこと BASEコミュニティ Meetupに参加する 弊社ではショップオーナー向けのコミュニティポータルを運営しており、その一つの取り組みとしてBASEコミュニティ Meetupを開催しています。 BASEコミュニティポータル community.thebase.com 前回はこちら：BASEコミュニティ Meetup vol.15 大阪（2026年8月開催） community.thebase.com 今後は運営側としてこの場に関わり、ショップオーナーの声を直接聞いて発送領域の改善につなげていきたいです。 非機能要件の課題をもっと洗い出す CXチームへのヒアリングで、非機能要件の課題は開発チームから見えにくいことが分かりました。機能要件だけでなく、非機能要件の課題を洗い出して改善していきたいと考えています。 おわりに 本記事では、顧客中心主義を開発の意思決定に組み込むために実践した3つの取り組みを紹介しました。 開発チームの中だけで顧客の使い方を想像していた状態から、顧客の実態をもとに改善を提案できる状態に変わりました。ただし、可視化できてきたのは機能要件に関する要望が中心です。非機能要件の課題はまだ隠れているものが多く、これをどう見つけていくかが今後の課題です。 弊社では、顧客の声をもとにプロダクトを改善していくことに関心のあるエンジニアを積極採用しています。興味を持っていただけたら、ぜひ下記からご応募ください！ binc.jp 明日は、BASEテックブログ夏のブログリレーのラストを飾る、rerenoteさんの記事です。お楽しみに！

はじめに こんにちは。技術戦略部CTOブロックの ikkou です。ZOZOでは毎年、独自の新卒研修を実施しています。さらに昨年からは、日本CTO協会の新卒エンジニア合同研修にも参加しています。参加は任意として、興味を持つ研修を自身で選択できるようにしました。本年度は2名の新卒エンジニアが参加しました。本記事では参加者によるレポートをお伝えします。 目次 はじめに 目次 日本CTO協会の新卒エンジニア合同研修とは 第1回：関係の質を上げるファシリテーション 第2回：Google Cloudで実現するクラウドネイティブ・アーキテクチャ 第3回：エンジニアの働き方とキャリア論 第4回：Codexを使った開発 第5回：GMOペパボによるサーバー解体研修 第6回：Alibaba Cloudから学ぶクラウドの基礎 第7回：合同ISUCON研修 印象に残った学び 業務・キャリアに活かしたいこと まとめ 日本CTO協会の新卒エンジニア合同研修とは 日本CTO協会は、企業の技術責任者が集まり、日本のDX（デジタルトランスフォーメーション）とCX（コーポレートトランスフォーメーション）の推進を目指す団体です。新卒エンジニア合同研修は、その会員企業の新卒エンジニアを対象とした取り組みで、2024年度に始まり、今年で3年目を迎えました。1社では用意しきれない学びの機会を企業の枠を越えて持ち寄り、業界全体で新卒を育てるという趣旨の研修です。 2026年度は全7回で、回ごとに異なる会員企業が講義を担当し、会場もその企業のオフィスへと変わります。扱われた領域は、ファシリテーションからクラウド、キャリア、コーディングエージェント、物理サーバー、パフォーマンスチューニングまで多岐にわたりました。参加者は各社の新卒エンジニア約100名で、講義だけでなくグループワークや懇親会を通じて他社の同期と交流できるのも、この研修の特徴です。 第1回：関係の質を上げるファシリテーション 第1回は北島が担当いたします！　今回は、株式会社メンバーズさんの神尾武志さんによる「関係の質を上げる」ためのファシリテーションを学ぶ講義で、最後にグループワークを実践するという研修でした。 ファシリテーションとは「人々の活動が容易にできるよう支援し、うまくことが運ぶよう舵取りすること」と定義されています。そのために必要なのが参加者同士の関係の質、つまり心理的安全性や相互理解です。この土台を作るのがファシリテーターの役割だという話でした。 具体的な立ち回りとして「伝える・場を見る・働きかける」の3つが紹介されました。 まず「伝える」では、参加者はファシリテーターより情報が少ない状態でその場に来ます。はじめにアジェンダ・趣旨・ゴールを伝えて心の準備をしてもらうことで、参加者が安心して場へ入れるようになります。途中でまとめを挟んで「今どこにいるか」を共有するのも、透明性を保つための大切な作法です。 次に「場を見る」では、参加者同士が議題を介して自走できているかを観察します。うまくいっていないなら介入し、回っているなら手を引く。どちらの判断も「働きかけ」であり、ファシリテーターが場全体を俯瞰して舵取りする姿勢が関係の質を守ります。 最後に「働きかける」では、問いの設計と仕組みの設計が肝でした。「質問ありませんか？」は答えにくく、「どちらかといえば？」「一言だけ感想を」のようにクローズな問いや小さな問いから入るほうが参加しやすくなります。発言しない人に対しても「やる気がない」と捉えるのではなく、事前に書いてもらう、その場で書く時間を取るなど、場の設計で引き出せるという視点は新鮮でした。 グループワークは「懇親会でもっとお互いを知りたくなる自己紹介を作る」がテーマでした。 私のグループは「話したいエピソードを選んで話す」というお題にし、私はファシリテーターを担当しました。 エンジニアならではのエピソードを中心に、お題を自由に選べる形式にしました。その結果、心理的安全性が保たれ、相互理解も自然に進みました。共通点が見えた瞬間に場の雰囲気はぐっと変わり、ファシリテーションの効果を実感しました。 第2回：Google Cloudで実現するクラウドネイティブ・アーキテクチャ 第2回も北島が担当いたします！　今回は、Google Cloudさんによる「次世代のクラウドネイティブ・アーキテクチャ」をテーマにした講義でした。 コンピュートは仮想マシン → コンテナ → サーバーレスという流れで進化しており、今の新規開発ならCloud Runが主流だという話でした。コンテナを渡すだけでデプロイでき、アクセスがなければ料金もかかりません。このシンプルさが強みです。 データベースもAI目線で見ると選び方が変わってきていて、ベクトル検索に対応しているAlloyDB（PostgreSQL互換の高性能版）が今注目されているとのことでした。 その流れで出てきたデータ基盤の話に、最も関心を引かれました。「統合・品質・可読性」の3条件が揃っていないと、AIエージェントは正しく動かないという話でした。散在データを集めて正確にし、人間とエージェントの双方が理解できる形にします。SREが「信頼性」と向き合うときの考え方と同じだと感じました。 こうしたデータ基盤の上に乗るのがGeminiです。テキスト・画像・動画をまとめて処理できるマルチモーダル性が他社との違いで、さらにGemini Roboticsとして映像・音声・物理動作を統合した身体性AIへの展開も紹介されていました。AIが「考える」から「動く」へ変わっていく様子には、少しゾクっとしました。 全体を通して伝わってきたのは、Google Cloudの強みがデータ基盤とGeminiを同じプラットフォームでつなげられる点にあり、AI活用の本質は技術より先にデータを整えることにあるということです。 懇親会ではGoogleのサービスに関するクイズがありました。結果は100人中9位でした。 第3回：エンジニアの働き方とキャリア論 第3回は、佐藤が担当いたします！　今回は、株式会社LayerX代表取締役CTOの松本勇気さんによる発表でした。テーマはエンジニアの働き方とキャリアです。ご自身の経験を交えながら、「キャリアを投資として考える」「フォロワーシップとマネジメント」「LLM時代のエンジニアのキャリア論」という三部構成でお話を伺いました。 第一部のテーマは、キャリアを投資家の視点で捉えるという考え方です。自分が持っている時間、体力、知識、経験、信用、これらはすべて資産であり、キャリアとはその資産を運用し続けるプロセスだと説明されました。そうであれば、投資と同じようにバランスシートやポートフォリオを意識できるはずです。手元の資産をどこへ配分し、どんなリターンを期待するのかを常に考える、という発想です。 興味深かったのは、リスクの取り方についての話です。大きな挑戦にはレバレッジが効く一方で、当然ながら失敗する可能性もあります。しかし、その経験自体も知識として蓄積され、次の判断の精度を上げてくれます。何もしないという選択にもリスクとリターンがある、という指摘には考えさせられました。もう1つ強調されていたのが、周囲のコミュニティです。友人、一緒に働く上司や同僚、社外のエンジニアコミュニティなど、どのような人たちと時間を共にするかが、そのまま自分の成長につながります。コミュニティを充実させること自体が、資産を増やすための投資の1つだといえます。 第二部では、チーム開発とマネジメントについての話がありました。そもそも、なぜチームで開発するのでしょうか。1人で開発すれば意思決定は速く、他人への配慮も要らないため、効率のよい面もあります。それでもチームを組むのは、大規模なものを作るには人数が必要だからです。1人では視点や考慮も不足します。そのうえでチームの効率を落とさないために欠かせないのが、マネジメントだと説明されました。 ここで出てきたのがフォロワーシップという考え方です。マネージャーも完璧ではありません。だからこそメンバー側から自己開示をしたり、自分の考えを言語化して伝えたりすることで、マネージャーが動きやすい状況を作れます。マネジメントされるのを待つのではなく、こちらからも働きかけていくという姿勢です。この話は個人的にとても面白く聞きました。マネジメントは上司から一方通行で受け取るものだと思っていたのですが、実際にはメンバー側からフォロワーシップという形で応えられます。働くうえで自分たちが楽しいと感じられる状態を作るために、こちらから動く余地があるという視点は、これまで持っていなかったものです。 第三部のテーマは、LLMの登場によってエンジニアのキャリアがどう変わるのかです。結論として示されたのは、デザイナーやエンジニアといった職種の垣根が今後どんどん低くなるという見立てでした。LLMを使って設計からデザイン、実装までを一人で担います。そうした働き方が当たり前になっていくという話です。ここで出てきたキーワードがAI builderです。LayerXでは、この言葉を実際に使っているそうです。 では、新卒は何をすればよいのでしょうか。挙げられていたのは、まず師匠を探すことでした。ロールモデルになる人や、優秀だと思える上司の近くで学ぶ価値は大きいという話です。もう1つが、軸をずらして戦うという戦略です。経理とエンジニアリング、営業とエンジニアリングのように、本来は別々だった職種を掛け合わせて自分の立ち位置を作るという考え方です。掛け合わせが差別化になるという指摘は、今後のキャリアを考えるうえで役に立ちそうだと感じました。 第4回：Codexを使った開発 第4回も佐藤が担当いたします！　今回はオンラインでの開催で、OpenAIでCodexの開発に携わる方による講義でした。前半はCodexの使い方の解説、後半は実際にCodexでアプリを作るハンズオンという構成です。 はじめに扱われたのが、コンテキストとは何かという話でした。コンテキストはエージェントのワーキングメモリであり、そこに何をどれだけ載せるかがエージェントの振る舞いを決めます。コンテキストウィンドウには限りがあるため、必要な情報を必要なだけ渡す設計が重要です。あわせて、SkillsとMCPが何を担うものなのか、両者の違いについても解説がありました。 講義でとくに時間が割かれていたのが、Skillsの作成です。面白かったのは、スキルを作るためのスキルが用意されている点でした。作りたい処理の要件をエージェントと対話しながら整理し、改善を重ねて1つのスキルに落とし込んでいきます。手続きを頭の中に置いたまま毎回プロンプトで説明するのではなく、繰り返す作業をスキルとして切り出していく進め方です。さらに、他の人が使っているスキルを自分のCodexでもそのまま動かせるように環境を整える、という話もありました。個人の工夫で終わらせず、チームで共有できる資産にしていく発想です。 複数のエージェントを並行して動かす場合は、それぞれに必要な処理をどう組み込むかが課題になります。ここで紹介されたのが、ツールを実行するタイミングの設定でした。ある処理の前に動かすもの、後に動かすもの、セッションの開始時に動かすものといった設定を組み合わせることで、エージェントが動く土台そのものを設計できます。いわゆるハーネスエンジニアリングにあたる考え方だと理解しました。 登壇者が強調されていたのが、Auto-reviewの機能です。Codexでは、エージェントが操作できる範囲を定めるサンドボックスと、範囲外の操作をする際の承認方法を組み合わせて設定できます。通常の設定では、ワークスペース内の一般的な操作はそのまま実行でき、設定された境界を越える場合に人間へ承認を求めます。Auto-reviewを有効にすると、こうした承認要求の一部を別のレビューエージェントが審査し、その判定に応じて実行を制御します。人間が逐一確認する手間を減らしつつ、無制限に権限を渡すリスクも避けられる仕組みだといえます。このほかにも、デフォルトの設定の考え方、プランモードの使い方、画像を渡した開発の進め方など、実践的なTipsを数多く紹介いただきました。 講義の後半は、実際にCodexを使ったアプリ開発です。私は、自社のキャラクター（箱猫マックスくん）を題材にしたポモドーロタイマーの拡張機能を作りました。作業と休憩の時間を管理するシンプルなツールです。 驚いたのは、そのスピードでした。作りたいものの要件を伝えてから、動くところまでこぎつけるのにかかった時間は10分ほどです。完成したものが次の画面で、集中する時間をカウントダウンし、残り時間に応じてキャラクターがバーの上を進んでいきます。 この規模のアプリケーションであれば、思いついたその場で形にして試せます。わざわざ作るまでもないと諦めていたアイデアも、まず動かしてから判断できるようになります。手元の道具をこうして気軽に作れるという感覚は、講義を聞くだけでは得られないものでした。 普段からコーディングエージェントは使っていましたが、開発している当人から設計の意図を聞けたのは貴重な機会でした。エージェントにどこまで任せ、どこを人間が握るのかの線引きを、権限の設定という具体的な形で考えられるようになったのが一番の収穫です。 第5回：GMOペパボによるサーバー解体研修 第5回は北島が担当いたします！　今回は、GMOペパボさんによる物理サーバーの話でした。 クラウド全盛の今でも物理サーバーには独自の強みがあるという話は、新鮮に感じられました。コストはクラウドより安く抑えられ、メガクラウドや為替レートにも左右されません。クラウドやAIであっても「末端は物理ハードで動いている」という言葉には、強く納得しました。デジタルガジェットとして楽しい、という言い方も好きでした。 ただ管理の大変さも正直に話していただきました。ラッキングやケーブリング、部品交換、温湿度・入退室管理、深夜のトラブル対応など、クラウドなら画面の操作で済むところが、すべて自前になります。スペック選定もシビアで、買ったら変更できない分、過剰でも不足でも損をします。寿命も3〜5年で、老朽化したら計画的なリプレースとデータ移行が必要になるという話をしていただきました。 その話を聞いた後で、実際にサーバーを解体する体験がありました。CPU、ECCメモリ、ストレージ、マザーボード、冗長電源、NIC、冷却ファン、そしてOSが止まっていても遠隔操作できるリモート管理カード（iLO・iDRAC）まで、構成要素を一通り手で触りました。話で聞いていた「管理が大変」の意味が、実物を目の前にすると一気に腑に落ちました。 普段はKubernetesやクラウドの抽象レイヤーの上で仕事をしているので、こうして物理を触る機会はなかなかありません。重さがあり、熱を持ち、騒音も出します。そうした実体のあるコンピューターと向き合うと、インフラへの解像度は一段上がった気がしました。 第6回：Alibaba Cloudから学ぶクラウドの基礎 第6回は佐藤が担当いたします！　今回のテーマはAlibaba Cloudです。中国の巨大ECを運営するアリババグループ傘下のクラウド事業会社が提供するパブリッククラウドサービスです。欧米含めグローバルに30リージョン・104のアベイラビリティゾーンを展開しており、アジア太平洋地域では1位、世界では4位という立ち位置にあると紹介されました。中でも特にアジア市場に集中的に投資をしており、中国をはじめとするアジア市場との結びつきが強いのも特徴といえます。講義はクラウドの基礎から始まり、後半はAI時代に向けたクラウドの話へと進んでいきました。 まず扱われたのが、クラウドとオンプレミスの違いです。自社でサーバーや機器を購入して設置、管理するのがオンプレミス、プロバイダーが管理するインフラをネットワーク越しに借りるのがクラウドという整理でした。クラウドのメリットとしては、負荷に応じてリソースを増減できるスケーラビリティと、使った分だけ支払えばよいコスト効率が挙げられます。 面白かったのは、この違いを会計の視点から捉え直す話です。オンプレミスはサーバーという資産を購入するため、初期に大きな投資が発生します。これがCapEx、資本的支出です。対してクラウドは月々の利用料として支払うため、発生した期に費用として計上されます。こちらがOpEx、運用費用にあたります。CapExでは、ピーク時の負荷を事前に予測して設備を購入しなければなりません。予測が外れれば過剰投資になり、逆に足りなければ機会損失につながります。OpExであれば需要に応じてコストが変動するため、事業の変化に追従しやすくなります。クラウドが選ばれる理由を技術面だけでなく経営面から説明されると、腹落ちの度合いが違いました。 続いて、どこまでをプロバイダーに任せるかによる分類、クラウドサービスモデルの話です。まずは、仮想マシンやネットワークなどインフラ環境を提供するIaaSがあります。そのうえに、アプリケーションの実行基盤まで用意するPaaS、アプリケーションそのものを提供するSaaSと続きます。プロバイダーに任せる範囲が広がるほど、利用者が管理する範囲は狭くなります。さらに近年は、AIの大規模モデルをサービスとして利用できるMaaS（Model as a Service）も加わってきているという話がありました。クラウドの分類そのものが、AIの登場によって更新されつつあるということだと理解しました。 構成の話として紹介されたのが、ハイブリッドクラウドとマルチクラウドです。ハイブリッドクラウドは、パブリッククラウドとプライベートクラウドやオンプレミスを組み合わせる構成を指します。一方のマルチクラウドは、AWSとGoogle Cloudのように複数のパブリッククラウドを組み合わせる構成です。ベンダーロックインを避けられる、それぞれの強みを活かせるといった利点がある反面、運用や監視が各クラウドで異なるため複雑になるという課題もあります。この話は、自分の業務と結びつけて聞けました。ZOZOでも複数のクラウドを併用しており、普段はその上で開発をしています。当たり前のものとして使っていた構成に名前と理由がついた感覚です。なぜこうなっているのかを考える良いきっかけになりました。 講義の終盤で取り上げられたAIとセキュリティの話には、特に興味を引かれました。AIの普及によって、必要な電力量やリクエストの量が急増し、AIのためのデータ基盤も求められるようになっています。そうした変化のなかで、AI時代のクラウドのセキュリティをどう担保するかに力を入れているという話でした。インフラや資源に強みを持つからこそ描ける展望があるのだと感じました。 第7回：合同ISUCON研修 第7回は北島が担当いたします！　今回は株式会社PR TIMESさんによるISUCON研修 *1 です。Webアプリケーションのパフォーマンスチューニングに取り組みました。チーム戦ではなく個人戦で、AIをどう活用できるかが問われる内容でした。 GETのインデックス最適化、DBのJOIN最適化、POSTの非同期処理と順番にチューニングし、結果は90人中7位でした。スコアが上がるたびに手応えはありましたが、40万点あたりで完全に詰まってしまい、1位の60万点には遠く及びませんでした。 壁にぶつかって気づいたのが、「計測が先、最適化は後」とするべき順番を逆にやっていたということです。アクセスログを集計してどのエンドポイントが遅いかを可視化し、スロークエリを洗い出してからボトルネックを潰していくという順番が正解です。自分は「これが遅そう」という勘で先に手を動かしていました。やったこと自体は間違いではありませんが、どこに時間を使うべきかが見えていないままでした。 AIの使い方も、同じ話でした。後半で引き出しが尽きてきたとき「なんか遅い気がするんだけどどうすればいい？」のような質問をしてもスコアはまったく伸びませんでした。AIは事実ベースで動くため、感覚を渡しても答えは出てきません。「このエンドポイントのレイテンシが〇ms出ている、原因として何が考えられる？」という具体的な数字があってはじめて、有効な回答が返ってきます。 裏を返せば、わからないことやぼんやりした概念はそのままにせず、AIに聞いて解消してしまうのが一番いい使い方です。AIには納得がいくまで質問でき、聞けばすぐ答えてくれます。ぼんやりしたまま放置する理由はありません。事実をつかみ、わからないことをなくしていくのがAI時代の学び方だと思いました。 印象に残った学び 全7回を振り返ると、扱われた領域はキャリアからインフラ、AIまで幅広いものでした。それでも通して聞くと、回をまたいでつながる話がいくつもあります。2人に共通して印象に残ったのは、次の3つです。 1つ目は、AIとの向き合い方が具体的な設計の問題として語られていたことです。第4回では、コマンドの実行権限をどう設定するか、どのタイミングでどのツールを動かすかという形で、エージェントが動く土台そのものを設計する話がありました。第7回では、感覚を投げても答えは返ってこず、具体的な数字を渡してはじめて有効な回答が得られるという経験をしました。第3回で出てきたAI builderという言葉も、AIを前提に自分の仕事の範囲を引き直す姿勢を指しています。AIを使いこなすというと、うまい指示を出す技術の話に聞こえがちです。しかし研修を通して見えてきたのは、どこまでを任せ、何を渡し、どこで人間が判断するのかを決める設計の話でした。 2つ目は、抽象化されたレイヤーの下には実体があるということです。第5回のサーバー解体は、普段の開発では意識しない層に触れる機会でした。第2回と第6回でクラウドの話を聞いた後だったこともあり、抽象化されたサービスの下には物理的な実体があるという当たり前の事実を、実感を伴って理解できました。第6回で出てきたCapExとOpExの話も、同じ方向を向いています。クラウドを使うというのは、本来自分たちが抱えるはずだったコストとリスクを、誰かに預けるという判断です。何が抽象化されているのかを知っていれば、預けている範囲も、自分たちが引き受けるべき範囲も見えてきます。 3つ目は、場や関係性も設計できるという視点です。第1回のファシリテーションと第3回のフォロワーシップは、扱っている題材こそ違うものの、根っこは同じでした。参加者が発言しないのは、やる気がないからではなく場の設計に理由があるのかもしれません。マネジメントがうまく回らないのは、マネージャーだけの問題ではなくメンバー側から働きかける余地があるのかもしれません。どちらも、目の前の状況を所与のものとして受け取らず、自分の側から設計できると捉える見方です。チームで働くとき、技術と同じくらい実践的な考え方だといえます。 業務・キャリアに活かしたいこと 私たちは配属されたチームが異なり、日々向き合っている技術も違います。それでも研修を終えて、共通して持ち帰りたいと考えたことが3つありました。 1つ目は、計測を先に置くことです。第7回で痛感したとおり、勘を頼りに手を動かしても、どこに時間を使うべきかは見えてきません。改善の施策を考える前に、何が起きているのかを数字で押さえることが重要です。当たり前でありながら、忙しくなるほど飛ばしてしまいがちな手順だと反省しました。 2つ目は、エージェントに任せる範囲の設計です。日々の開発でコーディングエージェントを使う場面は増えていますが、その多くは個人の工夫にとどまっています。繰り返す作業をスキルとして切り出し、チームで共有できる形にしていくことは、今すぐ始められる改善だと感じました。 3つ目は、チームへの働きかけです。ミーティングの進行や他チームとの相談の場面で、自分から場を作れるようになりたいと考えています。関係の質が土台にあるという第1回の話は、そのまま日々の仕事に持ち込めるものでした。 キャリアという長い時間軸で見ると、第3回の軸をずらして戦うという話が心に残っています。新卒の今は、複数の領域を掛け合わせられる場所に自分を置いていくための資産を積む時期なのだと考えています。 まとめ 全7回を終えて振り返ると、扱う領域は毎回まったく違っていたにもかかわらず、繰り返し語られていた話題があります。AIによって仕事がどう変わるのか、という問いです。 各回で語られていたのは、たとえば次のような話です。 職種の垣根は低くなり、1人が担える範囲は広がっていく エージェントに任せる範囲を決め、動く土台を整えることが仕事になる データが整っていなければAIは力を発揮できない 感覚ではなく事実を渡してはじめて、有効な答えが返ってくる それぞれ別の会社の、別のテーマの講義でしたが、いずれも同じ変化を違う角度から説明しているように聞こえました。 共通していたのは、AIが人の仕事を奪うという語り口ではなかったことです。むしろ、手を動かす部分をAIが担えるようになったからこそ、何を任せて何を自分で判断するのかを決める仕事の比重が増していくという見立てでした。新卒としては不安を覚えてもおかしくないテーマですが、研修を終えた今は、自分から動かせる余地の大きさのほうを強く感じています。 そしてもう1つ、この研修ならではの価値が、他社の同期と過ごす時間でした。同じ年に社会人となった人たちが、それぞれ違う環境で何を考えているのかを知ることができました。グループワークや懇親会で交わした会話は、講義とは別の刺激になりました。来年以降に参加する方にも、ぜひこの時間を楽しんでもらえたらと思います。 ZOZOでは、新卒・中途に限らず、一緒にサービスを作り上げてくれる方を募集中です。ご興味ある方は以下のリンクからぜひご応募ください。 corp.zozo.com *1 : 「ISUCON」は、さくらインターネット株式会社の商標または登録商標です。