なぜAIエージェントは「予測不能」と感じられるのか？

近年、AIコーディングエージェントや文書自動化エージェントが注目を集めていますが、多くの実務者が共通して感じる課題があります。それは 「結果が毎回異なる」 という点です。同じ文書を入力しても、今日は正しく読み取れても、明日は全く異なるフィールドを抽出してしまう——これでは信頼性に欠けます。

この問題の根本原因は、LLMの確率的な性質にあります。LLMは本質的に「次のトークンを予測する」仕組みであるため、入力が同一でも出力が変動し得ます。しかし、実際のプロダクションシステムでは、この変動性を許容できません。特に契約書、法律文書、医療記録のように 高い精度が要求されるドメイン ではなおさらです。

ここで重要な解決策として浮上するのが、「強力なフィードバックループ（Feedback Loop）」 です。単にLLMにクエリを投げて結果を受け取る1回限りのパイプラインではなく、出力結果を再び入力として活用し、継続的に改善する構造 が必要です。

本記事では、実際のAWSベースのプロダクションシステム Doczy.ai のアーキテクチャを通じて、予測可能なAIエージェントを構築するための具体的な設計パターンを分析します。単なる概念説明ではなく、実際に99%の精度を達成した事例から、皆さんのプロジェクトに応用可能なインサイトを提供します。

AI agent architecture diagram showing feedback loop between LLM and structured data output Coding Session Visual

フィードバックループの3段階：入力 → 処理 → フィードバック

Doczy.aiのアーキテクチャを分析すると、フィードバックループは大きく3つの段階で構成されています。各段階がどのように予測可能性を高めるのかを見ていきましょう。

第1段階：スマートチャンキング — 文書構造を保持する入力前処理

一般的なRAGシステムは、文書を単純にトークン長で分割するか、意味単位で分割するにとどまります。しかしDoczy.aiは、「スマートチャンキング」 という特許技術を採用しています。

# スマートチャンキングの概念を簡略化した疑似コード
# 実際のシステムはより複雑なアルゴリズムを使用します。

def smart_chunk(document_text: str) -> list[dict]:
    """
    文書の階層構造と意味を保持するチャンキングアルゴリズム。
    単純な長さベースのチャンキングとは異なり、
    セクション/条項/表などの構造を維持します。
    """
    chunks = []
    
    # 1) 意味的分割：段落、セクションヘッダーを基準に一次分割
    semantic_segments = split_by_semantic_boundary(document_text)
    
    # 2) 構造的タグ付け：各セグメントにメタデータ（条項タイプ、ネストレベル）を付与
    for segment in semantic_segments:
        segment['clause_type'] = classify_clause(segment['text'])
        segment['nesting_level'] = detect_nesting_level(segment)
        # 例：Exhibit（別添）は3レベル、Schedule（日程表）は1レベルなど
    
    # 3) 重複除去と関連グループ化
    deduplicated = remove_overlaps(semantic_segments)
    grouped = group_by_sequential_id(deduplicated)
    
    return grouped

核心インサイト： 文書を「フラットなテキスト」と見なさず、元の階層構造と関係性を保持する ことが精度向上の第一歩です。日本語文書でも、条項のネストや別表の参照関係など、構造を無視するとLLMの出力品質が大きく低下します。

第2段階：デュアルクラスタリング — 意味と構造を同時に分析

チャンキングされたデータは、2つの視点から同時に分析されます。

# デュアルクラスタリングの概念を簡略化した疑似コード

def dual_clustering(chunks: list[dict]) -> list[dict]:
    """
    意味的類似度と構造的パターンを同時に考慮してクラスタリング。
    2つの結果を合成して最終的な文書モデルを生成します。
    """
    # 1) 意味的クラスタリング：埋め込みベースの類似度
    semantic_clusters = cluster_by_embedding(chunks, threshold=0.85)
    
    # 2) 構造的クラスタリング：パターン認識（条項タイプ、テーブルレイアウトなど）
    structural_clusters = cluster_by_pattern(chunks)
    
    # 3) 投影（Projection）アルゴリズム：2つのクラスタを整列・合成
    enriched_model = project_and_merge(
        semantic_clusters, 
        structural_clusters
    )
    
    return enriched_model

なぜデュアルクラスタリングが重要なのか？

LLMだけでは文書の「意味」は捉えられても、「構造的コンテキスト」を見落とすことがあります。例えば、「3階建ての建物を建設する」という条項が本文にあり、別添（Exhibit）に「地下2階の駐車場」とあった場合、LLMはこれらを別々の内容として扱う可能性があります。しかし構造分析により、「この文書は本文+別添の構造である」と認識できれば、両方の内容を統合解釈できます。

第3段階：プロンプト最適化フィードバックループ — Few-shotからMulti-shotへ

最も重要な段階です。Doczy.aiはプロンプトを一度作成して終わりにしません。

# プロンプト最適化フィードバックループの概念

class PromptOptimizer:
    """
    実際の出力結果に基づいて継続的にプロンプトを改善するループ。
    Few-shot → Multi-shotへと進化し、精度を高めます。
    """
    def __init__(self):
        self.base_prompt = """
        次の契約書の条項から主要情報を抽出してください：
        - 当事者名
        - 契約金額
        - 有効期間
        - 解約条件
        """
        self.example_pool = []  # 過去の成功/失敗事例を保存
    
    def generate_optimized_prompt(self, document_type: str) -> str:
        # ドメイン別のfew-shot例を選択
        relevant_examples = self.select_examples(document_type)
        
        # 最近の失敗事例に基づいて警告文を追加
        failure_patterns = self.analyze_recent_failures()
        
        optimized = f"""
        {self.base_prompt}
        
        [参考例]
        {relevant_examples}
        
        [注意事項]
        - {failure_patterns}
        - ネストされた別添がある場合は、必ず本文と一緒に解釈すること
        """
        return optimized

