メインコンテンツまでスキップ

チュートリアル: 高度なユースケース

目標: 複数の Rephlo 機能を組み合わせて生産性を最大化する、高度なワークフローを習得します。 レベル: エキスパート 所要時間: 読了に30〜60分、習熟には継続的な取り組みが必要

目次​

  1. マルチプロバイダーワークフローの最適化
  2. Space の連結とコンテキストオーケストレーション
  3. 高度なコマンドコンポジション
  4. エンタープライズワークフロー統合
  5. AI支援コードレビューパイプライン
  6. 多言語コンテンツパイプライン
  7. リサーチシンセシスワークフロー
  8. プライバシー優先の機密データ処理
  9. リアルタイムミーティングアシスタント
  10. クリエイティブライティングワークフロー

1. マルチプロバイダーワークフローの最適化​

難易度: エキスパート 所要時間: セットアップ30分、その後継続的な最適化 前提条件: プロバイダーを2つ以上設定済み(推奨: Gemini 3.5 Flash や GPT-5.4 Mini のような高速モデルに加え、Claude Sonnet 4.6 のようなプレミアムモデル)

シナリオ​

毎日数百件のテキスト処理を行っているとします。単純なタスク(文法修正、書式整形)には高価なモデルは不要ですが、複雑な推論タスクにはトップクラスの AI が必要です。タスクを戦略的に異なるプロバイダーへ振り分けることで、品質を保ちながらコストを大幅に削減できます。

ワークフローアーキテクチャ​

ステップバイステップのセットアップ​

ステップ1: プロバイダー別のコマンドグループを作成する​

  1. Dashboard > Commands > Manage Groups を開きます。
  2. 3つのグループを作成します。
    • "Quick Tasks"(緑、稲妻アイコン)
    • "Standard Tasks"(青、歯車アイコン)
    • "Deep Analysis"(紫、脳アイコン)

ステップ2: 複雑さに応じてコマンドを設定する​

Quick Tasks(Gemini 3.5 Flash - 高速・低コスト)

  • Grammar Check
  • Spelling Fix
  • Text Formatting
  • Simple Translation
  • Bullet Point Extraction

Standard Tasks(GPT-5.4 Mini - バランス型)

  • Email Rewriting
  • Code Documentation
  • Summary Generation
  • Meeting Notes Cleanup

Deep Analysis(Claude Sonnet 4.6 - プレミアム)

  • Legal Document Review
  • Complex Code Refactoring
  • Strategic Analysis
  • Long-form Content Creation
  • Multi-document Synthesis

ステップ3: コマンドにプロバイダーを割り当てる​

  1. 該当グループ内の各コマンドを編集します。
  2. Provider ドロップダウンで、指定するプロバイダーを選択します。
  3. コマンドを保存します。

ステップ4: 会話の途中でプロバイダーを切り替える​

複雑さが変化していく chat の会話では:

  1. 最初の探索には Gemini 3.5 Flash のような高速モデルで会話を始めます。
  2. より深い分析が必要になったら、chat ヘッダーの Provider セレクターをクリックします。
  3. Claude Sonnet 4.6 に切り替えます。
  4. 会話のコンテキストは保持され、モデルだけが変わります。

コスト計算の例​

各タスクを適切な階層へ振り分けることが、コスト削減の源です。タスク種別ごとの相対コストは、単純なパターンに従います。

タスク種別月間件数最適化なし最適化あり
文法チェック500プレミアムモデル(高コスト)高速モデル(非常に低コスト)
メール書き直し200プレミアムモデル(高コスト)バランス型モデル(低コスト)
深い分析50プレミアムモデル(高コスト)プレミアムモデル(高コスト)
正味の効果750支出が最大高頻度の階層で大幅削減

最大のレバーは、頻度が高く複雑さの低い行です。文法チェックのような作業をプレミアムモデルから高速モデルへ移すだけで、支出の大部分を削減できます。現在の Dedicated API の料金(およびモデルごとの credit の消費方法)については、Rephlo の料金 と プラン & 料金 を参照してください。

プロのヒント​

  • 類似タスクをまとめて処理する: プロバイダーを切り替える前に、すべての文法チェックをまとめて処理します。
  • グループごとにホットキーを使う: Quick Tasks には Ctrl+1、Standard には Ctrl+2、Deep には Ctrl+3 を割り当てます。
  • History を確認する: History ページを確認し、格下げできそうなタスクを見つけます。

起こりうる落とし穴​

  • 複雑なタスクの振り分け不足: 出力品質が下がった場合は、そのコマンドをより上位の階層に移動してください。
  • 高速モデルへの過度な依存: より小型で高速なモデルは、コンテキストウィンドウが狭く、推論能力も弱い場合があります。振り分け先の具体的なモデルの制限を確認してください。
  • API キー管理: すべてのプロバイダーキーが有効で、残高が十分にあることを確認してください。

2. Space の連結とコンテキストオーケストレーション​

難易度: エキスパート 所要時間: セットアップ45分、その後は状況により変動 前提条件: 異なる知識ドメインを持つ Space を3つ以上作成済み

