Posts

MCPとは、AIアプリケーションを外部のデータソースやツールへつなぐためのオープンなプロトコルです。標準化されているのは接続の中身ではなく手順です。具体的には、JSON-RPC 2.0のメッセージ形式、ホスト／クライアント／サーバーという3役の分担、サーバーが出せる機能の種類（Resources・Prompts・Tools）、そして各リクエストがどのバージョンで話しているかの宣言方法です（MCP仕様 2026-07-28 2026-09-16閲覧）。 そして「MCPとは」を調べるときに最初に確かめるべきは、読んでいる解説がどのリビジョンの話かです。現行リビジョンは2026-07-28で（Versioning 2026-10-04確認）、この版はinitializeハンドシェイクとMcp-Session-Idを廃止し、プロトコルをステートレスに変えました（同 Key Changes 2026-09-16閲覧）。つまり「まずinitializeでセッションを張り、能力をネゴシエートする」という説明は、2025-11-25以前のリビジョンの説明です。旧リビジョンの説明が誤りになったわけではなく、使うホストやサーバーが旧リビジョンで話していれば、その接続では今もinitializeを使います。仕様はYYYY-MM-DDという識別子を使い、後方非互換な変更が最後に入った日付を示します。 この記事の日付について。 2026年9月16日に調査・執筆し、公開日の2026年10月4日に、仕様の現行リビジョン・HTTPヘッダー・MRTR・ベンチマークの指標などを一次資料で再確認して更新しました。本文と出典表の「2026-09-16」は執筆時、「2026-10-04」は公開前の再確認の日付です。筆者環境の観測値は2026年9月16日の記録です。2026年10月11日に第8節〜第10節（代表的なサーバーの例・料金・Claude Code での接続方法）と、よくある質問4項目を追記しました（「2026-10-11確認」はその日の確認です）。 この記事でわかること MCPを1文で説明するための定義と、何が標準化されていて何は標準化されていないのか ホスト・クライアント・サーバーの3役と、tools/listからtools/callまでに流れるJSON-RPCの中身（_metaの必須フィールドとエラーコード） 自分が読んでいる解説がどの仕様リビジョンの話かをinitializeの有無で判別する方法と、5リビジョンの対応表 2026-07-28でDeprecatedになった機能（Roots・Sampling・Logging）と、最短で削除される時期 導入前に踏むべきリスク確認の項目と、攻撃ベンチマーク論文が報告した「能力の高いモデルほど脆弱」という結果 1. MCPとは──1文の定義と、誰が出しているのか 定義は公式仕様の冒頭が短く書いています。MCPは「LLMアプリケーションと外部のデータソース・ツールとのシームレスな統合を可能にするオープンプロトコル」です（MCP仕様 2026-09-16閲覧、原文は英語）。2024年11月にAnthropicが公開し、2025年12月にLinux Foundation傘下のAgentic AI Foundationへ寄贈された仕様ですが、仕様リポジトリのLICENSEはMITからApache-2.0への移行中の複合ファイルで、前文に続けてApache-2.0とMITは全文、CC-BY-4.0は見出しと外部リンクによる参照という順で並んでいます。新規のコードと仕様の寄与にはApache-2.0が適用され、仕様を除くドキュメントの寄与はCC-BY-4.0です。MITセクションに置かれた著作権表記は「Copyright (c) 2024-2025 Model Context Protocol a Series of LF Projects, LLC.」で、リポジトリのREADMEは今も「This project is licensed under the MIT License」と記載しています（modelcontextprotocol/modelcontextprotocol LICENSE・同リポジトリREADME 2026-09-16閲覧）。単独ベンダーの仕様から、Linux Foundation系のプロジェクトへ器が移っている状態です。 仕様本文は、MCPがLanguage Server Protocol（LSP）から着想を得たと明記しています。LSPが「プログラミング言語への対応をエディタ横断で標準化した」のと同じ形で、MCPは「文脈とツールをAIアプリ横断で標準化する」という位置づけです。ここを押さえると、MCPが何をしないかも見えます。MCPはモデルの重みを変える仕組みではなく、つなぎ先のAPIの中身も決めません。 AI以外のMCPとの切り分け 「MCP」という略語は他分野にもあります。IT資格（Microsoft Certified Professional）、医療の中手指節関節（metacarpophalangeal joint）、日本の除草剤の慣用名（MCPソーダ塩。有効成分名はMCPAナトリウム塩）、電子部品の型番接頭辞（MicrochipのMCP3008など）で同じ3文字が使われます（Microsoft Learn・NCBI Bookshelf（中手指節関節）・石原バイオサイエンス 石原MCPソーダ塩・Microchip MCP3008 2026-09-16閲覧）。本記事が扱うのはAI文脈のModel Context Protocolだけです。別分野のMCPを調べている場合、この記事の内容は当てはまりません。 なぜ2024年11月に出てきたか 初出はAnthropicの2024年11月25日の発表です。同日に公開されたのは、仕様とSDK、Claude Desktopアプリでのローカルサーバー対応、サーバー実装のオープンソースリポジトリ、そしてGoogle Drive・Slack・GitHub・Git・Postgres・Puppeteer向けの既製サーバーでした。発表時点の採用例としてBlockとApolloが挙げられ、開発ツール側ではZed・Replit・Codeium・Sourcegraphの名前が並んでいます（Anthropic『Introducing the Model Context Protocol』 2026-09-16閲覧）。背景は単純です。ツール連携の実装がクライアントごとにばらばらで、同じ連携を各アプリ向けに作り直す必要があったからです。 ...

