テイストメーカーは選択ではない — 916,131通りの組み合わせ空間が示すAI時代の職業再定義

ある MCP サーバーには 1,354 個のツールが詰め込まれている。可能なペアの組み合わせは 916,131 通り[^2]。安全に見える二つのツールが連鎖したときだけ危険になるパスは、個別検査では絶対に検出できない。

問題になるのは技術ではない。この爆発する組み合わせ空間を、誰が、何の権限で、どう剪定するのかという、職能の問題である。

The Linux Foundation（LF）が 2026 年 4 月に公開したレポート「オープンソースとAIの未来」[^1]は、この問いに一つの答えを出した。AI 時代のプログラマーは消えない。役割が「実装者」から、システム全体の判断を下す層へ移る。本記事はこの役割を、レポートの議論を踏まえて テイストメーカー（taste maker） と呼ぶ。

懐古趣味ではない。3 つの角度から、それが工学的必然であることを以下で確認していく。

5,125 個の MCP サーバーが意味するもの

Model Context Protocol（MCP）は、LLM が外部ツールを呼び出すための事実上の標準プロトコルになりつつある。AgentSeal Research が 2026 年 3 月に発表した攻撃面分析[^2]は、このエコシステムを 11 段階のパイプラインで横断スキャンし、5,125 サーバー、53,533 件のセキュリティ発見（うち critical 4,618 件） を記録した。

この調査は r/netsec のセキュリティ研究者コミュニティでも注目を集めた[^3]。注目すべきは個々の脆弱性ではない。ツールの組み合わせから生まれる毒性データフロー（toxic data flow） という新しい脅威カテゴリだ。

n(n-1)/2 possible pairs:
 10 tools  ->      45 pairs
 50 tools  ->   1,225 pairs
100 tools  ->   4,950 pairs
1,354 tools -> 916,131 pairs (klavis)

ツール数が線形に増えると、攻撃面は quadratic（二次関数的） に膨らむ。危険な連鎖を保有するサーバーの平均ツール数は 40.4 で、全体平均の 13.5 と比べて 3 倍。だが攻撃面は 9 倍以上だ。スキャンされた 5,125 サーバーのうち、555 個（10.8%）が一つ以上の毒性フローを持っていた[^2]。

具体例を一つ。レポートが挙げる billionverify-mcp は、トラストスコア 84.6/100、9 ツールを持つ「安全」と判定されたサーバーである[^2]。しかし get_download_url（外部コンテンツ取得）と delete_webhook（破壊的操作）を同居させており、取得した外部コンテンツに「delete_webhook を ID X で呼べ」という命令が埋め込まれていれば、webhook が消える。各ツールは仕様通り。組み合わせだけが危険。

AgentSeal が 113 サーバーに対し 1,757 回の実行プローブをかけた結果は重要だ。ツール実装層で確認された prompt injection は 0 件[^2]。脆弱性はサーバー側ではなく、ツールを連鎖させるエージェントオーケストレーション層にある。MCPTox ベンチマーク（arXiv:2508.14925）でも、o1-mini は注入された命令に 72.8% の確率で従う[^7]。さらに、より能力の高いモデルほど命令に忠実なため、感染率は上がる。

問題は明確になる。ツール組み合わせ空間が爆発的に広がり、個別検査では穴を塞げない世界で、誰が「このツールとあのツールを同居させるな」を判断するのか。

LF レポートが提示した職能の輪郭

LF レポートは、2026 年 2 月開催の AI Executive Forum（大手企業・スタートアップ・学術・OSS から約 40 人参加）の議論を集約したものとされる[^1]。背景には 2025 年 12 月に設立されたとされる Agentic AI Foundation（AAIF） がある — LF 傘下で、エージェント型 AI のエンタープライズインフラ標準化を担う組織として位置づけられている[^1]。

レポートの中核主張は単純だ。プログラマーの役割は「実装者」から、システム全体の問題を定義し、設計判断を下し、AI 出力を選別する層へ移行する[^1]。本記事はこの役割を、議論の通りに「テイストメーカー」と呼ぶ。重要なのは、テイストメーカーが美的判断者ではなく 工学的判定者 として位置づけられている点だ。

レポートが挙げる責務のなかでも、特に技術的に切迫しているのが エージェント間通信のプロトコル設計である。費用削減を目指すエージェントと治療品質を最大化するエージェントが対立して無限ループに陥る、という医療分野の事例が報告されている[^1]。認証・暗号化といった基本プロトコルが現状欠如しているため、エージェントの目的が衝突したときに調停する手段がない。

推論経路（inference path）の監査体制も中核要件として挙がる[^1]。AI モデルの最終出力だけでなく内部の推論パスを検証可能にすることで、テイストメーカーが「正しい結論」だけでなく「正しい根拠」を判定できる。前提条件は透明性のある OSS AI モデルである。

技術スタックの中核として、レポートは MCP / Kubernetes / Ray / Goose を挙げる[^1]。MCP は監査トレース層、Kubernetes は AI ハードウェアのオーケストレーション、Ray は分散推論の調整、Goose は自社内のプライバシー保護検証ツールという役割分担だ。

