4-3　文脈供給の実装：プロジェクト・RAG・ソース限定AI

※もともと有料教材でしたが、今はすべて無料で読めます。経緯はこちら→https://note.com/bonnno420/n/n226b8551ab12

意気込んで作り込んだカスタムGPT。3週間後には自分でも開かなくなり、今は設定画面の肥やしになっている——身に覚えはありませんか。

飽き性だからではありません。作る「順序」が逆だっただけです。

この記事で渡すのは、その原理です。

原因は仕組み化の順序です。先にカスタムを作り込む運用は、思考の変化・モデルの進化に追い越されて腐ります。健全な順序は逆——まず都度の対話で運用し、繰り返しが確定したものだけを固定化する。カスタムは出発点ではなく、成熟した運用の結果です。

コンテキスト供給の理論を、実装に落とします。あなたの業務知識をAIに届ける代表的な仕組みは3つあります。

①プロジェクト機能（ChatGPTのGPTs/プロジェクト、GeminiのGem、Claudeのプロジェクト——名前は違えど同じ原理です）。特定の業務のための指示書＋資料＋対話履歴をひとまとめにした作業空間です。「記事作成アシスタント」なら、文体のルールと過去記事を登録しておく。「問い合わせ対応」なら、製品マニュアルと回答方針を登録しておく。毎回のプロンプトで背景説明を繰り返す必要がなくなり、品質が安定します。2-16で学んだ「設定の固定化」の完成形です。作るときは、第2部の6問に沿って、目的・利用場面・根拠資料・操作・制約・受け入れ条件を指示書へ固定します。この指示書は、そのまま人間の新メンバー向けマニュアルにもなります。

②RAG（検索拡張生成）。1-5で学んだ「カンニングペーパー方式」です。プロジェクト機能に資料を載せるのも簡易的なRAGですが、本格的なRAGは、質問のたびに大量の文書庫から関連箇所を検索して文脈に差し込みます。社内ナレッジベースとAIをつなぐ企業導入の中核技術で、第5部で扱う「データ整備」の話に直結します。

③ソース限定AI（NotebookLMが代表）。発想が独特で、「渡した資料しか見ない」ことを価値にした設計です。通常のAIは学習知識と資料を混ぜて答えるため、どこまでが資料の内容か曖昧になります。ソース限定型は、回答の根拠を資料内の該当箇所として示せるため、ハルシネーションが構造的に起きにくい。契約書の読み込み、研究論文の整理、試験対策、議事録からのレポート生成——「正確さが命」の用途で絶大な威力を発揮します。

使い分けの原理はこうです。繰り返す業務はプロジェクト化する。組織の知識を常時使うならRAGを整える。特定資料への正確性が命ならソース限定型を使う。

実体験から

筆者自身、最初はここで遠回りをしました。「AIに知識を覚えさせれば成果が上がる」と考え、カスタムGPT、Google Drive連携、Notion、Git、Obsidian Sync、MCP連携……手当たり次第に試した時期があります。「とりあえず全部ぶち込んで、整理はAIに任せればいい」——そう思っていました。

しかし実際に運用すると、前提から崩れていきました。当時の環境では、Geminiにはコネクタがなく、Claudeはページ作成はできてもデータベースの参照・検索はプラン次第でできない。「一つのサービスに全部集めれば、どのAIからも参照できる」という発想自体が、AIごとに文脈供給の実装が違うという現実の前で成立しませんでした（各サービスの仕様は変わり続けます。ここで大切なのは個別の可否ではなく、"AIごとに供給の作法が違う"という構造のほうです）。

連携を通すたびに、手でコピー＆ペーストした方が速いと感じる場面もありました。正確には、速さの問題ではありません。連携を待つ数秒が、考えている途中の思考を途切れさせる。コピペなら、思考を止めずにそのまま渡せる。仕組み化したはずが、かえって集中を削っていたのです。

別の作業で使っていたAIエージェントが、あるとき急に詰まったこともありました。原因は、Markdownへの書き出し量を軽く見ていたこと——机（コンテキストウィンドウ）に載せる量を甘く見ていたら、実際に机が溢れたのです（1-3・コンテキストウィンドウ）。

そしてNotion運用でぶつかった本当の壁も、料金ではありませんでした。書き出したものが、思っていたほど「純粋な」Markdownではなかったことです。独自の形式に寄っている分だけ、後から他のツールへ持ち出す互換性が削られていく。サービスに預けるほど、資産は自分の手から離れていきました。

遅いと感じた同期の仕組みは、壊れる前に見切って早々にやめました。転換点は、こうした試行を一通りやり終えたときに訪れます。「Markdownならサービスに依存しない」——そう気づいて、運用の軸をMarkdownへ寄せました。自動整理のスクリプトも検討しましたが、結局は自分で整理する方式を選びました。理由は効率ではありません。自分で触れ続けることが、内容との接点になると感じたからです。

課題は、知識をどこに保存するかではありませんでした。必要な情報を、必要な瞬間に、AIへ低コストで渡せる状態を作ることだったのです。誤解しないでほしいのですが、先に挙げた3つの実装（プロジェクト・RAG・ソース限定AI）が悪いわけではありません。間違っていたのは、それらを作り込む順序でした。

その順序を、原理として整理しておきます。先にカスタムを作り込む運用は、たいてい失敗します。思考は変わり、市場は変わり、モデルも進化するため、固定したコンテキストはその瞬間から過去の断面になっていくからです。作り込んだ指示書の更新コストは、思った以上にリターンに見合いません。健全なライフサイクルはこうです。

対話 → 運用 → パターン発見 → コンテキスト整理 → 繰り返し確定 → 固定化（Projects/GPT/Gem） → 自動化

まず都度の対話で運用し、パターンとして繰り返しが確定したものだけを固定化する。カスタムは出発点ではなく、成熟した運用の結果です。自動化とは、成熟した運用を固定化する工程にほかなりません。原則を一行で言えば——変わるものは生成し、変わらないものだけ固定する。この思想を突き詰めると、「AIを育てる」のではなく「運用を育てる」という構えに行き着きます。育てるべきは特定のカスタムやプロンプトではなく、パターンを発見し固定化していく運用のサイクルそのものなのです。なお、固定化した資産は、しまい込んだ瞬間から古び始めます。資産を生かし続ける鍵は、繰り返し「触れる」こと——この保存の先の設計は、第6部で「接点」の思想として正面から扱います。

保存版・供給の3実装と順序

• プロジェクト機能＝業務単位の指示書＋資料の固定化。依頼前の6問を指示書にする

• RAGは文書庫との動的接続、ソース限定AIは「資料しか見ない」ことによる正確性

• カスタムは出発点ではなく成熟した運用の結果。変わるものは生成し、変わらないものだけ固定する

• 育てるのはAIではなく運用。パターン発見→固定化のサイクルを回す

これで冒頭の"作り込んだカスタムが肥やしになる"が防げます。

【2026年時点の一例】 資料の常設は ChatGPT／Claude のプロジェクト機能、NotebookLM。組織規模のRAGは Microsoft 365 Copilot＋社内文書のような構成が該当します。名称は数年で入れ替わりますが、本文の原理は変わりません。

やってみよう: 週1回以上繰り返しているAI依頼を1つ選び、プロジェクト（またはGem/GPT）として指示書＋資料付きで仕組み化してみましょう。指示書の下書きはこのプロンプトで。

📍 番号や読む順に迷ったら講座マップへ。目的別ルートと全84レクチャーの対応表があります。