【T-02】AIエージェントフレームワークの設計思想 〜役割・記憶・自律性をどう実現するか〜
kome
🔧 TECH ARTICLE 🔧
〜 T-02 〜
AIエージェントフレームワークの設計思想
⚙️ はじめに
「AIに質問したら答えてくれる」――これだけなら、普通のチャットボットです。
でも、もしAIが自分でタスクを管理し、状況に応じて振る舞いを変え、外部のツールと連携できたら? それはもう「チャット」ではなく、自律的なエージェントです。
この記事では、AIエージェントを「賢く」動かすためのフレームワーク設計について、3つの柱を中心に解説します。
⚙️ このフレームワークで何を解決するのか?
▸ 要件定義:AIの課題
普通のAIチャットには、こんな限界があります:
❌ 1回の質問で忘れる → 前の会話を覚えていない
❌ 何でも同じ調子 → タスクに応じた専門性がない
❌ 手が動かない → ファイル操作やWeb検索ができない
❌ 段取りが悪い → 複雑なタスクの順序を管理できない
▸ ゴール:こんなAIが欲しい
✅ 文脈を理解して対話 → 過去の会話や作業状態を把握
✅ 状況に応じた専門家 → 設計の話なら設計者、テストならQA担当
✅ 自分で道具を使える → ファイル操作、Web検索、テスト実行
✅ 段取り上手 → タスクの優先度と依存関係を管理
⚙️ フレームワークの3本柱
このフレームワークは、3つの仕組みでAIを「自律的なエージェント」に変えます。
┌─────────────────────────────────────────────────┐
│ AIエージェントフレームワーク │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────────────┐ │
│ │ 柱 1 │ │ 柱 2 │ │ 柱 3 │ │
│ │ ペルソナ │ │ タスク │ │ 外部ツール連携 │ │
│ │ システム │ │ 管理 │ │ (MCP) │ │
│ │ │ │ │ │ │ │
│ │ 役割を │ │ 段取り │ │ 手足を │ │
│ │ 切り替え │ │ を管理 │ │ 与える │ │
│ └─────────┘ └─────────┘ └─────────────────┘ │
└─────────────────────────────────────────────────┘
⚙️ 柱1:ペルソナシステム 〜状況に応じた専門家〜
▸ ペルソナとは?
人間のチームでも、設計は設計者、テストはQA担当、セキュリティはセキュリティ専門家が担当しますよね。AIエージェントにも同じ考え方を適用します。
タスクの種類 起動するペルソナ 得意なこと
─────────────────────────────────────────────────────────
「全体設計を考えて」 → 🏗️ アーキテクト → システム構造、拡張性
「UIを作って」 → 🎨 フロントエンド → ユーザー体験、アクセシビリティ
「バグを調べて」 → 🔍 アナライザー → 根本原因の特定、調査
「セキュリティ確認」 → 🛡️ セキュリティ → 脆弱性発見、対策提案
「ドキュメント書いて」 → 📝 スクライブ → 文書作成、わかりやすい説明
▸ 自動切り替えの仕組み
ペルソナは手動で指定することもできますが、タスクの内容から自動で判定されます。
ユーザーの依頼
│
├─ キーワード分析 (30%) 「設計」「パフォーマンス」等
├─ コンテキスト分析 (40%) 対象ファイル、プロジェクト状態
├─ 過去の傾向 (20%) ユーザーの好みや作業パターン
└─ システム状態 (10%) リソース使用率、エラー有無
│
▼
最適なペルソナを自動選択
▸ ペルソナが変わると何が変わる?
単なる「口調の変化」ではありません。ペルソナによって、以下が動的に変わります:
| 項目 | アーキテクト | セキュリティ | フロントエンド |
|---|---|---|---|
| 優先事項 | 拡張性・保守性 | 安全性・コンプライアンス | ユーザー体験 |
| 分析の深さ | システム全体 | 脅威と脆弱性 | UI/UXの使いやすさ |
| 使うツール | 設計パターンDB | 脆弱性スキャン | UIコンポーネントDB |
| 判断基準 | 長期的な影響 | リスクの大きさ | ユーザーへの影響 |
⚙️ 柱2:タスク管理システム 〜段取りの自動化〜
▸ なぜタスク管理が必要?
複雑な作業を頼むと、AIは途中で何をしていたか忘れたり、順番を間違えたりします。タスク管理システムは、AIに「やることリスト」を持たせる仕組みです。
▸ タスク管理の階層
レイヤー1: セッション内タスク
└─ 今の会話の中でやるべきこと(3〜20個)
└─ 状態: 待機 → 実行中 → 完了 / ブロック中
レイヤー2: プロジェクトタスク
└─ 数日〜数週間にわたる機能開発
└─ 構造: エピック → ストーリー → タスク
レイヤー3: オーケストレーション
└─ 複数ドメインにまたがる複雑な作業
└─ 並列実行・順次実行の制御
▸ タスクの状態管理
📋 待機中 (pending)
│
▼ 開始条件が満たされた
🔄 実行中 (in_progress) ← 同時に1つだけ
│
├─ 依存タスクが未完了 → 🚧 ブロック中 (blocked)
│ │
│ └─ 依存解決 → 🔄 実行中に戻る
│
└─ 完了条件を満たした → ✅ 完了 (completed)
▸ 実際の動き(例)
ユーザーが「認証機能を追加して」と依頼した場合:
自動生成されるタスクリスト:
📋 Task 1: 要件の確認と設計
📋 Task 2: データベーススキーマの設計 ← Task 1に依存
📋 Task 3: API実装 ← Task 2に依存
📋 Task 4: フロントエンド実装 ← Task 3に依存
📋 Task 5: テスト作成 ← Task 3, 4に依存
📋 Task 6: セキュリティレビュー ← Task 5に依存
→ AIは依存関係を理解し、正しい順番で1つずつ実行
→ 各タスク完了時に進捗を報告
→ ブロックされたら原因を特定して対処
⚙️ 柱3:外部ツール連携(MCP)
▸ MCP(Model Context Protocol)とは?
MCPは、AIモデルが外部ツールやデータと安全に通信するための標準規格です。
従来のAI:
ユーザー ←→ AI(頭だけ)
MCP対応AI:
ユーザー ←→ AI ←→ ドキュメント検索
←→ ファイル操作
←→ ブラウザ操作
←→ テスト実行
▸ AIに「手足」を与える
MCPを通じて、AIは以下のような「道具」を使えるようになります:
┌──────────────────────────────────────────────────┐
│ AIエージェント │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ドキュメント│ │ 分析 │ │ UI │ │
│ │検索サーバー│ │ サーバー │ │ サーバー │ │
│ │ │ │ │ │ │ │
│ │・公式文書 │ │・問題分解 │ │・UIパーツ│ │
│ │・パターン │ │・根本原因 │ │・デザイン│ │
│ │・ベスト │ │・仮説検証 │ │・最新の │ │
│ │ プラクティス│ │・推論 │ │ トレンド │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────┐ │
│ │ ブラウザ │ │
│ │ 操作 │ │
│ │サーバー │ │
│ │ │ │
│ │・Web検証 │ │
│ │・E2Eテスト│ │
│ │・画面確認 │ │
│ └──────────┘ │
└──────────────────────────────────────────────────┘
▸ MCPの動作フロー
ユーザー: 「Reactの最新の状態管理パターンを調べて実装して」
[AIエージェント]
│
│ ① ドキュメント検索サーバーに問い合わせ
│ → 公式ドキュメントから最新パターンを取得
│
│ ② 分析サーバーで設計を検討
│ → プロジェクトに最適なパターンを選定
│
│ ③ UIサーバーでコンポーネント参考を取得
│ → モダンなUI実装パターンを参照
│
│ ④ 実装
│ → ファイルを作成・編集
│
│ ⑤ ブラウザ操作サーバーでテスト
│ → 動作確認・スクリーンショット取得
│
▼
結果をユーザーに報告
⚙️ 3つの柱が連携する仕組み
3つの柱は独立ではなく、相互に連携して動作します。
[ユーザーの依頼]
│
▼
[ペルソナシステム] ── 最適な専門家を選択
│
▼
[タスク管理] ── 作業を分解し、順序を決定
│
▼
[MCPツール連携] ── 各タスクに必要な道具を提供
│
▼
[品質チェック] ── 8段階の検証ゲート
│
▼
[完了報告]
▸ 品質を保証する8段階ゲート
すべての作業は、以下の検証を通過します:
ゲート1: 構文チェック → コードが文法的に正しいか?
ゲート2: 型チェック → データ型の整合性はあるか?
ゲート3: コード品質 → 読みやすく保守しやすいか?
ゲート4: セキュリティ → 脆弱性はないか?
ゲート5: テスト → 期待通りに動くか?
ゲート6: パフォーマンス → 十分に速いか?
ゲート7: ドキュメント → 説明は正確で十分か?
ゲート8: 統合テスト → 他の部分と問題なく動くか?
⚙️ 実際の活用事例
▸ wp-story-syncでの活用
本プロジェクト「wp-story-sync」では、このフレームワークの考え方を実際に適用しています。
活用例1: シリーズ別の記事管理
├─ Aquaria(水の惑星) → 深海テーマのスタイル自動適用
├─ Solaris(音楽宇宙) → 音楽テーマのスタイル自動適用
├─ RAGteller(火星) → サイバーパンクテーマのスタイル自動適用
└─ Tech(技術記事) → ターミナルテーマのスタイル自動適用
活用例2: 自動化パイプライン
Markdown執筆 → バリデーション → WordPress投稿 → リッチUI適用
(人間の作業は「書く」だけ、あとは自動)
活用例3: 品質管理
・フロントマターの検証(6層チェック)
・HTMLの自動変換と整形
・エラー時の自動検知と報告
💡 フレームワーク設計のポイント
▸ やるべきこと
✅ 役割を明確に分ける → 1つのペルソナに1つの専門領域
✅ タスクの粒度を適切に → 大きすぎず、小さすぎず
✅ 失敗を前提に設計する → エラー時の復旧パスを用意
✅ 外部ツールは疎結合に → 1つが壊れても全体に影響しない
✅ 検証を自動化する → 人間のチェックに頼らない
▸ やってはいけないこと
❌ 1つのAIに全部やらせる → 専門性が薄まる
❌ タスクの順序を無視する → 依存関係でエラーが起きる
❌ ツール連携を密結合にする → 変更時に全体が壊れる
❌ エラーを握りつぶす → 問題が見えなくなる
❌ セキュリティを後回しにする → 最初から組み込むべき
⚙️ まとめ
AIエージェントフレームワークの設計思想をまとめると:
1. ペルソナシステム → AIに「役割」を与える
2. タスク管理 → AIに「段取り力」を与える
3. MCPツール連携 → AIに「手足」を与える
この3つが揃うことで、AIは「質問に答えるだけの存在」から「自律的に仕事を進めるパートナー」に進化します。
重要なのは、フレームワークは道具であり、最終的な判断と責任は人間にあるということです。AIエージェントの設計は、人間とAIの最適な協働を目指すものです。
⚙️ 参考リンク
この記事はAIエージェントフレームワークの設計思想を解説したものです。
⚙️ Tech Series – T-02 🔧
Engineering the future…