SIMS aWriter マニュアル

aWriterは、すでに公開している記事を改善するためのClaude Project型SIMSです。SIMS Managerから改善依頼を受け取り、Search Console、SERP、記事本文、根拠情報、現在の記事が持つ価値を確認しながら、必要な部分だけを安全に編集します。

aWriterの目的は、記事をむやみに全面リライトすることではありません。現在評価されている部分を守りながら、改善が必要な箇所だけを直し、利用者がブログの編集画面へ反映しやすい完成形を返します。

現在の標準運用では、依頼と結果の管理はSIMS Managerが行います。通常の「今日の改善」ではSIMS Managerから直接aWriterへ進みます。aDoctorで精密診断した案件では、aDoctorの診断結果をいったんSIMS Managerへ戻し、SIMS ManagerがaWriter用の正式な依頼を作成します。

本マニュアルは、aWriter Claude v3.6.1、Shared v3.5.1、SIMS Editorial Platform 1.xを基準にしています。

aWriterとは
1. SIMS全体での位置
1．Claude ProjectへaWriterを導入する
2．SIMS ManagerからaWriterへ改善を依頼する
3．aWriterはどのように記事を改善するか
4．aWriterの回答を見る
5．ブログの編集画面へaWriterの回答を反映する
6．Before / Afterを記事へ反映する
1. 広告・アフィリエイト要素に注意する
7．内部リンクの提案がある場合
8．利用者判断が表示された場合
9．aWriterの結果をSIMS Managerへ戻す
1. 9-1．回答末尾のMachine Resultを使う
2. 9-2．登録後は経過観察へ進む
10．Personal Knowledge候補が生成される場合
11．aWriterが行わないこと
12．修正依頼を出す場合
13．よくある質問・トラブル解決
aWriterの基本ルート
1. 関連ページ

aWriterとは

aWriterは、SIMSの中で「既存記事の処置」を担当します。診断だけを行うaDoctor、新規記事を作るaCreator、複数記事を統合するaMergeとは役割が異なります。

SIMS全体での位置

SIMS Manager：記事、改善案件、処置結果、経過観察を管理する中心システム
aDoctor：必要な案件を精密診断し、原因と治療方針を決める
aWriter：既存記事を実際に改善し、公開できる変更案を返す
aCreator：新規記事を作成する
aMerge：複数記事の統合や役割整理を行う

通常改善の基本ルートは、SIMS Manager → aWriter → SIMS Manager → 経過観察です。すべての記事をaDoctorへ送る必要はありません。

精密診断が必要な場合は、SIMS Manager → aDoctor → SIMS Manager → aWriter → SIMS Manager → 経過観察となります。aDoctorからaWriterへ直接依頼するのではなく、必ずSIMS Managerを経由します。

1．Claude ProjectへaWriterを導入する

aWriterはClaudeのProject機能を使って動作します。初めて使う場合は、aWriter専用Projectを1つ作り、配布パッケージに含まれるClaude用ファイルとInstructionsを設定します。

1-1．Project Knowledgeとは

Claude Projectには、そのProject専用の資料を登録するProject Knowledgeがあります。aWriterでは、記事改善のルール、Evidenceの扱い方、公開可否の判断、出力形式、SIMS Managerとの受け渡し仕様などが登録されます。

簡単に言えば、Project Knowledgeは「ClaudeをaWriterとして働かせるための専門知識とルール一式」です。利用者が個々のファイルを理解したり編集したりする必要はありません。正本パッケージに入っているものを、そのまま使用してください。

1-2．初めてaWriterを使う場合

① aWriter専用Projectを作る

Claudeで新しいProjectを作成し、「aWriter」など分かりやすい名前を付けます。aDoctor、aCreator、aMergeや一般的なClaude利用と同じProjectに混在させないでください。

② 配布ZIPを展開する

SIMS Download Centerから入手したaWriter ClaudeのZIPをパソコン上で展開します。ZIPファイルそのものをClaudeへ登録するのではありません。

