なんでも技術ブログ

【温故知新】RAGに「キーワード検索(BM25)」を足したら、AIが劇的に賢くなった話 目次 1. はじめに：「型番」が検索できないAIなんて役立たずだ 2. 基礎知識：ベクトル検索が苦手なこと、キーワード検索が得意なこと 3. 実装・設定：EnsembleRetrieverで「いいとこ取り」 4. 応用テクニック：重み付け（Weight）の黄金比 5. トラブルシューティング：日本語の壁（分かち書き） 6. まとめ：枯れた技術を見捨てるな はじめに：「型番」が検索できないAIなんて役立たずだ 「この製品コード『A-1234』の在庫教えて」とAIに聞いて、「すみません、分かりません」と返されたことありませんか？ 文脈は合っているのに、固有の記号に弱い。これが最新のAI（ベクトル検索）の弱点です。 現場の実務では、ふわっとした意味検索よりも、型番やエラーコードの「完全一致」検索の方が重要だったりします。「流行りの技術（Vector）さえ入れればOK」と思っていると、現場から総スカンを食らいます。 基礎知識：ベクトル検索が苦手なこと、キーワード検索が得意なこと ベクトル検索は「意味の近さ」を計算します。「美味しい」と「美味」は近くになりますが、「A-1」と「A-2」は（文字は似ていても）全く別物として扱うのが苦手です。 一方、昔ながらのキーワード検索（BM25など）は、単語の出現頻度を見るので、固有名詞や専門用語にめっぽう強い。この両者を組み合わせるのが、最強のソリューション ハイブリッド検索 です。 ...

【LangChain】CustomRetriever実装：パッケージ製品が自社業務に合わない時の「魔改造」術 目次 1. はじめに：「ウチの会社は特殊だから」への処方箋 2. 基礎知識：Retrieverはただの「検索関数」である 3. 実装・設定：BaseRetrieverを継承して俺俺ロジックを書く 4. 応用テクニック：日付フィルターや権限チェックを挟む 5. トラブルシューティング：非同期メソッド(ainvoke)の実装忘れ 6. まとめ：痒い所に手が届くシステムこそが定着する はじめに：「ウチの会社は特殊だから」への処方箋 業務システムの導入プロジェクトで、現場から必ず出る言葉。「ウチの業務フローは特殊なんで、パッケージそのままじゃ使えません」。 RAG開発でも同じです。標準のベクトル検索だけでは、「最新の日報だけ検索したい」「部長以上しか見られない極秘文書を除外したい」といったドロドロした要件に対応できません。 そんな時こそ、LangChainの CustomRetriever の出番です。既存の仕組みに満足せず、自社のルールに合わせて検索ロジックを魔改造する。これぞ社内SEの腕の見せ所です。 基礎知識：Retrieverはただの「検索関数」である 難しく考える必要はありません。LangChainにおけるRetrieverとは、「クエリ文字列(str)を受け取り、関連ドキュメントのリスト(List[Document])を返す」ただのクラスです。 つまり、この入力と出力の規格...

【Self-RAG】「自分の仕事を変だと思えるか」メタ認知を持つAIエンジニアリング 目次 1. はじめに：伸びる部下、伸びない部下の違い 2. 基礎知識：Self-RAG（自己反省型RAG）の仕組み 3. 実装・設定：LangGraphで「書き直しループ」を作る 4. 応用テクニック：Hallucination Graderの実装 5. トラブルシューティング：無限ループという名の残業地獄 6. まとめ：AIに「自律」を教える面白さ はじめに：伸びる部下、伸びない部下の違い 長年マネージャーをやっているとわかります。伸びる部下は、提出前に「これ、論理飛躍してないか？」と自分でチェックできる（メタ認知が高い）。伸びない部下は、書いたものをそのまま持ってきて「違います」と突っ返される。 AIも同じです。生成した答えをそのまま垂れ流すAIは、もう古い。これからのトレンドは、 「自分で自分の回答を採点し、ダメならやり直す」AI 、すなわち Self-RAG です。 基礎知識：Self-RAG（自己反省型RAG）の仕組み 通常のRAGは一方通行（Retrieve -> Generate）ですが、Self-RAGはループします。 1. ドキュメントを検索する。 2. そのドキュメントが「質問に関連しているか」を自己評価する。 3. 回答を生成する。 4. 生成した回答が「ドキュメントと矛盾していないか（幻覚ではないか）」を自己評価する。 ...

