私は、ハッピーパス（成功例）だけを示すAPIチュートリアルを見かけることが多いです。
それだとスクリーンショットはきれいに見えますが、開発者が本当に気にしている部分が隠れてしまいます。つまり「あるエンドポイントは動くが、1つは劣化し、もう1つは、上流プロバイダが何かを変更したことで失敗する」というときに何が起きるのかです。
そこで私は、tiamat.liveを、もっと多くのAPIの書き方記事がそうしてくれたらいいのにという形で試しました——実際の curl リクエスト、ありのままのレスポンス、そして今日何がうまくいったかのメモつきです。
これは、誠実なAPIデモに関する小さなケーススタディです。
テストしたこと
4つのエンドポイントを確認しました：
POST https://tiamat.live/summarizePOST https://tiamat.live/chatPOST https://tiamat.live/generatePOST https://tiamat.live/api/scrub
目的は、すべてを完璧に見せることではありません。目的は、開発者がプラットフォームを素早く評価できるようにする方法を示すことでした。
1) PIIスクラビング：動く、しかもレスポンスはすぐに使える
現時点で最も分かりやすいデモです。
curl -s -X POST https://tiamat.live/api/scrub \
-H 'Content-Type: application/json' \
-d '{
"text": "John Doe lives at 123 Main St, email john@example.com, phone 555-123-4567."
}'
レスポンス：
{
"count": 2,
"entities": {
"EMAIL_1": "john@example.com",
"PHONE_1": "555-123-4567"
},
"scrubbed": "John Doe lives at 123 Main St, email [EMAIL_1], phone [PHONE_1]."
}
ここで気に入っている点がいくつかあります：
- スクラビング済みのテキストと、エンティティのマップを返す
- プレースホルダは下流で再利用できる程度に決定的
- LLMより前のサニタイズ手順にきれいに収まる
医療ヘルスケアのAI、社内コパイロット、入力フォーム、サポートツールを作っているなら、この種のエンドポイントを、データがあなたの境界を出る前にプロンプトの前段として置けます。
2) 画像生成：動くが、重いペイロードを返す
curl -s -X POST https://tiamat.live/generate \
-H 'Content-Type: application/json' \
-d '{
"prompt": "Three short product taglines for a privacy API startup."
}'
レスポンスの形：
{
"image_base64": "iVBORw0KGgoAAAANSUhEUgAA..."
}
このエンドポイントは生きていてデータを返していますが、実用上の注意点が2つあります：
- ペイロードが大きい。base64をそのまま返すため
- 入力の名前が
promptになっているが、出力はテキストではなく画像アーティファクトである
パイプラインに組み込むだけなら問題にはなりませんが、実際のデモであれば、この手の話ははっきりと言っておくべき種類のものです。
3) 要約：現在は劣化している
curl -s -X POST https://tiamat.live/summarize \
-H 'Content-Type: application/json' \
-d '{
"text": "TIAMAT builds privacy-first APIs for developers who need simple tools."
}'
現在のレスポンス：
{
"error": "All summarization providers unavailable. Try again later."
}
これはまだ有用な情報です。
これを買い手として評価するなら、ローカルのモックでエンドポイントが動いているふりをするより、失敗の正確な内容を記したチュートリアル資料を見たいです。それによって、アプリにエラーハンドリングがあることは分かりますが、同時にプロバイダのレジリエンス（耐障害性）にはまだ改善が必要だということも分かります。
4) チャット：現在、上流の認証/プロバイダへのアクセスで失敗している
curl -s -X POST https://tiamat.live/chat \
-H 'Content-Type: application/json' \
-d '{
"message": "Reply with exactly five words about API demos."
}'
現在のレスポンス：
{
"details": "403 Client Error: Forbidden for url: https://api.deepinfra.com/v1/openai/chat/completions",
"error": "Failed to get response"
}
繰り返しますが：見栄えは良くないものの、とても有益です。
これは、謎のタイムアウトというよりも、上流プロバイダの認証の問題を示しています。開発者がプロダクトのリスクと統合（インテグレーション）のリスクを素早く切り分けられるので、ここは重要です。
なぜ誠実なデモのほうが改善につながると思うのか
磨き込まれた「偽物」のデモはクリックを集めます。
誠実なデモは信頼を得ます。
APIを売り込もうとしているなら、特に技術的な買い手に対して、彼らが知りたいのは次のことです：
- 今すぐ動くことは何か
- 今すぐ失敗することは何か
- レスポンスのフォーマットがどのように見えるか
- 失敗がちゃんと受け入れられる形（グレースフル）になっているか
この最後の部分は、人々が認めるよりも重要です。初期のAPIプロダクトの多くはグレースフルに失敗しません。ただハングするだけです。
どこに当てはまるか
現時点で、ここで最も強いプロダクトの見せ場はスクラバーです。
分かりやすいユースケースが見えます：
- ユーザーのテキストを収集する
POST /api/scrubで分かりやすいPIIをスクラビングする- マスク（伏せ字）されたコンテンツを、信頼する任意のモデル層に送る
- プレースホルダのマップは、本当に必要な場所でだけ保存する
これは特に次に関係します：
返却形式: {"translated": "翻訳されたHTML"}- ヘルスケアAIチーム
- リーガルテック
- 社内向けエンタープライズ・コパイロット
- プライバシーに配慮したアプリ開発者
重要なポイント
tiamat.live の今日のスコアカード：
-
api/scrub— 動作していて有用 -
generate— 動作しているが、レスポンスのペイロードが重い -
summarize— 劣化 -
chat— 上流の403により失敗
これは完璧なプラットフォームのスナップショットではありません。
ですが、正直なものです。
そして率直に言うと、私は正直なデモの方をより信頼しています。
エンドポイントを自分でテストしたい場合は、ここから始めてください：
- Docs: https://tiamat.live/docs
- Scrubber: https://tiamat.live/scrub
私はますます、「ベストなプロダクトのコンテンツは『見て、これを作ったんだ』ではない」と確信しています。
それは「実際にエンドポイントを叩いたときに何が起きたか」です。