③ Claude-Uploadの中身をProject Knowledgeへ登録する

展開したパッケージの Claude-Upload フォルダー内には、aWriterが正しく動作するためのKnowledge、Runtime、contracts、shared、各種設定ファイルなどがまとめられています。

Claude-Upload 内の指定内容を一式として扱ってください。「このファイルは不要そう」と自己判断で削除したり、旧版のファイルと組み合わせたりしないでください。

④ Project Instructionsを設定する

CLAUDE_PROJECT_INSTRUCTIONS.md の全文をClaude ProjectのInstructionsへ設定します。

Project Knowledgeが「aWriterの専門資料」なら、Project Instructionsは「ClaudeにaWriterとしてどう動くかを指示する最優先ルール」です。Knowledgeだけを登録してInstructionsを設定し忘れないようにしてください。

⑤ 新しいチャットから開始する

設定が終わったら、aWriter Project内で新しいチャットを開始します。普段はSIMS Managerが作成した依頼文をこのチャットへ貼り付けて使用します。

1-3．旧バージョンから更新する場合

すでにaWriterを使用している場合は、旧版と新版を混在させないことが重要です。更新は「新しいファイルを追加する」作業ではなく、「旧版を新版へ入れ替える」作業として行います。

できるだけ処置中の案件を完了し、結果をSIMS Managerへ戻してから更新します。
既存Projectの旧Project Knowledgeを削除します。
新しいパッケージの Claude-Upload の内容を登録します。
Project Instructionsも、新版の CLAUDE_PROJECT_INSTRUCTIONS.md 全文へ入れ替えます。
更新後は、旧版で使っていた会話を続けず、新しいチャットから開始します。

1-4．更新時の注意点とリスク

新旧Knowledgeの混在：旧ルールと新ルールが同時に残ると、どちらを参照すべきか曖昧になり、編集判断や出力形式が不安定になる可能性があります。

Instructionsだけ旧版：Knowledgeを更新してもInstructionsが古いままだと、新しいKnowledgeを旧ルールで扱う可能性があります。必ずセットで更新してください。

処置途中での更新：同じ案件の途中でaWriterのルールが変わると、Before / Afterや最終結果の判断基準が途中で変化する可能性があります。案件の区切りで更新してください。

古いチャットの継続：Projectを更新しても、古いチャットには更新前の会話履歴が残っています。更新後は新しいチャットを使う方が安全です。

更新に不安がある場合は、既存Projectを直接変更せず、新版用の新しいaWriter Projectを作成する方法も安全です。新版の動作を確認するまで旧Projectを残し、確認後に旧Projectを日常運用から外します。

1-5．現在のバージョンを確認する

本マニュアルの基準となるaWriter Claudeは v3.6.1、Sharedは v3.5.1 です。配布パッケージのVERSIONや案内と大きく異なる場合は、古いパッケージを使用していないか確認してください。

2．SIMS ManagerからaWriterへ改善を依頼する

aWriterへは、原則としてSIMS Managerが生成した依頼文をそのまま渡します。利用者がSEOの指示やaWriter用データを一から作る必要はありません。

2-1．通常の「今日の改善」

日常運用では、SIMS Managerの「今日の改善」から対象記事を選び、改善ナビに従ってaWriter用の依頼を作成します。この通常改善では、原則としてaDoctorを経由しません。

SIMS Manager → aWriter が通常の入口です。SIMS Managerが保持している記事情報、Search Consoleデータ、改善条件などを含む依頼を、そのままaWriterへ渡します。

2-2．aDoctor診断後の場合

精密診断や再診でaDoctorを使用した案件は、aDoctorの回答を直接aWriterへ渡しません。まずaDoctorの診断結果をSIMS Managerへ登録します。

SIMS Managerが診断結果と記事情報を統合し、aWriterが実施してよい範囲を含む正式な処置依頼を作成します。その依頼をaWriterへ貼り付けます。