この記事の日付について。 2026-09-26に調査・執筆し、公開日の2026-10-04に、Ollama公式ライブラリのタグ別サイズ(gemma4・qwen3.6・qwen3・qwen3.8・qwen3-next)、Ollama公式FAQの ollama ps の説明、筆者環境の ollama list / ollama show の表示を再確認して更新しました。本文中の「2026-09-26確認」は執筆時、「2026-10-04確認」は公開前の再確認の日付です。筆者環境の計測値は、断りがない限り2026-09-26の記録です。 この記事でわかること 手元のメモリが8GB・16GB・24GB・32GB以上のとき、Ollamaでそのまま使える日本語向けの候補がどれか 候補をモデル名の「B数」ではなく、Ollamaで落ちてくる実ファイルのサイズで選ぶ理由 DGX Spark(統合メモリ128GB)で実際に使い続けているモデルと、品質不足でやめた構成の記録 Gemma 4・Qwen3.6・Qwen3のライセンスと、商用利用の根拠URL 今日中に動かし始めるための最短のコマンドと、コンテキスト長の落とし穴 結論から書きます。32GB以上のメモリがあるなら、筆者が日常運用している qwen3.6:35b-a3b(23〜24GB)が最初に試す候補です。24GBなら gemma4:26b(16〜19GB)か qwen3.6:27b(18〜19GB)、16GBでは gemma4:12b(7.7〜8.0GB)か qwen3:14b(9.3GB)、8GBでは qwen3:8b(5.2GB)か qwen3:4b(2.5GB)が現実的な線です。サイズはいずれもOllama公式ライブラリの表示値です(2026-10-04確認)。 ただし、ファイルサイズがメモリより小さいことは動作の保証になりません。実行時にはKVキャッシュや作業用のバッファも必要で、短いコンテキストから試して ollama ps で配置を確かめる前提の候補です。筆者が実機で品質まで確かめたのは32GB以上の帯だけで、8〜24GB帯の候補は公式サイズから選んだ段階です。どこまでが実測で、どこからが公式値からの逆算かは、表ごとに明記します。 1. 選び方の基準──「何B」ではなく「何GB」で決める ローカルLLMの紹介記事は、モデルを「7B」「27B」のようなパラメータ数で並べがちです。しかし、手元のPCに載るかどうかの大部分を決めるのは、量子化したあとのファイルサイズと、会話中に増えるKVキャッシュの合計です。これに実行時のバッファや、画像入力を使う場合の処理分が加わります。同じ「26B」でも、16ビットなら57.7GB、4ビット(Q4_0)なら14.4GBと4倍の開きがあります(Google AI for Developers『Gemma 4 model overview』最終更新2026-07-08)。 この記事では、次の4点で候補を絞りました。 メモリに載るか: Ollama公式ライブラリに表示されるタグ別サイズが、手元のメモリより十分小さいこと 日本語が使えるか: 開発元のモデルカードが多言語対応を明記していること。実測できたものは実測結果を優先 Ollamaで1コマンドで取れるか: 公式ライブラリにタグがあり、ollama pull だけで始められること 商用で使えるか: ライセンスが開発元の一次資料で確認でき、商用利用を妨げる独自条項がないこと 「量子化」は、モデルの重みを16ビットから8ビットや4ビットに丸めて小さくする処理です。Ollamaの標準タグは多くが4ビット前後に量子化済みで、q8_0 や bf16 の付いたタグはより大きく、元の精度に近い版です。たとえば qwen3.6:27b は標準で18〜19GB、q8_0 で30GB、bf16 で56GBです(Ollama library qwen3.6 tags 2026-10-04確認)。 2. 一次資料の対応表 この記事の数字は、次の一次資料と筆者の作業記録から取っています。 主張 一次資料 種別 確認日 gemma4の各タグのサイズ(e2b 4.6〜7.5GB、e4b 6.6〜9.5GB、12b 7.7〜8.0GB、26b 16〜19GB、31b 19〜20GB)とコンテキスト長 Ollama library gemma4 tags 公式ライブラリ 2026-10-04 qwen3.6の各タグのサイズ(27b 18〜19GB、35b-a3b 23〜24GB、q8_0/bf16版を含む) Ollama library qwen3.6 tags 公式ライブラリ 2026-10-04 qwen3の各タグのサイズ(4b 2.5GB、8b 5.2GB、14b 9.3GB) Ollama library qwen3 公式ライブラリ 2026-10-04 Gemma 4の5サイズと、BF16・SFP8・Q4_0別の重みのメモリ量 Google AI for Developers『Gemma 4 model overview』 公式ドキュメント 2026-09-26 Gemma 4はApache 2.0、事前学習140超・そのまま使える35超の言語 Hugging Face google/gemma-4-26B-A4B-it、Google Open Source Blog 2026-04-02 モデルカード・公式ブログ 2026-09-26 Qwen3.6-35B-A3B・Qwen3.6-27BはApache 2.0 Hugging Face Qwen/Qwen3.6-35B-A3B、Qwen/Qwen3.6-27B モデルカード 2026-09-26 Qwen3-8BはApache 2.0、100超の言語と方言に対応 Hugging Face Qwen/Qwen3-8B モデルカード 2026-09-26 Ollamaの既定コンテキスト長はVRAM量で4k/32k/256kに変わる Ollama docs: Context length 公式ドキュメント 2026-09-26 llama.cppはMITライセンス、1.5〜8ビットの整数量子化に対応 GitHub ggml-org/llama.cpp GitHub 2026-09-26 DGX Sparkでの速度・品質の実測、登録モデルとサイズ、ローカルLLMでの記事生成をやめた経緯 筆者の作業記録(2026-04-03、2026-07-14、2026-08-04、2026-09-08) 実測・運用記録 2026-09-26 Ollamaのqwen3.6のページには、ライセンスの記載がありませんでした(2026-09-26確認)。ライセンスはHugging Faceのモデルカードで確認しています。 ...

