プログラマブルなカスタマーサポートAI:実際どこまで制御できるのか(2026年)

「プログラマブル」が本当に意味すべきこと

「プログラマブルなカスタマーサポートAI」を検索すると、互いにかみ合わない2つの陣営が見つかる。一方は「APIがあるから自動化できる」と考え、もう一方は「自分でエージェントを書いている」と考える。どちらも狭すぎる。

サポートにとって本当に意味のある形でのプログラマブルとは、次の5つを形作れることを指す。AIがどう振る舞うか、何を知っているか、何をできるか、何を許可されているか、そしてデフォルトが不十分なときにどう拡張するか。Webhookは提供するがリトリーバルの制御を提供しないツールは、本当の意味でプログラマブルではなく、単に周辺がスクリプト可能なだけだ。システムプロンプトの編集はできてもチケットに対してアクションを起こせないツールは、テキストボックス付きのチャットボットにすぎない。

このフレーミングが重要なのはコストの問題があるからだ。特にエンジニアの間にある本能的な感覚として、本当の制御にはモデルから積み上げて構築する必要がある、というものがある。この本能は、2週間の統合作業を静かに9か月のプラットフォームプロジェクトへと変えてしまう。だからこそ、経路を選ぶ前に全体の範囲を一度に見ておくことが役立つ。

プログラマビリティのスペクトラム

以下が正直な範囲であり、制御が最も少ないものから最も多いものまでを示している。そしてこれは、どれだけメンテナンスが必要かとほぼ完全に一致する。

左から順に見ていくと:

1. 閉じたトグル。 ベンダーのボットをオンにするだけ。定型回答をいくつか編集し、フォールバックメッセージを設定するくらいだ。エンジニアリングはゼロ、実質的な制御もゼロ。プロセスが枠に収まっている限りは優れているが、収まらなくなった瞬間に破綻する。
2. 設定とルール。 ノーコードのビルダー。インテント、決定木、ルールベースのルーティング。制御は増えるが、依然としてベンダーのレール上にある。UIが公開しているもの以上には手が届かない。
3. APIとWebhook。 ヘルプデスクやボットがRESTエンドポイントとイベントフックを公開する。自分のコードから操作できるが、配管自体を自分で敷設し、知能も自分で供給し続ける必要がある。
4. プログラマブルなチームメイト。 リトリーバル、アクション、テストを備えた既製のエージェントで、かつ本物の開発者向けの面を保っている。挙動を設定し、周辺部分をスクリプト化するだけで、エンジンを作り直す必要はない。ここが強調されているのには理由がある。
5. ゼロからの構築。 ファウンデーションモデルのAPIの上にエージェントを組み立てる。最大の制御、最大のメンテナンス、そしてメッセージごとのトークン課金。

このテーマに関するほとんどのコンテンツは、選択肢が#1か#5しかないかのように振る舞う。愚かなボットを買うか、賢いものを構築するかだ。しかし興味深い領域、そしてほとんどのサポートチームが着地すべき場所は#4である。

プログラマブルなサポートAIで制御できる5つのこと

経路を比較する前に、実際に何をプログラミングしているのかを具体的にしておく価値がある。サポートAIが「プログラマブル」だと言うとき、私が指しているのは、開放されるか閉じたままになるかのこの5つの面だ。

• 挙動とプロンプト。 トーン、ペルソナ、いつエスカレーションするか、いつ黙っているか。当然の要件だが、多くの閉じたボットは今でも挨拶欄しか提供しない。
• 知識とリトリーバル。 AIが回答する前に読むもの。ヘルプセンター、過去のチケット、社内文書。これの質こそが、役に立つ回答と自信満々な誤答とを分けるものであり、閉じたツールが最も隠しがちな面である。
• アクションとツール。 AIが注文を調べたり、チケットにタグを付けたり、返金を発行したり、トリアージしてルーティングしたりできるか。話すだけではなく。
• ガードレールとテスト。 何を実行することが許されているか、そして顧客に触れる前にそれが正しく振る舞うことをどう証明するか。ゼロからの構築がほぼ必ず欠いているものだ。
• API・CLIによる拡張。 デフォルトがカバーしないすべてのための逃げ道。社内サービスを呼び出す、スクリプトを実行する、誰も想定していなかったツールを組み込む。

