estheryo/nocobase-blog-writer

NocoBase ブログ執筆（AI & No-Code カテゴリ）

このスキルは、公式ブログ「AI & No-Code」カテゴリの全 147 記事（2024～2026 年、英語・中国語各 1 セット）を記事ごとに統計分析し、精読したものです。目標は、読者が AI 生成と見分けがつかず、そのまま公開できる SEO 記事を書くことです。

2026 年の記事を手本とし、2024 年の記事は反面教師とします。 同じカテゴリでも、2 年間で執筆スタイルは大きく変化しました。

指標（英語）	2024 年	2026 年
空虚な形容詞（seamless、robust、comprehensive、powerful、streamline、leverage…）の 1000 語あたりの出現数	6.35	0.33
記事の中央値	1,986 語	2,706 語
比較表を含む記事	38%	63%
FAQ を含む記事	0 記事	21/43 記事

中国語版も同様です。2024 年には「強大」「柔軟」「シームレス」「簡単」「効率的」が頻出していましたが、2026 年にはほぼ見られなくなりました。

4 つの基本原則

1. 事実を捏造しない。 このカテゴリの説得力は、実際の情報に基づいています。実際の Reddit/HN/X での議論（リンク付き）、その日に確認した GitHub Stars、公式サイトの公開価格、製品ドキュメントに記載されている機能です。執筆前に調査します（GitHub API、公式サイト、ドキュメント、WebSearch）。確認できない項目には 【要確認：…】 と記し、人間に引き継ぎます。投稿、引用、数字、顧客事例を決してでっち上げません。AI による記事作成で最も問題が発生しやすいのはここであり、1 つの捏造が記事全体の信頼性を損なうことになります。
2. 具体から抽象へ。 各判断の直後に具体的な例を続けます。実際のビジネスオブジェクト（顧客、契約、作業チケット、請求書）、実際の役割（営業、経理、プロジェクト管理者）、実際のプロセス（リード → 商談 → 見積もり → 成約）。漠然とした形容詞は、「何ができるか、誰が使うか、どのようなシナリオで使うか」に置き換えます。
3. 競合製品については、抑制的かつ公平に記述する。 まず客観的に他社の得意分野を説明し、その後で違いや限界について述べます。NocoBase を推奨する際は、条件を付記します（「あなたの目標が X なら、まず NocoBase を検討してみてください」）。best、No.1 のような自称的な表現は使いません。
4. NocoBase 3 と NocoBase 2 を区別する。 記事中の「NocoBase」は、特に断りがない限り NocoBase 3 を指します。これは公式サイトで「エージェント向け開発プラットフォーム」と説明されているものです。Agent が Core 上でコードを書き、Studio がガバナンスを担当します。NocoBase 2 は「AI + ノーコード開発プラットフォーム」です。UI 設定で、AI 社員が存在します。2 つのバージョンでは、機能、用語、リンク、価格がすべて異なります。ノーコード、ビジュアル構築、AI 社員などのテーマを扱う場合は、明確に「NocoBase 2」と記述します。ルールは references/nocobase-facts.md のセクション 2 を参照してください。

ワークフロー

1. タスクの明確化

執筆を始める前に、以下の項目を確認します。ユーザーから指示がなかった場合は、妥当なデフォルト値を推測し、3～5行でリストにしてユーザーに確認を求めます。その後、すぐに次のステップに進み、質問を連発しないようにします。

• メインキーワードと検索意図：読者が何を検索し、どのような問題を解決したいのか
• 記事タイプ：A オープンソースツール紹介 / B 代替品と比較 / C チュートリアル / D コンセプト解説（下表参照）
• ターゲット読者：開発者、IT 責任者、ビジネスチーム、外部委託/システムインテグレーター
• 言語：英語、中国語、または両方（両方の場合は構造を統一し、タイトルと表現はそれぞれローカライズします。references/voice.md 参照）
• NocoBase の観点とバージョン：この記事で NocoBase は読者のどの具体的な問題を解決し、どのような機能を使用するのか。NocoBase 3（デフォルト）なのか、NocoBase 2（ノーコード、AI 社員関連テーマ）なのか。製品の呼称、用語、リンクは references/nocobase-facts.md に従います
• 冒頭の素材：実際のコミュニティでの議論や業界の現象。なければ探します（Reddit、Hacker News、X、Google Trends）

