2026-06-17 · code, biz

38歳が『実践 LLMアプリケーション開発』を読んで設計した内製ツール化の3段階判断：プロトタイプ・評価監視・ガードレール設計の実務線引き

プロトタイプと本番の間にある「判断ライン」

『実践 LLMアプリケーション開発』（Suhas Pai著、オライリー・ジャパン）を読んで最も刺さったのは、「プロトタイプで動いた」と「本番で回せる」の間に引くべき判断ラインの具体論だった。

Amazonで見る | 楽天で見る

Claude Codeでブログ自動投稿の仕組みを作ったとき、「ローカルで動いた」から「毎日06:03 JSTに確実に投稿される」までの間に何度も止まった。評価指標がない、コスト管理が曖昧、エラー時の挙動が未定義——この本が整理している「評価・監視・ガードレール」の章は、その隙間を埋める設計指針になった。

個人事業+法人併営で内製ツールを回すとき、「どこまで作り込むか」の判断は常に迫られる。外注すれば確実だがコストがかかる。自作すれば安いが保守が自分に返る。この本の論点を実務に引き寄せて、3段階の判断基準を設計した。

第1段階：プロトタイプは「動作確認」まで（評価設計なし）

プロトタイプ段階では評価設計を入れない。目的は「技術的に実現可能か」の確認だけ。

ブログ自動投稿の場合、最初はローカルでPythonスクリプトを手動実行し、Markdown生成→Content Collections読み込み→GitHub push→Cloudflare自動デプロイの流れが通ることを確認した。出力品質の良し悪しは見ない。エラーハンドリングもない。「1回通った」で十分。

この段階で評価指標やログ監視を入れると、「そもそも動くのか」の検証が遅れる。プロトタイプは捨てる前提で、最小構成で動作確認だけする。

第2段階：定常運用前に「評価・監視・コスト管理」を入れる

定常運用に移行する前に、3つの仕組みを必ず入れる。

評価: 出力が要件を満たしているか。ブログ記事なら文字数・見出し構成・書籍引用の有無・アフィリエイトリンク形式の正確性を自動チェックする。手動確認は続けるが、最低ラインを機械で弾く。

監視: エラー時に気づく仕組み。GitHub Actionsのログ、Cloudflareのデプロイ通知、記事公開後のサイトヘルスチェックを組み合わせる。異常検知したらSlack通知する設計も検討したが、現状はGitHub Actionsの失敗通知メールで運用している。

コスト管理: APIコストの上限を決める。Claude APIの月額予算を設定し、超過しそうなら自動停止するか手動承認に切り替える。Cloudflareは無料枠内で収まっているが、トラフィック増加時の課金ラインは把握している。

この3つがないまま定常運用すると、「いつの間にか壊れていた」「コストが予想外に膨らんだ」「出力品質が落ちていた」に気づけない。プロトタイプから本番への移行ラインは、ここに引く。

第3段階：ガードレール設計で「やってはいけないこと」を明示する

ガードレールは、AIが絶対に超えてはいけないラインを事前に規定する仕組み。

ブログ自動投稿の場合、著者事実台帳に「書いてはいけないこと」として以下を明示している。

  • 年齢を偽る（38歳を50歳と書く等）
  • 未読書籍を引用する（読了書籍リスト外の本を記事で紹介しない）
  • 未達成目標を達成済みとして書く（FI達成していないのに「FIREしました」等）
  • 具体的な金額を事実として書く（目標値・想定値と明示する場合はOK）

これらは「プロンプトで指示したから守られる」ではなく、「システムレベルで弾く仕組み」として設計する。記事生成後に読了書籍リストと照合し、未登録書籍が引用されていたら公開前にエラーで止める。年齢表現も正規表現でスキャンし、疑わしい記述があれば人間確認に回す。

ガードレールの設計は「AIが何をやらかすか」を事前に列挙する作業。実装コストは高いが、信頼を失うコストはもっと高い。

内製ツール化の判断基準は「保守コストを誰が払うか」

3段階の判断基準をまとめると、以下になる。

  1. プロトタイプ：動作確認のみ（評価なし・捨てる前提）
  2. 定常運用移行前：評価・監視・コスト管理を入れる
  3. 信頼性が必要な箇所：ガードレールで「やってはいけないこと」を規定する

この基準で「どこまで内製するか」を判断している。外注したほうが早い場面もあるが、保守を自分でコントロールできる範囲なら内製する。逆に、保守コストが自分のキャパシティを超えるなら、最初から外注するか諦める。

『実践 LLMアプリケーション開発』が整理している評価・監視・ガードレールの論点は、「プロトタイプで満足する人」と「本番で回せる人」を分ける設計指針になる。個人事業+法人併営で内製ツールを回す実務に、そのまま応用できた。

関連書籍

参考

← ブログ一覧へ戻る