原文タイトル：Thin Harness, Fat Skills
原著者：Garry Tan
翻訳：Peggy，BlockBeats

編者コメント：当「より強力なモデル」が業界のデフォルト回答となる中、この記事は異なる判断を提供しています：本当に10倍、100倍、さらには1000倍の生産性差を生むのは、モデル自体ではなく、モデルを取り巻くシステムデザイン全体です。

本文の著者であるGarry Tanは、現在Y Combinatorの社長兼CEOであり、長年にわたりAIと初期の起業生態系に取り組んできました。彼は「fat skills + thin harness」というフレームワークを提唱し、AIアプリケーションをスキル、ランタイムフレームワーク、コンテキストルーティング、タスク分業、そして知識圧縮などの重要なコンポーネントに分解しています。

この体系のもと、モデルは能力のすべてではなく、システム内の実行ユニットに過ぎません。出力の品質を真に決定するのは、コンテキストの整理方法、プロセスの固定化、および「判断」と「計算」の境界をどのように明確にするかです。

さらに重要なことは、この方法論が概念的なレベルにとどまらず、実際のシナリオで検証されていることです：数千の起業家に直面するデータ処理とマッチングタスクに対し、システムは「読み取り-集約-判断-書き戻し」のループを通じて、コードの再記述が必要ない状態で、人間のアナリストに近い能力を実現し、持続的なセルフオプティマイゼーションを実現しました。この「学習するシステム」により、AIは一度限りのツールから、複利効果を持つインフラストラクチャに変革されました。

したがって、この記事が提供する中心的な警告も明確になりました：AIの時代において、効率の差は最先端のモデルを使用しているかどうかではなく、持続的な能力の蓄積と自己進化を実現するシステムを構築しているかどうかにかかっています。

以下は原文です：

Steve Yeggeは、AIプログラミングエージェントを使用する人は、「エフィシエンシーがカーソルとチャットツールだけを使ってコードを書くエンジニアの10倍から100倍、およそ2005年のGoogleエンジニアの1000倍」であると述べています。

注：Steve Yeggeは、シリコンバレーで影響力のあるソフトウェアエンジニア、テクニカルブロガー、およびエンジニアリングカルチャの評論家です。鋭い、長大で、強烈な個人スタイルを持つ技術記事で知られています。過去にはAmazonやGoogleなどの企業でシニアエンジニアを務め、その後Salesforceに参加し、さらには初期のAI関連企業で活動しており、また初期のDartプロジェクトの推進者の1人でもあります。

これは誇張ではありません。私はこれを見てきましたし、経験もしました。しかし、このような差があると人々はしばしば誤った方向に帰属させます：より強力なモデル、より賢いクロード、より多くのパラメータ。

実際、効率が2倍に向上した人と100倍に向上した人は、同じモデルを使用しています。違いは「知能」ではなく、「アーキテクチャ」にあり、そしてこのアーキテクチャは、カード1枚に書けるほど単純です。

ハーネス（ランタイムフレームワーク）こそが製品そのものです。

2026年3月31日、Anthropicはクロードコードの完全なソースコードをnpmに誤って公開しました — 総計51.2万行。私はそれを一読しました。これは、私が常にYC（Y Combinator）で語っていることを確認しました：真の秘密はモデルにあるのではなく、「モデルを包むレイヤーに」あります。

リアルタイムのコードリポジトリコンテキスト、プロンプトキャッシュ、特定のタスク向けに設計されたツール、不要なコンテキストの最小化、構造化されたセッションメモリ、並行して実行されるサブエージェント — これらはモデルをより賢くするわけではありません。しかし、それらはモデルに「正しいコンテキスト」を「正しいタイミング」で提供し、無関係な情報に溺れるのを避けることができます。

この「包装」レイヤーは、ハーネス（ランタイムフレームワーク）と呼ばれます。そしてすべてのAI構築者が真に尋ねるべき質問は、ハーネスに何を入れるべきか、何を外に残すべきか、です。

この質問には実際、非常に具体的な回答があります — それを私は、「薄いハーネス（薄いランタイムフレームワーク）」、「太いスキル（豊富な機能）」と呼んでいます。

5つの定義

瓶の栓は常にモデルの知能にありません。モデルは実際にはすでに推論し、情報を総合し、コードを書く方法を知っています。

彼らが失敗する理由は、彼らがあなたのデータを理解していないためです — あなたのスキーマ、あなたの規約、あなたの問題が具体的にどのような形をしているか。そして、以下の5つの定義は、まさにこの問題を解決するためにあります。

