/note/tech

AIは回せば回すほど凄いのか ―「常時稼働」という設計の敗北

要約:

■ 1. 「AI常時稼働」言説への違和感

  • AI常時ぶん回しへの疑問:
    • AIエージェントを24時間動かして開発を完全自動化した、という投稿がSNSに溢れている
    • 寝ている間もAIがコードを書き続ける、AI社員を常時稼働させ量産中、といった発信は伸びやすい
    • 現役の開発者としてAIを日常的に使う立場から、そこまで回す必要があるのかという疑問が残る
  • 「凄そうに見せる」商売の構造:
    • AIで派手なことをやっているように見える投稿はインプレッションを稼ぎやすい
    • その注目はフォロワー増加、有料noteの販売、PV収益に直結する
    • 実際に成果が出ているかとは無関係に、凄そうに見える発信自体に経済的インセンティブが働く
  • 額面通り受け取る必要のなさ:
    • 発信者全員がそうだとは言わず、本当に有効な運用をしている人もいる
    • ただしこのインセンティブ構造がある以上、24時間ぶん回しているという言説を額面通り受け取る必要はない

■ 2. コストから見た破綻

  • 従量課金という前提:
    • LLMのAPIは従量課金であり、高品質なモデルを常時稼働させればトークン消費は青天井になる
    • 個人開発者の予算感でこれを続けるのは現実的ではない
  • 格安モデルの罠:
    • 安価なモデルは出力の精度が下がるため手戻りのコストが発生する
    • 生成されたコードのレビュー、修正指示、再生成というループを人間が回すコストがかかる
    • 安く大量に回す戦略は、高品質なモデルで一発で仕留めるよりしばしば高くつく
  • どちらに転んでも生じる矛盾:
    • 高品質モデルの常時稼働はAPI課金で破綻する
    • 格安モデルの常時稼働は人間の時間という手戻りコストで破綻する

■ 3. 「回さない」ことこそ設計

  • 無駄な処理を走らせない原則:
    • ソフトウェアエンジニアリングでは無駄な処理を走らせないことが良い設計の基本だった
    • 条件分岐による不要処理のスキップ、アーリーリターン、キャッシュがその具体例
    • AIを使った開発でもこの原則は何も変わらない
  • 目指すべき理想:
    • 最小のトークンで狙った出力(ゴール)に到達することが本来目指すべき方向
  • 常時稼働は設計の敗北:
    • とにかく常時回すというアプローチは設計判断を放棄している
    • 条件分岐が書けずループでゴリ押しするコードと構造的に同じもの

■ 4. 動的オーケストレーションの欠如

  • あるべきマルチエージェント構成:
    • 親玉となるモデルが状況を判断し、必要なときだけ特化型の子分を呼び出す動的なオーケストレーションが理想
    • タスクが発生したら起動し、終わったら止める
    • 呼び出す・呼び出さないの判断そのものが設計の腕の見せどころ
  • 常時稼働が示す裏返し:
    • 全部を常に動かしておくのは、判断ロジックを作れない、あるいは作る発想がないことの裏返し
    • オートスケーリングやサーバーレスが当たり前の時代に、AIだけ常時フル稼働が正義とするのは逆行

■ 5. ゴールは「作ること」ではなく「使われること」

  • 誤ったボトルネックの前提:
    • AIを常時回して量産する発想は、開発のボトルネックが作ることにあるという前提に立つ
    • この前提自体が間違っている
  • 「作る」の裏にある泥臭さ:
    • AIにより動くゲームを作ること自体は驚くほど速くなった
    • 面白いゲームにするには難易度カーブやレベルデザインの調整が要り、数値をいじっては遊んで確かめる反復を伴う
    • 触っていて気持ちいいという手触りの作り込みが必要になる
    • 世界観やキャラクターに一貫性を持たせる判断が必要になる
    • プレイして・感じて・直すという泥臭い反復が欠かせない
  • 映像作品でも同じ構造:
    • 素材の生成は速くなっても、どのカットを何秒見せるか、どこで音を入れるかという編集の判断は残る
    • その判断は観る人間の感覚に依存する
  • 実用システムのエッジケース:
    • ECサイトや予約システムも、画面と機能を作るだけならAIで一瞬
    • 実際に使われるには決済まわりの安全性、個人情報の扱い、注文の二重登録への備えが不可欠
    • ここを飛ばして生成されたものは、動いて見えても金や個人情報を任せられないシステムになる

■ 6. リリース後の自動化できないフェーズ

  • プロダクトはリリースして終わりではない:
    • 誰に届けるのかを見極めて周知するマーケティングが必要
    • ライセンスや価格をどう設計するかを決める必要がある
    • 検索で見つけてもらうための地道なSEO整備が必要
    • 初期ユーザーの声を拾い、対応と改善を重ねる工程が必要
  • 完全自動化できない理由:
    • 判断の主体が人間であり相手も人間である以上、構造的に完全自動化できない
    • AIは文章のドラフトや分析の補助はするが、誰にどう届けるかという意思決定は肩代わりしない

■ 7. 「ハイ次!」が成立する理由

  • スキップされている工程:
    • AIで作った、ハイ次!というサイクルを高速で回せている場合、リリース後のフェーズを丸ごとスキップしている可能性を疑うべき
    • 使われるための泥臭い工程を全部飛ばせば、いくらでも次に行ける
    • それはプロダクトの量産ではなく、誰にも届かない成果物を積み上げているだけかもしれない
  • 骨組みだけの家という比喩:
    • 内装も検査も引き渡しもせず、骨組みだけの家を次々に建てているようなもの
    • 着工数だけを見れば凄まじい生産性だが、誰も住めない

■ 8. 結論

  • AI活用そのものは否定しない:
    • AIは作業スピードを圧倒的に上げてくれる優秀な道具であり、実際に開発の中心で使っている
    • 問題は道具そのものではなく、放置して稼ぐ魔法の装置であるかのような扱い方
  • 押さえるべき三つの視点:
    • AIは常時回すものではなく、必要なときに最小のコストで狙った出力を引き出すもの
    • 良い設計とは回す量を増やすことではなく、いかに回さずに済ませられるか
    • プロダクト開発のゴールは使われることであり、そこには自動化できない工程が必ずある
  • 迫力に飲まれない姿勢:
    • 回した量は成果ではなく、その言葉が発信者の商材である可能性すらある
    • ツールやハッタリに踊らされず目の前の課題と向き合うことが、本物のプロダクトへの最短ルート

MEMO: