GitHubのトレンドやShow HNで見つけたツールを紹介するとき、「実際に触ってみた」の一言が乗るかどうかで記事の信頼感は大きく変わる。ではその「触ってみた」を、LLMエージェントに自動化させたらどうなるか。

本稿は、この自動化を毎日稼働するpipelineとして実装して1週間以内に実ツールで完走させた設計のうち、環境に依存しない部分を抽出したものである。結論を先に言うと、技術の中心はLLMの操縦ではなく「LLMに何を判定させないか」の線引きである。

丸投げすると壊れる — 3つの型

LLMエージェントに「このツールを試して感想を書いて」と丸投げしたとき、壊れ方は3つに整理できる。

偽の成功報告: エージェントは「起動しました」「動作しました」と書くが、実際には起動に失敗している。「成功した」という文章は生成できてしまう。この種の偽陽性は、レポートが整っているだけに発見が遅い
実行環境の汚染: 試用対象はインターネットで見つけたコードである。setupスクリプトが何をするか分からない状態で、ホストのシェルでnpm installを走らせるのは賭けである
一次系の破壊: 試用結果を紹介文へ自動反映すると、試用側のbugがそのまま公開文章に波及する。自動化した側が最初に踏む地雷はここである

つまり必要なのは「操作はLLMに任せるが、成功の判定・実行の場所・失敗の伝播の3点は人間の設計が握る」構成である。以下、その4原則を述べる。

設計 — 4原則

原則	内容	防ぐもの
1. 検証は決定的に	LLMは計画と操作のみ。成功判定はコードが行う	偽の成功報告
2. 使い捨てsandbox	発見コードは隔離containerの中でのみ実行	実行環境の汚染
3. fail-open	試用の失敗は一次系に伝播しない	一次系の破壊
4. 証拠契約	レポートは構造化JSON+スクショ+動画で固定	根拠のない感想文

原則1 — 検証は決定的に (LLMに判定させない)

LLMに任せるのは、(a) どう操作するかの計画、(b) 操作の実行、(c) レポートの文章化である。任せないのは成功判定である。

web UIツールの場合、2段に分ける。まず無録画の計画段階でDOMの候補と初期スクショを渡し、操作planをJSONで出させる — クリック対象・入力値・各stepの検証条件 (期待URL・期待文字列のような、実行後に機械的に確認できるもの) を含む形である。次の録画段階でそのplanを実行し、各stepの検証条件をコードが判定する。planが棄却されたら修正を3回まで再要求し、それでも駄目なら途中経過のbestを採用する。

成功の基準は、exit code・port probeの応答・期待文字列の存在のような決定的な条件だけである。エージェントが「うまくいきました」と書いたことは、検証条件の1つに数えない。実際の稼働でも、レポートの事実行には操作記録の番号を付け、文章の各行がどの操作に根拠を持つか照合できる形にしている。根拠を引きにくい感想は、そもそも書かせない方が安全である。

原則2 — 使い捨てsandbox

試用対象のコードは、使い捨てのDocker containerの中でのみ実行する。契約は次のとおりである (検証日: 2026-09-06・Docker 29)。

docker run -d --network <隔離bridge> --dns 1.1.1.1 \
  --memory 2g --memory-swap 2g --cpus 1.5 --pids-limit 256 \
  --security-opt no-new-privileges --cap-drop ALL --user 1000:1000 \
  --tmpfs /tmp:rw,exec,size=512m \
  --publish 127.0.0.1::3000 --publish 127.0.0.1::5173 \
  <専用image> sleep infinity

要点は3つである。第一にhost volumeをmountしない・秘密を入れない。containerがどれだけ汚れても、捨てれば済む。第二にnetworkは外向きだけ許す。隔離bridge宛ての通信はhost側のfirewall規則で遮断し、npm registryやGitHubへの接続は可、hostのLANや他サービスへの接続は不可、と方向を固定する。第三に資源と寿命の上限である。memory・pids・CPUに上限を置き、全体で12分の壁時計timeoutを過ぎたら無条件でkillし、containerを残骸ごと消す。正常終了時もfinally節で同じ後始末を走らせる — 「終わったのに消し忘れたcontainer」が環境を蝕むのは、手動運用でも自動運用でも同じ事故である。

コマンドの実行にはdenyリストの関所を通す。sudo・ホームdirectory外への大量書込・disk直叩き・fork bomb・docker socket触媒のような類を弾き、このリストはテストで固定する。実装を弄って緩んでいないかを、機械が毎回確認するためである。なおsetupスクリプトの類はcurl | sh形式が多く、これ自体は許可する — 使い捨て・非root・capabilityなし・network隔離の4条件で償っている。許可の根拠を契約の側に置くのが、禁止リストを運用する基本の構えである。

原則3 — fail-open (試用の失敗は一次系に伝播しない)

pipelineの出力は一次系 — ここでは紹介文のdraft — へ反映するが、反映moduleが失敗しても一次系は無傷を貫く。試用に失敗したら、紹介文は自動試用を入れる前の状態のまま使われる。失敗は常にあり得る前提で設計する。

これも検証で示した。再起草moduleをわざと必失敗に差し替えて回しても、一次系のファイルはbyte単位で不変だった。sandboxを実行不可にした場合も同じである。fail-openは「例外を握りつぶす」ことではなく、「一次系の状態を試用前の値に保つ」ことである。だから一次系のdraftには常に、試用なしで成立する本文が先に存在している。

原則4 — 証拠契約

レポートは自由文にしない。schemaを持つJSON (状態・種別判定・setup記録・操作記録・検証結果・摩擦のlist) を正本とし、人間が読むmdはそこから描画する。証拠は操作スクショと録画 (web UIの場合) をstep番号付きで保存し、JSON内の各事実行がどの操作記録に当たるか追える形にする。

副次効果として、誇張の機械検査が効く。レポートの文章に最上級の宣伝語が入ると、一次系と同じ禁止語検査で弾かれ、その行は採用されない。AI生成文の誇張は、生成後に言葉で削るより、通過条件にしてしまう方が維持できる。

失敗パターン

実装と稼働で起きた・防いだ失敗を、記録側と運用側に分けて挙げる。

記録で壊す:

crash前の成果物を完成扱いにする: 実行が途中で死ぬと、前回の中途レポートが「ある」ように見える。開始時にincompleteの印を書き、完成時にのみ判定を書く方式にすると、中途物は自動的に無効になる
LLMの文章をそのまま事実にする: 「起動しました」は事実ではない。exit codeとprobe応答が事実である。レポートの事実行は機械可読な検証結果からのみ生成する
根拠照合のない感想: どの操作を見てそう言ったのか引けない行は、後に訂正も検証もできない

運用で壊す:

後始末を成功経路にだけ置く: timeout・LLM破綻・docker異常のどの経路でもcontainerが消えるように、後始末はfinallyに置く。孤児containerは気づかないうちにdiskとportを握る
再実行の無条件化: 毎朝全対象を再試用すると、時間とAPI費用が際限なく増える。過去に成功・部分成功した対象はskipするresumeを入れる
一次系への直接書込: 試用側が一次系のファイルへ直接触ると、fail-openが保てない。一次系への書き手は反映moduleただ1つに限定する

実測

この構成で、公開OSS 2件を通している。web UIツール1件 (Vue製のicon picker) は、cloneから起動・操作・検証・レポート生成・録画まで自動で完走し、操作スクショ4枚と動画1本、終了後のcontainer残骸0件だった。CLIツール1件 (Node.js製の速度計測ツール) はREADME由来のコマンド候補を順に試し、exit code 0と出力文字列の両方で成功を確認した。別の3件はsetupに失敗したが、いずれもfail-openで一次系は無傷のままである。

失敗3件は無価値ではない。setupに要した時間・引っかかった工程・必要だった権限が記録されており、「試したが動かなかった」ことも構造化された事実として残る。紹介しない判断にも使える。

範囲の限りも書いておく。試用の対象は、ブラウザで操作できるweb UIとshellで実行できるCLIに限られる。libraryとして組み込んで使う型はREADMEの確認どまりで、実際に依存へ入れての評価は別の工程になる。

この設計が効く条件

発見→試用→発信を毎日回す場合に効く: 1回の調査のためなら、仮想環境を手で作ってagent sessionを1本走らせる方が早い。契約と検証のコストは、繰り返しで償却できるときだけ払う価値がある
試用対象が大量に流れてくる場合に効く: 全件を人間が触るのは不可能なとき、機械の一次ふるい+人間の確認という分担が成立する
LLMの操縦技術が主役ではない: 驚くべき操作は要らない。淡々とplan通り押して、検証をコードで通す。agentに求めるのは安定であって、賢さではない

自動試用の価値は「AIがすごい」ことではなく、触った事実と証拠の紐付きを機械の規律で保てることにある。LLMが操作し、コードが検証し、失敗が一次系を壊さない — 業務効率化として残るのは、この3つの線引きである。

なお、海外AI製品を日本語業務に入れる前の導入前確認 (実地試用の設計を含む) はJapan LaunchOpsで請け負っている。相談は日本語AI評価のページで受け付けている。