API中継サービスを選ぶとき、多くの人はまず料金やモデルの一覧を確認します。しかし、「リクエストの内容は記録されるのか？」「APIキーが漏えいしたら、どう被害を抑えればいいのか？」「チャージした残高は返金できるのか？」「選んだモデルが本当に呼び出されるのか？」まで確認する人は、あまり多くありません。この記事では、すぐに使える API中継サービスのデータセキュリティ自己点検リストを紹介します。5つのステップで、一つずつ確認していきましょう。
これは「宣伝をそのまま信じる」ためのレビューではありません。特定のサービスを対象にしたものでもありません。このリストは、どのAPI中継サービスにも使えます。この記事では、比較しやすいようにAPIYIが公開している説明を例として取り上げます。今使っているサービスについて、自分で確認してみてください。
この記事で得られること：読み終えると、実行可能な確認手順と、ローカルで試せるスクリプトが手に入ります。少額をチャージしてログ、モデル、料金が想定どおりかを検証してから、残高を追加するか判断できます。
API中継サービスのデータセキュリティ自己点検：要点
API中継サービスは、あなたとモデル提供元の間に位置します。リクエストはまず中継サービスに届き、そこからモデル提供元へ転送されます。そのため、確認すべきなのは「モデルを使えるか」だけではありません。この経路にどのような記録が残るのか、誰があなたの利用枠を操作できるのか、問題が起きたときに追跡できるのかも確認が必要です。以下の表に、5つのステップの概要をまとめました。
| ステップ | 確認すること | 確認できること |
|---|---|---|
| ステップ1：ログ | デフォルトで何が記録されるか、トラブルシューティング時にリクエスト本文も記録されるか | どの情報が保存される可能性があるか把握できる |
| ステップ2：APIキー | 利用可能なモデル、利用上限、IP制限、プロジェクトごとの分離 | 漏えい時の損失を抑え、すぐに無効化できる |
| ステップ3：返金 | 返金条件、金額の計算方法、返金までの時間、運営主体 | チャージ前に安心でき、問題が起きたときの問い合わせ先がわかる |
| ステップ4：モデルの経路 | モデル名に対応する上流モデル、予備の経路、1回ごとの呼び出し先 | モデルがダウングレードされたり、差し替えられたりしていないか確認できる |
| ステップ5：マスキング | 組織の要件に沿って機密情報を扱っているか、事前にマスキングしているか | 最悪の場合に情報が漏れる範囲を最小限に抑えられる |
データセキュリティを自己点検する基本方針
このリストの基本方針は、「まず確認し、次に少額で検証し、最後に利用を増やす」です。最初の4つのステップでは、「サービス提供元の説明や規約がどうなっているか」を確認します。5つ目のステップでは、「規約に問題がなくても、自分から不要な情報を渡さない」ことを確認します。
見落とされがちなのは、最後の確認です。実際の利用シーンで一度試し、呼び出し記録を使って利用状況を照合しましょう。説明ページにどれだけ詳しく書かれていても、Request IDが付いた実際の呼び出しほど説得力のある確認方法はありません。
ステップ1：API中継サービスのログ記録範囲を確認する
まず確認したいのは、サービス提供者がデフォルトで何を記録しているのか、またトラブルシューティングの際にリクエストや回答の本文が記録される可能性があるかです。「ログがある」ことと「内容が保存される」ことは同じではありません。重要なのは、ログにどのような情報が含まれているかです。
APIYIの公開情報を例にすると、通常の呼び出しログには、呼び出し時刻、モデル、トークン使用量、料金、ステータスなどが記録され、入力と出力の本文は記録されません。調査への協力が必要な場合は、管理者が一時的に詳細ログを有効にできます。詳細ログには、プロンプト全文、システムメッセージ、会話履歴、関数呼び出しのパラメーター、モデルの回答が含まれる可能性があります。
ログの種類と確認事項
| ログの種類 | 含まれる可能性のある内容 | 確認しておきたいこと |
|---|---|---|
| 通常の呼び出しログ | 呼び出し時刻、モデル、トークン使用量、料金、ステータス | 定期的にエクスポートし、照合作業や記録に利用する |
| 詳細ログ（トラブルシューティング時に一時的に有効化） | プロンプト全文、システムメッセージ、会話履歴、関数呼び出しのパラメーター、モデルの回答 | 調査を依頼する前に、内容がマスキングされていることを確認する |
| アップロードファイル | 詳細ログに含まれるかどうかは、公開情報に記載なし | ファイルを扱う場合は、事前にサービス提供者へ書面で確認する |
特に注意したい点が2つあります。1つ目は、詳細ログが「一時的に有効化して調査を支援する」ためのものだということです。そのため、問い合わせやサポートへの調査依頼をする前に、再現用のサンプルに含めてはいけない情報を整理しておきましょう。2つ目は、ファイル本体が詳細ログに含まれるかどうかが公開情報に記載されていないことです。記載がないからといって、勝手に判断せず、直接確認してください。
通常ログの保存期間や削除のタイミングについては、APIYIのドキュメントにあるログ保存ポリシーを確認できます。照合や記録のために必要であれば、呼び出し履歴を早めにエクスポートしておきましょう。「プラットフォームがずっと保存してくれる」とは限りません。
🎯 技術的なアドバイス：ログの方針を評価する際は、APIYI（apiyi.com）のコンソールで実際の呼び出しログの項目を確認し、公開情報と照らし合わせてみてください。文章を読むだけより、具体的に把握できます。
ステップ2：APIキーと利用上限を設定する
APIキーはモデルを呼び出すための認証情報であり、アカウント残高を引き出すための「暗証番号」にも相当します。API中継サービスを利用する際に注意したいリスクの一つが、APIキーの漏えいです。公開リポジトリやスクリーンショット、グループチャットに誤って載せてしまうケースがよくあります。
APIキーは、次の方法で管理しましょう。
- 外部に漏らさない：APIキーを公開リポジトリに書き込んだり、スクリーンショットや画面録画、グループチャットに載せたりしないでください。コードでは環境変数から読み込むようにします。
- プロジェクトごとに分ける：プロジェクトごとに別のAPIキーを使います。問題が起きたときに、どのプロジェクトが原因かをすぐに特定でき、取り消すAPIキーも一つで済みます。
- 用途に応じて権限を制限する：APIキーを作成するときは、実際の用途に合わせて利用可能なモデル、利用上限、IP制限などを設定します。制限できる項目は、できるだけ設定しましょう。
- 定期的に確認する：呼び出し履歴と残高を定期的に確認し、見覚えのないモデルや時間帯の呼び出しがないか注意しましょう。
- 異常があればすぐに対処する：見覚えのない呼び出しや不審な請求に気づいたら、まず該当するAPIキーを無効化して新しいキーを作成し、その後、サービス提供元に履歴の確認を依頼します。
調査時に見落としやすい点がもう一つあります。カスタマーサポートに連絡するときは、APIキー全体を送らないでください。Request ID、呼び出し時刻、発生した事象を伝えれば、原因の特定には十分です。APIキー全体を送ると、漏えいのリスクを増やすことになります。
APIキーのセルフチェックリスト
| 確認項目 | 合格基準 | 不合格の場合の対応 |
|---|---|---|
| 保管場所 | 環境変数またはシークレット管理ツール | すぐに移行し、漏えいしたAPIキーを再発行する |
| プロジェクトの分離 | プロジェクトごとに独立したAPIキーを使用 | プロジェクトごとに分け、古いAPIキーを順次廃止する |
| 権限の範囲 | モデル、利用上限、IPなどを制限 | 管理画面で設定可能な制限を追加する |
| 確認頻度 | 定期的に確認する習慣がある | カレンダーにリマインダーを設定し、毎回残高の変化を確認する |
第 3 ステップ：チャージ前に返金ルールと運営主体を確認する
チャージする前に、返金条件、返金額の計算方法、返金までにかかる時間、サービスの運営元の4点を確認しましょう。これらの情報はポリシーページに記載されています。チャージ後に「返金できない」と気づくのが、最も困るケースです。
APIYIの返金ポリシーを例にすると、ルールはおおむね次のとおりです。チャージから30日以内であれば返金を申請でき、返金額は未使用残高などのルールに基づいて計算されます。キャンペーンで付与された金額は差し引かれます。また、中国本土のユーザーは、すでに発行済みの請求書がある場合、返金を申請できません。返金にかかる時間は支払い方法によって異なるため、申請前にポリシーの詳細を確認してください。
運営主体も重要な確認項目です。APIYIの利用規約には、運営主体が MrrBase, LLC と記載されています。他のAPI中継サービスを確認するときも、運営主体が明記されているか、利用規約で確認できるかをチェックしましょう。
問い合わせる際は、公式サイトやドキュメントに掲載されている窓口を優先してください。APIYIが公開している窓口は、WeCom（企業WeChat）カスタマーサポート、[email protected]、Telegramの@apiyi001です。公式ページに掲載されていない「個人の連絡先」には、安易に送金したり、アカウント情報を伝えたりしないようにしましょう。
返金・運営主体の確認表
| 確認項目 | 確認すること | APIYIの公開情報の例 |
|---|---|---|
| 返金期限 | チャージ後、いつまで申請できるか | チャージから30日以内 |
| 返金額の計算 | どのように計算され、付与分はどう扱われるか | 未使用残高などのルールに基づき計算。キャンペーンで付与された金額は差し引き |
| 返金できないケース | どのような場合に返金できないか | 中国本土のユーザーは、請求書が発行済みの場合、申請不可 |
| 返金までの時間 | 返金にどれくらいかかるか | 支払い方法によって異なるため、ポリシーの詳細を確認 |
| 運営主体 | 誰が運営しているか | MrrBase, LLC |
| 公式窓口 | どこに問い合わせるか | WeComカスタマーサポート、[email protected]、Telegram @apiyi001 |
第4ステップ：モデル名と上流チャネルを確認する
「モデルが安価なものにすり替えられているのでは」という不安は、API中継サービスのユーザーによくある懸念の一つです。出力品質を感覚で判断するより、サービス提供元に次の3点を直接確認しましょう。ページやログに表示されるモデル名は、上流のどのモデルに対応しているのか。予備チャネルを使用しているのか。特定の呼び出しがどのチャネルを経由したか、どう確認できるのか。
APIYIのモデルの忠実性に関する説明を例にすると、モデルのダウングレードや置き換えは行わないとしています。Claudeの場合、デフォルトではAWS Bedrockの公式接続を利用し、予備チャネルにはAnthropic公式キーによる直接接続を使用します。重要なのは、サービス提供元が「デフォルトチャネル」と「予備チャネル」を公開ページに明記していることです。曖昧な説明に終始していないか確認しましょう。
Request IDで個別の呼び出しを確認する方法
特定の呼び出しを検証したい場合は、そのRequest IDを保存しておきましょう。APIYIのRequest IDを使ったトラブルシューティングの説明によると、ログで該当する呼び出しのモデル、チャネル、ステータス、課金記録を確認できます。不明点がある場合は、Request IDを添えてカスタマーサポートに問い合わせてください。
実用的な習慣として、重要な呼び出しごとに、自社のシステムにも記録を残しておくとよいでしょう。少なくとも、呼び出し時刻、リクエストしたモデル名、返されたモデル名、トークン使用量を記録します。問題が起きたときに、自社の記録とプラットフォームのログを照合できます。
| 質問 | 期待する回答 | 回答がない場合のリスク |
|---|---|---|
| モデル名は上流のどのモデルに対応するか | 明確な対応関係 | モデルが置き換えられているか判断できない |
| 予備チャネルを使用しているか | 予備チャネルと切り替え条件の説明 | チャネル切り替え後に挙動が変わっても、理由を説明できない |
| 個別の呼び出しでチャネルを確認する方法 | Request IDを使ってログを照会 | 問題が起きた際に証拠を示せない |
| モデルのダウングレードを行うか | ダウングレード・置き換えを行わないとの公開声明 | 比較・検証の基準となる約束がない |
第 5 步：機密情報は事前にマスキングしてから送信する
社内コード、未公開の文書、顧客情報、財務情報や医療情報を扱う場合は、まず所属組織のセキュリティ要件を満たしているか確認してください。マスキングできる情報は事前にマスキングし、問題の調査にはできるだけ小さなサンプルを使って再現しましょう。資料全体をそのままアップロードするのは避けてください。
組織で機密情報を第三者の中継サービスに通すことが禁止されている場合は、そのルールを厳守してください。「便利だから」という理由で例外にしてはいけません。マスキングの目的は完全な安全を保証することではなく、万一の際に情報が露出する範囲を最小限に抑えることです。
以下は、ローカル環境でマスキングする簡単な例です。プロンプトを送信する前に、よくある形式の機密情報をプレースホルダーに置き換えます。ただし、一般的な形式にしか対応していないため、目視での確認や組織のコンプライアンス要件への対応に代わるものではありません。
import re
PATTERNS = {
"EMAIL": r"[\w.+-]+@[\w-]+\.[\w.-]+",
"PHONE": r"\b1[3-9]\d{9}\b",
"API_KEY": r"\bsk-[A-Za-z0-9]{16,}\b",
}
def redact(text: str) -> str:
for label, pattern in PATTERNS.items():
text = re.sub(pattern, f"<{label}>", text)
return text
print(redact("联系 [email protected]，手机 13800000000，Key sk-abcdefghijklmnop1234"))
API中継サービスのデータ安全性をすばやくチェック
最初の5ステップは「質問」、ここからは「検証」です。初めて利用する際は、まず少額をチャージし、実際の利用シーンに近いタスクを、機密情報を含めずに1〜2件試してみましょう。その後、呼び出しログやモデル、料金を確認します。この記事では、まず5ドルをチャージし、想定どおりに利用できることを確認してから、残高を追加するか判断する方法をおすすめします。
最小限の例：照合できるテスト実行
次のコードは環境変数からAPIキーを読み込み、最小限のリクエストを1回送信します。返されたモデル名と使用量を出力するので、コンソールのログと照合できます。
import os
import openai
client = openai.OpenAI(
api_key=os.environ["API_KEY_TEST"],
base_url="https://api.apiyi.com/v1" # 使用 APIYI 统一接口
)
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": "用一句话介绍你自己"}],
max_tokens=400,
)
print("id:", resp.id)
print("model:", resp.model)
print("usage:", resp.usage)
SDKが返す resp.id が、プラットフォームのログに表示されるRequest IDと同じかどうかは、公式ドキュメントで確認してください。コンソールの呼び出しログから該当時刻の記録を見つけ、モデル、ステータス、料金が手元の出力と一致するか照合しましょう。
完全なコードを表示：ローカル監査ログ付きテスト実行スクリプト
import json
import os
import re
import time
from typing import Optional
import openai
PATTERNS = {
"EMAIL": r"[\w.+-]+@[\w-]+\.[\w.-]+",
"PHONE": r"\b1[3-9]\d{9}\b",
"API_KEY": r"\bsk-[A-Za-z0-9]{16,}\b",
}
AUDIT_FILE = "relay_audit.jsonl"
def redact(text: str) -> str:
"""提交前脱敏常见敏感字段。"""
for label, pattern in PATTERNS.items():
text = re.sub(pattern, f"<{label}>", text)
return text
def call_and_audit(
prompt: str,
model: str = "gpt-4o-mini",
system_prompt: Optional[str] = None,
max_tokens: int = 400,
) -> str:
"""调用模型，并把可对账的信息写入本地审计文件。"""
client = openai.OpenAI(
api_key=os.environ["API_KEY_TEST"],
base_url="https://api.apiyi.com/v1", # 使用 APIYI 统一接口
)
messages = []
if system_prompt:
messages.append({"role": "system", "content": redact(system_prompt)})
messages.append({"role": "user", "content": redact(prompt)})
started = time.time()
resp = client.chat.completions.create(
model=model,
messages=messages,
max_tokens=max_tokens,
)
record = {
"time": time.strftime("%Y-%m-%d %H:%M:%S", time.localtime(started)),
"requested_model": model,
"returned_model": resp.model,
"response_id": resp.id,
"prompt_tokens": resp.usage.prompt_tokens,
"completion_tokens": resp.usage.completion_tokens,
"latency_s": round(time.time() - started, 2),
}
with open(AUDIT_FILE, "a", encoding="utf-8") as f:
f.write(json.dumps(record, ensure_ascii=False) + "\n")
return resp.choices[0].message.content
if __name__ == "__main__":
print(call_and_audit("请用两句话解释什么是 API 中转站"))
スクリプトの実行後、relay_audit.jsonl を開き、記録された時刻、モデル、トークン使用量をコンソールのログと1件ずつ照合してください。リクエストしたモデルと返されたモデル名が異なる場合や、料金と使用量が一致しない場合は、記録を添えて公式窓口に問い合わせましょう。
🚀 すぐに試す：初回の少額テストには APIYI（apiyi.com）がおすすめです。上記のスクリプトを実行し、コンソールのログと照合すればセルフチェックは完了です。機密情報を扱う必要はありません。
よくある質問
Q1：API中継サービスは、プロンプトや回答を保存しますか？
サービス提供元の説明によります。APIYIの公開情報では、通常の呼び出しログに記録されるのは日時、モデル、トークン使用量、金額、ステータスで、入力・出力の本文は記録されません。トラブルシューティングを支援する場合に限り、管理者が一時的に詳細ログを有効にすることがあります。どのAPI中継サービスを使う場合も、事前にこの点を確認しておきましょう。
Q2：プロジェクトごとに異なるAPIキーを使うのはなぜですか？
APIキーに問題が起きた場合、そのプロジェクトのキーだけを無効化すれば、ほかのプロジェクトには影響しません。また、呼び出し履歴から、どのプロジェクトで問題が起きたのかを特定しやすくなります。利用可能なモデルや上限額などの制限も設定しておけば、損失を小さく抑えやすくなります。
Q3：チャージ後に気が変わった場合、必ず全額返金されますか？
必ずしもそうとは限りません。具体的なポリシーによって異なります。APIYIの場合、チャージ後30日以内であれば返金を申請できますが、返金額は未使用残高などのルールに基づいて算出されます。キャンペーンで付与された金額は差し引かれ、中国本土のユーザーは、すでに領収書が発行されている場合、返金を申請できません。申請前にポリシー全文を確認しましょう。また、返金の着金までにかかる時間は決済方法によって異なります。
Q4：呼び出したモデルが差し替えられていないことを確認するには？
次の2つの手順で確認できます。まず、サービス提供元に、モデル名に対応する上流モデルと、代替経路の有無を確認します。次に、重要な呼び出しのRequest IDを保存し、ログでその呼び出しのモデル、チャネル、ステータス、課金記録を照合します。APIYIの公開情報では、モデルのダウングレードや差し替えは行わないと説明されています。apiyi.comで少額のテストを行い、自分で確かめることもできます。
Q5：アップロードしたファイルが詳細ログに記録されることはありますか？
公開情報には、ファイル本体が詳細ログに記録されるかどうかが明記されていないため、記録されないと決めつけないでください。ファイルを含むリクエストを送る場合は、事前にサービス提供元へ確認しましょう。社内コードや顧客情報などの機密情報を扱う場合は、まず機密情報をマスキングするか、最小限のサンプルで問題を再現してください。
Q6：社内ルールで機密情報を第三者に渡せない場合は、どうすればよいですか？
組織のルールに従い、利便性を理由に回避しないでください。機密情報を含まないタスクはAPI中継サービスに任せ、機密情報を含むタスクは組織が認めた環境内にとどめる方法があります。API中継サービスのチェックリストはリスク軽減には役立ちますが、コンプライアンス上の要件に代わるものではありません。
API中継サービスのデータ安全性セルフチェック：要点
- ログは種類ごとに確認する：通常ログと詳細ログは別物です。まず、トラブルシューティング時にリクエスト本文が記録されるかを確認しましょう。
- APIキーの利用範囲を決める：プロジェクトごとに分け、モデル・利用上限・IPアドレスなどを制限しましょう。異常があれば、まず無効化してから再発行します。
- 返金条件は全文を確認する：申請期限、返金額の計算方法、返金できないケース、返金の反映時期を、チャージ前に一つずつ確認しましょう。
- 利用するチャネルを照合できるようにする：上流のモデル名と予備チャネルを確認し、Request IDを使って個々の呼び出しを検証しましょう。
- 機密情報は手元でマスキングする：機密情報はマスキングしてから送信します。組織の規定で送信が認められていない場合は、送信しないでください。
- 少額から試して、問題がなければ増額する：まず5ドルをチャージして、実際の利用シーンで動作を確認しましょう。初回の検証には、APIYI apiyi.comの利用がおすすめです。
まとめ
API中継サービスのデータ安全性をセルフチェックするには、宣伝文句を確認可能な事実に置き換えることが大切です。
- ログとマスキング：デフォルトで記録される範囲を確認し、機密情報はマスキングしてから送信します。
- APIキーと利用上限：プロジェクトごとに分離し、用途に応じて権限を制限します。異常があれば、すぐに無効化しましょう。
- 返金とチャネル：チャージ前に返金ルールと運営主体を確認し、Request IDを使ってモデルとチャネルを照合します。
API中継サービスは、宣伝だけを見て選ぶ必要はありません。データの記録方法、APIキーの権限、返金ルール、モデルのチャネルを一つずつ確認したうえで、実際に呼び出して検証すれば、より納得して判断できます。まずはAPIYI apiyi.comで少額の残高を使って手早く効果を確認し、期待どおりだと判断できてから利用額を増やすのがおすすめです。
📚 参考資料
-
ログ保存ポリシー — 通常ログの保存期間と削除のタイミングを確認できます。照合作業や記録の保管前に、保存期間をご確認ください。
-
返金ポリシー — 返金条件、金額の計算方法、返金の反映について説明しています。チャージ前に返金対象外となるケースをご確認ください。
-
利用規約 — 運営主体とサービスに関する取り決めを確認できます。サービスの運営者をご確認ください。
-
モデルの忠実性に関する説明 — モデルの接続先とダウングレードを行わない方針について説明しています。デフォルトの接続先と予備の接続先をご確認ください。
-
Request ID による調査方法 — 個々の呼び出しについて、モデル、チャネル、課金内容を照合できます。問題が発生した場合は、Request ID を添えてサポートへお問い合わせください。
著者: APIYI 技術チーム
技術交流: APIYI 公式サイト apiyi.com からお問い合わせください。詳しい資料は docs.apiyi.com のドキュメントセンターをご覧いただけます。
