L1 & L2：AIに「多く語らせる」より「正確に語らせる」

本稿では、スペクトラムの最初の2層に焦点を当てます。

• L1（基本応答者）：LLMは受動的に生成し、フロー全体は外部コードが制御します。代表的なアーキテクチャは Prompt + RAG Definition 検索拡張生成（Retrieval-Augmented Generation）——一言で言えば、AIが回答する前に指定したナレッジベースから情報を検索し、その情報に基づいて回答を生成する仕組みです。知識を「記憶」ではなく「参照」で補います。 。
• L2（ルーティング分配者）：LLMが意図を識別し、事前定義されたパスへリクエストを振り分けます。代表的なアーキテクチャは Intent Classification + Router。

導入記事でも触れたとおり、システムが「話す（情報を出力する）」だけでよく、タスクの境界が明確で、レイテンシ要件が3秒以内であれば、L1/L2が正解であることが多いです。

ただし「正解」と「自動的にうまくいく」は別の話です。製薬・金融・法的コンプライアンスなど、データ精度への要求が厳しい業界では、L1/L2アーキテクチャの設計が不適切だと、2種類の核心的な問題でシステム的に失敗します。検索精度の不足と、ルーティング動作の予測不能です。

本稿ではこの2つの問題の根本原因・工学的な対処策・UIデザインの対応ロジックを順に解体していきます。最後に、L1/L2の構造的な限界を正面から分析します——この限界を理解することが、L3への移行を判断する前提条件になります。

定義の明確化：L1とL2は何をして、何をしないか

最適化の議論に入る前に、2つの層の能力の境界を正確に画定しておく必要があります。そうしないと、アーキテクチャ意思決定の出発点がすでにずれてしまいます。

L1：受動的生成（Context-based Generation）

L1のコア能力は、与えられたコンテキストの中で回答を生成することです。このコンテキストはモデルの学習知識から来ることもありますが、エンタープライズ用途では外部検索（RAG）によって提供されることが多いです。

重要な境界制約：L1は業務システムの外部状態を一切変更しません。データベースへの書き込みも、ワークフローのトリガーも、副作用を伴うAPIの呼び出しも行いません。L1は読み取り専用の情報処理層であり、その能力の境界は「読む・比較する・まとめる・提示する」に尽きます。

L2：静的ルーティング（Static Routing）

L2はL1に意図識別の層を追加したものです。ユーザーの意図を判断し、事前定義された実行パスにリクエストを振り分けることができます。このパスはハードコードされています——コンプライアンス照会ならAパス、レポート出力ならBパス、価格照会ならCのAPIを呼ぶ、という具合です。

重要な境界制約：L2の計画能力は**静的（Static）**です。if-elseの分岐ロジックは処理できますが、「中間結果に基づいて次のステップをその場で計画する」や「実行中に戦略を動的に調整する」が必要になった時点でL2は機能しなくなります。これはL2の実装上の欠陥ではなく、設計上の定義による境界です。

よくある誤解：層のミスマッチ

アーキテクチャ最適化に入る前に、頻出する工学的な誤りをひとつ指摘しておきたいと思います。

          
graph LR
  A[システムはL1から始まる] --> B[精度が不十分と気づく]
  B --> C[RAGの最適化を積み重ねる]
  C --> D[それでも効果が出ない]
  D --> E[一気にMulti-agent（L4）へ飛ぶ]

        

このパターンの問題は「層をスキップすること」自体ではなく、L1の基礎設計をまだ正しく作れていない段階で諦めてしまうことにあります。Multi-agentを早まって導入しても、本来なら正確に特定できたはずの欠陥が、複雑なオーケストレーション層の中に埋もれて増幅されるだけです。Anthropicのエンジニアリングチームが多くの顧客事例を総括して出した提言は明快です：問題を解決できる最もシンプルな解を見つけ、本当に必要な時だけ複雑さを加える¹。

高規制業界の多くのシナリオでは、「最もシンプルな解」は正しく設計されたL1/L2であり、より複雑なAgentシステムではありません。

L1アーキテクチャ：検索精度における3つの失敗パターン

RAGはL1アーキテクチャのコアメカニズムです。モデルの知識が古くなるという問題を解決してくれますが、高精度が求められるビジネスシナリオでは、3つの層でシステム的に失敗します。この3つの失敗を理解することが、どこに手を入れるかを知る前提になります。

失敗パターン1：チャンク分割が意味の完全性を壊す

RAGの標準的なフローは、文書を複数の チャンク Definition RAGシステムがナレッジベースを構築する際、長い文書をまず小さな断片に分割してインデックスに格納します。この処理を【チャンク分割】（Chunking）、各断片を【チャンク】（chunk）と呼びます。検索時にシステムが探すのは最も関連性の高いチャンクであり、文書全体ではありません。 に分割し、ベクトル化してインデックスに格納し、クエリ時に最も類似したチャンクを取得してモデルに渡す、というものです。問題は**「切る」というその行為そのもの**にあります。

テキストを固定トークン数で切断すると、年次コンプライアンスレポートの特定のポリシー条項が、3つの別々のチャンクに分散してしまうことがあります。各断片は単独では合法な文章ですが、3つが揃って初めて意味をなします。しかしRAGシステムは検索フェーズで断片しか見えないため、チャンクをまたいだ論理的なつながりを把握できません。

医療分野の比較実験では、同一のRAGパイプラインで固定トークン分割をセマンティック認識型のAdaptive Chunkingに置き換えたところ、精度が50%から87%へ向上し、検索の関連性も大幅に改善されたといいます²。この数値の規模は、高精度シナリオにおいて、分割戦略そのものが桁違いの差を生む設計判断だということ——適当に設定してよい設定項目ではないことを示しています。

実践上の改善方向としては、セマンティック分割（字数ではなく意味的な境界で切る）・命題分割（テキストを独立した「事実文」に分解し、各文が単体で完結するようにする）・階層インデックス（チャンクの上にセクション要約の層を別途構築し、検索時に目次を引くように章を特定してから内容を精読する）などが挙げられます³。

失敗パターン2：ドメイン語義のずれがベクトル空間上の位置を狂わせる

ベクトル検索の根本的なロジックは、意味的に近いテキストはベクトル空間でも距離が近くなる、というものです。ただしこの「意味的に近い」はEmbeddingモデルが定義するものであり——大半の汎用Embeddingモデルは汎用コーパスで学習されています。

製薬の領域では、「適応症」「禁忌」「承認経路」といった専門用語は、汎用ベクトル空間での表現品質が日常語彙に比べて著しく低下します。「このオーファンドラッグ（希少疾病用医薬品）の指定要件は？」という質問に対し、システムが取得するのはポリシー条項ではなく、まったく関係のない文書かもしれません。

これはRAGのシステム的な盲点です：Embeddingモデルと業務ドメインの語義のずれ。対処の方向性は、ドメインのアノテーションデータでEmbeddingモデルをファインチューニング（Fine-tune）し、ベクトル表現をドメインの語義構造に近づけることです。Prompt Engineering Guideの工学的推奨事項も明示しています：特定の垂直ドメインで運用する場合、Embeddingモデルのファインチューニングは選択肢ではなく必須のステップです⁴。

失敗パターン3：マルチホップ推論が単回検索の能力範囲を超える

最初の2つの失敗は、分割戦略とEmbeddingの品質を改善することで緩和できます。しかし3つ目の失敗が関係するのはRAGのアーキテクチャ上の制約です。

一回の検索では回答できない種類の質問があります——それは複数の文書・複数のセクションにまたがる組み合わせ推論を必要とします。例えば：「2023年度と2024年度のコンプライアンスレポートを比較して、両年の間で実質的な修正があったポリシー条項はどれか？」