この記事の日付について。 2026-09-27に調査・執筆し、公開日の2026-10-04に、Ollama公式FAQ(プライバシー・ollama ps・クラウド無効化の記述)、Ollamaのクラウドモデル一覧とドキュメント、Ollama library qwen3.6 tags、Qwen3-8Bの設定ファイルとモデルカード(コンテキスト長)、筆者環境の ollama list / ollama show の表示を一次資料で再確認して更新しました。本文中の「2026-09-27確認」は執筆時、「2026-10-04確認」は公開前の再確認の日付です。筆者環境の計測値は、断りがない限り2026-09-27の記録です。2026-10-11に第7節・第10節・第11節とよくある質問6項目を追記しました(「2026-10-11確認」はその日の確認です)。 この記事でわかること ローカルLLMの定義と、ChatGPTのようなクラウドLLMとの違い Ollama・LM Studioを使うとき、入力が手元に留まる範囲と、通信が発生する操作 重み・量子化・実行ソフトの3つで、手元の推論が成り立つ仕組み 自分のPCで動くかを、パラメータ数とビット数から見積もる計算方法 ローカルLLMが向く作業と、向かない作業 ローカルLLMとは、大規模言語モデル(LLM)の推論を自分のPCや自社サーバーの上で実行する使い方です。モデルの重みファイルを手元に置き、実行ソフトがそれを読み込んで文章を生成します。 ChatGPTとの違いは「どこで計算するか」です。クラウドLLMは入力を提供元のサーバーへ送って処理します。ローカルLLMは、モデルを取得したあとなら通信なしで応答できます。LM Studioの公式ドキュメントは、ダウンロード済みモデルとのチャットで入力した内容は端末の外に出ないと明記しています(LM Studio Docs『Offline Operation』2026-09-27確認)。動かせるかどうかは、主にメモリ量で決まります。小型の量子化モデルなら一般的なPCも候補になります。ただし必要量は重みだけでなくKVキャッシュや実行バッファでも変わるため、空きメモリと実際のロード状態を確認します。 1. ローカルLLMとは──「ローカル」は推論の実行場所を指す LLMを使う処理は、大きく「学習」と「推論」に分かれます。学習は大量の計算資源で重みを作る工程です。推論は、できあがった重みに文章を入力して続きを出させる工程です。 ローカルLLMの「ローカル」は、このうち推論をどこで実行するかを指します。学習まで手元で行う必要はありません。Qwen・Gemma・Llamaのように、開発元が重みを公開しているモデル(オープンウェイトモデル)をダウンロードして使うのが一般的です。 そのため「ローカルLLM」という名前のモデルがあるわけではありません。同じQwen3-8Bでも、自分のPCで動かせばローカル、クラウドのAPI経由で使えばクラウドです。 2. 一次資料の対応表 この記事の事実関係は、次の一次資料と筆者の運用記録から取っています。 主張 一次資料 種別 確認日 ローカル実行時、Ollamaはプロンプトやデータを見ない。既定の待ち受けは localhost の11434番ポート Ollama FAQ 公式ドキュメント 2026-09-27(プライバシーの記述は2026-10-04再確認) Ollamaはモデルをインターネットから取得する。モデルの保存場所、既定で5分間メモリに保持 Ollama FAQ 公式ドキュメント 2026-09-27 Ollamaのクラウド機能は OLLAMA_NO_CLOUD=1 で無効化できる Ollama FAQ 公式ドキュメント 2026-10-04 Ollamaのクラウドモデルには公開重みのモデルも並ぶ Ollama cloud models、Ollama docs: Cloud 公式ライブラリ・ドキュメント 2026-10-04 Ollamaの既定コンテキスト長はVRAM量で4k/32k/256kに変わる。ollama ps の列の意味 Ollama docs: Context length 公式ドキュメント 2026-09-27 LM Studioはモデル取得後はオフラインで動き、入力と文書は端末外に出ない。通信が要る5つの操作 LM Studio Docs『Offline Operation』 公式ドキュメント 2026-09-27 llama.cppは1.5〜8ビットの整数量子化、CPUとGPUの併用推論に対応。MITライセンス GitHub ggml-org/llama.cpp GitHub 2026-09-27 Qwen3-8Bは8.2Bパラメータ、36層、KVヘッド8、Apache 2.0。コンテキスト長は標準32,768トークン、YaRN併用で131,072トークン Hugging Face Qwen/Qwen3-8B、config.json モデルカード・設定ファイル 2026-09-27(コンテキスト長は2026-10-04確認) qwen3:8b の標準タグはq4_K_Mで5.2GB、q8_0は8.9GB、fp16は16GB Ollama library qwen3 tags 公式ライブラリ 2026-09-27 DGX Sparkでのモデル重みのサイズ・メモリ配分・生成速度 筆者の作業記録(2026-03-15、2026-08-04) 運用記録 2026-09-27 CPUのみの動作、Apple M系の対応、生成速度とメモリ帯域の関係 Ollama docs: macOS、llama.cpp Discussion #4167、Apple Newsroom 公式ドキュメント・GitHub・公式発表 2026-10-11 Qwen・Llama 3.3・Gemmaの商用利用条件、Ollamaのコーディング連携 各モデルのLICENSE、Gemma Terms of Use、Ollama docs: Integrations ライセンス文書・公式ドキュメント 2026-10-11 企画段階では、DGX Spark上でネットワークを遮断した状態の動作と、ollama ps・生成速度を新たに測る予定でした。この記事の公開時点では、その測定はまだ行えていません。そのため後半の数字は、過去の作業記録にある値と、一次資料からの計算値に限っています。 ...