GraphRAG入門：AIに「点」ではなく「線」を理解させるナレッジグラフの力 目次 1. はじめに：組織図は箇条書きでは表現できない 2. 基礎知識：ベクトル検索の限界とGraphRAG 3. 実装・設定：LangChainとNeo4jで作る知識のネットワーク 4. 応用テクニック：LLMGraphTransformerでの自動抽出 5. トラブルシューティング：グラフDBの構築コスト 6. まとめ：「関係性」が見えれば、答えが変わる はじめに：組織図は箇条書きでは表現できない 「A部長とB課長は仲が悪いが、C係長は両方と仲が良い」 こんな複雑な人間関係、箇条書きのテキストで表現できますか？ できませんよね。でも、これを理解していないと社内政治は生き残れません。 AIも同じです。従来のRAG（ベクトル検索）は「キーワード（点）」を探すのは得意ですが、「AとBはどういう関係か？（線）」を推論するのは苦手でした。その壁を突破するのが、グラフ構造を取り入れた GraphRAG です。 基礎知識：ベクトル検索の限界とGraphRAG ベクトル検索は「意味が近い」ものを探します。あくまで類似度です。 一方、知識グラフ（Knowledge Graph）は「主語→述語→目的語」という構造化データです。これにより、「イーロン・マスク → 買収した → Twitter」のような明確な事実関係をAIがトレースできるようになります。これは、複雑なサプライチェーン問題や医療データの解析で絶大な威力を発揮します。 ...

【LangChain】Configurableで実装する「お客様の気まぐれ」に耐えるAIシステム 目次 1. はじめに：「やっぱりGPT-4がいい」「いや安くしたい」 2. 基礎知識：ハードコードは死への第一歩 3. 実装・設定：configurable_fields の使い方 4. 応用テクニック：ユーザーごとに検索ソースを切り替える 5. トラブルシューティング：デフォルト値を忘れるな 6. まとめ：変更に強いコードは、お財布にも優しい はじめに：「やっぱりGPT-4がいい」「いや安くしたい」 クライアントの要望というのは、秋の空のように変わります。 「最高の精度で！」と言われてGPT-4で組んだ翌日に、「請求額が高すぎる！GPT-3.5に戻して！」と怒られる…。開発現場あるあるですよね。 その度にコードを書き換えてデプロイし直すなんて、ナンセンスです。実行時（Runtime）にパラメータを外から注入できるようにしておく。これがプロの仕事です。LangChainの Configurable 機能を使えば、それが簡単に実現できます。 基礎知識：ハードコードは死への第一歩 model = ChatOpenAI(model="gpt-4") と書いてしまった瞬間、そのコードの柔軟性は死にます。 LangChainには configurable_fields や configurable_alternatives という仕組みがあり、チェーンの構造を...

【LangChain】「Runnable」インターフェースが革命的な理由：組織もコードも規格統一が命 目次 1. はじめに：Excelのフォーマットがバラバラな問題 2. 基礎知識：LCEL (LangChain Expression Language) の核 3. 実装・設定：invoke, batch, stream の三種の神器 4. 応用テクニック：RunnableParallelで並列処理を爆速化 5. トラブルシューティング：古いChainからの移行戦略 6. まとめ：共通言語を持つ組織は強い はじめに：Excelのフォーマットがバラバラな問題 「月次の売上報告、AさんはPDF、BさんはExcel、Cさんはメール本文…統一してくれ！」 管理職なら誰もが一度は叫びたくなる瞬間です。フォーマットが統一されていないと、集計作業（＝パイプライン）が組めないんですよね。 LangChainの世界でも同じことが起きていました。以前は LLMChain や RetrievalQA など、クラスごとに呼び出し方が微妙に違って使いづらかった。それを解決し、全てを統一規格にしたのが Runnable インターフェース です。これのおかげで、我々はレゴブロックのように自由に処理を組み立てられるようになりました。 基礎知識：LCEL (LangChain Expression Language) の核 LangChain v0.1以降、推奨されている構文が LCEL（パイプ演算子 | で繋ぐ書き方）です。これを実現す...

