【ITニュース解説】Does your system read back what it writes?

システム開発や運用において、私たちはシステムが正しくデータを記録していると信じがちだが、その記録されたデータが本当に活用されているかを確認することは非常に重要である。今回紹介する事例は、システムが生成した情報が実際には誰にも読まれず、結果として多大な非効率性を生み出していたという問題と、その発見から解決までの経緯を明らかにする。これは、多くのシステムに共通して見られる可能性のある一般的なバグの形である。

この問題の舞台は、複数のタスクを自動的にスケジュールし、実行する「オーケストレーションプラットフォーム」だ。このプラットフォーム上で動作する「ワーカーエージェント」と呼ばれるプログラム群は、それぞれの処理過程で、作業上の注意点、実行頻度、成功したアクセス方法といった「永続的な知識」を「ノートファイル」という形で記録するように指示されていた。エージェントは指示通りに動作し、中には40キロバイトに達するファイルも多数作成され、保管されていった。

しかし、これらのノートファイルが本当に役立っているのかという疑問が生じ、筆者は簡単な検証を行った。具体的には、システム全体のコードベースを対象に、ノートファイルのファイル名を検索（一般的にはgrepコマンドのようなツールを使用）したのだ。その結果は驚くべきものだった。ノートファイルの名前がコード内で参照されている箇所は、ファイルをアーカイブする処理と、ユーザーインターフェースでファイル名の一覧を表示する処理の、わずか2箇所のみだった。つまり、実際のデータ処理の計画を立てる際や、処理を実行する際に、これらのノートファイルが読み込まれることは一切なかったのである。エージェントが手間をかけて書き込んだ貴重な情報は、誰にも参照されることなく、ただひたすらディスクに積み重ねられていただけだった。これはまさに「書き込み専用のメモリ」のような状態だと言える。

この問題には、実は以前から見過ごされていた兆候があった。全てのジョブがノートファイルを維持していたわけではなく、一部のジョブだけがファイルを作成していたのだ。当初、筆者はこれをエージェントの動作の不一貫性と捉えていたが、実際には非常に合理的な行動だった。誰も活用しないノートを人間が書き続けないのと同じように、システムもまた、何のフィードバックもない記録は継続しない。この事実は、ソフトウェアの振る舞いにも当てはまるという示唆を与えている。

さらに、この「書くだけで読まれない」というバグには、もう一つの深刻な側面が存在した。それは、各ワーカーエージェントに渡される「プラン」（実行計画）自体も、ジョブの実行が終了すると同時に破棄されていたことだ。例えば、過去に70回も実行されたことのある同じジョブであっても、システムは毎朝、そのプランを完全にゼロから再構築していた。データベースのスキーマ情報、ファイルへのパス、データ識別ルールといった、一度確立すれば再利用できるはずの重要な情報が、毎晩のように最初から作り直されていたのである。この非効率性は、実際のコストとして明確に現れていた。本来であれば5回の処理サイクル（エージェントのターン）で完了するはずの正常な実行が、平均で6.5回、最悪の場合で10回ものターンを要していた。また、「今日は新しいデータがない」と判断され、すぐに処理が完了するジョブであっても、すでに結果が分かっているにも関わらず平均3.5回のターンを消費しており、無駄な処理にリソースが費やされていたことが明らかになった。

これらの非効率性を解消し、システムが記録した情報を有効に活用できるようにするために、いくつかの重要な設計原則が導入された。

一つ目は「限定的であること、全体ではないこと」だ。ノートファイル全体をそのままシステムへの指示（プロンプト）として渡そうとすると、情報量が多すぎて入力が破損するという、過去に解決済みだった別のバグが再発する可能性があった。そのため、ノートファイルの中から最も重要な部分だけを「キュレーションされたヘッダー」として毎回システムに渡し、残りの詳細な情報はディスク上に保持し、エージェントが必要に応じて参照できるようにした。

二つ目は「厳選されていること、追記ではないこと」だ。単に情報を追記していくだけでは、ファイルがすぐに肥大化し、管理が困難になる。そこで、情報が変更された場合は古いものを新しいもので置き換え、もはや不要になった情報は削除するようにした。もし永続的な変更が何もなければ、ファイル自体はそのままにしておく。この「何もしない」という選択が、不必要な処理の繰り返しを防ぎ、システム全体の負荷を軽減する効果がある。

三つ目は「指示が優先され、コンテキストが譲歩すること」だ。もしプランとノートの合計サイズがシステムの処理上限を超えてしまう場合、最も重要なのは実行計画である「プラン」であり、ノートは補足情報であるという判断がされた。そのため、プランが優先され、ノートの方がトリミング（切り詰め）されるように設計された。これにより、システムにとって最も重要な指示が確実に伝達される。

そして、アーキテクチャ全体よりも重要だったとも言える、プロンプトレベルでの詳細な工夫も導入された。それは、プランを立案するシステムに対して、「今日は新しいデータがない」という結果であっても、それは「プランが正常に機能した」ことを明示的に伝えるという指示である。もしこの指示がないと、システムは「何も起こらなかった」という静かな結果を、あたかもパフォーマンス不足であるかのように誤解し、実際には問題ないはずのプランを不必要に書き直してしまう可能性があったからだ。

この一連の経験は、システムが生成するデータが実際に利用されているかどうかを定期的に確認することの重要性を強く示唆している。もしあなたのシステムが何らかの情報を記録させているのであれば、そのファイル名をコードベースで検索してみてほしい。たった30秒ほどの簡単な確認で、あなたのシステムにも同様の「書くだけで読まれない」非効率性が潜んでいることを発見できるかもしれない。そして、その発見は、大きなコスト削減やパフォーマンス向上に繋がる可能性を秘めている。