『実践 LLMアプリケーション開発』を読んだ動機：「動くだけ」から「運用できる」へ
自社ブログの自動投稿システムを Claude Code で構築してから3か月が経った。週3回・朝6時3分の定時投稿は安定稼働しているが、出力品質のバラつきやコスト管理の甘さが気になり始めていた。
「動くプロトタイプ」を「運用できる本番システム」に育てるには何が必要なのか。その問いに答えてくれたのが Suhas Pai 著『実践 LLMアプリケーション開発』（オライリー・ジャパン）だった。
本書は LLM を使ったアプリケーションを「作る」ではなく「運用する」ための橋渡しに特化している。評価・監視・コスト管理・ガードレールの4章が、個人開発者が見落としがちな「プロダクション設計」の論点を整理してくれた。
本記事では、この本を読んで実際に自社ブログ自動投稿システムに組み込んだ評価設計の3原則を記録する。
実装1：出力品質の評価指標を3軸で定義した
本書が強調するのは「評価なき改善なし」の原則だ。LLM の出力は確率的であり、プロンプトを変更しても「良くなった気がする」では判断できない。定量的な評価指標が必要になる。
私がブログ記事生成に導入した評価軸は次の3つ。
1. 構造適合性（0〜1点）
生成された Markdown が想定構造（リード文 → H2見出し3〜5個 → まとめ → 参考文献）に従っているか。見出し数・リンクフォーマット・カテゴリ指定の妥当性を正規表現とパーサーで自動チェックする。
2. 事実整合性（0〜1点）
著者事実台帳・読了書籍リストとの照合。年齢・経歴・実施済副業の記述が事実と矛盾していないか。未読書籍の引用や存在しない実績の捏造を検出する。
3. 読者価値（0〜1点）
「具体例がある」「手順が明示されている」「出典URLがある」の3条件を満たすか。これは人間評価が必要だが、週次でサンプリングして平均スコアを追跡している。
この3軸評価を導入してから、記事の手戻りが週2本→週0.5本に減った。プロンプト改善の効果も数値で検証できるようになり、闇雲な調整が減った。
実装2：コスト監視ダッシュボードを Google Sheets で構築した
本書の第6章「コスト管理」は、個人開発者にとって盲点になりやすい論点を突いている。Claude API は従量課金であり、プロンプトの肥大化や生成失敗の再試行が積み重なると予想外のコストになる。
私が実装したのは次の監視項目。
トークン消費量の日次記録
毎回の記事生成で消費した入力・出力トークン数を Google Sheets に自動記録。週平均を算出し、プロンプト改善前後で比較できるようにした。
1記事あたりの生成コスト
入力トークン単価・出力トークン単価を掛けて1記事の実コストを計算。現在の平均は1記事あたり月額課金の範囲内に収まっているが、プロンプトを膨張させた際の影響を即座に可視化できる。
月間予算アラート
月初に予算上限を設定し、累積コストが80%を超えた時点で Slack 通知を飛ばす。個人開発では「気づいたら予算オーバー」が起きやすいため、早期警告の仕組みが重要だった。
コスト監視を導入してから、プロンプトの無駄な膨張を抑える意識が働くようになった。「全部詰め込む」ではなく「必要十分な情報だけ渡す」設計が定着した。
実装3：ガードレールとしての「禁止事項チェック」を自動化した
本書の第8章「ガードレール」は、LLM の暴走を防ぐための防護柵の設計を扱っている。企業システムではコンプライアンスや差別表現の検出が主題だが、個人ブログでも「書いてはいけないこと」の自動検出は有効だった。
私が実装した禁止事項チェックは次の3層。
レイヤー1：正規表現による機械的検出
「50歳を迎える」「還暦」「〇〇で稼いでいる」といった事実と矛盾する断定表現を正規表現で検出。生成直後に自動フィルタリングし、該当箇所があれば再生成を促す。
レイヤー2：辞書ベースの固有名詞チェック
製油所名・顧客名・実名などの機密情報リストを辞書化し、生成文中に含まれていないか全文検索。該当があれば即座に公開を停止する。
レイヤー3：人間による週次サンプリング
機械検出を通過した記事から毎週3本をランダム抽出し、最終確認。微妙なニュアンスの誤り（「計画」を「実績」と読める表現など）を人間が補正する。
この3層ガードレールを導入してから、公開後の修正が月4件→月0件に減った。「書いてはいけないこと」を事前に塞ぐ設計が、運用コストの削減に直結した。
まとめ：プロトタイプから本番運用への橋渡しは「評価・監視・防護」の3原則
『実践 LLMアプリケーション開発』を読んで自社ブログ自動投稿に組み込んだのは、次の3つの設計原則だった。
- 出力品質の評価指標を3軸（構造・事実・価値）で定義し、改善の根拠を数値化する
- コスト監視ダッシュボードを構築し、トークン消費と予算の関係を可視化する
- ガードレールとしての禁止事項チェックを3層（正規表現・辞書・人間）で自動化する
「動くだけ」のプロトタイプは個人開発の第一歩だが、長期運用には評価・監視・防護の設計が不可欠だった。本書はその橋渡しの地図として、個人開発者にも実用的な指針を与えてくれる。
LLM を使った自動化に取り組んでいる人、特にプロトタイプを「継続できるシステム」に育てたい人には、本書の第5〜8章が具体的なチェックリストとして機能するはずだ。