Amazon Bedrock は、Anthropic や OpenAI をはじめとする主要モデルからオープンウェイトモデルまで、幅広いモデルの選択肢を提供しています。アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）は 2026 年 7 月 28 日、東京・赤坂インターシティコンファレンスにて「AWS Bedrock LLM Day Japan」を開催しました。AWS Summit New York City で発表された最新アップデートをいち早くお届けするとともに、Amazon Bedrock で実験段階から本番運用へとスケールしているお客様 5 社の事例、AWS パートナー各社によるソリューション紹介とデモ展示（パートナー Expo）を通じて、本番環境対応のソリューションへ進むための次のステップをお届けしました。 イベントは 2 部構成で、前半は全参加者向けに最新アップデートとお客様事例を、後半はサービス詳細を掘り下げる Tech Session と、パートナー企業様が生成 AI のビジネス価値を紹介する Business Session を 2 会場で並行開催しました。本記事では、その模様をレポートします。 開会のご挨拶 イベントの冒頭では、AWS ジャパン AIML 事業開発マネージャー 井形 健太郎が開会の挨拶を行い、本イベントの狙いと一日の流れを案内しました。 AWS Keynote と最新アップデート 基調講演には、WW Bedrock & AgentCore GTM Director の Eugene Kawamoto が登壇しました。AWS に 13 年以上在籍し、日本で最初のビジネス開発担当者として東京でキャリアをスタートした Eugene は、冒頭で本日の主題として「モデルの柔軟性」「高セキュリティなプラットフォーム」「エージェントの大規模な構築」の 3 領域を提示しました。 Amazon Bedrock は現在、世界中で 12.5 万を超えるお客様の生成 AI を支え、100 を超えるモデルをサポートしています。直近では本年 4 月の OpenAI との戦略的パートナーシップを受けて GPT-5.5 / GPT-5.4 / Codex が利用可能になり、Anthropic の次世代モデル Claude Fable 5 も一般提供が開始されました。最高水準のオープンウェイトモデルがフロンティアモデルに肩を並べつつある点にも触れています。 基盤面では、AWS PrivateLink による閉域接続と Zero Data Retention（データ非保持）の原則に加え、新しい推論プラットフォーム Project Mantle を紹介しました。障害時もオペレーターが環境にアクセスしない「ゼロオペレーターアクセス」、統合キャパシティプールによる高いデフォルトクォータ、東京を含むアジアパシフィック 4 リージョンでの稼働とリージョン特化エンドポイント、リクエストを 3 つの優先度レーンに割り当てるサービスティアが特長です。 エージェントについては「本番稼働は依然として難しい」と切り出しました。多くのチームがエージェントのロジックではなく認証やメモリ、ガバナンスの構築に何か月も費やしており、「エージェントが本番で動いていない 1 か月は、組織の勢いを積み上げられない 1 か月」だと述べました。これに応える Amazon Bedrock AgentCore では、直近 6 か月でエージェントの実行タスク数が 15 倍に増加。鍵となるのは「ハーネス」で、モデルが「脳」、AgentCore の各コンポーネントが「身体」だとすれば、その身体をうまく使う仕組みがハーネスにあたります。AWS Summit New York City で一般提供を開始した AgentCore harnessにより、数回の API 呼び出しでアイデアから本番まで数分に短縮できるようになりました。 最後のテーマは「データ、コンテキストがすべて」です。優秀な新入社員でも社内のプロセスを知らなければ活躍が難しいのと同じだと Eugene は説明しました。公開データについては Amazon の Web 検索を AgentCore の Web Search として、社内データについては取り込み・解析・検索をマネージドで担う Amazon Bedrock Managed Knowledge Base として提供（いずれも一般提供開始）。さらに構造化・非構造化を横断する AWS Context（近日提供予定）も紹介し、「今日の限界を、明日の境界として受け入れるな」という言葉で講演を締めくくりました。 お客様事例 続いて、Amazon Bedrock で生成 AI を本番運用へとスケールさせているお客様 5 社にご登壇いただきました。 日本電気株式会社 コーポレート IT AI プラットフォーム統括部 ディレクター 野口 忠則 氏は、「Anthropic 協業の舞台裏」として、Claude Cowork on Bedrock を 2 週間で本番構築した経緯を共有しました。AWS から Amazon Bedrock 経由でも利用可能になるとの情報提供を受けたのは、全社展開を決めていた 6 月 1 日のわずか 3 週間前。国内のデータ所在要件を満たせるのが Amazon Bedrock 経由だけであり、利用者が作成したスキル等を後から移行できないため、初日を逃すと切り替えが実質不可能になることが決断の理由でした。 最大の難所は、リリース 1 週間前の金曜夜に判明した MCP 経由のシステム間認可の不具合です。深夜まで調査しても自社メンバーだけでは解決できず、AWS サポートへ緊急扱いでエスカレーションし、土曜の朝から調査を開始。「6 月 1 日のリリースは無理だと思った」という状況から、担当営業と AWS 側エンジニアの全力支援で日曜夕方には原因を特定できたと振り返りました。接続先の SaaS が OAuth 2.0 / DCR に対応しているとは限らない点は、自社の認可中継サーバーで対応しています。 結果として、一般提供前のサービスの早期適用で 2 週間・12 万人規模の本番展開を完遂し、国内大手 IT ベンダー初の先行事例となりました。7 月 27 日時点の利用者は 9,700 名です。成功のポイントは、組織の後押しと許容、大規模システムを支える推進力、そしてリファレンスがない中でもベンダーとともに問題を 1 つずつ検証・改善する One Team 体制の 3 点でした。 丸紅株式会社 バリュークリエーションオフィス 事業成長支援課 芹川 武尊 氏（写真上）と Digital Experts 株式会社 仲吉 朝洋 氏（写真下）は、AgentCore runtime 上で本番運用している 2 つのエージェントを紹介しました。1 つは「VCO Agent」で、チャットに指示するだけで AI がコードの作成・実行まで行い、データ分析からドキュメント生成、定型業務のスキル化と共有までをプログラミング不要で現場の非エンジニアに届けます。総合商社では機密区分やアクセス権が業務ごとに異なるため、機密データを社外に出さず本人の権限の範囲内で処理することが前提条件でした。4 月 1 日の開発開始から 9 日で初回利用、16 週後には利用者 619 名・直近週 1,647 件・ユーザー作成スキル 285 個に達しています。 もう 1 つは、企業名を入力するだけで市場調査から情報収集・数値分析・レポート出力までを実行する競合分析エージェントです。1 社あたり数分 × 競合企業数のため全体で 1 時間弱かかることもあり、サーバーレスで最大 8 時間の連続実行を完走できることが採用の決め手になりました。いずれも AWS Lambda やコンテナ基盤と比較のうえ、セッションごとの microVM 割り当てと JWT / IAM の標準サポートを理由に AgentCore runtime を選定。「本番化の鍵は、モデルの選定より安全な実行環境の設計」というのが 2 つの運用から得た結論でした。 ファストドクター株式会社 オンライン本部 プロダクト部 部長 / リードアーキテクト 加藤 倫弘 氏は、医療事務 AI による自動化を「PoC から本番への筋道」として共有しました。1 件の診察は数十ステップが直列に処理されますが、AI を入れたのはそのうち 1 ステップだけ。医療証を見てどの公費制度かを特定する工程で、医療事務が 1 件 2〜5 分かけており、自治体ごとに様式も運用も異なるためルールベースでは最後まで解けなかった「難所」でした。実行基盤に AgentCore runtime、フレームワークに Strands Agents を採用し、書いたのは業務手順とツールだけだったためプロトタイプは 1 日で動いたといいます。 本番化のコツは 3 点。精度を上げるのは AI 以外の作り込みであること（前処理は決定的なコードでやり切り、マニュアル照合だけを AI に任せる）、出力の型を先に決めて確信度が低い案件は止めて人へ回す「間違えても大丈夫な構造」を先に作ること、そして評価とダークローンチを経て約 1 週間の全件チェックを挟んで本番運用に移す段階的なリリースです。「間違えない AI を作ろうとすると、永遠に本番に出せない。構造で受け止める」という考え方が根底にあります。 株式会社リクルート プロダクト開発統括室 プロダクトディベロップメント室 VP 片岡 歩 氏は、「Chat から Agent へ — その転換を、6000 人全員に」をテーマに、社員 1,500 名とパートナー 4,500 名の計 6,000 名にエージェント型 AI 環境を届ける共通基盤を紹介しました。Claude Code のランチャーから LiteLLM を経由し、Amazon Bedrock 上のクローズドモデルと自社 GPU サーバー上のオープンウェイトモデルの双方を扱える構成です。チャット型は現行の業務フローがベースのため生産性改善は 10〜20% ですが、エージェント型は業務プロセスそのものに編み込まれ、リードタイムを 1/10、1/20 に変える。だからこそ部分導入では効かず、「全員が使えることが必要条件」だと語りました。 課題は、パートナーや非エンジニアも含めて全員が使える環境をつくることと、想定外のトークン利用によるコスト爆発を防ぐことの、半ば矛盾した 2 つ。オープンウェイトモデルによるコストの固定費化と、LiteLLM で月間上限に達したら利用不可にする制御で対応し、勉強会や非エンジニア向け GUI ランチャーで利用を促進。登録ユーザー数は 3,000 人に達しました。AI-DLC を適用したある事例では 120 人月規模の案件を 3 名・20 営業日で完了し、コストで 97.5%、リードタイムで 84% の削減となっています。 jinjer 株式会社 プロダクト開発部 VPoT 玄 章夫 氏は、AgentCore を本番導入して直面した壁とその越え方を共有しました。分断されていた勤怠・休暇・人事労務のサービスを、チャットの共通窓口から横断利用できる AI アシスタントを開発。基盤を自前で作らずプロダクト開発に集中するため、Runtime・Memory・Identity・Observability を標準提供する AgentCore を選定し、自前構築見積り 2 か月に対して実績 1 か月と、約 1 か月の期間短縮を実現しました。 一方で 2 つの壁に直面します。1 つはパフォーマンスで、設定への知見不足からメモリ処理が想定以上に実行され、レスポンス遅延を招いていました。プロファイリングと TTFB 計測でボトルネックを特定し、メモリ書き込みを一括化することで書き込み時間を 70% 短縮。「マネージドサービスでも、設定や実行方式の理解が重要」というのが学びです。もう 1 つの LLM コストは、Strands Agents の採用、共通プロンプトのキャッシュ（入力トークンコストを 70% 削減）、小型モデルやルールベースへの振り分け、入出力サイズの最適化で対応。「LLM コストはモデル単価だけでは決まらない」として、システム全体での最適化が必要だと述べました。 後半セッション①：Tech Session Tech Session では、AWS のスペシャリストソリューションアーキテクトが最新モデル活用とエージェント構築基盤を解説しました。 AWS ジャパンの Sr. AI Specialist SA 石見 和也は「Claude on AWS」として、単に Amazon Bedrock で Claude が使えるという話を超え、多様なアーキテクチャパターンが立ち上がっていることを解説しました。AWS が提供する Claude のソリューションは、包括的な生成AIプラットフォームである Amazon Bedrock、Anthropic ネイティブな API 群を AWS の認証・監査・支払いと組み合わせて使える Claude Platform on AWS、ClaudeのEnterprise PlanをAWS Marketplace上での契約・支払いに集約する形の 3 つがあります。さらに、Claude Agent SDK を AgentCore runtime 上で動作させる方法や、Claude Platform on AWS経由でClaude Managed Agentsを利用しつつ、Lambda MicroVM 経由で AWS にアクセスする方法など、クラウド上でエージェントを長時間動作させる際のアーキテクチャも紹介しました。 AWS ジャパン Senior AI Solution Architect 菊田 遥平は、AWS が提供する OpenAI の最新アップデートを解説しました。Amazon Bedrock では GPT-5.4,5.5,5.6 と ChatGPT Work / Codex が利用可能になっており、GPT モデルは bedrock-mantle エンドポイント経由・Responses API 形式で提供されます。従来のモデルや API 形式とは Zero Data Retention に関わるサーバー側のデータ保持の仕組みが異なるので、利点と注意点について紹介しました。現時点では機能差分も存在し、テキスト出力のみであること、Cross Region Inference（CRIS）に未対応で US リージョンに限られること、コンテキスト長が 272K トークンであること（発表後に GPT-5.6 で 1M コンテキスト長に対応 https://aws.amazon.com/about-aws/whats-new/2026/08/gpt-sol-terra-luna-long-context-bedrock/ ）を説明しました。そのうえで、セキュリティやガバナンス、請求の統合、技術的なサポートといった AWS の利点に価値を感じるお客様には、ぜひ Amazon Bedrock 経由で OpenAI の機能を使ってほしいと呼びかけました。 AWS ジャパンの AI Specialist SA 鯨田 連也は、AWS Summit New York City で提起された「エージェントには適切なコンテキストが必要」「エージェントの構築自体が難しい」という 2 つの課題について、AgentCore がどのように解決するのかを、キーノートより一歩踏み込んで解説しました。前者のコンテキストの課題に対しては、Amazon Bedrock Managed Knowledge Base から、ユーザーごとに検索可能な文書を制御する ACL、ドキュメント種別を問わず自動でパースとチャンキングを行う Smart Parsing、複雑なクエリを分解して複数のナレッジベースを並列検索する Agentic Retrieve Stream API などの機能を紹介しました。あわせて、Amazon 独自の検索スタックにより Zero Data Egress で検索できる Web Search Tool on AgentCore も取り上げました。後者のエージェント構築の課題に対しては、モデル・ツール・スキル・メモリ・ファイルシステムを設定するだけで、ノーコードでエージェントを構築できる AgentCore harness の機能や利用方法について示しました。 後半セッション②： Business Session ビジネストラックでは「業務プロセス自動化」「業界特化型」「セキュリティ」という 3 つのテーマで構成され、それぞれのテーマで 3 社が異なるアプローチから同じ課題に挑みました。全登壇を貫いていたのは、「PoC で終わらせず、本番環境で安全に動かす」という一貫した問題意識です。コスト、工数、統制のそれぞれで定量的な効果が示され、生成 AI を「現場で使い続けられる形」にする実践知が共有されました。本ブログでは、テーマごとに登壇 3 社をまとめてご紹介します。 テーマ①：業務プロセス自動化 「AI エージェントで業務を自動化したいが、コストが読めない」「ノーコードで始めたいが品質が担保できない」「マルチエージェントは概念としては理解できるが、実際どう動くのか」 ―　本テーマでは、3 社がそれぞれ異なるアプローチでこの課題に回答しました。 KDDI アイレット 平野 健介 氏 サーバーワークス 久保 賢二 氏 ナレッジコミュニケーション 横内 俊宏 氏 トップバッターの KDDI アイレット は、企業や組織の AI 活用を促進する「AI Chat for Business」の運用知見をもとに、ID 定額モデルの固定費課題を実利用量のみ課金する トークン従量課金モデル で解決し、100 名以上の利用でコスト最大半額程度に低減できる可能性を提示。続く サーバーワークス は、Amazon Bedrock AgentCore の Agent Skills を活用した「Paperwork Agent」で、複雑な申請書様式を「教える」だけで作成時間を 20 分から 5 分へ約 75%削減 。締めくくりの ナレッジコミュニケーション は「AI は人で動かす」をテーマに、評価軸ごとにエージェントを分離した課題発見型のマルチ AI エージェント（ミルボン様事例）を、PoC 1 か月・実装 3 か月で立ち上げた実践知を共有しました。 テーマ②：業界特化型 建設と製造 ― 日本の基幹産業が抱える「人手不足」「属人化」「紙文化」に、AI エージェントはどう応えるのか。3 社がそれぞれの「現場」で実証した解決策を共有しました。 アジアクエスト 菊池 啓介 氏 シーイーシー（CEC） 青山 貴哉 氏 富士ソフト 吉田 祐史 氏 アジアクエスト は建設業界向けの 3 つの AI ソリューション（定型書類の自動作成、AI チャットによる BIM ソフト「Revit」操作、2D 図面の AI 3D モデル変換）で業界の DX を加速。 シーイーシー（CEC） は、FA/製造現場のドメイン知識を活かした設備保全 AI エージェントで、設備停止による 年間 4,500 万円規模の損失 に対し平均復旧時間 40%短縮を目標に属人化を解消。 富士ソフト は AI カメラ×Amazon Bedrock の「VisionAI Navi」で、Nova Lite （Claude 比約 1/8）/ Qwen3 VL （約 1/5）/ Claude Sonnet 5 を用途で使い分け、PoC 20 万円〜の低コストでコストと精度を両立します。 テーマ③：セキュリティ AI エージェントを PoC から本番に昇格させるとき、最大の壁は「セキュリティと統制」です。暴走、データ漏洩、監査不能 ― 本テーマでは、3 社がそれぞれ異なるレイヤーからこの課題に挑みました。 Aokumo Norihiro Takachi 氏 SCSK 渡辺 大介 氏 NRI（野村総合研究所） 北條 学男 氏 Aokumo は、J-SOX / FISC 環境で 1,200 以上の本番アクションを安全に実行する「Governed Execution OS」で、4 つの統制を「構造」として組み込み MTTR 73%削減 ・J-SOX 監査証跡を 3 分以内に出力（SBI グループ様で監査サイクルを数か月→18 日に短縮）。 SCSK は「本番投入、最悪のシナリオ」を防ぐ実行・統制・データの 3 層構成「Agentic AI プラットフォーム」を提示。 NRI （野村総合研究所） は、OWASP 脅威 17 項目の 71%が入出力監視だけでは検知困難と示し、プロアクティブ脆弱性診断とトレースログ分析基盤「AgentTrase」で内部を可視化する継続的な診断・監視を実現します。 クロージング クロージングは Tech Session と Business Session の 2 会場でそれぞれ行いました。 Tech Session では AWS ジャパン Sr. GTM Specialist AI/ML 樋口 亮太より、Business Session では AWS ジャパン Partner AI Specialist 井上　陽治より、AI 市場が 2030 年まで約 24 倍に成長すると言われる中で「導入した後、いかに価値を最大化するか」が本日のメインテーマであったと振り返りました。そして登壇内容から共通して見えてきた価値最大化の鍵として、モデルの柔軟性、セキュアなプラットフォーム、エージェントの構築の 3 点を挙げました。 次のステップとして、320 社以上のお客様にご参加いただいている「AWS ジャパン 生成 AI 実用化推進プログラム」を案内。あわせて、2026 年 8 月末に AWS ジャパン本社（麻布台ヒルズ）で開催予定の「生成 AI Frontier Meetup」を紹介しました。 パートナー Expo とネットワーキングの様子 セッション終了後は、ご登壇いただいたパートナー企業様の展示ブースで各社のソリューションを体験いただけるパートナー Expo とネットワーキングを実施しました。軽食・ドリンクをご用意し、休憩時間も含めて参加者とパートナー、AWS メンバーが自由に交流できる場としました。会場では各ブースを巡る「ブーススタンプラリー」も実施し、多くの参加者にパートナー各社のデモをご覧いただきました。AWS のメンバーも待機し、セッションの内容や個別の技術相談にその場でお答えしました。 おわりに 本イベントでは、最新のサービスアップデートから、本番運用へとスケールさせているお客様の事例、パートナー各社が現場で積み上げた実装と統制の知見までを一日でお届けしました。共通して見えてきたのは、生成 AI の議論の焦点が「何ができるか」から「どう本番で動かし続けるか」へ移っているということです。AWS ジャパンは、今後もモデルの選択肢とエージェント構築基盤の拡充、そして技術支援を通じて、お客様の生成 AI の本番活用と価値創出に貢献してまいります。 イベント当日投影いたしました、資料はこちらよりダウンロードいただけます。 AWS より投影の資料： AWS Bedrock LLM Day Japan AWS セッション資料 パートナー企業様より投影の資料： AWS Bedrock LLM Day Japan Partner Session

