mozillazg

無料枠3,000リクエストで「新規事業のAIエージェントチーム」 ─ さくらのAI Engine 5モデルを分担させる日次バッチ 本記事の概要 さくらのAI Engine の基盤モデル無償プラン(チャット生成 3,000回/月まで無料)を使って、米国・中国のテックニュースから新規事業案と MVP 設計を毎朝メールで届けるバッチを作りました 工程ごとに gpt-oss-120b / Kimi-K2.6 / Kimi-K2.7-Code / llm-jp-3.1 を使い分け、「アナリスト」「企画担当」「テックリード」「エンジニア」「編集者」の小さな AIエージェントチームとして動かすことにしました 消費は 1日7リクエスト、月に約220リクエストで、無料枠の 7% ほどです。リトライも含めてリクエスト数を数え、上限に達したら止まる仕組みも入れました 注意点は「回数」より 「1リクエストあたりのトークン」。推論モデルは考える段階でもトークンを使うため、max_tokens が足りないと JSON が途中で切れます 基盤モデル無償プラン:チャット生成は 3,000回/月まで無料 はじめに:3,000リクエストは「バッチ」向き さくらのAI Engine には 基盤モデル無償プラン と 従量課金プラン があります。無償プランでもチャット生成(chat completions)を 月3,000リクエストまで 無料で使えます。しかも gpt-oss や Kimi、Qwen、Gemma など、複数のモデルを同じ OpenAI 互換 API で選べます。 導入手順は公式ページと、すでに多くの方が書いている Zenn などの記事が分かりやすいので、この記事では省きます。 さくらのAI Engine 公式 zenn.dev zenn.dev ここで考えたいのは 月3,000回をどう使うか です。1日あたりにすると約100回になります。 ユーザーのリクエストに応じて LLM を呼ぶサービス:ユーザー数に比例して消費が増えるので、少しバズるだけで枠を使い切ります(アクセスがごく少ないなら別ですが) 呼び出し回数が決まっているバッチ:1日に何回呼ぶかを設計の段階で決められるので、無料枠と相性が良いです このようなことから「毎朝1回、決まった回数だけ呼ぶバッチ」を作ることにしました。 無料枠の落とし穴:回数ではなくトークン 「3,000回まで無料」と聞くと回数だけを気にしがちですが、実際に効いてくるのは 1リクエストで扱えるトークン数(コンテキスト長) です。 例として、米国上場企業の年次報告書(10-K)を LLM に要約させるケースを考えます。 ※趣味で米国株の適時開示の日本語サマリーサイトを作っています。 8-k-insights.netlify.app Apple の最新 10-K を edgartools で取得し、データ量を測りました(トークン数は英文で「4文字 ≒ 1トークン」とした概算です)。 Item 7(MD&A:経営者による業績分析)だけを抽出した場合 $ python3 item7.py Apple (AAPL) の最新 10-K を SEC EDGAR から取得中... Item 7 抽出完了! 文字数: 17,839 文字 (概算トークン数: 4,459 tokens) 10-K の全文 $ python3 token_test.py === Apple 10-K 全文データ量（計測結果） === 総文字数 : 297,053 文字 概算トークン数 : 約 74,263 tokens 対象 概算トークン gpt-oss-120b (128K) llm-jp-3.1 (4K) 10-K の Item 7 のみ 約4.5K OK 入力だけで超える 10-K の全文 約74K △ 入りはするが、出力と思考の分を圧迫する NG 10-K 1冊を丸ごと渡すような処理では、モデルによってはまったく収まりません。128K のモデルでも、入力が長くなるほど応答速度や精度が落ちる可能性があります。100万トークン級のコンテキストを持つ Gemini Flash 系の無料枠のほうが、こうした超長文には向いています(Groq などの無料枠にも、1日あたりのトークン上限があります。自分がテストした感じだと20万トークン/日)。 ただ、これは極端な例です。ニュースの見出しや抜粋を扱う程度なら数千〜1万トークンで足りるので、ほとんどのユースケースでは問題になりません。それでも 「回数無料 ≠ 何でも投げてよい」 は頭に入れておくと良いと思います。 ! 後で詳しく書きますが、gpt-oss や Kimi のような推論モデルは、回答の前の「思考」でも出力トークンを使います。入力が短くても max_tokens が足りずに出力が途中で切れることがあるので、注意が必要です。 さくらのAI Engine で使えるモデル コントロールパネルの「利用可能なモデル」。従量課金での単価もここで確認できる モデル コンテキスト長の目安 従量単価(入力 / 出力, 1万トークンあたり) 特徴・向いている用途 gpt-oss-120b 128K ¥0.15 / ¥0.75 推論・分析・ツール利用に強い汎用モデル llm-jp-3.1-8x13b-instruct4 4K ¥0.15 / ¥0.75 日本語に最適化した国産モデル。日本語の生成・要約向け preview/Kimi-K2.6 256K ¥0.60 / ¥3.00 長文理解・分析・文章作成に強い汎用モデル preview/Kimi-K2.7-Code 256K ¥0.52 / ¥5.04 コーディング特化。コード生成・設計・デバッグ preview/Phi-4-mini-instruct-cpu 128K ¥0.01 / ¥0.03 小型・低コスト。分類や簡単な要約 preview/Qwen3-0.6B-cpu 32K ¥0.01 / ¥0.03 非常に軽量・高速。定型処理 preview/Qwen3-VL-30B-A3B-Instruct 256K ¥0.10 / ¥0.30 画像・動画の理解。OCR、画面解析 preview/Qwen3.6-35B-A3B 256K ¥0.30 / ¥1.50 文章と画像を扱えるバランス型 preview/gemma-4-31B-it 256K ¥0.24 / ¥0.96 Google 系のマルチモーダルモデル ※ 2026年11月時点の、筆者の表示です。preview/ が付いたモデルはパブリックプレビューなので、提供終了や仕様変更の可能性があります。 ! API で指定するモデル ID には preview/ 接頭辞が付く ものがあります(例:preview/Kimi-K2.6)。/v1/models で一覧を取れるので、最初に確認しておくと事故を防げます。 curl -s api.ai.sakura.ad.jp \ -H "Authorization: Bearer $SAKURA_AI_TOKEN" | jq -r '.data[].id' 作ったもの:毎朝届く「テック×ビジネスアイデア日報」 シリコンバレーと中国のテックニュースを毎朝分析し、そこから考えられるビジネスモデルと、その MVP の実装方法・マーケティング案をメールで届けるバッチ です。GUI はなく、VPS 上で systemd timer から1日1回起動します。 メールの構成は次のとおりです。 本日のサマリー(朝30秒で読める分量) 英語のテックニュース 2本(原文の抜粋 + 日本語訳) 中国語のテックニュース 2本(原文 + ピンイン + 日本語訳)。中国語の勉強も兼ねています ビジネスアイデア 2案。それぞれに次の内容が付きます 課題、ソリューション、ターゲット、収益モデル、なぜ今か、競合との差別化 実現可能性のスコア(技術・コスト・速度・市場性・リスク、各5点満点) MVP 設計(スコープ、やらないこと、技術スタック、アーキテクチャ、データモデル、マイルストーン、KPI) マーケティング案(ポジショニング、価格、ローンチ手順、獲得チャネル) 実際のメールのサンプルの一部です。 テック×ビジネスアイデア日報 2026-11-07 2. 中国語テックニュース(ピンイン・日本語訳付き) 办公提效之后，企业级 Agent 开始对经营结果负责 bàn gōng tí xiào zhī hòu， qǐ yè jí Agent kāi shǐ duì jīng yíng jié guǒ fù zé [C2] 极客公园 过去一年，智能体是 AI 行业最受关注的方向之一。 guò qù yī nián， zhì néng tǐ shì AI háng yè zuì shòu guān zhù de fāng xiàng zhī yī。 ... 業務効率化の次は、企業向けエージェントが経営結果に責任を持つ 3. ビジネスアイデア提案 案1. AgentLedger 社内の複数AIエージェントの「利用コスト＆ガバナンス」を自動集計し、経費精算までワンストップ化するSaaS。 課題: 企業向けAIエージェントが複数導入されると、部門別の利用コスト、機密情報の入力有無、 成果の追跡が煩雑になり、経理とITの負荷が急増している。 収益モデル: 企業が月額3万円（20名以下）〜10万円（200名以下）をサブスクで支払う。 ... 実現可能性評価 技術 4 / コスト 4 / 速度 5 / 市場性 3 / リスク 3 → 合計 19/25 MVP期間 5週 🛠 MVP実装設計 backend: Python 3.11 + FastAPI + SQLAlchemy + Alembic database: PostgreSQL 15（さくらのクラウド マネージドデータベース or 同一VPS上のDocker） infra: さくらのクラウド VPS + Docker Compose + Nginx + Let's Encrypt + GitHub Actions ... 中国の記事で起きた「エージェントが業務効率化から経営成果の段階に入った」という話を、日本の中小企業向けの AI コスト管理 SaaS に落とし込んでいます。こんなメールを毎朝自動で出すようにして、毎日、新しいビジネスアイディアを考える習慣を強制的に作ろうと思っています。 アーキテクチャ:工程ごとに得意なモデルを割り当てる この構成の肝は、1つの LLM に全部を頼まないこと です。Manus のような「プランナー」「リサーチャー」「評価者」を組み合わせるエージェント構成を、モデルの役割分担で簡易的に再現しました。 工程 役割 モデル 選んだ理由 回数/日 ニュース収集 ─ (LLM 不使用) RSS で十分 0 トレンド分析・掲載記事の選定 アナリスト gpt-oss-120b 約100件の見出しから構造を読み取る推論力 1 掲載記事の日本語訳 翻訳者 Kimi-K2.6 中国語→日本語の品質と長文への強さ 1 ビジネスアイデア生成 企画担当 Kimi-K2.6 発想の幅と文章力(temperature 0.8) 1 実現可能性の評価 CTO gpt-oss-120b 楽観に偏らない冷静な採点(temperature 0.3) 1 MVP 設計・マーケティング案 エンジニア Kimi-K2.7-Code 技術スタックやデータモデルの具体性 2 本日のサマリー 編集者 llm-jp-3.1-8x13b 自然な日本語。入力が短いので 4K に収まる 1 ピンイン付与 ─ pypinyin LLM を使う必要がない 0 合計 7 設計でのポイントは3つです。 LLM でなくてよい処理は LLM に投げない:ニュース収集は RSS、ピンインは pypinyin で済ませています。ピンインを LLM に作らせると声調を間違えることがあり、リクエストも1回分無駄になります まとめて処理できるものはまとめる:翻訳は記事ごとではなく、4本を1リクエストにまとめています コンテキスト長に合わせて仕事を割り振る:llm-jp は 4K なので、トレンドの見出しとアイデアのタイトルだけを渡すサマリー担当にしました 月のリクエスト見積もり 通常 : 7 回/日 × 31日 = 217 回/月 (無料枠の約 7%) 最悪ケース: 各工程が「リトライ3回 × JSON再生成2回」まで失敗しても ≒ 6 回 × 7 工程 = 42 回/日 × 31日 ≒ 1,300 回/月 (それでも枠内) 残りの枠は、ほかのバッチを追加したり、NUM_IDEAS を増やしたりする余地として使えます。 さくらAI Engine API実装のポイント 全体は Python で 800行ほどです。OpenAI 互換 API なので、公式の openai SDK の base_url を差し替えるだけで使えます。 from openai import OpenAI client = OpenAI( base_url="api.ai.sakura.ad.jp", api_key=os.environ["SAKURA_AI_TOKEN"], # アカウントトークン(ID:シークレット形式) max_retries=0, # SDK の自動リトライは数えられないので切り、自前で管理する ) 1. リクエスト数を自前で数え、上限で止める 無料枠を超えるとレートリミットがかかります(従量課金プランなら課金されます)。そこで リトライも含めたすべてのリクエストを、月単位で JSON ファイルに記録 しています。MONTHLY_REQUEST_LIMIT(既定 2,500)に達したら、それ以上呼びません。 max_retries=0 にしているのがポイントです。SDK の自動リトライは裏で実行されるので、自分のカウンタに反映されません。 def chat(model, system, user, *, max_tokens=4000, temperature=0.7, retries=2, timeout=300): """1回のチャット補完。リトライも1リクエストとしてカウントする。""" for attempt in range(retries + 1): if usage_this_month() >= config.MONTHLY_REQUEST_LIMIT: raise QuotaExceeded("今月のリクエスト数が上限に達しました") _record(model) # ← 送信する「前」に記録する(失敗しても1回は1回) resp = client.chat.completions.create(...) ... data/usage.json にはモデルごとの内訳も残るので、どのモデルが枠を使っているかが一目で分かります。 { "2026-11": { "total": 31, "by_model": { "gpt-oss-120b": 8, "preview/Kimi-K2.6": 12, "preview/Kimi-K2.7-Code": 8, "llm-jp-3.1-8x13b-instruct4": 3 } } } 2. 推論モデルの「思考トークン」で JSON が切れる問題 最初は max_tokens=8000 で Kimi-K2.6 にアイデア5案を JSON で出させていました。ところが finish_reason: "length" で JSON が途中で切れ、アイデアが0件になりました。 レスポンスを調べると、Kimi は message.reasoning に思考過程を出力していて、思考も max_tokens の枠を消費している ことが分かりました。 r = client.chat.completions.create(model="preview/Kimi-K2.6", messages=[...], max_tokens=3000) print(r.choices[0].message.model_dump()["reasoning"][:80]) ' The user is asking for a new business idea for Japan, formatted as a JSON object ...' 同じように preview/Qwen3.6-35B-A3B で max_tokens=300 の短い翻訳を頼むと、content が None(finish_reason=length) で返ってきました。思考だけで枠を使い切ったのだと思います。 対策として、length で止まったら max_tokens を倍にして再試行 するようにしました。 content = (resp.choices[0].message.content or "").strip() finish = resp.choices[0].finish_reason if finish == "length": 推論系モデルは思考にもトークンを使うため、途中切れなら上限を倍にして再試行 max_tokens = min(max_tokens * 2, 32000) elif content: return content あわせて、初期値も「出力に必要な量 + 思考分」を見込んで多めにしています(アイデア生成と MVP 設計は 16,000)。 3. LLM の JSON のエラー対応 工程どうしは JSON でやり取りしています。そのため、壊れた JSON は後続の工程すべてに響きます。実際に次のような出力に遭遇しました。 症状 例 対処 コードフェンス付き 先頭と末尾のフェンスだけを外す 前置きの文章付き 見出し [E1] について: {...} raw_decode で各 { から読み、最も長く読めたものを採用 文字列内の生の改行 "text": "1行目\n2行目" json.loads(strict=False) オブジェクトの開き括弧が抜ける ...},"index":1,...(gpt-oss で1回発生) 再生成 途中で切れた結果、内側の小さなオブジェクトだけがパースされる {"ideas": [... が切れて {} に 期待するキーがあるかを検証し、なければ再生成 特に最後の問題は気づきにくいです。パース自体は成功するので、例外にならずに「アイデア0件」で処理が進んでしまいます。そこで、工程ごとに必須キーを指定するようにしました。 def chat_json(model, system, user, *, expect=None, **kw): """JSON で返すよう指示し、パース失敗(または expect キーが空)なら1回だけ再生成する。""" system += "\n\n出力は有効なJSONのみとし、前置きや説明文、コードフェンスは付けないこと。" for attempt in range(2): text = chat(model, system, user, **kw) try: data = parse_json(text) if expect and not (isinstance(data, dict) and data.get(expect)): raise ValueError(f"キー '{expect}' がありません") return data except (ValueError, json.JSONDecodeError): _dump_failure(model, text) # 生の出力を data/debug/ に保存して後で調べる if attempt == 1: raise 呼び出し側 ideas = chat_json(MODEL_IDEA, ANALYST, prompt, expect="ideas", max_tokens=16000, temperature=0.8) 壊れた出力を data/debug/ に保存しておくと、上の表にある「開き括弧が抜ける」のような珍しい壊れ方も後から確認できます。 4. 一部が失敗してもメールは届ける 翻訳・評価・MVP 設計・サマリーは、失敗してもその欄を空にするだけで処理を続けます。止めるのは、トレンド分析とアイデア生成(これがないとメールの意味がない工程)と、QuotaExceeded が出たときだけです。致命的なエラーのときは、トレースバックをメールで通知します。 for idea in ideas[:config.NUM_MVP]: try: idea["mvp"] = analyzer.design_mvp(idea, idea.get("evaluation", {})) except QuotaExceeded: raise # 枠切れだけは即座に止める except Exception as exc: print(f"MVP設計失敗 ({idea.get('title')}): {exc}") # 欄が空になるだけ 5. その他 重複防止:直近14日分の掲載記事 URL とアイデア名を history.json に保存しています。プロンプトで「次の提案済みアイデアとは重複させない」と伝えているので、毎日同じような案が届くことはありません ソースごとの癖: 36kr の RSS は WAF に弾かれて HTML が返ってくるので、ソースから外しました Hacker News の RSS は、ブラウザを装った User-Agent だと 419 を返し、シンプルな UA なら通ります。両方を順に試すようにしています TechCrunch はページ本文に広告文、中国系メディアは冒頭に「作者｜编辑｜」が入るので、正規表現で取り除いています Gmail API:OAuth の refresh_token を使って、サーバー上でブラウザ操作なしに送信しています(スコープは gmail.send だけ) デプロイ:VPS で、systemd timer に OnCalendar=--* 07:00:00 Asia/Tokyo と Persistent=true を指定しています。VPS が止まっていた日は、起動後に実行されます [Timer] OnCalendar=--* 07:00:00 Asia/Tokyo Persistent=true RandomizedDelaySec=300 動かしてみて分かったこと 1回の実行は5〜8分。推論モデルは1リクエストに数十秒〜1分かかります。バッチなので問題ありませんが、ユーザーとやり取りする用途では、モデル選びの段階でレイテンシを測っておくべきです gpt-oss-120b の分析は筋が良いが、事実を間違えることもある。米国のスタートアップを「中国の」と書いた例がありました。トレンド分析は「着想のきっかけ」と割り切り、元記事へのリンクを必ず付けるようにしています llm-jp は 4K でも十分役に立つ。短い日本語を整える役なら、自然さは一番。ただ JSON ではコードフェンスを付けがちなので、パーサ側で吸収しています モデルを分けると、プロンプトも工程ごとに尖らせられる。「楽観に偏らず現実的に評価する CTO」と「発想を広げる企画担当」を同じモデルの同じ会話でやらせるより、モデルも temperature も分けたほうが、評価が甘くなりにくい まとめ さくらのAI Engine の無償プランは 月3,000リクエストで複数の有力モデルを試せる、とてもコスパの良い環境だと思います ただし 回数だけでなくトークンにも注意 が必要です。超長文はモデルによって入らず、推論モデルは思考の分も max_tokens を使います 呼び出し回数を設計で固定できる バッチ処理 と特に相性が良いです 工程ごとに得意なモデルを割り当てると、小さなマルチエージェント構成を無料で組めます。※ここがおすすめ　最近cognition aiのセミナーに参加したが、そこでもマルチエージェントの話をしており、マルチエージェントはトレンドのように思う。 以前からManusのような「プランナー」「リサーチャー」「コード担当」「評価者」が分業エージェントを作ってみたいと思っていました。それが API キー1つで実現できたのは、正直かなり便利・ナイスな仕組みだと思います。トークン数で言えば、Gemini Flash Liteが最強だと思いますが、さくらAI Engineは、これはこれで良さがあると思うので、用途に応じて、ぜひ試してみてください！ 参考 さくらのAI Engine 公式ページ さくらのAI Engine Inference API 仕様 さくらのAI Engine 操作ガイド さくらのAI Engineで利用できるAIモデルを比較する（2026年9月版） pypinyin / edgartools