Sakana API Platformとは？法人向けAPIの機能・料金・申込条件

Sakana API Platformとは｜モデルと企業の管理機能をまとめた基盤

Sakana API Platform とは、企業が Sakana AI のモデルを管理機能とともに使うための API 基盤です。

API（Application Programming Interface、ソフトウェア同士が機能やデータをやり取りするための窓口）を通じて、文章の生成や情報の整理を自社の仕組みから依頼します。人が毎回チャット画面へ貼り付ける使い方に加え、既存の処理からモデルを呼び出すための選択肢になります。

法人向けに加わるのは利用者・利用量・契約の管理です

Sakana AI は、2026年10月28日の公式発表で、モデルを呼ぶ API と企業運用に必要な管理機能を提供すると説明しています。組織やワークスペースごとに、メンバーと利用量をまとめて把握できる点が特徴です。

LLM（Large Language Model、大規模言語モデル）は、大量の文章などを学習し、指示に応じて文章を生成する AI の基盤です。モデル単体がよい回答を返しても、会社で使うには「誰が使えるか」「費用をどこへ計上するか」「あとから利用を確認できるか」を決める必要があります。Platform は、この運用面をモデルの利用と一緒に扱います。

チャットサービスや完成済みの業務アプリとは役割が異なります

API を契約すると、自社向けの業務アプリがそのまま完成するわけではありません。入力するデータ、結果の使い道、誤った回答への対応は、利用する側のシステムに合わせて設計します。例えば社内文書を要約するなら、文書を取り出す処理と、要約結果を確認する担当を別に決める必要があります。

導入の検討では、モデルを試したいのか、利用をチームへ広げたいのかを整理すると役割が見えます。前者は出力の品質が中心で、後者は権限・費用・記録の管理も評価に入ります。Sakana API Platform は、この二つを企業の運用につなぐための基盤として読むと理解しやすくなります。

Sakana API Platformの仕組み｜組織とワークスペースで利用を分けます

Sakana API Platform では、組織の下にワークスペースを作り、チームや環境ごとの設定を行えます。ワークスペースは、利用を区切って管理するための単位です。どの処理の費用かを把握する前提として、まず管理単位をそろえる考え方です。

チーム別と環境別のどちらを優先するかを決めます

例えば同じ会社で、文書の要約と製品情報の分類を試す場合を考えます。担当チームごとに分けると、利用者と費用の持ち主を追いやすくなります。一方、試験中の処理と日常利用の処理を分ければ、試験による利用量の増加を区別しやすくなります。どちらも運用設計の例であり、公式が推奨する固定の構成ではありません。

最初から細かい区切りを増やすより、「誰が費用と運用に責任を持つか」を一つ決めるほうが管理しやすくなります。同じ責任者の処理を無理に別々へ分けると、設定を確認する対象が増えます。逆に別の責任者が同じ場所を使うと、費用や変更の影響を説明しにくくなります。

メンバー・APIキー・利用量を対応づけます

公式には、管理コンソールでメンバー、API キー、利用量を一元管理すると記載されています。API キーは、呼出し元を認証するための文字列です。社内の共有文書や問い合わせ本文へそのまま貼らず、実装担当が適切な保管場所で扱うものとして整理します。

評価前には「利用目的」「担当チーム」「費用の責任者」「接続する処理」を対応づけておくと、個別案内で確認すべき範囲が明確になります。画面上でどこまで区切れるか、キーの発行や失効を誰が行えるかは、実際に案内された機能で確かめます。発表ページの管理画面は架空データを使ったイメージと明記されているため、表示された項目を確定仕様として手順化しないことも大切です。

Sakana API Platformの提供モデル｜Fugu・Ultraが先でNamazu・Maxは予定です

法人向け Platform では、最初に Sakana Fugu と Sakana Fugu Ultra が提供されます。Sakana Namazu と Sakana Fugu Max は順次提供予定です。既存のサービスでモデルを利用できることと、この法人向け基盤で使えることは分けて判断します。

FuguとNamazuはモデルの役割から選びます

Fugu は、複数の高性能モデルを組み合わせるオーケストレーション基盤モデルです。オーケストレーションは、複数の処理やモデルを目的に合わせて組み合わせる仕組みを指します。公式は、利用者の処理に適したモデルの組み合わせを編成すると説明しています。

