エージェント構築における Shippy の教訓：モデルより信頼性の高いツールと評価が重要

Shippy は、誤った判断が現実の重大な影響を及ぼすような高リスクな意思決定のために設計された海事用 AI エージェントです。ここではそのアーキテクチャと、Ai2 が他の環境プラットフォームへ引き継いでいる教訓について解説します。

2026 年 7 月 13 日

Ai2

海洋保護のような高リスクな運用領域向けに AI エージェントを構築する際、何よりも重要なのは信頼性です。海事アナリストにとって誤った回答は、パトロール艦艇を数マイルも間違った方向へ進ませることになり、すでに逼迫している貴重なリソースを浪費し、最悪の場合、人員の危険を招く恐れがあります。

そこで Skylight チームがリアルタイムの海事領域認識のための AI である Shippy の構築に着手した際、真の難所はモデルそのものの開発ではありませんでした。重要だったのは、「正しく動作し」「自身の限界を遵守し」「多様なタスクにわたって安定して機能する」信頼できるシステムを構築することです。さらに、新しい衛星や船舶からの信号が常時流入する Skylight の生データに基づいて検証を行う必要がありました。これは一度きりの静的なスナップショットではなく、継続的に更新されるデータに対する検証なのです。

エージェントの解剖：スキル、ソウル、そして設定

Shippy のようなエージェントは、3 つの要素で構成されていると考えられています。ソウル（核となる意志）、スキル（実行能力）、そして設定です。

ソウル（Soul）は、Shipppy の人格を定義し、行動の境界を設定するシステムプロンプトです。スキル（Skills）は、特定の種類のリクエストにどう対応するかを示します。このソウルとスキルは Docker イメージに組み込まれ、バージョン管理されたデプロイ可能なアーティファクトとして、Shippy が「何であるか」を定義しています。

一方、設定（Config）にはそれ以外のすべてが含まれます。どのエージェントハネスを実行するか（Shippy の場合はオープンソースのエージェントフレームワークである OpenClaw）、どの大規模言語モデル（LLM）を使用するか（現在は Claude Opus 4.6 に依存）、そしてランタイムの設定などです。API キーのような機密情報は、実行時に注入されます。モデルやハネスを差し替えるのは再構築ではなく、設定の変更で済みます。

Shippy のスキルは、Claude Code や Codex といったコーディングツールと同じ agent-skills spec に従っています。これは構造化されたフロントマターを持つプレーンな Markdown ファイルです。これにより、各スキルが理解しやすく、バージョン管理され、修正も容易になっています。現在 Shippy が備えているスキルの例は以下の通りです：

Skylight API を活用してイベント（漁業活動や船舶間での荷役など、Skylight が可視化する船舶の振る舞い）や船舶データを照会します。

また、排他的経済水域（EEZ）および海洋保護区（MPA）の境界情報を検索し、Skylight のモデル（Atlantes など）が既に生成している活動分類を基盤に、船舶が放送する位置情報や移動信号からなる航跡データを解釈します。

さらに、Shippy でのチャット回答から Skylight マップ上の正確な場所へジャンプできるインタラクティブなマップリンクも生成します。

例えば、特定の地域に関する質問への回答ワークフロー全体を記述した「Skylight API クエリスキル」があります。分析担当者が「先月のパナマの排他的経済水域における漁業活動を示してほしい」と尋ねると、このスキルの指示に従い Shippy はまず Skylight のリージョン API を通じて「パナマ EEZ」を境界ポリゴンに解決し、適当な推測やハードコードされた座標を使用せずに処理します。その後、その幾何形状内での漁業イベントを検索し、Skylight マップへの深いリンク付きで結果を整形します。また、Global Fishing Watch や TMT といった Skylight のパートナーから取得した船舶メタデータについても明記されます。

Shippy に投げられる単一の質問でも、複数のスキルが同時に連携します。「コイバ山脈海洋保護区（Cordillera de Coiba MPA）付近で操業している船舶はありますか？」という問いには、データ照会用の Skylight スキル、海洋保護区の境界情報を提供するパートナーである ProtectedSeas のデータベース、そして船舶の振る舞いを解釈する航跡スキルがすべて動員されます。これら一連のプロセスは、単一の対話ターンで完結します。

「魂」こそが、Shippy が何を行い、何をしないかを定義します。船舶が法律違反をしているかどうかという法的判断を下すことはなく、それはエージェントではなく人間が行うべき決定です。また、データで裏付けられない推測を行うこともありません。これらの境界線は、ファインチューニングに依存する暗黙的なルールではなく、システムプロンプトに明記されています。これにより、監査が可能となり、修正も容易になります。

