AI PMのROI：月3〜5万円と、無駄にした19周

いま起きていること

AIの運用費は、思ったより安く済んだ。そして、思ったより簡単に無駄が積み上がった。

パンダオフィスのAI社員4名（役割を分けたAIの担当者）の運用コストは、2026年2月の時点で月3〜5万円だった。内訳は、Claude Code の MAX プランが月 $200（約3万円）、その他の API 費用とツール・インフラ費用である。

（出典：自社ブログ記事「AI社員4名の実稼働レポート」2026-02-22）

この金額は、人件費と比べれば小さい。ただ、この数字にはAIの利用料しか含まれていない。人の時間は入っていない。

一方、同じ1年のあいだに、費用が目に見えないところで積み上がる出来事がいくつもあった。

1. レビューを19周した。 2026年8月22日、1本の保守用スクリプトのレビューを数えると19周していた。指摘は合計48件。重大度「高」の指摘は5周目でゼロになっており、残りの14周は軽微な指摘だけだった。原因は私のプロンプトにあった。「重大・高がゼロになったら承認」という規約に、私が「Aランク（90点以上）まで」「フォローアップを残さず」と書き足していた。AIはその言葉に忠実に、軽微な指摘を探し続けた。

2. 毎回、約45,000トークンを読み込んでいた。 AIが会話を始めるたびに読む設定の量である。特定のファイルを触るときだけ読ませるつもりの条件が、別の書き方で打ち消されていた。置き場所を3つに分けて、約12,000トークンにした。

（出典：自社の調査記録 2026-08-22〜23）

3. 失敗したビルドにも課金された。 Web サイトのホスティングの追加課金は、8月が51ドル、9月1日から2日の2日間で40ドルだった。検証用の環境に必要な設定値が1つも入っておらず、ビルドが毎回失敗し、長いものは45分走っていた。

4. 画像の再生成で、2日で約5,000円を使った。 2026年7月、画像生成AIで、気に入らないコマを個別に何度も作り直した。グリッドで1回生成すれば数十分の1で済む作業だった。前払いの残高が尽きて、初めて気づいた。

5. 手戻りが、新規の作業を超えた。 ある受託案件で、手戻り率が、6月10%、7月13%、8月169%と推移した。

（出典：自社の請求記録・調査記録・案件記録 2026-07〜09）

外部の調査にも、同じ傾向が出ている。McKinsey の2026年の調査では、約5社に1社で、AIの運用コストが利用の制約になり始めていた。また、80%が「AIで自分の生産性が上がった」と答える一方、利益（EBIT）にプラスの寄与があった組織は37%で、前年からほぼ横ばいだった。

（出典：McKinsey「The state of AI in 2026: On the road to ROI」2026-08-25）

PMの仕事で何が変わるか

従来のROIは、「導入費用に対して、どれだけ効果があったか」を測る計算だった。AIでは、費用が使うたびに発生する。確認を足す指示も、読み込む設定の量も、失敗した処理も、すべてそのまま費用になる。

PMの仕事は、単価の交渉から、消費の設計に移った。

• 単価（月額）は、ほぼ決まっている。変わるのは、使い方で決まる消費量である。
• 消費は、AIに指示した言葉の影響を受ける。「Aランクまで」と書き足しただけで、14周が追加された。
• 無駄は、測らないと見えない。8月まで、約45,000トークンの読み込みも、19周のレビューも、「なんとなく重い」で済ませていた。

この2つ目のポイントは見落としやすい。この時期に使っていたモデルは、公式に「応答が長くなる」「頼まなくても検証する」と挙動の変化が明記されていた。単価が変わらなくても、消費量は増える。確認を足す指示は、そのまま費用になる。

PMBOK-AIではこう扱う

1. 費用は、AIの利用料だけでなく、人の時間も含めて見る。 月3〜5万円はAIの利用料である。AIが速く実装を上げてくるほど、レビューと判断の往復は途切れなくなり、人の時間は減らない。

2. 判断の重さで、モデルを使い分ける。 深い判断が要る仕事には上位のモデル、範囲のはっきりした日常業務には軽いモデルを当てる。2026年9月に発表された Opus 5.5 は、判断が要る複雑な仕事向けで、Opus 5 より約40%安い。同月発表の Sonnet 5.5 は、範囲のはっきりした日常業務向けで、Sonnet 5 より30%以上速く、最大30%安い。モデルは名前ではなく役割で選ぶ。

（出典：Anthropic「Claude Opus 5.5」2026-09-22、「Claude Sonnet 5.5」2026-09-28）

3. レビューには、止める条件と上限を置く。 重大・高の指摘がゼロになったら終了する。上限は3周。「Aランク」のような基準を後から足さない。軽微な指摘は、別の課題として残す。

4. 毎回読み込むものを、定期的に測る。 置き場所を「いつも要る」「ファイルごとに要る」「作業ごとに要る」の3つに分ける。

5. 失敗した処理を打ち切る。 ビルドは15分で打ち切るようにし、費用の監視を常駐プロセスから Slack に流した。さらに、費用の上限に達したら本番の配信を止める設定が、既定で有効になっていた。同じ契約には取引先の本番サービスも同居していて、上限に達した瞬間に無関係な取引先の本番まで止まる。費用を守る設定が、もっと大きな事故の引き金になりうる。この設定は、必ずオフにする。

6. 大量の生成は、枚数と概算を出して承認を取る。 画像生成は、グリッドで1回生成するのを既定にした。作り直す前に、枚数と概算費用を提示する。

7. トークンの節約は、効きどころを選ぶ。 2026年10月には、推論の深さを一段下げる、サブエージェントには軽いモデルを使う、報告は20行以内にする、という節約を入れた。確かめる場面は、数字の出典、最新の情報、過去の記録、完了の報告の4つに絞った。

（出典：自社の運用記録 2026-10-07）

SLA（サービス水準）についても一言添える。AI社員の応答時間や解決率の目標値を決める前に、止める条件と上限を決めたほうがよい。数字の目標は、測ってから置く。測っていない目標値は、単なる願望である。

AIに何を任せるか、AIプロジェクトマネジメント実践ガイドも合わせて参照してほしい。

明日からやること

• AIの費用を、利用料と人の時間に分けて書き出す
• 毎回AIが読み込む設定の量を測り、置き場所を3つに分ける
• レビューに「重大・高ゼロで終了、上限3周」の規則を入れる
• 失敗した処理の打ち切り時間（ビルドなら15分）を設定する
• 費用の上限設定が「止める」になっていないか確認する。取引先の本番と同居しているなら、オフにする
• 大量の生成は、枚数と概算費用を出してから実行する

まとめ

AIの単価は安い。ROIを決めるのは、消費の設計である。確認を足す指示も、読み込む設定も、失敗した処理も、そのまま費用になる。測って、削って、止める条件を先に置く。