Claude の Files API（ベータ機能、2025年4月公開）は、ファイルを一度アップロードして同一ワークスペース内の複数のAPIリクエストで再利用できる仕組みです。この記事では、GWS（Google Workspace）監査ログCSVをFile APIで対話的に分析する設計パターンと、Batch APIとの選択基準を整理します。
この記事を読んだほうが良い人
- GWS管理コンソールの監査ログを毎月手動確認・Excel整理している情シス担当者
- Claude APIを使った監査ログ分析に興味があるが、Batch APIのジョブ設計はハードルが高いと感じている方
- 今月のログを手軽に深掘りしてから、自動化の設計は後で考えたい方
Batch APIとFile APIの役割の違い
GWS監査ログをClaudeで分析する場合、大きく2種類のアプローチがあります。
まずBatch APIから整理します。前月分のログを月初に一括投入し、翌朝に結果を受け取る非同期処理です。Anthropic公式ドキュメントによると標準APIの50%のコストで利用でき、定型の月次レポート自動化に適しています。DRASENASではClaude Batch APIでGWS監査ログを月次分析するで設計手順を解説しています。
一方、File APIが向くのは「今月5月分のログ、権限変更が多い。誰が対象？時間帯は？業務時間外も含まれる？」という連続した問いで深掘りする探索フェーズです。ジョブ管理は不要で、その場でCSVをアップロードして質問を重ねるだけで始められます。
2つのアプローチは競合する関係ではなく、探索と自動化を補完する関係で使うのが実務的です。たとえば、Batch APIの定期レポートで「権限変更が先月比2倍」という数値が出た月に、File APIで「内訳は？誰が何を変更したか？業務時間外の操作はあったか？」と掘り下げる、という組み合わせが考えられます。深掘りの結果「この確認は毎月パターン化できる」と気づいたものからBatch APIのジョブに移植していくのが、無理のない自動化の進め方です。
| 観点 | File API | Batch API |
|---|---|---|
| 処理タイミング | リアルタイム（同期） | 非同期（最大24時間） |
| 主な用途 | 対話的な探索・深掘り | 定型の月次自動処理 |
| 設計コスト | 低（シンプルな実装） | 高（ジョブ管理が必要） |
| API費用 | 入力トークン標準料金 | 入力トークンの50% |
| 向くシーン | 「今月何があったか」を確認する一巡目 | 毎月同じ分析を自動実行 |
探索の結果「この確認はパターン化できる」と判断できたら、Batch APIで自動化に移行するのが実務的な流れです。
GWS監査ログCSVの準備
File APIで分析するには、まず管理コンソールから監査ログをCSVでエクスポートします。管理コンソールの「レポート」セクションから対象のログ種別（ログイン・管理・Drive・グループ等）を選択し、期間を指定してエクスポートを実行します。
ログ種別ごとに別ファイルとしてエクスポートされます。分析対象が「ログイン異常＋権限変更」のように複数にまたがる場合は、分析の冒頭でClaudeに「このCSVのカラム構成を教えて」と問うと、列名と先頭数行を把握した上で次の質問に答えてくれます。事前に構造を確認してからプロンプトを組み立てると、列名の指定がズレるミスを防げます。
大量イベントが発生した月は1ファイルあたり20,000行を超えることがあります。エクスポート時に期間を2週間単位に分割するか、イベント種別でフィルタした上でダウンロードしておくと、後述するコンテキストウィンドウの上限問題を事前に回避できます。
File APIの仕組み: アップロード1回、質問は何度でも
File APIの核心は「ファイルを一度アップロードして file_id で参照できる」点です。同じCSVについて5つの質問を投げても、CSV自体のアップロードは1回で済みます。
CSVはネイティブの「document」ブロック形式に対応していないため、テキスト（text/plain）として変換してアップロードします。取得した file_id を各メッセージで参照すると、ファイル内容が入力トークンとして処理されます。
ファイル操作ごとのコストはAnthropicの公式ドキュメントに明記されています。
- アップロード・削除・一覧取得: 無料
- メッセージ内でファイル内容を参照した分: 入力トークンとして課金
file_id はアップロード時にAPIから返却されるランダムな識別子です。同じセッション内であれば変数に保持するだけで何度でも再利用できます。セッションをまたいで再利用したい場合は、別途ファイルやデータベースに file_id を保存しておく必要があります。毎月同じCSVを複数の分析セッションで参照するなら、セッション開始時に client.beta.files.list() で既存ファイルを確認してから再アップロードするかどうかを判断する実装も選択肢になります。
ファイルはワークスペース内に削除するまで無期限で残ります。テスト用ファイルや過去月のログが蓄積しないよう、分析セッションの最後に削除する処理をスクリプトに組み込んでおく運用を推奨します。
Pythonコード例: GWS監査ログCSVを対話的に分析する
以下は「CSVをアップロードし、複数の質問を連続して投げる」最小構成です。anthropic ライブラリ（pip install anthropic）と環境変数 ANTHROPIC_API_KEY が前提です。
CSV本文を io.BytesIO でバイト列に変換してアップロードする点と、メッセージのcontentに document ブロックを追加して file_id を参照する点が、通常のmessages APIと異なる部分です。
import io
import anthropic
client = anthropic.Anthropic()
# 1. 監査ログCSVをテキストとして読み込む
with open("gws_audit_may.csv", "r", encoding="utf-8") as f:
csv_text = f.read()
# 2. Files APIにアップロード（text/plain として送信）
uploaded = client.beta.files.upload(
file=("gws_audit_may.txt", io.BytesIO(csv_text.encode("utf-8")), "text/plain"),
)
file_id = uploaded.id
print(f"アップロード完了: {file_id}")
# 3. 対話ループ: 同じfile_idを使って質問を深掘りする
questions = [
"5月中に管理者権限が追加・変更されたユーザーと日時を一覧にしてください。",
"上記のうち、深夜22時〜翌6時（JST）に操作が行われたケースはありますか？",
"外部ドメイン(@company.com以外)へのファイル共有が急増している日はありますか？",
]
for question in questions:
response = client.beta.messages.create(
model="claude-haiku-4-5",
max_tokens=1024,
messages=[
{
"role": "user",
"content": [
{"type": "text", "text": question},
{
"type": "document",
"source": {"type": "file", "file_id": file_id},
},
],
}
],
betas=["files-api-2025-04-14"],
)
print(f"Q: {question}")
print(f"A: {response.content[0].text}\n")
# 4. 分析が終わったらファイルを削除する
client.beta.files.delete(file_id)
print("ファイル削除完了")
betas=["files-api-2025-04-14"] はFiles APIがベータ機能のため必須のパラメータです。このパラメータがないとAPI呼び出しがエラーになります。CSVをそのまま application/csv で渡そうとしてもドキュメントブロックとして受け付けられないため、text/plain に変換してアップロードする点に注意してください。
上記のサンプルでは質問ごとに独立したAPIリクエストを送っています。前の回答を踏まえてさらに深掘りしたい場合は、messages リストにアシスタントの回答を追加しながら会話を積み上げるマルチターン形式に変更します。ただし、マルチターンにすると過去のやりとりが蓄積してトークン数が増えます。探索の一巡目は上記の独立リクエスト形式で始め、気になった箇所だけをマルチターンで深掘りするのが効率的な進め方です。
異常検知プロンプト例: 権限変更・深夜ログイン・外部共有の3パターン
GWS監査ログの月次確認でよく使うプロンプトを3つ示します。ドメイン名や判定基準は組織のポリシーに合わせて書き換えてください。
権限変更の集中検出
管理者権限の変更は、不正アクセスやインサイダーリスクの早期発見に直結するイベントです。同一ユーザーへの反復的な権限変更は、設定ミスの繰り返しや意図的な操作の隠蔽を示すことがあります。「反復あり」フラグを立てると、フォローアップすべきケースを一目で絞り込めます。
このCSVから、管理者権限（スーパー管理者・代理管理者・グループ管理者）の
追加または削除が行われたイベントをすべて抽出してください。
日付・操作者・対象ユーザーをMarkdownの表で出力し、
同一ユーザーへの操作が複数回あった場合は「反復あり」とフラグを立ててください。
深夜ログインの検知
業務時間外のログインは、アカウント乗っ取りや不審な内部操作のシグナルになります。散発的な深夜ログインは正規の残業や海外出張が理由のこともありますが、同一ユーザーが3日以上連続して深夜にアクセスしている場合は、当該ユーザーへのヒアリングとその期間のアクティビティ確認を優先的に行うと効率的です。
このCSVのログインイベントのうち、22時〜翌6時（日本標準時 JST）に
発生したものを抽出してください。
ユーザーメールアドレス・日時・IPアドレスの一覧を作成し、
同じユーザーが3日以上繰り返している場合は「継続的な深夜アクセス」として
目立つよう表示してください。
外部共有の増加検知
外部ドメインへのファイル共有が集中しているパターンは、情報漏えいリスクの指標になります。退職直前の操作や、特定の外部委託先への集中共有なども、このパターンで発見できることがあります。「5件以上」の閾値は組織の規模や業態に合わせて調整してください。
このCSVから、自社ドメイン（@company.com）以外へのファイル共有・
権限付与イベントをすべて抽出してください。
共有元ユーザー・対象ファイル・外部ドメイン・日時を表で示し、
同一外部ドメインへの共有が5件以上ある場合は「外部集中」として注記してください。
いずれも「抽出→フラグ付け→優先度表示」という構成です。最初の質問で全体像を掴み、次の質問でフラグが立った対象を深掘りする使い方が実務に合っています。Claudeの出力はMarkdownの表形式で返ってくることが多いため、そのまま月次レポートへの貼り付け素材として使えます。
GWS監査ログCSV月次分析のコスト試算
GWS管理コンソールからエクスポートした監査ログCSVのトークン数は、列数と値の長さによって変わります。1行あたり約100〜150文字を目安にすると、規模ごとの概算は以下の通りです。
| ログ規模 | 概算入力トークン | claude-haiku-4-5（200Kウィンドウ） |
|---|---|---|
| 5,000行 | 約12万〜19万トークン | コンテキスト内に収まる |
| 20,000行 | 約48万〜75万トークン | 超過する可能性あり |
5,000行規模はclaude-haiku-4-5のコンテキストウィンドウ（200Kトークン）に収まります。20,000行は超過するケースがあるため、イベント種別ごと（ログイン・権限変更・共有操作）または期間ごとに分割してから分析する設計が必要です。
コストをさらに抑える観点では、Files API × Prompt Cachingの組み合わせが有効です。同じファイルを複数回参照するセッションでは、Prompt Cachingが有効な場合はキャッシュヒット分の入力トークンコストを大幅に削減できます。Files APIとPrompt Cachingを組み合わせた設計の詳細は、GWS監査ログのPrompt Caching設計でコスト削減で解説しています。
モデルの選択もコストに影響します。探索フェーズの最初の一巡はclaude-haiku-4-5（低コスト・高速）で全体像を掴み、深掘りが必要な箇所だけclaude-3-5-sonnetに切り替えるのが、精度とコストのバランスを取りやすい運用です。具体的なAPI料金は採用するモデルやトークン数によって変わるため、Anthropicの公式価格ページで最新の料金を確認してください。
Files APIを使う前に確認すること
本番利用を始める前に、以下の4点を確認してください。
対応プラットフォーム: Files APIはAmazon BedrockとGoogle Cloud（Vertex AI）では利用できません。Anthropic直接のAPIエンドポイント、Claude Platform on AWS、またはMicrosoft Foundryが対象です（Anthropic公式ドキュメントより）。現在の開発環境がBedrock経由の場合は、利用する前にエンドポイントの切り替えが必要になります。
ファイルの永続性と管理: アップロードしたファイルは明示的に削除するまでワークスペースに残ります。月次分析後の削除をスクリプトの最終ステップとして組み込んでください。複数の担当者やスクリプトがAPIを使う環境では、どのファイルを誰がアップロードしたかが分からなくなりやすいため、ファイル名にアップロード日や目的を含める命名規則を決めておくと管理しやすくなります。
個人情報の取り扱い: 監査ログにはメールアドレス・IPアドレスが含まれます。Anthropicのデータ保持ポリシーと社内のセキュリティポリシーを照合してから利用を開始してください。特に、外部クラウドAPIに送信するデータの範囲について、情報セキュリティ担当者と事前に合意を取っておくと、後から差し戻しになる事態を防げます。
ベータ機能の性質: 現時点ではベータのため、インターフェースや仕様が変更になる可能性があります。本番フローに組み込む前に、公式ドキュメントで最新の仕様を確認してください。betas パラメータの文字列（"files-api-2025-04-14" 等）も変更される可能性があるため、定期的な確認が必要です。
探索フェーズから自動化フェーズへ
File APIのインタラクティブ分析は、GWS監査ログのAI活用を「まず試してみる」ための最小の入口です。Batch APIのようなジョブ管理設計は不要で、CSVをアップロードしてその場で質問を重ねるだけで始められます。
実際に使い始めると、「権限変更の確認はパターンが読めるので自動化できる」「深夜ログインは人が文脈を判断したい」という使い分けの軸が見えてきます。その判断をもとにBatch APIでの定期レポート自動化を設計するのが、実務に即した順序です。
具体的には、次の3フェーズで進めると定着しやすくなります。
- フェーズ1（1〜2ヶ月目）: File APIで今月・先月の監査ログを探索し、組織特有のリスクパターンを把握する。どのイベント種別に問題が集中しやすいかを確認する段階
- フェーズ2（3〜4ヶ月目）: パターン化できた質問（例：権限変更の一覧、外部共有の集計）をプロンプトとして固定し、毎月同じ手順で実行できる形に整備する
- フェーズ3（5ヶ月目以降）: 固定プロンプトで対応できる定型分析をBatch APIに移行し、月初の自動実行レポートとして組み込む。File APIは引き続き突発的な深掘り用として残す
月次の監査ログ確認を「何かあってから遡る」から「毎月能動的に確認する」に変えること自体が、セキュリティ運用の大きな一歩です。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。
「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
※ この記事は DRASENAS Blog の転載です。オリジナルではコードや設定手順が随時アップデートされています。