Automate This

手動プロセスのスクリーン録画を分析して、実際に動作する自動化スクリプトを構築します。

ユーザーが何か繰り返しまたは退屈なタスクを行っている様子を録画し、ビデオファイルを提供してもらえば、何をしているのか、なぜしているのか、どのようにスクリプト化するのかを把握します。

前提条件チェック

録画を分析する前に、必要なツールが利用可能であることを確認してください。これらのチェックは無言で実行し、問題のみを報告します：

command -v ffmpeg >/dev/null 2>&1 && ffmpeg -version 2>/dev/null | head -1 || echo "NO_FFMPEG"
command -v whisper >/dev/null 2>&1 || command -v whisper-cpp >/dev/null 2>&1 || echo "NO_WHISPER"

• ffmpeg は必須です。 見つからない場合は、ユーザーに次のように伝えてください：brew install ffmpeg（macOS）またはOS固有の同等コマンド。
• Whisper はオプションです。 録画にナレーションがある場合のみ必要です。見つからず、かつ録画に音声トラックがある場合は、pip install openai-whisperまたはbrew install whisper-cppをお勧めしてください。ユーザーが拒否した場合は、ビジュアル分析のみで続行します。

Phase 1：録画からコンテンツを抽出

ビデオファイルパス（通常は~/Desktop/にある）が与えられた場合、フレームと音声の両方を抽出します：

フレーム抽出

2秒ごとに1フレーム抽出します。これはカバレッジとコンテキストウィンドウの制限のバランスを取ります。

WORK_DIR=$(mktemp -d "${TMPDIR:-/tmp}/automate-this-XXXXXX")
chmod 700 "$WORK_DIR"
mkdir -p "$WORK_DIR/frames"
ffmpeg -y -i "<VIDEO_PATH>" -vf "fps=0.5" -q:v 2 -loglevel warning "$WORK_DIR/frames/frame_%04d.jpg"
ls "$WORK_DIR/frames/" | wc -l

セッション内のすべての後続の一時ファイルパスに$WORK_DIRを使用します。モード 0700 の実行ごとのディレクトリにより、抽出されたフレームは現在のユーザーのみが読み取り可能であることが保証されます。

録画が 5 分以上（150フレーム以上）の場合は、コンテキスト制限内に留まるように間隔を 4 秒ごとに 1 フレームに増やします。長い録画ではサンプリング頻度を下げていることをユーザーに伝えてください。

音声抽出と文字起こし

ビデオに音声トラックがあるかどうかを確認します：

ffprobe -i "<VIDEO_PATH>" -show_streams -select_streams a -loglevel error | head -5

音声が存在する場合：

ffmpeg -y -i "<VIDEO_PATH>" -ac 1 -ar 16000 -loglevel warning "$WORK_DIR/audio.wav"

# 利用可能な whisper バイナリを使用
if command -v whisper >/dev/null 2>&1; then
  whisper "$WORK_DIR/audio.wav" --model small --language en --output_format txt --output_dir "$WORK_DIR/"
  cat "$WORK_DIR/audio.txt"
elif command -v whisper-cpp >/dev/null 2>&1; then
  whisper-cpp -m "$(brew --prefix 2>/dev/null)/share/whisper-cpp/models/ggml-small.bin" -l en -f "$WORK_DIR/audio.wav" -otxt -of "$WORK_DIR/audio"
  cat "$WORK_DIR/audio.txt"
else
  echo "NO_WHISPER"
fi

どちらの whisper バイナリも利用できず、録画に音声がある場合は、ユーザーにナレーションコンテキストがないことを通知し、Whisper（pip install openai-whisperまたはbrew install whisper-cpp）をインストールするか、ビジュアルのみの分析で進めるかを尋ねてください。

Phase 2：プロセスの再構築

抽出されたフレーム（および利用可能な場合は文字起こし）を分析して、ユーザーが何をしたかについての構造化された理解を構築します。フレームを順に検討して、以下を特定します：

1. 使用されたアプリケーション — どのアプリが記録に表示されていますか？（ブラウザ、ターミナル、Finder、メールクライアント、スプレッドシート、IDE など）
2. アクションのシーケンス — ユーザーは順に何をしましたか？クリック単位で、ステップバイステップで。
3. データフロー — ステップ間でどの情報が移動しましたか？（コピーされたテキスト、ダウンロードされたファイル、フォーム入力など）
4. 決定ポイント — ユーザーが一時停止、確認、または選択を行った瞬間がありましたか？
5. 繰り返しパターン — ユーザーは異なる入力で同じことを複数回行いましたか？
6. 問題点 — プロセスが遅い、エラーが発生しやすい、または退屈に見えた場所はどこですか？ナレーションはこれを直接明かすことが多いです（「この部分が嫌い」、「これはいつも永遠にかかる」、「これを全てに対して行わなければならない」）。

