AIエージェント氾濫時代の交通整理 — ハーネスエンジニアリングで読み解くAIの適材適所

※この記事は「MTI Blog Summer 2026」の 6/5 分の記事です。

こんにちは、AIエンジニアリング部の平野です。普段はデータサイエンスやソフトウェアアーキテクチャまわりの仕事をしていて、最近はデータや生成AIをどう業務に活用するかという観点での技術検証や、ガイドライン整備をやっています。

この記事では、最近社内情報共有会で発表した内容を一般向けに書き直してお届けします。テーマは「AIエージェントに何でもやらせるのが、本当に最適解なのか？」という問いです。

Claude CodeやCursor、Devin、GitHub CopilotのAgent Mode……ここ数年で実用レベルの開発AIが一気に増えました。便利な一方で、「AIにDBを消された」「AIが書いたコードからシークレットが漏れた」といった事故も同じくらい増えています。

この記事では、公開されている業界横断データや現場で語られているパターンを眺めながら、「AIに何を任せ、何を任せないか」を整理する視点を提示します。

この記事で持ち帰ってほしいこと

AIエージェントやAIスキルがあふれる今、 「全部AIに任せる」も「AIに任せず人間が見る」も、どちらも答えにはなりません 。鍵は AIを使うかどうか ではなく、 どのタスクに、どのAI（あるいは人間）を当てるか ——つまり 適材適所 です。

この記事では、

業界横断データと現場で語られる落とし穴 から、なぜ「AIに任せれば速くなる」が成立しなくなっているのかを眺め、
ハーネスエンジニアリング という枠組みを補助線に、検証(Evaluator)を Computational / Inferential / Human の3層に分けて整理し、
そのうえで「どのタスクをどの層に置くか」の判断軸を提示します。

最終的にお伝えしたいのは、 「AIを使うな」ではなく「AIを正しい場所に置きましょう」 ということ。これ1つ持ち帰っていただければ十分です。

まずは業界全体のデータから

ここでは、業界横断の調査レポート1本を起点に、AIエージェント時代に起きている構造的な問題を見ていきます。

業界全体 — レビュー崩壊の定量データ（2026年）

Faros AI "AI Acceleration Whiplash" レポート

指標	変化
PRあたりインシデント比率	+242.7%
レビューなしマージ	+31.3%
コードチャーン（書き直し率）	+861%
開発者あたりバグ数	+54%

22,000人の開発者・4,000チームの2年間の 実測データ （サーベイではありません）
PRレビュー時間の中央値が 441%増加 — PRサイズが 51%大型化
生成速度がレビュー能力を超え、検証が構造的に追いつかなくなっている ことが定量的に示されています

出典: Faros AI: The AI Engineering Report 2026 - Ten Takeaways / AI is making engineers faster. So why does delivery feel slower?

現場で語られている「2つの落とし穴」

定量データの裏側で、AI活用が進んだ多くの現場で共通して語られているパターンが2つあります。特定の企業の話ではなく、 一般的な兆候 として紹介します。

落とし穴①: AIの出力を鵜呑みにして脆弱性が混入する

自然言語から一気にアプリを生成できるノーコード／ローコード系のAIツールが普及した結果、生成されたコードを 誰も精査しないまま本番に投入される ケースが増えています。生成されたコードは見た目こそ整っていますが、認証・認可・データアクセス制御まわりの設定が抜け落ちていることが多く、外部の調査では「AI生成アプリの過半数に何らかのセキュリティ問題」「相当数で重大な脆弱性」が観測されています。共通するのは 「動いているように見える」ことと「安全であること」が一致しない 点で、しかもその多くは既存のSAST/DAST/Linterで検出可能だったものばかりです。

落とし穴②: AI生成コードが承認プロセスをすり抜ける