5つすべてを開放するツールこそ、真にプログラマブルだ。1つか2つしか開放しないツールは、その言葉を売っているにすぎない。実際に人々が頭を悩ませる2つの経路、ゼロからの構築と中間の道を見ていく間、このリストを手元に置いておいてほしい。

経路A:モデルAPIの上でゼロから構築する

これは「プログラマブル」と聞いたときにほとんどのエンジニアが思い浮かべる経路であり、プロジェクト化してしまう経路でもある。OpenAIもAnthropicも、完成したサポートエージェントではなくモデルインフラを販売しており、まさにその点において優れている。ただし、両社がカバーするのは、「カスタマーサポートAI」という言葉が示唆するよりもずっと小さな部分にすぎない。

得られるのは本物のビルディングブロックだ。モデル、ツールを定義する手段、エージェントループ、いくつかのホスト型リトリーバルのプリミティブ。得られないのはサポートエージェントそのものだ。OpenAI自身のドキュメントもこの分担について率直で、「デプロイ、ツールの実装、状態の保存、承認の判断」は自分が所有し、「SDKはエージェントループを実行する」だけだとしている。AnthropicのClaude Agent SDKも同じ形をしている。セッション、フック、権限は用意されているが、ループは自分のプロセス内で動き、永続化は自分の統合作業になる。

つまり、「注文を調べて返金を発行する」というステップは、モデルが発行するツール呼び出しであり、Shopifyや自社の決済システムと会話するコードは完全に自分のものになる。他のすべての基盤となる要素、常に最新のドキュメントと同期するリトリーバル、会話の状態、チケットアクション、エスカレーション、テストハーネスも同様だ。ツール単位での詳細な比較が知りたければ、AgentKit vs Anthropic APIの比較記事が深く掘り下げている。

コストモデルが最も鋭い驚きをもたらす。チケットが解決されるかどうかに関わらず、すべてのメッセージについてトークン単位で課金される。システムプロンプト、取得されたチャンク、ツールの往復、推論、そしてすべてのリトライに対してだ。

プロンプトキャッシュは、サポート用途ではこの数字をかなり和らげてくれる。毎ターン同じヘルプセンターのコンテキストを再送信するため、キャッシュヒットは標準入力価格の約10%で読み込まれるからだ。しかしキャッシュが変えるのは請求額の大きさであって、課金単位そのものではない。1ターンあたり十数個のチャンクを取得し、2回リトライする10ターンの会話は、顧客が不満なまま去ったとしても、そのすべてが課金対象になる。

これはモデルプロバイダーへの批判ではまったくない。あくまで正直な範囲の話であり、素のモデルAPIはインフラであって従業員ではない。エージェントのロジックそのものが自社の製品であるときは、ここで構築すればよい。

経路B:エンジンを提供するプログラマブルなチームメイト

中間の道は、「プログラマブルなカスタマーサポートAI」と検索するほとんどの人が実際に求めているものに合致する。組み立てるのではなく、自社のスタックに向けて設定し、スクリプト化できる、すでにサポートのやり方を知っているエージェントだ。eeselのようなツールが位置するのはここであり、これが素のモデルAPIとは異なるカテゴリーであって、その上に乗った単なる使いやすいラッパーではないという点を正確に理解しておく価値がある。

AIヘルプデスクのチームメイトは、エンジン全体があらかじめ構築された状態で登場する。過去のチケットとヘルプセンターで学習し、すでに運用しているヘルプデスク内のキューに参加し、注文を調べ、タグ付けとトリアージを行い、返信を下書きまたは送信する。リトリーバル、会話の状態、チケットアクション、エスカレーションはすべて処理済みだ。実装するのはインフラではなく、設定するのは挙動になる。

開発者にとって重要な点はこうだ。「既製」は「閉じた箱」を意味しない。eeselは、デフォルトがカバーしない周辺部分のために、本当にプログラマブルな面を維持している。

