今日やったこと
ブログ「だからなんだ。」で明日以降展開される予定の、複数回に分かれる記事を扱いやすくするため、
WordPressに「シリーズ記事」の仕組みを実装した。
テーマは、
覚えておくのではなく、安心して忘れられる仕組みにする。
1. シリーズ子記事を通常の記事一覧から隠す
シリーズの第1回、第2回……のような子記事については、
トップページやカテゴリー一覧などに単独で大量表示されると、
シリーズ全体の構造が分かりにくくなる。
そこで、子記事にはカスタムフィールド
series_child = 1
を付与。
PHP側で、
- トップページ
- カテゴリー一覧
- タグ一覧
- 日付別一覧
などでは、
series_child が付いている記事を除外するようにした。
一方、シリーズの親記事は通常どおり表示される。
2. シリーズ内の順番を series_order で管理
子記事にはさらに、
series_order = 1
series_order = 2
series_order = 3
……
のように番号を設定。
重要なのは、
シリーズ親記事には series_order を付けない。
という運用にしたこと。
つまり、
親記事
→ シリーズ全体の入口
series_order = 1
→ 第1回
series_order = 2
→ 第2回
という構造。
3. シリーズトップに自動目次を作成
シリーズ親記事の本文に、
というショートコードを置くと、
同じ「シリーズ」に所属する子記事を
series_order 順に自動取得して表示するようにした。
表示例：
第1回：○○
第2回：○○（近日公開）
第3回：○○（近日公開）
公開済みの記事はリンクになる。
予約投稿の記事は、
公開前はリンクなしで
（近日公開）
と表示される。
予約時刻を迎えてWordPress上で公開状態になると、
自動でリンクに切り替わる。
つまり、
「公開日にシリーズトップを編集してリンクを開通する」
という作業が不要になった。
4. 子記事からシリーズトップへ戻れるようにした
次に、
シリーズ子記事を直接読んだ人が
「これは何の記事の一部なのか」
分からなくならないように、
記事末尾へシリーズトップへのリンクを自動追加。
当初は、
←「○○」シリーズトップへ
という単独リンクだった。
ただし、
参考・出典が非常に長い記事では、
本文を読み終わった位置からリンクまでの距離が長すぎる。
そこで、
というショートコードも追加。
必要な記事では、
本文終了直後・出典の前など、
好きな位置にシリーズトップへのリンクを置けるようにした。
記事の最下部にも自動リンクは残るため、
長い出典の前後両方からシリーズへ戻れる。
5. 記事末尾を「シリーズナビ」に拡張
さらに考えてみると、
記事末尾が
シリーズトップへ
だけでは、
次回予告を書いた直後の導線として少し弱い。
そこで記事末尾の自動リンクを、
シリーズ全体のナビゲーションに変更。
第1回なら、
シリーズトップへ ｜ 第2回（近日公開）
第2回が公開済みになれば、
シリーズトップへ ｜ 第2回へ →
中間回なら、
← 第1回へ ｜ シリーズトップへ ｜ 第3回へ →
最終回なら、
← 第1回へ ｜ シリーズトップへ
となる。
前後の記事は series_order を使って自動判定。
ここでも、
予約中の記事はリンクにせず
第N回（近日公開）
と表示する。
6. 結果としてできた構造
シリーズ親記事
- シリーズ全体の説明
- 各回への自動リンク
シリーズ子記事
- series_child = 1
- series_order = N
- 通常一覧からは非表示
- 記事末尾に前後ナビを自動表示
- 必要なら本文途中に
構造としては、
シリーズトップ
↓
第1回
↓
第2回
↓
第3回
と読み進められる一方で、
各記事
↓
シリーズトップ
にも戻れるようになった。
7. WAF犬との戦い
Code SnippetsでPHPを保存しようとすると、
何度か
Request failed with status code 403
が発生。
最初はコードミスを疑ったが、
原因はConoHa WINGのWAF。
Code Snippetsの
wp-json/code-snippet…
への保存リクエストが、
SQLインジェクション
XPathインジェクション
などの可能性として検知されていた。
一時的にWAFをOFFにすると保存成功。
作業後はWAFをONに戻して戸締り確認。
今日の教訓：
403が出たら、まずコードを見るな。犬を見ろ。
8. PHPを「書けなくても読む」話
作業の最後に、
PHPそのものについて少し確認。
たとえば、
‘post_status’ => array( ‘publish’, ‘future’ ),
は、
公開済みの記事
＋
予約中の記事
の両方を対象にする指定。
array は、
複数の値をひとまとめにする箱。
今日のPHPは大きく見ると、
- WordPressから情報を取得する
- 条件を判断する
- HTMLを作る
- WordPressへ返す
という流れになっている。
PHPを書けるようになることより先に、
「このコードは何をWordPressに頼んでいるのか」
くらいは読めるようにしておくと、
AIにコードを書かせる場合でも中身を監査しやすい。
今日の作業全体を通して、
ブログ運営の考え方がかなり明確になった。
覚えておくために仕組みを作るのではない。
忘れても困らないように仕組みを作る。
予約投稿した記事のリンク開通日時を覚えておく必要はない。
シリーズの次回リンクを公開日に手作業で直す必要もない。
必要な情報だけ設定しておけば、
あとはWordPressが処理する。
「だからなんだ。」は、
思考を保存する場所であると同時に、
安心して忘れるための装置にもなりつつある。
私とチャッピーの分業
さて、ここからが本題のAIとの協業の話である。
今回の作業では、
私はPHPを1行も書いていない。
代わりに私がやったのは、
- どんな動作にしたいか決める
- 実際のブログ画面を見ながら違和感を拾う
- 「親記事と子記事の関係」を整理する
- 表示位置や導線を判断する
- 実際にWordPressへコードを入れて動作確認する
- 403などのエラーが出たとき、管理画面やWAFログを確認する
といった部分。
一方、チャッピーには、
- 要件をPHPの処理に落とす
- Code Snippets用のコードを書く
- 修正箇所を具体的に示す
- エラー原因の候補を整理する
- 実装後の挙動を説明する
- series_child / series_order / shortcode の関係を言語化する
といった部分を任せた。
それを、
私：
「こう動いてほしい」
「ここは変じゃない？」
「この位置のほうが自然では？」
チャッピー：
「では、その仕様ならこう実装できます」
という往復で作業した。
最終的な判断は、
実際にブログを見ている私が行い、
コード化はチャッピーが担当する。
言うなれば私の担当は、わがままを言うこと。
ただし、ここでいう「わがまま」は、要件定義に近い。
「こうしたい」「これは嫌だ」「ここは自動にしたい」と言い続ける。
その曖昧な希望を、チャッピーがPHPの条件分岐やWordPressの処理に翻訳していく。
「子記事は一覧から隠したい」
「でもシリーズトップには出したい」
「予約中は近日公開にしたい」
「公開されたら勝手にリンクになってほしい」
「子記事からトップに戻りたい」
「いや、前後記事にも移動したい」
「参考が長い記事は途中にもリンク欲しい」
「でも普段は自動がいい」
非エンジニアの私の本分は、わがままを具体化することだった。
今回の作業で面白かったのは、
私がPHPを書けなくても、
コードの中にある
publish
future
array
series_child
series_order
といった要素を追っていくことで、
「いま何を条件にして、何を探して、何を表示しているか」
くらいは少しずつ読めるようになったこと。
生成AIを使うと、
プログラミングが完全にブラックボックスになるとは限らない。
むしろ、
「自分は仕様を決める」
「AIはコードを書く」
「自分は結果を見て修正する」
という分業を繰り返すことで、
仕組みそのものへの理解は深まることもある。
コメントを残す