ALP（アクティブローディングポリシー）：AIコンテキストグラフ管理におけるシンプルなパターン

Claude CodeのようなAIアシスタントと作業する際、最初の「蜜月期間」を過ぎると、ある根本的なジレンマが浮き彫りになります。AIには、あなたの好み、コードベースの慣習、製品知識、思考様式といった、必要なあらゆるコンテキストを持たせたいと誰もが望むでしょう。しかし、あらゆる情報を事前に与えすぎると、トークンコストが高騰し、応答が遅くなるだけでなく、逆説的に、過剰なコンテキストはAIの精度を高めるどころか、かえって低下させてしまうことが少なくありません。本質的な「シグナル」が「ノイズ」の中に埋もれてしまうのです。

ArcBlockでは、この問題に長らく苦慮していましたが、一度立ち止まって解決策を考案した結果、ALP（Active Loading Policy）と呼ぶパターンが生まれました。これは、製品でもフレームワークでも、販売目的のものでもありません。単なるエンジニアリングパターンであり、AIアシスタントがコンテキストを一度にすべてではなく、必要な時に読み込むための構造化手法です。その核心となる考え方はシンプルです。何をいつ読み込むべきかを明確にルール化し、そのルールをClaudeが参照するファイルに記述する。そして、会話の進行に合わせてClaudeがそのルールに従うようにするだけです。わずか一午後の設計作業で、これ以来、継続的に大きな成果をもたらしています。

この話が特筆に値するのは、そのソリューションが巧妙だからではない。むしろ、意図的に巧妙さを排したそのパターンこそが、私たちが様々な文脈で繰り返し発見する「制約が効率を促す」という原則を具現化している点にあるのだ。何がいつロードされるかを明示的に宣言することで、私たちはこれまで混沌としていた事柄に対する制御を手に入れた。そして、この制御は知識ベースの成長とともに、時間と共にその効果を増幅させていく。

私たちが解決を目指していた課題

ALP導入以前、Claude Codeの活用において、弊社はいくつかの摩擦点を経験していました。これらは個々には軽微に思えるものの、全体としては業務の大きな足かせとなっていたのです。数ヶ月にわたる作業を通じて、弊社は膨大な量の知識ファイルを蓄積してきました。具体的には、12種類もの製品に関するドキュメント、ファイルシステム抽象化からIDレイヤーに至るまで多岐にわたる技術アーキテクチャメモ、エンジニアリングに関する洞察や決定記録、さらにはコーディングスタイルやコミュニケーションパターンに関する個別の指針などが含まれます。これら全ての情報をClaudeに提供し活用できるようにすることが当然の選択肢でしたが、「利用可能にする」という点では、その具体的な方法について即座に疑問が持ち上がったのです。

安易な解決策として、各セッション開始時にあらゆる情報をコンテキストに詰め込む方法がありました。これは小規模なナレッジベースには有効でしたが、規模が拡大すると性能が著しく低下しました。トークン使用量が増加し、応答速度は目に見えて遅くなり、さらに我々は直感に反する現象を観測しました。Claudeの出力が、以前よりも焦点が定まらなくなったのです。AIアシスタントに12の製品に関するコンテキストを与え、それが1つの製品についてあなたをサポートしようとする場合、時には過剰に親切になろうとし、無関係な関連付けを行ったり、ユーザーが関心のない可能性まで考慮に入れて回答を曖昧にしたりすることがあります。つまり、コンテキストが増えれば増えるほど、シグナルではなくノイズを多く生み出していたのです。

しかし、より根本的な問題は、効率性だけでなく、体系的な記憶システムが全く欠如していた点にありました。セッションごとに、まるで記憶喪失の人物と対面しているかのような感覚に陥ったのです。私たちは、AIに読み込むべきファイルを繰り返し説明し、作業の現状を再確認させ、本来保持されているべき文脈をその都度、再提示し続ける必要がありました。私個人の知識と、チーム全体で共有すべき知識との間には、明確な区別が存在しませんでした。さらに、AIがどの知識がどのような状況に即しているかを学習する仕組みも不在でした。私たちが真に求めていたのは、コンテキストグラフのようなものでした。それは、構造化され、永続性があり、クエリ可能で、いつ何が読み込まれるかに関する明確なルールを持つ知識システムです。業界ではこの問題が議論され始めていますが、私たちは将来のプラットフォームではなく、現在のツールで機能するソリューションを必要としていたのです。

この摩擦コストは、単なる時間消費にとどまらず、認知的な負荷としても現れていました。セッションごとに、Claudeを私たちの作業コンテキストに再設定するための「心の準備」が求められました。この準備が、本来の作業への集中力を奪っていたのです。加えて、そのプロセスが場当たり的であったため、一貫性に欠けていました。時には、重要なファイルをClaudeに認識させるのを忘れたり、また時には過剰な情報を読み込ませてコンテキストを不明瞭にしてしまうこともありました。より良い解決策が、きっとあるはずだと感じずにはいられませんでした。

