第1回では、「AIツールを配ったのに変わらない」という現象の正体――AIを足しても開発プロセスを組み替えていないこと――を解きほぐしました。全3回の第2回となる本稿では、視点を「捉え方」から「判断」へ移します。「どう作るか」と「何を作るか」の2軸、一番の盲点である費用構造、そして適用をどう決めるか。マネジメントが実際に手を動かす判断編です。

【第1回のふりかえり】
「配ったのに変わらない」のは、AIツールを足しても開発プロセスを組み替えていないからでした。AI-assisted（道具の足し算）と AI-native（プロセスの再設計）は別物で、変化の本丸はハーネスという土台の上でプロセスと役割を組み替えること――。ここまでが第1回でした。第2回は、その先の実務です。ではマネジメントは、何を・どこに・どう判断し、どこに投資すべきか。

「作り方」と「作るもの」は別の判断

ここまでは「どう作るか」（開発プロセス）の話でした。判断のテーブルには、これとは独立したもう一つの軸「何を作るか」（成果物の性質）があります。この軸は、二つの問いで整理できます。
問い①：稼働時にAIを呼ぶか？――これがトークン課金の有無を決めます。
問い②：処理の流れを決めるのは、コードか、AIか？――これが費用と挙動の“読めなさ”を決めます。
二つの問いを重ねると、出来上がるシステムは三つの形に分かれます。

呼び方も整理しておきます。処理の流れをAIが決めるものをAgentic、コードが決めるものをNon-Agenticと呼ぶ二分法で言えば、Non-AI型とAI組込み型はどちらもNon-Agenticに属します。見逃されやすいのが真ん中のAI組込み型です。「Non-Agenticだが、トークン課金は乗る」――この形態の存在が、費用判断で最も混同されやすいポイントです（次章で詳述します）。

誤解しないでほしいのは、Agentic型がほかの二形態の上位互換ではないということです。Non-AI型は「同じ手順を確実に繰り返す」業務に向き、AI組込み型は「流れは固定だが、一部に非構造データの処理がある」業務に向き、Agentic型は「状況に応じて判断し、変化に追随する」業務に向きます。再現性が求められる業務にAgentic型を当てると確率的な振る舞いがノイズになり、変化が激しい業務にNon-AI型を当てると硬直化します。三つは階段ではなく、業務特性に応じた選択肢です。

何でもAIにしなくていい ―― 向き不向きという判断

この軸を実際に手を動かして確かめると、当たり前のことがはっきりします。入力に対して常に同じ結果が求められる処理（決定論的な処理）は、従来型のプログラムのほうが確実に優れています。これは技術者にとっては常識ですが、マネジメントの判断としても重要です。「AIの時代だから何でもAIで」という熱に対して、向き不向きがあるとはっきり線を引けることは、投資を無駄にしないための歯止めになります。計算・照合・帳票のように答えが一意に決まる処理を、わざわざ確率的に振る舞うAgentic型で作る理由はありません。

もう一つ、実務で最も多いパターンを押さえておきます。「業務の大半は決定論的だが、一部に非構造データの処理がある」――紙の帳票から項目を読み取る、問い合わせを分類する、文書を要約する、といったケースです。この答えは、多くの場合Agentic型ではなくAI組込み型です。流れはコードが握ったまま、AIにしかできないステップだけをAIに任せる。「AIを使う」ことと「エージェント化する」ことは、別の判断です。

費用構造 ―― ここが一番の論点

マネジメントにとって最も重要なのが費用の話です。先に前提を一つ。本章の費用の議論は、フロンティア各社のモデルをクラウドAPI経由（従量課金）で利用する前提で進めます。この前提そのものを選び直す選択肢――ローカルLLMという固定費構造――は、第3回で扱います。その上でポイントは、費用は二つの軸が別々に生むという点です。開発時の費用は開発プロセス軸が決め、稼働時の費用は成果物軸が決めます。

「トークン課金」は従来のAPI課金と同質ではない

「APIを呼んだら課金される」構造は従来からありました。ところがAgentic型のトークン課金は、表面上似ていても、構造的に異なります。特に重要な違いだけを抜き出します。