AIに「ハンコ」を押させるな：LangChainのHuman-in-the-loopで実現する責任ある自動化 目次 1. はじめに：AIが勝手にメール送っちゃった事件 2. 基礎知識：Human-in-the-loop (人間介入) とは 3. 実装・設定：LangGraphでの承認フロー実装 4. 応用テクニック：Slack連携によるスムーズな承認 5. トラブルシューティング：ステート管理の落とし穴 6. まとめ：最後の責任を取るのは私たち人間だ はじめに：AIが勝手にメール送っちゃった事件 「お客様に変なメール届いてるんですけど！」 完全自動化を目指しすぎた結果、AIエージェントが誤った内容のメールを顧客リスト全員に送信してしまった…。想像するだけで胃が痛くなりますね。 AIは便利ですが、幻覚（ハルシネーション）を見ます。だからこそ、重要なアクション（メール送信、DB更新、契約締結など）の前には、必ず**「人間のチェック（承認）」**を挟むべきです。今回は、LangChain (LangGraph) を使って、この「Human-in-the-loop」をシステム的に実装する方法をご紹介します。 基礎知識：Human-in-the-loop (人間介入) とは 「自動化の意味ないじゃん」と思うかもしれませんが、逆です。「9割はAIが下書きし、最後の1割（決定）だけ人間がやる」ことで、生産性と安全性を両立させるのがモダンなAI開発のアプローチなのです。 上司の承認印（ハンコ）みたいなものです。嫌われがちなハンコ文化ですが、事故防止装置としては優秀な...

【LangChain】HyDEでRAG検索精度を爆上げする：エンジニアにも「仮説思考」が必要だ 目次 1. はじめに：質問下手なユーザーを救いたい 2. 基礎知識：HyDE (Hypothetical Document Embeddings) とは 3. 実装・設定：LangChainでの実装コード 4. 応用テクニック：日本語特化の調整 5. トラブルシューティング：幻覚（ハルシネーション）との付き合い方 6. まとめ：AIに「気を回してもらう」技術 はじめに：質問下手なユーザーを救いたい 「全然ヒットしないんだけど！」というクレーム。ログを見てみると、検索ワードは「アレどうやるの？」……いや、分かるわけないだろ！ しかし、ユーザー教育をするより、システム側で賢くなる方が早い。ユーザーの曖昧な質問から、「たぶんこういう答えが欲しいんだろうな」と仮説を立てて検索する。そんな技術が HyDE です。 基礎知識：HyDE (Hypothetical Document Embeddings) とは HyDEのアプローチはこうです。 1. ユーザーの質問に対し、LLMがいったん「嘘でもいいから、ありそうな回答（仮説文書）」を生成する。 2. その「仮説文書」を使って、データベースを検索する。 つまり、 「検索クエリと回答は似てないけど、回答と回答は似ているよね」 という理屈です。ビジネスでも「とりあえず仮説を立ててから調査する」のが定石ですが、それをAIにやらせるわけです。 ...

