AIに丸投げしたコードは、動いても「朽ちる」
AIが生成するコードは動く。しかし変更に強いとは限らない。DjangoのURLハードコードを例に、「動くコード」と「保守できるコード」の違い、そしてAIエージェントに設計判断まで委ねたときに何が起きるかを考えます。
AI開発
社内RAGを「どこまで閉じるか」——ネット接続あり・社内ネットワーク完結・PC1台完結
社内RAGの相談で最初に確認するのは「社内の文書を外に送っていいか」です。ここの答えで選べる構成が変わり、しかもあとから変えるのがとても高くつきます。ネット接続あり／社内ネットワーク完結／PC1台完結の3段階で、それぞれ何ができて何ができなくなるかを整理しました。
RAGはマネージドか、自前か——AWS Bedrock と pgvector を両方作って分かったこと
社内RAGをAWS Bedrockのマネージドで組むか、pgvectorで自前に持つか。「マネージドは楽、自前は安い」という説明をよく見ますが、両方を本番まで作ってみると、楽な部分と面倒な部分がきれいに入れ替わるだけでした。判断を決める3つの問いと、実際に差が出た4つの場所を書きます。
「AIで開発費10％削減」がうまくいかない理由 ― 安くなったのは”書く”だけで、”確かめる”は安くなっていない
AIが安くしたのは「書く」工程だけで、「確かめる」工程はほとんど短くなっていません。3日の実装が半日で出ても、読み解きと修正に3日かかれば正味はマイナス。削減時間から検証時間を引いて測る考え方を、具体的なケースで解説します。
ハーネスとは何か——AIを「部下」のように動かすための権限とスキルの設定
ハーネスとは、AIを部下のように動かすための「権限とスキルの設定」のことです。同じモデルを使っていてもエージェントの成果がまるで違うのはなぜか。何を任せ、どこまで勝手にやらせ、どこで報告させるか——設計すべき3つを、実際の運用例と組織設計との対応から図解します。
社内RAGは、小さく始めたほうが安い——検討する順番と、最初にやめるべきこと
社内RAGの相談で最も多いのが「全社の文書を全部入れたい」という出発点です。ですがこれが費用を最も膨らませ、しかもお金をかけた案件ほど使われなくなります。対象を絞る／既存DBを使う／ローカルモデルで試す／権限だけは最初に設計する、という順番と、その理由を書きます。
RAGで後から効いてくる費用——権限設計と、モデルを差し替える日
RAGの予算を壊すのは初期費用ではなく「あとで足そう」とした部分です。権限は文書単位ではなくチャンク単位で必要になるため、後から足すと分割からやり直しになります。再計算は数万件で数時間、数十万件で日単位。埋め込みモデルの差し替えも必ず来ます。後から足せるものと足せないものを整理しました。
なぜRAGの見積もりは当たらないのか——金額を決めているのは、渡される文書の状態です
RAGの実装部分は正確に見積もれます。見積もれないのは、渡される社内文書の状態のほうです。スキャンPDFはOCRより精度検証に時間がかかり、Excelは行と列の関係を文章に組み直す設計が要る。そして「就業規則_最新版(修正)」のような版の重複だけは、技術では解決できません。
RAGの構築費用はいくらか——なぜ30万円台から始められるのか
社内RAGの相場は「小規模50〜200万円、運用は月5〜50万円」と言われます。ですがこの幅を作っているのは開発工数ではなく構成の選択です。埋め込みをローカル化しpgvectorを使えば追加の固定費は消え、小規模なら30万円台・保守は月1万円から始められます。そして予算を本当に壊すのは、初期費用ではない3つの場所です。
Django × pgvector でRAGを自前構築する
専用のベクトルDBを契約せず、すでに動いているPostgreSQLにpgvectorを入れてRAGを組む構成。次元数が後から変えられない理由、e5系のプレフィックス、HNSWとIVFFlatの選び分け、しきい値をギャップで切る方法、そして最も重い「埋め込みモデルを差し替える日」の入れ替え手順まで、Djangoの実コードで解説します。