AI生成コンテンツのレビューでは、感覚的な違和感が最後まで解消されないことがあります。GMOコネクトの事例では、点検表を249項目まで育てても指摘がすり抜けました。答えは、感想を数えられる条件に翻訳し、機械検査で担保することです。ここでは、249項目のうち**107項目(43%)**を機械検査化した手順と、法人がAIレビュー体制を構築する際に押さえるべき視点を扱います。
AIレビューとは
AIレビューとは、AIエージェントや生成AIを使って文書やコードの品質を点検する仕組みです。人手のチェックリストと自動検査を組み合わせ、指摘の抜け漏れを減らす手法です。近年は企業のAI活用が進み、レビュー体制の整備が課題になっています。
この記事のポイントは次の通りです。
- GMOコネクトの事例では、点検表が16項目から249項目まで拡大しても指摘がすり抜けました
- 感想を「数えられる条件」に翻訳する手順は、何を数えるか/どこで数えるか/何を数えないかの3つです
- 機械検査に落とし込めたのは249項目中107項目(43%)で、残り6割は目視が必要でした
- 「検査自体を検査する」という前提が、抜け漏れの再発防止に有効でした
- 法人がAIレビュー体制を構築する際は、チェックリストの増加だけに頼らない設計が求められます
言語化だけでは止まらなかった理由
GMOコネクトのエンジニアは、AIエージェントに仕事をさせるためチェックリストをMarkdownで持たせる手法を実践しました。約100枚のスライド資料を1か月かけて作成する間、レビューで出た指摘を型にして書き足し続けました。
点検表は2週間目に16項目から始まり、3週間目には「1枚単位」と「全体の流れ」の2本立てで249項目まで拡大しました。同じ週に、この点検表を25体のAIエージェントに渡してレビューさせたところ、336件の指摘が出ました。
しかし、4週間目に1枚ずつ読み直すと、点検表には無い観点がさらに14件見つかりました。項目を増やしても、すり抜けは止まりませんでした。
16項目で点検した段階の結果が、この状況を端的に示しています。形式的な検査は全ページで0件通過していましたが、章の並びやパーツの用途を人が見ると、16項目のうち11項目が全ページで未達、または半数以上のページで未達でした。同じ原稿に対して、機械の検査と人の検査で全く異なる結果が出たことになります。
AIレビューをすり抜ける「なんか妥当じゃない」の正体
すり抜ける指摘の多くは、事実誤りではありませんでした。書いてある内容自体は正しいのに、その文がそこにある目的を果たしていない、という性質の問題です。
近い切り分けは、RAGの評価フレームワークであるRagasにも存在します。RagasのFaithfulnessは、文脈に対する事実的な整合性を測定する指標です。一方で**Answer Relevancy(Response Relevancy)**は、生成された回答が質問に直接応えているかを評価する指標です。
文脈には忠実でも、質問の意図に応えていなければ実務では役に立ちません。ハルシネーション対策で捕まえられるのは前者だけであり、今回すり抜けていた指摘は後者の性質を持つものがほとんどでした。
途中で作成した検査ツールには、ページ挿入時に章内の参照番号がずれる問題への注意書きが残されていました。ところが、その注意書きを書いた本人が、同じ日に別の箇所で同じミスを起こしていたことが記録されています。注意書きだけでは防げないため、数える仕組みに置き換える必要がありました。
3日後に1枚ずつ読み直して見つけた指摘は、実は3日前のレビューで既に重大度「高」として出ていたものでした。指摘そのものの検出はできていても、直り切ったかどうかを誰も検査していなかったことが分かります。
「数えられる条件」へ翻訳する3つの手順
機械化のためにやることは1つだけです。感想を、数えられる条件に翻訳することです。手順は次の3つに整理できます。
手順1 何を数えるかを決める
「誰の話なのか読めない」という感想は、各ページの要点3行を全件集めて主語と文末の形を判定する形に置き換えました。要点185件を調べたところ、主語なしが183件(99%)、敬体はゼロという結果でした。印象ではなく、数字として問題の大きさが可視化されました。
締めの1文が資料の材料から出ているかという感想も、締めと自ページの重なりを他ページとの重なりと比較する形に翻訳しました。締めを持つ47枚のうち、重なり不足を検出したのは2枚で、誤検出は0件でした。
手順2 どこで数えるかを決める
「4行以上の段落は列挙にする」という基準は、原稿の文字数ではなく、ブラウザで開いた際の実測の高さを行送りで割って行数を出す方法に変えました。この検査を11ページ12段落に適用したところ、該当は0件でした。
手順3 何を数えないかを決める
「1ページで同じことを3度言わない」という基準は、段落と表のセルを3-gram Jaccardで総当たりする検査に置き換えました。ただし、表を要約する締めの文まで重複として拾うと誤検出になるため、その部分は数えない対象として除外し、実質3件の検出にとどめています。
前提:検査自体を検査する
これら3つの手順の前提として、検査の対象範囲そのものを疑う工程が必要でした。検査に「何枚見たか」を印字させ、実物の枚数と突き合わせる仕組みを入れたところ、章ファイルの1つの抜けが見つかりました。この抜けは、記録上5回再発していた型でした。
具体的な数値で見る機械化の効果
今回の取り組みで得られた数値を整理すると、以下のようになります。
| 項目 | 結果 |
|---|---|
| 点検表の項目数の推移 | 16項目 → 249項目 |
| 機械検査に落とせた項目 | 107項目(全249項目中43%) |
| 要点185件の主語判定 | 183件(99%)が主語なし |
| 要点185件の文末判定 | 敬体は0件 |
| 締めを持つページ47枚の検査 | 2枚で重なり不足を検出、誤検出0件 |
| 段落の行数判定(11ページ12段落) | 該当0件 |
| 検査自体を検査した結果 | 章ファイルの抜けを1件発見(5回再発した型) |
249項目のうち107項目(43%)という数字は、裏を返せば残り6割は目視でしか検査できないことも示しています。機械化はレビューの負担を減らしますが、すべてを代替するものではありません。
AIエンジニアアカデミーの現場から見えること
AIエンジニアアカデミーの法人研修を担当する中でも、似た壁にぶつかる企業を数多く見てきました。多くの現場では、レビューの指摘が出るたびにチェックリストへ追記する運用が先行し、項目数だけが膨らんでいく傾向があります。
受講生や卒業生からの相談でも、「チェックリストを増やしたのに同じ指摘が繰り返される」という声は珍しくありません。今回の事例のように、感想を主語・文末・重複といった数えられる単位に分解し直す作業は、属人的な言語化スキルよりも、検査設計そのものを見直す力を必要とします。
AIエンジニアアカデミーの研修プログラムでは、生成AIの活用スキルだけでなく、こうしたレビュー基準の形式知化や検査プロセスの設計を、実践課題を通じて扱う場面があります。組織にAIレビューを定着させるには、ツール導入以上に、この種の地道な翻訳作業を担える人材の育成が鍵になると感じています。
AIレビュー体制構築で押さえるべきポイント
言語化だけでは、AIレビューのすり抜けは止まりません。GMOコネクトの事例では、点検表を16項目から249項目まで育てても、指摘は残り続けました。
有効だったのは、感想を「何を数えるか/どこで数えるか/何を数えないか」という3つの手順で数えられる条件に翻訳する作業です。その結果、**249項目中107項目(43%)**を機械検査に落とし込むことができました。
一方で、残り6割は目視に頼らざるを得ない領域として残ります。法人がAIレビュー体制を構築する際は、機械化できる範囲と人手が必要な範囲を切り分け、検査自体を検査する仕組みまで含めて設計することが重要になります。
よくある質問
Q1. AIレビューを導入しても指摘がすり抜けるのはなぜですか。
A. すり抜ける指摘の多くは事実誤りではなく、文がそこにある目的を果たしていないという性質の問題です。感想のままでは検査条件として機能しないため、数えられる形に翻訳しない限り、機械検査では捕まえられません。
Q2. チェックリストの項目数を増やせば精度は上がりますか。
A. 今回の事例では、点検表を16項目から249項目まで拡大しても、すり抜けは止まりませんでした。項目を増やすだけでは、全件を毎回突き合わせる担保にはならないためです。
Q3. 「数えられる条件」に翻訳できない指摘はどう扱えばよいですか。
A. 今回の事例でも、249項目のうち機械化できたのは107項目(43%)にとどまり、残りは目視での確認が必要でした。翻訳できない項目は無理に機械化せず、人によるレビュー工程として明確に残すことが現実的です。
Q4. 「検査自体を検査する」とは具体的に何をすることですか。
A. 検査に「何枚見たか」といった対象範囲そのものを印字させ、実物の数量と突き合わせる工程を指します。今回の事例では、この工程によって章ファイルの抜けが1件見つかり、記録上5回再発していた型であることが判明しました。
法人向けのAI人材育成・研修導入をご検討の場合は、AIエンジニアアカデミーの法人研修プログラムについてお気軽にご相談ください。