ハーネスエンジニアリングの射程とは何か
- 開発現場と組織運営のハーネスエンジニアリング

本記事は、2026年8月27日に開催された「現場を動かすAIエージェント〜製造・リテール・モビリティ各業界の実践〜」での西見公宏の講演をもとに構成しています。

今回は、ハーネスエンジニアリングとは何を指すのかを取り上げます。 その考え方を開発現場や組織運営にどこまで適用できるのかも考えていきます。

私が見ている範囲では、いまハーネスエンジニアリングへの関心が非常に高まっています。 Martin Fowler氏のブログで言及され、The Wall Street Journalでもトークンコストの最適化を巡って話題になりました。 Amazonを見ても関連書がいくつも並んでおり、注目が集まっているのを感じます。

一方で、ハーネスエンジニアリングが具体的に何を指すのかは、少し分かりにくくなっています。 まずは概念を整理し、私たちが社内で取り組んでいる実践をご紹介します。 その実践を踏まえて、開発現場や組織運営にどのような変化をもたらせるのかを考えていきます。

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

ハーネスとは「モデルを取り巻く外部の仕組み」

エージェントにおけるハーネスとは、モデルを取り巻く外部の仕組みのことです。 まずはこの定義を押さえていただければと思います。

ハーネスの最も基本的な部分にあたるのが、エージェントハーネスです。 ソフトウェア開発を行うAIエージェントにとっては、作業対象のコードベースが働く環境になります。 エージェントは、ユーザーからの依頼やファイルの状態といった情報を環境から受け取ります。 AIエージェントの世界では、この情報の受け取りを「知覚」と呼びます。

エージェントに知っておいてほしいことも、受け取った情報に加えます。 CodexのAGENTS.mdやClaude CodeのCLAUDE.mdに書いた指示が、その代表例です。 エージェントがそれまでに実行してきた作業履歴もコンテキストに含まれます。

これらの情報をまとめてLLMに渡し、次に何をすべきかを推論させます。 ファイルを読むか、コードを書き換えるか、あるいはコマンドを実行するかなどを判断します。 エージェントは推論結果に従ってツールを実行し、環境へ実際に働きかけます。 その働きかけによって環境の状態が変わると、新たな情報を受け取って次の処理を考えます。 このループを繰り返すのが、AIエージェントの基本的な動きです。

もちろん、モデル自体の性能は欠かせません。 ただ、モデル単体でこの一連の動作が成り立つわけではありません。 情報を受け取り、コンテキストを組み立てるための外部の仕組みが必要です。 推論の結果を受けてツールを実行する仕組みも必要になります。

つまり、AIエージェントは「モデル＋ハーネス」と捉えられます。

現場で使われているエージェントハーネスには、Claude CodeやCodex、OpenCode、GitHub Copilotなどがあります。 LangChainのDeep Agentsのように、コーディングに特化しないものもあります。

エージェントハーネスとユーザーハーネス

一方、Claude CodeやCodexを使う開発者には、自分たちの仕事をうまく進められるようにエージェントを調整したい、という課題があります。 利用者が、既存のエージェントハーネスの外側に仕組みを用意するアプローチです。 ここでは、これをユーザーハーネスと呼んで区別します。

利用者の間でハーネスエンジニアリングが話題になるときは、ユーザーハーネスの調整を指していることが多いと感じます。 他方、研究論文などではエージェントハーネスそのものの最適化が主に扱われます。 同じ言葉で両方の話が出てくるため、何を調整しようとしているのかを切り分けて捉えると理解しやすくなります。

ユーザーハーネスには、たとえばコンテキストの与え方が含まれます。 プロンプトを一度渡すだけでなく、処理が進む中でそのターンの目的に合った情報を与え、計画の実行を支援します。 そのためによく使われているのが、エージェントスキルです。

また、AGENTS.mdやCLAUDE.mdだけでは、プロジェクトについて伝えたいことをすべて扱いきれません。 関連ドキュメントを必要に応じて参照できるようにし、プロジェクト固有の情報を整理しておきます。 これが、プロジェクトコンテキストを整える取り組みです。

ツールの実行についても、何でも自由に実行させてよいわけではありません。 たとえば、特定の条件では処理を実行させない、といった制御が求められます。 データベースのマイグレーション直後に、決まった別の処理を挟む制御も必要です。 モデルの判断だけに任せず、決定論的に制御を適用するためにフックを活用します。

