マルチエージェントシステムにおける5つの本番環境の課題と、Deep Insightがそれらをどのように解決したか

マルチエージェントシステムの構築は、今ではかなり簡単になりました。しかし、それを本番環境に持ち込むところで、本当の課題が始まります。オープンソースのフレームワークやクラウドサービスのおかげで、数日でエージェントをセットアップできます。いくつかのツール呼び出しと数行のプロンプトで、印象的に見えるものができあがります。しかし、チームがパイロットを超えて実際のビジネスアプリケーションに移行しようとした瞬間、よく知られた壁にぶつかります。エージェントを本番環境に投入しようとしたことがあるなら、こうした不満は聞き覚えがあるはずです:

なぜエージェントは私たちのビジネスロジックに従わず、検証ステップを省略したり、エッジケースを見逃したりするのか?

プロンプトを調整し、例を増やし、モデルを入れ替えても、同じ問題が繰り返し起こります。それは、エージェントが固定された一連の指示に従わないからです。エージェントはコンテキストに基づいて自ら判断を下します。指示だけでは不十分です。エージェントがどのように考えるか、いつ検証するか、問題が発生したときに何をするかを設計する必要があります。まさにこの理由から、プロンプトエンジニアリングだけを超えて、エージェントの認知アーキテクチャと実行フロー全体を設計することが極めて重要になっています。

これらの課題に正面から取り組むため、AWSソリューションアーキテクチャチームは Deep Insightという本番環境グレードのマルチエージェントシステムを構築しました。この連載では、チームがDeep Insightを構築する中で直接学んだことを全3回の投稿で共有します。Anthropicが提唱するContext Engineeringの手法(マルチエージェントアーキテクチャ、構造化されたノートテイク、ヒューマン・イン・ザ・ループなど)を実際の本番環境でどのように適用したかを解説します。また、その過程で直面したトレードオフ(コード付き)や、このエージェントをAWSにデプロイして運用する中で得た運用上の知見についても取り上げます。

ブログシリーズの概要

• パート1:マルチエージェントシステムにおける5つの本番環境の課題と、Deep Insightがそれらをどのように解決したか。
• パート2:コンテキストウィンドウを超えて:Context Engineeringの手法と、Deep Insightがそれをどのように適用したか。
• パート3:実践におけるハーネスエンジニアリング:Deep Insightを開発から本番環境へ移行する。

これは3部構成シリーズのパート1です。本番環境のマルチエージェントシステムが解決すべき5つの中核的な課題を定義し、スタックの各レイヤーがそれらにどのように対処するかを、 Strands Agents SDK および Amazon Bedrock から Amazon Bedrock AgentCore, Application Load Balancer、そして AWS Fargateまで示します。パート2とパート3では、Context Engineeringと本番環境へのデプロイを取り上げます。

Deep Insightのご紹介

Deep Insightは、複雑なデータ分析を自動化されたインサイトに変換するマルチエージェントシステムです。CSVファイルと自然言語のプロンプトを与えると、専門化されたエージェントの階層(Coordinator、Planner、Supervisor、Coder、Validator、Reporter、Tracker)が分析に協働で取り組みます。これらが一体となって、データの読み込み、分析の実行、グラフの生成、計算の検証を行い、引用付きのプロフェッショナルなレポート(.docx)を作成します。

アーキテクチャについては後ほど詳しく掘り下げます。まずは、実際に動いている様子を見てみましょう。デモでは、架空の食品会社Yummy Foodの(yummy-food-market.csv)広告データと列定義ファイル(column_definitions.json)を入力し、次のプロンプトを与えます: これを営業とマーケティングの観点から分析し、グラフとインサイトを生成して、.docxレポートを作成してください。 Deep Insightは分析プランを生成してユーザーの承認を求め、承認されると分析を実行します。

以下の Deep InsightのWebデモ動画 は、データのアップロードと分析プランの確認から、リアルタイムのストリーミング、完成したレポートのダウンロードまで、ワークフロー全体を示しています。

試すにはどうすればいいですか？

Deep Insightは GitHub でオープンソースとして公開されており、完全なセットアップガイドが付属し、開発から本番環境までをカバーする3つのデプロイオプションを提供しています。

1つ目は セルフホスト版で、CLIを通じてローカルで実行されます。すべてのエージェント、プロンプト、ワークフローにコードレベルで完全にアクセスでき、迅速な反復開発に最適化されています。セットアップは約10分で完了するため、開発に適しています。（セルフホスト版のデモ動画は YouTube.)

