内部リンクを後から整えたら、記事同士がつながった

内部リンクを後から整え、記事同士をつないだ関係図 AI社員で記事を回す実践記録

前の記事「投稿後にDB登録したら、記事が資産として残り始めた」では、公開した記事を`articles.db`へ登録した。

DBに記録し、目次へ載せ、`series_s2.md`も更新した。
それで公開後の管理は進んだ。

でも、投稿ID101の記事には、まだ別の作業が残っていた。

内部リンクだ。

記事は公開されている。
一覧にも載っている。
それでも本文の中では、関連記事への道がまだつながっていなかった。

内部リンクは、公開時に無理に完成させなかった。
公開後に本文を読み直し、関係があると確かめられた場所だけへ施工した。


公開しただけでは、記事はまだ一つずつ離れていた

公開された記事には、それぞれURLがある。

目次から開くこともできる。
シリーズの何本目かも分かる。

ただ、本文を読んでいる途中で、前に書いた記事へ移る道はなかった。

以前の記事「目次と内部リンクで、ブログを記事の集まりからサイトに変える」は、目次と内部リンクの設計について書いた記事だった。
その記事自体が公開されたあとも、本文内のリンクは未施工のまま残っていた。

記事は存在している。
けれど、本文同士の関係はまだ確定していなかった。

公開済みであることと、記事同士がつながっていることは別だった。


目次と内部リンクの記事では、内部リンクだけが公開後に残っていた

その記事のWordPress投稿IDは101だった。

公開後、`articles.db`への登録が終わった。
目次にも反映した。
`series_s1.md`も公開済みに変えた。

それでも、内部リンクだけは別工程として残っていた。

今回は、リンク先になる記事が本文の中でどんな役割を持つかを、公開後に本文を読み直して確かめた。

どこへでもつなげればいいわけではない。
記事名が出ているだけでも足りない。

読者がその文脈から次の記事へ移っても、話が続く場所だけを選んだ。

だから、DBや目次と同じタイミングでは施工しなかった。


本文へ3本、公開を人間に残す記事の末尾へ1本を後から施工した

2026年7月4日20時25分、目次と内部リンクの記事の本文へ3本の内部リンクを施工した。

リンク先は、「AIにブログを公開させない。post_draft.pyで下書き保存まで仕組みにした話」、「articles.dbで記事を管理する。ブログを感覚ではなく台帳で見る」、「記事を書く前に設計書を作る。AIにいきなり本文を書かせない理由」だった。

同時に、公開を人間に残す記事の末尾に残っていた`href=”#”`を、目次と内部リンクの記事の公開URLへ変更した。

目次と内部リンクの記事から、過去の記事へ戻る道を作った。
公開を人間に残す記事から、次の目次と内部リンクの記事へ進む仮リンクも、実際のURLへつなぎ直した。

施工後は、リンク先がHTTP 200を返すことを確認した。

変えたのはリンクだけだった。
リンク以外の段落は変更していない。

記事を書き直したのではない。
公開済みの本文に残っていた関係だけを確定した。


リンク先は本文の役割から先に決めた

目次と内部リンクの記事から、公開を人間に残す記事へつないだのは、その流れが直前の工程だったからだ。

articles.dbの記事は、記事を管理する土台だった。

設計書の記事は、本文を書く前に設計書を作る考え方の出発点だった。

3本とも、関連記事だから並べたのではない。

目次と内部リンクの記事の本文の中で、公開までの流れ、記事管理の土台、設計の出発点として役割があった。

その役割が書かれている文脈にだけリンクを置いた。

リンク先を増やすためではなかった。
本文にすでにあった関係を、読者が移れる形にしただけだった。


目次と内部リンクの記事と実装エージェントの記事は、あとから双方向につながった

目次と内部リンクの記事を公開した時点では、「実装エージェントを作った。AIに全部やらせず、担当を分ける」はまだ次の記事だった。

最初から、両方のリンクを一度に完成させることはできなかった。

実装エージェントの記事の公開後、まずその記事から目次と内部リンクの記事へのリンクを施工した。

そのあと、2026年7月9日に、目次と内部リンクの記事から実装エージェントの記事へのリンクも追加した。

これで、目次と内部リンクの記事と実装エージェントの記事は双方向につながった。

目次と内部リンクの記事は、誰が内部リンクを決め、誰が施工するかを書いた記事だ。
実装エージェントの記事は、その施工を担当する記事だった。

次の記事が公開されたあとに、二つの記事の関係が確定した。

内部リンクは、最初から全部を決め切るものではなかった。
公開後に記事が増えたからこそ、あとからつなげられる関係があった。


内部リンクは、記事同士の関係を残す工程だった

今回増やしたリンクの数は多くない。

目次と内部リンクの記事本文へ3本。
公開を人間に残す記事の末尾にあった仮リンクを1本差し替えた。
その後、目次と内部リンクの記事と実装エージェントの記事を双方向につないだ。

大事だったのは、本数ではなかった。

DBに記事を記録する。
目次とseriesへ反映する。
そのあとで本文を読み直し、記事同士の関係をリンクとして残す。

公開された記事は、一つずつ置かれたままでは終わらなかった。

次の記事が公開されるたびに、すでにある記事との関係を確かめられる。
自然につながる場所だけを、あとから施工できる。

内部リンクを後から整えたことで、独立していた記事同士のあいだを、読者が移れるようになった。

次は、1本の記事をカルテ1枚で最後まで回して、どこまで記録が残ったのかを振り返る。

コメント