Upgrade to Pro — share decks privately, control downloads, hide ads and more …

インバスケット試験対策アプリを 作って見えたAIエージェント構築 ナレッジ2選

Avatar for ShichijoYuhi ShichijoYuhi
September 29, 2026

インバスケット試験対策アプリを 作って見えたAIエージェント構築 ナレッジ2選

Avatar for ShichijoYuhi

ShichijoYuhi

September 29, 2026

More Decks by ShichijoYuhi

Other Decks in Technology

Transcript

  1. 03 自己紹介 自己紹介 シチジョウ ユウヒ 七條 雄飛 所属 NTT東日本 関心

    生成AI / AIエージェント / 長期記憶 そのほか AWS Community Builders AI Engineering (1年生) 2026Japan All AWS Certifications Engineers Xアカウント @nanaj_7_o
  2. 04 今日話したいこと 今日話したいこと レイテンシーが許容されるなら、成果物の監査 -> プラン -> 修正 のサイクルを取り入れよう 監査Agentによる指摘、安直な修正で終わらせずに、プランニングが大事

    マルチAgentが共有できる、メモリDBのハーネスを設計する 監査 -> 修正のサイクルを回す際の変更差分をメモすることで、 作業エージェントの消費トークン現象 & 不要なノイズ情報除去ができる
  3. 05 インバスケット試験とは 実際に起こりうるトラブルを、限られた時間で処理する試験 実際の試験のイメージ 1 次々に届く 業務情報 • 上司からの指示 •

    部下からの相談 • 取引先からの依頼 • 会議資料 • クレーム対応 2 制限時間内に 処理方法を考える どれを優先する? 誰に任せる? どう進める? 評価されるといわれている能力 3 案件ごとに 方針を記述 対応方針 • 優先順位 • 具体的な行動 1 2 3 • 関係者への連絡 • スケジュール 4 未処理 5 判断力 状況を正しく捉えて判断する 優先順位づけ 重要度・緊急度を見極める 時間管理 限られた時間を配分する 対人対応 関係者の立場を踏まえる 問題解決 実行可能な対応策を考える
  4. 07 最初にぶつかった問題 友人レビューで、生成品質と運用コストの問題が見えた 依頼してくれた友人のレビューをもらいながら改善を続けたが、 当初の生成結果は、そのまま試験対策に使える品質ではなかった。 QUALITY TIME / COST 問題と選択肢の間に

    論理的な矛盾が発生する 問題生成に時間がかかり、 AI利用料金のアラートが届く 案件本文・設問・選択肢を別々に生成すると、 前提条件や正解理由が食い違う。 論理の不整合問題を解消すること目的に、 各専門エージェントにタスクを分割するマルチエージェントを 構想したが、待ち時間とToken消費が膨れ上がり、断念。
  5. 08 演習世界モデルの設計 インバスケット試験の演習を紐解くと、単純な一問一答の世界観ではない 演習世界モデル = 業務テーマ × 登場人物・組織 × 時間・状態

    × 成果物・制約 01 03 業務テーマ どの判断領域を扱うか 02 登場人物・組織 誰が、どの権限と責任で関わるか 製品安全・品質 顧客・SLA・納期 • 所属・役職・担当領域・専門性 労務・人身安全・育成 法務・証拠保全・統制 • 指揮命令・相談・委任・社外関係 時間・状態 いつ、何が、どこまで確定したか • 権限・承認境界・予定 04 成果物・制約 • 発生時刻 / 受信時刻 / 期限 • 要求成果物 / 参照資料 / 模範回答 • 状態遷移と優先順位の変化 • 承認条件 / 禁止事項 / 完了条件 • 確定事実 / 未確認事項 / 後着情報 • 固定数値 / 契約条件 / 安全条件 作るもの/変えない条件
  6. 09 今回の演習生成フロー 演習生成タスク自体は3つのセクションに分割。 演習のコアになる部分(ストーリー)を最初に決めきるワークフロー設計 ストーリーアウトライン タスク・資料へ詳細化 全体整合性を監査 • 4つの設計軸を定義 •

    業務メール型タスクを作成 • 名称・数値・権限を固定化し て、構造化データとして管理 • 参照資料と時系列を展開 • タスク・資料・時系列を横 断 • 模範回答・評価観点を作成 コンテキスト • 修正PLANを先に作成 • REPAIR後に再監査
  7. 10 今回の演習生成フロー 演習生成タスク自体は3つのセクションに分割。 演習のコアになる部分(ストーリー)を最初に決めきるワークフロー設計 ストーリーアウトライン タスク・資料へ詳細化 全体整合性を監査 • 4つの設計軸を定義 •

    業務メール型タスクを作成 • 名称・数値・権限を固定化し て、構造化データとして管理 • 参照資料と時系列を展開 • タスク・資料・時系列を横 断 • 模範回答・評価観点を作成 コンテキスト • 修正PLANを先に作成 • REPAIR後に再監査
  8. 11 ストーリーコンテキストの実体 共有するコンテキストは文章ではなく、Pydanticの構造化データ StoryBibleOutput { } // actual fields (excerpt)

    "incident": "...", "initialFacts": ["..."], "hiddenConnections": ["..."], "storyThreads": {"major-01": "..."}, "fixedNumbers": {"lot": "..."}, "organizationHierarchy": [...], "teamMembers": [{ "name": "...", "role": "...", "specialty": "...", "scheduleEntries": [...] }], "respondentAuthority": [...], "respondentConstraints": [...] 構造化して共有する価値 共通のKey管理 氏名・数値・期限・権限 を、全Agentが同じkeyで 参照する 決定論的な バリデーションが可能 決定論的に検査可能なため 再現性の担保に寄与。 (Jev程のお手軽さはないです が、再現性を重視される方に 個人的にオススメ) 構造化データ管理によるバリデーション例 型・必須 固定値・参照 時系列・権限 type / enum 数量、各種ID ロール別の優先順位
  9. 12 試験問題生成に合わせた構成 Strands Agentsで紹介されているデザインパターンを参考に、3種類で比較 A SINGLE B 単一のAgentが順次実行 story task

    × 5 editorial GRAPH C 依存関係と実行順をedgeで固定 統括Agentがspecialist Agentをtoolとして選ぶ task 1 orchestrator story task 2 edit task 3 向く場面:認知負荷を最小にしたい AGENT AS TOOLS 向く場面:依存順が明確 / 並列化したい story tasks edit 向く場面:専門性 / tool / 権限を分離したい
  10. 13 実測比較 モデルはGPT5.6-luna。コスト面や矛盾の数を優先して、シングルモデルが有力 構成 実行時間 Token 推定Cost 矛盾の指摘数 Single Agent

    536.1秒 733k $0.200 0.5件 Graph 404.8秒 752k $0.212 4.5件 Agent as Tools 619.5秒 1,189k $0.317 0.5件 GPT5.6-lunaは100万トークン処理可能なロングコンテキスト対応モデル。 無理やり全部持たせても、今回は処理できた。 Graphが指摘数多かった理由を深ぼってみると、、、
  11. Graph:失敗から対策へ 14 監査指摘の修正を行うことで、他エージェント間でgapが発生。 DynamoDB Localを共有メモリにすることで端的に修正情報を伝える prompt内のlocal contextだけで 自己修正 BEFORE AFTER

    共有メモリを用意することで、効率的な情報伝播 設問Agent A Story nodeの構造化要約 設問Agent A 設問Agent B 設問Agent C 監査NG → 自己修正 監査NG → 自己修正 監査NG → 自己修正 改善差分は、ほかのAgentへ共有されない 統合時に人物・期限・前提が不一致 設問Agent B DynamoDB Local 全Agentが参照する共有メモリ 監査/修正 Agent 設問Agent C
  12. 16 監査Agentで大事なこと REVIEWとREPAIRの間に、PLANを入れる。 他のエージェントに与える影響の全体プランニングが重要。 MOST IMPORTANT REVIEW 矛盾・漏れを列挙 PLANがない PLAN

    REPAIR 計画どおりに修正 影響する成果物を特定 守るべき前提を固定 修正順序を決める 完了条件を定義 指摘をその場で直す → 別の成果物に矛盾 PLANがある 全体影響 → 修正順 → 実装 → 完了確認 再監査