PRODUCT NOTE / AI エージェント・PM
同じ社内エージェントを、作る側ではなく通す側・測る側・畳む側から見た記録。
この文書は「どう作ったか」ではなく、何を断り、何を着手前に数え、何をもって終わりにしたかを残した開発ノートです。コードは 1 行も出てきません。
| ステータス | 実運用中（社内・非公開）。進め方を書籍にまとめた Vol.4『PoCで終わらせない AIプロジェクトの進め方』は 2026-09-22 発売 — 書籍ページ |
|---|---|
| 立場 | PM / PdM。スコープ・費用・関係者の 3 つを握ったまま現場に座れる側 |
| 反復の単位 | 6 つのゲート。前へ進む反復ではなく、後ろへ戻る反復として計画する（戻った回数を数える） |
| このノートの範囲 | 判断と書式だけ。実装・構成・固有名は載せない（技術側の判断は 設計のノート） |
| 最終更新 | 2026-10-03 |
| 関連 | Vol.4『PoCで終わらせない AIプロジェクトの進め方』 ・ 社内 AI エージェントの設計（技術観点） ・ エージェント実行テレメトリ（実測） |
AI 案件は発注できる形になっていない。仕様は現場の観察からしか出ず、価値は実データでしか測れないので、要件定義書を書いて渡す手順がそもそも成立しない。
進め方は 6 つのゲートに分けた ——誰の何が困っているか／やらない理由を先に 3 つ／データが存在するか実測する／最小で作って本番の一部に当てる／作る前に決めた式で測る／続ける・畳む・人に返す。
いちばん重いのは 2 つめと 3 つめで、ここを飛ばした案件は例外なく PoC で止まった。
直した対策が実際に本番で効いているかを確認する工程を、6 つのゲートとは別に足した。
エージェントを作る技術的な判断は別のノートにある。こちらで扱うのは、その前後にある「やるかどうか」と「終わったかどうか」の判断です。困っていたのは次の 4 つ。
3 つめについては、外の数字も同じ方向を指していた。Gartner は「生成 AI プロジェクトの 30% 以上が PoC の後に放棄される」と出している（2024-07-29）。
放棄の理由として挙がっているのも、データの品質・コストの見積り・価値の不明確さで、作る技術の話ではない。
要件を聞き取るのではなく、他人の一日を分で数えた。どの作業に何分かかり、どこで手が止まり、止まったあと誰に聞きに行くか。作るものはここから出てくる。
現場に張り付く権限は、もともと PM が持っている。スコープ・費用・関係者の 3 つを握ったまま現場に座れるのは PM だけで、そこを外注すると観察と判断が切れる。名付けるなら Forward Deployed Engineer（FDE）に近い働き方だが、肩書きや契約を変えたわけではない。
このやり方は速いが、観察した人しか仕様を知らない状態を作る。後半の「自分が抜けても回るか」は、その副作用に対する判断です。
前へ進む反復ではなく、後ろへ戻る反復として計画している。戻るのは主に 3 つめで、戻った回数を記録する。
現場に張り付いて観察する。作るものを先に決めない。
3 つ書けない案件は立上げない。書式があるので、通すときの説明にそのまま使える。
行数・有効行数・鮮度・到達権限の 4 つを数える。足りなければ 1 つめか 2 つめへ戻る。
PoC 環境で完成させない。本番の一部に当てて、業務が動くかで判定する。
式は着手前に合意しておく。
3 択で決める。畳み方を決めていないものは、続けるとも言わない。
各判断の裏にある「なぜ」を、決定・仮説・結果の 3 点で残す。うまくいかなかったことも書く。
PoC が溜まる原因は、終わらせ方ではなく始める判断が軽いことだと考えた。落とせないから資源が分散し、どれも本番に届かない。
断る材料を先に作ると、①立上げ自体の判定ができ、②通すときに「この条件なら成立する」という形で同じ材料を使える。やる理由から書くと、読む側は「では全部できるのか」を確かめる作業に入ってしまう。
やらない理由を自分の言葉で書けるのは、現場に張り付いて観察している側（FDE に近い立場）にいるから。要件を聞き取って渡される側だと、断る根拠を自分の中に持てない。
「データはあります」は、ほぼ常に「テーブルはあります」の意味だった。行はあるが肝心の列が空、更新が半年前に止まっている、自分の権限では読めない —— このどれかで計画が崩れる。
崩れるのが着手後だと引き返す道が無く、体裁を保つために PoC を続けることになる。数えるコストは数時間で、外れた計画の損より安い。
機能の反復は前へ進む前提で見積る。データの反復は戻る。
戻りを計画に書いていないと、戻るたびに「遅れ」として扱われ、全ての見積りが外れる。戻ること自体は設計通りなので、回数を数えて予定に織り込むほうが筋が通る。
単価で計算すると必ず外れる。実際に効くのは 1 回のやりとりに積んでいる文脈の量で、題材のシステムではプロンプトが約 16 万字まで育っていた（経緯は設計側のノート）。
もう 1 つは同時に走る他案件との枠の競合で、これは自分の案件の設計では動かせない。どちらも単価の外側にある。
できることから書くと、読む側は「では全部できるのか」を確かめる作業に入り、説明が長くなるほど疑わしくなる。それより、止める条件が書いていない案件は決裁側から見ると終わりが無いのが問題だと考えた。
社内向けでも「買う理由」は要るので、範囲の表が事実上の価格表になる。
単価を推定すると、数字の出どころを聞かれた時点で全体が崩れる —— 推定の根拠を説明するコストが、効果そのものの説明より大きくなる。
申告なら出どころが明確で、信頼度を別に持てば粗さも扱える。
生成は速くなったが検証は速くならない。人の誤りは間違って見えるが、AI の誤りは正しく見える。
由来を免責にできると、忙しいときに検証を飛ばす動機が生まれ、速くなった分だけ損が増える。文面で完了を判定するのも同じ問題で、文面を満たしていても困りごとが消えていない場合がある。
レビューの落とし穴をチェックリストにして、完了条件の型と一緒に置いた。「AI が書いたので」は説明として通らないという扱いが定着した。
技術側では、外へ出る手前で判定を止める仕掛け（三値判定）が対応している。
観察から作る進め方は、観察した人しか仕様を知らない状態を作る。その状態のまま数を増やすと、増えた本数がそのまま止まるリスクになる。
横展開を成功の形に置くと、早すぎる共通化で間違った抽象を固めるほうへ動きやすい。共通化の判断は、同じ形が 3 件出るまで待つことにした。
同じ種類の対策を複数回足していたのに、どれも本番の設定には反映されていなかった。直らない理由は反映する手間ではなく、確認する工程そのものが誰のタスクにも載っていなかったことだった。
同じ事故が繰り返されることについて、依頼者から「なぜまた起きるのか、根本から見てほしい」と率直に問われたことが、この工程を足す直接のきっかけになった。
| 項目 | 決め方 | なぜこうしたか |
|---|---|---|
| 受益者 | 実際に使った人を数える。部署単位で丸めない | 部署で丸めると、使っていない人の時間まで効果に入る |
| 業務カテゴリ | 作業の種類で割る。案件名で割らない | 案件名で割ると、横展開のときに足し合わせられない |
| 期間 | 着手前に区切りを決める。延ばさない | 後で延ばせると、良い月だけ選べてしまう |
| 単価 | 推定しない。本人に申告させる | 推定は出どころを聞かれた時点で崩れる |
| 信頼度 | 式とは別に添える。粗い数字は粗いと書く | 粗さを式の中に隠すと、全体が信用されなくなる |
測れないものは測れないと書く。ここで無理に数字を作ると、次の案件の見積りまで汚れます。
題材は社内で運用しているシステムです。社名・人名・製品名は記載していません。本ノートは実務上の判断の整理であり、特定の進め方を推奨するものではありません。引用した外部の数字は出典・発表日を併記しています。
