プロローグ ── エージェントは壊れていない、ハーネスが壊れている
シリーズ構成 Ch.1 プロローグ（本章） / Ch.2 出自と提唱の経緯 / Ch.3 概念の整理：三層モデル / Ch.4 議論の変遷 / Ch.5 ベストプラクティス / Ch.6 アンチパターン / Ch.7 エピローグ
何かがおかしい
AIコーディングエージェントを初めて使ったときの体験を思い出してほしい。
驚くほどよく動く。「認証機能を追加して」と言えば、それらしいコードが返ってくる。「このバグを直して」と言えば、数秒で修正案が出てくる。「テストを書いて」と言えば、テストファイルが生成される。最初の数時間は魔法のように感じる。
しかしその魔法は長続きしない。
同じミスを何度も繰り返す。アーキテクチャの決まりを無視して自己流の解法を選ぶ。コンテキストウィンドウが尽きると迷子になる。長時間タスクの後半になると、前半に自分が生成したコードをすでに忘れている。マルチエージェントで並列実行すると、互いの変更が衝突する。そしていつの間にか、エージェントが生成したコードのクリーンアップに人間が費やす時間が、コードを自分で書くよりも長くなっている。
「モデルがまだ弱いせいだ」「もっと良いプロンプトを書けば解決する」と多くの開発者が思った。しかしそれは問題の本質を見誤っている。
2026年、コミュニティが学んだのはこうだ。エージェントは壊れていない。ハーネスが壊れているのだ。
三つの時代
AIを使ったソフトウェア開発には、明確に区分できる三つの時代がある。
timeline
title AI開発の三時代
2022〜2023 : プロンプトエンジニアリング時代
: 「どんな言葉を使えばよい応答が得られるか」
: 単発APIコールの最適化
2024〜2025 : コンテキストエンジニアリング時代
: 「何をモデルに渡すか」
: マルチターン・RAG・メモリ管理
2026〜 : ハーネスエンジニアリング時代
: 「システム全体をどう動かすか」
: 制約・フィードバックループ・環境設計プロンプトエンジニアリングの時代、エンジニアは「呪文」を探していた。「Chain of Thought を使え」「Few-shot を入れろ」「ロールプレイで話しかけろ」。指示の書き方を工夫することで、モデルの出力を改善しようとした。
コンテキストエンジニアリングの時代、問いは「何を送るか」に変わった。RAGで関連ドキュメントを注入し、会話履歴を管理し、ツール呼び出しの結果を適切に構造化する。「モデルが確信を持って答えるための情報を、どう揃えるか」がエンジニアリングの中心になった。
そしてハーネスエンジニアリングの時代、問いはさらに大きくなった。「何をシステムとして防ぎ、測定し、修正するか」。エージェントが自律的に複数ステップを実行し、複数のコンテキストウィンドウにまたがって作業する世界では、情報の渡し方だけでは追いつかない問題が次々と現れる。
この記事が扱うこと
本シリーズはハーネスエンジニアリングという概念を多角的に解説する。
どこから来た概念なのか。誰が定義し、なぜ今この言葉が必要とされているのか（Ch.2）。プロンプトエンジニアリング・コンテキストエンジニアリングとどう違うのか（Ch.3）。コミュニティの議論を経てどう形が定まってきたのか（Ch.4）。実践者たちが「効いた」と報告するパターンは何か（Ch.5）。繰り返し踏まれる失敗パターンは何か（Ch.6）。そしてこの概念がソフトウェアエンジニアリングにとって何を意味するのか（Ch.7）。
対象読者はAIエージェントを使ったことがある、あるいはこれから本番プロジェクトに投入しようとしているエンジニアだ。「とりあえず動く」から「信頼できる」へのギャップを埋めたいと感じている人に向けて書いた。
馬と馬具
「ハーネス（harness）」とは、馬具のことだ。手綱、くら、ビット、胸革。馬という強大な生き物の力を制御し、有用な仕事へと向けるための道具一式を指す。
馬は素晴らしい。速く走れる。重いものを引ける。しかし馬具なしの馬は、その力を制御できない。馬具によって初めて、馬の力は「役に立つ仕事」になる。
AIエージェントも同じだ。LLMは強大だ。コードを書ける。バグを見つけられる。ドキュメントを読める。しかし制約もフィードバックループも持たない野放しのエージェントは、その力を有用な方向に向けられない。ハーネスが、エージェントの能力を「信頼できるソフトウェア開発」に変換する。
この記事は、その「馬具」をどう設計するかについての話だ。
本シリーズは 2026年3月30日時点の情報を元に執筆しています。