Claude と Front:2026年、両者をつなぐすべての方法

Front はすでにこれを作っていた。それが誰も予想しない部分だ

私は eesel で AI エージェントを構築しており、それはつまり、うまく推論できるモデルと、現実の顧客であふれるヘルプデスクとのギャップに1週間の大半を費やしているということだ。Front は私が最もよく知るインテグレーションだが、それは決して自慢できる理由からではない。それに構築の対象としても珍しい相手で、共有受信箱はチケット管理システムではなく、その違いは API のいたるところに現れる。

2026年の初め、Front は私たちのもとで中堅企業向けの商談が停滞する単独の理由として最も多いものだった。チームは評価を通過し、回答を気に入り、そして皆同じことを言った。「Front が私たちのヘルプデスクなので、それに対応してもらえない限り本当の意味でこれを試すことはできない」と。私たちはこれを、英語とフランス語で月に200〜300件ほどのチケットを、約300件の技術文書をもとに処理している B2B SaaS チームから聞き、同じ月にデータ企業からも再び聞いた。だから私たちはそれを作った。それが私たちのFront インテグレーションの生い立ちのすべてであり、だからこそ私はこの調査に、Claude 側では何も見つからないだろうという予想を持って臨んだ。

私は間違っていた。それも嬉しい形で。Front は独自の MCP サーバーを出荷し、その3週間後には最初のバージョンを非推奨にしたうえで第2版を出荷した。これはマーケティングページではない。本番環境にあるものを、あるチームが改善し続けている証拠だ。

しかし、その同じ B2B チームが求めていたことこそ、この先を読み進めるうえで心に留めておく価値がある。彼らが欲しかったのはチャットウィンドウではなかった。ユーザーガイド、Slack、社内ナレッジベース、過去のチケットを1つの回答の中で横断的に参照でき、答えられなかった質問を教えてくれて、彼らが不足している記事を書けるようにしてくれる AI が欲しかったのだ。それはシステムであって、モデルではない。 このギャップを頭に入れておいてほしい。以下の各ルートは、その異なる断片をそれぞれ提供してくれるからだ。

まず、できないこと

「Claude for Front」という検索意図は、たいていドロップダウンが存在すると想定している。Front AI を開き、モデルを選び、Claude を選択、それで完了、と。

そんなものは存在せず、Front はその理由について珍しいほど率直だ。Front のAI 製品ページは、自社の FAQ の中でモデルに関する質問に答えている。OpenAI と Azure OpenAI の GPT モデル、そして AWS 上でホストされる Mistral モデルを使っている、と。ヘルプセンターの AI に関する FAQも同じ3社の名前を2回挙げており、Anthropic には一度も触れていない。

ここで私が見つけて楽しかった詳細がある。Anthropic は実際にFront のサブプロセッサ一覧に載っており、2026年7月から有効になっている。その処理活動として記載されているのは「Customer support」で、Zapier と同じ区分だ。一方で AWS、Azure、Google、OpenAI はすべて「AI-enabled functionality」の区分にある。Front はそれが何を意味するのかを公表していないので、私はそれ以上深読みするつもりはない。しかし率直に読めば、Front 自身のサポートチームは Claude を使えるが、あなたの Autopilot は使えない、ということだ。

私はモデル選択の存在をきちんと探した。単にその不在を流し読みしただけではない。Autopilot Resolve の設定ドキュメントは、Build、Customize、Deploy、Analytics、Routing、Channel の各設定を順に案内している。ナレッジソース、プレイブック、返信時間に関するメッセージ、プロンプト、外観、ルーティングルールが手に入る。プロバイダーの切り替えも、キー入力欄もない。企業レベルのFront AI設定ページも、一目で同じ話を物語っている。

これは Front への批判ではない。2〜3のプロバイダーを選び、それらに対して徹底的にチューニングするのは、十分に正当なプロダクトの意思決定であり、Front AI Copilotはエージェントのワークスペースの中で本当に優れている。同じパネルにあるより小さな機能についても同様だ。Analyze Topicsは人々がなぜ問い合わせを書いているのかを本当に有益な形で読み解いてくれるし、Front AI Translateは多言語のキューにおいてその存在意義を発揮する。ただそれは、問いの形が変わるということを意味するだけだ。あなたが問うべきは、どうすれば Autopilot に Claude を使わせられるか、ではない。どうすれば Claude にあなたの Front データを見せられるか、であり、それには4つの本当の答えがある。