外部システムとの連携もユーザーハーネスに含まれます。 会計システムに接続するなど、エージェントが使える機能を増やすためにCLIのコマンドやMCPを利用します。 利用者がエージェントの働き方を調整しているという点で、これもユーザーハーネスにあたります。

さらに、その外側には実行環境があります。 確認をすべて省略してローカル環境で動かすと、エージェントがホームディレクトリのファイルを削除してしまう可能性もあります。 そこでDev ContainersやDockerコンテナで実行環境を分けます。 EC2などのクラウド上に環境を用意して、外部ネットワークへのアクセスを制限する方法もあります。 エージェントが活動できる範囲を制約し、安全に使うための環境を用意することもユーザーハーネスの役割です。

コンテキスト、スキル、フック、外部連携、実行環境。 これらを自分たちの仕事に合わせてどう調整するかを考えるのが、使い手にとってのハーネスエンジニアリングです。

最初に、ハーネスはモデルを取り巻く外部の仕組みだとお話ししました。 モデルのすぐ近くには、環境から情報を受け取って推論し、行動するための基本的なループがあります。 その外側には、利用者が業務や安全のための仕組みを加えていきます。 どちらも、モデルを取り巻く外部の仕組みとして捉えることができます。

ループエンジニアリング

より発展した考え方として、ループエンジニアリングがあります。

ユーザーハーネスを整えたエージェントを、ゴールに到達するまでどのように動かすかを考えます。 複数のエージェントを組み合わせたり、セッションを分けたりして、活動の流れを設計する考え方です。

たとえば、実装を担当するエージェントが作業を終えたら、検証を担当するエージェントに渡します。 検証結果を受けてまた実装側に戻す、といった流れです。 あるいは、レビューの観点ごとに担当を分けます。 エージェント単体の動きだけでなく、活動全体をどう組み立てるかを考えます。

ここまでをまとめると、ハーネスエンジニアリングとは「AIエージェントが安定して働ける環境を設計・適用すること」と言えます。

使い手の関心は、長時間のタスクを安全に継続して実行させ、成果物の質を安定させる点にあります。 そのためにユーザーハーネスを調整します。

一方、作り手の関心は、多様なモデルに合わせてエージェントハーネス自体を最適化する点にあります。 トークンのコストを考えると、いつでもフロンティアモデルを使えるとは限りません。 ローカルで動かすオープンウェイトモデルで業務を進められるようにしたい場面もあります。 DeepSeek V4 Flashのようなモデルで、どうすればタスクをこなせるか、といった話です。

そのために、ハーネス自体をどう自動的に最適化するか。 コストを抑えながらタスクの成功率を高めるにはどうすればよいか。 こちらは、エージェントハーネスをつくる側のハーネスエンジニアリングです。

対象は違いますが、AIエージェントが安定して働ける条件を設計するという課題は両者に共通しています。

ジェネラティブエージェンツでの事例

タスクゼロを開発するためのハーネスエンジニアリング

抽象的な説明だけでは分かりにくいため、ここからは私たちの社内での実践をご紹介します。

私たちは、AIエージェントの運用プラットフォームであるタスクゼロを開発しています。 AIエージェントに特化したタスク管理とデータ管理の仕組みを用意し、社内の業務をエージェントに代行してもらうためのものです。

私たちの主力事業は研修事業ですが、その運営には細かな仕事がたくさんあります。 見積もりを何度も更新したり、お客様からの「こういう条件でも対応できますか」という相談に応じたりします。 受講者が急に欠席することもあれば、別の方に入れ替わることもあります。 通常は人が対応するこうした業務を、私たちの会社ではAIエージェントが担当しています。

私たちは、タスクゼロを開発するためのハーネスエンジニアリングを実践しています。 同時に、タスクゼロの中でエージェントが業務を進めるためのエージェントハーネスも独自につくっています。

開発プロセスでは、私たちは毎日Google Meet（現在はZoom）で会話をしています。 タスクゼロがミーティングの書き起こしを読み、私たちが今の設計で何を重要だと考えているのかを整理します。 私たちが何に関心を持っているのかも整理します。

ミーティングから整理した情報を、エージェントが参照できる場所に集約します。 設計判断をドキュメントに残したり、開発タスクを整理したりしていきます。 このようにして蓄積されるものが、私たちのプロジェクトコンテキストです。

さらに、情報を検索する手段をスキルとして用意します。 開発を担当するエージェントが、私たちの会話や大事にしていること、設計判断を参照できるようにするためです。 エージェントが、その前提を踏まえて開発するための仕組みです。

対話を重ねるほど開発の前提が共有されていく