シナリオ​

法務コンプライアンスの知識、技術仕様、事業戦略を必要とする、包括的な提案書を準備しているとします。各知識ドメインはそれぞれ別の Space にあります。ファイルを統合することなく、それらを連携させる必要があります。

ワークフローアーキテクチャ​

ステップバイステップのワークフロー​

ステップ1: ドメインごとの Space を作成する​

  1. Legal Space: コンプライアンス文書、契約テンプレート、規制ガイドラインをアップロードします。
  2. Technical Space: API ドキュメント、技術仕様、アーキテクチャ図をアップロードします。
  3. Business Space: 価格表、事例、競合分析をアップロードします。

ステップ2: セクションごとのコマンドを作成する​

コマンド: "Draft Compliance Section"

Using the regulatory requirements and compliance standards in the Space,
draft a compliance section for a proposal that addresses:
- Data protection requirements
- Industry-specific regulations
- Certification requirements

Format as formal proposal text with numbered sections.

割り当て先: Legal Space

コマンド: "Draft Technical Architecture"

Based on the technical specifications and API documentation,
create a technical architecture section covering:
- System integration approach
- Security architecture
- Scalability considerations

Include diagrams in ASCII format where helpful.

割り当て先: Technical Space

コマンド: "Draft Business Case"

Using the pricing models and case studies, draft a business case section:
- ROI analysis framework
- Competitive positioning
- Success metrics

Reference specific case study outcomes where applicable.

割り当て先: Business Space

ステップ3: Space を連結したワークフローを実行する​

  1. Legal Space を有効化 > "Draft Compliance Section" を実行 > 出力を保存します。
  2. Technical Space を有効化 > "Draft Technical Architecture" を実行 > 出力を保存します。
  3. Business Space を有効化 > "Draft Business Case" を実行 > 出力を保存します。

ステップ4: Space をまたいで統合する​

Space を必要としない "Meta-Synthesis" コマンドを作成します:

コマンド: "Synthesize Proposal Sections"

I have the following sections from different domains:

{{input_content}}

Create an executive summary that:
1. Highlights the key points from each section
2. Identifies connections between technical, legal, and business aspects
3. Provides a cohesive narrative for decision-makers

Output as a 2-page executive summary.

その後、3つの出力すべてを入力に貼り付けて、統合コマンドを実行します。

複数の Space からの変数の挿入​

上級ユーザー向けに、明示的なファイル参照を含むマスターコマンドを作成します:

Review this proposal draft: {{input_content}}

Cross-reference with:
- Compliance: {{compliance_checklist_pdf}}  [from Legal Space]
- Technical: {{api_v3_spec_md}}             [from Technical Space]
- Pricing: {{enterprise_pricing_xlsx}}      [from Business Space]

Identify any inconsistencies or gaps.

注記: これには、対象のファイルが現在アクティブな Space 内にあるか、複数の Space にまたがるコマンド(高度な設定)を使用している必要があります。

プロのヒント​

  • "Meta-Space" を作る: 他の Space の要約やインデックスだけをまとめた Space です。
  • 命名を統一する: ファイル名にドメインの接頭辞(legal_、tech_、biz_)を付けると、変数の挿入がしやすくなります。
  • Space をバージョン管理する: 重要なドキュメント更新の前に、古いバージョンをアーカイブします。

起こりうる落とし穴​

  • コンテキストウィンドウの制限: 複数の Space を組み合わせるとトークン上限を超えることがあります。Compact 機能を使用してください。
  • 古いデータ: 重要なワークフローの前に、すべての Space が最新の状態であることを確認してください。
  • 切り替えのオーバーヘッド: 頻繁な Space の切り替えは、作業の流れを妨げることがあります。

3. 高度なコマンドコンポジション​

難易度: エキスパート 所要時間: チェーンごとに20分のセットアップ 前提条件: 変数の理解、中級レベルのコマンド作成経験

シナリオ​

構造化データ(JSON、Markdown のテーブル)を出力し、他のコマンドや外部ツールで利用できる、高度なコマンドチェーンを作成する必要があります。

ワークフローアーキテクチャ​

パターン1: 構造化データの抽出​

コマンド: "Extract Meeting Actions"

Analyze this meeting transcript and extract all action items.

Output ONLY valid JSON in this exact format:
{
  "meeting_date": "YYYY-MM-DD",
  "action_items": [
    {
      "owner": "Person Name",
      "task": "Task description",
      "due_date": "YYYY-MM-DD or null",
      "priority": "high|medium|low"
    }
  ]
}

Transcript:
{{input_content}}

パターン2: JSON から Markdown への変換​

コマンド: "Actions to Markdown Table"

Convert this JSON action items list to a Markdown table:

{{input_content}}

Output format:
| Owner | Task | Due Date | Priority |
|-------|------|----------|----------|
| ...   | ...  | ...      | ...      |

Include a summary row with total counts per priority level.

パターン3: Space のコンテキストを使った自己参照プロンプト​

