公開しようとした記事の「公開」ボタンを押した瞬間、トップページが真っ白になった。

エラーメッセージにはこう書かれていた。

Fatal error: Allowed memory size of 1073741824 bytes exhausted
(tried to allocate ... bytes) in
/home/.../wp-includes/blocks.php on line 1680

「メモリが枯渇した」と。1GBのメモリを使い切った、と。

WordPressに詳しい方なら「あー、ありがちなやつね」と思うかもしれない。でも私は非エンジニアだ。コードを書ける人ではない。それなのに、その日のうちに、このトラブルを根本解決できた。

理由はひとつ──AIをパートナーとして使ったから。

この記事は、その夜の出来事を記録したものだ。技術的な解説と、もうひとつ、私がこの体験を通じて確信した「ある変化」について書いていく。それは「エンジニアと非エンジニアの境界が曖昧になっている」という変化だ。

エラーを見て、最初に思ったこと

ブラウザに表示された真っ白な画面と、英語のエラーメッセージ。

普通なら焦るところだ。サイトが見られなくなった。記事を入稿したばかりなのに。読者が来たら何も表示されない。

しかし、最初に思ったのは「コードが何か変なことしてる？」だった。

少し説明すると、私はその直前に functions.php というWordPressの設定ファイルを編集していた。サイトのトップページに、独自のレイアウト（記事サムネイルの並び方や About セクションの配置など）を動的に表示させるためのコードを追加していた。

そのコードが何か悪さをしている──直感的にそう思った。

そしてもうひとつ、思ったことがある。

「AIに聞けば解決する」と。

これは私の体感的な確信だ。ここ数ヶ月、ChatGPTとClaudeを毎日のように使ってきた経験から、こういう種類の問題は「AIに状況を伝えれば、かなりの確率で原因にたどり着ける」という肌感覚があった。

だから、焦らなかった。

AIに聞いた瞬間、原因が判明した

私がやったのは、ただひとつ。

エラーメッセージをそのままClaudeに貼り付けて、「functions.phpを編集していたらこのエラーが出た」と伝えた。直前に書き換えたコード（自作のレイアウト関数）も一緒に共有した。

Claudeの返答は、一発だった。

knot_works_inject_full_layout 関数の中で get_the_excerpt() を呼んでいるのが原因です。 get_the_excerpt() は内部で the_content フィルターを呼び出します。 そして、あなたの関数は the_content フィルターに登録されています。 つまり、あなたの関数が自分自身を無限に呼び出す構造になっています。

「そりゃそうだよね」と思った。

驚きはなかった。AIならこれくらい突き止めるだろう、と思っていた。

ただ、原因の説明そのものは、最初は何を言っているのか分からなかった。「フィルター」という言葉も、「自分自身を呼ぶ」というのも、初見では意味不明だ。

でも、説明を何度か読み返すうちに、頭の中でイメージが組み上がっていった。

何が起きていたのか──「自分自身を呼ぶ関数」という仕組み

少し技術的な話をする。読み飛ばしても大丈夫だが、この仕組みを理解できたとき、私の中で何かが変わった気がする。だから書き残しておきたい。

無限再帰とは何か

「再帰」というのは、関数が自分自身を呼び出すこと。

正しく使えば便利な仕組みだが、止まる条件がないと、関数は永遠に自分自身を呼び続ける。これを「無限再帰」と呼ぶ。

私のコードで起きていたのは、まさにこれだった。

具体的に何が起きていたか

私の書いたコードは、ざっくりこういう流れだった。

// トップページに、Heroセクションと記事一覧を動的に注入する関数
function knot_works_inject_full_layout($content) {
    if (is_front_page()) {
        $hero = knot_works_hero();
        $articles = knot_works_recent_articles();  // ← この中で問題発生
        $about = knot_works_about();
        return $hero . $content . $articles . $about;
    }
    return $content;
}

// この関数を the_content フィルターに登録
add_filter('the_content', 'knot_works_inject_full_layout');

そして、knot_works_recent_articles() の中で get_the_excerpt() を呼んでいた。記事の抜粋を取得するためだ。

ここで何が起きたか。

1. WordPressがトップページを表示しようとする
2. the_content フィルターが発動 → knot_works_inject_full_layout が呼ばれる
3. その中で get_the_excerpt() が呼ばれる
4. get_the_excerpt() は内部で再び the_content フィルターを呼ぶ ← ここがトラップ
5. すると、knot_works_inject_full_layout がまた呼ばれる
6. その中で再び get_the_excerpt() が呼ばれる
7. 4 に戻る ← 無限ループ

関数が自分自身を呼び続け、PHPが「もうメモリが足りません」と悲鳴を上げて停止した。それが、あのエラーメッセージだった。

解決策──static変数で「処理中フラグ」を立てる

Claudeが提示した解決策は、シンプルだった。

function knot_works_inject_full_layout($content) {
    static $is_processing = false;

    // すでに処理中なら、そのまま返す（再帰を断ち切る）
    if ($is_processing) return $content;

    if (is_front_page()) {
        $is_processing = true;  // 処理中フラグを立てる
        $hero = knot_works_hero();
        $articles = knot_works_recent_articles();
        $about = knot_works_about();
        $is_processing = false;  // 処理が終わったらフラグを下ろす
        return $hero . $content . $articles . $about;
    }
    return $content;
}

ポイントは static $is_processing = false; の部分。

PHPの static 変数は、関数が呼び出されても値が保持される。つまり、関数が自分自身を呼んだとき、最初の呼び出しで立てた「処理中」フラグが、2回目の呼び出しでも残っている。

