MCP Stateless HTTP｜2.1.0更新と小さな連携サービス設計

8月3日の更新を切り分ける：個別パッケージ2.1.0と7月28日の大きな更新

今回の話は、似た日付の二つの発表を分けて読むことから始まります。8月3日に公開された Voltagent の投稿が伝えているのは、npm パッケージ「@voltagent/mcp-server 2.1.0」の更新です。投稿には Stateless Streamable HTTP、サーバーレスな実行先への組み込み、セッション保存領域が不要になること、公式 MCP SDK 1.30.0 とリクエスト単位のストリーミング対応が記されています。ここから確認できるのは、ひとつのサーバー実装と利用ライブラリの変更であり、MCP 全体が 2.1.0 になったという意味ではありません。出典は Voltagent の投稿 です。

一方、7月28日に ClaudeDevs が告知したのは、MCP 仕様そのものの「2026-07-28」です。MCP がプロトコル層で状態を持たない設計になり、リモートサーバーを配置・拡張しやすくする大きな更新だと説明されています。公式ブログは、従来の初期化・セッション識別子を前提とする流れから、各リクエストが自分で必要な情報を持つ流れへ移ること、負荷分散先を固定しなくてよいことを詳しく説明しています。告知本文は ClaudeDevs の投稿、背景の解説は 公式リリース候補解説 で確認できます。

事実・推論・提案を分けて読む

事実として扱えるのは、各投稿と仕様に書かれた版番号、通信上の扱い、SDK の対応内容です。そこから「運用費が必ず下がる」「応答が必ず速くなる」と結論づけるのは推論です。サーバー台数を増やしやすくなる可能性はありますが、データベース、外部サービスの制限、認証、監視、問い合わせ対応は別に残ります。この記事ではこの線引きを崩さず、売り方の話は編集上の提案として示します。

補足動画の候補は YouTube収集結果 にまとまっています。ただし動画の本数や紹介順を仕様の根拠にはせず、版番号と通信方式の確認には一次情報を使います。更新直後は解説記事の表現が先行しやすいため、個別パッケージの説明と公式仕様の説明を同じ段落に混ぜないことが、読者の誤解を防ぎます。

読者が持ち帰るべき更新の意味

更新の価値を技術の新しさだけで説明すると、顧客には導入理由が伝わりません。顧客が知りたいのは、いま手作業で行っているどの確認を、何分短くでき、どのデータを扱い、失敗したとき誰が戻すのかです。したがって、以降では仕様変更を「接続を提供する商品」ではなく「仕事の前後をつなぐ一機能」の材料として読み替えます。

たとえば、問い合わせを受けてから社内台帳を検索し、回答案を作り、担当者が確認する流れがあるとします。MCP はその間のデータ受け渡しを揃える手段ですが、顧客が買うのは手段ではなく、確認にかかる時間の短縮と判断の漏れを見つけやすくする仕組みです。対象業務を狭く切るほど、価値を測る指標も保守の境界も明確になります。

接続状態を持たない方式で変わる運用コストと、変わらない注意点

Stateless は「サービス全体が何も覚えない」という意味ではありません。通信の一回の依頼を、前の接続の記憶に頼らず処理できる、という層の話です。公式の 2026-07-28 仕様のトランスポート説明 では、各メッセージを一つの MCP エンドポイントへの HTTP POST として運び、返信は JSON またはその依頼に紐づく SSE ストリームで返す形が示されています。状態が必要な業務なら、買い物かご ID や案件 ID のような明示的な識別子を引数にして、必要なデータを別に管理します。

従来、接続ごとの識別子を特定の実行先へ追従させるため、固定振り分けや共有セッション保管を用意することがありました。状態を通信層から外せると、同じ処理を複数の実行先へ回しやすくなり、増減や障害時の切り分けが単純になります。ただし削れるのは「接続に紐づく管理」の一部です。データベース接続、外部 API の制限、監視、権限確認、重複実行への対策は残るため、月額を安くし過ぎる根拠にはなりません。

見積もりに入れる五つの費用

