SKILL.md — AgentSpeak(L) & BDI Agent Architecture
自律エンティティが、競合する目標を管理し、イベントに応答しながら、進行中の作業を放棄することなく、知覚、熟考、行動を行う必要がある場合に。
決定ポイント
主要アーキテクチャの選択
IF システムに永続的な目標のないイベント反応のみが必要
→ リアクティブ/ルールシステムを使用（BDIは過剰）
ELIF システムに割り込みのない静的環境での計画が必要
→ 古典的プランナーを使用
ELIF システムに動的環境での反応性と目標永続性の両方が必要
→ BDIアーキテクチャを使用
選択関数呼び出し表
| 状況 | 使用関数 | 判断基準 |
|---|---|---|
| 新しいイベントが到着 | SE (イベント選択) | 優先度、緊急度、リソース制約 |
| イベントに計画が必要 | SO (オプション選択) | コンテキストガード、計画成功履歴、リスク許容度 |
| 複数のアクティブな意図 | SI (意図選択) | 期限、リソース割り当て、公平性ポリシー |
| 計画の失敗が発生 | SO 次に SI | 失敗処理計画を見つけ、その後意図を再スケジュール |
計画失敗回復の決定木
計画PがアクションAの実行中に失敗:
IF この失敗タイプに対する失敗処理計画が存在する
→ 失敗イベントを投稿し、SOに回復計画を選択させる
→ 修正された意図スタックで継続
ELIF 同じトリガーイベントに対する代替計画が存在する
→ イベントにバックトラックし、SOに次の適用可能な計画を試させる
→ 失敗した計画を検討対象から除外
ELIF 代替手段がない
→ 失敗を意図スタックの上位に伝播
→ IF 親計画が存在する → 親レベルで失敗イベントをトリガー
→ ELSE 意図を完全に破棄
信念更新の影響評価
新しい信念Bが到着:
IF Bが既存の信念と矛盾する
→ 信念修正プロトコルを実行
→ すべてのアクティブな意図のコンテキストガード違反をチェック
→ IF コンテキストがもはや成立しない → 意図を中断（破棄はしない）
ELIF Bが新しい適用可能な計画を有効にする
→ イベントキュー内で、今や適用可能な計画を持つ休眠イベントがないかチェック
→ SEを使用して再優先順位付け
ELIF Bが保留中の目標条件を満たす
→ 達成をマークし、関連する意図をクリーンアップ
→ 計画クリーンアップのために達成イベントを投稿
障害モード
1. 計画スラッシング
症状: エージェントが進捗なく計画間を急速に循環する。同じイベントが繰り返し異なる計画をトリガーする。 検出ルール: 同じイベントがN実行サイクル内で3回以上処理され、毎回異なる計画が選択されている場合、計画スラッシングが発生している。 根本原因: SO（オプション選択）関数が非決定的、またはコンテキストガードが弱すぎる/重複している。 修正方法: SOを明示的に優先順位付けする。コンテキストガードを強化して相互排他的にする。選択基準に計画成功/失敗履歴を追加する。
2. 古い信念による麻痺
症状: エージェントが時代遅れの世界モデルに基づいて計画を選択する。環境に関する誤った前提により計画がすぐに失敗する。 検出ルール: 計画失敗率が50%を超え、失敗が実行時（計画時ではない）のコンテキストガード違反による場合、古い信念が原因である。 根本原因: 環境変化率に比べて信念更新頻度が低すぎる。信念修正が意図のコンテキストチェックに伝播していない。 修正方法: 知覚頻度を上げる。信念の古さを示すタイムスタンプを追加する。コンテキストガードが無効になった意図を中断する。
3. 無限意図ループ
症状: エージェントが同じ目標に対してさらに意図を生成するイベントを投稿する意図を作成する。意図スタックが無制限に増大する。 検出ルール: 意図スタックの深さが、対応する目標達成なしに経時的に単調増加する場合、意図ループが発生している。 根本原因: 計画が、終了条件なしに元の目標に最終的に戻るサブゴールを作成する。 修正方法: コンテキストガードに達成検出を追加する。意図の包含関係を実装する（重複意図を統合）。最大再帰深度制限を追加する。
4. 計画内ポリシーアンチパターン
症状: 同じイベントが計画本体内の条件分岐に基づいて異なる動作をトリガーする。エージェントポリシーが分散し、変更が困難になる。
検出ルール: 計画本体に優先度/緊急度の条件分岐（if high_priority then X else Y）が含まれている場合、ポリシーが間違った場所にある。
根本原因: エージェントの合理性が選択関数ではなく計画ロジックにエンコードされている。
修正方法: すべての優先度/ポリシーロジックをSE/SO/SI関数に移動する。計画をポリシーに依存せず、コンテキストにのみ敏感にする。
5. 単一意図ボトルネック
症状: エージェントが割り込みを処理できない。緊急イベントが長時間実行タスクの完了を待つ。並行性がない。 検出ルール: エージェントが常に最大1つのアクティブな意図しか持たない場合、単一意図ボトルネックが発生している。 根本原因: SI（意図スケジューリング）関数が真の並行性を実装していない。意図を並行ではなく排他的として扱っている。 修正方法: 複数のアクティブな意図を許可する。SIでプリエンプティブスケジューリングを実装する。計画を中断可能なシーケンスとして設計する。
実践例
例1: 計画競合を伴うマルチエージェントタスク割り当て
シナリオ: 2つのエージェント（A1、A2）が協調してdeliver(package, destination)を達成する。両方とも計画を持つが、能力が異なる。
初期状態:
- A1の信念:
location(A1, warehouse),can_carry(A1, small_items),location(package, warehouse) - A2の信念:
location(A2, depot),can_carry(A2, any),has_vehicle(A2) - 共有信念:
size(package, large),destination(customer_site)
イベント: +!deliver(package, customer_site) が両エージェントに投稿される
決定プロセス:
-
A1の計画選択（SO）:
- 計画P1:
+!deliver(X,Y) : can_carry(A1,small_items) & size(X,small) <- pickup(X); transport(X,Y) - コンテキストガード失敗:
size(package,large)がsize(X,small)と矛盾 - 該当する計画なし →
plan_failure(deliver, no_capability)を投稿
- 計画P1:
-
A2の計画選択（SO）:
- 計画P2:
+!deliver(X,Y) : can_carry(A2,any) & has_vehicle(A2) <- pickup(X); drive(X,Y); dropoff(X) - コンテキストガード成功 → P2が選択
- 意図I1を作成:
[pickup(package), drive(package,customer_site), dropoff(package)]
- 計画P2:
-
A1の信念更新:
- メッセージを受信:
attempting(A2, deliver, package) - 信念を更新:
+delegated(deliver, package, A2) - 失敗した意図を破棄
- メッセージを受信:
初心者の誤り: 両方のエージェントが配送を試み、リソース競合を引き起こす。 専門家の洞察: 調整は、ハードコードされたエージェント知識ではなく、信念の共有と計画コンテキストガードを通じて行われる。
例2: 意図再考を伴う割り込み処理
シナリオ: 長時間実行されるデータ処理タスクを実行中のエージェントが、緊急のセキュリティアラートを受信する。
初期状態:
- アクティブな意図I1:
[process_batch(data1), process_batch(data2), generate_report()] - 現在の実行:
process_batch(data1)の途中（あと10分かかる）
イベント: +security_alert(intrusion_detected, server_3)
決定プロセス:
-
イベント選択（SE）:
- SEの優先順位: セキュリティイベント > ルーチン処理
security_alertがI1の継続よりも選択される
-
計画選択（SO）:
- 計画P3:
+security_alert(Type,Location) : has_admin_access <- isolate_system(Location); notify_team(Type) - コンテキストガード満たされる → P3が選択
- 意図I2を作成:
[isolate_system(server_3), notify_team(intrusion_detected)]
- 計画P3:
-
意図スケジューリング（SI）:
- 現在の意図: I1（
process_batch(data1)で中断中）、I2（新規、緊急） - SIポリシー: セキュリティ意図が処理意図をプリエンプトする
- 実行のためにI2を選択
- 現在の意図: I1（
-
実行:
isolate_system(server_3)を即座に実行notify_team(intrusion_detected)を実行- I2が完了し、意図セットから削除
-
再開:
- I1のみ残る:
[process_batch(data1), process_batch(data2), generate_report()] process_batch(data1)を中断ポイントから再開
- I1のみ残る:
初心者の誤り: セキュリティアラートを無視するか、または処理タスクを完全に放棄する。 専門家の洞察: 意図の中断は、進捗を維持しながら応答性を可能にする。SIスケジューリングポリシーは明示的で設定可能である。
品質基準
- エージェントアーキテクチャに、文書化されたポリシーを持つ明示的なSE、SO、SI選択関数がある
- 各計画に、現在の信念に対して評価可能な、明確に定義されたトリガーイベントとコンテキストガードがある
- 計画ライブラリに、主要な計画タイプごとに失敗処理計画が含まれている（成功パスのみではない）
- 信念更新メカニズムが、矛盾する情報を処理し、変更をアクティブな意図に伝播できる
- 複数の意図が、明確なスケジューリング/プリエンプションルールの下で同時にアクティブにできる
- イベントキューの処理が（FIFOではなく）明示的な優先順位割り当てで優先順位付けされている
- 計画の失敗が、システムクラッシュやサイレント失敗ではなく、イベントをトリガーする
- コンテキストガードが相互排他的であるか、または非決定性を避けるために計画選択が明示的に順序付けられている
- エージェントが、意図スタックとトリガーイベントを公開することで、自身のアクションを説明できる
- 高イベント負荷下でも、システムのパフォーマンスがグレースフルに劣化する（無限ループやスタックオーバーフローがない）
対象外の境界
対象外: すべての動作がリアクティブである単純なルールベースシステム（永続的な目標がない） → 代わりに使用: 基本的なルールエンジンまたはイベントアクションシステム
対象外: 実行中に環境が変化しない静的な計画問題
→ 代わりに使用: 古典的プランナー（A*、STRIPS、HTN）
対象外: 応答時間やハードデッドラインの保証が必要なリアルタイムシステム → 代わりに使用: タイミング分析を伴うリアルタイムスケジューリングシステム
対象外: すべての調整が中央コントローラーで処理できるシステム → 代わりに使用: ワークフローオーケストレーションまたは集中型タスクキューイング
対象外: 自律的な意思決定を伴わない純粋なデータ変換パイプライン → 代わりに使用: ETLツール、ストリーム処理フレームワーク
対象外: 機械学習や統計的推論を主要機能として必要とするアプリケーション → 代わりに使用: BDIを調整レイヤーとして持つMLフレームワーク（必要な場合）