AIエージェント開発の現状とAgentic Coding

AnthropicのClaude CodeやOpenAIのCodexのような開発用のAIエージェント（コーディングエージェント）は、一度のセッションで数百行、ときには数千行の差分を出力します。一方で、人間がコードを読む速度はほとんど変わっていません。これまで、「⁠コードを全部読んで理解する」という行動は、ソフトウェア開発、そして生成AIを使った開発における当たり前の習慣でした。しかし、生成される量だけが一方的に増え続けた結果、この前提は成り立たなくなりつつあります。

生成量が人間の確認能力を超えたとき、コードの品質をどのように担保すべきなのでしょうか。その答えの1つが、本特集の主題であるハーネス（harness）です。本章では、ハーネスエンジニアリングがどのような開発手法なのかについて解説していきます。

Agentic Codingとは何か

まずは、コーディングエージェントがソフトウェア開発をどう変えてきたかを振り返りましょう。LLMの登場からしばらくは、ChatGPTのようなチャット形式での対話や、実装案を行単位で提示する「コード補完」のように、AIはあくまで人間の作業を補助する役割にとどまっていました。

転機となったのは、2025年2月にOpenAIの創設メンバーであるAndrej Karpathy氏が提唱したVibe Codingという概念です[1]。これは、人間は意図（What）を自然言語で伝えるのみで、実現方法（How）はAIエージェントに完全に委ねるという開発の進め方を指します。生成されたコードを読まずに受け入れる点で、それまでのAIによる開発支援とは一線を画すものでした。

ただし、この「コードを読まずに受け入れる」という前提は当初から問題視されていました。2025年前半時点のLLMは、一通りの実装を自律的に進められはするものの、質の高い生成物を得るためには、実際には人間が動作を見守り、随時介入する必要があったためです。生成物を楽観的に信用する危うさから、Vibe Codingはしばしばアンチパターンとして語られてきました。

Vibe Codingの広まりと前後して登場したスタイルがAgentic Codingです。Agentic Codingでは、AIエージェントの自律性を尊重しつつ、テストやレビューといった従来のソフトウェア開発の規範に則って開発を進めます。用語としても早い段階から使われており、2025年5月ごろには論文やエンジニアコミュニティで用いられ始めていました[2]。

Agentic Codingでは、AIエージェントの自律性を尊重しつつ、テストやレビューといった従来のソフトウェア開発の規範に則って開発を進めます[3]。また、エージェントが計画・実装・テスト・修正のループを自律的に反復し、タスクを遂行していく点も特徴です。具体的な実践方法は多岐にわたりますが、いずれもエンジニアがチームで品質を保つために積み上げてきた作法を、エージェントにも守らせるためのナレッジだと言えます。

ただし、LLM自体の限界は変わらず、生成物が実用水準に達しないという課題は両者に共通していました。Agentic Codingではこれを、テストやリンターによる機械的な検証と、生成物を人間が毎回評価して受け入れるかを判断することによってカバーしていました。生成結果をそのまま受け入れるVibe Codingとは、この点で対照的です。整理すると表1のとおりです。

LLMの自走性能の急激な向上

前述のように、当時のAgentic Codingの運用は「エージェントは自律的に動き、生成物は人が評価して受け入れる」という前提に立っていました。この前提を揺るがしたのが、2025年後半からのLLMのコーディング性能の急激な向上です。

象徴的なのがコーディングベンチマークの数字です。実際のGitHubリポジトリの課題をエージェントに解かせるSWE-bench Verifiedでは、Anthropicのモデルの最高スコアが2024年10月時点の49％から2025年11月には80％に達しています[4]。AI分野の情報発信で知られるSimon Willison氏は、2025年11月から12月に登場したOpus 4.5とGPT-5.2について、「⁠LLMが突如として高いコーディング性能を獲得した転換点」だと述べています[5]。

ここで重要なのが、コーディング性能の向上により、AIエージェントの「自走性能」が高まったという点です。コーディングや端末操作の性能が向上したことにより、エージェントはゴールを与えられただけで、長時間タスクを進め続けられるようになりました。それまでは数十分単位しか続かなかったAgentic Codingの自律ループが、数時間から数日にわたる自走へと進化したのです。Andrej Karpathy氏も、2025年12月を境に、長時間タスクにおける一貫性や粘り強さが大きく向上したと述べています[6]。

