フラッシュカードでMCPを使っても安全？ 2026年の権限、プライバシー、書き込みアクセス

2026年5月20日、NSAはModel Context Protocol（MCP）のセキュリティ指針を17ページにまとめて公開しました。デッキの内容が公開してよい単語だけではないなら、これは無視できません。FlashcardsのMCP接続では、要求に応じてカード、ワークスペースのメタデータ、復習履歴がAIクライアントへ返されます。同じフルアクセスの資格情報で、カードを変更したり削除済みにしたりするツールも呼び出せます。フラッシュカードでMCPを使っても安全かを判断するポイントは2つです。そのデータを選んだクライアントへ渡してよいか、そのクライアントが書き込みツールを使えるかです。

OAuthは認可とトークン交換を保護し、Flashcardsサーバーは各ツールで実行できる操作を絞ります。それでも、提案された編集が妥当かは判断できません。取得したデータをFlashcards内に留めることも、AIクライアントが書き込み前に必ず確認することも保証しません。

見るべき境界は具体的です。各ツールのアクセス範囲、Flashcardsが強制するルール、クライアント側にしかない保護策です。

フラッシュカードでMCPを使っても安全か？ 実際のデータ経路を追う

リモートMCPセッションには、次の4つの役割が関わることがあります。

1. あなた
2. リクエストを入力するAIアプリケーションまたはMCPクライアント
3. モデルがクライアント外で処理される場合のモデルプロバイダー
4. FlashcardsのMCPサーバーとバックエンド

クライアントとモデルプロバイダーを1つの製品が兼ねる場合もあります。ツールの結果を別のサービスへ送る製品もあります。確実に言えるのは、Flashcardsが認証済みのMCPクライアントへ要求されたデータを返すところまでです。その後の経路は、クライアントのアーキテクチャ、プラン、設定によって変わります。結果がモデルのコンテキストに入る場合も、1社のプロバイダーの基盤内に留まる場合も、別の処理事業者へ渡る場合もあります。

現実的なリスクは3つです。読み取りによって、カード本文、デッキ構成、ワークスペース設定、復習イベントが開示されることがあります。書き込みによって、不要なカードが作られたり、内容が変わったり、カードやデッキが削除済みになったりします。エージェントが依頼を誤解し、取り込んだ資料内の指示をコマンドとして扱う可能性もあります。

NSAが2026年5月に公開したMCP指針が示す区別は参考になります。認証、認可、検証は欠かせませんが、動的なツール呼び出し、共有コンテキスト、暗黙の信頼が生むリスクは、それらだけでは解消できません。公開の語学学習デッキと、顧客の機密メモから作ったデッキには、別々の判断が必要です。

FlashcardsのOAuthが保護する範囲

Flashcardsは対話型MCPクライアント向けに、PKCEとDynamic Client Registrationを使う認可コードフローを採用しています。接続はブラウザで承認し、PKCEが認可コードの交換を開始元のクライアントに結び付けます。サーバーは、アクセストークンがFlashcardsのMCPリソース向けに発行されたことも確認します。FlashcardsのMCPコネクタガイドに、エンドポイントとディスカバリーメタデータが記載されています。

この仕組みが保護するのは、ログインとトークン交換です。2025年11月25日付の安定版MCP認可仕様では、このフローにPKCEとリソース固有のトークンを必須としています。同じ仕様には、MCP全体では認可の実装が任意であることも明記されています。そのため、FlashcardsにOAuthがあっても、別のMCPサーバーの認可方式までは判断できません。

Flashcardsが現在公開するOAuthスコープはflashcardsだけです。読み取り専用と読み書き可能なOAuth権限を分けて発行しておらず、この資格情報はコネクタが公開するすべての機能へのアクセスを認可します。したがって、設定を「読み取り専用」と呼べるのは、AIクライアント側でsql_executeを無効化またはブロックしている場合です。サーバーはsql_query自体が書き込めないよう強制します。一方、クライアントがsql_executeを送れば、同じ資格情報でその呼び出しも認可できます。

