Tech Article Angle

---
name: tech-article-angle
description: "技術記事向けの記事アイデア、メモ、技術的観察を、現在需要の高い論点へ運ぶ。AI導入後の摩擦、ワークフロー再設計、検証、セキュリティ、保守性、実測改善、人間の判断を軸に、テーマ・タイトル・構成・リライトを整える。技術記事の企画や推敲に使う。汎用SEO、非技術エッセイ、学術論文、出典重視の調査報告には使わない。"
---

# 技術記事需要論点化

## 手順

**ステップ1: 記事の対象を固定する**
1. ユーザー依頼または草稿から、種となるアイデア、想定読者、技術領域、公開目的を抽出する。
2. 想定読者が欠けている場合は、材料から具体的な技術記事の読者層を1つ推定する。例: AI支援開発者、テックリード、データエンジニア、プラットフォームエンジニア、セキュリティ意識の高い個人開発者、エンジニアリングマネージャー。
3. 入力が完成済み草稿の場合は、ユーザーが新しい主張を求めない限り、中心主張を維持する。
4. 入力が広いテーマだけの場合は、読者が判断すべき実務上の意思決定を1つに絞る。

**ステップ2: 現在の技術記事需要へ論点を寄せる**
1. `references/current-demand-model.md` を読み、論点を1つ以上の需要レーンへ分類する。
2. AI導入後の実務摩擦に接続するレーンを優先する。例: 検証、安全性、保守性、CI/CD、ワークフロー再設計、人間の責任、データと業務アクションの設計、実測改善。
3. 論点を一般的な「AIは便利」という主張へ縮めない。
4. AIとの自然な接続がない場合は、実務証拠レーンを使う。例: 実測改善、移行記録、デバッグ記録、アーキテクチャ判断、失敗分析。

**ステップ3: 記事角度の候補を作る**
1. 記事角度を5案作る。
2. 各案について、次の項目を書く。
   - 想定読者
   - 読者の痛み
   - 記事の約束
   - 必要な具体的証拠
   - 技術記事としていま読む理由
3. 具体的な読者の痛みまたは証拠の道筋がない案は棄却する。
4. 候補をJSONとして保存した場合は、`python3 scripts/score-angles.py --input assets/angle-candidates.json` を実行する。JSON化していない場合は、`references/current-demand-model.md` の基準で手動採点する。

**ステップ4: 構成より先にタイトルを作る**
1. `assets/title-patterns.md` を読み、タイトル型を確認する。
2. 採用前に、少なくとも10個のタイトル候補を作る。
3. 具体的な問題、実測結果、運用上の副作用、意思決定点が見えるタイトルを優先する。
4. 「使ってみた」「まとめ」「入門」「考えたこと」だけのタイトルは、具体的な結果や判断を足して書き換える。

**ステップ5: 記事構成を組む**
1. ユーザーが別形式を指定していない場合は、次の骨格を使う。
   - フック: 読者の仕事で何が変わったか
   - 問題: 何が壊れる、または曖昧になるか
   - 前提: 解決策の前に必要な背景知識
   - 試行: 実際に何を試したか
   - 証拠: 数字、設定、diff、ログ、事例、Before/After
   - 判断: 採用すべきこと、避けるべきこと、様子を見るべきこと
   - 転用: 他のチームや読者がどう再利用できるか
2. 各セクションを読者メリットに結びつける。
3. 証拠が足りない場合は、結果を作らず `TODO: collect evidence` と明記する。

**ステップ6: 草稿をリライトまたは批評する**
1. 冒頭5段落以内で、読むメリットが分かるように強める。
2. 抽象的な主張は、具体的な観察の後ろへ移動する。
3. 曖昧なトレンド語を、開発者、チーム、システム、運用に起きる具体的な影響へ置き換える。
4. つながりが弱い箇所には、節ごとの読者の疑問を補う。
5. 埋め草、定型的な対比、根拠のない断定を削る。
6. ユーザーが別の文体を求めない限り、丁寧な日本語を維持する。

**ステップ7: 出力を検証する**
1. Markdownファイルを作成した場合は、`python3 scripts/check-article-angle.py --file [draft.md]` を実行する。
2. 出力に、読者、痛み、約束、証拠の道筋、転用できる学びが含まれることを確認する。
3. 検証に失敗した場合は、もっとも弱いセクションを修正してから納品する。

## エラー処理

* テーマが広すぎる場合は、執筆前に、1つの意思決定、1つのワークフロー、または1つの失敗モードへ縮小する。
* 証拠がない場合は、アウトラインを作り、証拠不足を `TODO: collect evidence` と明記する。数字、事例、ベンチマークを捏造しない。
* 草稿が一般的なAI論に流れた場合は、`references/current-demand-model.md` の「AI導入後の実務摩擦」レーンへ戻す。
* タイトル候補が弱い場合は、本文を変える前に `assets/title-patterns.md` を使って候補を追加生成する。
* 技術記事向けではない記事の場合は、特定媒体に依存した需要仮説を止め、別媒体向けに調整するか確認する。