AIエージェント導入は、まず「作業」ではなく「レビュー」から始める

AIエージェントを業務に入れたい。
そう考えたとき、多くの人は「どの作業を自動化するか」から考えます。

でも、実務ではこの順番だとうまくいかないことが多いです。
理由はシンプルで、AIに作業を任せる前に、人間側のレビュー基準が整理されていないからです。

何をもって良しとするのか。
どこを見て、何を直すのか。
その判断基準が曖昧なままでは、AIに作業させても品質は安定しません。

そして現場では、こんな光景が起きがちです。

AIが作ったコードや文書を、人間が渋い顔をして一行ずつ直している。
これなら自分で書いたほうが早かった……という、あの絶望感です。

これはAIが使えないというより、AIに「何を良しとするか」をまだ渡せていない状態です。

だから、私が勧めたいのは逆の順番です。

まずレビューをAI化する。
そのうえで、少しずつ作業そのものをAIに任せていく。

この進め方の方が、現場では圧倒的に成功しやすいと思っています。

AIエージェントに必要なのは「自律」と「知識」

AIエージェントを考えるときに重要なのは、大きく2つあります。

ひとつは、自律的に動けること。
もうひとつは、必要な知識にアクセスできることです。

単に一度指示されたことを実行するだけでは、業務では使いにくいです。
AIエージェントには、

自分が何をしないといけないか整理する
タスクを分解する
必要な情報を取りに行く
進捗や不足を見ながら次の行動を決める

といった動きが求められます。

つまり、AIエージェントの本質は「賢い自動実行」ではなく、
知識を使いながら、自律的に仕事を前に進めることにあります。

AIエージェントは「計画→実行→レビュー→修正」で回る

AIエージェントの動作は、基本的に次のサイクルで考えると分かりやすいです。

計画を作る
実行して成果物を作る
成果物をレビューする
レビュー結果をもとに修正する

このループを回すことで、成果物の品質を徐々に上げていきます。

ここで一番重要なのは、実は「実行」ではありません。
一番重要なのはレビューです。

なぜなら、AIは最初から完璧なものを出すわけではないからです。
むしろ現実には、出して、見直して、直していく前提で考えた方がうまくいきます。

だからこそ、レビューの質がそのままAI活用の質になります。

いきなり作業エージェントを作ると失敗しやすい

AI導入でありがちなのが、いきなり「作業代行AI」を作ろうとすることです。

でも実際には、作業は状況依存が大きく、ばらつきも多いです。
現場ルール、暗黙知、例外処理、ツール制約などが一気に乗ってきます。

その結果、

思ったより精度が出ない
人が毎回全部見直す
結局、手間が減らない
現場で使われない

という流れになりがちです。

問題は、AIが悪いというより、先に品質基準を渡していないことです。

先に作るべきなのは「レビューAI」

先に作るべきなのは、作業用AIではなくレビュー用AIです。

これはかなり重要です。

作業そのものは複雑でも、レビュー観点は比較的言語化しやすいことが多いです。
たとえば、人が成果物を見るときには無意識にこう考えています。

前提条件は揃っているか
抜け漏れはないか
利用者に誤解を与えないか
この構成で本当に運用できるか
説明の順番は自然か

こうした観点をAIに持たせるだけでも、かなり価値があります。

まず作業者がレビューAIでセルフチェックする。
その後、人が最終レビューする。
これだけでもレビュー工数は下げられます。

さらに大きいのは、レビュー観点がそのまま作業AIを育てる土台になることです。

レビュー観点は「会話」から作れる

ここが一番大事なポイントです。

レビュー観点は、最初から机の上で完璧に設計しなくてもいいです。
むしろ、実際のレビュー会話から抽出する方が現実的です。

複数人でレビューしているなら、その打ち合わせを文字起こしする。
すると、実際の現場で何を見ているかがそのまま残ります。

たとえば、こんな発言です。

「この前提が書かれていないと後続が困る」
「この図だと責任範囲が曖昧」
「ここは利用者視点で読むと分かりにくい」
「この説明順だと誤解されそう」

こういう発話は、そのままレビュー観点の原石になります。