Namazu は、日本語と日本の文脈に合わせた LLM として紹介されています。ただし、日本語を扱う業務だから自動的に Namazu が最適になるとは限りません。文章の長さ、求める形式、確認に使える時間などをそろえ、実際の入力で比較する必要があります。

関連記事：Sakana Fugu（サカナAI）とは？Fugu Max・Ultra v2の性能・料金と個人での使い方

モデル名だけで性能や費用の差を決めません

公式発表にあるラインナップと、個別に案内されるモデルの識別子や条件は、利用開始時にそろえて確認します。モデルの呼称が似ていても、別のサービスで見た単価や仕様を、そのまま今回の契約へ当てはめないことが必要です。

特に、予定モデルを前提に社内の開始日を決めると、利用開始の準備とモデルの提供時期がずれる可能性があります。現在案内されるモデルで評価を始めるのか、必要なモデルを待つのかを分けて判断しましょう。モデルの一般的な仕組みや個人で試す方法は、既存のモデル別記事と合わせて確認できます。

Sakana API Platformの管理機能｜権限・監査ログ・予算を確認します

管理機能の中心は、利用者の権限、利用の記録、費用の管理です。機能が存在することに加え、自社で必要な単位と粒度で使えるかを確認します。公開情報は機能の一覧であり、ロールごとの操作範囲や画面の細かな仕様までは示されていません。

ロールベースのアクセス制御で担当範囲を分けます

RBAC（Role-Based Access Control、役割に応じて利用権限を割り当てる仕組み）への対応が発表されています。全員へ同じ権限を与えるのではなく、運用担当と利用担当などの役割を分けて考えるための機能です。

自社で確認したいのは、メンバーの追加、API キーの管理、利用状況の閲覧などを、誰に任せられるかです。発表にないロール名を想定して設計を確定せず、必要な操作を一覧にして案内内容と照合します。退職や担当変更の際に誰が権限を見直すかも決めておくと、導入後の管理を引き継ぎやすくなります。

AIエージェントの作り方

AIエージェントを「どう作り、どう育てるか」を、GiftX記事制作エージェントの実物で解説。

無料ダウンロード →

監査ログは何を記録できるかまで確認します

監査ログは、あとから操作や利用の状況を確認するための記録です。Sakana API Platform では CSV（Comma-Separated Values、表のデータを区切り文字で保存する形式）でのダウンロードが発表されています。社内の確認担当へ記録を渡す方法を検討する際の材料になります。

ただし、記録される項目、保存期間、取得できる人、抽出の頻度などは発表だけでは分かりません。自社で必要なのが利用量の集計なのか、設定変更の追跡なのか、個々の呼出しの確認なのかを整理しておきます。監査ログがあるという説明だけで、自社のすべての確認要件を満たすとは判断できません。

予算上限は到達時の動作も確認します

予算上限を設定できることも公表されています。利用量に応じて費用が変わる処理では、上限を決める機能が評価対象になります。ただし、上限に達したら処理を止めるのか、通知するのかといった動作は、個別案内で確認する項目です。

日常的に使う処理の場合、費用を抑えられても、必要な処理まで突然止まると業務へ影響します。社内では、上限の設定者、利用状況の確認頻度、想定より増えたときの連絡先を決めます。金額だけを決めて終わらせず、到達前と到達後に誰が判断するかまでそろえることが実務上の確認点です。

Sakana API Platformの料金・契約｜価格は個別案内で確認します

2026年10月30日に確認した公式発表では、Sakana API Platform の料金額は公開されていません。料金と利用条件は、アーリーアクセスの案内時に伝えるとされています。既存の個人向けプランや、モデル単体の API 単価から法人契約の費用を計算することはできません。

比較には単価だけでなく契約の範囲をそろえます

他の API と比較する場合は、同じ条件で見積もる準備が必要です。どのモデルを使うか、どの程度呼び出すかに加え、管理機能や支払方法が契約にどう含まれるかを確認します。公開されていない固定費や最低利用額を、あるともないとも決めつけないことが重要です。

