Maliang Writer
チュートリアル約12分で読めます

AIエージェント術:ルール・スキル・プロジェクトフォルダと5つ

公開ドキュメントを見ると、多くのエージェントがルールファイル、スキル、プロジェクト資料で作業を組み立てています。この方式で長編を書くとき補うべき5つのことと、Maliang Writerの対応を解説。

Maliang Writerチーム · Maliang Writer

この記事の目次 9セクション

まず結論:作業の方式は似ていて、長編で補うべきは5つのこと

この1、2年で、多くの「エージェント」が登場しました:テンセントのWorkBuddy、バイトダンスのCoze(扣子)、Manus、Kimi Agent、オープンソースのOpenClaw、そしてコード執筆の出自を持つClaude Code、Cursor、Codex CLI。宣伝はそれぞれ違いますが、公開ドキュメントと照らすと、そのうち多くの製品で作業の方式が似ています:

  1. 複数ステップの実行:エージェントがあなたの要求を読み、自分でステップに分け、ファイルを読み書きし、資料を調べ、結果を見て次の手を決める。
  2. プロジェクトフォルダ(プロジェクト、ワークスペース、ライブラリとも呼ばれる):読むべき資料と成果物をここに置く。
  3. ルールファイルとスキル:常駐するルールファイル(CodexはAGENTS.md、Claude CodeはCLAUDE.md)に、必要に応じて使うスキル(Skill)が加わる。各スキルは1つの説明書で、スクリプトが付くこともある。

公開ドキュメントには、こうした収束が見られます:WorkBuddyのプロジェクトメモリファイルはAGENTS.mdと互換性があり(プロジェクト)、スキルマーケットはOpenClawのスキルのエコシステムと互換性があります(スキルマーケット)。Cozeのプロジェクトでは、サブ会話がファイルとagents.mdを共有し(Cozeのプロジェクト)、OpenClawもCozeも、メモリにMarkdownファイルを使っています(OpenClawのメモリ、Cozeのメモリ)。ManusやKimi Agentなどの製品が同じ組み立て方を採っているかは、公式資料に完全な説明が見当たらないため、試用するときに確認することをお勧めします。

だから、どのエージェントが小説を書くのに強いかを問うより、こう問うほうがよいでしょう:この作業方式で、数十万字の本を書くとき、誰かがやらなければならないことは何か? 以下、1つずつ述べ、各節の最後にMaliang Writerのやり方を説明します。

1:資料をどう置くか:本の構造を先に作っておく

各製品の資料の組み立て方は異なり、ローカルのワークスペース、プロジェクトファイル、ライブラリがあり、使える範囲はそれぞれ確認が必要です。フォルダで小説の資料を管理すると、人物カード、第37章、第3巻ですでに無効になった設定は、いずれも1つ1つのファイルで、どれが何で、どれを基準にするかは、作者がはっきり示す必要があります。次のように作ることをお勧めします:

  • 設定、人物、プロット、本文を分けて置く。
  • 本文は1章1ファイルで、ファイル名に番号を付ける。
  • 人物カードに「現在の状態」の欄を設ける。
  • 別に伏線リストを置く。

ディレクトリがはっきりし、状態の注記が明確であれば、エージェントは読むべき資料を見つけやすくなります。試し書きのときも、実際にどの内容を参照したかを確認してください。具体的なフォルダ構造とルールファイルの書き方は、小説フォルダとCLAUDE.mdの書き方を見てください。

Maliang Writerは、この層の構造をすでに用意しています:巻、章、章プロット、キャラクター、設定、伏線、ストーリーラインは、最初から分類されていて、左側は目次とカードです。

2:1章ごとに何を読むか:コンテキストには限りがある

モデルが1ステップで見られる内容には上限があります。たとえばKimiのヘルプセンターには、Agentのコンテキストは128K tokens(約8〜10万漢字、機能と制限)と明記されています。WorkBuddyの公式ドキュメントには、既定のコンテキストは200Kで、GLM-5.3は1Mまで開けると明記されている一方、1Mにしても「モデルが賢くなるわけではなく、1ラウンドあたりの消費が倍々に増えるだけ」と注意しています(モデルの説明)。本が数十万字を超えたあとは、通常、章ごとに選んで読むことになります。

