すべての記事
Claude API でApp Storeの多言語ストア掲載情報を文字数制限つきで生成する
App Storeの掲載情報を翻訳のまま貼るとSubtitleの30文字などの制限で弾かれます。Claude APIのTool Useで文字数制限をスキーマとして強制し、生成後の再検証と超過フィールドだけを圧縮する修復ループで各ロケールの上限内に収める実装を、キーワード欄の使い切り方まで含めて解説します。
API リクエスト1本でリモート MCP サーバーに直接つなぐ — Messages API の MCP コネクタ実装メモ
ローカルに MCP クライアントを立てずに、Messages API の mcp_servers と mcp_toolset だけでリモート MCP サーバーのツールを呼ぶ実装をまとめました。allowlist/denylist 設計、レスポンス処理、無人運用での落とし穴まで。
前の実行が終わらないうちに次が走り出すとき — リースとフェンシングトークンで定期エージェントの多重起動を抑える
毎朝の定期実行が前回の処理を追い越して二重に走り出す問題を、リースとフェンシングトークンで抑える設計を解説します。素朴なロックが破れる瞬間の分析から、任意ストア上の最小リース実装、副作用直前のトークン検証、上限付きキャッチアップまで、運用で固めた既定値とともに実装コード付きで整理しました。
サポートAIが本番で「自信満々に間違える」とき — 根拠の外を踏ませず、迷ったら人へ渡す運用メモ
Claude API のカスタマーサポートエージェントが、テストでは完璧でも本番で存在しない情報を断言してしまう問題への対処。検索段階で「答えない」を決める設計、根拠付き生成、誤自信率の計測、エスカレーション精度の調整までを運用視点でまとめます。
ツール定義を一行直しただけで、キャッシュが丸ごと作り直しになりました — cache_control ブレークポイントの置き場所
ヒット率が突然ゼロに張り付いた原因は、揮発するブロックを安定したブロックより上流に置いていたことでした。prefix キャッシュのカスケード失効の仕組みと、安定→揮発でブロックを並べ替え、4つしかない cache_control ブレークポイントをどこに置くかを実装と判断表で整理します。
上限が倍になった日に決めたこと — 共有APIキーで定期ジョブを束ねる余白予算の設計
レート上限が倍になってもジョブ間隔を詰めなかった理由と、共有APIキーで複数の定期ジョブを束ねる「余白予算」の設計をまとめました。レスポンスヘッダーからの現状計測、ジョブ別の消費割り当て、予算を据え置いた判断の背景、本番運用で見えた落とし穴までを実コードとともに紹介します。
Claude API の従量課金で、Stripe の請求額と自分の帳簿がズレるとき — 使用量イベントの突合運用メモ
Claude API の従量課金は「使った分だけ請求」が理想ですが、実運用ではStripe側の集計と自前の使用量台帳が静かにズレます。Billing Meters の冪等化・突合ジョブ・モデル変更耐性まで、運用で効いた設計を整理します。
毎朝のバッチでプロンプトキャッシュが毎回ミスしていた — 1時間TTLを延命するウォーミング間隔と損益分岐の出し方
数時間おきに走る定期実行では、1時間TTLのプロンプトキャッシュでも毎回コールドミスします。中身を変えずにTTLを延命するウォーミングの間隔をTTLから逆算し、読み取りコストを織り込んだ損益分岐を式で出す方法を、4サイトの自動生成パイプラインの実測とともにまとめました。
思考が常時オンのモデルに移すと、プレフィルが静かに効かなくなる — Fable 5 でストリーミングとトークン予算を直した記録
Fable 5 は思考が常時オンです。プレフィルが使えない・ストリーミングの先頭ブロックがテキストではない・max_tokens に思考分の余白が要る、という三つの前提崩れを、自分の自動投稿パイプラインで直した実装メモです。
同じモデルが環境ごとに別名になる問題 — Claude をマルチプロバイダーで呼ぶ識別子リゾルバの設計
Fable 5 が API・Bedrock・Vertex で同時に使えるようになった結果、同じモデルが環境ごとに別の識別子を持つようになりました。ハードコードした model 文字列が移行を阻む問題を、論理モデル名・能力フラグ・起動時検証を備えた識別子リゾルバで畳み直す実装を整理します。
Claude API のプロンプトキャッシュが本番で静かにヒットしなくなるとき — TTLと節約額の実測メモ
プロンプトキャッシュは導入直後だけ効いて、本番では知らぬ間にヒットしなくなることがあります。完全一致プレフィックスを静かに壊す5つの要因、5分と1時間TTLの選び方、節約額を推測でなく実測に変える計装、変更頻度の階段で置くブレークポイント設計までを運用目線でまとめました。
毎回まっさらな環境で目覚める無人エージェント — 最初の30秒に状態回復を設計する
スケジュール起動の無人エージェントは、毎回まっさらな使い捨て環境で目を覚まします。書き込めないはずのパス、まだ起動しきっていないファイルシステム、消えた作業ディレクトリ。最初の30秒に状態回復を織り込む設計を、実際の運用ログから具体的に書きました。