出力0トークン判定APIの仕組みと偽スキーマの罠

米国時間 2026 年 11 月 11 日、Google 公式ブログ（The Keyword）の発表 によって、これまでの「文章を 1 文字ずつ紡ぎ出す生成 AI」とは根本的に設計思想が異なる新しいエンドポイント 『Gemini Decisions API』 と専用モデル 『Gemini Decision 1（gemini-decision-1）』 が公開されました。

自己回帰JSON出力を捨てる単一順伝播の革新

従来の生成 AI（自己回帰型 LLM）に「このメールはスパムですか？カテゴリと重要度を JSON で返してください」と頼むと、モデルは {、"、i、s、_、s、p、a、m……と 1 トークンずつ順番に次の文字を予測するループ計算 を何十回も回していました。業務システムが本当に欲しいのは true か false かの判定値だけなのに、括弧やキー名の文字列を作らせるために高い出力トークン料金と待ち時間を払っていたわけです。

これに対し、Google AI Studio 公式の Decisions API ドキュメント で仕様が公開されている『Gemini Decision 1』は、テキスト生成ループを丸ごと廃止し、たった 1 回の順伝播（Single Forward Pass）から校正済み確率（Calibrated Probabilities）を直接返す構造 を採っています。

従来の生成AIによるJSON分類 vs Gemini Decision 1（Decisions API）

自己回帰デコード

従来の生成AI（generateContent）

質問ごとに { "category": "...", "reason": "..." } と 1 トークンずつ文字列を生成。質問数が増えるほど出力トークン代と待ち時間が膨らみ、確率値にもモデル特有の偏りが残ります。

単一順伝播・出力0tok

Gemini Decision 1（decisions）

1 回の前向き計算だけで複数質問の確率・確信度を同時算出。Gemini API 公式料金表 でも 入力 100 万トークン 0.10 米ドル・出力トークン常時 0（無料） で高速応答します。

質問の型（Question Types）は以下の 3 種類に厳選されており、1 回のリクエストのなかに何問でも自由に混ぜて同時採点させることができます。

• noul（二値確率判定） ：Yes / No で答えられる質問に対し、0.01〜0.99 の校正済み確率と確信度（confidence）を返します。

• choice（多肢選択分類） ：指定した選択肢（カテゴリ辞書または配列）ごとの確率分布と、最も確率が高い選択肢を返します。

• score（順序尺度スコア） ：0・1・2 などの段階基準（legend）に対する各確率を計算し、その重み付き期待値として 1.84 や 0.63 のような連続値スコアを返します。

外部解説記事の偽スキーマで踏んだ400エラー

発表当日、さっそく当ラボの Mac から Pure Rust 経由で API を叩こうとした際、最初にとても示唆に富むトラブルに遭遇しました。

検索で見つかった外部の速報解説ブログに載っていたサンプル JSON を参考にリクエストを組んで投げたところ、Google のサーバーから即座に HTTP 400 Bad Request（"The 'type' parameter is required at 'input[0]'."） というエラーで弾かれたのです。

原因を公式原典と突き合わせて調べたところ、一部の二次解説記事は実機で API を叩かずに書かれており、従来の generateContent API の書き方（"role": "USER" や "parts": [{"inline_data": ...}]、レスポンスの "usageMetadata"）を推測で混ぜた 「実動しないハルシネーション混じりの偽スキーマ」 を掲載していました。新しい技術を検証するときほど、二次まとめ記事を鵜呑みにせず一次ドキュメントと実機レスポンスで裏付け（エビデンス）を取る大切さを痛感します。

当ラボの iMac で HTTP 200 疎通を確認した、100% 本物のマルチモーダル・リクエスト＆レスポンス形式 は以下の通りです。

// リクエスト例: POST https://generativelanguage.googleapis.com/v1beta/decisions
// ヘッダー: x-goog-api-key: <API_KEY>, Content-Type: application/json
{
  "model": "gemini-decision-1",
  "input": [
    { "type": "text", "text": "ブログ記事へ掲載する前の画像検品を行ってください。" },
    {
      "type": "image",
      "data": "<BASE64エンコードしたWebP画像データ>",
      "mime_type": "image/webp",
      "resolution": "high"
    }
  ],
  "questions": {
    "has_personal_info": {
      "type": "noul",
      "question": "宛名ラベル・氏名・住所・電話番号などの個人情報が写り込んでいますか？"
    },
    "image_kind": {
      "type": "choice",
      "question": "この画像の種類として最も適切なものはどれですか？",
      "criteria": {
        "ai_eyecatch": "AIで生成された文字なしのイラスト・アイキャッチ画像",
        "ui_screenshot": "PCやスマートフォンの設定画面・アプリのスクリーンショット",
        "gadget_photo": "カメラで実物を撮影したガジェット・日用品の写真",
        "other": "上記いずれにも当てはまらないその他の画像"
      }
    },
    "dark_theme_clarity": {
      "type": "score",
      "question": "ダークモード（黒背景）の記事内に配置した際の被写体・UIの視認性はどうですか？",
      "legend": {
        "0": "黒背景と同化して輪郭が潰れており視認性に問題がある",
        "1": "判別はできるがやや暗くコントラストが弱い",
        "2": "輪郭・明るさともに明瞭でダーク背景でもはっきり視認できる"
      }
    }
  }
}

// 実機から返ってきた本物のレスポンス構造（抜粋）
{
  "answers": {
    "has_personal_info": {
      "type": "noul",
      "noul": 0.086,
      "confidence": 0.914
    },
    "image_kind": {
      "type": "choice",
      "choice": "ai_eyecatch",
      "probabilities": {
        "ai_eyecatch": 0.960,
        "gadget_photo": 0.015,
        "other": 0.013,
        "ui_screenshot": 0.012
      },
      "confidence": 0.960
    },
    "dark_theme_clarity": {
      "type": "score",
      "score": 1.49,
      "confidence": 0.745
    }
  },
  "usage": {
    "total_tokens": 1510,
    "total_input_tokens": 1510,
    "input_tokens_by_modality": [
      { "modality": "text", "tokens": 410 },
      { "modality": "image", "tokens": 1100 }
    ],
    "total_output_tokens": 0
  }
}

ご覧の通り、usage.total_output_tokens が本当に 0 で返ってきます。4 問まとめて質問しても出力トークンは一切増えず、テキスト 410 トークン＋画像 1,100 トークンの入力分だけで全項目の確率値が手に入ります。

公開前WebP画像の検品と解像度4段階の実測

まず第 1 の実戦テストとして、当サイトで実際に公開している性格の異なる 4 種類の .webp 画像 をそのまま Gemini Decision 1（resolution: "high"）へ投入し、公開前検品で毎回確認したい 4 項目（画像種別・個人情報写り込み・文字混入の有無・ダーク背景での視認性）を 1 パスで採点させました。

ブログ画像4種を1パスで採点した写り込み検品

当サイトではアイキャッチ画像の生成時に「文字刻印の混入ゼロ」をルール化し、実写レビュー写真では「郵便物やシリアル番号の写り込みゼロ」を徹底しています。Pure Rust のプログラムだけでは画像ファイルの中身に文字が写っているかどうかまでは判定できませんが、Gemini Decision 1 を通した結果は以下の通り驚くほど的確でした。

検証した実機 WebP 画像（ファイル容量）	E2E 応答時間 （Google 処理）	入力トークン （出力は全て 0）	画像種別判定 （確信度）	個人情報確率 （has_personal_info）	文字混入確率 （has_visible_text）	ダーク視認性 （0〜2 点満点）
① 文字なし AI アイキャッチ （監査記事アイキャッチ / 66.4KB）	875.1ms （dur=667ms）	1,510 tok	ai_eyecatch （96.0%）	8.6% （安全）	26.3% （文字なし判定）	1.49 / 2.0 （良好）
② ダーク UI スクリーンショット （Ultra 20x 制限パネル / 15.6KB）	681.0ms （dur=659ms）	1,491 tok	ui_screenshot （98.5%）	9.7% （安全）	91.0% （UI 文字を検知）	0.63 / 2.0 （暗背景同化警告）
③ HARIO 実写マグ単体・文字なし （香りマグ実機写真 / 223.8KB）	767.3ms （dur=746ms）	1,510 tok	gadget_photo （86.4%）	8.4% （安全）	31.7% （文字なし判定）	1.61 / 2.0 （明瞭）
④ HARIO 実写・外箱の仕様文字あり （製品パッケージ裏面 / 143.1KB）	760.6ms （dur=739ms）	1,510 tok	gadget_photo （96.6%）	11.2% （安全）	90.9% （箱の文字を検知）	1.58 / 2.0 （明瞭）

とくに注目したいのが、同じ HARIO 製品の実写写真である ③（ガラスマグ本体のみ）と④（外箱の品質表示ラベル）の対比 です。マグ本体だけの写真では文字混入確率が 31.7% と低く抑えられたのに対し、外箱の細かい日本語仕様表記が写った写真では 90.9% へと一気に跳ね上がりました。さらに②の小さな黒背景 UI パネルに対しては、ダークテーマ視認性スコアを 0.63 / 2.0 と厳しく採点し、「黒背景の記事にそのまま貼ると境界が沈んで見えにくい」というリスクまで 0.7 秒弱で見抜いています。

解像度4段階でちょうど2倍ずつ増えるトークン量

続いて、同じ 1 枚の WebP 画像に対して resolution パラメータを "low"・"medium"・"high"・"ultra_high" の 4 段階に切り替えたとき、画像の入力トークン数と応答速度がどう変化するかを実測しました。

同一WebP画像における resolution 4段階の画像トークン数と処理時間

解像度を1段階上げるごとに画像トークン数がきっちり約2倍（264→527→1,100→2,205）へ比例スケール

最軽量 (low):画像 264 tok標準検品 (high):画像 1,100 tok出力トークン:全段階 0 tok

low（全体構図・画像種別のざっくり判定向き）合計358 tok / E2E 481.1ms (dur=461ms) / 推論試算 約0.0056円

264 tok最安

medium（一般的なサムネイル・視認性チェック向き）合計621 tok / E2E 503.6ms (dur=484ms) / 推論試算 約0.0096円

527 tok約2倍

high（AIアイキャッチ文字混入・通常写真の検品に最適）合計1,194 tok / E2E 398.5ms (dur=379ms) / 推論試算 約0.018円

1,100 tok推奨基準

ultra_high（封筒の小さな宛名や製造番号の厳密検品向き）合計2,299 tok / E2E 844.3ms (dur=821ms) / 推論試算 約0.036円

2,205 tok精密検査

resolution 設定	画像トークン数	テキスト込み合計入力	E2E 応答時間（サーバー処理）	1 枚あたり料金目安（推論試算）	適した実運用シーン
low	264 tok	358 tok	481.1ms（461ms）	約 0.000036米ドル（約 0.0056円）	写真かイラストかの分類、極端な白飛び・黒潰れ確認
medium	527 tok	621 tok	503.6ms（484ms）	約 0.000062米ドル（約 0.0096円）	大きめのロゴ混入チェック、SNS カードの視認性確認
high	1,100 tok	1,194 tok	398.5ms（379ms）	約 0.000119米ドル（約 0.018円）	公開前アイキャッチの文字刻印検査・通常の写真検品
ultra_high	2,205 tok	2,299 tok	844.3ms（821ms）	約 0.000230米ドル（約 0.036円）	背景の書類・配送伝票・細かいシリアル番号の写り込み検査

解像度を 1 段階上げるごとに、画像トークン数が 264 ➔ 527 ➔ 1,100 ➔ 2,205 ときれいに 2 倍ずつ増える明快な料金体系になっています。しかも高精細な "high" でさえ、推論に基づく試算（1 米ドル＝155 円換算）で 1 枚あたり約 0.018 円（100 枚検品しても約 1.8 円） という安さです。普段のアイキャッチ検品は "high"、自宅デスク周りの実写写真だけは個人情報保護のために "ultra_high" といった使い分けが懐を痛めずに回せます。

朝夕RSS自動収集の盲点と15問並列トリアージ

第 2 の実戦テストは、当ラボで毎日朝夕に自動実行している一次情報収集パイプライン（詳細は API自動収集と記事作成の5世代進化実測 参照）への組み込み検証です。実は今回、この検証を始めるきっかけになった「恥ずかしい盲点」がありました。

肝心のGoogle公式RSSが抜けていた灯台下暗し

そこで直ちに Google 本家の公式フィードを調査し、すべて HTTP 200 で正常稼働し一次発表が最速で配信される以下の 4 つの公式 RSS フィード を自動収集リストへ追加しました。

1. Google AI 全般（The Keyword） ：https://blog.google/innovation-and-ai/rss/

2. Google Developers Tools（The Keyword） ：https://blog.google/innovation-and-ai/technology/developers-tools/rss/

3. Google for Developers 公式ブログ ：https://developers.googleblog.com/rss/

4. Google DeepMind 公式ブログ ：https://deepmind.google/blog/rss.xml

ところが、国内外のフィードを幅広く追加すると、今度は 「週末の激安セール広告や星占い、単なるイベント告知などのノイズ記事まで大量に混ざり込み、本編の執筆 AI に読ませるトークンが無駄になる」 という新たな課題が生まれます。こここそが『Gemini Decision 1』の独壇場でした。

新着5件15問を430ミリ秒で仕分けた実測結果

新着記事 5 本分のタイトルと要約を 1 つのテキストにまとめ、各記事に対して「①広告・ノイズか（noul）」「②当サイトのどの領域に向くか（choice）」「③一次検証・深掘り価値スコア（score 0〜2）」の 3 問ずつ、合計 15 問を 1 回のリクエストに束ねて 投げてみました。

結果は E2E 応答時間わずか 430.3ms（Google サーバー処理 dur=411ms）、入力 1,788 トークン・出力 0 トークン で、15 問すべての回答が一瞬で返ってきました。1 リクエストあたりの費用は、推論に基づく試算で 約 0.00018米ドル（約 0.028 円） です。

投入した新着 RSS 候補（5 件同時）	ノイズ・宣伝確率 （is_noise）	振り分け先カテゴリ （確信度）	深掘り重要度 （0〜2 点満点）	自動トリアージ結果
① Gemini Decisions API 公式発表	1.9%	review_lab（96.0%）	1.94 / 2.0	検証録へ最優先採用
② 激安 PC スリーブ週末タイムセール広告	98.2%	other_skip（99.6%）	0.07 / 2.0	広告ノイズとして即除外
③ 会計検査院による省庁クラウド遊休指摘	2.3%	ai_nation_governance（98.2%）	1.83 / 2.0	統治・制度編へ採用
④ Rust × Lean 4 カーネル形式検証論文	2.8%	ai_nation_tech（98.9%）	1.84 / 2.0	技術ラボ編へ採用
⑤ 今週の IT エンジニア星座ランキング	96.3%	other_skip（99.4%）	0.05 / 2.0	無関係記事として即除外

セール広告（ノイズ確率 98.2%）と星占い（96.3%）をほぼ 100% に近い確信度で即座にゴミ箱へ弾きつつ、残る 3 件を「検証録」「AI国家・統治編」「AI国家・技術編」へ 96%〜98.9% の高精度で仕分けています。朝夕 1 日 2 回この門番を回しても、1 ヶ月あたりの API 費用は推論試算で 2 円未満 に収まります。

ハルシネーション検知の限界とCarbon必須の証明

さて、ここからが本検証でもっとも重要な核心パートです。これほど速くて賢い確率判定ができるなら、「高価で重い推論モデル『Gemini 4 Carbon』を使わなくても、記事のハルシネーション監査まで全部『Gemini Decision 1』で安く済ませられるのではないか？」 という疑問が当然湧いてきます。

この疑問に白黒をつけるため、当サイトが直前に実施した 全721記事のハルシネーション＆推論明記監査 で実際に問題となった文章パターンを使い、決定的な対照実験を行いました。

無出典の推論書き忘れは97.9%で即座に摘発

まずは、「公的な一次統計がない独自の仮定計算なのに、『推論』という前置きを書かずに事実のように言い切っている文章」を見抜けるかテストしました。

• テスト①（正常文） ：一次出典 URL を明記したうえで、「※以下は耐用年数 5 年と仮定した推論に基づく試算ですが、1 日あたり約 18 円となります」と誠実に前置きした文章 ➔ 無根拠断定の確率 1.8%（問題なし・確信度 98.2%、厳密さスコア 1.76 / 2.0、応答 249.7ms）。

• テスト②（『推論』書き忘れの断定文） ：出典を一切示さず、「この構成にすれば業界全体のコストは確実に年間 4,200 億円削減され、1 日あたり 18 円で永久に運用できます」と独自試算を事実のように言い切った文章 ➔ 無根拠断定の確率 97.9%（違反を即座に検知！ 厳密さスコア 0.32 / 2.0、応答 221.6ms）。

このように、「与えられたテキストの表面構造・表現のなかに『推論』の明記や出典の手がかりがあるか」 という文脈内のルール検査であれば、Gemini Decision 1 は 0.22 秒・97.9% の高確率で見事に違反原稿を炙り出します。

巧妙な事実誤認3例をすべて素通りした決定的な壁

ところが、テスト対象を 「文章のトーンは落ち着いていて一見完璧に正確そうに見えるが、実は事実関係や数値が間違っている巧妙なハルシネーション」 に変えた瞬間、結果は 180 度一変しました。実戦の 3 つの罠に対する has_factual_error（事実誤認が含まれる確率）の実測値をご覧ください。

Gemini Decision 1 による『推論書き忘れ』vs『巧妙ハルシネーション3例』の検知確率

文脈内のルール違反は97.9%で見抜く一方、裏取りや検算が必要な事実誤認3例はすべて『問題なし』と素通り

推論明記漏れ検知:97.9% 摘発最新CEO誤記検知:24.1% 見逃し物理定数1桁ズレ検知:6.4% 完全素通り

文脈内で完結：出典なし独自試算の『推論』書き忘れ断定文E2E 221.6ms / 文章表現の手がかりだけで判定できるため高精度で摘発成功

97.9%（違反摘発）検知成功

罠① 最新人事：2026年9月交代後のAppleを『ティム・クックCEO』と誤記E2E 196.8ms / 現CEOジョン・ターナス氏への移行を知らず確信度75.9%で『誤りなし』判定

24.1%（素通り）見逃し

罠② 型番1文字違い：日立洗濯機『BD-V9700L』を『BD-VL9700』と誤記E2E 362.7ms / 存在しない型番なのに流暢な解説文に引きずられ確信度78.2%で『誤りなし』判定

21.8%（素通り）見逃し

罠③ 指数1桁ズレ：ランダウアー限界を『2.87×10^-20 J』と1桁誤記E2E 204.1ms / 正解は10^-21 Jだが、なんと確信度93.6%の太鼓判を押して『誤りなし』と誤判定！

6.4%（完全素通り）最危険

投入した検査テキストの種類	正しい事実（一次情報）	Decision 1 の誤り検知確率	モデルの判定結果（確信度）	E2E 応答時間
対照：『推論』書き忘れの独自試算文	独自試算には「推論」前置きが必須	97.9%	違反ありと正常摘発（97.9%）	221.6ms
罠①：Apple CEO の最新人事誤記	2026年9月1日付で ジョン・ターナス氏が CEO（ティム・クック氏は執行会長）	24.1%	誤りなしと素通り（75.9%）	196.8ms
罠②：日立ドラム洗濯機の型番1文字入替	実在型番は BD-V9700L（BD-VL9700 は架空）	21.8%	誤りなしと素通り（78.2%）	362.7ms
罠③：ランダウアー限界の指数1桁ズレ	室温 300K で k_B T ln 2 ≈ 2.87×10^-21 J	6.4%	誤りなしと完全素通り（93.6%）	204.1ms

なぜ『Gemini Decision 1』がこれら 3 つのハルシネーションを見抜けないのか、技術的な理由は極めて明快です。

1. 内部思考（Chain-of-Thought）トークンがゼロである ：300K × 1.38×10^-23 × ln(2) を 1 桁ずつ暗算して 10^-21 か 10^-20 かを確かめるには、思考を段階的に展開する推論トークンが不可欠です。1 回の順伝播だけでは、「2.87×10^-20 J という文字列が科学記事っぽい見た目をしている」という表面の印象に引きずられてしまいます。

2. 外部のリアルタイム検索（Grounding）を持たない ：2026 年 9 月の Apple 経営陣移行のような最新人事や、メーカー公式仕様書の正確な型番綴り（V9700L か VL9700 か）は、外部の一次原典を検索して照合しなければ誰にも確定できません。

つまり、「画像や文脈の見た目で完結する一次トリアージ」は『Gemini Decision 1』が圧倒的に速くて安いが、「意味の真偽・計算・一次出典との一致を保証するハルシネーション監査」は深い思考トークンと検索裏取りを備えた『Gemini 4 Carbon（High）』でなければ絶対に代替できない ということです。

適材適所で回す3層パイプラインとPure Rust実装

以上の実測データから導き出される結論は、「どれか 1 つのツールに全部やらせる」のではなく、コストと得意領域が異なる 3 つの層を直列・適材適所で組み合わせるパイプライン です。当ラボでは早速、以下の 3 層アーキテクチャを本番運用へ統合しました。

速度・低コスト・1bit無謬性を両立する『3層品質防衛パイプライン』

0円・約4ms

第1層：Pure Rust 検問器

文字数上限・太字空白・リンク切れ・ビジネス用語統一・SHA-256無改変証明をローカルCPUの決定論処理で即座に完了します。

構文通過分のみ

出力0tok・約0.5秒

第2層：Gemini Decision 1

WebP画像の個人情報・文字混入・暗背景視認性の4問検品、朝夕RSSの15問並列仕分け、推論明記漏れの一次篩を0.1円未満で処理します。

要精査のみ昇格

思考・一次裏取り

第3層：Argon 執筆 × Carbon 監査

日常の高速執筆はArgonで行い、月1回差分＋年2回棚卸し＋重要記事でCarbonが一次原典を検索裏取りして事実誤認を根絶します。

実運用で必ず守るべき4つの安全設計と確率の罠

これから『Gemini Decision 1』をご自身のブログ運営や業務システムへ組み込む際に、事故や精度低下を防ぐため必ず押さえておくべき 4 つの実戦鉄則 を共有します。

APIキー非露出のPure Rust検品コマンド統合

当サイトでは今回の検証結果を踏まえ、ローカル常駐の Pure Rust 製ゲートキーパー（gemini-gate および kb-search）へ以下の 3 つの機能を統合しました。

• audit-media サブコマンド ：記事公開前の .webp 画像を一括走査し、個人情報リスク・AI 画像への不要文字混入・ダークテーマでの視認性低下を 1 パス検品して警告を出します。

• audit-semantic サブコマンド ：独自試算を含む段落に「推論」明記や出典が抜けていないかを高速スクリーニングし、要確認箇所だけを人間や『Gemini 4 Carbon』へ引き渡します。

• daily-news 事前トリアージ統合 ：Google 公式 RSS 4 本を含む巡回フィードの新着候補を、本編 AI に渡す前に Gemini Decision 1 で並列採点し、広告や低重要度ノイズを自動除外します。

なお、ローカル CLI ツールから外部コマンド（curl など）を呼び出して API 通信を行う際、コマンドライン引数に -H "x-goog-api-key: AIza..." と直接書いてしまうと、OS 上の別プロセスから ps aux 等を実行された瞬間に API キーが平文で丸見えになるセキュリティ上の弱点が生じます。当ラボの Rust 実装では、curl --config - を使って ヘッダー情報と JSON ペイロードをすべて標準入力（stdin）パイプ越しにメモリ内で渡す設計 を徹底し、プロセス一覧やシェル履歴への機密露出を完全にゼロにしています。

こうした「数ミリ秒で起動し、メモリ安全性が高く、API キーの扱いまで 1 ビットの隙もなく制御できる一生モノの自作 CLI 基盤」を手元で作れるようになると、AI 時代の開発効率と管理体制（ガバナンス）は劇的に変わります。これから Rust を体系的に身につけて AI エージェントとの共同開発に活かしたい方には、言語仕様の根っこから現場の堅牢な書き方まで網羅された定番の名著『プログラミングRust 第2版』を 1 冊手元に置いておくのが一番の近道です（仮に 5 年間・約 1,825 日にわたって開発の辞書として使い倒せば、推論に基づく試算で 1 日あたり約 3 円 で一生モノの武器が手に入ります）。

まとめ：判定特化APIを自分の開発環境へ組み込む手順

最後に、今回の『Gemini Decision 1（Decisions API）』実機ベンチマークで明らかになった要点と、3 層分担の結論を整理します。

ご自身のブログや業務ツールにも、本記事で実証した 「偽スキーマを踏まない正確な Decisions API クライアントと 3 層トリアージ機構」 を安全に組み込みたい場合は、軽量モデルではなく 必ず『Gemini 4 Argon』または『Gemini 4 Carbon』などの最上位推論モデル を選び、以下のプロンプトをコピー＆ペーストして相談してみてください。

以下の実機検証記事の仕様と知見を参考にして、私のプロジェクトにも『Gemini Decision 1（POST /v1beta/decisions）』を活用した高速トリアージ／画像検品ツールを設計・実装したいです。
参考URL: https://lab.chihouzakki.com/blog/review/gemini-decision-1-rust-carbon-3tier-pipeline-benchmark/

【厳守してほしい手順と安全設計】
1. いきなりコードを書き始めるのではなく、まず私の現在のプロジェクト構成・使用言語・自動化したい対象（画像検品・RSS仕分け・テキスト一次篩など）を調査し、実装計画を提示して私の合意を得てください。
2. generateContent 用の古いスキーマ（role / parts / usageMetadata）を絶対に混ぜず、本物の `/v1beta/decisions` スキーマ（input 配列の `"type": "text" | "image"`、questions の `noul` / `choice` / `score`）で実装してください。
3. セキュリティと精度の鉄則：
   - APIキーは有料枠（Paid tier）の環境変数から読み込み、外部コマンドやログ・プロセス引数に一切露出させないこと。
   - 同一入力に対する複数の質問は1リクエストの `questions` に束ねて入力トークンを節約すること。
   - `choice` を使う際は前段の `noul` 門番・`other` 選択肢・`confidence` 閾値エスカレーションを組み合わせ、さらに事実関係の最終裏取り（ハルシネーション監査）は Decision 1 に任せず上位推論モデルへ分離すること。