章の前に、関連する資料がそろっているか、最新かを確認し、書き終えたあとも、本文と設定が一致しているかを確認する必要があります。第120章を書くとき、通常は次のものが必要です:

  • この章の章プロット。
  • 登場人物のカード。とくに現在の状態。
  • 直近の2、3章の本文。
  • この章に関わる伏線、設定。
  • 文体サンプル1つ。

各製品の資料の与え方は異なります:ルールファイルに従って読むもの、ライブラリから検索して注入するもの(WorkBuddyのプロジェクト資料はRAGの形でタスクに注入される)、メモリに頼るものがあります。試し書きのときは、この章で読んだものが最新の設定か、直前の章で起きたばかりのことを落としていないかを確認してください。長い会話には別の問題もあります:初期の内容が圧縮されたり忘れられたりします。Kimiのヘルプセンターも、会話のラウンドが多すぎる(たとえば50ラウンドを超える)と初期の内容を忘れることがあり、とくに長編小説の創作で起きやすいと注意しています。

3:書き終えたあと、誰が整理するか:章末の資料を速やかに更新する

1章書き終えると、本の「状態」が変わります:誰かが負傷した、誰かが秘密を知った、宝具1つが持ち主を変えた、伏線が1つ回収された。これらの変化が人物カードと伏線リストに書き戻されなければ、次の章が読むのは古い情報です。

汎用エージェントには、会話のメモリ整理を備えるものがあります(たとえばWorkBuddyは毎晩その日の会話を整理する、メモリ)が、章ごとに小説の人物状態と伏線を更新する専用の流れは、公式資料に説明が見当たらないため、試用するときに確認することをお勧めします。よくあるやり方は、ルールファイルに「1章書き終えるごとに、人物状態と伏線リストを更新する」と1行加えるか、スキルを1つ書いて行わせることです。試し書きのとき、次の点を確認できます:

  • 1章書き終えるごとに、人物状態と伏線リストが更新されたか。
  • 新しく加えた記録に、本文中の根拠があるか。
  • 新しい情報が古い設定と矛盾したとき、どう扱うか。変更は原文を保っているか、どこを直したかがわかるか。

Maliang Writerは、この手順を決まった流れにしています:章を書き終え、このラウンドが終わると、記録係が、この章の人物状態、関係、位置、持ち物、伏線を整理します。合わない箇所は「確認待ち」に挙げられ、作者が確認して処理します。

4:変更をどう確認するか:数十のファイルの中で、どの数文が直されたか

エージェントが改稿するとき、多くは一度に複数のファイルを動かします。コード執筆の出自を持つツールには、既存の手段があります:Claude CodeとCursorにはチェックポイントがあり、Codex CLIは公式にGitでチェックポイントを作ることを勧めており、変更はファイルごとに比較し、戻せます。汎用エージェントは各社でやり方が違い、たとえばWorkBuddyのライブラリでは、AIによるMarkdownドキュメントの修正は原文を上書きせず、確認待ちの状態で示されます(ライブラリ)。

小説を書く人にとって、見たいのはファイルの差分ではなく、「この段落は、もとはどう書かれ、今はどう書かれているか」です。Maliang Writerは、AIの修正を、組版された本文の中に置きます:赤が削除、緑が追加で、1か所ずつ保持または元に戻せます。ラウンド全体が気に入らなければ、このラウンドを取り消すか、このラウンドの前から別の枝を作れます。

5:古い設定をいつしまうか:第3巻以降

第3巻まで書くと、前の2巻の一部の脇役、地点、伏線は、すでに現在の展開から退いていますが、資料は残っています。人物表を読むとき、資料を検索するときに、それらを含めてしまうと、コンテキストを占めるだけでなく、退場した人物が書き戻されることもあります。

