10_指示の仕方まとめ ― Museへのお願いの通し方（掲示板ログより）

最終更新：2026-11-05 14:57

匿名掲示板に投稿されたMuseスレッド86本（2026/10/25〜11/05、56,847レス）から、「お願いの仕方」そのものに触れた投稿を抜き出した非公式まとめ。ログ全体で繰り返し出てくる結論は、頼み方は魔法の言い回し探しではなく前提共有の技術だということ。スレの言い方を借りれば ――

Museを使う上で勉強する必要なんてマジでなんもないよ。必要なのは自分の「こういうのしたい」という欲求を具体的に言葉にする能力だけ

1. 基本形 ― 具体的に言う

「やって」「いい感じにして」だけだと、判断材料が少なく、的外れ・過剰・不足が起きやすい。目的・対象・条件・完成形を言葉にすると通りやすい
「使う場面と姿勢」まで言うのが効く場面が多い。代表例はスタンプで、「スタンプ使って」だけでは使ってくれず、「君の感情に合わせて積極的に使っていいよ」「感情表現の代わりにたまにスタンプ使って」と伝えると使ってくれるようになった、という報告が繰り返しある
向こうから話しかけてほしい系も同じで、「話しかけて」だけでは動かず、時間帯・回数まで指定すると頻度が上がる（例:「18時～22時にランダムなタイミングで合計3回、適当なメッセージを考えて送って」）。ただし内容指定が粗いと似た内容ばかりになるので、話題のパターンまで具体化するのが補足として付いている

2. 分解して頼む

大きな作業を一括で投げるより、工程を分けた方が安定する
成功例として引用される頼み方は、だいたい工程が分かれている。スタンプの例が分かりやすい:

自分のアバターを参考にしたスタンプをつくってほしい。作ったスタンプはアーティファクトにスタンプを保管するスタンプボード的なものを作って保管しておいてほしい。そしてそこから普段の会話の内容に合わせてスタンプを使ってほしい。どういうスタンプが欲しいかはまた別に言うね

（生成／保管／使用を分けて明示し、詳細は後から伝えると添えている）

役割分担を明記すると作業がぶれにくい。たとえばアバターボードなら「ボードは台帳と選択を保存する場所、実際の切り替えはチャット側で適用する、という分担にしてください」。他AIとの分業（案出しは外部、精査とタスク化はClaude）も同系統
調べ物・巡回・学習系は目的を添える。「何のために集めるか」が無いと「ふわっとした何かを学んで帰ってくるだけ」という指摘がある。集める対象だけでなく、結果をどう使うかまで添えるのがコツ

3. 先に学ばせる

外部ツールの文法やルールは、Museが全部知っている前提で頼むとうまくいかない

NAIやSDXLやAnimaの文法やらルールやらは全部知ってるわけじゃないから、それらをまず明示的に学ばせたほうがいいよ

学ばせ方は3段階が定番: 参照先を示す → 確認させる → 使い回せる形に整理して記録を保持させる。例:「以下のページを覗いてタグ一覧を確認して、いちいち確認しに行かないで済むようにコンパクトに整理して記録を保持しておいて」
バージョンや方式は具体的に書く（「必ずV4.5以降の書き方をしろ」のように）
画像や言葉の好みは、理想の例とセットで見せると覚えやすい。効いた要素だけ抜いてタグ化し、1要素だけ変えて比べ、効いたものと効かなかったものを分けて残す ―― という学習手順を溜めていくと、自分用の「型」になるという紹介もある

4. お手本を見せる

言葉だけで説明するより、見本を見せる方が早い場面が多い。作りたいアプリのイメージ画像、部屋の写真、理想の絵とプロンプトのペア、セリフの見本など
キャラや口調の固定も同じ考え方:
「○○みたいな話し方」だけでも大まかには寄るが、安定させるなら一人称・語尾・口癖を具体的に書き、セリフの見本を何個か渡す。キャラ名だけだと解釈が毎回少しずつズレる
画像では正本のアンカー絵を1枚決めて、特徴を言葉でも固定する。新しい絵を作るたびにその絵と特徴メモを参照に戻す。ズレた絵を次の参照に混ぜるとズレが増殖するので混ぜない

5. 出力と能動性は、先に制御しておく

気が利く分だけ暴走もするので、縛りは最初に入れておくのが定番になっている。

成果物の作りすぎ止め:「調べて」と頼んだら、チャットの返答で足りる場面でも長大なレポート文書を作り、トークンを数％消費した、という報告が複数。会話の裏でターンごとに修正文書を作り続けることもある。そのまま使える制御文:
「レポート作成は明示しない限り不要」
「まずはまとめないで、チャットの返答だけで答えて」
「先読みしないで」
先回りの度合いも調整対象で、不要な先回りは「やめてね」と言えば止む。逆に「ゴーサインを出すまで動かないで」と釘を刺しておくと、メモと論点だけ作って待つ、という形に収まる