もう1つは、レビュー体制を整えていても AI生成コードが承認プロセスを実質的に迂回してしまう 問題です。「2名の承認が必須」のような運用ルールを敷いていても、人間レビュアーが大量のAI生成PRを捌ききれず、「形だけ承認ボタンを押す」レビューが増えていきます。さらに「AIが書いたコードなので大丈夫だろう」というバイアスが乗ると、形式上は承認されたが実質的には検証されていない変更が本番に流れ込みます。先のレポートで「レビューなしマージが+31.3%」となっているのは、まさにこの構造を定量化したものと言えます。

この2つを合わせると、見える構造はシンプルです。 生成は速くなったが、検証は遅いまま 、もしくは 形だけの検証になってしまっている 。これが冒頭で挙げた「インシデント比率+242.7%」を生んでいる根本原因だと考えています。

なぜ起きるのでしょうか？：検証の不適切さという共通点

ここまでに見てきた構造をもう少し抽象化してみます。共通しているのは、コードを作る側(Generator)の速度が上がったこと自体ではなく、 検証する側(Evaluator)が「そのタスクに対して不適切な状態」で動いていた ことです。

一方では、検証に必要な知識を持つ人もツールも介在せず、生成物がそのまま本番に届いていました
もう一方では、形式上のレビューはあるものの、AI生成PRの量に飲まれて判断基準が機能していませんでした
業界全体のデータが示すのも、PRが大型化しすぎてレビューが構造的に追いつかない、という同種の現象です

ポイントは「自動化したから安全」でも「人間がやれば安全」でもないことです。 適切な知識と判断基準を持たないままの検証は、自動でも手動でも事故になります 。逆に言えば、検証側が「そのタスクに必要な視点」を備えていれば、Generator側がAIであっても問題は起きにくくなります。

Generator-Evaluator という整理

このとき有効なのが、 Generator(作る側)とEvaluator(検証する側)を分けて考える 整理です。これは私が独自に唱えるものではなく、Anthropicが "Harness design for long-running application development" で示している3エージェント構成(Planner / Generator / Evaluator)でも使われている語彙で、より一般化したパターンとして同社の "Building effective agents" でも Evaluator-optimizer ワークフローとして紹介されているものです。本記事ではこれを主役というよりは 「適材適所を考えるための整理軸」 として使います。

	よくある状態	望ましい状態
Generator	AIが高速にコードを書く	同じくAIが高速にコードを書く
Evaluator	人間が一手に検証 → 量に飲まれる／観点を持てない	タスクの性質に応じて、機械的検証・AI検証・人間判断を使い分ける

つまり、Evaluatorをどう「正しく分担するか」が肝になります。これを整理するのに役立つのが、次に紹介するハーネスエンジニアリングの考え方です。

ハーネスエンジニアリングという考え方

ここで枠組みとして「ハーネスエンジニアリング」という考え方を紹介します。これはBöckeler氏（ThoughtWorks / martinfowler.com）が "Harness engineering for coding agent users" で提唱しているもので、AIエージェントの設計論として整理しやすい枠組みです。

エージェント = モデル + ハーネス

エージェント = モデル + ハーネス
ハーネスとは、AIモデル以外のすべて——ツール・制約・フィードバックループ・ドキュメント——の総称

Böckeler氏はハーネスを ガイド（フィードフォワード） と センサー（フィードバック） の2軸で整理しています。本記事ではこれを実務に落とすため、 センサーを「ガードレール」と「可観測性」に分解した独自の3軸 で再整理してみます（原典の2軸の言い換えではなく、運用視点での再構成です）。

ガイド（フィードフォワード）	ガードレール（センサー：フィードバック）	可観測性（センサー：フィードバック）
AIへの入力品質を上げる	AIの出力を検証してその場で差し戻す	検証結果や挙動を計測・可視化して改善にフィードバック
CLAUDE.md構造化、アーキ仕様書、コーディング慣行、スキル整備	テスト・Linter・SAST、LLM敵対的レビュー	テスト通過率・AIコスト、エージェント成功率