1、スキルファイル（技能ファイル）

スキルファイルは、モデルに「何をするか」ではなく、「どのようにするか」を教える再利用可能なマークダウンドキュメントです。注目すべき大部分は：スキルファイルは、実際にはメソッド呼び出しのようなものです。それはパラメータを受け取ることができます。異なるパラメータを使用してそれを呼び出すことができます。同じ手順が、異なるパラメータが渡されることでまったく異なる能力を示すことができます。

例えば、/investigate というスキルがあるとします。これには7つのステップが含まれています：データ範囲の定義、タイムラインの構築、各文書にダイアライズを行う、総合的な要約、両面からの論証、出典の引用。これは3つのパラメータ、TARGET、QUESTION、DATASET を受け取ります。

もし、セキュリティ研究者と210万通の証拠保全メールにそれを適用すると、そのスキルは医学研究アナリストに変身し、告発者が抑圧されたかどうかを判断します。

もし、シェル企業と米国連邦選挙委員会（FEC）の報告書にそれを適用すると、そのスキルは法廷証拠調査官に変身し、協同的政治的寄付の追跡を行います。

同じスキル。同じ7つのステップ。同じMarkdownファイル。スキルの説明は判断プロセスを表しており、それを実際の世界に適用するのは呼び出し時に渡されるパラメータです。

これは「prompt engineering」ではなく、ソフトウェアデザインです：ただし、ここではプログラミング言語としてMarkdownを使用し、ランタイム環境として人間の判断力を使用しています。実際、Markdownは、過程、判断、およびコンテキストを記述しており、これらはモデルが最も理解しやすい言語です。

2、Harness（ランタイムフレームワーク）

Harness は、LLM を実行するためのプログラムレイヤーです。それが行うことは、モデルをループで実行し、あなたのファイルを読み書きし、コンテキストを管理し、セキュリティ制約を実行することのみです。

それだけです。「薄い（thin）」です。

逆のパターンは：太いハーネス、薄いスキルです。

おそらくこれを見たことがあります：40以上のツール定義、説明だけで半分ほどのコンテキストウィンドウを占有する；万能なGod-tool、MCPを往復するのに2〜5秒かかる；あるいは、REST APIの各エンドポイントを個別のツールにラップする。その結果、トークンの使用量が3倍になり、遅延が3倍になり、失敗率も3倍になります。

本当に理想的な方法は、目的に特化し、迅速で機能が限定されたツールを使用することです。

例えば Playwright CLI では、各ブラウザ操作にわずか100ミリ秒かかります。Chrome MCP の場合、スクリーンショットを1回撮るには15秒かかります。前者の方が75倍速いです。

現在のソフトウェアはもはや「過剰に詳細に磨き上げる」必要はありません。あなたがすべきことは、本当に必要なものだけを構築することであり、それだけです。

3、Resolver（リゾルバ）

リゾルバは基本的にコンテキストのルーティングテーブルです。タスクタイプ X が発生すると、ドキュメント Y が優先的に読み込まれます。スキルはモデルに「どのようにするか」を伝えます。リゾルバはモデルに「いつ何を読み込むべきか」を伝えます。

例えば、ある開発者がプロンプトのある行を変更したとします。リゾルバがない場合、彼は変更を行った後すぐにリリースするかもしれません。しかし、リゾルバがある場合、モデルはまず docs/EVALS.md を読み込みます。そしてこのドキュメントには、まず評価スイートを実行し、前後のスコアを比較するという内容が記載されています。精度が2％以上低下した場合、原因を特定してロールバックします。この開発者はもともと評価スイートの存在すら知らなかったかもしれません。正しいコンテキストを適切なタイミングでロードしたのはリゾルバです。

Claude Code にはリゾルバが組み込まれています。各スキルには説明フィールドがあり、モデルはユーザーの意図をスキルの説明と自動的にマッチングします。/ship というスキルが存在することを覚えておく必要すらありません。説明そのものがリゾルバです。

率直に言って、以前の私の CLAUDE.md には20000行もありました。すべてのクセ、パターン、遭遇したすべての教訓がそこに詰め込まれていました。これはばかげています。モデルの注意力の品質が著しく低下しています。Claude Code は私にそれを削除するように直接指示しました。

最終的な修正策は、おそらくたったの200行だけでした。いくつかのドキュメントポインターだけを残しました。本当に必要なドキュメントは、リゾルバにその時に読み込ませるようにします。このようにすれば、20000行の知識は引き続き利用できますが、コンテキストを汚染することはありません。

