2026年7月の主な製品アップデートをご紹介します。 製品アップデート インスタンス画面の改善により、テスト実行をさらに迅速に インスタンスに関する重要な情報へすばやくアクセスできるよう、インスタンス画面のレイアウトを刷新しました。 プラットフォーム全体のデザインに合わせて、「Linked Runs」は画面左上に表示されるようになり、主要なインスタンス情報は右側に整理されています。これにより、より効率的で一貫性のある操作が可能になりました。 また、実行ボタンを画面の上部と下部の両方に配置しました。ページ内を移動する手間が減り、これまで以上にスムーズにテストを開始できます。 AIを活用したテストを支援するMCPアクションを追加 PractiTest MCPに新たなアクションを追加し、AIアシスタントを活用して日常的なテスト業務をさらに幅広く進められるようになりました。 新たに利用できる機能は以下のとおりです。 ・AIアシスタントを通じて、APIタイプのテストをPractiTest上に直接作成できます。 ・AIとの会話画面を離れることなく、既存のインスタンスに対するテスト実行を作成し、その実行結果を記録できます。 詳しくは、 MCPのドキュメント をご覧ください。 今後の予定 PractiTestライブトレーニング カスタマーサクセスチームによるライブトレーニングを開催します。PractiTestについて知りたいことを、ぜひこの機会にご質問ください。 ヨーロッパ： 8月19日（水）14:00 CEST 北米： 8月19日（水）14:00 EDT／11:00 PDT アジア太平洋地域： 8月19日（水）12:30 AWST ライブトレーニングに申し込む PractiTestの最新情報とその先へ AIによるテスト生成の次に求められるもの テストケース、スクリプト、要約、バグレポートの生成など、AIを活用した機能は、急速に多くのテスト管理プラットフォームで標準的なものになりつつあります。 現在、ツールの真の差別化要因は、AI機能を搭載しているかどうかではありません。テストに関する背景情報や状況をどのように活用し、より適切な意思決定を支援できるか、リスクを軽減できるか、そしてチームの働き方を改善できるかが重要です。 ブログ記事を読む 合格率は90％。それでもリリースに自信を持てますか？ QAチームが扱うテストデータは、これまで以上に増えています。しかし、リリースの可否を判断するには、それらのデータからリスクと準備状況を明確に把握しなければなりません。 従来の指標だけでは十分な判断が難しい理由と、QAリーダーが自信を持ってリリースを決定するために重視すべきポイントをご紹介します。 ブログ記事を読む ※ PractiTest公式HP より翻訳