この質問に答えるには、①2023年の関連条項を特定し、②2024年の関連条項を特定し、③両者の差異を把握し、④その差異が「実質的」かどうかを判断する、という手順が必要です。これはマルチホップの推論チェーンであり、標準RAGの「検索→生成」という一回きりのフローは、構造上このようなタスクを支えられません。

この失敗パターンについては本稿の末尾でさらに掘り下げます。なぜならそれはL1アーキテクチャの構造的な限界を直接示しているからです。

L1の最適化戦略：ハイブリッド検索と追跡可能性の設計

3つの失敗パターンを理解すれば、最適化の方向性は自ずと見えてきます。以下の2つの戦略は、高規制シナリオで有効性が確認されている方向性です。ただし注意点があります：これらはRAGの補完的な強化策であり、置き換えではありません——ベクトル検索は依然として候補を高速に取得するコアメカニズムです。

戦略1：ハイブリッド検索（Hybrid Retrieval）

ハイブリッド検索の基本的な考え方は、互いを補完する2種類の検索能力を組み合わせることです。

• キーワード検索 Definition スパース検索とも呼ばれます （BM25）：キーワードの完全一致によるマッチング——従来の検索エンジンに近く、意味的に近いコンテンツではなく同じ語を含む文書を探します。専門用語や正確な数値の検索において特に高い信頼性を発揮します。
• 密集検索（Dense Retrieval）：ベクトルの意味論に基づく手法で、意味的に近似した表現や多様な言い回しのクエリに対して効果が高いです。

高規制シナリオで推奨される実践は：密集検索で意味的に関連する候補を高速に取得し、BM25や構造化インデックスで重要な専門用語と数値を精確に検証するという組み合わせです。研究によれば、ハイブリッド検索はドメイン特化型RAGの展開において、検索正答率とランキング精度を最大13.1%向上させます⁵。

表・年次報告書などの構造化された長文書を扱うシナリオでは、チャンク層の上に**階層インデックス（Hierarchical Index）**を構築することも有効です：各ノードにデータの要約を格納し、検索時はまずセクションを特定してから内容を精読する——これはRAGが断片の中を盲目的に探し回るより、人間が文書を読む方法に近いです³。

戦略2：追跡可能性の設計（Source Traceability）

エンタープライズ向け高規制システムの実際の利用においてよく見落とされることがあります：ユーザーが必要とするのは答えだけではなく、答えがどこから来たかを知ることです。

コンプライアンスレビューや薬事承認評価などのシナリオでは、AIが生成した要約は第一歩に過ぎません——ユーザーはその後、原典ソースを確認し、表現が正確かどうかを確かめてから採用を決めます。システムが出力を文書のページ数や表の位置に正確に紐づけられなければ、ユーザーは手動で遡らなければなりません。これは効率の問題にとどまらず、厳しい監督環境下ではコンプライアンスリスクに直結します。

追跡可能性の設計は付加価値ではなく、高規制業界におけるL1システムの基本要件です。

• 生成された各結論には、出典文書名・章・ページ数（可能であれば段落番号や表の番号まで）を付与しなければなりません。
• 同じ結論に複数のソースがある場合、それらのソース間に矛盾がないかを示す必要があります。
• 根拠となるソースが見つからない場合、システムは自力で推測して生成するのではなく、生成を拒否すべきです。

このステップによってL1システムは「答えを出すモデル」から検証可能な情報の入口へと変わります——この位置づけの転換こそが、高規制業界でユーザーの信頼を築く上での鍵になります。

L2アーキテクチャ：ルーティングの確実性を工学的に実現する

L1が「正しい情報をどう見つけるか」を解決するなら、L2が解決するのは：正しいパスで正しいリクエストを処理することです。

L2アーキテクチャの核心的な課題は「確実性」です——ただしこの言葉は工学的に正確に定義しなければ、誤解を招きやすいです。

確実性の3つの工学的な次元

