1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

OpenAI・Anthropic互換APIを無料で使おう！「さくらのAI Engine」3,000リクエスト使い切りチャレンジ
@ynakayama(Yasuhiro Nakayama)

ai-digest v1.1 をリリースして Anthropic 互換 API と外部入力の扱いを改善した

1
Posted at

ai-digest v1.1 を昨日リリースしました。

v1.1 の中心は、さくらの AI Engine で外部 API、RSS、画像配信元の挙動をアプリケーション側で推測せず、設定、検証、ログ、明示的な処理経路として扱えるようにしたリリースです。

具体的には、Anthropic 互換 API ごとに異なる Thinking とツール選択の挙動を設定可能にし、OpenAI 互換経路を独立したバックエンドとして追加しました。設定ミスは収集処理や API 呼び出しを始める前に拒否し、ツール呼び出しに失敗した場合は停止理由と応答構造をログへ残します。

同時に、外部フィードから入る URL、画像応答、レポート日付の検証も強化しました。v1.1 の変更内容はリポジトリのバージョン履歴にまとめています[1]。

リリース後には、環境変数から変更できるようにした出力上限を 16,000 トークンへ広げ、Kimi-K2.6 で再測定しました。3 件を処理した実行では、入力 675 トークン、出力 3,935 トークンで build_report の呼び出しまで完了しました。

この記事では、まず v1.1 で何を変えたか、その変更をなぜ入れたかを説明します。実測値と月間試算は、変更後の動作確認として後半にまとめます。

v1.1 の変更概要

v1.1 で追加・変更した主な項目は次のとおりです。

分類 変更
設定検証 未知の SUMMARIZER_BACKEND を拒否
Anthropic 互換 API Thinking、ツール選択、JSON テキスト受け入れを設定化
API 経路 OpenAI 互換 Chat Completions バックエンドを追加
出力制御 MAX_OUTPUT_TOKENS を環境変数から読み込む
再試行 ANTHROPIC_MAX_RETRIES を追加
応答検証 build_report だけを受け付け、途中で切れた引数を拒否
ログ 停止理由、ブロック種別、入出力トークン数を INFO へ出力
URL http と https 以外を収集時と描画時に拒否
画像取得 応答を読みながらサイズ上限を適用
パス検証 レポート日付の正規表現を文字列全体へ固定
テスト 設定、URL、パス、画像上限、plain バックエンドを単体試験化
開発方針 doc/POLICY を追加

変更項目は多いですが、設計上の意図は三つに整理できます。

  1. 設定ミスを推測で補正しない
  2. 互換 API の差を設定可能な処理経路として表現する
  3. 外部入力を信頼せず、失敗理由を観測可能にする

設定ミスを別の処理として実行しない

未知の SUMMARIZER_BACKEND を拒否する

ai-digest には、要約処理を選ぶ SUMMARIZER_BACKEND があります。

SUMMARIZER_BACKEND=claude

v1.1 では、次の三つを正式な値として扱います。

値 処理
claude Anthropic または Anthropic 互換 Messages API
openai OpenAI 互換 Chat Completions API
plain 生成 API を使わず機械的に話題を作成

以前は、未知の値が既定の claude と同じ経路へ流れる可能性がありました。

例えば、API を使わない実行を意図して次のように設定した場合です。

SUMMARIZER_BACKEND=palin

plain のタイプミスですが、これを claude として動かすと、実行者は API を使わないつもりなのに、収集結果が生成 API へ送られます。

v1.1 では、未知の値を見つけた時点で終了します。

SUMMARIZER_BACKEND is 'palin'; expected one of: claude, plain, openai.

この変更は、タイプミスを親切に補正するためのものではありません。実行者が指定していないバックエンドをアプリケーションが選ばないための変更です。

API 呼び出し前に設定を検証する

v1.1 では、次の値も収集開始前に検証します[2]。

