プロンプトを丁寧に書いても、AIの出力はブレます。
原因は思想を「渡した」のではなく「貼り付けた」からです。
この記事では、AIに思想を再現させるための構造設計の判断基準を整理します。
AIはプロンプトを処理しますが、思想を持ちません。思想とは「判断の根拠を構造化したもの」です。どれだけ丁寧なプロンプトを書いても、それが構造として設計されていなければAIは毎回違う判断をします。AIに思想を再現させるには、プロンプトを渡すのではなく、役割と判断基準を構造として設計することが必要です。
AIはテキストを理解しますが、思想を持ちません
AIは与えられたテキストを処理する能力を持っています。長文を読み込み、要約し、構造を把握し、指示に従って出力を生成できます。
でも、AIは思想を持ちません。
思想とは「一貫した判断の根拠」です。「この状況ではこう判断する、なぜならこういう価値観があるから」という軸のことです。人間が思想を持つのは、経験と価値観が蓄積されて判断のパターンが内面化されているからです。
AIにはその内面化がありません。毎回の処理は独立しています。同じプロンプトを渡しても、同じ判断が返ってくる保証はありません。プロンプトの文脈が変われば、出力の方向も変わります。
「このプロンプトは毎回同じ判断を再現できるか」——これが、AIに思想を渡す設計の出発点の問いです。
私がビジネッツの記事執筆パイプラインを構築したとき、この問いに向き合うことになりました。「ビジネッツらしい記事」を毎回安定して生成するには、AIに何をどう渡せばいいのかを設計しなければならなかったからです。
MCP環境とn8n環境で思想の再現性が変わった——その原因は何ですか
最初、私はClaude MCP環境でパイプラインを動かしていました。この環境では、AIがGoogle DriveやローカルのMarkdownファイルを直接参照できます。create-article.txtというビジネッツの記事設計ルール全文を、AIが必要なときに読みに行く設計でした。
この設計では、AIは記事を書くたびに「ルール全文」を参照して判断していました。コンテキストの範囲が広いため、思想の再現性は比較的安定していました。
n8nに移行したとき、この前提が崩れました。
n8nのLLMノードはAPIを通じてAIに問い合わせます。外部ファイルの自律的な参照はできません。各ノードが受け取れるのは、そのノードに直接渡されたテキストだけです。コンテキストの範囲が、MCP環境と比べて大幅に限定されました。
コンテキストの範囲が変わると、思想の再現性も変わります。この変化がn8n移行後の整合性崩れの根本原因でした。
失敗：思想を「貼り付けた」——あなたのプロンプトは構造になっていますか
n8nへの移行直後、私はcreate-article.txtをそのままLLMノードのSystem promptに貼り付けました。MCP環境で機能していたルール全文をそのままコピーした形です。
結果、複数の問題が起きました。
MCP操作指示が混入した
create-article.txtには「ファイルを作成する」「CSVに追記する」というMCP向けの操作指示が含まれていました。n8nのLLMノードはMCPと接続していないため、これらの指示はAIにとって意味をなさない命令として混入し、出力の整合性を乱しました。
プレースホルダーが未置換のまま出力された
{{KEYWORD_JA}}のような変数が、置換されないまま出力本文に出ることがありました。汎用プロンプトの構造がn8nのデータフローと噛み合っていなかったからです。
BZタグとCTA導線が機能しなかった
ビジネッツ記事の構造要素（[BZ:conclusion]タグ・内部リンクの配置ルール・CTAの挿入位置）が安定して再現されませんでした。全ルールを1つのプロンプトに詰め込んだことで、AIはどの判断をどの処理で使えばいいかが曖昧になっていました。
クレジット消費が激増した
長文のルール全文を毎回読み込む設計では、ノードごとのトークン消費が大きくなりました。
これらの問題はすべて、「思想を渡した」のではなく「情報を貼り付けた」ことから起きていました。
解決：思想を分解して構造として渡す
問題の根本は「1つのノードに複数の役割を持たせていたこと」でした。解決策は、役割ごとにプロンプトを分割して、それぞれのノードに必要な判断だけを渡すことです。
私がパイプラインを最初から分割設計で実装した理由は、すでに「設計と生成を分けた方が精度が上がる」という知見が公開されていたからです。自分でゼロから試行錯誤する必要はありません。「巨人の肩の上に立つ」という言葉通り、先人が検証した最適な方法を最初から採用するのが合理的な判断です。
私のパイプラインでは、役割をこう分割しました。
01ノード（設計：gpt-4o-mini）
- タイトル・seoTitle・seoDescriptionのSEOルール
- H2構造の設計基準（タイプ分類・想定字数・差別化観点）
- 内部リンク候補の選定ルール
- primary_topicとtopicSlugsの選定基準
02ノード（生成：claude-sonnet-4-6）
- ビジネッツの文体ルール（ですます調・問いかけ・一人称）
- BZタグの使用基準（conclusion・important・caution・check）
- CTA導線の挿入位置と文面
- 内部リンクブロックの配置ルール
モデルの使い分けも設計の一部です。設計（タイトル・構造）はgpt-4o-miniに任せ、ビジネッツの思想・文体の判断が必要な生成はclaude-sonnet-4-6に任せています。「思想判定が必要かどうか」が使い分けの基準です。
「全部を1つのプロンプトに詰め込めば完全になる」は誤りです。判断の種類が増えるほど、1つのノードで扱うコンテキストは重くなり、各判断の再現性は下がります。
この分割後、内部リンクの配置・primary_topicの選定・BZタグの使用が安定して意図通りに機能するようになりました。
AIに思想を持たせる設計とは何か——あなたのプロンプトは3問に答えられますか
ここまでの経験から、「AIに思想を持たせる」とはどういうことかが整理できました。
思想とは判断根拠の構造です。「この状況ではこう判断する理由」を言語化して、処理の手順として設計したものが思想の構造化です。
AIにこの構造を渡すには、3つの問いを使います。
– このプロンプトで判断が再現できるか → NOなら判断基準が曖昧。言語化が不十分
– このプロンプトで出力が揺れないか → YESなら役割が明確。NOなら分割が必要
– このプロンプトは役割が明確か → NOなら複数の判断が混在している。分割する
この3問に答えることで、プロンプトが「思想の構造」として機能しているかを診断できます。
「貼り付け」と「構造設計」の違いは、この3問に答えられるかどうかです。create-article.txtをそのまま貼り付けたとき、3問のどれにも答えられませんでした。01ノードと02ノードに分割した後は、3問すべてに答えられます。
他の設計領域への応用——この原則はどこまで広がりますか
この原則は、n8nやAI記事生成に限りません。
チーム設計
人間のメンバーに仕事を渡すとき、「役割と判断基準が明確か」を問うことは、AIへの思想設計と同じ問いです。「あとはよろしく」という渡し方は、プロンプトを貼り付けるのと同じです。
AI活用全般
ChatGPTへの依頼でも、Claudeへのプロンプトでも、「この依頼は役割が明確か」「判断が再現できる渡し方か」を問うことで、出力の安定性が変わります。汎用的な質問ではなく、役割を特定した問い方をするだけで精度が上がります。
設計思想の統一
複数のAIを使う設計では、どのAIにどの判断を任せるかの設計が必要です。私のパイプラインでは「思想判定はClaude、情報処理はgpt-4o-mini」という役割分担が設計の核にあります。これも「思想を構造として設計する」の一形態です。
まとめ——今日、使っているプロンプトに3問を当てはめてみてください
AIに思想を持たせるための原則を整理します。
- AIはテキストを処理しますが、思想を持ちません：プロンプトを渡しても思想は移りません
- 思想とは判断根拠の構造です：一貫した判断が再現できる形に言語化したものが思想の構造
- 構造として渡したときだけ再現されます：役割が明確で、判断基準が分離されたプロンプトだけが思想を再現します
今日できる一歩を3つ挙げます。
- 今使っているプロンプトに「このプロンプトは役割が明確か」を問いかけてみてください。複数の判断が混在していれば、分割の余地があります。
- 「このプロンプトで出力が揺れないか」を確認してください。揺れているなら、判断基準が曖昧な部分を特定してください。
- 設計（構造・方針）と生成（出力・文体）を分離できないかを検討してみてください。分割するだけで再現性が上がります。
思想は理解させるものではありません。設計するものです。
判断の順番を整理したい方に、無料PDFを用意しています。
コメント