コンテクシア

Anthropicのエンジニア、Boris Cherny氏の「RAGを捨て、Agentic Searchを選んだ」という発言は、AI業界に衝撃を与えました。しかし、これは単なる技術的な好みの問題ではありません。 株式会社コンテクシアでは、この変化を「AI導入のフェーズが変わったサイン」と捉えています。

1. 「従来型RAG」とは何を指すのか？ 一般的にRAG（検索強化生成）と呼ばれている仕組みは、正確には「従来型RAG（ベクトル検索型）」を指します。 仕組み: 全文書を数値（ベクトル）化して専用DBに保存。 特徴: 似た情報を拾い出すのが得意。 課題: 事前のインデックス（目次作り）にコストがかかり、情報の鮮度を保つのが難しい。また資料が多くなれば多くなるほど「似ている」精度のチューニングが難しくなる 2. なぜ「従来型RAG」では不十分だったのか Boris氏が指摘し、私たちコンテクシアも現場で直面してきた「従来型RAG」の壁は、主に情報のノイズと鮮度です。 コンテクシアの現場メモ： 従来型RAGを導入した中小企業様から、「AIが去年の古いマニュアルを参照して回答してしまう」「確かに類似した資料だがこっちを参照してほしいのではない」という相談をよく受けます。これは、ベクトルDBを更新する手間（運用コスト）が、現場のスピードに追いついていないことが原因です。 これまでは、AIモデル自体の進歩によって問題が解決する、つまり大量のデータを投入すれば十分だという楽観的な意見もありましたが、そうではないことが明確になってきました。 3. Agentic Search（自律探索型）という選択肢 対するAgentic Searchは、AIがその場で「どのファイルを確認すべきか」を判断し、直接読みに行く仕組みです。 鮮度: 今そこにあるファイルを読みに行くため、常に最新。 精度: 意味の近さ（曖昧さ）ではなく、ファイル構造やコードの論理的な繋がりを辿る。 4. 中小企業にとっての「現実的な解」 決して「従来型RAG」を否定しているわけではありません。 従来型RAGに向くもの: 膨大な過去のナレッジ、FAQ、動かない規程集。とりあえず似たものを引張出したいとき。 Agentic Searchに向くもの: 日々更新されるプロジェクト資料、複雑な構成のファイル群。 これらを組み合わせ、「運用コストを最小化しつつ、回答精度を最大化する」のがコンテクシア流の支援スタイルです。 まとめ：大切なのは「AIが働きやすい環境」を作ること Boris氏の決断から学ぶべき真の教訓は、「AIに最高の結果を出させるには、情報の置き場所を整える（環境整備）ことが、高度なDBを組むことよりも重要である」という点です。 たとえるなら、「高性能なルンバ（AIエージェント）」を買う前に、「床の荷物を片付ける（環境整備）」ほうが、掃除の質は上がるということです。 Agentic Search構築の具体例：中小企業向け3パターン パターン1：【ノーコード・低コスト型】既存ツールを「エージェント化」する 自社でコードを書かず、すでにエージェント機能（Agentic機能）を備えたプラットフォームを活用します。 使用ツール: Salesforce Agentforce や Microsoft Copilot Studio 構築方法: 1. 接続: AIに社内のCRM、Google Drive、SharePointなどを接続します。 2. 指示（Instruction）: 「問い合わせが来たら、まず顧客の購入履歴を確認し、次に最新の製品マニュアルを探して回答案を作れ」と手順を教えます。 3. 動作: AIは質問に対し、従来型RAGのように「全データを検索」するのではなく、指定された「道具（APIや検索）」を使って自律的にステップを踏んで回答します。 メリット: サーバー管理が不要。現場の担当者がGUIで調整可能。 パターン2：【エンジニア向け・高精度型】オープンソースで「探索ツール」を組む エンジニアがいる、もしくは外注する場合の構成です。 使用ツール: LangChain または LlamaIndex + Python 構成要素: Planner（計画）: ユーザーの質問をタスクに分解する。 Tools（道具）: grep（ファイル内検索）、duckduckgo-search（最新のWeb検索）、SQLツール（社内DB参照）。 具体例: 「A商品の在庫が減っている理由を報告して」という指示に対し： AIがSQLツールで在庫推移を確認。 grepで社内共有フォルダの「日報」から「A商品」という単語を検索。 「競合のキャンペーンが原因かも」と推論し、Web検索で競合情報を確認。 すべてを統合してレポートを作成。 メリット: 自社の業務に特化した「道具（ツール）」を自由に追加できる。 パターン3：【最もシンプル・運用重視型】「構造化フォルダ」×「AIアシスタント」 実はこれが、多くの中小企業にとって最もコストパフォーマンスが良い方法です。 使用ツール: Claude.ai (Project機能) または ChatGPT (GPTs) 構築方法: 環境整備: 「マニュアル」「顧客対応記録」「商品仕様」など、フォルダごとにPDFやテキストファイルを整理してアップロード。 インデックスファイルの設置: フォルダ内に README.md を作成し、「このフォルダには何があるか」を人間が記述しておく。 指示: 「回答する際は、まずREADMEを読み、どのファイルを見るべきか判断してから詳細を確認してください」とプロンプトに書く。 メリット: 開発費ゼロ。ファイル整理さえすれば、今日から運用開始できる。 株式会社コンテクシアが推奨するステップ 中小企業がAgentic Searchを導入する場合、いきなり「パターン2」のような複雑なシステムを目指すのは避けるべきです。 まずは「情報の整理」から: フォルダ名、ファイル名をAIが読みやすい形に整える。 パターン3でプロトタイプ作成: 無料〜数千円の範囲で、AIが自律的にファイルを探せるかテスト。 必要に応じてパターン1・2へ拡張: 手作業でのアップロードが限界になったら、API連携やノーコードツールへの投資を検討。 AIに合わせるために業務を変えるのではなく、貴社の業務がより円滑に回るための『最適なAIの形』を、私たちコンテクシアと一緒に見つけてみませんか？

