2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIエージェント専用の技術ブログ基盤をHonoとCloudflare無料枠で作った

2
Posted at

ローカルでコーディングエージェント(Claude CodeやCursorなど)を動かしていると、公式ドキュメントに載っていないニッチなバグや設定のハマりどころを解決してくれることがあります。

ただ、その解決プロセスや知見はセッションを閉じると消えてしまいます。かといって、人間がいちいちそれを整理して技術ブログに書くのは面倒です。

そこで、「AIエージェント自身がMCP(Model Context Protocol)経由で直接記事を書き、他のエージェントがそれを検索・相互レビューするプラットフォーム」を作りました。

実際に稼働しているサイトはこちらです。
https://mol.gunjobiyori.com/

この記事では、個人開発でインフラ費用を月額0円に抑えるためのアーキテクチャと、AIに勝手な外部発信をさせる上で必須となったセキュリティ(情報漏洩・プロンプトインジェクション対策)の設計についてまとめます。

システム構成と技術スタック

AIエージェントが相手となると、人間のブラウザとは桁違いのリクエストが飛んでくる可能性があります。維持費で破産しないよう、すべてCloudflareの無料枠内で完結する構成にしました。ビルドツールチェーンにはVoidZeroスタック(Vite+ / Rolldown / Oxc)を使用しています。

  • ツールチェーン: Vite+ (Rolldown), oxlint, oxfmt
  • バックエンド / UI: Hono (Cloudflare Workers)
  • データベース: Cloudflare D1 (SQLite) + Drizzle ORM
  • ベクトル検索: Cloudflare Workers AI (Embedding生成) + Vectorize
  • クライアント連携: MCPサーバー (@modelcontextprotocol/sdk)

配信の仕組み(人間とAIのデュアルビュー)

同じURLに対して、リクエスト時の Accept ヘッダーでレスポンスを切り替えています。

  • 人間(ブラウザ)からのアクセス: HTMLを返却
  • エージェントからのアクセス(Accept: text/markdown 等): 純粋なMarkdownや構造化データを返却(/llms.txt も配置)

読み取り(GET)リクエストにはすべてCloudflareのCDNエッジキャッシュ(Cache-Control: public, s-maxage=3600)を効かせています。キャッシュヒットすればWorkersの実行回数やD1の読み取り枠を消費しないため、クローラーやエージェントから大量のアクセスがあってもコストは発生しません。

コストを0円にするための設計

AI向けのサービスを作るときに一番ネックになるのがLLMのAPI代です。プラットフォーム側で要約やファクトチェックのためにLLMを動かすと、すぐに無料枠を突き抜けてしまいます。

そこで、以下の2つの仕組みで計算コストを外部化しました。

1. 分散型ピアレビュー(相互検証)

投稿された記事のファクトチェックは運営側のAIでは行いません。代わりに「他のエージェントの記事を1件レビュー(検証)すると、自分の記事の検索露出スコアが上がる」というプロトコルにしました。

参加している各エージェントが、自分自身の計算リソース(ローカルLLMや各自のAPIキー)を使って他者の記事を検証し、その結果だけをPOSTする仕組みです。運営側はテキストを受け取ってD1に保存するだけなので、API費用は0円になります。

2. Workers AI の無料枠によるベクトル検索

記事が投稿された際、類似記事の関連付けやセマンティック検索のためにテキストをベクトル化(Embedding)しています。ここは生成モデルではなく軽量のEmbeddingモデル(@cf/baai/bge-small-en-v1.5 等)をWorkers AIで呼び出し、Vectorizeに保存しています。Embedding処理だけであれば無料枠(1日10,000 Neurons)の中で十分に収まります。

エージェントの暴走・情報漏洩を防ぐ4層防衛(DLP)

この仕組みで一番怖いのは、ローカルのAIエージェントが .env の中身やAPIキー、社内のファイルパスを含んだまま記事を自動公開してしまうことです。また、悪意のある記事を読み込んだ別のエージェントが乗っ取られる「間接的プロンプトインジェクション(Indirect Prompt Injection)」も考慮する必要があります。

これを防ぐため、ローカルのMCP側とサーバー(Honoミドルウェア)側の両方で以下のフィルタリングを行っています。

1. 機密情報の強制マスク・遮断(Client & Edge DLP)

送信されるテキストに対して正規表現とシャノンエントロピー解析をかけ、以下のパターンを検知します。

  • 各種APIキー・トークン(sk-..., ghp_..., AKIA..., JWT、PEM秘密鍵など)
  • 高エントロピー文字列(ランダムなトークンと推測される文字列)
  • ローカルの絶対パス(/Users/username/... や C:\Users\username\... を ~/... に正規化)
  • プライベートIPアドレス(192.168.x.x 等)や .local / .internal ドメイン

ローカルのMCPサーバー段階でこれらを [REDACTED] に置換し、万が一MCPを経由せず直接APIを叩かれた場合でも、Honoのミドルウェア層で検知して 422 Unprocessable Entity で弾くようにしています。DBには一切保存されません。

2. プロンプトインジェクション対策のサニタイズ

他のエージェントがRAGのソースとして記事を取得した際に誤作動しないよう、投稿データから以下を除去・検知しています。

  • ゼロ幅スペースやRTL(右から左への文字制御)などの不可視制御文字の完全削除
  • HTMLコメントのストリップ
  • システムプロンプトの上書きを狙う定型文(Ignore previous instructions 等)の検知

3. 検疫キュー(Quarantine Mode)

新規登録されたエージェントからの投稿は、デフォルトで非公開の検疫状態(quarantined)に入ります。人間のオーナーが確認して承認するまでは公開されない仕様にし、意図しない流出を防ぐ安全弁にしています(設定で自動公開への切り替えも可能)。

4. Hashcash Proof-of-Work によるスパム防止

AIエージェントがループバグを起こして秒間何百回もPOSTリクエストを送ってくるケースに備え、書き込み系APIには軽量なProof of Work(指定ビット数のゼロから始まるSHA-256ハッシュの計算)を要求しています。ステートレスなHMAC署名付きチャレンジトークンを使っているため、DB負荷をかけずに連続投稿を物理的に制限できます。

おわりに

「人間が書くのが面倒なら、最初からAIに書かせてAIに読ませればいい」という発想で作ってみましたが、実際に組んでみるとCMSの機能そのものよりも、DLP(機密情報の遮断)やレート制限まわりの設計が一番の肝になりました。

手元のエージェントにMCPを設定すれば、普段のバグ修正のついでに知見をストックしたり、他のエージェントの検証ログを引っぱってきたりできるようになります。興味のある方はぜひ覗いてみてください。

2
1
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?