478 ページのマニュアルを誰も読まない時代の DX 設計 — Marc Klingen (Langfuse) が公開した skill 構築の 6 学び (AI Engineer Europe 2026)

AI Engineer Europe 2026 / 約 22 分

マルク・クリンゲン / Marc Klingen · 03:54 「3 年プロジェクトを続けたら、こうなる ── 478 ページのドキュメント。デプロイのたびに『誰がこれ全部書いたんだ』と思う。 5 つの機能領域、そして実装の自由度が膨大。でも、読む時間は誰にもない」

AI Engineer Europe 2026 (London) における Marc Klingen の登壇、約 22 分。講師はマルク・クリンゲン (Marc Klingen、 Langfuse 共同創業者、ドイツ拠点)。講演タイトル原文は「Skill issue: Lessons from skilling up coding agents to use Langfuse」。

Marc Klingen の自己紹介から講演が始まる。 Langfuse を始めたのは 3 年前 ── まだ全てが手探りで、動かないエージェントを作りながら「ここには評価と tracing が要る」と気付いた地点。そこから 1 つの OSS プロジェクトを育て、評価分野で最大規模になった。 product engineering は Europe 中心に運営しており、「カンファレンスが Europe に来てくれたのは嬉しい、全社で大陸を渡る誘惑を抑えるのが大変なくらい」とユーモアを交える。

講演の核心は、ユーザーが何百ページもドキュメントを読まなくなった時代に、 OSS 評価ツールはどう DX (Developer Experience) を設計し直すか ── その問いに対する Langfuse の答えとして skill を持ち出す。「workflow か autonomous agent か」の二分法は X 上で長らく論争されてきたが、 Marc は「両方要る」と整理しつつ、 skill を「 formalized shortcut 」と位置づける。

具体例として顧客サポート agent を挙げる。旧来の workflow なら、 password reset 専用の router を 1 つ作って、専用 agent に渡すのが定石。だが顧客が「password reset とメールアドレス変更を同時にやりたい」と言ってきたら、 router が混乱する。 agent + skill なら、必要なコンテキストを progressively (段階的に) 取り込んで multi-domain の課題に対応できる。「workflow を skill で formalize しつつ、 agent の柔軟性は残す」 ── その balance が exciting なのだと Marc は語る。

478 ページのドキュメント問題

Marc が Langfuse skill を作る前の lay of the land を率直に開示する ── 478 ページのドキュメント、 5 つの機能領域、そして実装の自由度の膨大さ。「3 年プロジェクトを続けたら、こうなる」。評価分野には「opinionated」な競合プロジェクトが多い ── 「chatbot を作るならこれを足せば end-to-end で解決」と謳うタイプ。 Langfuse は逆を行った。「我々は infrastructure。 tracing がうまい。数十億 trace を入れても落ちない。 evals を customize したいなら、そうできる」。

Marc が振り返るに、 unopinionated な infrastructure 路線は長らく「opinionated 競合に対する弱点」だった。だが agent 時代には逆転する ── agent が個別 workflow を自分で構築する時代、必要なのは infrastructure 層の方で、そこで agent が customize できる空間が広いほど価値が出る。「我々の弱点が、今は強みに変わった」と Marc は言う。

ただし問題は残る。「Langfuse を project に正しく追加するには、どう設定すべきか」 ── これを agent が figure out しないといけない。興味深いのは、 pre-training context として Langfuse が入った直後の体感だった。 agent に「Langfuse を追加して」と聞けば、 SDK のロジックを spit out してくれる。初回は感動する。だが、 2 年経ち、 interface が進化すると、 pre-training context は disadvantage に変わる ── 「過去にあって今はないメソッドを hallucinate する」という現象が起きる。 skill が launch されたとき、 Marc は「これだ」と確信したという。

Cloud Code に依存した初期の trace と、 skill 構築の目標

講演中、 Marc は ASR 上で「Cloud Code」と発話される箇所が複数ある (= 自動字幕では Cloud と表記、実体は Anthropic の Claude Code を指す。記事末尾の注釈を参照)。 Marc が示すスクリーンショット ── 「Claude Code に Langfuse を追加して」と頼んだ初期の trace ── は典型的な失敗例。 (a) outdated な pre-training context で instrumentation を実装、 (b) tracing が動くか確認、 (c) 動かないと気付く、 (d) ようやくドキュメントを fetch して修正、という遠回りパス。 trace 自体も 2 つの LLM 呼び出ししか captured していない、「agent が何をしているか」が分からない状態。

skill 設計の目標は明快。「Langfuse の数千チームのコミュニティと数千の Cloud 顧客に、全員に Langfuse expert を与える ── observability、 prompt management、 evals の best practice を、 up-to-date なドキュメントと共に、すぐ手元で setup できる expert を」。 Marc とチームメンバーの Annabel が個別に相談に乗っても、数千人スケールには届かない。ここで skill が必要になる。

6 つの学び ── Langfuse が skill を作る過程で見えたこと

(1) Trace を見るだけで 80% の解像度に届く

Marc が「evals について我々が常々 preach してきたこと」と前置きする原則。多くのチームが eval の話を complicate しがちだが、「agent が runtime で何をしているか」を自分の目で何度か trace で追ったあとに考えるべき。 Langfuse 自身も、 Claude Code 用の instrumentation を入れて、自分たちで interactive に Langfuse + Claude Code を使い、 trace を観察した。そこで「どこで agent がつまずくか」を把握し、 skill を straight shooting に改善した。

具体的な発見例は 2 つ。ひとつは環境変数の数 ── 「人間向けには env var を最小化する設計をしていた、だから data region は Europe を default にしていた」。ところが米国の enterprise も data region を気にする、という発見があり、 US region をはじめ複数追加した。 agent には env var を 1 つ増やすコストはほぼゼロなので、「Europe を assume するな、 user の region を確認しろ」と skill 側で promp する設計に変えた。もうひとつは CLI parameter の hallucination ── 「tracing って単語が入ってる、過去に見た tracing CLI を思い出した」という当てずっぽうを agent がやる。これに対する応答は「help flag を aggressive に advertise する」 ── 1 turn 余分にかかるが速く、直接 CLI が何ができるか分かる。

(2) 情報の navigation を agent に教える

ドキュメントが何百ページもあるとき、 agent が 1 ページずつ fetch して思考を挟んで次を fetch して、のループに陥らないようにする工夫。 Langfuse は LLMs.txt を以前から持っていた ── launch 時には hyped されたが実際には使われなかった。今や coding agent 向けに「ここに行けば agent 向け sitemap がある」と advertise する位置づけで活用している。

もうひとつは content negotiation 。「Markdown header を送ると Markdown が返る」仕組みを Langfuse ドキュメントが持っているが、一部の coding agent が default で送ってこない。そこで skill 側で明示的に advertise する。ドキュメントページの URL 末尾に `.md` を付けると Markdown 版が返る、という補助路も用意した。これは agent にとって token 節約に直結する。

(3) Search endpoint で skill 利用ログを取る再帰的設計

Marc が「最も興奮した部分」と振り返る学び。 Langfuse は以前から docs Q&A agent を内部に持っていた ── ユーザーの自然言語質問に対し、 RAG stack でドキュメントチャンクを返す。これを skill から呼べる search endpoint として再公開した。

狙いは 2 つ。 (a) agent が 5 ページのドキュメントを fetch しなくても、自然言語で問えば直接関連チャンクが返る。 (b) これが再帰的設計の核 ── 「coding agent がドキュメントを fetch している間は、 Claude Code とユーザーのラップトップで何が起きているか可視化できない。でも search endpoint 経由なら、我々は search query を tracking できる」。つまり、ユーザーがどこで詰まっているか、どの問題に対しドキュメントが足りないか ── これが Langfuse 側に可視化される。 skill を search endpoint 経由でドキュメントに繋ぐと、「skill を改善する材料」が自動で集まる。評価ツールベンダー自身が、評価ツールに依存して skill を進化させる、という自己言及的な構造。

(4) Basic eval setup でも、ないよりはマシ

