ペドロ・ロドリゲス / Pedro Rodrigues · 13:22 「ボトルネックはもうコンテキストやない、 ガイダンス (guidance) や。 ツールはもう揃ってる、 必要なのは agent に正しい操作方法を伝える skill の方や」
Pedro Rodrigues が AI Engineer Europe 2026 で発表したのは、 Supabase 公式 Agent Skill の launch と、 その制作過程で得た 「マスター論文以来、 1 つのドキュメントにこれだけ時間を費やしたことはない」 という 3 ヶ月の設計知見だった。 タイトルは元々 「MCP vs Skills」 として提出していたが、 業界の議論が決着して 「両者は別の役割」 という consensus に到達したため、 「両方を組み合わせて context gap を閉じる方法」 に差し替えた、 という導入が時系列としても象徴的。
この講演が MEMEX で取り上げる意味は明確だ。 2025 年 10 月の Anthropic 公式発表 (Barry Zhang × Mahesh Murag の 「Don't Build Agents, Build Skills Instead」) で skill の概念が登場してから 6 ヶ月、 一般企業が自社製品向けに skill を実装した 最初の本格的事例 がこれ。 OpenAI 側からも Nick Cooper が 「MCP と CLI は両方使え」 と protocol 設計論を出しているが、 Pedro の話は 「自社の製品 docs を agent 用に再パッケージする」 実装側の現場知見になる。
Agent は賢いが、 あなたの製品を知らない
Pedro の問題定義はシンプルだ。 「Agent は十分賢い、 日常的な mundane task は自分でこなせる。 問題は、 学習時に存在していなかった、 あるいは学習後に更新されたもの — 例えば あなたの製品 — に対面したとき、 agent には right guidance が必要になる」。
Supabase での実例: agent は Row-Level Security (RLS) PostgreSQL の機能で、 テーブル単位ではなく行単位でアクセス制御を行う仕組み。 例えば user_id ごとに 「自分の行しか見えない」 という制約を SQL レベルで強制できる。 マルチテナント SaaS では事実上必須の機構で、 Supabase が backend として人気な大きな理由でもある。 ただし RLS を有効にしたテーブルの上に VIEW を作る場合、 デフォルトでは VIEW が RLS を bypass してしまうという罠があり、 これを防ぐには `security_invoker = true` フラグを明示的に渡す必要がある の落とし穴を見落とす、 古い training data に基づいた stale な情報で動く、 そして 「自分が知らないことを認めるのに lazy で stubborn」 — 新しい情報を取りに行こうとしない。 これらが specific な workflow へのガイダンスがあれば全部回避できる、 というのが Supabase Skill の出発点。
Pedro が実演する具体例: collaborative app で 「RLS が有効なテーブルの上に新しい SQL view を作って」 と頼む。 PostgreSQL では、 view を on top に作るとき security_invoker = true を明示しないと、 view は RLS を bypass してしまい、 本来見えないはずのデータが露出する。 MCP のみを与えた agent (Claude Sonnet 4.6) はこの罠に落ちる。 MCP + Skill を与えると、 同じ agent が正しく安全に実装する。 ツール (MCP) は同じ、 違うのは guidance の有無だけ。
Skill 設計の 3 原則 — 3 ヶ月の試行錯誤から
Pedro が抽出した skill 制作の 3 原則は、 これから自社製品の skill を書こうとするチームにとって reference になる。
原則 1: 情報を duplicate するな、 公式 docs を point せよ
「Skill を自分自身のためのドキュメントとして扱え。 自分のドキュメントは duplicate しないやろ?」 と Pedro。 すでに製品の公式 documentation がある以上、 skill 内に同じ情報をコピーするのは保守地獄の入り口。 代わりに、 agent に対して 「最新のドキュメントを web で search して確認してから answer せよ」 と 非常に stubborn に 指示する必要がある — モデルは default で training data に頼るので、 何度も念押しが必要。
Supabase は先日 docs を SSH で expose Supabase が AI Engineer Europe 2026 直前に発表した実験的施策。 公式 documentation を SSH プロトコル経由で agent からアクセス可能にする。 LLM は filesystem や Linux-based tool に非常に familiar なので、 docs を 「remote filesystem として navigate できる構造」 で expose すると、 一般の web search より agent が情報を取りに行きやすい、 という仮説。 Pedro は AI Engineer Europe で 「まだ実験段階、 フィードバック歓迎」 と公開意見を求めた という実験を announce した。 LLM は filesystem や Linux-based tool に非常に慣れている、 だから docs を remote filesystem として navigate できる構造で expose すれば、 web search よりも agent が情報を取りに行きやすい、 という仮説。 これは現時点で実験段階だが、 「ドキュメントを単なる HTML 文書として置く」 web 時代の前提を、 agent 時代に reshape する試みとして注目される。
原則 2: Skip できるものは skip される
これが講演で最も実用的な指摘。 「Agent は外部情報の取得や tool calling が expensive なので、 default で training data に逃げる。 同じことが reference file にも起きる」。 Supabase で実証したのは、 skill.md の本体に書いた情報は agent が読むが、 別ファイルに切り出した reference file は lazy にしか load しない。 そして reference file を 1 つ load した後に、 さらに別の reference file を load する確率はほぼゼロ。 3 つ・4 つに分割した時点で論外。
対策: agent に絶対 miss してほしくない情報 (Supabase の場合は security checklist) は、 reference file ではなく skill.md 直書きにする。 「最初は security checklist を reference file に切り出していたが、 agent が usually miss するので、 skill.md に直接書くことにした」 — これは Anthropic の progressive disclosure 思想 の現場補正で、 「progressive にロードされる前提では危ない情報がある」 という reality check になっている。
原則 3: Opinionated になれ
「自分の製品のことはあなたが一番よく知ってる。 user がどう使うべきかも知ってる、 あるいは知ってるべき。 自分が考える 最も効果的な workflow を agent に強く誘導することを恐れるな」。 これは多くの skill 設計者が躊躇する点で、 「agent の autonomy を奪うのでは」 と心配して曖昧な指示にしがちだが、 Pedro の経験では opinionated な workflow を埋め込むほど agent の output が安定する。
Supabase の specific 例: database schema management の場合、 (1) 開発/staging で DDL を自由に走らせる → (2) Supabase Advisor (security / performance チェック) で問題を発見・修正 → (3) その上で migration file を作る。 これは 「change のたびに migration file を作る」 という直感的な workflow と違う、 opinionated な手順だが、 Supabase が経験的に best だと結論づけた flow。 Skill にこれを encode することで、 agent が prematurely migration file を量産するのを防ぐ。
「Markdown ファイルを test する時代」 — Eval で skill を検証
Pedro が時代の象徴として強調するのが、 「我々は今、 documentation を test できる時代に living している。 数年前なら bonkers だった」 という指摘。 Skill は単なるドキュメントではなく、 agent の挙動を変える 実行可能な仕様書 なので、 CI で test できる。
Supabase の eval setup:
- 6 つの specific シナリオ: ongoing Supabase project の異なる状況を模した task set
- 4 つの agent × 2 vendor: Claude Code 上の Opus 4.6 と Sonnet 4.6、 Codex 上の GPT 5.4 と GPT 5.4 Mini
- 3 つの test condition: (1) baseline (MCP も skill もなし)、 (2) MCP のみ、 (3) MCP + Skill
- 評価方法: 4-graded test completeness score を BrainTrust LLM eval のための SaaS プラットフォーム。 trace 収集・eval 実行・regression 検出を一元管理する。 BrainTrust は AI Engineer Europe 2026 のスポンサーで、 Supabase の skill eval も BrainTrust 上で実行された。 Arize Phoenix と直接の競合関係にあるが、 BrainTrust はより SaaS 寄り、 Phoenix は open source 寄りという棲み分け 上で実行
結果はすべてのモデルで MCP + Skill が他の 2 条件を上回った。 「ツールはすでに揃っていた、 既に MCP server もあった。 必要だったのは、 Supabase でどう操作するかの right guidance だけ」。 これが Laurie Voss (Arize) の Ship Real Agents での 「production agent の信頼性は eval architecture 次第」 という主張と、 同じ通底音を奏でる。 Vincent Koc (Comet) の Malleable Evals でも 「multiple 評価手段を組み合わせる」 という業界 consensus が出ていたが、 Pedro の数字はその効果を 4 モデル × 6 シナリオ × 3 条件の grid で実証した形になる。
残った難題 — Skill の配布と registry
講演の Q&A で出てきた重要な question: 「組織内で skill をどう配布する?」。 Pedro の回答は率直で、 「これは現時点で skill の最大の constraint」。 業界は今、 distribution 方式の覇権争いの最中で、 Vercel の skills package、 各 model vendor の plug-in 形式 (.clot、 .cursor 等) が並存する。 「まだ standard がない」。
Supabase 内部では skill を repository に同梱する方式を採用。 オープンソースの repo なら自然に discoverable、 closed なら access 権がある人だけが使える。 「他社の skill の distribute の仕方を見ても、 みんな repo に直接置く方法に収斂しつつある」。 これは Nick Cooper (OpenAI) の MCP discovery 議論 と同じ問題 — agent が大量のツールから必要なものを見つける identity / discovery 層がまだ未整備、 という業界の宿題。
編集所見 — Skill = 製品 docs の reshape、 という見立て
この講演を MEMEX で取り上げる視点は 3 つ。
(1) Skill は B2B 製品の新しい競争軸。 これまで developer-facing 製品の差別化は 「良い API」 「良い docs」 だったが、 agent 時代では 「agent 向けの opinionated skill を提供するか」 が新しい競争軸に加わる。 Supabase が先に動いたことで、 Firebase / Neon / PlanetScale 等の競合は 「skill を出すか、 置いていかれるか」 の岐路に立たされる。 これは Anthropic の skills 公式提唱 から 6 ヶ月で起きた業界 dynamic の早さを示す。
(2) ドキュメントを 「読み物」 から 「実行可能な仕様」 に変える。 Pedro の 「Markdown を test する時代」 という言い回しは、 docs と test と implementation の境界が agent 時代に溶ける兆候。 Skill は markdown だが eval で test され、 production agent の挙動を決定する。 Documentation チームの仕事が DevRel と SRE の中間に shift する可能性がある。
(3) 「Stubborn な指示」 が必要、 という現場知見。 「Agent は default で training data に頼る」 「skip できるものは skip される」 という Pedro の指摘は、 prompt engineering 時代から続く agent 設計の reality check。 これは Agentic search の context engineering や Granola の 「Cannot one-shot it」 知見 と通底する。 Agent は賢いが lazy、 だから guidance は spoon-feed しないと届かない。
動画の構成
- (00:00) 自己紹介、 MCP vs Skills 論争が決着した今の問題設定
- (01:50) Agent は賢い、 でも あなたの製品を知らない
- (02:30) Supabase での RLS bypass 実例 — MCP のみ vs MCP + Skill
- (05:09) Supabase Agent Skill 一般公開 announcement (live tweet)
- (05:56) 原則 1 — 情報を duplicate するな、 docs を point
- (06:34) docs を SSH で expose する実験
- (07:34) 原則 2 — Skip できるものは skip される
- (09:07) 原則 3 — Opinionated になれ、 database schema 管理の例
- (10:50) Skill を eval で test する方法 — 4 model × 6 シナリオ × 3 条件
- (12:36) 結果: MCP + Skill がすべての条件で勝つ
- (13:22) 結論: ボトルネックはコンテキストではなくガイダンス
- (14:00) インストール手順、 Supabase blog 公開
- (15:00-18:26) Q&A — vector DB / 配布方式 / registry 問題