RAGの精度が劇的向上：ParentDocumentRetrieverで「文脈切れ」を防ぐ技術 目次 1. はじめに：「断片的な報告」に怒る上司の気持ち、今ならわかる 2. 基礎知識：なぜ通常のRAGでは精度が出ないのか 3. 実装・設定：ParentDocumentRetrieverの導入手順 4. 応用テクニック：チャンクサイズの黄金比を探る 5. トラブルシューティング：ストレージ圧迫問題 6. まとめ：木を見て森も見るAIを作ろう はじめに：「断片的な報告」に怒る上司の気持ち、今ならわかる 「部長、トラブルです！」「詳しく話せ」 これ、RAG（検索拡張生成）でも同じことが起きています。単純なベクトル検索だと、AIは文書の断片（チャンク）しか読みません。だから「契約解除について」という章は見つけられても、それが「いつ」「誰が」対象なのか、文脈を見失ってしまうのです。 今回は、この問題を解決する ParentDocumentRetriever について解説します。これを入れるだけで、AIの回答が「気が利くベテラン社員」のように的確になります。 基礎知識：なぜ通常のRAGでは精度が出ないのか 通常のRAGは、文書を小さく切って（例：500文字）、それぞれをベクトル化します。 検索時には「類似した断片」は見つかりますが、その断片だけでは答えを作るための情報が欠けていることが多いのです。 ParentDocumentRetrieverは、 「検索は小さい単位で行い、AIに読ませるときは親...

Webスクレイピング×LangChainで競合調査を自動化する：BeautifulSoupとPlaywrightの実戦投入 目次 1. はじめに：「ググってまとめといて」業務を撲滅したい 2. 基礎知識：LangChainにおけるWebLoaderの仕組み 3. 実装・設定：静的サイト(BS4)と動的サイト(Playwright)の使い分け 4. 応用テクニック：取得データの整形と要約 5. トラブルシューティング：アクセス拒否とIPブロックの壁 6. まとめ：情報は「探す」時代から「集まってくる」時代へ はじめに：「ググってまとめといて」業務を撲滅したい 企画部門やマーケティングチームから、「競合他社のこの製品のスペック、一覧表にしてくれない？」みたいな依頼、来ませんか？ 最初は手作業でコピペしていても、10件目くらいで「俺の時給を使ってやることか？」と虚無感に襲われます。 こういう単純作業こそ、AIとスクレイピングの出番です。今回はLangChainを使って、URLを渡すだけでWebサイトの内容を引っこ抜き、さらにAIに「要するにどういうこと？」と要約させる自動化フローを紹介します。 基礎知識：LangChainにおけるWebLoaderの仕組み LangChainには document_loaders という便利なモジュール群があり、その中にWebサイト読み込み用のクラスが用意されています。これらは単にHTMLを取得するだけでなく、メインコンテンツの抽出（不要なヘッダーや広告の削除）まで考慮されているのが特徴です...

「管理画面を作って」と言われて絶望する前に：Streamlitで脱Excelバケツリレー 目次 1. はじめに：HTMLもCSSも書きたくない私たちへ 2. 基礎知識：Streamlit vs Gradio どっちを使うべき？ 3. 実装・設定：Pythonファイル1つでアプリが立ち上がる魔法 4. 応用テクニック：Session Stateを使った対話型アプリ 5. トラブルシューティング：動作が遅い時のキャッシュ活用法 6. まとめ：エンジニアのリソースを「本質」に集中させる はじめに：HTMLもCSSも書きたくない私たちへ 「このAIモデル、誰でも使えるように画面作ってよ」 上司は簡単に言いますが、Web画面を作るのがどれだけ大変か。 React？Vue？バックエンドはFlask？ …いや、私はAIエンジニアであり、Webデザイナーではありません。CSSの中央揃えで半日溶かすのはもう嫌なんです。 そんな我々の悲鳴に応えてくれたのが Streamlit です。「Pythonスクリプトを書くだけで、勝手にイケてるUIが出来上がる」。嘘みたいな話ですが、本当です。これで社内のExcelバケツリレー業務を根絶やしにしましょう。 基礎知識：Streamlit vs Gradio どっちを使うべき？ PythonだけでUIを作るライブラリ、主に2大巨頭があります。 Gradio : Hugging Faceが開発。AIモデルのお披露目（デモ）に特化。入出力がシンプル。 ...

