なぜあなたのAI駆動開発はうまくいかないのか？
──今押さえるべきハーネスエンジニアリングとは何か

2026年6月10日に開催された「AI NATIVE EXPO 2026」に西見が登壇し、「なぜあなたのAI駆動開発はうまくいかないのか？──今押さえるべきハーネスエンジニアリングとは何か」というタイトルで講演しました。

読み込み中...

コーディングエージェントを導入すれば、一人の開発者が短時間で大量の実装を行うことができます。 しかし、実装が速くなっても、生成されたコードをレビューし、仕様どおりに動くかを確かめる仕事はなくなりません。 どのようにテストするかを決めたり、なぜその設計を選んだのかをチームへ伝えたりする仕事も必要です。 実装を担当した開発者がこれらを引き受けなければ、別のメンバーの仕事が増えるだけです。

このように、負担がチームの別の場所へ移動するだけの構造では、AI駆動開発がうまくいったとはいえません。 AI駆動開発を本当の意味で上手くいくようにするためには、どのようにすれば良いのでしょうか。 それには、チームの意図と、AIエージェントの動作が噛み合うように、AIエージェントが働く環境を設計していく必要があります。 講演では、この環境を継続的に整備する取り組みとして、ハーネスエンジニアリングを紹介しました。

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

AIエージェントは、次の行動を選ぶモデルと、その行動を実行するためのハーネスで構成されます。 LangChainも、AIエージェントをモデルとハーネスに分けて説明しています。

GPT、Claude、Geminiなどのモデルは、与えられた情報から次の行動を選ぶことができます。 しかし、モデル単体ではファイルやAPI、ブラウザへはアクセスできず、コマンドも実行できません。 モデルを取り巻く環境にアクセスすることができないのです。

ハーネス（エージェントハーネス）は、モデルと環境とを橋渡しする役割を持ちます。 まずハーネスは、利用者の依頼と、作業に必要な情報やツールをモデルへ渡します。 モデルがファイル操作やコマンド実行を求めると、ハーネスがその操作を実行し、結果をモデルへ返します。 さらに、作業状態を保持し、決められた手順で結果を検証することもハーネスの役割です。 モデルとハーネスを組み合わせることで、AIエージェントは実際の作業を進めることができるのです。 Claude CodeやCodex、OpenCode、GitHub Copilot CLI、Deep Agentsは、こうしたモデルとハーネスからなるコーディングエージェントです。

これらのコーディングエージェントには、ファイル操作やコマンド実行といった汎用的な機能が備わっています。 しかし、それだけでは、個々のプロジェクトで何を守り、どこまで変更してよいのかまではAIエージェントが判断できません。 仕様や設計方針、品質基準、作業の完了条件はプロジェクトごとに異なるため、利用者側で与える必要があります。

開発チームは、エージェントスキルやプロジェクトコンテキストを通じて、こうした前提をAIエージェントへ伝えます。 また、AIエージェントに使わせるツールと権限、処理の前後に実行するフック、変更後に必ず通すテストも決めます。

本稿では、コーディングエージェントをプロジェクトごとの条件に合わせるために、利用者が管理する一連の情報と設定をユーザーハーネスと呼びます。 ユーザーハーネスの主な要素は次のとおりです。

• エージェントスキル
• プロジェクトコンテキスト（AGENTS.mdやCLAUDE.md）
• 仕様書とADR（設計記録）
• AIエージェントが利用できるツールと権限
• フック
• テストと検証手順

ハーネスエンジニアリングは、このユーザーハーネスをチームの開発方針と品質基準に合わせて整備し、改善し続ける取り組みです。 AIエージェントの作業結果や失敗から得た知見をユーザーハーネスへ反映し、開発の進め方を継続的に見直していきます。

AI駆動開発で加速する人間への負荷

AI駆動開発とは、要件定義、プロトタイピング、コーディング、テスト、品質管理といった開発プロセス全体にAIを組み込む、新しい開発のパラダイムです。

METRが2026年に実施した技術職への調査では、回答者は、AIツールによって業務上の成果が中央値で1.4〜2倍、作業速度が中央値で3倍になったと答えました。 ただし、METRは作業速度の向上が仕事の価値を過大に表す可能性も指摘しています。

個人で完結する仕事なら、作業速度の向上がそのまま成果につながります。 しかし、チーム開発では実装後にレビューや仕様確認が続きます。 例えば、ある開発者がAIで大量のコードを作っても別のメンバーが確認するなら、大量のコードによって別のメンバーの仕事が単純に増えることになります。