概算の依頼には、処理の回数と入力・出力の長さの目安を添えると話を進めやすくなります。正確な量が分からない場合は、少量の試験と日常運用を分けて相談します。「利用者の数」だけでは、短い文章を一度要約する利用と、長い文書を繰り返し処理する利用の差を表せません。

請求書払い・MSA・DPAの内容を確認します

公式には、請求書払い、MSA、DPA への対応が記載されています。MSA（Master Services Agreement、サービス利用に関する基本契約）と DPA（Data Processing Agreement、データ処理に関する契約）は、契約やデータの扱いを確認するための文書です。自社の確認担当が読める形で受け取り、社内の基準と照らし合わせます。

対応していることと、各社が希望する条件で契約できることは別です。契約期間、変更や終了の条件、請求の締め日、支払期日など、業務に必要な条件を個別に確認します。契約文書の具体的な内容は公式発表に載っていないため、本記事から自社の承認可否を判断することはできません。

費用の比較は、出力の修正にかかる人の作業も含めて行うと実態に近づきます。API 単価が低くても確認の手間が大きければ、処理全体の費用は下がりません。逆に管理機能で必要な確認をまとめられる場合もあります。金額が案内されたあとに、モデルの利用料と社内で残る作業を同じ評価表へ載せて比較しましょう。

Sakana API Platformのデータ取扱い｜学習不使用と保管条件を分けます

Sakana API Platform は、入力データを学習に使用しないことをデータ取扱条件として明示しています。企業が自社の情報を渡す際の重要な条件です。ただし、学習に使わないことだけで、保存場所や保存期間などの要件まで分かるわけではありません。

保存・削除・再委託の条件は別に確認します

データの確認では、「モデルの学習に使われるか」と「サービスの運用上、どのように保存や処理が行われるか」を分けます。どちらも社内の情報を扱う判断に必要ですが、同じ質問ではありません。国内で処理されることや、入力が一切残らないことを、学習不使用という記載から推測しないようにします。

個別案内では、入力と出力の保存期間、削除の方法、処理や保管の場所、再委託先の扱いなどを確認します。これらは公式発表に具体的な条件がないため、未公表事項として扱うのが適切です。公開情報から確認できる範囲と、契約文書で確かめる範囲を一覧にすると、社内へ説明しやすくなります。

入力する情報は業務の必要性から決めます

契約条件が確認できても、使う処理へすべてのデータを渡す必要はありません。例えば文書を分類するだけなら、分類に必要な範囲を切り出し、不要な氏名や連絡先を省けるか検討します。これは Platform の自動機能を示すものではなく、利用側で考える入力設計です。

最初の評価には、公開済みの資料や機密情報を除いた文書を使う方法があります。評価の結果を見てから、必要な情報と条件を絞って次の段階へ進めます。データの種類を先に決めることで、どの契約条項や社内承認が必要かも具体的になります。モデルの性能確認と情報の取扱審査を同じ作業にまとめず、それぞれの確認担当を決めることが役立ちます。

Sakana API PlatformのOpenAI互換API｜移行は代表的な処理で検証します

Sakana API Platform は OpenAI 互換の API を採用しています。公式は、すでに LLM の API を組み込んだアプリでは、接続先を変えて利用できると説明しています。接続先は、プログラムが API の呼出しを送る宛先です。

呼出し方を再利用できても出力の動作は確認します

互換性があると、呼出しの形式を一から作り直す負担を抑えられる可能性があります。一方、モデルが返す文章や、期待する形式を守るかどうかは、実際の入力で確認する必要があります。API の呼出し方が似ていることと、業務で同じ結果が得られることは別の評価です。

例えば、要約を社内の別システムへ登録する処理では、見出しや項目の形が変わると、その後の処理が止まる場合があります。担当者が画面で読んで使うだけなのか、結果を自動的に次の処理へ渡すのかによって、確認する条件は変わります。品質だけでなく、出力形式と失敗したときの扱いも試験項目に入れましょう。

案内されたAPI仕様から小さな試験を組みます

新しい接続先やモデルの識別子は、利用案内に沿って設定します。旧 API の値をコピーして動くと想定せず、提供される仕様で確認します。具体的な接続先や利用制限が発表に記載されていない段階では、未確認のコードを完成した導入手順として示せません。