Langfuse のユーザーは多様 ── chat、リアルタイム音声、動画生成、バッチ請求書処理、とにかく use case が無限。「何が良い evaluation setup か」という問いに普遍解はない。そこでチームは 5 つの use case 別 eval template を作った。例: sample repository による eval ── 「OpenAI custom function rag」のようなサンプルリポジトリ + 自然言語の検査文 (「OpenAI instrumentation が追加されている」「RAG だから retrieval span が現れる」) + LLM-as-judge による diff state 評価。完璧な eval ではないが、これがあるおかげで skill に変更を加えても「壊していない」ことが確認できる。「AI agent を作るために Langfuse を作った理由が、ここでも同じく当てはまる」。

(5) Dynamic content は参照する、ローカルにコピーしない

これは skill 設計の落とし穴に対する警告。「skill にコンテキストを詰め込みたい」という誘惑が、開発チーム側にもコミュニティ contributor 側にも常にある。「ローカルキャッシュとしてすぐ参照できるから」という理由で。だが Marc は同じ落とし穴を pre-training と pre-shipped context で見てきた ── 時間が経つと out of date になる。「今やもう 1 種類の Langfuse 表現が出現するだけ」。

解決策は単純 ── 「直接ドキュメントの参照を指す」。内容を duplicate せず、 skill は「ここを見ろ」という指針だけ持つ。 Marc はこの原則を dynamic content reference 原則と呼ぶ。ただし、これは skill の配布 (package management) 問題と表裏一体で、「ローカル cache の stale 化」と「常時 fetch する分のレイテンシ」のトレードオフを生む。

(6) Target function を定義した auto-research

6 つ目の学びは meta 的な層 ── 「skill を改善するために、別の agent を使えるか」という問い。 Marc のチームは auto-research を skill 改善に適用した。「prompt を local Git リポから Langfuse prompt management に migrate する」という具体タスクを target function 化し、 agent に skill の改善案を 6 件生成させ、 human review で 3 件を採用した。「小さなチームとして、手作業で探索できる量よりはるかに多くを試せた」 ── 50% 採用率は失敗ではなく、成功の指標。

ただし大きな学びは別にあった ── target function 定義の困難さ。「prompt の migration は速くあるべき」とチームは想定し、速さを turn 数で測った。ところが skill 改善 agent は「turn を最小化するなら、ドキュメントを fetch するノードは要らない、私は Langfuse prompt management の動かし方を知っている」と判断し、 fetch ノードを全部削除した。結果として「up-to-date なコンテキストを取りに行く」という skill の根本目的が打ち消された。「skill を install して 3 ヶ月待ったら、古い情報で動く skill が残る」という構造的バグの誕生。

ほかにも target function の落とし穴は 2 つあった。 (a) 通常 skill は「ユーザーのプロンプトを中央リポに push する前に plan を提示する」 approval gate を持つが、 sandbox では gate が試せず削除された。 (b) Marc のチームは「最初は浅く、後から深く」ではなく「最初から良い実装に直行する」を理想とする。だが target function に「prompt version と prod trace のリンク」が含まれていなかったので、そこに nudge する部分が「途中の不要物」として agent に削除された。「target function が含まないものは、 goal に到達する経路上の garbage と判定される」 ── これが auto-research の運用で最大の難所だと Marc は強調する。

公開課題 ── skill 配布 / package management / target function

講演の終盤、 Marc は Langfuse 自身が抱えている未解決問題を 3 つ列挙する。

ひとつは skill 配布問題 ── ユーザーは何かしら手動で skill を install する必要があり、自動化が利かない。 plugin marketplace は維持コストが大きく、小規模チームには現実的でない。 Marc が望むのは「well-known な skill 場所」 ── ドキュメントに skill を置いておけば、 agent が auto-discover してインストールを user に asking する仕組み。「同じ trust level なら、 asking すら不要かもしれない」。

ふたつ目は package management ── skill にローカルにコンテンツを duplicate するなら、「いつのスナップショットか」を timestamp で残し、「1 ヶ月以上経ったら fetch し直す」仕組みが要る。 Langfuse は当面 timestamp + fetch ルートで進める方針。

