Navanの出張・経費MCPに見るエージェント対応の段階設計 — 読み取り専用のデータ接続から取引委任へ
法人出張・経費管理のNavanがMCPを公開し、ClaudeやChatGPTから出張・経費データを分析可能にしました。読み取り専用から承認・予約という取引委任へ進む段階設計を、小売・ECにも通じるエージェント対応の事例として読み解きます。
この記事のポイント
- 法人出張・経費管理のNavanが2026年7月2日にMCP（Model Context Protocol）を公開し、ClaudeやChatGPTなどのAIツールから出張・経費データを自然言語で分析できるようにしました
- 初期版は読み取り専用ですが、経費承認やポリシー更新、外部AIからの出張予約への拡張が明言されており、データ接続から取引委任へ権限を段階的に広げるエージェント対応の設計例になっています
- 自社の取引データに公式の接続口を用意し、閲覧から承認・購入へと委任範囲を広げていく手順は、AIエージェント経由の販売に備える小売・EC事業者の実装計画にそのまま転用できます
Navanが公開した出張・経費MCPの中身
Navan announced the launch of its Model Context Protocol (MCP), which allows customers to connect Navan to their existing AI tools and securely access their travel and expense data.
aithority.com2026年7月2日（米国時間）、AIを軸にした法人向け出張・経費管理プラットフォームのNavan（NASDAQ: NAVN）が、自社サービスのMCP（Model Context Protocol）提供開始を発表しました。顧客企業はNavanを自社で使っているAIツールへ接続し、出張と経費のデータを自然言語の質問だけで分析できるようになります。接続先はClaude、ChatGPT、CursorをはじめとするMCP対応システム全般で、特定のAIベンダーに縛られない設計です。
本記事はこの発表を、旅行業界の新機能としてではなく、取引データを持つ事業者がAIエージェントへ接続口をどう開くかという事例として読み解きます。エージェンティックコマースとは、AIエージェントが利用者に代わって商品やサービスの発見、比較、購入といった手続きを進める販売のあり方を指します。出張・経費管理はその最前線から遠く見えますが、後述するとおり、取引のエージェント化が最初に大規模化しやすい領域と目されています。
想定ユーザーは出張管理者と財務責任者です。発表では「ポリシー外の支出が最も多いのは世界のどのチームか」「第2四半期の500ドル超でフラグが付いたまま未承認の経費をすべて表示して」といった質問例が挙げられています。有効化は管理者がNavanの設定画面でIntegrations内のMCPをオンにするだけで、技術文書や用途別のプロンプト集は開発者ポータルに公開されています。
NavanのMCPは、当社のエコシステム全体を従業員の日常のワークフローに直接持ち込むための重要な一歩です。10年以上にわたるNavanのデータを活用して構築しており、旅行領域で最もコンテキストを理解したMCPの一つとして、今後のさらなる機能拡張の舞台を整えるものです。
見逃せないのは、初期リリースが読み取り専用に絞られている点です。データの参照と分析はできますが、経費の承認や予約の実行はできません。そしてNavanは、この制限を終着点ではなく、取引機能へ進むための土台と位置づけています。
取引データの接続口を公式に開くという選択
MCPは、Anthropicが2024年11月に公開したオープン規格で、AIモデルと外部のデータソースやツールを標準化された方法でつなぎます。事業者がMCPサーバーを一つ用意すれば、対応するあらゆるAIアシスタントから接続できるため、AIツールごとに個別のAPI連携を作り込む必要がなくなります。その後OpenAIやMicrosoft、Googleといった主要AI企業も対応し、AIと外部システムをつなぐ事実上の標準になりました。仕組みの基礎はMCPの解説記事にまとめています。
Navanがこの規格の上に載せたのは、10年以上かけて蓄積した出張・経費データです。データの持ち主が公式の接続口を提供すれば、利用企業はWeb上の不確かな情報ではなく、契約先の一次データに基づく回答をAIから得られます。何を根拠にどう答えたかを追跡できるため、誤情報への対処も契約関係の中で完結します。
この構図は小売・ECの商品データへそのまま置き換えられます。商品、在庫、価格、注文、返品ポリシーといったデータを、AIが正確に読める形で保持しているか。公式の接続口がなければ、外部のAIツールはスクレイピングや推測という精度の低い手段でデータを取りに来ます。商品データの機械可読性を整え、正規の入り口を用意することが、エージェント経由の取引に備える最初の工程になります。
読み取り専用は入口、承認と予約への段階設計
今回の発表は、今後の拡張として立替経費の承認、出張ポリシーの更新、利用者が好みのインターフェース内で出張を予約できるエージェント統合を明記しています。閲覧と分析の先に、承認や予約という取引行為をAIツール上で完結させる段階が、最初から設計へ織り込まれているということです。
ただし、閲覧と取引では要求される仕組みが大きく異なります。誰が、どの範囲の操作を、どこまでの金額で委任したのかを検証できなければ、承認や予約は安心して任せられません。書き込み権限が開けば、プロンプトインジェクション（外部から紛れ込ませた指示でAIに不正な操作をさせる攻撃）や誤操作の影響が、高速かつ大規模に波及するリスクも生まれます。読み取り専用で運用を固めてから権限を広げるNavanの手順は、この非対称性を踏まえた設計だと言えます。
この線引きは、発見・分析と決済実行の分離という、エージェンティックコマース全体に共通する現在地とも重なります。現時点のNavan MCPは分析の道具であり、予約や決済を自律的に実行するエージェントではありません。何が提供済みで、何がまだ計画かを切り分けて読むことが、この種の発表を評価する基本になります。
Navan Anywhereが示す、自社画面の外で売る戦略
今回のMCPは単発の機能追加ではなく、「Navan Anywhere」と呼ぶ配布戦略の一部です。Navanは2026年6月9日、AI旅行エージェントをGoogleのGemini Enterpriseへ組み込むNavan Anywhereを発表し、従業員が普段の業務ツールを離れずに出張を計画・予約・管理できる体制の第一弾としました。画面を持たず、機能とデータをAPIで外部の画面に提供するヘッドレスアーキテクチャを採り、航空券・ホテルの在庫からポリシー制御、経費自動化までを外部プラットフォームへ埋め込む構想です。2026年内にはさらに対応先を広げる計画も示されています。
自社アプリへの集客を前提にしてきたSaaSが、ユーザーのいる場所へ機能を配る方向へ転じたと読めます。Investing.comの報道によれば、Navanの直近12カ月の売上高は7億6,500万ドル、時価総額は約62億ドルです。上場企業として成長を続けるうえで、自社サイトの外から取引を獲得するチャネルの開拓が戦略の柱になっています。
小売・ECにとって、これは自社ECサイトと外部AIチャネルの関係という論点そのものです。ChatGPTやGeminiの中で商品が発見され、取引が始まる流れが強まるほど、自社画面だけを前提にした販売設計では接点を失います。一方で外部チャネルへの依存には、手数料、顧客接点、データ所有という代償が付きます。開かれた庭と壁に囲まれた庭の使い分けという設計判断が、旅行でも物販でも同じ形で問われ始めています。
なぜ法人旅行から先に進むのか
Navanの動きは、旅行業界全体で進む接続口整備の流れの中にあります。GDS（航空券やホテルの在庫を旅行会社へ流通させる基幹システム）大手のSabreは2025年9月、AIエージェントからのリアルタイム検索・予約・購入後対応を想定したエージェント対応APIとMCPサーバーを発表しました。Kiwi.comも2025年8月にフライト検索のMCPサーバーを公開し、PhocusWireによればExpediaやTourRadar、ホテル管理システムのApaleoにも対応が広がっています。
法人旅行が先行しやすい理由を、業界メディアのBusiness Travel Newsはルールとプロセスで動く領域だからと説明しています。1件の予約は在庫、発券、決済承認、精算、旅程変更対応と、複数システムの処理を連鎖させます。ポリシーが明文化され、承認フローが構造化された取引は、人間の画面操作よりAIエージェントの直接接続に向いており、エージェント型の取引が最初に大規模化する業界の一つになるという専門家の見方も紹介されています。
同時に、冷静な評価も出ています。PhocusWireは、現段階のMCP経由の体験には既存の検索や自社アプリを上回る決定的な理由がまだ乏しく、最初の予約は信頼・決済・認証が確立済みの閉じた環境から始まるという見立てを伝えています。契約と認証を前提にする法人向けサービスは、まさにこの条件を満たします。小売・ECでも、会員制のサービスやB2B調達のように、ルールと認証が整った取引からエージェント化が進むと見るのが自然です。
まとめ
NavanのMCP公開は、出張・経費データの分析を会話型にするという利便性の話にとどまりません。取引データを持つ事業者が公式の接続口を開き、読み取りから承認・予約へと委任範囲を段階的に広げる、エージェント対応の進め方を示した事例です。旅行という題材で起きていますが、問われているのは業種を選ばない設計判断です。
順序は明快です。まず自社のデータをAIが読める形に整え、公式の接続口を用意する。閲覧系の機能で運用とガバナンスを固めてから、承認や購入という取引行為の委任へ進む。並行して、自社チャネルと外部AIチャネルの役割分担を決める。自社の画面の外で取引が始まる流れに対して、Navanが示したこの段階設計は、小売・EC事業者がそのまま下敷きにできる実装計画になります。