観点	従来のAPI課金	Agentic型のトークン課金
業務の複雑さとの関係	業務の複雑さとコストはほぼ独立	業務の複雑さがそのままコストに反映される（難しい判断ほど高くつく）
上限の見え方	プランやレート制限で明示的	1リクエスト内でAIが何度も推論するため青天井になりうる
変動要因	トラフィックの量	量に加えて、リクエストの内容そのもの

なお、AI組込み型のトークン課金は、性質としては左列（従来のAPI課金）に近い点に注意してください。呼び出し回数と入出力サイズが設計時に固定されるため、「単価×件数」の感覚が通用します。右列の性質――複雑さの反映、青天井、内容依存――は、AIが処理の流れを握るAgentic型に固有のものです。トークン課金の有無ではなく、流れを誰が握るかが、費用の“読めなさ”を分けます。

特に押さえたいのが「業務の複雑さがそのままコストに反映される」という性質です。従来のITコスト構造では、難しい業務ロジックを実装しても、本番の実行コストはそう変わりませんでした。難しさは開発時の人件費に乗るだけで、本番は粛々と動く。ところがAgentic型では、難しい判断をAIにさせるほど多段の推論が回り、業務の難しさが本番でも費用として現れ続けます。「一度作れば本番では安く動く」という従来の前提が崩れます。

結論

「AI-nativeにしたら本番が高くつく」のではありません。本番の費用構造を変えるのは成果物の形であって、開発プロセスではありません。AI-nativeで開発してもNon-AI型なら稼働時は従来通り。逆にAI-assistedで作ったシステムでも、稼働時にAIを呼べばトークン課金が乗ります。そしてその課金が“読める”か“読めない”かを分けるのは、AI介在の有無ではなく、処理の流れを誰が握るか（AI組込み型かAgentic型か）。この区別が、費用判断の出発点です。

本章では費用の話を重ねてきましたが、これは投資をためらわせるためではありません。うまく組めたときに得られるものは大きい――実装にかかる工数の構造が変わり、人の時間を実装作業から要件・評価・判断へ寄せられる。変化の速い業務に、システムを追随させ続けられる。だからこそ、その効果を絵に描いた餅にしないために、費用の構造を先に押さえておく――本章をここに置いたのは、その順序のためです。

判断のための四つの軸

ここからは判断の実務です。AI導入を判断するとき、次の四つの軸を共通の足場にします。これらは前向きに進める判断にも、慎重に進める判断にも、適用しないという判断にも、同じように使えます。

軸1. システム適合軸（主にAI-native開発側）

AI-nativeは、AIがコードと文脈の全体像を読み解けることを前提にします。対象システムがこの前提とどこまで噛み合うかを見る軸です。

軸2. コスト軸（両方に関わる）

AI-nativeもAI組込み型・Agentic型も、従来と異なる費用が発生します（前章参照）。それを組織として引き受けられるかを見る軸です。

軸3. 組織・人材軸（主にAI-native開発側）

AI-nativeへの移行は、技術の話であると同時に組織と人材の話です。むしろこちらが本丸になることも多い軸です。

軸4. 技術リスク軸（両方に関わる）

AI-nativeもAgentic型も、技術的にまだ発展途上です。本番適用にあたって認識しておくべきリスクを整理します。

軸1（システム適合）と軸3（組織・人材）はAI-native移行の判断で特に重みが増し、軸2（コスト）と軸4（技術リスク）はAI-native移行と成果物形態（特にAgentic型）の両方の判断に効いてきます。組織として進める判断にも、慎重に進める判断にも、同じ四つの軸を共通の足場にして自社の言葉で言語化するのが本稿の立場です。

適用の三つの問い

四つの軸を踏まえた上で、実際の適用は次の三つの問いに落とし込みます。順番に答える必要はなく、組織として並行して言語化する論点です。

1. どこに適用するか ―― システム特性と業務特性

すべての領域に同じ度合いで進める必要はありません。むしろ領域ごとに異なる選択をすることが現実的です。

2. 何を適用するか ―― 開発プロセス軸と成果物軸

「AIを導入する」という問いは、二つの独立した問いに分解して別々に判断します。

