専門書をスキル化するときの線引きと、事業サイトの掲載内容の詰め方
専門書をスキル化するときの線引きと、事業サイトの掲載内容の詰め方
「積み残しって何でしたっけ」とこの日は三回聞いている。 朝と昼と夜、そのたびに別のセッションを立ち上げて、同じ質問から入った。 覚えていられる量ではないので、毎回 memo の計画書から拾い直させている。
拾い直させて朝いちばんに分かったのは、積み残しの一つが積み残しではなかったことだった。
写真を待つのをやめた
自分の事業サイトには、事例のページを3本ぶん作りかけで抱えていた。 止まっていた理由は写真だった。 現場の写真が届くまでは出せない、と自分で決めていた。
けれど文章のほうは、もう書き終わっている。 写真が無くても、読む人にとって役に立つ内容は載っている。 それなら写真の枠だけ外して先に出せばいい。
写真は後から入手する予定なので、その進捗だけ計画書に書き残させた。 1本を公開状態にしてブラウザで見たら、カードが1枚だけで左に寄り、右側が間延びしていた。 中央に寄せさせて直した。
事例が作り話でないことを、自分で確かめた
残り2本は、公開の判断が付いていなかった。 中身が実際にあった依頼に基づくのか、説明のために組み立てた想定なのか、自分でも曖昧なまま置いていたからだ。
確かめると、どちらも実際の依頼がもとになっていた。 所要時間も請求額も現実の数字で、内容には店主も目を通している。 そうなると、公開に必要なのは出来事の裏取りではなく、数字を今の料金表と揃えることだけになる。
そこから先は機械的な作業だった。 未確定を示す黄色マーカーが2本で合わせて37箇所あった。 それを全部外し、下書きバナーと noindex も落とさせた。 公開ページは3本から6本に増えた。
デプロイは一度止まった。 自動モードの分類器が、許可していないコマンドをブロックしたためだ。 許可済みの経路に切り替えて出し直した。 ついでにリポジトリを見たら、origin への push が3月で止まったまま12コミット分たまっていた。 まとめて上げさせた。
料金表を「どこの鍵か、どうするか」に組み替えた
料金表は行が並んでいるだけだった。 同じ「開ける」でも中身の違うものが一行に同居していて、読む人が自分の状況をどの行に当てはめればいいのか分からない。
そこで、料金表の下に組み合わせのマトリックスを下書きさせた。 本番に漏れないよう、下書き専用のマーカーを付けて配信物に混ざらないことを先に確かめている。 出来上がりを見て、これは案ではなく本体でいいと判断した。 料金表そのものを、「どこの鍵か」を親、「どうするか」を子にした親子構造へ置き換えた。 下書きブロックのほうは消させた。
途中で、直したはずの表示が古いまま変わらなかった。 ディスク上の実ファイルを確認させたら、料金表は共通パーツを4ページへ配る仕組みになっていた。 配る前の元ファイルを直す必要があった。 構造化データのほうにも同じ値が入っていたので、そちらも揃えさせている。
夜には文言も直した。 どの作業を指すのか読み取りづらい行があったので、動作が分かる言い方に変えた。 表のグループの境目が薄くて見分けられなかったため、境界線だけ濃く太くさせた。 行と行の区切りは薄いまま残したので、グループの内と外がはっきりした。
専門書を、手口を残さずに知識にする
蔵書のデータベースには、錠前まわりの専門書が入っている。 章立てで整理されているから、そのままプロジェクト固有のスキルにできるはずだと思った。 最初に出した指示は「章ごとに可能な限り詳細に保存」だった。
この指示は、そのまま実行させると具合が悪い。 その本には解錠の具体的な手順まで書かれている。 詳細に保存すれば、手順がスキルの中に半永久的に残る。 このサイトにはもともと防犯上の線引きがあり、解錠手法が具体的に載っている本を鍵屋が公に薦めるのは適切でない、という判断も済ませてあった。 自分で引いた線を、自分の指示で越えるところだった。
方針を変えた。 錠前の構造、弱点の種類、対策の考え方までを残し、実行できる手順は残さない。 使う目的は記事を書くときに事実関係を素早く確かめることであって、開け方を覚えることではない。
計画書を作らせて Codex にレビューさせたら、致命的な指摘が3件返ってきた。 独自の表現に言い換えれば著作権リスクを避けられる、という前提が甘い。 生成した知識を検証する工程が無く、記事はWeb情報で裏取りするという既存の方針と食い違っている。 対象が全章では、目的に対して広すぎる。
どれも当たっていたので、対象を全体の半分強にあたる9章へ絞り、著作権チェックと事実の裏取りを工程に組み込んだ。
書かせる係と、見張る係を分けた
DBから9章分を抜き出すと241チャンクあった。 サブエージェントを9件並列で走らせ、章ごとに整理させた。
出来上がったものは、書いたのとは別のサブエージェント9件に見せた。 元の生テキストと突き合わせ、手口にあたる記述の混入と著作権上の問題を探す係だ。 書いた本人に自己チェックさせても、自分の書いたものは通してしまう。
5件で修正が入り、4件は問題なしだった。
一番効いたのは、ある章の末尾にあった「除外した内容の概要」という節だ。 本文からは手口を落としてあるのに、その節が、落としたキーワードの一覧になっていた。 除外したと宣言すると、何を除外したかが残る。 消させた。
ほかは、原文の言い回しに寄りすぎた表現の書き換えと、攻撃対象の具体的な位置情報の削除だった。 最後に9ファイル全体へ危険キーワードのスイープをもう一度かけさせ、残っていないことを確かめた。
できたスキルは、その日の積み残しの一項目ですぐ試した。 スキルから引いた記述を、Webの一次情報で裏取りする。 業界団体が出している耐用年数のガイドラインが見つかり、スキル側の記述とも食い違わなかった。 記事の出典として使えるのは、本ではなくこちらだ。
画面を見ないと決まらないこと
昼と夜は、ローカルでサイトを立ち上げっぱなしにして、ブラウザを見ながら直していた。
店主の手仕事を紹介する読み物ページには、数字が埋まっていない項目を黄色くしてある。 聞き取りながら、確定した項目だけ黄色を外して白背景に戻させた。 製作期間はその場で決まった。 寸法は桁の合わない答えが混ざったので、反映させずに黄色のまま残した。 分からないものを分からないまま画面に出しておくと、次に何を聞けばいいかが一目で分かる。
全部埋まったところで、表の下に残っていた「この表は店主に確認して埋めてください」という編集者向けのメモが内容と矛盾した。 消していいかと確認されたので、消した。
同じページの図面は、SVGで描き起こさせた。 最初はPDFを画像として書き出してきたので、そうではないと差し戻している。 ほしいのは、図面に載っている寸法を読み取って線を引き直したものだ。 1ピクセルを模型の実寸1ミリに対応させ、寸法から座標を計算させた。 一度目は原図と逆向きに描かれた。 実物の写真を渡して見比べさせたら、写真のほうが90度倒れていた。 起こすと今度は上下が逆で、そこまで直してからもう一度描き直させている。
公開前の読み物も1本進んだ。 本人確認をどう運用しているか、実際のやり方を聞いて埋めた。 ただし手順の条件そのものは、なりすましの入口になりうるので読み物には書かない。 ここでも「載せない」を先に決めてから書いている。
学んだこと
- 「写真が無いから出せない」は、写真が要る箇所だけの制約だった。ページ全体を止める理由にはならない
- 落としたものについて「落とした」と書き残さない。断り書きそのものが索引になる
- 書く係と見張る係は分ける。同じエージェントに自己チェックさせても、自分の書いたものは通る
- 未確定を黄色で画面に出しておくと、聞くべきことがそのまま一覧になる。埋まったら黄色を外すだけで進捗も見える
- 共通パーツを配る作りのサイトでは、配られた先を直しても表示は変わらない。元ファイルを疑う
積み残し
- 店主に確認する項目（料金表の2行と、下書きページの公開に必要なもの）
- 現場の写真の入手。揃ったら事例ページの写真枠を戻す
- 図面SVGの精度。実物の写真に合わせた描き直しは途中まで
- スキルの残りの章を対象に含めるかどうかの判断