生成AI活用: ソースコードレポジトリへの情報集約を考えてみた

はじめに

今年は生成AI 活用の年ということで、自分が参画しているプロジェクトでも生成AI コーディングを進めようという話がありました。

その中で精度向上のためにソースコードレポジトリへの情報集約を試してみたのでそのふりかえりです。

結論から言うと現状うまくいっていません。当初目的である生成AI の精度向上がうまくいっていない、まで行っていればよかったのですが、それ以前の状態です。人手による作業や、仕組みを回すために必要なメンテナンスポイントが新規に多数発生するので、「これを継続的にやるのか？」となっている状態です。

技術的課題ではない内容もあるので、今後も粛々とやっていくしかないという話です。

現状の諸課題

ドキュメント類 MS Office依存

あらためて考えるとドキュメントはほとんどレポジトリにコミットされていません。かなりの分量が Excel で作成されています。

これはなぜかと言うと、非エンジニア職も参照・編集するからです。特に決定事項に関わることは合意事項などはエンジニアだけが(厳密にはそうではないですが、アカウントや操作の都合上、レポジトリオンリー管理はハードルがある)参照・編集できる場所・方法だけでの管理が難しいです。

また、 Excel の場合はまだ何とかなるのですが、場合によって PowerPoint の場合もあり、こちらの場合は自動的に内容を抽出してテキストにする難易度が更に上がります。プロジェクト内だけであれば最新の PDF を作って対応という手もあります。

しかし、ウォーターフォール工程で言うところの詳細設計前までの資料はプロジェクト外の説明のためにも利用されることがあります。ここでの再利用性を考えると MS Office 製品でもある程度操作できる状態の最新に同期されたものが欲しいという要望が現状あります。

オフィススイートサービスのセキュリティーポリシー

前述の結果、ドキュメントの保存場所は会社契約のオフィススイートサービス上になります。すると、セキュリティポリシーの都合もあり、外部サービスからオフィススイートサービスに対して気軽にAPIで内容を取得することができません。つまり、現状ではMCP Serverなどでの対応は難しい状態です。

各人のローカル端末で実施するときはローカル同期ディレクトリを見るようにという話も考えられなくはないです。しかし、各人が同じ設定でセットアップできているかの確認も必要ですし、レポジトリ内の特定のディレクトリにシムリンク(やそれに相応するもの)を張って参照させることになりそうなのでうまく動かないことがありそうです。また、頻度は低いものの、同期失敗したときの対処も考慮できていません

変換や自動化のための仕組みが現状だとかなり重たい

前述の前提になるとデータとビューを分けて、データをレポジトリにコミット、ビューを生成という手段はあります。しかし、これを本気でやろうとすると 2019年の NTTデータのパラメーターシートと IaC の話

の強化版をやる必要があります。

具体的には

• 変換の仕組みが必要 (それでも PowerPoint はどうかな.....)
• (主に非エンジニア職向けの) テキスト直接ではない編集ツールを準備
• 変換した後の配布処理が一部手動

と、割と頑張らないといけないパートがあります。技術的制約とは限らない部分もあるのでこれから随時の取り組みになるかと思います。

変換の仕組みは定型であればそれこそトランスフォーム処理なので、バージョン変わった時のメンテナンスなどは生成AI で、なんとかならないですかね (学習データのカットオフ問題や、新バージョンの仕様がMCPで取得できる仕組みがあるか次第だと思いますが)。

「その情報は生成AIの活用にプラスに働いていくのか？」

逆に現状でもテキストのものもあります。オフィススイートサービスも Markdown に張り付けてある程度体裁が整うものや、拡張機能などである程度 Markdown に出力できるのでこの辺りはどうにかなります。しかし、現状で、テキストでも問題ない情報というと、内部議事録とタスク情報くらいのものでこれは役に立つのだろうか、と疑問が残る感じでした。

決定事項の情報があるのはいいことだと思うのですが、そこまでの紆余曲折だったり、こういう議論があったが採用されなかったあたりまで入り込むとコンテキスト容量も消費しますし、プラスに働くんでしょうか。

ソースコードも集約してモノレポ化した結果、人によって生成AI に与えたいルールが違う

フロントとバックエンドで言語が違うことも多いですし、別の規約やルールを適応したい状態です。年初あたりだとルール読み込みファイル/ディレクトリが1か所に固定されていて少し困ったことがありました。

この辺りは下半期になる頃には対応していたツールも出ていた記憶ですが、モノレポ化 に伴って Sparse Checkout する人も出てきたのでやはりルールの取得/配布のツールは何かしら用意が必要なのかなと思っています。

生成AI に与えるコンテキストが大きくなりがち

単純に対応してるとインプットファイルが増えていっているのでコンテキストが大きくなっていっていきます。これは外部コンテキスト保存/圧縮のツールを間に挟む方法もありますが、根本的にはその人が基本的に参照しない領域まで見に行かない方がよいのではないかとも思います。

ツールによっては生成AI が参照しないディレクトリ/ファイルを指定する設定ファイルが出てきているのでそちらを使うのも手かもしれません。

生成AI の作業ディレクトリ/作業ファイルをどう扱うか

仕様駆動開発(SDD)やAI-DLCなどの手法では生成AI が読み書きするファイルが出てくるので、生成AI 用の作業ディレクトリが必要になります。些事ではありますが、モノレポになって共同のレポジトリを使うので名前にもそれぞれこだわりがあって合わせるのも大変でした。

また、作業生成ファイルをどうするかの問題もあります。今のところレポジトリにはコミットしないことになったのですが

• Conventional Commit と共にPull Request マージタイミングのコミットメッセージにサマリを埋め込む
• サマリを Pull Request に埋め込む

のどちらにするかという話になっています。GitHub を使っているなら Pull Request でよいかなとは思っていますが、汎用のやり方ではないですし、どうしたものかなと思っています。

また、使ったプロンプトもどこで保存するかという話もあり(今はプロジェクトのファイルストレージに Pull Request と紐づけたフォルダを作成してそこに保存している)、あまり方法が定まっていません。

おわりに

必ずしも生成AI ツールの発展だけで解消しづらい内容を含んでいるので、来年も継続的に取り組んでいこうと思います。