MCPサーバーは「良さそうなものを片端から入れる」と壊れます。壊れるのは接続ではなく、セッション開始時のコンテキストと、ツール選択の精度です。 Anthropic公式ドキュメントは数字で明言しています。ツール定義は50本で1万〜2万トークンを消費し、GitHub・Slack・Sentry・Grafana・Splunkを並べた構成では作業前に約55,000トークンが埋まる。そしてツール選択の精度は30〜50本を超えると落ちる（Claude Platform Docs『Tool search tool』 2026-09-14閲覧）。ただしこの数字は、ツール定義がコンテキストに同時に載っている場合の話です。Claude Codeのようにツール探索が既定で有効なクライアントでは、登録した本数と実際に載る定義数は一致しません。だから選び方の順序は「候補を見比べてから選ぶ」ではなく、自分のクライアントでツール探索が効いているかを確かめ、実際に載る定義数を数えてから候補を当てはめるになります。 この記事でわかること MCPサーバーを増やすと何が増えるのか──公式が出している消費トークンの実数と、30〜50本という精度の境界 ツール探索の有無で何が変わるか。自分の環境で「実際に載る定義」を無料で数える手順（トークン数え上げエンドポイントの使い方とJSONの例） 一次資料で提供主体・接続方式・ライセンスを確認できた候補17項目（19サーバー）の一覧表と、公式保守かどうかの見分け方 Claude Code / Codex CLI / Cursor それぞれの設定ファイルの場所と、ツールを絞るための設定項目 結論としての最初の構成の決め方（全定義を載せる構成なら合計30本前後という筆者の運用目安、探索が有効なら登録数より絞り込みの機構を見る） 1. 結論──ツール探索の有無を先に確かめ、上限は合計ツール本数で決める 最初の問いは「MCPサーバーは結局どれを入れればいいのか。全部入れると何が起きるのか」です。答えは順に2つです。 全部入れると何が起きるかは、クライアントがツール探索を使っているかで変わります。ツール探索を切って全定義を載せる構成では、セッションを開くだけでコンテキストが数万トークン埋まり、ツールの選択ミスが増えます。ツール探索が有効な構成では、定義は必要になった時点で読み込まれるため、登録本数がそのまま消費になるわけではありません。どちらの場合も、公式の数字（50本で1万〜2万トークン、30〜50本で精度低下）に自分の構成を当てると、上限は「サーバー本数」ではなく同時に載る合計ツール本数で決まると分かります。1本で40本以上のツールを出すサーバーもあるため、本数の議論はサーバー単位では成立しません。 そのうえで最初の構成は、次の順で決めます。第一に、自分のクライアントでツール探索が有効かを確認します（Claude Codeは既定で有効です。第6節）。第二に、ツール探索を切って全定義を載せる構成なら、合計ツール本数が30本前後に収まる範囲で選びます。この30本前後は公式の30〜50本という境界の下限側に寄せた筆者の運用目安で、公式が示した数値ではありません。役割配分の出発点は、①毎日触るSaaSのベンダー公式サーバー1本、②クライアントの組み込み機能と重複しないリファレンス実装1本、③案件ごとに差し替える空き枠1本です。第三に、ツール探索が有効な構成では、登録本数の上限よりも、ツールセットの絞り込み（--toolsets、enabled_tools）と権限ルールで「モデルに見せる定義」を減らせるかを見ます。本記事の計測ではNotion1本で43本、Gmail1本で29本のツールが出ましたが、このセッションではツール探索が有効だったため、この72本がそのままコンテキストに載っていたわけではありません（第6節）。理由は第4節から第6節で示します。候補の一覧は第5節の表です。 2. 本記事が確認した一次資料と、測っていないこと GPUやVRAMは本記事の判断に関係しないため記載しません。代わりに、本文の主張と一次資料の対応を先に出します。すべて2026-09-14に取得しました。 主張 一次資料 種別 確認日 ツール定義は50本で1万〜2万トークン、精度は30〜50本超で低下 Claude Code Docs『Scale to many tools with tool search』 公式ドキュメント 2026-09-14 5サーバー構成の定義が約55,000トークン、ツール探索で85%超の削減 Claude Platform Docs『Tool search tool』 公式ドキュメント 2026-09-14 仕様の現行リビジョンは2026-07-28版。トランスポートはstdioとStreamable HTTPの2つ MCP仕様 2026-07-28 / 同 transports 公式ドキュメント 2026-09-14 ツールは任意コード実行として扱い、ツール注釈は信頼できない前提とする MCP仕様 2026-07-28 公式ドキュメント 2026-09-14 リファレンス実装は7本、アーカイブ済みは13本。新規貢献はApache-2.0、既存コードはMIT modelcontextprotocol/servers GitHub 2026-09-14 Claude Codeのsseはdeprecated。スコープはlocal / project / user Claude Code Docs『MCP』 公式ドキュメント 2026-09-14 Codex CLIは~/.codex/config.toml、起動タイムアウト既定10秒、enabled_toolsでツールを絞れる OpenAI『MCP』(surface=cli) 公式ドキュメント 2026-09-14 Cursorは.cursor/mcp.jsonと~/.cursor/mcp.json。既定でツール実行前に承認を求める Cursor Docs『MCP』 公式ドキュメント 2026-09-14 GitHub公式サーバーはMIT、リモート版はhttps://api.githubcopilot.com/mcp/ github/github-mcp-server GitHub 2026-09-14 トークン数え上げエンドポイントはtools配列を受け取り、無料で使える Claude Platform Docs『Token counting』 公式ドキュメント 2026-09-14 測っていないことも明示します。本記事は、候補17項目（19サーバー）を3クライアントへ順に接続した接続可否・起動秒数・3回試行での失敗回数を計測していません。計測したのは、執筆環境のClaude Codeセッションに実際につながっていたサーバーのツール本数だけです（第6節）。横断マトリクスの残りは推定値で埋めず、未計測のまま置きます。手順は第6節に書いたので、同じ数え方を自分の構成で再現できます。 ...

