【ITニュース解説】Your agent forgot a decision you made last week. Mine did too.

ソフトウェア開発の現場では、日々の重要な決定、例えば「この機能にはどのデータベースを使うか」といったことの背景や根拠が、時間が経つと忘れ去られがちだ。チームメンバーの変更や異動があると、過去の経緯はますます不明確になる。

その結果、過去に解決済みの問題が再び議論されたり、古くなった設計がシステムに残り続け、予期せぬ不具合を引き起こすことがある。記事では、チームがキュー（データ処理の順番を管理する仕組み）に関する設計変更の経緯を思い出せず、古い設計が本番環境で問題を引き起こした事例を紹介しており、このような混乱は開発チームの生産性やシステム品質に悪影響を及ぼす。

従来のテキスト検索技術では、単に文章として情報を検索するだけで、ある決定が他の情報とどのように関連しているか、複雑な関係性を自動的に把握することは難しい。

そこで登場するのが、「memgraph」というツールだ。これは、そうした「意思決定の忘れ」という課題を解決するために作られた、小さくても強力なツールである。memgraphは、単なるテキスト情報としてではなく、意思決定や関連する事実、そしてそれらの間の「関係性」をグラフ構造として記録・管理することに特化している。

memgraphの最大の特徴は、非常にシンプルであることだ。特別なサーバーやネットワーク接続は不要で、コマンドラインから操作できる。記録されたデータは一つのJSONファイルとして保存されるため、プロジェクトのコードと共にバージョン管理システムで管理でき、意思決定の履歴を容易に追跡できる。

memgraphを使い始めるには、まずmemgraph initコマンドでプロジェクト内にグラフを初期化する。次に、チームの意思決定や、その決定に影響を与えた事実をグラフに追加していく。例えば、「キューの実装にPostgresデータベースの通知機能を使う」という決定があった場合、memgraph add --type decision --title "Use Postgres LISTEN/NOTIFY for the queue" --source "ADR-014"のように記録する。ここでADR-014は、その決定が記録された設計書などの情報源を指す。また、「Postgresの通知機能で送れるデータのサイズには上限がある」という事実が判明した場合、memgraph add --type fact --title "NOTIFY payloads cap at 8000 bytes" --source "Postgres docs"のように記録する。

そして、これらの決定や事実がどのように関連しているかを明確に記録するのが重要だ。例えば、通知機能のデータサイズ制限という「事実」が、Postgresの通知機能を使うという「決定」と「矛盾する」関係にある場合、memgraph link m-002 m-001 --relation contradictsのようにリンクを張ることで、その関係をグラフに明確に記録する。さらに、データサイズ制限という事実を受けて、「キューをRedis Streamsという別の技術に切り替える」という新しい決定がなされた場合、memgraph supersede m-001 m-003 --reason "payload cap makes NOTIFY the wrong tool"のように記録できる。このsupersede機能は重要で、過去の決定を削除せず、新しい決定に置き換えられた履歴を残すことで、変更経緯を明確に保つ。

memgraphは、このように記録された情報から、開発チームが直面する三つの重要な疑問に迅速に答えることができる。一つ目は、「なぜこの決定がなされたのか？」という疑問だ。特定の決定IDを指定してmemgraph whyコマンドを実行すると、その決定の根拠となった情報源、それを支持した要素、矛盾する要素、そしてその決定が他の何かに置き換えられたかどうかが一覧で表示される。これにより、決定の背景や経緯が瞬時に把握できる。

二つ目は、「何か陳腐化しているものや矛盾はないか？」という疑問だ。memgraph checkコマンドは、現在のグラフの状態を分析し、まだ解決されていない矛盾、すでに置き換えられた古い決定に依存している要素、あるいは根拠が不明な情報（ソースがない主張）がないかを自動的に検出する。これは、まるで監査役のように、チームの知識ベースに穴がないか、一貫性が保たれているかをチェックしてくれる。特に重要なのは、memgraph checkがエラーを検出した場合に、その結果を開発プロセスに組み込めることだ。例えば、新しいコードをシステムに統合する（マージする）前に、memgraph checkを実行し、もし矛盾や古い決定への依存が見つかれば、そのコードはマージされないように設定できる。これにより、問題が本番環境に到達する前に、開発の初期段階で食い止めることが可能になる。

三つ目は、「私たちは何を信じているのか？」という疑問だ。memgraph listコマンドを実行すると、グラフに記録されているすべての決定と事実が一覧表示され、すでに置き換えられたものはそのようにマークされる。これにより、現在のチームが共通認識として持つべき情報や、現行の設計原則が明確になり、チーム全体の知識を統一できる。

しかし、どんな優れたツールも、その使い方が重要である。memgraphのグラフは、そこに記録される情報の質に大きく依存する。このツールは、情報源が本当に正しいかどうかを判断することはできない。あくまで、どこからその情報が来たのか、そして情報全体として矛盾がないかを教えてくれるだけだ。そのため、「情報源のない決定は、単なる噂にすぎない」と記事は強調している。根拠のない主張はmemgraph checkによってフラグが立てられ、修正が促される。そして、決定を変更する際は、前の決定を安易に削除するのではなく、必ずsupersedeコマンドを使って置き換えるべきだ。歴史を消し去ってしまうと、チームは半年ごとに同じ選択について再び議論することになりかねない。

このようにmemgraphは、開発チームが過去の意思決定の経緯を明確に保ち、現在のシステムの状態を健全に維持するための強力な支援ツールである。システムエンジニアを目指す上で、単にコードを書く技術だけでなく、チームとしていかに効率的かつ正確に開発を進めるかというプロセス管理の視点も非常に重要になる。memgraphは、その一助となるだろう。