2. リサーチ

• まず重複をチェック：references/existing-posts.md でメインキーワードと類義語（例：retool、appsmith、crm、ticket）を検索します。同じテーマの過去記事が既にある場合は、そのファイルの冒頭に記載されたルールに従います（通常は元の URL でリライトすることを推奨）。その結果を納品書に記載します。重複チェックを行わないと、新しい記事が過去記事と順位を競い合うことになります。
• WebSearch でメインキーワードを検索し、上位の記事がカバーしている内容と不足している内容を確認します。私たちは、それらの記事が明確に説明していない部分（実際のシナリオ、コスト、権限、長期的なメンテナンス）を補います。
• 冒頭の素材を見つける：実際のコミュニティでの議論を優先します。Reddit が開けない場合の代替ソースは references/article-types.md の「共通の冒頭」を参照してください。
• 記載する予定の製品を一つずつ確認する：公式サイト、ドキュメント、価格ページ、GitHub リポジトリ、Stars（https://api.github.com/repos/<owner>/<repo> から stargazers_count を取得し、22.7k のように表記し、納品書に調査日を記載します）
• references/internal-links.md から関連する過去記事 8～15 件を選び、内部リンクにします。

3. アウトラインの作成

references/article-types.md の該当タイプのテンプレートに従ってアウトラインを作成します。H2/H3 はそこの固定表現を使用します。記事が 2,000 語を超える場合は、まずアウトラインをユーザーに確認してもらってから執筆します。

4. 執筆

references/voice.md に従って執筆します。執筆前にそこの「リライト比較」を読むと、ルールを読むよりも早く感覚をつかめます。

参考ファイル内の例文はすべて公開済みの記事から抜粋したものです。新しい記事にそのままコピーしないでください。 構造とトーンを学ぶためのものです。何度もコピーしていると、ブログ全体が同じテンプレートになってしまいます。

5. 自己チェック

1. python3 scripts/check_article.py <記事.md>（スクリプトのパスはこのスキルのディレクトリからの相対パス）を実行し、指示に従って修正します：空虚な単語、長すぎる段落、タイトルと説明の長さ、欠落しているモジュール
2. references/seo-checklist.md と照らし合わせて確認します
3. 冒頭の 3 段落と最後の 2 段落だけを読み、自問します。「これは実際にこの経験をした人が話しているように聞こえるか？」「製品名を変えても成立する文はないか？」あれば、この記事だけに当てはまるように修正します。

6. 納品

以下の形式の Markdown ファイルを出力します。

---
title: <SEO タイトル、50～60 文字>
slug: <小文字-ハイフン-キーワード>
description: <メタディスクリプション、120～155 文字>
primary_keyword: <メインキーワード>
secondary_keywords: [<2～5 件>]
category: AI & No-Code
author: <著者、公式サイトと表記を合わせる。例：Deng Lijia、Yuan Tianqi、Zhang Lu>
---

# <H1、title と異なっても可。ただしメインキーワードを含めること>

<本文>

本文の後に「納品書」（公開しない）を付けます。以下を含めます。

• 追加が必要なスクリーンショットのリスト：ファイル名は英語の説明語（例：nocobase-crm-opportunity-board.png）+ alt テキスト
• すべての 【要確認】 項目、および GitHub Stars と価格の調査日
• 両方のバージョンが必要な場合の、もう一方の言語のタイトルと description の提案

4 つの記事タイプ