4、Latent と deterministic（潜在空間と決定論的）

あなたのシステムでは、各ステップはこのカテゴリに属するか、あるいはそのカテゴリに属するかのどちらかです。そして、これらを混同することは、エージェントデザインにおける最も一般的な誤りです。

・潜在空間は、知能の存在する場所です。モデルはここで読み、理解し、判断し、意思決定します。ここで扱われるのは、判断、総合、パターン認識です。

・決定論的は、信頼性の存在する場所です。同じ入力に対し、常に同じ出力を得ます。SQL クエリ、コンパイルされたコード、算術演算などがこれに属します。

1 つの LLM は、8 人の人々の夕食の座席を手配するのに役立ちます。各人の性格と社会関係を考慮しつつ。しかし、800 人の座席を手配するように要求すると、それは「見た目は合理的でありながら、実際には完全に誤っている」座席表を真顔で作り上げるでしょう。なぜなら、これは潜在空間が扱うべき問題ではなく、latent space に硬直的に詰め込まれた決定論の問題、具体的には組合せ最適化問題だからです。

最悪のシステムは、常にその境界線の両側において仕事を間違った場所に配置します。一方、最良のシステムは、非常に容赦なく境界線を明確に引きます。

5、Diarization（文書整理 / トピックの描写）

Diarization は、AI が現実の知識に基づいて作業するのに真に重要なステップです。

その意味は、モデルが特定のトピックに関連するすべての資料を読み、その後、構造化された描写を作成することです。何十枚、場合によっては何百枚もの文書からの見解を 1 枚の紙に凝縮します。

これは SQL クエリが出力できるものではありません。これは RAG パイプラインが出力できるものでもありません。モデルは実際に読み進め、相互に矛盾する情報を同時に把握し、何が変化したか、いつ変化したかに注意を払い、それらの内容を総合的な構造化された知識に変換する必要があります。

これがデータベースクエリとアナリストのレポートの違いです。

This Architecture

これら 5 つの概念は、非常にシンプルな 3 層アーキテクチャに組み合わされることができます。

・最上位レイヤーはファットスキル：Markdown で書かれた手続きがあり、判断、方法論、およびドメイン知識を保持します。価値の 90% は、このレイヤーにあります。
・中間層は薄い CLI ハーネス：約 200 行のコードで、JSON を入力とし、テキストを出力し、デフォルトでは読み取り専用です。
・最下層はアプリケーションシステムです：QueryDB、ReadDoc、Search、Timeline — これらは確定性の基盤です。

核心原則は方向を指定することです：「インテリジェンス」をスキルに、そして「実行」を確定性ツールにできるだけ押し上げて、ハーネスを軽量化したままにします。

その結果、モデルの能力が向上するたびに、すべてのスキルが自動的に強化され、そして下部の確定性システムは常に安定かつ信頼性が保たれます。

学習するシステム

以下是我使用一个我们正在 YC 构建的真实系统来展示这五个定义如何一起工作。

2026 年 7 月，Chase Center。Startup School 有 6000 名创始人参加。每个人都有结构化申请材料、问卷回答、与导师 1:1 对话的转录，以及公开信号：X 上的发帖、GitHub 提交记录、Claude Code 的使用记录（可以看出他们的开发速度）。

传统做法是：15 个人的项目团队逐份阅读申请，凭直觉判断，然后更新一张表格。

这个方法在 200 人规模时还能运转，但在 6000 人时就彻底失效了。没有人类能在脑中同时容纳这么多画像，并意识到：AI agent 基础设施方向最优秀的三个候选人，分别是拉各斯的开发工具创始人、新加坡的合规创业者、以及布鲁克林的 CLI 工具开发者——而他们在不同的 1:1 对话中，用完全不同的表述描述了同一个痛点。

模型可以做到。方法如下：

Enrichment（情報強化）

有一个技能叫 /enrich-founder，它会拉取所有数据源，做信息增强、diarization，并标出「创始人说的」和「实际在做的」之间的差异。

底层的确定性系统负责：SQL 查询、GitHub 数据、Demo URL 的浏览器测试、社交信号抓取、CrustData 查询等。一个定时任务每天运行一次。6000 个创始人画像始终保持最新。

diarization 的输出，能捕捉到关键词搜索完全无法发现的信息：

创始人：Maria Santos 公司：Contrail（contrail.dev） 自述："AI agent 的 Datadog" 实际在做：80% 的代码提交集中在计费模块 → 本质是在做一个披着可观测外衣的 FinOps 工具

