AIエージェントを強化する『合成データ』作成の実践的Tips集

```python def debias_loop(dataset, max_iterations=3): for i in range(max_iterations): audit = bias_auditor.run(dataset) high_severity = [b for b in audit.biases if b.severity == "high"] if not high_severity: break for bias in high_severity: supplemental = generator.run( constraints=bias.remediation, count=len(dataset) // 10 ) dataset = dataset + supplemental return dataset ``` Tip: バイアス修正のためにデータを追加すると、別の軸でバイアスが生じる可能性があります。反復ごとにすべての軸を再監査するのがポイントです。 7. Planner / Generator / Validator の三層エージェント構成で合成データ品質を向上させる ![](https://cdn-ak.f.st-hatena.com/images/fotolife/s/shibuiyusuke/20260310/20260310131916.png) 7.2 Planner の設計 Planner はデータセット全体の「設計図」を作成します。重要なのは、生成を一括で行うのではなく、バッチに分割して逐次的に多様性を確保する点です。 ``` PLANNER_PROMPT = """ 以下の要件に基づき、合成データの生成計画を作成してください。 目標: カスタマーサポートチケット 1000件 カテゴリ分布: billing(30%), shipping(25%), product_defect(20%), account(15%), other(10%) 重症度分布: severity 1-5 が均等分布 言語: 日本語 80%, 英語 20% 計画はバッチ単位（各50件）で作成してください。 各バッチには以下を含めてください: - 対象カテゴリと件数 - 特に含めるべきエッジケース - 前バッチの Validator レポートを踏まえた修正指示 """ ``` 7.3 Validator の差し戻し判定 Validator は単に合格/不合格を判定するだけでなく、不合格データの「修正コスト」を推定します。修正コストが高いデータは再生成、低いデータは LLM による自動修正に回します。 ```python class ValidationResult(BaseModel): record_id: str is_valid: bool issues: list[str] fix_cost: Literal["low", "medium", "high"] # low: 自動修正可能, medium: 部分再生成, high: 全体再生成 ``` 7.4 Tips: 三層構成の運用ノウハウ * **Planner にデータセット全体の統計を見せる**: バッチごとに現時点のデータセット統計を渡すことで、不足している領域を自動的に補填できます。 * **Generator のモデルと Validator のモデルを変える**: Generator に Haiku、Validator に Sonnet を使うといったコスト最適化が可能です。 * **Validator の合格率をモニタリングする**: 合格率が 70% を下回ったらプロンプトに問題があります。90% 以上なら Validator の基準が緩すぎる可能性を疑いましょう。 8. エージェントに「ペルソナ」を与えてリアルな利用者や業界のデータを合成する LLM に「あなたは30代の営業マネージャーです」と役割を指示するだけで、語彙の選択、関心事、行動パターンがそのペルソナに沿ったものに変化します。これを合成データ生成に応用すると、ユーザーセグメントごとにリアルなデータを生成する手助けとなります。 8.2 ペルソナ定義のテンプレート ペルソナは曖昧な人物像ではなく、データ生成に直結する属性を明示的に定義します。 ```python class Persona(BaseModel): """合成データ生成用ペルソナ""" role: str # "製造業の品質管理エンジニア" experience_years: int tech_literacy: Literal["low", "medium", "high"] communication_style: str # "簡潔で技術用語を多用" typical_goals: list[str] # ["不良率の低減", "検査工程の自動化"] common_frustrations: list[str] # ["レガシーシステムとの連携"] vocabulary_hints: list[str] # ["SPC", "Cp値", "工程能力指数"] error_patterns: list[str] # ["専門略語の過多", "前提知識の省略"] ``` 8.3 ペルソナ × シナリオのマトリクス生成 ペルソナ単体よりも、ペルソナとシナリオを掛け合わせたマトリクスが強力です。 ```python personas = [ Persona(role="新卒エンジニア", tech_literacy="medium", ...), Persona(role="CTO", tech_literacy="high", ...), Persona(role="非技術職の営業", tech_literacy="low", ...), ] scenarios = [ "本番環境でエラーが発生した", "新機能の要件を整理したい", "パフォーマンスの劣化を調査したい", ] for persona in personas: for scenario in scenarios: prompt = f""" あなたは「{persona.role}」です。 技術リテラシー: {persona.tech_literacy} コミュニケーションスタイル: {persona.communication_style} よく使う用語: {', '.join(persona.vocabulary_hints)} 以下の状況で、社内チャットツールに投稿するメッセージを生成してください: 状況: {scenario} このペルソナらしい語彙・文体・情報の粒度で書いてください。 """ ``` 8.4 業界特化ペルソナの自動生成 ペルソナ自体を LLM に生成させることで、自分のドメイン知識の限界を超えたペルソナを獲得できます。 ``` PERSONA_GENERATOR_PROMPT = """ {industry}業界において、以下の条件でペルソナを5つ生成してください。 条件: - 職種・役職は重複させない - 技術リテラシーのレベルをばらけさせる - 各ペルソナは最低3つの「ありがちな困りごと」を持つ - その業界特有の専門用語をvocabulary_hintsに含める 出力は以下の形式に従ってください: {schema} """ ``` 8.5 Tips: ペルソナベース生成の落とし穴 * **ステレオタイプの増幅**: 「新卒 → 技術力が低い」のような紋切り型になりがちです。意図的に反ステレオタイプのペルソナを混ぜましょう。 * **ペルソナ間の一貫性**: 同一ペルソナから生成したデータ群の中で文体や語彙が一貫しているかを Critic Agent でチェックします。 * **ペルソナ数の目安**: データセットサイズの 5-10% 程度のユニークペルソナがあると多様性と一貫性のバランスが取れます。 9. 合成データを作る Agent Skill を Agent Skill で作る ― メタ Agent Skill による統一制御 ここまでのセクションでは「1件のデータをいかに高品質に作るか」に焦点を当ててきました。しかし現実のプロジェクトでは、互いに関連する複数のドキュメントを、共通のテーマ・フォーマット・世界観のもとで一括合成する必要があります。たとえば以下のようなケースです。 * ある架空企業の「就業規則」「出張旅費規程」「情報セキュリティポリシー」を整合性を保って同時に生成したい * 患者 100 名分の「診療録」「検査結果」「処方箋」を、同一の医療機関フォーマットで統一して合成したい * SaaS プロダクトの「API リファレンス」「チュートリアル」「FAQ」を同一プロダクトの用語体系で揃えたい これらを個別の Agent Skill（＝単一ドキュメント種別に特化した生成用Agent Skill）で個々に作ると、ドキュメント間でフォーマットが揃わない、用語が不統一、相互参照が破綻する、といった問題が起きます。ここで登場するのがメタ Agent Skillです。 本セクションでは Anthropic の Agent Skills を活用します。Agent Skills は SKILL.md ![](https://cdn-ak.f.st-hatena.com/images/fotolife/s/shibuiyusuke/20260310/20260310131934.png) メタ Skill が「何を統一するか」の横断ルールを `references/` ディレクトリに定義し、個別 Skill はそのルールに従って生成します。これにより、複数ドキュメントの統一合成が可能になります。 9.2 メタ Agent Skill の SKILL.md 以下はメタAgent Skillの例です。重要なのは、Phase 1で統一コンテキストを策定し、保存して後続の処理で活用することです。ここでドキュメント全体のフォーマットやデザイン、用語等を整理することで、共通性をもたせた複数ドキュメントを生成可能にします。 ``` --- name: synthetic-data-orchestrator description: > 複数の関連ドキュメントを共通のテーマ・用語・フォーマットで 統一して合成するメタSkill。ドキュメント間の整合性が必要な 合成データ生成タスクで使用してください。 --- # 複数ドキュメント統一合成オーケストレータ ## Phase 1: 統一コンテキストの策定 `references/unified_context_schema.json` を読み込み、以下を策定： - **用語辞書**: 正規表現と禁止同義語（最低20語） - **フォーマットルール**: 章番号体系、日付・金額表記 - **相互参照マップ**: ドキュメント間の参照関係と種別 策定結果を `references/unified_context.json` に保存。 ## Phase 2: 生成順序の決定 `scripts/resolve_order.py` で相互参照からトポロジカルソート。 循環参照がある場合はスタブ生成モードを使用。 ## Phase 3: 個別 Skill による順次生成 各Skillに統一コンテキストと先行ドキュメントの**必要セクション抜粋のみ**を渡す。 （全文は渡さない — コンテキスト長を圧迫するため） ## Phase 4: 横断的整合性検証 `scripts/cross_validate.py` で用語・参照・フォーマットを検証。 criticalな問題があれば該当ドキュメントを再生成。 ``` 9.3 統一コンテキストと検証スクリプト 統一コンテキストの核となるのは、用語辞書・フォーマットルール・相互参照マップの3つです。 ```json { "terminology": [ { "canonical": "従業員", "forbidden_synonyms": ["社員", "スタッフ", "ワーカー"], "usage_note": "就業規則上の正式名称として統一" } ], "formatting_rules": { "heading_style": "第X条（タイトル）", "date_format": "令和Y年M月D日", "numbering_system": "条 → 項 → 号" }, "cross_references": [ { "source_doc": "employment-regulation", "source_section": "第15条（出張）", "target_doc": "travel-expense", "target_section": "第3条（適用範囲）", "reference_type": "委任" } ] } ``` この定義に基づき、全ドキュメントに対して禁止同義語の出現チェック、参照先セクションの存在確認、日付フォーマットの準拠チェックを決定論的に実行します。Agent Skills のアーキテクチャでは、スクリプトは bash 経由で実行され出力のみがコンテキストに入るため、検証ロジックがどれだけ複雑でもトークンコストは結果分だけで済みます。 9.4 個別ドキュメント生成 Skill の例 メタAgent Skillで生成した統一コンテキストを用いて、合成データを作成します。以下では就業規則を作成するAgent Skillを示しています。就業規則は長文かつ複数ドキュメントにまたがることが多く、全体で矛盾なくフォーマットが統一されていることが求められます。 ``` --- name: gen-regulation description: > 就業規則の合成データを生成するSkill。統一コンテキストが 提供された場合はその用語辞書・フォーマットに厳密に従います。 --- # 就業規則合成 Skill ## 生成手順 1. `references/unified_context.json` の用語辞書・フォーマットルールを読み込む 2. 先行ドキュメントの参照セクション抜粋との整合性を確保 3. 総則〜附則の10章構成で生成（出張条文に旅費規程への委任を含める） ## 品質チェック - [ ] 全条文が `heading_style` に従っているか - [ ] `forbidden_synonyms` が一切含まれていないか - [ ] 相互参照先の条文番号が正確か ## ノイズ注入ガイドライン - 一部条文に「ただし書き」や例外規定を含める - 附則に施行日を記載 - 別表（勤務時間表、賃金テーブル）への参照を含める ``` 9.5 なぜ「Skill で Skill を作る」構造が有効なのか 第一に、段階的処理との相性です。メタ Skill のメタデータ（約数百トークン）だけが常時読み込まれ、個別 Skill も必要な時だけトリガーされます。 第二に、スクリプトによる決定論的な検証です。用語チェックや参照確認は LLM に任せるよりPythonスクリプトでルールベースで行うほうが確実で、スクリプト出力のみがコンテキストに入るためコスト効率も高いです。 第三に、モジュール性です。新しいドキュメント種別の追加は `gen-xxx/SKILL.md` を作成し、`cross_references` を更新するだけです。 9.6 Tips: 統一合成の実践ノウハウ * **用語辞書は「多すぎるくらい」が正解**: `forbidden_synonyms` は多めにリストアップし、生成の自由度を制限します。 * **ルールベース評価とLLM-as-a-Judgeを併用する**: 文字列マッチでは意味的な不整合（「週休2日」と「土日休み」の矛盾など）は見逃します。最終チェックにはLLM-as-a-Judgeを通しましょう。 * **循環参照にはスタブ生成で対処する**: まず循環ドキュメントの「スタブ」（章立てと条番号のみ）を生成し、他方を本生成した後にスタブを差し替えます。 まとめ: 合成データのエンジニアリングは面白い というわけで、LLMやAIエージェントを使って合成データを作る様々なTipsを紹介しました。工夫次第で多様なエンジニアリングや合成方法が可能になり、とても楽しい領域です。 R&Dチームではリサーチエンジニアを募集しています。また、検索エンジニアやデータエンジニア、MLOpsエンジニアも募集しています。一緒にR&Dチームおよびデータ検索基盤チームを0→1で立ち上げたい方はぜひ気軽にお話できると幸いです。 🛰️ ワークフロー自動生成R&Dとか業務フロー合成データとか検索とかに興味ある方、雑談しましょう！ また、Ai Workforce事業部エンジニア組織の詳細は以下Engineering Deckをご覧ください。 https://speakerdeck.com/layerx/ai-workforce-engineering-hiring-deck

AIエージェントを強化する『合成データ』作成の実践的Tips集

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト