GPTs配布型・ナレッジ配布型・MCP型、どれがいい？推論費用と知識の公開範囲で決める

教材を入れたAIを配るか、教材そのものを配るか。それとも、各自のAIから教材を取りに来てもらうか。

前の記事では、GPTs配布型とナレッジ配布型を、更新管理・仕事への応用・指導設計から比べました。最後に触れたのが、「正本は管理者が持ち、使うAIは各自」という第三の選択肢です。

今回は、それを『AI×Threadsの教科書』のMCPサーバーとして実際に作りました。受講生のCodexやClaude Codeに、教科書の型や要点を渡す仕組みです。

検討してみると、設計を決めたのは大きく2つでした。

AIが文章を考えて書く費用を、誰が持つのか。教科書の知識を、どこまで利用者側へ渡してよいのか。

僕らが選んだのは、教科書の必要な部分をMCPで渡し、受講生が普段使うAIに、自分の資料と組み合わせて書いてもらう形です。一方、質問する窓口と進め方を用意して渡したいなら、AIチャットつくーるのような共通のAIチャットが合います。

どちらも僕らが提供している仕組みです。今回は、講座運営者が自分の用途に合わせて選べるよう、設計で気づいた違いを整理します。

3つの配り方は、「どこで作業するか」が違う

ここでいうGPTs配布型は、前の記事と同じく、講師が用意した共通のAIチャットを使ってもらう方式を指します。GPTs(カスタムGPT)そのものに加え、同じように共有できるAIチャットも含む呼び方です。

すでにCodexやClaude Codeで、プロフィール、商品説明、過去の投稿などをまとめている人は、そこから離れずに使えると便利です。講師のAIへ移動するたびに、自分の仕事の前提を説明し直す場面を減らせます。

一方、まだ自分のAIの作業場がない人には、質問する場所と手順が用意された共通のAIチャットが使いやすいこともあります。

なお、MCPはAIと外部の情報・機能をつなぐための共通の取り決めです。MCPという名前だけでは、文章をどこで生成するかも、知識をどこまで返すかも決まりません。AI Crew：MCPとは？仕組み・できること・注意点

このため、MCP型はさらに「資料を返す設計」と「サーバー内で文章を作って返す設計」に分かれます。ここが今回の判断の分かれ目でした。

最初の軸は、誰の契約でAIを動かすか

「推論費用」というのは、AIが情報を読み、判断し、文章を生成するための費用です。月額契約の利用枠に含まれる場合も、APIの使用量として請求される場合もあります。

GPTs配布型・MCP型という配り方だけで、費用の負担者が決まるわけではありません。どのAIを、誰の契約やAPIキーで動かすかを別に考えます。

例えば、ChatGPTの契約とOpenAI APIの請求は別です。利用者がChatGPTを契約していても、講師側のサーバーが呼び出すAPI料金まで、その契約に含まれるわけではありません。OpenAI公式：ChatGPTとAPIの請求管理

今回、僕らの用途では、主な候補を次の4通りに整理できました。

「受講生の一次情報と混ぜたい」「当社で文章生成の費用を持たない」「利用者のAPIキーを預からない」「教材の正本は当社で更新したい」。この条件を重ねると、最初の案が残りました。

これは、あらゆるAIアプリの設計が4通りしかないという意味ではありません。今回の教材提供で、比較すべき候補を4つに絞ったということです。

また、当社側の推論費用がないことと、運営費用がないことは別です。MCPサーバーの稼働、認証、ログの保存、保守や問い合わせ対応は残ります。受講生側でも、AIを使う分だけ自分の利用枠を消費します。

APIキーを預からないことも、使いやすさの一部

利用者が自分のAPIキーを持ち込む形は、BYOKと呼ばれます。採用するなら、キーの保管だけでなく、権限、利用量、失効、誤動作したときの課金まで設計する必要があります。

APIキーは単なる接続用の合言葉ではなく、その人の利用枠や請求につながる権限です。漏洩や不正利用が、予期しない料金につながる可能性もあります。OpenAI公式：APIキーの安全性

