AIエージェントは「段取りが自明な作業」では効かない ― 固定手順と実測で比べた

「AIエージェントを入れれば効率化できる」——最近いちばん多く聞く言葉です。AIが自分で段取りを決めて複数の道具を順に使う仕組みは、たしかに強力に見えます。ただ、それが「効く作業」なのかどうかは、作る前には分かりません。効く前提で組んでしまってから「実は要らなかった」と気づくのが、いちばん高くつきます。

そこで、自動サイト診断を題材に同じ道具・同じレポート生成のまま、「調べる順番を誰が決めるか」だけを変えた2方式を作り、実測で比べました。方式Aは人が書いた固定手順、方式BはAIが段取りを決めるエージェントです。先に結論を書くと、自社5サイトで試した範囲では、AIが決めた段取りは人が書いた手順と実質同じで、時間だけ1.9倍・費用だけ2.0倍になりました。この記事は「エージェントを作った自慢」ではなく、エージェント化が効く作業・効かない作業を実測で切り分けた記録です。決済者向けの要約版は 実績ページの事例（AIエージェントが効く場面、効かない場面を測る） にあります。

題材：URLを渡すと自動でサイトを診断する

作ったのは、URLを渡すと調べる項目を選んで順に実行し、平易な診断レポートにまとめる仕組みです。7つの道具はすべてプログラムが実測し、AIは「どれを、どの順で使うか」を決めることと、結果を文章にまとめることだけを担当します。数値には一切触れさせていません。この「数値を作らせない」構造は、後の機械照合とセットで効いてきます。

道具	実測する内容
ページ取得	HTTPステータス・最初の反応までの時間・合計時間・転送量・リダイレクト
SSL証明書	有効期限・発行者（openssl で実際に接続）
ドメイン	有効期限（whois）
SEO基本	title / description / h1 / canonical / 構造化データ / robots / sitemap
リンク切れ	内部リンクの死活（上限25件・300ms間隔）
法令表記	プライバシー / 特商法 / 規約 / Cookie / 会社情報への言及
セキュリティヘッダ	HSTS・CSP など6種の有無

先に断っておくと、この診断で測っているのは1回のページ取得の応答時間までです。表示速度の指標（Lighthouse / Core Web Vitals）や表示崩れの検出は実装していません。「自動でサイトを診断する」以上のことは、この記事では言いません。

動かす前に、止め方を4つ決めた

AIに段取りを任せる＝AIが選んだ道具を自動で実行する、ということです。実行する前に止める仕組みを先に握っておく必要があります。実装より先に、次の4つを固定してから動かしました。

歯止め	中身
対象ホスト	ホワイトリスト。自社サイト以外は実行を拒否
道具	ホワイトリスト。AIが知らない名前を返しても実行されない
回数	1診断あたりの実行上限（12回）
金額	1診断あたり50円 ＋ 月次3,000円で停止
記録	拒否した実行もログに残す（許可外を試したことが分かるように）

基盤は自前オーケストレーション（tool use の手動ループ）です。フレームワークに任せず自分でループを回すのは、まさにこの歯止めを自分の手で握るためでした。回数と金額の上限はループの中で判定するので、AIが何を返そうと上限で止まります。

結果：使う道具も順番も、AIと人でほぼ同じだった

自社5サイト（analyzegear.co.jp / toha.jp / noimi.jp / shirugear.com / zennankan.com）を、2方式で診断しました。道具もレポートの作り方も同じで、違うのは「調べる順番を誰が決めるか」だけです。

	使った道具	所要	うちAIが考えた時間	コスト
固定順（人が書いた手順）	7個	35.1秒	21.0秒	3.05円
エージェント（AIが決める）	7個	67.0秒	53.7秒	5.95円

ポイントは中身です。AIは5サイトすべてで7つの道具を全部使いました。省略も追加もありません。順番もほとんど同じでした。

analyzegear.co.jp   取得 → SSL → ドメイン → SEO → ヘッダ → 法令 → リンク
noimi.jp            取得 → SSL → ドメイン → SEO → ヘッダ → 法令 → リンク
shirugear.com       取得 → SSL → ドメイン → SEO → ヘッダ → 法令 → リンク
toha.jp             取得 → SSL → ドメイン → SEO → ヘッダ → 法令 → リンク
zennankan.com       取得 → SSL → ドメイン → SEO → リンク → 法令 → ヘッダ

5サイト中4サイトで完全に同一。残る1サイトも後半3つが入れ替わっただけです。道具の実行そのものにかかった時間は、両方式ともおよそ14秒でした。差の32秒は、すべてAIが「次に何をするか」を考えていた時間です。検査時間ではありません。

ここが今回の核心です。調べる項目が7つに決まっていて、どのサイトにも同じ手順が使える作業では、AIに段取りを考えさせても人が最初に書いた固定手順とほぼ同じ結論にしかならない。にもかかわらず、その「考える時間」に時間1.9倍・費用2.0倍を払っていたことになります。段取りが自明な作業に、段取りを決める知能は要りませんでした。

数値の正しさは、機械照合で確かめた

「AIに数値を作らせない」と設計で決めても、それが守られたかは別に確かめる必要があります。レポートに書かれた数値が、道具の実測値に含まれるかを機械的に照合しました。結果は151個すべてが実測値と一致し、実測値に無い数値は0個でした。母数は5サイト×2方式＝10件ぶんの合計です。

ただし、この照合を書いていて2件ひっかかりました。「セキュリティ設定6項目すべて」「26件目以降は未確認」——どちらも算数としては正しいのに、道具が返した値そのものには無い数字です。AIが数を「数えて」いた。そこで道具側が自分の項目数（checked_count）と未確認件数（not_checked）を返すよう変えました。渡した値から導ける数字であっても、AIに数えさせず、数えた結果を渡すほうが確実です。

AIは正しかった。間違っていたのは道具のほうだった

診断が「toha.jp に会社情報が見当たりません」と報告しました。しかし実際にはフッターに「運営者情報」があります。誤報かと思って中身を見に行くと、原因は判定に使う言葉でした。法令表記チェックが「会社概要 / 運営会社 / 企業情報」しか見ておらず、「運営者情報」も「会社情報」も拾えていなかったのです。

AIは、渡された実測値を正確に伝えただけでした。ここが見落としやすいところです。

「AIに数値を作らせない」を徹底しても、渡す数値が間違っていれば、AIは正しく間違いを伝える。

ハルシネーション対策として「実測は道具、AIは言い換えだけ」という構造はよく効きます。ただそれは、実測する側が正しいことを前提にしている。検証すべきはAIだけではありませんでした。判定語を足して5サイトを測り直しています。

拒否した実行が記録されていなかった

もう1つ、テストを書いていて気づいた穴です。許可外のホストを弾いたとき、その事実がログに残っていませんでした。歯止めとしては正しく拒否できているのですが、エージェントが許可外を試したことこそ記録すべきです。許可されたことだけを記録していては、後から「AIが何を試みたか」を追えません。拒否も記録するよう直しました。

では、エージェントはどこで効くのか

今回はっきり言えるのは、効かない作業を1つ特定したことだけです。調べる項目が事前に決まっていて、どの対象にも同じ手順が使える——そういう作業では、段取りをAIに任せる意味がありませんでした。手順を1行書けば済む所に、毎回考えるコストを足しているだけになります。

裏を返せば、効くのは「何を調べるべきか事前に決められない」場面——対象によって次の一手が変わる作業のはずです。ただし、これは今回測っていません。効かない場面を測っただけで、効く場面の数値は持っていません。推測を断定で書くつもりはないので、「こういう場面では効きます」とは言えない、というところで止めます。だからこそ、次にエージェントを検討するときも同じことをします——効くと信じて組む前に、固定手順と並べて小さく測る。

他の案件にも持っていける型

• エージェント化の効果を測る型。「AIが決める」と「人が決めた手順」を、同じ道具・同じ出力のまま並べて比べる。差が段取りの質なのか、ただの実行時間なのかを分離できる。
• 数値を作らせない構造。実測は道具、AIは言い換えのみ。そのうえで本文の数値を実測値と機械照合する。設計しただけで満足せず、守られたかを機械で確かめる。
• AIに数えさせない。項目数や残件数のような、渡した値から導ける数字も、道具の側で出しておく。
• 道具の正しさを疑う。AIの出力より先に、実測する側の取りこぼし（表記ゆれなど）を疑う。AIの「間違い」は道具の間違いのサインかもしれない。
• 止める仕組みを先に置く。対象・道具・回数・金額の4つを、実装より先に固定する。拒否も記録する。

再現条件と、書いていないこと

構成	Laravel 13 / PHP 8.3 / SQLite（docker 不要）
モデル	段取り・レポートとも claude-sonnet-5
基盤	自前オーケストレーション（tool use の手動ループ）
外部依存	curl / openssl / whois のみ。APIキーは Claude だけ
テスト	21件（ホワイトリスト・拒否の記録・数値照合・法令表記の表記ゆれ・コスト計算・上限の設定漏れ）

数値の母数と条件を添えます。35.1秒 / 67.0秒、3.05円 / 5.95円は自社5サイトでの平均で、サイトの規模で変わります。151個中151個一致は5サイト×2方式（10件）の合計、32秒の差はAIが考えていた時間で検査そのものは両方式とも約14秒です。

測っていないので書けないこと。「人が手作業で調べるより◯%速い」とは書けません（人が同じ7項目を手で調べる時間を測っていないため、工数削減は主張できません）。表示速度（Lighthouse / Core Web Vitals）や表示崩れの検出は未実装で、測ったのは1回の取得の応答時間だけです。「エージェントは◯◯な場面で効く」も断定しません（効かない場面を測っただけ）。検証は自社5サイトのみで、顧客サイトに診断結果を出した実績はありません。

まとめ

「AIエージェントを入れれば効率化できる」は、作業によっては成り立ちません。調べる項目が決まっている作業では、AIに段取りを任せても結果は同じで、時間と費用だけが増えました。大事なのは、これを作る前ではなく、固定手順と並べて小さく測ったから分かったことです。エージェント化が効くかどうかは、測らないと分かりません。効くと信じて全部を組む前に、いちばん単純な固定手順を対抗馬として置く——それだけで、払わなくてよかったコストが見えます。

事例の要約（非エンジニア・決済者向け）は 実績ページ に、AI活用の他の事例は AI活用ページ にまとめています。「AIエージェントを入れれば効率化できる」とは限りません。効く場面かどうかを、小さく作って測るところからご支援します。ご相談は お問い合わせ から。