1人でレビューしている場合でも同じです。
頭の中だけで判断せず、あえて声に出してレビューする。
それを文字起こしすれば、自分の暗黙知を取り出せます。

つまり、レビュー観点を作るとは、
人が無意識にやっている判断を、AIが使える形に変換することです。

そしてこれは、技術的に見るとさらに重要です。
レビュー観点を言語化することは、そのままAIへの「システムプロンプト」や「Few-shot（例示）」を作成することとほぼ同義です。

普段の会話やレビューコメントを残しておくだけで、
「このAIには何を重視させるか」
「どういう観点で良し悪しを判断させるか」
という最強の指示書が、少しずつ蓄積されていきます。

レビューAIをどう作ればよいか分からない、という不安はもっともです。
でも実際には、ゼロから難しい設計をする必要はありません。
普段のレビュー会話を拾い上げること自体が、すでにAI設計の第一歩になっています。

第一歩は「レビューの効率化」でいい

ここで大事なのは、最初から大きくやろうとしないことです。

まずは、レビュー観点を抽出する。
次に、それを使ってレビューAIを作る。
作業者がそのレビューAIでセルフチェックする。
最後に人が確認する。

この流れだけでも十分に価値があります。

しかも、人が最終レビューした内容もまた蓄積できます。
それを文字起こしし、レビュー観点として再抽出すれば、レビューAIの精度をさらに上げられます。

つまり、レビューAIは一発で完成させるものではなく、人のレビューを取り込みながら育てていくものです。

この始め方のいいところは、効果が見えやすいことです。
いきなり全部自動化しようとするより、導入しやすく、現場にも受け入れられやすいです。

AI導入も「スモールバッチで回す」アジャイルなプロセスでいい

ここも強調したいポイントです。

AI導入というと、大きな仕組みを最初に設計して、一気に定着させないといけないように感じるかもしれません。
でも、実際はそんなに構えなくていいと思っています。

むしろAI導入も、
小さく試して、フィードバックを得て、改善して、また回す
というスモールバッチの発想で進める方が自然です。

言い換えると、AI導入そのものがアジャイルなプロセスです。

最初はレビューだけ。
次に文章作成。
その後に図や周辺作業。
少しずつ広げながら、チームの中で「どこまでAIに任せるとちょうどよいか」を学習していく。

この進め方には、単なるツール導入以上の意味があります。
それは、チームとしてAIをどう育てるか、どう付き合うかという文化を作ることです。

AIは入れた瞬間に完成するものではありません。
現場の判断基準、言葉の癖、品質の感覚を吸い上げながら、徐々に戦力になっていきます。
だからこそ、いきなり完璧を目指さない方が、結果的には早いです。

作業AIは「実用化の見通しがあるもの」から作る

レビュー基盤ができたら、次に作業用AIを考えます。
ただし、ここでも対象選びが重要です。

最初に選ぶべきなのは、
導入しやすく、効果が高く、ROIが固い業務です。

逆に、最初から避けた方がよいのは、たとえばこういうものです。

特定のGUIツールを使わないと成立しない
画面操作が複雑で環境依存が強い
セキュリティや運用制約が重い
例外処理が多すぎる

もちろん、PC操作をAIにさせる方法もあります。
ただ、現場では制約が強く、使いづらいことも多いです。

だからこそ、最初は「できそうなもの」に絞るべきです。

例：詳細設計書の作成をAIに任せるには

たとえば、詳細設計書の作成を考えてみます。

前提はこんな感じです。

基本要件は整理済み
方向性はある程度見えている
最終成果物はエクセル方眼紙
図も含める必要がある

この条件を見ると、「全部まとめてAIにやらせるのは厳しい」と感じると思います。
実際、その通りです。

だから、ここでも分割します。

まずは文章部分からAIに任せる

詳細設計書の中でも、文章部分は比較的AIと相性が良いです。

過去の成果物を見せて、

どんな観点で書かれているか
どの粒度で整理されているか
書くべき項目は何か

をAIに抽出させる。
そのうえで、作成手順や記載方針をAIに作らせます。

ここで重要なのは、その手順を案件専用に閉じないことです。
別プロジェクトでも使えるように汎用化しておくことが大事です。