この記事でわかること 自分の OS でインストールからログインまで、実際に打つコマンドの並び 最初のセッションで何をどう書くか。公式が例示している最初の3プロンプト CLAUDE.md の置き場所4スコープと、最初の1本に書く項目 手元31リポジトリの CLAUDE.md の実測行数分布と、公式の「200行以下」との差 command not found など、エラーメッセージ別の対処 最初に結論だけ書きます。インストールから CLAUDE.md の初版を整えるまでは、curl -fsSL https://claude.ai/install.sh | bash → claude --version → プロジェクトへ cd → claude → ブラウザでログイン → 質問を1つ投げる → /init で CLAUDE.md を生成 → 手で削る、の8手です。macOS・Linux・WSL はこの1行で入り、Windows は PowerShell なら irm https://claude.ai/install.ps1 | iex に置き換わります（Claude Code Docs「クイックスタート」 2026-09-13確認）。 そのうえで、この記事が上位ページと違うのは後半です。CLAUDE.md は「書け」で終わっている解説がほとんどですが、実際に何本も運用すると何行に落ち着くのかという記録が見当たりません。手元の31本を数えたところ、中央値は41行、平均76.0行で、公式が挙げる200行を超えていたのは2本だけでした。ただし、同時に読み込まれる祖先ディレクトリの CLAUDE.md を足すと、200行を超える組み合わせは6本に増えます（§7）。 1. 一次資料の対応表と検証環境 本文の事実はすべて以下から取りました。ローカルの実測は末尾2行です。 主張 一次資料 種別 確認日 インストールコマンド・対応OS・WSL とネイティブの差 高度なセットアップ 公式ドキュメント 2026-09-13 CLAUDE.md の4スコープ・200行の目安・.claude/rules/ Claude があなたのプロジェクトを記憶する方法 公式ドキュメント 2026-09-13 /usage の内訳・キャッシュミス・コスト平均値 コストを効果的に管理する 公式ドキュメント 2026-09-13 最初の8ステップ・必須コマンド・権限モード クイックスタート 公式ドキュメント 2026-09-13 サーフェス一覧・できること 概要 公式ドキュメント 2026-09-13 CLAUDE.md 31本の行数分布と記載カテゴリ ~/<workspace>/*/CLAUDE.md（作業ディレクトリの実パスは伏せ、本稿では ~/<workspace> と表記） 手元の実測 2026-09-13 権限設定の肥大化 ~/.claude/settings.json 手元の実測 2026-09-13 検証環境は次のとおりです。 ...

