こんにちは、カカクコムCTOの京和です。
この記事は 食べログアドベントカレンダー2025 の24日目の記事です🎅🎄
2025年、食べログはサービス開始から20周年を迎えました。本記事では食べログのサービス黎明期を当時の私の視点で振り返りつつ、20周年を経て、AI時代のこれからについて書きたいと思います。
食べログ黎明期の振り返り
食べログは今から20年前、2005年3月にサービスを開始しました。 当初は現在のような検索・予約サイトではなく、「レストランの口コミサイト」としてスタートしました。
時代を感じる当時の食べログトップページ
そして2025年、食べログは日本の誰もが知る日本最大級のグルメサイトへと成長し、20周年を迎えることができました。20周年を記念したムービーが公開されていますので、既に見たことがある人も、まだ見たことがない人もぜひご覧ください。
私は2007年から2012年まで食べログに参画していて、一度退職を経て、2019年に再びジョインしました。2019年以降は食べログに関わる人達も増えているので、今回は食べログ老人会の一員1として、黎明期の話にフォーカスしたいと思います。
Rails フルリニューアルプロジェクト
2007年10月19日、食べログは Windows + ASP + SQL Server で構築されていたシステムを、Linux + Rails + MySQL へフルリニューアルしました。当時の空気感を伝える資料として、CNET Japanの記事が残っています。
「カカクコム、「食べログ」の開発環境にRuby全面採用--国内最大規模の事例に」
2007年当時でも食べログの月間UUは約380万人でした。まだ一定規模以上のサービスがRailsを本番採用する事例はほぼ見かけず、公開されている移行事例としてはおそらく国内初だったのではないかと思います。
リニューアルのきっかけ
始まりは2007年4月、当時24歳の若造エンジニアとして尖り散らかしていた私は、入社して2ヶ月ほどで食べログのシステムにフラストレーションが溜まり、仕事を早々に片付けて残りの時間でRailsでゼロから作り直すトライをしていました。まだエンジニアが私を含め3人ほどの時代です。 当時の食べログのシステムは一つの画面のすべての処理が一つのASPファイルに集約されており、MVCという概念もなく、最初の2000行くらいは共通コードで他にもコピペコードが大量に散乱していました。
若造の私はパワーポイントで説得する資料を作るよりも、実際にものを見せたほうが圧倒的に早いと考えていました。なので最初のバージョンができるまでは誰にも何も言わずに一人で進めていました。かっこいい言い方をするとスカンクワークスのようなものです。
Railsで一つの画面を再現してソースコードなども含めてエンジニアの上長に見せたところ、反応は上々でした。そのまま事業責任者である村上（現カカクコム社長）に持っていくと、「今は事業成長を優先させたい。だから3ヶ月でやるならいいよ」と言われました。無茶いいやがって、、、と正直自信はありませんでしたが、「やります」と宣言して、プロジェクトが始まりました。
結果的には3ヶ月で実装を完了させましたが、リリース後にアクセス負荷に耐えきることができず、最初の移行は失敗しました。そこからパフォーマンスチューニングやバグ修正などにもう3ヶ月を費やし、約半年後の10月19日、ようやくリリースに成功しました。移行には3回失敗し、次で失敗したらもうRails化は諦めよう。そんな泣きの4回目のリリースで無事にトラフィックを捌き切ることができ、安堵したことをよく覚えています。
リニューアル後の苦闘
リニューアル後、開発速度が上がりサービスの成長が加速する中で、今度はパフォーマンス・安定性との戦いが始まります。実感として苦しかったのはRubyよりも圧倒的にDBのパフォーマンスで、トラフィック増とデータ量増という2つの掛け算によって、至るところで新しい問題が生まれていました。
当時、社内のグループウェアとして使われていたガルーンには「食べログシステムスレ」というスレッドが存在していました。 このスレッドをダウンロードしてみると、約2.3MBの巨大なテキストファイルになりました。そこで、このファイルを NotebookLM に読み込ませ、当時の私が何と戦っていたのかを分析してもらいました。 以下の表はその中のほんの一部を抜粋したものです。
| 年月 | 主要な活動 |
|---|---|
| 2008年9月 |
|
| 2009年1月 |
|
| 2009年6月 |
|
| 2009年7月 |
|
| 2009年9月 |
|
NotebooLMの分析結果の要約では、
「当時の京和氏の投稿は、食べログがPV数とデータ量を急速に拡大していく中で、パフォーマンスの限界に継続的に挑戦し、アーキテクチャの変更や地道なインフラ/クエリチューニングを通じてサービスを支えていた記録となっています。」
と書かれていました。本当にそのとおりですね。
今では想像しづらいかもしれませんが、この頃は「トラフィックを捌く」こと自体がまだ難しい時代でした。 例えば Twitter（現X）も、アクセス集中時によくサービスダウンしており、「Twitter is over capacity.」というメッセージとともに、クジラが運ばれていく画像が表示されていました。2インターネット老人会の方であれば覚えている方も多いのではないでしょうか。
一方で、サイトのパフォーマンスが事業に大きく影響するという認識が広まり始めた時期でもありました。Amazonが2006年に発表した「0.1秒の遅延で売上が1%減少する」という検証結果は大きなインパクトがありました。
食べログでは2008年にレストラン一覧画面のチューニングを行ったところ、PVが一気に 120〜130% 伸びたことを今でもよく覚えています。速さは価値であり、エンジニアリングがユーザーと繋がっていることを肌で感じた瞬間でした。 パフォーマンスチューニングは、エンジニアだからこそできる最高の事業貢献の一つだと思っていて、私は今でもチューニングが大好きです。
Railsリニューアルの振り返り
Railsリニューアルによってコード量は約10分の1に圧縮され、開発速度は体感でも2〜3倍以上は速くなったと思います。OSSのエコシステムの恩恵を受けることができたことや、優秀なエンジニアを採用できるようになったことも踏まえると、さらに大きな効果があったと言えるでしょう。改めて振り返ると、リニューアルのインパクトは極めて大きかったと言えます。
結果的にRailsはPythonやPHPなど他の言語のフレームワークにも大きく影響し、その後10年以上に渡ってスタンダードの一つであり続けました。
- 口コミというデータをランキングという価値に変えるアルゴリズムの発明
- ユーザーに圧倒的なスピードで価値を届けるプロダクト開発組織
この2つが揃ったことが、食べログの技術的な持続的競争優位を築き、技術面から事業成長を大きくレバレッジできたのだと思います。
その中身は大きく変化し続けていますが、今でも食べログは Rails で動いています。今の食べログシステムのファーストコミッターであることは、私の数少ない、ちょっとした自慢です。
ファーストコミットは2007年4月16日12時23分。おなじみの "rails generate" でした。
ただ、これも次の10年の間には確実に変わっていることでしょう。生成AIによって、技術を取り巻く状況は大きく変化しました。「変わること」を恐れないこともまた、サービスが長く持続するための必要条件だと考えています。
食べログはなぜここまで成長できたのか
2015年頃、村上と会ったときに、ふとこう聞いたことがあります。
「食べログって、なんで成功したんですかね？」
返ってきた答えは、少し意外でした。
「運がよかったからかな」
もう少しかっこいいことを言ってもいいのにと思いました笑
ただ、その一言は今でも強く印象に残っています。
ここからは、その言葉を起点にした私自身の振り返りとして、食べログがなぜここまで成長できたのか、幾つか思うポイントを挙げていきたいと思います。
組織全体が徹底的にユーザーファーストだったこと
食べログは当時からユーザーとの距離が非常に近いサービスでした。食べログコミュニティには「機能改善要望」というスレッドがあり、「ここに書かれたものは即対応しよう」という方針がありました。書かれた要望にすぐに対応することで、「ここに書けば対応してもらえる」ということでさらに意見が集まります。 要望 → 対応 → 信頼 → さらなる要望という良い循環が生まれていました。
機能改善要望についての昔の社内説明資料
サービスが成長するにつれて、機能追加の影響範囲は広がり副作用がも大きくなるため、慎重に検討する必要が出てきます。また、コミュニティ運営そのものの難易度も上がっていきました。その結果、現在は食べログコミュニティは終了していますが、黎明期だからこそ成立していた価値の高い取り組みだったと言えるでしょう3。
また、「レビュアー懇親会」というオフラインイベントも開催しており、私もエンジニアとして参加して直接ユーザーと話す機会がありました。
レビュアー懇親会に参加する若かりし著者
当時、特に驚いたのは、彼らが食べログのサービス状況を極めて正確に把握していたことです。深夜のバッチ処理が遅くなってレプリケーション遅延が発生していたとき、あるレビュアーさんが「だいたい〜時くらいになると見えるようになるよ」と言ったのですが、その“何時くらい”がピタリと当たっていました。運営として内部の仕様を知っている私たちよりも細部を理解しているユーザーがいるというのは、大きな衝撃でしたし、それくらい熱意のあるユーザーに支えられているということを実感しました。
そしてもう一つ大きかったのが、事業責任者である村上が誰よりもヘビーユーザーだったことです。今から考えると迷惑な話ですが、改善点や問題点に気づいたら時間を問わずすぐに連絡してきましたし、新機能や改修をいざリリースしてから「これおかしくない？」と意見してくることも日常茶飯事でした。
ただ、その “細部までこだわり抜く” 姿勢が、高い品質基準になっていたのも事実です。その姿勢は、現在当社が掲げている「OTAKU SPIRIT」というバリューを当時から体現していたと言えます。
方法論として「名前がつく前」のことを実践する
2025年の現在では、ウェブサービスを運営するためのベストプラクティスや方法論が数多く確立されています。一方で、食べログの黎明期はそうした概念がまだ十分に言語化・体系化されていなかった時代でした。
例えば、先ほど触れた「機能改善要望」は、今で言えば Slack や Discord を使ってユーザーコミュニティを作り、ロイヤルユーザーから継続的にフィードバックを得る取り組みに近いものです。しかし、当時はそうした言葉や手法が一般化しておらず、自分たちがユーザーからの要望を取り入れるために考えた結果として行き着いた方法でした。
それ以外にも、振り返ると方法論として「名前がつく前」に自然と実践していたことがいくつもありました。
スケールしないことをする
この有名な言葉をポール・グレアムがブログに書いたのは2013年のことです4。サービスの黎明期、私たちはレビュアー一人ひとりと対話し、電話帳や雑誌を片手に新店情報を一件ずつ手動で登録し、外部のグルメブログの運営者に個別に勧誘メールを送るなど、今の規模では到底できないことを愚直に積み重ねていました。
「効率化」とは真逆にあるその泥臭い積み重ねこそが、初期の食べログのデータベースの質と熱量を決定づけ、結果として競合他社が容易には模倣できない強固な資産になったのだと思います。
エンジニアの越境
私はエンジニアでありながら「データ登録チームのリーダー」を兼務していた時期があります。 職種の役割分担よりも、「今、サービスにとって何が足りていないか」を基準に動く。職種の壁を超えて、サービスに必要なことは何でもやるというスタンスでした。 エンジニアがコードを書くことに閉じず、サービス全体を前に進めるために越境することは、当時はごく自然な行動だったと思います。
2008年の組織図。インフラとデータ登録チームに名前が載っていますが、当然のようにシステム開発チームの仕事もしていました。
"マイクロサービス以前"のサービス分割
「マイクロサービス」という言葉が広まる2014年よりずっと前、2010年頃から食べログではモノリスの肥大化に危機感を持ち、システムの分割や、フロントエンドとバックエンドの分離を進めていました。
当時は、「このまま一つのシステムに機能を積み上げ続けると、開発も運用も立ち行かなくなる」という感覚が、エンジニアの間で共有されていました。そこで進めていたのが、当時の言葉でいう「サブシステム化」です。今から見れば未熟な分割で、正直に言えばあまりうまくいかなかったのですが、
- 影響範囲を限定する
- 変更しやすい境界を作る
- チームごとに責任を持てる単位を切り出す
といった考え方は、現在のマイクロサービスの思想と本質的には近いものでした。
重要なのは、単に流行っていたから分割したのではなく、必要に迫られて分割したという点です。名前や理論が先にあったわけではなく、現実の痛みの課題解決する方法の一つとして選んだアーキテクチャでした。2011年にその当時の取組内容を発表した登壇資料が残っています。
私が尊敬する経営者である任天堂の元社長、岩田聡さんの言葉をまとめた『岩田さん: 岩田聡はこんなことを話していた。』という書籍があります。この本には、まだ1on1やユーザビリティテストといった言葉が広まっていない時代から、岩田さんや宮本さんがそれらを自然と実践していたことが書かれています。
仕事においては多くの場合、ベストプラクティスは帰納的に生まれます。先に言葉があり、それに従うのではなく、課題に向き合い、試行錯誤した結果として、後から名前がつけられます。
誰かに教わったわけではなく、目の前の課題に向き合い、必要なアプローチを自分たちで考え続けた結果、自然と「正しそうな形」にたどり着いていた。食べログの黎明期は、そのような事が多くあったと感じています。
ワンウェイドアの意思決定に勝ち続けたこと
ここからは私の完全に感覚的な話ですが、大きな事業を創る過程では、一度の判断ミスで成長が止まる、そんな局面が何度も訪れると思います。そうした「後戻りできない意思決定（ワンウェイドア）」を、何回、何十回と正解し続けることが大きな成功には必要不可欠なのではないかと思っています。
経営における「アート・クラフト・サイエンス」という3つの切り分けで言うと、ここは間違いなくアートの領域になるでしょう。しかも、ここは事業責任者にしかできないことです。食べログ黎明期においてはもちろん失敗も多くありましたが、最終的にはワンウェイドアの意思決定においては村上は正解し続けていた印象があります。ただ、どんな人でも100発100中、意思決定を当てられるわけではありませんし、外部環境など自分ではコントロールできない領域もあります。なので、最終的には運の要素が大きいのは間違いないでしょう。
ただ、「運がよかった」という言葉の裏には、
その運を受け止められるだけの“基礎体力”――例えるなら事業や組織の筋力のようなもの――を、日々の積み重ねで鍛え続けていた
という前提が必要条件だと思います。そうした前提を備えたうえで、初めて運否天賦の勝負に挑むことができる。それが、この規模のサービスを立ち上げるということなのだと思います。
ユーザーに向き合い続けること。
名前のない仕事を厭わないこと。
そして、ここぞという場面でワンウェイドアを踏み切る覚悟を持つこと。
村上の言った「運がよかった」は、謙遜でもあり、実感でもあり、同時にその裏にあった積み重ねを含んだ言葉だったのだと、今は解釈しています。
AI時代のこれから
食べログのAI活用における現在地
さて、時計の針を2025年に戻して、今年の話をしましょう。
技術面の取り組み
技術面では、Cursor / Devin / Claude Code といったAIコーディングツールの活用は、すでに“特別な取り組み”ではなく、現場の当たり前になりつつあります。 一方で、SDLC（ソフトウェア開発ライフサイクル）全体を高速化するには、コーディング以外のプロセスも合わせて強化していく必要があります。AI活用当初からその状況を見越して、レビューやQA、開発プロセスへのAI適用を推進してきました。
そして同時に、別の課題も出てきました。それは、“開発環境やプラットフォームの古さ”という 環境側の制約がボトルネックになるという状況です。開発環境が古いままだと、AIエージェントが自由に行動できなかったり、多数並行して稼働すること難しかったり、人間の関与を多く必要としてしまったりします。 そのため2026年は、AIツールの導入・活用だけでなく、開発環境全体を根本から見直し、再整備していくことにも、より踏み込んでいく必要があると考えています。AIで速く作れる時代だからこそ、速く・安全に・安心してリリースできる土台が重要になります。
事業面の取り組み
事業面では、 Voice AI Agentがユーザーの代わりにお店を予約してくれる、「ネット予約（リクエスト予約）」が一部地域で始まりました。来年以降、段階的に全国に展開されていく予定です。
そして2026年は、プロダクト体験の中核にAIが本格的に組み込まれる年になるでしょう。私たちはいま、「お店探しのAIエージェント」を食べログアプリ内に搭載することを計画しています。
場所やジャンルから検索して選ぶだけでなく、パーソナライズされたAIが自分のことを理解して、お店を提案してくれ、予約まで完結する。 そんな体験が当たり前になる日も、そう遠くないのかもしれません。
2025年に改めて感じた「人の重要性」
また、AI活用が進めば進むほど、逆説的に 「人の重要性」 を再認識した1年でもありました。
1. コミュニケーションの重要性
コーディングなどの「作業」をAIが代替するようになった結果、エンジニアの役割はより高度な設計へ、そしてステークホルダーとの対話や合意形成へとシフトしています。これらはAIが代替できない、典型的な“人と人の仕事”です。
2. 「問い」の質と、成果物への責任
AIは答えを出してくれますが、その質を決めるのは人間の「問い」です。AIに適切な問いを投げ、回答を吟味し、対話を繰り返して、自分の思考と生成物の質を研ぎ澄ませていく。このプロセスにおいて、個人差が強烈に出るようになりました。人間側で判断軸やゴールイメージがないと、ただAIの提案を受容するだけになり、それでは成果物の品質は上がりません。
生成AI時代の新しい問題として「ワークスロップ（workslop）」という言葉が最近出てきています5。これは、AIによって低品質の成果物を大量生産し、レビューや修正の負担を受け手に押し付けるという問題です。
3. AI時代においても、人を動かすのは人
どれだけAIが進化しても、最終的に組織を動かし、事業を推進するのは人間の熱量です。技術だけでは越えられない壁があり、最終的には信頼や共感が成果を左右する場面が増えていることを痛感しています。AI時代だからこそ、人間力が相対的に重要になっているのだと思います。
AIネイティブカンパニーとして目指す未来
AIの進化を見ていると、「人間にしかできない創造的な活動」という領域は、今後ますます狭くなっていくと感じます。AIは文章を書き、コードを書き、デザインを行い、スライドも作る。 人間のあらゆる知的な活動を、実用的な形でAIが再現できる段階に近づいていると言えるでしょう。
一方で、AIにはできないことがあります。
それは 意思決定をすることと、責任を引き受けること です。
どんなプロダクトを作るのか。
誰の、どんな課題を優先するのか。
どこで勝負し、どこで引くのか。
これらは最終的に、人間が決めるしかありません。そして、その判断の結果に責任を持つのも人間だけです。 意思決定と責任を引き受け、周囲を巻き込み物事を推し進めていくリーダーシップがこれからますます重要になると感じています。
去年のアドベントカレンダー6で私は、AIネイティブとは 「既存の業務プロセスにAIを部分的に当てはめるのではなく、業務の根本的な設計段階からAI活用を織り込んだ形で設計し直すこと」 だと書きました。
それはAI活用の一側面で、今、私の考えるAIネイティブカンパニーとは、そうした深いAI活用を通じて、 「意思決定と責任を引き受ける人間が、より良い判断を下せる状態を組織として作れている会社」 だと思っています。
AIよってあらゆる作業が代替されていった結果、人間の役割は薄れるどころか、むしろますますより純度高く、鮮明な状況になっていくでしょう。
おわりに
20周年のテックブログということで、PdM、デザイナー、営業など様々な職種の方にご協力いただきました。改めてありがとうございました。
後世に歴史を残すということも、私たちの重要な役割です。今では失われてしまったデータも多いのですが、今あるものを残していくこと。今回それができたことを、個人的にも嬉しく思っています。
今回のアドベントカレンダーの執筆や編集のプロセスを通じて、それぞれがこれまでの食べログ史を振り返り、次に繋げていければと思います。
食べログでは、20年の歴史を未来へ繋いでいく仲間を募集しています！
ご興味のある方は、ぜひこちらもチェックしてみてください。
- 食べログ老人会が気になる方はぜひ「食べログ老人会 × Z世代！？ 入社14年目と若手が語り尽くす、激動の技術変遷」をご覧ください。↩
- 「How Twitter Slayed the Fail Whale」でアクセス増に苦戦するTwitterの当時の様子と、あのクジラは何者かについて書かれています。↩
- 「年表で振り返る食べログ20年の歴史 〜20年分の感謝を込めて〜」にコミュニティも含めた食べログの歴史はこちらに詳しく書かれているので、より詳細を知りたい方はこちらの記事をぜひご覧ください。↩
- 「Do Things that Don't Scale」を参照ください。末尾にはなんとサムアルトマンの名前があり、ニヤリとしてしまいました。↩
- 「Beware co-workers who produce AI-generated ‘workslop’」↩
- 「カカクコム社のテックカンパニー、そしてAIネイティブへの道」↩
