Shippy が示す、高リスク領域の AI Agent 設計

導入

Ai2 が Hugging Face Blog で公開した Shippy の技術解説は、AI Agent を実運用に持ち込む際の重要な事例だ。Shippy は Skylight の海事状況把握プラットフォーム上で、船舶行動、排他的経済水域、海洋保護区、船舶トラック、地図への深いリンクなどを扱う。

この領域では、誤った回答は単なるチャット体験の失敗ではない。巡視船を誤った場所へ向かわせ、限られた執行リソースを浪費し、場合によっては人員の安全にも関わる。そのため Shippy の本質は、より強いモデルを選ぶことではなく、非決定的な Agent をいかに制御可能にするかにある。

主なポイント

• Agent を soul、skills、config に分解：soul は振る舞いと境界を定めるシステムプロンプト、skills は具体的な依頼への処理手順、config は実行フレームワーク、モデル、ランタイム設定を担う。モデルやハーネスの変更は設定変更で済む。
• スキルは Markdown として管理：Shippy のスキルは構造化 frontmatter を持つ Markdown ファイルで、Skylight API の照会、EEZ や MPA の境界検索、船舶トラックの解釈、Skylight マップへのリンク生成などをカバーする。
• 決定的な CLI で API 呼び出しを安定化：初期試作では Agent が直接 API リクエストを組み立て、ページネーション、ジオメトリ、フィルタ指定で微妙な誤りが発生した。そこで専用の Skylight CLI を用意し、認証、ページ処理、構造化出力を CLI 側に寄せた。
• ユーザーごとの隔離セッション：Mothership は会話ごとに専用の Kubernetes デプロイメントを用意する。ユーザーの Skylight JWT はセッション作成時に注入され、ファイルや履歴はそのセッション内に閉じる。
• 評価対象はモデル単体ではない：静的なベンチマークでは、Agent がどのツールを選び、ライブデータをどう扱い、どこで止まるかは測れない。Shippy はモデル、スキル、サンドボックスを含むシステム全体として評価される。

意義と影響

Shippy の教訓は、企業向け Agent の信頼性がアーキテクチャの問題であることだ。モデル性能だけでなく、型付き API、安定した CLI、明示的な権限制御、セッション分離、業務に即した評価が不可欠になる。

特に重要なのは、Shippy が法的判断を下さず、データが支えない推測もしないよう明示されている点だ。高リスクの現場では、答える能力だけでなく、答えてはいけない範囲を理解することが価値になる。

他分野で Agent を導入する場合も、この設計は参考になる。複雑な API を予測可能なツールに包み、スキルを監査可能にし、ユーザーデータを分離し、実際のワークフローで検証する。そこまで整えて初めて、Agent はデモではなく運用基盤になり得る。

Source: Hugging Face Blog