• 再現可能性（Reproducibility）：同じ入力に対して、いつクエリしても同じ文書やデータソースに辿り着けること。これはインデックスの安定性とバージョン管理に依存しており、LLM自体の問題ではありません。
• ルーティングの一貫性（Routing Consistency）：同じユーザーの意図に対して、常に同じロジックパスを辿ること。これは分類器の安定性とルーティングルールの明示的な定義に依存しています。
• 出力の構造化（Output Structuring）：LLMの生の出力は、 temperature Definition temperatureはLLMの出力のランダム性を制御するパラメータです。0に設定すると理論上は最も確定的な出力になり、1に設定すると創造性は上がりますが安定性が下がります。ただしtemperature=0でも、モデルのバージョンが異なれば表現が変わることがあります。 =0であっても、モデルのバージョンが異なれば表現がずれることがあります。真の確実性は、出力を事前定義された構造の中に制約すること（JSONスキーマ・列挙オプション・フォーマットテンプレートなど）から生まれます。その後に下流のルール検証層を加えます。つまり、AIの出力を事前に定義した構造（例えば「はい/いいえ/不明」の3択のみ許可する）に制約し、さらに下流のルール検証層を重ねることで実現します——モデル自体が完全に一貫した文章を生成することに期待するのとは根本的に異なります。

L2ルーティングの二層構造

L2ルーティングは工学的には、並列する2つの戦略ではなく、二層のパイプライン構造です。

第一層：意図分類器（Intent Classifier）

ユーザーの入力を事前定義された意図カテゴリにマッピングする役割を担います。この層の設計原則は：軽量で確実性の高い分類モデルを使うこと——意図識別を同じ生成型LLMに任せてはいけません。

典型的な分類粒度の例：

• オープンエンドの分析リクエスト（「競合の動向を分析して」など）→ L1の検索フローへ
• 固定フォーマットのデータ照会（「今四半期のコンプライアンスレポートを出力して」など）→ 対応するAPIを直接呼び出す
• 対応範囲外のリクエスト（競合他社の非公開内部データなど）→ インターセプトしてユーザーに補足を促す
• コンプライアンス上センシティブなリクエスト（規制上の禁止語句を含む質問など）→ 強制的に人的レビューのパスへ

第二層：分類結果に基づくルーティング戦略

意図識別が完了して初めてルーティングの実行に入ります。この層の核心的な原則は：重要なビジネスパスはハードコード（Hard-coded）されたルールで制御し、LLMに自己判断させないことです。

例えば、医薬品の適正使用に関する説明をユーザーが照会した場合、L2ルーティングは汎用検索フローではなく、人的レビューを経たSOPドキュメントライブラリに直接誘導すべきです——この種の情報に求められる権威性の要件は、「精度の低い検索結果」が入り込む余地を許しません。

          
graph TD
  Input([ユーザー入力]) --> Classifier[意図分類器]
  Classifier -- "意図スコア/分類結果" --> Router[ルーティングルール層]
  
  Router -- "A" --> L1[L1検索フローを呼び出す]
  Router -- "B" --> API[APIを直接呼び出す]
  Router -- "C" --> Audit[人的レビューキューへ]
  Router -- "拒否" --> Reject[ガイダンス応答を返し、ユーザーに補足を要求]

        

回答の拒否：最も過小評価されているシステム能力

L2の層において最も重要な制御ロジックは「どう答えるか」ではなく、「いつ答えるべきでないか」です。

学術的にはこの能力を「Abstention（棄答・拒答）」と呼びます。MIT Pressの系統的なレビューによる定義では：LLMが回答を拒否する行動であり、ハルシネーションを減らし、安全性を高める可能性を持つとされています⁶。さらに研究が示しているのは：高リスク領域（医療・法律・コンプライアンス）では、過信した誤った回答が引き起こす損害は、「答えられない」と明確に伝えることの損害をはるかに上回るということです。

工学的には、L2システムの拒否能力は以下の3層を重ねて実装できます。

