この連載「うちのSkill」では、社内で実際に運用しているSkillを紹介しています。今回取り上げる/file-safetyは、AIエージェントに直接ファイル操作を任せる組織であれば業種を問わず必要になる、基盤寄りのSkillです。
「今いる場所」を根拠にしない
SKILL.mdの冒頭に置かれているのは、パスの参照方法です。プロジェクトのルートを基準に相対パスを書くことは珍しくありませんが、この手順書はそこに一文加えています。カレントディレクトリがルートとは限らないという前提です。スクリプトは自分がどこに配置されているかからルートを特定し、明示されたルートと突き合わせて確認する設計になっています。実行時の作業ディレクトリを無条件に信用しないという判断です。
解決した先がルートの外に出ていないかを確認する
操作対象のパスは、シンボリックリンクやジャンクションを経由した先まで解決したうえで、ルート内にとどまっているかを確認します。見た目のパスがルート配下でも、リンクの先が外部を指していれば、操作の影響範囲はルートの外に及びます。親ディレクトリを含む一括削除や移動は、この解決を済ませたあとの対象を確認してから、同じシェルの標準的な操作で行うと定めており、確認前の対象に対していきなり一括処理をかけることを避けています。
移動は一手順ではなく、確認と検証を挟んだ手順にする
ファイルの移動は「参照先と依存プロセスの確認」「退避」「コピーとハッシュ照合」「参照の更新」「検証」「元の整理」という順序で行うと定められています。コピーしたら終わりではなく、ハッシュ値の照合で内容が壊れていないことを確かめてから参照を切り替え、最後に元ファイルを片づける流れです。移動先を用意してすぐ上書きするような操作は、この手順には含まれていません。
同期フォルダは、ロックの代わりにならない
Google Driveのような同期フォルダは分散ロックではないと明記されています。同じ共有ファイルを複数の端末が同時に自動更新すると、後勝ちで上書きが起きる可能性があるためです。この手順書は、共有ファイルの編集担当を一つの端末に固定し、他端末側の自動更新を止めることを求めています。さらに、同一端末の中であっても同じファイルを複数のエージェントに同時編集させず、書き込みの前に読み取り時点から内容が変わっていないかを確認するよう指示しており、ロックの不在を運用の手順でカバーする設計です。
ルールの文章そのものには強制力がないと明記する
SKILL.mdの終盤には、この文章自体が持つ限界についての一文があります。ClaudeはSKILL.mdの内容ではなく実際の設定ファイルとsandboxの状態に従い、CodexはCodex側の設定に従うという説明です。特定のファイルによる保護や、手順書の文章だけでアクセスを強制できるという前提を持たないよう念を押しています。手順を書いた文章と、実際にエージェントの権限を制限する仕組みは別物であるという区別を、規範の中に組み込んでいます。
自分の組織で真似るには
複数のAIエージェントに実際のファイル操作を任せる組織であれば、この規範の要点は3つに整理できます。まず、実行時のカレントディレクトリを信用の根拠にせず、スクリプト自身の配置からルートを特定して照合すること。次に、移動や一括削除のような取り返しのつきにくい操作は、確認と検証を挟んだ複数手順に分解し、一手順で完結させないこと。そして、同期フォルダや共有ファイルには「同時に触れない」という運用ルールを明文化しつつ、そのルールが実際に効くのは手順書の文章ではなくsandboxや権限設定の側であるという区別を、最初から前提にしておくことです。ルールを書くことと、ルールを強制する仕組みを持つことは別の作業だと考えると、規範の設計がぶれにくくなります。