こんにちは！ LIFULLのマーケット横断部署でエンジニアリングマネジャーをしている吉永です。 本日は、エンジニアもサービス改善の施策を提案しやすくするために、生成AIへ調査手順や参照する情報、出力形式をまとめた、再利用可能な指示書を作った取り組みについて紹介します。 ※本記事では、この指示書を「施策提案スキル」と呼びます。 生成AIを活用してチームの企画力を広げたい方や、AIに施策案を出してもらっても一般論にとどまりがちだと感じている方の参考になれば幸いです。 取り組みを始めた背景 施策提案スキルで実現したこと 2つの使い方と、その結果 私のアプローチ: データから課題と施策を探す チームのエンジニアのアプローチ: アイデアの確からしさをAIで補強する 結果の違いから見えたドメイン知識の価値 次に取り組みたいこと 最後に 取り組みを始めた背景 実際にチームへ展開すると、2つのケースで結果に違いが出ました。一つは、私が生成AIに現状分析から施策案の作成までを任せたケースです。もう一つは、長くサービス開発に携わってきたエンジニアが自分のアイデアを生成AIで補強したケースです。 この経験から、生成AIに施策を考えてもらう際に、プロンプトやデータ分析と同じくらい大切だと感じたものがあります。それが、人が持っているドメイン知識です。 ※ここでいうドメイン知識とは、サービスの仕様やユーザー理解、過去施策の経緯など、担当業務を通じて蓄積される知識や経験のことです。 私たちのチームでは、サービス改善を企画するメンバーがSEOやCRO（Conversion Rate Optimization、コンバージョン率最適化）など、複数領域の施策を並行して担当していました。 継続的に改善を進める一方で、施策の選択肢を出し続けることには難しさがあります。特に当時は、チーム目標と現状のギャップを埋めるプランを早急に立て、実行へ移す必要がありました。 そこで考えたのが、エンジニアも施策提案に参加しやすい環境を作ることです。 エンジニアは、日々の開発を通じてサービスの仕様、データ構造、技術的な制約、ユーザー体験上の違和感に触れています。ただし、気付きを企画として説明するには、現状の数値、期待効果、過去施策との差分、A/Bテストの設計などをそろえる必要があります。アイデアはあっても、提案書へ落とし込むまでのハードルが高い状態でした。 このハードルを生成AIで下げられないかと考え、過去の不動産情報を提供するアーカイブサイトの課題抽出から改善提案までを支援するスキルを作成しました。 スキルを作成した後は、企画担当者のタスクが多く、施策を十分に検討する時間を確保しにくい一方で、チーム目標とのギャップを埋める必要があるという現状をエンジニアへ共有しました。そのうえで、「こんなスキルを作ってみたので、試しに使ってみませんか。みんなで施策案を出してみましょう」と声をかけました。 完成した仕組みを渡すだけではなく、なぜ今エンジニアからも施策案を出したいのかを伝えたことで、チームの課題を自分ごととしてとらえてもらえたと思います。 施策提案スキルで実現したこと 初版のスキルでは、生成AIに「施策を考えて」と依頼するだけではなく、施策提案に必要な調査と整理を一定の手順で進められるようにしました。 当初扱っていたのは、主に次の情報です。 行動データから、ページ閲覧や導線の利用状況を確認する ソースコードを読み、現在の仕様や実現可能性を確認する 課題、仮説、対象ユーザー、期待効果、リスクを整理する A/Bテストの指標と判断基準を含む、施策仕様書のたたき台を作る 初版で特に意識したのは、推測と事実を混ぜないことです。仮説を立てたらデータで確認し、確認できないものは仮説として残すようにしました。また、施策の魅力だけではなく、対象となるユーザーの規模、実装コスト、既存機能への影響まで整理するようにしていました。 これにより、エンジニアは自分の気付きやアイデアを入力し、企画担当者が優先度や実施可否を検討できる内容まで具体化しやすくなりました。 一方、実際に使ってみると、過去の類似施策や足元のチーム目標とのつながりまで十分に確認できないケースがありました。この点は、後述する施策案の比較を通じて見えてきた課題です。 そこで現在のスキルには、次の観点を追加しています。 関連する過去施策とA/Bテスト結果を確認し、同じ失敗を繰り返さない 足元のチーム目標や中間指標と、施策が動かす指標のつながりを確認する 「なぜ行うか」「何を変えるか」「誰に届けるか」を整理し、提案の優先理由を明確にする スキルも一度作って終わりではなく、実際の提案結果から得た学びを取り込みながら更新しています。 2つの使い方と、その結果 スキルを使って、私とチームのエンジニアがそれぞれ施策案を作りました。興味深かったのは、同じスキルを使っていても、生成AIへの入り口が異なっていたことです。 私のアプローチ チームのエンジニアのアプローチ 出発点 まず行動データを分析する 日々感じていた改善アイデアを入力する 生成AIの役割 数値から課題を抽出し、施策案を広く作る アイデアの確からしさをデータや過去事例で検証する 人が主に提供したもの 分析対象と目標 仮説、ユーザー理解、実装経験、過去施策の記憶 結果 複数の案を作ったが、実施候補には選ばれなかった 2件が実施候補に選ばれ、いずれもA/Bテストでエンジニアが提案したBパターンが既存パターンを上回り、採用された 私のアプローチ: データから課題と施策を探す 私は、行動分析ツールのデータから現状を把握し、課題を抽出したうえで改善案を作るところまで生成AIに依頼しました。 生成AIは、複数のデータや実装を横断し、短時間で施策候補を並べることには向いていました。施策ごとの期待効果や実装コストも整理できたため、検討材料を増やすという点では役立ちました。 一方で、作成した案は実施には至りませんでした。 実施に至らなかったのは、案そのものが成立していなかったためではありません。中には、過去に類似施策を実施し、A/Bテストで新しいパターンが既存パターンを下回っていた案もありました。また、足元で改善したい指標へ直接つながらず、優先度が下がった案もありました。 データから一見妥当に見える改善余地を見つけるだけでは、今その施策を選ぶ理由として十分ではありません。過去の失敗を踏まえて再挑戦するなら何を変えるのか、現在の目標に対してどの指標を動かすのかまでつながって、初めて実行候補になります。初版のスキルには、その判断に必要な文脈を確認する仕組みが不足していました。この経験が、過去施策の結果と足元の目標指標を確認する現在の形へ更新するきっかけになりました。 チームのエンジニアのアプローチ: アイデアの確からしさをAIで補強する 今回施策を提案したのは、長年アーカイブサイトのフロントエンド開発に携わっているチームメンバーです。 開発を通じて、過去にどのような施策を実施し、何がうまくいかなかったかを知っています。さらに、普段の開発やサービス利用の中で感じていた改善アイデアも持っていました。 今回は、そうした経験から生まれたアイデアを生成AIに入力し、関連する行動データや過去施策を調べてもらうことで、仮説の確からしさを補強しました。つまり、AIにゼロから施策を発明してもらうのではなく、自分の中にある仮説を検証し、企画として説明できる形へ整えるために使ったのです。 その中から2件が実施候補に選ばれました。どちらのA/Bテストでも、エンジニア提案のBパターンが既存パターンを上回り、採用されました。エンジニアのアイデアが提案で終わらず、検証と本実装まで進んだことは大きな成果でした。 結果の違いから見えたドメイン知識の価値 この結果だけで、データ起点のアプローチが悪く、アイデア起点のアプローチが常に正しいとは言えません。試した施策の性質や優先順位も異なるため、単純な比較はできないと思います。 それでも、今回の経験から強く感じたのは、生成AIは入力された情報を増幅する存在だということです。 チームのエンジニアが入力したのは、施策のアイデアだけではありません。その背景には、長年の開発で蓄積した次のような情報がありました。 ユーザーが画面上で迷いやすい箇所 過去に試した施策と、その成否だけでは表せない学び データやコードがその形になっている理由 実装コストや既存機能への影響に関する感覚 日々の開発で感じていた、小さな違和感や改善の余地 これらは、データベースやドキュメントを検索するだけでは、すべてを取得できるとは限りません。人の中にある経験知と、生成AIが集められるデータや実装情報が組み合わさったことで、提案の説得力が増したのだと思います。 生成AIによって、調査や資料化のコストは大きく下げられます。一方で、調べる対象や深掘りする違和感を選び、結果を業務の文脈で解釈するには、引き続きドメイン知識が必要です。 生成AIの急速な高度化に伴い、人間の業務を支援・代替する場面も増えています。私自身、これから人の役割はどう変わっていくのだろうと考えていました。 しかし、今回の2施策では、エンジニア提案のBパターンが既存パターンを上回りました。その結果を見て、ドメイン知識を持つ人の役割はまだまだ大きいと感じました。AIが十分なデータへアクセスできても、最初に渡す問いや仮説の質、その結果を業務の文脈で解釈する力によって、得られる成果は変わります。 人間にしか担えない領域はまだあります。生成AIが発達しても、担当するサービスや業務への理解を深める重要性は変わらないと思います。むしろ、生成AIが知識やアイデアを増幅できるようになったことで、入力となるドメイン知識の価値がさらに高まるのではないかと感じています。 次に取り組みたいこと 今回のスキルには、行動データ、ソースコード、計測仕様、過去の施策資料など、すでに言語化されている情報を参照できるようにしました。 次の課題は、人だけが持っている情報を、生成AIが利用しやすい形に整えることです。 たとえば、次のような情報を継続的に残せると、施策提案の質をさらに高められると考えています。 施策を実施した事実だけでなく、当時の仮説と判断理由 A/Bテストで勝った理由、負けた理由についての振り返り 見送った案と、見送った時点の制約 開発や問い合わせ対応で感じたユーザー体験上の違和感 サービス固有の用語、データの定義、実装上の制約 ただし、すべてを無制限にAIへ渡せばよいわけではありません。情報の公開範囲、個人情報や機密情報の取り扱い、古くなった知識の更新方法、AIが参照した根拠を追える状態も合わせて設計する必要があります。 最終的には、職種に関係なく、誰でも気軽に質の高い施策提案ができる状態を目指しています。人のアイデアと経験を起点に、生成AIが調査、検証、具体化を支援する。その積み重ねによって、企画担当者の負荷を分散するだけでなく、チーム全体でサービスを良くする文化につなげていきたいと思います。 最後に 今回の取り組みを通じて、生成AIが得意なことと、人が持つ知識の価値をあらためて考えることができました。 生成AIに施策案を作ってもらう際は、いきなり「改善案を出して」と依頼するのではなく、まずチームが持っている仮説や過去の経験を入力できないか考えてみると、結果が変わるかもしれません。 チームで生成AIを使った施策提案に取り組む方の参考になれば幸いです。最後まで読んでいただきありがとうございました！ 最後に、LIFULLではともに挑戦していける仲間を募集しています。ご興味をお持ちいただけましたら、ぜひ以下のページもご覧ください。 hrmos.co hrmos.co

! この記事で使うもの Claude Code — Anthropic社が提供するターミナル上で動くAIコーディングアシスタント。チャット形式でファイル操作・コード生成・分析などができる カスタムエージェント — Claude Codeに「専門家の人格」を与える仕組み。Markdownファイル1つで、名前・得意分野・使えるツール・AIモデルを定義できる この記事では、このカスタムエージェントを10体作って「仮想チーム」にした話をする QAチームが1人しかいない問題 自分はビットキーでソフトウェア品質戦略を担当している。品質データの分析、Qase[1]の運用設計、ダッシュボー