AI開発はプロンプトからコンテキスト、ハーネスへと向かう ハーネス成熟度を測る3つのチェックリスト：ハーネスなしでは「スケール」に限界 「人間がボトルネック」に（2/2 ページ）

「LLMを導入したのに生産性が上がらない」「レビューに追われる」　現場が直面する“限界”に対し、トップランナーたちが口をそろえて語るのが「ハーネスエンジニアリング」だ。先行者が明かす知見・ノウハウからハーネスエンジニアリングの実相に迫る。

[加山恵美, 編集：石川俊明，＠IT]

ハーネスなしでは「スケール」に限界　「人間がボトルネック」に

　この成熟度レベルの進展に伴い、人間がしているコーディングや実装のための作業が、順次AIに置き換わっていく。この定量的な変化について、FPTジャパンホールディングスの澁谷暢大氏は実務データに基づく分類を示している。

　手動プロセス中心のレベル1「Traditional」では人間の関与率が90〜100％（シャピロ氏のレベル0〜1相当）、既存プロセスをAIで強化するレベル2「AI Augmented」では関与率が50〜70％（同レベル2〜3相当）とされる。そしてAI前提の次世代開発モデルであるレベル3「AI Native」では、AIがプロセスの中心となり人間は設計・維持・監督に回るため、人間の関与率は20〜30％にまで低下する（同レベル4相当）。

FPTによる開発プロセス成熟度の分類（講演資料より引用）

　しかし、多くの開発組織がレベル2からレベル3へ移行しようとする際、深刻な人間のボトルネックに行き当たる。AIエージェントを並列稼働させることができてもレビューが追い付かない上、AIエージェント自身が自力で開発環境を起動・構築できないため、結局は人間の手作業がボトルネックとして残ってしまうのだ。

　ミラー氏の試算によれば、仮に1000体のエージェントが使い放題になったとしても、開発者1人が扱えるのはせいぜい5体が限度だという。

　「モデルの問題ではありません。モデルは十分に優れています。ボトルネックはわれわれ人間です」（ミラー氏）

　AnySphereではインフラと環境を適切に整備したことで、組織全体で1日に数千体のエージェントを自律実行させることに成功しているという。モデルの進化を待つのではなく、エージェントが自律的に動き、検証までを完結できる環境側のスケールこそが重要であり、それが「ハーネスエンジニアリング」の潮流に直結しているというわけだ。

買えるハーネス、自社でしか作れないハーネス　今から始められる

　立場の異なるプレイヤーが一様にハーネスを強調する背景には、市場全体が共通のアーキテクチャパターンに到達したという事実もある。

　Cognition AI Japanのシバタアキラ氏が「モデルそのものではなく周辺の設備（ハーネス）こそがわれわれのコアIP」と明言し、GitHubのウィリアム・チャン氏が、週1000ものプルリクエストを出す開発チームでハーネスを再構築した知見を明かしたように、ハーネスの設計精度は組織の開発能力に直結する要因となっている。

　FPTの澁谷氏も指摘するように、今後のテーマは「AI生成物の品質を確保するパイプライン（ハーネス）を構築できるか」にある。

　こうした中現在は、Amazon Web Services（AWS）の「AI-DLC」、Microsoftの「GitHub Spec Kit」、Anthropicの「Agent Skills」など、意図と規約を構造化してAIに読ませる基盤が共通の仕組みとして整いつつある。これらを踏まえ、開発組織が構築すべきハーネスの構造を整理すると、クラウドにおける「責任共有モデル」と同一の概念で把握できる。つまり「買えるハーネス」と「自分で作るハーネス」があるということになる。

　買えるハーネスとは、ベンダーが製品やサービスに実装するものだ。サブエージェントの構成、フィードバックループ、開発状態を保持するVM（仮想マシン）、隔離サンドボックス、モデルのルーティングなどが該当する。

　一方、自分で作るハーネスとは、自社のリポジトリや組織内で作る仕組みだ。方向性を示すハーネス（ConstitutionやSkills）、逸脱を止めるガードレール（Lint、型、test、CI〈継続的インテグレーション〉、Hooks）、そして自己修復まで回す能動品質ループで構成される。

　どれほどプラットフォーム・製品側が高度化していったとしても、自社固有のアーキテクチャや品質基準を守る領域はユーザー側、つまりエンジニア自身が構築し続けなければならない。またハーネスは一度作ったら終わりではなく、改善を継続する必要もある。GitHubのチャン氏が明かした事例では、社内ツールで一時的にlintをコメントアウトした際、AIが「コメントアウトするのが正しい」と誤学習し、不適切なコードが増殖する悪循環が発生したという。

　チャン氏が「良いコードが（その後の）良いコードをつくる」と語ったように、リポジトリの状態そのものがAIへの指示として伝わってしまうこともあるため、ハーネス側で健全な環境を維持し続ける設計（ループ）が不可欠となる。

ハーネス成熟度を測る3つのチェックリスト

　ハーネスエンジニアリングは決して“先の話”ではない。よく使うプロンプトをテキストファイルに保存・整理しているなら、ミラー氏が「すでにスキルを作り始めているが形式化していないだけ」と語るように、すでにハーネス構築の初期段階に足を踏み入れている。

　ミラー氏は「よく使うプロンプトを3つ選んでスキルにしてみてほしい」と推奨した上で、自社のAI支援開発プロセスにおいて「ハーネス」が機能しているかどうかを評価する指標として、以下の3つを確認するよう呼び掛けた。

1. Runnable：人手を借りずに開発環境を起動・稼働できるか
2. Accessible：AIが必要な文脈を各種ツールから自律的に引き出せるか
3. Verifiable：AIが自分の成果物を自力で検証・テストできるか

　この指標において「いいえ」となった項目こそが、組織が優先して設計すべきハーネスの「中身」となる。

　キーパーソンたちが語るように、開発組織におけるAI活用の成熟度を決定づけるのは、採用しているモデルの性能ではない。「モデルの周囲にどのような実行環境と統制システムを設計しているか」だ。

　プロンプトのチューニングから脱却し、ハーネス設計へと舵を切ることこそが、AI駆動開発において決定的な生産性の差を生み出す鍵になる。自社のアーキテクチャや組織文化をどうハーネスとして落とし込めるのか。AI活用の“勝敗”は、モデルの外側で決まり始めている。