分かりやすい例が、プルリクエストの増加です。 コーディングエージェントによって実装量が増えると、コード変更の確認を求めるプルリクエストも増えます。 しかし提出者がコーディングエージェントに頼りすぎたあまりに実装の理由や設計判断を説明できなければ、レビュー担当者はコードの背景から調べることになります。

さらに、AIが細部まで実装して多数のテストケースを作れば、確認するコードとテストも増えます。 細部まで実装され、テストが増えること自体は品質の向上につながるかも知れませんが、そのコードとテストが仕様に合っているかは、誰かが確かめなければなりません。

実装担当者の作業が速くなっても、チーム全体ではレビューや仕様確認、テスト方法の検討、設計判断の共有にかかる時間が増えてしまう可能性があります。 個人の作業速度が上がったかどうかと、チーム全体の開発が改善したかどうかは、分けて考える必要があります。 これがAIツールの導入だけでは、実際の成果に繋がらない可能性がある大きな理由です。

AIが働く環境をチームで設計する

開発者が作業のたびに指示を考えている使い方では、AIエージェントの成果は、その開発者がどれだけ詳しく指示できるかに左右されます。 チームで安定した結果を得るには、参照させる情報や許可する操作、変更してよい範囲、人間へ判断を戻す条件をユーザーハーネスに記録しておく必要があります。

また、変更後に必ず実行する検証方法と、失敗したときに確認するログをあらかじめ決めます。 AIエージェントが作業に失敗した場合は、エラーログや検証結果をもとに修正させます。 同じ失敗を繰り返すなら、その都度指示し直すのではなく、エージェントスキルやプロジェクトコンテキストを更新します。

講演では、AIエージェントが継続して作業できる環境を整える例として、三つの取り組みを紹介しました。 AnthropicのLong-Running Agentsは、作業一覧や進捗記録を次のセッションへ引き継ぎ、各セッションでテストを実行する方法を示しています。 OpenAIのHarness Engineeringは、リポジトリ内の知識を基準にして、リンターや構造テストで設計上の制約を機械的に検証しています。 ThoughtworksのOuter Harnessは、指示や制約を与える仕組みと、テストやLinterから結果を返す仕組みを分けて整理しています。

チームで決めた仕様や設計方針はAIエージェントが作業中に読める場所へ置き、実施すべき検証方法などもユーザーハーネスに記録することで、チームでユーザーハーネスを育てる仕組みづくりが重要となります。

AIに任せる範囲を段階的に広げる

講演では、OECDによるAIシステムの分類をもとに、AIに任せる範囲を人間の関与の仕方に応じて四段階に整理しました。

第1段階 AIは提案だけを行う

Human Support / No-Action Autonomyでは、AIはコードや手順を提案し、人間が開発環境へ反映します。 初期のChatGPTを使った開発は、この形が中心でした。

第2段階 人間の承認後にAIが実行する

Human-in-the-Loopでは、AIがファイル変更やコマンド実行の前に承認を求めます。 操作を確認できる反面、人間の応答を待つたびに作業が止まります。

第3段階 AIが実行し、人間が監督する

Human-on-the-Loopでは、AIが定められた権限内で作業を進めます。 人間は動作状況と結果を確認し、異常があれば停止してルールや権限を見直します。 講演では、このHuman-on-the-Loopを現時点での現実的な目標として示しました。

第4段階 AIが実行と検証を続ける

Human-out-of-the-Loopでは、人間が定めた範囲内で、AIが作業から検証、修正まで進めます。 テストなどで正しさを確認できない仕事は、この段階へ移さず人間が担います。

したがって、業務ごとに人間が判断すべき箇所を先に決めます。 そのうえで、AIエージェントがテストなどを使って自分で結果を確かめられる仕事から任せます。 ユーザーハーネスに検証手順を追加し、AIエージェントが自分で完了を確認できる仕事から、人間の承認を外していきます。

共有知を実装できる仕様に変える

AIによって実装速度が上がっても、設計判断や品質基準が共有されていなければ、AIエージェントが作るコードや資料が増えるほど、確認にかかる負担も増えます。 設計方針が統一されないまま変更が重なれば、保守しにくいコードや技術的負債も増えていきます。

そのため、業務要件や運用上の制約、設計方針、品質基準をチームで明確にし、AIエージェントが作業中に参照できる形で残します。

この作業をチームで進める方法の一つがMob Elaborationです。 AIが示した質問や提案をチームで検討し、業務要件、運用要件、システム設計を具体化します。 合意した内容は仕様書やADRとして記録します。