第一層：ルールベースのブロッキング（Rule-based Blocking） 明確に判明している境界条件をハードコードします。例：質問が競合他社の非公開財務データ、またはデータベースがカバーしていない期間に関するものであれば、直接インターセプトし、標準化されたガイダンス文を返します（「現在のシステムがカバーするのは2020〜2024年のデータです。ご照会の内容は対象範囲外です。期間をご確認ください」）。

これが最も確実でコストが低い拒否メカニズムであり、ルールで網羅できる境界条件に適しています。

第二層：検索信頼度の閾値（Retrieval Score Threshold） RAGフローでは、各検索に類似度スコア（Similarity Score）が付随します。最もスコアの高い検索結果が設定した閾値を下回っている場合、システムは信頼できる根拠を見つけられていないことを意味します——この場合は生成を拒否すべきであり、低品質の検索結果を無理やり組み合わせて回答を捏ち上げてはいけません。

retrieval_results = retrieve(query)
if retrieval_results[0].score < CONFIDENCE_THRESHOLD:
    return "現在のナレッジベース内に、このご質問に直接関連する資料が見つかりませんでした。"
            "質問の内容をご確認いただくか、データ管理担当者にお問い合わせください。"
else:
    return generate(query, retrieval_results)

第三層：境界識別分類器（「この質問はシステムの対応範囲を超えているか」を判断するもの） ルールで網羅できないが意味論的には識別可能な範囲外リクエストについては、「この質問がシステムの対応範囲内かどうか」を判断する専用の分類器を訓練します。研究によれば、多様な「範囲外の質問」サンプルが十分にある場合は専用の分類器が最もよく機能し、サンプルの多様性が限られている場合はルールベースのブロッキングも効果的です。両者を組み合わせることで、通常は両方の状況をカバーできます⁷。

UI/UX：入力を制約し、不確実性の発生源を減らす

アーキテクチャ層での確実性設計は、フロントエンドのインタラクション設計の協力があって初めて機能します。非技術系のビジネスユーザーに対して、UIデザインの本質は入力のあいまいさを減らすことにあります——システムにユーザーの意図を推測させるより、インターフェースがユーザーに意図を明確化させる方が正しいです。

以下は実践上で導入しやすい3つのデザインパターンです。

パターン1：意図認識型のフォーム式対話

フォームの各フィールドがシステムのバックエンドに必要なパラメータに直接対応します。ユーザーがフォームを送信した時点で、意図識別とパラメータ収集が完了しており、システムはAIによる推論なしに直接検索または呼び出しフローに入れます。

トリガー条件：意図分類器が高度に構造化された意図タイプ（「競合分析」「コンプライアンス照会」など）を識別したとき。

インタラクション：システムがパラメータ収集インターフェースを能動的に表示し、ユーザーが医薬品名・期間・分析軸をドロップダウンで選択します。ユーザーに自然言語のPromptを手書きさせません。

バックエンドのL2との連携：フォームの各フィールドがルーティングルールの一つのパラメータスロットに直接対応します。ユーザーがフォームを送信した瞬間、意図識別とパラメータ抽出が完了し、バックエンドはLLMの意図推論プロセスを経ることなく直接L1検索またはAPI呼び出しに入ります。

適用シナリオ：タスクの構造が高度に予測可能で、ユーザー層が（技術背景を持たない）ビジネス担当者であり、特定のパラメータ範囲内での動作が求められる場面。

パターン2：ドメイン用語のファセット誘導（Faceted Search Guidance）

トリガー条件：ユーザーが自由テキストの入力を始めたとき、システムがリアルタイムで関連する可能性のある用語カテゴリを識別します。

インタラクション：入力欄の横に用語サジェストリストを提供し、ユーザーが入力中に標準化された用語を選択できるようにします。入力が終わった後に表記揺れのある非標準の表現が混入するリスクを防ぎます。

バックエンドのL2との連携：用語が標準化された入力は意図分類器のあいまいさを大幅に減らし、同時にL1検索フェーズのベクトル検索精度を向上させます（標準用語は自由な表現よりも安定したベクトル表現を持ちます）。