今回の対象は、開発者ばかりではありません。普段のCodexやClaude Codeを使うための契約とは別に、APIの発行や支払い管理まで覚えてもらうことは、教材を使う目的から遠いと判断しました。

教科書へ接続するための認証と、生成AIのAPI利用を許可するキーは別物です。今回のMCP接続で、受講生の生成AI用APIキーを当社へ預けてもらうことはありません。

もう1つの軸は、知識をどの形で渡すか

教科書の型を利用者のAIに使ってもらうなら、そのAIが型を読める必要があります。

ここで「ナレッジを隠したい」という言葉を、少し分解する必要がありました。

僕らが採用したのは、真ん中です。教材の要点や型を返し、利用者側のAIがそれを読むことを許容しています。

使ってみると、画面には自分向けに書かれた投稿だけが出てきて、「教科書の文章を持ち出した」という感覚があまりありませんでした。でも、管理画面で返答を確認すると、使った型やルールの文章は、ちゃんと利用者側へ渡っています。

画面上で目立たないことと、情報が渡っていないことは違います。

その文章を保存したり、別の用途に転用したりできない仕組みではありません。取得を積み重ねれば、MCPで提供している範囲の知識を相当程度集められる可能性もあります。

ただし、今回の接続先が返すのは、購入者向けに選び直し、編集した型や教材の要点です。社内の資料庫や、教科書の動画・PDFの全内容を、そのまま公開しているわけではありません。

僕らは、購入者がすでに学べる内容を、自分のAIで使いやすく届けることを優先しました。読ませるために返した知識は、利用者側に渡る。その前提で、返してよいものを選ぶという判断です。

もし型の文章そのものを渡したくないなら、サーバー側でその型を使って文章を生成し、完成文だけを返す案が候補になります。その場合は、生成に必要な利用者の情報をサーバーへ送り、そこで発生する推論費用を誰かが持つことになります。

なお、文字数の判定や計算結果を返すだけなら、サーバー側でAIを動かす必要はありません。「完成文をAIに書かせる処理」と「プログラムで検査する処理」は分けられます。

今回は「教材を返すサーバー」と「書くAI」を分けた

実際の構成は、次のようにしました。

サーバーは、Cloudflare Workers上で動くTypeScriptのプログラムです。接続を認証し、呼ばれたツールに応じて教材を検索したり、投稿を機械的に検査したりして、結果を返します。このMCPサーバーから、文章生成のためのAIは呼び出していません。

用意したツールは5つです。

例えば、利用者が「1+5の型で、自分の作品について投稿を作って」と頼むと、利用者側のAIが必要な型やルールを取得します。それを、自分の作品の説明、経験、普段の口調などと組み合わせて文章にします。

「何を取りに行くか」「返ってきた型を自分の材料にどう当てはめるか」「どう書くか」を考えるのは、利用者が使うAIです。サーバーは、受け取った検索条件やIDに応じて、用意された資料や検査結果を返します。

必要な情報を取得して生成に使うという意味で、RAGに近い構成です。ただし、MCPそのものがRAGというわけではありません。同じMCPでも、データを登録する、計算する、別のAIへ生成を依頼する、といった設計にできます。

また、会話のたびに必ず5つのどれかが呼ばれるわけでもありません。すでに得た情報で文章を直す場面など、ツールを呼ばずに答えることもあります。接続確認やツール一覧の取得といった通信も、教材を取得する処理とは別です。

「手元で使う」は「何も外へ送らない」ではない

自分の資料を作業フォルダに置いていても、CodexやClaude CodeのAI処理までパソコン内だけで完結する、という意味ではありません。利用するAIの提供元には、処理に必要な情報が送信されます。

さらに、今回のMCPサーバーにも、AIがツールの引数に入れた情報は届きます。検索なら検索語、投稿チェックならチェック対象の本文です。会話全体やフォルダ全体をMCPへ渡す仕組みにはしていませんが、「利用者の情報は一切当社を通らない」とは言えません。

この区別は、サーバー内で生成する案と比べるときにも大切です。各自のAIなら、読み取りを許可した手元の資料を必要に応じて使えます。サーバー内のAIが直接使える利用者の資料は、そのサーバーへ入力したり、別途接続したりした範囲になります。