非決定的なエージェントのための決定論的ツール

エージェントは本質的に非決定的です。モデルが何を行うかを完全に制御することはできませんが、そのエージェントが利用するツールを予測可能にすることは可能です。そのため、Shippy は生きた API コールを発行するのではなく、専用 CLI を通じて Skylight と「対話」します。

当社の API には数十種類の入力タイプやネストされたフィルタオブジェクト、ページネーションのカーソル、複雑な幾何学入力が用意されています。初期のプロトタイプでは、Shippy に API コールを一から構築させるようにしていました。しかしその結果、微妙ながら深刻なバグが次々と発生しました。ページネーションの不備で結果が静かに欠落したり、幾何学の符号化エラーが発生したり、フィルタタイプの誤解によって正しく見えるクエリが間違ったデータを返すといった問題です。

Skylight CLI は、こうした複雑さを予測可能なインターフェースに集約します。Shippy は単一のコマンド（skylight events search に型付きフィルタフラグを指定）を実行するだけで、CLI が認証処理、ページネーション、構造化された出力の生成を一貫して担当します。

また、この CLI は自己文書化機能も備えています。詳細な --help 説明文とエラーメッセージが充実しており、エージェントや人間開発者が推測に頼らず、ミスを素早く復元できる十分なコンテキストを提供します。出力は常にローカルの JSON ファイルとして保存され、シェル経由でパイプ処理されることはありません。初期段階では、結果セットが大きすぎるとパイプバッファの上限に達したり、jq などの後続ツールが破綻する問題が発生していました。ディスクへの書き出しによりこれらの課題を回避でき、エージェントは後のステップでもクエリ結果をプログラム的にアクセスできるようになります。

CLI の背後には 標準化された API が存在します。Skylight イベント、船舶、地域、衛星画像、船舶の軌跡など、複数のリソースタイプが、共通する「検索」と「集計」の 2 つの操作を通じてアクセス可能です。API の入力と出力は、フィールドごとの説明を付与した型付きスキーマとして定義されています。

このように、型付き API、決定論的な CLI、そして CLI コマンドを参照するエージェントスキルという 3 つの層が組み合わさることで、Shippy の各コンポーネントは独立してテスト可能になります。API には専用のテストスイートが存在し、CLI は人間またはエージェントによって実行可能です。また、エージェントのスキルは基盤となる処理（プラミング）を担う CLI コマンドを参照するため、Skylight API を利用するたびに Shippy がゼロから仕組みを作り直す必要がありません。各層が次の層で起こりうるミスを狭めることで、システム全体の信頼性が担保されます。

隔離されたホスティング環境

Skylight は現在、70 カ国を超える政府機関や NGO にサービスを提供しています。フィリピンの水産担当官であれば、自分の Skylight アカウントに紐づく「関心領域」や船舶監視リスト、アラート設定を持っています。彼が Shippy に質問した際、エージェントからの API 呼び出しは必ずそのユーザーのデータのみを返す必要がありますし、会話履歴が他者に見られることは絶対にあってはいけません。

すべてのユーザーは、それぞれが独立した一時的なセッション内で Shippy と対話します。この仕組みを大規模かつ確実に動作させることが、本プロジェクトにおける最も重要なエンジニアリング課題の一つでした。そこで開発されたのがMothershipというエージェントホスティングプラットフォームです。これは各ユーザーのセッションごとに専用の Kubernetes デプロイメントを割り当てるシステムです。ユーザーが会話を開始すると、システムは即座にエージェントランタイム、スキル、そして Skylight CLI をパッケージ化した一連のポッド（Pod）を起動します。ここでユーザー固有の Skylight JWT がプロビジョニング時に注入されるため、エージェントからの API 呼び出しは自動的にそのユーザーのデータ範囲内に制限されます。

エージェントがマルチステップ分析の間に作成するファイルは、そのセッション内にのみ存在し、ユーザー間で共有されることはありません。サンドボックス内では、コードの記述・実行、依存関係のインストール、データセットの取得、そして複雑な分析の実行が可能です。ネットワークレベルでは、必要なサービス以外へのアクセスは制限されています。

モデルではなくエージェントを評価する

多くのベンチマークは、一般的な AI を静的な質問に対して評価します。しかし、これらはエージェントが実際のワークフローに組み込まれた際の振る舞い——ツールの選択方法、生データの照会、結果に基づく行動、そしてどこで停止すべきかの判断——を捉えることができません。そこで私たちは、Shippy の動作原理に基づいた独自の評価システムを構築しました。これはモデル、スキル、サンドボックス全体を含むエージェント全体を、生データに対してスコアリングするものです。