クライアント側でツールをブロックする設定は、運用上有効な対策です。ただし、OAuthの認可範囲は変わりません。資格情報を持つクライアントに悪意がある場合や、クライアントが侵害された場合、そのクライアントの動作までは制限できません。

Flashcards MCPの3つのツールで実際にできること

このコネクタが公開するのは、任意のPostgreSQL文ではなく、パーサーが制約を強制するSQL方言です。3つのツールは、それぞれ異なる範囲にアクセスします。

ツール	現在のアクセス範囲	データ変更	慎重なクライアント設定
list_workspaces	ユーザーがアクセスできるワークスペースを最大100件一覧表示。ID、名前、アクティブなカード数、最終アクティビティ、既定かどうかを含む	なし	このアカウント単位のメタデータをクライアントへ返してよい場合だけ有効にする
sql_query	指定した1つのワークスペースにあるworkspace、cards、decks、review_eventsを読み取る	なし	目的が明確な読み取り作業だけで有効にし、必要な列だけを要求する
sql_execute	指定した1つのワークスペースで、cardsとdecksのレコードを挿入、更新、または削除済みとして記録する	あり	納得できる形でクライアント側の書き込みを制限できない限り、無効にしておく

MCPガイドとAPIリファレンスでは、公開されているSQL方言を説明しています。どこまで信頼するかを決めるうえで重要な実装上の境界もあります。

ワークスペースの選択は実際にどう機能するか

1回のSQL呼び出しが対象にするワークスペースは、必ず1つです。FlashcardsはSQL文を実行する前に、ユーザーがそのワークスペースへ今もアクセスできるかを再検証します。これにより、呼び出し側が他人のワークスペースIDを指定してアクセスすることを防ぎます。

選択済みのワークスペースは、既定値にすぎません。workspaceIdを省略するとその既定値が使われますが、IDを指定すれば、同じ接続からユーザーがアクセスできる任意のワークスペースを対象にできます。list_workspacesが返すIDは結果に含まれるワークスペースのものに限られますが、workspaceIdを明示すればユーザーがアクセスできる任意のワークスペースを引き続き対象にできるため、100件という上限は分離境界ではありません。

テスト用ワークスペースは、クライアントがツール呼び出しをどう表示するか確かめるのに役立ちます。呼び出し先がそこに留まれば、単純なミスによる損失も抑えられます。ただし、同じ接続から別のアクセス可能なワークスペースを指定できるため、厳密な分離境界にはなりません。厳密に分けるには、本番ワークスペースへの権限を持たない別アカウントか、別のデプロイメントが必要です。

読み取り専用アクセスでも見える情報

list_workspacesとsql_queryでは、カードの状態を変更できません。データの修復やスケジュールの再計算もできません。この分離はサーバー側で強制されるため、クライアントからsql_executeを呼べない状態なら、誤ってデータベースを変更する可能性は大きく下がります。

それでも、返されたデータはFlashcardsのバックエンドから外へ出ます。苦手分野を調べるクエリにも、カード本文や復習イベントが含まれることがあります。短いカードであっても、患者の情報、社内システム名、個人的な語学の例文、面接用メモが入っているかもしれません。

Flashcardsのプライバシーポリシーは、MCPとAgent APIを通じて要求されたデータも対象にしています。プロトコル上、Flashcardsは結果をMCPクライアントへ送ります。そこから別のモデルプロバイダーへ渡るか、クライアントやプロバイダーがどれだけ保持するか、学習に利用されるかは、クライアントの構成とプロバイダーの規約次第です。「読み取り専用」をプライバシーの保証だと考えず、これらの条件を確認してください。

書き込み権限はデータベース全体へのアクセスより狭い

sql_executeが受け付けるのはINSERT、UPDATE、DELETEですが、対象はcardsとdecksだけです。workspaceとreview_eventsは読み取り専用です。期日、復習回数、保存されたFSRSの状態など、カードのスケジュール項目も、このSQL方言では読み取り専用です。MCPから復習結果を送信したり、FSRSのスケジュール状態を直接書き換えたりすることはできません。

