Smartsheet が AWS で MCP サーバー構築

Smartsheet は、数十万の組織が信頼するエンタープライズ向けワーク管理プラットフォームです。企業チームが AI エージェントの導入を進める中で、これらのエージェントは Smartsheet などのシステム内部データへの構造化されたアクセスを必要としますが、既存のシステムの多くはそのような用途には対応していません。

このギャップを埋めるため、Smartsheet は AWS 上にリモート Model Context Protocol (MCP) サーバーを構築しました。これにより、AI クライアントは Smartsheet のデータや機能に直接アクセスできるようになります。Amazon Quick や Claude Desktop といった AI アシスタントを使えば、自然言語で Smartsheet の機能を操作できます。プロジェクトデータの分析、タスクの更新、シート作成、ワークスペース管理などが、言葉による指示だけで実行可能です。

企業ではまた、人間の指示を待たずに稼働する業務向けにカスタム AI エージェントも構築されています。これらのエージェントは MCP を介して Smartsheet 上で連携しながら、自律的に役割を果たします。具体的には要件の収集、タスクの引き受け、テスト結果の添付、ドキュメントのドラフト作成などが該当します。これらは人間が普段使うシート上で行われるため、従来数週間かかっていたワークフローを数日、あるいは数時間に圧縮することが可能になります。

MCP サーバーは、Smartsheet の既存 API と中央集権的なインテリジェンス層に接続します。さらにその上に AI 最適化されたインターフェースを追加し、トークンコストの削減、ハルシネーション（幻覚）の防止、そして大規模言語モデル（LLM）がエンタープライズデータと確実に連携できる仕組みを実現しています。本格的な稼働以降、これらの最適化により Smartsheet は内部テレメトリデータに基づき、30 億トークン以上の削減を達成しました。

本稿では、Smartsheet のリモート MCP アーキテクチャの全体像を解説し、特にその背後にある AWS インフラストラクチャに焦点を当てます。ここではセキュリティ、ガバナンス、スケーリングとデプロイメント、そして Smartsheet が AWS 上で構築した AI 固有の最適化技術について取り上げます。

アーキテクチャ

1 つの MCP レイヤが、内部および外部のエージェント双方に対応します。Smartsheet 独自の Smart Assist（製品内 AI エクスペリエンス）も、Amazon QuickSight などの外部接続 AI クライアントも、同じインフラストラクチャ上で動作し、共通のツール、最適化手法、そしてインテリジェンススタックを利用しています。この同等性は意図的なアーキテクチャ上の選択です。「一度構築すれば、すべてのエージェント型クライアントが即座に恩恵を受ける」という設計思想に基づいています。

データパスにおいてアーキテクチャ上極めて重要な AWS サービスは以下の通りです：

Smartsheet のリモート MCP サーバー構築は、AWS Fargate を活用したステートレスサーバーコンテナ（Amazon ECS）を基盤としています。

データ取り込みには Amazon Kinesis Data Streams と Amazon Managed Service for Apache Flink を採用し、変更イベントを Amazon S3 へ転送します。また、LLM の推論処理やクロスプロジェクトの洞察を提供する知識グラフには、それぞれ Amazon Bedrock と Amazon Neptune を利用しています。

詳細なアーキテクチャの流れは以下の通りです。

• AI クライアントから API ゲートウェイ層を経て MCP サーバーへ：リクエストはまず AWS WAF、AWS Shield、AWS Application Load Balancer、そして OAuth 認証による検証層を通過し、その後 AWS Fargate 上で稼働する MCP サーバーに到達します。

• MCP サーバーからドメインサービスへ：トランザクション処理を行うため、MCP サーバーは Smartsheet のドメインサービスの API を呼び出します。

• MCP サーバーからインテリジェンス層へ：クロスプロジェクト型のエージェントによる洞察を得るため、Amazon Neptune と Databricks で構築されたインテリジェンス層を照会します。

• ドメインサービスからインテリジェンス層へ：変更イベントは Amazon Kinesis と Apache Flink を経由してストリーミングされ、Amazon S3 にバックアップされたインテリジェンス層に蓄積されます。このインテリジェンス層はメダリオンのアーキテクチャを採用しています。

エッジ保護、コンテナレジストリ、観測性（オバザビリティ）、シークレット管理などの関連サービスについては、後続の各セクションで詳しく説明します。

デプロイとスケーリング

スケーリングの観点では、AI トラフィックは従来のリクエストパターンとは一線を画します。エージェントは自律的にツール呼び出しのシーケンスを調整し、タスクを処理する間に数秒間に複数のリクエストを発行しますが、モデルが推論を行う間は静寂に戻ります。このバースト性の高いパターンに対応するには、突発的な急増と持続的なスループットの両方に柔軟に応答できるスケーリング戦略が必要です。