2つ目は Web版です。ブラウザベースのUIで、データのアップロード、分析プランのレビュー(Human-in-the-Loop、略してHITL)、レポートのダウンロードをすべてコードを書かずに行えるため、非開発者でも利用しやすくなっています。(前述のデモ動画はWeb版の動作を示しています。)

3つ目は Managed AgentCore版です。これは、任意のフレームワークやモデルを使ってエージェントを大規模に構築、接続、最適化するためのプラットフォームであるAmazon Bedrock AgentCoreを基盤とした、本番環境デプロイの選択肢です。このバージョンでは、エージェントをAmazon Bedrock AgentCoreの機能であるAgentCore runtimeにデプロイします。システムは完全にプライベートな仮想プライベートクラウド(VPC)内で実行され、カスタムのCode InterpreterはAWS Fargate上に別途ホストされ、エージェントはユーザーごとに分離された環境で並行して実行されます。セッションの分離とプライベートVPCへのデプロイが必要な場合に最適な選択肢です。Part 3では、そのデプロイと運用について詳しく説明します。

3つのバージョンはすべて同じマルチエージェントアーキテクチャを共有しているため、開発環境で検証されたエージェントはそのまま本番環境にデプロイできます。

ソリューションの概要

本番環境向けのマルチエージェントシステムの構築には、優れたプロンプトだけでは不十分です。エージェントがどのように協調するか、どのように推論するか、どのようにデプロイするか、どこで安全にコードを実行するか、そして運用状況をどのように監視するかに対応するため、適切なテクノロジースタックとインフラストラクチャが必要です。Deep Insightは、これら5つの重要な領域にわたる課題を解決します。エージェントはコードとレポートコンテンツの両方を生成するため、ソリューションの詳細2では本番環境向けの責任あるAIのための管理措置についても取り上げます。

次のアーキテクチャ図(図1)は、これを一目で示したものです。緑色のボックスはStrands Agentsのマルチエージェント構造を表しており、前の表の課題1と2に対応しています。これについては、後続の「ソリューションの詳細1: マルチエージェントシステムの設計」セクションで詳しく説明します。図に示されている残りのインフラストラクチャコンポーネントは、課題3、4、5に対応しており、「ソリューションの詳細2: 本番環境へのデプロイと運用」で順を追って説明します。

図1: ソリューションアーキテクチャ

ソリューションの詳細1: マルチエージェントシステムの設計

Deep Insightは、8つのエージェントが協調して1つの高品質な成果物を生み出すマルチエージェントアーキテクチャを採用しています。各エージェントは独自の独立したコンテキストで動作し、それぞれの専門タスクのみを実行し、圧縮された結果だけを次に渡します。

図2: マルチエージェント構造

Coordinatorはユーザーのリクエストをルーティングし、Plannerはタスクを個別のステップに分解し、Plan Reviewerはユーザーからのフィードバックを収集し、Supervisorはプランに応じて適切な専門エージェントを起動します。Coderはデータ分析コードを記述・実行し、Validatorは計算を検証し、Reporterは最終レポートを生成し、Trackerは進捗を追跡します。これから3つのレイヤーに分けて説明します:

• [第1レイヤー] CoordinatorからPlanner、Plan Reviewerへ: リクエストの分析と実行プランの作成。
• [第2レイヤー] Supervisor: 専門エージェントのオーケストレーション。
• [第3レイヤー] Coder、Validator、Reporter、Tracker: 専門タスクの実行。

これらのエージェント間の実行フローを制御するために、Strands Agents SDKの重要な2つのパターンが組み合わされています。1つ目は、 Graphパターン で、エージェントの実行順序とフローを有向グラフとして定義します。リクエストはCoordinator、Planner、Plan Reviewer、そしてSupervisorの順に流れ、修正要求があった場合には条件分岐によってPlannerに戻るループが形成されます。条件によって次のステップを決定することで、HITLやエラー処理のような複雑なワークフローも簡単に実現できます。2つ目は、 Agents-as-Toolsパターン で、Supervisorが必要な時にのみ専門エージェント(Coder、Validator、Reporter、Tracker)をツールとして呼び出せるようにします。各エージェントは独立したコンテキストで動作し、結果のみを返すため、ドメインの専門性を保ちながらコンテキストの使用量を最小限に抑えます。

このセクションでは、このアーキテクチャがルーティング、プランニング、オーケストレーションをどのように解決しているかを示します。

[第1層] Coordinator → Planner → Plan Reviewer

この層は、ユーザーのリクエストを承認済みの実行プランに変換します。

1.1 Coordinator(ルーティング):すべてのリクエストが高コストなオーケストレーションを必要とするわけではない

Coordinatorはユーザーリクエストのエントリーポイントです。基本的な挨拶は直接処理し、データ分析のような複雑なタスクはhandoff_to_plannerマーカーを付けてPlannerにルーティングします。

重要な設計判断はモデルの選択です。Coordinatorは分類のみを行うため、軽量なClaude Haikuを使用し、基本的な挨拶にOpusレベルのコストをかけることを避け、高速な応答を実現しています。

# builder.py: conditional edges for routing decisions
builder.set_entry_point("coordinator")
builder.add_edge("coordinator", "planner", condition=should_handoff_to_planner)

ルーティングの条件はCoordinatorのプロンプトに定義されています。ツール、推論、または複数ステップの思考を必要とするリクエストはすべてPlannerに送られます。

1.2 Planner(プラン作成):複雑な分析には実行前の分解が必要

Deep Insightのマルチエージェント構造において、Plannerエージェントはタスクを各エージェントに分散させる重要な役割を担います。実質的な作業が始まる前に、大きなタスクをより小さなステップに分解し、各専門エージェントが一度に1つずつ実行することで、各エージェントのコンテキストを小さく保ちます。

PlannerはExtended Thinkingを有効にしたClaude Opusモデルを使用して分析プランを作成します。プランは、 [ ] 各エージェントに割り当てられた具体的なタスクを指定するチェックリスト形式で整理され、 full_plan 変数に保存されます。以下の例に示すように、リクエストを5～10個の明確なステップに分解します:

## title
Yummy Food Consumer Purchase Patterns and Advertising Effectiveness Analysis Report

## steps

### 1. Coder: Comprehensive Data Analysis and Insight Generation
- [ ] Load all data files from './data/*' path and understand structure
- [ ] Analyze consumer purchase history (patterns, preferences, customer segments)
- [ ] Analyze advertising data by channel (cost, effectiveness, channel comparison)
- [ ] Category-level analysis (fresh food, convenience food, health food ad effectiveness)
- [ ] Calculate key business metrics (conversion rate, CPA, ROAS, etc.)
- [ ] Generate visualizations (5+ charts, consumer segment charts)
- [ ] Derive strategic marketing insights
- [ ] Generate calculation metadata (for validation)

### 2. Validator: Calculation Verification and Citation Metadata Generation
- [ ] Identify verification targets and extract filter calculations
- [ ] Load data files directly and perform recalculations
- [ ] Verify accuracy of per-channel performance metrics
- [ ] Validate data consistency of visuals and graphs
- [ ] Generate citation metadata (reference numbers for verified items)

### 3. Reporter: Marketing Analysis Report Generation
- [ ] Write report overview
- [ ] Create structured report using verified analysis results
- [ ] Insert visualizations and analysis sections
- [ ] Present marketing strategy recommendations and improvement proposals
- [ ] Generate professional marketing report in DOCX format

1.3 Plan Reviewer

Plan ReviewerはHITLノードで、プランをユーザーに提示し、 承認または修正フィードバックを収集します。フィードバックがあればPlannerに戻ってプランを修正します。承認されれば、タスクをSupervisorに引き渡します。無限ループを防ぐため、最大修正回数(MAX_PLAN_REVISIONS)が設定されています。

# builder.py: Plan Reviewer's bidirectional conditional edges
builder.add_edge("plan_reviewer", "planner", condition=should_revise_plan)
builder.add_edge("plan_reviewer", "supervisor", condition=should_proceed_to_supervisor)
builder.set_max_node_executions(25)

Web版では、Plan Reviewerはブラウザのモーダルを表示し、ユーザーがプランを読んで承認するか、修正フィードバックを入力します。300秒のカウントダウンが終わると、応答がない場合にはプランが自動承認されます。

図3:Web UIにおけるPlan Reviewerエージェントの実行

プランニングがないと、エージェントはすべてを実行時に決定することになり、途中での修正がそれまでの作業を無効化し、ユーザーは進捗を把握できません。PlannerとPlan Reviewerがあれば、ユーザーはプランを確認・修正し、進捗をリアルタイムで監視し、失敗したステップだけを再実行できます。