UPDATEとDELETEには、どちらもWHERE句が必須です。条件のないSQL文は防げますが、有効な広い条件なら多数の行に一致する可能性があります。構文検証だけでは、その条件が意図どおりか判断できません。

カードとデッキに対するDELETEは、同期に使う削除タイムスタンプを設定します。その場でデータベースの行を物理削除するわけではありません。削除済みの項目は通常のデータ一覧から見えなくなり、MCPコネクタには取り消しや復元のツールがありません。誤って削除した場合は、別の経路かバックアップから復旧する必要があります。

利用規約では、AIが生成した出力を変更として適用する前に確認するよう求めています。ここでは特に重要です。FlashcardsはSQL文の種類、リソース、列、件数上限を検証できますが、その編集を望んだ理由までは検証できません。

承認を担うのはクライアント

Flashcardsはsql_queryにreadOnlyHint、sql_executeにdestructiveHintを付けています。2025年11月25日付の安定版MCPスキーマでは、ツールの注釈は明確にヒントとして扱われます。対応するクライアントが承認方針を決める材料にはなりますが、それ自体に強制力はありません。

有効で認証済みのsql_execute呼び出しをFlashcardsが受け取ると、すぐに実行します。Flashcards側に2回目の確認画面はありません。人間の承認を待つ処理があるなら、リクエストがサーバーへ届く前にAIクライアント内で行われます。

クライアントの挙動は製品ごとに異なります。たとえば、OpenAIのdeveloper modeドキュメントには、書き込み操作は既定で確認が必要で、その判断を会話単位で記憶させられると書かれています。MCP appsのヘルプページでは、確認プロンプトがアプリの権限、コンテキスト、ワークスペースの制御によって変わると説明しています。別のクライアントには異なる制御がある場合も、何もない場合もあります。

実際にクライアントが提供する中で、最も厳しい設定を使ってください。

• 個別のツールを無効にできるなら、作業に必要になるまでsql_executeをオフにしておく。
• 変更のたびに承認を必須にできるなら、その設定を選び、書き込みの承認は記憶させない。
• 提案された呼び出しが表示されたら、workspaceId、すべてのSQL文、WHERE条件、一致する見込みのレコード数を確認する。
• 書き込みツールをブロックできない、または呼び出し前に確実に停止できないなら、最初から書き込み可能な接続として扱う。

これらの設定でミスの可能性は下げられます。それでも、モデルの出力には人間の判断が必要です。

SQL文1つにつき100件という上限の意味

1つのSQL文が返す、または変更するレコード数は最大100件です。1つのバッチには最大50文を含められます。したがって、すべてのSQL文が上限に達すれば、認証済みのツール呼び出し1回で理論上は最大5,000件のレコードに影響します。1枚のカードに対する確認とは、影響の桁が違います。

変更バッチには原子性があります。バッチ内のすべてのSQL文が成功するか、トランザクション全体が失敗するかのどちらかです。1つのSQL文でエラーが起きたとき、バッチが途中まで適用されることは防げます。ただし、意図は検証せず、有効なバッチがコミットされた後の取り消し機能もありません。

シリアライズ後の結果には48,000文字の上限もあります。この上限は変更の実行後に適用され、MCPレスポンスのサイズだけを制限します。結果が大きすぎるとして拒否される前に、変更がコミットされる可能性があります。影響範囲を見積もる基準は、SQL文ごとの100件という上限です。広い範囲へ書き込む前に、sql_queryで対象を確認してください。

学習素材からプロンプトインジェクションが入り込むこともある

フラッシュカードの本文は自然言語で、AIクライアントが解釈する対象そのものです。取り込んだノートには、隠された指示、引用されたプロンプト、信頼できない作成者の文章が含まれる可能性があります。エージェントがその資料を読み、同時に書き込みツールを使える状態なら、データを新しいコマンドだと誤解することがあります。