• Network Access は、許可した任意のREST APIに、GET、POST、PATCH、DELETEと、ドメインごとの認証ヘッダー付きでエージェントがアクセスできるようにする。認証情報はヘッダーとして存在し、モデルに見せられることは決してない。
• Webhook は、どんなツールにも一意のURLを与え、送信されたペイロードが何であれエージェントを呼び起こす。
• **CLI**とカスタムスキルにより、自分で所有したい部分をスクリプト化でき、1つのスキルが1回の実行で複数のツールにまたがることもできる。ヘルプデスクを読み、Shopifyを確認し、Slackに投稿する、といった具合だ。

私が持ち続けたい区別はこうだ。価値を生む部分ではやはり自分でコードを書くが、そこにたどり着くためにリトリーバル、状態、ヘルプデスクのコネクタをゼロから作り直す必要はない。そして、すでに運用しているヘルプデスクに接続するため、コネクタ(1000以上)はベンダー側の問題であり、自分の問題ではない。

MCPが静かに中間の道を広げている

中間の道が強くなり続けているもう1つの理由がある。ヘルプデスクが「REST APIを渡すから自分で構築しろ」という姿勢から、自前のModel Context Protocolサーバーを提供する方向へ移っているのだ。MCPはAnthropicが導入したオープンな標準であり、ツールごとに専用の統合を作る代わりに、1つのプロトコルを通じてエージェントを外部システムに接続する。

ファーストパーティのリストは急速に増えている。

• Gorgiasはmcp.gorgias.com/mcpで無料のMCPサーバーを提供しており、現在オープンベータ中だ。
• Frontはmcp.frontapp.com/mcpのサーバーを文書化しており、異例なほどクリーンな権限モデルを持つ。PKCE付きのOAuth 2.1とユーザーごとのスコープにより、エージェントの権限は認可したチームメイト本人のものと正確に一致する。
• Atlassianは公式のリモートMCPサーバーを運用しており、OAuth経由でJira、Confluence、Jira Service Managementを接続する。

MCPがしないことは、AIをそれ単独でプログラマブルにすることだ。サーバーが公開するのはツールであり、頭脳、リトリーバルの質、そして実際にその返金を発行すべきかどうかを決めるガードレールは、依然として自分で用意するか購入するかしなければならない。MCPは接続層であり、まさにそれゆえに「プログラマブルなチームメイト」という経路を容易にするのであって、「すべてを自作する」経路を容易にするわけではない。

罠:「プログラマブル」と「自分が作った」を混同すること

ここで、構築したいという本能に対して異議を唱えておきたい。実際にサポートエージェントをリリースしてきた開発者たちのコンセンサスは驚くほど一貫しており、それは「絶対に構築するな」ではない。モデル呼び出しは簡単な部分であり、プログラマブルに聞こえるものすべてがメンテナンスの尾を隠している、というものだ。

サポートエージェントは、話すだけでなく行動できるという事実から始めよう。本番環境でのハルシネーションを防ぐことについてのAsk HNのスレッドで、最も鋭いフレーミングはまさにこの点についてだった。

"The failure mode I keep seeing isn't hallucination per se... it's blurred responsibility between intent and execution. Once a model can both decide and act, you've already lost determinism."

crosslayer, Hacker News

アカウントの状態を変更できるエージェントには、より良いプロンプトだけでなく、制約されたアクション空間と許可/拒否リストが必要だ。そして、テストなしにガードレールが機能しているかどうかを知ることはできないが、それをきちんと構築しているチームはほとんどない。これが、シミュレーション、つまり実際の過去のチケットを再生し、本番のキューに触れる前にサンドボックス内で、実際にチームが送った回答と照らし合わせてエージェントの回答をスコアリングすることの最も強力な論拠だ。まさにこの理由から、これはeeselの中核的なスキルの1つになっており、ゼロからの構築がほぼ必ず省略してしまうものでもある。

次にリトリーバルがある。誰もがこれを過小評価している。人気のオープンソースRAGテンプレートを保守するMicrosoftのエンジニアが、この反射的な思い込みに終止符を打った。

"So few developers realize that you need more than just vector search for RAG, so I still spend many of my talks emphasizing the FULL retrieval stack for RAG."