コードを読まないAgentic Codingに必要なもの

自走が数時間に及ぶと、生成物の量も飛躍的に増え、「⁠生成物はすべて人が読んでから受け入れる」というルールは維持できなくなります。むしろ、コードを逐一読まずに意図とゴールだけを伝え、プロセスに細かく介入しないほうが、スループットの観点では合理的です。実際、同じプロンプトをスクリプトで繰り返し流すRalph Wiggum Loop[7]や、達成条件を満たすまで作業を続けさせるClaude Codeの/goalコマンドのように、開発の過程をすべてエージェントに委ねる手法はすでに広く定着しており、こうした工夫は「ループエンジニアリング」とも呼ばれ始めています[8]。

しかし、構図だけを見れば、これはアンチパターンとされていた旧来のVibe Codingの姿そのものです。Vibe CodingとAgentic Codingの線引きを唱えてきたSimon Willison氏自身も2026年5月、両者の距離が縮まっていると認めています[9]。

では、両者を分けるものは何でしょうか。前述の表1のとおり、Agentic Codingでは人がコードを読む代わりに、テストやリンターなどによる機械的な評価を行い、開発が収束した後の最終的な受け入れのみを人が判断します。このようにエージェントの行動を評価し、制御する一連のしくみこそが、現在ハーネスと呼ばれているものです。

しかし、仕様や設計、影響範囲の大きい変更など、AIエージェントだけでは適切に判断しきれない開発領域は依然として存在します。エンジニアが担ってきた評価や制御のうち、任せられるものから順に、しくみへオフロードしていくアプローチがハーネスエンジニアリングです。

ハーネスエンジニアリングとは

ハーネスという言葉の定義

AIエージェント関連のドキュメントには、「⁠エージェントハーネス」「⁠ハーネスエンジニアリング」といった形で、ハーネスという言葉がよく出てきます。ハーネス（harness）はもともと馬具を指す言葉で、工学の世界でもワイヤーハーネスやテストハーネスという用語が定着していますが、いずれもAIエージェントの文脈で指すものとは異なります。

AIエージェントにおける「ハーネス」はバズワード化している節があり、話し手によって言葉の指す範囲が異なります。そこで本章では、まず主要な論者がこの言葉をどう使っているかを順に眺め、そこから共通の整理軸を取り出すことにします[10]。

論者ごとのハーネス

最初は、エージェント開発フレームワークを提供するLangChainです。同社のハーネスの定義は「Agent＝Model＋Harness」という式で表されます[11]。モデルを制御して、AIエージェントとして動作させる「モデル以外の実装」の総体をハーネスと呼ぶ立場です。実際に同社が公開するエージェント実装では、モデルを固定したまま、ハーネス側の改善だけで端末操作の遂行能力を測るTerminal-Bench 2.0のスコアを13.7ポイント引き上げたと報告しています[12]。モデルが同じでもハーネスが性能を決める、というわけです。

Claude Codeを提供するAnthropicも、同じ視点からハーネスを「モデルを取り巻くソフトウェアの足場（scaffolding⁠）⁠」と定義しています[13]。特徴的なのは、長時間動き続けるエージェントを支える文脈で語られることです。ステートレスなLLMにセッションをまたいで作業を引き継がせるため、セットアップスクリプトや進捗ファイル、Git履歴、自動テストを、前のセッションから次のセッションへのバトンを受け渡すかのようにリポジトリへ残していきます。

一方、異なる視点を示すのが、ThoughtworksのBirgitta Böckeler氏がMartin Fowler氏のサイトに寄稿した記事です[14]。Böckeler氏はこの記事で、あいまいに扱われていたハーネスという用語の定義を整理するため、「⁠エージェントに組み込まれたハーネス（内部ハーネス⁠）⁠」と「ユーザーが構築する外部ハーネス（ユーザーハーネス⁠）⁠」を区別することを提案しました。この2種類のハーネスは並列の関係ではなく、モデルを核として外側へ順に重なる入れ子の関係にあります（図1）。このうち外部ハーネスとは、コーディングエージェントの利用者が、生成の前に与える情報（フィードフォワード）と、生成物への評価として返す情報（フィードバック）のループとして構成する環境だと述べています。エージェントの中身には手を入れず、その外側に環境を積み上げることで品質を高めていきます。