開発タスクは、その性質に応じて分担します。 動作確認が複雑なものは人間が担当し、自分で実行結果を検証できるものはエージェントに任せます。 もう少し議論が必要なことは、人間同士で話し合います。

ただし、その議論も話して終わりにはしません。 書き起こしをAIが分析し、再びプロジェクトコンテキストに反映します。 エージェントは更新された情報を読み、私たちの設計判断や関心を踏まえて次の開発を進めます。 このサイクルを繰り返しています。

ここで人間が集中するのは、設計判断を充実させることです。

私たちはこのサイクルが好きです。 みんなで話しているとエージェントが重要事項を整理してくれて、その内容が開発に反映されていく。 話せば話すほど、エージェントが私たちの考え方に沿って働いてくれるようになります。

最近は、開発しているというより、ずっと話しているような感覚もあります。 もちろん、その対話で扱っているのはユースケースや設計上の課題です。 ユースケースや設計上の課題を話し合うことで、エージェントが開発を進めやすくなっています。

自己検証できる開発タスクを進めるためのハーネスも、私たちは独自につくっています。 Devinのようなサービスを使ってもよいと思います。

私たちが独自につくっているのは、開発しているプロダクトに固有の事情があるためです。 エージェントハーネスの開発が私たちの専門領域であることも、理由の一つです。 必ず独自のハーネスを開発しなければならない、という話ではありません。

開発で行っていることは一般業務にもつながる

開発プロセスでは、さまざまな場所で生まれる情報を集約し、エージェントに仕事を進めてもらっています。 これは、タスクゼロそのものの発想でもあります。

研修事業には、受講者の管理や受講者向けの書籍発送の対応など、細かな実務があります。 研修先への入館申請や、講師がその日に現地へ行けるかどうかの調整もその一例です。 タスクゼロのエージェントがこうした仕事を進められるのは、判断に必要な情報が集約されているからです。

そう考えると、一般業務の進め方も、開発現場でプロジェクトコンテキストを強化する取り組みとそれほど違いはありません。 集めるのは、開発に必要な情報か、研修の運営に必要な情報か。 扱う仕事は違っても、コンテキストを整えてエージェントが働けるようにする、という考え方は共通しています。

個人のエージェントと組織の仕組みをつなぐ

組織でAIエージェントを活用する場合、リモートで動くエージェントに仕事を任せる方法があります。

ただ、最近は個人が手元のパーソナルエージェントに、自分の作業を代行してもらう場面も増えています。 Claude CodeやCodex、Hermes Agentなどがその例です。 こうしたエージェントを使い慣れている人は、組織が用意したリモートのエージェントしか使えないと不自由に感じます。 使い慣れた手元の環境で、自分らしい進め方で仕事を進めたいという思いがあるためです。

そこで私たちは、それぞれのパーソナルエージェントをタスクゼロに接続しています。 自分に合った仕事のやり方は、個人の環境で構築できるようにしています。 もちろん、組織の情報に個人のエージェントを接続する以上、データの管理は慎重に考えなければなりません。

そのうえで、個人のエージェントが進めた仕事の結果も、タスクゼロに情報として入ってくるようにします。 一人ひとりが持っている仕事のノウハウを個人の環境だけにとどめず、組織の情報としても蓄積していくわけです。

私たちはこれを、組織のハーネスと個人のハーネスのダブルループ学習として捉えています。 個人の仕事の進め方を工夫しながら、その結果を組織にも蓄積し、組織のノウハウを強化していく。 私たちのハーネスエンジニアリングの実践では、こうしたことを実現しようとしています。

ハーネスエンジニアリングの射程とは何か

人が承認し続ける状態から、活動全体を監督する状態へ

こうして考えると、ハーネスエンジニアリングは開発者だけのものではありません。 AIエージェントを使って仕事を進めることそのものに関わる考え方です。

AIの使い方を少し振り返ってみると、人の関わり方は段階的に変化してきました。 2022年末にChatGPTが登場した頃は、人間がチャットに指示を入力していました。 AIの回答を見て判断し、自分の手で作業を実行していました。 AIが人間を支援する、ヒューマンサポートの段階です。

そこから、AIエージェントが実際に環境へ働きかけるようになりました。 ある行動を実行するときには、人間が確認して承認を与えます。 これがHuman-in-the-loopです。

しかし、エージェントが一つひとつ承認を求めて止まっていると、人間はずっとその対応をしなければなりません。 エージェントにある程度は自分で動いてもらい、仕事を進めてもらえる構造をつくりたいと考えています。 そのために考えたいのが、Human-on-the-loopです。 エージェントが仕事を進め、人間はその活動全体を監督する形です。

