Apertureの仕組み

アイデンティティと認証・モデルによるルーティング・テレメトリのキャプチャ・セッションの追跡

最終検証日：2026年4月9日
翻訳: 竹洞 陽一郎

Aperture by Tailscaleは、現在ベータ版です。

Apertureは、すべてのAIリクエストを中央のプロキシ経由でルーティングし、組織にAI利用状況の一貫した可視性をもたらします。
このページでは、4つの中核的な仕組み、すなわちアイデンティティと認証、モデルによるリクエストのルーティング、テレメトリのキャプチャ、セッションの追跡について説明します。
これらが組み合わさることで、監査、コスト意識、運用上の洞察が可能になり、チームは安全にLLMクライアントを導入できます。

アイデンティティと認証

従来のAPIプロキシでは、クライアントはトークンやAPIキーで認証する必要があります。
Apertureは、Tailscaleのアイデンティティ層を使うことで、このステップをなくします。

tailnetへのすべての接続は、暗号学的なアイデンティティの証明を伴います。
リクエストがApertureに到着すると、プロキシはリモートIPアドレスを使ってTailscaleに問い合わせます。
Tailscaleは、ユーザーのログイン名（例: alice@example.com）、永続的なデバイス識別子、そのデバイスに割り当てられたタグを返します。

このアイデンティティは、クライアントからではなくTailscaleのコントロールプレーンから得られるため、信頼できます。
ユーザーは、Tailscaleの鍵交換を侵害しない限り、自分のアイデンティティを偽装できません。

このアイデンティティは、システム全体を通じて流れます。
すべてのメトリクスレコードには、ログイン名とデバイスIDが含まれます。
ダッシュボードはユーザーごとにフィルタリングします。
アクセス制御は、Tailscaleのタグから導出されたロールを使用します。

ts-unplugを使って接続するクライアントも、Tailscaleのアイデンティティを通じて認証されます。
各ts-unplugインスタンスは、それぞれ独自のデバイスとしてtailnetに参加するため、Apertureはts-unplugデバイスのログイン名でリクエストを識別します。
各人が自分専用のts-unplugインスタンスを実行する場合、Apertureはアクティビティを個々のユーザーに帰属させます。
複数人が1つのts-unplugインスタンスを共有する場合、すべてのアクティビティは同じアイデンティティの下に表示されます。

タグ付きデバイスのアイデンティティ

タグ付きのTailscaleデバイスがApertureに接続するとき、そのデバイスにはユーザーアカウントが関連付けられていません。
代わりにApertureは、デバイスのタグから合成的なアイデンティティ（synthetic identity）を作成します。

Apertureは、デバイスのタグをアルファベット順に並べ替え、カンマで連結して、安定したログイン名を作成します。
たとえば、tag:prod と tag:api のタグを持つデバイスは、ダッシュボード・ログ・セッション追跡において tag:api,tag:prod として表示されます。

デバイスにユーザープロファイルもタグもない場合、アイデンティティの解決は失敗し、そのデバイスはアクセスを拒否されます。

タグ付きデバイスにアクセスを許可するには、この合成アイデンティティをグラントの src フィールドで使用します（これは grants と temp_grants の両方に当てはまります。どちらも同じ src のJSONフィールドを使用し、一致の挙動も同一です）。

• tag:ci-runner を持つ単一タグのデバイス:

  "src": ["tag:ci-runner"]

• tag:api と tag:prod を持つ複数タグのデバイス:

  "src": ["tag:api,tag:prod"]

• タグ付きノードを含むすべてのノードに一致するワイルドカード:

  "src": ["*"]

正しいタグ文字列を見つける: ノードの正確なタグ文字列を確認するには、次の方法があります。

1. 一時的に src: ["*"] を設定してノードの接続を許可し、Apertureのダッシュボードで合成アイデンティティを確認したうえで、グラントを正確なタグ文字列に絞り込む。
2. ノードのタグをアルファベット順に並べ替え、カンマで連結して手動で構築する。
3. Tailscale管理コンソールでノードのタグを確認する。

タグ付きノードからのすべてのセッションが同じユーザーから来ているように見える場合は、トラブルシューティングガイドの「すべてのセッションが同じユーザーから来ているように見える」を参照してください。

モデルによるリクエストのルーティング

リクエストが到着すると、Apertureはリクエスト本文からモデル名（例: claude-sonnet-4-20250514 や gpt-4o）を抽出します。
プロキシは、どのプロバイダーがそのモデルを提供しているかを調べ、正しい認証ヘッダーを注入したうえで、リクエストをそのプロバイダーのAPIエンドポイントへ転送します。

クライアントから見ると、プロキシはあたかもLLMプロバイダー自体であるかのように見えます。
クライアントはプロキシのURLに接続し、標準的なAPIリクエストを送信します。
プロキシは、ルーティングを透過的に処理します。

次の表は、サポートされているAPI形式をまとめたものです。
互換性フラグを含むプロバイダーの詳細については、プロバイダー互換性リファレンスを参照してください。

テレメトリのキャプチャ

キャプチャシステムは、各LLMとのやり取りを再構築・分析するために必要なすべてを記録します。

• リクエストデータ: HTTPメソッド、パス、ヘッダー（機微な値はマスキング済み）、リクエスト本文全体。
• レスポンスデータ: ステータスコード、ヘッダー、レスポンス本文全体。
• 抽出されるメトリクス: 種類別（入力・出力・キャッシュ済み・推論）のトークン数、モデル名、リクエストの所要時間、ツール利用回数。
• セッションコンテキスト: Claude CodeやCodexなど、対応するプロバイダーやエージェントの関連リクエストを結びつけるセッションID。

プロキシは、レスポンス完了後にテレメトリを非同期で処理するため、クライアントは大きな遅延なくレスポンスを受け取ります。

プロキシは、2つの技術的な課題を透過的に処理します。

• 圧縮: プロキシは、圧縮された状態（gzip、deflate、Brotli）で到着したレスポンス本文を、保存する前に展開します。
• ストリーミング: ストリーミングレスポンス（Server-Sent Events）では、プロキシは一貫したメトリクス抽出のために、イベントストリームから完全なレスポンスオブジェクトを再構築します。

セッションの追跡

1つのコーディングタスクや会話は、通常、多数のLLMリクエストを伴います。
Claude Codeを使う開発者は、1つの問題をデバッグする間に50件以上のリクエストを生成することがあります。
グループ化しなければ、これらは50件の無関係なイベントとして表示されます。
セッションの追跡を使えば、これらは全体として分析できる1つのまとまりになります。

Apertureは、さまざまなクライアントの種類からセッション識別子を検出して、関連するリクエストをセッションごとにまとめます。
次の表は、各クライアントの種類がどのようにセッションを識別するかを示しています。

セッションによって、会話レベルの分析が可能になります。
Apertureダッシュボードの「ログ（Logs）」ページは、リクエストをセッションごとにまとめ、コーディングセッションやチャット会話の全体的なコンテキストを表示します。
リクエスト単位ではなく会話単位でトークンのコストを確認したり、コーディングアシスタントがタスクをどのように分解したかを追跡したり、どの会話が最も多くのリソースを消費したかを特定したりできます。

次のステップ

• Apertureを使い始める: サインアップ、プロバイダーの設定、最初のLLMクライアントの接続。
• AIアクセスを制御する: 各ユーザーがどのモデルにアクセスできるかを定義するグラントを設定する。
• AI利用状況を監視・エクスポートする: ダッシュボードにアクセスし、利用データをエクスポートする。