Bookshelf × MCP
本屋で、ふと手が止まる。
「あれ、この本もう持っていたか?」——そんなときの話。
10年分の読書メモを、まるごと AI に渡してみた。
AI を、
賢くしたのではない。
"自分の本棚"に、繋いだだけ。
AI は何でも知っているように見えて、実は、こちらが何を読んだかだけは知らない。そこだけを埋める小さな道具をひとつ手渡すと、汎用の AI が急に「自分のこと」を分かってくれるようになる——その手ざわりを、読書記録を材料に書いていく。
この記事の問い
何でも知っている AI に「自分だけの道具」を
ひとつ持たせると、なぜ急に頼れる存在になるのか?
そして、手元の PC で動いていた道具を、
なぜわざわざ世界に公開することになったのか?
先に答えを置く。AI を賢くするより、"自分のデータ"に繋ぐほうが、体感はずっと大きく変わる。その繋ぎ方の共通規格が MCP で、思っているよりずっと小さく作れる。作ったあとで「スマホからも使いたい」と欲が出て、そこから話が少しややこしくなる。その"少し"の中身が、この記事の後半だ。
ざっくり言うと
博識なコンシェルジュがいても、あなたの家の本棚の中までは知らない。だから「この本、もう持っている?」には答えられない。そこでコンシェルジュに、自分の本棚だけを覗ける小さな窓をひとつ付ける。すると急に「それは7年前に買っています」と言えるようになる。MCP は、その"窓の付け方"を決めた規格だ。
Chapter 01
ざっくり言うと——「これは読んだか?」は、記録があっても、その場で引けなければ意味がない。読書メモは10年分あるのに、いちばん必要な瞬間に取り出せなかった、という話。
始まりは、いつもの本屋だった。面白そうな一冊を手に取って、そこでピタッと止まる。「これ、前に買っていなかったか?」。思い出せない。スマホで読書アプリを開き、指でスクロールして、たいてい途中で諦める。それで買って帰ると、家の棚に同じ背表紙がいる——そんな失敗を、何度かやっている。
読書の記録自体は、ちゃんとある。読書メーターというサービスに、読んだ本をずっと記録してきた。数えてみたら、読んだ本は1800冊あまり（のべ2000件超）。そのうち、感想まで書いたのが877冊。10年分の読書ログを分析した記事を書いたこともある。この読書メモが、まるごと手元にあるのだ。困るのは、いちばん必要なその瞬間に、それを引けないことだった。
やりたいことは、実はごく素朴だ。「三体は読んだ?」「冨樫義博の本は何冊ある?」「今年は何冊読んだ?」——これに、その場で答えが返ってくればいい。アプリを開いてスクロールするのではなく、ふだん使っている AI に、そのまま聞きたい。
そして、ちょうど手元に、その隙間を埋めてくれる仕組みがあった。MCP だ。
Chapter 02
ざっくり言うと——MCP は「AI に道具を繋ぐための、共通の差し込み口」。USB-C のように形がひとつに決まっているから、道具を作る側は「どの AI 用に作るか」で悩まなくてよくなった。
MCP（Model Context Protocol）は、AI に「外の道具」を持たせるための共通規格だ。2024年11月に公開され、2026年のいまでは事実上の標準として定着している。難しく考える必要はない。スマホの USB-C の差し込み口を思い浮かべればいい。
かつては、機械ごとにケーブルの形がバラバラだった。充電器もイヤホンも、専用の差し込み口がないと使えなかった。USB-C は、それをひとつの形に揃えた。MCP がやったのは、その「AI と道具」バージョンだ。天気を調べる道具、書類を探す道具、そして——自分の読書記録を引く道具。差し込み口の形が同じなら、道具を作る側は「どの AI 用に作るか」で迷わなくていい。
この「作る側が楽になる」が、効いてくる。AI そのものを自分で動かすタイプの仕組み——前に書いた朝刊エージェントのように、API で AI を呼び出してパイプラインを組む話——とは、実は向きが逆だ。あちらは「AI を自分で動かす」。MCP は「できあいの AI に、道具のほうを差し込む」。自分で AI を動かさなくていいぶん、ずっと手軽になる。
2つの向き
AI を自分で動かす：API で呼び出してパイプラインを組む（作り込む）
道具のほうを差し込む：できあいの AI に MCP で足す（軽い）
読書記録を引くだけなら、下の道で十分だ。自分で AI を動かす必要はない。ふだん使っている Claude に、本棚を覗く窓をひとつ足せばいい。やることは、その窓——MCP サーバー——を、ひとつ書くことだけになる。
Chapter 03
ざっくり言うと——道具は「探す・著者で並べる・数える」の3つだけに絞った。増やそうと思えば増やせたが、まず動くものを出すことを最優先にした。
読書記録といっても、中身はただの、タイトル・著者・日付・短い感想が並んだデータの束だ。これを AI から引けるように、道具（ツール）を3つだけ用意した。
· 探す search_books
タイトルや著者の言葉で検索する。「この本、読んだ?」に答えるための道具
· 著者で並べる books_by_author
「冨樫義博の本ぜんぶ」のように、書いた人でまとめて出す
· 数える reading_stats
全部で何冊か・著者ランキング・年ごとの冊数を集計する
これで足りる。感想を全文検索したい、似た本を薦めてほしい、読むペースをグラフにしたい——欲を出せば、道具はいくらでも増やせる。でも、増やさなかった。まず動くものを手元に置いて、実際に使ってから考えればいい。使う前に「あったら便利かも」で足した機能は、たいてい使わないからだ。
同じ考え方を、土台の選定でもした。MCP の TypeScript SDK には新しいバージョン（v2）の準備が進んでいたが、まだ安定する前だった。だから、枯れて動く実績のある v1 系を選び、v2 への引っ越しは「別の日の仕事」にした。動くことがいちばん大事なときに、足元の土台をわざわざ賭けにする理由はない。
まず出す、という考え
「あとで広げやすいように」と土台を作り込むほど、最初の一歩は重くなる。3つに絞って、枯れた土台に乗せる——この2つだけで、その日のうちに動くところまで行けた。広げるのは、必要になってからでいい。
ここまでは、ほとんど迷わずに進んだ。話がややこしくなるのは、この道具を「どこに置くか」を考え始めてからだ。
Chapter 04 — 図で見る
ざっくり言うと——同じ道具でも「手元の PC に置く」か「世界に置く」かで、使える場所が変わる。ブラウザやスマホの Claude から使いたいなら、手元に置いたままでは届かない。
道具は書けた。次は「どこで動かすか」だ。選べる道は2つある。手元の PC の中で動かすか、インターネットに置いて、世界から呼べるようにするか。下の図が、その違いのすべてだ。
上の段は「手元の PC の中」ですべて完結する。手軽だが、ブラウザ版の Claude（claude.ai）からは届かない——PC の中で動くものに、ブラウザは繋がれないからだ。下の段は、サーバーをインターネットに置いて、どこからでも呼べるようにする。かわりに、誰でも叩ける入口になってしまうから、鍵を2つかける。「どこからでも使える」と「誰でも叩ける」は、同じことの表と裏なのだ。
最初は、上の段だけで満足していた。手元の Claude から本棚を引ければ、やりたかったことはできている。でも「スマホからも使いたい」と思った瞬間、話は下の段へ動いた。前提が変わったのだ。次の章は、その下の段——世界に開けることの、代償の話になる。
Chapter 05
ざっくり言うと——サーバーを世界に置くと、誰でも叩ける入口になる。認証の仕組みを作り込むかわりに、「発信元を絞る」「入口を秘匿する」の2つで守った。データはすでに公開しているから、守る対象は秘密ではなく、無駄に叩かれないことだ。
ブラウザの Claude から自分の道具を使うには、そのサーバーをインターネット上の URL として公開する必要がある。仕組みのうえで、AI 本体は自分の PC からではなく、Anthropic のクラウド側からその URL を叩きに来る。だから URL は、世界に開いていなければならない。
世界に開いた入口には、当然、心配ごとがある。普通ならここで「ログイン（認証）」を作り込むところだが、その仕組みは重い。自分の読書記録に、そこまで積むのは大げさだ。そこで認証を作らないかわりに、軽い鍵を2つだけかけた。
このサーバーをまっとうに叩いてくるのは、Anthropic のクラウドだけだ。だから送信元 IP をその帯域（160.79.104.0/21）に限定して、あとは門前払いにする。自分の PC からブラウザで直接開いても弾かれる——それが正常、という状態にした。
URL の後ろに、推測では辿り着けない長いシークレットパスを付ける。パスを知らなければ、正しい URL にも入れない。しかもこのパスは、公開しているコードには書かず、動かすときだけ環境変数で外から渡す。公開リポジトリをどこまで探しても、パスは出てこない。
ここで、正直に前提をひとつ置いておきたい。読書記録のデータそのものは、すでに公開している。サーバーのコードと一緒に、誰でも見られる場所に置いた。だから2つの鍵の狙いは、「秘密を守る」ことではない。
守っているのは秘密ではない
最悪、誰かにサーバーを叩かれても、返ってくるのは「もう公開済みの1808冊」だけ。
だから鍵は、秘密のためではなく「無駄に叩かれない」ためにかけている。
この見極めは、大事だと思っている。守るものの正体を「秘密」だと勘違いすると、認証だの暗号だのを、どんどん積みたくなる。でも守っているのは秘密ではなく、ただの落ち着き（無駄に叩かれて課金されない、という程度の安心）だ。そう見切れば、鍵は2つで足りる。認証なしで入口を開けること自体は、Anthropic の公式も想定の内だ——公開する入口の、気をつけるポイントを踏まえたうえで、読み取り専用の道具に限って、の話ではあるが。
Chapter 06
ざっくり言うと——世界に置く土台は、余計な部品を足さなければ月額ほぼ0円に収まる。ただ、途中で部品どうしの相性に一度つまずいた。安く上げる道は、たいてい少し回り道になる。
世界に置く土台には、使った瞬間だけ立ち上がるタイプのサーバー——AWS Lambda を選んだ。待っている間は課金されない。個人が月に数十回叩く程度なら、無料枠に収まって、実際0円だ。この「持つより、呼ぶほうが安い」という考えは、このサイトそのものの作りや、朝刊エージェントの運用費を1/10にした話と同じ筋にある。
0円を守るために、わざと足さなかった部品が2つある。手前に置く API Gateway（入口を別立てにする部品）と、WAF（怪しいアクセスを弾く専用サービス）。どちらも「あると見栄えがいい」が、月額が乗ってしまう。先ほどの2つの鍵は、この2つを足さずに済ませるための工夫でもあった。守り方を軽くすれば、作りも安くなる。
つまずいた1つ
途中で、正しい入口はちゃんと動くのに、間違った入口を叩くと変なエラー（500）が返る症状にぶつかった。原因は、Web フレームワーク（express）の新しい5系と、それを Lambda に載せるアダプタの相性だった。新しくすれば良い、というものではないのだ。枯れて相性の取れた express 4系に揃え、未定義の入口には自分で明示的に404を返す一手間を足したら、きれいに収まった。
この手のつまずきは、記事ではよく省かれる。だが実際の作業は、半分がこういう相性合わせでできている。新しい部品ほど良い、とは限らない。「枯れた組み合わせ」を選ぶのは、SDK で v1 系を選んだのと同じ考えだ。地味だが、これが効く。
もうひとつ。AWS 公式の「Lambda 用 MCP アダプタ」も検討したが、使わなかった。それを使うと AWS の IAM 認証が前提の作りになり、ふだんの Claude（カスタムコネクタ）からはそのまま繋げないのだ。公式だから最適、とも限らない。やりたいこと（認証なしで、ふだんの Claude から繋ぐ）に、素直な構成を選ぶほうが、結局まっすぐだった。
Chapter 07
ざっくり言うと——「自分のデータに繋ぐ」「欲張らない」「前提が変わったらやり直す」。この3つが、今回いちばん効いた芯だった。
本屋の小さな困りごとから始めて、公開までやってみた。持って帰れる芯を、3つだけ。
汎用の AI をどう賢く使うか、より、"自分のデータ"に繋ぐほうが、体感は大きく変わる。博識なコンシェルジュに、自分の本棚を覗く窓をひとつ足すだけで、「自分のこと」を分かってくれるようになる。繋ぐ先は、読書記録でなくてもいい。家計でも、レシピでも、日記でも、同じ形が効く。
道具は3つ、土台は枯れたバージョン、守りは軽い鍵2つ。「あとで広げやすいように」を我慢するほど、最初の一歩は軽くなる。使う前に「あったら便利かも」で足した機能は、たいてい使わない。まず出して、使ってから足せばいい。
「手元で使えれば十分」で始めた道具は、「スマホからも」で前提がひっくり返り、公開する作りにやり直しになった。最初の決めごとが古くなったら、素直にやり直す。欲張っていなければ、やり直しも軽い。1と2は、3のための備えでもあるのだ。
いちばんの収穫は、道具そのものより「自分のデータに AI を繋ぐ」入口の低さを、体で分かったことだった。難しいのは AI のほうではなく、たいてい自分のデータを、どう小さく切り出して渡すかのほうにある。読書記録は、その練習にちょうどよかった。
本屋で「これは読んだか?」と固まったら、いまはポケットの中の Claude に聞けばいい。AI エージェントの大きな話の手前には、こういう半日で作れる小さな繋ぎ目が、いくつも転がっている。
Afterword — 後日談
ざっくり言うと——この記事を公開した、その日のうちに「使ってから足す」が実際に起きた。増やしたのはツールではなく、データの種別。道具3つの形はそのまま、読書記録は"メディア記録"になった。
実は、この話には続きがある。記事を公開した、その日のことだ。使ってみると、同じ形の問いが本の外にもあることに、すぐ気づいた。観た映画、観たアニメ、やったゲーム——「これ観た?」「これやった?」は、「これ読んだ?」とまったく同じ形をしている。
それで、広げた。といっても、やったのはツールを増やすことではない。データの種別を増やしただけだ。Prime Video の視聴履歴、Audible や Kindle の購入記録——あちこちのサービスに散らばっていた記録をかき集めて、読書記録と同じ形の束に揃えた。いまは本・オーディオブック・映画・アニメ・ドラマ・バラエティ・ゲームの7種別が、ひとつの窓から引ける。
道具は、3つのままだ。「探す」「作り手で並べる」「数える」——それぞれに種別の絞り込みを足し、名前を search_books → search_media のように付け替えた。「著者」が「作り手（creator）」になったのは、著者・監督・開発元をひとことで言うためだ。リポジトリの名前も、読書専用のものから media-log に改めた。
ここで、Ch.03 の決めごとが効いてくる。最初に3つへ絞ってあったから、広げるときも「3つに種別を足す」だけで済んだ。もし最初から道具を10個作り込んでいたら、改修も10個ぶんだった。欲張らない設計は、出すときだけでなく、広げるときも軽い。「使ってから足せばいい」と書いた手前もあるが——まさか、書いたその日に足すことになるとは思っていなかった。
Coda
AI を、賢く
したのではない。
"自分の本棚"に、
繋いだだけ。
難しいのは、たいてい AI のほうではない。
自分のデータを、どう小さく切り出すか——そちらにある。
読書記録は、たまたま手元にあった材料にすぎない。家計でもレシピでも日記でも、「自分のデータに窓をひとつ付ける」という形は変わらない。半日あれば、本屋で固まる時間は消せる。道具は小さくていい。効くのは、繋がっていること、それ自体だ。
Fact-check
主要な事実は一次情報にあたっている：MCP（Model Context Protocol）は Anthropic が2024年11月に公開したオープン規格。リモート接続の通信方式 Streamable HTTP は2025年3月のMCP仕様改訂で採用。Anthropic 側の送信元 IP 帯（160.79.104.0/21）と、カスタムコネクタの登録条件（無料プランでも1個まで・認証は任意）は Anthropic の公式ドキュメントで確認。AWS Lambda の無料枠（月100万リクエスト＋40万GB秒）は AWS 公式の料金ページのとおり。読書の数は、読んだ本（ユニーク）1810冊・のべ2041件・感想を書いたのが877冊——公開MCPは、地域が分かる2件だけ除いた1808冊（感想875）を配信している。後日談の汎化——道具3つのまま、本・オーディオブック・映画・アニメ・ドラマ・バラエティ・ゲームの7種別へ——は、公開リポジトリ（media-log-mcp）のREADMEとコミット履歴のとおり（種別追加と改名は、この記事の公開当日〜翌朝に行われた）。一方で、「賢くするより繋ぐほうが効く」「欲張らないほど出せる」といった主張は、外部調査ではなく、実際に作ってみての筆者の実感だ。事実の誤りには、反論を歓迎する。