【勉強】生成 AI 利用者編②自分の文脈を AI に渡す

生成 AI は毎日使っているのに、知識そのものは数年前で止まっている自覚がありました。Gemini や Claude を私生活で触っているのですが、どちらも「だいたい分かっている」つもりになっていて、実際には用語の意味も課金の仕組みも説明できない、という状態です。そこで、キャッチアップすべき項目を洗い出したラーニングパスを自分用に作り、端から潰していくことにしました。

構成は 3 レイヤー・12 ステップで、項目数は 60 ほどです。利用者編から始めて、開発者編・運用者編へ進みます。進め方は「まず自分で手を動かして調べる・検証する」「詰まったところや調べきれなかったところを AI に補ってもらう」「ワークログに残す」の 3 つを項目ごとに繰り返します。

前回の利用者編①では、プロンプト入力欄だけで完結する領域を扱いました。今回の利用者編②は、ファイルのアップロードや指示文の保存といった少しの作業で、AI を自分の文脈に引き込む領域です。「自分の文脈を AI にどう渡すか」を軸に、ファイル・記憶・器・ツール・ブラウザ・手順の順で見ていきます。この記事は、そのワークログを清書したものです。個人的に勉強して、個人的にまとめただけのものなので、網羅的な解説になっていない可能性が大いにあります。また、生成 AI まわりは動きが速く、とくに今回扱う各社の機能は 2026 年秋に入れ替わりの最中なので、記載の内容はすべて 2026-09 時点のものになります。

下の表が今回のやることリストです。私と同じような状況にある人は、ぜひこの順番で自分でもタスクをこなしてみることをオススメします。

RAG と Gemini Notebook

Gemini Notebook（2026-07 に NotebookLM から改称、Google 公式ブログ）を読書メモの整理に使えそうだと思っていたのですが、これが RAG という仕組みで動いていると聞いたので、RAG そのものから調べ直しました。

RAG（Retrieval-Augmented Generation、検索拡張生成）は、AI が回答を作る前に外部の文書から関連する箇所を検索し、それをプロンプトに組み込んでから生成する技術です。あらかじめ文書群を検索しやすい形にしておく「インデックス作成」と、質問のたびに動く「検索 → 拡張 → 生成」に分かれます。

• 分割（Chunking）：長い文書を、段落などの意味のまとまりごとに短いブロック（チャンク）に切り分ける
• 埋め込み（Embedding）：チャンクを数値の配列（ベクトル）に変換し、キーワードの一致ではなく意味の近さで探せるようにする
• 索引（Indexing）：ベクトルと元のテキストをベクトルデータベースに格納する
• 検索（Retrieval）：質問文に近いチャンクを取り出す
• 拡張（Augmentation）：取り出したチャンクと元の質問を合わせてプロンプトを作る
• 生成（Generation）：拡張されたプロンプトを読んで回答を生成する

Gemini Notebook はこの一連の流れを全自動でやってくれるサービスで、アップロードした資料（ソース）を根拠に回答し、参照元も確認できます。オライリー・ジャパンでは DRM フリーの電子書籍を販売しているので、購入済みだった 直感 LLM の epub をソースにしたノートブックを作ってみました。「埋め込みってどんなやり方があるの？」のような書籍に関連する質問には、15 箇所ほどの引用を付けて回答してくれます。「3 章について 400 字でまとめて」にも答えてくれました。一方で「今年の冬は寒くなるのかな？」のような関連しない質問には、「お手持ちのソースには気象に関する情報は含まれていません」と返ってきます。なお、この「ソースにないことは答えない」振る舞いは RAG そのものの性質ではなく、「ソースにないことは答えるな」と生成段に指示している結果で、グラウンディングと呼ばれるものです。

気になったのは、前回記事のコンテキストの項目で扱った「文書を丸ごとコンテキストに載せる」やり方（Long Context）との違いです。使い分けの軸を整理しました。

