CLOUD SECURITY LAB

🔧 ハーネス(Harness)とスキル(Skill)は何が違うのか？ — AIエージェント時代の核心概念整理

—

by

cslab
in

エージェントが「何ができるか」がスキルであれば、「どのように運用されるか」がハーネスである。

>

🎯 この記事で扱うこと

  • OpenAIのハーネスエンジニアリング実験 — 100万行のコード、人間による記述は0行
  • Anthropicが定義した長期実行エージェントのハーネス構造
  • スキル(Skill)とハーネス(Harness)の根本的な違い
  • なぜこの2つの概念が混同されるのか、どのように区別すべきか
  • 実務でハーネスを直接設計する方法

📌 導入 — なぜこの区別が重要になったのか

2025年末から2026年初頭にかけて、AIエージェントの世界に2つの重要な記事が登場しました。

1つは、OpenAIがCodexエージェントを活用して約100万行のコードを人間の手を借りずに完成させた内部実験をまとめた「Harness Engineering」という投稿でした。もう1つは、AnthropicがClaude Agent SDKを利用して、複数のコンテキストウィンドウにわたってエージェントが一貫して作業を継続できるように設計した方法論を紹介したエンジニアリングブログでした。

どちらの記事も「ハーネス(Harness)」という言葉を使用していました。しかし、現場ではこの概念が「スキル(Skill)」と混同され、混用されることがよくあります。

エージェントを直接設計または運用しようとするエンジニアであれば、これら2つの概念の違いを正確に理解している必要があります。

🔍 スキル(Skill)とは何か

スキルは、エージェントが外部世界と相互作用する単位能力です。簡単に言えば、エージェントが「何ができるか」のリストです。
分類 例
基本ツール bash実行、ファイル読み書き、git操作
MCPサーバー Puppeteer(ブラウザ自動化)、Slack、Google Drive
外部API ウェブ検索、データベースクエリ、コード実行
サブエージェント 特定の役割に特化した下位エージェントへの委任

スキルはエージェントのランタイムまたは周辺機器(peripherals)と見なすことができます — モデルが環境とどのように相互作用するかを定義します。

人間に例えるなら、スキルは個人の能力です。Pythonでコーディングできる、英語でコミュニケーションできる、データを分析できる — これらがスキルです。

🔍 ハーネス(Harness)とは何か

ハーネスは、エージェントを取り巻く実行環境全体です。エージェントハーネスはAIモデルを包み込み、そのライフサイクル・コンテキスト・ツールアクセス・検証・安全性を管理するインフラレイヤーです。モデルがテキストを生成する場合、ハーネスはモデルが何を見るか、何ができるか、いつ停止すべきか、誤った場合に何が起こるかを決定します。

ハーネスは、エージェントを生産的かつ正しい方向に維持するための制約、ツール、ドキュメント、フィードバックループの集合体です。

再び人間に例えるなら、スキルが「個人の能力」であるとすれば、ハーネスは会社のオンボーディングシステム、コードレビュープロセス、KPI、ドキュメント体系のようなものです。どんなに優れた個人能力を持つ従業員でも、適切な業務環境がなければ、一貫して良い成果を出すことはできません。

🔍 2つの概念の核心的な違い
区分 スキル (Skill) ハーネス (Harness)
定義 エージェントの個別能力単位 エージェントを包む実行環境
質問 「何ができるか？」 「どのように運用されるか？」
構成要素 ツール、MCPサーバー、API、関数 制約、フィードバックループ、コンテキスト管理、ドキュメント構造
適用時点 エージェントが行動するとき エージェントが存在する間ずっと
設計主体 ツール提供者(開発者) 環境設計者(エンジニアリングチーム)
比喩 従業員の個人技術 会社の業務体系/プロセス

🔍 OpenAIのハーネスエンジニアリング

OpenAIの5ヶ月間の内部実験では、エンジニアはコードを直接記述しませんでした。彼らが設計したのは、信頼性の高いコード生成を可能にする環境であり、その環境に付けられた名前がハーネスです。

OpenAIハーネスの構成要素は以下の通りです。

1. AGENTS.md — 目次としての知識マップ

単一の巨大なドキュメントの代わりに、約100行の短いAGENTS.mdをコンテキストに注入し、これを目次として使用します。実際の知識ベースは構造化されたdocs/ディレクトリに存在し、設計ドキュメント、実行計画、アーキテクチャマップが単一の情報源として管理されます。

2. 階層型アーキテクチャの強制

Types → Config → Repo → Service → Runtime → UIの順序で厳格な依存関係レイヤーをカスタムリンターと構造テストで強制します。エージェントはこのモジュール境界を違反することはできません。

3. ドリフト検出エージェント

バックグラウンドエージェントが定期的に古いドキュメントをスキャンし、クリーンアップPRを開きました — エージェントのためのドキュメントを、エージェントが作成する構造でした。

🔍 Anthropicのハーネス — 長期実行エージェント問題解決