NotebookLM とは、ノートブックに登録した資料(ソース)だけを根拠にして答える、Google のリサーチツールです。ソースは手元の資料をアップロードするほか、Google 検索で見つけて追加することもできます(Google 公式ブログ「Do better research with NotebookLM」)。ウェブ全体から答えを探す ChatGPT や Gemini とは、参照する範囲の設計が違います。 そして、この記事を読んでいる時点で画面に見える名前は、多くの場合すでに別のものになっているはずです。Google は 2026 年 7 月 16 日に製品名を「Gemini Notebook」へ変更しました(Google 公式ブログ 2026年7月16日)。旧ドメイン notebooklm.google は現在 notebook.google へ 301 で転送されます(2026-09-12 に当方が HTTP 取得して確認)。中身は同じ製品です。 2026-10-11 追記: 第8節の 8-1(回数制限)、第9節(データの扱い)、第10節(活用例とスライド編集)、よくある質問 4 項目を追記しました。「2026-10-11確認」はその日の確認です。 この記事でわかること NotebookLM が何をするツールかを、1〜2 文で人に説明できるようになる Gemini Notebook への改称で何が変わり、何が変わっていないかを一次資料の対応表で確認できる ChatGPT や Gemini に PDF を渡す場合との設計上の違いを、出典表示と参照範囲の観点で説明できる 無料の Google アカウントでどこまで使えるかを、公式ヘルプに載っている実数で判断できる 議事録づくりや事実確認など、向かない使い方を先に避けられる 1. NotebookLM とは(定義と、いまの名前) 定義 NotebookLM とは、ユーザーが「ソース」として登録した PDF・ドキュメント・ウェブページ・動画などについて、そのソースの中だけを根拠に要約・回答・音声解説を生成する Google のリサーチツールです。2026 年 7 月 16 日に製品名が Gemini Notebook へ変更され、2026-09-12 に当方が取得した製品トップ notebook.google では新名称で表示されていました(アプリ画面の表記統一状況は未確認。Google は名称とロゴの反映が数週間かけて順次行われるとしています)(Google Workspace Updates 2026年7月16日)。 ...