汎用エージェントで本を書くとき、よくあるやり方は、作者が自分で古い資料をアーカイブのディレクトリに移すか、ルールにどれをもう参照しないかを明記し、新しい章を書くときに実際に参照した資料を確認することです。Maliang Writerは巻ごとに扱います:新しい巻を書くとき、前の数巻にしか登場しない人物、地点、伏線がアーカイブにしまわれ、新しい章を書くときは参照されません。人物が復帰したときは、常用に戻されます。具体的なやり方は、長編で新しい巻に入ったとき、古い設定をどう扱うかを見てください。

汎用エージェントで長編を書く:5項目の試し書きチェック

すでにWorkBuddy、Coze、OpenClaw、またはプログラミングエージェントで本を書いているなら、次の5項目で確認できます。ある製品がルールファイルやカスタムスキルに対応しているかは、公式の説明に従い、説明が見当たらないものは試用するときに確認することをお勧めします:

  1. 資料の構造:設定、人物、プロット、本文を分けて置けるか。本文を1章1ファイルにできるか。
  2. ルール設定:章の前に読む資料、文体の要求、直してはいけない設定を明記できるか。
  3. 章末の整理:1章書き終えるごとに、人物状態と伏線リストをどう更新するか。新しい記録と矛盾をどうあなたの確認に回すか。
  4. 変更の確認:製品付属のバージョン、確認待ち機能、またはGitで、どのファイルのどの段落が直されたかを見分けられるか。
  5. 巻ごとのアーカイブ:1巻書き終えたあと、退場した人物と回収済みの伏線を、常用資料から外せるか。

この5項目は、試し書きのときの確認リストとして使え、どの作業を作者自身が担うことになるかを見極めるのにも役立ちます。

執筆の流れに合わせてツールを選ぶ

あなたの状況お勧め
小説以外にも、事務やリサーチのタスクが多い汎用エージェント。これらのタスクと執筆を一緒に置く
フォルダとGitに慣れ、ルールと台帳を自分で維持してもよいプログラミングエージェントでも汎用エージェントでもよい
数百章の連載を書き、巻・章の目次、章末の整理、確認待ちの入口が最初から欲しい小説執筆ソフト
ジャンルの調査はエージェント、本文は執筆ソフト両方を使い、結論を設定カードと章プロットに持ち帰る

各種ツールの比較は、小説を書くソフトは6種類に分かれると汎用エージェントで小説を書くときの選び方を見てください。

よくある質問

Q:小説執筆ソフトの中のエージェントと、汎用エージェントは、何が違いますか?
どちらも、AIに本の資料を読み書きさせ、複数ステップでタスクを完了させるものです。Maliang Writerを例にすると、巻・章の目次、キャラクターカード、記録係による章末の整理と確認待ち、本文の赤い削除・緑の追加と1か所ずつの保持・元に戻す、このラウンドの取り消し、別の枝、巻ごとのアーカイブと復帰は、いずれも最初から用意された機能で、確認待ちに挙がった内容は、引き続き作者が確認して処理します。

Q:汎用エージェントに小説スキルを入れれば、同じになりますか?
スキルで解決できるのは「どう書くか」の一部で、たとえば作品開始の流れ、章プロットの書式、文体の要求です。しかし、人物状態を誰が更新するか、矛盾をどう扱うか、変更をどう確認するかは、製品に対応する画面と流れがあるかによります。スキルを入れる前に、そのスクリプトを見てください。WorkBuddyの公式も、非公式のスキルにはインジェクションのリスクがあると注意しています。

Q:コンテキストを1Mにすれば、本全体を入れられますか?
より多くの内容を入れられますが、1ラウンドあたりの消費も増えます。WorkBuddyを例にすると、公式はGLM-5.3は1Mまで開けると説明し、「モデルが賢くなるわけではなく、1ラウンドあたりの消費が倍々に増えるだけ」と注意しています。全書を一度に入れられるかは、ほかのコンテキストの占有にもよります。章ごとに必要な資料を選ぶのも、消費を抑える方法です。

Q:Maliang Writerは、どのモデルを使っていますか?
モデルは選べ、選んだモデルと使用量に応じてクレジットが差し引かれます。具体的には、製品内の表示に従ってください。

すべての記事に戻る