コマンド: "Apply Style Guide"(Space のコンテキストを使用)

Rewrite the following text according to the style rules in my Space:

Text to rewrite:
{{input_content}}

Style requirements from Space:
{{style_guide_md}}

Additional rules:
1. Maintain the original meaning
2. Flag any terms that need glossary definitions
3. Output the rewritten text followed by a "CHANGES MADE:" section

パターン4: 複数ステップのチェーンコマンド​

複数の操作を明示的につなげたコマンドを作成します:

コマンド: "Full Content Pipeline"

Process this content through the following stages:

INPUT:
{{input_content}}

STAGE 1 - ANALYSIS:
Identify the following:
- Main topic (1 sentence)
- Key points (bullet list)
- Target audience
- Tone assessment

STAGE 2 - ENHANCEMENT:
Based on the analysis, improve the content by:
- Strengthening weak arguments
- Adding transitions
- Improving clarity

STAGE 3 - FORMATTING:
Format the enhanced content as:
- Headline (max 10 words)
- Subheadline (max 20 words)
- Body (with H2 sections)
- Call to action

Output all three stages clearly separated with markdown headers.

プロのヒント​

  • JSON の検証: 抽出した JSON は、下流のツールで使用する前にバリデーターでテストします。
  • エスケープ処理: インジェクション問題を防ぐため、コードブロックには三重バッククォートを使用します。
  • 決定論的な出力: 構造化データの場合は、temperature を 0.1〜0.3 に設定します。

起こりうる落とし穴​

  • フォーマットのずれ: AI が正確な JSON スキーマから逸脱することがあります。明示的な例を含めてください。
  • トークンの肥大化: 複数ステージのコマンドはより多くのトークンを消費します。使用状況を監視してください。
  • エラーの伝播: ステージ1の出力が悪いと、その影響がチェーン全体に波及します。

4. エンタープライズワークフロー統合​

難易度: エキスパート 所要時間: 初期セットアップに2〜4時間 前提条件: 管理者権限、標準化されたチームプロセス

シナリオ​

チームには、複数のユーザーにわたって一貫した AI 支援ワークフローが必要です。コンプライアンスのため、監査ログを備えた標準化されたコマンドライブラリを作成したいと考えています。

ワークフローアーキテクチャ​

ステップ1: 標準化されたコマンドライブラリを作成する​

命名規則: [DEPT]-[CATEGORY]-[ACTION]

  • LEGAL-CONTRACT-Review
  • LEGAL-NDA-Generate
  • HR-POLICY-Summarize
  • SALES-PROPOSAL-Draft

監査コンプライアンス用のコマンドテンプレート:

[AUDIT HEADER]
Department: {{department}}
Document Type: {{doc_type}}
Processing Date: {{current_date}}
Operator: To be logged by Rephlo History

[TASK]
{{actual_instruction}}

[OUTPUT REQUIREMENTS]
1. Include a "Compliance Notes" section
2. Flag any regulatory concerns
3. Mark confidence level (High/Medium/Low)
4. List sources referenced

ステップ2: コマンドライブラリをエクスポートする​

  1. Commands ページに移動します。
  2. Export(右上のメニュー)をクリックします。
  3. 含めるコマンドをすべて選択します。
  4. JSON ファイルとしてエクスポートします: company-commands-v1.0.json。

ステップ3: チームに配布する​

オプションA: 直接インポート

  • JSON ファイルを社内のファイル共有経由で共有します。
  • 各メンバーが Commands > Import > ファイルを選択、の順に操作します。

オプションB: ポリシー用の共有 Space

  • すべてのコンプライアンス文書を含む "Company Policies" という Space を作成します。
  • Space の構成をエクスポートします。
  • チームは Commands と Space の両方をインポートします。

ステップ4: レポート用のバッチ処理​

コマンド: "Batch Compliance Check"

Review the following documents for compliance with our policies:

Documents to review:
{{input_content}}

For EACH document, provide:
1. Document identifier
2. Compliance status: PASS / FAIL / NEEDS REVIEW
3. Issues found (if any)
4. Recommended actions

Output as a CSV table:
Document ID, Status, Issues, Actions

ステップ5: 監査ログの管理​

  1. History ページを開きます。
  2. フィルターを使い、期間・コマンド・ユーザーごとに表示します。
  3. コンプライアンスレポート用に、履歴を CSV としてエクスポートします。
  4. エクスポートしたファイルを、文書管理システムに保存します。

プロのヒント​

  • コマンドをバージョン管理する: 変更履歴を追跡できるよう、コマンド名にバージョン(v2.1)を含めます。
  • 重要なコマンドをロックする: コンプライアンス上重要なコマンドは、管理者設定で編集不可にマークします。
  • 定期的な監査: History のエクスポートを毎月レビューするようスケジュールします。

起こりうる落とし穴​

  • バージョンのずれ: チームメンバーが共有コマンドを変更してしまうことがあります。命名規則を使用してください。
  • 古い Space: ポリシー文書がチームの全 Space で更新されていることを確認してください。
  • 不完全な監査ログ: ユーザーが Rephlo を経由しない場合、一部の操作が記録されないことがあります。

