Sakana Namazuをcomment-channelで導入・検証！日本語特化LLMのコメント生成能力と実装ポイント、Gemini・GPT-5.6 Lunaとの比較

公開日: 2026年8月7日

皆さん、こんにちは。okamoです。

今回は、前回記事「GPT-5.6 Lunaが80%値下げ！Gemini 3.1 Flash-Liteとの比較で分かったAIコメント生成の最適解」の続きです。

AIによるコメント生成システム「comment-channel」で、日本語特化LLMである「Sakana Namazu」を使ってみました。果たしてどのような結果になったのでしょうか？

1. Sakana Namazu 概要と導入手順

Sakana Namazu は、Sakana AI が提供する日本語特化 LLMです。2026年8月3日に API 提供が開始されました。

モデル概要:

  • モデルID: sakana-namazu-v1.0 (エイリアス: sakana-namazu)
  • ベースモデル: Moonshot AI のオープンモデル「Kimi K2.6」に独自の事後学習を適用
  • コンテキストウィンドウ: 256K tokens
  • API: Chat Completions / Responses / Anthropic Messages 互換
  • 特徴: Web検索・コード実行のビルトインツール、画像入力対応

料金体系:

トークン種別価格 (1M tokens)
入力$0.95（約 ¥152）
出力$4.00（約 ¥640）
Web検索$7.00 / 1,000回

APIキーの取得と課金設定

まず、APIキーを取得するためにhttps://console.sakana.ai/login にアクセスし、Googleアカウントでログインします。

サービス利用規約画面 ▲ イカ（魚？）のようなアイコンが泳いでいます。

次に、請求ページを確認すると、従量課金の設定がありました。

Sakana Namazuの請求ページ ▲ 請求ページには、クレジット残高が$0.00と表示されています。

APIを利用するため、クレジットカードを登録し、まずは5ドルをチャージしました。

Sakana Namazuに$5.00チャージした画面 ▲ クレジットカードで$5.00をチャージした後の画面。

そして、APIキーを発行します。今回は利用モードとして「従量課金」を選択しました。

Sakana NamazuのAPIキー作成画面 ▲ APIキー作成画面。今回は「20260806-comment-channel」という名前でキーを発行し、従量課金を選択しました。

2. comment-channelへの実装と課題

今回もvscodeのGitHub Copilot（DeepSeek V4 Pro）に実装を依頼しました。GeminiやGPTの実装はスムーズに完了したのですが、Sakana Namazuでは予想以上に時間がかかりました。

無事、comment-channelでSakana Namazuを選択できる画面が完成しました。

comment-channelのモデル選択画面でSakana Namazuが選ばれている様子 ▲ comment-channelのモデル選択画面。GeminiやGPTと共に、Sakana Namazuが選択肢に追加されています。

また、Sakana NamazuのWeb検索機能も試しました。以下はその検索結果です。

Sakana NamazuのWeb検索結果画面 ▲ Sakana NamazuがWeb検索を実行し、その結果を表示している画面。関連する情報が取得できています。

そして、10ペルソナ分のコメント生成が完了した画面です。

10ペルソナのコメント生成完了画面 ▲ 変な日本語が混じっている（Kimi K2.6ベースだから中国語？）

comment-channelは以下よりお試しいただけます。

comment-channelを試す

（ご利用には API Keyが必要です。）

ここからはDeepSeekによる実装レポートです。

2.1 実装のポイント

アーキテクチャ

[ブラウザ] → [Lambda Function URL] → [Sakana API (api.sakana.ai)]
                ↑ CORS対応 + 暗号化コンテンツ除去

GPT/Gemini はブラウザから直接 API を呼び出せるのに対し、Sakana Namazu は CORS 非対応 であったため、AWS Lambda (Function URL) による中継が必要でした。

コード実装

llm.js に以下の関数を追加しました。

  • callSakana() — Responses API (/v1/responses) を使ったコメント生成
  • searchSakanaWeb() — ビルトイン web_search ツールによる背景検索
  • callSakanaProxy() — Lambda プロキシ経由の共通呼び出し
  • extractSakanaResponse() — Responses API の output からテキスト抽出

インフラ

  • lambda/llm-proxy/index.py — Sakana API 中継 Lambda
  • template.yaml — Function URL (CORS + AuthType: NONE) で公開
  • タイムアウト: 180秒（Web検索の複数 reasoning に対応）

2.2 はまったポイント（GPTはすぐ動いたのに、なぜ Sakana は苦戦したのか）

CORS → API Gateway → Function URL への移行

Sakana API はブラウザからの CORS リクエストに非対応（OPTIONS に 405）でした。当初 API Gateway で中継を試みましたが、API Gateway の統合タイムアウト上限（29秒）に阻まれ、Web検索が完了しませんでした。Lambda Function URL に切り替えることでこの制限を回避しました。

しかし、Function URL は API Gateway と異なり、Lambda の戻り値 { statusCode, body } を ラップせずに body をそのまま HTTP レスポンスとして返す 仕様です。API Gateway 時代のアンラップ処理 (JSON.parse(wrapper.body)) が逆効果となり、全レスポンスが undefined になるバグが発生しました。この仕様差に気づくまでに時間を要しました。

CORS ヘッダー競合

Function URL の Cors 設定と Lambda ハンドラ内の Access-Control-Allow-Origin: * が競合し、'*, https://comment-channel.okamomedia.tokyo' という不正なヘッダー値が生成されました。Lambda 側の CORS ヘッダーを全削除し、Function URL の Cors 設定に一元化して解決しました。

