gemini-history-analyzer

Gemini 履歴アナライザー

Google Takeout からエクスポートした Gemini Apps のアクティビティ ZIP ファイルを展開し、分類、分析します。このスキルでは、次の処理を行います。

• 展開（中国語／Unicode のファイル名に対応）
• コンテンツの分類とトピック分析
• 会話パターンからのユーザープロファイル抽出
• 文脈を確認しながら行う、ドメイン固有のキーワード検索
• 個人情報／機密コンテンツの検出
• メモリファイルの任意作成を含む、構造化レポートの生成

まず確認：会議の文字起こしか、プロンプトと応答か

本格的な分析に入る前に、3～5 個のファイルをサンプルとして確認し、会話の種類を判断します。

手がかり	会議の文字起こし	プロンプトと応答
話者ラベル	「张三:」、「李四:」、「Speaker 1:」	「User:」、「Assistant:」、「You:」
コンテンツのパターン	話し合いの流れ、交互の発言、雑談	質疑応答、指示→出力
長さの分布	ばらつきがあり、短い発言が多い	アシスタントの応答が長い
ファイル名	中国語が多く、会議形式のタイトル	英語が多く、トピックに基づくタイトル

分析方法は会話の種類によって異なります。

• 会議の文字起こし → トピック分類、話者分析、決定事項の追跡、ユーザープロファイルの抽出
• プロンプトと応答 → 利用パターンの分析、能力評価、関心分野のマッピング

ステップ 1：ZIP を展開する

Google Takeout のファイルには、中国語／Unicode のファイル名が含まれています。macOS の unzip はファイル名を破損するため、必ず unar を使用してください。

# Install unar if missing
brew install unar 2>/dev/null || true

# Extract to a target directory
unar -o <output-dir> -q "<takeout-zip-path>"

標準的な構造は次のとおりです。

Takeout/
└── My Activity/
    └── Gemini Apps/
        ├── *.txt          # Conversation transcripts
        ├── *.html         # Web-format backups (rare)
        ├── *.png/jpg      # Images from conversations
        ├── *.mp3/mp4/wav  # Audio/video attachments
        ├── *.pdf          # Uploaded/shared documents
        ├── *.xlsx/docx    # Office documents
        └── *.zip          # Nested archives (animation frames, etc.)

ステップ 2：一覧化して分類する

個々のファイルを読む前に、すべてのファイルを一覧化します。

# Count by extension
find <extract-dir> -type f | sed 's/.*\.//' | sort | uniq -c | sort -rn

# List all txt files (these are the primary content)
find <extract-dir> -name "*.txt" -type f | sort

# Get total size per type
find <extract-dir> -type f -exec du -sh {} \; | sort -rh | head -30

次の項目を表にまとめます。

• ファイルの合計数、合計サイズ
• ファイル形式ごとの内訳（txt の数／サイズ、メディアファイルの数／サイズなど）
• ファイルのタイムスタンプが意味を持つ場合は、日付の範囲

ステップ 3：サンプルを確認して分類する

ファイル一覧の中から、散らばった位置にある txt ファイルを 3～5 個読みます（最初の数個だけでなく確認してください。タイムスタンプやファイルサイズによって、種類ごとにまとまっている場合があります）。それぞれについて、次の項目を確認します。

1. 会話の種類を判断するため、最初の約 100 行を読む
2. 言語を特定する（中国語／英語／混在）
3. 大まかなトピック分野に分類する
4. 話者の人数と会話のパターンを記録する

このサンプルをもとに、残りのファイルの分析方針を決めます。

ステップ 4：全コンテンツを分析する

各 txt ファイルを読み、次の情報を抽出します。

4a. メタデータ

• タイトル（ハッシュの接尾辞を除いたファイル名）
• おおよその所要時間（文字起こしのタイムスタンプから算出）
• 話者の人数と識別情報
• 言語の割合（中国語％／英語％）

4b. トピック分類

主要トピックと副次トピックを割り当てます。デフォルトのカテゴリは次のとおりです（実際のコンテンツに応じて調整してください）。

• ソフトウェア開発
• AI／LLM ツールとワークフロー
• インフラストラクチャ／クラウド／DevOps
• ビジネス／戦略
• 製品／デザイン
• チーム／人事／人員
• 金融／投資（分析対象となることが多い分野）
• 法務／コンプライアンス
• 個人／その他

4c. ファイルごとの主な調査結果

各ファイルについて、次の情報を記録します。

• 主な議論の要点（箇条書きで 3～5 項目）
• 決定事項またはアクション項目
• 注目すべき引用（原文のまま、文脈を添える）
• 言及された関係性（人物、企業、プロジェクト）

ステップ 5：ドメイン固有のキーワード検索

特定の分野（金融、法務など）のコンテンツを探す場合：

1. AND／OR ロジックを使ってキーワードリストを作成する — 例：金融の場合、stock OR investment OR fund OR portfolio OR 股票 OR 投资 OR 基金 に加えて、EPS、P/E、dividend、arbitrage などの分野固有の用語も含めます
2. すべての txt ファイルを検索する — キーワードの組ごとに実行します
3. 一致箇所の前後の文脈を読む（前後 10 行） — キーワードの一致だけでは、大量の誤検出が発生します。「Investment」はビジネス戦略を意味する場合があり、「option」は UI の選択肢を意味する場合があり、「fund」は保険機能を意味する場合があります
4. 一致箇所を分類する：
   • 明確な該当箇所（会話がこの分野についてのもの）
   • 誤検出（同じ単語でも意味が異なる）
   • 判断が難しい（さらに詳しく読む必要がある）
