はじめに
以前、コーディングエージェント Cline の Skills を使って、Oracle Database の AWR レポートを生成・分析したり、Mermaid ダイアグラムを生成する方法を紹介しました。今回は Cline の Workflows という機能を使って、音声データをアップロードしてから文字起こし・要約するまでの一連の作業を半自動化してみました。
このブログでご紹介している workflow は、OCI 生成AIサービス（Generative AI Service）の xai.grok-4-1-fast-reasoning をLiteLLM 経由及び OpenAI Compatible API Provider で接続して動作を確認しています。GPT-5.2 では、Workflow を完遂するために非常に多くの試行錯誤が行われることを確認していますので、Reasoning/Thinking モデルの利用をおススメします。
Cline の Workflows とは
Cline の Workflows は、繰り返し行う複数ステップの作業をマークダウンファイルで定義して自動化する機能です。チャット入力欄で / に続けてファイル名を入力すると（例えば /transcribe.md）、定義した手順に沿って Cline がステップを順番に実行してくれます。
Workflows ファイルには、自然言語による指示、CLI コマンド、Cline のツール呼び出し（XML 構文）、MCP ツールを組み合わせて記述できます。ファイルの置き場所はプロジェクト内（.clinerules/workflows/）かグローバル（~/Documents/Cline/Workflows）の2択で、プロジェクト横断で使いたいものはグローバルに置いておくと便利です。
Skills との違いは、Skills がトピックに応じてオンデマンドで読み込まれる知識・手順の集合体であるのに対して、Workflows はユーザーが /コマンド名 で明示的に呼び出して実行するものです。毎回同じ手順を踏む作業はスクリプト化してしまう手もありますが、手順が複雑だったり途中で人間の判断が必要なポイントがあるような作業には Workflows がよく合います。
作ったもの
OCI の以下のサービスを組み合わせて、音声データから要約を得るまでを半自動化する Workflow を定義しました。
- OCI Object Storage（音声データの保存先）
- OCI Speech（文字起こし）
- Cline の 推論エンジンとしての OCI 生成AIサービス（Generative AI）の xai.grok-4-fast-reasoning（要約）
処理の流れは次のとおりです。
-
audio_dataフォルダーに置いた音声データをユーザーに選ばせる - OCI Object Storage の指定バケットにアップロードする
- OCI Speech の文字起こしジョブを作成・実行する
- ジョブの完了を待機してから結果をダウンロードする
- SRT ファイルを LLM で要約して
outputフォルダーにマークダウンで保存する
前提
- OCI CLI と構成ファイル（
~/.oci/config）が設定済みであること（ユーザーに与える権限は最小権限の原則に従って不必要な権限を付与しないようにしましょう） - OCI CLI 用の rc ファイル（"
~/.oci/oci_cli_rc）にcompartment-id` が定義済みであること
[DEFAULT]
compartment-id=ocid1.compartment.oc1..aaaaaaaaXXXXXXXXXXXXXXXXXXXXXXXXXX
- OCI Object Storage と OCI Speech を利用できる IAM 権限があること
- OCI 生成AIサービス（Generative AI）を利用できる IAM 権限があること
制約
現状、このワークフローは英語音声専用です。OCI Speech で使えるモデルがテナント・リージョンによって異なるうえ、CLI でモデル一覧を取得する方法が不明だったため、モデル選択の自動化を断念しました。なお、ワークフロー実行時に言語設定を確認してくるので、そこで日本語を指定すれば Cline が適宜対応を試みますが、動作は保証できません。
Workflow ファイル
以下が実際のワークフロー定義ファイルです。
ワークフロー定義ファイルを展開する
# OCI Speech を使って文字起こしを行うワークフロー
## ルール
- ユーザーへ何かを確認する場合は、ツールを使って選択肢を提示して、その中からユーザーに選ばせます
- 確認は１項目づつ順番に行います
- `OCI setup` を呼び出すことは禁止です
- OCI の `config` ファイルを読み出すことは禁止です
- OCI CLI が必要とするテナンシID、設定ファイルに指定されているので、CLI のオプションに明示的な指定は行いません
## STEP
### STEP-1 音声データの指定
- `audio_data` フォルダーへ音声データを配置するようにユーザーへ促します
- `audio_data` フォルダーのファイルを一覧表示して、ユーザーに文字起こし対象の音声データファイルを選択させます
- 選択されたファイル名にスペース、空白や特殊記号が含まれる場合は、ユーザーに確認した上で、"_"に置き換えて`mv`でファイル名を変更します
### STEP-2 音声データのオブジェクトストレージへのアップロード
- アップロード先のバケットは一覧を提示してユーザーに選択させます
- `oci os object head --bucket-name バケット名 --name ファイル名` コマンドで既に同名のオブジェクトがバケットに存在しないかどうか確認します
- 同名オブジェクトがある場合は、上書きするか、別の名前でアップロードするか確認します
- 上書きするときは、`oci os object put` コマンドに `--force`オプションを指定します
- 別の名前でアップロードする際は適切なファイル名候補を提示して確認します
- 音声データファイルを選択したバケットへアップロードします
- アップロードが成功したかとうかを `oci os object head --bucket-name バケット名 --name ファイル名` コマンドで確認します
### STEP-3 OCI Speech ジョブのパラメータの確認
以下をツールを使ってユーザーに確認して、パラメータを OCI CLI が期待するフォーマットの JSON ファイルに書きだします。JSON ファイルは、tmp フォルダーに配置します
- 出力先バケットは、音声データと同じバケットをデフォルトとして確認
- ジョブ名と説明は、同じ文字列として、音声データファイル名前から生成した英数字と"-"、"_"で構成されるものをデフォルトとして確認。日本語、スペース、空白と特殊記号は使用できません
- 言語は英語をデフォルトとして確認
- 句読点を有効化するかどうか？
- ダイアライゼーションを有効化するかどうか？（有効化する場合、人数は自動検知）
なお、文字起こし結果は json と srt の両方を取得します
#### [CRITICAL]JSON ファイルのパラメータの制約
- `description`は、英数字と"-"、"_"で構成されます。日本語、スペース、空白と特殊記号は使用できません
- `display-name`は、英数字と"-"、"_"で構成されます。日本語、スペース、空白と特殊記号は使用できません
- `object-names`は、日本語、スペース、空白と特殊記号は使用できません
#### サンプル JSON ファイル
```json
{
"compartmentId": "ocid1.compartment.oc1..aaaaaaaaxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"inputLocation": {
"locationType": "OBJECT_LIST_INLINE_INPUT_LOCATION",
"objectLocations": [
{
"bucketName": "speech-bucket-20250127-1510",
"namespaceName": "orasejapan",
"objectNames": [
"developer_coaching_oci_log_analytics_gen_ai_real_time_intelligence.mp3"
]
}
]
},
"outputLocation": {
"bucketName": "speech-bucket-20250127-1510",
"namespaceName": "orasejapan",
"prefix": "transcription_output/"
},
"displayName": "developer_coaching_transcription",
"additionalTranscriptionFormats": ["SRT"],
"modelDetails": {
"languageCode": "en-US",
"domain": "GENERIC",
"transcriptionSettings": {
"diarization": {
"isDiarizationEnabled": true
}
}
}
}
```
### STEP-4 OCI Speech ジョブを作成
OCI CLI と STEP-3 で作成した JSON ファイルで、Speech ジョブを作成します
```bash
oci speech transcription-job create --from-json file://temp_speech_config.json
```
### STEP-5 ジョブの状態確認
- ジョブの状態確認をして、`IN_PROGRESS` であることが確認できたら 60秒待って再確認。これをジョブが完了するまで繰り返す
```bash
oci speech transcription-job get --transcription-job-id ocid1.aispeechtranscriptionjob.oc1.{REGION}.xxxxxxxxxxxxxxxxxxxxxxxxxxx
```
### STEP-6 結果の取得
結果の JSON と SRT ファイルをダウンロードして、output フォルダーへ配置
### STEP-7 要約
以下のプロンプトで SRT ファイルを要約して、output フォルダーへマークダウン形式で保存します。ファイル名はどの音声データの要約であるかがわかる名前にします。
```
テキストデータは、動画の文字起こしです。日本語で整理してください。短くまとめることよりも文字起こしを読みのものとして読みやすく理解しやすいように整理してください。出力にはこの動画のテーマ、スピーカーなどの登場人物、全体の概要と取り上げられているすべてのトピックの要約を含めてください。トピック毎に話者が異なる場合は誰の発言の要約か明記してください。新しい製品、サービス、技術を紹介している場合はそれらをもれなく網羅してください。過度に箇条書きにせず句構造文法を意識した自然で各トピックに熟知していない読者にも読みやすい文章にしてください。ただし、文字起こしに含まれていない情報は付け加えないでください。
```
しばらく使ってみた改善点を反映したワークフロー改訂版はこちらのブログでご紹介しています（2026年2月28日追記）。
ワークフローの概要
各ステップのポイント
ファイル名の正規化（STEP-1）
OCI Speech の API はファイル名に日本語・スペース・特殊記号を受け付けません。そのため音声ファイル選択後にファイル名を検査し、問題があれば _ に置き換えるよう Cline に指示しています。これを Workflow に含めておくことで、うっかりそのままアップロードして API エラーになるという失敗を防げます。
重複チェックとアップロード（STEP-2）
oci os object head で同名オブジェクトの存在確認をした上で、上書きか別名かをユーザーに確認します。アップロード後も同コマンドで存在確認して成功を担保します。oci os object put 側のエラーだけに頼るより確実です。
パラメータ JSON の生成（STEP-3）
OCI Speech の文字起こしジョブ作成には、コンパートメント ID・バケット名・オブジェクト名・言語・ダイアライゼーション設定などを含む JSON を渡す必要があります。これを手で書くと設定漏れが起きやすいので、Cline に対話形式でパラメータを確認させてから JSON を生成させています。最終的な出力を SRT形式にすることやダイアライゼーション（話者分離）の有効化など、コンソール操作でも忘れがちな設定もここでカバーされます。
OCI Speech ジョブを作成（STEP-4）
パラメータ JSONファイルを使って、OCI Speech ジョブを作成します。
ジョブ完了待機（STEP-5）
文字起こしジョブは非同期で実行されます。IN_PROGRESS の間は 60 秒おきに oci speech transcription-job get でステータスをポーリングし、完了するまで待機します。自分でポーリングスクリプトを書かなくていいのは地味に楽です。
結果の取得（STEP-6）
結果の JSON と SRT ファイルをダウンロードして、output フォルダーへ配置します。
要約プロンプト（STEP-7）
文字起こし結果の SRT ファイルを LLM に読ませて要約します。単純に「要約して」と指示するだけではなく、「短くまとめることよりも読みやすさを優先して整理する」「話者が異なる場合は誰の発言か明記する」「文字起こしに含まれていない情報は付け加えない」など、読み物として使えるアウトプットになるよう細かく指示しています。ここは好みですね。単に「要約して」だとLLM は箇条書きを多用しがちですが、箇条書きで完結な要約は話題のドメインに関して読み手が前提知識を持っているときには簡潔で良いのですが、知らない分野だと行間を埋められず理解が難しいことがあります。そこで、私はいつもここに書いたようなプロンプトで箇条書きに頼らない文章を出力させています。LLM による要約が嫌いという人は一度お試しください。
Workflow の設定
Cline にこの Workflow を設定する手順は下記のブログの「ワークフローを定義する」セクションを参考にしてみてください。
使ってみて感じたこと
今回、Cline の LLM には、OCI 生成AIサービス（Generative AI Service） の xAI の Grok 4 Fast Reasoning を使いました。Grok は OCI CLI についてある程度の知識を持っているため大まかな方向性は正しいのですが、細かいパラメータの指定を間違えることがあり、Workflow を作る以前は、試行錯誤の末に正解にたどり着けないこともありました。そうした経験を Workflow ファイルに落とし込んでおくことで、次回以降は同じ失敗をしなくてすみます。
OCI コンソールで同じ作業をしようとすると、オブジェクトストレージ・OCI Speech とサービスをまたいで画面を切り替えながら進める必要があり、どのオプションを設定したかも忘れがちです。IDE を開きながら /transcribe.md と打つだけで一連の作業をエージェントが順番に案内してくれるのは、実際に使ってみると想像以上に楽でした。もちろん、Clineが補完してくれますので、ワークフロー名の全てを手打ちする必要はありません。このワークフローを作ってからは OCI Speech のコンソールを開かなくなりました。
頻繁に（毎日何度も）実行するならシェルスクリプトにした方が速いですが、数日に一度くらい使う作業には Workflow や Skill が向いていると感じます。スクリプトを作ってその呼び出し手順を Skill に定義するのが、再利用性と柔軟性のバランスとしては一番うまい使い方かもしれません。
Cline on Windows with Git Bash の TIPS
Cline から Git Bash on Windows で CLI を実行したとき、CLI からの応答（STDOUT）がターミナル上で折り返すと Cline が境目の文字を2回拾ってしまうことがあります。しばらく、OCI CLI が謎の認証エラーで悩まされたのですが、この現象で compartmentId が壊れていたことが原因でした。ターミナルは横方向には縮めないことをお勧めします。
あとがき
Cline の Workflows は、手順が決まっているけれど途中でパラメータの確認や選択が必要な作業を半自動化するのに向いています。今回は OCI Speech を例にしましたが、他のサービスやツールとの組み合わせにも応用しやすい仕組みです。Workflows の詳細は公式ドキュメントを参照してください。