ルート1:Front 独自の MCP サーバー

これが私を驚かせたルートであり、ほとんどの読者がまず試すべきものだ。

Front はMCP Serverを、開発者向けポータルにある7つのファーストパーティのインテグレーション面のうちの1つとして挙げており、Front 自身の言葉で、Claude や ChatGPT のような AI エージェントが会話を読み、返信するための手段だと説明している。仕様ページは、私が確認した2026年8月12日のわずか6日前に最後に更新されていた。

その概要は次の通りだ。

このうち2つの行が、他よりも多くの意味を持っている。

1つ目は ID だ。エージェントの実効的な権限は、それを認可した人物の権限とまったく同じで、呼び出しのたびに Front に対してライブで照合される。その人が請求関係の受信箱を見られないなら、Claude も見られない。中央管理された Claude Enterprise のロールアウトの下でも、IT が接続を許可することはできるが、それでも各個人が自分自身の同意を完了させる必要がある。これはこれ以上ないほど驚きのないセキュリティモデルであり、だからこそこれはパニックを起こす人もなくオープンベータでいられるのだ。

2つ目は送信のゲートだ。send_message は create_draft とは別のツールで、下書き ID を必要とし、destructiveHint: true を伴っている。これにより Claude は送信のたびに立ち止まって確認を求める。つまりループはこうなる。Claude が下書きを作り、あなたが確認し、あなたが承認する。メッセージごとに。

接続は本当に速い。Front のはじめにの記事はオープンベータであること(「Everyone has access」)を確認しており、2つの道を示している。1つ目は Claude 自身のディレクトリにあるコネクタの登録で、Front によればすでに稼働している。2つ目はカスタム接続で、Front の管理者がプライベートな開発者アプリを作成し、OAuth スコープを設定し、任意の MCP クライアントをそのエンドポイントに向ける。Front はこの道の例として Claude Code、Cursor、ChatGPT の開発者モードを挙げている。

レート制限はチームメンバーごとで、Core API の予算とは別のプールにある。

私の見解: どの Front プランに入っていても、今日これを接続すべきだ。無料であり、ファーストパーティであり、「このアカウントは前四半期に何について不満を言っていたか」を実際の受信箱に対して Claude に尋ねられることは、この記事全体の中で最も即座に役立つことだ。これはチケット振り分けよりもClaude の生産性アシスタントに近いので、チームのためのツールとして予算を組んでおくとよい。そしてベータの警告は文字通り受け取ってほしい。ツール名はまだ変わりつつあるので、ビジネスプロセスをまだそこに固定配線しないことだ。

ルート2:同じサーバーを自分で接続する

これは切り分けて扱う価値がある。この制約は現実のもので、特定のグループの人々に影響するからだ。

Front は動的クライアント登録をサポートしていないため、接続するクライアントはクライアント ID とシークレットを伴う機密性の高い接続を保持する必要がある。DCR しか扱えない MCP クライアントはすべて対象外になる。Front はこの道で機能しない例として Codex を挙げている。

Claude Code や Cursor にとって、これは設定ファイルと数分の OAuth 作業にすぎない。ディレクトリ登録に対する利点はコントロールだ。アプリ側でスコープを選べるので、アナリスト向けには読み取り専用の接続を、リードには読み取りと書き込みの接続を、どちらも送信はできないようにして作成できる。以前に何らかのClaude AI インテグレーションを設定したことがあれば、これに違和感を覚えることはないだろう。そのパターンは、Claude Jira インテグレーションやClaude Slack インテグレーションの背後にあるものと同じだ。

私の見解: デフォルトより厳しいスコープが欲しいとき、あるいは使う人がエディタの中で暮らしていて Claude アプリの中ではないときは、ディレクトリのコネクタの代わりにこれをやるとよい。それ以外の場合は、ディレクトリ登録のほうが可動部が少ない。

ルート3:コミュニティのサーバー、今ではほぼ過去のもの

Front が独自のものを出荷する前は、コミュニティがそのギャップを埋めていた。Frontapp に特化した2つのリポジトリは実在し、数値は2026年8月12日に GitHub API から取得したものだ。

1つ目はリアルタイムイベント向けの Front ウェブフックをサポートしており、これは公式ベータが謳っている以上のものだ。2つ目は自らを実験的だと説明しており、メッセージの取得しか行わない。

知っておく価値のある落とし穴がひとつある。「front mcp」で検索すると、frontmcp という146スターのリポジトリが出てくるが、これは MCP サーバーを構築するための汎用フレームワークであり、ヘルプデスクとしての Front とは何の関係もない。私はもう少しでこれを引用するところだった。そうしないように。

ここでのセキュリティ上の姿勢は、自前ホスト型の MCP サーバーによくある通常のものだ。ローカルで動くプロセスに Front の API トークンを渡し、そのトークンはあなたが与えた権限をそのまま持つ。Front 自身のサーバーは、チームメンバーのライブな OAuth セッションに紐づけることで、これを回避している。

私の見解: これらは3月時点では正しい答えだったが、今はもうそうではない。Front の公式サーバーのほうがスコープが優れており、レート制限も優れており、そのラップ対象である API を持つ会社自身がメンテナンスしている。コミュニティのリポジトリに頼るのは、公式ベータがまだ提供していないウェブフック駆動のイベントが必要な場合だけにしよう。

ルート4:Core API の上に構築する

これは、答えが無人でなければならないときに大半のエンジニアが行き着く場所であり、本当の設計判断が生きている場所だ。私はこの記事のためにFront の Core APIのドキュメントをきちんと読み込んだが、3つのことがそれ以外のすべてを形作っている。

下書きは元に戻せるが、送信済みメッセージはそうではない

これは Front の API 設計の中で最も有用な単一の要素であり、もっと多くのヘルプデスクがこれを真似てほしいと思う。

下書きは第一級のリソースだ。作成し、編集し、削除することができる。作成は可能で、編集も削除もできる。送信はまったく異なる権限レベルを持つ別のエンドポイントだ。messages:send は drafts:write とは別物だ。そして一度メッセージが送信されれば、それで終わりだ。Front の API サーフェスのどこにも、編集エンドポイントも、送信取り消しも、リコールもない。

実務上の帰結は、無料で手に入る最良のセキュリティ機能だ。drafts:write と comments:write だけを持ち messages:send を持たないトークンを発行すれば、モデルが午前3時に何を決めようと、あなたのエージェントは物理的に顧客へメールを送ることができない。 これはプロンプトの指示でも、あなたが維持しなければならないガードレールでもない。API 自身が強制する権限だ。

私ならバージョン1をまさにこの形で出荷するだろう。チームに見える形で、投稿後も編集可能で、決して Front の外に出ない、内部向けのコメントだけを書くようにして。これは優れたサポート向け AI コパイロットであればどれも持っている形と同じであり、悪い回答が私的な恥で済むことと、悪い回答が顧客がすでに手にしているメールになってしまうこととの違いだ。

Hacker News の誰かが、それの別バージョンにかかるコストを次のように描写していた。

"LLM chatbots are a step forward for customer support. Well, ours started hallucinating a support phone number that while is a real number is not our number. Lots of people started calling which was a bad time for everyone. Especially the person's number it actually is. So maybe two steps forward and occasionally one back."

treis, Hacker News

履歴にはアクセスできるが、分単位で料金を払うことになる

まず良い知らせから。ローリングウィンドウはなく、どこまで過去へさかのぼれるかにも上限はない。会話一覧の取得は、カーソルによるページネーションで履歴全体を歩ける。

制約はスループットであり、それはプランによって形作られている。

ページは会話100件が上限だ。バースト許容量はプラン上限の半分で、それを超えると10分間の補充待ちのペナルティが発生する。会話検索は別枠で、グローバル予算の40%という上限が設けられており、エージェントのメインループが「検索してから行動する」形であれば、これは大きく効いてくる。Front は料金ページで、毎分・毎月あたり追加100リクエストにつき200ドルで余裕を追加販売している。

誰かにバックフィルを約束する前に、計算をしておこう。Professional プランで1ページあたり100件のペースで会話2年分を処理するのは、午後の片手間仕事ではなく、再開可能な状態を持つスケジュール済みのジョブだ。これは私が楽観的に見積もられているのを見てきたFront チャットボットプロジェクトすべての背後にある、同じ現実だ。

もう1つ知っておく価値のある制限がある。それが根拠にできる対象を左右するからだ。Front AI 自身の外部ナレッジソースはウェブサイトのクロールであり、3,000ページが上限で、r/CustomerSuccess の Front ユーザーは、その機能が登場したとき英語のみでしか動かなかったと指摘していた。

