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 を使って候補を追加生成する。
• 技術記事向けではない記事の場合は、特定媒体に依存した需要仮説を止め、別媒体向けに調整するか確認する。