AIエージェントに8,000字の記事を書かせて投稿させると、更新1回ごとに本文を2回書き写すのと同じコストがかかります。原因は、テキストが「トークン」としてエージェントの出力を毎回通過することです。データの通り道をエージェントの外に出せば、送る指示は本文の大きさに関係なく数行で済みます。今日は、Zenn AIに投稿された技術記事を題材に、この落とし穴が中小企業のAIエージェント活用にとって何を意味するのかを読み解きます。
なお当社（株式会社TOE / AIの鬼）は、AI導入支援やAI検索対策を売りうる立場です。利害のある発信であることを最初に明示しておきます。
何が起きたのか
素材の筆者は、AIエージェント（Claude Code + ブラウザ拡張）に技術記事を Zenn へ投稿させようとしました。ところが Zenn には公式MCPも公開の書き込みAPIもないため、投稿はエディタをブラウザで操作する形になります。Zenn のエディタは CodeMirror ベースで、外部から文字を入れる手段は実質「ページ上で JavaScript を実行する」しかありません。
素直に実装すると、本文を JavaScript の文字列リテラルとして丸ごとコードに埋め込むことになります。動きはします。しかし記事の全文がエージェントの出力を経由するため、更新のたびに致命的に遅くなった、というのが起きたことです。今回は公開済み記事に追記・修正を3回繰り返す必要があり、その回数ぶんコストが積み上がりました。
なぜ遅いのか ― 本文がエージェントの出力を2回通る
素材が挙げているのは、8,000字の記事を1回更新するときの内訳です。
- エージェントがファイルを読む（8,000字ぶん消費）
- エージェントが JavaScript コードとして書き出す（もう8,000字ぶん消費）
つまり1回の更新で記事2本分を書き写しているのと同じことになります。誤字修正のような小さな差し替えでも、本文全体が再送されます。さらに、バッククォートやバックスラッシュのエスケープ事故も起きやすい、と素材は指摘しています。
ここで効いているのは、AIエージェントがテキストを「トークン」として数える、という根本的な制約です。大量テキストを流し込むほどトークン消費が増え、コストも時間も膨らみます。これは個人開発やスタートアップに限らず、大きな文章をエージェントに扱わせるすべての業務で起きる現実的なボトルネックです。
回避策と正攻法
素材が示す解決策は、データの通り道をエージェントの外に出すことです。ローカルに使い捨ての HTTP サーバ（127.0.0.1:8899）を立て、ブラウザ側に本文を直接 fetch させます。本文はあらかじめ base64 にしておくと、改行やクォートのエスケープ事故が原理的に起きません。ページ側で実行する JavaScript は数行で済み、本文が何KBでもその数行は変わりません。
素材は実装上の要点を3つ挙げています。
insertTextを使う：textContentへの直接代入では CodeMirror の内部状態が更新されず、保存しても反映されません。execCommand('insertText')はキーボード入力と同じ経路を通るため、エディタが変更を検知します。- base64 を挟む：UTF-8 の日本語・改行・記号すべてがエスケープ不要になります。デコードは
TextDecoderで行います（atobだけだとマルチバイトが壊れます）。 - CodeMirror は仮想スクロール：
innerTextで検証すると画面内の行しか取れません。確認するならスクロールしながら覗くか、保存後に公開ページ側で確かめます。
そして素材は、終わったらサーバは必ず落とすこと、そして「そもそもの正攻法は GitHub 連携」であることを明記しています。Zenn はリポジトリに Markdown を置いて push すれば公開されます。ブラウザ操作もこのトリックも要りません。有志製の zenn-mcp（Zenn CLI を MCP ツール化したもの）を使えば MCP 経由で完結させることもできます。ブラウザ操作が必要になるのは、すでに Web エディタで公開してしまった記事の本文を差し替えたい、といった限られた場面だけです。
| 方法 | エージェントを通るテキスト量（更新1回） | エスケープ事故 | 向いている場面 |
|---|---|---|---|
| 本文を JS 文字列に直書き | 本文2回分（読む＋書き出す） | 起きやすい | 短いテキストの一発投入 |
| ローカルHTTPサーバ + fetch | 数行の指示だけ（本文サイズと無関係） | base64で原理的に回避 | 公開済み記事の本文差し替え |
| GitHub連携 / zenn-mcp | ファイルを書いて push | なし | 新規に書く場合の正攻法 |
中小企業にとって何が変わるのか
これは一見、技術者向けの細かい話です。しかし中小企業がAIエージェントを業務に入れるときにも、同じ判断が効きます。
素材が最後に言い切っているのは、「公式MCPやAPIがあるならそちらが常に速い。ブラウザ操作は最後の手段」という順序です。裏返すと、大量テキストを扱う業務ほど、公式ツール化・API化されたソリューションを探す価値が高いということです。自前でエージェントに指示を出して画面を操作させる方式は、短い入出力の業務に留めておくのが現実的です。
具体的には、次のように切り分けられます。
- クリック・短い入力・ページ読み取りといった通常の操作は、ブラウザ拡張をそのまま使えば十分です。
- 数KB以上のテキスト投入のときだけ、データがエージェントの出力を通過しない経路（今回ならローカルHTTPサーバ + fetch）を用意します。
- 新規に文章を作って外部サービスへ載せるなら、GitHub 連携のように「ファイルを書いて push するだけ」で済む正攻法を先に探します。
同じ発想は、AIエージェントにAPIキーや機密を渡すかどうかの設計判断とも地続きです。「エージェントの通り道に何を流すか」を最初に決めるという点で共通しています。値そのものをエージェントに見せない設計についてはAIエージェントに「キー名だけ」渡す設計は成立するのか ― trustlessが値を見せない一点に絞った理由を、トークン従量でコストが変動する構造そのものについてはAIコンピュート費用が「固定」から「変動」へ──GPU先物市場が動き出すと中小企業のAIコスト計画はどう変わるのかを、あわせてご覧ください。
当社の実測と突き合わせると
当社（AIの鬼）も、記事を毎日、人手を介さず自動生成しています。2026-08-27時点で、収集済みニュース3000件・自社要約つきニュース1727件・本文取得済み833件・記事264本を機械的に回しています。記事は1本あたり平均約4031字で、素材が問題にした8,000字級の文章を日常的に扱う規模です。
それでも、運用中のAI API課金は0円です。社内業務の自動化は27本動いていますが、トークン従量課金で膨らむAPIには依存していません。この一点は、素材の「大量テキストほどトークン消費とコストが膨らむ」という指摘と符合します。文章の量に比例してコストが増える経路を、そもそも運用の中心から外している、という状態です。
ただし、当社はZennへの投稿そのものを題材にしていないため、Zennでこの手法を使ったときの速度やトークン消費は測っていません。素材の言う「記事2本分」も、当社が実測した秒数や課金額ではなく、素材の中の文字数ベースの比喩です。ここは正直に線を引いておきます。
この記事で言えないこと
- 素材は「記事2本分」という文字数ベースの比喩を出しているだけで、更新1回あたりの秒数・トークン数・課金額の実数は示していません。何倍遅い、何円かかる、といった数字は素材からは分かりません。
- ローカルHTTPサーバ（
127.0.0.1限定・使い捨て）のセキュリティ上の妥当性を、当社は第三者検証していません。 zenn-mcpの安定性や、Zenn以外のサービスで同じ手法が通用するかは、素材からは分かりません。- 当社はZennへの投稿速度・トークン消費・API課金額を測っていません。「API課金0円」は当社の運用全体の実測であり、Zenn投稿の話ではありません。
- 効果や削減幅の保証はできません。ここに挙げた切り分けが読者の環境で必ず速くなるかは、実測しない限り分かりません。
まとめ
- Zenn には公式MCPも公開の書き込みAPIもなく、AIエージェントに投稿させるとエディタのブラウザ操作になります。本文をJS文字列に直書きすると、更新1回で本文がエージェントの出力を2回通り、記事2本分のコストがかかります。
- 回避策は、データの通り道をエージェントの外に出すことです。ローカルHTTPサーバ + fetch なら、送る指示は本文サイズに関係なく数行で済み、base64を挟めばエスケープ事故も原理的に消えます。
- 新規に書くなら正攻法は GitHub 連携（または
zenn-mcp）で、ブラウザ操作は公開済み記事の差し替えなど最後の手段に限られます。 - 中小企業がAIエージェントを使うなら、大量テキストの業務ほど公式API・公式ツールを先に探し、自前の画面操作は短い入出力に留めるのが現実的です。
- 当社は平均約4031字の記事を毎日自動生成しつつAI API課金0円で回していますが、Zenn投稿の速度やコストは測っていません。数字は測った範囲でのみ言えます。
この記事は、Zenn AI「AIエージェントにZennへ記事を書かせると遅い ― ローカルHTTPサーバ経由で本文を流し込む」を素材に、当社（株式会社TOE / AIの鬼）の記事生産量・AI API課金額（2026-08-27時点の自動集計）の実測とあわせて書きました。