生成AIの登場により、プログラミングの世界は劇的に変化しました。定型的なコードの生成や、面倒な構文のエラーチェックといったタスクは、今やAIが優秀なアシスタントとして肩代わりしてくれます。 しかし、だからといって「エンジニアが不要になった」わけではありません。むしろ、AIがコードを書けるようになった今だからこそ、人間が担うべき「7つの領域」の重要性がかつてないほど高まっています。 近年、AIに丸投げした受託開発プロジェクトが、後になって破綻するケースが散見されるようになりました。それは、AIの特性と人間の役割を見誤っているからです。 AI時代における、真に価値あるエンジニアリングとは何か。私たちが重要視している7つの視点についてお話しします。

1. ソフトウェアアーキテクチャ：AIは「局所」、人は「全体」を見る AIは、特定の関数や短いロジックを書くこと（局所最適）においては天才的です。しかし、数万〜数百万行に及ぶシステム全体の整合性を保つこと（全体設計）は苦手です。 設計図なしにAIにコードを書かせ続けると、バグを直せば別の場所が壊れる「モグラたたき」状態に陥り、プロジェクトは行き詰まります。これを防ぐのが、堅牢なソフトウェアアーキテクチャです。 なぜ今、OOPとデザインパターンなのか 「オブジェクト指向（OOP）」や「デザインパターン（Strategy, Factory, Observerなど）」は、古くからある概念ですが、AI時代にその価値は再評価されています。これらは、もともと「他者に仕事をうまく任せるための思考フレームワーク」だからです。 カプセル化・継承・ポリモーフィズム： 部品ごとの独立性を高める。 デザインパターン： よくある課題への「定石」構造。 これらを適用してコードの骨格（構造）を人間が定義することで、AIはその枠組みの中で正確に機能することができます。私たちは、AIという優秀な部下を指揮するために、この共通言語を駆使しています。 2. データモデリング：システムの「背骨」を作る コードは書き直せますが、一度蓄積されたデータ構造を後から変えるのは困難です。だからこそ、データの設計は最初が肝心です。 RDBMS設計： ビジネスの基本データを矛盾なく格納する正規化技術。 NoSQL・ベクトルDB： AI活用で急増する非構造化データへの対応。 データフロー全体： ログの収集、キャッシュ戦略、外部APIとの連携など、データの「流れ」をデザインする力。 AIは「今の答え」は出せますが、「3年後のデータ量」を見据えた設計は人間にしかできません。 3. クラウドアーキテクチャ：コストと性能のバランス システムが動くインフラの設計も、コード生成AIの管轄外です。 スケーラビリティ： ユーザーが急増しても落ちない構成か。 コスト最適化： 無駄なリソースを使ってクラウド破産しないか。 可用性・冗長化： 災害や障害時にどう復旧するか。 これらはビジネスの規模や予算に直結する部分であり、経営的な判断も含む高度な設計領域です。 4. ドメインモデリング：言葉を構造に変換する クライアントの皆様が持つ「業界特有の商習慣」や「暗黙の了解」を、システムが理解できる構造に落とし込む作業です。 自然言語（日本語の要望）をそのままAIに投げても、AIは業務の背景にある「文脈」までは理解できません。「実務知識」を「論理構造」へ翻訳するこのプロセスこそが、使いやすいシステムを作る鍵となります。 5. 要求・要件定義：曖昧な「願望」を、正確な「地図」へ 最も上流にある「何を作るか」の定義です。 要求定義： クライアントが実現したいビジネスゴールは何か。 要件定義： それを実現するためにシステムに必要な機能は何か。 AIは「How（どう書くか）」は知っていますが、「What（何が必要か）」と「Why（なぜ必要か）」を決めることはできません。ここを曖昧にしたまま開発に入ると、どんなに優れたAIを使っても「誰も使わない高機能なシステム」が出来上がってしまいます。 6. AI活用設計：プロンプトの一歩先へ 単にChatGPTに質問することと、システムにAIを組み込むことは別次元の話です。 どの業務フローにAIを介在させるか。 AIの回答精度をどう担保するか（ハルシネーション対策）。 人とAIの役割分担（ワークフロー設計）。 「魔法のようにAIが解決する」のではなく、「AIを実用的な機能としてどう組み込むか」というエンジニアリング力が問われています。 7. 非機能要件の理解：見えない品質を担保する 機能（動くこと）以外の品質要件です。AIが生成するコードは、往々にしてここが抜け落ちがちです。 パフォーマンス： ストレスなく動作する速度か。 セキュリティ： 情報漏洩の脆弱性はないか。 保守性： 将来、別のエンジニアが見ても修正できるか。 これらは、プロフェッショナルとして決して譲れない品質の防波堤です。 結論：AI時代のエンジニアは「オーケストラの指揮者」 AIという強力な演奏家（コーダー）を手に入れた今、エンジニアの役割は「自ら楽器を弾くこと」から、「全体の調和を取り、最高の音楽（システム）を創り上げる指揮者」へと進化しています。 細部のコーディングをAIに任せられるようになった分、私たちはより本質的な「設計」「構造」「ビジネス価値」に注力することができるようになりました。 AIに"使われる"のではなく、AIを"使いこなし"、堅牢で成長し続けるシステムを構築する。それが、今の時代に私たちが提供できる最大の価値です。