適用シナリオ：専門用語が密な領域（医薬品名・規制条文番号・疾患ICD-10コードなど）で、ユーザーによる標準用語の習熟度にばらつきがある場合。

パターン3：拒否時のガイダンスUX（Refusal UX）

システムが回答を拒否することにした場合、ユーザー体験の処理がシステムへの信頼評価に直結します。

やってはいけないこと：「回答できません」とだけ表示し、次のステップを何も示さない。

正しいやり方：拒否応答には3つの要素を含めるべきです：①拒否理由を明確に説明する（「このご照会は現在のデータカバレッジ範囲外です」であって、あいまいな「答えられません」ではない）；②ユーザーに入力の修正を促す（「期間を2020〜2024年に絞っていただくか、以下の照会可能なデータ種別をご選択ください」）；③人的サポートへのエスカレーションパスを提供する（「サポートが必要な場合は[データ支援担当]にご連絡ください」）。

このデザインの核心的なロジックはこうです：拒否は失敗ではなく、自分の境界を正確に認識できるシステム自体が、信頼性の証になります。

L1/L2の構造的な限界：解決できない3つの問題

以上の最適化の方向性はすべて、L1/L2のアーキテクチャフレームワークの中で機能するものです。しかし3種類のビジネスシナリオは、L1/L2の設計をどれだけ精緻化しても、構造的な失敗を免れません——これは実装品質の問題ではなく、その層の定義が持つ境界です。

この3つの失敗パターンを理解することが、「L3の導入を検討すべきか」を判断するための核心的な根拠になります。

限界①：マルチホップ推論（Multi-hop Reasoning）

シナリオ：「2023年から2024年の間に実質的な改訂があったコンプライアンス条項のうち、我々の製品ラインに直接影響するものはどれか？」

L1が失敗する理由：この質問には複数の文書・複数の時間軸にまたがる比較推論が必要です——システムはまず両年の関連条項を特定し、その差異を比較し、差異の「実質性」を判断し、さらにそれを特定の製品にマッピングしなければなりません。これは少なくとも4ステップの推論チェーンを含むタスクです。

標準RAGの「一回の検索→一回の生成」フローは、構造上一度の検索と一度の生成しかサポートしません。中間ステップの出力に対して再度検索することも、一つの質問をサブ問題に分解して段階的に解くこともできません。RAGFlowのエンジニアリングレポートも指摘しています：「マルチホップ問題」はRAGシステムの意味論的なギャップが最も顕著なシナリオの一つであり、従来の検索手法ではこの種のシナリオへの対応に限界があります⁸。

何が必要か：問題をサブタスクに分解し、反復的に実行できる能力——これはL3（ツール実行者）のコア能力です。

限界②：動的計画（Dynamic Planning）

シナリオ：ユーザーが新薬の薬事承認に関する相談を送ってきました。3か国の異なる規制フレームワークが絡み、各国の要件が相互に制約し合っています。

L2が失敗する理由：このタスクの処理パスは事前に書き切れません。システムはまず3か国の基本的な規制フレームワークを把握し、それらの間の競合点を識別してから、競合点に基づいて次に何を照会するかを決めます。言い換えると、「ステップNで何をするか」は「ステップN-1の結果に依存する」——これこそがL2のハードコードされたルーティングが対応できない動的計画の要件です。

L2は「コンプライアンス照会であればAパス」という静的なロジックは処理できますが、「検索結果に基づいてAパスに行くかBパスに行くかをその場で決める」という動的なロジックは処理できません。

何が必要か：実行中に中間結果に基づいて後続ステップを再計画できる能力——同じくL3のコア能力です。

限界③：複数システムにまたがる状態の協調（Cross-system State Management）

シナリオ：ユーザーが社内研究レポートの主要な結論を、CRMシステム・社内ナレッジベース・コンプライアンス審査システムの3プラットフォームに同時反映させたい。