こうしたパターンを処理し検証するために、Smartsheet は MCP サーバーを AWS Fargate 上で動作する Amazon ECS 上に構築しました。ECS の自動スケーリング機能では、トラフィック量と計算リソースの使用率を組み合わせたターゲット追跡ポリシーを採用しています。各リクエストが単なるプロキシではなく、LLM 最適化されたシリアライゼーションなどのサーバーサイド処理を伴うため、計算リソースを意識したスケーリングが不可欠です。本番環境に近いトラフィックパターンでの徹底的な負荷テストにより、インフラがエージェントのバーストを吸収してもパフォーマンスが低下しないことが実証されました。

デプロイの側面では、アクティブなエージェントセッションを中断せずに更新を配信することも同様に重要です。コンテナイメージは Amazon Elastic Container Registry（Amazon ECR）に保存され、継続的インテグレーション・継続的デリバリー（CI/CD）パイプラインを通じて、多層の安全網で展開されます。ECS のデプロイメント用サーキットブレーカーが展開中に失敗したコンテナを検知すると、自動的に直前の安定バージョンへロールバックします。手動での介入は不要であり、顧客への影響も回避できます。

デプロイは、影響範囲を最小限に抑えるという AWS Well-Architected の原則に従い、まず最も小規模なリージョンから順次展開されます。各リージョンの展開後には、自動化されたエンドツーエンドテストが実行され、本番環境におけるツールの動作を検証します。

カナリテストは 15 分ごとに実行され、完全な認証およびゲートウェイ経路を介したマルチステップ MCP ワークフローを実行します。その結果は監視スタックにフィードバックされるため、顧客からの報告が来る前にパフォーマンスの低下を検知することが可能です。ECS Fargate と ALB を組み合わせた構成の詳細は、AWS による MCP サーバーのデプロイガイド に記載されています。

ガバナンスと観測性

エンタープライズ顧客にとって、AI の導入における最大の障壁はガバナンスです。Smartsheet ではこれをツールフレームワーク自体に組み込みました。アクセス制御、エラーハンドリング、監査証跡は、すべてのツールにデフォルトで備わっています。

アクセス権限は組織ごとに階層化されています。管理者は、AI へのアクセスを全社的に有効にするか、破壊的な操作のみを制限するか、あるいは完全な書き込みおよび破壊的機能まで開放するかを選択でき、各組織が自らの導入ペースをコントロールできます。ツールには readOnlyHint や destructiveHint といった MCP プロトコルの注釈が付与されており、AI クライアントはこれに基づいて自動的に適切な確認フローを適用します。

サーバーは、リクエストのライフサイクル全体にわたって OpenTelemetry シグナル（ログ、トレース、メトリクス）を出力します。すべてのツール呼び出しでは、プライバシーの制約内で可能な限り最大限のコンテキスト（ユーザー、組織、ツール名、結果など）を取得し記録しています。これにより、利用状況の分析やコンプライアンス監査の基盤が整います。

エージェントからのトラフィックは、従来の API トラフィックよりも監視が困難です。1 つのユーザーリクエストが複数のツール呼び出し連鎖を生み出すことがあり、障害が発生した場合も原因を遡って数段階先まで追跡する必要があります。Smartsheet では、エージェントファーストなアイデンティティとトレーシングを導入し、ツールチェーン全体にわたるコンテキストの相関付けを通じて観測性を強化しています。ログは Amazon Kinesis を経由して Amazon OpenSearch Service にストリーミングされ、AWS Observability Best Practices のパターンに従って処理されます。インフラストラクチャのメトリクスは Amazon CloudWatch で可視化されています。また、Datadog によってツールごとのアプリケーションパフォーマンス監視（APM）が可能となり、PagerDuty がインシデントのルーティングを担っています。

すべての呼び出しでは、Amazon Simple Queue Service（Amazon SQS）を通じて構造化された分析イベントが Intelligence Layer へ送信されます。これによりフィードバックループが完結し、実際の稼働データに基づいて優先すべきツールの選定や、最適化戦略の実負荷下での効果検証が可能になります。

AI エージェントの通信を保護する

MCP サーバーは、Smartsheet の本番 API と同じセキュリティインフラストラクチャの背後で稼働しています。エッジでは AWS WAF と AWS Shield が防御を行い、仮想プライベートクラウド（VPC）内のプライベートサブネットがネットワークを隔離します。サービス間の通信には相互 TLS（mTLS）を採用し、認証されていないリクエストは計算リソースに到達する前に OAuth2 プロキシによって拒否されます。MCP サーバーは、AWS の MCP サーバーデプロイメントガイダンス に基づく「多層防御」のモデルに従っています。