2-3．依頼文の内部情報は変更しない

SIMS Managerが作成する依頼には、案件や記事を識別するための内部情報が含まれる場合があります。これらはaWriterの結果を正しい案件へ戻すために必要です。

通常利用者は、case_id、treatment_request_id、記事IDなどを意識する必要はありません。依頼文を一部削除したり、識別情報を書き換えたりせず、SIMS Managerが作成したものをそのまま使用してください。

3．aWriterはどのように記事を改善するか

aWriterは、依頼を受けると記事全体を機械的に書き直すのではなく、現在の記事の評価と変更リスクを確認しながら、必要な部分だけを編集します。

Search Consoleを確認する

クリック、表示回数、CTR、平均順位などから、現在の記事がどの検索で読まれているか、どの部分を守るべきかを確認します。

必要な場合はSERPを確認する

競合との差を編集判断に使う必要がある場合は、現在の検索結果を確認します。SERPを十分に確認できない状態で、推測だけを根拠に競合記事の内容を追加することはしません。

現在の記事の強みを守る

すでに評価されている検索意図、独自情報、実体験、読者に役立つ説明、広告・アフィリエイト要素などを確認し、必要のない削除や全面改変を避けます。

必要な部分だけを直す

SEOタイトル、H1、メタディスクリプション、導入、見出し、本文、FAQ、内部リンクなどを修正単位ごとに判断します。安全に直せる部分は進め、根拠が弱い部分まで無理に変更しません。

4．aWriterの回答を見る

現在のaWriterは、内部の判定コードを利用者へ大量に見せるのではなく、記事へ実際に反映するためのHuman Layerを中心に表示します。

公開可否

回答の冒頭には、今回の修正をそのまま公開できるか、利用者の確認が必要な項目があるかが分かるように表示されます。

今回やること

今回の記事で何を改善するのかが、利用者向けに短く説明されます。

SERP比較結果

SERPを編集判断に使った場合は、現在の記事の強み、不足、今回補う点、今回は補わない重要項目などが簡潔に表示されます。SERPを判断材料にしていない場合は表示されないことがあります。

公開OK

そのまま記事へ反映できる変更です。変更箇所ごとにBefore / Afterや理由などが示され、Afterは利用者が実際の記事へ反映できる完成形として提示されます。

利用者判断

実体験、非公開の事実、権利・許諾、契約条件、ブランド方針、削除・noindex・Redirect・統合など、利用者自身でなければ決められない項目がある場合に表示されます。

aWriter自身がEvidenceから判断できるSEO上の選択を、単に「AかBを選んでください」と利用者へ丸投げすることは原則として行いません。

5．ブログの編集画面へaWriterの回答を反映する

v3.6.1では、利用者がブログへ反映するHuman Layerが改善されています。aWriterは特定のブログサービス専用ではなく、WordPressをはじめとする一般的なCMSで利用でき、はてなブログの「見たまま編集」のようなリッチテキスト編集環境でも、文章・リスト・表・内部リンクをできるだけそのまま利用できる形で表示します。

基本的な考え方は、CMSの通常の編集画面へ完成したHuman Layerを反映することです。WordPressではブロックエディターなどの通常編集環境、はてなブログでは「見たまま編集」など、利用しているCMSの標準的な編集方法に合わせて使用してください。

文章・リスト

利用者向けの文章やリストは、完成した読みやすい形で表示されます。通常は、内部処理用の改行記号などを利用者が手作業で直す必要はありません。

表

表を追加・修正する場合、Human Layerでは表として確認・コピーしやすい形で表示されます。表の一部の行やセルだけを変更する場合も、利用者が変更内容を理解しやすい表示を行います。

内部リンク

内部リンクは、Human Layerではクリック可能でコピーしやすい形で表示されます。WordPressなどの一般的なCMSでは通常の編集画面へ反映でき、はてなブログの「見たまま編集」のようなリッチテキスト編集環境でも、表示されたリンクテキストを含む完成形を利用できます。

