- はじめに
- テックタッチの EO ってどんな仕事？
- 【最近の業務実例】claude.ai コスト可視化に向けたリサーチと技術検証をもとに判断支援した話
- 上記をもとに構成案を整理（中継層なしの最小構成）
- 構成を実現するためのClaude側のテレメトリに関する技術仕様を確認
- コスト試算もしてみる
- 結果：izzii への引き渡し
- おわりに
- 最後に
はじめに
Engineering Office （ 以下 EO ）でマネージャーをしている kirai です。
この記事では、「テックタッチ」の Engineering Office （ EO ） がどのように仕事を進めているのかを、直近の実例を交えてご紹介します。 今回は、弊社の AI サービスコスト管理の運用一環として取り組んだ「claude.ai のユーザー別コスト可視化」の調査・提案の様子を紹介したいと思います。
テックタッチの EO ってどんな仕事？
EO の役割概要
「テックタッチ」では2025年より「AI 駆動経営」を掲げ、AI を前提としたエンジニアリング組織の運営基盤を整備する EO を2026年5月に新設しました。
（私自身のEO業務としては2026年1月よりスタート）
EO のミッションは、AI を前提としたエンジニアリング組織の運営基盤を整備し、各マネージャーが適切な情報・権限・ガードレールのもとで、人・投資・技術・AI 活用を高品質に判断できる状態をつくることです。
現在の活動領域は大きく3つとなります。
| カテゴリ | 主な活動 |
|---|---|
| マネージャー・リーダー支援 | 意思決定に必要な情報の提示と論点整理、会議体設計を通じたスムーズな合意形成支援 |
| タレント運用（HRBP 業務） | HR 部門と協働したエンジニアリング組織の人材運用支援、オンボーディング整備 |
| AI リソース運用 | AI 利用費・予算進捗の可視化と ROI に基づく投資判断の支援、利用ルール整備 |
テックタッチのEO では、「最終決定権を持たない役割」 として設計しています。 「判断するのは各 HEAD / 部門マネージャー、EO は判断材料と論点整理を提供する」という役割分担となっています。
EO として大事にしている3つの設計原則
仕事を進める際に大事にしている設計原則が3つあります。 後半で紹介する業務実例でも、この3原則を意識しながら進めました。
- 代行ではなく標準化
- 人手で肩代わりするのではなく、レビュー観点・ダッシュボード・ルールに落として、誰でも回せる状態にします。
- 統制ではなく判断支援
- 最終判断はマネージャー・責任者に残し、EO は判断材料と論点整理を提供します。
- 便利屋ではなく再現性
- 属人的な個人依存を減らし、組織として再現可能な仕組みとして残します。
【最近の業務実例】claude.ai コスト可視化に向けたリサーチと技術検証をもとに判断支援した話
きっかけ
昨今、どの会社でもAIサービスの利用が急速に進んでいるかと思います。 弊社のCTO からも、「会社全体の AI サービスへのコスト支出をより精緻に把握できるようにしたい」と要望を受けたところから始まりました。
EO として課題を引き取る
弊社では、Security and Reliability Division （ 以下、SR Div ）の HEAD の 市川（ 以下、izzii ）が、社内の AI サービス利用コストを取りまとめており、まずは状況把握から開始しました。
izzii と確認を進めていく中で分かったのが、Anthropic の「サブスクリプション（ Team Plan ）契約」では、Admin Console から 組織全体やプロダクト別の支出は見えるものの、個別ユーザー単位の利用状況やコストを精緻に把握できない ※1 ことでした。
izzii の方でも、コストの見える化に向けていくつかアイディアはあったものの、まだ調査や確認が進められていない状況でした。 そこで、EO として支援できそうな領域だと思い、リサーチを私が引き取り、izzii に共有できるよう準備をすすめました。
EO の設計原則「統制ではなく判断支援」とある通り、izzii が判断を下しやすい情報を整理する目的が、今回のスタートとなりました。
※1 Anthropic: Claude Code and new admin controls for business plans
Claude と一緒に整理した、izzii に渡すべき情報について
リサーチを進めるにあたって、まず 「izzii にとって嬉しい情報は何か」 を相棒となる Claude と一緒に整理しました。
テックタッチとして嬉しい条件を整理
izzii は SRE / 情シスの HEAD を務めているので、下記の観点の情報はほしいと思い整理しました。
- データレジデンシーの観点からデータが国内で保管されること
- テレメトリの中身を最小限にすること
- プロンプト本文やツール詳細など機密性の高い情報は送信せず、コスト分析に必要な情報のみに絞ること。
- 最小コスト・最小構成であること
- 「見える化のためのコストをかけすぎない」（既存サービスを流用）
- 維持管理の負担が小さい構成となること。
- また、Anthropic 側の機能改善によりコストの可視化が行える可能性もあるため、移行しやすい・捨てやすい構成を考慮すること。
国内の手法をリサーチ
上記の条件を軸に、Claude の Deep Research / Web Search を活用して、AWS や Anthropic のドキュメント、各社の技術記事をリサーチしました。 2026年3月〜4月時点で AI が整理してくれた選択肢は以下の3パターンでした。
- OTel Collector 中継方式（ECS / EC2 / EKS 等）
- API Gateway 中継方式
- GCP の Cloud Run + BigQuery
当時のリサーチ結果では「東京リージョンの CloudWatch Logs は OTLP / Bearer Token 直送に対応していない ※2 ※3 ※4」と結果が出力された事もあり
当初は「API Gateway 中継方式」の方向で整理を進めていました。
※2 Amazon CloudWatch Logs が HTTP ベースのプロトコルを使用したログ取り込みのサポートを開始（2026/3/16）
※3 Classmethod: Claude の OTel を CloudWatch に OTLP で Collector なしに送る
※4 sjramblings.io: CloudWatch Logs HTTP Endpoints
よもやま話：実機で確かめたら、東京でも CloudWatch へテレメトリが直送ができた話
AIのリサーチ結果と並行して、CloudWatch の現状を把握したくなり、実際に自分の目でも実機環境の確認を進めていました。
弊社では、AWS の技術調査等をエンジニアが自由に行える、「Sandbox」環境をSRE チームが用意してくれており、早速確認してみたところ…。
実は、東京リージョンのCloudWatch のロググループの「アクション」メニューを見ると、「ベアラートークン認証設定」がメニューに存在している事に気づきました。
Claude のリサーチ結果だけでは、東京リージョンは対応していないと判断しそうになりましたが 実機環境上では利用出来そうだったため、提案の方針を変えて実際に検証を行うことにしました。
CloudWatchへのOtelでのテレメトリ直送が提案できるか技術検証の概要
最初の技術検証の手順は図の通り、CloudWatch 側での環境が整ったらまずは「PowerShell」で疎通できるか確認をしてみることにしました。
AWS での検証概要
AWS へログインを行ったら下記の作業を行います。
- 東京リージョンの CloudWatch でロググループとログストリームを作成
- 今回は検証目的のためログクラスは Standard、保持期間は1日で設定で大丈夫
- 「アクション」→「ベアラートークン認証設定」を有効化
- 「ベアラートークン認証ステータスが正常に更新されました」のメッセージを確認
- CloudWatchのサイドパネルから「セットアップ」→「設定」→「ログタブを選択」→「API キー」 から"作成"でキーを発行
- 1日の期限で発行
- 出力されたキーは後続で利用するので控えておく
PowerShell を使って CloudWatch へのログ送信作業概要
CloudWatch の環境準備が整い、API キーが取得できたら、PC 上で PowerShell のコードを実行します。 コードの結果が正常に終了したら、再度 CloudWatch の管理画面にアクセスして、ログが記録されているか確認します。
- PowerShell から OTLP / JSON で疎通テスト
- 実際にイベントを送信してコマンド上で「200 OK」 を確認
※参考: PowerShellで疎通確認する際のコード
# === 設定 ===
$endpoint = "https://logs.ap-northeast-1.amazonaws.com/v1/logs"
$logGroup = "＜ロググループ名＞"
$logStream = "＜ログストリーム名＞"
$apiKey = "＜API Key＞"
# === タイムスタンプ（ナノ秒）===
$timestampNano = [int64]([DateTime]::UtcNow - (Get-Date "1970-01-01")).TotalMilliseconds * 1000000
# === OTLP/JSON ペイロード ===
$body = @{
resourceLogs = @(@{
resource = @{
attributes = @(
@{ key = "service.name"; value = @{ stringValue = "blog-test" } }
)
}
scopeLogs = @(@{
logRecords = @(@{
timeUnixNano = "$timestampNano"
severityNumber = 9
severityText = "INFO"
body = @{ stringValue = "Hello from PowerShell - blog test message" }
})
})
})
} | ConvertTo-Json -Depth 10 -Compress
# === ヘッダー ===
$headers = @{
"Authorization" = "Bearer $apiKey"
"Content-Type" = "application/json"
"x-aws-log-group" = $logGroup
"x-aws-log-stream" = $logStream
}
# === 送信 ===
Invoke-WebRequest -Uri $endpoint -Method POST -Headers $headers -Body $body
検証の結果、東京リージョンで HTTP 200 OK を確認し、Bearer Token を使ったCloudWatch へのデータ直送が動く事が確認できました ※5。
AWS What's New の公式発表は US リージョンのみの記載でしたが、検証を行った2026/05月時点では AWS Docs からはリージョン制限の記述が消えており、サイレントロールアウトが行われていたようです。
今回は AI を鵜呑みにせず、自分の目で実環境を確かめて良かったケースとなりました！
この発見によって、東京リージョンでの 最小構成で提案できる事が分かりました。
※5 AWS Docs: CloudWatch Logs OTLP エンドポイント Bearer Token 認証
上記をもとに構成案を整理（中継層なしの最小構成）
実機検証で「東京リージョンの CloudWatch へ OTel でデータ直送が動く」事が確認できたので、提案アイディアとして中継層なしの 3層構造のアイディア構成を取りまとめました。
- ① アクティブ層（CloudWatch Logs、30日 rolling）
- OTel テレメトリを東京リージョンの CloudWatch Logs に直送。Infrequent Access（ IA ）ログクラスにすると、 Standard から ingest コストを50%削減できます ※6。
- ② 集計層（Google Spreadsheet、永久蓄積）
- GAS の日次バッチで Logs Insights クエリを実行し、集計後の数値のみを Spreadsheet に追記。Google Workspace 内で完結するため追加課金なし。
- ③ アーカイブ層（S3 Glacier Deep Archive、永久蓄積）
- EventBridge Scheduler + Lambda + CreateExportTask で日次 S3 エクスポート。
※6 AWS Docs: Logs Insights QL commands supported in log classes
構成を実現するためのClaude側のテレメトリに関する技術仕様を確認
構成案を実装に落とすうえで必要なClaude側のテレメトリ仕様も、相棒の Claude と一緒に確認しました。 テレメトリの仕様を整理すると下記となります。
- claude.ai のうち、個別ユーザー単位の可視化に対応する OTel テレメトリ送信機能を備えているのは Claude Code と Claude Cowork のみで、Claude（Chat）は現時点で未対応
- Claude Cowork は、 Anthropic の管理画面から OTel エンドポイントの設定が可能
- PC 側の
~/.claude/settings.jsonでは制御できないため、管理画面で設定すると利用者全員に設定が配布されることに注意
- PC 側の
- Claude Code は、 Anthropic の管理画面（ Server-managed settings ）で設定、または個人設定の
~/.claude/settings.jsonへの直接編集、または管理者配布のmanaged-settings.json（MDM 等で配布）の3経路がある - 環境変数
OTEL_LOG_USER_PROMPTS/OTEL_LOG_TOOL_DETAILSを未設定（デフォルト）にすると、プロンプト本文やツール詳細は送信されず、コスト分析に必要な最低限の情報のみが CloudWatch Logs に届く
今回の検証では、組織展開時に MDM 経由等で配布しやすい settings.json 方式を前提に検討しました。
⚠️ 注意: 複数の設定源がある場合、下記の優先順位となります ① Server-managed settings（remote-settings.json）- Anthropic の管理画面で配信 ② managed-settings.json - MDM 等で配信 ③ ~/.claude/settings.json - 個人設定 上位が存在する場合、下位の設定は上書きされます。 そのため、ローカルの settings.json で環境変数を設定しても、管理者が組織レベルで 配信した設定があれば、そちらが優先されることに注意してください。 もし、本記事のように、settings.jsonを使ってテレメトリ送信の検証設定を行う場合 会社から「remote-settings.json」や「managed-settings.json」が配信されていないか 事前に確認してから進めてください。
コスト可視化に必要な Claude 側の設定確認
次に、実際にOtelを使ってClaudeがテレメトリを送信する際に必要な設定（環境変数）について、仕様を整理しました。 コスト可視化だけであれば必要な設定は下記のみとなります。
| 環境変数 | 役割 |
|---|---|
| CLAUDE_CODE_ENABLE_TELEMETRY=1 | テレメトリ送信を有効化する起点となる設定。 |
| OTEL_LOGS_EXPORTER=otlp | OTLP プロトコルで送信する宣言 |
| OTEL_EXPORTER_OTLP_PROTOCOL=http/json | HTTP / JSON 形式を指定 |
| OTEL_EXPORTER_OTLP_ENDPOINT | 送信先（今回は東京リージョンの CloudWatch Logs ） |
| OTEL_EXPORTER_OTLP_HEADERS | Bearer Token 認証、ロググループ、ログストリームを指定 |
Claude Code 側の settings.json はこのような形になります ※7：
"env": { "CLAUDE_CODE_ENABLE_TELEMETRY": "1", "OTEL_LOGS_EXPORTER": "otlp", "OTEL_EXPORTER_OTLP_PROTOCOL": "http/json", "OTEL_EXPORTER_OTLP_ENDPOINT": "https://logs.ap-northeast-1.amazonaws.com", "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer <api key>,x-aws-log-group=<log group name>,x-aws-log-stream=<log stream name>" }
※7 Claude Code 公式ドキュメント: Managed Settings
実際にCloudWatchで記録されるテレメトリの例が下記となります。
{ "@timestamp": "2026-05-XX XX:XX:XX", "resource": { "attributes": { "service.name": "claude-code", "service.version": "2.1.128", "os.type": "windows" } }, "body": "claude_code.api_request", "attributes": { "cost_usd": 0.000465, "model": "claude-haiku-4-5-20251001", "input_tokens": 375, "output_tokens": 18, "duration_ms": 999, "user.email": "[REDACTED]", "session.id": "[REDACTED]" } }
VS Code と Claude.aiのデスクトップアプリでの検証
実際に、VS Codeの拡張機能と claude.ai のデスクトップアプリ経由で、CloudWatchへテレメトリが直送されるか技術検証を行いました。
前段の検証で利用したCloudWatchの情報（APIキー・ロググループ・ログストリーム）をsettings.jsonに登録して、両者のツールからClaudeとやりとりしたところ
いずれも、下記の通りCloudWatchの送信先へテレメトリが直送されることを確認出来ました！
VS Code 拡張経由での動作検証の様子
※VS Code拡張経由の場合「claude-code」と認識していることや、利用モデル、tokenとコストを CloudWatch 側で確認。
claude.aiの「Code」での動作検証の様子
※「claude-code-desktop」と認識していることや、利用モデル、tokenとコストを CloudWatch 側で確認。
cost_usd と user.email が同じイベントに乗っているため、テレメトリを集計するだけで 個別ユーザー単位のコストが集計できることが把握できました。
コスト試算もしてみる
最後に、取りまとめた3層構成のコスト感を、当時 claude.ai を利用していたプロダクト組織のメンバー数を仮置きして試算しました。 ※8
上記の図の通り、当時 claude.ai を利用していたプロダクト組織のメンバー数を仮置きして、IA / Standard 両ログクラスで試算しました。
当時の利用メンバー14名で 月額 ¥7（IA） / ¥12（Standard）程となり、将来的な最大想定の150名でも 月額 ¥82（IA） / ¥137（Standard）程でした。
5年累計では、 ¥4,905（IA） / ¥8,205（Standard）程 という規模感になりました。
試算結果からみると「見える化のためのコストをかけすぎない」を実現できる構成案だったことが、最終的に整理できました。
※8 コスト試算は以下の AWS 公式料金ページ（アジアパシフィック 東京リージョン、2026年5月時点）を参照: CloudWatch Pricing / S3 Pricing / Lambda Pricing / EventBridge Pricing / Athena Pricing
結果：izzii への引き渡し
今回の検証内容を、claude.ai の Project 機能を活用して取りまとめました。
リサーチ過程・検証手順・構成案・コスト試算を一箇所に集約し、izzii へ最終的に連携。
連携した情報をベースに、izzii が 環境構築と展開方法を巻き取って進めてくれました。
自分も kirai さんの設計をベースに terraform でインフラ作って claude.ai のコスト集計機構の動作確認しました！ あとは自分で巻き取って展開進めていきます！
（Slack より、本人の許諾を得て引用）
おわりに
ここまで読んでいただきありがとうございました。
弊社では AI 駆動を掲げ、ビジネスサイド・プロダクトサイド共に AI を前提とした業務推進を行っています。
今回のように AI のリサーチ結果を鵜呑みにすると、本来目指したかった姿にたどり着けなかった可能性もあります。
AI 駆動前提におけるリスクと、自分の目と手で実環境を確認することの大切さを改めて実感した調査でした。
なお、Claude Cowork については、管理画面で OTel 設定を有効にすると組織全体に反映される仕様のため、今回の個人検証スコープからは外しています。こちらは izzii の方で組織展開と合わせて確認する予定です。
最後に
最後に少しだけ EO 職の紹介となりますが、「テックタッチ」では2025年より 「 AI 駆動経営」 を掲げ、AI を前提としたエンジニアリング組織の運営基盤を整備する Engineering Office （ EO ） を2026年5月に新設しました。
EO は戦略立案だけでなく、今回の記事のように 自ら手を動かして実機検証まで降りていく スタイルで、マネージャーやリーダーが適切な判断をできる状態をつくる事をミッションとしています。まさにこれから職種としての成果を出しながら、役割を洗練させていくフェーズです。
こうした仕事に興味を持っていただいたそこのあなた！ぜひ一度お話ししませんか？