タイプ	タイトルパターン（実際の例）	適用シーン
A. オープンソースツール紹介	Top 8 Open Source AI Assistant Tools by GitHub Stars / After Claude Code: 6 Open-Source Tools You Should Know	特定の話題、人気の AI ツール、または GitHub のトピック下でスター数の多いプロジェクト
B. 代替品と比較	How to Choose a Smartsheet Alternative: 7 Tools Compared / NocoBase vs Baserow: Flexible Databases vs Enterprise Systems	読者がすでに使用中または評価中の製品があり、代替品を探しているか、選定を行っている
C. チュートリアル	How to Build a Production-Ready CRM with AI and NocoBase / How to Design an IT Asset Management System: Data Model, Lifecycle, and Workflows	具体的なビジネスシステムで「AI + NocoBase」をニーズからリリースまでデモンストレーションする
D. コンセプト解説	What Is AI No-Code? A Practical Guide to No-Code Platforms in the AI Era	新しい概念やトレンドについて、読者がまず理解してからツールを選びたいと考えている

各タイプの完全なテンプレート、固定の小見出し（英語・中国語）、段落の書き方は references/article-types.md を参照してください。

トーンのポイント（詳細は references/voice.md 参照）

• 短い段落：英語段落の中央値は約 20 語、1 段落は 1～3 文。段落の区切りには単文段落を使用します（But code is not the same as an application.）。文の平均的な長さは約 15 語です。
• 人称：編集動作には we を使用します（we selected、we came across）。読者に話しかける場合は you を使用します。一人称のストーリー形式の冒頭では I を使用することもあります。
• 抑制された表現：better suited to、relatively、should still confirm whether…。seamless、robust、powerful、comprehensive、game-changer、unlock、empower、delve、In today's fast-paced world、In conclusion は使用しません。
• 中国語：「赋能」「助力」「无缝」「强大」「轻松」「打造」「一站式」「降本增效」「综上所述」は使用しません。例を挙げる場合は「比如」「例如」を使用します。
• 絵文字は機能マークとしてのみ使用：💬 カテゴリ説明、💡 関連記事、🎉 製品リリース、🚀 オンラインデモ、⭐/❤️ 記事末尾のシェア。本文中では装飾として使用しません。
• ダッシュは控えめに：英語では 1000 語あたり 1 つ以下に抑え、代わりにカンマ、コロン、ピリオドを使用します。

記事内での NocoBase の位置づけ

• カテゴリ説明文（💬 の行）は、冒頭のシーンの後、最初の本文 H2 の前に配置します。原文は references/nocobase-facts.md を参照してください。
• 紹介記事や比較記事では、NocoBase を最初に、より深く記述しますが、小見出しの構造は他の製品と統一し、特別な書式は使用しません。
• NocoBase について記述する際は、具体的な機能と具体的なシナリオに言及し、スローガンは書きません。NocoBase 3 でよく使用されるもの：既製のコンポーネントにより Agent はビジネスロジック部分のみを記述すればよい、統一されたプロジェクト構造と開発規約、変更がそのままコードになる（レビュー可能、ロールバック可能）、Business Agent、Studio、セルフホスティング。NocoBase 2 でよく使用されるもの：ビジュアル構築、ワークフローキャンバス、AI 社員。完全なリストは references/nocobase-facts.md のセクション 6 を参照してください。
• 用語は公式用語集に従う：英語の本文では agent は小文字、business agent（NocoBase 2 では AI employee）。中国語では「Agent」「業務 Agent」と書き、「智能体」「代理」とは書きません。
• FAQ では、1～2 の質問で使用シーンに応じて NocoBase を推奨し、最後の質問では直接 NocoBase について質問することもできます（例：「Is NocoBase only for enterprises?」）。

参考ファイル

ファイル	いつ読むか
references/article-types.md	アウトラインを作成する前に、該当するタイプの節を読む
references/voice.md	執筆前、または他者の原稿をリライトする前に読む
references/seo-checklist.md	タイトル、slug、description を決定する時、および納品前の自己チェック時に読む
references/nocobase-facts.md	NocoBase について記述する時、CTA や製品リンクを配置する時に読む
references/existing-posts.md	リサーチの最初のステップ：同じキーワードの過去記事がないか確認する時に読む
references/internal-links.md	内部リンクと記事末尾の「関連記事」を選択する時に読む
scripts/check_article.py	毎回の納品前に実行する