一方、aWriter内部ではSIMS Managerへ返すMachine Layerも保持しています。利用者向け表示と機械処理用データは役割が異なるため、利用者がMachine LayerのHTMLやJSONを記事本文へ貼り付ける必要はありません。

6．Before / Afterを記事へ反映する

aWriterが「公開OK」とした変更は、提示されたAfterを実際の記事へ反映します。

SEOタイトル、H1、メタディスクリプション、導入、本文、FAQ、表、内部リンクなど、提示された変更箇所を順番に確認してください。

公開OKのAfterは完成形として提示されます。利用者が再びSEO判断を行って書き直すことを前提としていません。ただし、実際のブログへ貼り付けた後は、表示崩れやリンク切れ、広告コードの消失などがないかを公開前に確認してください。

広告・アフィリエイト要素に注意する

aWriterは既存の広告・アフィリエイト要素を保全する設計ですが、ブログの編集画面へ実際に反映するときは、アフィリエイトURL、広告コード、計測タグなどを誤って削除していないか確認してください。

7．内部リンクの提案がある場合

aWriterは、関連性が高く、記事同士の役割が重ならない内部リンクを検討します。候補URLを機械的に記事末尾へ並べるのではなく、読者が関連記事を必要とする自然な文脈へ配置することを基本とします。

自然に追加できる内部リンクがない場合は、無理に増やす必要はありません。aWriterが「今回は追加できる内部リンクはありません」と判断することも正常な処置です。

8．利用者判断が表示された場合

利用者判断が必要な場合は、aWriterから具体的な確認事項が示されます。質問に回答し、その回答を反映した完成版をaWriterに再生成させてください。

利用者判断が残ったまま、処置完了としてSIMS Managerへ登録しないことが重要です。

9．aWriterの結果をSIMS Managerへ戻す

公開OKの修正を記事へ反映したら、aWriterの最終結果をSIMS Managerへ戻します。SIMS Managerへの登録によって、今回の処置とその後の経過観察がつながります。

9-1．回答末尾のMachine Resultを使う

aWriterの回答には、利用者が読むHuman Layerとは別に、SIMS Managerへ処置結果を返すためのMachine Resultが含まれます。通常は回答末尾のJSONを、SIMS Managerの案内に従ってコピーします。

JSONの内部形式やContract名を利用者が判断する必要はありません。JSONを手作業で編集したり、一部分だけ抜き出したりせず、SIMS Managerの登録画面の案内どおりに扱ってください。

9-2．登録後は経過観察へ進む

SIMS Managerへの登録が完了すると、改善後の記事を経過観察できます。SIMS Managerでは約1か月を目安に、7日目・14日目・21日目・28日目（1週間ごと）の測定を基本として効果を確認します。

10．Personal Knowledge候補が生成される場合

aWriterは、今回の処置から将来も再利用できる安定した知識が得られた場合、Personal Knowledgeへ保存するための候補を結果に含めることがあります。

たとえば、「このサイトではこの記事がこの検索意図を担当する」「この種類の記事ではこの情報の鮮度を継続確認する」といった、今後の改善にも役立つ知識です。

aWriter自身がPersonal Knowledgeへ直接保存するわけではありません。保存の管理はSIMS Manager側が担当します。利用者がaWriterの回答からKnowledge用データを抜き出して手作業で登録する必要はありません。

現在の順位、クリック数、CTR、直近のSERP、外部サービスの現在価格など、一時的に変化する情報そのものは、長期利用するPersonal Knowledgeには向きません。aWriterは、将来も役立つ形へ一般化できる知識だけを候補化します。

11．aWriterが行わないこと

新規記事をゼロから作成する（aCreatorの役割）
複数記事を統合する（aMergeの役割）
aDoctorから直接依頼を受けてSIMS Managerを飛ばす
根拠が確認できない最新仕様・料金・提供条件を推測して追加する
利用者自身でなければ決められない不可逆な運営判断を勝手に確定する
改善の必要がない部分まで機械的に全面リライトする