この問題は、OAuthの仕組みが破られなくても起こります。認可済みのクライアントには、すでに書き込みを試みる権限があります。

NSAのMCPセキュリティレポート全文では、ツールとモデルの出力を、処理パイプラインの次の工程にとって信頼できない入力として扱っています。推奨しているのは、厳密なリソース境界、パラメーター検証、出力の精査、最小権限です。こうした対策でリスクは下がりますが、プロンプトインジェクションを不可能にはできません。

Flashcards側にもサーバーの保護策があります。パーサーは未対応のSQL文の種類やリソースを拒否し、MCPツールがシェルや制限のないデータベース接続になることはありません。それでも、混入した指示は、アクセス可能なカードへの構文上有効な変更を要求できます。サーバーに見えるのは許可されたリクエストだけで、そのリクエストを出すようモデルを誘導した会話は見えません。

機密性の高い作業では、セッションを小さく保ってください。信頼できる情報源を1つ、対象ワークスペースを1つ、必要なツールだけに絞ります。信頼できないインポート、無関係なコネクタ、人の確認を挟まないFlashcardsへの書き込みを、同じエージェント実行にまとめないでください。セッションを小さくすれば不審な呼び出しに気付きやすくなりますが、分離境界にはなりません。

下流のプライバシー境界はクライアントとモデル構成で決まる

データの正本はFlashcardsに残りますが、要求した内容はMCPクライアントへ渡ります。その先の扱いは製品ごとに異なります。クライアント自体がモデルを動かす場合も、別のプロバイダーを呼び出す場合もあります。ツールの結果を会話履歴に保持したり、ワークスペース管理者に公開したり、メモリ機能と組み合わせたりすることもあります。アーキテクチャが違えば、プライバシー境界も変わります。

OpenAIは具体例の1つです。現在のApps in ChatGPTドキュメントには、アプリから取得したデータを回答のコンテキストに使い、メモリやWeb検索と組み合わせる場合があると書かれています。また、Business、Enterprise、Eduアカウントと、"Improve the model for everyone"が有効な個人プランでは、学習への利用に関する既定値が異なることも説明しています。これはOpenAI固有のルールで、MCP全体の挙動ではありません。

実際に使うクライアント、アカウントの種類、ワークスペースポリシー、リージョン、設定を確認してください。見るべき項目は、保持期間、学習への利用、メモリ、管理者アクセス、再委託先、削除です。機密性のある元資料がクライアント外へ出るかどうかをドキュメントで確認できないなら、本物のデッキを使って試さないでください。

ホスト版アカウントの削除、コネクタの切断、下流にあるコピーの削除は、それぞれ別の操作です。Flashcardsのプライバシーポリシーでは、ホスト版にあるデータの削除を説明しています。すでにクライアントやモデルプロバイダーが保持しているデータをFlashcardsから削除することはできません。プロバイダー側の制御も使う必要があります。

接続解除と資格情報の失効は別の手順

現在のFlashcards OAuth実装では、有効期間1時間のアクセストークンと、固定の有効期限がないローテーション式のリフレッシュトークンを発行します。現時点で、ユーザー向けのOAuth接続失効画面や公開の失効エンドポイントはありません。コネクタを削除すると、クライアントが資格情報を破棄する場合があります。ただし、このクライアント側の操作だけで、サーバー側のトークンが無効になったとは保証できません。

ヘッドレスのfca_ Agent APIキーは、別の種類の資格情報です。このキーは、FlashcardsのAgent Connectionsから失効させられます。アクセス手順を文書化するときや接続を終了するときは、2つの認証経路を分けて扱ってください。

脅威モデル上、サーバー側でOAuthを即時に失効できることが必須なら、現在のOAuthコネクタには、そのためのユーザー向け機能がありません。この制約は、使い捨ての公開デッキより、機密性の高いデータへ長期間接続する場合に重くなります。

接続前の実践チェックリスト