ANTHROPIC_THINKING_MODE
ANTHROPIC_TOOL_CHOICE_MODE
ANTHROPIC_TEXT_JSON_FALLBACK
ANTHROPIC_MAX_RETRIES
MAX_OUTPUT_TOKENS
OPENAI_API_KEY
OPENAI_MODEL

例えば、出力上限が 0 以下なら次のエラーで停止します。

MAX_OUTPUT_TOKENS is 0; expected a positive number.

論文やニュースを収集した後で API に拒否されるのではなく、外部アクセスを始める前に設定不備を確定させます。

設定は処理を形作る入力です。値が不明なまま実行を続けると、障害の発生位置が設定読込から API 応答まで後退し、原因の切り分けも難しくなります。

Anthropic 互換 API の差を設定として扱う

HTTP 200 でも必要な応答が返るとは限らない

ai-digest は、生成モデルへ自由文を要求していません。build_report というツールの入力として、次の構造を返すように要求します。

topics
  ├─ category
  ├─ title
  ├─ bullets
  └─ source_indexes

さくらの AI Engine へ接続する手順は、先の記事で整理しました[3]。

その後の実行では、Messages API が HTTP 200 を返したものの、応答は thinking ブロックだけでした。モデルは出力上限の 4,000 トークンを Thinking に使い切り、build_report の tool_use へ到達していませんでした。

stop_reason=max_tokens
content_types=thinking
input_tokens=5708
output_tokens=4000

API 形式が Anthropic 互換でも、モデルが Anthropic と同じ Thinking、ツール強制、停止動作を示すとは限りません。

v1.1 では、この差を一つの例外処理で吸収せず、リクエストを構成する設定へ分解しました。

ANTHROPIC_THINKING_MODE

Thinking の扱いを次の二つから選べます。

値 動作
default thinking パラメーターを追加せず、接続先の既定動作を使う
disabled thinking.type=disabled を追加する

disabled の場合は、Anthropic SDK の extra_body を使います。

request["extra_body"] = {
    "thinking": {
        "type": "disabled",
    },
}

構造化された日次レポートだけが必要なら、長い Thinking は成果物ではありません。Thinking が出力枠を消費してツール呼び出しを妨げる接続先では、無効化を明示できます。

一方、接続先がこの追加パラメーターを受け付けない場合もあります。そのため、モデル名を見て自動的に追加するのではなく、設定した場合だけ送ります。

ANTHROPIC_TOOL_CHOICE_MODE

ツール選択は次の三つから選べます。

値 API へ送る値 意図
forced 名前付きの build_report Anthropic と同じ強制指定
any 名前を指定せずツール使用を要求 名前付き指定だけを無視する接続先への対応
auto モデルへ選択させる 強制指定を受け付けない接続先への対応

forced は次の形式です。

{
    "type": "tool",
    "name": "build_report",
}

any はツール名を送りません。

{
    "type": "any",
}

ai-digest が提示するツールは build_report 一つだけなので、ツール使用が守られれば結果は同じです。

auto は次の形式です。

{
    "type": "auto",
    "disable_parallel_tool_use": True,
}

auto ではモデルが通常テキストを選ぶ可能性があります。そのため、システムプロンプトにも次の指示を追加しました[4]。

通常の回答文や思考過程を出力せず、必ず build_report ツールを呼び出してください。

ここでも接続先をモデル名から推測しません。forced、any、auto を明示的に選び、ログで結果を確認します。

ANTHROPIC_TEXT_JSON_FALLBACK

互換 API によっては、ツール呼び出しではなく、ツール引数に相当する JSON を通常テキストとして返します。

v1.1 では、次の設定を追加しました。

ANTHROPIC_TEXT_JSON_FALLBACK=enabled

ただし、既定値は disabled です。

有効にした場合も、任意の文章をレポートとして扱いません。次の条件をすべて満たす場合だけ採用します。

  • 応答がテキストブロックである
  • JSON オブジェクトとして解析できる
  • topics がリストである
  • 採用したことを警告ログへ出す

