Ai2がHugging FaceでShippy設計を公開。仕事で使えるAIの条件が見える

チャット欄の向こうに業務がつながる

Ai2がHugging Faceで公開したShippyは、AIチャットの次の形をよく示しています。ShippyはSkylightチームによるmaritime domain awareness（海上状況把握）向けのAIエージェント（道具を使って作業を進めるAI）です。

ポイントは一言で言えます。仕事で使えるAIは、賢さよりも任せ方で決まります。Shippyは、会話だけでなく、地図、データ、利用者権限、評価までつながっています。

紹介例では、GhanaのEEZ（排他的経済水域）について答える時に、境界データの出典を示します。データの締め時点も出します。質問時刻とSkylight地図への深いリンクも添えます。

海上監視は特殊な仕事です。それでも、ここでの設計は多くの職場に重なります。AIに頼みたいのは、きれいな文章だけではないからです。

営業なら顧客情報に触れます。経理なら社内データに触れます。問い合わせ対応なら履歴と規約に触れます。AIがどこまで見て、どの道具を使い、どこで止まるかが重要になります。

Shippyは、違法かどうかの法的判断をしません。データが支えない推測もしません。これは、AIに役割を与えるだけでなく、やらせないことを明確にする設計です。

読者にとって気になるのは、いつから使えるのかです。発表では、Shippyをearly adoptersへ段階的に開放すると書かれています。一般提供日とShippy単体の料金は、発表に書かれていません。

Skylightは無料の海上状況把握プラットフォームです。ただし、Shippyの料金体系が同じだとは発表されていません。ここを分けると、期待と事実が混ざりません。

Shippyは、API（システム同士の接続口）をAIに直接自由に作らせません。代わりにSkylight CLI（コマンド操作の窓口）を使います。AIの作業範囲を細くするほど、仕事の結果は追いやすくなります。

初期試作では、API呼び出しをAIに作らせていました。そこでページ送りの誤りが出ました。地理データの符号化ミスも出ました。正しそうに見えるのに、違うデータを返す危険もありました。

CLIは、その複雑さを一定の操作へ閉じ込めます。認証、ページ送り、構造化出力はCLIが扱います。大きな結果はローカルJSONファイルへ書きます。

実務のAIで怖いのは、別の人の情報が混ざることです。Shippyは利用者ごとに一時的な隔離セッションで動きます。Mothershipが専用のKubernetes（実行環境を動かす仕組み）deploymentを用意します。

起動時には、利用者のJWT（ログイン権限を表す情報）が入ります。API呼び出しは、その人のデータに閉じます。作業中にできたファイルも、セッションの外へ共有されません。

これは、社内AIにも通じる発想です。便利なAIほど、多くの情報へ触れます。だからこそ、誰の権限で動くかが設計の中心になります。

Shippyの評価は、単純なモデル比較ではありません。自然文の依頼を実際のShippy sessionに流します。Harbor（評価用のオープンな枠組み）を使い、実データに対して走らせます。

専門家がシナリオとrubric（採点基準）を作ります。LLM judge（AIによる採点役）が、各基準を0から1で採点します。理由も残します。

skills、モデル、基礎データが変わるたびに評価は走ります。合格ラインを下回る版は利用者へ出ません。今後は、地図UI操作、モデルルーティング、cross-thread memory（会話スレッドをまたぐ記憶）も作るとされています。

Shippyの話は、AIを仕事に入れる時の合言葉になります。まずモデル名を聞くのではありません。どの道具を渡し、どの権限で動かし、失敗した時にどう止めるか。そこに、現場で使えるAIの差が出ます。

出典