AI時代にCTOは必要か。コードを書く人より判断する人が足りなくなる

AIがコードを書くなら、CTOはいらなくなるのでしょうか。僕の答えは逆です。AI時代ほど、技術上の推奨を作り、経営者が決裁できる材料へ変える人が必要になります。

理由は、AIが実装を速くしても、会社として何を作るか、どの費用と危険を受け入れるか、誰が本番投入を承認するかまでは決めないからです。実装案が早く出るほど、経営者の前には多くの選択肢が並びます。選択肢を会社の判断へ変える人がいなければ、試作品と未決事項だけが増えていきます。

ただし、すべての会社が正社員CTOを採用すべきという話ではありません。必要なのは肩書きではなく、技術判断の責任者です。社内のエンジニアが担う会社では社内へ権限を渡し、担当者がいない会社では外部のCTOや技術顧問で補えます。

AI時代にもCTOは必要です。ただし正社員採用だけが答えではありません

CTOを「会社で一番コードを書く人」と捉えると、AIが実装を担う時代には不要に見えます。僕はCTOを、事業の目的と技術上の選択肢をつなぎ、会社として採用する案を推奨する人だと考えています。

たとえば、新しいサービスを三か月後に出したいとします。AIを使えば、画面やAPIの試作は以前より始めやすくなりました。しかし、三か月後に誰が使うのか、最初の顧客へ何を約束するのか、個人情報をどこへ保存するのか、公開後に誰が障害へ対応するのかは、コードを生成しても決まりません。

CTOは、事業側から期限、予算、顧客との約束を聞きます。技術側からは、実現方法、継続費用、運用人数、セキュリティ、失敗した場合の影響を集めます。集めた情報を同じ物差しへそろえ、推奨案と見送る案を経営者へ渡します。

最終決裁は経営者に残ります。CTOが担うのは、経営者の代わりに会社を決める仕事ではなく、技術に詳しくなくても選べる状態を作る仕事です。CTO代行が経営判断へ用意する材料でも、推奨を作る人と最終決裁者を分けています。

正社員CTOが必要かどうかは、会社の成長段階と技術判断の量で変わります。毎週複数の開発チームが動き、採用、予算、設計、障害対応を継続して決めるなら、社内の専任者が必要になる可能性が高いです。技術議題が月に数件で、実装は開発会社が担っているなら、部分稼働の外部CTOでも判断を回せます。

AIが増やすのはコードより、会社が選ぶ案です

AIは、一つの要望から複数の実装案を作れます。既存サービスを導入する案、最小限だけ自社開発する案、全面的に作る案を短時間で比べることもできます。選択肢が増えること自体は歓迎すべき変化です。

一方で、選択肢が増えるほど、前提をそろえる仕事が重くなります。開発費が安い案でも、毎月の利用料や保守作業が大きい場合があります。公開が早い案でも、顧客データを扱えない場合があります。機能が豊富な案でも、半年後に変更できる人がいなければ事業の足かせになります。

AIへ「最適な案を選んでください」と頼んでも、会社が優先する条件を渡さなければ一般的な回答しか返りません。売上を優先するのか、顧客との約束を守るのか、初期費用を抑えるのか、将来の変更余地を残すのかは、経営上の方針です。方針が曖昧な状態では、生成される案を増やしても決裁は速くなりません。

DORAの2025年調査は、約5,000人の技術職への調査回答と定性データから、AIを組織の強みと弱みを増幅する存在として整理しています。調査はCTOの必要性を直接証明する比較実験ではありませんが、AIツールだけで組織の成果が決まらず、明確な方針、利用者への集中、開発基盤といった周囲の条件が結果を左右するという説明は、経営者にも重要です。

実装の入口だけが速くなると、仕様確認、レビュー、テスト、本番承認に仕事が集まります。AI時代のボトルネックは、コードを書き始める場所から、作った案を会社として採用する場所へ移ります。

AI時代のCTOが引き受けるのは、五つの経営判断です

最初に必要なのは、何を作るかの判断です。顧客の課題、売上への影響、作らない場合の損失を比べ、今扱う課題を一つに絞ります。AIは候補を広げられますが、限られた資金と時間をどこへ使うかは会社が決めます。