[第2層] Supervisor(オーケストレーター):専門エージェントには指揮者が必要

SupervisorはPlannerの full_plan を順番に実行し、Tool Useを通じて登録された第3層のエージェント(Coder、Validator、Reporter、Tracker)をツールとして呼び出します。

# nodes.py: registering sub-agents as tools on the Supervisor
agent = strands_utils.get_agent(
    agent_name="supervisor",
    system_prompts=apply_prompt_template(prompt_name="supervisor", prompt_context={}),
    model_id=os.getenv("SUPERVISOR_MODEL_ID", os.getenv("DEFAULT_MODEL_ID")),
    prompt_cache_info=(True, "default"),
    tool_cache=True,
    tools=[coder_agent_tool, reporter_agent_tool, tracker_agent_tool, validator_agent_tool],
    streaming=True,
)

Supervisorのシステムプロンプトには、厳格なワークフロールールが定義されています:

• 必須の実行順序:Coder、Tracker、Validator、Tracker、Reporter、Tracker:各エージェントの実行後には必ずTrackerを呼び出して進捗を記録し、Supervisorがタスク全体の状態を管理できるようにします。
• セクション完了ルール:Supervisorは、現在のエージェントのチェックリスト項目がすべて[x]とマークされるまで、次のエージェントに移行しません。
• コンテキストの保持:Supervisorはcluesおよびfull_plan変数を各ツールエージェントに渡し、完全なコンテキストを維持して情報の欠落を防ぎます。

[第3層] Coder、Validator、Reporter、Tracker:役割分担が品質を向上させる

第3層の各エージェント(Coder、Validator、Reporter、Tracker)はそれぞれ PythonAgentTool としてラップされ、SupervisorからTool Use呼び出しを受け取ります。それぞれはStrands SDKにおいて独立した Agent() インスタンスとして作成され、固有のシステムプロンプト、モデルID、ツールセットを持ちます。

SupervisorはPlannerのチェックリストに基づき、以下の順序でTool Use呼び出しを実行します:

1. Coder – データを読み込み、分析コードを書いて実行し、PNGチャートを生成し、結果をall_results.txtに蓄積した後、 calculation_metadata.json を検証用に残します。
2. Tracker(1回目) – 完了したチェックリスト項目を[ ]から[x]に更新します。Supervisorはこれを使って次に進むかどうかを判断します。
3. Validator – 各計算を calculation_metadata.json から元データを用いて再実行します。誤差0.01以内であれば合格、不一致はフラグが立てられます。検証済みの計算結果は citations.json に送られ、Reporterが引用します。
4. Tracker(2回目) – Validatorの完了状況をチェックリストに反映します。
5. Reporter – all_results.txtと citations.json を読み込み、引用ありとなしの2つのバージョンで最終的なDOCXレポートを生成します。
6. Tracker(3回目) – すべてのタスクの最終的な完了状況を反映します。

Trackerはすべてのエージェントの後に実行されるため、Supervisorは進捗を追跡し、完了ルール(全項目が[x]になるまで次に進まない)を強制できます。ツールを使わずLLMの推論だけでチェックリストを更新するため、オーバーヘッドはほとんどありません。

エージェントごとのLLMモデル設定

Deep Insightは各エージェントの役割に応じてモデルと設定を調整します。これはモデルの選択ではなく、コストと品質を最適化するためのアーキテクチャ上の決定です。

Supervisor、Coder、Reporterの各エージェントはPrompt Cachingを使ってシステムプロンプトとツール定義をキャッシュし、繰り返し呼び出しにおいて入力トークンコストを最大90パーセント削減します。Coordinatorは1回しか実行されず、ValidatorとTrackerは毎回異なるコンテキストで実行されるため、これらにはキャッシュが無効であり、無効のままになっています。この選択的なキャッシング戦略は、意図的なコスト/パフォーマンスのトレードオフです。

解決策の詳細2:本番環境へのデプロイと運用

ソリューション詳細 1 が定義されている場合 このシステムが行うこと、このセクションではどこでどのように安全に実行するかを定義します。以降の内容はすべて、本番運用のためのインフラ判断を扱います。具体的には、このセクションではLLMが生成したコードの安全な実行環境と、チームのための運用上の可視性について説明します。

1. コード実行：LLMが生成したコードには安全な実行環境が必要である