AI-DLC（AI-Driven Development Lifecycle、AI駆動開発ライフサイクル）では、AIエージェントが見つけた要件の不足や矛盾を、開発の初期段階でチームへ質問として返します。 例えば、対象とする利用者や例外時の処理、必要な性能が決まっていなければ、AIエージェントが確認を求めます。 人間は業務と事業の状況を踏まえて質問に答え、必要であればチームで検討します。 誰が使うのか、例外をどう扱うのか、どの程度の性能が必要かについて合意したうえで、実装に着手します。

決まった要件や設計判断をユーザーハーネスへ残しておけば、担当者が変わっても、AIエージェントへ同じ説明を繰り返す必要はありません。 AIエージェントは作業中に仕様書とADRを読み、判断の前提にします。 会議で決まった事項もAIエージェントに整理させ、仕様書やADR、バックログへ反映します。

ユーザーハーネスをチームの資産として育てることで、チームとAIエージェントとが共に成長する構造をつくることができます。

長期的な設計判断は人間が担う

LLMを使ったエージェントは、目の前の問題を順に処理することには優れています。 しかし、判断の影響が後の工程まで及ぶ長期計画では、初期の選択が将来の状態をどう変えるかまで見通せないことがあります。

2026年1月に公開された論文「Why Reasoning Fails to Plan」は、LLMの推論が長期計画でつまずく理由を分析しています。 論文では、状態遷移と評価方法が明示された環境を使い、長期的な意思決定を調べました。 実験では、各段階の評価に基づいて局所的に最適な行動を選び続けると、早い段階の判断に固定され、その後の修正が難しくなる結果が示されました。 ソフトウェア設計を直接評価した論文ではありませんが、段階的な推論と長期計画を分けて考える手掛かりになります。

ソフトウェア設計でも、将来のデータ量や業務変更を考慮する必要があります。 データが1万件か100万件か、処理が毎秒100件か一日10件かで適切な設計は変わります。 さらに、事業の成長や保守性、性能要件も設計を左右します。

こうした長期的な前提は、人間が業務や事業の状況を踏まえて決め、AIエージェントが参照できる形で明示する必要があります。 人間が決めた将来のデータ量や性能要件は、仕様書やADRとしてユーザーハーネスに記録する必要があります。

当社における実践

当社は、AIエージェント運用プラットフォーム「タスクゼロ」の開発を通じて、ハーネスエンジニアリングを実践しています。 タスクゼロは、AIエージェント向けのタスク管理とデータ管理の機能を備え、社内業務の一部をAIに任せるためのプラットフォームです。

開発にあたっては、設計判断や開発タスクに加え、仕様に関する議論と関連資料をユーザーハーネスとして管理しています。 タスクゼロには複数の機能と業務要件があるため、人間が全体の設計と変更の影響範囲を確認します。

複数のシステムにまたがる処理や画面操作のうち、業務上の意味を踏まえなければ成否を判断できない動作確認は人間が担当します。 一方、テストや静的解析で結果を確認できる作業には、自社で開発している「GAエンジニアリングハーネス」を利用しています。 GAエンジニアリングハーネスは、クラウド上で開発を完結できるAIエージェントです。

テストや静的解析で完了を確認できる作業はAIエージェントに任せます。一方、動作が業務上正しいかを判断する作業は人間が担当します。

また、会話や会議からAIエージェントが重要事項を抽出し、バックログやドキュメントへ反映する運用も進めています。 人間同士のディスカッションをもとに、AIエージェントがユーザーハーネスに重要事項を反映することで、チームの思い描いている理想像がAIエージェントの動作に自動的に反映されるような仕組みを整えています。

チーム全体の生産性につなげる

AI駆動開発は、一人の開発者がコードを速く書けるようになることだけを意味しません。 個人の作業が速くなっても、レビューや仕様確認、設計判断、品質管理の進め方が従来のままであれば、ここまで見てきたとおり、チーム全体の生産性は上がらないからです。

AIエージェントを組織で活用するには、チームの知見や設計判断、品質基準を、AIエージェントが参照できる形で管理する必要があります。 利用できるツールと権限、検証方法、人間が介入する条件も、ユーザーハーネスとして定めます。

ハーネスエンジニアリングは、こうした情報と実行環境を継続的に整備する取り組みです。 AIエージェントの作業結果を検証し、足りなかった情報や手順をユーザーハーネスへ反映します。

AIエージェントが一定の品質で作業を続けられる環境を整えることで、AI駆動開発を個人の効率化で終わらせず、チーム全体の生産性と品質の向上につなげられるのです。