【この記事の注目ポイント】
- OmioはOpenAI Codexを開発全体に組み込み、製品開発の工数を従来比20%まで圧縮した
- 47カ国・3,000超の交通事業者を束ねる旅行サービスで、生成AIを業務フローの再設計に使った点が重要である
- 日本企業にとっては、AIを足すのではなく業務設計ごと作り直す発想が競争力の差になる
旅行予約の現場で起きている開発速度の変化
あなたの会社でも、新機能を出したいのに社内調整や実装待ちで何週間も止まる場面はないでしょうか。旅行サービスはその典型です。列車、バス、フェリー、航空券をまたぐ予約体験は複雑で、裏側には多数の事業者接続と在庫管理が走っています。今回のOmioの動きは、その複雑さをAIで“少し楽にする”話ではありません。開発組織そのものを、生成AI前提で作り直した話です。
Omioは47カ国で3,000以上の交通事業者と連携するマルチモーダル旅行プラットフォームです。ここでいうマルチモーダルとは、複数の移動手段を横断して最適ルートを扱うことを指します。事業規模が大きいほど、画面1つ直すだけでも確認項目が膨らみます。だからこそ、表面的にAI機能を載せるだけでは効果が出ません。OmioのCTOであるTomas Vocetka氏が、古い業務手順に技術だけを貼り付けるやり方を拒んだ点に、私は強い意味を見ます。
私がこの記事で最も重要だと受け取ったのは、Omioが「AI導入=ツール追加」と考えていないことです。内部業務の進め方を根本から変えなければ、Booking画面の改修速度も、検証の速さも、結局は上がらないからです。現場の開発責任者は、この視点を一度は真剣に考える必要があります。
Codexを開発工程の中心に置いた運用設計
Omioはまず、社内にChatGPTの基礎利用を広げ、従業員が生成AIに慣れる段階を作りました。ここでの役割は、いきなり本番作業を任せることではありません。用語や応答の癖を体感させ、AIとの協働を標準化するための導入でした。そのうえで本命として入れたのがOpenAI Codexです。Codexはコード生成に強いモデルで、ソフトウェア開発が主領域です。
OmioはCodexを研究、アーキテクチャ設計、実装、テスト、コードレビュー、保守まで、開発ライフサイクル全体に埋め込みました。これは単なるコーディング補助ではありません。開発の前後工程を含めてAIに流し込む設計です。しかも同社は、社内データと各種ツールをつなぐ独自コネクタも構築しています。つまり、開発者がまず情報を探すのではなく、IDE(統合開発環境)上で即座に作業へ入れる状態を作ったのです。
成果は数字に表れています。新しい製品を作るための技術作業は、以前の約20%にまで下がりました。ここでの20%は、単なる印象ではなく、同じ成果を出すための工数が5分の1になったことを意味します。さらに、4人以上が四半期がかりで進めていた案件が、1人のエンジニアで約1か月に収まる水準へ縮んだとされています。四半期は約3か月ですから、リードタイムの圧縮幅はかなり大きいです。私はこの差を、AIが“速く書く”のではなく“迷いを減らす”ことで生まれた差だと解釈しています。
Omioの使い方で興味深いのは、2023年にすでに自然言語で旅程を検索・予約できる会話型インターフェースを公開していた点です。例えば「ローマからフィレンツェまで最速で行くには」「パリとバルセロナなら飛行機と列車のどちらがよいか」といった入力に対し、システムがライブの在庫と料金を参照して候補を返します。ここで重要なのは、学習済み知識だけで答えていないことです。実在する予約情報に接続しているからこそ、生成AIが“そのまま予約できるUI”になっています。私はここに、検索から会話へ、さらに会話から取引へ進む流れがはっきり出ていると見ました。
加えてOmioは、責任の所在を人間に残しています。AIは開発、分析、意思決定を速める一方で、最終責任は人が負うという方針です。生成AIが便利かどうかより、誰が最後に止めるのかを決めている点が、実務では決定的です。読者の現場でも、ここを曖昧にしたまま導入だけ進めると、あとで必ず運用が崩れます。
日本企業が学ぶべきは予約画面より業務再設計
日本の旅行会社、交通系プラットフォーム、EC、SaaS開発組織にとって、この事例はかなり示唆が強いです。明日から考えるべきなのは、「どの画面にAIを載せるか」ではありません。「どの業務をAI前提で組み替えるか」です。ここを分けて考えないと、PoC止まりになります。
特に日本企業は、既存の基幹システムや部門分断を残したままAIを入れがちです。しかしOmioは、社内機能を全部AI対応に作り替えるよう求めています。これは厳しい運用ですが、効果は明快です。仕様確認、実装、検証、レビューの往復が減るからです。開発者から見れば、ChatGPTを使えることと、Codexを業務の標準工程にすることは別物です。前者は個人の補助、後者は組織の生産方式の変更です。
私が引っかかったのは、AI導入を“便利な追加機能”として扱う日本企業がまだ多いことです。Omioの事例は、そうした発想が遅れにつながると示しています。3,000社超の事業者接続を抱える環境で20%水準まで工数を落としたなら、国内のもっと小さな組織でも、業務設計を見直せば十分に改善余地があります。とくにbooking、在庫照会、顧客応対、社内レビューのような定型と変動が混ざる領域は、生成AIの効果が出やすいです。
AIを足す企業から、AIで業務を組み替える企業へ
今後は、旅行業界に限らず「AIを導入した会社」と「AIで作業の流れを変えた会社」の差がはっきりします。前者は見栄えのよい機能を増やしますが、後者は開発速度そのものを変えます。Omioのような事例が増えると、客側は自然言語で予約できる体験を当たり前に期待します。そうなると、旧来型の検索画面だけでは競争になりません。
私は、次に問われるのはモデル品質よりも、社内接続と責任分界です。OpenAIモデルをどれだけ賢く使うか以上に、どこまでデータをつなぎ、誰が最終判断を持つかで差がつきます。ここを押さえた企業だけが、生成AIを本当の生産基盤として使い切ります。

編集部コメント
「正直に言うと、Omioの事例は“AIの見せ方”ではなく“組織の作り替え方”の話でした。ここを読み違えると、日本企業はまた便利機能を一つ増やしただけで満足します。私が引っかかったのは、生成AIの議論がいまだにUI中心に偏りがちなことです。本当は、開発手順と責任分界を変えた会社が先に勝ちます。」