画面には、すでにメッセージが表示されている。
台風接近に伴う旅程キャンセルの問い合わせに対して、AIエージェントが作成した返信文の下書き。顧客の予約情報、交通機関の運休状況、キャンセル料の免除条件──それらを突き合わせて生成されたテキストが、送信待ちの状態でオペレーターの画面に並んでいる。
オペレーターがやることは、その内容を確認し、「送信」ボタンを押すことだけだ。
一見すると、それは些細な作業に見える。AIがほとんどの仕事を終えたあとの、形式的な一手。だが、この構造にはもう少し複雑な意味がある。なぜ「送信」を自動化しなかったのか。なぜ最後の一手だけを、人間の手に残したのか。その問いに向き合うことが、この記事の出発点になる。
AIエージェントが「やっていること」と「やっていないこと」
2026年2月、日経クロステックが報じたJTBの事例は、経済産業省とNEDOが実施するGENIAC-PRIZEへの応募プロジェクトとして開発されたAIエージェントに関するものだ。台風や降雪などの荒天時に殺到する旅程キャンセルの問い合わせに対応するために設計されたこのシステムは、単なるチャットボットではない。複数の社内システムを横断的に操作し、既存の業務フローに沿ってキャンセル処理を進めるAIエージェントである。
構造を整理すると、このAIエージェントが扱う処理にはいくつかの層がある。
まず、LLM（大規模言語モデル）が担っている領域。顧客がコンタクトボード（JTBの会員向けWebサイトに設置されたサポート窓口）を通じて送ってきたメッセージの内容を読み解き、何を求めているのかを理解する。旅程の変更なのか、キャンセルなのか、払い戻しの確認なのか。自然言語で書かれた曖昧な要求を解釈し、適切な対応カテゴリに振り分ける作業は、LLMの得意領域だ。さらに、AIエージェントは顧客への返信メッセージの下書きを作成する。これもLLMの言語生成能力が活きる部分である。
次に、AIエージェントが行うシステム操作。報道によれば、このエージェントは3つの社内システムを操作・参照する仕組みを持つ。顧客に販売した旅行商品の情報を基幹系業務システムから取得し、交通機関のトラブル情報を参照し、キャンセル条件への該当性を判断する。ブラウザ自動操作の技術を用いて既存の業務システムのUIを直接操作するという構成は、既存システムにAPIが整備されていない現実への実践的な対応でもある。
そして、ここが構造上もっとも注目すべき点なのだが、鉄道の運行情報に基づく判定──すなわち「この路線は運休しているか」「この列車は欠航扱いか」といった判断は、LLMに任せずルールベースで処理されている。
この設計判断は、技術的な制約というよりも、意図的な選択として読むべきだろう。鉄道の運行ステータスは、曖昧さを許容しにくい領域だ。「運休」か「通常運行」か「遅延」かは、後続のキャンセル料免除判定に直結する。ここでLLMの確率的な推論を介在させると、判断の根拠が不透明になり、誤判定時の責任の所在も曖昧になる。だからこそ、この部分はルールベースに分離された。
「全部AIでやればいい」という発想が見落とすもの
荒天時のJTBでは、平常時の数十倍のキャンセル問い合わせが殺到するという。従来はそのすべてを人間のオペレーターが処理していた。交通機関のトラブル情報を確認し、旅行商品の契約条件と照合し、キャンセル料の免除可否を判断し、顧客への返信文を作成する。高いスキルと知識を持つオペレーターでも、この負荷はきつい。
その文脈で考えれば、「AIで全部自動化すればいい」という発想は自然に出てくる。メッセージの理解、情報の取得、条件の判定、返信文の作成、そして送信──一連の流れをすべてAIに任せれば、人的リソースの問題は解決するように見える。
だが、JTBはそうしなかった。
このシステムには、少なくとも3つの「AIに任せない」設計が組み込まれている。第一に、鉄道運行判定のルールベース分離。第二に、返信メッセージを「下書き」として生成し、完成品として直接送信しないこと。第三に、最終的な送信操作を人間のオペレーターが行うこと。
これらは「技術的にできなかった」のではない。JTBの開発担当者である合田航氏は以下のように述べている。
「AIで全てをきれいに解決する世界観を持たず、業務フローを丹念に分解して言語化しきることが最も重要だった」（合田氏）
JTBが旅程トラブル対応AIエージェント開発、業務システムを操作：日経クロステック
https://xtech.nikkei.com/atcl/nxt/column/18/03506/021200001/?n_cid=nbpnxt_mled_itmh
つまり技術的にはエンドツーエンドの自動化も視野に入りうる段階で、あえてそうしない選択がなされている。
ここにある設計思想を、単純な「慎重さ」や「段階的導入」として片付けるのは、構造の読みが浅い。もう少し踏み込むと、これは判断という行為を、どの主体に、どの粒度で、どの条件下で配置するかという設計の問題であることが見えてくる。
判断は一枚岩ではない
「AIが判断した」あるいは「人間が判断した」──私たちはしばしば、判断という行為を一枚岩のものとして語る。しかし、JTBの事例を構造的に見ると、一つのキャンセル対応の中に、性質の異なる複数の「判断」が折り重なっていることがわかる。
顧客のメッセージから意図を読み取る判断。これは文脈理解と分類の判断であり、多少の曖昧さを許容できる。LLMが得意とする領域だ。
鉄道が運休しているかどうかの判断。これは事実確認の判断であり、曖昧さを許容できない。ルールベースが適している。
キャンセル料が免除されるかどうかの判断。これは契約条件と事実の突き合わせであり、根拠の透明性が求められる。AIが処理を補助しつつも、その根拠が追跡可能でなければならない。
返信メッセージの内容が適切かどうかの判断。これは品質と正確性の最終確認であり、誤りがあった場合に顧客との関係に直接影響する。ここに人間のオペレーターが立つ。
そして、メッセージを送信するかどうかの判断。これは最終的な実行承認であり、取り消しが困難な行為の前に置かれるゲートである。
これらの判断は、それぞれ異なるリスクプロファイルを持ち、異なる処理主体に配置されるべきものだ。LLMが担うべきもの、ルールベースが担うべきもの、人間が担うべきもの。その振り分けは、技術の能力だけで決まるものではない。
判断の分解──タスクとしての分解ではなく、判断行為そのものの分解──が、このシステムの設計の核心にある。
「Human-in-the-Loop」は答えではない
AIシステムにおいて「最終判断は人間が行う」という設計パターンは、しばしばHuman-in-the-Loop（HITL）と呼ばれる。一見すると、JTBの事例もこのパターンに該当するように見える。
だが、HITLという概念には、構造的な曖昧さがある。「人間が最終確認する」と言ったとき、その人間は何を確認しているのか。何の権限を持っているのか。確認の結果として何を変更できるのか。そもそもAIの出力のどこに注意を払うべきかが明示されているのか。
多くのHITL設計では、人間はAIの出力を「承認するだけの存在」に形骸化する。AIが生成した結果を確認する時間的余裕がない、確認すべきポイントが明確でない、あるいは単純に「AIが言っているのだから正しいだろう」という認知的バイアスが働く。結果として、人間がループに入っているという形式は満たしているが、実質的な判断機能は果たしていない──そういう事態が起こりうる。
JTBの事例が注目に値するのは、単にHITLを採用したことではなく、人間が実質的に判断機能を発揮できるように、判断の前段階をAIとルールベースで構造化していることだ。オペレーターは、ゼロから情報を収集して判断する必要がない。AIが整理した情報と生成した下書きを、最終チェックとして確認する。その確認に集中できるように、それ以外の処理がシステムによって済まされている。
これは「人間を入れた」のではなく、「人間が機能する位置を設計した」という方が正確だろう。
「判断の配置」という問い
ここまで見てきたJTBの事例から浮かび上がるのは、AIの性能や導入の巧拙ではなく、もっと根本的な問いだ。
誰が、何を、どの条件下で判断するのか。
その判断の配置を、誰が決めているのか。
JTBの事例では、開発チームがこの配置を意図的に設計している。LLMにはメッセージ解釈と下書き生成を任せる。鉄道運行判定はルールベースに分離する。最終送信は人間が行う。この配置は、技術の性能から自動的に導かれたものではない。業務の性質、判断のリスクプロファイル、誤りが生じた場合の影響範囲──それらを勘案して、意図的に設計されたものだ。
この「判断の配置を設計する」という行為そのものに名前はあるだろうか。業務プロセスの設計とも違う。AI導入のフレームワークとも違う。ワークフロー自動化の話でもない。
判断という行為そのものを、設計の対象として扱うこと。どの判断をどの主体に配置し、判断と判断の間にどのような境界線を引くのか。その境界を明示し、意図的に管理すること。
それが Decision Design（判断の設計） である。
Decision Designは、判断という行為そのものを設計対象とする思想だ。
その中心にあるのがDecision Boundary（判断の境界） という概念である。誰が決めるのか。どこまでを任せ、どこからを引き受けるのか。その線を、無自覚のまま放置せず、意図的に設計すること。それがDecision Designである。
この記事の有料部分では、Decision Designの構造的な定義、それが何の問題に対する概念なのか、そしてJTBの事例をモデルにしたDecision Boundaryの具体的な実装案について論じる。
詳細版について
本稿は、公開範囲を基に構成したInsynergyの日本語サイト版です。詳細な議論と実装上の考察はnoteの詳細版で解説しています。