全体を把握すること、全てを見通すこと

 

こんにちは、横井です。

AIコーディングを進めていると、あたかもAIがリポジトリ全体を見通して作業しているかのように錯覚することがあります。

実際にはAIはその都度のリクエストに対して応答しているだけです。LLM（大規模言語モデル）やエージェントのメモリ機能のおかげで、連続してリクエストを送ると、あたかも学習し成長しているかのような印象を抱いてしまいます。

しかし、例えばコードにエラーがあり修正を行うのですが、エラーが解消されない場合は再び修正を試みる。。といったコード修正の無限ループに陥った場合、一度作業を中断して状況を見直し再び作業を再開すると、これまでの経緯が反映されず、ルールに反した動作が現れることがあります。その結果、コードが破損し「最初から作り直した方が早いかな？」といった残念な感じになることもありました。

また、AIコーディングでは、依存関係の確認、すなわちクロスリファレンス機能が機能していない点も問題です。たとえば、GeneXusでは、オブジェクトや項目属性がどこで利用されているかがクロスリファレンスとして即座に把握できるため、使用されているものは削除できない安全策が整っています。しかし、スクラッチ開発におけるソースコードの管理では、GitHubのようなリポジトリでも依存関係が完全には把握されず、「問題ない」と判断して削除したファイルが、実は他の部分から参照され、システムが正常に動作しなくなるといった事態が起こりやすいです。まあ、これはAIコーディングに限った話ではありませんが、GeneXus開発に慣れているとクロスリファレンス機能が存在するのが当たり前だったので結構困りました。

別な話としては、アジャイルにAIコーディングを進めると、機能を追加してくなかでリファクタリングを提案してくるのですが、あたかも全てを見直してコード修正してくれているようで実はメモリに残っている範囲でリファクタリングを行い、随分と初期に行ったコーディング個所が漏れ落ちてしまう事もあります。

例えばデータベースアクセスのコードが、効率向上を考慮してコネクションプールを利用するようにリファクタしてくれるのですが、初期のコーディング部分は直接接続のまま残されてしまっていたり。といった具合です。

このように人は広い視野で物事(リポジトリ内)を記憶しておくことができるので「ここ大丈夫だったかな?」と目くばせする事ができます。(もちろん、業務システムの様に量が多く、漏れ抜けが許されない場合は横展開チェックなど記憶に頼らない確認手段は必要ですが)

一方でLLMはリポジトリ全体を記憶しておくこと、記憶し続ける事が現状では難しいので、その都度のリクエストに含まれる情報や短期的なメモリ機能の範囲でしか「把握」という状況ができません。

なんらか代替手段が無いと業務システムのような規模は難しいなと感じています。

私がAIコーディングにおいてリポジトリ管理として望む点は、以下になります。

• クロスリファレンス機能
• 例えば、グラフデータベースのように各ソースコード間の関係性を表現できる仕組みがあれば、どの部分に依存しているかが一目で分かり、誤って必要なファイルを削除してしまうといったリスクを減らすことができます。
• リポジトリ(ソースコード)全体の把握
• こちらは、リポジトリ全体を文脈で検索可能なデータベース化ができれば。と思います。現状のRAG（Retrieval Augmented Generation）で実現できるかは不明な部分もあります。ソースコードのファイルは大きいため、通常RAG化する場合はファイルを複数のチャンクに分割してベクトル化します。ひとつのチャンク内に収まる文脈であれば、文脈検索により正確な抽出が可能です。しかし、ロジックが分割されたチャンクに跨った状態だと、文脈が分断され検索精度が出ない(ヒットしない)可能性もあります。逆に、ソースコード全体を丸ごとベクトル計算してしまうと、文脈が広がりすぎてベクトルの意味が希薄になってしまいます。そのため、適切な文脈情報を保持するには、チャンク分割は避けられませんがその要求は矛盾したものとなってしまいます。ただ単に機械的に分割するのではなく、ロジックの処理単位に分割できれば、チャンク単位での検索でも高い正確性が持てるかもしれません。ただ、この場合はどうやって分割するか? コードのロジックを解釈しながら分割ができるのか? といった技術課題が多々あり実現可能かどうかは未知数ですが、今後の技術の進展に期待したいところです。

といった感じで、全体を把握する・全てを見通す。という人にはごく当たり前にできる事が実は結構難解で高度な機能なのだとAIを使い込んでみて気づかされました。

では。