API ゲートウェイレイヤーが認証とスコープ検証を担当し、ドメインサービスではより細粒度な権限管理を行います。つまり、UI を通じてシートにアクセスできないユーザーは、MCP 経由でもそのシートにはアクセスできません。

AI による通信には、特有のレート制限（速度制御）の課題が伴います。ユーザーの単一の質問に対して、数秒のうちに複数のツール呼び出しが発生する可能性があるからです。また、多くの企業ユーザーが共有された社内プロキシの背後にいるため、IP アドレスに基づく従来のレート制限は信頼性が低くなります。

この課題に対処するため、Smartsheet は AWS WAF を活用した多層型のレート制限を実装しました。3 つのレイヤーが連携して機能します。まず外側のエッジで包括的な保護を行い、ID ヘッダーのカスタム集計キーを用いてユーザーごとの使用量をメーターリングし、さらに高負荷な操作についてはパスごとの制御を設けます。ユーザーごとのメーターリングとは、IP アドレス単位でプールするのではなく、セッションごとに個別にカウントする仕組みです。この多層型のレート制限は、AWS WAF のレートベースルールにおける 3 つの最重要項目のパターンに従っています。

非決定性の AI ワークフローのテスト

Smartsheet では従来通り、単体テスト、統合テスト、ツールレベルでの検証という標準的なテストレイヤーを維持しています。しかし、MCP サーバーは従来の API サービスにはない独自の課題を生み出します。通常の API のレスポンスは UI によって決定論的にレンダリングされますが、MCP ツールのレスポンスは一度 LLM を経由します。モデルがそれを読み取り、推論を行い、最終的にユーザーが目にする内容を生成するのです。この非決定性のレイヤーが存在することで、「テストで正しいとは何か」という定義そのものが変化します。

Smartsheet は、LLM をループに組み込んだエンドツーエンドのワークフローテストに多大な投資を行っています。これらのテストでは、ワークスペースの作成やデータ入力、結果の照会、そしてモデルによる解釈がエンドユーザーにとって妥当かどうかを検証するなど、現実的なビジネスシナリオをシミュレートします。これらは CI/CD パイプライン（AWS にホストされたランナーを持つ GitLab CI）で実行されるほか、各プロダクション AWS リージョンに対してカナリテストとして継続的に実施されています。

AI 利用効率の最適化

企業が AI エージェントの導入を拡大するにつれ、トークンの消費量がコスト増の主要因となっています。LLM への呼び出しごとにツール応答のコストが発生し、コンテキストウィンドウの容量も奪われます。現在、多くの MCP ツール呼び出しはサブエージェントによる調整なしに実行されており、エージェントが一度に一つのツールを直接呼び出して、ステップごとの推論を行っています。ツール設計に知恵がなければ、処理はすぐに遅くなり、高額になり、エラーも多発します。各ツール呼び出しは独立して効率的である必要があるため、Smartsheet では以下の 3 つのレベルで最適化を図っています。

• トークン消費をレスポンスごとに制限する段階的開示（プログレッシブ・ディスクロージャー）
• 幻覚的なパラメータや無駄な呼び出しを防ぐための厳密な型付けされたツールスキーマ
• データ量の多い応答においてトークン数を 35〜47% 削減する独自シリアライゼーション形式

段階的開示

各ツールの応答は、あらかじめ設定されたトークン予算に収まるように設計されています。サーバーは列数とデータ密度に基づいて、レスポンスに含まれる行数を動的に計算します。例えば、5 列のシートなら 15 列のシートよりも多くの行を返すことができますが、総量は予算内に抑えられます。シートの行数が 50 行であっても 5 万行であっても、応答サイズは常に一定範囲内に保たれます。モデルはまず全体像を把握し、ユーザーの具体的な質問に基づいてフィルタリングをかけて詳細へと絞り込んでいきます。

メタデータフィールドは、モデルに対して何が起こったかを正確に伝えます。is_sampled はデータが切り捨てられたかどうかを示し、rows_in_sheet はシートの行数全体を、rows_actual は実際に返された行数を、そして filters_applied は適用中のフィルタの内容を記述します。モデルはこの情報をもとに、完全な状況を把握できているか、それともフィルタを使ってクエリを絞り込む必要があるかを判断します。

段階的な開示（プログレッシブ・ディスクロージャー）はサーバー側で決定されます。MCP サーバーが予算管理やサンプリングを担当し、返されるメタデータを通じて AI クライアントに信号を送ることで、クライアント自身がフォローアップクエリを調整できるようにします。