自由文から都合のよい部分を抽出する処理は追加していません。構造を満たす JSON だけを、明示的に許可した場合だけ受け付けます。

OpenAI 互換 API を別バックエンドとして追加した

さくらの AI Engine は、Anthropic 互換 Messages API と OpenAI 互換 API の両方を提供しています。

v1.1 では、次のバックエンドを追加しました。

SUMMARIZER_BACKEND=openai

設定例は次です。

SUMMARIZER_BACKEND=openai
OPENAI_API_KEY=<UUID>:<シークレット>
OPENAI_BASE_URL=https://api.ai.sakura.ad.jp/v1
OPENAI_MODEL=preview/Kimi-K2.6

OpenAI 互換経路は、Anthropic 互換経路が失敗したときに自動で選ばれるフォールバックではありません。実行者が明示的に選ぶ独立した経路です。

自動切り替えにすると、一回のバッチ内で次の状態が見えにくくなります。

Anthropic 互換 API が何回呼ばれたか
OpenAI 互換 API が何回呼ばれたか
どちらの応答からレポートが生成されたか
どちらの利用量が計上されたか

明示的なバックエンドにすることで、一回の実行と一つの API 経路を対応付けます。

OpenAI 互換バックエンドでは、Anthropic 用のツール定義を function tool 形式へ変換し、tool_calls[].function.arguments を読み取ります[5]。

解析後は Anthropic 経路と同じ to_topics() に渡します。

Anthropic 互換 tool_use.input ─┐
                               ├─ to_topics() ─ レポート
OpenAI 互換 function.arguments ┘

通信形式が違っても、出典番号、箇条書き、話題の検証条件は共通です。

openai パッケージは標準の requirements.txt へ追加していません。OpenAI 互換バックエンドを選んだ環境だけでインストールします。

python -m pip install openai

既定の Anthropic 経路や plain 経路へ、使わない API クライアントを追加しないためです。

出力上限を環境変数から変更できるようにした

.env に書いても使われていなかった

以前の出力上限は、summarizer.py の定数でした。

MAX_OUTPUT_TOKENS = 4000

エラーメッセージでは MAX_OUTPUT_TOKENS を増やすよう案内していましたが、設定ファイルから値を読む処理がありませんでした。

次の行を .env に追加しても、API へ送る値は 4,000 のままでした。

MAX_OUTPUT_TOKENS=16000

設定が読み捨てられても警告が出ないため、実行者から見ると「出力上限を増やしたのに結果が変わらない」状態になります。

v1.1 では、Config.max_output_tokens へ値を読み込み、Anthropic 互換と OpenAI 互換の両方へ渡します。

request = {
    "model": model,
    "max_tokens": max_output_tokens,
    ...
}

既定値は 4,000 のままです。

MAX_OUTPUT_TOKENS=4000

接続先や測定目的に応じて変更でき、0 以下なら実行前に拒否します。

上限を増やすこと自体を解決策にしない

Thinking が有効なモデルでは、出力上限は最終 JSON だけでなく Thinking にも使われます。

そのため、上限を 4,000 から 16,000 へ増やしても、モデルが 16,000 トークン考え続ければ build_report は返りません。

v1.1 では、次を別の設定として扱います。

Thinking を無効にするか
ツールをどう選ばせるか
出力上限をいくつにするか

これらを一つの調整値へまとめないことで、「Thinking を止めるべき状態」と「完成したツール引数を収めるために上限を増やす状態」を区別できます。

再試行回数を設定可能にした

Anthropic Python SDK は、一部の通信エラーや HTTP エラーを自動的に再試行します。

通常運用では有用ですが、API 設定を比較する場合は、一回の cli.py run が何リクエストを消費したか分からなくなることがあります。

v1.1 では次を追加しました。

ANTHROPIC_MAX_RETRIES=0
値 用途
2 SDK の既定動作
0 一回の試行を一リクエストに固定

