問題提起：エージェントはブラックボックスのまま動く

現在のAIエージェントシステムは、人間がインテントを与えた後の「実行」精度を急速に高めている。Claude Code、Codex、Hermesといったツールはその典型だ。しかし上位レイヤーの問いは手つかずのまま残っている。「次に何が起きるべきか」「なぜその選択なのか」——この問いへの答えは、依然として人間が担うか、エージェントの内部に埋もれたまま外部から見えない状態にある。

結果として何が起きるか。エージェントが最終的な出力だけを返し、その判断過程が記録されない。なぜその行動を選んだのか、どんな選択肢を棄却したのか、その後の結果が次の判断にどう影響したのか——これらが全て不透明なまま、次のタスクが始まる。これが「エージェントのブラックボックス問題」だ。

Source によれば、この問題意識から生まれたのがオープンソースプロジェクト「Spice」である。作者のJia氏はこう定義する。「SpiceはエージェントのUpper、決定層だ」と。

Spiceの設計思想：実行の前に推論境界を置く

Spiceはエージェントの実行を置き換えない。これが重要な設計原則だ。Claude CodeやCodexといった既存の実行エージェントはそのまま使う。Spiceはそれらの「手前」に位置し、意思決定プロセスを明示的な構造として記録する役割を担う。

具体的にSpiceが記録・可視化しようとする情報は以下の6項目だ。

• 何が観測されたか（what was observed）
• どんな選択肢が検討されたか（what options were considered）
• なぜその選択肢が選ばれたか（why one option was selected）
• どんなトレードオフが棄却されたか（what trade-offs were rejected）
• その後何が起きたか（what happened afterward）
• その結果が次の決定にどう影響すべきか（how that outcome should affect the next decision）

この構造を「Decision Card」と呼ぶ。現在のランタイムはまだ初期段階だが、すでにインストール・LLMプロバイダーの設定・ターミナルでの実行・Decision Cardの検査・外部エージェントへの承認済み実行ハンドオフが可能な状態にある。GitHubリポジトリは `https://github.com/Dyalwayshappy/Spice` で公開されている。

プロンプトエンジニアリングの視点から読む

ここで筆者の専門領域から一点補足する。Spiceが解こうとしている問題は、プロンプト設計の文脈でも長年議論されてきた課題と重なる。

Chain-of-Thought（CoT）プロンプティングは、LLMに「考える過程」を出力させることで精度を上げる手法だ。しかしCoTはあくまで単一の推論ステップを可視化するものであり、「複数の選択肢を比較した上でなぜこれを選んだか」「棄却された選択肢は何か」という構造的な意思決定ログを永続的に保存する仕組みではない。

Spiceが目指すのはその先だ。エージェントが行動を起こす前の「推論境界（reasoning boundary）」を外部から検査可能な形で保存し、次の判断サイクルにフィードバックする。これは単なるログ記録ではなく、エージェントの意思決定を監査可能にするアーキテクチャの提案と言える。

プロンプト設計の観点では、この「Decision Card」の構造自体が一種の出力フォーマット指定として機能する可能性がある。LLMに対して「観測・選択肢・選択理由・棄却理由・結果・次への影響」という6項目を必ず出力させる構造化プロンプトを組み合わせることで、Spiceのランタイムは意味のある決定ログを生成できると考えられる。

結論：「実行の透明性」から「決定の透明性」へ

AIエージェントの信頼性議論はこれまで「何をしたか」の説明責任に集中してきた。Spiceが提起するのは一段上の問いだ——「なぜそれをしたか」を、実行前の段階で構造化して残せるか。

プロジェクトはまだ初期段階であり、実運用での有効性は今後の検証に委ねられる。しかし「決定層」という概念の分離は、エージェントアーキテクチャの設計思想として注目に値する。エージェントを使って何かを作っている読者は、GitHubリポジトリを確認し、Decision Cardの構造設計にフィードバックを送ることが最も具体的なアクションになるだろう。