L1/L2が失敗する理由：前述のとおり、L1の定義は「業務システムの外部状態を変更しない」であり、L2の実行パスは事前定義されています。どちらも複数の外部システムを協調させ、システム横断的な整合性を維持し、各システムの応答状態に基づいて後続の操作を動的に判断するタスクには対応できません。

このシナリオは外部ツールの呼び出し（L3の能力）が必要なだけでなく、複数ツール間でコンテキスト状態を維持し、部分的な失敗（例えばCRMの更新は成功したがコンプライアンスシステムがタイムアウト）を処理する必要があります——これはさらにL4（協調オーケストレーター）の能力領域に踏み込んでいきます。

この3つの失敗パターンが、L1/L2の構造的な限界を描き出しています：タスクが複数ステップにまたがる動的推論、複数システムにまたがる状態の協調、または中間結果に基づくパスの再計画を必要とするとき、L1/L2アーキテクチャは限界に達します。これがL3が存在する根本的な理由です——次の記事で詳しく解体していきます。

ビジネスの意思決定：L1/L2にとどまるべきか、アップグレードすべきか

実際のビジネス意思決定において、以下の判断フレームワークが現在のシナリオにL1/L2を超えるものが必要かを評価するのに役立ちます。

以下の条件がすべて成立するならば、L1/L2が正解です：

• タスクに明確な正誤の基準がある（主観的な判断に依存しない）
• システムは情報を出力するだけでよく、外部システムの状態を変更する必要がない
• 各クエリは独立しており、ステップをまたいで中間結果を蓄積する必要がない
• レイテンシ要件が3秒以内

以下のシグナルがひとつでも現れたら、L3の導入を真剣に検討すべきです：

• ユーザーの質問に、複数の文書を組み合わせた推論が必要
• 第一ステップの検索結果に基づいて、第二ステップで何を照会するかを決める必要がある
• 有効な回答のために外部APIを呼び出し、その戻り値に基づいた判断が必要
• 「考えてからまた考える」複合的なシナリオ（例えば回答の自己検証）が存在する

精度の問題はまず検索パスで解決すべきであり、モデルの規模で解決しようとしてはいけません。 L1の回答が不正確であれば、最初のステップはChunkingの戦略・Embeddingの品質・検索召還のロジックを見直すことです——より大きなモデルに乗り換えたり、L3に直接ジャンプしたりすることではありません。

おわりに：確実性は信頼の基盤であり、また境界でもある

導入記事で提示した核心的な観点に立ち返りましょう：高規制業界では、AIプロダクトの成否はどれだけ多くのことができるかではなく、どの程度まで予測可能かにかかっています。

L1/L2システムの追跡可能な引用を一つひとつ「信頼の預け入れ」と見なすとしたら——ユーザーがソースを目にして、正確性を検証して、一度の信頼を積み上げる——それと同時に、信頼できる根拠がないのにシステムが強引に生成する場合は「信頼の引き出し」が起きます。何度か引き出しが続けば、ユーザーはすべての出力を疑い始め、システムのビジネス価値は根本から侵食されます。

L1/L2の設計目標は、システムをより賢く見せることではなく、システムの振る舞いを安定させ、境界を明確にし、繰り返し検証しなくてすむようにすることです。この予測可能性は、高規制業界では参入条件であり、その他のシナリオではユーザーの信頼の基盤となります。求められる程度は違っても、設計の方向性は一致しています。

しかし予測可能性は限界をも意味します。ビジネス要件の複雑さが静的ルーティングと単回検索の能力範囲を超えたとき、L1/L2を無理に「持たせる」ことは、見かけは安定しているが実は脆いシステムを生み出すだけです。

限界を認めることはアーキテクチャの成熟の証であり、限界を識別することはL3への出発点です。

次の記事ではL3（ツール実行者）に入ります：システムがどのツールを呼び出すかを自ら決め、どの順序で実行するかを能動的に計画し始めるとき、LLMは「受動的な生成」から「能動的な計画」へと変わります——この転換が真の能力の跳躍をもたらし、同時に正視すべき工学的な複雑性ももたらします。