1. 元資料を分類する。公開の学習ノート、個人情報、勤務先の機密情報、規制対象データに、同じアクセスポリシーを使うべきではありません。その資料をクライアントとデータ処理を担う事業者へ送る権限がないなら、MCP経由で渡さないでください。
2. サーバーURLを確認する。文書化されたエンドポイントはhttps://mcp.flashcards-open-source-app.com/mcpです。紛らわしい類似ドメインや、出所不明の定義からコピーしたコネクタは避けてください。
3. 双方のポリシーを読む。まずFlashcardsのプライバシーポリシーを確認し、次に実際に使うAIクライアントの保持、学習への利用、メモリ、ログ、削除のルールを確認してください。
4. 予備のワークスペースで十分かを決める。リハーサルには役立ちますが、同じアカウント上にある別のワークスペースも接続先にできます。厳密な分離が必要なら、別アカウントか別のデプロイメントを使ってください。
5. クライアント側でsql_executeをブロックした状態から始める。ブロックできないクライアントなら、OAuth資格情報が書き込み可能なままだと理解してから接続してください。
6. 必要最小限のデータだけを要求する。回答に必要な列と行だけを選び、無関係な秘密情報を会話に含めないでください。
7. 一括変更の前に、復元できることを確認したバックアップを作る。フラッシュカードのバックアップガイドで、手順全体を説明しています。
8. 広い範囲への更新や削除は、毎回sql_queryで事前確認する。正確なカードIDまたはデッキIDを優先し、一致件数が想定どおりか確かめ、変更を小さなSQL文に分けてください。
9. クライアントに承認機能があるなら使う。毎回ワークスペースと完全なペイロードを確認し、破壊的操作のヒントだけで確認画面が強制されるとは考えないでください。
10. 意識的にアクセスを終了する。現在はサーバー側の失効に制約があることを踏まえ、OAuthコネクタを切断し、クライアントに保存された資格情報を削除します。fca_キーはAgent Connectionsで失効させ、下流のデータ削除は別に行ってください。

ここまで判断した後の設定手順は、ClaudeにFlashcardsをMCPで接続する方法で説明しています。接続ガイドが扱うのは操作手順です。このチェックリストでは、そのデッキをそもそも接続対象にしてよいかを判断します。

オープンソースとセルフホストが役立つところ

Flashcardsコネクタには、読み取りと書き込みが別ツールであること、許可するSQL文が限定されていること、呼び出しごとにワークスペースへのアクセス権を確認すること、スケジュール項目が読み取り専用であること、ソースコードが公開されていることなどの特徴があります。これらの制御により、アクセス範囲を確認して制限しやすくなります。リスクは下げられますが、クライアントの安全性やモデルの判断の正しさは保証できません。

セルフホスト型のデプロイメントなら、Flashcardsのデータ保存と処理を、自分で管理する基盤へ移せます。それでも、外部のAIサービスへ送るクエリには、デプロイメント外へ出るカードデータが含まれます。モデルとクライアントの経路にも、データベースと同じ水準のプライバシーが必要です。

シンプルな判断基準

MCPの読み取りツールを使ってよいのは、要求するデータが選んだクライアント経路を通ってFlashcardsの外へ出てもよく、プロバイダーの規約を受け入れられ、その開示に見合う作業である場合です。クライアントがsql_executeを実際にブロックしていない限り、接続自体はフルアクセスと考えてください。

書き込みツールを有効にするのは、目的を絞った作業で、重要な呼び出しの前にクライアントが停止でき、対象行を事前確認し、使えるバックアップがある場合だけにしてください。1つのバッチは100件をはるかに超えるレコードに影響でき、削除にはMCPからの取り消し手段がないことも忘れないでください。

デッキをクライアントやその処理事業者と共有できない場合、下流のポリシーが不明な場合、同じアカウント内で厳密なワークスペース分離が必要な場合、OAuthの即時失効が必須な場合、人の確認なしに破壊的な書き込みを行う必要がある場合は、接続を見送ってください。その場合はMCPなしでFlashcardsを使うか、データ経路全体が要件を満たすデプロイメントとモデル構成を選びます。