すると、2回目の呼び出しでは「あ、もう処理中だ」と判断して、何もせずに return する。これで再帰が断ち切られる。

このコードを書き換えて「ファイルを更新」を押した瞬間、トップページが復活した。

「そりゃそうだよね」と思った。AIの言うとおりにしたら、直った。それだけだった。

復旧してから感じた違和感──「これって、エンジニアの仕事じゃないの？」

復旧後、私は次の作業に淡々と移った。記事1の入稿、Aboutページの作成、ナビのカスタマイズ。Day 3 の作業はまだ続いていた。

でも、しばらくしてから気づいた。

「私、いま、エンジニアしか遭遇しないようなトラブルを解決したよね？」

functions.php のフィルター内での再帰問題。これは初心者向けの教科書には載っていない。中級者向けのWordPress開発書を読み込んでいる人か、実際に同じ問題を経験したことがある人しか分からない領域だ。

私はWordPressのコアを読み込んだことはない。PHPも基礎しか知らない。そんな私が、このトラブルを「その日のうちに」「冷静に」「根本解決」できた。

これは何を意味するのだろう。

私が確信したこと──エンジニアと非エンジニアの境界が曖昧になっている

長いこと、社会は「エンジニア」と「非エンジニア」を明確に分けてきた。

エンジニアはコードを書ける人。非エンジニアはコードを書けない人。両者の間には、技術書を何冊も読み、研修を受け、何年もかけて越える壁があった。

しかし、AIの登場で、この壁が崩れ始めている。

私ができたこと、できなかったこと

整理してみる。

私ができたこと

• エラーメッセージを読んで「コードが原因かも」と直感する
• 直前に書いたコードをAIに共有する
• AIの説明を何度か読み返して、仕組みを理解する
• AIの提示したコードを、自分の functions.php に適用する
• 適用後の動作を確認する

私ができなかったこと

• ゼロから「無限再帰」という現象を予測する
• get_the_excerpt() の内部実装を知っている
• static 変数の動作原理を、原典から説明する

つまり、私は 「自分でコードを書いて問題解決する」のではなく、「AIと協働して問題解決する」 スタイルでこのトラブルを乗り越えた。

そして、結果は同じだ。トップページは復旧した。

新しい能力の地図

これからの時代、能力はこんなふうに分類されるんじゃないか。

従来の分類：
  エンジニア = コードを書ける人
  非エンジニア = コードを書けない人

これからの分類：
  ・コードを書ける人
  ・コードを読んで理解できる人
  ・AIにコードを書かせて適用できる人
  ・AIに頼ることすらできない人

「AIにコードを書かせて適用できる人」というのは、今までなかった分類だと思う。

私はこの3番目に位置する。たぶん、これからの時代の多くの人が、この位置に来る。

そして、3番目の人ができることは、従来の「コードを書けない人」とは比べ物にならない。

チェックリスト──同じトラブルを乗り越えるために

最後に、実用的な情報を残しておく。

functions.php を編集する前にやっておくこと

1. ファイルの内容を必ずバックアップする 私はテキストエディタ（VS CodeやSublime）に編集前のコードをコピペで保存している。GitHub等を使う方が本格的だが、テキストエディタへのコピペでも、ないよりは100倍マシだ。
2. 編集する範囲を最小限にする 一度に大量のコードを書き換えると、エラーが出たときの原因特定が難しくなる。できるだけ小刻みに変更して、都度動作確認する。

エラーが出たときの手順

1. 慌てない サイトが真っ白になっても、復旧の手段はある。深呼吸する。
2. エラーメッセージを正確にコピーする ブラウザに表示されたエラーをそのままコピーする。「Fatal error:から最後まで」を全部コピーするのが安全。
3. AIに状況を伝える
   • エラーメッセージ全文
   • 直前に編集したコード
   • 何をしようとしていたか
   この3点を伝えれば、AIは原因を絞り込んでくれる確率が高い。
4. AIの説明を理解しようとする 一発で理解できなくても大丈夫。何度か読み返す。分からない単語は別途AIに聞く。理解できなくても適用できることもあるが、理解できると次回から自分で対処できる範囲が広がる。
5. 修正後、必ず動作確認する 再びサイトが正常に表示されることを確認してから、別の作業に移る。

AI時代のデバッグ術

ひとつ、知っておきたい原則がある。

「AIに丸投げ」と「AIをパートナーにする」は違う

「エラーが出たから直して」と丸投げするだけだと、AIは表面的な解決策しか出せないことがある。

「エラーが出た。直前にこのコードを書いた。何が原因だと思う？」と、状況を構造化して伝えると、AIは深く考えてくれる。

これは人間同士の対話と同じだ。情報を整理して伝えれば、相手の思考の質が上がる。AIも同じ。

結びに──Knot Works について

Knot Worksは、私（yama_k）が運営する独学者向けメディアだ。中小企業診断士の独学を「迷わず、進める」ためのコンテンツを発信している。

この記事のような技術的なトラブルシューティング記録も、ときどき書いていく予定だ。私自身が「非エンジニアなのに実装する」というスタイルで Knot Works を運営しているので、その過程で遭遇した出来事は、同じような立場の方の参考になるかもしれない。

中小企業診断士の独学に興味がある方は、診断士コーチアプリ（App Store）も覗いてみてほしい。「迷わず進める学習ナビ」をコンセプトに、独学者の判断疲労を減らす設計になっている。

そして、もしあなたも「非エンジニアだけど何か作ってみたい」と思っているなら──大丈夫、今の時代、AIがいる。

エンジニアと非エンジニアの境界は、もう曖昧になっている。