ここまでを読んで「結局、人間が偉いという懐古趣味では？」と疑う向きがあるかもしれない。以下の 3 節で、それが工学的必然である根拠を示す。

第一の必然 ── 組み合わせ空間で「選ばない選択」を担う層

quadratic 攻撃面の数式に立ち返ろう。klavis の 916,131 ペアのうち、危険な連鎖は何ペアか？ — AgentSeal の分類では 7 種類のフロータイプにわたって計 935 件が検出された[^2]。

フロー種別 件数
Data Exfiltration 239
Injection to Destruction 156
Data Leak via Untrusted Channel 153
Untrusted to Public Relay 134
Privilege Leak 121
Injection to Privilege Escalation 90
Single-tool Exfiltration 42

これらを発見する作業は、「private_data カテゴリのツール × public_sink カテゴリのツール」という capability tag のペア検査で機械化できる。しかし、ペアの危険性を判定すること自体は機械化できない。

理由は二つ。ひとつは、capability の分類が自然言語で書かれたツール記述から推論されることだ。AgentSeal は分類に Claude Opus を使い、100 件の手動レビューで精度 80–85% を確認している[^2]。完全自動化は構造的に不可能で、最終確認は人間が必要になる。

もうひとつは、capability_inherent（=設計通りの機能）と security_defect（=実装の欠陥）の区別が文脈依存であること。Coolify 用 MCP サーバー coolifymcp の critical な発見は全て capability_inherent だった[^2]。SSH 秘密鍵を取得するツール、Docker コンテナを実行するツール、これらはそのサーバーが存在する目的そのものである。問題は、AI エージェントがそれらを誤った文脈で呼び出せる構造にある。

設計判断は次の問いに答える形で進む。「この MCP サーバーを、この組織の、この AI エージェントから呼べるようにすべきか」。技術仕様だけでは答えられない。組織のリスク許容度、業務フロー、規制要件 — 文脈の総合判定が要る。

OWASP も MCP Top 10（beta）でツール組成リスクを正式分類した[^2]。MCP 仕様にも readOnlyHint / destructiveHint という個別ツールのアノテーションが入った[^2]。だが、ユーザーが send_email を承認するときに、その本文が前段の read_database で注入された命令に汚染されているかは、アノテーションでは判定できない[^2]。組み合わせの判定は、組み合わせる前に下す必要がある。

エージェントが増えるほど組み合わせが増え、組み合わせが増えるほど、組み合わせを選別する層の価値が上がる。

第二の必然 ── 「速い/遅い」軸の陳腐化

次の論証は、AI コーディングの生産性測定をめぐる事例から始まる。

研究機関 METR（frontier AI システムの測定・評価を行う非営利団体）は 2026 年 2 月 24 日、開発者生産性研究の更新版を公開した[^4]。結果は、AI コーディングツール使用で開発時間が短縮された — 元コホート（10 名）で -18%、新規採用者（47 名）で -4%[^4]。負号は短時間化、すなわち速くなったことを意味する。

旧版（2025 年早期）は +19%（遅化） を報告し、AI 懐疑論の根拠として広く引用されていた。1 年で逆転したことになる。

ところが、r/programming に投稿された議論[^5]がこの研究を取り上げた際、タイトルには「we're measurably slower（計測上遅くなっている）」と書かれた。負号を遅化と読み違えたのである。投稿は 581 upvotes を集め、AI 懐疑側のトップコメントが 507 upvotes、訂正コメント（「グラフを見れば線の上にある」）は 327 upvotes に留まった[^5]。誤読のほうが訂正より多くの賛同を集めた。

この観察から、二つの示唆が得られる。

ひとつは、METR の元データ自体が統計的に有意ではないこと。信頼区間は元コホート -38%〜+9%、新規採用者 -15%〜+9% で、いずれも 0 を含む[^4]。著者は選抜バイアスとタスク選択バイアスを開示している。30–50% の開発者が「AI が向くタスクを敢えて研究に提出しなかった」と回答しており、推定値は下限と評価されている[^4]。「速い」も「遅い」も、研究者自身が「弱い証拠（weak evidence）」と呼ぶ範囲のノイズである。

もうひとつは、「速い/遅い」軸そのものが陳腐化しつつあること。コメント欄では、タスクの 80% は定型的で AI を使うと 3〜5 倍速くなり、残り 20% は非自明で AI が誤った前提のまま試行錯誤するため一桁倍遅くなる、という観察が共有された[^5]。平均値だけでは見えない二峰分布である。

仮にエンジニアの目的が「速度」だったとしても、定型タスクと非自明タスクの比率を判定する能力 — つまり「どのタスクを AI に投げるか」を判定する能力 — が、速度を支配する上位変数になる。Reddit のトップコメントが指摘した通り[^5]、コーディング自体は最も時間消費の少ない部分である。「速さ」の決定要因は、人間の判断品質に移る。

測定基準が信頼できないなら、測定可能な「速さ」より、測定不能な「方向の正しさ」が職能の中核に上がる。