なぜルールテーブルなのか

解決策の設計に着手した際、私たちはそれぞれ異なるトレードオフを伴ういくつかのアプローチを検討しました。最初の選択肢は、会話の内容からClaudeが読み込むべきコンテキストを自動で推論させるというものでした。このアプローチには明白な魅力がありました。手動による設定が一切不要で、AIが賢く振る舞うという点です。しかし、それには明白なリスクも伴います。Claudeが関連性の高い情報を誤って判断する可能性があり、その場合、なぜそのような判断に至ったのかを把握する術がありません。監査証跡は存在せず、その挙動を調整する手段もなく、透明性は皆無でした。AIが自身のコンテキストについて意思決定を行うことは、まさに私たちが確立しようとしていた制御自体を放棄するに等しいと感じられました。

より高度な選択肢として、埋め込みベースの検索システムを構築することも考えられました。このシステムでは、全てのドキュメントをベクトル化し、Claudeがその内容を意味に基づいてクエリできるようになります。このアプローチには確かに利点があり、おそらく業界が目指す方向性でしょう。しかし、差し迫った我々のニーズには、少々やりすぎだと感じられました。この方法では、埋め込みモデルやベクトルデータベースへの依存が生じ、インフラの複雑性が増し、さらに継続的なメンテナンスが必要となります。私たちが求めていたのは、半日ほどでセットアップでき、テキストエディタで簡単に修正できるものでした。既存のClaude Codeパラダイム内で機能し、そのために新たなツールを構築する必要がないものを求めていたのです。

ルールテーブル方式が採用された決め手は、そのシンプルさと透明性という2つの特性にありました。具体的には、claude.mdファイル内にMarkdown形式のテーブルが設けられ、トリガー条件とファイルパスを紐付けています。Claudeが「AFS」や「ファイルシステムアーキテクチャ」に関する会話を読み取ると、このテーブルを参照し、合致するルールに基づいてtechnical/afs.mdを読み込む仕組みです。ブログ記事の執筆時には、私たちの執筆スタイルの設定が読み込まれ、アーキテクチャレビューの際には、私たちのエンジニアリングに関する知見が反映されます。ルールは明確に記述されており、何が起こるかを正確に把握できます。Markdownファイルの一行を編集するだけで動作を変更できるため、柔軟性も高いです。人間が理解しやすい形式であるため、新しいチームメンバーでもテーブルを見れば、コンテキストの読み込みがどのように機能するかを即座に把握できます。魔法のような要素やブラックボックスはなく、不透明な判断を下す機械学習モデルも介在しません。

私たちが採用したフォーマットは、意図的に簡素化されています。トリガー条件とファイルパスという2つの列を持つシンプルなテーブルです。トリガー条件は自然言語で記述され、Claudeがこれを解釈することで、複雑なパターンマッチングを必要とせず、高い柔軟性を実現します。ファイルパスは、所定のルートからの相対パスです。これだけです。具体的な例を以下に示します。

## Active Loading Policy (ALP)

| Trigger | Load File |
|---------|-----------|
| Discussing ArcSphere product | `products/arcsphere.md` |
| Discussing AFS architecture | `technical/afs.md` |
| Writing blog posts or articles | `content-profile/writing-style.md` |
| Making architecture decisions | `profile/engineering-insights.md` |
| Discussing DID or identity | `technical/did-capability.md` |

そのシンプルさは、欠点ではなく特長です。トリガーのブール論理結合、優先順位付け、時間条件といった、より表現力の高い設計も検討できました。しかし、表現力を高めるほど、認知的負担が増大します。現行のシンプルなバージョンで、我々のケースの90%を賄うことができます。残りの10%についても、Claudeに何をロードすべきか、いつでも明示的に指示することが可能です。ルール言語を時期尚早に最適化することは、まさに我々が回避したかった過剰な設計、そのものだったでしょう。

READMEファイルの役割

ルールテーブルはClaudeに対し、いつファイルを読み込むべきかを指示しますが、詳細なドキュメントを読み込むことを決定する前に、そのトピックが実際に適切であるか否かをClaudeが判断する助けにはなりません。もし個々のファイルが内容の濃いものであれば、Claudeに勘で3つも4つもファイルを読み込ませることは避けたいでしょう。必要とされるのは、Claudeがナレッジベースと照合してパターンマッチングを行い、実際に何が必要かについて情報に基づいた決定を下せるような、より軽量な方法なのです。