この再構築をユーザーに番号付きステップリストとして提示し、自動化を提案する前に正確であることを確認するよう求めます。これは重要です — 間違った理解は無用な自動化につながります。

形式：

この記録であなたがしていることが見えます：

1. Chrome を開き、[特定の URL] に移動
2. 認証情報でログイン
3. レポートダッシュボードにクリックスルー
4. CSV エクスポートをダウンロード
5. Excel で CSV を開く
6. 列 B が「保留中」の行でフィルタリング
7. それらの行を新しいスプレッドシートにコピー
8. 新しいスプレッドシートを [受信者] にメール送信

ステップ 3-8 を異なるレポートタイプに対して 3 回繰り返しました。

[ナレーションが存在した場合]：エクスポートステップが最も遅い部分であり、毎週月曜朝にこれを行うとおっしゃっていました。

これはあなたがしていたことと一致していますか？間違っていたり、見落としたりしたことはありますか？

ユーザーが再構築が正確であることを確認するまで、Phase 3 に進まないでください。

Phase 3：環境フィンガープリント

自動化を提案する前に、ユーザーが実際に何を使用できるかを理解してください。これらのチェックを実行します：

echo "=== OS ===" && uname -a
echo "=== Shell ===" && echo $SHELL
echo "=== Python ===" && { command -v python3 && python3 --version 2>&1; } || echo "not installed"
echo "=== Node ===" && { command -v node && node --version 2>&1; } || echo "not installed"
echo "=== Homebrew ===" && { command -v brew && echo "installed"; } || echo "not installed"
echo "=== Common Tools ===" && for cmd in curl jq playwright selenium osascript automator crontab; do command -v $cmd >/dev/null 2>&1 && echo "$cmd: yes" || echo "$cmd: no"; done

ユーザーが既に持っているツールに提案を制限するためにこれを使用します。よりシンプルなパスが本当に機能しない場合を除き、5 つの新しいものをインストールする必要がある自動化を決して提案しないでください。

Phase 4：自動化を提案

再構築されたプロセスとユーザーの環境に基づいて、最大 3 段階で自動化を提案します。すべてのプロセスが 3 段階を必要とするわけではありません — 判断を使用します。

段階構造

Tier 1 — クイックウィン（5 分以内で設定） 最小限の有用な自動化です。シェルエイリアス、ワンライナー、キーボードショートカット、AppleScript スニペット。プロセス全体ではなく、最も痛い単一ステップを自動化します。

Tier 2 — スクリプト（30 分以内で設定） プロセス全体をエンドツーエンドで自動化するスタンドアロンスクリプト（bash、Python、または Node — ユーザーが持っているもののいずれか）。一般的なエラーを処理します。必要に応じて手動で実行できます。

Tier 3 — 完全自動化（2 時間以内で設定） Tier 2 のスクリプトプラス：スケジュール実行（cron、launchd、または GitHub Actions）、ロギング、エラー通知、および必要な統合スキャフォルディング（API キー、認証トークンなど）。

提案形式

各段階ごとに、以下を提供します：

## Tier [N]：[名前]

**何を自動化するか：** [再構築からのどのステップ]
**何が手動のままか：** [どのステップがまだ人間が必要か]
**時間節約：** [録画の長さと繰り返し回数に基づいて、実行ごとに推定される時間節約]
**前提条件：** [既にインストールされていない必要なもの — 理想的には何もない]

**仕組み：**
[2-3 文の平易な英語での説明]

**コード：**
[完全で機能し、コメント付きのコード — 疑似コードではない]

**テスト方法：**
[機能することを確認するための正確なステップ（可能な場合はドライランから開始）]

**取り消す方法：**
[何か問題が起きた場合、変更を元に戻す方法]

アプリケーション固有の自動化戦略

記録に表示されるアプリケーションに基づいて、これらの戦略を使用します：

ブラウザベースのワークフロー：

• 最初の選択肢：ウェブサイトにパブリック API があるかどうかを確認します。API 呼び出しはブラウザ自動化より 10 倍信頼性があります。API ドキュメントを検索します。
• 2 番目の選択肢：既知のエンドポイントで単純な HTTP リクエストを行う場合はcurlまたはwget。
• 3 番目の選択肢：UI をクリックスルーする必要があるワークフローの場合は Playwright または Selenium。Playwright を優先 — より高速で、より安定しています。
• パターンを探します：ユーザーがダッシュボードから同じレポートを繰り返しダウンロードしている場合、ほぼ確実に API または直接 URL でクエリパラメータを使用して利用可能です。

スプレッドシートとデータワークフロー：

