【ITニュース解説】A Routine Name Is Not Its Memory Key

ITシステムを構築する際、私たちが「タスク」や「処理」と呼ぶものには、人間が理解しやすい「名前」と、システムが内部で正確に区別するための「ID（識別子）」という二つの異なる識別子が必要となる。これらを適切に管理することが、システムの安定した運用には欠かせない。

記事では「ルーチン」という言葉で説明されているが、これは「特定の目的を持った一連の処理や自動化されたタスク」と考えると理解しやすいだろう。例えば、「日次レビュー」という名前のルーチンがあったとする。この名前は、私たちがそのタスクを特定し、コマンドラインで実行したり、他の人に説明したりするために使う、人間向けの識別子だ。しかし、システムがそのルーチンの実行状態や過去の履歴を正確に管理するためには、この人間向けの「名前」とは別に、システム内部でのみ使われる「安定した識別子（ID）」が必要となる。

もし、この人間向けの名前とシステム内部のIDを同一視してしまうと、どのような問題が起こるだろうか。例えば、あるルーチンの名前を「日次レビュー」から「毎日の報告」へと少し変更しただけで、システムにとっては全く別の新しいルーチンとして扱われてしまう。その結果、それまでの実行履歴や、保存されていた重要な状態が失われ、ルーチンはまるで初めて実行されるかのように、初期状態から動作を開始することになるのだ。これは、ルーチンが持っていた「記憶」が失われることを意味し、運用の継続性を大きく損なう原因となる。

このような問題を解決するために、記事では「APC（Agent Project Context）」と「APX（Agent Project eXecution）」という二つの層を導入し、それぞれの役割を明確に分担している。

APCは、プロジェクト全体で共有され、バージョン管理されるような「ポータブルな情報」を扱う層である。例えば、プロジェクトのルール、エージェントの定義、使用するスキルなど、ソースコードを管理するリポジトリと一緒に持ち運びが可能な、いわば「プロジェクトの設計図」のようなものだと考えると良い。これは、プロジェクトの普遍的な真実や、チーム全体で合意された設定を含む。

一方、APXは、実際にルーチンを実行し、その実行に関する「ローカルな運用状態」を管理する層だ。つまり、タスクが日々どのように動いているか、その時に何が起きたかといった、実行時に発生する具体的な情報を扱う。重要なのは、ルーチンの「安定したID」を管理するのはこのAPXの役割だということだ。APCがプロジェクトの「静的な真実」を扱うのに対し、APXはルーチンの「動的な実行状態」を扱うという明確な分担がある。

APXでは、各ルーチンに対して、人間が読むための名前と、システムが内部で使うユニークなIDの両方が割り当てられる。私たちがCLI（コマンドラインインターフェース）を使ってルーチンを実行する際には名前で指定するが、APXは内部でそのIDを使ってルーチンの「プライベートなメモリ」の場所を特定する。具体的には、~/.apx/projects/<project-id>/routines/<routine-id>/memory.mdのようなパスで、ルーチンごとに専用のメモリ領域が確保される。この「メモリ」には、例えば前回の実行で解決できなかった問題のメモや、次の実行に役立つ一時的な情報など、ルーチンが自身の継続的な運用に利用する短いメモが保存される。

もしルーチンを編集した際に、そのIDまで変わってしまうと、新しいIDのルーチンは以前のメモリパスを参照できなくなり、過去のメモを読むことができなくなる。APXはこの問題を避けるため、ルーチンの内容（スケジュール、プロンプト、実行対象など）を更新する際にも、既存のIDはそのまま引き継ぐ。これにより、ルーチンは見た目や動作が変わっても、その「アイデンティティ」と「記憶」を維持し続けることができる。また、編集が新規作成ではないことを示すために、作成日時も維持される。

ルーチンのメモリのような実行時状態を、プロジェクト全体で共有されるAPCに含めたくなる誘惑もあるかもしれない。しかし、両者には明確な境界が必要だ。ルーチンのメモリは、「この特定のスケジューリングされたタスクが、実行と実行の間でローカルに何を覚えておくべきか」という、そのルーチン自身の運用に関する情報であり、チーム全体の普遍的なルールとして共有されるべき情報ではない。

例えば、「日次レビュー」ルーチンが、あるローカルな検査で未解決の問題を見つけたというメモを残したとする。このメモは、その環境で実行されている「日次レビュー」ルーチン固有のものであり、プロジェクト全体で守るべきルールではない。もし、このようなローカルなメモがAPCに含まれてしまうと、他の人がプロジェクトのリポジトリをコピーした際にも、そのローカルメモまで引き継がれてしまう。また、レビューなしにコミットされてしまい、まるでプロジェクト全体で守るべきルールであるかのように扱われ、混乱を招く可能性がある。もしプロジェクトとして恒久的なルールが必要になった場合は、人間が適切なレビュープロセスを経て、それをAPCに「昇格」させるべきだ。それまでは、ローカルなメモはローカルに留まる。この明確な境界があることで、APCはポータブルでレビュー可能な「プロジェクトのコンテキスト（背景やルール）」を、APXは「ローカルな実行状態」を管理するという役割が明確になり、両システムの理解が深まる。

ルーチンを変更する際には、単に表示されている内容が変わったかどうかだけでなく、その裏側にある状態も確認することが重要だ。具体的には、以下の四つの質問を自分に問いかけてみると良い。

1. ルーチンはまだ同じIDを持っているか？
2. そのルーチンの既存のメモリパスはまだ機能するか？
3. 変更によって作成時間や以前の実行状態は維持されたか？
4. もし名前が変わった場合、それは意図的に全く新しいルーチンを作成したのか、それとも既存のルーチンを移行する際に、その状態（メモリなど）をどう扱うかを明確に決定した結果なのか？ 特に最後の質問は重要で、表示名がコマンドラインでの検索キーとして使われることが多い一方で、実行時のIDはルーチンのデータや履歴を保持する錨の役割を果たす。だから、名前変更は単なるJSONレコードの書き換えによる偶発的な副作用ではなく、製品としての意図的な決定であるべきだ。

安定した識別子（ID）は、一見すると地味で面白みに欠けるものに見えるかもしれない。しかし、その真価は、ルーチンが数週間、数ヶ月と長期にわたって運用され、変更されていく中で発揮される。安定したIDがあることで、スケジュールされた作業が自身の履歴を適切に保持し、ローカルな状態が不必要にプロジェクト全体に影響を与えず、そしてちょっとした編集が運用上の継続性を損なわないという、システム運用における不可欠な価値を提供する。APCにはポータブルなプロジェクトの真実を、APXにはルーチンのローカルな状態を任せる。そして、ルーチンに変更を加える際には、その記憶が依存するIDを必ず維持することが重要だ。