リソース：読み取り専用のデータをアプリに渡す

前のレッスンでは、リソースを「アプリが選ぶ、読み取り専用のデータ」とひとまとめに扱いました。ここからは、その中身をもう一段掘り下げます。

リソースはHTTPのGETに近い

ツールは「実行」を担い、呼ぶたびに何かが変わることがあります。値を書き込む、メールを送る、計算する。副作用があるということです。

リソースはそれと対照的です。読み取り専用で、同じURIを何度読んでも壊れるものは何もありません。ウェブでいうGETリクエストに近い性質を持っています。

この違いを覚えておくと、「これはツールにすべきか、リソースにすべきか」を設計するときの判断が速くなります。

直接リソースと、パラメータ付きのテンプレート化リソース

リソースには2つの指定のしかたがあります。

一つは、URIが固定された直接リソースです。「議事録の一覧」のように、いつ呼んでも同じ場所を指します。もう一つは、URIの一部が変数になったテンプレート化リソースです。「この議事録IDの中身」のように、呼ぶたびに対象が変わります。

テンプレート化リソースのパラメータは、入力の途中で候補を補ってもらえる仕組み（補完API）と組み合わせられます。「@」に続けて名前の一部を打つと候補が絞り込まれていく、というような体験は、この仕組みの上に成り立っています。

購読すると、変更のたびに知らせてくれる

リソースには、もう一つ覚えておく価値のある機能があります。購読です。

対応しているサーバーであれば、特定のリソースを購読しておくと、そのリソースの中身が変わるたびに通知が届きます。ポーリングで「変わっていないか」を毎回尋ねに行く必要がありません。

ただし購読は、すべてのサーバーが対応しているとは限らない任意の機能です。サーバー側がこの機能を持つと宣言していなければ、購読自体ができません。つないだサーバーが対応しているかどうかは、確かめてから前提にする必要があります。

アプリがどう組み込むかは、決まった正解がない

前のレッスンでも触れたとおり、リソースを最終的にどう会話へ組み込むかは、つないでいるアプリ側の設計です。公式仕様はやり方を一つに決めていません。

同じリソースの仕組みでも、つなぐ先のアプリによって体験が変わる理由はここにあります。プロトコルが決めているのは「読み取り専用のデータを、URIで指し示して渡せる」というところまでです。

やってみよう

演習1：どちらのリソースにするか考える

自分が欲しい「読み取り専用のデータ」を1つ思い浮かべてください。それは固定のURIで指せる直接リソースが向いているか、パラメータで対象を絞るテンプレート化リソースが向いているか、理由とあわせて考えてみてください。

演習2：購読する価値があるか考える

演習1で挙げたリソースは、頻繁に中身が変わるものでしょうか。変わるたびに知りたいものであれば、購読する価値があります。逆にめったに変わらないものなら、購読より毎回読みに行く方がシンプルかもしれません。どちらが自分の用途に合うか考えてみてください。

今日のまとめ

3行で振り返ります。

• リソースは読み取り専用で、ツールと違って何度読んでも状態を変えない
• URIが固定の直接リソースと、パラメータで対象が変わるテンプレート化リソースの2種類がある
• 購読に対応したリソースは、変更のたびに通知を受け取れる（ただし任意機能で、対応の有無はサーバー次第）

次のレッスンでは、もう一つの「ユーザーが選ぶ」土台、プロンプトを深掘りします。あなたが毎回書くプロンプトと、サーバー作者が用意するプロンプトの違いから始めます。