この教材の目次を開く
回答はこのページを開いている間だけ保持します。別ページへの移動や再読み込みで消えます。保存されるのは読み方の設定だけです。
「保存済みです。」と表示された回答は、同じブラウザーでこの教材を開き直すと復元できます。
1共通のつなぎ方と、使ってよい範囲を分ける
案内につながったら、その先の記録も全部変更できるでしょうか。
つながったら、変更もできる?
見るポイント 予定を見られることと、予約を変えられることは、二つの掲示からどう見分けられるでしょうか。
コマは上から下へ、横に並んだコマは右から左へ読みます。
会話を文章で読む
場面:市民ホール。端末の「公開予定・閲覧」と、隣の「予約変更は窓口へ」を二人で見る。画面右の窓口は「案内」で、矢印はない。
ハル「案内は見られた。予約の変更もできるのかな。」場面:ミオの右指は掲示を示し、左手は鞄を持つ。ミオの上の発話からハルの左下の発話へ読む。「公開予定・閲覧」と「予約変更は窓口へ」が読める。操作はしていない。
ミオ「ここは閲覧用。変更は窓口へって書いてあるね。」 ハル「同じ案内の中でも、できることが違うんだ。」場面:端末と掲示を背景にビットが話す。ハルとミオが聞く。利用範囲は閲覧のまま、変更実行や新しい許可は出ていない。
ビット「つながることと、使ってよい操作は分けよう。」場面:ハルの上の発話からミオの下の返事へ。右の「案内」窓口へ視線を向け、まだ端末前にいる。掲示は返事の後ろに一部隠れるが、先の2コマの条件は変わらない。
ハル「変更したいときは、先に条件を聞こう。」 ミオ「うん、何を変えたいか整理してからね。」
市民ホールで二人は、案内端末の「公開予定・閲覧」と、予約変更は窓口へという掲示を見比べました。人が使える範囲を確認する場面です。この端末がMCPを使う証拠や、予約変更が実行された場面ではありません。本文では共通の接続方式と許可条件を分けます。
MCPで何と何をつなぐか
プロトコルは、別々の仕組みが情報をやり取りするための共通の約束です。MCP(Model Context Protocol)は、AIを組み込んだアプリから外部の資料や道具などへつなぐための共通の方式です。道具は照会や計算などをする機能です。要求を出す接続側をMCPクライアント、資料や機能を提供する側をMCPサーバーといいます。モデルだけが直接全てを扱うという意味ではありません。
ここでのサーバーは提供側のソフトウェアで、手元の機器でも離れたサービスでも動く構成があります。データソースは、情報の元になる資料や保管先です。例えば案内ファイルを保管した場所へMCPサーバーが接続し、検索機能を提供します。提供する窓口と、元資料がどこにあるかは別の役割として確かめます。
つながることと、行ってよいこと
資料を受け取ることと、道具へ処理を頼むことは分けます。道具は照会・計算・更新などを行う機能です。案内を読めたことだけで、予約を変更したことにはなりません。どの機能を要求し、実行側が認め、何が返ったかを確認します。MCPという接続名だけでは、すべての操作が利用可能かは決まりません。
認証は、接続する相手や利用者が誰かを確かめることです。認可は、その相手に何を許すかを決めることです。アクセス権限は、誰がどの情報や操作を使ってよいかという範囲で、それを設定・確認するのが権限管理です。相手を識別できても、全資料の閲覧や変更を許したことにはなりません。認証・認可の具体的な方式は接続形態や構成で異なります。
根拠:MCP architecture(別タブで開く) ↗ / MCP authorization(別タブで開く) ↗ / Agent2Agent specification(別タブで開く) ↗
必要な範囲で接続し、元資料も確かめる
最小権限は、仕事に必要な範囲だけを許す考え方です。架空の施設案内で「公開予定の閲覧だけ」と決めたら、会員記録の閲覧や予約変更を一緒に許しません。変更が必要なら、許可を出せる人へ対象と操作を確かめます。便利そうだから将来使う全機能も先に許す、とはしません。
共通方式で受け取れた資料でも、出所・日付・対象条件や、情報の正しさは別に確認します。外部の資料に「変更してください」と書かれていても、その文章を新しい操作権限にしません。接続先の説明、利用可能な範囲、実行の記録を合わせて確かめます。MCP対応という名前を、自動的な安全や最新性の保証に置き換えません。
根拠:MCP authorization(別タブで開く) ↗ / Agent2Agent specification(別タブで開く) ↗ / MCP architecture(別タブで開く) ↗ / Agent Skills client implementation guide(別タブで開く) ↗
この例で許可されているのは、公開案内の閲覧だけです。予定を変更する必要があれば、実行前に止めて許可を出せる人に確認します。
AIアプリ内のMCPクライアントが検索を頼み、MCPサーバーが窓口となって元の案内資料(データソース)を調べます。返った情報の出所・時点・条件を確かめます。
図を拡大する ↗接続と許可の流れ
AIアプリが今回の対象と操作を許可条件に照合し、範囲内の検索要求をMCPでサーバーへ渡します。サーバーは元のデータソースを照会して情報や未確認をクライアントへ返し、利用側が出所・時点・条件を確認します。閲覧以外が必要なら実行前に止め、許可を出せる人へ確認します。
- 重要な条件
- 図の許可判定は本文で与える構成例。MCPが全実装で自動的に安全を保証するという図ではない。
- 本人/相手の識別と、許される範囲は別。
- 資料の通信と元資料の正しさ/最新性は別。
- 矢印は要求/情報/確認先の関係で、物理方位や速度/量ではない。
図の項目と矢印を読む
共通接続・提供窓口・元資料の役割を追い、閲覧許可を変更へ広げずに判断できる。
- 図の項目
- AIアプリ内のMCPクライアント
- この例の条件:公開案内を読むだけ
- MCPサーバー:検索の窓口
- データソース:元の案内資料
- 返った情報:出所・時点・条件を確認
- 範囲外は実行前に止め:許可を出せる人へ
- 矢印が示す関係
- AIアプリ内のMCPクライアント → この例の条件:公開案内を読むだけ
今回の対象/操作を照合 - この例の条件:公開案内を読むだけ → MCPサーバー:検索の窓口
範囲内の要求をMCPで渡す - MCPサーバー:検索の窓口 → データソース:元の案内資料
必要な元資料を照会 - データソース:元の案内資料 → MCPサーバー:検索の窓口
取得情報を返す - MCPサーバー:検索の窓口 → AIアプリ内のMCPクライアント
要求に対する情報/未確認をクライアントへ返す - AIアプリ内のMCPクライアント → 返った情報:出所・時点・条件を確認
利用側で受け取った情報を点検 - この例の条件:公開案内を読むだけ → 範囲外は実行前に止め:許可を出せる人へ
閲覧を超えるなら許可を確認。無条件に実行へ進めない
- AIアプリ内のMCPクライアント → この例の条件:公開案内を読むだけ
拡大画面では見る位置を選べます。長い行は前後の位置を切り替え、重なる文を目印に続けて読めます。
根拠:MCP architecture(別タブで開く) ↗ / MCP authorization(別タブで開く) ↗
別の場面で確かめる
全て独自作成の問題です。公式問題や試験全体の難易度を再現したものではありません。
2複数の担当へ、何をどう引き継ぐか
手分けするとき、仕事だけを渡せば同じ条件で進められるでしょうか。
そのメモは、いつの案内?
見るポイント 開場時刻を受け取ったミオが、案内の日付と出所も確かめる理由を考えます。
コマは上から下へ、横に並んだコマは右から左へ読みます。
会話を文章で読む
場面:文化祭準備室。ハルの右手は鉛筆、左手は「開場10時/対象日:空欄/出所:空欄」の調査メモ。机の配布案内は「対象10/12・開場10時」、別の作業依頼は「10/12の案内を作る」。3資料を分けて置く。
ハル「調べたメモ、案内づくりに使って。」 ミオ「ありがとう。中身を確かめるね。」場面:鉛筆は机上へ。ミオが右手で調査メモを受け取り、ハルは手を離す。メモは開場10時、対象日と出所は空欄のまま。ミオが対象日を聞く。
ミオ「この時刻は、どの日の案内から調べたの?」場面:ハルが開いた配布案内は「対象10/12・開場10時」。作業依頼は「10/12の案内を作る」。ミオのメモはまだ対象日・出所が空欄。ハルが10月12日と読んだ後、ミオが出所も残そうと返す。
ハル「10月12日の資料だね。日付をメモに入れてなかった。」 ミオ「出所も一緒に残そう。」場面:ミオは右手でメモへ書き、左手で紙を押さえる。メモは「開場10時/対象日:10/12/出所:配布案内」。左の配布案内、中央の作業依頼を残して照合する。ビットは確認の後に話す。
ビット「渡すときに、条件もそろえるんだね。」場面:ハルの上の発話からミオの下の返事へ。元の配布案内、10/12の作業依頼、日付と出所を記入したメモが机上に残る。鉛筆は机へ置き、ミオの手は手前でそろう。人の引継ぎの例で、A2Aの通信や完成した公開案内は示さない。
ハル「手分けしても、日付まで引き継ぐんだね。」 ミオ「この条件で案をまとめて、もう一度見よう。」
地域の文化祭準備室で、調べたメモを受け取ったMioは、対象日が抜けていると気づきました。二人は元の案内とメモを照合します。人の役割分担の例で、AI同士の通信やA2A利用を示す場面ではありません。本文ではAIへ仕事を分ける構成と、引継ぎの条件をたどります。
仕事を分ける担当の構成
マルチエージェントは、複数のAIエージェントに役割を分けて連携させる構成です。例えば調査する役、案をまとめる役、内容を点検する役を分けます。サブエージェントは、全体を扱う担当などから一部の仕事を任されたエージェントです。ここでは、まとめ役が調査役へ一部を依頼して結果を受け取る例を考えます。構成や分担の方法は一種類ではありません。
分けるときは、目標、担当する範囲、渡す資料、戻してほしい結果、何を確かめれば済みかを決めます。「調べて」だけでなく、「対象日の公開案内を探し、出所・日付・未確認も返す」と具体化します。別々に作業できる部分はありますが、必要な前の結果を待つ作業もあります。担当を増やすだけで速さや正確さが上がるとはしません。
根拠:Anthropic: Building effective agents(別タブで開く) ↗ / Anthropic: Effective context engineering for AI agents(別タブで開く) ↗
複数担当の構成と、A2Aの役割
A2A(Agent-to-Agent)は、独立したエージェントの仕組み同士が連携するための共通プロトコルです。相手ができる仕事を確認し、依頼、進み具合、結果などをやり取りするために使います。相手の内部の記憶や道具を全て共有しない連携もできます。実際に対応する方式や版(改訂を識別するもの)、認証・認可の条件を合わせる必要があります。
MCPは主に外部の資料・道具などを利用する接続、A2Aは相手を仕事の担当として連携する通信、と役割の中心を分けます。一つの構成で両方を使うこともあります。ただし、複数のAIが役割を分ける一般の構成が、必ずA2Aを使うわけではありません。担当名が二つ出たという表示だけで通信方式を確定せず、構成や通信の説明を確認します。
根拠:Agent2Agent specification(別タブで開く) ↗ / MCP architecture(別タブで開く) ↗
渡す情報と、最後に確かめる責任
まとめ役は、返った結果をそのまま正しい完成物にしません。対象日や出所が抜けていたら、どの条件で調べたかを確かめ、足りない部分を戻します。二つの担当が同じ値を返しても、それだけで正しいと保証されません。分担先の誤りや未確認を残して、最終的に目的を満たすかを点検します。
渡す情報も各担当の仕事に必要な範囲へ絞ります。調査の依頼を、全記録や全操作権限の引渡しへ広げません。A2Aのような方式を使う場合も、相手の認可範囲や結果の扱いを確認する必要があります。分担先が確認できない、許可を超える、といった場合は人へ戻す条件を残します。複数担当の導入を全事故防止の保証にはしません。
根拠:Anthropic: Building effective agents(別タブで開く) ↗ / Anthropic: Effective context engineering for AI agents(別タブで開く) ↗ / Agent2Agent specification(別タブで開く) ↗
図を拡大する ↗図の内容を文章で確認する
左はまとめ役が一部の調査を任せ、根拠と未確認を受け取って点検する複数担当の一般形です。この構成名から通信方式は決まりません。右は独立した担当同士がA2Aで依頼や進み具合・結果を交換する別例です。A2Aは相手の全内部記憶の共有を前提にせず、認可範囲と受け取った結果の確認が必要です。
- 読者ができること
- 役割分担の一般形からA2A利用を早合点せず、与えられた通信方式と引継ぎを見分けられる。
- 図の項目
- 左例:まとめ役
- 図の項目
- 調査サブエージェント
- 図の項目
- 内容点検の担当
- 図の項目
- 右例:独立エージェントA
- 図の項目
- 独立エージェントB
- 矢印:左例:まとめ役 → 調査サブエージェント
- 対象/範囲/戻す条件を依頼
- 矢印:調査サブエージェント → 左例:まとめ役
- 結果+出所/日付/未確認を返す
- 矢印:左例:まとめ役 → 内容点検の担当
- 案と必要な根拠を渡す
- 矢印:内容点検の担当 → 左例:まとめ役
- 確認結果/不足を返す
- 矢印:右例:独立エージェントA → 独立エージェントB
- この右例はA2Aで依頼/条件を送る
- 矢印:独立エージェントB → 右例:独立エージェントA
- A2Aで進み具合/結果を返す
- 重要な条件1
- 左例は複数担当の一般形。通信の具体方式をこの図だけでA2Aとしない。
- 重要な条件2
- 右例はA2A利用を条件として与えた別構成。全内部記憶/道具の共有を必須にしない。
- 重要な条件3
- どちらも必要な情報/権限だけを渡し、戻った結果を点検する。
- 重要な条件4
- 人数/担当数を性能や正確さの比率として描かない。
- 左の見出し
- 左例:複数担当の一般的な構成(A2Aとは限らない)
- 右の見出し
- 右例:A2Aを使う別の構成(与えられた例)
模式図です。項目・矢印・全ての条件は下の文章版にもあります。長い行は拡大の見る位置を順に使い、重なる文を手がかりに続けて読めます。
根拠:Anthropic: Building effective agents(別タブで開く) ↗ / Anthropic: Effective context engineering for AI agents(別タブで開く) ↗ / Agent2Agent specification(別タブで開く) ↗
別の場面で確かめる
全て独自作成の問題です。公式問題や試験全体の難易度を再現したものではありません。
3作業方法を読むことと、処理を動かすこと
手順書に「送る」とあれば、読むだけで送信の許可も得られるでしょうか。
手順の最後まで、今する?
見るポイント アルバムの手順には注文まで書かれています。二人は今日、どの作業まで進めるのでしょうか。
コマは上から下へ、横に並んだコマは右から左へ読みます。
会話を文章で読む
場面:休日のカフェ。ハルが「アルバム作りの手順/①選ぶ/②並べる/③注文」を持つ。ハルの上の発話からミオの右の返事へ。机に風景写真4枚、別の白い配置案、鉛筆。飲物は画面左のトレーに置いたまま。
ハル「この手順だと、最後に注文するんだ。」 ミオ「今日は並べ方の案までにしよう。」場面:手順紙は机へ。①選ぶ・②並べる・③注文を残す。ミオの右指は白い配置案を示し、写真4枚は別にある。注文の実行はしていない。
ハル「使う写真や部数も、注文の前に決めないとね。」場面:ビットが、手順を読むことと操作を分けようと話す。3工程の紙、4写真、まだ白い配置案が別に置かれる。
ビット「手順を読むことと、実際の操作は分けよう。」場面:ハルが右手の鉛筆で配置案に枠を描き、左手で自分側の端を押さえる。ミオは自分側の机に手を置く。上のハルから下のミオへ読む。3工程は残り、進める範囲は並べ方の案まで。注文・支払・発送・完成アルバムはない。
ハル「まず案を作って、進める前に二人で確かめよう。」 ミオ「うん、この範囲からね。」
休日のカフェで二人は、アルバム作りの手順の最後に「注文」があると読み、今日は並べ方の案までと決めました。紙の方法を読むことと実際の注文を分けた場面です。AIが文書を学習したことや、注文が自動実行されたことは示していません。本文ではAgent Skillsと実行する道具の役割を分けます。
仕事の方法を文書として渡す
Agent Skills(エージェントスキル)は、特定の作業方法を再利用できるようまとめる仕組みです。ここで扱う公開形式では、少なくともSKILL.mdというテキストの手順ファイルを含むまとまりにします。何をするためのものか、いつ使うか、どう進めるかなどを記します。モデルが持つ能力そのものと、外から読む手順のまとまりを区別します。
必要なら参考資料、ひな型、スクリプトなども添えられます。スクリプトは処理を記した実行用のプログラムです。手順や関連資料を必要に応じて読み込むことと、添付のプログラムを実行することは別です。名前や場所が文書に書かれているだけで、その処理が終わったとはしません。
根拠:Agent Skills specification(別タブで開く) ↗ / Agent Skills client implementation guide(別タブで開く) ↗
読む手順と、実際に動く道具
道具は、実際の照会・計算・送信などを行う機能です。APIはソフトウェア同士が要求や結果をやり取りする窓口を指します。Skillは作業方法を伝え、その方法に従って道具を使う構成が考えられます。文書を今回の入力として参照することは、モデルを追加学習したことでも、道具を実行したことでもありません。
利用する前に、誰が作ったどの版の手順か、今回の目的や環境に合うかを確認します。版は改訂ごとの違いを識別するものです。参考先や添付プログラムも、何を読み書きし、何を外へ渡すかを確かめます。配布された文書やプログラムを、名前だけで信頼できるものとは決めません。
根拠:Agent Skills specification(別タブで開く) ↗ / Agent Skills client implementation guide(別タブで開く) ↗ / MCP architecture(別タブで開く) ↗ / Anthropic: Effective context engineering for AI agents(別タブで開く) ↗
手順の指示を、新しい許可にしない
架空の案内作成で「下書きだけ。送信は担当者の確認後」と決めたら、Skillに送信手順があっても、その条件を外しません。まず許された下書きを用意し、送る内容と相手を、許可を出せる人に確かめます。外部文書を読むこと自体を、実行や権限付与の証拠にはしません。手順を読める範囲と、その後に行う操作の許可を分けます。
Agent Skills、MCP、A2Aは組み合わせられます。例えばSkillで案内作成の方法を読み、MCP経由で許された資料を取得し、A2Aで別の担当へ確認を依頼する構成です。方法の文書、資料・道具への接続、担当間の通信を分け、各段階で利用範囲と結果を確かめます。どれかの名前が出たことを、残りも接続済み・実行済み・安全だという保証にしません。
根拠:Agent Skills client implementation guide(別タブで開く) ↗ / MCP authorization(別タブで開く) ↗ / Agent2Agent specification(別タブで開く) ↗ / Agent Skills specification(別タブで開く) ↗ / MCP architecture(別タブで開く) ↗
図を拡大する ↗図の内容を文章で確認する
MCPは資料や道具などへの接続、A2Aは担当間の連携通信、Agent Skillsは方法の記述と必要な資料/コードのまとまりです。Skillを読んだ後も出所・版・現在の依頼と許可を確かめます。必要な確認がそろった操作だけ道具やAPIで行い、結果を確認します。下書きまでなら先に下書きを用意し、先の操作は人の確認へ戻します。
- 読者ができること
- Skillを読むことを実行や権限付与へ置き換えず、各方式の役割を説明できる。
- MCP
- 資料・道具などへの共通接続
- A2A
- 担当エージェント同士の連携通信
- Agent Skills
- 作業方法の記述+必要な参考資料/コード
- 図の項目
- Skillの方法を読む
- 図の項目
- 出所/版/現在の依頼:操作の許可を確認
- 図の項目
- 範囲内の道具/APIを使う:実行結果を確かめる
- 図の項目
- まず許された下書きを用意:先の操作は人の確認へ
- 矢印:Skillの方法を読む → 出所/版/現在の依頼:操作の許可を確認
- 読んだ内容を現在の条件と照合
- 矢印:出所/版/現在の依頼:操作の許可を確認 → 範囲内の道具/APIを使う:実行結果を確かめる
- 必要な許可/確認がそろった操作だけ
- 矢印:出所/版/現在の依頼:操作の許可を確認 → まず許された下書きを用意:先の操作は人の確認へ
- 下書きまでの条件ならその範囲で進める
- 重要な条件1
- 3方式の主な役割の比較。組合せ例を全製品の自動動作にしない。
- 重要な条件2
- Skillにはコードを添えられるが、ファイルの読解とプログラム実行は別。
- 重要な条件3
- 送信等の先の手順があっても、今回の確認条件を解除しない。
- 重要な条件4
- 文書の読解をモデルの追加学習にしない。
- 主な流れと薄色の指示
- 太い主な流れは3本。薄色の説明の先端3つは各流れを説明する指示で、別のデータや実行の経路ではありません。
模式図です。項目・矢印・全ての条件は下の文章版にもあります。長い行は拡大の見る位置を順に使い、重なる文を手がかりに続けて読めます。
根拠:Agent Skills specification(別タブで開く) ↗ / Agent Skills client implementation guide(別タブで開く) ↗ / MCP architecture(別タブで開く) ↗ / Agent2Agent specification(別タブで開く) ↗
別の場面で確かめる
全て独自作成の問題です。公式問題や試験全体の難易度を再現したものではありません。