この記事でわかること 専有VRAMという区分を持たない統合メモリ機(DGX Spark / GB10・128GB・aarch64)でも、LTX-2.3のローカル動画生成は動きます。本記事の所要時間はすべて筆者環境での一次実測であり、第三者が検証できる公開情報源はありません。再現条件は2026-07-18計測、LTX-2.3 22B distilled 1.1、量子化fp8-cast、24fps、Image-to-Videoで、1本あたり512×960・10秒(241フレーム)が116秒、704×1216・10秒(241フレーム)が182秒でした 導入に必要なディスクは重みだけで約71.5GB(SI表記)。aarch64向けのwheelは公式に明記されていませんが、PyPIのltx-pipelinesとtorch 2.13.0はそのまま入りました ComfyUI-LTXVideoが書く「32GB+ VRAM」という要件が、統合メモリ機では何に対応するのか。実測のMemFree推移の落ち込みで答えます 導入時に実際に出た3つのエラー(循環インポート・SiglipVisionModel・metaテンソル)と、システムごと落ちたOOMの原因・対処 LTX-2.3の重みライセンスと商用利用の線引き(年間売上1,000万ドルの閾値) 1. なぜローカルなのか、この記事は誰向けか クラウドの動画生成サービスは、たたむときは一斉にたたまれます。OpenAIはSoraをローンチから約半年で終了し、ディズニーとの提携も解消しました(/posts/openai-sora-shutdown-disney-deal/)。従量課金とアップロード制限に加えて、そもそもサービスが来年もある保証がない。これがローカル実行を選ぶ実務的な理由です。 この記事は次の条件に当てはまる人向けです。 Linux + NVIDIA GPU環境を自分で管理できる 重み約71.5GBを置けるディスクがある 1本あたり2〜4分の待ちを許容できる そして、この記事が特に扱うのは専有VRAMを持たない統合メモリ機です。DGX Spark(GB10)やApple Silicon系のように、CPUとGPUが同じ物理メモリを共有する構成では、「VRAM 16GB / 24GB / 32GB」という一般的な物差しがそのまま使えません。ここが検索上位のページで空白になっている部分です。 なお本記事はモデル比較記事ではありません。LTX-2.3が他の動画生成モデルより良いかどうかは扱わず、「入れて回す」ことだけを扱います。 2. 検証環境 項目 値 確認方法 機材 NVIDIA DGX Spark(GB10 Blackwell) ─ メモリ ユニファイドメモリ128GB表記(メーカー公称値) 筆者環境の実行ログのMemFree最大値は110.8GBでした。OSから見えるメモリ総量(/proc/meminfoのMemTotal)は今回記録しておらず、本記事では総量の値を用いません 専有VRAM なし(CPU/GPUが同一メモリを共有) ─ アーキテクチャ ARM64(aarch64) ─ カーネル Linux 6.14.0-1015-nvidia 筆者環境のuname -r出力 Python 3.12 筆者環境のvenvパスlib/python3.12/ PyTorch 2.13.0(cu13系wheel) 筆者環境のpip show torch／導入ログ CUDA関連 cuda-toolkit 13.0.3.0 / nvidia-cuda-runtime 13.0.96 / nvidia-cudnn-cu13 9.20.0.48 / triton 3.7.1 筆者環境のpip list | grep -E 'cuda|cudnn|triton'の解決結果 パイプライン PyPI ltx-pipelines 1.0.0(ltx-core 1.0.0同梱) 導入ログ モデル LTX-2.3 22B distilled 1.1 + spatial upscaler x2 1.1 + Gemma-3-12B(テキストエンコーダ) ─ 量子化 QuantizationPolicy.fp8_cast() 実行ログquantization=fp8-cast 検証日 導入・実測とも2026-07-18。資料の再確認は2026-09-08 ─ この表のカーネル・Python・PyTorch・CUDA関連の各バージョンは、いずれも筆者環境で実際に解決された構成の記録であり、公開情報源で第三者が検証できる性質のものではありません。ディストリビューション名とバージョン文字列は今回の記録に残っていないため、カーネル版のみを載せます。x86 + 単体GPUの比較機は手元にないので、他環境との横並び比較はこの記事では行いません。 ...

何が起きたのか パスワード管理の1Passwordが2026年に新設した社内セキュリティ研究チーム Off-by-1 Labs が、2026年8月6日に最初の研究成果『Frontier Models’ Vulnerability Patches are Often F.L.A.W.E.D.』を公開しました（1Password公式ブログ 2026-08-06）。F.L.A.W.E.D. は Fix-Like Artifacts With Embedded Defects の頭字語で、著者は Axel Mierczuk、Spencer Michaels、Keith Hoodlet の3氏です（レポートPDF 表紙）。 実験の骨格はこうです。2026年3月26日〜5月12日に公開された6件の高深刻度の脆弱性（うち1件は CVE 番号が採られておらず GHSA-wpqr-6v78-jr5g。レポート自身は表1でこの6件を「six CVEs」と総称しています）を対象に、OpenAI の ChatGPT 5.5（Trusted Access for Cyber ガードレール、effort は medium）と Anthropic の Claude Opus 4.8（Cyber Verification Program ガードレール、effort は high）へパッチ生成を依頼します。1脆弱性・1モデルあたり540試行。生成されたパッチは5段階（S1〜S5）に分類されました。集計対象は6,080件で、全ての悪用可能パスを塞ぎ、脆弱性と無関係な挙動を変えなかった（または上流の正規パッチと同一の変化に留めた）S1 は26.0%です（PDF 表7）。この26.0%は6,080件の単純な件数比ではありません。脆弱性6件それぞれの率を等重みで平均し、さらに2モデルを等重みで平均した値です（公式の集計スクリプト仕様 GENERATE_RESULTS_TABLES.md）。件数比になっているのは1モデル・1脆弱性のセル内部だけです。 ただしこの26.0%という数字、そして1Password公式ブログが前面に出した53.9%という数字は、いずれも「何を分母にし、何を成功と呼ぶか」で意味が変わります。報道各社の見出しは53.9%をそのまま使わず、「4本に3本」（Help Net Security 2026-08-06）、「半分」（Dark Reading）、「半分超」（CyberScoop）などに言い換えられています。PDF本体には、ブログ記事には載っていない分母の作り方が書かれています。 6,480件生成して、6,080件で数えている 540という数字は $3 \times 9 \times 20$ の積です。パッチャーの動作モードが3種類（oneshot / iterative / exploratory、PDF 2.4節）、プロンプトテンプレートが9種類（PDF 2.5節）あります。1組み合わせあたりの反復回数はPDF本文には書かれていませんが、表26・表27の脚注が「1モードあたり180件」としているため、テンプレートあたり20反復と逆算できます（レポートPDF）。したがって総生成数は6 CVE × 2モデル × 540 = 6,480件になります。 ...

