superlog-onboard

Superlog のオンボーディング

OpenTelemetry のトレース、ログ、メトリクスをユーザーのプロジェクトに接続し、テレメトリが Superlog に送信されるようにします。現在ユーザーが作業しているアプリだけでなく、リポジトリ内のすべてのアプリとサービスを対象にしてください。

カスタムのヘルパーレイヤーよりも、ネイティブの OpenTelemetry API とフレームワークで文書化されているブートストラップを優先してください。特定のスタックで行き詰まったら、推測せず、その言語の OTel ドキュメントを検索してください。

編集を始める前に、該当するコンパニオンスキルを読んでください。

• 一般的な OTel の方針については otel-onboarding-style。
• Python サービスについては otel-python-style。
• FastAPI サービスについては otel-fastapi-style。
• LiveKit エージェントについては otel-livekit-style。
• Next.js／Vercel アプリについては otel-nextjs-style。
• Expo／React Native アプリについては otel-expo-style。
• Supabase Edge Functions については otel-supabase-edge-style。
• その他の言語（Go、Java/Kotlin、Ruby、Rust、.NET/C#、PHP、Elixir、プレーンな Node など）については otel-generic-style。上記のいずれにも当てはまらない場合のフォールバックとして使用してください。

ステップ 0 — エンドポイントと公開トークンの取り扱い

OTLP エンドポイントは常に https://intake.superlog.sh で、ブートストラップのソースに直接記述します。

Superlog の公開取り込みトークンは sl_public_ で始まります。プロジェクト単位で、書き込み専用であり、アプリケーションのソース（ブラウザーやモバイルのバンドルを含む）に記述しても安全なよう意図的に設計されています。PostHog のプロジェクトトークン、Sentry の DSN、Datadog RUM のクライアントトークンと同様に、1 つのプロジェクトにテレメトリを送信できますが、データの読み取り、設定の変更、Superlog アカウントへのアクセスはできません。

公開トークンはエンドポイントの隣に定数としてインラインで記述してください。.env ファイル、デプロイ設定、生成されるシェルコマンドには入れないでください。ソースレベルの設定が想定されるオンボーディング方法であり、環境変数の不足によるデプロイの失敗を防げます。

OTLP エクスポーターでヘッダーが必要な場合は、エクスポーターのコンストラクターに**x-api-keyヘッダーを指定して公開トークンを渡してください。これはオンボーディングで最もよくある失敗です。トークン自体は有効でも、エクスポーターが別のヘッダー名（またはヘッダーなし）で送信するため、取り込み時にすべてのリクエストが 401 となり、キーに問題がないのにインストールが失敗したように見えます。取り込み先がトークンを読み取る場所は次の 2 つだけです。x-api-key: <token>、または Authorization: Bearer <token>（リテラルの Bearer プレフィックスが必須です）。x-api-key を使用してください。Bearer プレフィックスの落とし穴を避けられ、Authorization を削除するプロキシや SDK にも影響されません。別のヘッダー名（api-key、x-superlog-token、Bearer なしの Authorization: <token>）を作らないでください**。いずれも 401 になります。

ヘッダー名が記述される箇所を 1 か所だけにするため、1 行のヘルパーでラップし、必ずヘルパーを定義してください。未定義の superlogHeaders を呼び出してはいけません。

function superlogHeaders(token: string): Record<string, string> {
  return { "x-api-key": token };
}

def superlog_headers(token: str) -> dict[str, str]:
    return {"x-api-key": token}

質問は不要です。次の 2 つの方法で対応します。

プロンプトに公開トークンが含まれている場合

呼び出し元のプロンプトに sl_public_... トークンが含まれている場合は、プレフィックスを検証し、作成するすべてのテレメトリのブートストラップファイルにインラインで記述してください。チャットにトークン全体を表示してはいけません。他の公開クライアントトークンと同様、コードの差分から確認できます。

公開トークンなし

