ステートレスMCP時代のAIエージェント承認設計

ステートレスMCPで、運用の文脈はどこに残るか

MCPは2026年7月28日にステートレス化される予定です。新仕様ではセッションとinitializeが廃止され、クライアントはハンドシェイクを並列実行できます。GitHub MCP Serverは公式リリースに先立ち、最新仕様へ対応しています。GitHub MCP Server supports the next MCP specification

GitHub MCP ServerはRedisセッション、initialize時のDB書き込み、呼び出しごとのDB読み取りを廃止しました。リクエスト値はHTTPヘッダーから取得し、SDK処理前にペイロードを検査しない構成です。サーバーが状態を持たないほど、作業の文脈と権限はIssue、Linear、PRといった外部の記録で管理する必要があります。

Linear起点の実装をどこまで任せるか

Copilot cloud agent for Linearは2026年7月23日に一般提供となりました。Linearの課題を割り当てると、エージェントは内容を分析し、GitHub Actions上の一時的な開発環境で作業してドラフトPRを作成します。進捗はLinearのアクティビティタイムラインに通知され、完了時にはレビューが依頼されます。Copilot cloud agent for Linear is now generally available

課題ごとにモデル、カスタムエージェント、対象ブランチ、作業ブランチを指定できます。課題を読む役とコードを書く役に、同じ権限を与える必要はありません。小規模チームでも、課題作成と分類は軽い権限、実装は限定ブランチ、マージは人間のレビュー後、と役割を分ける設計が必要です。

GitHub Issuesの承認機能を権限管理と混同しない

GitHub Issuesの公開プレビューでは、ラベル、フィールド、Issue種別、クローズ、担当者変更について、エージェントの提案を個別または一括で承認・拒否できます。各アクションには高・中・低の信頼度と理由が付き、高信頼度は自動適用、中・低信頼度は提案として保留されます。Agent automation controls in GitHub Issues in public preview

ただし、承認機能はセキュリティ制御ではありません。Issue変更権限を持つエージェントは、提案を経ずに直接変更できます。承認画面を置くだけでは、誤った自動クローズは防げません。トークンやアプリの実権限を絞り、直接実行できる操作そのものを限定します。保留案件は「has:suggestions」で検索できるため、日次の確認対象をこの検索に集約するとよいでしょう。

少人数チームの分岐点は、変更を戻しやすいか

自動適用に向くのは、分類ラベルの追加や担当エージェントの割り当てなど、履歴が残り、戻すコストが低い変更です。ワークフローでは「issue-intents: true」を設定し、close-issueやassign-to-userなどの対象操作に意図の明示を求められます。

一方で、Issueのクローズ、優先度に関わるフィールド変更、ユーザー担当の変更は提案に留めます。Linearから実装を依頼する場合も、エージェントの完了を完了条件にしません。ドラフトPR、テスト結果、レビュー承認を別々のゲートとして残す設計が適しています。

まとめ

ステートレスMCPでは、セッションではなくIssue、Linear、PRの記録がエージェント運用の文脈になります。まずは戻しやすい変更だけを自動適用し、直接権限、提案、マージ承認を分離してください。自動化の範囲は、チームがレビューできる量と速度を超えないことを判断基準に広げるべきです。