• データフィルタリング、変換、集計用の pandas を使用した Python。
• ユーザーが Excel で単純な列操作をしている場合、5 行の Python スクリプトがプロセス全体を置き換えます。
• csvkit：コードを書かずに簡単なコマンドライン CSV 操作を行います。
• 出力が Excel 形式のままである必要がある場合は、openpyxl を使用します。

メールワークフロー：

• macOS：osascriptは Mail.app を制御して添付ファイル付きメールを送信できます。
• クロスプラットフォーム：送信用の Pythonsmtplib、読み込み用のimaplib。
• メールがテンプレートに従う場合は、変数置換を含むテンプレートファイルから本文を生成します。

ファイル管理ワークフロー：

• 移動/コピー/名前変更パターン用のシェルスクリプト。
• バッチ操作用のfind + xargs。
• 変更時にトリガーされる自動化用のfswatchまたはwatchman。
• ユーザーがファイルを日付または種類でフォルダに整理している場合、それは 3 行のシェルスクリプトです。

ターミナル/CLI ワークフロー：

• 頻繁に入力されるコマンド用のシェルエイリアス。
• マルチステップシーケンス用のシェル関数。
• プロジェクト固有のタスクセット用の Makefile。
• ユーザーが異なる引数で同じコマンドを実行している場合、それはループです。

macOS 固有のワークフロー：

• ネイティブアプリ（Mail、Calendar、Finder、Preview など）を制御するための AppleScript/JXA。
• コードが必要ない単純なマルチアプリワークフロー用の Shortcuts.app。
• ファイルベースのワークフロー用のautomator。
• スケジュール済みタスク用のlaunchd plist ファイル（macOS では cron よりも優先）。

クロスアプリケーションワークフロー（アプリ間のデータ移動）：

• データ転送ポイントを特定します。各転送は自動化の機会です。
• 記録内のクリップボードベースの転送は、アプリが互いに通信していないことを示唆しています — 代わりに API、ファイルベースのハンドオフ、または直接統合を探します。
• ユーザーがアプリ A からコピーしてアプリ B に貼り付けている場合、自動化は A のデータソースから読み込み、B の入力形式に直接書き込む必要があります。

提案をターゲット化

これらの原則をすべての提案に適用します：

1. 最初にボトルネックを自動化します。 記録内のナレーションと時間は、どのステップが実際に痛いかを明かします。最悪のステップの 30 秒の自動化は、プロセス全体の 2 時間の自動化に勝ります。

2. ユーザーのスキルレベルに合わせます。 記録がターミナルに慣れた人を示している場合は、シェルスクリプトを提案します。GUI をナビゲートしている人を示している場合は、単純なトリガー（スクリプトのダブルクリック、Shortcut を実行、または 1 つのコマンドを入力）を持つ何かを提案します。

3. 実際の時間節約を推定します。 記録の期間を数えて、どのくらい頻繁に実行するかで乗算します。「この記録は 4 分です。毎日これをするとおっしゃっていました。それは年間 17 時間です。Tier 1 は毎回 30 秒に短縮します — 16 時間が戻ってきます。」

4. 80% のケースを処理します。 自動化の最初のバージョンは一般的なパスを完璧にカバーしてください。エッジケースは Tier 3 で処理するか、手動介入のためにフラグを立てることができます。

5. 人間のチェックポイントを保持します。 記録がユーザーがプロセスの途中で何かをレビューまたは承認しているのを示している場合、それを手動ステップのままにします。判断呼び出しを自動化しないでください。

6. ドライランを提案します。 すべてのスクリプトは、実際に実行せずに何をするかを示すモードを持つべきです。--dry-runフラグ、プレビュー出力、または破壊的なアクション前の確認プロンプト。

7. 認証とシークレットを説明します。 プロセスにログインまたは認証情報の使用が含まれる場合、決してハードコードしないでください。環境変数、キーチェーンアクセス（macOSsecurityコマンド）、または実行時のプロンプトを使用します。

8. 失敗モードを考慮します。 ウェブサイトがダウンしたらどうなりますか？ファイルが存在しない場合？形式が変わった場合？優れた提案はこれについて言及し、それを処理します。

Phase 5：構築とテスト

ユーザーが層を選択した場合：

1. 完全な自動化コードをファイルに書き込みます（適切な場所を提案 — ユーザーのプロジェクトディレクトリが存在する場合、それ以外の場合は~/Desktop/）。
2. ユーザーが見ている状態でドライランまたはテストを通じて説明します。
3. テストが機能する場合は、実際に実行する方法を表示します。
4. 失敗した場合は、診断して修正してください — 1 回の試行後に諦めないでください。

クリーンアップ

分析が完了した後（結果に関わらず）、抽出されたフレームと音声をクリーンアップします：

rm -rf "$WORK_DIR"

ユーザーに一時ファイルをクリーンアップしていることを伝えます。これにより、何も後に残されていないことがわかります。