結論：プロンプトは問題発生のたびにルールを追加する運用では必ず肥大化する。2026年4月時点の筆者のプロンプトは888行・22セクション・65チェック項目で、AIが全体を一貫して追従できる限界に近い。モデルのバージョンを上げても解決しない。対策は「プロンプトの改修」だけでなく「AIに任せる範囲を狭める」方向に踏み込む必要がある。

ムラサキ

この記事は、その壊れたAI応答を目撃した直後に書き始めました。リアルタイムの事例として残します。

プロンプトが育ちすぎて何が起きたか

今回発生した事象を具体的に記録する。同じパターンに気づいていないだけで、他の利用者にも起きているはずだ。

発生した具体事象①｜存在しない成果物番号を創作

今回のAI応答には、article_prompt.mdに存在しない成果物番号が6つ出力された。正解は「成果物2：アイキャッチ画像テキストデータ」「成果物3：記事データ」「成果物4：既存記事対応リスト」の3つだ。AIが生成したのは次の通り。

特に深刻なのは「成果物3：スプレッドシート行（タブ区切り）」だ。これはMake経由でスプレッドシートにAI出力を流し込んでいた時代の古い仕様で、現行のAPIパイプライン移行後は廃止されている。AIはプロンプト本文の現行仕様ではなく、過去の痕跡か自己の学習データから古い形式を再構成した。

発生した具体事象②｜Cocoonブロックのテンプレ逸脱

事象はこれだけでは終わらなかった。同じAIが本文HTMLを出力した際、Cocoon独自ブロックのテンプレートを9箇所全てで逸脱していた。最も分かりやすい例が吹き出しブロックだ。

プロンプトの吹き出しテンプレートでは、JSON属性のキー名としてname・icon・iconid・id・indexの5つを明示している。またサイト別のアイコンURLも具体的に記載されている。にもかかわらずAIが出力したHTMLは次のようだった。

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モデル側だけでなく、Claude Codeのクライアント側に起因する詰みもあります。代表例として画像貼付で発生する400エラーの構造を別記事で扱っています。

取りこぼし｜指示が効かなくなる

プロンプトに書かれた指示が出力に反映されないパターンだ。長文インプットでは指示の一部が漏れやすい。プロンプト規模が大きいほどリスクは高まる。

対策は「重要なルールを冒頭と末尾に配置する」こと。ただし重複するとプロンプト自体が肥大化するため、本当に重要な項目だけ冒頭に再掲する運用が現実的だ。

創作｜存在しない仕様を自己生成する

プロンプトに明記されていない仕様を、AIが学習データやプロンプト内の曖昧な表現から再構成して出力する。厄介なのは創作内容がそれらしい形式を保つため、検知が難しいことだ。

対策は「成果物の番号・名称・数をプロンプト冒頭で明示する」こと。article_prompt.mdでは1行目に「3つの成果物を出力してください」と書かれていたが、AIは最終的に6つ出力した。冒頭の明示だけでは足りず、出力テンプレート自体に「成果物2」「成果物3」「成果物4」の見出しを固定する対応が必要だ。

構造崩れ｜テンプレ厳守の指示でも出力がズレる

Cocoon独自ブロックのclass名・属性・ネスト構造が1バイトでも違うと、WordPress投稿後にブロックが崩れる。「テンプレートを1文字も変えずにコピーする」と指示しても、AIが微妙に変形させる事象が繰り返し発生した。

プロンプト内にテンプレート全文とサイト別アイコンURLが具体的に明記されているのに、AIはJSON属性キー名を別の単語に創作し、img srcを空文字で出力した。これは「指示を見落とした」のではなく「プロンプトより自己の学習データを優先した」結果だ。

対策は「禁止パターン例をプロンプトに明記する」こと。「×こう書くのは間違い／◯こう書くのが正解」という具体例を並べるとAIの独自解釈を抑制できる。ただし例を増やすほどプロンプトが肥大化するトレードオフがある。この矛盾こそが、「AIに任せる範囲を狭める」改善へつながる。

壊さないための設計原則

運用の中で身につく、プロンプトを壊さない設計原則をまとめた。当たり前に見えることばかりだが、実際には実行できていない部分が多い。

この「検証可能な指示だけが効く」原則を、完了条件として毎回強制する仕組みが/goalだ。評価器に証拠を出させる完了条件の書き方に、実際に効いた条件の4要素をまとめている。

セルフチェックの現実的な運用

現状の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運用の実例で似た分割構造を試しているので、その知見を横展開できる。

プロンプトを安定させることはキャッシュヒット率にも直結します。書き換えのたびにキャッシュが壊れる仕組みはPrompt Cacheでトークンを10倍安くする方法で詳しく整理しました。

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＋ルールベース変換方式は次のステップで実装予定です。

よくある質問

まとめ

プロンプトが888行を超えたら、モデルのバージョンアップを待つより設計を見直すべき。長大なプロンプトは破綻する。

今回の問題は、プロンプト運用の限界を示している。AIに複雑な構造ルールを守らせるより、Markdown＋ルールベース変換をPython側で機械的に処理する方が確実だ。次の記事では実装結果を公開する。