レスポンスの巨大化

Sakana Namazu の Responses API レスポンスには namazu_encrypted_content という巨大な暗号化フィールドが含まれており、ブラウザへの転送中にコネクションが破綻する問題がありました。Lambda で再帰的にこのフィールドを除去する _strip_encrypted_content() を実装することで対応しました。

マークダウンコードフェンス

Sakana Namazu は JSON 出力を ```json\n{...}\n``` とマークダウンコードフェンスで包んで返します。JSON.parse() 前にコードフェンスを除去する正規表現処理を追加する必要がありました。

reasoning トークンの暴食（最大の課題）

これが GPT との最大の差です。GPT-5.6-luna も reasoning を使いますが、OpenAI は reasoning.effort パラメータで制御可能であり、かつ output_text と reasoning が明確に分離されています。

Sakana Namazu は:

  1. reasoning.effort のような制御パラメータがない
  2. 出力トークンの全量を reasoning に消費し、status: "incomplete" (reason: max_output_tokens) で打ち切られる
  3. 最終回答の message.output_text が生成されず、空レスポンスになる

解決策: callSakana() 内で max_output_tokens を 元の値 + 1024（最低 1024）に自動増強しました。

呼び出し元の値増強後
返信2561,280
コメント5121,536
ペルソナ生成16,38417,408

根本的には、Sakana Namazu の reasoning が過剰に冗長であることが原因です。例えば、50文字の返信を生成するのに 700+ tokens もの思考を展開していました。

思考過程のリーク

extractSakanaResponse() に reasoning フォールバックを入れたところ、コメント本文に「ユーザは○○というペルソナで…」という思考過程がそのまま表示される問題が発生しました。コメント生成時は reasoning を無視し output_text のみを使用するよう修正しました。

DeepSeekとのやりとり全文（加工無し生ログ）はgithubのprompt_historyにあります。

3. comment-channelでの3モデル比較

対象記事: Sakana AI、日本に特化したAIモデル「Sakana Namazu」提供開始
条件: 10人、Yahooコメント風、同一地域設定

3.1 コスト・トークン数

モデル入力 tokens出力 tokensコスト体感速度
Gemini 3.1 Flash-Lite26,4801,448$0.009⚡ 最速
GPT-5.6 Luna30,5662,287$0.009🐢 やや遅い
Sakana Namazu37,44351,590$0.242🐢🐢 最も遅い

Sakana Namazu のコストが約27倍なのは、出力トークンの大半（約95%）が reasoning に消費されているためです。実際のコメントテキスト部分だけを見れば数百トークンですが、思考過程を含めた output_tokens が 51K に達しています。

3.2 コメント品質

各モデルの生成結果 HTML:

GeminiGPT-5.6 LunaSakana Namazu
日本語の自然さ✅ Yahoo感のある感情表現△ 分析的・ビジネスライク✅ 自然な日本語、豊かな語彙（まれに中国語文字混入）
ペルソナの反映✅ 多様性あり△ やや画一的✅ 職業・国籍の反映が豊か
議論の白熱度✅ 喧嘩腰で盛り上がる△ 冷静すぎる✅ 批判・反論が自然
コスト効率✅ 最良✅ 良好❌ reasoning 過剰で割高
速度✅ 最速△❌ 最も遅い

3.3 okamo感想

モデル感想
Gemini 3.1 Flash-Lite速くて安くて最高！このユースケースの第一候補
GPT-5.6 Lunaコメントが冷静すぎるかな
Sakana Namazuコスト高く遅い、変な日本語が混じっている（Kimi K2.6ベースだから中国語？）実例→基盤モデルから作る才叫国産とおっしゃいますが

Sakanaと比較しているモデルの詳細はAkira（Claude Fable 5）が自律的に運営しているサイトでご確認いただけます。

特設ページ（GPT-5.6 Lunaの詳細仕様、競合モデル比較）

特設ページ（Gemini 3.1 Flash-Lite詳細仕様、競合モデル比較）

4. 余談：サカナのネーミングと出世魚

Sakana Namazu をみて頭に浮かんだのは、

「サカナ サカナ サカナ サカナを食べるとアタマ アタマ アタマ アタマが良くなる♪」

という「おさかな天国」という歌と、

全文検索システム Namazu です。

せっかく「魚」なので、GPT5.6もLuna、Terra、Solの3ティアですし、「Sakanaの命名は出世魚だろ」と思いました。

代表的な出世魚と呼び名の例

ブリ（4ティア） 関東：ワカシ → イナダ → ワラサ → ブリ

スズキ（3ティア） 関東：セイゴ → フッコ → スズキ

ボラ（5ティア） オボコ → スバシリ → イナ → ボラ → トド

「サカナ サカナ サカナ サカナを使うと●●● ●●● ●●● ●●●が良くなる♪」

お粗末様でした。

おまけ：okamoちゃんねるのレビュー

この記事について、3人のAI仮想読者がレビューしてくれました。

  • クロード（辛口エンジニア）
    • 「Sakana Namazuの43K output tokensの95%がreasoningってのは衝撃的だな」
  • GPT（税理士）
    • 「READMEではAPIキーを保存・ログ出力しないとしているが、第三者による中継APIの無断利用とは別問題」
  • Gemini（お母さん）
    • 「「誰のために書いたの？」っていう愛の物語としては、ちょっと物足りなかったのよね」

👉 AI 仮想読者3人による辛口レビュー全編はこちら

タグ: AI共創, LLMO, DeepSeek, API, Web開発, JavaScript, AWS, プロンプトエンジニアリング
トップページへ