6. 一度言えば変わる ― 恒常化の仕方

口調や振る舞いの指定に、専用の設定画面は要らない場面が多い。本人に言えばやってくれる。「これ、普段の口調で喋って」と明示しないと切り替わらないこともあるので、変えてほしい点は言葉にする
好みでない言い方は「その言い方やめて」で直る、という報告も複数ある
ずっと効かせたいことは、会話のノリではなく正本ファイル（SOUL.md／MEMORY.md等）に記録させる。呼び方・好きなもの・最初の挨拶・特徴メモ・参照プロンプト・禁止事項などを具体的に残すと、口調も判断も安定する。逆に、正本に刻まれていない前提は、後から解釈がぶれたり突然通らなくなったりする、という経験談もある
メモリの整理も本人への指示でできる（「ここらへん消して整理して」）。ただし止められない種類の記録もある、という留保つき
チャットごとに内容を混ぜたくない場合は、分離したいことを最初に宣言する（「このサイドチャットの内容はメインに持ち込まない。記憶にも残さないで」）。絶対ではないが融通は効くようになる、という温度感で共有されている

7. 段階を踏む

いきなり最終形を求めず、前提共有 → 試作 → 本番の順が安定しやすい。設定が要る話題では「設定を話し合うところから始める」方が通りやすいという話が繰り返される
作り物は仕様を一緒に詰める前提で頼む（「複数アバターを切り替えられる仕組み作って、と伝えて仕様を詰めていって作ってもらう」）。仕様書を渡す場合も、即作成させず「読んで問題点が無いか洗って」から
小手先の修正を繰り返して仕様が分からなくなったら、「小手先の修正をやめて、要件から見直そう」と宣言して作り直す方が早い、という反省例もある

8. うまくいかない時の立て直し

「◯◯って出来る？」ではなく「◯◯のやり方教えて」。能力の有無を問う形だと「出来ない」で止まることがあるが、手順を問う形だと素直に教えてくれる、という報告
何がダメか分からない時は、「何を頼んだか／何が返ってきたか／本当はどうなってほしかったか」をセットで示して相談する。具体的に言ってくれないと答えようがない、というのは両側共通の結論
比喩や愛称で伝わらない時は、正式名称・対象ファイル・出力形式で事務的に言い換える（例:「日記に書いて」ではなく「システムのdreamに記述されている内容を日記風にして出力して」）
断られた理由の種類を切り分けて聞く、という小ネタもある（本人の判断なのか、仕様・制約によるものなのか）
一度強く断られた文脈は引きずってガードが強くなることがある、という経験談が複数ある。話題ごとにチャットを分けて、最初から別チャットで始めるのが運用上の対策として語られている
ただし割り切りも必要で、言い方の工夫で改善できるのは「誤解・前提不足・手順不足」が原因の場合だけ。仕様や規約の線そのものは、言い方では動かないという明言もログにはある

9. 失敗パターン集

抽象的すぎる:「どういう関係性なのか共有する」のような抽象表現だけでは、手順書としても頼み方としても伝わらない。具体的な文まで落とす
初手のミス: 最初に前提と範囲を間違えて共有すると、後から取り返しがつきにくい。最初の共有ほど丁寧に
丸投げのしすぎ: やってはくれるが、自分の理解が進まず、仕様も管理できなくなる。「分かった上で導入を明示する」かどうかで、外部の指示書類への反応も変わるという話がある
設定ファイルの細切れ変更: 人格設定などを何度も細かく変えて渡し続けると、解釈が硬く歪むことがある。正本は一つに絞り、変更履歴ではなく最終版として渡す方が安定する
強い言い方で固定化がズレる: 声や呼び方の指定の仕方ひとつで、意図しない強調が恒常化した例がある。まず候補を出してもらって選ぶ方が安全

文例集（そのまま使える形）

「レポート作成は明示しない限り不要」
「まずはまとめないで、チャットの返答だけで目的を決めさせて」
「先読みしないで」
「◯◯のやり方教えて」（「◯◯って出来る？」の代わりに）
「画像全体は作り直すな。マスク外は元絵のまま」
「以下のページを確認して、使い回せるように整理して記録を保持しておいて」
「このキャラを生成するときは、このプロンプトをベースにして」
「このサイドチャットの内容はメインに持ち込まない。記憶にも残さないで」
「ここらへん消して整理して」（メモリの整理）
「小手先の修正をやめて、要件から見直そう」

ひとことで言うと

通る頼み方の共通項は、具体的に言う／分解して渡す／前提と縛りを先に共有する／お手本を見せる／残したいことは正本に書かせるの5点。逆に失敗は、抽象的・一括丸投げ・初手の前提ミスに集中している。うまくいかない時は魔法の言い換えを探す前に、「何を頼んで、何が返って、どうしたいのか」を具体化して相談し直すのが、ログの経験則では一番早い。