こうした場面で、READMEファイルは極めて重要な存在となります。弊社のナレッジベースでは、すべてのディレクトリに高密度なインデックスとして機能するREADMEを配置しています。製品ディレクトリのREADMEは、各製品につき一行の簡潔な説明を含んでいます。これにより、Claudeはトピックの関連性を十分に認識でき、一方でREADME自体の読み込みに過度なコストがかかることもありません。技術文書のREADMEでは、各アーキテクチャコンポーネントが1、2文で要約されています。これらは人間が読むためのドキュメントではありません（もちろん、人間にとっても有用ではありますが）、あくまでClaudeのためのインデックスなのです。

この方式は、私たちが「2段階読み込み戦略」と呼ぶものを実現します。 第1段階では、ClaudeがREADMEを読み込んで全体像を把握します。これは費用対効果が高く、数百トークンというわずかなコストでディレクトリ内にどのような情報があるかを理解できます。

第2段階では、READMEと現在の会話に基づき、Claudeは実際に必要とされる特定のファイルを判断し、それらのみを読み込みます。

この仕組みは、特定の章を熟読する前に本の目次を確認するのに似ています。あるいは、オペレーティングシステムがパス解決を行う際に、ファイルの内容全体を読み込む手間を避け、ディレクトリのメタデータを利用するのと同様の考え方です。

READMEを用いるアプローチは、見過ごされがちな「誤ったマッチング」という問題解決にも寄与します。要約レイヤーがなければ、たとえば「アイデンティティについて議論する」といったトリガーをClaudeが検知した際、それが非技術的な文脈でのブランドアイデンティティやユーザーアイデンティティに関する話題であるにもかかわらず、当社のDIDドキュメントを読み込んでしまう恐れがあります。しかし、READMEはClaudeが文脈を判別し、曖昧さを解消するために十分な情報を提供します。具体的には、「DID + Capability: 検証可能なクレデンシャルを使用した分散型アイデンティティ検証」といった記述があることで、Claudeは会話の真の意図を正確に判断できるようになるのです。このような軽量なセマンティックマッチングは、Claudeが言語モデルであるという特性そのものにより自然に機能します。私たちは、単にClaudeが正確に情報を照合するために必要なデータを提供しているに過ぎません。

そのためにも、質の高いREADMEを作成するスキルは磨く価値があります。目指すは、最小限のトークンで最大限の情報密度を実現すること。各単語がClaudeのパターンマッチングを効果的に支援するよう心がけましょう。「このディレクトリには」といった定型句は避けましょう。Claudeはそれがディレクトリのインデックスであることを既に認識しています。関連性の高い会話で用いられるであろう、特徴的な用語から記述を始めるのが効果的です。各項目を説明する際に、もし一文しか使えないとしたらどう表現するかを考え、その一文から冗長な要素を削ぎ落としましょう。こうした要約の作成に費やした時間は、Claudeがより賢明な読み込み判断を下すたびに、確実な成果として現れるでしょう。

Override Priority and Team Dynamics

ALPを個人で運用し始めた当初、設計は単純明快でした。個人の知識ファイルは個人ディレクトリに、ルールは個人の claude.mdに記述されていました。しかし、チームでの利用へ移行するにつれて、新たな要件が浮上しました。私たちは、製品ドキュメント、技術アーキテクチャ、企業戦略といった、誰もがアクセスできる共有知識を必要としました。同時に、システム全体をフォークすることなく、個人がその共有知識をカスタマイズしたり拡張したりできることも望まれました。さらに、プロジェクトが、個人およびチームのデフォルトとは異なる独自のコンテキストを持てるようにすることも求められました。

この解決策は、優れた設計のシステムにおける構成の典型的な動作を反映した優先度チェーンです。優先度は3段階で、次の順に適用されます。最優先されるのがプロジェクトレベルのオーバーライド、次にユーザーレベルのオーバーライド、そしてプラグインのデフォルトです。具体的には：

Claudeが products/arcsphere.mdを読み込む際、まずプロジェクトレベルのオーバーライドが存在するかを確認します。存在しない場合はユーザーレベルのオーバーライドを、それも存在しない場合はプラグインのデフォルトにフォールバックします。これにより、チームは公式の製品ポジショニングや技術的決定を反映する「信頼できる」ドキュメントを維持しつつ、個々のユーザーは自身のニーズに応じて特定のファイルを拡張したり上書きしたりすることが可能になります。ある製品に深く関わる開発者は、その製品のドキュメントを、より詳細な個人向けバージョンとして所有できるでしょう。また、新しいアプローチを模索するチームメンバーが、技術文書を実験的なメモで上書きするといった使い方も考えられます。これらの変更は、他の誰にも影響を及ぼしません。

