2026年4月17日、3サイトの記事制作で使っているarticle_prompt.mdに従って記事を書かせたところ、AIが存在しない「成果物1・5・6」を勝手に創作した。実際の定義は「成果物2・3・4」の3つしかない。さらに同じチャット内で、Cocoon独自ブロックのテンプレートも9箇所全てで逸脱させた。SE歴20年・Claude Code Max 5xプランで記事制作と自動化パイプラインを運用する筆者が、プロンプト肥大化で起きる破綻パターンと、Markdown＋ルールベース変換による改善方向を整理する。
結論：プロンプトは問題発生のたびにルールを追加する運用では必ず肥大化する。2026年4月時点の筆者のプロンプトは888行・22セクション・65チェック項目で、AIが全体を一貫して追従できる限界に近い。モデルのバージョンを上げても解決しない。対策は「プロンプトの改修」だけでなく「AIに任せる範囲を狭める」方向に踏み込む必要がある。
この記事は、その壊れたAI応答を目撃した直後に書き始めました。リアルタイムの事例として残します。
プロンプトが育ちすぎて何が起きたか
今回発生した事象を具体的に記録する。同じパターンに気づいていないだけで、他の利用者にも起きているはずだ。
発生した具体事象①｜存在しない成果物番号を創作
今回のAI応答には、article_prompt.mdに存在しない成果物番号が6つ出力された。正解は「成果物2：アイキャッチ画像テキストデータ」「成果物3：記事データ」「成果物4：既存記事対応リスト」の3つだ。AIが生成したのは次の通り。
| AIが出力した成果物名 | 実際の定義 |
|---|---|
| 成果物1: 記事データ（キー名付き形式） | 成果物3の一部 |
| 成果物2: アイキャッチ画像テキストデータ（3パターン） | 成果物2は存在するが3パターンは指示されていない |
| 成果物3: スプレッドシート行（タブ区切り） | 現行仕様に存在しない（旧Make運用時代の仕様） |
| 成果物4: 既存記事対応リスト | 正しい |
| 成果物5: 画像一覧＋内部リンク設置指示 | 存在しない |
| 成果物6: FAQ JSON-LD | 成果物3のfaq_jsonldフィールドとして存在 |
特に深刻なのは「成果物3：スプレッドシート行（タブ区切り）」だ。これはMake経由でスプレッドシートにAI出力を流し込んでいた時代の古い仕様で、現行のAPIパイプライン移行後は廃止されている。AIはプロンプト本文の現行仕様ではなく、過去の痕跡か自己の学習データから古い形式を再構成した。
発生した具体事象②｜Cocoonブロックのテンプレ逸脱
事象はこれだけでは終わらなかった。同じAIが本文HTMLを出力した際、Cocoon独自ブロックのテンプレートを9箇所全てで逸脱していた。最も分かりやすい例が吹き出しブロックだ。
プロンプトの吹き出しテンプレートでは、JSON属性のキー名としてname・icon・iconid・id・indexの5つを明示している。またサイト別のアイコンURLも具体的に記載されている。にもかかわらずAIが出力したHTMLは次のようだった。
| 項目 | プロンプトの指定 | AIの出力 |
|---|---|---|
| JSON属性キー | name / icon / iconid / id / index | iconImage / iconName / balloonName |
| img src | shumatsu-lab.com/…/murasaki_icon.png（明記） | 空文字 |
| divクラス | speech-wrap sb-id-1 sbs-stn sbp-l sbis-cb cf block-box not-nested-style cocoon-block-balloon（9クラス） | speech-wrap sbs-right sbp-2 sbis-cn cf block-box（5クラス・一部創作） |
| 本文pタグ | wp:paragraphブロックで囲む | プレーンテキスト直書き |
JSON属性のキー名は完全に創作されている。プロンプトにはiconImageやiconNameという文字列は出現しない。AIが自己の学習データから別形式のCocoon記述を想起し、プロンプト内の正規テンプレートより優先して出力した。
timeline・faq・icon-boxでも同じパターンの逸脱が起きた。特にfaqは5問分全てがプロンプトの正規テンプレートと構造が異なり、WordPress投稿後にバリデーションエラーが出た。
過去にも起きていたブロック構造崩れ・登録漏れ
プロンプト肥大化による破綻は、実は以前から別の形で起きていた。Cocoon独自ブロック（FAQ・timeline・icon-box等）のclass名や属性を守れず、WordPress投稿後にブロックが崩れるケースが多発していた。
また、記事更新時の変更履歴登録漏れも繰り返し発生した。本文中に「更新履歴を必ず追加する」と記載していても、AIが見落とす。問題が起きるたびにプロンプトへチェック項目や禁止パターンを追加してきた結果、現在は65項目まで膨らんだ。
問題発生は「AI側の劣化」ではなく「プロンプト側の設計限界」
今回の事象は2026年4月16日にClaude Opus 4.7がリリースされた翌日に発生した。「4.7が4.6より指示を取りこぼしやすい」という解釈も成り立つが、1サンプルでモデル傾向を断定するのは早計だ。
本質的な原因はプロンプト側にある。どれだけモデルが賢くなっても、888行の指示を完全に追従できる保証はない。問題発生のたびにルールを追加する運用を続ける限り、いずれ破綻する。プロンプト設計そのものを見直す必要がある。
肥大化の軌跡｜0項目から70項目超までの成長曲線
65チェック項目に至るまでの経緯を整理する。同じ道を避けるための参考になるだろう。
問題発生のたびにルール追加で膨らんでいく構造
最初はチェック項目ゼロから始まった。AIに記事を書かせ、出力に問題が出るたびに「次回から○○しないこと」というルールを1行追加する。この運用で最終的に70項目を超える規模まで膨らんだ。
各項目は「発生実績のある問題への対策」なので削りづらい。削った瞬間に同じ問題が再発する恐怖がある。加算のみで減算がない運用になってしまう。
運用基盤の変更（スプレッドシート→パイプライン）で一気に不要化
転機は運用基盤の変更だった。以前はAI出力をスプレッドシートに貼り付け、Makeで自動投稿する構成だった。タブ区切り形式・文字数制限・Make連携専用のルールが多数存在していた。
WordPress REST APIへ直接投稿するパイプラインに移行した際、Make連携前提のルール群が不要になった。この棚卸しでチェック項目は2〜3割削減できた。重要なのは「不要ルールが2〜3割も残っていた」という事実だ。
現状の規模と「AIが読める限界」の体感値
2026年4月時点のarticle_prompt.mdの規模。
- 全888行・約72,000文字（およそ2.5万〜3万トークン）
- 22セクション
- 65項目のセルフチェック
- バージョンv4.3（複数回のリファクタリングを経由）
Claudeのコンテキストウィンドウ1Mトークンに対しては微々たる量だが、「指示を正確に追従できる規模」という観点ではすでに限界付近だ。プロンプト側の複雑度が高ければ取りこぼしが発生する。
AIが落ちるパターンの分類
運用で観測したAI応答の破綻パターンは3つに分類できる。タイプごとに原因と対策が異なる。
取りこぼし｜指示が効かなくなる
プロンプトに書かれた指示が出力に反映されないパターンだ。長文インプットでは指示の一部が漏れやすい。プロンプト規模が大きいほどリスクは高まる。
対策は「重要なルールを冒頭と末尾に配置する」こと。ただし重複するとプロンプト自体が肥大化するため、本当に重要な項目だけ冒頭に再掲する運用が現実的だ。
創作｜存在しない仕様を自己生成する
プロンプトに明記されていない仕様を、AIが学習データやプロンプト内の曖昧な表現から再構成して出力する。厄介なのは創作内容がそれらしい形式を保つため、検知が難しいことだ。
対策は「成果物の番号・名称・数をプロンプト冒頭で明示する」こと。article_prompt.mdでは1行目に「3つの成果物を出力してください」と書かれていたが、AIは最終的に6つ出力した。冒頭の明示だけでは足りず、出力テンプレート自体に「成果物2」「成果物3」「成果物4」の見出しを固定する対応が必要だ。
構造崩れ｜テンプレ厳守の指示でも出力がズレる
Cocoon独自ブロックのclass名・属性・ネスト構造が1バイトでも違うと、WordPress投稿後にブロックが崩れる。「テンプレートを1文字も変えずにコピーする」と指示しても、AIが微妙に変形させる事象が繰り返し発生した。
プロンプト内にテンプレート全文とサイト別アイコンURLが具体的に明記されているのに、AIはJSON属性キー名を別の単語に創作し、img srcを空文字で出力した。これは「指示を見落とした」のではなく「プロンプトより自己の学習データを優先した」結果だ。
対策は「禁止パターン例をプロンプトに明記する」こと。「×こう書くのは間違い／◯こう書くのが正解」という具体例を並べるとAIの独自解釈を抑制できる。ただし例を増やすほどプロンプトが肥大化するトレードオフがある。この矛盾こそが、「AIに任せる範囲を狭める」改善へつながる。
壊さないための設計原則
運用の中で身につく、プロンプトを壊さない設計原則をまとめた。当たり前に見えることばかりだが、実際には実行できていない部分が多い。
- 原則1運用基盤が変わったら即座に不要ルールを削る
出力先・投稿フロー・連携ツールが変わったら、その前提で作られたルールは全て再評価する。筆者はMake→APIパイプライン移行でチェック項目を2〜3割削減できた。
- 原則2発生実績のないチェック項目は削除候補に回す
必要性は認識していても、実行するには記事投稿時に「引っかかった項目」「引っかからなかった項目」を記録する仕組みが必要。そのデータなしに削減判断はできない。
- 原則3プロンプト内で同じ情報を複数箇所に書かない
重複記載はメンテナンスコストと不整合リスクの両方を生む。1か所に集約し、他では参照マーカーで誘導する。
- 原則4重要なルールは冒頭と末尾の両方に配置する
取りこぼし対策として効く。ただし再掲は本当に重要な項目に絞る。全項目を再掲するとプロンプト自体が倍加して逆効果になる。
- 原則5問題発生時だけでなく運用構造変更時にも見直す
問題ベースの見直しでは機能追加の加算だけになる。運用構造の変更時に減算する機会を作る。この2タイミング両方で見直さなければ肥大化を止められない。
セルフチェックの現実的な運用
現状の65項目のセルフチェックは、AIに全項目チェックさせる前提で設計されている。だがこの前提自体が限界に近い。
AIに65項目を全部チェックさせることの限界
今回の事象がそれを示している。AIは「成果物数は3つ」というプロンプト冒頭の前提すら守れず、Cocoonブロックテンプレートも9箇所全て逸脱させた。この状態で65項目のセルフチェックが機能していると考えるのは無理がある。
実際にはAIが「セルフチェック済み」と主張しながら、一部項目しか確認していない可能性が高い。そうなると、65項目の存在意義そのものが成り立たない。
加算ではなく減算を前提にする発想の転換
チェック項目を減らすことを運用の中心に据え直す必要がある。これまでは「問題発生→対策ルール追加」という加算型で動いており、削除の機会がなかった。加算を続ければいずれプロンプトは破綻する。
逆の発想を導入する。新しいルールを追加するときは、不要になったルールを同時に1つ削る。追加と削除をセットで回せば、ルール総量の肥大化を防げる。筆者自身も完全には実行できていないが、今回の事象を機に減算の仕組み化を進める必要がある。
今後のプロンプト運用ロードマップ
今回の事象を受けて、筆者がこれから試す運用改善は4つ。そのうち1つは、AIの構造崩れ問題を根本から解決する可能性がある。
プロンプト本体とチェックリストを物理的に分離する
現状はarticle_prompt.md一本にプロンプト本体と65項目のチェックリストを同居させている。この肥大化が取りこぼしを招いている。
検討中の案は、本体プロンプト（出力仕様・執筆ルール）とチェックリスト（出力後の自己検証項目）を別ファイルに分離し、AIに2段階で読み込ませる構成だ。本体を短く保ちながら、チェックは別リソースとして明示的に実行させる。
チェック項目の定期棚卸しワークフロー
発生実績のないチェック項目を削除する。記事投稿時にAIがチェック結果を記録し、月次で「引っかかった項目」と「引っかからなかった項目」を集計する。データで削減判断できる状態にする。
小規模プロンプト×複数回呼び出しへの分割構想
1本の巨大プロンプトで全工程を指示するのではなく、フェーズごとに小規模プロンプトを連鎖させる方式も検討している。「構成案生成」「本文執筆」「内部リンク設計」「セルフチェック」を別プロンプトで実行し、前段の出力を次段に渡す。
欠点は情報伝達ロスと実装コスト。シンプルさを失う代わりに各フェーズでの指示追従性が上がる。Claude CodeでのCLAUDE.md＋BUGS.md運用の実例で似た分割構造を試しているので、その知見を横展開できる。
Markdown＋ルールベース変換方式への移行
今回の構造崩れ問題への最も本質的な対策はAIに任せる範囲を狭めることだ。AIには標準Markdown＋カスタムコンテナ記法で書かせ、Python側のルールベース変換器でCocoon HTMLに変換する。
この方式のMarkdown記法はZennやQiitaが採用しているものと同じ考え方だ。吹き出しブロックは次のように書く。
:::balloon name=ムラサキ
この記事はその壊れたAI応答を目撃した直後に書き始めました。
:::この3行をPython側の変換器が受け取り、サイト別の正規Cocoonテンプレートに機械的に展開する。アイコンURL・iconid・divクラス・JSON属性キーなど、AIが間違えやすい要素を変換器が自動で埋める。
実装の主要部分はPython製Markdownパーサー（markdown-it-py）の拡張機能で実現できる。工数見積は約3日（22時間程度）。現在使用中の9種のCocoon独自ブロックはすべてこの方式でカバー可能だ。wp:columnsやwp:groupのような利用頻度ゼロのブロックは当面対応せず、必要になったときに追加する。
この記事自体は現行ルール（Cocoon HTMLベタ書き）で出力しています。Markdown＋ルールベース変換方式は次のステップで実装予定です。
よくある質問
- Qプロンプトはどれくらいの規模から肥大化リスクが出ますか？
- A
セクション数が20以上、チェック項目が50を超えると、人間も全体を把握しきれなくなり、AIの取りこぼしや創作リスクが高まります。
- Qどのタイミングでプロンプトを棚卸しすべきですか？
- A
問題が出たときに追加・修正する、出力先やワークフローが変わったときに見直すの2つが効果的です。実績のないチェック項目は削除候補に回すと、自動的にプロンプトが整理されます。
- QClaude Opus 4.7は4.6よりプロンプトを取りこぼしやすいですか？
- A
本記事の事例は4.7リリース直後の1サンプルで、4.7固有の傾向なのか偶発的なものなのか判断できません。モデルバージョンより、プロンプト側の肥大化が根本的な原因と考えるべきです。
- Qプロンプトを分割すべきですか？
- A
1チャット内で完結するワークフローなら一体化のほうが情報ロスが少なくなります。複数フェーズに分解できるなら小規模プロンプト×複数回呼び出しのほうが安定します。
- QMarkdownとCocoonの変換を自動化する方法はありますか？
- A
AIにMarkdown（カスタムコンテナ記法含む）で書かせ、PythonでルールベースにCocoon HTMLへ変換するのが有効です。ZennやQiitaの :::name 記法と同じ手法で、AIの逸脱を防げます。
まとめ
プロンプトが888行を超えたら、モデルのバージョンアップを待つより設計を見直すべき。長大なプロンプトは破綻する。
今回の問題は、プロンプト運用の限界を示している。AIに複雑な構造ルールを守らせるより、Markdown＋ルールベース変換をPython側で機械的に処理する方が確実だ。次の記事では実装結果を公開する。