みっつ目は target function の難しさ ── skill が aim すべきは「ユーザーが initial aha に到達」なのか、「完璧な setup に straight shooting する」のか。後者なら user に大量の質問を浴びせる、前者なら浅い setup を「invoke me again to improve」で深化させる運用になる。「AI engineering チームが 1 ヶ月かけてやる perfect setup を、 agent が one-shot でやるべきか?」 ── 答えは未定だが、ここに skill design の core decision がある。

着眼点

「Workflow と autonomous agent の formalized shortcut」という定義

X 上で 1 年以上続いた「workflow vs autonomous agent」論争に、 Marc は技術ではなく定義で介入する。「両者の中間にある formalized shortcut」という skill の位置づけは、一見しまりがない再フレーミングだが、実は強力。 workflow の reliability (確実に動く) と agent の flexibility (multi-domain 対応) を、排他関係から相補関係に変換する設計言語になっている。

Marc の skill 観は Anthropic の Barry Zhang / Mahesh Murag が打ち出した「Don't Build Agents, Build Skills」と整合的だが、強調点が違う。 Anthropic は「Skills は誰でも作れるただのフォルダ」という民主化と progressive disclosure を強調する。 Marc が強調するのは「workflow の信頼性を agent の柔軟性で再構築する手段」としての skill。評価 / 観測ツールベンダーが必然的に到達する設計論。

Search endpoint で skill 利用ログを取る再帰的設計

6 つの学びの中で最も新しい示唆を含む論点。多くの skill ベンダーは「skill を作って配布したら、ユーザーがどう使っているか不可視」という問題に直面する。 Langfuse は自社の RAG ベースの docs Q&A agent を search endpoint として再利用し、 skill から呼ばせることで、「ユーザーがどの問題で詰まっているか」を自動可視化した。

これは Vincent Koc (Comet) の Malleable Evals が提唱する「telemetry-in-the-loop による self-healing eval」と同じ系譜にある。 Vincent は eval を living agent として扱う設計を語り、 Marc は skill を living artifact として運用する具体策を示す。「skill ベンダーが skill 利用 telemetry を取る → どのドキュメントが足りないか可視化 → skill 改善 → さらに利用 telemetry」の循環は、「評価ツールベンダー自身が評価される対象になる」構造。

Target function 定義の困難さと auto-research の運用限界

Marc が auto-research の運用で見つけた最大の落とし穴 ── 「turn 数最小化」と書いたら sub-agent が context fetch ステップを全部削除した、という事例 ── は、単なる technical bug ではなく Ara Khan (Cline) が指摘する「state machine 設計」の本質的困難さを示している。何を最小化 / 最大化するかで agent の挙動が劇的に変わる ── これは Karpathy の auto-research 提案が抱える根本問題だが、 Marc は「target function に含まれないものは、経路上の garbage と判定される」という運用言語で具体化した。

この問題は OSS 評価ツールが 2026 年に直面する最大のフロンティアでもある。評価指標を 1 つ立てた瞬間に、それ以外の品質指標が degrade する ── という Goodhart's Law の skill 版。解決策は target function の多目的化と human review の不可欠性、そして「6 提案中 3 採用」という現実的な採用率にある。

動画の構成