Anthropicが直面した核心的な課題は、エージェントが複数のコンテキストウィンドウにわたって一貫した進行を維持することでした。各新しいセッションは、以前に何が起こったかについての記憶なしに開始されます。これは、交代勤務のエンジニアが互いに引き継ぎなしで作業する状況に似ています。

Anthropicの解決策は、役割を2つのエージェントに分離することでした。

イニシャライザーエージェント(Initializer Agent)

最初のセッションで動作し、init.shスクリプト、claude-progress.txt進行ログ、初期gitコミットを設定します。

特に、機能リスト(Feature List)をJSON形式で作成することが重要です。

{
  "category": "functional",
  "description": "New chat button creates a fresh conversation",
  "steps": [
    "Navigate to main interface",
    "Click the 'New Chat' button",
    "Verify a new conversation is created"
  ],
  "passes": false
}

JSONが選択された理由は、エージェントがMarkdownファイルよりもJSONファイルを不適切に修正したり上書きしたりする可能性が低いからです。

コーディングエージェント(Coding Agent)

以降のすべてのセッションで、一度に1つの機能のみを処理するように要求されます。セッション終了時には、gitコミットと進行状況ファイルの更新を通じて、次のエージェントが迅速にコンテキストを把握できるように環境を整理します。

🔍 エージェント失敗モードとハーネスの解決方式

エージェントの主な失敗パターンは2つありました。1つ目は、一度に多くのことを実装しようとしてコンテキストの途中で終了し、次のセッションが半分しか完成していないコードを引き継ぐ問題。2つ目は、一部の機能が完成すると残りの機能も完成したと宣言してしまう問題でした。

このような失敗を防ぐのがハーネスの役割です。
失敗パターン イニシャライザーエージェント対応 コーディングエージェント対応
早期完了宣言 JSON機能リストファイル作成 セッション開始時に機能リスト確認
未文書化の進行状況 初期git + 進行ノート設定 セッション開始/終了時に更新
テストなしで完了処理 ブラウザ自動化ツール設定 すべての機能を直接検証後、合格と表示
アプリ実行方法探索の無駄 init.shスクリプト作成 セッション開始時にinit.sh実行

—

💻 ハーネス構造を直接作成してみる

以下は、Anthropicブログを参考にした最小限のハーネス構造の例です。

project/
├── AGENTS.md            # エージェント用目次 (100行以下)
├── docs/
│   ├── architecture.md  # システムアーキテクチャ
│   ├── decisions/       # 設計決定履歴
│   └── api-contracts/   # インターフェース契約
├── init.sh              # 開発サーバー起動スクリプト
├── feature_list.json    # 機能リスト (passes: false → true)
└── claude-progress.txt  # セッション間引き継ぎファイル

feature_list.json 機能項目更新例:

import json

def mark_feature_done(feature_id: str):
    with open("feature_list.json", "r+") as f:
        data = json.load(f)
        for feature in data["features"]:
            if feature["id"] == feature_id:
                feature["passes"] = True
                feature["completed_at"] = "2026-04-14"
        f.seek(0)
        json.dump(data, f, indent=2)
        f.truncate()

claude-progress.txt 作成パターン:

## Session 2026-04-14

### Completed
- [FEAT-012] 로그인 폼 유효성 검사 구현
- [FEAT-013] JWT 토큰 발급 로직 추가

### Current State
- 개발 서버 정상 동작 중 (port 3000)
- 기본 인증 플로우 동작 확인 완료

### Next Priority
- [FEAT-014] 리프레시 토큰 처리 로직 (미시작)

⚠️ 注意事項 — よくある設計ミス

スキルを多く与えればハーネスが強くなるという錯覚

Vercelがツール数を80%削減した際、パフォーマンスはむしろ向上しました。プロダクションハーネスは、タスクの段階に応じて利用可能なツールを動的に制限します。スキル過多はエージェントを混乱させます。

単一の巨大な指示ファイルの落とし穴

単一の巨大なマニュアルは、古いルールの墓場となります。エージェントは何がまだ有効か区別できず、人間はメンテナンスを停止し、そのファイルは静かに有害な妨害物となります。

コンテキスト過負荷

コンテキスト使用率が約40%を超えると、パフォーマンスが低下します。ツール、冗長なドキュメント、蓄積された履歴でエージェントを満たすと、かえってパフォーマンスが低下します。

✅ まとめ
項目 スキル ハーネス
核心質問 何ができるか？ どのように運用されるか？
主要構成 ツール、MCP、API ドキュメント構造、制約、フィードバックループ、コンテキスト管理
設計対象 エージェントの能力 エージェントの環境
失敗時の症状 特定作業不可 一貫性のない結果、ドリフト、ループ

エージェント時代のエンジニアリング分野は、コード作成から環境設計へと移行しています。最も効果的なエンジニアは、最も速いコーダーではなく、エージェントがその中で推論できるようにリポジトリを構造化する方法を理解している最高の環境設計者です。

スキルはエージェントに翼を与えるものであり、ハーネスはその翼が正しい方向に飛べるようにする航空管制システムです。

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です