当社の評価フレームワークでは、専門家がシナリオと評価基準を作成します。各タスクにどの基準が適用されるかを選択し、重み付けを設定することで、各タスクが実際に重要視すべき点に基づいて採点されます。例えば、「釣りイベント」に関する問い合わせでは、データの正確性が最も重視され、次に境界の解決や時間範囲が続き、情報源の明記や応答スタイルは相対的に軽視されます。また、専門家は個々の回答を正解・不正解として注釈付けし、評価者が判断する際の正解基準（グランドトゥルース）を提供します。

パイプラインはシンプルです。自然言語のプロンプトをサンドボックスに投入し、LLM によるジャッジが各項目を 0 から 1 の間で採点します。その際、なぜ回答が基準を満たしたか、あるいは満たさなかったのかについて、文章で理由も併記されます。最後に、これらの重み付き集計値が決済閾値と比較され、判定が行われます（下の図参照）。

タスクの実行には、オープンな評価フレームワークである Harbor を利用しています。私たちは Harbor 用プラグインを開発し、テスト対象の正確なバージョンで実際の Shippy セッションを起動させます。これにより、ユーザーが直面するのと同じ実データに対して評価が行われます。このスイートは特定のバージョン化された Shippy ビルドに対して並列実行され、タイムスタンプ付きの結果ファイルと、前回の実行とのスコア変化を示すレポートが生成されます。スキルやモデル、基盤となるデータに変更があった際は必ず再実行を行い、評価基準で後退したバージョンの Shippy がエンドユーザーに到達しないよう制御しています。

Shippy は、データ検索およびガードレール関連のタスクで一貫して高いスコアを記録しています。具体的には、軍事情報に関するリクエストを正しく拒否し、ユーザーデータの分離を維持し、出典を正確に明記できています。最新のテストでは、主に 3 つのパターンが浮き彫りになりました。1 つ目はパトロール計画タスクで、Shippy が意思決定支援ではなく戦術的な推奨へと踏み越えてしまったケースです。2 つ目は幾何学的な制約を持つクエリで、境界の簡略化処理によってイベントを見逃してしまった事例です。3 つ目は、存在しない CLI コマンドをエージェントが創作してしまっていたケースです。これら 3 つの問題は、次のスキル改善ラウンドに向けた重要な示唆となっています。

私たちの目指す方向

Shippy は現在、早期採用者向けに順次公開を開始しており、ストレステストを通じて「エージェントが答えにくい質問」や「強化が必要なガードレール」を特定してもらうことを求めています。今後取り組む主な機能は以下の通りです。

• エージェントによる UI 操作：現在はマップへのリンクを返すだけですが、今後は Skylight マップそのものを直接操作できるようになります。地域移動やフィルタ適用、時間範囲の調整などをエージェントが行います。
• モデルのルーティング：すべての質問に最先端モデルを使う必要はありません。簡単な照会には軽量で高速なモデルを割り当て、複雑な調査には重厚なフルモデルを使用する仕組みを整えています。
• スレッド間での記憶機能：現在の Shippy はスレッド内では会話履歴が保持されますが、スレッドを超えて文脈を引き継ぐことはできません。今後は、分析官の管轄区域や好む情報源といった「永続的な事実」を記憶し、自動的に適用する機能を構築中です。これにより、「今週の漁業活動を表示」といった指示に対し、毎回分析官の排他的経済水域（EEZ）を再指定する必要がなくなります。

Shippy での取り組みは、すでに Ai2 内における他のエージェントへの考え方を形作り始めています。特に Wildlife-conservation platform の「EarthRanger」や、地球観測ツール群のオープンスイートである「OlmoEarth」においてその影響が見られます。Mothership は汎用性を備え、他のエージェントをホストできることを前提に設計されているため、現在は海運分野への適用が最優先ですが、これが唯一の領域になるとは考えていません。

*Shippy は Ai2 の Skylight チームによって開発されました。Skylight は、70 カ国以上の 300 以上のパートナー機関で利用されている無料の海洋ドメイン認識プラットフォームです。*

私たちと一緒に

Ai2 では、透明性が高くオープンソースの AI の未来を構築しています。私たちは「オープンな環境」で開発を進め、科学の進展と、この世界を変える技術への根本的な理解を深めることを目指しています。

利益追求が目的ではありません。AI がもたらす恩恵を広く社会に共有し、人類全体の福祉に貢献することこそが私たちの使命です。もしその理念に共感していただけるなら、ぜひ当社の募集要項をご覧ください。

求人ページ

最新ニュースの定期配信

Ai2 の最新のニュースを毎月お届けするニュースレターへの登録も受付中です。