OPENAI SEARCH INSIGHT

2026.08.31 / OpenAI最新情報

loveholidays、Codexで非技術職も開発参加へ

この記事で分かること: loveholidaysがOpenAI Codexを使って非エンジニアの開発参加、データ基盤運用、ソフトウェア提供量をどう変えたのかを知りたい。

OpenAIは2026年8月26日、欧州8市場で事業を展開するオンライン旅行会社loveholidaysが、Codexを通じてプロダクト、デザイン、商業部門をソフトウェア開発に参加させている事例を公開した。狙いは、アイデアをエンジニアリングの優先順位付け待ちに置かず、顧客体験や業務改善へ速く転換することにある。

公式発表によると、同社はデザインシステム、フロントエンド技術、Codexを組み合わせた「Search Playground」を構築した。非エンジニアを含む社内利用者が顧客向け体験を試作・検証でき、すでに10件超の検索体験が開発され、そのうち少なくとも3件が同社Webサイトで稼働している。

OpenAIが示した発表の要点

loveholidaysは、毎日60兆通りの旅行パッケージの組み合わせを処理し、旅行の検索・予約を速く柔軟にする技術基盤を長年にわたり整備してきた企業だ。今回の主題は、その既存プラットフォームを誰が変更・活用できるかをCodexによって広げている点にある。

同社のDmitri Lerko氏（Head of Engineering）は、「誰もがビルダーだ」と説明する。アプリケーションやインフラへの変更、コードのデプロイは、もはやエンジニアだけの活動ではなく、プロダクトマネージャー、デザイナー、商業部門の関係者も価値創出とデプロイに関与しているという。

CTOのMike Jones氏は、技術と従業員の専門知識をAIとCodexによってより広く利用可能にする構想を、「旅行のための一般知能」の構築と表現した。これはOpenAIの公式事例における同社のビジョンであり、汎用AI製品の提供計画や新たなサービス仕様を示すものではない。

Search Playgroundで試作の待ち行列を減らす

従来、新しい顧客体験の案を持つ事業部門の担当者は、プロトタイプを作る価値をエンジニアリング組織に認めてもらい、優先順位に入れてもらう必要があった。ある実験に工数を割けば、別の案件へ投入できるエンジニアリング時間は減る。この機会費用を下げることが課題だった。

そこでエンジニアは、社内のデザインシステムとフロントエンド技術を基盤にSearch Playgroundを作成した。利用者はアイデアを動作する顧客体験へ変換し、フィードバックを集め、価値があるかを検証できる。重要なのは、単に生成AIへ指示して画面を作るのではなく、既存のデザインシステムを使う検証環境として整えた点だ。

公式発表では、マーケティング部門が「Crisps from Abroad」施策向けに、コンテスト応募の受付と旅行情報の提供を行う対話型マイクロサイトを構築した例も紹介された。従来は外部制作会社への依頼が想定されたが、同チームはCodexとSearch Playgroundを使い、既存デザインシステムを維持しながら数時間で構築したとしている。

データ基盤とインフラの専門性をワークフロー化

変化は顧客向け画面の試作にとどまらない。loveholidaysのデータプラットフォームとインフラは、もともと技術者向けに設計されており、変更には専用ツール、リポジトリ、ソースコード管理、社内手順の知識が必要だった。行き詰まった場合は専門エンジニアの支援を受ける構造だった。

同社は、エンジニアリングチームのベストプラクティス、指示、検証をワークフローへ記述し、Codexが他の利用者を案内できるようにしている。利用者は基盤の内部構造をすべて理解しなくても、目的に沿って変更案を作成し、チェックを実行し、リリース工程を進められるという。

ここでのポイントは、専門家の代替を単純に目指すのではなく、専門家の知見を検証手順とともに再利用可能な形へ符号化することにある。公式記事では、データ・インフラ担当者の知識をCodex経由で24時間利用可能な状態に近づけ、セルフサービスの利用者を支える考え方が示されている。

成功率、変更数、デプロイ数に表れた指標

OpenAIの公式発表によれば、loveholidaysのデータプラットフォームにおけるAI支援変更の成功率は、過去1年で58%から93%へ上昇した。また、サポート依頼1件当たりのデータプラットフォーム変更数は4倍になった。より広いセルフサービス型インフラのワークフローでも、成功率は63%から90%へ高まったとしている。

