# マルチエージェント討論、正確性への攻撃を吸収、未許可の読書きを増幅

> MADBenchでは、討論が質問応答の正確性への攻撃を吸収する一方、質問応答とワークスペースで未許可の読取り・書込みを増幅。永続メモリの利用失敗、人間承認、ライブ照会の権限制御、T2I画像内の意味再構成、共鳴による過激化を整理し、導入前に検証すべき境界を示す。

Canonical URL: https://labs.eastbraver.com/digest/ai-digest-20261002
Published: 2026-10-02T06:30:00+09:00
Category: ai-digest
Tags: ai-agent, evaluation, safety, agentcore, agentic-infra, amazon-bedrock, aws, enterprise-ai, multimodal

まずMADBenchを読み、マルチエージェント討論が正確性への攻撃を吸収する一方、未許可の読取り・書込みを増幅する結果を確認したい。続いてU-Fuzzの永続メモリ試験、AgentCoreのイベント実行と人間承認、Amazon Quickの利用者権限によるライブ照会を押さえる。CollageAttackが示す画像内の意味再構成と、説得より共鳴で強く観測されたエージェント間の過激化も、別々の安全性評価として重要だ。各更新は独立しているが、出力の正しさだけで運用可否を決めないという判断でつながる。

導入判断では、最終回答の正確性だけでなく、未許可の読取り・書込み、メモリ検索、画像内で再構成される意味、人間承認、利用者権限、対話による信念増幅を個別に検証する必要がある。各更新は別々の事象だが、表面に現れる出力だけでは捉えにくい失敗をどの段階で調べ、いつ人間の確認を挟むかという共通の運用課題を示している。（[出典1](https://arxiv.org/html/2609.39146v1) / [出典2](https://arxiv.org/html/2609.38275v1) / [出典3](https://aws.amazon.com/blogs/machine-learning/building-ambient-agents-with-amazon-bedrock-agentcore-from-event-driven-signals-to-human-in-the-loop-workflows/) / [出典4](https://aws.amazon.com/blogs/machine-learning/serve-live-governed-data-in-ai-built-apps-with-amazon-quick/) / [出典5](https://arxiv.org/abs/2609.38253) / [出典6](https://arxiv.org/html/2609.38296v1)）

## MADBench、質問応答の正確性攻撃を吸収し未許可の読取り・書込みを増幅

MADBenchは、マルチエージェント討論への攻撃が最終回答に与える影響と、敵対的影響の伝播を測るセキュリティ評価ベンチマークである。6攻撃群を、356件の元タスクから作成した3,958件のテストケースで評価する。（[出典1](https://arxiv.org/abs/2609.39146) / [出典2](https://arxiv.org/html/2609.39146v1)）

対象は、単一エージェント由来の直接プロンプトインジェクション、間接プロンプトインジェクション、RAGポイズニング、ツールハイジャックの4群と、討論固有の2群である。討論固有の2群は、悪意あるエージェントによる協調攻撃（M5）と、侵害されたオーケストレーター（M6）である。M5には、共通の誤答を目標に協調する共謀モード、各自が独立に誤答を選ぶ独立モード、相手ごとに矛盾する回答と根拠を送る不整合モードがある。M6はオーケストレーターのシステムプロンプトに悪意ある指示を加え、タスク配分と最終集約を操作する。（[出典1](https://arxiv.org/html/2609.39146v1)）

評価目標は、正解が利用できるタスクでの最終回答の正確性、トークン消費量、少なくとも1体の善良なエージェントによる許可範囲外ファイルの読取りと許可範囲外ファイルへの書込みである。増幅係数は、攻撃成功率、未許可の読取り・書込み率、コストの各指標について、討論での値を単一エージェントでの値で割った比で、1未満を吸収、1超を増幅とする。（[出典1](https://arxiv.org/html/2609.39146v1)）

MADBenchの著者らの評価では、討論は質問応答タスクの正確性に対する攻撃を吸収した一方、質問応答とワークスペースの両タスクで未許可の読取り・書込みを増幅した。RAGポイズニングでは、討論により質問応答の正確性に対する攻撃成功率が単一エージェント基準の74%（増幅係数0.74）に下がった。（[出典1](https://arxiv.org/html/2609.39146v1)）

各エージェントは、特記がない限りホスト型API経由でgpt-4oを使う。著者らによると、gpt-4oで5体中3体が共謀した構成では、攻撃なしで正解したタスクのうち28.30%で最終回答が誤答に変わった。当初正解していた善良なエージェントが討論中に誤答へ転じた割合は3.26%だった。同じ共謀構成でオーケストレーターと討論エージェントのモデルをGPT-5、GPT-6 Astraに替えると、この攻撃成功率は6.90%、3.28%だった。（[出典1](https://arxiv.org/abs/2609.39146) / [出典2](https://arxiv.org/html/2609.39146v1)）

> [!CAUTION] 確認できていない点
> モデル別の比較はM5の共謀モード（3体共謀）に限られ、他の攻撃群やワークスペースタスクでのモデル別指標は確認できない。

**比較表: 単一エージェント基準に対する吸収と増幅**

増幅係数は、攻撃の影響が単一エージェント基準より小さければ吸収、大きければ増幅と判定する。MADBenchでは、正確性と未許可操作で異なる結果が出た。（[出典1](https://arxiv.org/html/2609.39146v1)）

| 観点 | 吸収 | 増幅 |
| --- | --- | --- |
| 増幅係数の判定 | 単一エージェント基準との比較で1未満。（[出典1](https://arxiv.org/html/2609.39146v1)） | 単一エージェント基準との比較で1超。（[出典1](https://arxiv.org/html/2609.39146v1)） |
| 評価で観測した対象 | 質問応答タスクの正確性に対する攻撃。（[出典1](https://arxiv.org/html/2609.39146v1)） | 質問応答とワークスペースの両タスクにおける未許可の読取り・書込み。（[出典1](https://arxiv.org/html/2609.39146v1)） |

**EastBraverの見立て:** 討論の導入を一律の安全性向上とみなすべきではない。正確性への攻撃は吸収し得る一方、権限外の読取り・書込みは増幅し得るため、回答品質と操作権限を分けて評価する必要がある。（[出典1](https://arxiv.org/html/2609.39146v1)）

- 出典: [arXiv](https://arxiv.org/abs/2609.39146)（原著論文（プレプリント）、2026-10-01 13:00 JST）

**関連する技術ガイド:** [プロンプトインジェクション](/guides/prompt-injection) / [RAG](/guides/rag)

## U-Fuzz、正しい永続メモリの利用失敗を条件別に検出

論文著者らによると、保存内容が正しくても、要求の言い換えで適切なメモリが検索されない、別の記録に置き換わる、更新後も古い記録が新しい値より上位になる、といった利用失敗が起こり得る。通常の要求や更新でも発生し、保存項目に異常がない場合も含まれる。（[出典1](https://arxiv.org/html/2609.38275v1)）

著者らは、メモリ状態を固定して要求を変える「クエリ関連失敗」と、要求を固定して保存メモリを変える「メモリ状態失敗」に分類した。U-Fuzzは通常の対話から作ったチェックポイントと対応クエリを種に、要求または保存情報の片方を変異させる。各変異は実行前に検証する。（[出典1](https://arxiv.org/html/2609.38275v1)）

著者らは、複数のメモリシステムとベンチマークにおいて、同じ実行予算ならU-Fuzzが多様なベースラインより多くの固有なメモリ利用失敗を一貫して発見したと報告した。検索過程を隠して最終応答だけを観測する条件でも、固有かつエンドツーエンドの失敗をベースラインより多く発見したという。（[出典1](https://arxiv.org/html/2609.38275v1)）

評価対象は、検索過程を観測できるMem0、A-Mem、Graphiti、MemOSの4メモリシステムと、LoCoMo、LongMemEval-Sの2ベンチマークである。実行予算をLoCoMoで8,000、LongMemEval-Sで4,000に固定した3回平均で、U-FuzzがLoCoMoで発見した固有失敗はMem0で45.3件、A-Memで73.3件、Graphitiで62.0件、MemOSで53.7件だった。（[出典1](https://arxiv.org/html/2609.38275v1)）

> [!CAUTION] 確認できていない点
> 検索過程を公開しない商用メモリ機能への適用結果は確認できない。

**比較表: U-Fuzzが分ける2種類のメモリ利用失敗**

変化させる入力を片方に限定し、要求に起因する失敗と保存状態に起因する失敗を区別する。（[出典1](https://arxiv.org/html/2609.38275v1)）

| 観点 | クエリ関連失敗 | メモリ状態失敗 |
| --- | --- | --- |
| 固定するもの | メモリ状態を固定する。（[出典1](https://arxiv.org/html/2609.38275v1)） | 要求を固定する。（[出典1](https://arxiv.org/html/2609.38275v1)） |
| 変えるもの | 要求を言い換えるか、別の対応対象へ向けるか、未対応化する。（[出典1](https://arxiv.org/html/2609.38275v1)） | 保存情報を更新、削除、または無関係な情報について変更する。（[出典1](https://arxiv.org/html/2609.38275v1)） |
| 失敗例 | 同義の言い換えで検索結果が変わる、または未対応の質問で無関係な記録を検索する。（[出典1](https://arxiv.org/html/2609.38275v1)） | 古い値が残る、競合記録を誤処理する、または削除済みメモリを検索する。（[出典1](https://arxiv.org/html/2609.38275v1)） |

**EastBraverの見立て:** 永続メモリの評価では、保存内容の正しさだけで合否を決められない。要求を変える軸と保存状態を変える軸を分けることで、検索から最終応答までの利用失敗を切り分けやすくなる。（[出典1](https://arxiv.org/html/2609.38275v1)）

- 出典: [arXiv](https://arxiv.org/abs/2609.38275)（原著論文（プレプリント）、2026-10-01 13:00 JST）

**関連する技術ガイド:** [AI AgentのMemory](/guides/memory) / [AI Agent評価](/guides/ai-agent-evaluation)

## AgentCoreでイベント検知から人間の承認までをつなぐ構成

Amazon Bedrock AgentCoreのリファレンス実装は、イベントからジョブを生成してAgentCore Runtime上のエージェントを呼び出し、結果や人間への入力要求をAmazon DynamoDBへ戻す一連の構成を示した。人間への問い合わせは単一のask_humanツールと共通の応答エンベロープで扱われ、エージェントが応答を求めるとジョブはinterrupted状態になる。（[出典1](https://aws.amazon.com/blogs/machine-learning/building-ambient-agents-with-amazon-bedrock-agentcore-from-event-driven-signals-to-human-in-the-loop-workflows/)）

Amazon S3へのファイルアップロードでは、通知を受けたSignal Processor Lambdaがambient-signalsテーブルから一致するシグナルを検索し、ジョブを作成する。API層またはスケジューラーがAmazon SQSへジョブを投入し、Job Execution Lambdaがエージェントを呼び出して処理結果をDynamoDBへ書き戻す。（[出典1](https://aws.amazon.com/blogs/machine-learning/building-ambient-agents-with-amazon-bedrock-agentcore-from-event-driven-signals-to-human-in-the-loop-workflows/)）

React製の画面はAmazon CloudFront経由でAmazon S3から配信され、API Gateway／Lambda層をポーリングする。エージェントがask_humanを通じて応答を求めると、ジョブのrequiresActionが有効になり、利用者はJobs画面のInterruptedタブで質問や承認待ちの操作に対応できる。利用者が回答すると、Job Execution Lambdaが回答を継続プロンプトに含めてエージェントを再度呼び出す。（[出典1](https://aws.amazon.com/blogs/machine-learning/building-ambient-agents-with-amazon-bedrock-agentcore-from-event-driven-signals-to-human-in-the-loop-workflows/)）

実行開始時の人間の関与はシグナル単位で切り替わる。既定のautoExecuteがfalseではジョブをidle状態で止めて確認と実行を待つ。autoExecuteがtrueでは直ちにワーカーキューへ送り、実行中にエージェントがask_humanを呼んだ場合だけ人間を介在させる。（[出典1](https://aws.amazon.com/blogs/machine-learning/building-ambient-agents-with-amazon-bedrock-agentcore-from-event-driven-signals-to-human-in-the-loop-workflows/)）

記事掲載時点でサンプルに実装済みのイベント源は、Amazon S3へのファイルアップロードとスケジュール実行である。API Webhookとデータベース変更は、対応するハンドラーLambdaとSignals画面の入力項目を追加する拡張ポイントとして示されている。（[出典1](https://aws.amazon.com/blogs/machine-learning/building-ambient-agents-with-amazon-bedrock-agentcore-from-event-driven-signals-to-human-in-the-loop-workflows/)）

**比較表: autoExecuteによる実行開始と人間介在の違い**

設定は、人間がジョブ開始前に確認するか、即時実行後にask_humanが必要になった時だけ応答するかを切り替える。（[出典1](https://aws.amazon.com/blogs/machine-learning/building-ambient-agents-with-amazon-bedrock-agentcore-from-event-driven-signals-to-human-in-the-loop-workflows/)）

| 観点 | autoExecuteがfalse | autoExecuteがtrue |
| --- | --- | --- |
| ジョブの開始 | 既定設定。idle状態で人間の確認と実行を待つ。（[出典1](https://aws.amazon.com/blogs/machine-learning/building-ambient-agents-with-amazon-bedrock-agentcore-from-event-driven-signals-to-human-in-the-loop-workflows/)） | ジョブを直ちにワーカーキューへ投入し、エージェントを実行する。（[出典1](https://aws.amazon.com/blogs/machine-learning/building-ambient-agents-with-amazon-bedrock-agentcore-from-event-driven-signals-to-human-in-the-loop-workflows/)） |
| 人間が関与する時点 | エージェントの実行前に人間が確認する。（[出典1](https://aws.amazon.com/blogs/machine-learning/building-ambient-agents-with-amazon-bedrock-agentcore-from-event-driven-signals-to-human-in-the-loop-workflows/)） | 実行中にエージェントがask_humanを呼んだ場合だけ人間が関与する。（[出典1](https://aws.amazon.com/blogs/machine-learning/building-ambient-agents-with-amazon-bedrock-agentcore-from-event-driven-signals-to-human-in-the-loop-workflows/)） |

**EastBraverの見立て:** この構成で分けて考えるべき境界は、ジョブ開始前の確認と実行中の割り込みである。autoExecuteの設定が前者を、ask_humanによる中断状態が後者を担う。（[出典1](https://aws.amazon.com/blogs/machine-learning/building-ambient-agents-with-amazon-bedrock-agentcore-from-event-driven-signals-to-human-in-the-loop-workflows/)）

- 出典: [AWS](https://aws.amazon.com/blogs/machine-learning/building-ambient-agents-with-amazon-bedrock-agentcore-from-event-driven-signals-to-human-in-the-loop-workflows/)（公式情報、2026-10-02 01:40 JST）

**関連する技術ガイド:** [Human-in-the-Loop](/guides/human-in-the-loop) / [AI Agent](/guides/ai-agent)

## Amazon Quick、Live Data in AppsでSPICE／Direct Queryをライブ参照

Amazon QuickのLive Data in Appsにより、AI生成アプリは統制済みQuick Sightデータセットをリアルタイムに照会できるようになった。従来は構築時に数値が埋め込まれ、公開時点の静的スナップショットだったが、公開済みアプリからSPICEとDirect Queryの両データセットをライブ参照できる。（[出典1](https://aws.amazon.com/blogs/machine-learning/serve-live-governed-data-in-ai-built-apps-with-amazon-quick/)）

公開後は、アプリを開くたびに構築時と同じSQLが利用者の権限で再実行され、既存の行レベルセキュリティ（RLS）と列レベルセキュリティ（CLS）が適用される。利用者は認証済みのQuickユーザーである必要があり、構築者と利用者のどちらにも最低でもReader Pro（Professional）ロールが必要になる。匿名・公開アクセスには対応しない。データセットごとの初回同意はサーバー側でクエリごとに検証され、構築者も構築中にデータセットを承認する。（[出典1](https://aws.amazon.com/blogs/machine-learning/serve-live-governed-data-in-ai-built-apps-with-amazon-quick/)）

AWSによると、表示の鮮度条件はデータセット方式で異なる。SPICEではデータセットを更新するとアプリの表示も更新され、Direct Queryではデータセットの更新は不要になる。（[出典1](https://aws.amazon.com/blogs/machine-learning/serve-live-governed-data-in-ai-built-apps-with-amazon-quick/)）

クエリと結果サイズにはガードレールがあり、転送可能量を超える場合は不完全な結果を返さず、クエリを絞るよう促す。大きな結果が必要な場合は、エージェントに集約データの取得を依頼するか、ページ分割の実装を指示する。また、列名の変更や列の削除後は、アプリ内のクエリを再構築する必要がある。（[出典1](https://aws.amazon.com/blogs/machine-learning/serve-live-governed-data-in-ai-built-apps-with-amazon-quick/)）

> [!CAUTION] 確認できていない点
> 監査ログのイベント名、利用者識別情報、保存条件は取得した資料では確認できない。

**比較表: ライブ表示の更新条件**

どちらもライブ照会の対象だが、アプリに最新内容を反映する条件が異なる。（[出典1](https://aws.amazon.com/blogs/machine-learning/serve-live-governed-data-in-ai-built-apps-with-amazon-quick/)）

| 観点 | SPICE | Direct Query |
| --- | --- | --- |
| 更新処理 | データセットの更新が必要。（[出典1](https://aws.amazon.com/blogs/machine-learning/serve-live-governed-data-in-ai-built-apps-with-amazon-quick/)） | 更新処理は不要。（[出典1](https://aws.amazon.com/blogs/machine-learning/serve-live-governed-data-in-ai-built-apps-with-amazon-quick/)） |
| アプリへの反映 | データセットの更新後にアプリの表示が更新される。（[出典1](https://aws.amazon.com/blogs/machine-learning/serve-live-governed-data-in-ai-built-apps-with-amazon-quick/)） | データセットの更新を待たずにアプリへ反映される。（[出典1](https://aws.amazon.com/blogs/machine-learning/serve-live-governed-data-in-ai-built-apps-with-amazon-quick/)） |

**EastBraverの見立て:** 採用判断では、ライブ参照の可否だけでなく、SPICEの更新運用とDirect Queryの直接参照を分けて考える必要がある。権限制御は既存ルールを継承できる一方、結果量の抑制と列変更時のクエリ再構築はアプリ運用側の責任として残る。（[出典1](https://aws.amazon.com/blogs/machine-learning/serve-live-governed-data-in-ai-built-apps-with-amazon-quick/)）

- 出典: [AWS](https://aws.amazon.com/blogs/machine-learning/serve-live-governed-data-in-ai-built-apps-with-amazon-quick/)（公式情報、2026-10-02 04:49 JST）

**関連する技術ガイド:** [Guardrails](/guides/guardrails)

## CollageAttackが突くT2Iモデルのクロスモーダル安全性

論文著者らが示した弱点は、個別には明示性の低い文字断片でも、生成後の画像内で空間的に構成されると意図した有害な意味を再構成できるという、T2Iモデルのクロスモーダル安全性の隙間である。（[出典1](https://arxiv.org/abs/2609.38253)）

CollageAttackは、文脈に沿った場面、場面に接地した文字媒体、空間的に分散した文字断片を組み合わせ、意味の組み立てを画像平面へ移す、自動化された単一プロンプト型のブラックボックス脱獄攻撃として提案された。（[出典1](https://arxiv.org/abs/2609.38253)）

評価対象は、商用のGPT-Image-2、Doubao-Seedream-5.0-Lite、Wan2.7-Image-Proと、オープンウェイトのHiDream-O1-Image、FLUX.2の5モデルである。著者らによると、攻撃成功率は最大86.0％に達し、同一モデル上の最強ベースラインを18.5ポイント上回った。（[出典1](https://arxiv.org/abs/2609.38253) / [出典2](https://arxiv.org/html/2609.38253v1)）

> [!CAUTION] 確認できていない点
> 論文は各モデルの既存の安全機構に追加の防御策を重ねた条件を評価しておらず、防御を追加した場合の成立条件は確認できない。

**EastBraverの見立て:** 防御評価を個々の文字要素だけで完結させず、生成画像上で再構成される意味まで評価対象に含めることが、この攻撃を捉える分岐点になる。（[出典1](https://arxiv.org/abs/2609.38253)）

- 出典: [arXiv](https://arxiv.org/abs/2609.38253)（原著論文（プレプリント）、2026-10-01 13:00 JST）

## LLMエージェントの過激化、説得より共鳴で強く観測

Seckinらは、感情面・行動面の尺度で説得と共鳴の双方が標的を過激化させたものの、既存信念とメッセージが整合する共鳴の効果が一貫して強く、関連する信念にも波及したと報告した。（[出典1](https://arxiv.org/html/2609.38296v1)）

主実験では標的と影響者の両方にLlama-3.1-8B-Instructを使用し、頑健性検証としてQwen3-8Bでも主要な結果を再現した。標的は、2024年General Social Surveyの社会人口学的・心理的属性に基づく3,309種類の人物像を演じた。（[出典1](https://arxiv.org/html/2609.38296v1)）

影響者は、標的が重要でないとした信念を強める説得と、重要とした既存信念を増幅する共鳴に分けて対話し、それぞれに過激化を狙わない中立的な対照条件が置かれた。対話は30ターンで、5ターンごとに感情面・行動面の質問票を実施し、質問票のやり取りは後続の対話履歴から除外した。（[出典1](https://arxiv.org/html/2609.38296v1)）

指標は、信念の重要度（5段階）、支持者と反対者への感情温度差（0〜100の感情温度計）、月あたりの金銭的関与、週あたりの時間的関与、暴力化し得る抗議への参加意向（5段階）、信念を守るための戦争への賛同（5段階）の6つである。ガードレールが回答に影響した可能性のある応答を除いて再分析しても、共鳴が説得より強いという結果は定性的に変わらなかった。（[出典1](https://arxiv.org/html/2609.38296v1)）

> [!CAUTION] 確認できていない点
> 論文は過激化への防御策を評価しておらず、どの対策が共鳴による増幅を抑えるかは確認できない。

**比較表: 説得条件と共鳴条件の比較**

両条件で過激化が観測されたが、共鳴は説得より一貫して強く、関連する信念への波及も報告された。（[出典1](https://arxiv.org/html/2609.38296v1)）

| 観点 | 説得 | 共鳴 |
| --- | --- | --- |
| 対象となる信念 | 標的が重要でないとした信念。（[出典1](https://arxiv.org/html/2609.38296v1)） | 標的が重要とした既存信念。（[出典1](https://arxiv.org/html/2609.38296v1)） |
| 影響者の働きかけ | 選んだ信念について、標的をより極端な立場へ動かそうとする。（[出典1](https://arxiv.org/html/2609.38296v1)） | 既存信念に沿って、標的を過激化させようとする。（[出典1](https://arxiv.org/html/2609.38296v1)） |
| 観測された結果 | 感情面・行動面の尺度で過激化が報告された。（[出典1](https://arxiv.org/html/2609.38296v1)） | 過激化の効果が説得より一貫して強く、関連する信念にも波及した。（[出典1](https://arxiv.org/html/2609.38296v1)） |

**EastBraverの見立て:** 評価上の焦点は、新しい信念を植え付ける説得だけでなく、既存信念と整合する共鳴が増幅と波及を起こす点にある。ただし、主実験は8B級の単一モデルを両役に用いた条件で、頑健性検証もQwen3-8Bの1モデルに限られる。（[出典1](https://arxiv.org/html/2609.38296v1)）

- 出典: [arXiv](https://arxiv.org/abs/2609.38296)（原著論文（プレプリント）、2026-10-01 13:00 JST）

**関連する技術ガイド:** [AI Agent評価](/guides/ai-agent-evaluation) / [AI Agent](/guides/ai-agent)

## ほかの確認済みの更新

本文と同じ方法で根拠を確認した更新を、要点だけ短くまとめる。

- **Cloudflare、型付き回答を確率付きで返す決定モデルClefをWorkers AIで提供**：Cloudflareは、文章を生成せず、入力状態と型付きの質問に対して許可された回答ごとの確率を返す決定モデル「Clef」（27B）と「Clef-flash」（9B）をWorkers AIで公開した。質問型は`noul`、`choice`、`score`の3種類で、重みはApache 2.0でHugging Faceに公開されている。ベンチマーク結果はCloudflareの自社評価である。（[出典1](https://developers.cloudflare.com/changelog/post/2026-10-01-clef-workers-ai/) / [出典2](https://blog.cloudflare.com/clef-decision-models/)）
- **AWSのStrands Labs、ローカル実行できる決定モデルStrands Decider 2Bを公開**：Qwen3.5-2B-Baseを基にした約19億パラメーターの決定モデルで、Clefと同じ3種類の質問型に確信度付きで答える。コード、学習レシピ、評価はApache 2.0で公開された。リポジトリはJevBenchの正答率0.723（231課題中167課題）を示す一方、6回の再学習で標準偏差が3.2課題あったため、約10課題未満の差は未決として扱うよう注記している。（[出典1](https://github.com/strands-labs/strands-decider) / [出典2](https://huggingface.co/StrandsAgents/strands-decider-2B-hobson-v19)）