AIに最新情報を拾わせて、採用するか捨てるかまで判断させてみた

AIに、最新情報を拾わせるところから、今の運用に採用するか捨てるかの判断まで任せてみた。

拾うことと、仕分けることはできた。6件の候補を今の運用に照らして、採用1件・部分採用2件・不採用2件・保留1件に分けた。それぞれに「なぜそう判断したか」も残せた。

ただ、採用と判断したものも、そこで確定はしなかった。今の運用は「提案する役」と「承認する役」を分けてある。AIにできるのは、根拠をそろえた提案を出すところまでで、最後のGOは人間が出す。

だからこれは「AIが自分で技術を選べた」という話ではない。AIは決められた場所で止まった。

きっかけ・仮説

複数のAI環境を使っていると、外から拾った情報が手元にどんどん溜まる。新しいツール、他社の運用、話題のやり方。溜めるだけなら難しくない。問題は、そのうちどれを実際の運用に入れて、どれを捨てるかだ。

この仕分けを人間が全部やると、溜まる速度に追いつかない。

そこで、拾う → 今の運用と照らす → 採用か不採用かまで判断する、をAIにやらせた。

仮説はこうだ。「今の運用の正（ルールや設計の文書）がそろっていれば、AIは新しい情報をそれに照らして、採用か不採用かまで判断できる」。

言える範囲と言えない範囲も先に決めた。言えるのは、6件という少数の候補について、1セッションで1人が回した結果だけ。長く続くのか、もっと多い件数でも回るのか、判断の精度が高いのかは言えない。定量指標は用意していないので、書くのはその範囲で分かったことに限る。

やったこと（検証方法）

手順は4つ。

1. 拾う。すでに手元に溜めてあった情報の置き場（8月に仕分けたブックマーク73件ほか）から、今の運用に関係しそうな候補を6件抜き出した。
2. 物差しを決める。今回使ったのは6つ。具体的か / 今の運用と整合するか / コストに見合うか / 弱点をふさぐか / すでにある決定を壊さないか / やりすぎ（何でもルールに足す）になっていないか。
3. 照らす。6件それぞれを、今の運用の正（役割分担の設計文書、共通ルール、決定台帳）と突き合わせた。
4. 判定する。採用 / 部分採用 / 不採用 / 保留 の4段階で判定し、それぞれに理由を1文以上つけた。

一次情報の本文（元記事そのもの）には、今回は直接アクセスしていない。手元の要約をもとに判断し、確認できていないものは「保留」寄りに倒した。

候補	今の運用のどこに関わるか	判定	ひとことの理由
機械で判定できるルールは自動チェックへ、判断が要るルールは指示文へ分ける	完了条件の検証方法	部分採用	分ける考え方はすでに一致。自動チェックへの落とし込みだけ取り込む余地
他社のAI自走化のPoC設計思想	仕組み全体（完了条件の契約・判断根拠の蓄積）	不採用	同じ考え方を今の設計ですでに持っている。新しく足す利得が薄い
要件定義の抜け漏れを検出するツール	計画役の工程	部分採用（候補登録）	かみ合う。ただし中身を確認してから。次の記事以降で検証
実装の前に、まず既存の作りものを探す	着手前の判断	採用	「同じものを別の場所に作る」失敗に直接効く。足す量も小さい
習熟度ランク別に権限を段階制御する設計	役割ごとの権限	不採用	権限はすでに固定で分けてある。1人運用にランク制御は過剰
別モデルに設計書のクイズを作らせて曖昧さを検出	確認役の工程	保留	効くかもしれないが、中身と費用対効果が未確認

起きたこと（検証結果）

判定は4段階に分かれた。採用1・部分採用2・不採用2・保留1。全部が「採用」にも「不採用」にも寄らず、物差しごとに違う結論が出た。

ひとつ目は採用したケース。「実装の前に、まず既存の作りものを探す」という判断基準を、着手前のチェックに1項目入れる提案をまとめた。これは以前、同じ目的の仕組みを別の場所に二重に作ってしまった失敗（別の記事で扱った）に直接効く。

ただし、ここで話は止まった。AIができたのは、提案の文面と、どこに足すかの差分案を作るところまでだ。実際に運用へ反映するかどうかは、人間の承認待ちになっている。

ふたつ目は不採用にしたケース。他社のAI自走化のPoCで語られている「判断根拠をためてAIを自走させる」という考え方は、新しく取り込まなかった。同じ考え方は、今の運用の完了条件の契約や、決定を「提案」と「承認」に分ける仕組み、情報を段階で分けて管理するやり方で、すでに実装されているからだ。「良さそうだから全部足す」を避けた。

わかったこと

拾って仕分けるところまでは、AIにやらせて成立した。今の運用の正がそろっていれば、新しい情報をそれに照らして「これは採用、これは不採用」まで持っていける。

一方で、採用の確定はできなかった。というより、できない設計にしてある。「提案する」と「最後に決める」を分けてあるので、AIの出力はどれだけ根拠がそろっていても「提案」で止まる。

これは今回に限れば良かった。AIが自分で「採用」と決めて運用に反映してしまうと、後から「なぜ入れたのか」を追えなくなる。止まる場所が決まっていたおかげで、判断の中身を人間が確認できる状態で残った。

n=6・1セッションなので、判断の精度は測れていない。6件のうち、はっきり判断できたのは4件。1件は「中身を見てから」の保留で、もう1件は部分採用の粒度の調整が残った。

実際どうなん？（まとめ）

最新情報を拾って、今の運用に採用するか捨てるかを判断させるのは、ある程度できた。

ただし「AIが運用を決めた」わけではない。採用と判断したものも、人間の承認を待って止まっている。今の答えは「拾う・仕分けはできた。採用の確定には人の承認が要る設計なので、AIは根拠つきの提案で止まる。止まる場所が決まっているのは悪くなかった」。

補足・注記

この記事で扱ったのは、手元に溜めた情報をAIに仕分けさせる取り組みだけだ。複数のAI環境をまたいで情報を共有する仕組みは別の記事で、ひとつのAI環境の中で企画・実装・確認の役割を分ける取り組みは別の記事で扱っている。「提案する役」と「承認する役」を分ける設計は、後者と地続きだ。