2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIエージェントの週次記事生成スキルを「週4本・品質重視」に再設計した手順

2
Last updated at Posted at 2026-03-30

2026-03-31_qiita.PNG

3行まとめ

  • AIエージェントの記事生成スキルを**「毎日7本」から「週4本・品質重視」に再設計**し、プライバシーリスクと品質の両方を改善した
  • 再設計の過程で判明したプライバシー漏れの発生原因を、モデル種別×運用時期で分析した
  • スキル指示書に匿名化テーブル + Completion Check + 本数制限を組み込み、生成段階からチェックが効く設計にした

背景

AIエージェント(AntiGravity)に定義した create_articles スキルで、毎週1週間分のnote/Qiita/Discord記事を一括生成しています。

しかし、週の公開予定記事を通して見返した際、以下の問題が発覚しました。

問題1:話題の重複によるプライバシーリスクの増大

毎日投稿を前提にすると、1週間で7本の記事が必要です。しかし作業ログの話題は有限のため、無理に本数を埋めようとすると:

  • 話題が似通った記事が連続する
  • プライバシーぎりぎりの内容にまで手を出してしまう
  • 記事単体ではセーフでも、複数記事の組み合わせで個人の状況が立体的に見えてしまう

問題2:過去記事にプライバシー上の問題表現が残っていた

Gemini 3.1 Pro High で過去記事を横断チェックした結果、個人特定につながりうる表現が残っていた記事が合計5本見つかりました。


原因分析:なぜ漏れが起きたか

漏れが発生した記事の作成経路を追跡し、2つの系統を特定しました。

系統1:Claude Sonnet 4.6 の一気通貫処理

  • 記事作成からサムネイル抽出までを一度に走らせていた
  • 前半で品質は保たれていたが、後半のプライバシーチェック精度が低下していた可能性
  • 「AIに一度に全部やらせると後半の品質が下がる」という既知の問題が表面化

系統2:初期のカスタムGPT(MyGPT)運用

  • プライバシーチェック機構が未成熟な時期に生成された記事
  • 指示書にNGワードリストや匿名化ルールが存在しなかった

補足: Claude Opus 4.6 や Gemini 3.1 Pro High で生成された記事では、プライバシー関連の問題表現はほとんど見られませんでした。上位モデルの方がプライバシー感度が高い傾向があります。


実装1:投稿スケジュールの再設計

変更内容

スキル指示書(SKILL.md)の Calendar セクションを以下のように変更しました。

## Calendar

週4日制(日・月・水・金)で公開する。

- Day 0 (Sun): 週レポート Note
- Day 1 (Mon): 技術・AI活用 Note
- Day 3 (Wed): 開発ログ Note + 要件充足時 Qiita
- Day 5 (Fri): 方法論・マインドセット Note + 要件充足時 Qiita

Qiitaは週全体で 1〜2本まで。

設計判断

  • 毎日投稿 → 週4本に削減することで、1本あたりの密度を引き上げ
  • Qiita記事は技術的に再現性がある内容に限定
  • プライバシーリスクの高い日のログは除外対象として明記

実装2:匿名化テーブルの追加

スキル定義の Privacy / Safety Rules セクションに匿名化テーブルを追加しました。

### 研究・学術系
- 具体的な学術誌名 → `英文誌`
- 研究助成金の具体名 → `研究助成金`
- 応募時期や対象者を特定できる情報 → 削除
- 特定の運動課題名 → `動作分析` `運動課題`
- 具体的な計測機器名 → `計測機器` `計測機器類`

### キャリア・プライベート系
- 転職の具体的経過 → `転職` `転職の報告`
- 所属コミュニティの固有名 → `所属コミュニティ` `研究会`
- 個人名 → `知人のエンジニア` `共同研究者`

実装3:Completion Check の追加

保存直前に実行されるNGワードチェックを追加しました。

## Completion Check

公開用本文に以下が残っていないことを最終確認してから保存する:

- 具体的な学術誌名
- 研究助成金の具体名
- 特定の運動課題名
- 具体的な転職経過
- 個人名
- 計測機器の具体的な列挙

実装4:公開前修正のモデル分担

プライバシー漏れの修正作業を通じて確認した、モデルごとの適性を運用ルールに反映しました。

作業内容 推奨モデル 理由
記事本文の生成 Claude Opus 4.6 品質・人間味・プライバシー感度
公開前の表現修正 Gemini 3.1 Pro High レート制限に余裕・処理速度が速い
高速ドラフト生成 Claude Sonnet 4.6 速度重視時のフォールバック

重要: プライバシーチェックの最終責任は人間が持つ前提です。AIの自動チェックを信頼しすぎず、公開直前の目視確認工程は省略しないでください。


再現手順

環境

  • AIエージェント: AntiGravity(Google社製)
  • ノート管理: Obsidian
  • スキル定義: .agent/skills/create_articles/SKILL.md

手順

  1. SKILL.mdCalendar セクションを週4日制に変更
  2. Privacy / Safety Rules に匿名化テーブルを定義
  3. Completion Check セクションを追加(NGワードリストを定義)
  4. 除外ルール(プライバシー観点)をCalendarセクションに明記
  5. 週次バッチ実行後、公開前に自分の目で1回確認
  6. 修正が必要な場合は Gemini 系に「この表現を一般化して」と依頼

まとめ

  • 本数削減は妥協ではなく、品質とプライバシーの両方を守るための設計判断
  • プライバシー漏れの原因は**「モデルの特性 × 運用時期の成熟度」**の2軸で説明できた
  • スキル指示書に匿名化テーブル + Completion Check + 本数制限を組み込むことで、生成段階からチェックが効く仕組みに改善

今後の課題: 現時点では匿名化テーブルは手動メンテナンスです。NGワードが増えてきた場合、外部リストファイルに分離して管理する設計も検討余地があります。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?