この手順を作った理由
この図書館は、内製化の事例を調べる過程で同じ課題に繰り返し当たりました。
LIXIL は AppSheet の全社展開について、進め方も数字も公開したうえで、つまずいた点として**「開発者の異動・退職によるブラックボックス化」**を挙げています。そしてどう解決したかは公開されていません。
内製化を進めるほど、この問題は増えます。 10,000 点のアプリを作った組織は、10,000 点の引き継ぎ候補を持っています。エンジニア業の巻にこの手順を置いているのは、これが最終的にエンジニアのところに来るからです。
以下は、この課題への「解答」ではありません。解答が公開されていない状態で、少なくとも安全に始めるための手順です。
触る前に境界を作る（工程 1・2）
引き取るシステムは動いています。 止めたら業務が止まります。
だから最初にやるのは読むことですが、「読むだけのつもり」が事故になります。 AI に読ませて調べさせると、途中で直しにかかることがあります。
permission ルールで止まるもの
Claude Code の deny ルールは、Read に書いたパスへの Edit（新規作成を含む）も一緒にブロックします。そして緩いモードにしても、deny ルールと明示的な ask ルールはすべてのモードで適用されます。
つまり「調査中は全部 deny」から始めて、必要になったところだけ開けていく形が作れます。
permission ルールで止まらないもの
ここが重要です。 deny が効くのは組み込みのファイルツールと、Claude Code が中身を解釈できる Bash のファイルコマンドだけです。Python や Node のスクリプトがファイルを開く場合には適用されません。
# permission ルールを素通りするpython -c "open('config.yml','w').write('...')"調査対象がスクリプトを実行しうるシステムなら、これは現実的な穴です。OS レベルで止めるには sandbox が要ります（facts/claude-code/sandboxing.md）。
具体的な設定は 秘密ファイルを AI に読ませない・書き換えさせないにあります。引き取り作業では、秘密情報だけでなく「本番の設定ファイル全部」を同じ扱いにしてください。
仕様を書き起こす（工程 3）
コードから「何をしているか」を文章にさせます。**「仕様書」ではなく「現状の記録」**として書かせるのが要点です。
- 仕様書 = こうあるべき
- 現状の記録 = いま実際にこう動いている
引き取り時に要るのは後者です。バグも含めて現状です。「これはバグなので直しました」を調査段階でやらせないでください。 そのバグに依存した運用があるかどうかは、まだ分かりません。
ファイル数が多いときは、大量ファイルを一括処理するの形で 1 ファイルずつ回します。出力の形を固定して表にすると、全体像が先に見えます。
書き起こしたものを検証する（工程 4）
この工程が最も飛ばされ、最も高くつきます。
AI が生成した「このシステムはこう動いています」という文書は、それらしく読めます。 そして間違っていても、読んだだけでは分かりません。引き取る側は正解を知らないので、照合できません。
確度を C にしているのは、この工程の型を出典で示せないからです。この図書館は「生成された仕様の検証方法」について、根拠を持てる資料を見つけられていません。
現時点で書けるのは、次の程度です。
- 入出力で確かめる。 「この処理はこういう場合にこうなる」と書かれていたら、実際にその入力を通して確かめる
- 書かれていないものを疑う。 生成された説明に出てこないファイルやテーブルがあれば、そこは読まれていない
- 数字と条件分岐を優先して見る。 「〜の場合は」「〜を超えると」は間違いが業務に直結する
この工程を人が持つ（human_check）のは、責任の所在の問題でもあります。 引き取った後に壊れたとき、「AI がそう言っていた」は説明になりません。
記録を残す（工程 5）
次に引き取る人が同じ作業を繰り返さないように残します。CLAUDE.md / AGENTS.md / GEMINI.md がその場所になります（会社のルールを守らせる）。
ただし出典が明記しているとおり、
どちらも context であり、強制される設定ではない
「触ってはいけない」と書いても止まりません。 止めたいものは工程 2 の権限側でやります。ここに書くのは、知らないと時間を溶かすことです。
- なぜこの奇妙な処理があるのか（分かった範囲で）
- どこを触ると何が止まるか
- 確かめていないこと
最後の項目を必ず書いてください。 引き取り作業は途中で終わります。どこまで確かめたかが書かれていないと、次の人は「全部確認済み」と誤解します。
この手順が解決していないこと
- ブラックボックス化そのものは防げません。 これは起きた後の手順です。起きる前にやることは 現場の要望をアプリにするの棚卸しと申請制になります
- 生成された仕様の検証方法に根拠が無い（工程 4）。この図書館で最も埋めたい穴のひとつ
- LIXIL がどう解決したかは未公開。 課題として挙げられているだけ
- 吉本興業/FANY の「野良GAS の解消」が未調査。 まさにこの手順の実例に当たるはずで、確度 A の一覧に載っているが深掘りできていない
- 引き取りにかかった工数の実データが無い。 「何人月かかるか」に答えられる公開記録を見つけられていない