信頼できるAI海事エージェントを構築することは、モデル選択というよりも、はるかにシステム設計の問題であることがわかった。これは、リアルタイムの海洋状況把握（maritime domain awareness）のために特化して構築されたAIエージェント「Shippy」を開発する中で、Skylightが得た中心的な教訓である。この領域では、誤った回答はユーザーを苛立たせるだけでなく、哨戒船を何マイルも進路から外し、限られたリソースを浪費し、場合によっては要員を危険にさらす可能性がある。
Summary
主なポイント
- ShippyはSkylightが構築したリアルタイム海洋状況把握向けAIエージェントであり、船舶行動、EEZおよびMPA境界、船舶航跡に関するクエリを処理する。
- そのアーキテクチャは3つのコンポーネントで構成されている：ソウル（システムプロンプト）、スキル（タスク処理）、コンフィグ（Claude Opus 4.6の利用を含むランタイム設定）。
- Shippyは、モデルが生のAPIコールを直接構築した際に発生したエラーパターンを排除するために、目的別に設計された決定論的CLIを通じてSkylightのAPIと通信する。
- 各ユーザーセッションはMothershipによってプロビジョニングされる専用のKubernetesサンドボックス内で実行され、Skylightの数百に及ぶ政府およびNGOクライアント間で完全なデータ分離を保証する。
- 評価は、タスクおよびルーブリックに基づくフレームワークに依拠しており、LLMジャッジがライブデータに対する応答をスコアリングする — 静的ベンチマークから意図的に離れたアプローチである。
なぜ海洋状況把握は信頼性のハードルを引き上げるのか
多くのAIツールは、平凡な回答が単に役に立たないだけの環境で動作している。海事オペレーションは異なる。Skylightは、漁業取締りから保全モニタリングまで、70カ国以上にわたる数百の政府機関およびNGOにサービスを提供している。そのような文脈でアナリストが、船舶が海洋保護区内で違法に操業しているかどうかを尋ねた場合、幻覚や不正確な応答の代償は即時かつオペレーション上のものとなる。
この文脈が、Shippyのあらゆるアーキテクチャ上の決定を形作った。Skylightチームが繰り返し立ち返った問いは「モデルに何ができるか？」ではなく、「正確であり続け、自らの限界内にとどまり、幅広いタスクにわたって耐えうるシステムをどう構築するか？」だった。すべては、衛星や船舶信号の新しいデータが到着するたびに継続的に更新されるSkylightのライブデータに対して検証されなければならなかった。
Shippyのアーキテクチャ：ソウル、スキル、コンフィグ
SkylightはShippyというAI海事エージェントを、ソウル、スキル、コンフィグという3つの明確なレイヤーで説明している。この区別は、一見したほど些細なものではない。
ソウルはシステムプロンプトであり、Shippyのペルソナを定義し、厳格な行動上の制限を設定する。Shippyが何を行うか、そして決定的に、何を行わないか。ソウルは明示的で監査可能である：Shippyは、船舶が法律に違反しているかどうかについて法的判断を下さず、データが裏付けないことについて推測しない。これらはファインチューニングに埋め込まれた緩いガードレールではなく、システムプロンプトに直接書き込まれているため、容易に確認・改訂できる。
スキルは、特定のリクエストタイプをどのように処理するかをShippyに指示する。これらはClaude CodeやCodexのようなコーディングツールで使われているエージェント・スキル仕様と同じものに従っており、構造化されたフロントマターを持つプレーンなMarkdownファイルとして記述され、各スキルをバージョン管理し理解しやすく保っている。Shippyの現在のスキルセットには以下が含まれる：
- Skylight APIに対する船舶行動およびイベント（漁業、船舶間の積替え）のクエリ
- 排他的経済水域（EEZ）および海洋保護区（MPA）の境界の参照
- Skylight独自のモデルがすでに生成している活動分類に基づいた、船舶航跡データおよび位置信号の解釈
- アナリストがチャットの応答からSkylightマップ上の正確な位置に直接ジャンプできるようにするインタラクティブなマップリンクの生成
1つのユーザー質問で複数のスキルが同時に有効化されることがある。たとえば、船舶がCordillera de Coiba MPA付近で操業しているかどうかを尋ねると、ShippyはSkylightのデータクエリスキル、ProtectedSeasの境界データベース、および船舶航跡解釈スキルを、1回の対話ターンの中で組み合わせて利用する。
コンフィグとモデル選択の問題
コンフィグレイヤーは、どのエージェントハーネスを実行するか、どのLLMを使用するか、APIキーのようなシークレットの注入など、ランタイムに関するすべてを扱う。Shippyは現在、大規模言語モデルとしてClaude Opus 4.6上で動作している。重要なのは、基盤となるモデルの入れ替えが再構築ではなくコンフィグ変更で済む点である — ソウルとスキルはそれとは独立したDockerイメージに焼き込まれており、システムの進化に応じて異なるクエリタイプを異なるモデルにルーティングする柔軟性をチームに与えている。
非決定論的エージェントのための決定論的ツール群
初期のより示唆的な教訓の1つは、Shippyに生のAPIコールを直接構築させたことから得られた。その結果は、微妙な失敗の絶え間ない発生だった：結果を密かに取りこぼす不正なページネーション、ジオメトリのエンコードエラー、一見正しそうに見えるがフィルタータイプの誤解により誤ったデータを返すクエリ。Skylight APIには、数十種類の入力タイプ、ネストされたフィルターオブジェクト、ページネーションカーソル、複雑なジオメトリ入力が存在し、モデル生成エラーを招きやすい広大なインターフェース面がある。
その解決策が、目的別に設計された決定論的CLIである。生のAPIコールを構築する代わりに、Shippyは型付きフィルターフラグを伴うskylight events searchのような単一コマンドを発行し、CLIが認証、ページネーション、構造化出力を処理する。CLIは自己文書化されており、詳細なヘルプテキストとエラーメッセージを備えているため、エージェントは推測に頼ることなくミスから回復できる。結果は常にローカルのJSONファイルに書き出され、シェル経由のパイプに流さないことで、初期プロトタイプで大きな結果セットに対して問題となったパイプバッファ制限を回避している。
このレイヤー構造 — 型付きAPI、決定論的CLI、CLIコマンドを参照するエージェントスキル — により、各コンポーネントを独立してテストできる。各レイヤーは、次のレイヤーが間違えうる範囲を狭める。これは、高リスク領域における研究プロトタイプと本番システムを分けるアーキテクチャ上の規律である。
Kubernetesサンドボックスとデータ分離の課題
Skylightのユーザーベースは、機密性が高く管轄区域固有のデータを持つ政府機関にまたがっている。フィリピンの漁業監視官は、自身のアカウントにスコープされたウォッチリスト、関心領域（Areas of Interest）、アラート設定を持っている。彼らのデータが他のユーザーセッションに決して漏れ出さないこと、そして会話履歴が完全にプライベートに保たれることを保証することは、このプロジェクトにおける最も重要なエンジニアリング作業の1つだった。
その解決策が、SkylightのエージェントホスティングプラットフォームであるMothershipである。Mothershipは各ユーザーセッションごとに専用のKubernetesデプロイメントをプロビジョニングする。会話が開始されると、システムはエージェントランタイム、そのスキル、およびSkylight CLIをパッケージした一連のPodを起動する。ユーザーのJWTトークンはプロビジョニング時に注入され、すべてのAPIコールをそのユーザーのデータにスコープする。マルチステップ分析の間にエージェントが書き込むファイルは、そのセッション内にのみ存在し、ユーザー間でアクセスされることは決してない。
サンドボックス内で、エージェントはかなりの操作能力を保持している — コードを書いて実行し、依存関係をインストールし、データセットを取り込み、マルチステップ分析を行うことができる。ネットワークレベルでは、サンドボックスは必要なサービスのみに制限されている。この分離はセッション単位でスコープされ、エフェメラルであり、アプリケーションロジックだけに頼るのではなくインフラストラクチャレベルで強制されている。
実運用コンテキストにおけるエージェント評価
標準的なAIベンチマークは、静的な質問セットに対するモデルのスコアを測定する。しかしそれらは、エージェントが実際のワークフローに組み込まれたときに何が起こるか — どのようにツールを選択し、ライブデータをクエリし、その結果に基づいて行動し、いつ停止すべきかを判断するか — を捉えない。Skylightがカスタム評価システムを構築したのはまさにこのためである。
LLMジャッジを用いたルーブリックベースのフレームワーク
Skylightの評価フレームワークでは、専門分野のエキスパートがシナリオとルーブリックを作成し、各タスクにどの評価基準を適用するかとその重み付けを決定する。たとえば漁業イベントのクエリでは、データの正確性が最も重く評価され、次に境界の解像度と時間枠が続き、情報源の帰属はそれより低い重みとなる。エキスパートは個々の応答を正解または不正解として注釈付けし、ジャッジがスコアリングするためのグラウンドトゥルースを提供する。
パイプラインは自然言語プロンプトをライブサンドボックスに通し、LLMジャッジが各評価基準を0〜1のスケールで採点し、なぜ応答が基準を満たしたか／満たさなかったかについて文章で理由を説明する。重み付きの合計スコアは固定の合格閾値と照合される。タスクは、Skylightが構築したプラグインを介してHarborというオープン評価フレームワーク上で実行され、実際のユーザーが直面するのと同じライブデータに対して本物のShippyセッションを立ち上げる。
最近の評価実行から得られた結果は、具体的で行動可能な失敗パターンを示している。哨戒計画タスクでは、Shippyが意思決定支援の範囲を超えて戦術的な推奨に踏み込みすぎる傾向が見られた。ジオメトリに敏感なクエリでは、境界の単純化に起因するイベントの見落としが露呈した。またあるケースでは、エージェントが存在しないCLIコマンドを生成した。各パターンはスキル改善のターゲットに直接対応しており、これはまさに、よく設計された評価システムが生み出すべきものである。
Shippyの今後 — そしてその先へ
SkylightはShippyをローリングベースでアーリーアダプターに開放し、弱いガードレールや不適切に処理されたクエリをあぶり出すためのストレステストを明示的に招いている。次の開発サイクルでは3つの領域をターゲットとしている：エージェント主導のUI制御（マップリンクを返すだけでなく、Skylightマップを直接制御し、フィルターを適用し時間範囲を調整すること）、モデルルーティング（単純なルックアップをより小さく高速なモデルに振り分け、複雑な調査にはフルスペックモデルを予約すること）、そしてスレッド間メモリ（アナリストの管轄区域や好みの情報源といった永続的な事実を、別々の会話スレッド間で保持すること）。
より広い意味でのインパクトは、海事アプリケーションをはるかに超えて広がる。Mothershipはドメインに依存しないよう設計されており、Skylightの親組織であるAi2はすでに、野生生物保全プラットフォームEarthRangerや、地球観測ツールのオープンスイートであるOlmoEarthにShippyから得た教訓を適用している。このアーキテクチャ — ソウル、スキル、コンフィグ、決定論的ツール群、セッション単位で分離されたサンドボックス、ライブデータ評価 — は、誤答のコストが単なるユーザーの不満以外のもので測られるあらゆるドメインにおいて、AIエージェントをデプロイするための青写真となる。
FAQ
Shippyは何を行うよう設計されていますか？
Shippyは、リアルタイムの海洋状況把握のためにSkylightが開発したAIエージェントです。アナリストが船舶行動をクエリし、排他的経済水域および海洋保護区の境界を参照し、船舶航跡データを解釈し、Skylightのライブデータプラットフォームに直接紐づいたインタラクティブなマップリンクを生成するのを支援します。
Shippyはどのようにクエリ応答の信頼性を確保していますか？
Shippyは、すべてのSkylight APIコールを処理するために決定論的CLIを使用し、モデルが生のAPIコールを直接構築した際に発生したエラーパターンを回避します。ソウル、スキル、コンフィグというモジュラーアーキテクチャと、システムプロンプト内の厳格な行動境界を組み合わせることで、この設計は柔軟性よりも予測可能で監査可能な挙動を優先しています。
Shippyはどのように正確性と信頼性の評価を受けていますか？
Skylightは、専門分野のエキスパートがタスクシナリオと重み付けされたルーブリックを作成するカスタム評価フレームワークを構築しました。LLMジャッジが、各評価基準についてライブデータに対するエージェント応答を0〜1のスケールでスコアリングし、その理由を文章で説明します。重み付き合計は固定の合格閾値と照合され、評価基準において後退が見られるShippyのバージョンはエンドユーザーには提供されません。
Shippyは船舶活動に関する法的判断を行いますか？
いいえ。Shippyは、船舶がいかなる法律にも違反しているかどうかについて法的判断を下すことを明示的に避けており、データが裏付けないことについて推測しません。そうした判断は人間のアナリストに委ねられています。これらの制限は、モデルのファインチューニングに暗黙的に埋め込まれているのではなく、監査および調整可能な形でシステムプロンプトに直接書き込まれています。
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”Shippyは何を行うよう設計されていますか？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Shippyは、リアルタイムの海洋状況把握のためにSkylightが開発したAIエージェントです。アナリストが船舶行動をクエリし、排他的経済水域および海洋保護区の境界を参照し、船舶航跡データを解釈し、Skylightのライブデータプラットフォームに直接紐づいたインタラクティブなマップリンクを生成するのを支援します。”}},{“@type”:”Question”,”name”:”Shippyはどのようにクエリ応答の信頼性を確保していますか？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Shippyは、すべてのSkylight APIコールを処理するために決定論的CLIを使用し、モデルが生のAPIコールを直接構築した際に発生したエラーパターンを回避します。ソウル、スキル、コンフィグというモジュラーアーキテクチャと、システムプロンプト内の厳格な行動境界を組み合わせることで、この設計は柔軟性よりも予測可能で監査可能な挙動を優先しています。”}},{“@type”:”Question”,”name”:”Shippyはどのように正確性と信頼性の評価を受けていますか？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Skylightは、専門分野のエキスパートがタスクシナリオと重み付けされたルーブリックを作成するカスタム評価フレームワークを構築しました。LLMジャッジが、各評価基準についてライブデータに対するエージェント応答を0〜1のスケールでスコアリングし、その理由を文章で説明します。重み付き合計は固定の合格閾値と照合され、評価基準において後退が見られるShippyのバージョンはエンドユーザーには提供されません。”}},{“@type”:”Question”,”name”:”Shippyは船舶活動に関する法的判断を行いますか？”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”いいえ。Shippyは、船舶がいかなる法律にも違反しているかどうかについて法的判断を下すことを明示的に避けており、データが裏付けないことについて推測しません。そうした判断は人間のアナリストに委ねられています。これらの制限は、モデルのファインチューニングに暗黙的に埋め込まれているのではなく、監査および調整可能な形でシステムプロンプトに直接書き込まれています。”}}]}
本記事は人工知能の支援を受けて作成され、編集チームによるレビューを経ています。