"Front recently added the ability to include external knowledge sources as well as previous conversations in the AI knowledge (go to Settings/Gear icon -> your workspace -> FrontAI -> Knowledge sources -> Add source -> External Sources). It currently only works for English pages."

tea_lean, r/CustomerSuccess, Reddit

設定パネルはその上限を具体的な形にしている。ソースの種類は2つ、それがリストのすべてだ。

API の上に構築することこそが、その限界を超える方法だ。あなたの検索(リトリーバル)層は、認証さえできれば何でも読めるからだ。それがルート4の利点であり、それは本物の利点だ。そしてそれこそが、どんなモデルを向ける前であってもAI 搭載のナレッジベースをきちんと整備しておく価値がある理由のすべてでもある。

ウェブフックは機能し、そして安全側に倒れて失敗する

Front は2種類のウェブフックを提供している。ルールウェブフックは UI で設定され、何かを手早くテストする手段だ。アプリケーションウェブフックはコードで管理する経路で、開発者アプリ上の機能として宣言され、HMAC で署名され、inbound_received、outbound_sent、assignee_changed、new_comment_added を含む固定のイベント一覧を購読する。

アーキテクチャを左右する3つの運用上の詳細がある。

• あなたのエンドポイントには応答に5秒の猶予しかない。常に、素早く確認応答し、非同期で処理すること。
• 連続して3回失敗すると、Front はウェブフックを無効化し、アプリの作成者にメールを送る。見逃した分の再送信はないので、自分自身で API と突き合わせて調整する必要がある。
• 一括操作と過去データのインポートは、ウェブフックを一切発火させない。それらが必要ならイベントエンドポイントをポーリングすること。

また、サイドバープラグインを出荷することもできる。これは会話の横に表示される iframe 化されたアプリで、Claude の出力を別の場所ではなく Front の UI の中に置きたい場合に使える。

私の見解: この API は優れている。スコープはよく考えられており、下書きと送信の分離はまさに欲しい境界であり、ドキュメントは注意すべき鋭利な部分について正直だ。これの上に構築することは十分実現可能だ。問題は常に「できるかどうか」ではなく、「Front が変更を出荷するたびに、18か月後もこれをまだ保守していたいと思うかどうか」だった。

1回の返信に実際いくらかかるのか

ここが私の予想が最も外れた部分であり、Front が競合と大きく異なる点だ。

Claude Sonnet 5は入力トークン100万につき2ドル、出力トークン100万につき10ドルだ。根拠のあるサポート返信は、スレッド、システムプロンプト、いくつかのヘルプセンター記事を含めるとおよそ6,000トークンの入力に、出力側は約250トークンとなる。これを0.015ドルとしよう。Claude Opus 5は5ドルと25ドルの料金で、同じ返信をおよそ0.036ドルに着地させる。プロンプトキャッシングはキャッシュされた入力を通常料金の10分の1で読むので、どちらもさらに下がる。

Front Autopilot は1会話あたり0.05ドルから始まる。

少しこれについて考えてみてほしい。他のヘルプデスクでこの試算をしたときは、ネイティブの AI は生のトークンコストの30倍もして、自前構築の論拠は自然と成り立った。Front のネイティブ料金はトークンコストのおよそ3倍であり、Opus は誤差の範囲内にある。 Front はまた、MCP サーバーについてアクションごとの課金を一切しない一方で、他社の比較可能なファーストパーティのブリッジは1アクションあたり1.5セントを課金している。

つまり、安いトークンという論拠はここではほとんど蒸発してしまい、残るのはプラットフォームの請求書だ。Front が実際に高くつくのはそこであり、Front 自身のユーザーもそれについて率直だ。

"Front is so expensive. We're up to 55 users now. Spending like 35k a year on it, just to make comments on emails. It's insane."

Coleybama, r/sysadmin, Reddit

また、何かを買う前に確認しておく価値のある価格の落とし穴もある。Professional は座席あたり65ドルだ。Copilot は20ドル、Smart QA は20ドル、Smart CSAT は10ドル。この3つすべてを Professional に積み上げると座席あたり115ドルになるが、Enterprise は105ドルでこの3つすべてを含んでいる。アシスト型の AI をきちんと導入するつもりなら、まず Enterprise を確認しよう。Autopilot はどちらにしても別枠の使用料のままだ。

