AIハーネスとスキルはそれぞれ何をするのか

生産性100倍という言葉を確かめてみたかった

私は「生産性が何倍も高まった」という話を聞くと、まず何を基準に比較したのか気になります。AIエージェントをうまく使えば生産性が100倍になるという主張についても、同じように感じました。数字をそのまま受け入れるよりも、同じモデルを使いながら作業の進め方がどう変わり得るのかを見てみたいと思いました。

ちょうどその頃、2026年3月31日にClaude Codeのクライアントソースがnpm配布パッケージのソースマップを通じて流出する事件がありました。約51万行規模のプログラムコードでした。モデルの重みではなく、モデルを呼び出しツールを実行する製品コードに関する事件です。この件についてはZDNetのコラムも書いたことがあります。

Y Combinatorのギャリー・タンはこのコードを読み、自身がかねて強調していた設計方式の重要性を再確認したと書いています。彼が注目したのは、モデルに必要なファイルと情報を提供し、作業を続けていくプログラム構造でした。

その記事のタイトルは「Thin Harness, Fat Skills」です。実行を調整するプログラムは簡潔に保ち、業務ごとの手順は再利用できるスキルとしてまとめようという提案です。

私は生産性の倍率よりも、この役割分担のほうに関心が向きました。モデルの性能が同じでも、どんな資料を読ませ、どんなツールを使わせ、結果をどう確認するかによって、作業結果は変わり得るからです。

同じモデルを使っても作業条件は異なる

タンの記事は、スティーブ・イェギの大きな生産性向上の主張を引用するところから始まります。コーディングエージェントをうまく使いこなす人は、チャットボットや他のツールを使う人より10~100倍生産的だというものです。しかしその記事には、この倍率を一般化できるような比較実験や共通の測定基準は示されていません。

したがって、100倍という数値がコード流出事件によって裏付けられたと言うのは難しいでしょう。確かめるべき問いはもっと具体的です。モデルがリポジトリの規則を把握しているか、必要な資料を見つけられるか、コードを実行した後にエラーを確認できるか、といったことです。

モデル自体の能力とともに、こうした作業環境も見る必要があります。どちらか一方だけが優れていれば、すべての問題が解決すると考えるのは難しいでしょう。

たとえばコードを修正するよう依頼されたエージェントは、関連ファイルを読み、修正し、テスト結果を受け取って次の行動を決めます。この過程をつなぐプログラムがあってこそ、モデルの応答は実際の作業へとつながります。公開されていない機能名やコードの存在だけをもって、その機能が製品として出荷されたと判断することもできません。

このように、モデルの呼び出し、ツールの実行、作業の状態や権限などを管理するプログラムをハーネス（harness）¹と呼びます。この記事では、モデルが実際に仕事をこなせるよう実行過程を管理する部分、という意味で理解しておけば十分です。

実行管理、業務手順、計算ツールを切り分けてみる

タンは、業務ごとに必要な手順をスキルに収め、ハーネスはその手順とツールを実行することに集中させようと提案しています。すべてのシステムにそのまま適用すべき標準構造というより、彼が開発経験にもとづいて勧める設計の方向性です。

彼が批判しているのは、使いもしないツールの説明を一度に詰め込んだり、不要な呼び出し段階を増やしたりするやり方です。入力が長くなり、ツールの応答を待つ時間が増えることがあります。ただし、ツールの数が多い、あるいはMCP²を使っているという理由だけで、トークン・時間・失敗率がすべて3倍になるわけではありません。実際の呼び出しと作業を基準に測定する必要があります。

それぞれの役割を分けると次のようになります。

スキル（Skill）³は、特定の業務の手順と参考資料をまとめたものです。中心にはマークダウン文書であるSKILL.mdがあり、必要に応じて実行するスクリプトや例示ファイルを一緒に置くこともできます。タンは、調査対象、質問、資料を受け取って分析の手順を適用する/investigateスキルを例に挙げています。

彼が挙げた例は、研究者による安全性の問題提起に関するメールを調査すること、選挙資金の資料から法人間の関係を調査することです。異なる資料であっても、範囲を定め、時系列に整理し、相反する根拠を検討するという手順は再利用できる、という説明です。この例だけをもって、その調査が実際に完了した、あるいは専門家水準の正確さを得たと見なすことはできません。

ハーネスはモデルを呼び出し、ファイル・ツールへのアクセスと作業の状態、権限を管理します。タンは約200行の簡潔なCLI構造を提案していますが、運用環境によって必要な機能は異なります。コードの行数を減らすために、権限確認やエラー復旧を省略してはいけません。

