社内文書AIにベクトルDBは要らなかった — 全文投入で本番運用した設計と限界
Hiroba による自動要約
社内マニュアルをAIに参照させる際、一般的なRAG（ベクトル検索）ではなく、マニュアル全文をプロンプトに毎回投入する構成を採用し、2社のSlackボットで本番稼働。トークン数計算とプロンプトキャッシュの活用により、ベクトルDB不要で運用が壊れにくく、表の断片化や検索漏れの問題を排除できた一方、入力量に正比例したコスト増加が課題。
読んで良かったら、シェアしてみてください。
同じタグの記事が他に 4853 件あります。
関連する記事
同じタグの記事
GPT-6（Astra/Sol/Luna）と Claude Opus 5.5 で同じアプリを作らせて、品質・時間・料金を実測比較
ZennGPT-6 の3バージョンと Claude Opus 5.5 に Three.js 3D シミュレーションと CSV ダッシュボードの実装を依頼し、品質・所要時間・API 料金を実測比較した。結果、見た目の豊かさは Opus 5.5、品質と費用のバランスは GPT-6 Sol、3D 実装の速度は GPT-6 Astra が優れ、モデル選定は用途次第であることが明らかになった。
Haiku 5.5 移行前の応答ブロックと料金見積り検査
QiitaClaude Haiku 5.5 へ移行する際、モデル ID 交換前に応答処理と料金見積りの前提を分離するための Python コード例を紹介。思考ブロック・途中終了・使用量欠損を検査し、トークン数計算の変動・キャッシュ別計上・料金帯の適用など実装時の注意点を解説。公開 API 仕様（2026 年 10 月 8 日版）に基づく合成 fixture で再現可能。
Claude Sonnet 5.5がリリース—Sonnet 5同価格で30%高速化、API破壊的変更5つまとめ
Qiita2026年9月28日、Anthropic が Claude Sonnet 5.5 をリリース。Sonnet 5 と同じ $2/$10/1M tokens の価格で出力速度が30%以上向上し、Terminal-Bench 4.0 では 70.6% のスコアを記録。thinking の仕様変更、effort パラメータの目盛り変更、ツール呼び出し時の thinking ブロック導入など 5 つの破壊的変更があり、既存コードの修正が必要。