『BizTrip-Copilot（ビズトリップ・コパイロット）』自律性100%はなぜ危険か？「やっていいこと・ダメなこと」の境界線を引いた出張エージェント

Posted at 2026-09-22

「出張や学会に行くたびに、規程PDFと睨めっこして上限額を調べ、最安ルートを比較し、上司への申請メールを書く……」
そんな不毛な事務作業に、毎回数時間を溶かしていませんか？

「ChatGPTに聞けば一発では？」と思いきや、平気で架空のホテルや嘘の金額をでっち上げ（ハルシネーション）、かといって大手向けの出張管理システムは高すぎて手が出ない。そこで私たちは、「曖昧なルールの読解はAI（RAG）、絶対にミスれない計算は堅牢なプログラム」と徹底的に役割分担させた、出張計画特化の自律型エージェントを開発しました。

目指したのは、勝手に決済まで走ってしまう危険な100%自動化ではなく、規程違反を先回りして検知し、最後の送信ボタンだけは人間に委ねる「絶妙な距離感の相棒」です。1回の実行コストを数十円に抑え、中小企業や研究室でも明日から現場投入できるリアルなAIエージェントの設計思想をまとめました。

1. はじめに：なぜ、出張計画エージェントを作ったのか

ハッカソンのテーマである「業務を自立化するAIエージェント」。
私たちはこのテーマに対し、「出張計画作成に特化したエージェント」という答えを出しました。

きっかけは、私たちの身の回りにある「強烈なペイン（痛み）」でした。

学会出張に潜む「見えないコスト」

大学で研究活動をしていると、学会への参加やフィールドワークなど、出張の機会が多くあります。しかし、そこで毎回立ちはだかるのが「補助金申請のための書類準備と、事前調査の膨大な手間」です。

行き先も日程も毎回違うため、移動手段や宿の最安値をイチから調べ直す必要がある
社内（学内）の出張規程（上限金額や利用可能な交通機関のルール）を読み解きながらプランを組む必要がある
手作業でまとめるため、規程違反や計算ミスなどの「人為的ミス」が頻発する

研究や本来の業務に集中したいのに、この事務作業に数時間を奪われる。これが最初の出発点でした。

既存ツール（Concur Travel等）は「重すぎる」

もちろん、世の中には出張管理や経費精算を効率化する素晴らしいツールが存在します（Concur Travelなど）。しかし、市場調査を進める中でひとつの壁にぶつかりました。

「研究室や中小企業には、オーバースペックかつ高価すぎる」という点です。

既存のエンタープライズ向けシステムは、導入コストが高く、柔軟な設定変更が難しい場合があります。「もっと軽快に、チャットベースでサクッと規程に合ったプランを提案してほしいだけなのに……」という、無料のチャットAIと、数百万円のエンタープライズ版の間にある「空白の市場」が見えてきました。

目指した世界：「自律性100%」ではなく「絶妙な距離感の相棒」

今回のハッカソンで私たちが最も議論したのが、「自律性」の定義です。

AIがあらゆる手配から決済、申請までを勝手に終わらせてしまう「自律性100%」は、一見便利に見えます。しかし、金銭が絡む業務において、人間がプロセスをブラックボックス化されることは、セキュリティ・ガバナンスの観点から非常に危険です。

💡 私たちのエージェントのコンセプト
「人の仕事を完全に奪う（代替する）」のではなく、「人を的確にサポートする」こと。

面倒な規程の読み込みや最安値の検索、コンプライアンス違反の検知はAIが「自律的」に行う。しかし、最終的な承認ルートへの投入（メール送信など）は、人間が判断して実行する。

この「人とAIの絶妙な距離感」こそが、実際の業務に導入できる真の業務自立化エージェントだと考え、開発をスタートしました。

2. 『BizTrip-Copilot（ビズトリップ・コパイロット）』

ここで、まずは今回開発した出張計画エージェント『BizTrip-Copilot（ビズトリップ・コパイロット）』がどのように動くのか、全体のフローと5つのコア機能をご紹介します。

ユーザーがやることは、「どこへ、何のために、いつ行くのか」をチャットに入力するだけです。

2.1 必要なのは自然言語だけ。意図を汲み取る「入力・解析フェーズ」

ユーザーが「来週の金曜から2泊3日で、東京の〇〇学会に参加したい」と入力すると、システムが自動で「出張目的」「目的地」「行程日時」などの必須項目を抽出・解析します。