5. AI支援コードレビューパイプライン​

難易度: エキスパート 所要時間: セットアップ30分 前提条件: コーディング標準を含む Technical Space、画像認識(vision)対応のプロバイダー

シナリオ​

スクリーンショットからのコード(レガシーシステムや直接アクセスできない PR など)をレビューし、抽出・分析して改善提案を生成し、ドキュメントを作成する必要があります。

ワークフローアーキテクチャ​

ステップバイステップのワークフロー​

ステップ1: Code Standards Space を作成する​

  1. Space を作成します: "Code Standards"。
  2. コーディング標準のドキュメントをアップロードします:
    • coding-guidelines.md
    • security-checklist.md
    • naming-conventions.md
    • performance-patterns.md

ステップ2: パイプラインコマンドを作成する​

コマンド1: "Extract Code from Screenshot"(Vision コマンド)

Extract all code visible in this screenshot.

Output requirements:
1. Preserve exact formatting and indentation
2. Use appropriate syntax highlighting markers
3. Note any text that's unclear with [UNCLEAR: best guess]
4. Identify the programming language

Output format:
```[language]
[extracted code]
```

Confidence: [High/Medium/Low]

コマンド2: "Review Code Quality"(Code Standards Space を使用)

Review this code against our coding standards:

{{input_content}}

Check for:
1. Style guide violations (reference: {{coding_guidelines_md}})
2. Security issues (reference: {{security_checklist_md}})
3. Naming convention violations (reference: {{naming_conventions_md}})
4. Performance anti-patterns (reference: {{performance_patterns_md}})

For each issue found, provide:
- Line number (approximate if from screenshot)
- Severity: CRITICAL / WARNING / INFO
- Description
- Suggested fix

Output as structured list.

コマンド3: "Generate Review Report"

Create a formal code review document from these findings:

{{input_content}}

Report format:

# Code Review Report

## Summary
- Total issues: [count]
- Critical: [count]
- Warnings: [count]
- Info: [count]

## Detailed Findings
[For each issue, format as a table]

## Recommendations
[Prioritized action items]

## Appendix
- Original code reviewed
- Standards referenced

ステップ3: 複数ファイルのレビュー戦略​

関連する複数のファイルをレビューする場合:

コマンド: "Multi-File Architecture Review"

Review these related code files for architectural consistency:

{{input_content}}

Analyze:
1. Dependency relationships
2. Circular dependency risks
3. Separation of concerns
4. Interface consistency
5. Error handling patterns

Create a dependency diagram using ASCII:
[Draw module relationships]

Highlight any architectural concerns.

ステップ4: バージョン管理との連携​

レビューレポートを生成した後:

  1. Markdown レポートをコピーします。
  2. PR のコメントやコードレビューツールに貼り付けます。
  3. 監査のため、History のエントリ ID を参照します。

プロのヒント​

  • スクリーンショットをまとめて撮る: パイプラインを開始する前に、関連するコード画面をすべてキャプチャします。
  • 命名を統一する: スクリーンショットのファイル名には行番号の範囲を含めます。
  • レビューテンプレートを作る: セキュリティ、パフォーマンス、スタイルなど、レビュー種別ごとに異なるコマンドを用意します。

起こりうる落とし穴​

  • OCR エラー: Vision による抽出は、細かい構文を見落とすことがあります。重要なコードは必ず確認してください。
  • コンテキストの欠落: スクリーンショットには git の履歴情報がありません。テキストによる説明で補ってください。
  • 大きなファイル: 非常に長いコードファイルは、分割して処理する必要がある場合があります。

6. 多言語コンテンツパイプライン​

難易度: エキスパート 所要時間: セットアップ1時間、その後継続的な改善 前提条件: 多言語用語集の Space、ネイティブスピーカーによるレビュー(任意)

シナリオ​

ブランドの一貫性、文化的な適切さ、用語の正確さを保ちながら、5言語以上で公開する必要のあるコンテンツを作成しています。

ワークフローアーキテクチャ​

ステップ1: Terminology Space を作成する​

Space: "Brand Terminology"

アップロードするもの:

  • brand-glossary.csv (term, EN, ES, FR, DE, JA, ZH)
  • style-guide-translations.md
  • cultural-notes.md
  • forbidden-terms.md

用語集フォーマットの例:

term,EN,ES,FR,DE,JA,ZH
Product Name,SuperApp,SuperApp,SuperApp,SuperApp,SuperApp,SuperApp
Free Trial,Free Trial,Prueba Gratuita,Essai Gratuit,Kostenlose Testversion,無料トライアル,免费试用

ステップ2: 翻訳コマンドを作成する​

コマンド: "Translate to Spanish"(Brand Terminology Space を使用)

Translate this content to Spanish (Spain variant):

{{input_content}}