公開トークンをローカルで生成し、サインアップインテントをすぐに登録してから、並行して作業を続けます。サインアップが完了するまでインストールを止めないでください。

1. 次の形式のランダムな平文の公開取り込みトークンを生成します。 sl_public_<base64url-ish random bytes>。プレフィックスの後に、少なくとも32バイト分のエントロピーを使用します。ブートストラップファイルに直接埋め込めるよう、平文はメモリー内に保持します。ただし、トークン全体をチャットに表示してはいけません。

2. keyHash = sha256(plaintextToken) を小文字の16進数で計算し、keyPrefix = トークンのプレフィックス + プレフィックスの後に続く最初の6文字 とします。

3. Content-Type: application/json を指定し、次の本文で POST https://api.superlog.sh/api/signup-intents を実行します。

   {
     "keyHash": "<sha256 hex>",
     "keyPrefix": "<short public token prefix>",
     "returnTo": null
   }
   

   エージェントのランタイムが現在の会話に戻るための安全なリターンリンク／ディープリンクを提供している場合は、returnTo として渡します。それ以外の場合は null を使用します。このリクエストに平文のトークンを含めてはいけません。

4. 応答には id、signupUrl、expiresAt が含まれます。ユーザーの既定のブラウザーで signupUrl を開き（open "$signupUrl" / xdg-open "$signupUrl" / start "" "%signupUrl%"）、チャットにURLを表示します。サインアップタブが開いており、GitHub／Slack のインテグレーションはそこで行うこと、またインストールの最後に取り込みを確認することを簡潔に伝えます。現在の作業を中断する必要はありません。

5. サインアップが完了するまで待たないでください。 生成した平文トークンをブートストラップのソースで使用し、ステップ1〜4を続けます。ステップ4が判定ゲートです。実際のテレメトリーを送信し、応答コードに基づいてユーザーがまだサインアップを完了する必要があるかどうかを判断します。

ステップ1 — リポジトリー内のすべてのアプリ／サービスを洗い出す

