7月18日、AWSが「How Smartsheet built a remote MCP server on AWS」と題した記事を公開した。この記事では、Smartsheetがプロジェクト管理・作業管理SaaSとして提供するプラットフォーム上で、AWS上にリモートMCPサーバーを構築した際のアーキテクチャ、セキュリティ、スケーリング、そしてAI最適化の実装詳細について詳しく紹介されている。
Model Context Protocol（MCP）は、AIエージェントが外部システムのデータや機能にアクセスするための標準プロトコルだ。Anthropicが2024年11月に公開して以来、エンタープライズ向けAIエージェント連携の文脈で急速に採用が進んでいる。Smartsheetはこの仕組みをAWS上で本番運用しており、GA（一般提供開始）から最初の4週間で週次ユーザー数が87%超の成長を記録した。
「1つのMCP層で内外を統一」するアーキテクチャ設計
この実装で最も特徴的なのは、自社の内部AIと外部AIクライアントが同一インフラを共有する設計だ。SmartsheetのAI機能「Smart Assist」と、外部クライアントであるAmazon QやClaude Desktopが、同じツール・同じ最適化スタックで動く。「一度構築すれば、あらゆるエージェントクライアントが即座に恩恵を受ける」というのが設計思想だ。
データパス上の主要AWSサービスは以下の通りだ。
- AWS Fargate（Amazon ECS）: ステートレスなMCPサーバーコンテナの実行基盤
- Amazon Kinesis Data Streams + Amazon Managed Service for Apache Flink: 変更イベントをAmazon S3に取り込むストリーム処理
- Amazon Bedrock + Amazon Neptune: LLM推論とナレッジグラフ（クロスプロジェクト分析に活用）
リクエストの流れは、AIクライアント → APIゲートウェイ層（AWS WAF、AWS Shield、ALB、OAuth検証）→ MCPサーバー → ドメインサービスまたはインテリジェンス層という構成だ。
AIトラフィック特有の「バースト」にどう対処したか
AIエージェントのトラフィックパターンは従来のAPIとは異なる。エージェントはタスク処理中に数秒間で複数のツールコールを連射し、モデルが推論する間は静寂になる。このバースト性への対応がスケーリング設計の核心だ。
ECS Auto Scalingはトラフィック量とコンピュート使用率を組み合わせたターゲット追跡ポリシーで動く。単純なプロキシではなく、LLM向けシリアライゼーション等のサーバーサイド処理を伴うため、コンピュート認識型のスケーリングが必要になる。
デプロイ側では、アクティブなエージェントセッションを中断しないローリングアップデートが求められる。コンテナイメージはAmazon ECRで管理され、ECSのデプロイサーキットブレーカーが障害発生時に自動的に前バージョンへロールバックする。また、最小リージョンから順次展開するというAWS Well-Architectedフレームワークの「影響半径を減らす」原則に従っている。カナリアテストは15分ごとに実行され、フル認証パスを含む複数ステップのMCPワークフローを検証する。
セキュリティ：レート制限の工夫が実用的
MCPサーバーはSmartsheetの本番APIと同等のセキュリティ基盤（AWS WAF、AWS Shield、VPCプライベートサブネット、mTLS、OAuth2プロキシ）の背後で動く。
AIトラフィック特有の課題として、企業ユーザーが共有プロキシ経由でアクセスするためIPベースのレート制限が機能しないという問題がある。Smartsheetはこれに対してAWS WAFによる3層のレート制限で対応している。
- 外縁での一括保護
- IDヘッダーのカスタム集計キーによるユーザー単位の計測
- 高コスト操作に対するパス別制御
ユーザー単位の計測により、IPではなくセッション個別に流量が管理される。
AI消費向けの3つの最適化
トークン消費はエンタープライズAI運用のコスト直結要素だ。Smartsheetは3つのレベルで最適化を実装している。
1. プログレッシブディスクロージャー（段階的なデータ開示）
ツールレスポンスはトークンバジェット内に収まるよう動的に制御される。例えば5列のシートは15列のシートより多くの行を返せるが、合計はバジェット内に収まる。レスポンスにはis_sampled（データが切り捨てられたか）、rows_in_sheet（総行数）、rows_actual（返却行数）、filters_applied（適用フィルター）といったメタデータが含まれ、モデルがフォローアップクエリの要否を判断できる。
2. 強型付きツールスキーマ
各ツールはPydanticモデルから生成したJSON SchemaをMCPのツールディスカバリー経由で公開する。カラム名は実行前に実際のシートと照合され、不一致時は黙って失敗するのではなく有効な選択肢を含む構造化エラーを返す。これによりLLMのハルシネーション（パラメータ名の誤生成等）を境界で遮断する。
3. 独自シリアライゼーション形式
JSONの構造オーバーヘッド（括弧、クォート、繰り返しキー）は通常レスポンスのトークン数の15〜25%を占める。Smartsheetは独自フォーマットを構築し、キー名を1回だけ定義してデリミタで区切る方式に変更した。代表的な33件フィルタクエリの場合、JSON比で約35%のトークン削減（約6,000トークン → 約3,900トークン）を達成した。行数が増えるほど差は拡大する。これら最適化の累積効果として、内部テレメトリによれば累計30億トークン以上の削減を実現しているとされる。
ガバナンスとオブザーバビリティ
アクセス制御は組織単位で3段階に設定可能だ。AIアクセスのグローバル有効化、読み取り専用操作への制限、フルな書き込み・破壊的操作の許可、のいずれかを組織が選択する。ツールにはreadOnlyHintやdestructiveHintといったMCPプロトコルアノテーションが付与されており、AIクライアントが適切な確認フローを自動適用できる。
オブザーバビリティはOpenTelemetryでログ・トレース・メトリクスを収集し、Amazon KinesisでAmazon OpenSearch Serviceにストリーム転送する構成だ。Datadogでツール単位のAPM可視性を確保し、PagerDutyでインシデントルーティングを処理している。
非決定的なAIワークフローのテスト
従来のAPIと異なり、MCPツールのレスポンスはLLMを通過してから最終出力になる。この非決定性が「正しい」テストの定義を変える。Smartsheetはワークスペース作成・データ書き込み・クエリ・モデル解釈検証といった現実的なビジネスシナリオを含むエンドツーエンドテストをCI/CDパイプライン（GitLab CI、AWS上でのランナー実行）に組み込み、各本番リージョンに対してカナリアテストとして継続実行している。
詳細はHow Smartsheet built a remote MCP server on AWSを参照していただきたい。
