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

JAWS-UG AI/ML #43：AIエージェントとAI-DLCで加速する！AI/ML実践LT大会 登壇資料

https://jawsug-ai.connpass.com/event/406132/?utm_campaign=event_message_to_selected_participant&utm_source=notifications&utm_medium=email&utm_content=title_link

Transcript

1. JAWS-UG AI/ML #43 インバスケット試験対策アプリを 作って見えたAIエージェント構築 ナレッジ2選 2026 / 09 / 29 七條 雄飛
2. 02 アジェンダ アジェンダ 自己紹介 試験問題に合わせた構成 今日話したいこと 実測比較 インバスケット試験とは Graph：失敗から対策へ 作ってみたアプリ画面 監査Agentで大事なこと 今回の演習生成フロー ストーリーコンテキストの実体
3. 03 自己紹介 自己紹介 シチジョウ ユウヒ 七條 雄飛 所属 NTT東日本 関心 生成AI / AIエージェント / 長期記憶 そのほか AWS Community Builders AI Engineering (1年生) 2026Japan All AWS Certifications Engineers Xアカウント @nanaj_7_o
4. 04 今日話したいこと 今日話したいこと レイテンシーが許容されるなら、成果物の監査 -> プラン -> 修正 のサイクルを取り入れよう 監査Agentによる指摘、安直な修正で終わらせずに、プランニングが大事 マルチAgentが共有できる、メモリDBのハーネスを設計する 監査 -> 修正のサイクルを回す際の変更差分をメモすることで、 作業エージェントの消費トークン現象 & 不要なノイズ情報除去ができる
5. 05 インバスケット試験とは 実際に起こりうるトラブルを、限られた時間で処理する試験 実際の試験のイメージ 1 次々に届く 業務情報 • 上司からの指示 • 部下からの相談 • 取引先からの依頼 • 会議資料 • クレーム対応 2 制限時間内に 処理方法を考える どれを優先する？ 誰に任せる？ どう進める？ 評価されるといわれている能力 3 案件ごとに 方針を記述 対応方針 • 優先順位 • 具体的な行動 1 2 3 • 関係者への連絡 • スケジュール 4 未処理 5 判断力 状況を正しく捉えて判断する 優先順位づけ 重要度・緊急度を見極める 時間管理 限られた時間を配分する 対人対応 関係者の立場を踏まえる 問題解決 実行可能な対応策を考える
6. 作ってみたアプリ 演習プロンプトとパラメータで何回でも新規演習可能なwebアプリ 06
7. 07 最初にぶつかった問題 友人レビューで、生成品質と運用コストの問題が見えた 依頼してくれた友人のレビューをもらいながら改善を続けたが、 当初の生成結果は、そのまま試験対策に使える品質ではなかった。 QUALITY TIME / COST 問題と選択肢の間に 論理的な矛盾が発生する 問題生成に時間がかかり、 AI利用料金のアラートが届く 案件本文・設問・選択肢を別々に生成すると、 前提条件や正解理由が食い違う。 論理の不整合問題を解消すること目的に、 各専門エージェントにタスクを分割するマルチエージェントを 構想したが、待ち時間とToken消費が膨れ上がり、断念。
8. 08 演習世界モデルの設計 インバスケット試験の演習を紐解くと、単純な一問一答の世界観ではない 演習世界モデル ＝ 業務テーマ × 登場人物・組織 × 時間・状態 × 成果物・制約 01 03 業務テーマ どの判断領域を扱うか 02 登場人物・組織 誰が、どの権限と責任で関わるか 製品安全・品質 顧客・SLA・納期 • 所属・役職・担当領域・専門性 労務・人身安全・育成 法務・証拠保全・統制 • 指揮命令・相談・委任・社外関係 時間・状態 いつ、何が、どこまで確定したか • 権限・承認境界・予定 04 成果物・制約 • 発生時刻 / 受信時刻 / 期限 • 要求成果物 / 参照資料 / 模範回答 • 状態遷移と優先順位の変化 • 承認条件 / 禁止事項 / 完了条件 • 確定事実 / 未確認事項 / 後着情報 • 固定数値 / 契約条件 / 安全条件 作るもの／変えない条件
9. 09 今回の演習生成フロー 演習生成タスク自体は3つのセクションに分割。 演習のコアになる部分(ストーリー)を最初に決めきるワークフロー設計 ストーリーアウトライン タスク・資料へ詳細化 全体整合性を監査 • 4つの設計軸を定義 • 業務メール型タスクを作成 • 名称・数値・権限を固定化し て、構造化データとして管理 • 参照資料と時系列を展開 • タスク・資料・時系列を横 断 • 模範回答・評価観点を作成 コンテキスト • 修正PLANを先に作成 • REPAIR後に再監査
10. 10 今回の演習生成フロー 演習生成タスク自体は3つのセクションに分割。 演習のコアになる部分(ストーリー)を最初に決めきるワークフロー設計 ストーリーアウトライン タスク・資料へ詳細化 全体整合性を監査 • 4つの設計軸を定義 • 業務メール型タスクを作成 • 名称・数値・権限を固定化し て、構造化データとして管理 • 参照資料と時系列を展開 • タスク・資料・時系列を横 断 • 模範回答・評価観点を作成 コンテキスト • 修正PLANを先に作成 • REPAIR後に再監査
11. 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 ロール別の優先順位
12. 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 / 権限を分離したい
13. 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が指摘数多かった理由を深ぼってみると、、、
14. 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
15. Graph：失敗から対策へ 15 DynamoDB localの具体例紹介 マルチエージェント目線で共有メモリを作る利点 ◆ 後続で動くエージェントが更新内容を検知できる (最新版を把握できる) ◆ 万が一停止したとき、失敗したときの再開が用意 ◆ 必要なKey変更差分 (payloadのみを情報共有できるので、変わっていない 演習ストーリー全文を提供する必要がない)
16. 16 監査Agentで大事なこと REVIEWとREPAIRの間に、PLANを入れる。 他のエージェントに与える影響の全体プランニングが重要。 MOST IMPORTANT REVIEW 矛盾・漏れを列挙 PLANがない PLAN REPAIR 計画どおりに修正 影響する成果物を特定 守るべき前提を固定 修正順序を決める 完了条件を定義 指摘をその場で直す → 別の成果物に矛盾 PLANがある 全体影響 → 修正順 → 実装 → 完了確認 再監査
17. 17 まとめ まとめ Graphマルチエージェントでは、セルフ改善の差分を共有Memoryへ反映して、他エー ジェントも変更内容を気づけるようにしよう レイテンシーが許容されるなら、 成果物の監査 -> プラン -> 修正 のサイクルを取り入れよう