自分の数字を入れてみよう。

これを現実的などんなチーム規模でも実行してみると、同じことが起きる。座席の請求書が AI の請求書を圧倒するのだ。 これはつまり、Claude パイプラインを構築して AI 支出を最適化することは、小さい数字を最適化しているだけで、大きい数字はそのままだということを意味する。これは、コストだけを理由にルート4に手を伸ばそうとしている誰に対しても私が伝えたい論拠であり、私たちがAI カスタマーサービスのコストの解説で解きほぐしているのと同じ罠だ。

正直に言えば、この反論としては、API 支出は現実のものであり、実際にそこで痛い目を見る人がいることも挙げられる。

"The problem with AI at this time is the API cost. It's so expensive and having them replace existing worker requires tools. You add cost snd tools, turns out not worth the savings overtime."

DeepPeeps, r/AIforOPS, Reddit

お金は実際どこに使われるのか

会話を読み、ナレッジベースから検索し、コメントとして返信を下書きし、行ったことを記録するバージョン1にとって、エンジニア15日分というのが私の正直な見積もりだ。その部分は難しくない。私はだいたいこれと同じものを一度ならず構築してきた。

難しい部分は4週目から始まり、それは決してモデルの問題ではない。エージェントがいつ黙っているべきかを知ることだ。Hacker News のあるエンジニアは、修正方法も含めたアーキテクチャ全体を、私がこれまで読んだ設計文書の多くよりも上手に描写していた。

"[...] On my side I now search for the most relevant Q&A pair based on the embedding of user's input and QA and jam as much as I can into the token limit. It provides accurate answers 99% of the time. If it can't find a suitable answer, it may create a plausible response on the spot, but that's getting rarer as training set grows. To prevent the bot from providing incomplete information, you can instruct it to ask users to contact support via email if it doesn't have enough information."

kozikow, Hacker News

真ん中の一文をもう一度読んでほしい。「その場でもっともらしい回答を作ってしまうことがある」というのは、リスクのすべてをわずか一文で言い表しており、そこで提示されている緩和策は、プロンプトの中の一つの指示にすぎない。それは機能しなくなるまでは機能するが、その失敗は設計上、静かに起きる。自信満々の間違った回答は、自信満々の正しい回答とまったく同じに見えるからだ。

信頼度ベースのルーティングはプロンプトではない。検索スコアリングであり、実際の結果に対して調整するしきい値であり、会話が手つかずのままに見えるようにして人間が普通に引き継げるようにする棄権パスだ。それは2週目ではなく6週目の話であり、だからこそチケットトリアージは、誰かがシステムプロンプトに付け加えた一文としてではなく、独立したカテゴリとして存在している。この作業の規模感をつかもうとしているなら、チケットトリアージを自動化する方法についての私たちのガイドが分類の層をカバーしており、チケットトリアージ向けの AIはすでにそれを構築した企業をカバーしている。

これを誤ったときのコストも決して机上の話ではない。

"I'm reminded of the Air Canada customer service chatbot. It completely made up a refund policy (and there are still people on HN who insist LLMs don't hallucinate) and a court ruled the company had to honor it [1]."

jmyeet, Hacker News

公平に言えば、Front の Autopilot はすでにこのエスカレーション部分の半分をこなしており、ある Front ユーザーはそれを率直に描写していた。エージェントは共有受信箱とドキュメントを読み、行き詰まったら問題はエスカレーションされる、と。そのハンドオフはプロダクトの中で確認でき、ボットが修理の手配を提案し、顧客がそれを受け入れると、実際の会話を作成し、人間がいつ返信するかを顧客に伝える。

Front のテストの仕組みが実際に何をカバーしているのか知っておく価値がある。これは人々が思い込みがちな部分だからだ。Front のシミュレーションは、プレイブック上のTestボタンだ。1つの仮想的なメッセージを入力すると、そのプレイブックが発火するかどうか、そして何を言うかのプレビューが表示される。これは有用ではあるが、あなた自身の解決済みの会話に対するリプレイではない。これらは異なる保証であり、後者こそが、そのエージェントが先月正しい対応ができていたかどうかを教えてくれるものだ。

私なら実際どう決めるか