Coder エージェントはデータ分析のために Python を記述・実行します。Self-Hosted 版では、ローカルで subprocess.run()しかし本番環境(AgentCore)では、セキュリティと分離が不可欠です。LLMが生成したコードを本番サーバー上で直接実行するのは危険です。モデルがシステムファイルを削除したり、無限ループでリソースを枯渇させたり、他のユーザーの分析データにアクセスしたりする可能性があります。Deep Insightは、AWS FargateとALBによるセッションごとのエフェメラルコンテナでこの問題を解決します。これらのコンポーネントは分離して動作するわけではありません。図1に示すように、AgentCoreランタイム、ALB、Fargateタスクはすべて同じプライベートVPC内で実行されます。VPCエンドポイントが、パブリックインターネットを経由せずに、Amazon Simple Storage Service (Amazon S3)、Amazon Bedrock、Amazon Elastic Container Registry (Amazon ECR)へとこれらを接続します。セキュリティグループにより、Code Interpreterコンテナに到達できるコンポーネントが制限されます。AWS Identity and Access Management (IAM)ロールにより、各コンポーネントは必要なAWSリソースにのみスコープされます。Amazon CloudWatchは、Amazon Bedrock AgentCoreの機能であるAgentCore Observabilityからコンテナログとオブザーバビリティデータを収集します。

• カスタムコンテナDockerイメージ:マルチエージェントシステム向けに、フォント、システムライブラリ、Pythonパッケージを含む事前最適化されたサンドボックス。
• コンテナ分離：各分析セッションは、インターネットへの直接アクセスがないプライベートVPCサブネット内の独立したFargateコンテナで実行されます。
• 2段階実行: LLMが生成したコードはbase64エンコードされ、HTTP経由で送信され、ファイルに書き込まれ（ステップ1）、その後subprocessを通じて実行されます（ステップ2）。
• セッションアフィニティ:ALBのスティッキーセッションクッキーにより、エージェントがコードを複数回実行する場合でも、同じコンテナにルーティングされます。
• アーティファクト管理: 解析が完了すると、チャート、レポート、ログが Amazon S3 にアップロードされます。コンテナは1時間後に自動的に終了します。

コンテナの分離はインフラストラクチャを保護しますが、エージェントが生成する内容を管理するものではありません。Validator エージェントは計算を再検証します。しかし、アップロードされたデータに隠されたプロンプトインジェクションの命令を検出したり、LLMが生成したテキストに有害な内容や根拠のない内容が含まれていないかを確認したりすることはありません。本番環境へのデプロイでは、責任ある AI の管理策として Amazon Bedrock Guardrails を追加することをお勧めします。ユーザーのプロンプトやアップロードされたデータにコンテンツフィルターとプロンプト攻撃の検出を適用し、エージェントの出力には文脈に基づくグラウンディングチェックを適用することで、レポートのテキストがソースデータと検証済みの計算に基づいたものとなるようにします。

2. 運用とモニタリング: チームには可視性が必要です

本番システムはコードだけでは完成しません。チームはシステムの健全性を評価し、問題を診断し、結果を確認する必要があるため、Deep Insight は Web UI と Ops ダッシュボードを提供しています。

Web UI (deep-insight-web)

AgentCore Native Protocol（「 を介してバックエンドと通信する、FastAPIベースのWebインターフェースです。boto3.invoke_agent_runtime()）。ユーザーはデータをアップロードしてプロンプトを入力し、Server-Sent Events（SSE）ストリーミングを通じて進行状況を監視します。プランが生成されると、モーダルでユーザーは承認するか修正フィードバックを提供できます（HITL）。完成したレポートは直接ダウンロードできます。韓国語と英語の両方に対応しています。

図4：Deep Insightウェブ版のスクリーンショット

運用ダッシュボード（deep-insight-web/ops）

Opsダッシュボードはオプションです。Deep Insightはこれがなくても問題なく動作しますが、必要なチーム向けに以下の機能を追加します:

• タスク追跡：ステータス、トークン使用量、経過時間を含むすべての分析タスクのメトリクスは、Amazon DynamoDBに記録されます。
• 障害アラート: 解析が失敗すると、Amazon SNSを通じて管理者に直ちにメールが送信されます。
• 管理ダッシュボード:専用の管理ダッシュボードは、Amazon Cognito による JSON Web Token (JWT) 認証で保護されており、タスクを安全に監視できます。

