コンテンツにスキップ
Olivares AI docs

Claude Code を接続する（協調経路）

Claude Code は Olivares AI にとっての 正規の協調ソース です。実行するツールについて OpenTelemetry（OTLP）テレメトリを発し、対話する MCP サーバーは、ツールが read か write かについてのイントロスペクションヒント（readOnlyHint / destructiveHint）を公開します。 これらは合わせて、高忠実度かつエージェントに帰属したエッジで モジュール III — R/RW access map に供給し、permitted-vs-observed 像の協調的な半分を成します。

本ページはその経路を配線します。Claude Code の OTLP エクスポーターをエンジンのレシーバーに 向け、次にソースを宣言してそのテレメトリをアクセスエッジにします。一般的なソース配線の 仕組みと、これがどこに当てはまるかについては、Connect a source と アーキテクチャ概要 を参照してください。これが生む 正規化イベントの形については、イベントリファレンス を参照してください。

このソースから得られるもの

Section titled “このソースから得られるもの”

配線されると、Claude Code のテレメトリはエンジンのデータモデルに正規化され、 モジュール III に供給されます:

出力来歴備考
アクセスエッジ agent session → resource (read/write)シグナルソース otel信頼度 attributed — 起点は共有サービスアカウントではなく具体的なセッション
MCP サーバーエッジ session → MCP serverシグナルソース otelモード unknown（接続自体はアクセスではない。これはトポロジー/インベントリ）
MCP イントロスペクションからの R/RW ヒントシグナルソース mcp_annotation信頼できない — 裏付けシグナルであり、単独でエッジになることは決してない
コストサンプル（リクエスト単位のモデル使用量）api-request テレメトリaccess map ではなく FinOps に供給
finding（反回避）テレメトリのギャップ / 拒否されたツールまだアクティブなのに発信を止めたセッションはフラグされる

コネクタは read-first かつ最小データ です。関係（どのセッションがどのリソースに触れたか、 read か write か）を記録し、ペイロードは決して記録しません。生のツール入力やシェルコマンド — シークレットや PII を運びうる — は、観測になる前に秘匿化されたリソース参照に縮約されます。 その態勢が既定であり、いかなるコンテンツの保持も、明示的でカテゴリースコープのオプトインです。

配線の仕組み

Section titled “配線の仕組み”

2 つの半分があり、それらは Claude Code が動作するホスト上のループバックソケットで出会います。

  1. エンジンは OTLP レシーバーをコア取り込みとして公開します。 協調コネクタは Claude Code 自身の OpenTelemetry 出力向けに OTLP レシーバー（gRPC と HTTP）を実行し、 加えてそのツールフック用のエンドポイントを実行します。既定でループバックにバインド します — 協調取り込みは未認証なので、ホスト外から到達可能であってはなりません。ループバックに 留めてください。ホスト外のバックストップはカーネルコレクターであり、公開された OTLP ポートではありません。
  2. あなたは Claude Code の OTLP エクスポーターをそのレシーバーに向け 、ソースを宣言 して、 エンジンがあなたのテナント向けにそれを実行すべきだと知らせます。
  Claude Code (agent host)                 Olivares AI engine
  ┌──────────────────────────┐             ┌─────────────────────────────┐
  │ OTLP exporter            │── loopback ─▶│ cooperative OTLP receiver   │
  │ (OTEL_* env on the CLI)  │   (4317/4318)│ → normalize → access edges  │
  │ MCP servers (R/RW hints) │             │ → module III (R/RW map)     │
  └──────────────────────────┘             └─────────────────────────────┘

ステップ 1 — Claude Code をレシーバーに向ける

Section titled “ステップ 1 — Claude Code をレシーバーに向ける”

Claude Code は自身の OpenTelemetry 環境変数を通じて構成されます。エージェントホスト上で、 その OTLP エクスポートを有効化し、エンジンのループバックレシーバーに向けます。エンジンの レシーバーは標準の OpenTelemetry ポート（gRPC と HTTP）に従います。Claude Code の エクスポーターのエンドポイントを、対応するループバックアドレスとプロトコルに設定してください。

既定では、コネクタは 構造的 テレメトリのみ — セッションとアイデンティティの属性、ツール名、 R/RW モード、タイミング — を保持し、Claude Code がそれらを発するよう構成されていても、 プロンプトテキスト、ツール本体、生の API 本体は決して保持しません。コンテンツカテゴリーを 保持する特定の監査済みの理由がない限り、そのままにしてください。