ただテキストを埋めるだけではありません。もし「帰りの日時」などの必要な条件が不足している場合は、AIが自律的に質問を返し、入力の漏れを未然に防ぎます。人間が入力フォームの項目を一つひとつ埋めるのではなく、AIが会話の中から必要な情報を組み立てていく設計です。

2.2 会社のルールを記憶する「RAGによる規程チェック」

ここが、一般的な検索AIとは異なる本システムの心臓部です。
システム内にはデータべース（Library機能）があり、自社の「出張旅費規程」などのPDFやテキストデータを事前にアップロードしておきます。

RAG（検索拡張生成）技術を用いることで、AIが「役職ごとの宿泊費上限額」や「新幹線指定席の利用ルール」などの細かな社内ルールを正確に読み取り、前提知識として保持した状態でユーザーのサポートにあたります。

2.3 費用と時間のタイパを測る「比較・最適化」

出張の意図を解析したAIは、交通機関や宿泊施設の情報を元に複数の出張プランを自動で組み立てます。

単に検索結果を並べるのではなく、「交通費と宿泊費の小計」や「往復の所要時間」をシステム側で自動計算します。価格の安さと、移動時間の短さ（タイムパフォーマンス）のバランスを評価し、最も効率的なプラン順にソートして提案します。

2.4 ルール違反を未然に防ぐ「合規性（コンプライアンス）自動判定」

提案される各プランには、2.2で読み込んだ社内規程と照らし合わせた「AI審査結果」が自動で付与されます。

たとえば、規程の宿泊費上限が8,000円のところ、10,000円の少しリッチなホテルが含まれるプランには、AIが自律的に「要承認」という警告ラベルを付けます。これにより、申請者と経理担当者の間で発生していた「規程違反による差し戻しラリー」を劇的に削減します。

2.5 最後の「めんどくさい」を消す、承認メール生成

最適なプランを選択し終わると、AIが社内規程と承認フローに則った「上司向けの申請メール」の下書きを自動生成します。

生成された文面は、ワンクリックで .eml ファイルとして書き出すことが可能です。ダウンロードしたファイルをダブルクリックすれば、普段お使いのメーラー（Outlookなど）が立ち上がり、宛先や件名、プラン内容が入力された状態でそのまま送信できます。

「調べる → 規程と見比べる → メールを書く」という数時間かかっていた作業が、わずか数分で完結する瞬間です。

3. なぜこの「業務自立型エージェント」が必要だったのか

今回のプロダクトを説明した際、必ずと言っていいほど聞かれる（あるいは思われる）疑問があります。

「出張の相談なら、ChatGPTにプロンプトを投げれば済むんじゃないの？」

たしかに、単なる「おすすめのホテル」や「一般的な観光ルート」を知りたいだけであれば、汎用のChatGPTで十分です。しかし、私たちが解決したい「業務としての出張手配」においては、ChatGPT単体では致命的な欠点が3つありました。

3.1 汎用LLM（ChatGPT単体）が抱える3つの限界

社内ルールの非認知： 汎用LLMは「自社（自学）の出張旅費規程」を知りません。役職ごとの宿泊費上限や、新幹線の指定席が使えるかどうかの判断ができません。
ハルシネーション（嘘の価格・経路）： LLMは文章を生成するのは得意ですが、正確な計算やリアルタイムの価格検索は苦手です。存在しない架空の安いホテルや、矛盾した移動時間をでっち上げるリスクがあります。
セキュリティと権限の境界がない： チャットAIは指示すれば何でも書いてしまいますが、業務において「やっていいこと」と「やってはいけないこと」の制御（ガバナンス）が効きません。

業務システムにおいて「もっともらしい嘘（ハルシネーション）」をつくAIは、かえって人間の確認コストを増やしてしまいます。だからこそ、ただのチャットUIではなく、「自律的に動きつつも、確実なロジックで制御されたAIエージェント」が必要でした。

比較項目	汎用 ChatGPT 単体	本業務自立型エージェント
社内ルールの理解	❌ 知らない（一般的な回答になる）	⭕ RAGにより「自社の出張旅費規程」を正確に参照
価格・費用の正確性	❌ ハルシネーション（嘘の価格）の恐れあり	⭕ 決定論的なプログラム（計算ロジック）で正確に算出
規程違反の検知	❌ ユーザーが自分で判断する必要がある	⭕ 予算超過や違反を自動検知し、赤字で警告
セキュリティ・制御	❌ 暴走や誤った処理を実行するリスクがある	⭕ 人間による最終確認（承認メールの送信など）を必須化

