Shippy の教訓から学ぶエージェント構築

記事一覧に戻る

• エージェントの解剖：スキル、魂、設定
• 非決定的なエージェントのための決定論的なツール
• サンドボックス化されたホスティングと分離
• モデルではなくエージェントを検証する
• 私たちの進むべき道

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

ガーナの排他的経済水域（EEZ）に関するライブクエリに答える Shippy。回答には作業の過程が示されており、境界線の出典、データの更新日、クエリのタイムスタンプ、そして分析官が数値を一つひとつ検証できるよう Skylight マップへの深いリンクが含まれています。

海洋保護のような高リスクな運用ドメインで AI エージェントを構築する際、何よりも重要なのは信頼性です。海洋分析官にとって間違った答えは、巡視船を数マイルも誤った方向へ進ませることになり、すでに逼迫している貴重なリソースを浪費し、最悪の場合、人員の危険にさらす結果につながります。

そこで Skylight チームがリアルタイムの海洋ドメイン認識のための AI である Shippy を構築しようとした際、真の難所はモデルそのものではありませんでした。重要だったのは、正しく動作し、自身の限界を遵守し、多様なタスクにわたって耐えうるシステムを構築することです。そして、新しい衛星や船舶の信号が到着するたびに継続的に更新される Skylight のライブデータに対して、すべてを検証する必要がありました。これは単なる静止したスナップショットではなく、常に動き続ける生きたデータなのです。

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

Shippy のようなエージェントを構成する要素は、大きく分けて三つです。ソウル（Soul）、スキル（Skills）、そして設定（Config）です。

ソウルとは、Shippy の人格を定義し、行動の境界線を引くシステムプロンプトのことです。一方、スキルは、特定の種類のリクエストに対して Shippy がどのように対応すべきかを指示するものです。このソウルとスキルは、Docker イメージとして一体化されます。これはバージョン管理されたデプロイ可能なアーティファクトであり、Shippy が「何者であるか」を定義するものです。

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

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

現在 Shippy が備えているスキルは以下の通りです：

• Skylight API をクエリしてイベント（Skylight が検出する漁業や船舶間のトランスシップメントなどの船の行動）および船舶データを取得する
• 排他的経済水域（EEZ）と海洋保護区（MPA）の境界情報を検索する
• 船舶がブロードキャストする位置情報や移動信号である vessel track データを解釈する。これは、Atlantes などの Skylight のモデルが既に生成している活動分類に基づいています

• シッピーのチャット回答から、スカイライトマップ上の正確な場所へジャンプできるインタラクティブな地図リンクを生成する

例えば、「スカイライト API 照会スキル」は、特定エリアに関する質問に答えるための一連の流れをコード化しています。アナリストやユーザーが「先月のパナマ排他的経済水域（EEZ）での漁業活動を示してほしい」と尋ねると、このスキルの指示に従ってシッピーはまず、スカイライトの地域 API を通じて「パナマ EEZ」を境界ポリゴンとして特定します。座標を推測したりハードコードしたりするのではなくです。その後、その領域内で漁事象（Fishing Events）を検索し、結果をスカイライトマップへの深いリンク付きで整形して表示します。また、Global Fishing Watch や TMT などのパートナー企業から取得した船舶メタデータも併せて付与されます。

シッピーに投げかけられた一つの質問が、複数のスキルに同時に接続されることもあります。「コイバ山脈海洋保護区（MPA）付近で操業している船舶はありますか？」という問いには、データの照会にはスカイライトのスキルを、海洋保護区の境界情報にはパートナーである ProtectedSeas のデータベースを、そして船舶の行動解析には船舶軌跡スキルを活用します。これらすべてが、単一の対話ターン内で完結します。

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

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

エージェントは非決定論的です。モデルが何を判断するかを完全に制御することはできませんが、モデルが頼るツール自体の挙動を予測可能にすることは可能です。

そのために Shippy は、API を直接呼び出すのではなく、専用 CLI を通じて Skylight と「対話」します。

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

Skylight CLI はこうした複雑さを予測可能なインターフェースに集約します。Shippy は単一のコマンド（skylight events search with typed filter flags）を発行するだけで、認証処理、ページネーション管理、構造化された出力はすべて CLI が担当します。また、この CLI は自己文書化機能も備えています。詳細な --help 説明やエラーメッセージが充実しているため、エージェントも人間開発者も推測に頼らず、ミスを即座に修正して回復できます。

出力結果は常にローカルの JSON ファイルとして保存されます。シェルを介してパイプラインで流す方式では、初期段階において大量の結果セットがパイプバッファの制限に達したり、jq などの後続ツールを破損させたりする問題が発生しました。ディスクへの書き込みによりこれらの問題は回避でき、エージェントは後のステップでもプログラムを通じてクエリ結果にアクセスできるようになります。

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

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

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

Skylight は、70 カ国以上にある数百の政府機関や NGO にサービスを提供しています。フィリピンの水産監視官には、その Skylight アカウントに限定された「関心領域（Areas of Interest）」、「船舶監視リスト」、「アラート設定」が用意されています。彼らが Shippy に質問した際、エージェントからの API 呼び出しは必ず該当者のデータのみを返す必要がありますし、会話履歴が他者に閲覧されることは絶対にあってはいけません。

Shippy の利用者は、それぞれ個別の一時セッション内でシステムと対話します。この仕組みを大規模かつ確実に運用することは、本プロジェクトにおける最も重要なエンジニアリング課題の一つでした。