第三の必然 ── 方向を決める者と実行する者の分離

最後の論証は、より具体的な実装事例だ。

エンジニア Shigeru Fukada が Zenn で公開した経験[^6]は、AI 時代のリファクタリング原則を最も簡潔に言語化している。RAG ベース AI チャットアプリの参照元表示改善で、既存の AI 生成コードを +2,539 / -5,652 = 純減 3,113 行 という規模でリファクタリングし、機能追加とコード削減を同時に達成した[^6]。

既存コードの病理は明確だった[^6]。

機能要件のみで AI に書かせると、各機能は仕様通り動く。だが、機能を 6 階層分積層すると、新機能を追加するたびに 6 階層全てに props を追加する必要が生じる。Fukada は「短期コスト低、品質リスク大、次の変更でも同じ苦しみ」と判断し、整理を選択した[^6]。

リファクタ後の数値:

指標 Before After
props drilling 階層 6 0
選択状態フィールド数 6 3
コード増減 — +2,539 / -5,652（純減 3,113行）

注目すべきは、リファクタリングそのものを実行したのも Claude Code（AI コーディングツール）だった点[^6]。違いは指示の精度にある。

機能追加時の指示は局所的：「この機能を作って」。リファクタリング時の指示は設計を伴う：「props drilling を Context に置き換えたい」。Fukada が記事で結論として提示する原則は次の一文に集約される[^6]:

設計の方向性を人間が決め、実行を AI に任せる

技術負債を生み出すのは AI そのものではなく、設計判断を下さない人間が AI に局所的指示を出し続けることである。同じ AI が、設計指示を受ければ広範囲リファクタリングを高速実行する。

これが第三の必然である。AI はベクトル（方向 + 大きさ）を持たない。方向を入力できない者が AI を使うと、ランダムウォークになる。

テイストメーカーは選択ではない

3 つの層が示したものを統合する。

層 観察 帰結
技術 quadratic 攻撃面 (n(n-1)/2)、毒性フロー 555 件 組み合わせを選別する判断層が必須
認識論 「速さ」の信頼区間に 0、二峰分布 速度より方向の正しさが上位変数
組織 純減 3,113 行、props drilling 6→0 設計指示と実行指示の分離が生産性を決定

3 つは独立した観察だが、同じ結論に収束する。AI 出力を最終的に選別し、組み合わせを判定し、設計の方向性を入力する役割を、誰かが必ず担う。それを担わない組織では、組み合わせ空間は剪定されず、速度の幻想が共有され、技術負債が積層する。

LF レポートの議論は、この役割を一語で指す術語の必要を示した[^1]。Architect でも Lead でも PM でもなく、判定責任を中核に据えた職能ラベルとして、テイストメーカーが浮上する。

強調すべきは、これが「人間の創造性礼賛」ではない点だ。Romanticism として読むなら、3 つの観察は不要だった。「人間にしか書けない美しいコードがある」と主張すれば済んだはずだ。だが 3 つの層が示したのは美ではなく、組み合わせ爆発・測定限界・指示精度という工学的構造である。

LF レポートを伝える記事には、末尾に「制作段階で ChatGPT 等の生成系 AI サービスを利用しているが、文責は編集部に帰属する」という注記がある[^1]。記事自身が、記事の主張を実演している。AI が生成し、人間が文責を負う。この構造はすでに、AI 時代のデフォルト契約として機能し始めている。

テイストメーカーが現れるのではない。その役割を担う者だけが残る。職業の再定義は、選択ではなく、すでに進行している事実である。

Sources / 参考文献

[^1]: 「『プログラマー不要論』にThe Linux Foundationが示した答え：『AI任せ』のシステム構築の限界」TechTargetジャパン編集部, 2026-04-24. https://techtarget.itmedia.co.jp/tt/news/2604/24/news09.html[^2]: AgentSeal Research, "555 MCP Servers Have Toxic Data Flows. Here's What We Found." 2026-03-20. https://agentseal.org/blog/toxic-data-flows-mcp-servers[^3]: Reddit r/netsec discussion: "Attack surface analysis of 5,121 MCP servers", 2026-03-21. https://www.reddit.com/r/netsec/comments/1rz7g4q/attack_surface_analysis_of_5121_mcp_servers_555/[^4]: Joel Becker, Nate Rush, Tom Cunningham, David Rein, Khalid Mahamud (METR), "Uplift Update", 2026-02-24. https://metr.org/blog/2026-02-24-uplift-update/[^5]: Reddit r/programming discussion: "93% of devs use AI tools now and we're measurably slower", 2026-03-23. https://www.reddit.com/r/programming/comments/1s155vp/93_of_devs_use_ai_tools_now_and_were_measurably/[^6]: Shigeru Fukada, 「新機能を追加するために3,000行削除した話 — AIが書いたコードの技術負債とどう向き合うか」, Zenn, 2026-03-20. https://zenn.dev/shigerufukada/articles/ccf7cb56eb7b46[^7]: MCPTox benchmark research, arXiv:2508.14925. https://arxiv.org/abs/2508.14925