3. どこから着手するか ―― 順序の判断

「どこに」「何を」が決まっても、一度に動かせるわけではありません。順序の判断が実行性を決めます。

人間が握り続けるべきこと

AI-nativeを選ぶか選ばないか、Agentic型を作るか作らないかに関わらず、人間が握り続けるべき領域があります。むしろ、AIに任せられる範囲が広がるほど、人間の判断はより広範囲で、より高度になります。「人間が握る」列が、AIに委ねきれない人間の判断です。

工程		人間が握る	AIが担う
価値判断フェーズ	事業判断	何を解決すべきか、なぜAIでやるか、投資対効果。ビジネス価値の最終定義。	市場・競合の調査補助、シナリオ分析の補助。
	要求定義	誰の何を解決するか。価値仮説の言語化。ステークホルダー合意。	ヒアリング整理、矛盾点の指摘、事例参照。
開発判断フェーズ	要件・設計	何を作るかの決定。評価基準の定義。アーキテクチャ判断（何を捨て何を取るか）。	文書化、不整合チェック、選択肢提示、詳細設計、API定義生成。
	実装・検証	差分レビュー、危険箇所への介入。受け入れ観点設計。最終判断、業務適合性の確認。	コード生成全般、テスト生成・実行・解析。生成役と評価役のAIが分担。
運用判断フェーズ	デプロイ判断	本番投入の最終判断、ロールアウト戦略決定。	デプロイ実行、監視自動化。
	運用・改善	異常への対処方針、改善優先度、撤退の判断。	異常検知、ログ分析、改善案生成。

重要なのは、これらの判断が価値判断フェーズに偏っているわけではないことです。各フェーズに人間の判断密度があります。特にAI時代に押さえたいのは、開発判断が「作業の指示」ではなくなることです。開発プロセスやアーキテクチャの選び方一つで、人間が制御でき、AIが推論しやすく、長期メンテに耐える構造が作れるかが決まります。これは従来の「コードをどう書くか」よりも、一つ上の抽象度の判断です。

AIに任せられる範囲が広がるほど、人間の判断はより広範囲で、より高度になります。

まとめ

本稿では、「配ったのに変わらない」という現象を入口に、AI開発でマネジメントが押さえるべき勘所を整理してきました。要点は三つです。

届けたいメッセージは一つです。AI-nativeや成果物三形態に対する判断は、システム特性に応じて、自社の言葉で領域ごとに言語化することが大事。観点を押さえた上で選ぶこと。組織にとって本当に価値ある選択は、構造を理解し、四つの軸を整理し、三つの問いに自社の答えを持つことの先にあります。

そして第3回へ ―― まだ蓋を開けていない箱

もっとも、本稿にはまだ一つ、蓋を開けていない箱があります。開発時にも稼働時にも現れた「トークン課金」――実はこの費用には、変動費（クラウドAPI）と固定費（ローカルLLM）という二つの経済形態があり、どちらを選ぶかは「どう作るか」とも「何を作るか」とも独立した、もう一つの判断です。続く第3回では、この「モデルをどう調達するか」という第三の軸を扱います。変動費と固定費の分かれ目、成果物三形態との相性の非対称、そして意外な盲点――開発そのものが最大のAIワークロードになるという話まで。判断の地図を、もう一枚だけ広げます。

最後に、本稿の根底にある姿勢を共有させてください。AIについては、自分自身と自組織でまず使い込み、自分たちなりの理解を深めることが、判断の前提だと考えています。机上で考えるだけでは実感できないことが多く、技術がもたらす変化は手を動かして体感する必要があります。すでに使いこなしている人たちの声を聞くことも、判断を磨く近道です。知って、使って、それから選ぶ――この順序を推奨します。

出典・参考資料

Agentic System / 費用構造

編集注記

本稿は、技術の詳細ではなくマネジメントの判断に効く観点に絞って構成しています。用語の系譜（Vibe Coding / Agentic Engineering 等）や内部アーキテクチャといった技術的な深掘りは、あえて割愛しています。文中の各社の動向・製品名・時期は執筆時点（2026年7月時点）のものです。