0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@joyrswd

AIレビューを先送りしたら、「知識の置き場」を作って失敗した話

0
Posted at

前回の記事では、AIレビューで見つかった指摘を一件ずつ潰すのではなく、

  • 同じ原因の問題をまとめて探す
  • 修正した内容そのものも再レビューする
  • 同じ種類の問題が繰り返し出るなら構造から見直す

といった形で、レビュー後の動きを AGENTS.md に持たせた話を書きました。

その過程で、もう一つ整理したことがあります。

レビューで見つかったものを、全部その場で直す必要はない。

人間がレビューする場合なら当たり前の話ですが、AIにある程度自律的に作業を続けさせようとすると、この判断を明示しておかないと、レビュー指摘によって作業範囲がどんどん広がっていきます。

今回は、

今回直さないレビュー指摘をどう扱うか

から始まり、

その判断や知見を次の作業にも使えないか

と考えてKnowledge Baseまで作ろうとし、最終的に撤回したところまでを書きます。

TL;DR

レビュー指摘を、次の4つに分けられるようにしました。

判定 扱い
Accept now 今回対応する
Reject 採用しない
Defer 今は対応せず、条件が来たら再考する
Observe 判断材料が足りないため経過を見る

すると今度は、Defer や Observe にしたものを「あとで考えられる状態」でどこかに残しておく必要が出てきます。

まず workbench/ に非authoritativeな形で保持する仕組みを作りました。

さらに、レビューから得た知見そのものをKnowledge Baseとして蓄積し、別の作業でも再利用できないか試しました。

実際、過去の知見を与えるとAIの調査が深くなるケースは確認できました。

ただし、その影響はレビューの補助に留まりませんでした。過去の知見をもとに、現在の設計上のownershipやarchitectureまで変更する方向に推論が広がりました。

知識は役に立つ。でも、その知識にどこまで設計へ口を出す権限があるのか。

そこを安全に決められず、Knowledge Baseは採用を見送りました。

最終的に残ったのは、

「知識を全部覚えさせる」より、「あとで扱う仕事を適切に残す」方が先ではないか

という感覚でした。

レビュー指摘を全部その場で直すのをやめた

AIレビューを繰り返していると、指摘にはいろいろあります。

たとえば、

  • 今回の実装に直接必要な修正
  • 今回とは別の改善案
  • 将来的には良さそうだが今は不要なもの
  • 本当に問題になるか、まだ判断材料が足りないもの

です。

これらを全部「レビューで見つかったから直す」と扱うと、レビューをするたびに作業範囲が広がります。

そこで、レビューやフィードバックを受け取ったときに、まず扱いを分けるようにしました。

判定 意味
Accept now 今回の作業として対応する
Reject 意図的に採用しない
Defer 今はやらないが、条件が揃えば再考する
Observe 現時点では判断せず、状況を見る

この仕組みを入れたのが次の変更です。

ここでやりたかったのは、単にレビュー指摘を先送りできるようにすることではありません。

レビュー結果が、そのまま現在の作業範囲を拡張しないようにすることでした。

でも「あとで考える」は、どこに置くのか

Defer を作ると、すぐ次の問題が出ました。

あとで考える

と言ったものを、本当にあとで考えられるのか。

会話の中だけに残していたら、別のセッションでは簡単に埋もれます。かといってIssueとして全部管理するほどでもないし、採用済みの要件や設計を置く場所に入れてしまえば、今度は正式に採用されたもののように見えてしまいます。

そこで使ったのが workbench/ でした。

当時の workbench/ は、まだ採用していない検討材料や調査結果などを扱う場所でした。

ここに、

  • なぜ今は対応しないのか
  • どの状況になったら再考するのか
  • 現時点ではどの程度重要なのか

といった情報と一緒に、Defer や Observe の内容を残せるようにしました。

重要なのは、

残したからといって、採用されたわけではない

ということです。

workbench/ にあるものは、あくまで再評価可能な材料です。TODOリストでもなければ、将来必ず実装する約束でもありません。

そこで思った。「レビューの知識そのものを残せないか？」

ここまでは、個別のレビュー指摘を残す話です。

でもレビューを続けていると、もう少し欲が出てきます。

たとえば、ある作業で永続化まわりの失敗経路をレビューし、

正常系だけではなく、途中失敗や復旧経路も見ないと危ない

という知見を得たとします。

別の作業でも似た構造が出てきたとき、またゼロから同じことを考えるより、

過去にこういう失敗パターンがあった

という知識をAIが持っていた方が、レビューが深くなるのではないか。

つまり、

レビュー結果ではなく、レビューから得た知見を再利用したい