3.2 読解（AI）と計算（システム）を分ける【③ 信頼性・堅牢性】

私たちがこだわったのは、AIに「すべてを任せない」というアーキテクチャです。

ユーザーの意図を汲み取ったり、RAG（検索拡張生成）を使って規程PDFの文章を読み解いたりする「曖昧な情報の処理」はLLM（AI）に任せます。
一方で、交通費と宿泊費の合算や、時間の比較ソートといった「絶対間違えてはいけない処理」は、会社自身のプログラム（計算ロジック）に任せています。

「読解・判定」と「計算」を明確に分離することで、AIの柔軟性を活かしつつ、業務システムとして絶対に外せない信頼性と堅牢性を担保しています。

4. システムの全体像（アーキテクチャとデータ構造）

第3章でお伝えした「読解（AI）と計算（プログラム）の分離」や「セキュリティの担保」を、実際のシステムとしてどのように実装したのか。全体のアーキテクチャとデータ構造を解説します。

4.1 全体の処理フロー（流れ図）

本エージェントの処理は、大きく5つのフェーズに分かれています。AIが自律的に動く部分と、システムがカッチリと計算・制御する部分をパイプラインとして繋いでいます。

入力・意図抽出（LLM）： ユーザーの自然言語チャットから「目的地・日程・目的」をJSON形式で抽出。不足があればユーザーへ再質問。
規程検索（RAG / Vector DB）： 抽出した条件とユーザーの役職データを元に、ベクトル化された「社内規程（Library）」から該当するルール（上限金額や利用可能座席など）を検索・取得。
プラン構築・計算（ロジック）： 交通機関や宿泊施設のデータから候補を取得し、「交通費＋宿泊費の小計」と「往復の所要時間」をプログラム側で正確に計算。
合規性判定（LLM ＋ロジック）： Step3で出た結果とStep2の規程を照らし合わせ、上限超過やルール違反がないかを判定。違反があれば「要承認」フラグを立てる。
出力・生成（LLM ＋ロジック）： ユーザーが選んだプランを元に承認メールの文章を生成し、.eml ファイルとして出力。

4.2 データ構造とER図

エージェントが自律的に正しい判断を下すためには、シンプルかつ拡張性の高いデータ構造が必要です。本システムでは、「ナレッジ」「申請コンテキスト」「計算・見積り明細」「承認ガバナンス」の4つのドメインを明確に分離したリレーショナル設計を採用しています。主要なテーブルとリレーション（ER）は以下のように設計しました。

主要なデータドメインとエンティティの責務

ナレッジ・規程ドメイン（PROJECTS, DOCUMENTS, DOCUMENT_CHUNKS）
社内規程のPDF等をチャンク（分割）し、ベクトルデータとして格納します。規程が改訂された際もシステム改修は不要で、最新のファイルをアップロードするだけでRAGが新しいルールを読み取る構造です。
申請・コンテキストドメイン（USERS, TRIP_REQUESTS）
AIがユーザーのチャットから抽出した「いつ・どこへ・何のために」という出張要件を保存します。また、USERSに「役職（Role）」を持たせることで、AIが「部長は宿泊費10,000円まで、一般社員は8,000円まで」といった規程の分岐を正確に処理できるようにしています。
計算・見積り明細ドメイン（TRAVEL_PLANS, PLAN_LEGS, PLAN_COSTS）
AIに直接計算させると「架空の安いホテル」などをでっち上げる（ハルシネーション）リスクがあるため、移動経路（PLAN_LEGS）や費用明細（PLAN_COSTS）はプログラム側で決定論的に算出し、プラン集約テーブル（TRAVEL_PLANS）へ正規化して保存しています。ここにAIの審査結果である「合規性ステータス」を持たせます。
承認・ガバナンスドメイン（APPROVAL_DRAFTS）
AIが勝手に経理へ決済データを送ることを防ぐため、最終的に採択されたプランに基づく承認メールの下書き（.eml）として情報を管理します。「Human-in-the-Loop（人間の介在）」をデータ構造のレベルで強制する役割を持ちます。

💡 設計上の工夫：冗長なリレーションの排除による堅牢性の向上
業務システムとしての堅牢性を高めるため、データの不整合を防ぐ厳密な正規化にこだわりました。

当初の構想では「承認メール（APPROVAL_DRAFTS）」に対して、「出張リクエスト（TRIP_REQUESTS）」からも直接紐付けを行う設計を考えていました。しかし、「採用されたプラン（plan_id）が決まれば、大元の出張申請（trip_id）は自ずと特定できる」という関係性（推移的従属）に基づき、大元から直接引っ張る冗長なリレーションを設計から排除しました。

これにより、「プランA（東京出張）に紐づく承認メールなのに、誤って大阪出張のデータが混ざってしまう」といった更新時異常を構造レベルで防いでいます。ただAIを繋ぎ合わせただけでなく、バックエンドのRDB設計を手を抜かずに作り込んだことが、本システムの信頼性を支えています。

4.3 独自の計算方式と最適化（タイパの考慮）

また、私たちは単に「安い順」に並べるのではなく、「価格と時間のバランス（タイムパフォーマンス）」を計算方式に組み込みました。

システム内部では、以下のような計算とソートを行っています。

総費用の計算： (往路交通費＋復路交通費) ＋ (宿泊費 × 泊数) を絶対的な数値として算出。
所要時間の計算： 出発から到着までのトータル移動時間を分単位で算出。
最適ソートアルゴリズム： 「費用が安く、かつ移動時間が短いもの」をスコアリングし、最優排序（ベストバランス順）でユーザーに提示します。

「LCC（格安航空）を使えば安いが、空港までの移動と待ち時間で半日潰れてしまう」といった、ビジネスにおいて実用的ではないプランをAIが自律的に下位へ落とす仕組みです。

これにより、ユーザーは「会社のお財布」と「自分の体力・時間」の両方に優しいプランを瞬時に選ぶことができます。

5. 社内規程を外さない「信頼性・堅牢性」

出張計画という「お金」が絡む業務において、AIのハルシネーション（もっともらしい嘘）は致命傷になります。
たとえば、「部長の宿泊費上限は本当は10,000円なのに、AIが勝手に『15,000円までOKです』と嘘をついてしまう」といった事態は絶対に防がなければなりません。

ここでは、信頼性と堅牢性を担保するために、私たちが実装した2つの工夫を紹介します。

5.1 検索（RAG）に「答えを勝手に選ばせない」プロンプト設計

一般的なAIチャットに「このホテルは会社の規程に合っていますか？」と漠然と聞くと、AIは自身の学習データから「一般的なビジネスホテルの相場」を元に適当な回答を作ってしまうリスクがあります。

そこで本システムでは、AIに勝手に判断させるのではなく、「抽出」と「判定」を厳格に分けるプロンプト設計を行いました。

具体的には、RAG（検索拡張生成）のプロセスで以下の制約をかけています。

ルールの特定： まずVector DBからユーザーの役職に応じた「規程の該当部分（例：第5条宿泊費）」だけを正確に引っ張ってくる。
厳格な判定指示： その抽出したテキストだけをコンテキストとして渡し、「提供されたテキストのみを基準にして判定せよ。外部の知識は一切使ってはならない」と強力なガードレール（システムプロンプト）を敷く。

💡 実際のシステムプロンプトのイメージ
あなたは厳格な経理担当者です。以下の【社内規程】のみに基づき、【提案プラン】が合規か違反かを判定してください。上限を1円でも超える場合は必ず「要承認」フラグをTrueにしてください。

このように「AIの想像力」を意図的に縛ることで、常に社内規程という絶対的な正解から外れない、極めて堅牢な判定システムを実現しました。

5.2 規程のバージョン変更に強い「ルールとモデルの分離」

企業の出張規程は、「消費税の増税」や「物価高騰による宿泊費上限の引き上げ」などで定期的にアップデートされます。
もし、判定ルールをプログラムのソースコード内に直接書き込んだり（ハードコーディング）、LLMのプロンプト内にベタ書きしたりしていると、規程が変わるたびにシステムの改修工事が必要になってしまいます。

私たちのエージェントは、「AIモデル・計算ロジック」と「社内規程のデータ（Library）」を完全に分離した構造にしています。

ルールが変わった時： 新しい規程のPDFやテキストファイルをシステムにアップロード（上書き）するだけ。
システム側： コードもプロンプトも一切変更不要。次回の実行時から、AIは自動的に新しいルールのPDFを読みに行って判定を行います。

「使われるたびに確かめられる範囲が広がり、モデルが変わってもルールは変わらない。」
この拡張性の高さこそが、私たちが目指した業務エージェントの姿です。

6. AIの暴走を防ぐ「セキュリティ」設計

「業務を自立化するAI」を作る上で、最も恐れなければならないのはAIの暴走です。
経費や出張手配といった「お金」と「社内ガバナンス」が絡む領域において、AIが勝手に航空券を予約したり、上司へ不適切なメールを誤送信したりすることは、企業にとって致命的なインシデントになり得ます。

本エージェントでは、 セキュリティを最重要課題と捉え、「アクセスできデータ・できないデータ」の明確な境界線をシステムレベルで定義しました。

6.1 アクセスできる・できないデータの厳格な切り分け

AIが不用意に機密情報へアクセスして情報漏洩を起こさないよう、データアクセスの範囲（スコープ）を厳格に切り分けています。

アクセスできるデータ（許可）： ユーザーが入力した「出張の希望条件」、およびLibraryにアップロードされた「出張旅費規程（PDF/Text）」のみ。
アクセスできないデータ（遮断）： 企業の基幹人事システム、全社員の給与データ、社内ネットワーク上の非公開ファイルなど。

AIはあくまで独立した「検索・判定エンジン（RAG）」というサンドボックス（隔離された環境）内で動作するため、システムがハッキングされたりAIが予期せぬ挙動をしたりしても、会社のコアデータが脅かされることはありません。

6.2 AIの「やっていいこと・ダメなこと」の境界線

チームのディスカッションで徹底的に話し合ったのが、「どこまでをAIに任せるか」というラインです。本システムでは、AIの役割を以下のように明確に制限しました。

🟢 AIが「やっていいこと」（自律性の発揮）
- ユーザーの意図を汲み取り、条件に合う移動手段や宿を検索・提案すること。
- 社内規程（Library）を参照し、ユーザーの希望プランが「合規か・違反か」を自律的に判定して警告を出すこと。
- 承認用メールの「下書き（文章）」を作成すること。
🔴 AIが「やってはいけないこと」（自律性の制限）
- ユーザーの確認を待たずに、勝手にホテルや新幹線の決済を行うこと。
- 上司や経理部門に対して、AI自身が直接メールを送信すること。
- 「要承認」の警告を、AIの判断で勝手に取り消すこと。

6.3 すべてを自律任せにしない「人間の承認フロー（.eml生成）」

このセキュリティ設計を象徴する機能が、第2章で紹介した「承認メール（.emlファイル）の出力」です。

技術的には、AIから上司のアドレスへ直接API経由でメールを飛ばすことは簡単に実装できます。しかし、私たちはあえてそれをしませんでした。

AIが作成したプランとメール文面は、一度 .eml 形式でユーザーの手元にダウンロードされます。ユーザー自身がローカルのメーラー（Outlook等）でファイルを開き、自分の目で内容を確認し、自分の手で「送信ボタン」を押す。

この「Human-in-the-Loop（人間の介在）」というワンクッションを最終工程に挟むことで、最終的な責任（アカウンタビリティ）の所在を人間に残しています。
「100%の自律化」という幻想を追い求めるのではなく、99%の面倒な作業をAIが引き受け、最後の1%の決断を人間が行う。これこそが、実際の企業が安心して導入できる現実的かつ安全なAIエージェントの姿です。

7. 中小企業に寄り添う「コストパフォーマンス」

第1章でも触れた通り、既存の出張管理システム（SAP Concurなど）は非常に高機能ですが、数百万円の導入費用や高い月額費用がかかるため、中小企業や大学の研究室には手が届きません。

私たちがターゲットにする「中小規模の組織」が無理なく導入・継続できるよう、コストパフォーマンスに対して、システム実行コストと運用コストの最適化を行いました。

7.1 AIを「呼ばないで済む箇所は呼ばない」設計

LLM（大規模言語モデル）のAPIは、入力・出力される「文字数（トークン数）」に応じて課金されます。つまり、AIに何でもかんでも処理させると、使えば使うほど赤字になるシステムになってしまいます。

そこで私たちは、第3章で解説した「読解（AI）と計算（プログラム）の分離」を、コスト削減の最大の武器として活用しました。

AI（有料API）を使う部分： ユーザーの意図抽出、社内規程の判定、メール文章の生成のみ。
プログラム（安価・無料API）を使う部分： 交通ルートの検索、宿泊施設の価格取得、費用と時間の合算ソート。

複雑な計算や検索処理をすべて標準的なWeb APIとロジックに逃がすことで、LLMへ投げるプロンプトを極限までシェイプアップし、1回のプラン提案あたりのLLM呼び出しコスト（原価）を数円〜十数円単位まで圧縮することに成功しました。

7.2 RAGによる「つまみ食い」でコンテキスト長を節約

社内規程をAIに読み込ませる際、何十ページもあるPDFを毎回そのままLLMのプロンプトに突っ込んでいては、莫大なトークン費用が発生します。

