OpenCode × Phala｜TEE付きAPIでAIエージェントを7時間動かした

なぜ「エージェントとして」動かすことに意味があるのか

機密性を訴えるAI APIの多くは、チャットで1問1答する分には問題なく使えます。ところがコーディングエージェントとして使おうとすると、途端に選択肢が狭まります。ファイルを読む、コマンドを実行する、Webを取得する、といった動作はすべて tool calling（function calling）に依存しているためです。

「TEE対応」と書かれていても、tool calling が実際に成立するかどうかは別の話です。ここを確認せずに選ぶと、環境を組んでから動かないことに気づきます。

そこで編集部では、OpenAI互換クライアントである OpenCode ↗（外部サイト・新しいタブで開きます） に Phala の推論APIをつないで、実作業を約7時間そのまま任せてみました。以下はその記録です。

つなぎ方

Phala の推論APIは OpenAI 互換なので、専用のプラグインは要りません。OpenCode の設定ファイルにプロバイダを1つ足すだけです。

{
  "provider": {
    "phala": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Phala (TEE)",
      "options": {
        "baseURL": "https://inference.phala.com/v1",
        "apiKey": "{env:PHALA_API_KEY}"
      },
      "models": {
        "deepseek/deepseek-v4-flash-0731": { "name": "DeepSeek V4 Flash (TEE)" },
        "phala/qwen3.6-35b-a3b-uncensored": { "name": "Qwen3.6 35B-A3B Uncensored" }
      }
    }
  }
}

APIキーは設定ファイルに直接書かず、環境変数から読ませます。キーを平文でファイルに置くと、そのファイルがバックアップや共有の対象になったときにそのまま漏れます。

エージェントごとのモデル分けやローカルLLMの接続まで含めた設定の全体像は、OpenCodeにプライベートAIをつなぐ設定ガイドにまとめています。

同じゲートウェイは https://api.redpill.ai/v1 からも使えます（運営会社が同じで、アテステーションの内容も一致します）。違いはカタログで、redpill.ai 側にはTEE非対応のモデルも並びます。編集部が上記の tool calling の動作を両方の窓口で確認したところ、どちらも同じように tool_calls を返しました。

用途ごとにエージェントを分けておくと、モデルの使い分けが楽になります。OpenCode では agent ごとに model を指定できるので、「普段の作業はこのモデル、拒否が邪魔になる調査はこちら」という切り替えが設定だけで済みます。

実測した結果

規模

ツールの内訳は、シェル実行382・Web取得136・ファイル編集61・ファイル読み込み51・ファイル書き込み37・利用者への質問23などでした。読むだけでなく書き換えと実行まで含めて完走しています。

失敗した36回の中身は、取得先が404を返した、接続できなかった、利用者が権限を拒否した、のいずれかです。モデル側が要求を断ったことによる失敗は含まれていません。

断られた回数

アシスタントが出力したテキスト706件を、拒否の定型表現（「お応えできません」「申し訳ありませんが」「不適切」I can't help など）で全文検索したところ、該当は0件でした。

実効コスト

公式のモデルAPIが公開している単価（入力$0.20 / 出力$0.40 / キャッシュ読み$0.07、いずれも100万トークンあたり）に、実際に消費したトークンを掛けたものです。

注目したいのは内訳です。全トークンの88%、全コストの71%がキャッシュ読み込みでした。出力に対する課金は$0.10しかありません。

エージェントは、1ターンごとにそれまでの会話全体を読み直します。つまり実際の請求を決めるのは出力単価ではなく、「同じ文脈を何回読み直すか」と「そこにキャッシュ割引が効くか」です。入力単価と出力単価だけを並べた比較表は、この構造を落とします。

速度

平均値にはツールの実行待ちが含まれます。最短は1.7秒、最長は20分を超えるターンもありました。代表値というより分布として見てください。

失敗の内訳

7時間で発生したストリーミングの中断は12件でした。

• レート制限が3回。「しばらくしてから再試行してください」というメッセージで、再試行すれば回復しました
• コンテキスト上限の超過が5回。これはエラーメッセージ自体が上限を教えてくれるので、確認手段としても使えます。Qwen3.6の無検閲モデルは131,072トークン、Gemma-4の無検閲モデルは65,536トークンでした
• 残りは別プロバイダ（比較用に併用していたもの）の上流混雑によるものです

コンテキスト上限のエラーは、いずれも「出力に32,000トークンを要求した」ことが引き金でした。上限の小さいモデルでは、確保した出力枠がそのまま入力を圧迫します。無検閲モデルは上限が小さいものが多いので、ここは設定で調整する前提だと考えたほうが安全です。

事前に確認しておきたかったこと

tool calling の可否は対応表では判断できない

比較用に別のゲートウェイ経由で無検閲モデルを試したところ、No endpoints found that support tool use（404）が返り、ツールを全部無効にしないと起動すらしませんでした。

逆方向の落とし穴もあります。今回メインで使ったモデルは、カタログ上の supported_parameters が空配列でした（同カタログでは66件中14件がこの状態です）。それでも740回のツール呼び出しが問題なく成立しています。

つまり、カタログのメタデータは「できない」の根拠にも「できる」の根拠にもならないということです。判定できるのは実際に叩いたときだけです。無検閲モデルを選ぶときは特に、小さなツール呼び出しを1回テストしてから環境を組むことをおすすめします。

アテステーションが何を証明しているか

Phala の推論APIはアテステーション取得用のエンドポイントを備えていて、Intel TDX の quote と NVIDIA GPU の証明、動いているコードの出自まで返ってきます。実在する、検証可能な仕組みです。

ただし**model パラメータに何を指定しても、返る証明は同一でした。応答には serving: "aggregator" と入っています。これは設計どおりで、公式の Trust Boundary 文書も、アテステーションレポートはゲートウェイ**を検証するものだと説明しています。

「証明が取れた」ことと「そのモデルの推論がTEE内で行われた」ことは別です。詳しくはPhalaとは？TEE対応AI APIの仕組みを解説で整理しています。

この構成が向く場面・向かない場面

対応サービス

よくある質問

QOpenCodeでPhalaを使うのに専用のプラグインは必要ですか？

必要ありません。OpenAI互換なので、設定ファイルの provider に baseURL と APIキーを書けば動きます。APIキーは環境変数から読ませてください。

QTEE対応と書かれていれば、コーディングエージェントとして使えますか？

別の話です。エージェント動作は tool calling に依存するため、TEEの有無とは無関係に対応可否が分かれます。しかもカタログのメタデータは実態と一致しないことがあるので、小さなツール呼び出しを1回試してから環境を組むのが確実です。

Qエージェント運用のコストはどう見積もればよいですか？

入力単価と出力単価だけでは足りません。編集部の実測では全コストの71%がキャッシュ読み込みでした。エージェントは毎ターン会話全体を読み直すため、キャッシュ割引の有無と会話の長さが実額を左右します。

Q無検閲モデルをエージェントとして使えますか？

モデルによります。編集部の環境では、あるゲートウェイ経由の無検閲モデルは tool use 非対応として404を返し、別の無検閲モデルはファイル読み書きまで完走しました。事前の実地確認が要ります。

本記事の掲載内容の最終確認日: 2026-08-14（15日前）