Requirements:
1. Use formal "usted" form
2. Apply terminology from: {{brand_glossary_csv}}
3. Maintain markdown formatting
4. Preserve any URLs or code blocks unchanged
5. Flag any culturally sensitive content with [REVIEW: reason]

Output the translation directly, no explanations.

コマンド: "Localize for Japan"

Adapt this Spanish translation for Japanese audience:

{{input_content}}

Localization requirements:
1. Convert to appropriate politeness level (teineigo)
2. Adapt examples to Japanese context
3. Use terminology from: {{brand_glossary_csv}}
4. Adjust date/time/currency formats
5. Note any Western concepts needing explanation with [EXPLAIN: term]

Cultural notes to reference: {{cultural_notes_md}}

ステップ3: Space を使った翻訳メモリ​

翻訳メモリとして機能する、言語ごとの Space を作成します:

Space: "Translation Memory - Spanish"

  • これまでに翻訳・承認済みのコンテンツをアップロードします。
  • AI はこれらを参照し、今後の翻訳の一貫性を保ちます。

コマンド: "Translate with Memory"

Translate this to Spanish, maintaining consistency with previous translations:

New content:
{{input_content}}

Reference our translation history in this Space for:
- Consistent terminology
- Matching tone and style
- Previously approved phrases

Flag any NEW terminology not in our translation memory with [NEW: term].

ステップ4: 品質検証​

コマンド: "Translation Quality Check"

Compare this translation against the original and our standards:

ORIGINAL (English):
[Paste original]

TRANSLATION (Spanish):
{{input_content}}

Check for:
1. Meaning accuracy (any mistranslations?)
2. Terminology consistency (using glossary: {{brand_glossary_csv}})
3. Natural flow (reads naturally to native speakers?)
4. Forbidden terms (checking: {{forbidden_terms_md}})
5. Format preservation (markdown, links intact?)

Output a quality score (1-10) with specific issues found.

ステップ5: バッチ処理​

大量のコンテンツセットの場合:

コマンド: "Batch Translate Strings"

Translate these UI strings to Spanish:

{{input_content}}

Input format: key=English value
Output format: key=Spanish value

Use glossary: {{brand_glossary_csv}}
Maintain exact key names.
Do not translate placeholder variables like {username} or {{count}}.

プロのヒント​

  • 1つの Space に1言語: 翻訳メモリを分けておくと、コンテキストがすっきりします。
  • 用語集をバージョン管理する: ブランド用語が変わったら、用語集のバージョンを更新します。
  • 逆翻訳テスト: 英語に翻訳し直して、意味のずれがないか確認します。

起こりうる落とし穴​

  • コンテキストの欠落: 短い文字列は、コンテキストがないと誤って翻訳されることがあります。
  • 用語集の競合: 同じ用語でも、文脈によって異なる訳語が必要な場合があります。
  • 文字数の制限: 翻訳後のテキストは長くなることがあります。UI の制約を考慮してください。

7. リサーチシンセシスワークフロー​

難易度: エキスパート 所要時間: プロジェクトごとに1〜2時間 前提条件: PDF 取り込み機能、引用管理システム

シナリオ​

20件以上のソースにわたる学術的またはビジネス上のリサーチを行っています。重要な知見を抽出し、テーマを特定し、洞察を統合しながら、適切な引用を維持する必要があります。

ワークフローアーキテクチャ​

ステップバイステップのワークフロー​

ステップ1: 引用付きのリサーチ Space を作成する​

Space: "Market Research 2025"

PDF をアップロードする際は、内容が分かりやすい名前を使います:

  • Smith2024_AI_Market_Analysis.pdf
  • Jones2023_Consumer_Behavior_Study.pdf
  • TechReport2024_Industry_Trends.pdf

ステップ2: 引用付きで要点を抽出する​

コマンド: "Extract Findings with Citations"

Extract the key findings from this research document:

{{input_content}}

For each finding, provide:
1. Finding summary (1-2 sentences)
2. Direct quote (if available)
3. Page number or section
4. Methodology used
5. Limitations noted by authors

Output format:
### Finding 1: [Title]
- **Summary**: [text]
- **Quote**: "[direct quote]" (p. XX)
- **Method**: [methodology]
- **Limitations**: [any caveats]
- **Citation**: [Author, Year, Title]

ステップ3: クロスリファレンスマトリクスを作成する​

コマンド: "Create Cross-Reference Matrix"

Analyze these research summaries and create a cross-reference matrix:

{{input_content}}

Matrix format:
| Theme/Topic | Source 1 | Source 2 | Source 3 | Consensus |
|-------------|----------|----------|----------|-----------|
| [Theme]     | [✓/✗/~]  | [✓/✗/~]  | [✓/✗/~]  | [Yes/No/Mixed] |

Legend:
✓ = Supports
✗ = Contradicts
~ = Neutral/No data

After the matrix, provide:
1. Strong consensus areas (all sources agree)
2. Contested areas (sources disagree)
3. Research gaps (no sources address)

ステップ4: 文献レビューを統合する​

コマンド: "Generate Literature Review Section"

