予約エージェントのためのEval：不正なスケジュールを防ぐテストスイート

予約エージェントのためのEval（評価）は、綺麗な案件を1回予約できるだけのデモと、実際の現場の配車業務を耐え抜くエージェントの違いを生む存在です。フィールドオペレーションにおいて、言語モデルに丁寧な応答をさせることは難しくありません。本当に難しいのは、案件の詳細情報の収集、適切なツールの使用、承認ステップの遵守、不適切なスケジュールの防止、問題が発生した際の説明など、同じワークフローを安定して実行できると証明することです。役に立つテストスイートは、予約エージェントを商用ソフトウェアとして扱います。つまり、入力、ツール、状態、失敗モード、アサーション、そしてレビュー可能なトレースを備えている必要があります。

この記事は、小規模事業者チーム向けのスケジューリングおよび配車フローを構築する開発者に向けて書かれています。特定のコードベースではなく、システム全体の構造を示すため、例はアーキテクチャのレベルにとどめています。AIエージェントツールの設計、エージェントによるスケジューリング挙動、ポイントを押さえたEval設計のチェックリストとしてご活用ください。

アーキテクチャ：エージェント、ツール、承認

予約エージェントには、検査しやすいシンプルなアーキテクチャが必要です。エージェントを中央に配置しますが、すべての決定権を持たせるわけではありません。その周辺に、空き枠検索、顧客ヒアリング、作業員のマッチング、ルートチェック、予約仮押さえ、確定といったツール呼び出しを定義します。また、承認ルールを明確にしておきます。そのまま直接予約できるリクエストもあれば、仮押さえを作成すべきものや、ディスパッチャー（配車担当者）やオフィス管理者による判断を必要とするものもあります。

このアーキテクチャでは、「会話」と「アクション」の違いも明確にする必要があります。会話は意図を収集し、ツールは状態を変更し、承認は提案された変更が許容できるかを決定します。これらの役割が曖昧になると、システムが理解に失敗したのか、ツールの選択に失敗したのか、それともポリシーの適用に失敗したのかを特定できず、Evalの判定も曖昧になります。

相互運用性を確保するため、ツール層はModel Context Protocolサーバーや同様の内部APIのパターンに従うことができます。エージェントが特定のプロダクトランタイムを使用している場合は、Claudeドキュメントなどのベンダー仕様書に記載されているツール契約の形状に合わせて構成してください。重要なのはスタックのブランドではなく、すべてのファンクションコーリングによるスケジューリングのアクションが、予測可能な入力、予測可能な出力、そしてEvalが検査できるトレースを持っていることです。

スケジューリングツールの定義

安全に予約を完了できる最小限のツールセットから始めましょう。一般的なセットには、顧客検索、サービス種別の分類、予約可能枠の検索、作業員要件チェック、移動可能性チェック、予約仮押さえ、予約確定、そしてキャンセル・解放が含まれます。各ツールには単一の限定された役割を持たせるべきです。1つのツールで空き枠の検索と実際の予約の両方を行ってしまうと、エージェントが一時停止したり、選択肢を比較したり、承認を求めたりする機会が減ってしまいます。

優れたAIエージェントのツールAPI設計により、テストスイートは具体的なアサーション（検証）を行えるようになります。テストでは、予約エージェントが確定の前に空き枠の確認を呼び出したか、正しいサービス種別を渡したか、利用不可の時間を避けたか、処理がブロックされた際に仮押さえを解放したかなどを検証できます。これは、最終的なメッセージ文章だけで良し悪しを判断するよりもはるかに強固です。

ノーコードやワークフローベースのシステムでも、同じ原則が適用されます。予約フローがn8nドキュメントのパターンで構成されている場合は、業務全体を1つの自動化の中に隠すのではなく、各ワークフローのステップを観測可能にしてください。Evalは、親切な返答メッセージから推測するのではなく、ツールの実行結果を直接読み取れる必要があります。

ここでも、設計の参考としてMCPサーバーの例が役立ちます。スケジューリングサーバーは、内部データベースのすべてのフィールドを公開する必要はありません。エージェントが安全に実行できる操作のみを公開し、無効な呼び出しが発生した際には即座にエラーとなるような十分なスキーマ詳細を提供します。これにより、予約エージェント用ソフトウェアのEvalは、感覚的な判定ではなく明確な契約に基づいた検証になります。

状態、メモリ、コンテキスト

予約はステートフル（状態保持）な処理です。顧客が名前を伝え、希望日時を変更し、ゲートの暗証番号に言及し、さらに同じ作業員が再訪問できるかを質問してくることがあります。エージェントには、記憶したすべての発言を予約の許可とみなすことなく、こうしたコンテキストを整理して保持できるだけのメモリが必要です。セッションコンテキスト、顧客履歴、保留中の仮押さえ、永続的な案件記録はそれぞれ分離して管理してください。

Evalスイートには、同じ会話の中で方向性が変化するようなテストケースを含めるべきです。例えば、午後の希望から始まり、午前に変更され、最終的に最も早い利用可能な枠を要求するケース。過去のアドレスを再利用しつつサービス種別を変更するケース。また、不完全な情報入力に対して、予約ツールを呼び出す前に不足している情報を質問するケースなどです。

これらのテストは、小規模事業者チーム向けの予約エージェント向けEvalにおいて特に重要です。オフィスのスタッフは、顧客情報が不完全な状態で作業を開始することが多いからです。エージェントは早期に拒絶することで現実の運用を損なうべきではありませんが、不足している情報を勝手に創作してもいけません。有益な振る舞いとは、判明している情報を保持し、不足している情報を明確にし、入力が揃った段階でのみツールを使用することです。

状態の管理はコストにも影響します。個々のテストが単一の振る舞いに焦点を当て、顧客、作業員、サービスエリアのフィクスチャ（テストデータ）を再利用すると、予約エージェント向けEvalの実行コストを抑えられます。最もコストがかかるのは、すべてを一度に検証しようとして、どの振る舞いが退化したのかすら特定できない巨大なプロンプトです。

ガードレールと障害モード

ガードレールは一般的な注意事項ではなく、配車ルールとして記述する必要があります。予約エージェントには、二重予約の回避、必要なスキル条件の遵守、対応外のサービスエリアの回避、承認が必要な場合の確定ではなく仮押さえの実行、ツールの結果が不完全な場合の不確実性の開示などを指示します。それぞれのルールを少なくとも1つのEvalに対応付けます。

障害モードのテストスイートは、意図的に厳しい条件で構成すべきです。利用不可能な時間帯、作業員の制約の競合、住所の欠落、曖昧なサービス内容の説明、重複する顧客レコード、ツールのタイムアウト、期限切れの仮押さえ、ポリシー外の要求を行う顧客などをテストします。優れた予約エージェント向けEvalには正常系（ハッピーパス）も含まれますが、その本当の価値は、実際のオフィスで毎週のように発生する扱いづらいイレギュラーなケースで発揮されます。

エージェントによるスケジューリングにおいて有用なパターンの1つは、確定を行う前に計画を検証することです。エージェントはスロットを提案し、使用した制約理由を説明し、必要に応じて承認を待ちます。そしてEvalは、システムがフライングで確定を行わなかったことをアサートします。これにより、最終メッセージの見た目が整っているかをチェックするだけでは見逃してしまう種類のバグを検出できます。

競合のキーワードや代替アプローチと比較検討する際は、現実的な視点を保ちましょう。シンプルな案件であれば、確定的（デターミニスティック）な予約フォームの方がエージェントよりも安全です。予約エージェントが真価を発揮するのは、会話の中にトレードオフ、例外処理、静的なフォームでは対応しきれない文脈が含まれる場合です。ガードレールは、エージェントに不当な権限を与えて創作させることなく、そうした柔軟性を維持するためのものです。

エージェントの挙動の評価

評価は、決定論的な検証と人間の目による評価を組み合わせて行う必要があります。決定論的な検証では、ツールの呼び出し順序、必須項目、ブロックされたアクション、漏れている承認、最終状態などをカバーします。人間の目による評価では、エージェントが次のステップを分かりやすく説明できているか、過度に断定的な表現をしていないかをカバーします。これら2つを1つの曖昧なスコアに混ぜ合わせるべきではありません。

予約エージェント向けEvalを改善するための第一歩は、テスト対象の振る舞いに具体的な名前を付けることです。「適切な予約を作成する」といった抽象的な表現ではなく、「空き枠検索の前に不足している住所を質問する」、「作業員のスキルが不足している場合は確定しない」、「顧客が提案枠を拒否した後に仮押さえを解放する」といったテストケースを作成します。これらの名前がそのまま回帰テストのレポートになります。

LLMのファンクションコーリングに対するテストも含めてください。エージェントは誤ったツールを呼び出しているにもかかわらず、応答文面だけは正しそうに見せかけることができるからです。Evalは関数名、引数、結果の処理、判明した最終メッセージを検査する必要があります。ツールが適任の作業員なしと返した場合は、それを予約確定に変換してはいけません。ツールが2つの時間枠を返した場合は、想定されるポリシー順序に従って選択肢を提示する必要があります。

予約エージェント向けEvalの例は、コンパクトな会話フィクスチャとして保存できます（初期のユーザーメッセージ、ツールのモック、期待される呼び出し、期待される最終状態、簡潔な根拠）。ディスパッチャー、サポートリード、開発者が一緒に確認できる程度に可読性を保ってください。目標は誰にも信頼されない独自のベンチマークではなく、チーム全体での安心感です。

パターンの拡張

予約用スイートが安定したら、1つの巨大なテストを作るのではなく、横方向に拡張します。新しいサービスライン、時間外の対応、スケジュール変更、キャンセル、承認、引き継ぎなどを追加します。異なる拠点、クルー（作業チーム）、顧客履歴のテストデータを投入します。障害が発生した際に具体的な修正箇所が特定できるよう、各Evalは十分に小さな単位に保ちます。

このパターンを、案件、作業員、時間枠、制約条件、承認など、エージェントに公開するプラットフォーム固有のオブジェクトに関連付けるには、CrisphiveドキュメントにあるCrisphive自体のドキュメントを参照するのが最適です。技術スタックが変わっても原則は同じです。エージェントは会話的であって構いませんが、Evalは質素で明確、かつ再現可能でなければなりません。

予約エージェント向けEval 2026において、新奇性だけを無意味に追い求めるべきではありません。本質的な価値を持つ仕事とは、今も昔もツールの契約、状態の境界設定、ガードレール、そして失敗のレビューです。テストスイートが顧客の目に触れる前に不正なスケジュールを捉えられるなら、それは役割を果たしています。エージェントが自信満々に回答を作成できることを証明するだけなら、テストする対象を間違えています。

次にとるべき最善のステップは、1つの予約ジャーニーを選択し、5つのテストケースを作成することです（正常な予約、詳細情報が不足しているケース、空き枠がないケース、承認が必要なケース、ツール障害のケース）。プロンプト、ツールスキーマ、ワークフロー、またはポリシーが変更されるたびに、それらを実行してください。これによって、予約エージェント向けEvalのノウハウが単なる一度きりのローンチ時チェックリストではなく、日々の運用習慣へと変わっていきます。