記録を3層に分ける

2026/08/31

いつもご覧いただきありがとうございます。連載の第2回です。

前回は、AIに引き継ぎファイルを書かせている話を書きました。今回は、その記録が増えたあとの話です。

この回が効くのは、品質の再現性とスケジュールの確実性です。

1本では引けなくなったので、3層にした

記録が増えると、今度は別の問題が起きます。どれを読めばよいのか分からなくなるという問題です。

そこで、記録を3つの層に分けました。

層	中身	分量
事務所の共通ルール	全案件に共通する作法。フォルダの決まり、作図の規則、失敗から作ったルール	約5万3千字
案件ごとのルール	その建物に固有の条件。構造種別、採用断面、決着済みの検討	主要案件で約1万2千字
作業ごとの引き継ぎ	直近の作業の続き	1本あたり数千字、38本

読む順番も決めてあります。共通ルール → 案件のルール → 直近の引き継ぎ。上から下へ、抽象から具体へ降りてきます。

もうひとつ、技術資料の索引を別に作りました。設計に使う便覧やソフトのマニュアルは膨大です。「どの資料の何ページに何が載っているか」を1本のファイルにまとめてあり、資料を探す前に必ずこれを読ませます。

分けた理由は単純です。ひとつのファイルに全部書くと、案件が変わったときに関係のない記述まで読ませることになります。読ませる量が増えるほど、AIの注意は散ります。人と同じです。

記録は、放っておくと追記だけが積み上がります。追記だけを続けると、どれが最新で正しいのか判定できなくなります。

そこで当社では、節目に統合するという工程を入れました。

ある案件では、1週間ぶんの引き継ぎ9本が溜まっていました。これを1本のファイルに統合しました。統合後のファイルの冒頭には、こう書かせてあります。

このファイル1本でこの案件の作業を再開できるようにまとめたもの。

元の引き継ぎ9本は経緯の元資料として残してある。通常は読む必要がない。

本ファイルと食い違う場合は、本ファイルが正（実ファイルで検算済み）。

3行目が肝心です。どちらが正かを明記しないと、統合したこと自体が新しい混乱の種になります。そして「実ファイルで検算済み」と書けるように、統合の際には記述と実際のデータを突き合わせています。

前回の連載の第5回で、「知識を貯める仕組みは動いているが、捨てる・直す仕組みが無い」という指摘をAI自身から受けた話を書きました。統合はその答えのひとつです。

この運用が本当に機能するのかを、意図せず試すことになりました。

8月に、新しいノートパソコンを実戦投入することにしました。海外出張に持ち出すためです。日程が決まっていたので、期限までに使える状態にする必要がありました。

このとき、何を再現すればよいかを、引き継ぎファイルから逆算しました。

同期すべきフォルダはどれか。必要な設計ソフトは何か。どのファイルが必ず要るか。ソフトの設定はどうなっているか。それらは全部、過去の引き継ぎと共通ルールに書いてありました。書いてあったので、抜けを探す作業が要りませんでした。

AIが自分で書いた記録を読んで、自分が動く環境を別の機械に再現した、ということになります。

さらに、上で書いた「1本に統合した引き継ぎ」の冒頭には、こう書いてあります。

別のPCに移っても、これとファイル同期があれば立ち上がる。

書いたとおりになりました。

ここまで読んで、「AI特有の話だ」と思われたかもしれません。実際には逆です。

担当者が変わっても、時間が空いても、同じ品質で再開できる。設計事務所が昔から課題にしてきた属人化の解消と、まったく同じことをやっています。

違うのは密度です。人のチームでは、引き継ぎは担当が代わるときに書きます。当社では、作業を区切るたびに書きます。頻度が二桁違います。

その頻度でやると、記録の質が保てないのではないか、と思われるかもしれません。逆でした。書く相手が「昨日を覚えていない優秀な人」だと分かっていると、書き方が具体的になります。曖昧に書けば、翌日そのぶん自分が困ります。

設計期間が1年を超える案件は珍しくありません。その間、担当者の記憶と手帳だけで一貫性を保つのは無理があります。仕組みで持つほうが確実です。

項目	内容
品質の再現性	読む順番が決まっているので、案件が変わっても前提が揺れません
スケジュールの確実性	作業の再開に時間がかかりません。長期の案件、中断のある案件ほど効きます