何かに計装を追加する前に、ここに何があるかをすべて列挙します。ワークスペースのマニフェスト（pnpm-workspace.yaml、ルート package.json の workspaces、go.work、Cargo ワークスペース、Python pyproject.toml のワークスペース設定、apps/* や services/* の慣例）を確認します。各サービスを特定します。Web フロントエンド、API、ワーカー、バックグラウンドジョブ、CLI、サンプル／デモアプリ、モバイルアプリ、Supabase、および／またはサーバー関数が対象です。モバイルやサーバーレス／エッジ関数も対象です。クライアント側であることや実行時間が短いことを理由に除外してはいけません。実行時のエントリーポイントがない、型／設定のみのパッケージは除外します。実行可能なサービスを除外したり、「対象外」のままにしたりしてはいけません。この作業ですべてを計装してください。後続の作業はない可能性があります。

作業を始める前に一覧をユーザーに提示し、修正があれば教えてもらいます。

ステップ2 — 各サービスにネイティブ OTel をインストールしてブートストラップする

言語にネイティブな OpenTelemetry SDK を使用します。 公式パッケージがある場合は、ベンダーのラッパーや独自実装のヘルパーを使用しないでください。「ネイティブ」とは、たとえば Node サーバーでは @opentelemetry/sdk-node、一般的な Next.js／Vercel アプリでは @vercel/otel（sdk-node は Next の webpack を壊し、フレームワークのブートストラップを見落とします）、Vite／SPA／Expo では @opentelemetry/sdk-trace-web とブラウザー／モバイル対応のエクスポーター、Python では opentelemetry-instrumentation-* と opentelemetry-sdk、Go では go.opentelemetry.io/otel を使用することです。

広範なラッパー API は使用しないでください。sendSuperlogSpan、recordCounter、recordLog、startTelemetrySpan、withTelemetry のような再利用可能なヘルパーは避けてください。ネイティブのトレーサー／メーター／ロガーをモジュールスコープで取得し、SDK 独自の API を直接使用します。TypeScript／JavaScript では、範囲を限定したビジネススパンに公開済みの @superlog/otel-helpers の withSpan ヘルパーを使用し、@superlog/otel-helpers を package.json に追加します。パッケージをインストールできる場合、関数全体を startActiveSpan と try／catch／finally に展開せずに済むため、これは必須です。OpenInference／プロバイダーの計装で直接観測できるプロバイダー SDK の呼び出しをヘルパーで囲んではいけません。エッジランタイムでアップストリームの OTel SDK を実際に読み込めない場合は、シムを小さく保ち、プロバイダーに依存せず、OTel 形式にします。tracer.startActiveSpan、span.setAttributes、SpanStatusCode、meter.createCounter、histogram.record を使用してください。 3 つのシグナルすべて（トレース、ログ、メトリクス）を接続します。ログは標準出力だけではなく OTLP 経由で送信します。使用言語の OTel ログブリッジを設定し、アプリのログ（既存のログレベルや構造化フィールドを含む）に、アクティブな trace_id / span_id が自動的に付与されるようにします。既存のロガーはそのまま動作します。下位に OTLP ハンドラー／プロセッサーを追加するだけです。

ログブリッジは任意ではなく、SDK の初期化だけで「対応済み」になるものでもありません。ほとんどの言語 SDK やフレームワークラッパーは、デフォルトでトレース（場合によってはメトリクスも）を接続しますが、明示的な LoggerProvider と OTLP ログエクスポーター、ログレコードプロセッサー、および既存のロガーへのブリッジが必要です。たとえば、Python の標準ライブラリでは LoggerProvider、OTLPLogExporter、ルートロガーに追加する LoggingHandler（既存レコードのトレース相関には LoggingInstrumentor も）が必要です。Node では @opentelemetry/sdk-logs とプロジェクトのロガー（pino／winston／bunyan）向けの計装が必要です。@vercel/otel では logRecordProcessor(s) オプションが必要です。これを指定しないと、ログはプロセス外に送信されません。各スタックで必要な要素の詳細は、対応するスタイルスキルを参照してください。

ログブリッジでよくある問題を、必ず確認してください。

• アプリがルートロガーを使っているのに、名前付きロガーにハンドラーを追加している（またはその逆）ため、何も流れない。
• デフォルトのレベルフィルター（例：WARNING）が、ユーザーが Superlog で確認したい INFO／DEBUG の行を取りこぼしている。
• シャットダウン時に BatchLogRecordProcessor がフラッシュされず、短時間で終了する CLI、サーバーレス、エッジ関数で最後のバッチが失われる。ランタイムの終了フックに shutdown()／forceFlush() を接続してください。
• 既存のベンダー向けトランスポート（Pino → Logtail、Winston → Datadog など）を残しても問題ありません。むしろ想定どおりです。ただし、別のフォーマッターで同じ行を二重送信する第 2 のトランスポートを追加するのではなく、ロガーからブリッジするようにしてください。
• スパン外で出力されたログには trace_id / span_id が付きません。これは正しく、想定どおりです。ログ呼び出しの前後に使い捨てのスパンを開始して「修正」しないでください。

ブートストラップのルール：

• ブートストラップファイルは、フレームワークのインポートより前に実行する必要があります。言語／フレームワークで文書化されているフック（--import フラグ、instrumentation.ts、main.py の先頭でのインポートなど）を使ってください。
• エンドポイント（https://intake.superlog.sh）と公開インジェストトークンは、ブートストラップのソースに直接記述してください。process.env.OTEL_EXPORTER_OTLP_* から読み込んだり、.env ファイルを作成したりしないでください。（各スタックでの正確な形式は、フレームワーク固有のスタイルスキルを参照してください。）
• gRPC ではなく、HTTP OTLP エクスポーターを使用してください。gRPC はネイティブバインディングを取り込み、バンドラーの動作を妨げ、コンテナーを複雑にします。
• プロジェクトで既に使われているパッケージマネージャーを使用してください（ロックファイルから判別してください）。
• 冪等性のある編集を優先してください。設定ファイルがすでにある場合は、上書きせずに編集してください。
• すべてのサービスについて、OTel リソースに次のリソース属性を設定してください：service.name、service.version、deployment.environment.name、および vcs.repository.url.full（リポジトリの正規の HTTPS URL。例：https://github.com/acme/api）。リポジトリ URL は重要です。SDK 初期化時に service.name とともにハードコードして問題ありません。ビルドプラットフォームからスラッグを取得できる場合（Vercel の VERCEL_GIT_REPO_OWNER／VERCEL_GIT_REPO_SLUG、Railway の RAILWAY_GIT_REPO_OWNER／RAILWAY_GIT_REPO_NAME）は、環境変数から取得する方法を優先してください。また、ランタイムがすでに設定している環境変数（VERCEL_GIT_COMMIT_SHA、RAILWAY_GIT_COMMIT_SHA、GITHUB_SHA、SOURCE_COMMIT、GIT_COMMIT、HEROKU_SLUG_COMMIT、…）から、可能な範囲で vcs.ref.head.revision（コミット SHA）も設定してください。実行中のプロセスから git を呼び出さないでください。SHA を省略するのは問題ありませんが、URL の省略は不可です。OTel のセマンティック規約のキーを正確に使用してください。git.repo や app.repo_url のような独自のキーを作らないでください。 フレームワーク別のルール：
• Next.js/Vercel： ブートストラップには instrumentation.ts の @vercel/otel registerOTel(...) を使用してください。リポジトリですでにそのアーキテクチャが使われており、それを拡張する場合を除き、代わりに @opentelemetry/sdk-node / NodeSDK を直接使ったブートストラップを使用しないでください。ルートハンドラー内で @opentelemetry/api のトレーサー／メーターを使うのは、自動計装ではカバーできない箇所に限ってください。registerOTel はデフォルトではログをエクスポートしません — @opentelemetry/exporter-logs-otlp-http の OTLPLogExporter を指定して、logRecordProcessor（v1）／logRecordProcessors（v2）を渡してください。渡さない場合、ログはプロセスの外に出ません。インストールされている @vercel/otel のメジャーバージョンに合わせてオプション名を指定してください。
• Expo/React Native： 既存の Expo Go／非対応ランタイム向けガードを維持してください。対応ビルドでは、Sentry の初期化およびアプリ登録／ユーザーコードの実行より前に initObservability() を呼び出してください。オブザーバビリティモジュールにエンドポイントと sl_public_ トークンを直接記述してください。Superlog には EXPO_PUBLIC_* 環境変数を使用しないでください。
• Supabase Edge Functions： 現在、ホスト型 Supabase Edge では Deno ネイティブの OpenTelemetry は動作しません。上記の軽量な OTel 形式のシムパターンを使用してください。エクスポーターのエンドポイント／ヘッダーは1か所のセットアップエリアにまとめ、Superlog 固有の関数名／ファイル名は避けてください。
• Python/FastAPI： リクエスト処理を手動ミドルウェアに置き換えるのではなく、FastAPIInstrumentor.instrument_app(app) などのネイティブ計装を使用してください。
• Python/LiveKit： シャットダウンコールバックをまたぐライフサイクルスパンには、start_span と trace.use_span(..., end_on_exit=False) を使用し、シャットダウンコールバックで終了できます。処理範囲が限定された作業には、引き続きデコレーターまたはコンテキストマネージャーを使用してください。

既存のオブザーバビリティベンダーとの併用を前提にしてください。Sentry、Datadog、New Relic、Honeycomb、Logtail、Pino のトランスポートなどを削除しないでください。 OTel はそれらと併用します。移行中も両方のシグナルを流したいというのがユーザーの明確な要望です。既存ベンダーの仕組みを取り除くかどうかを決めるのは、あなたではありません。

ステップ 3 — ビジネス処理の周囲にカスタムスパン、メトリクス、ログを追加する

自動計装で取得できるのは、HTTP の送受信、DB クエリ、フレームワークのライフサイクルです。これは最低限であり、これだけで十分というわけではありません。問題が発生した際に、人が実際に確認したい処理を見つけるためにプロジェクトを調査してください。

トレース

重要なビジネス処理はすべてアクティブスパンで囲んでください。自動計装されたスパンがある箇所ではそれを使用して構いませんが、まだスパンが付いていない処理には追加してください。

• 命名規則：domain.verb（order.process、payment.charge、email.send、agent.run、interview.create、job.<type>）。

• 属性：エンティティ ID（order.id、user.id、workspace.id、tenant.id）、件数、重要な分岐の結果を示す真偽値、LLM 呼び出しのモデル名／プロバイダー。

• 例外を記録してください：失敗時には span.recordException(err) と span.setStatus({ code: ERROR }) を呼び出します。

• 境界が明確な Python 関数では、@tracer.start_as_current_span("operation.name") を優先してください。同じ呼び出しをデコレーターとコンテキストマネージャーの両方として使えます。関数全体に適用する場合は、通常デコレーター形式が適しています。

  @tracer.start_as_current_span("do_work")
  def do_work():
      print("doing some work...")
  

  デコレーターが適さない場合（部分的な範囲、動的なスパン名など）には、コンテキストマネージャーを使用してください。処理範囲が限定された作業に、分離された start_span() と手動の end() を使用しないでください。

• 単純なゲッター、純粋な変換、内部ヘルパーなど、実際のレイテンシーや失敗要因がないものは対象外にしてください。

• 属性に PII を含めないでください（メールアドレス、パスワード、トークン、リクエスト本文全体など）。

ログ

ログが構造化され、処理のコンテキストを持つようにしてください。具体的には、スパン内で出力されたすべてのログ行について、trace_id／span_id が設定され、構造化フィールド（orderId、userId など）が属性として保持された状態で Superlog に届く必要があります。トレース／スパンのコンテキストは、ログブリッジやインテグレーションでネイティブに追加できる場合もあれば、追加の作業が必要な場合もあります。

状況の説明（「バッチ処理の照合を開始」「3xx の後に再試行」など）や例外イベントにはログを使用してください。エラーログを出力するのは、処理を回復できず、手動での介入が必要な場合に限ってください。

メトリクス

ビジネス＋パフォーマンス＋コストをカバーします。確認するカテゴリは3つです。

• ビジネスロジックのカウンター。 意味のある状態遷移をすべて記録します。作成、開始、完了、失敗、再試行などです。テナント別、チャネル別、ステータス別など、カーディナリティの低いディメンションのみを使います（ユーザー ID や注文 ID は使いません）。
• パフォーマンスのヒストグラム。 ユーザーが気にする操作のレイテンシ、キューの深さ、バッチサイズ、ペイロードサイズを記録します。プロジェクトに既存の計測機能（time.perf_counter ブロック、カスタムの LatencyTracker、"[TIMING]" ログ行など）がある場合は、それを再利用します。二重に計測するのではなく、既存の測定値からヒストグラムを出力します。
• コスト — 特に LLM のコスト。 プロジェクトが OpenAI／Anthropic／Google／その他の LLM プロバイダーを呼び出す場合は、利用可能であれば OpenInference などのプロバイダー計装を優先し、ネイティブ SDK の呼び出しを読みやすい状態に保ちます。プロダクトハンドラーに料金の定数や LLM コスト計算を追加しないでください。Superlog は、取得したプロバイダー／モデル／トークン属性を使って、UI／クエリレイヤーで推定コストを一元的に計算します。プロバイダー計装ですでに取得されているトークンカウンターを重複させないでください。

メーターはモジュールレベルで一度だけ取得し、計装もモジュールレベルで作成して、ホットパスでインクリメントします。呼び出しごとに新しいメーターを作成しないでください。

Step 4 — アプリが引き続き動作することを確認する

サービスごとに、次の手順を実行します。

1. プロジェクト独自の開発用またはビルド用コマンドを実行します（package.json／pyproject／Makefile ですでに設定されているもの）。OTel のインストールに起因するエラーなく起動することを確認します。また、アプリをインポートまたは起動するテレメトリのブートストラップスモークテストも実行し、プロバイダーの設定、エクスポーターの構築、ログブリッジ、フレームワーク計装がすべて初期化されることを確認します。Python サーバーの場合は、uv run python -c 'from app.main import app; print(app.title)' のようなインポート／起動コマンドを使えます。Node／Next の場合は、リポジトリのビルド／起動手順を使います。サーバーの場合は、curl で少なくとも1つのルートにアクセスして、計装を通じてトラフィックが流れることを確認します。可能であれば、静的なヘルスチェックルートだけでなく、計装された操作を実行するルートを選んでください。CLI の場合は、実際のコマンドを実行します。アプリ本来の起動が壊れた状態でリリースしないでください。これはリグレッションです。

2. 本番環境に実際のテレメトリを送信し、3つすべてのシグナルについてレスポンスコードを確認します。 これは必須条件です。実行中のアプリに少なくとも1つのスパン、ログ、メトリクスを実際に出力させ、OTLP エクスポーターによる /v1/traces、/v1/logs、/v1/metrics への HTTP レスポンスを確認します。特にログの経路を確かめるには、計装された操作内でプロジェクトのロガーを呼び出すルートにアクセスする（または CLI コマンドを実行する）必要があります。取り込み元からのレスポンスステータスが判定基準です。

   • 3つすべてが 2xx を返す → 完了です。 サインアップはすでに確認済みです。Step 5 に進みます。ユーザーにサインアップのタブへ戻るよう促さないでください。
   • いずれかが 401／403 を返す → トークンがまだ有効になっていません。 Step 0 の URL でサインアップを完了するようユーザーに伝えます（タブはすでに開いています）。確認が取れたら、スモークテストを再実行し、3つすべてで 2xx が確認できるまで再確認します。401／403 のまま成功と判定しないでください。
   • いずれかが 5xx を返す、タイムアウトする、または POST が行われない → 実際の不具合です。 先に進む前にデバッグしてください。/v1/traces しか確認できない場合、ログブリッジが接続されていません（最も一般的な原因は、LoggerProvider が設定されていない、誤ったロガーにハンドラーが接続されている、レベルフィルターが厳しすぎる、@vercel/otel に logRecordProcessor(s) がない、またはシャットダウン時にバッチプロセッサーがフラッシュされていないことです）。/v1/metrics が見つからない場合は、メータープロバイダーまたは定期リーダーが接続されていません。

ブートストラップが読み込まれても POST が行われない場合や、スパンは POST されてもログ／メトリクスが POST されない場合は、部分的な成功ではありません。先に進む前に修正してください。

Step 5 — 引き継ぎ（ユーザーへの最終メッセージ）

この手順に進めるのは、Step 4 で /v1/traces、/v1/logs、/v1/metrics から 2xx が返った場合のみです。トークンはすでにブートストラップのソースに埋め込まれています。チャットに再掲しないでください。テレメトリはユーザーのプロジェクトに流れています。次に必要なのはデプロイです。

変更内容

3～7個の短い事実ベースの箇条書きで、インストールしたパッケージ、作成・変更したファイル、追加したビジネススパン／メトリクスを説明します。サービスごとに変更が異なる場合はサービスごとに、同じ場合はまとめて記載します。既存のオブザーバビリティベンダー（Sentry、Datadog、Logtail、Pino transports など）を意図的に残した場合は、併用することが明確になるように記載します。

デプロイ

「いつもどおりデプロイしてください」で終わらせず、今すぐデプロイに進めるようにします。リポジトリから最も可能性の高いデプロイ方法を推測し、具体的な次のアクションを1つ提示します。

• リポジトリに直接デプロイするためのツール／設定（vercel.json、netlify.toml、fly.toml、wrangler.*、railway.json、render.yaml、Dockerfile、package.json 内のデプロイスクリプトなど）がある場合は、デプロイ先を示し、本番環境／公開環境へのデプロイコマンドを実行する前に確認を求めます。「<command> を使って <target> に今すぐデプロイできます。実行しますか？」と伝えます。ユーザーが承諾した場合は実行し、結果を確認します。
• デプロイが CI によるプッシュ／マージ時に行われる場合は、そのことを明確に伝え、ユーザーに必要な次の手順を具体的に示します。ブランチのコミット／プッシュ／マージ、または既存のホスティングダッシュボードを開くよう案内します。以下の厳格なルールを守ってください。このスキルの実行中に、ユーザーがスキル外で明示的にその作業を依頼しない限り、コミット、プッシュ、PR の作成は行わないでください。
• 本番環境へのデプロイ方法を特定できない場合は、代替として最適なローカル実行方法を提案します。開発サーバーを起動し、計測対象のルートにアクセスし、実行した正確なコマンドと、見つけられなかった本番デプロイ情報をユーザーに伝えます。
• デプロイまたはローカル実行の後、デプロイ環境からもトレース／ログ／メトリクスが送信されるよう、少なくとも1つの計測対象ルートにアクセスします。

Superlog の環境変数を設定する必要はありません。エンドポイントと公開トークンはブートストラップのソースに含まれています。

Step 6 — MCP の提案

エージェントから GitHub や Slack を手動で操作することは、もうユーザーに求めないでください。サインアップ時のインテントページが認証後に両方の連携を処理します。ユーザーが GitHub でサインインした場合は、アプリに適切なリポジトリ権限があることも引き続き確認します。

次回のデバッグ時にエージェント（Claude Code、Codex、Cursor など）がテレメトリを直接照会できるよう、Superlog MCP サーバーのインストールを提案します。ダッシュボードに切り替えることなく、チャット内からログを検索し、トレースを取得し、エラー率を確認できます。

Claude Code（最も一般的です。このスキルも Claude Code で実行されています）の場合は、代わりに実行することを提案します。

claude mcp add --transport http superlog https://api.superlog.sh/mcp

この操作ではユーザーの Claude Code 設定を編集します。実行前に確認してください（ユーザーが独自の MCP スコープを設定している場合や、別の場所にインストールしたい場合があります）。ユーザーが断った場合は、後で自分で実行できるようにコマンドを表示します。

ユーザーが使用する可能性のある他のエージェントについては、案内だけにとどめ、実行しないでください。

• Codex：codex mcp add superlog --url https://api.superlog.sh/mcp && codex mcp login superlog
• Cursor など：https://superlog.sh/ → Connect から mcpServers のスニペットをコピーします。

最後は、アプリをデプロイするよう促す一文で締めくくります。すぐにリリースできます。

厳格なルール

• プロジェクトのルートディレクトリ外のファイルは変更しないでください。
• コミット、プッシュ、PR の作成はしないでください。
• 正確なコマンドとデプロイ先を提示したうえで、ユーザーから明示的な確認を得るまでは、本番環境／公開環境へのデプロイコマンドを実行しないでください。
• インラインで指定してよいのは sl_public_ で始まる公開インジェストトークンのみです。アカウント／セッション／管理者トークン、秘密鍵、プロバイダー API キーはインラインで指定しないでください。完全なトークンをチャットに表示しないでください。
• 既存のオブザーバビリティベンダーは、ユーザーから削除を依頼されない限り削除しないでください。
• プロジェクトで既に使われているパッケージマネージャーとロガーを使用してください。
• 言語に対応したネイティブの OTel パッケージを優先してください。SDK が既に提供しているテレメトリの仕組みを独自に作り直さないでください。
• 計測処理が原因で開発／ビルドコマンドがエラーになった場合は、失敗として扱います。問題を修正するか、報告してください。問題を取り繕わないでください。