計算や定型的な条件検査は、別のツールに任せることができます。たとえば表の合計を計算したり、すべての項目が条件を満たしているかを検査したりする作業は、モデルに答えを書かせるよりも、コードで実行して結果を確認するほうが適しています。ここで言う決定論的処理⁴とは、同じ入力と状態から同じ結果を出すよう設計された処理を意味します。

座席の割り当てを例にすると、違いがはっきりします。誰と誰を一緒に座らせるとよいか、意見をまとめる作業にはモデルを使えます。しかし、数百人を割り当てながら重複や定員超過がないかを確認するには、条件をコードで検査するほうが適しています。

割り当ての条件が複雑であれば、最適化ツールを使うこともできます。ただし、コードやSQLだからといって自動的に正確になるわけではありません。入力資料や制約条件が誤っている場合もあれば、プログラムにも誤りがあり得ます。モデルの判断とツールの計算を、それぞれ検証する過程が必要です。

スキルには業務の手順と判断基準を記し、ハーネスは実行を管理し、ツールは計算とデータ処理を担う、というかたちです。このように役割を分けておくと、エラーが起きたときにどの部分を直せばよいか見極めやすくなります。

スキルは必要な瞬間に読み込む

Agent Skillsはコード流出事件よりも前から公開されていました。構造を理解するために流出コードを入手する必要もありません。公式文書でファイル構成と動作方式を確認できます。

Anthropicは2025年10月16日にAgent Skillsを紹介し、12月18日には複数の製品で使える公開標準として発表しました。SKILL.mdの名前と説明、指針、追加ファイルをひとまとめにする方式です。このファイル形式の公開と、タンが提案したハーネス設計が業界全体の標準になったという主張とは、区別する必要があります。

公式文書が強調している原則は、必要な情報を順に読んでいく段階的開示（Progressive Disclosure）⁵です。まず名前と説明を読んでどのスキルが関連しているかを判断し、必要なときにSKILL.mdの本文を読みます。本文が指し示す補助資料も、その作業に必要なときに呼び出せます。最初からすべての文書を入力に入れなくてもよい方式です。

タンも似たような経験を紹介しています。自分が経験したことをすべて盛り込んだ結果、CLAUDE.mdが約2万行になり、その後、他の文書を指し示す約200行の案内文にまで削ったというのです。必要な作業が生じたときに該当文書を探しに行くように変えたわけです。これは彼自身の運用経験であり、すべてのプロジェクトにとって200行が最適だという意味ではありません。

この方式を使うには、文書を短く分けるだけでは不十分です。どんな状況でどの文書を読むべきかの説明が明確でなければならず、モデルが実際に必要な文書を見つけているかどうかも確認する必要があります。

Oswarldの視点

私はこの構造を見ながら、組織が業務知識をどのように残すかについて考えました。文書として整理された規定や、ソフトウェアとして実装された手順があっても、実際の見積もりや契約審査でどんな順序で何を確認するのかは、担当者の経験の中にしか残っていない場合があります。こうした部分を、文書とツールに分けて整理できるのではないかと考えました。

たとえば見積作成スキルには、必要な入力、価格表を確認する順序、割引の承認を受けるべき条件、計算結果を確認する項目を記すことができます。価格計算は別のツールが担います。こうした文書は、次の担当者やエージェントが手順を再利用する際に役立つでしょう。

ただ、タンの記事でスキルを「永続的なアップグレード」と表現している部分には同意しがたいです。手順もまた、会社の方針やツールが変われば古びます。新しいモデルが指針を違ったふうに解釈することもあります。コードに技術的負債⁶が生じるのと同じように、スキルにも修正・検証すべき事柄が積み重なり得ます。

セキュリティも管理の対象です。Snykは2026年2月、公開スキル3,984件を検査し、1,467件、約36.82%で少なくとも1つのセキュリティ問題を見つけたと報告しています。ClawHubなどを対象にしたこの調査結果であり、すべての公開スキルにおける欠陥比率として一般化することはできません。悪意ある指示と意図しない脆弱性の両方を含んだ数値です。

スキルは文書の形をとっていても、ファイルへのアクセスやコードの実行に影響を与えることがあります。誰が管理するのかを定め、修正履歴を残し、外部へデータを送ったりコマンドを実行したりする部分を審査する必要があります。私は、こうした管理まで含めて再利用できるようになって初めて、組織にとって役立つ資産になると考えます。

おわりに

最初の問いに戻ると、ハーネスやスキルという名前だけで生産性100倍を説明することはできません。同じ品質の結果を得るのにかかった時間、人が手直しした時間、失敗した作業まで合わせて見る必要があります。私は大きな倍率よりも、こうした比較のほうに関心があります。

モデルを選ぶことと合わせて、作業環境を整える必要があります。必要な情報がどこにあるか、どのツールを使うか、何をもって成功とみなすかを決めておけば、結果が思わしくなかったときに原因を探るのも容易になります。

