AIエージェント × Skills中心設計

Transcript

1. AIエージェント × Skills中心設計 コンテキスト制約と業務フロー分解の設計思想 2026.03.16
2. 目次 01 命題 — コンテキスト制約 AIの文脈は有限資源 02 解法 — 業務フロー分解 + Skills設計 5つの設計原則 03 Skill中心アーキテクチャ 3層構造と原則の対応 04 マスター/サブエージェント構成 運用アーキテクチャ例 05 Skills設計原則（ 6つ） 実践的な設計ガイドライン 06 RAG依存 vs Skill+Script設計 比較とコスト効果 07 具体業務フローへの当てはめ PoC例 08 まとめ — Next Action 結論と次のステップ
3. 01 命題 — コンテキスト制約 AIエージェントの文脈（コンテキスト）は有限資源である コスト増大 入力・出力が長くなるほど トークン消費は増えやすい 応答遅延 入力・出力が長くなるほど 応答は遅くなりやすい 精度低下 文脈が長大になると 重要情報の取りこぼしが起 きやすい 文脈崩壊 情報量が増えすぎると 重要な前提が埋もれる場合 がある 全部を長いプロンプトに詰め込む設計は、持続的な運用に限界が出やすい
4. 02 解法 — 業務フロー分解 + Skills設計 「全部覚えさせる」のではなく「必要な時に必要な能力を起動する」 5つの設計原則 # 原則 一言 1 Context is finite 文脈は有限資源として管理する 2 Skills are capability units 能力はSkill単位で分解する 3 Knowledge is loaded on demand 知識は必要時に読み込む 4 Separate reasoning & execution 判断と実行を分離する 5 Systems must fail gracefully 失敗を前提に安全に設計する
5. 03 Skill中心アーキテクチャの全体像 Flow（業務フロー） • Phase順にSkillを連結 • 人間承認ゲートを • 明示的に配置 Skill（業務能力パッケージ） • 手順書 (SKILL.md) • 参考資料 (references/) • 自動処理 (scripts/) • テンプレート (assets/) 外部接続 • 社内DB / ナレッジベース • 外部API / RAG検索 原則との対応 原則 対応する設計要素 Context is finite Skill本文は短く保ち、詳細は参考資料へ分離 ※例: 5,000 tokens未満を目安 Skills are capability units 1 Skill = 1責務のパッケージとして設計する Knowledge on demand metadata → 手順書 → 参考資料の順で段階的に読む Reasoning ≠ Execution 判断はモデル、定型実行は scriptsや外部APIへ委譲する Graceful failure 人間承認ゲート / fallback / retry を前提に設計する
6. 04 マスター/サブエージェントと Skillの関係 単一エージェント + Skillsでも成立する。業務分業や並列化が必要な場合は、この構成が有効になりやすい。 マスターエージェント（オーケストレーター） • Flow判定（意図→業務フロー選択） • Skill→エージェント割り当て • 進捗監視・人間承認ゲート管理 サブAgent A • 企画 • 執筆 • レビュー サブAgent B • コード生成 • テスト サブAgent C • リサーチ • 分析 共有リソース — Knowledge（社内DB・Notion）/ Tools（外部API・連携サービス）
7. 05 Skills設計原則（ 6つ） 1 Skill 1責務 FAQ回答と議事録整形は分ける。 起動条件が明確になり、誤発火を抑えやすい Skill本文は薄く、詳細は分離 手順書は短く保ち、例外集や仕様書は 参考資料へ ※例: 5,000 tokens未満を目安 知識は読む単位を小さくする マニュアル丸ごとではなく FAQ・ルール・判定基準に分割する RAGは主に検索、scriptは主に実行 検索・想起はRAG、請求計算・帳票変換・ 在庫集計などの定型処理は scriptが担う 決定的処理はモデルに任せすぎない 金額計算・フォーマット変換・バリデーション は可能な限り決定的な処理系へ委譲する 長い処理は要約・圧縮前提 中間ログは要点を残し、次工程へ 渡す情報を圧縮する
8. 06 RAG依存 vs Skill+Script設計 ※以下は一般的な傾向であり、個別実装によって逆転しうる 観点 RAG依存設計 Skill+Script設計 知識取得 強い 強い 定型処理 相対的に弱い 相対的に強い 再現性 中 高めやすい コスト制御 中 高めやすい 文脈節約 弱め 強い 保守性 文書品質に依存しやすい 構造化しやすい 段階ロードのコスト効果 metadata name + description ~100 words ▼ 必要時 手順書 SKILL.md本文 ~5,000 tokens ▼ 必要時 参考資料 references/ 必要時のみ 検索強化だけでは業務自動化は完結しない場合がある。検索可能性と実行可能性の両方を設計することが重要。 RAGは“思い出させる”仕組み、scriptは“やり切る”仕組み
9. 07 具体業務フローへの当てはめ（ PoC例） クライアントの実際の業務 1つを選び、以下の観点で当てはめる Skill この業務のどこがSkillになるか Script どこが自動処理になるか 承認ゲート どこで人が判断するか Knowledge どの知識を参照するか 当てはめの構造 対象業務: [ 業務名 ] Phase 1: [ 〇〇 ] → Skill: [ 〇〇 ] Phase 2: [ 〇〇 ] → Skill: [ 〇〇 ] + Script: [ 〇〇 ] Phase 3: [ 〇〇 ] → 人間承認ゲート Phase 4: [ 〇〇 ] → Skill: [ 〇〇 ] TODO: クライアントの実際の業務を選定し、ワークショップで当てはめを実施
10. 08 まとめ — なぜ業務フロー分解が重要か コンテキスト制約 → Skills設計が必要 → 業務フローの適切な分解が重要 結論 文脈を有限資源として扱う Skillは小さく責務分離する Knowledgeは必要時参照に限定する 再現性と効率が求められる処理は scriptへ委譲する 最新潮流（補足） Agent Skills — 主要ベンダー間で類似パターンが見られ、ポータビリティ向上の兆しがある 段階ロード前提の設計 — コスト・速度・精度のバランス改善に寄与しやすい Code execution / scripts — ツール接続が増える実務環境で有効な設計要素になりやすい Next Action: PoC対象業務の選定 / 具体業務での Skill分解ワークショップ