調査コードへ max_retries=0 を直接書かず、運用設定として切り替えられます。

未知の値や負の値は、API 呼び出し前に拒否します。

API 応答を原因別に診断できるようにした

tool_use がないという一文だけでは足りない

以前は、ツール呼び出しがなければ次のエラーでした。

Claude did not return a build_report tool call.

この表示では、次の状態を区別できません。

Thinking の途中で上限へ到達した
通常テキストを返して終了した
別のツールを呼び出した
build_report の引数が途中で切れた
JSON 引数が壊れていた

v1.1 では、API 応答ごとに次を INFO ログへ出します。

id
model
stop_reason
content_types
input_tokens
output_tokens

表示例は次です。

api response: id=chatcmpl-...
model=preview/Kimi-K2.6
stop_reason=tool_use
content_types=thinking,tool_use
input_tokens=675
output_tokens=3935

応答全文は DEBUG ログだけへ出します。

python cli.py run --verbose

INFO ログへ Thinking 全文を出すと、毎日の cron ログへ数千トークンが追加されます。通常時には応答の形と使用量だけを残し、内容が必要な調査時だけ全文を確認します。

build_report だけを受け付ける

以前の実装は、最初に見つけた tool_use を採用していました。

v1.1 では、名前が build_report のブロックだけを読み取ります。

if (
    getattr(block, "type", "") == "tool_use"
    and getattr(block, "name", "") == "build_report"
):
    ...

モデルが別のツール名を返した場合、その引数をレポートとして扱いません。

途中で切れたレポートを公開しない

tool_use ブロックがあっても、stop_reason=max_tokens なら、引数が途中で切れている可能性があります。

v1.1 では、この状態を部分的なレポートとして通しません。

Model hit max_tokens while writing the build_report arguments,
so the report is truncated; lower MAX_TOPICS or raise MAX_OUTPUT_TOKENS.

JSON 文字列が解析できない場合も、単なる「利用可能な話題がない」という結果へ変換せず、引数が不正であることを明示します。

失敗を空の正常結果へ近づけないことが、この変更の意図です。

外部フィードと画像取得を防御的にした

v1.1 は生成 API の互換性対応だけではありません。RSS、Atom、記事ページ、画像配信元を扱う処理も更新しています。

http と https 以外の URL を拒否する

フィードに含まれる URL は、最終的に HTML のリンクとして表示されます。

HTML の自動エスケープは、タグの構文を壊す文字を無害化します。しかし、次のような URL は、文字列としては正しい href です。

javascript:...
data:...

自動エスケープだけでは、クリック時の動作を防げません。

v1.1 では、絶対 URL の http と https だけを受け付けます。

SAFE_URL_SCHEMES = ("http", "https")

検査は二段階で行います。

  1. 収集時に不正な URL を破棄する
  2. 保存済みレポートを描画するときにも再検査する

過去のバージョンで保存されたデータや手動編集された JSON もあるため、収集時の検査だけには依存しません。描画時に不正な URL を # へ置き換えます。

画像を全件読み込んでからサイズを測らない

以前は、画像の HTTP 応答全体をメモリーへ読み込んだ後でサイズを確認していました。

HTTP 応答を全件取得
    ↓
バイト数を測定
    ↓
上限超過なら破棄

この順序では、巨大なファイルや終了しない応答に対して、上限が防御になりません。

v1.1 では stream=True で取得し、チャンク単位で上限を確認します。

for chunk in response.iter_content(chunk_size=CHUNK_BYTES):
    total += len(chunk)
    if total > limit:
        return None

上限は次のとおりです。

対象 上限
画像 8 MiB
画像 URL を探す HTML 4 MiB
読取単位 64 KiB

上限を超えた応答は途中までのデータを利用せず、ローカル生成画像へフォールバックします。

日付の正規表現を文字列全体へ固定する

レポート日付の検証では、末尾に $ を使っていました。

Python の $ は文字列末尾だけでなく、末尾の改行直前にも一致します。そのため、次の値が検証を通る可能性がありました。

2026-08-02\n

v1.1 では \A と \Z を使用し、文字列全体を日付形式へ固定しました。

\A[0-9]{4}-[0-9]{2}-[0-9]{2}\Z

この問題はパス検証の単体テストを追加したことで見つかりました。

変更を単体テストへ落とし込んだ

v1.1 では、次の領域へテストを追加しました。

設定値の読込と拒否
レポート日付と保存パス
URL スキームの検証
画像応答のサイズ上限
plain バックエンド
Anthropic 互換リクエストの組立
OpenAI 互換ツール引数の解析
出力上限の伝播

今回追加した処理は、特定の API 応答を一度通せば完了する修正ではありません。

例えば、次の条件は将来の変更でも維持する必要があります。

未知のバックエンドで API を呼ばない
不正 URL を HTML へ出さない
上限超過の画像を全件読み込まない
途中で切れたツール引数を公開しない
設定した MAX_OUTPUT_TOKENS を実際のリクエストへ渡す

手順書だけでなくテストへ置くことで、後の機能追加が安全条件を壊した場合に検出できます。

doc/POLICY を追加した

v1.1 では、実装方針を doc/POLICY にまとめました。

対象は単なるコーディングスタイルではありません。

対応 Python バージョン
モジュール構成
設定値の扱い
エラー時の停止方針
外部入力の検証
ログの粒度
テストの配置
バージョン履歴

今回の変更では、「不明な値を既定値へ戻すか」「外部 API の差を自動判定するか」「失敗時に別バックエンドへ切り替えるか」といった判断が複数箇所に現れました。

方針を文書化することで、個別の修正ごとに判断基準が変わらないようにしています。

v1.1 へ更新した設定例

Anthropic 互換 Messages API を使う基本設定は次です。

ANTHROPIC_API_KEY=
ANTHROPIC_AUTH_TOKEN=<UUID>:<シークレット>
ANTHROPIC_BASE_URL=https://api.ai.sakura.ad.jp
ANTHROPIC_MODEL=preview/Kimi-K2.6

ANTHROPIC_THINKING_MODE=default
ANTHROPIC_TOOL_CHOICE_MODE=auto
ANTHROPIC_TEXT_JSON_FALLBACK=disabled
ANTHROPIC_MAX_RETRIES=0

MAX_OUTPUT_TOKENS=16000
SUMMARIZER_BACKEND=claude

この設定は、今回の再測定に使った条件です。

Thinking を含めた実使用量を測るため、ANTHROPIC_THINKING_MODE は default にしています。日常運用で Thinking が不要なら、次へ変更できます。

ANTHROPIC_THINKING_MODE=disabled

測定と運用では目的が異なるため、同じ設定を必須にはしていません。

変更後に出力上限を広げて再測定した

ここからは、v1.1 の変更後に行った確認です。

最初の測定結果と条件は、既存の記事にまとめています[6]。

最初の実行では、アプリケーション側の上限と実出力がどちらも 4,000 でした。

stop_reason=max_tokens
content_types=thinking
input_tokens=5708
output_tokens=4000

この結果だけでは、実際に何トークンあれば build_report まで到達するか分かりません。

v1.1 で MAX_OUTPUT_TOKENS を環境変数として使えるようにしたため、次へ変更しました。

MAX_OUTPUT_TOKENS=16000

実行コマンドは次です。

LOOKBACK_HOURS=72 python cli.py run --verbose

この実行では、3 件のニュースを収集しました。

collected 0 arXiv papers
collected 3 news articles
deduplicated 3 entries into 3

API リクエストには、設定した 16,000 が渡されています。

'max_tokens': 16000
'model': 'preview/Kimi-K2.6'
'tool_choice': {
    'type': 'auto',
    'disable_parallel_tool_use': True
}

応答の要約ログは次です。