次に、作るか買うかを決めます。既存サービスで始めれば早く試せますが、利用料、機能制限、データ移行が残ります。自社で作れば業務へ合わせやすい半面、保守、障害対応、担当者の採用まで会社が引き受けます。比較期間と対象業務をそろえなければ、初期費用の安さだけで誤った案を選びます。

三つ目は、AIへ渡す情報と権限です。公開情報の整理と、顧客データを含む本番環境の変更では、失敗時の影響が違います。入力してよい情報、参照できるシステム、実行できる操作、記録するログを決め、人間の承認が必要な境界を置きます。

四つ目は、本番へ出す条件です。AIが作ったコードも、人が書いたコードと同じく、仕様、テスト、セキュリティ、切り戻し方法を確認します。「AIが生成したから危険」「人が書いたから安全」と作者だけで分けず、変更の影響で確認の深さを変えます。

五つ目は、続ける条件と止める条件です。試作品が動いた事実だけでは、事業で使う判断はできません。誰が何のために使い、どの数字が変われば投資を続けるのか、費用や事故がどこまで増えたら止めるのかを先に決めます。

五つの判断には、事業と技術の両方の情報が必要です。経営者だけでは技術上の影響を読み切れず、実装担当者だけでは予算や顧客との約束を決められません。経営と技術をつなぐ人が会議の前にそろえる論点のように、両者の間で推奨案を作る役割が必要です。

AI時代のCTOは、実装より判断の流れを設計します

AI時代のCTOも、コードや設計を読める必要があります。技術を理解せずに、生成された案の前提、変更範囲、危険を評価できないからです。ただし、CTO自身がすべてのコードを書く必要はありません。

CTOが設計するのは、誰が課題を選び、誰がAIへ依頼し、誰が結果を確認し、誰が本番投入を承認するかという流れです。危険度の低い変更は自動化し、顧客データ、決済、認証、削除できない操作には人間の承認を残します。判断理由、採用しなかった案、見直す条件も会社の記録として残します。

AIの利用率や生成したコード量を、個人の評価へ直結させる必要もありません。見るべき対象は、顧客へ価値が届くまでの時間、判断待ち、手戻り、変更失敗、復旧にかかった時間です。実装だけが速くなってレビュー待ちが増えたなら、AIを使う人を増やす前に仕事の流れを直します。

社内に経験のあるエンジニアがいるなら、技術上の推奨を作る権限を渡し、経営者との決裁経路を明示する方法があります。方向を示せば社内で動ける会社なら、月に数回の技術顧問でも足りる場合があります。開発会社の管理、優先順位、採用、障害対応まで動かす人がいないなら、外部CTOが実行管理へ入る選択肢があります。

正社員CTOの採用をやめる必要はありません。条件が合えば、最短1週間で外部の技術責任者と着手し、採用活動と技術判断を並行できます。正社員CTOが決まったら、判断記録、権限、未解決の議題を引き継ぎます。CTOを業務委託で入れて採用までの空白を埋める方法も、外部の人へ経営判断を丸投げせずに使う前提で書いています。

明日の会議で、止まっている技術判断を一つ書き出します

AIツールの追加契約やCTO採用の前に、直近一か月で止まった技術議題を一つ選んでください。顧客データをAIへ渡してよいか、試作品を本番で使ってよいか、開発会社の提案を採用するか、追加予算を出すかといった議題です。

一枚の資料へ、決めたい期限、比較する案、足りない情報、技術上の推奨を作る人、最終決裁者、決裁後に動く人を書きます。推奨を作る人の欄だけが空白なら、足りないのはコードを書く人数ではなく、技術判断の責任者です。

正社員CTOを採用するか、社内のエンジニアへ役割を渡すか、外部のCTOを入れるかは、空白になった仕事の量と継続期間から決められます。肩書きから探し始めるより、止まった議題から必要な役割を決めるほうが、依頼範囲も評価方法も具体的になります。

AIは、案を作る速度を上げます。会社として何を採用し、どの結果を引き受けるかは人が決めます。AI時代のCTOに求められるのは、コードを独占することではありません。経営と技術をつなぎ、増えた選択肢を決めて動ける形へ変えることです。