HashiCorpの共同創業者Mitchell Hashimoto氏も、同じく利用者の立場からハーネスエンジニアリングを語っています[15]。同氏のAI導入記に書かれているのは、エージェントがミスをしたら、同じミスを二度と繰り返さないようにリポジトリ側のしくみを足していく、というシンプルな指針です。

OpenAIも、ハーネスエンジニアリングと題した利用者向けの記事を公開しています[16]。「⁠生成されたコードが人間のスタイルの好みに合致しなくても、正しく保守可能で、将来のエージェントが読み取れるなら基準を満たす」という割り切りを示し、エージェントを働かせ続けるための環境整備に主眼を置いています。

内部ハーネスと外部ハーネス

こうして並べると、同じ「ハーネス」でも、指す範囲が2通りに分かれていることがわかります。LangChainとAnthropicが語るのはエージェントの作り手のためのハーネスであり、Birgitta Böckeler氏やMitchell Hashimoto氏、OpenAIが語るのは使い手のためのハーネスです。同じ言葉が、話し手のポジションによって異なるスコープのまま使われています。

この2つを見分けるため、本章ではBirgitta Böckeler氏の示した区分をふまえ、前者を内部ハーネス、後者を外部ハーネスと呼び分けます[17]（表2）。

内部ハーネスは、AIエージェントの作り手のための層です。Claude CodeやCodexで言えば、モデルそのものを除いた内部実装、つまりツール定義やコンテキスト管理、ループ制御などがこれにあたります。エージェントを自作する場合も、Claude Agent SDKやClaude Managed Agentsのように、ベンダーがハーネスをSDKやマネージドサービスとして公開しているため、作り手はエージェントの定義を渡すだけで済みます。

もう一方の外部ハーネスは、エージェントの使い手のための層です。AGENTS.mdやCLAUDE.mdといったルールファイルやエージェントスキル（以下スキル⁠）⁠、テスト、CI/CD、権限設定といった、構築済みのエージェントを外側から制御するしくみの総体を指します。内部ハーネスの上にもう1枚かぶせる形になるので、いわば「ハーネス上のハーネス」です。

「それは普段の開発環境と何が違うのか」と思った方もいるでしょう。実際、外部ハーネスで紹介する道具に目新しさはありません。テストもCI/CDも権限設定も、AIエージェント以前から使われてきましたし、ルールファイル、スキル、Hooksも、Agentic Codingの実践の中で整備されてきたものです。エージェント製品を導入しただけでは付いてこない、利用者側で管理するしくみ全般が外部ハーネスです。

本特集で扱うのはどちらか

エンジニアが一般的なシステム開発にエージェントを導入する際、内部ハーネスはほとんどの場合、作り込む対象ではありません。コーディングエージェントという完成済みプロダクトの一部であり、どう設計されていて、どう使えばよいかを理解すれば十分だからです。

エージェントの利用者が育てるべきなのは、外部ハーネスです。こちらは概念を理解するだけでは足りず、必要な形もプロジェクトごとに異なるため、チームごとに最適化していくしかありません。本特集では、この外部ハーネスを設計・構築し、エージェントが効率的に動作できるように改善していく一連の営みを「ハーネスエンジニアリング」と呼びます。以降、単に「ハーネス」と表記した場合は、外部ハーネスを指します。

AIエージェント向けのハーネス環境構築

では、外部ハーネスは具体的にどのような要素で構成されるのでしょうか。チームが積み上げてきた開発基盤を、エージェント向けに整え直すのが基本です。

ハーネスを構成する設定／機能

外部ハーネスを構成する道具は、エージェントに判断材料と観測手段を与えるためのものです（表3）。それぞれの詳細は後続の章で扱うため、ここでは「どんな役割の道具があるのか」だけを押さえます。

AGENTS.mdやCLAUDE.mdなどのルールファイルとスキルは、プロジェクト固有の前提や手順をエージェントに伝えるためのものです。ビルドやテストのコマンド、コーディング規約、触ってほしくない領域といった、それまでチームの暗黙知だったものをリポジトリ上に明文化します。

リンターやテストは、生成された変更が基準を満たしているかを、エージェント自身が確認するための観測手段になります。テストのないリポジトリでエージェントが迷走しがちなのは、モデルの能力以前に、検査結果のフィードバックがないからです。これらを開発工程のどこで実行し、失敗をどう修正へつなげるかは第2章で整理します。

