はじめに

変化の流れがはやすぎて、ついていけていない生成AI事情。とはいえ何かしら活用してみたいなと思い、今更ながらAPI経由でのLLM callを試しながら、当ブログに本文要約機能を実装してみる。

併せて、ここ最近でいろいろと組み替えた部分も踏まえて、改めて2025/6時点のシステムアーキテクチャをまとめてみました。

LLM本文要約機能

LLM本文要約機能は、Cloudflare Workers上にWEB APIとして実装。リクエストされたブログ本文をプロンプトとともにLLMに渡して本文要約、要約結果をレスポンスする作りとしています。

呼び出し側（Nuxt3のフロントエンド）は、ビルド時にこのAPIをcallし得られた要約文をページに埋め込んで静的生成しています。この流れは、ブログのコンテンツをmicroCMSからビルド時に引っ張っている動きと同様。

LLMのモデルは、GoogleのGemini ~~2.0 Flash~~ 2.5 Flash-Liteを採用（2025/12/9 モデルを変更）。

APIが無料である程度のボリューム使用できること
本文要約自体はそれほど難しいタスクではないと思うので、~~最新の2.5でなくても十分~~
→ いつの間にかGemini 2.0 Flashが利用できなくなっているようなので、2.5 Flash-Lite に変更（2025/12/9）

というの採用の理由、あまり深い意味はありません。

要約結果は、Cloudflare KV上にキャッシュさせ、LLMへのリクエストは初回のみ、以降はキャッシュされた結果を利用するようにもしています。これは

LLMへのリクエスト回数を絞ること
要約結果の変動を防ぐこと
必要に応じて要約結果を人が修正できるようにすること

を目的としたもの。

特に3つ目にも記載しましたが、LLMによる要約を完全に信頼してはいないため、必ず要約結果を確認し必要に応じて修正できる仕組みであることを重視しました。

動かし始めてまだ日が浅いですが、今のところはよい感じで動いてくれてそう。

作ってみた感想

仕組み自体はWEB API callをしているだけなので、大して難しいわけでもなく、すんなり作れたのですが。。。ちょっと苦戦したのはプロンプトの作成。

要約結果がなかなか思うようにならずに、LLMに指示する表現を色々変えながらTry & Errorを繰り返しました。特に、今回出力されたものをそのままページに埋め込む仕組みにしていますが、LLMがMarkdownのCode Block形式で出力してくる点が面倒でした。これをそのまま埋め込むとCode Blockとして表示されてしまうため、色々な言い回しを試し、何とかCode Block形式にしない出力が得られるようになりました。このあたりが自然言語をInputとするプロンプトの難しさね。AIを使いこなすにはプロンプト力が試されるわけか。

また要約結果を眺めていると、自分視点の要約結果と、第三者視点の要約結果（「筆者は〇〇と述べている」みたいな表現）が混在している点も気になっています。このあたりもゆくゆくはプロンプトを修正してどちらかに統一するようにしてみたいなと思います。

ブログシステムアーキテクチャ ver.202506

以上を踏まえた上で、2025/6時点のJamstackブログのシステムアーキテクチャは次の通り。

最近 Cloudflare領域が拡大していますね。これなら静的ページのホスティング自体もnetlifyからCloudflare Pagesに移管してしまってもよいのでは？と思うこともありますが、1プラットフォームに依存・固めすぎるのも面白くないという理由でしばらくはこの構成で行こうかと（単純に移行するのが面倒でもあり）。

Tags