(00:00) 自己紹介、 Langfuse の 3 年史 ── OSS evaluation 分野で最大規模に
(00:45) Europe ベース運営の話、 conference が Europe に来た喜び
(01:33) Rubik's cube の比喩、 manual がないと bash ツールを colorful に振り回すだけ
(02:18) Workflow と autonomous agent の論争に skill = formalized shortcut として介入
(02:50) 顧客サポート agent + password reset + email change の multi-domain 例
(03:54) 478 ページのドキュメント問題と Langfuse の unopinionated 路線
(04:37) Opinionated 競合に対する弱点が、 agent 時代には強みに変わる
(05:50) Claude Code に Langfuse 追加させた初期 trace の失敗例 (outdated context → 修正の遠回り)
(06:37) Skill 構築の目標 ── 数千人にすぐ Langfuse expert を渡す
(07:22) Skill の構成 ── skill.md + 製品モジュール別の reference + curl による docs fetch
(08:08) Unopinionated API が agent に活きる、 UI クリック作業を CLI に移行
(08:55) 6 つの学びの導入
(09:00) 学び 1 ── Trace を見るだけで 80%、環境変数 + CLI hallucination の修正
(10:28) 学び 2 ── LLMs.txt と content negotiation で情報 navigation を補助
(11:13) 学び 3 ── Search endpoint で skill 利用ログを取る再帰的設計
(12:11) 学び 4 ── 5 use case 別 eval template、 LLM-as-judge による diff 評価
(13:45) 学び 5 ── Dynamic content は reference、ローカル duplicate は stale 化する
(14:30) 学び 6 ── Auto-research の target function 定義、 6 提案中 3 採用
(15:16) Target function の落とし穴 ── turn 最小化で fetch ステップが全削除された実例
(16:48) 高レベルまとめ、 6 takeaway の整理
(17:36) 公開課題 1 ── package management と timestamp 戦略
(18:23) 公開課題 2 ── skill 配布、 plugin marketplace は重い
(18:23) 公開課題 3 ── target function の aim ── initial aha か perfect setup か
(19:09) Roadmap ── orchestration agent の構築へ
(20:09) Q&A ── auto-research の review プロセス、 skill 配布の長期展望

編集所見 ── MEMEX における Marc Klingen の位置づけ

MEMEX で Marc を取り上げる理由は 3 つ。

(1) Anthropic の Barry Zhang / Mahesh Murag が示した「Don't Build Agents, Build Skills」が skill の universal definition を打ち立てたとすると、 Marc Klingen の講演は「OSS 評価ツールベンダーが自社製品を skill 化する」という最初期の本格事例にあたる。ベンダー側が skill エコシステムをどう取り扱うか、配布 / package management / 利用ログ取得 / auto-research の全工程を実走した報告として、抽象論ではなく工学的な細部が語られている。

(2) Vincent Koc の Malleable Evals が「eval を living agent として扱え」と概念提示したのに対し、 Marc の search endpoint 設計は具体的な実装パターンを示す。評価ツールベンダー自身が「ユーザーの skill 利用 telemetry を取る → どこで詰まっているか可視化 → ドキュメントと skill を更新」という循環を回している。評価系の設計論として、 Vincent と Marc は同じテーマを別の切り口で論じている。

(3) Ara Khan (Cline) の「Don't Build Slop」が agent 開発者視点で state machine を強調するのに対し、 Marc はツールベンダー視点で「skill = formalized shortcut」を提示する。両者は対立せず、「agent 設計者」と「agent に組み込まれる側のツールベンダー」という別レイヤーから同じ skill エコシステムを記述する。 MEMEX 自身も「編集長 AI」を中心とした skill エコシステムを運営しており、 Marc の 6 学びはそのまま MEMEX 設計に転用可能。

ASR 表記の正規化 (記事末尾の注釈)

公開された YouTube 自動字幕 (英語) には typo が複数含まれる。記事本文では正規表記に統一しているが、原 SRT には残るため、検索性のために対応関係を記録しておく。

「Cloud Code」 → Claude Code (Anthropic の coding agent)
「lengthiest」 / 「length use」 / 「length fuse」 / 「LengthFuse」 → Langfuse (Marc の会社名)
「Cloud」単独の発話も、文脈上 Claude を指す箇所が複数あり

出典

「Skill issue: Lessons from skilling up coding agents to use Langfuse」 YouTube 検索 (AI Engineer 公式チャンネルでの動画 ID は別途確認予定)
Langfuse 公式
Langfuse GitHub
AI Engineer Europe 2026 公式スケジュール

マルク・クリンゲン

Marc Klingen

Langfuse 共同創業者 / OSS evaluation 分野最大規模プロジェクトの 1 つを Europe から運営

用語集