小さな連携サービスの見積もりでは、通信方式だけでなく、依頼を受けてから顧客へ結果を返すまでの仕事を分解します。接続状態を持たないことによる余白は、二つ目以降の利用者を増やすときの設計負担を抑える材料にはなりますが、最初の顧客の要件整理やデータ確認を無料にする理由ではありません。次の五項目を、初期費用・月額・利用量のどこに含めるか決めます。

1. 接続先の仕様を読み、入力と出力を決める時間。
2. データの変換、項目名の対応、失敗時の表示を決める時間。
3. 正常系、入力不足、権限不足、通信断を確認する試験時間。
4. 利用量、外部サービス料金、保存領域など利用に応じて増える原価。
5. 稼働確認、問い合わせ、軽微な変更、障害時の調査に充てる保守時間。

この分解をしておけば、「接続が簡単になったので安くできます」という曖昧な提案を避けられます。価格を下げるなら、どの作業を含めないのか、どの条件で追加料金になるのかも同じ表に書きます。

状態を明示的に残す場合

通信層が状態を持たなくても、業務には状態が必要です。たとえば「請求書を確認中」「担当者の承認待ち」「外部サービスへの送信済み」という情報は、依頼をまたいで残さなければなりません。ここを曖昧にすると、再接続後に同じ請求書を二度送る、別顧客の案件を取り違える、といった事故につながります。

状態を扱うときは、次の順番で決めると範囲がぶれません。

1. 一つの案件を識別する ID と、誰の案件かを保存する。
2. 各処理が受け取る ID、現在の状態、更新日時を定義する。
3. 同じ依頼が再送されたときの扱いを、再利用・拒否・再計算から選ぶ。
4. 保存期間、削除依頼、担当者が手で直せる範囲を決める。

この設計は、Stateless の利点を打ち消すものではありません。通信の状態と業務の状態を分ければ、実行先は分散しながら、必要な業務記録だけを顧客単位で管理できます。

エンジニアが売れる一機能の選び方：業務の前後をつなぐ連携サービス

「MCPを導入します」という提案は、顧客から見ると何が変わるのか分かりにくく、料金の比較もできません。売り物にするのは、データを受け取る場所、判断に必要な情報、返す結果が一つの流れに収まる機能です。広い業務を丸ごと置き換えるのではなく、担当者が毎日繰り返す確認を一つ選び、導入前後の時間とミスの数を比べます。

業界データを検索する

業界データの検索は、入力と出力を説明しやすい題材です。顧客が指定した企業名、地域、品目、期間を受け取り、公開情報や社内で許可された台帳を検索し、根拠となる URL と取得日を添えて返します。検索結果を丸ごと渡すのではなく、「条件に一致した候補」「一致しなかった項目」「人が確認すべき点」に分けると、担当者が次に行う作業まで見えます。

この機能の価値は、検索速度だけではありません。調査条件の抜けを減らし、同じ条件で再確認できることにあります。初期費用には検索条件と表示形式の整理を含め、月額にはデータ源の変更確認と結果の不具合調査を含める、といった境界を置けます。公開情報の利用条件や取得頻度は相手ごとに異なるため、使える範囲を先に書面化します。

見積もりの根拠をまとめる

見積もり作成では、商品名、数量、単価、納期、過去案件の条件などが複数の場所に分かれがちです。入力された案件情報から参照すべき資料を探し、計算に使った項目と不足情報をまとめ、最終金額は担当者が確認してから確定する形にします。ここでは「金額を決める機能」ではなく、「金額の根拠を確認しやすくする機能」と位置づけることが重要です。

売上に直結するため、削減時間を測りやすい一方、誤った単価が混ざった場合の影響も大きくなります。価格表の更新者、適用期間、例外値の扱いを明示し、結果には参照元と計算日時を残します。担当者の承認を必須にするなら、その確認画面と差し戻しの扱いを初期費用に含め、単なる検索機能と同じ金額で扱わないようにします。

問い合わせを分類する

問い合わせ分類は、受信した文章から種類、緊急度、担当部署、次に必要な情報を整理する機能です。入力は本文と最低限の顧客情報、出力は分類結果と根拠、確認が必要な項目です。最初から返信まで任せるのではなく、分類後に人が確認する流れにすれば、誤分類があったときの修正方法と責任範囲を説明できます。

この機能では正解率だけでなく、分類できない問い合わせをどれだけ早く人へ渡せるかが重要です。月額に含める分類項目の数、判定の見直し回数、過去データの再分類を分けておけば、顧客の要望が膨らんでも値付けを保てます。問い合わせの内容には個人情報が含まれる場合があるため、保存期間と閲覧できる担当者を最初に確認します。

狭い機能を商品として定義する

候補を一つに絞ったら、次の順番で一枚の説明に落とし込みます。

1. 顧客が今どの画面や資料を見ているかを一文で書く。
2. 受け取る入力を三つ以内に絞り、入力不足時の扱いを決める。
3. 返す結果を一つの画面または一つの報告書にまとめる。
4. 人が確認する箇所と、提供側が調査する箇所を分ける。
5. 成功を「何分短縮」「何件処理」「何回の差し戻し」と数値化する。

この一枚があれば、接続方式の説明を長くしなくても、顧客は自分の業務との関係を判断できます。機能を増やす提案は、最初の測定で価値が確認できた後に行います。最初から検索、分類、登録を全部含めると、どの部分に料金を払っているのかが曖昧になります。

初期費用と月額の作り方：原価・利用量・保守範囲を分けて料金を示す

Stateless Streamable HTTP を使えることは、料金表の一項目ではなく、提供範囲を整理するための材料です。価格は「通信が新しいから高い」「接続が簡単だから安い」と決めず、顧客固有の作業と利用者が増えても共通化できる作業を分けて考えます。初期費用は一度だけ発生する設計・接続・試験・引き継ぎ、月額は稼働確認・問い合わせ・小さな変更、利用量に応じた原価は別枠にします。

計算の土台は、次の二つの式で十分です。初期費用は「要件整理時間＋接続と変換の時間＋試験時間＋引き継ぎ時間」に自分の時間単価を掛け、月額の下限は「保守時間×時間単価＋固定費＋障害対応の予備＋利用量原価」で求めます。ここに利益を加え、顧客が削減できる時間の価値を上限の目安にします。式を見せれば、値下げ交渉でも何を削るのかを話し合えます。

仮置き価格の例

以下は相場の断定ではなく、個人エンジニアが最初の提案を作るための仮置きです。顧客の作業時間、接続先の料金、利用量、対応時間に合わせて再計算してください。たとえば、設計・接続・試験を合計18時間、時間単価を1万円と置くなら、初期費用は18万円が出発点になります。月に2時間の保守、固定費と障害対応の予備を合わせて3万円、1,000件を超える依頼や外部サービスの従量料金は実費とする設計も考えられます。

基本枠の数字は、実際に想定する件数から決めます。少ない利用量に高い固定費を載せると導入されにくく、上限なしで月額を固定すると、利用が伸びたときに提供側が損をします。最初の顧客には小さめの枠で始め、14日間の実測後に枠と価格を改めて提案すると、推測だけで値段を決めずに済みます。

顧客の削減時間から上限を決める

顧客の担当者が一か月に20時間を調査へ使い、時間の価値を4,000円と置くなら、削減できる時間の価値は8万円です。そこから全額を利用料にするのではなく、残る確認作業、誤りのリスク、導入後の学習負担を差し引いて、月額3万から5万円を仮の提案範囲にする、といった考え方ができます。数字は顧客の業種や代替手段で変わるため、提案書には計算に使った時間と単価を明記します。

「何分短くなったか」だけでなく、「何件を人が確認したか」「差し戻しが何回減ったか」も記録します。時間短縮が小さくても、根拠の確認漏れが減るなら価値はあります。反対に、処理が速くなっても確認作業が増えるなら、価格を上げる前に機能の範囲を見直すべきです。

料金表に含める保守境界

月額保守で曖昧になりやすいのは、「少しの変更」と「別の開発」の境目です。たとえば、接続先の一時的な応答失敗の調査、月一回の利用量報告、既存項目の対応先を一時間以内で直す作業は含める一方、新しいデータ源の追加、業務ルールの変更、出力画面の作り直し、過去データの一括修正は別料金にします。顧客が困る場面を想像し、含む・含まない・追加になる条件を表にします。

