【ITニュース解説】A Project Can Decline APX Without Rejecting APC

APC（Agent Project Context）とAPX（Agent Project eXecutor）は、ソフトウェア開発プロジェクトにおける情報の整理とツールの利用方法に関する概念だ。まず、APCはプロジェクトが共有する文脈、つまり「これはどういうプロジェクトで、どういうルールで進めるか」といった情報を定義するための規約である。これは、プロジェクトの設計図や共通のルールブックのようなものと考えるとわかりやすい。特定の開発ツールに縛られず、誰でも理解できるようにプロジェクトの指示、開発を助けるエージェントの定義、利用できるスキル、安全なメモなどを.apc/ディレクトリやAGENTS.mdファイルに保存する。この仕組みによって、プロジェクトの情報は「ポータブル」、つまり異なる環境やツール間で簡単に持ち運べるようになる。

一方、APXは、APCで定義された共有の文脈を読み取り、実際の開発作業を行うためのランタイム（実行環境）やツール層を提供する。これは、APCで定められた設計図やルールに基づいて、具体的な作業を実行する「作業場」や「実行エンジン」のようなものだ。APXは、開発中のセッション情報、一時的なキャッシュ、開発者個人の設定など、プロジェクト全体で共有する必要のない一時的な情報をリポジトリ（プロジェクトのファイル保管場所）の外で管理する。これにより、共有されるプロジェクト情報は常に清潔に保たれ、個人的な作業内容によって汚染されることがない。

この二つの概念において、特に重要なのは「プロジェクトはAPXの使用を拒否しながらも、APCの利用は継続できる」という点だ。全てのプロジェクトがAPXを使うわけではない。たとえば、開発チームが既に別の優れた開発ツールを使っている場合や、特定のツールに依存せず、複数のツールで読み込めるようなシンプルなファイル形式だけを望む場合がある。また、プロジェクトの管理者がまだAPXの評価を終えていないといった状況も考えられる。もし、APCを使っている全てのプロジェクトがAPXの導入や実行を許可していると自動的にみなされてしまうと、せっかくツールに依存しないことを目指したAPCという規約が、特定の製品を使うための前提条件になってしまう。これではAPCが持つ本来のメリットが失われてしまうことになる。

このような状況を避けるため、プロジェクトがAPXを使用しないという意思を明確に表明できる仕組みが用意されている。プロジェクトは、.apc/project.jsonというファイルに{"apx": "declined"}という記述を追加する。この記述は、APCに対応したランタイムツールに対して、「このプロジェクトではAPXを提案したり実行したりしないでください」というはっきりとした指示を出す。しかし、この設定があったとしても、プロジェクトの重要な共有情報、例えば指示やエージェントの定義、スキル、安全なプロジェクトメモリといったAPCの情報は、通常通り.apc/ディレクトリ内に保存され続ける。APXを使わないという選択は、プロジェクトが「失敗した」状態を意味するものではなく、あくまで「このプロジェクトではAPX以外のツールや方法を使いたい」という、プロジェクトの明確な境界線を示すものなのだ。

この仕組みによって、開発ツールがプロジェクトに対してどのように振る舞うべきかを判断するための三つの状態が導入された。一つ目は"installed"という状態だ。これはAPXが現在の環境で利用可能であり、必要に応じてそのコマンドを使っても良いということを意味する。二つ目は"declined"で、前述の通り、APXを提案したり実行したりせず、APCファイルを直接使って作業を進めるべきだという指示である。三つ目は、この設定がmissing（欠落している）かnull（無効）の場合だ。このケースでは、開発ツールはAPXが利用可能であると勝手に仮定してはならない。APXに依存するような処理を行う前に、実際にAPXがその環境で利用できるかどうかを確実に確認する必要がある。これらの状態は、プロジェクトレベルでの意思決定を表現するものであり、ツールが自動的にAPXの有無を検出する代わりに使えるものではない。例えば、"installed"と記述されていても、実際にAPXのコマンドが問題なく動作するかどうかは個別の確認が必要であり、値が欠けているからといってAPXが存在しないと断定できるわけではない。また、"declined"という設定は、「APC自体を無視する」という意味ではないことを理解しておくべきだ。

プロトコルとしてのAPCと、ランタイムとしてのAPXをこのように明確に分離することは、非常に実用的なメリットをもたらす。APCは、リポジトリに対してツールに依存しない共有の文脈を提供する「規約」の役割を果たす。一方でAPXは、その文脈を読み取り、日々の開発作業を行うための「実行環境とツール層」を提供する。これらは互いに協力し合って機能するが、それぞれが独立した価値を持つ存在でもある。

この独立性があるからこそ、多様な開発スタイルが許容される。例えば、ある開発者はプロジェクトのリポジトリを自分のコンピューターに複製し、APCで定義された規約を読み取り、自分が普段使い慣れているエディターや別のコーディングエージェントを使って作業を進めることができる。一方で、別の開発者はローカルでの実行にAPXを使っても構わない。それぞれの開発者が自分の好むワークフローを選ぶことができ、その選択が互いのプロジェクト設定を上書きしたり、干渉したりする必要がないのだ。

開発ツールがAPCの情報を見たとき、まず最初に尋ねるべきは「このプロジェクトリポジトリは、ポータブルで永続的な情報として何を定めているのか？」という問いである。そして、その情報に基づいて初めて、「この環境で、どのローカルツールが使用を許可され、実際に利用可能なのか？」という問いを立てるべきなのだ。この優先順位を守ることで、開発ツールは常にプロジェクトにとって役立つ存在であり続け、開発ツールの選択がプロジェクト自体の特性やアイデンティティの一部となってしまうことを避けることができる。このように、APCとAPXの概念、そしてAPXの利用を拒否できる仕組みは、柔軟で協調的なソフトウェア開発を実現するための重要な基盤を提供するものだ。