ガードレールも可観測性も、Böckeler氏の整理では同じ「センサー（フィードバック）」に位置づけられます。本記事では、 「その場で止める/差し戻すもの」 と 「蓄積して改善ループに使うもの」 を分けて扱うために2つに割っています。可観測性で得た計測データがガイドとガードレールの改善に戻る、 循環構造 になっているのがポイントです。

Evaluatorの階層構造

3軸のうち ガードレール（Evaluator） を深掘りすると、以下の階層になります。本記事の中核となる分類です。

Evaluation（検証）
├── by Machine（機械による検証）
│   ├── Computational（アルゴリズムで解決できる検証）
│   │     Linter / Formatter, Unit Test / SAST, CI/CD パイプライン, Script / CLI
│   └── Inferential（LLMで初めて可能になった検証）
│         設計レビュー, 敵対的コードレビュー, 未知の脆弱性探索, セマンティック問題検出
└── by Human（責任・ビジネス判断が伴う検証）
      本番デプロイ承認, アーキテクチャ決定, インシデント対応, 例外的状況の判断

Computational（計算的） と Inferential（推論的） と Human（人間） の3階層に分けて、「何を任せるか」を考える——これが本記事の中心となる視点です。

適材適所マップ：Evaluatorの性質で振り分けましょう

どのEvaluatorに任せるべきでしょうか？

その検証、機械で実行できますか？
├── Yes → アルゴリズムで解決できますか？
│   ├── Yes → Computational（Linter, UnitTest, SAST, CI/CD, Script）
│   └── No  → Inferential（設計レビュー, 敵対的レビュー, 未知脆弱性探索）
└── No  → Human（本番承認, アーキ決定, インシデント対応）

どのケースでもAIは活用できます。違いは 「AIに何を作らせるか」 です。

ケース1: Computational Controls

ルールで書けるなら、LLMを使う理由はありません

タスク	具体例	LLMに任せると？
Linter / Formatter	コード規約を100%機械的に適用	ファイルごとにスタイルが異なる可能性
Unit Test	同一条件で毎回同じ結果	「前回通った」と判断してスキップする可能性
SAST（既知CVE）	既知脆弱性DBとの照合。漏れなし	確率的に見逃すことがある
CI/CD	ビルド・テスト・デプロイを自動化	非決定性により成果物が変わりうる
Script / CLI	入出力が決まった処理を確実に再現	実行のたびにフォーマットが揺れることがある

コストの観点: Linterは秒で無料です。同じチェックをAI（LLM）でやるとトークンコストが発生し、速度も劣ります。

実行タイミングがカギ: IDE内で秒で検出 → push前にhookで検証 → push後にCIで網羅チェック。 ローカルでサクサク回せるのが最強 です。

AIの出番: Linterの ルール自体を書かせましょう （Semgrepカスタムルール等）。AIが直接コードを書くより、AIが書いたルールで人間が書いたコードを検査する方が、はるかに安全で再現性があります。

ケース2: Inferential Controls

LLMで初めて可能になった検証を活かしましょう

タスク	なぜLLM？	Computationalだと？
設計レビュー	暗黙の品質基準を文脈で評価	Linterは「長い」とは言えるが「どう分けるか」は言えない
敵対的コードレビュー	生成AIと文脈を切り離した別AIが検証	ルールベースでは意図の矛盾を検出できない
未知の脆弱性探索	既知DBにないパターンを推論で発見	SASTは既知パターンのみ
テストケース生成	受け入れ基準からテストを自動生成	仕様の行間は読めない
PR要約・影響分析	数十ファイルの差分から意図を要約	`git diff --stat`ではファイル一覧しか出ない

コスト注意: Inferentialはトークンコストが高いです。Computationalで解決できるものを先に自動化するのが鉄則です。

Evaluatorも万能ではない: AIレビューの指摘が的外れなことも多いです。別のAIにレビュー結果を精査させ「対応すべきか」を仕分けるとフィードバックの質が上がります。