Hooksは、エージェントがツールを使う直前や直後に、定義済みの処理を割り込ませるしくみです。危険な操作の検査や、編集後の自動整形などに使えます。MCPは、ローカルのツールや外部サービスをエージェントと接続するための共通規格です[18]。また、エージェントの権限やサンドボックスを事前に設定しておくと、実行できる操作と、失敗したときの影響範囲を限定できます。

これらの道具は性質が一様ではありません。ルールファイルやスキルはあくまでAIエージェントへの指示であるため、守られる保証がなく、無視されることがあります。一方、リンターやテストは同じ入力に必ず同じ判定を返します。何を「お願い」にとどめ、何を機械的な判定へ移すかという切り分けは、ハーネスエンジニアリングの重要なポイントです。

ハーネスエンジニアリングでできるようになること

では、ハーネスエンジニアリングの導入で何が変わるのでしょうか。4つの観点で見ていきましょう。

生成量が増えても確認対象を絞れる

1つ目は、確認すべき対象を絞れることです。冒頭の説明のとおり、エージェントが生成する速度は、人間がコードを読む速度をすでに超えています。リンターで判定できる書式、型検査で見つかる不整合、既存のテストで検出できるデグレードはエージェントと外部ハーネスに任せ、人間は仕様や設計、影響範囲の大きい変更など、機械だけでは判断しにくい部分に集中できます。

人が付きっきりでなくても作業を続けさせられる

2つ目は、自走力の強化です。利用者に「これで合っていますか」と確認を求める代わりに、生成物に対する確認基準をハーネスの形で与えれば、エージェントは自己チェックと修正のループを自ら回せるようになり、承認待ちの回数が減るぶんだけ自走力が強化されます。

ただし、エージェントが長時間の自走を実現できても、人間側がそれを許可できるかは別の問題です。生成のスループットとは別に「承認なしで任せて本当に大丈夫なのか」という不安を払拭しなければなりません。そのための備えをハーネスとして設計します。ロボット掃除機を走らせる前に部屋を整頓しておくのと同じで、Hooksで危険なツール実行に介入できるようにし、OSやマシンレベルで動作環境を分離しておくことで、人が席を離れている間も安心して作業を任せられます。

失敗を次のしくみに変えられる

3つ目は、一度起きた失敗をフィードバックしてしくみに変えられることです。同じ修正を何度も指示するようであれば、その失敗を次回から自動で検出できるしくみをハーネスに追加すれば、同じ失敗を繰り返さずに済みます。

失敗をもとに見直す設定の場所は、たとえば次のように失敗の種類によって決まります。

• プロジェクトの前提を把握できていないミスなら、参照情報やルールファイルを見直す
• 誤った変更を成功と判断したなら、テストや検査の基準を見直す
• 危険な操作を実行しようとしたなら、権限や実行前の検査を見直す
• 環境の外まで変更が及んだなら、コンテナやサンドボックスを見直す

ちなみに、同じ規約をルールファイルやスキルへ書き足しても違反が改善しない場合、確率的な「お願い」で守らせる限界を超えている可能性が高いです。決定論的なしくみであるリンターやHooksでの検査へのオフロードを検討し、機械的に判定させましょう。

チームの基準をエージェントにも共有できる

4つ目は、個人の工夫がチームの資産になることです。エージェントへ直接出した指示はセッションが終われば失われますが、ルールファイルやテスト、CI環境、権限設定としてハーネスをリポジトリに残せば、開発メンバーとエージェントの双方が参照でき、属人性やロックインの少ない開発基盤を育てることができます。

これらはいずれも、人がその場で担っていた確認や指示、判断を、プロジェクト側のしくみへ移し替える話です（表4）。

小さく始めるハーネス構築

外部ハーネスは、小さく始めて段階的に育てていくものです。本節ではClaude Codeを例に、どのファイルをどこへ置くかを見ていきます[19]。最初に導入する一式を図2に示します。

your-project/
├─ CLAUDE.md               # プロジェクトの前提と規約
├─ .claude/
│   └─ settings.json      # 権限設定（allow/deny/ask）
├─ .devcontainer/
│   └─ devcontainer.json  # ホスト環境からの分離
├─ .github/
│   └─ workflows/
│       └─ ci.yml         # マージ前の検証
├─ package.json            # ローカルでの検証（npmスクリプト）
├─ eslint.config.js        # 静的検査
└─ tests/                  # ふるまいの検証