最後の行は4つすべてに当てはまり、これはベータゆえの偶然ではない。Front のコネクタは、人間をループの中に保つように設計されている。1人のチームメンバーとしての ID、送信のたびの確認、毎分20送信。これらは優れたアシスタントの特性であり、自律エージェントを失格にする特性だ。この橋は優れているが、それが向いているのはあなたのチームであって、あなたのキューではない。

あなたが望んでいたのがティア1の会話が自然に解決されていくことだったなら、モデルは一度も欠けているピースではなかった。それはAI エージェントというカテゴリが埋めるために存在するギャップであり、選ぶ前に、それがルールベースのチャットボットとどう違うのかを理解しておく価値がある。

より広い分野については、最良の AI ヘルプデスクソフトウェアのまとめが、すでにそのスタックを構築した企業をカバーしており、Front 向けの最良の AIは、それをこの受信箱に特化して絞り込んでいる。

Front 向けの eesel AI

というわけで、ここまでのすべてを踏まえた、正直な提案だ。

eeselは Front App Store からインストールでき、本物の AI エージェントとしてあなたの共有受信箱に参加する。ウィジェットでもなければ、2つ目の受信箱でもない。会話を読み、返信を下書きして送信し、非公開コメントを追加し、チームメンバーへルーティングし、タグを更新し、メール、ウェブチャット、SMS にわたって SLA の期限を管理し、顧客が使ったのと同じチャネルで返信する。すでに構築済みの Front のルール、割り当てロジック、SLA ポリシーを尊重する。セットアップは30分以内で完了する。

この記事のテーマを踏まえると、特に重要な点は3つある。

第一に、モデルの問題があなたの問題ではなくなる。Anthropic は eesel が名指ししているプロバイダーの1つなので、「自分の Front の会話に Claude 級の推論を使いたい」という直感があったなら、OAuth アプリや検索(リトリーバル)層、エスカレーションロジックを自分で保守することなく、その結果を手にできる。

第二に、ナレッジの上限が動く。ユーザーガイド、Slack、社内ナレッジベース、過去のチケットのすべてから一度に回答を引き出したいと望んでいた、あの B2B チームを覚えているだろうか。eesel は過去の Front の会話、定型返信、ナレッジベースの記事を自動的に取り込み、公開ウェブサイトのクロールだけに限定されない。それが、ソースタイプ2つとそのすべて、との違いだ。

第三に、この記事全体がずっと巡っている問題について。あなたは、人間がすべての返信を承認する「下書きをレビューする」モードから始め、それを信頼できるようになった簡単な会話については自律モードに切り替える。そして、どのアクションが承認されどれが却下されたかを含め、ツールごとに何が行われたかを正確に確認できる。

料金は対応した Front の会話1件あたり0.40ドルで、1会話は、そこに含まれるすべての返信とフォローアップを含む1タスクを意味する。プラットフォーム料金なし、座席あたりの課金なし、最低利用料なしで、まず50ドル分の無料利用枠から始まる。月間1,000会話のうち200件をこちらにルーティングすれば、その200件分だけ支払うことになる。率直に言えば、結果にかかわらず対応した会話ごとに課金される。計算はどのみち実行されるからだ。そして月間デフォルトの上限は250ドルで、これがエージェントを一時停止させるので、悪い週が悪い請求書になることはない。

これこそ、購入検討者に実際に比較してほしい内容だ。エスカレーション、根拠付け、レポートがすでに組み込まれた状態での1会話0.40ドルと、座席にかかる費用に加えて Autopilot の1会話0.05ドル、そして自分で保有するバージョンのためのエンジニア15日分と際限のない保守作業、との比較だ。

自分自身の Front の会話でeesel を無料で試してほしい。まずネイティブ側を見たいなら、私たちのFront レビューはそれがどこで優れているかについて公正にまとめているし、座席の請求書こそがあなたが本当に解決したい問題なら、Front の代替がそこにある。

古いドキュメントを読んでいる場合に向けて、1つ注記しておく価値がある。Front AI Answersは、今でも参照されているのを目にするかもしれないレガシーの機能名であり、もはや購入できない。

最後に実務上の注意を一つ。この記事に書かれていることは何一つ、今日決断することをあなたに強いるものではない。今日の午後、Front の MCP サーバーを接続してみてほしい。それは無料であり、あなた自身の共有受信箱をすぐにより役立つものにしてくれるからだ。そのうえで、キューにエージェントを置きたいかどうかは、別の問いであり別の答えを持つ問題として、あらためて決めればいい。