はじめに
こんばんは、mirukyです。
「AIエージェントにコードを書かせたら、半分書いたところでコンテキストが切れて、次のセッションで最初からやり直しになった。」
この経験、ありませんか。
2025年後半から、AIコーディングエージェントの能力は飛躍的に向上しました。Claude Code、OpenAI Codex、Kiro CLI、GitHub Copilot Agent Mode ── どれもコードを「書く」能力は十分です。しかし、長時間の自律作業で一貫した品質を維持する能力は、まだ人間の設計に依存しています。
その設計手法こそが、ハーネスエンジニアリングです。
プロンプトエンジニアリングが「何をどう指示するか」、コンテキストエンジニアリングが「何を文脈に含めるか」を扱うのに対し、ハーネスエンジニアリングは**「AIエージェントが長期間、安定して成果を出し続けるための環境と制御構造をどう設計するか」**を扱います。
本記事では、この新しいパラダイムの全貌を解説します。
本記事の情報は2026年3月時点のものです。ハーネスエンジニアリングは急速に発展中の概念であり、各ツール・フレームワークの仕様は変更される可能性があります。
目次
- ハーネスエンジニアリングとは
- パラダイムの進化 ── Prompt → Context → Harness
- なぜ今ハーネスエンジニアリングが必要なのか
- ハーネスエンジニアリングの5つの柱
- 実践: エージェントハーネスの構築
- 失敗パターンと対策
- 各ツールにおけるハーネスの実装
- コンテキストエンジニアリングとの関係
- 実例: 350Kラインを52日で構築した開発者の教訓
- おわりに
1. ハーネスエンジニアリングとは
1-1. 「ハーネス」の語源と意味
「ハーネス（harness）」には2つの由来があります。
| 由来 | 意味 | ハーネスエンジニアリングでの対応 |
|---|---|---|
| 馬具のハーネス（手綱・馬具） | 馬の力を制御し、意図した方向に導くための装具 | AIエージェントの自律性を制御し、意図した成果に導く仕組み |
| ソフトウェアのテストハーネス | テスト対象を包み込み、実行・検証・ログ取得を行うフレームワーク | エージェントの実行を包み込み、進捗管理・品質検証・状態保存を行う仕組み |
どちらの意味も、ハーネスエンジニアリングの本質を端的に表しています。強力だが制御が必要な力を、構造的に管理するという考え方です。
1-2. 定義
ハーネスエンジニアリングとは、AIエージェントが複数のコンテキストウィンドウにまたがって一貫した品質で作業を継続するための、環境・制御構造・フィードバックループを設計する技術体系です。
Anthropicが2025年11月に公開した技術ブログ「Effective harnesses for long-running agents」では、この課題を次のように表現しています。
長時間稼働するエージェントの核心的な課題は、エージェントが個別のセッションで作業しなければならず、各セッションは前のセッションの記憶なしに始まるということです。シフト制で働くソフトウェアエンジニアのチームを想像してください。新しいエンジニアが、前のシフトで何が起こったかの記憶なしに到着するのです。
1-3. ハーネスエンジニアリングが扱う範囲
ハーネスエンジニアリングは、以下の領域を横断的に設計します。
| 領域 | 具体的な設計対象 |
|---|---|
| 環境構築 | ディレクトリ構造、設定ファイル、初期化スクリプト、開発サーバー |
| 進捗管理 | フィーチャーリスト、進捗ファイル、gitコミット履歴 |
| フィードバックループ | コンパイル、ユニットテスト、E2Eテスト、CIパイプライン |
| セッション間の橋渡し | 進捗メモ、構造化されたハンドオフ、環境の「クリーン状態」維持 |
| 品質ガードレール | アーキテクチャ規約、技術的負債の制御、テストによる自己検証 |
2. パラダイムの進化 ── Prompt → Context → Harness
2-1. 3つのパラダイムの比較
AIとの協働手法は、3つのパラダイムを経て進化してきました。
| 観点 | プロンプトエンジニアリング | コンテキストエンジニアリング | ハーネスエンジニアリング |
|---|---|---|---|
| 時期 | 2022年〜 | 2025年前半〜 | 2025年後半〜 |
| 中心人物/契機 | OpenAI GPT-3公開 | Andrej Karpathy、Tobi Lutke | Anthropic「Effective harnesses」 |
| 対象 | 単発のLLM呼び出し | コンテキストウィンドウの設計 | 複数セッションにまたがるエージェント |
| 主な関心 | 指示の書き方 | 文脈に何を含めるか | エージェントが安定して動く環境全体 |
| 比喩 | 上司への報告書の書き方 | 会議資料の準備 | プロジェクト全体の運営体制 |
| スコープ | 1回のAPI呼び出し | 1つのコンテキストウィンドウ | 複数コンテキストウィンドウ/セッション |
| 主な成果物 | プロンプトテンプレート | RAGパイプライン、Few-shot設計 | 進捗ファイル、フィーチャーリスト、CI設計 |
2-2. パラダイムの進化を時系列で見る
①プロンプトエンジニアリング（2022年〜）
GPT-3/ChatGPTの登場とともに、「どう指示すれば良い回答が得られるか」に焦点が当たりました。Chain of Thought、Few-shot、Tree of Thoughtなどの技法が研究されました。しかし、多くの人が「プロンプトエンジニアリング」を「チャットボットへの入力の工夫」と解釈してしまい、本来の技術的な深さが伝わりにくい問題がありました。
②コンテキストエンジニアリング（2025年前半〜）
ShopifyのCEO Tobi Lutkeが「context engineering」という用語を推奨し、Andrej Karpathyが「+1」と支持したことで広まりました。Karpathyは次のように述べています。
人々はプロンプトを、日常的にLLMに与える短いタスク記述と結びつけます。しかし産業レベルのLLMアプリケーションでは、コンテキストエンジニアリングは、次のステップに必要なちょうど良い情報でコンテキストウィンドウを埋めるという繊細な技術と科学です。
コンテキストエンジニアリングは、RAG、ツール定義、Few-shot例、状態管理など、コンテキストウィンドウに何をどう詰めるかを体系化しました。
③ハーネスエンジニアリング（2025年後半〜）
Claude Code、OpenAI Codex、Kiro CLIなどのAIコーディングエージェントが本格普及するなかで、1つのコンテキストウィンドウ内の最適化だけでは不十分であることが明らかになりました。エージェントが何時間、何日にもわたって作業を続ける場合、セッション間の引き継ぎ、進捗追跡、品質維持の仕組みが必要です。これがハーネスエンジニアリングです。
3. なぜ今ハーネスエンジニアリングが必要なのか
3-1. エージェントの能力と課題のギャップ
2025年後半の時点で、AIコーディングエージェントは以下の能力を持っています。
| 能力 | 状況 |
|---|---|
| コード生成 | フロンティアモデルはSWE-bench Verifiedで高スコアを記録 |
| ツール使用 | ファイル操作、シェル実行、Web検索、ブラウザ操作など |
| 自律的な計画と実行 | タスク分解、順序立てた実装、テスト実行 |
| 長時間作業 | コンテキストウィンドウのコンパクション機能 |
しかし、実際に長時間稼働させると以下の問題が発生します。
①One-shot問題: エージェントが一度にすべてを実装しようとし、コンテキストの途中で機能が半完成のまま止まる
②早期完了宣言: いくつかの機能が動いた段階で「完了」と判断し、残りのタスクを放置する
③コンテキスト喪失: コンパクション（コンテキスト要約）後に、前のセッションで何をしたか正確に把握できず、既に動いているコードを壊す
④テスト不足: コード変更後にcurlやユニットテストは行うが、エンドツーエンドでの検証をしない
⑤技術的負債の増幅: 一度導入された不適切なパターンを「正規のやり方」として学習し、コードベース全体に拡散する
3-2. ハーネスがないとどうなるか
Anthropicの技術ブログでは、ハーネスなしでClaude Agent SDKを長時間稼働させた場合の失敗パターンが2つ報告されています。
失敗パターン1: 一気にすべてを実装しようとする
高レベルのプロンプト（例: 「claude.aiのクローンを作って」）を与えると、エージェントはアプリ全体を一度に構築しようとします。コンテキストの途中で実装が止まり、次のセッションのエージェントは半分しか完成していないコードの状態を推測しなければなりません。
失敗パターン2: 途中で「完了」と宣言する
プロジェクトの後半、いくつかの機能が動いている状態で、新しいエージェントインスタンスが周囲を見回し、進捗があることを確認し、「ジョブ完了」と宣言してしまいます。
ハーネスエンジニアリングは「AIを信頼しないこと」ではない
ハーネスは制約ではなく、支援構造です。優秀な人間のエンジニアもまた、gitのブランチ戦略、CIパイプライン、コードレビューといった「ハーネス」の中で最高のパフォーマンスを発揮します。AIエージェントにも同じことが当てはまります。
4. ハーネスエンジニアリングの5つの柱
Anthropicのエンジニアリングブログと実践者のフィードバックから、ハーネスエンジニアリングの5つの柱が浮かび上がります。
4-1. 環境の初期化（Initializer Agent）
最初のセッションで、プロジェクト全体の骨格を構築する専用エージェントを動かします。
| 成果物 | 目的 |
|---|---|
| フィーチャーリスト（JSON） | 実装すべき機能を構造化リストとして定義。各機能にはテスト手順と合否フラグを含む |
| init.shスクリプト | 開発サーバーの起動手順を文書化。毎セッションの環境復元に使用 |
| 進捗ファイル（claude-progress.txt） | エージェントの作業履歴を時系列で記録 |
| 初期gitコミット | 追加されたファイルを記録し、変更の起点を明確化 |
フィーチャーリストはMarkdownではなくJSONで管理する
Anthropicの実験では、Markdownファイルはエージェントが不適切に書き換えてしまう頻度が高いことがわかりました。JSONファイルは構造的であるため、エージェントによる意図しない変更が起こりにくいとされています。
フィーチャーリストの例:
{
"category": "functional",
"description": "新規チャットボタンで新しい会話を作成できる",
"steps": [
"メインインターフェースに移動する",
"「新規チャット」ボタンをクリックする",
"新しい会話が作成されることを確認する",
"チャットエリアにウェルカム状態が表示されることを確認する",
"サイドバーに会話が表示されることを確認する"
],
"passes": false
}
4-2. インクリメンタル進捗（Incremental Progress）
1セッション1機能。 これがハーネスエンジニアリングの核心ルールです。
エージェントは各セッションで以下のサイクルを繰り返します。
①進捗ファイルとgitログを読み、現在の状態を把握する
②フィーチャーリストから次に取り組むべき機能を1つ選ぶ
③ init.shを実行して開発サーバーを起動し、基本動作を確認する
④選んだ機能を実装する
⑤エンドツーエンドでテストし、合格した場合のみフィーチャーリストの passes を true に更新する
⑥gitコミットし、進捗ファイルに作業内容を記録する
⑦次のセッションのために環境を「クリーン状態」にする
「クリーン状態」とは何か
mainブランチにマージして問題ないレベルの状態を指します。重大なバグがない、コードが整理されている、ドキュメントが更新されている、そして開発者が新機能にすぐ取りかかれる状態です。
4-3. フィードバックループ（4層のフィードバック）
AIエージェントが自分のミスを素早く検知し修正するためには、複数層のフィードバックが必要です。
| 層 | 検出対象 | レイテンシ | 例 |
|---|---|---|---|
| 第1層: コンパイル | 構文エラー・型エラー | 数秒 | Go/TypeScriptのホットリロード |
| 第2層: ユニットテスト | ロジックエラー・リグレッション | 数分 | pytest、Jest |
| 第3層: E2Eテスト | 統合エラー・UI不整合 | 数分〜数十分 | Playwright、Puppeteer MCP |
| 第4層: CI/CD | クロスプラットフォーム問題・全体整合性 | 数十分 | GitHub Actions |
この4層は、レイテンシは段階的に増加しますが、検出範囲も段階的に広がります。1行の変更は第1層で即座に検証され、モジュール間のリファクタリングは第4層で総合的に検証されます。
強い型付け言語はエージェントの品質ゲートになる。 Go + TypeScript + Protocol Buffersのような強い型システムは、エージェントのミスをランタイムではなくコンパイル時に捕捉します。弱い型付け言語では、同じエラーがサイレントにランタイムまで入り込む可能性があります。
4-4. コードベースそのものがコンテキスト
外部のRAGシステムや追加メモリファイルを構築するのではなく、コードベース自体を高品質なコンテキストとして設計するという考え方です。
①ディレクトリ構造がドキュメントである: backend/internal/domain/loop/（データ構造） → backend/internal/service/loop/（ビジネスロジック） → web/src/components/loops/（フロントエンド）というように、製品概念からコードパスへの直接的なマッピングを設計する
②命名規則の統一: フロントエンドとバックエンドで同じ概念に同じ名前を使う。エージェントはコードベース全体を探索しなくても、ディレクトリ名から適切な場所を推測できる
③クリーンアーキテクチャの強制: DDD（ドメイン駆動設計）のレイヤー分け ── ドメイン層、サービス層、ハンドラー層 ── がエージェントに「どこに何を書くべきか」を伝える
④リポジトリがコンテキストそのもの: 別途RAGを構築する必要はなく、コードベース自体を高品質に保つことがコンテキストの質を上げる最善の方法
4-5. 技術的負債の制御
AIエージェントは技術的負債を指数関数的に増幅する。 これがハーネスエンジニアリングの最も直観に反する発見です。
人間のエンジニアは、コード中の「地雷」を見つけたとき「これは踏まないように迂回しよう」と判断します。しかしエージェントは違います。コードベース中にあるパターンを「正当なアプローチ」として学習し、次に同様の機能を生成するとき、そのパターンを体系的に再利用します。
| 状況 | 人間の対応 | エージェントの対応 |
|---|---|---|
| サービス層をバイパスしてDBに直接クエリするコード | 「一時的な回避策」と理解し、新規コードでは避ける | 「コードベース内の正当なパターン」として新規コードでも採用する |
| ハードコードされたマジックナンバー | 将来リファクタリングが必要と認識する | 別のファイルにも同じマジックナンバーを複製する |
| 不適切な命名 | 文脈から意図を推測する | 不適切な命名を新規コードにも適用する |
対策は明確です。定期的にリファクタリング専用セッションを設ける。 新機能の実装を止め、技術的負債の清掃だけを行います。良いパターンがコードベースの大部分を占めれば、エージェントは良いパターンを増幅します。
逆もまた真なり: 良いパターンも増幅される
技術的負債の増幅はリスクですが、裏を返せば、コードベースに良いパターンを意図的に配置すれば、エージェントはそれを増幅して適用します。これは投資戦略として活用できます。共有プリアンブルファイルやベースクラスを整備すれば、その改善がコードベース全体に波及します。
5. 実践: エージェントハーネスの構築
5-1. 2エージェント構成
Anthropicが提案し検証した基本構成は、イニシャライザーエージェントとコーディングエージェントの2つで構成されます。
| エージェント | 役割 | 実行タイミング |
|---|---|---|
| イニシャライザーエージェント | 環境構築、フィーチャーリスト作成、init.sh生成、初期コミット | プロジェクト開始時の1回のみ |
| コーディングエージェント | 1機能ずつインクリメンタルに実装、テスト、コミット、進捗更新 | 以降すべてのセッション |
両者の違いは初回のユーザープロンプトだけです。システムプロンプト、ツールセット、ハーネスの構造自体は同一です。
5-2. コーディングエージェントの典型的なセッション
各セッションは以下のステップで始まります。
[Assistant] 作業ディレクトリとプロジェクトの状態を確認します。
[Tool Use] <bash - pwd>
[Tool Use] <read - claude-progress.txt>
[Tool Use] <read - feature_list.json>
[Assistant] 直近のgitログを確認します。
[Tool Use] <bash - git log --oneline -20>
[Assistant] 開発サーバーを起動し、基本動作を検証します。
<init.shを実行>
[Assistant] 基本機能が正常に動作していることを確認しました。
次に実装する機能を選定します。
<フィーチャーリストから未完了の最優先機能を選択>
<実装開始>
このパターンにより、各セッションは常に「現状の正確な把握」から始まり、過去のセッションの記憶がなくても適切に作業を継続できます。
5-3. 3つのプリミティブ
大規模なエージェント協働開発では、3つのプリミティブが基盤となります。
①分離（Isolation）
各エージェントは独立したワークスペースを持ちます。git worktreeとサンドボックスにより、並列作業時のコンフリクトを構造的に排除します。
②分解（Decomposition）
「このコードベースを改善して」ではなく、「このスコープを担当し、受け入れ基準はこれで、完了の定義はこれ」と明確にタスクを分解します。所有権がエージェントの推論の質を変えます。
③協調（Coordination）
エージェントには人間のような「フロントエンドエンジニア」「バックエンドエンジニア」といった役割分担は不要です。同じエージェントがコード作成、ドキュメント生成、PRレビュー、他エージェントのオーケストレーションを行えます。必要なのはコミュニケーションと権限の設定であり、職種ではありません。
6. 失敗パターンと対策
Anthropicの実験で特定された失敗パターンと、ハーネスによる対策をまとめます。
| 失敗パターン | イニシャライザーエージェントの対策 | コーディングエージェントの対策 |
|---|---|---|
| プロジェクト全体を早期に完了宣言する | 入力仕様に基づき、構造化されたJSONフィーチャーリストを作成する | セッション開始時にフィーチャーリストを読み、未完了の1機能を選んで作業する |
| 環境をバグや未ドキュメントの状態で放置する | 初期gitリポジトリと進捗ノートファイルを作成する | セッション開始時に進捗ノートとgitログを読み、開発サーバーで基本テストを実行する。セッション終了時にgitコミットと進捗更新を行う |
| 機能を未検証のまま完了とマークする | フィーチャーリストを作成する | すべての機能を自己検証し、慎重にテストした後にのみ passes を true にする |
| アプリの実行方法の把握に時間を浪費する | init.shスクリプトを作成する | セッション開始時にinit.shを読む |
7. 各ツールにおけるハーネスの実装
7-1. Claude Code
Claude Codeは、ハーネスエンジニアリングと最も親和性の高いツールです。
| ハーネス要素 | Claude Codeでの実装 |
|---|---|
| 進捗管理 | CLAUDE.mdファイルにプロジェクトルールと進捗を記録 |
| セッション間引き継ぎ |
/compact でコンテキスト圧縮。Hooksでセッション開始/終了時の自動処理 |
| フィーチャーリスト | JSONファイルで管理し、CLAUDE.mdから参照 |
| テスト自動化 | シェルツールでテスト実行、Puppeteer MCPでE2Eテスト |
| 並列作業 | git worktree + 複数ターミナルで並列エージェント |
| エージェントオーケストレーション | サブエージェント機能でタスクを委譲 |
Claude Agent SDKを使って独自のハーネスを構築することも可能です。Anthropicのquickstartリポジトリには、autonomous-codingの実装例が公開されています。
7-2. OpenAI Codex
OpenAIもハーネスエンジニアリングの概念と関連した実践を行っています。Redditの開発者PalasCat1994は、「OpenAIは最近、AIエージェントを使って5か月で100万行以上のコードを生成した方法を説明した。彼らはこの手法をHarness Engineeringと呼んでいる」と報告しています。エージェントに構造化された環境を提供し、安定的に成果を出し続ける手法は、ツールを問わず共通の課題です。
7-3. Kiro CLI
AWSのKiro CLIは、ハーネスエンジニアリングの複数要素をネイティブ機能として備えています。
| ハーネス要素 | Kiro CLIでの実装 |
|---|---|
| エージェント制御 | カスタムエージェント（JSON設定）でツール・権限・コンテキストを定義 |
| ルール管理 | ステアリングファイル（.kiro/steering/）でプロジェクト規約を伝達 |
| セッション管理 |
/compact、/save、/load でセッション状態を管理 |
| 品質ゲート | 粒度別ツール信頼でシェルコマンドの実行を段階的に制御 |
| 並列処理 |
use_subagent ビルトインツールで最大4つの並列サブエージェント |
7-4. 汎用構成（ツール非依存）
特定のツールに依存しないハーネスの構成例です。
project-root/
feature_list.json # 機能リストと合否フラグ
progress.md # セッション間の進捗メモ
init.sh # 環境初期化スクリプト
.github/
workflows/
ci.yml # CIパイプライン
tests/
unit/ # ユニットテスト
e2e/ # E2Eテスト
docs/
architecture.md # アーキテクチャ決定記録
8. コンテキストエンジニアリングとの関係
8-1. 排他的ではなく、包含的
ハーネスエンジニアリングはコンテキストエンジニアリングを置き換えるのではなく、包含します。
プロンプトエンジニアリング（1回のAPI呼び出し）
└─ コンテキストエンジニアリング（1つのコンテキストウィンドウ）
└─ ハーネスエンジニアリング（複数のコンテキストウィンドウ/セッション）
コンテキストエンジニアリングの技法 ── RAG、Few-shot、ツール定義の最適化 ── は、ハーネスの中で各セッションの品質を最大化するために引き続き重要です。ハーネスエンジニアリングは、それに加えてセッション間の一貫性と長期的な品質維持を設計します。
8-2. Andrej Karpathy の提言との整合性
Karpathyがコンテキストエンジニアリングについて述べた以下の言葉は、ハーネスエンジニアリングにもそのまま当てはまります。
これを正しく行うには、タスク記述と説明、Few-shot例、RAG、関連する（マルチモーダルな）データ、ツール、状態と履歴、圧縮が必要です。これを上手く行うことは非常に非自明です。
ハーネスエンジニアリングは、この「状態と履歴」と「圧縮」の部分を、エージェントの長時間稼働に特化して深掘りしたものと位置づけられます。
8-3. Drew Breunigの観点
「コンテキストエンジニアリング」という用語の重要性を論じたDrew Breunigは、LangChain主催のイベントでの講演で、なぜ用語が重要なのかを次のように説明しています。
成功するバズワードは無から生まれるのではありません。私たち全員が持ち、共感できる共通の経験を特定するのです。その経験に名前を与えることで、アイデアや経験が結晶化し、コミュニティのものになります。
ハーネスエンジニアリングもまた、同じパターンです。多くの開発者が「エージェントを長時間安定して動かすにはどうすれば」と試行錯誤してきた経験が、この用語によって結晶化しつつあります。
9. 実例: 350Kラインを52日で構築した開発者の教訓
Redditのr/ClaudeAIで、ある開発者が52日間で356KラインのプロダクションコードをAIエージェントと共に構築した経験を共有しています（600コミット、約965Kラインのコードスループット）。この実例は、ハーネスエンジニアリングの原則が実際のプロジェクトでどう機能するかを示しています。
9-1. 主要な教訓
①コードベースがエージェントのコンテキストであり、プロンプトではない: 厳格なDDDレイヤリング（22のドメインモジュール）により、エージェントは「どこに何を書くべきか」を自律的に判断できた
②技術的負債は指数関数的に増幅される: 一時的な回避策がエージェントに「正規パターン」として学習され、コードベース全体に拡散した。定期的なリファクタリング専用セッションが必須だった
③4層のフィードバックが必要: コンパイル → ユニットテスト（700以上） → E2Eテスト → CIパイプラインの4層が、エージェントに素早いフィードバックを返した
④認知帯域幅は実際の制約: 3つの並列ワークツリーが1人の人間の判断力の上限だった。4つ目を追加すると意思決定の品質が目に見えて低下した（約50,000行/日が上限）
⑤実験コストが崩壊したら、方法論も進化すべき: あるアーキテクチャは設計段階ではなく、3つの並列エージェント環境がバックエンドをダウンさせた実運用の失敗から生まれた。発見から修正まで2日。従来のチームなら2週間のアーキテクチャ討議が必要だった
9-2. 別の開発者の補足: 手順書 > 原則
同スレッドの別の開発者（200KラインのコードベースをClaude Codeで構築）は、異なるアプローチを報告しています。
あなた（元投稿者）はエージェントをコードジェネレーターとして扱い、良いコンテキストを必要としています。私たちはエージェントをプロセスエグゼキューターとして扱い、良い手順書を必要としています。
この開発者は250行の手順書を作成し、エージェントの反復ループ ── ログ読み取り → 評価実行 → サマリー読み取り → 上位推奨の選択 → 修正 → テスト → コミット → ログ更新 ── をスクリプト化しました。結果、あるツールの精度が0.5から0.96に向上したと報告されています。
10. おわりに
ハーネスエンジニアリングは、革命的に新しい概念ではありません。
振り返れば、ソフトウェア開発はこれまでも「強力な力を構造的に管理する」歴史の連続でした。手動テストからテストハーネスへ、手動デプロイからCI/CDへ、monolithからマイクロサービスへ。その都度、私たちは力を解放するための制御構造を設計してきました。
ハーネスエンジニアリングは、その最新の章です。
AIエージェントがコードを書く時代において、ソフトウェアエンジニアに求められるスキルは変わりつつあります。コードを書く能力から、エージェントが安定して良いコードを書き続ける環境を設計する能力へ。それは、アーキテクチャ設計、テスト設計、CI/CD設計、そしてコードベースそのものの品質管理 ── 従来のソフトウェアエンジニアリングの真髄だったスキルが、新しい文脈で再評価される動きでもあります。
最後に、あるRedditの開発者の言葉を引用します。
ハーネスエンジニアリングの投資先は、従来のソフトウェアエンジニアリングと同じです。明確なコードを書くこと、良いアーキテクチャを維持すること、技術的負債を適時に清掃すること。唯一の違いは目的です。以前はそれを人間のエンジニアのために行っていましたが、今はAIエージェントが信頼性高く動作するためにも行うのです。
ではまた、お会いしましょう
参考リンク
- Anthropic - Effective harnesses for long-running agents (2025年11月)
- Anthropic - Building effective agents (2024年12月)
- Anthropic - Claude Agent SDK quickstart: autonomous-coding
- Simon Willison - Context Engineering (2025年6月)
- Drew Breunig - Why "Context Engineering" Matters (2025年7月)
- Reddit r/ClaudeAI - 350K-Line Codebase in 52 Days (Harness Engineering Lessons)
- Reddit r/ClaudeAI - Autonomous harness for Claude Code (Context Engine)