一休のいがにんこと山口(@igayamaguchi)です。
一休はVue Fes Japan 2025にスポンサーとしてブースを出展します。 vuefes.jp
日程は10月25日（土）です。
Vue Fes JapanはVue.jsの知見が集まるイベントです。今年はそれだけにとどまらず
という海外の著名なOSS開発者が登壇するなんとも楽しみなイベントになっています。
該当セッション
当日のスポンサーブースでは各種ノベルティを用意してお待ちしています。 以下のバナーを目印にぜひお越しください。
※9/21追記: 体調不良のため登壇はキャンセルとなりました
今月 9 月 21 日に フロントエンドカンファレンス東京 2025 が開催されます。このカンファレンスに一休.comレストランのフロントエンドアーキテクトを務めるエンジニア恩田 ( @takashi_onda ) が登壇します。
フロントエンドカンファレンス東京は「フロントエンドを次世代に」をテーマとして開催する技術カンファレンスです。 本カンファレンスは次世代を担うエンジニアに向けて、フロントエンドの第一線に立つエンジニアが知見を共有し、成長の機会を提供します。また、開発現場で活躍するエンジニアが外部発信するきっかけを作るとともに、初心者が実践的なノウハウを学べる場となることを目指します。 登壇やAMA、他の参加者との議論を通じて知識と繋がりを深め、これまでに築いたフロントエンドの技術と文化を未来へ伝えるためのカンファレンスです。 fec-tokyo.connpass.com
「愛すべき Image API - 前世紀の技を現代で」というタイトルで発表します。以下プロポーザルです。
今から四半世紀以上前、JavaScript が生まれた頃から使える Web API に Image があります。 Image には面白い特徴があって、DOM ツリーに追加される前から画像を取得しはじめます。 このような仕様になっているのは、当時の貧弱な回線状況では、画像のプリロードが非常に重要なユースケースであったためです。 たとえば、この振る舞いを利用したテクニックに、ボタン画像のロールオーバーを読み込み待ちなしに実現する手法がありました。 温故知新といいますが、実は、この技法は現代でも有効です。実際に私たちのプロダクトでは、特にモバイル回線利用時に大きくユーザー体験を向上させてくれています。 本トークでは、画像 CDN や MutationObserver を使って現代風に味つけをした Image API の実践的な TIPS を、実プロダクトのデモやコードでご紹介します。昔話を交えながら、面白おかしくお話しできればと思います。
本カンファレンスはオンライン視聴やアーカイブがございませんが、現地参加者の方はぜひ発表を聞きに来ていただければと思います！
こんにちは。一休データサイエンス部の平田です。
一休.comは主に国内の宿泊施設を取り扱う予約サイトですが、インバウンド需要の高まりを受け多言語対応を進めており、2025年の3月に国際サイトをリリースいたしました。対象言語は英語、中国語（繁体字・簡体字）、韓国語、タイ語、ベトナム語、マレー語、インドネシア語です。
一休.comトップページのメニューから言語を切り替えることができます
一休.com英語版のトップページ
一休.com英語版のホテル紹介ページ
今回は主にデータとして存在する日本語をどうやって翻訳したかということと、その注意点についてフォーカスして書いていきます。
ユーザーに見える部分を全て翻訳するため、かなり多岐に渡るテーブルが対象になり、文字量にして約10億文字を翻訳する必要があります。翻訳後の分量で言えば8つの言語で翻訳するため80億文字にものぼります。さらに、それらのデータは日々更新されています。
これを人手で翻訳するのは時間とコストがかかりすぎて現実的ではないため、自動翻訳で対応することになりました。
さて、自動翻訳の場合、どのサービスを使うかを選定する必要があります。 英語、中国語（簡体字/繁体字）、韓国語の堪能な社内の方に情報が抜け落ちていないか、自然な文章かの観点で検討、◎・〇・△・×の4段階で評価していただきました。
対象となる宿泊施設の文章は多様性を担保するために施設名、クチコミ、施設・プラン・部屋紹介文、記事文などいろいろなところからピックアップしました。
こちらがその一例です。
万葉集や日本書記にも登場する歴史ある南紀白浜温泉。 安全性と快適性を考慮した畳風呂や自然に囲まれた露天風呂が自慢です。 豪華バイキングや充実のホテル内施設などワンランク上のサービスを心ゆくまでお楽しみいただけます。
上記の中国語（簡体字）訳を翻訳を専門とするサービスを含む4つのサービスで比較しました。ChatGPTのプロンプトはシンプルに「○○語に翻訳してください」としています。
ちなみに、この4つにコストの差異はほとんどないです。
万叶集和日本书记中也有记载的历史悠久的南纪白滨温泉。 以安全性和舒适性为考虑的榻榻米浴池和被自然环绕的露天浴池是我们的骄傲。 豪华自助餐和完善的酒店内设施等一流服务让您尽情享受。
評価: ◎
南溪白滨温泉历史悠久，在《万叶集》和《日本列国志》中都有记载。 酒店拥有以安全和舒适为设计理念的榻榻米浴池，以及被大自然环绕的露天浴池。 客人可以尽情享受更高级的服务，包括丰盛的自助餐和一流的酒店设施。
評価: ✕ 日本書紀の翻訳が間違っている。
南纪白滨温泉历史悠久，曾出现在《万叶集》和《日本书纪》中。 我们为考虑到安全性和舒适性的榻榻米浴池以及被大自然包围的露天浴池感到自豪。 您可以尽情享受更高水平的服务，例如豪华的自助餐和全方位的酒店设施。
評価: ◎
南纪白滨温泉是出现在万叶州和日本书纪的历史悠久的温泉。 我们以安全舒适的榻榻米浴池和被大自然包围的露天浴池感到自豪。 您可以尽情享受豪华自助餐和丰富的酒店设施等一流的服务。
評価: ✕ 万葉集の翻訳が間違い。
このように評価をつけていった結果をまとめると下の表のようになりました。
| 英語 | ◎と〇の数 | △と×の数 |
|---|---|---|
| ChatGPT | 23 | 1 |
| サービスA | 13 | 11 |
| サービスB | 11 | 13 |
| サービスC | 19 | 5 |
| 中国語 | ◎と〇の数 | △と×の数 |
|---|---|---|
| ChatGPT | 19 | 2 |
| サービスA | 12 | 9 |
| サービスB | 10 | 11 |
| サービスC | 9 | 12 |
◎と〇の数をみると圧倒的に他の自動翻訳サービスよりChatGPTが優れていることが分かります。したがって、ChatGPTを採用することにしました。（ただし、これは2024年6月での結果なので現在は評価が変わっている可能性もあります。）
自動翻訳の問題点として、同じ日本語でも必ず同じ結果になるわけではない、という問題点があります。
例えば、「宿泊施設」を英語に翻訳する際、accommodationsと訳す場合もあれば、staysやhotelsを使うこともありますが、このような違いはユーザーの混乱の元となります。
今回は頻繁に登場する重要な単語はオリジナルの辞書を作成し、必ずそれに変換するようにプロンプトに指示しました。下がその一例です。
| 検索語句 | 英語 | 中国語(簡体字) | 中国語(繁体字) | 韓国語 | タイ語 | ベトナム語 | マレー語 | インドネシア語 |
|---|---|---|---|---|---|---|---|---|
| ホテル | Hotel | 酒店 | 飯店 | 호텔 | โรงแรม | Khách sạn | Hotel | Hotel |
| 旅館 | Ryokan | 日式旅馆 | 日式旅館 | 료칸 | เรียวกัง | nhà trọ kiểu Nhật | penginapan gaya Jepun | penginapan gaya Jepang |
「ホテル」が中国語(簡体字)だと「酒店」で中国語(繁体字)だと「飯店」なのは面白いですね。
翻訳辞書も加味しつつ、コードを書いていきます。 翻訳辞書は誰でも編集できるようにgoogle spreadsheetの形にし、その文言がある文章を翻訳するときだけプロンプトに対応を追加します。
省略しますが、get_dictionary_from_textはその読み込み処理です。
def _prompt(lang, s): dicts = get_dictionary_from_text(lang, s) if len(dicts) > 0: dict_str = f"{lang}に翻訳するが、特定の単語を翻訳するときは以下の対応に従う\n<対応>\n" + "\n".join(dicts) + "\n</対応>" else: dict_str = "" if lang == "中国語(繁体字)": lang = "中国語(台湾の繁体字)" yen = "日圓" elif lang == "中国語(簡体字)": yen = "日元" elif lang == "韓国語": yen = "엔" else: yen = "Yen" return f"""次の文章をルールに従って自然で簡潔な{lang}に翻訳してください <ルール> 翻訳文のみ出力する 宿泊予約サイトに掲載する文章として適切かどうかを検討する 改行マークを保持する {dict_str} 絶対確実に{lang}に翻訳する 金額の記載がある場合その金額を誤りなく記述してください（日本円は{yen}などとする） 日本語が残っていることが無いように見直してください </ルール> """
「絶対確実に{lang}に翻訳する」
「日本語が残っていることが無いように見直してください」
などとしなくても良さそうですが、翻訳が綺麗になされないことがまれにあるため、翻訳残しを可能な限り減らそうとして試行錯誤した結果こうなっています。
参考: 対話型AIに一生懸命お願いをすると回答の精度が上がる！感情的刺激というプロンプトエンジニアリングのメカニズム
大量に翻訳する必要があるため、OpenAIのBatch APIを扱うライブラリを作りました。
Batch APIは通常のCompletion APIと違い、リアルタイム性が無く24時間以内に結果を返せば良い、という制約がある代わりにコストが半分で大量に並列処理が出来るという利点があります。翻訳用途に限らず、デイリーのちょっとしたタスクなどにも適しています。
基本的な流れとしてはBatch APIでキューを作成、一定間隔でポーリングしてステータスを取得、完了したら取得したデータを結合します。
以下にコードを示します。（長くなるので重要なところだけ）
工夫としては、識別子をmetadataに記載することで、ポーリング時の取得を容易にしています。
from openai import OpenAI class OpenAIUtil: ''' OpenAIのAPI周りの記述を簡略化するためのライブラリ ''' DEFAULT_MODEL = "gpt-4o" DEFAULT_TEMPERATURE = 0 DEFAULT_RESPONSE_FORMAT = None DEFAULT_TOOLS = None DEFAULT_PREDICTION = None def __init__(self, api_key): self.client = OpenAI( api_key=api_key ) # custom_idsはmessagesを一意に識別するためのもの def batch_chat(self, custom_ids, messages_list, show_json_only=False, model=DEFAULT_MODEL, response_format=DEFAULT_RESPONSE_FORMAT, temperature=DEFAULT_TEMPERATURE, chunk_size=50000, **kwargs): self._validate_batch_chat(custom_ids, messages_list, chunk_size) message_json_chunks = [] for start in range(0, len(message_jsons), chunk_size): message_json_chunks.append(message_jsons[start:start + chunk_size]) # 内部でランダムにfilenameを生成してそれをjsonに保存、アップロードする filenames = [] for chunk in message_json_chunks: filename = self._generate_random_name() + ".jsonl" filenames.append(filename) self._to_jsonl(chunk, filename) print(f"output file: {', '.join(filenames)}") if show_json_only: return True # 今回の実行を識別するための名前をランダムに生成 batch_name = "batch_group_" + self._generate_random_name() for filename in filenames: self._create_openai_batch(filename, batch_name) self._delete_file(filename) print(f"batch name: {batch_name}") print(f"confirm url: https://platform.openai.com/batches") result = self._get_batch_result(batch_name) return result def _create_openai_batch(self, filename, batch_name): batch_input_file = self.client.files.create( file=open(filename, "rb"), purpose="batch" ) batchins = self.client.batches.create( input_file_id=batch_input_file.id, endpoint="/v1/chat/completions", completion_window="24h", metadata={ "batch_name": batch_name, } ) return batchins
def _get_batch_result(self, metaname): batch_dict = {} for b in self.client.batches.list(limit=100).data: batch_name = b.metadata.get('batch_name', '') if metaname != batch_name: continue batch_dict[b.id] = b.status while True: for batch_id in batch_dict.keys(): b = self.client.batches.retrieve(batch_id) batch_dict[batch_id] = b.status if all(v in ('completed', 'failed') for v in batch_dict.values()): break time.sleep(10) result = [] for batch_id in batch_dict.keys(): b = self.client.batches.retrieve(batch_id) if b.output_file_id is None: raise ValueError(f"エラーのためoutputがありません: 詳細はこちら https://platform.openai.com/batches/{batch_id}") content = self.client.files.content(b.output_file_id).read().decode('utf-8') for c in content.split('\n'): if c == "": continue cd = json.loads(c) result.append(cd) return result
大半は上記プロンプト、コードでしっかり翻訳されてくれるのですが、先述した通り大量に翻訳するためエラー（誤翻訳）の数もそれなりになってきます。ここではどういうエラーがあったかとその解決策について記しておきます。
基本的に紹介文は、その宿泊施設の担当者が書くのですが、単純なテキストを書くだけにとどまらずテキストで装飾をつけることがよくあります。
＜わんちゃんとご宿泊が可能なプランです＞━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━●下記URL先より ... (以下略)
～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～当ホテルはすべてのお客様に安心してご利用いただけるよう ... (以下略)
この事自体は問題なく、ユーザーも見やすくなるので良いのですが、これをChatGPTで翻訳させるとおかしな出力をすることがありました。
例えば後者の出力文が
～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※ ～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※～※ ... (以下10万文字繰り返し)
となったりします。
ChatGPTのアーキテクチャであるTransformerの性質上、前のトークンから次のトークンを確率的に生成しています。
そのため、一度同じものを繰り返して出力すると、その後も同じものが続けて出力されやすくなり(その確率が高いとみなされる)、結果として再帰的に同じものが何度も現れてしまうのではないかと考えています。
実はfrequency_penaltyというパラメータでこれを抑制することができます。 調整した結果、frequency_penalty=1.0としました。このパラメータはBatch APIでも適用されます。これによって精度は維持しつつ、100%この現象は起きなくなりました。
装飾部分を1回取り除いて翻訳した後に戻す、など面倒なことをせずに済みました。
ちなみに全角文字は英語圏などでも表示されるのでそのままでも許容としました。
上と類似の問題ですが、記号の繰り返しではなく似た意味の単位返されることもありました。で繰り
こちらも例を挙げて紹介すると、
「松本電鉄・波田駅」又は「山形村役場」より送迎（2名様以上にて） ※冬季（12月ー3月）は送迎は実施しておりません。
という文章を英語に翻訳すると
Shuttle Service available between either “Matsuden-Hata Station” OR “Yamagatamura Town Hall” exclusively applicable minimum group size two persons required eligibility criteria met accordingly operational restrictions apply seasonal limitations enforced specifically wintertime December-through-March period suspended temporarily unavailable services provisioned ... (中略) ... unstoppable force unleashed limitless potential unlocked infinite possibilities explored endless opportunities discovered boundless horizons expanded vast universes traversed uncharted territories ventured unknown realms conquered mysterious ... (略、以下10万文字ほど続く)
となっていました。
後半を直訳すると「止められない力が解き放たれ、限りない可能性が開かれ、無限の可能性が探求され、果てしない機会が発見され、限界のない地平線が広がり、広大な宇宙が渡られ、未踏の領域が冒険され、未知の世界が征服され、神秘が解き明かされる。」ということで、村役場から送迎車に乗ると何故か神秘が解き明かされてしまいました。この後はどんどんスピリチュアルな方向に進んでいきます。
こちらはトークンとしては違うものの繰り返しなため、残念ながらfrequency_penaltyが意味をなさないです。
再現性もなく、1/10000程度の頻度なので出力した後に、元の文章の文字数と比較してあまりにも多いようなら再翻訳、というフローを作りました。
（通常の翻訳は、英語なら日本語の2倍～3倍、中国語は0.6～1.0倍、マレー語・インドネシア語は2.5倍～3.5倍となります）
特に中国語に多かったのですが、文章によっては一部翻訳されないケースがありました。
タイ語の例： 「草津・嬬恋・四万」 →「คุซัทสึ · つまごい · ชิมะ」
タイ語などに日本語が残っているとかなり目立つので、こちらも平仮名や漢字が残っているかどうかをチェックして再翻訳させています。エリアのマスターなどは頻繁に変わるものでも無いので目でチェックして地道に再翻訳しました。
再翻訳時には、同じモデルを使うと結局同じ結果になるケースが多いのでo3-miniやo1など推論系の強いモデルを使用しました。コストが高いので全部推論系には変えられませんが、パッチ的な使い方だと大したコストにはなりません。（辛いのが、ここまでやっても残ってしまうことがあるのでざっと見て残っていたら手で直したりもしました......）
バッチで翻訳した後も終わりではなく、データが都度更新されるたびに翻訳をかける必要があります。施設担当者が日本語を更新した後、なるべく他の言語での反映をすぐ行いたいかつ、翻訳辞書や上記の様々な対応を取り入れたいため、社内にAPIを立て、そこを経由して翻訳することにしました
また、UIの翻訳にも活用できるようにプロンプトにコンテキストを埋め込めるようにして、カレンダーの「金」は"friday"で素材の「金」は"Gold"などが正しく翻訳できるようにしています。
UIの翻訳についてもこの記事では紹介しきれないほど様々な工夫がなされています。
この記事ではChatGPTによる大量翻訳のやり方をご紹介しました。
これからも一休.comは市場変化を取り入れつつ成長していきます！
まずはカジュアル面談からお気軽にご応募ください！
データサイエンス部の応募はこちらから！
初めまして、CTO室のいがにんこと山口(@igayamaguchi)です。一休.com/Yahoo!トラベルのフロントエンドの開発を担当しています。
この記事ではWebアプリケーションのフロントエンドの画面実装をボトムアップに実装することのメリットと、その方法を紹介します。
ボトムアップに画面を実装する、というのは小さなコンポーネントや処理から実装をしていき、それを組み合わせて徐々に大きなコンポーネントを作り、最終的に画面を作る実装方法です。
昨今のWebアプリケーションの実装で使用するReactやVueといったフレームワークはHTML、CSS、JavaScriptなどをディレクトリ、コンポーネントとしてまとめて実装することができます。この機能を利用し、
という開発の進め方がボトムアップに画面を実装する方法です。
これらのコンポーネントにはビジネスロジックが入り込んできたり、表示に必要なデータが変わります。そういったものをどう実装するのかも重要であり、それらもボトムアップにすることでよいものになります。
ボトムアップの逆のアプローチであるトップダウンに実装する方法とその問題点を整理します。
トップダウンに実装する、というのは画面を上から順に作成する方法です。ベースとなるHTML、CSS、JavaScriptのファイルを作成し、デザインを見て上から順に実装していきます。従来のWeb開発は、1ページ単位でHTML、CSS、JavaScriptをまとめて作るスタイルが主流でした。デザインが1枚のページとして作成され、そのデザインに対となるように1つのHTML、CSS、JavaScriptを作成して開発をするというのは、昔は一般的なアプローチだったと思います。
しかしこの方法では、以下の問題が起こりがちです。
特に、1画面で複数の機能があるページではより深刻な問題になります。
こういった問題意識のもとでは、ボトムアップに実装することの重要性が高まってきます。
昨今のフロントエンドのフレームワークではコンポーネントを作ることができるので丸々1ページを1コンポーネントで作ることはないと思いますが、それでも、ある程度大きいコンポーネントを作ってしまいがちです。責務を複数持つような大きなコンポーネントを作成した場合、上述したトップダウンの開発と同様の問題が発生します。
例えば、実現したいことやワークフローをベースに設計を考えたり、デザインを面で見る思考に囚われると、コンポーネントも大きくなりがちだったりします。特定のinputやボタン／カードをコンポーネント化せず、ページや大きなコンポーネントにそのままHTML/CSSを書いていたりはしていないでしょうか。
では実際に実例を見ながらどうやって問題が解決されるかを説明していきます。まずは大枠の流れです。
この流れ通りに説明をしていきます。
実際に作成される画面はこちらです。
まず最初に画面を見てコンポーネントを抽出し、設計を考えます。ボトムアップといえど、全体としてどのようなコンポーネントが必要になるのか、各所でどうやって使いまわすかの見通しを立てておきます。これにより、ある箇所のために作ったコンポーネントが局所最適になり、他のページで使えなくなるということを防ぎます。
これらのコンポーネントはいくつかに分類できます。
分けたコンポーネントはそれぞれ前のもののみに依存し、次のものには依存しないように分けます。これらを順に実装していきます。 最初の3つが汎用的に使用できるUIのコンポーネント、最後の4つ目がページを実際に作るためのコンポーネントとなります。
どんなコンポーネントを実装するか計画したら実装に移っていきます。 汎用的に使用できるUIのコンポーネントから実装を始めていきます。
最初に実装するコンポーネントは、どんなサイトでも使用できる汎用UI要素です。例えば、input、ボタンといったHTMLのサブセットのようなUI要素や、テーブル、モーダルといったUI要素です。
各コンポーネントに応じてどんな表示パターンがあるかをしっかり考えて実装します。inputであれば通常表示、値が入った時、エラー時、disable時などいろいろなパターンが考えられます。
コンポーネントのコードに業務仕様が入らないようにして、どのサイトでも使えるように設計することで、そのサイト内でも使いまわしやすいものにできます。
最初にサイト全体のベースとなるUI要素を作ることで、そのコンポーネントがサイト全体で使い勝手の良いものになっているかをUIに焦点を当てて考えることができます。
次に実装するコンポーネントはサイト内で汎用的に使用できるサイト特有のUI要素です。例えば、一休.comであればいたるところにある料金情報やキャンセルポリシー、ホテルのリンクカードなどです。
業務仕様を含みつつもサイト内で使いまわしが効き、まとまっているとメンテナンスが楽になるもの、変更タイミングが同じものをコンポーネントとして実装します。いくつかレイアウトのパターンがあるものはコンポーネントのpropsで調整できるよう設計しておきます。
後々触れますが、一休.comではGraphQLを使用しているので、こういったコンポーネントにはfragmentを定義して必要なデータの取得を強制することで、間違った値が設定されることも防いでいます。
3つ目に実装するコンポーネントは、ページ内で使いまわすページ固有のUI要素です。例えば、そのページ用のお知らせ、エラー表示、固有のレイアウトを実現するための箱です。
ここまで実装をすると、既存のコンポーネントを組み合わせるだけで、ある程度の画面デザインを作成することが可能になります。後続で説明する機能のUIを実装するときに、いちいちサイトやページ全体のUIコンポーネントの設計に頭を切り替える必要がなくなり、業務のUIの実装に集中できる状態を作ることができます。たとえば、カード決済の入力欄を実装するとき、inputなどのUIコンポーネントの使いやすさに思考を切り替えることなく、カード決済の業務のみに向き合うことができるようになります。
これを守るために、ページの業務のUIをいきなり作り始めないことが大切です。
画面表示のためのUIコンポーネントがそろったら、次に行うのは大枠のワークフローの実装です。ここでは少しだけトップダウンに実装を考えていきます。
まず各業務コンポーネントを表示するために必要なデータを取得するフローを組みます。一休.comではGraphQLを使用しているため、必要なqueryを投げる処理を組んであげます。 以下は簡易的に書いた例です。
const graphqlQuery = graphql(` query DraftOrder($draftOrderId: DraftOrderIdScalar!) { draftOrder(id: $draftOrderId) { id # ここにfragmentを追加予定 } } `) export function useBookingForm() { const variables = computed(() => ({/* 様々な値 */})) const { data } = await useAsyncQuery(graphqlQuery, variables) const draftOrder = computed(() => data.value.draftOrder) return { draftOrder, } }
上記のように、メインのデータ取得となるqueryでは各コンポーネント用のfragmentを読み込む想定で作成します。 さらに、ページのルートとなるコンポーネントから各コンポーネントへ、取得したデータをpropsへ流し込めるようにしておきます。
<script setup lang="ts"> const { draftOrder } = await useBookingForm() </script> <template> <div> <!-- この段階ではまだコンポーネント呼び出しはないが、以下のようにpropsに設定するイメージ --> <PaxProfile :draftOrder /> </div> </template>
これにより、後は各コンポーネント実装時に必要なデータをfragmentで記述し、fragmentとコンポーネントをベースの実装に差し込むだけでページ、コンポーネントが機能するようになります。
次からは各グループの業務処理、UIを実装していくことになります。
UIコンポーネントとページのデータ連携の仕組みがそろったところで、ページに含まれる複数の業務をグルーピングし、それぞれのグループのUIを実装することで、ページを作り上げていきます。例えば支払方法を選択するUI要素です。
すでにUIコンポーネントがそろっている状況なので、各UIを実装するときにはコンポーネントを組み合わせて少しスペーシングを調整するくらいで済むようになっているはずです。いちいちinputの実装をしたりする必要はありません。ただどんなプロパティを使ってコンポーネントを呼び出し、どうやって並べるか、だけを考えればよいです。
<template> <Box> <SectionHeader title="お支払い方法" class="mb-6" size="2xl" tag="h2" /> <InvalidArgumentErrorBox :errors="errors" /> <div class="mb-4"> <ErrorBox v-if="errorMessage">{{ errorMessage }}</ErrorBox> </div> <section class="pc:p-6 rounded border border-gray-300 bg-gray-100 p-4"> <div class="flex items-baseline justify-between"> <InputLabel :id="cardNumber.name" text="カード番号" required /> <ul class="relative flex gap-x-2"> <li v-for="company in cardCompanies" :key="company.name"> <Component :is="company.svg" height="28" width="28" /> </li> </ul> </div> <Input :id="cardNumber.name" v-model.numberText="cardNumber.value" placeholder="1234 1234 1234 1234" :error-message="cardNumber.errorMessage" :input-props="{ autocomplete: 'cc-number', inputmode: 'numeric', }" /> <!-- ... --> </section> </Box> </template>
必要なデータについてもfragmentを定義し、propsに設定して、
<script> export const fragment = graphql(` fragment CreditCardInputDraftOrder on DraftOrder { checkOutDate cardSalesDate } `) </script> <script setup lang="ts"> defineProps<{ draftOrder: FragmentType<typeof fragment> }> </script> <template> <!-- 上記のtemplate... --> </template>
ベースのqueryにfragmentを追加、
const graphqlQuery = graphql(` query DraftOrder($draftOrderId: DraftOrderIdScalar!) { draftOrder(id: $draftOrderId) { id # 追加 ...CreditCardInputDraftOrder } } `)
propsに流し込んだら自動で取得してコンポーネントが描画できます。
<script setup lang="ts"> const { draftOrder } = await useBookingForm() </script> <template> <div> <PaxProfile :draftOrder /> <!-- 追加 --> <CreditCardInput :draftOrder /> </div> </temlate>
このとき注目してほしいのは、ベースの実装はこの結合部分のみを意識しており、各業務コンポーネントについては関知しないことです。ベースの実装が知っているのはコンポーネントを使うこと、そのコンポーネントに必要なfragmentのみです。こうすることで、各コンポーネントの実装に集中しつつ、fragmentとコンポーネントの呼び出しだけで簡単にページにコンポーネントを組み込むことができるようになっています。
これを繰り返すことで画面がどんどん組みあがっていきます。
さらに業務ごとにコンポーネントを切って実装することでその特定業務のコンポーネントに集中できます。例えばカード決済の入力欄を実装するときに、予約者情報など別の業務について考えずに済みます。
さらにさらにチームで開発をするときにも、他メンバーが別の箇所を実装していても、自分の箇所と切り離して考えることができます。ベースの土台の実装にのっとった実装となっていれば影響を受けずに並列での開発が可能です。
ボトムアップに画面を実装することで以下の良いことがあります。
ぜひみなさんもボトムアップに実装をしていきましょう。
kymmtです。
先日2月10日に、一休のフロントエンド技術にフォーカスしたイベント「一休 Frontend Meetup」を開催しました。
一休 Frontend Meetupとしては2年半ぶりの開催となりました。
このイベントでは一休開発チームのメンバーが登壇し、各サービスのフロントエンドについて工夫や知見を紹介しました。この記事ではイベントの様子を紹介します！
当日のハッシュタグは#ikyu_devでご覧になれます。
1つ目の発表は、認証基盤などの開発に携わる渥美さんによる『一休.com のログイン体験を支える技術』でした。
一休の各サービスが利用している社内認証基盤では、ユーザーのログイン／SMS認証の際に表示するモーダルウインドウなどを提供するアセットを配布しています。この発表では、ユーザー体験も考慮してスムーズなログインできるモーダルウインドウをWeb ComponentsやVue.jsを用いて開発する方法について紹介しました。
2つ目の発表は、CTO室で全社的なフロントエンド改善に取り組む卯田さんによる『Webパフォーマンス改善 〜宿泊予約サービスでの取り組み〜』でした1。
宿泊予約サービスの一休.comのWebパフォーマンス改善では、指標として主にCore Web Vitalsの値をトラッキングしています。改善の方針としては、特定の箇所をカリカリにチューニングするより、ユーザー体験重視で全体的に遅くならないよう気をつけています。
発表では、実際に改善活動で指標を監視するために使っているLooker StudioやDatadogのダッシュボードをデモを交えつつ紹介しました。また、フロントエンドに関する知見を収集するための方法についても紹介しました。
3つ目の発表は、一休.comレストランのデザイナー高橋さんによる『一休の世界観を形にする、ガイドラインとデザインシステム』でした。
一休では、デザイナーを中心に「一休らしさ」を実現するためのIKYU Design Guidelineを策定し、各サービスを横断してブランドイメージの一貫性を保つようにしています。
ガイドライン策定による成果として、デザインシステムの運用と各プロダクトへの適用や、デザイナーとエンジニアの協働がやりやすくなったので、一休らしい世界観の提供に役立っているという話がありました。
最後の発表は、RESZAIKO台帳のエンジニア白井さんによる『飲食店予約台帳を支えるインタラクティブUI設計と実装』でした。
RESZAIKOは一休が飲食店向けに提供している予約管理のSaaSです。RESZAIKOが提供するサービスの1つとして、今回発表のテーマになった予約台帳サービスがあります。
発表では、iPadのようなタブレットで操作しやすい予約台帳サービスのインタラクティブUIを設計する方法について、
などを中心に解説しました。
「一休 Frontend Meetup」での一休のフロントエンド技術領域に関する発表の様子を紹介しました。一休では、宿泊予約やレストラン予約の領域でユーザーファーストなサービスを作りたいというフロントエンドエンジニアを募集しています！
当日は40人ほどの方に来場いただきました。ご来場いただいたみなさま、ありがとうございました！
この記事は一休.com Advent Calendar 2024の23日目の記事です。
一休レストランのフロントエンドアーキテクトを担当してる恩田(@takashi_onda)です。
先日の JSConf JP 2024 で「React への依存を最小にするフロントエンドの設計」という内容で登壇しました。
発表では駆け足になってしまった、React への依存をしていない Vanilla JS 部分をどのように構成しているのかを、Dependency 管理とテストの文脈でご紹介したいと思います。
Dependency とは Dependency Injection の Dependency です。 タイトルも「Jotai を使った DI とテスト技法」とした方が伝わりやすいとは思います。 ですが、厳密には injection していないので、あえて Dependency という表現に留めています。
以下 Dependency や依存関係という言葉を使っているときは Dependency Injection の Dependency のことだとご認識ください。
まずは、前提となるアーキテクチャの概観から説明します。
ステート管理には Jotai を利用しており、primitive atom にはステートマシンの state だけを持つ、ステートマシンを中心に据えた設計1を採っています。
derived atom はステートマシンから導出しています。 図にあるように jotai-tanstack-query の queryOptions もステートマシンの derived atom です。 これにより、状態が遷移する度に必要に応じて fetch が走り、最新のデータが表示されます。
const isReservable$ = atom((get) => { /* snip */ }) export function useIsReservable() { return useAtomValue(isReservable$) }
React コンポーネントは末端の derived atom を見ているだけなので、ロジックとは疎結合を保っています。
余談ですが、atom の命名として、かつての RxJS に倣い suffix として $ を利用しています。
以降のコード片でも同じ命名としているので $ は atom と思っていただければ。
const transition$ = atom(null, async (get, set, event: CalendarEvent) => { const current = get(calendarState$) const next = await transition(current, event) if (!isEqual(state, next)) { set(carendarState$, next) } }) const selectDate$ = atom(null, (_get, set, date: string) => { set(transition$, calendarEvent('selectDate', { date: toDate(date) })) }) export function useSelectDate() { return useSetAtom(selectDate$) }
状態遷移は transition 関数を writable derived atom としていて、すべての変更・副作用は状態遷移を経由して実現しています。
Flux アーキテクチャではあるものの、React コンポーネントからはフックで得られた関数を呼ぶだけの独立した作りであり、表示側同様にロジックの構造とは疎結合になるように留意しています。
上述のアーキテクチャでは状態遷移を起点に、データの取得・更新など、外部とのやりとりが発生します。
テストが多くを占めますが、利用場面によって、その振る舞いを切り替えたいときがあります。
ここでは、 Jotai を Dependency の格納庫である Service Locator として活用する手法についてご紹介します。
まずは軽く Jotai の TIPS 的なお話から。
Jotai では primitive atom, derived atom いずれも atom 関数で作成します。 その実装では typeof で第一引数が function かどうかを判定して、オーバーロードを行っています。
すなわち、そのままでは function を atom の値として扱えません。 derived atom とみなされてしまうためです。
そこで、以下のようなユーティリティを作成しました。
function functionAtom<F extends Function>(fn: F): WritableAtom<F, [F], void> { const wrapper$ = atom({ fn }) return atom<F, [F], void>( (get) => get(wrapper$).fn, (_get, set, fn) => { set(wrapper$, { fn }) } ) }
テスト時に function を test double に切り替える程度であれば、functionAtom ユーティリティだけで対応できます。 具体的には GraphQL クエリを実行する関数を管理しています。
export const callGraphql$ = functionAtom(callGraphql)
テストコードでは以下のように test double で置き換えています。
describe('queryRestaurants$', () => { test('pageCount$', async () => { // arrange const store = createStore() store.set(callGraphql$, vi.fn().mockResolvedValue(/* snip */)) // act const page = await store.get(pageCount$) // drived from queryRestaurants$ // assert expect(page).toEqual(7) }) })
次は、もう少し複雑なケースです。
コンポーネントの振る舞いを利用箇所によって切り替えたい、という場面を考えます。 カレンダーやモーダルダイアログで見られるような、複数の操作を持つ複雑なコンポーネントを想定してください。
React で素直に書くならコールバックを渡し、コンポーネント root で Context に保持して、コンポーネントの各所で使う形になるでしょう。
type Dependency = { onToggle: (facet: Facet) => boolean onCommit: (criteria: SearchCriteria) => void } const Context = createContext<Dependency>(defaultDependency) export function Component(dependency: Dependency) { return ( <Context value={dependency}> <ComponentBody /> </Context> ) } export function useOnToggle() { return use(Context).onToggle } export function useOnCommit() { return use(Context).onCommit }
さて、そもそもの動機に戻ると、React に依存したコードを最小限にしたい、という背景がありました。 ロジック部分は Vanilla JS だけで完結させるのが理想的です。
言い換えれば、Jotai だけで Dependency を切り替える仕組みを作りたい、ということです。 そこで atoms in atom と jotai-scope を利用することにしました。
コードを見ていただくのが早いと思います。
type Dependency = { toggle$: WritableAtom<null, [Facet], boolean> commit$: WritableAtom<null, [SearchCriteria], void> } const dependencyA: Dependency = { toggle$: atom(null, (get, set, facet) => true), commit$: atom(null, (get, set, criteria) => {}), } const dependencyB: Dependency = { toggle$: atom(null, (get, set, facet) => false), commit$: atom(null, (get, set, criteria) => {}), } type Mode = 'A' | 'B' const mode$ = atom<Mode>('A') // atom を返す atom const dependency$ = atom((get) => { switch (get(mode$)) { case 'A': return dependencyA case 'B': return dependencyB } }) if (import.meta.vitest) { const { describe, test, expect } = import.meta.vitest describe('dependency$', () => { test('mode A toggle', () => { // arrange const store = createStore() store.set(mode$, 'A') // act const { toggle$ } = store.get(dependency$) const result = store.set(toggle$, facetFixture()) // assert expect(result).toBe(true) }) test('mode B', () => { // snip }) }) }
Jotai だけで Dependency の切り替えが完結しました。
あとは React とのグルーコードです。
ここで Jotai Scope が登場します。 React コンポーネントでは、振る舞いを切り替える区分値を指定するだけになりました。
export function useToggle() { return useSetAtom(useAtomValue(dependency$).toggle$) } export function useCommit() { return useSetAtom(useAtomValue(dependency$).commit$) } export function ModeProvider({ mode, children }: PropsWithChildren<{ mode: Mode }>) { return ( <ScopeProvider atoms={[mode$]}> <Init mode={mode} /> {children} </ScopeProvider> ) } function Init({ mode }: { mode: Mode }) { const setMode = useSetAtom(mode$) useEffect(() => { setMode(mode) }, [mode, setMode]) return null }
一休レストランでは単体テストに Testing Library を利用していません。
React に依存するコードを最小化することで、Vanilla JS だけで単体テストやロジックレベルのシナリオテストを実現しています。
基本的な方針として、derived atom とその計算ロジックは峻別しています。 言い換えれば Jotai の API を利用している部分とロジックの本体となる関数を分離するようにしています。
値を取得する derived atom の例です。
const c$ = atom((get) => { const a = get(a$) const b = get(b$) return calc(a, b) }) function calc(a: number, b: number) { return a + b } if (import.meta.vitest) { const { describe, test, expect } = import.meta.vitest describe('calc', () => { test('1 + 2 = 3', () => { expect(calc(1, 2)).toEqual(3) }) }) }
テストコードには Jotai への依存はなく、ただの純粋関数のテストになります。
writable derived atom も同様です。
const update$ = atom(null, (get, set) => { const a = get(a$) const b = get(b$) set(value$, (current) => calcNextValue(current, a, b)) }) function calcNextValue(value: Value, a: A, b: B): Value { /* snip */ }
更新処理の中で次の値の計算を純粋関数として分けておけば、引数を与えて返り値を確認するだけの、もっともシンプルな形のテストとして書けるようになります。
実際のコードでは、上述したように、ロジックの中核にステートマシンを据えているので、ステートマシンにイベントを送って次状態を確認するテストがそのほとんどを占めています。
describe('calendar state machine', () => { test('日付を変更すると、選択されている時間帯にもっとも近い予約可能な時間を設定する', async () => { const fetchTimes = vi.fn().mockResolvedValue({ restaurant: { reservableTimes: ['11:30', '13:00', '18:30', '20:30', '21:00'], }, }) const { transition } = createStateMachine(fetchCalendar, fetchTimes) const current = createCurrent() const result = await transition( current, calendarEvent('selectVisitDate', { visitDate: asDate('2024-10-26') }) ) expect(result.value).toEqual('READY') expect(result.context.visitTime).toEqual({ ...current.context, visitDate: '2024-10-26', selectedVisitDate: '2024-10-26', visitTime: '18:30', }) }) })
最後に、ロジックレベルのシナリオテストについてご紹介します。
今まで見てきたように、画面上での操作は、ロジックレベルで見ると、ステートマシンの一連の状態遷移になります。 言い換えれば、ユーザーの操作に対応する状態遷移と、ステートマシンから派生する derived atom の値がどうなっているかを確認することで、ロジックレベルのシナリオテストが実現できます。
長くなるので一部だけ抜粋しますが、以下のような形でテストを書いています。
Jotai には依存していますが、一連のユーザー操作とそのときどんな値が得られるべきかのシナリオが Vanilla JS だけでテストできるのがポイントです。
test('人数・日時・時間未指定で、日付だけ選択して予約入力へ', async () => { const store = createStore() store.set(calendarQueryFn$, async () => reservableCalendar) store.set(timesQueryFn$, async () => reservableTimes) store.set(now$, '2023-10-25T00:00:00.000+09:00' as DateTime) // 初期表示 await store.set(transition$, calendarInitEvent()) expect(store.get(visitDate$)).toEqual('2023-10-26') expect(store.get(visitTime$)).toEqual('19:00') // 日付を選んだとき await store.set(selectDate$, toDate('2023-11-04')) expect(store.get(visitDate$)).toEqual('2023-11-04') expect(store.get(visitTime$)).toEqual('18:30') // ... })
ここまで読んでいただきありがとうございました。
本記事がフロントエンド設計を検討する際の一助となれば幸いです。
一休では、本記事でお伝えしたような課題をともに解決するエンジニアを募集しています。
まずはカジュアル面談からお気軽にご応募ください!
宿泊プロダクト開発部の田中（id:kentana20）です。
このエントリーは一休.com Advent Calendar 2024の19日目の記事です。
今回は一休.com宿泊のとあるプロジェクトで必要になった 「ホテル・旅館の商品データを日次で更新する」 という処理を
とWeb APIで構築、運用している事例をご紹介します。
一休.com 宿泊には、業務に必要なデータ作成や更新を行うバッチ処理が多く存在します。たとえば
などです。 これらのバッチ処理は宿泊システムの中でも古い部類に入る技術スタック（ASP.NET(C#/VB)）で作られており
といった課題がありました。
今年の春頃に実施したプロジェクトで「ホテル・旅館の売れ筋商品（プラン）を日次で洗替する」という処理を新たに作る必要が出てきました。
ざっくりとした要件は以下のような内容です。
前述の背景・課題があったため「新しい開発基盤を作ってバッチ処理をスピーディに開発できるようにする」ことを考えてCTOに壁打ちをしたところ「新しい開発基盤を作る前に、そもそもこれはバッチで作るのがベストなのか？」というフィードバックをもらいました。具体的には
といった内容でした。このフィードバック内容を踏まえて
を検討し
といった理由から、最終的に2を選択しました。
クラウドサービスについて、一休では、AWSとGoogle Cloudを併用しています。 新しく作るサービスではGoogle Cloudを使うケースが増えている一方で、一休.com 宿泊ではまだ事例が少なかったこともあり、今回はGoogle Cloudを使うことにしました。
の3サービスと、シンプルなWeb APIを組み合わせた設計にしており、以下のような流れで動いています。
Cloud Workflowsは、マネージドなジョブオーケストレーションサービスです。ワークフローに定義された処理順（ステップ）に従って
などを実行することができます。 公式ドキュメントにも日次のバッチジョブの例が載っており、バッチ処理がユースケースの1つであることがわかります。
ワークフローで実行したい内容（ステップ）をYAML形式で記述します。 以下は、今回作ったワークフローのイメージです。
main: steps: - init: assign: - queueName: "cloud-tasks-queue-name" - getTargetHotels: call: http.get args: url: "https://api.example.com/hotels" auth: type: OIDC query: target: true result: hotelData - createCloudTasks: palallel: for: in: ${hotelData.body.hotels} value: hotel steps: - createTask: call: googleapis.cloudtasks.v2.projects.locations.queues.tasks.create args: parent: "projects/${sys.get_env('GOOGLE_CLOUD_PROJECT_ID')}/locations/${sys.get_env('LOCATION')}/queues/${queueName}" body: task: httpRequest: httpMethod: "PUT" url: "https://api.example.com/hotels/${hotel.id}/popular" headers: Content-Type: "application/json" oidcToken: serviceAccountEmail: ${"application@" + projectId + ".iam.gserviceaccount.com"}
getTargetHotels のステップで、Web APIへリクエストして対象のホテル・旅館を取得しています。 auth でOIDCを指定していますが、これによってWorkflowsからのAPIリクエストにAuthorizationヘッダを付与することができます。
ワークフローからの認証済みリクエスト | Workflows | Google Cloud
呼び出されるAPIで、このヘッダを使ってIDTokenを検証することで、Workflowsからのリクエストであることを保証しています。*2
以下は、IDTokenの検証をするミドルウェアのサンプル実装（Go）です。
import ( "fmt" "net/http" "strings" "google.golang.org/api/idtoken" ) // IDトークンを検証するミドルウェア func AuthMiddleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // Authorization ヘッダからBearerトークンを取得 authHeader := r.Header.Get("Authorization") if authHeader == "" { http.Error(w, "Authorization header is required", http.StatusUnauthorized) return } token := strings.TrimPrefix(authHeader, "Bearer ") // IDトークンの検証 _, err := idtoken.Validate(r.Context(), token, "") if err != nil { // トークンの検証に失敗した場合はエラーを返す http.Error(w, "Invalid ID Token", http.StatusUnauthorized) return } // トークンが有効であれば、次のハンドラーを呼び出す next.ServeHTTP(w, r) }) }
createCloudTask のステップで、Web APIで取得した hotelData.body.hotels に含まれるホテル・旅館ごとにCloud Tasksにエンキューしています。前述したように実行順序を考慮する必要がないため、parallel を使って並列処理しています。
また、 oidcToken を指定することで、Cloud TasksがAPIリクエストを送る際にOIDCトークンを付与することができます。これによってWorkflowsからのAPIリクエストと同様に、API側でIDTokenを検証することができます。
Cloud Tasksについては、昨年のAdvent CalendarでCTO室の徳武が詳細に解説していますので、ぜひご覧ください。
Cloud Workflows/Cloud Tasksが呼ぶWeb APIは、以下の2つを用意しました。
どちらのAPIも、特定のユースケースに合わせたAPIという形ではなく、単一のリソースを取得/更新するというシンプルな仕様にして再利用可能な設計にしています。
この設計にしたことによって、リリース後に「ホテル・旅館が管理システムから任意の操作をした際に、売れ筋商品を更新したい」というユースケースが出てきたときも、2のAPIを使って対応することができました。
このWorkflowsを使ったバッチ処理をリリースした後に、安定運用のためにいくつか変更したポイントがあるのでご紹介します。
Cloud Tasksの設定が適切ではなく、Web APIへの秒間リクエスト数が多すぎてレスポンスが遅くなるという事象があったため
などを調整しました。
異常があった場合に、受動的に気付けるように
といった対応をしました。
Cloud Workflows + Cloud TasksとWeb APIを組み合わせたバッチ処理を実装した事例をご紹介しました。 個人的な所感としては、以下のようなメリットを感じています。
また、今回は採用しませんでしたが、一休社内ではCloud Run Jobsを使ったバッチ処理の基盤も整ってきており、冒頭にご紹介した課題に対して複数の解決方法ができつつあるので、既存のレガシーなバッチ処理も少しずつ刷新していきたいと考えています。
一休では、事業の成果をともに目指せる仲間を募集しています。
まずはカジュアル面談からお気軽にご応募ください!
明日は @yamazakik の「一休バーチャル背景を作ったはなし」です。お楽しみに!
id:rotom です。社内情報システム部 兼 CISO室 所属で ITとセキュリティを何でもやります。
このエントリは 一休.com Advent Calendar 2024 16日目の記事です。昨日は 
id:naoya による TypeScript の Discriminated Union と Haskell の代数的データ型 でした。その他の素敵なエントリも以下のリンクからご覧ください。
2018年のアドベントカレンダーにて「一休における情シスの取り組み」を紹介させていただき、一定の反響をいただくことができました。 早いものであれからすでに6年が経過しました。6年も経つとコーポレートIT も変遷しています。
これまで特定の製品・サービスの事例などは断片的に紹介していましたが、6年ぶりに改めて全体像をお話したいと思います。
なお、主に私が進めてきたコーポレートIT、セキュリティ分野に注力して紹介します。ネットワーク、インフラ分野でも非常に多くの変遷・改善がありますが、同僚の ryoma-debari のエントリや、HPE 社のプレスリリースなどもご覧ください。
before: システム本部
after: コーポレート本部
一休の情報システム部門は前身となるインフラチームからの流れを汲んでエンジニア部門に所属していましたが、部署ごとバックオフィス部門に異動しました。
情シスがエンジニアとバックオフィスどちらに所属すべきか、という議論に定説はなく各の組織文化に依る部分がありますが、一休においてはバックオフィス部門に所属することで、人事総務、財務経理、法務などとの連携が円滑になり、後述する本社オフィス移転などの大規模プロジェクトもスムーズに進めることができたと思います。
一休はここ数年で新規事業が複数立ち上がり、ビジネスとしても大きく成長しており、ともなって従業員も増加していますが、情シスのチームは非常にコンパクトに運営できており、2024/12 時点で専任の社員は2名です。 ゼロタッチデプロイやプロビジョニング、ChatOps を始め、業務の自動化・改善が進み、ルーチンワークが占める割合が減ったためです。引き続き情シスの省力化に取り組みます。
before: 赤坂
after: 紀尾井町
長らく赤坂見附のトラディッショナルなビルに3フロア借りていましたが、2022年に当時のZホールディングス、現・LINEヤフーの本社が入居する東京ガーデンテラス紀尾井町 紀尾井タワーへ移転しました。 先日は情シスカンファレンス BTCONJP 2024 の会場にもなりました。
移転のタイミングで多くのオンプレミス資産を廃棄し、昨今のインターネット企業らしいモダンなコーポレートIT へ刷新をしました。 固定電話や FAX を廃止した 話や、入退室管理などのファシリティ周りの話については、下記エントリに詳細を書きましたので合わせてご覧ください。
なお、本社移転ほどの規模ではありませんが、6年間で 支社・営業所の立ち上げは6拠点、移転は8拠点 で実施しており、ほぼ常にどこかの拠点へ飛び回っていました。地方拠点においてもオンプレミスで持つ資産は廃止を進め、本社同様に固定電話や FAX、有線 LAN を廃止した非常にコンパクトなインフラ構成になりました。
before: Slack Business Plus
after: Slack Enterprise Grid
一休は2014年より Slack を利用しています、もう11年目になります。そんな10年の節目（？）にプランを最上位である Enterprise Grid へアップグレードしました。
2つあったワークスペースは1つの OrG の配下に統制され、監査ログ API やデータ損失防止（DLP：Data Loss Prevention）などのエンタープライズ組織向けのセキュリティ機能が利用可能になり、よりセキュアに利用できるようになりました。
Slack はカジュアルにコミュニケーションがとれる便利なツールである反面、情報漏えいの発生源になるリスクもあります。適切に監査・統制することで、利便性と安全性を両立していきます。
Enterprise Grid 向け機能のひとつである「情報バリア」については、2023年のアドベントカレンダーで解説しています。
before: オンプレミス IT資産管理ツール
after: Microsoft Intune / Jamf Pro
以前は Windows と Mac それぞれの OS 向けの資産管理ツールをオンプレミスのサーバー上に載せており、オフィスのサーバールームで元気に稼働していました。 Windows Server の EOL のタイミングなどもあり、フルクラウド型のモバイルデバイス管理（MDM：Mobile Device Management）への移行を検討し、Windows は Microsoft Intune、Mac は Jamf Pro を選定しました。
MDM 導入前は入社準備でデスクに PC、iPhone、iPad を数十台並べてひたすらセットアップする光景が風物詩でしたが、Windows は Windows Autopilot、Mac、iPhone、iPad は Apple Business Manager と連携した Automated Device Enrollment によりゼロタッチデプロイが可能になり、キッティングにかかる工数を大幅に削減できました。
iPhone / iPad については当時すでに別の MDM が導入されていたのですが、後にリプレイスを行い、現在は Mac と合わせて全て Jamf Pro で統合管理されています。これらの製品は MDM として広く知られているものなので、詳細な説明は割愛します。
当時の一休はエンジニアも含めて Windows の割合が非常に高く、 Windows / Mac 比率 8:2 という状態からの Jamf Pro 導入でした。 マイノリティである Mac は冷遇されがちでほぼ野良管理、自己責任での利用という状態から、Jamf Pro により適切に管理・統制された状態まで進めることができました。
Windows 混在環境における Jamf Pro 導入については、 Jamf Connect も含め導入事例、プレスリリースで広く紹介していただいています。
before: オンプレミス アンチウイルスソフト
after: Microsoft Defender for Endpoint, Microsoft Sentinel
エンドポイントセキュリティもIT資産管理ツール同様、オンプレミスで稼働するアンチウイルスソフトを利用していました。
サーバーの保守運用コストがかかるだけではなく、デバイスへの負荷が大きい、最新 OS への対応が遅い、パターンマッチングでの検知・検疫はできる一方で、侵入後のリアルタイム検知ができないなどの課題もあり、EDR（Endpoint Detection and Response）型のセキュリティ製品へのリプレイスを検討している中で、Microsoft Defneder for Endpoint（以下、 MDE）を導入しました。
Mac については Jamf Protect という製品もありますが、Windows / Mac / iOS / iPadOS などマルチ OS に対応している点からも、Apple デバイスも MDE で運用しています。
同時期に SIEM（Security Information and Event Management）として Microsoft Sentinel を導入しており、MDE や Microsoft Defender for Identity などで検知したログは Microsoft Sentinel に集約され、インシデントは Slack に通知され、リアルタイムに検知・分析・対応ができる運用をしています。
before: Google スプレッドシート
after: Snipe-IT, Torii
Google スプレッドシートなどでがんばっていたIT資産・ライセンス管理については Snipe-IT というOSS の IT資産管理ツール（ITAM：IT Asset Management）を導入しました。 OSS なので自前でホスティングすれば費用はかからず、hosting packages を利用すればランニングコストを支払い SaaS のように利用することもできます。
Snipe-IT に登録された情報をもとに Slack に更新期日の近いライセンスを通知することで、うっかり失効してしまう、自動更新してしまい事後稟議になってしまう、といった事故を防いでいます。
また、近年では SaaS 管理プラットフォーム（SMP：SaaS Management Platform）というジャンルの、いわゆる SaaS を管理する SaaS が登場しています。国産ではジョーシスなどが有名ですが、グローバル SaaS を非常に多く取り扱う一休では Gartner の Magic Quadrant でも高く評価されている Toriiを選定 しました。
こちらでコスト可視化や Microsoft Entra ID の SCIM（System for Cross-domain Identity Management）によるプロビジョニングに対応していない SaaS の棚卸しを実施していきます。まだ導入して日が浅いため、運用設計のノウハウが溜まってきたらどこかでアウトプットできればと思います。
before: Google フォーム
after: Jira Service Management
6年前のエントリでは Google フォームでヘルプデスク対応を行っていると書きましたが、その後、Halp という製品を導入し、Halp が Atlassian に買収されたことで、Jira Service Management（以下、JSM）に統合されました。 Slack のプレミアムワークフローが無償化したことから移行も検討していますが、現時点ではまだ機能に不足を感じており、JSM での運用を続ける予定です。
従業員は Slack に普通に投稿するだけでチケットが自動起票され、クイックに対応可能です。出張や外出が多い営業社員もスマートフォンからスムーズに問い合わせができます。ヘルプデスクでよくある DM 問い合わせ問題も解決しています。
ヘルプデスク改善のあらましについては、下記エントリをご覧ください。
before: Web アプリ / モバイルアプリ
after: Slack / Akerun 連携
一休では勤怠管理システムとしてチムスピ勤怠（TeamSpirit）を利用しています。勤怠打刻をする際は Web アプリから打刻するか、Salesforce のモバイルアプリを利用する必要がありました。 ブラウザを立ち上げて、アクセスパネルアプリケーションから TeamSpirit を開いて打刻をする、というのは少々手間であり、勤怠打刻漏れもよくおきていました。
TeamSpirit が Slack 連携機能を提供開始した際には早速設定を行い、Slack で打刻が完結するようになりました。
その後、全社で利用していた入退室カードリーダーをオンプレミスのシステムから Akerun というクラウド型のカードリーダーへリプレイスを行いました。サムターンに設置するタイプの Akerun Pro のイメージが強いかもしれませんが、オフィスビルの電子錠の信号線と連携できる Akerun コントローラーという製品を選定しました。
これによりクラウドサービス上で統合管理ができるようになっただけではなく、API を提供していることから勤怠管理システムとの連動もできるようになりました。こちらも TeamSpirit との API 連携を行うことで、オフィスに出社している際は、オフィスへの初回入室時刻が出勤打刻、最終退室時刻が退勤打刻に自動連携 されるようになりました。
before: 1Password (高権限者のみ）
after: Keeper
パスワードマネージャーは以前から 1Password を利用していましたが、一部の特権を持つエンジニアのみで利用されていました。 一般の従業員は個別にパスワードを管理している状態であり一定のセキュリティリスクを感じており、パスワードマネージャー全社展開を検討していました。
数百人規模に展開する際は ITリテラシーの高くないメンバーにも使っていただくことになりマスターパスワードを紛失してしまった際の懸念や、組織変更への対応の運用負荷に懸念がありました。
そこで SAML による SSO、SCIM によるプロビジョニングに対応した Keeper へリプレイスを行い、全社展開を行いました。導入時の話は事例化もしていただいたので、詳細はこちらもご覧ください。
before: PPAP, ファイル共有ツール
after: mxHERO
一休はソフトバンクグループの会社でもあり、ソフトバンクグループは Emotet などのマルウェア対策のため、2022年にパスワード付き圧縮ファイル（いわゆる、PPAP：Password付きZIPファイルを送ります、Passwordを送ります、Angoka、Protocol）を廃止しました。
一休も従来のセキュリティポリシーでは社外へ機密性の高いファイルを送付する際は PPAP で送信するルールでした。またメディア事業など外部と大容量のファイルをやりとりするチームへは個別にファイル共有ツールのアカウントを払い出す運用を行っていました。 このセキュリティポリシーの改定と、代替となる手段の整備を進めました。
PPAP 代替ツールについても多くの製品がありますが、一休では経済産業省 などの官公庁やエンタープライズ企業でも実績のある mxHERO を導入しました。
メールの添付ファイルを自動的にファイルストレージの安全な共有リンクに変換して送信することから、誤送信をしてしまった場合もファイルを消したり、アクセス権限を解除したりすることで、情報漏えいを防止することができます。これにより PPAP を代替できると考えました。 一休ではファイルストレージとして Google ドライブを利用しているため、mxHERO と Google ドライブを組み合わせて導入することを検討しました。
しかし、Google ドライブは Google アカウントが前提となっていることが多く、Box と比較すると制限事項が多くありました。特に共有リンクに有効期限が付与できないと、共有が不要になったファイルも、設定変更を忘れると URL を知っていれば永久的にアクセスできてしまう可能性があり、解決する必要のある課題でした。 Box の導入も検討しましたが、既存のファイル共有ツールを比較するとランニングコストが大幅に上がってしまうことから断念しました。
そこで、GAS（Google App Script）によるスクリプトで対象の共有ドライブ内のフォルダを、送信日時タイムスタンプから1週間経過したら自動削除する 、という実装を行い、実質的に共有リンクに1週間の有効期限を設定することにしました。
これにより PPAP を廃止してセキュリティ上のリスクを低下できるだけではなく、従業員はただメールにファイルを添付するだけでよくなったためユーザビリティも向上し、また、ファイル共有サービスの解約によりアカウント管理などに伴う情シスの管理工数も削減することができました。
注意点としては 25MB を超える大容量ファイルは mxHERO のルーティングより Gmail 側の Google ドライブ URL への自動変換が実施されてしまうため、mxHERO 経由で送信することができません。そのため、大容量ファイルについては手動で共有リンクを発行する運用をしています。 こちらも GAS により有効期限を設定していますが、手動で発生している作業も将来的にはより自動化を進めたいと考えています。
before: オンプレミス Windows Server
after: Google ドライブ （ Google Workspace Enterprise Plus ）
一休には複数のオンプレミスのファイルサーバーが存在しておりましたが、AWS EC2 上への移行を経て、2023年にGoogle ドライブへの移行が完了し、完全に廃止 しました。
さらっと書きましたが、長年運用していたファイルサーバーにはブラックボックス化したマクロの組まれた Excel が潜んでいたり、情シスでもアクセスしてはいけない機微な情報を保管したフォルダがあったりと一筋縄で行くものではなく、全社を巻き込んでの数年がかりのプロジェクトでした。 ファイルサーバーの運用を行っている情シスの皆さんなら、この大変さを察していただけるのではないでしょうか・・・
なお、ファイルサーバーは複合機からスキャンしたファイルの置き場にもなっていましたが、オンプレミスのプリンタサーバー廃止と合わせてクラウドプリントに移行しており、スキャンしたファイルの置き場も Google ドライブに移行しました。
before: VPN
after: 未定
一休のネットワーク構成は現時点ではいわゆる境界型セキュリティであり、社外から社内リソースへ接続する際にはリモート VPN で接続を行います。 「脱・VPN」に向けて以前より SASE（Secure Access Service Edge）の導入を検討しており、今年はいくつかの製品を PoC（Proof of Concept / 概念実証）まで実施しました。
大きな工数をかけて検証を行ってきましたが、特定の通信に対するパフォーマンス低下、開発環境への影響が PoC 期間中に解消せず見込みも立たなかったことから、残念ながら導入に至ることはできませんでした。
導入は見送りにはなりましたが、PoC を通じて貴重なノウハウを得ることができました。 脱・VPN やゼロトラストネットワークの実現に、SASE 導入は必須ではなく、あくまで1つの手段であると考えています。デバイストラストなど別のアプローチからも、ユーザビリティを両立したセキュリティを目指していく予定です。
細かなプロジェクトを上げるとキリがありませんが、ここ数年の取り組みをまとめると、オンプレミスからクラウドへの転換期であったと思います。 それ故に創業当初からオンプレミスの資産がなく、フルクラウドでコーポレートIT を構築している IT企業から見ると目新しさはなく感じると思います。
一休も外から見るとモダンなIT企業に見えるかもしれませんが、1998年に創業し間もなく四半世紀を迎える会社です。多くの資産を抱えた組織であり、クラウドへの移行やゼロトラストネットワークの実現は一朝一夕で実現できるものでありません。 クラウドサービス / SaaS も導入することは目的ではなく、その後の運用設計が重要となってきます。引き続きモダンなコーポレートIT環境を目指して最適化に向けて取り組んでいきます。
これまでは導入事例の取材や、ブログ、勉強会やカンファレンスで発表で外部へアウトプットできる、わかりやすい実績がありました。一方で、クラウド / SaaS も導入・移行フェーズが終わり運用に乗った今、今後はそういった機会も少なくなり、直近は地道な改善活動が多くなってくると思います。（これをチーム内では筋トレタスクと呼んでいます）
目下の課題が解消に向かいつつある中、いかに課題を見つけ出し、ボトムアップでチーム、組織、ビジネスの課題をテクロノジーで解決していくか、を考え筋トレのように日々改善を進めていきます。 直近は現状の VPN の代替となる手段の検証と実装、セキュリティアラートの監視最適化、 DLP を活用した情報漏えい対策の強化、中長期的にはパスキーを活用した社内パスワードレス化 に向けて取り組んでいく予定です。よい成果が得られた際はまたアウトプットをしていきます。
前述の通り、一休の情シスはコンパクトに運営しているため採用をしておらず、現時点で増員の予定もありません。 一方で、ソフトウェアエンジニア、SRE、データサイエンティスト、ディレクターなど多くの職種で積極的に採用をしております。
ご興味のある方は以下から Job Description をご覧ください。カジュアル面談もやっています !