これは、単発の自動化ではなく、再利用可能なSkillを作ることでもあります。

文章は「作るAI」と「レビューするAI」で回す

文章をAIに作らせたら、次にレビューAIで確認します。

抜け漏れはないか
前提条件は明確か
読み手が困らないか

こうした観点でレビューし、指摘が出たら再修正する。
これで「作る→見直す→直す」のループが回り始めます。

この状態になると、作業AIはかなり実用的になります。
人はゼロから作るのではなく、最後の確認と判断に集中できます。

エクセル反映は最初から無理に自動化しなくていい

詳細設計書で厄介なのが、エクセルへの転記です。

もちろん、AIで直接扱える環境や変換手段があれば自動化もできます。
ただ、ここに時間がかかりそうなら、最初は人が貼り付けて整えるだけでも十分です。

この考え方はかなり大事です。

AI導入では、「そこも自動化しないと意味がない」と考えてしまいがちです。
でも実際には、一部だけでも工数が大きく減るなら、それで十分に価値があります。

全部自動でなくていい。
まずは、AIが得意なところから任せればいいです。

図の作成も「下書きはAI、仕上げは人」でいい

図も同じです。

アーキテクチャ図のようなものは、AIで下書きを作れることがあります。
ただ、そのまま実務で使える品質になるとは限りません。

その場合は、人が仕上げればいいです。

ここでも重要なのは、無理に全部AIに寄せないことです。
むしろ、

下書きはAI
仕上げは人
仕上げた図をAIがレビュー

という分担の方が現実的です。

しかも最近は、AIの画像認識能力も上がってきているので、
図に対してもレビュー補助を入れやすくなっています。

「結局、人の仕事が残る」のでいい

ここまで読むと、こう思うかもしれません。

「結局、細かい面倒な作業は人に残るのでは？」

答えは、はいです。
少なくとも初期段階では、その通りです。

でも、それで問題ありません。

AI導入で大切なのは、最初から100点の完全自動化を目指すことではなく、
費用対効果が高い部分から順番に置き換えることです。

人がやった方が早い作業が残る。
それはむしろ自然です。

その部分は人がやればいいし、場合によっては外部パートナーに依頼してもいい。
大事なのは、AIで大きく削れるところを先に削ることです。

成功する導入は「導入して回収し、次へ進む」

うまくいくAI導入は、だいたい同じ流れになります。

まず、レビューをAI化する。
そこで浮いた工数を使って、文章作成の一部をAI化する。
次に、図や周辺作業へ広げる。
その後で、さらに細かい工程の自動化を検討する。

つまり、

導入して回収する。
導入して回収する。
これを繰り返す。

この感覚がとても重要です。

初期コストはかかります。
でも、段階導入にしておけば、回収までの期間を短くしやすいです。
結果として、費用圧迫も抑えやすくなります。

ツール選定より先に、設計思想を決める

最後にひとつ大事なことがあります。

この話の本質は、どのツールを使うかではありません。

Google系でもいいし、Microsoft系でもいい。
必要なら文字起こし、図作成、ワークフロー、表計算のツールを組み合わせればいいです。

本当に大事なのは、次の設計です。

レビュー観点が言語化されているか
AIが必要な知識にアクセスできるか
計画→実行→レビュー→修正のループが回るか
人とAIの役割分担が現実的か
ROIが固いところから導入できているか

ここができていれば、ツールは後から選べます。

まとめ：AIエージェント導入は「レビュー設計」が起点になる

AIエージェントを現場で使える形にしたいなら、
いきなり作業の完全自動化を目指さない方がいいです。

まずやるべきなのは、レビュー観点を整理することです。
その観点は、打ち合わせやレビュー時の会話から抽出できます。
そして、その観点を使ってレビューAIを作る。

そこから、

レビューを効率化する
作業を分割する
AIに向く部分から任せる
残る作業は人が担う
改善を繰り返す

という流れで広げていけばいいです。

AIエージェント導入で大切なのは、
全部を一気に変えることではありません。

まずレビューをAI化する。
そこから始めるのが、現場ではいちばん現実的で、いちばん強い進め方だと思います。
本ブログが誰かの役に立つことを祈ってます。✧٩(ˊωˋ)و✧*