新しい用語が次々と出てきても、すべての名前を覚える必要はないと思います。どのプログラムが実行を管理し、どの文書が業務手順を伝え、どのツールが結果を計算するのかを理解していれば、実際の導入について議論できます。

スキルを導入するなら、まずは反復業務一つから始めてみるとよいと思います。手順を文書に残し、実際の事例に適用し、抜け落ちていた条件や誤った結果を直していくのです。モデルや手順を変えた後も、同じ事例で改めて確認します。

こうして確認された手順が積み重なれば、チームの経験をより容易に共有できるようになるでしょう。文書の数やハーネスのコードの長さよりも、次の作業で実際に役立ったかどうかが重要な基準だと考えます。

チームでエージェントを使って削減した反復業務があれば、何が減り、何は依然として自分で確認しなければならなかったのか、ぜひ教えてください。そうした経験が、導入方法を具体的に語り合ううえで役立つと思います。

参考資料と関連リンク

主要出典

• Garry Tan, “Thin Harness, Fat Skills”, gbrain GitHub repository, 2026。：タンの設計提案と個人的な運用経験をまとめた記事です。生産性の倍率を検証した実験報告ではありません。
• Anthropic, “Equipping agents for the real world with Agent Skills”, Anthropic Engineering Blog、2025年10月16日（12月18日の公開標準に関する更新あり）。：SKILL.md標準とProgressive Disclosure（段階的開示）の設計原則が詳しく説明されています。スキルを自分で作ってみるなら、この文書から読むのがよいでしょう。
• Steve Yegge, “The AI Vampire”, Medium、2026年2月。：エージェント使用の経験と作業の強度、疲労を論じた個人的なエッセイです。
• Gergely Orosz, “Steve Yegge on AI Agents and the Future of Software Engineering”, The Pragmatic Engineer、2026年2月。——イェギ本人のエージェント使用経験と導入に関する見解を聞けるインタビューです。

背景知識

• VentureBeat, “Claude Code’s source code appears to have leaked: here’s what we know”, 2026年3月31日。：2026年3月31日のClaude Codeソース流出を報じた記事です。
• Zscaler ThreatLabz, “Anthropic Claude Code Leak”, 2026年4月。：ソース流出を餌にマルウェアを配布した事例を分析しています。同日のAxiosサプライチェーン攻撃は別件です。
• Snyk, “Agent Skills Security Audit Report”, 2026年2月。：調査対象3,984件のうち1,467件でセキュリティ問題を報告しています。調査範囲と検出基準もあわせて確認する必要があります。

筆者アン・グァンソプ（安光涉）は世宗大学校経営学科教授であり、INLEVEL9のリードコンサルタントである。大学では経営データ管理、ビジネスアナリティクスなど統計およびデータ分析を教える一方、実務ではGTM戦略とAI戦略コンサルティングを率い、技術とビジネスの接点を設計している。AI対話システムの記憶アーキテクチャ（HEMA）研究で学術論文を発表しており、毎日グローバルなAI論文をキュレーションするDaily Arxivプロジェクトを運営している。高麗大学校技術経営専門大学院の修士課程とKMBAを修了した。著書に《考えを委ねる人々：ホモ・ブレインレス》がある。

著者 アン・グァンソプ（Oswarld） は世宗大学校 兼任教授、INLEVEL9 戦略コンサルタントです。経歴、研究、著書、最近の活動は著者紹介で更新しています。 最近の活動 · 2026年7月：HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI。

각주

1. ハーネス（Harness）：モデルの呼び出し、ツールの実行、作業の状態や権限などを管理するプログラムを指します。実装によって含まれる機能は異なります。 ↩

2. MCP（Model Context Protocol）：AIアプリケーションが外部のツールやデータに接続する方式を定めた公開プロトコルです。業務手順を収めるスキルと併せて使うことができます。 ↩

3. Agent Skill：SKILL.mdの指針と、必要に応じたスクリプト・参考資料をまとめた構成です。文書を追加したからといって、その分野の正確さや専門性が自動的に保証されるわけではありません。 ↩

4. 決定論的処理：同じ入力と同じ状態から同じ結果を出す処理です。コードやSQLの結果も、データ、実行環境、時刻・乱数の使用などによって変わり得るため、条件を併せて管理する必要があります。 ↩

5. 段階的開示（Progressive Disclosure）：必要な情報を段階的に読んでいく方式です。スキルの名前と説明で関連性を判断し、本文と補助ファイルは必要なときに呼び出します。 ↩

6. 技術的負債：短期的な選択や先送りにした改善のために、その後の修正・運用に追加コストがかかる状態を意味します。 ↩