そこで開発したのが「Mothership」と呼ぶエージェントホスティングプラットフォームです。これは、各ユーザーセッションごとに専用の Kubernetes デプロイメントを即時割り当てる仕組みです。ユーザーが会話を開始すると、システムはエージェントのランタイム、スキルセット、そして Skylight CLI をパッケージ化した一連のポッド（Pod）を起動します。この時点で、ユーザー固有の Skylight JWT が注入され、エージェントからの API 呼び出しは、そのユーザーのデータ範囲に限定されます。

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

エージェントの評価：モデル単体ではない

既存のベンチマークは、一般向けの AI を静的な質問に対して評価する傾向があります。しかし、それでは実務ワークフローに組み込まれたエージェントの振る舞い——ツール選択、生データへの照会、結果に基づくアクション、そしていつ停止すべきかの判断——を捉えることはできません。

そこで私たちは、Shippy の実際の動作原理に基づいた独自の評価システムを構築しました。これはモデルだけでなく、スキルやサンドボックス環境を含めた「エージェント全体」を対象に、生データを用いて総合的にスコアリングする仕組みです。

評価フレームワークでは、専門家がシナリオと評価基準を作成し、各タスクに適用する指標を選択して重み付けを行います。これにより、各タスクは本当に重要な要素に基づいて採点されます。例えば、「釣りイベントに関する問い合わせ」の場合、データの正確性が最も重視され、次に境界の解決や時間範囲が重要視され、情報源の明記や回答スタイルは相対的に軽視されます。

また、専門家は個々の回答を「正解」「不正解」として注釈付けし、評価者（ジャッジ）が採点するための正解基準を提供します。これにより、評価プロセスに客観的な根拠が与えられます。

パイプラインの仕組みはシンプルです。自然言語のプロンプトがサンドボックス内を処理され、LLM による評価者が各基準に対して 0 から 1 のスコアを付け、その回答が基準を満たしたか否かの理由を文章で説明します。最終的に、重み付けされた集計値が固定の合格ラインと比較され、合格・不合格が判定されます。以下の図はその様子を示しています。

*当社のパイプラインにおける単一タスクの評価方法。自然言語のプロンプトがサンドボックスを通過し、LLM 評価者が各基準にスコアと根拠となる文章を付与します。重み付けされた集計値は固定の閾値と比較され、合格か不合格かが決定されます。*

タスクの実行は、オープンソースの評価フレームワークである Harbor を通じて行われます。私たちは、テスト対象の正確なバージョンで実際の Shippy セッションを起動し、ユーザーが直面するのと同じ実データに対して評価を行う Harbor プラグインを開発しました。

このスイートは特定のバージョン化された Shippy ビルドに対して並列実行され、タイムスタンプ付きの結果ファイルと、前回の実行に対するスコア変動を示すレポートを生成します。スキル、モデル、あるいは基盤となるデータに変更が生じた際は常に再実行を行い、評価基準で後退したバージョンの Shippy がエンドユーザーに届くことを防いでいます。

Shippy は、データ検索やガードレール（安全装置）タスクにおいて一貫して高いスコアを記録しています。具体的には、軍事情報に関するリクエストを適切に拒否し、ユーザーデータの分離を維持し、出典の明記も正確に行っています。

最新のテスト結果で最も明確に見られたのは、以下の 3 つのパターンです。まず、パトロール計画タスクにおいて、Shippy が意思決定支援ではなく戦術的な推奨へと踏み越えてしまったケース。次に、境界線の簡略化が原因でイベントを見逃してしまった幾何学的に敏感なクエリ。そして最後に、存在しない CLI コマンドをエージェントがでっち上げてしまった事例です。

これらすべての課題は、次のスキル改善ラウンドに向けた具体的な指針となっています。

*Skylight 内で実行される Shippy の評価スイート：各シナリオは加重された基準で採点され、判定の根拠も表示されるため、失敗した際に修正すべき特定の行動を特定できます。*

今後の展望

Shippy は現在、ロールイングベース（順次）で初期採用者に公開されており、ストレステストを通じて、エージェントが回答に苦戦する質問や、強化が必要なガードレールを見つけることを求めています。今後取り組む主な機能は以下の通りです。

• エージェントによる UI 制御。現在の Shippy は地図へのリンクを返すだけですが、今後は Skylight の地図そのものを操作できるようになります。地域への移動、フィルターの適用、時間範囲の調整などが可能です。

• モデルルーティング。すべての質問に最先端モデルが必要とは限りません。単純な照会には軽量で高速なモデルを割り当て、複雑な調査にはフルスペックのモデルを使用する仕組みを導入しています。

• スレッド間メモリ。現在の Shippy はスレッド内での会話履歴は保持しますが、スレッドを超えた文脈の共有はできません。今後は、分析官の管轄区域や好む情報源といった永続的な事実を記憶し、自動的に適用する機能を構築中です。これにより、「今週の漁業活動を表示」といった指示に対し、毎回分析官の排他的経済水域（EEZ）を再指定する必要がなくなります。

Shippy への取り組みは、Ai2 内における他のエージェント開発にもすでに影響を与えています。特に野生生物保護プラットフォーム「EarthRanger」や、地球観測ツール群のオープンスイート「OlmoEarth」においてその考え方が即座に反映されています。Mothership は汎用性を備え、他エージェントをホストすることを前提に設計されているため、現在は海運分野への適用が最優先ですが、これが唯一の領域になるとは考えていません。

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