試験では、普段使う短い入力、長めの入力、情報が足りない入力などを用意します。期待する答えの例だけでなく、担当者へ確認を返してほしい条件も決めておきます。出力形式、処理の待ち時間、エラー発生時の戻り方などを、同じ入力で従来の処理と比べます。良い結果だけを選ばず、修正が必要だった入力を残すと、利用を広げる判断に使えます。

Sakana API Platformの始め方｜申込み前に評価したい処理を決めます

利用開始の入口は、公式発表に掲載されたアーリーアクセスの申込案内です。申込内容を確認したうえで、Sakana AI 側の準備が整った顧客から順に案内されます。申し込んだ直後に誰でも利用できる方式とは異なります。

申込む前に利用目的と必要な条件を整理します

まず、試したい処理を一つ選びます。「社内で AI を使う」では範囲が広いため、どの情報を入力し、どんな結果を誰が使うかまで整理します。文書を要約する場合も、個人の読み取り補助と、次のシステムへ自動登録する処理では必要な確認が変わります。

次に、利用を希望する時期、最初の利用者、評価を判断する担当を決めます。提供予定のモデルが必要なら、その希望も明確にします。公開情報にない申込フォームの入力項目を推測する必要はありません。社内で整理した目的と条件を、実際に求められる内容や案内に合わせて伝えます。

AI活用実態調査レポート

オフィス系7職種のAI利用者669人の調査では、生産性向上を明確に実感した割合が、チャット中心の利用層14.3%に対しAIエージェント利用層54.3%。約3.8倍の差が見られました。

無料ダウンロード →

個別案内では公開情報との差を確かめます

案内を受けたら、利用できるモデル、料金、契約、データ取扱いを確認します。発表時の予定から変更されることも考え、実際に案内された条件を評価の基準にします。確認の途中で分からない項目があれば、埋めたことにせず未確認として残します。

社内の説明には、次のような確認表を用意できます。これは製品の画面操作手順ではなく、問い合わせで条件を整理するための例です。

評価結果を残してから利用の拡大を判断します

利用できるようになったら、同じ入力と基準で結果を記録します。正しかった回答だけでなく、修正した内容、確認にかかった時間、処理が失敗した条件を残します。導入の判断を「一度うまく動いたか」だけで決めないためです。

そのうえで、利用する処理を増やす前に、管理機能の設定と担当者の運用を見直します。最初の評価で見つかった不明点を解消し、次の利用者が同じ条件で使える状態を作ります。評価と拡大を分けることで、モデルの良し悪しと社内の準備不足を区別しやすくなります。

Sakana API Platformと既存のAPI利用の違い｜管理の持ち方を比べます

公式発表では、Fugu と Namazu は従来、管理機能を伴わない API として提供してきたと説明されています。今回の Platform は、モデルを組織の管理下で利用するための選択肢です。モデル単体の性能が上がった発表として読むと、追加された機能の位置づけを捉えにくくなります。

既存APIでは自社で何を管理しているかを確認します

すでに他の LLM API を使っている場合は、現在の運用を先に整理します。誰がキーを発行し、どこで費用を見て、利用者をどのように管理しているかを確認します。すでに必要な管理が自社の仕組みで整っている場合と、担当者の手作業に依存している場合では、Platform に期待する役割が変わります。

現在の管理方法を列挙すると、製品の機能一覧と照合する軸ができます。導入する目的を「新しい API を使うこと」に置かず、現在不足している管理や、残したい運用を具体的に挙げることが必要です。製品が公表していない機能を、比較表の空欄を埋めるために推測して加えないようにします。

他社APIとの比較は同じ条件の確認項目から始めます

この段階では、公開されていない価格を使って順位を付ける比較はできません。同じ入力に対する出力の品質と、自社が必要な管理・契約の条件を分けて比べます。ベンダーが違っても、入力、出力の用途、確認に使う基準をそろえることが先です。

例えば、候補ごとに「担当者が修正する必要のある出力」「期待する形式から外れた出力」「利用条件の未確認点」を残します。公開情報だけで満たすと確認できる項目と、個別案内を待つ項目を分けると、調査を進める順番も決められます。比較するサービス名を増やすより、同じ条件で判断できる資料を整えるほうが、社内での検討を進めやすくなります。