2026年7月15日、オンラインイベント「RAKUS AI Conference 2026 Summer」を開催しました。本記事では、その中の1セッション「顧客の声から生まれた『AI返信補助機能』の開発プロセス」（登壇：楽楽自動応対AI開発課 四方大輔さん・今井陸斗さん）の内容を、技術広報がレポート形式でまとめます。 「作ったのに使われないAI機能」、心当たりはありませんか 半年間、精度を上げ続けてもお客様の声は変わらなかった 顧客に直接聞いて分かった、担当者が本当に困っていたこと 「メール作成AI」から「メールアシスタント」への方向転換 ドキュメントではなく「動くもの」でお客様と議論する あった方がいいはずの機能が、実は「邪魔」だった AIプロダクト開発で大切な3つのこと エンジニアの仕事は「実装する」から「お客様を理解する」へ speakerdeck.com 「作ったのに使われないAI機能」、心当たりはありませんか AI機能をリリースしたものの、思ったほど使ってもらえない。精度を上げても上げても、現場からの評判は変わらない。AIプロダクト開発に携わるエンジニアであれば、一度はこうした壁にぶつかったことがあるのではないでしょうか。 今回紹介するのは、楽楽自動応対開発チームが、まさにこの壁にぶつかり、そこから立て直していった実例です。結論を先に言ってしまうと、このチームが学んだのは以下の3点でした。 お客様の業務フローを知らずに機能を作ると、使われない機能ができあがる AIで動くPoC（試作品）を即座に作り、ドキュメントではなく「動くもの」で議論する 機能の要・不要を決める「正解」は、現場のお客様だけが知っている この3点は楽楽自動応対に限った話ではなく、AIを使ったプロダクト開発に取り組むエンジニアなら誰でも実践できる考え方だと感じています。以下、実際に何が起きたのかを時系列で見ていきます。 半年間、精度を上げ続けてもお客様の声は変わらなかった 楽楽自動応対は、問い合わせメールをチームで一元管理し、過去の対応履歴を資産として活用しながら応対業務を効率化するクラウドサービスです。主にカスタマーサポートなど、メールを多く扱う現場の担当者に利用されています。 2025年10月、このサービスに「メール作成AIエージェント機能」がリリースされました。受信メールを読み取り、過去の類似の問い合わせを参照しながら、AIが返信文案を自動生成するという機能です。リリース前には精度検証を行い、ビジネスサイドと「使い物になる」ラインをすり合わせた上での公開でした。 ところが、リリース後の利用率は思っていたほど上がりませんでした。ビジネスサイド経由で聞こえてくるお客様の声は「精度が悪い」「使えない」「手で書いた方が早い」というものが多く、なかなか厳しい現実に向き合うことになったといいます。 当時は本番環境でAIがどう振る舞っているかを継続的に追う仕組みが整っておらず、プロンプトの改善やロジックの見直し、モデルの切り替えといった、いわば小手先の精度改善を重ねる日々が続きました。しかし、それでも「使えない」という声は減らず、気づけば半年が経過していたそうです。 顧客に直接聞いて分かった、担当者が本当に困っていたこと 根本的に改善するには、まず現場で今何が起きているかを知る必要がある。そう考えたチームが取った行動は、素直にお客様に話を聞きに行くことでした。 登壇した四方さんは楽楽自動応対の開発を10年近く担当しており、当初はドメイン知識も顧客理解も十分にあるつもりだったといいます。しかし実際にお客様の声を聞く中で、「お客様が実際にどうメール応対業務を行っているか」を全く理解できていなかったことを痛感したそうです。 具体的に見えてきたのは、次のような実態でした。メールの応対業務は一般的にいくつかの工程からなるフローで進みますが、AIが担当するようになったのは「作成」の工程だけでした。AIが作った文面をそのまま使うかというと、多くの担当者はやはり信用しきれず、必ず内容を確認します。つまり、AIで作成を楽にしたつもりが、確認という新たな手間を生み、かえって担当者の負荷を上げてしまっていたのです。 さらに、メール応対はいわゆるフロントオフィス業務であり、メールの品質がそのまま顧客体験の品質に直結します。だからこそ「AIに丸投げする」という発想自体が、現場の感覚とズレていたことも見えてきました。同時期に行われた市場調査でも同様の声が上がっており、「メールを自動生成する」という機能の前提そのものが、お客様に求められていなかったのではという疑いが確信に変わっていったといいます。 「AI活用やAIエージェントというのは、突き詰めればお客様の業務をAIに置き換えることだと考えていたはずなのに、その当たり前ができていなかった」と四方さんは振り返ります。 「メール作成AI」から「メールアシスタント」への方向転換 信用してもらえないという声に応えるため、チームはAIが本文をいきなり自動生成するのではなく、返信を組み立てるための材料を提示する方向へと舵を切りました。コーディングエージェントの「プランモード」に近い発想です。 具体的には、メールの内容を読み取って要点を示したり、類似の過去問い合わせを探したり、大量にあるテンプレートの中から適したものを提案したりと、担当者の作業そのものをAIが肩代わりするのではなく、担当者の判断をAIがサポートする形へと機能を再設計していきました。 とはいえ、AIプロダクト開発において「何を作れば使われるか」が最初から明確なケースは多くありません。「ざっくり楽にしたい」「なんとなく自動化したい」といった、ふわっとした要望から出発することがほとんどだと四方さんは言います。このメールアシスタント機能への転換時も、必要な機能は何か、情報を見せすぎるとかえって読まれなくなるのではないか、といった議論が社内で白熱したそうです。 最終的にたどり着いたのは「正解はお客様に聞くしかない」という発想でした。そして、その正解に最速でたどり着くために取ったアプローチが、後半で紹介する開発プロセスの変革です。 ドキュメントではなく「動くもの」でお客様と議論する 後半のセッションを担当した今井さんは、開発プロセスそのものの変革について紹介しました。 これまでの開発は、ビジネスサイドが要求資料を作成し、それに沿って開発側が要件をすり合わせ、仕様が固まってから実装するという進め方でした。この方法では、実装が完了するまで実際の動きが見えづらく、デザインモックだけでは確認しきれない部分が残ります。結果として、実装後にビジネスサイドへ触ってもらって初めて「なんとなく違う」というフィードバックが出て、手戻りが発生することも少なくありませんでした。 そこで今回は、最初から動くものを仮で作る「PoCファースト」のアプローチを取ったといいます。これを可能にしたのは、AIの進歩によってコーディングの大部分を指示ベースで任せられるようになったことが大きいと今井さんは説明します。PoCの作成にはClaude Codeを活用し、あくまで仮の実装であることを前提に、保守性やコードの綺麗さよりもスピードを優先する、いわゆるバイブコーディングで進めたそうです。 さらに、ビジネスサイドとの検討で「必要かもしれない」と挙がった機能は取捨選択せず、いったんすべてPoCに盛り込みました。実装のほとんどをAIに任せられるため、機能数が多少増えても実装コストがそこまで膨らまない、という判断があったからこそ取れた選択です。 そして重要なのは、このPoCをビジネスサイドだけでなく、実際に機能を使うことになるお客様にも直接見せたという点です。「不要かもしれない」という機能が本当に不要かどうかは、社内の議論だけでは決められません。現場を知るお客様に判断してもらうのが最も確実だと考えたからです。 あった方がいいはずの機能が、実は「邪魔」だった 実際にお客様へPoCを見せた結果は、チームの想定とは異なるものでした。 当初、メールアシスタント機能にはメール本文の要約や、質問に対する回答方針の提示など、返信に役立つと思われる機能を一通り盛り込んでいました。しかしお客様に見せてみると、要約や回答方針があってもAIの回答が100%正しいとは限らないため、結局は本文や過去のやり取りを自分の目で確認する必要があり、時短にはつながらないという意見が返ってきました。「あった方がいい」と思っていた機能が、実際には「邪魔」だった、という気づきです。 一方で、返信に使うテンプレートの提案機能や、作成した本文に対する添削機能は「使える」という評価を得られました。 ターゲットについても発見がありました。当初は返信業務を行うユーザー全員を対象に機能を検討していましたが、経験豊富なベテラン担当者にとっては、AIが出してくる情報を追加で確認する手間がむしろノイズになってしまうという声が上がりました。一方、メール作成に不慣れな新人担当者にとっては、テンプレートを探す時間や、作成したメールを先輩に確認してもらう時間を減らせるという利点が明確でした。この結果を踏まえ、ターゲットは「全ユーザー」から「新人担当者」へと絞り込まれました。 お客様と実際に対話し、業務フローを理解できたからこそ、このようにターゲットを変える判断ができたと今井さんは振り返ります。 AIプロダクト開発で大切な3つのこと 今井さんは、今回の経験から見えてきた学びを、楽楽自動応対に限らずどのようなエンジニアでも実践できるものとして、3点に整理していました。 1. お客様の業務フローを知ること 作ろうとしている機能がどう使われるかを知らずに開発すると、使われない機能ができあがる可能性が高くなります。無駄な機能を作らないためには、まずエンジニア自身がお客様の業務を把握することが欠かせません。 2. AIを使って動くPoCを即座に作ること ドキュメントや文章ベースで議論するよりも、実際に動くものを見ながら議論した方が認識のずれが生まれにくく、圧倒的に効率的です。この段階では機能を絞り込まず、思いつくものはすべて載せて、いったん全体を見える状態にしてから議論することが有効だといいます。 3. できあがったPoCを、実際に使うお客様に見てもらうこと 機能が使えるか使えないかの「正解」を持っているのは、現場を知るお客様です。答えのない状態でビジネスサイドと開発側だけで議論するのではなく、正解を知っているお客様に判断してもらう。この段階で不要な機能を見極めておけば、リリース後の手戻りも減らせます。 エンジニアの仕事は「実装する」から「お客様を理解する」へ 今回の事例のポイントは、開発プロセスを変えたことで開発スピードが上がった、という話に留まりません。AIに実装を任せることで生まれた余白の時間を、お客様と向き合う時間に転換できたことこそが本質だと今井さんは強調していました。 お客様と対話することで、実際に機能が使われる場面への解像度が上がり、より良い機能開発につながります。しかも一度きりではなく、機能をブラッシュアップするたびに繰り返し対話することで、方向性が合っているかを都度確認できるようになったといいます。お客様の業務フロー理解とフィードバックの解消をエンジニア自身が担うことで、エンジニアの仕事は「機能を実装するもの」から「機能を考えるもの」へと、上流にシフトしつつあると感じている、というのが今回のセッションの結びでした。 ラクスが大切にしている「顧客志向」という価値観と、AIによって実装のスピードが上がった「AIネイティブ」な開発とが組み合わさることで、お客様への価値提供を最大化できるようになった。これは楽楽自動応対チームに限った話ではなく、AIプロダクト開発に取り組むすべてのエンジニアにとって参考になる視点ではないかと感じています。 rakus.connpass.com 「RAKUS AI Conference 2026 Summer」の他レポート記事 ・ AIを載せることはゴールではない。ラクスCTOと開発副本部長が語った、組織とプロダクトの変革 ・ 楽楽精算AIエージェントを支える、LLMOpsとインフラの選択肢 ・ 仕様駆動開発、導入半年。「本当に速くなってるの?」にデータで答える

2026年7月15日、ラクスは自社イベント「RAKUS AI Conference 2026 Summer」を開催しました。オープニングは、CTO 兼 開発本部長の「公手 真之」と、執行役員 兼 開発本部 副本部長の「矢成 行雄」による2つのセッションです。 一方は「AIネイティブな開発組織をどう作るか」という組織の話。もう一方は「複数のプロダクトにAIをどう実装するか」というプロダクトの話。扱う対象は違いますが、2人が最後に置いた結論は同じでした。AIを載せること自体はゴールではない、というものです。 「SaaS is dead?」にどう答えるか 組織の話：ツールを導入すれば、AI駆動開発は進むのか 「導入すれば自然に進む」という前提 現場の好感触と、伸びない実数 サーベイで「現在地」を可視化する 浸透を止めていた要因と、「強制力」への転換 セッションの結論 プロダクトの話：ユーザーは「正答率」を求めているのか 複数プロダクトで顧客業務を支える 3つのプロダクトの実装例 「正答率」：ユーザーが本当に求めていたもの 「縦の壁」と「横の壁」、そして専門組織 現在地 2つのセッションが指していた同じ方向 おわりに 「SaaS is dead?」にどう答えるか 2人とも、話の入り口はクラウドサービス業界の現状に置いていました。 競合がひしめくレッドオーシャンで、新規の「白地」と他社からの乗り換えを奪い合う。そんな状況を背景に、近年は「SaaS is dead?（クラウドサービスはもう役割を終えるのではないか）」という論調も出てきています。 これに対する2人の答えは、「dead?」ではなく「 SaaS is evolving 」でした。クラウドサービスは終わらず、むしろ進化する。AIはクラウドを置き換えるものではなく、これまで届けてきた価値をもう一段引き上げるものだ、という立場です。 矢成はここに補足を加えました。ラクスはすでに、System of Record に蓄積した信頼できるデータと、それを動かす業務ワークフローを持っている。その土台の上にAIが乗るからこそ価値が出る。「データ・ワークフロー・AI」がそろってはじめて意味を持つ、という整理です。そして「価値そのものだけでなく、それを届けるスピードが競争力になる」という現状認識は、2人に共通していました。 同じ現状認識から出発しながら、公手は「組織をどう変えるか」を、矢成は「プロダクトに何をどう実装するか」を語りました。 組織の話：ツールを導入すれば、AI駆動開発は進むのか 公手のセッションは「複数プロダクト組織のAIネイティブ化における戦略」。冒頭で「ここから先は、少し泥くさい話になります」と断ったとおり、成功事例の紹介ではなく、うまくいかなかった過程の共有でした。 「導入すれば自然に進む」という前提 ラクスは生成AIを早い段階から取り入れてきました。2022年秋には GitHub Copilot を使い始めるメンバーが現れ、2023年4月に全面導入。その後も Cursor、Devin、Claude Code を、現場の判断で比較的自由に導入しています。ツールが先行したぶん、ガイドラインやセキュリティ対策も早めに整えられました。 開発組織は国内が約350人、海外が約100人。各チームは技術スタックも開発拠点も異なり、それぞれが顧客志向のもとで最適なやり方を選び、成果を出してきました。その実績があったからこそ、「優秀な現場にAIツールを渡せば、良い使い方を見つけてAI駆動開発は自然に進むだろう」という前提が置かれていた、と公手は振り返ります。 結果は、その前提どおりにはなりませんでした。 現場の好感触と、伸びない実数 導入後、現場からはインパクトのある報告が上がってきました。あるプロジェクトではコードの95%を生成AIが実装。SPEC駆動開発（SDD）で開発工数を50%削減、E2Eテスト自動化でテスト工数を30%削減、調査コストを25%削減、海外チームとのリードタイムも30%削減。体感面でも「実装が楽になった」「PoCや新機能開発は確実に速くなった」「学習が速くなった」といった声が目立ちました。 一方で、同じ現場から別の声も上がっています。「AIならではの手戻りが発生する」「レビューが重く、品質確認の負荷はむしろ増えた」。ビジネス側からは「開発が明らかに速くなった」という実感が返ってこず、エンジニアに聞いてもリリースが速くなった手応えは曖昧でした。 そこで公手たちは、体感ではなく実数を確認します。全面導入の前後で、リリース回数と新機能の数がどう変化したかを計測したところ、期待したほどには伸びていませんでした（なお公手は、この数値について「機能の規模は無視した参考値」と限界を明示していました）。 ここから導かれた学びは明快です。実装フェーズは確かに楽になった。しかし、その前後の工程やプロセス全体が変わらなければ、価値提供のスピードは上がらない。従来のプロセスにAIツールを足すだけでは、成果には届かないということです。 サーベイで「現在地」を可視化する 次の打ち手は、現状の可視化でした。ラクスには開発者体験の向上をミッションに掲げる技術チームがあり、そのチームが「AI駆動開発がどこまで浸透しているか」を測るサーベイを作成します。開発チームごと・開発工程ごとに、世の中の最新のAI活用事例をベンチマークとして自己評価し、成熟度をスコアリングする仕組みです。 結果として、チーム間のばらつきの大きさが見えてきました。実装フェーズのAI活用は進む一方で、テストやレビューはほぼ手つかず。そして、開発速度が改善しているチームほど、実装以外の工程でもAIを使い、SPEC駆動開発を取り入れている、という相関が確認できました。 浸透を止めていた要因と、「強制力」への転換 ヒアリングからは、浸透を止めている共通の要因が見えてきます。 コスト意識が高いため、効果が見えるまで新しいツールの導入判断に時間がかかる AI活用の「目指す姿」が見えにくく、学習コストを踏まえると日々の開発が優先される チームをリードする推進役が不足し、良い使い方がチーム全体に広がらない これを受けて、公手たちは方針を大きく変えます。これまでのラクスは「各チームの自律的な最適化」で成果を出してきましたが、それに任せるだけでは組織全体としては思うように浸透しない。そこで今期は、組織として明確な方向性を示し、強制力を持って進める方針に踏み込みました。上記の各要因には、それぞれ次の打ち手が当てられています。 各チームごとの効果検証を待たない： 生産性向上がはっきりしていた Claude Code を全面導入し、それを前提とした SPEC駆動開発を、ベトナムやインドネシアの開発拠点も含めて全面展開する 「AI駆動開発 実践カタログ」を整備する： AIネイティブ開発で実践すべき約20項目を職種ごとに定義し、「どこまでやれば実践できていると言えるか」まで明文化する。ガイドラインにとどめず「組織として目指す姿」の共通言語とし、開発マネージャーの目標にも組み込む 推進役を置き、外から支援する： 勉強会や情報共有会、社内イベント、社内報・社内ラジオでの紹介、表彰制度、他チームの有識者による Enabling を用意し、成功事例とノウハウが横に流れる環境を整える 「各チームの自律に任せる」文化を大切にしてきた組織が、あえて「強制力」に舵を切る。公手は、その難しさも含めて率直に語っていました。 セッションの結論 締めくくりで、公手はこう述べました。AIネイティブ開発組織への変革のゴールは、AI駆動開発を浸透させること自体ではない。顧客価値と事業価値を、これまで以上のスピードと品質で生み出すことだ、と。AIの登場から約4年、ラクスの本格的なAIネイティブな開発づくりは動き出したばかりで、「正解はまだ見えにくいが、試行錯誤しながら一歩ずつ進んでいく」と結びました。 プロダクトの話：ユーザーは「正答率」を求めているのか 続く矢成のセッションは「複数プロダクトで進めるAI機能実装 実践から得たリアルな学びとロードマップ実現への挑戦」。組織の話をプロダクトの現場に引き継ぐ内容で、こちらも「うまくいった話」より「ぶつかった話」が中心でした。 矢成はセッションを貫く問いを立てます。AIがコモディティ化する時代に勝負を分けるものは何か。ユーザーは本当に「正答率」を求めているのか。複数プロダクトの同時並行開発の成否は、何によって分かれたのか。 複数プロダクトで顧客業務を支える ラクスの特徴は、単一プロダクトではなく、顧客業務を支える複数のプロダクトを持っていることです。受注・見積・契約といった販売管理、経費精算や仕訳、問い合わせ応対やFAQといったカスタマーサポート。これらが組み合わさることで、販売から経費、サポートまで、顧客の業務がひとつながりで支えられます。矢成はこれを、点ではなく「面で支える」と表現しました。 そこでラクスが選んだのは、複数のプロダクトへ同時並行でAIを実装する道です。一つに絞って局所最適する方法は取りませんでした。矢成が繰り返し強調したのは、「顧客提供価値の向上につながらないAI実装に意味はない」という前提です。流行っているから載せる、載せること自体が目的になる。それを避けることが出発点でした。 3つのプロダクトの実装例 具体例として、3つのプロダクトが紹介されました。 経費精算（楽楽精算）／伝票作成AIエージェント 伝票入力の手間に対して、AI-OCRとエージェントを組み合わせる。領収書をアップロードすると、過去の申請事例などから経費精算データを予測し、入力まで済ませる。手作業が「確認するだけ」に変わる 販売管理（楽楽販売）／DB構成提案 初期設定や業務フロー構築が企業ごとに複雑で、導入のハードルになっていた。そこへ対話型ナビゲーションのAIアシストを導入する。AIと対話しながら進めるだけで自社に合った設定が提案され、専門知識がなくても使い始められる カスタマーサポート（楽楽自動応対）／メール作成エージェント 担当者ごとの応対品質のばらつきに対して、応対履歴や社内ナレッジベースから回答文案を自動生成し、品質を底上げする。さらに応対履歴からFAQ記事を提案・公開し、問い合わせの発生そのものを減らす 技術の実装方法は異なりますが、狙いは共通しています。「ユーザーの手作業」と「専門性の壁」をAIが肩代わりし、顧客が本質的な業務に集中できる状態をつくる。AIの実装は、そのための手段という位置づけです。 「正答率」：ユーザーが本当に求めていたもの 当初、開発チームがもっとも力を入れていたのは正答率の向上でした。エンジニアとしては自然な発想です。しかし、ユーザーの関心はそこにありませんでした。 ユーザーが重視していたのは、正答率そのものよりも「最終的な正解へ、早く楽にたどり着けるか」でした。なぜその答えになったのかの分かりやすさ、方向を示して軌道修正できること、間違ったときにリカバリーしやすいこと。正答率は入り口の一指標にすぎなかったわけです。 打ち手は、人が最後に主導権を持つ Human-in-the-loop の徹底でした。面倒な作業は自動化し、確認と修正は人に残す。「AIが提案し、人が確認する」という役割分担で、精度と安心感を両立させます。矢成はこの優先順位を、次のように言い切りました。 「90%正解でも、確認・修正しづらいAI　＜　80%正解でも、確認・修正しやすいAI」 数字の高さよりも、使う人の体験を優先する。開発に熱が入るほど見落としやすい観点です。 「縦の壁」と「横の壁」、そして専門組織 複数プロダクトを同時に走らせたことで、組織面の課題も見えてきました。矢成はこれを「縦の壁」と「横の壁」と呼びます。 縦の壁（チーム内）： AI機能の開発には、LLMやAIの専門スキルと、業務ドメインの深い理解の両方が必要になる。しかし、すべてのプロダクトチームに両方を求めるのは現実的でない。 横の壁（チーム間）： 複数プロダクトが同時に走ったため、APIのレート制御、LLMの精度評価、トークン消費コストの可視化、負荷試験の設計など、一度作れば共有できるものを各チームが個別に作ってしまう。「車輪の再発明」が各所で発生した。 打ち手は、AI開発の専門組織を新設し、そこに2つの役割を持たせることでした。一つは、難易度の高いコア開発をまとめて引き受ける役割。これにより縦の壁が下がり、各プロダクトチームは自分たちが最も詳しいドメインの実装に集中できます。もう一つは、ガイドライン策定や定例でのナレッジ共有など、知識の標準化を横に広げる役割。これにより横の壁が下がります。この設計は、専門性の高い開発を集約するチームと横展開を支援するチームを分ける「チームトポロジー」の考え方を下敷きにしたもので、この組織はAIロードマップを継続的に実現する役割も担い始めています。 現在地 現時点では、複数のプロダクトにAIが載り、個々の業務効率化で成果が出はじめた段階です。業務ルールや運用にAIが寄り添う「協働型AI」の一部が実現しています。この先は、プロダクト個別の最適化から、データとワークフローをプロダクト横断でつなぐ段階へ。さらに、より大きな顧客価値を生む相乗効果へと進め、プロダクトをより「AI Native」「Agentic」に近づけていく、そう結ばれました。 2つのセッションが指していた同じ方向 組織の話とプロダクトの話は、結論が重なりました。 公手：変革のゴールはAI駆動開発の浸透ではなく、顧客価値と事業価値をこれまで以上のスピードと品質で生み出すこと 矢成：AIを載せること自体が目的ではなく、顧客が本質的な業務に集中できる体験をつくり続けること どちらも主語は顧客です。AIは、価値提供のスピードと品質を上げるための手段として位置づけられている。 ラクスが創業から重視してきた「顧客志向」が、AIという新しい道具を得ても一貫している。 これが2つのセッションに共通するメッセージでした。矢成が立てた「勝負を分けるものは何か」という問いの答えも、モデルの性能や正答率ではなく、AIを顧客の体験にどこまで着地させられるか、という一点にあると読み取れます。 この2つは、「複数プロダクトを持つ組織である」という前提でもつながっています。各領域で最良の製品をそろえる「ベストオブブリード」は、ラクスが長年強みにしてきたものです。矢成の話はこの強みをAI時代に生かす戦略であり、公手の話はその複数プロダクトを横断してAIネイティブ化を進める土台づくりにあたります。開発本部が掲げる「顧客に価値を高速提供できるAIネイティブな開発組織へ変革し、次世代の統合型ベストオブブリードを実現する」というビジョンを、組織とプロダクトの両面から具体化しようとしている、と位置づけられます。 両者が共通して触れていたのが、これから強化したい人材像でした。公手が挙げたのは2種類のエンジニアです。AIが高品質な成果を出し続けられる開発基盤（ハーネス）を設計できるエンジニアと、「何を作るか」を研ぎ澄ます顧客価値の設計エンジニア。実装のボトルネックが解消された先で問われるのは「何を作るか」であり、この視点は矢成の言う「業務ドメインの深い理解」とも重なります。 おわりに 今回の2セッションは、「AIでこれだけ成果が出た」という事例集ではありませんでした。「ツールを導入しても進まなかった」「正答率を上げても使われなかった」と、うまくいかなかった過程を共有する内容です。AIをどう組織に根づかせ、どうプロダクトの価値に変えるか。同じ課題に直面している開発組織は少なくないはずで、ラクスもまた、正解の見えにくい中を試行錯誤しながら進んでいる最中です。 そして、ここで語られた変革は、まだ道半ばです。強制力を持って浸透を進める組織づくりも、顧客体験に着地させるプロダクトづくりも、これから担い手を必要としています。ラクスの開発本部では、先に触れた2つの人材像を、まさに募集しています。この試行錯誤を一緒に進めてくれる方は、ぜひ一度 採用ページ をのぞいてみてください。 また、当日の発表資料はSpeakerDeckで公開しています。ぜひあわせてご覧ください。 - 発表資料 speakerdeck.com speakerdeck.com なお、8月下旬ごろに発表のアーカイブ動画をラクスエンジニア情報ポータルサイトにて公開予定です。 - ラクスエンジニア情報ポータルサイト https://career-recruit.rakus.co.jp/career_engineer/ 「RAKUS AI Conference 2026 Summer」の他レポート記事 ・ 顧客の声から生まれた『AI返信補助機能』の開発プロセス ・ 楽楽精算AIエージェントを支える、LLMOpsとインフラの選択肢 ・ 仕様駆動開発、導入半年。「本当に速くなってるの?」にデータで答える