先ほど触れたループエンジニアリングも、この延長線上にあります。 個々の処理のたびに人間が介入するのではなく、エージェントが継続して仕事を進められるように設計していきます。 そのために、エージェントの活動をどう組み合わせるかを考えます。

さらに、人間が関与せずに自律的に実行するHuman-out-of-the-loopという考え方もあります。 ただ、今、技術的な到達点として考えたいのは、Human-on-the-loopをどう実現するかです。

一人ひとりの生産性を高めるだけでは解決しない

この話の背景にあるのは、一人ひとりの生産性を高めても、それだけでは組織全体の問題は解決しないということです。

個人がClaude CodeやCodexを使いこなすことは、もちろん大切です。 ただ、コードをたくさん生成できるようになっても、チームの仕事が進むとは限りません。

たとえば、メンバーがAIで大量のコードを生成し、次々にプルリクエストを送ってきたとします。 でも、なぜその実装になっているのかを聞いても、AIが書いたものなので本人もよく分からず、説明できません。 そうなると、レビューする人が一つひとつ調べて確認しなければなりません。

コードの量だけを見れば、生産性が上がっているように見えます。 しかし、レビューする側の負担が増えて、プロセス全体では仕事が進まなくなります。 場合によっては、そうしたコードがないほうがよかった、ということにもなりかねません。

ですから、個人の生産性が高まることを前提に、チームの中でコンテキストをどうすり合わせるかを考える必要があります。 何をつくろうとしているのか、どんな設計判断をしているのか、ほかの人が何をしているのかを共有します。 その理解をもとに、人間とAIが役割を分担して仕事を進めます。

先ほどご紹介した、みんなで話しながら設計判断を充実させるという取り組みも、ここにつながっています。

チームの合意を、AIが参照できる形にする

AWSのAI-DLC（AI-Driven Development Lifecycle）でも、モブエラボレーションが重視されています。 個人がそれぞれAIエージェントを使い続けるというより、まずはみんなで前提を合わせます。 そのうえでAIエージェントに働いてもらう、という考え方です。

前提を合わせる必要がある理由の一つは、AIが判断するときに考慮する時間の範囲が短いことだと思っています。

ソフトウェアは、コードを実装したら終わりではなく、その後何年も保守し続けることになります。 一方、AIエージェントは、目の前の仕事が数秒で片づけばよい、というような動きをしてしまうことがあります。 目の前のタスクが終わることと、その後も人間が保守していけることは同じではありません。 この時間の捉え方にずれがあると、エージェントが出してきた成果物が、人間の意図と合わなくなります。

だからこそ、長期的に大事にしたいことやチームとしての合意を明文化し、AIに伝えていくことが重要です。 単に作業を依頼するだけでなく、その作業の前提となる設計判断を、コンテキストとして参照できるようにする必要があります。

私たちが対話の機会を増やしているのもそのためです。 ユースケースや設計上の課題について話し合い、その内容をドキュメントに反映させます。 チームの理解を共有し、その理解に基づいてエージェントにも仕事をしてもらいます。 そうやって、チームで品質をつくっていきたいと考えています。

開発組織から事業組織へ

これまでは、こうした仕事の進め方や組織のあり方を、主に人間を対象として考えてきました。 これからは、AIとの協働を前提に、組織をどうつくっていくかまで考える必要があります。

その際に重要になるのが、ハーネスエンジニアリングという考え方です。

その射程は、個人の作業を速くすることだけではなく、チーム全体の生産性を高めることにあります。 AIを中心に仕事が進む仕組みを考えるうえで、欠かせない視点だと考えています。

私たちが対話を重ねてプロジェクトコンテキストを強化しているのも、このためです。 各自が別々の前提で仕事を進めるのではなく、共有した設計判断に基づいて人間とエージェントが役割を分担します。 対話の内容をエージェントが参照できる形に残すことで、人間とAIの双方が同じ理解に立って仕事を進められるようにしています。

そして、この考え方は開発組織だけにとどまりません。 研修事業の運営にも、この考え方を適用できます。 個人のエージェントを組織の仕組みにつなぎ、仕事の結果やノウハウを組織の情報として蓄積していくことにも適用できます。

開発組織のハーネスエンジニアリングから、事業組織のハーネスエンジニアリングへ。 AIエージェントを組織で活用していく際には、エージェント単体の調整だけでなく、その外側にある仕事の進め方や組織運営にまで、この考え方を広げていくことが大切だと思っています。