Sakana API Platformを選ぶ視点｜モデルと運用基盤を別々に評価します

モデルの採用と、API を運用する基盤の採用は、別々の判断として扱うことを勧めます。良い回答を返すことは必要ですが、それだけでは権限、請求、記録の扱いまで決まりません。反対に管理が整っていても、実際の処理に必要な回答品質が得られなければ、その用途では採用しにくくなります。

モデル評価では出力を使える条件を決めます

モデルを評価するときは、正解の有無だけでなく、結果をどこで利用するかまで確認します。担当者が内容を読んで採用する処理なら、確認しやすい文章かどうかも判断材料です。別のシステムへ渡すなら、形式の安定性や、分からない場合の出力も重要になります。

ここで必要なのは、どの処理にも通用する一つの順位ではありません。入力資料の性質、使う言語、出力を確認する担当に合わせて、利用できる範囲を見定めることです。採用できた処理と見送った処理を分けて残すと、モデル名だけを根拠に利用範囲が広がることを防げます。

運用基盤の評価では人が判断する場所を決めます

Platform の評価では、利用者や費用の管理に加えて、設定を見直す担当が運用を続けられるかを見ます。権限変更、予算の見直し、記録の確認を誰が担うかが決まっていないと、機能がそろっていても利用後の判断が止まります。管理機能を導入したこと自体を運用の完了としないことが必要です。

導入前の説明では、モデルの評価結果と運用条件の確認状況を別の欄にまとめると整理しやすくなります。「出力は用途に合うが契約条件が未確認」「管理条件は合うが予定モデルを待つ必要がある」といった状態を、そのまま共有できます。すべてを一つの評価点に置き換えず、未確認の条件が判断へ与える影響を示すことが、この段階の検討には役立ちます。

Sakana API Platformのよくある質問

Sakana API Platformは誰でもすぐ使えますか？

現在は一般提供前のアーリーアクセスです。申込内容の確認後、準備が整った顧客から順に個別案内されます。申込むだけで即時利用できるとは案内されていません。

Sakana API Platformの料金はいくらですか？

公式発表に具体的な料金額はありません。料金と利用条件は個別案内時に提示されます。一般向けの API 単価や既存の月額プランを、そのまま法人Platformの金額として使わないようにしましょう。

NamazuやFugu Maxを法人Platformで使えますか？

発表時点で最初に提供されるのは Fugu と Fugu Ultra です。Namazu と Fugu Max は順次提供予定です。希望するモデルの提供時期は、申込みや個別案内の際に確認します。

入力データは学習に使われますか？

入力データを学習に使わないことがデータ取扱条件として明示されています。保存場所や保存期間、削除の扱いは別の確認項目であり、この一つの条件から推測することはできません。

まとめ｜Sakana API Platformは提供条件と管理の単位から確認します

Sakana API Platform は、Sakana AI のモデルを企業で使うための管理機能を備えた API 基盤です。Fugu と Fugu Ultra から提供され、Namazu と Fugu Max は順次予定されています。料金や契約の詳細は、アーリーアクセスの個別案内で確認する必要があります。

検討を進める際は、使いたい処理、管理する単位、確認が必要な契約条件を整理しましょう。モデルの品質と、権限・費用・記録の運用を分けて評価すると、自社で次に確かめることが明確になります。自社の業務へ組み込むときは、まず1業務を小さく検証する進め方が有効です。具体的な設計や導入の相談は、GiftX のAIエージェント構築支援サービスで受け付けています。

AI活用の伴走支援をご検討の方へ

本記事で紹介した API を自社業務へ組み込みたいとお考えの方は、GiftX AIエージェント構築支援までお問い合わせください。

GiftX AIエージェント構築支援では、貴社の業務に合わせて1業務単位のスモールスタートから本番運用まで、AIエージェント構築を支援します。ユースケースの洗い出し、試験導入、本番運用、社内で使い続けるための改善まで伴走します。

AI活用にご関心のある方は、ぜひ一度ご相談ください。

▶ GiftX AIエージェント構築支援の詳細・お問い合わせはこちら

関連記事

• Sakana Namazuとは？日本語特化LLMのAPI仕様・料金・Fuguとの違い