本システムでは、RAG（検索拡張生成）技術とVector DB（ベクトルデータベース）を活用し、「ユーザーの役職と目的地に関連するルールの数行（チャンク）」だけをピンポイントで抽出してからLLMに渡しています。
ルールブック全体を読ませるのではなく、必要な箇所だけを「つまみ食い」させることで、精度の向上と圧倒的なコストダウンを両立させました。

7.3 運用保守という「見えないコスト」の削減

導入費用やAPIの通信費だけでなく、「運用にかかる人件費」も大きなコストです。

第5章で述べた通り、本システムは「ルールとモデルが分離」されています。
もし来月から「宿泊費の上限が1,000円アップ」したとしても、外部のシステム開発会社に改修を依頼する必要は一切ありません。 総務の担当者が、新しいルールのPDFを管理画面（Library）からアップロードするだけで、即座にAIの判定基準がアップデートされます。

💡 コストパフォーマンスの総括
「インフラ通信費（原価）」と「運用保守費（人件費）」の両方を極小化するアーキテクチャ。これにより、大企業の専用システムに劣らない高度な自律エージェントを、中小企業でも導入できる価格帯で提供可能にしました。

8. できないこと・検証したこと

どんなに優れたAIであっても、現時点ですべての業務を完璧にこなせるわけではありません。本ハッカソン期間中の検証を通じて明確になった「本システムでは処理しきれない例外ケース（限界）」と、今後の課題について共有します。

8.1 できないこと①：ビザや為替が絡む「特殊な海外出張」

現状のシステムは、国内出張や定型的な手配においては極めて高い精度を発揮します。しかし、「複数国を跨ぐトランジット」「リアルタイムの為替変動を伴う経費計算」「渡航ビザの要件確認」といった特殊な海外出張については、あえてスコープから外しています。

為替レートや各国の安全情報（渡航制限など）は日々激しく変動するため、静的な規程データ（RAG）だけを頼りにAIに判断させると、ハルシネーションや重大なコンプライアンス違反を引き起こすリスクがあるためです。海外出張への対応は、外部のリアルタイム為替APIや渡航情報APIとの連携が必要な「今後の拡張課題」としています。

8.2 できないこと②：出張中の「突発的な旅程変更」への追従

「台風で新幹線が計画運休になった」「現地での商談が延びて、急遽もう1泊することになった」といった、リアルタイム・事後的なトラブル対応も現在のAIにはできません。

本エージェントはあくまで「事前の出張計画と申請（Email生成）」に特化して自律性を発揮する設計です。承認が下りた後の動的なリカバリーについては、現時点では人間が手動で対応し、帰社後に事後精算を行う従来のフローに依存しています。

8.3 検証したこと：AIの「わからない」を引き出す

開発中のテストでは、意図的に「情報が全く足りないプロンプト（例：来週どこかに行きたい）」や「絶対に規程違反になるホテル指定」を入力する検証を繰り返しました。

結果として、システムは無理に嘘のプランをでっち上げることはせず、「目的と日時を教えてください」と自律的に聞き返したり、確実に「要承認」の警告を出したりすることを確認できました。
「できないこと」の境界線をシステムに明確に認識させたからこそ、コア機能の堅牢性が劇的に高まったと言えます。

9. まとめ：AIがもたらす「ハッピー」なワークスタイル

今回開発した「出張計画エージェント」によって、誰がどんなハッピーを得られるのか。
それは単なる「作業時間の短縮」だけではありません。

申請者（社員）： 毎回イチから最安値を探し、規程集と睨めっこしながら申請メールを書く数時間の苦痛から解放され、本来の研究やビジネスに集中できる。
承認者（上司・経理）： ルール違反のプランを弾く「差し戻しラリー」がなくなり、AIが一次審査を終えたクリーンな状態の申請だけを承認できる。

私たちが目指したのは、AIが人間の仕事を完全に奪い取るディストピアではなく、「面倒なこと・間違えやすいこと」はAIが自律的に片付け、最終的な「決断と責任」は人間が持つという、人とAIが共存する未来のワークスタイルです。

「AIエージェント」というバズワードに振り回されず、セキュリティ、コスト、堅牢性という地に足のついた評価基準と向き合ったことで、中小企業でも本当に使える実用的なプロダクトの片鱗を作ることができました。

このハッカソンでの経験を糧に、今後も「人を的確にサポートする」次世代のエージェント開発を続けていきたいと思います。最後までお読みいただき、ありがとうございました！