どちらも、本人の材料を正しく用意し、出来上がった文章を確かめる工程は残ります。

5つの「〇〇くん」を、共通の教材とツールで支える

もう1つ大きかったのは、用途ごとのAIを別々に持つ発想から、1つの教材を複数の用途で使う発想へ変えられたことです。

これまでの5つのGPTsの役割を、今回は次のように分担させました。

5つの用途と、5つのツールは、1対1の関係ではありません。「1+1を書く」と「1+5を書く」は同じ型取得ツールを使えますし、1回の投稿作成で型取得・ルール参照・投稿チェックを組み合わせることもできます。

利用者には、これまでの「〇〇くん」に相当する頼み方や手順を渡す。裏では共通の教材を参照する。用途が増えるたびに教材一式を別のAIへ複製する必要がなくなります。

型や表現ルールを改訂したら、教材を編集してサーバーへ反映します。以降の取得では、新しい内容を返せます。 利用者ごとのファイルを一つずつ差し替えてもらう運用にはしません。

ただし、すでに会話へ取り込まれた文章や保存済みのコピーまで、書き換えられるわけではありません。更新後の内容を使うには、改めて取得する必要があります。

知識が渡っても、管理者側に残る価値がある

今回の設計では、型やルールの文章は利用者側へ渡ります。それでも、管理者が持ち続ける意味があるものは残ります。

1つは、教材を更新して届け続ける運用です。新しい型を追加する、説明を直す、検証できた実績があれば更新する。その後の呼び出しで、新しい情報を使ってもらえます。取り出した時点の文章だけでは、その後の更新までは手に入りません。

もう1つは、実行する機能です。投稿を渡すと文字数や書式を検査して返す。利用者に返るのは検査結果で、検査プログラムそのものを配布しているわけではありません。

AIチャットつくーるが合う人、MCPが合う人

今回の僕らはMCP型を選びましたが、すべての講座をこの形にする必要はありません。

AIチャットつくーるが合うのは、利用者に質問する場所と進め方を用意して渡したい人です。 例えば、講座の質問窓口を作りたい、決めた順番でヒアリングしたい、共通の基準で添削してほしい、といった用途です。利用者が自分の作業フォルダや接続を整える前から、用意されたAIとの対話を始められます。

僕が作っているAIチャットつくーるでは、作成者が設定した指示とナレッジを使うAIを、リンクで共有します。会話の利用枠はAI作成者の契約で管理し、作成者や利用者に生成AI用APIキーを預けてもらう形にはしていません。利用者側へAPIの管理を求めず、提供側のプランで利用を支える選び方です。

このようなアプリに将来MCPの入口を設けるとしても、利用者のAPIキーを預かる方式を選ぶ必要はありません。入口のつなぎ方と、推論費用を誰の契約でまかなうかは別の設計です。これは考え方の例で、AIチャットつくーるのMCP対応を案内するものではありません。

資料を返すMCPが合うのは、利用者が自分のAIで進めている仕事に、教材を組み込んでほしい人です。 自分の商品説明や過去の成果物がすでにまとまっていて、講師の知識をそこへ混ぜたい。使うAIや進め方も、各自で選びたい。その代わり、提供者は返した知識が利用者側へ渡ることを受け入れ、接続とサーバーを運用します。

『AI×Threadsの教科書』では、この使い方を優先しました。これから自分の作業場を作る受講生向けには、専用の構築プロンプトも用意しています。接続先だけ渡せば誰でも使えると考えず、最初に自分の資料を整理する手順まで含めて提供しています。

ナレッジ配布型が合うのは、教材を受け取った人が自由に編集し、自分の資産として使うことを優先したい場合です。 更新頻度が低く、配った版を各自で管理してよい教材なら、ファイルで渡す方法は分かりやすい選択です。

誰がAIを動かす費用を持ち、何をどこまで渡してよいか。 ここを先に決めると、用意するものが共通チャットなのか、教材ファイルなのか、MCPサーバーなのかを選びやすくなります。

自分の講座や仕事に合わせて、こうした仕組みをアプリにしたい方は、当アプリの運営会社が提供するAI Crewの受講生がつくったホームページや業務アプリも参考になります。