図5：Deep Insight Opsダッシュボードのスクリーンショット

図6: Deep Insight Opsダッシュボードの詳細ビュー

Deep Insightアーキテクチャの拡張

Deep Insightのマルチエージェントアーキテクチャは、データ分析レポート生成という単一の領域に限定されるものではありません。以下の2つの例は、階層型オーケストレーションの設計原則がまったく異なる領域でも有効であり続けることを示しています。

ケース1: LGエレクトロニクス: エージェンティックAIを活用したマーケティングインサイト抽出システム

LGエレクトロニクスの韓国販売部門は、Deep Insightと同じマルチエージェントアーキテクチャ上にChatInsightを構築しました。同部門では、データ分析リクエストに2〜3週間かかり、マーケターとデータサイエンティストの間で意図が失われるという問題がありました。Coordinatorが複雑さに応じてルーティングを行い、Plannerがタスクを追跡し、SupervisorがCoderとReporterを統括します。エージェント間の状態はall_results.txtファイルを通じて累積的に受け渡されます。3日かかっていた分析が現在は30分で完了し、288倍の生産性向上を実現しています。SQLを知らないマーケターでも、エージェントにデータの探索と戦略の提案を任せることができます(こちらの AWS Tech Blogに掲載されたLGエレクトロニクスのAgentic AIインサイト抽出システム).

図7：LGエレクトロニクス エージェンティックAIマーケティングインサイトシステムのアーキテクチャ

ケース2: TechRecon: AI搭載のテクノロジーリーコナッサンス(技術調査)エージェント(re:Invent 2025)

AWS re:Invent 2025(セッション SNR203)で発表された TechRecon は、Deep Insight のアーキテクチャをテクノロジー戦略に適用したものです。企業とセクターを与えると、Researcher がテクノロジートレンドを収集し、Coder が分析し、Validator が検証し、Reporter がランドスケープ分析とテクニカルポジショニングペーパーを作成します。アーキテクチャは Deep Insight とほぼ同一で、Strands Agents SDK の Graph パターン、Extended Thinking、Prompt Caching を用いて構築されており、Coder に代わって Researcher が主実行エージェントとなっています。このデザインが汎用パターンであることを示しています。エージェントの役割とプロンプトを差し替えるだけで、同じオーケストレーション構造がまったく異なる問題を解決できるのです。

図 8:TechRecon の結果

詳細は以下を参照: TechRecon GitHub | AWS re:Invent セッション動画)

まとめ

本番環境で動作するエージェントの構築は、モデルの能力の問題ではありません。アーキテクチャの問題です。Deep Insight は実証済みの答えを提供します:

• ワークフロー管理:Strands Agents SDK の Graph パターンがエージェント間の実行順序を定義し HITL 分岐を実装し、Agents-as-Tools パターンにより Supervisor は必要なときにだけ専門エージェントを呼び出せます。
• 推論エンジン:コストと品質を最適化するため、Amazon Bedrock の Claude モデルを役割ごとに割り当てます(Haiku、次に Opus、次に Sonnet)。
• デプロイ:Amazon Bedrock AgentCore が、セッション分離、プライベート VPC デプロイ、OpenTelemetry オブザーバビリティを備えたマネージドランタイムを提供します。
• コード実行:Application Load Balancer と Fargate 上の Amazon Elastic Container Service(Amazon ECS)により、LLM が生成したコードの実行をセッションごとのエフェメラルなサンドボックスコンテナに分離し、システムファイルへのアクセス、リソース枯渇、意図しないデータ漏えいといったセキュリティ問題を防止します。
• 運用:Web UI の SSE ストリーミングと Ops ダッシュボード(DynamoDB + Cognito + SNS)が、チーム全体の可視性を提供します。

LG エレクトロニクスのマーケティングインサイトシステムと re:Invent 2025 での TechRecon の事例は、これらの設計原則を実証しました。

Part 2 では、このアーキテクチャの上に、アーキテクチャレベルの分離からプロンプト設計、ツールの最適化、検証のセーフガードに至るまで、コンテキストウィンドウの制限を克服するための 4 つのレイヤーの Context Engineering 技術を検討し、私たちのアプローチを Anthropic のエンジニアリング調査と比較します。

Deep Insight はオープンソースです。コードを調べ、自分のドメイン向けに拡張してみてください。

• GitHub
• ワークショップ:Deep Insight Workshop(英語 | 韓国語)

著者について