📖この記事は約12分で読めます
1. 実験の衝撃：ルール違反が50タスクで17件に激減
前編ではLLMが会話中はルールを忘れやすいことを確認しました。しかし、ファイル操作を伴うコーディングタスクでは劇的な違いが現れました。筆者のチームが50回の連続検証を実施した結果、初期違反136件が50タスク後には17件にまで減少。これは単なる偶然ではなく、LLMが「既存コードのスタイルを模倣する」ことでルール遵守が維持されていることを示唆しています。
具体的には、Pythonの`ast`モジュールでAST（抽象構文木）を解析し、コード違反を検出する実験が行われました。条件A（ルール提示+非準拠）では違反数が急減した一方、条件C（ルールなし+非準拠）では違反が685件に増加。この差はLLMが「ファイルに残るコードのスタイルを学習」するかどうかにかかっていました。
筆者は「ルールはプロンプトではなく、ファイルに置け」と主張します。これはLLMにとってRAM（コンテキストウィンドウ）の揮発性と、HDD/SSD（ファイルシステム）の持続性の違いを意識した設計思想です。特にR8（ダブルクォート強制）のようなルールでは、条件Cでは違反が全体の63%を占めるなど、LLMのデフォルト行動との乖離が顕著に現れました。
この実験の意義は、LLMの指示遵守を「意識的な従順」ではなく「学習データの再現」に転換する点にあります。ファイルに残るコードがLLMのFew-shot効果を活用し、ルールを「お手本」として埋め込むことで、持続的な遵守が可能になるのです。
2. LLMのルール遵守メカニズム：模倣の力
LLMがルールを守る最大の要因は、ファイルに残るコードのスタイルを「模倣」することです。筆者のチームが示したデータでは、条件Aでは初期の違反136件がタスク1、18、20で急減。これはLLMが初期の違反を修正したコードを「お手本」として学習し、後続のタスクで再現する「Few-shot効果」が働いたためです。
一方で、条件Cではルール提示がないため、LLMは学習データの平均（Pythonの慣習）に回帰します。結果としてR8違反が344件増加し、LLMのデフォルト行動がルール設計と矛盾する場合のリスクが浮き彫りになりました。この現象は「天井効果」の一形態でもあり、初期違反が少ない場合、改善余地が限られてしまう問題があります。
筆者は「LLMのルール遵守は、プロンプトの言葉ではなく、ファイルに残るコードの物理的制約に依存する」と指摘しています。これはLLMが「言語モデル」であることに反するように思えますが、実際には「コード生成」は文脈と形式の組み合わせであり、LLMが形式を模倣することでルールを遵守しているのです。
このメカニズムを活かすには、ファイルシステムに「ルールの種」を埋め込む必要があります。例えば、プロジェクトのルートディレクトリにスタイルガイドを配置し、LLMがそれを読み込むことで、ルールを「物理的に強制」する設計が有効です。
3. 実験結果の深掘り：なぜルールが維持されるのか
50タスクの検証で最も注目すべきは、LLMが「ルール違反を修正したコードをファイルに残すことで、後続のタスクで再利用する」点です。これはコンピュータサイエンスにおける「持続化（Persistence）」の原理に合致し、LLMが揮発性のRAM（コンテキストウィンドウ）に依存するのではなく、永続的なファイルシステムにルールを固定することで、ルール遵守を長期化していることが明らかです。
具体的には、タスク1で違反したコードを修正し、その修正版をファイルに保存すると、タスク2以降でLLMはその修正版を「お手本」として参照します。このプロセスは人間の学習に似ており、一度学んだルールを「忘れない」ことで、持続的な遵守が可能になります。
ただし、このメカニズムには限界もあります。筆者のチームは「実験はClaude Opus 4.5のみに限定されている」と明記しており、他のLLM（Llama3やQwen3など）への一般化は未確認です。また、条件B/D（準拠プロジェクト）では天井効果の影響が排除できないため、すべてのプロジェクトに適用できるとは限りません。
この結果は、LLMの指示遵守を「言語的理解」ではなく「形式の模倣」として設計するべきだというメッセージでもあります。特にコード生成のような形式の強いタスクでは、LLMが「言葉で理解する」より「形式で再現する」ことで、より安定した結果を得られる可能性があります。
4. 実践応用：ファイルシステムを活用したルール設計
筆者の実験結果を活かすには、まずプロジェクトのルールを「ファイルに固定化」する必要があります。例えば、`.prettierrc`や`.eslintrc`などの設定ファイルにスタイルガイドを記載し、LLMがそれを自動的に読み込むことで、ルールを「物理的に強制」できます。
また、GitHubにスクリプトや測定コードを公開することで、再現性を高めることができます。これはLLMの指示遵守を検証するだけでなく、他の開発者も同じ条件でテストできるため、信頼性の高い設計が可能になります。
さらに、ファイルに残るコードの「お手本効果」を強化するには、プロジェクトの初期段階で「ルールの種」を埋め込むことが重要です。例えば、初期のコードテンプレートにスタイルガイドを組み込み、LLMがそれを基にコード生成を行うことで、ルールを意識的に遵守する習慣を育てることができます。
ただし、このアプローチはLLMの学習データに依存するため、プロジェクトのルールが学習データと矛盾する場合、LLMのデフォルト行動が干渉する可能性があります。そのため、プロジェクトごとにカスタムのルールセットを用意し、LLMがそれを優先的に参照するように設計する必要があります。
5. 将来展望：LLMとファイルシステムの融合
筆者の実験は、LLMが「ファイルシステムと連携することで、ルール遵守を長期化できる」ことを示しています。これは今後のLLM開発において、ファイル操作を伴うタスク（コード生成、ドキュメント作成、データ処理など）における設計指針を変える可能性があります。
特に、ローカルLLM（llama.cppやOllamaなど）の普及により、ファイルシステムへのアクセスが容易になった今、LLMが「ローカルのコードベースと連携してルールを遵守する」設計が注目されます。例えば、ローカルの`.gitignore`ファイルをLLMが参照し、不要なファイルを除外する処理を自動化するなど、ファイルベースのルール適用が可能になります。
ただし、このアプローチには「LLMの学習データとプロジェクトのルールが一致しない場合の対処」が課題です。今後の研究では、LLMが「プロジェクト固有のルールを優先的に学習する」仕組みを構築し、デフォルト行動と矛盾しないように設計する必要があります。
最終的に、LLMは「言語モデル」から「形式モデル」へと進化し、ファイルシステムと連携することで、持続的なルール遵守を実現する存在になるかもしれません。この実験はその第一歩であり、今後の技術革新に期待が寄せられています。
実際の活用シーン
このファイルベースのルール設計は、さまざまな実務場面で応用可能です。例えば、ソフトウェア開発チームがLLMを活用してコード生成を行う際、`.prettierrc`や`.eslintrc`などの設定ファイルにプロジェクト固有のスタイルガイドを記載することで、LLMが自動的にルールに従ったコードを生成します。これにより、開発者がコードの整形やバグ修正に時間を割く必要がなくなり、生産性が向上します。
また、ドキュメント作成にも応用可能です。LLMがプロジェクトのREADME.mdやAPIドキュメントを生成する際、`_template.md`のようなテンプレートファイルを参照することで、プロジェクトの命名規約やフォーマットを維持できます。これは特に複数の開発者が協業するプロジェクトで有効で、一貫性のあるドキュメント作成を実現します。
さらに、データ処理の自動化にも活用できます。LLMがCSVやJSONデータを処理する際、`schema.yaml`などのスキーマファイルを参照することで、データの形式や型のチェックを自動化します。これにより、データの信頼性を確保しながら、手間を省けるようになります。
他の選択肢との比較
このアプローチは、従来の「プロンプトエンジニアリング」や「静的解析ツール」などと比較していくつかの利点があります。まず、プロンプトにルールを明記する方法では、LLMがタスクごとにルールを忘れてしまう問題がありました。一方、ファイルにルールを固定することで、LLMが一貫して遵守できるため、持続性が高まります。
また、静的解析ツール（ESLintやPrettierなど）はコードの違反を検出するためのツールですが、LLMがコード生成段階でルールを守るという点では限界があります。このファイルベースの設計はLLM自体にルールを「内包」させることで、コード生成と違反検出を同時に行えます。
さらに、このアプローチはLLMの「Few-shot Learning」を活用しているため、従来の「One-shot」や「Zero-shot」の設計より、精度が高まります。これは特に複雑なルールやプロジェクト固有のスタイルガイドがある場合に有効です。
導入時の注意点とベストプラクティス
このアプローチを導入する際には、いくつかの注意点があります。まず、プロジェクトのルールがLLMの学習データと矛盾する場合、LLMがデフォルト行動に回帰する可能性があります。これを防ぐためには、プロジェクトの初期段階でルールを明確化し、LLMがそれを優先的に参照するよう設計することが重要です。
また、ルールの更新や変更が必要な場合、ファイルに記載されたルールも同時に更新する必要があります。これにより、LLMが古いルールに従ってコードを生成してしまうリスクを防げます。この点を考慮し、ルールファイルのバージョン管理を徹底する必要があります。
さらに、このアプローチはLLMの「持続化（Persistence）」に依存するため、ファイルシステムの信頼性が重要です。特に、分散開発環境では、ルールファイルの同期が欠かせません。Gitなどのバージョン管理システムを活用し、チーム全体でルールファイルを共有・更新することで、一貫性を保つことができます。
今後の展望と発展の可能性
このファイルベースのルール設計は、今後のLLM開発において重要な方向性として注目されています。特に、ローカルLLMの普及により、ファイルシステムへのアクセスが容易になることで、LLMが「ローカルのコードベースと連携してルールを遵守する」設計が広まりそうです。これにより、クラウドベースのLLMに依存せず、プライバシーやセキュリティを確保しながらルール遵守を実現できます。
また、今後の研究では、LLMが「プロジェクト固有のルールを優先的に学習する」仕組みの構築が進むと予測されます。これにより、LLMが学習データの平均に依存せず、プロジェクトの要件に合わせたルールを遵守できるようになります。さらに、LLMが「ファイルベースのルール」を活用して、CI/CDパイプラインに統合される可能性もあります。
最終的に、LLMは「言語モデル」から「形式モデル」へと進化し、ファイルシステムと連携することで、持続的なルール遵守を実現する存在になるかもしれません。この実験はその第一歩であり、今後の技術革新に期待が寄せられています。
📦 この記事で紹介した商品
※ 上記リンクはAmazonアソシエイトリンクです。購入いただくと当サイトに紹介料が入ります。
コメント