这种「说法 vs 实际行为」的差异，需要同时读取 GitHub 提交历史、申请材料和对话记录，并在脑中整合。没有任何 embedding 相似度搜索能做到这一点，关键词过滤也不行。模型必须完整阅读，然后做出判断。（这正是应该放在 latent space 的任务！）

マッチング（Matching）

これは「スキル = メソッドコール」が力を発揮する場所です。

同じマッチングスキルを3回呼び出すと、まったく異なる戦略が生み出される可能性があります：

/match-breakout：1200人を処理し、ドメインごとにクラスタリングし、30人ごとのグループ化（埋め込み + 決定論的アサインメント）

/match-lunch：600人を処理し、クロスドメインの「ランダムマッチング」、各テーブル8人で重複なし——LLMが最初にトピックを生成し、それから決定論的アルゴリズムで座席を配置

/match-live：現場でのリアルタイム参加者を処理し、最近傍埋め込みを基に、200ms以内に1対1のマッチングを完了し、既に会った人を除外

さらに、モデルは従来のクラスタリングアルゴリズムでは達成できない判断を下すことができます：

「SantosとOramは両方ともAIインフラストラクチャに属していますが、競合関係ではありません—Santosはコストアトリビューションを行い、Oramは配置を行っています。同じグループに配置すべきです。」
「Kimは申請時には開発者ツールと書いていましたが、1対1の会話では、SOC2コンプライアンスの自動化に取り組んでいることがわかりました。FinTech / RegTechに再分類すべきです。」

このような再分類は、埋め込みが完全に捉えられないものです。モデルは全体の画像を読む必要があります。

学習ループ（Learning Loop）

イベント終了後、/improveスキルはNPS調査結果を読み込み、「まあまあ」のフィードバックに関してダイアライズを実行します—否定的なレビューではなく、「もう少しでよかった」フィードバック—そしてパターンを抽出します。

その後、新しいルールを提案し、マッチングスキルに書き戻します：

参加者が「AIインフラストラクチャ」と言った場合、コードの80%以上が課金モジュールである場合：
→ FinTechに分類し、AIインフラではなく

同じグループ内の2人が既に知り合いである場合：
→ マッチングの重みを下げる
新しいリレーションシップを優先的に導入

これらのルールはスキルファイルに書き戻されます。次回実行時に自動的に有効になります。スキルは「自己書き換え」を行います。7月のイベントでは、「まあまあ」の評価が12%を占めていましたが、次のイベントでは4%に低下しました。

skill ファイルが「まあまあ」の意味するものを習得すると、システムはコードを書き換えることなくより良くなります。

このパターンはどの分野にも適用できます：

取得 → 読み取り → 日誌化 → カウント → 統合

そして：調査 → 検証 → 日誌化 → skill の書き換え

もし2026年に最も価値のあるループを尋ねるなら、それはこのセットです。ほとんどすべての知識作業に適用できます。

スキルは永続的なアップグレードです

最近、X に OpenClaw へのコマンドを投稿しました。反応は予想を上回りました：

Prompt: 一度限りの作業を許可しません。もし将来繰り返される作業をお願いする場合、最初に3から10のサンプルを手動で処理して結果を示してください。私が承認すれば、それを skill ファイルに記述してください。自動実行する必要がある場合は、定期タスクに追加してください。判断基準は：2回目に尋ねる必要がある場合、失敗したと見なされます。

このコンテンツは1000以上いいねを獲得し、2000以上のブックマークがつきました。多くの人がこれを prompt engineering のテクニックと考えています。

実際には、これは先ほど説明したアーキテクチャです。書き留めた各スキルは、システムの永続的なアップグレードです。それは退化せず、忘れ去られません。午前3時に自動実行されます。そして次世代のモデルがリリースされると、すべてのスキルが一瞬で強化されます──latent 部分の判断能力が向上し、deterministic 部分は依然として安定して信頼できます。

これがYeggeが言う100倍の効率の源泉です。

より賢いモデルではなく、むしろ：厚いスキル、薄いハーネス（Thin Harness, Fat Skills）、そしてすべてを能力に固定する規律です。

システムは複利的に成長します。一度構築し、長期運用します。

[Original Article Link]

BlockBeats の公式コミュニティに参加しよう：

Telegram 公式チャンネル：https://t.me/theblockbeats

Telegram 交流グループ：https://t.me/BlockBeats_App

Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia