AI エージェント（Claude Code や CLI Agent 等）を活用して業務の自動化や省力化を進めていると、ある段階で必ず「プロンプト調整の泥沼」に直面します。

「指定したフォーマットだけを出力してほしい」 「1 文字もブレずに正確にファイルに転記・抽出してほしい」

そう考えてプロンプトに「余計な解説を挟むな」「型の指定を厳密に守れ」と指示を重ね、失敗するたびに再試行を繰り返す。しかし、コスト削減や省力化のために導入したエージェントなのに、プロンプト修正とやり取りの往復によって、かえって時間とコストが奪われている感覚はないでしょうか。

なぜ簡単なファイル出力や文字転記でエージェントは失敗するのか。結論から言えば、問題はタスクの大きさや難易度ではなく、「非決定論的な生成」と「決定論的な転記」を同一のモデルに直接やらせようとしていることにあります。

本記事では、AI エージェントへの委譲における失敗パターンを紐解き、委譲の損益分岐点を明確に切り替える設計思想と実用的なアプローチについて解説します。

委譲のアンチパターン: エージェントに逐語転記・直接変異を任せるリスク

エージェントに対して、ファイル変異（直接書き換え）や逐語転記、文字起こし・データ抽出などの「100%の逐語一致が求められる作業」を直接任せることには、技術的に大きな 2 大リスクが存在します。

1. 安全分類器による実行ブロック（Blocked by classifier）

Headless 環境や自律型 CLI エージェントでファイルを直接書き換えるシェルコマンド（sed -i やリダイレクトによる上書き等）を実行させようとすると、セーフティ分類器（Safety Classifier）が破壊的操作と判定して処理をブロックする現象が発生します1。プロンプト側でこれを迂回しようとすると、指示が複雑化してプロンプトインジェクション風の構造になり、悪循環に陥ります。

2. ステータス SUCCESS の裏に潜むサイレント失敗

エージェントのツール呼び出しログ上は {"status": "SUCCESS"} と正常終了を返しているにもかかわらず、実際には対象ファイルが生成されていない、あるいは空ファイルが置かれたまま終了する「サイレント失敗」が発生することがあります1。エージェント側のコンテキスト処理やツール応答の解釈における勘違いにより、最終的な永続化処理がスキップされてしまうためです。

確率的モデル単体に逐語一致を求める限界

OpenAI が Structured Outputs を導入した背景にも見られるように、確率的テキスト生成モデル（LLM）単体では、1 文字のブレもない完全な逐語一致や型定義の厳密な保全を安定して出力させることは極めて困難です2。LLM は「文脈に沿って最も確率の高いトークンを予測する」本質を持っているため、決定論的なデータ転記とは根本的に得意領域が異なります。

損益分岐点を見極める: 「生成」vs「転記」

では、エージェントにどこまで任せ、どこからをシステム側で処理すべきでしょうか。委譲の損益分岐点は「タスクのコード行数」や「タスクの規模」ではなく、「処理の本質が生成（非決定論）か転記（決定論）か」 で切るのが正解です。

Anthropic の Building Effective Agents においても、自律型エージェント（Agents）と決定論的コードパス（Workflows）の明示的な分離が推奨されています3。

区分生成（LLM に委譲すべき領域）転記（決定論的コードに委譲すべき領域）
処理の本質非決定論的（意図解釈、要約、未知構造の理解、ロジック設計）決定論的（100% 逐語一致抽出、型変換、ファイル変異、ステータス検証）
期待する成果文脈に応じた柔軟な発想・コードの自動生成完全に再現可能なバイト単位の確実性
失敗時の影響軽微な表記ゆれ（後段補正やレビューで吸収可能）サイレント失敗、分類器ブロック、データ破損
コスト構造推論トークンコスト（付加価値を生む）再試行・プロンプト修正往復（無駄なオーバーヘッド）

タスクがどれだけ小さくても（例: 1 行の文字列を JSON の型に合わせて転記するだけ）、決定論的な処理を LLM に直接やらせると確率的揺らぎのリスクが残ります。逆にタスクがどれだけ大きくても（例: 数百行の処理スクリプト全体を新規作成させる）、それがロジックの「生成」であれば、LLM は最大のパフォーマンスを発揮します。

解決策: エージェントに「転記」させるな、「転記スクリプト」を書かせよ

この問題を解決する設計パターンが 「LLM on Scripter」（エージェントに直接転記させず、転記スクリプトを書かせて実行させる）アプローチです。

1486 記事での逐語一致率 100% を達成した実証データ

当リポジトリの一次検証ログにおいて、過去のブログ記事（全 1486 記事）からフロントマターや特定メタデータを自動抽出・照合する処理を実施しました1。

当初、LLM に対して直接ファイルを読み込ませてデータを抽出・ファイル保存させようとしたところ、無応答や前述のコマンドブロックが発生しました。そこで役割分担を変更し、「LLM に抽出・転記を行う Perl スクリプト（extract-posts.pl）を書き出させ、実行と検証は決定論的な実行環境側で引き受ける」 構成へ切り替えました。

結果として、全 1486 記事におけるデータの逐語一致率 100%（エラー・不一致 0 件）および 11 シリーズ全件の完全抽出を、例外なく即座に完走させることに成功しました1。

実務デバッグの罠: UTF-8 デコード漏れのシグネチャ

決定論的スクリプトを作成・実行する際の実務知見として、文字コードの取り扱いにおける罠が存在します。

Perl の JSON::PP モジュール等で抽出データを扱う際、明示的な UTF-8 デコード（JSON::PP->new->utf8->decode(...)）を行わずに生のバイト列のまま照合を行うと、「ASCII 文字（半角英数）のみ一致し、日本語等のマルチバイト文字が含まれると全滅する」という症状が発生します1。

# ❌ 誤り: UTF-8 デコードを行わず生のバイト列で比較（ASCII しか一致しない）
my $data = JSON::PP::decode_json($raw_json);

# ⭕️ 正解: 明示的に utf8 オプションを適用して Unicode 文字列として比較・検証
my $json_engine = JSON::PP->new->utf8(1);
my $data = $json_engine->decode($raw_json);

「ASCII 文字だけ通って日本語が落ちる」現象を見かけた場合は、プロンプトの不備を疑うのではなく、スクリプト側のデコード漏れを疑うのがデバッグの第一歩です。

まとめ: 堅牢な AI Operations へのステップ

AI エージェントを業務に組み込む際は、以下のチェックリストで役割分担を再設計することをお勧めします。

  1. その作業は 100% 同じ出力が求められる「決定論的処理」か？ → Yes であれば、エージェントに直接実行させずスクリプト化する。
  2. エージェントには「ロジック（コード）の生成」を行わせているか？ → エージェントの役割を「転記作業者」から「スクリプト執筆者」へ昇格させる。
  3. ファイル変異や型検証は決定論的実行環境側に閉じているか？ → 分類器ブロックやサイレント失敗を防ぐため、実行権限と変異処理をレイヤー分離する。

エージェントに逐語転記を行わせるのをやめ、スクリプトを書かせる側に回すことで、プロンプト調整の泥沼から抜け出し、きわめて高い再現性と生産性を両立できます。

AI エージェントを活用した業務プロセスの自動化や、堅牢な Agentic Workflow の設計・運用でお困りの方は、ぜひ コンタクトフォーム よりご相談ください。

Footnotes

  1. 当リポジトリの一次検証ログ ↩ ↩2 ↩3 ↩4 ↩5

  2. OpenAI - Introducing Structured Outputs in the API ↩

  3. Anthropic - Building Effective Agents ↩