AIエージェントが失敗するたびに、プロンプトを長くする。別のモデルに変える。さらに資料を読み込ませる。それでも、古い仕様を参照したり、テストを飛ばしたり、完了していない仕事を「完了」と報告したりする。
この問題を、AIの周囲にある実行環境から解くのがHarness Engineeringだ。目的、参照情報、使える道具、権限、進捗、検証、失敗からの復旧を設計し、モデルの能力を実際の成果につなげる。
この考え方は、SIerの仕事と深く接続する。要件定義、既存システムとの連携、品質保証、保守運用は、まさに企業がAIに仕事を任せるために必要な機能だからだ。
ただし、「SIerが昔からやってきたことだから有利」と言い切るのは早い。人が読んで守る手順を、機械が実行し、違反を検知できる仕組みに変えられるか。そこが分岐点になる。
本稿では、公開された技術資料と国内SIerの取り組みを踏まえ、具体的なサービスと収益モデルを考える。業務例、料金設計、導入手順は筆者の提案であり、実在案件の実績ではない。
Harness Engineeringが設計するもの
LLMは、文章を読み、推論し、次の行動を提案できる。しかし、正しい資料へのアクセス、許可された操作、途中状態の保存、成果の確認まで、モデル単体で保証することはできない。
ハーネスとは、それらを担う実行環境だ。AIに「気をつけて」と言う代わりに、許されない操作は実行できず、検証を通らない成果物は完了にならないようにする。
OpenAIは2026年2月の技術記事で、短いAGENTS.mdを情報への地図として使い、詳細資料を必要に応じて参照する構成を紹介している。アーキテクチャの制約も、文書に書くだけでなく、独自の静的チェックや構造テストで強制している。OpenAIの技術記事
Anthropicも、長時間動くエージェントについて、初回に環境を整え、以降は小さく作業を進め、進捗ファイルやGit履歴を次のセッションへ残す方式を紹介している。Anthropicの長時間エージェント設計
ここでの設計対象は、AIへの説明だけではない。AIが何を根拠に動き、何をもって完了し、どこから再開できるかという仕事の仕組みそのものである。
SIerの既存業務をどう変換するか
SIerの業務との対応を、実装する成果物まで落とすと次のようになる。これは本稿での整理であり、業界標準の分類ではない。
| SIerの業務 | ハーネスとして実装するもの |
|---|---|
| 要件定義 | 目的、対象範囲、禁止事項、受入条件を持つタスク定義 |
| 業務仕様の管理 | 有効な仕様の所在、適用日、承認者、関連機能への参照 |
| システム連携 | 入力、権限、失敗時の挙動が決まった業務API |
| 品質保証 | 受入条件に対応するテストと実行結果 |
| 変更管理 | 変更内容、検証証拠、承認範囲を結び付けるゲート |
| 運用保守 | 途中状態、障害分類、再開手順、停止条件 |
| 障害分析 | 再発した失敗をテストや権限制御に反映する改善 |
「承認者を正しく判定すること」と設計書に書くだけでは、実行可能な仕様にはならない。異動日当日はどちらの所属を使うのか、代理承認がある場合はどうするのか、承認者が不在なら止めるのか。条件と期待結果まで必要になる。
同じように、「本番変更は承認が必要」と指示するだけでは権限制御にはならない。承認された変更と対象環境を確認する仕組みが、実際の実行経路に必要だ。事前に許可された定型操作はその範囲で進め、承認済みの内容を超える変更は止める。
SIerの経験が価値になるのは、経験を説明できたときだけではない。経験を、検証可能な条件と実行可能な制御へ変換できたときだ。
開発の自動化と顧客業務の自動化を分ける
SIerとの融合には、二つの入口がある。
一つは、SIer自身の開発工程を動かすハーネスだ。仕様を調べ、改修箇所を特定し、コードとテストを作り、レビュー可能な変更を提出する。狙いは、開発原価とリードタイムの改善になる。
もう一つは、顧客の業務を動かすハーネスだ。問い合わせの調査、申請の照合、発注内容の確認などを、顧客の権限と業務ルールの中で実行する。こちらは、業務サービスとして継続提供する対象になる。
富士通は2026年2月、要件定義から設計、実装、結合テストまでを対象にするAIドリブン開発基盤を発表した。既存資産や知識を整えるAI-Ready Engineeringを重要な工程と位置付け、人月ベースから顧客提供価値ベースへの転換も掲げている。なお、発表中の「3人月を4時間」は実証対象約300件のうち1件の結果であり、全案件の平均として扱うべきではない。富士通の発表
NTTデータはSmart AI Agentについて、開発標準と基盤の整備に加え、コンサルティングから導入・運用、BPSまでの支援を説明している。NTTデータの公開資料
これらの公開方針からは、開発工程の変革と、顧客業務への提供という二つの方向が読み取れる。ただし、それぞれの収益性や本番での成功率まで、これらの資料から判断できるわけではない。
自社の作業を速くする施策と、顧客が継続して対価を払うサービスは、別々に事業性を評価する必要がある。
既存システムの小規模改修に適用する
具体例として、申請システムに「月途中の組織変更でも承認者を正しく決める」という変更依頼が来た場合を考える。
最初の仕事は、コードを書くことではない。何が正しいかを確定することだ。申請時点と承認時点のどちらを基準にするのか。差し戻し後の再申請は新しい所属を使うのか。過去の承認履歴は保存するのか。
ここをAIに推測させると、整合性のあるコードができても業務仕様は間違う。仕様が未確定なら、未確定として顧客の業務責任者へ戻す必要がある。
正しい仕様の所在を決める
大規模な既存システムでは、最新版の設計書、実装、運用手順、過去の議事録が一致しているとは限らない。
そのため、「資料をすべて検索できる」だけでは不十分だ。どの資料が承認済みか、いつから有効か、実装との差異は既知かを管理する。資料間の矛盾は、AIが黙って解消する対象にしない。
コードは現在の挙動を示すが、望ましい仕様を保証するわけではない。承認済み要件は意図を示すが、実装済みとは限らない。この区別を維持し、要件、関連機能、変更、テスト結果を結び付ける。
完了条件を変更前に固定する
この例なら、受入条件には次のような項目が必要になる。
-
異動日前、当日、翌日の申請で、合意した基準日の承認者を選ぶ。
-
代理承認、差し戻し、再申請の既存仕様を維持する。
-
過去の承認履歴を変更しない。
-
権限のない利用者による承認操作を拒否する。
-
対象画面からの申請と関連バッチの双方で検証する。
作業中のAIが、都合よく受入条件や期待結果を書き換えられないようにする。実装する側と受入基準を管理する側の権限を分けることが、独立した検証の土台になる。
変更と証拠を一緒に提出する
実行の流れは、次のように設計できる。
- 承認済み要件を確認する。
- 改修候補を作成する。
- 受入条件を検証し、証拠が十分か判断する。
不足 → 修正または仕様確認を行い、改修候補の作成へ戻る。 - 証拠が十分なら、変更と証拠を提出する。
- リリース権限を確認する。
許可範囲内 → 反映して結果確認。許可範囲外 → 承認待ち。
顧客に提出するのは、変更したファイルだけではない。対象の要件、参照した仕様の版、テスト結果、確認していない範囲、残るリスクをまとめた記録も必要になる。
Anthropicの評価設計の記事も、エージェントの発言や操作履歴と、環境で実際に成立した結果を区別している。「予約したと言った」と「予約が存在する」は別の評価対象だ。Anthropicのエージェント評価
改修でも同じである。「修正しました」という文章より、合意した条件を満たす実行結果の方が検収に使える。ただし、テストに含まれない条件まで正しさが証明されたわけではない。
中断後の再開を業務単位で設計する
作業が止まったとき、チャット履歴を要約するだけでは再開できない。どの版を変更したか、どこまで検証したか、誰が何を承認したかが必要になる。
さらに、顧客業務を実行するエージェントでは、タイムアウト後の再実行が危険になる。発注処理の応答が返らなくても、発注そのものは成立しているかもしれない。
この場合は、実行識別子と処理状態を確認してから再開する。複数システムにまたがる処理には、取り消しや補正の手順も設計する。回復方法は「もう一度同じ指示を出す」ではなく、業務上の状態から決める。
再試行には回数、経過時間、費用の上限を設ける。同じ失敗が続く場合は、修正で進められるのか、仕様確認が必要なのかを分類して止める。上限のない修正ループは、納期も原価も見積もれない。
SIerが商品化できる三つのサービス
ここからは事業提案になる。顧客が買いやすい単位を、成果物と運用責任で区切る。
| サービス案 | 顧客に渡すもの | 料金設計の案 |
|---|---|---|
| 既存資産のAI対応 | 仕様の索引、適用版、業務ルール、評価用ケース | 対象業務と整備範囲を定めた初期費用 |
| 特定業務のエージェント実装 | 接続API、権限制御、検証、再開手順 | 対象業務単位の構築費用 |
| エージェントの運用改善 | 稼働監視、評価更新、障害対応、モデル変更時の検証 | 基本月額と処理量に応じた従量費用 |
初期整備で渡すものは、設計書の再編集だけでは足りない。検索した情報を誰が正しいと認めるか、変更時に誰が更新するか、更新漏れをどう検知するかまで含める。
運用サービスも、稼働時間だけを監視していては弱い。動いているのに間違った処理を続けるエージェントはあり得るからだ。業務ごとの成功条件と失敗条件を監視し、モデルやツールを変更したら既存の評価ケースを再実行する。
再利用できる部分を増やせば、継続収益の余地が生まれる。権限制御や実行記録などの共通機能を基盤として使い、顧客固有の業務ルール、接続、評価を追加する。ただし、毎回ゼロから個別対応する運用では、月額課金にしても利益は積み上がらない。
成果報酬を付けるなら、測定できる範囲に限定したい。処理リードタイムや確認工数は比較しやすい一方、顧客企業の売上にはAI以外の要因も多い。AIの寄与を切り分けられない成果指標で、料金や責任を決めるのは難しい。
運用責任を機能ごとに定める
顧客が最終承認するというだけでは、責任分担は明確にならない。契約と運用設計では、例えば次のように担当を定める案が考えられる。
| 対象 | 担当と責任の案 |
|---|---|
| 業務仕様と例外の確定 | 顧客の業務責任者が判断し、SIerが根拠と条件を記録する |
| 接続と権限制御の実装 | SIerが許可された操作範囲を実装し、違反の拒否を検証する |
| 仕様変更時の対応 | 顧客が変更を通知し、SIerが評価ケースと実装を更新する |
| 実行中の障害と復旧 | SIerが契約範囲で検知・停止・復旧し、業務判断が必要な例外を顧客へ戻す |
人の承認を置くことは、設計や検証の不足を顧客に引き受けてもらう理由にはならない。逆に、顧客が確定していない業務ルールまで、SIerが推測して実行するべきでもない。
モデル提供者のサービス条件と、SIerが顧客に約束する運用水準も分けて考える。障害の検知時間、対応時間、復旧手順、評価の実施頻度など、管理できる対象を合意し、残る判断と制約を明示する。
人月商売と汎用基盤がもたらす圧力
Harness EngineeringをSIerの追い風とだけ捉えると、事業判断を誤る。
人月を基準に対価を決める契約では、同じ仕事を少ない工数で完了できるようになると、次回の見積もりや契約更新で売上が縮む可能性がある。固定価格なら原価低減を利益にできる余地があるが、それも競争や顧客への還元要求とは無関係ではない。
したがって、社内で「生産性が上がった」と報告するだけでは足りない。空いた能力で追加需要に対応するのか、納期を短縮して受注率を高めるのか、業務運用を継続提供するのか。売上と利益への接続を決める必要がある。
もう一つの圧力は、汎用機能の製品化だ。Microsoft Agent 365は、企業内のエージェントを把握、管理、保護する制御基盤を提供している。Microsoft Agent 365
この動きから考えると、ログや管理画面を作ったことだけで、長期の差別化を説明するのは難しい。共通基盤の機能が増えるほど、SIerはその上で何を提供するかを問われる。
差別化の候補は、顧客固有の業務ルール、既存システムとの確実な接続、実際の失敗から育てた評価ケース、障害時に業務を復旧する能力だ。ただし、顧客の情報や評価データを他社案件へ再利用できるとは限らない。共通化する仕組みと顧客が保有する情報を分けて設計する必要がある。
AIを導入したSIerが勝つというより、AIを使った後の品質と採算を説明できるSIerに商機がある。
自動化率より業務全体の費用を測る
導入効果を、コード生成速度やAIだけで処理できた割合だけで測ると、実際の採算を見失う。
仮に月100件の調査業務があり、従来は1件2時間、月200時間かかっていたとする。導入後の人の確認が1件30分まで減っても、評価更新や障害対応に月40時間かかれば、残る作業は月90時間になる。
| 仮定した比較項目 | 導入前 | 導入後 |
|---|---|---|
| 調査と確認の人の作業 | 月200時間 | 月50時間 |
| 新たな評価更新と障害対応 | 比較上は0時間 | 月40時間 |
| 比較対象の合計 | 月200時間 | 月90時間 |
この仮定では、調査と確認だけなら75％減だが、追加運用を含む人の作業削減は55％になる。さらに利用料、基盤費用、初期整備、レビュー待ち、誤処理の復旧費用を加える必要がある。実案件では導入前から存在する保守工数も両側に含めて比較する。
空いた110時間も、そのまま現金の利益になるとは限らない。追加案件に回せるか、残業や外注を減らせるかで、経済的な効果は変わる。
測るべき指標には、人の総関与時間、受入条件を満たした完了率、差し戻し率、復旧までの時間、成功した業務1件当たりの総費用がある。
停止判断の品質も重要だ。仕様が矛盾したときに止まることは、望ましい動作である。一方、許可された定型処理で毎回人を呼べば、確認コストが膨らむ。必要な停止と不要な停止を、別々に評価する。
最初の案件をどう選ぶか
最初から数千の画面や全業務を対象にすると、仕様整理だけで投資が膨らむ。まずは、反復件数があり、完了条件を定義でき、影響範囲を絞れる業務を選ぶ。
候補としては、問い合わせの一次調査、限定した種類の改修についての影響調査、既存仕様に基づくテスト案の作成などがある。最初は、本番更新より、読み取りとレビュー可能な成果物の提出から始めやすい。
導入は、次の順序で進める案が考えられる。
-
現状を測る。 処理件数、人の作業時間、差し戻し、事故の種類を把握する。
-
過去案件で評価する。 正常ケースに加え、仕様の矛盾、権限不足、ツール障害を用意する。過去の答えが漏れないようにする。
-
実業務に並走させる。 AIの結果を人の処理と比較し、まだ外部の状態を変更させない。
-
許可範囲を限定して動かす。 読み取りから下書き、限定的な更新へ進め、各段階で総費用と品質を確認する。
処理順が固定され、判定条件も明確な部分は、従来のプログラムやワークフローで実装する方が予測しやすい。調査対象や手順を状況に応じて選ぶ部分に、エージェントを使う。
Anthropicも、定義済みの手順を動かすワークフローと、モデルが手順を選ぶエージェントを区別し、必要な場合にだけ複雑さを増やす方針を勧めている。Anthropicの設計指針
全部を自律化する必要はない。業務の中で、AIの判断が価値を生む場所を見つけ、その前後を確実な仕組みでつなぐことが大切だ。
業務仕様をAIが実行できる資産にする
Harness Engineeringは、SIerの経験を生かせる領域だ。ただし、過去のやり方をそのまま続ける理由にはならない。
レビューで毎回同じ指摘をしているなら、その条件をチェックにできるかを考える。担当者だけが知る例外があるなら、適用条件と根拠を管理する。障害のたびに調べ直すなら、実行状態と復旧手順を残す。
業務仕様を担う人の役割も変わる。要求を設計書にまとめるだけでなく、正しい仕様の根拠を定め、例外を整理し、受入条件と権限の境界を設計する仕事が重要になる。
企業が対価を払う対象は、AIの賢さだけではない。自社の業務で、何を任せられ、何が確認され、問題が起きたらどう戻せるかという実行能力だ。
その能力を顧客ごとに構築し、運用の中で改善し、共通化できる部分を増やす。そこまで進めて初めて、Harness EngineeringはSIerの新しい事業になる。
参考資料
2026年10月4日時点で確認した公開資料。各社の発表内容と、本稿の事業提案・仮定は区別して記載した。
-
OpenAI — Harness engineering: leveraging Codex in an agent-first world
-
Anthropic — Effective harnesses for long-running agents
-
Anthropic — Demystifying evals for AI agents
-
Anthropic — Building effective agents
-
富士通 — AIドリブン開発基盤の発表
-
NTTデータ — AIエージェントとSmart AI Agentの取り組み
-
Microsoft — Agent 365
着想の入口は、Mori氏（@0xjmori）の「Harness Engineering: How to Build AI Agents That Actually Work」。本稿はその投稿の逐語訳ではなく、上記の一次資料を参照し、SIerの業務と事業モデルへの接続を検討したもの。
WRITTEN BY
コメント