VISIONHUB / DAILY AI BRIEF /

業務責任者・PM / 情報システム / AI導入担当

会社の知識とルールを、
AIの仕事につなぐ。

Sakana AIが「Aquarium」を発表。情報を探して答えるだけでなく、権限・人の承認・記録と組み合わせて、組織の判断と実行を支える基盤です。

ONE-PAGE BRIEF

Aquariumで整える、AIと人の役割

文書・表・DBを共通の意味と関係でつなぎ、AIの判断・実行と人の承認へ進む。全体をアクセス権と記録で支える概念図。

誰に:会社の情報と手順を使ってAIを業務に組み込みたいチーム。/何を:判断の前提、権限、承認、実行をまとめて設計。/条件:接続とルールを整え、自社の業務で正確さと効果を確かめる。

01 / 誰の、どんな課題か

答えが出ても、会社の仕事は終わらない。

「この案件の担当は誰か」「どの資料が最新版か」「誰の承認が必要か」。AIに文章を作ってもらうだけでは、こうした前提の確認や、その後の実行が人に残ります。Aquariumが扱うのは、この判断と行動をつなぐための共通基盤です。[1]

業務責任者・PM

確認と引き継ぎが多い

案件情報や担当、判断条件をそろえ、何をAIに任せ、どこで人が決めるかを設計する。

導入判断:見落としや修正の手間も含めて、仕事が前に進むか。

情報システム・データ担当

情報の意味が部門で違う

文書・表・DBをつなぎ、用語や関係を共通化する。接続・同期は対象に合わせて設計する。

導入判断:既存の保存先・権限・更新方法と両立できるか。

管理・監査の担当

何を根拠に動いたか追いたい

権限と承認を定め、参照した情報から実行結果までを記録でたどる。

導入判断:誰が確認し、異常時にどう止め、戻すか。

読者別の課題整理・導入判断は本記事の提案です。製品固有の導入成果を示しません。

02 / 仕組みを分けて考える

データをつなぐ。意味をそろえる。手順に沿って動かす。

オントロジーとは、組織の知識・ルール・データが「何を意味し、互いにどう関わるか」を定義したものです。資料を集めるだけでなく、AIが判断に使う前提を整理します。[1][2]

DATA文書・表・DB既存の保存先につなぐ
ONTOLOGY意味・関係・ルール判断の前提をそろえる
MANAGED AGENTS参照・判断・実行承認を手順に組み込む
Governance:アクセス権 / 実行前の承認 / 根拠と結果の記録
公式説明を基にした役割の整理。矢印は情報を判断・実行につなぐ流れで、実装上の通信経路を示しません。統制は全体に関わります。

既存情報と接続する

公式発表は保存先を移し替えずにつなぐと説明。紹介ページでは、接続・同期の方法は対象に合わせて設計するとしています。すべての社内システムに即接続できるという意味ではありません。[1][2]

実行の手順を定義する

情報の参照、AIの判断、関数の実行、人の承認をワークフローにします。紹介ページにはYAMLで手順を定義する考え方が示されています。[2]

動いた後も確かめる

公式説明では、判断の根拠から結果までを記録し、速度・精度やモデル利用状況を把握します。必要な監査証跡を満たすかは、個別の要件で確認します。[1]

03 / 既存のAI利用と何が違う?

検索して答えるところから、業務の判断と実行へ。

仕組み主な役割業務で使うときの確認
チャット質問への回答や文案の作成。根拠、権限、承認、実行先をどこで扱うか。
RAG関連資料を検索し、その内容を回答に使う仕組み。検索できた資料と、業務で実行してよい行動は別。
Aquarium知識・ルール・データの関係を定義し、統制と実行手順を組み合わせる。接続・同期、定義の整備、権限・承認、評価と保守を設計する。

横長の表は左右に動かせます。これは役割の比較で、性能ランキングではありません。チャットやRAGにも権限管理・業務実行を組み合わせた製品があります。Aquariumだけが可能な機能とは断言していません。

04 / 説明用の仮想例

PMの議事録から、課題候補を出し、人が承認する。

  1. 入力と範囲を決める

    閲覧してよい議事録、案件一覧、担当領域、承認者を用意。機密会議を対象から外すなど、読める範囲を先に定める。

  2. AIが候補と根拠を出す

    「A社の確認回答待ち」を課題候補にし、担当案と該当発言を添える。期限が書かれていなければ「未定」にする。

  3. PMが承認・修正・差し戻し

    正式な課題か、担当案が妥当かを判断。承認が必要な処理は、未承認のまま実行しない設計にする。

  4. 承認した内容を登録し、結果を残す

    接続先への登録処理を別途設計。二重登録や失敗時の再実行を確認し、入力・提案・承認・結果を追えるようにする。

本記事の仮想ワークフロー。登録先の連携や例外処理の実現方法は導入時の確認事項です。

仮想の出力例

課題候補:A社の仕様確認が未完了
根拠:議事録の「回答がまだ届いていない」という発言
担当案:案件台帳の窓口担当者(PMが確認)
期限:記載なし・要確認
状態:承認待ち

05 / 導入前に何を確かめる?

まず一つの業務で、間違いと手戻りを測る。

データと権限

接続できる保存先、同期の遅れ、削除・権限変更の反映、機密情報の送信先と保存先を確認する。

承認と例外

どこで誰が止めるか、不在時の扱い、失敗時の再実行、二重処理と取り消し方法を確認する。

費用と保守

料金体系、モデル利用費、接続構築、定義の更新、監視の担当と費用を見積もる。

上記は本記事の確認項目です。提供済みの個別機能を列挙したものではありません。

  1. 架空・許可済みの入力で試す

    正解が分かる議事録などを用意し、見落とし・誤抽出・根拠の正しさを確認する。

  2. 権限と承認の境界を試す

    見せない資料、承認しない操作、情報の更新・削除を含むケースで、意図した手順になるか確かめる。

  3. 人の作業まで含めて比べる

    確認・修正の時間、完了までの時間、失敗件数、総費用を記録。許容できる条件を決めてから利用範囲を広げる。

06 / 発表と、これから確かめること

構想は具体的。効果は自社の仕事で確かめる。

公式に説明されたこと

オントロジー、統制、エージェント実行基盤の3つ。FDEとともに構築・検証を進める導入相談を案内しています。[1]

今後の開発として示されたこと

運用の修正・判断を取り込んで更新し続ける仕組みや、エージェント構築をAIが支援する仕組み。提供済み機能とは分けて読む必要があります。[1]

今回の資料で確認できないこと

公開料金、独立した性能実測、定量的な業務改善効果、Aquariumの全社本番導入実績。問い合わせと個別評価が必要です。

発表には金融機関との過去のAI実装案件が紹介されています。ただし、それらをAquarium自体の導入実績とは扱いません。Aquariumの活用事例は順次紹介する予定とされています。[1]

出典と確認範囲

  1. Sakana AI:Aquarium発表(2026年10月23日)

    3つの中核機能、開発背景、既存案件との関係、今後の開発・事例公開方針を確認。

  2. Sakana Aquarium:プラットフォーム紹介

    接続・同期の個別設計、情報更新、YAMLによるワークフローと人の承認、導入相談を確認。

確認日:2026年10月23日。機能の説明は公開時の一次資料に基づきます。PMの業務例・比較表・評価手順は本記事による整理・提案で、製品の独立評価ではありません。

ONE-PAGE BRIEF
文書・表・DBを共通の意味と関係でつなぎ、AIの判断・実行と人の承認へ進む。全体をアクセス権と記録で支える概念図。