【Open Interpreter体験記】AIにPCの「全権」を与えたら、仕事が消滅するかパソコンが壊れるか 目次 1. はじめに：ジャービスに憧れたエンジニアの末路 2. 基礎知識：Open Interpreterとは何か？ 3. 実装・設定：コマンド一発で起動する魔人 4. 応用テクニック：スクレイピングからグラフ作成まで全自動 5. トラブルシューティング：サンドボックスを使わないと死ぬ 6. まとめ：飼いならせれば最強のパートナー はじめに：ジャービスに憧れたエンジニアの末路 アイアンマンのAI、ジャービス。エンジニアなら誰もが一度は夢見ますよね。「デスクトップにある書類を整理して、いい感じにまとめておいて」と話しかけるだけで仕事が終わる世界。 Open Interpreter は、まさにそれを実現するオープンソースツールです。しかし、先に警告しておきます。これは「諸刃の剣」です。強力すぎる権限を持つため、使い方を間違えればPC環境を破壊しかねません。それでも試したいという勇気ある方（と、バックアップを取り済みの慎重な方）だけ、続きを読んでください。 基礎知識：Open Interpreterとは何か？ ChatGPTの「Code Interpreter」のローカル版、しかも制限なしバージョンだと思ってください。 通常のチャットAIはコードを生成してくれますが、実行するのは人間です。しかしOpen Interpreterは、 生成したPythonコードやシェルスクリプトを、あなたのPC上で直接実行します...

AIエージェントに「検索能力」を与える：Tavily Search API vs Google Search API徹底比較 目次 1. はじめに：「その情報は古いですよ」とAIに言わせない 2. 基礎知識：なぜLLMに検索APIが必要なのか 3. 実装・設定：AI特化型検索「Tavily」の実力 4. 応用テクニック：コストと精度のトレードオフ 5. トラブルシューティング：APIレート制限との戦い 6. まとめ：リアルタイム情報こそがビジネスの武器 はじめに：「その情報は古いですよ」とAIに言わせない 「ChatGPTに聞いたら、古いライブラリを勧められました…」 新人がハマりがちな罠です。LLMは学習時点（カットオフ）までの知識しか持っていません。しかし、ビジネスの世界はナマモノです。昨日のニュース、今日の株価、リリースされたばかりのライブラリ。これらを知らないAIは、ただの「物知りな老人」でしかありません。 そこで必要なのが、AIに「ググる能力」を与えることです。今回は、AIエージェント開発においてデファクトスタンダードになりつつある検索ツールを比較し、実装方法を解説します。 基礎知識：なぜLLMに検索APIが必要なのか 「RAG（社内データ検索）があればいいのでは？」と思うかもしれません。しかし、RAGはあくまで「手持ちの知識」です。未知の情報を探すには、外部のインターネットに接続するしかありません。 これを実現するのが Search Tool です。LangChainなどのフレームワークでは、エージェント...

「Cursor」は月額20ドルの価値があるか？ 40代管理職が全社導入を検討してみた結果 目次 1. はじめに：部下からの導入要望vs.コスト意識 2. 基礎知識：結局、VSCode Copilotと何が違うの？ 3. 実装・設定：既存のVSCode設定を一瞬で移行する方法 4. 応用テクニック：コードベース全体を読ませたリファクタリング 5. トラブルシューティング：社内規定とセキュリティの壁 6. まとめ：エンジニアの「時間」を買うと思えば安い はじめに：部下からの導入要望vs.コスト意識 「部長、開発ツールをCursorに変えたいんですが」 最近、現場からこんな声が上がってくるようになりました。聞けば月額20ドル。今の円安（150円換算）だと3,000円。GitHub Copilotも払ってるのに、さらに追加コスト？正直、財布の紐を握る身としては渋い顔をせざるを得ません。 「エディタなんてメモ帳でいいんだよ（極論）」と言いたくなるのをグッと堪え、まずは自分で自腹を切って試してみました。結論から言います。 これ、開発速度が倍になります。稟議通しましょう。 基礎知識：結局、VSCode Copilotと何が違うの？ CursorはVSCodeをフォークして作られているので、見た目はほぼVSCodeです。じゃあ何が違うのかというと、 「AIファースト」なUX設計 です。 Copilotが「賢い補完機能」だとしたら、Cursorは「隣にいるペアプロ相手」です。特に cmd+k ...