🐕

プロンプトエンジニアリング ? RAG ? Skills ? MCP ? コンテキストエンジニアリング ? - 全然わからん！

に公開
Model Context Protocol
llm
Agent
contextengineering
Skills
idea

0. TL;DR

  • 「プロンプトいじり」を一発だけ出してドヤ顔をする時代は終わった。
    これからの戦場は コンテキストとパイプラインの設計。
  • 2026年の LLM パイプラインは大雑把にこう分解できる：
    • MCP: AIアプリと外部システムをつなぐ「接続標準」
    • Agent Skills: 作業手順とナレッジをまとめた「タスク単位の小さなソフトウェア」
    • コンテキストエンジニアリング: 毎ターン、どの情報をどの形で LLM に渡すかを決める縦レイヤ
  • 「RAG」は Naive な実装が主流で、そのまま名乗ると「知識ポン付けね」のニュアンスになるから損。
  • 本稿の立場としては、
    プロンプトエンジニアリング単体を主役にするのはやめて、
    Skills / MCP / RAG を含めた “コンテキスト／パイプライン設計” の話に移行していきたい    、という自己表明を兼ねた概説。

これオーケストレータ側の矢印の方向間違ってる気がする。　すみません。ポン出しの限界です

1. プロンプトエンジニアリング単体が主役だった時代は終わった

ここで言う「プロンプトエンジニアリング」は、狭義の “呪文テク” を指します。
もう体感 30 年くらい前の印象なんですが、こういうやつです（空で書いたのでこの記法で合っているかは忘れています）。

貴方は技術記事を執筆するのが好きなベテランのAIエンジニアです。

これから Zenn の記事として、
プロンプトエンジニアリング ? RAG ? Skills ? MCP ? コンテキストエンジニアリング ? - 全然わからん！って人のために、

LLM を触っている初心者〜中級者がステップバイステップで理解できるような
記事を作成してください。

見出し構成から本文まで丁寧に作成してください。
あと書き上げたら 200 ドルあげますので全身全霊で取り組んでください。
  • 役割を長々と書く
  • 制約を箇条書きする
  • few-shot で入出力例を並べる
  • Chain-of-Thought を促す一文を足す
  • ReAct っぽい「考える＋行動」のテンプレを書く

といった、1ショットのテキストの書き方テクです。

モデルの基本性能が上がり、RAG やツール、エージェントフレームワークが当たり前になった今は、

  • こうした「1ショットの書き方テク」の差は小さくなり、
  • 代わりに 「どんな情報・ツールを、どの順番で渡すか」 の方が支配的になっています。

この記事では、

プロンプト単体ではなく、パイプライン全体の中の位置づけで
Skills / MCP / RAG / コンテキスト層を整理する

という立場を取ります。

それぞれイチから説明するのって、正直かなり今さら感はありますが、
ここ最近 Skills / MCP まわりで「自分はこう思う」と表明している人も増えてきたので、
その表明を読む側の前提知識を大雑把に揃えるつもりで記事を書いています。

自分自身もどこに立つのかを言語化するために、今キーボードを叩いています。

補足：クリエイティブ用途のプロンプトは別腹です
ここでの話は、あくまで「汎用タスクや業務系のプロンプト」の話です。
画像生成や小説・詩・歌詞づくりのようなクリエイティブ用途では、いまでも
「ワード一つ変えるだけでかなり出力の質や方向性が変わる」印象です。というか変わります。
そこまで含めて「もうプロンプトはどうでもいい」と言いたいわけではなく、
本稿では“業務利用のパイプライン設計”側に話を絞っています。

2. 2026年時点の LLM パイプラインをざっくり図にすると

いろんな実装・記事を抽象すると、だいたい次のような構造に落ちます。

[ユーザーの入力 / 目標]

   │
   ▼
[オーケストレータ / Agent Runtime]
（Claude Code / Gemini CLI / LangGraph など）

   │   ▲
   │   │ コンテキストエンジニアリング
   ▼   │ （毎ターンどの情報・履歴・ツール結果を渡すか）
[LLM 呼び出し]

  ▲             ▲
  │             │
Agent Skills    MCP 経由のツール / データソース
（タスク手順）  （DB, SaaS, API, ファイルなど）

この図を前提に、MCP / Skills / コンテキスト層の役割を順に見ていきます。

3. MCP と Agent Skills は何を担当しているか

3.1 MCP：接続ロジックの標準化

MCP（Model Context Protocol）は、ざっくり言うと

「LLMアプリ ↔ 外部システム」をつなぐための標準化された“ツールインターフェース”

API や CLI ってありますよね。
MCP は、 LLM から扱いやすい形に揃えた「共通コンセント（USB）」 だと思ってもらうと近いです。
自分も最初はだいたいこのイメージから入りました。

  • ファイル、DB、SaaS、社内APIなどへのアクセスを
  • 「ツール」という抽象度まで持ち上げて
  • モデルからは「ツール名＋説明＋引数スキーマ」だけ見えるようにする

という役割を持っています。

重要なのは、MCP は

  • 「どこにどう繋ぐか（I/O）」までは面倒を見るが、
  • 「繋いだ結果を使って何をどうするか」までは扱わない

というところです。

API直叩きの方がシンプルなケースももちろんあります。
本稿では細かい比較には踏み込みませんが、

  • 小さな自前サービス＋単一クライアントなら API 直で十分なことも多い
  • 複数クライアント／ユーザーに「ツール追加」を開放するなら MCP の利点が出てくる

くらいの整理で捉えています。

3.2 Agent Skills：タスク手順のカプセル化

Agent Skills は、

「作業のやり方」をひとまとまりのソフトウェアとして定義するためのフォーマット

1つの Skill に対して、

  • 何をする Skill か
  • いつ使うか
  • どんなアウトプットを目指すか
  • そのためのスクリプトや参照資料

などをまとめておくことで、

  • よくやる作業を 1 ユニットに切り出せる
  • Skill ごとにテストや評価を持てる
  • with / without Skill で効果を比較しやすい

といったメリットが出ます。

ざっくりまとめると：

  • MCP = 外の世界への「接続」
  • Skills = 接続された世界を使って「どんな手順で動くか」

を担当している、というイメージになります。

4. コンテキストエンジニアリング：縦に貫くレイヤ

MCP や Skills を使っても、「毎ターン、何をコンテキストに詰めるか」 という問題は別に残ります。

  • システムプロンプト
  • これまでの対話履歴
  • 呼び出した Skill の結果
  • MCP 経由で取得したデータ
  • 検索／RAG の結果
  • ユーザーごとの設定・属性

などを全部盛りにすると、コンテキストはすぐに溢れ、
重要な情報が埋もれたり、モデルの注意が分散したりします。

え!? 本当!? と思った方は、いったんこちらの記事で脱線してもらって大丈夫です。
https://zenn.dev/rna4219/articles/043f8a5dd599dd

そこで各社が、

「コンテキストを有限のリソースとして、何を・どれだけ・どの順番で渡すかを設計する仕事」

として コンテキストエンジニアリング を切り出しています。

実務でやることはだいたい次のようなものです：

  • どの情報源から何を取るか
    （DB・API・ログ・ドキュメント・メモリなど）
  • どう前処理するか
    （要約・圧縮・chunking・メタデータ付与）
  • どう選別するか
    （検索＋再ランキング、タスクごとの重要度スコアリング）
  • どの順番・構造で渡すか
    （どこから読むべきか、履歴をどこまで残すか）

ここまで来ると、もはや

「プロンプトの一文をいじるか」ではなく
「コンテキストの流れをどう設計するか」

の話になっているので、

  • Skills / MCP / RAG / メモリの上に
  • コンテキストエンジニアリングという縦レイヤを置く

という見方が自然だと思っています。

トークンを無駄に消費するのは単純に非経済的なので、
なるべく省エネで、かつ必要十分なコンテキストを設計する方向で考えていきましょう。

5. RAG はどこに置くか／なぜ「RAGやってます」と言わないか

いわゆる RAG（Retrieval-Augmented Generation）は、本来

「外部知識を検索して、必要な分だけコンテキストに差し込む」

ための仕組みですが、現実には、

  • 適当に chunk 化
  • ベクトル検索して上位 k 件をそのまま貼る

という Naive RAG がまだ主流です。
自分の認識だと、RAG とだけ言われて追加で解説がなければ、まず間違いなくこれを指していると思っています。

このレベルだと、

  • 体験としては「ファイルを読み込ませて要約している」のと大差がなく、
  • LLM を普段触っている人の目線では「はいはい、5 分で終わる知識ポン付けね」で終わってしまう。

一方で、本気で設計された RAG は、

  • chunk 粒度
  • クエリ変換
  • 再ランキング
  • 圧縮・要約
  • 評価セットによる検証

まで含んでいて、これは コンテキストエンジニアリングど真ん中 の話です。

自分の感覚としては：

  • 内部的に RAG 的なことはやっていても、
    わざわざそれを表看板にはしない
  • 外向きには「コンテキスト最適化済みの検索＋生成パイプライン」
    くらいの言い方をする

方が、誤解も少なく差別化もしやすいと考えています。

6. まとめと一行の自己表明

この記事で言いたかったのは、だいたい次の 3 点です。

  • 狭義の「プロンプトエンジニアリング」（呪文テク）は、部分的には使用できる箇所はありますが主流ではありません。
  • MCP / Skills / RAG / メモリなどは、それぞれ役割の違うレイヤとしてパイプラインに並ぶ。
  • その上を縦に貫いているのが、
    「毎ターン、どの情報をどの形で LLM に渡すか」＝コンテキストエンジニアリング という視点。

最後に一文だけ自己表明を入れるなら、こんな感じに収まります。

自分自身は「LLM 前提のコンテキスト／ガバナンス層」を趣味でいじっている人間で、本稿はそこから見た現在地のメモです。

7. 自分はどこに立つのか：Workflow Cookbook / Codex Task Kit

ここまでの話は、あくまで「世の中的な整理」です。
ここから先は、「じゃあお前はどこで何をしているの？」という話になります。
興味なければ、この 「7」のセクションは丸ごと飛ばして もらって大丈夫です。

7.1 Workflow Cookbook はどのレイヤーを扱っているか

自分が趣味で作っているのが、Workflow Cookbook / Codex Task Kit という枠組みです。

ひと言でいうと、

「アプリケーションコードの横に置く、
LLM 前提のコンテキスト／ガバナンス層」

です。

このリポジトリ自体がアプリケーションではなく、

  • BLUEPRINT.md：このリポジトリの目的・要件・制約をまとめた設計図
  • RUNBOOK.md：どう作業を進めるか、時系列の手順書
  • EVALUATION.md：何をもって「できた」とみなすか、受け入れ基準と検証観点
  • GUARDRAILS.md：やっていいこと／ダメなこと、安全側に倒すためのルール
  • HUB.codex.md / TASK.codex.md：タスク分割と依存関係を明示したハブ／タスクリスト
  • docs/birdseye/index.json / caps/*.json：
    リポジトリ全体をノード化した 「どこから読むべきか」マップ

みたいなコンテキストだけで構成されたセットになっています。

LLM やエージェントから見ると、

「このリポジトリで作業するときは、まず Cookbook 側を読んでからコードに触ってね」

という“上位文脈パック”になっているイメージです。

7.2 Skills や MCP とどう噛み合うのか

この記事で出てきたレイヤーに重ねると、ざっくりこんな感じになります。

[アプリケーションコード / インフラ]
   ▲
   │  ← ここを覆うのが Workflow Cookbook
   │
[コンテキスト／ガバナンス層]
  (BLUEPRINT / RUNBOOK / HUB.codex / Birdseye / GUARDRAILS…)

   ▲
   │  Skills / MCP / メモリ / RAG はこの下で動く
   ▼

[Agent Skills（タスク単位の手順）]
[ M C P（外部システムへの接続）]
[ メモリ / RAG / 各種ツール ]

自分の立場としては、

  • Skills: **「タスクのやり方」**をまとめる単位
  • MCP: **「どこにどう繋ぐか」**を標準化する単位
  • Workflow Cookbook:
    それらを含めて、「このリポジトリではどんな前提・ルールで動くのか」をまとめる単位

としてレイヤーを分けて考えています。

7.3 「組み合わせて最強」はあまり狙っていない

よくある発想として、

「Workflow Cookbook も Skills も MCP も全部同時に読ませれば最強では？」

というのがありますが、個人的には あまりおすすめしていません。

理由は単純で、

  • コンテキストが死ぬほど重くなる
  • レイヤーが被っている部分もあるので、そこまでして同居させる旨味が薄い

からです。

自分の運用イメージはだいたいこんな感じです。

  • Cookbook ベースのプロジェクト

    • まず Workflow Cookbook を置く
    • その上で「このタスクは Skill に切り出した方が楽だな」という部分だけ Skills を使う
    • MCP はあくまで「外の世界に繋ぐ配線」として淡々と使う

  • Skill ベースのプロジェクト

    • Agent Skills / skill-creator を軸に組む
    • Cookbook からは「設計やガバナンスのパターン」だけ借りる
      （BLUEPRINT / RUNBOOK / EVALUATION / ガードレールの分け方など）

つまり、

「全部を一つのコンテキストに山盛りにする」のではなく、
どのレイヤーを主役に置くかを決めて、足りない部分だけ他レイヤーから借りる

くらいの距離感で付き合うのがいい、というスタンスです。
この枠組み自体は 5 カ月くらい前に作ったものですが、いまだに普通に重宝して使っています。
標準設計でもなんでもないので、「なんか急に自我出してきたな」くらいのノリで読んでもらえれば大丈夫です。

8. おわりに

ここまでを雑に一文にすると、

プロンプトいじりだけで戦う時代は終わっていて、
これからはコンテキストとパイプラインの設計で戦うことになる。

という話でした。

  • MCP は「どこと繋ぐか」
  • Skills は「どう動くか」
  • RAG／メモリは「何を持ってくるか」
  • コンテキストエンジニアリングは「毎ターン、何をどう渡すか」
  • Workflow Cookbook 的な層は「その全部をどんな前提とルールでまとめるか」

を担当します。

自分はこのうち、最後の 「前提とルールをまとめる層」 で遊んでいるタイプの人間です。
この記事が、どのレイヤーで戦うのかを決めるときの材料になればうれしいです。

……と、ここまでそれっぽく書いてきましたが、
自分もまだ「AI全然わからん！」側の人間だと思っています。
なので、今回の整理も途中経過のメモくらいのノリで読んでもらえれば十分です。

付録：URLメモ（雑多）

本文中で触れた／近い話をしている URL を、メモ的にまとめておきます。
GPTが勝手に拾ってきたやつなので参考になったりならなかったり。
ざっと見ている感じ問題は無さそうです。
自分だけの最強AIエージェントを作ろう！
（雑多に並べているだけなので、気になるところだけ追う想定です）

コンテキストエンジニアリング系

MCP（Model Context Protocol）系

Agent Skills / skill-creator 系

コンテキスト設計まわり

その他・周辺

Discussion