api response:
id=chatcmpl-b0492ee5ac6b3000
model=preview/Kimi-K2.6
stop_reason=tool_use
content_types=thinking,tool_use
input_tokens=675
output_tokens=3935

3 件から 3 トピックが生成され、レポート保存まで完了しました。

summarized 3 entries into 3 topics
report for 2026-08-03 written to data/reports/2026-08-03

結果を整理すると次のとおりです。

項目 値
入力件数 3 件
入力トークン 675
出力上限 16,000
実出力 3,935
応答ブロック thinking,tool_use
終了理由 tool_use
生成トピック 3 件
API リクエスト 1 回
レポート生成 完了

3,935 は Thinking と build_report のツール引数を合わせた実出力です。個別の内訳は API 応答にありません。

今回の入力では、4,000 トークンでも計算上は 65 トークン余ります。

4000 - 3935 = 65

余裕は約 1.63% しかありません。入力内容やモデルの判断過程が少し変われば上限へ到達します。実際、34 件を入力した実行では 4,000 トークンを Thinking だけで使い切りました。

出力上限 4,000 が常に不足するわけではありません。しかし、Thinking を出力するモデルに対して、レポート JSON の大きさだけを根拠に固定値を決めることもできません。

6 件を平日に毎日処理した場合の試算

月間試算では、3 件を処理した今回の実測値を基礎にします。

項目 3 件の実測
入力トークン 675
出力トークン 3,935
合計トークン 4,610
リクエスト 1 回

毎回 6 件を処理する条件は、件数に比例すると仮定して 2 倍にします。

項目 6 件の 1 回あたり試算
入力トークン 1,350
出力トークン 7,870
合計トークン 9,220
リクエスト 1 回

平日に 1 日 1 回、月 22 回実行すると次の値になります。

項目 月間試算
実行回数 22 回
処理件数 132 件
入力トークン 29,700
出力トークン 173,140
合計トークン 202,840
リクエスト 22 回

Kimi-K2.6 の単価は、入力が 10,000 トークンあたり 0.6 円、出力が 10,000 トークンあたり 3 円です。基盤モデル無償プランでは、対象モデルを月 3,000 リクエストまで利用できます[7]。

入力分は次です。

29,700 ÷ 10,000 × 0.6 円
= 1.782 円

出力分は次です。

173,140 ÷ 10,000 × 3 円
= 51.942 円

合計は次です。

1.782 円 + 51.942 円
= 53.724 円

従量課金単価へ換算した月額は約 53.72 円です。

項目 1 回 月 22 回
入力換算 0.081 円 1.782 円
出力換算 2.361 円 51.942 円
合計 2.442 円 53.724 円

無償枠に対するリクエスト使用率は次です。

22 ÷ 3000 × 100
= 約 0.73%

基盤モデル無償プランの範囲内なので、実際の請求額は 0 円です。約 53.72 円は、同じ利用量を従量課金単価へ当てはめた参考値です。

モデル別のリクエスト数とトークン数は、さくらの AI Engine コントロールパネルの 利用量 > モデル で確認できます[8]。

6 件処理のトークン数は、3 件の実測値を単純に 2 倍した試算です。入力トークンは件数とおおむね連動しますが、Thinking の長さは厳密には比例しません。

そのため、値の扱いは次のとおりです。

値 種別
入力 675、出力 3,935 3 件処理の実測
入力 1,350、出力 7,870 6 件処理の比例試算
月 53.72 円 22 回を従量課金単価へ換算した参考額
月 22 リクエスト 運用条件から直接決まる値

v1.1 で変えたのは、失敗を判断できる形にしたことである

v1.1 では、接続先が期待どおりに動かないとき、単に「互換 API が使えなかった」とは扱いません。

次の状態を分けて記録し、それぞれに対応する設定を持たせました。