ケース3: Evaluation by Human

責任を伴う判断は、引き続き人間が担いましょう

タスク	なぜ人間？	AIに任せると？
本番デプロイ承認	ビジネス状況との総合判断	事業コンテキストを把握しきれない可能性
インシデント対応	法的・ビジネス的判断	組織固有の事情を知らない場合がある
アーキテクチャ決定	チームスキル・組織戦略との整合	技術的最適解とチーム的最適解は異なることがある
例外的状況の判断	前例がない状況での意思決定	一般論に寄りがち

例：PRレビューの進化形
大まかなレビューはAIが実施し、過去の失敗やインシデントから 「人間が見るべき観点」 をAIが抽出・提示 → 人間はそこだけ判断する。さらに、 その観点リストを組織がメンテナンスし続ける ことで、ハーネスのフィードバックループが回り続けます。

判断フレームワーク

あなたのタスク、どこに置きますか？

実務で迷ったときに使える、シンプルな問いの並びです。

問い	Yesなら	AIの関わり方
アルゴリズムで解決できる？	→ Computational	AIにルール・パイプライン・スクリプトを書かせましょう
文脈・推論が必要？	→ Inferential	AI（LLM）にレビュー・分析させましょう
責任・ビジネス判断が伴う？	→ Human	AIに判断材料をまとめさせましょう

ポイント: どのケースでもAIは活用できます。違いは 「AIに何を作らせるか」（成果物） と 「AIに直接やらせるか」（推論） です。

判断マトリクス

各レイヤーの強み・弱みを並べて比較するとこうなります。Human列は 「その道の第一人者がベストコンディションで臨んだ場合」を想定した一意見 として読んでください（実際には経験・状況・分野などで大きく変わる前提です）。

観点	Computational	Inferential	Human（その道の第一人者を想定）
決定性	◎ 同一入力→同一結果	△ 確率的	△ 状況依存
再現性	◎ 完全再現	△ 揺れあり	× 属人的
実行コスト	◎ 低い	△ LLM利用料	× 人件費
速度	◎ 秒〜分	○ 分〜時	× 時〜日
文脈理解	× ルール内のみ	○ 推論可能	◎ 暗黙知・経験で補える
未知への対応	× 既知パターンのみ	○ 類推可能	◎ 前例のない状況でも判断可能
監査性	◎ ログ完全	△ 説明性に課題	○ 記録次第

戦略はシンプルです。 Computationalで解決できるものを先に自動化 → Inferentialは「ルールにできない領域」に集中 → Humanは「責任を伴う判断」に集中 、これに尽きます。

まとめ

「AIに適切な成果物を作らせましょう」

Computational — AIにルール・パイプライン・スクリプトを書かせましょう
Inferential — AIに直接レビュー・分析させましょう（ただしコスト意識を）
Human — AIに判断材料をまとめさせて、人間が決めましょう

AI活用の本質

AIエージェントやスキルが増えてきた今、 「全部AIに任せる」が最適解ではありません 。同時に、 「AIに任せず人間が見れば安全」も幻想 です
本記事の核は、タスクの性質に応じて Evaluatorを適切なレイヤー(Computational / Inferential / Human)に振り分ける ことです。Generator-Evaluatorという語彙は、その 適材適所を整理するための補助線 として使っているにすぎません
適材適所マップを実務に落とすときに、本記事では3軸の整理を補助線として使いました（Böckeler氏のガイド/センサー2軸を、運用視点で「ガードレール」と「可観測性」に分けた独自整理です）
- ガイド でAIの入力品質を上げる(プロジェクトドキュメント、コーディング規約、スキル定義)
- ガードレール で出力をその場で検証・差し戻す(Computational→Inferential→Humanの順で組み合わせる)
- 可観測性 で改善ループを回す(成功率、コスト、インシデント率を計測してガイドとガードレールに反映)