あわせて、連絡を受け付ける時間帯、一次回答までの目安、障害と要望の優先順位、顧客側に確認してもらう情報を決めます。接続状態の管理が軽くなっても、問い合わせに答える時間は自然には減りません。保守を売るなら、作業時間と対応範囲を月額の根拠として説明できる状態にしておきます。

最初の14日で行う検証：速度・再接続・障害・権限・採算を見る

最初の14日は、完成品を作り込む期間ではなく、狭い一機能が売れるかを測る期間です。正常な入力を一度通して終わりにせず、接続が切れたとき、同じ依頼が再送されたとき、権限が足りないとき、利用量が想定を超えたときに、顧客と提供側のどちらが何をするかを確認します。速度の改善は測定結果として扱い、仕様から自動的に導かれる効果とは分けて記録します。

14日間の検証で行う順番

1. 1〜2日目は、対象業務を一つに固定し、導入前の処理時間、件数、差し戻し、担当者の確認箇所を記録する。機能を追加せず、入力と出力の境界を決める。
2. 3〜5日目は、正常な入力だけでなく、空欄、表記揺れ、古い日付、想定外の値を試す。中央値と95パーセンタイルの応答時間、処理成功率、手直し時間を残す。
3. 6〜8日目は、通信を途中で切り、同じ依頼を再送し、外部サービスが一時停止した場合を確認する。二重登録を避ける方法と、担当者へ返すエラー表示を決める。
4. 9〜11日目は、顧客ごとの権限、期限切れの認証情報、閲覧範囲外のデータを確認する。顧客Aの依頼から顧客Bの結果が見えないことを、実データに近い条件で検証する。
5. 12〜14日目は、総件数、外部サービスの利用料金、調査と問い合わせの時間、顧客が削減できた時間を集計する。月額、利用量上限、保守時間を再計算し、継続・値上げ・撤退の条件を提示する。

順番を守る理由は、採算だけを先に見ると不具合対応の時間を見落とし、速度だけを先に見ると顧客の確認負担を見落とすからです。各日で記録する項目を同じにし、顧客の感想だけでなく処理件数と作業時間を残します。14日で十分な件数が集まらなければ、期間を延ばす前に測定対象を狭くします。

続ける・値上げする・やめる基準

判定の数値はサービスごとに違うため、最初は仮の基準を置きます。たとえば、顧客の削減時間の価値が月額の二倍以上あり、通常入力の大半が担当者の追加修正なしで次の作業へ進み、障害時の調査時間が月額に含めた保守時間内なら継続候補です。これらは一般的な保証値ではなく、最初の顧客と合意して測るための目安です。

一方、価値は確認できても保守時間が想定を超えるなら、利用量上限、対応時間、月額を見直します。権限の境界を守れない、外部サービスの変更を制御できない、顧客の確認作業が削減されない場合は、機能を増やす前に撤退を検討します。値上げや撤退を失敗と見なさず、提供範囲と顧客の課題が合っていないという測定結果として扱うことが大切です。

まとめ：Stateless HTTP更新を小さな連携サービスの価値へ変える

Stateless Streamable HTTP の重要点は、接続を持たないこと自体ではなく、依頼を実行先から切り離しやすくなることで、連携サービスの運用範囲を説明しやすくする点にあります。8月3日の @voltagent/mcp-server 2.1.0 は個別パッケージの更新、7月28日の MCP 2026-07-28 は仕様の更新です。この二つを分けて伝えたうえで、顧客の仕事から一機能を選び、初期費用・月額・利用量・保守境界を別々に提示します。

売る前に、正常系の速度だけでなく、再接続、障害、権限、入力の揺れ、14日間の採算を測ります。顧客が削減できた時間と、提供側に残る保守時間の両方が見えれば、更新の新しさに頼らず、続ける・値上げする・撤退する判断を数字で説明できます。小さく始め、測れた価値の範囲だけを次の提案へ広げることが、個人エンジニアの連携サービスを長く保つ設計です。

出典：MCP 2.1.0と2026-07-28仕様の参照URL

1. Voltagent「@voltagent/mcp-server 2.1.0」
2. ClaudeDevs「MCP 2026-07-28」
3. Model Context Protocol Blog「The 2026-07-28 MCP Specification Release Candidate」
4. Model Context Protocol Specification 2026-07-28: Transports
5. YouTube収集結果