ステップ 2 — ソースを宣言する

Section titled “ステップ 2 — ソースを宣言する”

実際の（デモではない）ソースは、OLIVARES_SOURCES_CONFIG 環境変数で名指される単一の オペレーター所有設定ファイルから配線され、エンジンが 起動前 に読みます。シークレットは そのオペレーターファイル内に値で存在し、ストアには決して入りません。各エントリはソース、 その kind、属するテナント、そしてソースごとの config ブロックを名指します:

{
  "sources": [
    {
      "name": "claude",
      "kind": "claude",
      "tenant": "<tenant-ref>",
      "config": {
        "grpc_addr": "127.0.0.1:4317"
      }
    }
  ]
}
  • name はこのソースインスタンスに対するあなたのラベルです。
  • kind は協調 Claude Code コネクタを選びます。
  • tenant はそれが生むすべてのエッジを 1 つのテナントにスコープします（モジュール III の 読み取りはテナントスコープかつ特権付きです）。
  • config はコネクタ自身の設定を保持します — 例えば OTLP レシーバーがバインドする ループバックアドレスです。コネクタはエージェントのものを借りるのではなく自身のレシーバーを バインドするため、Claude Code の OTEL 変数を無効化してもコレクターを黙って切ることは できません。

未構成または空のソースは失敗するのではなく正直に警告 します。未知の、埋め込まれていない、 またはロードに失敗する kind は起動時に報告され、決して黙って no-op に落とされません。ファイルを 編集した後は、コンポジションルートが再読込するようエンジンを再起動してください。

ステップ 3 — エッジが到着していることを検証する

Section titled “ステップ 3 — エッジが到着していることを検証する”

Claude Code がエクスポートしソースが宣言された状態で、リソースに触れる Claude Code セッション（ファイルを読む、コマンドを実行する、MCP ツールを呼ぶ）を実行し、それから access map を見てください。アクセスグラフの閲覧は 特権付き、テナントスコープ、監査対象の アクション です（editor ロール以上 — 最下位の viewer では決して不可）。そのため適切な ロールのトークンを使ってください:

  • アクセスグラフはモジュールルート /v1/m/accessmap/graph で提供されます。
  • permitted-vs-observed の結果 — least-privilege drift — は /v1/m/accessmap/drift にあります。

これらのモジュールルートは到達可能ですが、提供される OpenAPI ドキュメントには意図的に 含まれていません 。その契約は製品の型付き Go/TS インターフェースに存在します。新鮮な エンジンから投入済みグラフまでのエンドツーエンドの手順は、Zero to graph チュートリアル に従ってください。

シグナルソースが otel で、Claude Code セッションに帰属したエッジが見えるはずです。MCP イントロスペクションが R/RW ヒントを寄与した場合、それは別の mcp_annotation シグナルとして 到着し、エッジのモードを裏付けます — ただしそれ自体で確立はしません。

この経路の正直な限界

Section titled “この経路の正直な限界”
  • MCP 注釈は信頼できない。 readOnlyHint / destructiveHint は、サーバーが自身について 宣言する助言的ヒントです。MCP 仕様は、クライアントがそれらを信頼できないものとして扱わなければ ならないと述べています。製品はそれらを裏付けシグナルとして表面化し、信頼度を正直に示します — ヒントだけでエッジを「read-only」に格上げすることは決してありません。
  • 帰属はエージェント単位のアイデンティティに依存する。 エッジはセッションアイデンティティに 帰属します。1 つのサービスアカウントを共有するエージェントのプールは帰属を潰します。それを 解決するのはガバナンスの関心事（エージェント単位のアイデンティティを発行し強制する）であり、 このコネクタが捏造できるものではありません。
  • 協調的である。 エージェントが報告するものを見ます。決して発信しないエージェント、または エージェントの経路の外で起きる活動は、構造上このソースには見えません — それこそが、非協調の カーネルバックストップとストアネイティブ監査がこれと並んで存在する理由です。
  • 設計段階の深度。 プラットフォームの多くは pre-1.0 です。ここでの能力は検証済みの協調 取り込み経路として扱ってください。下流のモジュールやフィールドがまだ構築されていない場合、 製品はカバレッジを暗示するのではなくそう述べます。

次のステップ

Section titled “次のステップ”