エージェント構築における Shippy の教訓：モデルより信頼性の高いツールと評価が重要
Allen AI は、高リスクな海洋監視領域向けエージェント「Shippy」の構築プロセスを通じて、信頼性を担保するための「ソウル・スキル・設定」を分離したアーキテクチャと、動的データ検証の重要性を明らかにしました。
キーポイント
エージェントの三要素アーキテクチャ
Shippy は「ソウル（システムプロンプトと行動境界）」「スキル（Markdown 形式の実行機能）」「設定（ランタイム構成）」という 3 つの要素に分解され、Docker イメージとしてバージョン管理される設計を採用しています。
信頼性と動的検証の重視
海洋監視のような高リスク領域ではモデル性能以上にシステムの信頼性が重要であり、衛星や船舶信号などの生データを継続的に取り込みながらリアルタイムで検証する仕組みが不可欠であると強調しています。
構成管理とモデルの分離
API キーや使用する LLM（Claude Opus 4.6）、エージェントハッチス（OpenClaw）などの設定は「設定」層に属し、モデルやフレームワークの変更をビルドなしで実行可能にする柔軟な設計が採用されています。
標準化されたスキル定義
スキルの記述には Claude Code や Codex で使用される「agent-skills spec」を採用し、構造化された Markdown ファイルとして可読性、バージョン管理、修正の容易さを確保しています。
重要な引用
Building an AI agent for a high-stakes operational domain like protecting the ocean is, above all, a problem of reliability.
We think of an agent like Shippy as three things: a soul, skills, and config.
Secrets like API keys are injected at runtime; swapping the model or the harness is a config change, not a rebuild.
影響分析・編集コメントを表示
影響分析
この記事は、単なる技術的な機能紹介にとどまらず、実社会に直結する高リスク領域で AI エージェントを運用するための「設計思想」と「ベストプラクティス」を示した点で重要です。特に、モデルの能力だけでなく、システム全体の信頼性をどう担保するかという課題解決アプローチは、他の産業分野におけるエージェント開発にも大きな示唆を与えるものです。
編集コメント
AI エージェントの実用化において、モデルの性能だけでなく、信頼性や運用プロセスをどう設計するかが成否を分けるという本質的な洞察が得られる記事です。特に「設定」層による柔軟な変更と、生データに基づく継続検証の考え方は、実システム構築における重要な指針となります。
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 の最新のニュースを毎月お届けするニュースレターへの登録も受付中です。
原文を表示
Shippy is a maritime AI agent built for high-stakes decisions, where the wrong answer has real impacts. Here's the architecture behind it—and the lessons we're carrying into Ai2's other environmental platforms.
July 13, 2026
Ai2
Building an AI agent for a high-stakes operational domain like protecting the ocean is, above all, a problem of reliability. For a maritime analyst, a wrong answer could send a patrol vessel miles in the wrong direction, costing significant resources that are already stretched thin and potentially putting personnel in harm's way.
So when the Skylight team set out to build Shippy, our AI for real-time maritime domain awareness, the real work wasn't the model. It was building a system we could trust to be correct, to stay within its limits, and to hold up across a wide range of tasks. And we had to verify all of it against Skylight's live data, updated continuously as new satellite and vessel signals arrive—not a static snapshot.
Agent anatomy: skills, soul, and config
We think of an agent like Shippy as three things: a soul, skills, and config.
The soul is the system prompt that frames Shippy's persona and sets behavioral boundaries. Skills tell Shippy how to handle specific kinds of requests. Together, the soul and skills are baked into a Docker image—a versioned, deployable artifact that defines what Shippy *is*. Config covers everything else: which agent harness to run (in Shippy’s case, OpenClaw, an open-source agent framework), which LLM to use (currently, Shippy relies on Claude Opus 4.6), and runtime settings. Secrets like API keys are injected at runtime; swapping the model or the harness is a config change, not a rebuild.
Shippy’s skills follow the same agent-skills spec used by coding tools like Claude Code and Codex—plain markdown files with structured frontmatter. This keeps each skill comprehensible, versioned, and easy to revise. Shippy currently includes skills for:
- Querying the Skylight API for Events (the vessel behaviors Skylight surfaces, like fishing or transshipment between two vessels) and vessel data
- Looking up Exclusive Economic Zones (EEZ) and Marine Protected Area (MPA) boundaries
- Interpreting vessel track data, the position and movement signals ships broadcast, building on the activity classifications Skylight's models, including Atlantes, already produce
- Generating interactive map links that let an analyst jump from a Shippy in-chat answer to an exact location on the Skylight map
For example, the Skylight API query skill encodes the full workflow for answering a question about a specific area. When an analyst or user asks, "show me fishing activity in Panama's EEZ last month," the skill's instructions direct Shippy to first resolve "Panama EEZ" to a boundary polygon through Skylight's regions API instead of guessing or hard-coding coordinates, then query Fishing Events within that geometry, format the results with deep links back to the Skylight map, and attribute any vessel metadata drawn from Skylight partners like Global Fishing Watch or TMT.
A single question posed to Shippy can hook into several skills at once. "Are there vessels operating near the Cordillera de Coiba MPA?" draws on the Skylight skill for data query, our partner ProtectedSeas’ database for MPA boundary context, and the vessel track skill for interpreting vessel behavior. All of this happens in a single dialogue turn.
The soul defines what Shippy will and won't do. It won't make legal determinations about whether a vessel is breaking the law—that is a determination for people, not an agent. It also won't speculate beyond what the data supports. These boundaries are explicit in the system prompt, not implicit in fine-tuning, which makes them auditable and easy to revise.
Deterministic tools for a nondeterministic agent
Agents are nondeterministic. You can't control what the model decides to do, but you can make the tools it reaches for predictable. To that end, Shippy 'talks' to Skylight through a purpose-built CLI that calls the API, rather than issuing raw calls itself.
Our API has dozens of input types, nested filter objects, pagination cursors, and complex geometry inputs. In early prototypes, we let Shippy construct API calls from scratch. It produced a steady stream of subtle bugs: malformed pagination that silently dropped results, geometry encoding errors, and correct-looking queries that returned wrong data because of a misunderstood filter type.
The Skylight CLI collapses that complexity into a predictable interface. Shippy issues a single command – skylight events search with typed filter flags – and the CLI handles authentication, pagination, and structured output. The CLI is also self-documenting: extensive --help text and detailed error messages give the agent (and human developers) enough context to recover from mistakes without guessing. Its output is always written to a local JSON file rather than piped through the shell. Early on, large result sets would hit pipe buffer limits or break downstream tools like jq. Writing to disk sidesteps both problems and lets the agent programmatically access query results across subsequent steps.
Underneath the CLI is a standardized API: multiple resource types – Skylight Events, vessels, regions, satellite imagery, vessel tracks, and more – accessible through a common pair of operations, search and aggregate. The APIs' inputs and outputs are defined as typed schemas with field-level descriptions.
This layering – typed API, deterministic CLI, and agent skills that reference the CLI's commands – means that each of Shippy's components can be tested independently. The API has its own test suite. The CLI can be exercised by a human or an agent. And the agent skills reference CLI commands that handle the plumbing so that Shippy doesn't have to reinvent the wheel every time it hits the Skylight API. Each layer narrows what the next layer can get wrong.
Sandboxed hosting and isolation
Skylight serves hundreds of government agencies and NGOs across over 70 countries. A fisheries officer in the Philippines has Areas of Interest, vessel watchlists, and alert configurations that are scoped to their Skylight account. When they ask Shippy a question, the agent's API calls need to return their data, and their conversation history must never be visible to anyone else.
Every user talks to Shippy inside their own ephemeral, isolated session, and making that work reliably at scale was one of the most significant engineering efforts behind the project. We built Mothership, an agent hosting platform that provisions a dedicated Kubernetes deployment for each user session. When a user opens a conversation, the system spins up a set of pods packaging the agent runtime, its skills, and the Skylight CLI. The user's Skylight JWT is injected at provision time so the agent's API calls are scoped to that user's data.
Files the agent writes during a multi-step analysis exist only within that session and are never shared across users. Inside the sandbox, the agent can write and run code, install dependencies, pull in datasets, and work through multi-step analyses. At the network level, the sandbox is restricted to only the services it needs.
Evaluating an agent, not a model
Most benchmarks rank general-purpose AI on static questions. They don't capture how an agent behaves once it's wired into a real workflow: how it selects tools, queries live data, acts on results, and knows where to stop. So we built our own eval system around how Shippy works, scoring the whole agent – model, skills, and sandbox together – against live data.
In our eval framework, subject-matter experts write scenarios and rubrics, choosing which criteria apply to each task and setting the weights, so every task is graded on what actually matters for it. A fishing-events query, for instance, weights data accuracy most heavily, with boundary resolution and timeframe next, and source attribution and response style carrying less. They also annotate individual responses as correct or incorrect, giving the judge ground truth to score against. Subject-matter experts additionally annotate individual responses as correct or incorrect, giving the judge ground truth to score against.
The pipeline is straightforward: a natural-language prompt runs through the sandbox, an LLM judge grades each criterion from 0 to 1 and explains in writing why the response did or didn't meet it, and the weighted aggregate is checked against a fixed pass threshold, as the diagram below shows.
Tasks are executed through Harbor, an open evaluation framework. We wrote a Harbor plugin that spins up a real Shippy session on the exact version being tested, against the same real data a user would encounter. The suite runs in parallel against a specific versioned Shippy build, producing a timestamped results file and a report of score changes against the previous run. We rerun the suite whenever the skills, model, or underlying data change, and a version of Shippy that regresses on our eval criteria doesn't reach end users.
Shippy scores consistently across data retrieval and guardrail tasks, correctly refusing military intelligence requests, maintaining user data isolation, and attributing sources accurately. In our latest run, the clearest patterns were patrol-planning tasks where Shippy overstepped into tactical recommendations rather than decision support, geometry-sensitive queries where boundary simplification caused missed Events, and one case where the agent invented a CLI command that didn't exist. Each of these directly informs our next round of skill improvements.
Where we're headed
We're opening Shippy to early adopters on a rolling basis and inviting them to stress-test it—to find the questions the agent answers poorly and guardrails that may need tightening. Here’s what we're building next:
- Agent-driven UI control. Shippy returns map links today; next it will drive the Skylight map itself, moving to a region, applying filters, and adjusting time ranges.
- Model routing. Not every question needs a frontier model, so we're routing simple lookups to smaller, faster ones and saving the full-weight model for complex investigations.
- Cross-thread memory. Conversation history persists within a thread, but context doesn't carry across threads. We're building memory so Shippy carries persistent facts (e.g., an analyst's jurisdiction, preferred sources) and applies them automatically. So, "Show me fishing activity this week" won't mean re-specifying an analyst's EEZ each time.
Our work on Shippy is already shaping how we think about agents elsewhere at Ai2—most immediately EarthRanger, our wildlife-conservation platform, and OlmoEarth, our open suite of Earth observation tools. Mothership was built to be general and to host other agents, so while maritime is the first domain we're applying it to, we don't expect it to be the last.
*Shippy is built by the Skylight team at Ai2. Skylight is a free maritime domain awareness platform used by 300+ partners across 70 countries.*
Join us
At Ai2 we’re building the future of transparent, open-source AI — built in the open to empower scientific progress and fundamental understanding of this world changing technology. We’re not here to make profits, we’re here to make sure benefits of AI are shared widely and for the benefit of humanity. If this appeals to you, please take a look at our open roles.
Subscribe to receive monthly updates about the latest Ai2 news.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み