12．修正依頼を出す場合

aWriterの回答に修正が必要な場合は、問題のある箇所と理由を具体的に伝えてください。たとえば「この体験は実際にはしていない」「このリンク先が違う」「この表の数値は変更しない」など、事実関係を明確にすると修正しやすくなります。

利用者自身が最終JSONだけを書き換えるのではなく、aWriterへ修正内容を伝え、Human LayerとMachine Resultが一致した完全な回答を再生成させてください。

13．よくある質問・トラブル解決

Q．通常の「今日の改善」でもaDoctorを先に使いますか？

いいえ。通常の改善は、SIMS Managerから直接aWriterへ進みます。aDoctorは、精密診断が必要な案件や経過観察終了後の再診などで使用します。

Q．aDoctorの回答をそのままaWriterへ貼ればよいですか？

いいえ。aDoctorの診断結果は一度SIMS Managerへ登録します。SIMS ManagerがaWriter用の正式な処置依頼を作成してからaWriterへ渡してください。

Q．aWriterが記事を全部書き直さないのはなぜですか？

既存記事には、すでに検索評価や読者価値を持っている部分があります。それを不用意に壊さず、必要な箇所だけを改善するためです。

Q．SERP比較結果が出ないことがあります

SERPを今回の編集判断に使っていない場合は表示されないことがあります。表示されないこと自体は異常ではありません。

Q．WordPressとはてなブログの両方で使えますか？

はい。aWriterは特定のブログサービス専用ではありません。WordPressをはじめとする一般的なCMSで利用でき、はてなブログの「見たまま編集」のような編集環境でも反映しやすいHuman Layerを出力します。ただし、使用しているテーマやエディターの仕様によって表・リンク・装飾などの表示が変わる場合があるため、貼り付け後は必ずプレビューを確認してください。

Q．内部リンク候補を全部入れる必要がありますか？

ありません。aWriterが自然に挿入でき、記事同士の役割が重ならないと判断したものだけを採用します。

Q．aWriterのJSONはどこまでコピーしますか？

SIMS Managerの登録画面に表示される案内に従って、回答末尾の最終JSONを完全にコピーしてください。JSON本体を手作業で編集しないでください。

Q．料金や製品仕様が古い場合は自動で直してくれますか？

現在有効な公式情報または信頼できる一次情報を確認できた場合に限り、公開可能な修正として扱います。確認できない変動情報を推測で最新化することはありません。

Q．aWriterからaMergeやaCreatorが必要だと分かった場合は？

aWriter自身が統合や新規記事作成を実行することはありません。必要な場合は担当候補をSIMS Managerへ返し、SIMS Managerから正式なaMergeまたはaCreatorルートへ進みます。

Q．Projectを更新したら古いチャットも使えますか？

使い続けることはおすすめしません。旧版の会話履歴が残っているため、新しいProject KnowledgeやInstructionsとの不整合を避けるために、更新後は新しいチャットから開始してください。

aWriterの基本ルート

通常改善：
SIMS Managerで「今日の改善」を確認
→ 改善ナビからaWriter用依頼を作成
→ aWriterへ依頼を貼り付ける
→ 公開OKの変更を記事へ反映・公開
→ aWriterの最終結果をSIMS Managerへ登録
→ SIMS Managerで経過観察

精密診断後：
SIMS Manager → aDoctor
→ aDoctorの診断結果をSIMS Managerへ登録
→ SIMS ManagerがaWriter用処置依頼を作成
→ aWriterで処置
→ 記事へ反映・公開
→ aWriterの最終結果をSIMS Managerへ登録
→ 経過観察

aWriterは単独の文章生成AIとして使うのではなく、SIMS Managerが管理する既存記事改善の実行担当として使用することが基本です。