こんにちは。プロダクトエンジニアリング部でAndroidのネイティブアプリエンジニアをしている久野です。 今回はイマーシブモデルルームというApple Vision Pro向けのアプリを日本発売日に合わせてリリースした話をします。 なぜAndroidのネイティブアプリエンジニアの私がApple Vision Proの開発を担当したかというと、元々学生の頃からインターンや趣味でVRコンテンツ作成に携わっていた中、Apple Vision Proの発売を聞き「これを使ったアプリの開発をしてみたい！」と強く思い、上長や会社に挑戦してみたいと相談したところ、快く承諾して頂けたのがきっかけです。 イマーシブモデルルームについて 苦労したこと 技術調査および実機開発 リリース時期 デザイン、モデルの確認 工夫した機能 空間ビデオ スプラッシュの作成 まとめ イマーシブモデルルームについて イマーシブモデルルームは没入感のある高精細かつリアルなモデルルームや臨場感のある3D映像(空間ビデオ)で物件の魅力を体験することができるApple Vision Pro向けのアプリです。 2024年6月28日(金)にApple Vision Pro向けアプリにおいて国内不動産ポータルで初めて *1 の提供です。 App Storeにおいて公開していますので、Apple Vision Proをお持ちの方は体験してみてください。 prtimes.jp イマーシブモデルルーム LIFULL Co., Ltd ナビゲーション 無料 apps.apple.com 苦労したこと 技術調査および実機開発 今回イマーシブモデルルームはUnityを利用して開発を行いました。 UnityのApple Vision Pro用SDKであるPolySpatialは2023年の11月中旬に公開されましたが、情報が非常に少なくアプリのビルド等を進めるのも困難でした。また、SDK自体の更新も頻繁に行われていたのでそれに合わせてUnityを利用してApple Vision Proのアプリで何が実現できて何が出来ないかということの検証を進めていました。最新の情報をキャッチアップすることが重要だったため、Unityのフォーラムや個人の方が公開していらっしゃる記事を常にチェックしながら開発を進めました。 Apple Vision Proの実機に関連することでも苦労しました。Apple Vision Proの基本的な操作は目線と手を利用して行います。そのため、アプリケーションの開発においても実機を利用して、目線と手を使った操作の確認が必要でした。ただ、SDKが公開された11月段階ではアメリカにおいても実機は発売されていないので、Unity Editor及び Apple Vision ProのSimulatorを利用して確認を行ないました。 しかし、Unity EditorやApple Vision ProのSimulatorでは両手の入力をするようなコンテンツ（イマーシブモデルルームの機能ですと3Dモデルのマンションを回転、サイズの変更をする）といったジェスチャーの確認を行うことが困難です。そのため、弊社で3月にアメリカで発売された実機を入手して技適申請を行うまでの間はデベロッパラボを月に一度程の頻度で応募をして利用させて頂きました。それによって開発中のアプリを実機で挙動確認させて頂きました。 developer.apple.com リリース時期 リリース日を日本での発売日に合わせるために行っていた取り組みを説明します。 Apple Vision Proが日本で発売される時期がわからない状況で、発売日にリリースすることを目標にして進めていました。 そのことから、アプリのリリース時期を３段階に分けてそれぞれの段階においてどのようなアプリをリリースするかということをチームで定めていました。 チームの計画としては下記3パターンを考えていました。 7月リリースパターン 9月リリースパターン 12月リリースパターン 7月のリリースパターンでは時間も少なかったため必要最小限のプロダクトを開発し、そこからブラッシュアップしていくという方法を取りました。早い段階から動く形にしておくということを意識しながら進めることで想定よりも早い段階でのリリースに対応することが出来ました。 デザイン、モデルの確認 まずUnity Editorを用いてビジュアルのチェックを行なっていました。しかし、Apple Vision Proの特性を最大限に活かすためにはこれだけでは不十分です。実際にアプリをApple Vision Proにビルドし、モデルがどのように見えるか、ユーザー体験がどのように実現されるかを確認することが不可欠でした。 この確認作業ではデザイナーの方と密に連携し、デザイン及び体験の確認を何度も繰り返しました。特にリリース直前にはデザイナーの方とUnity Editorの画面を一緒に見ながら確認及び細かい修正を行いました。 またモデル更新の反映など軽微な確認にはPolySpatialの Play to Device 機能を活用しました。Play To Deviceを利用することでBuildをせずにUnity Editorから再生したものをApple Vision ProのSimulatorで確認できます。これにより開発プロセスの効率が大幅に向上しました。 工夫した機能 空間ビデオ 今回アプリの中で空間ビデオを表示する機能も提供しています。 空間ビデオはUnityのPolySpatialの VisionOSVideoComponent でも対応しています。上記のドキュメントに従って設定を行なっていたのですが、動画が再生されないという問題にぶつかりました。そのため以下のような対応を行いました。 初めに、Volume cameraの設定です。 以下二つの設定に対して同じものを指定する必要がありました。 Project Settings > PolySpatial > Default Volume Camera Window Config Scene内の Volume Camera > Volume Window Configuration この二つに設定しているVolume cameraを同じものにすることで、Apple Vision Proの実機で空間ビデオの再生をすることが出来ました。 また、動画はコーデックが空間ビデオに対応されているものである必要がありました。iPhone等で撮影した後でPCに送る際にはオートコーデックが発生して別のコーデックに変更がかからないように注意する必要がありました。 スプラッシュの作成 今回のアプリの中でユーザーがアプリを開始するたびにスプラッシュを表示しています。 Unityにはデフォルトで Splashを表示する機能 が存在していますが、今回のPolySpatialでは利用することが出来ないということをフォーラムで見かけ、実際に調査を行ったのですが利用することが出来ませんでした。 そのため、デフォルトの機能を利用せずにスプラッシュの代わりにアプリ起動時にアプリのキービジュアルを表示する機能を作成しました。 実装面では、Volume cameraの WindowEvent を活用しました。 こちらを利用して、アプリが開かれた際にキービジュアルを数秒間表示してから、アプリのコンテンツを体験出来るように実装しました。 まとめ Apple Vision Proの日本発売日に合わせて、「イマーシブモデルルーム」を無事リリースしました。技術調査や実機開発、デザイン確認など、数々の課題はありましたが、3Dモデルデータを利用した住まい探しの新たな可能性を広げるプロダクトを生み出す第一歩になったのではと思います。これからも、住生活を革進することの出来るプロダクトを開発していこうと思います。 LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co hrmos.co *1 : 2024年6月28日時点、自社調べ

KEELチーム の相原です。 前回のエントリは「LLMを利用したPlatform Engineering」でした。 www.lifull.blog 今回は、小さい経路最適化ミドルウェアを実装してAZ間通信を削減した話を書きたいと思います。 背景 我々KEELチームはKubernetsベースの内製PaaSであるKEELを開発しており、LIFULLのほとんどのサービスがこのKEEL上で動いています。 www.lifull.blog そして、KEELは巨大なマルチテナントのKubernetesクラスタとしてAWSの複数のAvailability Zone(以下AZ)に展開されていて、多くのmicroservicesが互いに通信しあっています。 そのためAZ間通信はプラットフォームとして重要な関心事の一つです。 レイテンシやAWSのAZ間通信に対する課金を最小限に抑えるため、なるべくAZ間通信を減らしたいという要求があります。 我々のプラットフォームでは現在LLMのサポートを強めており、それに伴い扱うペイロードのサイズも増加傾向にあることからも対応の優先度が上がってきています。 www.lifull.blog 実際にKubernetesの Topology Aware Routing をプラットフォーム側で配布してデフォルトで有効にしたり、Istioの Locality Load Balancing をクラスタ全体で有効にして、クラスタ内の通信の経路最適化に努めてきました。 ※Istioが有効になっているPodではTopology Aware Routingは機能しないため、全てのPodにIstioを導入できていない場合はクラスタ全体として両方を有効にする必要があります 一方で、KEELはステートレスなクラスタとして永続性が必要とされるデータストアは基本的にクラスタ外に依存しており、未だ最適化できていない経路も存在しています。 そこでその残されたAZ間通信も削減すべく、小さい経路最適化ミドルウェアを実装する判断に至りました。 背景 実装 シンプルなConnection Pool 余談: Connection Storm Topology Aware Routing 注意点 最後に 実装 さて、KubernetesやIstioが実現するクラスタ内通信の経路最適化はKubernetesのService Discoveryに依存しているため、クラスタ外への通信で真似することはできません。 つまりクライアントはサーバがどのトポロジに配置されているかを知る共通の手段を持っていないということです。 サーバ側がDNSのSRVレコードなどに対応していればそれをそのまま利用できますが、そうでもない場合全てのサーバに新規にService Discoveryを入れるということはあまりに大変です。 そこで我々はTCPサーバとして振る舞うConnection Poolのミドルウェアとして経路最適化を実現することに決めました。 LIFULLにはRubyのUnicornなど1リクエスト1プロセスなプロセスモデルのアプリケーションサーバがいくつかあり、元々プロセスをまたいだConnection Poolを実現したいという要求があります。 しかし、プラットフォームとしてProxySQLを提供するなど特定のユースケースでは対応できていたものの、 あらゆるAZ間通信 には対応できていませんでした。 Connection Poolでの経路最適化のアイデアはシンプルで、維持している接続をトポロジごとに管理して、なるべくクライアントと同じトポロジの接続を取り出して使うだけです。 つまりConnection Poolが維持している接続を疑似的にService Discoveryとして利用するということです。 これが実現できれば色々と都合が良さそうなのでやっていきましょう。 シンプルなConnection Pool まずは普通のTCPプロキシにシンプルなConnection Poolを実装していきます。接続を取り回すだけのソフトウェアになるのでGoが無難でしょう。 MinIdleConnections , MaxIdleConnections でアイドルな接続をコントロールできるようにして MaxIdleTime , MaxLifetime で生存期間を設定できるよくあるやつです。 設定は大体こういうインタフェースでしょうか。 Connection は MaxIdleTime の判定で利用する returnedAt を持てるようにしただけの net.Conn の薄いラッパーです。 type ConnectionPoolStrategy int const ( FIFO ConnectionPoolStrategy = iota LIFO ) type ConnectionPoolOption struct { MaxConnections uint MaxIdleConnections uint MinIdleConnections uint MaxIdleTime time.Duration MaxLifetime time.Duration Dialer func (context.Context) (net.Conn, error ) ConnectionPoolStrategy ConnectionPoolStrategy } type ConnectionPool struct { option *ConnectionPoolOption connectionMutex sync.Mutex connections []*Connection idleConnections []*Connection } コンストラクタは省略するとして、接続を取り出す部分はこんな感じになります。 func (p *ConnectionPool) Get(ctx context.Context) (*Connection, error ) { p.connectionMutex.Lock() defer p.connectionMutex.Unlock() defer func () { go p.prepareIdleConnection(ctx) }() for { connection, err := p.getIdleConnection(ctx) if err != nil { return nil , xerrors.Errorf( "failed to get idle connection: %w" , err) } if connection == nil { break } now := nowFunc() if (p.option.MaxIdleTime > 0 && now.Sub(connection.returnedAt) > p.option.MaxIdleTime) || (p.option.MaxLifetime > 0 && now.Sub(connection.createdAt) > p.option.MaxLifetime) || !connection.isHealthy() { _ = connection.Close() p.removeConnection(ctx, connection) continue } return connection, nil } connection, err := p.newConnection(ctx) if err != nil { return nil , xerrors.Errorf( "failed to create connection: %w" , err) } return connection, nil } ロックを取りながらアイドルな接続を取り出し、生存期間を満たしていれば死活監視をしてから接続を返します。 アイドルな接続がなければ新規に接続を作成して返します。 prepareIdleConnection は MinIdleConnections を満たすようにアイドルな接続を用意していて、 isHealthy はソケットに read(2) して EAGAIN or EWOULDBLOCK であることの確認です。 func (c *Connection) isHealthy() bool { // A zero time value disables the deadline. _ = c.conn.SetReadDeadline(time.Time{}) syscallConnection, ok := c.conn.(syscall.Conn) if !ok { return false } rawConnection, err := syscallConnection.SyscallConn() if err != nil { return false } healthy := false if err := rawConnection.Read( func (fd uintptr ) bool { b := make ([] byte , 1 ) _, err := syscall.Read( int (fd), b) if errors.Is(err, syscall.EAGAIN) || errors.Is(err, syscall.EWOULDBLOCK) { healthy = true } return true }); err != nil { return false } return healthy } そして、使い終わった接続を維持するためのPutを実装します。 MaxIdleTime で判断するための returnedAt の更新も忘れないようにしましょう。 func (p *ConnectionPool) Put(ctx context.Context, connection *Connection) error { p.connectionMutex.Lock() defer p.connectionMutex.Unlock() if p.IdleConnections() < int (p.option.MaxIdleConnections) { connection.returnedAt = nowFunc() p.idleConnections = append (p.idleConnections, connection) } else { _ = connection.Close() p.removeConnection(ctx, connection) } return nil } ちなみに、ここまでの内容のTCPプロキシでの利用イメージはこんな感じになります。 func main() { ... semaphore := make ( chan struct {}, maxConnections) shutdown := make ( chan struct {}, 1 ) wg := sync.WaitGroup{} go func () { ctx := context.Background() for { local, err := listener.AcceptTCP() if err != nil { select { case <-shutdown: return default : continue } } semaphore <- struct {}{} wg.Add( 1 ) go func () { defer func () { <-semaphore wg.Done() }() defer local.Close() remote, err := connectionPool.Get(ctx) if err != nil { return } defer connectionPool.Put(ctx, remote) defer remote.Cancel() c := make ( chan struct {}, 2 ) f := func (c chan struct {}, dst io.Writer , src io.Reader ) { _, _ = io.Copy(dst, src) c <- struct {}{} } go f(c, remote, local) go f(c, local, remote) select { case <-c: case <-shutdown: local.CloseWrite() } }() } }() // Graceful shutdown quit := make ( chan os.Signal, 1 ) signal.Notify(quit, syscall.SIGTERM) <-quit time.Sleep(time.Duration(lameduck) * time.Second) close (shutdown) listener.Close() wg.Wait() } 余談: Connection Storm この実装では、維持している接続が MaxLifetime に達した時に強制的にその接続を破棄します。 古い接続が使われ続けることを防ぐためのものですが、これには比較的大きなトレードオフがあります。 それは Connection Storm と呼ばれる現象で、維持されていた接続が一斉に MaxLifetime によって切断されることで、新規の接続が大量に確立して接続先に大きな負荷がかかるというものです。 それを防ぐためには リトライなどでよく知られるJitter を入れるとよいです。 Jitterはランダム性を注入する概念で、生存期間の判定箇所にJitterを入れて一斉に切断されることを防ぎます。 リトライにおけるJitterは、接続先の障害発生時などに複数のリトライが同時に行われるとカスケード障害を起こしてしまうため、リトライにランダム性を持たせるために利用されています。 type ConnectionPoolOption struct { MinIdleConnections uint MaxIdleTime time.Duration MaxLifetime time.Duration + Jitter func (time.Duration) time.Duration Dialer func (context.Context) (net.Conn, error ) ConnectionPoolStrategy ConnectionPoolStrategy } now := nowFunc() - if (p.option.MaxIdleTime > 0 && now.Sub(connection.returnedAt) > p.option.MaxIdleTime) || - (p.option.MaxLifetime > 0 && now.Sub(connection.createdAt) > p.option.MaxLifetime) || + if (p.option.MaxIdleTime > 0 && now.Sub(connection.returnedAt) > p.option.Jitter(p.option.MaxIdleTime)) || + (p.option.MaxLifetime > 0 && now.Sub(connection.createdAt) > p.option.Jitter(p.option.MaxLifetime)) || !connection.isHealthy() { _ = connection.Close() p.removeConnection(ctx, connection) 実際のJitterの実装はこんな感じになると思います。 jitterPercentage でどの程度ランダム性に開きを持たせるかを調整できるようにするイメージです。 テストの時には引数の duration をそのまま返せばいいでしょう。 func (duration time.Duration) time.Duration { jitter := time.Duration( float64 (duration) * jitterPercentage * (rand.Float64()* 2 - 1 )) return duration + jitter } 閑話休題。 Topology Aware Routing ここまででシンプルなConnection Poolの実装が完成したので、ここからようやく本題の経路最適化の実装に入ろうと思います。 アイデアは先に書いた通りシンプルで、維持している接続をトポロジごとに管理して、なるべくクライアントと同じトポロジの接続を取り出して使うだけのものを目指します。 トポロジはIPをベースに判断するとして、今回はサイドカーとしてクライアントのプログラムと同じサーバで動かすことを想定しているため、クライアントのトポロジは自身のIPから判断することができそうです。 トポロジの一覧を --topologies=a=192.168.0.0/24,b=192.168.1.0/24,c=192.168.2.0/24 のように受け取り、プログラム内では以下のように取り扱うことにします。 type Topology struct { Name string CIDR net.IPNet } var topologyList []Topology var topologyName string if topologyAwareRouting { for _, t := range strings.Split(topologies, "," ) { if t == "" { continue } parts := strings.Split(t, "=" ) if len (parts) != 2 { log.Fatalf( "invalid topologies: %s" , topologies) } _, cidr, err := net.ParseCIDR(parts[ 1 ]) if err != nil { log.Fatalf( "failed to parse CIDR %s: %+v" , parts[ 1 ], err) } topology := Topology{ Name: parts[ 0 ], CIDR: *cidr, } topologyList = append (topologyList, topology) if topology.CIDR.Contains(net.ParseIP(ownIP)) { topologyName = topology.Name } } } CIDRを持ったトポロジの一覧が topologyList として管理されていて、自身のIPから判断したクライアントのトポロジを事前に topologyName として定義しておきます。 ( topologyName を事前に定義するのは計算コストを嫌っているだけで、当然クライアントの接続から都度判断することも可能なのでサイドカーではなく独立してデプロイすることも可能です) Kubernetesでは自身のIPを Downward API から取得可能で、AWSでも インスタンスメタデータ から取得できるのでこれを使います。 それでは先ほどのConnection Poolの実装にこれらを与えてTopology Aware Routingに対応していきましょう。 まずは topologyList を受け取るれるようにしつつ、維持している接続をHashMapでトポロジごとに管理できるように構造体を変更します。 type ConnectionPoolOption struct { MinIdleConnections uint MaxIdleTime time.Duration MaxLifetime time.Duration Jitter func (time.Duration) time.Duration + TopologyList []Topology Dialer func (context.Context) (net.Conn, error ) ConnectionPoolStrategy ConnectionPoolStrategy } type ConnectionPool struct { connectionMutex sync.Mutex connections []*Connection - idleConnections []*Connection + idleConnections map [ string ][]*Connection } 次に、接続を取り出す Get でクライアントのトポロジ topologyName を受け取って、同じトポロジの接続を取り出す部分です。 - func (p *ConnectionPool) Get(ctx context.Context) (*Connection, error ) { + func (p *ConnectionPool) Get(ctx context.Context, topologyName string ) (*Connection, error ) { p.connectionMutex.Lock() defer p.connectionMutex.Unlock() defer func () { go p.prepareIdleConnection(ctx) }() for { - connection, err := p.getIdleConnection(ctx) + connection, err := p.getIdleConnection(ctx, topologyName) if err != nil { return nil , xerrors.Errorf( "failed to get idle connection: %w" , err) } if connection == nil { + if n := p.pickRandomIdleTopologyName(); n != nil { + topologyName = *n + continue + } break } now := nowFunc() if (p.option.MaxIdleTime > 0 && now.Sub(connection.returnedAt) > p.option.Jitter(p.option.MaxIdleTime)) || (p.option.MaxLifetime > 0 && now.Sub(connection.createdAt) > p.option.Jitter(p.option.MaxLifetime)) || !connection.isHealthy() { _ = connection.Close() - p.removeConnection(ctx, connection) + p.removeConnection(ctx, topologyName, connection) continue } return connection, nil } connection, err := p.newConnection(ctx) if err != nil { return nil , xerrors.Errorf( "failed to create connection: %w" , err) } return connection, nil } pickRandomIdleTopologyName はフォールバックの処理で、同じトポロジの接続がなかった際に適当なトポロジの接続を代わりに使います。 フォールバックの戦略を外から与えられるようにしてもいいですね。 他はそれぞれ先のHashMapを扱って接続を取り出したり削除したりしてるだけです。 細かい話ですが、 idleConnections がHashMapになることで総接続数を得るための計算コストが O(1) でなくなってしまうため、別でAtomicなカウンターを用意しておいた方がよいです。 最後に Put の実装です。 func (p *ConnectionPool) Put(ctx context.Context, connection *Connection) error p.connectionMutex.Lock() defer p.connectionMutex.Unlock() + topologyName := p.topologyName(connection.RemoteAddr()) + if p.IdleConnections() < int (p.option.MaxIdleConnections) { connection.returnedAt = nowFunc() - p.idleConnections = append (p.idleConnections, connection) + p.idleConnections[topologyName] = append (p.idleConnections[topologyName], connection) } else { _ = connection.Close() - p.removeConnection(ctx, connection) + p.removeConnection(ctx, topologyName, connection) } return nil } net.Conn の RemoteAddr() で接続先のIPを取得し、以下の関数で topologyList として受け取ったCIDRから適切なトポロジを取得します。 func (p *ConnectionPool) topologyName(addr net.Addr) string { for _, t := range p.option.TopologyList { switch addr := addr.( type ) { case *net.TCPAddr: if t.CIDR.Contains(addr.IP) { return t.Name } case *net.UDPAddr: if t.CIDR.Contains(addr.IP) { return t.Name } } } return "" } これで経路最適化を行うTopology Aware Routingも完成です。 簡易的な実装による楽観的な経路最適化ですが、接続先のService Discoveryに依存しない あらゆるAZ間通信 に対応するものができました。 例えばAWSのElastic Load BalancerはAZごとにIPを持っており、それがDNSラウンドロビンで返却されます。 このミドルウェアをクライアントに導入することで、AWSのロードバランサに対する接続であってもAZ間通信を削減することに成功しました。 なお、AWS Application Load Balancerはデフォルトで クロスゾーン負荷分散 が有効になっていて、これを導入してもロードバランサとUpstreamの間ではAZ間通信が発生する可能性があります。 Upstreamが十分にAZに分散されていればクロスゾーン負荷分散を無効にする判断ができるかもしれません。 注意点 このミドルウェアに限らずこういった経路最適化で考慮しなければならないことがあります。 それはトポロジ間の分散です。 クライアントとサーバでトポロジ間の分散が不十分な場合、例えばクライアントが一つのトポロジに集中してデプロイされてしまっている場合に、そのトポロジのサーバに負荷が集中してしまいます。 これを防ぐためには慎重にトポロジ間で分散させる必要があり、それにはKubernetesの Pod Topology Spread Constraints を利用することができます。 これはデプロイ時にトポロジ間のばらつきに対する制約をかけられる機能で、LIFULLではKubernetes Manifestを生成するためのコードジェネレータでKubernetesのTopology Aware Routingの設定とともにデフォルトの設定として配布しています。 www.lifull.blog ただしこれはあくまでデプロイ時の制約で、Podがスケールインした後のリバランスまでは面倒を見てくれません。 そこで、あわせて kubernetes-sigs/descheduler を導入して RemovePodsViolatingTopologySpreadConstraint を有効にすることをお勧めします。 これにより Pod Topology Spread Constraints に違反しているPodを再スケジュールしてくれるため、その後の再デプロイで再度制約をかけることができます。 またこの制約を機能させるためにはノードのトポロジ間のバランスも重要で、 cluster-autoscaler などで適切に設定する必要があることにも注意してください。 (AWSのAuto Scaling Groupはスポットインスタンスを使っていなければ いい感じにやってくれる ので特に気にする必要はない気がします) 最後に Connection Poolのミドルウェアに簡易的なTopology Aware Routingを実装することで あらゆるAZ間通信 を削減することに成功しました。 これによりレイテンシの改善とAZ間通信に対する課金を抑えることができます。 AZ間のレイテンシはLIFULLの環境では最悪ケースで5msにも及ぶことがあり、それなりのインパクトを期待しています。 マルチプロセスなアプリケーションサーバを運用しているとそれっぽいConnection Poolが欲しくなることはあって、手前味噌ですがこのアプローチはちょうどいい塩梅なのではないでしょうか。 最近は調子に乗ってこれにRedisのプロトコルパーサを載せて、RedisへのクエリのRead/Writeの分離機能を実装するなどもしてしまっています。 KEELではRead Heavyなキャッシュなどの用途に向けて運用が簡単なRedis Sentinelクラスタを提供していまして、クライアント実装に手を入れづらい際にこれを入れるだけでいい感じに動くというちょうどいいTCPプロキシとしての立ち位置を確立しつつあります。 KEELチームでは、いくつかの機能をProxy-Wasmで実装してIstio経由で配布していたりもしますが、こういう実装はProxy-Wasmでは実現しづらく第二のService Meshとして今後もこのちょうどいいTCPプロキシを改善していく予定です。 (オーバーエンジニアリングとの境目を気にしながら、)プラットフォームとして必要なものがあれば何でも実装するKEELチームにもし興味を持っていただけた場合は、是非カジュアル面談をさせてください！ hrmos.co hrmos.co 次のエントリでは、KubernetesのPodの終了際のログが欠損してしまう問題をeBPFで unlink(2) を bpf_override_return して対処した問題について書こうと思うので購読してお待ちください :D

KEELチーム の相原です。 これまでKEELチームではKubernetesベースの内製PaaSであるKEELを開発・運用しながら、合間で社内で汎用AI(仮)と呼ぶAutoGPT実装 keelai を開発してきました。 www.lifull.blog 我々はあくまでプラットフォーマーであり、目指すところはLLMを利用したPlatform Engineeringです。 いくつかの取り組みが実を結んできたのでここで紹介したいと思います。 APIの提供 GitHub ActionsからのLLM利用 Slack AutomationsによるLLMノーコードツールの提供 Chrome Extensionで実現するシームレスなLLM体験 コマンドラインツールでのLLM活用 Jupyter Notebookでの高度なLLM活用 まとめ APIの提供 何はともあれまずはAPIの提供でしょう。 ここでは我々が開発するAutoGPT実装である keelai をAPIとして提供しています。 移植性のためにOpenAI互換のインタフェースになっていて、当然Server Sent Eventsにも対応しています。 KEELチームで開発しているSAMLベースの認証基盤の下で社内に公開しており、Kubernetesクラスタ内通信も含めてIstioのAuthorizationPolicyで認可しています。 FastAPIを使っていてちょうどよくWebインタフェースが用意されていることもあり、開発者はAPI Keyなどを発行することなくすぐにAPIを利用することができます。 IstioのRequestAuthenticationで任意のJSON Web Tokenを検証することもでき、あらゆる場所から安全に呼び出すことが可能です。 また、セグメントごとのトークンベースのRate Limitを実装してあり、SAML認証済みのユーザやJSON Web Tokenの任意のペイロード・呼び出し元ワークロードに応じてヘッダを付与し、それをもとにSliding Windowで流量制限しています。 呼び出し元ワークロードの判定をヘッダから行うためには、まずIstioのPeerAuthenticationでmTLSを強制して呼び出し元のEnvoyを保証し、Envoyが付与する x-envoy-peer-metadata をProxy-Wasmでパースしてワークロードを取得するなどちょっとハックしているので、この辺はまた別のエントリで書くとしましょう。 当然サイト信頼性に責任を負う立場として、各種メトリクスやOpenTelemetryによるトレースの収集、適切なリトライやエラーハンドリングによってProduction Readyな品質となっており、コンシューマ向けのプロダクトからもこのAPIが呼ばれています。 各種ベクトルデータベースの提供 や Semantic Search用のコンポーネントの提供 もしていますが、嬉しい誤算で汎用AI(仮)ということもあり基本的に現在はこのAPIを介してあらゆる機能を実現しています。 (OpenAIへの課金を懸念して llama.cpp ベースのオープンソースLLMのAPIサーバも提供していますが、これも嬉しい誤算でLLMの価格競争による低コスト化が進んでいるので今のところ出番はなさそうです) 今後はKubernetesクラスタであるKEEL自身のLLMを使ったAIOps(?)を強化していく予定で、Alertmanagerから発火する運用自動化用のKnative Serviceが存在しているため、そこから同様に keelai のAPIを呼ぶことで更なる自動化を進めていきます。 keelai はSelf-hostingされた汎用AI(仮)として社内の監視基盤とも連携できるのでここは色々と遊べそうです。 GitHub ActionsからのLLM利用 APIには前述した通りIstioのレイヤでJSON Web Tokenの検証と認可が実装されているため、同じく我々が提供する GitHub Actions Self-hosted runners を利用することでGitHub Actionsから以下のように呼び出すことができます。 www.lifull.blog $ ID_TOKEN = $( curl -sSL -H " Authorization: Bearer ${ACTIONS_ID_TOKEN_REQUEST_TOKEN} " " ${ACTIONS_ID_TOKEN_REQUEST_URL} &audience= ${GITHUB_ACTION_PATH} " | jq -r .value ) $ curl -sSL -X POST -H " Authorization: Bearer $ID_TOKEN " -H " Content-Type: application/json " https://keelai-api.keelai.svc.cluster.local:8080/v1/chat/completions -d " $( echo $@ | jq -sc --arg model " $MODEL " ' . as $messages | {"model": $model, "messages": $messages} ' ) " これには GitHubのOpenID Connect を利用していて、サーバ側はこのようにGitHubから送られてきたJSON Web Tokenのclaimsをもとに認可することが可能です。 apiVersion : security.istio.io/v1beta1 kind : AuthorizationPolicy metadata : name : keelai-api spec : action : ALLOW rules : - when : - key : request.auth.claims[iss] values : - https://token.actions.githubusercontent.com - key : request.auth.claims[repository_owner] values : - lifull selector : matchLabels : app.kubernetes.io/name : keelai-api これにより各リポジトリにAPI Keyを配布することなく、気軽にLLMを利用した自動化を始めることができています。 さて、LLMによるソフトウェアエンジニアリングの生産性向上でやはり最初に思いつくものはコードレビューでしょう。 既にOpenAIのAPIを叩いてコードレビューするようなものはありふれていますが、目指すべき先は社内のコーディングガイドラインや過去の障害実績をもとにしたコードレビューだと思います。 そのためには社内情報にアクセスできる必要があり、そこで汎用AI(仮)を目指す keelai が役に立ちます。 keelai はAutoGPT実装として、目的達成のため自律的に複数の関数を使い分けながら回答を作成できるため、(今はまだ精度に改善点はあるものの)必要に応じて過去の障害情報を参照しながらコードレビューすることが可能です。 我々はプラットフォーム戦略としてKubernetes Manifestからドキュメントまでを一手に生成する コードジェネレータも開発しており 、これによって多くのGitHub Actionsを配布しています。 その中でコードレビューの機能も実験的に提供しており、プロンプトに以下のような指示を加えて、 git diff の出力をもとにコードレビューの結果を reviewdog の形式で出力させています。 The output MUST be `%f:%l: %m` format. <snip> %f: File name %l: Line number %m: Message </snip> Line number MUST be the line number of the file that calculated from the diff. こうしておくことで reviewdog を使って雑にPullRequestへのインラインコメントが可能です。 echo " $body " | reviewdog -efm =' %f:%l: %m ' -reporter = github-pr-review -filter-mode = nofilter このメソッドは手軽な割に意外と汎用的で、セキュリティに特化したコードレビュー機能が社内で配布され始めたりと好感触です。 他にも、利用しているOSSのバグチケットをGitHub Actionsのスケジュール実行で監視して翻訳・要約してIssueとして起票するチームがあったりとGitHub ActionsからのLLM利用が進んでいます。 Slack AutomationsによるLLMノーコードツールの提供 次はSlack Automationsを利用した疑似的なLLMノーコードツールを提供している話です。 Slack AutomationsとはSlackの有料プランで利用できるワークフロービルダーです。 リアクション時やスケジュール実行でチャンネルへの発言からスプレッドシートへの追記まで割となんでもできます。 api.slack.com Deno Slack SDK を使ってステップと呼ばれる任意の処理も自作可能で、組み込みのステップは多くないものの自分で作ってしまえば問題ありません。 LIFULLではこのSlack AutomationsからLLMを呼び出せるようにして、LLMノーコードツールとして職種問わず広く社員が業務を自動化できる環境を整えています。 とは言うものの、Slack Automationsは2024年8月現在でステップのSelf-hostingに対応していません。 つまりプライベートネットワーク上で公開されているAPIにアクセスすることができません。 幸い我々のAutoGPT実装である keelai はSlack Botとしても実装されており、Slack AutomationsからメンションすることでLLMを発火させることができました。 www.lifull.blog 実際の利用例は以下のようなイメージです。 基本的にはリアクションなどを起点に組み込みの Reply to a message in thread を使いながらメンションしてLLMを発火させているだけです。 リアクション時にペイロードとして渡ってくるメッセージのURLからメッセージ本文を取得するステップを実装していますが、これはFew-shot promptingをしやすくするためのものであり必須ではありません。 そして設定したリアクションをすると以下のようにLLMが呼び出されます。 これもなかなか好評で、プログラミングなしでLLMによる業務の自動化が可能であることから職種問わず広く利用されています。 ちなみに、回答結果へのリアクションは keelai 自身が行っており、Slackの chat.update を通してServer Sent Eventsを表現しているためそれの完了通知という意味もありつつ、ここから更にリアクション起点のSlack Automationsを発火させるためという意味もあります。 Slack Automationsには簡易的なフォームを作成する機能もあり、 総務部門など各部署が自分達で相談の一次受けのフォームを用意するといったことが行われています 。 汎用AI(仮)である keelai は当然社内でのこれまでの相談内容や社内ドキュメントをSemantic Searchできるようになっているため、そこそこの精度で回答することが可能です。 そして、 Submit すると事前に定義されたプロンプトにフォームの入力を埋め込んでLLMが呼び出されます。 Slack Automationsにはスプレッドシート連携の機能もあるため、完了通知のリアクションを起点に質問と回答結果のペアをスプレッドシートに追記しておいて、それをもとにプロンプトの改善に繋げるといった運用になっています。 他にも経理部門が為替の日次確認の自動化を実現していたり、RSSによって通知されるニュースをリアクションで要約するワークフローが普及していたりと、こういったことをエンジニアでなくてもすぐに実現できる点が汎用AI(仮) + Slack Automationsの強みです。 元々Slack Botとして keelai を開発し始めた狙いでもありますが、コミュニケーションツール内でLLMを利用することにより社員が日頃からLLMの活用を目にしやすく、利用者の拡大にも一役買っていると思います。 我々はプラットフォーマーとして多くのステップを Deno Slack SDK で開発しており、ループ機構を実現するステップやSlack Automations側でOAuthのサポートがあるためそれを使ったGitHubやGoogle Apps Scriptへアクセスするステップなどが既に実装されています。 (Self-hostingのサポートを待ちつつ)今後もLLMノーコードツールとして機能開発を続けていきます。 Chrome Extensionで実現するシームレスなLLM体験 LIFULLのプラットフォームを広く開発する我々KEELチームは、プラットフォーム戦略の一環としてChrome Extensionも開発しています。 KEELチームが開発する汎用AI(仮)が keelai なので、このChrome Extensionの名前は keelext です。 当初はGrafanaのユーザ体験を補完するなどプラットフォームの利用補助が主なスコープでしたが、汎用AI(仮)の開発に伴いそのスコープが拡大してきています。 LLM周りでの主な機能としては、対応している社内サービスなどのページを開くと keelai のアイコンが表示され、それをクリックするとモーダルが開いて例えばConfluenceの場合はそのページの要約が生成されます。 他にはGrafana上のエラーメッセージの解決方法を過去のエラー対応のやり取りをもとに提案してくれる機能や、右クリックのメニューからは選択範囲の文字列の翻訳・要約するなどありがちな機能も実装してあります。 生成結果の言語はブラウザの設定言語に従いますが、モーダル内でそのまま翻訳することも可能です。 このシームレスなユーザ体験により、利用者は keelai のアイコンを見かけたら とりあえずクリックするだけで何かがいい感じに生成される ということが実現されています。 他にもフォームの自動入力など社内の各種プラットフォームのLLM連携が実現されており、LLMを利用したPlatform Engineeringを支える重要なコンポーネントとなっています。 当然これも keelai のAPIを利用することで実現されていて、 APIの提供 で紹介した社内の認証基盤の認証フローを chrome.identity.launchWebAuthFlow で踏んでいます。 そのため利用者が手元にAPI Keyを用意することなく安全に呼び出すことができています。 あとは愚直にひたすら実装していくだけです。あえて言うとすれば生成結果をServer Sent Eventsでそのままモーダルにストリーミングしていて、性質上複数回クリックするなどしてリクエストが重複する可能性が高いので丁寧にAbortControllerで重複を防いでることくらいでしょうか。 Gmailで利用できるメール返信文の自動生成を実装しているなど本家と衝突して危ういものもありますが、メールは職種によっては評判がよかったりするのでとりあえず短期の生産性向上を目指してあらゆるページにLLM連携を実装していっています。 とはいえChrome Extensionだと権限の問題で実現できる範囲に制約があり、現在は鋭意デスクトップアプリケーションを開発中です。 (プラットフォーマーとして、Kubernetesベースの内製PaaS・GitHub ActionsからKubernetes Manifest, ドキュメントまでを握るコードジェネレータを中心としたコマンドラインツール・Chrome Extensionとやってきたので次はデスクトップアプリケーションかなというところです) コマンドラインツールでのLLM活用 我々は keelctl と呼ばれるコマンドラインツールも開発しており、先に紹介したコードジェネレータもこの keelctl に実装された機能の一つです。 www.lifull.blog 実はコマンドラインツールでのLLM活用は以前に似た内容のエントリを書いていて、社内の認証基盤の認証フローをコマンドラインから踏んでAPIを利用するという大枠は変わっていません。 www.lifull.blog こちらも順調に機能拡充が進んでいて、Conventional Commits形式のコミットメッセージの自動生成の他にも色々なタスクをコマンドラインツールからLLMを活用することで実現しています。 中でも、CSVのカラムを入力として他のカラムを埋める keelctl llm fillcsv という機能が好評です。 System: You are an AI assistant. Given a question and its answer, your task is to generate alternative expressions (paraphrasing) for that question to provide more options. User: Paraphrasing provides a new perspective on the question and aids users in obtaining the answer. Please generate at least 10 paraphrasings. Paraphrasing MUST be joined semicolons. question: keelaiの利用方法 answer: keelaiを利用する際には対象のSlackチャンネルにkeelaiを招待してメンションするか、keelaiのSlack Appsに対してDirect Messageで話しかけてください paraphrasing: keelaiを利用するには;keelaiの使い方;keelaiのドキュメント;LLMを使いたい question: %s answer: %s paraphrasing: 例えば上記のようなプロンプトテンプレートを与えると、以下のCSVを行ごとに処理して paraphrasing カラムを question と answer から生成した想定される質問の別バリエーションで埋めることができます。 question,answer,paraphrasing LIFULLに興味がある場合の次のアクション,お気軽に[カジュアル面談](https://hrmos.co/pages/lifull/jobs/010-9998)をお申込みください, ... 利用イメージは以下です。 コマンドを実行するだけでLLMを使ったタスクを並行で一括実行することができます。 中身は汎用AI(仮)なので、社内情報へのアクセスはもちろんのこと検索や画像生成まであらゆるタスクをこなすことができます。 $ keelctl llm fillcsv input.csv question,answer paraphrasing --prompt-template /path/to/paraphrasing.tmpl --concurrency 10 先のプロンプトテンプレートは社内知識をEmbeddingに変換する時に検索精度向上のために利用しているもので、他にも社内のよくある質問集の多言語対応をする際にも似た要領で一括実行しています。 最近では膨大な業務データのLLMを利用したタグ付けにも使用されたりと、簡単に使える一括処理として広く使われるようになってきました。 Jupyter Notebookでの高度なLLM活用 一方で、CSVの行ごとの一括処理ではまとまった単位で処理をしたい時や複雑な前処理が必要な時に対応することができません。 KEELチームはプラットフォームの機械学習サポートとして JupyterHub を運用しており、そこでそういった高度なユースケースに対応しています。 JupyterHubは社内の認証基盤と統合されており、社員であればURLにアクセスするだけでJupyter Notebookを利用可能です。 そして認証基盤との統合により keelai のAPIをNotebook上から認証なしに実行することができ、すぐにプログラムからLLMを使い始めることができます。 余談ですが、Jupyter Notebookは比較的リッチなUIを実現できるため、このような簡易的な画像生成用のNotebookも提供しています。 これとは別にStable Diffusion WebUIのホスティングもしていて、利用者は用途に応じて画像生成AIを使い分けることが可能です。 このJupyter Notebookの表現力を活かし、Slack上の keelai でCode Interpreter相当の機能を実現するためのインタフェースとしても利用されます。 また、コマンドラインツールの実行者はソフトウェアエンジニアに限られてしまいますが、Jupyter Notebookであれば誰もが簡単に実行できます。 共有ストレージをNotebookにマウントして、作成したJupyter Notebookの配布機構も備えたことで、作成したLLMの高度なユースケースを配布するプラットフォームとしても機能するようになりました。 まとめ 今回はLIFULLでのLLMを利用したPlatform Engineeringを紹介しました。 LIFULLのプラットフォームを開発する我々KEELチームは、Kubernetesベースの内製PaaSであるKEELを開発・運用しながら、社内で汎用AI(仮)と呼ぶAutoGPT実装 keelai も開発しています。 そして、コードジェネレータを備えた keelctl 、プラットフォームのユーザ体験を補完するChrome Extensionである keelext といった複数のチャネルを活かして、LLMを利用したPlatform Engineeringを進めてきました。 Slack Automationsを利用した疑似的なLLMノーコードツールやJupyter Notebookの提供では、利用者が自律的にLLMを用いた業務改善を行い更にそれを配布する仕組みも作ることで、社内のLLM活用にレバレッジを効かせることにも成功しています。 今後は根幹を担う汎用AI(仮)を中心に機能を増やしつつ、KubernetesクラスタであるKEEL自身のAIOps(?)を強化し、あらゆる面からLLMを使ってLIFULLの生産性向上に貢献していきたいと考えています。 もし興味を持っていただけた場合は、是非カジュアル面談をさせてください！ hrmos.co hrmos.co

エンジニアの小林と申します。 LIFULL HOME'S の横断領域の開発を担当しています。 私たちの開発しているLIFULL HOME'Sでは、A/Bテストの実施によって市場学習（≒PDCA）の回数を増やし、より良いプロダクトを作り上げることを目的として、日々多くのA/Bテストが実施されています。 しかしながら、いくつかの問題があります。 今回はLIFULL HOME'SにおけるA/Bテストの成熟度と課題、そして現在の取り組みをご紹介します。 A/Bテストの成熟度と課題 A/Bテスト成熟度モデル 課題 新しい取り組み 構成図 A/Bテスト一覧 A/Bテスト詳細（概要） A/Bテスト詳細（結果） 解決された課題 これからの展望 まとめ A/Bテストの成熟度と課題 A/Bテスト成熟度モデル Kohavi, R., Tang, D., & Xu, Y. (2020).によるA/Bテスト成熟度モデルに照らすとLIFULL HOME'SのA/BテストはWalkフェーズへ移行を目指している段階です。 Walkフェーズへ移行するにあたり課題となったのは A/Bテスト設計の標準化 結果の信頼性の確立 の2点です。 table { border-collapse: collapse; } th { border: solid 1px #666666; color: #000000; background-color: #ff9999; } td { border: solid 1px #666666; color: #000000; background-color: #ffffff; } フェーズ 概要 Crawl A/Bテストで利用するユーザー識別子の発行と結果を集計するための基盤が整っている。 Walk 標準的な指標の定義ができている。 ユーザーのサンプル比率のミスマッチ（SRM）が起きないように仕組み化されている。 A/Bテスト結果の信頼性が確立されている。 Run 評価基準が合意され、システマチックな意思決定するプロセスが確立されている。 Fly テスト集計～プロダクトへのロールアウトまで全てのプロセスが自動化されている。 参照： Kohavi, R., Tang, D., & Xu, Y. (2020). Experimentation Platform and Culture. In Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing (pp. 58-78). Cambridge: Cambridge University Press 課題 EDDの導入を済ませ、次の課題は更なる標準化と結果の信頼性の確立となりました。 ここで課題となるのが集計・分析の過程です。 A/Bテストのプロセスを整理すると以下の図のようになります。 A/Bテストの各プロセス 1. テストの設計 の標準化についてはEDD（Experimental Design Doc）の導入により一定の改善が行われています。 EDD導入については以下のnoteをご覧下さい。 note.com 2. テストの実装 、 3. テストの実施 については半年ほど前にA/Bテスト用社内packageが開発され、新規マイクロサービスにおいてはA/Bテストを低コストで実装できるようになりました。 www.lifull.blog 4. テストの計測 については主にBigQueryに接続したGoogle スプレッドシートにおいて行われています。 このGoogle スプレッドシートのテンプレートが部署（賃貸・分譲 etc...）によって異なり、BigQueryに対するクエリやベイズ計算のロジックもそれぞれに実装されています。 スプレッドシートで表示している値は汎用性を持たせられており、EDDで判断指標として指定したGoal MetricsやGuardrail MetricsなどのMetrics以外にも多くの指標を取得しています。 また、この知見を蓄積するドキュメントはテストごとにConfluence（アトラシアン社製企業向けWiki）にまとめられていますが、Confluenceは検索性が低くInstitutional memoryの蓄積（組織全体が過去の経験から学んだことを、どれだけ覚えているか）という観点では質が低い状態です。 新しい取り組み 前項で挙げた課題を解決するために A/Bテストをはじめとしたコントロール実験を正確に測定し、意思決定を明確化すること 結果・分析を記録し、施策の知見を未来に向けて蓄積すること を目指したコントロール実験実行・分析基盤としてexp-libraryというA/Bテスト管理基盤を作成しました。 構成図 exp-library構成図 メトリクス定義の複雑な入力を受け付けるために、Next.jsを採用しました。 Python製の集計用バッチを定期実行してBigQueryからユーザーの行動データを取得し、集計・ベイズ計算を実行してBigQueryに保存しています。 A/Bテスト一覧 テスト一覧 登録されたA/Bテストの一覧です。 検索と様々な絞り込みが可能です。 後述するテスト情報の詳細の内容も含めて文字列検索をするため、Confluenceで感じていた過去の施策の検索しにくさを解消します。 A/Bテスト詳細（概要） A/Bテスト詳細画面 登録されたA/Bテストの詳細情報です。 こちらで計測のオン・オフが可能です。実施期間中のみ自動で計測する仕様にもできましたが、過去の施策の結果も収集するために、手動で切り替えられるようにしています。 こちらから施策のドキュメントにアクセス可能です。 A/Bテスト詳細（結果） A/Bテスト詳細（結果）画面 計測結果を表示しています。 解決された課題 今回作成した集計バッチで全てのA/Bテストを集計することで、全社で集計フローが統一されました。 また、これまでは部署ごとのスプレッドシートの中にあったクエリや計算ロジックがPythonのコードとしてGitHubで管理されることで、統計に知見のあるエンジニア・データサイエンティストが内容を精査・改善するハードルが下がりました。 これによりテストの計測について、一定の標準化が成され、結果の信頼性を担保に向けて検証が容易になりました。 これからの展望 現在このexp-libraryは既存のスプレッドシートから移行するべくβテストと称して社内の一部の施策担当者からFBを受け、改善を行っています。 今後はエンジニア・企画の工数を削減し、A/Bテストの回数を増やすべく、以下の機能実装を行っていきます。 A/B テスト勝敗判定の自動化 A/B テストの開始・終了の自動化、A/B寄せの自動化 Feature Flag 多腕バンディットアルゴリズムによるコントロール実験機能 まとめ exp-libraryの命名の由来は以下のとおりです。 市場調査の数を指数関数的（exponentially）に増やし、あらゆる実験（experiments）を収集し、経験(experience)を蓄積し、公開する。 「公共図書館の本質的な機能は、資料を求めるあらゆる人々やグループに対し、効率的かつ無料で資料を提供するとともに、住民の資料要求を増大させるのが目的である」 中小都市における公共図書館の運営(1963) 会社の資産とも言える施策の試行錯誤を正確に記録した資料を残し、今後に活かしていくことを目的に基盤を作成しました。 LIFULL HOME'SのA/Bテストをより良い状態にしていくために今後も改善をしていきます。 ともに良いプロダクト作りをしてくれる仲間を募集しています。 hrmos.co hrmos.co

こんにちは、グループデータ本部データサイエンスグループの清田です。 5月28日から31日にかけて静岡県浜松市にて開催された 人工知能学会全国大会（JSAI 2024） に参加してきました。 LIFULLでは、今年もシルバースポンサーとして協賛しております。 今年は、学会理事および副実行委員長として運営にも関わっていましたので、舞台裏の部分も少しお伝えします！ なお、昨年熊本で開催されたJSAI 2023の様子も書かせていただいています。 www.lifull.blog 過去最多の参加人数とハイブリッド開催のメリット 人工知能学会 は、1986年に設立された学術研究団体で、「人工知能（AI）に関する研究の進展と知識の普及を図る」ことを目的としたさまざまな活動を行っています。 この記事でお伝えする全国大会のほか、以下のようなさまざまな事業を行っています。 学会誌・論文誌の発行 研究会の開催 各種セミナーの開催 産業界と学術界の連携シンポジウム（SIAI）の開催 今回のJSAI 2024は、約3800名の参加者が集まり、過去最多の参加人数となりました。 現地での熱気から、ChatGPTに端を発する生成AIブームを受け、AIに対する関心がますます高まっていることを肌で感じました。 JSAI 2024のクロージングセッションにて発表された参加者数の推移 上のグラフに示されているように、全国大会の参加者数は、コロナ禍によるフルオンライン化を経て、コロナ禍前を超える参加人数となっています。 2020年と2021年は完全オンライン開催でしたが、2022年からは現地会場での開催が復活するとともに、ハイブリッド開催となりました。 グラフを見ると、オンラインで参加できるようになったことで、これまで仕事や家庭の都合などの諸事情で参加できなかった方々が参加者層に加わったように思えます。 また、全国大会では、Zoomによるオンライン参加だけでなく、「録画の後追い再生」など、便利なサービスも提供されています。 オンライン参加の方だけでなく、現地参加の方からも、これらのハイブリッド開催ならではのサービスは非常に好評であることが、アンケートの結果からわかっています。 ハイブリッド開催は、設備や運営スタッフの配置などで大きなコストがかかるものの、ニーズも非常に大きいため、来年以降も継続される方針です。 JSAI 2024におけるダイバーシティ＆インクルージョンへの取り組み 人工知能学会全国大会は、毎回多様な分野の方々が参加するイベントであり、実際に参加してみると、非常にダイバーシティの大きなコミュニティであることを肌で感じます。 ただ、参加者の属性についていえば、まだ大きな偏りがあります。 代表的な属性である「性別」について見ると、女性の参加者の割合は15%未満であり、依然として男性の参加者の方が圧倒的に多い状況です。 （人工知能学会の会員比率については、さらに偏りがあり、女性の割合は約6%です） 社会を根本から変革する可能性を持つAI分野のコミュニティには、さまざまなバックグラウンドの人材が集まることが求められます。 もし、AI分野の研究者の属性が、極端に偏ってしまった場合、構築するAIが実社会で活用できないものになってしまう可能性も指摘されています。 私が人工知能学会の編集委員長を担当していた時期に、学会誌2020年9月号にて企画した特集「ダイバーシティとAI研究コミュニティ」でも、この問題を取り上げました。 特集の共同企画者の伊藤貴之先生（お茶の水女子大学）へのインタビュー記事がAINOWに掲載されていますので、もしよろしければぜひご覧ください。 ainow.ai 人工知能学会では、この問題への取り組みを進めるため、「多様性・包摂推進委員会」を2023年に設立しました。 sites.google.com 委員長の高野雅典さん（サイバーエージェント）が、コミュニティにおける属性の偏りがなぜ起こるかを解説されています。 結果の不平等と機会の不平等のフィードバック構造（多様性・包摂推進委員会のWebサイトから引用） こうした状況を改善するため、多様性・包摂推進委員会では、以下のような方針を掲げて活動を行っています。 コミュニティ醸成・支援 学会参加者・会員・運営者の啓発 制度・慣習に関する課題の共有と解決策の提案 具体的な活動の一つとして、2023年11月に開催された人工知能学会合同研究会2023、および今回のJSAI 2024にて、「女性向けランチ会」を開催しています。 ダイバーシティの課題として挙げられるマイノリティの人々の「ロールモデルの少なさ」、つまり「職業・生き方において参考にする/したい人と出逢う機会が少ない」という問題を改善するため、マイノリティの方々どうしが交流する場を創出することが、このランチ会の目的です。 今回、学会理事として冒頭にご挨拶をしましたが、参加者の方々が交流を心から楽しまれている様子を拝見することができました。 株式会社onerootsの榊原 美穂さんが、参加者として報告記事を投稿されていますので、こちらもぜひご覧ください。 www.wantedly.com オーガナイズドセッション「不動産とAI」 今回のJSAI 2024では、2017年から2019年まで3回にわたって開催した「不動産とAI」オーガナイズドセッションを、4年ぶりに開催することができました。 sites.google.com 今回は、以下のようなテーマで発表募集を行い、応募があった6件の研究発表とパネルディスカッションでプログラムを編成しました。 不動産分野への生成AI技術の応用 不動産価値の推定 マルチメディアとしての不動産ビッグデータの活用 経済学、建築学、地理学、都市学など、不動産と密接に関連をもつ分野との連携 パネルディスカッションでは以下のようなテーマで、多岐にわたる議論を行いました。 生成AIへの期待や課題提起 既存ストックの価値を高めるためにAI技術が果たせる役割 不動産領域の多様なデータへの要望や課題提起 学際である不動産の他業界との関わりについて 来年も、引き続き「不動産とAI」をテーマとしたセッションを企画していく予定です。 ご期待ください！ 来年は大阪での開催 来年の全国大会（JSAI 2025）は、 EXPO 2025 大阪・関西万博 の会期中の大阪で、2025年5月27〜30日に開催を予定しています。 来年の全国大会会場は大阪・中之島にあるグランキューブ大阪です JSAI 2025では、実行委員長という役割で関わる予定です。 大阪・関西万博との連動企画など、より社会に開かれた学会への変革に向けた取り組みを進めてまいります。 参加される皆様に満足していただける全国大会になるよう、微力ながら尽力してまいりますので、皆様どうぞよろしくお願いいたします！ LIFULLでは、共に成長しながら働く仲間を募っております。 現在、以下の職種を募集しております。LIFULL HOME’Sデータセットなど、豊富な研究開発資源を活かしながら、多様な社会課題の解決に向けた研究開発やプロダクト創出に取り組んでみませんか？ hrmos.co ご興味をお持ちの方、ぜひお気軽にご相談ください！

こんにちは、エンジニアの中島です。 この記事は2024年7月のLIFULL社でのアクセシビリティ改善およびやっていき活動の報告です。 この活動報告は月次で出すかもしれないし出さないかもしれないくらいの温度感で運用されています。 目次 目次 サービス改善 ログイン画面の入力フォームの名前設定 物件登録画面のステップ情報のスクリーンリーダー対応 売買物件登録画面のテーブル文脈の排除 物件登録画面内の物件画像編集モーダルのアクセシビリティ対応 取扱物件の一覧ページにある各コントロールへの名前設定 育成・啓発の取り組み アクセシビリティ1on1 社内表彰 お知らせ サービス改善 本期間中の改善取り組みのターゲットはLIFULL HOME'S 賃貸・流通マネージャーサイトです。 こちらはLIFULL HOME'Sをご利用いただいている会員様(不動産会社様)が、物件を掲載する際にお使いになる管理画面になります。 諸事情で発表できないものもありますが公開可能な取り組みを紹介させていただきます。 ログイン画面の入力フォームの名前設定 ログイン画面の入力フォームには一部名前が設定されていないコントロールがあり、支援技術ユーザーにとっては何の入力が求められているのかがわかりにくい状況がありました。 これらのコントロールに適切な名前を設定する修正を行いました。 物件登録画面のステップ情報のスクリーンリーダー対応 物件登録画面は入力ページ、確認ページ、登録完了ページの3ステップで構成されています。 そのステップの現在地情報は画面上部に画像で表示されていますが、代替テキストが「進捗状況」とだけ書かれていて、ステップの一覧、現在地情報を支援技術から読み取ることができない状況にありました。 そこで、代替テキストを空にし、スクリーンリーダー用にaria-currentを設定した順序リストで補うように修正しました。 売買物件登録画面のテーブル文脈の排除 売買の物件登録画面はレイアウトのためにテーブルを使っており、また余白のために空白のセルを使っていたりとセマンティクスが不適切であり、スクリーンリーダーでの読み上げが壊滅的であるという問題がありました。 前回賃貸物件登録画面でも同様の問題があり、role設定でテーブル文脈を破棄する対応を行いましたが、売買側にも同様の修正をしました。 物件登録画面内の物件画像編集モーダルのアクセシビリティ対応 賃貸・売買ともに物件登録画面内に登録する物件画像を編集するためのモーダルがあります。 モーダルがモーダルとして認識されない、モーダル内のコントロールにフォーカスが適切に移動しない、フォーカスがトラップされない、モーダル内のコントロールのフォーカスインジケータが見えないなど様々な問題がありました。 これらを解消すべく、求められるrole/stateの設定およびフォーカス管理、フォーカスインジケータの可視化対応などを行いました。 取扱物件の一覧ページにある各コントロールへの名前設定 不動産会社様がLIFULL HOME'Sに掲載しようと登録した物件の一覧ページには、確認したい物件を絞り込むための検索フォームが設定されていますが、これらのコントロールには名前が設定されていないものが多くありました。 それぞれのコントロールに名前を設定し、支援技術ユーザーでもコントロールの目的を理解できるよう修正しました。 育成・啓発の取り組み アクセシビリティ1on1 本期間中は先月と同じくフロントエンドエンジニア6人、デザイナー1人に対して行いました。 内容はWCAGの解説、APG(aria authoring practices)の解説、coga-usableの解説、実際のアプリケーション開発時でのアクセシビリティ配慮に関する相談などが主なものとなります。 社内表彰 LIFULL社ではクォータに一度、エンジニアがそろうエンジニア総会というものがあり、そこにアクセシビリティへの取り組みを表彰する枠が用意されています。 4Q(2024/07)の表彰はLIFULL HOME'S アーカイブ開発チームと売買開発チームでした。 アーカイブチームはマンションブランドごとの物件一覧ページのリニューアルにおいてフルキーボード操作、及びロストすることのないフォーカスマネージメントを実現した点が評価されました。 また売買開発チームは売買物件の一覧ページ末尾にある不動産会社情報カルーセルのタブストップ数を減らし、キーボード操作をより用意にした点が評価されました。 お知らせ LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

グループデータ本部データサイエンスグループの嶋村です。 データサイエンスグループが主催でデータサイエンス系の自社イベント『 LIFULL AI Hub 100 ミニッツ ＃2 「ファクトブック」 』を開催しました。第1回目の『 LIFULL AI Hub 100ミニッツ #1 「LLM（大規模言語モデル）の研究開発」 』に引き続き、オフライン・オンラインともに盛況となり、今回も講演を聴講していて学びがありました。当日は、 X（旧Twitter）でも実況 しておりましたので、当日の様子が少しでも伝わればと思います。 主催のデータサイエンスグループはグループデータ本部配下の研究開発組織になります。グループデータ本部は、LIFULLグループで生まれる新たなデータを安全かつ効果的に活用できるようにし、事業の変化と持続的な成長を促進することを目指している組織です。その中で、データサイエンスグループは「活用価値のあるデータを創出」し、「データを活用した新たな機能やサービス」の研究開発に取り組んでいます。 今回のテーマである「ファクトブック」は、以前本ブログでも記載した「 LIFULLファクトブックで目指す真のドメイン知識獲得 」に関する発表となります。弊社LIFULLの事例だけではなく、先行してファクトブック活動を続けられている東北一円にドラッグストアを展開する薬王堂さまの事例に関する発表もありました。 第一部　トークセッション　「ファクトブック事例」 第一部では、まず、 LIFULLデータサイエンスパートナである鹿内氏 から企業における分析の実情や、ファクトブック活動の概要について説明がありました。 データの利活用に関する調査結果があり、その中で「特に課題・障壁はない」と回答している企業も多いが、本当にそうだろうか？という問いは大変興味深かったです。実は課題に気付けておらず、真のデータ利活用は進んでいない、という可能性もあると感じました。データサイエンスグループも様々な部署と連携して社内でのデータ利活用に向けた取り組みをすることがありますが、大小問わず課題は山積でまだまだ伸びしろがある状態なため、日々革進させていきたいです。 次に、LIFULLデータアナリストの羽賀と、薬王堂の西郷さまから、データを企業運営にどのように活かしているかについて講演がありました。 LIFULL羽賀からは社内で実施しているファクトブック活動の事例や、これまでの実績や課題に関する発表がありました。作成したファクトブックコンテンツに基づいて考察をする読み会の開催数は15回にわたり、のべ参加者数は約200名であることや、読み会での考察をもとに社内で新たな発想が生まれた事例が紹介されました。一方で、熱量ある参加者を継続的に確保するにはどうしたら良いか、という課題も提起されていました。 また、西郷さまからは薬王堂さまが提唱する 薬王堂PBMA（Purchase Behavior Modification Analytics） が紹介され、その薬王堂PBMAの実現に向けてファクトブック活動が重要な取り組みであることが話されていました。初期の時点では数名で実施していたファクトブック活動も、営業メンバやインターンシップを交えて、徐々に拡大されている事例は、弊社でもとても参考になりました。 第二部　クロストーク　パネルディスカッション クロストークではファシリテータの鹿内氏と、登壇者である羽賀・西郷さまを交えて、ファクトブック活動をどのように発展させていくかというディスカッションがありました。 ファクトブック活動は読み会が重要ではありますが、ファクトブックコンテンツそのものが整っているのが大前提です。そのコンテンツで、どのような項目を、どのように見せるのか、試行錯誤の話がありました。たとえば、統計分野ではお馴染みの累積分布を見せるにしても、累積分布に馴染みのない参加者も居るため、丁寧に説明をしたりと工夫がありました。 ファクトブックコンテンツを作成していく上では、データが整備されていることも欠かせず、データクリーニングの重要性についても語られていました。データがバラバラで集約できていないケースや、データはあるがフォーマットがバラバラで分析しづらいケースなどもあるため、いかに使いやすいデータを作るかが鍵となることは間違いありません。 ファクトブック活動を発展させていく上では、キーマンが欠かせず、そのキーマンは誰なのかという問いは興味深く参考になりました。薬王堂さまでは、役職や年齢は関係なく、熱意があり行動を起こせる方を起用していました。薬王堂さまの場合、代表取締役である西郷さまのトップダウンのコミットメントに合わせて、熱量ある人材によるボトムアップのコミットメントが合わさることで、発展されていったと感じました。 ファクトブックコンテンツというアウトプットで満足するのではなく、アウトカムにつなげることが重要だ、というディスカッションもありました。確かにアウトプットだけをしていると、「これは何のための分析だろう」となってしまうことは往々にして起こりがちです。そのため、ファクトブック活動を通じてアウトカムにつなげるというイメージが共有できていると、地道な分析であっても意義が理解でき、また分析結果に基づいたネクストアクションも生まれやすいと感じます。 クロストークの最後に総括として、鹿内氏から、ファクトブック活動は「各職種の領域にまたがるデータについて、コミュニケーション（ディスカッション）をするきっかけになる」という話がありました。読み会を通じてデータについて相互理解を深めることで、データドリブンな文化の形成につながっていくと思うため、改めてファクトブック活動の重要性を再認識できました。 以上のようなディスカッションがあり、運営側の立場ではありましたが、聴講者の一人として大変興味深く学びになりました。今回の学びをLIFULLファクトブックでも活かしていきたいです。 おわりに 今回はデータサイエンス系の自社イベント「LIFULL AI Hub 100ミニッツ」の取り組みについて紹介しました。次回は第3回のイベントも企画しており、気軽にご参加いただけると嬉しいです。 LIFULL Co., Ltd. - connpass 最後になりますが、データサイエンスグループでは「活用価値のあるデータを創出」し「データを活用した新たな機能やサービスの研究開発」を加速して下さるシニアデータサイエンティストを募集しています。また、今回のファクトブック活動を推進している羽賀の部署でも、データアナリストを募集しております。 hrmos.co hrmos.co 興味お持ちいただける方は、 カジュアル面談 も行っていますのでお気軽にご連絡ください。

こんにちは、エンジニアの中島です。 この記事は2024年4月〜6月のLIFULL社でのアクセシビリティ改善およびやっていき活動の報告です。 この活動報告は月次で出すかもしれないし出さないかもしれないくらいの温度感で運用されています。 目次 目次 サービス改善 取扱物件検索の検索方法選択タブのボタン化 物件登録画面(賃貸のみ)のタブのボタン化とテーブル文脈の破棄 物件登録画面(賃貸のみ)内のダイアログのキーボード操作を可能に 物件登録画面(賃貸のみ)内の郵便番号からの住所入力補完機能をキーボード操作可能に 物件登録画面(賃貸のみ)内の画像登録UIをキーボード操作可能に 取扱物件一覧(賃貸のみ)内のフォーカス不能なボタンを修正 育成・啓発の取り組み 新入社員研修 アクセシビリティ1on1 WCAG解説書 輪読会 社内表彰 お知らせ サービス改善 本期間中の改善取り組みのターゲットはLIFULL HOME'S 賃貸・流通マネージャーサイトです。 こちらはLIFULL HOME'Sをご利用いただいている会員様(不動産会社様)が、物件を掲載する際にお使いになる管理画面になります。 諸事情で発表できないものもありますが公開可能な取り組みを紹介させていただきます。 取扱物件検索の検索方法選択タブのボタン化 マネージャーにログイン後に表示されるページの取扱物件検索の検索方法選択タブはdivで実装されており、フォーカス不能・選択不能であるという問題がありました。 いったんそれをボタン化し、キーボード操作を可能にしました。 またタブ内に表示される各フィールドに適切な名前を設定しました。 物件登録画面(賃貸のみ)のタブのボタン化とテーブル文脈の破棄 物件情報を登録する画面では、多岐にわたる入力をする必要があり、そのためタブを使って情報を分割しています。 しかしながらこのタブもdivで実装されており、フォーカス不能・選択不能であるという問題があったため、こちらも同様にボタン化する対応を行いました。 また、この物件登録画面はレイアウトのためにテーブルを使っており、また余白のために空白のセルを使っていたりとセマンティクスが不適切であり、スクリーンリーダーでの読み上げが壊滅的であるという問題がありました。 こちらは組み直しが大規模改修となり困難なためrole設定でテーブル文脈を破棄する対応を行いました。 物件登録画面(賃貸のみ)内のダイアログのキーボード操作を可能に 物件登録画面内にはダイアログが表示されるボタンが随所に設置されています。 しかし、多くは click ではなく mousedown イベントによって起動するように実装されており、キーボード操作でのダイアログ表示ができないという問題がありました。 これらをクリックに変更し、キーボードでのダイアログ開閉を可能にしました。 またダイアログのrole設定不備・および名前設定の不備・キャンセル、送信ボタンのフォーカス不能不備などの問題も合わせて修正しました。 物件登録画面(賃貸のみ)内の郵便番号からの住所入力補完機能をキーボード操作可能に 物件登録画面内に住所入力を簡単に行うために郵便場号から住所入力を行う機能があります。 しかしこちらも機能を呼び出すボタンにフォーカスが当たらないといった問題ありました。 こちらも適切なrole、振る舞いの設定を行い、キーボード操作での利用を可能にしました。 物件登録画面(賃貸のみ)内の画像登録UIをキーボード操作可能に 物件登録画面には物件の画像を登録するUIがありますが、こちらも画像の選択ボタン、削除ボタンなどいくつかのボタンがキーボード操作不能という問題がありました。 他と同様に適切なrole、振る舞いの設定を行い、キーボード操作での利用を可能にしました。 取扱物件一覧(賃貸のみ)内のフォーカス不能なボタンを修正 会員様の取扱物件を一覧表示する画面には、表示された物件の編集や削除を行うためのボタンなどが数多くあります。 いずれも名前の設定漏れがあったりキーボード操作ができないといった問題がありました。 他と同様に適切な名前設定、role設定、振る舞いの設定を行い修正を致しました。 育成・啓発の取り組み 新入社員研修 弊社では毎年6月ごろに新入社員(新卒・中途)向けにアクセシビリティの理解を深めるための研修を行っています。 この研修は今年で3回目で、内容は freeeさんのアクセシビリティ研修 の資料を参考にさせていただいており、毎年LIFULLに合わせてマイナーチェンジを行っています。 アクセシビリティとは何か、基本的な考え方など説明する会は営業職等を含めた全職種対象で行い、その後より具体的な内容をものづくり職種を対象に行いました。 サービス作りに直結する学びになったという声だけでなく、営業資料作成時にも気を付けていきたいなど、多岐にわたる感想をいただきました。 アクセシビリティ1on1 本期間中は先月と同じくフロントエンドエンジニア6人、デザイナー1人に対して行いました。 内容はWCAGの解説、APG(aria authoring practices)の解説、coga-usableの解説、実際のアプリケーション開発時でのアクセシビリティ配慮に関する相談などが主なものとなります。 WCAG解説書 輪読会 アクセシビリティやっていき勢向けにWCAGの輪読会を隔週で行っています。 本期間中は4月1日、5月30日、6/27日の3回行われました。 範囲は達成基準1.3.4〜1.4.3です。 社内表彰 LIFULL社ではクォータに一度、エンジニアがそろうエンジニア総会というものがあり、そこにアクセシビリティへの取り組みを表彰する枠が用意されています。 3Q(2024/04)の表彰はLIFULL HOME'S 賃貸開発チームでした。 LIFULL HOME'S(賃貸)の問い合わせフォームのアクセシビリティ改善に取り組んでいただいたことが評価されました。 キーボード操作時の細かい不備や、Web標準に準拠したフォームの入力支援などさまざまな修正が行われました。 お知らせ LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

QAの山下です。 QAグループという名前で横断組織として手動&自動テストやツール開発、プロセス改善など仕組みづくりに取り組んでいます。 今回は LIFULL HOME'S の開発で実行されているE2Eテスト（リグレッションテスト）をシフトレフトし、実行時間を80％短縮した話を紹介します。 ざっくり何をやったのか 大規模なリポジトリでのdevelopマージ後のE2Eテストの9割をPR上で実行可能にした コードのpushからE2Eテスト完了まで5～8分で完了できる 運用上の課題も頑張って解消した 目次 ざっくり何をやったのか 目次 結論 前提情報 E2Eテストとは リグレッションテストとは LIFULL HOMESでのE2Eテストの位置付け シフトレフトとは EEとは 対象のプロダクトの規模 起こっていた課題 テストの削除とリファクタを行い、テストケースを3割削減した デプロイ後のアプリケーションに対してe2eテストを実行できるようにした 開発チームとのコミュニケーションを積極的に行い、運用課題の発見と改善を実施した テスト結果通知のコメントが量産されPRが見づらくなる 問題の概要 検討事項 解決法 マージ要件を満たせない 問題の概要 解決法 検討事項 テストの再実行がやりづらい 問題の概要 解決法 これからやりたいこと 結論 以下の図の通りです。 Git-Flow をベースとしたフローに則り開発されていたリポジトリで、developマージ後に実施されていたE2Eテストの9割をPR上で実⾏できるようにシフトレフトしました。 コードのpushからE2Eテスト完了まで5～8分で完了します。 シフトレフト前後の図 前提情報 今回のPJの紹介にあたって前提となる情報を記載します。 E2Eテストとは 本番相当の環境で、ビジネスプロセスを最初から最後まで実⾏するテストの⼀種です。（ISTQBより） LIFULL HOME'Sでは内製の⾃動テストフレームワーク「 Bucky 」を使ってE2Eテストを実施しています。 リグレッションテストとは ソフトウェアの変更されていない領域の欠陥を検出するためテストの⼀種。（ISTQBより） Aの機能に手を加えたのにBの機能でバグが出た！のような現象を検知するテストです。 LIFULL HOMESでのE2Eテストの位置付け 重大な問題点がないことを(回帰テスト観点で主要機能の動作)を保証する。 テストした結果、不具合が発見された場合は修正を行う。修正が完了しない限り、本番へリリースすることはできない。 テストスコープは以下です 動かなくなると重大な被害を被る機能群 物件の検索や資料請求等 過去に障害が起こった機能群 確認が漏れそうな機能群 シフトレフトとは テストおよび品質保証の活動の実施を、ソフトウェア開発ライフサイクル内で可能な限り早く⾏うためのアプローチ。（ISTQBより） 今回はdevelopブランチで実施されていたテストをPR上で実行するようにしたことでシフトレフトを実現しています。 シフトレフトするメリットは以下が挙げられます 早期にフィードバックできることで大きな手戻りやバグを未然に防ぎ、全体のテスト時間を短縮しソフトウェアの品質向上が期待できます。 EEとは 瞬時に検証環境が手に入るEphemeral Environmentの略称。 Pull Requestの内容をもとに一定期間アクセス可能な環境の複製をデプロイする機能。 Vercelのpreview環境のようなもの 弊社の全社アプリケーション実行基盤である KEEL の1つの機能です。 対象のプロダクトの規模 今回実施した対象のリポジトリの規模を記載します。 LIFULLの看板サービスであるLIFULL HOME'Sの主要機能が実装されているリポジトリ 1ヶ月間のauthor数: 約100人、Merged PR数: 約200 起こっていた課題 developブランチマージから本番環境反映まで8.5時間かかっていた QAGの工数が1~4時間/日かかっていた 基本的に朝9時からdevelopブランチに対して自動テストを実行 実行後の結果を確認、バグが検知されれば開発チームに仕様確認 14時くらいに本番環境反映 E2Eテストでバグを検知した時の手戻りの多さ Revert対応率は3年連続で50%を超えていた QAGと開発チームのコミュニケーションに時間がかかる 弊社QAGは横断組織で、機能開発チームに常駐しているわけではありません。そのためE2Eテストが失敗した際に、E2Eテストのメンテナンスが必要なのか、バグなのかがすぐに判断できませんでした。 都度開発チームに調査依頼を投げていたので、両チームの負担となっていました。 ここまではこのPJに関する前提状況を書きました。ここからはPJの中で実施したことを時系列順で書いていきます。 テストの削除とリファクタを行い、テストケースを3割削減した 前述 したdevelopブランチマージ後に実施していたテストは、合計400ケースほどありました。これらをそのまますべてシフトレフトすると以下の懸念がありました。 ※後述のリファクタは保証したい内容は変えずにシナリオを変えることを指してます。例えば元々1ケース1アサート*2 だったシナリオを1ケースで2アサーションするように変更する等です。 実行時間が長いことで開発者体験が悪くなる 最悪の場合、QAと開発者の対立の原因になる 再実行数が増えコストが上がる これらの問題を解決するため、テストの再設計を実施しました。結果としてテストケース数を3割削減、またテストの実行時間も削減できました。 この項目で実施したことは以下です。 テストを実行時間順にソートする 実行時間が長いものから削除、リファクタ、再設計箇所の洗い出し テスト技法を用いて検討 該当のテストケースが追加された時の意図(バグチケット等)を基に、現在でも同じテストケースが必要か検討 レビュー実施 開発者との合意形成 テストの削除、リファクタ、再設計を実施したことによりステークホルダーに影響があるため合意を形成する必要がありました。 ステークホルダーは機能開発のエンジニア、企画職 合意は以下の内容で形成しました 対象テストケース 削除対象とした理由 実装 デプロイ後のアプリケーションに対してe2eテストを実行できるようにした 本題とは離れるので詳しくは割愛しますが、Helmにおける Chart Hooks を編集し、前述のEEデプロイ後にEEに対して E2Eテストを実行するようにデプロイパイプラインを修正しました。 開発チームとのコミュニケーションを積極的に行い、運用課題の発見と改善を実施した ここまでで「リモートブランチにPushされる度にPR上でE2Eテストが実行される」状態にはできました。しかし作ったら終わりではありません。ここから運用課題とどう向き合ったのかを書いていきます。 挙がっていた運用課題は以下です。 テスト結果通知のコメントが量産されPRが見づらくなる E2Eテスト特有の不安定さ故にマージ要件を満たせない テストの再実行がやりづらい それぞれについて問題の概要、検討事項、解決法を書いていきます。 テスト結果通知のコメントが量産されPRが見づらくなる 問題の概要 現状E2Eテストが完了した際に以下のようなコメントがされます。 画像 E2Eテスト結果確認コメント 開発している時には気づけなかったのですが、コミット数が多くなってくるとコメントがその分量産されPRの見渡しが悪くなるとのフィードバックをもらいました。 検討事項 「PR内に存在する過去のE2E結果コメントを削除→新規のテスト結果コメントを投稿」の処理に変えれば良いのでは？と考えました。 懸念としては、PR内で過去のテスト結果を見ることができなくなることでした。 しかし 過去のテスト結果を見ることはユースケースとして多くない 別のマネジメントツールがあり、過去の結果を見たくなった時はそこからPRの番号で閲覧できる ので問題無しと判断しました。 解決法 以下の処理に変更しました。 PR内に存在する過去のE2E結果コメントを削除 新規のテスト結果コメントを投稿 マージ要件を満たせない 問題の概要 このE2EテストはCIとしてPushの度に実行されます。またリグレッションテストとしての役割も持っているので、当然全てのテストが成功してからdevelopブランチに反映されるべきです。 そのため導入時はテストが100%成功していないとマージができないようにしていました。 しかし、このルールでは開発者体験が悪化してしまいました。原因は以下です。 E2Eテストは他のテストレベルと比較して不安定さが高い ネットワークの問題等で1個でも失敗してしまうとマージができない 後述の「テストの再実行がやりづらい」問題のため、テストの再実行に10分かかってしまう。 ABテストが多い LIFULL HOME'Sでは多くのプロジェクトが並行して進んでおり、それに比例してABテストも数多く存在します。 基本的にはE2Eテストシナリオではメインに採用されている方を期待していますが、自動テスト時に期待していない方を引いてしまった場合、UIやロケーターが変わるので失敗してしまいます。 開発者も他チームのABテスト事情を全て把握しているわけではない 解決法 マージ要件に閾値を設ける手段を取りました。 具体的には自動テストのpass率が90%を超えている場合にはマージ可能としました。 検討事項 チーム内で話し合った結果、避けたかったこととしては以下が列挙されました。 バグの流出 自動テストで検知されているバグを無視してマージした結果本番で障害が出る E2Eテストの形骸化 テストが失敗してもマージ可能なため自動テストのメンテナンスをせずに放置される可能性がある。 自動テストのメンテナンス不足で失敗が増え、テスト結果が信頼できなくなる等が起こる傾向にある 開発者体験が悪くなること プロダクトコードに問題が無く、flakyテストによってマージが阻まれる事 他チームで実施されているABテストによってテストが失敗し、マージが阻まれる事 テスト成功率100%を求め続けることで開発者のストレスになる 最悪の場合QAと開発者で対立が生まれる 上記の「バグの流出」と「E2Eテストの形骸化」は自動テスト成功率を100%を強いることで解決できますが、3つ目に関しては自動テスト成功率を100%を強いると起こり得てしまう問題です。 過去の自動テストの結果を見て、flakyテストとABテストで期待していないパターンを引いた場合でも90%は下回らないということが分かりました。 そのためマージ要件をE2Eテストのpass率100%→90%に変更しました。 テストの再実行がやりづらい 問題の概要 テストの再実行を行いたい場合、以下の手順を踏む必要がありました。 EEの再起動 E2Eテストの実行 E2Eテストの結果 特にコードの修正をしていない場合の再実行では、E2Eを再実行したいだけのためにEEの再構築も行わなければなりません。 EE再構築からテスト完了まで10分を超えることもあり、これはユーザーにとってストレスでした。 解決法 GitHub Actionsの workflow_dispatch を使い、E2Eテストの再実行を楽にしました。 以下の流れでテストの再実行が実施されます。 workflow_dispatchでPR番号を入力する 入力されたPR番号から再実行すべきテストケースを取得 入力されたPR番号から再実行対象のFQDNを取得 WorkflowでE2Eテストの再実行用スクリプトを実行 これによってコードの変更をしていない場合でのE2Eテスト再実行の手間が軽減され、時間としては10分→5分ほどにまで削減できました。 これからやりたいこと シフトレフトすることでE2Eテストの実行時間を80%短縮することができ、早期にフィードバックができるようになりましたが、まだまだ改善できる部分があります。 e2eテストの安定化 現在はUIの変更や改修に対して脆いテストが存在しています。これを解消するために data-testid のような自動テスト用の属性をプロダクトコードに導入し、テストの安定化を図りたいです。 アラートの仕組み化 前述の通り閾値を設けてマージの可否を決めています。そのため本来メンテが必要なテストケースが放置されてしまう可能性があります。 現在はQAGが定期的にテスト結果をモニタリングし、担当部署にアナウンスしていますが今後はアラートの仕組みを導入して一定の条件で担当部署に通知するようにしたいです。 ABテストに対応するためのcookie固定化 前述の通りLIFULL HOME'Sでは多くのプロジェクトが並行して進んでおり、ABテストも数多く存在し、この数に比例して「自動テストで期待していないパターンを引いてしまう」という問題が発生しやすくなります。 これを解消するために「e2eテストからのリクエストだった場合はABテストのcookieを固定化する」ような仕組みを開発者と協力し導入したいです。 これからもQAとして品質改善、開発スピード、開発者体験向上に貢献していきたいと考えています。

グループデータ本部データサイエンスグループの嶋村です。 グループデータ本部は、 LIFULLグループで生まれる新たなデータを安全かつ効果的に活用 できるようにし、 事業の変化と持続的な成長を促進 することを目指している組織です。その中で、データサイエンスグループは研究開発組織として、「 活用価値のあるデータを創出 」し、「 データを活用した新たな機能やサービス 」の研究開発に取り組んでいます。 事業を革進し続けて様々な社会課題を解決していくために、 データを最大限に活用できる状態にしていきたい と考えています。その一環として、不動産情報・住宅サイトである LIFULL HOME'S に掲載される 不動産広告画像を定量的に評価（数値化） し、その評価結果をプロダクトの改善に活用できる状態にするための取り組みを続けています。 2024年4月27日に弊社が協賛している「 第88回 Machine Learning 15minutes! Hybrid 」が開催され、今回の取り組みについて登壇をしました。 基盤モデルCLIPを活用した不動産広告画像品質評価 by @LIFULL 画像品質の定量評価とは 画像品質の定量評価をするためには、画像品質の良し悪しを数値で表現する必要があります。しかし、感覚的に画像品質の良さがわかったとしても、その 品質を厳密に数値化することは簡単ではありません 。 たとえば、以下の2つの画像は生成AIを用いて作成した架空の物件の内観写真です。2つの画像を見比べてみて下さい。 室内写真の比較 おそらく多くの方は、左の写真①の方が右の写真②よりも、以下の観点で「良い」と感じるのではないでしょうか。 画像の明るさが適切である（暗すぎない、明るすぎない） 画像がぼやけておらず鮮明に見える 画像の撮影画角が良く広々と見える など しかし、それらを点数（数値）で表現しようとすると、100点満点中、100点なのか、50点なのか、0点なのか、点数を付けるのは難しいと感じるのではないでしょうか。 そこで、データサイエンスグループは 深層学習や画像処理技術を用いて不動産広告画像の見栄えの定量化 を試みました。 画像品質情報の算出と蓄積、そして活用 画像品質に関する情報を作成する取り組みの詳細は前述したスライドでご説明していますが、画像品質の定量化には基盤モデルCLIP（Contrastive Language-Image Pre-Training）の派生であるCLIP-IQA（Image Quality Assessment）を用いました。CLIP-IQAはテキストラベルで指定した品質評価の観点に対して、品質評価結果を数値で出力する仕組みです。 ここでの難しさは どのような評価観点を定め 、 どのようなテキストラベルで評価値を算出するか 、でした。 まず、弊社のコラムで公開している 写真撮影のコツ などを参考に、評価観点を定めました。そして、テキストラベルは様々な表現方法があるため、生成AIを用いて半自動的にベストなラベルを決定する仕組みを作りました。 実験時は膨大な写真画像に対して評価値算出の処理を実行しましたが、弊社の アプリケーション実行基盤KEEL を最大限に活用することで、効率良く実験環境を構築し実験を進めることができました。 画像品質の定量評価は以下のように活用できるのではないかと考えており、今後も新たなデータを創出してサービスを革進させていきたいと熱意を持って取り組んでいます。 画像品質評価結果が良い画像を優先的に表示する 画像品質評価結果に基づいて自動で画像を修正する など おわりに 今回は不動産広告画像を定量的に評価する取り組みを紹介しました。今後も研究開発に関する取り組みをどんどん発信していきたいと思います。 その一環として、データサイエンス系の自社イベント「 LIFULL AI Hub 100ミニッツ 」を定期的に開催しています。当日の様子は togetterでのまとめ をご覧下さい。 次回は7月頃の実施を予定 しており、少しでも興味を持ってくださった方は、 弊社のconnpassアカウント に登録していただけるとイベントのご案内をお届けできます。是非、気軽にご参加いただけると嬉しいです。 最後になりますが、データサイエンスグループでは「活用価値のあるデータを創出」し「データを活用した新たな機能やサービス」の研究開発を加速して下さる シニアデータサイエンティストを募集 しています。 hrmos.co 興味お持ちいただける方は、 カジュアル面談 も行っていますのでお気軽にご連絡ください。

データサイエンスグループの島です。 普段は機械学習システムバックエンドの開発や運用を行っております。 2024年5月25日に半蔵門の本社2Fにて機械学習(AI・人工知能)に関するライトニングトーク(LT)会が開かれました。 素晴らしいLT会でしたので、内容をいくつかシェアさせてください。 第89回 Machine Learning 15minutes! Hybrid - connpass 「Machine Learning 15minutes!」というコミュニティを運営している 門前さん が主催するLT会です。 以前の開催 に引き続き、 LIFULL AI Hub が協賛という形での開催となりました。 現地参加とオンラインのハイブリッド開催で、会場20名、オンライン100名ほどがいらっしゃいました。 様々な方が発表してくださり非常に盛り上がりました。豪華な内容でとても示唆に富んでいました。関係者の皆様、参加いただいた皆様ありがとうございました。 LIFULLからは分析に関わる社員向けのデータ活用施策である ファクトブック に関する発表を行っております。 とても盛りだくさんなLT会ですべてをご紹介できないのですが、LIFULLのような事業会社でのAI活用という視点で心に残ったものを共有させてください。 元木 大介さん【２週間で世界１万ダウンロード 自然言語プログラミングの衝撃】 吉崎亮介さん【仕事の対話をAIでハックする考え方とプロセス】 森 正弥さん 【AIは人の仕事を奪うのか？ AI時代の新たな哲学】 懇親会 元木 大介さん【２週間で世界１万ダウンロード 自然言語プログラミングの衝撃】 元木さん が開発されている自然言語プログラミングフレームワークに関する発表でした。 Zoltraakとniwatokoという２つのプロジェクトが説明されました。 （Zoltraakの名称は『葬送のフリーレン』から引用されています。） github.com github.com Zoltraakはプロンプトとして与えた曖昧な要求から、ドキュメントを生成するためのフレームワークです。例えば要件定義書などを生成できます。 niwatokoでの自然言語からのプログラム生成も検証中のようです。Zoltraakで生成した要件定義書を入力にする使い方があります。汎用的に実現できるとすごそうな予感がします！ 自然言語でのプログラミングが可能になると、開発者の数が10倍くらいになるのでは？というようなお話もありました。ゲームチェンジ感をひしひしと感じます。 2つのプロジェクトを統合すると、プロダクトが一瞬で出来上がるというような世界観ですね。まさに魔法のようです。 Zoltraakを使ってみるとわかるのですが、CLIでの操作が魔法を扱っているようなワクワク感を感じさせるUXになっています。 プロダクト開発においては、ワクワク感を持って勢いで作ってしまうことは地味に重要なんじゃないかと思っています。ワクワクさせる仕掛けを私も大切にしていきたいです。 また今回のLTには含まれていませんが、Zoltraakの価値観や使命感については、元木さんによるツイートがありました。 熱い想いが語られており、生成AI活用を盛り上げていくぞ！という勢いが滲み出ており、非常に共感します！ #自然言語プログラミングZoltraak の使命、将来像、価値観をまとめます ＊ 俗に言うミッション、ビジョン、バリューですが、Zoltraak開発の中心的存在である私たちは日本人なので「日本語」を特に大切にします ちなみにこれはグローバリズムとの対立を生む思想ではありません。後述します。 将来像:… pic.twitter.com/rgL9MEBhaB — 元木大介@生成AI塾&抽象プログラミング言語: ゾルトラーク、にわとこ (@ai_syacho) 2024年4月26日 吉崎亮介さん【仕事の対話をAIでハックする考え方とプロセス】 吉崎さん からはAIを介して成果物を出す人間をどう増やすかというお話を頂きました。 スライドはこちらをご覧ください。 speakerdeck.com ボリュームのあるスライドですので、かいつまんで説明いたします。 まず、「AIから目的とする出力を引き出すためには、十分な量の入力が必要である」という話が前提になっています(下記スライドP17までの議論です)。 短いプロンプトでふわっとした指示をした場合に、意図通りにAIが動いてくれない経験は皆様もお有りだと思います。 業務にAIを活用したい場合、業務固有のデータやノウハウをAIに与えることが重要です。 したがって、 業務経験データベースに業務固有のデータを入力する準備ができていること が重要で、これに 「高度な論理的思考力というフィルタ」としてのAI活用 をかけ合わせると、仕事で使えるAIとなります。 では、業務固有のデータ、業務経験を蓄積する際に、どういうことに気をつければよいのでしょうか。 業務経験をここでは、「本質的な情報(x)」から「表現(y)」への写像として捉えています。 AIとの協業では「本質」をいかにうまく扱うかが重要であるという話の流れになります。 下記スライドでは本質的な情報からアウトプットを生み出すためのプロセスにおいて、AIとの協働がうまく行っている状態の例を示しています。暗黙知としてのナレッジが表出化され、AIへの入力として組み込める状態だということですね。 「AIによるx→yへの変換を人間が修正した結果」を自動的にDBに集積し、それをAIに渡す入力をアップデートすることでAIの表現を洗練させていく、というアイディアがこの図のポイントだと思います。 弊社の話題に移すと、LIFULLでもkeelaiというSlack Botを社内用に運用しております。 生成AIによる20,000時間の業務効率化を支える取り組み - LIFULL Creators Blog keelaiでもRAG(Retrieval-Augmented Generation)を用い、既存のバックオフィスFAQの内容を情報の取得元の1つとしています。 いかにしてkeelaiを活用できる場面を増やすかという点を考えており、吉崎さんの発表の「業務経験の集積」という考え方が参考になりそうです。 興味深い発表をしていただきありがとうございました！ 森 正弥さん 【AIは人の仕事を奪うのか？ AI時代の新たな哲学】 森さん は博報堂のChief AI Officerの方で、AI倫理に関するお話をいただきました。 発表は主にこちらのnoteの内容でしたので、noteをご覧いただくのが良いかと思います。 note.com 主張としては『「リアル VS ネット」または「現実 VS 仮想」といった二項対立に陥らないようにする』というような内容で、両極のベストを組み合わせた第三の方法を見つけるような考え方を身につける必要があるということでした。 これはまさにその通りだと思っていて、AI時代になっていくと一人の人間の意思による力がAIによって増幅されていくので、それを争いに使うと被害が大きくなってしまいます。 AIによって生まれた実務能力によって様々なものが加速していくので、AIを使って何がしたいのかをよくよく議論しておかないと、AかBかのどちらかに寄ってバランスが悪くなっただけになりかねないと思います。 プロダクトマネジメントの文脈で、プロダクトビジョンの制定とその実現に向けた継続的な議論が重要だというような話があります。 弊社LIFULLでは プロダクトマネジメントの活用 を近年意識しており、 昔よりはプロダクトのあり方について議論する場は増えてきていると感じています。 様々な人たちと様々な議論を行うことで、より多様な視点を包含した方法につながるのではないかと思います。 懇親会 懇親会もとても盛り上がりました。 オンラインのzoomをプロジェクターで投影しながら、オフラインの会場と繋いで雑談するというハイブリッドで行われました。 話題としては様々なお話があったのですが1つだけ挙げると、さきほどの森さんにEUのAI法案について解説いただいたのが興味深かったです。 EU AI法案が加盟国に承認され成立 規制は2026年に適用の見通し | NHK | EU こちらは2026年から本格的に適用予定の規制なのですが、これはEUが基本的人権をどう考えているかのメッセージだというお話をされました。 規制とは単に守るべきものと捉えがちですが、規制があるからこそ、その領域に対して人々がリテラシー意識を持つようになるとも言えます。 AI法案の罰則の上限はGDPRの罰則の上限よりも高いので、EUはAIと人権の問題を重く見ており、 それは(GDPRすなわちデータの問題よりも)議論されるべきものだと考えていると言えるのかもしれません。 AI開発者はAIにバラ色の未来を投影しがちですが、インターネットにもフェイクニュースやフィルターバブルの問題はあるので、技術がもたらす様々な副作用に目を向けていかないといけないということですね。 （もちろん、バラ色の未来を実現させることもとても重要です） 「Machine Learning 15minutes!」には様々なバックグラウンドの方が集まり、とても熱気がある会でした。弊社も協賛という形でのご協力ができて嬉しいです。 最後に LIFULLでは生成AIを積極活用する方針があり、共に成長できる仲間を募集しています。 media.lifull.com ご興味のある方はこちらの採用ページからぜひご応募ください。 hrmos.co hrmos.co hrmos.co hrmos.co

こんにちは。クオリティアーキテクトグループでQAエンジニアをしている星野です。 元々はQAグループという名前で横断組織として社内のテストプロジェクト支援などを嗜んでいましたが、 組織が統合・再編成され、より自動テストやツール開発、プロセス改善などエンジニアリングに寄った仕組みづくりに取り組んでいます。   ３行まとめ 共通のフォーマットを開発したよ 抵抗感なく浸透させるように工夫したよ こっそり横断的なメトリクスも取ったら便利っぽかったよ ３行まとめ 背景 課題 対策 やったこと 当たり前品質編 : 満たさないと論外 魅力品質編: 乗り換える理由をつくる 横断部署が常にぶちあたる浸透の課題 ロガー 広報 効果と現状とこれから 終わりに 背景 課題 LIFULLではチームごとにやりやすい開発体制を選択しています。 奇抜な開発スタイルをとっているわけではありませんが、それぞれに特色があり独自に改善活動を行って進化しています。 改善の進めやすさなど柔軟性のメリットもありますが、一方で次のような課題が出てきます。 ナレッジの横展開がむずかしい フォーマットが異なるためツールやノウハウをそのまま再利用できないことがある 部署異動や新人の学習コストが高い 学び直しが必要になる 他部署の成果物を読み解く際にフォーマットの理解から必要になる 我々のような横断的なQA組織の立場としては次のような課題があります。 測定・調査が難しい チームごとにテスト成果物のフォーマット（ここではテスト仕様書・項目書）が異なるためメトリクスを活用しにくい, 状況を把握しにくい 非同期で変化するためそれぞれの形に合わせて自動化しても追跡が難しい 改善施策を広めにくい 上記の「ナレッジの横展開」と同様 １チームの閉じた単位で改善を行うためスピードが出ず再開発する必要もある 加えて最近では特に海外の開発拠点とこれまで以上に密な連携を行って開発するようになりました。 覚えることが多い状況の中、テスト部分で海外拠点メンバーが困らないように「とりあえずこれまで通り自分たちのフォーマットを使って進めましょう。どんな形がいいかはみんなで検討しよう。」の方針となるチームも多く、フォーマット迷子になっている状況でした。   対策 ここまでの流れでおわかりの通り、標準となるテスト仕様書のテンプレートを開発しました。 シンプルに言うとそれだけなのですが、会社のテックブログなのでそれらしいことを書きます。   やったこと もちろんですが、チームの外にいる人から「急だけど今日からこのテンプレートでテスト書いてね！じゃ！」と言われても圧倒的なパワー差による主従関係でもない限り通りません。   ではどんなテンプレートを用意すれば既存のやりかたと勝負できるか。 品質分野の人間なのでみんな大好きな狩野モデルを出して説明します。   （引用 : ナレッジ - 品質管理なら日本科学技術連盟 ）   狩野モデルについての詳細な説明は割愛します。 要は利用者の目線で見たときに、当たり前に揃っていて欲しいものがないと不満を感じるし、魅力に感じるような要素がないと満足度は上がらない、というざっくり説明で進行します。 このモデルをもとにどんなテンプレートが必要かを考えると、以下を満たす必要がありました。 当たり前品質（満たさないと論外） 現在使っているテンプレートでできることはできる テストケースの書き方を極力変える必要がない 一元的品質（あればあるほどいい） サポートの手厚さ 魅力品質（これだけでも使う理由あるやん） 開発チームの未解決課題にアプローチした機能 当たり前品質編 : 満たさないと論外 まずはじめに行ったのは既存フォーマットの調査です。 基本的にはチーム単位で独自にツールベンダーと契約することは予算的にも現実的ではないため、スプレッドシートを用いることが主です。 スプレッドシートは自由度が高いため独自進化しやすく、GASや式を用いた機能拡張が進んだチームも見られました。 機能の不足で乗り換えを躊躇するチームは限られているので充足は徐々に行っていくとして、まずは元となるテストケースの書き方（カラムなど）に焦点を当てます。   よく使われるカラムや書き方を調べ、代替や統合ができそうかを考え、プロトタイプを作ってはヒアリングを行い（海外拠点メンバーを含む）利用者の声を聞きにいってました。 特に奇抜なフォーマットが出来上がるわけもなく、よくある一般的な内容に落ち着いたため詳細は省略しますが、  PMなど進捗が気になる人に一目で状況がわかるようにテスト進捗メトリクスのグラフをつけたり、 複数端末で同時にテストする需要があるのでテスト結果を入力するカラムを複数個並べるといった小さな気配りを機能ごとに想定ユーザーとシチュエーションを設定していっぱいちりばめた記憶があります。 もちろんですが、想定は想定でしかないため、実際に見てもらってユースケースと食い違ったり噛み合わせが悪い部分はアップデートを重ねています。   その後は不足している機能の拡充で、既に進化しているチームのシートを参考にしながら機能を汎化させ取り込んでいきます。 具体的には、スマートフォンの実機でテストする際の効率をよくするためにQRコードを自動で生成したり、テスト環境を切り替える際にテストケース内のドメインを一括で切り替えたりといったあるある機能群なのでこちらも割愛します。 つまるところは「この機能がないと不便なんだよなぁ〜」をなくす運動です。「その機能、別になくていいのに必須入力なんだよなぁ〜」も生み出さないよう、利用者以外には影響を及ぼさないような設計を意識しました。   魅力品質編: 乗り換える理由をつくる いま現在利用されているテンプレートでは叶っていない機能、抱えている・またはこれから抱える問題の解決につながるような機能を考えます。 背景でも述べていますが、ここは明らかでした。海外開発拠点との連携が密になり、言語の壁が課題となっています。 DeepLのような翻訳サービスが進歩していても、都度都度テストケースの中身を翻訳にかけるのはとても手間です（ましてやスプレッドシートなのでセル単位）。 メンバーも元々英語が必要な環境だと言われて入社しているわけではないですし、自分もそうですが全員が全員、語学が堪能ではありませんし全員が急に上達するのも現実的ではありません。   そこで、指定したシートのテストケースをボタンひとつで翻訳してくれる機能を用意しました。ありがとうGoogleTranslate関数くん。 他にも共通テンプレートとなると複製の手間が発生することが目に見えているため、GASでAPIを用意し常に最新版のテンプレートを生成してくれる仕組みを用意したり、それをgithub actionsに組み込んでPR作成時にトレースも取れた状態でつくれるようにしたりと開発者体験の向上を進めました。 これで「今まで使ってたGoogleDriveから複製して使ってたこれまでのテンプレートより全然楽じゃん...」な状況が手に入ったわけです。   横断部署が常にぶちあたる浸透の課題 ヒアリングを重ねて使いやすい形を手に入れ、既存機能にも追いつき、他にない機能も搭載されました。 プロダクトを作った後に課題となるのは「浸透」です。使ってもらえなければこの新テンプレートは存在しているだけで何の価値も出せていません。   ロガー そこで、まずは利用状況を追跡し可視化する機能を実装しました。 利用時に必ず操作するボタンをトリガーに、利用しているチーム、github actionsから生成されていればPR番号などをログとして蓄積し、見える化を行いました。 これにより、一度使っていてもその後に利用が見られなければ、なにか問題・課題を見つけてくれていると考えられるのでヒアリングをする、といった動き方ができます。 また、よく使ってくれているチームや一度も使っていない（知らない or 乗り換えるメリットを得られない）チームなどが明らかになります。ターゲットが明確になることで次の打ち手の確度が上がります。 実際はクチコミで「なんかQAがつくったテンプレがいい感じらしい」と自然に広がってくれたようで、じわじわ増えていく様子が見られました。   リリースした新機能が活用されているのかどうかだったり、サポートの問い合わせがあったときにログの利用者情報からシートをすぐ特定できるため重宝しています。   広報 次に、定期的に丁寧なアナウンスです。 読み手にとって価値の薄い「つかってくださ〜い」の広報を何度行っても響きません。むしろノイズとなり煙たがられます。 そこで、魅力となる便利機能が搭載されたタイミングで、その機能の概要と使い方を1~2分の動画説明を添えて広報しました。   使い方もほぼ誤解なく伝わっているようで、利用数に対して機能の使い方に関する質問はほとんどありません（バグの報告や新機能の提案、感謝の声などがフォームやDMに届いてます）。 使われていなくて質問がないのか、使われている上で質問がないのか、これには大きな違いがありますが、前述の利用状況を見える化したことでその判別ができます（ちなみに独自の名前をつけたことでslackにてエゴサがとてもしやすい）。   効果と現状とこれから 定量的なアウトカムについては恐縮ながらまだ計測できていません。 取り組み自体、半期で計画・調査・実装・展開・浸透を行なっているためデータを蓄積している最中になります。 また、このテンプレートは裏でこれまたこっそりとメトリクスを収集できるようにしており、利用されたすべてのシートでテストケース総数や実施した環境数、テストタイプの数や実施期間などが取得できています。 これらのデータを既存テンプレート利用時の実態と比較できればよかったのですが、背景で述べたようにチームごとに実態が異なっており、また詳細なデータも取れるかわからないのが現状です。   整理しやすくなった、見やすくなった、翻訳機能が助かっている、などの定性的なフィードバックはもらえるようになったものの、定量的なアウトカムはやはり難しいため、 新たに取得しているメトリクスから、新機能リリース後の変化や改善施策実施後の効果計測、チームごとの健康状態可視化、ベストプラクティスの発見と横展開などの取り組みに繋げていく基盤として機能させていこうと構想しています。   終わりに ただただ共通テンプレートをつくった話を長々と述べました。 たかが共通テンプレートですが、利用するだけで恩恵を得られるような仕組みを用意したり、改善を誘導するような仕込み（本記事では割愛しました）ができたりと、工夫の余地は結構ありました。 たかが共通テンプレートですが、浸透させるのも頭を悩まされ、たくさんの方に協力していただきました。 たかが共通テンプレート。されど共通テンプレート。   以上です。 お読み頂きありがとうございました。

こんにちは、グループデータ本部データサイエンスグループの清田です。 昨年のDEIM 2023 に引き続き、「 第16回データ工学と情報マネジメントに関するフォーラム（通称DEIM 2024） 」に参加・登壇してきましたので、その様子を報告いたします。 ※昨年の様子はこちら www.lifull.blog 昨年に引き続いての「直列ハイブリッド」開催 コロナ禍の影響が徐々に薄れ、対面形式でのイベントが再開される中、DEIMでは昨年に引き続き「直列ハイブリッド」というユニークな形式で開催されました。 2月28日から3月1日までの3日間はオンライン開催、土日をはさんで3月4日・5日は兵庫県姫路市の会場での現地開催でした。 オンライン開催用に配布されたロゴ入りバーチャル背景。LIFULLも前回に引き続き協賛しております 現地会場のアクリエひめじ（兵庫県姫路市） ハイブリッド開催のイベントは今や一般的になりましたが、どうしてもオンライン参加者と現地参加者の間のコミュニケーションが難しくなってしまうという課題があります。 オンライン開催中には多くの発表を集中して聴講し、現地開催中には多くの参加者との交流をもつことができる開催形態は、参加者としても利点が多いと思います。 開催にご尽力いただいた関係者の方々に、心からの敬意を表したいと思います。 スポンサー企業各社の常設展示会場。今回も多くの方々と交流をもたせていただきました 大規模言語モデル(LLM)のインパクト 2022年11月にリリースされたChatGPT、およびその技術的基盤となる大規模言語モデル（LLM）は、AI、情報処理に関する研究にも大きな影響を与えています。 とくに自然言語処理分野でなされてきた研究課題のうちかなりの部分は、LLMによって解けるようになったこともあり、研究のテーマ設定自体が大きく変わりつつあります。 DEIM 2024でも、40件以上のLLMに関する研究発表が行われており、トレンドの大きな変化を実感しました。 また、3月4日に開催された チュートリアルセッション でも、LLMに関する以下のチュートリアルが企画され、いずれも多くの参加者を集めていました。 クラウド環境で駆動する生成系AIの最先端 LLMと音声理解・生成の最新動向 大規模言語モデルに基づく検索モデル LLMの嘘：ハルシネーション解説 共有データ資源のこれから LLMなどの生成AI技術が飛躍的に発展する中、生成AIが必要とするデータ資源の存在が、あらためて注目されています。 LIFULLでも、 国立情報学研究所（NII） のご協力のもと、 LIFULL HOME’Sデータセット を2015年11月より学術研究用途に提供しています。 現時点で 170件を超える研究成果 が発表されていて、 LIFULL HOME’S 3D間取り などの新たなサービスの実現にもつながっています。 www.lifull.blog AIや情報処理に関する研究は、多くの研究者がアクセスできる共有データ資源の存在に支えられて発展してきました。 Webに蓄積された大量のデータ資源が、自然言語処理や画像処理などの研究の発展を促すとともに、Webを活用したビジネスの発展の基盤となり、さらにWeb上のデータ蓄積を加速するという「好循環」が、AIなどの発展を支えてきました。 一方で、生成AI技術の隆盛は、「データを独占的に保有すること自体が巨大な利益につながる」という状況も生み出しています。 こうした状況で、「好循環」が滞ってしまうのではという懸念も出てきています。 2023年には、Twitter社（現X社）が、これまで学術研究者向けに認めてきたAPIの利用を停止するという出来事もありました。 techcrunch.com こうした流れの中、今後のAI研究を支えるためのデータ資源のあり方を、改めて振り返ることが必要ではないかと考えています。 DEIM 2024では、LIFULLからの技術報告として、「不動産情報サービスの研究開発における研究データ資源」についてのプレゼンテーションを行いました。 この発表では、LIFULLにおけるデータセットの共有と活用の取り組みを紹介するとともに、Webが出現するより前の1990年代からの共有データ資源をとりまく環境の変化を俯瞰した上で、今後の共有データ資源の健全な発展を図るための方策についての考察を行いました。 もしよろしければ、ぜひ発表資料をご覧ください。 speakerdeck.com LIFULLでは、 Webインテリジェンスとインタラクション（WI2）研究会 や、2024年5月に浜松で開催される 人工知能学会全国大会（JSAI 2024） など、複数の学会イベントをこれからもサポートしてまいります。 また、LIFULLでは、共に成長しながら働く仲間を募っております。 現在、以下の職種を募集しております。LIFULL HOME’Sデータセットなど、豊富な研究開発資源を活かしながら、多様な社会課題の解決に向けた研究開発やプロダクト創出に取り組んでみませんか？ hrmos.co hrmos.co ご興味をお持ちの方は、ぜひお問い合わせください！

こんにちは。フロントエンドエンジニアの根本です。 LIFULL HOME'Sのプロダクト開発と、スポーツ関連の新規事業開発に携わっています。 2024年5月18日に開催された「RESEARCH Conference」というリサーチをテーマにしたイベントに登壇いたしました。この記事ではそのイベントや登壇内容についてご紹介します。 RESEARCH Conferenceとは？ researchconf.jp RESEARCH Conferenceは、リサーチをテーマとした日本発のカンファレンスです。 より良いサービスづくりの土壌を育むために、デザインリサーチやUXリサーチの実践知を共有し、リサーチの価値や可能性を広く伝えることを目的としています。 行政、大企業、スタートアップなど立場の違いを超えて活発な議論を重ね、共に学び合うリサーチコミュニティを育てることを目指します。（上記ページより引用） 上記のように、このイベントでは「リサーチ」というテーマに対して組織形成やプロジェクトでの取り組み事例など様々な切り口のセッションが開かれ議論できる場になっています。 LIFULLでは毎年スポンサーとして協賛しており、今回はリサーチを活用した開発プロセスについてエンジニアという立場からお話をする機会をいただきました。 発表内容 今回のカンファレンステーマは「ROOTS」。私たちは「プロダクトに命を吹き込む：UXリサーチとエンジニアリングの共創」と題し、UXリサーチャーと共に登壇しました。特に、本記事では開発プロセスに焦点をあてた内容を紹介します。 チーム構成 今回のプロジェクト事例では、プロダクトオーナー、UXリサーチャー、UXエンジニア、デザイナーの4名で先行リサーチを行い、施策検討段階で開発チームと合流し開発プロセスを進めています。本チームでの開発プロセスについて下記で紹介します。 職種分業体制 私たちのチームで中小規模の開発に取り入れている職種分業体制では、主に企画とデザイナーがバディとなり、リサーチ結果を仕様に落とし込んだ仕様書という形でエンジニアにバトンタッチする進め方を採用しています。 その結果、開発規模が大きくなった時、顧客理解や仕様理解不足が発生し開発停滞や後戻りが発生することも少なくありません。 職種連携体制 新規開発など大きめのPJを進めていく場合、職種分業体制ではなく職種連携体制を採用し開発を進めています。 この体制ではリサーチに携わっている、企画・デザイナー・UXエンジニアの３職種が連携し仕様の落とし込みを実施しています。 UXエンジニアが仕様策定に関わることで、後続の開発フェーズではエンジニアと仕様意図をしっかりと共有しながら技術的な設計のすり合わせが可能になります。 UXエンジニアの介在価値 UXエンジニアが担う仕様作成では、 職種横断チームでのUXエンジニアとしての働き方 - LIFULL Creators Blog でも過去に紹介しているようにテクニカルプロトタイプを用いて仕様のすり合わせを実施します。 その結果、リサーチ内容をプロダクトに昇華していく工程がよりシームレスになり好循環な開発プロセスを実現できるようになっています。 このようにプロジェクト規模や組織体制に合わせて柔軟な開発プロセスを踏み、その中でエンジニアも当事者意識を持ってリサーチに関与していくことが重要であると考えます。 発表資料はこちらからご覧ください。 www.docswell.com イベントに参加した感想 今回登壇するにあたり、自分にとってのリサーチの「ROOTS」とは何かを思い返しました。 元々、大学の研究では認知心理学、認知科学分野を専攻し人の認知的な特性を理解した上で、情報システムはどうあるべきかという点を考えていました。 それらを知るためのリサーチであり、エンジニアとしてプロダクト開発をしている今もその「ROOTS」を持ってリサーチに関わっているのだと振り返ることができました。 今回登壇されていた様々な企業・団体の方のリサーチへの取り組みは興味深いものばかりで、とても勉強になり刺激にもなりました。 また、AI活用などによりリサーチ作業自体の効率化をエンジニアとしてサポートできるという発見もあり今後は様々な形でリサーチを推進していこうと思う機会になりました。 最後に LIFULLではリサーチを活用しながらプロダクト開発を一緒に推進してくれる仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

プロダクトエンジニアリング部の興津です。私は普段アプリケーションエンジニアとしてLIFULL HOME'Sのサイト改善業務しています。そのかたわらで、社内の制度を利用して、LIFULLのサービスの一つであるACTION FOR ALLの企画もしています。 今回はそんなLIFULLの独自の制度である「キャリフル」と、その経験を通して私が得られたものについて紹介します。 LIFULLの独自制度「キャリフル」について まず初めに、エンジニアの自分が企画に挑戦することを可能にした、LIFULLの独自制度である「キャリフル」を紹介します。 キャリフルとは、LIFULLの社内兼業制度で、業務時間の1割程度を本業とは別の業務ができる制度です。 私のように、普段とは別の職種に挑戦することもできるほか、たとえば同じエンジニアでもLIFULLの別のサービスの開発に携わることも可能です。 キャリフルについては公式Noteでも紹介しているため、もっと詳しく知りたい方はこちらをご参照ください。 corp.LIFULL.com 私がキャリフルに応募した理由 私がACTION FOR ALLの企画職に応募した理由は2つあります。スキルアップとビジョンマッチです。 企画職を体験することでスキルアップをしたい 自分のキャリアビジョンを考えた時、これからはエンジニアの業務だけではなく、一緒にサイト改善を担う企画やデザイナーの業務にも気を配れる存在になりたいと考えました。 特に前職が顧客の社内Webサービスの構築PJに参画することが多かったこともあり、企画職が何をする仕事で、何をエンジニアに期待していることがまったくわからない状態でした。 企画のことを知るためには、実際に企画を経験してみるのが一番よいと考え、企画のキャリフル募集を探し始めました。 ACTION FOR ALLのビジョンに共感し、事業に貢献したい 運が良かったことに、探し始めた時とほぼ同じタイミングで、企画の未経験でも応募可能な募集が始まりました。それがACTION FOR ALLの企画です。 ACTION FOR ALLは国籍や人種、性別、背負うハンディキャップにかかわらず、誰もが自分らしく「したい暮らし」に出会える世界の実現を目指す事業です。 さまざまなバックグラウンドを持つ人が安心して相談できる不動産会社を探すことができるFRIENDLY DOORなどのサービスがあります。 actionforall.homes.co.jp 私がLIFULLに入社を決めたのも、ACTION FOR ALLをはじめとした、社会課題の解決に事業として本気で取り組んでいるところに共感したからでした。 特に、私は長年プライベートでも社会的弱者とされる方々の支援活動を行っていたこともあり、LIFULLの数ある事業の中でもACTION FOR ALLは最も好きな事業です。 いつかACTION FOR ALLに貢献できる仕事ができればと思っていた中で、キャリフルの募集はまたとないチャンスでした。 こうして、企画のキャリフルに応募したいと思った時と同じくして、携わってみたいと考えていた事業の企画が募集をしていたため、応募しました。 挑戦して知った、企画職のたいへんさ 施策案を作ることの難しさ LIFULLにおけるサイト改善の企画職の仕事のメインは、現状のサイトの課題を見つけ、その解決策を立案することです。 言葉にすると簡単ですが、やってみると想像以上に難しいことを痛感しました。 まず、先輩方がアップデートを続けてきたサイトに対して、課題を見つけ出すことすら私にはできませんでした。見慣れて愛着が出てしまっていることもあり、「もう今のサイトが完璧なのでは」と言う気持ちになってしまいました。 先輩方の助けも借りながらなんとか課題を見つけることができても、今度はその解決策を見つけることができませんでした。たとえば、FRIENDLY DOORの会社情報が長すぎるのでは、という課題が出た時に、皆で情報を整理してスッキリできないか案を出し合おうということになりました。しかし、私は考えても「全部の情報が必要！」という思考になってしまい、よい案を思い付くことができませんでした。その時に先輩方からは「ほかの同じようなサイトもよく見て、参考にできるようなものがないと見てみるとよい」というアドバイスをいただきました。企画の人たちは自分たちのサービスだけでなく、競合他社をはじめとした世の中のさまざまなサービスを見ているんだと気付かされた一件です。 さらに、施策を立ち上げた後に行う仕様作成でも、簡単な施策であっても実際にドキュメントに起こしてみると、「こんな細かいところまで考えなければいけないのか」という気付きの連続でした。たとえば、私はFRIENDLY DOORの駅・路線での絞り込み機能を追加する施策の仕様作成を担当しました。この施策も、「複数の路線が通る駅で絞り込まれた時のURL」や「複数の駅が選択された時のH1の文章」など、検討しなければいけないことがたくさんありました。一つ一つの検討事項の結果がサービスの質や売り上げにつながっていくと思うと、いわゆる「決めの問題」となる些細な決定でも責任を感じました。 開発を託すことの不安 無事に仕様が完成し、エンジニアに託した後も、企画はけっして気が抜ける状態ではないということを知ることができました。 エンジニアとして自分が開発者として参画しているときは、現在どんな進捗で、どんな課題があって、計画通りにリリースができそうか否かが簡単にわかりました。それに、何かトラブルが発生したとしても「いざとなれば自分が必死になって頑張る」という最終手段があるという安心感もあります。 企画の場合は、開発中は大きなトラブルなく進むことを祈るしかできません。トラブルを防ぐための打ち手として、事前に仕様を十分に検証するということは可能ですが、開発が始まった後にできることはあまり多くなく、非常にもどかしい気持ちになりました。進捗が遅れた時のリリース日延期の判断や、リソース調整など、企画としてできることにおいても、その判断を早くするためには進捗の把握を積極的に行わなければならないということに気付きました。 最も、私の本業はエンジニアであるため、最終的には自分も開発に入ってなんとかするという判断ができますし、実際にそうした施策もありました。しかし、本業がエンジニアでない企画はそうもいかないので、さらに不安が大きいであろうことは想像にかたくありません。 施策が実を結ばなかったことの悔しさ 企画の先輩方にアドバイスをもらいながら仕様を作り、エンジニアに多くの工数を使って改修してもらった施策が、必ずしもうまくいくとは限りません。 中にはリリース後にビジネス指標が悪くなってしまい、緊急で改修前の状態に戻す判断が必要となった施策もありました。 たくさんの人の協力を得ながら行った改修の結果が悪かったことは、本当に悔しく、皆に対して申し訳ない気持ちになりました。 企画の人たちはこんなプレッシャーとともに施策を打ち出しているのかと思うと、頭が下がる思いです。 エンジニアの自分だからこそできること 企画のたいへんさがよくわかった一方で、エンジニアだからこそ企画業務で活かせることもいくつかありました。 技術観点から策定する仕様 仕様を決めるときに、自分がエンジニアであるため、既存のソースコードやDB構成などを自分で確認できます。 そのため、仕様を決める時に実装のしやすさや性能などを考慮した仕様を考えることができました。 もちろん、そこをエンジニアに相談して一緒に仕様を決めていくことも可能であり、普段の業務でもこうして進めていくことも多いです。 それでもエンジニアのリソースを別のところに使えることは効率的でした。 SQLを用いた分析 先日、FRIENDLY DOORでは住宅弱者フレンドリーな物件一覧のページをリリースしました。 LIFULL.com この一覧ページを作った後に、この一覧に掲載される物件の傾向を分析することになりました。「一覧に掲載される物件はどんな増減をしているのか？」「都道府県ごとに差異はあるのか？」「フレンドリーな物件を多く扱う不動産会社はとは？」ということを知れば、次の打ち手の材料にできると考えたためです。 上記の疑問点は、SQLで件数を調べることで知ることが可能です。 こちらもエンジニアに依頼して調べることも可能ですが、ちょっと気になった件数も自分で簡単に調べられるのはエンジニアならではの強みだと思います。 普段の業務での知見を活かした改善 ACTION FOR ALLではLIFULL HOME'Sとは異なる独自のドメインやリポジトリを有していますが、LIFULLでは技術的に管轄している部署が存在していない状態でした。 開発は施策ごとにベトナムの開発拠点であるLIFULL Tech Vietnam Co.,Ltd.(以下LFTV)に依頼しているため、サービスのリリース当初から保守運用があまり積極的に行われていない現状がありました。 そこで、普段の業務で行っていることを活かし、ライブラリのアップデートの推進やテスト用の環境の整備などのエンジニアとしてできることも積極的に行っています。 キャリフルの経験を、普段の業務に活かしていく 普段の業務の経験をキャリフルで活かすことも可能ですが、逆にキャリフルで得た経験が普段の業務に活きていることも感じています。 企画に寄り添えるエンジニアに 当初の目論み通り、企画が行う業務や企画ならではの困難さを体験したことで、企画に寄り添えるエンジニアとして成長できていると感じています。 たとえば、日々の進捗確認では一見エンジニアどうしで把握しておけばよいかもしれないことも、可能な限りエンジニア以外にもわかりやすい言葉を使って説明するようにしています。開発の進捗が端的にしかわからないことは不安であることを知ったからです。 また、施策の結果が数字としてはうまくいかなかった時こそよかったところを見つけて前向きな言葉を発することを心がけるようになりました。結果が振るわなかった時の企画の悔しさや決断の重圧を身をもって知っているからです。 次の段階としては、より確度の高い施策を作れるように、エンジニアの立場からバックアップできることを考えていきたいと思っています。 エンジニア組織のいないサービスに参画したことで、技術的に強くなった ACTION FOR ALLには専属のエンジニアが存在しないため、障害対応が発生した時は自分しか調査をできる人間がいませんでした。（2024年1月現在は、開発を依頼しているLFTVのメンバーも障害調査ができる権限を付与し、一緒に調査ができるよう整備しています） 普段は同じチームの先輩方に頼れる技術的な判断も、自分に委ねられることになります。 この状況に身を置くことで、技術的にも成長できました。もちろんこの成長は、普段のエンジニア業務の中でも糧になっています。 終わりに このように、LIFULLでは自分の所属以外の業務や職種にも積極的にチャレンジできる環境が整っています。 さまざまなことに挑戦して成長したいと考えているエンジニアの方は、ぜひ以下のページも見ていただけますと幸いです。 hrmos.co hrmos.co

プロダクトエンジニアリング部の二宮です。 次のプレスリリースにある通り、LIFULLでは生成AIを使って20,000時間以上の業務時間削減をしたという大きな成果を上げることができました。数字の根拠が粗い試算ではあるものの、実は社内では1年間で20,000時間の削減を目標としていたため、その半分の期間で目標達成できて関係者が色めき立っています。 lifull.com 私は keelaiという社内用AIのプロジェクト に開発者の一人として関わっていて、生成AIツールの活用を推進する有志のプロジェクト（タスクフォースチーム）にもメンバーの一人として携わっています。そのため、エンジニアの中でもある程度全体が分かる立場として、生成AI技術の社内普及のための取り組みについて共有します。 私は各部署の導入の相談やプロンプトの技術サポートを担当することが多く、社内発表も行っているため、結果的に生成AI関連のチームの中でもいろいろな人から声をかけられたりして情報が集まる立場になりました。その技術と普及活動の両面で話をします。 LIFULLの生成AI活用の現状 現在、keelaiは月間でおよそ580人に利用してもらっています。去年の11月に『 社内向けAI botの運用で学んだ技術コミュニケーションのコツ 』という記事を書いた時点では次のような状態だったので、そこからも大きく伸びました。 keelaiはSlack上で動くAIチャットボットを含んだ "汎用AI(仮)" 技術スタックで、LIFULLグループのSlackユーザーおよそ1000人程度の中で月間200人以上に利用して頂いています。これはけっこうな成功例と言っていいんじゃないでしょうか？ 社内での利用実態を見ても、keelaiはすでに社内で当たり前に使われているツールになったと思います。 内製AI（keelai）の開発・活用方針 ほとんどの内容は、KEELチームの相原さんが以下の記事で紹介している通りです。「なるべく作らない」方針で、Slackで利用できるチャットボットを主軸に社内の汎用的に使える機能を提供するようにして、個々の部署の問題は各部署でプロンプトエンジニアリングやSlackワークフローの設定ができるようイネーブリングしていく作戦で少人数での開発を実現しています。実は私自身もKEELチームに所属しているわけではなく、インナーソースのコミッターとして活動しています。 www.lifull.blog 汎用AIを目指す上でもあらゆる業務上の課題を解決する機能を私達だけで実装することは現実的ではないため、「なるべく作らない」ことでコストとバランスが取れたスケーラビリティだけを素早く示してインナーソースによって成長していくことを目指しました。 この記事の時点からさらに発展した点として、 Slackワークフロー と組み合わせて、ノーコードで生成AIを使った自動化機能を実現できるようになったことが挙げられます。例えば、『 海外の開発拠点メンバーと、受託先ではなくチームメンバーとして協働するための取り組み 』では、海外チームとのやり取りを生成AIで翻訳する使い方が紹介されています。 他にも、Slackワークフローのフォーム投稿を利用して、例えば総務では社内のFAQのRAG（社内情報検索）を使って一次回答をする機能を用意しました。私も便利に利用しています🙇 少し技術的な余談ですが、keelaiの投稿完了後に :keel_complete: という絵文字を付与していて、更に続けて別のSlackワークフローを起動できるように工夫しています。例えばプログラムでkeelaiに多数の問い合わせを投げ、その結果をGoogle Sheetsに収集するなどの使い方もできます。これを利用して、先日 クリエイターの日委員 によってSlackワークフローとkeelaiを使った自動化のハッカソンが実施されました。 生成AIを活用した会社の成功事例として、よく内製生成AIツールのログを徹底的に残して良い事例や注力ポイントを見つけている話を聞きますが、keelaiではプロンプトのログをあえて残していません。その代わりに公開チャンネルでの利用内容を定期的に見ているのと、Slackメッセージ内に誤回答の報告ボタンを用意することで代替しています。これはプライベートチャンネルやダイレクトチャットで、部門外秘の内容まで気兼ねなく利用してもらえるようにするためです。 普及のためにやったこと せっかく便利な機能を用意しても、それに気づいて使ってもらえなければ意味がありません。生成AIの力を普及させるために、各社でいろいろ苦心されていると思います。我々もその点は同様で、あの手この手を考えていろいろなメディアを通してコミュニケーションしています。 社内ゼミ Generative AI Award (GAIA) 相談窓口の準備 ドキュメントの拡充 Slackの広報 各部門の推進リーダーがいること これらの発表の後に「さっき紹介した事例に似たことを自分の部署でもやってみたいんだけど…」と声がかかることが多く、大きな活用促進のきっかけになることも多いです。 また、keelai自体がそうなのですが、これらは戦略的に考えられたものだけでなく、社員の自主的な動きが事後的に公式化したものも多いです。そういうボトムアップな動きがちゃんと合流できてるのもすごい点かもしれません。 社内ゼミ こちらの『 LIFULLの挑戦の機会と制度 』という記事にある通り、LIFULLには社内大学の制度があります。この制度を使って生成AIのプロンプトエンジニアリングのゼミを行いました。 社員が学びたい事をその分野に特化した社員が講師となって教えあう、大学のゼミのような勉強会が実施されています。 このゼミは実は公式の取り組みではなくて、 プロダクトプランニング部の部長の大久保慎さん が自主的に行ったものです。つまり正確にはLIFULLの生成AIチームの公式の取り組みではありません（もちろん内容のチェックや広報などで協力しました）。 このゼミの内容は、「初心者がプロンプトの基礎を学んですぐに中級者になることを目指す」ようなものでした。これは200人を越える社内ゼミ過去最高の参加人数を記録し、事後の内容の評判も良いものでした。実際にこのゼミをきっかけに利用者は大きく伸び、大きな自動化案件のきっかけにもなりました。 Generative AI Award (GAIA) 『 20,000時間以上の業務時間を創出 』にも記載している通り、LIFULLではGenerative AI Award (GAIA)という表彰を行っています。ただし、今のところはインセンティブ提供というより成功事例の普及が主目標で、特に賞品などを用意しているわけではありません。 また、上記診断によって活用度が高い従業員を表彰する「Generative AI Award(通称GAIA)」を月一回実施することで、優良事例の水平展開と共にモチベーション向上にも繋げています。 LIFULLにはThink Togetherという、役員と直接質問や議論できる場があります。そこで会長の井上さんにkeelaiや生成AIの話をしていて「本当はもっと盛り上がる方法があるんじゃないか」と言ったところ、「じゃあ全社総会で時間空けとくから何か発表してみてよ、 長沢翼（CTO） と一緒に！」と言われて突如始まりました。当時私はkeelaiの開発に関わっていたものの、生成AIを推進するタスクフォースに所属しているわけではなかった（後に合流した）ので、事情を知らない人からすると急に始まった謎コンテンツだったと思います😂 そこでアクセシビリティのチーム（『 フロントエンドエンジニアが組織横断のアクセシビリティ専門部署を立ち上げた 』）が既にエンジニア組織内でアクセシビリティに対して勝手に表彰する取り組みを行っていたので、長沢さんのアイデアでそれを生成AIの文脈で真似しました。具体的には生成AIを大きく活用できた事例を見つけ、代表者にインタビューした内容とともに発表しています。 内容は次のようなことを心がけています。 聞いてて面白い内容にする：特にオンラインでの発表になることが多いので、客観的な評価基準を設けるというよりは、本当に自分たち自身が面白いと思う事例を取り上げて、やや大げさなレベルで「ここがすごい」と言って分かりやすくすることを意識しています。 平均値ではなく例外に注目する：例えば「平均的に活用度が高いエンジニアチーム」ではなく「同じ職種の中でも例外的に活用度が高い営業チーム」にインタビューしました。そして普及のために何をしたのか、周囲のメンバーの反応で助かったことはあるのか等を聞いていきました。 「自分だったらこうするだろう」という意識を持って話を聞いて意外な点を見つける：例えば普及率の高い営業チームの人に話を聞く際に、「自分でもSlackや総会発表で積極的にアナウンスすることは思いつくし、他のチームでもそれはやっている。じゃあむしろ共有内容や周りの雰囲気に違いがあるんじゃないか」などと仮説を立ててインタビューしました。その結果、「とにかく新しいものを気軽でおもしろ用途から試して身近に思ってもらう。周囲にもそういう面白さを受け入れる雰囲気がある」ということが分かりました。 これらの指針は、LIFULLで社内導入された 中尾さんのKPIマネジメント の考え方のツールの1つである TTPS（徹底的にパクって進化させる） や、UXリサーチの方々が勧めていた メタファシリテーション の考え方にも影響されている気がします。 こういう普及活用はどうしても「必要なのは分かるけど別に興味は湧かない。ひとまず最低限言われたことをするか」というような減点思考の捉えられ方をされてしまいがちです。そこで加点思考のコンテンツを用意するのは良い雰囲気を作るのに役立つことだったと思います。 相談窓口の準備 サポートとして、Slackに相談窓口を用意しています。各部署でオーナーシップを持ってもらって、複雑なプロンプトの改善やアイデアを相談できるようにしています。最近ではSlackの ハドルミーティング を使ったオフィスアワー方式の相談会も試しています。 ドキュメントの拡充 使い方を説明するドキュメントはしっかり準備しています。特にkeelai Showcaseというプロンプトや利用例を紹介するページがあります。 「誰でも」と言ってはいるものの、それほど関係者外からの投稿は多くなく、ほとんどkeelaiチームの関係者が投稿しています😅 誰かに書いてもらうというよりはむしろ、ここの事例の中から近いものを紹介して別のチームにアドバイスすることや、この内容を見て「似たことができるかも」と声をかけてもらうことに役立っています。他にもSlackワークフローの設定手順や利用方法を動画で説明したり、色々とやり方を試行錯誤しています。 最近は生成AIのタスクフォースチームとして、GAI WIKIという「LIFULL社員が生成AIで知りたいことが大体分かるリンク集」のようなページを用意しました。 Slackの広報 『 社内向けAI botの運用で学んだ技術コミュニケーションのコツ 』にも書いた内容です。「次の行動を喚起する」ことを意識し、大抵はサポートチャンネルへの誘導を目的にしています。 自分自身が受け手になったときのことを思い出しても、この手の広報はほとんど素通りされて、後で「え？こんな便利なツールが用意されてたの？教えてよ！」って思うことが多いはずです。それを防ぐためには、「興味の扉が開く」ようなタイミングを狙って投稿すると良いんじゃないかと感じています。つまり、新しい機能リリースや面白い事例がある度に共有する、オンラインの総会で関連する話題が挙がったときに参考になるドキュメントをコメントするなど、皆の興味が高まるタイミングにすかさずアピールすることを心がけています。 各部門の推進リーダーがいること プレスリリース にもある通り、各部門に推進リーダーを立ててもらっています。 その他にも職種や業務特性に則して各論での利用促進を図るために、部門毎の生成AI活用推進リーダーを31名擁立し、網羅的な利用促進に繋げることができています。 これは実際に生成AIツールを推進する意味でも役立っていて、例えば「GAIAで表彰するときにその人に詳しく話を聞く」とか「活用度診断があるときにその人を通じて広報する」などで連携していて、他の取り組みを支えるベース担っていると思います。また、何か部署内で困りごとがあるときに、その方から連絡が来ることが多いです。 ただ、普段の推進リーダーの活動を、各々の自主性だけにまかせきりになってしまっている部分が多い点は課題だと思っています。もし自分が任命されたとしたら、ひとまずSlackや総会で情報共有はするものの、それ以上のことをどうすればいいか困ってしまうはずです。ただその分、先ほどGAIAの項目でも触れた、営業チームに聞いたおもしろ画像や音楽での盛り上げ方は想定外でビックリしました😂 今後の展望 最後に今後の展望をまとめます。おおまかには、生成AI推進のタスクフォースチームとして引き続き利用開始できていない人やチームに更に普及させていくことような動きをしつつ、特にkeelaiのチームとしては、成功したチームの施策を更に進展させる次のような取り組みを行うつもりです。 keelai APIの提供 keelaiのAPIを準備して、開発組織の中でより便利な効率化を行おうとしています。 まずGitHub Actionsを使って「社内ドキュメントや仕様書をうまく検索してアドバイスする」ような自動レビューを提供しました。LIFULLでは『 コマンド1発でKubernetes上にProduction Readyな環境を手に入れる 』で紹介されているkeelctlというツールが広く使われているので、主要なリポジトリにすぐ導入できます。 他にもプロダクトのエラーログを参照し、エラー発生時に簡単な問題であればそのままプルリクエストを作るなどいろいろな構想があります。これはシステム基盤も含めて内製していることのメリットだと思います。 過去に関わったチームのフォローアップ keelaiの社内での普及率は順調に上がってきたため、ここから大幅に利用者数が増えることは無いと考えています。そこでむしろ、過去に相談したことのあるチームに、プロンプトはきちんと動作しているか、他に困っていることが無いかなどを聞いてより深化させるチャンスが無いか探ろうと思っています。 また、別のSlackワークスペースの子会社からもSlackコネクトされたチャンネルで利用できるようにしているのですが、利用実態がよく分からないまま放置してしまっているので、そこにも取り組む必要を感じています。 社内コミュニティを盛り上げる （これはやや個人的な目標ですが）LIFULLには 社内サークル制度 があり、生成AIについて広く情報共有するサークルが設立されました。もちろん私もメンバーとして参加しています。 今のところ、ランチしながら生成AIのツールや使い方を話すことが活動内容のほとんどですが、更に何かもう少し広く役に立つ勉強会などの企画をしたいと思います。また、サークルには推進リーダーの方も何名か参加しているので、各部署の面白い普及の進め方を吸い上げて展開することもできるかもしれません。ボトムアップの方向からの動きも更に盛り上げるつもりです。 GAIPの知見を広げる またLIFULLには ジェネレーティブAIプロダクト開発ユニット（通称GAIP） という生成AIを使ったプロダクト開発の専門組織（『 さっそく試してみた！国土交通省不動産情報ライブラリAPI x 生成AI！ 』）があります。そこが生成AIのプロダクト開発の多くの知見が溜まっているようで、私の所属するプロダクトエンジニアリング部の注力ポイントとしても生成AIが挙げられているものの、それをつなぐ取り組みはこれからです。 最後に LIFULLでは一緒に自分たちの仕事を良くしていくエンジニアを求めています。これらの取り組みに興味を持っていただけたなら、ぜひ求人情報やカジュアル面談のページもご覧ください🙇 hrmos.co hrmos.co

グループデータ本部データサイエンスグループの嶋村です。 グループデータ本部は、 LIFULLグループで生まれる新たなデータを安全かつ効果的に活用 できるようにし、 事業の変化と持続的な成長を促進 することを目指している組織です。その中で、データサイエンスグループは研究開発組織として、 「活用価値のあるデータを創出」 し、 「データを活用した新たな機能やサービス」の研究開発 に取り組んでいます。 事業を革進し続けて様々な社会課題を解決していくために、 データを最大限に活用できる状態にしていきたい と考えています。その一環として、分析に関わる社員全員に対して、真のドメイン知識獲得、またデータ分析リテラシー向上の機会としてLIFULLファクトブックの作成に取り組んでいます。 LIFULLファクトブックとは LIFULLファクトブックは事業部のアナリストと連携をしてトライアルとして昨年から作成を始めていたのですが、形として完成してきたことから、先日、社内でLIFULLファクトブックの紹介をしました。 トライアルの中で試行錯誤を続け洗練 してきたこともあり、 広く興味を持ってもらえる結果 となりました。その際の資料をお見せできる範囲で用いながら、LIFULLファクトブックとは何か、ご紹介したいと思います。 LIFULLファクトブックに関する取り組みには 2つのねらい があります。1つ目は 「真のドメイン知識の獲得をすること」 で、良質な仮説を作れる状態やドメイン知識が共通化される状態にし、事業革進の効率を高めるということです。2つ目は 「分析リテラシの向上をすること」 で、正しい分析や説明を意思決定層へ届けることで、迅速で正しい意思決定ができる状態にすることです。 たとえば、分析をする際に「代表値」として「平均値」が使われることが多いですが、統計的な知識を持たず、「とりあえず平均値で」という状態だと誤った解釈になり、正しい意思決定にもつながりません。分布の特性次第で平均値が良いのか、中央値や最頻値といった他の代表値が良いのか、変わってくることがあります。また、二峰性など複数の分布が混在している場合では、分布を確認したうえで成分を分ける必要もあります。 LIFULLファクトブックを活用し、 実際のデータがどのような分布になっているのかを確認 するだけでなく、読み会と呼んでいる集まりを通じて 継続的にディスカッション をしています。特定の仮説や目的を持った分析（アドホック分析や深堀り分析と呼んでいます）とは異なり、様々な軸での分布を見ることでファクトを確認します。その際に、 今までの経験から想像していたデータと実際に確認したデータが異なるという気づきを得られることが多く、正しくファクトを定着させることが重要 であると再確認できました。 下図はLIFULLファクトブックのコンテンツ例です。 左側に分布を理解するためのグラフ があり、 右側に要約や説明が記述 されています。左側のグラフでは、需要と供給を表すデータの分布をそれぞれ載せており、 分布の山の違い が一目でわかるように可視化しています。また、 累積分布 を載せることで、分布のビン幅（横幅）に囚われず、 分布の形状を正しく理解 できるようにしています。右側では、各種統計量を載せ、 グラフおよび統計量から読み取れるファクトや考察 が記載できるようにしています。また、どのように作られたデータやグラフなのか、参加者が後からでもわかるように、算出方法の定義や関係資料へのリンクを載せられるようにしています。 LIFULLファクトブックの作成や読み会を通じて、様々な意見をいただきました。 当初は活動の意義がなかなか伝えられず賛同を得られない場面 もありましたが、 現在では読み会の参加者も大幅に増え大盛況 になっており、社内兼業制度「 キャリフル 」を活用して読み会での発表をする社員も増えてきました。最初はグラフやデータの読み方がわからない、という声がありましたが、一つ一つレクチャをすることで 「統計の基本知識がわかるようになった」 や 「ドメイン知識を得る良いきっかけになった」 といった声も多く集まりました。 おわりに 今回は真のドメイン知識を獲得しデータ分析リテラシを向上させる取り組みである「LIFULLファクトブック」の紹介をしました。 お知らせとなりますが、データサイエンス系の自社イベント 「 LIFULL AI Hub 100ミニッツ 」 を計画しており、次回は「LIFULLファクトブック」の取り組みについて紹介をする予定です。少しでも興味を持ってくださった方は、是非、気軽にご参加いただけると嬉しいです。 最後になりますが、データサイエンスグループでは「活用価値のあるデータを創出」し「データを活用した新たな機能やサービス」の研究開発活用を加速して下さる シニアデータサイエンティストを2枠募集 しています。 【研究開発職】データサイエンスで高難易度な技術課題に取り組む研究開発に興味ある方 【実事業への活用促進職】研究開発成果や新たなAI技術を活用し、実プロダクト・システム開発推進に興味ある方 いずれかに興味お持ちいただける方は、 カジュアル面談 も行っていますのでお気軽にご連絡ください。 hrmos.co

こんにちは。 LIFULLのグループデータ本部データサイエンスグループ所属の岩﨑です。 私の所属するグループデータ本部データサイエンスグループは、LIFULLのデータを通じて事業の成長を促す研究開発を担う部門です。 『データ科学と研究開発の成果によってワクワクと喜びを生み出す』をビジョンとして掲げ、AI技術シーズの創出や活用によってデータの価値を最大化し、社会課題の解決に向けて日々革進をし続けています。 2024年2月24日に開催された「第86回 Machine Learning 15minutes! Hybrid」という機械学習関連のLTを行うイベントで登壇いたしました。 この記事ではそのイベントや登壇内容、感想などを書いていきます。 Machine Learning 15minutes!とは machine-learning15minutes.connpass.com 「Machine Learning 15minutes!」は、「機械学習」について「15minutes以内」で語るLTを6～9人程度で行い、DeepLearningなどの先端的な事例、強化学習などの流行している技術、ビジネスへの応用例など、様々な角度から機械学習についての知見を広げ、LT終了後の懇親会でネットワーキングを行うイベントです。（上記ページより引用） 上に記載しているように、このイベントでは機械学習に関するLTを複数人で行います。その中でLIFULLからは、「LLMを用いた住まい探しにおけるユーザー価値観の推定」と題して、不動産業界でのLLMの研究・活用について共有・議論をしました。 同イベントはオンライン開催のみの時期もありましたが、私が登壇させていただいた第86回の前回からLIFULL AI Hubと協賛という形でLIFULL本社でハイブリット開催をしています。 なお、3/30に開催される次回第87回はミイダス社で、4/27（土）開催の次々回第88回は、再度弊社にてハイブリッド開催を予定しています。 私が感じたように第88回イベントも幅広い機械学習に関連する発表を聞いたり、専門の方と議論ができる機会となると思いますのでぜひ、会場へ足をお運びいただければと思います！ 協賛させていただいていますLIFULL AI Hubは、機械学習やデータサイエンスに特化した知見や成果事例などを社内外に発信していくことを目的としたLIFULL主催のイベントとなります。 詳細はこちらをご覧ください。 www.lifull.blog 発表内容 第86回の登壇者や発表内容は下記のページに記載されています。 発表は大きく3つのカテゴリに分けられており、各カテゴリの発表で機械学習分野の最新情報や社会実装例などの情報共有と議論が行われました。 machine-learning15minutes.connpass.com 生成AIの最新業界トレンド 発表1：【生成AI の未来】 14:05～ 発表2：【ニュース、映画、ゲーム、AIアバターまで、動画と世界を生成する。第2の生成AIブームに備えよう】 14:20～ LLMプラットフォーム最新状況 発表3：【LLMOps with Azure Machine Learning prompt flow】 14:35～ 発表4：【IBMの大規模言語モデルGraniteと生成AI Governance 機能のご紹介】 14:55～ 発表5：【自社で70B LLMを事前学習からやって日本最高精度を達成した話】15:10～ AIディスラプティブ 発表6：【ドメイン知識を活用した、薬局における来局予測】 15:25～ 発表7：【LLMを用いた住まい探しにおけるユーザ価値観の推定】 15:40～ 発表8：【画像・動画・音楽・スピーチ生成AIの進歩】 15:55～ 今後の生成AIについての議論（発表1）、LLM向けのプラットフォームの状況（発表3, 4）、日本最高精度を達成したLLM（発表5）など幅広い機械学習関連のお話を聞くことができました。 その中でLIFULLのデータサイエンスグループからは【LLMを用いた住まい探しにおけるユーザ価値観の推定】（発表7）と題して、不動産業界におけるLLMの活用に向けた研究の紹介をしました。 上記の発表資料はこちらからご覧ください。 www.docswell.com LLMは大規模言語モデル（Large Language Model）と名のつく通り、言語モデルとしてチャットボットなどに利用されることが多い印象を受けます。 しかし、今回紹介した研究ではLLMを単なる言語モデルとしてではなく、ユーザ行動のシミュレーションに利用することでユーザの価値観を深く理解したクローン（デジタルクローン）を開発しています。 このデジタルクローンはユーザの価値観に合った物件推薦や、ユーザにより使いやすいUI/UXへの改善に役立てることができると考えています。 現時点ではまだ研究の初期段階ですが、少ないサンプル数においてはLLMを利用したデジタルクローンが人間と近い物件評価（二つの物件の相対評価）が可能なことを確認できています。下のスライドでは、デジタルクローン・人間双方の物件評価の方法とその精度について説明しています。 イベントに参加した感想 このイベントの感想を参加者、登壇者と目線を分けて書いていこうと思います。 まず参加者としては、幅広い機械学習に関連する発表を聞いたり、専門の方と議論ができるというとても有意義な場だったと感じます。 最先端の技術の話はもちろん、実際に社会実装されている技術・システムのお話などもとても興味深いものでした。 また、会場の雰囲気もあまり堅いものではなく、気軽に雑談や質問ができるとても良い環境でした。 次に登壇者としては、LIFULLのデータサイエンスグループで行っている自身の取り組みを紹介し、意見をいただける貴重な機会だったと感じています。 発表の中でコメント・質問をしてくださったり、その後の懇親会で内容について議論ができたりと、研究やプロダクトをより良い方向へ改善していくためのフィードバックをたくさんいただくことができました。 最後に 今後、さまざまな方と研究開発に関して、意見交換や情報共有を行えればと考えております。 この記事を通じてLIFULLの研究開発に関心をお持ちいただけた方は是非こちらからご連絡ください。 hrmos.co

こんにちは、イノベーション開発室ジェネレーティブAIプロダクト開発ユニットの上田です。 2024/4/1に国土交通省の不動産情報ライブラリとAPIが公開されました！このAPIとGPTsを使って、生成AIでの活用を模索してみました。 不動産情報ライブラリとは 不動産情報ライブラリ 不動産情報ライブラリとは、不動産の取引価格、地価公示等の価格情報や防災情報、都市計画情報、周辺施設情報等、不動産に関する情報をご覧になることができる国土交通省のWEBサイトです。 具体的には、以下のように地図上で不動産情報を確認することができます！ 国土交通省不動産情報ライブラリ（千代田区麹町周辺） また、今回のサイトの公開に合わせて、APIも公開されています。 www.reinfolib.mlit.go.jp APIを利用することで、Webサイトで得られる、不動産価格情報（取引価格・成約価格）、国土数値情報（学区・医療施設・福祉施設・保育園・幼稚園など）などがJSON形式で簡単に取得可能です。 今回は、このAPIを使い「ざっくりした住所を伝えれば、その地域の周辺施設や価格情報を解説してくれるGPTs」を構築してみました！ 住所から周辺情報を教えてくれるAI 以下のように動作します。 LIFULLの生成AIチームのエンジニアが、先日4/1にリリースされたばかりの国土交通省の「不動産情報ライブラリ」のAPIを使ってGPTsを作りました！爆速すぎる！ #LIFULL #エンジニア #不動産情報ライブラリ #生成AI #GAI #GenerativeAI pic.twitter.com/WWfV9csvUj — LIFULL Developer (@lifulldeveloper) April 5, 2024 機能的には、住所を入力することで、その地域の周辺施設や価格情報を解説してくれる、以上のものはありません。 しかしながら、これによって不動産業界では以下のように活用できるのではないか、と感じています。 例えば・・ 不動産仲介業者は：物件やエリアの住所を用いての周辺施設や価格情報を手に入れ、物件の購入や賃貸を探すユーザ対して、ニーズに合った物件・エリアをより迅速に、より正確に提供できる。 物件探しを行うユーザは：GPTsなど生成AIのサポートがあることで、複数地域について気になる観点での比較や、そもそものデータの読み解き方についての知識を補うなど、利用ハードルを下げることができる。 と言ったものが想像できます！これらは今回作成したGPTsから想像できますが、さらに他のデータの活用も視野に入れて考えてると 地域密着情報に詳しい不動産アシスタントAI 地域情報をまとめたパンフレットの自動生成 その地域での暮らしのシミュレーション など、多くの活用が考えられます。 まとめ 不動産情報ライブラリは生成AIの領域においても十分活用可能であることが明らかになりました！ API利用の際には、利用申請が必要でしたが、公開初日に申請したためわずか1日ほどで利用可能になりました。 ※追記：2024/04/05時点では以下のような状況とのことです！ 現在、当初の想定を大きく上回るAPI利用申請をいただいております。 大変恐れ入りますが、APIキーが５営業日以内に発行できない場合もございます。 しばらくの間、ご不便をお掛けすることについて、何卒ご了承ください。 APIの利用申請はこちらから可能です！ https://www.reinfolib.mlit.go.jp/api/request/ また、国土交通省の各種のデータを含め、一つのエンドポイントからこれだけの情報を取得できるのはとても革新的です。各種施設の緯度経度も取得できるので、位置情報のデータ処理を加えることでより柔軟な表現で周辺情報などを扱えるため、より活用の幅を感じました！ 私が所属する組織のビジョンは「ジェネレーティブAIの力で、あらゆる住替え体験の次元を変え、誰もが理想の住生活をおくる未来を引き寄せる」です。我々の部署ではこうした生成AIを活用したプロダクト開発を積極的に行っています！このビジョンに共感し、一緒に新しい価値を創出していく仲間を募集しています！ hrmos.co hrmos.co

こんにちは。エンジニアの小林建太です。 今回はフロントエンド業務での課題をChrome拡張機能で解決を試みた事例をご紹介させていただきます。 LINEヤフー Techから2024年1月に公開された「Tappy」というツールにインスパイアされた拡張機能「 Tap Analyzer 」を開発し、公開しました。 chromewebstore.google.com Tappyとは Tappyの課題と着想 開発した機能 技術 技術選定 開発 chrome debugger API LLMの利用 活用のメリット 今後の展望 Tappyとは Tappy（ https://twitter.com/lycorptech_jp/status/1752587301564436593 より） Tappyは、LINEヤフー Techが開発したスマートフォンのウェブサイトでのタップ操作の成功率を可視化するツールです。URLを入力するだけで、そのページに含まれるボタンやリンクなどのタップ可能な要素のサイズを分析し、指で操作しやすいかどうかを判定して可視化します。現在はiOS端末の解像度のみ対応しています。 tappy.yahoo.co.jp Tappyの課題と着想 私はLIFULLにおいて認証が必要なページを開発していますが、UIについてはデザイナーが作成するデザインを実現するのみで定量的な評価ができていません。特にモバイルの利用者が多いため、ユーザビリティの分析を定量的に行えないかと考えていました。 Tappyで提供される「ウェブサイトでのタップ操作の成功率」はユーザビリティ（使いやすさ）とアクセシビリティ（情報に到達できるか）のどちらにも関わる指標としてある程度有用でしょう。 しかし、サーバー側で処理を行うため、動作にCookieやセッション情報が必要なページでは使用できません。 そこで、Tappyと同様の機能をクライアントサイドで実現するChrome拡張機能を開発することにしました。 ユーザビリティについては以下のIPAの資料が参考になります。 www.ipa.go.jp アクセシビリティについては以下のMDNの資料が参考になります。 developer.mozilla.org 開発した機能 作成したChrome拡張機能は、以下の機能を備えています。 拡張機能「Tap Analyzer」が動作している様子 ウェブページ上のタップ可能な要素(ボタン、リンクなど)の大きさを解析 要素のサイズからタップの成功率を算出 タップ成功率に応じてタップ可能な要素に色付けして可視化 技術 技術選定 拡張機能の作成には Plasmo を利用しました。 Plasmoはブラウザ拡張機能専用のReactフレームワークです。 テストや自動デプロイするための機能なども提供しておりオールインワンなフレームワークです。 Chrome拡張機能はクセが強いChrome APIを利用して作成する必要がありますが、Plasmoはそれらの面倒なポイントを抽象化してくれます。 主な特徴は以下の通り。 React＋Typescript ライブリローディング + React HMR .env ファイルサポート ゼロコンフィグで開発できる 競合としてCRXJSなども挙げられますが、こちらはViteをBundlerにした開発をスムーズにしてくれるもので、Chrome APIの抽象化などはしてくれません。 crxjs.dev 開発 chrome debugger API 私はこれまでに Webpack + Vue.js、CRXJS + Reactなどの構成で拡張機能を作成した経験はあるため、概ね苦労することはありませんでした。 その中で今回初めて触れたのがchrome debugger APIです。 chrome.debugger  |  API  |  Chrome for Developers 大雑把に説明するとChrome Dev Toolsで提供している機能をAPI経由で利用するものになります。 1 つ以上のタブにアタッチし、ネットワーク インタラクションの測定、JavaScript のデバッグ、DOM や CSS の変更などを行います。 今回の拡張機能のウィンドウサイズの変更に利用しています。 chrome.tabs.query ( { active: true , currentWindow: true } , ( tabs ) => { if ( tabs [ 0 ] ?.id ) { chrome. debugger .attach ( { tabId: tabs [ 0 ] .id } , "1.3" , function () { void chrome. debugger .sendCommand ( { tabId: tabs [ 0 ] ?.id } , "Emulation.setDeviceMetricsOverride" , { width: newDevice.getWidth (), height: newDevice.getHeight (), deviceScaleFactor: newDevice.getViewport () .deviceScaleFactor , mobile: true , fitWindow: true } ) } ) } ︙ } ) このように chrome.tab で現在のタブの情報を取得し、そのtab idに対してchrome.debuggerをアタッチしてウィンドウサイズを変更しています。 また、スクリーンショットの取得もchrome.debuggerを利用しています。 chrome. debugger .sendCommand ( { tabId: tabs [ 0 ] ?.id } , "Page.captureScreenshot" , params , ( result ) => { if ( result ) { // 画像保存 const downloadEle = document .createElement ( "a" ) downloadEle.href = "data:image/png;base64," + result.data downloadEle.download = "screenshot.png" downloadEle.click () } } ) LLMの利用 拡張機能開発の本筋ではありませんが、こういった試験的な開発を行いたい時に困るのがデザイン面です。 今回の開発においては拡張機能アイコンとポップアップウィンドウのUIのデザインをどう解決するか迷いました。 結果的に拡張機能アイコンはChatGPTのデザイン系のGPTsで作成し、UIのCSSはCopilotで適当なものを作成してもらい、完成としました。 ChatGPTで作成したアイコン画像 活用のメリット この拡張機能を活用することで、以下のようなメリットが期待できます。 モバイル向けUIのタップ領域の適切なサイズを検討できる 既存のページについて操作性を重視してUIを最適化できる アクセシビリティの観点からも適切な設計ができる Cookieやセッションが必要なページでもTappyの機能を利用可能 今後の展望 現在は一部の機能しか実装されていませんが、利便性を高めていきたいと思っています。 様々な解像度の端末への対応（現在はChrome Dev Toolsでデフォルト設定されたモバイル端末にのみ対応） UIの色分け以外の可視化方法の検討 ユーザビリティの向上 個人で開発したため、個人のRepositoryとして公開しております。 是非、皆さまの貴重な知見やコードをコントリビュートしていただき、一緒にモバイルUIの改善に貢献していきましょう。 github.com LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co