状態 確認・変更する項目
Thinking で上限到達 ANTHROPIC_THINKING_MODE、MAX_OUTPUT_TOKENS
ツール引数の途中で上限到達 MAX_TOPICS、MAX_OUTPUT_TOKENS
名前付きツールが無視される ANTHROPIC_TOOL_CHOICE_MODE=any
ツール強制が使えない ANTHROPIC_TOOL_CHOICE_MODE=auto
JSON テキストだけが返る ANTHROPIC_TEXT_JSON_FALLBACK
Anthropic 経路で成立しない SUMMARIZER_BACKEND=openai
リクエスト数を固定して比較する ANTHROPIC_MAX_RETRIES=0
不明な設定値 API 呼び出し前に停止

外部 API の挙動をコードが推測して自動補正するのではなく、実行者が設定を選び、ログで結果を確認できる構造にしています。

同じ方針で、外部フィードの URL、画像サイズ、レポート日付も、受け入れ可能な境界をコードとテストで定義しました。

ai-digest の収集、重複排除、構造化要約、出典保持、画像生成、閲覧処理の分離については、設計時の記事で説明しています[9]。

まとめ

ai-digest v1.1 をリリースしました。

このリリースでは、Anthropic 互換 API の挙動差を、Thinking、ツール選択、JSON テキスト、再試行、出力上限という独立した設定へ分解しました。OpenAI 互換経路も、自動フォールバックではなく明示的なバックエンドとして追加しています。

設定値が不明な場合は既定値へ戻さず、外部アクセスを始める前に停止します。API 応答からは停止理由、ブロック種別、トークン数を記録し、途中で切れたツール引数や別名のツール呼び出しをレポートとして受け付けません。

外部フィードについても、URL スキーム、画像応答のサイズ、レポート日付を検証し、その条件を単体テストへ落とし込みました。

リリース後の確認では、MAX_OUTPUT_TOKENS=16000 を実際のリクエストへ反映し、3 件の入力に対して 675 入力トークン、3,935 出力トークンで build_report の呼び出しとレポート生成が完了しました。

この実測値を毎回 6 件へ比例換算し、平日に 1 日 1 回、月 22 回動かす条件では、従量課金換算で月約 53.72 円です。リクエスト数は月 22 回で、3,000 回の無償枠の約 0.73% となります。

実測値は v1.1 の変更後に成立したことを確認する材料です。v1.1 の主目的は、特定の一回を成功させることではなく、接続先と外部入力の差を推測せず、安全に設定し、失敗時にも原因を判断できるようにすることです。

参考文献

  1. id774, ai-digest Repository Version History（2026-08-02）. https://github.com/id774/ai-digest/blob/master/doc/VERSIONS
  2. id774, config.py（2026-08-02）. https://github.com/id774/ai-digest/blob/master/config.py
  3. id774, さくらの AI Engine の Anthropic 互換 API で ai-digest を動かす（2026-07-31）. https://qiita.com/ynakayama/items/d486fc70c8a29f5f765c
  4. id774, ai_digest/analyzer/summarizer.py（2026-08-02）. https://github.com/id774/ai-digest/blob/master/ai_digest/analyzer/summarizer.py
  5. id774, ai_digest/analyzer/openai_compat.py（2026-08-02）. https://github.com/id774/ai-digest/blob/master/ai_digest/analyzer/openai_compat.py
  6. id774, ai-digest でさくらの AI Engine の利用量を実測する（2026-08-02）. https://qiita.com/ynakayama/items/112f03b45ec2f15f37a8
  7. さくらインターネット, さくらの AI Engine（2026-08-03 閲覧）. https://ai.sakura.ad.jp/sakura-ai/ai-engine/
  8. さくらインターネット, さくらの AI Engine コントロールパネル「モデルの利用量」（2026-08-03 閲覧）. https://secure.sakura.ad.jp/ai/usages/model
  9. id774, AI 論文とニュースを日次でまとめる ai-digest を作った（2026-07-31）. https://blog.id774.net/entry/2026/07/31/5164/
1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?