*図 2: 段階的な開示の実際の様子。AI クライアントはメタデータ付きでサンプリングされたデータを受け取り、その後、ターゲットを絞ったフォローアップリクエストを行います。

LLM を現実に引き戻す：スキーマ駆動型のツール契約

LLM を現実（グランド）に留めておくことは極めて重要です。制約がないと、モデルはパラメータ名をでっち上げたり、存在しない演算子を発明したりして、失敗した呼び出しにトークンを浪費します。

各ツールは、Pydantic モデルから生成された厳格な JSON スキーマを MCP のツールディスカバリーを通じて公開しています。パラメータは有効な列挙型（enum）に制限され、実行前に列名が実際のシートと照合されます。不一致が生じた場合は、静かに失敗するのではなく、有効な選択肢を含む構造化されたエラーを返します。

スキーマ検証によって、境界面で hallucination（幻覚）を検知できるため、エージェントは試行錯誤なしにツールカタログを確実にナビゲートできるようになります。

トークン効率を高めるシリアライゼーション

JSON の構造的オーバーヘッド（中括弧、引用符、キー名の繰り返し）は、通常レスポンスのトークン数の 15〜25% を占めます。数千行にわたるスプレッドシートデータを返すサーバーの場合、このオーバーヘッドがすぐに膨らんでしまいます。

Smartsheet はこのオーバーヘッドを解消する独自シリアライゼーション形式を開発しました。キー名は各レコードごとに繰り返されるのではなく、一度だけ記述されます。また、構文自体もより効率的にトークン化できる区切り文字に置き換えられています。代表的な 33 件のフィルタリングクエリでは、最適化されたレスポンスは約 3,900 トークンに対し、同等の JSON は 6,000 トークンを超え、同じ情報を伝えるのに約 35% もトークンを削減できました。1,000 行に達するとその差はさらに広がります。JSON ではオブジェクトごとにキー名が繰り返される一方、最適化形式では一度だけ宣言すれば済むからです。

Smartsheet の今後の展望

現在、AI エージェントは MCP を通じて Smartsheet と統合されています。一般提供（GA）から最初の 4 週間で、ユーザー数は前週比で 87% 以上増加しました。

MCP はあくまで配信レイヤーです。次なるステップは、接続点そのものに知能を持たせることです。例えば、利用する個人やチーム、組織に合わせて動的に形を変えるリソースが挙げられます。また、ワークフロー上で自律的に動作するエージェントや、専門家が各ステップでゼロから思考を始めるのではなく、推論を互いに引き継げるルーティングレイバーもその一例です。MCP 接続はそのままに、顧客ごとに異なる知能を提供し、デプロイの手間は一切不要です。

AWS は、こうした新興するエージェント要件に対応するため、インフラの進化を続けています。Amazon Bedrock AgentCore では、実行環境の提供やリソースの発見、パーソナライゼーション、ガバナンスといった機能が標準で用意されています。Smartsheet は引き続き、AWS のこうした機能を積極的に採用し、自社のニーズに合わせて機能強化を進めています。

MCP プロトコル自体も進化を続けています。Elicitations により、破壊的な操作を実行する前に人間による確認（ヒューマン・イン・ザ・ループ）が可能になりました。また、MCP Apps を活用すれば、対話型 UI を AI 会話の中に直接組み込むことができます。さらに Tasks は、非同期で長時間実行されるオペレーションをサポートします。Smartsheet では、これらの機能が成熟するにつれて導入を検討しています。

AI の進化は速いです。AWS を基盤にすることで、新しいプロトコルやモデル、あるいは全く新しいエージェントアーキテクチャが登場しても、常にそのペースに合わせていくためのインフラを提供できます。

Smartsheet の MCP サーバーへ接続するには、AWS Marketplace のリストページをご覧ください。または、Smartsheet MCP ドキュメント を参照してください。

執筆者について

Vasil Kosturski

Vasil は Smartsheet のシニアエンジニアであり、同社のリモート MCP サーバーを概念段階から一般提供（GA）まで導いたチームのリーダーを務めています。この投稿で取り上げるシステム設計、AWS におけるアーキテクチャ構築、そして AI に特化した最適化の実現も彼が主導しました。より広範な視点では、Smartsheet の開発者エコシステムの全体に関わり、パブリック API プラットフォームの整備にも携わっています。

Smartsheet 入社前は、分散システムとリアルタイムデータ処理に 10 年以上従事し、直近では Sportradar でリードデベロッパーとして、大量データを扱う Kafka ベースのイベント処理パイプラインを構築していました。現在はブルガリアのプロヴディフに拠点を置いています。