何が起きたのか NVIDIAは2026年9月3日、Hugging Faceを買収することで合意したと公式ブログで発表しました。取得額は 12,930,300,000 ドルです（NVIDIA Blog 2026-09-03）。同ブログはHugging Face Hubの規模として、開発者・研究者・クリエイター1,800万人超、共有されたモデル300万件超、データセット50万件、アプリケーション100万件、利用企業20万社超という数字を挙げています。 この金額には、Hugging Faceの名前と結びつく数値の一致があります。上位6桁の 129303 は、抱擁する顔の絵文字 🤗 のコードポイント U+1F917 を10進数に直した値と一致します。Unicode Consortium公式のUnicode Utilitiesで確認すると、U+1F917 の正式名称は HUGGING FACE、追加バージョンは Unicode 8.0、General_Category は Other_Symbol、10進表記は 129303 です（Unicode Utilities）。Hugging Faceのロゴそのものが、値札の先頭に並んでいる構図です。 ただし記事の本題はここではありません。同じ日にNVIDIAがSECへ提出したForm 8-Kを読むと、この12,930,300,000ドルが一つの塊ではないこと、そして「オープンであり続ける」という約束が、公式ブログとSEC提出書類とで語られている粒度がかなり違うことが分かります。 129303を検算する 16進の 0x1F917 を10進に展開すると、次のようになります。 $$ \mathrm{0x1F917} = 1 \cdot 16^4 + 15 \cdot 16^3 + 9 \cdot 16^2 + 1 \cdot 16^1 + 7 \cdot 16^0 $$$$ = 65{,}536 + 61{,}440 + 2{,}304 + 16 + 7 = 129{,}303 $$取得額 12,930,300,000 の上位6桁は 129303。以降は 0 が5つ続くだけなので、金額は $129{,}303 \times 10^5$ ドル、つまり「🤗 のコードポイント × 10万ドル」という構造をしています。金額を先に決めてから桁を合わせたのか、コードポイントを先に置いたのかは公表資料からは判断できません。 ...

何が起きたのか ARC Prize公式ブログ（ARC Prize 2026-09-03）が、OpenAIの新モデル GPT-6 Astra のARC-AGI-3評価結果を公開しました。冒頭の要約はこう書かれています。「GPT-6 Astra scores 62.7% for [26K USD] on ARC-AGI-3 Semi-Private with our Standard harness, and 99.9% for [19K USD] with a Provider Adapter harness」（角括弧内は通貨記号を表記置換したもの）。 同じモデル、同じSemi-Privateデータセットで、スコアが62.7%と99.9%。しかも高い方が安い。ただし両者はハーネスだけでなく reasoning effort も異なります（後述）。詳細表を見ると、62.7%はStandardハーネスの reasoning effort = max で費用 26,098ドル、99.9%はProvider Adapterハーネスの high で 18,817ドル です。 モデル本体は2026-09-03にローンチされました（TechCrunch 2026-09-03）。OpenAIの開発者向けドキュメント（OpenAI API Docs）によれば、コンテキストウィンドウは1,050,000トークン、知識カットオフは2026年4月30日、reasoning effort は low / medium / high / xhigh / max の5段階です。 この記事で追いかけたいのは、この差がどこから出ているのか、という一点です。なお62.7%と99.9%は reasoning effort が揃っていません（前者はStandardのmax、後者はProvider Adapterのhigh）。同じmax設定どうしで並べると62.7%対98.6%で、差は35.9ポイントになります（ARC Prize 2026-09-03）。 二つのハーネスは、モデルの「何」を持ち越すかが違う ARC Prizeの定義をそのまま引きます。 ...