このオーバーライドメカニズムは、自然な貢献の流れも作り出します。個人のオーバーライドが有用であると認められた場合、プルリクエストを介して共有プラグインに還元することができます。当初は個人の実験として始まったオーバーライドは、実際に利用されることでその有効性が確認され、共有の知識へと発展していくのです。共有すべき変更点はレビュープロセスを通じて統合され、公開すべきでない個人的な記録はあくまで個人に留められます。これは、全員が共有リポジトリを直接編集する場合と比較してはるかに洗練された方法です。後者の場合では、調整にかかる労力が増大し、変更の衝突というリスクも発生しかねません。

このパターンを検討しているチームにとって、重要な洞察は、優先順位の連鎖が信頼モデルに合致するように構築されるべきであるという点にあります。プロジェクトのオーバーライドが優先されます。なぜなら、プロジェクト固有のコンテキストが最も直接的であるためです。特定のコードベースで作業する場合、その規約が一般的なデフォルト設定に優先されるべきです。その次に、ユーザーによるオーバーライドが続きます。これは、個人のワークフローが重視されるためです。ユーザーが自身の用途に合わせて製品をより良く表現できる方法を持つ場合、それが妨げられるべきではありません。プラグインのデフォルトは、チームの合意を反映したドキュメントという「共有された真理」で、システムの基盤を固めます。この順序は、一度明確にすれば自然に受け入れられましたが、チームごとに異なる信頼モデルを持つ可能性があるため、その根拠を明確にしておく価値があります。

ALP導入後の変化

すぐに実感できる具体的なメリットは、まさに期待通りでした。クロードが無関係なコンテキストを処理しないため、応答速度が向上し、ファイルを事前に全て読み込まず、必要な時に応じてオンデマンドで処理することでトークン使用量が削減され、一つの製品に取り組む際にクロードの注意が多数の製品に分散されず、より集中的な出力が得られるようになったのです。こうした効率性の向上は確かに現実のものですが、今回の変更における最も興味深い核心は別の点にあります。トークンが節約され、応答はより機敏になり、コストも多少は下がります。それはそれで十分でしょう。

より大きな変化は、行動様式と文化にありました。ALP以前、私たちはAIのコンテキストを「バケツ」のように捉え、知っていることをすべて投げ込み、AIが関連する情報を自力で判断してくれることを期待するばかりでした。ALP以降は一転、コンテキストを設計されたシステムとして考えるようになりました。どのような知識が存在し、それぞれの情報はいつ、どのように関連し合うべきなのか？知識ベースは、受動的に蓄積されるものではなく、能動的にキュレーションされる対象へと変わったのです。Claudeがその情報を利用することを前提に、ドキュメントの書き方そのものを見直しました。READMEがインデックスとして機能すると理解した上で、情報密度についても深く考察するようになりました。ALPルールの設計は、私たちが何をわかっており、どの知識がいつ重要になるのかを、明確に言語化することを促しました。

チームにとって、ALPは、これまでのAIを活用したワークフローの多くに欠けていた、共有知識のための自然な構造を提供します。新しいチームメンバーが加わった際、彼らはプラグインをインストールするだけで、チームの製品ドキュメント、技術アーキテクチャ、戦略的コンテキストに即座にアクセスできるようになります。これらの情報は、事前にまとめて与えられるのではなく、必要な時にオンデマンドで読み込まれます。Claudeはどの情報がどこにあり、いつ読み込むべきかを既に把握しているため、メンバーは「Xのドキュメントはどこ？」と尋ねる必要がありません。ルールテーブル自体が、存在する知識の種類とその関連性を示す一種のメタドキュメント、つまり知識のマップとして機能します。知識システムが暗黙的で断片化されたものではなく、明示的で容易に発見できるため、オンボーディングのプロセスがより迅速になります。

このパターンは、AIの能力と人間システムの関係性に対する私たちの思考様式をも変革させました。ALP自体は、とりわけ巧妙なものではありません。単なるMarkdownテーブルといくつかの命名規則から構成されています。しかし、そこには「制約が効率を可能にする」という有用な原則が組み込まれています。明示的な読み込みルールの制約を受け入れることで、私たちは精度の高いコンテキストが得られるという効率性を手に入れました。同様に、READMEインデックスの制約を受け入れることで、2段階読み込みによる効率化を実現しました。この原則は、優れたソフトウェアアーキテクチャ、ユニックス思想、そして実効性のある組織設計に見られるものと共通しています。制約とは、単なる制限ではありません。それは、自由を可能にする構造そのものなのです。AIツールに課す制約について慎重に検討することで、その能力が低下するどころか、むしろより強力になることを私たちは発見しました。ALPは、この広範なパターンを示す小さな一例に過ぎませんが、その有効性は明確に実証されています。