5. 明確な該当箇所と判断が難しい箇所について、ファイル全体を再読する

grep の出力だけで判断してはいけません。文脈の確認は必須です。

ステップ 6：レポートを生成する

レポートの構成

# Gemini History Analysis Report
**Source**: <zip filename>
**Date analyzed**: <today>
**Extraction size**: <N files, N MB>

## 1. Content Overview
- Total conversations: N
- Conversation type: [Meeting Transcripts | Prompt-Response | Mixed]
- Language distribution: X% Chinese, Y% English, Z% Mixed
- Date range: <earliest> to <latest>
- Media attachments: N images, N audio, N video

## 2. Topic Distribution
| Category | Count | % | Notes |
|----------|-------|---|-------|
| ... | | | |

## 3. Key Findings
(Bulleted, organized by significance)

## 4. Domain-Specific Analysis
(If user requested finance/legal/etc. keyword search)
- Matches found: N
- Confirmed relevant: N
- False positives: N (with examples of what caused them)

## 5. Notable Documents
Non-txt files worth attention: PDFs, spreadsheets, etc.

## 6. Valuable Quotes
Verbatim quotes that capture key insights

## 7. PII / Sensitive Content
(Flag if detected — do NOT include the actual PII in the report)
- File: <name>, Type: <resume/background-check/etc.>, Risk: <high/medium/low>

ステップ 7：メモリファイルの生成（任意）

ユーザーが調査結果をプロジェクトメモリとして保存したい場合（.claude/projects/<path>/memory/ など）：

メモリファイルを生成するタイミング

• ユーザーから明示的な依頼がある（「ユーザープロファイルを作成して」「これを覚えておいて」など）
• 分析によって、ユーザーの好み、ワークフロー、制約に関する再利用可能な知見が得られた
• プロジェクトにメモリシステムがある（既存の memory/MEMORY.md を確認する）

提案するメモリファイルの種類

1. ユーザープロファイル（user-profile.md）— 会話からユーザーの役割、好み、性格がわかる場合
2. フィードバック／ワークフロー（feedback-*.md）— 会話から実証済みのワークフローや、すべきこと／すべきでないことがわかる場合
3. プロジェクトコンテキスト（project-*.md）— 会話から進行中のプロジェクト、決定事項、制約がわかる場合

メモリ書き込みの手順

• プロジェクトで既存のメモリ形式に従う（他のメモリファイルでフロントマターの規約を確認する）
• 分析にさかのぼれるよう、originSessionId またはソースタグを含める
• 新しいエントリーを MEMORY.md のインデックスに追加する
• 既存のメモリと重複させない — 既存ファイルを更新する

ステップ 8：クリーンアップ

# Remove extracted files after analysis complete (user confirms)
rm -rf <extract-dir>

重大な落とし穴（実際の使用から）

1. ZIP の展開：必ず unar を使う

macOS の unzip は中国語のファイル名を気付かれないまま破損させます。ファイル名が文字化けしたパスになり、多くのファイルが展開に失敗します。brew install unar と unar -o <dir> <zip> を使えば、すべて正しく処理できます。

2. キーワード検索：grep は最初の手順であり、答えではありません

実際の分析では、「stock」「investment」「fund」「option」「portfolio」「trading」をキーワードに検索したところ、ファイルの 80% 以上で一致しましたが、どれもすべて誤検出でした。これらの単語はソフトウェア開発の文脈で頻繁に登場します。一致した箇所は必ず前後の文脈を確認してください。

3. 読んでいる内容を把握する

Gemini Takeout の txt ファイルは、元の Gemini のプロンプトと応答のペアではありません。次のような場合があります。

• 飞书妙记（Feishu Miaojii）が書き起こしてエクスポートし、その後 Gemini にアップロードした会議の記録
• Gemini に手動でコピー＆ペーストしたメモ
• 分析のために貼り付けた PDF／記事のテキスト 各ファイルの最初の約 100 行を読み、内容を決めつけないようにしてください。

4. 個人情報が含まれている可能性があります

履歴書、身元調査フォーム、連絡先リストなどは、会話履歴に頻繁に含まれます。これらにはフラグを立て、内容をレポートに含めないでください。メモリファイルや Wiki ページを作成する場合は、個人情報をコピーせず、要約してください。

5. 大きなファイルは優先度を判断する

63KB の記録は、2 時間の会議に相当します。関連性が非常に高いと判断された場合を除き、全体を読まないでください。概要を把握するには、最初の 10% と最後の 10% を読みます。キーワードが一致するか、トピックとの関連性から必要と判断した場合のみ、全体を読んでください。

6. 大量のファイルは並列で読む

100 件を超えるファイルがある場合は、並列のサブエージェントを起動し、それぞれ 10～15 件ずつ読み取って要約します。結果を統合してください。1 つのエージェントがすべてのファイルを順番に読むと、コンテキストを使い切ってしまいます。