Using the research summaries and cross-reference matrix, write a literature review section:

{{input_content}}

Structure:
1. Introduction to the topic
2. Thematic analysis (organize by theme, not by source)
3. Areas of consensus
4. Areas of debate
5. Identified gaps
6. Conclusion

Requirements:
- Use APA 7th edition in-text citations
- Include all sources from the matrix
- Maintain academic tone
- 1500-2000 words

ステップ5: 参考文献リストを生成する​

コマンド: "Format Bibliography"

Generate a properly formatted bibliography from these citations:

{{input_content}}

Format: APA 7th Edition

Order: Alphabetical by first author's last name

Include:
- All in-text citations mentioned
- DOIs where available
- Access dates for web sources

Output as a formatted reference list.

プロのヒント​

  • 大きな PDF を分割する: PDF が100ページを超える場合は、セクションごとに個別に抽出します。
  • 命名を統一する: AuthorYear_ShortTitle.pdf の形式にすると、引用の追跡がしやすくなります。
  • サブ Space を作る: 非常に大規模なプロジェクトでは、サブトピックごとに Space を作成します。

起こりうる落とし穴​

  • 引用の正確さ: AI が生成した引用は、必ず元のソースと照合してください。
  • ハルシネーションによる引用: AI は、もっともらしいが誤った直接引用を生成することがあります。
  • 新しさへの偏り: AI は新しいソースを過度に重視することがあります。バランスの取れたカバレッジを確保してください。

8. プライバシー優先の機密データ処理​

難易度: エキスパート 所要時間: 初期セットアップに1〜2時間 前提条件: Ollama がインストール済み、ローカルモデルがダウンロード済み

シナリオ​

クラウドの AI プロバイダーに送信できない機密データ(PII、PHI、財務記録)を扱っています。コンプライアンスを維持しながら、このデータをローカルで処理する必要があります。

ワークフローアーキテクチャ​

ステップバイステップのセットアップ​

ステップ1: Ollama をインストールして設定する​

  1. ollama.com から Ollama をダウンロードします。
  2. インストールしてサービスを起動します。
  3. 十分な性能のモデルを取得します: ollama pull llama3.1:8b または ollama pull deepseek-coder:33b。
  4. 確認: ollama list でモデルが表示されることを確かめます。

