結論を先に書くと、移植は「全部入れる」作業ではなく、入れるものを絞る作業です。追従は、原典の控えを版ごとに保存して差分を取る運用で足ります。

原典を探す：総当たりより本文の参照を辿る

配布基盤に一覧はなかった

relmea が使った配布基盤には、定義の一覧を取得するAPIがありませんでした。そのため、名前（キーワード）を総当たりで引いて、中身を取得しました。

件数の推移は次のとおりです。

  • 2026-06-16: 50枚
  • 7月上旬に追加して、66枚から74枚
  • 7月17日に20枚を追加して、94枚

見つかる経路は本文の参照だった

2026-07-28 の全面再棚卸しでは、131個のキーワードを総当たりしましたが、新規は0件でした。新しく見つかったのは、すでに手元にある定義の本文が参照していた別の定義、1枚だけです。

総当たりを重ねるより、既存の定義の本文に書かれた参照を辿るほうが確実でした。

裸のファイル名は定義ではない

定義の本文に「〜.md」のような裸のファイル名が出てくることがあります。これは別の定義ではなく、作業フォルダ上のファイルでした。20個のキーワードで引いても見つかっていません。

結局、そのファイルを参照している3つの定義の本文から仕様を逆算して復元し、新しく設計しました。原典が手に入らないものは、読み取れる範囲から作り直すしかありません。

報告は自分で引き直して裏を取る

サブエージェントに探索させたとき、「取得・内容確認済み」と詳細つきで報告された定義がありました。自分で引き直すと、その定義は存在しませんでした。

それ以来、台帳に書く前に自分で1回引いて裏を取っています。2026-09-19 の棚卸しでは、65枚を全件実測しました。結果は、取得できたものが52、不在が12、権限で読めないものが1です。

移植するかどうかを決める基準

見つかった定義をすべて移植するわけではありません。relmea の記録から、実際の判断を3例挙げます。

7月6日: 8枚の判定

  • 手元にすでに同じ働きのものがある3枚は、移植不要でした
  • 配布元の商用ツールに依存するもの、既存の動画制作の仕組みと重複するものは、移植しませんでした。重複を入れると真実の源が二つになるためです
  • 移植したのは2枚でした

7月17日: 新規16枚などから

新規16枚などのうち、8体を移植しました。あわせて共有知識を2本、コマンドを2本作っています。

配布基盤の専用機能に依存する4枚は見送りました。2枚は、方法論だけを共有知識に抽出しています。丸ごと入れず、使える部分だけ取るという選び方です。

7月29日: 3枚まとめて移植しないと決めた例

理由は3つありました。

  • 成果物の名前まで既存の2つと衝突し、真実の源が3重になる
  • 既存の設計方針が明示的に否定していた手法そのもので、正面から衝突する
  • スライド生成の仕組みが、3系統目になる

移植しない代わりに、固有の価値だけを既存の定義に抽出しました。たとえば、懐疑の所在の判定、時制の誠実さ、実際の支払いの裏取り、証拠と反論を1対1で配線することです。

この判断は固定ではありません。8月25日に改めて判断し、そのうち2段は移植しています。前提が変われば、結論も変わります。

移植するときに書き換える部分

移植は、コピーではありません。原典が前提にしている環境を、自分の環境に合わせて書き換えます。

代表例は、認証情報の扱いです。原典には、APIキーを定義の中に書かせる手順がありました。relmea ではこれを、OSのキーチェーン（鍵の保管庫）から参照する方式へ全面的に書き換えています。

配布基盤のホスティングを前提にした部分は、持ち込みませんでした。

原典の補助スクリプトにも同じ判断を当てはめます。配布先の環境専用のものは移植せず、同じ目的を果たす確認手順に読み替えました。

一方で、書き換えない部分もあります。外部講座のスキル集のうち、組版スクリプトは無改変でコピーしています。手を入れると、次の改訂で差分が取れなくなるためです。

原典の改訂は、控えとの差分で取り込む

版を知る手段は見出し行だけ

relmea が扱った原典には、改訂履歴の節がありませんでした。版を判別できるのは、見出し行にある版の表記だけです。

2026-07-28 の棚卸しで、版が進んでいたのは3件でした。そのうち1件は v2.0 で、モデルごと置き換えられていました。ウェビナー系の16枚は更新が要りませんでした。むしろ、手元のほうが原典より進んでいたものが5枚ありました。

2026-09-19 の棚卸しでは、移植後に出ていた原典の改訂11件を取り込んでいます。

版ごとの控えを残す

外部講座のスキル集7本は、2026-09-20 に7体へ移植しました。このとき、原典の控えを版ごとに日付つきのフォルダで保存しています。v2.1 は 2026-09-18 付け、v2.2 は 2026-10-02 付けです。

講座側が改訂されたら、控えと新しい版で差分を取ります。10月3日に v2.2 の差分を取り込んだときの内容は、漫画のファイル名規則の変更と、表紙の規定の追加などでした。

組版スクリプトと共有知識は、v2.1 から変更がありませんでした。差分を取ったから、「変わっていない部分」も確定できたことになります。差分は、変わった箇所だけでなく、変わっていない範囲も教えてくれます。

原典を無条件に正としない

原典の欠陥は実在する

原典を読み込む中で、次の欠陥が見つかりました。

  • 呼び出し先がすでに統合されていて、存在しない（デッドリンク）
  • 同じ定義の内容が、本文の3か所で食い違っている
  • 見出しは v2.0 のままなのに、本文は v2.2 になっている

見出しの版表記だけが頼りの運用では、最後の例は特に厄介です。見出しを信じて「更新なし」と判断すると、本文の変更を見落とします。

原典で定義が廃止されることもある

手元の共有知識が出所として挙げていた2枚が、原典側で廃止されていました。廃止は 7月31日と 8月16日です。その名前で引くと、「見つからない」が返りました。

対応として、共有知識の冒頭に「出所の現況表」を置き、読み替え先を書いています。出所が消えても、読み手が行き先を探し直さずに済みます。

1段が丸ごと置き換わった例

2026-10-14 には、原典で1段が丸ごと別の定義に置き換わりました。教育区間の定義が、録画で流す自動ウェビナーの本編に変わったものです。

手元でも1体を削除し、新しい1体を作っています。同時に、周辺の3定義に原典の改訂を反映し、参照を付け替えました。

取り込む前には、立場の違うレビュー2体を通しています。その結果、重大な指摘が2件、軽微な指摘が15件ありました。すべて直してから入れています。置き換えを素通しにしなかったのは、周辺の定義まで影響するためです。

移植後の定義の数は、実ファイルで数え直す

最後に、数の管理です。移植を重ねると定義の数が増減します。relmea では、定義の数を書くたびに、実ファイルを ls で数え直しています。

過去の記述からコピーすると、ずれが入ります。実際に、内訳の足し算が2体ぶん合っていなかったことがありました。10月14日の置き換えでは、1体を削除して1体を作ったため、体数は133のままでした。

移植と追従の運用は、次の4点に絞れます。

  • 探すときは、既存の定義の本文にある参照を辿り、見つけた定義は自分で引き直して裏を取る
  • 移植するかは、手元との重複（真実の源が複数にならないか）と、原典の専用機能への依存で決める
  • 移植時は、環境に依存する部分を書き換え、差分を取りたいスクリプトは無改変で持つ
  • 追従は、版ごとの控えを日付つきで残し、差分で取り込む。原典の欠陥と廃止も前提に置く

なお、ここに書いた数字は relmea の実運用で数えた値で、すべての原典に当てはまるとは限りません。自分のチームで試すときは、同じ手順で数え直してください。