と考えました。

そこで一度、Knowledge Baseを作る方向に進みました。

この実験を含んでいたのがPR #31です。

Knowledge Baseは、ちゃんと効いた

Knowledge Baseのアイデア自体が、まったく役に立たなかったわけではありません。

AIDD Skeletonを適用した実プロジェクト側（Consumer）で、過去の知見を与えた場合と与えない場合を比較しました。

すると、過去の知見がある方では、

  • 類似する失敗経路まで調べる
  • より広い永続化リスクを考える
  • 単発の修正だけでなく、共通する構造まで踏み込む

といった形で、推論が深くなるケースが確認できました。

つまり、

過去のレビュー知識は、次のレビューにちゃんと影響する。

ここまでは狙い通りです。

むしろ、問題はその先でした。

Knowledge Baseが設計にまで口を出し始めた

Knowledge Baseありのセッションでは、想定どおり永続化リスクをより広く追いました。

ところが、その影響はレビューの深掘りに留まりませんでした。

実験では、過去の知見を持った側が safe-log のownershipを変更し、さらにcollector/control architectureを追加する方向にまで踏み込みました。

推論が深くなったこと自体は成功です。

でも、その知見には、

現在の設計そのものを変更するauthorityを与えた覚えはありません。

ここで困りました。

過去のレビューで得た知見は、あくまで「こういう失敗パターンがあった」という参考情報のつもりでした。

ところがAIにとっては、それが現在の設計を変える根拠にもなり得ます。

ある作業で得た知見が、別の作業ではarchitectureを変更する理由として使われる。

するとKnowledge Baseに保存した情報が、事実上、設計authorityの一部を持ち始めます。

「参考情報なので従わなくていい」では解決しない

AIDD Skeletonでは、それまでにも責務の境界をかなり意識していました。

たとえば、

  • Requirements
  • Design
  • Testing
  • 実装
  • レビュー結果

は、それぞれ同じものではありません。

そこへKnowledge Baseを追加して、

Knowledge Baseは参考情報です。
正式な設計ではありません。

と書けば解決するかというと、そう単純でもありません。

AIはKnowledge Baseを読んだ時点で、その情報を推論の材料にできます。

「authorityはない」と書いても、

この過去の失敗を避けるなら、今回も構造を変えた方がよい

という推論そのものを止めるわけではありません。

逆に影響を弱くしすぎれば、今度はKnowledge Baseを持つ意味が薄くなります。

「いつ使ってよい知識か」を決められなかった

Knowledge Baseを本当に成立させるなら、少なくとも次のようなことを決める必要があります。

  • どの知識を保存するのか
  • どの範囲の作業で再利用できるのか
  • いつ読み込むのか
  • どのauthorityより弱いのか
  • 現在のSoTと食い違ったらどうするのか
  • 別プロジェクトへ持ち込んでよいのか
  • いつ古い知識として捨てるのか

だんだん、単なる「レビュー知見のメモ」ではなくなってきました。

かなり大きな仕組みです。

そしてConsumerでの比較では、Knowledge Baseによって推論が深くなる効果と同時に、現在の設計や責務境界へ与える影響も確認できました。

効果がないからやめたのではありません。

効果はある。でも、その効果の範囲を安全に境界づけられなかった。

そこでKnowledge Baseの導入は取りやめました。

最後のコミットがこれです。

docs: remove knowledge base governance

名前の通り、一度作ったKnowledge Base governanceを削除しています。

それでも「あとで考える場所」は必要だった

Knowledge Baseはやめました。

ただし、

Deferしたものをあとで再考したい

という最初の問題まで消えたわけではありません。

むしろKnowledge Baseを試したことで、必要なものの輪郭が少し見えてきました。

欲しかったのは、

過去の知識を何でも蓄積する場所

ではなく、

今はやらないが、条件が来たら再び扱うものを残しておく場所

だったのかもしれません。

知識そのものを蓄積するより、

あとで扱う仕事

として残した方が自然なのではないか。

そう考え始めると、今度は別の違和感が出てきました。

その置き場として使っていたディレクトリの名前です。

workbench/

「作業台」。

確かに最初はそんな場所でした。

でも、レビューで先送りしたものや、再開条件を持つものまで置くようになると、

もう単なるworkbenchではないのでは？

という話になっていきます。

そしてここから、AIDD Skeletonのディレクトリ構成そのものを見直すことになりました。

それは次の記事で書こうと思います。

関連リンク

AIDD Skeleton:

今回触れた主な変更:

※この記事は筆者自身の開発経験・判断・問題意識をもとに、生成AI（ChatGPT）との対話を通じて構成・文章化しています。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?