エンジニアリング組織全体では、AI支援を受けたコード変更の割合が1年前の約7%から79%へ増加した。同じ期間にデプロイ数は73%増えた一方、エンジニアリング人員はおおむね横ばいだった。これらはloveholidaysの公表値であり、他社環境で同じ効果を保証する比較実験の結果ではない。

コスト面では、従来は機会費用が高かった最適化に取り組めるようになり、データエンジニアリングチームがクラウドストレージ費用を年約3万6,000ポンド削減したという。さらにデータ処理の無駄を減らすことで、年約10万ポンドの追加削減を見込むとしている。導入・利用量ではなく事業成果でAIを測る姿勢も、同社が強調した点である。

日本の実務で見直すべき設計

日本企業がこの事例から評価すべきなのは、「非エンジニアにもコード生成AIを配るか」だけではない。まず、どの顧客体験、データ変更、インフラ変更なら、利用者の目的、利用可能なコンポーネント、検証、承認・リリースの流れを一つのワークフローにできるかを棚卸しする必要がある。

特に社内のデザインシステム、テンプレート、リポジトリ規約、テスト、変更管理が分散している場合、Codexの利用者が増えても出力品質や統制は揃いにくい。非技術職の自走を促す前に、再利用するUI部品、編集可能な範囲、必須チェック、エスカレーション先を明文化することが実務上の前提になる。

また、データ基盤とインフラは顧客画面の試作より影響範囲が広い。編集部の考察としては、変更の提案、検証、承認、実行の権限を同一視しない設計が重要だ。たとえば低リスクの定型変更から始め、検証結果と変更履歴を残し、例外時には専門チームへ戻す運用を評価項目に加えるべきである。

Agent Memories編集部の考察

この事例の技術的な新規性は、Codexを個人のコーディング補助として使うだけでなく、組織固有の専門知識へ接続する共通インターフェースとして位置付けているところにある。Lerko氏はCodexを、エンジニア、データサイエンティスト、事業部門が共有する「単一のコントロールプレーン」と表現している。

ただし、共通インターフェース化の価値は、AIが出した変更を無条件に採用することではない。むしろ、組織が蓄積してきた設計原則、検証条件、リリース判断を機械可読・実行可能な手順に変える作業にある。AI導入の成否はモデル利用の有無より、知識と統制をワークフローへ落とせるかに左右されると考えられる。

専門エンジニアの役割も、定型依頼を個別に処理する比重から、プラットフォーム、ガードレール、検証、自動化を改善する比重へ移る可能性がある。これは公式記事内でJones氏が述べた、実装だけでなく事業課題へ深く関与する仕事への変化とも整合する。ただし、職務構成や人員計画への影響は各社の統制設計と業務特性に依存する。

よくある質問

loveholidaysでは誰がCodexを使っているのか

OpenAIの公式発表では、プロダクトマネージャー、デザイナー、商業部門のチームが、コードベースへの貢献や顧客体験の試作に関与している。データプラットフォームやインフラのセルフサービス利用者も、Codexに案内されながら変更を進める仕組みが説明されている。

非エンジニアが本番サイトを自由に変更できるのか

公式記事は、少なくとも3件の検索体験がWebサイトで稼働していることを明らかにしている。一方で、全利用者の権限範囲、承認者、具体的な本番反映条件は記載していない。したがって、非エンジニアが無制限に本番変更できるとは判断できない。

成果は開発速度だけなのか

いいえ。公式発表には、AI支援変更の成功率、サポート依頼当たりの変更数、デプロイ数、クラウドストレージ費用とデータ処理の無駄の削減見込みが示されている。loveholidaysは、AIの利用率自体ではなく、事業課題の解決とその影響を測る方針を掲げている。

まとめ

loveholidaysのCodex活用は、アイデアを持つ人と構築できる人の隔たりを縮める取り組みとして注目される。Search Playgroundによる顧客体験の試作と、データ・インフラ知識のワークフロー化を並行させ、開発能力を組織全体へ広げながら成果指標で評価していることが特徴だ。

日本の開発組織では、まず高頻度かつ定型的な変更を対象に、知識、設計部品、検証、権限、監査を一連の運用として整えることが現実的である。Codexを導入するかという選択と同時に、誰が何を安全に変更でき、どの成果をもって価値と判断するかを再設計する必要がある。

本カテゴリはMiraigent / Agent Memoriesによる非公式編集記事です。OpenAIとの提携・承認・後援を示すものではありません。