pamelafox, Hacker News

1回きりのリトリーバルでは不十分であり、結局は結果を評価して再クエリを行うエージェント的なループが必要になる。それは設定フラグではなく、本物のシステムだ。そして、それが構築されて初めて、本当の数字、つまりメンテナンスが姿を現す。460件以上のコメントが付いたr/AI_Agentsのスレッドから。

"The hardest part wasn't the LLM or voice quality - it was keeping the agent's knowledge current as policies changed and edge cases emerged."

I build AI agents for a living, Reddit

私たちは何年もの間、本番のサポートキューでAIを運用してきたが、エッジケースこそが仕事のすべてだ。先週変更されたポリシー、昨日ローンチされた製品ライン、あらゆる汎用エージェントを壊すあの奇妙な返金フロー。この作業はクイックスタートには現れないし、決して終わることがない。

制御とメンテナンス:実際にすべてを決める軸

視野を広げると、経路はどれだけの制御が得られるかと、どれだけメンテナンスが必要かという2つの軸の上に並ぶ。誤りは、この2つが連動する、つまり制御が増えれば常に維持コストも増える、と思い込むことだ。

閉じたボットは低い制御・低いメンテナンスだ。ゼロからの構築は高い制御・高いメンテナンスであり、誰もがこれが唯一の線だと思い込んでいる対角線にあたる。プログラマブルなチームメイトの売り文句のすべては、右下のコーナーにある。高い制御を、高いメンテナンスなしに得られるのは、エンジン、コネクタ、テストが他の誰かの維持対象になり、それでいて周辺部分のためのAPI、CLI、Webhookは手に入るからだ。

コストの面でも同じ分裂が現れる。自作すれば、解決されようがされまいが、リトライや長い会話のたびに上昇するトークン単位の従量制に乗ることになり、さらにその裏にあるエンジニアの給与も発生する。対照的にeeselは、使用量ベースで対応したチケット1件あたり約40セント、返信単位ではなくチケット単位で課金され、席数料金もプラットフォーム料金も月額最低料金もない。ある開発者が言ったように、「1日10分を節約する一方で、静かに週に何時間ものメンテナンスコストを発生させる」エージェントこそが罠であり、自作はクイックスタートで見えるほど安い選択肢であることはめったにない。

では、どちらの経路を選ぶべきか?

どちらの経路も間違いではなく、異なるチームに適している。以下は表形式にした短いまとめだ。

手っ取り早いルールはこうだ。エージェントのロジックそのものが自社の実際の製品であり、リトリーバル、ガードレール、評価を永久に担当できるエンジニアがいるなら、モデルAPIの上に構築すればいい。解決済みのチケットと、周辺部分のためのプログラマブルな面が欲しいなら、既製のチームメイトの方が速く、2年目にはより安く、はるかに手がかからない。まだこの分野を検討している段階なら、最良のAIエージェントガイドとチケットトリアージのためのAIのまとめが、ツールごとに詳しく解説している。

eeselを試す

「プログラマブルなエージェントを構築する」か「購入する」かを天秤にかけてここまで来たのであれば、ほとんどのサポートチームにとっての正直な答えは、自作はクイックスタートでは安く見えて、2年目にはより高くつく、というものだ。eeselは中間の道を正しく実践したものだ。すでに運用しているヘルプデスクに接続し、過去のチケットとドキュメントで学習し、そしてゼロからの構築がほぼ必ず省略してしまうステップとして、本番のチケットに回答する前に実際のチケット履歴でシミュレーションを行うAIサポートチームメイトだ。

重要な部分ではプログラマブルな面を維持できる。任意のREST APIのためのNetwork Access、Webhook、CLI、カスタムスキルを、まずリトリーバル、状態、コネクタを作り直すことなく利用できる。クレジットカードも営業電話も不要で無料で開始でき、料金は対応したチケット単位なので、消費したトークンではなく実際に行われた作業に対して支払うことになる。四半期をかけてプログラマブルなエージェントを構築するよりも、自社のキューに向けて既存のものを使いたいのであれば、それが自分のチケットで実際に動く様子を見る最も速い方法だ。