ステップ2: Rephlo を Ollama 専用に設定する​

  1. Settings > Providers を開きます。
  2. Ollama をローカルエンドポイント(http://localhost:11434)で設定します。
  3. すべてのクラウドプロバイダーの API キーを無効化または削除します。
  4. 接続をテストします。

ステップ3: プライバシーに配慮したコマンドを作成する​

コマンド: "Anonymize PII"

Anonymize all personally identifiable information in this text:

{{input_content}}

Replacement rules:
- Names: Replace with [NAME_1], [NAME_2], etc.
- SSN: Replace with [SSN_REDACTED]
- Phone: Replace with [PHONE_REDACTED]
- Email: Replace with [EMAIL_REDACTED]
- Address: Replace with [ADDRESS_REDACTED]
- DOB: Replace with [DOB_REDACTED]

Create a reference key at the end:
[NAME_1] = First name encountered (DO NOT include actual name)

コマンド: "Summarize Medical Record"

Summarize this medical record for clinical review:

{{input_content}}

Include:
- Chief complaint
- Relevant history
- Current medications
- Assessment and plan

PRIVACY NOTICE: This command runs entirely locally. No PHI is transmitted.

Output in SOAP note format.

コマンド: "Analyze Financial Statement"

Analyze this financial statement for anomalies:

{{input_content}}

Check for:
1. Unusual transaction patterns
2. Round number red flags
3. Timing irregularities
4. Missing documentation indicators

Format as a compliance review checklist.

ステップ4: コンプライアンス用ドキュメントを作成する​

コマンド: "Generate Processing Log"

Create a data processing log entry for compliance:

Processing Details:
- Data Type: [Auto-detect from input]
- Date/Time: [Current]
- Purpose: {{purpose}}
- Retention Policy: [Per company guidelines]

{{input_content}}

Generate a processing record in the format required by [GDPR/HIPAA/SOC2].
Include: Legal basis, data minimization confirmation, and storage location.

ステップ5: エアギャップ検証​

処理中にネットワーク通信が発生していないことを確認します:

  1. インターネットを切断します(Wi-Fi をオフ、有線 LAN を抜く)。
  2. サンプルの機密データでテストコマンドを実行します。
  3. コマンドが正常に完了することを確認します。
  4. これにより、純粋にローカルで処理されていることが確認できます。

プロのヒント​

  • モデルの選択: 一般的なタスクには llama3.1:8b、コード分析には deepseek-coder:33b を使用します。
  • 定期的な更新: (機密性のないネットワーク上で)Ollama とモデルを定期的に更新します。
  • ユーザープロファイルを分ける: 機密データの作業には、専用の Windows ユーザープロファイルを使用します。

起こりうる落とし穴​

  • 品質の低下: ローカルモデルは、GPT-5.4 や Claude Sonnet 4.6 のような最先端のクラウドモデルには及ばないことがあります。期待値を調整してください。
  • ハードウェアの制約: 大きなモデルには十分な RAM(16GB以上)が必要で、GPU があればより高速になります(任意)。
  • History の保存: Rephlo の History はローカルに保存されます。ディスク暗号化が有効になっていることを確認してください。

9. リアルタイムミーティングアシスタント​

難易度: エキスパート 所要時間: セットアップ15分 前提条件: デュアルモニターまたは画面分割、高速なプロバイダー(Gemini 3.5 Flash や GPT-5.4 Mini のような低レイテンシモデルを推奨)

シナリオ​

ライブミーティング中に、議論をすばやく要約し、アクションアイテムを抽出し、フォローアップメールをリアルタイムで下書きする必要があります。

ワークフローアーキテクチャ​

ステップバイステップのセットアップ​

ステップ1: ミーティング用のコマンドグループを作成する​

グループ: "Meeting Tools"(稲妻の絵文字、黄色)

グループ内のコマンド:

  • Quick Summarize
  • Extract Actions
  • Draft Follow-up
  • Clarify Point
  • Translate(国際的なミーティング向け)

ステップ2: 速度を最適化する​

  1. Meeting Tools グループのデフォルトプロバイダーとして、Gemini 3.5 Flash や GPT-5.4 Mini のような低レイテンシモデルを設定します(ほぼ即時の応答)。
  2. グローバルホットキーを、片手で押せるものに設定します: Ctrl+\ または Ctrl+.
  3. Settings で "Copy to Clipboard Automatically" を有効にします。

ステップ3: ミーティング専用のコマンドを作成する​

コマンド: "Quick Summarize"(5秒未満)

Summarize this in 2-3 bullet points. Be extremely concise:

{{input_content}}

コマンド: "Extract Actions"

Extract action items from this meeting discussion:

{{input_content}}

Format each as:
[ ] [Owner] - [Task] - [Due date if mentioned]

If no owner is clear, use [UNASSIGNED].

コマンド: "Draft Follow-up Email"

Draft a brief follow-up email based on this meeting discussion:

{{input_content}}

Structure:
- Subject line
- Thank attendees
- Key decisions made
- Action items (with owners)
- Next steps

Keep it under 200 words. Professional but warm tone.

コマンド: "Clarify Point"

Someone just said this in a meeting and I need to understand it better:

{{input_content}}

Provide:
1. What they likely mean (1 sentence)
2. A clarifying question I could ask
3. Related context that might be relevant

ステップ4: リアルタイムのワークフロー​

ミーティング中:

  1. 重要なポイントを聞き取ります。
  2. キーフレーズをメモ帳に入力またはペーストします。
  3. テキストを選択し、ホットキーを押します。
  4. "Quick Summarize" または "Clarify Point" を実行します。
  5. 得られた洞察を、その場ですぐ議論に活かします。

ミーティング直後:

  1. ミーティングの全メモを貼り付けます。
  2. "Extract Actions" を実行します。
  3. "Draft Follow-up Email" を実行します。
  4. ミーティング終了から5分以内にフォローアップを送信します。

プロのヒント​

  • 事前に準備する: Rephlo を開き、Meeting Tools グループを表示しておきます。
  • 文字起こしを活用する: ミーティングプラットフォームに文字起こし機能があれば、それを入力として使用します。
  • ホットキーを練習する: リアルタイムでの利用には、体で覚えることが欠かせません。

起こりうる落とし穴​

  • 注意散漫: ミーティング中に Rephlo に集中しすぎると、内容を聞き逃すことがあります。
  • 音声の遅延: 文字起こしがライブの議論に遅れることがあります。
  • コンテキストの不足: 短い断片は、全体の文脈がないと誤解されることがあります。

10. クリエイティブライティングワークフロー​

難易度: エキスパート 所要時間: 可変(継続的なプロジェクト) 前提条件: スタイルガイドの Space、キャラクター・世界観設定ドキュメント

シナリオ​

小説や長編コンテンツを執筆しており、何百ページにもわたってキャラクター、プロットのポイント、文体の一貫性を保つ必要があります。

ワークフローアーキテクチャ​

ステップバイステップのセットアップ​

ステップ1: World Bible の Space を作成する​

Space: "Novel - Project Nightfall"

含めるドキュメント:

  • characters.md - 声のサンプル付きの完全なキャラクタープロフィール
  • plot-outline.md - 章ごとのあらすじ
  • world-rules.md - 魔法体系、テクノロジー、社会のルール
  • locations.md - 舞台設定の説明
  • timeline.md - 時系列の出来事
  • style-guide.md - 文体、視点(POV)のルール、時制

キャラクタープロフィールのフォーマット:

# SARAH CHEN

## Basics
- Age: 32
- Occupation: Quantum physicist
- Appearance: Short black hair, wire-frame glasses, always wears her mother's jade pendant

## Personality
- Analytical but empathetic
- Dry sense of humor
- Avoids conflict but fierce when cornered

## Speech Patterns
- Uses scientific metaphors
- Rarely uses contractions when stressed
- Catchphrase: "That's statistically improbable."

## Arc
- Chapter 1-5: Skeptic
- Chapter 6-12: Reluctant believer
- Chapter 13-20: Leader

## Voice Sample
"The probability of two people meeting in a city of eight million isn't romantic—it's just math. But math never explained why I couldn't stop thinking about him."

ステップ2: 章ごとのコマンドを作成する​

コマンド: "Draft Chapter Scene"

Write a scene for Chapter {{chapter_number}} based on:

Scene brief:
{{input_content}}

Requirements:
1. Maintain POV: [Third person limited, Sarah's perspective]
2. Match tone: [Reference {{style_guide_md}}]
3. Include characters: [Check {{characters_md}} for voice consistency]
4. Setting: [Check {{locations_md}} for accurate details]
5. Plot alignment: [Verify against {{plot_outline_md}}]

Write approximately 1500 words. End on a hook for the next scene.

コマンド: "Character Voice Check"

Review this dialogue for character voice consistency:

{{input_content}}

Cross-reference with character profiles in {{characters_md}}.

For each character's lines, check:
1. Speech pattern match (contractions, vocabulary, etc.)
2. Personality alignment
3. Arc-appropriate attitude (based on chapter)

Flag any lines that feel out of character with [OOC: reason].

コマンド: "Continuity Check"

Check this chapter excerpt for continuity errors:

{{input_content}}

Verify against:
- Timeline: {{timeline_md}}
- Previous chapters: [Note any callbacks]
- World rules: {{world_rules_md}}

Flag:
1. Time inconsistencies
2. Character knowledge errors (character shouldn't know X yet)
3. World-building violations
4. Dropped plot threads

Output as a continuity report.

ステップ3: スタイルガイドの徹底​

コマンド: "Apply Style Guide"

Edit this passage to match my writing style:

{{input_content}}

Style requirements from {{style_guide_md}}:
- Sentence rhythm: [Varied, mix short punch with flowing descriptions]
- Dialogue tags: [Said, asked primarily; avoid adverbs]
- Description ratio: [30% description, 40% dialogue, 30% action]
- POV discipline: [Strict limited; no head-hopping]

Rewrite to match these guidelines while preserving the scene's intent.

ステップ4: 章ごとのワークフロー​

各章について:

  1. その章のプロットアウトラインを確認します。
  2. "Draft Chapter Scene" を使って、シーンごとに下書きします。
  3. 会話文に "Character Voice Check" を実行します。
  4. 章全体に "Continuity Check" を実行します。
  5. 最終的な仕上げとして "Apply Style Guide" を実行します。
  6. 今後の参照のため、その章を Space に追加します。

ステップ5: シリーズバイブルの維持管理​

各章を完成させた後:

コマンド: "Update Series Bible"

Based on this completed chapter, identify any updates needed for the series bible:

{{input_content}}

Check for:
1. New character revelations → Update {{characters_md}}
2. New locations introduced → Update {{locations_md}}
3. Timeline events → Update {{timeline_md}}
4. World-building details → Update {{world_rules_md}}

Output as a list of suggested updates with specific text changes.

プロのヒント​

  • 下書きをバージョン管理する: 各下書きのバージョンを、章番号とバージョン番号を付けて Space に保存します。
  • キャラクターの声のウォームアップ: 会話文を書く前に、そのキャラクターの声のサンプルを読み返します。
  • アウトラインの柔軟性: 物語の展開に合わせてプロットアウトラインを更新します。Space には最新の設定(canon)が反映されます。

起こりうる落とし穴​

  • AI への過度な依存: AI はあくまで補助であり、あなた自身の創作的な声を置き換えるものではありません。
  • 一貫性のずれ: Space が大きくなるにつれ、古いエントリが新しいものと矛盾することがあります。
  • トークン上限: 非常に長い小説は、Space の容量を超えることがあります。完結したアークはアーカイブしてください。

まとめ: パワーユーザーの原則​

これらの高度なワークフローを習得したら、次の原則を心に留めておいてください。

  1. 適切なタスクに適切なプロバイダーを: 単純なタスクにプレミアムモデルを使わないようにします。
  2. 記憶としての Spaces: あなたの Spaces は「第二の脳」です。整理に時間をかける価値があります。
  3. レシピとしての Commands: 繰り返し行うワークフローのために、再利用可能なコマンドチェーンを構築します。
  4. すべてを監査する: コンプライアンスと継続的な改善のために History を活用します。
  5. 機密データはローカルで: メールで送りたくないデータには、デフォルトで Ollama を使用します。
  6. 反復して磨き上げる: これらのワークフローは進化していきます。コマンドは定期的に更新してください。

このチュートリアルは、Rephlo に習熟したユーザー向けの高度なテクニックを扱っています。これらの概念になじみがない場合は、基礎的なチュートリアルから始めてください。

関連ドキュメント: