はじめに
こんにちは、チームGGGの代表はまぐちです。
2名チームで参加してます。
本件は、AI HACK2026の参加のため、記事を作成しております。内容は皆さまがイメージできるように出来る限り詳しく書いております。
早速ですが、皆さまはこのようなことを言われたことないですか
「次の飲み会、幹事お願い」
宴会や会食の幹事を経験したことがある人なら、この一言のあとに意外と多くの作業が待っていることを知っていると思います。
お店を探すだけなら、すでに便利なサービスはたくさんあります。
しかし実際には、
- 参加人数を確認する
- 予算を合わせる
- 個室が必要か考える
- 条件に合う店舗を比較する
- 食事への配慮を確認する
- 参加者へ候補を共有する
- 出欠を集める
- 予約前の確認事項を整理する
- 決定内容を共有する
- カレンダーへ予定をまとめる
といった作業が続きます。
さらに、
「人数が増えた」
「予算を少し変えたい」
「やっぱり個室を優先したい」
となれば、候補をもう一度見直す必要があります。
そこで開発したのが、宴会・会食の幹事業務を一つの流れにつなぐ ENCOPA（エンコパ） です。
ENCOPAが目指しているのは、
「おすすめのお店を答えるAI」ではなく、
「宴会を開催できる状態まで、幹事の仕事を前へ進めるAI」
です。
AI HACKをきっかけに考えたこと
ENCOPAは、AIプロダクト開発をテーマとする AI HACK をきっかけに開発しました。
今回特に意識したのは、単にLLMをAPIから呼び出すだけでは、実際のプロダクトとしては不十分だということです。
AIを業務の中へ入れるなら、
AIは何を判断するのか
どこまで自律してよいのか
失敗したときどうするのか
何回まで推論させるのか
どんな情報を渡すのか
どこから人間が判断するのか
まで決める必要があります。
ENCOPAでは、Agentic AIを設計するうえで特に、
- セキュリティ
- コストパフォーマンス
- 信頼性・堅牢性
- 自律性
- アイデア・独創性
を意識しました。
この5つを別々の機能として追加するのではなく、一つのAgentic AIを成立させるための設計条件として考えています。
ENCOPAで解決したかったこと
従来の幹事業務は、だいたい次のように分散しています。
グルメサイトで店を探す
↓
条件に合うか一軒ずつ確認
↓
候補を共有
↓
出欠を確認
↓
食事への配慮を確認
↓
条件変更があれば再検討
↓
決定内容を共有
↓
予定をまとめる
大変なのは「店を検索すること」だけではありません。
検索結果を見たあとに、
- この店で人数は大丈夫か
- 予算には合うか
- 個室条件をどう考えるか
- 情報が不足していないか
- 店舗へ何を確認するべきか
- 次に参加者へ何を伝えるべきか
を考え続ける必要があります。
ENCOPAでは、この部分を一つのワークフローとして扱います。
条件入力
↓
実在店舗検索
↓
条件評価
↓
AIによる候補比較
↓
予約前の確認事項整理
↓
参加者へ共有
↓
出欠・食事配慮を確認
↓
幹事が内容を確認
↓
予定化
つまり、
検索結果を出すことではなく、検索結果を「意思決定できる状態」に変えること
を中心にしました。
現在実装している機能
現在のENCOPAでは、次の機能を実装しています。
- 全国47都道府県を対象とした店舗検索
- 人数・予算・目的・個室などの条件設定
- ホットペッパー グルメWebサービスからの実在店舗取得
- 条件一致・予算・利便性などを使った候補評価
- OrcaRouterを利用した店舗候補分析
- Coordinatorによる `FINALIZE` / `RUN_SPECIALISTS` の動的選択
- Policy GateによるAction実行前の権限・上限制御
- Tool Registryを介した専門Agentの実行
- Observationを受けたCoordinatorの再判断
- 最大2つのSpecialistを使う詳細分析
- Agent出力の機械的な自己検証
- 必要な場合のみ最大1回の自己修正
- 最大4ステップ・最大5 LLM callsの実行制限
- 処理経路と使用量を確認できるAction Trace
- 人間の承認が必要な操作の明示
- 店舗住所・アクセス情報の表示
- Googleマップ / Appleマップへの導線
- 招待リンクを使ったグループ作成
- 参加者自身による出欠回答
- アレルギー情報の登録
- アレルギー情報の閲覧権限制御
- グループ内メッセージ
- 予約内容の共有
- 参加者向け文面の作成・コピー
- ICS形式のカレンダーファイル生成
一方、現在のENCOPAでは次の操作は行っていません。
- リアルタイム空席照会
- 店舗への自動予約
- 自動キャンセル
- メールやLINEへの自動通知
- Agentによる外部サービスへの不可逆な操作
予約そのものをAIに任せるのではなく、
AIは情報整理と判断支援を行い、重要な操作は人間に残す
構成です。
「AI付き店舗検索」との違い
店舗候補をLLMへ渡して、
「この中ならどのお店がおすすめ？」
と聞くだけでもAIでプランは作れます。
ただ、アプリの横断や連絡などは人間側でしないといけなくなってしまいます。
ENCOPAでやりたかったのは、
質問
↓
回答
だけではありません。
現在の状態を確認
↓
必要な処理を判断
↓
処理を実行
↓
必要なら追加分析
↓
結果を検証
↓
必要なら1回だけ修正
↓
次にやることを整理
↓
必要なら人間へ戻す
という流れです。
そのため、単一のLLM Requestではなく、状況に応じて処理構成そのものを変えるAgent Orchestrationを実装しています。
全体アーキテクチャ
現在の構成は次のようになっています。
┌──────────────────────────────────────┐
│ 幹事 / 参加者 │
└──────────────────┬───────────────────┘
│
▼
┌──────────────────────────────────────┐
│ ENCOPA / Vercel │
│ │
│ Next.js 16 / React 19 / TypeScript │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ 店舗検索 API │ │ Agent API │ │
│ │ /api/venues │ │ /api/agent │ │
│ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │
│ ┌──────▼─────────────────▼───────┐ │
│ │ Validation / Authorization │ │
│ │ Rate Limit / Security │ │
│ └───────────────────────────────┘ │
│ │
│ Group / RSVP / Allergy / Chat / ICS │
└────────────┬────────────┬────────────┘
│ │
店舗取得│ │AI推論
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ Hot Pepper │ │ OrcaRouter │
│ Gourmet Web API │ │ AI Gateway │
└──────────────────┘ └────────┬─────────┘
│
▼
┌───────────────┐
│ LLM / Provider│
└───────────────┘
┌──────────────────────┐
│ Turso / libSQL │
│ │
│ Groups / Members │
│ Messages / Limits │
│ Venue Cache │
│ Agent Cache │
└──────────────────────┘
主な技術構成は次の通りです。
| 領域 | 技術 |
|---|---|
| Frontend / Backend | Next.js 16 |
| UI | React 19 |
| Language | TypeScript |
| Styling | Tailwind CSS v4 |
| Database | Turso / libSQL |
| AI Gateway | OrcaRouter |
| 店舗データ | ホットペッパー グルメWebサービス |
| Hosting | Vercel |
| UI Components | Radix UI / Lucide React |
AIに全部を任せない
ENCOPAでは、判断できるものまですべてLLMへ投げているわけではありません。
例えば、
- 人数
- 予算
- 個室
- 宴会対応人数
- 飲み放題
- コース
- アクセス情報
などはプログラムで扱えます。
まずアプリケーション側で候補を評価します。
店舗データ
│
├─ 人数条件
├─ 予算条件
├─ 個室条件
└─ 利便性
│
▼
Deterministic Score
│
▼
Agentによる補助分析
│
▼
候補を再評価
現在の画面では、候補スコアを概ね、
Deterministic Score × 0.65
+
Agent Score × 0.35
として組み合わせています。
AIだけでランキングを決定する構成ではありません。
考え方としては、
コードで判断できることはコードで。
文脈を必要とする判断だけAIで。
です。
LLMが存在しない店舗を推薦しても採用しない
Agentへ候補店舗を渡す際には、店舗ごとのIDも一緒に渡します。
Agentが返した店舗IDについては、アプリケーション側で、
入力候補に存在するIDか
を確認します。
候補集合に存在しないIDは採用しません。
Agent Output
↓
Venue ID
↓
候補ID集合と照合
│
├─ 存在する → 採用
│
└─ 存在しない → 除外
LLMが新しい店舗を生成して、そのままUIへ表示される構造にはしていません。
ENCOPAのAgentic AI
ENCOPAでは、Coordinatorが最初から固定された一連の処理を実行するのではなく、現在の状態を見て次のActionを選びます。
選択肢は大きく、結果を確定する `FINALIZE` と、追加分析を行う `RUN_SPECIALISTS` です。
ユーザーの目的
↓
Coordinator Agent
↓
次のActionを選択
├─ FINALIZE
└─ RUN_SPECIALISTS
↓
Policy Gate
↓
必要な専門Agentだけ起動
↓
Observation
↓
Coordinatorが再判断・統合
↓
Self Check
↓
必要なら1回だけ修正
↓
幹事へ提示
この流れは、次のループとして実装しています。
Decide
↓
Policy Gate
↓
Tool
↓
Observation
↓
Re-decide
Policy Gateは、Actionを実行する前に、権限、残りステップ、LLM呼び出し数、Specialist数、修正回数を確認します。これにより、Coordinatorが処理を選んでも、上限やポリシーに反するActionはそのまま実行されません。
Agent Loopの主要ファイルは次のように分けています。
lib/agent/
├── runner.ts # Agent Loopの実行
├── policy.ts # Actionの許可・拒否・承認要求
├── state.ts # ステップ数や使用量などの状態
└── tools.ts # 実行可能なToolの登録
無制限に自律実行させないため、ハードリミットも設定しています。
| 制御対象 | 上限 |
|---|---|
| Agent Loop | 最大4ステップ |
| LLM呼び出し | 最大5 calls |
| Specialist | 最大2つ |
| 自己修正 | 最大1回 |
ENCOPAにおける自律性は、
AIが何でも操作することではなく、制約の中で状況に応じた次の処理を選ぶこと
として設計しています。
どんなときに詳細分析へ進むのか
通常の条件では、Coordinatorだけで分析します。
Coordinator
↓
Self Check
↓
Result
一方、現在の実装では次のような場合に詳細分析へ進みます。
- 食事への配慮が必要
- 20人以上
- 上位候補の評価差が小さい
- 価格情報が不足している
- 宴会対応人数が不明
- 個室希望だが該当候補が確認できない
- Coordinator自身が追加確認を要求した
つまり、
常時Multi-Agentではなく、必要になった場合だけMulti-Agent
です。
Specialistも必要な役割だけ動かす
現在は3種類のSpecialistを用意しています。
会場比較担当
目的・人数・予算・個室・アクセスの観点から候補を比較します。
予約リスク確認担当
不足している情報や、予約前に店舗へ確認した方がよい事項を整理します。
会食進行担当
幹事が次に行う作業や、参加者へ共有する内容を整理します。
ただし、3種類すべてを同時に呼び出すわけではありません。
現在は、
会場比較担当
+
状況に応じて
予約リスク確認担当
または
会食進行担当
という2担当を選びます。
Coordinator
↓
必要な役割を判定
↓
Specialistを2担当選択
↓
並列実行
↓
Synthesizer
これによって、必要以上にAgentを増やさずに詳細分析を行います。
Agentの回答をそのまま信用しない
Agentic AIで難しいのは、
「Agentが回答したので正しい」
とは限らないことです。
ENCOPAでは、Agentの出力後にコード側で自己検証を行います。
Agent Output
│
▼
┌───────────────────────────┐
│ Deterministic Self Check │
│ │
│ ・推薦店舗IDは正しいか │
│ ・推薦理由があるか │
│ ・確認事項が空でないか │
│ ・予約済みと誤認してないか │
│ ・人数条件に矛盾しないか │
│ ・個室条件に矛盾しないか │
│ ・食事配慮を落としてないか │
└──────────────┬────────────┘
│
問題あり？
│ │
NO YES
│ │
│ ▼
│ Agentへ修正依頼
│ 最大1回
│ │
│ ▼
│ 再検証
│ │
└───────┤
▼
Result
例えば、
予約しました
予約済みです
会場を確保しました
のような文言は、現在のENCOPAの能力と矛盾します。
これはLLMへ再度判断させなくても、コードで確認できます。
モデルでしか判断できないことと、コードで検証できることを分ける
ようにしています。
自己修正は1回だけ
Self Checkで不備を検出した場合、修正用のリクエストをAgentへ送ります。
ただし最大1回です。
Agentが生成
↓
コードで検証
↓
不備を検出
↓
1回だけ修正
↓
再検証
それでも問題が残る場合は、
要確認
として幹事へ返します。
何度も修正を繰り返すと、
- コスト
- レイテンシ
- 同じ誤りの反復
- 処理ループ
が増えるためです。
AIだけで解決できないものを、無制限にAIへ戻し続けないようにしています。
OrcaRouterをどう使っているか
ENCOPAのLLMアクセスには OrcaRouter を利用しています。
ここで分けているのが、
Agent Orchestration
と、
Model Routing
です。
ENCOPA自身が決めるのは、
- 標準分析で十分か
- 詳細分析へ進むか
- どのSpecialistを使うか
- 出力に問題があるか
- 人間へ戻すべきか
という業務フローです。
その中で必要になるLLM RequestをOrcaRouterへ送ります。
┌───────────────────────────┐
│ ENCOPA │
│ │
│ ・分析深度を判断 │
│ ・Specialistを選択 │
│ ・結果を統合 │
│ ・自己検証 │
│ ・人間へ戻す │
└─────────────┬─────────────┘
│
│ LLM Request
▼
┌───────────────────────────┐
│ OrcaRouter │
│ │
│ ・Model Routing │
│ ・AI Gateway │
│ ・Provider abstraction │
│ ・Best-effort Failover │
└─────────────┬─────────────┘
│
┌───────┼───────┐
│ │ │
▼ ▼ ▼
Model A Model B Model C
整理すると、
ENCOPA
「何を考える必要があるか」
↓
OrcaRouter
「どのモデルへ送るか」
という分担です。
Auto Routerを利用する
現在のENCOPAでは、モデル指定を環境変数で切り替えられるようにしています。
既定値は、
ORCAROUTER_MODEL=orcarouter/auto
です。
接続部分は、
ORCAROUTER_BASE_URL=https://api.orcarouter.ai/v1
ORCAROUTER_MODEL=orcarouter/auto
という構成になっています。
重要なのは、特定モデル名そのものではありません。
業務上の判断をENCOPAに残し、モデル選択をRouter側へ分離する
ことが目的です。
モデルが変化しても、宴会幹事のワークフローそのものがモデル固有の実装に引っ張られにくくなります。
OrcaRouterだけに信頼性を任せない
Routerを入れているからといって、アプリ側で障害を考えなくてよいわけではありません。
ENCOPAではOrcaRouter側のFailoverをbest-effortとして扱い、アプリ側にも、
- Retry
- Timeout
- Circuit Breaker
- Workflow Deadline
- Specialist失敗時の縮退
- Synthesis失敗時の縮退
を実装しています。
OrcaRouter / Provider
×
│
▼
ENCOPAが検知
│
┌────┼─────┐
▼ ▼ ▼
Retry Timeout Circuit Breaker
│
▼
縮退して継続
Routerがあることを理由に、アプリケーション側の障害対策をなくしてはいません。
通常1回、必要な場合だけ処理を増やす
Standard分析では、
Coordinator
↓
Self Check
↓
Result
となり、基本は 1 routed call です。
詳細分析では、
Coordinator
↓
Specialist A ─┐
├─ 並列
Specialist B ─┘
↓
Synthesizer
↓
Self Check
↓
Result
となり、基本は 4 routed calls です。Self Checkで不備があった場合だけ修正用に1回追加し、どの経路でも最大5 callsを超えません。
| モード | 通常 | 自己修正が必要 |
|---|---|---|
| Standard | 1 call | 最大2 calls |
| Detailed | 4 calls | 最大5 calls |
さらに、Agent Loopは最大4ステップ、Specialistは最大2つ、自己修正は最大1回です。同じ条件・候補の分析結果がCacheにある場合は、LLMを呼び出さず0 callで再利用します。
つまり、
毎回最大構成を動かすのではなく、必要な場合だけ計算量を増やし、上限到達時は安全に終了する
設計です。
Action Traceで処理を見える化する
画面には、AgentがどのActionを選び、Policy Gateを通過し、どのToolが実行されたかをAction Traceとして表示します。
確認できる主な項目は次の通りです。
- 実行したActionとObservation
- 使用ステップ数 / 最大ステップ数
- LLM calls数 / 最大calls数
- 使用Specialist数 / 最大数
- Human Approvalが必要な操作
- Policy Gateによる停止・拒否
ここで表示するのは、ユーザーが処理を検証するための実行記録です。モデル内部のChain-of-Thoughtを表示するものではありません。
Agent分析結果をキャッシュする
同じ条件で何度もLLMへ問い合わせる必要もありません。
Agent分析結果は、
Process Memory Cache
+
Turso Shared Cache
で保持します。
同じ条件・候補
↓
Memory Cache
│ │
HIT MISS
│ │
0 call ▼
Turso Cache
│ │
HIT MISS
│ │
0 call ▼
OrcaRouter
Agent CacheのTTLは30分です。
Serverless Instanceが変わった場合でも、Turso側の共有Cacheから同じ結果を利用できます。
店舗検索にもキャッシュと縮退を入れる
AIだけが外部依存ではありません。
店舗検索も外部サービスに依存しています。
そのため、店舗検索側にも、
- Cache
- Retry
- Circuit Breaker
- 日次利用上限
- Stale Cache
- Graceful Degradation
を入れています。
店舗検索
│
▼
Fresh Cache?
│ │
YES NO
│ │
▼ ▼
結果 Hot Pepper API
│
成功？
│ │
YES NO
│ │
▼ ▼
Cache保存 Stale Cache?
│ │
YES NO
│ │
▼ ▼
保存済み エラー
結果表示
Fresh Cacheは30分です。
店舗検索元へ接続できない場合は、最大24時間までの保存済み検索結果をStale Cacheとして使用できます。
その場合は、保存済みデータであることと取得時刻を画面に表示します。
古い情報を最新情報のようには見せません。
店舗検索APIへ渡す条件も絞る
店舗検索APIで使用する主な検索条件は、
都道府県
人数
です。
予算・目的・優先条件・個室希望・食事配慮などは、店舗を取得したあとにENCOPA側で評価します。
そのため、
同じ地域
+
同じ人数
であれば、保存済みの店舗検索結果を利用しながら、
予算を変える
個室条件を変える
優先条件を変える
といった再評価ができます。
外部APIへの依存と呼び出し回数を減らすための設計です。
セキュリティ ── Agentの権限を増やしすぎない
Agentic AIで重要なのは、モデルが賢いかどうかだけではありません。
Agentが何を実行できるのかも重要です。
ENCOPAではAIに、店舗の自動予約、予約の自動キャンセル、外部サービスへの確定情報送信を単独で実行する権限を与えていません。
Agentの役割は、
比較
整理
確認事項抽出
次Actionの提案
までです。
さらに、ActionはToolを直接呼び出すのではなく、必ずPolicy Gateを通過します。
CoordinatorがActionを選択
↓
Policy Gate
├─ ALLOW
├─ DENY
└─ HUMAN_APPROVAL_REQUIRED
参加者への共有、予約、キャンセルのように外部へ影響する操作は、人間の明示的な承認が必要なActionとして扱います。現在未実装の予約・キャンセルについても、Agentが勝手に実行できる構成にはしていません。
実装している主な対策として、
- APIキーをServer-sideでのみ保持
- OrcaRouter接続先Hostを制限
- 店舗情報を信頼できない入力として扱う
- Prompt Injectionを想定したSystem Prompt
- Agent出力の店舗IDを検証
- Policy Gateによる外部書き込みActionの制限
- Human Approvalが必要なActionの明示
- Agent Loop・LLM calls・Specialist・修正回数の上限制御
- CSRF対策
- POST Bodyサイズ制限
- HttpOnly Cookie
- SameSite Strict
- ProductionでのSecure Cookie
- Session TokenのHash保存
- AES-256-GCMによる機微情報暗号化
があります。
LLMへ個人情報を送りすぎない
Agent分析へ送るのは、
検索条件
+
公開店舗情報
です。
氏名、連絡先、アレルギー品目の詳細は候補分析Agentへ送りません。
食事への配慮が必要な場合には、
dietary = true
という情報を使います。
Agentが扱う情報そのものを減らすことで、問題が起きた際の影響範囲も減らしています。
アレルギー情報は本人と幹事だけ
参加者は自分のアレルギー情報を登録できます。
保存する機微情報にはAES-256-GCMを使用しています。
また、アレルギーの詳細は、
本人
+
幹事
に閲覧範囲を制限しています。
他の参加者からは詳細を確認できません。
参加者のSession Tokenについても、DBへ平文のTokenを保存せず、Hash化した値を保持します。
あえてAIを使わない処理もある
ENCOPAはAgentic AIを使ったプロダクトですが、すべてをLLM化してはいません。
例えば、検証済みの予約情報などから作れる定型的な案内については、必ずしもLLMを経由する必要はありません。
LLMを追加すれば、
- APIコスト
- レイテンシ
- 外部障害
- Prompt Injection経路
も増えます。
そのため、
AIを入れる価値が、追加されるリスクやコストを上回る部分だけAIを使う
ようにしています。
信頼性・堅牢性 ── AIが止まっても全部を止めない
例えば店舗検索に成功し、その後のAgent分析だけが失敗した場合。
店舗検索成功
↓
候補店舗を取得
↓
Agent分析
×
↓
AI分析のみ利用不可
↓
店舗候補は比較可能
という状態になります。
Specialistが全員失敗した場合も、Coordinatorの標準計画へ戻します。
Synthesizerに失敗した場合も、取得できている計画へ縮退します。
高度な処理が失敗したらサービス全体を止めるのではなく、可能な機能まで縮退する
ことを意識しています。
自律性 ── 「次の処理」をAgentが変える
ENCOPAの自律性は、自動で文章を書くことだけではありません。
ユーザー条件
↓
店舗検索
↓
決定論的評価
↓
Coordinator
↓
分析深度を判断
↓
必要ならSpecialistを選択
↓
並列処理
↓
結果を統合
↓
自己検証
↓
必要なら1回修正
↓
必要なら人間へ戻す
というように、状況によって実行する処理の深さや構成を変えるところにあります。
一方で、不可逆な操作は自律化していません。
AI
↓
比較・整理・提案
幹事
↓
確認・判断
店舗
↓
実際の予約
自律性とHuman-in-the-Loopの両方を残しています。
アイデア・独創性 ── 「店」ではなく「幹事」をAgent化する
店舗検索そのものはすでに多くのサービスがあります。
AIによるおすすめ機能も珍しいものではありません。
そこでENCOPAでは、
検索精度だけで差別化しようとしない
ことにしました。
一般的な検索サービスでは、
条件入力
↓
店舗一覧
↓
詳細
↓
予約
が中心です。
ENCOPAでは、
条件整理
↓
店舗検索
↓
候補比較
↓
追加分析判断
↓
予約前確認事項整理
↓
参加者共有
↓
出欠確認
↓
食事配慮管理
↓
幹事確認
↓
予定化
までを一つの流れとして扱っています。
つまり、
店舗をAI化するのではなく、「幹事」という仕事そのものをAgent化する
ことを狙いました。
Agentic AIとして意識した5つの観点
ここまでの設計を整理すると、次のようになります。
| 観点 | ENCOPAで行っていること |
|---|---|
| セキュリティ | 権限制限、暗号化、Prompt Injection対策、入力・出力検証 |
| コストパフォーマンス | Adaptive Multi-Agent、Cache、利用上限 |
| 信頼性・堅牢性 | Retry、Timeout、Circuit Breaker、Degradation |
| 自律性 | Coordinator → Specialist選択 → Synthesis → Self Check |
| アイデア・独創性 | 幹事WorkflowそのものをAgent化 |
重要なのは、この5つが独立していないことです。
自律性を上げると別の問題が生まれる
自律性を高める
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
LLM Call増加 攻撃面増加 外部依存増加
│ │ │
▼ ▼ ▼
Adaptive Agent Least Agency Retry
Cache HITL Timeout
Usage Limit 権限制御 Circuit Breaker
Degradation
自律性を高くすれば、LLM呼び出しが増えます。
そのため、必要な場合だけMulti-Agentに切り替えます。
Agentができることを増やせば、攻撃面も広がります。
そのため、Agentへ予約操作などの権限を渡していません。
外部サービスを増やせば、障害ポイントも増えます。
そのため、RetryやCircuit Breaker、Cacheによる縮退が必要になります。
自律性そのものではなく、自律性によって生まれるリスクまで設計する
ことを意識しました。
コストを運用でも制限する
LLM Request数を減らすだけではなく、利用量にも上限を設定しています。
例えば、
- クライアント単位の時間上限
- Agent Workflowの日次上限
- Detailed Analysis専用の日次上限
- Venue APIの日次上限
です。
詳細分析用の上限へ達した場合は、可能ならStandard Planへ縮退します。
Detailed上限
↓
到達
↓
Standardへ縮退
↓
利用継続
「性能が高いAgent」だけではなく、
継続して運用できるAgent
にするための制御です。
テストでも確認する
AI機能は、一度デモで動いただけでは十分とは考えていません。
ENCOPAでは、
pnpm lint
pnpm typecheck
pnpm build
pnpm test
pnpm audit --prod
を使っています。
統合テストでは、
- Agent処理
- Cache
- OrcaRouter互換処理
- 権限分離
- CSRF
- アレルギー情報のアクセス制御
- 予約情報の更新競合
- メッセージの重複防止
- Retry
- Circuit Breaker
- 縮退処理
- 招待リンク
- グループ間のデータ分離
などを確認しています。
UIも実際のブラウザで確認する
APIが正しくても、UIが崩れていればユーザーは使えません。
そのため、
pnpm visual-check
も用意しています。
複数のViewport幅で実際にブラウザ描画し、
- 横方向へのはみ出し
- Hydration失敗
- Style未適用
- 文字切れ
- Console Error
- UIコントロールの崩れ
などを確認します。
プログラムとして動くことと、プロダクトとして使えることは別
として扱っています。
現在の技術構成
Next.js 16
React 19
TypeScript
Tailwind CSS v4
Radix UI
Lucide React
+
Vercel
+
Turso / libSQL
+
Hot Pepper Gourmet Web Service
+
OrcaRouter
ローカル開発ではSQLiteを使用でき、本番環境ではTurso / libSQLへ接続する構成です。
現時点でできないこと
ここは、現在の機能と将来構想を混同しないよう明確にしています。
リアルタイム空席確認
現在は行っていません。
店舗への自動予約
現在は行っていません。
自動キャンセル
現在は行っていません。
メール・LINE等への自動通知
現在は行っていません。
SSO
現在は招待リンクとCookieによる軽量な参加方式です。
WebSocketによるリアルタイムチャット
現在のチャットはリアルタイムSocket方式ではありません。
店舗のアレルギー対応保証
ENCOPAでは保証しません。
ユーザーから店舗への直接確認が必要です。
今後
現在の実装に含まれていない今後の拡張としては、
- OrcaRouterのRouting結果を用いたルーティング品質分析
- Human Approvalを前提とした実空席・予約API連携
- 参加人数や条件変更を受けた複数ターンの再プランニング
を考えています。
例えば、
参加人数が変わる
↓
現在の候補を再評価
↓
条件を満たさなければ再検索
↓
変更案を作る
↓
幹事へ提示
↓
幹事が判断
まで継続的につながれば、さらに「幹事Agent」としての価値を高められます。
ただし、これらは現在の実装機能ではありません。
AI HACKを通して感じたこと
今回ENCOPAを作る中で感じたのは、
実際のwebアプリにAIだけを入れたプロダクトでは「業務にAIを入れたこと」自体は価値になりにくい
ということです。
本当に考える必要があるのは、
AIに何を任せるのか
AIへ何を渡すのか
AIが間違えたらどうするのか
何回まで考えさせるのか
どこから人間が判断するのか
AIが使えない場合どうするのか
だと思います。
ENCOPAでも、Agentを増やすこと自体を目的にはしていません。
必要な場面だけAgentを増やし、
AIを使う必要のない処理はコードに任せ、
AIを信用しきれない部分はコードで検証し、
重要な操作は人間に残しました。
Agentic AIを実際のプロダクトとして使うには、この境界線を作ることが重要だと感じています。
まとめ
ENCOPAを開発する中で一番重要だったのは、
AIに何をさせるかだけでなく、AIに何をさせないかを決めること
でした。
店舗情報は既存APIから取得する。
数値で判断できる部分はコードで処理する。
文脈が必要な比較だけAgentへ任せる。
通常はCoordinatorだけで処理する。
難しい場合だけSpecialistを追加する。
Agentの回答はコードで再検証する。
必要なら1回だけ修正する。
それでも不確かなものは人間へ戻す。
外部サービスが利用できない場合は、可能な範囲まで機能を落として継続する。
そしてOrcaRouterを利用することで、
ENCOPA
= 業務上「何を考えるか」を決める
OrcaRouter
= 「どのモデルへ送るか」を担う
という境界を作りました。
「店を探すAI」ではなく、
宴会を開催できる状態まで、幹事の仕事を前へ進めるAgentic AI。
それがENCOPAです。
参考
- OrcaRouter
- https://www.orcarouter.ai/ja
- AI HACK
- https://aihackathon.jp/