実務適用ポイント：

  • Few-shot → Multi-shot: 単に2～3個の例を与えるだけでなく、実際の出力結果と比較しながらプロンプトを継続的に修正します。
  • エラーパターンのフィードバック: 「こういう場合に間違えやすい」というパターンを蓄積し、プロンプトに警告として追加します。
  • ドメイン特化: 医療契約書と金融契約書ではプロンプトが異なります。文書分類（File Class）を先に実行し、それに応じたプロンプトテンプレートを選択する構造です。

この3段階のループが適切に機能すれば、時間が経つほどエージェントの精度が向上する 好循環が生まれます。Doczy.aiでは22ヶ月間で250万件の契約書を処理し、99%の精度を維持しています。

Cloud infrastructure diagram with AWS services like Lambda, S3, and Bedrock connected in a pipeline Algorithm Concept Visual

日本市場における適用コンテキスト

日本企業の文書自動化への示唆

日本では、多くの金融機関や官公庁が依然として ルールベースの文書処理 に依存しています。Doczy.aiの事例から得られる教訓は以下の通りです。

  1. ルールベース（55%精度）→ AIベース（99%精度）への移行は現実的です。

    • 日本の金融庁の電子開示、特許文書、建設契約書などにも適用可能です。
    • ただし、初期導入時は「100%自動化」ではなく、「人間のレビュアー + AIアシスト」方式から始めるのが安全です。

  2. スマートチャンキングが特に重要です。

    • 日本語文書は英語よりも助詞や活用が複雑で、表やリスト構造が頻出します。
    • 単純なトークンベースのチャンキングは日本語に特に脆弱なため、形態素解析 + 構造認識 を組み合わせたチャンキング戦略が必要です。

  3. プロンプト最適化ループは「知識管理」の問題です。

    • 実務で最も軽視されがちなのが「エラー事例の収集とフィードバック」です。
    • 単にLLM APIを接続するだけのプロジェクトは失敗する可能性が高いです。エージェントが間違えたケースを体系的に収集し、プロンプトに反映するプロセス を先に設計すべきです。

この技術の限界と注意点

  • 初期構築コスト： スマートチャンキング、デュアルクラスタリングは単純なRAGよりもエンジニアリングコストが高くなります。小規模プロジェクトにはオーバーエンジニアリングになる可能性があります。
  • ドメイン専門性： 99%の精度は医療契約書に特化した結果です。別のドメイン（特許、不動産など）に適用するには、最初から再学習が必要です。
  • LLMコスト： 137MのAPIコール、442Bトークンは相当なコストです。コスト対効果を計算し、必要な部分にのみLLMを使用するハイブリッドアプローチが重要です。

次のステップとしての学習方向

  1. RAG（Retrieval-Augmented Generation）の基礎を固める： LangChain、LlamaIndexを利用した基本的なRAG実装から始めましょう。
  2. 文書構造分析ライブラリの探索： python-layoutparser、pdfplumberなどで文書構造を抽出する練習をしてみてください。
  3. プロンプトエンジニアリングの高度化： 単純なプロンプト作成ではなく、Few-shot、Chain-of-Thought、Self-Consistencyなどの手法を実験してみてください。
  4. AWS Bedrock + Lambdaベースのパイプライン構築： 実際のサーバーレスアーキテクチャで文書処理パイプラインを自作することが、最も効果的な学習です。

参考： 本記事で扱ったフィードバックループの概念は、AIコーディングエージェントにも同様に適用できます。AIコーディングエージェント、予測可能な結果を作る核心：強力なフィードバックループでより詳細な内容を確認してください。また、最新のLLMモデル比較とAIゲートウェイ構成に興味があれば、DeepSeek V4、Vercel AI Gatewayに正式登場 Pro vs Flash完全比較もあわせてご覧ください。

Data analyst reviewing contract insights dashboard with charts and key metrics Software Concept Art

まとめ：予測可能なAIエージェントは「設計」の問題

Doczy.aiの事例が明確に示しているように、AIエージェントの予測可能性は 「どのLLMを使うか」よりも「どのようにフィードバックループを設計するか」 に依存します。

単にGPT-4oやClaudeをAPIで呼び出すことを超えて、以下の質問を自分自身に投げかけてみてください。

  • 入力前処理： 自分の文書の構造を保持しながらチャンキングしているか？
  • 分析エンジン： 意味と構造を同時に考慮しているか？
  • フィードバックメカニズム： 出力結果を分析してプロンプトを継続的に改善しているか？

この3つの質問すべてに「Yes」と答えられるなら、あなたのAIエージェントはすでに予測可能なレベルに達しています。そうでなければ、今からでもフィードバックループを設計に組み込んでください。そうすることで初めて、AIは単なる「新技術」ではなく、ビジネスに実際の価値をもたらす「ツール」になり得ます。

根拠資料： Automating contract intelligence with Doczy.ai™ on AWS - AWS Architecture Blog

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。