最初に、変更の成否を機械的に確かめる検査を導入します。入れるのは、リンターとテスト、そしてマージ前にそれらを実行するCI環境（GitHub Actions）です。

次に実行権限に制約を加えていきます。Dev Containerでホスト環境から分離したうえで、.claude/settings.jsonに許可する操作（allow⁠）⁠、禁止する操作（deny⁠）⁠、都度確認する操作（ask）を宣言します。Claude Code自体にも、コマンド実行をOSレベルで隔離するサンドボックス機能があります。

最後に、プロジェクトの前提を伝えるルールファイルを書きます。Claude Codeはリポジトリ直下のCLAUDE.mdを自動で読み込みます。AGENTS.mdを読むエージェントを併用するプロジェクトでも、CLAUDE.mdに@AGENTS.mdと書けば内容を取り込めます。

運用が始まったら、ミスを観測するたびにハーネスに要素を足していきます。同じ説明を毎回チャットで繰り返していると気づいたら、常に守らせたい規約はルールファイルへ、特定の作業で必要な手順はスキルへ切り出します。.claude/skills/配下のSKILL.mdの本文は呼び出し時にだけ読み込まれるため、コンテキストの肥大化を防げます。

編集後の自動整形や実行前の検査を確実に走らせたいなら、settings.jsonにHooksを定義し、ツール実行の直前（PreToolUse）や、成功した直後（PostToolUse）に処理を割り込ませます。外部サービスへの接続が必要になったら、MCPサーバーを.mcp.jsonへ登録します。ここまで足した状態が図3です。

your-project/
├─ .claude/
│   ├─ settings.json       # Hooksの定義を追記
│   └─ skills/
│       └─ スキル名/
│           └─ SKILL.md    # 呼び出し時だけ読み込む作業手順
└─ .mcp.json                # 外部ツール接続（MCP）

ここに挙げたファイル名や置き場所はClaude Codeでの例ですが、ほかのコーディングエージェントにも同様のしくみがあります。開発工程へどう組み込むかは、次章以降で詳しく見ていきます。

ハーネスエンジニアリングが引き受けない役割

ここまで、ハーネスに期待を持たせる書き方をしてきましたが、ハーネスは銀の弾丸ではありません。リンターやテスト、権限設定をどれだけ厚くしても、エラーやバグは0件、とはいきません。ハーネスを整えた後も人に残る仕事を、見ていきましょう。

判断の基準を引き受ける

ハーネスは、エージェントによるコードの変更を、与えられた基準に基づいて判定します。裏を返すと、与えられていない基準については何も判定できません。たとえば、ECサイトの割引率の上限を30％にするか、40％まで許すかは、プロダクトの収益や販売戦略から導くビジネス上の判断であり、ハーネスの側からは決められません。人間が判断し、明文化した基準を、テストや型に落とし込んで、初めて検査の対象になります。ビジネスが変われば、この判断は何度でもやり直しです。

また、ハーネスの基準を通過したからといって、変更をそのまま採用できるとは限りません。

• そもそもの要求や仕様が、プロダクトの目的に合っているか
• 値や処理が、ドメインの意味に合っているか
• エージェントの実装の裏にある、設計上のトレードオフを受け入れてよいか

といった本質的な観点のレビューは、引き続きエンジニアの仕事です。ハーネスの判定結果を手がかりに、どの変更を重点的に読むかを決めるのも人の役割です。

ハーネス自体を保守する

見落とされがちなのが、ハーネスの保守です。形式だけは残っているものの、実質的な機能を失ったハーネスに、心当たりのある方も多いのではないでしょうか。

• スキップされたまま放置されたテスト
• 実態から大幅に離れたAGENTS.md
• うるさいからと無効化されたリンターのルール
• 仕様変更に追従していないモック

壊れたハーネスは、AIエージェントを誤った仕様へ誘導します。エージェントはテストや検査の結果を作業が成功した根拠として利用するため、その結果が誤っていれば、誤った成功判定のうえに変更を積み重ねていきます。エージェントにとって、誤ったコンテキストは「ないよりマシ」ではなく「ないより厄介」だと覚えておきましょう。

まとめ

本章では、自走性能を活かしたエージェント運用に不可欠な「ハーネス」と「ハーネスエンジニアリング」とは何かを整理し、実際に利用するための考え方をまとめました。