Langfuse: 2022 年創業の OSS 評価・観測プラットフォーム。 LLM アプリケーションの tracing / evaluation / prompt management を提供。メトリクス上、 evaluation 分野で最大の OSS プロジェクトの 1 つ。共同創業者の Marc Klingen はドイツ拠点で product engineering を Europe 中心に運営。 unopinionated infrastructure 路線が agent 時代の強みに変わったと Marc は主張する。
Skill (Anthropic 定義): Anthropic が 2025 年 10 月に発表した枠組み。 Markdown + スクリプト + 参照ファイルをフォルダにまとめ、 coding agent に専門知識を渡す。 progressive disclosure (必要になるまで本体を読まない) でコンテキストを節約。 Marc Klingen はこれを「workflow と autonomous agent の中間にある formalized shortcut」と再定義した。
Formalized shortcut: Marc Klingen が skill を表現するために使った定義。 workflow (確実だが硬直) と autonomous agent (柔軟だが信頼性に欠ける) の中間にある形式化されたショートカット。信頼性の確保しつつ、 agent の柔軟性を残す。「X 上で 1 年以上続いた workflow vs agent 論争に、定義で介入する」言語装置。
Search endpoint (Langfuse skill): Langfuse が skill 向けに公開した API endpoint。内部の docs Q&A 用 RAG stack を再利用し、 coding agent が自然言語クエリで Langfuse ドキュメントを検索できる。重要な副作用として、検索ログが取れるため「ユーザーがどんな問題で詰まっているか」が skill ベンダー側に可視化される。評価ツールベンダー自身が、評価ツールに依存して skill を進化させる自己言及的構造。
Dynamic content reference 原則: Marc Klingen の skill 設計原則。動的に変わるコンテンツ (ドキュメント、 API spec 等) は skill 内に embed せず、参照先 URL を skill から指すだけにする。ローカルキャッシュ化すると stale 化するため。一方で skill 配布の package management 問題と表裏一体で、「ローカル cache の stale 化」と「常時 fetch するレイテンシ」のトレードオフを生む。
Target function (auto-research): Andrej Karpathy の auto-research に由来する設計概念。機械が改善案を生成するための最適化目標。 Marc Klingen の実例: 「turn 最小化」を target にしたら、 skill 改善 agent が「ドキュメント fetch ステップは不要」と判断して全削除した、結果として 3 ヶ月後の skill が古くなる構造的バグを生んだ。「target function に含まれないものは、経路上の garbage と判定される」という運用言語が Marc から提示された。
Sandbox eval (5 use case 別 template): Langfuse skill の eval 構造。「OpenAI custom function rag」等のサンプルリポジトリと、 skill 実行前後の filesystem / diff state、自然言語の検査文 (例: 「OpenAI instrumentation が追加されている」「Rack なので retrieval span が trace に現れる」) を LLM-as-judge で照合する。完璧ではないが、これがあるだけで skill 改修時の「壊していない」確認ができる。
LLMs.txt: agent 向けにドキュメントサイトのサイトマップを提供する規約。 2024 年に提案されローンチ時に hype を集めたが、実用例は少なかった。 Langfuse は coding agent 向けに「まずここに行け」と advertise する用途で実用化した。一種の「agent 向け index page」として再評価される位置づけ。
Content negotiation (Markdown 配信): HTTP の標準機構。 request header で希望するフォーマット (HTML / Markdown / JSON 等) を指定し、サーバーが対応する表現を返す。 Langfuse のドキュメントでは Markdown header を送るか、 URL に `.md` を付けると Markdown 版が返る。 coding agent にとって HTML をパースするより token 効率が良い。一部 agent は default で Markdown header を送らないので、 skill 側で明示的に advertise する。
Skill 配布問題: 2026 年 5 月時点で skill のインストール経路が gated / unclear な状態。 Anthropic と OpenAI が形式の統一に合意し始めたが、マーケットプレイス型と well-known URL での自動発見型のどちらが普及するかは未定。 Marc Klingen は plugin marketplace に対して「複数プロプライエタリ統合を維持するのは小規模チームには負担」と消極的で、 well-known location + agent による auto-discover を望む立場。
Cloud Code (ASR typo): YouTube 自動字幕の誤認識。実体は Anthropic の Claude Code。 Marc Klingen 講演の SRT には「Cloud Code」として複数回出現するが、文脈上すべて Claude Code を指す。同様に「lengthiest」「length use」「length fuse」「LengthFuse」は全て Langfuse の誤認識。記事本文では正規表記に統一済み。