応答速度も、最初のトークンが出るまでの時間が入力トークン数にほぼ比例するので、文書が大きいほど RAG に分があります。2024 年の Google DeepMind の比較研究（Retrieval Augmented Generation or Long-Context LLMs?）の結論は「載るなら Long Context のほうが精度は高く、コストは RAG が圧倒的に安い。まず RAG で答え、無理そうなら全文に切り替えるハイブリッドが現実解」というもので、両者は対立するものではなく組み合わせるもののようです。

メモリと指示ファイル

前回記事のコンテキストの項目で、メモリや CLAUDE.md が「セッションをまたぐ手段」として名前だけ出てきたので、それぞれがいつ読まれるのかを一度整理したいと思っていました。このあたりの仕様は各社で異なるようなので、題材は普段使っている Claude Code に絞ります。

前回記事の結論は「コンテキストは短期記憶で、毎ターン入力に含まれ、/compact は圧縮であって永続化ではない」でした。今回は別の観点から表にしてみます。

Claude Code では、CLAUDE.md（主にユーザーが管理）とメモリ（主に Claude が管理）で長期記憶を持ちます（Claude があなたのプロジェクトを記憶する方法）。CLAUDE.md は ~/.claude/CLAUDE.md（そのユーザー）、./CLAUDE.md（そのプロジェクト）、./CLAUDE.local.md（そのプロジェクトのそのユーザー）のようにスコープ別に置けて、大きくなってきたら .claude/rules/ 以下に分割できます。メモリのほうは ~/.claude/projects/<project>/memory/ 以下に user / feedback / project / reference の 4 種類のファイルとして自動で管理されます。

余談として、指示ファイルの仕様を AI ツール間で揃える AGENTS.md の動きもありますが、Claude Code は AGENTS.md があるからといって読むわけではなく、CLAUDE.md から @AGENTS.md のようにインポートする必要があるようです。

それぞれが読まれるタイミングは以下のようになります。

試しに、~/.claude/CLAUDE.md に「入力が日本語であっても回答はすべてフランス語とすること」と書いてみたところ、新規セッションで「こんにちは」と送ると「Bonjour」と返ってきました。既存のセッションでは何も変わりません。指示ファイルはセッション開始時に読まれるはずなので期待どおりでした。なお、CLAUDE.md もメモリもシステムプロンプトではなくユーザープロンプトとして渡されるので、モデルは「読んで従おうとする」だけで、厳密に守る保証はないそうです。

余談ですが、/doctor を実行すると、各指示ファイルのトークン数を計測して健全かどうかを見てくれます。また、CLAUDE.md や AGENTS.md をどう育てるかは Context Engineering と呼ばれる領域の一部で、開発者編で API を直接叩く側から見直すことになりそうです。

カスタム AI

カスタム指示や前回記事に登場したツールなどを束ねて活用する「カスタム AI」機能が 3 社から出ているので、その違いについて整理してみました。これらは、Claude では Projects（直前の項目に登場した Claude Code のプロジェクトとは別物です）、Gemini では Gem、ChatGPT では Custom GPTs と呼ばれています。

3 社のヘルプ（プロジェクトとは何ですか？、Gems の作成と使用、GPTs in ChatGPT）を読んで、持たせられるものを 1 枚にまとめました。

いずれも、カスタム指示とファイルをアップロードできる点は共通しているので、特定の役割や知識を与えた専用 AI アシスタントとして活用できます。違いとしては、Claude Projects ではメモリを持つこと、Custom GPTs では機能を ON/OFF できたり通常のチャット中に @ で呼び出せる点あたりが大きそうです。

なお、Custom GPTs は OpenAI から廃止と移行計画が公式に告知されていて、2026-09 時点で個人プランでは新規作成ができなくなっています（移行先は Plugins という機能）。また、Google 側も Gem を含めた再編が進んでいて、この 2 社に関しては本記事の執筆時点では過渡期にあります。

動作確認として、Gemini Gem を新規作成してみました。カスタム指示は次のとおりです。

あなたはプロフェッショナルな翻訳家です。
ユーザーから入力されたテキストが英語の場合は自然な日本語に翻訳し、日本語の場合は自然な英語に翻訳してください。
翻訳の際は、単なる直訳ではなく、文脈やニュアンスを重視した自然な表現に仕上げてください。
余計な解説は加えず、翻訳結果のテキストのみを出力してください。

その後、Gem に対して「Gemini 3.8 Flash is our most intelligent Flash model, engineered for long-horizon software engineering, autonomous agents, and complex enterprise workflows—all with the speed and cost efficiency of Flash.」を入力すると、「Gemini 3.8 Flash は、長期にわたるソフトウェアエンジニアリング、自律型エージェント、複雑なエンタープライズワークフロー向けに設計された、最高峰の知性を備えた Flash モデルです。Flash ならではの優れた処理速度とコスト効率をそのまま実現しています。」と返ってきました。毎回「あなたは翻訳家です。…」のような指示を与えなくて済むのが利点です。毎回ファイルをアップロードする必要があるようなユースケースでは、さらに便利に活用できるでしょう。

ちなみに、Claude Projects のプロジェクトナレッジについてドキュメントで詳しい説明があり、コンテキストに収まる量なら全文を毎回載せ、超えると裏で RAG に切り替わる 2 段構えでした。RAG の項目で調査した「載るなら Long Context、超えたら RAG」を自動的に切り替えるアイデアの、ひとつの実現例といえそうです。

ツールと実行場所

前回記事の AI 検索でツールの仕組み（モデルは実行せず、ツールを呼びたいというレスポンスを返すだけ）は押さえたので、今回はコード実行を題材に「では誰が、どこで実行するのか」まで深掘りしました。

この理解に際して、そもそも Claude と Claude Code の違いをあまり意識していなかったので、少し回り道をしてしまいました。現在、モデルにアクセスする手段（インターフェース）として、GUI・API・CLI が用意されていることが多いです。

Claude の場合、このインターフェースごとに用意されているツールが異なることがあります。② Claude API では、サーバーツール（web_search / code_execution など。Anthropic 側で実行）とクライアントツール（自作。自分のコードで実行）があります（Claude でのツール使用）。一方で ③ Claude Code では、Bash / Read / Edit / WebSearch など、全部ローカルで実行されるツールが提供されています（ツールリファレンス）。

この整理がついていない状態で、動作確認をしました。e-Stat から国勢調査の結果の CSV をダウンロードし、Claude Code に「この条件で集計してトップテンを出力して」と依頼します。当時の私の仮説では、この集計のためにコード実行ツールを使用すると見込んでいたのですが、結果を見ると Bash ツールしか使われませんでした。

Claude Code は Claude API の上で動いていて、Bash / Read / Edit / WebSearch などをクライアントツールとして実装しています。今回起きていたのは、モデルが集計のために Bash ツールの呼び出しを返す → Claude Code が私の WSL 上で実行する → その出力を結果としてモデルに送り返す → モデルが結果を読んで次を決める、という往復だったのでしょう。前回の記事では「クライアントツールの自作は開発者編で」と後回しにしていたのですが、実はクライアントツール自体は利用者として毎日使っていたのでした。

ちなみに、サーバーツールのコード実行ツールは 3 社とも提供しており、「モデルが書いたコードを、モデルの外にある使い捨てのコンテナで実行し、標準出力とファイルを結果として返す」ということをしています（2026-09 時点。Code execution tool、Code execution、Data analysis with ChatGPT）。

サンドボックスにインターネットがないのは、モデルが書いたコードにデータを外へ持ち出させない・任意のパッケージを引かせないための設計です。

ブラウザ操作エージェント

ふだん使っている Chrome に Gemini ボタンがあるので気になっていました。また、Claude でもブラウザ操作できるのか分からなかったので、まとめてみました。

2 社の提供形態を 2026-09 時点で並べると次のようになります（Claude in Chrome、Gemini in Chrome）。

実際に Claude in Chrome で「Yahoo ジャパンの野球のニュース 5 本の要約を作成して」と頼んでみました。自動承認モードでスタートしたところ、[スポーツ] → [野球] のタブを自力で発見し、記事のサマリを作ってくれました。読むだけのタスクだったので、承認を求められる場面は一度もありませんでした。

Skill の自作

このキャッチアップでは、AI にワークログをレビューしてもらうときの作法（補足の構成、表記ゆれは直す、など）がメモリに 5 つほど散っていて、手順として 1 か所にまとめたいと思っていました。

Skill は、なんらかのタスクの手順書をフォルダにまとめ、必要なときだけ AI に読ませる仕組みです（Agent Skills）。中心になるのは SKILL.md で、読まれ方が 3 段階に分かれています。

• Level 1：SKILL.md の YAML フロントマター（name、description）だけが起動時に読まれ、システムプロンプトに含まれる
• Level 2：description から「この Skill を使う」と判断されると、SKILL.md の本文が読まれる
• Level 3：同梱したスクリプトや参照ファイルは、必要になったときだけ読まれる（スクリプトは出力だけがコンテキストに入るので、SKILL.md に直接書くより節約になる）

置き場は、Claude Code なら ~/.claude/skills/ が個人用、.claude/skills/ がプロジェクト用です。claude.ai なら設定画面から zip でアップロードすれば同じスキルを使うことができます。

作り方には、skill-creator という Skill 作成用の Skill を使う方法と、手動で SKILL.md を書く方法があります。今回は前者で、/plugin から skill-creator をインストールして /skill-creator を実行したところ、新規作成の題材として「このキャッチアップの技術レビューをスキル化する（今はメモリに蓄えているだけ）」と提案されたので、そのまま採用しました。Skill の内容、プロジェクト固有かユーザー用か、動作テストをするか、の 3 点をヒアリングされ、回答するとユーザー Skill として ~/.claude/skills/genai-catchup-review/ が作られました。

作ってみて残った疑問は、プロジェクト固有の Skill は、メモリに手順書を蓄えておくのと何が違うのか、でした。これまで技術レビュー方針はメモリに蓄えられており、それで事足りていたので、スキル化するメリットはどこにあるのかということです。ドキュメントには、ほぼこの問いへの直接の答えがあります。”Create a skill when you keep pasting the same instructions, checklist, or multi-step procedure into chat, or when a section of CLAUDE.md has grown into a procedure rather than a fact”。読まれ方と配り方の 2 点で違う、ということでした。

今回切り出した作法は、事実ではなく手順だったので Skill 向きでした。プロジェクト固有で他者と共有するわけではなくても、手順であるという一点で Skill にする価値があるようです。

最後に、今回出てきたツール・Skill・カスタム AI の関係を 1 枚にまとめます。前回記事の AI 検索で整理した「Tool / Agent / Skill の線引き」の答え合わせでもあります。

Skill は「ツールを持たない」のがポイントです。新しいツールを生やすのではなく、既にあるツールの使い方を書いた文書で、同梱のスクリプトも結局 Bash ツール経由で走ります。カスタム AI が「固有の指示とファイル」を器に固定して共有可能にするのに対し、Skill は固有の指示だけを切り出して共有可能にするもの、という比較もできます。

おわりに

ファイル・記憶・器・ツール・ブラウザ・手順と、AI に自分の文脈を渡す手段は思っていたより多く、それぞれの読まれるタイミングや実行場所を整理できたのは収穫でした。一方で、指示ファイルやメモリを AI は「読んで、従おうとする」だけで、置き場もインターフェースごとに違います。実際にこのキャッチアップのレビューや記事化で Skill とメモリを併用していると、古い情報やお互いの重複が出てきていて、マネジメントには慣れが必要だと感じています。

次は利用者編③として、ローカル LLM など、独立した環境や専門ツールを導入する領域を扱う予定です。